- 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