SUO: RE: Procedures Document Draft 3
Dear Tom,
See comments below.
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
> -----Original Message-----
> From: Tom Johnston [mailto:tjohnston@acm.org]
> Sent: 21 November 2003 19:03
> To: West, Matthew R SITI-ITPSIE; Standard-Upper-Ontology (E-mail)
> Subject: RE: Procedures Document Draft 3
>
>
> Matthew:
>
> see below, marked "TJ".
>
> -----Original Message-----
> From: owner-standard-upper-ontology@majordomo.ieee.org
> [mailto:owner-standard-upper-ontology@majordomo.ieee.org]On Behalf Of
> West, Matthew R SITI-ITPSIE
> Sent: Wednesday, November 19, 2003 6:17 AM
> To: Standard-Upper-Ontology (E-mail)
> Subject: SUO: Procedures Document Draft 3
>
>
>
> 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.
>
> TJ: I like it. (I'm not yet a voting member, you know!)
MW: I didn't, but I think it is important to recognise the
diversity of this group, and this should be relevant even
for those that see themselves as external observers.
>
> 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.
>
> TJ: are the only projects envisaged ones that produce standards?
> (And here ("standards") is a term I think it would be useful
> to define.)
MW: I guess you could apply this process to the SUO Purpose and
one or two other things that might not be considered standards.
This was how I lighted on the word "deliverable" in other places.
At some poit I guess I am going to get consistent.
>
> 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)
>
>
> TJ: nice work, Matthew. Thank you.
MW: Thanks. I think there is one more draft before I move to the
next stage.
>
>
>
>