- From: David Martin <martin@AI.SRI.COM>
- Date: Mon, 15 Sep 2003 10:04:36 -0700
- To: Monika Solanki <monika@dmu.ac.uk>
- Cc: www-ws@w3.org
Monika Solanki wrote: > > > Hi David, > > David Martin wrote: > >> Hi Monika - >> >> I believe you have been saying that a "postcondition" in DAML-S (if >> that term were used) would be the same as the condition of a >> conditional effect. I guess, since we don't normally talk about >> "postconditions" in DAMl-S documentation, there's no precise answer. >> But I tend to think of it differently than (I think) you've been >> saying. more below ... >> >> 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, >> >> >> >> >> If you are talking about conditions of conditional effects, it >> doesn't seem quite accurate to say they are true only after service >> execution. At least for some such conditions they may also be true >> before service execution. For example, "book in stock" might >> certainly be true (or false) both before service execution and after. >> >> therefore this condition is the "Post condition". >> >> Actually, I tend to think of "postcondition" and "effect" as >> synonymous. So then, in my mind at least, a postcondition would not >> be the same as the condition part of a conditional effect; rather it >> would be the same as the effect part. > > > The ambiguity in thinking about it in this way is that the "Effect" part > maps to "Thing", while only the "Condition" part maps to "Condition". > This is also what I had mentioned in the first or second email of this > thread. Is this "Effect part" a logical formulae, if it is the same as a > condition? If it were indeed to be , then I believe, that ceEffect > should map to "Condition" as well I agree that Condition should be the range of ceEffect. I expect we will be discussing this soon, in the context of a larger range of issues about conditions and effects. , although I am still not sure, if the > semantics of "Post Condition" would be that of "Effect " or "Condition > part of Effect" or a conjunction of the two. I'm not sure either, but I think Michael Kifer put forward an excellent way of thinking about this. In any case, let's remember that if we don't use "postcondition" in OWL-S specs, than we don't necessarily have to struggle over the precise definition of that term :-). -- David > >> >> I can't say for sure whether others in the DAML-S Coalition hold the >> same view on this as me, but I think most probably do. >> >> Regards, >> -- David >> >> 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 >>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<** >>> >> >
Received on Monday, 15 September 2003 13:04:22 UTC