DC-8 Breakout Session

Dublin Core Registry

Background

Metadata registries are one of the components of the infrastructure which will provide for metadata management on the Web. Registries are formal systems that can disclose authoritative information about the semantics and structure of
data elements. They provide definitions of metadata elements; optionally they give information on local extensions in use, manage multi-lingual versions of element names and definitions, give mappings to other metadata schemas, and provide examples of good practice. Registries are designed to meet the needs of software and humans to locate information about existing schema throughout the various processes of metadata creation, maintenance of repositories, and inter-working with other services.

A DC registry is proposed as a means to assist the better management of the DC element set(s), as well as helping implementors share information about their use of Dublin Core. The DC registry could be used by

People involved in building systems who want to create metadata according to defined standards, who want to discover whether appropriate metadata element sets already exist for their purpose, who wish to align their metadata sets with those that exist for other purposes, who wish to find translations of English versions of definitions and element names.
Software which wants to manipulate metadata and needs to know its structure and semantics, metadata creation tools which need to validate and present helpful user interface, conversion tools that need reference to mapping between elements

Other related activities in the wider world include a small number of large registries of metadata elements such as the Environmental Protection Agency's Environmental Data Registry . As regards international standards, ISO/IEC 11179 provides standards for the informational and organisational structure of metadata registries.

Session overview

The breakout sessions will build on Eric Miller's presentation of the prototype Open Metadata Registry by considering various aspects of the DCMI registry. The overall purpose of the breakout sessions is to clarify requirements for the registry, to explore policy issues, and relate these to the prototype Open Metadata Registry. Open issues can be identified to form the basis of a renewed charter for a Registry Working Group.

If you are planning to attend and would like a short five minute slot to present information on related activity please can you contact me (r.heery@ukoln.ac.uk).

Proposed topics for discussion are:

Purpose of registry

The registry might fulfil various purposes such as:

Managing the DC namespace
Providing an authoritative source of information regarding DC for humans and software
Facilitating take up of DC
Managing change and evolution of the DC schema(s)
Providing authoratative mappings between DC schema and other metadata element sets

Scope of registry

Will the scope extend outside the recommended DC element sets to include DC managed controlled vocabularies (e.g. recommended values for DC Type)? Should a registry "gather" vocabularies (into a central repository) or function like a search engine over distributed vocabularies?
Will 'application profiles' be included? What would be the impact?
Will mappings be included?
How much functionality is required for seraching and browsing?

Policy and process

What will be the process for approval of metadata elements? Tom Baker has presented a strawman proposal for the basis of this discussion looking at the approval levels of DC elements and qualifiers, see text in section below under Reading Materials.
Can the registry assist in liaison with other metadata activities by linking to their registries, or registering their element sets?

The Registry WG will need to liaise as appropriate with registry activity outside the DCMI. In particular with

ISO 11179 community
W3C RDF Schema Group
W3C XML Schema Group

Technical solution

How do our discussions relate to the way data has been structured in the Open Metadata Registry?
What are the open issues as regards the prototype?

DC Registry working group charter

The DC working group will act as a focus for activity regarding metadata registries within the DCMI. Have we identified the basis of a charter? How will this WG relate to the Interest Group for Dublin Core in Multiple Languages?

Reading materials

1. Registries Workshop held in Bath, March 2000 for notes see http://www.mailbase.ac.uk/lists/dc-registry/2000-04/0000.html

2. The DC reference descriptions in multiple languages is at
http://www.DL.ulis.ac.jp/DCML/,
The DC Multiple Language Interest Group page is at
http://purl.org/DC/groups/languages.htm#multilingual

3. Strawman proposal from Tom Baker
A tiered model for the status of Dublin Core tokens
Thomas Baker Version: 11 August 2000

This short paper is intended as a strawman for discussion on the levels of approval status for DCMI metadata tokens. The term "tokens" is being used here as a catch-all term for metadata words such as elements and qualifiers (see [1]). The context of these tokens is a registry based on the Resource Description Format, which supports the modeling
of assertions. The default assertion considered here involves the DCMI Usage Committee saying something about a token's status. The DCMI Registry Working Group will need to consider whether working groups of
the DCMI (such as DC-Education or DC-Government) should likewise make assertions about the status of tokens. Whether the tokens in question must be in a namespace maintained by DCMI is also a question beyond the
scope of this brief paper.

Local Tokens

Any project or implementation may assert that a local token is based on or related to a Dublin Core token and make this asserted relation known by publishing the token in an RDF schema and communicating the URI of the token to DCMI. DCMI will acknowledge the assertion by publishing this link in its registry. Most links will never be reviewed by DCMI, so such a back-link will not imply DCMI endorsement of any kind.

Registration provides a public record of tokens in use by local projects, encourages the reuse of tokens by others, and promotes an ongoing process of standardisation and harmonisation based on usage.

As a feature of the RDF schema format, each registered element and token will have a URI plus a name and definition in any language (not necessarily English).

Proposed Tokens

Any implementor of a Dublin-Core-based schema may put forward a token for review by the DCMI Usage Committee by providing it with a machine-readable name along with a label and definition in clear and understandable English, putting it into an RDF schema published on the Web, and communicating the URI of the token to DCMI. A Local Token put forward for recognition as a Conforming Token is called a Proposed Token.

A proposal is considered to be "well-formed" if it describes the token using the expected style and template, possibly with a few well-chosen examples. Proposals for qualifiers must specify the element intended to be qualified. Proposed tokens continue to reside in the namespace of the proposer.

Conforming Tokens

The DCMI Usage Committee will evaluate Proposed Tokens against the grammatical principles of Dublin Core. Tokens judged by the Usage Committee to substantially meet these principles will be assigned a token in a DCMI-maintained namespace. The Usage Committee will specify whether a token is an element or a qualifier (element refinement or value encoding).

Non-Conforming Tokens

Local Tokens that have been reviewed and found _not_ to be in conformance with principles may be explicitly flagged as
Non-Conforming if the Usage Committee is so inclined. In the case of such a verdict, a summary of Usage Committee comments may be appropriate.

Recommended Tokens

Any Proposed Token may be promoted to the status of Recommended Token if it has been shown to be of general use and broad interest across disciplines. The DCMI Usage Committee may want to recommend that multiple Conforming Tokens of similar scope be combined into one single Recommended Token.

Obsolete Tokens

Over time, the meaning of a token may shift through usage. In such cases, the DCMI Usage Committee should consider revising the definition of a token to match the changed usage. Alternatively, tokens may become superseded, deprecated, or obsolete. Such tokens will remain the Dublin Core registry as Obsolete Tokens as they may be needed to interpret legacy metadata.

[1] http://www.gmd.de/People/Thomas.Baker/DC-Grammar.html

Rachel Heery - 2000-09-27