SERVICE clause not working with limits higher than 1

[thomasdegroot18]

While writing queries I came by an error that looks like something that happens in virtuoso, as I can not figure out why this query does not work. I am trying to retrieve all the heights of a set of buildings from two different datasets. But while the code works for one example as shown in the code below. The code breaks when the limit is set to 2. It looks as if the service query changes with when multiple records are being selected. This in turn breaks the entire query as shown in the error message below.

Query with the limit set to 1 in the select query.

prefix bag: <http://bag.basisregistraties.overheid.nl/def/bag#>
select ?pand ?shapeHeight {
  {
    select ?pand {
      ?pand bag:geometriePand _:1.
    }
    limit 1
  } 
  service <https://api.demo.triply.cc/datasets/kadaster/2-5D/services/2-5D/sparql> {
    ?pand <https://data.labs.pdok.nl/bag/def/measuredHeight> ?shapeHeight.
  }
}
limit 1

Result with a limit set to 1:

1 | http://bag.basisregistraties.overheid.nl/bag/id/pand/0003100000117485 | "14.07"^^xsd:double

Query written that has a limit of two for the select statement.

prefix bag: <http://bag.basisregistraties.overheid.nl/def/bag#>
select ?pand ?shapeHeight {
  {
    select ?pand {
      ?pand bag:geometriePand _:1.
    }
    limit 2
  } 
  service <https://api.demo.triply.cc/datasets/kadaster/2-5D/services/2-5D/sparql> {
    ?pand <https://data.labs.pdok.nl/bag/def/measuredHeight> ?shapeHeight.
  }
}
limit 1

Error message when the limit is set to 2.

Error - http status (500) - Query evaluation error: Virtuoso S0022 Error SQ200: No column pand.

SPARQL query: define sql:big-data-const 0 PREFIX bag: http://bag.basisregistraties.overheid.nl/def/bag# PREFIX rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema# PREFIX sesame: http://www.openrdf.org/schema/sesame# PREFIX owl: http://www.w3.org/2002/07/owl# PREFIX xsd: http://www.w3.org/2001/XMLSchema# PREFIX fn: http://www.w3.org/2005/xpath-functions# SELECT ?rowIdx ?shapeHeight WHERE { ?pand https://data.labs.pdok.nl/bag/def/measuredHeight ?shapeHeight. } VALUES (?rowIdx ?pand) { ("0" http://bag.basisregistraties.overheid.nl/bag/id/pand/0003100000117485 ) ("1" http://bag.basisregistraties.overheid.nl/bag/id/pand/0003100000117486 ) }

I've checked the queries but could not figure out why the query converts the values such that it does not accept the ?pand, but I could not figure it out. Possibly the query can be rewritten to insert the values correctly.

[TallTed]

@thomasdegroot18 -

I noticed that you have two LIMIT clauses -- one on the overall query, and one of the internal SELECT. What happens if you make both of these (not just the inner) LIMIT 2?

I see that the SERVICE instance is running 07.20.3217 built Nov 15 2017. If possible, that instance should be upgraded to the recent 7.2.5.1 on stable/7, or to the 7.2.6-rc now on develop/7.

Can you please confirm the version of Virtuoso in use on your local instance, where you're running the above query? Output of virtuoso-t -? or virtuoso-iodbc-t -? is best; the SPARQL query on this page can also be used.

[TallTed]

@thomasdegroot18 -

Please provide the above details, so we have some chance of reproducing the issue.

Assuming that your local instance is running 7.2.5.1 or later, it will likely help if you can provide a full explain and profile plan for the two queries -- the one that runs without error (with LIMIT 1) and with error (with LIMIT 2).

[LaurensRietveld]

@TallTed I ran into this issue as well. I tried this on 7.2.5.1, and on the lastest version in the master branch. Both show the same behaviour.

Could you elaborate more on how to create an explain and profile plan for these two queries? Would that make sense, considering virtuoso is the endpoint being federated to? (not the endpoint that handles the full query)

Test queries: limit1 that works limit 2 that fails

[kidehen]

Here's the second query ready for execution from our URIBurner instance.

As you can see, it returns the same solution as the first one that you indicated was working. Thus, we are looking at codebase related issues i.e., functionality that might not be in the Open Source edition, since our URIBurner service is based on the Commercial Edition.

/cc @TallTed @HughWilliams @pkleef