W3C home > Mailing lists > Public > www-ws@w3.org > June 2001

Re: Instantiating a DAML-S Process

From: David Martin <martin@ai.sri.com>
Date: Wed, 13 Jun 2001 22:15:06 -0700
Message-ID: <3B28485A.ADCDB528@ai.sri.com>
To: buttler@cc.gatech.edu
CC: www-ws@w3.org
David -

Here is another comment in answer to your 2nd question.  In my previous
msg, I pointed out that in specifying the CongoBuy and related
processes, we are *restricting* classes and properties, rather than
*instantiating* them.  But that didn't answer your point about why we
are using UnionOf in connection with a sequence.  Below there's an
additional comment on this point from my colleague Srini Narayanan - 

David Buttler wrote:
> 
> .....
> 
> A second question:
> In defining the CongoBuy process (as well as the other examples),  there
> are several examples where there should be a sequence of action.  For
> this purpose a unionOf construction is used.  For example:
> 
> <!--
> SignInSequence is a sequence whose components are a simple process
> SignIn
> followed by a simple process LoadProfile
> -->
> 
> <rdfs:Class rdf:ID="SignInSequence">
>  <daml:subClassOf
> rdf:resource="http://www.ai.sri.com/daml/ontologies/services/1-0/Process.daml#Sequence"/>
> 
>   <daml:subClassOf>
>     <daml:Restriction>
>       <daml:onProperty
> rdf:resource="http://www.ai.sri.com/daml/ontologies/services/1-0/Process.daml#components"/>
> 
>       <daml:toClass>
>        <daml:subClassOf>
>         <daml:unionOf rdf:parseType="daml:collection">
>           <rdfs:Class rdfs:about="#SignIn"/>
>           <rdfs:Class rdfs:about="#LoadProfile"/>
>         </daml:unionOf>
>        </daml:subClassOf>
>       </daml:toClass>
>     </daml:Restriction>
>   </daml:subClassOf>
> </rdfs:Class>
> 
> In my understanding, a unionOf type is not an ordering, but a
> possibility of choosing one type or another.  So in the example above,
> every type in the sequence is either a SignIn type or a LoadProfile
> type.  However, the sequence says nothing about the order of the types,
> or how many types should be in it.  So, this seems to be only part of
> the specification, or maybe not even the right way to specify such a
> condition.  Is this true?

Yes, great point! I think this relies on a daml+oil
hack which is in http://www.daml.org/2001/03/reference.html#collection.

        Whenever an element has the rdf:parseType attribute with value
       "daml:collection", the enclosed elements must be interpreted as
elements
        in a list structure, constructed using the elements List, first,
rest
        and nil .

So the list structure will preserve the ordering. And one could add
cardinality information to the components list to specify the length
of the sequence. Note, this does not say anything more about the
execution semantics.  

Perhaps a better way to make this clear is to use the ProcessList
attribute for sequences.  This is defined in Process.daml. We are 
planning to use this for describing sequences of processes instead. Thus
the
components property of the sequence process should be a ProcessList
(list of processes). Then the first item property of the process list
would
be restricted to be of type SignIn and and the second to be of type
LoadProfile.  daml:Collection would only be used to describe bags.

Many thanks for the excellent questions.  

[Srini Narayanan]

Regards,

- David Martin
Received on Thursday, 14 June 2001 01:17:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:38 GMT