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

Re: Preconditions /effects vs Preconditions/Postconditions

From: David Martin <martin@AI.SRI.COM>
Date: Mon, 15 Sep 2003 10:04:36 -0700
Message-ID: <3F65F124.5090508@ai.sri.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:44 GMT