Re: Produce construct worries

> [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.

> 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.

> 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.

> 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.

> 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.

                                             -- Drew


-- 

                                         -- Drew McDermott
                                            Yale University
                                            Computer Science Department

Some see the glass as half empty, some as half full.  Surely the
truth lies somewhere in between.

Received on Friday, 26 November 2004 20:52:59 UTC