[Fwd: Some rq25 comments]

Thanks to Simon for a first batch of review comments.

	Andy

-------- Original Message --------
Subject: Some rq25 comments
Date: Tue, 13 Feb 2007 01:47:37 +1000
From: Simon Raboczi <raboczi@itee.uq.edu.au>

I've only started grinding my way though rq25, but I figure it'll be
more useful to deliver it in chunks as I work through it rather than
waiting until I finish it all.
If you could repost this to the list, I'd be obliged.

Comments on rq25 rev 1.12 §1-4
http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html

§1.2.3

"Result sets" aren't actually sets.  Should we rename them as
"collections"?

§1.2.4

First definition of IRI (not IRI reference?)  As well as anticipating
the IRI spec, we're also anticipating RFC3986.  Might want to
reiterate the comment from RFC3987:
       "Note that in [RFC2396] URIs did not include fragment
identifiers, but in
        [RFC3986] fragment identifiers are part of URIs."

§2.2

"The results of a query are a sequence of solutions, corresponding to
the ways in which the query pattern..."
The (result set) of a query is a sequence of solutions, corresponding
to the ways in which the query graph pattern...

-- the term "query pattern" is never actually defined, although it
starts popping up later in the document.  We should either officially
define it, or use "graph pattern".  Would "query pattern" include
both graph patterns and value constraints?

"The results enumerate..."
Each solution enumerates...

s/therefor/therefore

§2.3.2

Perhaps the abbreviations for literals like xsd:integer/float/double
would fit more naturally into §2.3, seeing as they apply to TURTLE
graphs as well as SPARQL graph patterns.

§2.4

"Blank nodes labels..."
s/nodes/node

"An application or client may not expect blank node labels in a query
to refer to a particular blank node."

Will we be adopting RFC2119 to specify the meaning of "may not"
here?  I'd be a bit more comfortable with "should not" in this
particular case.  (Actually, I'd be happiest with "must not" and
completely prohibiting people from trying to finesse the scope of
bnode labels, but I suspect that'd be too unpopular.)

"Labels are used to indicate co-occurrences of blank nodes ."
s/used to/used only to/
s/nodes ./nodes./

§3

"It is possible to restrict solutions by constraining the RDF terms
that may match a given query ."
s/query ./query./

§3.1

"Variable bindings can be restricted to strings matching a regular
expression by using the regex operator."
s/operator/function/

"Only plain literals with no language tag and XSD strings..."
s/XSD string/<code>xsd:string</code> typed literals/

§3.1

"Restricting the Values of Number"
Restricting Numeric Values

Souri's point from the 2007-02-06 teleconference is well-observed:
the . punctuation in graph patterns seems capricious.  Compare the
examples in §3.1 which elide them, and in §3.2 which include them.

§4.1.1

The grammar currently requires that BASE, if present, occurs only
once and precedes the PREFIX clauses; this isn't stated explicitly.
On the other hand, it seems like it might be useful to allow multiple
BASEs:
E.g. BASE <http://www.w3.org/>
       PREFIX rdf:  <1999/02/22-rdf-syntax-ns#>
       PREFIX rdfs: <2000/01/rdf-schema#>
       PREFIX xsd:  <2001/XMLSchema#>
       BASE <http://purl.org/dc/>
       PREFIX dc:   <elements/1.1/>
       PREFIX dcq:  <terms/>
       PREFIX dct:  <dcmitype/>

Additionally, should state what happens in the case of redundant
(possibly conflicting) PREFIX declarations.

§4.1.4

"Blank nodes in query patterns..."
s/query patterns/graph patterns/
-- see above note about §2.2 and whether "query pattern" would
include value constraints, though

"...other abbreviations for common subjects and predicates."
Perhaps a forward link to §4.2.1/4.2.2 where these abbreviations are
defined?

§4.4

"Basic graph pattern consists of zero or more triple patterns."
s/pattern/patterns

Do we really allow empty BGPs?  Do we allow a value constraint
applied to an empty BGP to yield a result set of infinite cardinality?
E.g. SELECT ?x WHERE { FILTER (?x > 7) }

Received on Monday, 12 February 2007 18:11:21 UTC