- From: David Martin <martin@AI.SRI.COM>
- Date: Tue, 26 Oct 2004 10:19:06 -0700
- To: Daniel Elenius <daele@ida.liu.se>
- CC: Evren Sirin <evren@cs.umd.edu>, public-sws-ig@w3.org
It's a leftover, and it should also be removed (in fact, was removed late last night :-). Cheers, David Daniel Elenius wrote: > What about the "chosen" property. Should it remain, or is it also a > leftover from previous versions? > > Evren Sirin wrote: > >> >> 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 17:19:22 UTC