Skip to content

Developing an OBO Reference Ontology

Warning

These materials are under construction and incomplete.

Prerequisites

Preparation

  • TBD

What is delivered as part of the course

Description: Leading a new or existing OBO project; maybe reference ontology develoment?

Learning objectives

  • detailed knowledge of OBO principles and best practises
  • use OBO Dashboard
  • use OBO Registry
  • use PURL system

Tutorials

Week 8: Ontology Development

First Instructor: Nico Matentzoglu, Becky Jackson

Description

By the end of this session, you should be able to:

  • Merge ontology modules & imports with robot merge
  • Create a classified version of an ontology with robot reason
  • Add metadata to an ontology with robot annotate
  • Create a simple release workflow using ROBOT commands in a Makefile
  • Create a new ontology with ODK

Preparation

Please complete the following and then read the section below: - ROBOT Mini-Tutorial, part 2 - Software Carpentry: Automation and Make

What is an ontology release?

Like software, official OBO Foundry ontologies have versioned releases. This is important because OBO Foundry ontologies are expected to be shared and reused. Since ontologies are bound to change over time as more terms are added and refined, other developers need stable versions to point to so that there are no surprises. OBO Foundry ontologies use GitHub releases to maintain these stable copies of older versions.

Generally, OBO Foundry ontologies maintain an "edit" version of their file that changes without notice and should not be used by external ontology developers because of this. The edit file is used to create releases on a (hopefully) regular basis. The released version of an OBO Foundry ontology generally a merged and reasoned version of the edit file. This means that all modules and imports are combined into one file, and that file has the inferred class hierarchy actually asserted. It also often has some extra metadata, including a version IRI. OBO Foundry defines the requirements for version IRIs here.

The release workflow process should be stable and can be written as a series of steps, e.g.: 1. Update modules from templates 2. Merge ontology modules & the main edit file into one 3. Assert the inferred class hierarchy 4. Add a version IRI & other important metadata

This series of steps can be turned into ROBOT commands: 1. robot template 2. robot merge 3. robot reason 4. robot annotate

Since we can turn these steps into a series of commands, we can create a Makefile that stores these as "recipes" for our ontology release!

Additional materials and resources

Contributors