SPARQL 1.1 Query Review Part 1

Andy, Steve, all,

since I agreed to review the SPARQL Query sec, here is the first part
of my review, which covers Sec 1-17, i.e., up to the algebra section.

Best regards,

Birte

1.1, Description of Sec. 19: I suggest to link SPARQL update
to the update specification

2.5, 2nd example query: Do I not have to use a fullstop to end the
triple pattern? I could be wrong here.
 ?P foaf:givenName ?G ;
      foaf:surname ?S ***.***
   BIND(CONCAT(?G, " ", ?S) AS ?name)

4.1.1.2 There is an extra space before the fullstop in "Relative IRIs
are combined with [...] basic algorithm in Section 5.2*** ***. Section
5.2 should be section 5.2 to be consistent with the rest of the
document.

8.1 Filtering of query solutions [...] using NOT EXIST***S***

8.1.1 [...] given the values of variables in-scope
I think at this point the term in-scope has not yet been
introduced. Can we at least link that to 18.2.1 Variable Scope
(#variableScope)

8.3.3 I suggest to use in both examples ?x (curently the first query
uses ?a and the second ?x); the use of ?a somehow suggests a
relationship with :a in the data, which is not intended.

9 [...] Property paths allow for more concise expression*s* of some
SPARQL basic graph patterns [...] Variables can not be used, no space
in can not

9.1 (table)
"A sequence path of elt1, followed by elt2" is the only entry that
does not end with a fullstop
A alternative path of elt1, or elt2 <- A**n** alternative..., I would
remove the comma
A path of zero or one elt. <- A path of zero or one occurrences of
elt. (to be consistent with the rest)

9.2 "Example: Arbitrary length path match: Some forms of limited
inference are possible as well. For example: all
types and supertypes of a resource:"
This only applies to RDF(S) entailment. With OWL entailment not only
subClassOf statements can lead to subsumptions or types. Maybe this should be
clarified, e.g., by saying "Some forms of limited (RDF and RDFS)
inference are possible as well."

9.3 "Any variables introduced in the equivalent pattern are not part of
the results - they are hidden by implicit projection of the results to
just the variables given in the query." This should probably mention
that variables are also fresh, i.e., newly introduced variables do not
occur anywhere else in the query.

"whereas if the query were written out" is it not "was written out"
since query is singular?

10 "[...] The new variable must not already be in-scope in the query
at that point it is used." at *the* point

10.1 I would find it very helpful, if the sentence "Use of BIND is a
separate element of a group graph pattern and it ends any basic graph
pattern." is picked up in the example. Does this mean that the BGP
   ?x ns:price ?p .
   ?x ns:discount ?discount
   BIND (?p*(1-?discount) AS ?price)
   FILTER(?price < 20)
   ?x dc:title ?title .
of the example is equivalent to
   { ?x ns:price ?p .
     ?x ns:discount ?discount
     BIND (?p*(1-?discount) AS ?price)
   }
   { FILTER(?price < 20)
     ?x dc:title ?title .
   }
This doesn't seem to make sense. Can the example be shown also with
brackets to illustrate what "ends any BGP" means?

11.1 The results table uses ?totalPrice in the header, but there shouldn't
be a question mark, just totalPrice as ? is just variable syntax, but
the variable is totalPrice. It might also make sense to just use org
in the following text instead of ?org and there is also one
?totalPrice in the last sentence of the section. Typewriter font
should be used for the variables or query syntax elements as elsewhere
in the document.

"[...] In aggregate queries and sub-queries variables that appear
in the query pattern, but are not in the GROUP BY clause cannot be
projected nor used in project expressions." I would add a comma after
"GROUP BY clause"
I don't think this is correct. I can select expressions with aggrated
variables that are not grouped:
SELECT (SAMPLE(?x) AS ?y) { ?x :p ?z } GROUP BY ?z
Isn't (SAMPLE(?x) AS ?y) what you call a project expression? Shouldn't
project expression anyway be select expression?
"It is an error for aggregates to project variables with a name
already used in other aggregate projections."
Isn't it even forbidden to use any variable that is used elsewhere?
SELECT (SAMPLE(?x) AS ?y) { ?x :p ?y } GROUP BY ?y
would not be valid, right?

11.2 "Note that the empty set is used in some aggregates to pass
scalar arguments to the set function. Sclar arguments are used to pass
argument to the set function which apply to all values passed. "
One sentence is redundant. Probably the second as it also has a
grammar error "which pll*ies*"
"And example is..." <- "An example is..."

16.2.2 "where app:customDate identified an extension function", I
would use "identifies" here

16.2.4 The document pretty consistently sets SPARQL grammar keywords
in typewriter font, but not so in this section. CONSTRUCT and FILTER
are normal font, but WHERE is typewriter

17 "These errors have no affect outside of FILTER evaluation."
s/affect/effect/

17.4.1.4 "There is a filter operator EXISTS that takes a graph
pattern.  exists returns true/false depending on whether the pattern
matches the dataset"
The second exists should also be uppercase.
True/false is usually written in typewriter font within the document.
Shouldn't dataset in "pattern matches the dataset" not rather be
something like active graph or queried graph?

"The NOT EXISTS form translates into fn:not(EXISTS{...})."
Why is the next line then explicitly specifying the evaluation of NOT EXISTS
{ pattern } to return xsd:boolean values?

"Returns true if pattern matches the dataset." same as above
s/dataset/active graph/?

The algebra function exists is mentioned here first. This is the only
function that is all lowercase. All others have an uppercase first
character. Furthermore, in the "titles" exists is also written with
first character uppercse, e.g., "Definition: Exists" (funnily under
18.4.1.8 Sample) or "Definition: Evaluation of Exists" in 18.5.

17.4.2.8 "The IRI function constructs an IRI by resolving the string
argument (see RFC 3986 or any later RFC that superceeds RFC 3986. ). "
remove the fullstop and space in the brackets.

-----------------

also noticed, although Sec. 18 not yet reviewed:
18.2.1 "v is in-scope if in-scope in" <- "v is in-scope if **it is**
in-scope in"
although Sec 18+ not yet reviewed.

Received on Saturday, 3 December 2011 18:54:46 UTC