- From: Simon Raboczi <raboczi@tucanatech.com>
- Date: Sat, 9 Oct 2004 01:09:08 +1000
- 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 UTC