- From: William Bug <William.Bug@DrexelMed.edu>
- Date: Wed, 10 Jan 2007 21:37:12 -0500
- To: Tim Clark <twclark@nmr.mgh.harvard.edu>, Mark Wilkinson <markw@illuminae.com>, dirk.colaert@agfa.com, Daniel Rubin <rubin@med.stanford.edu>, w3c semweb hcls <public-semweb-lifesci@w3.org>, public-semweb-lifesci-request@w3.org
- Message-Id: <CA0A6F5A-9ACB-44DE-99E8-881C5BEC8D6F@DrexelMed.edu>
Here, here. I also would join Chimezie in saying I don't want to ruffle feathers on this issue, but if either NCBO and/or NLM/NCBI would start experimenting with a more broadly deployed LSID Registry & Resolution Service (NCBO for ontologies and NLM/NCBI for BioRDF data sets and/or data sets with ontology-centric annotations), I think there would be many interested in making use of it. As to Dirk's original point below, this is a requirement for OBO Foundry ontologies - "the original URI should still point to the old term or concept, even if it is deprecated" - though I take it not all BioPortal ontologies will follow the OBO Foundry guidelines. There's also been a lot of work on ontology class metadata standards recently - much focused within the OBI ontology development group - with a specific eye toward helping to support the link between deprecated classes and those classes to which the original semantic content covered by the defunct class has been transferred. To fully represent this evolutionary graph, there will likely be a need for some ruled-based formalism to deal with scenarios where the deprecated class has not simply been decomposed into 2 or more newer classes - or scenarios where multiple deprecated classes map to multiple current classes. Even under the simple case where 1 entity -- > 2 entities, rules may be required to more fully and formally express the semantic transference asserted by the ontological evolutionary graph. For the time being, we at least are working to include metadata properties to make it possible to - in theory - reconstruct the ontology graph as it existed on a particular date. Cheers, Bill On Jan 10, 2007, at 8:32 PM, Tim Clark wrote: > > LSID not dirty. LSID nice. :-) > > TC > > On WednesdayJan 10, 2007, at 11:19 AM, 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/ >> >> > > Bill Bug Senior Research Analyst/Ontological Engineer Laboratory for Bioimaging & Anatomical Informatics www.neuroterrain.org Department of Neurobiology & Anatomy Drexel University College of Medicine 2900 Queen Lane Philadelphia, PA 19129 215 991 8430 (ph) 610 457 0443 (mobile) 215 843 9367 (fax) Please Note: I now have a new email - William.Bug@DrexelMed.edu
Received on Thursday, 11 January 2007 02:37:35 UTC