SUO: SUOP Topic :> Current Draft Of Procedure Text
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
SUOPT :> CDOPT. Note 1
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
SUO WG, Procedure PL,
Toward a better synchronization of the namespaces and workspaces and
other spaces in my head with the working group webspace, and so that
I can keep better track of what has been covered and what not, I'll
place a copy of the "Current Draft Of Procedure Text" (CDOPT) here:
| Subj: SUO: Procedures Document Draft 3
| Date: Wed, 19 Nov 2003 11:17:01 -0000
| From: West, Matthew R SITI-ITPSIE <matthew.west@shell.com>
| To: Standard-Upper-Ontology <standard-upper-ontology@ieee.org>
|
| Dear Colleauges,
|
| Please find below a revised version of the Procedures Document.
|
| The main changes are:
| - adding a scope statement for the document
| - allowing anyone to raise formal issues
| - Adding the PAR as a normative reference
| - Adding an annex with definitions of some key terms
| - adding some explanation to the Formal Issue Form.
|
| Matthew West
| Principal Consultant
| Shell Information Technology International Limited
| Shell Centre, London SE1 7NA, United Kingdom
|
| Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
| Email: matthew.west@shell.com
| Internet: http://www.shell.com
|
| 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)
|
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o