- From: Francis McCabe <fgm@fla.fujitsu.com>
- Date: Wed, 18 Feb 2004 10:28:14 -0800
- To: David Martin <martin@ai.sri.com>
- Cc: public-sws-ig@w3.org
Perhaps this is slightly tangential to the issue; but ... this view of process seems very one-shot and RPC-ish. an ongoing conversation is still a process. But you don't invoke or perform or use a conversation. Frank On Feb 17, 2004, at 9:10 AM, David Martin wrote: > > Following up on this proposal, below is an initial version of the > OWL-S code for the "Perform" construct. This will go in Process.owl. > > It's essentially the same as I described in the original message, but > calling it "Perform" instead of "Use". Also, I'm adding the property > hasBinding, which was missing from the example, and slightly renaming > a couple other properties. > > Here's the updated example: > > <process:Perform> > <process resource="http://..../SomeProcess.owl"> > <hasBinding> > <InputBinding> > <formal resource="http://..../SomeProcess.owl#Input1"/> > <actual resource="#Person1"/> > </InputBinding> > </hasBinding> > <hasBinding> > <OutputBinding> > <formal resource="http://..../SomeProcess.owl#Output1"/> > <actual resource="#MyVar43"/> > </OutputBinding> > </hasBinding> > > ... other bindings ... > </process:Perform> > > Here are the proposed new declarations for Process.owl: > > > <owl:Class rdf:ID="Binding"> > <owl:Restriction> > <owl:onProperty rdf:resource="#formal"/> > <owl:cardinality > rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> > </owl:Restriction> > <owl:Restriction> > <owl:onProperty rdf:resource="#actual" /> > <owl:cardinality > rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> > </owl:Restriction> > </owl:Class> > > <owl:ObjectProperty rdf:ID="formal"> > <rdfs:domain rdf:resource="#Binding"/> > <rdfs:range rdf:resource="#Parameter"/> > </owl:ObjectProperty> > > <!-- I don't think it's possible to specify the range. It's supposed > -- to be the union of swrl:Variable and the parameterType of the > -- corresponding formal. > --> > <owl:ObjectProperty rdf:ID="actual"> > <rdfs:domain rdf:resource="#Binding"/> > </owl:ObjectProperty> > > <!-- Similarly, here I don't think it's possible to specify the > desired restriction on the 'actual' properyy. > --> > > <owl:Class rdf:ID="InputBinding"> > <rdfs:subClassOf rdf:resource="#Binding"/> > <owl:Restriction> > <owl:onProperty rdf:resource="#formal"/> > <owl:allValuesFrom rdf:resource="#Input"/> > </owl:Restriction> > </owl:Class> > > <owl:Class rdf:ID="OutputBinding"> > <rdfs:subClassOf rdf:resource="#Binding"/> > <owl:Restriction> > <owl:onProperty rdf:resource="#formal"/> > <owl:allValuesFrom rdf:resource="#Output"/> > </owl:Restriction> > <owl:Restriction> > <owl:onProperty rdf:resource="#actual"/> > <owl:allValuesFrom rdf:resource="&swrl;#Variable"/> > </owl:Restriction> > </owl:Class> > > <owl:Class rdf:ID="Perform"> > <rdfs:subClassOf rdf:resource="#ControlConstruct"/> > <owl:Restriction> > <owl:onProperty rdf:resource="#process"/> > <owl:cardinality > rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> > </owl:Restriction> > </owl:Class> > > <owl:Property rdf:ID="process"> > <rdfs:domain rdf:resource="#Perform"/> > <rdfs:range rdf:resource="#Process"/> > </owl:Property> > > <owl:Property rdf:ID="hasBinding"> > <rdfs:domain rdf:resource="#Perform"/> > <rdfs:range rdf:resource="#Binding"/> > </owl:Property> > > > Comments welcome. > > Regards, David > > > David Martin wrote: > >> Greetings -- >> In an earlier discussion on this list, I had proposed 3 new "control >> constructs" for the OWL-S process model: "Invoke", "Accept", >> "Select". >> (See public-sws-thread >> [OWL-S]: Proposal for 3 new control constructs] >> here: >> http://lists.w3.org/Archives/Public/public-sws-ig/2004Jan/0110.html >> ) >> In our recent OWL-S telecons, we have reached a consensus *not* to >> explicitly distinguish between the "invoke" and "accept" of a Web >> service, at least, not in the way that I proposed earlier. Also, we >> are putting aside the "select" construct. >> Instead of distinct "invoke" and "accept" constructs, this message >> proposes a single new construct, which indicates the "use of" or a >> "reference to" a Web service that's defined elsewhere. This is in >> accord with the recognition that we want to maintain a highest (most >> abstract) level of process description, which states what needs to >> get done when, but tolerates minimal commitments about where each >> thing needs to get done, and by whom. (That is, we want to allow it >> to be left unspecified as to which subprocesses are executed by which >> participants/roles, and by which distinct enactment engines.) >> This is *not* to say that these things will never be specified - just >> that we want to allow a level of description where they may be >> absent. In fact, we are also thinking in terms of a second, lower, >> more detailed, style of description (a "middle level", in my mind) in >> which these kinds of details are added in. But more about that in >> other messages. >> Here's an initial strawman proposal for this new construct, which >> indicates the use of a Web service that's defined elsewhere. It's >> syntactically about the same as the "invoke" construct proposed >> earlier -- but it doesn't carry the same implications about what's >> going to happen where. >> We've been calling one of these things a "Reference" in >> conversations, but to me that's not really very helpful, so I'm >> proposing "Use". Other suggestions are welcome. ("Employ", "enact", >> "execute", "do", "run", "apply" ?) >> USE >> --- >> The use construct, used something like this: >> <Use> >> <process resource="http://..../SomeProcess.owl"> >> </Use> >> simply means "The indicated process, defined elsewhere, is used at >> this point (within a larger process)". For simplicity, I'm assuming >> here and throughout this message that the specified process model is >> an atomic process. >> I also propose a conventional means of binding arguments, that happens >> inside this construct. Like this: >> <Use> >> <process resource="http://..../SomeProcess.owl"> >> <binding> >> <formalInput resource="http://..../SomeProcess.owl#Input1"/> >> <actualInput resource="#Person1"/> >> </binding> >> <binding> >> <formalOutput resource="http://..../SomeProcess.owl#Output1"/> >> <actualOutput resource="#MyVar43"/> >> </binding> >> ... other bindings ... >> </Use> >> The "formalInput" and "formalOutput" properties have values that are >> instances of process:Input or process:Output, respectively. >> The "actualInput" property has values that are either variables or >> instances of the type associated with the formalInput. >> The "actualOutput" property has values that are variables. >> (Note: variables can include, but are not limited to, inputs and >> outputs associated with the larger, composite process. The details >> of variables are being discussed in other e-mail threads.) >> I will send the OWL declarations, which would go into Process.owl, in >> a later message. >> Comments welcome. >> Thanks, David >
Received on Wednesday, 18 February 2004 13:28:26 UTC