Re: URIs and Unique IDs

It seems to me that in cases where an application wants to use the most up
to date version of something, you don't have to change the semantics and
keep the same UID. You can instead have a subscription service with allows
an application to be notified of every change to new versions.  Then the
application that wants the new version can have a mechanism for updating
it's innards to replace every occurrence of the old UID with the new one.

For applications that need to retain both can do that too. Everyone can be
happy.

Michael

On Sat, Nov 1, 2008 at 2:31 PM, Michael F Uschold <uschold@gmail.com> wrote:

> See inline comments.
>
> On Thu, Oct 30, 2008 at 4:20 PM, Michael Lang(Jr.) <
> michaelallenlang@gmail.com> wrote:
>
>> Michael,
>>
>> I'm not sure that its as cut and dry as:
>>
>> "Thus, any ontology versioning system of the future will rely on these two
>> principles:
>> 1. If the semantics of a term changes, then it needs to have a new unique
>> ID.
>> 2. If the semantics of a term does NOT change, then it should maintain the
>> same ID in any future versions."
>>
>>
>> There will certainly be times when an ontology-driven application is
>> purposely dependent on the evolution of the semantics of a term.
>>
>>
>  In other words, the application wants to change its behavior when the
>> semantics of a term are changed.  In this case, the URI should not be
>> changed if the semantics of a term are changed. If it was changed, the
>> application would keep functioning in its original manner instead of
>> adapting to the new meaning of the term.
>>
>
> Can you think of a clear example where the application will only do the
> right thing when the unique identifier (UID) for a resource ceases to be
> used for that [conceptual] resource and is instead used for a resource with
> a different semantics?  In this case, do you propose that the application is
> notified of the new meaning or, it just changes w/o notice? Note, I'm asking
> about the UID in a world where it is de-conflated from the URI and the
> physical location on the web.
>
>
>
>> I think, in general, it should be left up to the community of users and/or
>> managers of an ontology to communicate with each other and decide what
>> approach to take when creating a new version of an ontology.  Different
>> ontologies and different applications will require different approaches.
>>
>
> Proably true in general, but I need some concrete examples to be convinced
> that willy nilly semantics changing of the semantics of resources is
> desirable.
>
>
>>
>> Mike Lang
>>
>>
>> On Thu, Oct 30, 2008 at 5:14 AM, Michael F Uschold <uschold@gmail.com>wrote:
>>
>>> I'm resending this message to the semantic web discussion group for the
>>> record.
>>>
>>> On Wed, Oct 29, 2008 at 3:53 PM, Michael F Uschold <uschold@gmail.com>wrote:
>>>
>>>> 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 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 systemof the future will rely on these two
>>>> principles:
>>>> 1. If the semantics of a term changes, then it needs to have a new
>>>> unique ID.
>>>> 2. 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.
>>>>
>>>> The practical difficulties will be the same whether the standard is
>>>> blessed or not. It only really depends on whether the standard is a de facto
>>>> standard,or whether it is getting significant use. If users build things and
>>>> ontology producers break things through carelessness, this will hinder
>>>> semantic web technology adoption.
>>>>
>>>> Another question is what to do if the original standard is belived to be
>>>> incorrect, and the new one is the fixed one. Can one then keep the same URI?
>>>> Again, the answer should be informed by the impact on applications. The
>>>> same problems will occur if you change the semantics and keep the same URI
>>>> even if you are fixing a mistake.  The URI with the wrong semantics must
>>>> keep its original unique ID.
>>>>
>>>> Michael Uschold
>>>>
>>>
>>>
>>
>>
>> --
>> Revelytix, Inc.
>>
>> phone: 410-584-0009 (office)
>>           443-928-3782 (cell)
>> skype: michael.allen.lang.jr
>> aim: MikeJrRevelytix
>>
>
>