- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Tue, 22 Apr 2008 16:19:30 -0400
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: Uli Sattler <sattler@cs.man.ac.uk>, OWL Working Group WG <public-owl-wg@w3.org>
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