Community:Versioning and URIs - Revision history

MichaelUschold at 22:01, 13 April 2010

2010-04-13T22:01:55Z

MichaelUschold at 21:47, 13 April 2010

2010-04-13T21:47:46Z

MichaelUschold at 21:44, 13 April 2010

2010-04-13T21:44:16Z

MichaelUschold at 21:40, 13 April 2010

2010-04-13T21:40:59Z

MichaelUschold at 22:38, 12 April 2010

2010-04-12T22:38:28Z

MichaelUschold at 22:31, 12 April 2010

2010-04-12T22:31:44Z

MichaelUschold at 21:54, 12 April 2010

2010-04-12T21:54:33Z

MichaelUschold at 21:48, 12 April 2010

2010-04-12T21:48:49Z

MichaelUschold at 21:43, 12 April 2010

2010-04-12T21:43:10Z

MichaelUschold at 21:20, 12 April 2010

2010-04-12T21:20:15Z

@@ Line 43: / Line 43: @@
 ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.
-== Background ==
+{{Semantic Elephant Text}}
-In May 2008, Michael Uschold kicked off a discussion with the subject "A Semantic Elephant" 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?)].
-−
-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].
-−
-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].
-−
-From all this, Uschold teased out three distinct but closely related modeling isssues that are in this ODP Wiki:
-−
-# [[Community:Overloading OWL sameAs]]: sameAs is being used in the linked data community in a way that is inconsistent with its semantics
-# [[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:
-## it is hard to find when two things should be the same
-## even if you can find the links, prolific use of owl:sameAs will create computational problems.
-# [[Community:Versioning and URIs]]: When and whether to make new URIs for different versions of things.
 ==Original Post==

@@ Line 44: / Line 44: @@
 == Background ==
-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?)].
+In May 2008, Michael Uschold kicked off a discussion with the subject "A Semantic Elephant" 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?)].
 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].
@@ Line 56: / Line 56: @@
 ## it is hard to find when two things should be the same
 ## even if you can find the links, prolific use of owl:sameAs will create computational problems.
-# [Community:Versioning and URIs]: When and whether to make new URIs for different versions of things.
+# [[Community:Versioning and URIs]]: When and whether to make new URIs for different versions of things.
 ==Original Post==

@@ Line 52: / Line 52: @@
 From all this, Uschold teased out three distinct but closely related modeling isssues that are in this ODP Wiki:
-# ''Overloading owl:sameAs'': sameAs is being used in the linked data community in a way that is inconsistent with its semantics
+# [[Community:Overloading OWL sameAs]]: sameAs is being used in the linked data community in a way that is inconsistent with its semantics
-# ''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:
+# [[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:
 ## it is hard to find when two things should be the same
 ## even if you can find the links, prolific use of owl:sameAs will create computational problems.
-# ''Versioning and URIs: ''When and whether to make new URIs for different versions of things.
+# [Community:Versioning and URIs]: When and whether to make new URIs for different versions of things.
 ==Original Post==

@@ Line 9: / Line 9: @@
 }}
 {{Additional information header}}
 ''Issue'': When and whether to make new URIs for different versions of things.
@@ Line 42: / Line 43: @@
 ## Avoids maintenance and performance issues, ontology-driven applications will not break. Challenge is lack of infrastructural support to do this accurately and efficiently.
-'''Original Post:'''
+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].
 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.
@@ Line 69: / Line 84: @@
-'''Summary of Followup Discussion'''
+==Summary of Followup Discussion==
 ''Example 1: WordNet''

@@ Line 23: / Line 23: @@
 ''Examples:''
 # A new version of Wordnet used a different namespace, so there were many new URIs minted for resources that were semantically identical.
-# A new version of SKOS kept the original namespace. This resulted in changing the semantics of an existing URI.
+# A new version of SKOS kept the original namespace. This resulted in changing the semantics of existing URIs.
 ''Conclusions:''

@@ Line 26: / Line 26: @@
 ''Conclusions:''
@@ Line 79: / Line 94: @@
 # Keep the URIs the same but change the semantics (Example 2: SKOS)
 # 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)
 # 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).

@@ Line 13: / Line 13: @@
 ''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]
-''Related Discussions'': [http://lists.w3.org/Archives/Public/semantic-web/2008May/0081.html Managing Co-reference (Was: A Semantic Elephant?)]
+''Related Discussions'':
 ''Related Modeling Issues:''

← Older revision		Revision as of 21:43, 12 April 2010
Line 30:		Line 30:

	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])		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])
		+
		+	'''Original Post:'''
		+	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.
		+
		+	However the current situation is like the wild West, and everyone will be doing different things, resulting in a mess.
		+
		+	# Wordnet published a new version and minted all new URIs even though many or most of the entries were semantically identical.
		+	# 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.
		+
		+	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.
		+
		+	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.
		+
		+	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:
		+
		+	''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.''
		+
		+	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.
		+
		+	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.  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:
		+
		+	# If the semantics of a term changes, then it needs to have a new unique ID.
		+	# If the semantics of a term does NOT change, then it should maintain the same ID in any future versions.
		+
		+	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.
		+
		+
		+	'''Summary of Followup Discussion'''