Re: Blank node identifiers in FILTER clauses

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