Re: [OWL-S] Who does what?

Hi Drew -

Thanks belatedly for your thoughtful comments regarding these 
alternatives.  I agree with your conclusion, but I'm not entirely clear 
about your main point ... let me play devil's advocate ...

Drew McDermott wrote:

>    [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.

I guess I was actually thinking that (1) and (3) were complementary 
approaches.  That is, I'm imagining a single all-role-encompassing 
process model PM, as in (1), which is so completely explicit about which 
steps are carried out by which roles (more explicit than OWL-S currently 
supports), that either of the following would be possible:

a) a tool could extract separate process models from PM - one for each 
role - so that the output of the tool would be the same as (3), and then 
the style-(3) process models could be enacted
OR
b) you could feed the PM into an enactment engine, and tell it to "play 
role A", and it would be able to just enact the steps for role A (so 
that the effect would be the same as if it were enacting a separate 
style-(3) process model for role A)

So I'm thinking that the choice between specifying a multi role process 
in style-(1) vs style-(3) would be a matter of engineering convenience; 
not so much a matter of which style is more expressive.  But you seem to 
be saying that style-(1) is in principle broken, and I don't yet see 
why.  [Is it because style-(1) would be clear about who *enacts* each 
service, but would not be clear about when they are *invoked*, and by whom?]

> 
> 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; 

Who has to represent the Cartesian product?  I guess you must be 
thinking that each enactment engine would have to do that; in other 
words, each enactment engine is keeping track of all the possible states 
of all of the participants.

I think you must be making some assumption that I'm not making.  It 
seems to me that if my (b) is possible, then approach (1) is no more 
problematic than (3) - (although I tend to think (1) is messier and 
harder to think about).

Please clarify if you can - or wait until our next teleconference if you 
prefer.

Thanks,
David

> 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.
>

Received on Monday, 5 January 2004 01:39:48 UTC