Re: Blank node identifiers in FILTER clauses

On Fri, Jul 14, 2006 at 05:37:16PM +0200, Eric Prud'hommeaux wrote:
> 
> On Fri, Jul 14, 2006 at 02:48:10AM +0100, Enrico Franconi wrote:
> > 
> > On 13 Jul 2006, at 17:23, Eric Prud'hommeaux wrote:
> > 
> > >Note that this graph does not directly create any triples with
> > >food:hasDrink or wine:hasColor in the predicate. MyDinner must have a
> > >drink because it is a RedMeatCourse, which is a subClassOf something
> > >which, if it has a Drink, must have a Red drink. Also, it's a
> > >MealCourse, which must have at least one Drink.
> > >
> > >So there we go. It must hasDrink of something with the color Red.
> > >
> > >Query:
> > >PREFIX food: <http://www.w3.org/2001/sw/WebOnt/guide-src/food#>
> > >PREFIX wine: <http://www.w3.org/2001/sw/WebOnt/guide-src/wine#>
> > >SELECT ?Meal ?WineColor
> > >WHERE {
> > >   ?Meal food:hasDrink _:Wine .
> > >   _:Wine wine:hasColor ?WineColor }
> > >
> > >Pellet <http://www.mindswap.org/2003/pellet/demo> gives these
> > >results:
> > >
> > >|  Meal 	| WineColor |
> > >+---------------+-----------+
> > >| test:MyLunch 	| :White    |
> > >| test:MyDinner	| :Red	    |
> > >
> > >
> > >When querying Pellet for:,
> > >   ?Meal food:hasDrink ?Wine .
> > >   ?Wine wine:hasColor ?WineColor
> > >
> > >it gives no results because it has no bindings for the Wine. But why
> > >not? Certainly, it as deduced that there is something there, but it's
> > >opaque to RDF. Why doesn't it infer the triples:?
> > >  food:MyLunch hasDrink [ hasColor :White ] .
> > >  food:MyDinner hasDrink [ hasColor :Red ] .
> > 
> > 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.
> 
> Perhaps I misinterpret here, but I thought that would be an argument
> against materializing a closure and then querying it, as opposed to
> proving the existence of certain triples.
> 
> What query pattern could one match with bNodes and SPARQL's current
> entailment rules for matching that one couldn't match with variables
> against the inferred graph? (Note, showing me why Pellet should not
> infer
>   food:MyLunch hasDrink [ hasColor :White ] .
>   food:MyDinner hasDrink [ hasColor :Red ] .
> would be one way to answer this question.)

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

I'm really surprised this is not how people currently handle OWL
semantics. bNodes are perfect for this. If anyone wrote a backward-
chaining OWL engine, it seems they'd have to do this. (Come to think
of it, I think cwm is basically backward-chaining.)

Or maybe I just don't get something...


> > Bnodes give a true increase in expressivity whenever coreference in  
> > the answer set plays a role.
> > 
> > >That seems quite in order to me, freeing us to use bNodes as
> > >existential that affect future counting semantics, or remove them,
> > >treat them exactly as regular variables except you can't select them
> > >and they don't show up in SELECT *.
> > 
> > If you want to remove bnodes, and have variables to play their role  
> > when "not selected" (i.e., projected away), then the semantics of  
> > SPARQL should change: it should not be anymore the current two stages  
> > evaluation (BGP + algebra) but it should be uniformly defined with a  
> > *global* notion of (non-distinguished) variable assignment that  
> > considers the whole SPARQL expression. It could be interesting.  
> > Necessary time to come up with a convincing theory and practice about  
> > it: at least one year, I guess..., or more if we do start discussing  
> > with Pat about the details :-)
> > That's why I always said that a standardising effort like SPARQL  
> > should come *after* researchers have done their duty and the results  
> > are mature enough to be applied.
> > 
> > cheers
> > --e.
> 
> -- 
> -eric
> 
> home-office: +1.617.395.1213 (usually 900-2300 CET)
> 	    +33.1.45.35.62.14
> cell:       +33.6.73.84.87.26
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.

-- 
-eric

home-office: +1.617.395.1213 (usually 900-2300 CET)
	    +33.1.45.35.62.14
cell:       +33.6.73.84.87.26

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Sunday, 16 July 2006 17:12:25 UTC