- From: David Martin <martin@AI.SRI.COM>
- Date: Mon, 15 Sep 2003 09:59:34 -0700
- To: Jos de Bruijn <jos.de-bruijn@uibk.ac.at>
- Cc: Monika Solanki <monika@dmu.ac.uk>, www-ws@w3.org
Jos de Bruijn wrote: > Dear all, > > Here is a better quote from the WSMF document about what a > post-condition is in terms of Web Services: > > Post-conditions describe what a web service returns in response to its > input. > > A post-condition provides a declarative description of the relation that > must hold between the input and the output of the service. > A limitation of DAML-S in my opinion is the limited of the effect. Since > DL does not include variables, it is currently not possible to formulate > the post-condition of the service in the DAML-S "effect". Jos - I certainly agree that there is an issue about the expressiveness of DL, and whether it is adequate for capturing preconditions and effects. However, note that the current DAML-S/OWL-S release includes an appendix giving some recommendations about using DRS (Declarations in RDF made Simple), which does include variables, to express preconditions and effects. Also, DAML/OWL researchers are progressing towards a more expressive "rules language" (more expressive than DL, that is), which we also expect to be used in conjunction with OWL-S. Regards, David > > > Best, > Jos > > > Monika Solanki wrote: > >> Short reply for now. >> >> I guess, we all are talking about the same thing. The difference is >> maybe only in the way we put it across. Post condition is indeed the >> condition which is true after service execution. However, in the >> terminology that we use in DAML-S, an "Effect" may be produced under >> certian condition and this condition is true only after service >> execution, therefore this condition is the "Post condition". Quoting >> from WSMF document: >> >> The pre-condition is the condition that has to be true >> for the input in order for the web service to be able to successfully >> execute it. The postcondition >> is the condition that holds once the complex service has been executed >> successfully, i.e., it defines constraints on its output. >> >> >> Sheshagiri, Mithun wrote: >> >>> >>> >>> -----Original Message----- >>> *From:* Monika Solanki [mailto:monika@dmu.ac.uk] >>> *Sent:* Friday, September 12, 2003 6:18 PM >>> *To:* Sheshagiri, Mithun >>> *Cc:* 'Sheila McIlraith'; www-ws@w3.org >>> *Subject:* Re: Preconditions /effects vs Preconditions/Postconditions >>> >>> >>> >>> Sheshagiri, Mithun wrote: >>> >>>>I might be be wrong but I think Monika and Sheila are talking about two >>>>different conditions. >>>> >>>>Monika is talking about Effect of execution being a condition and this she >>>>terms as postcondition. >>>> >>> :-) .. Incidentally, by "Postcondition" , I mean precisely, the >>> conditions under which the "effect" is produced and which is alos >>> a subclass of ceCondition (which is also what Sheila is referring >>> to), and not "the effect of execution being a condition". >>> [Sheshagiri, Mithun] >>> >>> I was under the impression that postcondition would be >>> something that holds after the service is executed. >>> >>> AtomicProces: BuyBook >>> input: bookName >>> precondition: validUser >>> effect: points to disjointUnionOf(BookShippedEffect, >>> BookWillBeShippedEffect) >>> (BookShippedEffect, BookWillBeShippedEffect ) subClassOf >>> ConditionalEffect >>> BookShippedEffect >>> +------ceEffect BookShipped >>> +------ceCondition BookImmAvail >>> BookWillBeShippedEffect >>> +-------ceEffect BookWillBeShipped >>> +-------ceCondition ¬BookImmAvail >>> >>> BookImmAvail determines the effect so is it correct to call it >>> a postcondition? >>> >>> On the other hand, >>> The effect of executing an AtomicProcess might be the assertion >>> of a condition. I thought this would be a postcondition >>> >>> AtomicProcess: ValidateCC >>> input: CCname, CCnum, CCexpiry >>> effect: points disjointUnionOf(ValidEffect, InValidEffect) >>> (ValidEffect, InValidEffect) subClassOf ConditionalEffect >>> ValidEffect >>> +------ceEffect Valid >>> +------ceCondition CreditApproved >>> InValidEffect >>> +-------ceEffect InValid >>> +-------ceCondition ¬CreditApproved >>> ValidP /sameValues/ Valid >>> >>> Now Valid and ValidP could be subClassOf process.owl#Condition >>> and Valid is this case, IMHO, is a postcondition. And since >>> ceEffect can point to owl:Thing, this is permitted. >>> >>> phew! I need a program that generates names for my classes and >>> properties. >>> >>> >>> --Monika >>> >>>>(ceEffect points to a concept which is a subclassof >>>>process:#Condition. And Sheila is talking about the condition being pointed >>>>by ceCondition which decides the effect. >>>> >>>>mithun >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Sheila McIlraith [mailto:sam@ksl.Stanford.EDU] >>>>>Sent: Thursday, September 11, 2003 5:45 PM >>>>>To: Monika Solanki >>>>>Cc: www-ws@w3.org >>>>>Subject: 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> -- >>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<** >>> 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 >>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<** >>> >> >> -- >> **>><<**>><<**>><<**>><<**>><<**>><<**>><<** >> 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 >> **>><<**>><<**>><<**>><<**>><<**>><<**>><<** >> > > -- > Jos de Bruijn > > Institute of Computer Science > University of Innsbruck > Technikerstraße 13 > A-6020 Innsbruck > Austria > > Tel: +43 512 507 6475 > Fax: +43 512 507 9872 > Email: jos.de-bruijn@uibk.ac.at > Homepage: http://homepage.uibk.ac.at/~c703239/ > > Next Web Generation research group > http://www.nextwebgeneration.org/ >
Received on Monday, 15 September 2003 12:59:30 UTC