Re: Proposal to close ISSUE-83 and ISSUE-8

wait, wait - now I'm even more confused than I was -- are we, or are  
we not, talking about the EasyKeys proposal being part of OWL 1.1?   
If so, wouldn't the last property in a property chain be implemented  
exactly the same way?   If so, then we aren't closing the issue with  
a Reject, if not, then what is the difference?  So couldn't we have  
"easykeys" at the end of property chains?
  -JH
p.s. btw, I did look at Uli's slides, but without the accompanying  
explanation for the non-theorist, and there was very little in the  
log, the details were not terribly clear - I was assuming at some  
point there'd be some description of the solution in one of our  
documents.  I



On Jan 10, 2008, at 6:33 PM, Bijan Parsia wrote:

>
> On Jan 10, 2008, at 10:57 PM, Jim Hendler wrote:
>
>> I must admit to being confused- I thought the issue of property  
>> chains ending in data properties has the same decidability as  
>> inversefunctional datatypes - that is, that Uli has a suggestion  
>> we might adopt that fixes things (Bijan - you wailed on me when  
>> you thought i was ignoring this!) -- is there a reason these are  
>> different?  If not, shouldn't the solution work for Issue 8 as well?
>
> The problem is that although decidable (though you have to be  
> careful, so the exact details of the proposal matter) like  
> *general* inversefunctional data properties, the implementation is  
> seriously non-trivial and there has been no evidence that *any*  
> implementor will implement it, at least, in a complete way. (This  
> is why we have an "EasyKeys" proposal in the works.) So, we  
> shouldn't *require* it as things stand now. However, if some  
> implementor wants to implement it, or some user wants it and will  
> pay some implementor, then they have syntax "ready to hand" (i.e.,  
> it doesn't require inventing new terms, just relaxing some  
> restrictions on existing syntax).
>
> Ah yes, you weren't at the F2F so you might not have the design  
> principle I'm applying fresh to mind. At the first OWLED, the  
> guiding principles for adding features were:
> 	1) There had to be strong, committed user demand. (i.e., it  
> shouldn't just be "Nice to have I guess" but "I will use this")
> 	2) We had to have a good understanding of the feature, how to  
> implement it, etc.
> 	3) We had to have commitment from the implementors to actually  
> implement it.
>
> At the moment there's not the slightest evidence that any  
> implementor will implement this (the general feature).
>
> What I believe some implementor *will* do is implement something  
> similar to the corresponding DL-safe rules...but that's why we have  
> a RIF task force.
>
> Hence we close it until we get some evidence that it will be  
> implemented. (The general feature, of course.)
>
>>  -JH
>> p.s. I was told this about issue 8, I cannot tell for sure if it  
>> also is the case for issue-83,
>
> Issue-83 proposes an undecidable feature.
>
> Cheers,
> Bijan.
>

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180