- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Mon, 30 Mar 2009 12:16:37 -0400
- To: Chimezie Ogbuji <ogbujic@ccf.org>
- CC: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>, 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>
Chimezie Ogbuji wrote: > I think I'm going to break this out into a separate feature request and try > to better articulate the problem and suggested solutions before we run out > of steam in our current feature review. That would be great - reading below, I think we're still not communicating well with each other, so rather than keep at it, I'd like to see this feature request articulated so I can understand it better. For now, I see 3 potential distinct features here: 1/ A way for users to explicitly write a query that defines the default graph component of the RDF dataset as comprising "the RDF merge of all graphs that the SPARQL engine knows about". This is what's been referred to at times in the past as "FROM *", and is the one that I am sympathetic too but have trouble imagining how it would be specified. 2/ A way for users to explicitly specify that the named graphs component of the RDF dataset should be merged and used as the default graph of the RDF dataset. I don't really understand what this would gain, since to get to this point you'd already have needed to somehow specify (e.g. via FROM NAMED) the relevant graphs that should be named graphs in the RDF dataset, and you can use that same mechanism (e.g. FROM) to stick those graphs' contents into the default graph part of the RDF dataset. 3/ A way for users to refer to RDF datasets by name. I wrote about how we deal with this in Open Anzo (via "named datasets") here: http://www.thefigtrees.net/lee/blog/2009/03/named_graphs_in_open_anzo.html I'm pretty happy with this approach but don't personally think it's ripe for standardization. Lee >> Right, but this just scopes part of the query to the dataset, which has >> already been defined as above. Unless I misunderstand, the feature in >> question is how does a SPARQL user specify that they want to query >> against "all the graphs that the engine could possibly query". > > The feature I had in mind was "how does the user specify that they want to > query against all the named graphs of the specified dataset" preferably as a > default graph. So, it is exactly about specifying which subset of the > dataset should be queried and how to carve up such subsets and (possibly) > refer to them by name. > >> This sounds like a different feature to me: this sounds like asking for >> some way to treat the named graphs in a data set as a single graph. But >> I don't see any reason for that since you can just use the default graph >> for that - since you already needed to have some way to define the named >> graphs in your data set as containing "all graphs", you could just as >> easily define the default graph as containing "all graphs". > > Right, but currently if this is not specified by the user (in some way, > currently FROM ... is the only way) then the server can provide anything for > the default graph (including an empty graph , which is what the tests in the > latest test suite sanction). > > The motivation here is that an empty default graph is not quite as useful as > a default graph that (either by default or by specific instruction from the > user) is instead the merge of all the named graphs and it would be nice if > there was an explicit way to specify this w/out relying on the applications > behavior which could differ between systems. > >> Well, that's a bit different since everything inside GRAPH ?var { ... } >> needs to match against a single graph from the named graph part of the >> data set. > > Yes, I realize that now. Which means that even this would not work as a > workaround for the need described above (unless the the desired behavior is > to match against a single graph from the named graph). >
Received on Monday, 30 March 2009 16:17:22 UTC