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

SUO: RE: Re: Standard Upper Ontology Procedures




Dear Jon,

I nearly answered this as an implied question earlier.

The purpose of the Procedures document should support the overall
purpose of the SUO (as indeed should the purpose of all top level
documents/deliverables).

This might be demonstrated by the purpose for the procedures
commencing:

This procedures document supports the purpose of the SUO by ...

This would indicate the subordination, and allow the check that 
the purpose was indeed supportive.

I am trying to be lightweight still, or else I might suggest we
really do things properly and get into:

Mission, Vision, Objectives, Strategy, Critical Success Factors,
Risks, Key Performance Indicators, Plans and Tasks and all that 
proper management stuff. (The current Purpose for the SUO would 
probably match the Mission here).

We might get into that sometime, but in any case we need the
procedures document as a bootstrap even for that.


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: 13 November 2003 15:15
> To: SUO
> Subject: SUO: Re: Standard Upper Ontology Procedures
> 
> 
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
> SUOP.  Note 5
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
> JA = Jon Awbrey
> MW = Matthew West
> 
> Matthew,
> 
> Let me review the last few exchanges a little more carefully,
> as the evidently anti-4D behavior of the SUO reflector, plus
> a storm and a power loss at the receiving end, have slightly
> scrambled my thoughts on the matter.
> 
> MW: We need to start work on the procedures document.
>     The process I intend to apply is one we use in
>     the part of Shell that I am in:
> 
> MW: 1.  I will define a purpose and target audience for
>         the document, together with a table of contents.
> 
> MW: 2.  These are reviewed and amended, informally
>         if we can make that work, but more formally
>         (raising formal issues) if we run into problems.
> 
> MW: 3.  I (and possibly others) will fill in the blanks.
>         It may not be appropriate to attempt a full draft
>         before a first review because of dependencies,
>         but we will see.
> 
> MW: 4.  Review draft document and amend,
>         informally where possible, formally
>         when that doesn't work.
> 
> MW: 5.  Repeat 3 & 4 until we have reached consensus,
>         or a point where a vote is necessary to resolve
>         any issues.
> 
> MW: 6.  I will propose a motion for acceptance of the document.
> 
> MW: 7.  The document becomes subject to its own
>         provisions for revision and improvement.
> 
> MW: Any comments?  (silence is taken as consent).
> 
> JA: We already have a Scope and Purpose Document,
>     worked out after many grueling months of BST&T,
>     and each time I read it I like it more and more --
>     I learned in Psych somewhere that this effect is
>     a prediction of Cognitive Dissonance Theory, given
>     the fact that I got no remuneration for the BST&T.
> 
> JA: So I think that what we need is a Procedures Guideline.
>     And I suggest that we start in stepwise refinement mode,
>     beginning with the broadest principles that all members
>     of the working group would rationally adopt as maxims
>     for their conduct, only when settlement is achieved
>     on these grander scores descending a step closer
>     toward the brass tacks.
> 
> MW: I do not mean a purpose for SUO, but for the procedures 
> document itself.
>     The purpose gives you a basis against which to check the 
> content to see
>     that it meets the purpose (or else of course you can 
> change the purpose
>     to match the document).  Similarly, the Target Audience 
> (SUO members I
>     guess) means that you can establish some (if any) common 
> context which
>     should impact the language.
> 
> JA: Fair enough, but I should have thought
>     that "more perfect co-product" would
>     just about cover it.  The Quod to be
>     Demonstrated is that there is a clear
>     relationshiop between the Purpose set
>     and the Procedures to be developed.
> 
> Okay.  Let me try to think this through.
> 
> Varieties of Purpose.
> 
>   1.  There is the purpose of the SUO Working Group (SUO WG),
>       as stated in SUO PAR or SUO Scope and Purpose (SUOPAR).
>       Water under the bridge.  2-gones.  Subject to amendment.
> 
>   2.  There is the purpose of the SUO Procedures document (SUOP).
>       To be determined.  To be announced.  In the fullness of time.
> 
> Question.  What is the proper relationship of the SUOP to SUOPAR?
> 
> Now, purposes are one of those things that pragmatic thinkers
> tend to think about, a lot, so I know that I must have some
> pertinent pragmatic thoughts about this precise problem
> packed away somewhere.
> 
> At first sight, this seems to demand some sort of ordering,
> involving either enabling purposes, metagoals, or subgoals:
> 
>   1.  Control ordering.  Monitory oversight hierarchy.
> 
>   2.  Purpose ordering.  Goal hierarchy.
> 
>   3.  Precendent order.  Step number.
> 
> Questions about Goals and Purposes.
> 
>   1.  Closure under Meta.
> 
>       1.1.  Is a goal of a goal a goal?
> 
>       1.2.  Is a purpose of a purpose a purpose?      
> 
>   2.  Transitivity under Sub.
> 
>       2.1.  Does the subprocedure have the
>             same goal as the superprocedure?
> 
>       2.2.  Does the procedure document for project X
>             have the same purpose as project X itself?
> 
> Those are some of the initial Issues that I suggest we need 
> to think about.
> 
> Jon Awbrey
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
>