W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

Re: SPARQL 1.1 Query Review Part 1

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 06 Dec 2011 12:20:59 +0000
Message-ID: <4EDE08AB.9020802@epimorphics.com>
To: public-rdf-dawg@w3.org

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.


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


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

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

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


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


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


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

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.


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 

(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

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.


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


> 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

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 

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


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

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
> Sample) or "Definition: Evaluation of Exists" in 18.5.


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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:05 UTC