Après test, j'ai constaté qu'en ajoutant les sous-catégories, la requête prend trop de temps, c'est sans doute ce que vous voulez dire mais je n'avais pas compris.
Pour archive, j'ai testé la requête suivante, qui échoue:
SELECT ?item (COUNT(distinct ?sitelink) as ?count)
WHERE
{
?item wdt:P31 wd:Q5 .
?item wdt:P21 wd:Q6581072 .
?item wdt:P106/wdt:P279 wd:Q864503 .
?sitelink schema:about ?item .
?item wikibase:sitelinks ?linkcount .
FILTER (?linkcount >= 5) .
FILTER NOT EXISTS { ?wfr schema:about ?item . ?wfr schema:inLanguage "fr" } }
GROUP BY ?item ORDER BY DESC(?count) LIMIT 200
Des moyens de gérer les trous dans la requête seraient peut-être d'identifier les principales sous classes de biologistes qui pourraient nous intéresser pour faire des requêtes individuelles, ou de passer par une requête directe sans passer par le moteur SPARQL (mais pas lancée trop régulièrement pour pas faire plier le serveur).