SUO: Re: CYC Event vs. SUMO Process -- Tomorrow's Sea Battle in a Teacup
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
Patrick Cassidy wrote:
>
> This note will respond to several comments made regarding
> this thread. First, I would like to make clear what
> I think can be accomplished by this thread.
>
> 1. Now that John Sowa's proposal has been approved,
> and effort will proceed to develop some form of merged
> ontology, I am trying to discover some procedure that will
> enable us to make substantive progress in constructing such
> an ontology. The issue of creating mappings to SUMO, CYC,
> and other ontologies is related, but not central to building
> a "merged" ontology, which will be able to stand on its own
> and might eventually come to be viewed by some as "the"
> standard with the largest community of users. ...
Patrick,
The thing that will prevent any of these characterizations of event and process from
being taken seriously by any research community -- communities whose sense of common
sense is not defined by the maxim "if it's in a textbook it can't be common sense" --
much less viewed as 'the' standard, is that the segments of the SUO community that
generated these characterizations have not taken seriously any of the definitions
of event or process that are already standard in those research communities, say,
engineering, physics, operations research, statistics, systems science, just to
name the ones that I'm acquainted with.
Jon Awbrey
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 2. I suggest that we try to find some degree of
> consensus on what would constitute an "Event" in a
> merged ontology, since events (or the 4-D correlate
> "activity") are central to all ontologies dealing
> with real-world problems. If agreement can be found
> on that class, the discussion can be expanded to
> related classes.
> 3. If a different process for building such a merged
> ontology appears preferable to any of the participants,
> I hope they will make a suggestion for the alternative.
>
> ===================================
> The main point at issue right now is whether an Event
> (called Process in SUMO) must have a location in space
> in the ontology we would be constructing ("SCMO").
> The location can be a default or "unknown".
> It seems to be agreed that an Event must have a
> location in Time.
>
> (1) As best I can determine, neither CYC nor SUMO
> currently has axioms specifying that an Event **must**
> have a location in space, though CYC has an axiom
> specifying that a subtype of Event, "Event-Localized"
> must have a (relatively fixed) location in space.
> I have proposed that all events that are located in
> time (events affecting properties of physical
> objects or mental states) in fact do have a location
> in space, and the representation of Event should have
> a relation specifying that every Event has some necessary
> spatial location. Applications that have no need to
> consider the spatial location of an Event can ignore that
> relation, which could be given an innocuous default value
> of "inThePhysicalUniverse" or "Unknown".
>
> (2) One participant has objected to the requirement that
> Events must be defined as *necessarily* having a location in
> space. If we have only one general kind of Event, then
> whichever option we choose, there will
> be potential users who either:
> (a) have to remove the "necessary" axiom to the relation, or
> (b) have to add the "necessary" axiom to the relation.
>
> If this is the correct interpretation of the discussion
> thus far, it may be necessary to put this question to
> a vote.
>
> (3) An alternative could be to have, somewhat similar to CYC,
> a higher-level class of "TemporalEvent" which has no spatial
> location required, and as a subclass of that "SpatioTemporalEvent"
> which has both spatial and temporal locations as necessary
> relations. Since I consider all temporally located Events to
> be necessarily spatially located (and that the CYC distinctions
> are not well motivated), I think this is unnecessarily
> complicated, but I could live with it, if the majority of our
> participants consider it the better solution. But I think
> it would create problems mapping to other ontologies.
>
> In contemplation of the need for voting at some point
> in this process, I would suggest that we form a Working Group
> of the IEEE-SUO group to specifically deal with the details
> of creating a merged ontology. Before proposing such a
> working group in a formal motion, I would like to know if
> others think it is the best way to proceed. (if almost all
> voting members wish to participate, a committee may be
> unnecessary).
> Meanwhile, I would like to reply to some of the comments
> made about this issue, and we may be able to reach a tentative
> consensus on the immediate question and proceed to related
> questions.
>
> ============================
>
> R.1.
> Matthew West has responded:
> >
> > In a 4D ontology what SUMO calls Process, CYC calls event,
> > in EPISTLE we call activity, it does necessarily have a spatial
> > location. This arises because an activity consists of the temporal
> > parts of the participants in the activity.
> >
> > Of course the problem here is that a 3D ontology does not admit
> > temporal parts, only spatial parts, so there is a different sort of
> > inconsistency that is not so easy to overcome.
> >
> > Of course that an activity necessarily has a location does not mean
> > that you need to know or be interested in it.
> >
>
> [PC] Yes, the spatial location of Events (Activities) in 4-D is
> to me a good reason to make spatial location a necessary relation,
> as I think it will make the translation between the two
> paradigms easier. Ignoring the (default) spatial location should
> not create any problems for those who don't need it.
> I hope it is clear that having spatial locations as necessary
> relation attached to the EVENT class does not require that
> anyone actually fill in the value, or do anything with it.
> It is just there if one wants it.
> ---------------------
>
> R.2.
> Chris Partridge has written [in part]
> [snip]
> > This raises for me the question about the motivation for
> > the necessity of the different types of relations. Wouldn't
> > you agree that any attempt to synthesise these candidate
> > 'ontologies' merely by examination of the axioms without
> > an understanding of their motivation (or whether they are
> > aware of or address the relevant issues) is a thankless task?
> >
> > I know from many discussions with Nicola that these kinds of
> > concern are part and parcel of his work in trying to build an
> > ontology. Not being particularly familiar with SUMO or CYC,
> > I wonder whether it is possible to divine their motivations
> > from the available documentation for dealing with
> > the hypothetical Mary's birthday example. Maybe a SUMO or
> > CYC person could comment.
> [PC] Since SUMO and CYC people monitor this list, I also hope
> that they will provide suggestions regarding specific issues.
> If we make a suggestion here (e.g. that a spatial location
> for #$Event/&%Process is a necessary relation) that they
> think is not an optimal structure for an ontology, I hope
> they will let us know and explain their views.
> I also hope that someone familiar with the DOLCE ontology
> will contribute to these discussions. As best I can
> tell, it does appear that in DOLCE an event (one type of
> "Perdurant") has a necessary spatial location, since
> Perdurants have spatial parts (which depends on the
> spatial locations of their participants). But that may
> not be the correct interpretation.
>
> R.3.
> Chris Menzel responded
> >>
> >> 1. Require events to occur at locations (in regions) because
> >> there are events that are not spatial at all, e.g.,
> >> "what if Bob thought about Mary's birthday party?"
> >> is a hypothetical, with no spatial relationships at all.
> >
> > It's also not an event in the relevant sense. In your question
> > "what if Bob...", you are wondering about what would have been
> > the case had a certain event *type* been realized. Types are
> > abstract, so indeed nonspatial and nontemporal. But I take it
> > OpenCyc and SUMO are talking about event *tokens*, all of which
> > (plausibly, anyway) occur in a region of space-time. Thinking
> > events, in particular, occur between the ears.
> [PC] from which I conclude that he agrees that instances
> (tokens) of Events must have some spatial location. That is
> indeed the issue that we are discussing.
>
> R.4.
> Richard Cooper responded:
> > If no 4-space specification is required in either events or
> > processes, yet a 4-space specification can optionally be attached
> > to both events and processes, then I am satisfied with the
> > representations. But I don't want to have to deal with defaults
> > unless I somehow represent that 4-space information is important
> > in the situation(s) I want to represent.
> [PC] I am not quite sure whether having some default location
> ("InThePhysicalUniverse") in the representation of Event and then
> ignoring it completely means that one has to "deal with" it in
> the sense Richard intended. Depending on how one implements a
> program using the ontology, I can foresee essentially zero
> additional computational overhead when having a required default
> location.
>
> R.5.
> Adam Pease wrote:
> >
> > Rich,
> > I agree with you on these points, and SUMO does not force you into the
> > situation that you are concerned about.
> >
> [PC] I am not sure what Adam means here. Is it that SUMO does not
> require that one specify the exact location of every instance of
> Event (neither does any other ontology that I know of), or that
> SUMO does not require that an Event even have a location? I think
> that the latter is true, but I would like to know if Adam has any
> objection to a merged ontology requiring a spatial location
> for Events, as I have suggested.
>
> 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
> =============================================
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o