Hi Sebastian, On 01.06.2016 13:07, Sebastian Hellmann wrote: > Hi Markus, > > On 01.06.2016 12:58, Markus Kroetzsch wrote: >> On 01.06.2016 10:46, Sebastian Hellmann wrote: >>> https://en.wikipedia.org/wiki/Unique_name_assumption >> >> The UNA is a principle in formal logic and knowledge representation. >> It is not really related to this discussion. For example, standard >> DBMS all make the UNA, but you can still have many identifiers (keys) >> for the same object in a database. > > Then the database does not use UNA. The above sentence reads like you > could have two primary keys, but then still have them pointing to the > same row. > UNA means, if you have two identifiers A, B you add a triple A > owl:differentFrom B at all times.
I don't think that this mixing of different notions is making much sense. Every SPARQL processor under simple semantics makes the UNA, while RDF and OWL entailment regimes for SPARQL do not make it. This has nothing to do with how you model concepts and their IDs in your domain. You can have the same data and use it in different SPARQL tools, sometimes with a UNA sometimes without, but your choice of modelling identifiers is not affected by that. Markus >> The explanation is that UNA refers to the internal interpretation of >> symbols in the database, whereas the outside, user-level notions of >> "identifier" and "concept" may be represented in a database by many >> symbols and their relationships. >> >> Markus >> >>> >>> On 01.06.2016 10:02, Markus Kroetzsch wrote: >>>> Re "a concept cannot have multiple IDs": >>>> >>>> There seems to be some major misconception underlying the below email. >>>> It is certainly not the case that identifiers must be unique by >>>> definition. Every identifier must identify a unique object, but a >>>> single >>>> object can have multiple identifiers. This is standard meaning of >>>> "identifier" applies to URIs just as well as to IDs in databases and >>>> all >>>> kinds of other areas. >>>> >>>> Requiring that every concept can only be identified in one way would >>>> make things very hard in decentralised data ecosystems such as LOD. In >>>> fact, it would already cause problems in individual databases, which >>>> often need to merge identifiers as they improve over time (e.g., >>>> MusicBrainz Ids 2ca98ac1-62f0-4cdc-89ad-9d4b7602440a and >>>> 6a10f49d-e7db-40d3-a348-bbd5717ebbbe refer to the same concept). >>>> >>>> Cheers, >>>> >>>> Markus >>>> >>>> On 31.05.2016 17:53,jacc...@petrobras.com.br wrote: >>>>> Clarifying: >>>>> >>>>> The function of an ID (identifier) is to identity a concept, not to >>>>> describe it. So they must be unique by definition, a concept can not >>>>> have multiple IDs . Multiple concepts may be equivalent to one >>>>> another, >>>>> but that doesn't mean they are the same. If you have two different IDs >>>>> (i.e. the Unicode comparison of the strings results in mismatch) you >>>>> have by definition two different concepts. That is not what you want. >>>>> You want multiple labels for the same concept/ID. >>>>> >>>>> The description of a concept (or definition, philosophically speaking) >>>>> is the whole group of other properties you ascribe to the concept by >>>>> referencing its ID, including as may human readable labels as you need >>>>> and relations to other concepts. You can choose to use an automatic >>>>> generated ID in order to guarantee uniqueness or use manually ascribed >>>>> human readable strings, but with the later you must guarantee the >>>>> uniqueness by process (as is the case with DBpedia IDs, which are >>>>> derived from Wikipedia IDs). >>>>> >>>>> It is not a RDF requirement for the IRIs to be simple (although that >>>>> saves parsing time) or human readable, but they MUST be unique and >>>>> stable, otherwise the identity of the concept is compromised. Human >>>>> readable IDs are only helpful in manual edition of files, which >>>>> happens >>>>> only in examples and didactic purposes. Real world IDs are mostly >>>>> UUIDs >>>>> (universally unique IDs) generated by the system (for Java, see >>>>> java.util.UUID ). Some systems use prefixed URLs in order to embed >>>>> provenance into the ID, but that is a very, very bad practice: >>>>> provenance is metadata as any other, you should use specific >>>>> properties >>>>> for that. IDs were not designed to provide any other semantics besides >>>>> identity. >>>>> >>>>> Cheers. >>>>> ============================================= >>>>> Marcelo Jaccoud Amaral >>>>> PETROBRAS >>>>> Tecnologia da Informação e Comunicações - Arquitetura Tecnológica >>>>> (TIC/ARQTIC/AT) >>>>> ============================================= >>>>> dum loquimur, fugetir invida aetas: carpe diem, quam minimum credula >>>>> postero. >>>>> -- Horatius >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> De: Katie Frey<kf...@cfa.harvard.edu> >>>>> Para: Markus Kroetzsch<markus.kroetz...@tu-dresden.de> >>>>> Cc: "DBpedia Discussion >>>>> \(ML\)"<dbpedia-discussion@lists.sourceforge.net> >>>>> Data: 2016-05-31 11:50 >>>>> Assunto: Re: [Dbpedia-discussion] Concept Identifiers >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> Dear Markus, >>>>> >>>>> Thank you for the insight. We might also try to assign both >>>>> numeric and >>>>> descriptive IDs to a concept. It seems as though best practices don't >>>>> really exist in this area, other than the general imperative to >>>>> keep the >>>>> URIs simple and as stable as possible. >>>>> >>>>> Best, >>>>> Katie >>>>> <https://www.wikidata.org/entity/Q544> >>>>> >>>>> -- >>>>> Katie E. Frey >>>>> John G. Wolbach Library, Harvard-Smithsonian Center for Astrophysics >>>>> 60 Garden Street, MS-56, Cambridge, MA 02138 >>>>> email: _kfrey@cfa.harvard.edu_<mailto:kf...@cfa.harvard.edu>| phone: >>>>> 617-496-7579_ >>>>> __http://astrothesaurus.org_ <http://astrothesaurus.org/> | >>>>> _http://library.cfa.harvard.edu/_ >>>>> >>>>> "Surprising what you can dig out of books if you read long enough, >>>>> isn’t >>>>> it?" >>>>> - Rand al'Thor (in Robert Jordan's The Shadow Rising, Book Four of the >>>>> Wheel of Time) >>>>> >>>>> "This is insanity!" "No, this is scholarship!" >>>>> - Yalb and Shallan (in Brandon Sanderson's Words of Radiance, Book Two >>>>> of the Stormlight Archive) >>>>> >>>>> On Thu, May 26, 2016 at 4:06 PM, Markus Kroetzsch >>>>> <_markus.kroetzsch@tu-dresden.de_ >>>>> <mailto:markus.kroetz...@tu-dresden.de>> wrote: >>>>> Dear Katie, >>>>> >>>>> DBpedia mostly uses descriptive URIs that are based on the titles of >>>>> Wikipedia articles in a specific language. These URIs change if pages >>>>> are renamed, but for many concepts, this does not occur so often. You >>>>> would probably only notice it if you are using the URIs for several >>>>> years. >>>>> >>>>> If you instead want to use numeric IDs based on Wikipedia pages (or >>>>> DBpedia URIs), you can take them from Wikidata. These IDs are stable, >>>>> but not descriptive. They are kept unique in that they can only be >>>>> deleted but not reused. For example, >>>>> _http://dbpedia.org/page/Solar_System_is currently the same as_ >>>>> __https://www.wikidata.org/entity/Q544_. >>>>> >>>>> The Wikidata URI uses content negotiation to redirect you to the HTML >>>>> page if you open it in a browser, and to RDF if you open it with an >>>>> RDF >>>>> crawler. See _https://www.wikidata.org/wiki/Wikidata:Data_access_for >>>>> direct links to the RDF content. >>>>> >>>>> To manually find out what the Wikidata ID is for a Wikipedia page, you >>>>> can go to the Wikipedia page and use the link to "Wikidata item" on >>>>> the >>>>> left. To do this in an automated fashion, you can use the SPARQL >>>>> endpoint, e.g., with the query >>>>> >>>>> SELECT * >>>>> WHERE { >>>>> <_https://en.wikipedia.org/wiki/Solar%20System_> schema:about >>>>> ?item . >>>>> } >>>>> >>>>> (try it in the Wikidata SPARQL UI: _http://tinyurl.com/jlk4fz2_) >>>>> >>>>> The Wikidata Web API can also map page titles to IDs for you prefer >>>>> JSON >>>>> over SPARQL: >>>>> _ >>>>> __https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&sites=enwiki&titles=Solar+System&props=_ >>>>> >>>>> >>>>> Each of these methods can also be used to fetch many IDs at once. So >>>>> basically it is fairly straightforward to translate from DBpedia >>>>> URIs to >>>>> Wikidata URIs. The mapping between the two changes over time only when >>>>> DBPedia URIs change their meaning (e.g., if "Solar System" is >>>>> renamed to >>>>> "Solar System (astronomy)" or something). >>>>> >>>>> Best regards, >>>>> >>>>> Markus >>>>> >>>>> >>>>> >>>>> On _26.05.2016 20_ <tel:26.05.2016%2020>:43, Katie Frey wrote: >>>>> Hello, >>>>> >>>>> How are concept IDs handled for DBpedia? It looks like the concept >>>>> URIs >>>>> are descriptive (i.e. for the concept_ >>>>> __http://dbpedia.org/page/Solar_System_, the concept ID is >>>>> "Solar_System"). Are the descriptive IDs used throughout all of >>>>> dbpedia >>>>> (back and front end) or are terms ultimately kept unique by using >>>>> numeric identifiers? >>>>> >>>>> I've been developing a controlled vocabulary and I would also like to >>>>> use URIs so that my terms can be used with other linked data schemes. >>>>> My group and I have had a lot of discussions regarding the concept >>>>> IDs; >>>>> some want them to be descriptive, based on the preferred term for each >>>>> concept so that they are human readable but this could cause >>>>> problems if >>>>> the terms used to describe each concept change over time, others want >>>>> them to be randomly generated so that if the description of a term >>>>> drifts over time the URI for the concept will always remain static. >>>>> >>>>> We are trying to figure out if there are any standards or best >>>>> practices >>>>> we should be looking towards when it comes to concept IDs. Any >>>>> thoughts/comments/justifications would be appreciated. >>>>> >>>>> Best, >>>>> Katie >>>>> >>>>> -- >>>>> Katie E. Frey >>>>> John G. Wolbach Library, Harvard-Smithsonian Center for Astrophysics >>>>> 60 Garden Street, MS-56, Cambridge, MA 02138 >>>>> email: _kfrey@cfa.harvard.edu_ >>>>> <mailto:kf...@cfa.harvard.edu><mailto:_kfrey@cfa.harvard.edu_ >>>>> <mailto:kf...@cfa.harvard.edu>> | phone:_ >>>>> __617-496-7579_ <tel:617-496-7579> <tel:_617-496-7579_ >>>>> <tel:617-496-7579>>_ >>>>> __http://astrothesaurus.org_ <http://astrothesaurus.org/> | >>>>> _http://library.cfa.harvard.edu/_ >>>>> >>>>> "Surprising what you can dig out of books if you read long enough, >>>>> isn’t >>>>> it?" >>>>> - Rand al'Thor (in Robert Jordan's The Shadow Rising, Book Four of the >>>>> Wheel of Time) >>>>> >>>>> "This is insanity!" "No, this is scholarship!" >>>>> - Yalb and Shallan (in Brandon Sanderson's Words of Radiance, Book Two >>>>> of the Stormlight Archive) >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Mobile security can be enabling, not merely restricting. Employees who >>>>> bring their own devices (BYOD) to work are irked by the imposition >>>>> of MDM >>>>> restrictions. Mobile Device Manager Plus allows you to control only >>>>> the >>>>> apps on BYO-devices by containerizing them, leaving personal data >>>>> untouched!_ >>>>> __https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_ >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Dbpedia-discussion mailing list_ >>>>> __Dbpedia-discussion@lists.sourceforge.net_ >>>>> <mailto:Dbpedia-discussion@lists.sourceforge.net>_ >>>>> __https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion_ >>>>> >>>>> >>>>> -- >>>>> Markus Kroetzsch >>>>> Faculty of Computer Science >>>>> Technische Universität Dresden_ >>>>> __+49 351 463 38486_ <tel:%2B49%20351%20463%2038486>_ >>>>> __http://korrekt.org/_ >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> What NetFlow Analyzer can do for you? Monitors network bandwidth >>>>> and traffic >>>>> patterns at an interface-level. Reveals which users, apps, and >>>>> protocols >>>>> are >>>>> consuming the most bandwidth. Provides multi-vendor support for >>>>> NetFlow, >>>>> J-Flow, sFlow and other flows. Make informed decisions using capacity >>>>> planning reports. >>>>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_______________________________________________ >>>>> >>>>> 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." >>> >>> -- >>> All the best, >>> Sebastian Hellmann >>> >>> AKSW/KILT research group at Leipzig University >>> Insitute for Applied Informatics (InfAI) at Leipzig University >>> DBpedia Association >>> Events: >>> * *April 24, 2016* Submission Deadline, SEMANTiCS 2016: Workshop & >>> Tutorial Proposals >>> <https://docs.google.com/document/d/1VOWyU9Oo2KOuRh09R9CJeC9aWcSNokDW4yHeuGHICPI/pub> >>> >>> * *May 10th, 2016* Submission Deadline, SEMANTiCS 2016: Research & >>> Innovation Papers >>> <https://docs.google.com/document/d/1bYXVeO-vWwIctJgDv4rS3H5oFv0Yz_tyTo0xQcAEtPU/pub> >>> >>> * *Sep 12th-15th, 2016* SEMANTiCS 2016, Leipzig <http://semantics.cc/> >>> Venha para a Alemanha como PhD: http://bis.informatik.uni-leipzig.de/csf >>> Projects: http://dbpedia.org, http://nlp2rdf.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 >>> Thesis: >>> http://tinyurl.com/sh-thesis-summary >>> http://tinyurl.com/sh-thesis >> > > -- > All the best, > Sebastian Hellmann > > AKSW/KILT research group at Leipzig University > Insitute for Applied Informatics (InfAI) at Leipzig University > DBpedia Association > Events: > * *April 24, 2016* Submission Deadline, SEMANTiCS 2016: Workshop & > Tutorial Proposals > <https://docs.google.com/document/d/1VOWyU9Oo2KOuRh09R9CJeC9aWcSNokDW4yHeuGHICPI/pub> > * *May 10th, 2016* Submission Deadline, SEMANTiCS 2016: Research & > Innovation Papers > <https://docs.google.com/document/d/1bYXVeO-vWwIctJgDv4rS3H5oFv0Yz_tyTo0xQcAEtPU/pub> > * *Sep 12th-15th, 2016* SEMANTiCS 2016, Leipzig <http://semantics.cc/> > Venha para a Alemanha como PhD: http://bis.informatik.uni-leipzig.de/csf > Projects: http://dbpedia.org, http://nlp2rdf.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 > Thesis: > http://tinyurl.com/sh-thesis-summary > http://tinyurl.com/sh-thesis -- Markus Kroetzsch Faculty of Computer Science Technische Universität Dresden +49 351 463 38486 http://korrekt.org/ ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Dbpedia-discussion mailing list Dbpedia-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
