W3C home > Mailing lists > Public > www-ws@w3.org > October 2003

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

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Mon, 6 Oct 2003 20:23:59 -0400
To: "'www-ws@w3.org'" <www-ws@w3.org>
Message-Id: <8B6DD50B-F85C-11D7-994E-0003936A0B26@isr.umd.edu>

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

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

We do, just not the one you would hope for :)

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

This is imprecise. Do you mean that ALL parts of the process model is 
so meant? Including Atomic Processes? Somewhat pointless Web Service 
(or, at least, not a common case).

>  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 fail to see how this is substantially different than having a single 
description encompassing both.
> Once we're explicit about these assumptions, I think it becomes clear 
> fairly quickly that one normally wants to be explicit

Not to me.

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

Uh...why? I mean, other than latency analysis? Or maybe some failure 
recovery thing.

But all this is made perfectly clear by the particular instantiated 
processes. No need for a control construct, much less three. Indeed, 
the control constructs inhibit reusability.

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

Uh...Well, thus far we have unmentioned unresolved problems, and magic 
clarity for the alternative approach. I'm not won over.

> (2) More important, I think developers are going to want to make these 
> distinctions explicit in their OWL-S code for easier > comprehensibility,

I doubt it strongly. Indeed, as far as I can tell, it flies in the face 
of a large trend in web services which is to minimize these 
distinctions as much as possible. It may be nuts, but it's real.

> and it may also be extremely useful for OWL-based reasoners to have 
> visibility into these distinctions.

?? I'd want something concrete here. I think you can easily infer them 
from the groundings, and there's no more needed for an automated 

>  I think both of these points represent important requirements.

The latter requirement, I'd claim, is equally if not better met by the 
current status quo. The former seems spurious to me, especially if one 
has tool based support to indicate *when* a call is going out.

> (3) I accept that there may be some times when you want to specify a 
> process model so abstractly

It's not that abstract.

> 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

I take this to be a fairly normal case.

>  (as Bijan, at least, has been arguing).

I guess I have :) Late binding!

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

Uh..Ok, backing please?

Compare with Erlang, which has function invocation and message passing, 
and a syntactic difference between them (though it *doesn't* have "on 
this machine/node, that machine node" or even a send to self vs. send 
to other heavy distinction, it's all *send*). We ground on WSDL. WSDL 
describes message exchange patterns (aka, "operations"). Those 
operations may be bound to local function calls (I imagine), but that 
layer we don't drill down to.

Ok, we may have a sense of local function invocation...tests in 
conditions, precondition evaluation, etc., but surely they're already 
clearly marked.

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

This presumes that you already know what *specific* services you are 
going to use. If so, you have the groundings. Given that, you should be 
able to easily derive this from the grounding. Why add redundant info 

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


I can see cases where you want to specify that some processes are off 
current machine, or something, but I don't see that a control construct 
is the answer.



Nope, these aren't floating my boat. In case anyone had hopes otherwise 

Bijan Parsia.
Received on Monday, 6 October 2003 20:24:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:10 UTC