innovation in metadata design, implementation & best practices

DCMI Usage Board - Administrative Process

Title:

Dublin Core Usage Board Administrative Processes

Creator:
Stuart A. Sutton
Date Issued:
2001-12-22
Identifier:
Replaces:
Is Replaced By:
Latest version:
Description of document:

This document describes the rules and regulations of the DCMI Usage Board.


 

Dublin Core Usage Board Administrative Processes


INDEX
Part 1: Usage Board: Overview, Meetings, Documentation - 1. Usage Board Membership - 2. Meetings - 3. Categories of Usage Board Decisions - 4. Communication and Documentation Part 2: Proposals for Recommendations and Registrations: Form and Process - 5. Proposals for Recommendations - 6. Proposals for Registration of Encoding Schemes and Vocabularies - 7. Proposals for Registration of Application Profiles [Under development] Part 3: Revision of UB Administrative Processes - 8. Process for Revision of UB Administrative Processes [Under development]


Usage Board: Overview, Meetings, Documentation

  1. Usage Board Membership [top]
  • 1.1. The UB will consist of at least seven and no more than eleven people (nine is ideal) appointed by the DCMI Directorate.
  • 1.2. Usage Board member terms shall be for two years, renewable once. Initial appointments will be made so as to stagger terms.
  • 1.3. Members should be selected based on the following criteria:
    • 1.3.1. Knowledgeable concerning the development history and purpose of the DC element set and its relationship to the metadata world at large;
    • 1.3.2. Related to a metadata community relevant to DCMI;
    • 1.3.3. Willing and able to commit time and energy to the functions of the UB;
    • 1.3.4. Able to communicate verbally and in writing in English well enough to prepare documents and discuss complex issues in a group setting;
    • 1.3.5. Geographic and domain distribution of members is relevant but will not override other criteria.
  • 1.4. The UB Chair will be appointed from one of the membership by the DCMI Directorate. The term of the chair shall be for two years, renewable once.
  • 1.5. For internal communication the UB uses the closed mailing list dc-usage@jiscmail.ac.uk. The messages are archived and publicly available at http://www.jiscmail.ac.uk/lists/dc-usage.html.
  1. Meetings [top]
  • 2.1. Scheduling
    • 2.1.1. Meetings should be at least twice a year.
    • 2.1.1.1. One meeting should be scheduled during the annual DC general workshop/conference.
    • 2.1.1.2. The second should be scheduled at a different time of the year, preferably close to other conferences, so as to make attendance convenient for as many members as possible.
    • 2.1.1.3. Scheduling should be done far enough in advance so that as many members as possible may be present.
  • 2.2. Funding for meetings should be supported as much as possible by DCMI.
  • 2.3. Attendance by members
    • 2.3.1. Members must attend at least one meeting in a given year to maintain membership in good standing.
    • 2.3.2. Members who miss two meetings in succession may be replaced by the DC Directorate.
  • 2.4. Attendance by others
    • 2.4.1. Attendance at UB meetings by other than the UB is by invitation.
    • 2.4.1.1. Interested attendees should request an invitation via the UB Chair or the Managing Director.
    • 2.4.2. Participation in discussion of proposals by any interested parties is encouraged.
  • 2.5. Agenda preparation and distribution
    • 2.5.1. The UB chair is responsible for preparing the meeting agendas and assigning shepherds to proposals.
    • 2.5.2. Agenda items shall include the name and email address of the UB member responsible for shepherding the proposal through the UB process.
    • 2.5.3. Agendas shall be available on the UB page of the DCMI website.
  • 2.6. Minutes
    • 2.6.1. Minutes of discussion points and decisions shall be drafted based on notes taken by relevant shepherds and the chair.
    • 2.6.2. Minutes shall be available on the DC UB website.
    • Categories of Usage Board Decisions[top]
  • 3.1. Recommended
    • 3.1.1. CROSS-DOMAIN. Terms of general use and broad interest across domains.
    • 3.1.2. DOMAIN-SPECIFIC. Terms of interest to a limited domain or set of domains.
    • 3.1.3. OBSOLETE. For terms that have been superseded, deprecated, or rendered obsolete. Such terms will remain in the registry for use in interpreting legacy metadata.
  • 3.2. Registered
    • 3.2.1. Used for schemes, application profiles, and translations for which the DCMI provides information but not necessarily specific recommendation.
  1. Communication and Documentation[top]
  • 4.1. Communication Responsibility Table

What Where Who Comment
Proposal draft posted WG list, DC-General WG Chair
Proposal added to DC-UB agenda DC-UB Website, DC-UB list DC-UB Chair Should this also be announced to WG?
Proposal announced for public comment DC-General DCMI Managing Director
Usage Board Outcome DC-General DCMI Managing Director
Scheme submission DC-UB List [Web Team Submission Tool]
Scheme registration DC-UB List [Web Team Submission Tool] Shepherd may announce to WG list
Digest of scheme registrations DC-General DC-UB chair Possibly instead by Makx?
  • 4.2. Documentation
    • 4.2.1. Important documents like UB membership, meeting agendas, meeting minutes, proposals to the UB, voting or decision documents and results (if not part of minutes) and similar are archived as separate documents in an area of the DCMI web site devoted to the UB.
    • 4.2.2. Structure of the UB website is similar to a working group page with an issues, forums and resources section. If necessary, an UB internal section can be password protected.
    • 4.2.3. Historic documents relevant to the UB work, like voting proposals and results from the first DC Qualifier voting will be archived at the same page.
    • 4.2.4. Results of the UB work which take the form of official DCMI documents (working drafts, proposed recommendations and recommendations) are made available and archived at: http://dublincore.org/documents/ as all the other similar documents.
    • 4.2.5. The UB page maintains links to all XML/RDF schemas of UB-maintained namespaces held on the DCMI Web site.

Proposals for Recommendations and Registrations: Form and Process

  1. Proposals for Recommendations[top]
  • 5.1. Sources of proposals
    • 5.1.1. DCMI working groups
    • 5.1.1.1. Existing working groups
    • 5.1.1.2. Working groups established for the purpose of developing proposals
    • 5.1.2. Metadata implementors
    • 5.1.3. UB itself
  • 5.2. Proposals should include:
    • 5.2.1. A "name" for use in encodings
    • 5.2.2. A "label" and "definition" in clear Englise
    • 5.2.3. An example or two if appropriate, making clear what type of literal values are expected
    • 5.2.4. Best practice recommendations
    • 5.2.5. Whether the proposed term is an Element, Controlled Vocabulary of general application, or Element Refinement (typology to be taken from the reference grammar)
    • 5.2.6. For qualifiers: the element being qualified
    • 5.2.7. A pointer to a description, in standard form (to be specified) of the working group or organization putting forward the proposal: its scope, aims, a brief history, current status, and a pointer to archives
    • 5.2.8. A discussion of possible overlap with existing terms
    • 5.2.9. A summary history of the post-proposal discussion, written by the shepherd, shall be included (if there was one)
    • 5.2.10. An analysis of the impact on existing Dublin Core applications
    • 5.2.11. An analysis of interoperability with other metadata schemes
    • 5.2.12. A justification of the need for the proposed element or qualifier in a cross-domain application
    • 5.2.13. Links to further information on the web

Proposal Requirements Tables

        <tbody>
          <tr>
            <td nowrap valign="top">Element
            Namespace</td>

            <td>Designation of the DCMI namespace for the
            proposed element</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Name</td>

            <td>The unique token assigned to the proposed
            element</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Label</td>

            <td>The human-readable label assigned to the
            proposed element</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element
            Status</td>

            <td>Designation of whether the status of the
            proposed element is Domain-Specific or
            Cross-Domain</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element
            Definition</td>

            <td>The definition of the element</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element
            Comment</td>

            <td>A remark concerning the application of the
            proposed element</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Encoding
            Scheme(s)</td>

            <td>Value qualifiers that aid in the interpretation
            of the proposed element values (formats) or that
            control the range of legitimate element values
            (controlled vocabularies)</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element
            Examples</td>

            <td>Example "use statements" with assigned
            literals</td>
          </tr>
        </tbody>
      </table>

    </center>  

New DCMI Namespace Element Qualifier

      <table border="1" cellpadding="3" width="85%">
        <tbody>
          <tr>
            <td>
            </td>
          </tr>

          <tr>
            <td nowrap valign="top">Qualified Element
            Namespace</td>

            <td>Designation of the DCMI namespace for the
            element being qualified</td>
          </tr>

          <tr>
            <td nowrap valign="top">Qualified Element
            Name</td>

            <td>The unique token assigned to the element being
            qualified</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Qualifier
            Namespace</td>

            <td>Designation of the DCMI namespace for the
            proposed element qualifier</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Qualifier
            Name</td>

            <td>The unique token assigned to the element
            qualifier</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Qualifier
            Label</td>

            <td>The human-readable label assigned to the
            element qualifier</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Qualifier
            Status</td>

            <td>Designation of whether the status of the
            proposed element qualifier is Domain-Specific or
            Cross-Domain</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Qualifier
            Definition</td>

            <td>The definition of the element qualifier</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Qualifier
            Comment</td>

            <td>A remark concerning the application of the
            element qualifier</td>
          </tr>

          <tr>
            <td>Element Qualifier Encoding Scheme(s)</td>

            <td>Value qualifiers that aid in the interpretation
            of the proposed element qualifier values (formats)
            or that control the range of legitimate element
            qualifier values (controlled vocabularies)</td>
          </tr>

          <tr>
            <td nowrap valign="top">Element Qualifier
            Examples</td>

            <td>Example "use statements" with accompanying
            literals</td>
          </tr>
        </tbody>
      </table>

    </center>  
  • 5.3. Supporting Materials and Processes for New Element and Element Qualifier Proposals:
    • 5.3.1. For each proposed element and element qualifier, include supporting information required under Part 5.2 of the UB Administrative Processes. Clearly label the discussion of each Sub-Part.
    • 5.3.2. Review Part 5.4. " Criteria for Evaluation of Proposals" of the UB Administrative Processes and provide additional supporting materials where appropriate (e.g., if there are "alternative ways of implementing the term" (5.4.3.3.)), include information regarding the alternatives).
    • 5.3.3. Encoding schemes should be registered with DCMI through its online registration system.
  • 5.4. Criteria for Evaluation of Proposals
    • 5.4.1. Clarity
    • 5.4.1.1. Can the term be clearly defined?
    • 5.4.1.2. Can the semantics of the proposed element or element qualifier be expressed precisely, unambiguously, and briefly?
    • 5.4.2. Practicality
    • 5.4.2.1. Is the term practical?
    • 5.4.2.2. How difficult would it be for people creating metadata to comprehend the semantics of the proposed element or element qualifier and to apply it reasonably in the description of resources?
    • 5.4.3. Placement
    • 5.4.3.1. Does the term refine an existing element?
    • 5.4.3.2. If the proposed term is an element, can it reasonably be handled as effectively as an element or value qualifier for an existing element?
    • 5.4.3.3. Are there alternative ways of implementing the term? Within the conceptual framework of the Dublin Core Element Set (i.e., element/element qualifiers and value/value qualifiers), are there alternative ways to achieve the ends sought?
    • 5.4.4. Needs
    • 5.4.4.1. Is there a clear requirement in existing implementations for the term in support of resource discovery?
    • 5.4.4.2. Is there a demonstrated need for the proposed element, element qualifier, or value qualifier?
    • 5.4.4.3. Are there existing implementations or controlled vocabularies, etc., supporting the term?
    • 5.4.5. Fit with other elements/qualifiers
    • 5.4.5.1. Follows existing principles of qualification
    • 5.4.5.2. Is well-formed
    • 5.4.5.3. Does not conflict with or create ambiguity with regard to existing elements, or qualifiers
    • 5.4.5.4. Does not create problems for existing legacy implementations if those implementations have followed recommended practice
  • 5.5. Action Chart

New DCMI Namespace Element

    <tbody>
      <tr>
        <td valign="top" nowrap>Condition 1:</td>

        <td>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?</td>

        <td valign="top" nowrap>If so, do that;
        else …</td>
      </tr>

      <tr>
        <td valign="top" nowrap>Condition 2:</td>

        <td>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?</td>

        <td valign="top" nowrap>If so, do that;
        else …</td>
      </tr>

      <tr>
        <td valign="top" nowrap>Condition 3:</td>

        <td>Can the community of practice's need be solved
        with a new domain-specific qualifier for an
        existing DCMI element?</td>

        <td valign="top" nowrap>If so, do that;
        else …</td>
      </tr>

      <tr>
        <td valign="top" nowrap>Condition 4:</td>

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

        <td> </td>
      </tr>
    </tbody>
  </table>

</center>  
  • 5.6. Process for Moving Proposals

    • 5.6.1. Pre-announcement process
    • 5.6.1.1. Proposal is received by DCMI Managing Director or UB Chair.
    • 5.6.1.2. Proposal is given preliminary review for completeness by DCMI Managing Director and UB Chair.
    • 5.6.1.3. If complete and no revisions needed, proposal is circulated to UB members and announced for public comment. by the Managing Director.
    • 5.6.1.4. If incomplete or revisions needed, proposal is returned to originator, with request for revision or additional information.
    • 5.6.2. Announcements
    • 5.6.2.1. Announcements of comment period for proposals to be discussed by the UB shall be made on the DC-general list and other relevant lists.
    • 5.6.2.2. Announcements of proposals shall be made by the DCMI Managing Director.
    • 5.6.2.3. Announcements will include:
      • 5.6.2.3.1. Links to relevant information to be considered with the proposal
      • 5.6.2.3.2. Relevant deadlines for comments
      • 5.6.2.3.3. Addresses for comment submission
      • 5.6.2.3.4. Information about UB meeting at which the proposal will be discussed, including how to request an invitation to participate
      • 5.6.2.3.5. Name and contact information for the assigned shepherd
    • 5.6.3. Shepherds
    • 5.6.3.1. Each proposal shall be assigned a shepherd by the UB chair from among the UB membership.
    • 5.6.3.2. Shepherds should have knowledge of the proposal issues or be connected to the WG originating the proposal.
    • 5.6.3.3. Responsibilities
      • 5.6.3.3.1. Monitor discussion on relevant lists (shepherds should be members of the relevant DC WG list during the time of consideration of a proposal).
      • 5.6.3.3.2. Summarize the comment period discussion and points of contention of the proposal for the UB, either verbally at the meeting or in writing prior to the meeting (preferred).
      • 5.6.3.3.3. Serve as liaison to the relevant WG or community during the time the proposal is under discussion and after a decision has been made.
      • 5.6.3.3.4. Recommend to the UB any further action after a decision has been made on the proposal.
      • 5.6.3.3.5. Prepare registration information for the DCMI Web Team.
      • 5.6.3.3.6. Prepare draft of UB official decision on the proposal for review and approval by the UB.
    • 5.6.4. Comment period
    • 5.6.4.1. Comment period on proposals should be managed on the DC-General list.
    • 5.6.4.2. Comment periods should be at least one month.
    • 5.6.4.3. Public discussions of UB related issues during public comment periods should take place on DC-GENERAL or other working group mailing lists as specified in the announcement.
    • 5.6.5. Voting
    • 5.6.5.1. Voting shall be limited to scheduled meetings and conference calls.
    • 5.6.5.2. Voting shall be limited to UB members present at the meeting or conference call and able to participate in the discussion.
    • 5.6.5.3. UB members who cannot be present may present their arguments for or against a proposal in writing prior to a meeting (this shall not constitute a vote).
    • 5.6.5.4. UB members who cannot be present may explore other options with the chair, if they cannot be present for an important vote. In all cases, a vote may not be cast by a member who is not present, either actually or virtually, for the relevant discussion.
    • 5.6.5.5. Consensus is achieved if fewer than two UB members object to a proposal.
  • 5.7. Registration of UB Decisions on Proposals

    • 5.7.1. A document explaining the UB decision regarding a proposal will be written in a timely fashion by the shepherd and approved by the UB.
    • 5.7.1.1. The decision will include brief statements of recommendations being issued and detailed explanations of UB decisions not to issue recommendations.
    • 5.7.1.2. UB decisions will be in a form determined by the UB and numbered consecutively for the purpose of citation.
    • 5.7.1.3. The DCMI Web Team will publish UB decisions in the Documents section of the DCMI Web site in a category named DCMI Usage Board Decisions.
    • 5.7.2. Recommended terms will be registered by the shepherd who was responsible for moving the proposal through the UB process.
    • 5.7.2.1. The shepherd will complete a web form transferring the relevant information to the DCMI Web Team for inclusion into the Registry.
    • 5.7.2.2. The DCMI Web Team will report to the UB list when registration has been completed.
    1. Proposals for Registration of Encoding Schemes and Vocabularies [top]
  • 6.1 Submissions of new encoding schemes and vocabularies will be received on the DC-UB list via a web form

  • 6.2. DC UB members will "claim" responsibility to shepherd submissions based on:

    • 6.2.1. Their knowledge of a particular scheme or vocabulary
    • 6.2.2. Their knowledge of the language used in the scheme or vocabulary
    • 6.2.3. Their interest or knowledge of a particular subject or topical area covered by the scheme or vocabulary
    • 6.2.4. The time they have available for such tasks
  • 6.3. Submissions unclaimed after one week will be assigned to a DC-UB member by the chair.

  • 6.4. The DC-UB chair will not shepherd individual submissions, but will keep track of submissions and ensure that all are resolved in some manner.

  • 6.5. The shepherd will be responsible for verifying the submitted information:

    • 6.5.1. Name of the scheme or vocabulary
    • 6.5.2. Availability and maintenance status
    • 6.5.3. Appropriateness of the maintenance agency
    • 6.5.4. Uniqueness and appropriateness of the proposed token
    • 6.5.5. Possible use with elements not specified in the proposal
  • 6.6. If necessary, the shepherd will initiate contact with the maintenance agency in the case of questions or concerns about the status of the scheme, the proposed token, or to clarify the submission.

  • 6.7. The shepherd will edit the submission and complete the registration process by submitting the information to the DCMI Web Team.

  • 6.8. The DCMI Web Team will report to the UB list when registration has been completed.

  • 6.9. The DC-UB chair will prepare a monthly report of all new schemes.

    1. Proposals for Registration of Application Profiles [top]
  • [Under development]



  • rev. sas 12/22/01

    Decision Tree for Proposing Qualifiers