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




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.

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.

| 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.

| 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.

| 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.

| 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.

| 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.

| 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?

| 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.

| 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?

| 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