Re: Some glitches in process definitions

Drew McDermott wrote:

> In our latest attempts to finish the process formalism for Owl-S,
> there are a couple of issues that we have to address:
> 
> (1) The "ParentPerform" entity seems unnecessary to me.  I would have
>    to work to get my surface-syntax parser to deal with it.  After
>    staring at this problem for a while, I fudged the output of the
>    parser to include this thing, but I don't see the need for it.  For
>    one thing, it's misleading.  The ParentPerform is the actual
>    process instance we're describing, not its parent.  

I never really found it misleading (but now you are making me wonder). 
I think it's meant to only be mentioned within a Perform construct.  In 
that case, "parent perform" is (fairly) easily understood (I guess) to 
be talking about (the execution trace of) the "perform" of the enclosing 
(parent) process.

Having said that, however, I tend to agree with your other points. 
Let's discuss in the telecon tomorrow.   (But let's bear in mind that we 
don't have the luxury of major re-conceptualization within the 1.1 
release.  If your proposal has substantial implications it might have to 
wait for 1.2.)


>    For another,
>    the ParentForm has no independent motivation for existing.  There's
>    nothing we can say about it; it's just there so a parameter called
>    I1 is always used as a parameter and never as a variable.

I don't quite get the point just above, though.

> 
>    I propose that we do what standard programming languages do: within
>    a process definition, allow references to the inputs and outputs of
>    that process as ordinary symbols.  The only obstacle is the 
>    XML scoping rules, which require a name to denote the same thing
>    everywhere.  The solution is to introduce a new property (e.g.,
>    'localName') for parameters.  Any reference to a parameter of the
>    current process in the surface syntax would get translated to a
>    reference to its localName in the XML/RDF syntax.
> 
> (2) In the most recent draft of the technical overview of processes, I
>    introduced a pseudo-control-construct called 'Produce'.  Its
>    purpose is to link output parameters of the current process to
>    their values, as in this tableau (from the technical-overview
>    draft):
> 
>     define composite process CP(inputs: (I1),
> 				outputs: (O1))
>       {
>        step1 :: perform S1(I11 <= Incr(I1), I12 <= "Academic");
>        step2 :: perform S2(I21 <= step1.O11);
>        produce (O1 <= pi * max(0, step2.O21))
>       }
> 
>    The last line says "The output O1 of the process [CP] is \pi times
>    the max of 0 and the o21 output of step2."  We have to have
>    something like this because the outputs of the process depend on
>    the flow of control through the process, so that an alternative
>    such as declaring the outputs in the header would be unworkable. 

Right, but doesn't our current approach using withOutput (within a 
Result) allow for this already?

- David

Received on Tuesday, 19 October 2004 05:13:12 UTC