I am working with @antaljanosbenjamin on implementing the Interactive workload of the LDBC Social Network Benchmark's Interactive workload in SPARQL (see our previous issue).
We stumbled upon a query that seems to produce non-deterministic results. I created a Gist with a standalone version of the query.
For the LDBC SF1 data set, this query should produce:
+-------------------+-----------+
| tagName | postCount |
+-------------------+-----------+
| "Tom_Gehrels" | 28 |
| "Sammy_Sosa" | 9 |
| "Charles_Dickens" | 5 |
| "Genghis_Khan" | 5 |
| "Ivan_Ljubičić" | 5 |
| "Marc_Gicquel" | 5 |
| "Freddie_Mercury" | 4 |
| "Peter_Hain" | 4 |
| "Robert_Fripp" | 4 |
| "Boris_Yeltsin" | 3 |
+-------------------+-----------+
While it returns these results sometimes, it also produces incorrect results at times:
+-------------------+-----------+
| tagName | postCount |
+-------------------+-----------+
| "Tom_Gehrels" | 16 |
| "Marc_Gicquel" | 5 |
| "Charles_Dickens" | 4 |
| "Robert_Fripp" | 4 |
| "Brazil" | 3 |
| "Dimitri_Tiomkin" | 3 |
| "Freddie_Mercury" | 3 |
| "Ivan_Ljubičić" | 3 |
| "Muammar_Gaddafi" | 3 |
| "Peter_Hain" | 3 |
+-------------------+-----------+
However, when it does produce the incorrect results, they are consistent (i.e. they are always the same).
Now, as usual for Heisenbugs, this issue quite tricky to reproduce, but erroneous results occurred on both our laptops, and on our server as well. I can compress the Stardog instances and send them over to you if it helps.
We're working on Ubuntu machines and leave everything for Stardog on default, expect the memory and timeout settings.