2004-01-10 Page 12 of 12 Standard Upper Ontology Working Group Development Guidelines Version 1.0 D6 Status: Stage 2: Draft Material Date: 2004-01-10 Editor: Matthew West Copyright © 2004 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 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] ISO 9000:2000, Quality management systems — Fundamentals and vocabulary [4] ISO/IEC Directives, Part 2, 2001 [5] ISO/IEC Guide 2, 1996 3 Definitions This clause 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 Defect non-fulfilment of a requirement (3.10.1) related to an intended or specified use [ISO 9000:2000, definition 3.6.3] 3.2 Definition precise statement of the essential nature of some thing Note: Taken from the Oxford English Dictionary. 3.3 Deliverable formal product of work approved by a resolution of the Standard Upper Ontology Working Group 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.4 Example typical instance that illustrates a concept Note: Adapted from the Oxford English Dictionary. 3.5 Formal Issue alleged defect in a deliverable that has been identified and documented according to the procedures in this document 3.6 Informative Elements documentation that improves understanding, but to which conformance is not required [ISO/IEC Directives, Part 2, 2001, definition 3.7] 3.6.1 preliminary elements elements that identify the document, introduce its content and explain its background, its development and its relationship with other documents [ISO/IEC Directives, Part 2, 2001, definition 3.7.1] 3.6.2 supplementary elements elements that provide additional information intended to assist the understanding or use of the document [ISO/IEC Directives, Part 2, 2001, definition 3.7.2] 3.6.3 required element element the presence of which in a document is obligatory [ISO/IEC Directives, Part 2, 2001, definition 3.7.3] 3.6.4 optional element element the presence of which in a document is dependent on the provisions of the particular document [ISO/IEC Directives, Part 2, 2001, definition 3.7.4] 3.7 Intended Audience those to whom the document is addressed and who need to understand it 3.8 Normative Elements elements that describe the scope of the document, and which set out provisions [ISO/IEC Directives, Part 2, 2001, definition 3.6] 3.9 Principle general rule or law adopted as a guide to action Note: Taken from the Oxford English Dictionary. 3.10 Provisions 3.10.1 Requirement (expressed in a standard) expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted [ISO/IEC Directives, Part 2, 2001, definition 3.10.1] 3.10.2 recommendation expression in the content of a document conveying that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited [ISO/IEC Directives, Part 2, 2001, definition 3.10.1] 3.10.3 statement expression in the content of a document conveying information [ISO/IEC Directives, Part 2, 2001, definition 3.10.1] 3.11 Purpose intended function 3.12 Requirement (of the deliverable, rather than in it) need or expectation that is stated, generally implied or obligatory NOTE 1 “Generally implied” means that it is custom or common practice that the need or expectation under consideration is implied. NOTE 2 A qualifier can be used to denote a specific type of requirement, e.g. product requirement, quality management requirement, customer requirement. NOTE 3 A specified requirement is one which is stated, for example, in a document. NOTE 4 Requirements can be generated by different interested parties. [ISO 9000:2000, definition 3.1.2] 3.13 Standard document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context NOTE Standards should be based on the consolidated results of science, technology and experience, and aimed at the promotion of optimum community benefits. [ISO/IEC Guide 2:1996, definition 3.2] 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 [1]. This document defines a very basic Quality Management System as defined in ISO 9000 [3]. 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 All voting shall be undertaken through the process of proposing and voting on a motion. The counting of votes shall be by whatever process is determined for the passing of motions in the SUO WG from time to time. When a vote is not passed, the stage shall be repeated or the work terminated. 5.1 Stage 1 –Approval In order to initiate the process of approving work towards developing the Standard Upper Ontology, the proposers shall submit a motion to the Standard Upper Ontology Working Group defining the objectives of the work and including an outline of the deliverables. This motion shall include at least: - The objective of the work, - 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 Manager for the work. The motion may also include: - reference to initial material, or deliverable material for any later stages of the process. - the nomination of additional roles to perform the work, e.g. deliverable editor. If the motion is passed the work becomes authorised by the Standard Upper Ontology Working Group. Note: The motions for existing starter documents are considered here to be Approval motions. 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 deliverables. The Manager may circulate the Draft Material for comment at his discretion. No formal vote on this Draft Material is taken, but interested parties can make informal comments or raise formal issues (see definition in 3) against it. A log of issues raised formally shall be kept by the manager. Note: The work that has been done on developing existing starter documents is considered in this document to fall within this stage. 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 permitted: - 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 Manager should consider resolving the formal issues and resubmitting the document for a further vote. If the deliverable is a draft standard, then at this stage it is submitted to the IEEE SA for their consideration. 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 or passage, - 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 Manager shall maintain a log of formal issues raised against the deliverable. The formal issue log shall be publicly available. A formal issue is resolved when the Manager 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 Manager 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. Bibliography [1] Dale, Barrie G. Managing Quality, Blackwell Publishers, 2003 ISBN: 0631236147 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 not yet responded to. Accepted The formal issue has been accepted as valid, but no resolution has been identified and agreed with the formal issue raiser/owner. Rejected The formal issue has not been accepted. A reason must be given. Withdrawn The formal issue has been withdrawn by the formal issue raiser/owner. Resolved The resolution to the formal issue has been agreed in principle with the formal issue raiser. The resolution is documented in the formal issue log, but has not yet been reflected in the deliverable. Completed The resolution of the formal issue is reflected in the deliverable to which it refers. Created by the Manager. 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 has a small impact on the deliverable meeting its purpose. Major Technical A defect where the scale and impact of the defect mean that the deliverable will not be able to meet its purpose without the defect being remedied. 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 Example: Examples of “other indication” include figure number, note number, example number and paragraph number. 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 Manager. Agreed Resolution action to be taken to resolve agreed between the Manager for the deliverable and the Formal Issue Owner Created by the Manager. Completion Date date on which the Agreed Resolution is incorporated into the deliverable Created by Manager. 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 Elements A standard may include normative and informative elements in Clauses and Annexes. It shall be clearly indicated which Clauses and Annexes are normative and which informative. Informative material in normative Clauses or annexes may be included through: - Notes, introduced by the word “Note:” - Examples, introduced by the word “Example:” or “e.g.” Notes and examples may be numbered.