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

Re: SUO: Re: Industry takeover




John,

At 07:57 PM 5/2/2003 -0400, John F. Sowa wrote:
>Adam,
>
>What are the statistics about how SUMO has been used?
>
> > Early on, in the SUMO development and with our project
> > of linking to WordNet, we did make a number of additions
> > and changes, but now that we're creating many domain
> > ontologies, very little needs changing day to day.
>
>That confirms my point:  when you were linking to
>something that somebody else had developed, you were
>making many changes to SUMO.

I don't think that's true actually.  It reflected more the fact that we 
were early in the SUMO project when we started the mapping to 
WordNet.  Changes settled down rapidly I'd say after the first 1/3 of the 
mappings.  Also, I'd characterize the change more in the realm of addition 
instead of reorganization.  I think there's an interesting project in what 
I might call "ontology archeology" that could be done since we've made the 
entire history of the SUMO project available.  Someone could run statistics 
over the CVS log for all the past 51 versions of SUMO and see how it 
changes, as well as how it changed relative to the CVS log for the WordNet 
mappings.

In addition, a portion of the new work we're doing does also map to at 
least informal ontologies, like databases and spreadsheets.  SUMO rarely 
needs changing, as you can see from the CVS log.  Instead, large amounts of 
additional content are needed at more domain-specific levels, as you can 
see from the ontology of Government that we recently posted.

This experience just doesn't support the assertions you're making.  It may 
not be sufficient to refute them.  That would take a broader range of 
experiences, but it does cast a certain amount of doubt on the criticisms 
you're making.


>But when you add new things to it yourself, I suspect
>that you were taking the easy way out, which it to
>accept SUMO as is.

I disagree.  If there's a real need for a change, we're not shy about 
making a change.  It's simply the case that few changes have been needed.

>What I am most concerned about is the extension to
>new applications where you have to adapt to somebody
>else's preconceptions.  How many people have done
>that with SUMO, and what are their experiences?

There are a few papers at <http://ontology.teknowledge.com> that you can 
read.  There are only a few though, so I doubt they will convince you.

>And your other data also suggests problems:
>
> > While, as Andrei pointed out, proving consistency in
> > first order logic is a process that mathematically is
> > not guaranteed to terminate...
>
>Yes.  In general, it is not guaranteed to terminate,
>but for smaller modules, it is possible to prove consistency.
>Sometimes, you can make do with relative consistency in terms
>of something that has a long-established history of use, such
>as the integers.

As I understand it, this is a mathematical property that has nothing to do 
with a history of use.  Most non-trivial FOL theories simply can't be 
proven consistent.  But maybe a mathematician/logician like Chris Menzel 
could comment more definitively on this.

>That is a very important reason for keeping the modules
>distinct.  You can link them together for those people who
>are willing to take a chance, but you also need to let
>people make their own choice about which ones to accept.

yes, that's why we took your advice and divided SUMO into 11 separate 
modules with a specified dependency structure.

> > ...  as well as being impossible in practice on theories of
> > any significant size, we have done proofs for consistency
> > within specified time boundaries.  We found and removed
> > inconsistencies found in up to 50-step proofs.  We can run
> > for days now without finding anything, so we have some
> > degree of confidence that SUMO is internally consistent.
>
>For some kinds of applications, that might be acceptable,
>but not for others.  It is essential to provide individually
>tested modules, each of which is guaranteed to be consist,
>and larger combinations, which people might accept on a
>buyer-beware basis.
>
>The issues of merging and combining modules are not something
>that you can limit to the development stage.  It is an
>issue that arises for every major application.

We just haven't found that to be the case, in the way you 
advocate.  However entertaining this debate might be, I think we're going 
to have to agree to disagree.  What did you think about my proposal to let 
the two groups of interested parties make progress without impediment from 
the other?  Can we at least agree not to block each other, and reconvene at 
a later date when there may be more evidence for our respective positions?

Adam


>John
>