Re: Answers to questions about BioPortal
I added this requirement (URI for most current version) to the wiki since it is essential for the operation of the software we use. Be nice to have the chaining between versions as well. -S On Jan 17, 2007, at 7:26 AM, Daniel Rubin wrote: We will be adding terminologies such as ICD and SNOMED into BioPortal and creating URIs for all terms in all terminologies/ ontologies. Those URIs will also probably contain the version info for the terminology so that new terminology releases do not invalidate older URIs. Would that work from everyone's perspective, or are there other requirements (for example, I could imagine it would be nice is there were another layer that permitted people to refer to a URI that pointed to the current version of a term, though it could be quite a bit of work to provide that service). Daniel ___ Daniel Rubin, MD, MS Clinical Asst. Professor, Radiology Research Scientist, Stanford Medical Informatics Scientific Director, National Center of Biomedical Ontology MSOB X-215 Stanford, CA 94305 650-725-5693 At 02:03 AM 1/17/2007, [EMAIL PROTECTED] wrote: I don't know if any commercial clinical system is rteally using URI's right now, but I think this will come. If an URI is the ultiimate and unique way of pointing to a resource then future systems should use URI's to 'codify' diagnoses for example in stead of storing a local code in the data base. Currently many systems store the combination of a coding system (ICD, SNOMED) + the specific code + a locally deployed repository. However, conceptually this is the same of pointing to the SNOMED or ICD URI in the SNOMED/URI ontology residing at some site. By the way also by using codesystem/code combinations you have the versioning problem. "Code System" is also holding version info. __ Dr. Dirk Colaert MD Advanced Clinical Application Research Manager Agfa Healthcare mobile: +32 497 470 871 Daniel Rubin <[EMAIL PROTECTED]> 11/01/2007 04:43 To Dirk Colaert/AMIPU/[EMAIL PROTECTED] cc "w3c semweb hcls" , public-semweb- [EMAIL PROTECTED] Subject Re: Answers to questions about BioPortal This is a very good.point; permanent URIs is a reasonable requirement we will aim to provide. Though I am intrigued with your use case about clinical systems referring to a URI. Are you aware of any commercial system that is contemplating referring to entities on the semantic Web via URI? We'd certainly be interested in catalyzing commercial efforts use these technologies effectively, and it would be particularly nice if we could get these systems using public knowledge sources such as terminologies instead of embedding them in the code... BTW--if there are other requirements for BioPortal, it would be good to elicit them now. Daniel At 11:53 PM 1/9/2007, [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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
RE: Answers to questions about BioPortal
Actually this is a very good idea, and we have created a section on our wiki for gathering requirements from the public: http://www.bioontology.org/wiki/index.php/Public_Requirements We have seeded this with URI requirements that we have gathered from this community. Alas, we do not yet have a "wish list/requirements" from various communities, but this is exactly what we want, and we hope that this wiki mechanism will improve our outreach to that end. If there are others who would be valuable to contribute, feel free to encourage them to participate (the wiki is open to the public to contribute). In addition, people can add other types of requirements other than URI if they would to see other functionality in BioPortal. Thanks Daniel At 07:55 AM 1/17/2007, Kashyap, Vipul wrote: Daniel, Thanks for the news. ICD and SNOMED are the two biggies used in healthcare and this would a very useful services. Hopefully, you have got an exhaustive set of wish lists/requirements from various communities. Was wondering if you are planning to make the requirements and/or spec open to the public? This would be valuable to both the HCLS and other W3C communities! Best regards, ---Vipul === Vipul Kashyap, Ph.D. Senior Medical Informatician Clinical Informatics R&D, Partners HealthCare System Phone: (781)416-9254 Cell: (617)943-7120 http://www.partners.org/cird/AboutUs.asp?cBox=Staff&stAb=vik To keep up you need the right answers; to get ahead you need the right questions ---John Browning and Spencer Reiss, Wired 6.04.95 From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] On Behalf Of Daniel Rubin Sent: Wednesday, January 17, 2007 10:26 AM To: [EMAIL PROTECTED] Cc: w3c semweb hcls; [EMAIL PROTECTED] Subject: Re: Answers to questions about BioPortal We will be adding terminologies such as ICD and SNOMED into BioPortal and creating URIs for all terms in all terminologies/ontologies. Those URIs will also probably contain the version info for the terminology so that new terminology releases do not invalidate older URIs. Would that work from everyone's perspective, or are there other requirements (for example, I could imagine it would be nice is there were another layer that permitted people to refer to a URI that pointed to the current version of a term, though it could be quite a bit of work to provide that service). Daniel ___ Daniel Rubin, MD, MS Clinical Asst. Professor, Radiology Research Scientist, Stanford Medical Informatics Scientific Director, National Center of Biomedical Ontology MSOB X-215 Stanford, CA 94305 650-725-5693 At 02:03 AM 1/17/2007, [EMAIL PROTECTED] wrote: I don't know if any commercial clinical system is rteally using URI's right now, but I think this will come. If an URI is the ultiimate and unique way of pointing to a resource then future systems should use URI's to 'codify' diagnoses for example in stead of storing a local code in the data base. Currently many systems store the combination of a coding system (ICD, SNOMED) + the specific code + a locally deployed repository. However, conceptually this is the same of pointing to the SNOMED or ICD URI in the SNOMED/URI ontology residing at some site. By the way also by using codesystem/code combinations you have the versioning problem. "Code System" is also holding version info. __ Dr. Dirk Colaert MD Advanced Clinical Application Research Manager Agfa Healthcare mobile: +32 497 470 871 Daniel Rubin <[EMAIL PROTECTED]> 11/01/2007 04:43 To Dirk Colaert/AMIPU/[EMAIL PROTECTED] cc "w3c semweb hcls" , [EMAIL PROTECTED] Subject Re: Answers to questions about BioPortal This is a very good.point; permanent URIs is a reasonable requirement we will aim to provide. Though I am intrigued with your use case about clinical systems referring to a URI. Are you aware of any commercial system that is contemplating referring to entities on the semantic Web via URI? We'd certainly be interested in catalyzing commercial efforts use these technologies effectively, and it would be particularly nice if we could get these systems using public knowledge sources such as terminologies instead of embedding them in the code... BTW--if there are other requirements for BioPortal, it would be good to elicit them now. Daniel At 11:53 PM 1/9/2007, [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
RE: Answers to questions about BioPortal
Daniel, Thanks for the news. ICD and SNOMED are the two biggies used in healthcare and this would a very useful services. Hopefully, you have got an exhaustive set of "wish lists/requirements" from various communities. Was wondering if you are planning to make the requirements and/or spec open to the public? This would be valuable to both the HCLS and other W3C communities! Best regards, ---Vipul === Vipul Kashyap, Ph.D. Senior Medical Informatician Clinical Informatics R&D, Partners HealthCare System Phone: (781)416-9254 Cell: (617)943-7120 http://www.partners.org/cird/AboutUs.asp?cBox=Staff&stAb=vik To keep up you need the right answers; to get ahead you need the right questions ---John Browning and Spencer Reiss, Wired 6.04.95 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Rubin Sent: Wednesday, January 17, 2007 10:26 AM To: [EMAIL PROTECTED] Cc: w3c semweb hcls; [EMAIL PROTECTED] Subject: Re: Answers to questions about BioPortal We will be adding terminologies such as ICD and SNOMED into BioPortal and creating URIs for all terms in all terminologies/ontologies. Those URIs will also probably contain the version info for the terminology so that new terminology releases do not invalidate older URIs. Would that work from everyone's perspective, or are there other requirements (for example, I could imagine it would be nice is there were another layer that permitted people to refer to a URI that pointed to the current version of a term, though it could be quite a bit of work to provide that service). Daniel ___ Daniel Rubin, MD, MS Clinical Asst. Professor, Radiology Research Scientist, Stanford Medical Informatics Scientific Director, National Center of Biomedical Ontology MSOB X-215 Stanford, CA 94305 650-725-5693 At 02:03 AM 1/17/2007, [EMAIL PROTECTED] wrote: I don't know if any commercial clinical system is rteally using URI's right now, but I think this will come. If an URI is the ultiimate and unique way of pointing to a resource then future systems should use URI's to 'codify' diagnoses for example in stead of storing a local code in the data base. Currently many systems store the combination of a coding system (ICD, SNOMED) + the specific code + a locally deployed repository. However, conceptually this is the same of pointing to the SNOMED or ICD URI in the SNOMED/URI ontology residing at some site. By the way also by using codesystem/code combinations you have the versioning problem. "Code System" is also holding version info. __ Dr. Dirk Colaert MD Advanced Clinical Application Research Manager Agfa Healthcare mobile: +32 497 470 871 Daniel Rubin <[EMAIL PROTECTED]> 11/01/2007 04:43 To Dirk Colaert/AMIPU/[EMAIL PROTECTED] cc "w3c semweb hcls" , [EMAIL PROTECTED] Subject Re: Answers to questions about BioPortal This is a very good.point; permanent URIs is a reasonable requirement we will aim to provide. Though I am intrigued with your use case about clinical systems referring to a URI. Are you aware of any commercial system that is contemplating referring to entities on the semantic Web via URI? We'd certainly be interested in catalyzing commercial efforts use these technologies effectively, and it would be particularly nice if we could get these systems using public knowledge sources such as terminologies instead of embedding them in the code... BTW--if there are other requirements for BioPortal, it would be good to elicit them now. Daniel At 11:53 PM 1/9/2007, [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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" cc Subject Answers to questions about BioPortal
Re: Answers to questions about BioPortal
We will be adding terminologies such as ICD and SNOMED into BioPortal and creating URIs for all terms in all terminologies/ontologies. Those URIs will also probably contain the version info for the terminology so that new terminology releases do not invalidate older URIs. Would that work from everyone's perspective, or are there other requirements (for example, I could imagine it would be nice is there were another layer that permitted people to refer to a URI that pointed to the current version of a term, though it could be quite a bit of work to provide that service). Daniel ___ Daniel Rubin, MD, MS Clinical Asst. Professor, Radiology Research Scientist, Stanford Medical Informatics Scientific Director, National Center of Biomedical Ontology MSOB X-215 Stanford, CA 94305 650-725-5693 At 02:03 AM 1/17/2007, [EMAIL PROTECTED] wrote: I don't know if any commercial clinical system is rteally using URI's right now, but I think this will come. If an URI is the ultiimate and unique way of pointing to a resource then future systems should use URI's to 'codify' diagnoses for example in stead of storing a local code in the data base. Currently many systems store the combination of a coding system (ICD, SNOMED) + the specific code + a locally deployed repository. However, conceptually this is the same of pointing to the SNOMED or ICD URI in the SNOMED/URI ontology residing at some site. By the way also by using codesystem/code combinations you have the versioning problem. "Code System" is also holding version info. __ Dr. Dirk Colaert MD Advanced Clinical Application Research Manager Agfa Healthcare mobile: +32 497 470 871 Daniel Rubin <[EMAIL PROTECTED]> 11/01/2007 04:43 To Dirk Colaert/AMIPU/[EMAIL PROTECTED] cc "w3c semweb hcls" , [EMAIL PROTECTED] Subject Re: Answers to questions about BioPortal This is a very good.point; permanent URIs is a reasonable requirement we will aim to provide. Though I am intrigued with your use case about clinical systems referring to a URI. Are you aware of any commercial system that is contemplating referring to entities on the semantic Web via URI? We'd certainly be interested in catalyzing commercial efforts use these technologies effectively, and it would be particularly nice if we could get these systems using public knowledge sources such as terminologies instead of embedding them in the code... BTW--if there are other requirements for BioPortal, it would be good to elicit them now. Daniel At 11:53 PM 1/9/2007, [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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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 au
Re: Answers to questions about BioPortal
I don't know if any commercial clinical system is rteally using URI's right now, but I think this will come. If an URI is the ultiimate and unique way of pointing to a resource then future systems should use URI's to 'codify' diagnoses for example in stead of storing a local code in the data base. Currently many systems store the combination of a coding system (ICD, SNOMED) + the specific code + a locally deployed repository. However, conceptually this is the same of pointing to the SNOMED or ICD URI in the SNOMED/URI ontology residing at some site. By the way also by using codesystem/code combinations you have the versioning problem. "Code System" is also holding version info. __ Dr. Dirk Colaert MD Advanced Clinical Application Research Manager Agfa Healthcare mobile: +32 497 470 871 Daniel Rubin <[EMAIL PROTECTED]> 11/01/2007 04:43 To Dirk Colaert/AMIPU/[EMAIL PROTECTED] cc "w3c semweb hcls" , [EMAIL PROTECTED] Subject Re: Answers to questions about BioPortal This is a very good.point; permanent URIs is a reasonable requirement we will aim to provide. Though I am intrigued with your use case about clinical systems referring to a URI. Are you aware of any commercial system that is contemplating referring to entities on the semantic Web via URI? We'd certainly be interested in catalyzing commercial efforts use these technologies effectively, and it would be particularly nice if we could get these systems using public knowledge sources such as terminologies instead of embedding them in the code... BTW--if there are other requirements for BioPortal, it would be good to elicit them now. Daniel At 11:53 PM 1/9/2007, [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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
RE: Answers to questions about BioPortal
> 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 Have an example for this one: If the instance is of a the class "Tumor" then on giving treatment it changes in size, shape etc, and might ultimately disappear. On each visit we are observing a different version of the tumor instance [in Tom]. Regards, Nigam.
RE: Answers to questions about BioPortal
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.
Re: Answers to questions about BioPortal
Hi Bill, Is the work that you mention below part of that for BIRN and is there a pointer to a policy? Also, have you found it necessary to be able to re-create the graph within the same version of the ontology on a day-to-day basis or is a version-to-version basis acceptable? Trish 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.
Re: Answers to questions about BioPortal
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
Re: Answers to questions about BioPortal
William Bug wrote: 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. Agreed. The whole point of the semantic web is to come up with a standard that can broadly be applied to interconnect or integrate ontologies/data sets across different organizations (e.g., NCBO and NLM/NCBI). Cheers, -Kei -Kei
Re: Answers to questions about BioPortal
This is a very good.point; permanent URIs is a reasonable requirement we will aim to provide. Though I am intrigued with your use case about clinical systems referring to a URI. Are you aware of any commercial system that is contemplating referring to entities on the semantic Web via URI? We'd certainly be interested in catalyzing commercial efforts use these technologies effectively, and it would be particularly nice if we could get these systems using public knowledge sources such as terminologies instead of embedding them in the code... BTW--if there are other requirements for BioPortal, it would be good to elicit them now. Daniel At 11:53 PM 1/9/2007, [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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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,
Re: Answers to questions about BioPortal
And the metadata (AnnotationProperties) I mentioned previously are designed to support the ability manage versioning at the level of nodes and edges. Again - it's just a proposal at this point, but its in recognition of this need you stated more eloquently than I in your previous post on this thread, that many biomedical ontology developers have gradually come to recognize must be addressed. Daniel Rubin has also begun to work with the SKOS developers to help them continue to evolve this resource so we'll also have a annotation standard for managing the variety of lexical elements associated with an ontology. Daniel has been soliciting SKOS Use Cases from those biomedical ontology projects currently making use of SKOS. We're just talking low-hanging fruit here - e.g., we all use the same AnnotationProperties to specify associated synonyms, misspellings, preferred terms, etc.. Cheers, Bill On Jan 10, 2007, at 10:10 PM, kc28 wrote: William Bug wrote: 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. Agreed. The whole point of the semantic web is to come up with a standard that can broadly be applied to interconnect or integrate ontologies/data sets across different organizations (e.g., NCBO and NLM/NCBI). Cheers, -Kei -Kei 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, PA19129 215 991 8430 (ph) 610 457 0443 (mobile) 215 843 9367 (fax) Please Note: I now have a new email - [EMAIL PROTECTED]
Re: Answers to questions about BioPortal
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: H... sounds like a job for LSID's... oops! Said a dirty word! ;-) Cheers all! M 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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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,
Re: Answers to questions about BioPortal
Hi, 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, -Kei 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. -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: H... sounds like a job for LSID's... oops! Said a dirty word! ;-) Cheers all! M 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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
RE: Answers to questions about BioPortal
On the format of URI (slash vs hash), it would be worth hearing from the as much of the W3C community as possible, as there could be differences of opinion. At this point, we are collecting the requirements. In terms of synchronization, BioPortal will serve up the "current version" as defined by the authors of the ontologies. They can either push those to us, or if they prefer, they can discuss with us the possibilities for pull at regular intervals. Daniel At 07:37 AM 1/10/2007, Xiaoshu Wang wrote: >> 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. If the authors have their own namespace URI, that means they have to maintain a copy of the ontology at their own site. I wonder how will the synchronization between the bioportal to the external site be established? If an ontology is to adopt the URI that the bioportal provides, I wonder what kind of URI, in terms of the hash vs. slash, that the bioportal will support. For a samll sized ontology, the hash URI would be sufficient and ideal. But if the ontology's size is huge, I do believe the slash URI should be used to avoid the unnecessary import. From the implementation point of view, however, supporting slash URI would take a lot more hassle than supporting the hash URI. I wonder if bioportal will be able to support that? Xiaoshu
Re: Answers to questions about BioPortal
LSID not dirty. LSID nice. :-) TC On WednesdayJan 10, 2007, at 11:19 AM, Mark Wilkinson wrote: H... sounds like a job for LSID's... oops! Said a dirty word! ;-) Cheers all! M 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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
Re: Answers to questions about BioPortal
How will LSIDs help? -Alan On Jan 10, 2007, at 11:19 AM, Mark Wilkinson wrote: H... sounds like a job for LSID's... oops! Said a dirty word! ;-) Cheers all! M 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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
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: H... sounds like a job for LSID's... oops! Said a dirty word! ;-) Cheers all! M 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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
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: H... sounds like a job for LSID's... oops! Said a dirty word! ;-) Cheers all! M 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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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,
Re: Answers to questions about BioPortal
H... sounds like a job for LSID's... oops! Said a dirty word! ;-) Cheers all! M 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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
RE: Answers to questions about BioPortal
>> 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. If the authors have their own namespace URI, that means they have to maintain a copy of the ontology at their own site. I wonder how will the synchronization between the bioportal to the external site be established? If an ontology is to adopt the URI that the bioportal provides, I wonder what kind of URI, in terms of the hash vs. slash, that the bioportal will support. For a samll sized ontology, the hash URI would be sufficient and ideal. But if the ontology's size is huge, I do believe the slash URI should be used to avoid the unnecessary import. From the implementation point of view, however, supporting slash URI would take a lot more hassle than supporting the hash URI. I wonder if bioportal will be able to support that? Xiaoshu
Re: Answers to questions about BioPortal
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]> Sent by: [EMAIL PROTECTED] 10/01/2007 01:46 To "w3c semweb hcls" 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
