Standard Upper Ontology Development Guidelines Version 1.0 D2 Editor: Matthew West 1. Introduction (editorial note: this section replaced with recently submitted text) 1.1. Purpose The purpose of this document is to support the purpose of the Standard Upper Ontology Group 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 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. 2. Process (editorial note: numbering of stages changed) 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 (editorial note: Following paragraph inserted to clarify what is a valid formal issue, “issue” qualified to be “formal issue” throughout the document.) 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. Any voting member of the Standard Upper Ontology Group may raise a formal issue against a document. (editorial note: This is under discussion.) 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 understandability. 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. Annex 1 Formal issue Pro Forma Formal issue Raiser: Date Raised: Status: Formal issue level: Title: Clause: Formal issue: Proposed Resolution (optional): Discussion: Agreed Resolution (project and formal issue raiser): Completion Date: