Hi Paul,
I agree with you, and that's why I said adopting a foundational ontology
would be unwise for DBpedia: it is so heterogeneus, that it would be hard,
if not impossible, to get every single aspect right. However, a totally
property-infered model, like Samaruga proposed, would not really need an
OWL, DL-based ontology, the RDF/linked data model is quite suitable to
representing it.
I suppose DBpedia's ontology is aimed at supporting some basic reasoning,
it is not just a documenting tool. To support reasoning, it has to be
sound. So at least some sort of validation is needed to guarantee the
reasoners can do their work.
I'm not refering to nomenclature problems like calling the root of the
biological taxonomy dbo:Species, which a horribly chosen name. You just
rename it to LivingBeing and then it should be OK.
I'm talking about problems like creating a class Person and then
sub-classing it with Roles, which are not sub-classes of Person. This is
a very common mistake in conceptual modeling, and a lot of people do it
because they have worked their whole life with ER diagrams, and most of
the time that led to relational bases that worked fine. But conceptually,
this leads to a lot of problems, since a Person is a kind, i.e., it has an
identifier that distinguishes every instance from one another. And a
Person who is both a Painter and a Boxer would have two IDs, it would be
two persons simmultaneously (this is not like multiple inheritance, OWL is
not C++). And worst, if a Skater injuries it self and stop being a skater,
it ceases also to be a Person, which is not what the ontology is suposed
to represent. If you simply ignore these problems you will end up with
inconsistent ontologies which will lead to bad inference. You can make a
simple model, but not too much, otherwise it does not represent what it
should.
Some parts od the dbPedia ontology are simple as they should be, and that
works fine, but other parts look like a SKOS tree, where the owl:subClass
gets confused with skos:narrower of some other sort of PART-OF relation.
In other points, such as the case with Document/File and Document/Image
(but no Document/Text), the modeler forgot the distinction between the
piece of work (a novel, a law) and the media that supports it (a file, a
physical book, a rock). Putting File as a subclass of Document is a big,
big mistake. This things must be corrected to improve the quality of the
ontology and make it more useful.
I'm not saying you should apply very strict definitions, but you have to
apply some definitions, and those should work together. When a ontology is
built with definitions made by several people, you have to make sure they
do not collide, even if they are simple. Sometimes the correction is also
simple: move the Person subtree to a PersonOccupation subtree and
everything will make sense. This would help people work directly with more
DBpedia classes instead of making extensive remapping inside their
applications.
Cheers.
=============================================
Marcelo Jaccoud Amaral
PETROBRAS
Tecnologia da Informação e Comunicações - Arquitetura (TIC/ARQSERV/ARQTIC)
ramal: 706-7507
tel: +55 (21) 2116-7507
=============================================
dum loquimur, fugetir invida aetas: carpe diem, quam minimum credula
postero.
-- Horatius
De: "Paul Houle" <paul.ho...@ontology2.com>
Para: jacc...@petrobras.com.br, "Sebastian Samaruga"
<ssama...@gmail.com>
Cc: DBpedia <Dbpedia-discussion@lists.sourceforge.net>, "Sebastian
Hellmann" <hellm...@informatik.uni-leipzig.de>, "John Flynn"
<jflyn...@verizon.net>
Data: 2017-07-10 10:41
Assunto: Re[2]: [DBpedia-discussion] Call for Ontology Editor demos
for DBpedia
Marcelo,
classes have their place, but people get into a lot of trouble by
taking classes too seriously or deciding they have to be organized some
particular way.
People tend to disagree about classes more than they disagree about
properties, for instance, this famous film critic
http://www.rogerebert.com/rogers-journal/video-games-can-never-be-art
thinks that
https://en.wikipedia.org/wiki/Resident_Evil_(film)
is art and that
https://en.wikipedia.org/wiki/Resident_Evil_(2002_video_game)
is not. Roget Ebert disagrees about the class hierarchy, but
probably would agree with all of the properties asserted for both
"creative" works.
"Class first" thinking also tiles with other endemic forms of bad
ontology. For instance, many ontologists believe that a "well organized"
classification tiles everything into a tree. In some cases this is driven
by the linearization of the tree (as in the case of recent versions of the
Dewey Decimal system which have elaborate faceting in some areas) in other
cases (Foundational Model of Anatomy) it is a preference (which leaves the
"is a" property used for very different purposes such as defining what
kind of organ the kidney is but also defining the hierarchy of arteries
and veins that fan out from the heart.
It all sorta-kinda makes sense, except when you look close and see
that the classification of blood vessels into veins and arteries is not
true and in fact there are blood vessels that connect the
intestines/spleen/etc. to the liver as well as that connect the
hypothalamus to the pituitary that are not arteries or veins, even if
they are frequently called veins.
Trouble is, the FMA starts with the "vein", "artery" dichotomy and
that distorts the properties in place so there is not a consistent set of
properties that would let you follow a blood vessel from the heart, to
the digestive system, through the portal system, and ultimately back to
the heart. You get bad properties because of a bad classification.
At risk of sounding like Korzybski, I'd also say that "is a" is a
dangerous phrase. One trouble with it is that some people use it when
they want to say rdf:type, other people when they want to say
rdfs:subClassOf. It causes a certain amount of confusion for people, it
causes even more trouble when mixing these up causes your OWL reasoner to
run for a few hours to solve what you think is a simple problem (or that
would be a simple problem if you formulated it correctly.)
------ Original Message ------
From: jacc...@petrobras.com.br
To: "Sebastian Samaruga" <ssama...@gmail.com>
Cc: "DBpedia" <Dbpedia-discussion@lists.sourceforge.net>; "Sebastian
Hellmann" <hellm...@informatik.uni-leipzig.de>; "John Flynn" <
jflyn...@verizon.net>; "Paul Houle" <paul.ho...@ontology2.com>
Sent: 7/7/2017 2:11:05 PM
Subject: Re: [DBpedia-discussion] Call for Ontology Editor demos for
DBpedia
Yes, it is possible to define classes solely on the properties of the
subjects, following the philosophic view what a thing IS can only be
defined based on the properties that you can percieve in it. This may be
true, but is not useful. Yes, you can say that a Person has a birthDate,
but the definition of Person cannot rely solely on that, there are other
things such as Lion that have birthDates and such individuals do not
belong to the class Person. In other words, the domain of birthDate is not
Persons. Neither is it applicable to all living beings: what part of a
Frog or Butterfly lifeline is the 'birth'? When is a Tree "born"? Even in
humans there is a large debate regarding birth and conception -- when is
the gamete-ovum-embryo-fetus-baby "alive"? And what about the birth of
an era or the birth of a project? The domain to which the property
birthDate can be attached must be properly defined to avoid misuse of the
property. Bear in mind that DBpedia does have a class Birth, and it is a
subclass of PersonalEvent, so to be consistent, birthDate SHOULD be
applicable only to persons, and not to other animals. Property and domain
definitions are part of the ontology definition, and a lot of them are
lacking or inappropriately defined DBpedia's ontology. For example, the
property date has a correct range of xsd:date, but the domain is defined
as owl:Thing, which means anything may have a date. That is IMHO totally
wrong: the domain should be an event, not owl:Thing. However, dbo:Event is
not exactly a event in the proper time-continuum sense, since an the
dbPedia Event is not puntcual, but durative (e.g. a SportEvent may take
days, and a SpaceMission may take years. As I said before, it is not easy
to get everything right. It takes a lot of effort.
An ontology based solely on property aggregation is doomed to be an
ontology with bad definitions. It reminds me of the case of Plato's
definition of a human being as a featherless biped (based on its
properties), and the consequent rebate by Diogenes, who plucked the
feathers from a cock, brought it to Plato’s school, and said, ‘Here is
Plato’s man.’
Yes, such property-defined ontologies exist, mainly originated by automata
that aggregates related terms statistically, but you cannot rely just on
that to build a useful ontology. You need a Person to check if the result
makes sense, to be sure you are not making errors such as infering that
Band and Orchestra are equivalent classes because they have the same
properties. Sometimes the distinguishing feature is not mapped. (You may
argue that in this case you should have a single class MusicalGroup, but
that is another discussion, about granularity and abstract classes.)
Cheers.
=============================================
Marcelo Jaccoud Amaral
PETROBRAS
=============================================
=============================================
Marcelo Jaccoud Amaral
PETROBRAS
Tecnologia da Informação e Comunicações - Arquitetura (TIC/ARQSERV/ARQTIC)
user-id: bi70
ramal: 706-7507
tel: +55 (21) 2116-7507
=============================================
dum loquimur, fugetir invida aetas: carpe diem, quam minimum credula
postero.
-- Horatius
De: Sebastian Samaruga <ssama...@gmail.com>
Para: jacc...@petrobras.com.br
Cc: Paul Houle <paul.ho...@ontology2.com>, public-lod <
public-...@w3.org>, John Flynn <jflyn...@verizon.net>, Sebastian Hellmann
<hellm...@informatik.uni-leipzig.de>, DBpedia <
Dbpedia-discussion@lists.sourceforge.net>, semantic-web at W3C <
semantic-...@w3c.org>
Data: 2017-07-06 15:56
Assunto: Re: [DBpedia-discussion] Call for Ontology Editor demos
for DBpedia
Question: isn't it possible to 'aggregate' classes of subjects in respect
to the properties / predicates some set of subjects have in common.
Example: a Person class subjects would have 'birthPlace', 'birthDate' and
'name' properties and an Artist subclass would have those properties of
Person plus 'creatorOf' properties of artworks objects. So a superclass
would have a superset of the properties of a subclass.
Sorry for my ignorance. Best,
Sebastian.
On Jul 6, 2017 3:30 PM, <jacc...@petrobras.com.br> wrote:
Virtus in medium est.
I agree that by any standard, the DBpedia Ontology is messy, and needs
some work. Otherwise, it would be only a list of concepts with almost no
relations between them. These relations (the subconcept hierarchy and
other relevant relations defined by the authors of the ontology) need to
be there if the ontology is to be useful to something more than mere
documentation.
However, a well sound ontology needs a LOT of work, and the wider the
scope, the harder it is to get it right. Since DBpedia has no scope
boundaries, the amount of work to select a suitable foundational ontology
and expand it would be huge. No, I'm not quoting Trump, it is really huge.
What DBpedia needs is a few abstract notions without commitment to any
foundational ontology, since the tradeoffs each FO makes would hurt
DBpedia genericity. For example, different groups may fight years about an
exact definition of "Software", but most will agree it is a intelectual
product, such as a romance, a song or a theater play. The ontology should
reflect that, without getting in details about how software is encoded,
versioned, reified etc., since these details are important only to
applications dealing with the concept of software, and not for DBpedia
itself.
A few months ago, I complained that ComputerLanguage was not a subconcept
of Language, and it was promptly corrected, since it is very hard do
disagree with that. There are a lot of places where such refactoring is
needed, and I think it would help a lot. Further refining, such as
creating subclasses of ComputerLanguage, should be avoided in the name of
keeping the ontology simple and generic. Upper-level classes are needed to
sort things out, but one should also avoid defining things like
disjointness because it would lead to stuff like partition completeness
and other stuff which are clearly not needed for the purposes of DBpedia.
But I agree a cleanup is needed, since a lot of dbo:Things don't make much
sense.
Cheers.
=============================================
Marcelo Jaccoud Amaral
Petrobras, Brazil
=============================================
De: "Paul Houle" <paul.ho...@ontology2.com>
Para: "John Flynn" <jflyn...@verizon.net>, "'Sebastian Hellmann'" <
hellm...@informatik.uni-leipzig.de>, "'semantic-web at W3C'" <
semantic-...@w3c.org>, 'public-lod' <public-...@w3.org>, 'DBpedia' <
Dbpedia-discussion@lists.sourceforge.net>
Data: 2017-07-06 12:25
Assunto: Re: [DBpedia-discussion] Call for Ontology Editor demos
for DBpedia
I would disagree.
The DBpedia Ontology is not designed to support any specific kind of
reasoning.
What it *is* designed to do is capture the somewhat structured data that
exists in Wikipedia. Following the much misunderstood "semantic web",
the emphasis is on properties first, and then classes second. Think of
it as a set of baseball or Pokemon cards; the point is not to replicate
or even closely describe the performance or rules of the game, but to go
after the long hanging fruit of "things that are easy to ontologize."
There is a real price to pay for this; from the viewpoint of conventional
application development and introductory computer science, the data is
not always factually correct or satisfies the invariants required for a
particular algorithm. Practically that means that you might ask for "US
States" and get 48 or 51, that somebody like Barry Bonds or Mel Gibson
has their career much better represented than J. Edgar Hoover or J. Eric
S. Thompson, and you would probably find that the "tree of life" in
DBpedia is not really a tree.
If you need to reasoning in some domain you need to find some area you are
willing to pump the entropy out of, create the data structures
appropriate for what you want to do, and possibly incorporate data from
DBpedia, doing whatever cleanup is necessary. That's not different at
all from the situation of "doing reasoning over reasoning over data
collected by a large organization".
------ Original Message ------
From: "John Flynn" <jflyn...@verizon.net>
To: "'Sebastian Hellmann'" <hellm...@informatik.uni-leipzig.de>;
"'semantic-web at W3C'" <semantic-...@w3c.org>; "'public-lod'" <
public-...@w3.org>; "'DBpedia'" <Dbpedia-discussion@lists.sourceforge.net>
Sent: 7/5/2017 11:43:02 AM
Subject: Re: [DBpedia-discussion] Call for Ontology Editor demos for
DBpedia
I have long been curious about the DBpedia ontology structure so I just
took a look at the ontology represented in (
https://dl.dropboxusercontent.com/u/375401/dbo_no_mappings.nt) as
referenced in the email below.
I normally start the evaluation of an ontology by looking at the top-down
class relationships. So, I did a search for the classes that were listed
as a direct subclass of owl#Thing to get a general idea of the
organization of the DBpedia class structure.
To say the least, I was sorely disappointed. Here are a few of the DBpedia
classes that are direct subclasses of owl#Thing: Food, Media, Work,
Blazon, Altitude, Language, Currency, Statistic, Diploma, Award, Agent,
PublicService, Disease, GrossDomesticProdutPerCapita, ElectionDiagram,
Demographics, Relationship, Medicine, List, BioMolecule. I gave up after
this small sample. It is obvious that the DBpedia community needs to worry
a lot more about the structure of the ontology itself rather than focusing
on selecting a new editor. A working group needs to be established to go
back to the drawing board and look at the DBpedia ontology form the top
down. It certainly doesn't make much sense as it is currently structured.
John Flynn
http://semanticsimulations.com
From: Sebastian Hellmann [mailto:hellm...@informatik.uni-leipzig.de]
Sent: Wednesday, July 05, 2017 10:43 AM
To: 'semantic-web at W3C'; public-lod; DBpedia
Subject: [DBpedia-discussion] Call for Ontology Editor demos for DBpedia
Dear all,
we are preparing a switch from the mappings wiki (
http://mappings.dbpedia.org) to another ontology editor and started to
collect requirements/tools here:
https://docs.google.com/document/d/1HwtJJ3jIlrQAPwHYhvpw4a4Z4hZorTGaZTB8Bq8Y-TI/edit
We already have a demo for Webprotege thanks to Ismael Rodriguez, our GSoC
student. As we are lacking time and resources, we will probably only
consider editors with a running demo, so the community can try it.
Our main interest is of course to manage the DBpedia core ontology and
push any mappings to other ontologies in separate files. So we provide a
core version for demo purposes created with:
rapper -g dbpedia_2016-10.nt | grep -v '\(
http://schema.org\|http://www.wikidata.org\|http://www.ontologydesignpatterns.org\
)' > dbo_no_mappings.nt
https://dl.dropboxusercontent.com/u/375401/dbo_no_mappings.nt
(I hope that the regex didn't kick out anything essential or broke any
axioms...)
We would be very happy, if anyone from the semantic web community would
make a demo with their favorite editor and add a link to the Google Doc
and post a short message on the DBpedia discussion list[1] or on slack
https://dbpedia.slack.com/.
This would help us to make a more informed decision. The next DBpedia Dev
online meeting will be on 2nd of August 14:00 (each first Wednesday per
month). Presentations of editors are also welcome. We will also discuss
the editor question during the DBpedia meeting in Amsterdam, co-located
with SEMANTiCS on 14.9. http://wiki.dbpedia.org/meetings/Amsterdam2017
Thank you for your help!
[1] https://sourceforge.net/projects/dbpedia/lists/dbpedia-discussion
--
All the best,
Sebastian Hellmann
Director of Knowledge Integration and Linked Data Technologies (KILT)
Competence Center
at the Institute for Applied Informatics (InfAI) at Leipzig University
Executive Director of the DBpedia Association
Projects: http://dbpedia.org, http://nlp2rdf.org,
http://linguistics.okfn.org, https://www.w3.org/community/ld4lt
Homepage: http://aksw.org/SebastianHellmann
Research Group: http://aksw.org
------------------------------------------------------------------------------
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
"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."
"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."[anexo "att696od.jpg" removido por Marcelo Jaccoud
Amaral/BRA/Petrobras]
"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
