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