http://ontologydesignpatterns.org/api.php?action=feedcontributions&feedformat=atom&user=MichaelUschold 2026-05-04T23:32:16Z User contributions MediaWiki 1.25.6 http://ontologydesignpatterns.org/index.php?title=User:Kerekestunde&diff=9608 2010-05-25T06:45:26Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=kerekes<br /> |LastName=tunde<br /> |Gender=Female<br /> |Organization=de clars<br /> |OrganizationType=Educational Training and Research Institution<br /> |OrganizationWebSite=http://declars.com<br /> |Country=Switzerland (CH)<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Using ODP account to dmoz.org<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:Dianabelluno&diff=9606 2010-05-25T06:44:52Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=diana<br /> |LastName=belluno<br /> |Organization=gigi srl<br /> |OrganizationType=EU System Programme or Agency<br /> |Country=Italy (IT)<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=upload ontologies<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:CarlosS%E1&diff=9597 2010-05-06T22:31:51Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Carlos<br /> |LastName=Sá<br /> |Gender=Male<br /> |Organization=FEUP<br /> |OrganizationType=Educational Training and Research Institution<br /> |Country=Portugal (PT)<br /> |Role=Student<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=to learn more about Ontology design patterns<br /> |PossibleMainContribution=To have some help to solve modeling problems<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:PaolaDiMaio&diff=9592 2010-05-03T21:05:01Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Paola<br /> |LastName=Di Maio<br /> |Gender=Female<br /> |Organization=ISTCS,ORG<br /> |OrganizationType=Professional Organization<br /> |OrganizationWebSite=http://WWW.ISTCS,ORG<br /> |Country=United Kingdom United Kingdom (GB)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Have created a pattern, would like to publish it<br /> |DomainsOfInterest=knowledge management, systems engineering<br /> |HowDidIKnowAbout=colleagues<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:HuiminZHU&diff=9587 2010-04-22T22:57:58Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=huimin<br /> |LastName=ZHU<br /> |Gender=Female<br /> |Organization=the university of southampton<br /> |OrganizationType=Educational Training and Research Institution<br /> |Country=United Kingdom United Kingdom (GB)<br /> |Role=Student<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=learning<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:JacsonBarros&diff=9585 2010-04-21T00:44:27Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Jacson<br /> |LastName=Barros<br /> |Gender=Male<br /> |Organization=Research on Research Group, USA<br /> |OrganizationType=Educational Training and Research Institution<br /> |Country=Brazil (BR)<br /> |Role=PhD Student<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=My project linking healthcare databases among themselves and then with linked data linkeddata.org/. Using ontologies.<br /> |HowDidIKnowAbout=colleagues<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:AndrewFarrow&diff=9583 2010-04-20T18:28:27Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Andrew<br /> |LastName=Farrow<br /> |Gender=Male<br /> |Organization=Rightscom Ltd<br /> |OrganizationType=Professional Organization<br /> |Country=United Kingdom United Kingdom (GB)<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Track current thinking<br /> |HowDidIKnowAbout=colleagues<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:FrederikGailly&diff=9581 2010-04-19T02:13:41Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Frederik<br /> |LastName=Gailly<br /> |Gender=Male<br /> |HomePage=http://www.managementinformation.ugent.be/frederikgailly.html<br /> |Organization=Ghent University<br /> |OrganizationType=Educational Training and Research Institution<br /> |OrganizationWebSite=http://www.ugent.be<br /> |Country=Belgium (BE)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=One of my research topics is the ontology reengineering of the Resource Event Agent Enterprise ontology and in this context i am very interested in the work of the ODP community.<br /> |PossibleMainContribution=To have some help to solve modeling problems, To help other users to solve modeling problems<br /> |DomainsOfInterest=Business ontology, ontology-driven conceptuel modelling<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:AlbertSecure&diff=9579 2010-04-19T02:12:37Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Albert<br /> |LastName=Secure<br /> |Gender=Male<br /> |Organization=Sydney Law School<br /> |OrganizationType=Educational Training and Research Institution<br /> |Country=Australia (AU)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Solve modeling issues<br /> |PossibleMainContribution=To have some help to solve modeling problems, To help other users to solve modeling problems<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:JensWissmann&diff=9569 2010-04-16T00:01:32Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Jens<br /> |LastName=Wissmann<br /> |Gender=Male<br /> |Organization=FZI Research Center for Information Technologies, Karlsruhe<br /> |OrganizationType=Governmental Organization<br /> |OrganizationWebSite=http://www.fzi.de<br /> |Country=Germany (DE)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Our institution supports SMEs in introducing semantic technologies. In this context I often model or evaluate ontologies (mainly OWL). Rather than reinventing the wheel I would like benefit from the insights of the ODP community, and also contribute patterns that proved useful in our work to the community.<br /> |PossibleMainContribution=To have some help to solve modeling problems, To help other users to solve modeling problems<br /> |DomainsOfInterest=OWL modelling<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:CarlosTorresCruz&diff=9567 2010-04-15T13:35:17Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Carlos<br /> |LastName=Torres Cruz<br /> |Gender=Male<br /> |Organization=THDC, S.A. DE C.V.<br /> |OrganizationType=Professional Organization<br /> |Country=Mexico (MX)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Tengo necesidar de desarrollar proyectos para de industria farmaceutica bajo PAO<br /> |PossibleMainContribution=To have some help to solve modeling problems<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:NicolaGuarino&diff=9565 2010-04-15T13:33:30Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Nicola<br /> |LastName=Guarino<br /> |Gender=Male<br /> |HomePage=http://www.loa-cnr.it<br /> |Organization=ISTC-CNR, Laboratory for Applied Ontology, Trento<br /> |OrganizationType=Educational Training and Research Institution<br /> |OrganizationWebSite=http://www.loa-cnr.it<br /> |Country=Italy (IT)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Contributing to discuss modelling issues<br /> |PossibleMainContribution=To have some help to solve modeling problems<br /> |HowDidIKnowAbout=colleagues<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:AlexandraGalatescu&diff=9563 2010-04-15T13:32:15Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Alexandra<br /> |LastName=Galatescu<br /> |Gender=Female<br /> |Organization=National Institute for R&amp;D in Informatics<br /> |OrganizationType=Educational Training and Research Institution<br /> |OrganizationWebSite=http://www.ici.ro<br /> |Country=Romania (RO)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=I am interested in general solutions and tools for ontology-based modeling of applications and for inference and search, based on ontologies, on models and Web.<br /> |PossibleMainContribution=To have some help to solve modeling problems<br /> |DomainsOfInterest=ontology-based modeling, inference and search<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:EdwardMayaka&diff=9561 2010-04-15T13:31:18Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Edward<br /> |LastName=Mayaka<br /> |Gender=Male<br /> |Organization=Topquadrant (K) Ltd<br /> |OrganizationType=Professional Organization<br /> |Country=Kenya (KE)<br /> |Role=Manager<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=To share knowledge with peers<br /> |PossibleMainContribution=To have some help to solve modeling problems, To help other users to solve modeling problems<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:JeffSchmitz&diff=9559 2010-04-15T13:30:19Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Jeff<br /> |LastName=Schmitz<br /> |Gender=Male<br /> |Organization=The Boeing Company<br /> |OrganizationType=Non Governmental Organization and Association<br /> |Country=United States United States (US)<br /> |Role=Developer<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=To learn about evolving modeling patterns and to contribute where my experience allows.<br /> |PossibleMainContribution=To have some help to solve modeling problems, To help other users to solve modeling problems<br /> |HowDidIKnowAbout=friends<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:TerryMeehan&diff=9557 2010-04-15T13:28:14Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Terry<br /> |LastName=Meehan<br /> |Organization=Mouse Genome Informatics, The Jackson Laboratory<br /> |OrganizationType=Educational Training and Research Institution<br /> |Country=United States United States (US)<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Ontology design<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:The_problem_with_discussion_list_threads&diff=9556 2010-04-14T22:25:39Z

<p>MichaelUschold: </p> <hr /> <div>===The Problem===<br /> There is an enormous ton of content about ontology modeling issues in discussion list archives, ''but'': <br /> <br /> # ''there is no agreed place to go to find out about modeling issues'', so it is hard to find what you need; <br /> # the same issues get discussed over and over on different lists; <br /> # one discussion thread may interleave two or more distinct issues that are never teased out;<br /> # if you do find a relevant thread;<br /> ## the content is raw and hard to digest; <br /> ## the summary you want is ofter not there, or is hard to find;<br /> # it is often easier just to ask the question again, and the cycle continues. <br /> <br /> ===A Solution===<br /> We have created the [http://ontologydesignpatterns.org/wiki/Community:Main ontology modeling issues] section in the [http://ontologydesignpatterns.org/wiki ODP Wiki] to address these problems. We envision the following steps in the evolution of a modeling issue: <br /> <br /> # Lively discussion happens on some mailing list. <br /> # Post a summary to the list of the key points raised, including the pros and cons of proposed solutions. <br /> # Post a modeling issue on the ODP Wiki (based on that summary). <br /> # Post a note to any relevant discussion lists inviting them to contribute to the Wiki. <br /> # Discuss and refine the issue further in the ODP Wiki <br /> # Post major updates back to relevant discussion lists. <br /> <br /> OR, start with step 3, and post the modeling issue directly on the ODP Wiki. <br /> <br /> '''To Contribute:''' <br /> <br /> # Visit [http://ontologydesignpatterns.org/ Ontology Design Patterns Wiki] <br /> # If you need a login and password, click the &quot;[http://ontologydesignpatterns.org/wiki/Odp:Register How to register]&quot; link at lower left of the page.<br /> # Visit the &quot;[http://ontologydesignpatterns.org/wiki/Community:Main Ontology Modeling Issues]&quot; page for further information, examples and instructions.</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:MichaelRiben&diff=9554 2010-04-14T21:53:26Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Michael<br /> |LastName=Riben<br /> |Gender=Male<br /> |Organization=M.D. Anderson Cancer Cent<br /> |OrganizationType=Educational Training and Research Institution<br /> |OrganizationWebSite=http://www.mdanderson.org<br /> |Country=United States United States (US)<br /> |Role=Professor<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=To understand the best way to build ontologies<br /> |PossibleMainContribution=To have some help to solve modeling problems<br /> |DomainsOfInterest=Healthcare<br /> |HowDidIKnowAbout=surfing the web<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Overloading_OWL_sameAs&diff=9551 2010-04-13T22:04:29Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Overloading of owl:sameAs<br /> |Description=General Issue: owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> == Concise Summary ==<br /> ''Issue: ''owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics. <br /> <br /> ''Source'': Numerous, this issue has been discussed over and over on various lists. The summary so far is mainly based on a discussion that was originally about the proliferation of URIs and managing co-reference, and evolved into a discussion about owl:sameAs ''per se''. <br /> <br /> * [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]: [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Managing Co-reference (Was: A Semantic Elephant?)] May 2008<br /> * [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]: [http://lists.w3.org/Archives/Public/semantic-web/ ISBNs, owl:sameAs, etc] December 2009<br /> <br /> ''Related Discussions: ''<br /> <br /> * &lt;nowiki&gt;[linking open data]&lt;/nowiki&gt; [http://simile.mit.edu/mail/ReadMsg?listName=Linking Open Data&amp;msgId=19328 URI aliases and owl:sameAs was: Terminology Question] <br /> <br /> * W3C public-lod [http://www.mail-archive.com/public-lod@w3.org/msg00663.html sameAs proliferation (was Visualizing LOD Linkage)] August 2008<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Feb/0186.html owl:sameAs links from OpenCyc to WordNet] February 2009<br /> * W3C semantic-web-lifesci [http://lists.w3.org/Archives/Public/public-semweb-lifesci/2009Mar/0169.html owl:sameAs and identity [was Re: blog: semantic dissonance in uniprot]] March 2009<br /> * [http://www.mail-archive.com/topbraid-composer-users@googlegroups.com/msg00994.html [tbc-users] counting and owl:sameAs] April 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Jun/0443.html how do I report bad sameAs links? (dbpedia &lt;-&gt; Cyc)] June 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Jun/0038.html sameas.org] June 2009<br /> * W3C public-lod [http://www.mail-archive.com/public-lod@w3.org/msg02554.html A &quot;sameas&quot; widget for Firefox] June 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Jul/0306.html owl:sameAs [recipe]] July 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2010Mar/0215.html SKOS, owl:sameAs and DBpedia] March 2010<br /> <br /> ''Related Modeling Issues'': <br /> * [[Community:Versioning and URIs]]<br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> <br /> ''Examples:'' <br /> <br /> * relating a foaf:Person instance to the person's home page. <br /> * relating a geographical region with a political entity. For example, the physical area that a city occupies with the city itself. <br /> * relating the DBpedia resource referring to a place with to a GeoNames resource corresponding to that same place <br /> <br /> ''Conclusions:''<br /> <br /> There is a lot of confusion about how owl:sameAs should be used in the linked open data community. It is being used in ways that are semantically incorrect and can give incorrect inferences. A number of points and suggestions came up.<br /> <br /> # There is frequent tendency to use sameAs to link resources that provide information about something to resources that represent the thing. E.g. relating a resource denoting a book to a resource that is the Amazon page for the book.<br /> # There is a tradeoff between formal accuracy on the one hand and pragmatic usefulness on the other hand. It often arises that treating things as the same has the desired behavior. Rather than being harmful, the vagueness can be an advantage.<br /> # It was proposed that a weaker similarity relationship be created to be used instead of sameAs when there is not true identity between the two resources. Some argued that there already are alternatives, e.g. skos:related and rdfs:seeAlso<br /> # Arguments were given pro and con, as to whether the new relationship should have a formal semantics. One proposal creates a mechanism that removes it from the logic entirely See: [http://eprints.ecs.soton.ac.uk/15614/1/camera-ready.pdf Managing URI Synonymity to Enable Consistent Reference on the Semantic Web]. If the formal semantics is important, should the similarity relation <br /> ## be a relation in the logical vocabulary of OWL, as sameAs is? -or-<br /> ## be just a relation in an ontology?<br /> # Having too many ways to specify similarity might be confusing and hinder uptake of the technology.<br /> # A suggestion was made to have owl:sameAs links made in separate files so that they can easily be excluded.<br /> # A suggestion was made that there be specific guidelines and practices between owners of data in how they reach agreement on what should be linked. See: [http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html Bernard Vatant suggested some good practice of mutual linking] ''<br /> <br /> {{Semantic Elephant Text}}<br /> <br /> == July 2007 Thread ==<br /> In July 2007, [http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html Bernard Vatant suggested some good practice of mutual linking] ''quoted below'':''<br /> <br /> It's been a very long and interesting [http://simile.mit.edu/mail/BrowseList?listName=Linking%20Open%20Data&amp;from=13231&amp;amp;amp;to=13231&amp;by=thread thread] on [http://universimmedia.blogspot.com/2007/02/linking-open-data.html Linking Open Data] forum and elsewhere, about the use and semantics of owl:sameAs. I just suggested the following best practices :<br /> <br /> # Assertions such as &quot;a:foo owl:sameAs b:bar&quot; should be grounded on some form of agreement of the owners of a:foo and b:bar, on whichever basis they both decide to agree.<br /> # For outsiders (owning neither a: or b: domains), such agreement could be shown by the presence of the assertion in symmetrical way in both domains, each domain using its own URI/resource on subject side, and the other's on object side, that is :(a) asserts &quot;a:foo owl:sameAs b:bar&quot;(b) asserts &quot;b:bar owl:sameAs a:foo&quot;.<br /> # If one side (a) pushes the assertion first, the other side (b) should be at least made aware of it by (a), and is entitled to say she agrees or not : (a) says that &quot;a:foo owl:sameAs b:bar&quot;, but as the owner of (b), I do not necessarily agree. Such lack of agreement could be implicitly entailed from the absence of the reciprocal assertion on (b) side.<br /> <br /> Granted, from a pure logical viewpoint, those assertions are strictly equivalent since owl:sameAs is a symmetrical property, but from a social/trust viewpoint, having each side declaring it in a specific direction could be interpreted as a formal proof of agreement. It's what have been done e.g. between [http://dbpedia.org/resource/Berlin DBpedia] and [http://sws.geonames.org/2950159/ GeoNames]. The title thread shows once again by its sheer length, and if necessary, that there is no universal way to ground such agreement, which belongs to the realm of language and social communication. <br /> <br /> <br /> == May 2008 Thread ==<br /> In May 2008, after a vigorous discussion, [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Aldo Gangemi summarized the issues on May 16, 2008] as follows:<br /> <br /> * Issue 1: managing to suggest the rationale of owl:sameAs appropriately, i.e. in a harmless way for future usages (Aldo, Michael)<br /> * Issue 2: distinguishing &quot;data provision&quot; vs. &quot;representational&quot; usages of owl:sameAs (Yves)<br /> * Issue 3: need for another operator, e.g. representing equality under a closed set of properties (Geoff, Harry), or some relaxed rdfs:sameAs (Jim)<br /> * Issue 3a: using another existing relation, such as skos:related or rdfs:seeAlso, but these are either too weak (rdfs:seeAlso), or constrained (skos:related)<br /> * Issue 4: need for a semiotic grasp over co-reference, maybe outside formal semantics (Bernard, Peter)<br /> <br /> On issue (1), it seems that either most people agree, or they tend to prefer a discussion on issue (2), i.e. that when data provision is the intended usage, the referential vagueness introduced by owl:sameAs in many cases is not harmful, but an advantage. As Hugh puts it: &quot;we consider coreference as more knowledge about things, which can be represented in the SW, and can be used by applications if and when they see fit. And as someone said, there is no truth, only opinions. So we need an infrastructure for opinions, but that is the SW.&quot;<br /> <br /> <br /> But at this point, others switch to issue (3), and say (including me) that, if this is the case, it would be better to choose/define a different operator that ensures a safe semantics, instead of relying on an actual identity operator like owl:sameAs. Finally, some nasty :) semioticians subtly suggest that we need some way out of formal semantics, in order to represent a kind of &quot;similarity semantics&quot;. As Peter puts it: &quot;Everyone talks about meaning without saying what it is they are trying to achieve by agreeing on a formal meaning&quot;.<br /> <br /> <br /> My position, which I had when proposing the thread, is that we need to use things as efficiently as possible, without creating areas for useless wrong inferences. Another operator would be perfect, but (as Michael, Geoff, Harry require) it should provide the user with some serious features, comparable to what owl:sameAs does. Therefore, we need to talk about similarity, equality, etc. at the metalevel, just as owl:sameAs does, since it is a relation in the logical vocabulary of OWL, not a relation from a specific ontology. Most problems of co-referencing and identity seem to arise from the collapsing of the distinction between entities and information that denotes those entities (as noticed by Bernard, Harry, Aldo), be it dependent on some &quot;meaning&quot; or not. The metalevel we need to address is therefore the semiotic one, as correctly pointed in this discussion.<br /> <br /> <br /> My proposal is that such metalevel is not necessarily &quot;outside formal semantics&quot;, and some work from my group and elsewhere is proceeding in the direction of a reconciliation between a semiotic, social meaning, and the formal encoding of meaning.<br /> <br /> <br /> == Summary and Synthesis ==<br /> ''Correct Usages: ''A common case of a correct use is to link one resource that denotes a particular real world object to another resource that denotes the same object. Typically this will be done in two different collections of resources from two different namespaces. Examples:<br /> <br /> * the DBpedia resource referring to a music album should have a sameAs link to a MusicBrainz resource that denotes that same album <br /> * the DBpedia resource referring to a company should have a sameAs link to a DailyMed resource referring to that same company<br /> * an instance of a foaf:Person denoting Tim Berners-Lee should have a sameAs link to the resource in DBLP corresponding to Tim Berners Lee.<br /> <br /> ''Possibly correct usage:''<br /> <br /> * the DBpedia resource referring to a place may have a sameAs link to a GeoNames resource corresponding to that same place<br /> ** &lt;nowiki&gt;&lt;http://dbpedia.org/resource/Bangalore&gt; &lt;http://www.w3.org/2002/07/owl#sameAs&gt; &lt;http://sws.geonames.org/1277333/&gt; .&lt;/nowiki&gt;<br /> ** Note that the geonames reference is to a web page, not necessarily to an RDF resource.<br /> <br /> ''Probably incorrect usages: ''<br /> <br /> # relating a foaf:Person instance to the person's home pageThis should be done using the relationship: foaf:homepage, not owl:sameAs.<br /> # relating a resource denoting a book to a resource that is the Amazon page for the book.<br /> # relating a geographical region with a political entity. For example, the physical area that a city occupies with the city itself.<br /> <br /> The first two are similar in that there is a confusion between a resource denoting a real world entity and a web page that contains information about that real world entity. <br /> <br /> The books example is interesting because for most intents and purposes, people just want to say: yes, the books we are talking about in each case are the same. So owl:sameAs seems highly appropriate. This likely work much of the time. It could be a problem for someone wanting to analyze an Amazon web page for say its structure and layout. Then the book that the web page is featuring is an attribute of the web page, not the web page itself.<br /> <br /> <br /> ''Issue: ''even if the usage is strictly incorrect, in some cases it may not matter. It depends on the intended use. Using owl:sameAs in a variety of ways with somewhat vague semantics can actually be an advantage.<br /> <br /> We can have best of both worlds if we have a more generic relation that is being used the way owl:sameAs is now (vaguely) and having sub-relations that have more specific meanings. <br /> <br /> <br /> ''Issue: ''If we move to a new vocabulary of similarity relationships that inludes the curent sameAs (as strictly defined) as well as a looser relationship (as sameAs is often used in practice), then there is a communication and migration challenge getting people to use them correctly.<br /> <br /> Maybe what is now called “sameAs: should be renamed to “literalSameAs” and then the strictly correct uses of sameAs could be changed to literalSameAs, and the loose ones would remain the same. <br /> <br /> <br /> '''Ideas / Proposals'''<br /> <br /> ''More vocabulary needed to cover different cases. The vocabulary should provide clear and formal semantics, in the way that sameAs has, the semantics will be weaker.''<br /> <br /> ''Essentially the same thing: ''The main thing being talked about by one resource is for all ''non-technical'' intents and purposes the same thing that is being talked about by the other resource.Examples<br /> <br /> * <br /> ** DBpedia country related to the corresponding GeoNames URI. <br /> ** a person or company related to their home page. There already is a foaf:page relationship for this, so this could be set as a sub-property of ''EssentiallyTheSameThing''<br /> ** A book like, On the Road and various ISBNs for various manifestations of that book. <br /> <br /> ''Use existing properties like rdfs: seeAlso and skos:related to denote similarity, which is what owl:sameAs is often used for.''<br /> <br /> This may have some merit, but often these have too weak a semantics.<br /> <br /> <br /> Distinguish a set of core assertions about a resource from ancillary assertions. See: ''http://dbooth.org/2007/uri-decl/ ''<br /> <br /> <br /> '''Good points raised:'''<br /> <br /> * Most problems of co-referencing and identity seem to arise from the collapsing of the distinction between entities and information that denotes those entities. Thus the metalevel we need to address is the semiotic one. &lt;nowiki&gt;[Aldo's] proposal is that such metalevel is not necessarily &quot;outside formal semantics&quot;, and some work from my group and elsewhere is proceeding in the direction of a reconciliation between a semiotic, social meaning, &lt;/nowiki&gt;and the formal encoding of meaning.<br /> * A URN and a non-URN URI can be linked by owl:sameAs. Example:urn:ietf:rfc:3187 (URN) owl:sameAs [http://tools.ietf.org/html/rfc3187.html http://tools.ietf.org/html/rfc3187.html] (URL). <br /> * if too many things are sameAs to lots of other things, then the amount of intelligent conclusions you can draw from the LOD cloud will be limited. (Martin Hepp)<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9550 2010-04-13T22:02:45Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ==Concise Summary==<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion initially took place off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Overloading OWL sameAs]]<br /> * [[Community:Versioning and URIs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> ''Conclusions:'' <br /> # to some extent, URI proliferation is inevitable in an open web. It is probably the only way to allow people to independently publish web data.<br /> # We will have to rely on a combination of manual effort and sophisticated automated methods to detect clashes, and attempt to resolve them. There is a difference of opinion of how good a job automated techniques can do.<br /> # large scale duplication of URIs as in the case of YAGO and DBpedia, is unfortunate, but has now largely been rectified. That it happened at all is due to this all being very new.<br /> # it was argued that it does not matter much because noone is going to load all the triples into a one triple store. A counter argument to this is that even if you load a lot of triples into one store, the problem of inefficiency of sameAs reasoning can arise.<br /> # that these issues are arising at all can be seen as a good thing, insofar as it reflects that linked data is being made available and put to real use. Tim Berners-Lee notes that: &quot;Life is, on balance, good.&quot;<br /> <br /> {{Semantic Elephant Text}}<br /> <br /> ==Original Post==<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> ==Summary of Responses== <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9549 2010-04-13T22:01:55Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ==Concise Summary==<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Examples:'' <br /> # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.<br /> # A new version of SKOS kept the original namespace. This resulted in changing the semantics of existing URIs. <br /> <br /> ''Conclusions:''<br /> # There are no guidelines for when and whether to create new URIs as ontologies evolve<br /> # There is no consistency in how people are approaching the problem.<br /> # Reasons for this are:<br /> ## insufficient technological infrastructure for ontology maintenance &amp; change management <br /> ## URIs are overloaded <br /> # Approaches include:<br /> ## Mint new URIs even thought the semantics for most may be identical<br /> ## Keep URI the same for a small number of terms even though the semantics may change<br /> ## Use depracation for old terms, keeping the same URI<br /> ## Mint new URIs for only the changed terms.<br /> # Tradeoffs:<br /> ## Attractive for using the ontology for the first time. The proliferation of URIs may result in maintenance and performance issues. <br /> ## Attractive for using the ontology for the first time. Ontology-driven applications may break.<br /> ## Attractive in the case when ontologies are continuously evolving.<br /> ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.<br /> <br /> {{Semantic Elephant Text}}<br /> <br /> ==Original Post==<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> ==Summary of Followup Discussion==<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Template:Semantic_Elephant_Text&diff=9548 2010-04-13T21:57:41Z

<p>MichaelUschold: </p> <hr /> <div>&lt;noinclude&gt;<br /> This is the 'Semantic Elephant Text' template.<br /> It should be called in the following format:<br /> &lt;pre&gt;<br /> {{Semantic Elephant Text}}<br /> &lt;/pre&gt;<br /> Edit the page to see the template text.<br /> &lt;/noinclude&gt;&lt;includeonly&gt;<br /> {| class=&quot;wikitable&quot;<br /> |}<br /> == Background ==<br /> In May 2008, Michael Uschold kicked off a discussion with the subject &quot;A Semantic Elephant&quot; describing the unnecessary and costly proliferation of URIs and owl:sameAs links. This discussion evolved to be mostly about managing co-reference. Intitialy private, this discussion was moved to the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List] at Tim Berners-Lee's request. See: [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]. <br /> <br /> The original discussion evolved into a discussion about owl:sameAs per se, which has been a recurring topic on various lists over the years. [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Aldo Gangemi provided a concise summary on May 16, 2008].<br /> <br /> In October 2008, Uschold started a closely related discussion focused more on challenges with Versioning and URIs. It was under the subject: [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs].<br /> <br /> From all this, Uschold teased out three distinct but closely related modeling isssues that are in this ODP Wiki:<br /> <br /> # [[Community:Overloading OWL sameAs]]: sameAs is being used in the linked data community in a way that is inconsistent with its semantics <br /> # [[Community:Proliferation of URIs, Managing Coreference]]: How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> ## it is hard to find when two things should be the same <br /> ## even if you can find the links, prolific use of owl:sameAs will create computational problems. <br /> # [[Community:Versioning and URIs]]: When and whether to make new URIs for different versions of things. <br /> &lt;/includeonly&gt;</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Template:Semantic_Elephant_Text&diff=9547 2010-04-13T21:53:41Z

<p>MichaelUschold: New page: &lt;noinclude&gt; This is the 'Semantic Elephant Text' template. It should be called in the following format: &lt;pre&gt; {{Semantic Elephant Text}} &lt;/pre&gt; Edit the page to see the template text. &lt;/no...</p> <hr /> <div>&lt;noinclude&gt;<br /> This is the 'Semantic Elephant Text' template.<br /> It should be called in the following format:<br /> &lt;pre&gt;<br /> {{Semantic Elephant Text}}<br /> &lt;/pre&gt;<br /> Edit the page to see the template text.<br /> &lt;/noinclude&gt;&lt;includeonly&gt;<br /> {| class=&quot;wikitable&quot;<br /> |}<br /> &lt;/includeonly&gt;</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9546 2010-04-13T21:47:46Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ==Concise Summary==<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Examples:'' <br /> # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.<br /> # A new version of SKOS kept the original namespace. This resulted in changing the semantics of existing URIs. <br /> <br /> ''Conclusions:''<br /> # There are no guidelines for when and whether to create new URIs as ontologies evolve<br /> # There is no consistency in how people are approaching the problem.<br /> # Reasons for this are:<br /> ## insufficient technological infrastructure for ontology maintenance &amp; change management <br /> ## URIs are overloaded <br /> # Approaches include:<br /> ## Mint new URIs even thought the semantics for most may be identical<br /> ## Keep URI the same for a small number of terms even though the semantics may change<br /> ## Use depracation for old terms, keeping the same URI<br /> ## Mint new URIs for only the changed terms.<br /> # Tradeoffs:<br /> ## Attractive for using the ontology for the first time. The proliferation of URIs may result in maintenance and performance issues. <br /> ## Attractive for using the ontology for the first time. Ontology-driven applications may break.<br /> ## Attractive in the case when ontologies are continuously evolving.<br /> ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.<br /> <br /> == Background ==<br /> In May 2008, Michael Uschold kicked off a discussion with the subject &quot;A Semantic Elephant&quot; describing the unnecessary and costly proliferation of URIs and owl:sameAs links. This discussion evolved to be mostly about managing co-reference. Intitialy private, this discussion was moved to the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List] at Tim Berners-Lee's request. See: [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]. <br /> <br /> The original discussion evolved into a discussion about owl:sameAs per se, which has been a recurring topic on various lists over the years. [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Aldo Gangemi provided a concise summary on May 16, 2008].<br /> <br /> In October 2008, Uschold started a closely related discussion focused more on challenges with Versioning and URIs. It was under the subject: [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs].<br /> <br /> From all this, Uschold teased out three distinct but closely related modeling isssues that are in this ODP Wiki:<br /> <br /> # [[Community:Overloading OWL sameAs]]: sameAs is being used in the linked data community in a way that is inconsistent with its semantics <br /> # [[Community:Proliferation of URIs, Managing Coreference]]: How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> ## it is hard to find when two things should be the same <br /> ## even if you can find the links, prolific use of owl:sameAs will create computational problems. <br /> # [[Community:Versioning and URIs]]: When and whether to make new URIs for different versions of things. <br /> <br /> ==Original Post==<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> ==Summary of Followup Discussion==<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9545 2010-04-13T21:44:16Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ==Concise Summary==<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Examples:'' <br /> # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.<br /> # A new version of SKOS kept the original namespace. This resulted in changing the semantics of existing URIs. <br /> <br /> ''Conclusions:''<br /> # There are no guidelines for when and whether to create new URIs as ontologies evolve<br /> # There is no consistency in how people are approaching the problem.<br /> # Reasons for this are:<br /> ## insufficient technological infrastructure for ontology maintenance &amp; change management <br /> ## URIs are overloaded <br /> # Approaches include:<br /> ## Mint new URIs even thought the semantics for most may be identical<br /> ## Keep URI the same for a small number of terms even though the semantics may change<br /> ## Use depracation for old terms, keeping the same URI<br /> ## Mint new URIs for only the changed terms.<br /> # Tradeoffs:<br /> ## Attractive for using the ontology for the first time. The proliferation of URIs may result in maintenance and performance issues. <br /> ## Attractive for using the ontology for the first time. Ontology-driven applications may break.<br /> ## Attractive in the case when ontologies are continuously evolving.<br /> ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.<br /> <br /> == Background ==<br /> In May 2008, Michael Uschold kicked off a discussion with the subject “A Semantic Elephant” noting some problems with an unnecessary and costly proliferation of URIs and owl:sameAs links. This discussion evolved to be mostly about managing co-reference. Intitialy private, this discussion was moved to the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List] at Tim Berners-Lee's request. See: [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]. <br /> <br /> The original discussion evolved into a discussion about owl:sameAs per se, which has been a recurring topic on various lists over the years. [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Aldo Gangemi provided a concise summary on May 16, 2008].<br /> <br /> In October 2008, Uschold started a closely related discussion focused more on challenges with Versioning and URIs. It was under the subject: [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs].<br /> <br /> From all this, Uschold teased out three distinct but closely related modeling isssues that are in this ODP Wiki:<br /> <br /> # [[Community:Overloading OWL sameAs]]: sameAs is being used in the linked data community in a way that is inconsistent with its semantics <br /> # [[Community:Proliferation of URIs, Managing Coreference]]: How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> ## it is hard to find when two things should be the same <br /> ## even if you can find the links, prolific use of owl:sameAs will create computational problems. <br /> # [Community:Versioning and URIs]: When and whether to make new URIs for different versions of things. <br /> <br /> ==Original Post==<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> ==Summary of Followup Discussion==<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9544 2010-04-13T21:40:59Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ==Concise Summary==<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Examples:'' <br /> # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.<br /> # A new version of SKOS kept the original namespace. This resulted in changing the semantics of existing URIs. <br /> <br /> ''Conclusions:''<br /> # There are no guidelines for when and whether to create new URIs as ontologies evolve<br /> # There is no consistency in how people are approaching the problem.<br /> # Reasons for this are:<br /> ## insufficient technological infrastructure for ontology maintenance &amp; change management <br /> ## URIs are overloaded <br /> # Approaches include:<br /> ## Mint new URIs even thought the semantics for most may be identical<br /> ## Keep URI the same for a small number of terms even though the semantics may change<br /> ## Use depracation for old terms, keeping the same URI<br /> ## Mint new URIs for only the changed terms.<br /> # Tradeoffs:<br /> ## Attractive for using the ontology for the first time. The proliferation of URIs may result in maintenance and performance issues. <br /> ## Attractive for using the ontology for the first time. Ontology-driven applications may break.<br /> ## Attractive in the case when ontologies are continuously evolving.<br /> ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.<br /> <br /> == Background ==<br /> In May 2008, Michael Uschold kicked off a discussion with the subject “A Semantic Elephant” noting some problems with an unnecessary and costly proliferation of URIs and owl:sameAs links. This discussion evolved to be mostly about managing co-reference. Intitialy private, this discussion was moved to the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List] at Tim Berners-Lee's request. See: [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]. <br /> <br /> The original discussion evolved into a discussion about owl:sameAs per se, which has been a recurring topic on various lists over the years. [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Aldo Gangemi provided a concise summary on May 16, 2008].<br /> <br /> In October 2008, Uschold started a closely related discussion focused more on challenges with Versioning and URIs. It was under the subject: [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs].<br /> <br /> From all this, Uschold teased out three distinct but closely related modeling isssues that are in this ODP Wiki:<br /> <br /> # ''Overloading owl:sameAs'': sameAs is being used in the linked data community in a way that is inconsistent with its semantics <br /> # ''Proliferation of URIs, Managing Co-Reference'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> ## it is hard to find when two things should be the same <br /> ## even if you can find the links, prolific use of owl:sameAs will create computational problems. <br /> # ''Versioning and URIs: ''When and whether to make new URIs for different versions of things. <br /> <br /> ==Original Post==<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> ==Summary of Followup Discussion==<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9543 2010-04-13T21:06:38Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ==Concise Summary==<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion initially took place off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Overloading OWL sameAs]]<br /> * [[Community:Versioning and URIs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> ''Conclusions:'' <br /> # to some extent, URI proliferation is inevitable in an open web. It is probably the only way to allow people to independently publish web data.<br /> # We will have to rely on a combination of manual effort and sophisticated automated methods to detect clashes, and attempt to resolve them. There is a difference of opinion of how good a job automated techniques can do.<br /> # large scale duplication of URIs as in the case of YAGO and DBpedia, is unfortunate, but has now largely been rectified. That it happened at all is due to this all being very new.<br /> # it was argued that it does not matter much because noone is going to load all the triples into a one triple store. A counter argument to this is that even if you load a lot of triples into one store, the problem of inefficiency of sameAs reasoning can arise.<br /> # that these issues are arising at all can be seen as a good thing, insofar as it reflects that linked data is being made available and put to real use. Tim Berners-Lee notes that: &quot;Life is, on balance, good.&quot;<br /> <br /> <br /> ==Original Post==<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> ==Summary of Responses== <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Overloading_OWL_sameAs&diff=9542 2010-04-13T20:52:49Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Overloading of owl:sameAs<br /> |Description=General Issue: owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> == Concise Summary ==<br /> ''Issue: ''owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics. <br /> <br /> ''Source'': Numerous, this issue has been discussed over and over on various lists. The summary so far is mainly based on a discussion that was originally about the proliferation of URIs and managing co-reference, and evolved into a discussion about owl:sameAs ''per se''. <br /> <br /> * [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]: [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Managing Co-reference (Was: A Semantic Elephant?)] May 2008<br /> * [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]: [http://lists.w3.org/Archives/Public/semantic-web/ ISBNs, owl:sameAs, etc] December 2009<br /> <br /> ''Related Discussions: ''<br /> <br /> * &lt;nowiki&gt;[linking open data]&lt;/nowiki&gt; [http://simile.mit.edu/mail/ReadMsg?listName=Linking Open Data&amp;msgId=19328 URI aliases and owl:sameAs was: Terminology Question] <br /> <br /> * W3C public-lod [http://www.mail-archive.com/public-lod@w3.org/msg00663.html sameAs proliferation (was Visualizing LOD Linkage)] August 2008<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Feb/0186.html owl:sameAs links from OpenCyc to WordNet] February 2009<br /> * W3C semantic-web-lifesci [http://lists.w3.org/Archives/Public/public-semweb-lifesci/2009Mar/0169.html owl:sameAs and identity [was Re: blog: semantic dissonance in uniprot]] March 2009<br /> * [http://www.mail-archive.com/topbraid-composer-users@googlegroups.com/msg00994.html [tbc-users] counting and owl:sameAs] April 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Jun/0443.html how do I report bad sameAs links? (dbpedia &lt;-&gt; Cyc)] June 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Jun/0038.html sameas.org] June 2009<br /> * W3C public-lod [http://www.mail-archive.com/public-lod@w3.org/msg02554.html A &quot;sameas&quot; widget for Firefox] June 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2009Jul/0306.html owl:sameAs [recipe]] July 2009<br /> * W3C public-lod [http://lists.w3.org/Archives/Public/public-lod/2010Mar/0215.html SKOS, owl:sameAs and DBpedia] March 2010<br /> <br /> ''Related Modeling Issues'': <br /> * [[Community:Versioning and URIs]]<br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> <br /> ''Examples:'' <br /> <br /> * relating a foaf:Person instance to the person's home page. <br /> * relating a geographical region with a political entity. For example, the physical area that a city occupies with the city itself. <br /> * relating the DBpedia resource referring to a place with to a GeoNames resource corresponding to that same place <br /> <br /> ''Conclusions:''<br /> <br /> There is a lot of confusion about how owl:sameAs should be used in the linked open data community. It is being used in ways that are semantically incorrect and can give incorrect inferences. A number of points and suggestions came up.<br /> <br /> # There is frequent tendency to use sameAs to link resources that provide information about something to resources that represent the thing. E.g. relating a resource denoting a book to a resource that is the Amazon page for the book.<br /> # There is a tradeoff between formal accuracy on the one hand and pragmatic usefulness on the other hand. It often arises that treating things as the same has the desired behavior. Rather than being harmful, the vagueness can be an advantage.<br /> # It was proposed that a weaker similarity relationship be created to be used instead of sameAs when there is not true identity between the two resources. Some argued that there already are alternatives, e.g. skos:related and rdfs:seeAlso<br /> # Arguments were given pro and con, as to whether the new relationship should have a formal semantics. One proposal creates a mechanism that removes it from the logic entirely See: [http://eprints.ecs.soton.ac.uk/15614/1/camera-ready.pdf Managing URI Synonymity to Enable Consistent Reference on the Semantic Web]. If the formal semantics is important, should the similarity relation <br /> ## be a relation in the logical vocabulary of OWL, as sameAs is? -or-<br /> ## be just a relation in an ontology?<br /> # Having too many ways to specify similarity might be confusing and hinder uptake of the technology.<br /> # A suggestion was made to have owl:sameAs links made in separate files so that they can easily be excluded.<br /> # A suggestion was made that there be specific guidelines and practices between owners of data in how they reach agreement on what should be linked. See: [http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html Bernard Vatant suggested some good practice of mutual linking] ''<br /> <br /> == July 2007 Thread ==<br /> In July 2007, [http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html Bernard Vatant suggested some good practice of mutual linking] ''quoted below'':''<br /> <br /> It's been a very long and interesting [http://simile.mit.edu/mail/BrowseList?listName=Linking%20Open%20Data&amp;from=13231&amp;amp;amp;to=13231&amp;by=thread thread] on [http://universimmedia.blogspot.com/2007/02/linking-open-data.html Linking Open Data] forum and elsewhere, about the use and semantics of owl:sameAs. I just suggested the following best practices :<br /> <br /> # Assertions such as &quot;a:foo owl:sameAs b:bar&quot; should be grounded on some form of agreement of the owners of a:foo and b:bar, on whichever basis they both decide to agree.<br /> # For outsiders (owning neither a: or b: domains), such agreement could be shown by the presence of the assertion in symmetrical way in both domains, each domain using its own URI/resource on subject side, and the other's on object side, that is :(a) asserts &quot;a:foo owl:sameAs b:bar&quot;(b) asserts &quot;b:bar owl:sameAs a:foo&quot;.<br /> # If one side (a) pushes the assertion first, the other side (b) should be at least made aware of it by (a), and is entitled to say she agrees or not : (a) says that &quot;a:foo owl:sameAs b:bar&quot;, but as the owner of (b), I do not necessarily agree. Such lack of agreement could be implicitly entailed from the absence of the reciprocal assertion on (b) side.<br /> <br /> Granted, from a pure logical viewpoint, those assertions are strictly equivalent since owl:sameAs is a symmetrical property, but from a social/trust viewpoint, having each side declaring it in a specific direction could be interpreted as a formal proof of agreement. It's what have been done e.g. between [http://dbpedia.org/resource/Berlin DBpedia] and [http://sws.geonames.org/2950159/ GeoNames]. The title thread shows once again by its sheer length, and if necessary, that there is no universal way to ground such agreement, which belongs to the realm of language and social communication. <br /> <br /> <br /> == May 2008 Thread ==<br /> In May 2008, after a vigorous discussion, [http://lists.w3.org/Archives/Public/semantic-web/2008May/0126.html Aldo Gangemi summarized the issues on May 16, 2008] as follows:<br /> <br /> * Issue 1: managing to suggest the rationale of owl:sameAs appropriately, i.e. in a harmless way for future usages (Aldo, Michael)<br /> * Issue 2: distinguishing &quot;data provision&quot; vs. &quot;representational&quot; usages of owl:sameAs (Yves)<br /> * Issue 3: need for another operator, e.g. representing equality under a closed set of properties (Geoff, Harry), or some relaxed rdfs:sameAs (Jim)<br /> * Issue 3a: using another existing relation, such as skos:related or rdfs:seeAlso, but these are either too weak (rdfs:seeAlso), or constrained (skos:related)<br /> * Issue 4: need for a semiotic grasp over co-reference, maybe outside formal semantics (Bernard, Peter)<br /> <br /> On issue (1), it seems that either most people agree, or they tend to prefer a discussion on issue (2), i.e. that when data provision is the intended usage, the referential vagueness introduced by owl:sameAs in many cases is not harmful, but an advantage. As Hugh puts it: &quot;we consider coreference as more knowledge about things, which can be represented in the SW, and can be used by applications if and when they see fit. And as someone said, there is no truth, only opinions. So we need an infrastructure for opinions, but that is the SW.&quot;<br /> <br /> <br /> But at this point, others switch to issue (3), and say (including me) that, if this is the case, it would be better to choose/define a different operator that ensures a safe semantics, instead of relying on an actual identity operator like owl:sameAs. Finally, some nasty :) semioticians subtly suggest that we need some way out of formal semantics, in order to represent a kind of &quot;similarity semantics&quot;. As Peter puts it: &quot;Everyone talks about meaning without saying what it is they are trying to achieve by agreeing on a formal meaning&quot;.<br /> <br /> <br /> My position, which I had when proposing the thread, is that we need to use things as efficiently as possible, without creating areas for useless wrong inferences. Another operator would be perfect, but (as Michael, Geoff, Harry require) it should provide the user with some serious features, comparable to what owl:sameAs does. Therefore, we need to talk about similarity, equality, etc. at the metalevel, just as owl:sameAs does, since it is a relation in the logical vocabulary of OWL, not a relation from a specific ontology. Most problems of co-referencing and identity seem to arise from the collapsing of the distinction between entities and information that denotes those entities (as noticed by Bernard, Harry, Aldo), be it dependent on some &quot;meaning&quot; or not. The metalevel we need to address is therefore the semiotic one, as correctly pointed in this discussion.<br /> <br /> <br /> My proposal is that such metalevel is not necessarily &quot;outside formal semantics&quot;, and some work from my group and elsewhere is proceeding in the direction of a reconciliation between a semiotic, social meaning, and the formal encoding of meaning.<br /> <br /> <br /> == Summary and Synthesis ==<br /> ''Correct Usages: ''A common case of a correct use is to link one resource that denotes a particular real world object to another resource that denotes the same object. Typically this will be done in two different collections of resources from two different namespaces. Examples:<br /> <br /> * the DBpedia resource referring to a music album should have a sameAs link to a MusicBrainz resource that denotes that same album <br /> * the DBpedia resource referring to a company should have a sameAs link to a DailyMed resource referring to that same company<br /> * an instance of a foaf:Person denoting Tim Berners-Lee should have a sameAs link to the resource in DBLP corresponding to Tim Berners Lee.<br /> <br /> ''Possibly correct usage:''<br /> <br /> * the DBpedia resource referring to a place may have a sameAs link to a GeoNames resource corresponding to that same place<br /> ** &lt;nowiki&gt;&lt;http://dbpedia.org/resource/Bangalore&gt; &lt;http://www.w3.org/2002/07/owl#sameAs&gt; &lt;http://sws.geonames.org/1277333/&gt; .&lt;/nowiki&gt;<br /> ** Note that the geonames reference is to a web page, not necessarily to an RDF resource.<br /> <br /> ''Probably incorrect usages: ''<br /> <br /> # relating a foaf:Person instance to the person's home pageThis should be done using the relationship: foaf:homepage, not owl:sameAs.<br /> # relating a resource denoting a book to a resource that is the Amazon page for the book.<br /> # relating a geographical region with a political entity. For example, the physical area that a city occupies with the city itself.<br /> <br /> The first two are similar in that there is a confusion between a resource denoting a real world entity and a web page that contains information about that real world entity. <br /> <br /> The books example is interesting because for most intents and purposes, people just want to say: yes, the books we are talking about in each case are the same. So owl:sameAs seems highly appropriate. This likely work much of the time. It could be a problem for someone wanting to analyze an Amazon web page for say its structure and layout. Then the book that the web page is featuring is an attribute of the web page, not the web page itself.<br /> <br /> <br /> ''Issue: ''even if the usage is strictly incorrect, in some cases it may not matter. It depends on the intended use. Using owl:sameAs in a variety of ways with somewhat vague semantics can actually be an advantage.<br /> <br /> We can have best of both worlds if we have a more generic relation that is being used the way owl:sameAs is now (vaguely) and having sub-relations that have more specific meanings. <br /> <br /> <br /> ''Issue: ''If we move to a new vocabulary of similarity relationships that inludes the curent sameAs (as strictly defined) as well as a looser relationship (as sameAs is often used in practice), then there is a communication and migration challenge getting people to use them correctly.<br /> <br /> Maybe what is now called “sameAs: should be renamed to “literalSameAs” and then the strictly correct uses of sameAs could be changed to literalSameAs, and the loose ones would remain the same. <br /> <br /> <br /> '''Ideas / Proposals'''<br /> <br /> ''More vocabulary needed to cover different cases. The vocabulary should provide clear and formal semantics, in the way that sameAs has, the semantics will be weaker.''<br /> <br /> ''Essentially the same thing: ''The main thing being talked about by one resource is for all ''non-technical'' intents and purposes the same thing that is being talked about by the other resource.Examples<br /> <br /> * <br /> ** DBpedia country related to the corresponding GeoNames URI. <br /> ** a person or company related to their home page. There already is a foaf:page relationship for this, so this could be set as a sub-property of ''EssentiallyTheSameThing''<br /> ** A book like, On the Road and various ISBNs for various manifestations of that book. <br /> <br /> ''Use existing properties like rdfs: seeAlso and skos:related to denote similarity, which is what owl:sameAs is often used for.''<br /> <br /> This may have some merit, but often these have too weak a semantics.<br /> <br /> <br /> Distinguish a set of core assertions about a resource from ancillary assertions. See: ''http://dbooth.org/2007/uri-decl/ ''<br /> <br /> <br /> '''Good points raised:'''<br /> <br /> * Most problems of co-referencing and identity seem to arise from the collapsing of the distinction between entities and information that denotes those entities. Thus the metalevel we need to address is the semiotic one. &lt;nowiki&gt;[Aldo's] proposal is that such metalevel is not necessarily &quot;outside formal semantics&quot;, and some work from my group and elsewhere is proceeding in the direction of a reconciliation between a semiotic, social meaning, &lt;/nowiki&gt;and the formal encoding of meaning.<br /> * A URN and a non-URN URI can be linked by owl:sameAs. Example:urn:ietf:rfc:3187 (URN) owl:sameAs [http://tools.ietf.org/html/rfc3187.html http://tools.ietf.org/html/rfc3187.html] (URL). <br /> * if too many things are sameAs to lots of other things, then the amount of intelligent conclusions you can draw from the LOD cloud will be limited. (Martin Hepp)<br /> <br /> <br /> <br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=User:DanielSchober&diff=9540 2010-04-13T18:13:27Z

<p>MichaelUschold: Creating user page with biography of new user.</p> <hr /> <div>{{User Template<br /> |FirstName=Daniel<br /> |LastName=Schober<br /> |Gender=Male<br /> |HomePage=http://www.imbi.uni-freiburg.de/biom/index.php?showEmployee=schober<br /> |Organization=IMBI<br /> |OrganizationType=Educational Training and Research Institution<br /> |OrganizationWebSite=http://www.imbi.uni-freiburg.de/<br /> |Country=Germany (DE)<br /> |Role=Researcher<br /> |Picture=ODPUser.png<br /> }}<br /> {{Account Request Template<br /> |Motivation=Align and put Naming Conventions of the OBO Foundry into ODP, hence developing new patterns.<br /> |PossibleMainContribution=To help other users to solve modeling problems<br /> |DomainsOfInterest=naming conventions (labelling guidelines)<br /> |HowDidIKnowAbout=conference/public events<br /> }}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9537 2010-04-13T01:37:43Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion initially took place off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Overloading OWL sameAs]]<br /> * [[Community:Versioning and URIs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> ''Conclusions:'' <br /> # to some extent, URI proliferation is inevitable in an open web. It is probably the only way to allow people to independently publish web data.<br /> # We will have to rely on a combination of manual effort and sophisticated automated methods to detect clashes, and attempt to resolve them. There is a difference of opinion of how good a job automated techniques can do.<br /> # large scale duplication of URIs as in the case of YAGO and DBpedia, is unfortunate, but has now largely been rectified. That it happened at all is due to this all being very new.<br /> # it was argued that it does not matter much because noone is going to load all the triples into a one triple store. A counter argument to this is that even if you load a lot of triples into one store, the problem of inefficiency of sameAs reasoning can arise.<br /> # that these issues are arising at all can be seen as a good thing, insofar as it reflects that linked data is being made available and put to real use. Tim Berners-Lee notes that: &quot;Life is, on balance, good.&quot;<br /> <br /> <br /> '''Original Post'''<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> '''Summary of Responses''' <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Overloading_OWL_sameAs&diff=9536 2010-04-12T23:15:00Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Overloading of owl:sameAs<br /> |Description=General Issue: owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue: ''owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics. <br /> <br /> ''Source:''<br /> <br /> ''Related Discussions:''<br /> <br /> ''Related Modeling Issues'': <br /> * [[Community:Versioning and URIs]]<br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> <br /> ''Examples:''<br /> <br /> ''Conclusions:''<br /> <br /> ''Correct Usages: ''A common case of a correct use is to link one resource that denotes a particular real world object to another resource that denotes the same object. Typically this will be done in two different collections of resources from two different namespaces. Examples:<br /> <br /> * the DBpedia resource referring to a music album should have a sameAs link to a MusicBrainz resource that denotes that same album <br /> * the DBpedia resource referring to a company should have a sameAs link to a DailyMed resource referring to that same company<br /> * an instance of a foaf:Person denoting Tim Berners-Lee should have a sameAs link to the resource in DBLP corresponding to Tim Berners Lee.<br /> <br /> ''Possibly correct usage:''<br /> <br /> * the DBpedia resource referring to a place may have a sameAs link to a GeoNames resource corresponding to that same place<br /> ** &lt;nowiki&gt;&lt;http://dbpedia.org/resource/Bangalore&gt; &lt;http://www.w3.org/2002/07/owl#sameAs&gt; &lt;http://sws.geonames.org/1277333/&gt; .&lt;/nowiki&gt;<br /> ** Note that the geonames reference is to a web page, not necessarily to an RDF resource.<br /> <br /> ''Probably incorrect usages: ''<br /> <br /> # relating a foaf:Person instance to the person's home page. This should be done using the relationship: foaf:homepage, not owl:sameAs.<br /> # relating a resource denoting a book to a resource that is the Amazon page for the book.<br /> # relating a geographical region with a political entity. For example, the physical area that a city occupies with the city itself.<br /> <br /> The first two are similar in that there is a confusion between a resource denoting a real world entity and a web page that contains information about that real world entity. <br /> <br /> <br /> The books example is interesting because for most intents and purposes, people just want to say: yes, the books we are talking about in each case are the same. So owl:sameAs seems highly appropriate. This likely work much of the time. It could be a problem for someone wanting to analyze an Amazon web page for say its structure and layout. Then the book that the web page is featuring is an attribute of the web page, not the web page itself.<br /> <br /> <br /> ''Issue: ''even if the usage is strictly incorrect, in some cases it may not matter. It depends on the intended use. Using owl:sameAs in a variety of ways with somewhat vague semantics can actually be an advantage.<br /> <br /> <br /> We can have best of both worlds if we have a more generic relation that is being used the way owl:sameAs is now (vaguely) and having sub-relations that have more specific meanings. <br /> <br /> <br /> ''Issue: ''If we move to a new vocabulary of similarity relationships that includes the current sameAs (as strictly defined) as well as a looser relationship (as sameAs is often used in practice), then there is a communication and migration challenge getting people to use them correctly.<br /> <br /> Maybe what is now called sameAs should be renamed to literalSameAs and then the strictly correct uses of sameAs could be changed to literalSameAs, and the loose ones would remain the same. <br /> <br /> <br /> '''Ideas / Proposals'''<br /> <br /> More vocabulary needed to cover different cases. The vocabulary should provide clear and formal semantics, in the way that sameAs has, the semantics will be weaker.<br /> <br /> ''Essentially the same thing: ''The main thing being talked about by one resource is for all ''non-technical'' intents and purposes the same thing that is being talked about by the other resource. Examples<br /> <br /> * DBpedia country related to the corresponding GeoNames URI. <br /> * a person or company related to their home page. There already is a foaf:page relationship for this, so this could be set as a sub-property of ''EssentiallyTheSameThing''<br /> * A book like, On the Road and various ISBNs for various manifestations of that book. <br /> <br /> ''Use existing properties like rdfs:seeAlso and skos:related to denote similarity, which is what owl:sameAs is often used for.''<br /> <br /> This may have some merit, but often these have too weak a semantics.<br /> <br /> <br /> Distinguish a set of core assertions about a resource from ancillary assertions. See: ''http://dbooth.org/2007/uri-decl/ ''<br /> <br /> <br /> ''Blog Summary: [http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html]<br /> <br /> ''It's been a very long and interesting [http://simile.mit.edu/mail/BrowseList?listName=Linking%20Open%20Data&amp;from=13231&amp;amp;amp;to=13231&amp;by=thread thread] on [http://universimmedia.blogspot.com/2007/02/linking-open-data.html Linking Open Data] forum and elsewhere, about the use and semantics of owl:sameAs. I just suggested the following best practices :''<br /> <br /> # Assertions such as &quot;a:foo owl:sameAs b:bar&quot; should be grounded on some form of agreement of the owners of a:foo and b:bar, on whichever basis they both decide to agree.<br /> # For outsiders (owning neither a: or b: domains), such agreement could be shown by the presence of the assertion in symmetrical way in both domains, each domain using its own URI/resource on subject side, and the other's on object side, that is :(a) asserts &quot;a:foo owl:sameAs b:bar&quot;(b) asserts &quot;b:bar owl:sameAs a:foo&quot;.<br /> # If one side (a) pushes the assertion first, the other side (b) should be at least made aware of it by (a), and is entitled to say she agrees or not : (a) says that &quot;a:foo owl:sameAs b:bar&quot;, but as the owner of (b), I do not necessarily agree. Such lack of agreement could be implicitly entailed from the absence of the reciprocal assertion on (b) side.<br /> <br /> Granted, from a pure logical viewpoint, those assertions are strictly equivalent since owl:sameAs is a symmetrical property, but from a social/trust viewpoint, having each side declaring it in a specific direction could be interpreted as a formal proof of agreement. It's what have been done e.g. between [http://dbpedia.org/resource/Berlin DBpedia] and [http://sws.geonames.org/2950159/ GeoNames]. The title thread shows once again by its sheer length, and if necessary, that there is no universal way to ground such agreement, which belongs to the realm of language and social communication. <br /> <br /> <br /> '''Good points raised:'''<br /> <br /> * Most problems of co-referencing and identity seem to arise from the collapsing of the distinction between entities and information that denotes those entities. Thus the metalevel we need to address is the semiotic one. &lt;nowiki&gt;[Aldo's] proposal is that such metalevel is not necessarily &quot;outside formal semantics&quot;, and some work from my group and elsewhere is proceeding in the direction of a reconciliation between a semiotic, social meaning, &lt;/nowiki&gt;and the formal encoding of meaning.<br /> * A URN and a non-URN URI can be linked by owl:sameAs. Example:urn:ietf:rfc:3187 (URN) owl:sameAs [http://tools.ietf.org/html/rfc3187.html http://tools.ietf.org/html/rfc3187.html] (URL). <br /> * if too many things are sameAs to lots of other things, then the amount of intelligent conclusions you can draw from the LOD cloud will be limited. (Martin Hepp)<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9535 2010-04-12T22:38:28Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Examples:'' <br /> # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.<br /> # A new version of SKOS kept the original namespace. This resulted in changing the semantics of existing URIs. <br /> <br /> ''Conclusions:''<br /> # There are no guidelines for when and whether to create new URIs as ontologies evolve<br /> # There is no consistency in how people are approaching the problem.<br /> # Reasons for this are:<br /> ## insufficient technological infrastructure for ontology maintenance &amp; change management <br /> ## URIs are overloaded <br /> # Approaches include:<br /> ## Mint new URIs even thought the semantics for most may be identical<br /> ## Keep URI the same for a small number of terms even though the semantics may change<br /> ## Use depracation for old terms, keeping the same URI<br /> ## Mint new URIs for only the changed terms.<br /> # Tradeoffs:<br /> ## Attractive for using the ontology for the first time. The proliferation of URIs may result in maintenance and performance issues. <br /> ## Attractive for using the ontology for the first time. Ontology-driven applications may break.<br /> ## Attractive in the case when ontologies are continuously evolving.<br /> ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.<br /> <br /> <br /> '''Original Post:'''<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> '''Summary of Followup Discussion'''<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9534 2010-04-12T22:31:44Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Examples:'' <br /> # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.<br /> # A new version of SKOS kept the original namespace. This resulted in changing the semantics of an existing URI. <br /> <br /> ''Conclusions:''<br /> # There are no guidelines for when and whether to create new URIs as ontologies evolve<br /> # There is no consistency in how people are approaching the problem.<br /> # Reasons for this are:<br /> ## insufficient technological infrastructure for ontology maintenance &amp; change management <br /> ## URIs are overloaded <br /> # Approaches include:<br /> ## Mint new URIs even thought the semantics for most may be identical<br /> ## Keep URI the same for a small number of terms even though the semantics may change<br /> ## Use depracation for old terms, keeping the same URI<br /> ## Mint new URIs for only the changed terms.<br /> # Tradeoffs:<br /> ## Attractive for using the ontology for the first time. The proliferation of URIs may result in maintenance and performance issues. <br /> ## Attractive for using the ontology for the first time. Ontology-driven applications may break.<br /> ## Attractive in the case when ontologies are continuously evolving.<br /> ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.<br /> <br /> <br /> '''Original Post:'''<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> '''Summary of Followup Discussion'''<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9533 2010-04-12T21:54:33Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Examples:'' <br /> # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.<br /> # A new version of SKOS kept the original namespace. This resulted in changing the semantics of an existing URI. <br /> <br /> ''Conclusions:''<br /> <br /> <br /> '''Original Post:'''<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> '''Summary of Followup Discussion'''<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> <br /> There is another alternative in principle:<br /> <br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9532 2010-04-12T21:48:49Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': <br /> * [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> * [http://www.w3.org/2006/07/SWD/track/issues/153 SKOS namespace change: Issue 153]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> '''Original Post:'''<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> '''Summary of Followup Discussion'''<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> <br /> There is another alternative in principle:<br /> <br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9531 2010-04-12T21:43:10Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> '''Original Post:'''<br /> Currently there is no accepted practice on how/whether to migrate to new URIs when a new version of an ontology is published. This is largely due to the fact that there is no good technology for managing versioning, and the W3C consciously (and probably sensibly) decided not to address the issue. Versioning information is meant to be placed on a version annotation.<br /> <br /> However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.<br /> <br /> # Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.<br /> # The SKOS working group is currently (Oct 2008) considering the pros and cons of various options. One is to adopt all new URIs in a new namespace, just like Wordnet. Another is to keep the exact same name space, and change the semantics of a small number of terms while keeping the same URI. A third is to keep the same URI for the unchanged terms, and mint new URIs for the terms with different semantics.<br /> <br /> This is a problem because they have no guidelines, they are basically stumbling along in the dark. I believe that this is an urgent matter that needs attention to prevent a nightmare from unfolding.<br /> <br /> In the current state of semantic web use, it may not matter to much what choice the SKOS team chooses. This is mainly relatively few applications will be impacted, which may be due to the fact that the applications are not driven by the ontologies.<br /> <br /> However, when usage of ontologies and ontology-driven applications becomes more mainstream, the differences could be profound. Given that this issue is intimately tied up with versioning, and that we have no good solutions yet, do we continue to throw our hands up and punt? Absolutely not, it is essential that a good precedent is set ASAP that is based on sound principles. Here is how:<br /> <br /> ''We should imagine a future where ontology versioning is handled properly and do things that are going to make things easy to migrate to that future. We don't know how the versioning black box will work, but we should be able to make some clear and definitive statements about WHAT it does.''<br /> <br /> For example, in the future, ontology-driven applications will be fairly mainstream. URIs are used as unique identifiers. When applications are driven from ontologies, then they will break if you change the semantics in mid-stream. Imagine an application that relied on the semantics of broader as it was originally specified with transitivity. They loaded data that was created using that semantics. Then the SKOS spec changes and broader is no longer transitive. New datasets are created according to this new meaning. The application loads more data. It needs to know which data is subject to transitive closure and which is not. This is impossible, if the same SKOS URI is used for versions with different semantics. They are different beasts, and thus MUST have different URIs.<br /> <br /> Similarly, if SKOS mints a whole new namespace and changes all the URIs, the application also has a problem. It has datasets with the old URI and datasets with the new URIs. This means that the datasets will not be linked like they should, they will treat the two different URIs for the same thing as being different. If one wanted to go into OWL-Full, one can use owl:sameAs, but this is not very practical.&amp;nbsp; The only reasonable solution is to have the same URI for things with the same semantics. Thus, any ontology versioning system of the future will rely on these two principles:<br /> <br /> # If the semantics of a term changes, then it needs to have a new unique ID.<br /> # If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.<br /> <br /> If either of these two guidelines are broken, then so will the ontology-driven applications of the future. These maxims hold without exception for any standards that are formally released as standards. A question arises if we need to hold to the same standards for standards like SKOS which was never formally blessed.<br /> <br /> <br /> '''Summary of Followup Discussion'''<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> <br /> There is another alternative in principle:<br /> <br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Overloading_OWL_sameAs&diff=9530 2010-04-12T21:25:18Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Overloading of owl:sameAs<br /> |Description=General Issue: owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue: ''owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics. <br /> <br /> ''Source:''<br /> <br /> ''Related Discussions:''<br /> <br /> ''Related Modeling Issues'': <br /> * [[Community:Versioning and URIs]]<br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> <br /> ''Examples:''<br /> <br /> ''Conclusions:''<br /> <br /> ''Correct Usages: ''A common case of a correct use is to link one resource that denotes a particular real world object to another resource that denotes the same object. Typically this will be done in two different collections of resources from two different namespaces. Examples:<br /> <br /> * the DBpedia resource referring to a music album should have a sameAs link to a MusicBrainz resource that denotes that same album <br /> * the DBpedia resource referring to a company should have a sameAs link to a DailyMed resource referring to that same company<br /> * an instance of a foaf:Person denoting Tim Berners-Lee should have a sameAs link to the resource in DBLP corresponding to Tim Berners Lee.<br /> <br /> ''Possibly correct usage:''<br /> <br /> * the DBpedia resource referring to a place may have a sameAs link to a GeoNames resource corresponding to that same place<br /> ** &lt;nowiki&gt;&lt;http://dbpedia.org/resource/Bangalore&gt; &lt;http://www.w3.org/2002/07/owl#sameAs&gt; &lt;http://sws.geonames.org/1277333/&gt; .&lt;/nowiki&gt;<br /> ** Note that the geonames reference is to a web page, not necessarily to an RDF resource.<br /> <br /> ''Probably incorrect usages: ''<br /> <br /> # relating a foaf:Person instance to the person's home pageThis should be done using the relationship: foaf:homepage, not owl:sameAs.<br /> # relating a resource denoting a book to a resource that is the Amazon page for the book.<br /> # relating a geographical region with a political entity. For example, the physical area that a city occupies with the city itself.<br /> <br /> The first two are similar in that there is a confusion between a resource denoting a real world entity and a web page that contains information about that real world entity. <br /> <br /> <br /> The books example is interesting because for most intents and purposes, people just want to say: yes, the books we are talking about in each case are the same. So owl:sameAs seems highly appropriate. This likely work much of the time. It could be a problem for someone wanting to analyze an Amazon web page for say its structure and layout. Then the book that the web page is featuring is an attribute of the web page, not the web page itself.<br /> <br /> <br /> ''Issue: ''even if the usage is strictly incorrect, in some cases it may not matter. It depends on the intended use. Using owl:sameAs in a variety of ways with somewhat vague semantics can actually be an advantage.<br /> <br /> <br /> We can have best of both worlds if we have a more generic relation that is being used the way owl:sameAs is now (vaguely) and having sub-relations that have more specific meanings. <br /> <br /> <br /> ''Issue: ''If we move to a new vocabulary of similarity relationships that inludes the curent sameAs (as strictly defined) as well as a looser relationship (as sameAs is often used in practice), then there is a communication and migration challenge getting people to use them correctly.<br /> <br /> Maybe what is now called “sameAs: should be renamed to “literalSameAs� and then the strictly correct uses of sameAs could be changed to literalSameAs, and the loose ones would remain the same. <br /> <br /> <br /> '''Ideas / Proposals'''<br /> <br /> ''More vocabulary needed to cover different cases. The vocabulary should provide clear and formal semantics, in the way that sameAs has, the semantics will be weaker.''<br /> <br /> ''Essentially the same thing: ''The main thing being talked about by one resource is for all ''non-technical'' intents and purposes the same thing that is being talked about by the other resource.Examples<br /> <br /> * <br /> ** DBpedia country related to the corresponding GeoNames URI. <br /> ** a person or company related to their home page. There already is a foaf:page relationship for this, so this could be set as a sub-property of ''EssentiallyTheSameThing''<br /> ** A book like, On the Road and various ISBNs for various manifestations of that book. <br /> <br /> ''Use existing properties like rdfs: seeAlso and skos:related to denote similarity, which is what owl:sameAs is often used for.''<br /> <br /> This may have some merit, but often these have too weak a semantics.<br /> <br /> <br /> Distinguish a set of core assertions about a resource from ancillary assertions. See: ''http://dbooth.org/2007/uri-decl/ ''<br /> <br /> <br /> ''Blog Summary: [http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html]<br /> <br /> ''It's been a very long and interesting [http://simile.mit.edu/mail/BrowseList?listName=Linking%20Open%20Data&amp;from=13231&amp;amp;amp;to=13231&amp;by=thread thread] on [http://universimmedia.blogspot.com/2007/02/linking-open-data.html Linking Open Data] forum and elsewhere, about the use and semantics of owl:sameAs. I just suggested the following best practices :''<br /> <br /> # Assertions such as &quot;a:foo owl:sameAs b:bar&quot; should be grounded on some form of agreement of the owners of a:foo and b:bar, on whichever basis they both decide to agree.<br /> # For outsiders (owning neither a: or b: domains), such agreement could be shown by the presence of the assertion in symmetrical way in both domains, each domain using its own URI/resource on subject side, and the other's on object side, that is :(a) asserts &quot;a:foo owl:sameAs b:bar&quot;(b) asserts &quot;b:bar owl:sameAs a:foo&quot;.<br /> # If one side (a) pushes the assertion first, the other side (b) should be at least made aware of it by (a), and is entitled to say she agrees or not : (a) says that &quot;a:foo owl:sameAs b:bar&quot;, but as the owner of (b), I do not necessarily agree. Such lack of agreement could be implicitly entailed from the absence of the reciprocal assertion on (b) side.<br /> <br /> Granted, from a pure logical viewpoint, those assertions are strictly equivalent since owl:sameAs is a symmetrical property, but from a social/trust viewpoint, having each side declaring it in a specific direction could be interpreted as a formal proof of agreement. It's what have been done e.g. between [http://dbpedia.org/resource/Berlin DBpedia] and [http://sws.geonames.org/2950159/ GeoNames]. The title thread shows once again by its sheer length, and if necessary, that there is no universal way to ground such agreement, which belongs to the realm of language and social communication. <br /> <br /> <br /> '''Good points raised:'''<br /> <br /> * Most problems of co-referencing and identity seem to arise from the collapsing of the distinction between entities and information that denotes those entities. Thus the metalevel we need to address is the semiotic one. &lt;nowiki&gt;[Aldo's] proposal is that such metalevel is not necessarily &quot;outside formal semantics&quot;, and some work from my group and elsewhere is proceeding in the direction of a reconciliation between a semiotic, social meaning, &lt;/nowiki&gt;and the formal encoding of meaning.<br /> * A URN and a non-URN URI can be linked by owl:sameAs. Example:urn:ietf:rfc:3187 (URN) owl:sameAs [http://tools.ietf.org/html/rfc3187.html http://tools.ietf.org/html/rfc3187.html] (URL). <br /> * if too many things are sameAs to lots of other things, then the amount of intelligent conclusions you can draw from the LOD cloud will be limited. (Martin Hepp)<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9529 2010-04-12T21:22:34Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion initially took place off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Overloading OWL sameAs]]<br /> * [[Community:Versioning and URIs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> ''Conclusions:'' <br /> # to some extent, URI proliferation is inevitable in an open web. It is probably the only way to allow people to independently publish web data.<br /> # We will have to rely on a combination of manual effort and sophisticated automated methods to detect clashes, and attempt to resolve them. There is a difference of opinion of how good a job automated techniques can do.<br /> # large scale duplication of URIs as in the case of YAGO and DBpedia, is unfortunate, but has now largely been rectified. That it happened at all is due to this all being very new.<br /> # it was argued that it does not matter much because noone is going to load all the triples into a one triple store. A counter argument to this is that even if you load a lot of triples into one store, the problem of inefficiency of sameAs reasoning can arise.<br /> # that these issues are arising at all can be seen as a good thing, insofar as it reflects that linked data is being made available and put to real use. Tim Berners-Lee notes that: &quot;Life is, on balance, good.&quot;<br /> <br /> <br /> '''Original Post'''<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> '''Summary of Responses''' <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9528 2010-04-12T21:20:15Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': [http://lists.w3.org/Archives/Public/semantic-web/2008Oct/0192.html URIs and Unique IDs] from [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web List]<br /> <br /> ''Related Discussions'': [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> <br /> ''Related Modeling Issues:'' <br /> * [[Community:Proliferation of URIs, Managing Coreference]]<br /> * [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> <br /> There is another alternative in principle:<br /> <br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Versioning_and_URIs&diff=9527 2010-04-12T21:09:38Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: Versioning and URIs<br /> |Description=General Issue: When and whether to make new URIs for different versions of things.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': When and whether to make new URIs for different versions of things.<br /> <br /> ''Source'': <br /> <br /> ''Related Discussions'': [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]<br /> <br /> ''Example 1: WordNet''<br /> <br /> The WordNet maintainers published a new version in OWL format and used a new namespace which contained the new version number in it. This means that every single resource in Wordnet now has a different URI, even though many are exactly the same as before. <br /> <br /> ''Example 2: SKOS''<br /> <br /> In 2008, the SKOS working group is updated the SKOS vocabulary/ontology. They have decided that two terms have the wrong semantics, and the new version will reflect the correct semantics. The majority of the terms are unchanged. They chose not to mint all new URIs, but rather to use the same URI for terms with different semantics.<br /> <br /> ''Example 3: Open Biomedical Ontologies ''<br /> <br /> There is an explicit policy of ''not'' changing URIs as new versions of the ontology are released - for one thing that would be impractical – some of them are updated daily. Rather there is a policy on deprecation - terms that are deprecated are marked as such and kept in the ontology so as not to leave dangling pointers. ([http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg])<br /> <br /> <br /> ''Continuous vs. Discrete Ontology Evolution''<br /> <br /> Examples 1 and 2 relate to the case where an ontology is undergoing discrete evolution - ''i.e. ''a specific effort is undertaken to update the ontology resulting in a new version. Example 3 relates to a the case where an ontology is undergoing (more or less) continuous evolution - ''i.e. ''it is changing all the time, and no attempt is made to create and name a new version of the ontology, per se. These cases may be sufficiently different to warrant different approaches.<br /> <br /> <br /> ''Approaches:''<br /> <br /> # Mint new URIs for all terms, even when the semantics does not change (Example 1:Wordnet) <br /> # Keep the URIs the same but change the semantics (Example 2: SKOS)<br /> # Do not change URIs as new versions of the ontology are released. Depracate old terms and leave them in the ontology marked as such. (Example 3: Open Biomedical Ontologies)<br /> <br /> There is another alternative in principle:<br /> <br /> # Mint new URIs for all and only the terms whose semantics changed. In the case of SKOS, this would mean new URIs for the small number of terms that changed. The ontology would presumably also get a new URI because it changed. (No examples).<br /> <br /> <br /> ''Tradeoffs:''<br /> <br /> Option 1 has the apparent advantage of starting with a clean slate, and would be attractive to anyone using the ontology for the first time. However it causes a proliferation of URIs, with consequent maintenance and performance problems. Maintenance becomes problematic because the developer of the ontology-based applications needs to carefully ensure things are in order. If they are, then owl:sameAs can be used to link the old and new URIs, which is a performance problem. <br /> <br /> Option 2 is also attractive to anyone who is using SKOS for the first time. However it breaks a trust in the use of a URI as a unique resource. It creates a new beast with a new semantics which should have a new name. This runs the risk of breaking applications that rely on that trust. <br /> <br /> Option 3: is attractive because it retains backwards compatibility, but does so at the cost of extra infrastructural support.<br /> <br /> Option 4 is attractive to anyone who wants to do things that are 'semantically proper'. This was verified by an informal poll at ISWC-2008. I asked Aldo Gangemi, Sean Bechofer, Ian Horrocks, Jeff Pan, Peter Mika, Ora Lassila, Terri Payne, Martin Hepp, Fausto G. One of these polled nevertheless preferred option 2, believing that some practical concerns trumped the semantic ones. This option is unattractive because it seems messy to have one ontology with two namespaces. It could lead in the future to arbitrarily many namespaces for the same ontology, as it evolves over time. This could all be solved with proper change management infrastructure, as yet to be invented.<br /> <br /> <br /> ''Root Causes''<br /> <br /> Basically, people often know what the right thing to do is, but it is often too easy and expedient to do the wrong thing. This is exacerbated by the lack of necessary infrastructure to do the right thing. There are some key root causes.<br /> <br /> # lack of a good technological infrastructure for ontology maintenance<br /> # lack of a good technological infrastructure for change management <br /> # overloading of URIs<br /> <br /> <br /> ''Maintenance'': Currently, URIs are not sacred, they can change at the whims of their authors/maintainers. The only way to be sure is to mint and manage your own URIs and link them to other ones as a courtesy. This leads to a proliferation of URIs.<br /> <br /> ''Change management: ''Initially, the W3C consciously (and probably sensibly) decided not to address the change management and versioning issue. A stop gap solution using annotation properties was provided instead. This is not going to be solved in the short term. <br /> <br /> ''URI overloading: ''Take a simple example from Wordnet. The following URL is being use for the many different things: &lt;nowiki&gt;http://wordnet.princeton.edu/wordnet/v2.2/pickle&lt;/nowiki&gt;. This is being used to denote the authoring organization, the name of the ontology, the version of both the ontology and the ontology term, the URL, the name of the term as well as being a unique identifier. Most of these things should be able to change, leaving the URI the same. This being a common way to do things makes it too tempting to do things the 'wrong way'.<br /> <br /> [http://lists.w3.org/Archives/Public/semantic-web/2008Nov/0073.html Alan Ruttenberg] points out that this likely contributed to the SKOS problem. The terms that changed were broader and its inverse. They are no longer transitive. If the URIs were UIDs only, then you could have simply changed the label on the old broader to ''broader transitive'' and moved on. This is a key reason for a movement to use opaque numeric UIDs for concepts in the Open Biomedical Ontologies.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Resource_multiple_attribution&diff=9526 2010-04-12T02:30:32Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: RDF Resource multiple attribution<br /> |Description=General Issue: How to attribute a single resource with two values of the same property in one document<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=Intellectual Property, General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to attribute a single resource with two values of the same property in one document<br /> <br /> ''Example: ''publishing multiple licenses along with one rdf document. <br /> <br /> ''Source'': The thread: [http://lists.w3.org/Archives/Public/public-lod/2009Dec/0046.html attaching multiple licenses] ([http://markmail.org/thread/xu4hywhgexdmrzje Markmail]) in the [http://lists.w3.org/Archives/Public/public-lod/ W3C Linked Open Data Discussion List.]<br /> <br /> ''Conclusions:''<br /> <br /> # One way is to use RDF reification, but this has some issues.<br /> # OWL 2 has Axiom Annotations designed to do this.<br /> # Caution: approaches often won't work unless the community adopts conventions and follows them.<br /> # Principles: <br /> ## two documents about the same resource should serve the same data<br /> ## data should not be replicated all over the place<br /> <br /> <br /> ''Georgi Kobilarov'' posed the [http://markmail.org/message/xu4hywhgexdmrzje original question]: <br /> <br /> I'm looking for a best practice for publishing multiple licenses along with one rdf document. Say I publish one URI for an artist: [http://example.org/resource/Madonna http://example.org/resource/Madonna]. <br /> I aggregate information from multiple sources about that artist, and those sources have different licenses. One triple comes from a source under GNU FDL, another triple from a source under Public Domain, and a owl:sameas link which I want to publish under Creative Commons License. <br /> <br /> Any pointers to how to do that?<br /> <br /> <br /> ''Toby Inkster'' [http://markmail.org/message/y65ytyk7iyus5mix suggests] two options. One is reification, where you could create a statement resource which has the usual subject, predicate and object properties and an additional one for the licence. The other is to publish your data in a format that can make use of multiple graphs (e.g. N3). Unfortunately, this is not well supported in triple-consuming software.<br /> <br /> However, you can fake named graphs in RDF/XML and Turtle, for example, by splitting the data into multiple documents and use rdfs:seeAlso links between the files to enable auto-dicovery. You could also duplicate that data - but that introduces other problems.<br /> <br /> <br /> ''Georgi Kobilarov'' [http://markmail.org/message/vi3wyhfqwk6d7qxj responds that] this solution would run into the issue that &quot;two documents about the same resource should serve the same data&quot;. The html output would probably show all triples, but the content negotiated / 303ed rdf document would contain only links to other rdf documents. This would have to be set as common practice for it to work.<br /> <br /> <br /> ''Tom Heath'' [http://markmail.org/message/i5stbltaiajlvpip suggests] including the triples by reference to the source documents, rather than replicating external triples. In his view, &quot;&lt;nowiki&gt;there's something that feels fundamentally wrong about replicating RDF data rather than just pointing applications to the places where they can find it... [it] seems &lt;/nowiki&gt;fundamentally un-Web-like&quot;<br /> <br /> <br /> ''Alan Ruttenberg'' [http://markmail.org/message/p2r4ne6woyoxr6ip points out that] OWL 2 provides a documented way of doing this using [http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Annotations Axiom Annotations] along with a mechanism for [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Translation_of_Axioms_with_Annotations translating axioms with annotations]. It will last, and avoids confusion caused by RDF reification.<br /> <br /> <br /> ''Keith Alexander'' [http://markmail.org/message/tr3riemv72ujlbif adds]: I think that any publishers of linked data that want to place some restrictions on how their data is reused, should provide clearer guidelines on the technical solutions to fulfilling those requirements. Maybe if they thought about it and realised how confusing it all is, they'd decide they didn't really want to restrict reuse that much in the first place.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Resource_multiple_attribution&diff=9525 2010-04-12T02:23:43Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=General Issue: RDF Resource multiple attribution<br /> |Description=General Issue: How to attribute a single resource with two values of the same property in one document<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=Intellectual Property, General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to attribute a single resource with two values of the same property in one document<br /> <br /> ''Example: ''publishing multiple licenses along with one rdf document. <br /> <br /> ''Source'': The thread: [http://markmail.org/thread/xu4hywhgexdmrzje attaching multiple licenses] in the [http://lists.w3.org/Archives/Public/public-lod/ W3C Linked Open Data Discussion List.]<br /> <br /> ''Conclusions:''<br /> <br /> # One way is to use RDF reification, but this has some issues.<br /> # OWL 2 has Axiom Annotations designed to do this.<br /> # Caution: approaches often won't work unless the community adopts conventions and follows them.<br /> # Principles: <br /> ## two documents about the same resource should serve the same data<br /> ## data should not be replicated all over the place<br /> <br /> <br /> ''Georgi Kobilarov'' posed the [http://markmail.org/message/xu4hywhgexdmrzje original question]: <br /> <br /> I'm looking for a best practice for publishing multiple licenses along with one rdf document. Say I publish one URI for an artist: [http://example.org/resource/Madonna http://example.org/resource/Madonna]. <br /> I aggregate information from multiple sources about that artist, and those sources have different licenses. One triple comes from a source under GNU FDL, another triple from a source under Public Domain, and a owl:sameas link which I want to publish under Creative Commons License. <br /> <br /> Any pointers to how to do that?<br /> <br /> <br /> ''Toby Inkster'' [http://markmail.org/message/y65ytyk7iyus5mix suggests] two options. One is reification, where you could create a statement resource which has the usual subject, predicate and object properties and an additional one for the licence. The other is to publish your data in a format that can make use of multiple graphs (e.g. N3). Unfortunately, this is not well supported in triple-consuming software.<br /> <br /> However, you can fake named graphs in RDF/XML and Turtle, for example, by splitting the data into multiple documents and use rdfs:seeAlso links between the files to enable auto-dicovery. You could also duplicate that data - but that introduces other problems.<br /> <br /> <br /> ''Georgi Kobilarov'' [http://markmail.org/message/vi3wyhfqwk6d7qxj responds that] this solution would run into the issue that &quot;two documents about the same resource should serve the same data&quot;. The html output would probably show all triples, but the content negotiated / 303ed rdf document would contain only links to other rdf documents. This would have to be set as common practice for it to work.<br /> <br /> <br /> ''Tom Heath'' [http://markmail.org/message/i5stbltaiajlvpip suggests] including the triples by reference to the source documents, rather than replicating external triples. In his view, &quot;&lt;nowiki&gt;there's something that feels fundamentally wrong about replicating RDF data rather than just pointing applications to the places where they can find it... [it] seems &lt;/nowiki&gt;fundamentally un-Web-like&quot;<br /> <br /> <br /> ''Alan Ruttenberg'' [http://markmail.org/message/p2r4ne6woyoxr6ip points out that] OWL 2 provides a documented way of doing this using [http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Annotations Axiom Annotations] along with a mechanism for [http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Translation_of_Axioms_with_Annotations translating axioms with annotations]. It will last, and avoids confusion caused by RDF reification.<br /> <br /> <br /> ''Keith Alexander'' [http://markmail.org/message/tr3riemv72ujlbif adds]: I think that any publishers of linked data that want to place some restrictions on how their data is reused, should provide clearer guidelines on the technical solutions to fulfilling those requirements. Maybe if they thought about it and realised how confusing it all is, they'd decide they didn't really want to restrict reuse that much in the first place.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9524 2010-04-12T01:57:46Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion initially took place off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> ''Conclusions:'' <br /> # to some extent, URI proliferation is inevitable in an open web. It is probably the only way to allow people to independently publish web data.<br /> # We will have to rely on a combination of manual effort and sophisticated automated methods to detect clashes, and attempt to resolve them. There is a difference of opinion of how good a job automated techniques can do.<br /> # large scale duplication of URIs as in the case of YAGO and DBpedia, is unfortunate, but has now largely been rectified. That it happened at all is due to this all being very new.<br /> # it was argued that it does not matter much because noone is going to load all the triples into a one triple store. A counter argument to this is that even if you load a lot of triples into one store, the problem of inefficiency of sameAs reasoning can arise.<br /> # that these issues are arising at all can be seen as a good thing, insofar as it reflects that linked data is being made available and put to real use. Tim Berners-Lee notes that: &quot;Life is, on balance, good.&quot;<br /> <br /> <br /> '''Original Post'''<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> '''Summary of Responses''' <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9523 2010-04-12T01:56:18Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion initially took place off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> ''Conclusions:'' <br /> # to some extent, URI proliferation is inevitable in an open web. It is probably the only way to allow people to independently publish web data.<br /> # We will have to rely on a combination of manual effort and sophisticated automated methods to detect clashes, and attempt to resolve them. There is a difference of opinion of how good a job automated techniques can do.<br /> # large scale duplication of URIs as in the case of YAGO and DBpedia, is unfortunate, but has now largely been rectified. That it happened at all is due to this all being very new.<br /> # it was argued that it does not matter much because noone is going to load all the triples into a one triple store. A counter argument to this is that even if you load a lot of triples into one store, the problem of inefficiency of sameAs reasoning can arise.<br /> # that these issues are arising at all can be seen as a good thing, insofar as it reflects that linked data is being made available and put to real use. Tim Berners-Lee notes that: &quot;On balance, life is good.&quot;<br /> <br /> <br /> '''Original Post'''<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> '''Summary of Responses''' <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9522 2010-04-12T01:44:23Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0078.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion initially took place off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> <br /> '''Original Post'''<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> '''Summary of Responses''' <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9521 2010-04-12T01:43:30Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0078.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion tool initially off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> <br /> '''Original Post'''<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> <br /> '''Summary of Responses''' <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9520 2010-04-12T01:42:01Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0078.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion tool initially off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> <br /> '''Original Post'''<br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> Below is a summary of the responses. <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9519 2010-04-12T01:40:20Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this. <br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': How to avoid or manage two negative consequences to the current proliferation of new URIs being minted for the same things. Specifically: <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0078.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion tool initially off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example(s)'' <br /> # Wordnet issued new URIs for all of its terms for the new version, even when they referred to exactly the same thing.<br /> # Yago and DBpedia minted different URIs for the exact same Yago classes<br /> <br /> Here is the original Post by Michael Uschold in May 2008:<br /> <br /> This message is about URI proliferation on the Semantic Web, illustrated by examples from DBpedia, YAGO and Wordnet. Consider this: <br /> <br /> # The [http://wzus.ask.com/r?t=p&amp;d=us&amp;s=a&amp;c=a&amp;l=dir&amp;o=0&amp;sv=0a300517&amp;ip=48331b72&amp;id=C70CD4877AC94DDE30A935341869788A&amp;q=yago+wikipedia&amp;p=1&amp;qs=0&amp;ac=3&amp;g=081apnaichsczS&amp;en=te&amp;io=8&amp;ep=&amp;eo=&amp;b=alg&amp;bc=&amp;br=&amp;tp=d&amp;ec=10&amp;pt=Yago%20-%20A%20Core%20of%20Semantic%20Knowledge&amp;ex=tsrc%3Dtxtx&amp;url=&amp;u=http://www.mpi-inf.mpg.de/%7Esuchanek/downloads/yago/ Yago team] ontologized a portion of the Wikipedia category hierarchy and produced a set of YagoClasses, each corresponding to exactly one WordNet synset.&amp;nbsp; Here is a sample URI:&lt;br/&gt; [http://www.mpii.de/yago/resource/wordnet_calculator_102938886 http://www.mpii.de/yago/resource/wordnet_calculator_102938886] <br /> # The [http://dbpedia.org/ DBpedians ]saw that it was good, so they added the Yago classes to their datasets. BUT:&amp;nbsp; Different URIs were used.&lt;br/&gt; [http://dbpedia.org/class/yago/Calculator102938886 http://dbpedia.org/class/yago/Calculator102938886]<br /> # I found several URI conventions for Wordnet on the web, here are 3 (of how many?):<br /> ## [http://xmlns.com/wordnet/1.6/ http://xmlns.com/wordnet/1.6/] &lt;br/&gt; See: [http://xml.coverpages.org/CC-Metadata-spec-10b2.html http://xml.coverpages.org/CC-Metadata-spec-10b2.html]<br /> ## [http://wordnet.princeton.edu/%7Eagraves/wordnet/0.9/ http://wordnet.princeton.edu/~agraves/wordnet/0.9/] '''&lt;br/&gt; See: [http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1 http://www.idealliance.org/papers/extreme/proceedings/html/2006/Freese01/EML2006Freese01.html#t4-1]<br /> ## [http://www.w3.org/2006/03/wn/wn20/instances/ http://www.w3.org/2006/03/wn/wn20/instances/] '''&lt;br/&gt; See: [http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf http://www.w3.org/2006/03/wn/wn20/rdf/wordnet-frame.rdf]<br /> <br /> The synset IDs in the first two cases (hardwired into the URIs) are from version 3.0, but one has to poke around to discover that. There might be version problems too, ''but that's another elephant.''There are various issues here:<br /> <br /> # What is the true relationship between all these URIs? e.g are they identical in meaning?&amp;nbsp; In general, there is no good way to determine what this relationship is.<br /> # Why are there so many URIs for ostensibly the same exact thing?<br /> # Even if you do find out the exact semantic relationship, what is a practical way to resolve it?&amp;nbsp;&amp;nbsp;<br /> ## Using &lt;tt&gt;'''owl:sameAs''' &lt;/tt&gt;or &lt;tt&gt;'''owl:equivalentClass'''&lt;/tt&gt; may be adequate ''logically,&amp;nbsp; ''but IMHO, is wholly inadequate, ''practically. ''Adding large number of redundant triples and requiring inferencing will burden the already limited capabilities of knowledge stores at large scale.<br /> ## pre-processsing all the files with a script changing the URIs may be possible, but has its own issues:<br /> ### what URI should be the one chosen, yet a new one? That exacerbates the problem.<br /> ### a simple namespace prefix would be easy to deal with, but in the example above the names are also different. e.g. '''wordnet_calculator_102938886 '''vs. '''Calculator102938886'''&lt;br/&gt; Writing scripts that rely on naming conventions is dangerous. They may not be consistently applied and there may be 100s or 1000s or millions to check.<br /> ### The scripts have to be re-checked and revised and re-run each time a new version comes online<br /> <br /> Specific Questions/Recommendations to the DBpedia and Yago teams: <br /> <br /> * would it&amp;nbsp; be possible to agree on a single URI for the Yago classes, and then use some other mechanism to go to the right URL? <br /> * what is the proper logical relationship between the Yago classes and the wordnet synsets? <br /> * Should they be taken as logically equivalent or merely as 'corresponding' to each other in some manner?&amp;nbsp;<br /> * Might that correspondence be expressed with a meta-level property,&amp;nbsp; (say correspondingSynset) with domain: YagoClass and range: WordNetSynset?<br /> <br /> <br /> <br /> <br /> <br /> In summary: <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> Below is a summary of the responses. <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9518 2010-04-12T00:54:37Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this. <br /> <br /> ''Source:'' This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0078.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion tool initially off the list, and then was moved to the list for the record. <br /> <br /> ''Related Discussions'': <br /> <br /> ''Related Modeling Issues:'' [[Community:Overloading OWL sameAs]]<br /> <br /> ''Example(s)''<br /> <br /> Here is a summary of the first part.<br /> <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> Below is a summary of the responses. <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold http://ontologydesignpatterns.org/index.php?title=Community:Proliferation_of_URIs,_Managing_Coreference&diff=9517 2010-04-12T00:48:58Z

<p>MichaelUschold: </p> <hr /> <div>{{TitleDescription Template<br /> |Title=Proliferation of URIs, Managing Coreference<br /> |Description=General Issue: There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this.<br /> }}<br /> {{Graphical representation}}<br /> {{Modeling Issue Template<br /> |Author=MichaelUschold,<br /> |Domain=General<br /> }}<br /> {{Additional information header}}<br /> ''Issue'': There are some negative consequences to the current proliferation of new URIs being minted for the same things. The issue is how to avoid or manage this. <br /> <br /> <br /> This issue is related to modelling issue: [[Community:Overloading OWL sameAs]]<br /> <br /> <br /> This discussion is taken from a thread called [http://lists.w3.org/Archives/Public/semantic-web/2008May/0078.html Managing Co-reference (Was: A Semantic Elephant?)] on the [http://lists.w3.org/Archives/Public/semantic-web/ W3C Semantic Web Discussion List]. A vigorous discussion tool initially off the list, and then was moved to the list for the record. Here is a summary of the first part.<br /> <br /> <br /> In Uschold's original post to selected individuals, it was noted that a proliferation of different URIs for the same resource was occurring, and that it was causing two specific problems:<br /> <br /> # it is hard to find when two things should be the same<br /> # even if you can find the links, prolific use of owl:sameAs will create computational problems.<br /> <br /> Below is a summary of the responses. <br /> <br /> ''Chris Bizer:''<br /> <br /> Problem 1 is not really so bad, for there is much matching technology is out there that can be used, albeit there will be some limits on precision. Problem 2 is not a problem either because noone is going to load everything into a single store.<br /> <br /> <br /> ''Frank van Harmelen''<br /> <br /> Problem 1 is very real, but is only recently becoming a problem with the recent surge of semantic web data coming on line. Frank disagrees with Chris Bizer's optimism. Also, matching at the schema/class level is handled differently than matching instance. Frank refers to some good work going on in addressing these issues, not by matching after the fact, but by elminiting the proliferation at source.<br /> <br /> # [http://sindice.com/ http://sindice.com/]<br /> # [http://www.sindice.com/pdf/sindice-ijmso2008.pdf http://www.sindice.com/pdf/sindice-ijmso2008.pdf]<br /> # [http://www.okkam.org/ http://www.okkam.org/]<br /> # [http://www.okkam.org/IRSW2008 http://www.okkam.org/IRSW2008]<br /> <br /> ''Chris Bizer:''<br /> <br /> My optimism was more about instance level identity links than at the class level. Within the LOD effort we repeatedly run into situations where it is really easy to generate owl:sameAs links based on some simple domain-dependent rules.<br /> <br /> <br /> ''Kinsgley Idehan'':<br /> <br /> The URL problems are being addressed, e.g. in the UMBEL project. Wikipedia, OpenCye, WordNet and Yago Ideitifiers are being rationalized. See: [http://www.umbel.org/announcement.xhtml http://www.umbel.org/announcement.xhtml]<br /> <br /> ''Fred Giasson: ''<br /> <br /> There are edge cases when it is not immediately clear, even for a human, to decide what deserves a unique URI. <br /> <br /> <br /> ''Jim Hendler: ''<br /> <br /> &quot;So what you are really saying is scaling is a technology/research challenge now that there's much more out there. We need to go beyond just triple stores and get some fast inferencing at Web scales. Makes sense to me.&quot;<br /> <br /> <br /> ''Michael Uschold:'' <br /> <br /> The computational issue of owl:sameAs proliferation is a major problem, even if noone is going to load all the semantic web data into a single store. For today's triple stores that do limited inference, owl:sameAs &quot;has a significant run time&quot; [http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html#rdfsparqlruleintro according to the developers of OpenLink's Virtuoso triplestore]. It can easily [http://www.openlinksw.com/weblog/oerling/?id=1347 double query times].<br /> <br /> Chris Bizer's remark that there is no need to worry because noone is going to load ''all ''the data misses two important facts. First, companies that build and delivering software products using public data will have to bring the data they are using in house to control it. Second, you don't have to load ''all ''the data before computational issues arise. Do you really think that, for example, Powerset relies on the data sitting on the DBpedia servers. Proliferation of URIs on a large scale will cause performance issues and should be avoided where possible.<br /> <br /> <br /> ''Soren Auer:''<br /> <br /> Even with such proliferation, people will be able to build useful applications. Once, certain information sources are established (and for that page rank inspired data rank algorithms could be developed) - people will automatically tend to reuse established identifiers and this will counteract the proliferation.<br /> <br /> <br /> ''Tim Berners-Lee''<br /> <br /> So multiple URIs for the same thing is life, a constant tradeoff, but life is, on balance good.<br /> {{My references}}<br /> {{Modeling Issue toolbar}}</div>

MichaelUschold