Re: DAML-S: Conditional E/Os

Mithun,

I second Mark's comments.  Conditons that dictate outputs and
effects are important in many circumstances.   Many people confuse
preconditions with the conditions in conditional outputs/effects.
Nevertheless, most conditions are indeed the conditions in conditional
effects/outputs rather than precoditions.

To demonstrate the usefulness of conditional outputs/effects, imagine the
following simple examples:

Loan Service:
   output = "loan approved", if creditRating = good
   output = "loan denied", if creditRating = poor


CaliforniaAlcoholStore Service:
   output = "your order will be shipped", if age >= 21
   output = "sorry we may not sell you alcohol in the state of California"
             if age < 21

In some cases the condition is determined by the service, as is the case
with CongoExpress and the Loan Service above.  In such cases, it is
useful to know what the condition is because it allows you to determine a
suitable alternative course of action.

In cases where the user/agent knows the value of the condition in advance,
articulation of the condition allows the agent to determine whether or
not a service will have the desired outcome.  If you already know that
you're under 21, then there is no point in attempting to buy alcohol
at the CaliforniaAlcoholStore, similarly, if you know that Congo doesn't
have a particular book in stock, then there is no point in trying to
order it via CongoExpress.

Sheila


> I see where you are going with this. I guess, to some degree you are
> correct that the truth value of this term
> is not useful in this context, at least not for an isolated service request.
> However, it might be the case that there were other ways for the client to know
> whether the book was in stock, and this might lead to the conclusion that
> the service was not useful in some cases -
> (for some books). Suppose, for example, another service provided by this
> provider was an "in stock' query. Or suppose that the requester routinely
> tried a couple times before giving up. It would be good to establish that
> the reason for failure was such that the condition dictating the failure
> outcome existed so that the requester didn't try again to buy that
> particular book from that site.
>
>
> At 08:55 PM 5/25/2003 -0400, mithun sheshagiri wrote:
> >Hi All,
> >               Lets take the example of ExpressCongoBuy atomic service.
> > This service has 2 conditional  outputs- congoOrderShippedOut and
> > congoOutOfStockOutput. Only one of these will materialize (depending on
> > the BookInStock and BookOutStock conditions) on service execution.
> >
> >In this case what is the use of BookInStock/BookOutStock? The "values" of
> >these variables are not part of the advertisement, since the value depends
> >on congoBuyBookISBN (input). The value of this variable can be known only
> >when the response from service provider is received. Now, if I get the
> >desired output then I won't be interested in BookInStock because I know it
> >is true. If I get the undesired output, then I can use the value of the
> >condition variable to determine whether failure was due to a normal
> >problem (book being out of stock) or a abnormal problem (book was in stock
> >and still the service did  not execute as intended). So, is diagnosis the
> >only purpose of condition variable.
> >
> >--
> >Mithun Sheshagiri
> ><http://www.cs.umbc.edu/~mits1>http://www.cs.umbc.edu/~mits1
>
> * Dr. Mark H. Burstein <burstein@bbn.com>
> * Director, Human Centered Systems Group
> * BBN Technologies
> * 10 Moulton Street
> * Cambridge, MA 02138
> *
> * Tel: 617-873-3861
> *  Fax: 617-873-4328
> * htttp://daml.bbn.com/burstein
>

==============================================================================

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

Received on Monday, 26 May 2003 17:18:13 UTC