Re: [OWL-S] output characterization (was "new IOPE example #1")

Hi Mike -

Thanks for your response; I'm taking the liberty to copy this to the list.

Huhns, Michael wrote:

> Hi David,
> 
> The postconditions or effects are the things that hang around after the
> service has completed its operation.  With the add example (similarly
> for the interest rate one) it is certainly true that 5 is the sum of 2
> and 3 and should remain true for a long time, but unless this is stored
> somewhere, possibly for future reference or future use, it is not an
> effect.  So, if 5 gets cached, it is an effect.  If the service is
> stateless, then there is no effect (or postcondition).

In my last message, I deliberately avoided using the word "effect" because I don't 
want us to get bogged down at this point in figuring out what we mean by "effect". 
I take it you regard "postcondition" as synonymous with "effect".  I don't.  When I 
say "postcondition", I mean any expression that's guaranteed to be true upon 
successful completion of the service.  But PLEASE -- let's also not get bogged down 
in discussing what we mean by "postcondition" at this point.

> 
> For the interest-rate use case, the differences between S1 and S2 are
> not in IOPE, but in properties of the service and should be represented
> in the same way that other QoS parameters are.

OK, that seems to me like a reasonable kind of an answer.  But, if I understand what 
you have in mind, I'm not convinced it's the best way to go.  I'm looking for the 
best way for OWL-S to characterize the relationship between the inputs and outputs 
of these two simple services, in terms of the vocabulary provided by my hypothetical 
accounting ontology.

I think what you're proposing is a property, say, "function-computed", and the 
declaration of my compute_interest1 service mentions "interest_compounded_daily" as 
the value of function-computed.

That's fine, as far as it goes, but I don't see why it's better than my 
"postcondition" (or whatever you want to call it) proposal.  In fact, my approach 
seems better in several respects (at least, more general in its applicability and 
more explicit about the relationship between the inputs and outputs).

Regards,
David

> 
> Cheers,
> Mike
> 
> -----Original Message-----
> From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org]
> On Behalf Of David Martin
> Sent: Tuesday, April 13, 2004 4:01 PM
> To: public-sws-ig
> Cc: Richard Waldinger
> Subject: [OWL-S] output characterization (was "new IOPE example #1")
> 
> 
> There are cases where some characterization of a service's output will
> be needed 
> (say, by a matchmaker or planner trying to locate a service that
> embodies a 
> particular function from its inputs to its output).  Here's a simple
> example, 
> involving 2 services.
> 
> ---- use case:
> 
> Suppose there are 2 standard ways of computing the annual interest on a
> certificate 
> of deposit - using daily compounding or using weekly compounding.
> Service S1 
> computes it using daily compounding, and service S2 computes it using
> weekly 
> compounding.  Both services have balance and rate as inputs, and the
> interest as output.
> 
> Now suppose there's a standard, widely-used accounting ontology that
> defines these 
> methods using OWL properties "interest_compounded_daily" and 
> "interest_compounded_weekly".  Each of these properties has Pair(float,
> float) for 
> domain and float for range.  The meaning of an instance of
> interest_compounded_daily:
> 
> Pair($500, 10%) interest_compounded_daily $55.10
> 
> is simply that $55.10 is the correct value of interest for the given
> balance and 
> rate, under that method of interest computation.
> 
> (Note: the challenge here isn't to somehow axiomatize these properties
> defined in 
> the accounting ontology; we're just taking them as givens.)
> 
> --- end of use case
> 
> The question at hand is:
> 
> Q1: Given the existing accounting ontology, how should an OWL-S
> description of these 
> 2 services characterize their output so a planner or matchmaker can
> choose between 
> them?  (Note: from the planner or matchmaker's point of view, 
> interest_compounded_daily and interest_compounded_weekly are
> primitives.)
> 
> Q2: (optional) - what's wrong with having a simple "postcondition" (or
> whatever you 
> want to call it) something like the following?  (The declaration would
> presumably be 
> expressed in OWL-S with the postcondition in SWRL, as in the "Add"
> example, but 
> reverting here to a logic-programming style of notation for
> readability):
> 
>      Process declaration: compute_interest1(+Balance, +Rate, -Interest)
>      Postcondition: interest_compounded_daily(Pair(Balance, Rate),
> Interest)
> 
> David
> 
>

Received on Tuesday, 13 April 2004 19:56:05 UTC