Re: Answers to questions about BioPortal

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 17:37:28 UTC