- From: Daniel Elenius <daele@ida.liu.se>
- Date: Sun, 24 Oct 2004 17:21:13 -0700
- To: public-sws-ig@w3.org
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 Monday, 25 October 2004 13:17:45 UTC