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. Following the DCMI Namespace Policy, the URIref given to an individual term is determined by the vocabulary, the DCMI Namespace, to which the term is assigned. The URIref 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 URIrefs to assign to these properties.

Options Available

1. No resource-type-specific terms permitted in AP: If the only terms permitted in a DCAP are those from metadata vocabularies applicable to generic resource types, then the descriptive capacity of the AP is potentially limited. And in the case of the DC CD WG, the WG was chartered specifically to produce a DCAP for a single type of resource.
2. 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) URIrefs to refer to the property defined by the WG. The assignment of URIrefs to its properties is critical to the goals of the WG.
3. Third-party-owned URI assigned: If the WG itself can not assign persistent URIrefs, and DCMI UB can not assign the term to a DCMI Namespace, then the WG must seek a third-party authority 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.
4. Inclusion of property in current "dcterms" DCMI Namespace: It is widely understood that all properties in the dcterms vocabulary are applicable to a wide range of resource types, and introducing resource-type-specific properties would be potentially confusing to users. It may also open up the prospect of many proposals for other resource-type-specific properties, and would almost certainly require new policy for the Usage Board.
5. Inclusion of property in a new DCMI Namespace: If the use of the dcterms vocabulary is not appropriate, a separate vocabulary (DCMI Namespace) might be assigned for each resource-type-specific set of properties, with terms assigned URIrefs such as http://purl.org/dc/collection/terms/accrualStatus. Such a move would require the establishment of policies and procedures for the maintainance of those vocabularies by the Usage Board.

Issues Arising

If Option 3

What are implications for DCMI WGs? Is there a risk of WGs "stretching" the semantics of existing terms because it is diffcult to find an authority who can provide persistent URIrefs for new terms? Would different WGs find different authorities to provide URIrefs? How would users perceive the use of a range of URIs owned by different authorities?

If Option 4 or Option 5

All elements/element refinements issued by DCMI to date have been applicable to a broad range of resource types, and issuing resource-type-specific properties represents a shift in the scope of DCMI activity.

How would such a shift be perceived by users? Does it introduce a potential overlap with the activity of non-DCMI bodies creating metadata vocabularies? What would be the educational/documentational challenges?

What are the technical implications? Use of rdfs:domain?

Are there any limits to the resource-types for which DCMI might create resource-type-specific properties?

If Option 5

If new vocabularies/namespaces are created, how would these vocabularies be managed? By Usage Board in the same way as the current DCMI Namespaces?

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/