-----------------------------------------------------------------------
Diane's draft as text (rev. dih 5/30/01), for quoting in email
-----------------------------------------------------------------------
DRAFT--Dublin Core Usage Board Process
Changes made during DCMI UB meeting in Dublin, OH, May 21-22, 2001
Changes (and fixes to errors) from WORD draft circulated 5/29 noted in
green.
1. Usage Board Membership
o 1.1. The UB will consist of at least seven and no more than
eleven people (nine is ideal) appointed by the DCMI Directorate
o 1.2. Usage Board member terms shall be for two years, renewable
once. Initial appointments will be made so as to stagger terms
o 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 and domain distribution of members is
relevant but will not override other criteria
o 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.
2. Meetings
o 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.1.1.3. Scheduling should be done far enough in
advance so that as many members as possible may be
present
o 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)
o 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 Directorate
o 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.3. Participation in discussion of proposals is
encouraged
o 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 DC UB website
o 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
o 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. Metadata implementors
+ 3.1.3. UB itself
o 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, Encoding
Scheme, Controlled Vocabulary, 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
o 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 Vocabulary Terms Encoding
Schemes
Element qualified Vocabulary list
name
Name name Term Name of scheme
Label Label Label/Acronym
Definition Definition Definition URL for online
access
Originator Originator Originator Maintenance
body
Justification Justification Justification
Discussion of Discussion of Discussion of
overlap with overlap with overlap with
other terms other terms other terms
Impact analysis Impact analysis Impact analysis
Interoperability Interoperability Interoperability
analysis analysis analysis
Discussion Discussion Discussion
summary summary summary
Examples and best Examples and best Examples and best
practice practice practice
recommendations recommendations recommendations
4. Process for moving proposals
o 4.1. Pre-announcement process
+ 4.1.1. Proposal is received by DCMI Managing Director or UB
Chair
+ 4.1.2. Proposal is given preliminary review for completeness
by DCMI Managing Dirctor and UB Chair
+ 4.1.3. If complete and no revisions needed, proposal is
circulated to UB members and announced for public comment
+ 4.1.4. If incomplete or revisions needed, proposal is
returned to originator, with request for revision or
additional information
o 4.2. Announcements
+ 4.2.1. Announcements of comment period for proposals to be
discussed by the UB, or pending registration of new
encodingschemes shall be made on the DC-general list and
other relevant lists
+ 4.2.2. Announcements of proposals shall be made by the DCMI
Managing Director
+ 4.2.3. Announcements will include:
+ 4.2.3.1. Links to relevant information to be considered
with the proposal
+ 4.2.3.2. Relevant deadlines for comments
+ 4.2.3.3. Addresses for comment submission
+ 4.2.3.4. Information about UB meeting at which the
proposal will be discussed, including how to request an
invitation to participate
+ 4.2.3.5. Name and contact information for the assigned
shepherd
o 4.3. Shepherds
+ 4.3.1. Each proposal shall be assigned a shepherd by the UB
chair
+ 4.3.2. Shepherds should have knowledge of the proposal
issues or be connected to the WG originating the proposal
+ 4.3.3. Responsibilities
+ 4.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)
+ 4.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)
+ 4.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
+ 4.3.3.4. Recommend to the UB any further action after a
decision has been made on the proposal
o 4.4. Comment period
+ 4.4.1. Comment period on proposals should be managed on the
DC-General list
+ 4.4.2. Comment periods should be at least one month
o 4.5. Criteria for recommendation
+ 4.5.1. Follows existing principles of qualification
+ 4.5.2. Is well-formed
+ 4.5.3. Does not conflict with or create ambiguity with
regard to existing elements, or qualifiers
+ 4.5.4. Does not create problems for existing legacy
implementations if those implementations have followed
recommended practic
o 4.6. Categories of recommendation
+ 4.6.1. CROSS-DOMAIN. Terms of general use and broad interest
across domains.
+ 4.6.2. DOMAIN-SPECIFIC. Terms of interest to a limited
domain or set of domains.
o 4.7. Categories not recommended but able to be registered
+ 4.7.1. NON-CONFORMING. Proposed terms found not to be in
conformance with principles, but registered as used by one
or more implementations
+ 4.7.2. OBSOLETE. For terms that have been superseded,
deprecated, or rendered obsolete. Such terms will remain in
the registry for use in interpreting legacy metadata.
o 4.8. Voting
+ 4.8.1. Voting shall be limited to scheduled meetings and
conference calls
+ 4.8.2. Voting shall be limited to UB members present at the
meeting or conference call and able to participate in the
discussion
+ 4.8.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.8.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
+ 4.8.5. Consensus is achieved if fewer than two UB members
object to a proposal
5. Follow-up to meetings
o 5.1. Registration (to be added later)
o 5.2. Communication
+ 5.2.1 For internal communication the UB uses the closed
mailing list [log in to unmask] The messages are
archived and made available to the UB only via password
+ 5.2.2 Public discussions of UB related issues during public
comment periods should take place on DC-GENERAL
o 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.
+ 5.3.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.
+ 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.
+ 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.
------------------------------------------------------------------------
rev. dih 5/30/01
|
