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 >> >> >> >> >Received on Thursday, 27 November 2008 02:07:31 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:45:34 GMT