SUO: Procedures Document Draft 2
Dear Colleagues,
Please find below a revised version of the procedures document
with some responses to some of the initial comments made. I have:
- Included the purpose and Target Audience
- Qualified "issue" to "formal issue" to try to make the restricted
sense intended clearer
- Added a few words to define what makes an issue a formal issue
- Revised the stage numbering
- added editorial notes to try to highlight the changes.
Doubtless I have missed some things, but I'm sure Jon will remind me.
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 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: