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

Francis McCabe wrote:

> 
> Perhaps this is slightly tangential to the issue; but ...
> 
> this view of process seems very one-shot and RPC-ish.

No argument about that.  But note that we are not starting from scratch 
here on a new language.  This particular proposal ie part of fleshing 
out and tidying up an existing language, and yes, it is a lot like a 
workflow or programming language in many ways.  We never claimed of 
OWL-S that our primary objective was modeling conversations.

> 
> an ongoing conversation is still a process. But you don't invoke or 
> perform or use a conversation.

Well, yes, but as part of a conversation you might ask a question of 
another person and then wait for the answer.

- David

> 
> 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 Thursday, 19 February 2004 00:18:13 UTC