SUO: Re: SUOP Topic :> Current Draft Of Procedure Text
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
SUOPT :> CDOPT. Note 4
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
In: SUOPT :> CDOPT. http://suo.ieee.org/email/thrd3.html#11706
Re: SUO Procedures Document Draft 4 (24 Nov 2003):
MW: http://suo.ieee.org/email/msg11808.html
Matthew,
I am storing my working copy of your current Procedure draft here.
I'll be trying to put some of your definitions, if you will excuse
the phrase, not to mention forgive my illusions about their utility
for clearing up confusions from time to time, along with my remarks,
in due course, at locations in the linked dynamic data structure that
I am building in the Archive. I am doing this partly for the purpose
of trying to reuse those things we write, especially those pieces that
we are blessed to settle on, and that therefore remain more invariant,
in other words, less transient, from time to time. This type of reuse
strategy is intended to help us keep from repeating ourselves needlessly,
and thus if it must be heedlessly, then at least the virtual repetition
via links will be more efficient, if not yet to say any more effective.
Jon Awbrey
MW: My intent was to publish a draft about once a week until some sort of
stability was reached, but I am away at a conference the next few days,
and thanks to Jon's constructive criticism there have been quite a few
updates to make. So this one comes early.
MW: For those who just want to see additions and major
updates, these follow (editorial note: ...) inserts.
| Standard Upper Ontology Working Group Development
| Guidelines
| Version 1.0 D4
| Status: Stage 2: Draft Material
| Editor: Matthew West
|
| 1. Introduction
| (editorial note: added in this version)
| 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. Copyright
| (editorial note: added in this version)
| The copyright of this document is vested in the IEEE. The
| document may be copied on whole or in part, but no charge
| may be made for it.
|
| 1.2. 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 Normative
| References [1] by providing principles and an effective
| and efficient process and templates to enable the
| efficient and effective development of deliverables for
| the Standard Upper Ontology Working Group.
|
| 1.3. Intended Audience
| (editorial note: updated in this version)
| The intended audience for this document is the
| participants 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.4. 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.5. Requirements
| (editorial note: added in this version)
| 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 are fit for their stated purpose and
| meet their stated requirements.
|
| 2. Fundamental Principles
| (editorial note: added in this version)
| The process defined in this document is based on the
| principles of Quality Management. A text on Quality
| Management is given in [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.
| Fit for purpose can be difficult to tie down, however, it
| does not mean gold plated, and it does not mean an 80%
| solution. Fit for purpose means 100% meeting agreed
| (stated) requirements.
|
| 3. Process
|
| 3.1. Stage 1 - Work Programme Approval
| In order to initiate the process of approving an activity
| for the Standard Upper Ontology Working Group, the
| proposers of the activity 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 shall include at least:
| - 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 an
| authorised part of the Standard Upper Ontology Working
| Group activity.
| The Standard Upper Ontology Working Group Chair shall
| maintain a publicly available a numbered list of motions
| that pass as resolutions of the Standard Upper Ontology
| Working Group.
|
| 3.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 Annex 1) 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 Section 4.
|
| 3.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
| taken 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
| Section 4.
| "Yes with comments" does not require the formal issues
| 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 passes to the
| next stage.
|
| 3.4. Stage 4 - Deliverable Proposal
| The Work Programme team processes the formal issues
| raised as a result of the Draft Deliverable ballot and
| then the Work Programme Leader submits the document for a
| formal vote 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.
|
| 3.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.
|
| 4. Formal Issue Resolution Process
| To be valid, a formal issue shall identify a defect in
| the 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 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.
| (editorial note: added in this version)
| 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.
|
| 5. References
|
| 5.1. Normative References
| [1] Project Authorisation Request for P1600.1, IEEE-SA,
| 2000 available from the internet 2003-11-19
| http://suo.ieee.org/PAR.pdf
|
| 5.2. Bibliography
| [2] Dale, Barrie G. Managing Quality, Blackell
| Publishers, 2003 ISBN: 0631236147
|
| Annex 1
|
| Definitions (Normative)
| 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 that is an objective of an approved
| Standard Upper Ontology Working Group Work Programme
|
| Example
| typical instance that illustrates a concept
| Note: Adapted from the Oxford English Dictionary.
|
| Formal Issue
| defect in a deliverable that has been identified and
| documented according to the procedures in this document
|
| 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
|
| Intended 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 Form (Normative)
| This annex defines the form that shall be used to
| document formal issues.
|
| Issue No:
| Formal issue Owner:
| Date Raised:
| Status:
| Formal issue level:
| Deliverable:
| Section:
| Title:
| Formal issue:
|
| Proposed Resolution (optional):
|
| Discussion:
|
| Agreed Resolution (Work Programme and formal issue
| raiser):
|
| Completion Date:
|
| Field Definitions
| (editorial note: added in this version)
|
| Issue No.
| identifying serial number for the issue
|
| Formal Issue Owner
| person who raises the formal issue, or in their absence
| has taken ownership of the formal issue
|
| Date Raised
| date on which the formal issue is submitted for
| consideration
|
| 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.
|
| 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.
|
| Deliverable
| name of the deliverable on which the issue is raised
|
| Section
| section number and other indication of where the issue
| occurs
|
| Title
| title for the issue
|
| Formal Issue
| statement of the issue
| This should identify the defect, and how it prevents the
| deliverable from meeting its purpose.
|
| Proposed Resolution
| proposed change to the deliverable that would eliminate
| the defect
|
| Discussion
| documentation of considerations that lead to a resolution
|
| Agreed Resolution
| action to be taken to resolve agreed between the Work
| Programme Leader for the deliverable and the Formal Issue
| Owner
|
| Completion Date
| date on which the Agreed Resolution is incorporated into
| the deliverable
|
| Responsibilities for Field Completion
| The issue raiser shall complete at least the following
| fields on submitting the issue:
| · Formal issue raiser
| · Date Raised
| · Formal issue level
| · Deliverable
| · Section
| · Title (of the issue)
| · Formal issue
| The issue raiser may optionally include a Proposed
| Resolution.
| The Work Programme 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
|
| Annex 3
|
| Documentation Requirements (Normative)
|
| Introduction
| This Annex presents minimum requirements that documents
| shall meet in order to facilitate their development.
|
| 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 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.
| 7. References including:
| - Normative references (to standards whose provisions
| also form part of this deliverable),
| - Bibliography,
| 8. Annex 1 Definitions.
|
| Normative and Informative Text
| A standard may include normative and informative text.
| Sections 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 sections 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.
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o