review http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml
CVS version 01/01/2010
Change summary:
Compared to the first public working draft, this publication includes the new features of SPARQL 1.1 into the main SPARQL Query specification. In this publication, new content is gathered together for easy of review of these new features. The structure of the document will further change to full integrate the new features.
Particular, as apposed to the original SPARQL spec, sections 8-10 are new, as well as section 13 extends the SELECT query form (formerly Section 10 in the original SPARQL) spec by expressions.
Detailed Comments:
* Abstract
We may want to add in the abstract a half sentence about the new
features:
"SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports extensible value testing and constraining queries by source RDF graph."
--suggestion-->
"SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports aggregation, subqueries, creating values by complex expressions, extensible value testing, and constraining queries by source RDF graph."
* Status section
"The structure of this document will change to full integrate [...]"
->
"The structure of this document will change to fully integrate [...]"
* Introduction:
"The SPARQL query language is closely related to the following specifications:"
Suggest to add an editor's note that pointers to other related specs (updagte, entailment, service description) should be added.
* Section ordering:
SELECT expressions are as a feature a bit hidden at the moment, only appearing in the context of aggregates. I suggest to introduce a new subsection between 2.4 and 2.5called "Creating values with expressions" to introduce a simple example for value creation via expresssions in a subquery. For instance, here a suggestion for a new section 2.5 (could maybe also go into section 3, or we should actually have an own section "projectsion", not sure 100% where it fits better, but would put it in Section 2 for the moment):
======================================
SPARQL 1.1 allows to create values from complex expressions. The query below shows how to concatenate first names and last names from foaf data.
This can be achieved by using expressions in the @@the use of fn:concat in the example is still to be decided.SELECT
clause.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:givenName "John" . _:a foaf:surname "Doe" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT fn:concat(?G, " ", ?S) AS ?name WHERE { ?P foaf:givenName ?G ; foaf:surname ?S }
name |
---|
"John Doe" |
Section 5 introduces basic graph patterns and group graph patterns, the building blocks from which more complex SPARQL query patterns are constructed. Sections 6 to 11 present constructs that combine SPARQL graph patterns into larger graph patterns. In particular, Section 6 introduces the ability to make portions of a query optional; Section 7 introduces the ability to express the disjunction of alternative graph patterns; Section 8 shows how to define a pattern in terms of the absence of another pattern; Section 9 shows how to aggregate values; Section 10 introduces the ability to nest queries; and Section 11 introduces the ability to constrain portions of a query to particular source graphs. Section 11 also presents SPARQL's mechanism for defining the source graphs for a query.
Section 12 defines the constructs that affect the solutions of a query by ordering, slicing, projecting, limiting, and removing duplicates from a sequence of solutions.
Section 13 defines the four types of SPARQL queries that produce results in different forms.
Section 14 defines SPARQL's extensible value testing framework. It also presents the functions and operators that can be used to constrain the values that appear in a query's results.
Section 15 is a formal definition of the evaluation of SPARQL graph patterns and solution modifiers.
Section 16 contains the normative definition of the SP
======================================
* Section 8.2 (this is non-critical):
I am not 100% sure about the alternative MINUS proposal, but does actually still anybody advocate it? It seems we didn't get any comments on it upon FPWD. We should probably discussing about removing it. If not, what is not entirely clear to me is what happens with bags with duplicate solutions in the MINUS approach, i.e. is it intended to reduce multiplicity of solutions, etc.
* Section 9.1
"In aggregate queries and sub-queries only expressions which have been used in GROUP BY, or aggregated expressions (i.e. expressions where all variables appear inside an aggregate function)."
-->
"In aggregate queries and sub-queries only expressions which have been used in GROUP BY, or aggregated expressions (i.e. expressions where all variables appear inside an aggregate function) can be projected (@@ ref to project expressions?)."
(the following is non-critical for now)
Note even that way "which have been used in" is ambiguous, since it might be read as
that subexpressions of the actual GROUP BY or aggregate expression can be used.
E.g.
SELECT ?X
... GROUP BY ?X+?Y
* Section 9.2
key is definded for varLists only whereas Partion is defined for "GroupClause"s.
Should we add a todo that this has to be resolved?
(the following is a suggestion, non-critical for now)
I think the following change to the Definition of key may resolve this:
=====================
The operators that make up aggregates consist of three functions: Key, Partition, and Aggregation. Write μ(Expr) for the application of the solution mapping μ to all the variables appearing in the expression Expr. @@ref definition application of a mapping to an expression Key is a function that projects aggregated solution values from a solution: Definition: key Single valued function: returns a solution projected down to named variables only: key(GroupClause, μ) = eval(μ(GroupClause)) and the set of all keys: key(GroupClause, Ω) = { k | μ in Ω, k=key(GroupClause,μ) } Partition is a function which groups solutions according to the Definition: Partition The partition of the multiset Ω is: Partition(GroupClause, Ω) = { (k,μ) | μ in Ω, k=key(GroupClause, μ) }GROUP BY
expression: