- From: Robert Scanlon <rscanlon@revelytix.com>
- Date: Tue, 15 Mar 2011 17:20:18 -0500
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: Richard Cyganiak <richard@cyganiak.de>, public-rdb2rdf-wg@w3.org
- Message-ID: <AANLkTimqWcfj2vfgcoTfT09LS7AEw3jKEP1VccEyx4td@mail.gmail.com>
Hi Eric, Maybe I'm misinterpreting your 'desiderata chain' below, but I don't think I'd agree that "SPARQL doesn't say whether the first FROM supplements or replaces the default graph.". The spec<http://www.w3.org/TR/sparql11-query/#rdfDataset>clearly states "A SPARQL query may specify the dataset to be used for matching by using the FROM clause and the FROM NAMED clause to describe the RDF dataset. If a query provides such a dataset description, then it is *used in place of* any dataset that the query service would use if no dataset description is provided in a query. " My apologies if I'm reading something out of context. Bob Scanlon Revelytix On Tue, Mar 15, 2011 at 4:49 PM, Eric Prud'hommeaux <eric@w3.org> wrote: > We talked for a while and settled on "default". Desiderata chain: > > SPARQL doesn't say whether the first FROM supplements or replaces > the default graph. Any protocol which addresses this is independent > of (has broader applicability than) RDB2RDF. Any such protocol will > be phrased in terms of the "default graph" and not in terms of the > "unnamed graph". If R2RML emits an "unnamed graph", it won't have a > defined semantics in SPARQL (know one will know how to query the > "unnamed graph"). If we use "unnamed graph", we'll have to provide > the linkage to "default graph". That recipe, plus the identifier > "unnamed graph" won't give us any more versatility than we already > have. > > Apparently I was mistaken about the choice of replacing or > supplementing, which means that I know of several non-conferment > implementations. I don't think that this changes the resolution, > do you Seema or Souri? > > > * Richard Cyganiak <richard@cyganiak.de> [2011-03-15 21:18+0000] > > I'd like to re-iterate my position from this call that we should define > the output of an R2RML mapping as an RDF Dataset in the SPARQL sense, as it > already says in the introduction, and consistently use the SPARQL's > terminology. > > > > This would imply using the terms “named graph” and “default graph”. The > term “unnamed graph” would be removed from the spec. > > > > The objection raised in the call was that the default graph used in a > SPARQL query can actually be constructed on the fly, on a query-by-query > basis, by using the FROM keyword or SPARQL protocol parameters. > > > > This is a valid observation. But I argue that this doesn't conflict at > all with the use of the RDF Dataset concept and the term “default graph”. > > > > To quote from the SPARQL spec [1]: > > > > > A SPARQL query may specify the dataset to be used for matching by using > the FROM clause and the FROM NAMED clause to describe the RDF dataset. If a > query provides such a dataset description, then it is used in place of any > dataset that the query service would use if no dataset description is > provided in a query. > > > > This makes clear that if FROM/FROM NAMED are used, then one queries a > *different* dataset from the one that the query service offers *by default* > if FROM/FROM NAMED were not used. > > > > I'm proposing that we think of the R2RML-generated dataset as the dataset > which a query service would use by default in absence of a specific dataset > description. This doesn't preclude the possibility of overriding the default > graph or any other graph with FROM/FROM NAMED and the SPARQL protocol. > > > > This would be a simple change in terms of spec text (s/unnamed > graph/default graph/ and check the early sections for anyplace that should > say “RDF dataset” instead of “RDF graph”). So I propose that we do this > before the WD release. > > > > If there are no objections (on- or off-list), I'll go ahead and do this. > > > > Best, > > Richard > > > > [1] http://www.w3.org/TR/rdf-sparql-query/#unnamedGraph > > -- > -ericP > >
Received on Tuesday, 15 March 2011 22:20:54 UTC