W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2005

Re: SPARQL Protocol for RDF

From: Kendall Clark <kendall@monkeyfist.com>
Date: Thu, 2 Jun 2005 10:09:32 -0400
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: public-rdf-dawg-comments@w3.org
Message-ID: <20050602140932.GD30693@monkeyfist.com>

On Thu, Jun 02, 2005 at 10:12:17AM +0300, Patrick Stickler wrote:

> Great work!


> A few questions/comments:
> 1. All examples explicitly specify the background graph, and while 
> that's
> of course not incorrect, it would perhaps be good if the
> first few basic examples would omit specification of a background graph 
> to
> reflect what will most likely be the most common use case, that of a
> given SPARQL portal recieving queries without any specification of a
> the background graph, and defaulting to the default background graph of 
> the
> portal itself.

A good suggestion and one that will be acted upon. :>

> 2. The parameter for specifying the background graph should follow the
> terminology used in the SPARQL spec and thus should be named
> 'background-graph-uri' and not 'default-graph-uri' as the term
> "default graph" has no definition in SPARQL.

Right, but...We talked about synching up on these, and my memory is that we
chose "default graph" rather than "background graph". I may be
misremembering or the QL editors may not have fixed those bits yet. But,
yes, these will be synched eventually.

> 3. Since the SPARQL language itself provides facilities for
> explicitly specifying which graph a given query, or components
> of a query, should be evaluated against, and the query itself can
> (and if needed, must) include FROM/FROM NAMED qualifications
> naming the relevant graphs, why is it necessary to redundantly
> specify any graph URIs in the parameters?

I'll repeat the bits I already wrote in response to Danny:

The design we've come up with allows the RDF dataset (which is composed of
zero or one default (sometimes called "background") graph and zero or more
named graphs) to be specified either in the protocol, or in the query
language, or in both. In the case where it is specified in both, but the RDF
datasets are not identical, the dataset specified in the protocol trumps the
one specified in the query.

This is spelled out in the latest draft thus:

  The RDF dataset may be specified either in a legal [SPARQL] query using
  FROM and FROM NAMED keywords; or it may be specified in the protocol
  described in this document; or it may be specified in both the query
  proper and in the protocol. In the case where both the query and the
  protocol specify an RDF dataset, but not the identical RDF dataset, the
  dataset specified in the protocol must be the RDF dataset consumed by
  SparqlQuery's query operation.
Since both you and Danny asked about this, this bit must either be vague
or just doesn't stand out enough in the draft presently. I'll think about
ways to make it more difficult to miss. :>

Let me add that the WG spent a *lot* of time talking about this, over the
course of many months, and we think we had good reasons for allowing this
flexibility in specifying the RDF dataset. There are very good reasons for
specifying it in the query language and for specifying it in the protocol,
reasons which overwhelm the simplicity argument (that is, specifying it in
one and only one place).

> If a specific graph needs to be specified, then it seems to me
> that it would be better, as in more economical and elegant, to
> use the existing machinery in the SPARQL query language itself
> to identify those graphs rather than introducing alternative,
> and potentially redundant parameters for doing so. This also
> alleviates any chance of conflicts between the query and the
> parameters, such as if they disagree about which graph is the
> background graph.

We specify what is supposed to happen if they disagree, per above.

I won't respond in this message to yr comments about the nature of the RDF
dataset or unnamed graphs. But we're still considering the underlying design
and someone will respond eventually. :>

Thanks for the comments.

Kendall Clark
Received on Thursday, 2 June 2005 14:10:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC