SUO: RE: Standard Upper Ontology Procedures
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: 14 November 2003 02:14
> To: SUO
> Cc: West, Matthew R SITI-ITPSIE
> Subject: Re: Standard Upper Ontology Procedures
>
>
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
>
> SUOP. Note 13
>
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
>
> JA = Jon Awbrey
> MW = Matthew West
>
> JA: SUOP 05. http://suo.ieee.org/email/msg11596.html
>
> MW: I nearly answered this as an implied question earlier.
>
> MW: 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).
>
> MW: This might be demonstrated by the purpose for the
> procedures commencing:
>
> MW: "This procedures document supports the purpose of the SUO by ..."
>
> "The SUOP supports the SUOPAR purpose by ..."
>
> Sounds like a good start. I suggest that we spend some time thinking
> about the nature of the intended support relation, X supports Y by Z.
> Surprise, surprise, it's 3-adic.
>
> But I wonder if this is properly called "subordination"?
> After all, which document is boss of which? Which doc
> can hire and fire which?
>
> MW: This would indicate the subordination, and allow
> the check that the purpose was indeed supportive.
>
> MW: I am trying to be lightweight still, or else I might
> suggest we really do things properly and get into:
>
> MW: 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).
>
> Sounds like worthy subjects for discussion.
> And I think the days for bantam bandying
> of lighter words are probably behind us.
>
> MW: We might get into that sometime, but in any case we need
> the procedures document as a bootstrap even for that.
>
> Matthew,
>
> Let me now make a concrete proposal:
>
> Let us develop the SUO Procedure Doc in group, online, the way
> that we did the SUO Scope and Purpose, that went to make up the
> SUO PAR. Wear the mantle of your leadership lightly, then, and
> commit to servant-lead more as a catalyst or a facilitator than
> "yet another manifesto author" (YAMA). After all, that's my job.
> The last thing that the SUO WG needs at this point is yet another
> small subcommittee retreating to some clositer to achieve among
> their company what anthropologists call a "separate consensus",
> in effect, a condition of collective mentality indiscernible
> from the hermeneutically sealed contentments of a tight knit
> cabal's mutually admiring hallucinations. No more of these
> documents that authors fall so in love with that no amount
> of petard hoisting will shake them from their devotions.
MW: I thought we were already doing this ...
>
> You may log that as an Issue.
MW: Well as I expect you realise it isn't an issue. An issue
can only be raised against a deliverable and identifies a defect in
it, it is about a state or outcome, not a process. What you have is
a proposal for a process. Technically we should not care too much
about the development approach, just as long as the outcome is fit
for purpose.
MW: I wouldn't labour this, but getting into the right way of
defining issues is part of what helps to make the quality process
work.
>
> Jon Awbrey
>
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
>
>