Fw: Unordered construct

Evren Sirin, please a question about your last comment on split+join vs.
unordered, see below

----- Original Message ----- 
From: "Evren Sirin" <evren@cs.umd.edu>
To: <jeff@inf.ed.ac.uk>
Cc: <public-sws-ig@w3.org>
Sent: Tuesday, October 12, 2004 5:59 AM
Subject: Re: Unordered construct


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

Is this really true? Because in the description of Split+Join is mentioned:
" concurrent execution of a buch of process components with barrier
synchronisation .... "
While in the Unordered/Any-Order description no barrier-synchronisation
mechanism is mentioned.
But what is the exact meaning of barrier-synchronisation and what is the
difference between barrier-synchronisation and an execution-schedule-plan
requiring some synchronisation?
And how is synchronisation in general and especially this
barrier-synchronisation made for control-constructs?
Its not really clear to me from the OWL-S document and files how these
synchronisation is done and how it looks like.
Is my assumtion right, that the synchonisation of Sub-Processes is encoded
in the
precondition-expressions of processes with some kind of external semaphores?

Thanks for any answer

Claus P.
(cspriese@gmx.de)

> 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).
>
> Evren
>
>>-- Jeff
>>
>>
>>
>>
>
>

Received on Wednesday, 17 November 2004 21:38:42 UTC