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

Data:

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

_:a  foaf:givenName   "John" .
_:a  foaf:surname  "Doe" .

Query:

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"

====================================== * the document outline should have a @@todo. Actually, I would reorder the subqueries and aggregates sections, but we could decide on that later. Here is a snippet to replace the current section outline (although this might anyways still change in future versions, I think it's good to inform the reader): ======================================

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: ===================== Algebra Operators

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 GROUP BY expression:

Definition: Partition

The partition of the multiset Ω is:

Partition(GroupClause, Ω) = { (k,μ) | μ in Ω, k=key(GroupClause, μ) }

========================= * Definition:Count/Definition:Sum (the following is non-critical for now) "|M|" looks on my browser a bit like "IMI" ... maybe spaces help? Similar for "|S|" which looks like "ISI" * Section 10: As mentioned earlier, there are IMO problems with the example in this section, cf. http://www.w3.org/mid/678A08B1-AE63-40A7-B8C9-84EC67A3D9A2@deri.org (second part of that mail). I suggest to change the example to: PREFIX : SELECT ?y ?name WHERE { :alice :knows ?y . { SELECT ?y MIN(?name) WHERE { ?y :name ?name } GROUP BY ?name } } Editorial: "In general, GroupGraphPatternSub is evaluated and then the resulting multiset is projected with the Project funstion," --> "In general, GroupGraphPatternSub is evaluated and then the resulting multiset is projected with the Project function" "The reuslting sequence is converted back to a multiset with ToMultiset." -> "The resulting sequence is converted back to a multiset with ToMultiset." * Section 15: Apologies if I overlooked something, but why is the section marked "(Informative)"?