You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Rob Vesse (JIRA)" <ji...@apache.org> on 2018/02/13 10:06:00 UTC
[jira] [Commented] (JENA-1487) Incorrect SPARQL query result set
when applying ORDER BY after an empty GROUP BY
[ https://issues.apache.org/jira/browse/JENA-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362080#comment-16362080 ]
Rob Vesse commented on JENA-1487:
---------------------------------
This behaviour is perfectly in line with the spec. The difference between the two queries is the use of the {{COUNT(?o)}} aggregate. Per the specification ([https://www.w3.org/TR/sparql11-query/#defn_aggCount)] the count of a group is the cardinality of the given variable which in this case is zero because the cardinality of zero rows is always zero so using the aggregation introduces a single binding.
Note that the fact that the aggregate occurs in the {{ORDER BY}} is not relevant here, aggregates are extracted out and executed as part of the group by operator per the specification ([https://www.w3.org/TR/sparql11-query/#sparqlGroupAggregate] and [https://www.w3.org/TR/sparql11-query/#aggregateAlgebra]). This is more easily seen in the algebra form:
{noformat}
(project (?s)
(order ((desc ?.0))
(group (?s) ((?.0 (count ?o)))
(sequence
(filter false
(table unit))
(bgp (triple ?s ?p ?o))))))
{noformat}
Versus:
{noformat}
(project (?s)
(group (?s)
(sequence
(filter false
(table unit))
(bgp (triple ?s ?p ?o)))))
{noformat}
Note that in the first form {{COUNT(?o)}} is converted into an expression as part of the group operator so by the time that it is seen by {{ORDER BY}} it is simply operating over a temporary internal variable.
> Incorrect SPARQL query result set when applying ORDER BY after an empty GROUP BY
> --------------------------------------------------------------------------------
>
> Key: JENA-1487
> URL: https://issues.apache.org/jira/browse/JENA-1487
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 3.6.0
> Reporter: Claus Stadler
> Priority: Major
>
> Ordering an empty result set must not introduce additional bindings, but this happens with the following example (run on an arbitrary dataset - including an empty one):
> {code:bash}
> ./fuseki-server --file=test.ttl /foobar
> {code}
> The Json below is obtained from the Fuski bundle; but I noted this issue first using the ARQ API, where the incorrect result set contains a single BindingProjectNamed instance.
> {code:sql}
> SELECT ?s
> WHERE {
> ?s ?p ?o
> FILTER(false)
> }
> GROUP BY ?s
> ORDER BY DESC(COUNT(?o))
> {code}
> {code:json}
> {
> "head": {
> "vars": [ "s" ]
> } ,
> "results": {
> "bindings": [
> {
> # NOTE THIS EMPTY BINDING HERE!
> }
> ]
> }
> }
> {code}
> The result set is correct without the ORDER BY:
> {code:sql}
> SELECT ?s
> WHERE {
> ?s ?p ?o
> FILTER(false)
> }
> GROUP BY ?s
> {code}
> {code:json}
> {
> "head": {
> "vars": [ "s" ]
> } ,
> "results": {
> "bindings": [
> # CORRECT
> ]
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)