innovation in metadata design, implementation & best practices
Topic: Attributes of DCMI Terms ("Usage Board profile")
Agenda frozen: 2004-10-02 07:25, Saturday
Maintainer: Tom Baker
Latest version: http://dublincore.org/usage/meetings/2004/10/ISSUES/profiles-usageboard/
Note: If any of the links below are broken, please refer to
the meeting packet
for copies of the key documents discussed at the meeting.
Discussion in Shanghai:
In Shanghai, I would like to briefly discuss the following
issue in order to define a process for moving this forward.
At a minimum, I would like to determine the extent to which
these issues should be decided in the Usage Board (as opposed
to DC-Architecture or the Directorate). We will not have
time in Shanghai to discuss any of these points in detail,
so UB members need not read the following as carefully as
they might have otherwise. At a most general level, I would
like to know how urgent we feel it is to clarify aspects of
Summary of the issue:
The issue of "DCMI terms describing DCMI terms" has been on
the back burner for a long time. We have already in effect
defined more than two dozen metadata terms describing various
attributes of metadata terms (Name, Label, Definition; types
of Status; etc...). However, we have merely documented
these terms in Web pages [1,2] -- never have we "declared"
the terms formally or assigned them URI references backed by
DCMI Namespace Policy. For the purpose of the RDF schemas,
we have mapped the handful of attributes most needed for
the schemas to existing terms (e.g., in the rdfs namespace
maintained by W3C).
We need both to clarify both the status of these terms (perhaps
taking the occasion to clean up some of the definitions)
and the policy by which the terms will be maintained (if
different from the existing DCMI Namespace Policy). We also
need to consider whether the terms should be assigned URIs
and documented in RDF schemas, as other DCMI metadata terms
According to my notes, we discussed this issue briefly in
Ithaca in 2003 and concluded that the following steps would
1. Define the set of properties and encoding schemes
for describing terms.
2. Understand how they relate to existing terms.
3. Ask DCMI Directorate for UB namespace.
4. Set up UB namespace and declare terms as necessary.
5. Define an application profile.
At present, the terms we use are defined in the introductions
of two documents - the consolidated document "DCMI Metadata
Terms"  and the historically complete "DCMI Metadata Terms:
a complete historical record" . I have attached a summary
of the terms and their definitions below.
I currently see the following issues:
1) We need to look carefully at the RDF schema binding to
determine which of the attributes used in  and  are
really needed in the RDF schemas. From my notes, here is
a draft mapping, with reference to a hypothetical namespace
"dcu:" to hold terms not yet formally declared:
Name: NOT USED
Namespace: rdfs:isDefinedBy rdf:resource="xxx"
Label: rdfs:label xml:lang="en-US"
Definition: rdfs:comment xml:lang="en-US"
Type of term: rdf:type rdf:resource="http://.../#element"
Status: dcu:status rdf:resource="http://.../#recommended"
Date issued: dcterms:issued
Comment: dc:description xml:lang="en-US"
See: rdfs:seeAlso rdf:resource="http://..."
References: dcterms:references rdf:resource="http://.../#W3CDTF"
Date modified: dcq:Modified
Decision: dcu:decision rdf:resource = "uri"
Version: dcu:version rdf:resource = "uri"
Replaces: NOT USED
Is Replaced By: NOT USED
Broader Than: NOT USED
Narrower Than: rdfs:subClassOf
Of course, we need to consider the possibility that not
all of the attributes of  and  would be needed in
the RDF schemas.
2) If we accept the mappings of some terms defined in  and 
to existing terms in namespaces maintained by W3C and to DCMI's
own Terms namespace, then at a minimum it would appear we would
need to declare the following:
dcu:status - Harry needs this for the DCMI Registry
3) In addition, it would appear we need the term
Harry needs this for the DCMI Registry, and Tom thinks this
is needed so that a translation of DCMI term definitions
into languages such as Japanese can reference the specific
Term Version used as the basis for the translation.
4) The term dcu:status has, in effect, a controlled vocabulary
These are currently defined in the document DCMI Usage Board
Process, and the URIs are anchors to specific points in that
document. We should consider whether it is a good idea to
continue this or whether we would want to declare a status
vocabulary, and if so, how their URIs should be formed.
5) The term "Type of Term" (currently mapped in the RDF
binding to rdf:type) also has, in effect, a controlled vocabulary
6) Work on the DCMI Abstract Model  and a formal model for
DCMI Application Profiles  suggests a need for several
other terms, along the lines of:
In September 2004, Pete posted a strawman set of terms at
7) DCMI's RDF schemas  have long asserted the existence of
URI references for terms based on the DCMI Namespace
http://purl.org/dc/terms/ -- even though, technically,
this should not have been possible without going through
UB process. These include:
We would need to formulate a policy for creating,
maintaining, and identifying such terms - bearing
in mind that the terms above are already "legacy"
(i.e., for all we know, there may be applications
in the world that would break if DCMI were to
drop or deprecate these terms).
8) Since the addition of
we have two new attributes for Vocabulary Terms:
Narrower Than - currently represented with rdfs:subClassOf
Usage Board Application Profile (draft)
Name  The unique token assigned to the term.
URI  The Uniform Resource Identifier used to uniquely
identify a term.
Namespace  The Uniform Resource Identifier of the namespace
within which the term is defined.
Label  The human-readable label assigned to
Definition  A statement that represents the concept
and essential nature of the term.
Type of term  The type of term, such as Element or Encoding
Scheme, as described in the DCMI Grammatical
Status  Status assigned to term by the DCMI Usage Board,
as described in the DCMI Usage Board Process.
Date issued  Date on which a term was first declared.
Comment  Additional information about the term
or its application.
See  A link to authoritative documentation.
References  A citation or URL of a resource referenced
in the Definition or Comment.
Refines  A reference to a term refined by an Element
Qualifies  A reference to a term qualified by an Encoding
Broader Than  A reference from a more general to a more specific
Narrower Than  A reference from a more specific to a more general
Date modified  Date on which a term declaration was subsequently
Decision  A link to the Usage Board decision describing
the creation or modification of a term
Version  An historical version of a term declaration.
Replaces  A reference to the immediately precedent
historical version of a term declaration.
Is Replaced By  An identifier for the historical version of a
term declaration by which this historical version
Strawman vocabulary drafted by Pete Johnston, July 2004
about a hypothetical http://example.org/dcap/
dc:title Schema for the DCAP vocabulary
dc:description This schema contains descriptions of the DCAP terms.
Terms are declared using RDF Vocabulary Description Language
dc:title The DCAP Vocabulary
dc:description The DCAP Vocabulary provides classes and properties
used to describe Dublin Core Application Profiles and Property Usages
and related resources.
Label: Schema Document
Label: Metadata Vocabulary
Label: Application Profile
Label: Property Usage
Label: Binding Schema
Label: Vocabulary or Profile Status
Label: Proposed Recommendation
Label: Vocabulary or Profile Status
Label: Optional (Recommended)
Label: Encoding Scheme
Label: Maximum Occurrences
Label: Is Member Of
Label: See also
Label: Is Expressed By
Label: Preferred XML Namespace Name
Label: Preferred XML Namespace Prefix