Re: A bunch of OWL-S difficulties

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.

> 
> 
> 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.)

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.

I think I'll let others reply to (4) below, and I'll come back to (5) in 
another message.

Regards,
- David

> 
> 
> 4) inConditions, Preconditions and Results (again)
> In Process.owl, a comment says that:
> 
> Process.hasPrecondition and Result.inCondition properties refer to
> Conditions that are tested in specific contexts.  Preconditions are
> evaluated with respect to the client environment before the process is
> invoked, result conditions are effectively meant to be 'evaluated' in
> the server context after the process has executed.
> 
>> From this, I take it that inCondition is tested by the service 
>> provider _after_ the process has executed.
> 
> If this is the case, what is the difference between an inCondition and a 
> Result? Both will hold true in
> the same cases (I assume that the client believes to be true whatever 
> the server holds true). In any
> case the inCondition seems to be exposing server-side internals that the 
> client really doesn't need to
> know. Whatever the client needs to know should be in the Effect...
> 
> If the inCondition is (contrary to the comment in Process.owl) tested 
> _before_ the process executes, then it's the same as a precondition...
> 
> 
> 5) Split+Join vs Unordered
> What is the difference between these two control constructs? Can I get 
> an example to show the difference?
> 
> 
> Thanks a lot if you made it this far!
> 
> Best regards,
>

Received on Monday, 6 September 2004 07:43:22 UTC