LIMIT not respected in Javascript-submitted query

Support Bug
1

The query …

PREFIX cco: <http://www.ontologyrepository.com/CommonCoreOntologies/> 
PREFIX event: <http://ontology.com/Event#> 
PREFIX general: <http://ontology.com/GeneralConcepts#> 
SELECT ?region (COUNT(distinct ?event) as ?countOfMurders) 
FROM <http://graph.com> 
FROM NAMED <http://ontology.com> 
WHERE { 
      { graph <http://ontology.com> {
        ?type rdfs:subClassOf* event:MurderOrHomicide . 
         ?country a cco:Country ; rdfs:label ?coLabel .
          BIND (str(?coLabel) as ?checkLabel) . 
         } }
    ?event a ?type ; general:located_at ?loc . 
    ?loc rdfs:label ?region .
    FILTER (?checkLabel = ?region) .
} GROUP BY ?region 
ORDER BY DESC(?countOfMurders)
LIMIT 15

Returns all regions and their counts. The LIMIT is not respected.

Here is the query plan …

prefix cco: <http://www.ontologyrepository.com/CommonCoreOntologies/>
prefix event: <http://ontology.com/Event#>
prefix general: <http://ontology.com/GeneralConcepts#>

From <http://graph.com>
From Named <http://ontology.com>
Slice(offset=0, limit=15) [#15]
`─ Projection(?region, ?countOfMurders) [#119]
   `─ OrderBy(DESC(?countOfMurders), offset=0, limit=15) [#119]
      `─ Group(by=[?region] aggregates=[(COUNT(DISTINCT ?event) AS ?countOfMurders)]) [#119]
         `─ Filter(?checkLabel = ?region) [#119]
            `─ MergeJoin(?loc) [#238]
               +─ Sort(?loc) [#238]
               │  `─ MergeJoin(?event) [#238]
               │     +─ Sort(?event) [#5.4K]
               │     │  `─ MergeJoin(?type) [#5.4K]
               │     │     +─ Sort(?type) [#1.4K]
               │     │     │  `─ Bind(Str(?coLabel) AS ?checkLabel) [#1.4K]
               │     │     │     `─ LoopJoin(_) [#1.4K]
               │     │     │        +─ MergeJoin(?country) [#238]
               │     │     │        │  +─ Scan[POS](?country, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, cco:Country){<http://ontology.com>} [#238]
               │     │     │        │  `─ Scan[PSO](?country, <http://www.w3.org/2000/01/rdf-schema#label>, ?coLabel){<http://ontology.com>} [#2.4K]
               │     │     │        `─ PropertyPath(event:MurderOrHomicide -> ?type in <http://ontology.com>, minLength=0) [#6]
               │     │     │           `─ Scan[POS](?type, <http://www.w3.org/2000/01/rdf-schema#subClassOf>, event:MurderOrHomicide){<http://ontology.com>} [#3]
               │     │     `─ Scan[POS](?event, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, ?type) [#11.2M]
               │     `─ Scan[PSO](?event, general:located_at, ?loc) [#423K]
               `─ Scan[PSO](?loc, <http://www.w3.org/2000/01/rdf-schema#label>, ?region) [#5.4M]

Although the query plan indicates “slice”, no slicing is performed.

I know that the query can be written differently/more efficiently, but this structure is required due to its being run against multiple triple stores (and other bugs are present in those stores). The problem is checking the location value (which is just a string) against the country label (which is a string with a language tag).

Andrea

2

To be clear, this is only in the Javascript interface. The query works correctly through the command line.

Perhaps I must translate the LIMIT into the JS limit: xxx parameter?

Andrea

3

Andrea,

When you say the “Javascript interface,” do you mean using stardog.js directly to execute a query, or the web console interface at localhost:5820? If it’s the latter, it may be that the web console is transforming the query before sending it and changing or removing the limit. If you enable slow query logging (with a low threshold like 0s) you should be able to see in the log what query is actually being sent.

4

When I run stardogjs.query.execute and have a ‘LIMIT 15’ in my query, it is not respected. The LIMIT passed as a parameter overrides the LIMIT in the query.

I would have expected the LIMIT in the query to take precedence.

Andrea

5

Which of the two limits would or should take precedence seems to be quite subjective (even internally we have a little bit of a split). If you only specify the limit in the query, does that work as intended?