overzealous empty path detection?

[pfps]

The query https://qlever.cs.uni-freiburg.de/wikidata/1glIyB

SELECT DISTINCT * WHERE { 
<http://www.wikidata.org/entity/Q11629> 
( (<http://www.wikidata.org/prop/direct/P279> / ((<http://www.wikidata.org/prop/direct/P279>)*|(<http://www.wikidata.org/prop/direct/P31>)*))
| (<http://www.wikidata.org/prop/direct/P31> / ((<http://www.wikidata.org/prop/direct/P279>)*|(<http://www.wikidata.org/prop/direct/P31>)*)) )
?x1 }

causes

This query might have to evaluate the empty path, which is currently not supported. In file "/local/data-ssd/qlever/qlever-code/src/engine/TransitivePathImpl.h " at line 160

But the equivalent https://qlever.cs.uni-freiburg.de/wikidata/5D68x8

SELECT DISTINCT * WHERE { 
<http://www.wikidata.org/entity/Q11629> 
( (<http://www.wikidata.org/prop/direct/P279> / <http://www.wikidata.org/prop/direct/P279>*)
| (<http://www.wikidata.org/prop/direct/P279> / <http://www.wikidata.org/prop/direct/P31>*)
| (<http://www.wikidata.org/prop/direct/P31> / <http://www.wikidata.org/prop/direct/P279>*)
| (<http://www.wikidata.org/prop/direct/P31> / <http://www.wikidata.org/prop/direct/P31>*) )
?x1 }

works fine.

Why is the former a problem?

There quite a few queries like this in the paths section of the wdbench benchmark.

[hannahbast]

@pfps The problem is that QLever simply rewrites property paths with | as a UNION. For example

?x wdt:P31 / (wdt:P31* | wdt:P279*) ?y

becomes

?x wdt:P31 ?tmp . { ?tmp wdt:P31* ?y } UNION { ?tmp wdt:P279* ?y }

and the two parts of the UNION indeed have an empty-path problem, hence the error message.

To fix this, QLever should rewrite the query as follows:

{ ?x  wdt:P31/wdt:P31* ?y } UNION { ?x wdt:P31/wdt:P279* ?y }

It's not hard to fix for this special case, but requires a bit of work for arbitrary property paths (where the operators can be arbitrarily nested).

[pfps]

Yeah, the right solution might be to have several possible rewrites, and pick the one that appears to be best (with ones that can't be evaluated ranked last). But that can become expensive for very complex path expressions. (But how often do these occur?)

Another possible way to go would be to allow empty paths if either side is not unconstrained. But that probably would be an even bigger change.