Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Torniai icbo

699 visualizaciones

Publicado el

  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Torniai icbo

  1. 1. Developing an application ontology for biomedical resource annotation and retrieval: challenges and lessons learned C. Torniai, M. Brush, N. Vasilevsky, E. Segerdell,M. Wilson, T. Johnson, K. Corday, C. Shaffer and M. Haendel ICBO 2011
  2. 2. Outline eagle-i project  Aims  Ontology role eagle-i ontology  Requirements  Implementation Implementation choices Challenges consortium
  3. 3. eagle-iNIH funded pilot project working to make scientific resources morevisible via a federated network of nine institutional repositoriesIndex invisible resourcesreagents, protocols, techniques, instruments, expertise, organisms, software, training, human studies, biological specimens, etc.Enable discovery by implementing semantic relationships between resourcesMake data available using ontology-driven approach to research resource annotation and discovery Facilitate development of shared semantic entities that can be referenced in publications, databases, experiments, etc. consortium
  4. 4. eagle-i ontology: development drivers 1) Represent collected resource information 2) Use the ontology to control the data collection and search applications user-interface (UI) and logic 3) Build a set of ontologies that are reusable and interoperable with other ontologies and existing efforts for representing biomedical entities. - Follow OBO Foundry orthogonality principle - Best practices for biomedical ontology development - Engage in discussions within the bio-ontology and resource discovery community (alignment with similar efforts NIF, BRO, VIVO) consortium
  5. 5. Ontology role in eagle-i architecture NIF, PubMedEnt Search Application rezGene Federated Network eagle- iontologies Repositories (RDF)Data Collection Application Glossary Resource Application information collection consortium
  6. 6. Modeling approach• Preliminary data collection to identify key properties for each resource type• Set of 300 queries used identify relationships between resources – “Which laboratories in the United States are equipped with high- resolution ultrasound machines for brachial artery reactivity testing (BART)?” – “Find in situ hybridization protocols for whole-mount preparations of Aplysia.”• Develop initial model with a set resource classes and properties created de novo and from existent ontologies consortium
  7. 7. Implementation Ontology/Method Scope/PurposeBasic Formal Ontology (BFO) Upper ontologyInformation Artifact Ontology Ontology metadata (IAO) Relation Ontology (RO) Common properties Minimum Information to Reuse classes and propertiesRepresent External Ontology from external ontologies Terms (MIREOT)
  8. 8. Ontology layersGoal: to decouple research resources representation frominformation used for application appearance and behavior Application specific module Classes, annotation properties and individuals required to drive the UIs eagle-i core ontology Classes and properties used to represent information about biomedical research resources MIREOTed ontology files Externally sourced classes and consortium properties
  9. 9. eagle-i core and mireoted sources eagle-i core ontology: 1283 classes, 56 object properties, and 61 data properties. External Ontologies Purpose/subsets Classes Ontology of research material entities, Biomedical 509 processes, devices Investigations (OBI) NCBITaxonomy Organisms taxa 192 people, organization, VIVO ontology 20 publications Ontology of Clinical human study designs and 19 Research (OCRe) facets Biomdedical Resource instruments 13 Ontology (BRO) consortium
  10. 10. Application-specific moduleContains properties and classes required to drive the UIs ofthe data collection and search applications UI Annotations file Holds annotations made on core eagle-i and MIREOTed classes and properties using these annotation values and additional properties UI Annotation Definition file Definition UI annotation properties and possible instance values for these properties consortium
  11. 11. Application-specific module design pattern– Values for the annotation properties ‘inClassGroup’ and ‘inPropertyGroup’– An example of a resource annotated as a “Primary Resource Type” consortium
  12. 12. Examples of ‘inClassGroup’ and ‘inPropertyGroup’ values Label Description Example Denotes classes for instrument’,Primary Resource Type which instances are ‘biospecimen’, ‘protocol’ collected Denotes classes or BFO classes such properties that are not ‘continuant’ or Data Model Exclude included in the model ‘occurrent’ or RO used for the data tool or relations such ‘precedes’ the search tool UIs Denotes a class for ‘antibody immunogen’ which instances can only created within Embedded Class be created in the ‘antibody’, ‘construct context of an insert’ created within embedding class ‘plasmid’ consortium
  13. 13. Additional application-specific properties Label Description Example Property Type Used to specify the Value set to domain of an imported “OBI_0000245” eagle-i domain property. Each annotation (‘organization’) for Data Property constraint will contain the URI of one RO property class ‘location_of’’ Used to specify the range Value set to of an imported property. “ERO_0000004” eagle-i range Data Property Each annotation will (‘instrument’) for RO constraint contain the URI of one property class ‘located_in’ Defines the value of Capitalized eagle-i preferred preferred label to display ‘Organization’ for Annotation label in the data collection tool OBI_0000245 Property and search UIs (‘organization’) consortium
  14. 14. Data Collection Application ‘eagle-i preferred definition’ is used for tooltipsClasses annotated ‘eagle-i preferredwith ‘primary label’ is used forresource type’ the display name Property annotated as ‘’primary property’ Construct insert is an Technique is example of a annotated as resource ‘referenced annotated as taxonomy’ an ‘embedded
  15. 15. Challenges and benefits Reuse of existent ontologies Ontology Layers  Application-specific module Community coordination and alignment Best practices and toolsconsortium
  16. 16. Reuse of existent ontologiesUsing BFO as upper level ontology and the relation ontology (RO)Advantages– Integration with other ontologies– Ease the design process– data integration and publication (Linked Open Data)Challenges– Need to exclude some classes (continuant, occurrent) from UI visualization after the inferred module has computed– Non all relevant ontologies are built using BFO– Domain and Range in RO not specified or not specific enough for an application For the future we plan to use OWL2 axiom annotationconsortium
  17. 17. Ontology layersAdvantages– effective means to drive an application UI while maintaining interoperability with external ontologies and data sources– separate what is relevant to share with the community from what was specific to an application– facilitate parallel concurrent developmentChallenges– significant effort to keep the annotations current with the core module– risk of excessive proliferation of annotation properties as quick way to simplify application development complexity.consortium
  18. 18. Application-specific module We identified a common set of requirements for bridging the gap between an application and domain-specific ontologies – application-specific labels and definitions – exclusion of sets of classes and properties from the model used by the application – restriction of domain and range for some imported properties – definition of display order of object and data properties at class level consortium
  19. 19. Community coordination Commitment to collaboration with similar efforts aimed at resource modeling – Aligned high level models with NIF, BRO, VIVO – Service, instrument (device) implemented in OBI and reused by NIF and eagle-i – Currently working on coordinated representation of reagents, biospecimens, and genotype information Challenges – Process is time consuming and it requires extra implementation efforts • Implement and import back from reference ontologies – Application ontologies have peculiar requirements • Example: Service hierarchy in eagle-i based on type of process rather than input and output of the process (OBI) consortium
  20. 20. Best practices and tools Need of best practices and tools for – Reusing/reference existent ontologies • Ontofox, OWL module extractor, NCBO extractor service – Have tools integrated in ontology editors (Protégé) • Plugins for managing and syncing imports and MIREOTed terms – Have several “community views” or ‘slims’ that could be directly imported with different level of complexity consortium
  21. 21. Conclusion Developing an ontology-driven application has been an important benchmark for usage of biomedical ontologies. We have designed a layered set of ontologies, consisting of a broadly applicable core ontology and application-specific module  Requirements and principles to inform a general design pattern for building applications that rely on ontologies for their logic and user interface Future steps  refining and documenting these requirements  sharing our lessons learned  engaging in efforts addressing the issues we have exprienced consortium
  22. 22. eagle-i core module: Carlo consortium