- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 06 Jun 2005 12:47:47 +0100
- 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 UTC