Re: [OWL-S]: Proposal for 1 new control construct

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