- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Thu, 19 Mar 2009 10:05:26 +0000
- To: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
> -----Original Message----- > From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg- > request@w3.org] On Behalf Of Lee Feigenbaum > Sent: 18 March 2009 16:00 > To: SPARQL Working Group > Subject: [BlankNodeRefs] Questions on blank node refs > > (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. There are two kinds of bNodes, bnodes as elements of query syntax (things such as [] and _:a in the query string) and being able to use something to refer to a bNode in the data which the <_:label> scheme that several systems use gives. <_:label> are the query constants that refer to a bNode in the data. They don't get mixed up with bNodes-as-non-distinguished-variables in queries. In ARQ, blanks-as-query-variables are internally variables (they can be distinguished from named variables). Some dancing occurs when printing a query to reverse the process. > 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. Agreed - they only make sense referring back to a data source that issued the blank node in the first place. > 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. Agreed. We can't require reading a file twice to preserve bnode labels because that's wrong. It only applies to persistent data and even then some systems only guarantee the label for the duration of a session or some other system concept. One possibility here is to write a working group note that documents the usage but does not make it a fully-fledged feature of SPARQL (i.e. in a REC) Andy > > Lee > > [1] http://www.w3.org/TR/rdf-sparql-query/#sparqlBGPExtend
Received on Thursday, 19 March 2009 10:06:43 UTC