Standard Upper Ontology Development Guidelines Version 1.0 D3 Status: Stage 2: Draft Material Editor: Matthew West 1. Introduction 1.1. Purpose The purpose of this document is to support the purpose of the Standard Upper Ontology Group, as stated in the Project Authorisation Request [1] by providing principles and lightweight procedures and templates to enable the efficient and effective development of deliverables for the Standard Upper Ontology Group. 1.2. Target Audience The target audience for this document is the participants in the Standard Upper Ontology Group, noting that they can come from a wide range of backgrounds with a wide range of (and lack of) knowledge and experience. 1.3. Scope (editorial note: Inserted in this version) This document applies to all deliverables of the Standard Upper Ontology Workgroup that require approval by the Standard Upper Ontology Workgroup. This includes: - Ontologies developed under the Standard Upper Ontology Workgroup, - This document. This excludes: - Deliverables of other standards bodies, - Discussions on the Standard Upper Ontology e-mail lists. 2. Process 2.1. Stage 1 - Activity Approval A proposal shall be submitted as a motion to the Standard Upper Ontology Group (SUO) defining the objectives of a Work Programme and include an outline of the deliverables of the Work Programme. The motion shall also include the nomination of a Project Manager for the Work Programme. The motion may include reference to initial material, or deliverable material for any later stages of the process. The motion may include the nomination of additional roles within the work programme, e.g. deliverable editor. If the motion is passed the Work Programme becomes a recognised part of the Standard Upper Ontology activity. 2.2. Stage 2 - Draft Material Development Draft Material may be developed towards or in support of the project deliverables. This may be circulated for comment at the discretion of the Project Manager. No formal vote on this Draft Material is taken, but interested parties can raise formal issues against it. It is good practice to develop and maintain a formal issues log, but at this stage it is not required. Formal issues shall be raised using the pro-forma in Annex A, and sent to the SUO list. The formal issue resolution process is defined below in Clause 3. 2.3. Stage 3 - Draft Standard Proposal When the project is satisfied that they have the material in a form that constitutes a technically complete Standard, they may propose it as a Draft Standard. A formal vote is taken. The following responses are allowed: - Abstain - Yes - Yes with comments - No with comments Comments are made as formal issues raised as described in Section 3. "Yes with comments" does not require the formal issues raised to be resolved before the document is accepted as a Standard. This might be appropriate when there are editorial issues, or perhaps minor technical issues. "No with comments" means that the document is not considered fit for purpose as a standard, 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 standard. 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 may pass to the next stage. 2.4. Stage 4 - Standard Proposal The project should attempt to resolve any formal issues raised as a result of the Draft Standard ballot and then when the Project Leader is satisfied that as many formal issues as possible have been resolved, then the document can be submitted for vote as a Standard. The voting is as for a Draft Standard. The standard is passed if a majority vote for it, but in the event that there are any "no with comments" votes, the Project Leader should consider resolving the formal issues and resubmitting the document for a further vote. 2.5. Stage 5 - Revision A Standard may have formal issues raised against it. A log of these formal issues shall be maintained by the SUO Chair. A Project to resolve one or more formal issues against a Standard may be proposed. 3. Formal Issue Resolution Process To be valid, a formal issue shall identify a defect in the deliverable of the Standard Upper Ontology 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. (editorial note: changed in this version.) Anyone may raise a formal issue against a Standard Upper Ontology Working Group 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. The project shall maintain a log of formal issues raised against the deliverable for a deliverable that has reached Draft Standard level or beyond. The formal issue log shall be publicly available. A formal issue is resolved when the project and the issue raiser agree that it is. The status of a formal issue has one of the following values: Raised The formal issue has been raised, but the project has not yet responded to the formal issue. Accepted The formal issue has been accepted as valid by the project, but no resolution has been identified and agreed with the formal issue raiser. Rejected The formal issue has not been accepted by the Project. 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 project. 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. A formal issue is considered outstanding unless it is either completed or withdrawn. 4. Normative References (editorial note: added in this version) [1] Project Authorisation Request for P1600.1, IEEE-SA, 2000 available from the internet 2003-11-19 http://suo.ieee.org/PAR.pdf 5. Bibliography Annex 1 Definitions (Normative) (editorial note: added in this version) 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 of an approved Standard Upper Ontology Workgroup project Example typical instance that illustrates a concept Note: Adapted from the Oxford English Dictionary. Formal Issue documentation of a defect identified in a deliverable of the Standard Upper Ontology Workgroup 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 Target 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 Pro Forma (Normative) (editorial note: initial text added in this version) This annex defines the form that shall be used to document formal issues. The issue raiser shall complete at least the following fields on submitting the issue: - Formal issue raiser - Date Raised - Formal issue level - Deliverable - Clause - Title (of the issue) - Formal issue The issue raiser may optionally include a Proposed Resolution. The Project 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 Issue No: Formal issue Raiser: Date Raised: Status: Formal issue level: Deliverable: Clause: Title: Formal issue: Proposed Resolution (optional): Discussion: Agreed Resolution (project and formal issue raiser): Completion Date: Annex 3 Document Requirements (Normative)