Panoramica

ROBOT fornisce un modo standardizzato ma configurabile per supportare il ciclo di vita dello sviluppo ontologico tramite una libreria di funzionalità comuni di alto livello e un’interfaccia a riga di comando. ROBOT si basa su OWL API ed è compatibile con tutte le sintassi ontologiche supportate da OWL API: RDF / XML, OWL/XML, Turtle, OWL Functional Syntax, OWL Manchester Syntax e OBO format. Il codice sorgente è scritto in Java ed è disponibile dal nostro repository GitHub sotto una licenza open source (BSD 3). È anche rilasciato come libreria Java su Maven Central. Codice ROBOT può essere utilizzato da qualsiasi linguaggio di programmazione che gira sulla Java Virtual Machine (JVM). Lo strumento da riga di comando è confezionato come un file JAR che può essere eseguito su Unix (inclusi macOS e Linux), Windows e altre piattaforme supportate dalla JVM. Questo file JAR è disponibile per il download dal sito ROBOT GitHub, insieme a script specifici della piattaforma per l’utilizzo di ‘robot’ dalla riga di comando. Le istruzioni per l’installazione e la documentazione sono disponibili presso http://robot.obolibrary.org.

Architettura

Abbiamo precedentemente descritto l’architettura di base dello strumento , che riassumiamo qui.

Il codice sorgente del ROBOT è costituito da due parti: ‘robot-core’ e ‘robot-command’. ‘robot-core’ è una libreria che supporta attività comuni di sviluppo dell’ontologia, che chiamiamo “operazioni”. ‘robot-command’ fornisce un’interfaccia a riga di comando divisa in” comandi”, ognuno dei quali avvolge un’operazione “robot-core”.

La maggior parte delle operazioni ROBOT pacchetto funzionalità di basso livello fornito da OWL API in funzionalità di alto livello comune ai flussi di lavoro di sviluppo ontologia nella comunità OBO. Per la migliore compatibilità, miriamo a abbinare la versione esatta dell’API OWL utilizzata da ROBOT con la versione esatta utilizzata dall’ultima versione di Protégé. Alcune operazioni usano Apache Jena . Ogni operazione funziona con oggetti Java che rappresentano ontologie OWL, ragionatori OWL, classi OWL,ecc., mentre ogni comando lavora con stringhe di opzione di riga di comando e file. I comandi eseguono anche varie fasi di conversione e convalida. L’interfaccia della riga di comando utilizza la libreria CLI di Apache Commons per l’analisi dei comandi.

Ogni operazione ha una serie di test unitari creati con JUnit che vengono eseguiti ogni volta che viene generato il prodotto finale (il file JAR). Ogni comando in ROBOT è documentato nella propria pagina web (ad esempiohttp://robot.obolibrary.org/reason). Le pagine web sono create in formato Markdown e contengono esempi da riga di comando incorporati che vengono analizzati ed eseguiti come parte dei nostri test di integrazione, con i risultati confrontati con un set di output “gold standard”. La funzionalità “diff” del ROBOT viene utilizzata quando si confrontano i file di ontologia, altrimenti viene utilizzato il confronto dei file standard. Questo aiuta a garantire la correttezza e la coerenza della documentazione e del codice. I test unitari e i test di integrazione vengono eseguiti su qualsiasi richiesta pull sulla base di codice tramite Travis Continuous integration (Travis CI), in modo che i contributi alla base di codice vengano verificati.

Comandi e operazioni

ROBOT fornisce attualmente 15 operazioni (nella libreria’ robot-core’) e 19 comandi (per l’interfaccia a riga di comando). Alcuni comandi sono piuttosto specializzati e la maggior parte dei progetti di ontologia non li utilizzerà tutti. Qui forniamo una panoramica dei comandi più comuni e generali. In ogni caso, la funzionalità di base è supportata da operazioni nella libreria ‘robot-core’, che può essere utilizzata indipendentemente dall’interfaccia della riga di comando da qualsiasi linguaggio di programmazione eseguito sulla JVM.

Converti

Sono supportati una varietà di formati di ontologia OWL, tra cui RDF / XML, Turtle, Manchester, formato OBO e altro ancora. Per consentire un’ulteriore interoperabilità, ROBOT include un comando ‘convert’ per cambiare tra i formati di ontologia supportati. Un elenco completo dei formati supportati può essere trovato nella documentazione’ convert’.

Ragionamento

Ragionamento è una delle operazioni più importanti in ROBOT. Il comando ‘reason’ copre due usi: convalida logica di un’ontologia e classificazione automatica. In entrambi i casi, gli utenti possono scegliere il loro ragionatore preferito, che viene utilizzato per eseguire l’inferenza. Le grandi ontologie come l’ontologia del gene usano tipicamente l’ALCE, che esegue rapidamente il ragionamento usando il profilo OWL EL. Ontologie più piccole con un’assiomatizzazione più ricca, come l’Ontologia delle relazioni, in genere usano un ragionatore DL GUFO completo come eremita .

Quando il comando ‘reason’ viene invocato su un’ontologia di input, ROBOT avvierà un reasoner utilizzando l’interfaccia OWL API Reasoner. Le inferenze risultanti sono controllate per garantire che l’ontologia sia logicamente coerente: l’ontologia deve essere coerente e non avere classi insoddisfacenti (cioè, classi che non possono essere istanziate senza introdurre un’incoerenza. Se l’ontologia è incoerente, questo viene segnalato e l’esecuzione si arresta. ROBOT può opzionalmente eseguire controlli aggiuntivi, come ad esempio garantire che non ci sono due classi sono dedotti per essere equivalente post-ragionamento.

Se l’ontologia è coerente, ROBOT eseguirà classificazione automatica. Tutti gli assiomi “sottoclasse” dedotti direttamente vengono aggiunti all’ontologia. È possibile configurare la generazione di altri tipi di assiomi.

L’affermazione di tutti gli assiomi inferiti è spesso un passo fondamentale nel processo di rilascio per le ontologie biomediche. Molte di queste classi di ontologia affermano solo una singola superclasse denominata (‘A subClassOf B‘, dove B è un’altra classe nell’ontologia) e zero o più superclassi anonime e/o classi equivalenti anonime (’A subClassOf/equivalentTo (R some B)’, dove R è una proprietà dell’oggetto). Queste classi anonime consentono al ragionatore di fare inferenze, che vengono poi asserite. Pertanto, nella versione di rilascio di un’ontologia, una classe può avere più di una superclasse denominata.

Il comando ‘reason’ ha comandi “helper” aggiuntivi. Il comando’ relax ‘afferma una sottoclasse di assiomi implicata secondo una semplice regola strutturale: un’espressione’ A equivalentTo (R some B) e … ‘comporta’A sottoclasse di R some B’. Questo può essere utile in quanto i consumatori di bio-ontologie spesso si aspettano di navigare in queste espressioni, ad esempio, partonomy in GO e Uberon. Il comando’ relax ‘ allevia lo sviluppatore di ontologia dalla necessità di affermare questi oltre agli assiomi di equivalenza, e come tale è anche spesso incluso nei flussi di lavoro di rilascio. Infine, il comando “riduci” rimuove la sottoclasse ridondante degli assiomi e può essere utilizzato dopo “relax” per rimuovere gli assiomi duplicati che sono stati asseriti in quel passaggio.

Il comando ‘materializza’ utilizza un’espressione Materializzando Reasoner (EMR) per affermare espressioni dedotte della forma ‘Una sottoclasse di R alcuni B’ . Dove il comando “ragione” afferma le superclassi con nome dedotto, “materializza” afferma le superclassi anonime. Questo non fa parte del ciclo di rilascio standard, ma può essere utile per la creazione di sottoinsiemi di ontologia completi.

Lavorare con ontologie esterne

La Fonderia OBO mira a coordinare le ontologie in modo modulare, in modo tale che parti di alcune ontologie possano essere utilizzate come elementi costitutivi per altre ontologie. Ad esempio, l’ontologia delle entità chimiche di ChEBI viene utilizzata per costruire definizioni OWL per i processi metabolici e le attività nell’Ontologia genica . Esistono una varietà di strategie diverse per sfruttare le ontologie esterne e gestire le dipendenze tra ontologie, a seconda del caso d’uso.

Estrai

Il comando ‘estrai’ crea un modulo basato su un insieme di entità da estrarre (il “seme”). Esistono quattro diversi metodi di estrazione (come specificato dall’opzione’ method method’): MIREOT, TOP, BOT e STAR.

Il metodo di estrazione MIREOT del ROBOT si basa sul principio dello stesso nome e richiede che vengano specificate una o più entità “bottom”. Facoltativamente, è possibile specificare anche una o più entità “top”. Il comando estrae tutte le entità di livello ” inferiore “e i loro antenati fino al livello” superiore” dall’ontologia di input. Se non vengono fornite entità” top”, sono inclusi gli antenati fino all’entità di livello superiore (‘owl: Thing’).

I metodi TOP, BOT e STAR utilizzano l’implementazione SLME (Syntactic Locality Module Extraction) dell’API OWL, che è garantita per acquisire tutte le informazioni logicamente rilevanti per il set di semi . Il metodo BOT (”bottom”) include tutte le relazioni tra le entità di input e i loro antenati. Il metodo TOP include tutte le relazioni tra le entità di input e i loro discendenti. Infine, il metodo STAR include solo tutte le relazioni tra entità di input. Il metodo STAR produce le uscite più piccole, mentre il metodo TOP produce in genere le uscite più grandi.

Per supportare la provenienza dei termini di ontologia, il comando ‘extract’ ha un’opzione ‘annot annotate-with-source true’ che annoterà ogni termine estratto con l’URL dell’ontologia di origine da cui viene estratto.

Rimuovi e filtra

I comandi ‘rimuovi’ e ‘filtra’ sono usati per operazioni a grana fine sugli assiomi OWL. ‘rimuovi’ consente agli utenti di scegliere quali insiemi di assiomi desiderano rimuovere da un’ontologia di destinazione. ‘filter’ fa il contrario, in modo che solo gli assiomi selezionati vengano copiati dall’input in una nuova ontologia di output.

Questi due comandi funzionano iniziando con un set seme di entità, quindi applicando vari selettori per trovare entità correlate e infine selezionando quali tipi di assiomi rimuovere o filtrare. Ci aspettiamo che solo un piccolo numero di “utenti esperti” utilizzi direttamente questa funzione, ma questi comandi alla fine forniranno una base per altri comandi di livello superiore.

Questi comandi possono essere utilizzati per generare sottoinsiemi di ontologia basati su annotazioni filtrando o rimuovendo entità con l’annotazione specificata. Le ontologie OBO Foundry spesso annotano le classi con la proprietà ‘in subset’ per specificare dove può essere utilizzata una classe. Il selettore di annotazione consente all’utente di fornire un valore di annotazione completo o un modello da abbinare utilizzando l’espressione regolare.

Unisci

Il comando ‘unisci’ combina due o più ontologie di input separate in un’unica ontologia. Fornisce anche la possibilità di unire tutte le ontologie importate di una singola ontologia di input in un’ontologia principale, che viene spesso utilizzata quando si crea una versione.

La fusione delle ontologie importate (specificate dalle istruzioni import) nell’ontologia di input viene eseguita automaticamente, in modo che l’utente non debba elencare ogni ontologia importata come input. Offriamo l’opzione (‘collapse collapse-import-closure false’) per disattivare questa funzione, supportando i casi in cui gli utenti possono unire più ontologie di input che hanno istruzioni di importazione ma vogliono mantenere separate le loro importazioni.

Interrogazione e segnalazione

I flussi di lavoro di ontologia in genere includono operazioni di query sull’ontologia, producendo report che possono essere informativi sia per gli editor che per gli utenti dell’ontologia, ad esempio una tabella di tutte le classi più le loro definizioni testuali. Le operazioni di query possono essere utilizzate anche per i controlli di convalida. Il linguaggio di query SPARQL fornisce un modo universale e dichiarativo per i manutentori di ontologia per creare report di ontologia e controlli di convalida . ROBOT fornisce un modo conveniente per eseguire query con il comando ‘query’, o controlli di convalida utilizzando ‘verify’. Inoltre, il comando’ report ‘ include un pacchetto configurabile di query standard per progetti OBO che possono essere utilizzati in qualsiasi flusso di lavoro di ontologia, senza richiedere al manutentore di avere familiarità con SPARQL.

Query

Il comando ‘query’ del ROBOT esegue query SPARQL su ontologie o altre risorse RDF. Questo può essere utilizzato da un manutentore di ontologia per eseguire query interattive o, più in genere, per includere query standard in un flusso di lavoro di ontologia. Il comando’ query ‘ avvolge una delle poche operazioni che utilizza Apache Jena , piuttosto che l’API OWL. L’API Jena consente al ROBOT di caricare un’ontologia come una raccolta di triple contenute da un oggetto modello RDF. Fornisce un motore di query SPARQL per quei modelli, che usiamo per eseguire tutte le query.

Le query‘SPARQL SELECT’ producono una tabella di risultati separata da virgole o tabulazioni. Le query ASK producono un file con un valore booleano. Le query ‘SPARQL CONSTRUCT’ producono un file RDF, che può essere ulteriormente elaborato dal ROBOT o unito all’ontologia caricata. “I COSTRUTTI forniscono un modo conveniente per eseguire l’espansione in stile “macro”. Le query ‘SPARQL UPDATE’ inseriscono e / o rimuovono i dati direttamente in un’ontologia (come modello RDF). ROBOT converte il modello RDF aggiornato in un oggetto di ontologia API OWL da salvare in una qualsiasi delle sintassi supportate.

Il comando ‘query’ supporta un’opzione per caricare ontologie importate come grafi denominati con l’opzione ‘use use-graphs’. Se questo è impostato su ‘true’, le importazioni possono essere interrogate come grafici denominati (il nome è l’IRI di ontology) e il grafico predefinito è un’unione di tutti i grafici. L’utilizzo del grafico predefinito è simile alla conduzione di una “unione” di tutte le importazioni prima dell’interrogazione, ma la distinzione tra le importazioni verrebbe persa in una “unione”.

Verify

Il comando ‘verify’ è una variazione dell’esecuzione ‘SPARQL SELECT’. Le query vengono utilizzate per garantire che un’ontologia sia conforme a un insieme predeterminato di condizioni; ad esempio, assicurando che nessuna classe abbia più definizioni testuali. Data una query SELECT,’ verify ‘ avrà successo (cioè, esci con il codice di stato 0) se non vengono restituiti risultati. Fallirà (cioè, esci con un codice di stato diverso da zero) se tutti i risultati vengono restituiti dalla query. Quindi, data una query SPARQL che seleziona i dati non validi, il comando ‘verify’ verificherà che l’ontologia (o altra risorsa) non contenga tali dati non validi.

Report

Il comando ‘report’ è un’estensione di ‘query’ e ‘verify’ che fornisce una serie di controlli di qualità configurabili (QC) per un’ontologia e restituisce un foglio di calcolo o un output YAML delle violazioni. Il foglio di calcolo viene emesso in formato separato da virgole o tabulazioni e facile da leggere per un utente, mentre l’output YAML può essere facilmente analizzato da altri programmi.

I controlli QC includono controlli di annotazione, controlli logici e controlli di metadati. Le annotazioni sono importanti per facilitare la comprensione umana, quindi il comando’ report ‘ trova i casi in cui le annotazioni mancanti o duplicate potrebbero causare problemi. I controlli logici guardano alla coerenza strutturale e alla coerenza dell’ontologia. Infine, ‘report’ identifica i metadati di ontologia mancanti, come specificato dalle raccomandazioni di OBO Foundry.

Sono presenti tre livelli di violazioni segnalate: ERRORE, AVVISO e INFORMAZIONI. Un ERRORE è il più grave, ad esempio un’etichetta mancante o duplicata. Per impostazione predefinita, il comando’ report ‘ non riesce se ci sono violazioni a livello di errore, interrompendo qualsiasi processo di compilazione automatica. Questi tipi di violazioni devono essere corretti prima di pubblicare un’ontologia. Le violazioni a livello di AVVISO dovrebbero essere corrette il prima possibile, ad esempio le equivalenze di classe uno a uno dedotte, che in genere non sono volute nei progetti OBO. INFO è per correzioni consigliate che aiutano a mantenere la coerenza tra le ontologie OBO Foundry, ad esempio l’inizio di una definizione con una lettera maiuscola e termina con un punto. ‘report’ può essere configurato con un’opzione da riga di comando per fallire su un livello di violazione diverso o per non fallire mai, indipendentemente da eventuali violazioni. Documentiamo ogni controllo QC con un suggerimento per una correzione manuale che l’utente può applicare.

Un “profilo” predefinito con livelli di report per ogni controllo QC è fornito da ROBOT, ma gli utenti sono anche in grado di creare i propri profili. In questi profili, possono modificare i livelli di violazione dei singoli controlli, scegliere di escludere determinati controlli e aggiungere i propri controlli come query SPARQL. Ad esempio, alcune ontologie possono classificare una classe priva di una definizione testuale come un errore, mentre altre possono classificare questo come un avvertimento. Uno dei nostri obiettivi è quello di convergere su un profilo standard che sia al massimo utile per l’insieme di tutte le ontologie nella libreria OBO, incoraggiando l’adozione di controlli di qualità comuni.

Repair

Anche se la maggior parte dei problemi sollevati da ‘validate’ e ‘report’ devono essere risolti manualmente, ROBOT fornisce anche un comando ‘repair’ che può risolvere automaticamente alcuni problemi. L’implementazione corrente unirà annotazioni su assiomi duplicati e aggiornerà i riferimenti alle classi deprecate quando vengono annotate con una sostituzione suggerita. Intendiamo estendere la “riparazione” a una gamma più ampia di problemi comuni per i quali la correzione corretta è chiara.

Sviluppo di ontologia basata su modelli

ROBOT fornisce un sistema di generazione di termini di ontologia basato su modelli. Gli utenti hanno anche la possibilità di collegare il proprio sistema di generazione termine nel loro flusso di lavoro, come Dead Simple OWL Design Patterns (DOS-DPs) .

Un’enorme quantità di dati è memorizzata in fogli di calcolo e database e i formati tabulari sono adatti a molti tipi di dati. Il comando ‘template ‘ del ROBOT consente agli utenti di convertire i dati tabulari in formato RDF/OWL. Un modello di ROBOT è semplicemente un file di valori separati da tabulazioni (TSV) o valori separati da virgole (CSV) con alcune convenzioni speciali, che sono delineate nella documentazione del modello di ROBOT .

Questi modelli possono essere utilizzati per lo sviluppo di ontologia modulare. I fogli di calcolo del modello possono essere mantenuti come parte del repository del codice sorgente dell’ontologia e, invece di modificare direttamente il file dell’ontologia, gli sviluppatori modificano le righe nel foglio di calcolo che corrispondono ai termini dell’ontologia. Il comando ‘template’ viene quindi utilizzato per generare un modulo dell’ontologia, che viene incluso come istruzione import nella versione dell’ontologia degli editori e unito durante il processo di rilascio.

Flussi di lavoro

Un flusso di lavoro è costituito da un insieme di attività coordinate da un certo sistema di flusso di lavoro. I flussi di lavoro di ontologia consistono in attività come l’esecuzione di controlli QC, la creazione di moduli di importazione, il ragionamento su ontologie e la generazione di vari prodotti di rilascio di ontologia.

Il ROBOT stesso non è un gestore del flusso di lavoro, sebbene consenta di concatenare più comandi in un unico comando lungo. Quando si concatenano i comandi del ROBOT, l’ontologia di output da un comando viene passata direttamente come input al comando successivo. Ad esempio, il concatenamento può essere utilizzato per sostituire due comandi che uniscono ontologie e quindi ragionare sul prodotto unito:

`robot merge on input ont-1.owl input ingresso ont-2.owl output output unito.gufo.

ragione robot input input unito.gufo output uscita ragionata.gufo`.

Invece di creare il prodotto unito ed eseguire ‘reason’ su questo, può essere fatto in un unico comando:

`robot merge input input ont-1.owl input ingresso ont-2.owl reason output output ragionato.gufo`.

Il vantaggio chiave del concatenamento è che le ontologie non devono essere serializzate e analizzate tra ogni passaggio; lo stesso oggetto OWL API ontology viene mantenuto in memoria e passato attraverso la catena di comandi del ROBOT. Per le grandi ontologie, il concatenamento può migliorare notevolmente le prestazioni del ROBOT.

Poiché i comandi del ROBOT possono essere eseguiti sulla riga di comando, è possibile utilizzare diversi sistemi di flusso di lavoro. Evidenziamo l’uso di GNU Make, che viene tipicamente utilizzato per compilare software. Un Makefile è costituito da un insieme di regole utilizzate per creare “obiettivi”. Nello sviluppo di ontologia, il Makefile viene utilizzato per attività automatizzate, come la preparazione di un’ontologia per il rilascio. In questo caso, i target sono solitamente file di ontologia. Le “ricette” per le regole sono comandi di sistema in stile Unix, eseguiti dal comando ‘make’.

Comandi ROBOT possono essere utilizzati come ” ricette “per rendere i”bersagli”. Un flusso di lavoro tipico non utilizzerà tutti i 19 comandi del ROBOT. Ad esempio, non tutti i progetti di ontologia possono utilizzare modelli di ROBOT e quindi non tutti i flussi di lavoro di rilascio devono includere il comando ‘template’. Gli sviluppatori di ontologia possono decidere quali comandi sono necessari per eseguire il rilascio e creare un flusso di lavoro attorno a tali comandi. Figura 1 mostra un modo standard in cui una selezione di comandi ROBOT è combinato per un flusso di lavoro di rilascio.

Il flusso di lavoro di rilascio del ROBOT. Un tipico flusso di lavoro di rilascio utilizzando ROBOT. Il file di ontologia edit ONT-edit.owl viene prima verificato come controllo di qualità con ROBOT ‘verify’. Quindi, i file di testo contenenti elenchi di termini ontologici esterni nella directory imports vengono utilizzati per rigenerare i moduli di importazione utilizzando “extract”, assicurando che le importazioni siano aggiornate. ONT-modifica.owl viene quindi passato attraverso una serie di comandi ROBOT (’reason‘,’ relax‘,’ reduce ‘e’ annota’) per generare il rilascio, ONT.gufo. Infine, ONT.owl viene convertito in formato OBO

In primo luogo, i controlli di controllo qualità vengono eseguiti sulla versione dell’ontologia degli editori con’ report ‘o’ verify‘. Questi cercano classi equivalenti, spazi bianchi finali nelle annotazioni, riferimenti automatici, sintassi di riferimento incrociato errata e etichette mancanti. I risultati vengono salvati in una directory ‘reports / ‘ specificata. Se ci sono violazioni a livello di errore, l’attività fallirà e scriverà le violazioni in una tabella in modo che possano essere facilmente identificate. Questo passaggio consente agli sviluppatori di vedere rapidamente se le nuove modifiche hanno introdotto problemi all’interno dell’ontologia e risolverli prima di rilasciarli.

Supponendo che il passaggio iniziale di controllo QC sia stato completato correttamente, il passo successivo è creare i moduli di importazione. Il ROBOT ‘ extract ‘viene eseguito per ogni voce in un elenco di importazioni, che hanno file di termini corrispondenti (per il set di semi) nella directory’ imports/’. Questo crea tutti i moduli di importazione nella stessa directory ‘ imports/’. Ciò garantisce che quando un’ontologia viene rilasciata con termini esterni, tutti i termini esterni sono aggiornati con le versioni rilasciate delle ontologie di origine. Il rilascio di termini esterni obsoleti può causare confusione, poiché il termine mostrerà sia i vecchi che i nuovi dettagli nei servizi di ricerca ontologica come Ontobee e il servizio di ricerca ontologica . Ulteriori controlli QC possono essere eseguiti sull’ontologia completa con le importazioni utilizzando il comando ‘verify ‘o eseguendo nuovamente’ report’.

Infine, vengono creati i principali prodotti di rilascio: il file OWL e il file OBO. Per creare la versione OWL, il file degli editor viene passato attraverso una serie di comandi ROBOT concatenati:’ reason‘,’ relax‘,’ reduce ‘e’annota’. Questa serie di comandi aiuta a garantire che l’ontologia rilasciata sia facile da sfogliare e comprendere, oltre che priva di assiomi ridondanti. Se uno di questi comandi non riesce, il processo Make terminerà con il messaggio di errore corrispondente. Ad esempio, se un’ontologia è incoerente, il passaggio “motivo” fallirà. Infine, il comando’ annota ‘ aggiunge la versione IRI ai metadati dell’ontologia. Questo file OWL viene quindi convertito in formato OBO, a quel punto tutte le destinazioni vengono copiate in una directory di rilascio datata.

Il kit di sviluppo Ontologia

Creare un Makefile per coordinare tutti questi passaggi può essere difficile. Rendiamo questo più facile per gli sviluppatori di ontologia fornendo un Ontology Development Kit (ODK). Questo può essere usato per creare un repository GitHub seguendo un layout standard, con un Makefile standard che segue il flusso di lavoro descritto sopra. Il repository GitHub risultante verrà anche configurato automaticamente per eseguire i passaggi di convalida (come “report”) del flusso di lavoro tramite Travis CI . Il flusso di lavoro può anche essere eseguito utilizzando Docker con contenitori ODK rilasciati su Dockerhub . Ciò consente una facile esecuzione dei flussi di lavoro sul computer locale di uno sviluppatore di ontologia, con Travis CI o tramite strumenti di compilazione scalabili come Jenkins .

ODK si basa su ROBOT e dimostra l’utilità del ROBOT, ma una discussione completa va oltre lo scopo di questo articolo.