- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Wed, 18 Mar 2009 11:59:42 -0400
- 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 UTC