W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2006

Re: major technical: blank nodes

From: Richard Newman <r.newman@reading.ac.uk>
Date: Thu, 12 Jan 2006 14:30:41 -0800
Message-Id: <13E8F196-A806-4794-BF71-5C8CF469E02A@reading.ac.uk>
Cc: public-rdf-dawg-comments@w3.org
To: Fred Zemke <fred.zemke@oracle.com>


On 12 Jan 2006, at 13:38, Fred Zemke wrote:
> Thus if the user, in the course of writing a
> query, later decided he wants to receive the value of the blank node,
> he must rewrite the query with a variable in place of the blank node.
> The user might as well just write the query without blank nodes from
> the beginning.

You are forgetting the instance where RDF triples are serialised to  
produce a query pattern (same syntax), or mechanically constructed.  
Variables have to be named, which needs a gensym-like construct; in  
this instance, one might as well use a bnode.

> A possible reply is that the "SELECT *" only selects
> the variables and not the blank nodes, so the distinction has a  
> meaning.
> However, SQL has found that the wildcard asterisk in the SELECT list
> was a bad language idea, and I do not recommend it for SPARQL.

SPARQL is not SQL, and it's a bit of a leap to say that because  
something is bad in SQL it must be bad in SPARQL.

Again, consider machine-generated queries. Employing blank nodes and  
SELECT * makes for a much simpler query generator IMO.

> This is not a criticism of the blank nodes of the form [ :p "v" ],
> which correspond to the linguistically useful "that which"  
> construction.
> Perhaps the reply is that blank nodes of the form _:a or [] exist
> to provide the translation for [ :p "v" ].  However, the rule for
> translating these says that the implementation must create a unique  
> blank
> node, ie, different from any that the user has already placed in the
> query; it could just as well be worded to say that the  
> implementation must
> create a unique variable name, different from any the user has chosen.

That seems like a reasonable point.

> This is not a criticism of blank nodes in CONSTRUCT templates, where
> there actually is connection between the SPARQL blank nodes and
> RDF blank nodes.  Blank nodes in the CONSTRUCT template should be
> retained.

I think there is some utility in maintaining some equivalence between  
SELECT and CONSTRUCT templates and patterns. Allowing blank nodes  
allows for useful substitution between these two places.

-R
Received on Thursday, 12 January 2006 22:30:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:49 GMT