Re: Doubt about expressing partial order plan in OWL-S 1.1

> > [me]
> > Actually, it doesn't.  It's been replaced by "Any-order," which
> > requires its steps to be executed in sequence, without saying _which_
> > sequence.
> 
> [Manshan Lin]
> Since there are "Any-order" in OWL-S 1.1, it means that some processes 
> without ordering constraints cannot be executed in parallel. But how can
> we know an process can not be executed in parallel with another process?
> Is there any markup in OWL-S 1.1 indicating this? Or the choice between
> "Any-order" and "Split-join" is up to the user, who models the process?
> If the user, who is constructing the new composite process, is not familiar
> with the component processes' implementation, what's the criteria for the
> choice?

The short answer is that a composite process is indeed designed by the
"user" (a famously slippery word, which certainly doesn't mean the
"end user" here), and that the designer _expresses_ that the steps are
to be executed in some nonoverlapping order; that doesn't mean that
it's impossible or counterproductive to execute them in some other
way.

The long answer is that Owl-S doesn't embody a solution to the
process-composition problem.  For that matter, it's only a start at
the problem of dealing with a single service.  It needs a better
treatment of conditionals and loops before it can even express the
_answers_ to composition problems.  

The semantics of Any-order reflects two things: (1) It's easy to
state; (2) the process designer might have _client-side_ reasons for
avoiding overlap among the processes (i.e., a desire to make certain
side-effect sequences be atomic).  That's a pretty arbitrary pair of
issues to start with, but you have to start somewhere.  The next phase
is a lot tougher: come up with a set of composition mechanisms that is
powerful enough to handle most composite processes, and constrained
enough that such processes can be generated automatically, or
semiautomatically. 

-- 

                                         -- Drew McDermott
                                            Yale University
                                            Computer Science Department

Received on Saturday, 1 January 2005 15:51:46 UTC