# Méthode d'adaptation d'une ontologie d'application : cas des expérimentations agronomiques

Catherine Roussey, Anne Tireau, Pascal Neveu

► To cite this version:

Catherine Roussey, Anne Tireau, Pascal Neveu. Méthode d'adaptation d'une ontologie d'application : cas des expérimentations agronomiques. 36. Journées francophones d'Ingénierie des Connaissances (IC), AFIA- Association Française d'Intelligence Artificielle, Jul 2025, Dijon, France. pp.73-79. hal-05142985

HAL Id: hal-05142985

https://hal.inrae.fr/hal-05142985v1

Submitted on 3 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Méthode d'adaptation d'une ontologie d'application : cas des expérimentations agronomiques

Catherine Roussey¹, Anne Tireau¹, Pascal Neveu¹

¹ MISTEA, Université de Montpellier, INRAE, Institut Agro, Montpellier

prenom.nom@inrae.fr

## Résumé

Nous présentons une méthode pour adapter une ontologie d'application afin d'améliorer sa qualité pour qu'elle réponde aux exigences d'ingénierie des connaissances : inférence, alignement avec d'autres ontologies, cohérence, etc. Les ontologies d'application sont majoritairement utilisées dans les systèmes d'information et n'ont pas pour vocation à être partagées directement dans une large communauté. Nous avons ainsi identifié plusieurs activités pour adapter une ontologie d'application dont la principale est la construction/utilisation d'une ontologie du domaine. Nous avons appliqué notre méthode sur une ontologie créée il y a plus de 10 ans dans le domaine de la gestion des données d'expérimentations agronomiques.

## Mots-clés

adaptation d'ontologie, retro-conception d'ontologie, restructuration d'ontologie, ingénierie directe d'ontologie, ontologie d'application, ontologie de domaine, ontologie d'expérimentations agronomiques.

## Abstract

We present a method for reengineering an application ontology in order to improve its quality in order to meet current knowledge engineering requirements : inferences, ontologies alignment, coherency, ... Application ontologies are used in existing information systems and are not directly intended to be shared by a large community. We have therefore identified several activities to adapt an application ontology. The main one being the usage or the construction of a domain ontology. The domain ontology is aligned with reference ontologies. We applied our method to an ontology created over 10 years ago in the domain of agronomic experimentation data management.

## Keywords

ontology reengineering, ontology reverse engineering, ontology restructuring, forward engineering ontology, application ontology, domain ontology, agronomic experimentation ontology.

## 1 Introduction

Une ontologie d'application offre le niveau de spécificité le plus fin, c'est-à-dire qu'elle est dédiée à un champ d'ap-

plication précis à l'intérieur d'un domaine. Ainsi, elle décrit le rôle particulier des entités de l'ontologie de domaine dans ce champ. Par exemple, les spécifications d'un avion Airbus constitue une ontologie d'application précisant les concepts généraux pouvant provenir d'une ontologie de domaine de l'aéronautique. Une ontologie d'application est aussi un artefact sémantique développé pour répondre aux besoins d'une application [8]. Les ontologies d'application sont utilisées comme modèle de données pour les bases de graphes, impliquant ou non des inférences, ou comme modèle de données unifié pour interroger des sources de données hétérogènes [19]. Les ontologies d'application existent depuis le début des systèmes à base de connaissances, car elles constituent le cœur de ces systèmes. En revanche, elles sont souvent partagées uniquement dans la communauté utilisatrice, les conceptrices et concepteurs du système. Par conséquent, elles ne sont pas nécessairement publiées sur le Web. Dans nos travaux nous avons à notre disposition une ontologie d'application, formalisée dans les technologies du Web sémantique, qui existe depuis plus de 10 ans. Cette ontologie permet de gérer les données d'expérimentations agronomiques [12]. Elle n'intègre pas toutes les bonnes pratiques et toutes les dernières évolutions de la communauté d'ingénierie des connaissances : modularité des ontologies, alignement entre ontologies, publication sur le Web. Nous nous sommes engagés dans une démarche pour adapter cette ontologie d'application afin qu'elle intègre les éléments d'une ou plusieurs ontologies de domaine, qu'elle puisse être alignée avec d'autres ontologie de référence, et qu'elle permette de réaliser des inférences. Ainsi, nous esperons que la communauté utilisatrice tire rapidement profit de cet effort en structurant notre démarche. Dans ce sens, nous proposons une méthode capable d'adapter une ontologie pour améliorer sa qualité.

## 2 Méthodes d'adaptation d'ontologies

A notre connaissance il existe peu de travaux sur l'adaptation (reengineering) d'ontologies. Dans [6] l'adaptation d'une ontologie est définie comme le processus composé de 3 activités : 1) la rétro-conception (reverse engineering) reconstruit le modèle conceptuel d'une ontologie implémentée, 2) la restructuration transforme le modèle en
un nouveau modèle plus adéquat et 3) l'ingénierie directe (forward engineering) implémente le nouveau modèle dans un langage ontologique (identique ou différent de celui de l'ontologie initiale) pour produire une nouvelle ontologie. La méthode proposée a été utilisée pour adapter une ontologie des unités existantes en fonction d'un nouveau besoin [7]. Ce travail a été poursuivi dans la méthodologie Neon avec plusieurs scénarios : 4 «réutilisation et adaptation de ressources ontologiques existantes», 5 «réutilisation et fusion de ressources ontologiques existantes», 6 «réutilisation, fusion et adaptation de ressources ontologiques existantes»[17]. Dans les scénarios incluant l'adaptation, les 3 activités précédentes (rétro-conception, restruc-turation, ingénierie directe) sont toujours présentes. Des niveaux d'abstraction sont ensuite ajoutés : spécification, conceptualisation, formalisation, implémentation sur les-quels les changements vont être appliqués. Ce qui produit des parcours incluant les 3 activités appliquées sur chaque niveau d'abstraction sélectionné.

## 3 Méthode d'adaptation d'une ontologie d'application

Nous appliquons les étapes des activités présentées dans l'état de l'art, en ajoutant une activité de construction ou d'utilisation d'une ontologie de domaine. De plus, nous proposons de réorganiser les activités pour adapter une ontologie d'application. La différence étant que l'ontologie d'application est utilisée dans un système d'information en activité. Sa publication sur le Web est motivée par une vo-lonté de transparence. De plus, nous souhaitons garder le système opérationnel pendant ce processus de ré-ingénierie. Notre approche se décompose en trois grandes activités schématisées dans la figure 1 :

- analyse de l'ontologie d'application et de sa docu-mentation pour identifier les différents problèmes et à quel niveau d'abstraction ces difficultés sont appa-rues (spécification, conceptualisation, formalisation et implémentation).

- construction/utilisation d'une ontologie de domaine ayant une couverture similaire à celle de l'ontolo-gie d'application. Ainsi elle servira de support pour faire évoluer et/ou corriger l'ontologie d'application de façon itérative.

- refonte de l'ontologie d'application en vérifiant que le système reste opérationnel, ce qui implique que notre utilisation de l'ontologie de domaine soit adaptée en fonction du comportement du système.

<figure><img src="image_2.png" /><figcaption>FIGURE 1 – Présentation générale de la méthode</figcaption></figure>

### 3.1 Analyse de l'ontologie d'application

L'activité d'analyse correspond à l'activité de rétro-conception de l'état de l'art et se compose de 3 étapes

comme présenté dans la figure 2.

<figure><img src="image_3.png" /><figcaption>FIGURE 2 – Les étapes de l'analyse de l'ontologie d'application</figcaption></figure>

**A.1 Recherche de la documentation** La documentation est constituée d'un ensemble de ressources incluant : les do-cuments de spécification, les sources d'information utili-sées au cours de la conception de l'ontologie, les modèles conceptuels et les différentes versions des fichiers sources (par exemple RDF/XML, OWL/XML).

**A.2 Évaluation** L'objectif de cette opération est d'identi-fier les évolutions nécessaires, les manques de l'ontologie à tous les niveaux (spécification, conception, formalisation, implémentation). Durant cette étape, des outils d'évalua-tion doivent être utilisés comme par exemple un raison-neur si le système nécessite des inférences ou d'autres ou-tils d'évaluation de la qualité des ontologies comme OOPS [14] ou O'FAIRe [2]. Cette étape intègre aussi l'identifi-cation des bonnes pratiques de modélisation (les patrons de conception) et des mauvaises pratiques de modélisation (anti-pattern) présentes dans l'ontologie d'application. Le groupe de personnes en charge de cette étape doit être dif-férent de l'équipe de conception initial de l'ontologie d'ap-plication.

**A.3 Consolidation du modèle conceptuel** L'objectif de cette étape est de concevoir, si il n'est pas disponible ou pas à jour dans la documentation, le modèle conceptuel ac-tuel de l'ontologie d'application. Ainsi, il sera possible ul-térieurement de le faire évoluer en fonction des résultats de l'étape précédente (cf C.4 et R.2). Dans cette étape, des outils de conception de diagramme doivent être utilisés, en préférant des outils d'édition collaborative.
## 3.2 Conception/utilisation de l'ontologie de domaine

L'ontologie de domaine est centrée sur la formalisation des connaissances du domaine, alors que l'ontologie d'application peut contenir des connaissances propres au fonctionnement du système, telles que les interactions avec les utilisatrices et utilisateurs. A ce titre, l'ontologie d'application utilisée dans un système n'a pas forcément vocation à être publiée sur le Web. Il se peut qu'elle ne soit pas une spécification directe d'une ontologie de domaine existante. Ce cas se produit plus spécifiquement lorsque l'ontologie d'application a été créée à partir d'une feuille blanche. Nous recommandons de construire une ontologie de domaine distincte de l'ontologie d'application. Ainsi, l'ontologie de domaine sera publiée sur le Web et servira de documentation pour l'ontologie d'application. Cette activité n'est pas identifiée directement dans l'état de l'art. L'équipe de conception de cette nouvelle ontologie peut intégrer les autrices et les auteurs initiaux de l'ontologie d'application ou de nouvelles personnes.

<figure><img src="image_4.png" /><figcaption>FIGURE 3 – Les étapes de la conception de l'ontologie de domaine</figcaption></figure>

La figure 3 présente les étapes de cette activité. Cette activité reprend les étapes d'une méthode de conception d'ontologie comme Linked Open Term [13] ou Acimov [9] en prenant comme base les résultats de l'analyse de l'ontologie d'application précédente.

**C.1 Spécification** Les spécifications de l'ontologie d'application sont reformulées pour se concentrer sur les spécifications des connaissances du domaine (de quoi le système va parler) et supprimer les spécifications liées au besoin de l'application (interface graphique, gestion des utilisatrices et utilisateurs, etc...).

**C.2 Recherche de ressources sémantiques** Pour être à jour avec l'état des connaissances actuelles, une nouvelle recherche est effectuée pour identifier des ontologies du domaine proche, des ontologies noyau, des thésaurus, des terminologies voire des standards d'échange de données. L'accent est mis sur l'identification des patrons de concep-

tion à réutiliser en vue de corriger les mauvaises pratiques de modélisation identifiées précédemment.

**C.3 Normalisation de la terminologie** Cette étape sélectionne un terme, comme label préféré, non équivoque pour chaque élément de l'ontologie afin de lever les ambiguïtés identifiées dans l'analyse. Un élément de l'ontologie peut avoir plusieurs labels par langue mais un seul label préféré. Et inversement un label préféré ne peut être associé qu'à un seul élément de l'ontologie. Les ressources identifiées dans l'étape précédente sont utilisées pour poser des définitions en langue naturelle à chaque élément de l'ontologie du domaine. Les recommandations actuelles demandent une définition de type aristotélicienne, c'est à dire qui prend en compte le voisinage de l'élément. Une définition indique les points communs avec les parents et les différences avec les frères<fnref n="1" />.

**C.4 Conception du modèle conceptuel** Au fur et à mesure de la normalisation, le modèle conceptuel initial de l'ontologie d'application est modifié pour représenter celui de l'ontologie de domaine en fonction des ajouts et des retraits. Cette étape est effectuée à l'aide d'un langage graphique et d'un outil dédié en suivant les questionnements de l'équipe de conception. Cette étape itérative se fait en collaboration avec l'équipe de conception du système d'information et leur communauté utilisatrice de ce système.

**C.5 Formalisation** Une fois le modèle conceptuel suffisamment avancé, l'ontologie de domaine est formalisée dans un des langages du Web sémantique (OWL par exemple). Le modèle est ainsi traduit à l'aide d'outils dédiés comme Protégé [11] ou à partir de fichiers tabulés qui seront transformés à l'aide d'outils comme Ontotext Refine<fnref n="2" /> ou OpenRefine<fnref n="3" />.

**C.6 Publication sur le Web** Cette étape inclut le fait de donner un identifiant pérenne à l'ontologie, de publier son code et sa documentation sur le Web à l'aide d'URIs déréférencables, de la rendre disponible dans un portail et de lui associer un dépôt GIT pour permettre à sa communauté utilisatrice de suivre son évolution et d'informer d'erreurs potentielles<fnref n="4" />.

## 3.3 Refonte de l'ontologie d'application

La refonte a pour but de profiter des outils et des ressources de l'état de l'art, tout en améliorant de façon itérative l'ontologie d'application. Cette activité prend comme support l'ontologie de domaine, en lui ajoutant les éléments nécessaires au fonctionnement du système (notamment les interactions avec les utilisatrices et utilisateurs ou des agents lociciels). Cette activité est une évolution de l'activité d'ingénierie directe de l'état de l'art (voir section 2). Elle doit forcément impliquer les conceptrices et concepteurs initiaux

<footnote n="1">1. INRAE (2024), Rédiger une définition, quelques clés, Vocabulaires Ouverts@INRAE, https://vocabulaires-ouverts.inrae.fr/rediger-definition-quelques-cles/</footnote>

<footnote n="2">2. https://www.ontotext.com/products/ontotext-refine/</footnote>

<footnote n="3">3. https://openrefine.org/</footnote>

<footnote n="4">4. https://vocabulaires-ouverts.inrae.fr/publier-vocabulaire/</footnote>
de l'ontologie d'application. Il est préférable d'impliquer aussi l'équipe de conception de l'ontologie de domaine. La figure 4 présente les différentes étapes.

<figure><img src="image_5.png" /><figcaption>FIGURE 4 – Les étapes de la refonte de l'ontologie d'application</figcaption></figure>

### R.1 Modularisation des spécifications
Cette étape réorganise les spécifications de l'ontologie d'application en module et ordonnancement des modules à la manière de la méthode Acimov [9].

### R.2 Conception et formalisation d'un module
Cette étape se concentre d'abord sur la conception et formalisation d'un module en travaillant d'abord sur la hiérarchie des classes. La relation hiérarchique a étudiée est d'abord la relation de subsomption comme `rdfs:subClassOf` puis les relations de méronymie comme `foaf:member` ou `dcterms:hasPart`. Cette étape inclut de vérifier la cohérence des définitions logiques des classes (axiomes) et l'alignement avec les classes des ontologies externes.

### R.3 Mise en conformité des codes du système
Cette étape implique de faire des tests unitaires du nouveau module puis de réaliser les tests d'intégration du module dans le système. Il se peut que les tests impliquent des changements dans le module qui doivent être reportés au niveau de l'ontologie de domaine. Comme le préconise Acimov, l'équipe itère ensuite sur le module suivant (itération de R.2 et R.3) jusqu'à la fin des spécifications.

## 4 Etude de cas sur l'ontologie OESO

PHIS est un système d'information piloté par des ontologies, qui est basé sur la suite logicielle OpenSILEX [12]. Il est conçu pour stocker, tracer, gérer et visualiser les données hétérogènes produites par les plateformes de phénotypage végétal à haut-débit : données phénotypiques (images, courbes de croissances des plantes, spectres, mémes manuelles), données environnementales (sol, atmosphère), données génétiques (taxonomie scientifique, lignées) et données sur la conduite des cultures (irrigations, traitements phyto, ...). Ces données sont hétérogènes sur plusieurs dimensions : plusieurs échelles struc-

turelles (du gène à la parcelle) et temporelles (mesures à la minute, mesures annuelles) provenant d'environnements variés (champ, serre, exploitation agricole). Pour générer ces données, l'architecture OpenSILEX combine une gestion des données de flux par un système NoSQL (MongoDB), avec une gestion des données «statiques» par une base de graphes (RDF4J). Les données de flux ont besoin d'être contextualisées par des métadonnées décrivant les ressources biologiques, les capteurs, les plateformes, les types de mesures, ... L'ontologie d'application qui struture la base de graphes est intitulée «Experimental Scientific Objects Ontology» (OESO). Elle a été créée en 2012 en s'inspirant des éléments de l'ontologie des expérimentations scientifiques EXPO [16]. EXPO est une ontologie générique datant de 2006 qui utilise SUMO. EXPO n'est pas disponible en téléchargement. Elle n'est pas orientée sur la structuration des données mais plus sur la documentation d'une expérimentation. Notre objectif est de remettre à jour OESO en fonction des nouvelles ontologies.

Actuellement, nous avons déjà réalisé l'activité d'analyse de l'ontologie OESO et commencé l'activité de conception de l'ontologie de domaine. Les résultats seront disponibles sur un dépôt GIT.

### 4.1 Analyse de OESO

Plusieurs versions de OESO sont disponibles dans des répertoires GIT privés. Initialement, l'ontologie s'intitulait Ontology For Experimental Phenotyping Object (OEPO)<fnref n="5" />. La dernière version (1.2.1) de OESO est visible sur Web-Protégé pour permettre aux développeuses et développeurs de proposer des modifications. Nous avons centré notre analyse sur cette version.

#### A.1 Recherche de la documentation
Aucun document ne décrit l'ensemble des spécifications de OESO.

Différents rapports (livrables de projet, thèse, rapports de stage...) contiennent des sous-parties du modèle conceptuel de OESO. Un modèle conceptuel complet combinant les éléments NoSQL et les éléments de OESO a été construit à l'aide de draw.io en suivant le formalisme de WebVOWL. Il a été diffusé sous un format poster.

OESO est formalisée en OWL. OESO n'importe aucune ontologie directement, en revanche elle utilise des éléments provenant d'autres ontologies (PROV, FOAF, OA, Time, Vcard, DCTERMS, SKOS, ORG). OESO se comporte de 126 classes, 60 propriétés objets, 87 propriétés de type de données, 16 propriétés d'annotations et 160 individus. Elle inclut deux modules Ontology of Experimental Events (OOEV) et security. Le module OEEV définit une hiérarchie des évènements. Auparavant ce module existait comme ontologie à part entière dans les versions précédentes de OESO. Enfin, le module security permet de gérer les droits des utilisatrices et utilisateurs.

#### A.2 Evaluation
Pour analyser OESO nous avons utilisé l'outil OOPS. Comme le montre la Figure 5 : 10 types d'écueils (Pitfalls) différents ont été détectés par cet outil. Les plus importants en nombre sont : les 216 éléments de

<footnote n="5">5. https://agroportal.lirmm.fr/ontologies/OEPO</footnote>
l'ontologie non documentés P08; les 55 propriétés objets définies sans domaine et codomaine. Ces propriétés objets n'ont pas de propriétés inverses définies. Les écueils les plus intéressants concernent les 2 classes qui ont le même label et les classes équivalentes détectées.

<figure><img src="image_6.png" /><figcaption>FIGURE 5 – Résultat de l'évaluation de OOPS</figcaption></figure>

Une personne experte en ingénierie des connaissances a aussi parcouru l'ensemble de l'ontologie manuellement pour détecter les différents écueils. Cette ontologie ayant été développée par un collectif sur le long terme, il est compréhensible de trouver des incohérences telles que : P02 l'existence de classes ayant des labels synonymes, P07 la fusion de concepts dans une même classe. 7 écueils non mentionnés dans la littérature ont été détectés.

- L'utilisation d'un patron de conception structurel du développement logiciel (le patron composite), qui induit de mauvaises propriétés logiques s'il est ainsi formalisé.

- L'utilisation des éléments de syntaxe RDF comme élément de l'ontologie. Par exemple, la classe `rdf:Bag` a été utilisée pour représenter des collections d'entités.

- L'utilisation de propriété d'annotation dans la déclaration de contraintes. Par exemple, la partie d'axiome `<label min 1 xsd:string> exprime la contrainte qu'un label soit toujours associé à un élément de l'ontologie donné.

- Le mauvais usage de la relation de spécialisation entre classes (`rdfs:subClassOf`) à la place d'une relation de méronymie (composition).

- L'absence de classes soeurs dans une hiérarchie incomplète, ou la réorganisation de la hiérarchie. Par exemple, la hiérarchie des documents (`oeso:Document`) contient des classes `oeso:Multimedia`, `oeso:InteractiveResource`, `oeso:Dataset` et `oeso:WebSite`. La hiérarchie des fichiers (`oeso:Datafile`) contient les classes `oeso:Image` et `oeso:Archive`.

- A l'inverse des classes ont des labels laissant imaginer qu'elles ont un lien entre elles qui n'existent pas actuellement dans l'ontologie. Par exemple, la classe `oeso:Group` n'a aucun lien avec les classes `oeso:VariablesGroup` et `oeso:GermplamsGroup`.

- Certains éléments d'ontologie externe utilisés dans OESO sont obsolètes.

En résumé, des relations de méronymie entre classes ont été mal formalisées dans OESO. Un autre problème vient du fait de la réutilisation d'éléments venant d'ontologies externes ayant des labels similaires (`foaf:Agent` et `prov:Agent`). Ceci s'explique par le fait que les concepts et concepteurs ont voulu inclure différentes ontologies au cours du temps sans vérifier la cohérence globale. L'évaluation manuelle a aussi permis de détecter un nouveau patron de conception ontologique : le patron liant un organisme vivant à sa description taxonomique et/ou génétique décrite dans une ressource génétique (GermBank). Pour finaliser, chaque élément de l'ontologie a été annoté sur WebProtégé pour indiquer son statut : à corriger, en cours ou valide. La figure 6 montre un extrait de cette étape.

### A.3 Consolidation du modèle conceptuel
Le modèle construit à l'aide de draw.io correspond à la version actuelle de OESO. Vu sa taille importante, il est envisagé de le présenter en plusieurs sous-parties orientées sur un besoin explicite.

## 4.2 Conception de l'ontologie de domaine

Nous allons définir une ontologie du domaine de l'expérimentation agronomique intitulée «Experiment on Living Organisms in Agriculture» (ELOA).

### C.1 Spécification
Vu l'absence de spécification actuelle disponible, une série de questions de compétences sont en cours de rédaction pour mieux définir les besoins de ELOA. Ces spécifications enrichissent les questions de compétences de REPRODUCE-ME [15]. Les besoins et les éléments de OESO qui sont en lien avec le fonctionnement du système PHIS (la gestion des utilisatrices et utilisateurs, la gestion des interfaces et des fichiers NoSQL) ont été identifiés et supprimés.

### C.2 Recherche de ressources sémantiques
Depuis quelques années, plusieurs ontologies du domaine de l'expérimentation, en général, et de l'expérimentation agronomique en particulier, ont vu le jour. Dans l'écosystème de BFO, nous pouvons citer :

- Experimental Factor Ontology (EFO)<fnref n="6" /> est utilisé pour annoter les types de variables scientifiques présents dans la base EBO.

- Ontology for Biomedical Investigations (OBI) [4] décrit les études cliniques et biomédicales.

- Agronomy Ontology (AgrO)<fnref n="7" /> est utilisé pour annoter les tableaux constituant les carnets de terrains des expérimentations de semenciers.

Dans l'écosystème de PROV, nous avons des ontologies plus génériques du domaine de l'expérimentation : P-Plan [5] étend Prov pour décrire les méthodes et les variables utilisées comme entrée/sortie de ces méthodes. L'ontologie « workflow description vocabulary»(wfdesc) intègre les

<footnote n="6">6. https://www.ebi.ac.uk/efo/</footnote>

<footnote n="7">7. https://agroportal.lirmm.fr/ontologies/AGRO</footnote>
ontologies Object Reuse and Exchange (ORE), Annota-
tion Ontology (AO) et PROV pour décrire les traitements
des données scientifiques [3]. REPRODUCE-ME [15] in-
tègre PROV, P-Plan et la Time ontologie pour décrire les
expérimentations, leurs protocoles et des données d'en-
trées/sorties. Plus récemment un nouveau patron de concep-
tion ontologique sur les expérimentations a été proposé
dans [10]. Dans le domaine des expérimentations agrono-
miques il existe plusieurs standards d'échange de données.
Le plus connu est le format ICASA [18]. Le modèle de
données décrit dans ISA spécification est aussi très utilisé.
Enfin il existe un standard décrivant les bonnes pratiques
de conduites des expérimentations des produits phytosani-
taires produit par Organisation Européenne et Méditerran-
énéenne pour la Protection des Plantes (OEPP/EPPO) [1].

**C.3 Normalisation de la terminologie** Comme indiqué dans l'étape d'évaluation, plusieurs termes synonymes ou proches ont été utilisés pour définir des classes qui n'ont pas de liens entre elles. Un travail de normalisation et de définition en langue naturelle est en cours. Il s'est avéré qu'après discussions avec les développeuses et développeurs, les classes qui partagent des labels identiques ont en fait des usages bien différents. Par exemple, le *foaf:Agent* est utilisé pour décrire les utilisatrices et utilisateurs du système PHIS, alors que le *prov:Agent* décrit les personnes impliquées dans les expérimentations agronomiques.

C.4 Conception du modèle conceptuel Nous avons décidé de spécialiser l'ontologie PROV pour décrire les expéri- mentations agronomiques. A partir du texte du standard de OEPP/EPPO, et des terminologies extraites de ICASA et ISA spécification nous allons définir les classes et spéci- fier leur lien de spécialisation avec les classes de PROV. Nous allons aussi essayer de nous appuyer sur l'ontologie AgrO (en utilisant des alignements SKOS) pour conserver une compatibilité avec BFO.

5 Discussion et conclusion

Une ontologie d'application en production est développée
avec une pression constante de la communauté utilisatrice.
Ce type d'ontologie, par exemple OESO, est développé par
des collectifs ayant souvent des niveaux de compétence
en ingénierie des connaissances hétérogènes. Compte tenu
des deux points cités précédemment il est évident qu'un
collectif exploitant des ressources ontologiques pour une
application s'expose à des risques importants d'apparition
d'écueils tout au long de sa vie. Ainsi nous avons proposé
une méthode d'adaptation de l'ontologie d'application pour
détecter et gérer ces difficultés.

Un des problèmes les plus difficiles à gérer dans une onto-
logie d'application en cours d'exploitation est de gérer en
continue les évolutions des ontologies externes réutilisées.
Nous n'avons pas encore trouver une solution acceptable.

Remerciements

Les auteurs tiennent à remercier l'ensemble de l'équipe
OpenSILEX. Ces travaux ont été financé en partie par
le projet CASDAR Connaissances 2024 «Standardiser les

données expérimentales et techniques pour faciliter leur
réutilisation et accélérer l'innovation et le développe-
ment agricole : application aux travaux sur les biosolu-
tions»(STAR) financé par FranceAgriMer et le projet ANR
«Infrastructure Biologie Santé» PHENOME-EMPHASIS
project (ANR-11-INBS-0012) financé par l'Agence Natio-
nale de la Recherche et le Programme d'Investissements
d'Avenir (PIA).

Références

[1] Pp1/152(4) : Design and analysis of efficacy evalua-
tion trials. Technical Report 3, OEPP/EPPO, 2012.

[2] Emna Amdouni, Syphax Bouazzouni, and Clement Jonquet. O'faire makes you an offer : metadata-based automatic fairness assessment for ontologies and semantic resources. *International Journal of Metadata, Semantics and Ontologies*, 16(1) :16-46, 2022.

[3] Khalid Belhajjame, Jun Zhao, Daniel Garijo, Matthew Gamble, Kristina Hettne, Raul Palma, Eleni Mina, Oscar Corcho, José Manuel Gómez-Pérez, Sean Bechhofer, et al. Using a suite of ontologies for preserving workflow-centric research objects. *Journal of Web Semantics*, 32 :16–42, 2015.

[4] Ryan R Brinkman, Mélanie Courtot, Dirk Derom, Jennifer M Fostel, Yongqun He, Phillip Lord, James Malone, Helen Parkinson, Bjoern Peters, Philippe Rocca-Serra, et al. Modeling biomedical experimental processes with obi. In *Journal of biomedical semantics*, volume 1, pages 1–11. Springer, 2010.

[5] Daniel Garijo Verdejo and Yolanda Gil. Augmenting prov with plans in p-plan : scientific processes as linked data. CEUR Workshop Proceedings, 2012.

[6] Asunción Gómez-Pérez, Mariano Fernández-López, and Oscar Corcho. *Ontological Engineering : with examples from the areas of Knowledge Management, e-Commerce and the Semantic Web*. Springer Science & Business Media, 2006.

[7] Asunción Gómez-Pérez and Ma Dolores Rojas-Amaya. Ontological reengineering for reuse. In Dieder Fensel and Rudi Studer, editors, *Knowledge Acquisition, Modeling and Management*, pages 139–156, Berlin, Heidelberg, 1999. Springer Berlin Heidelberg.

[8] Nicola Guarino. Understanding, building and using ontologies. *International journal of human-computer studies*, 46(2-3) :293–310, 1997.

[9] Fatma-Zohra Hannou, Victor Charpenay, Maxime Le-
françois, Catherine Roussey, Antoine Zimmermann,
and Fabien Gandon. The acimov methodology : agile
and continuous integration for modular ontologies and
vocabularies. In *MK 2023-2nd Workshop on Modular
Knowledge associated with FOIS 2023-the 13th Inter-
national Conference on Formal Ontology in Informa-
tion Systems*, 2023.

[10] Jacques Hilbey, Xavier Aimé, and Jean Charlet. Un patron de conception pour la modélisation onto-logique des paradigmes expérimentaux. In *34es*
<figure><img src="image_7.png" /><figcaption>FIGURE 6 – Extrait de OESO sur WebProtégé</figcaption></figure>