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.
> > > 
> > [me]
> > 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:

I guess this is the problem: Position (1) assumes that the links
between steps in a process are like the links between actors in two
different processes.  There are some clear cases where they do
resemble each other, such as 

    Step 2 can't run until data from step 1 are available.
    Agent B can't run until message from agent A is received.

The problem is that these resemblances are superficial.  For example,
suppose the message from A is never received.  In this case B may
timeout and decide what to do about A's disappearance.  It might, for
instance, find an A' to deal with, or just abort the whole
transaction.

Whereas if step 2 never receives the data from step 1, that is not
step 2's problem.  In fact, step 2 doesn't _exist_ until step 1 is
finished.  If step 1 times out, it is the responsibility for the agent
enacting this process to decide what to do (or the responsibility of
some exception handler for this thread of the agent, or whatever).  In
fact, step 1 might be part of B's process for dealing with agent A.
It would be somewhat bizarre, maybe even circular, to think of B's
steps as homunculi that must react to each other's stumbles as though
they were autonomous entities.

> > [me]
> > 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; 
> 
> [David]
> 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.
> 

No, I was thinking that if the process must represent its entire state
in situations such as the one in which A and B have broken off
contact, then A and B will be behaving for a while as if completely
unsychronized, and so the possible states of the "process" will be the
Cartesian product of the possible states of A and B during that
period.

I should admit that I'm not opposed in principle to the idea of
representing the interaction between a bunch of actors as one big
diagram, if the result is increased clarity.  I'm just claiming that
the connections within an agent will be quite different from the
connections between agents, and the notation should reflect that
fact. 

                                             -- Drew

-- 
                                   -- Drew McDermott
                                      Yale Computer Science Department

Received on Monday, 5 January 2004 15:14:12 UTC