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

Re: SPARQL Protocol for RDF

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 06 Jun 2005 12:47:47 +0100
Message-ID: <42A437E3.7060301@hp.com>
To: kendall@monkeyfist.com
CC: Patrick Stickler <patrick.stickler@nokia.com>, public-rdf-dawg-comments@w3.org



Kendall Clark wrote:
> On Thu, Jun 02, 2005 at 10:12:17AM +0300, Patrick Stickler wrote:
> 
> 
>>Great work!
> 
> 
> Thanks.
> 
> 
>>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.

The term "default graph" has been adopted in the query language as well.  The WG 
used the term "background graph" for a while but everyone talked about the 
"default graph" so that term seems to have more usefulness.

The query language spec (editors' draft) uses "default".

	Andy


> 
> 
>>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 Monday, 6 June 2005 11:48:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:48 GMT