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

Re: SUO: Negotiation Instead of Legislation





At 1:13 PM -0500 2/20/02, John F. Sowa wrote:
>I agree with the principle, although I think my ontology is less
>flawed than any others I have ever seen.  Even then, I would not
>recommend it as a standard.

I would agree with "any" -> "many"

>
>>  Personally, as I've said on the SUO several times, I believe there
>>  should be more than one, but still a small number, of SUOs.  The first
>>  step in developing a negotiated ontology should be to pick the SUO to
>>  use.
>
>One point I make is that in any kind of design or architecture for
>anything, there are only three numbers that need no justification:
>zero, one, and infinity.  Any "small number" greater than 1 requires
>a very rigorous proof of adequacy.  Otherwise, it is just a grossly
>inadequate approximation to infinity.

You're right that we disagree.  I think that there are a very small 
number of fundamentally irreconcilable upper-level notions.  Like 
whether there is a continuant/occurrent distinction.  In practice, I 
think we should allow for some number of SUOs, where "some number" 
will, I believe, be controlled by the amount of effort required to do 
one, and then let people choose the one that suits their needs best. 
A free-market onto-economy.

>The other point of disagreement is whether you begin the negotiation
>from some top-down legislated SUO or from some bottom-up discovery
>procedure, which determines what the critical categories really are.
>The method I recommend in the slides is top-down for the superficial
>stuff (i.e., something like WordNet), and bottom-up for the stuff
>that really matters to the application (i.e., the stuff you really
>axiomatize).

Having an upper level to start with helps in reverse engineering 
legacy systems as well as building new ones.  And I'm not saying the 
upper level becomes part of the product generated, it just helps a 
lot to know that e.g. there are events, object, locations, etc., and 
that's all.  When you design your new system or analyze the old one, 
you group things into these categories.  It's a good first step.

>In any case, please look at the slides, the recommended approach,
>and the example (which has been successfully implemented for a
>large -- 9000 employees -- company).

Very nice.  I can't help but observe that your architecture paper 
mentions an upper level as a component!

-Chris


-- 

Christopher A. Welty        http://www.cs.vassar.edu/faculty/welty/
Vassar College Computer Science Dept.         Voice: (845) 437-5992
Poughkeepsie, NY 12604-0462                     Fax: (845) 437-7498