RE: FW: Semantics of Preconditions and Effects

> This effect is actually a knowledge effect (since it is only a change in
the state of the knowledge of the client and not an actual physical change
in the state of the world). 
 
Hmmm.... is there not also a change in the state of the knowledge of the
loan provider. It has received a request for a loan and it knows whether or
not it has accepted the request. This will likely have an effect on its
willingness to advance funds to a borrower - ie. there is some (partial)
model of the world that is shared between requester and provider and the
interaction has had an effect on respective preceptions of the state of that
shared world (tending toward synchrony).
 
Stuart

-----Original Message-----
From: Monika Solanki [mailto:monika@dmu.ac.uk] 
Sent: 3 September 2003 14:11
To: Battle, Steve; www-ws@w3.org
Subject: Re: FW: Semantics of Preconditions and Effects





The (situation calculus) semantics of the conditional effect tells us that
following the output, we are in a situation s where we know 'loan-denied'.
I think this licenses us to remove the scare quotes from "loan denied" and
to interpret the output as telling us about the state of the world - at
least in terms of what the customer can be said to know at this point. It
doesn't require reasoning about my credit rating.
 
knows(loan-denied,s)
 
Given that we can only know something that is in fact true, it surely
follows that my loan is denied in situation s.
 
loan-denied(s)
 
I'm actually restating Mithun's point that we can only  talk about things
that are directly represented in the output (or elsewhere in additional
post-conditions).
It is this fact that  may be used in subsequent conditions (e.g. to prevent
a denied application from going through), and the customer has sufficient
information to be able to reason correctly about the (negative) outcome.


Am I right in understanding  that over here, you are implying that such an
output, implicitly implies an effect. 
knows(loan-denied,s)
and therefore it is possible to use this implicit effect as a precondition
for composition with another service?

This effect is actually a knowledge effect (since it is only a change in the
state of the knowledge of the client and not an actual physical change in
the state of the world). As I understand from Sheila's response to my
earlier mail, that these kind of knowledge effects get manifested in
"outputs", as you have mentioned above that the output is "loan denied". My
conclusion from Sheila' s response was that we cannot really consider
effects of such kinds as the "effects"  that DAML-S service specification
implies and therefore we cannot use it in that context. So when composing
these kind of services with others, maybe we have to look only for an
output-input mapping rather than a precondition-effect mapping, since there
is actually no effect generated.  


 
As it says on the wall of many an English Pub, "Please do not ask for
credit, as a refusal often offends".
 
 Steve.

-Regards,

Monika


-----Original Message-----
From: Sheshagiri, Mithun [mailto:Mithun.Sheshagiri@hp.com
<mailto:Mithun.Sheshagiri@hp.com> ]
Sent: Thursday, August 28, 2003 3:18 PM
To: 'Monika Solanki'; Sheshagiri, Mithun
Cc: daml-process@bbn.com <mailto:daml-process@bbn.com> ; www-ws;
'steve.battle@hp.com <mailto:steve.battle@hp.com> '
Subject: RE: Semantics of Preconditions and Effects


 

-----Original Message-----
From: Monika Solanki [mailto:monika@dmu.ac.uk <mailto:monika@dmu.ac.uk> ] 
Sent: Wednesday, August 27, 2003 5:59 PM
To: Sheshagiri, Mithun
Cc: daml-process@bbn.com <mailto:daml-process@bbn.com> ; www-ws;
'steve.battle@hp.com <mailto:steve.battle@hp.com> '
Subject: Re: Semantics of Preconditions and Effects



Sheshagiri, Mithun wrote:



Since ceEffect points to owl:Thing, there is nothing that prevents you from
representing Knows(ISBN) as an effect. Also, it is useful to have a means by
which you can generate an effect which is also a precondition for some other
service.

This is precisely what I was aiming at.



 
I also had some doubts about the semantics of conditional O/Es.
 
Loan Service:
   1. output = "loan approved", if creditRating = good
   2. output = "loan denied", if creditRating = poor
 
If this were the advertised service and after execution of the service using
WSDL, I get my output as "loan denied". It is important to know the value of
CreditRating, since it could be used to determine the cause of  the
output:"loan denied" and a contingency plan can be worked out. There are 2
ways of finding the value of creditRating: make it part of the output
message or deduce it from the output.
At per current spec, the value of creditRating is not part of the WSDL
grounding (output message). Is it correct to deduce that my creditRating is
"poor" from the output "loan denied"? If this deduction is correct, then the
semantics is IFF.
 

I don't think so it is correct to deduce anything 
(a) if it is not specifiied explicitly in the output
(b) if it is not specified anywhere in the service ontology specification

As Sheila mentioned in one of the other emails that it may be possible that
a provider may not want to divulge the details abt loan denial. In such a
scenario, no deductions can be made. 
[Sheshagiri, Mithun] 
In this particular case, since the service provider did describe condition
creditRating as part of the service ontology, he/she does want the user to
know the the reason for loan denial/loan approval. 

Alternatively if the semantics is only an implication, 

I think it should be, atleast logically it makes sense.


is the following correct:
As part of the service description I make the following additional
statements:
3. output of Loan Service is disjointUnionOf  ("loan approved" and "loan
denied")

I think we do need to specify something like this 


4. "loan approved" owl:complementOf "loan denied"
5. So when I get the output "loan denied" can I say something like
output(loan denied) is equivalent to ¬output(loan approved)
6. From 1. (and assuming ¬good=poor), I have creditRating=poor 
 

This can be discussed further as Bijan has suggested in one of the other
emails


And if value of creditRating cannot be found by any means (explicit,
deduction or some other service), then is there a need for using
creditRating in describing th service? This problem could be solved by
sending the value of creditRating as part of the output.

Since nothing is mandatory in the specification currently, I guess it all
depends on the service provider, i.e. if he wants to send it as part of the
output
[Sheshagiri, Mithun] 
I guess what I am trying to say is that if a publisher of the service wants
to convey something than he/she should have the means to do so. If the Loan
Service provider adhered to current specs, the value of the condition cannot
be conveyed. Please correct me if I am wrong

 

mithun

http://www.cs.umbc.edu/~mits1 <http://www.cs.umbc.edu/%7Emits1> 
 

Any comments from other members appreciated

Cheers,

Monika


-----Original Message-----
From: Monika Solanki [mailto:monika@dmu.ac.uk <mailto:monika@dmu.ac.uk> ] 
Sent: Wednesday, August 27, 2003 2:26 PM
To: daml-process@bbn.com <mailto:daml-process@bbn.com> ; www-ws
Subject: Semantics of Preconditions and Effects



Hi All,

I am trying to understand the semantics of preconditions and effects . In
one of the papers 

Narayanan, S. and McIlraith, S., "Simulation, Verification and Automated
Composition of Web Services", 

I found that preconditions for any service can also be modelled as knowledge
based apart from physical preconditions.For e.g: agent Knows(bookName) for a
service like LocateBook. I am interested in knowing whether agent can have
knowledge based effects as well for e.g: agent Knows(ISBN), especially for
information providing services.

Any thoughts appreciated.
  
Cheers,

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 <mailto:monika@dmu.ac.uk>  
web: http://www.cse.dmu.ac.uk/~monika <http://www.cse.dmu.ac.uk/%7Emonika> 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**


-- 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<** 
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 <mailto:monika@dmu.ac.uk>  
web: http://www.cse.dmu.ac.uk/~monika <http://www.cse.dmu.ac.uk/%7Emonika> 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**



-- 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<** 
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 <mailto:monika@dmu.ac.uk>  
web: http://www.cse.dmu.ac.uk/~monika <http://www.cse.dmu.ac.uk/~monika> 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**