I would like to offer the following strawman for discussion on this
list and at DC-8 in Ottawa.
A TIERED MODEL FOR THE STATUS OF DUBLIN CORE TOKENS
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 ). 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.
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
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).
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.
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).
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
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.
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
Dr. Thomas Baker [log in to unmask]
Schloss Birlinghoven +49-2241-14-2352
53754 Sankt Augustin, Germany fax +49-2241-14-2619