Re: Preconditions /effects vs Preconditions/Postconditions

Monika,

In DAML-S we are able to express conditional effects.  These are
the side effects of a web service, as contrasted with its output.
E.g.,  AcmeBookSeller Web Service:
  *output* is purchase receipt
  *conditionalEffect* is comprised of a *condition* and an *effect*
    the *effect* is that the book is sent to the customer,
    under the *condition* that the book is in stock.

Side effects of services are critical to encode for the purposes of
automated WS composition, where such effects must be considered in
composing and executing services.  (Something we humans do all the time.)

As to how this relates to the wschor document you were reading, it would
be helpful to have the citation, but without seeing it, here is a
general answer.  In the AI planning literature the term "effect" is often
used synonymously with the term "postcondition".  It is used
generically to captures the notion of effects which are either conditional
(i.e., conditional effects) or unconditional.

I'm guessing that ws-chor's notion of "postcondition" is used in this
context.  It is possible that they have done away with the notion of
condition in their "postcondition", because this is simpler, but I would
argue, is not sufficiently expressive to capture the true side effects
of web services.

As for what we need for WS composition, we need both the *effect*
and the *condition*, but the *effect* is the key notion.

Regards,
Sheila McIlraith


On Thu, 11 Sep 2003, Monika Solanki wrote:

>
> In DAML-S we have Preconditions and Effects(Conditions and Effect).
>
> BPEL4WS does not have the notion of Preconditions and Postconditions( to
> the best of my knowledge). However the ws-chor group  have defined
> Precondition and Postcondition for the use cases in their requirement
> document.
>
> I am wondering if the semantics of the "Conditions" for "Effects" as
> defined in DAML-S are different from "Post conditions" in ws-chor doc,
> as  what we are really interested in is the condition itself.  What
> would be lost (just for the sake of argument) if we were to discard the
> notion of "effect" and retain only the condition part of "Effect" i.e if
> I may call it,  "Post condition". I say this because I feel that in some
> way the effect part gets reflected in the output. Maybe "Effect" makes
> it more explicit. I guess even for service composition, what we are
> really interested in apart from input -output is the conditions that are
> captured in Preconditions and Effects. I guess what I am really trying
> to say is can we simplfy the notion of Conditional effects by
> attributing it as "post condition" without compromising anything that is
> not covered in any other property parameter.
>
> Any comments / thoughts well appreciated
>
> Thanks,
>
> Monika
>
> --
> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
> Monika Solanki
> Software Technology Research Laboratory(STRL)
> De Montfort University
> Hawthorn building, H00.18
> The Gateway
> Leicester LE1 9BH, UK
>
> phone: +44 (0)116 250 6170 intern: 6170
> email: monika@dmu.ac.uk
> web: http://www.cse.dmu.ac.uk/~monika
> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>
>

==============================================================================

*** Moving to Dept. Computer Science, University of Toronto ***

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-at-ksl-dot-stanford-dot-edu
Stanford, CA 94305-9020

Received on Thursday, 11 September 2003 12:44:47 UTC