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 09:59:34 -0700
Message-ID: <3F65EFF6.1010802@ai.sri.com>
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 GMT

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