- From: csp <cspriese@gmx.de>
- Date: Wed, 17 Nov 2004 18:48:01 +0100
- To: <evren@cs.umd.edu>, <public-sws-ig@w3.org>
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