Agility of the DBpedia ontology

Hi everyone.

I am currently building a query about Writers.
And I am trying to deal with the range of property “Occupation”.
I have found that “PersonFunction” is a reasonable range for “Occupation”.
But while having a look at some objects of the “Occupation” property, that are NOT of type
“PersonFunction”, I have found some weird things.

For example, the resources “Actor” and “Author” are only of type “Thing”, not of type “PersonFunction”.
the resources “Art_historian” and “Book_reviewer” are of types “Thing” and “Book” (???), but not of type “PersonFunction”.
“Biographer” is of type “Thing” and “Person” (???). But not of type “PersonFunction”


I can agree that the occupation of a Writer (or more generally the occupation of a Person) can be many classes more than just PersonFunction. It could be:

But my question is this:
how to discuss proper type hierarchy in DBPedia?
And more important: what process should be enabled to update the type hierarchy (and the types of resources in general)?

Cleaning up the old one is an option, but with many side effects and it will be slow.
You can still edit it at and soon you will be able to debug it better with
which takes all URIs from DBpedia and Wikidata:

To achieve agility, however, we envision the Databus to hold many other ontologies by DBpedia sub-communities. One example is this here:
This is a classification built by the Czech DBpedia. It is automated, so once we get the abstract/text extraction going, it will pump out updated hypernym classifications/hierarchies.

So in my opinion, if you really want to have a good model for occupation, start a subproject and release it on the Databus, either free like “propan/lhd” and we might integrate it into core from there or paid (support in preparation).

Professions/occupations such as Arti historian, Book reviewer, Biographer etc typically don’t have infoboxes. DBpedia types are mostly assigned by infoboxes (though datasets like Heuristic Types and LHD assign extra types not based on infoboxes).

AFAIK, there is no infobox that generates the class PersonFunction directly. Instead, that class is used as an intermediate node when RDFizing Person boxes that include many positions/occupations over time (thin politicians and sports players who may change positions and teams many times over their life).

Sorry to answer in the negative…

indeed this query shows all PersonFunction to be intermediate nodes such as (note the numeric suffix)

These don’t resolve directly, nor are served as part of the main entity, eg

 curl -L -Haccept:text/turtle


dbo:occupation  dbr:Music_teacher ,
                <> ,

But you have to SPARQL to find the properties of
Which in this case happen to be useless:

rdf:type	dbo:PersonFunction; dbo:title "Band director"@en