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-lifesci@w3.org>, 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" <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.
