Re: SPARQL 1.1 Query Review Part 1

Birte,

Thank you for the review.

Steve - I've left non-editorial points on your sections as marked @@ 
below.  I have done some editorial changes to them which you might wish 
to check; hope that's OK.

	Andy

On 03/12/11 18:54, Birte Glimm wrote:
> 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

Done

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

It's not required.  The DOT is not needed when not followed by more 
triples (if you'll forgive the double negative).

Ditto
?s :p ?o OPTIONAL { ?s :q ?v }


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

Done (2)

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

Done

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

reworded as:

"""
given the values of variables in the group graph pattern in which the 
filter occurs.
"""
and filters are, more generally, applicable to group graph patterns.

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

Changed.

It was also wrong because the variable x is used in the answers

> 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

Correct as is but this is not working for you so changed to:

"more concise expressions for some"

"cannot" vs "can not" -- both are correct.  Separate words used here to 
leave a slight stress to the "not".

> 9.1 (table)
> "A sequence path of elt1, followed by elt2" is the only entry that
> does not end with a fullstop

Done, and comma removed.

> A alternative path of elt1, or elt2<- A**n** alternative..., I would
> remove the comma

Done

> A path of zero or one elt.<- A path of zero or one occurrences of
> elt. (to be consistent with the rest)

Done.

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

Changed to:

"For example, for RDFS, all types and supertypes of a resource"

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

Done.

"""
Any variables introduced in the equivalent pattern are not part of the 
results and are not already used elsewhere.
""
also, I made the introduced variable start ?_ to make them look a bit 
machine-y.


(of course, could introduce bnodes and the project happens for free :-)

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

Use of the the past subjunctive in a conditional.

The more informal "was" is taking over in written text.

The present subjunctive is archaic
"if the query be written out"

I have noticed 9.3 says that :p* is equivalent to :p{0} union :p+. 
Translation text removed - the example is not affected otherwise (it is 
equivalent in this case - just not in general and not expressed like 
that in the formal algebra).

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

Done
"""
The new variable must not already be in-scope in the query at the point 
where it is used.
"""

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

Good idea.

It's not

 >     { FILTER(?price<  20)
 >       ?x dc:title ?title .
 >     }

the FILTER applies to the whole group.


I've added an equivalent query example:

"""
Equivalent query (BIND ends the basic graph pattern:
            the FILTER applies to the whole group graph pattern):
PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
PREFIX  ns:  <http://example.org/ns#>

SELECT  ?title ?price
{  { ?x ns:price ?p .
      ?x ns:discount ?discount
      BIND (?p*(1-?discount) AS ?price)
    }
    {?x dc:title ?title . }
    FILTER(?price < 20)
}
"""

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

Done.

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

I have done the editorial side of these comments.  I reformatted this 
area - I kept ?org but it's monospaced, and monospaced all SPARQL syntax 
in text.

@@Steve - please check your happy with the changes.

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

Done

> 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

@@Steve

> Isn't (SAMPLE(?x) AS ?y) what you call a project expression? Shouldn't
> project expression anyway be select expression?

@@Steve

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

@@Steve

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

@@Steve

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

Done

> 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

First CONSTRUCT is referring to the query form, not the syntax (e.g. in 
the section titles) so I've added "query form".  I have corrected the 
others.

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

Done

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

Done

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

Changed to:

"given the bindings in the current group graph pattern, the dataset and 
the active graph at this point in the query evaluation."

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

because NOT EXISTS is the important form so I wanted to emphasise it.

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

remove " the dataset" (twice) given the longer text now preceding it.

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

Capitalized.

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

Done.  And put back ref to RFC 3987 as, on checking, I see that RFC 3987 
allows real, concrete IRIs, not just mapped to URIs.

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

Done

Received on Tuesday, 6 December 2011 12:21:43 UTC