Re: Blank node identifiers in FILTER clauses

On Jul 24, 2006, at 7:37 PM, Eric Prud'hommeaux wrote:
[pruning ruthlessly, not caring about attribution too much]

[snip]
>> ?Wine is treated as a distinguished variable. In this sense it
>> doesn't not quite conform to the SPARQL semantics, but since there
>> are no SPARQL semantics for OWL DL, and quasi-distinguished variables
>> are a new phenomenon, I think this is acceptible. Distinguished
>> variables bind *only* to named entities, thus their bindings may not
>> be BNodes, which are *not* names, but existential variables.
>
> SPARL Query 2.7 Blank Nodes in Query Results gives examples of
> bindings to blank nodes, as does XML Query Results 2.3.1. Variable
> Binding Results (per the RDF Semantics definition of bNodes [BN]).

This is completely and totally irrelevant. Distinguished variables  
bind only to names. Undistinguished variables bind to whatever but  
don't return binding. This is just standard terminology. What don't  
you get?

Pellet uses ?vars to indicate distinguished variables and blank nodes  
in the query to indicate nondistinguished variables. Hence the  
behavior you see.

This working group has introduced a new kind of variable that I've  
been calling semi- or quasi-distinguished which can bind to  
existential variables. This is accomplished via a scoping set and is  
not required behavior for all applications of the semantic framework.  
If you just purge the scoping set of blank nodes, then you will get  
the normal behavior of variables (that is ?vars will be  
distinguished, not quasi-distinguished). Since there IS no mandated  
semantics for SPARQL-OWL-DL, it's pretty much up to the  
implementations to do what they want. I personally think that quasi- 
distinguished variables are interested and potentially useful, but  
they are decidedly new. Pellet implements a more common and  
traditional behavior, as to the other description logic query systems.

So, dude, the whole problem is that you don't understand the  
terminology. There's nothing mystical here. There's nothing special  
about the proof procedure.

[snip]
>> If the scoped set for the OWL DL entailment regime contains BNodes
>> (making ?vars quasi-distinguished), then we should expect the above
>> two queries to return with bindings. If not, then the current
>> behavior is correct. Since it's not yet defined, I think we're ok :)
>
> I would expect that the entailment for RDF would be sufficient
> here.

Your expectation is unfounded and wrong. You don't understand the  
semantics of sparql. What can be in a binding is determine by the  
*scoping* (sorry, not "scoped") set, not the entailment regime. You  
could get no bnodes in answers coupled with RDF entailment by not  
allowing bnodes in the scoping set.

> That is, the triple pattern
>   food:MyLunch hasDrink ?x .
>   ?x hasColor :White .
> should match
>   food:MyLunch hasDrink _:q .
>   _:q hasColor :White .

Not if the scoping set is restricted to literals and uris. Which  
would make the ?vars distinguished...a perfectly sensible thing to do.

[snip]
>> The above KB is not a legal OWL DL KB, so it cannot be entailed. (See
>> the transformation to triples:
>> 	<http://www.w3.org/TR/owl-semantics/mapping.html#4.1>
>> """Bnode identifiers here must be taken as local to each
>> transformation, i.e., different identifiers should be used for each
>> invocation of a transformation rule. Ontologies without a name are
>> given a bnode as their main node; ontologies with a name use that
>> name as their main node; in both cases this node is referred to as O
>> below.""")
>
> Hmm, I read this as a directive about the notation in the mapping
> table. That is, I expec that

I don't know what you meant to write, but you are wrong if you think  
that this allows for:

	_:x :p _:x.

To be a legal OWL DL ontology. It isn't. Try a species validator.  
It's not known if entailment, given arbitrary bnodes in aboxes, is  
decidable for OWL DL.

[snip]
>>> We were trying match:
>>>  Paul :hasFriend _:Y .
>>>  _:Y rdf:type Employee .
>>>  _:Y hasFriend _:Z .
>>>  _:Z rdf:type Manager .
>>
>> This isn't cyclic.
>
> Agreed. Perhaps I should have worked harder on the segue.

Or read up a little.
[snip]
> Are you saying that one can query the little house inference

Little house? What? I don't care.

> without
> the current semantics of indistinguished variables?

Nondistinguished.

> Or are you
> agreeing that, if the inference manifests in an RDF graph, that the
> triples can be matched by either variables or bNodes?

Dude, it doesn't make any sense to discuss stuff without specifying  
which instantiation of the scoping set and entailment regime you want  
to discuss. It *depends* on these.

>>> I'm really surprised this is not how people currently handle OWL
>>> semantics.
>>
>> I suspect it's because you don't understand OWL semantics, and have
>> not studied how to implement a sound and complete reasoner. Or
>> rather, you don't recognize the distinction between an anonymous or
>> generated individual in a model, and a BNode.
>
> You're right. Until we get to counting, I don't see how the use of
> bNodes is insufficient for representing the graph pattern that we are
> currently matching with bNodes in the the SPARQL pattern.

You don't need counting to make the idea of matching *a* graph  
pattern insufficient. Disjunction suffices.

If you want to go back to the crazy "deductive closure" stuff, well,  
you'll have a hard row to hoe. In fact, I request we stop this right  
now.

[snip]
>> Well, it really doesn't make sense to talk of "backward chaining"
>> since you just don't chain at all, really. Pellet does do some data
>> driven inference (e.g., classification and realization) and some on
>> demand inference (e.g., arbitrary entailments, and queries at the
>> moment), but it's not really a helpful way to think about it.
>
> Right, I was just trying to understand why cyclicity came up at all.
[snip]
*Really*? That wasn't evident to me.

IIRC, Enrico raised it to point out that BNodes aren't sufficient to  
represent all answers for OWL DL, since cyclic answers are possible,  
but not representable in OWL DL:

""""You can't do that since you can not represent all the possible
answers. You couldn't represent the case when there is a cyclic
coreference between bnodes.
E.g., _:a R _:b.
       _:b S _:a.""""

I think it's time to wind down this discussion as I don't see how it  
remotely is going to help resolve whatever issues started all this up.

Cheers,
Bijan.

Received on Monday, 24 July 2006 19:05:44 UTC