Prezentare generală

ROBOT oferă o modalitate standardizată, dar configurabilă, de a sprijini ciclul de viață al dezvoltării ontologiei printr-o bibliotecă de funcționalități comune la nivel înalt și o interfață de linie de comandă. ROBOT se bazează pe OWL API și este compatibil cu toate sintaxele ontologie care OWL API acceptă: RDF/XML, OWL/XML, Turtle, OWL sintaxa funcțională, Owl Manchester sintaxa, și formatul OBO. Codul sursă este scris în Java și este disponibil din depozitul nostru GitHub sub o licență open source (BSD 3). De asemenea, este lansat ca o bibliotecă Java pe Maven Central. Codul robotului poate fi utilizat din orice limbaj de programare care rulează pe mașina virtuală Java (JVM). Instrumentul de linie de comandă este ambalat ca un fișier JAR care poate fi rulat pe Unix (inclusiv macOS și Linux), Windows și alte platforme acceptate de JVM. Acest fișier JAR este disponibil pentru descărcare de pe site-ul ROBOT GitHub , împreună cu scripturi specifice platformei pentru utilizarea ‘robot’ din linia de comandă. Instrucțiunile de instalare și documentația sunt disponibile de la http://robot.obolibrary.org.

arhitectura

am descris anterior arhitectura de bază a instrumentului , pe care o rezumăm aici.

codul sursă al robotului este format din două părți: ‘robot-core’ și ‘robot-command’. „robot-core” este o bibliotecă care susține sarcini comune de dezvoltare a ontologiei, pe care le numim „operațiuni”. „robot-command” oferă o interfață de linie de comandă împărțită în” comenzi”, fiecare dintre acestea înfășurând o operație „robot-core”.

cele mai multe operațiuni ROBOT pachet de funcționalitate la nivel scăzut furnizate de OWL API în funcționalitate la nivel înalt comune fluxurilor de lucru de dezvoltare ontologie în comunitatea OBO. Pentru cea mai bună compatibilitate, ne propunem să potrivim versiunea exactă a OWL API utilizată de ROBOT cu versiunea exactă utilizată de cea mai recentă versiune Prot. Unele operațiuni folosesc Apache Jena . Fiecare operație funcționează cu obiecte Java care reprezintă ontologii OWL, Owl reasoners, clase OWL, etc., în timp ce fiecare comandă funcționează cu șiruri și fișiere de opțiuni din linia de comandă. Comenzile efectuează, de asemenea, diverse etape de conversie și validare. Interfața liniei de comandă utilizează biblioteca Apache Commons CLI pentru parsarea comenzilor.

fiecare operație are un set de teste unitare construite cu JUnit care sunt executate de fiecare dată când produsul final (fișierul JAR) este generat. Fiecare comandă din ROBOT este documentată în propria sa pagină web (de ex. http://robot.obolibrary.org/reason). Paginile web sunt create în format Markdown și conțin exemple de linie de comandă încorporate care sunt analizate și executate ca parte a testelor noastre de integrare, cu rezultatele comparate cu un set de ieșiri „standard de aur”. Funcționalitatea ‘diff’ a robotului este utilizată la compararea fișierelor ontologice, altfel se folosește Compararea standard a fișierelor. Acest lucru ajută la asigurarea corectitudinii și coerenței documentației și a codului. Testele unitare și testele de integrare sunt executate la orice solicitare de tragere pe baza de cod prin integrarea continuă Travis (Travis CI) , astfel încât contribuțiile la baza de cod să fie verificate.

comenzi și operații

robotul oferă în prezent 15 operații (în biblioteca ‘robot-core’) și 19 comenzi (pentru interfața liniei de comandă). Unele comenzi sunt destul de specializate, iar majoritatea proiectelor de Ontologie nu le vor folosi pe toate. Aici oferim o prezentare generală a celor mai comune și generale comenzi. În fiecare caz, funcționalitatea de bază este susținută de operațiunile din biblioteca ‘robot-core’, care pot fi utilizate independent de interfața liniei de comandă din orice limbaj de programare care rulează pe JVM.

Convert

sunt acceptate o varietate de formate de Ontologie OWL, inclusiv RDF / XML, Turtle, Manchester, format OBO și multe altele. Pentru a permite interoperabilitatea suplimentară, ROBOT include o comandă ‘convert’ pentru a schimba între formatele ontologice acceptate. O listă completă a formatelor acceptate poate fi găsită în documentația ‘convert’.

raționamentul

raționamentul este una dintre cele mai importante operații în ROBOT. Comanda ‘reason’ acoperă două utilizări: validarea logică a unei ontologii și clasificarea automată. În ambele cazuri, utilizatorii își pot alege rezonatorul preferat, care este utilizat pentru a efectua inferența. Ontologii mari , cum ar fi ontologia genică, folosesc de obicei elani, care efectuează raționamentul rapid folosind profilul OWL EL. Ontologiile mai mici cu axiomatizare mai bogată, cum ar fi ontologia relațiilor, folosesc de obicei un raționator dl OWL complet, cum ar fi pustnic .

când comanda ‘reason’ este invocată într-o ontologie de intrare, robotul va iniția un reasoner folosind interfața Owl API Reasoner. Inferențele rezultate sunt verificate pentru a se asigura că ontologia este coerentă logic: ontologia trebuie să fie consecventă și să nu aibă clase nesatisfăcătoare (adică., clase care nu pot fi instanțiate fără a introduce o inconsecvență). Dacă ontologia este incoerentă, aceasta este raportată și execuția se oprește. Robotul poate efectua opțional verificări suplimentare, cum ar fi asigurarea faptului că nu se deduce două clase ca fiind post-raționament echivalent.

dacă ontologia este consecventă, robotul va efectua clasificarea automată. Toate axiomele deduse direct sunt adăugate ontologiei. Generarea altor tipuri de axiome poate fi configurată.afirmarea tuturor axiomelor deduse este adesea un pas fundamental în procesul de eliberare a ontologiilor biomedicale. Multe dintre aceste clase de Ontologie afirmă doar o singură superclasă numită (‘a subClassOf B’, unde B este o altă clasă din Ontologie) și zero sau mai multe superclase anonime și/sau clase echivalente anonime (‘a subclassof/equivalentTo (r some B)’, unde R este o proprietate obiect). Aceste clase anonime permit raționatorului să facă inferențe, care sunt apoi afirmate. Prin urmare, în versiunea de lansare a unei ontologii, o clasă poate avea mai multe superclase numite.

comanda „reason” are comenzi suplimentare „helper”. Comanda relax afirmă subclasa axiomelor conform unei reguli structurale simple: o expresie ‘a echivalentto (r some B) și …’ implică ‘o subclasă a R some B’. Acest lucru poate fi util, deoarece consumatorii de bio-ontologii se așteaptă adesea să navigheze în aceste expresii, de exemplu, partonomie în GO și Uberon. Comanda ‘relax’ scutește dezvoltatorul ontologiei de necesitatea de a le afirma pe lângă axiomele de echivalență și, ca atare, este adesea inclusă și în fluxurile de lucru de eliberare. În cele din urmă, comanda ‘reduce’ elimină subclasa redundantă a axiomelor și poate fi utilizată după ‘relax’ pentru a elimina axiomele duplicate care au fost afirmate în acel pas.

comanda ‘materialize’ folosește o expresie Materializing Reasoner (EMR) pentru a afirma expresii deduse ale formei ‘a subclasă de R unele B’ . În cazul în care comanda’ reason ‘afirmă superclase numite deduse,’ materialize ‘ afirmă superclase anonime. Aceasta nu face parte din ciclul de eliberare standard, dar poate fi benefică pentru crearea de subseturi ontologice complete.

lucrul cu ontologii externe

Turnătoria OBO își propune să coordoneze ontologiile într-un mod modular, astfel încât părți ale unor ontologii să poată fi folosite ca blocuri de construcție pentru alte ontologii. De exemplu, ontologia entităților chimice ChEBI este utilizată pentru a construi definiții de bufniță pentru procesele și activitățile metabolice din ontologia genelor . Există o varietate de strategii diferite pentru valorificarea ontologiilor externe și gestionarea dependențelor între ontologii, în funcție de cazul de utilizare.

Extract

comanda „extract”creează un modul bazat pe un set de entități de extras („sămânța”). Există patru metode diferite de extracție (așa cum se specifică în opțiunea ‘–method’): MIREOT, TOP, BOT și STAR.

metoda de extracție MIREOT a robotului se bazează pe principiul cu același nume și necesită specificarea uneia sau mai multor entități „de jos”. Opțional, pot fi specificate și una sau mai multe entități” de top”. Comanda extrage toate entitățile de nivel ” de jos „și strămoșii lor până la nivelul” de sus ” din ontologia de intrare. Dacă nu sunt furnizate entități „de top”, strămoșii până la entitatea de nivel superior („owl: Thing”) sunt incluse.

metodele TOP, BOT și STAR utilizează implementarea OWL API syntactic Locality module Extraction (SLME), care este garantată pentru a capta toate informațiile relevante logic pentru setul de semințe . Metoda BOT („partea de jos”) include toate relațiile dintre entitățile de intrare și strămoșii lor. Metoda TOP include toate relațiile dintre entitățile de intrare și descendenții acestora. În cele din urmă, metoda stea include numai toate relațiile dintre entitățile de intrare. Metoda stea produce cele mai mici ieșiri, în timp ce metoda de sus produce de obicei cele mai mari ieșiri.

pentru a susține proveniența termenului ontologic, comanda ‘extras’ are o opțiune ‘–annotate-with-source true’ care va adnota fiecare termen extras cu URL-ul ontologiei sursă din care este extras.

Eliminare și filtrare

comenzile ‘eliminare’ și ‘filtrare’ sunt utilizate pentru operații cu granulație fină pe axiome bufniță. ‘remove’ permite utilizatorilor să aleagă ce seturi de axiome doresc să elimine dintr-o ontologie țintă. ‘filter’ face opusul, astfel încât numai axiomele selectate sunt copiate de la intrare într-o nouă ontologie de ieșire.

aceste două comenzi funcționează începând cu un set de semințe de entități, apoi aplicând diferiți selectori pentru a găsi entități conexe și, în final, selectând ce tipuri de axiome să eliminați sau să filtrați. Ne așteptăm ca doar un număr mic de „utilizatori de putere” să utilizeze direct această caracteristică, dar aceste comenzi vor oferi în cele din urmă o bază pentru alte comenzi de nivel superior.

aceste comenzi pot fi folosite pentru a genera subseturi de Ontologie bazate pe adnotări prin filtrarea sau eliminarea entităților cu adnotarea specificată. Ontologiile Obo Foundry adnotează adesea clase cu proprietatea ‘in subset’ pentru a specifica unde ar putea fi utilizată o clasă. Selectorul de adnotări permite unui utilizator să furnizeze o valoare completă de adnotare sau un model care să se potrivească folosind expresia regulată.

Merge

comanda ‘merge’ combină două sau mai multe ontologii de intrare separate într-o singură ontologie. De asemenea, oferă posibilitatea de a îmbina toate ontologiile importate ale unei singure ontologii de intrare într-o singură ontologie principală, care este adesea folosită la crearea unei versiuni.

fuzionarea ontologiilor importate (specificate de declarațiile de import) în ontologia de intrare se realizează automat, astfel încât utilizatorul nu trebuie să listeze fiecare ontologie importată ca intrare. Oferim opțiunea (‘–collapse-import-closure false’) pentru a dezactiva această caracteristică, susținând cazurile în care utilizatorii pot îmbina mai multe ontologii de intrare care au declarații de import, dar doresc să-și păstreze importurile separate.

interogarea și raportarea

fluxurile de lucru ontologice includ de obicei operații de interogare peste ontologie, producând rapoarte care pot fi informative atât pentru editori, cât și pentru utilizatorii ontologiei-de exemplu, un tabel cu toate clasele plus definițiile lor textuale. Operațiunile de interogare pot fi, de asemenea, utilizate pentru verificări de validare. Limbajul de interogare SPARQL oferă o modalitate universală și declarativă pentru întreținătorii ontologiei de a crea rapoarte ontologice și verificări de validare . ROBOT oferă o modalitate convenabilă de a efectua interogări cu comanda ‘query’ sau verificări de validare folosind ‘verify’. În plus, comanda’ raport ‘ include un pachet configurabil de interogări standard pentru proiectele OBO care pot fi utilizate în orice flux de lucru ontologic, fără a necesita ca responsabilul să fie familiarizat cu SPARQL.

interogare

comanda ‘interogare’ a robotului rulează interogări SPARQL pe ontologii sau alte resurse RDF. Acest lucru poate fi utilizat de un întreținător de Ontologie fie pentru a efectua interogări interactive, fie mai tipic pentru a include interogări standard într-un flux de lucru ontologic. Comanda ‘query’ împachetează una dintre puținele operații care utilizează Apache Jena , mai degrabă decât OWL API. API-ul Jena permite robotului să încarce o ontologie ca o colecție de Triple conținute de un obiect Model RDF. Acesta oferă un motor de interogare SPARQL pentru acele modele, pe care le folosim pentru a rula toate interogările.

interogările’SPARQL SELECT’ produc un tabel de rezultate separat prin virgulă sau filă. Cere interogări produce un fișier cu o valoare booleană. Interogările SPARQL CONSTRUCT produc un fișier RDF, care poate fi procesat ulterior de ROBOT sau fuzionat înapoi în ontologia încărcată. ‘CONSTRUCT’ s oferă o modalitate convenabilă de a efectua expansiunea stilului „macro”. Interogările ‘SPARQL UPDATE’ introduc și / sau elimină date direct într-o ontologie (ca Model RDF). ROBOT convertește modelul RDF actualizat înapoi la un obiect ontologie OWL API pentru a fi salvat în oricare dintre sintaxele acceptate.

comanda ‘query’ acceptă o opțiune de încărcare a ontologiilor importate ca grafice numite cu opțiunea ‘–use-graphs’. Dacă aceasta este setată la ‘true’, importurile pot fi interogate ca grafice numite (numele fiind IRI-ul ontologiei), iar graficul implicit este o uniune a tuturor grafurilor. Utilizarea graficului implicit este similară cu efectuarea unei ‘ fuziuni ‘a tuturor importurilor înainte de interogare, dar distincția dintre importuri s-ar pierde într-o’îmbinare’.

Verify

comanda ‘verify’ este o variație a execuției ‘SPARQL SELECT’. Interogările sunt utilizate pentru a se asigura că o ontologie se conformează unui set predeterminat de condiții; de exemplu, asigurându-se că nicio clasă nu are mai multe definiții textuale. Având în vedere o interogare SELECT, ‘verify’ va reuși (exit with status code 0) dacă nu se returnează niciun rezultat. Va eșua (adică., ieșiți cu un cod de stare diferit de zero) dacă rezultatele sunt returnate din interogare. Deci, având în vedere o interogare SPARQL care selectează Date nevalide, comanda ‘verify’ va verifica dacă ontologia (sau altă resursă) nu conține astfel de date nevalide.

Report

comanda ‘report’ este o extensie a ‘query’ și ‘verify’ care oferă o serie de controale configurabile de control al calității (QC) pentru o ontologie și returnează o foaie de calcul sau o ieșire YAML a încălcărilor. Foaia de calcul este afișată fie în format separat prin virgulă, fie în filă și ușor de citit pentru un utilizator, în timp ce ieșirea YAML poate fi ușor analizată de alte programe.

verificările QC includ verificări de adnotare, verificări logice și verificări de metadate. Adnotările sunt importante pentru a facilita înțelegerea umană, astfel încât comanda ‘raport’ găsește cazuri în care adnotările lipsă sau duplicate ar putea cauza probleme. Verificările logice analizează coerența structurală și coerența ontologiei. În cele din urmă, ‘raport’ identifică metadatele ontologice lipsă, așa cum se specifică în recomandările OBO Foundry.

există trei niveluri de încălcări care sunt raportate: eroare, avertizare și informații. O eroare este cea mai severă, cum ar fi o etichetă lipsă sau duplicat. În mod implicit, comanda ‘raport’ eșuează dacă există încălcări la nivel de eroare, oprind orice procese automate de construire. Aceste tipuri de încălcări trebuie remediate înainte de publicarea unei ontologii. Încălcările la nivel de avertizare ar trebui remediate cât mai curând posibil, de exemplu, echivalențe de clasă unu la unu, care sunt de obicei neintenționate în proiectele OBO. INFO este pentru remedierile recomandate care ajută la menținerea coerenței în ontologiile Obo Foundry, cum ar fi începutul unei definiții cu o literă mare și încheierea cu o perioadă. ‘raport’ poate fi configurat cu o opțiune de linie de comandă pentru a eșua la un alt nivel de încălcare sau pentru a nu eșua niciodată, indiferent de încălcări. Documentăm fiecare verificare QC cu o sugestie pentru o remediere manuală pe care utilizatorul o poate aplica.

un „profil” implicit cu niveluri de raport pentru fiecare verificare QC este furnizat de ROBOT, dar utilizatorii pot, de asemenea, să-și creeze propriile profiluri. În aceste profiluri, aceștia pot modifica nivelurile de încălcare a verificărilor individuale, pot alege să excludă anumite verificări și să adauge propriile verificări ca interogări SPARQL. De exemplu, unele ontologii pot clasifica o clasă lipsită de o definiție textuală ca o eroare, în timp ce altele pot clasifica acest lucru ca un avertisment. Unul dintre obiectivele noastre este de a converge pe un profil standard, care este maxim util pentru setul de toate ontologiile din biblioteca OBO, încurajând adoptarea de controale comune de control al calității.

Repair

deși majoritatea problemelor ridicate de ‘validate’ și ‘report’ trebuie rezolvate manual, ROBOT oferă și o comandă ‘repair’ care poate remedia automat anumite probleme. Implementarea curentă va îmbina adnotările pe axiome duplicate și va actualiza referințele la clasele depreciate atunci când sunt adnotate cu o înlocuire sugerată. Intenționăm să extindem ‘repararea’ la o gamă mai largă de probleme comune pentru care remedierea corectă este clară.

Templated ontology development

ROBOT oferă un sistem de generare a termenului ontologic bazat pe șabloane. Utilizatorii au, de asemenea, opțiunea de a conecta propriul sistem de generare a termenului în fluxul lor de lucru, cum ar fi Dead Simple OWL Design Patterns (DOS-DPs) .

o cantitate imensă de date este stocată în foi de calcul și baze de date, iar formatele tabulare sunt potrivite pentru multe tipuri de date. Comanda ‘template’ a robotului permite utilizatorilor să convertească datele tabulare în format RDF/OWL. Un șablon ROBOT este pur și simplu un fișier de valori separate prin file (TSV) sau valori separate prin virgulă (CSV) cu câteva convenții speciale, care sunt prezentate în documentația șablonului robotului .

aceste șabloane pot fi utilizate pentru dezvoltarea ontologiei modulare. Foile de calcul șablon pot fi menținute ca parte a depozitului de cod sursă al ontologiei și, în loc să editeze direct fișierul ontologic, dezvoltatorii editează rânduri în foaia de calcul care corespund termenilor din ontologie. Comanda ‘template’ este apoi utilizată pentru a genera un modul al ontologiei, care este inclus ca o declarație de import în versiunea editorilor a ontologiei și fuzionat în timpul procesului de lansare.

fluxuri de lucru

un flux de lucru constă dintr-un set de sarcini coordonate de un sistem de flux de lucru. Fluxurile de lucru ontologice constau în sarcini precum executarea verificărilor QC, construirea modulelor de import, raționamentul asupra ontologiilor și generarea diferitelor produse de eliberare a ontologiei.

robotul în sine nu este un manager de flux de lucru, deși permite mai multe comenzi să fie înlănțuite împreună într-o singură comandă lungă. La înlănțuirea comenzilor robotului, ontologia de ieșire dintr-o comandă este transmisă direct ca intrare la următoarea comandă. De exemplu, înlănțuirea poate fi utilizată pentru a înlocui două comenzi care îmbină ontologii și apoi raționează peste produsul îmbinat:

`robot merge –input ont-1.bufniță … intrare ont-2.owl — ieșire fuzionat.bufniță.

robot motiv-intrare fuzionat.owl-ieșire motivat.bufniță.

în loc să creeze produsul îmbinat și să ruleze ‘reason’ peste asta, se poate face într-o singură comandă:

`robot merge –input ont-1.bufniță … intrare ont-2.owl motiv – ieșire motivat.bufniță.

avantajul cheie al înlănțuirii este că ontologiile nu trebuie serializate și analizate între fiecare pas; același obiect ontologie API OWL este menținut în memorie și trecut prin lanțul de comenzi ROBOT. Pentru ontologii mari, înlănțuirea poate îmbunătăți considerabil performanța robotului.

deoarece Comenzile robotului pot fi executate pe linia de comandă, pot fi utilizate un număr de sisteme de flux de lucru diferite. Subliniem utilizarea GNU face, care este de obicei folosit pentru a compila software-ul. Un Makefile constă dintr-un set de reguli utilizate pentru a face „ținte”. În dezvoltarea ontologiei, fișierul Makefile este utilizat pentru sarcini automate, cum ar fi pregătirea unei ontologii pentru eliberare. În acest caz, țintele sunt de obicei fișiere ontologice. „Rețetele” pentru reguli sunt comenzi de sistem în stil Unix, efectuate de comanda „make”.

Comenzile robotului pot fi folosite ca „rețete” pentru a face „ținte”. Un flux de lucru tipic nu va folosi toate cele 19 comenzi ale robotului. De exemplu, nu toate proiectele de Ontologie pot utiliza șabloane ROBOT și, prin urmare, nu toate fluxurile de lucru de lansare trebuie să includă comanda ‘șablon’. Dezvoltatorii de Ontologie pot decide ce comenzi sunt necesare pentru a efectua lansarea și pentru a construi un flux de lucru în jurul acestor comenzi. Figura 1 prezintă un mod standard în care o selecție de comenzi ROBOT este combinat pentru un flux de lucru de eliberare.

fluxul de lucru de eliberare a robotului. Un flux de lucru tipic de eliberare folosind robotul. Fișierul de editare ontologie ONT-edit.owl este verificat mai întâi ca o verificare a controlului calității cu robotul ‘verificați’. Apoi, fișierele text care conțin liste de termeni ontologici externi în directorul de importuri sunt utilizate pentru a regenera modulele de import folosind ‘extract’, asigurându-se că importurile sunt actualizate. ONT-editare.owl este apoi trecut printr-o serie de comenzi ROBOT (‘reason’, ‘relax’, ‘reduce’ și ‘adnota’) pentru a genera eliberarea, ONT.bufniță. În sfârșit, ONT.owl este convertit în format OBO

în primul rând, controalele de control al calității sunt rulate peste versiunea editorilor a ontologiei cu „raport” sau „verificați”. Acestea caută clase echivalente, spații albe în adnotări, auto-referințe, sintaxă incorectă de referință încrucișată și etichete lipsă. Rezultatele sunt salvate într-un director ‘rapoarte/’ specificat. Dacă există încălcări la nivel de eroare, sarcina va eșua și va scrie încălcările într-un tabel, astfel încât acestea să poată fi identificate cu ușurință. Acest pas permite dezvoltatorilor să vadă rapid dacă noile modificări au introdus probleme în ontologie și să le remedieze înainte de eliberare.

presupunând că etapa inițială de verificare QC s-a încheiat cu succes, următorul pas este crearea modulelor de import. Robotul ‘ extract ‘este rulat pentru fiecare intrare dintr-o listă de importuri, care au fișiere de termeni corespunzătoare (pentru setul de semințe) în directorul’ imports/’. Aceasta creează toate modulele de import în același director ‘ imports/’. Acest lucru asigură că atunci când o ontologie este eliberată cu termeni externi, toți termenii externi sunt actualizați cu versiunile lansate ale ontologiilor sursă. Eliberarea Termenilor externi expirați poate provoca confuzie, deoarece termenul va afișa atât detaliile vechi, cât și cele noi în serviciile de căutare ontologică, cum ar fi Ontobee și serviciul de căutare ontologică . Verificările suplimentare QC pot fi rulate peste ontologia completă cu importuri folosind comanda ‘ verify ‘sau rulând din nou’ report’.

în cele din urmă, principalele produse de lansare sunt create: dosarul bufniței și dosarul OBO. Pentru a crea versiunea OWL, fișierul Editorilor este trecut printr-o serie de comenzi ROBOT înlănțuite: ‘reason’, ‘relax’, ‘reduce’ și ‘adnota’. Această serie de comenzi ajută la asigurarea faptului că ontologia lansată este atât ușor de navigat și înțeles, cât și liberă de orice axiome redundante. Dacă oricare dintre aceste comenzi eșuează, procesul Make se va încheia cu mesajul de eroare corespunzător. De exemplu, dacă o ontologie este incoerentă, pasul rațiunii va eșua. În cele din urmă, comanda ‘adnotare’ adaugă versiunea IRI la metadatele ontologiei. Acest fișier OWL este apoi convertit în format OBO, moment în care toate țintele sunt copiate într-un director de lansare datat.

kitul de dezvoltare ontologică

crearea unui fișier Makefile pentru a coordona toți acești pași poate fi o provocare. Facem acest lucru mai ușor pentru dezvoltatorii de Ontologie oferind un kit de dezvoltare ontologică (ODK) . Aceasta poate fi utilizată pentru a crea un depozit GitHub urmând un aspect standard, cu un Makefile standard urmând fluxul de lucru detaliat mai sus. Depozitul GitHub rezultat va fi, de asemenea, configurat automat pentru a rula pașii de validare (cum ar fi ‘raport’) a fluxului de lucru prin Travis CI . Fluxul de lucru poate fi executat și folosind Docker cu containere ODK lansate pe Dockerhub . Acest lucru permite executarea ușoară a fluxurilor de lucru fie pe computerul local al unui dezvoltator de Ontologie, cu Travis CI, fie prin instrumente scalabile, cum ar fi Jenkins .

ODK se bazează pe ROBOT și demonstrează utilitatea robotului, dar o discuție completă depășește domeniul de aplicare al acestui articol.