If I understand you correctly you just want to get the way instances are classified on Wikidata.
So starting with the example @AKSW gave:
SELECT DISTINCT ?event_type ?event_typeLabel {
?event_type wdt:P279* wd:Q26907166
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
LIMIT 100
The *
is a pretty expensive operation to calculate and by the time of writing Wikidata has close to 50 million items. That is why I had to add the LIMIT
because I was getting time-outs without it.
Graphing it
To get a feel for the data I like to look at it in the Wikidata graph builder. Because it shows clustering so nice.
https://angryloki.github.io/wikidata-graph-builder/?property=P279&item=Q26907166&iterations=2&mode=reverse

As you can see there are already a lot of classifications after 2 iterations. So we might also already be happy with this query:
SELECT DISTINCT ?event_type ?event_typeLabel {
?event_type wdt:P279/wdt:P279 wd:Q26907166
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
Note that it only goes 2 times along the property P279. At the moment this gives me 281 items.
If you really need to traverse the tree in full you can filter out "instance of" (P31) statements using FILTER NOT EXISTS
. But the problem is that that currently always runs into timeouts:
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
With a subquery you can limit the results from the tree, but you will get incomplete data:
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 [] }
}