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”

Etc.

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:
yago:Activity100407535
yago:Duty100719494
yago:Function100720565
yago:Occupation100582388

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 http://mappings.dbpedia.org and soon you will be able to debug it better with http://global.dbpedia.org/?s=https%3A%2F%2Fglobal.dbpedia.org%2Fid%2FWzpc&p=http%3A%2F%2Fdbpedia.org%2Fontology%2FmeltingPoint&src=general
which takes all URIs from DBpedia and Wikidata: http://global.dbpedia.org/?s=http%3A%2F%2Fnl.dbpedia.org%2Fresource%2FEthanol

To achieve agility, however, we envision the Databus to hold many other ontologies by DBpedia sub-communities. One example is this here: https://databus.dbpedia.org/propan/lhd/linked-hypernyms/2016.04.01
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)

http://dbpedia.org/resource/Faye_Barker__1
http://dbpedia.org/resource/George_N._Parks__1
http://dbpedia.org/resource/George_N._Parks__2

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

 curl -L -Haccept:text/turtle http://dbpedia.org/resource/George_N._Park

returns

dbo:occupation  dbr:Music_teacher ,
                <http://dbpedia.org/resource/George_N._Parks__1> ,
                dbr:Band_director 

But you have to SPARQL to find the properties of http://dbpedia.org/resource/George_N._Parks__1.
Which in this case happen to be useless:

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