W3C home > Mailing lists > Public > www-ws@w3.org > October 2003

Re: [owl-s] Time ontology usage for OWL-S 1.0

From: Feng Pan <pan@ISI.EDU>
Date: Mon, 13 Oct 2003 13:34:57 -0700
Message-ID: <000f01c391c9$77de3090$a800a8c0@Feng>
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
(e.g. begins/ends, duration) for interval events. So I don't think during is

> >>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

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
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
in case later we want to consider timeout as an interval event, instead of a


Received on Monday, 13 October 2003 16:38:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:10 UTC