================================================================
Section 0. Contact and confidentiality
================================================================
Contact e-mail:
Do you mind your use case being made public on the working group
website and documents?
That's fine.
================================================================
Section 1. Application
================================================================
In this section we ask you to provide some information about the
application for which the vocabulary(ies) and or vocabulary mappings
are being used.
Please note:
-- If your use case does not involve any specific application, but
consists rather in the description of a specific vocabulary, skip
straight to Section 2.
-- If your application makes use of links between different
vocabularies, do not forget to fill in Section 3!
1.1. What is the title of the application?
BIRNLex
1.2. What is the general purpose of the application?
What services does it provide to the end-user?
BIRNLex is an integrated ontology+lexicon used for various purposes - some end-user/interactive, others back-end/infrastructure - within the the BIRN Project to support semantically-formal data annotation, semantic data integration, and semantically-driven, federated query resolution.
*1.3. Provide some examples of the functionality of the application.
Try to illustrate all of the functionalities in which the
vocabulary(ies) and/or vocabulary mappings are involved.
Here a few examples of BIRNLex class definitions that illustrate our current need for lexical support and links to external knowledge sources. They provide a representative sense of how we are currently using SKOS. Our general design goals have been to use both the Dublin Core MD elements and SKOS where ever possible. Preferably we'd like to use SKOS for all lexical qualities. If OWL-DL would support it, we'd subclass various DC and SKOS AnnotationProperties as needed, when the base element is not sufficiently specific to encapsulate our intended usage. Ideally, this "subclassing" would be done in layers. There are certain annotation properties that should be shared across all biomedical knowledge resources. There are other required elements specific to our needs in BIRN. Since this sort of sub-classing of AnnotationProperites is not allowed in OWL-DL (OWL 1.0), right now we've hard-coded these "derived" classes. You see them below list either with a "birn_annot" or an "obo_annot" namespace prefix. I would add the "obo_annot" elements are of our own creation now and should be considered a recommendation for the OBO Foundry & NCBO to consider, as opposed to being an accepted standard.
The goal here - of course - is to define these ontology class lexical support elements in such a way so as to promote sharing and integration of this information throughout the field AND provide a defined, structured standard for bioinformatics software developers to code against.
Class: Anterior_ascending_limb_of_lateral_sulcus
birn_annot:birnlexCurator Bill Bug
birn_annot:birnlexExternalSource NeuroNames
birn_annot:bonfireID C0262186
birn_annot:curationStatus raw import
birn_annot:neuronamesID 49
birn_annot:UmlsCui C0262186
obo_annot:createdDate "2006-10-08"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:modifiedDate "2006-10-08"^^http://www.w3.org/2001/XMLSchema#date
skos:prefLabel Anterior_ascending_limb_of_lateral_sulcus
skos:scopeNote human-only
Class: Medium_spiny_neuron
birn_annot:birnlexCurator Maryann Martone
birn_annot:birnlexDefinition The main projection neuron found in caudate nucleus, putamen and nucleus accumbens. Characterized by small soma, 10-15 µm, unindented nucleus with little cytoplasm, and 3-5 spherically radiating dendrites covered by dendritic spines. Neurotransmitter is GABA but may co-express one or more neuropeptides.
birn_annot:bonfireID BF_C000100
birn_annot:curationStatus pending final vetting
dc:source Maryann Martone
obo_annot:createdDate "2006-07-15"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:modifiedDate "2006-09-28"^^http://www.w3.org/2001/XMLSchema#date
skos:prefLabel Medium_spiny_neuron
Class: Metencephalon
birn_annot:birnlexCurator Bill Bug
birn_annot:birnlexDefinition Anterior part of the hindbrain ventral to the cerebellum.
birn_annot:birnlexExternalSource NeuroNames
birn_annot:bonfireID C0376353
birn_annot:curationStatus pending final vetting
birn_annot:neuronamesID 534
birn_annot:UmlsCui C0376353
obo_annot:createdDate "2006-10-05"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:modifiedDate "2006-10-05"^^http://www.w3.org/2001/XMLSchema#date
skos:prefLabel Metencephalon
skos:scopeNote No longer includes the Cerebellum.
Class: Microscopy_contrast_enhancement_protocol
birn_annot:birnlexCurator Bill Bug
birn_annot:birnlexCurator BIRN OTF
birn_annot:curationStatus uncurated
obo_annot:createdDate "2006-05-15"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:modifiedDate "2006-10-11"^^http://www.w3.org/2001/XMLSchema#date
skos:changeNote Changed preferred Label from Contrast_enhancement_protocol to Microscopy_contrast_enhancement_protocol.
skos:editorialNote Should really be importing the FlyBase biological imaging ontology, now that it is so mature. Unfortunately, this is currently only available in OBO format. It really needs to be incorporated directly or through import into OBI (BB:2006-10-10).
skos:prefLabel Microscopy_contrast_enhancement_protocol
Class: Medulla_oblongata
birn_annot:birnlexCurator Bill Bug
birn_annot:birnlexExternalSource NeuroNames
birn_annot:bonfireID C0025148
birn_annot:curationStatus raw import
birn_annot:neuronamesID 695
birn_annot:UmlsCui C0025148
obo_annot:createdDate "2006-10-05"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:modifiedDate "2006-10-07"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:synonym "myelencephalon" [lang: en]
skos:prefLabel Medulla_oblongata
Class: Episodic_recall_paradigm
birn_annot:birnlexCurator Angie Laird
birn_annot:birnlexCurator Jessica Turner
birn_annot:birnlexDefinition A behavioral paradigm in which subjects recall items from episodic memory (autobiographical history, long-term event memories).
birn_annot:birnlexExternalSource BrainMap.org
birn_annot:curationStatus uncurated
obo_annot:createdDate "2006-06-01"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:modifiedDate "2006-10-11"^^http://www.w3.org/2001/XMLSchema#date
skos:prefLabel Episodic_recall_paradigm
Class: Fear
birn_annot:birnlexCurator Jessica Turner
birn_annot:birnlexExternalSource UMLS
birn_annot:bonfireID C0015726
birn_annot:curationStatus uncurated
birn_annot:UmlsCui C0015726
obo_annot:createdDate "2006-06-01"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:externallySourcedDefinition Unpleasant but normal emotional response to genuine external danger or threats; compare with ANXIETY and CLINICAL ANXIETY. (CSP)
obo_annot:externallySourcedDefinition The affective response to an actual current external danger which subsides with the elimination of the threatening condition. (MeSH)
obo_annot:modifiedDate "2006-10-11"^^http://www.w3.org/2001/XMLSchema#date
skos:prefLabel Fear
Class: Forebrain
birn_annot:birnlexCurator Allan MacKenzie-Graham
birn_annot:birnlexDefinition The part of the brain developed from the most rostral of the three primary vesicles of the embryonic neural tube and consisting of the Diencephalon and Telencephalon.
birn_annot:birnlexExternalSource NeuroNames
birn_annot:bonfireID C0085140
birn_annot:curationStatus pending final vetting
birn_annot:neuronamesID 8
birn_annot:UmlsCui C0085140
obo_annot:createdDate "2006-07-15"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:modifiedDate "2006-09-28"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:synonym prosencephalon
skos:prefLabel Forebrain
Class: C57BL/6
birn_annot:birnlexCurator Bill Bug
birn_annot:birnlexCurator Rob Williams
birn_annot:birnlexCurator Maryann Martone
birn_annot:birnlexDefinitionSource MGI
birn_annot:bonfireID BF_T0000258
birn_annot:curationStatus pending final vetting
obo_annot:createdDate "2006-10-05"^^http://www.w3.org/2001/XMLSchema#date
obo_annot:externallySourcedDefinition Jax subline 6 (Kaliss) of the Jax black subline derived from Little (1921) line which derived from original Lathrop stock (Beck, J.A., et al., Geneology of mouse inbred strains (2000), Nature, Jan2000, v24, p23).
obo_annot:externallySourcedDefinition A substrain of C57bl inbred mouse. Inbr (J) 150. Origin: substrains 6 and 10 were separated prior to 1937. This substrain is now probably the most widely used of all inbred strains. Substrain 6 and 10 differ at the H9, Igh2 and Lv loci. Maint. by J,N, Ola. (http://www.informatics.jax.org/external/festing/mouse/docs/C57BL.shtml)
obo_annot:externallySourcedDefinition C57BL/6 has an increased preference for alcohol and narcotics and is used in studies of the genetics of substance preference (Peirce, J.L., Derr, R., Shendure, J., Kolata, T. & Silver, L.M. A major influence of sexspecific loci on alcohol preference in C57Bl/6 and DBA/2 inbred mice. Mamm. Genome 9, 942�948 (1998)).
obo_annot:modifiedDate "2006-10-05"^^http://www.w3.org/2001/XMLSchema#date
skos:prefLabel C57BL/6
1.4. What is the architecture of the application?
What are the main components?
Are the components and/or the data distributed across a
network, or across the Web?
As stated above, we have several applications for which BIRNLex is being employed. The following is just a subset of tools either extant or in the offing:
a) online curation
we are moving to an RDF backend that will enable us to curate the BIRNLex ontology+lexicon via the web
b) annotation
we have applications designed to support domain experts annotating neuroimaging data. We are working to adapt these applications so that the annotations will be built using the BIRNLex classes according to the PATO formalism.
c) query/mediation
the BIRN mediator is design to federate the 60+ resident laboratory data repositories. Site databases register with the mediator by mapping the relevant elements from their resident data model into the mediator's global model. We will be moving to use BIRNLex classes to formally define the semantics of these mappings. The associated lexical elements will also be used to support semi-automatic semantic mapping of unstructured data. For this reason, we are working to solicit more contributions by the wider BIRN community to the lexicon included in BIRNLex. This process will include a need to manage commensurate definitions for the classes, as well as handling various types of lexical variants.
d) MBAT/SMART Atlas/Query Atlas
Within BIRN we have several software development projects designed to support integrated neuroimaging data set analysis. Some of these tools are also designed to support automated and semi-automated annotation in describing the geometries identified within the pixel & voxel data sets. These will be migrating toward using the structured BIRNLex semantic framework to build out these annotations.
e) image processing pipelines
Many labs have a variety of image processing tasks performed on a regular basis as a chained series of algorithms. These pipeline workflows are both driven off and generate metadata associated with the images. BIRNLex will increasingly be used to support formal, shared semantic descriptions of the images and workflows applied to them.
e) Storage Request Broker (SRB) + Metadata Catalog (MCAT)
BIRN use the SRB GRID-style file system to support distant collaborations. Data stored on SRB is described both via manual & automatic population of the SRB MCAT. MCAT content is important both to support distributed pipeline workflows and to help the BIRN Mediator locate data associated with resolved queries. Again, BIRNLex will increasingly become a critical resource for populating MCAT from this community, shared semantic framework.
f) XCEDE
XCEDE (XML-based Clinical Experiment Data Exchange Schema) is the BIRN XML Schema used to support automated imaging and clinical data exchange both in a static scenario as well as via Mediator-driven web service responses. BIRNLex is designed to be used extensively to represent semantic info in XCEDE instances. XCEDE was developed as a collaborative effort between neuroimaging scientists, who collect and use the data, and computer scientists developing methods to store and retrieve the data in a generalizable, extensible method.
In all of these applications, it is critical to have a clear, distinct, and shared representation for the associated lexicon. For instance, when integrated BIRN segmented brain images with those from other projects across the net, use of lexical variants from a variety of public terminilogies and thesauri such as SNOMED and MeSH can provide a powerful means to largely automate semantic integration of like entities - e.g., corresponding brain region, equivalent behavioral assays described using different preferred labels/names. In provided a community shared formalism for representing the associated lexicon, SKOS can greatly simplify this task. If, for instance, the lexical repository (collection of LUIs) contained in UMLS were represented according to SKOS, this would provide an extremely valuable resource to the community of semantically-oriented bioinformatics researchers, as well as a powerful tool to support LSI/NLP when linking to unstructured text.
1.5. Briefly describe any special strategy involved in the
processing of user actions, e.g. query expansion using the
vocabulary structure.
As implied above, the BIRN Mediator will be able to use the BIRNLex associated lexicon for query expansion against unstructured data. We also expect to use the alternative lexical variants to support uses of the various neuroinformatics tools using whichever register lexicon they prefer to use when browsing & searching annotated data.
1.6. Are the functionalities associated with the controlled
vocabulary(ies) integrated in any way with functionalities provided
by other means? (For example, search and browse using a structured
vocabulary might be integrated with free-text searching and/or some
sort of social bookmarking or recommender system.)
See above.
1.7. Any additional information, references and/or hyperlinks.
================================================================
Section 2. Vocabulary(ies)
================================================================
In this section we ask you to provide some information about the
vocabulary or vocabularies you would like to be able to represent using SKOS.
Please note:
-- If you have multiple vocabularies to describe, you may repeat
this section for each one individually or you may provide a single
description that encompasses all of your vocabularies.
-- If your use case describes a generic application of one or more
vocabularies and/or vocabulary mappings, you may skip this section.
-- If your vocabulary case contains cross-vocabulary links (between
the vocabularies you presented or to external vocabularies), please
fill in section 3!
2.1. What is the title of the vocabulary? If you're describing
multiple vocabularies, please provide as many titles as you can.
The following are the collection of terminologies and ontologies we are linking into BIRNLex:
Neuronames, Brainmap.org classification schemes, RadLex, Gene Ontology, Reactome, OBI, PATO, Subcellular Anatomy Ontology (CCDB - http://ccdb.ucsd.edu/), MeSH
We'd like to be able to use elements from the PsychInfo thesaurus, but licensing restrictions have been a hindrance to moving forward on that task.
Besides the clinical, radiological, and neuroanatomic terminologies that have been the target of standardization efforts within their field, we will also be describing cognitive experiments, with links to concepts from cognitive psychology (e.g., the PsycInfo thesaurus). These terminologies are not at all standardized and are being developed as part of the BIRNLex efforts.
2.2. Briefly describe the general characteristics of the
vocabulary, e.g. scope, size...
The general resources we assume don't require additional description by us.
Neuronames: brain anatomy (~750 classes and 1000s of associated lexical variants)
Brainmap.org classification: hierarchies to describe neuroanatomy, subject variables, stimulus conditions, and experimental paradigms associated with functional MRI of the nervous system
Subcellular Anatomy Ontology: designed to describe the subcellular entities associated with ultrastructural and histological imaging of neural tissue
2.3. In which language(s) is the vocabulary provided?
In the case of partial translations, how complete are these?
We currently are only dealing with English.
*2.4. Please provide below some extracts from the vocabulary. Use
the layout or presentation format that you would normally provide
for the users of the vocabulary. Please ensure that the extracts you
provide illustrate all of the features of the vocabulary.
see above for extracts from BIRNLex
2.5. Describe the structure of the vocabulary.
What are the main building blocks?
What types of relationship are used? If you can, provide
examples by referring to the extracts given in paragraph 2.4.
The core relations we've been assembling are subsumptive. We are working to develop - based on the OBO Relations Ontology - ObjectProperty relations to capture the more complex relations that will - for instance - enable us to separately represent and process structure and function in the context of nervous system mesoscopic structure.
2.6. Is a machine-readable representation of the vocabulary
already available (e.g. as an XML document)? If so, we would be
grateful if you could provide some example data or point us to a hyperlink.
OWL and OWLDoc (HTML) representations of BIRNLex will be available from www.nbirn.net soon.
2.7. Are any software applications used to create and/or maintain
the vocabulary?
Are there any features which these software applications
currently lack which are required by your use case?
Protege-OWL.
The AnnotationProperties described above have largely been created, populated, and managed manually. We need more automated means to, for instance, draw terms from the various community ontologies and vocabularies we are linking into BIRNLex (see above).
2.8. If a database application is used to store and/or manage the
vocabulary, how is the database structured? Illustration by means
of some table sample is welcome.
See above.
2.9. Were any published standards, textbooks or written guidelines
followed during the design and construction of the vocabulary?
Did you decide to diverge from their recommendations in any
way, and if so, how and why?
We have been working close with the NCBO to adopt the OBO Foundry recommendations in the construction of our ontology.
To date, there has not been much clarification on how to both maintain the associated lexicon in an independent, though integrated manner. Use of SKOS elements has been a big help to us here, so that, for instance, we can create software applications specifically designed to draw on "skos:prefLabel", "obo_annot:synonym", "obo_annot:definition", etc.
2.10. How are changes to the vocabulary managed?
Currently we are doing this manually in Protege-OWL, but, as mentioned above, we are moving toward a client-server infrastructure that will created an RDF-based backend store and support both curation of the ontology and annotation using the ontology via Java Portlet-based applications. BIRN has a core infrastructure staff dedicated to use of the GridSphere Java Portlet implementation framework (www.gridsphere.org).
2.11. Any additional information, references and/or hyperlinks.
================================================================
Section 3. Vocabulary Mappings
================================================================
In this section we ask you to provide some information about the
mappings or links between vocabularies you would like to be able to
represent using SKOS.
Please note:
-- If your use case does not involve vocabulary mappings or links,
you may skip this section!
3.1. Which vocabularies are you linking/mapping from/to?
We have been working on several mappings which are currently being done manually. This is mainly because our need for very specific definitions makes it rarely possible to do simple string-to-string correspondences. Often we derive a preferred label for a BIRNLex class from an existing terminology, but either the lack of definition or incommensurate nature of the definition requires we create a definition that fits our usage. Therefore, it is not necessarily obvious how the mappings can be used in our infrastructure
Terminology mapping will become much more relevant as we start to include means to semi-automatically extract concepts from unstructured text.
*3.2. Please provide below some extracts from the mappings or links
between the vocabularies. Use the layout or presentation format that
you would normally provide for the users of the mappings. Please
ensure that the examples you provide illustrate all of the different
types of mapping or link.
3.3. Describe the different types of mapping used, with reference
to the examples given in paragraph 3.2.
3.4. Any additional information, references and/or hyperlinks.