This document contains some reference notes and has no official standing. It is subject to change at any time and should not be considered to be stable nor citable.
From the World Wide Web Consortium Process Document (1 August 2014):
"Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public)."
The W3C Process Document provides a detailed process for assessing consensus and managing dissent. "A group SHOULD only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock."
W3C produces several kinds of documents. The most important is a "technical report" whose purpose is to standardize Web technology. A technical report that has completed the W3C standards process is called a "Recommendation". A "Team Submission" is an informative document produced by a W3C Team but is not part of the technical report development process. Groups may also produce W3C Notes. A Note documents information that is not part of a technical specification (e.g. use cases or best practices). It also may be used to clarify the status of abandoned work.
There are two kinds of W3C groups that contribute to the development of Recommendations. An Interest Group brings together people who want to exchange ideas and evaluate potential Web technologies. A Working Group produces deliverables, including Recommendation Track technical reports and software.
- A Working Group creates one or more Working Drafts to refine the document that satisfies their charter.
- After a review suggests that a Working Draft has met the requirements to become a standard, the draft is published as a Candidate Recommendation.
- The Candidate Recommendation receives feedback from the entire W3C membership, while the Working Group formally collects implementation experience to demonstrate that the specification works.
- A Proposed Recommendation finalizes the review of the W3C membership and is assessed by the Director.
- If the director determines that the member review supports advancement to a standard, the W3C publishes the document as a Recommendation. The director may also decline to advance the document, to require additional work by the Working Group, or push the specification to a lower maturity level.
Members are organizations that have joined the W3C and that provide representatives to participate on the Advisory Committee and to participate in Working and Interest Groups.
The W3C Team provides technical leadership and manages W3C Activies. It includes the Director, Chair, Chief Operating Officer, paid staff, unpaid interns, and Fellows. Fellows are individuals whose salary is paid by a Member organization.
The Advisory Committee provides guidance to the Team on issues of strategy and management. It has no decision-making authority.
The Technical Architecture Group's scope is limited to technical issues about Web architecture. It documents and builds consensus around principles of Web architecture. It resolves issues about Web architecture brought to it. It coordinates cross-technology architecture developments inside and outside the W3C. The TAG is a permanent part of the W3C. Three members are appointed by the W3C Team. Five members are elected by the Advisory Committee. The ninth member is the W3C Director. The TAG observes the standard W3C consensus process, but may vote if consensus cannot be obtained and a timely decision is required. See the TAG Charter for details.
A Working Group consists of Member representatives, invited experts, and Team representatives. An Interest Group has the same types of members, plus public participants. To allow rapid progress, Working Groups are small (typically <15 people) and are experts in the area. Working and Interest Groups have Charters that define the group's mission, scope, duration, and deliverables. The Group has a Chair who is appointed by the Director. A group may have task forces to carry out assignments for the group. Group members who do not demonstrate a serious commitment to the charter may be removed from Good Standing in the group.
Working Groups have a "heartbeat" requirement to ensure that the group moves forward and is publicly accountable. The working group must update its technical report draft at least every three months.
Working Groups and Interest Groups have a specified duration. A group may be closed if the Director determines that there are insufficient resources to go forward or if the deliverable is produced ahead of schedule. If a Working Group is closed, the W3C publishes any unfinished specifications on the Recommendation track as a "Working Group Note".
Working groups track errors on an "errata page" that is linked from the Recommendation.
There are several classes of revisions to a Recommendation:
- A Recommendation can be republished if a revision involves non-textual changes (e.g. changing to a different version of HTML)
- Editorial changes do not require a technical review. In this case, the Recommendation drops back to the Proposed Recommendation stage.
- Substantive changes that do not introduce new features move the Recommendation back to the Candidate Recommendation stage.
- Substantive changes that introduce new features require starting at the beginning of the process with a new First Public Working Draft.
A W3C Recommendation can be rescinded. This may happen if it contains many errors that conflict with a later version or if burdensome patent claims affect implementers and cannot be resolved.
From The Internet Standards Process -- Revision 3 (RFC 2026, October 1996). See also The IETF Process: an Informal Guide.
The Internet Standards process is an activity of the Internet Society that is organized and managed on behalf of the Internet community by the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG). ...
The Internet Standards Process described in this document is concerned with all protocols, procedures, and conventions that are used in or by the Internet...
In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet.
Internet Society (ISOC) is "global cause-driven organization governed by a diverse Board of Trustees that is dedicated to ensuring that the Internet stays open, transparent and defined by you." Its trustees are appointed or elected by its Chapters, Organization members, and the IETF. The ISOC promotes the Internet.
Internet Engineering Task Force (IETF). The goal of the IETF is "to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet." The IETF commits to an open process, technical competence, rough consensus, and a basis in real-world experience in implementing its specifications. "There is no formal membership in the IETF and participation is open to all. Participation is by individual technical contributors rather than by formal representatives of organizations." (IETF Working Group Guidelines and Practices) IETF Area Directors manage areas of focus (e.g. security-related technology) and may be assisted by an advisory group.
Internet Engineering Steering Group (IESG). The IETF Area Directors along with the IETF Chair form the IESG. The IESG "is responsible for technical management of IETF activities and the Internet standards process. ... The IESG is directly responsible for the actions associated with entry into and movement along the Internet "standards track," including final approval of specifications as Internet Standards."
Internet Architecture Board (IAB). The IAB is a committee of the IETF responsible for oversight of the Internet architecture and the Internet Standards process, including appeals. It is responsible for editorial management of the RFC document series. It advises the ISOC Board of Trustees and Officers. It is comprised of twelve members selected by the IETF Nominations Committee, the IETF Chair, and several ex-officio positions.
A Request For Comments (RFC) is an archival document in the official publication channel for Internet standards documents. RFCs include two important document types: Internet Standard (STD) and Best Current Practices (BCP). Internet Standards are generally related to technical specifications required for communication across interconnected networks. Best Current Practices "define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." BCPs are subject to the same set of procedures as standards track documents. There are also informational RDFs that are not subject to the rules for Internet standardization.
A Birds of a Feather (BOF) meeting may occur at which an issue is discussed, and a problem is well-understood and scoped. The meeting may result in the formation of a Working Group (WG) with a specific charter.
A Working Group (WG) has a charter that is negotiated between a prospective working group Chair and the relevant Area Director, and approved by the IESG. The Charter specifies the objectives and approach of the WG and enumerates milestones and a timeframe for completion.
The WG is led by a chair and has a document editor. WGs are autonomous and determine the details of their own operation. The core rule for operation is that acceptance or agreement is achieved via working group 'rough consensus'."
After the tasks of a WG are completed, the group is disbanded. If the WG produces a standard, it often becomes dormant with its mailing list available to review the work as it moves toward Standard status.
If it becomes evident that a WG can't complete its work, the Area Director (in consultation with the WG) can: recharter, choose a new Chair, or disband the group.
The Document Editor "is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group."
A Design Team is a sub-group that develops a proposal to solve a particular problem.
An Internet-Draft (I-D) is a working document prepared in advance of a WG work session. Internet Drafts have no official standards status whatsoever.
Mature standards documents pass through two levels: Proposed Standard and Internet Standard (a third level - Draft Standard - was eliminated in RFC 6410)
A Proposed Standard "is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances." A Proposed Standard "should have no known technical omissions with respect to the requirements placed upon it" and must remain at that level for at least six months.
"An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community." The IESG issues an IETF-wide "Last Call" of at least four weeks, then confirms the advancement to the Internet Standard level. The following criteria apply:
- There are at least two successful, independent interoperating implementations.
- There are no significant errata that would prevent interoperability with deployed specifications.
- There are no unused features that greatly increase implementation complexity.
- If patented, two implementations must have successfully used the licensing process.
Best Community Practices (BCPs) follow a process similar to that of Internet Standards:
- Submit to IESG for review.
- Last-Call on IETF Announce mailing list.
- The IESG makes a final determination of whether to approve the action.
However, there are not two levels of maturity and once approved, the BCP is complete.
"A new version of an established Internet Standard must progress through the full Internet standardization process as if it were a completely new specification. Once the new version has reached the Standard level, it will usually replace the previous version, which will be moved to Historic status. ... the relationship between the previous and the new versions must be explicitly stated in the text of the new version ..."
"As the technology changes and matures, it is possible for a new Standard specification to be so clearly superior technically that one or more existing standards track specifications for the same function should be retired. In this case, or when it is felt for some other reason that an existing standards track specification should be retired, the IESG shall approve a change of status of the old specification(s) to Historic. This recommendation shall be issued with the same Last-Call and notification procedures used for any other standards action."
Although public comment forms a part of the DCMI processes for adopting changes to metadata terms and Recommendations, achievement of consensus is not explicitly listed as a criterion for acceptance as it is in the W3C and IETF processes.
"The Directorate consists of compensated directors who support the Executive Committee and DCMI's three Boards through the provision of specific services in areas such as financial management, required reporting, and the development and execution of DCMI activities."
"The Governing Board manages the affairs of DCMI and performs the duties usually performed by the board of directors of a corporation."
"The Technical Board is the organizational body that ensures the publication and maintenance of DCMI technical and semantic specifications in accordance with DCMI policy. These include specifications to which DCMI has made a long-term maintenance commitment, adaptations of DCMI specifications published by formal standards organizations, and specifications published as products of DCMI communities."
The Technical Board has three committees:
- Usage Committee - makes technical decisions regarding semantic specifications (i.e. DCMI Metadata terms).
- Standards Committee - manages the process by which DCMI specs are recognized by standards organizations (ISO 15836).
- Community Specifications Committee - manages DCMI Communities and Task Groups and publication of DCMI Community Specifications
"The Advisory Board is the organizational body that advances DCMI's work through engagement with DCMI community members and liaising with other initiatives that have shared, metadata-related interests. The Board is responsible for overseeing the programmatic work of the Initiative"
Refer to the approval procedure and documents pages for more information.
- DCMI metadata terms
- DCMI Recommendations.
- DCMI Recommended Resources (including Application Profiles).
- DCMI Process Documents.
DCMI essentially has a single set of terms, so it doesn't really adopt "new" vocabularies - just changes to the terms in the DCMI vocabulary.
DCMI Recommendations are "semantic or technical specifications that have been approved through DCMI's formal approval process. These specifications are stable and are supported for adoption by the Dublin Core community."
DCMI Recommended Resources are "resources under the responsibility of the DCMI Executive that are recommended as material for use by the DCMI community in support of their use of Dublin Core metadata."
DCMI Process Documents "describe process and procedures relevant for the operation of DCMI and its work structure."
Refer to the Procedure for approval of proposals by DCMI
Proposals can come from the Directorate, Affiliates, Communities, Task Groups, other organizations, or any individual (basically anyone).
Documents are submitted to the DCMI Managing Director. "The Directorate acknowledges receipt and decides whether a document falls in one of the five categories, possibly in consultation with the Advisory Board. A first decision on whether DCMI will accept a proposal for consideration is communicated to the submitter no later than two months after submission with specification of the process and timeline foreseen."
The subsequent procedure varies depending on the category of the proposed change
From the Procedure for approval of proposals by DCMI
Proposals related to existing DCMI metadata terms (including editorial comments or updating obsolete references) are evaluated by the DCMI Usage Board within four weeks from submission. If the advice from the Usage Board is negative, the Directorate rejects the proposal and informs the submitter with reasons for rejection. If the advice is positive and the proposed change is substantial, the Directorate prepares for public comment. Minor editorial changes will be made immediately without a public comment period.
Any comments from the UB are communicated to submitters who have the opportunity to make modifications based upon those comments. If major changes are made, the proposal needs to be re-submitted.
Public comment is open for a minimum of four weeks, announced by the Directorate on DC-GENERAL and with a news item on the DCMI Web site and published on the Public Comment page. If serious objections are expressed by the public, the Directorate decides what to do, in consultation with the Usage Board: (a) reject the proposal and inform the submitter with reasons, giving the option to re-submit with changes, or (b) ask submitters to make minor changes to the proposal.
If no serious objections are received, the Usage Board incorporates the proposal in the documentation of Dublin Core terms, after which the Directorate publishes an updated version of the DCMI Metadata Terms on the DCMI Web site and announces to DC-GENERAL and with a news item on the DCMI Web site.
The details of the policy regarding term changes are also spelled out in Section 3 of the Namespace Policy for the Dublin Core Metadata Initiative (DCMI). This policy has formed the basis for the term change policy of the Darwin Core Namespace Policy.
Changes to DCMI terms or term declarations will occur from time to time for a variety of reasons. Such changes have varying implications for DCMI term URIs and DCMI namespaces. The following classes of changes are identified along with examples and associated implications.
In all cases, any changes to DCMI terms or term declarations will result in an update to the versioning information carried in the DCMI recommendation and/or DCMI term declaration associated with that term.
A. Minor editorial errata
Errors of spelling, punctuation, or other clerical mistakes discovered in DCMI recommendations and/or DCMI term declarations will be corrected without a comment period, following notification to the DCMI Usage Board [DCMI-USAGE], as long as, in the judgment of the DCMI Directorate, there are no implications for negative impact on users or applications that rely on those DCMI term declarations.
Correction of minor editorial errata will result in no changes to DCMI term URIs.
B. Substantive editorial errata
Errors of substance discovered in DCMI recommendations and/or DCMI term declarations will trigger public notification of the correction to the DC-General mailing list [DC-GENERAL]. Errors that, in the judgment of the DCMI Directorate, compromise the immediate usefulness or accuracy of DCMI metadata systems will be corrected immediately (for example, an incorrect URL to a resource external to DCMI). Others will be corrected following a 14-day public comment period to assure that changes do not adversely effect systems or applications which rely on the DCMI namespace infrastructure.
Correction of substantive editorial errata will result in no changes in DCMI term URIs.
C. Semantic changes in DCMI terms
Changes of definitions within DCMI recommendations and/or DCMI term declarations will be reflected in the affected DCMI recommendation and/or DCMI term declaration. If, in the judgment of the DCMI Directorate, such changes of meaning are likely to have substantial impact on either machine processing of DCMI terms or the functional semantics of the terms, then these changes will be reflected in a change of URI for the DCMI term or terms in question. The URIs for any new DCMI namespaces resulting from such changes will conform to the DCMI namespace URI pattern defined above.
D. Addition of DCMI term declarations to existing DCMI namespaces New DCMI term URIs will occasionally be added to existing DCMI namespaces. Addition of DCMI term URIs to existing DCMI namespaces will not trigger changes in DCMI namespace URIs.
From the Procedure for approval of proposals by DCMI
The DCMI Directorate assigns the status of Proposed Recommendation or (in cases where a Recommendation already exists) Proposed Revised Recommendation.
Proposals go through an initial review in the Advisory Board for at least four weeks. After negative review, the Directorate informs the submitter with reasons for rejection. Modified proposals can be re-submitted. If AB review is positive, the Directorate prepares for public comment. Any comments from the AB are communicated to submitters who get the opportunity to make modifications based upon those comments. If major changes are made, the proposal needs to be re-submitted.
Public comment is open for a minimum of four weeks, announced by the Directorate on DC-GENERAL and with a news item on the DCMI Web site and published on the Public Comment page. If serious objections are expressed by the public, the Directorate decides what to do, in consultation with the Advisory Board: (a) reject the proposal and inform the submitter with reasons, giving the option to re-submit with changes, or (b) ask submitters to make minor changes to the proposal.
After successful public comment, the Directorate publishes the Recommendation on the DCMI Web site and announces to DC-GENERAL and with a news item on the DCMI Web site.
From the Procedure for approval of proposals by DCMI
The Recommended Resources process is simpler than that for Recommendations in that it does not require public comment:
In general, evaluation and subsequent acceptance or rejection of proposed DCMI Recommended Resources are at the discretion of the Directorate, in consultation with the Advisory Board. The procedure for Application Profiles is different and is described in Section 4 below.
The decision on acceptance or rejection is taken by the Directorate and communicated to the submitter no later than six months after the submission of the proposal. Rejections are communicated to the submitter with reasons for rejection. The Directorate announces the acceptance of proposals to DC-GENERAL and with a news item on the DCMI Web site. The Recommended Resource is published on the DCMI Web site (possibly as a link to the resource, for example as is the case with the question-and-answer service AskDCMI).
If the Recommended Resource is an Application Profile, the process is similar, except that a review is conducted by the Usage Board rather than the Advisory Board or Directorate.
##Global Biodiversity Information Facility (GBIF)
Website: http://www.gbif.org/
###Background document:
Recommendations for the Use of Knowledge Organisation Systems by GBIF (2011)
A precursor to this paper was the GBIF Report on Vocabularies for Biodiversity (GRVB), but its URL http://imsgbif.gbif.org/CMS/DMS_.php?ID=1057 doesn't work. There is another document called "Vocabularies for Biodiversity Informatics" from April 2010 that may be an early draft. It contains the recommendations cited in the KOS report.
GRVB Recommendation 1 recommends promoting the practice of developing flat vocabularies (concepts and definitions) independently from modeling relationships between concepts.
GRVB Recommendation 3 recommends a three-layered approach:
- Well-defined human-readible terms without constraints.
- A logical layer (RDF/OWL)
- project documents including applicability statements.
GRVB Recommendation 4 recommends using SKOS as a minimal mechanism for expressing and sharing multi-lingual vocabularies.
Mentioned: ISO 25964 (standards for vocabulary development). ISO 25964 covers how thesari should be developed and is complementary to SKOS which addresses how thesari should be expressed on the Web.
###Organizational Structure
The Secretariat "is charged with developing, executing and reporting on the GBIF work programme".
The GBIF Governing Board "is the means by which GBIF Participants make collective decisions. Currently meeting once a year, it consists of one representative from each Participant country and organization."
Task Groups are established by the GBIF Governing Board (for example, see http://www.gbif.org/newsroom/news/fitness-for-use-task-groups-announced). In particular, the Science Committee may set up Task Groups to address specific issues (See Rules of Procedure of the GBIF Governing Board).
###Products Controlled vocabularies at http://rs.gbif.org/ e.g. http://rs.gbif.org/vocabulary/gbif/establishment_means.xml. See the GBIF Vocabulary Server for more on this.
Maintains a resource library that includes Best Practice guides on a number of subjects, for example the Best practice guide for compiling, maintaining, disseminating national species checklists.
###Procedure for generating products (?)
See http://www.loc.gov/standards/
See http://www.niso.org/home/ "Designated by ANSI [American National Standards Institute] to represent U.S. interests as the Technical Advisory Group (TAG) to the International Organization for Standardization's (ISO) Technical Committee 46 on Information and Documentation."