ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] FW: URIs and Unique IDs [xfrd from [oor-forum]]

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Fri, 07 Nov 2008 14:06:11 -0500
Message-id: <491491A3.1060905@xxxxxxxx>
Mike Uschold wrote:    (01)

> 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 ...
> 
> 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.    (02)

> 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.    (03)

I fully agree.    (04)

> Here is how.
> 
> ...
> 
> Thus, any ontology versioning system of the future will rely on these
> two principles:    (05)

> 1. If the semantics of a term changes, then it needs to have a new unique ID.    (06)

Yes.  Being very careful, this means that *any change* in a formal 
definition must cause the creation of a new ID -- the meaning of the 
term, as used by inference engines -- has changed.    (07)

A change to an "informal" definition, however, is a bit more in the eye 
of the beholder.  Changes that are intended/perceived as purely 
editorial, or clarification of intent, may not warrant changing the ID 
and confusing existing users.  OTOH, as text analyzers continue to get 
smarter, it can be argued that no "informal" definition is only for 
consumption by humans, and therefore it is not "informal" anymore.    (08)

> 2. If the semantics of a term does NOT change, then it should maintain
> the same ID in any future versions.    (09)

The simple fact is that it is not possible to guarantee this, because it 
is not clear how and when to apply this rule.    (010)

Because W3C deliberately (or accidentally and stupidly, take your pick) 
confused the concepts of location and identification, there is a 
relationship between URIs and the URLs that occur in them.  And this 
creates a versioning interaction between the version of the resource and 
the versions of the terms it defines.    (011)

The semantics of a term changes when the semantics of terms used in its 
definition changes.  One can argue, therefore, that a change to the 
resource may (transitively) affect the semantics of many terms 
introduced in it.    (012)

So a tool is faced with two problems:    (013)

  A.  When a new version of the resource is created, do we change the 
URL?  And what happens to the URIs inside it?    (014)

If we don't change the URL, then the old URIs will automatically 
associate to the new resource.  If we change a contained term and its 
URI, then we undefine the old URI altogether, unless we retain both in 
the new resource.  If we change a contained term and don't change its 
URI, we violate Michael's rule (1), and create unpredictable reasoning 
behaviors among our clients.  So this does not seem to be a viable option.    (015)

If we do change the URL, then none of the old URIs will associate to the 
new resource.  If we change all the URIs to match the new resource URL 
(which is the default behavior of some current tools), other ontologies 
that contain references to the old URIs won't work with the new version 
at all, regardless of the semantics.  We have to create the "synonym" 
(OWL:sameas) declarations for the terms that haven't actually changed. 
If we change the URIs only for terms that have changed (following Mike's 
rules), all appears to be well, but the new resource is implicitly 
dependent on the old one, because many of its URIs point to the old 
resource.  This becomes unwieldy over time, but it seems to be the 
required behavior.    (016)

  B.  How do we know when a term has "changed"?    (017)

Tools can track which concepts were edited, and selectively change the 
id=URIs for those concepts.  But since that change may affect the 
semantics of any term that references it, it seems that every term in 
which that URI is used must also have its URI changed.  And, with 
respect to Mike's rule 2, it is not clear that that is always correct 
practice.    (018)

For example, if the change to a term broadens the classification, and 
another term is defined to be an intersection that involves that term, 
does the semantics of the intersection change?  Has anything been added 
to the extension of the term that could now occur in the intersection? 
That determination may require some interesting reasoning.    (019)

And in the same way, when another ontology that imports terms from this 
resource is modified to use the new URI, because that correctly 
represents the intent, does that require a version change to all the 
terms in that ontology that use the new URI or that use terms that use 
the new URI?    (020)

This is just the problem of the confusion introduced by the change -- it 
propagates to the resource in which the change occurs as well as the 
resources that use it.  Each occurrence must now be judged on its own 
merits -- no practice is always right.    (021)

> If either of these two guidelines are broken, then so will the
> ontology-driven applications of the future.    (022)

Perhaps.  But they will be broken.  And that will happen because of 
practices, and because of the complexity of the reasoning required to 
avoid violation.    (023)

> These maxims hold without exception for any standards that are
> formally released as standards.    (024)

By W3C, by OASIS, by OMG, by ISO, by UN/CEFACT, by HL7, by WHO, ...?
The best you can hope for is that any one body will police its own.  But 
they will use the work of others.    (025)

I think we must accept the idea that synonymies will be a critical part 
of web-based reasoning, in any case.  (There is no single source of 
knowledge, and there will be no single appointed source, no matter what 
registry police we create.)  We have to be able to say, a posteriori, 
that term A1 in ontology A is semantically identical to term B2 in 
ontology B, and reasoning tools have to expect to see such things and 
use them.  And we should not be surprised to find it necessary to write 
that term B2v2 in ontology Bv2 is the same as term B2 in ontology B, for 
the reasons above.    (026)

> Another question is what to do if the original standard is believed 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.    (027)

I agree.  As Wikipedia demonstrates, "believed to be incorrect" is 
sometimes a subjective thing.    (028)

-Ed    (029)

"Inheritance and versioning interact in weird and wonderful ways.
Unfortunately, I can't find anything like sensible semantics for any
of them."
   -- Michi Henning    (030)

-- 
Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (031)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (032)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (033)

<Prev in Thread] Current Thread [Next in Thread>