Re: Blank node identifiers in FILTER clauses

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.)

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

Received on Friday, 14 July 2006 15:36:09 UTC