- From: Monika Solanki <monika@dmu.ac.uk>
- Date: Wed, 03 Sep 2003 14:13:16 +0100
- To: "Battle, Steve" <Steve_Battle@hplb.hpl.hp.com>, www-ws@w3.org
- Message-ID: <3F55E8EC.2000707@dmu.ac.uk>
> 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]
> Sent: Thursday, August 28, 2003 3:18 PM
> To: 'Monika Solanki'; Sheshagiri, Mithun
> Cc: daml-process@bbn.com; www-ws; 'steve.battle@hp.com'
> Subject: RE: Semantics of Preconditions and Effects
>
>
>
> -----Original Message-----
> From: Monika Solanki [mailto:monika@dmu.ac.uk]
> Sent: Wednesday, August 27, 2003 5:59 PM
> To: Sheshagiri, Mithun
> Cc: daml-process@bbn.com; www-ws; '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]
>> Sent: Wednesday, August 27, 2003 2:26 PM
>> To: 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
>> 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 Wednesday, 3 September 2003 09:11:04 UTC