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

Re: SUO: RE: Procedure of development

Jim,

We have not yet seen many of the ballots.  Please forward the ballots (completely and without comment) to the SUO list.

Bob


Schoening, James R CECOM DCSC4I wrote:
780D366C8FDBD411859D0000F8081371013C2049@mail5.monmouth.army.mil"> 
 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 developmen
t.  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