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

Re: [All] SPARQL Query Language Review

From: David Wood <dwood@softwarememetics.com>
Date: Sat, 5 Nov 2005 11:29:16 -0500
Message-Id: <365556C8-72B4-4F9F-8651-4704CD30138A@softwarememetics.com>
Cc: Brian McBride <brian.mcbride@hp.com>
To: public-swbp-wg@w3.org

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- 
[7] http://www.w3.org/2001/sw/BestPractices/HTML/2005-10-21-curie
[8] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/ 
[9] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/ 
[10] http://smi-web.stanford.edu/people/noy/nAryRelations/n- 
[11] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Jul/ 

Received on Saturday, 5 November 2005 16:29:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:45 UTC