SUO: CYC event vs. SUMO Process -- really different?
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.
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. 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.
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.
>
> 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?
>
> Mike Pool
>
[PC]
OK, it is clear that there are differences between CYC #$Event and
SUMO %&Process. They each have different predicates defined on them.
So let us try to decide which predicates make most sense to us to
include in our merged ontology. (?"SCMO" = "Sumo-Cyc merged Ontology"
or "Self-Consistent Merged Ontology"?)
The outline of this section of the discussion is:
[1] Distinguish necessary predicates from predicates which
merely specify the classes of their arguments.
[2] Decide whether Cyc "Events" really are just as located as
SUMO "Processes".
[3] Specify the necessary relations that are the minimum that are
needed to define "Event" in our new SCMO ontology.
[1] Necessary versus possible predicates
One problem is that OpenCyc has a mechanism to specify "necessary"
predicates, but SUMO relies on axioms and is less systematic in that
regard. I think that we first need to come to some agreement as to
how we want to distinguish *necessary* properties/relations of
classes from *possible* relations among instances. In OpenCyc,
for example, there is a RuleMacroPredicate "#$relationAllExists"
which is a macro which expands in the following manner:
**(#$comment #$relationAllExists "(#$relationAllExists PRED COL1 COL2)
** means that for any instance INST1 of COL1, there exists some
** instance INST2 of COL2 such that (PRED INST1 INST2) holds.
** (#$relationAllExists PRED COL1 COL2) is thus redundant with a
** commonly-encountered form of rule. So #$relationAllExists (and its
** defining axiom; see #$expansion) enables this common type of rule
** to be stated more tersely. Moreover, (forthcoming) code support
** will enable type-level inferencing with #$relationAllExists.")
**
The logical definition (:ARG1 is the predicate name PRED above):
** (expansion relationAllExists
** (implies (isa ?TERM :ARG2)
** (thereExists **?OTHER
** (and (isa ?OTHER :ARG3)
** (:ARG1 ?TERM ?OTHER)))))
It is the necessary relations that "define" a class, giving the
common properties that all members of the class must have.
So in the first discussions of a class I would prefer to
focus on the necessary relations.
In the Protege browser (which implements the OKBC logical
model) each slot has a facet named "required" which can be checked,
and if it is checked, I believe that this would be equivalent
to requiring some instance of the "range" argument to exist,
for each instance of the "domain" argument. If that is
the proper interpretation, then we can use that facet
in Protege to serve as an equivalent to the "relationAllExists"
of CYC.
In the formal language (SKIF?) we could use a macro
like relationAllExists or explicitly axiomatize each necessary
relation in full.
[2] Are CYC Events located in space? Are SUMO processes?
SUMO has several axioms indicating some necessary relations on
PROCESS: none of these involve the location. Interestingly,
subprocesses are explicitly referred to a time, though Processes
themselves are not. See:
http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&name=Process&skb=SUMO
and
http://ontology.teknowledge.com:8080/rsigma/SKB.jsp?req=SC&skb=SUMO&id=101
(=> (instance ?PROCESS Process)
(exists (?CAUSE) (agent ?PROCESS ?CAUSE)))
(=> (instance ?PROC1 Process)
(exists (?PROC2) (causes ?PROC2 ?PROC1)))
(=> (and (instance ?ROLE CaseRole)
(holds ?ROLE ?ARG1 ?ARG2)
(instance ?ARG1 ?PROC)
(subclass ?PROC Process))
(capability ?PROC ?ROLE ?ARG2))
(=> (and (instance ?PROC Process)
(subProcess ?SUBPROC ?PROC))
(exists (?TIME) (time ?SUBPROC ?TIME)))
In OpenCYC I could find 5 necessary relations on EVENT. Two
were for relations defined directly on Event:
(relationAllExists subEvents Event Event)
(relationAllExists actors Event SomethingExisting)
... and three were inherited from the higher classes TemporalThing
and Situation of which Event is a subclass:
(relationAllExists duration TemporalThing Time-Quantity)
(relationAllExists intangibleParts PartiallyIntangibleIndividual
IntangibleIndividual)
(relationAllExists parts PartiallyIntangibleIndividual Intangible)
--------------
As far as *necessary* relations are involved, the two ontologies
agree that an Event/Process is located in Time (which can be a time
point). They also agree that events have participants: actors (CYC)
can be almost anything involved:
> "Thus actors is a broad relation that holds between a given event
> and any contemporary existing thing (see SomethingExisting) that
> is meaningfully involved in the event. (actors EVENT ACTOR) means
> that ACTOR is somehow saliently (directly or indirectly) involved
> in EVENT during EVENT."
whereas in (SUMO) the CaseRole may be more specific. We can discuss
participants at a later time.
---------------
Neither of the ontologies requires that an Event/Process be
located in Space -- but CYC does require spatial location, as
Pierre points out, for the subclass of Event, "Event-Localized".
(relationAllExists eventOccursAt Event-Localized Place)
**BUT** in CYC "Place" is a fairly specialized kind of location.
For Cyc, the "Place" referred to should be relatively stable,
e.g. not moving with respect to the Earth's surface. So that
restricted kind of Event is located in a restricted kind of
Place. That doesn't leave out the possibility that other
kinds of Events can be located in other kinds of locations.
I think that it would be useful to require in fact that all Events,
which are located in Time, must also be located in space. Consider
subclasses of Cyc Event which do not have the necessary relation
"eventOccursAt". For example, AilmentCondition is an event that
refers to malfunctioning in an organism. But organisms are located in
space, so the ailment must also be located in space, namely in that
region of space that is #$cospatial with the organism, even if it is
moving with respect to the Earth's surface (e.g. from Beijing to
Toronto). All spatial locations are in fact relative to some physical
object anyway, so we can require that all events located in Time be
located relative to some Physical Object -- a geographical location is
only one option.
There are other kinds of location in Cyc, but they are scattered
around under "SpatialThing-Localized". For example,
#$SpaceRegion-Empirical in CYC:
> "A specialization of #$SpatialThing-Localized whose instances are
> intangible regions of space located in the empirically observable
> universe. A space region might or might not be connected (see
> #$spatiallyContinuous). It might be partially or completely filled
> with (occupied by) #$PartiallyTangibles, or it might be completely
> empty (but cf. #$EmptySpaceRegion). In any case, the space region
> itself is not to be confused with a physical object or other
> spatially localized (non-space-region) thing that might happen to be
> #$cospatial with it. A given space region can be characterized
> fully merely by specifying its location and dimensions. Thus
> (although this is not the case with spatial things in general),
> space regions are identical (#$equals) if and only if they are
> #$cospatial. #$SpaceRegion-Empirical is in a way the spatial
> analogue of #$TimeInterval, whose own instances can be fully
> characterized by specifying their temporal properties; these two
> collections can be used, respectively, to talk about space and time
> as dimensions ."
I think that it would be useful to collect all classes that refer
to a spatial location under one "Location" class and put that at the
top level in the merged SCMO ontology (or directly under "Physical",
depending on its definition). That can serve as the class that
contains the "location" for any kind of Event. In SUMO "Region"
seems to serve the function of a general "Location" but it is
conflated with objects themselves, and would have to be dissociated
to serve as a pure locational attribute. This is presumably the reason
why in SUMO "located" can serve to locate both objects and processes.
The "located" relation in SCMO would have to be a different
relation for objects and for processes (Events), in that they
would be axiomatized differently. This is also suggested by the
Italian ISTC-CNR group in their paper "The WonderWeb Library of
Foundation Ontologies" :
http://www.ladseb.pd.cnr.it/infor/Ontology/Papers/WonderWebD17V2.0.pdf
"perdurants have well-defined temporal location, while their spatial
location seems to come indirectly from the spatial location of their
participants"
Requiring a location for all events also works for mental events,
(events that depend predominantly on the thought processes of
intelligent agents) such as the change of ownership of an object,
or the change of a person's role. The location for ownership change
could be the union of the spatial locations of the object owned, the
former and new owners, and any other thing that is directly affected
by the change of ownership at the time of the Event.
The location of the beginning of the universe, for another
example, would have as its location the whole universe at that time (=0).
==================
[3] Suggestion:
3.1 We decide on how to specify necessary relations,
and focus on those initially for defining classes.
3.2 In a merged ontology, we should have a general class
"Location" which can have a "Place" relative to the Earth's
surface, and other locations relative to specific physical
objects. A Location could be an aggregate of disconnected
spatial locations.
3.3 All Events which are located in Time will also
necessarily have a location at some such spatial
"Location".
3.4 An Event takes place over some interval of time, which
may be of zero duration.
3.5 Specific kinds of event may have locations of a
more specific kind.
3.6 the predicate relating objects to their locations will
be different from the predicate relating Events to their
locations.
=======================
If we can agree on that much, the specifics of the axiomatization,
other relations on Events, and the implications for other classes
and relations can then be discussed. If there is disagreement
on the above, please make alternative suggestions, or suggest
alternative starting points to try to build the merged ontology.
Contact me directly if you would rather hash out specific
questions that don't require general notice.
Pat
=============================================
Patrick Cassidy
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax)
internet: cassidy@micra.com
=============================================