Re: Blank node identifiers in FILTER clauses

On 16 Jul 2006, at 19:13, Eric Prud'hommeaux wrote:
> In order to give you more to argue with, I've worked out some triples
> that I think are implied by your little house example.
>
> We were trying match:
>
>   Paul :hasFriend _:Y .
>   _:Y rdf:type Employee .
>   _:Y hasFriend _:Z .
>   _:Z rdf:type Manager .
>
> There are two possibile interpreations relavent to proving this.
> Either the left or right of:
>
>   Paul rdf:type Worker .        Paul rdf:type Worker .
>   Paul :hasFriend Andrea .      Paul :hasFriend Simon .
>   Andrea rdf:type Employee .    Simon rdf:type Employee .
>   Andrea :hasFriend Caroline .  Simon :hasFriend Andrea .
>   Caroline rdf:type Manager .   Andrea rdf:type Manager .
>
> Since all sides of the disjunction entail
>
>   Paul :hasFriend _:Y .
>   _:Y rdf:type Employee .
>   _:Y hasFriend _:Z .
>   _:Z rdf:type Manager .
>
> I think you should be able to infer it, and then query it:
>
> SELECT ?X
> WHERE { ?X rdf:type Worker .
>         ?X :hasFriend ?Y .
>         ?Y rdf:type Employee .
>         ?Y :hasFriend ?Z .
>         ?Z rdf:type Manager } # note ?vars

As mentioned by Bijan, if E-entailment in SPARQL is standard OWL-DL  
ABox entailment (which is at the heart of Pellet), then the well- 
formedness condition for "(G' union S(BGP'))" (section 5.1 in rq24)  
says that only individuals can be used in the answer set - no bnodes.  
In this context, the above query (as correctly it does in Pellet)  
will return the empty set. This has been already discussed at length  
in the past (see, e.g., <http://lists.w3.org/Archives/Public/public- 
rdf-dawg/2006JanMar/0305>). Non-distinguished variables *do* provide  
more expressive power when querying RDF graphs whose semantics imply  
the existence of implicit bnodes, like in the little house example.  
If your query language does not allow bnodes in the answers, then you  
can see how it is impossible to query the little house.

> I'm really surprised this is not how people currently handle OWL
> semantics. bNodes are perfect for this.

Why does OWL-DL (and the whole literature and pracrice of databases)  
consider bnodes (aka existential variables) in the answer set?  
Because answers would not be unique anymore (there would be  
infinitely many different answers to a query to a dataset), and most  
horribly, some of them may be infinitely long.

> If anyone wrote a backward-chaining OWL engine, it seems they'd  
> have to do this.

I hope I convinced you. Backward chaining is irrelevant here, we are  
talking about sound and complete reasoners wrt OWL-DL semantics.

cheers
--e.

Received on Monday, 17 July 2006 20:42:14 UTC