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

Minutes SWSL telecon - March 4, 2004 #42

From: Battle, Steve <steve.battle@hp.com>
Date: Fri, 12 Mar 2004 16:44:14 -0000
Message-ID: <E864E95CB35C1C46B72FEA0626A2E80820100B@0-mail-br1.hpl.hp.com>
To: public-sws-ig@w3.org

=========================================
Minutes SWSL telecon - March 4, 2004  #42
=========================================

Participants:
BG Benjamin Grosof
DB Daniela Berardi
DM David Martin
MK Michael Kifer
RH Rick Hull
SB Steve Battle
SM Sheila McIlraith

scribe: SB

Minutes
-------

Daniela presented - Automatic Composition of eServices: the "Roman" way

DB: (e-service as Execution tree)
DB: Actions are transparently delegated. Data is not modelled.
SB: Is the choice of branch followed (in the execution tree) determined by
the client?
DB: Yes
SM: Are a,b only actions, and not concerned with parameters?
RH: We have two parameters (search by author or by title) so we have two
actions.
SM: Say we are searching for books on Amazon. We have 500K books or so. Do
we have 500K  separate actions?
RH: No, we still search either by author or title.
MK: Will we be looking at the differences with Rick's approach later?
RH: Yes.

DB: (eService composition in the "Roman Framework")
MK: What is the target eService (S0)?
RH: The desired global behaviour, the goal. S' (the delegator) is
constructed to use available  services. We have a desired composite S0, and
it constructs S'. S' delegates the doing of  a,b,r to S1 and S2.
MK: But what is the connection between S0 and S'; can it be an
approximation?
DB: a,b,r become virtual action on S'.
RH: S0 is the desired behacviour. S' is able to talk to a client and
delegate, bossing S1,S2  around.
SM: S0 (the target) appears to be a complete spec of all the transitions in
the service. This  is unlike classic planning where we aim to reach a goal
state.
DB: It's fundamental that S0 is a complete description. We're looking to
extend the framework  so they need not be complete.
SM: Is there any notion of state? For example, in Amazon a book may be out
of stock. In the  situation calculus this would be represented as a fluent,
or in OWL-S as an effect.
DB: States are encoded by fluents.

DB: (Key idea for finding composition: exploit description logics)
DB: We can model dynamic behaviour with a description logic encoding.

DB: (Results on automatically building eService composition)
DB: If the DL knowledge base is satisfiable we build a model. The solution
is the delegator.
RH: If we take a naive approach we end up with exponential space, but we use
FSMs to get  exponential time. What is the lower bound?
SM: What kind of DL reasoner do you use?
DB: ALC
DM: Is there a technical report available?
DB: Yes <http://www.dis.uniroma1.it/pub/calvanes/bera-etal-TR-22-2003.pdf>.

DB: (Results)
MK: You are reducing the problem of constructing an FSM to DL. Do known
techniques provide  similar reductions?
DB: Yes, composition in dymanic logic can be moved to DL, exploiting a 1-1
correspondence.
RH: Existing approaches look at synthesis or verification. This approach
starts with multiple,  pre-existing FSMs and combines them. Others have
looked at starting with a single FSM and  restricting it to get the desired
behaviour, synthesising a controller. We are, in effect,  marrying these two
approaches, so we have not a single controller but a controller of multiple
pre-existing FSMs.
MG: Robert Floyd was interested in algorithms to compose automata
<http://news-service.stanford.edu/news/2001/november7/floydobit-117.html>.
RH: There is a community looking at FSM descriptions of eServices. I think
they are gradually  looking to the classical literature.
MK: He really invented automata theory. It's important to drill down to
fundamentals.
MG: There is also Jimmy Crawford's work.

DB: (e-composition schema)
SM: Are the messages synonymous with actions?
RH: No, a particular action may depend on information from two different
peers. We're  interested in syntheising a model that embraces both actions
and messages.
MK: In principle even a message can be encoded as an action.
RH: Can we build a bridge to actions that have preconditions and effects? We
can go from the  messaging model to Danielas model, but not yet all the way
to DAML-S.
SM: Do you mean execution actions rather than what is really being
performed?
RH: Yes - actions in terms of effects.
MK: So messages are low-level actions, but there's no representation of what
they do. What  about describing the peers with pi-calculus to represent what
each guy is doing?
RH: With the pi-calculus, individual components are basically FSMs. But
pi-calculus doesn't  look at unbounded queues, all communication is
synchronous. The kinds of questions we ask are  different to those asked by
the pi-calculus people.

DB: ("Roman" activity based vs. message based)
SM: Was the activity based model developed in OWL-S the right choice? Things
like BPEL are  more message based.
RH: Can we take Danielas result and apply it to the message based model?
RH: 1) How do we represent a single eService? Using a FSM, transitions can
be labelled with  incoming and outgoing messages, or actions (changes to the
world). 2) How does composition  allow for messages?
MK: Can these internal actions be represented as a change in a database?
RH: As a change in the fluents representing the outside world.
SM: How do actions relate to messages? Is the relation indexed by a
situation, and is  therefore a fluent?
RH: They're fluents by definition.
RH: The message passing model is interesting. We want to represent them in
the most natural  way with their subtle aspect formally present before
simplifying and reducing. We don't want  to prematurely force them into the
situation calculus.
SM: What about data? How do I model Amazon as an FSM without parameters?
DB: This is a high level of abstraction.
SM: This is a different starting point to DAML-S. Any WS that takes input is
parameterized. Do  we enumerate all the ground actions or limit ourselves to
services without parameters. What if  the output is a function of the
parameter values?
RH: That's a non-determisism based on the parameter value. The service makes
the choice to go  one way or the other. But in the Roman model it's always
the client that makes the  non-deterministic choice.
SM: The parameter may also dictate the services we require (eg. buy me a
ticket to Hawaii).

All agreed to continue with the presentation at the next telecon.


Actions arising: MG to send reference to Robert Floyds work to list.
Received on Monday, 15 March 2004 12:22:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 9 December 2014 23:03:41 UTC