|Home > Usage > Documents > Process >|
|Creator:||Diane I. Hillmann|
|Creator:||Stuart A. Sutton|
|Is Replaced By:||Not Applicable|
|Description of document:||This document describes the process by which the DCMI Usage Board reaches decisions on terms and application profiles, as well as its process for managing the registration of encoding schemes.|
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 year terms which are renewable. 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 a two year term which is renewable.
1.5. Liaisons from DCMI affiliates may be appointed by DCMI management in consultation with the Usage Board Chair.
1.5.1. Liaisons are non-voting but are encouraged to participate in discussion on the Usage Board list and at meetings.
1.5.2. Liaisons do not serve as shepherds. 1.6. For internal communication the UB uses the closed mailing list firstname.lastname@example.org. The messages are archived and publicly available at http://www.jiscmail.ac.uk/lists/dc-usage.html.
2.1.1. Meetings should be held at least twice a year.
18.104.22.168. One meeting should be scheduled during the annual DC general workshop/conference.
22.214.171.124. 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.
126.96.36.199. Scheduling should be done far enough in advance so that as many members as possible may be present.
2.2. Funding for regular UB member attendance at meetings should be supported as much as possible by DCMI.
2.2.1. Funding for Liaisons attendance at UB meetings should be supported by their institution. 2.3. Meeting agenda 2.3.1. The UB Chair maintains the agenda, which cites links to relevant supporting documentation, including JISCMAIL postings.
2.3.2. All materials pointed to in the agenda are archived at http://dublincore.org/usage/meetings/ after the final pre-meeting version of the agenda has been distributed. After the meeting, the archive version of the agenda is edited to point to these archive copies.
2.4. Attendance by members
2.4.1. Members must attend at least one meeting in a given year to maintain membership in good standing.
2.4.2. Members who miss two meetings in succession may be replaced by the DC Directorate.
2.5. Attendance by others
2.5.1. Attendance at UB meetings by other than the UB is by invitation.
188.8.131.52. People interested in attending should request an invitation via the UB Chair or the Managing Director.
2.5.2. Participation in discussion of proposals by any interested parties is encouraged.
2.6. Agenda preparation and distribution
2.6.1. The UB chair is responsible for preparing the meeting agendas and assigning shepherds to proposals.
2.6.2. Agenda items shall include the name and email address of the UB member responsible for shepherding the proposal through the UB process.
2.6.3. Agendas shall be available at http://www.dublincore.org/usage/meetings/ a few weeks before the meeting.
2.7. Important decisions will be assigned a number for citation purposes and documented on the DCMI website.
> 3.1. Recommended: Elements, Element Refinements, and DCMI-maintained Vocabulary Terms (e.g., member terms of the DCMI Type Vocabulary) useful for resource discovery across domains.
3.2. Conforming: Elements, Element Refinements and Application Profiles may be assigned a status of conforming. Elements and Element Refinements assigned a status of conforming are those for which an implementation community has a demonstrated need and which conform to the grammar of Elements and Element Refinements, though without necessarily meeting the stricter criteria of usefulness across domains or usefulness for resource discovery.
3.3. Obsolete: For Elements and Element Refinements that have been superseded, deprecated, or rendered obsolete. Such terms will remain in the registry for use in interpreting legacy metadata.
3.4. Registered: Used for Vocabulary Encoding Schemes and language translations for which the DCMI provides information but not necessarily a specific recommendation.
Part 2-Proposals: Form and Process
4.1. Sources of proposals may be:
4.1.1. DCMI working groups
184.108.40.206. Existing working groups
220.127.116.11. Working groups established for the purpose of developing proposals
4.1.2. Metadata implementers
4.1.3. UB itself
4.2. Requirements for proposals for "Recommended" and "Conforming" status
4.2.1. To be supplied by the proposers (see table below):> >
4.2.2. To be supplied by the UB shepherd:
Proposal Requirements Table Name A suggested unique token for use in encodings Label A suggested human-readable label for the proposed term Definition The suggested definition of the term Comment Information concerning the possible application of the proposed term Examples Examples of use of the proposed term, making clear what type of literal values are expected Type of term Is the proposed term an "element," or an "element refinement" (as defined in http://dublincore.org/usage/documents/principles) [NOTE: Encoding schemes are registered using a separate process] Term qualified If the proposed term is an element refinement, which term does it qualify? Why needed A justification of the need for the proposed term Working Group or community support Demonstration and documentation that the proposed new term has substantial support of Working Group members (if applicable) as well as others in the relevant community. Evidence of such support can include votes held on mailing lists or in face-to-face meetings or positive endorsements from members of the DC-GENERAL mailing list. Proposed status Is the term proposed as Recommended or Conforming? Related DCMI terms A discussion of possible overlap with existing terms Related non-DCMI terms An annotated listing of related terms in non-DCMI metadata vocabularies Impact on applications An annotated listing of existing applications that could be affected by recognition of this term About the proposers 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
18.104.22.168. A summary history of the post-announcement discussion
4.3. Guidelines: The following criteria are offered as guidelines for developing a proposal -- they reflect criteria that the Usage Board will use in its decision-making. They do not constitute further requirements for the formal documentation of a proposal.
4.3.1. Criteria for evaluating a term proposal
22.214.171.124.1. Can the term be clearly defined?
126.96.36.199.2. Can the semantics of the proposed element or element refinement be expressed precisely, unambiguously, and briefly?
188.8.131.52.1. Is the term practical?
184.108.40.206.2. How difficult would it be for people creating metadata to comprehend the semantics of the proposed element or element refinement and to apply it reasonably in the description of resources?
220.127.116.11.1. Does the term refine an existing element?
18.104.22.168.2. If the proposed term is an element, can it reasonably be handled as effectively as an element refinement or encoding scheme for an existing element?
22.214.171.124.3. Are there alternative ways of implementing the term? Within the conceptual framework of the Dublin Core Element Set (i.e., element/element refinements and encoding schemes), are there alternative ways to achieve the ends sought?
126.96.36.199.1. Is there a clear requirement in existing implementations for the term in support of resource discovery?
188.8.131.52.2. Is there a demonstrated need for the proposed element or element refinement?
184.108.40.206.3. Are there existing implementations or encoding schemes, etc., which use the term?
220.127.116.11. Fits with other DCMI-maintained terms
18.104.22.168.1. Follows existing principles of refinement
22.214.171.124.2. Is well-formed
126.96.36.199.3. Does not conflict with or create ambiguity with regard to existing DCMI-maintained terms
188.8.131.52.4. Does not create problems for existing legacy implementations if those implementations have followed recommended practice
4.4. Decision tree for assessing the need for a new term>
> 4.5. Process for Moving Proposals
Decision Tree Table Condition 1: Can the need be solved with a vocabulary encoding scheme for an existing DCMI Element or Element Refinement? If so, do that; else … Condition 2: Can the need be solved through an application profile that references an element or element refinement from an existing and recognized non-DCMI namespace? If so, do that; else … Condition 3: Can the need be solved with a new refinement for an existing DCMI element? If so, do that; else … Condition 4: Create a new DCMI Element (and, if necessary, Element and Vocabulary Encoding Scheme) to meet the need.
4.5.1. Appointment of Shepherds
184.108.40.206. Each proposal shall be assigned a shepherd by the UB chair from among the UB membership.
220.127.116.11. Shepherds should have knowledge of the proposal issues or be connected to the WG originating the proposal.
18.104.22.168.1. Monitor discussion on relevant lists (shepherds should be members of the relevant DC WG list during the time of consideration of a proposal and are encouraged to join in the discussion to ensure that all relevant issues are exposed during the discussion period).
22.214.171.124.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).
126.96.36.199.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.
188.8.131.52.4. Verify registration information for the DCMI Web Team.
184.108.40.206.5. Prepare draft of UB official decision on the proposal for review and approval by the UB.
4.5.2. Pre-announcement process
220.127.116.11. Proposer must inform the DCMI Managing Director and the UB Chair of the intent to submit a proposal at the earliest possible time in the proposal's development so that the UB Chair can assign a UB member to serve as shepherd for the proposal process and to calendar: (1) the deadline for submission of the proposal; and (2) the date the UB will deliberate and make its decision which must be at least six weeks after the proposal submission deadline.
18.104.22.168. No later than six weeks before the submission deadline, the proposer will provide the UB Chair with a draft of the proposal for distribution to the shepherd.
22.214.171.124 At the time the draft of the proposal is distributed to the shepherd, the UB Chair will schedule a conference call to discuss the draft among, at a minimum, the propose, the shepherd and the UB Chair. Others participants may be invited at the discretion of the proposer, the shepherd and the UB Chair. Notes capturing significant issues discussed during the call will be recorded and distributed to the call participants and the UB members.
126.96.36.199. No later than the deadline for submission set by the UB Chair, the proposer shall submit the finished proposal to the DCMI Managing Director and the UB Chair.
188.8.131.52. Proposal is given preliminary review for completeness by DCMI Managing Director and UB Chair.
184.108.40.206. If complete and no revisions needed, proposal is circulated to UB members and announced for public comment by the Managing Director. A period of two weeks will be allowed between the date of the decision on completeness and the public announcement of the proposal to provide time for preparation of the supporting materials for public dissemination.
220.127.116.11. If incomplete or revisions needed, proposal is returned to originator, with request for revision or additional information.
18.104.22.168. Throught out the periods of discussion and deliberations, UB members are free to comment and join as individuals in listserv discussions of the proposal. Opinions expressed by UB members during such discussions should not be considered official opinions of the UB.
22.214.171.124. Between the close of the public comment period and the UB meeting, the shepherd shall prepare the final version of the proposal and distribute it to the UB.
126.96.36.199. The benchmark dates in the proposal process shall follow the pattern set out in the table below:
Intention to Propose
See section 188.8.131.52 above 4 weeks 16 weeks before UB meeting DCMI Executive Director
See sections 184.108.40.206-3 above 5 weeks 12 weeks before UB meeting UB Chair
See section 220.127.116.11 above 2 weeks 7 weeks before UB meeting DCMI Executive Director
Comment Period See section 18.104.22.168 above 4 weeks 5 weeks before UB meeting DC-General Participants
Preparation and Transmittal
See section 22.214.171.124 above 1 week 1 week before UB meeting Shepherd
126.96.36.199. Announcements of comment period for proposals to be discussed by the UB shall be made on the DC-General list and other relevant lists.
188.8.131.52. Announcements of proposals shall be made by the DCMI Managing Director.
184.108.40.206. Announcements will include:
220.127.116.11.1. Links to relevant information to be considered with the proposal
18.104.22.168.2. Relevant deadlines for comments
22.214.171.124.3. Addresses for comment submission
126.96.36.199.4. Information about UB meeting at which the proposal will be discussed, including place, time, and how to request an invitation to participate
188.8.131.52.5. Name and contact information for the assigned shepherd
4.5.4. Communication Responsibility Table> >
Communication Responsibility Table What Where Who Comment Proposal draft posted WG list, DC-General WG Chair Proposal added to UB agenda UB Website, UB list UB Chair Proposal announced for public comment DC-General DCMI Managing Director Usage Board Outcome DC-General DCMI Managing Director
4.5.5. Comment period
184.108.40.206. Comment period on proposals should be managed on the DC-General list.
220.127.116.11. Comment periods should be at least one month in length and commence at least six weeks before the UB meeting at which action is to be taken.
18.104.22.168. 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. The public discussion must start at least six weeks before the UB meeting at which the issues will be discussed.
22.214.171.124. Voting shall be limited to scheduled meetings and conference calls.
126.96.36.199. Voting shall be limited to UB members present at the meeting or conference call and able to participate in the discussion.
188.8.131.52. 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).
184.108.40.206. 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 physically or virtually, for the relevant discussion.
220.127.116.11. A proposal is approved if more than 50% of assigned votes in are in favor and fewer than 25% of assigned votes are against the proposal. Every effort will be made to achieve a firm consensus on a proposal before it is deemed approved.
4.6. Decisions of the UB are forwarded to the DCMI Directorate for endorsement and approval.
4.7. Registration of UB Decisions on Proposals
4.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.
18.104.22.168. The decision will include brief statements of recommendations being issued and detailed explanations of UB decisions not to issue recommendations.
22.214.171.124. UB decisions will be in a form determined by the UB and numbered consecutively for the purpose of citation.
126.96.36.199. 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.
4.7.2. Recommended terms will be put into the official DCMI documentation by the UB Chair.
5. Proposals for Registration of Encoding Schemes [SECTION 5 UNDER REVISION BY DIANE]
[NOTE: Some items deleted; Communication Table deleted.]> 5.1. Submissions of new encoding schemes may be forwarded to the UB Chair no later than six weeks prior to the next scheduled UB meeting.
5.2. A shepherd will be assigned to evaluate the submissions. Shepherd assignment will be based on:
5.2.1. Knowledge of a particular scheme
5.2.2. Knowledge of the language used in the scheme
5.2.3. Interest or knowledge of a particular subject or topical area covered by the scheme
5.2.4. Time the member has available for such tasks
5.3 The UB chair will not shepherd individual submissions, but will keep track of submissions and ensure that all are resolved in some manner.
5.4. The shepherd will be responsible for verifying the submitted information:
5.4.1. Name of the scheme
5.4.2. Availability and maintenance status
5.4.3. Appropriateness of the maintenance agency
5.4.4. Uniqueness and appropriateness of the proposed token
5.4.5. Possible use with elements not specified in the proposal
5.5. 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.
5.6. The shepherd will edit the submission and complete the registration process by submitting the information to the DCMI Web Team.[NOTE: Whether or not this is sufficient depends on whether we are still planning to maintain a simple web page of vocabularies.]
5.7. The DCMI Web Team will report to the UB list when registration has been completed.
5.8. The UB chair will announce new schemes as needed.
5.9. Communication Responsibility Table
6.1. Sources of proposals
6.1.1. DCMI working groups or working groups established for the purpose of developing one or more proposals
188.8.131.52. Existing working groups
184.108.40.206. Working groups established for the purpose of developing proposals
6.1.2. Metadata implementers, established projects or research groups
6.1.3. UB itself
6.2. For the purposes of review by the Usage Board:
6.2.1. The Usage Board is interested in reviewing application profiles that make substantial use of Dublin Core elements. The review of application profiles by the Usage Board serves to:
220.127.116.11. analyze the usage of Dublin Core within significant implementations;
18.104.22.168. assign a DCMI stamp of approval;
22.214.171.124. promote the sharing of application profiles between communities; and
126.96.36.199. identify new terms as candidates for inclusion in DCMI namespaces.
6.2.2. Application profiles must provide, for each term, an identifier of the element set where it is defined, ideally in the form of URIs for individual terms.
6.2.3. If the terms in an application profile describe anything other than generic "resources" (the typical domain of Dublin Core), the application profile must make this clear. This is particularly important if an application profile is based on a data model that describes multiple classes of resources, such as agents or collections.
6.2.4. It is recommended that application profiles be prepared using previously reviewed application profiles be prepared using the Dublin Core Application Profile guidelines published by CEN (ftp://ftp.cenorm.be/public/ws-mmi-dc/mmidc076.zip).
6.2.5. Each application profile must provide, or point to, a short text that describes:
188.8.131.52. The context and purposes in which the application profile is used or is likely to be used.
184.108.40.206. The organizations or individuals involved in its development and a capsule history thereof.
220.127.116.11. Any arrangements, policies, or intentions regarding the future development and maintenance of the application profile.
6.3. Review of Application Profiles by the Usage Board
6.3.1. An application profile is "well-formed" if it is presented in accordance with the broad and flexible requirements outlined above. These presentation requirements may become more specific as "good practice" emerges over time.
6.3.2. Usage Board review focuses on the use of terms related to Dublin Core terms and on any data models that provide a context for those terms. The Usage Board is agnostic about the use of terms not directly related to Dublin Core; strictly speaking such terms are outside the scope of Usage Board review.
6.3.3. The use of terms related to Dublin Core (such as refinements of Dublin Core elements, or Dublin Core elements that have been constrained for particular contexts) will be evaluated from the standpoint of semantic conformance, grammatical principle (eg, "dumb-down"), clarity, and good practice.
6.4. Publication and use of Usage Board Reviews
6.4.1. An application profiles that "pass" review will be assigned the status of 'conforming' and a date stamp. Changes to the application profile will be considered a new application profile and will require a new submission to the UB and a new timestamp.
6.4.2. For application profiles that "pass" review, the Usage Board will publish a Review on a Web page for application profiles.
6.4.3. Each Review will include, at a minimum:
18.104.22.168. Any comments from the Usage Board on the application profile.
22.214.171.124. Pointers to locally archived copies of the application profile as originally submitted and (if necessary) as subsequently amended in light of Usage Board comments.
126.96.36.199. A pointer to the "latest version" of an application profile held by its maintainers.
6.5. Review represents a form of recognition, and its URL will be persistent for purposes of citation.
Metadata associated with this resource: http://dublincore.org/usage/documents/process/index.shtml.rdf
Copyright © 1995-2004 DCMI All Rights Reserved. DCMI liability, trademark/service mark, document use and software licensing rules apply. Your interactions with this site are in accordance with our privacy statements. Please feel free to contact us for any questions, comments or media inquiries.
DCMI and the DCMI Web site are hosted by OCLC Research.