Page History

...

Over 300 queries were generated and analyzed to first identify their relevance and semantic linkage, and then to specify the relations required to answer these queries. Using the preliminary data and the analysis of the queries, we defined a preliminary high-level data model. Next we identified a set of classes and properties that had to be created de novo, as well as those from existent biomedical ontologies that could be reused to implement this model. Currently, these include:

• Ontology for Biomedical Investigation (OBI)
• Basic Formal Ontology (BFO)
• RO (OBO Relation Ontology)
• Uber-Anatomy Ontology (Uberon)
• Ontology for Clinical Research (OCRe)
• Sequence Ontology  (SO)
• Software Ontology (SWO)
• NCBI Taxonomy
• Disease Ontology (DO)
• Mammalian Phenotype Ontology (MP)
• PATO - Phenotypic Quality Ontology
• Gene Ontology (GO)
• Cell Line Ontology (CO)
• Information Artifact Ontology (IAO )
• VIVO Ontology

...

In order to be able to meet all the requirements we developed an import strategy to implement a layered approach that allows to decouple research resources representation from information used to drive application appearance and behavior. This import strategy is fondly referred to as the Messy FishTM  (see Figure 1) or the ERO Matryoshka doll.

Figure 1

Lessons learned

...

In the process of developing ERO in compliance with eagle-i project requirements, best practices for biomedical ontology development, and interoperability with other ontology-based resource systems and community ontologies we have learned important lessons related to:

1. Reuse of existent ontologies

2. Use of layered import strategy

3. Best practices and Tools

...

Reuse of existing ontologies

...

Using upper level ontologies such BFO and trying to reuse existing ontologies following the OBO Foundry orthogonality principles  has the advantage of guiding the development process and enabling the integration of other ontologies. However, when it comes to driving application UIs directly from an ontology, there is a need for implementation methods which exclude some upper level classes, specify or modify properties domain and range and deal with different modeling approaches (as not all the ontologies we have reused follow the same principles).

 

Use of layered import strategy

...

The strategy we used to separate the core and the application layer has shown its effectiveness as it has enabled parallel ontology development. The challenges it presents are related to keeping the annotations current and in preventing excessive proliferation of annotation properties as a quick way to simplify application development complexity. We have identified some common requirements in terms of annotations that are useful to drive a UI directly from an ontology and we will formalize them as design pattern. 

Best practices and tools

For the development process, we have used Ontofox as a useful tool to MIREOT classes form other ontologies and generate our imports files. To drastically streamline this process, we developed scripts to automate the syncing of import files. To have the whole MIREOT roundtrip process integrated into an ontology editor such Protege would be ideal (i.e. selection of terms from an external ontology, updates to imported terms in the proper import files and checks of the ontology's consistency). We also identified the need to provide some community views or 'slims' with different content granularity and axiomatic complexity. Although at the present time there are some useful tools to facilitate this process (Ontodog)  to have these facilities integrated into an editing tool would be ideal. 

Review process

...

Before the official release we have asked Jie Zheng and Melanie Courtot to review the ontology.

 

The reviewers' comments and the actions taken are available in this Google doc.  

For more info about our development strategies and lessons learned check our publications. 

...