I must admit I find this discussion fascinating.
As far as I understand, Sebastian H. proposes NOT to materialize the types
in the DB.
So (what I call) service implementors (or call them SPARQL authors, if you
want) will specialize their query by first matching a set of qualifying
properties that THEY consider to be relevant.
So basically service implementors manage their own type system via a
subpart the of their query instead of letting the DB modelers decide for
them.
Le jeu. 13 juil. 2017 Ã 15:57, Sebastian Samaruga <***@gmail.com> a
écrit :
> Regarding typing by the properties of aggregated subjects / objects:
> domain / range having these properties or values for those properties
> (meta-types, I call them 'kinds') I see no trouble in inferring inheritance
> hierarchies being sub-classes a superset of the properties of parent
> classes properties. Once the inference is done (curated) there should be no
> problem in materializing (dinamically?) into RDFS / OWL, maybe via XSLT.
>
> Draft here:
> https://docs.google.com/document/d/1OqsVn6uo0cr6qruzWj9yRASrmvAIAf4HsHuLS2aRSy8/edit?usp=drivesdk
>
> And here:
> https://docs.google.com/document/d/1VrvIV4rXyUyGl5jvDAgsEV4GRxX_NvMICgkdnbvj9DQ/edit?usp=drivesdk
>
> Regards,
> Sebastián.
> On Jul 13, 2017 2:55 AM, "Olivier Rossel" <***@gmail.com>
> wrote:
>
>> Once again, I will give you my opinion, as the service implementor of
>> search.datao.net.
>>
>> search.datao.net is a lookup service where you type the label of a
>> resource, retrieve from an internal DB all the resources of the
>> LinkedData with such a label (+their type and endpoint), and then
>> lookup all the queries stored in Datao that can be applied upon those
>> resources.
>>
>> The queries lookup step matches the types and endpoint of the found
>> resources vs the types and endpoint in the queries stored in Datao.
>>
>> Simply said, I heavily rely upon the types of the resources in the
>> LinkedData (both when indexing in the internal DB, and during the
>> lookup for applicable queries).
>>
>> If you change the typing in DBPedia, there are critical consequences
>> for my service.
>>
>> As far as I understand, you want to go from ineritance to (some kind
>> of) composition to precisely define a given Person instance.
>>
>> That sounds like an very interesting move from a conceptual level.
>>
>> But practically, from my own perspective as a service implementor,
>> this has enormous impacts.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 12, 2017 at 1:04 AM, <***@petrobras.com.br> wrote:
>> > Sebastian Hellmann <***@informatik.uni-leipzig.de> wrote on
>> 2017-07-11
>> > 19:10:03:
>> >> 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.
>> >
>> > Child, Teenager and Adult come to mind, but these could also be seen as
>> > phases of Person and would require timely updating. It's the problem we
>> have
>> > with roles. Possible but not practical. In the past, Man and Woman were
>> > natural subclasses, but since we have the property dbo:sex, it is not
>> worth.
>> >
>> > Since subclassing Person would mean referring to a minority, the
>> politically
>> > correct people would be against ANY subclass... :-)
>> >
>> > There are some sensible subclasses, like Celebrity, but Persons which
>> appear
>> > on Wikipedia are all Celebrities, so this would be also useless.
>> >
>> > I am inclined to agree with you that we could cover any situation with
>> > proper properties (pun intended), even fictitious/non-fictitious. Which
>> > would exclude the need for Cyborg and other strange classes with no
>> actual
>> > instances outside fiction.
>> >
>> >
>> > Marcelo Jaccoud Amaral
>> >
>> >
>> >
>> >
>> > Sebastian Hellmann <***@informatik.uni-leipzig.de> gravou em
>> 2017-07-11
>> > 19:10:03:
>> >
>> >> De: Sebastian Hellmann <***@informatik.uni-leipzig.de>
>> >> Para: ***@petrobras.com.br, Paul Houle <***@ontology2.com>
>> >> Cc: DBpedia <Dbpedia-***@lists.sourceforge.net>, John Flynn
>> >> <***@verizon.net>, Sebastian Samaruga <***@gmail.com>
>> >> Data: 2017-07-11 19:10
>> >> Assunto: Purpose of the DBpedia Ontology was Re: [DBpedia-
>> >> discussion] Call for Ontology Editor demos for DBpedia
>> >>
>> >> 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?
>> >> - Data transformation and hubbing: subClassOf/subProperty linking to
>> >> other ontologies allows to export information into other schemas
>> >> without much ontological committment
>> >> - 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.
>> >>
>> >> - minimal foundation: Time, Place, maybe Events and a few top
>> >> classes should provide enough structure to build a consistent
>> >> system. 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.
>> >>
>> >> 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
>> >>
>> >
>> >> On 10.07.2017 18:24, ***@petrobras.com.br wrote:
>> >> 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" <***@ontology2.com>
>> >> Para: ***@petrobras.com.br, "Sebastian Samaruga"
>> >> <***@gmail.com>
>> >> Cc: DBpedia <Dbpedia-***@lists.sourceforge.net>,
>> >> "Sebastian Hellmann" <***@informatik.uni-leipzig.de>, "John
>> Flynn"
>> >> <***@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: ***@petrobras.com.br
>> >> To: "Sebastian Samaruga" <***@gmail.com>
>> >> Cc: "DBpedia" <Dbpedia-***@lists.sourceforge.net>; "Sebastian
>> >> Hellmann" <***@informatik.uni-leipzig.de>; "John Flynn" <
>> >> ***@verizon.net>; "Paul Houle" <***@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 <***@gmail.com>
>> >> Para: ***@petrobras.com.br
>> >> Cc: Paul Houle <***@ontology2.com>, public-lod <
>> >> public-***@w3.org>, John Flynn <***@verizon.net>, Sebastian
>> Hellmann
>> >> <
>> >> ***@informatik.uni-leipzig.de>, DBpedia <Dbpedia-
>> >> ***@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, <***@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" <***@ontology2.com>
>> >> Para: "John Flynn" <***@verizon.net>, "'Sebastian
>> Hellmann'" <
>> >> ***@informatik.uni-leipzig.de>, "'semantic-web at W3C'" <
>> >> semantic-***@w3c.org>, 'public-lod' <public-***@w3.org>, 'DBpedia' <
>> >> Dbpedia-***@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" <***@verizon.net>
>> >> To: "'Sebastian Hellmann'" <***@informatik.uni-leipzig.de>;
>> >> "'semantic-web at W3C'" <semantic-***@w3c.org>; "'public-lod'" <
>> >> public-***@w3.org>; "'DBpedia'" <
>> Dbpedia-***@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:***@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-***@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."
>> >>
>> >> --
>> >> 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[anexo "lnleobnaofjmkfjh.png"
>> >> 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-***@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-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>
>