Comments on SPARQL draft (pt. 1)

Looking through the 2005-03-17 editor's draft, the doc has *growed* so
I've only done the query stuff here, I'll look at Result Forms etc
later.

Overall the doc's really nice, it works both as a spec and a tutorial
without flab. I haven't been following the list, so apologies where
things have been explained/worked through in discussions I've missed.
I've only a couple of coarse grained comments on the language itself,
so I'll get them out of the way before editorial bits/minor language
points.

*** Language features ***
INSERT
I'm sure this has been discussed at length, but I can't ignore it -
where's the INSERT? Ok, I can see there may be the argument that it's
not really a query, and there would be be implementation issues. But
aside from the basic utility, there will be bound to be expectations
of people coming to SPARQL from SQL, and the absence of something so
fundamental is likely to attract criticism. Surely all that would be
needed is INSERT {graph pattern} and it's done..? (I'd also expect
this to be reflected in the Protocol, perhaps with PostGraph/PutGraph
constructs).

OPTIONAL
The doc made me chuckle - soon after the material on OPTIONAL there's
an editorial comment that there was an objection to UNION on the
grounds that it would complicate implementation and discourage
adoption. If UNION will discourage adoption then OPTIONAL will have
people emigrating to Mars. I don't know whether it's just my addled
neurones, or the way it's presented in the doc, or in the language
design (I suspect the latter), but I found this construct incredibly
hard to comprehend. In case I still haven't understood it properly, I
won't go further than to ask - is this functionality particularly
useful? If so, can't it be done in a simpler fashion?

*** Editorial/minor points ***
There seems to be a little inconsistency in the description early on
when in comes to URIs -
[[[
2.1
Query Term Syntax
The terms delimited by "<>" are URI relative references
...
The term "URI" in this document should be read as "absolute URI".]]]

also in the same section:
[[[Single quotes ('')  are also allowed. ]]]

I'm not certain, but (as a sub-delim) couldn't the single quote appear
within a URI?

[[[
Turtle allows URIs to be abbreviated with prefixes:
]]]

Moving on -
[[
2.2 Graph Patterns
Definition: RDF Term

An RDF Term is anything that can occur in the RDF data model.
]]
"anything" seems vague

[[
An RDF triple contains three components:

    * the subject, which is an RDF URI reference or a blank node
]] 
I think this needs integrating better with the general description in
relation to URIs and the comment re. literal subjects

[[
2.3 Graph Pattern Matching
...
Definition: Restriction
]]
I found this particular definition confusing, especially as
"Restriction" doesn't seem to be used in the section that follows.

[[
2.4 Examples of Graph Patterns
... tripe patterns ...
]]
juvenile-amusing typo

[[
2.7 Other Syntactic Forms
SPARQL uses a "Turtle-like" syntax for writing basic graph patterns. 
]]
I think an explanation of how the syntax differs from Turtle is needed

[[
Blank Nodes
]]
The text layout with examples mid-sentence is a little confusing.

[[
3.1 Matching RDF Literals
...
Matching Arbitrary Datatypes
...note that the query processor does not have to have any
understanding of the values in the space of the datatype.
]]
Huh?

[[
3.2 Constraining Values
...
Note that a constraint can be considered to be a triple with a special
predicate.
]]
If it's worth noting, it's worth explaining.

[[
4 Combining Patterns
...
A Basic Graph Patterns is, 
]]
typo

[[
5.5
5.5 Nested Optional Blocks
...
Query:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?foafName ?gname ?fname
]]
Shouldn't the SELECT clause include ?mbox ?

(maybe not - I've not grokked OPTIONAL)

[[
6.1 Joining Patterns with UNION
]]
The layout of the examples in this section,with multiple statements on
one line is harder to read.

[[
7 RDF Dataset
]]
This section would be really confusing to anyone that hadn't
previously encountered named graphs.

[[
...
A query processor is not required to support named graphs.
...
8 Querying the Dataset
]]
It's not clear what the expectations are - maybe a separate section is
needed to be explicit about what a query processor SHOULD support.

[[
8.1 Accessing Graph Labels
...
It is not necessary to use the GRAPH clause to create the data graph
for a collection of graphs. The query environment may provide the RDF
dataset to be queried.
]]
How?

[[
8.3 Restricting via Query Pattern
]]
3 typos in the first 2 paragraphs, 1 in the last - someone was in a hurry ;-)

Language point: In the same section, I found the syntax
[[ GRAPH data:bobFoaf {... ]]
confusing, it looks like that's a property. I don't know, maybe it
would be better to insist that graph names be written in full..?

[[
8.4 GRAPH and a background graph
...has found read in...
...a aggregator...
]]
typos, and the title doesn't seem right somehow

[[
8.5 Definition for GRAPH
Definition: DatatSet Graph Pattern
...
]]
could this be clearer?

[[
9 Query Execution and Ordering
...
]]
As noted, this section does need filling out. But -

Language point: is there/should there be any way of explicitly
overriding default execution order?
-- 

http://dannyayers.com

Received on Saturday, 19 March 2005 10:58:57 UTC