DRAFT--Dublin Core Usage Board Process

NOTE: Comments/questions are inserted with the relevant section in red, [bracketed] including the initials of the commentor. Changes/additions to the document are in green, italicized for black and white printouts.

1. Usage Board Membership
   • 1.1. The UB will consist of nine people appointed by the DCMI Advisory Board (Advisory Board members can serve on the Usage Board, but should not constitute more than half the UB). [Not sure how it would work to have the Advisory Board make appointments. --TB]
   • 1.2. Usage Board member terms shall be for two years, renewable once. [Is this a standard? We may want to relax this a bit in order to stagger terms--TB]
   • 1.3. Members should be selected based on the following criteria:
   • • 1.3.1. Possession of an understanding of 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 sufficient to prepare documents and discuss complex issues in a group setting
     • 1.3.5. Geographic 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 Advisory Board. The term of the chair shall be for two years, renewable once.
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, placed to make attendance convenient for as many members as possible
   • 2.2. Funding for meetings
   • • 2.2.1. Funding for meetings should be supported as much as possible by DCMI
     • 2.2.2. Funding for UB meetings held in conjunction with "regular" DCMI meetings or conferences may be supported by the member's institution (if that institution were already funding attendance at the conference/workshop)
   • 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 will be replaced by the DC Advisory Board
   • 2.4. Attendance by others
   • • 2.4.1. Attendance at UB meetings is open to all. [That means anyone from anywhere who wants to go (and incur any travel expenses)? How will it be announced? --RG]
     • 2.4.2. Participation in discussion of proposals is encouraged
   • 2.5. Agenda preparation and distribution
   • • 2.5.1. The UB chair is responsible for preparing the meeting agendas and assigning shepherds
     • 2.5.2. Agendas and relevant proposals shall be available on the DC website at least one month ahead of scheduled meetings [See section 5.3? --DH]
     • 2.5.3. Agenda items shall include the name and email address of the UB member responsible for shepherding the proposal through the UB process
   • 2.6. Minutes
   • • 2.6.1. Records 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 website as soon as possible after the meeting [See section 5.3? --DH]
3. Proposals
4. • 3.1. Sources of proposals
   • • 3.1.1. 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. External metadata communities (many of these will be assigned to working groups and not come directly to the UB)
     • 3.1.3. UB itself
   • 3.2. UB originated proposals
   • • 3.2.1. Generally non-controversial
     • • 3.2.1.1. Addition of schemes to existing elements
       • 3.2.1.2. Addition of simple terms to vocabulary lists maintained by the DCMI
       • 3.2.1.3. Modification of definition, scope or official examples of an existing element, qualifier or term in a vocabulary list
     • 3.2.2. Proposals should be circulated as usual, if objection to "non-controversial" status develops, it can be routed to a WG by the chair, in conjunction with the DCMI Advisory Board
   • 3.3. Proposals should include: [What parts of this need to be included in the Registry? --TB] [We also need words here to specify which portions will be "tokens" and which translatable into other languages. --TB]
   • • 3.3.1. A "name" of the proposed element or qualifer for use in encodings
     • 3.3.2. A "label" and "definition" in clear English
     • 3.3.3. An example or two if appropriate, making clear what type of literal values are expected
     • 3.3.4. Whether the proposed term is an Element, Encoding Scheme, Controlled Vocabulary, or Element Refinement (typology to be taken from the reference grammar)
     • 3.3.5. For qualifiers: the element being qualified
     • 3.3.6. 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.3.7. A discussion of possible overlap with existing terms
     • 3.3.8. A summary history of the post-proposal discussion, written by the shepherd, shall be included (if there was one)[Time frame? --RG]
     • 3.3.9. An analysis of the impact on existing Dublin Core applications
     • 3.3.10. An analysis of interoperability with other metadata schemes
     • 3.3.11. A justification of the need for the proposed element or qualifier in a cross-domain application
     • 3.3.12. Links to further information on the web
   • 3.4. Distribution
   • • 3.4.1. Proposals may be posted on a WG website and linked to the UB agenda [See section 5.3? --DH]
5. Process for moving proposals
6. • 4.1. Announcements
   • • 4.1.1. Announcements of proposals to be discussed by the UB shall be made on the DC-General list and other relevant lists
     • 4.1.2. Announcements of proposals may be made by the WG chair or the UB chair
     • 4.1.3. Announcements should be made at least once, preferably twice
   • 4.2. Shepherds
   • • 4.2.1. Each proposal shall be assigned a shepherd by the UB chair
     • 4.2.2. Shepherds should have knowledge of the proposal issues or be connected to the WG originating the proposal
     • 4.2.3. Responsibilities
     • • 4.2.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)
       • 4.2.3.2. Summarize the discussion and points of contention of the proposal for the UB, either verbally at the meeting or in writing prior to the meeting (preferred)
       • 4.2.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 [Does this include a "revise and resubmit" recommendation? --TB]
       • 4.2.3.4. Recommend to the UB any further action after a decision has been made on the proposal
   • 4.3. Pre-meeting discussion
   • • 4.3.1. Discussion on proposals should be managed on the relevant DC WG list or the DC-General list (if the proposal does not emanate from a WG) [Time frame? --RG] [One month? --TB]
   • 4.4. Criteria for acceptance of proposals
   • • 4.4.1. Follows existing principles of qualification
     • 4.4.2. Is well-formed
     • 4.4.3. Does not conflict with or create ambiguity with regard to existing elements, or qualifiers
     • 4.4.4. Does not needlessly create problems for existing legacy implementations ["Needlessly" is vague and undefined --RG]
     • 4.4.5. Qualifies as an interoperability solution with cross-domain application
   • 4.5. Categories of acceptance (using Tom's definitions)
   • • 4.5.1. CONFORMING. Proposed terms judged by the Usage Committee to substantially meet grammatical principles. [Use of "terms" unclear. Do we mean qualifiers or elements? --RG]
     • 4.5.2. NON-CONFORMING. Proposed terms found not to be in conformance with principles, if the Usage Committee wishes to state this for the record. Perhaps the registry would model this as an assertion about a term located in a non-DCMI namespace. In most cases, however, a verdict would simply be returned to the proposer with comments or a recommendation to revise and resubmit.
     • 4.5.3. RECOMMENDED. Conforming terms shown to be of general use and broad interest across disciplines. The Usage Committee may want to recommend that multiple Conforming terms of similar scope be combined into one single Recommended term. [What about conforming (to principles) but not recommended (i.e. not of general use)? --RB]
     • 4.5.4. OBSOLETE. For terms that have been superseded, deprecated, or rendered obsolete. Such terms will remain in the registry for use in interpreting legacy metadata.
   • 4.6. Voting
   • • 4.6.1. Voting shall be limited to scheduled meetings [Is there any chance of approving through an email ballot non-controversial qualifiers, e.g. the registration of a new encoding scheme? Or doing a conference call? --RG]
     • 4.6.2. Voting shall be limited to UB members present at the meeting and able to participate in the discussion
     • 4.6.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)
     • 4.6.4. UB members who cannot be present may explore other options with the chair, such as conference calling, etc. 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 [What if there's a tie? --RG] [Perhaps 2/3 majority is too low a threshold? --TB]
7. Follow-up to meetings
8. • 5.1. Registration
   • 5.2. Communication
   • • 5.2.1 For internal communication the UB uses the closed mailing list dcmi-usageboard@dublincore.org. The messages are archived and made available via a web-based browsing and search interface at: http://lists.dublincore.org/cgi-bin/ezmlm-cgi?5
     • 5.2.2 Public discussions of UB related issues should take place in the appropriate lists like DC-GENERAL, DC-AC and the working group lists and if necessary be cc:ed to the internal UB list.
     • 5.2.3 The mails from the old dc-usage list should be archived in the DCMI websites UB area (see below). The JISCMAIL dc-usage list which has not been used this year should be subsequently closed:
     • • Mailing list: dc-usage@jiscmail.ac.uk
       • Archive: http://www.jiscmail.ac.uk/lists/dc-usage.html
       [Does this really need to be in our permanent documentation? --DH]
   • 5.3. Documentation
   • • 5.3.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. It could be structured similarily as a working group page with an issues, forums and resources section. If necessary, an UB internal section can be password protected.
     • 5.3.2 Historic documents relevant to the UB work, like voting proposals and results from the first DC Qualifier voting are to be gathered and archived at the same page (background).
     • 5.3.3 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://www.dublincore.org/documents/ as all the other similar documents. This includes upcoming lists of acknowledged vocabulary and encoding scheme qualifiers.
     • 5.3.4 The UB page maintains links to upcoming external relevant metadata, vocabulary and encoding scheme registries.