Re: Proposed change to the OWL-2 Direct Semantics entailment regime

On 1 Dec 2010, at 07:02, Enrico Franconi wrote:

> On 30 Nov 2010, at 16:31, Bijan Parsia wrote:
> 
>> On 30 Nov 2010, at 14:51, Lee Feigenbaum wrote:
>> 
>>> On 11/30/2010 9:49 AM, Enrico Franconi wrote:
>>>> I repeat myself: *any* OWL-QL or OWL-EL implementation by design incorporates BGPs with OWL Direct Semantics in the manner I'm proposing.
>> 
>> This is pretty obviously false, afaict. But maybe you were being hyperbolic?
> 
> Well, I just said that the way any publication/manual defines the semantics of any tool supporting conjunctive queries with distinguished variables in the OWL-QL and OWL-EL families is exactly what I'm proposing. This is obviously true.

So you weren't referring to existing implementation or possible implementations? Or do you mean strictly conforming (e.g., compiling bnodes to someValuesFrom)? Even there, you could maintain the syntax and treat it differently when doing SPARQL evaluation.

>> Nothing prevents an engine with non-distinguished variables + existential variable interpretation of bNodes in data from leaving the query engine untouched and skolemizing the data on input.
> 
> I don't think so for the following reason. In any DB related technology (such as OWL-QL, or in recent works on OWL-EL) you have necessarily built in the unique name assumption.

But then you aren't strictly conforming (neither OWL QL nor OWL EL make the UNA). If the implementor is willing to tolerate this deviation, why not another?

> If your language has counting or functionalities (such as OWL-QL) then skolemising the bnodes as individuals would be plain wrong, as you can easily imagine.

Again, I generally support this deviation from the spec, esp. if it aligns it self with the common behavior in RDF(s) engines and common expectations. This should be no surprise as I advocated in the OWL WG for changing the semantics of BNodes to anonymous local names, partly to align with what I think are the preferred semantics for SPARQL.

Now, generally at the W3C we try not to violate other specs, at least, not without good reason. I think there's very good reason here and, technically, we can avoid violating the specs by loosening the relationship between query answering and entailment. It's messy, but standards making is a bit of a sausage making exercise.

>> But no, I don't think the implementation cost is high.
> 
> As a consequence of the above, you need to implement specific ways to handle bnodes *in* the engine. I can't imagine how this could be simply done, since the technology is based on rewriting queries as SQL queries, but then your pseudo-skolems in the DB would have UNA, etc...

Again, I don't see how this is a compelling argument, all your other arguments put together. You can't simultaneously require strict adherence to the spec and argue that we should accommodate an implementation strategy based on willful violation of the spec.

Notice this is only an argument against your overall argument strategy. I'm more than willing to entertain the needs of implemetnations that vary from the strict details of the existing specification --- that's information about the quality of the spec, often. However, then we need to take the "it's what the spec demands" as a trump card and allow other considerations.

BTW, the UNA issues was discussed with relevant implementors during the OWL WG (you can find the corresponding issues pretty easily), particularly wrt OWL QL. Part of the strong argument against it was staying inside the RDF user mindset (IIRC).

>>> i.e. wouldn't we be asking all current SPARQL-OWL implementations to change their behavior?
>> 
>> The big one is returning bNodes, as Enrico pointed out. But the gain in SPARQL/RDF compatibility would be worth it, IMHO.
> 
> Same issue as above. If you language has built-in UNA, then the reimplementation is not going to be trivial IMHO.

Oh, that sets up the refutation nicely: No OWL profile has a built-in UNA. Thus, afaik, only one implementation (pointers to others more than welcome!) would be harshly affected and it already deviates from the standard.

BTW, I never got a reply to you about conveying my questions to the users/implementors you are championing or putting me otherwise in contact with them. That seems to be the last possible source of information on this topic. If we can plumb that soon, I'll be happy to write up a general pro/con summary to put forth to the group.

(One other advantage of the current regime is that it extends straightforwardly to arbitrary patterns of BNodes. OWL DL and subsets only allow tree patterns which, again, makes "moving on up" from RDF and RDFS to OWL over a given dataset more difficult.)

Cheers,
Bijan.

Received on Thursday, 2 December 2010 12:02:45 UTC