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

Mark -

Thanks, belatedly, for this proposal.  I'm not entirely contented with the class and 
property names, but that's minor.  I have a couple questions / comments ...

Mark Burstein wrote:

> Based on our discussion, here's a variant proposal to allow inputs to be 
> "set" to the outputs of other steps.
> 
> At 12:10 PM 2/17/2004, 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>
> 
> 
> 
> How about this:
> 
> 
> <process:Perform>
>     <process resource="#AtomicProcess5"/>
>   <withInput>
>     <Binding>
>        <ofParameter resource="#AP5Input1"/>  ;; must be a parameter of 
> AtomicProcess5
>        <source>
>             <ProcessOutput>
>                <step resource="#perform29"/>     ;; must be a Perform 
> within the same Composite Process
>                <param resource="#output10"/>     ;; must be an output of 
> the process named in #perform29
>              </ProcessOutput>
>           </source>

Couldn't the source also be an input parameter of the parent process?  Or a "LOCAL"? 
   Or a non-local instance of some class, mentioned by URL? (in all cases, 
obviously, something other than ProcessOutput would be used)  I don't think you 
meant to exclude any of those possibilities; just checking.

>        </Binding>
>     </withInput>
>   <assignOutput>
>     <Assignment>
>        <toParameter resource="#ParentOutput7"/>   ;; must be a parameter 
> of some step in the same composite, or a "LOCAL" or output parameter of 
> the parent process.
>        <fromOutputParameter resource="#Output5/>  ;; must be a parameter 
> of AtomicProcess5
>      </Assignment>

The ability to assign an output of this process to the input of some other process 
seems okay in principle, but in practice, wouldn't it be better practice to show 
that assignment inside the other process (that is, the process to which the input 
belongs)?  In fact, this seems so compelling as a point of good practice that I'm 
thinking we should only allow the toParameter of assignOutput to apply to locals and 
outputs of the parent.  What do you think?

Regards, David

>    </assignOutput>
> </process:Perform>

Received on Thursday, 11 March 2004 01:59:51 UTC