Re: [Fwd: Some rq25 comments]

Seaborne, Andy wrote:
> 
> 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"?

"Result sets" is a common term and "result collections" is a bit long so, on 
balance, I prefer the term "result set".

(and of course, may be each row has a hidden index, making it a set)

> 
> §1.2.4
> 
> First definition of IRI (not IRI reference?)

RFC 3986 section 4.1

URI-reference = URI / relative-ref

so it's only the relative reference that added and for SPARQL, there are no 
relative references after parsing.

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

which is covered by the "RDF URI reference" - RDF-code invented that term to 
include the fragment, be absolute and anticipate IRIs.

> 
> §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?

"quey pattern" (as in the pattern of the query) used to be something that the 
definitions covered but the formal concept is no longer needed.

I've changed the first occurrence to "graph pattern of the query"


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

The current form is correct - it's the whole result set that includes all the 
possible ways that the variables can be bound to match - one solution is on 
possible way.

reworded:
"""
Each solution gives one way in which the selected variables can be bound to 
RDF terms so that the query pattern matches the data. The result set gives all 
the possible solutions.
"""

> 
> s/therefor/therefore

Fixed

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

I wanted to be clear what the data is - writing the full lexical form and 
datatype is longer and emphasises the point that integers aren't special 
except as syntactic shorthand.  2.3.2 gives the full form and says 42 is a 
SPARQL shortform (which happens also to be true in Turtle but that's not the 
point here).

> 
> §2.4
> 
> "Blank nodes labels..."
> s/nodes/node

Fixed

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

We aren't using RFC 2119 (we state what SPARQL is - the protocol then ties us 
to the correct behaviour) but "should" is more natural.  Changed

As to the unpopularness ;-) <_:abc> is superficially syntactically legal some 
systems are providing told bnodes (it's illegal because we say that IRIs must 
be legal IRIs in the grammar but don't embed the full IRI productions (which 
are scheme sensitive anyway) and it's not a legal IRI).

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

That's clearer - done.

> s/nodes ./nodes./

Done

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

Done

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

Done (and the following str)

Eric - is that a correct change to make?

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

If it's the misparsing that you're pointing out, I changed it to:
"Only plain literals with no language tag and literals which are XSD strings"

> 
> §3.1
> 
> "Restricting the Values of Number"
> Restricting Numeric Values

Changed - and in the TOC.

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

Removed in 3.2

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

Personal comment: seems a bit confusing - but maybe I'm just used to seeming 
full IRIs.  To differ from Turtle and N3 without a string reason seems a 
little unhelpful.

An alterntaive viewpoint is that the comment seems more about the restricted 
characters in a localname as much as BASE.

        PREFIX d:    <http://purl.org/dc/>
        PREFIX dc:   d:elements/1.1/
        PREFIX dcq:  d:terms/
        PREFIX dct:  d:dcmitype/

(having seen that I think it is maybe not such as good idea)

> 
> §4.1.4
> 
> "Blank nodes in query patterns..."
> s/query patterns/graph patterns/

Corrected

> -- 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?

Added links to 4.2.1 and 4.2.2

> 
> §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) }

This is an empty group with a filter - filters apply to groups these days.

[Project ?x
   [Filter ( ?x > 7 )
     [empty group]]]

The empty group, {} is specifically mentioned as having one solution of no 
variable bindings.

Another perspective is that the result set would be finite anyway - filters 
don't bind variable, they restrict bindings.  When SPARQL was declarative it 
wasn't clear but with the algebra, filters apply a boolean expression to the 
group.

c.f.
SELECT ?x WHERE { ?x math:lessThan 7 }

	Thanks for the comments,
	Andy

> 
> 
> 
>

Received on Sunday, 18 February 2007 17:56:49 UTC