Title Government Application Profile
Creator Maewyn Cumming
Contributor Palle Aargaard; Makx Dekkers; Paul Murphy; Peter Pappamikail, John Borras, DC-Gov
Date Issued 2001-09-17
Identifier
Replaces Not applicable
IsReplacedBy Not applicable
Status of document This is a DCMI Working draft
Description This proposal is for an application profile that clarifies the use of Dublin Core in a public administration context. It was prepared by the Managing Information for e-Government (MIReG) group in conjunction with the DC-Gov Working Group.
1. Introduction
2. Namespaces and Format of entries
4. DC-Government Application Profile
This document proposes a possible application profile to clarify the use of the Dublin Core Metadata Element set by public administrations and in public sector-related applications and projects. The proposal is submitted by the Dublin Core Government Working Group to the Dublin Core Usage Board. The content of this document is intended to reflect the consensus reached within DCGov for a minimal extension set.
Dublin Core
is already being used by practically all public administrations that want to
use metadata to improve access to their information.
However,
though seen as the ideal starting point, Dublin Core is not sufficient for our
varied and specialised needs. It doesn't cater for data security, or the
requirements of data protection or freedom of information legislation, nor the
need for information audit trails, or the complex legislative processes.
It is
therefore necessary to advance on two inter-connected fronts:
- the
development of an extension to DC to create an element set comprehensive enough
to cope with the job in hand;
- the
development of an appropriate metadata framework , including application
profiles, encoding schemes and indications of best practice, that
administrations can subsequently use to support the proposed extended metadata
set.
The DC-Gov
working group has therefore joined forces with the MIReG Advisory Board to
advance the extension; MIReG is part of the European Union IDA Programme
(Interchange of Data between Administrations) for 2001, charged with producing
an EC metadata framework. The MIReG Advisory Board consists of
* John Borras - UK Office of the e-Envoy
* Peter Pappamikail, European Parliament,
ParlML project
* Palle Aagaard, 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
MultiMedia Information - Dublin Core (MMI-DC) Workshop. The Dublin Core
Government working group will likewise continue to work over the next year with
other interested parties to clarify and quantify the various issues and develop
further proposals as necessary.
The extension
to DC is the subject of the present submission; The metadata framework is
exclusively the concern and remit of MIReG and will develop in consequence of
the first.
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, or |
|
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) |
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) |
These are domain-specific encoding schemes for DC-Gov. |
|
Form of Obligation |
In the DC-Gov data model the obligation can be: Mandatory, Mandatory if applicable, Recommended or Optional. "Mandatory" ensures that some of the elements are always supported and “Mandatory if applicable” means that this element must be supported if the information is available. An element with a Mandatory obligation must have a value. The “Recommended” and “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 this metadata field |
|
DC Comment |
Dublin Core comments on this metadata field |
|
DC-Gov Definition |
DC-Gov definition of this metadata field, if different from the DC definition |
|
DC-Gov Comment |
DC-Gov comments on this metadata field |
|
Best practice |
Recommendations of best use of this element for DC-Gov |
|
Open questions |
Problems, notes, open questions regarding this field |
A summary of the extensions, additions and other changes proposed to the Dublin Core Elements Set
A. Additional Element
1. Audience
A class of entity for whom the resource is intended or useful
B. Additional refinements to existing DC elements
1. Date
|
acquired |
Date on which the resource was received into the organisation |
2.
Relation
|
isBasedOn |
The
described resource is a translation, derivation or interpretation of another
resource |
|
isBasisFor |
The
described resource is translated, derived or interpreted by another resource |
3. Rights
|
access marking |
Item or notation regulating access to the resource. |
|
previousAccessMarking |
Item or notation of immediately preceding marking, if any, at time of change. |
|
accessMarkingChangeDate |
Date that the access marking allocated previously to the current accessMarking was changed. |
|
accessRights |
Constraints or obligation governing the release of the resource. |
|
copyright |
Identifier or statement indicating the legal ownership and rights regarding use of the resource |
4.
Subject
|
category |
A broad or top level subject categorisation or classification of subject areas. |
|
keyword |
Term describing the specific subject of the resource. |
5.
Type
|
aggregationLevel |
A resource type may be an aggregation of
instances of another resource type: |
|
dossierType |
Classification of the dossier or collection of items |
|
itemType |
Classification of the item, file or
document |
4.
DC-Government Application Profile
Audience
|
Name |
audience |
|
Label |
Audience |
|
Choice of Namespace: |
? |
|
DC-Gov Refinement(s) |
- |
|
Form of Obligation |
Optional |
|
DC-Gov Definition |
A class of entity for whom the resource is intended or useful. |
|
DC-Gov Comment |
This element describes the people for whom the resource is aimed, e.g. the educational level, profession etc. It does not indicate rights of access. |
|
Best practice |
This element should be left blank unless a specific audience is intended; i.e. there is little to be gained in terms of retrieval by putting ‘general public’ or ‘everyone’. |
|
Open questions |
An encoding scheme is needed and will be developed as part of the MIReG project |
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 |
Mandatory if applicable |
|
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 |
Examples of a Contributor include a person or organisation. Typically, the name of a Contributor should be used to indicate the entity. |
|
Best practice |
- |
|
Open questions |
- |
Coverage
|
Name |
coverage ¦ spatial |
|
Label |
Coverage ¦ Spatial |
|
Choice of Namespace |
DCMES Qualifiers |
|
DC Encoding Scheme(s) |
DCMI Point, ISO 3166, DCMI Box, TGN |
|
DC-Gov Encoding Scheme(s) |
ISO 191115 Other schemes as appropriate |
|
Form of Obligation |
Recommended or Mandatory if applicable |
|
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? Should there be a separate Jurisdiction refinement? Is this really a sub-refinement of Coverage.spatial? Can we have Jurisdiction as a refinement of Creator and Coverage? |
|
Name |
coverage ¦ temporal |
|
Label |
Coverage | Temporal |
|
Choice of Namespace |
DCMES Qualifiers |
|
DC Encoding Scheme(s) |
DCMI Period, W3C-DTF |
|
DC-Gov Encoding Scheme(s) |
DCMI Period, W3C-DTF |
|
Form of Obligation |
Recommended or Mandatory if applicable |
|
DC Definition |
Temporal characteristics of the intellectual content of the resource. |
|
DC Comment |
Coverage will typically include temporal period. |
|
DC-Gov Definition |
- |
|
DC-Gov Comment |
- |
|
Best practice |
- |
|
Open questions |
Level of obligation |
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 |
Mandatory |
|
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 |
Examples of a Creator include a person or organisation. Typically, the name of a Creator should be used to indicate the entity. This Agent often has legal responsibilities and obligations, and personal names may be needed for audit trails. |
|
Best practice |
Indicate the Creator as specifically as possible, e.g. include not only the organisation but also the section, department or team and individual as applicable. |
|
Open questions |
Do we need qualifiers for the Jurisdiction and Function of the Creator? |
Date
|
Name |
date |
|
Label |
Date |
|
Choice of Namespace |
DCMES version 1.1 |
|
DC Refinement(s) |
Created, Valid, Available, Issued, Modified |
|
DC-Gov Refinement(s) |
Acquired, Created, Valid, Available, Issued, Modified, |
|
DC Encoding Scheme(s) |
W3CDTF, DCMI Period |
|
DC-Gov Encoding Scheme(s) |
W3CDTF, DCMI Period |
|
Form of Obligation |
Mandatory if applicable |
|
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? |
Date
|
Name |
date ¦ acquired |
|
Label |
Date ¦ Acquired |
|
Choice of Namespace: |
? |
|
DC Refinement(s) |
- |
|
DC-Gov Encoding Scheme(s) |
W3CDTF |
|
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 tabled 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 |
- |
|
Name |
date ¦ created |
|
Label |
Date | Created |
|
Choice of Namespace |
DCMES Qualifiers (2000-07-11) |
|
DC Encoding Scheme(s) |
W3CDTF |
|
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 |
- |
|
Name |
date ¦ valid |
|
Label |
Date | Valid |
|
Choice of Namespace |
DCMES Qualifiers (2000-07-11) |
|
DC Encoding Scheme(s) |
W3CDTF, DCMI Period |
|
DC-Gov Encoding Scheme(s) |
W3CDTF, DCMI Period |
|
DC Definition |
Date (often a range) of validity of the resource. |
|
DC Comment |
- |
|
DC-Gov Definition |
- |
|
DC-Gov Comment |
- |
|
Best practice |
? |
|
Open questions |
- |
|
Name |
date ¦ available |
|
Label |
Date | Available |
|
Choice of Namespace |
DCMES Qualifiers (2000-07-11) |
|
DC Encoding Scheme(s) |
W3CDTF, DCMI Period |
|
DC-Gov Encoding Scheme(s) |
W3CDTF, DCMI Period |
|
DC Definition |
Date (often a range) that the resource will be or did become available. |
|
DC Comment |
- |
|
DC-Gov Definition |
- |
|
DC-Gov Comment |
- |
|
Best practice |
- |
|
Open questions |
- |
|
Name |
date ¦ issued |
|
Label |
Date | Issued |
|
Choice of Namespace |
DCMES Qualifiers (2000-07-11) |
|
DC Encoding Scheme(s) |
W3CDTF |
|
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 |
A unique date, rather than a range, on which a resource was published or otherwise made available. Includes date resource was put onto a web site. The Time of issue may also be needed e.g. where the item was subject to a press embargo. |
|
Best practice |
|
|
Open questions |
|
|
Name |
date ¦ modified |
|
Label |
Date | Modified |
|
Choice of Namespace |