The document discusses the development of an ontology for annotating and retrieving biomedical resources as part of the eagle-i project. It describes the aims of the project, the role of the ontology, and challenges faced in developing the ontology. Key points include: 1) The eagle-i project aims to make scientific resources more discoverable through a federated network of repositories indexed with an ontology. 2) The ontology was designed to represent resource information, control the user interface of data collection/search tools, and be interoperable with other biomedical ontologies. 3) Challenges included balancing application needs with reuse of existing ontologies, managing different ontology layers, and coordinating with

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. Outline
 eagle-i project
 Aims
 Ontology role
 eagle-i ontology
 Requirements
 Implementation
 Implementation choices
 Challenges
consortium

3. eagle-i
NIH funded pilot project working to make scientific resources more
visible via a federated network of nine institutional repositories
Index invisible resources
reagents, 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. 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. 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. 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. Implementation
Ontology/Method Scope/Purpose
Basic Formal Ontology (BFO) Upper ontology
Information Artifact Ontology
Ontology metadata
(IAO)
Relation Ontology (RO) Common properties
Minimum Information to Reuse classes and properties
Represent External Ontology from external ontologies
Terms (MIREOT)

8. Ontology layers
Goal: to decouple research resources representation from
information 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. 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. Application-specific module
Contains properties and classes required to drive the UIs of
the 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. 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. 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. 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. Data Collection
Application
‘eagle-i preferred
definition’ is used
for tooltips
Classes annotated ‘eagle-i preferred
with ‘primary label’ is used for
resource 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. Challenges and benefits
 Reuse of existent ontologies
 Ontology Layers
 Application-specific module
 Community coordination and alignment
 Best practices and tools
consortium

16. Reuse of existent ontologies
Using 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 annotation
consortium

17. Ontology layers
Advantages
– 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 development
Challenges
– 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. 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. 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. 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. 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. eagle-i core module:
http://code.google.com/p/eagle-i/
Carlo Torniai
torniai@ohsu.edu
consortium