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

Following up on my earlier msg, I feel even more inclined now to say 
that it should be perfectly OK to have an effect that just characterizes 
the relationship between the input(s) and the output(s), as in the "Add" 
example.  We've often spoken of an "effect" as "a statement that's 
guaranteed to be true upon successful completion of the service". 
That's the spirit in which the "Add" effect says simply

   Add_Out will be the sum of Add_In1 and Add_In2

(where "sum" is a relationship (property) defined in some other ontology 
having to do with arithmetic).

It's certainly reasonable to say that this statement "is guaranteed to 
be true upon successful completion of the service".

I understand that many have the additional intuitions that

1) an "effect" is something that is caused by, or at least results from, 
the operation of the service

2) an "effect" changes the world

(Note: I'd say (1) is true of the "Add" effect, but not (2).)

My view on this is that defining clearly what is meant by (1) and (2) 
poses considerable added challenges and potential for confusion, and 
there's no significant practical gain from doing so.  And ruling out 
simple examples like the "Add" effect eliminates a lot of useful service 
characterizations.

Maybe we should have been calling this "postcondition" all along, 
instead of "effect".

- David

David Martin wrote:

> 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 Monday, 12 April 2004 04:28:50 UTC