Re: OWL-S: Handling Failures, and automatic generation of composite process IOPRs

Thanks for the replies.
See answers inline.

>Other reasons: The outputs property declares the types of the outputs;
>the 'withOuput' declares the values.
>  
>
What do you mean by "the outputs property"? The Output _class_ declares 
types of course, and no-one was suggesting that that was unnecessary. 
But the hasOutput property is merely a link to instances of this 
class... Anyway, I was already convinced by David's explanation :)

>Composite processes may not have Results.  (See below.)
>
>  
>
>>[Daniel]
>>Yes, OK. But in real life, wouldn't all outputs be conditional? A 
>>process can always fail... And I think it would be useful to distinguish 
>>the fail-cases from success-cases. This could be as easy as having a 
>>subclass of Result call FailureResult for these cases. Even better would 
>>be to have some kind of failure/exception ontology to relate to... This 
>>is an area where I think OWL-S could do better. Consider BPEL4WS's 
>>exceptions and recovery actions for instance. 
>>    
>>
>
>You're probably right, but that's a whole new set of issues....
>
>  
>
I agree, but interesting ones nonetheless... Has there been any work 
done on this kind of thing?

>>>>2) About mapping Composite IOPEs to Atomic IOPEs and Profile IOPEs
>>>>A comment in CongoProcess.owl says:
>>>>
>>>>     Note: Input, output, precondition, and effect properties of 
>>>>*composite*
>>>>     processes can, in principle, be automatically generated by tools.
>>>>     Since such tools don't yet exist, they have been manually generated
>>>>     for this example.
>>>>
>>>>How would such automatic generation happen? 
>>>>        
>>>>
>
>It wouldn't.  That comment should be deleted.  
>
>  
>
Yes, that's what I thought.

>As we discussed in today's telecon, it's probably not feasible to
>infer the outputs or effects of a composite process.  A simple case is
>where a step generates two outputs, only one of which is a useful
>output of the process the step belongs to.  But the real problem is
>that it's undecidable what effects or values a composite process is
>going to have, unless some strong limits are put on recursion of
>'perform's of other processes.  I don't know if the topic of limiting
>recursion in Owl-S has ever come up.
>
>However, if a composite process has explicit Results, the process
>maintainer has to be diligent about maintaining the accuracy of the
>Results as a description of what the composite process does.
>
>  
>
>>>>3) More on Results
>>>>It seems to me that in many cases, there will be two Results 
>>>>connected to the same inCondition -- one for the case where the 
>>>>inCondition is true, and one for the case where it is false (an 
>>>>error/fail case). Why not have some shorthand for this, rather than 
>>>>expressing it as two different inConditions? Also, what happens if no 
>>>>inCondition is true? No Result? Should there be a way to express a 
>>>>"fallback" Result?
>>>>        
>>>>
>
>Adopting a "shorthand" convention in XML/RDF is like putting a smaller
>hood ornament on your SUV to reduce gasoline consumption.
>
>  
>
LOL :)
Well the point wasn't merely to make the code shorter, but also to 
somehow have it make more sense IMO.

>>>[David]
>>>Currently it is expected the inConditions will be exclusive, so as to 
>>>avoid any ambiguity and minimize complexity in evaluating them.  But 
>>>they needn't be exhaustive.  If there is no inCondition that's true, 
>>>then there's no Result, and that's OK.  
>>>      
>>>
>
>Hmm.  I'm not sure I agree that 'inConditions' are normally
>exclusive.  In realistic applications it's likely that there will be
>orthogonal sets of conditions, where each set is mutually exclusive.
>
>In any case, it wouldn't be hard to put an "if ... elseif ... else"
>construct into the surface syntax, although it won't appear in the
>next version, which I am hoping to post today.
>
>  
>
Yes, that's also similar to what I was suggesting above.

>>>[David]
>>>No result just means that 
>>>there's no effect, and nothing to be specified about the values of the 
>>>outputs.   (That is, there will be outputs, but there's nothing to be 
>>>said about what their values will be in the given condition.)
>>>      
>>>
>
>I can believe "no effect," and I can believe that some outputs are
>left unspecified.  (Perhaps output 1 says whether some quantity was
>retrievable, and output 2 says what the quantity is; if output 1 =
>false, then output 2 = "don't care.")  I think leaving _all_ outputs
>unspecified would always be a bug.
>
>  
>

Received on Tuesday, 7 September 2004 20:22:10 UTC