I can throw away parts of any ontology and still keep the instance data so that doesn't distinguish the DBpedia ontology from other ontologies. Maybe DBpedia is distinuished from other data sources in that in the data each individual is an instance of only one class (or precisely one class and its ancestors). But that's not a big distinction - I can remove redundant instance relationships from other data sources as well.
I don't see that religious organizations are particularly difficult. Many other entities have a similar multiple views, for example a park as a geographical area vs a park as an administrative unit. The (a?) problem with monastery in DBpedia is that it is a subclass of building. However, the physical extent of a monastery is generally not a single building or even a group of buildings but is instead a geographical extent (complex in the DBpedia English comment on monastery) containing buildings. So there is a contradiction between the English description of monastery in DBpedia and its superclass building. As well, many monasteries in DBpedia are not buildings but are instead complexes of buildings. peter On 07/14/2017 10:04 AM, Paul Houle wrote: > Big picture is that that the DBpedia Ontology itself is small and you can > throw part of it or all if it away but still keep the instance data. > > Religious organizations and structures are particularly problematic because of > the conflict between the "geo-spatial" view in which a church building is a > "place of interest" vs a "spiritual community" both in the sense as an > organization you might want to join, sell something to, etc. and to address > the question of why somebody would go to a church. > > That is, a "church" can well be an Islamic Center that meets at some random > commercial space while it saves up money to buy a mosque, or a coven that > meets in the woods, a church that meets in the basement of some other > church, etc. > > This kind of thinking is central to differences religionists have in their > thinking such that some organizations build elaborate spaces that "look like a > church" while you see some other churches that are plain, even spartan > because they they think it is what is in your heart that counts, or adherence > to doctrine, etc. > > It is definitely not an area you will get complete agreement on! > > ------ Original Message ------ > From: "Peter F. Patel-Schneider" <pfpschnei...@gmail.com> > To: "Sebastian Hellmann" <hellm...@informatik.uni-leipzig.de> > Cc: "DBpedia" <Dbpedia-discussion@lists.sourceforge.net> > Sent: 7/14/2017 12:31:40 PM > Subject: Re: [DBpedia-discussion] Purpose of the DBpedia Ontology was Re: Call > for Ontology Editor demos for DBpedia > >> On 07/11/2017 03:10 PM, Sebastian Hellmann wrote: >>> Hi all, >>> >>> DBpedia has always had a firm founding in engineering and we should see the >>> whole thing as an "information machine". From this perspective the purpose >>> of >>> the DBpedia Ontology becomes quite clear: >>> >>> - Usability for queries - driven by the question, what do our users want to >>> retrieve? >> >> As a user I would like to not retrieve false information. (I realize that if >> there is false information in DBpedia that comes from Wikipedia there is >> little that can be done.) However, I don't want the DBpedia ontology to >> cause >> extra falsities. This means, for example, that monastery should not be a >> subclass of building. >> >>> - Data transformation and hubbing: subClassOf/subProperty linking to other >>> ontologies allows to export information into other schemas without much >>> ontological committment >> >> Relying only on links between co-extensional classes is inadequate so using >> inclusion relationships is better. However, it would be useful to be able to >> say that a DBpedia class is more general than a class from other ontology, >> not >> just that it is more specific. >> >>> - Data Quality: in my opinion data quality increases a lot if every person >>> was >>> to have a birthDate, so this can be defined as a goal. We are at around 60% >>> right now. Another goal would be to validate the correctness by >>> cross-referencing data, e.g. to German National Library. So the ontology >>> should directly produce a system that can help us track what data is >>> missing. >>> SHACL provides us with a new modeling paradigm and we will make a call for >>> SHACL specs of DBpedia applications to get concrete input for DBpedia's >>> ontology. We are still discussing internally where to keep them. GitHub >>> seems >>> like a good option. >> >> I don't see this as a viable goal. Sure, getting more data (out of >> Wikipedia) >> is useful, but Wikipedia isn't designed to be complete in this way. >> Further, >> some data, including birthdates, is always going to be incomplete. The >> birthdates of some historical figures are currently unknown and some of these >> are likely never to be known. >> >> Given that this is the case, what should be done instead? My view is that >> systems like DBpedia should be accepting of incomplete data. Further, they >> should provide facilities to get as much as possible out of incomplete data. >> For example, it should be possible to state that some person belongs to the >> class of people born in the seventeenth century without knowing their exact >> birthdate. >> >>> - minimal foundation: Time, Place, maybe Events and a few top classes >>> should >>> provide enough structure to build a consistent system. >> >> This is verging close to mandating a very simple upper ontology. I'm not >> against upper ontologies but it is possible to go too far along this route. >> >> On the other hand, the top level of the current ontology is a mess. I've >> toyed with trying to fix this, but the needs to be some guidelines before >> starting on radical changes to the DBpedia ontology. (Yes, I've also thought >> about what could be in these guidelines.) >> >>> There are many extra >>> ontologies like LHD, DBTax, Yago, etc. that can all be sorted under these >>> then. We might even resort (please don't see it as a threat) to SKOS maybe >>> for >>> roles or build a separate vocabularies, that can be used as mixins, i.e. >>> <Peter> a dbo:Person ; dbo:occupation dbo:Actor . # dbo:Actor as instance. >>> This might also be dbr:Actor , i.e. referencing the Wikipedia Article. >>> Given >>> that Wikipedia is so heterogeneous in its article types, we can help with >>> building a structure that distinguishes between Individual articles, i.e. >>> Barrack Obama and Categorial / Role-type articles, i.e. >>> https://en.wikipedia.org/wiki/Actor . Such information can be taken from >>> text, >>> which is why we are building up http://wiki.dbpedia.org/textext >>> >>> 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. >> >> How about person born in the seventeenth century, mentioned above? >> >> Why disallow subclasses of Person in particular? Is there anything special >> about Person? Instead there should be a rationale for designating a class >> as >> terminal in this way. >>> 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. >> >> This is a thorny problem. However, spouse is probably not a good case. >> There >> are very many more than a dozen people in the world (and probably quite a few >> more than a dozen people in Wikipedia) with more than one spouse. The >> functionality of spouse is an artifact of a particular society (unless you >> are >> limiting spouse to that particular society). >> >> Perhaps a better example is (biological) father for people. Nearly all >> people >> have only one recorded father. Exceptions come from at least two sources - >> recording both biological father and legal father and mythological beings who >> have different fathers in different accounts. Nevertheless it is useful to >> state that father is functional. >> >> What then to do about spouse? I'm not sure. >> >>> All the best, >>> Sebastian >> >> >> 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 > ------------------------------------------------------------------------------ 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
