RE: [BlankNodeRefs] Questions on blank node refs



> -----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