W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

Re: Querying "all graphs" (was: Re: Graph to retrieve DESCRIBE result from)

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 31 Mar 2009 11:32:48 +0100
Message-Id: <42BC1BB6-B295-414A-97B4-3CEF5699DD57@garlik.com>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 30 Mar 2009, at 16:17, Chimezie Ogbuji wrote:
>> 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.

Right, I've never quite liked this bit of design in SPARQL. My stores  
all work as if the default graph was the union (or something similar)  
of all the named graphs, and I know a couple of others do, but I guess  
not everyone does that.

- Steve

Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
Received on Tuesday, 31 March 2009 10:33:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC