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

Re: Unordered construct

From: David Martin <martin@AI.SRI.COM>
Date: Tue, 19 Oct 2004 12:17:21 -0700
Message-ID: <41756841.4000708@ai.sri.com>
To: Evren Sirin <evren@cs.umd.edu>
CC: jeff@inf.ed.ac.uk, public-sws-ig@w3.org

Evren Sirin wrote:

> 
> jeff@inf.ed.ac.uk wrote:
> 
>> Quoting Evren Sirin <evren@cs.umd.edu>:
>>
>>  
>>
>>> Description of Unordered construct in OWL-S 1.0 was closer to the first
>>> interpretation but for OWL-S 1.1 it is now being considered to adopt the
>>> second interpretation. There are couple of reasons for this change: 1)
>>> Sometimes it is more intuitive to think of composite processes as a
>>> single unit and it is required to put constraint on the composite
>>> process as a whole (as in the example Naveen pointed out) 2)
>>> Interleaving is already permitted in Split+Join and if interleaving
>>> between composite processes is allowed then in most cases concurrency
>>> between atomic processes can also be allowed.
>>>   
>>
>>
>> I find the proposed change very counterintuitive.
>>
>> "Unordered" sounds like a lack of constraints.  If anything,
>> it should even allow concurrency.  If we really want to change
>> the semantics, I think there should be a name change as well.
>> "Ordered"?  "Any-Order"?  "Permuted" :) ?
>>
>> It looks like there are three cases:
>>
>>  1. Concurrency (and hence interleaving) is allowed.
>>  2. Interleaving is allowed, but not concurrency.
>>  3. Neither is allowed.
>>
>> Right now, we lack (3), and the proposal is to change so that
>> we instead lack (2).  Is that right?
>>  
>>
> Yes.
> 
>> At the moment, perhaps it seems (to some?) that (3) is more
>> important than (2), but how do we know that won't change?
>> It all seems messy to me, without a clear rationale.
>>  
>>
> The rationale was what I tried to describe. In most of the cases you 
> either want interleaving all the way with concurrency (1) or you don't 
> want any kind of interleaving (3). The best use case we have for (2) is, 
> this definition aligns exactly with the "unordered tasks" notion in SHOP 
> planner. The main reason for not allowing concurrency (while allowing 
> interleaving) in SHOP is to avoid issues related to temporal reasoning. 
> However, it is still possible to convert the generated sequential plans 
> to concurrent ones (there is an algorithm called multi-timeline 
> preprocessing) Therefore, from process modelling perspective (1) almost 
> always seems preferable to (2). Do not forbid concurrency but if the 
> planner decides to perform some steps sequentially this is still valid 
> with respect to the definition of the control construct. Is this enough 
> reason to completely get rid of (2)? Maybe not. I'm not the expert on 
> this subject and I'm happy to hear other arguments.
> 
>> (I don't, by the way, think it's "clear that Unordered *should*
>> imply non-concurrency" [emphasis added].)
>>  
>>
> 
> I didn't mean that Unordered name itself implies non-concurrency. What I 
> meant was Unordered construct in OWL-S should not permit concurrency 
> because otherwise it is exactly same as the Split+Join construct. In 
> OWL-S 1.0 Unordered was defined to allow concurrency and that was why 
> clarifying the definition of Unordered was needed at the first place. 
> After there is a decision on the exact interpretation another name can 
> be chosen if needed. I personally think "Any-Order" is more appropriate 
> for (3).

In the OWL-S telecon this afternoon, in our great wisdom (and also with 
full awareness of the various positions expressed recently on this 
list), we have decided to take just the following action for the 1.1 
release:

We will rename Unordered to Any-Order and we will allow (some might say 
"ask") Evren to further refine the definition (if needed) to make it 
crystal clear that (3) is the intended semantics.

*provided* that Evren (who couldn't make the telecon) agrees to this 
decision.

Needless to say, other changes can be considered for future releases, 
beyond 1.1.

Regards,
David
Received on Tuesday, 19 October 2004 19:17:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:58 GMT