SUO: Procedures Document Draft 4
Dear Colleagues,
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.
For those who just want to see additions and major updates,
these follow (editorial note: ...) inserts.
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 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.