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

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.
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 12:02:26 UTC