[Fwd: Re: Conditionals :revisited]

  Forwarded as per Bijan's suggestion.... :-)

-------- Original Message --------
Subject: Re: Conditionals :revisited
Date: Wed, 27 Aug 2003 01:18:48 -0700 (PDT)
From: Sheila McIlraith <sam@ksl.Stanford.EDU>
To: Monika Solanki <monika@dmu.ac.uk>
CC: daml-process@bbn.com, terry <terry@acm.org>



Hi Monika,

Here is a brief response, since it's late!

On Wed, 27 Aug 2003, Monika Solanki wrote:

>
> Hi All,
>
> I am reading up the threads on Conditionals started by Terry and carried
> on by Sheila. Here, I am referring to the Congo Example for some details
> regarding these threads. Excuse me, if I bring out already discussed issues.
>
> In ExpressCongoBuy we have two output properties:
> 1.congoOrderShippedOutput - condition :BookInStock
> 2. congoOutOfStockOutput - condition :BookOutStock
>
> It is intutive that only one of these two would be true, however,
> nowhere is it specified that only one of these two would be outputted by
> service.  Should we not have something like this:
>
> 
>     
>     
>   


Yes.  I agree.


>
> Further, I am wondering why do we have two conditions, when we actually
> just need one. Is it possible to reduce this to something like :
>
> if(BookInStock)
>     congoOrderShippedOutput
> else
>     congoOutOfStockOutput
>
> (I am not too sure about the current scenario however when we do express
> conditions as logical formalism this can be a possibility )

You're correct that this is a succinct way to express it, but this
isn't the way conditional IOPEs are expressed in DAML-S, and since
we don't have a logical language to express negation, two conditions
are necessary, I believe.  (Perhaps you see a way around this.  We
are open to suggestions.)  We haven't revisted the actual representaiton
of conditionals in some time.  Indeed, Dave, Terry and I were
discussing that we should make them easier, since many have difficulty
with them the way they're expressed now.


>
> Sheila , correct me if I am wrong, however my interpretation from one of
> your emails was that in DAML-S we only need to specify the different
> outputs a service can generate and the conditions under which those
> outputs would be generated. We do not need to specify which condition
> needs to be true to generate a particular output.

I'm not sure I understand the distinction you're making.  If I've
misunderstood, please clarify.

I believe we do need to specify which conditions need to be true to
generate a particular output (as is done in the congo example above)
precisely for the reason you state below.  Nevertheless, there will
be cases where a service provider may not wish to expose *what* that
condition actually is (consider a loan provider who doesn't want to
divulge the criteria for loan approval/denial), but merely that it
exists. The representation needs to handle this case.  This is
similar to the notion of unexposed process models in BPEL.

> However somehow I feel
> that it is necessary to expose this aspect of the control flow in the
> ontology itself as it gives the service seeking agent apriori knowledge
> of what to expect from a service and consequently to decide whether to
> go ahead with service execution. In the current representation, I think,
> for a process we have all the conditional properties bundled together
> without any notion of which properties would be true for a particular
> execution trace (I may be wrong here.....) . With the changes from PAC
> to PAI it might be an idea to include this as part of the trace ontology.
>
> I would really appreciate more input from other members to help me clear
> my ideas on this issue.
>
> Thanks & Regards,
>
> Monika

Regards,
Sheila

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