Standard Upper Ontology Working Group Development Guidelines Version 1.0 D5 Status: Stage 2: Draft Material Date: 2003-12-08 Editor: Matthew West Copyright © 2003 by the Institute of Electrical and Electronics Engineers, Inc. Three Park Avenue New York, NY 10016-5997, USA All rights reserved. This document is an unapproved draft of a proposed IEEE Standard Working Group procedure. As such, this document is subject to change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only. Prior to submitting this document to another standards development organization for standardization activities, permission must first be obtained from the Manager, Standards Licensing and Contracts, IEEE Standards Activities Department. Other entities seeking permission to reproduce this document, in whole or in part, must obtain permission from the Manager, Standards Licensing and Contracts, IEEE Standards Activities Department IEEE Standards Activities Department Standards Licensing and Contracts 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA 1. Overview 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. 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 References [1] by providing principles, a process, and templates to enable the efficient and effective development of deliverables for the Standard Upper Ontology Working Group. 1.2. Intended Audience The intended audience for this document is those who participate 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.3. 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.4. Requirements 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 meet their stated requirements. 2. References [1] Project Authorisation Request for P1600.1, IEEE-SA, 2000 available from the internet 2003-11-19 http://suo.ieee.org/PAR.pdf [2] IEEE Standards Style Manual, IEEE-SA, 2000 available from the internet 2003-12-10 http://standards.ieee.org/guides/style/2000Style.pdf 3. Definitions 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. 3.1. Conformance agreeing or corresponding in character or qualities Note: Taken from the Oxford English Dictionary definition for congruous. 3.2. Defect cause of failure of a deliverable to meet its purpose 3.3. Definition precise statement of the essential nature of some thing Note: Taken from the Oxford English Dictionary. 3.4. Deliverable formal product that is an objective of an approved Standard Upper Ontology Working Group Work Programme Note: This may include Draft Standards for approval by the IEEE Standards Authority, work towards such standards, or internal documents for the SUO WG, e.g. this document. 3.5. Example typical instance that illustrates a concept Note: Adapted from the Oxford English Dictionary. 3.6. Formal Issue alleged defect in a deliverable that has been identified and documented according to the procedures in this document 3.7. Informative documentation that improves understanding, but to which conformance is not required 3.8. Normative Documentation that sets out a standard or norm to which conformance may be required 3.9. Principle general rule or law adopted as a guide to action Note: Taken from the Oxford English Dictionary. 3.10. Purpose intended function 3.11. Intended Audience those to whom the document is addressed and who need to understand it 3.12. Term word or group of words expressing a notion Note: Taken from the Oxford English Dictionary. 4. Fundamental Principles The process defined in this document is based on the principles of Quality Management. A text on Quality Management is given in the Bibliography [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. The phrase 'fit for purpose' can lead to differences in interpretation. For the purposes of deliverables covered by these guidelines a deliverable shall be considered 'fit for purpose' if and only if it satisfies each and every stated and agreed requirement placed upon it. 5. Process 5.1. Stage 1 – Work Programme Approval In order to initiate the process of approving a Work Programme for the Standard Upper Ontology Working Group, the proposers of the Work Programme 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 motion shall include at least: - The objective of the Work Programme, - 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 authorised by the Standard Upper Ontology Working Group. The Standard Upper Ontology Working Group Chair shall maintain a publicly available and numbered list of motions that pass as resolutions of the Standard Upper Ontology Working Group. 5.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 3) 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 Clause 6. 5.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 undertaken 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 Clause 6. “Yes with comments” does not require the formal issues that have been 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 is recognised as a Draft Deliverable and passes to the next stage. 5.4. Stage 4 – Deliverable Proposal The Work Programme team processes the formal issues that have been `raised as a result of the Draft Deliverable ballot and then the Work Programme Leader submits the document for a formal vote to be recognised 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. 5.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. 6. Formal Issue Resolution Process To be valid, a formal issue shall identify a defect in a 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 accompanying 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. 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. Annex 1 Bibliography [3] Dale, Barrie G. Managing Quality, Blackell Publishers, 2003 ISBN: 0631236147 Annex 2 Formal issue Form (Normative) This annex defines the form that shall be used to document formal issues. Issue No: Formal issue Creator: Formal issue Owner: (if different from creator) Date Raised: Status: Formal issue level: Deliverable: Clause: Title: Formal issue: Proposed Resolution (optional): Discussion: Agreed Resolution (Work Programme and formal issue raiser): Completion Date: Field Definitions and Responsibilities Issue No. identifying serial number for the issue Created by Work Programme Leader. Formal Issue Creator person who raises the formal issue Created by Issue Creator. Formal Issue Owner person who has taken ownership of the formal issue in the absence of the creator. Created by Work Programme Leader. Date Raised date on which the formal issue is submitted for consideration Created by Issue Creator. 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. Created by Work Programme Leader. 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. Created by Issue Creator. Deliverable name of the deliverable on which the issue is raised Created by Issue Creator. Clause clause number and other indication of where the issue occurs Created by Issue Creator. Title title for the issue Created by Issue Creator. Formal Issue statement of the issue This should identify the defect, and how it prevents the deliverable from meeting its purpose. Created by Issue Creator. Proposed Resolution proposed change to the deliverable that would eliminate the defect Created by Issue Creator. Discussion documentation of considerations that lead to a resolution Created by Work Programme Leader. Agreed Resolution action to be taken to resolve agreed between the Work Programme Leader for the deliverable and the Formal Issue Owner Created by Work Programme Leader. Completion Date date on which the Agreed Resolution is incorporated into the deliverable Created by Work Programme Leader. Annex 3 Documentation Requirements (Normative) Introduction This Annex presents minimum requirements that documents shall meet in order to facilitate their development. Draft Standards should conform to the “IEEE Standards Style Manual” [2]. 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 overview 7. 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 by the deliverable. 8. Normative references (to standards whose provisions also form part of this deliverable), 9. Bibliography. Normative and Informative Text A standard may include normative and informative text. Clauses 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 Clauses 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.