- From: Barry Bishop <barry.bishop@ontotext.com>
- Date: Wed, 08 Aug 2012 12:16:34 +0200
- 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, e.g. 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. SELECT * FROM DEFAULT 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. SELECT * FROM DEFAULT 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. barry
Received on Wednesday, 8 August 2012 10:17:04 UTC