Re: [OWL-S] Who does what?

   [David Martin]
   It seems to me there are three paths towards getting OWL-S to meet these 
   requirements [which I revisit below].  These aren't necessarily
   exclusive; that is, the solution might be some combination of
   elements from these paths.  Also, there might be other paths that
   I'm not including here.

   (1) Make "who does what" more explicit in OWL-S process models, by 
   relying on "participant", and adding additional, related, constructs as 
   needed to spell it out.

Attractive idea, but it will ultimately disappoint you.

   (2) Convince ourselves that OWL-S groundings can provide the missing 
   information, and extend them if needed, and document how this works.

Bad idea.  Or maybe it's an incoherent idea.  Or maybe it's my fault
for not really knowing what it means.

   Note that these first 2 paths allow for the specification of all the 
   roles within a single process model, which is what most of our 
   discussions seem to assume.  The 3rd path, however, relies on separate 
   process models for the different roles.

   (3) Adopt a convention of specifying a separate process model for each 
   role (so that a role gets associated with an entire process model rather 
   than with individual process steps within the more complex process 
   models of (1) and (2)).  And make sure we have an appropriate set of 
   constructs to support this convention.

Only really workable idea.

The problem with the first scheme is that it works fine as long as
the participants are more or less in synchrony.  But as soon as they
diverge somehow (even pause from communicating with each other while
they communicate with other parties), then either you have to
represent the Cartesian product of their states; or you have to allow
their process lines to diverge, and then you wind up here, at the
bitter end of this paragraph.

Instead, if you start by representing their processes separately, then
all you have to do to represent the joint choreography is to indicate
that a certain act in one player's script is a possible or normal
reaction to an act is another player's script.  Neither player needs
this information to act, but a reasoner can draw conclusions from it.

Then David's desiderata are accomplished thus:

   (a)    It should be possible to specify (composite) processes involving 
   multiple roles (not just the usual two - provider/requester - that we 
   talk about the most).

You can have any number of participants.

   (b)    It should be possible to specify all possible* combinations of 
   "who does what"; that is, which roles perform which steps (including 
   evaluating conditions).
     *under some reasonable analysis of what's possible, which I won't 
   address here

Does your reasonable analysis include the possibility that different
roles do the same step in different enactments of the process?

If so, I'm not sure whether the position I endorse can't handle that.
On the other hand, it could represent a script where two role takers
normally negotiate who is to do what; or a script in which two role
takers consult the same rule in deciding who does what, so they don't
have to negotiate.  Is there another way that different role players
could perform a given step?  What if two role players _both_ do a
given step?  Is that allowed or should the results be undefined?

   (c)    It should be possible to unambiguously express 
   "fully-fleshed-out" processes -- that is, processes that are executable 
   by some set of enactment engines -- where "unambiguously" means, I 
   think, that one can easily make an assignment of roles to enactment 
   engines, and, once such an assignment has been made, the behavior of 
   each enactment engine is then clearly spelled out.

Not a problem for trusty idea #3.

-- 
                                   -- Drew McDermott
                                      Yale Computer Science Department

Received on Friday, 19 December 2003 19:33:01 UTC