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

On 30 Nov 2010, at 09:57, Enrico Franconi wrote:

> Hi,
> I'd like to propose a change to the OWL-2 Direct Semantics entailment regime as it is currently defined in the spec.
> 
> Currently, bnodes in a BGP bind only to individuals or other bnodes. According to the formal semantics (and the spirit) of RDF, bnodes represent existential (but unknown) information. If the information is encoded in RDF (or in other simple languages where existential information can always be uniquely and exactly materialised explicitly as bnodes, like RDFS and OWL-RL) then the existential meaning of bnodes in queries is correctly captured by binding them just to individuals or other bnodes. However, in OWL-2 Direct Semantics entailment regime a lot of existential information remain necessarily implicit, and we would weaken the notion of answer (wrt standard OWL-2 Direct Semantics entailment regime in 25 years of description logics literature) if we do not treat bnodes in BGPs properly.

I'd prefer a more neutral term, such as "treat bnodes in BGPs according to a straightforward extrapolation from the RDF semantics". I would argue, myself, that that isn't the proper way to treat them. Indeed, I would argue (and have a lot) that it's not the proper way to treat them in RDF graphs :)

[snip]
> So, my proposal would be - only in the case of the OWL Direct Semantics entailment regime - to allow (as an option -- say, with a flag -- or as an additional definition) for an extended meaning of bnodes in the query as proper existential nodes. In this case the answer to a query - when bnodes in the answer are filtered out - is monotonically richer (that is, any non-bnode element of the answer set in the original semantics is also in the answer set of this stronger semantics, but not viceversa).

Yes, but filtering BNodes removes answers. And most users experience and expect the BNodes.

> When treating bnodes as proper existential nodes in the case of the OWL Direct Semantics entailment regime, bnodes should be filtered out from the answer since nothing is known in the research literature about what happens when we leave them in (e.g., they may be infinitely many, since they are not restricted anymore to be bound to to existing nodes or blank nodes in the graph).

This is at least one reason to not standardize this.

> Let me know what do you think about this proposal.

(Writing not as an active group member, but as a highly interested party.)

I'm don't think this is a good idea.. Please note that this is a reversal of a long held position (indeed, I championed non-distinguished variables in the first SPARQL WG).

On the one hand, adding some sort of (even more?) optional variant that is well known and defined is relatively harmless. OTOH, standards body should do some picking and choosing. The practical pain induced by having non-distinguished variables is far too high for any known benefits (see the above). So, I think it's a disservice to introduce them into these documents. In over 6(!) years of teaching and evangalizing non-distinguished variables, I've not been able to come up or have anyone come up with a compelling example (or even a naturally occurring example) that wasn't tree like and then only by backporting an existential restriction. That suggests that, at the very least, it's premature to standardize.

Interpreting BNodes the way we do matches exactly just about every users expectations (so doesn't surprise them). The BNode patterns we know how to implement are easily captured by class expressions and it's *much* easier for users to understand that distinction than to understand a rather strange synonym for existential restrictions that is also a homonym for something else.

Also, I'd be very surprised if implementors wanted to support this. I personally think Pellet should rip out that bit of implemetnation.

Finally, since it's so well defined and understood its not like if it becomes suddenly known useful that there'd be any barrier to implementations picking it up.

Right now, we have a very clean story for users and implementors. There's some hysterical raisons in the mix, but the story is reasonably clean in spite of that. Adding reasoning adds answers. Period. Let's not muddle it.

Cheers,
Bijan.

Received on Tuesday, 30 November 2010 12:16:48 UTC