RE: Querying "all graphs"



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Lee Feigenbaum
> Sent: 30 March 2009 17:17
> To: Chimezie Ogbuji
> Cc: Kjetil Kjernsmo; 'RDF Data Access Working Group'
> Subject: Re: Querying "all graphs"
> 
> 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


A couple of Jena stores provide the feature of providing the RDF merge of all the named graphs in the dataset.  This can be accessed via a URI (there's no reason why a graph can't be in the dataset in different ways under different names) or the engine can be told to make default graph the RDF merge of named graphs.  This is a property of the SPARQL service being offered.

The computer graph is a strict RDF graph - the computed merge masks duplicates.

In fact the "real" default graph is also available via a named graph with a particular URI even if the query default graph is the RDF merge of named graphs.

Eg.

http://jena.hpl.hp.com/wiki/TDB/Datasets


I'm not sure this is the best way to do it - it is a way to do with without needing to change SPARQL.

The thing I see as missing to what I understand Chimezie describes, is the ability for the client to ask for the service to reconfigure for this mode.  At the moment, the solution is one where it's a feature of what the service offers.

So it covers 2 (via configuration of the service or query processor) and 3 but not 1.  It's more for the case where FROM/FROM NAMED are not being used and it's about what the service offers.

 Andy


> 
> >> 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:41:15 UTC