DCMI Government Application Profile
| Creators: |
Maewyn Cumming
|
| Contributors: |
Palle Aargaard
Makx Dekkers Paul Murphy John Borras |
| Date Issued: | 2001-09-17 |
| Latest Version: | https://dublincore.org/specifications/dublin-core/gov-application-profile/ |
| Release History: | https://dublincore.org/specifications/dublin-core/gov-application-profile/release_history/ |
| Description: | This proposal is for an application profile that clarifies the use of Dublin Core in a Government context. It was prepared by the Managing Information for e-Government (MIReG) group in conjunction with the DCMI-Government Working Group. |
Contents
- Introduction
- Namespaces and Format of entries
- DC-Extensions and additions
- DC-Government Application Profile
1. Introduction
In June 2001, the first of a series of seminars was held in Brussels under the general title 'Managing information resources for e-government' (MIReG). Attended by representatives from many European governments as well as Australia, Canada and New Zealand, it revealed that we were all in similar positions regarding tagging information to improve acessibility and manageability.
Following the seminar MIReG became part of the revised IDA Programme (Interchange of Data between Administrations) for 2001. It will produce an EC metadata framework covering vocabulary control and other encoding schemes, ontologies and topic maps, software interfaces and best practice guidelines. MIReG works in conjunction with other EC programmes such as ParlML.
Working practices within IDA require the establishment of an Advisory Board to take control of each programme. The MIReG Advisory Boardconsists of:
· John Borras - UK Office of the e-Envoy
· Peter Pappamikail, European Parliament, ParlML project
· Palle Aargaard, Denmark, Communications Consultant, Danish State Information Service
· Makx Dekkers, Luxembourg, Managing Director, DCMI
· Paul Murphy, European Commission, IDA Programme
· Maewyn Cumming, UK Office of the e-Envoy.
MIReG also works with CEN (European Standards Organisation) to help its Metadata for MulitMedia Information - Dublin Core™ (MMI-DC) Workshop.
MIReG's main tasks are to:
- Produce an EC metadata framework, including a metadata standard, XML schema to support standard, vocabulary lists (geography and subjects), specifications for toolkits and search engines and implementation advice, eg training, conversion of legacy systems;
- Support the DC-Gov Working Group in the establishment of a Dublin Core™ government extension; and
- Support the establishment of an MMI-DC government metadata standard
Metadata in the public sector
Dublin Core™ is already being used by practically all governments that are attempting to improve access to their information. However, though seen as the ideal starting point, it is not sufficient for our varied and specialised needs. It doesn't cater for data security, or the requirements of the data protection or freedom of information legislation, the need for information audit trails, or the complex legislative processes. It is therefore necessary to extend DC to create an element set comprehensive enough to cope with the job in hand.
MIReG will also need to build on the DC-Gov extensions to create a metadata standard with a more comprehensive remit than DC, but remaining compatible. While DC covers the requirement for improved resource discovery, elements and refinements to satisfy the needs of good records management and integrated document management systems are also needed.
Why? Official information often has a long life. Records are maintained for statutory periods, these can vary from a few months to perpetuity. The management of these records, and the ability to locate them after many years and many changes in the structure of government, is a challenging task, and more so now that that electronic records are making many of the established systems redundant. In their eternal drive for efficiency, government are looking for a system that will allow the creation of metadata that will see information resources throughout their long lives, minimising the need to repeat or edit data.
2. Namespaces and Format of entries
The DC-Government Application Profile consists of several namespaces:
· Dublin Core™ Metadata Element Set, Version 1.1 [DCMES version 1.1]
· Dublin Core™ Qualifiers [DCMES Qualifiers (2000-07-11)]
· DC-Gov Metadata Element Set (DC-GOVMES)
· DC-Gov Metadata Element Set Qualifiers (DC-GOVMES Qualifiers)
Format of entries:
| Name | The unique token assigned to the qualifier |
| Label | The human-readable label assigned to the qualifier. |
| Choice of Namespace | DCMES version 1.1, DCMES Qualifiers (2000-07-11) or DC-Gov Metadata Element Set = DC-Gov, DC-Gov Metadata Element Set Qualifiers = DC-Gov Qualifiers |
| DC Refinement(s) | DC Element Refinements: These qualifiers make the meaning of an element narrower or more specific. A refined element shares the meaning of the unqualified element, but with a more restricted scope. |
| DC-Gov Refinement(s) | DC-Gov refinement, see above; these are domain-specific refinements for DC-Gov. |
| DC Encoding Scheme(s) | These qualifiers identify schemes that aid in the interpretation of an element value. These schemes include controlled vocabularies and formal notations or parsing rules. A value expressed using an encoding scheme will thus be a token selected from a controlled vocabulary (e.g., a term from a classification system or set of subject headings) or a string formatted in accordance with a formal notation (e.g., "2000-01-01" as the standard expression of a date). If an encoding scheme is not understood by a client or agent, the value may still be useful to a human reader. |
| DC-Gov Encoding Scheme(s) | DC-Gov encoding scheme, see above; these are domain-specific encoding schemes for DC-Gov. |
| Form of Obligation | In the DC-Gov data model the obligation can be: mandatory (M), mandatory if applicable (MA), strongly recommended (R) or optional (O). Mandatory "M" ensures that some of the elements are always supported and mandatory if applicable "MA" means that this element must be supported if the information is available. An element with a mandatory "M" obligation must have a value. The strongly recommended and the optional elements should be filled with a value if the information is appropriate to the given resource but if not, they can be left blank. |
| DC Definition | Dublin Core™ definition of metadata field |
| DC Comment | Dublin Core™ comments to this metadata field |
| DC-Gov Definition | DC-Gov definition of metadata field |
| DC-Gov Comment |
DC-Gov comments to this metadata field |
| Best practice |
Recommendations of best use of this element for DC-Gov |
| Open questions | Problems, notes, open questions regarding this field |
3. DC-Extensions and additions
A summary of the extensions, additions and other changes proposed to the Dublin Core™ Elements Set.
A. Additional Element
1. Audience
A category of user for whom the resource is intended
B. Additional refinements to existing DC elements
1. Date
>
> >Acquisition >Date on which the resource was received into the organisation. >
2. Relation
>
> >IsBasedOn >The resource is an adaptation, translation, derivation or > interpretation of another resource >> >IsBasisFor >The resource is adapted, translated, derived or interpreted > by another resource >
3. Rights
>
> >Access marking >Item or notation regulating access to the resource. >> >Previous Access marking >Item or notation of immediately preceding marking, if any, > at time of change. >> >Access marking change date >Date that the access marking allocated previously to the > current AccessMarking was changed. >> >Access rights >Constraints or obligation governing the release of the resource. >> >Copyright >Indicates the copyright status of the resource >
4. Subject
>
> >Category >Broad subject categories from a prescribed list. >> >Keyword >Words or terms used to describe, as specifically as possible, the subject > matter of the resource. >
5. Type
>
> >Aggregation level >A resource type may be an aggregation of instances of another resource > type. >> >Dossier type >Describes the purpose or genre of a collection of items >> >Item type >Describes the purpose or genre of a specific item or document >
4. DC-Government Application Profile
Audience
>
> >Name >Audience >> >Label >Audience >> >Choice of Namespace: >? >> >DC Refinement(s) >See below >> >DC-Gov Refinement(s) >See below >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >- >> >Form of Obligation >O >> >DC Definition >A class of entity for whom the resource is intended or useful. >> >DC Comment >> > >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >> > >Open Questions >Encoding scheme(s) are needed but the definitive scheme > does not yet exist. >
Contributor
>
> >Name >Contributor >> >Label >Contributor >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >> > >DC-Gov Refinement(s) >> > >DC Encoding Scheme(s) >> > >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >MA >> >DC Definition >An entity responsible for making contributions to the content > of the resource. >> >DC Comment >Examples of a Contributor include a person, an organisation, > or a service. Typically, the name of a Contributor should be used to indicate > the entity. >> >DC-Gov Definition >> > >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
Coverage
>
> >Name >Coverage ¦ Spatial >> >Label >... >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >DCMI Point, ISO 3166, DCMI Box, TGN >> >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >R or MA >> >DC Definition >Spatial characteristics of the intellectual content of the > resource. >> >DC Comment >Coverage will typically include spatial location. Recommended > best practice is to select a value from a controlled vocabulary. >> >DC-Gov Definition >- >> >DC-Gov Comment >> > >Best Practice >Use Coverage with qualifier Spatial or Temporal. >> >Open Questions >Is there a suitable encoding scheme that meets the level of > detail and variety of regions that government information resources cover? > >
>
> >Name >Coverage ¦ Temporal >> >Label >Coverage | Temporal >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >DCMI Period, W3C-DTF >> >DC-Gov Encoding Scheme(s) >- >> >Form of Obligation >R or MA >> >DC Definition >Temporal characteristics of the intellectual content of the > resource. >> >DC Comment >Coverage will typically include temporal period. Recommended > best practice is to select a value from a controlled vocabulary. >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >? >> >Open Questions >>
Creator
>
> >Name >Creator >> >Label >Creator >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >> > >DC-Gov Refinement(s) >> > >DC Encoding Scheme(s) >> > >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >See below >> >DC Definition >An entity primarily responsible for making the content of > the resource. >> >DC Comment >Examples of a Creator include a person, an organisation, or > a service. Typically, the name of a Creator should be used to indicate the > entity. >> >DC-Gov Definition >> > >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
Date
>
> >Name >Date >> >Label >Date >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >see below >> >DC-Gov Refinement(s) >see below >> >DC Encoding Scheme(s) >see below >> >DC-Gov Encoding Scheme(s) >- >> >Form of Obligation >MA >> >DC Definition >A date associated with an event in the life cycle of the resource. >> >DC Comment >Typically, date will be associated with the creation or availability > of the resource. Recommended best practice for encoding the date value is > defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format. >> >DC-Gov Definition >- >> >DC-Gov Comment >> > >Best Practice >A refinement should always be used. >> >Open Questions >Do we accept the Date element without refinement? How to deal > with inadequacies of the possible encoding schemes? There are limitations > in conveying: 1) BCE dates; 2) non-Gregorian calendar dates; 3) ambiguity, > approximation (e.g., about, near, flourished, assumed); 4) partially known > dates (e.g., 19?? ); 5) date is unknown/unavailable; 6) open-ended intervals > (e.g., 1999-); 7) complex, multi-instance/period intervals. Are there > conventions (e.g. bracket, slash, etc.) or other encoding schemes we want > to specify to allow for these limitations? >
Date
>
> >Name >Date ¦ Acquired >> >Label >DATE ¦ Acquired >> >Choice of Namespace: >? >> >DC Refinement(s) >See below >> >DC-Gov Encoding Scheme(s) >W3CDTF >> >Form of Obligation >> > >DC Definition >Date on which the resource was received into the organisation. >> >DC Comment >> > >DC-Gov Definition >- >> >DC-Gov Comment >The nature of a resource can change when it is submitted > by one authority to another, ( e.g. in legislative procedures) without > necessarily any change being made to the content of that resource. EXAMPLE: > The date that a legislative text is tables for consideration (=date of > acquisition by the House) is not the same as the date the resource is > adopted (by the submitting or receiving authority). >> >Best Practice >> > >Open Questions >>
Date
>
> >Name >Date ¦ created >> >Label >Date ¦ Created >> >Choice of Namespace: >DCMES Qualifiers (2000-07-11) >> >DC Encoding Scheme(s) >see below >> >DC-Gov Encoding Scheme(s) >W3CDTF >> >DC Definition >Date of creation of the resource. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
Date
>
> >Name >Date ¦ valid >> >Label >Date ¦ Valid >> >Choice of Namespace: >DCMES Qualifiers (2000-07-11) >> >DC Encoding Scheme(s) >see below >> >DC-Gov Encoding Scheme(s) >W3CDTF >> >DC Definition >Date (often a range) of validity of the resource. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >? >> >Open Questions >>
Date
>
> >Name >Date ¦ available >> >Label >Date | Available >> >Choice of Namespace: >DCMES Qualifiers (2000-07-11) >> >DC Encoding Scheme(s) >see below >> >DC-Gov Encoding Scheme(s) >W3CDTF >> >DC Definition >Date (often a range) that the resource will become or did > become available. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >? >> >Open Questions >>
Date
>
> >Name >Date ¦ issued >> >Label >Date | Issued >> >Choice of Namespace: >DCMES Qualifiers (2000-07-11) >> >DC Encoding Scheme(s) >see below >> >DC-Gov Encoding Scheme(s) >W3CDTF >> >DC Definition >Date of formal issuance (e.g. publication) of the resource. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >Includes date resource was put onto a web site. >
> Time may also be needed e.g. where the item was subject to a press embargo.> >Best Practice >> > >Open Questions >>
Date
>
> >Name >Date ¦ modified >> >Label >Date | Modified >> >Choice of Namespace: >DCMES Qualifiers (2000-07-11) >> >DC Encoding Scheme(s) >see below >> >DC-Gov Encoding Scheme(s) >- >> >DC Definition >Date on which the resource was changed. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >> > >Open Questions >>
Description
>
> >Name >Description >> >Label >Description >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >Table of contents; Abstract >> >DC-Gov Refinement(s) >Table of contents; Abstract >> >DC Encoding Scheme(s) >> > >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >R >> >DC Definition >An account of the content of the resource. >> >DC Comment >Description may include but is not limited to: an abstract, > table of contents, reference to a graphical representation of content or > a free-text account of the content. >> >DC-Gov Definition >- >> >DC-Gov Comment >The description could cover approach to subject (e.g. critique, > explanation, beginners guide), reason for production of resource, groups > and organisations referred to, events covered, list of key fields (database) > or chapters, any other useful information >> >Best Practice >> > >Open Questions >>
Format
>
> >Name >Format >> >Label >Format >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >Extent; Medium >> >DC-Gov Refinement(s) >see below >> >DC Encoding Scheme(s) >IMT >> >DC-Gov Encoding Scheme(s) >IMT >> >Form of Obligation >R >> >DC Definition >The physical or digital manifestation of the resource. >> >DC Comment >Typically, Format may include the media-type or dimensions > of the resource. Format may be used to determine the software, hardware > or other equipment needed to display or operate the resource. Examples of > dimensions include size and duration. Recommended best practice is to select > a value from a controlled vocabulary (for example, the list of Internet > Media Types [MIME] defining computer media formats). >> >DC-Gov Definition >> > >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
Identifier
>
> >Name >Identifier >> >Label >... >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >- >> >DC-Gov Refinement(s) >> > >DC Encoding Scheme(s) >> > >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >M >> >DC Definition >An unambiguous reference to the resource within a given context. >> >DC Comment >Recommended best practice is to identify the resource by means > of a string or number conforming to a formal identification system. Example > formal identification systems include the Uniform Resource Identifier (URI) > (including the Uniform Resource Locator (URL)), the Digital Object Identifier > (DOI) and the International Standard Book Number (ISBN). >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >Use best practice statement as above. >> >Open Questions >Should ISBN, ISSN be used as encoding schemes?How to deal > with internal identifiers - we could build on EC work developing a hierachical > scheme for identifiers, adding identifiers for country/organisation/item > to create a unique identifier. >
Language
>
> >Name >Language ¦ ISO639-2/B >> >Label >Language ¦ ISO639-2/B >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >- >> >DC-Gov Refinement(s) >- >> >DC Encoding Scheme(s) >ISO 639-2/B; RFC 1766 >> >DC-Gov Encoding Scheme(s) >ISO 639-2 >> >Form of Obligation >M >> >DC Definition >A language of the intellectual content of the resource. >> >DC Comment >> > >DC-Gov Definition >Use the bibliographic codes from ISO 639-2. ISO 639-2 in general > is a DCMI approved encoding scheme. >> >DC-Gov Comment >- >> >Best Practice >Use codes rather than text. >> >Open Questions >>
Publisher
>
> >Name >Publisher >> >Label >Publisher >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >> > >DC-Gov Refinement(s) >> > >DC Encoding Scheme(s) >> > >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >R >> >DC Definition >An entity responsible for making the resource available. >> >DC Comment >Examples of a Publisher include a person, an organisation, > or a service. Typically, the name of a Publisher should be used to indicate > the entity. >> >DC-Gov Definition >> > >DC-Gov Comment >> > >Best Practice >A publisher has certain legal responsibilities regarding the > information, so should always be named. >> >Open Questions >>
Relation
NOTE - qualifiers appear here in pairs, to save space.>
> >Name >Relation >> >Label >Relation >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >see below >> >DC-Gov Refinement(s) >see below >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >Form of Obligation >O >> >DC Definition >A reference to a related resource. >> >DC Comment >Recommended best practice is to reference the resource by > means of a string or number conforming to a formal identification system. >> >DC-Gov Definition >- >> >DC-Gov Comment >If using qualifiers, use the most specific one that is applicable. >> >Best Practice >> > >Open Questions >>
Relation
>
> >Name >Relation ¦ isVersionOf / HasVersion >> >Label >Relation | Is Version Of / Has Version >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >Form of Obligation >> > >DC Definition >The described resource is a version, edition, or adaptation > of the referenced resource. Changes in version implies substantive changes > in content rather than differences in format. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
>
> >Name >Relation ¦ IsBasedOn / IsBasisFor >> >Label >Relation ¦ Is Based On / Is Basis For >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >The described resource is a translation, derivation or interpretation > of another resource. >> >DC-Gov Comment >Whereas IsVersionOf indicates a 'linear' evolution of a > content from one stage to another, IsBasedOn indicates a 'transversal' > relationship with another resource, either of a similar or same nature > in another language or of a completely separate resource that nonetheless > has inspired or been used in the creation or evolution of the resource. > EXAMPLES. A legal act that 'IsBasedOn' a draft legislative proposal and > a European Union directive. A press release that IsBasedOn the published > research paper. >> >Best Practice >> > >Open Questions >Need some good examples here, and perhaps a better definition. >
>
> >Name >Relation ¦ IsFormatOf / HasFormat >> >Label >Relation | Is Format Of / Has Format >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >DC Definition >The described resource is the same intellectual content > of the referenced resource, but presented in another format. >> >DC Comment >- >> >DC-Gov Definition >The described resource is the same intellectual content > of the referenced resource, but presented in different physical or digital > format. >> >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
>
> >Name >Relation ¦ isReplacedBy / Replaces >> >Label >Relation | Is Replaced By / Replaces >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >Form of Obligation >> > >DC Definition >The described resource is supplanted, displaced, or superceded > by the referenced resource. >> >DC Comment >- >> >DC-Gov Definition >> > >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
>
> >Name >Relation ¦ IsPartOf / HasPart >> >Label >Relation | Is Part Of / Has Part >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >Form of Obligation >> > >DC Definition >The described resource is a physical or logical part of > the referenced resource. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >Can be used in conjuction with Type¦Aggregation level > to give a clear description of dossiers and collections. >> >Best Practice >> > >Open Questions >>
>
> >Name >> Relation ¦ IsRequiredBy / Requires >> >Label >Relation | Is Required By / Requires >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >DC Definition >The described resource requires the referenced resource > to support its function, delivery, or coherence of content. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >> > >Open Questions >>
>
> >Name >Relation ¦ isReferencedBy / References >> >Label >Relation | Is Referenced By / References >> >Choice of Namespace: >DCMES Qualifiers >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >DC Definition >The described resource is referenced, cited, or otherwise > pointed to by the referenced resource. >> >DC Comment >- >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >> > >Open Questions >>
Rights
>
> >Name >Rights >> >Label >Rights >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >- >> >DC-Gov Refinement(s) >See below >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >See below >> >Form of Obligation >MA >> >DC Definition >Information about rights held in and over the resource. >> >DC Comment >Typically, a Rights element will contain a rights management > statement for the resource, or reference a service providing such information. > Rights information often encompasses Intellectual Property Rights (IPR), > Copyright, and various Property Rights. >> >DC-Gov Definition >- >> >DC-Gov Comment >The rights element is used to indicate security markings, > as well as legal and other obligations and restrictions on access to the > resource. >> >Best Practice >> > >Open Questions >>
Rights
>
> >Name >Rights ¦ AccessMarking >> >Label >Rights ¦ Access Marking >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >- >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >Item or notation regulating access to the resource. >> >DC-Gov Comment >The security or access classification of the resource. EXAMPLES: > Secret, Confidential-within-administration, Public >> >Best Practice >> > >Open Questions >>
>
> >Name >Rights ¦ PreviousAccessMarking >> >Label >Rights ¦ Previous Access Marking >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >- >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >Item or notation of immediately preceding marking, if any, > at time of change. >> >DC-Gov Comment >> > >Best Practice >> > >Open Questions >>
Rights
>
> >Name >Rights ¦ PreviousAccessMarkingChangeDate >> >Label >Rights ¦ Previous Access Marking Change Date >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >W3CDTF >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >Date that the access marking allocated previously to the > current AccessMarking was changed . >> >DC-Gov Comment >Date of the change indicated in the preceding refinement. >> >Best Practice >> > >Open Questions >>
Rights
>
> >Name >Rights ¦ AccessRights >> >Label >Rights ¦ AccessRights >> >Choice of Namespace: >? >> >DC Refinement(s) >See below >> >DC-Gov Encoding Scheme(s) >- >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >Constraints or obligation governing the release of the resource. >> >DC-Gov Comment >Indicates the legal or other basis upon which governs public > access to the resource.EXAMPLE: Regulation (EC) No 1049/2001 of the European > Parliament and of the Council of 30 May 2001 regarding public access to > European Parliament, Council and Commission documents (http://europa.eu.int/eur-lex/en/lif/dat/2001/en_301R1049.html) >> >Best Practice >> > >Open Questions >Should we add the option of using an encoding scheme? >
>
> >Name >Rights ¦ Copyright >> >Label >Rights ¦ Copyright >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >- >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >Identifier or statement indication the legal ownership and > rights regarding use of the resource. >> >DC-Gov Comment >> > >Best Practice >Link to a standard description of rights such as the Crown > copyright notice at www.hmso.gov.uk/docs/copynote.htm. >> >Open Questions >Does this clash with the DC-Lib proposal to have a Date¦copyright > refinement? Would it be better to put the Copyright statement and date > together in this refinement? >
Source
>
> >Name >Source >> >Label >Source >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >- >> >DC-Gov Refinement(s) >- >> >DC Encoding Scheme(s) >URI >> >DC-Gov Encoding Scheme(s) >URI >> >Form of Obligation >see below >> >DC Definition >A reference to a resource from which the present resource > is derived. >> >DC Comment >The present resource may be derived from the Source resource > in whole or in part. Recommended best practice is to reference the resource > by means of a string or number conforming to a formal identification system. >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >Reference by means of an identifier >> >Open Questions >>
Subject
>
> >Name >Subject >> >Label >Subject >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >- >> >DC-Gov Refinement(s) >see below >> >DC Encoding Scheme(s) >LCSH ; MeSH ; DDC ; LCC ; UDC >> >DC-Gov Encoding Scheme(s) >LCSH ; MeSH ; DDC ; LCC ; UDC >> >Form of Obligation >MA >> >DC Definition >The topic of the content of the resource. >> >DC Comment >Typically, a Subject will be expressed as keywords, key phrases > or classification codes that describe a topic of the resource. Recommended > best practice is to select a value from a controlled vocabulary or formal > classification scheme. >> >DC-Gov Definition >- >> >DC-Gov Comment >> > >Best Practice >> > >Open Questions >May Subject element be used in a unqualified form? >
Subject
>
> >Name >Subject ¦ Category >> >Label >Subject ¦ Category >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >- >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >A broad or top level subject categorisation or classification > of subject areas. >> >DC-Gov Comment >Differs from Subject¦Keyword in that it requires > a broad heading only not a specific subject descriptor. This will be used > for browsing systems (Yahoo-type categories) and other circumstances where > only a broad heading is needed. >> >Best Practice >Value to be taken from wither framework-specifi or organisation > specific taxonomy. >> >Open Questions >Coincides with the proposed DC-Lib Subject¦Classification > refinement. Prefer 'Category' as 'Classification' implies an alphanumeric > code. >
Subject
>
> >Name >Subject ¦ Keyword >> >Label >Subject ¦ Keyword >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >- >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >Term describing the specific subject of the resource >> >DC-Gov Comment >Entry would contain the subject to be found at the lowest > level of granularity available in a controlled vocabulary or thesaurus > and descriptive of the xubject matter of the resource. >> >Best Practice >Term from a thesaurus or similar controlled vocabulary. >> >Open Questions >Coincides with the proposed DC-Lib Subject¦Keyword.Requires > a specific subject descriptor rather than broad heading. Will be used > to aid the mapping of multiple thesauri. >
Title
>
> >Name >Title >> >Label >Title >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >Alternative >> >DC-Gov Refinement(s) >Alternative >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >- >> >Form of Obligation >M >> >DC Definition >A name given to the resource. >> >DC Comment >Typically, a title will be a name by which the resource is > formally known. >> >DC-Gov Definition >- >> >DC-Gov Comment >For alternative title add any form of the title used as a > substitute or alternative to the formal title of the resource, including > abbreviations. >> >Best Practice >Drop initial articles if present >> >Open Questions >>
Type
>
> >Name >Type >> >Label >Resource Type >> >Choice of Namespace: >DCMES version 1.1 >> >DC Refinement(s) >- >> >DC-Gov Refinement(s) >See below >> >DC Encoding Scheme(s) >DCMI Type >> >DC-Gov Encoding Scheme(s) >see below >> >Form of Obligation >R >> >DC Definition >The nature or genre of the content of the resource. >> >DC Comment >Type includes terms describing general categories, functions, > genres, or aggregation levels for content. Recommended best practice is > to select a value from a controlled vocabulary. To describe the physical > or digital manifestation of the resource, use the Format element. >> >DC-Gov Definition >- >> >DC-Gov Comment >- >> >Best Practice >Use a controlled list and identify the source with encoding > scheme. >> >Open Questions >Do we accept the Type element in an unqualified form? >
>
> >Name >Type ¦ AggregationLevel >> >Label >Type ¦ Aggregation Level >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >Collection; Dossier; Item >> >Form of Obligation >R >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >A resource type may be an aggregation of instances of another > resource type. >> >DC-Gov Comment >> >This element allows searches to be restricted to records at a particular > level of aggregation. It also controls the management actions which > may be taken on the record(s).
>It should be worked in conjunction with Relation¦HasPart. This > refinement describes where in the collection hierachy, if anywhere, > a resource sits; the relation indicates what, if any other resources > also belong in that hierachy.
>Note that it is possible for a 'Folder' or 'collection' level description > to exist for a resource which is empty, i.e. it contains no parts. In > this instance the HasPart relation would not indicate the level. Nor > is it possible to limit a search by Level by using HasPart.
>The entry indicates the level of aggregation.
>> >Best Practice >> > >Open Questions >>
>
> >Name >Type ¦ DossierType >> >Label >Type ¦ Dossier Type >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >R >> >DC Definition >> > >DC Comment >A number of items gathered together into one container or > folder. >> >DC-Gov Definition >Classification of the dossier or collection. >> >DC-Gov Comment >An example encoding scheme (as used by UK) is Policy; Case; > Parliamentary Question; Ministers Case. >> >Best Practice >> > >Open Questions >>
>
> >Name >Type ¦ ItemType >> >Label >Type ¦ ItemType >> >Choice of Namespace: >? >> >DC Encoding Scheme(s) >- >> >DC-Gov Encoding Scheme(s) >> > >Form of Obligation >R >> >DC Definition >> > >DC Comment >> > >DC-Gov Definition >Classification of the item, file or document. >> >DC-Gov Comment >> > >Best Practice >> > >Open Questions >Should we develop a DC-Gov Type encoding scheme that covers > specifically governmental Types such as Parliamentary Questions, Ministerial > Correspondence etc? >