Namespace Policy for the Dublin Core™ Metadata Initiative (DCMI)- Working Draft

Title:

DRAFT Namespace Policy for the Dublin Core™ Metadata Initiative (DCMI)

Editor: Stuart Weibel
Contributor: Tom Baker
Contributor: Tod Matola
Contributor:
Date Issued: 2001-03-09
Identifier: http://dublincore.org/specifications/dublin-core/dcmi-namespace/2001-03-09/
Is Replaced By: http://dublincore.org/specifications/dublin-core/dcmi-namespace/2001-09-17/
Latest version:
Status of document:
This is a DCMI Working Draft.
Description of document:

NOTE: This document is for discussion purposes only at this time.

The use of XML namespaces [XML-NAMES] for formal, machine-processable declarations of metadata entities is a convention intended to support web-addressable concepts that can be shared across applications, and hence promote the possibility of shared semantics.  DCMI adopts this convention for the identification of all DCMI terms.  This document identifies the policies and procedures associated with the naming of existing DCMI terms and those that will be defined in the future.


Glossary:

The following are defined terms in this document:

  • DCMI recommendations
    A DCMI recommendation is a document written for human reading that is the final result of the approval process for DCMI terms.
     
  • DCMI terms
    The phrase DCMI terms is used to denote names of elements or qualifiers identified in DCMI recommendations and systems.  Each DCMI term is identified by a Uniform Resource Identifier within the DCMI namespace.
     
  • DCMI term declarations
    A DCMI term declaration is the machine-processable representation of a DCMI term, expressed in a schema language and maintained in the DCMI registry.
     
  • DCMI registry
    The DCMI registry is the software repository of DCMI term declarations for all DCMI terms.
     
  • DCMI metadata packages
    A DCMI metadata package is a discrete collection of DCMI terms identified as a group for management purposes.  Each DCMI package has its own sub-namespace within the DCMI registry namespace.
     

I. Introduction

The use of XML namespaces [XML-NAMES] for formal, machine-processable declarations of metadata entities is a convention intended to support web-addressable concepts that can be shared across applications, and hence promote the possibility of shared semantics.  DCMI adopts this convention for the identification of all DCMI terms.  This document identifies the policies and procedures associated with the naming of existing DCMI terms and those that will be defined in the future.

II. Relation of DCMI term declarations to DCMI recommendations

DCMI Recommendations are human-readable documents that describe the end products of the process of proposing, discussing, revising, and approving DCMI terms.  These documents constitute the primary deliverables of the initiative and can be used to communicate the definitions of DCMI terms and related architectural issues to interested readers.  The consensus-driven agreements articulated in these documents are encoded in a schema language in order to support machine-processable declarations that can be useful to software applications.  The DCMI registry is the authoritative repository of all such declarations for terms managed by the initiative.

III. Namespace declarations used by DCMI for DCMI registry declarations

The namespace of the Dublin Core™ metadata element set (version 1.1) is:

http://purl.org/dc/elements/1.1/

Declarations for individual elements are constructed by adding entity_name, for example:

http://purl.org/dc/elements/1.1/title

is the web-addressable identifier for one of the 15 elements of the Dublin Core™ metadata element set.  Each of the 15 elements can be so identified.  Stability of namespace identifiers for metadata terms is critical to interoperability over time. Thus, the wide promulgation of this set of identifiers dictates that they be maintained to support legacy applications that have adopted them.

As DCMI registry infrastructure evolves, it will become the repository of the canonical definitions of all DCMI terms (in the form of schema declarations that are machine-processable, but also can provide human-readable definitions).  Thus, the three currently approved DCMI metadata packages have the following namespaces:

http://purl.org/dc/elements/1.1/``http://dublincore.org/2000/03/13/dcq# ``http://dublincore.org/2000/03/13/dctype#

Official declarations for all additional metadata packages approved by DCMI, including additional elements, qualifiers and domain specific metadata packages, are specified as

http://dublincore.org/_YYYY/MM/DD_/_package_identifier#_[term_name]

Thus, subcomponents of DCMI namespace Identifiers include the following components:

protocol identifier http://
DCMI Domain dublincore.org/
YYYY/MM/DD/ a date-stamp identifying the date of instantiation of the package in the registry software
package_identifier string a string identifying the DCMI metadata package in which a given set of DCMI terms are aggregated
term_name string a hash-delimited string identifying the name of the DCMI term

It is important to recognize that the date-stamp component should not be construed as a version identifier or even as a date-stamp identifying the inclusion of a given term in a given DCMI metadata package, but rather as an administrative device signaling the instantiation of a given package.

IV. DCMI metadata declarations in multiple languages

DCMI terms must have a single URI within the DCMI registry to assure unambiguous identity, however DCMI terms are rendered in many different languages and character sets.  It is a functional requirement of a multi-lingual metadata registry such as the DCMI registry that an application be able to issue a service request to the registry to return the attributes of a given term in any of the languages and character sets in which it has been encoded.

V. Policy concerning classes of changes to DCMI terms

Changes to DCMI terms or term declarations will occur from time to time for a variety of reasons. Such changes have varying implications for namespace declarations.  The following classes of changes are identified along with examples and associated implications for namespaces.

A. Minor editorial errata

Errors of spelling, punctuation, or other clerical mistakes discovered in the DCMI registry will be corrected without public notification or comment period, as long as, in the judgment of the DCMI directorate, there are no implications for negative impact on users or applications that rely on DCMI term declarations.

Correction of minor editorial errata will result in no changes in namespaces within the DCMI registry.

B. Substantive editorial errata

Errors of substance discovered in the DCMI registry will trigger public notification of the correction to the general information email server (DC-General).   Errors that, in the judgment of the DCMI Directorate, compromise the immediate usefulness or accuracy of DCMI metadata systems will be corrected immediately (for example, an incorrect URL to a resource external to DCMI).  Others will be corrected following a 14-day public comment period to assure that changes do not adversely effect systems or applications which rely on the DCMI namespace infrastructure.

Correction of substantive editorial errata will result in no changes in namespaces within the DCMI registry.

C. Semantic changes in DCMI terms

Changes of definitions of DCMI terms will be reflected in metadata registry declarations as a result of a formal approval process within DCMI. If, in the judgment of the DCMI Directorate, such changes of meaning are likely to have substantial impact on either machine processing of DCMI terms or the functional semantics of the terms, then these changes will be reflected in a change of namespace identifier for the DCMI term or terms in question.

D. Changes in approval status

A DCMI term can have one of several approval statuses as defined by the DCMI Usage Board. (proposed, conforming, recommended, obsolete are currently under discussion).  Changes in approval status represent annotation on the DCMI term declarations.  It is a functional requirement of the DCMI registry to respond to a service request querying the approval status of a DCMI term for any date within the operational interval of the registry.

Changes in approval status have no impact on namespace identifiers for DCMI terms

E. Addition of DCMI term declarations to existing DCMI metadata packages

New elements or qualifiers will from time to time be added to existing DCMI metadata packages.  Such additions will be uncommon for, for example, the Dublin Core™ element set, and somewhat more frequent for packages that are lists of controlled terms such as the DC Type list.

Addition of DCMI terms to existing packages will not trigger changes in namespace identifiers.

F. Addition of new packages to the DCMI metadata registry

DCMI terms are packaged in collections of terms that have DCMI metadata package identifiers as part of their namespace identifiers.  New packages will be added to the DCMI registry as the result of approval of additional collections of DCMI terms.

VI. Persistence Policy

DCMI recognizes that people and applications depend on the persistence of formal documents and machine processable schemas made available on the DCMI Website and through the DCMI metadata registry. The DCMI pledges that as far as they are able, formal documents and metadata schemas will continue to be available throughout the life of the DCMI. Where a persistent resource is modified, a change history will be archived.

In the event that DCMI is disbanded, then any organization will be granted the right to make a copy (at a different URI) of all public persistent DCMI resources, so long as (1) they are not modified, (2) are preserved in their entirety and (3) are made available to others free of charge.

VII. Archival time series of registry status

It is a functional requirement of the DCMI registry that a service request to the registry with a parameter of any date within the interval of operation of the registry shall return the state of the registry and all DCMI terms on that date.

References

[XML-NAMES] Namespaces in XML, W3C Recommendation, 14 January 1999
http://www.w3.org/TR/REC-xml-names