W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: Review of Query 1.1

From: Axel Polleres <axel.polleres@deri.org>
Date: Sun, 3 Jan 2010 22:07:52 +0000
Cc: Andy Seaborne <andy.seaborne@hp.com>, Steve Harris <steve.harris@garlik.com>, Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Message-Id: <E9AEB83D-E909-4F5B-A7BD-F5020E61C2CB@deri.org>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Happy new year alltogether

Find attached my review for Query 1.1. Did it offline, so hope this is still the latest version
I agree with Birte's assessment that the document looks very good. Thanks to the editors!
Note that I made some suggestions for changes... which you may want to at least address 
with a todo/Editor's note.

As for (also raised by Birte) the concern whether "todo"/"Editor's note's" or "SPARQL WG note" we may think of 
unifying these stylistically in future drafts (not critical in this version, from my point of view.)


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):
======================================
			<div2 id="CreatingValuesWithExpressions">
				<head>Creating Values with Expressions</head>
<p>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 <code>SELECT</code> clause.
<p class="todo">@@the use of fn:concat in the example is still to be decided.</p>
</p>
<div class="exampleGroup">
  Data:
  <pre class="data">@prefix foaf:  &lt;http://xmlns.com/foaf/0.1/&gt; .

_:a  foaf:givenName   &quot;John&quot; .
_:a  foaf:surname  &quot;Doe&quot; .
</pre>
  <div class="queryGroup">
    Query:
    <pre class="query">PREFIX foaf:   &lt;http://xmlns.com/foaf/0.1/&gt;
SELECT fn:concat(?G, " ", ?S) AS ?name
WHERE  { ?P foaf:givenName ?G ; foaf:surname ?S }
</pre>
    <div class="result">
      <table class="resultTable" id="table59">
        <tr>
          <th>name</th>
        </tr>
        <tr>
          <td>&quot;John Doe&quot;</td>
        </tr>
      </table>
    </div>
  </div>
======================================

* 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):

======================================
<p><a href="#GraphPattern">Section 5</a> 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, <a href="#optionals">Section 6</a> 
introduces the ability to make portions of a query optional; <a href="#alternatives">Section 7</a> 
introduces the ability to express the disjunction of alternative graph 
patterns; <a href="#negation">Section 8</a> shows how to define a pattern in terms of the absence of another pattern; <a href="#aggregateFunctions">Section 9</a> shows how to aggregate values; <a href="#subqueries">Section 10</a> introduces the ability to nest queries; and <a href="#rdfDataset">Section 11</a> 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.</p>
 
<p><a href="#solutionModifiers">Section 12</a> defines the constructs that affect the solutions of a query by 
ordering, slicing, projecting, limiting, and removing duplicates from a 
sequence of solutions.</p>

<p><a href="#QueryForms">Section 13</a> defines the four types of SPARQL queries that produce results 
in different forms.</p>

<p><a href="#tests">Section 14</a> 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.</p>

<p><a href="#sparqlDefinition">Section 15</a> is a formal definition of the evaluation of SPARQL graph 
patterns and solution modifiers.</p>

<p><a href="#grammar">Section 16</a> 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:

=====================
 <div3 id="aggregateAlgebra">
  <head>Algebra Operators</head>
    <p>The operators that make up aggregates consist of three functions: Key, Partition, and Aggregation.</p>

  <p>Write &#956;(<i>Expr</i>) for the application of the solution mapping &#956; to all the variables appearing in the expression <i>Expr</i>.</p> 
<p>@@ref  definition application of a mapping to an expression</p>

    <p>Key is a function that projects aggregated solution values from a solution:</p>
     <div class="defn">
    <p><b>Definition: key</b></p>

    <p>Single valued function: returns a solution projected down to named variables only:</p>

    <p>key(GroupClause, &#956;) = eval(&#956;(GroupClause))</p>

    <p>and the set of all keys:</p>

    <p>key(GroupClause, &#937;) = { k | &#956; in &#937;, k=key(GroupClause,&#956;) }</p></div>

    <p>Partition is a function which groups solutions according to the <code>GROUP BY</code> expression:</p>

    <div class="defn">
      <p><b>Definition: Partition</b></p>

      <p>The partition of the multiset &#937; is:</p>

      <p>Partition(GroupClause, &#937;) = { (k,&mu;) | &mu; in &#937;, k=key(GroupClause, &mu;) }</p>
    </div>
=========================

* 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 : <http://people.example/>
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)"?
Received on Sunday, 3 January 2010 22:08:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT