Re: [OWL-S] Process subClassOf IntervalEvent

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:

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

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

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

Thanks,

Feng


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