I shall have a look at your paper. Thanks for posting the link.
> The issue is not about *version policy* but about ontology's *design and
deployment*.
I don't think it is an either/or. Ontology design and development faces a
versioning challenge when the ontology evolves. Perhaps 'version policy' is
not the right term, how about 'change management'?
Michael
On Tue, Nov 18, 2008 at 3:32 PM, Xiaoshu Wang <wangxiao@musc.edu> wrote:
> The issue is not about *version policy* but about ontology's *design and
> deployment*. We should take lessons from software engineering, where we are
> all trying to remove the code dependency by carefully refactoring code to
> handle change.
> Ontology engineering is not much different because our knowledge about the
> world is bound to change. But we would like our URI to be stable. Hence,
> the concern of ontology engineering is to manage the logic-dependence
> through careful ontology modularization. I have discussed this issue and
> offered some solutions in a paper that I presented at DILS 08[1].
>
> 1. Ontology Design Principles and Normalization Techniques in the Web.
> http://www.inesc-id.pt/ficheiros/publicacoes/4799.pdf
>
> Xiaoshu
>
>
> John Graybeal wrote:
>
>> On Nov 9, 2008, at 8:50 AM, Alan Ruttenberg wrote:
>>
>>
>>
>>> I should point out that within the Open Biomedical Ontologies 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.
>>>
>>>
>>
>> Term deprecation works for me. And I think there does need to be a single
>> (i.e., unversioned) URI for each term, that always reflects the 'latest
>> semantics' of a given term. My view is that we're really creating a
>> dictionary that maps a string to a definition (crudely put)*, and yes the
>> semantics/definition for a term may change over time, so that should be
>> reflected in the 'latest' expression of the term (the one that the 'latest
>> semantics' URI represents).
>>
>> But I think there also needs to be an appreciation that the exact concept
>> associated with that term is evolving over time, and each time it
>> explicitly evolves, that is a slightly (or hugely, sometimes) different
>> conceptualization. It isn't at all impractical to create a new URI for each
>> such change, even if it changes every minute, at least that I can see.
>>
>> What I like about this scenario is that a user can use either concept for
>> the term -- the very specific versioned one, or the unversioned 'latest'
>> one -- according to what they want to express. I don't see why both
>> concepts shouldn't be available.
>>
>> I tend toward the opinion (thanks to Michael U's arguments) that changing
>> the versioned URI should only occur when something about the term is
>> explicitly changed -- new versions of the vocabulary, in and of themselves,
>> are not sufficient.
>>
>> John
>>
>>
>> * So Peter's defense of visible names resonates for me.
>>
>>
>> --------------
>> John Graybeal <mailto:graybeal@mbari.org> -- 831-775-1956
>> Monterey Bay Aquarium Research Institute
>> Marine Metadata Interoperability Project: http://marinemetadata.org
>>
>>
>>
>>
>