- ReplicatingDCMESINDCTERMS

Replicating DCMES properties in the DCTERMS namespace

This document is part of the DC Usage Board Wiki.

IMPORTANT: Do not cite materials in this Wiki other than for the purposes of collaborating on document creation. This Wiki is intended to be used to work on draft copies of documents. Finished documents will be published, in a persistent and citable form, on the dublincore.org Web site (or elsewhere in some cases).

Please announce any significant changes to this Wiki via the DC-USAGE@jiscmail.ac.uk list.

To express a view on this proposal please complete the short JISCMail survey by 2006-04-26.

Proposal

The 15 DCMES properties that are currently assigned URIs in the DC namespace (http://purl.org/dc/elements/1.1/) will be replicated in the DCTERMS namespace (http://purl.org/dc/terms/), i.e. 15 new terms will be added to the DCTERMS namespace.
The existing terms in the DC namespace will continue to be valid, however implementors will be encouraged to use the newer terms.
The RDFS/OWL machine-readable declarations for the 15 existing terms will be modified to indicate the equivalences between the existing terms and the newer terms.
The RDFS/OWL machine-readable declarations for the 15 new terms will indicate the equivalences between the newer terms and the existing terms.
The human-readable declarations of both sets of terms will indicate the equivalences between the older and newer terms and will recommend usage of the newer terms.
The DCMI namespace policy and the various encoding guidelines (XHTML, XML and RDF) will be updated to use the newer terms.
The DCMI-maintained XML schemas that support the encoding of DC metadata in XML will be updated.

Background

The Namespace Policy for the Dublin Core Metadata Initiative (DCMI) defines how term URIs are assigned to all DCMI metadata terms and what guarantees DCMI makes about their persistence.

The 15 terms (elements) that make up the "Dublin Core Metadata Element Set, Version 1.1" are assigned URIs in the DC namespace (i.e. they are assigned URIs that begin with http://purl.org/dc/elements/1.1/). All other DCMI terms (including new elements, element refinements, encoding schemes and terms in DCMI-maintained controlled vocabularies) are assigned URIs in the DCTERMS namespace, the DCMITYPE namespace or in a vocabulary-specific namespace.

Implementors of metadata systems using DC properties that go beyond the use of the 15 DCMES elements therefore need to build knowledge about two different namespaces into their applications. This causes some confusion about the correct URI for terms in the different namespaces. For example, there is some evidence of people using 'DC' URIs for terms in the DCTERMS namespace and vice versa. There is also some evidence that the perceived hurdle of having to deal with two namespaces rather than one is sufficient to cause implementors to ignore Dublin Core metadata in favour of their own (or third-party) solutions.

According to the current namespace policy, the following XHTML example use of two DCMI elements is correct:

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />

<meta name="DC.title" content="_the title_" />
<meta name="DCTERMS.audience" content="_the audience_" />

Under the proposed change, this would become:

<link rel="schema.DC" href="http://purl.org/dc/terms/" />

<meta name="DC.title" content="_the title_" />
<meta name="DC.audience" content="_the audience_" />

Impact of this proposal

On metadata producers

Systems that expose metadata (e.g. for harvesting or in search results) will not need to be changed in any way, though the implementors of such systems will be encouraged to move to using the 15 new terms in the DCTERMS namespace rather than the older terms in the DC namespace.

On metadata consumers

Systems that consume metadata (e.g. by harvesting it or receiving it in search results) will need to be modified to treat the 15 new terms in the DCTERMS namespace as equivalents for the 15 older terms in the DC namespace. This may be done by hardwiring such knowledge into the software, or by extracting this knowledge automatically from the machine-readable schema declarations of the DCMI terms (i.e. the RDFS/OWL schemas that are available at the two namespace URIs).

On DCMI documentation

The DCMI namespace policy and the XHTML, XML and RDF encoding guidelines will all need to be updated.

The machine-readable RDFS/OWL schemas available at the DCMI namespace URIs will need to be updated.

The DCMI-maintained XML schemas will need to be updated.

Arguments in favour of the proposal

Replicating the 15 DCMES terms in the DCTERMS namespace means that implementors need only deal with a single namespace for all DC elements and element refinements.

Arguments against the proposal

Although in the long term this proposal should result in less confusion amoungst implementors, it may result in greater confusion in the short term.
The use of separate DC and DCTERMS namespaces may be perceived to be helpful in highlighting the 'core' natures of the 15 DCMES properties.

Note on the continued use of PURLs as metadata term identifiers

This proposal would result in the coining of fifteen new PURL-based identifiers for DCMI metadata terms. It should be noted that the continued use of PURLs as the base URI for DCTERMS identifiers will consolidate a situation in which DCMI cannot comply with a June 2005 W3C TAG resolution on the use of http URIs for non-information resources such as metadata terms. As explained in the W3C Working Draft Best Practice Recipes for Publishing RDF Vocabularies:

http://purl.org

If the PURL server were modified to support the selection of a response code by the maintainer of a PURL, this would solve the problem. However, it is unclear whether the maintainers of the PURL server software would want to do this.

> ReplicatingDCMESINDCTERMS