- From: Graham Klyne <GK@NineByNine.org>
- Date: Mon, 11 Apr 2005 17:03:49 +0100
- To: Dan Connolly <connolly@w3.org>, public-rdf-dawg-comments@w3.org
Dan, 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.) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Received on Tuesday, 12 April 2005 00:00:20 UTC