Query parsing errors when using SERVICE block

Support Bug
1

Hi

I've created 2 databases (with query.all.graphs set to true) in 6.1.2. All queries were via Studio

In testing DB I created the data as follows

prefix alu: <http://some.testing/voc/olt/alu#>
prefix : <http://some.testing/voc/olt/alu/inst#>
insert data {
    :thing1 alu:cardId "1" .
    :thing2 alu:cardId "2" .
    :thing3 alu:cardId "3" .
    :thing4 alu:cardId "4" .
}

And in the other DB I created the data as follows

prefix alu: <http://some.testing.com/voc/olt/alu#>
prefix : <http://some.testing/voc/olt/alu/inst#>
insert data {
    :thing1 alu:type "AACU-A" .
    :thing2 alu:type "AACU-B" .
    :thing3 alu:type "AACU-C" .
    :thing4 alu:type "AACU-C" .
}

Then I ran the following query against the testing DB

prefix alu: <http://some.testing/voc/olt/alu#>
select * where {
    service <db://other> {
        select ?c where {
            ?c alu:type "AACU-C"
        }
    }
    # ?c ?p ?o .
    ?c alu:cardId ?id .
}

I'm pretty sure it's valid SPARQL (online validators agree) but it gives the following error

Caused by: com.complexible.stardog.plan.eval.operator.OperatorException: Encountered " "where" "WHERE "" at line 11, column 1.
Was expecting one of:
    "(" ...
    "!" ...
    "^" ...
    "a" ...
    <Q_IRI_REF> ...
    <PNAME_NS> ...
    <PNAME_LN> ...
    <VAR1> ...
    <VAR2> ...

	at com.complexible.stardog.KernelDatabaseService$KernelDatabaseServiceQuery.evaluateBatch(KernelDatabaseService.java:130) ~[stardog-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.service.BatchingJoinArgServiceQuery$BatchingJoinArgIterator.nextIterator(BatchingJoinArgServiceQuery.java:128) ~[stardog-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.service.BatchingJoinArgServiceQuery$BatchingJoinArgIterator.computeNext(BatchingJoinArgServiceQuery.java:135) ~[stardog-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.service.BatchingJoinArgServiceQuery$BatchingJoinArgIterator.computeNext(BatchingJoinArgServiceQuery.java:93) ~[stardog-6.1.2.jar:?]
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141) ~[guava-26.0-jre.jar:?]
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136) ~[guava-26.0-jre.jar:?]
	at com.complexible.stardog.plan.eval.operator.impl.ServiceOperatorImpl.computeNext(ServiceOperatorImpl.java:89) ~[stardog-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.operator.impl.ServiceOperatorImpl.computeNext(ServiceOperatorImpl.java:34) ~[stardog-6.1.2.jar:?]
	at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-6.1.2.jar:?]
	at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:82) ~[stardog-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:29) ~[stardog-6.1.2.jar:?]
	at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-6.1.2.jar:?]
	at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:112) ~[stardog-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:25) ~[stardog-6.1.2.jar:?]
	at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-6.1.2.jar:?]
	at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:116) ~[stardog-6.1.2.jar:?]
	at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:39) ~[stardog-6.1.2.jar:?]
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141) ~[guava-26.0-jre.jar:?]
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136) ~[guava-26.0-jre.jar:?]
	at com.complexible.common.rdf.query.IteratorAsTupleQueryResult.hasNext(IteratorAsTupleQueryResult.java:78) ~[stardog-utils-rdf-6.1.2.jar:?]
	... 15 more

Switching to the ?c ?p ?o pattern instead of the ?c alu:cardId ?id gave the same error with these 2 test DBs. Weirdly, in the 'real' DBs I was using for testing and originally saw the issue, it then worked OK and returned the expected results! (they had identical data - 489m quads). I was initially using the ?c ?p ?o pattern to see if it worked OK, and after it did, I wanted to then filter down the data to named properties

2

Hi Rory,

Thanks for the report. We'll take a deeper look today at 6.1.2 but I tried with 6.2 and it seemed to work, i.e. I got

+---------------------------------------------+-------+
|                      c                      |  id   |
+---------------------------------------------+-------+
| http://some.testing/voc/olt/alu/inst#thing3 | "3"   |
| http://some.testing/voc/olt/alu/inst#thing4 | "4"   |
+---------------------------------------------+-------+

I had to tweak prefix declarations a little since alu: resolves to <http://some.testing/voc/olt/alu#> in testing but to <http://some.testing.com/voc/olt/alu#> in other.

It's possible that the server chooses different evaluation strategies based on whether the pattern which is joined with the SERVICE is selective or not. That could explain the bug appearing after changing ?s ?p ?o to ?c alu:cardId ?id.

Cheers,
Pavel

PS. It seems like you don't need the projection in the SERVICE for this query, i.e. could be simplified to

prefix alu: <http://some.testing.com/voc/olt/alu#>
select * where {
    service <db://other> {
            ?c alu:type "AACU-C"
    }
   ?c alu:cardId ?id .
}

but it might make a difference for a more complex SERVICE query, esp. in a combination with DISTINCT.

3

Re the some.testing.com - sorry, that's my bad. I used difference namespaces in actual testing and changed them to hide some details in the report and left a rogue .com floating around

I'll try to have a go on a new download of 6.2 on the bigger datasets