Usage Board Administrative Process
DCMI Usage Board Administrative Processes
| Creator: | Diane I. Hillmann |
|---|---|
| Creator: | Stuart A. Sutton |
| Contributor: | Thomas Baker |
| Date Issued: | 2006-02-13 |
| Identifier: | http://dublincore.org/usage/documents/2006/02/13/process/ |
| Replaces: | http://dublincore.org/usage/documents/2003/02/07/process/ |
| Is Replaced By: | Not Applicable |
| Latest version: | http://dublincore.org/usage/documents/process/ |
| Status of document: | This is a DCMI Process Document. |
| Description of document: | This document describes the process by which the DCMI Usage Board reaches and documents decisions. The descriptions of process in this document are intended to guide the UB in executing its responsibilities for ensuring "an orderly evolution of the metadata terms maintained by the Dublin Core™ Metadata Initiative". The process statements are amended from time to time to reflect the evolving role of the Usage Board. In case of discrepancies, the DCMI Bylaws control. |
Index
- Usage Board Membership
- Meetings
- Status assigned by Usage Board decisions
- Process for moving proposals
- Registration of Application Profiles
- New terms in Application Profiles
- Endorsement of terms in other namespaces
- Revisions of existing terms
1. Usage Board Membership [from DCMI Bylaws].
1.1. Membership. The Usage Board will consist of at least seven and no more than eleven people (nine is ideal) appointed by the DCMI Directorate.
1.2. Responsibilities. The mission of the Usage Board is to ensure an orderly evolution of the metadata terms maintained by the Dublin Core™ Metadata Initiative. The Usage Board evaluates proposals for new terms (or changes to existing terms) in light of grammatical principle, semantic clarity, usefulness, and overlap with existing terms. To proposals that are accepted, it assigns a specific status. The Usage Board also evaluates constructs that use DCMI terms, such as Application Profiles.
1.3. Selection and Appointment Process. Members are selected based on the following criteria: knowledgeable concerning the development history and purpose of the DC element set and its relationship to the metadata world at large; related to a metadata community relevant to DCMI; willing and able to commit time and energy to the functions of the UB; able to communicate verbally and in writing in English well enough to prepare documents and discuss complex issues in a group setting; geographic and domain distribution of members is relevant but will not override other criteria. The DCMI Directorate will appoint the UB Chair from one of the membership. The DCMI Directorate can propose the appointment of non-voting Liaison members to the Usage Board. Liaison members may represent DCMI Affiliates or Sponsors, or other organizations that have a stake in the development of the Dublin Core™ semantic specifications.
1.4. Terms. Usage Board members are appointed for two-year, renewable terms. They may step down at their own discretion at any time.
1.5. Decision process. The Usage Board strives for consensus, justifying its decisions and interpretations in terms both of principle and of empirical practice. To be approved, a proposal needs more than 50% of assigned votes in favor and less than 25% of assigned votes against. Important decisions will be assigned a number for citation purposes and documented on the DCMI Web site. Decisions of the UB are forwarded to the DCMI Directorate for endorsement and approval.
1.6. Communication and documentation. For internal communication, the UB uses a closed mailing list. The messages are archived and are made publicly available. Meetings are held at least once a year. This meeting is scheduled during the annual DC general workshop/conference. Further meetings can be scheduled, preferably close to other conferences, so as to make attendance convenient for as many members as possible. Scheduling is done far enough in advance so that as many members as possible may be present.
1.7. Reporting. The chair of the Usage Board is responsible for the preparation of a report of meetings and conference calls and submission to the DCMI Directorate. Based on this report and after endorsement of Usage Board decisions, the Managing Director communicates the decisions to the DCMI community. Decisions on semantics are included in the reference documentation on the DCMI Web site.
2. Meetings
2.1. The calendar of UB meetings will be announced prominently on the UB DCMI homepage and announced on the DC-General mailing list.
2.2. Funding for regular UB members attendance at meetings should be supported as much as possible by DCMI. Funding for the attendance of Liaisons at UB meetings should be provided by their institutions.
2.3. The UB Chair maintains the agenda, which cites links to relevant supporting documentation, including JISCMAIL postings. All materials considered by means of the agenda are consolidated in a PDF briefing book and distributed electronically to UB members and Liaisons. At the conclusion of the meeting, the PDF briefing book becomes the official record of matters considered at the meeting. Important decisions will be assigned a number for citation purposes and documented on the DCMI website.
2.4. Additional meetings of the UB through conference calls may be scheduled at the discretion of the UB Chair.
2.5. The UB chair is responsible for assigning shepherds to proposals. Agenda items shall include the name of the UB member responsible for shepherding the proposal through the UB process. Agendas shall be available at the Web page DCMI Usage Board Meetings several weeks before the meeting.
2.6. Members must attend at least one meeting in a given year to maintain membership in good standing. Members who miss two meetings in succession may be replaced by the DC Directorate.
2.7. Attendance at any UB meeting by other than the UB members and liaisons is by invitation. People interested in attending should request an invitation via the UB Chair or the Managing Director. Participation in discussion of proposals by any interested parties is encouraged.
3. Status assigned by Usage Board decisions
Conforming [URI http://dublincore.org/usage/documents/process/#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 DCMI Abstract Model.
Recommended [URI http://dublincore.org/usage/documents/process/#recommended]. Elements, Element Refinements, and DCMI-maintained Vocabulary Terms (e.g., member terms of the DCMI Type Vocabulary) that conform to the DCMI Abstract Model and do not semantically overlap with other terms in DCMI namespaces (i.e., http://purl.org/dc/elements/1.1/ and http://purl.org/dc/terms/) may be assigned the status of Recommended.
Obsolete [URI http://dublincore.org/usage/documents/process/#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.
Registered [URI http://dublincore.org/usage/documents/process/#registered]. Used for Vocabulary Encoding Schemes and language translations for which the DCMI provides information but not necessarily a specific recommendation.
Endorsed [URI http://dublincore.org/usage/documents/process/#endorsed]. A non-DCMI assertion may be assigned the status of Endorsed where: (1) the term is managed by a registration authority other than DCMI and the assertion is that the term is conforming to the DCMI Abstract Model; or (2) the term is managed by a registration authority other than DCMI and the assertion is that the term bears either a property or subproperty relationship to a DCMI term.
4. Process for moving proposals
4.1. Assignment of shepherd Each impending proposal and application profile shall be assigned a shepherd by the UB chair from among the UB membership at the earliest opportunity. Shepherds should have knowledge of the proposal issues or application profile domain.
4.2. Shepherd responsibilities include:
- Monitoring 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).
- Summarizing 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). Serving as liaison to the relevant WG or community during the time the proposal is under discussion and after a decision has been made. Preparing a draft of UB official decision on the proposal for review and approval by the UB.
- In general providing advice and expertise to the Working Group or domain on good practices, the Abstract Model, and other issues affecting the process of developing a proposal or application profile. The shepherd should bring issues of concern to the attention of the UB when appropriate.
4.3. Preparing for public comment periods. Completed proposals are forwarded to DCMI Managing Director or UB Chair. Proposals are given preliminary review for completeness by the DCMI Managing Director and UB Chair. If complete and no revisions are needed, proposals are 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. If incomplete or revisions are needed, proposals are returned to the originator, with a request for revision or additional information.
4.4. Announcing the public comment period. Before announcement of the public comment period, proposals must be moved to the DCMI Web site, given DCMI page headers and a status of 'Proposed'. Announcement of the public comment period shall be made on the DC-General mailing list by the head of UB. Announcements should include links to the proposal; links to other relevant information; deadlines for comments; email addresses to be used for submitting comments. (In general, comments regarding a proposal may be addressed to the relevant WG mailing list, the DC-General mailing list or privately to the shepherd.) Announcements may also include information about the UB meeting at which the proposal will be discussed, including place, time, and how to request an invitation to participate; name and contact information for the assigned shepherd. The announcement should ask specifically for communications supporting the proposal in order to gauge the level of community support.
4.5. Managing public comment periods. The comment period for proposals should be managed on the DC-General list. Comment periods must be at least one month in length and commence at least six weeks before the UB meeting at which action is to be taken. 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.
4.6. Communication responsibility
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 Directorate Usage Board decision announced DC-General DCMI Directorate
4.7. Voting on proposals. Voting shall be limited to scheduled meetings and publicly announced conference calls. Voting shall be limited to UB members present at the meeting or conference call and able to participate in the discussion. 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). 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.
4.8. Documenting Usage Board decisions. A document explaining the UB decision regarding a proposal will be written in a timely fashion by the shepherd and approved by the UB. The decision will include brief statements of recommendations being issued and detailed explanations of UB decisions not to issue recommendations. UB decisions will be in a form determined by the UB and numbered consecutively for the purpose of citation. UB decisions must be sufficiently documented so that the rationale for the decision is clear and useful in guiding the development of future proposals. This is particularly true where the decision rejects a proposal or recommends further action.
4.9. Announcing and publishing Usage Board decisions. Decisions are published on the Web page DCMI Usage Board decisions. New terms will be added to the official DCMI documentation by the UB Chair.
5. Proposals for registration of application profiles
5.1. Application Profiles subject to review. Application profiles emanating from DCMI Strategic Activities may be reviewed by the Usage Board. Metadata implementers (established projects, communities or research groups) may also request review, subject to approval by the UB Chair. Point to information regarding DCMI Strategic Activities when available.
5.2. Documentation of Application Profiles. 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. 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. It is recommended that application profiles be prepared using the guidelines "Dublin Core™ Application Profile Guidelines".
5.3. Contextual information about Application Profiles. The documentation for each Application Profile must provide -- or point to a short text that describes -- the context and purposes in which the application profile is used or is likely to be used; the organizations or individuals involved in its development and a capsule history thereof; and any arrangements, policies, or intentions regarding the future development and maintenance of the application profile.
5.4. Evaluation of terms in Application Profiles. 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. Note: revisit this.
5.5. Assignment of status "conforming". Application profiles which pass review will be assigned the status of conforming The status of conforming indicates a Usage Board assessment of the application profile as of the date of its submission for review. Changes to already conforming application profiles require further Usage Board review of the application profile in whole or in part according to the processes and criteria outlined in sections 5.1 through 5.3.
5.6. Publication of Usage Board reviews of Application Profiles. For application profiles that "pass" review, the Usage Board will publish a Review on a Web page for application profiles. Each Review will include, at a minimum: any comments from the Usage Board on the application profile; pointers to locally archived copies of the application profile as originally submitted and (if necessary) as subsequently amended in light of Usage Board comments; a pointer (with appropriate disclaimers) to the "latest version" of an application profile held by its maintainers.
5.7. Persistent identifiers for reviewed Application Profiles. Review represents a form of recognition, and its URL will be persistent for purposes of citation.
6. New terms proposed with an Application Profile
6.1. Evaluation of new terms. New terms appearing in application profile submissions must be evaluated for compliance with the DCMI Abstract Model prior to evaluation of the Application Profile itself.
6.2. Assignment of DCMI term URIs and status. New terms deemed in compliance with the DCMI Abstract Model may be given URIs in DCMI namespaces and assigned a status of conforming.
6.3. Conformance criteria. Decisions as to whether a proposed term is in compliance with the DCMI Abstract Model will be made using the DCMI-Compliant Term Decision Tree.
7. Proposals for endorsement of terms in other namespaces for use within Application Profiles
7.1. Existing terms housed in other namespaces to be used within Application Profiles seeking review must be evaluated for compliance with the DCMI Abstract Model prior to evaluation of the Application Profile itself.
8. Revisions of existing DCMI terms
8.1. Proposals for revisions. Requests to change terms in DCMI namespaces may originate within the Usage Board or externally. A Usage Board member will be assigned to draft a proposal for a change. Changes provisionally approved by the Usage Board will be circulated for general comment on the DC-General discussion list for one month before final approval. Final approval for term changes without significant opposition may be approved by email or teleconference vote.
8.2. Changes for formally standardized terms. Terms from namespace http://purl.org/elements/1.1/ require changes to the relevant standards: ISO Standard 15836-2003 (February 2003) and NISO Standard Z39.85-2001 (September 2001).
8.3. Terms from DCMI-hosted namespaces [to be added]
8.4. Application profile terms residing on DCMI hosted namespaces will be subject to the same change processes as other DCMI terms, but managed by the entities responsible for the terms. Application profile terms residing on non-DCMI namespaces will be subject to term policies of the host entity.
8.5. Changes to already 'conforming' application profiles require further Usage Board review of the application profile in whole or in part according to the processes and criteria outlined in previous sections. Changes to DCMI-registered "conforming" application profiles will be versioned according to DCMI namespace policies.