Editorial replies to: comments on SPARQL Query Language for RDF

To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: public-rdf-dawg-comments@w3.org
Bcc: eric+sent@homer.w3.org
Subject: Editorial replies to: comments on SPARQL Query Language for RDF
In-Reply-To: <20070522.140813.75957604.pfps@research.bell-labs.com>

Peter, thank you for your comments. This reply includes editorial
proposals to address comments 2, 4 - 6 and 7. Choices of language
expressivity and other non-editorial comments will be addressed in
a later reply.

* Peter F. Patel-Schneider <pfps@research.bell-labs.com> [2007-05-22 14:08-0400]
> 
> 	Comments on SPARQL Query Language for RDF
> 	W3C Working Draft 26 March 2007
> 
> Well, the document has certainly changed since the last time I reviewed
> it, so there is little point of going over my comments from before.
> 
> This is true EXCEPT for one thing.  Many of my comments from before
> complained about lack of rigour in the document.  Unfortunately, I have
> noticed a continued lack of rigour in many of the basic notions and
> definitions underlying SPARQL.
> 
> Because of problems described in 8/ below, I do not believe that the
> document is adequate to progress to the next stage of the W3C process,
> even without my fundamental disagreement with the treatment of the
> meaning of RDF graphs in SPARQL (3/ and 9/ below).
> 
> 
> [Note that this is not a complete review of the document.  I have only
> looked at some of the informative material and enough of the formal
> definitions to see that I cannot progress further without some more
> information.]
> 
> 
> 1/ A question on the basic notion of RDF.

non-editorial -- see next reply


> 2/ What is a sequence?  What exactly are the results of a SPARQL query?
> 
> I have always thought that a sequence was inherently ordered?  How then
> can a the "result of a query [be] a solution sequence" as well as a
> "result set" (Section 2.2).
> 
> This is particularly glaring at the beginning of Section 9.

This specification uses the phrase "result set" in line with its
common use to mean a table of results from a query. This phrase is
perhaps unfortunate in that this result set need not be a mathematical
set, but the usage is common. The beginning of Section 9 accurately
specifies the intent of the WG. Solutions are initially an unordered
collection (multiset) produced by graph matching. This collection may
be put into a total order to be delivered sequentially in the solution
sequence. The spec does not specify or constrain this ordering
process, except to require that if the query contains ORDER BY
modifiers, then the final ordering must conform to the ordering
constraints they describe. The phrase "result set" may be used to
refer to either or both of the unordered multiset and the final
totally ordered solution sequence.


> 3/ Matching literals

non-editorial -- see next reply


> 4/ Labeled blank nodes
> 
> What is a labeled blank node (Section 2.4)?  Is it just a blank node, or
> is it something else?

RDF/XML and Turtle both have ways of implying a blank node without
labeling them. Labeled blank nodes were added to RDF in the second
edition and have been in Turtle/N3 since N-triples.

I propose this introduction to 2.4 (in place of "Query results can
contain labeled blank nodes."):
  [[
  Query results can contain blank nodes. Blank nodes in the example
  result (sets|sequences) in this document are written in the form
  "_:" followed by a blank node label.
  ]]


> 5/ Syntactic shorthand and other short forms
> 
> Are all the syntactic short forms simply sugar for their long forms, or
> is there different relationships between 1 and "1"^^xsd:integer (Section
> 4.1.2) and the short forms in Section 4.2.  There are multiple wordings
> for expressing the short forms, including "the same as" (Section 4.1.2),
> "is equivalent to" (Section 4.1.4), and "syntactic sugar" (Section
> 4.2.3). 

Yes, the short forms are all syntactic sugar for the long forms.

Hmm, put this text after the grammar at the bottom of the section:

I propose:
  [[
  Tokens matching the productions INTEGER, DECIMAL, DOUBLE and
  BooleanLiteral are exactly (is that needed?) equivalent to a typed
  literal with the lexical value of the token and the corresponding
  datatype (xsd:integer, xsd:decimal, xsd:double, xsd:boolean).
  ]]
 

> 6/ Status of Section 4
> 
> Section 4 (SPARQL Syntax) is not labeled as informative.  However, it
> does not exhaustively cover the grammar of SPARQL.  For example,
> NumericLiteral is defined but not used in Section 4.

Many productions in the grammar are best explained simply by being in
the grammar, e.g.

  [1] Query    ::= Prologue ( SelectQuery
                                                       | ConstructQuery
                                                       | DescribeQuery
                                                       | AskQuery )
  [2] Prologue ::= BaseDecl? PrefixDecl*

while some have explanatory text, e.g.

  The BASE keyword defines the Base IRI used to resolve relative IRIs...

explains the use of the production

  [3] BaseDecl ::= 'BASE' IRI_REF

Missing points of specificity can be treated as bugs and fixed with
text that can be added during CR.


> 7/ union
> 
> Why is union often written out (e.g., Section 1.2.14)?

The WG wishes to make the spec accessible to the widest audience.
Support for symbols is not present in some common font families
(e.g. Arial, rather than Arial Unicode).  The realities of common
browser font support leave us using English text where a symbol would
be nicer.


> 8/ Basic Definition of SPARQL

non-editorial -- see next reply


> 9/ A Fundamental Disagreement on SPARQL

non-editorial -- see next reply


> 
> Peter F. Patel-Schneider
> Bell Labs Research
> 
> 
> 
> 
> From: "Eric Prud'hommeaux" <eric@w3.org>
> Subject: Re: comments on Section 1 and Section 2 of SPARQL Query Language for RDF
> Date: Thu, 17 May 2007 17:43:34 -0700
> 
> > The Data Access Working Group is ready to bring SPARQL Query to
> > Candidate Recommendation. The objections posted by Peter F.
> > Patel-Schneider pertain to parts of the language that have changed
> > since the last CR transition. We hope PFPS will agree to the language
> > changes, withdraw his objection, and help us with editorial updates
> > during the Candidate Recommendation phase.
> > 
> > Dear Peter,
> > 
> > It has been 15 months since your comments, and we have reorganized the
> > document substantially, hopefully in ways that address your comments.
> > (Please see section 12 to see the aggregated definitions and note that
> > section 2 is now informative.) I have responded to many of your
> > comments with "[gone]". Others are marked with "[definitions
> > replaced]". These annotations are sprinkled throught this reply with
> > the goal of responding to each comment.
> > 
> > I have drafted text to address your editorial comments and will
> > propose it to the working group after the transition to CR. None of
> > these changes affect the semantics of the query language as understood
> > by the working group.
> > 
> > There have been some changes to the entailment regime in the past
> > year. Your technical comments (both numbered C2.39) should be
> > addressed by the new semantics. If you wish to persue either the
> > editorial or technical comments, we should split out the thread as
> > the distinction is important to the W3C publication process.
> 
> 

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.