innovation in metadata design, implementation & best practices

DC Usage Board Decision 2 (DC-Government Proposal)

TO: Palle Aagaard, Co-chair, DC-Government Working Group
Andrew Wilson, Co-chair, DC-Government Working Group
FROM: DCMI Usage Board
DATE: 23 November 2001
RE: [UB Decision No. 2] Usage Board decisions on DC-Government proposal


The DCMI Usage Board reviewed the DC-Government proposal and application profile at a meeting in Tokyo on Monday, 22 October 2001. Members present were Tom Baker (chair), Diane Hillmann, Traugott Koch, Haruki Nagata, Andy Powell, Roland Schwaenzl, and Stuart Sutton (designated shepherd of the DC-Government proposal). This memo holds our official response to the DC-Government Working Group. It includes both comments on the DC-Government application profile as a whole and a response on proposals contained therein for new DCMI metadata terms.

As discussed below, the Board is asking the DC-Government Working Group to resubmit a number of its DCMI term proposals for re-consideration. In preparing such proposals, please refer to the appropriate sections of the Usage Board Administrative Process document at http://www.dublincore.org/usage/documents/process/ (especially sections 3.2 and 3.3).

As this was just the second proposal of an application profile to come before the Usage Board, we were obliged to clarify our processes and evaluation criteria in this regard. This proposal reached us just four days before the meeting, so we could not prepare as well as we would have liked. As discussed below, more explicit guidelines for evaluating application profile proposals are under development. We ask you to please bear with us as we work this out together.

1. Proposals for new DCMI metadata terms

      <td align="center">

Usage Board Decision

    <tr>
      <td>

acquired (for Date)

      <td>No recommendation issued</td>
    </tr>

    <tr>
      <td>

isBasedOn (for Relation)

      <td>Request to clarify and resubmit</td>
    </tr>

    <tr>
      <td>

isBasisFor (for Relation)

      <td>Request to clarify and resubmit</td>
    </tr>

    <tr>
      <td>

accessRights (for Rights)

      <td>Request to clarify and resubmit</td>
    </tr>

    <tr>
      <td>

accessMarking (for Rights)

      <td>Request to clarify and resubmit</td>
    </tr>

    <tr>
      <td>

copyright (for Rights)

      <td>Request to clarify and resubmit</td>
    </tr>

    <tr>
      <td>

previousAccessMarking (for Rights)

      <td>No recommendation issued</td>
    </tr>

    <tr>
      <td>

previousAccessMarkingChangeDate (for Rights)

      <td>No recommendation issued</td>
    </tr>

    <tr>
      <td>

category (for Subject)

      <td>No recommendation issued</td>
    </tr>

    <tr>
      <td>

keyword (for Subject)

      <td>Request to clarify and resubmit</td>
    </tr>

    <tr>
      <td>

aggregationLevel (for Type)

      <td>No recommendation issued</td>
    </tr>

    <tr>
      <td>

dossierType (for Type)

      <td>No recommendation issued</td>
    </tr>

    <tr>
      <td>

itemType (for Type)

      <td>No recommendation issued</td>
    </tr>
  </table>


  <p> </p>
</center>

As the Digest of Usage Board DCMI Namespace Decisions above indicates, the Board's decisions fall into two categories: (1) requests for clarification and resubmission, and (2) instances where no DCMI recommendation was issued.

1.1. Requests to clarify and resubmit

The profile submitted by the DC-Government Working Group followed the model provided by the draft profile of the DC-Libraries Working Group; the guidelines for application profiles under development will be roughly consistent with this. As presented, however, the proposal did not provide enough documentation to support a full review of metadata term proposals. For the following proposed terms, therefore, additional information (as outlined in Parts 3.2 and 3.3 of http://www.dublincore.org/usage/documents/process/) has been requested. In several instances, the Board has requested information beyond that required by the Process document.

1.1.1. isBasedOn and isBasisFor (for Relation)

The Board recognizes both "isBasedOn" and "isBasisFor" as valid refinements of "Relation". However, it finds the definition to be imprecise and inconsistent with the examples provided. The Board believes there is likelihood of confusion between the proposed pair of qualifiers and the existing pair "hasVersion" and "isVersionOf". The Board therefore asks the Working Group to provide a new and clearer definition of the "isBasedOn" set or perhaps to propose changes in the wording of "isVersionOf" and "hasVersion" to better convey the distinction that the Working Group intends. Such an exploration should engage the broader DCMI community -- perhaps through discussions on DC-General.

Finally, as noted by the Working Group in its best practice statement, the Board has some concerns over potential confusion of these proposed "Relation" qualifiers and the "Source" element. In its resubmission, the Working Group may wish to expand its best practice statement that these proposed "Relation" qualifiers are preferred over the use of "Source."

1.1.2. accessRights, accessMarking, and copyright (for Rights)

All three appear to be acceptable qualifiers of the "Rights" element. However, the information provided was insufficient to support a DCMI recommendation -- hence the request for clarification and resubmission with close attention to Parts 3.2 and 3.3 of http://dublincore.org/usage/documents/process/. The proposed DC-Libraries profile may contain a "copyright" qualifier for "Date", so DC-Government Working Group should perhaps liaise with this other Working Group on possible overlap. The resubmission should make very clear the appropriate sorts of literal values expected for "copyright."

1.1.3. keyword (for Subject)

The Board finds the proposal a bit confusing as presented. First, DDC is listed as an example but does not embody keywords as defined in the proposal. The Board felt that a new definition was needed. An additional and perhaps larger concern for the Board is the need for the Working Group to clarify the differences between an unqualified use of "Subject" and the proposed keyword refinement.

1.2. No DCMI Recommendation issued

Under Part 4.6 (Categories of recommendation) of http://dublincore.org/usage/documents/process/, the Board may issue a recommendation for a metadata term with one of three statuses: Cross-Domain, Domain-Specific, or Obsolete. There is no status for terms that are not recommended -- in essence, the Board either issues a recommendation or it does not. Where the Board does not issue a recommendation, an explanation of its decision is provided.

1.2.1. acquired (for Date)

The Board sees "acquired" as a valid refinement of the concept "Date". However, it sees this refinement as administrative in nature as opposed to discovery-oriented, and (as such) as outside the current scope of DCMI. The Board sees several alternatives available to the DC-Government Working Group: (1) to use a term for "acquired" from a different existing (non-DCMI) namespace; (2) to create a new (non-DCMI) namespace to be referenced in the DC-Government application profile; and/or (3) to liaise with the DCMI Administration Working Group as it addresses the issue of administrative metadata within the mission of DCMI.

1.2.3. previousAccessMarking (for Rights)

The Board sees "previousAccessMarking" as administrative in nature and not intended for resource discovery. As such, it is beyond the mission of DCMI. The Board suggests that the DC-Government Working Group liaise with the DCMI Administration Working Group, as above.

1.2.4. previousAccessMarkingChangeDate (for Rights)

While a case might be made that "previousAccessMarkingChangeDate" could function as a refinement of the "Date" element, the Board does not see it as a valid refinement of the "Rights" element.

1.2.5. category (for Subject)

The Board sees "category" as potentially a valid refinement of the "Subject" element. However, the Usage Board generally prefers to see such needs met by using encoding schemes, e.g., qualfiers for domain-specific vocabularies (see Appendix A below).

1.2.6. aggregationLevel, dossierType, and itemType (for Type)

The Board sees these as valid refinements to "Type". Given the examples provided, however, it appears to the Board that the need could be handled through using one or more domain-specific value encoding schemes.

2. The DC-Government Application Profile

As noted above, the Usage Board does not yet have formal guidelines for evaluating application profiles, but the DC-Government proposal has provided useful input towards their formulation. Since the Board assumes that the DC-Government Working Group will be submitting a revised application profile in the near future, it offers the following words as informal advice. The discussion begins with several general observations applicable to most of the element and qualifiers cited in the proposal and concludes with brief comments on each term individually. Attached in Appendix B are further discussion notes from our meeting in Tokyo.

2.1. Element and qualifier definitions

The formal guidelines for application profiles will detail the ways in which a term used from a vocabulary may be annotated with application-specific comments that specify how a term is used in a particular application or domain. At present, there is ongoing discussion about whether it is helpful or misleading to call these annotations "definitions"; in principle, an application profile should at any rate not re-"define" metadata terms in ways that violate the scope or intention of the terms as defined originally.

2.2. Element and qualifier comments

"Comments" are taken to be statements regarding the application of the element or qualifier as defined. Where an application profile does not narrow the original definition of an element or qualifier, there is no need for a domain-specific comment. Where domain-specific comments were provided in the DC-Government application profile in the absence of a domain-specific narrowing of the definition, the text would be best put into the Best Practices section of the table.

2.3. Permissible values

Many of the encoding schemes of use to DCMI-based applications will be registered with DCMI using the processes outlined in the draft Guidelines for Vocabulary and Encoding Scheme Qualifiers at http://www.dublincore.org/usage/documents/vocabulary-guidelines/. Practice communities registering an application profile with DCMI should promote schemes that are formally registered in order to promote consistent use of scheme names across DCMI-based applications.

2.4. Comments on elements and qualifiers cited in the profile

Proposed Qualifier

      <td align="center">

Comment

    <tr>
      <td valign="top">

Audience

      <td>The application profile puts forward an "Audience"
      element as a new DCMI element. There is no need to do so
      since the Board approved an "Audience" element for the
      http://purl.org/dc/terms/ namespace.</td>
    </tr>

    <tr>
      <td>

Contributor

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td>

Spatial

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td>

Temporal

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td>

Creator

      <td>Satisfactory (subject to the general comments)<br>
       While the comments suggest administrative goals well
      beyond discovery, it appears that any possible literals
      would not be inappropriate.</td>
    </tr>

    <tr>
      <td>

Date

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td>

Description

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td>

Format

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td valign="top">

Identifier

      <td>Satisfactory (subject to the general comments)<br>
       Note: ISBN and ISSN should be registered.</td>
    </tr>

    <tr>
      <td>

Language

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td valign="top">

Publisher

      <td>Publisher Satisfactory (subject to the general
      comments)<br>
       Note: Move the DC-Government definition to "Best
      Practice" and possibly change 'is' to 'may be'</td>
    </tr>

    <tr>
      <td valign="top">

Relation

      <td>Satisfactory (subject to the general comments)<br>
       Note: Remove reference to "aggregationLevel" in
      DC-Government definition since no recommendation has been
      issued.</td>
    </tr>

    <tr>
      <td valign="top">

isPartOf

      <td>Satisfactory (subject to the general comments)<br>
       Note: Remove reference to"aggregationLevel" since no
      recommendation issued.</td>
    </tr>

    <tr>
      <td>

Rights

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td>

Source

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td>

Subject

      <td>Satisfactory (subject to the general comments)</td>
    </tr>

    <tr>
      <td valign="top">

Title

      <td>Satisfactory (subject to the general comments)<br>
       Note: Liaise with DC-Libraries Working Group regarding
      the dropping of initial articles in titles since their
      proposal is conflicting with yours.</td>
    </tr>

    <tr>
      <td>

Type

      <td>Satisfactory (subject to the general comments)</td>
    </tr>
  </table>

</center>

APPENDIX A:
A DRAFT DECISION TREE FOR ASSESSING THE NEED FOR NEW METADATA TERMS

In addition to the criteria for evaluation of DCMI namespace proposals as set out in the Usage Board Administrative Processes document, the Usage Board is considering the following Action Chart (or decision tree) in assessing alternative ways for a practice community to meet a clearly defined metadata resource discovery need. The Chart sets out a series of conditions starting from the least disruptive condition for metadata interoperability and ending with the most disruptive. Thus, Condition 1 is to be preferred over Condition 2 and Condition 2 over Condition 3, etc. Only when the need cannot be solved through one of Conditions 1 through 3 should a community of practice propose a new domain-specific element and element qualifiers.

ACTION CHART (DECISION TREE)

> Condition 1: Can the community of practice's need be solved with a value qualifier (i.e., through a domain-specific vocabulary) for an existing DCMI element or element qualifier? > >
> If so, do that; else... >

>
> > Condition 2: Can the community of practice's need be solved through an application profile that references an element or element qualifier from an existing and recognized non-DCMI namespace? > >
> If so, do that; else ... >

>
> > Condition 3: Can the community of practice's need be solved with a new domain-specific qualifier for an existing DCMI element? > >
> If so, do that; else ... >

>
> > Condition 4: Create a new domain-specific DCMI element (and, if necessary, element and value qualifiers) to meet community of practice's need.


APPENDIX B:
SOME DRAFT THOUGHTS ON USAGE BOARD REVIEW OF APPLICATION PROFILES, BASED ON DISCUSSION IN TOKYO

Review of an application profile will be limited to two aspects:

  1. whether the application profile as a whole is "well-formed" according to a formal definition (yet to be finalized);
  2. whether any new terms put forward for inclusion under the DCMI namespace adhere to DCMI principles and criteria. Beyond these two matters, the Usage Board will generally defer to the expertise of the practice community. An application profile that meets the criteria of such a limited review will be formally "registered" with DCMI (not "recommended").

This process suggests that a community of practice wishing to put forward an application profile must distinguish between a new DCMI namespace proposal and a proposed application profile that uses those terms. Therefore, an application profile proposal that includes proposals for new DCMI terms will need to present these proposals separately. These could be presented at the same time so long as the supporting documentation for the two different types of proposals were complete.

As of 23 November, the latest draft Usage Board Process, which details the information needed for a DCMI term proposal, can be found at http://128.253.121.110/DC-UB/DC-UBprocess4.html. This document is currently undergoing extensive revision and expansion and will eventually include guidelines for application profiles -- a more detailed presentation of the ideas outlined here.

In general, application profiles may reference elements from established non-DCMI vocabularies. The Board encourages the reuse of established non-DCMI elements where this meets the needs of a practice community. However, the Usage Board considers recommendation of non-DCMI terms as beyond its jurisdiction per se. Rather, it will generally defer in such cases to the expertise of the practice community.

Element
Element Qualifier