Bad order of conditions in OPTIONAL clause may cause false results

[szarnyasg]

I ran into an interesting bug. To make it reproducible, I created a repository containing my install script, input data and queries: https://github.com/szarnyasg/4store-sparql-bug

I installed 4store 1.1.5 with Raptor 2.0.6 and Rasqal 0.9.28 to a 64-bit Linux Mint virtual machine. The installation log is available here: https://gist.github.com/szarnyasg/8159646

The query files are available here:

• https://github.com/szarnyasg/4store-sparql-bug/blob/master/SignalNeighbor.sparql

  PREFIX base: <http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#>
  PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  PREFIX owl:  <http://www.w3.org/2002/07/owl#>
  PREFIX rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  
  SELECT DISTINCT ?xRoute1
  WHERE
  {
    ?xRoute1 base:Route_routeDefinition ?xSen1 .
    ?xTE1 base:TrackElement_sensor ?xSen1 .
    ?xTE1 base:TrackElement_connectsTo ?xTE2 .
    ?xTE2 base:TrackElement_sensor ?xSen2 .
    ?xRoute1 base:Route_exit ?xSig .
  
    ?xRouteX base:Route_routeDefinition ?xSen2 .
    FILTER ( ?xRouteX != ?xRoute1 ) .
  
    OPTIONAL {
      ?xRoute2 base:Route_entry ?xSig .
      ?xRoute2 base:Route_routeDefinition ?xSen2 .
    } .
    FILTER (!bound(?xRoute2))
  }

  This query produces the correct results (confirmed by other tools).

• https://github.com/szarnyasg/4store-sparql-bug/blob/master/SignalNeighbor-bad.sparql

  The only difference is that in this query, lines 19 and 20 are in reversed order, so the OPTIONAL clause looks like this:

    OPTIONAL {
      ?xRoute2 base:Route_routeDefinition ?xSen2 .
      ?xRoute2 base:Route_entry ?xSig .
    } .

  This query produces the correct results but also false ones.

The visualized query is available here: https://github.com/szarnyasg/4store-sparql-bug/blob/master/SignalNeighbor-query-visualized.png (Notes: 1) RouteX is noted as Route3 on the figure. 2) For the sake of clarity, I deleted the rdf:type constraints from the query, as they had no effect on the results.)

The command line output is the following:

$ ./4s-query.sh SignalNeighbor
?xRoute1
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#3800>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#2326>

$ ./4s-query.sh SignalNeighbor-bad
?xRoute1
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#920>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#3202>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#4560>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#2868>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#4584>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#802>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#3858>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#558>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#1>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#3800>
<http://www.semanticweb.org/ontologies/2011/1/TrainRequirementOntology.owl#2326>

This isn't a serious issue and maybe it is related to some of the RDF libraries, but it might be worth investigating.

Thanks,
Gabor

[swh]

Wow, that's a really strange bug!

I'm afraid I absolutely don't have time to dig into the cause of it.

[msalvadores]

I'll look into it during the next few weeks.

Thanks for reporting the bug.