Re: General discussion for TC Wednesday 2008-04-21

On 22 Apr 2008, at 20:27, Alan Ruttenberg wrote:
>
> On Apr 22, 2008, at 12:18 PM, Bijan Parsia wrote:
>> On 22 Apr 2008, at 17:03, Alan Ruttenberg wrote:
>>> Thanks Bijan, Uli.
>>>
>>> My use case would be satisfied with the simplest of keys - no  
>>> inferred keys and keys only on named classes.
>>
>> Then I would suggest that this isn't not something for the current  
>> spec. When convergence on a preprocessing/macro language emerges,  
>> it seems like it could easily be handled by that. For now, a  
>> fairly simple program could handle it.
>
> Hi Bijan,
>
> Why wouldn't you think it is something for the current spec?

Because the trivialest version is not very well understood, esp. from  
a user perspective. It has a relatively unnatural definition (from  
the perspective a description logic; for example, it's not like it's  
obvious how to reduce it to DL Safe rules) and may have surprising  
interactions.

Also, there has not been much demand, afaict. Lack of keys has been  
persistently presented as a showstopper. Lack of keys that merge  
classes, well, has never been presented to me before.

> Not for the proposed implementation, but it would seem to me to be  
> within scope of
> the goals of easy keys, and my impression was that the feature  
> drove the implementation, rather than the other way around.

I don't understand what you mean. My point was that lack of  
specification here seems more or less harmless since it is 1) easily  
achievable with user programs or macros,  2) not widely requested,  
and 3) it might fall out of some other feature.

This is why we didn't add missing key checking to easy keys: because  
non-monotonicity is something that will probably come to OWL  
otherwise and we should strive to be minimal. In order to spec easy  
keys, we had to close a (unperceived by me) gap in DL Safe rules (in  
the handling of data properties).

For example, if we had a standard preprocessing language, then why  
would we want this feature built in? Conversely, if we have easy  
hilog, why would we want anything more than that and easykeys?

I'm not saying a case can't be made, but there are a lot of  
interactions to consider. In general, going from inequality to  
equivalence is tricky and, in fact, covered (potentially) by another  
feature.

> And if a fairly simple program can handle it, so much the better!

But it can't handle the more general case and the job is to show why  
we can stop here.

>> If we introduce it as a general feature, I think we have to take  
>> more care to align it to the easykeys behavior so they are  
>> reasonably consistent.
>
> If the named classes (as actual individuals) are considered as what  
> the keys are related to (rather than the punned individuals), then  
> there is no way for any key to be inferred at all, is there?

I don't know what you mean by "actual individuals" vs. "punned  
individuals". I guess it seems that in either case, if these are real  
assertions, then keys can be inferred.

> So if we said that in both cases inferred keys are considered in  
> the rule (trivially satisfied by there being none possible for the  
> class keys) then is that not viewable as consistent?

What I meant was that EasyKeys allows for inferred keys and defines  
how you handle them. Saying that you don't have inferred keys starts  
you out as being different from EasyKeys (e.g., more restricted).  
Saying *only asserted relations* is harder than talking about only  
existing individuals (and risks nonmononticity).

Cheers,
Bijan.

Received on Tuesday, 22 April 2008 19:45:00 UTC