Purpose and scope of DCMI Registry

2001-05-11

This document represents consensus reached by the Registry Working group on the requirements for a DCMI Registry. It is a brief outline which may be filled out in future after discussion with developers of the registry software, and after feedback from the Architecture WG and the Usage WG.

The purpose and scope of the DCMI Registry is:

• To assist DCMI to manage the evolution of DC vocabularies (to gather proposals for additional qualifiers, to manage process of approving qualifiers etc.)
• To provide authoritative definitions of recommended DC elements and qualifiers
• To identify DC recommended schemes
• To express these 'controlled metadata sets' and the relationships between them in machine readable schema language (see constraints) and in human readable mode.
• To provide a user friendly interface to the registered metadata ( search and browse facility, browseable element set lists, links to annotations and guidance on use of DC elements and qualifiers)
• To manage multilingual aspects of DC.

Essential Requirements:

The following requirements are recommended for implementation in Phase One:

• To enable DC elements and qualifiers to be annotated with a status such as 'proposed', 'recommended', 'deprecated' (these 'status' terms to be provided by the usage committee)
• Interfaces to enable search by element name, free text, and element set (DC elements, DC qualifiers etc.); and browse through lists of element sets by namespace (DC, DC qualifier, DC approved schemes etc.)

Other requirements:

Other requirements to be phased in, priority as indicated:

High priority:

• To link to authoritative translations of DC element and qualifier names and definitions.
• To register DC recommended domain specific 'application profiles' e.g. the DCMI Education group application profile

Priority to be established:

• To register authoritative mappings and crosswalks between DC and other metadata sets (e.g. ONIX, MARC etc.)
• To provide information on deployment (e.g. which services are using particular domain specific extensions)
• To provide links to best practice, guidelines for use (perhaps link into the user guide?)
• To enable implementors to submit proposed extensions and application profiles.

Constraints/Assumptions:

• We will use RDF schema language in the first instance as this is supported in the prototype software.
• We do not expect to solve the versioning problem within the early phases of the registry, otherwise we will never get started.

Dependencies:

In order to express DC elements and qualifiers in RDF there needs to be a decision on the namespace model for DC, in particular we will need to use a URL for each element and qualifier and scheme registered. For various reasons DC elements and qualifiers are now declared as separate namespaces, as are DC schemes and controlled lists. We need clarification on agreed practice regarding DC namespaces from the DC Architecture WG

In order to clarify process of assigning 'status' to DC qualifiers, recommended schemes, domain specific extensions we need advice from the Usage Committee

Development work on the DCMI Registry software is currently undertaken at OCLC. Work on multilingual aspects is being taken forward at ULIS, Tokyo.