W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > August 2012

Querying only the default graph from the data store

From: Barry Bishop <barry.bishop@ontotext.com>
Date: Wed, 08 Aug 2012 12:16:34 +0200
Message-ID: <50223C82.3010106@ontotext.com>
To: public-rdf-dawg-comments@w3.org
The working draft does not specify how the RDF dataset is constructed 
when no FROM and FROM NAMED clauses are present in the SPARQL query.

Implementations are therefore able to construct the dataset differently, 
a. dataset default graph contains only the data store's default graph
b. dataset default graph contains the RDF merge of all graphs in the 
data store

As soon as a single FROM or FROM NAMED clause is used then the data 
store's default graph is excluded from the query's dataset.

Which means that there is no portable way to defne a SPARQL query so 
that it executes only against the default graph in the data store - or 
even against a combination of the default graph and one or more named 
graphs. This is a problem that often confuses users of RDF data stores 
and is likely to lead to implementations that provide their own specific 
means to achieve this, e.g. http://www.openrdf.org/issues/browse/SES-850

Inspired by the update language's use of the 'DEFAULT' keyword for graph 
manipulation, I suggest an extension to the query language that allows 
"FROM DEFAULT" to be used, e.g.

WHERE { ..... }

=> dataset contains a default graph made up of the data store's default 
graph only

This construct can be used with any number of FROM <uri> or FROM NAMED 
<uri> clauses, e.g.

FROM <http://example.com#g1>
WHERE { ..... }

=> dataset contains a default graph made up of the data store's default 
graph merged with the contents of the data store's g1 graph

This would be a fairly trivial change for exisiting sparql processor 
implementations, but would provide a big improvement in 
functionality/flexibility by allowing a data store's default graph to be 
used/queried/merged in the same way as any of it's named graphs.

Received on Wednesday, 8 August 2012 10:17:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:30 UTC