All geek questions in one place

SPARQL query with COUNT and ORDER returns an odd result

The following query counts all triples in the store

SELECT count(*) where { ?s ?p <http://dbpedia.org/resource/Cat> }

And returns the expected results

http://dbpedia.org/sparql?default-graph-uri=http://dbpedia.org&query=select+count (*) + {+% 3FS +% 3Fp +% 3Chttp: //dbpedia.org/resource/ Cat% 3E +} + & debug = = & timeout = & format = text / HTML & save = display & file_name =

However, when I first tried this, I accidentally left in the ORDER BY statement, for example,

 select count(*) { ?s ?p <http://dbpedia.org/resource/Cat> } order by ?s

Then I get a very long list of results

http://dbpedia.org/sparql?default-graph-uri=http://dbpedia.org&query=select+count (*) + {+% 3FS +% 3Fp +% 3Chttp: //dbpedia.org/resource/ Cat% 3E +} + order + on +% 3FS & debugging = on & timeout = & format = text / HTML & save = display & file_name =

Can someone explain why this result is happening and what it means? Perhaps this is a bug with the implementation of Virtuoso SPARQL?

+4
source share
3 answers

This seems like an error if you run the same type of requests in another store, i.e. at http://api.talis.com/stores/bbc-backstage/services/sparql (which is not started by a virtuoso)

This first request works ...

 SELECT (count(?s) as ?c) WHERE { ?s ?p <http://purl.org/ontology/po/Version> . }

and second...

 SELECT (count(?s) as ?c) WHERE { ?s ?p <http://purl.org/ontology/po/Version> . } order by ?s

... gives the same result.

In fact, counting + ordering here does not make much sense, because ?s not selected to receive. But, as you said, you tried it by accident and ... it seems like a mistake.

My recommendation is to send an email to the virtuoso-user mailing list to notify me of this problem.

+5
source

We (= OpenLink) have problems. This ORDER BY is formally an error in the query: an aggregate without grouping means “aggregate to everything”, there should not be variables outside the aggregates at the output end of the query. However, this error is not reported now: violations of this rule are so numerous that the SQL compiler does automatic grouping, and our SPARQL-to-SQL preprocessor also ignores this error, if possible.

We will probably keep the current behavior as is. If "strict" compilation mode is added, it triggers an error report in such cases.

+2
source

It might be a bug with Virtuoso, it seems to handle aggregate queries and the ORDER BY as having an implicit GROUP BY . I noticed this on Virtuoso other endpoints besides DBPedia.

IMO is a mistake and you should report it to the Virutoso users mailing list, as msalvadores offers

+1
source

Source: https://habr.com/ru/post/1346293/

More articles:


All Articles