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

Re: Review of Query 1.1

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Mon, 04 Jan 2010 16:03:11 +0000
Message-ID: <4B42113F.5050709@talis.com>
To: Axel Polleres <axel.polleres@deri.org>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>, Andy Seaborne <andy.seaborne@hp.com>, Steve Harris <steve.harris@garlik.com>, Birte Glimm <birte.glimm@comlab.ox.ac.uk>


On 03/01/2010 10:07 PM, Axel Polleres wrote:
> 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.)

It was a WG decision to include the box.

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

The new features lists in the status links to each new feature.

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

Done.

 >
 > * Status section
 >
 > "The structure of this document will change to full integrate [...]"
 > ->
 > "The structure of this document will change to fully integrate [...]"

Done.

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

Added a list.

I have suggested a separate (short) document that is a guide to the 
other documents.

I added a "SPARQL 1.1 Conformance Tests" (title pending) because we have 
to produce something to get to REC.

Should I include the SPARQL library doc?

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

Good idea to have something

Added something for now.

But we need to align with the library document.

Please, please, please use valid markup.  This is missing end marker.


 > ======================================
 >
 > * the document outline should have a @@todo.

@@ added.

 >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 numbers may well change as the material gets integrated.  It is 
too early to write this section.

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

Agreed.

Please note the formalization of this feature is mime as best I could 
divine from the email trail.

 >
 >
 > * Section 9.1

(Steve will address comments on sec 9 and 10)


 > * Section 15:
 >   Apologies if I overlooked something, but why is the section marked 
"(Informative)"?

No idea - it's not in the previous REC.  In fact, it should be Normative 
(which is the default).  Removed.


	Andy
Received on Monday, 4 January 2010 16:03:43 GMT

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