Re: Produce construct worries

Drew McDermott wrote:

>>[Daniel Elenius]
>>
>>I have some concerns about the Produce construct, which was a late 
>>addition to OWL-S 1.1.
>>
>>If I have understood things correctly, the purpose of Produce is to bind 
>>outputs of the parent composite process from one of its children. This 
>>is necessary if the children are executed conditionally (i.e. the 
>>composite process is an If-Then-Else, Repeat-Until, or Repeat-While) 
>>since these bindings will depend on which subprocess gets executed, and 
>>this is not known until runtime. Therefore, the bindings can not be put 
>>in the parent composite process.
>>
>>BUT, I don't like the solution of introducing a new control construct 
>>for this, for several reasons:
>>
>>1) It seems like overkill. With Produce, we often need TWO additional 
>>construct, because adding a Produce after another construct means that 
>>both construct will have to be put inside a Sequence construct (unless 
>>there is already a Sequence).
>>    
>>
>
>In the surface syntax, all you need is one semicolon to indicate a
>sequence.  If one dreads adding a sequence, that indicates a problem
>with the XML/RDF notation, not with Produce.
>
>  
>
First, the OWL encoding is what we *do* have to work with. Even if we 
use Protege, Swoop, etc. to edit OWL-S services, or the OWL-S API to 
programmatically manipulate them, we still see the OWL properties, 
classes, and so on. I don't think it's a good idea to just throw all 
that overboard and say "to hell with the OWL encoding".

We have been toying with the idea of integrating support for the surface 
syntax in our editor, but many people will still want to work at the OWL 
level. It is therefore highly desireable to simplify the conceptual OWL 
encoding.

Secondly, there may be other ways to encode this that do not require a 
change in the surface syntax.


>>2) Produce differs from all the other constructs in that it is a pure 
>>"client-side" operation, whereas all the other ones are essentially 
>>"server-side".
>>    
>>
>
>I don't understand this one.
>
>  
>
Me neither, now that I read it again. Forget this one.

>>3) Produce is not an independently executable unit, but depends on 
>>another construct (the source of the parameter to bind) for its 
>>functionality. This could also be said of e.g. Repeat-Until, which 
>>depends on its untilProcess, but in this case the relationship is made 
>>explicit by the untilProcess property. There is no corresponding 
>>property in Produce to make the relationship explicit. Furthermore, if 
>>there was such a relationship, it would break with the structure of 
>>OWL-S composite processes always being trees with Performs at the leaves.
>>    
>>
>
>Produce doesn't really depend on another construct.  You could write
>
>   checkstep ::
>      perform send_message(supplier <= "Acme",
>			   part_no <= user_requested_part_no);
>   if checkstep.available 
>       then {
>	       produce(error_flag <= false);
>	       ...
>	    }
>       else produce(error_flag <= Not_avail_flag)
>
>Here the output parameters are bound to constants.
>
>  
>
But Produce's reaison d'etre is that we want to bind outputs from 
conditional branches, right? Otherwise, we could just have a 
valueFunction in the target of the data flow declaration. I was wrong in 
tying it to Performs, though, I should have said ControlConstructs. That 
is, producedBinding could be made a property of ControlConstruct.

>>4) It is difficult to model composite processes with Produce. In our 
>>OWL-S Editor (under construction) we can model all other control 
>>constructs in a very straightforward way, but it's hard to see how to 
>>handle Produce in any intuitive way graphically.
>>    
>>
>
>You could draw lines from each Produce to the declarations of the
>output parameters it sets.
>
>  
>
I'm not so sure it would integrate nicely with the otherwise very 
standard-looking process graphs that our tool generates.

>>5) And finally, it does not seem to me that it is really needed. The way 
>>Produce works is that it has a property producedBinding, which takes an 
>>OutputBinding. Why not just change the domain of producedBinding from 
>>Produce to Perform, and thus declare these OutputBindings at the Perform 
>>itself, rather than in an extra unwieldy Produce control construct? All 
>>Performs would declare their own OutputBindings, so the fromProcess 
>>property of the OutputBinding would always be ThisPerform. This seems 
>>much more straightforward to me.
>>    
>>
>
>As implied above, there is no tight binding between a Produce and an
>antecedent Perform.  A Produce can use values from more than one or
>less than one Perform.
>
>  
>
See my modification above. This would allow you to do anything that can 
now be done with Produce, only easier.

Another more fundamental concern, though, is the one I brought up in the 
email with subject "replacing hasDataFrom with hasDataTo". With Produce, 
we have some data flow declarations declared at the source and some 
declared at the target, which is confusing. See that email.

Cheers,
/Daniel

Received on Friday, 26 November 2004 21:42:55 UTC