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.

Received on Thursday, 12 January 2006 22:30:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:07 UTC