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

On Apr 22, 2008, at 3:46 PM, Bijan Parsia wrote:
> 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.

Not sure what this means?

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

That's another story. But as you've pointed out you don't need DL safe  
rules for this.

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

Uli, Ian and Dmitry have been aware of it since 2006. I'm not one to  
cry showstopper (I've noticed that showstopper is cried more often  
than it need be). Here's a thread from a 2006 visit to Manchester  
where we successfully did a workaround. However, the workaround is  
inefficient, depends somewhat on the details of the reasoner  
optimizations, and it would be more efficient and straightforward to  
implement this directly.

http://groups.google.com/group/BioPAX-Manchester/browse_thread/thread/7c0e121d65c63042

This was used in what I believe to still be fairly advanced  work with  
OWL and bioinformatics. See
http://bio.freelogy.org/wiki/Debugging_the_bug


>> 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 actually sure what you mean by implementing this in a  
preprocessing language. Regarding easy hilog, it would seem that when,  
and if, we add that to OWL, it would add extra entailments, in a  
similar manner in which new entailments would occur in other parts of  
the language. So I don't see that having this potential new feature  
should be a blocker.

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

OK. All I'm asking is that we consider the interactions and then make  
a judgement. The feature is well motivated by 2 year old use case that  
is still relevant. It is similar in spirit to the idea of easy keys.  
If there's a (real) showstopper, then fine. However it seems that you  
understood what is needed when you suggested it was an easy program,  
and to my mind, easy + needed = win.

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

I offer my very useful use case, above. With it we detected many  
errors in two important databases and computed mapping between  
reactions that other approaches did not. That use case does not need  
the more general case.

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

By actual individuals, I mean those things that, if they were set to  
be sameAs, would imply equivalentClass. The keys could be inferred in  
OWL Full, but I don't see any way to infer them in OWL DL. Stating  
them would be a new thing that OWL DL could do.

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

I wouldn't press this if there was an issue with monotonicity. Could  
you elaborate on how you see this coming about?

BTW, I appreciate you helping think this through,

Regards,
Alan

Received on Tuesday, 22 April 2008 20:20:11 UTC