Если я вас правильно понимаю, вы просто хотите узнать, как экземпляры классифицируются в Викиданных.
Итак, начиная с примера, @AKSW дал:
SELECT DISTINCT ?event_type ?event_typeLabel {
?event_type wdt:P279* wd:Q26907166
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
LIMIT 100
*
- довольно дорогая для вычисления операция, и к моменту написания Wikidata насчитывала около 50 миллионов элементов. Вот почему мне пришлось добавить LIMIT
, потому что я получал тайм-ауты без него.
Графика
Чтобы получить представление о данных, мне нравится просматривать их в построителе графиков Wikidata. Потому что это хорошо показывает кластеризацию.
https://angryloki.github.io/wikidata-graph-builder/?property=P279&item=Q26907166&iterations=2&mode=reverse
Как видите, после 2 итераций уже существует много классификаций. Таким образом, мы могли бы также быть счастливы с этим запросом:
SELECT DISTINCT ?event_type ?event_typeLabel {
?event_type wdt:P279/wdt:P279 wd:Q26907166
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
Обратите внимание, что он проходит только 2 раза вдоль свойства P279. На данный момент это дает мне 281 пунктов.
Если вам действительно нужно полностью пройти по дереву, вы можете отфильтровать операторы "instance of" (P31), используя FILTER NOT EXISTS
. Но проблема в том, что в настоящее время всегда возникают таймауты:
SELECT DISTINCT ?event_type ?event_typeLabel {
?event_type wdt:P279* wd:Q26907166 .
FILTER NOT EXISTS { ?event_type wdt:P31 [] }
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
LIMIT 100
С помощью подзапроса вы можете ограничить результаты из дерева, но вы получите неполные данные:
SELECT ?event_type ?event_typeLabel
WHERE
{
{
SELECT DISTINCT ?event_type
WHERE
{
?event_type wdt:P279* wd:Q26907166 .
}
LIMIT 1000
}
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
FILTER NOT EXISTS { ?event_type wdt:P31 [] }
}