W3C home > Mailing lists > Public > public-sws-ig@w3.org > September 2004

Re: A bunch of OWL-S difficulties

From: David Martin <martin@AI.SRI.COM>
Date: Tue, 21 Sep 2004 14:51:22 -0700
Message-ID: <4150A25A.1050207@ai.sri.com>
To: Daniel Elenius <daele@ida.liu.se>
CC: public-sws-ig@w3.org

Daniel Elenius wrote:

> David Martin wrote:
>>> 5) Split+Join vs Unordered
>>> What is the difference between these two control constructs? Can I 
>>> get an example to show the difference?
>> From the technical overview, it appears to me that there's only one 
>> difference: split+join indicates *concurrent* execution of a group of 
>> activities, whereas unordered is non-committal on that point.  That 
>> is, unordered is "looser", in that it could allow for either a 
>> sequential or a concurrent execution (or perhaps some arbitrary 
>> combination of the 2 approaches).  (Thus, informally, one could think 
>> of the set of unordered executions as a superset of the set of 
>> split+join executions.)
>> As to how often anyone would care about this distinction, or if it 
>> should be retained, that's a separate matter I guess.  Comments are 
>> welcome on this question.
>> Regards,
>> David
> Wouldn't a concurrent execution also include sequential execution as an
> extreme case? If you execute things concurrently on a  single-cpu
> computer, you switch back and forth, and it could be the case that one
> process completes before the other one starts. The concurrency semantics
> are simply non-commital on this point. At least in the OS case. And I
> don't see why the case with distributed processes should be any
> different. For example, if a composite process has a Split+Join with
> processes A and B, would the user be doing a mistake if he did not
> create a new thread and started both concurrently? I don't think so, I
> think he should be allowed to execute A, wait for the return values,
> then execute B, if he prefers. Separating the two cases seems to go into
> implementation issues rather than process semantics.

Yes, indeed I am sympathetic with your view, at least from the point of 
view of what is the most widespread understanding of these constructs, 
and from the point of view that it's easier to define and implement 
non-concurrency than concurrency.  We discussed this in the OWL-S 
telecon this morning, and I think everyone present was sympathetic.

We discussed the following possible steps:

(1) Clarifying Split and Split+Join, to indicate that they allow 
concurrency, but do not necessarily insist upon it.

(2) Redefining Unordered, to indicate that it actually insists upon 
*non-concurrent* execution, but where any ordering is acceptable.  (Note 
that this would be a very significant change from the current definition 
in the OWL-S technical overview.  But one or two users have already 
adopted this proposed definition anyway.)

(3) (not directly related to 1 and 2) Eliminating Iterate, because we do 
not think it will ever get used as it is defined.

Note that these constructs were based on the work of a founding member 
of the OWL-S Coalition, who is no longer present to advocate/defend the 
current definitions.  If the current definitions are causing too much 
confusion, we are open to changing them, perhaps as suggested above.  On 
the other hand, we don't want to make a change that ignores any widely 
accepted definitions, or that messes up anyone's work on semantics or 
tools for OWL-S, so we have to be somewhat cautious about this.

I would welcome additional input from people have expertise in this area.

Regards, David
Received on Thursday, 23 September 2004 10:46:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:46 UTC