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

Francis McCabe wrote:

> 
> David:
>  Well, ..., without intending to cast aspersions, Tony Hoare and Robin 
> Milner both had more sophisticated views of process in the 70's and 80's.
>  The point being that real world processes are actually more complex 
> than one-shot RPCs.

Again, no argument, Frank.  I never meant to imply anything to the contrary.

Regards,
David


> Frank
> 
> 
> On Feb 18, 2004, at 9:17 PM, David Martin wrote:
> 
>>
>>
>>
>> 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 23:09:31 UTC