- From: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Date: Fri, 10 Jan 2014 19:44:40 +0100
- To: janowicz@ucsb.edu, Sven Schade <sven.schade@jrc.ec.europa.eu>, public-locadd@w3.org
- CC: 'Pascal Hitzler' <pascal.hitzler@wright.edu>
Hello Krzysztof, > maybe we can ask the question the other way around: Why would you prefer > to reuse single relation and class names from different sources? First, as I have already stated (I hope clearly) in other emails, I have no strong opinions for always choosing one way (re-use terms) or the other (create new terms, mint new URIs, and add axioms). I actually strongly believe that both are necessary depending on the use case and that there is (arguably) a large blurred zone that we are now discussing. This is because some have expressed opinions that we should nearly _always_ do one way that I'm reacting. Second, I'm all for fighting against this obesity of creating systematically new classes and properties when this is not necessary. Not all triple stores / knowledge bases are saturated with possible inferences based on provided axioms. If you don't provide axioms then you rely on ontology matching tools to find correspondences while this conceptual work might have already been made by the person who provided the vocab. Maintaining axioms can have costs, in particular when terms usage evolve. Etc. So yes, I'm in favor or re-using terms rather than redefining when clearly, one wants to express the same thing. > This will force you to import many vocabularies/ontologies which will > create unintended logical consequences. You have to define what do you mean by "import". And you should not worry about those unintended logical consequences or please, provide me with concrete examples of "unintended logical consequences" following the re-use of terms from the top 10 LOD vocabularies (generally small, with few axioms, but largely re-used) to back up this "fear". > Additionally, you really do not > know whether those relations and classes are really the same. Let's be pragmatic ... we are not talking about re-using terms from a vocabulary made by a PhD student on a table, but from widely used vocabularies, which have been published following good practices, with usage notes, for which the maintainer and the community are known and can provide vast amount of experience. > Sven is not saying you should redo everything from scratch (e.g., your > own GeoSPARQL) but making a standard that imports single relations and > classes from multiple sources and hoping that they somehow stick > together seems odd to me. No. This discussion starts with the simple problem of finding an adequate property for representing a geographic identifier and the problem of re-using an existing property or creating a new one. Full stop. > For instance, I would be very surprised if the US government would give > up their own schema and use FAOF to annotate Persons. This is out of scope of this discussion. > Given Svens position at JRC, I guess this is his daily business. From my > perspective. We are currently working with the biggest existing GIS > company and they do not like the idea of using other ontologies that > they cannot control. Another example is schema.org. Just to make sure I understand: the argument is taste ('Like') or keeping control, right? Do those guys plan to expose their vocabulary? Do they expect other people to re-use their vocabulary? > Again, Pascal's, Sven's and my arguments are not to redo everything from > scratch but to have a precise and locally meaningful vocabulary and then > link out instead of just having a collection of pointers to other > namespaces. Nobody is saying this. Let's go back to the original problem of this thread: geographical identifier. Best regards. Raphaël -- Raphaël Troncy EURECOM, Campus SophiaTech Multimedia Communications Department 450 route des Chappes, 06410 Biot, France. e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com Tel: +33 (0)4 - 9300 8242 Fax: +33 (0)4 - 9000 8200 Web: http://www.eurecom.fr/~troncy/
Received on Friday, 10 January 2014 20:12:03 UTC