Re: Answers to questions about BioPortal

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.

-Alan

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!
>>
>> M
>>
>>
>> On Tue, 09 Jan 2007 23:53:49 -0800, <dirk.colaert@agfa.com> 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 <rubin@med.stanford.edu>
>>> Sent by: public-semweb-lifesci-request@w3.org
>>> 10/01/2007 01:46
>>> To
>>> "w3c semweb hcls" <public-semweb-lifesci@w3.org>
>>> cc
>>> Subject
>>> 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
>>> provide.
>>> 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
> ogbujic@ccf.org
>

Received on Wednesday, 10 January 2007 18:29:47 UTC