Re: SUO: CYC event vs. SUMO Process -- really different?
At 09:38 PM 6/12/2003 -0400, Patrick Cassidy wrote:
>Mike Pool has raised an interesting specific point about
>how to merge OpenCyc and SUMO, and focused on an important
>concept, namely Event (called Process in SUMO). He also
>argues a general point, that we shouldn't bother to
>relate a merged ontology to existing legacy ontologies.
I have no views on relating a merged (merger of what?) ontology to legacy ontologies unless I know what you're referring to here with "merged ontology"; in fact, I'm not advocating that OpenCyc and SUMO be merged. Perhaps you meant '*standard* ontology to existing legacy ontologies'?
If the latter is what you meant, I don't know if that's what my comments commit me to. Let's go back to the example of the meter. If a standard meter is created and it turns out that what Country X had been denoting with 'meter' actually turns out to be .9144*(standard meter), it may be prudent for them to do the mapping and maintain their old measurement system, as awkward as all the required conversions will turn out to be. The same is true for ontologies, it may make sense to keep legacy ontologies around and map them to a standard. I suppose that this is mostly an economic decision. However, I will claim that it is not and should not be the job of the standard developer to articulate or devise such a mapping except implicity in virtue of setting out the standard in terms of which the mapping will be defined. At the very least it should not be the primary focus of their standards development work.
>Here I would like to discuss whether, in a merged ontology,
>Event should be specified as necessarily having a spatial
>location. I focus here first on the 3-D aspect, but I hope
>it can be related to 4-D representations as well.
>
>This thread was renamed from:
>Re: SUO: Re: What is the motivation for having a multiplicity of ontologies?
>
>Since I think that we should try to find the maximum common
>ground among existing ontologies, and also try to build a
>merged ontology that includes the most useful elements of each
>existing ontology (others in addition to CYC and SUMO), I think
>this group should make an effort to find a merger of CYC and
>SUMO and also to relate the merged ontology as best we can
>to the existing ontologies. Mike indicates below that we
>shouldn't try to keep older ontologies around after creating
>a better merged ontology, but I don't think we have any
>option.
Again, I'm not saying that. It may make perfect sense to keep the older ontology around, it's just not the job of the standards developer to ensure that it or the mapping be part of the *standard*.
>The existing users will keep them around regardless
>of what we do. What I would propose is that those of us
>who would like to try to build a merged ontology just go ahead
>and work on it, and those who think it is important to also
>have mappings to other ontologies can work on that, and the two
>tasks need not interfere with each other. Some of us
>will presumably want to work on both aspects.
It's hard to argue that this isn't entirely reasonable and, we might note, we're also all free to attend baseball games and write country-western songs, etc., as we'd like. The question, though, is what the focus of the efforts of a standards group should be. What kind of effort will lead to a useful SUO? Implicit in your suggestion is that all of this is perfectly useful standards development work and I don't agree with that.
BTW, let me reiterate, these two options above do not exhaust the options. I, for one, am not necessarily in favour of either of the options you've presented above.
>So, to get on with it, I suggest we talk about Process and Event
>in CYC and SUMO. First, I reiterate Mike's useful comments
>and then add some suggestions of my own.
>
>
>Mike Pool wrote:
>>
>>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.
Sorry, I now see that the prefaces were full of typos. Let me know if the meaning is unclear and I can redo them.
I'm looking forward to working through the rest of the original message.
Mike
<snip>