A DBpedia SPARQL query misses small number of triples when asking for large number of relations - sparql

Question

I'm running the following SPARQL query on DBpedia (in fact I'm running a similar CONSTRUCT query via rdflib, see blow in the edited section):
SELECT *
WHERE {
{ ?influencer dbo:influenced ?influencee .}
UNION
{ ?influencee dbo:influencedBy ?influencer .}
?influencer rdf:type dbo:Person .
?influencee rdf:type dbo:Person .
}
The above query almost works, except that some (a small number of) triples is missing.
E.g. the following relation is missing:
<http://dbpedia.org/resource/Plato> --> <http://dbpedia.org/resource/Aristotle>
Yet, we can see the above relation really should be included, e.g. by manually examining the Aristotle entry on DBpedia and looking at the dbo:influencedBy section.
What's wore, is that if I augment the above code with some FILTER() expressions to limit the amount of returned tuples, I do get this missing relation in return:
SELECT *
WHERE {
{?influencer dbo:influenced ?influencee .}
UNION
{?influencee dbo:influencedBy ?influencer .}
?influencer rdf:type dbo:Person .
?influencee rdf:type dbo:Person .
FILTER(regex(?influencer, "Plato"))
FILTER(regex(?influencee, "Aristo"))
}
Edit 2022-07-02: I'm aware of the 10k query result limit imposed by the DBpedia backend, yet I believe this limit is not interfering here (as hinted by TallTed below). This is because, in fact, I'm using the rdflib to run the query and -- in it -- I'm using the CONSTRUCT rather than the SELECT clause:
>>> import rdflib
>>> g = rdflib.Graph()
>>> query = """
... PREFIX schema: <http://schema.org/>
... PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
... PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
... PREFIX dbo: <http://dbpedia.org/ontology/>
... PREFIX dbp: <http://dbpedia.org/property/>
... PREFIX dbr: <http://dbpedia.org/resource/>
...
... CONSTRUCT {
... ?influencer dbo:influenced ?influencee .
... }
... WHERE {
... SERVICE <https://dbpedia.org/sparql/query> {
... {?influencer (dbo:influenced|dbo:influences) ?influencee .}
... UNION
... {?influencee dbo:influencedBy ?influencer .}
...
... ?influencer rdf:type dbo:Person .
... ?influencee rdf:type dbo:Person .
... }
... }"""
>>> qres = g.query(query)
>>> len(qres)
9464
And this query returns less than 10k...
EDIT: 2022-07-02, part2:
Interestingly, running the above code with the following selector:
SELECT ?influencer ?influencee
instead of the CONSTRUCT, returns indeed 10000 results, suggesting that I'm bouncing from the limit.
So the question really is about why my CONSTRUCT clause returns much less results than the SELECT clause?
Thanks!

Answer 1

A quick check of the COUNT(*) on your initial query shows that there are 19,527 solutions.
It is not surprising that you don't get them all when you run your query, as there's a 10,000 solution limit on that public instance -- and it's not "a small number of" triples that's missing!
To get all solutions, you'll need to add a few clauses -- i.e., ORDER BY ?influencer ?influencee , LIMIT 10000, and OFFSET 0 -- and then run the query to get the first 10,000 solutions. Then, change the OFFSET clause to OFFSET 10000 and run the query again, to get the remaining 9,527.
Of course, you'll probably also want to add a DISTINCT to your SELECT, as there's probably no point in repeated statements of influence.