OWL-S: Handling Failures, and automatic generation of composite process IOPRs [was: Re: A bunch of OWL-S difficulties]

The issues here are tangled indeed ;)
See my replies below.

David Martin wrote:

> Daniel Elenius wrote:
>
>>
>> Hi.
>>
>> Here is a whole bunch of issues/questions/comments on OWL-S that I 
>> wish to discuss. Please dig in on any of them that you like. (The 
>> comments below refer to OWL-S 1.1 beta.)
>>
>> 1) About hasOutput
>> What is the purpose of the hasOutput property (both in Process and 
>> Profile)? There does not seem to be a need for it, since all Outputs 
>> need to be in som Result anyway. And IF the hasOutput property stays, 
>> the hasEffect property should also come back. There is an asymmetry:
>>
>> Process.hasOutput -- Result.withOutput
>> nil               -- Result.hasEffect
>
>
> Actually, it's not true that all Outputs need to be in some Result.  
> (We discussed on the phone recently, but I just want to put this out 
> on the list "for the record".)  Results are optional, and even when 
> there is a Result, the "withOutput" property is optional.
>
> The hasOutput property declares an output; the withOutput property 
> gives additional info about what value(s) the output may take in a 
> given condition.
>
> The asymmtery is deliberate: A process must always have the named 
> outputs that are (mandatorily) declared using hasOutput, but effects 
> are not named, and are purely conditional, so they are only mentioned 
> in Results.
>
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. Of course, it may not be 
in the scope of the basic OWL-S, but up to various extensions to handle 
this. But in my mind, standardazing such fundamental things would be 
very beneficial.

Marking fail-results would also help the automatic generation of a 
composite process's outputs/results from its sub-processes'. All 
fail-outputs/results could just be ignored (see more below).


>>
>>
>> 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? How would a tool decide 
>> what Results to put in
>> the CompositeProcess? These could depend on a bunch of Preconditions 
>> and Effects internal to
>> the Composite Process. The same goes for Inputs - it is not certain 
>> that the user needs to
>> be able to provide all Inputs in the CompositeProcess, some of them 
>> may be internal, i.e. provided
>> by outputs of other parts of the composite process. And some of them 
>> may never be needed at all,
>> depending on execution path.
>
>
> You are right.  But with respect to Inputs and Outputs, there is a 
> straightforward way to proceed, which is to simply declare, for the 
> composite process, *all* inputs and outputs that are associated with 
> its nested subprocesses, regardless of whether or not they are certain 
> to be used, *except* for those that are "internal", as you say.  (If 
> desired, the IOs that are certain to be used can be flagged as such, 
> although OWL-S doesn't currently provide a property for that purpose.  
> Perhaps we should.)
>
Yes... Let's see, what does "internal" really mean here? Is it only a 
matter of looking at all the Performs:
For each "hasDataFrom" property
If the value of the toParam property is an Input
AND
if the Binding of the hasDataFrom has a valueSource property
AND
if the fromProcess of this valueSource is an atomic process (i.e. not 
"TheParentPerform")
AND
if the theVar property of this valueSource is an Output
then mark this Input and Output as "internal"

?
 
What about internal preconditions and effects? For example, there could 
be a Result which includes an effect, the
purpose of which is only to "feed" a precondition of a subsequent atomic 
process in the same Sequence. But it could
also be the case that the user is executing this composite process 
partly for the sake of this effect. Here it seems that
explicit markup would be needed to support the automatic generation of 
composite preconds/results from sub-process
preconds/results.

The same could of course apply to inputs and outputs. Even if an 
input/output is needed in a later stage
in a composite process, the client could very well be interested in this 
input/output.

So I guess my argument so far is that parameters _must_ be marked as 
internal/fail-cases for any smart automatic generation
of composite parameters to be possible. But then again - even if the 
creator of composite process marks them as
internal, who's to say that some user won't find them valuable in 
themselves??

> Clearly, with this approach, to be smart, a matchmaker that's looking 
> at a composite process in connection with a service request will need 
> to be aware that its inputs and outputs may not always be required, 
> and may want to do some additional analysis of the IOs by looking at 
> the process model.
>
> With respect to preconditions and effects, I think the same approach 
> might still be possible, but there are some additional complications, 
> and I'm not so clear as to whether it's a useful thing to do.
>
>> The same problem occurs when one wants to decide which parameters 
>> should go into the Profile.
>> This case may be easier, as the Profile is presumably created by a 
>> human, so Results which are the
>> cause of some error in the processes need not be included for 
>> example, as no agent will search for
>> a process that produces some specific error.
>
>
> Right.  The IOPEs of the profile in many cases can be regarded as a 
> simplification or approximation of the process model, to meet the 
> practical needs of advertising and matchmaking.
>
>>
>>
>> 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?
>
>
> 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.  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.)
>
> But you are right - there are some things that could be done to make 
> it easier to specify the results.


Yes. As an example of what I mean (this is just off the top of my head):

Instead of writing something like:

<process:hasResult>
	<process:Result>
		<process:inCondition>
			condition here...
		</process:inCondition>
		<process:withOutput>
			output binding here...
		<process:withOutput>
		<process:hasEffect>
			"success" effect here...			
		</process:hasEffect>
	</process:Result>
</process:hasResult>
<process:hasResult>
	<process:Result>
		<process:inCondition>
			negation of condition from above here...
		</process:inCondition>
		<process:withOutput>
			output binding here...
		<process:withOutput>
		<process:hasEffect>
			"failure" effect here...			
		</process:hasEffect>
	</process:Result>
</process:hasResult>

We could have something like:

<process:hasResult>
	<process:Result>
		<process:inCondition>
			condition here...
		</process:inCondition>
		<process:conditionTrue>
			<process:SuccessCase>
				<process:withOutput>
					output binding here...
				<process:withOutput>
				<process:hasEffect>
					"success" effect here...			
				</process:hasEffect>
			</process:SuccessCase>
		<process:conditionTrue>
		<process:conditionFalse>
			<process:FailCase>
				<process:withOutput>
					output binding here...
				<process:withOutput>
				<process:hasEffect>
					"fail" effect here...			
				</process:hasEffect>
			</process:FailCase>
		</process:conditionFalse>
	</process:Result>
</process:hasResult>


This would make it more obvious that both effects actually relate to the 
same condition, and the condition
would only have to be written once. Of course, the fail-case could be 
optional: There _could_ be no result at all on a
failure.

/Daniel

Received on Monday, 6 September 2004 10:22:04 UTC