Re: why I don't like default graphs in the DATASET proposal

On 09/30/2011 12:31 PM, Andy Seaborne wrote:
> 
> 
> On 29/09/11 15:42, Pierre-Antoine Champin wrote:
>> Hi all,
>>
>> as Richard asked me during the telecon of 09-29, I'll try to pinpoint
>> what bothers me in the SPARQL DATASET proposal.
>>
>> One such point is the notion of *default graph*, which works well
>> with SPARQL but, IMHO, is not relevant in RDF Concepts.
> 
> DAWG tried to use a different word for "default" recognizing it brought 
> various intuitions.  It was "background" at one time, to suggest the 
> unnamed graph was the stuff the app believed, and the named graph were 
> named so you could choose to accept the assertion or not.
> 
> But the word "default" crept back in, and was the most used community 
> word, so it returned to the spec.

Yes, I noticed that the URL of section 8.2.1 Specifying the default
Graph is http://www.w3.org/TR/rdf-sparql-query/#unnamedGraph :)

>> In general, a *default value* is the value to use for a parameter when
>> no value is explicitly specified.
>>
>> In the case of SPARQL, this is the value corresponding to the GRAPH
>> keyword when this keyword is not used. E.g.
>>
>>    SELECT * WHERE {
>>      :pa foaf:knows ?s .            // a triple from the default graph
>>      GRAPH ?s { ?s foaf:name ?n }   // a triple from a named graph
>>    }
>>
>> But an equivalent query could be written
>>
>>    SELECT * WHERE {
>>      GRAPH :pa { :pa foaf:knows ?s }
>>      GRAPH ?s { ?s foaf:name ?n }
>>    }
> 
> Not quite equivalent : GRAPH ?var ranges over all the URIs of the (uri, 
> graph) pairs, but not the default graph.

Noted...

>> provided that I knew that the default graph of my SPARQL engine is :pa .
>>
>> A such, I consider the default graph to be a *property of the SPARQL
>> engine* used to query the data, rather than a property of the data itself.
> 
> I could accept saying it is a property of the SPARQL service.  From the 
> client POV, engine vs data is not very relevant.  It can only use a 
> service and a service offers the combination of the two.

That is if you limit the notion of SPARQL service to an online SPARQL
endpoint. As a programmer, I use a SPARQL library ("service"), but I
have access to the data otherwise...

>> The fact that the SPARQL rec had to define all together the data
>> structure and the querying process can explain that they ended up with
>> the dataset proposal as it is.
>  >
>> I agree with Richard that we should integrate a proposal that has
>> already been widely implemented and tested, rather than reinventing the
>> wheel. However, keeping default graphs looks like keeping the bath water
>> with the baby...
>>
>> I would prefer, in a nutshell, if the proposal was to :
>>
>> * define an RDF DATASET as a set of named graphs (uri, graph) -- i.e.
>> remove the default graph;
>> * explain that a SPARQL DATASET, used by a particular SPARQL engine, is
>> an RDF DATASET where one of the named graphs is also considered the
>> default graph in order to allow for shorter queries.
> 
> A potentially useful distinction (not the specific words).  But I would 
> want the multi-graph syntax to include the default graph.

I could probably live with that. Anyway, if I want to load a (plain)
turtle file in my datastore, I have to figure out under which name I
will store it...

>> I know that SPARQL does not require that the default graph is *also*
>> present as a named graph (though it does not forbid it), so the
>> statement above is slightly more constraining than what SPARQL specifies.
>>
>> So here are a few questions to SPARQL implementers: is it more frequent
>> that the default graph also has a URI, or that it doesn't? Would it be
>> hard to ensure that it has one? Would that break something in existing
>> applications?
> 
> Most frequent : it has no name.  The most frequent case is querying one 
> graph, nothing else in the dataset.

I you loaded that graph from a URL, it kind of has a name after all, no?
I you created it from scratch, it may be a little more tedious...

  pa


>  Andy
> 
>>
>>    pa
>>
>>
>> PS: if I didn't make myself clear about the default graph being a
>> property of the engine rather than the data, please consider the
>> following thought experiment:
>>
>> Imagine a world where SPARQL would have defined, as part of a dataset,
>> the notion of *default resource*, so that I could write
>>
>>    SELECT ?friend WHERE {
>>      foaf:knows ?friend
>>    }
>>
>> Would we feel compelled to include the default resource in RDF Concepts?
>>
>

Received on Friday, 30 September 2011 13:26:18 UTC