przegląd

ROBOT zapewnia znormalizowany, ale konfigurowalny sposób wspierania cyklu rozwoju ontologii poprzez bibliotekę popularnych funkcjonalności wysokiego poziomu i interfejs wiersza poleceń. ROBOT bazuje na OWL API i jest kompatybilny ze wszystkimi składniami ontologicznymi, które OWL API obsługuje: RDF/XML, OWL / XML, Turtle, OWL Functional Syntax, OWL Manchester Syntax i obo format. Kod źródłowy jest napisany w Javie i jest dostępny z naszego repozytorium GitHub na licencji open source (BSD 3). Jest również wydany jako biblioteka Java na Maven Central. Kod robota może być używany z dowolnego języka programowania działającego na maszynie wirtualnej Java (JVM). Narzędzie wiersza poleceń jest pakowane jako plik JAR, który można uruchomić na systemach Unix (w tym macOS i Linux), Windows i innych platformach obsługiwanych przez JVM. Ten plik JAR jest dostępny do pobrania ze strony ROBOT GitHub, wraz ze skryptami specyficznymi dla platformy do używania „robota” z wiersza poleceń. Instrukcje instalacji i dokumentacja są dostępne na stronie http://robot.obolibrary.org.

Architektura

wcześniej opisaliśmy podstawową architekturę narzędzia , którą podsumowujemy tutaj.

kod źródłowy robota składa się z dwóch części: „robot-core” i „robot-command”. 'robot-core’ jest biblioteką wspierającą wspólne zadania rozwojowe ontologii, które nazywamy „operacjami”. „robot-command „zapewnia interfejs wiersza poleceń podzielony na” polecenia”, z których każde obejmuje operację „Robot-core”.

większość operacji robotów pakuje funkcjonalność niskiego poziomu dostarczaną przez OWL API w funkcjonalność wysokiego poziomu wspólną dla procesów rozwoju ontologii w społeczności OBO. Aby uzyskać najlepszą kompatybilność, staramy się dopasować dokładną wersję interfejsu API OWL używanego przez robota do dokładnej wersji używanej przez najnowszą wersję Protégé. Niektóre operacje używają Apache Jena . Każda operacja działa z obiektami Java reprezentującymi ontologie OWL, reasonery OWL, klasy OWL itd., podczas gdy każde polecenie działa z ciągami opcji wiersza poleceń i plikami. Polecenia wykonują również różne kroki konwersji i walidacji. Interfejs wiersza poleceń wykorzystuje bibliotekę Apache Commons CLI do parsowania poleceń.

każda operacja ma zestaw testów jednostkowych zbudowanych z JUnit, które są wykonywane za każdym razem, gdy produkt końcowy (plik JAR) jest generowany. Każda komenda w robocie jest udokumentowana na własnej stronie internetowej (np. http://robot.obolibrary.org / reason). Strony internetowe są tworzone w formacie Markdown i zawierają wbudowane przykłady wiersza poleceń, które są analizowane i wykonywane w ramach naszych testów integracyjnych, a wyniki porównywane z zestawem wyjść „złotego standardu”. Funkcja „diff” robota jest używana podczas porównywania plików ontologicznych, w przeciwnym razie używane jest porównanie standardowych plików. Pomaga to zapewnić poprawność i spójność dokumentacji i kodu. Testy jednostkowe i testy integracyjne są wykonywane na dowolnym pull request do bazy kodu za pośrednictwem Travis continuous integration (Travis CI), dzięki czemu wkład w bazę kodu jest weryfikowany.

polecenia i operacje

ROBOT udostępnia obecnie 15 operacji (w bibliotece 'robot-core’) i 19 poleceń (dla interfejsu wiersza poleceń). Niektóre polecenia są dość wyspecjalizowane, a większość projektów ontologicznych nie używa ich wszystkich. Tutaj przedstawiamy przegląd najczęstszych i ogólnych poleceń. W każdym przypadku podstawowa funkcjonalność jest wspierana przez operacje w bibliotece „robot-core”, które mogą być używane niezależnie od interfejsu wiersza poleceń z dowolnego języka programowania działającego na JVM.

Konwertuj

obsługiwane są różne formaty ontologii OWL, w tym RDF / XML, Turtle, Manchester, format OBO i inne. Aby umożliwić dalszą interoperacyjność, ROBOT zawiera polecenie „convert” umożliwiające zmianę pomiędzy obsługiwanymi formatami ontologii. Pełną listę obsługiwanych formatów można znaleźć w dokumentacji 'convert’.

rozumowanie

rozumowanie jest jedną z najważniejszych operacji w robocie. Polecenie 'reason’ obejmuje dwa zastosowania: logiczną walidację ontologii i automatyczną klasyfikację. W obu przypadkach użytkownicy mogą wybrać preferowany reasoner, który służy do wykonywania wnioskowania. Duże ontologie , takie jak Ontologia genu, zwykle używają ELK, który szybko wykonuje rozumowanie wykorzystując profil el Sowa. Mniejsze ontologie o bogatszej aksjomatyzacji, takie jak Ontologia relacji, zwykle używają kompletnego sowy DL, np. Hermita .

gdy polecenie 'reason’ jest wywoływane na ontologii wejściowej, ROBOT zainicjuje reasoner za pomocą interfejsu Reasonera API OWL. Wynikłe wnioski są sprawdzane w celu zapewnienia, że ontologia jest logicznie spójna: ontologia musi być spójna i nie mieć niespójnych klas (tj., klas, których nie można utworzyć bez wprowadzenia niespójności). Jeśli ontologia jest niespójna, jest to zgłaszane i wykonywanie zatrzymuje się. ROBOT może opcjonalnie wykonywać dodatkowe kontrole, takie jak upewnienie się, że żadna z dwóch klas nie jest równoważna po rozumowaniu.

Jeśli ontologia jest spójna, ROBOT wykona automatyczną klasyfikację. Wszystkie bezpośrednio wnioskowane aksjomaty „podklasy” są dodawane do ontologii. Można skonfigurować generowanie innych typów aksjomatów.

twierdzenie wszystkich wywnioskowanych aksjomatów jest często fundamentalnym krokiem w procesie uwalniania ontologii biomedycznych. Wiele z tych klas ontologicznych utrzymuje tylko jedną nazwaną klasę nadrzędną (’a subClassOf B’, gdzie B jest inną klasą w ontologii), oraz zero lub więcej anonimowych klas nadrzędnych i/lub anonimowych klas równoważnych (’a subclassof/equivalentTo (r some B)’, gdzie R jest właściwością obiektu). Te anonimowe klasy pozwalają wnioskującemu wnioskować, które następnie są twierdzone. Dlatego też, w wersji release ontologii, klasa może mieć więcej niż jedną nazwaną klasę nadrzędną.

polecenie 'reason’ posiada dodatkowe polecenia „helper”. Polecenie „relax” zakłada podklasę aksjomatów według prostej reguły strukturalnej: wyrażenie „a equivalentTo (r some B) and … „pociąga za sobą podklasę R some B”. Może to być użyteczne, ponieważ konsumenci bio-ontologii często oczekują poruszania się po tych wyrażeniach, np. w partonomy W go i Uberon. Polecenie 'relax’ zwalnia programistę ontologii z konieczności twierdzenia o nich oprócz aksjomatów równoważności i jako takie jest również często uwzględniane w przepływach pracy wydań. Na koniec polecenie „reduce” usuwa zbędne podklasy aksjomatów i może być użyte po „relax” do usunięcia duplikatów aksjomatów, które zostały stwierdzone w tym kroku.

polecenie 'materialize’ używa wyrażenia Materializing Reasoner (EMR) do twierdzenia wnioskowanych wyrażeń w formie 'a subClassOf r some B’ . Tam, gdzie polecenie „reason” zapewnia wywnioskowanie nazwanych superklas, „materialize” zapewnia anonimowe superklasy. Nie jest to część standardowego cyklu wydania, ale może być korzystne dla tworzenia kompletnych podzbiorów ontologii.

praca z zewnętrznymi ontologiami

Odlewnia OBO ma na celu koordynowanie ontologii w sposób modułowy, tak aby Części niektórych ontologii mogły być użyte jako budulec dla innych ontologii. Na przykład ontologia jednostek chemicznych ChEBI jest używana do konstruowania definicji procesów i działań metabolicznych w ontologii genów . Istnieje wiele różnych strategii wykorzystania zewnętrznych ontologii i zarządzania zależnościami między ontologiami, w zależności od przypadku użycia.

Extract

polecenie 'extract’ tworzy moduł oparty na zestawie elementów do wyodrębnienia („seed”). Istnieją cztery różne metody ekstrakcji (określone przez opcję ’– method’): MIREOT, TOP, BOT i STAR.

metoda ekstrakcji MIREOTÓW robotów opiera się na zasadzie o tej samej nazwie i wymaga podania co najmniej jednego „dolnego” bytu. Opcjonalnie można również określić jeden lub więcej „top” podmiotów. Polecenie wyodrębnia wszystkie byty” dolnego „poziomu i ich przodków do poziomu „górnego” z ontologii wejściowej. Jeśli nie podano ” Top ” encji, to do encji najwyższego poziomu („owl: Thing”) dołączane są przodki.

metody TOP, BOT i STAR wykorzystują implementację OWL API Syntactic location Module Extraction (SLME), która gwarantuje przechwycenie wszystkich informacji logicznie istotnych dla zestawu nasion . Metoda bota („bottom”) zawiera wszystkie relacje pomiędzy jednostkami wejściowymi a ich przodkami. Metoda TOP zawiera wszystkie relacje pomiędzy jednostkami wejściowymi i ich potomkami. Wreszcie, metoda STAR obejmuje tylko wszystkie relacje między jednostkami wejściowymi. Metoda STAR produkuje najmniejsze wyjścia, podczas gdy metoda TOP zazwyczaj produkuje największe wyjścia.

aby wspierać pochodzenie terminów ontologicznych, polecenie 'extract’ ma opcję ’–annotate-with-source true’, która będzie adnotować każdy wyodrębniony termin adresem URL źródłowej ontologii, z której został wyodrębniony.

Usuń i filtruj

polecenia 'Usuń’ i 'filtruj’ są używane do drobnoziarnistych operacji na aksjomatach sowy. 'remove’ pozwala użytkownikom wybrać zestawy aksjomatów, które chcą usunąć z docelowej ontologii. 'filter’ robi odwrotnie, tak że tylko wybrane aksjomaty są kopiowane z wejścia do nowej ontologii wyjścia.

te dwa polecenia działają, zaczynając od zbioru encji, następnie stosując różne selektory, aby znaleźć powiązane encje, a na końcu wybierając typy aksjomatów do usunięcia lub filtrowania. Oczekujemy, że tylko niewielka liczba „zaawansowanych użytkowników” będzie bezpośrednio korzystać z tej funkcji, ale te polecenia będą ostatecznie stanowić podstawę dla innych komend wyższego poziomu.

polecenia te mogą być użyte do generowania podzbiorów ontologii opartych na adnotacjach poprzez filtrowanie lub usuwanie encji z podaną adnotacją. Ontologie obo Foundry często opisują klasy za pomocą właściwości „in subset”, aby określić, gdzie klasa może być używana. Selektor adnotacji umożliwia użytkownikowi podanie pełnej wartości adnotacji lub wzorca do dopasowania za pomocą wyrażenia regularnego.

Merge

polecenie 'merge’ łączy dwie lub więcej osobnych ontologii wejściowych w jedną ontologię. Zapewnia również możliwość scalania wszystkich importowanych ontologii pojedynczej ontologii wejściowej w jedną ontologię główną, co jest często używane podczas tworzenia wydania.

Scalanie zaimportowanych ontologii (określonych przez polecenia import) do ontologii wejściowej jest wykonywane automatycznie, dzięki czemu użytkownik nie musi wymieniać każdej zaimportowanej ontologii jako wejścia. Oferujemy opcję (’–collapse-import-closure false’), aby wyłączyć tę funkcję, wspierając przypadki, w których użytkownicy mogą łączyć wiele ontologii wejściowych, które mają instrukcje importu, ale chcą zachować ich import oddzielnie.

zapytania i raportowanie

przepływy pracy ontologii zazwyczaj obejmują operacje zapytań nad ontologią, tworząc raporty, które mogą być pouczające zarówno dla redaktorów, jak i użytkowników ontologii-na przykład tabelę wszystkich klas wraz z ich definicjami tekstowymi. Operacje zapytań mogą być również używane do sprawdzania poprawności. Język zapytań SPARQL zapewnia uniwersalny i deklaratywny sposób dla opiekunów ontologii do tworzenia raportów ontologicznych i sprawdzania poprawności . ROBOT zapewnia wygodny sposób wykonywania zapytań za pomocą polecenia „query” lub sprawdzania poprawności za pomocą polecenia „verify”. Dodatkowo polecenie 'report’ zawiera konfigurowalny pakiet standardowych zapytań dla projektów OBO, które mogą być używane w dowolnym przepływie pracy ontologii, bez konieczności zapoznania opiekuna ze SPARQL.

zapytanie

polecenie 'query’ robota uruchamia zapytania SPARQL na ontologiach lub innych zasobach RDF. Może to być używane przez opiekuna ontologii do wykonywania interaktywnych zapytań lub bardziej typowo do włączania standardowych zapytań do przepływu pracy ontologii. Polecenie 'query’ jest jedną z niewielu operacji , która używa Apache Jena, a nie OWL API. Jena API pozwala robotowi załadować ontologię jako zbiór trójek zawartych w obiekcie modelu RDF. Zapewnia silnik zapytań SPARQL dla tych modeli, którego używamy do uruchamiania wszystkich zapytań.

zapytania’SPARQL SELECT’ tworzą oddzieloną przecinkami lub tabulatorami tabelę wyników. Zapytania ASK tworzą plik o wartości logicznej. Zapytania 'SPARQL CONSTRUCT’ wytwarzają plik RDF, który może być dalej przetwarzany przez robota lub scalany z powrotem do załadowanej ontologii. 'CONSTRUCT’ S zapewniają wygodny sposób wykonywania ekspansji stylu „makro”. Zapytania 'SPARQL UPDATE’ wstawiają i / lub usuwają dane bezpośrednio w ontologii (jako Model RDF). ROBOT konwertuje Zaktualizowany Model RDF z powrotem do obiektu ontologii API OWL, który zostanie zapisany w dowolnej obsługiwanej składni.

polecenie 'query’ obsługuje opcję załadowania importowanych ontologii jako nazwanych Wykresów za pomocą opcji ’–use-graphs’. Jeśli wartość ta jest ustawiona na 'true’, import może być sprawdzany jako nazwane grafy (nazwa jest IRI ontologii), a domyślny wykres jest połączeniem wszystkich grafów. Użycie domyślnego wykresu jest podobne do przeprowadzenia „scalenia” wszystkich przywozów przed zapytaniem, ale rozróżnienie między importami zostałoby utracone w przypadku „scalenia”.

Verify

polecenie 'verify’ jest odmianą polecenia 'SPARQL SELECT’. Zapytania są używane do zapewnienia, że ontologia jest zgodna z z góry określonym zbiorem warunków; na przykład, zapewnienie, że żadna klasa nie ma wielu definicji tekstowych. Po zapytaniu SELECT, 'verify’ powiedzie się (np. zakończy działanie z kodem stanu 0), jeśli nie zostaną zwrócone żadne wyniki. Zawiedzie (tzn., zakończ z niezerowym kodem stanu), Jeśli jakiekolwiek wyniki są zwracane z zapytania. Tak więc, biorąc pod uwagę zapytanie SPARQL, które wybiera nieprawidłowe dane, polecenie 'verify’ sprawdzi, czy ontologia (lub inny zasób) nie zawiera takich nieprawidłowych danych.

Report

polecenie 'report’ jest rozszerzeniem 'query’ i 'verify’, które dostarcza szereg konfigurowalnych kontroli jakości (QC) dla ontologii i zwraca arkusz kalkulacyjny lub wyjście YAML naruszeń. Arkusz kalkulacyjny jest wyprowadzany w formacie oddzielonym przecinkami lub tabulatorami i łatwy do odczytania przez użytkownika, podczas gdy wyjście YAML może być łatwo analizowane przez inne programy.

kontrole QC obejmują kontrole adnotacji, kontrole logiczne i kontrole metadanych. Adnotacje są ważne dla ułatwienia zrozumienia przez człowieka, więc polecenie „report” wyszukuje przypadki, w których brakujące lub zduplikowane adnotacje mogą powodować problemy. Logiczne kontrole sprawdzają spójność strukturalną i spójność ontologii. Wreszcie, „raport” identyfikuje brakujące metadane ontologii, zgodnie z zaleceniami OBO Foundry.

istnieją trzy poziomy naruszeń, które są zgłaszane: Błąd, Ostrzeżenie i informacje. Najpoważniejszy jest błąd, taki jak brak lub duplikat etykiety. Domyślnie polecenie 'report’ nie powiedzie się w przypadku naruszenia poziomu błędu, zatrzymując wszelkie zautomatyzowane procesy kompilacji. Tego typu naruszenia muszą zostać naprawione przed opublikowaniem ontologii. Naruszenia na poziomie WARN powinny być naprawione tak szybko, jak to możliwe, np. wnioskowane równoważności klas jeden do jednego, które są zazwyczaj niezamierzone w projektach OBO. Informacje dotyczą zalecanych poprawek, które pomagają zachować spójność w ontologiach obo Foundry, takich jak rozpoczynanie definicji wielką literą i kończenie kropką. „raport” może być skonfigurowany z opcją wiersza poleceń, aby nie zawieść na innym poziomie naruszenia lub nigdy nie zawieść, niezależnie od jakichkolwiek naruszeń. Dokumentujemy każdą kontrolę jakości z sugestią ręcznej poprawki, którą użytkownik może zastosować.

domyślny” Profil ” z poziomami raportów dla każdej kontroli jakości jest dostarczany przez robota, ale użytkownicy mogą również tworzyć własne profile. W tych profilach mogą zmieniać poziomy naruszeń poszczególnych kontroli, wykluczać niektóre kontrole i dodawać własne kontrole jako zapytania SPARQL. Na przykład, niektóre ontologie mogą kategoryzować klasę pozbawioną definicji tekstowej jako błąd, podczas gdy inne mogą kategoryzować to jako ostrzeżenie. Jednym z naszych celów jest konwergencja na standardowym profilu, który jest maksymalnie przydatny dla zbioru wszystkich ontologii w bibliotece OBO, zachęcając do przyjęcia wspólnych kontroli jakości.

Naprawa

chociaż większość problemów zgłaszanych przez „validate” I „report” musi być naprawiona ręcznie, ROBOT zapewnia również polecenie „repair”, które może automatycznie rozwiązać niektóre problemy. Obecna implementacja Scali adnotacje dotyczące zduplikowanych aksjomatów i zaktualizuje odwołania do przestarzałych klas, gdy zostaną one opatrzone adnotacjami z sugerowanym zamiennikiem. Zamierzamy rozszerzyć „NAPRAWĘ” na szerszy zakres typowych problemów, dla których poprawna poprawka jest jasna.

Tworzenie ontologii szablonowej

ROBOT zapewnia system generowania terminów ontologicznych oparty na szablonach. Użytkownicy mają również możliwość podłączenia własnego systemu generowania terminów do ich przepływu pracy, takiego jak Dead Simple OWL Design Patterns (DOS-DPS) .

ogromna ilość danych jest przechowywana w arkuszach kalkulacyjnych i bazach danych, a formaty tabelaryczne są dobrze dostosowane do wielu rodzajów danych. Polecenie „szablon” robota pozwala użytkownikom konwertować dane tabelaryczne do formatu RDF / OWL. Szablon robota to po prostu plik wartości rozdzielanych tabulatorami (TSV) lub wartości rozdzielanych przecinkami (CSV) z pewnymi specjalnymi konwencjami, które są opisane w dokumentacji szablonu robota .

te szablony mogą być użyte do tworzenia ontologii modułowej. Arkusze kalkulacyjne szablonu mogą być utrzymywane jako część repozytorium kodu źródłowego ontologii i zamiast bezpośrednio edytować plik ontologii, Programiści edytują wiersze w arkuszu kalkulacyjnym, które odpowiadają terminom w ontologii. Polecenie 'template’ jest następnie używane do wygenerowania modułu ontologii, który jest dołączany jako polecenie import w edytorskiej wersji ontologii i scalany podczas procesu wydania.

Workflow

workflow składa się z zestawu zadań koordynowanych przez pewien system workflow. Przepływy pracy ontologii składają się z zadań, takich jak wykonywanie kontroli jakości, budowanie modułów importu, rozumowanie nad ontologiami i generowanie różnych produktów wydania ontologii.

sam ROBOT nie jest menedżerem przepływu pracy, chociaż pozwala na łączenie wielu poleceń w jedno długie polecenie. Podczas łańcuchowania poleceń robota, ontologia wyjściowa z jednego polecenia jest przekazywana bezpośrednio jako wejście do następnego polecenia. Na przykład, chaining może być użyty do zastąpienia dwóch poleceń scalających ontologie, a następnie wywołujących scalony produkt:

’ robot merge –input ont-1.Sowa — wejście ont-2.Sowa — wyjście połączone.Sowa.

robot reason –input merged.Sowa — wyjście uzasadnione.Sowa”.

zamiast tworzyć scalony produkt i uruchamiać 'reason’, można to zrobić jednym poleceniem:

`robot merge –input ont-1.Sowa — wejście ont-2.Sowa powód — wyjście uzasadnione.Sowa”.

kluczową zaletą łączenia łańcuchów jest to, że ontologie nie muszą być serializowane i parsowane między każdym krokiem; ten sam obiekt ontologii API OWL jest przechowywany w pamięci i przekazywany przez łańcuch poleceń robota. W przypadku dużych ontologii, łańcuchowanie może znacznie poprawić wydajność robota.

ponieważ polecenia robota mogą być wykonywane w wierszu poleceń, można użyć wielu różnych systemów przepływu pracy. Zwracamy uwagę na użycie GNU Make, który jest zwykle używany do kompilacji oprogramowania. Plik Makefile składa się z zestawu reguł używanych do tworzenia „celów”. W rozwoju ontologii, Makefile jest używany do zautomatyzowanych zadań, takich jak przygotowanie ontologii do wydania. W tym przypadku celami są zazwyczaj pliki ontologiczne. „Przepisy” dla reguł są poleceniami systemowymi w stylu Unix, wykonywanymi przez polecenie 'make’.

polecenia robotów mogą być używane jako „przepisy” do tworzenia „celów”. Typowy przepływ pracy nie wykorzysta wszystkich 19 poleceń robota. Na przykład, nie wszystkie projekty ontologii mogą używać szablonów robotów i dlatego nie wszystkie przepływy pracy wydań muszą zawierać polecenie 'template’. Programiści ontologii mogą zdecydować, które polecenia są potrzebne do wykonania wydania i zbudować przepływ pracy wokół tych poleceń. Rysunek 1 pokazuje standardowy sposób, w jaki wybór poleceń robota jest łączony dla przepływu pracy wydania.

Po pierwsze, kontrola jakości jest uruchamiana nad wersją edytorów ontologii z „raportem” lub „weryfikacją”. Wyszukują one równoważne klasy, końcowe spacje w adnotacjach, odwołania własne, nieprawidłową składnię odsyłaczy i brakujące etykiety. Wyniki są zapisywane do określonego katalogu ’ reports/’. Jeśli wystąpią jakiekolwiek naruszenia na poziomie błędu, zadanie nie powiedzie się i zapisze naruszenia do tabeli, aby można je było łatwo zidentyfikować. Ten krok pozwala programistom szybko sprawdzić, czy nowe zmiany wprowadziły jakiekolwiek problemy w ontologii i naprawić je przed wydaniem.

zakładając, że początkowy krok kontroli jakości zakończył się pomyślnie, następnym krokiem jest utworzenie modułów importu. ROBOT 'extract’ jest uruchamiany dla każdego wpisu na liście importów, które mają odpowiednie pliki terminowe (dla zestawu nasion) w katalogu’ imports/’. Spowoduje to utworzenie wszystkich modułów importu w tym samym katalogu ’ imports/’. Zapewnia to, że gdy ontologia jest wydana z zewnętrznymi terminami, wszystkie zewnętrzne terminy są aktualne z wydanymi wersjami źródłowych ontologii. Zwolnienie nieaktualnych terminów zewnętrznych może spowodować zamieszanie, ponieważ termin ten pokaże zarówno stare, jak i nowe szczegóły w usługach wyszukiwania ontologii, takich jak Ontobee i Ontology Lookup Service . Dodatkowe kontrole QC mogą być uruchamiane przez pełną ontologię z importem za pomocą polecenia „verify” lub przez ponowne uruchomienie „report”.

Ostatnio powstają główne produkty wydania: akta sowy i OBO. Aby utworzyć wydanie OWL, plik redaktorów jest przekazywany przez serię łańcuchowych poleceń robota: „reason”, „relax”, „reduce” i „annotate”. Ta seria poleceń pomaga zapewnić, że wydana ontologia jest zarówno łatwa do przeglądania i zrozumienia, jak i wolna od zbędnych aksjomatów. Jeśli którekolwiek z tych poleceń nie powiedzie się, proces Make zakończy się odpowiednim komunikatem o błędzie. Na przykład, jeśli ontologia jest niespójna, krok 'powód’ nie powiedzie się. Na koniec polecenie 'annotate’ dodaje wersję IRI do metadanych ontologii. Ten plik OWL jest następnie konwertowany do formatu OBO, w którym to momencie wszystkie cele są kopiowane do katalogu z datą wydania.

Zestaw programistyczny ontologii

Tworzenie pliku Makefile do koordynowania wszystkich tych kroków może być trudne. Ułatwiamy to programistom ontologii, dostarczając Ontology Development Kit (ODK). Może to być użyte do utworzenia repozytorium GitHub zgodnie ze standardowym układem, ze standardowym plikiem Makefile zgodnym z opisanym powyżej przepływem pracy. Powstałe repozytorium GitHub zostanie również automatycznie skonfigurowane do uruchamiania kroków walidacji (takich jak „raport”) przepływu pracy za pośrednictwem Travis CI . Obieg pracy można również wykonać za pomocą Dockera z kontenerami ODK wydanymi na Dockerhub . Pozwala to na łatwe wykonywanie obiegów pracy na lokalnym komputerze programisty ontologii, z Travis CI, lub za pomocą skalowalnych narzędzi kompilacji, takich jak Jenkins .

ODK opiera się na robocie i demonstruje jego użyteczność, ale pełna dyskusja wykracza poza zakres tego artykułu.