You can keep the Occupation tree under person if you can live with the
fact that these classes describe individuals, not occupations performed by
Persons. A Senator is a Politician, but a Parliament is not, because it is
an Organization. The Beatles is a Band but not an Artist, and the same is
true for Ballets and Orchestras. If you keep organization roles and
person roles under distinct trees, it works. Note that you will not be
able to represent common daily roles such as Client or Employer this way,
since these can be performed by any Agent, not only Persons. (Caligula's
horse Incitatus being a Consul does not count.)
The English ver to be (and the French être, Russian быть etc) does not
distinguish between being permanently and being temporarily, so maybe that
is why we Portuguese (and Italian, Spanish etc) speakers note a bit of
oddness in attaching temporary roles such as occupations with a permanent
relation such as IS-A. We distinguish "ele _é_ empregado da Google" (he
is permanently an employee of Google) from "ele _está_ empregado pela
Google" (he is currently/temporarily employed by Google).
You can argue that being a Writer is not exactly a role, since you are
saying something permanent about the person, and I agree, this is the
common sense. But you must guarantee that when a text is written by an
Agent (a person, a group of writers, the Senate, a council), this will not
imply that the Agent is a Writer. In other words, the subclasses of Person
are not roles with attached actions, they are subkinds the kind Person.
Also, they are not mixins, you cannot use these for subtyping from classes
different than Person. There can be a RobotWriter, subclass of Robot, but
it cannot be a subclass of Writer, because Person and Robot should be
disjoint (for now).
One should be aware of such limitations when matching equivalent classes
in other more strict ontologies. The DBpedia ontology should never used
out of the box except for simple queries, so it is nice to keep it simple
and free of strong assertions that would hinder its use. However, if we
define no constrains at all it may lead to the misinterpretation of some
classes. Making Person and Organization disjoint classes is a must, to
avoid bad subclassing.
Cheers.
=============================================
Marcelo Jaccoud Amaral
PETROBRAS
=============================================
De: "Peter F. Patel-Schneider" <pfpschnei...@gmail.com>
Para: Sebastian Hellmann <hellm...@informatik.uni-leipzig.de>,
jacc...@petrobras.com.br, Paul Houle <paul.ho...@ontology2.com>
Cc: DBpedia <Dbpedia-discussion@lists.sourceforge.net>
Data: 2017-07-17 09:55
Assunto: Re: [DBpedia-discussion] Purpose of the DBpedia Ontology
was Re: Call for Ontology Editor demos for DBpedia
One reason to have a subclass structure under Person (but also under any
natural kind) is to support generalizations for subcategories. Many of
the
subclasses of Person in DBpedia are for occupations, e.g., Architect,
Athlete,
NascarDriver, Politician, and Senator. If these subclasses of Person are
eliminated then there should be some way to retain that any senator is a
politician.
peter
On 07/11/2017 03:10 PM, Sebastian Hellmann wrote:
> Hi all,
[...]
> By the way, is there actually any sensible class that can be subclass of
> Person? As far as I see, the only essential distinction that lasts
lifelong is
> fictious/non-fictious . We are thinking about disallowing subclasses of
> Person, unless there is a valid concern brought up.
>
> Also it seems like we will not be able to handle all exceptions like
spouse
> being non-functional for a dozen persons. From a practical perspective,
if
> functionality is consistent for 95% of the data, this might be something
we
> can live with. Proper documentation of these pitfalls can be given.
>
> All the best,
> Sebastian
>
>
"O emitente desta mensagem é responsável por seu conteúdo e endereçamento. Cabe
ao destinatário cuidar quanto ao tratamento adequado. Sem a devida autorização,
a divulgação, a reprodução, a distribuição ou qualquer outra ação em
desconformidade com as normas internas do Sistema Petrobras são proibidas e
passíveis de sanção disciplinar, cível e criminal."
"The sender of this message is responsible for its content and addressing. The
receiver shall take proper care of it. Without due authorization, the
publication, reproduction, distribution or the performance of any other action
not conforming to Petrobras System internal policies and procedures is
forbidden and liable to disciplinary, civil or criminal sanctions."
"El emisor de este mensaje es responsable por su contenido y direccionamiento.
Cabe al destinatario darle el tratamiento adecuado. Sin la debida autorización,
su divulgación, reproducción, distribución o cualquier otra acción no conforme
a las normas internas del Sistema Petrobras están prohibidas y serán pasibles
de sanción disciplinaria, civil y penal."
------------------------------------------------------------------------------
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
