- From: Feng Pan <pan@ISI.EDU>
- Date: Mon, 13 Oct 2003 13:34:57 -0700
- To: "David Martin" <martin@ai.sri.com>
- Cc: "Monika Solanki" <monika@dmu.ac.uk>, <hobbs@ISI.EDU>, <www-ws@w3.org>
Hi David, Thanks for your comments. > Well, let's be clear about this. We can't start using begins/ends as > properties of processes, unless we arrange for Process to be part of the > domain of begins/ends. One way to do this would be to make Process a > subclass of TemporalThing, and I think this has been part of Jerry's > thinking all along. Am I right, Jerry? Does this sound reasonable to > everyone? > > (If we *don't* want to do that, of course we could keep our existing > properties startTime and endTime, and just change their ranges to be > InstantThing.) Since ProcessComponent ocurrs during some interval, we can define ProcessComponent as a subclass of IntervalEvent. Since IntervalEvent is a subclass of TemporalThing, begins/ends can be safely defined as a property of ProcessComponent. > ProcessComponent is the union of Process and another class called > ControlConstruct, and I'm thinking we should just make ControlConstruct > a subclass of TemporalThing, also. To me, that's conceptually OK. > > What we had in mind with "during" was to say that a ProcessComponent > occurs during some interval. Is intDuring appropriate for that? Maybe > we should just delete "during". That is, if we have begins/ends, why do > we also need during? > > What's the relationship between TemporalThing and IntervalEvent? Yes, I think we can either make both Process and ControlConstruct subclasses of TemporalThing, or more specificly subclasses of IntervalEvent. IntervalEvent is a subclass of TemporalThing, because it's a subclass of IntervalThing which is a subclass of TemporalThing. Yes, since Interval and IntervalEvent share all the properties and relations in the entry sub-ontology of time, we can directly specify temporal properties (e.g. begins/ends, duration) for interval events. So I don't think during is necessary here. > >>Here, can we use "inCalendarClock", which has as range > >>"CalendarClockDescription", which has everything that might be needed to > >>specify timeoutAbsolute ? >> > > "inCalendarClock" is a property of instant things (i.e. instants and > > instant events) that specifies an instant thing in a specific > > calendar-clock interval, but "timeout" and "timeoutAbsolute" are > > properties of process components that should be interval events. > > > > I think what you want to say is the duration of a timeout interval of a > > process component, for example, time out after 5 days, right? > > I think the intention was for "timeout" to be an interval, as you > describe above, but for timeoutAbsolute to give a particular instant at > which a timeout occurs. (So the range of timeoutAbsolute in the current > Process.owl doesn't make sense. Seems to me it should become InstantThing.) From the current range of timeoutAbsolute I thought it's an interval. Yes, if timeoutAbsolute is to give a particular instant at which a timeout occurs, the range should be InstantThing. Then we can use either inCalendarClock or inCalendarClockDataType properties to specify what calendar-clock interval this time out instant is in. > > In order to do this, I suggest you keep the timeoutAbsolute definition: > > > > <owl:ObjectProperty rdf:ID="timeoutAbsolute"> > > <rdfs:domain rdf:resource="#ProcessComponent"/> > > <rdfs:range rdf:resource="&time;#Interval"/> > > </owl:ObjectProperty> > > > > Then, you can use either the "durationDescriptionOf" or > > "durationDescriptionDataType" property to describe the duration of the > > time out interval. > > That makes sense to me, but for timeout, not timeoutAbsolute. > timeoutAbsolute would be the same, except for a range of InstantThing. Yes, I agree. We may also want to change the range of timeout to IntervalThing in case later we want to consider timeout as an interval event, instead of a pure interval. Thanks, Feng
Received on Monday, 13 October 2003 16:38:53 UTC