Re: URIs and Unique IDs

Another good example in science terminolog evolving  is the recent change in
definition of 'planet' which now excludes Pluto.
People want to use the same term 'planet', and so they should be able to.

This can work fine, as long as there is a different URI. This will also
allow legacy applications that use the old definition of planet to be used
alongside newer applications w/o any semantic interference.

If the  new URI is somehow linked to the old URI then this can have
advantages. E.g. some applications may always want to use the most recent
version, and this would be easily accomplished.

Michael

On Wed, Nov 26, 2008 at 4:45 PM, John Graybeal <graybeal@mbari.org> wrote:

> Correct in every respect but the 'you' part. :->  I would reframe the
> situation as follows: I am working with people who define the terms used for
> their data sets. Those people are (a) unfamiliar with ontologies, and (b)
> unaware of 'meaning creep' even as they are creating it via their revised
> definitions.  I'm not sure if these details affect your assessment, but this
> application, as described below, seems very different to me than "I want to
> supervise the creation of a community ontology for a domain."
>
> Rather, I want to use ontological methods to let community members use or
> refer to (relatively) unambiguous terms -- terms that they have defined,
> possibly with a large community, and possibly that they have mapped to other
> concepts. They are not building rich domain ontologies, merely capturing
> their local or community understanding. So I'm thinking my choices are
> either: (a) assign them a new opaque URI assuming the new concept is
> different, or (b) give them a versioned URI in case the new concept is
> different.
>
> The resource we are working with, as I see it, is this term of convenience
> (in this example, 'sea surface temperature'). They will define the term
> differently at different times. But the fact that their understanding of the
> concept has changed due to underlying technologies (even though to them the
> concept is 'unchanged' -- note that often the person updating the definition
> is not in a position to decide if the change is in fact significant) is very
> important
>
> I picked this example from a relatively stable science domain, but of
> course science domains in flux have faster meaning creep, as understanding
> evolves. Whether these actual changes are managed by changing opaque URIs,
> or changing version URIs while keeping a stable term fragment, should not
> impact how the semantic technologies can be applied. Or so I hope.
>
> John
>
>
>
> On Nov 26, 2008, at 2:51 PM, Alan Ruttenberg wrote:
>
> On Wed, Nov 26, 2008 at 5:17 PM, John Graybeal <graybeal@mbari.org> wrote:
>>
>> In our research community, on a regular basis you hear how important it is
>>> to know, as precisely as possible, the meaning of the parameters in a
>>> historical data collection. Whether or not "sea surface temperature"
>>> meant
>>> the temperature of water "collected somewhere near the surface and
>>> brought
>>> back on board", "measured in situ 1 meter below the surface", or
>>> "measured
>>> by a satellite" can significantly impact the temperature trend of a
>>> global
>>> ocean temperature analysis.
>>>
>>> Before you jump:  I appreciate that fundamentally these can be 3
>>> different
>>> concepts. My observation is that the people defining the terms don't
>>> always
>>> appreciate that; and simply letting a concept evolve, without tracking or
>>> versioning the evolution, will obviously produce analyses in the future
>>> that
>>> say "We don't know which version of the concept they had in mind when
>>> they
>>> labeled this data value."   Tracking the necessary information to answer
>>> questions like that is a minimal requirement for supporting historical
>>> data
>>> analyses for environmental science.  For me, that's a decisive argument
>>> for
>>> versioning.
>>>
>>
>> I see this as an argument for better modeling, not versioning. But
>> first let me see if I understand the scenario.
>>
>> You want to define sea surface temperature. There are a number of
>> methods for doing so. You are proposing to have a single class
>> (relation?) "sea surface temperature" that is versioned as follows:
>>
>> "sea surface temperature"
>>  v1: temperature of water "collected somewhere near the surface and
>> brought back on board
>>  v2: measured in situ 1 meter below the surface
>>  v3: measured by a satellite
>>
>> Your presumption is that for a while people will use v1, then they
>> will use v2 then they will use v3 and therefore you will know what
>> they mean in each case.
>>
>> Do I understand this correctly?
>>
>> -Alan
>>
>>
>>> John
>>>
>>> On Nov 9, 2008, at 10:41 PM, Alan Ruttenberg wrote:
>>>
>>> On Sun, Nov 9, 2008 at 9:18 PM, Peter Ansell <ansell.peter@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> ----- "Alan Ruttenberg" <alanruttenberg@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>> <snip>
>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>
> John
>
>
> --------------
> John Graybeal   <mailto:graybeal@mbari.org>  -- 831-775-1956
> Monterey Bay Aquarium Research Institute
> Marine Metadata Interoperability Project: http://marinemetadata.org
>
>