W3C home > Mailing lists > Public > public-sws-ig@w3.org > May 2004

Re: [OWL-S] Process subClassOf IntervalEvent

From: Feng Pan <pan@ISI.EDU>
Date: Mon, 3 May 2004 21:08:34 -0700 (PDT)
To: David Martin <martin@AI.SRI.COM>
Cc: Jerry Hobbs <hobbs@ISI.EDU>, public-sws-ig@w3.org
Message-ID: <Pine.GSO.4.21.0405032031300.6751-100000@nitro.isi.edu>

Hi David,

Thanks for copying the email to me. Yes, I'm on public-sws-ig@w3.org.

Currently the time ontology is used in Process.owl as follows:

  Process subclass IntervalEvent	
  ControlConstruct subclass IntervalEvent
  timeout: ProcessComponent --> IntervalThing
  timeoutAbsolute: ProcessComponent --> InstantThing
In class ProcessComponent's definition (restriction on property):

After you remove 

  Process subclass IntervalEvent
  ControlConstruct subclass IntervalEvent

"begins" and "ends" temporal property restrictions will have to be removed
(or re-defined) from the definition of ProcessComponent, since they are
based on the the above subclass relationship.

About "timeout" and "timeoutAbsolute", based on Mark Burstein's email:

> Process Instances now represents either a set of unrelated intervals 
> (like the old process class) or else something that is not an event at 
> all, but is just a spec for one.

it makes sense to me to still keep them as possible temporal properties of

> I've also removed the cardinality restrictions on temporal properties,
> which were based on these subclass relationships.

I don't understand why you (only) removed the cardinality restrictions on 
temporal properties (which I guess are "begins" and "ends", right?).
The problem is the whole restriction, not the cardinality, as they are
using owl:maxCardinality="1"...



On Mon, 3 May 2004, David Martin wrote:

> Bijan Parsia wrote:
> > 
> > I notice that:
> > 
> > <owl:Class rdf:ID="Process">
> >   <rdfs:comment> The most general class of processes </rdfs:comment>
> >   <rdfs:subClassOf rdf:resource="&time;#IntervalEvent"/>
> > ...
> > 
> > So, it follows that AtomicProcesses aren't instants, which, while I 
> > accept that, could perhaps complicate some aspects of reasoning with 
> > them. (E.g., while it's great if you know that an AP is going to take up 
> > a certain amount of time, since you may be trying to figure out the 
> > overall time for a some composition, but you typically don't want, i 
> > take it, (relevant) change to happen during the AP (at least, from 
> > "inside" the AP).)
> > 
> > More importantly, I don't think Processes, as we've currently defined 
> > them (i.e., as Process *definitions*) are TemporalThings at all. For 
> > example, it makes no sene to say that one definition is *before* another 
> > (it does make sense to say that this or that Process occurrence is 
> > before that other one, or that this Process execution is before this 
> > other one).
> OK, later today I've planning to remove both
>      Process subclass IntervalEvent
> and
>      ControlConstruct subclass IntervalEvent
> from the developing 1.1 Process.owl file
> (which, please note, is an incomplete, inconsistent *draft* at present).
> I've also removed the cardinality restrictions on temporal properties, 
> which were based on these subclass relationships.
> (This removal of the time ontology use) is one of the more regrettable 
> aspects of our switch to PAI.)
> Of course, if and when we develop an ontology of process "execution 
> traces" (as we have discussed in the past), we can again use the time 
> ontology in this way, with execution traces.
> In the meantime, I'm not clear what, if anything, we can say about time 
> in Process.owl.
> Feng, do you have any guidance regarding this?
> Thanks,
> David
Received on Tuesday, 4 May 2004 00:15:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:45 UTC