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

Re: Defintion of a simple process

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Tue, 14 Sep 2004 17:09:30 -0400 (EDT)
Message-Id: <200409142109.i8EL9UwL022956@pantheon-po02.its.yale.edu>
To: public-sws-ig@w3.org

> [Charlie Abela]
> Date: Thu, 9 Sep 2004 21:37:27 +0200
> A simple process is defined as being an abstraction of an atomic or
> composite one.
> When defining such a process, it is still possible to define some of the
> internal structure of a composite service, right?
> For example:
> Suppose that a composite service A has the following workflow defined:
> <composite A>
> 	<sequence>
> 		<service B>
> 		<service C>
> 	</sequence>
> </composite A>
> and service B is atomic while C is composite
> <composite C>
> 	<if-then-else>
> 		<condition>
> 			<service D>
> 		<else>
> 			<service E>
> 	</if-then-else>
> </composite C>
> Now
> A Simple service representation X, for the above would be something like:
> <simpleprocess X>
> 	<expandsTo>
> 		<service A>
> 	</expandsTo>
> </simpleprocess X>
> What if I want to expose the other subtasks in this abstract form as well?
> How would I do that? Basically the idea is to have a short representation of
> the workflow represented in the process model.

This is a good question, and I realize that we don't really have a
good answer to it.  The Owl-S ontology doesn't impose any limits on
how many processes a simple process can expand to or be realized by.
In fact, the same simple process can be expanded to a composite _and_
realized by an atomic (although that would be unusual).  The semantics
here has to do with choice; an agent has more than one way to make an
abstract process (more) concrete.

But I think you wanted to talk about something different, namely, how
a _particular_ execution of a simple process gets expanded.  We need a
parallel set of properties for this purpose.  Another facet is the set
of expansion choices an agent commits to doing.  The property "to be
expanded thus" on process occurrences is not quite the same as
"expanded thus" on process executions, because in loops and
conditionals a given occurrence can give rise to an unpredictable
number of executions.

In your example there aren't any choices (at least, none are
mentioned), but you still might want to be able to describe the way(s)
A is grounded down to the level of atomic actions.

                                            -- Drew

                                             -- Drew McDermott
                                                Yale University CS Dept.
Received on Tuesday, 14 September 2004 21:09:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:46 UTC