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

Dónal Murtagh wrote:

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

Hi -

Sorry about the delayed response.  Yes, these changes are discussed in 
the *draft* 1.1 Technical Overview section on process modeling.  Drew 
McDermott circulated that section on this list not long ago.  Since 
then, it has been incorporated in the Technical Overview document on the 
1.1 release page, and some further refinements have been made.

[However, my proposed related changes to the *profile* have not yet been 
made.]

Regards,
David

> 
> 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 Wednesday, 7 July 2004 19:27:31 UTC