https://www.wikidata.org/wiki/Q112336713

Manage your ontology's life cycle with the Ontology Development Kit (ODK)! The ODK is

• a toolbox of various ontology related tools such as ROBOT, owltools, dosdp-tools and many more, bundled as a docker image;
• a set of executable workflows for managing your ontology's continuous integration, quality control, releases and dynamic imports.

For more details, see

• 2022 Paper
• FOSDEM 2022 Presentation
• 2018 Article
• ICBO Workshop Slides 2018
• ICBO Workshop Slides 2017
• Docker image on Docker Hub

• How-to guides:
  • How to create your first repository with the ODK.
  • How to add license, title and description to your ontology.
  • How to import large ontologies efficiently.
• Reference:
  • Learn about the different kinds of release artefacts.
  • Learn about the ODK Project Configuration Schema for allowed parameters in your [project]-odk.yaml.
• Community:
  • If you have issues, file them here: https://github.com/INCATools/ontology-development-kit/issues.
  • We also have an active community on Slack; you can request access by making a ticket here as well.

• @gouttegd Damien Goutte-Gattat (ODK Lead, German BioImaging e.V.)
• @matentzn Nicolas Matentzoglu (ODK Deputy, Semanticly)
• @cmungall Chris Mungall (ODK Founder, LBNL)

• @anitacaron Anita Caron (Novo Nordisk)
• @balhoff Jim Balhoff (RENCI)
• @dosumis David Osumi-Sutherland (Sanger)
• @ehartley Emily Hartley (Critical Path Institute)
• @hkir-dev Huseyin Kir (EMBL-EBI)
• @shawntanzk Shawn Tan (Novo Nordisk)
• @ubyndr Ismail Ugur Bayindir (EMBL-EBI)

Full list of contributors: https://github.com/INCATools/ontology-development-kit/graphs/contributors

https://doi.org/10.1093/database/baac087

Outstanding contributors are groups and institutions that have helped with organising the ODK development, providing funding, advice and infrastructure. We are very grateful for all your contributions - the project would not exist without you!

The Monarch Initiative is a consortium of medical, biological and computational experts that provide major ontology services such as the Human Phenotype Ontology, Mondo and an integrative data and analytic platform connecting phenotypes to genotypes across species, bridging basic and applied research with semantics-based analysis.

https://monarchinitiative.org/

The Samples, Phenotypes and Ontologies (SPOT) team, led by Helen Parkinson, is concerned with high throughput mammalian phenotyping, Semantics as a Service and human genetics resources. Members of the SPOT team including David Osumi-Sutherland have made major contributions to ODK, and provided advice, use cases and funding.

https://www.ebi.ac.uk/spot/

https://hobi.med.ufl.edu/research-2/biomedical-informatics-3/

Knocean Inc. offers consulting and development services for science informatics, in particular in the area of biomedical ontologies and ontology tooling.

http://knocean.com/

The Critical Path For Alzheimer’s Disease (CPAD) is a public-private partnership aimed at creating new tools and methods that can be applied to increase the efficiency of the development process of new treatments for Alzheimer disease (AD) and related neurodegenerative disorders with impaired cognition and function.

https://c-path.org/

The ODK is provided as a set of Docker images:

• obolibrary/odklite (providing the essential tools required by all standard ODK workflows);
• obolibrary/odkfull (providing a richer set of tools that may be used in custom workflows).

Docker is the primary supported containerization engine to use the ODK images. On macOS and Windows, the docker tool is typically installed as part of Docker Desktop. On GNU/Linux, it should be available in your distribution’s package repository (possibly under various names, for example docker.io on Debian and moby-engine on Fedora).

The ODK has also been tested to work with Singularity and (on macOS only) Apple Container.

While ODK-managed repositories will contain a run.sh/run.bat script to facilitate calling the docker tool, the best way of running an ODK workflow is to use the dedicated odkrun command, which is available separately.

Using odkrun is not mandatory, though – just strongly recommended.

You can use the odk install command of the ODK Core module to install a “native ODK environment” that allows using the ODK without using a Docker image at all. See the documentation of ODK Core for more details.

Note that native environments:

• are only supported on GNU/Linux and macOS – on Windows, there is no alternative to the use of the Docker images;
• are highly experimental and not guaranteed to work – use them at your own risk!

Should you want to customize the build process of your ontology: Never do so by editing the main, ODK-generated Makefile. Put all custom workflows (including workflows that override the standard ODK workflows) in the “custom” Makefile, that you will find at src/ontology/myont.Makefile (assuming myont is the name of your ontology).

An example of how you can customise your imports for example is documented here.

The ODK is designed for creating a new repo for a new ontology. It can also be used to help figure out how to migrate an existing git repository to the ODK structure. There are different ways to do this.

• Manually compare your ontology against the templates folder and make necessary adjustments.
• Run the seed script as if creating a new repo. Manually compare this with your existing repo and use git mv to rearrange, and adding any missing files by copying them across and doing a git add.
• Create a new repo de novo and abandon your existing one, using, for example, github issue mover to move tickets across.

Obviously the last method is not ideal as you lose your Git history (then again, since most ontology projects don't seem to have a usable Git history to begin with, this may not be a great loss). Note even with git mv history tracking becomes harder.

If you have built your ontology using a previous version of ODK, migrating to a newer version can be done automatically using the provided update_repo command.

Note that customized workflows are not guaranteed to keep working after such a migration and may require additional work. Consult the changelog file for changes made between releases to assist with migration of custom workflows.

In general you do not absolutely need to migrate your repo to a newer version, but doing so will bring advantages in terms of aligning with emerging standard ways of doing things. Also, ODK developers may not be able to provide support if you run into issues while using an outdated ODK version.

You will find additional documentation in the src/ontology/README-editors.md file in your repo.

The ODK also comes with built in options to generate your own shiny documentation; see for example the PATO documentation here which is almost entirely autogenerated from the ODK.