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".

--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
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**