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

Re: SPARQL / Language spec ready for review

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 08 Oct 2004 17:37:17 +0100
Message-ID: <4166C23D.1020009@hp.com>
To: Simon Raboczi <raboczi@tucanatech.com>
CC: public-rdf-dawg@w3.org

Simon,

Thanks for the comments so far.  Changes and non-changes described inline.

I'll carry over these comments when you send further reviewers feedback.

	Andy


Simon Raboczi wrote:
> 
> 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.

No change for now.  See below.

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

v1.103:
Done.

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

Graph labels considered harmful : see :

http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0054.html

This section has been updated based on Pat's comments.

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

No change.
Triple is from RDF Concepts.
Use of statement has been eliminated from the document.

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

Can't change at the moment : I don't have the technology to change the images.

For now, better to have the text and images agree even if both wrong, rather 
than text right and images different.

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

I'll leave this to Eric.

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

No change for publication.
I wanted to get into the example without lots of defining and padding text. 
There is some explanation after the example.

> 
> ===
> 
> [[ 1.93 -- 2.1 Writing a Simple Query
> ... the '?' does not form part of the variables name.
> ]]
> 
> "variables" should be "variable's"

v 1.103:
Change made: "variables'" as the first use in the sentence is "Variables".

I see a panda :-)

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

We have duplication between intro 2. and 2.1.  Not enough time to fix before 
first WD publication.

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

No change. <> for URIs is mentioned in RFC 2396 so it is much wider than N-triples.

> 
> [[ 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 "^^"....
> ]]

There is (or will be) a reference to the formats mentioned.  Where they do the 
"usual" thing, I'd like to keep this doc simple and not explicitly mention it.

Also, "Plain literals are quoted within double quotes" needs to apply to typed 
and tagged literals as well.

> 
> ===
> 
> [[ 1.93 -- 2.1 Writing a Simple Query
> PRFEIX  : <http://example.org/book/>
> ]]
> 
> "PRFEIX" should be "PREFIX"

v1.103:
Done *2

> 
> ===
> 
> [[ 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"

~v1.10: changed that text to:
"will give the same results when applied to the same graph." to avoid "same as" 
discussions.



> "PRFEIX" should be "PREFIX"

v1.103:
Done

> 
> ===
> 
> (Continue with 2.2 and further tomorrow.)
> 
> 
Received on Friday, 8 October 2004 16:37:41 GMT

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