From Fins to Limbs to Leaves: Facilitating Anatomy Ontology Interoperability July 27, 2011

1. From Fins to Limbs to Leaves:Facilitating Anatomy Ontology InteroperabilityJuly 27, 2011 Introduction Melissa Haendel

2. Setting the stage Who are we? What do we need? What is an anatomy ontology? What are our bottlenecks: Getting info from the domain experts Ontology tools Synchronizing ontologies

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

4. What kinds of anatomy ontologies exist?

5. GO has an anatomy ontology Pic of zfishanaotmy here- how do these relate?

6. How do we reason across different levels of granularity? GO lateral line development neuromast development ? hair cell development neuromast part_of lateral line ? hair cell part_of neuromast cilium development cilium part_ofhair cell part_ofneuromast

7. Phenotype ontologies also have inherent anatomy WBbt C. elegans phenotype Designed primarily for annotation of phenotypes within a single species

8. 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 basiconicsensilla of the antenna function in detection of smell • Therefore, all large basiconicsensilla of the antenna are are olfactory sense organs Need visual here. Two example, one internal to a single ontology, one across onotlogies.

9. How inference can help, how it can hurt… The scientific knowledge in an ontology can make the reasons for classification explicit Need visual here.

10. Anatomy ontologies have work hard for us • 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 Ontologies must be intelligible to: Humans Machines

11. Why ontology development is like software or database development Ideal case: • maintainable • basic maintenance (e.g. correcting simple errors) is easy • scalable • grow your project as large as you need without breaking it • extensible • 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

12. Why ontology development is like software or database development Ideal case - Future editors can build on your work • Maintainable –by multiple editors • basic maintenance (e.g. correcting simple errors) is easy • Scalable –by multiple editors • grow your project as large as you need without breaking it • extensible–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

13. Anatomy ontology considerations • An ontology is a classification • There are many useful ways to classify anatomy • Maintaining multiple classification schemes by hand is impractical So you should automate it. • Everybody makes mistakes So you should let the computer find errors for you • Re-use other people’s work where possible Import class hierarchies Use common patterns • Cautionary note – formal languages have limitations. Don’t expect to be able to express everything!

14. Ontology development workflow and bottlenecks Term needed for annotation reconcile

15. Ontology development workflow and bottlenecks Term requested reconcile

16. Ontology development workflow and bottlenecks Term discussed by community reconcile

17. Ontology development workflow and bottlenecks reconcile

18. Ontology development workflow and bottlenecks GO MP UBERON CARO MA AAO TAO XAO ZFA Synchronize? CL reconcile

19. Common upper ontologies can facilitate synchronization XXX pitch use of caro here? Something more about reasoning across many ontologies, knowing that your work affects others, use of imports

20. Three bottlenecks Extracting domain knowledge into an ontology efficiently Multiple ontology editing tools, each with pros and cons, neither easily used by domain experts 3) Synchronization and reasoning across interoperable ontologies (Chris Mungall)

21. Two ontology editors (and viewers) commonly used by the biomedical community OBOEdit- OBO ontology editor and viewer http://oboedit.org/ 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

22. 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, Excel Visualization: Cmap, Vue, GraphViz Need too merge different sources of information Need a way to get this information into a computable form

23. Looking for solutions to the bottlenecks Need easy-to-use tools for information capture Ideally based on existing familiar tools Auto-populated from/to ontologies Social 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/formats Need enhanced bulk operations Need to know specific requirements for building tools and user feedback Need money and opportunities to interact (like this one!)

24. Chris I think your talk starts here…

25. How to synchronize ontologies Three approaches: • Mapping (bioportal set, ..) • Direct reconciliation (TAO and ZFA) • Synchronization using imports

26. Ontology mappings are often not useful

27. Zebrafish terms are is_asubtypes of teleost terms Reconciliation and linking between TAO and ZFA Teleost Anatomy Ontology Zebrafish Anatomy is_a Logic implemented via Xrefs- difficult to keep synchronized Xrefs logic can be less clear and more difficult to use

28. Synchronization by import across ontologies CARO VAO Present TAO Modularized ontology One can import a whole ontology or just portions of another ontology MIREOT: Minimum information to reference an external ontology term This strategy requires better facilities while editing

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

30. We need synchronization solutions that are integrated within ontology editing tools

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

32. Ontology landscape model view mammalian view link (small sample) ventral nerve cord cell tissue mesoderm user/editor view gut circulatory system gonad appendage larva gland respiratory airway muscle tissue skeletal tissue nervous system mollusc view neuro view neuro view trachea bone mantle limb fin vertebra tibia pons vertebral column mushroom body skeletal view mollusc foot parietal bone metencephalon mesonephros antenna mammary gland weberianossicle tentacle pupal DN3 period neuron tibiafibula brachial lobe skeletal view

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

34. Model view cross-ontology link (sample) caro /uberon/all cell tissue import metazoa skeleton nervous system gut gonad appendage circulatory system gland mesoderm respiratory airway larva muscle tissue skeletal tissue mollusca arthropoda vertebrata trachea bone mantle mushroom body limb fin vertebra tibia shell cuticle vertebral column foot antenna mesonephros parietal bone cephalopod drosophila teleost mammalia amphibia tentacle neuron types XYZ weberianossicle mammary gland tibiafibula brachial lobe mouse human zebrafish NO pons

35. Idealized protocol for new AOs • Collect draft list of terms • Subdivide roughly into applicability at taxonomic levels • Request new terms from existing AOs above you • Is a new mid-level AO required? - yes – collaborate and create, go to 1. • Import pre-reasoned subset from next AO above • Build your ontology (David will take it from here in his talk later today)

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

37. Modularizing ontologies – We need: • 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

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

39. Ideas for collaborative ontology editing Example: File extracted from ontology for this meeting: • 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 There is a better way…..

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

41. Ideas for using Google Docs Enable creation of Google Drawingsthat 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

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

43. Different relationships for different taxa Taxon 2: Taxon 1: