Difference between revisions of "CommentResponse:BB-1"

From SPARQL Working Group
Jump to: navigation, search
(Created page with "This is in response to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Aug/0011.html Dear Barry, > The working draft does not specify how the RDF dataset is c…")
 
Line 25: Line 25:
 
  > graphs.  
 
  > graphs.  
  
Note that the combination of querying named graphs and the default graph of  
+
Note that  
an endpoints dataset is supported via GRAPH graph patterns.
+
a) querying the default graph in the datastore is the standard behavior
 +
    when no explicit FROM or FROM NAMED clauses are given.
 +
b) the combination of querying named graphs and the default graph of  
 +
    an endpoints dataset is supported via GRAPH graph patterns.
 +
see also examples below.
  
 
  > This is a problem that often confuses users of RDF data stores  
 
  > This is a problem that often confuses users of RDF data stores  
Line 57: Line 61:
 
  > FROM <http://example.com#g1>
 
  > FROM <http://example.com#g1>
 
  > WHERE { ..... }
 
  > WHERE { ..... }
 +
 
  >  
 
  >  
 
  > => dataset contains a default graph made up of the data store's default  
 
  > => dataset contains a default graph made up of the data store's default  
Line 65: Line 70:
 
  > used/queried/merged in the same way as any of it's named graphs.
 
  > used/queried/merged in the same way as any of it's named graphs.
 
   
 
   
It looks like you suggest here to construct a new dataset composed of  
+
Note that similar to the example above, you can query the default
parts of the default dataset of an endpoint plus possible external  
+
graph and named graphs within this default dataset in a data store
graphs, please confirm. This is a feature currently not foreseen in the  
+
side by side by using GRAPH graph patterns, i.e.
features addressed in this round of SPARQL. The features being worked on  
+
 
in this round of standardization have been layed out at the beginning of the  
+
  SELECT *
WG in this document: http://www.w3.org/TR/sparql-features/
+
  WHERE
 +
  {
 +
    .....                              <-- matches the default graph
 +
    GRAPH <http://ex.com#g1> { .... }  <-- matches named graph g1
 +
  }
 +
 
 +
However, it might be the case that you suggest here to construct  
 +
a *new* dataset composed of *parts* of the default dataset of  
 +
an endpoint plus possible external graphs. Such a feature currently  
 +
not foreseen in the features addressed in this round of SPARQL.  
 +
 
 +
The features being worked on in this round of standardization  
 +
have been decided in a voting process at the beginning  
 +
of the WG and are documented in the following document:  
 +
http://www.w3.org/TR/sparql-features/
  
Work items postponed to a future working group are being collected  
+
Additionally, a list of work items and features postponed  
by the group at the following page:
+
to a future working group are being collected by the group  
 +
at the following page:
  
 
  http://www.w3.org/2009/sparql/wiki/Future_Work_Items
 
  http://www.w3.org/2009/sparql/wiki/Future_Work_Items
Line 86: Line 106:
 
  http://www.w3.org/2009/sparql/wiki/Feature:CompositeDatasets
 
  http://www.w3.org/2009/sparql/wiki/Feature:CompositeDatasets
  
might capture what you have in mind and a future WG might possibly  
+
might partially capture what you have in mind and a future  
work out the details of such feature.
+
WG might possibly work out the details of such feature.
  
We'd kindly ask you to confirm by a reply to this list that this addresses your comment.
+
We'd kindly ask you to confirm by a reply to this list that  
 +
this addresses your comment.
  
 
Axel Polleres, on behalf of the SPARQL WG
 
Axel Polleres, on behalf of the SPARQL WG

Revision as of 07:29, 4 September 2012

This is in response to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Aug/0011.html

Dear Barry,

> 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

It is correct that how the concrete default dataset of a SPARQL endpoint is conctructed is left open to implementations. Since different endpoints and implementations support different behaviours in this regard, the working group does not feel that there is a unique standard behavior to be advocated.

> 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. 

Note that

a) querying the default graph in the datastore is the standard behavior 
   when no explicit FROM or FROM NAMED clauses are given.
b) the combination of querying named graphs and the default graph of 
   an endpoints dataset is supported via GRAPH graph patterns.

see also examples below.

> 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

Please note that this the standard behaviour when no FROM clause is given, i.e. this corresponds to

SELECT *
WHERE { ..... }
> 
> 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.

Note that similar to the example above, you can query the default graph and named graphs within this default dataset in a data store side by side by using GRAPH graph patterns, i.e.

 SELECT *
 WHERE
 {
   .....                              <-- matches the default graph
   GRAPH <http://ex.com#g1> { .... }  <-- matches named graph g1
 }

However, it might be the case that you suggest here to construct a *new* dataset composed of *parts* of the default dataset of an endpoint plus possible external graphs. Such a feature currently not foreseen in the features addressed in this round of SPARQL.

The features being worked on in this round of standardization have been decided in a voting process at the beginning of the WG and are documented in the following document: http://www.w3.org/TR/sparql-features/

Additionally, a list of work items and features postponed to a future working group are being collected by the group at the following page:

http://www.w3.org/2009/sparql/wiki/Future_Work_Items

which also contains the features discussed in the beginning of the WG which have not been considered for this round:

http://www.w3.org/2009/sparql/wiki/Category:Features

Among this list, the feature

http://www.w3.org/2009/sparql/wiki/Feature:CompositeDatasets

might partially capture what you have in mind and a future WG might possibly work out the details of such feature.

We'd kindly ask you to confirm by a reply to this list that this addresses your comment.

Axel Polleres, on behalf of the SPARQL WG