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

Hi,

Le 31 mars 09 à 11:32, Steve Harris a écrit :

> 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

I also believe this is the most convenient way from an end-user  
perspective: "if you don't provide any restriction on the FROM clause,  
please query anything that's inside the store".

> others do, but I guess not everyone does that.

If I remember well, RAP does not use (at least it didn't) that  
strategy, then running a query on a store that contains named graphs  
without specifying a FROM / GRAPH clause will not return anything.
This is imho the kind of things that should be agreed within this WG,  
as it will help to use the same queries (w/ same results expected)  
whatever the engine is, then allow to switch easily from one store to  
another in, e.g., an enterprise architecture without redesigning the  
queries, etc.

While it not may be in the rec itself due to time restrictions / other  
priorities, a note on best practices for triple-store implementations  
might mention this kind of things (as well as using content- 
negociation / mimetypes to get results using a particular format, etc.)

Best,

Alex.

>
>
> - 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 9AD
>
>

-- 
Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Tuesday, 31 March 2009 10:57:46 UTC