Re: Choice construct questions

Daniel,
The comments in Process.owl are left from older versions of OWL-S and in 
the most recent technical overview document Choice is simply defined as:

> Choice is a control construct whose key property is chooseFrom, whose 
> value is a list of processes the execution of one of which constitutes 
> execution of the Choice.
>
> [[ This wording is a significant scale-down from the original idea, 
> which involved being able to choose an arbitrary number of the 
> processes specified as chooseFrom, and then impose further constraints 
> on the set chosen. We have decided to simplify because the machinery 
> used to implement the original idea was not thought through carefully, 
> and because there doesn't seem to be much demand for the complicated 
> version. ]]
>

Obviously, we need to revise the comments in Process.owl to be 
compatible with this simplified definition. Actually, one thing we might 
consider to simplify the definition even more is simply use 
process:components instead of process:chooseFrom to specify the bag of 
processes. That would make the definition more compatible with the rest 
of control constructs, e.g. Sequence, Any-Order, Split all use 
process:components property.

Evren





Daniel Elenius wrote:

>
> I'm slightly confused regarding the Choice construct, especially the 
> comments about it in Process.owl, and the
> "chosen" property (definitions from Process.owl below).
>
> First of all, the rdf:comment. It mentions a "choose property", which 
> "takes a choice bag and returns a chosen
> bag". This does not make sense. There is nothing called "choose" in 
> OWL-S, and properties don't have parameters
> and return values.
>
> Second, the "chosen" property. I assume that this is supposed to point 
> to what the service consumer actually chooses
> to execute. But why do we need such a property? Its value will depend 
> on actual execution, so the process chosen
> by the user should be kept track of by the OWL-S execution engine, not 
> the service instance. Unless it needs to
> be referenced somewhere else in the service...
>
> ...which may be the case given the comments after the definition of 
> the Choice class. It mentions being able to
> express "choose n from m" etc using cardinality restrictions, and 
> being able to describe how to execute the chosen
> construct(s). A possible interpretation is: If we have e.g. a 
> Sequence, where the first element is a Choice, and the
> second is an Any-Order, the Any-Order can use the value of the 
> "chosen" property as the value of its "components"
> property. This would mean: First choose a number of the control 
> constructs in the "chooseFrom" bag of the Choice, and
> then execute the chosen constructs in Any-Order.
>
> Is this how it is intended to be used? Of course, it can't be used 
> this way now, because chosen takes only a single
> ControlConstruct, not a ControlConstructBag. And even if it did take a 
> bag, bags are interpreted as unordered, so we
> could not enforce a particular order in a Sequence on the chosen 
> constructs. So if Choice is to be used in the way
> I described, I would suggets the following:
>
> 1) Remove the range restriction on chosen.
> 2) Create two subclasses of Choice, called SingleChoice and 
> MultipleChoice.
> 3) Add local range restrictions on chosen for these two subclasses, so 
> that
>   SingleChoice restricts chosen to ControlConstruct, and 
> MultipleChoice restricts
>   it to ControlConstructBag (or ControlConstructList, to maintain the 
> order in which the service consumer chose
>   the items).
>
> I still don't see how you can describe "choose n from m". There is no 
> way to express that there can only
> be n elements in a ControlConstructBag.
>
>
> /Daniel
>
>
>
> <!--
> Choice.
>
> -->
>
> <owl:Class rdf:ID="Choice">
>  <rdfs:comment>
>    Choice is the selection among a bag of Processes.  The choose
>    property, takes a choice bag and returns a chosen bag. The cardinality
>    of the bag can be specified through a restriction to get choose(n).
>  </rdfs:comment>
>  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
>  <rdfs:subClassOf>
>    <owl:Restriction>
>      <owl:onProperty rdf:resource="#chooseFrom"/>
>      <owl:cardinality 
> rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
>    </owl:Restriction>
>  </rdfs:subClassOf>
>  <rdfs:subClassOf>
>    <owl:Restriction>
>      <owl:onProperty rdf:resource="#chosen"/>
>      <owl:cardinality 
> rdf:datatype="&xsd;#nonNegativeInteger">1</owl:cardinality>
>    </owl:Restriction>
>  </rdfs:subClassOf>
>
> </owl:Class>
>
> <!-- Note that given Chosen and ChooseFrom, we can define both a control
> construct such as sequence or any-order (ex. choose and do chosen in
> sequence, or choose and do chosen in parallel) as well as a class that
> restricts the size of the Process Bag that corresponds to the
> "components" of the chosen and chooseFrom subprocesses using
> cardinality, mincardinality, maxcardinality to get choose at least n
> from m, choose n from m, and choose at most n from m, etc.  These 
> extensions are left as an exercises to the reader :)
> -->
>
> <owl:ObjectProperty rdf:ID="chooseFrom">
>   <rdfs:domain rdf:resource="#Choice"/>
>   <rdfs:range rdf:resource ="#ControlConstructBag"/>
> </owl:ObjectProperty>
>
> <owl:ObjectProperty rdf:ID="chosen">
>   <rdfs:domain rdf:resource="#Choice"/>
>   <rdfs:range rdf:resource ="#ControlConstruct"/>
> </owl:ObjectProperty>
>
> <!-- end choice -->
>
>
>
>
>

Received on Tuesday, 26 October 2004 02:55:14 UTC