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 <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 <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\
<http://schema.org/%7Chttp:/www.wikidata.org/%7Chttp:/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://dbpedia.org/>, http://nlp2rdf.org
<http://nlp2rdf.org/>, http://linguistics.okfn.org
<http://linguistics.okfn.org/>, https://www.w3.org/community/ld4lt
<http://www.w3.org/community/ld4lt>
Homepage: http://aksw.org/SebastianHellmann
Research Group: http://aksw.org
<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."
------------------------------------------------------------------------------
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
