Are we talking about versioning at a very high granularity level (e.g., a URI that points to an entire ontology)? Should we also consider versioning at finer granularity levels such as the levels of concepts or terms and their relationships within an ontology? Some of these concepts, terms and their relationships may evolve over time. We many need a versioning scheme for these. I think some of these finer granularity versioning examples can be found in the UMLS (Unified Medical Language System). At the instance level, we may need versioning as well. Also, the semantics of versioning may be unclear sometimes. For example, two different SNPs (Single Necleotide Polymorphisms) that were submitted to dbSNP may refer to the same location in the genome. Do we say they are two different versions of the same SNP? There may not be a standard notion/definition of versioning for biomedical entities.

Just my two-cent thought,


Alan Ruttenberg wrote:

I guess what I'm trolling for is some more careful description of the desired behavior. Some examples would be helpful, etc. My feeling is the technical management of how to arrange a uri/lsid is much easier than specifying and agreeing upon what the versioning behavior should be.

For instance, BioPAX took the strategy of using a different namespace for each of its versions. That cleanly separates which version you are referring to. Too cleanly - people who want to integrate data from the two versions now need to think too hard about how to do that.


On Jan 10, 2007, at 12:23 PM, Chimezie Ogbuji wrote:

Well, (not to open up a can of worms) ontology versioning can be handled as a mechanism 'built-in' to the protocol (as is the case with LSID) or via an HTTP resolution service (such as PURL). I'm more familiar with the latter scenario than the former. Assuming you have a static PURL address for the ontology you can specify which version the request is redirected to.

This is similar to the way W3C spec URLs work (from what I gather). There is usually a 'latest' link (which is always static) which redirects the a location specific to the current 'version'. I think this is a good model to follow for managing ontology locations (per version).

On Wed, 10 Jan 2007, Mark Wilkinson wrote:

Hmmmm... sounds like a job for LSID's... oops! Said a dirty word! ;-)

Cheers all!


On Tue, 09 Jan 2007 23:53:49 -0800, <[EMAIL PROTECTED]> wrote:

One comment on versioning issues (question2) . The matter is more complex than the answer suggests. If a clinical system ever refers to a URI in
BioPortal this URI should stay forever. Even if a new version of the
ontology is deployed the original URI should still point to the old term
or concept, even if it is deprecated. So versioning is more than a
development or collaboration issue. I don't know wether the answer given
to question 3 solves this.
Dr. Dirk Colaert MD
Advanced Clinical Application Research Manager
Agfa Healthcare               mobile: +32 497 470 871
Daniel Rubin <[EMAIL PROTECTED]>
10/01/2007 01:46
"w3c semweb hcls" <public-semweb-lifesci@w3.org>
Answers to questions about BioPortal
Dear HCLSIG users,
We have received a number of questions/comments from you for our BioPortal sneak preview. Please continue to provide comments/suggestions as this
will help us to ensure BioPortal meets the community needs. We have
collected the following recent feedback from several different members of
this list, and would like to summarize our responses to them  below to
clarify some of the recent questions:
1. Looking at the interface, it is not clear to me how best to reference an element of the ontologies there-- is there a URI mechanism that can be
used directly by outside researchers? How does
this relate to the DOID # (i.e., namespaces)?
Yes, a URI mechanism will be made available soon. Ontologies will have their own namespaces defined by the authors, or if none is provided, we
will create one based on our bioontology.org namespace.
2. Also, can you provide more details on how the BioPortal will provide versioning? Last I understood, there were no SVN capabilities with the
BioPortal - has that changed or did I misunderstand the set-up?
It is important to understand that BioPortal is a Web application that
accesses an ontology library, and that it is not a content  management
system (such as cvs and subversion). BioPortal stores the released
versions of ontologies and indexes their content.  For ontology
development, the authors use their preferred local systems (local cvs, svn, sourceforge, or gforge). When they create a new version that is ready
to be released publicly, it is submitted directly to BioPortal by  the
author. In some cases, we may be able to set up URL pull into BioPortal on
a regular basis.
3. Will there be a general way to identify deprecated terms in the
ontologies posted in BioPortal, how does LexGrid handle this information?
Yes, and LexGrid provides this functionality.
4. Are you [Mark Musen] the person to request updates of information
currently displayed on the site?
You can contact Daniel Rubin.
5. The terms of service says: "Except as expressly prohibited on the Site, you are permitted to view, copy, print and distribute publications and documents within this Site, subject to your agreement that:... You will display the below copyright notice and other proprietary notices on every
copy you make" I read this as saying that anything submitted to the
repository would be copyright "Copyright (c) 2005-2006, The Board of
Trustees of Leland Stanford Junior University. All rights  reserved.",
which I would guess some would consider unacceptable.
This is not the intended interpretation and we will change the wording of
the terms.
6. Termination of Use: "You agree that The National Center for Biomedical Ontology may, in its sole discretion, at any time terminate your access to
the Site and any account(s) you may have in connection
with the Site. Access to the Site may be monitored by The National Center for Biomedical Ontology." This is scary. There ought to be explicit cause for termination, otherwise people might be reluctant to entrust their work
to the site.
We will modify the terms to declare the conditions that would be a cause
for termination.
7. Disclaimer: "... PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS... ". (B The W3C has taken steps to ensure that access to the files hosted at the W3C domain will be maintained under a variety of circumstances, using
mirrors, externals services, etc. It would be desirable that similar
actions be taken by the NCBO, and some mention of them included in the terms of service, particularly if URIs in the bioontology.org namespace
are to be used.
NCBO sites are hosted by Stanford Information Technology Services, the same people who host the Stanford Hospital clinical database and Highwire
Press.  We anticipate having reliable availability of the  services we
8. Use of ontologies: "Only the submitter of the ontology will be able to modify it or submit new versions". B In a project such as ours that is group oriented, it is likely that individuals will come and go. I think there needs to be some notion of group access so that we aren't vulnerable
to a key individual becoming unavailable.
Yes, we are planning on adding group access.
9. It wasn't clear to me whether there was developer support e.g.  svn
access. I don't know whether Helen et. all had in mind using such services
at W3C, but such access is certainly part of the development  cycle of
projects such as ours. Is the model that ontology developers use external sites for this and only submit relatively stable versions of the ontology
to the BioPortal?
Correct. The model is that ontology developers use external resources such as sourceforge or their own local cvs for internal development, and they
submit stable release versions of their ontologies to the BioPortal.
-BiPortal Team.

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593

Reply via email to