Aperçu

ROBOT fournit un moyen standardisé mais configurable de prendre en charge le cycle de vie du développement de l’ontologie via une bibliothèque de fonctionnalités de haut niveau communes et une interface de ligne de commande. ROBOT s’appuie sur l’API OWL et est compatible avec toutes les syntaxes d’ontologie prises en charge par l’API OWL : RDF/XML, OWL/XML, Turtle, Syntaxe fonctionnelle OWL, Syntaxe OWL Manchester et format OBO. Le code source est écrit en Java et est disponible à partir de notre référentiel GitHub sous une licence open source (BSD 3). Il est également publié en tant que bibliothèque Java sur Maven Central. Le code ROBOT peut être utilisé à partir de n’importe quel langage de programmation qui s’exécute sur la machine virtuelle Java (JVM). L’outil de ligne de commande est emballé sous la forme d’un fichier JAR pouvant être exécuté sur Unix (y compris macOS et Linux), Windows et d’autres plates-formes prises en charge par la machine virtuelle java. Ce fichier JAR est disponible en téléchargement sur le site GitHub de ROBOT, ainsi que des scripts spécifiques à la plate-forme pour utiliser « robot » à partir de la ligne de commande. Les instructions d’installation et la documentation sont disponibles auprès de http://robot.obolibrary.org.

Architecture

Nous avons précédemment décrit l’architecture de base de l’outil, que nous résumons ici.

Le code source du ROBOT se compose de deux parties : ‘robot-core’ et ‘robot-command’. ‘robot-core’ est une bibliothèque supportant des tâches communes de développement d’ontologie, que nous appelons des « opérations ”. ‘robot-command’ fournit une interface de ligne de commande divisée en ”commandes », chacune enveloppant une opération « robot-core ».

La plupart des opérations ROBOTIQUES regroupent les fonctionnalités de bas niveau fournies par l’API OWL dans des fonctionnalités de haut niveau communes aux flux de travail de développement d’ontologie dans la communauté OBO. Pour une meilleure compatibilité, nous visons à faire correspondre la version exacte de l’API OWL utilisée par ROBOT avec la version exacte utilisée par la dernière version de Protégé. Certaines opérations utilisent Apache Jena. Chaque opération fonctionne avec des objets Java qui représentent des ontologies OWL, des raisonneurs OWL, des classes OWL, etc., alors que chaque commande fonctionne avec des chaînes et des fichiers d’options de ligne de commande. Les commandes effectuent également diverses étapes de conversion et de validation. L’interface de ligne de commande utilise la bibliothèque CLI Apache Commons pour analyser les commandes.

Chaque opération a un ensemble de tests unitaires construits avec JUnit qui sont exécutés chaque fois que le produit final (le fichier JAR) est généré. Chaque commande dans ROBOT est documentée dans sa propre page Web (par exemple http://robot.obolibrary.org/reason). Les pages Web sont créées au format Markdown et contiennent des exemples de ligne de commande intégrés qui sont analysés et exécutés dans le cadre de nos tests d’intégration, les résultats étant comparés à un ensemble de sorties « gold standard”. La fonctionnalité « diff » du ROBOT est utilisée lors de la comparaison de fichiers d’ontologie, sinon une comparaison de fichiers standard est utilisée. Cela permet d’assurer l’exactitude et la cohérence de la documentation et du code. Les tests unitaires et les tests d’intégration sont exécutés sur n’importe quelle requête d’extraction sur la base de code via Travis continuous integration (Travis CI), de sorte que les contributions à la base de code sont vérifiées.

Commandes et opérations

Le ROBOT fournit actuellement 15 opérations (dans la bibliothèque ‘robot-core’) et 19 commandes (pour l’interface de ligne de commande). Certaines commandes sont assez spécialisées, et la plupart des projets d’ontologie ne les utiliseront pas toutes. Nous donnons ici un aperçu des commandes les plus courantes et générales. Dans chaque cas, la fonctionnalité de base est prise en charge par des opérations dans la bibliothèque ‘robot-core’, qui peuvent être utilisées indépendamment de l’interface de ligne de commande à partir de n’importe quel langage de programmation qui s’exécute sur la JVM.

Convert

Une variété de formats d’ontologie OWL sont pris en charge, notamment RDF/XML, Turtle, Manchester, le format OBO, etc. Pour permettre une interopérabilité accrue, ROBOT inclut une commande « convertir » pour changer entre les formats d’ontologie pris en charge. Une liste complète des formats pris en charge se trouve dans la documentation « convertir ».

Raisonnement

Le raisonnement est l’une des opérations les plus importantes du ROBOT. La commande ’reason’ couvre deux utilisations : la validation logique d’une ontologie et la classification automatique. Dans les deux cas, les utilisateurs peuvent choisir leur raisonneur préféré, qui est utilisé pour effectuer l’inférence. Les grandes ontologies telles que l’ontologie des gènes utilisent généralement le WAPITI, qui effectue un raisonnement rapidement en utilisant le profil EL du HIBOU. Les ontologies plus petites avec une axiomatisation plus riche, telles que l’Ontologie des relations, utilisent généralement un raisonneur complet OWL DL tel que HermiT.

Lorsque la commande ’reason’ est invoquée sur une ontologie d’entrée, ROBOT lance un reasoner à l’aide de l’interface Reasoner de l’API OWL. Les inférences résultantes sont vérifiées pour s’assurer que l’ontologie est logiquement cohérente : l’ontologie doit être cohérente et n’avoir aucune classe insatisfaisante (i.e., classes qui ne peuvent pas être instanciées sans introduire une incohérence). Si l’ontologie est incohérente, cela est signalé et l’exécution s’arrête. Le ROBOT peut éventuellement effectuer des vérifications supplémentaires, telles que s’assurer qu’il n’y a pas deux classes équivalentes à un post-raisonnement.

Si l’ontologie est cohérente, le ROBOT effectuera une classification automatique. Tous les axiomes de « sous-classe » inférés directement sont ajoutés à l’ontologie. La génération d’autres types d’axiomes peut être configurée.

L’affirmation de tous les axiomes inférés est souvent une étape fondamentale du processus de libération des ontologies biomédicales. Beaucoup de ces classes d’ontologie n’affirment qu’une seule superclasse nommée (‘A subClassOf B’, où B est une autre classe de l’ontologie), et zéro ou plusieurs superclasses anonymes et/ou classes équivalentes anonymes (‘A subClassOf/equivalentTo (R some B)’, où R est une propriété d’objet). Ces classes anonymes permettent au raisonneur de faire des inférences, qui sont ensuite affirmées. Par conséquent, dans la version de publication d’une ontologie, une classe peut avoir plus d’une superclasse nommée.

La commande ‘reason’ contient des commandes « helper ” supplémentaires. La commande « relax » affirme que la Sous-classe d’axiomes implique selon une règle structurelle simple‘ une expression « A equivalentTo (R some B) et … » implique ‘Une sous-classe de R some B ». Cela peut être utile car les consommateurs de bio-ontologies s’attendent souvent à naviguer dans ces expressions, par exemple la partonomie dans GO et Uberon. La commande « relax » soulage le développeur de l’ontologie de la nécessité de les affirmer en plus des axiomes d’équivalence, et en tant que telle, elle est également souvent incluse dans les flux de travail de publication. Enfin, la commande ’reduce’ supprime les axiomes redondants de la sous-classe et peut être utilisée après ‘relax’ pour supprimer les axiomes en double qui ont été affirmés lors de cette étape.

La commande ’materialize’ utilise un Raisonneur matérialisant l’Expression (EMR) pour affirmer des expressions inférées de la forme ‘A subClassOf R some B’’ Lorsque la commande ‘reason’ affirme des superclasses nommées inférées, ‘materialize’ affirme des superclasses anonymes. Cela ne fait pas partie du cycle de publication standard, mais peut être bénéfique pour créer des sous-ensembles d’ontologie complets.

Travailler avec des ontologies externes

La fonderie OBO vise à coordonner les ontologies de manière modulaire, de sorte que des parties de certaines ontologies puissent être utilisées comme blocs de construction pour d’autres ontologies. Par exemple, l’ontologie des entités chimiques ChEBI est utilisée pour construire des définitions OWL pour les processus et activités métaboliques dans l’ontologie des gènes. Il existe différentes stratégies pour tirer parti des ontologies externes et gérer les dépendances entre ontologies, selon le cas d’utilisation.

Extract

La commande ‘extract’ crée un module basé sur un ensemble d’entités à extraire (la « graine”). Il existe quatre méthodes d’extraction différentes (comme spécifié par l’option ‘methodmethod’): MIREOT, TOP, BOT et STAR.

La méthode d’extraction de MIREOT du ROBOT est basée sur le principe du même nom et nécessite qu’une ou plusieurs entités « inférieures” soient spécifiées. Optionnellement, une ou plusieurs entités « top” peuvent également être spécifiées. La commande extrait toutes les entités de niveau « inférieur » et leurs ancêtres jusqu’au niveau ”supérieur » de l’ontologie d’entrée. Si aucune entité « supérieure » n’est fournie, les ancêtres jusqu’à l’entité de niveau supérieur (‘owl:Thing’) sont inclus.

Les méthodes TOP, BOT et STAR utilisent l’implémentation SLME (Syntactic Locality Module Extraction) de l’API OWL, qui est garantie de capturer toutes les informations logiquement pertinentes pour l’ensemble de semences. La méthode BOT (”bottom ») inclut toutes les relations entre les entités d’entrée et leurs ancêtres. La méthode TOP inclut toutes les relations entre les entités d’entrée et leurs descendants. Enfin, la méthode STAR n’inclut que toutes les relations entre les entités d’entrée. La méthode STAR produit les plus petites sorties, tandis que la méthode TOP produit généralement les plus grandes sorties.

Afin de prendre en charge la provenance du terme d’ontologie, la commande ‘extract’ a une option ‘annotannotate-with-source true’ qui annotera chaque terme extrait avec l’URL de l’ontologie source dont il est extrait.

Remove and filter

Les commandes ’remove‘ et ’filter’ sont utilisées pour des opérations à grain fin sur les axiomes OWL. ‘remove’ permet aux utilisateurs de choisir les ensembles d’axiomes qu’ils souhaitent supprimer d’une ontologie cible. ‘filter’ fait le contraire, de sorte que seuls les axiomes sélectionnés sont copiés de l’entrée dans une nouvelle ontologie de sortie.

Ces deux commandes fonctionnent en commençant par un ensemble de graines d’entités, puis en appliquant divers sélecteurs pour trouver des entités associées, et enfin en sélectionnant les types d’axiomes à supprimer ou à filtrer. Nous nous attendons à ce qu’un petit nombre d ‘ »utilisateurs expérimentés” utilisent directement cette fonctionnalité, mais ces commandes finiront par fournir une base pour d’autres commandes de niveau supérieur.

Ces commandes peuvent être utilisées pour générer des sous-ensembles d’ontologie basés sur des annotations en filtrant ou en supprimant des entités avec l’annotation spécifiée. Les ontologies de fonderie OBO annotent souvent les classes avec la propriété ’in subset’ pour spécifier où une classe peut être utilisée. Le sélecteur d’annotation permet à un utilisateur de fournir une valeur d’annotation complète ou un motif à assortir à l’aide d’une expression régulière.

Merge

La commande ‘merge’ combine deux ou plusieurs ontologies d’entrée distinctes en une seule ontologie. Il offre également la possibilité de fusionner toutes les ontologies importées d’une seule ontologie d’entrée en une seule ontologie principale, qui est souvent utilisée lors de la création d’une version.

La fusion des ontologies importées (spécifiées par les instructions import) dans l’ontologie d’entrée est effectuée automatiquement, de sorte que l’utilisateur n’a pas besoin de lister chaque ontologie importée en entrée. Nous offrons l’option (‘collapsecollapse-import-closure false’) pour désactiver cette fonctionnalité, en prenant en charge les cas dans lesquels les utilisateurs peuvent fusionner plusieurs ontologies d’entrée qui ont des instructions d’importation mais souhaitent conserver leurs importations séparées.

Interrogation et reporting

Les workflows d’ontologie incluent généralement des opérations de requête sur l’ontologie, produisant des rapports qui peuvent être informatifs pour les éditeurs et les utilisateurs de l’ontologie – par exemple, une table de toutes les classes plus leurs définitions textuelles. Les opérations de requête peuvent également être utilisées pour les vérifications de validation. Le langage de requête SPARQL fournit aux responsables d’ontologie un moyen universel et déclaratif de créer des rapports d’ontologie et des vérifications de validation. ROBOT fournit un moyen pratique d’effectuer des requêtes avec la commande ‘query’, ou des vérifications de validation à l’aide de ‘verify’. De plus, la commande ’report’ inclut un ensemble configurable de requêtes standard pour les projets OBO qui peuvent être utilisées dans n’importe quel flux de travail d’ontologie, sans que le responsable ne soit familier avec SPARQL.

Query

La commande ‘query’ du ROBOT exécute des requêtes SPARQL sur des ontologies ou d’autres ressources RDF. Cela peut être utilisé par un responsable d’ontologie pour effectuer des requêtes interactives, ou plus généralement pour inclure des requêtes standard dans un flux de travail d’ontologie. La commande ‘query’ enveloppe l’une des rares opérations qui utilise Apache Jena, plutôt que l’API OWL. L’API Jena permet au ROBOT de charger une ontologie sous la forme d’une collection de triplets contenus par un objet modèle RDF. Il fournit un moteur de requête SPARQL pour ces modèles, que nous utilisons pour exécuter toutes les requêtes.

Les requêtes ‘SPARQL SELECT’ produisent une table de résultats séparée par des virgules ou des tabulations. Les requêtes ASK produisent un fichier avec une valeur booléenne. Les requêtes ‘SPARQL CONSTRUCT’ produisent un fichier RDF, qui peut être traité par un ROBOT ou fusionné dans l’ontologie chargée. Les ‘CONSTRUCT’ fournissent un moyen pratique d’effectuer une extension de style ”macro ». Les requêtes ‘SPARQL UPDATE’ insèrent et/ou suppriment des données directement dans une ontologie (en tant que modèle RDF). ROBOT convertit le modèle RDF mis à jour en un objet ontologie de l’API OWL à enregistrer dans l’une des syntaxes prises en charge.

La commande ‘query’ prend en charge une option pour charger des ontologies importées sous forme de graphiques nommés avec l’option ’useuse-graphs’. Si cela est défini sur ‘true’, les importations peuvent être interrogées sous forme de graphiques nommés (le nom étant l’IRI de cette ontologie) et le graphique par défaut est une union de tous les graphiques. L’utilisation du graphique par défaut revient à effectuer une « fusion » de toutes les importations avant l’interrogation, mais la distinction entre les importations serait perdue dans une « fusion ».

Verify

La commande ’verify’ est une variante de l’exécution ’SPARQL SELECT’. Les requêtes sont utilisées pour s’assurer qu’une ontologie est conforme à un ensemble prédéterminé de conditions ; par exemple, s’assurer qu’aucune classe n’a plusieurs définitions textuelles. Étant donné une requête SELECT‘ ‘verify’ réussira (c’est-à-dire quitter avec le code d’état 0) si aucun résultat n’est renvoyé. Il échouera (c’est-à-dire, exit avec un code d’état différent de zéro) si des résultats sont renvoyés par la requête. Ainsi, étant donné une requête SPARQL qui sélectionne des données invalides, la commande ’verify’ vérifiera que l’ontologie (ou une autre ressource) ne contient pas de telles données invalides.

Report

La commande ’report’ est une extension de ‘query’ et ‘verify’ qui fournit une série de contrôles de contrôle qualité (QC) configurables pour une ontologie et renvoie une feuille de calcul ou une sortie YAML des violations. La feuille de calcul est sortie au format séparé par des virgules ou des onglets et facile à lire pour un utilisateur, tandis que la sortie YAML peut être facilement analysée par d’autres programmes.

Les contrôles QC incluent les contrôles d’annotation, les contrôles logiques et les contrôles de métadonnées. Les annotations sont importantes pour faciliter la compréhension humaine, de sorte que la commande « rapport » trouve les cas où des annotations manquantes ou dupliquées pourraient causer des problèmes. Les vérifications logiques examinent la cohérence structurelle et la cohérence de l’ontologie. Enfin‘ « rapport » identifie les métadonnées d’ontologie manquantes, comme spécifié par les recommandations d’OBO Foundry.

Il y a trois niveaux de violations qui sont signalés : ERREUR, AVERTISSEMENT et INFO. Une ERREUR est la plus grave, comme une étiquette manquante ou en double. Par défaut, la commande ‘report’ échoue en cas de violation au niveau des ERREURS, ce qui interrompt les processus de génération automatisés. Ces types de violations doivent être corrigés avant de publier une ontologie. Les violations au niveau de la MISE en GARDE doivent être corrigées dès que possible, par exemple les équivalences de classe un à un inférées, qui sont généralement involontaires dans les projets OBO. INFO concerne les correctifs recommandés qui aident à maintenir la cohérence entre les ontologies de la fonderie OBO, comme commencer une définition par une lettre majuscule et se terminer par un point.  » rapport  » peut être configuré avec une option de ligne de commande pour échouer à un niveau de violation différent ou pour ne jamais échouer, quelles que soient les violations. Nous documentons chaque contrôle QC avec une suggestion de correction manuelle que l’utilisateur peut appliquer.

Un « profil” par défaut avec des niveaux de rapport pour chaque contrôle QC est fourni par ROBOT, mais les utilisateurs peuvent également créer leurs propres profils. Dans ces profils, ils peuvent modifier les niveaux de violation des vérifications individuelles, choisir d’exclure certaines vérifications et ajouter leurs propres vérifications en tant que requêtes SPARQL. Par exemple, certaines ontologies peuvent catégoriser une classe dépourvue de définition textuelle comme une erreur, tandis que d’autres peuvent catégoriser cela comme un avertissement. L’un de nos objectifs est de converger vers un profil standard qui soit le plus utile possible pour l’ensemble de toutes les ontologies de la bibliothèque OBO, en encourageant l’adoption de contrôles de contrôle de qualité communs.

Repair

Bien que la plupart des problèmes soulevés par ‘validate’ et ‘report’ doivent être résolus manuellement, ROBOT fournit également une commande ‘repair’ qui peut résoudre automatiquement certains problèmes. L’implémentation actuelle fusionnera les annotations sur les axiomes en double et mettra à jour les références aux classes obsolètes lorsqu’elles seront annotées avec un remplacement suggéré. Nous avons l’intention d’étendre la « réparation » à un plus large éventail de problèmes courants pour lesquels la solution correcte est claire.

Développement de l’ontologie par modèle

Le ROBOT fournit un système de génération de termes d’ontologie piloté par modèle. Les utilisateurs ont également la possibilité de brancher leur propre système de génération de termes dans leur flux de travail, tel que les modèles de conception Dead Simple OWL (DOS-DPs).

Une énorme quantité de données est stockée dans des feuilles de calcul et des bases de données, et les formats tabulaires sont bien adaptés à de nombreux types de données. La commande « modèle » du ROBOT permet aux utilisateurs de convertir des données tabulaires au format RDF/ OWL. Un modèle de ROBOT est simplement un fichier de valeurs séparées par des onglets (TSV) ou des valeurs séparées par des virgules (CSV) avec certaines conventions spéciales, qui sont décrites dans la documentation du modèle de ROBOT.

Ces modèles peuvent être utilisés pour le développement d’ontologie modulaire. Les feuilles de calcul de modèle peuvent être maintenues dans le référentiel de code source de l’ontologie et, au lieu de modifier directement le fichier d’ontologie, les développeurs modifient les lignes de la feuille de calcul qui correspondent aux termes de l’ontologie. La commande ’template’ est ensuite utilisée pour générer un module de l’ontologie, qui est inclus en tant qu’instruction d’importation dans la version des éditeurs de l’ontologie et fusionné pendant le processus de publication.

Workflows

Un workflow consiste en un ensemble de tâches coordonnées par un système de workflow. Les flux de travail d’ontologie consistent en des tâches telles que l’exécution de contrôles QC, la création de modules d’importation, le raisonnement sur les ontologies et la génération de divers produits de publication d’ontologie.

Le ROBOT lui-même n’est pas un gestionnaire de flux de travail, bien qu’il permette d’enchaîner plusieurs commandes en une seule commande longue. Lors de l’enchaînement de commandes de ROBOT, l’ontologie de sortie d’une commande est transmise directement en entrée à la commande suivante. Par exemple, le chaînage peut être utilisé pour remplacer deux commandes qui fusionnent des ontologies puis raisonnent sur le produit fusionné :

`robot mergeinputinput ont-1.owlinputentrée ont-2.owl mergedsortie fusionnée.hibou.

raison du robot –entrée fusionnée.hibououtputsortie raisonnée.hibou`.

Au lieu de créer le produit fusionné et d’exécuter ‘reason’ dessus, cela peut être fait en une seule commande:

`robot mergeinputinput ont-1.owlinputentrée ont-2.owl reasonoutput sortie raisonnée.hibou`.

L’avantage clé du chaînage est que les ontologies n’ont pas besoin d’être sérialisées et analysées entre chaque étape; le même objet ontologie de l’API OWL est maintenu en mémoire et passé à travers la chaîne de commandes du ROBOT. Pour les grandes ontologies, le chaînage peut grandement améliorer les performances du ROBOT.

Comme les commandes de ROBOT peuvent être exécutées sur la ligne de commande, un certain nombre de systèmes de flux de travail différents peuvent être utilisés. Nous soulignons l’utilisation de GNU Make, qui est généralement utilisé pour compiler des logiciels. Un Makefile consiste en un ensemble de règles utilisées pour créer des « cibles ”. Dans le développement d’une ontologie, le fichier Makefile est utilisé pour des tâches automatisées, telles que la préparation d’une ontologie pour la publication. Dans ce cas, les cibles sont généralement des fichiers d’ontologie. Les  » recettes  » des règles sont des commandes système de type Unix, exécutées par la commande ‘make’.

Les commandes de ROBOT peuvent être utilisées comme « recettes » pour créer les ”cibles ». Un flux de travail typique n’utilisera pas les 19 commandes du ROBOT. Par exemple, tous les projets d’ontologie ne peuvent pas utiliser de modèles de ROBOTS et, par conséquent, tous les flux de travail de publication ne doivent pas inclure la commande ‘template’. Les développeurs d’ontologie peuvent décider quelles commandes sont nécessaires pour exécuter la version et créer un flux de travail autour de ces commandes. La figure 1 montre une manière standard de combiner une sélection de commandes de ROBOT pour un flux de travail de publication.

Le flux de travail de libération du ROBOT. Un flux de production typique utilisant un ROBOT. Le fichier d’édition d’ontologie ONT-edit.owl est d’abord vérifié en tant que contrôle de qualité avec le ROBOT ‘verify’. Ensuite, des fichiers texte contenant des listes de termes d’ontologie externes dans le répertoire imports sont utilisés pour régénérer les modules d’importation à l’aide de ‘extract’, garantissant ainsi que les importations sont à jour. ONT-modifier.owl est ensuite passé par une série de commandes de ROBOT (‘reason’, ‘relax’, ‘reduce’ et ‘annotate’) pour générer la libération, ONT.hibou. Enfin, ONT.owl est converti au format OBO

Tout d’abord, des contrôles de contrôle qualité sont effectués sur la version de l’ontologie des éditeurs avec ’report‘ ou ’verify‘. Ceux-ci recherchent des classes équivalentes, des espaces de fin dans les annotations, des auto-références, une syntaxe de référence croisée incorrecte et des étiquettes manquantes. Les résultats sont enregistrés dans un répertoire ‘reports/’ spécifié. S’il y a des violations au niveau de l’ERREUR, la tâche échouera et écrira les violations dans une table afin qu’elles puissent être facilement identifiées. Cette étape permet aux développeurs de voir rapidement si de nouvelles modifications ont introduit des problèmes au sein de l’ontologie et de les corriger avant de les publier.

En supposant que l’étape initiale de contrôle QC s’est terminée avec succès, l’étape suivante consiste à créer les modules d’importation. Le ROBOT ‘extract’ est exécuté pour chaque entrée dans une liste d’importations, qui ont des fichiers de termes correspondants (pour l’ensemble de semences) dans le répertoire ‘imports/’. Cela crée tous les modules d’importation dans le même répertoire ‘imports/’. Cela garantit que lorsqu’une ontologie est publiée avec des termes externes, tous les termes externes sont à jour avec les versions publiées des ontologies sources. La publication de termes externes obsolètes peut causer de la confusion, car le terme affichera à la fois les anciens et les nouveaux détails dans les services de recherche d’ontologie tels que Ontobee et le service de recherche d’ontologie. Des contrôles QC supplémentaires peuvent être exécutés sur l’ontologie complète avec des importations à l’aide de la commande ‘verify’ ou en exécutant à nouveau ‘report’.

Enfin, les principaux produits de version sont créés: le fichier OWL et le fichier OBO. Pour créer la version OWL, le fichier des éditeurs est passé par une série de commandes de ROBOT enchaînées: ‘reason’, ‘relax’, ‘reduce’ et ‘annotate’. Cette série de commandes permet de s’assurer que l’ontologie publiée est à la fois facile à parcourir et à comprendre, ainsi qu’exempte d’axiomes redondants. Si l’une de ces commandes échoue, le processus Make se terminera par le message d’erreur correspondant. Par exemple, si une ontologie est incohérente, l’étape « raison » échouera. Enfin, la commande ’annoter’ ajoute la version IRI aux métadonnées de l’ontologie. Ce fichier OWL est ensuite converti au format OBO, auquel cas toutes les cibles sont copiées dans un répertoire de version daté.

Le Kit de développement d’ontologie

Créer un Makefile pour coordonner toutes ces étapes peut être difficile. Nous facilitons cela pour les développeurs d’ontologie en fournissant un kit de développement d’ontologie (ODK). Cela peut être utilisé pour créer un référentiel GitHub suivant une mise en page standard, avec un Makefile standard suivant le flux de travail détaillé ci-dessus. Le référentiel GitHub résultant sera également automatiquement configuré pour exécuter les étapes de validation (telles que « rapport ») du flux de travail via Travis CI. Le flux de travail peut également être exécuté à l’aide de Docker avec des conteneurs ODK publiés sur Dockerhub. Cela permet une exécution facile des flux de travail sur l’ordinateur local d’un développeur d’ontologie, avec Travis CI, ou via des outils de construction évolutifs tels que Jenkins.

ODK s’appuie sur ROBOT et démontre l’utilité du ROBOT, mais une discussion complète dépasse le cadre de cet article.