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

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 Tuesday, 17 February 2004 12:10:44 UTC