Resend: [All] SPARQL Query Language Review

I sent this originally Sat pm but it has not appeared in the archive
yet, so ...

B

-----Original Message-----
From: McBride, Brian 
Sent: 05 November 2005 19:36
To: 'David Wood'; public-swbp-wg@w3.org
Subject: RE: [All] SPARQL Query Language Review

 

> -----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
  WHERE
  {
    ?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
discussion?

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

Brian


[...]

[a1]
http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0036.html

Received on Sunday, 6 November 2005 21:05:11 UTC