- From: Monika Solanki <monika@dmu.ac.uk>
- Date: Mon, 15 Sep 2003 18:21:18 +0100
- To: www-ws@w3.org
:-) .. I too agree with Martin to a very great extent. However, IMHO, we still need to define precisely the semantics and scope of : *output*, *Conditions for output*, "effect*, *Conditions for effect* to avoid any ambiguity and if/how they differ from "Post conditions" as specified in many other service specification languages. Thanks for the great discussion, any more inputs, well appreciated. David Martin wrote: > > > 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 >>>> **>><<**>><<**>><<**>><<**>><<**>><<**>><<** >>>> >>> >> > -- **>><<**>><<**>><<**>><<**>><<**>><<**>><<** 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:15:09 UTC