A bunch of OWL-S difficulties

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


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. 

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.


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?


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,

-- 
Daniel Elenius
Usable Ubiquitous Research Group (U2)
Department of Computer and Information Science
Linköping University, Sweden
Tel: +46 13 28 56 06, Fax: +46 13 142 231

Received on Wednesday, 1 September 2004 14:25:16 UTC