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

RE: [All] SPARQL Query Language Review

From: McBride, Brian <brian.mcbride@hp.com>
Date: Sat, 5 Nov 2005 19:35:32 -0000
Message-ID: <DE62D3D0BDEF184FBB5089C7D387C37449ACAD@sdcexc04.emea.cpqcorp.net>
To: "David Wood" <dwood@softwarememetics.com>, <public-swbp-wg@w3.org>


> -----Original Message-----
> From: David Wood [mailto:dwood@softwarememetics.com] 
> Sent: 05 November 2005 16:29
> To: public-swbp-wg@w3.org
> Cc: McBride, Brian
> Subject: Re: [All] SPARQL Query Language Review
> 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].

Thank you David.  I'd like to say again sorry for not having raised my
concerns sooner.  I would like to redirect my attitude from a negative
one, to the positive search for specific examples where the SPARQL spec
is in conflict with SWBPD proposals. 

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

As David has alluded to elsewhere [a1] I don't think this example fully
illustrates his concern.  For the record, the suggested query can be
expressed in SPARQL as follows:

  SELECT ?label
    ?collection skos:member ex:buffalomilk .
    ?collection rdfs:label ?label

> 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

Making the case requires a cogent argument.  If I understand correctly,
the suggestion is that that because RDF-in-XHTML believe RDF/A should be
capable of representing graphs that contain blank nodes, that SPARQL
should be able to have names that reference blank nodes across queries.
If we are to make this case convincingly to DAWG I suggest that we
should spell out the logic in a bit more detail.  I confess I'm a bit
too tired to see an argument right now.

 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.

Ralph, do you have an example you would like to contribute to this

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

Support for transitive closure is not the same thing as support in
SPARQL for transitive closure.  A SPARQL query can be made against a
ground graph.  It can also be made against a graph which has been
inferred from a ground graph by some inferencing process.  Therefore,
support for transitive closure can be achieved by a SPARQL query against
a graph which is the transitive closure of a ground graph.  This does
not require specific support for transitive closure in SPARQL.  

If we are to suggest that SPARQL should have specific support for
transitive closure we should identify SWBPD proposals that require
transitive closure support in SPARQL itself.  Can any of the WG members
or task forces suggest an example based on such a proposal?

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

I confess I'd like to go eat, so I'm not chasing all the references.
This seems to say that current n-ary relations draft uses a resource
named with a URI for aggregating nodes, but that there is a comment that
such nodes should be blank, and those nodes might be the objects of
other triples, and (I'm inferring) this implies a need to name those
blank nodes across queries.

To nail this one, it seems to me that we need to determine whether the
n-ary relations draft should be changed in the manner suggested, that
the nodes in question will indeed be the objects of other triples and
that this does create a requirement on SPARQL.  Anyone care to take a
stab at any of those steps?  It seems to me that given the current draft
uses named nodes, and the shortage of time, this is a non-starter for a
SWBPD position unless we move very quickly.

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

I have the feeling that David may be right here, but that, in part due
to my lassitude, we don't yet have the arguments lined up to adequately
support the claims being made.  I am in a workshop tomorrow, but I will
try to find the time to join some of the dots, but help would be great.



Received on Saturday, 5 November 2005 19:35:47 UTC

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