innovation in metadata design, implementation & best practices

Topic: Attributes of DCMI Terms ("Usage Board profile")
Agenda frozen: 2004-10-02 07:25, Saturday
Archived: 2004-11-10
Maintainer: Tom Baker
Latest version:
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.

Shepherd: Tom

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
this problem.

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
already are.

According to my notes, we discussed this issue briefly in
Ithaca in 2003 and concluded that the following steps would
be involved:

    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" [1] and the historically complete "DCMI Metadata Terms:
a complete historical record" [2]. 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 [1] and [2] 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"
   Refines: rdfs:subPropertyOf
   Qualifies: dcu:qualifies
   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 [1] and [2] would be needed in
   the RDF schemas.

2) If we accept the mappings of some terms defined in [1] and [2]
   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 
   of values:

   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
   of values:

6) Work on the DCMI Abstract Model [3] and a formal model for
   DCMI Application Profiles [4] 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 [5] have long asserted the existence of
   URI references for terms based on the DCMI Namespace -- 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:

        Broader Than
        Narrower Than - currently represented with rdfs:subClassOf

Usage Board Application Profile (draft)

   Name [1] The unique token assigned to the term.
   URI [1] The Uniform Resource Identifier used to uniquely
                      identify a term.
   Namespace [2] The Uniform Resource Identifier of the namespace 
                      within which the term is defined.
   Label [1] The human-readable label assigned to
                      the term.
   Definition [1] A statement that represents the concept
                      and essential nature of the term.
   Type of term [1] The type of term, such as Element or Encoding
                      Scheme, as described in the DCMI Grammatical
   Status [1] Status assigned to term by the DCMI Usage Board, 
                      as described in the DCMI Usage Board Process.
   Date issued [1] Date on which a term was first declared.

When appropriate
   Comment [1] Additional information about the term
                      or its application.
   See [1] A link to authoritative documentation.
   References [1] A citation or URL of a resource referenced 
                      in the Definition or Comment.
   Refines [1] A reference to a term refined by an Element 
   Qualifies [1] A reference to a term qualified by an Encoding
   Broader Than [1] A reference from a more general to a more specific
                      Vocabulary Term
   Narrower Than [1] A reference from a more specific to a more general
                      Vocabulary Term

   Date modified [2] Date on which a term declaration was subsequently 
   Decision [2] A link to the Usage Board decision describing
                      the creation or modification of a term
   Version [2] An historical version of a term declaration.
   Replaces [2] A reference to the immediately precedent
                      historical version of a term declaration.
   Is Replaced By [2] An identifier for the historical version of a 
                      term declaration by which this historical version
                      is superseded.



Strawman vocabulary drafted by Pete Johnston, July 2004
   about a hypothetical

  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 
                          (RDF Schema).
  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: Document

  Label: Schema Document

  Label: Agency

  Label: Metadata Vocabulary

  Label: Application Profile

  Label: Property Usage

  Label: Binding Schema

  Label: Vocabulary or Profile Status
  Label: Private
  Label: Draft

  Label: Proposed Recommendation

  Label: Recommendation

  Label: Vocabulary or Profile Status

  Label: Private

  Label: Unstable

  Label: Testing

  Label: Stable

  Label: Deprecated

  Label: Obligation

  Label: Reserved

  Label: Optional

  Label: Optional (Recommended)

  Label: Mandatory

  Label: Uses

  Label: Encoding Scheme

  Label: Obligation

  Label: Condition

  Label: Maximum Occurrences

  Label: Is Member Of

  Label: See also

  Label: Version

  Label: Status

  Label: Is Expressed By

  Label: Preferred XML Namespace Name

  Label: Preferred XML Namespace Prefix