Re: [OWL-S] new IOPE example #1

David Martin wrote:

> OK, here's a revision of the Add example that takes into account recent 
> comments in this same thread.  Still not sure what namespace we'll be 
> using for the ???'s - but I think it'll be "drs".  Drew, does this seem 
> compatible with DRS directions?
> 
> - David
> 
> <process:AtomicProcess rdf:id="Add">
>   <process:hasInput>
>     <Input rdf:id="Add_In1">
>       <parameterType
>          rdf:datatype="&xsd;anyURI">xsd:float</parameterType>
>     </Input>
>   <process:hasInput rdf:id="Add_In2">
>     <Input>
>       <parameterType
>          rdf:datatype="&xsd;anyURI">xsd:float</parameterType>
>     </Input>
>   </process:hasInput>
>   <process:hasOutput>
>     <Output rdf:id="Add_Out">
>       <parameterType
>          rdf:datatype="&xsd;anyURI">xsd:float</parameterType>
>     </Output>
>   </process:hasOutput>
>   <process:hasEffect>
>     <???:LogicalExpression>
>       <???:inLanguage><LogicFormalism
>         rdf:resource="&lf;swrl/></???:inLanguage>
>       <???:expression rdf:parseType="literal">
>         <???:Formula rdf:parseType="Collection">
>           <swrl:datavaluedPropertyAtom>
>             <swrl:propertyPredicate rdf:resource="&arithmetic;sum"/>
>             <swrl:argument1>
>               <arithmetic:Pair>
>                 <first rdf:resource="#Add_In1">
>                 <second rdf:resource="#Add_In2">
>               </arithmetic:Pair>
>             </swrl:argument1>
>             <swrl:argument2 rdf:resource="#Add_Out"/>
>           </swrl:datavaluedPropertyAtom>
>         </???:Formula>
>       <???:expression rdf:parseType="literal">
>     <???:LogicalExpression>
>   </process:hasEffect>
> </process:AtomicProcess>

Some interesting questions / objections came up about the effect part of 
this example today in our telecon.

Here are 2 of the primary points that came up, as I understand them.  My 
comments follow each point.  Responses welcome.

Issue 1) "This example expresses the relationship between inputs and 
outputs.  It's not correct to call that kind of characterization an 
'effect'.  An 'effect' is a change to 'the world' (including changes to 
knowledgebases)."

I've some sympathy with that, but we do frequently talk about outputs as 
"knowledge effects".  What's the harm in talking about the value of an 
output as one of the "effects" of a service?  Although it's clearly 
transitory, nevertheless the service certainly "had the effect" of 
setting the output to that particular value.

For those who object to calling this an "effect", would you be happy if 
it were called a "postcondition"?

Issue 2) "It's not useful to characterize the output of a 
purely-informational service in this way.  For one thing, it's just a 
restatement of the code that implements the service."

This objection seems groundless to me.  I can easily imagine service 
composition tasks where the composer will need to select an appropriate 
purely-informational service, and some characterization of the outputs' 
relationship to the inputs is precisely the information that will be 
needed.  (example below)

With respect to the issue of restatement - many (or most or all) of our 
frequently-discussed examples (of conditional outputs and effects) 
involve some degree of restatement of what the service does.  Indeed, 
how could they be otherwise and still be useful?

The point of this example was *not* to expose the inner workings of the 
"Add" service.  It was to characterize the relationship between input 
and output values in terms of some existing ontology (where "sum" was 
already defined).

I think perhaps the utter simplicity of this example and its roots in 
basic math have led to some confusion.  Let's imagine something with 
more obvious utility.  Suppose there are 2 standard ways of computing 
the annual interest on a certificate of deposit.  Service S1 computes it 
using method 1, and service S2 computes it using method 2.  Now suppose 
there's a standard accounting ontology that defines these methods using 
properties "interest_method1" and "interest_method2".  Each of these 
properties has Pair(balance, rate) for domain and  float for range.  The 
meaning of an instance of interest_method1:

Pair($500, 10%) interest_method1 $55.10

is simply that $55.10 is the correct value of interest for the given 
balance and rate, under that method of computation (which involves some 
form of compounding).

I claim the following:

    A) It would be extremely useful for a service composer to be able to 
distinguish between S1 and S2, and there should be a way for us to 
express that distinction using effects (or "postconditions", if that's 
the preferred terminology, or perhaps conditional outputs) that mention 
interest_method1 and interest_method2.

    B) However we do it for this example should also apply to the simple 
math example ("Add").

Cheers,
David

Received on Tuesday, 6 April 2004 18:34:43 UTC