Re: URIs and Unique IDs

On Sun, Nov 9, 2008 at 9:18 PM, Peter Ansell <ansell.peter@gmail.com> wrote:
> ----- "Alan Ruttenberg" <alanruttenberg@gmail.com> wrote:
>
>> This is a good example of why using names in URIs is a bad idea. If
>> the URIs were opaque numeric ids you could have simply changed the
>> label on the old "broader" to "broader transitive" and moved on. As
>> SKOS didn't do this it created problems for itself.
>
> This will only hide the issue from applications and make it impossible to determine the users original intent if they published their document before the change occurred. For upper ontologies being community developed I think it is wise not to hide these changes behind opaque URI's which never change on principle.

There is no hiding going on. In communities developing ontologies
there is ongoing communication. However many such communities are
learning as they go. I am saying that they should do what they can do
well first - specify what they mean clearly among themselves.

Subsequent changes that don't change what is meant (after this has
been communicated and documented) shouldn't force a change in URI just
because of a misunderstanding about how to construct a correct logical
axiom. Yet many changes I see, which would trigger a URI update
because they might be construed as "changes in semantics" are simply
corrections and improvements to the logical statements.

It seems to me that the "broader" relation as used by SKOS, was
understood to be transitive by the practitioners at the time. Upon
introduction to a wider audience this was at variance with common
usage. If the URI had stayed the same those using it would continued
to have had correct behavior. However they would find at some point
that the relation they were using started being called "broader
transitive" instead of "broader".

>> The OBO ontologies are moving towards *all* URI being numeric id based
>> for this reason (until recently it had only been classes that were
>> named that way).
>
> How will people using OBO ever be sure that they aren't going to use a term thinking it doesn't have reaching consequences like the broader->broaderTransitive difference and find out in future that it has changed and influenced their results in some way when someone could reasonably have determined that the nature of the term had changed and it needed a new number/name/URI/UID. I do recognise that whenever any property attached to a term changes that technically there could be a difference in the results of some application utilising the data, but reverting to saying that things just migrate on the spot always isn't a suitable solution either IMO.

Nobody can be sure of anything. However their policy has been arrived
at over many years of practice of arguably the most successful
collaboratively built ontology in history. If I had to make a wager, I
wouldn't bet against the solution they've come up with without a
really good case for it.

Moreover it resonates with my own (not insubstantial) experience in
working with ontologies. For example the BioPAX ontology, which I
worked on at some point, chose to version their URI's. As far as I can
tell, and this is looking back over some years, there was never any
positive benefit of doing so. There were however, a variety of
problems as people hassled with merging biopax level 1 and level 2
content, and as they had to migrate their queries as the URI changed,
for little benefit.

Bottom line is that there is a decent amount of experience that leads
to a conclusion of being very hesitant before changing ids. If you
have some experience to share that demonstrates otherwise I'm very
interested in hearing the specifics. I think we could do with more
case studies and fewer first principles here.

Regards,

-Alan

Received on Monday, 10 November 2008 06:41:41 UTC