From Fins to Limbs to Leaves: Facilitating Anatomy Ontology Interoperability July 27, 2011...
-
Upload
nathaniel-ryan -
Category
Documents
-
view
223 -
download
0
Transcript of From Fins to Limbs to Leaves: Facilitating Anatomy Ontology Interoperability July 27, 2011...
From Fins to Limbs to Leaves:Facilitating Anatomy Ontology
InteroperabilityJuly 27, 2011
IntroductionMelissa Haendel
Setting the stage
1. Who are we? What do we need?
2. What is an anatomy ontology?3. What are our bottlenecks:
Getting info from the domain experts Ontology tools Synchronizing ontologies
What is an anatomy ontology ?
A anatomical classification. There are many useful ways to classify parts of organisms:
its parts and their arrangement its relation to other structures
what is it: part of; connected to; adjacent to, overlapping?
its shape its function its developmental origins its species or clade its evolutionary history
What kinds of anatomy ontologies exist?
GO has an anatomy ontology
Pic of zfish anaotmy here- how do these relate?
How do we reason across different levels of granularity?
lateral line development
neuromast development
hair cell development
cilium development
?
?
cilium part_of hair cell part_of neuromast
hair cell part_of neuromast
neuromast part_of lateral line
GO
Phenotype ontologies also have inherent anatomy
Designed primarily for annotation of phenotypes within a single species
WBbt C. elegansphenotype
Anatomical inference
The scientific knowledge in an ontology can make the reasons for classification explicit–e.g.
Any sense organ that functions in the detection of smell is an olfactory sense organ
All large basiconic sensilla of the antenna function in detection of smell
Therefore, all large basiconic sensilla of the antenna are are olfactory sense organs
Need visual here. Two example, one internal to a single ontology, one across onotlogies.
How inference can help, how it can hurt…
The scientific knowledge in an ontology can make the reasons for classification explicit
Need visual here.
Anatomy ontologies have work hard for us
Ontologies must be intelligible to:
Humans Machines
Enable comparison of structures across different organisms, scales
Standardization of vocabulary among and between communities
Integration across databases Query across large amount of data Automatic reasoning to infer related classes Error checking Annotation consistency
Why ontology development is like software or database development
Ideal case: maintainable
basic maintenance (e.g. correcting simple errors) is easyscalable
grow your project as large as you need without breaking itextensible
easy to add new functionality without breaking existing integrate-able
Can integrate easily with work of others – so you don’t have to solve all problems yourself
Why ontology development is like software or database development
Ideal case - Future editors can build on your workMaintainable –by multiple editors
basic maintenance (e.g. correcting simple errors) is easyScalable –by multiple editors
grow your project as large as you need without breaking itextensible–by multiple editors
easy to add new functionality without breaking existing integrate-able
Can integrate easily with work of others – so you don’t have to solve all problems yourself
Anatomy ontology considerations An ontology is a classification There are many useful ways to classify anatomy Maintaining multiple classification schemes by hand
is impracticalSo you should automate it.
Everybody makes mistakesSo you should let the computer find errors for you
Re-use other people’s work where possibleImport class hierarchiesUse common patterns
Cautionary note – formal languages have limitations. Don’t expect to be able to express everything!
Term needed for annotation
Ontology development workflow and bottlenecks
reconcile
Term requested
Ontology development workflow and bottlenecks
reconcile
Term discussed by community
Ontology development workflow and bottlenecks
reconcile
Ontology development workflow and bottlenecks
reconcile
GO
CL
CARO
TAOAAO
XAO ZFA
MA
MPUBERON
Ontology development workflow and bottlenecks
reconcile
Synchronize?
XXX pitch use of caro here?Something more about reasoning across
many ontologies, knowing that your work affects others, use of imports
Common upper ontologies can facilitate synchronization
1) Extracting domain knowledge into an ontology efficiently
2) Multiple ontology editing tools, each with pros and cons, neither easily used by domain experts
3) Synchronization and reasoning across interoperable ontologies (Chris Mungall)
Three bottlenecks
Two ontology editors (and viewers) commonly used by the biomedical community
http://oboedit.org/
OBOEdit- OBO ontology editor and viewer
Protégé - OWL ontology editor and viewer
http://protege.stanford.edu/
Not going to talk about these as you either know about them already or will learn to use them later today
How can we increase the efficiency of extracting knowledge from domain experts?
An example of what has worked well so far:
1862 Christian Schussele
Familiar tooling: Google docs, Phenote, ExcelVisualization: Cmap, Vue, GraphViz
Need too merge different sources of informationNeed a way to get this information into a computable form
Looking for solutions to the bottlenecksNeed easy-to-use tools for information captureIdeally based on existing familiar toolsAuto-populated from/to ontologiesSocial management - who is responsible for what
Need better import/export functionality: - into/out of ontology editors from simple collection tools- from a myriad of ontology sources
Need better interoperability between editors/formatsNeed enhanced bulk operations
Need to know specific requirements for building tools and user feedback
Need money and opportunities to interact (like this one!)
Chris I think your talk starts here…
How to synchronize ontologies
Mapping (bioportal set, ..) Direct reconciliation (TAO and ZFA) Synchronization using imports
Three approaches:
Ontology mappings are often not useful
FMA (human) tibia FBbt (fruitfly) tibia
FMA extensor retinaculum of wrist
MA retina
GAZ (geography) Colon FMA (human) Colon
ZFA (zebrafish) aortic arch MA (mouse) arch of aorta
GAZ (geography) Serpentine CHEBI (chemistry) serpentine
Dictyostelium: giant cell FMA giant cell
ZFA (zebrafish) blastoderm Fbbt blastoderm stage
PATO (quality) male Chebi (chemical) maleate 2(-)
Zebrafish terms are is_a subtypes of teleost terms
is_a
Zebrafish Anatomy Teleost Anatomy Ontology
Reconciliation and linking between TAO and ZFA
Logic implemented via Xrefs- difficult to keep synchronizedXrefs logic can be less clear and more difficult to use
Synchronization by import across ontologies
One can import a whole ontology or just portions of another ontologyMIREOT: Minimum information to reference an external ontology term
This strategy requires better facilities while editing
CARO
VAO
Present TAO Modularized ontology
OntoFox: a Web Server for MIREOTing Good things: Based on MIREOT principle Web-based data input and output Output OWL file can be directly imported in your ontology No programming needed Programmatically accessible
Improvements: Integration into ontology editing tools More customizable http://ontofox.hegroup.org
We need synchronization solutions that are integrated within ontology editing
tools
What IS the anatomy ontology landscape?How can we efficiently build our anatomy
ontologies to be most interoperable?
We could have built: A single ontology for ontology editors and consumers Different editors have editing rights to different ontology partitions
- by taxon- by domain (e.g. neuroscience, skeletal anatomy)
No taxon-specific subtypes- use structure, function etc. as differentia
Dynamic views according to user needs
Ontology landscape model view
cell tissue
muscletissue
mesonephros
limb
antenna
weberian ossicle
mammary gland
nervous system
mollusc foot
tentacle
mantle
pupal DN3 period neuron
mushroom body
brachial lobe
pons
vertebravertebralcolumn
circulatory system appendage
mesoderm
gut
tibia
gland
bone
skeletaltissue
parietalbone
fin
gonad
trachea
respiratoryairway
link(small sample)
tibiafibula
larva
user/editorview
metencephalon
neuroview
skeletalview
mammalianview
ventralnervecord
molluscview neuro
view
skeletalview
Proposed model moving forward
Maintain series of ontologies at different taxonomic levels- euk, plant, metazoan, vertebrate, mollusc, arthropod,
insect, mammal, human, drosophila Each ontology imports/MIREOTs relevant subset
of ontology “above” it- this is recursive
Subtypes are only introduced as needed Work together on commonalities at appropriate
level above your ontology
zebrafish
caro / uberon/allcell tissue
metazoa
muscletissue
vertebrata
mesonephros
limb
arthropoda
antenna
teleost
weberian ossicle
mammalia
mammary gland
nervous system
mollusca
foot
cephalopod
tentacle
mantle
drosophila
neuron types XYZ
mushroom body
brachial lobe
NO pons
vertebravertebralcolumn
circulatory system
appendage
mesoderm
gut
tibia
gland
bone
skeletaltissue
parietalbone
fin
gonad
trachea
respiratoryairway
cross-ontologylink (sample)
amphibia
tibiafibula
larva
shellcuticle
skeleton
import
mouse human
Model view
Idealized protocol for new AOs
1. Collect draft list of terms2. Subdivide roughly into applicability at taxonomic
levels3. Request new terms from existing AOs above you4. Is a new mid-level AO required?
- yes – collaborate and create, go to 1.5. Import pre-reasoned subset from next AO above6. Build your ontology (David will take it from here in his talk later today)
Modularizing ontologies- positive reinforcement Identify key points of integration between ontologies Modularize based on domain or taxon
Import and reuse rather than cross-referencing or “aligning”
Let the reasoner help do the work Work together to distribute work
• To get the imports working well• To have distributed social responsibility assigned• Design patterns to ensure we are all doing the same thing• To check for consistency and errors across multiple ontologies using reasoners to get correct results for all users
-These ontologies are supposed to be orthogonal but aren’t always
• Visualization tools that can aid non-ontology experts in identifying errors across multiple ontologies
Modularizing ontologies – We need:
Existing tools for collaborative ontology editing don’t quite get us there
Google Refine has nice features for manipulating data, including RDF exports, but isn’t collaborative
Mapping Master for Protégé enables generation of OWL from spreadsheets, but is not collaborative and requires ontology knowledge
Web Protégé isn’t fully-fledged and is not useful for non-technical contribution
Ideas for collaborative ontology editing
Extracted from ontology with perl script Need to be edited by domain experts, and then
converted back in OWL Need to be merged with existing OWL file
Example: File extracted from ontology for this meeting:
There is a better way…..
Ideas for using Google Docs Enable creation of Google spreadsheets that curators and domain
experts can edit with the following features:
Tell Google spreadsheet which columns are which from ontology input file: labels, parents, URIs, xref, class, etc
Live-updated with latest external ontology versions using SPARQL
Export OBO/ RDF/ OWL serialization Enable search on external ontologies via autocomplete Track changes
This will solve some of the sync problems because the queries are executed whenever the doc is open or updated
Ideas for using Google Docs Enable creation of Google Drawings that curators and
domain experts can edit with the following features: Import of external ontologies Have relations and classes exported out from Google Drawing Export OBO/ RDF/ OWL serialization Linked to Google Spreadsheet Track changes
Ontology editor dreams
A truly collaborative web-based editing platform (a la Web Protégé) compatible with OWL and OBO
Supporting: Import and export of customizable
spreadsheets from Google Docs Creation of “live templates” (spreadsheet in
synch with SPARQL endpoints) Supports MIREOT import Users roles and permission Web based versioning
Different relationships for different taxa
Taxon 1: Taxon 2: