[OWL-S] OEs in the 1.1 Profile

As you (the OWL-S folks) know, for (not-yet-announced) release 1.1, 
we're removing classes
     ConditionalEffect and ConditionalOutput
from Process.owl (because this info is now carried as part of the new 
Result object).

However, there's a problem: Profile.owl still refers to 
ConditionalEffect and ConditionalOutput.  They are the ranges of 
profile:hasEffect and profile:hasOutput.

This was discussed  very briefly in the last telecon.  I observed that 
Profile and Process are no longer in sync with respect to outputs and 
effects (OEs), and someone put forward that it's OK, because we don't 
really mean for profiles to carry all the detailed info that Result 
objects carry.

So one solution might be to reinstate ConditionalEffect and 
ConditionalOutput classes, and just leave the profile properties as they 
are.  However, I find this a problematic solution, because this means 
that it will be less clear than ever what's the relationship between OEs 
of the profile and those of the process.  This is a recurring issue for 
us - that it's desirable to have a clear relationship between these. In 
OWl-S 1.0, we could say that OEs of profile are normally a subset of 
OE's of the corresponding process.  In 1.1, however, if we use different 
structures for OEs of profile, it won't  be possible to make such a 
clear statement about the relationship.

Therefore, it seems better to me that we also use the new Result class 
to express the OEs of Profile.   (That is, we eliminate hasEffect and 
hasOutput and create profile:hasResult, which runs parallel to 
process:hasResult.)  In this way, it'll be more straightforward to trace 
the relationships between the OEs of Process and Profile, and reasoning 
code that looks at the Results of a Process can also be used in looking 
at the results of a profile.

I suspect that for many simple services (certainly those with a single 
Result), it'll be fine for the Profile to reference the identical Result 
object as the Process.  In cases where the Process has several Result 
instances, of course, there would be no requirement that all of them be 
reproduced in the corresponding Profile.  In those cases, I suspect that 
the most common representation would be to reproduce just one of the 
Result instances from the Process.  Personally, I think that approach 
yields a cleaner picture than having completely different properties and 
classes used in profile  vs. process.

Comments?

- David

Received on Sunday, 20 June 2004 22:43:45 UTC