Re: SUO: Re: What is the motivation for having a multiplicity of ontologies?
At 05:19 PM 6/11/2003 +0200, Jean-Luc Delatre wrote:
>In http://suo.ieee.org/email/msg09709.html
>Pierre Grenon wrote :
>
>> Do you mean that because Cycorp has developed an ontology, Teknowlöedge has
>> developed an ontology and John Sowa has written a book and maintain a website
>> about his ontology, we need such multiplicity of ontologies? So we need X
>> because there is X? What the hell, man, do you have more things like that to
>> say?
>>
>> Or do you mean something like you and I do not see the same thing in the world
>> therefore we need an Awbrey and a Grenon ontology?
>
>I will speak S L O W L Y and LOUDLY so *everyone* gets *some* chance to understand...
>
>I am fairly sure that the SUMO ontology and the Cyc ontology are NOT the same
>(not to speak of the Grenon ontology versus Awbrey's ontology,
>or anyone else's ontology for that matter :o))
>and that they cannot currently be subsumed by any upper or merged ontology.
>
>But, if you or anyone else disagree, please SHOW US:
>Merge SUMO and Cyc right away, WITHOUT LOSING ANY SIGNIFICANT MEANING FROM EITHER ONE!
>Since everybody else has stumbled on such a challenge that would be a great achievement
>for SUO and the whole universe will be eternally gratefull to you...
>Or is it that you don't see any problem?
Jean Luc,
You may not have written S L O W L Y and LOUDLY enough for me; OTOH, maybe the problem isn't with the speed or volume.
The above is an interesting question, but I don't see how the challenge relates to your position. I wouldn't claim that it would be easy to merge OpenCyc or SUMO under one upper ontology. It may be, I don't know, I'm quite certain that it isn't trivial. However, suppose that it's difficult, why is that an argument against, rather than for, a single *standard* upper ontology?
Let's take an example. Let's consider two prima facie similar concepts from the two ontologies, &%Process and #$Event. ('&%' is a SUMO preface and '#$' is the Cyc preface). Note, however, that there is an important albeit subtle difference between the two. &%Process is a subclass of &%Physical, the class of things that are located in space and time. However, #$Event is not a subclass of #$SpatialThing or #$SpatialThing-Localized. Suppose I define &$MikeReprogramsHisVCROnJune102003 as an instance of &%Process and #$MikeReprogramsHisVCROnJune102003 as an instance of #$Event.
In SUMO I can say things like
(%&located &$MySwissArmyKnife &%MyLivingRoom)
in the same way that I can say
(%&located &$MikeReprogramsHisVCROnJune102003 &%MyLivingRoom)
However, in OpenCyc, while I can say
(#$objectFoundInLocation #$MySwissArmyKnife #$MyLivingRoom)
I cannot say
(#$objectFoundInLocation &$MikeReprogramsHisVCROnJune102003 #$MyLivingRoom)
or even:
(#$inRegion &$MikeReprogramsHisVCROnJune102003 #$MyLivingRoom)
because #$MikeReprogramsHisVCROnJune102003 is not an instance of #$SpatialThing or #$SpatialThing-Localized.
In OpenCyc one uses a different predicate, #$eventOccursAt, to relate events to the places at which they occur, but it is neither a generalization nor a specialization of the predicates used to specify relative spatial positions of physical objects, i.e., #$inRegion and its specializations. Events or processes are not located in the same way that physical objects are in OpenCyc; they are in SUMO.
So, this is a subtle but important difference between &%Process and #$Event, one that renders merging somewhat more complex than one might imagine at first blush if one had planned to simply map the two concepts to each other. So far I assume that I'm simply exemplifying a point that gets you really excited, i.e, it is very hard to merge or map two distinct ontologies.
But what is the solution here? Is it important that we maintain both different representations to further confuse future ontology builders or does it make more sense to try to produce a single standard upper ontology that makes a choice regarding how process/events will be defined in our standard ontology?
I would argue the latter. Keeping both representation around serves to confuse rather than standardize. Let us choose one and let the non-conformists ignore or adjust, that's the point (and result) of a standard. If we standardize the meter, for example, we don't keep several versions around because country X, country Y and region Z had all been denoting slightly different lengths with the term 'meter'. On the contrary.
I contend that it's much more useful to offer a standard with clear definitions than it is to maintain all these prima facie similar but fundamentally incompatible definitions as these will serve to prevent rather than facilitate interoperability.
best regards,
Mike Pool
>[snip]
>
>> Thanks for illustrating my point.
>
>The same to you!
>(Ahem... I am puzzled, are you REALLY that dumb, or do you pretend to on (some) purpose?)
>
>Take care...
>
>-- Jean-Luc Delatre
>-----------------------------------------------------------------------
>"Always do right - this will gratify some and astonish the rest."
> -- Mark Twain (1835-1910)
>-----------------------------------------------------------------------
> http://perso.club-internet.fr/jld/ -- GSM: +33 6 11 24 06 29