Scope of DCMI Namespaces

DCMI Assignment of URIrefs and DCMI Namespaces

A central part of DCMI's role is to support the creation, development, maintainance and use of DCMI terms. All DCMI terms are grouped into vocabularies which DCMI refers to as DCMI Namespaces. Currently there are three DCMI Namespaces and each DCMI Namespace is identified by a URI reference.

As part of the process of creating a new DCMI term, that term is assigned a name and a URI reference that provides a persistent, globally unique identifier for the term. The URIref assigned to an individual term is determined by the DCMI Namespace to which the term is assigned: the URI reference for the term is derived by appending the name of the term to the URIref of that DCMI Namespace. DCMI supports the assignment of these URIrefs with a policy statement guaranteeing their persistence as identifiers.[1].

Proposals for new terms typically emerge from the work of DCMI Working Groups who identify specific requirements for extending the DCMI vocabularies, and draft descriptions in the form required by the DCMI Usage Board. The Usage Board evaluates proposals according to a published set of criteria. [2].

DCMI Working Groups, DC Application Profiles and Resource-Type-Specific Properties

DCMI has emphasised its role in supporting cross-domain resource discovery. The properties (elements and element refinements) within the DCMI Namespaces are all applicable to a wide range of resource types; none are constrained to the description of a specific class of resource.

The Usage Board process document does not explicitly exclude the possibility of accepting proposals for properties that are specific to the description of one class of resource, but there is a widely-held perception that only properties that are applicable to a wide range of resource types are candidates for inclusion as elements or element refinements in DCMI Namespaces.

However, some Working Groups chartered by DCMI are working to develop DC-based metadata schemas for the description of specific types of resource, in the form of DC Application Profiles. The DC Collection Description WG is one such group [3, 4]. As part of this work, the group has suggested the use of properties that, while they are developed within the Dublin Core Grammatical Principles, are specific to the description of a Collection. For example, the term "Accrual Status" is used to provide

A statement of accrual policy (closed, passive, active, partial/selective), accrual method (purchase, deposit) and accrual periodicity (closed, irregular, periodic). [5].

The semantics of this property dictate that it is meaningful only when applied to the description of a resource to which "accruals" can be made, i.e. a Collection.

In order for these properties to be usable by implementers, they must be assigned (persistent, globally unique) URIrefs, so that those URIrefs can be cited in statements made within "instance metadata" records. But the only procedure currently available within DCMI for the assignment of persistent identifiers is to submit the terms to Usage Board as candidates for a DCMI Namespace. If this option is closed, then the WG then faces the question of what URIs to assign to these properties.

Options Available

No resource-type-specific terms permitted in AP:
No URIref assigned: The WG might decide not to assign a URIref to the property at all and to provide only a human readable description of the property. However if the WG fails to assign a URIref to a property, the goal of semantic interoperability that the WG was chartered to achieve is lost, or at least compromised, as individual implementers are left to assign (possibly many different) URIs to refer to the property defined by the WG. The assignment of a URIref to its properties is critical to the goals of the WG.
Third-party-owned URI assigned: If the WG itself can not assign persistent URIs, and DCMI UB can not assign the term to a DCMI Namespace, then the WG must seek a third-party who can provide this function, which in turn raises issues of trust in the capacity of that provider to deliver the persistence offered by DCMI.
Inclusion of property in current "dcterms" DCMI Namespace: Consequences? Use of rdfs:domain?
Inclusion of property in a new DCMI Namespace: Specific to resource-type? Specific to DCMI WG? UB-maintained/WG-maintained?

Issues Arising

References

[1] Powell, Andy and Harry Wagner. Namespace Policy for the Dublin Core Metadata Initiative (DCMI), (November 2001)
http://dublincore.org/documents/dcmi-namespace/

[2] Hillman, Diane and Stuart A. Sutton. DCMI Usage Board (UB) Administrative Processes, (February 2003)
http://dublincore.org/usage/documents/process/

[3] DC Collection Description Working Group
http://dublincore.org/groups/collections/

[4] Dublin Core Collection Description Application Profile
http://www.ukoln.ac.uk/metadata/dcmi/collection-application-profile/

[5] Term Proposal: [Collection] Accrual Status
http://www.ukoln.ac.uk/metadata/dcmi/collection-accrualStatus/

Title:	Scope of DCMI Namespaces
Creator:	Pete Johnston
Creator:	Andy Powell
Date Issued:	2004-02-17
Identifier:	http://www.ukoln.ac.uk/metadata/dcmi/dcmi-nmspc-scope/20040217/
Replaces:	Not applicable
Is Replaced By:	Not applicable
Latest Version:	http://www.ukoln.ac.uk/metadata/dcmi/dcmi-nmspc-scope/20040217/
Status of Document:	This is a DCMI Working Draft.
Description of Document:	This document raises the question of what URIs should be assigned to terms proposed by DCMI WGs in the course of their work on DCAPs, when the use of those terms is limited to the description of a particular class of resource. Currently, although such terms may be conforming in terms of the Dublin Core model, it may be that they are considered inappropriate as candidates for inclusion in one of the DCMI Namespaces. Since this is the only means of assigning a persistent URI owned by DCMI, this means that the WG is unable to assign a DCMI-owned URI for the term, and must seek a third-party that can provide such a URI.