HCLS/OntologyTaskForce/Create Bridging Ontology between NeuronDB and CoCoDat databases and UMLS Common Vocabulary

From W3C Wiki
< HCLS‎ | OntologyTaskForce
Revision as of 11:56, 19 September 2006 by (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Create a Bridging Ontology between NeuronDB and CoCoDat databases and UMLS Common Vocabulary

Whatever way I look at it, this seems to be a labor intensive (manual) task.

Task:

1. Link (as owl:sameAs, owl:differentFrom, ?) individuals in classes in each database separately with terms in the common vocabulary

       (a bridge ontology to the common vocabulary for each database with a single bridge ontology linking these, e.g., http://hissa.nist.gov/jb/neuro-db-integration-model/m2-integrator.owl)

Or

2. Link (as owl:sameAs, owl:differentFrom, ?) individuals in classes in all databases together with terms in the common vocabulary

        (one bridge ontology for all databases linking individuals in classes with terms in the common vocabulary)

The latter method matches John Barkley's initial example (http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Jun/0000.html). Nevertheless, I'm trying to understand:

1. Are they equivalent? (seem to be)

2. What are the extensibility and maintainability implications of each approach? (best practices)

With regard to maintainability, in (1), curators of each database separately maintain their bridge ontology to the common vocabulary. A single bridge ontology links database bridge ontologies by simply importing them. Such a single bridge between databases can be created on an ad-hoc basis by anyone wanting to integrate a custom selection. In the alternative approach (2), curators collaborate on maintaining the single bridge ontology integrating terminology between the common vocabulary and all databases to be integrated.

Finally, the big question is "what does this buy us?"

So far, my playing around with this indicates "not much" beyond simply connecting databases enabling a query capability using common vocabulary.

The databases have good anatomical hierarchies in place and the UMLS has a set of terms but there is little or no ontology in place that would result in bringing up substantia nigra pars compacta data, for instance, if we did a search on Parkinson's disease and dopamine neurons.

Can anyone confirm or disprove this suspicion?

If this is true, then I think we need to include a Parkinson's disease ontology in the bridge ontology.

Thoughts?

Task Objectives

Rationale

Scope

Parkinson’s disease at the cellular level.

NeuronDB and CocoDat databases UMLS common vocabulary

CoCoDat is a microcircuitry database containing data that characterize the experimental procedures, the brain structure (region, layer, neuron type and cellular compartment), as well as the experimental results of the following categories: morphology, firing properties, ionic currents, ionic conductances, synaptic currents, connectivity.

NeuronDB is a web-accessible database which integrates neuronal membrane properties (neurotransmitter receptors, ion channels and the transmitters themselves) with neuron morphology.

Examples demonstrating the need for ontological mapping between NeuronDB and CoCoDat

Example 1: Mapping between different neuron types

One very basic ontology issue stems from the fact that different databases identify types of neurons differently. For example, SenseLab includes the following two specific types of neuron:

  1. “Neocortical pyramidal neuron: deep,”
  2. “Neocortical pyramidal neuron: superficial.”

CoCoDat identifies these as a single type of neuron, “Pyramidal neuron.” Distinction among types of pyramidal neurons requires additional information about the neuron’s location. Normally this would include the brain region where the neuron is located, in this case the neocortex. Since all of CoCoDat’s data concerns the neocortex, however, the brain region is implicitly assumed in CoCoDat. The location also includes the layer within the neocortex. Layers 1-3 are “superficial,” while layers 4-6 are “deep.” Thus NeuronDB’s term “Neocortical pyramidal neuron: superficial” would map to the following general representation in CoCoDat:

  1. Pyramidal neuron
  2. Region: Neocortex
  3. Layer: Layer1, Layer2, Layer3

Here the single concept in NeuronDB (Neocortical pyramidal neuron: superficial) has mapped to several concepts (Pyramidal neuron, Neocortex, Layer1, Layer2, and Layer3) related by two relationships (Region and Layer).

Example 2: Mapping between different neuronal compartment structures

Another interesting set of problems occurs with dendritic compartments because CoCoDat and NeuronDB partition these compartments differently.

  1. NeuronDB allows two types of dendrite (apical and basal), each of which can have three compartments (proximal, medial, and distal). SenseLab’s designers believe that this degree of compartmentalization is necessary for describing the different functional phenotypes of neurons.
  2. CoCoDat employs two ways to conceptualize neuronal compartments.
    • One approach might be called anatomically-based and is similar in spirit to NeuronDB’s approach, but different in structure. The basal dendrite is not subdivided into compartments. The apical dendrite is divided into the same three compartments used by NeuronDB, but also has an additional compartment (the apical dendritic shaft). The apical dendrite also has an associated oblique dendrite that starts after the apical dendrite shaft and which is not further subdivided. (For simplicity, NeuronDB’s designers decided to subsume the oblique dendrite as part of the apical dendrite.)
    • The second approach might called experimentally-based. If experimental dendrite data is obtained close to the neuron cell body, then it is classified as proximal. If experimental dendrite data is obtained more distant from the neuron cell body, the it is classified as distal.

As a result, when queries to NeuronDB and CoCoDat involve neuronal compartments, there are a number of quite complex and detailed issues involving ontology mismatch and granularity. Here again, these issues may result in uncertainty as to what data should be returned in response to a particular query.

Participants

Donald Doherty, Kei Cheung, John Barkley

Use case context


Problem statement for this use case


Deliverables

  1. 1st Deliverable
    • bullet item
    • bullet item
  2. 2nd Deliverable
    • bullet item
    • billet item

Related resources

Task supports and dependencies

Tools and Services

Timeline for Task Completion

  • Stage 1 (3 month goals)
  • Stage 2 (6 months goals)

Categories