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