innovation in metadata design, implementation & best practices

DCMI Usage Board - Process

Title:

Dublin Core Usage Board Administrative Processes

Creator:
Diane I. Hillmann, dih1@cornell.edu
Date Issued:
2001-11-05
Identifier:
Replaces:
Is Replaced By:
Latest version:
Description of document:

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


## DRAFT--Dublin Core Usage Board Process Changes made during DC UB meeting in Dublin, OH, May 21-22, 2001 Changes (and fixes to errors) from WORD draft circulated 5/29 noted in green. Changes after DC-UB meetings in Tokyo in purple. 1. Usage Board Membership - 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 2. Meetings - 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 - - 2.2.1. Funding for meetings should be supported as much as possible by DCMI - 2.2.2. [Removed at Tom's suggestion] - 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 3. Proposals - 3.1. Sources of proposals - - 3.1.1. DCMI working groups - - 3.1.1.1. Existing working groups - 3.1.1.2. Working groups established for the purpose of developing proposals - 3.1.2. Metadata implementors - 3.1.3. UB itself - 3.2. Proposals should include: - - 3.2.1. A "name" for use in encodings - 3.2.2. A "label" and "definition" in clear English - 3.2.3. An example or two if appropriate, making clear what type of literal values are expected - 3.2.4. Best practice recommendations - 3.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) - 3.2.6. For qualifiers: the element being qualified - 3.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 - 3.2.8. A discussion of possible overlap with existing terms - 3.2.9. A summary history of the post-proposal discussion, written by the shepherd, shall be included (if there was one) - 3.2.10. An analysis of the impact on existing Dublin Core applications - 3.2.11. An analysis of interoperability with other metadata schemes - 3.2.12. A justification of the need for the proposed element or qualifier in a cross-domain application - 3.2.13. Links to further information on the web - 3.3. Criteria for Evaluation of Proposals - 3.3.1. Clarity - 3.3.1.1. Can the term be clearly defined? - 3.3.1.2. Can the semantics of the proposed element or element qualifier be expressed precisely, unambiguously, and briefly? - 3.3.2. Practicality - 3.3.2.1. Is the term practical? - 3.3.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? - 3.3.3. Placement - 3.3.3.1. Does the term refine an existing element? - 3.3.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? - 3.3.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? - 3.3.4. Needs - 3.3.4.1. Is there a clear requirement in existing implementations for the term in support of resource discovery? - 3.3.4.2. Is there a demonstrated need for the proposed element, element qualifier, or value qualifier? - 3.3.4.3. Are there existing implementations or controlled vocabularies, etc., supporting the term? - 3.3.5. Fit with other elements/qualifiers - 3.3.5.1. Follows existing principles of qualification - 3.3.5.2. Is well-formed - 3.3.5.3. Does not conflict with or create ambiguity with regard to existing elements, or qualifiers - 3.3.5.4. Does not create problems for existing legacy implementations if those implementations have followed recommended practice - 3.4. Distribution - - 3.4.1. Proposals will be posted on a WG website or the UB website and linked to the UB agenda ### Proposal Requirements Table
Elements Qualifiers Controlled Vocabulary Terms Encoding Schemes

Element qualified Vocabulary list name
Name name Term Name
Label Label
Label
Definition Definition Definition URL for online access
Source of proposal Source of proposal Source of proposal Maintenance body
Justification Justification Justification
Discussion of overlap with other terms Discussion of overlap with other terms Discussion of overlap with other terms
Impact analysis Impact analysis Impact analysis
Interoperability analysis Interoperability analysis Interoperability analysis
Examples and best practice recommendations Examples and best practice recommendations Examples and best practice recommendations
  1. Process for moving proposals
  1. Follow-up to meetings

6. Communication

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?
  1. Documentation

rev. dih 11/5/01