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

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 Monday, 6 October 2003 19:34:24 UTC