Re: DAML-S process model definition

The answer to these questions ended up being discussed *off* of
www-ws@w3.org.  Attached is the synopsis.

Regards,

Sheila McIlraith
Stanford University

==================================================================

Ed,

The DAML-S 0.6 Walkthrough and Congo example are correct.  The Bravo
example is incorrect and will be fixed in DAML-S release 0.7.  Thanks
for pointing this out and our apologies for this ambiguity.   Lots
of cooks!  

I find it easiest to understand the relationshop between simple and
composition processes and the expand property by drawing a picture.
Nevertheless, here is a textual explanation:

- A SimpleProcess expands to a CompositeProcess (in the process
ontology).

- MySimpleProcess is a subclass of SimpleProcess.  Therefore, it
inherits the property of expanding to CompositeProcess *but*
we want to restrict that expand property in this context to say that it only
expands to MyCompositeProcess (which is and must be defined as a
subclass of CompositeProcess)

Hope that helps.  Let's see if Dave and Massimo have any comments.
Massimo/Terry Payne at CMU wrote the Bravo example.

Regards,
Sheila

Ed Buckley wrote:

Apologies for the confusion, I am myself unfortunately.

As an example, take expanding a SimpleProcess to a CompositeProcess.
Congo and the walkthrough use:
  <daml:Class rdf:about="#My_SimpleProcess">
    <rdfs:subClassOf>
      <daml:Restriction>
        <daml:onProperty rdf:resource="&process;#expand"/>
        <daml:toClass rdf:resource="#My_CompositeProcess"/>
      </daml:Restriction>
    </rdfs:subClassOf>
  </daml:Class>

BravoAir uses:
  <process:expand>
    <rdfs:Class> rdf:about ="#My_SimpleProcess"</rdfs:Class>
    <rdfs:Class> rdf:about ="#My_CompositeProcess"</rdfs:Class>
  </process:expand>

And I have used myself the following, since expand is simply an
ObjectProperty:
  <daml:Class rdf:ID="#My_SimpleProcess">
    <process:expand rdf:resource="#My_CompositeProcess"/>
    ..
    ..
  </daml:Class>

Ed

<Snip email exchange to clarify>

*******Ed's orginal question to www-ws@w3.org**********************

> > From: edward.buckley@bt.com
> > To: sam@KSL.Stanford.EDU
> > Cc: www-ws@w3.org
> > Subject: DAML-S process model definition
> > Date: Wed, 21 Aug 2002 11:50:21 +0100
> > MIME-Version: 1.0
> >
> > Hi, I have some (further) questions relating this time to the Process
> Model:
> >
> > 1)
> > How is the top-level process definition defined?
> > Examples use service:topLevelProcess and service:isImplementedBy:
> > <process:ProcessModel rdf:ID="myService_ProcessModel">
> >   <service:topLevelProcess rdf:resource="#myService_Process" />
> >   <service:isImplementedBy>
> >     <service:Service rdf:resource="&myService_service;#myService"/>
> >   </service:isImplementedBy>
> > </process:ProcessModel>
    > > Where #myService_Process is the instance definition of the top level
> process
> > (a subclass of Process).
    > > However, From the ontology the correct method is to use:
> > <process:ProcessModel rdf:ID="myService_ProcessModel">
> >   <service:describes rdf:resource="&myService_service;#myService />
> >   <process:hasProcess  rdf:resource="#myService_Process" />
> > </process:ProcessModel>
    > > 2)
> > How is a process expanded and collapsed? The congo and bravoair examples
> > each use different methods to do this, or are they both valid? Expanding
> > this, is there a set/preferred method of defining everything? I seem to
> > remember reading previously that there is none.
    > > Thanks,
> > Ed
> > _____________________________________________
> > Edward Buckley
> > BTexact Technologies (www.btexact.com)
> > This electronic message contains information from British
> Telecommunications
> > plc which may be privileged or confidential. The information is intended
> to
> > be for the use of the individual(s) or entity named above. If you are
not
> > the intended recipient be aware that any disclosure, copying,
distribution
> > or use of the contents of this information is prohibited. If you have
> > received this electronic message in error, please notify us by telephone
> or
> > email (to the numbers or address above) immediately.

Received on Thursday, 22 August 2002 15:29:15 UTC