================================================================ 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.