Descripción general

ROBOT proporciona una forma estandarizada pero configurable de soportar el ciclo de vida de desarrollo de ontologías a través de una biblioteca de funcionalidad común de alto nivel y una interfaz de línea de comandos. ROBOT se basa en la API de OWL y es compatible con todas las sintaxis de ontología que admite la API de OWL: RDF/XML, OWL/XML, Turtle, Sintaxis Funcional de OWL, Sintaxis de Manchester de OWL y formato OBO. El código fuente está escrito en Java y está disponible en nuestro repositorio GitHub bajo una licencia de código abierto (BSD 3). También se lanzó como una biblioteca Java en Maven Central. El código de ROBOT se puede utilizar desde cualquier lenguaje de programación que se ejecute en la Máquina Virtual Java (JVM). La herramienta de línea de comandos está empaquetada como un archivo JAR que se puede ejecutar en Unix (incluidos macOS y Linux), Windows y otras plataformas compatibles con la JVM. Este archivo JAR está disponible para su descarga desde el sitio de ROBOT GitHub, junto con scripts específicos de la plataforma para usar ‘robot’ desde la línea de comandos. Las instrucciones de instalación y la documentación están disponibles en http://robot.obolibrary.org.

Arquitectura

Anteriormente describimos la arquitectura básica de la herramienta , que resumimos aquí.

El código fuente del ROBOT consta de dos partes: ‘robot-core’ y ‘robot-command’. ‘robot-core’ es una biblioteca que soporta tareas comunes de desarrollo de ontologías, a las que llamamos «operaciones». ‘robot-comando’ proporciona una interfaz de línea de comandos dividida en» comandos», cada uno de los cuales envuelve una operación ‘robot-core’.

La mayoría de las operaciones de ROBOTS empaquetan la funcionalidad de bajo nivel proporcionada por la API de OWL en una funcionalidad de alto nivel común a los flujos de trabajo de desarrollo de ontologías en la comunidad OBO. Para obtener la mejor compatibilidad, nuestro objetivo es hacer coincidir la versión exacta de la API de OWL utilizada por ROBOT con la versión exacta utilizada por la última versión de protegido. Algunas operaciones usan Apache Jena . Cada operación funciona con objetos Java que representan ontologías de OWL,razonadores de OWL, clases de OWL, etc., mientras que cada comando funciona con cadenas de opciones y archivos de línea de comandos. Los comandos también realizan varios pasos de conversión y validación. La interfaz de línea de comandos utiliza la biblioteca de CLI de Apache Commons para analizar comandos.

Cada operación tiene un conjunto de pruebas unitarias construidas con JUnit que se ejecutan cada vez que se genera el producto final (el archivo JAR). Cada comando en ROBOT está documentado en su propia página web (por ejemplo, http://robot.obolibrary.org / reason). Las páginas web se crean en formato Markdown y contienen ejemplos de línea de comandos incrustados que se analizan y ejecutan como parte de nuestras pruebas de integración, y los resultados se comparan con un conjunto de salidas «estándar de oro». La funcionalidad ‘diff’ del ROBOT se usa cuando se comparan archivos de ontología, de lo contrario, se usa la comparación de archivos estándar. Esto ayuda a garantizar la corrección y coherencia de la documentación y el código. Las pruebas unitarias y las pruebas de integración se ejecutan en cualquier solicitud de extracción en la base de código a través de Travis continuous integration (Travis CI) , de modo que se verifican las contribuciones a la base de código.

Comandos y operaciones

ROBOT actualmente proporciona 15 operaciones (en la biblioteca «robot-core») y 19 comandos (para la interfaz de línea de comandos). Algunos comandos son bastante especializados, y la mayoría de los proyectos de ontología no harán uso de todos ellos. Aquí proporcionamos una descripción general de los comandos más comunes y generales. En cada caso, la funcionalidad del núcleo está soportada por operaciones en la biblioteca ‘robot-core’, que se puede usar independientemente de la interfaz de línea de comandos desde cualquier lenguaje de programación que se ejecute en la JVM.

Convert

Se admite una variedad de formatos de ontología de BÚHO, incluidos RDF/XML, Turtle, Manchester, formato OBO y más. Para permitir una mayor interoperabilidad, ROBOT incluye un comando «convertir» para cambiar entre formatos de ontología compatibles. Se puede encontrar una lista completa de formatos compatibles en la documentación ‘convertir’.

Razonamiento

El razonamiento es una de las operaciones más importantes en el ROBOT. El comando’ reason ‘ cubre dos usos: validación lógica de una ontología y clasificación automática. En ambos casos, los usuarios pueden elegir su razonador preferido, que se utiliza para realizar inferencias. Las ontologías grandes, como la Ontología de Genes, suelen utilizar EL ALCE, que realiza el razonamiento rápidamente utilizando el perfil EL de BÚHO. Las ontologías más pequeñas con axiomatización más rica, como la Ontología de Relaciones, suelen utilizar un razonador DL de BÚHO completo como Ermitaño .

Cuando se invoca el comando ‘reason’ en una ontología de entrada, ROBOT iniciará un reasoner utilizando la interfaz de Reasoner de la API de OWL. Las inferencias resultantes se comprueban para asegurar que la ontología sea lógicamente coherente: la ontología debe ser coherente y no tener clases insatisfactorias (p. ej., clases que no se pueden crear instancias sin introducir una inconsistencia). Si la ontología es incoherente, esto se informa y la ejecución se detiene. El ROBOT puede realizar comprobaciones adicionales opcionalmente, como asegurarse de que no se infiera que dos clases sean post-razonamiento equivalentes.

Si la ontología es consistente, el ROBOT realizará una clasificación automática. Todos los axiomas de ‘subclase de’ inferidos directamente se añaden a la ontología. Se puede configurar la generación de otros tipos de axiomas.

La afirmación de todos los axiomas inferidos es a menudo un paso fundamental en el proceso de liberación de ontologías biomédicas. Muchas de estas clases de ontología solo afirman una única superclase con nombre (‘Una subclase de B’, donde B es otra clase en la ontología), y cero o más superclases anónimas y/o clases equivalentes anónimas (‘Una subclase de/equivalentTo (R algo de B)’, donde R es una propiedad de objeto). Estas clases anónimas permiten al razonador hacer inferencias, que luego se afirman. Por lo tanto, en la versión de lanzamiento de una ontología, una clase puede tener más de una superclase con nombre.

El comando ‘reason’ tiene comandos «helper» adicionales. El comando’ relax ‘ afirma que implica subclase de axiomas de acuerdo con una regla estructural simple: una expresión ‘A equivalentTo (R algunos B) y …’ implica ‘Una subclase de R algunos B’. Esto puede ser útil ya que los consumidores de bio-ontologías a menudo esperan navegar por estas expresiones, por ejemplo, partonomía en GO y Uberon. El comando’ relax ‘ libera al desarrollador de ontologías de la necesidad de afirmarlas además de los axiomas de equivalencia, y como tal, también se incluye a menudo en los flujos de trabajo de versiones. Finalmente, el comando’ reducir ‘elimina la subclase redundante de axiomas, y se puede usar después de’ relajar ‘ para eliminar axiomas duplicados que se afirmaron en ese paso.

El comando’ materialize ‘ utiliza una Expresión Materializing Reasoner (EMR) para afirmar expresiones inferidas de la forma ‘A Subclase of R some B’ . Donde el comando’ reason ‘afirma las superclases llamadas inferidas, ‘materialize’ afirma las superclases anónimas. Esto no es parte del ciclo de lanzamiento estándar, pero puede ser beneficioso para crear subconjuntos completos de ontología.

Trabajando con ontologías externas

La fundición OBO tiene como objetivo coordinar ontologías de manera modular, de modo que partes de algunas ontologías puedan usarse como bloques de construcción para otras ontologías. Por ejemplo, la ontología de entidades químicas de ChEBI se utiliza para construir definiciones de OWL para procesos metabólicos y actividades en la Ontología de Genes . Hay una variedad de estrategias diferentes para aprovechar ontologías externas y administrar dependencias entre ontologías, dependiendo del caso de uso.

Extract

El comando ‘extract’ crea un módulo basado en un conjunto de entidades a extraer (la»semilla»). Hay cuatro métodos de extracción diferentes (como se especifica en la opción’method method’): MIREOT, TOP, BOT y STAR.

El método de extracción de MIREOT del ROBOT se basa en el principio del mismo nombre y requiere que se especifiquen una o más entidades «inferiores». Opcionalmente, también se pueden especificar una o más entidades «principales». El comando extrae todas las entidades de nivel » inferior «y sus ancestros hasta el nivel» superior » de la ontología de entrada. Si no se proporcionan entidades «superiores», se incluyen ancestros hasta la entidad de nivel superior (‘búho: Cosa’).

Los métodos TOP, BOT y STAR hacen uso de la implementación de Extracción de Módulos de Localidad Sintáctica (SLME) de la API de OWL, que garantiza capturar toda la información lógicamente relevante para el conjunto de semillas . El método BOT («bottom») incluye todas las relaciones entre las entidades de entrada y sus ancestros. El método TOP incluye todas las relaciones entre las entidades de entrada y sus descendientes. Por último, el método STAR solo incluye todas las relaciones entre entidades de entrada. El método ESTRELLA produce las salidas más pequeñas, mientras que el método SUPERIOR suele producir las salidas más grandes.

Para admitir la procedencia de los términos de la ontología, el comando’ extract ‘tiene una opción’ annot annotate-with-source true ‘ que anotará cada término extraído con la URL de la ontología de origen de la que se extrae.

Eliminar y filtrar

Los comandos’ eliminar ‘y’ filtrar ‘ se utilizan para operaciones de grano fino en axiomas de BÚHO. ‘remove’ permite a los usuarios elegir qué conjuntos de axiomas desean eliminar de una ontología de destino. ‘filter’ hace lo contrario, de modo que solo los axiomas seleccionados se copian de la entrada en una nueva ontología de salida.

Estos dos comandos funcionan comenzando con un conjunto semilla de entidades, luego aplicando varios selectores para encontrar entidades relacionadas y, finalmente, seleccionando qué tipos de axiomas eliminar o filtrar. Esperamos que solo un pequeño número de «usuarios avanzados» usen esta función directamente, pero estos comandos eventualmente proporcionarán una base para otros comandos de nivel superior.

Estos comandos se pueden usar para generar subconjuntos de ontología basados en anotaciones, ya sea filtrando o eliminando entidades con la anotación especificada. Las ontologías de fundición OBO a menudo anotan clases con la propiedad ‘in subconjunto’ para especificar dónde se puede usar una clase. El selector de anotación permite al usuario proporcionar un valor de anotación completo o un patrón para que coincida con el uso de expresiones regulares.

Merge

El comando ‘merge’ combina dos o más ontologías de entrada separadas en una sola ontología. También proporciona la capacidad de fusionar todas las ontologías importadas de una sola ontología de entrada en una ontología principal, que se usa a menudo al crear una versión.

La fusión de ontologías importadas (especificadas por las instrucciones import) en la ontología de entrada se realiza automáticamente, de modo que el usuario no necesita listar cada ontología importada como entrada. Ofrecemos la opción (‘collapse collapse-import-closure false’) para desactivar esta función, lo que admite casos en los que los usuarios pueden combinar varias ontologías de entrada que tienen instrucciones de importación pero desean mantener sus importaciones separadas.

Consulta y generación de informes

Los flujos de trabajo de ontología normalmente incluyen operaciones de consulta sobre la ontología, produciendo informes que pueden ser informativos tanto para los editores como para los usuarios de la ontología, por ejemplo, una tabla de todas las clases más sus definiciones textuales. Las operaciones de consulta también se pueden utilizar para comprobaciones de validación. El lenguaje de consulta SPARQL proporciona una forma universal y declarativa para que los mantenedores de ontologías creen informes de ontología y comprobaciones de validación . ROBOT proporciona una forma conveniente de realizar consultas con el comando ‘query’, o comprobaciones de validación utilizando ‘verify’. Además, el comando’ report ‘ incluye un paquete configurable de consultas estándar para proyectos OBO que se pueden usar en cualquier flujo de trabajo de ontología, sin requerir que el mantenedor esté familiarizado con SPARQL.

Query

El comando ‘query’ del ROBOT ejecuta consultas SPARQL en ontologías u otros recursos RDF. Esto puede ser utilizado por un mantenedor de ontología para realizar consultas interactivas, o más típicamente para incluir consultas estándar en un flujo de trabajo de ontología. El comando’ query ‘ envuelve una de las pocas operaciones que usa Apache Jena , en lugar de la API de OWL. La API de Jena permite a ROBOT cargar una ontología como una colección de triples contenidos por un objeto de modelo RDF. Proporciona un motor de consultas SPARQL para esos modelos, que usamos para ejecutar todas las consultas.

Las consultas’SPARQL SELECT’ producen una tabla de resultados separada por comas o tabulaciones. Las consultas ASK producen un archivo con un valor booleano. Las consultas ‘CONSTRUCCIÓN SPARQL’ producen un archivo RDF, que puede ser procesado por ROBOT o fusionado de nuevo en la ontología cargada. Los CONSTRUCTOS proporcionan una forma conveniente de realizar una expansión de estilo «macro». Las consultas ‘SPARQL UPDATE’ insertan y/o eliminan datos directamente en una ontología (como modelo RDF). ROBOT convierte el modelo RDF actualizado en un objeto de ontología de la API de OWL para guardarlo en cualquiera de las sintaxis compatibles.

El comando ‘ query ‘admite una opción para cargar ontologías importadas como gráficos con nombre con la opción’ use use-graphs’. Si se establece en ‘true’, las importaciones se pueden consultar como gráficos con nombre (el nombre es el IRI de esa ontología) y el gráfico predeterminado es una unión de todos los gráficos. Usar el gráfico predeterminado es similar a realizar una ‘ fusión ‘de todas las importaciones antes de realizar la consulta, pero la distinción entre importaciones se perdería en una’fusión’.

Verify

El comando ‘verify’ es una variación de la ejecución’ SPARQL SELECT’. Las consultas se utilizan para garantizar que una ontología se ajuste a un conjunto predeterminado de condiciones; por ejemplo, para garantizar que ninguna clase tenga múltiples definiciones textuales. Dada una consulta SELECT, ‘verify’ tendrá éxito (es decir, salir con el código de estado 0) si no se devuelven resultados. Fallará (i. e., salir con un código de estado distinto de cero) si se devuelve algún resultado de la consulta. Por lo tanto, dada una consulta SPARQL que selecciona datos no válidos, el comando ‘verify’ verificará que la ontología (u otro recurso) no contenga dichos datos no válidos.

Report

El comando ‘report’ es una extensión de ‘query’ y ‘verify’ que proporciona una serie de comprobaciones de control de calidad configurables (QC) para una ontología y devuelve una hoja de cálculo o una salida YAML de las violaciones. La hoja de cálculo se genera en formato separado por comas o tabulaciones y es fácil de leer para el usuario, mientras que la salida YAML puede ser fácilmente analizada por otros programas.

Las comprobaciones de control de calidad incluyen comprobaciones de anotaciones, comprobaciones lógicas y comprobaciones de metadatos. Las anotaciones son importantes para facilitar la comprensión humana, por lo que el comando ‘report’ encuentra casos en los que las anotaciones faltantes o duplicadas podrían causar problemas. Las comprobaciones lógicas analizan la coherencia estructural y la consistencia de la ontología. Finalmente, ‘report’ identifica los metadatos de ontología faltantes, como se especifica en las recomendaciones de fundición OBO.

Hay tres niveles de violaciones que se reportan: ERROR, WARN e INFORMACIÓN. Un ERROR es el más grave, como una etiqueta faltante o duplicada. De forma predeterminada, el comando ‘report’ falla si hay violaciones de nivel de ERROR, lo que detiene cualquier proceso de compilación automatizado. Estos tipos de violaciones deben corregirse antes de publicar una ontología. Las infracciones de nivel WARN deben corregirse lo antes posible, por ejemplo, las equivalencias de clase uno a uno inferidas, que normalmente no se desean en los proyectos OBO. INFO es para correcciones recomendadas que ayudan a mantener la coherencia entre las ontologías de fundición OBO, como comenzar una definición con una letra mayúscula y terminar con un punto. el ‘informe’ se puede configurar con una opción de línea de comandos para que falle en un nivel de violación diferente o para que nunca falle, independientemente de cualquier violación. Documentamos cada verificación de control de calidad con una sugerencia para una solución manual que el usuario puede aplicar.

El ROBOT proporciona un «perfil» predeterminado con niveles de informe para cada comprobación de control de calidad, pero los usuarios también pueden crear sus propios perfiles. En estos perfiles, pueden cambiar los niveles de violación de comprobaciones individuales, optar por excluir determinadas comprobaciones y agregar sus propias comprobaciones como consultas SPARQL. Por ejemplo, algunas ontologías pueden categorizar una clase que carece de una definición textual como un error, mientras que otras pueden categorizar esto como una advertencia. Uno de nuestros objetivos es converger en un perfil estándar que sea de máxima utilidad para el conjunto de todas las ontologías de la biblioteca OBO, fomentando la adopción de controles de calidad comunes.

Repair

Aunque la mayoría de los problemas planteados por ‘validar’ y ‘informar’ deben solucionarse manualmente, ROBOT también proporciona un comando ‘reparar’ que puede solucionar automáticamente ciertos problemas. La implementación actual fusionará anotaciones en axiomas duplicados y actualizará las referencias a clases obsoletas cuando se anoten con un reemplazo sugerido. Tenemos la intención de extender la ‘reparación’ a una gama más amplia de problemas comunes para los que la solución correcta es clara.

Desarrollo de ontologías con plantillas

ROBOT proporciona un sistema de generación de términos de ontología basado en plantillas. Los usuarios también tienen la opción de conectar su propio sistema de generación de términos a su flujo de trabajo, como los Patrones de diseño de búhos simples Muertos (DOS-DPs) .

Se almacena una gran cantidad de datos en hojas de cálculo y bases de datos, y los formatos tabulares son adecuados para muchos tipos de datos. El comando «plantilla» del ROBOT permite a los usuarios convertir datos tabulares en formato RDF/OWL. Una plantilla de ROBOT es simplemente un archivo de valores separados por tabulaciones (TSV) o valores separados por comas (CSV) con algunas convenciones especiales, que se describen en la documentación de la «plantilla» de ROBOT .

Estas plantillas se pueden utilizar para el desarrollo de ontologías modulares. Las hojas de cálculo de la plantilla pueden mantenerse como parte del repositorio de código fuente de la ontología, y en lugar de editar directamente el archivo de la ontología, los desarrolladores editan filas en la hoja de cálculo que corresponden a los términos de la ontología. El comando ‘template’ se usa para generar un módulo de la ontología, que se incluye como una instrucción de importación en la versión de editores de la ontología y se fusiona durante el proceso de liberación.

Flujos de trabajo

Un flujo de trabajo consiste en un conjunto de tareas coordinadas por algún sistema de flujo de trabajo. Los flujos de trabajo de ontología consisten en tareas como ejecutar comprobaciones de control de calidad, crear módulos de importación, razonar sobre ontologías y generar varios productos de lanzamiento de ontologías.

El ROBOT en sí no es un gestor de flujos de trabajo, aunque permite encadenar varios comandos en un solo comando largo. Al encadenar comandos de ROBOT, la ontología de salida de un comando se pasa directamente como entrada al siguiente comando. Por ejemplo, el encadenamiento se puede usar para reemplazar dos comandos que fusionan ontologías y luego razonan sobre el producto combinado:

`robot merge input input ont-1.búho input entrada ont-2.búho output salida fusionada.buho.

razón del robot merged entrada fusionada.búho reasoned producción razonada.buho`.

En lugar de crear el producto combinado y ejecutar ‘reason’ sobre él, se puede hacer en un solo comando:

`robot merge input input ont-1.búho input entrada ont-2.razón de búho output producción razonada.buho`.

La ventaja clave del encadenamiento es que las ontologías no tienen que ser serializadas y analizadas entre cada paso; el mismo objeto de ontología de la API de OWL se mantiene en memoria y se pasa a través de la cadena de comandos del ROBOT. Para ontologías grandes, el encadenamiento puede mejorar enormemente el rendimiento del ROBOT.

Debido a que los comandos de ROBOT se pueden ejecutar en la línea de comandos, se pueden usar varios sistemas de flujo de trabajo diferentes. Destacamos el uso de GNU Make, que se usa típicamente para compilar software. Un Makefile consiste en un conjunto de reglas utilizadas para crear «destinos». En el desarrollo de ontologías, el Makefile se usa para tareas automatizadas, como preparar una ontología para su lanzamiento. En este caso, los destinos suelen ser archivos de ontología. Las «recetas» para las reglas son comandos de sistema de estilo Unix, llevados a cabo por el comando ‘make’.

Los comandos de ROBOT se pueden usar como las » recetas «para hacer los»objetivos». Un flujo de trabajo típico no utilizará los 19 comandos del ROBOT. Por ejemplo, no todos los proyectos de ontología pueden usar plantillas de ROBOT y, por lo tanto, no todos los flujos de trabajo de lanzamiento necesitan incluir el comando ‘template’. Los desarrolladores de ontologías pueden decidir qué comandos son necesarios para realizar la versión y crear un flujo de trabajo en torno a esos comandos. La Figura 1 muestra una forma estándar en la que se combina una selección de comandos de ROBOT para un flujo de trabajo de lanzamiento.

El flujo de trabajo de lanzamiento del ROBOT. Un flujo de trabajo de lanzamiento típico con ROBOT. El archivo de edición de ontología ONT-edit.el búho se verifica primero como un control de calidad con el ROBOT «verify». Luego, los archivos de texto que contienen listas de términos de ontología externa en el directorio imports se utilizan para regenerar módulos de importación utilizando ‘extract’, asegurando que las importaciones estén actualizadas. ONT-edit.a continuación, owl pasa a través de una serie de comandos de ROBOT (‘razon’, ‘relax’, ‘reduce’ y ‘annotate’) para generar la liberación, ONT.buho. Finalmente, ONT.owl se convierte al formato OBO

Primero, las comprobaciones de control de calidad se ejecutan en la versión de los editores de la ontología con’ report ‘o’ verify’. Buscan clases equivalentes, espacios en blanco al final de las anotaciones, autorreferencias, sintaxis de referencia cruzada incorrecta y etiquetas faltantes. Los resultados se guardan en un directorio ‘reports/’ especificado. Si hay infracciones de nivel de ERROR, la tarea fallará y escribirá las infracciones en una tabla para que puedan identificarse fácilmente. Este paso permite a los desarrolladores ver rápidamente si los nuevos cambios han introducido algún problema dentro de la ontología y corregirlos antes de publicarlos.

Suponiendo que el paso inicial de verificación de control de calidad se haya completado correctamente, el siguiente paso es crear los módulos de importación. El ROBOT ‘ extract ‘se ejecuta para cada entrada de una lista de importaciones, que tienen los archivos de términos correspondientes (para el conjunto de semillas) en el directorio’ imports/’. Esto crea todos los módulos de importación en el mismo directorio ‘ imports/’. Esto garantiza que cuando una ontología se publica con términos externos, todos los términos externos estén actualizados con las versiones publicadas de las ontologías de origen. La publicación de términos externos desactualizados puede causar confusión, ya que el término mostrará tanto los detalles antiguos como los nuevos en los servicios de búsqueda de ontologías, como Ontobee y el Servicio de Búsqueda de Ontologías . Se pueden ejecutar comprobaciones de control de calidad adicionales en toda la ontología con importaciones utilizando el comando ‘verificar’ o ejecutando de nuevo ‘informar’.

Por último, se crean los productos de la versión principal: el archivo BÚHO y el archivo OBO. Para crear la versión de OWL, el archivo del editor se pasa a través de una serie de comandos de ROBOT encadenados:’ razonar’,’ relajar’,’ reducir ‘y’ anotar’. Esta serie de comandos ayuda a garantizar que la ontología publicada sea fácil de navegar y comprender, así como libre de axiomas redundantes. Si alguno de estos comandos falla, el proceso Make terminará con el mensaje de error correspondiente. Por ejemplo, si una ontología es incoherente, el paso «razón» fallará. Finalmente, el comando’ anotar ‘ agrega la versión IRI a los metadatos de la ontología. Este archivo OWL se convierte a formato OBO, momento en el que todos los destinos se copian en un directorio de lanzamiento con fecha.

El Kit de desarrollo de Ontologías

Crear un Makefile para coordinar todos estos pasos puede ser un reto. Hacemos esto más fácil para los desarrolladores de ontologías al proporcionar un Kit de Desarrollo de Ontología (ODK). Esto se puede usar para crear un repositorio de GitHub siguiendo un diseño estándar, con un Makefile estándar siguiendo el flujo de trabajo detallado anteriormente. El repositorio GitHub resultante también se configurará automáticamente para ejecutar los pasos de validación (como ‘informe’) del flujo de trabajo a través de Travis CI . El flujo de trabajo también se puede ejecutar utilizando Docker con contenedores ODK liberados en Dockerhub . Esto permite una ejecución sencilla de flujos de trabajo en el equipo local de un desarrollador de ontologías, con Travis CI o a través de herramientas de compilación escalables como Jenkins .

ODK se basa en el ROBOT y demuestra la utilidad del ROBOT, pero una discusión completa está más allá del alcance de este artículo.