Standard Upper Ontology Working Group Development Guidelines Version 1.0 D4 Status: Stage 2: Draft Material Editor: Matthew West 1. Introduction (editorial note: added in this version) This document is a deliverable of the Standard Upper Ontology Working Group under P1600.1 of the IEEE. The work programme to develop this document was approved by Resolution 3 of this group. 1.1. Copyright (editorial note: added in this version) The copyright of this document is vested in the IEEE. The document may be copied on whole or in part, but no charge may be made for it. 1.2. Purpose The purpose of this document is to support the purpose of the Standard Upper Ontology Working Group, as stated in the Project Authorisation Request given in the Normative References [1] by providing principles and an effective and efficient process and templates to enable the efficient and effective development of deliverables for the Standard Upper Ontology Working Group. 1.3. Intended Audience (editorial note: updated in this version) The intended audience for this document is the participants in the Standard Upper Ontology Working Group, who come from a wide range of disciplinary backgrounds, levels of professional experiences, and areas of expertise. 1.4. Scope This document applies to all deliverables of the Standard Upper Ontology Working Group that require approval by the Standard Upper Ontology Working Group. This includes: - Ontologies developed under the Standard Upper Ontology Working Group, - This document. This excludes: - Deliverables of other standards bodies, - Discussions on the Standard Upper Ontology Working Group e-mail lists. 1.5. Requirements (editorial note: added in this version) The requirements for this document are: 1. To provide a process for the development of Standard Upper Ontology Working Group project deliverables. 2. The process should be as simple as possible. 3. The documentation of the process should be clear and unambiguous. 4. The true status of project deliverables should be transparent. 5. The process should support the development of deliverables that are fit for their stated purpose and meet their stated requirements. 2. Fundamental Principles (editorial note: added in this version) The process defined in this document is based on the principles of Quality Management. A text on Quality Management is given in [2]. In Quality Management, quality is defined as being “fit for purpose”. If a deliverable is not fit for purpose then it should be possible to identify defects in the deliverable whose removal will improve the quality. Fit for purpose can be difficult to tie down, however, it does not mean gold plated, and it does not mean an 80% solution. Fit for purpose means 100% meeting agreed (stated) requirements. 3. Process 3.1. Stage 1 – Work Programme Approval In order to initiate the process of approving an activity for the Standard Upper Ontology Working Group, the proposers of the activity shall submit a motion to the Standard Upper Ontology Working Group defining the objectives of a Work Programme and including an outline of the deliverables of the Work Programme. This shall include at least: - A statement of the purpose of each deliverable, - The intended audience for each deliverable, - The requirements that each deliverable shall meet to be fit for purpose. The motion shall also include the nomination of a Work Programme Manager for the Work Programme. The motion may also include: - reference to initial material, or deliverable material for any later stages of the process. - the nomination of additional roles within the work programme, e.g. deliverable editor. If the motion is passed the Work Programme becomes an authorised part of the Standard Upper Ontology Working Group activity. The Standard Upper Ontology Working Group Chair shall maintain a publicly available a numbered list of motions that pass as resolutions of the Standard Upper Ontology Working Group. 3.2. Stage 2 – Draft Material Development Draft Material may be developed towards or in support of the Work Programme deliverables. The Work Programme Manager may circulate the Draft Material for comment at his discretion. No formal vote on this Draft Material is taken, but interested parties can raise formal issues (see definition in Annex 1) against it. It is good practice to develop and maintain a formal issues log, but at this stage it is not required. Anyone may raise formal issues by using the form in Annex A, and sending them to the Standard Upper Ontology Working Group e-mail list. The formal issue resolution process is defined below in Section 4. 3.3. Stage 3 – Draft Deliverable Proposal At their discretion the Work Programme Leader may submit material for approval as a Draft Deliverable. A formal vote of the Standard Upper Ontology Working Group is taken to determine approval. The following responses are allowed: - Abstain, - Yes, - Yes with comments, - No with comments, Comments are made as formal issues raised as described in Section 4. “Yes with comments” does not require the formal issues raised to be resolved before the document is accepted as a Deliverable. This is appropriate when there are editorial issues, or minor technical issues. “No with comments” means that the document is not considered fit for purpose as a deliverable, i.e. there are major technical issues that need to be resolved. It does not mean that the voter does not support the intent of the deliverable. That is decided when the Work Programme is approved. Following the result of the vote, if the majority of those voting, vote in favour, the document passes to the next stage. 3.4. Stage 4 – Deliverable Proposal The Work Programme team processes the formal issues raised as a result of the Draft Deliverable ballot and then the Work Programme Leader submits the document for a formal vote as a Deliverable. The voting is as for a Draft Deliverable. The Deliverable is passed if a majority vote “Yes” or “Yes with Comments”, but in the event that there are any “no with comments” votes, the Work Programme Leader should consider resolving the formal issues and resubmitting the document for a further vote. 3.5. Stage 5 – Revision A Deliverable may have formal issues raised against it. The Standard Upper Ontology Working Group Chair shall maintain a log of these Formal Issues. A Work Programme to resolve one or more formal issues against a Deliverable may be proposed. 4. Formal Issue Resolution Process To be valid, a formal issue shall identify a defect in the deliverable of the Standard Upper Ontology Working Group that detracts from the deliverable meeting its stated purpose. Where the deliverable is a document, examples of defects include: - a spelling or grammar error, - an untrue statement, - an unclear, ambiguous or misleading statement, - something missing that is necessary. Anyone may raise a formal issue against a Standard Upper Ontology Working Group deliverable. The form in Annex 2 shall be used, together with the instructions there for completion. The Work Programme shall maintain a log of formal issues raised against the deliverable for a deliverable that has reached Draft Deliverable level or beyond. The formal issue log shall be publicly available. (editorial note: added in this version) A formal issue is resolved when the Work Programme and the formal issue owner agree that it is. In the first place the issue owner is the person who raised the issue. However, it may happen that a formal issue owner is unable to follow the resolution of a formal issue he owns. In this case the Work Programme Leader shall seek a substitute formal issue owner. If no substitute formal issue owner can be found the formal issue shall be considered to be withdrawn. A formal issue is considered outstanding unless it is either completed or withdrawn. 5. References 5.1. Normative References [1] Project Authorisation Request for P1600.1, IEEE-SA, 2000 available from the internet 2003-11-19 http://suo.ieee.org/PAR.pdf 5.2. Bibliography [2] Dale, Barrie G. Managing Quality, Blackell Publishers, 2003 ISBN: 0631236147 Annex 1 Definitions (Normative) This annex provides definitions of terms that are important to this document or are used in a special or restricted sense in this document. The definitions given are those that shall be used in interpreting this document. Definitions are given as phrases that can be substituted for the term defined. The definitions are therefore not sentences, and do not start with a capital letter and definite or indefinite article or end with a full stop. Conformance agreeing or corresponding in character or qualities Note: Taken from the Oxford English Dictionary definition for congruous. Defect cause of failure of a deliverable to meet its purpose Definition precise statement of the essential nature of some thing Note: Taken from the Oxford English Dictionary. Deliverable formal product that is an objective of an approved Standard Upper Ontology Working Group Work Programme Example typical instance that illustrates a concept Note: Adapted from the Oxford English Dictionary. Formal Issue defect in a deliverable that has been identified and documented according to the procedures in this document Informative documentation that improves understanding, but to which conformance is not required Normative Documentation that sets out a standard or norm to which conformance may be required Principle general rule or law adopted as a guide to action Note: Taken from the Oxford English Dictionary. Purpose intended function Intended Audience those to whom the document is addressed and who need to understand it Term word or group of words expressing a notion Note: Taken from the Oxford English Dictionary. Annex 2 Formal issue Form (Normative) This annex defines the form that shall be used to document formal issues. Issue No: Formal issue Owner: Date Raised: Status: Formal issue level: Deliverable: Section: Title: Formal issue: Proposed Resolution (optional): Discussion: Agreed Resolution (Work Programme and formal issue raiser): Completion Date: Field Definitions (editorial note: added in this version) Issue No. identifying serial number for the issue Formal Issue Owner person who raises the formal issue, or in their absence has taken ownership of the formal issue Date Raised date on which the formal issue is submitted for consideration Status status representing progress in resolving the formal issue Allowed values are: Raised The formal issue has been raised, but the Work Programme has not yet responded to the formal issue. Accepted The formal issue has been accepted as valid by the Work Programme, but no resolution has been identified and agreed with the formal issue raiser. Rejected The formal issue has not been accepted by the Work Programme. A reason must be given. Withdrawn The formal issue has been withdrawn by the formal issue raiser. Resolved The resolution to the formal issue has been agreed in principle by the formal issue raiser and the Work Programme. The resolution is documented in the formal issue log, but has not yet been reflected in the document. Completed The resolution of the formal issue is reflected in the document to which it refers. Formal Issue Level significance of a defect with respect to the purpose of the deliverable A formal issue has an importance level that is one of the following values: Editorial A defect that does not affect the technical performance of the document and does not affect its comprehension. Examples include spelling, grammar, or layout. Minor Technical A defect that is technical in nature, but is easy to fix. Examples include errors in construction of formal language statements. Major Technical A defect where the scale and impact of the defect may require significant thought and work. Examples include axioms stated in such a way that they do not have the intended effect, and missing material. Deliverable name of the deliverable on which the issue is raised Section section number and other indication of where the issue occurs Title title for the issue Formal Issue statement of the issue This should identify the defect, and how it prevents the deliverable from meeting its purpose. Proposed Resolution proposed change to the deliverable that would eliminate the defect Discussion documentation of considerations that lead to a resolution Agreed Resolution action to be taken to resolve agreed between the Work Programme Leader for the deliverable and the Formal Issue Owner Completion Date date on which the Agreed Resolution is incorporated into the deliverable Responsibilities for Field Completion The issue raiser shall complete at least the following fields on submitting the issue: · Formal issue raiser · Date Raised · Formal issue level · Deliverable · Section · Title (of the issue) · Formal issue The issue raiser may optionally include a Proposed Resolution. The Work Programme Leader shall complete the following fields: · Issue No · Discussion (that leads the resolution of the issue) · Agreed Resolution · Completion Date, which is the date the resolution is implemented in the deliverable Annex 3 Documentation Requirements (Normative) Introduction This Annex presents minimum requirements that documents shall meet in order to facilitate their development. Required Contents Documents shall include the following contents: 1. Title, 2. Version, 3. Status (approval stage as defined in this document) 4. Editor name, 5. A copyright statement, 6. An introduction that includes: - Boilerplate text that explains that the Standard Upper Ontology Working Group under IEEE P1600.1 developed this deliverable, and the resolution number that approved the work programme, - The purpose, - The intended audience, - The requirements to be met. 7. References including: - Normative references (to standards whose provisions also form part of this deliverable), - Bibliography, 8. Annex 1 Definitions. Normative and Informative Text A standard may include normative and informative text. Sections in the body of the standard are normative except for: - Notes, introduced by the word “Note:” - Examples, introduced by the word “Example:” or “e.g.” Notes and examples may be numbered. In addition to sections in the body of the document, it may have Annexes. Annexes may be either normative or informative, and this shall be stated in the title of the annex.