Collaborative ontology development by scientists

1. Collaborative ontology development by scientists Melissa Haendel

2. Setting the stage Who we are and what do we need What are our bottlenecks: Getting info from the domain experts Ontology tools Synchronizing ontologies 3. Modularizing anatomy ontologies 4. Ideas for collaborative ontology editing

3. Who are we? What do we want? Domain Experts: Anatomists, comparative morphologists, developmental biologists, immunologists, neuroscientists, etc. Engineers: have to build tools that can consume ontologies and give the Domain Experts the right results Domain experts: want to query for gene expression and phenotypes across species Ontologists: have to be able to interpret and represent domain knowledge computationally Ontologists: Biologists-gone-informatics, computer scientists and logicians Engineers: Our tool builders Ontologies and tools to develop them

4. Anatomy and phenotype ontologies have work hard for us • Enable comparison of structures across different organisms • Standardization of vocabulary among 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

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

6. Ontology development workflow and bottlenecks Term requested reconcile

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

8. Ontology development workflow and bottlenecks reconcile

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

10. 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 across interoperable ontologies

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

12. Two ontology editors (and viewers) commonly used by the biomedical community OBOEdit- OBO ontology editor and viewer http://oboedit.org/ More biologist-friendly (thank you John!) Protégé - OWL ontology editor and viewer http://protege.stanford.edu/ Tool used by broader community Both tools are non-trivial to learn to use Neither have a lot of bulk operations, import/export different formats easily, or deal with synchronization readily There is a barrier for domain experts to contribute knowledge, and a bottleneck for editors to get this knowledge into ontologies efficiently

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

14. Ontology mappings are often not useful (For anatomy, you may want to remove the mappings that NCBO Bioportal creates for your ontology and/or ask not to allow mapping)

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

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

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

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

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

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

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

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

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

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

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

26. Returning to the bottlenecks in our process…Looking for solutions 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!)

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

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

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

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

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