Re: [BlankNodeRefs] Questions on blank node refs

On 19 Mar 2009, at 10:05, Seaborne, Andy wrote:
>
>> -----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.

Same in my systems.

It's one of the few areas where we've been strongly encouraged to go  
outside of SPARQL, it's especially useful when dealing with real-world  
FOAF data.

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

Right, and possibly in conjunction with some system that is able to  
describe the capabilities of a SPARQL system, c.f. the work Bijan and  
I did in DAWG, which got postponed IIRC, and  
Feature:ServiceDescriptions.
Which would potentially allow you to tell which systems where  
interoperable, even though they can't all be.

- Steve

>>
>> [1] http://www.w3.org/TR/rdf-sparql-query/#sparqlBGPExtend
>

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Thursday, 19 March 2009 11:43:37 UTC