W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > April 2005

Re: Comments on SPARQL 17-Feb-2005 draft (SOURCE, Multiple-graph queries)

From: Graham Klyne <GK@NineByNine.org>
Date: Mon, 11 Apr 2005 17:03:49 +0100
Message-Id: <>
To: Dan Connolly <connolly@w3.org>, public-rdf-dawg-comments@w3.org


Thanks for your response.  I'll make some further comments, but I should 
say first that I feel less strongly about this than I do about the slightly 
related separation of I/O that I mentioned in another message, and won't 
object if DAWG really feels that multi-graph queries are needed.

At 14:06 08/04/05 -0500, Dan Connolly wrote:

> > 1. Multiple-graph queries
> >
> > I think these should be removed from the basic SPARQL core, since I feel
> > they add a fair deal of implementation complexity and an application can
> > achieve the same result by submitting multiple queries, possibly to
> > different query processors.
> >
> > I also feel it would be premature to standardize an approach to 
> multi-graph
> > querying ahead of there being a consensus/standard for something like RDF
> > named graphs.
>I think the WG has considered this argument under our SOURCE issue.
>   http://www.w3.org/2001/sw/DataAccess/issues#SOURCE

See below...

>While some argued, as you do, that it's premature to standardize,
>use cases such as
>  2.11 Finding Out New Things About People (Social Network Analysis)
>  http://www.w3.org/TR/rdf-dawg-uc/#u2.11

This use-case looks sound to me.

>motivated this design. More explicitly, it motivated a design objective...
>  4.2 Data Integration and Aggregation
>  http://www.w3.org/TR/rdf-dawg-uc/#d4.2
>which, by the way, was accepted without consensus, i.e. over an
>objection. So that will have to get reviewed when we request CR/PR.
>Though I don't see sufficient new information to re-open this issue in
>the WG, I have noted your comment under the SOURCE issue so that it
>will be part of that review.
>Feel free to add any further arguments that perhaps the WG
>has not considered, and please stay tuned for our last call
>documents; I hope by then we will have achieved a greater
>level of consensus.

Reviewing these, the SOURCE issue and corresponding design issue seem to 
combine two matters:
- referring to the source graph within a query, and
- matching multiple graphs in a single query

It might be interesting to explore a design that separates these issues, so 
that any cross-graph searching strategies are left to a higher layer.  For 
example, if a query is submitted to just a single graph, it might still 
make sense to have the NamedGraphPattern as part of a query, and for the 
graph to which the query may be submitted be either unnamed (background) or 
named.  UI think such a design might also need to allow a partial variable 
binding as input to as well as output from a query, so that the final 
variable binding result can be the result of several 'primitive' 
queries.  I think I can see an implementation of this being quite 
straightforward (indeed, it would be part of how I would implement queries 
over multiple graphs).

(You might feel that such a design introduces a different set of 
complexities --- it might be harder to explain -- so I offer this as a 
possible different approach, not as an assertion of a better solution.)


Graham Klyne
For email:
Received on Tuesday, 12 April 2005 00:00:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC