Re: SPARQL 1.1 Query Review Part 1

Thanks Birte, Andy,

Comments inline near @@Steve tags

On 6 Dec 2011, at 12:20, Andy Seaborne wrote:

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

Fine.

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

I believe that's as the group intended.

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

Yeah, terminology error, changed to 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?
> 
> @@Steve

I'm not really sure, that seems like more of a general select expressions restriction - I thought that was allowed at one time though?

I guess it wouldn't hurt to reiterate if that is the case, Andy?

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

Looks wrong, but I can't find this text anywhere… 11.2 is GROUP BY

"set is used" only appears in one place in the doc that I can see, and it looks unrelated.

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

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Tuesday, 6 December 2011 22:54:23 UTC