W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

Re: SPARQL / Language spec ready for review

From: Simon Raboczi <raboczi@tucanatech.com>
Date: Sat, 9 Oct 2004 01:09:08 +1000
Message-Id: <00F81155-193C-11D9-9647-000A95C5686E@tucanatech.com>
To: public-rdf-dawg@w3.org


On 02/10/2004, at 2:28, Seaborne, Andy wrote:

> The SPARQL language doc is ready for review in preparation for the 
> telcon next Tuesday.  Version v1.73 (or later) of:
>
>     http://www.w3.org/2001/sw/DataAccess/rq23/

These are my comments on revision 1.97.  I'm only up to section 2.2 so 
far, so I have to apologize that it's going to be later coming in than 
I estimated.  However, all my comments are on very minor issues.  I 
have yet to encounter an issue that would disincline me to endorse the 
document for publication.

===

[[ 1.97 -- Introduction
SPARQL is a query language for accessing such RDF graphs.  It provides 
facilities to:
  * select information
  * extract RDF subgraphs
  * construct new RDF graphs based on information from the target of the 
query.
]]

"Select information" seems a trifle vague.

[[ 1.97 -- 2 Making Simple Queries
Patterns are descriptions of graphs with named variables in place of 
some of the graph labels or relationships; the simplest graph patterns 
are single triple patterns.  The graph labels are values as defined in 
[RDF Core concepts] and are URIs, plain literals and typed literals.  
Patterns can be combined using various operators into more complicated 
patterns.
]]

I think it'd be more consistent to call these "graph patterns" rather 
than "patterns".

This is my attempt to kill two birds with one stone, by pushing the 
definition of /graph label/ into 1 Introduction:

[[ suggestion -- 1 Introduction
The subject, object and relationship components of graph statements may 
be labeled.  The /graph labels/ are values as defined in [RDF Core 
concepts] and are URIs, plain literals or typed literals.

SPARQL is a query language for accessing such RDF graphs.  It provides 
facilities to:
  * select labeled components from a target graph
  * extract RDF subgraphs
  * construct new RDF graphs based on information from the target of the 
query.
]]

[[ suggestion -- 2 Making Simple Queries
/Graph patterns/ are descriptions of graphs with named variables in 
place of some of the graph labels.  The simplest graph patterns are 
/triple patterns/ describing a single statement.  More complicated 
graph patterns are formed using various operators to combine triple 
patterns.
]]

I use the term "statement" above because it was defined in 1 
Introduction, whereas "triple" hasn't been defined.

===

2 Making Simple Queries

The <div style="clear:both;"></div> appearing after the first set of 
example diagrams (triple1, triple2, triplePattern1) doesn't have the 
intended effect under either Safari 1.2.3 or Mozilla Firebird 0.7.  The 
first of the three diagrams is pushed up by the text "with result:".

The resources <alice@work.example> and <robt@home.example> aren't valid 
URI references.  They should have a scheme part, presumably mailto:.

The labeling of blank nodes with _:1 and _:2 in both the triple 
diagrams and  the "who" column of the result gives the impression that 
the blank nodes have labels.  People desperately want to believe this, 
but it's not true and I'm uncomfortable about ever giving anyone an 
excuse to think so, doubly so in a W3C-sanctioned document.  Removing 
the _:1 and _:2 labels from the triple diagrams and leaving them in the 
result set would make me happier.  I prefer "harder to understand" over 
"easy to misunderstand".

I would prefer the diagram "query1" to be called "graphPattern1".

It would be helpful to make some sort of explanation of the tabular 
result format the first time it occurs.  Something along the lines of 
"there is a column for every variable occurring in the graph pattern, a 
row for each solution; a graph label appearing in a column (variable) 
and row (solution) is the value bound to that variable in that 
solution".

===

2.1 Writing a Simple Query

The data for the first example query should be specified to be in 
N-Triples format.  (It wouldn't hurt to similarly label the query as 
being actual SPARQL.)

===

[[ 1.93 -- 2.1 Writing a Simple Query
... the '?' does not form part of the variables name.
]]

"variables" should be "variable's"

===

[[ 1.93 -- 2.1 Writing a Simple Query
The terms quoted by "<>" are....
...also possible to write floating point doubles directly.
]]

I'd be inclined to pare this back to the absolute minimum to explain 
the preceding example, rather than trying to be a synopsis of the next 
several following paragraphs.

[[ suggestion -- 2.1 Writing a Simple Query
<http://example.org/book/book1> and 
<http://purl.org/dc/elements/1.1/title> are RDF URI references.  
"SPARQL Tutorial" is a plain literal.  ?title is a named variable.
]]

I'd then add a sentence about the format of URI references to the 
beginning of the paragraph about abbreviating them as QNames, and a 
paragraph describing the format of plain literals just before the one 
about typed literals.

[[ suggestion -- 2.1 Writing a Simple Query
URI References are quoted within angled brackets in the same manner as 
in N-Triples.  Because URIRefs can become long, SPARQL provides an 
abbreviation mechanism....
]]

[[ suggestion -- 2.1 Writing a Simple Query
Plain literals are quoted within double quotes (") in the manner of 
N-Triples, using a backslash (\) to escape quotation marks and certain 
other characters.  As in N-Triples, plain literals may bear an optional 
language tag suffix introduced with '@'.

RDF has typed literals.  Such literals are written using "^^"....
]]

===

[[ 1.93 -- 2.1 Writing a Simple Query
PRFEIX  : <http://example.org/book/>
]]

"PRFEIX" should be "PREFIX"

===

[[ 1.93 -- 2.1 Writing a Simple Query
Prefixes are syntactic...
... This query is equivalent to the previous one and will therefor have 
the same results:

PREFIX  dcore:  <http://purl.org/dc/elements/1.1/>
PRFEIX xsd:       <http://www.w3.org/2001/XMLSchema#>
]]

"therefor" should be "therefore"
"PRFEIX" should be "PREFIX"

===

(Continue with 2.2 and further tomorrow.)
Received on Friday, 8 October 2004 15:09:48 GMT

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