W3C home > Mailing lists > Public > public-owl-wg@w3.org > December 2007

Re: PROPOSAL to close ISSUE-8

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Thu, 13 Dec 2007 13:46:50 -0500
Message-Id: <F3C6A0A4-DAA4-41EC-A08C-DC29E38010CC@gmail.com>
Cc: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, public-owl-wg@w3.org
To: Uli Sattler <sattler@cs.man.ac.uk>

Another quick point to make is that at the meeting there was a clear  
use case give for the datatype at the end of a property chain, and  
for a comparison to a constant, but not for a comparison of two  
values. So until there is competition on the use case side, wouldn't  
the bias be to say that we could drop comparisons altogether.

-Alan

(fishing for use cases more compelling than shoe-size > iq )

On Dec 13, 2007, at 1:39 PM, Uli Sattler wrote:

>
> On 13 Dec 2007, at 18:31, Alan Ruttenberg wrote:
>
>>
>> On Dec 13, 2007, at 1:24 PM, Uli Sattler wrote:
>>
>>> On 13 Dec 2007, at 16:04, Alan Ruttenberg wrote:
>>>
>>>> I have had a discussion with Uli about this, and it seems that a  
>>>> limited form of this would not compromise decidability - e.g. no  
>>>> binary comparisons other than equality. She said she would write  
>>>> up a proposal.
>>>
>>> ...I seem to remember that i agreed to have a think (!) about it
>> Yes.
>>> - and I had: it seems to me that (i) we would need to "fork"  
>>> OWL11 in a difficult to understand way (i.e., you can either use  
>>> datatype properties at the end of property chains or, say,   
>>> comparisons, but not both), and
>>
>> This doesn't seem in principal different than transitive  
>> properties and cardinality constraints. Is it? If so, how would  
>> you characterize the difference?
>
> I partially agree (and thus partially disagree):  the difference  
> seems to be the complexity of specifying conditions when you may or  
> may not use properties in subproperty chains: it not only depends  
> on subproperty axioms, but also on the usage of the datatype  
> properties in comparisons...i am a bit short of time today and  
> tomorrow, but i will continue thinking about it...
>
>>
>>> (ii) we would need to ask implementors whether they would be  
>>> willing to implement this.
>>
>> Yes.
>>
>>> I would thus favour to not allowing them at all....Carsten?
>>
>> Yes, but we have two groups which clamor for them - Jim and Jeremy  
>> representative of them, and they are kind of obviously useful.  
>> Could we at least have the technical aspects of the case where  
>> they are not used in comparisons laid out?
>>
>> Anyways, I think it would be useful to have that in front of us,   
>> so we could have something concrete to ask the implementors about.
>>
>> -Alan
>>
>>>
>>> Cheers, Uli
>>>
>>>> -Alan
>>>>
>>>> On Dec 13, 2007, at 9:56 AM, Peter F. Patel-Schneider wrote:
>>>>
>>>>>
>>>>> Issue-8 asks for property chains that end with data properties.
>>>>>
>>>>> Adding this construct to OWL 1.1 would compromise decidability.
>>>>> This feature would automatically be in an OWL Full version  
>>>>> because in
>>>>> OWL Full data properties are also object properties.
>>>>>
>>>>> Later discussion asked whether having data properties in the  
>>>>> middle of
>>>>> a chain can be done.
>>>>>
>>>>> In OWL 1.1 such chains would have an empty extension, and thus be
>>>>> useless.  The situation in OWL Full is the same as for data  
>>>>> properties
>>>>> at the end of a chain.
>>>>>
>>>>> I therefore propose that we CLOSE ISSUE-8 (even though it is  
>>>>> not even
>>>>> OPEN) without doing anything on the twin grounds that it both
>>>>> compromises decidability in OWL 1.1 and is not handled by  
>>>>> tools, and
>>>>> that there is nothing special that needs to be done in OWL Full.
>>>>>
>>>>> Peter F. Patel-Schneider
>>>>> Bell Labs Research
>>>>>
>>>>> PS: I'm proposing handling ISSUE-8 in this manner as is it is  
>>>>> closely
>>>>>     related to ISSUE-83.
>>>>>
>>>>
>>>>
>>>
>>
>
Received on Thursday, 13 December 2007 18:47:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:29 GMT