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

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

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 zfish anaotmy here- how do these relate?

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

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

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

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 Ontologies must be intelligible to: HumansMachines  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

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. Term needed for annotation Ontology development workflow and bottlenecks reconcile

15. Term requested Ontology development workflow and bottlenecks reconcile

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

17. Ontology development workflow and bottlenecks reconcile

18. GO CL CARO TAOAAO XAOZFA MA MP UBERON Ontology development workflow and bottlenecks reconcile Synchronize?

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

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

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

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  Mapping (bioportal set,..)  Direct reconciliation (TAO and ZFA)  Synchronization using imports Three approaches:

26. Ontology mappings are often not useful FMA (human) tibiaFBbt (fruitfly) tibia FMA extensor retinaculum of wrist MA retina GAZ (geography) ColonFMA (human) Colon ZFA (zebrafish) aortic archMA (mouse) arch of aorta GAZ (geography) SerpentineCHEBI (chemistry) serpentine Dictyostelium: giant cellFMA giant cell ZFA (zebrafish) blastodermFbbt blastoderm stage PATO (quality) maleChebi (chemical) maleate 2(-)

27. 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 synchronized Xrefs logic can be less clear and more difficult to use

28. Synchronization by import across ontologies 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 CARO VAO Present TAOModularized ontology

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 celltissue muscle tissue mesonephros limb antenna weberian ossicle mammary gland nervous system mollusc foot tentacle mantle pupal DN3 period neuron mushroom body brachial lobe pons vertebra vertebral column circulatory system appendage mesoder m gut tibia gland bone skeletal tissue parietal bone fin gonad trachea respiratory airway link (small sample) tibiafibula larva user/editor view metencephalon neuro view skeletal view mammalian view ventral nerve cord mollusc view neuro view 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. zebrafish caro / uberon/all celltissue metazoa muscle tissue 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 vertebra vertebral column circulatory system appendage mesoderm gut tibia gland bone skeletal tissue parietal bone fin gonad trachea respiratory airway cross-ontology link (sample) amphibia tibiafibula larva shell cuticle skeleton import mousehuman Model view

35. Idealized protocol for new AOs 1.Collect draft list of terms 2.Subdivide roughly into applicability at taxonomic levels 3.Request new terms from existing AOs above you 4.Is a new mid-level AO required? - yes – collaborate and create, go to 1. 5.Import pre-reasoned subset from next AO above 6.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. 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:

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  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…..

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

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 1: Taxon 2: