Übersicht

ROBOT bietet eine standardisierte und dennoch konfigurierbare Möglichkeit, den Ontologie-Entwicklungslebenszyklus über eine Bibliothek allgemeiner Funktionen auf hoher Ebene und eine Befehlszeilenschnittstelle zu unterstützen. ROBOT baut auf der OWL-API auf und ist mit allen Ontologiesyntaxen kompatibel, die die OWL-API unterstützt: RDF / XML, OWL / XML, Turtle, OWL Functional Syntax, OWL Complete Syntax und OBO Format. Der Quellcode ist in Java geschrieben und steht in unserem GitHub Repository unter einer Open Source (BSD 3) Lizenz zur Verfügung. Es wird auch als Java-Bibliothek auf Maven Central veröffentlicht. Robotercode kann aus jeder Programmiersprache verwendet werden, die auf der Java Virtual Machine (JVM) ausgeführt wird. Das Befehlszeilentool ist als JAR-Datei gepackt, die unter Unix (einschließlich macOS und Linux), Windows und anderen von der JVM unterstützten Plattformen ausgeführt werden kann. Diese JAR-Datei kann von der ROBOT GitHub-Site zusammen mit plattformspezifischen Skripten für die Verwendung von ‚robot‘ über die Befehlszeile heruntergeladen werden. Installationsanweisungen und Dokumentation finden Sie unter http://robot.obolibrary.org.

Architektur

Wir haben zuvor die grundlegende Architektur des Tools beschrieben , die wir hier zusammenfassen.

Der ROBOTER-Quellcode besteht aus zwei Teilen: ‚robot-core‘ und ‚robot-command‘. „robot-core“ ist eine Bibliothek, die gängige Ontologie-Entwicklungsaufgaben unterstützt, die wir „Operationen“ nennen. „robot-command“ bietet eine Befehlszeilenschnittstelle, die in „Befehle“ unterteilt ist, von denen jeder eine „Robot-Core“ -Operation umschließt.

Die meisten Roboteroperationen verpacken Low-Level-Funktionalität, die von der OWL-API bereitgestellt wird, in High-Level-Funktionalität, die für Ontologie-Entwicklungsworkflows in der OBO-Community üblich ist. Um die beste Kompatibilität zu gewährleisten, möchten wir die genaue Version der von ROBOT verwendeten OWL-API mit der genauen Version der neuesten Protégé-Version abgleichen. Einige Operationen verwenden Apache Jena . Jede Operation arbeitet mit Java-Objekten, die OWL-Ontologien, OWL-Reasoner, OWL-Klassen usw. darstellen., während jeder Befehl mit Befehlszeilenoptionszeichenfolgen und -dateien arbeitet. Die Befehle führen auch verschiedene Konvertierungs- und Validierungsschritte aus. Die Befehlszeilenschnittstelle verwendet die Apache Commons CLI-Bibliothek zum Parsen von Befehlen.

Jede Operation verfügt über eine Reihe von Unit-Tests, die mit JUnit erstellt wurden und jedes Mal ausgeführt werden, wenn das Endprodukt (die JAR-Datei) generiert wird. Jeder Befehl in ROBOT ist auf einer eigenen Webseite dokumentiert (z. B. http://robot.obolibrary.org/reason ). Die Webseiten werden im Markdown-Format erstellt und enthalten eingebettete Befehlszeilenbeispiele, die im Rahmen unserer Integrationstests analysiert und ausgeführt werden, wobei die Ergebnisse mit einem „Goldstandard“ -Ausgabesatz verglichen werden. Die ‚Diff‘-Funktionalität von ROBOT wird beim Vergleichen von Ontologiedateien verwendet, andernfalls wird der Standarddateivergleich verwendet. Dies trägt dazu bei, die Korrektheit und Konsistenz von Dokumentation und Code sicherzustellen. Die Unit-Tests und Integrationstests werden bei jedem Pull-Request auf die Codebasis über Travis Continuous Integration (Travis CI) ausgeführt, so dass Beiträge zur Codebasis verifiziert werden.

Befehle und Operationen

ROBOT bietet derzeit 15 Operationen (in der ‚robot-Core‘-Bibliothek) und 19 Befehle (für die Befehlszeilenschnittstelle). Einige Befehle sind sehr spezialisiert, und die meisten Ontologieprojekte verwenden nicht alle. Hier geben wir einen Überblick über die häufigsten und allgemeinsten Befehle. In jedem Fall wird die Kernfunktionalität durch Operationen in der Bibliothek ‚robot-core‘ unterstützt, die unabhängig von der Befehlszeilenschnittstelle aus jeder Programmiersprache, die auf der JVM ausgeführt wird, verwendet werden können.

Konvertieren

Eine Vielzahl von OWL-Ontologieformaten wird unterstützt, darunter RDF / XML, Turtle, Manchester, OBO-Format und mehr. Um weitere Interoperabilität zu ermöglichen, enthält ROBOT einen ‚convert‘-Befehl, um zwischen unterstützten Ontologieformaten zu wechseln. Eine vollständige Liste der unterstützten Formate finden Sie in der ‚convert‘-Dokumentation .

Argumentation

Argumentation ist eine der wichtigsten Operationen im ROBOTER. Der Befehl ‚reason‘ deckt zwei Verwendungszwecke ab: logische Validierung einer Ontologie und automatische Klassifizierung. In beiden Fällen können Benutzer ihren bevorzugten Reasoner auswählen, der zur Durchführung von Inferenzen verwendet wird. Große Ontologien wie die Genontologie verwenden typischerweise ELK , das mit dem OWL-EL-Profil schnell argumentiert. Kleinere Ontologien mit reichhaltigerer Axiomatisierung, wie die Relations-Ontologie, verwenden typischerweise einen vollständigen OWL-Reasoner wie HermiT .

Wenn der Befehl ‚reason‘ für eine Eingabe-Ontologie aufgerufen wird, initiiert ROBOT einen Reasoner über die OWL API Reasoner-Schnittstelle. Die resultierenden Schlussfolgerungen werden überprüft, um sicherzustellen, dass die Ontologie logisch kohärent ist: Die Ontologie muss konsistent sein und keine unbefriedigenden Klassen aufweisen (d. h., Klassen, die nicht instanziiert werden können, ohne eine Inkonsistenz einzuführen). Wenn die Ontologie inkohärent ist, wird dies gemeldet und die Ausführung angehalten. Der ROBOTER kann optional zusätzliche Überprüfungen durchführen, z. B. sicherstellen, dass keine zwei Klassen nach der Argumentation als gleichwertig eingestuft werden.

Wenn die Ontologie konsistent ist, führt der ROBOTER eine automatische Klassifizierung durch. Alle direkt abgeleiteten ’subClassOf‘ Axiome werden der Ontologie hinzugefügt. Die Generierung anderer Arten von Axiomen kann konfiguriert werden.

Die Behauptung aller abgeleiteten Axiome ist oft ein grundlegender Schritt im Freigabeprozess für biomedizinische Ontologien. Viele dieser Ontologieklassen behaupten nur eine einzige benannte Oberklasse (‚A subClassOf B‘, wobei B eine andere Klasse in der Ontologie ist) und null oder mehr anonyme Superklassen und / oder anonyme äquivalente Klassen (‚A subClassOf / equivalentTo (R some B)‘, wobei R eine Objekteigenschaft ist). Diese anonymen Klassen ermöglichen es dem Reasoner, Rückschlüsse zu ziehen, die dann geltend gemacht werden. Daher kann eine Klasse in der Release-Version einer Ontologie mehr als eine benannte Oberklasse haben.

Der Befehl „reason“ verfügt über zusätzliche „helper“-Befehle. Der Befehl ‚relax‘ behauptet die zugehörige Unterklasse von Axiomen gemäß einer einfachen Strukturregel: Ein Ausdruck ‚A equivalentTo (R some B) and …‘ impliziert ‚A subClassOf R some B‘ . Dies kann nützlich sein, da Verbraucher von Bioontologien häufig erwarten, dass sie in diesen Ausdrücken navigieren, z. B. partonomy in GO und Uberon. Der Befehl ‚relax‘ entlastet den Ontologieentwickler von der Notwendigkeit, diese zusätzlich zu den Äquivalenzaxiomen zu behaupten, und ist daher auch häufig in Release-Workflows enthalten. Schließlich entfernt der Befehl ‚reduce‘ redundante Unterklassen von Axiomen und kann nach ‚relax‘ verwendet werden, um doppelte Axiome zu entfernen, die in diesem Schritt behauptet wurden.

Der Befehl ‚materialize‘ verwendet einen Ausdruck Materializing Reasoner (EMR), um abgeleitete Ausdrücke der Form ‚A subClassOf R some B‘ zu bestätigen. Wo der Befehl ‚reason‘ abgeleitete benannte Superklassen behauptet, behauptet ‚materialize‘ anonyme Superklassen. Dies ist nicht Teil des Standard-Release-Zyklus, kann jedoch für die Erstellung vollständiger Ontologie-Teilmengen von Vorteil sein.

Arbeiten mit externen Ontologien

Die OBO Foundry zielt darauf ab, Ontologien modular zu koordinieren, so dass Teile einiger Ontologien als Bausteine für andere Ontologien verwendet werden können. Zum Beispiel wird die ChEBI Chemical Entities Ontologie verwendet, um OWL-Definitionen für metabolische Prozesse und Aktivitäten in der Genontologie zu konstruieren . Je nach Anwendungsfall gibt es verschiedene Strategien zur Nutzung externer Ontologien und zur Verwaltung von Abhängigkeiten zwischen Ontologien.

Extract

Der Befehl „extract“ erstellt ein Modul basierend auf einer Reihe von zu extrahierenden Entitäten (dem „Seed“). Es gibt vier verschiedene Extraktionsmethoden (wie durch die Option ‚–method‘ angegeben): MIREOT, TOP, BOT und STAR.

Die MIREOT-Extraktionsmethode von ROBOT basiert auf dem gleichnamigen Prinzip und erfordert, dass eine oder mehrere „bottom“ -Entitäten angegeben werden. Optional können auch eine oder mehrere „top“ -Entitäten angegeben werden. Der Befehl extrahiert alle Entitäten der „unteren“ Ebene und ihre Vorfahren bis zur „oberen“ Ebene aus der Eingabeontologie. Wenn keine „top“ -Entitäten bereitgestellt werden, sind Vorfahren bis zur Top-Level-Entität (‚owl: Thing‘) enthalten.

Die TOP-, BOT- und STAR-Methoden verwenden die OWL API Syntactic Locality Module Extraction (SLME) -Implementierung, die garantiert alle Informationen erfasst, die für den Seed-Satz logisch relevant sind . Die BOT-Methode („bottom“) umfasst alle Beziehungen zwischen den Eingabeentitäten und ihren Vorfahren. Die TOP-Methode umfasst alle Beziehungen zwischen den Eingabeentitäten und ihren Nachkommen. Schließlich enthält die STAR-Methode nur alle Beziehungen zwischen Eingabeentitäten. Die STAR-Methode erzeugt die kleinsten Ausgaben, während die TOP-Methode typischerweise die größten Ausgaben erzeugt.

Um die Herkunft von Ontologiebegriffen zu unterstützen, verfügt der Befehl ‚extract‘ über die Option ‚–annotate-with-source true‘, mit der jeder extrahierte Begriff mit der URL der Quell-Ontologie versehen wird, aus der er extrahiert wurde.

Entfernen und filtern

Die Befehle ‚Entfernen‘ und ‚filtern‘ werden für feinkörnige Operationen an OWL-Axiomen verwendet. Mit ‚remove‘ können Benutzer auswählen, welche Sätze von Axiomen sie aus einer Zielontologie entfernen möchten. ‚filter‘ bewirkt das Gegenteil, sodass nur ausgewählte Axiome aus der Eingabe in eine neue Ausgabeontologie kopiert werden.

Diese beiden Befehle beginnen mit einem Startsatz von Entitäten, wenden dann verschiedene Selektoren an, um verwandte Entitäten zu finden, und wählen schließlich aus, welche Axiomtypen entfernt oder gefiltert werden sollen. Wir erwarten, dass nur eine kleine Anzahl von „Power-Usern“ diese Funktion direkt verwenden, aber diese Befehle werden schließlich eine Grundlage für andere übergeordnete Befehle bilden.

Diese Befehle können verwendet werden, um Ontologieteilmengen basierend auf Annotationen zu generieren, indem entweder nach Entitäten mit der angegebenen Annotation gefiltert oder diese entfernt werden. OBO Foundry-Ontologien kommentieren Klassen häufig mit der Eigenschaft ‚in subset‘, um anzugeben, wo eine Klasse verwendet werden könnte. Mit dem Annotations-Selektor kann ein Benutzer einen vollständigen Annotationswert oder ein Muster angeben, das mit regulären Ausdrücken übereinstimmt.

Merge

Der Befehl ‚merge‘ kombiniert zwei oder mehr separate Eingabe-Ontologien zu einer einzigen Ontologie. Es bietet auch die Möglichkeit, alle importierten Ontologien einer einzelnen Eingabeontologie in einer Hauptontologie zusammenzuführen, die häufig beim Erstellen eines Releases verwendet wird.

Das Zusammenführen importierter Ontologien (angegeben durch import-Anweisungen) in die Eingabe-Ontologie erfolgt automatisch, sodass der Benutzer nicht jede importierte Ontologie als Eingabe auflisten muss. Wir bieten die Option (‚–collapse-import-closure false‘) an, um diese Funktion zu deaktivieren, und unterstützen Fälle, in denen Benutzer mehrere Eingabeontologien zusammenführen können, die Importanweisungen haben, aber ihre Importe getrennt halten möchten.

Abfragen und Berichten

Ontologie-Workflows umfassen typischerweise Abfrageoperationen über die Ontologie, wodurch Berichte erstellt werden, die sowohl für Redakteure als auch für Benutzer der Ontologie informativ sein können – zum Beispiel eine Tabelle aller Klassen plus ihrer Textdefinitionen. Abfrageoperationen können auch für Validierungsprüfungen verwendet werden. Die SPARQL-Abfragesprache bietet Ontologie-Betreuern eine universelle und deklarative Möglichkeit, Ontologieberichte und Validierungsprüfungen zu erstellen . ROBOT bietet eine bequeme Möglichkeit, Abfragen mit dem Befehl ‚query‘ oder Validierungsprüfungen mit ‚verify‘ durchzuführen. Darüber hinaus enthält der Befehl ‚report‘ ein konfigurierbares Paket von Standardabfragen für OBO-Projekte, die in jedem Ontologie-Workflow verwendet werden können, ohne dass der Betreuer mit SPARQL vertraut sein muss.

Query

Der Befehl ‚query‘ des ROBOTERS führt SPARQL-Abfragen für Ontologien oder andere RDF-Ressourcen aus. Dies kann von einem Ontology-Betreuer verwendet werden, um entweder interaktive Abfragen auszuführen oder um Standardabfragen in einen Ontology-Workflow einzubeziehen. Der Befehl ‚query‘ umschließt eine der wenigen Operationen, die Apache Jena anstelle der OWL-API verwendet. Mit der Jena-API können SIE eine Ontologie als Sammlung von Tripeln laden, die in einem RDF-Modellobjekt enthalten sind. Es bietet eine SPARQL-Abfrage-Engine für diese Modelle, mit der wir alle Abfragen ausführen.

‚SPARQL SELECT‘-Abfragen erzeugen eine komma- oder tabulatorgetrennte Ergebnistabelle. ASK-Abfragen erzeugen eine Datei mit einem booleschen Wert. ‚SPARQL CONSTRUCT‘-Abfragen erzeugen eine RDF-Datei, die von ROBOT weiterverarbeitet oder in die geladene Ontologie zurückgeführt werden kann. ‚KONSTRUKTE bieten eine bequeme Möglichkeit, die Erweiterung im „Makro“ -Stil durchzuführen. ‚SPARQL UPDATE‘-Abfragen fügen Daten direkt in eine Ontologie ein und / oder entfernen sie (als RDF-Modell). ROBOT konvertiert das aktualisierte RDF-Modell zurück in ein OWL API-Ontologieobjekt, das in einer der unterstützten Syntaxen gespeichert wird.

Der Befehl ‚query‘ unterstützt eine Option zum Laden importierter Ontologien als benannte Graphen mit der Option ‚–use-graphs‘. Wenn dies auf ‚true‘ gesetzt ist, können die Importe als benannte Diagramme abgefragt werden (der Name ist der IRI von ontology) und das Standarddiagramm ist eine Vereinigung aller Diagramme. Die Verwendung des Standarddiagramms ähnelt der Durchführung einer ‚Zusammenführung‘ aller Importe vor der Abfrage, aber die Unterscheidung zwischen Importen würde bei einer ‚Zusammenführung‘ verloren gehen.

Verify

Der Befehl ‚verify‘ ist eine Variation der Ausführung ‚SPARQL SELECT‘. Die Abfragen werden verwendet, um sicherzustellen, dass eine Ontologie einem vorbestimmten Satz von Bedingungen entspricht, z. B. um sicherzustellen, dass keine Klasse mehrere Textdefinitionen hat. Bei einer SELECT-Abfrage ist ‚verify‘ erfolgreich (dh mit Statuscode 0 beendet), wenn keine Ergebnisse zurückgegeben werden. Es wird fehlschlagen (dh., exit mit einem Statuscode ungleich Null), wenn Ergebnisse aus der Abfrage zurückgegeben werden. Bei einer SPARQL-Abfrage, die ungültige Daten auswählt, überprüft der Befehl ‚verify‘, ob die Ontologie (oder eine andere Ressource) keine solchen ungültigen Daten enthält.

Report

Der Befehl ‚report‘ ist eine Erweiterung von ‚query‘ und ‚verify‘, die eine Reihe konfigurierbarer Qualitätskontrollprüfungen (QC) für eine Ontologie bereitstellt und eine Tabellenkalkulation oder YAML-Ausgabe der Verstöße zurückgibt. Die Tabelle wird entweder in Komma- oder tabulatorgetrenntem Format ausgegeben und ist für einen Benutzer leicht zu lesen, während die YAML-Ausgabe leicht von anderen Programmen analysiert werden kann.

Die QC-Prüfungen umfassen Annotationsprüfungen, logische Prüfungen und Metadatenprüfungen. Anmerkungen sind wichtig, um das menschliche Verständnis zu erleichtern, so dass der Befehl ‚report‘ Fälle findet, in denen fehlende oder doppelte Anmerkungen Probleme verursachen könnten. Logische Prüfungen betrachten die strukturelle Kohärenz und Konsistenz der Ontologie. Schließlich identifiziert ‚report‘ fehlende Ontologiemetadaten, wie in den Empfehlungen von OBO Foundry angegeben.

Es gibt drei Ebenen von Verstößen, die gemeldet werden: ERROR, WARN und INFO. Ein FEHLER ist der schwerwiegendste, z. B. ein fehlendes oder doppeltes Etikett. Standardmäßig schlägt der Befehl ‚report‘ fehl, wenn Verstöße auf Fehlerebene vorliegen, wodurch automatisierte Erstellungsprozesse angehalten werden. Diese Art von Verstößen muss vor der Veröffentlichung einer Ontologie behoben werden. Verstöße auf WARN-Ebene sollten so schnell wie möglich behoben werden, z. B. abgeleitete Eins-zu-Eins-Klassenäquivalenzen, die in OBO-Projekten normalerweise unbeabsichtigt sind. Dies ist für empfohlene Korrekturen gedacht, die dazu beitragen, die Konsistenz über OBO Foundry-Ontologien hinweg aufrechtzuerhalten, z. B. eine Definition mit einem Großbuchstaben zu beginnen und mit einem Punkt zu enden. ‚report‘ kann mit einer Befehlszeilenoption so konfiguriert werden, dass es auf einer anderen Verletzungsebene fehlschlägt oder niemals fehlschlägt, unabhängig von Verstößen. Wir dokumentieren jede QC-Prüfung mit einem Vorschlag für eine manuelle Korrektur, die der Benutzer anwenden kann.

Ein Standard- „Profil“ mit Berichtsebenen für jede QC-Prüfung wird von ROBOT bereitgestellt, aber Benutzer können auch ihre eigenen Profile erstellen. In diesen Profilen können sie die Verletzungsstufen einzelner Prüfungen ändern, bestimmte Prüfungen ausschließen und ihre eigenen Prüfungen als SPARQL-Abfragen hinzufügen. Zum Beispiel können einige Ontologien eine Klasse ohne Textdefinition als Fehler kategorisieren, während andere dies als Warnung kategorisieren können. Eines unserer Ziele ist es, ein Standardprofil zu erstellen, das für alle Ontologien in der OBO-Bibliothek maximal nützlich ist, um die Einführung gemeinsamer Qualitätskontrollen zu fördern.

Repair

Obwohl die meisten Probleme, die durch ‚validate‘ und ‚report‘ verursacht werden, manuell behoben werden müssen, bietet ROBOT auch einen ‚repair‘-Befehl, der bestimmte Probleme automatisch beheben kann. Die aktuelle Implementierung führt Anmerkungen zu doppelten Axiomen zusammen und aktualisiert Verweise auf veraltete Klassen, wenn sie mit einem vorgeschlagenen Ersatz versehen werden. Wir beabsichtigen, die Reparatur auf ein breiteres Spektrum häufiger Probleme auszudehnen, für die die richtige Lösung klar ist.

Template-Ontologie-Entwicklung

ROBOT bietet ein Template-gesteuertes Ontologie-Termgenerierungssystem. Benutzer haben auch die Möglichkeit, ihr eigenes Termerzeugungssystem in ihren Workflow einzubinden, z. B. Dead Simple OWL Design Patterns (DOS-DPs) .

Eine riesige Menge an Daten wird in Tabellenkalkulationen und Datenbanken gespeichert, und Tabellenformate eignen sich gut für viele Arten von Daten. ROBOT ’s ‚template‘ Befehl ermöglicht es Benutzern, Tabellendaten in RDF / OWL-Format zu konvertieren. Eine Robotervorlage ist einfach eine tabulatorgetrennte Wertedatei (TSV) oder kommagetrennte Wertedatei (CSV) mit einigen speziellen Konventionen, die in der Dokumentation zur Robotervorlage beschrieben werden .

Diese Vorlagen können für die modulare Ontologieentwicklung verwendet werden. Anstatt die Ontologiedatei direkt zu bearbeiten, bearbeiten Entwickler Zeilen in der Tabelle, die Begriffen in der Ontologie entsprechen. Der Befehl ‚template‘ wird dann verwendet, um ein Modul der Ontologie zu generieren, das als Importanweisung in der Editorversion der Ontologie enthalten ist und während des Freigabeprozesses zusammengeführt wird.

Workflows

Ein Workflow besteht aus einer Reihe von Aufgaben, die von einem Workflowsystem koordiniert werden. Ontologie-Workflows bestehen aus Aufgaben wie der Ausführung von QC-Prüfungen, der Erstellung von Importmodulen, der Argumentation über Ontologien und der Generierung verschiedener Ontologie-Release-Produkte.

ROBOT selbst ist kein Workflow-Manager, obwohl mehrere Befehle zu einem langen Befehl verkettet werden können. Bei der Verkettung von Roboterbefehlen wird die Ausgabeontologie eines Befehls direkt als Eingabe an den nächsten Befehl übergeben. Beispielsweise kann die Verkettung verwendet werden, um zwei Befehle zu ersetzen, die Ontologien zusammenführen und dann über das zusammengeführte Produkt schreiben:

`robot merge –input ont-1 .owl –Eingabe ont-2.owl –Ausgabe zusammengeführt.Eule.

robot reason –Eingabe zusammengeführt.owl – Ausgabe begründet.Eule`.

Anstatt das zusammengeführte Produkt zu erstellen und ‚reason‘ darüber auszuführen, kann dies mit einem Befehl erfolgen:

`robot merge –input ont-1 .owl –Eingabe ont-2.owl reason – Ausgabe begründet.Eule`.

Der Hauptvorteil der Verkettung besteht darin, dass Ontologien nicht zwischen jedem Schritt serialisiert und analysiert werden müssen; dasselbe OWL API-Ontologieobjekt wird im Speicher verwaltet und durch die Kette der Roboterbefehle geleitet. Bei großen Ontologien kann die Verkettung die Leistung des ROBOTERS erheblich verbessern.

Da Roboterbefehle über die Befehlszeile ausgeführt werden können, können verschiedene Workflow-Systeme verwendet werden. Wir heben die Verwendung von GNU Make hervor , das typischerweise zum Kompilieren von Software verwendet wird. Ein Makefile besteht aus einer Reihe von Regeln, mit denen „Ziele“ erstellt werden. In der Ontologieentwicklung wird das Makefile für automatisierte Aufgaben verwendet, z. B. zum Vorbereiten einer Ontologie für die Veröffentlichung. In diesem Fall sind die Ziele normalerweise Ontologiedateien. Die „Rezepte“ für die Regeln sind Systembefehle im Unix-Stil, die vom Befehl „make“ ausgeführt werden.

Roboterbefehle können als „Rezepte“ verwendet werden, um die „Ziele“ zu erstellen. Ein typischer Workflow verwendet nicht alle 19 Roboterbefehle. Beispielsweise verwenden möglicherweise nicht alle Ontologieprojekte Robotervorlagen, und daher müssen nicht alle Release-Workflows den Befehl ‚Vorlage‘ enthalten. Ontology-Entwickler können entscheiden, welche Befehle zum Ausführen der Freigabe erforderlich sind, und einen Workflow um diese Befehle herum erstellen. Abbildung 1 zeigt eine Standardmethode, in der eine Auswahl von Roboterbefehlen für einen Freigabeworkflow kombiniert wird.

Der Workflow für die Roboterfreigabe. Ein typischer Release-Workflow mit ROBOT. Die Ontologie-Bearbeitungsdatei ONT-edit.owl wird zunächst als Qualitätskontrolle mit dem ROBOTER ‚verify‘ verifiziert. Anschließend werden Textdateien mit Listen externer Ontologiebegriffe im Importverzeichnis verwendet, um Importmodule mithilfe von ‚extrahieren‘ neu zu generieren und sicherzustellen, dass die Importe auf dem neuesten Stand sind. ONT-bearbeiten.owl wird dann durch eine Reihe von Roboterbefehlen (‚reason‘, ‚relax‘, ‚reduce‘ und ‚annotate‘) geleitet, um die Freigabe ONT zu generieren.Eule. Endlich, ONT.owl wird in das OBO-Format konvertiert

Zunächst werden Qualitätskontrollen über die Editoren-Version der Ontologie mit „report“ oder „verify“ durchgeführt. Diese suchen nach äquivalenten Klassen, nachgestellten Leerzeichen in Anmerkungen, Selbstreferenzen, falscher Querverweissyntax und fehlenden Beschriftungen. Die Ergebnisse werden in einem bestimmten Verzeichnis ‚reports /‘ gespeichert. Wenn Verstöße auf Fehlerebene vorliegen, schlägt die Aufgabe fehl und schreibt die Verstöße in eine Tabelle, damit sie leicht identifiziert werden können. Mit diesem Schritt können Entwickler schnell feststellen, ob neue Änderungen Probleme in der Ontologie verursacht haben, und diese vor der Veröffentlichung beheben.

Angenommen, der erste QC-Prüfschritt wurde erfolgreich abgeschlossen, besteht der nächste Schritt darin, die Importmodule zu erstellen. Der ROBOTER ‚extract‘ wird für jeden Eintrag in einer Liste von Importen ausgeführt, die entsprechende Term-Dateien (für den Seed-Satz) im Verzeichnis ‚imports /‘ haben. Dadurch werden alle Importmodule im selben Verzeichnis ‚imports /‘ erstellt. Dadurch wird sichergestellt, dass bei der Freigabe einer Ontologie mit externen Termen alle externen Terme mit den freigegebenen Versionen der Quell-Ontologien auf dem neuesten Stand sind. Das Freigeben veralteter externer Begriffe kann zu Verwirrung führen, da der Begriff sowohl die alten als auch die neuen Details in Ontology-Suchdiensten wie Ontobee und dem Ontology Lookup Service anzeigt . Zusätzliche QC-Prüfungen können über die gesamte Ontologie mit Importen mit dem Befehl ‚verify‘ oder durch erneutes Ausführen von ‚report‘ ausgeführt werden.

Zuletzt werden die wichtigsten Release-Produkte erstellt: die OWL-Datei und die OBO-Datei. Um die OWL-Version zu erstellen, wird die Datei des Editors durch eine Reihe verketteter Roboterbefehle geleitet: ‚reason‘, ‚relax‘, ‚reduce‘ und ‚annotate‘. Diese Reihe von Befehlen trägt dazu bei, dass die freigegebene Ontologie sowohl einfach zu durchsuchen und zu verstehen als auch frei von redundanten Axiomen ist. Wenn einer dieser Befehle fehlschlägt, wird der Make-Prozess mit der entsprechenden Fehlermeldung beendet. Wenn beispielsweise eine Ontologie inkohärent ist, schlägt der Schritt ‚Grund‘ fehl. Schließlich fügt der Befehl ‚annotieren‘ die Version IRI zu den Ontologiemetadaten hinzu. Diese OWL-Datei wird dann in das OBO-Format konvertiert, wobei alle Ziele in ein datiertes Release-Verzeichnis kopiert werden.

Das Ontology Development Kit

Ein Makefile zu erstellen, um all diese Schritte zu koordinieren, kann eine Herausforderung sein. Wir machen dies für Ontology-Entwickler einfacher, indem wir ein Ontology Development Kit (ODK) bereitstellen. Dies kann verwendet werden, um ein GitHub-Repository nach einem Standardlayout zu erstellen, wobei ein Standard-Makefile dem oben beschriebenen Workflow folgt. Das resultierende GitHub-Repository wird auch automatisch so konfiguriert, dass die Validierungsschritte (z. B. ‚Bericht‘) des Workflows über Travis CI ausgeführt werden. Der Workflow kann auch mit Docker mit ODK-Containern ausgeführt werden, die auf Dockerhub veröffentlicht wurden . Dies ermöglicht die einfache Ausführung von Workflows entweder auf dem lokalen Computer eines Ontology-Entwicklers mit Travis CI oder über skalierbare Build-Tools wie Jenkins .

ODK baut auf ROBOT auf und demonstriert den Nutzen von ROBOT, aber eine vollständige Diskussion geht über den Rahmen dieses Artikels hinaus.