W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > January 2007

RE: Answers to questions about BioPortal

From: Kashyap, Vipul <VKASHYAP1@PARTNERS.ORG>
Date: Thu, 11 Jan 2007 15:42:32 -0500
Message-ID: <2BF18EC866AF0448816CDB62ADF6538105EAF089@PHSXMB11.partners.org>
To: "Trish Whetzel" <whetzel@pcbi.upenn.edu>, "kc28" <kei.cheung@yale.edu>
Cc: "Alan Ruttenberg" <alanruttenberg@gmail.com>, "w3c semweb hcls" <public-semweb-lifesci@w3.org>


I think this is a very important thread of discussion and we should probably
discuss this at some length.

Even before we discuss implementation mechanisms, we need to understand this
issue at the level of functional requirements. Some issues that arise are:

1. Everytime a new version of a concept is created, should the version of the
ontology be updated?
2. If yes, should the new version be a major version or minor version?
3. If no, is it OK for a version of ontology (say v1) to be linked to multiple
versions of a concept (say v1, v2, etc...)
...
Of course, if we extend this thinking to multiple levels of granularity, say
properties, axioms, etc. this could give rise to a large number of
configurations.

A key issue we need to think about is what kind of "business rules" or
"lifecycles" need to be defined to appropriately link various versions at
multiple levels of granularity and best practices around these. 

I too, am not clear about the use case for instance versioning? So if "Tom"
is an instance of the class "Person", what does it mean to have multiple
versions of Tom? Maybe there are some use cases that make sense in the
lifesciences context?

---Vipul


> > 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.
> 
> I think that both types, high-level e.g. this is a new release of the
> ontology, and low-level, e.g. a term (class or property) is deprecated,
> are needed. Not sure about versioning at the instance level.
> 
> Mechanisms that I have seen or am aware of are either 1) add annotation
> properties in the ontology for this purpose or 2) use a database backend
> that provides a mechanism to store information about deprecated terms.
> The database backend solution may be too heavy weight for a general
> solution?. As for the annotation property mechanism. the developers of the
> MGED Ontology have put together a policy of how to indicate deprecated
> terms for this resource:
> https://www.cbil.upenn.edu/magewiki/index.php/TermDeprecationPolicy
> Although there may be some items that are particular to the MGED Ontology
> and it's peculiarities, I believe that there are also items that can be
> generalized for use with other ontologies.
> 
> Cheers,
> Trish





THE INFORMATION TRANSMITTED IN THIS ELECTRONIC COMMUNICATION IS INTENDED ONLY FOR THE PERSON OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED MATERIAL.  ANY REVIEW, RETRANSMISSION, DISSEMINATION OR OTHER USE OF OR TAKING OF ANY ACTION IN RELIANCE UPON, THIS INFORMATION BY PERSONS OR ENTITIES OTHER THAN THE INTENDED RECIPIENT IS PROHIBITED.  IF YOU RECEIVED THIS INFORMATION IN ERROR, PLEASE CONTACT THE SENDER AND THE PRIVACY OFFICER, AND PROPERLY DISPOSE OF THIS INFORMATION.
Received on Thursday, 11 January 2007 20:53:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:21 UTC