- 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