SUO: RE: Procedure of development
Tim and all,
There are no specific rules that govern whether or how comments are
resolved within a working group. There are such rules at the stage of
formal IEEE ballots, but we're far away from that.
However, it is common practice and very smart to bring structure to
this process. This will help make sure you haven't missed any comments and
also assure participants that all comments have been fairly resolved. It
also helps when the same comment come up again.
However, since we're all volunteers, and we all have limited resources,
we'll have to do the best we can with the time we have. But some level of
structure (like a form to submit comments, postings on the web, numbering
scheme, etc.) may save more time than it costs.
Even though I have done some of this comment resolution in the past, at
this point I feel the Technical Editor(s) or other volunteers should handle
this.
Jim Schoening
-----Original Message-----
From: Tim King
To: standard-upper-ontology@ieee.org
Sent: 8/28/01 3:21 AM
Subject: SUO: Procedure of development
I request clarification here. As an active participant in ISO standards
development, I would characterise that process as being issues driven.
I can not perceive that it is possible to mandate a level of detail on
the proposed change column of the ballot forms; the editor of the
document has to demonstrate that the issue has been addressed through a
resolution of the issue. Although the difference may only be subtle, is
Adam right to claim that this IEEE activity is driven by change
proposals? This issue begs a supplementary question: is someone
collating all the ballot comments into an issues log that can be
examined at all points in the life history of the development. This log
should include a unique identifier and the eventual resolution.
I see issues as being user requirements and I expect that many of us
will be using our votes to protect our domain communities from a
standard that fails to address the needs of the users. A subset of the
participants in this mailing list will be capable to produce the robust
solutions that are demanded. These people fail to address all ballot
issues at peril of not converting NO votes into YES.
Cheers,
Tim.
> -----Original Message-----
> From: Adam Pease [ mailto:apease@ks.teknowledge.com
<mailto:apease@ks.teknowledge.com> ]
> Sent: 27 August 2001 15:36
> To: John F. Sowa
> Cc: West, Matthew R SITI-GREA-UK; Yang Yun;
> standard-upper-ontology@ieee.org; phayes@ai.uwf.edu
> Subject: Re: SUO: 2000-7-26 example
>
>
>
> John,
>
> At 10:06 PM 8/26/2001 -0400, John F. Sowa wrote:
> >Adam,
> >
> >My first change proposal is the same one that I recommended
> >at the SUO workshop at IJCAI.
> >
> >AP> Absolutely, what is your change proposal (stated as specific
> > > changes to the document)?
> >
> >Merge Robert Kent's IFF document with the SUMO document.
>
> This is a reasonable recommendation for a task (albeit a big
> one), but it
> is certainly not a change proposal. Take KIF as an example.
> "Include
> default reasoning in KIF" would be a recommendation for a
> task, and, like
> your recommendation for IFF and SUMO, one the success of which is not
> guaranteed. On the other hand
>
> change the BNF grammar in line 21, page 15 from
>
> foo ::= bar | baz
>
> to
>
> foo :: bar* | baz | bif
>
> would be a concrete change proposal.
>
>
> >The following point is fine, but my notion of feature is much more
> >than just an axiom or two here or there.
>
> It could be a substantial change or even a completely new
> proposal, but
> unless we get down to specifics it's very difficult to make progress.
>
> >AP> I think my stance is simply the as you say that "anyone
> who proposes
> >a new
> > > feature has a responsibility
> > > to explain the importance of that feature and why it should be
> > > adopted".
> >
> >I am writing up a more detailed explanation of the lattice of
> >theories and its implication for the ontology standards.
> >
> > > I'm not defending SUMO, just requesting that whoever says
> > > something is wrong with it must say precisely what it wrong
> > > (in terms of its terms or axioms), and provide a revision
> > > to the document.
> >
> >That parenthetical comment is the one I most object to. As I have
> >said from day one of the SUO effort, I believe that the methodology
> >for organizing the theories and axioms is far more important than
> >any particular axioms.
>
> Well, sure methodology is important, but we're not producing
> a methodology
> as the standard. Even if we accept that the methodology must be done
> first, at some point, one still has to specify terms and
> axioms. Anyway, I
> fear we've been over that ground before.
>
> >The urge to write axioms is very much like a programmer's desire
> >to write code when the overall architecture hasn't been done.
> >I believe that there is an important amount of work that has been
> >done on how to organize an ontology in the past 10 years and none
> >of it has been reflected in SUMO.
>
> "None" is rather strong, especially since many of the
> ontologies, if not
> all, that we've incorporated, we're built in the last 10 years.
>
> >I've been sketching out some
> >of the ideas in my comments, and Robert K. has been proposing them
> >in his IFF document. I realize that IFF is at too high a level
> >of abstraction for the underlying ideas to become apparent, but
> >I'm trying to bridge that gap.
>
> I see no way to bridge that gap other than actually writing
> or changing the
> axioms in IFF and SUMO to show how they can be made
> compatible. Explanations will help but, just as we can't
> create a model
> theory for KIF by English prose alone, so is prose also
> insufficient in
> this case.
>
> Adam
>
> >John Sowa
>
> Adam Pease
> Teknowledge
> (650) 424-0500 x571
>