W3C home > Mailing lists > Public > www-ws@w3.org > May 2003

Re: DAML-S ProcessModel

From: Sheila McIlraith <sam@ksl.Stanford.EDU>
Date: Mon, 19 May 2003 11:54:03 -0700 (PDT)
To: Stanislaw Ambroszkiewicz <sambrosz@ipipan.waw.pl>
cc: www-ws@w3.org, <agarwal@aifb.uni-karlsruhe.de>
Message-ID: <Pine.GSO.4.44.0305191149260.654-100000@ksl.Stanford.EDU>

If I understand you correctly, what you're proposing requires
web service providers to operate their web services in a very
different way than they do now.  Our objective with DAML-S was
to describe existing web services in a computer interpretable
form so that the type of interaction with WS that goes on
today by a human-being could instead be done by a computer program.
If we decide to change the way that Web services operate, I
agree that there are many new and compelling ways to design
such services, including the one you propose below.


On Mon, 19 May 2003, Stanislaw Ambroszkiewicz wrote:

> Dear Sheila,
> You wrote:
> "The DAML-S process model is still a declarative description of a process.
> Nevertheless the process is described in terms of procedural programming
> language/workflow constructs such as "if-then-else", "while"  etc.. As
> such, you can reason *about* the workflow/process using the DAML-S process
> model description.  This description provides the requester with
> the building blocks to have a conversation with the service -- an
> exchange of messages.  A composite process can have many possible
> execution trajectories, depending upon what messages are exchanged
> (imagine all the different executions you could have with amazon.com,
> depending upon what answers you gave to questions posed by the service).
> By providing this composite process model, a requester can analyse what
> answers it should give to questions to achieve a desired outcome.  This
> is important for automated composition tasks, among other things. "
> My reply:
> There is another way to realize this using "pure"
> declarative approach like in Prolog.
> In this case "a composite process" has exactly one
> "execution trajectory", however it has two phases:
> Query phase, and execution phase.
> This may be sketched as follows.
> Query phase:
> The requester specifies its "desired outcome", e.g.,
> "I want to buy a book of J.R.R. Tolkien".
> In the cyberspace it means that "an invoice for a book
> of Tolkien is delivered to the requester".
> The "desired outcome" must be expressed in a common
> generic conversation language.
> (As far as I know there are no means to express
> explicitly the "desired outcome" in DAML-S)
> The "desired outcome" is sent to bookstore.com.
> The bookstore.com has a look at its database and replies:
> "I will send you the invoice for a book of Tolkien, if
> you send me an order where:
> The title is 'The Lord of the Rings' and the price is 60 euro and ...
>  or
> the title is 'Hobbit' and the price is 30 euro  and ...
> ...
> This completes more or less the query phase.
> Execution phase:
> Once the requester receives the reply from the bookstore.com,
> it creates the order according to the options delivered by
> bookstore.com, fills some additional personal data to
> complete the order, and sends the order to the bookstore.com.
> (Of course, the choice made by the requester determines the
> execution path. However, it is done only by the requester
> who delivers the initial resources)
> The bookstore.com creates appropriate invoice and sends it
> back to the requester.
> This completes more or less the execution phase.
> Note that transactions is missed, however it is no problem
> to extend this approach with a transaction phase.
> As to "the service type" I will explain my view in the next
> email if it is still of interest.
> Best regards,
> Stanislaw,
>  -- Stanislaw Ambroszkiewicz
>  http://www.ipipan.waw.pl/mas/


Sheila McIlraith, PhD                 Phone: 650-723-7932
Senior Research Scientist             Fax:  650-725-5850
Knowledge Systems Lab
Department of Computer Science
Gates Sciences Building, 2A-248       http://www.ksl.stanford.edu/people/sam
Stanford University                   E-mail sam@ksl.stanford.edu
Stanford, CA 94305-9020
Received on Monday, 19 May 2003 14:54:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:08 UTC