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

Reply via email to