Further to the below, I've just seen that Stas filed this on Phabricator
this week,
https://phabricator.wikimedia.org/T116298
relating to queries like:
SELECT (COUNT(DISTINCT(?city)) AS ?count) WHERE {
?city wdt:P31/wdt:P279* wd:Q515 . # find instances of subclasses of city
?city wdt:P131* wd:Q1202 .
}
Either of these path requirements runs fine by itself; but something
about the combination causes the engine to time out.
-- James.
Hi Kingsley,
I had a problem with Blazegraph queries that had path requirements
containing a compound path predicate, and ending in a variable, eg
wd:Q289 wdt:P31/wdt:P279* ?o.
However, this particular example now appears to work. (With the recent
upgrade of the SPARQL endpoint to the latest Blazegraph production
release ?)
On the other hand, it appears that path queries can still fail if they
involve a variable intended to be a fixed constant set by a BIND
statement (usually the first thing a query engine will do).
So, for example, a query to count incidences of instances of subclasses
of painting, where the key requirement statement is
?a wdt:P31/wdt:P279* wd:Q3305213
runs in about 0.4 seconds. However, a very similar query where the
identity of that target superclass is set using a BIND statement,
BIND (wd:Q3305213 AS ?class) .
?a wdt:P31/wdt:P279* ?class .
times out -- or rather: it ought to be reporting that it has timed out,
and used to, but now it doesn't throw a "Query Timed Out" error, but
instead now after 120 seconds returns an (incorrect) count of zero. (An
additional, new bug).
Complete versions of these queries can be found at
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/suggestions#Path_assertions_that_end_in_a_variable_can_blow_up
and as a Blazegraph bug at
https://jira.blazegraph.com/browse/BLZG-1543
(although, as with a couple of other issues described on the same wiki
page linked above, that I've filed a Blazegraph bug for, there doesn't
seem to be any indication that anybody has actually read the bug...)
I'm not sure if Stas knows of other current issues with path queries.
I did post a complaint to this list, just after the query service was
publicly announced, that path queries seemed very slow. They *are*
still slower than the equivalent search on WDQ. But I think it was this
issue with binding variables that was underlying the worst of what I was
seeing.
As for cyclical paths, as I posted a couple of days ago, the queries at
https://www.wikidata.org/wiki/Wikidata:WikiProject_Names/given-name_variants
for counting up incidences of given-name variants involve graphs that
are anything but directed (based on the P460 "said to be the same as"
property), and Blazegraph seems to handle them without any particular
difficulty; though it's possible that there may have been earlier
problems when the service was still at an alpha stage.
-- James.
_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
