Re: Blank node identifiers in FILTER clauses

On Thu, Jun 29, 2006 at 11:54:24AM +0200, Jeen Broekstra wrote:
> 
> Bijan Parsia wrote:
> >On Jun 28, 2006, at 1:32 PM, Kendall Clark wrote:
> >
> >>On Jun 28, 2006, at 5:15 AM, Jeen Broekstra wrote:
> >>
> >>>I can live with either of these and have a slight preference for the
> >>>second. To be honest I could live without the blank nodes in queries
> >>>altogether. They are confusing and annoying (this discussion is a case
> >>>in point), and I find the supposed 'cut&paste' benefit unconvincing. But
> >>>that station is passed I guess.
> >>
> >>I couldn't agree more. I wasn't convinced by it as a reason, offered 
> >>by TimBL, for turtleizing our syntax, and I'm even less
> >>convinced by it now. It's the biggest single wart on SPARQL and I wish 
> >>we could chop it off w/out mercy.
> >>
> >>But I'm also not convinced that it's too late. If the WG decides to do 
> >>it, and will put in the work to make it happen,
> >>then it's "merely" a matter of doing the work.
> >
> >I would like to separate the syntax issue from the capability issue. At 
> >the moment, as I understand it, BNodes in the query represent 
> >*undistinguished* variables, that is, variables that do not need a 
> >binding to a constant and *cannot* report their bindings (thus don't 
> >need to establish one).
> 
> I'm not sure I understand this (though I *think* I agree with it ;)). I 
> have always understood that it currently works like this: blank node 
> identifiers in graph patterns act exactly the same as variable names (in 
> that the same bnode id in the same graph pattern is unified), only the 
> scoping is different and we can not report the binding in the 
> projection. It does need to establish a binding though, otherwise the 
> graph pattern match fails.
> 
> Using "unidentified" blank nodes (the square brackets syntax) however is 
> more akin to what you say: each blank node in the graph pattern is 
> unique and unaddressable, we can't unify it with a blank node anywhere 
> else in the graph, we just express that there should be _some_ value 
> (but don't care what that value is).
> 
> Perhaps I'm missing a bit of background here: can you clarify what you 
> mean with a 'distinguished' vs. a 'undistinguished' variable, exactly?
> 
> >This is an important capability (distinct from 
> >projection) which currently there is no other way to (exactly) express 
> >in SPARQL.
> 
> Yes, being able to use square bracket syntax as 'anonymous' variables is 
> useful I think:
> 
> SELECT ?x ?y
> WHERE
>  { ?x foaf:name [] ;
>       foaf:knows ?y .
>  }
> 
> or:
> 
> SELECT ?person ?friendname
> WHERE { ?person foaf:knows [
> 			    foaf:name ?friendname
> 			   ] .
>       }
> 
> But the blank node identifiers (_:a) used as variable names (...but with 
> different scoping) is just a pain IMHO. If you care about unifying the 
> binding somewhere else in the pattern (or getting the result in the 
> projection), give it a variable name. If you don't, use an anonymous 
> variable (square brackets).

I disagree, or perhaps, I have a different priority. While the use of
bNodes in a query to find people who know the same person:

  SELECT *
  WHERE { ?A foaf:knows _:known .
	  ?A foaf:knows ?B .
	  ?B foaf:knows _:known .
        }

can be replaced by a bit of syntax:

  SELECT ?A ?B
  WHERE { ?A foaf:knows ?known .
	  ?A foaf:knows ?B .
	  ?B foaf:knows ?known .
        }

I am betting (significant amounts of my time) that the parallelism
(and cut-and-paste-ism) with a popularly deployed assertion language
is worth the extra bit parser effort (keeping an association list of
bNode symbol to bNode). It is possible, however, that I am missing
some of Jeen's pain because I didn't fully implement something or
because he is working in a different context than I imagine.

> Cheers,
> 
> Jeen
> -- 
> Jeen Broekstra <jeen.broekstra@aduna-software.com>
> Senior Software Developer
> Aduna (http://www.aduna-software.com/)
> Prinses Julianaplein 14-b, 3817 CS Amersfoort, The Netherlands
> tel. +31-(0)33-4659987

-- 
-eric

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

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

Received on Sunday, 2 July 2006 10:38:05 UTC