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