Page MenuHomePhabricator

[BLZMI] 🐛hasType query returns timeout
Closed, ResolvedPublic

Description

SparqlHelper's hasType method generates a query to check whether the given entity is an instance of the provided "class" entity or any of its subclasses. Here is an example of the query, containing some real values, which should return true:

PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
ASK {
  BIND(wd:Q124 AS ?item)
  VALUES ?class { wd:Q18602249 }
  ?item wdt:P279* ?class.
}

When run on the current version of the query service (using Blazegraph), it returns true, and does so very quickly. (query link)

When run against https://query-next.wikidata.org/sparql, it runs for about 30 seconds and results in a server error: {"details":"Error id e7dce717-3e96-4f1c-9651-829ac94a8646-5","stack":""}

When run against https://qlever.dev, it results in a timeout, which is presumably the cause of the server error on query-next. (query link)

Steps to Reproduce

image.png (852×510 px, 104 KB)

Additional Info
Omitting the * from the query (which is what recursively checks subclasses), qlever.dev responds quickly, without a timeout error. (query link)

Notes:

Event Timeline

FWIW, the query works quickly for me if I inline the ?item variable or the ?class variable (or both). Given that ?class may have multiple values, inlining ?item is probably the best workaround in WBQC (I’m not sure why this used BIND() to begin with, to be honest).

PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
ASK {
  VALUES ?class { wd:Q18602249 }
  wd:Q124 wdt:P279* ?class.
}

But I’m also surprised that QLever fails on such a structurally simple query (rewrite)…

Hi @Hannah_Bast , do you know the reason for the BIND causing this timeout?

@trueg This is exactly https://github.com/ad-freiburg/qlever/issues/2867. It looks simple but it's actually a very complex issue.

In a nutshell: It's related to the so-called "empty path" semantics (which is relevant when there is a property path with * or ? involved). The problem is trivial to solve when one is willing to give up 100% standard compliance for all corner cases related to the empty path. These corner cases are very subtle, very hard to understand for normal users, and hardly relevant. See the long explanations in https://github.com/ad-freiburg/qlever/issues/2867

Let's continue the discussion over there. We are close to resolving this