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

RE: SUO: RE: CYC event vs. SUMO Process -- really different?




Dear Richard,

Yes, but lets understand the requirements before we cut code.


Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom

Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com


> -----Original Message-----
> From: richardm@tinwisle.com [mailto:richardm@tinwisle.com]
> Sent: 17 June 2003 20:25
> To: standard-upper-ontology@ieee.org
> Subject: RE: SUO: RE: CYC event vs. SUMO Process -- really different?
> 
> 
> 
> It would be helpful to me if someone would prepare a document 
> that contains the relevant definitions and axioms. I'd also 
> like to see a concept lattice corresponding to those 
> definitions with some indication of nearest neighbor concepts. 
> 
> Cheers,
> Richard
> 
> -----Original Message-----
> From: West, Matthew R SITI-ITPSIE [mailto:matthew.west@shell.com]
> Sent: Tuesday, June 17, 2003 6:59 AM
> To: Patrick Cassidy
> Cc: standard-upper-ontology@ieee.org
> Subject: RE: SUO: RE: CYC event vs. SUMO Process -- really different?
> 
> 
> 
> Dear Pat,
> 
> See comments below.
> 
> 
> Matthew West
> Principal Consultant
> Shell Information Technology International Limited
> Shell Centre, London SE1 7NA, United Kingdom
> 
> Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
> Email: matthew.west@shell.com
> Internet: http://www.shell.com
> 
> 
> > -----Original Message-----
> > From: Patrick Cassidy [mailto:pcassidy@bellatlantic.net]
> > Sent: 15 June 2003 21:23
> > Cc: standard-upper-ontology@ieee.org
> > Subject: Re: SUO: RE: CYC event vs. SUMO Process -- really 
> different?
> > 
> > 
> > 
> > Matthew West raises some issues  of methodology, and I have
> > responded to those under a different Topic heading:
> >    SUO -- Technical Methodology
> > 
> >    Here I will respond to the comments Matthew has made regarding
> > the question of the spatial location of Events.
> > 
> > 
> > [PC] >>===================================
> > >>   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.
> > > 
> > > 
> > > MW: However, you don't have to know or care about that 
> > > either.
> > > 
> > --------------
> >   [PC]   Right.  A default can be specified and ignored in
> > reasoning.
> > -------------------
> > 
> > 
> > > 
> > [PC] >>(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".
> > > 
> > > 
> > > MW: Everything that is necessarily true for something might
> > > not be known (up to existence) so there is some really general
> > > stuff here we should get sorted straight away. Something
> > > being necessarily true and necessarily known are just quite
> > > different, and we are not considering here what might be
> > > necessarily known e.g. some knowledge might be a prerequisite for 
> > > some action. E.g. a rescue is not normally mounted without some
> > > information indicating someone needs rescuing. simply being in 
> > > need of rescue is not sufficient in itself.
> > > 
> > [PC] >>(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.
> > > 
> > > 
> > > MW: Again I think this is about the location being known.
> > > 
> > ------------------
> > [PC]  To require that the logical structure of the class "Event"
> > require some necessary location for every instance does not
> > require that the location be known.  It only means that each
> > event takes place **somewhere**, wherever that is.  The
> > "somewhere" can be listed as "unknown" for all events, or as a
> > default, if one wishes.  It can be ignored in the reasoning
> > done by an application program.
> 
> MW: Agreed. (for actual historical events anyway)
> > -------------------
> > 
> > > 
> > [PC] >>(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.
> > > 
> > > 
> > > MW: Quite. You should always start by looking at what the 
> supertype
> > > is. In a 4D ontology the supertype (or a supertype 
> anyway) would be
> > > spatio-temporal extent (in EPISTLE we call this individual). This
> > > includes physical objects and one or two other things as subtypes
> > > as well as activities - i.e. things that exist in 
> space-time, rather
> > > than things that are universals.
> > > 
> > ----------------
> > [PC] Does this mean that you agree that it is better to have
> > spatial location as a required relation in a 3D ontology?
> 
> MW: Personally I find a 3D ontology incoherent, and I really 
> can't make
> sense of more than small isolated parts, so I couldn't 
> possibly comment.
> It is not even clear to me what a 3D event might be. (lets stick with
> actual historical ones for the moment).
> 
> Does it (necessarily) extend in time as well as space?
> If so, what does it consist of? (not temporal parts of anything since 
> continuants don't have temporal parts)
> If not, what is it at all?
> > -------------------
> > 
> > > 
> > >>    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.
> >  >
> >  >
> >  > MW: How will you cope with a 4D activity necessarily 
> > having temporal
> >  > parts in a whole/part relationship?
> >  >
> > ---------------------
> > [PC]   Depending the axiomatization, I imagine that a 4D activity
> > could have direct translation to a 3D "Event" [i.e. for every
> > 3D event there is a corresponding 4D activity and the temporal
> > and spatial bounds are identical -- plus other axioms].
> 
> MW: I notice that you are already assuming that an activity/process/
> event is extended in space-time. Why do you think this?
> 
> > The temporal parts of the 4D activity would have corresponding
> > translations to the temporal parts of the Event.  
> 
> MW: How would you relate the temporal parts of the event to the
> continuants that participate in the activity/process/event?
> 
> > The
> > "temporal part" relations would not be identical because they
> > would have different arguments, but they would be translatable.
> 
> MW: Temporal part of what? Activity/process/event or participant.
> 
> MW: If you are proposing a dualist (continuant AND occurent) based
> approach with an eternalist view of space-time then the occurent 
> elements might be considered the same as the 4-dimensional view.
> Since all continuants have dual object that are their life-histories,
> a 4-dimensionalist will argue that this is just redundant.
> > 
> > ------------------
> > 
> > ------------------------
> > 
> > [snip]
> > [PC] >>  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.
> >  >
> >  >
> >  > MW: There will be an immediate problem because a 4D ontology
> >  > has activities made up of temporal parts of other things, but
> >  > 3D ontologies won't even admit that temporal parts of things
> >  > exist. So could we start with how you intend to deal with that?
> >  >
> > [PC]   3D objects themselves don't have temporal parts, but the
> > events they participate in do.  3D computational ontologists have
> > no trouble referring to objects within specific intervals of time,
> > and there will be correspondences that can be accurately translated,
> > provided that the 3D axiomatization and the 4D axiomatization
> > are coordinated to permit such translation.  That is one of the
> > goals I would envision for the SUO effort.  As I mentioned, one of
> > the reasons I think that a 3D "Event" should have a necessary
> > spatial location is because I think it will make translation to
> > 4D "activity" easier.  Do you agree with this?
> 
> MW: I have no doubt that all the sensible things that can be said in
> a 3D ontology can be said in (and translated to) a 4D ontology. The
> issues I forsee are more that there are times when 3D ontologies are
> ambiguous but 4D ones are precise, and things that can be said clearly
> in a 4D ontology, but in extreme cases a 3D ontology must deny.
> > 
> >     I agree the mapping of 3D to 4D is important.  I suggest a
> > thread on the relation of 3D Events to 4D activities.  But I
> > recommend that we postpone initiation of that thread until we
> > determine if there is any kind of predominant view on
> > **any** aspect of the 3D "Event", since the relationship will
> > be critically dependent on the axiomatization of the 3D Event.
> > If there is a specific axiomatization of 3D event that you
> > think is not translatable into your view of 4D activity,
> > it would be good to know that and we can try to avoid it.
> 
> MW: On the contrary it would be particularly good to explore it. If
> we don't look at the difficult things we will get nowhere. But note
> comments above. I am not expecting anything to be more difficult in
> a 4D ontology - after all I moved to a 4D foundation because I found
> it gave greater clarity and precision of meaning.
> > 
> > 
> > >>
> > >>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.
> > > 
> > > 
> > > MW: Well there's another issue. How are you going to deal with
> > > possibility, possible worlds or Modal logic?
> > > 
> > [PC]    That is an issue for a different thread.  It is important,
> > and I hope someone starts that thread.  It would be several
> > dozen issues down the line on my list, as I think it may
> > have to be treated with meta-level wrappers around specific
> > assertions, which can be dealt with in isolation.  But I am
> > sure there are others that would be more qualified than I
> > to frame that issue for discussion and decision.
> 
> MW: OK, but since this is also the realm of the hypothetical, it means
> putting that off too.
> > 
> >     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
> > =============================================
> > 
> > 
> 
> 
>