RE: [OWL-S] OEs in the 1.1 Profile

Hi,

Are there the details of this change available anywhere. I searched the
OWL-S 1.1 Draft and found no mention of it. I'm particularly interested
in how conditions are modelled by Result.

Best Wishes,
Dónal

> -----Original Message-----
> From: public-sws-ig-request@w3.org 
> [mailto:public-sws-ig-request@w3.org] On Behalf Of David Martin
> Sent: 21 June 2004 03:43
> To: public-sws-ig
> Subject: [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 Monday, 21 June 2004 06:51:12 UTC