Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

SUO: RE: SUOP Topic :> Current Draft Of Procedure Text




Dear Jon,

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: Jon Awbrey [mailto:jawbrey@att.net]
> Sent: 23 November 2003 03:58
> To: SUO; West, Matthew R SITI-ITPSIE
> Subject: Re: SUOP Topic :> Current Draft Of Procedure Text
> 
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
> SUOPT :> CDOPT.  Note 2
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
> SUOPT :> CDOPT.  http://suo.ieee.org/email/thrd2.html#11706
> 
> Referring to "SUO Procedures Document Draft 3" (19 Nov 2003):
> 
> SUOPT :> CDOPT 01.  http://suo.ieee.org/email/msg11706.html
> 
> Matthew,
> 
> I am going to look for ways to chunk this draft into smaller pieces --
> to "modularize" it if we need a fancier name -- and maybe eventually
> work out a version tracking system for the more independent sections,
> so we don't have to keep reading through the whole text each time we
> make a change.

MW: Well in case you hadn't guessed I am maintaining a master Document
in MS Word, and as I identify improvements I can make from the various
discussions, I amend this document. I am issuing a new draft about once 
per week at the moment, with editorial notes to guide where the most
significant changes occur. This gives people a chance to see whether or
not I have been listening to their comments or missed/ignored them.

MW: I am hoping we are 1-2 drafts away from something that is worth
an initial vote on, but we will see.
> 
> I'll first read through the whole text just
> for small stuff and informational questions.
> I haven't had a chance to go through Tom's
> comments or your replies to them as of yet.
> 
> |      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.
> 
> "lightweight" is awk, colloq, or needs further explanation.
> 
> "effective and efficient" is the more logical order, from
> the general theoretical case to the special pragmatic case.

MW: Agree. Changed.
> 
> | 1.2. Target Audience
> 
> I suggest "Intended Audience".  You don't want to give your audience
> the impression that you intend to institute hostilities against them,
> especially if you are.

MW: Well I've used Target Audience for 15 years without objection, but
I have no problem with Intended Audience. So changed.
> 
> | 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.
> 
> This is where the "instituting hostilities" part seems to come in.
> 
> Maybe try:
> 
> > The intended audience of this document is the participants of
> > the IEEE Standard Upper Ontology [Working? Study?] Group, who
> > come from a wide range of disciplinary backgrounds, levels of
> > professional experiences, and areas of expertise.

MW: I make it Working Group, otherwise agreed and done.
> 
> | 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.
> 
> SUOW is bad acronym.  Suggest we stick with SUO SG or SUO WG.

MW: As above, from the PAR it looks like the correct name is Standard
Upper Ontology Working Group, so SUO WG, but you will notice I have
avoided using acronyms.
> 
> | 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.
> 
> Sounds like an non-contingent rule.
> Need to distinguish SUO and SUO WG.
> Unnecessary passivism.
> 
> > In order to initiate the process of approving an activity for the
> > Standard Upper Ontology Working Group, henceforward SUO WG, the
> > proposers of the activity shall submitt a motion to the SUO WG
> > defining the objectives of a Work Programme and including an
> > outline of the deliverables of the Work Programme.

MW: OK, but I'm not using the acronym in the document. I will follow
by using Work Programme throughout rather than Project.
> 
> | 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.
> 
> "recognized" is now a technical term lacking any operational or
> procedural definition at this point.  "formally recognized" has
> the same property, messing up the freedom to use "recognize" and
> "formal" in, er, non-official capacities.  perhaps the use of a
> rare word like "sanctioned" plus the inclusion of a definition,
> er, gloss.

MW: how about a quite ordinary word like "authorised" that has a pretty
clear meaning. I'm changing it to that contingently.
> 
> | 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 [may] raise formal issues against it.
> 
> excessive passivism again.  'who' may circulate and develop this?

MW: I will reword.
> 
> | 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.
> 
> agressive passivism again.  'who' shall raise formal issues?
> why do you say "pro-forma".  makes it sound perfunctory.

MW: Changed to form.
> 
> | 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.
> 
> who is "project"?  the abovesaid proposers?
> how do we know if they are satisfied or not?
> would it make any difference to the process
> if they propose a Draft Standard that they
> were not satisfied with, but just didn't
> tell anybody that?

MW: OK, so how about simply "At their descretion the Work Programme Leader
may submit material for approval as a Draft Deliverable."

MW: I will make this change.
> 
> | 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.
> 
> I will break here for now.
> 
> Jon Awbrey
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
>