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

On Apr 22, 2008, at 9:19 PM, Alan Ruttenberg wrote:
> 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?

I should say that it's not well understood by me.

Up to now, I've not had a use case.

I have seen enough use cases and situations to know what I, qua  
modeler, would or would not expect in a variety of cases. As we saw  
with EasiestKeys, sometimes you get rather surprising results.

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

It's not a matter of needing them. It's a matter of when I have DL  
Safe rules of the right sort (and or easy hilog) do I get the expect  
equivalences and 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.
>
> Uli, Ian and Dmitry have been aware of it since 2006.

I didn't say it hadn't been presented to them. I speak only for me.

> I'm not one to cry showstopper (I've noticed that showstopper is  
> cried more often than it need be).

I'm certainly willing to believe that. Hence the "persistently".   
Lack of keys is widely and vocally complained about. This, not so much.

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

I don't know what you mean by "directly" and I'm curious as to what  
you base this implementation judgement on. My understanding of what  
you think would work means that a preprocessing step would work fine.  
In my book, preprocessing (i.e., compiling away) is not a direct  
implementation. It's definitely not an obvious thing to do in the  
tableau.

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

I must be missing something; I didn't get the relevance of that  
thread. The lisp syntax is getting in my way, I guess.

> 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

I didn't say it wasn't useful (I don't doubt you have use cases and  
this seems interesting, though I don't have time right now to work  
through it in detail; I did notice a falsehood: """Based on advice  
received from Alan Rector at the University of Manchester, we decided  
to represent reactions using Qualified Cardinality Restrictions  
(QCRs). Although QCR's have been approved for inclusion into OWL 1.1,  
none of the publicly available reasoners except for FaCT++ are  
capable of reasoning with QCRs.""" RacerPro and KAON2 definitely had  
QCRs before then and are both publicly available.). I just don't yet  
have evidence that it rises (yet) to the level of specworthiness,  
esp. as several details are not obvious and given my experience in  
speccing easy keys. It doesn't fall directly out of that work.


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

If it can be implemented in a preprocessing step, and we had a  
standard macro langauge, then it could easily be implemented as a  
macro (i.e., without calling the reasoner).

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

If you plan to add syntax, then I become more strongly opposed. If we  
add syntax, then adding hilog should *not* change the semantics and  
then we have two ways to say almost but not quite the same thing.

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

I gave my current judgement.

> The feature is well motivated by 2 year old use case that is still  
> relevant.

I'd just like to point out that compared to keys simplicier, it's not  
very well motivated as something to special case into the spec.  
(Key's have been a big deal since before owl went to rec. People in  
RDF land have been, for years, working on various rule based  
approaches. Lots and lots of people have identified keys as key, etc.  
etc. Also, Uli and I had been saying that one could use DL Safe rules  
for key like stuff since, at least, 2005. It took a lot of pestering  
to get us off our butts to work out the details in detail.)

> It is similar in spirit to the idea of easy keys.

That "in spirit" is an important caveat.

The orthogonal way to add it is to have easy hilog. I've been  
noodling about easy hilog for a while and haven't gotten very far. I  
don't anticipate getting very far before last call.

Given that (arguably) you have the functionality with OWL Full, you  
can always lobby your vendors to add "just a little bit" of OWL Full  
(enough for your use case). Or you can implement it as a  
preprocessing step (I believe). In either case, you don't need  
special syntax, so it seem ok.

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

You misunderstood my point. Easy programs do not necessarily  
translate into easy to spec. An easy program means that if you have a  
narrow (albeit important) use case, you probably are ok without it  
being specced. If you think it needs significant implementation  
support, I'd rather see some of that support first so I'm sure it is  
reasonable and I'd want some evidence that it's widely high impact.  
After all, I could be wrong about the program :)

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

The problem is that we'd need to consider a fairly wide variety of  
cases to make sure that "stopping where we stop" isn't an  
idiosyncratic feature of your use case. The due diligence required is  
nontrivial. Compare with compound keys. Once we had the basic  
methodology (translation to DL Safe rules) and had gotten the DL Safe  
rules right, compound keys just falls right out, trivially. If we had  
DL Safe rules with tbox variables, er, we'd still need tbox variables  
in the head (which is non trivial). So we have to invent another  
mechanism which is perhaps similar in spirit and we'd have to have  
some confidence that it was, in fact, something sensible and not ad  
hoc (we spend quite a bit of time asking lots of different people if  
data oriented keys were useful and what they wanted).

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

One use case for which there is an existing work around and there is  
a proposed alternative and can be semantically seen as a subset of an  
existing specced langauge, but for which there are lots of questions  
about its generality and how it'd interact with other feature,  
strikes me as insufficient to add to our spec when you've just  
recently emphasized our time pressure. I'm certainly not going to  
work on it until at least EasyKeys, N-ary data predicates, and Rich  
Annotations have been dealt with. I, personally, have a much better  
grip on all of those.

Plus, it seems like solving easyhilog solves this and a bunch of  
other cases (e.g., when people use sameAs between classes for  
expressing mappings).

So I'd argue to defer this.

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

Yes, but then this is hilog. Adding hilog only for keys is rather  
odd, esp. if we want to try to restrain the hilogisty in a number of  
ways.

Plus, you can just ask for it as a OWL DL+some OWL Full features  
(just like you can as for inverse functional data properties). Thus,  
qua consumer, you are not spectacularly worse off.

Or you could bribe implementors. I hear that works too. ;)

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

Once you start talking about relations being (or not being there) you  
are inspecting the KB. Which is an epistemic operation. Which leads  
to nonmon (consider the k-operator).

> BTW, I appreciate you helping think this through,

Sure. At this point, I'm pretty convinced that 1) no syntactic hook  
is required, 2) it's not that easy to spec, 3) there are decent  
workarounds both implementationally and specwise.

So, I'm quite back to thinking it's something for later. I'd  
recommend writing up the use case for OWLED.

Cheers,
Bijan.

Received on Tuesday, 22 April 2008 23:13:29 UTC