Re: [OWL-S]: Proposal for 3 new control constructs

On Monday, October 6, 2003, at 07:34 PM, David Martin wrote:

[snip]

> INVOKE
> ------
>
> The invoke construct, used something like this:
>
>   <invoke>
>       <service resource="http://..../SomeService.owl">
>   </invoke>
>
> simply means "request the execution of the given atomic process-based 
> service".  The reference is to a service instance, which is important 
> because it specifies both a process model and a grounding.  For 
> simplicity, I'm assuming here and throughout this message that the 
> specified process model is an atomic process.
>
> Normally, this means the atomic process will be executed by some other 
> execution engine.

Does this mean that there is a non-normal case where it's not? Perhaps 
I'm conflating your and drew's issues.

>   How to contact a particular execution engine will be given by WSDL, 
> via grounding declarations.  There are some grounding details here 
> that still need to be worked out.

This suggests to me that there isn't an inter/intra engine call issue 
at stake here (or, to put it in Drew's terms, you're still making no 
distinction between input/outpus and function invocation parameter 
bindings).

If that's true, I don't know that I object. In a sense, this is a 
"chuck the dataflow orientation" which, as I think I wrote earlier, may 
be an artifact of my reading of the term "dataflow" in the 0.7 spec :)

> One important question that arises:
>
> Should we employ a conventional means of binding arguments, that 
> happens inside this construct?  Say, something like this:
>
>     <invoke>
>       <service resource="http://..../SomeService.owl">
>       <binding>
>          <input>"http://..../SomeProcess.owl#Input1"</input>
>          <value>15</value>
>       </binding>
>       ... other bindings ...
>     </invoke>
>
> I think that depends in part on the final resolution of this other, 
> fundamental question:
>
> Is there a single source for all the inputs of an atomic process, or 
> can there be multiple sources?

If we have a dataflow oriented architecture, then yes.

> Similarly for outputs?  (Note that in a recent telecon, several 
> coalition folks favored a "yes" answer to this question; noone present 
> seemed to favor "no".)

There are further complications in how inputs/ouputs (in the DAML-S, 
knowledge precondition/effect) can interact with (earlier or later) 
inputs/outputs or just precondition/effect evalution.

> ACCEPT
> ------
>
> The accept construct, something like this:
>
>     <accept>
>       <service resource="http://..../SomeService.owl">
>     </accept>
>
> simply means "accept an invocation request for the given atomic 
> process-based service, execute the atomic process, and return the 
> outputs to the requestor".  The same comments as above apply regarding 
> the reference to a service instance.

Do I have to return the outputs? What if I'm an in-only process? 
(Out-only from the other processes point of view?)

> SELECT
> ------
>
> The select construct, something like this:
>
>     <select>
>         <accept>
>            <service resource="http://..../SomeService.owl">
>            <followWith>
>              ... other control constructs
>            </followWith>
>         </accept>
>         <accept>
>            <service resource="http://..../SomeOtherService.owl">
>            <followWith>
>              ... other control constructs
>            </followWith>
>         </accept>
>         ... other accept clauses ...
>     </select>
>
> means "accept an invocation request for any of the given (atomic 
> process-based) services (whichever request comes first), then handle 
> that request, then do whatever follows".

I guess what I don't understand is whether you are proposing these as 
replacements for split and split join, where splits are typically, 
thus, represented as distinct composite processes (perhaps at the same 
"top level"?

I actually like select (though I might lift the "whichever request 
comes first" restriction).

As I wrote earlier, this is getting very close to Erlang, which, in 
itself, is ok by me, as I very much like Erlang. I'm unclear if this 
resolves, either way, the input/output issue as Drew has raised it.

Also, it seems that we haven't eliminated the need for dataflow 
constructs. For example, in "accept" how is the idea that "the outputs 
are returned to the requestor" expressed? Does it need to be?

Finally, I'll notice that this strikes me as a very *large* change. 
Substantially changing the style, at least, of the language (from 
dataflow and split-join, to more messagey). I'm not sure that it's a 
bad change, but I do think it's fairly large.

Cheers,
Bijan Parsia.

Received on Tuesday, 7 October 2003 06:16:20 UTC