There was a suggestion to eliminate all or most of the subclasses of Person from the DBpedia ontology. What happens then?
The current DBpedia ontology has a large number of classes under Person. Many of these classes are related to occupations, such as Architect, Artist, and Athlete. Under many of these occupation classes there are other, more-specific classes, such as MusicalArtist, Guitarist, MotorSportRacer, and NascarDriver. Asserting that a person belongs to one of the more-specific classes, such as NascarDriver, implies that the person belongs to its generalizations under Person, e.g., RacingDriver, MotorSportRacer, and Athlete for NascarDriver. The hierarchy of classes under Person provides DBpedia with a easy-to-use way of inferring significant information, such that if Kyle Busch is stated to be a NascarDriver then he is also a RacingDriver. This way of representing occupations has the advantages of being simple to specify and simple to use. If these subclasses of Person are eliminated there will have to be a multi-valued property for occupation, and then an instance of Person that is currently stated to be an instance of the class NascarDriver will have occupation nascarDriver. There will also have to be a generalization relationship between occupations, so that nascarDriver is a sub-occupation of racingDriver (and maybe also directly of motorSportRacer and athlete). Then there has to be a way of making this generalization relationship be effective. One way of doing this would be to have a convention that retrieving people with an occupation also retrieves people with sub-occupations of that occupation. However, this places a large burden on users of DBpedia. Alternatively there could be a set of axioms (or rules) asserting something like that whenever an instance of Person has an occupation that it also has all of the super-occupations of that occupation. This places an extra requirement either on the DBpedia extraction mechanism to materialize these inferences when DBpedia versions are created or on DBpedia services to make the results of these inferences available to users of the service. Another way of making occupations work correctly would be to have the DBpedia ontology include definitions for the occupation-based subclasses of Person, e.g., defining Artist as those instances of Person who have an occupation of artist or one of its sub-occupations. Under this methodology users of DBpedia don't need to change how they query for artists. However, this of course places a burden either on the DBpedia extraction mechanism or on DBpedia servers to perform the inferences needed to determine the membership of these defined classes. The replacement described above is not even adequate for the occupation-related subclasses of Person. Some of the subclasses of occupation-related classes, e.g., PrimeMinister, are not really occupations, just positions that imply an occupation. There will thus have to either be different additions made to the retrieval conventions or to the assertion axioms or the class definitions to account for these non-occupation subclasses. So although it is possible to eliminate explicit stating of membership in such subclasses in favour of properties, there are significant difficulties. I don't see that any gain achieved is worth the pain involved, particularly if the DBpedia ontology doesn't use a powerful ontology language. One advantage of going to a powerful ontology language is that other kinds of definitions and axioms can be used, such as defining one class as the disjoint union of several other classes. If there is a need for such definitions anyway then the cost of using a powerful ontology language is paid already so it may as well be also used to define classes in terms of property values. Peter F. Patel-Schneider Nuance Communications ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ DBpedia-discussion mailing list DBpedia-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion