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

In response to my re-post, Bijan wrote:

> Just to extract the relevant bit from the other more contentious bits, suppose there were a superconstruct "call" which is the unionOf <invoke> and <accept> (and <select> could be modeled as the accept of a choice).
> 
> Hmm. Acutally, david, absent the resolution of binding, this doesn't make the reference/definition distiction, afaict.

Bijan, either I haven't been clear enough about what I have in mind, or I am 
completely missing what you are concerned about.

In my proposal, the distinction between definition and reference is straightforward:

a process *definition* is given as an instance of class Process (as we already do in 
1.0), whereas

a process *reference* is given as an instance of class Invoke, which mentions some 
Process defined-elsewhere, using the "service" property, e.g.:

    <Invoke rdf:ID="MyProcessReference545">
        <service resource="http://..../SomeService.owl">
    </Invoke>

Remember this was just an initial sketch.  Some of the details need further 
elaboration, and some could change.

But in any case, I fail to see how this approach fails to make the 
reference/definition distinction.  I'm also not clear what you mean by "absent the 
resolution of binding".  My proposal included a simple approach to specifying the 
binding of values to inputs of the invoked process.  (Again, some details remain to 
be fleshed out, such as the use of variables in these bindings, but we had some 
discussion about that in the last telecon, and hopefully some of these details are 
forthcoming.)

Cheers,
David

David Martin wrote:

> [This is a re-post of a message I sent to the www-ws list back in 
> October.  I am re-posting it because the OWL-S Coalition recently 
> started discussing some of these issues again.  I should say there were 
> several replies on www-ws.  I meant to reply to some of the replies, but 
> regretfully didn't get around to it.  In any case, we can revisit all 
> the relevant issues as needed here.]
> 
> -----
> 
> Following up on recent messages (in particular,
> http://lists.w3.org/Archives/Public/www-ws/2003Sep/0111.html
> ),
> here's a proposal for 3 new constructs for OWL-S - "invoke", "accept",
> and "select".  These constructs are simple and non-novel.
> 
> (By the way, since no DAML-S coalition members responded to the message
> referenced above, I'll assume that we have consensus on the points made
> there :-).
> 
> This proposal is still somewhat sketchy.  I'll follow up at some point
> with a more precise spec with an example or two.
> 
> Although I believe there are many good reasons for having these
> additional constructs, I will just highlight 4 points here:
> 
> (1) For purposes of this discussion, I'm assuming that a process model
> is executable and is meant to be executed in a single execution engine,
> and that most service modelers will be concerned with writing 2 or more
> process models that will run on separate execution engines, and will
> synchronize and interact at various points.  I'm not necessarily
> claiming that we should *only* support these particular assumptions, but
> I am claiming that it's crucial for us to support them, and support them
> well.
> 
> Once we're explicit about these assumptions, I think it becomes clear
> fairly quickly that one normally wants to be explicit about  whether
> some atomic subprocess X should be
> (a) executed completely locally (like a subroutine),
> (b) executed remotely (requested of some other execution engine), or
> (c) executed locally at the request of some other execution engine.
> 
> These proposed constructs are intended to indicate (b) and (c)
> explicitly.  I realize that it may also be possible to indicate these
> things by means of the grounding ontology and the referenced WSDL specs
> - but as I indicated in the earlier message, I think there are some
> unresolved problems with that approach.
> 
> (2) More important, I think developers are going to want to make these
> distinctions explicit in their OWL-S code for easier comprehensibility,
> and it may also be extremely useful for OWL-based reasoners to have
> visibility into these distinctions.  I think both of these points
> represent important requirements.
> 
> (3) I accept that there may be some times when you want to specify a
> process model so abstractly that you prefer just to say "process X needs
> to get done at this point (within some larger composite process)",
> without specifying anything about how or where X is to be executed (as
> Bijan, at least, has been arguing).  That is, you might not want to
> indicate whether it's being invoked for execution somewhere else, or
> executed locally, or whatever.  And I think the introduction of these
> new constructs doesn't have to prevent that style of representation.
> 
> (4) But I claim that it'll be *far* more common, in real uses, that you
> will already know this kind of information about process X, and you will
> want to make it as clear as possible.  That is, most developers, most of
> the time, will find it useful and desirable to have this kind of
> information made explicit at the OWL-S process level (not just in the
> WSDL specs to which X is grounded).  In fact, it strikes me that there
> will be many cases where you may want to express this info about X well
> before you are able to complete the grounding for X.  That makes it even
> more important to allow for these constructs.
> 
> Now, for a brief, sketchy description of these constructs.
> 
> Each of these would be a new subclass of ControlConstruct (just like
> Sequence, Split, and all the rest).
> 
> 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.  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.
> 
> 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?  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".)
> 
> 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.
> 
> 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".
> 
> Cheers,
> David
> 
> 
> 
>

Received on Thursday, 29 January 2004 01:32:12 UTC