W3C home > Mailing lists > Public > public-swbp-wg@w3.org > December 2005

SPARQL semantics: open issue bnodeRef

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Thu, 29 Dec 2005 17:04:53 +0100
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>, public-swbp-wg@w3.org
Message-Id: <04BA1BB1-C359-4712-8D85-C8FB89322BA6@inf.unibz.it>
Cc: David Wood <dwood@softwarememetics.com>, Brian McBride <brian.mcbride@hp.com>

> From: Dan Connolly <connolly@w3.org>
> Date: 29 December 2005 15:25:43 GMT+01:00
> To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
> On Tue, 2005-12-27 at 19:37 +0100, Enrico Franconi wrote:
>> b) we want back the ability to label bnodes in a query as
>> "told-bnodes", in order to allow, e.g., for the use case
>> "Publishing on the Web" in
>> <http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/ 
>> 0430>;
>> also in the SWBP WG there are several requests to allow
>> for this, for example
>> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0176>.
> As we (re)discovered in the teleconference, the WG discussed
> a relevant issue, bnodeRef, at some length...
>   http://www.w3.org/2001/sw/DataAccess/issues#bnodeRef
> and decided, 2005-07-12, to postpone it.
> In all the discussion of it that I have seen recently, the
> designs go out of scope (by introducing yet another sort
> of term beyond literals, URIs, bnodes, and ?variables
> at the abstract syntax level) without a clear requirement
> nor a compelling use case. The "Publishing on the Web"
> use case does not have a critical mass of support.
> We'll need new information in order to re-open bnodeRef
> and consider designs.

Aren't you happy of the lengthy discussion in the SWBP WG I was  
I believe these are compelling cases from the real users community,  
and that they are enough to support the addition of an optional  
"told" keyword for each bnode in a query (or of an optional unique  
"told" keyword in a query, listing all the told bnodes).
I paste the latest summary message from the SWPB WG below

On 5 Nov 2005, at 17:29, David Wood wrote:
> Hi all,
> This message contains comments on SPARQL [1] problems with blank  
> nodes which specifically impact SWBP work.  It is in continuation  
> of the action item at [2].
> I wrote in [3] regarding blank nodes:
> On Oct 14, 2005, at 14:31, David Wood wrote:
>> 3)  The handling of blank nodes ("bnodes") is, again in my  
>> opinion, the single greatest failure of the specification.  We  
>> have to admit that RDF graphs contain bnodes and queries will run  
>> across them.  We also have to admit that a querier will (not  
>> 'may') often want to subsequently find information connected to  
>> those bnodes.  SPARQL's insistence that bnodes' true internal  
>> identities not be returned to a querier (correct in and of itself)  
>> combined with the lack of subquery capability ensures that many  
>> useful RDF queries routinely performed in other languages simply  
>> cannot be written in SPARQL.  OPTIONAL addresses only part of that  
>> functionality.
> There are at several places where the need to query across blank  
> nodes pop up in SWBP work.  Some of them are:
>   - SKOS Core
>   - RDF/A
>   - N-ary Relations
> The SKOS Core Guide [4] includes an example where a blank node is  
> used to represent a collection.  How, using SPARQL, could one  
> construct a query which asks, to use the example collection in the  
> Guide, for the rdfs:labels of any collections which includes a  
> skos:member ex:buffalomilk?
> The RDF-in-XHTML TF has been wrestling [5] with a use case  
> requiring the definition of properties referencing blank nodes. The  
> RDF/A Syntax [6] uses the CURIE proposal [7] to generate blank  
> nodes. Therefore, I make the case that since they are producing  
> graphs inclusive of blank nodes, SPARQL should be able to make  
> queries regarding those properties indirectly (e.g. "give me all  
> docs/elements which have things which have property x" and more  
> complex variations on that theme).  Ralph has commented privately  
> that he considers that important.
> Nokia's comments to SPARQL ([8] and [9]) suggest that they consider  
> support for transitive closure to be important, which is another  
> way of addressing the same issue.
> The N-ary Relations draft's Use Case 3: N-ary relation with no  
> distinguished participant [10] uses an "aggregating node" and  
> assigns it an explicit URI.  John Madden from Duke University has  
> made the (correct, IMHO) suggestion [11] that the aggregating node  
> should be a blank node.  In that case, he goes on to raise issues  
> regarding the applicability of OWL DL and comments, "In the  
> examples given, it strikes me as pretty likely that the aggregating  
> node would be a juicy target to be the object of other triples."   
> John seems to be thinking along lines similar to Ralph, Nokia and  
> myself.
> Therefore, I contend that sufficient need for querying across blank  
> nodes (whether by transitive closure or another mechanism, such as  
> subqueries) exists within the body of SWBP work and propose that  
> the working group take such a position with the DAWG regarding the  
> lack of such support in SPARQL.
> [1] http://www.w3.org/TR/rdf-sparql-query/
> [2] http://www.w3.org/2005/10/03-swbp-minutes.html#action17
> [3] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/ 
> 0107.html
> [4] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/
> [5] http://www.w3.org/2005/04/05-swbp-minutes.html
> [6] http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa- 
> syntax#id87921
> [7] http://www.w3.org/2001/sw/BestPractices/HTML/2005-10-21-curie
> [8] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/ 
> 2005Sep/0007.html
> [9] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/ 
> 2005Sep/0023.html
> [10] http://smi-web.stanford.edu/people/noy/nAryRelations/n- 
> aryRelations-2nd-WD.html
> [11] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Jul/ 
> 0017.html
> Regards,
> Dave
Received on Thursday, 29 December 2005 16:10:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:15 UTC