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

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.

> 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.

> 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.

> 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 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.

 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 10:32:15 UTC