W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

[BlankNodeRefs] Questions on blank node refs

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Wed, 18 Mar 2009 11:59:42 -0400
Message-ID: <49C11A6E.6010900@thefigtrees.net>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
(This is my issue for today to pick on a bit.)

I have a few questions and concerns about BlankNodeRefs, but first, 
here's my brief summary of the issue as I understand it (proponents, 
please fill in any gaps!)

Currently, when a blank node is returned as a query result, the ID 
(label) of the blank node only has any meaning within the scope of the 
result document (XML document or graph). SPARQL does not provide any way 
to then write a subsequent query that refers explicitly to a returned 
blank node.

The BlankNodeRef proposed feature would add a mechanism to refer 
explicitly to blank nodes returned from previous queries. This is 
useful, for instance, if a query writer/application wants to traverse 
(one query at a time), a structure such as an RDF list that is composed 
largely of blank nodes.

Here are my questions & concerns:

1/ implementation burden on systems that treat blank nodes as 
existentials -- in particular here I'm thinking of any SPARQL engine 
that has extended SPARQL BGP matching as per 12.6 in the spec [1] with 
some level of entailment that looks at blank nodes as existentials.

2/ interoperability - I question whether this is a key feature to 
standardize to promote interoperability. Blank node labels used via this 
feature will not, of course, be re-usable across implementations. I 
realize that an argument can be made that this promotes interoperability 
of applications that rely on re-using blank node refs, but I'm not 
thoroughly convinced that that meets my (personal) bar for the need to 
promote interoperability.

3/ implementation cost for systems that do not maintain persistent 
labels for blank nodes - I have in mind here things like systems that 
download static RDF files on the fly to query against, or federated 
query approaches that need to re-serialize blank nodes ids retrieved 
from other SPARQL endpoints to avoid label clashes. It seems like a 
potentially unnecessary burden to require these sorts of systems to 
maintain new persistent state to handle blank node refs.

Lee

[1] http://www.w3.org/TR/rdf-sparql-query/#sparqlBGPExtend
Received on Wednesday, 18 March 2009 16:00:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:38 GMT