# Construction de Graphe de Connaissance à partir de Bases de Données Relationnelles Mémoire de fin d'étude de Master en Informatique Spécialité: Systèmes Intelligents et Multimédia sous la direction de Catherine Roussey

Lucry Maël Choumele Nandong

► To cite this version:

Lucry Maël Choumele Nandong. Construction de Graphe de Connaissance à partir de Bases de Données Relationnelles Mémoire de fin d'étude de Master en Informatique Spécialité: Systèmes Intelligents et Multimédia sous la direction de Catherine Roussey. Intelligence artificielle [cs.AI]. 2025. hal-05246611v2

HAL Id: hal-05246611

https://hal.inrae.fr/hal-05246611v2

Submitted on 21 Nov 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
UNIVERSITÉ NATIONALE DU VIETNAM, HANOÏ
ECOLE INTERNATIONALE

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

CHOUMÉLÉ NANDONG LUCRY MAËL

CONSTRUCTION DE GRAPHE DE
CONNAISSANCE À PARTIR DE BASES DE
DONNÉES RELATIONNELLES

XÂY DỰNG BIỂU ĐỒ KIẾN THỨC TỪ CƠ SỞ
DỮ LIỆU QUAN HỆ

Spécialité : Systèmes Intelligents et Multimédia

Code : 8480201.02

MÉMOIRE DE FIN D'ÉTUDE DE MASTER
EN INFORMATIQUE

HANOÏ-2025
UNIVERSITÉ NATIONALE DU VIETNAM, HANOÏ
ECOLE INTERNATIONALE

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

CHOUMÉLÉ NANDONG LUCRY MAËL

CONSTRUCTION DE GRAPHE DE
CONNAISSANCE À PARTIR DE BASES DE
DONNÉES RELATIONNELLES

XÂY DỰNG BIỂU ĐỒ KIẾN THỨC TỪ CƠ SỞ
DỮ LIỆU QUAN HỆ

PROGRAMME : SYSTÈMES INTELLIGENTS ET MULTIMÉDIA

CODE : 8480201.02

MÉMOIRE DE FIN D'ÉTUDE DE MASTER
EN INFORMATIQUE

Sous la direction de :

CATHERINE ROUSSEY, Chargé de recherche, INRAE / UMR

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

Catherine ROUSSEY

HANOÏ-2025
ATTESTATION SUR L'HONNEUR

Je déclare par la présente que ce mémoire a été réalisé par moi-même sous la
direction et la supervision de ROUSSEY CATHERINE; et que les travaux et les
résultats qu'il contient sont conformes à la réalité de l'auteur et respectent
l'éthique de la recherche. Les données et figures présentées dans ce mémoire sont
issues de mes propres analyses, commentaires et évaluations, issues de diverses
sources et sont dûment mentionnées dans la partie référence.

De plus, les autres commentaires, analyses et données utilisés par d'autres auteurs
et organisations ont été explicitement mentionnés.

J'assume l'entière responsabilité de toute fraude détectée dans mon mémoire.

Hanoi, 05/09/2025

Auteur

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

CHOUMELE NANDONG Lucry Maël
CHOUMÉLÉ NANDONG LUCRY MAËL

CONSTRUCTION DE GRAPHE DE
CONNAISSANCE À PARTIR DE BASES DE
DONNÉES RELATIONNELLES

XÂY DỰNG BIỂU ĐỒ KIẾN THỨC TỪ CƠ SỞ
DỮ LIỆU QUAN HỆ

PROGRAMME : SYSTÈMES INTELLIGENTS ET MULTIMÉDIA

CODE : 8480201.02

MÉMOIRE DE FIN D'ÉTUDE DE MASTER
EN INFORMATIQUE

Sous la direction de :

CATHERINE ROUSSEY, Chargé de recherche, INRAE / UMR
MISTEA, Montpellier

HANOÏ-2025
REMERCIEMENTS

Je souhaite exprimer toute ma gratitude à celles et ceux qui ont joué un rôle déterminant dans la réalisation de ce mémoire et dans l'ensemble de mon parcours académique.

Avant tout, je remercie chaleureusement Dr. Catherine ROUSSEY, chargé de recherche au laboratoire UMR MISTEA - INRAE et encadrant de mon stage, pour son accompagnement rigoureux, son implication constante et la confiance qu'elle m'a témoignée tout au long de ce projet. Ses conseils ont été aussi précieux sur le plan scientifique que sur le plan humain.

Je tiens également à remercier Madame Farzaneh KAZEMI POUR pour son orientation pertinente, son soutien technique et sa disponibilité. Son expertise a été d'un grand apport à la qualité de mon travail.

Je souhaite remercier #DigitAg pour le soutien financier apporté à ce travail, qui a permis de mener à bien ce projet.

Je souhaite également adresser mes remerciements les plus sincères à toute l'équipe du laboratoire UMR MISTEA - INRAE. Travailler dans un environnement aussi stimulant, solidaire et humainement riche a été une véritable chance. Ce laboratoire est bien plus qu'un lieu de recherche: c'est un espace d'échange où chacun partage ses connaissances, s'entraide et progresse aux côtés des autres. Merci à tous les membres du labo pour leur accueil, leur esprit d'équipe et leur disponibilité, qui ont rendu mon stage aussi formateur que motivant.

Je tiens également à exprimer ma reconnaissance au corps enseignant et administratif de l'Institut Francophone International (IFI) de l'Université Nationale du Vietnam à Hanoi, notamment au Dr. HO Tuong Vinh pour ses précieux conseils académiques. Je remercie également tous les camarades de la promotion SIM P26 pour leur solidarité et les moments enrichissants partagés durant ces deux années.

Je n'oublie pas de remercier du fond du cœur ma famille — mes parents, mes frères et sœurs, mes neveux et nièces — pour leur soutien indéfectible, tant sur le plan moral que financier, leur amour et leur confiance m'ont toujours porté, même à distance.

À toutes ces personnes qui ont contribué, chacune à leur manière, à faire de cette expérience un succès, je dis un immense merci.
# DÉDICACE

À la famille,

CHOUMELE,

Ce mémoire leur est dédié, en témoignage de mon amour, de ma reconnaissance et de la profonde influence qu'elle a eue sur ma vie. Puisse ce travail être pour elle une source de récompense, et un prolongement de leur héritage de foi, de savoir et de droiture.
Résumé

Face aux défis majeurs liés à la sécurité alimentaire, à la réduction des impacts
environnementaux et à l'adaptation de l'agriculture au changement climatique,
la valorisation des données issues d'expérimentations agronomiques devient un
enjeu stratégique. Ces données, issues de sources diverses telles que des capteurs,
des observations humaines ou des images satellites, sont souvent stockées sous
forme tabulaire, présentent plusieurs limites : redondances fréquentes, données
cachées, ce qui rend leur exploitation et partage difficile. Pour dépasser ces li-
mitations, une étape de modélisation s'est avérée indispensable. Elle permet de
clarifier les entités manipulées, leurs attributs, ainsi que les relations entre en-
tités. Le stage réalisé s'inscrit dans une problématique visant à développer une
méthode de transformation des modèles conceptuels de données générés à partir
de ces données en modèles conceptuels d'ontologies qui seront ensuite transfor-
més en ontologie. La démarche repose sur la traduction d'un Modèle Conceptuel
de donnée en UML, conçu avec l'outil Draw.io, en un Modèle Conceptuel d'On-
tologie en langage CHOWLK. Ce modèle est ensuite converti en ontologie OWL
grâce à l'outil CHOWLK converter, afin de structurer et de partager efficace-
ment les connaissances. L'approche adoptée est semi-automatique, elle combine
des étapes de traduction automatisée avec des phases de validation et d'en-
richissement manuel, garantissant ainsi la cohérence et la qualité des graphes
de connaissances générés. Ce travail contribue à renforcer l'operability des
données agronomiques et à soutenir le développement de systèmes d'information
intelligents pour l'agriculture de demain.

**Mots-clés** : Modèle Conceptuel de donnée, ontologie, UML, CHOWLK, Draw.io, Modèle Conceptuel d'Ontologie.
Abstract

Faced with the major challenges related to food security, the reduction of envi-
ronmental impacts and the adaptation of agriculture to climate change, the val-
orization of data from agronomic experiments becomes a strategic issue. These
data, from various sources such as sensors, human observations or satellite im-
ages, are often stored in tabular form, present several limitations: frequent re-
dundancies, hidden data, which makes their exploitation and sharing difficult.
To overcome these limitations, a modeling step proved essential. It makes it
possible to clarify the entities manipulated, their attributes, as well as the rela-
tionships between entities. The internship carried out is part of a problem aimed
at developing a method for transforming conceptual data models generated from
this data into conceptual ontology models which will then be transformed into an
ontology. The approach is based on the translation of a conceptual data model
in UML, designed with the Draw.io tool, into a conceptual ontology model in
CHOWLK language. This model is then converted into an OWL ontology us-
ing the CHOWLK converter tool, in order to efficiently structure and share
knowledge. The approach adopted is semi-automatic, combining automated
translation steps with validation and manual enrichment phases, thus ensuring
the consistency and quality of the generated knowledge graphs. This work con-
tributes to strengthening the interoperability of agronomic data and supporting
the development of intelligent information systems for the agriculture of tomor-
row.

**Keywords** : conceptual data model, ontology, UML, CHOWLK, Draw.io,
Conceptual Ontology Model.
# Table des matières

<table><tr><td>0.1 Contexte</td><td>1</td></tr><tr><td>0.2 Définitions</td><td>2</td></tr><tr><td>0.3 Problématique</td><td>3</td></tr><tr><td>0.4 Objectifs</td><td>4</td></tr><tr><td>0.4.1 Objectif global</td><td>4</td></tr><tr><td>0.4.2 Objectifs spécifiques</td><td>4</td></tr></table>

## 1 Étude Bibliographique 6

1.1 Méthodes génériques de conception d'ontologies 6

1.2 Méthodes de conception d'ontologies à partir de bases de données relationnelles 10

1.2.1 Règles de traduction de BDR vers Ontologie 10

1.2.2 Approches et outils basés sur les règles sans contrainte 11

1.2.3 Approches et outils basés sur les règles avec contrainte 14

1.2.4 Tableau de Synthèse 20

1.3 Technologie du Web Sémantique 21

1.4 Synthèse 23

## 2 Solution proposée 25

2.1 Méthode outillée 25

2.2 Règles de traduction des modèles 26

2.2.1 E2C : Entité vers Classe 26

2.2.2 A2OP : Association vers propriété d'objet 26

2.2.3 I2S : Inclusion de clés primaires vers relation SubclassOf 29

2.2.4 A2DP : Attribut vers propriété de type de données 29

2.2.5 Recommandation 31
<table>
  <tbody>
    <tr>
      <td>3</td>
      <td>Développement de l'outil MCD2MCO</td>
      <td>33</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Présentation générale de la solution</td>
      <td>33</td>
    </tr>
    <tr>
      <td>3.2</td>
      <td>Structure des fichiers Draw.io en XML</td>
      <td>34</td>
    </tr>
    <tr>
      <td>3.3</td>
      <td>Algorithme</td>
      <td>35</td>
    </tr>
    <tr>
      <td>3.3.1</td>
      <td>Algorithme de Vérification</td>
      <td>36</td>
    </tr>
    <tr>
      <td>3.3.2</td>
      <td>Algorithme MCD2MCO</td>
      <td>37</td>
    </tr>
    <tr>
      <td>3.4</td>
      <td>Difficultés rencontrées lors de la conception de l'outil</td>
      <td>41</td>
    </tr>
    <tr>
      <td>3.5</td>
      <td>Implémentation technique en Python et Streamlit</td>
      <td>42</td>
    </tr>
    <tr>
      <td>3.6</td>
      <td>Description des interfaces de l'outil</td>
      <td>42</td>
    </tr>
    <tr>
      <td>3.6.1</td>
      <td>Interface d'accueil</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.6.2</td>
      <td>Interface de sortie</td>
      <td>44</td>
    </tr>
    <tr>
      <td>4</td>
      <td>Résultats et Évaluation</td>
      <td>47</td>
    </tr>
    <tr>
      <td>4.1</td>
      <td>Production des Modèles Conceptuels de Données</td>
      <td>47</td>
    </tr>
    <tr>
      <td>4.1.1</td>
      <td>Cas d'usage 1 projet STAR</td>
      <td>47</td>
    </tr>
    <tr>
      <td>4.1.1.1</td>
      <td>contexte</td>
      <td>47</td>
    </tr>
    <tr>
      <td>4.1.1.2</td>
      <td>Résultat de la transformation du MCD du projet STAR</td>
      <td>49</td>
    </tr>
    <tr>
      <td>4.1.2</td>
      <td>Cas d'usage 2 format de Données ICASA</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.1.2.1</td>
      <td>Contexte</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.1.2.2</td>
      <td>Résultat de la transformation du MCD du format de Données ICASA</td>
      <td>52</td>
    </tr>
    <tr>
      <td>4.2</td>
      <td>Évaluation du MCO</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.2.1</td>
      <td>Évaluation syntaxique avec l'outil CHOWLK Converter</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.2.2</td>
      <td>Évaluation par validation avec Protégé</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.2.3</td>
      <td>Limites observées</td>
      <td>55</td>
    </tr>
    <tr>
      <td>5</td>
      <td>Conclusion et perspectives</td>
      <td>57</td>
    </tr>
    <tr>
      <td>5.1</td>
      <td>Conclusion</td>
      <td>57</td>
    </tr>
    <tr>
      <td>5.2</td>
      <td>Perspectives</td>
      <td>58</td>
    </tr>
  </tbody>
</table>
# Acronyms

**AP** Average Population. 20

**API** Application Programming Interface. 13, 16

**AR** Attribute Richness. 19

**ATL** Atlas Transformation Language. 19

**BDR** Bases de Données Relationnelles. i, 2, 4, 10, 12–16, 18, 26

**CR** Class Richness. 20

**CSV** Comma-Separated Values. 1, 59

**DMEE** moteur Data Medium Exchange. 19

**EMF** Eclipse Medeling Framework. 19

**FAIR** Findable, Accessible, Interoperable, Reusable. 8

**FK** Foreign Key. 11

**ICASA** International Consortium for Agricultural Systems Applications. ii, 51, 52, 57

**IR** Inheritance Richness. 19

**JDBC** Java DataBase Connectivity. 12, 13, 17, 18

**JDK** Java Development Kit. 16

**LLM** Large Language Model. 59
**LOD** Linked Open Data. 7, 22

**LODE** Live OWL Documentation Environment. 59

**LOT** Linked Open Terms. 7–9, 23, 58

**MCD** Modèle Conceptuel de donnée. ii, 1–5, 24, 26, 33, 35, 48, 49, 51–53, 55, 57

**MCO** Modèle Conceptuel d'Ontologie. ii, 1–5, 7, 14, 17, 33, 47, 49, 51–55, 57, 59

**MDE** Model-Driven Engineering). 18

**ODBC** Open Database Connectivity. 17

**OGSRD** Ontology automatic Generation System based on Relational Database. 15

**OOPS!** OntOlogy Pitfall Scanner!. 9

**OWL** Web Ontology Language. 2, 3, 5, 9, 11–19, 22, 23, 26, 54, 56, 58, 59

**PK** Primary Key. 11

**R2O** Relational to Ontology. 12

**RDF** Resource Description Framework. 2, 16, 19, 22, 23

**RDFS** Resource Description Framework Schema. 12, 18, 22

**RR** Relationship Richness. 19

**SHACL** Shapes Constraint Language. 23

**SKOS** Simple Knowledge Organization System. 2

**SQL** tructured Query Language. 12, 15, 18, 19, 23

**UML** Unified Modeling Language. 1, 2, 4, 5, 33–35, 42, 57

**URI** Uniform Resource Identifier. 22, 23, 26

**XML** Extensible Markup Language. ii, 34, 41, 43, 54
Table des figures

<table><tr><td>1.1</td><td>Scénarios de construction d'ontologies et de réseaux d'ontologies</td><td>8</td></tr><tr><td>1.2</td><td>LOT methodology base workflow</td><td>10</td></tr><tr><td>2.1</td><td>Architecture du Système</td><td>25</td></tr><tr><td>2.2</td><td>Exemple de transformation entité vers Classe</td><td>26</td></tr><tr><td>2.3</td><td>Exemple de transformation de relation vers propriété d'objet</td><td>28</td></tr><tr><td>2.4</td><td>Exemple de transformation d'inclusion de clés primaires vers relation SubclassOf.</td><td>29</td></tr><tr><td>2.5</td><td>Exemple de transformation d'attribut vers propriété de type de données.</td><td>31</td></tr><tr><td>2.6</td><td>Exemple de relation entre sous classe et les autres classes.</td><td>31</td></tr><tr><td>3.1</td><td>Exemple de fichier XML brut</td><td>35</td></tr><tr><td>3.2</td><td>Images Python et Streamlit.</td><td>42</td></tr><tr><td>3.3</td><td>Image Interface d'accueil</td><td>43</td></tr><tr><td>3.4</td><td>Image interface de sortie avec erreur.</td><td>44</td></tr><tr><td>3.5</td><td>Image interface de sortie sans erreur.</td><td>45</td></tr><tr><td>4.1</td><td>MCD partiel issue données STAR</td><td>49</td></tr><tr><td>4.2</td><td>Résultat du MCO sur le MCD du projet STAR</td><td>50</td></tr><tr><td>4.3</td><td>MCD Partiel issue des données ICASA</td><td>52</td></tr><tr><td>4.4</td><td>Résultat du MCO sur le MCD du projet STAR</td><td>53</td></tr><tr><td>4.5</td><td>Exemple de résultat de l'ontologie OWL dans Protégé cas de STAR.</td><td>55</td></tr><tr><td>5.1</td><td>Perspectives de l'architecture</td><td>58</td></tr></table>
# Liste des tableaux

<table><tr><td>1.1</td><td>Tableau de synthèse des approches</td><td>21</td></tr><tr><td>4.1</td><td>tableau comparatif du MCD et MCO de STAR</td><td>51</td></tr><tr><td>4.2</td><td>tableau comparatif du MCD et MCO de ICASA</td><td>54</td></tr></table>
# Introduction Générale

## 0.1 Contexte

Dans un contexte marqué par les enjeux croissants de sécurité alimentaire, de transition vers une agriculture plus durable et d'adaptation aux changements climatiques, la valorisation et l'exploitation des données issues d'expérimentations agronomiques constituent un levier stratégique pour soutenir la recherche et l'innovation. Ces données, produites à partir de dispositifs expérimentaux variés tels que des capteurs, des observations humaines, des enquêtes de terrain, des images satellites ou encore des relevés obtenus par drones, représentent une richesse considérable pour la compréhension des phénomènes agricoles et environnementaux.

Cependant, elles sont bien souvent stockées sous forme de fichiers tabulés (CSV, Excel). Ces formats, bien qu'adaptés à des traitements ponctuels, présentent plusieurs limitations lorsqu'il s'agit d'exploiter la complexité des données qu'ils contiennent :

* La redondance des données, fréquente dans les fichiers tabulés, entraîne des duplications qui rendent difficile l'analyse rigoureuse et augmentent le risque d'incohérence.

* Les données cachées, comme des relations implicites entre colonnes ou des règles métier non explicitées, rendant difficiles la compréhension et l'exploitation des données contenues dans les fichiers.

* La faible documentation associée à ces jeux de données rend leur interprétation délicate, limitant leur réutilisation en dehors du cercle des producteurs initiaux.

Ces limitations rendent nécessaire la conception d'une approche permettant de passer des données tabulées à une représentation plus riche et explicite, où les entités, leurs attributs et leurs relations sont clairement définis. Une telle structuration permettrait non seulement de clarifier la sémantique implicite des données, mais aussi de poser les bases pour leur exploitation avancée dans des environnements intelligents.
Les technologies du Web sémantique, avec des langages comme RDF (Resource Description Framework) [Özsu (2016)], OWL (Web Ontology Language) [Bechhofer (2018)] et SKOS (Simple Knowledge Organization System) [Miles and Pérez-Agüera (2007)], offrent un cadre théorique solide pour représenter les informations sous forme de graphes de connaissances et d'ontologies. Ces concepts permettent de formaliser les relations entre les entités d'un domaine et d'ouvrir la voie à des traitements automatisés et à la découverte de connaissances implicites.

## 0.2 Définitions

Un modèle conceptuel représenté sous forme graphique avec des langages dédiés comme UML [Roques (2021)] est une représentation abstraite et structurée d'un domaine ou d'un système, mettant en évidence les entités, leurs attributs et les relations entre les entités, sans se préoccuper des détails techniques de mise en œuvre. Dans notre travail, nous distinguons deux types de modèles conceptuels :

* Le Modèle Conceptuel de Données (MCD), élaboré dans l'objectif de concevoir une Base de Données Relationnelles (BDR). Ce modèle est généralement mis en place à l'aide du langage UML;

* Le Modèle Conceptuel d'Ontologie (MCO), élaboré dans l'objectif de concevoir un graphe de connaissances. Ce modèle est généralement mis en place à l'aide du langage CHOWLK [Chávez-Feria et al. (2022)], qui est une extension de UML pour des ontologies.

Un schéma de base de données est selon [Salem et al. (2024)] une description de la structure de la base de données et des données qu'elle contient, vue à travers différents niveaux selon les besoins des utilisateurs, des administrateurs ou des concepteurs. Dans notre cas, nous définissons un schéma de base de données comme un équivalent au modèle logique; il est une représentation structurée des données, obtenue à partir du Modèle Conceptuel de Données. Il traduit les entités, attributs et relation définis au niveau conceptuel en tables, colonnes et liens entre tables à l'aide de clés étrangères.

Une base de données relationnelle selon Ketata et al. (2025) est un ensemble de tables interconnectées via des relations de type clé primaire/clé étrangère, où
chaque table représente une entité et contient un ensemble de lignes, appelées tuples, décrivant les individus de ce type d'entité.

**Une ontologie** est selon Posea and Harzallah (2004) une spécification formelle d'une conceptualisation d'un domaine, structurée à travers un ensemble d'entités et de relations. Dans notre cas, nous définissons une ontologie du Web comme étant une représentation structurée des données obtenue à partir du MCO. Elle traduit les entités en classe, les attributs en propriété de type de donnée ou en propriété d'annotation et les relations en propriété d'objet. Elle repose sur les standards du Web sémantique définis par le W3C et est exprimée dans le langage OWL.

**Un graphe de connaissances** selon Fensel et al. (2020), est un modèle struc-
turé dans lequel les données sont représentées sous forme de graphes, composés
de nœuds et de liens. Mais dans notre cas nous définissons un **graphe de connaissances** comme une ontologie peuplée, c'est-à-dire une ontologie dans laquelle les
classes sont instanciées. Il s'agit d'un ensemble de nœuds interconnectés via des
propriétés d'objet, et ainsi, chaque individu est typé par une classe et relié à ses
attributs par des propriétés de type de données ou des propriétés d'annotation.

**0.3 Problématique**

Le Modèle Conceptuel de Données (MCD) constitue une étape incontournable
pour structurer et organiser des données hétérogènes en formalisant les entités,
leurs attributs et les relations qui les lient. Cette modélisation permet d'apporter
une vision claire de la structure des données et sert de base à leur exploitation.
Cependant, si le MCD constitue une représentation conceptuelle efficace, il est
avant tout conçu pour la structuration de bases de données relationnelles, met-
tant en œuvre des principes comme l'unicité des représentations des individus,
l'appartenance des attributs à l'entité et l'hypothèse du monde clos<fnref n="1" />. Dans notre
cas, orienté vers la mise en place d'une ontologie, ce modèle n'est pas le plus
approprié, car il ne fournit pas directement les structures nécessaires à une for-
malisation exploitable par une ontologie.

Pour dépasser ces limites, la transformation d'un MCD en MCO compatible
avec les principes de modélisation du Web sémantique (comme OWL) apparaît

<footnote n="1">¹(Qui est l'hypothèse que ce qui n'est pas connu pour être vrai doit être faux. Ainsi, ce qui est inscrit dans la base est vrai et ce qui n'est pas inscrit dans la base est faux.)</footnote>
comme une solution pertinente. Elle met en œuvre des principes de multiplication des représentations des individus et l'hypothèse du monde ouvert <fnref n="2" />, ainsi qu'une conception où les propriétés de type de donnée et d'annotation sont traitées comme des entités de première classe (first-class citizens), c'est-à-dire au même niveau qu'une classe. Ce processus offre la possibilité de formaliser les entités d'un domaine, d'expliciter leurs relations, ainsi, il sera possible de raisonner pour enrichir les représentations. Néanmoins, cette transformation soulève plusieurs défis majeurs. Il est nécessaire de définir des règles de correspondance précises entre les composants du MCD et du MCO. Dans ce contexte, une question fondamentale se pose : comment transformer un MCD en un MCO, afin de passer d'une représentation conceptuelle orientée BDR à une représentation conceptuelle orientée ontologie ? Répondre à cette question implique de proposer une méthodologie rigoureuse et adaptable, capable de traiter la complexité des données tout en facilitant leur structuration et leur valorisation dans des environnements numériques intelligents.

## 0.4 Objectifs

### 0.4.1 Objectif global

L'objectif global de ce travail est de proposer une approche méthodologique permettant de transformer un MCD, conçu en langage UML, en un MCO puis en ontologie conforme aux standards du W3C. Cette transformation vise à passer d'une représentation conceptuelle, qui organise les entités, attributs et relations pour des besoins d'une BDR en une nouvelle représentation conceptuelle adaptée aux ontologies du web. Cette approche doit assurer une correspondance fidèle entre les éléments du MCD et le MCO, tout en restant suffisamment flexible pour s'adapter à la diversité et la complexité des modèles conceptuels de données.

### 0.4.2 Objectifs spécifiques

Pour atteindre cet objectif global, plusieurs objectifs spécifiques ont été définis :

* Concevoir les règles de transformation d'un MCD en MCO

<footnote n="2">²("Ce n'est pas parce qu'on ne connaît pas une information que cette information est fausse.")</footnote>
Mettre en place un ensemble de règles de traduction permettant d'assurer
une correspondance cohérente entre les éléments d'un Modèle Conceptuel
de Données (entités, attributs, relations, contraintes) en UML et les com-
posants d'un modèle graphe utilisant le langage CHOWLK. Cette étape
vise à poser les fondations conceptuelles de la transformation, en garantis-
sant que la structure et la logique du MCD soient correctement traduites
dans une nouvelle représentation graphique.

* Mettre en place un outil pour générer un MCO à partir d'un MCD Concevoir et développer un outil capable d'automatiser la génération d'un MCO à partir d'un MCD, en tenant compte des règles de transformation définies.

* Élaborer un processus de conversion du MCO en une ontologie OWL.
Cette étape vise à définir et à mettre en œuvre une architecture méthodologique permettant de transformer le MCO généré en une ontologie OWL conforme aux standards et aux bonnes pratiques du Web sémantique.
# Chapitre 1

## Étude Bibliographique

### 1.1 Méthodes génériques de conception d'ontologies

Dans le domaine de l'ingénierie des connaissances, plusieurs méthodologies ont été proposées afin d'orienter la conception des ontologies.

La méthodologie NeOn [Suárez-Figueroa et al. (2011)] est une approche struc-
turée, modulaire et évolutive pour la construction d'ontologies. Cette méthodo-
logie a été conçue dans le cadre du projet européen NeOn, en réponse à la
montée en complexité des projets d'ingénierie des connaissances dans des envi-
ronnements de plus en plus distribués, collaboratifs et centrés sur la réutilisation
de ressources existantes. La Méthodologie NeOn adopte une approche scénarisée
figure 1.1. Elle identifie neuf scénarios pratiques, correspondant à des situations
réelles rencontrées dans les projets. Ces scénarios couvrent un large éventail de
cas, allant de la création d'une ontologie à partir de spécifications initiales (scé-
nario 1) à la réutilisation et la transformation de ressources non-ontologiques
(scénario 2), la réutilisation ou la fusion d'ontologies existantes (scénarios 3 à
6), l'exploitation de patrons de conception d'ontologies (scénario 7), la restruc-
turation (scénario 8) et la localisation multilingue (scénario 9). Ces scénarios
ne sont pas exclusifs, et peuvent être combinés librement selon les besoins du
projet. L'un des points forts de la méthodologie réside dans son glossaire des
processus et activités, qui recense 59 opérations type impliquées dans l'ingénie-
rie des connaissances. Chaque activité est formellement décrite selon des critères
méthodologiques : objectifs, entrées, sorties, intervenants, moment d'exécution,
outils mobilisable, etc. Parmi les activités majeures, on retrouve : la spécification
des besoins ontologiques (Ontology Requirements Specification), la conception
du MCO, la création de l'ontologie du web, la mise en œuvre de l'ontologie dans
le système d'information, l'évaluation (validation, vérification), la modularisa-
tion, l'annotation, ou encore la traduction multilingue. Deux modèles de cycle
de vie sont proposés pour orchestrer ces activités :

* Le modèle en cascade, structuré en 4 à 6 phases selon les variantes (initiation, conception, implémentation, maintenance, et selon les cas, phases de réutilisation, fusion ou re-ingénierie).

* Le modèle itératif-incrémental, qui permet de diviser le développement en mini-projets successifs, intégrant progressivement les exigences fonctionnelles et facilitant l'ajustement en cas de changement.

Enfin, l'application de la méthodologie a été démontrée dans divers domaines concrets tels que le tourisme, l'e-emploi, l'éducation ou les systèmes mobiles. Elle s'intègre naturellement dans les initiatives du Web sémantique.

En ingénierie des connaissances, le processus de développement d'une ontolo-
gie suit généralement cinq étapes : spécification, planification, conceptualisation,
formalisation et implémentation. La méthodologie NeOn a marqué une avancée
importante en introduisant plusieurs scénarios de développement, mettant par-
ticulièrement l'accent sur la réutilisation des ressources existantes. Aujourd'hui,
le contexte a évolué, de nombreuses ontologies sont désormais disponibles sur le
Web, couvrant une grande variété de domaines. Dans ce nouvel environnement,
la méthode que nous avons retenue est LOT (Linked Open Terms), une méthode
issue de NeOn, mais qui s'adapte à cette réalité en sélectionnant directement
des ressources existantes et en supprimant la phase classique de conceptualisa-
tion. En revanche, elle ajoute deux étapes majeures qui sont la publication et
la maintenance des ontologies, garantissant leur intégration harmonieuse et leur
pérennité dans un écosystème sémantique interconnecté, tel que celui du Web
des données ouvertes et liées (Linked Open Data).
<figure><img src="image_6.png" /><figcaption>FIGURE 1.1 : Scénarios de construction d'ontologies et de réseaux d'ontologies</figcaption></figure>

Source : Suárez-Figueroa et al. (2011)

La méthode LOT [Poveda-Villalón et al. (2022)] propose une approche moderne, légère pour le développement d'ontologies. Il a été conçu en réponse aux limites observées dans les méthodologies classiques telles que METHONTOLOGY [Fernández-López et al. (1997)], NeOn [Suárez-Figueroa et al. (2011)] ou Ontology Development 101 [Noy et al. (2001)], en mettant l'accent sur l'intégration avec les pratiques d'ingénierie logicielle, la traçabilité des exigences, la réutilisation, la documentation, et la publication conforme aux principes FAIR (Findable, Accessible, Interoperable, Reusable). La méthode LOT repose sur quatre grandes activités organisées de manière itérative voir figure 1.2.

La première activité est la spécification des exigences d'ontologies : elle consiste à identifier les utilisateurs cibles les cas d'usage concrets, les objectifs de modélisation et les besoins d'échange de données. Ces exigences sont formalisées sous forme de questions de compétence, de phrases en langage naturel ou de tableaux. Cette étape garantit que la construction de l'ontologie est alignée avec
les objectifs métier.

La deuxième activité est l'implémentation de l'ontologie selon une démarche incrémentale, inspirée des cycles de développement logiciel. Chaque sprint intègre la conceptualisation des classes et propriétés, l'encodage formel de l'ontologie (généralement en OWL), la réutilisation d'ontologies existantes (via des portails comme AgroPortal), et des processus d'évaluation incluant la vérification logique (raisonneurs OWL, tests SHACL [Corman et al. (2018)]) et la validation fonctionnelle par rapport aux exigences initiales.

La troisième activité est la publication de l'ontologie. LOT recommande une publication automatisée et standardisée de l'ontologie et de sa documentation à l'aide d'outils comme Widoco. Elle s'accompagne de visualisations (notamment via Chowlk) et de pratiques de content négociation pour assurer l'accessibilité des différentes représentations (HTML, etc.). L'objectif est de garantir l'interopérabilité et la réutilisation dans des contextes ouverts et distribués.

Enfin, la quatrième activité concerne la maintenance et la gestion du cycle de vie de l'ontologie. LOT préconise l'utilisation d'outils de gestion de versions (Git, GitHub, GitLab), de plateformes collaboratives (WebProtégé [Horridge et al. (2019)], OnToology [Alobaid et al. (2019)]), et d'outils de contrôle qualité (OOPS! [Poveda-Villalón et al. (2014)], Themis [Fernández-Izquierdo and García-Castro (2019)]). Cela permet d'assurer un suivi rigoureux des modifications, une prise en compte des retours utilisateurs, et une documentation continue des évolutions. Validée sur dix-huit projets concrets dans des domaines variés (villes intelligentes, agriculture, énergie, etc.), LOT se démarque par son alignement avec les standards industriels et les bonnes pratiques logicielles. Elle permet d'intégrer l'ontologie comme un composant logiciel à part entière dans une chaîne de production continue, avec documentation, tests, versionnement, et déploiement. Contrairement aux approches telles que NeOn souvent centrées sur la phase de modélisation conceptuelle, LOT met l'accent sur la ré-utilisabilité, et la qualité tout au long du cycle de vie de l'ontologie.
<figure><img src="image_7.png" /><figcaption>FIGURE 1.2 : LOT methodology base workflow</figcaption></figure>

Source : Poveda-Villalón et al. (2022)

## 1.2 Méthodes de conception d'ontologies à partir de bases de données relationnelles

### 1.2.1 Règles de traduction de BDR vers Ontologie

La construction d'ontologies constitue un enjeu important pour les techniques du Web sémantique. Pour répondre à ce défi, plusieurs approches ont été proposées afin d'automatiser la génération d'ontologies à partir de données existantes, notamment à partir des bases de données relationnelles (BDR), qui représentent une source riche et structurée de données existantes. Des travaux sur la construction d'ontologie à partir de BDR ont proposé des règles de transformation. Ces règles définissent des correspondances entre les éléments des bases relationnelles et les éléments d'une ontologie peuplée ou non. Au total, nous avons trouvé 11 règles de transformation dans la littérature :

1. Une table avec une clé primaire non composée est transformée en une classe
OWL;

2. Une table avec une clé primaire composée de clés étrangères, dite table d'association, est transformée en deux propriétés objet dont l'une est l'inverse de l'autre;

3. Une clé primaire (PK) est transformée en une propriété de type de donnée avec cardinalité = 1;

4. Une clé étrangère (FK) est transformée en une propriété d'objet;

5. Une relation hiérarchique est transformée en une relation de sous-classe (subClassOf);

6. Une colonne est transformée en une propriété de type de données;

7. Une contrainte Not NULL sur une colonne est transformée en une contrainte de cardinalité OWL avec pour cardinalité minimale = 1;

8. Une contrainte UNIQUE sur une colonne transforme la propriété associée en une propriété fonctionnelle avec pour containte de cardinalité maximale = 1;

9. Transformation de la borne minimale d'une colonne en contrainte de cardinalité minimale;

10. Transformation de la borne maximale d'une colonne en contrainte de cardinalité maximale;

11. Transformation des tuples en individus.

Plusieurs travaux de recherche ont mis en œuvre ces règles dans des systèmes de conversion différents.

### 1.2.2 Approches et outils basés sur les règles sans contrainte

Certaines méthodes de transformation automatique de bases de données relationnelles en ontologies OWL se limitent à l'application des règles 1 à 6 et 11,
généralement centrées sur la génération des classes, propriété d'objet et pro-
priété de type de données et le peuplement, sans prise en charge explicite des
cardinalités ou des axiomes complexes.

Les travaux de Barrasa Rodríguez et al. (2004) (Voir ligne 1 tableau 1.1) pro-
posent l'outil R2O (Relational to Ontology), accompagné du processeur ODE-
Mapster [Barrasa et al. (2003)]. Cet outil permet de transformer des BDR en
ontologies RDFS ou OWL, facilitant ainsi la migration des données vers le Web
sémantique. R2O prend en entrées le fichier SQL de la base de donnée relation-
nelle, avec la possibilité d'intégrer des descriptions en langage naturel associées
aux tables et colonnes pour enrichir les correspondances. L'accès aux données se
fait directement sur la BDR, sans nécessité d'exposition préalable des contenus
sous forme de pages web dynamique. Concernant les sorties produites, l'outil
permet non seulement la génération d'une ontologie seule, mais aussi le peuplement de cette ontologie pour créer un graphe de connaissances contenant des
instances extraites de la BDR. La méthode mise en œuvre par R2O est automatique, l'exécution des transformations et le peuplement de l'ontologie sont
automatisés par ODEMapster. L'outil inclut un ensemble de règles (1,4,6 et 11) de traduction permettant la transformation. L'évaluation de R2O a été réalisée
à travers l'application FundFinder [Barrasa et al. (2003)], qui a démontré la
faisabilité et l'efficacité du peuplement d'ontologies à partir de bases relationnelles. Ce cas d'utilisation valide les capacités de l'outil et ouvre la voie à une
généralisation sur d'autres domaines.

Dans la même lancée, l'outil DB2OWL proposé par Ghawi and Cullot (2007)
(Voir ligne 2 tableau 1.1) dans le cadre d'une architecture d'interopérabilité
générale qui utilise des ontologies pour décrire explicitement la sémantique des
sources d'information. Cet outil a pour objectif de générer automatiquement
une ontologie à partir d'un schéma de base de données relationnelles. Elle se
base sur une approche en deux étapes. Premièrement, le contenu de chaque
BDR est décrit par une ontologie locale. Deuxièmement, les ontologies locales
sont ensuite intégrées dans une ontologie globale. Ainsi, cette approche crée des
correspondances entre les classes des différentes ontologies locales. Cet outil se
connecte directement à la base de données relationnelles via l'interface JDBC
et exploite les données disponibles. DB2OWL produit une ontologie décrivant
la structure du domaine. Les instances demeurent dans la base de données et
sont traduites dynamiquement lors de l'exécution de requêtes SPARQL [Pérez et al. (2009)], selon une approche dite query-driven. La méthode employée est entièrement automatique. DB2OWL applique les règles 1 à 6 de transformation permettant de générer les composants d'ontologies correspondants. L'outil a été développé en Java, utilisant l'API Jena pour la génération du fichier OWL et JDBC pour l'interface avec les bases de données. Il s'agit pour l'instant d'un prototype, destiné à être intégré dans des services plus larges de cartographie et d'interrogation sémantique.

Dans cette continuité les travaux de Bakkas et al. (2013) (voir ligne 3 tableau 1.1) proposent une architecture en deux étapes : la première est au niveau du schéma, les tables sont converties en classes OWL, les attributs en propriétés de type de données, et les clés étrangères en propriétés d'objets ; la seconde étape permet de peupler cette ontologie avec les données de la BDR. L'entrée utilisée pour cette méthode est un accès direct à la base de données relationnelles, exploitant les catalogues du système de gestion de bases de données (SGBD) pour extraire à la fois la structure et les enregistrements. En sortie, la méthode produit une ontologie complète comprenant à la fois la structure conceptuelle et les individus issus des BDR, autrement dit un graphe de connaissances. Le processus est entièrement automatique et s'appuie sur un ensemble de règles (1 à 6 et 11) de traduction. Pour la mise en œuvre, les auteurs ont développé un outil capable de prendre en entrée une base relationnelle et de produire un fichier d'une ontologie au format OWL, visualisable et testable dans l'environnement Protégé [Musen et al. (1995)] à l'aide du plugin OntoGraf [Sean Falconer (2010)]. L'évaluation de cette méthode s'est appuyée sur une étude de cas démontrant la capacité de l'outil à conserver les liens sémantiques entre les tables et les enregistrements de la BDR, et à garantir la cohérence de l'ontologie générée.

Enfin l'approche proposée par Huve et al. (2019) (Voir ligne 4 tableau 1.1) consiste en une exploitation directe du schéma de la base de données. Les entrées utilisées incluent notamment un template de configuration qui centralise les informations extraites de la BDR (tables, colonnes, hiérarchies) et permet d'alterner automatiquement le processus de transformation. Les sorties produites par ce système sont des ontologies OWL, pouvant contenir des classes, des propriétés et des instances. Cela permet de constituer non seulement une ontologie, mais également un graphe de connaissances exploitable. Un prototype logiciel
a été mis en œuvre pour concrétiser cette architecture et intégrer l'ensemble
des règles de transformation définies. L'approche s'appuie sur Protégé pour la
vérification de l'ontologie générée. Au total, 7 (1 - 6,11) règles de traduction ont
été utilisées afin de gérer la transformation des différents éléments de la BDR.
L'évaluation de cette approche a été réalisée à travers deux expérimentations :
la première a permis de valider le prototype à partir de trois scénarios d'une
base de données du domaine des soins dentaires ; la seconde a appliqué une mé-
thode de test de mutation<fnref n="1" /> [Jia and Harman (2010)] sur les ontologies générées.
Ce processus a permis de mesurer la robustesse et la qualité des ontologies en
identifiant les éventuelles erreurs et lacunes. Les résultats obtenus démontrent
la cohérence du système et confirment la capacité de l'architecture à produire
des ontologies fiables et lisibles.

1.2.3 Approches et outils basés sur les règles avec contrainte

Plusieurs travaux ont proposé des méthodes automatiques de transformation de
bases de données relationnelles en ontologies OWL, reposant sur les règles 1 à
11 de transformations, couvrant les classes, propriétés, hiérarchie, cardinalité et
instances.

Parmi ces travaux, Li et al. (2005) (voir ligne 7 tableau 1.1), introduisent
une méthode directe de transformation sans passer par un MCO. Cette méthode
vise à faciliter la construction d'ontologies OWL en exploitant directement les
informations contenues dans les BDR. Cette méthode prend en entrée les sché-
mas relationnels extraits des BDR, en accédant soit directement aux bases de
données, soit via la documentation associée. En sortie, elle produit une onto-
logie. Elle est également capable de générer une ontologie peuplée, c'est-à-dire
un graphe de connaissances intégrant les instances issues des tuples des bases
de données. Elle est automatique, reposant sur un ensemble de règles (1 - 8,11)
de transformation. Ces règles permettent de cartographier systématiquement les
éléments des schémas de bases de données (relations, attributs, clés primaires
et étrangères, contraintes) vers des classes et propriétés d'ontologies. Un frame-
work logiciel a été développé pour implémenter cette approche. Déployé dans
le cadre du projet web sémantique de l'université Renmin, cet outil a permis

<footnote n="1">¹(qui est une technique de test logiciel permettant d'évaluer la qualité d'un ensemble de cas de test)</footnote>
de générer automatiquement une ontologie à partir d'une bibliothèque numérique contenant environ 30 000 ressources économiques stockées en BDR. Le processus a abouti à la création de 20 classes d'ontologies, 400 propriétés et 30 000 instances, démontrant la pertinence et l'efficacité pratique de la méthode. L'évaluation de cette approche s'est concentrée sur sa capacité à extraire et à organiser les connaissances de manière cohérente et exploitable, avec un cadre général indépendant du domaine d'application.

De manière complémentaire, les travaux de Lakzaei and Shamsfard (2021) (Voir ligne 13 tableau 1.1) étendent ce même cadre pour traiter des cas complexes tels que l'héritage multiple, les entités faibles ou les attributs partagés entre plusieurs tables. Cette méthode s'inscrit dans le contexte des travaux récents visant à réduire la complexité et le coût des processus de construction manuelle d'ontologies. Le processus repose sur un accès direct à la BDR, permettant d'analyser les différentes composantes définies par l'utilisateur. L'objectif est de transformer ces éléments en composants d'ontologie selon un ensemble de règles (1 - 8,11) de traduction. Le système produit en sortie une ontologie OWL qui peut-être :

* soit non peuplée ;

* soit peuplée (incluant également les individus pour avoir un graphe de connaissances).

Une attention particulière est accordée à la prise en compte des contraintes de cardinalité présentes dans la BDR pour générer des axiomes précis. La méthode, entièrement automatique, a été implémentée en C#.NET et fonctionne avec SQL Server comme système de gestion de bases de données. Les ontologies produites peuvent être visualisées et éditées avec l'outil Protégé. Pour évaluer l'efficacité de leur méthode, les auteurs l'ont comparée à plusieurs approches existantes en utilisant trois critères : la capacité à créer des composants d'ontologie, l'analyse des éléments complexes des BDR, et des mesures quantitatives telles que la précision, le rappel et la F-mesure. L'évaluation a été réalisée sur trois bases de données représentatives (université, hôtel, système de transport), démontrant la capacité de l'approche proposée dans l'extraction des connaissances sémantiques riches.

Zhang and Li (2011) (voir ligne 8 tableau 1.1) présentent un outil, OGSRD (Ontology automatic Generation System based on Relational Database), qui
s’appuie sur un accès direct à la base de données relationnelles afin d’extraire
de manière automatisée l’ensemble des données nécessaires, telles que les tables,
les colonnes, etc. L’extraction des informations s’effectue à l’aide de la méthode
getMetaData de l’API Java, assurant ainsi une prise en charge complète des
structures relationnelles existantes. Le système produit une ontologie complète
au format OWL, et aussi un graphe de connaissances (ontologie peuplé), les tuples
de la base de données étant traduits en individus

Ling and Zhou (2013) (Voir ligne 9 tableau 1.1) proposent une approche re-
posant sur un accès direct aux données des BDR via un analyseur utilisant des
techniques de l'ingénierie inverse pour extraire les schémas relationnels. Cette
extraction alimente un processus de transformation qui repose sur l'ensemble
formalisé des règles (1 - 8,11) de traduction. La solution développée produit
en sortie une ontologie peuplée OWL. Une attention particulière est portée à
la gestion des contraintes de cardinalité : les clés primaires sont associées à des
cardinalités minimales et maximales fixées à 1 ; les attributs définis comme NOT
NULL imposent une cardinalité minimale égale à 1 ; les attributs UNIQUE sont
traduits par une cardinalité maximale égale à 1. La méthode est entièrement
automatique, le processus s'effectue via un prototype implémenté en Java (JDK
1.6), utilisant l'API Jena 2.6.0 pour la modélisation sémantique, et adossé à
un système de gestion de bases de données relationnelles MySQL 5.0.28. Cette
implémentation a fait l'objet d'une évaluation expérimentale, montrant que l'ap-
proche est efficace pour des BDR. L'évaluation de l'approche ne se limite pas
à vérifier si le graphe RDF généré est correct sur le plan syntaxique. Elle va
plus loin en validant aussi son bon fonctionnement. Autrement dit, on ne se
contente pas de voir si le fichier est bien écrit, mais on s'assure que les relations
et contraintes issues de la BDR sont correctement traduites dans l'ontologie.

De même Dadjoo and Kheirkhah (2015) (Voir ligne 10 tableau 1.1) proposent également une méthode de transformation des bases de données relationnelles en ontologies OWL. Cette méthode utilise comme entrée un accès direct à la base de donnée relationnelle, décrite en schéma de la base de données. Elle produit en sortie une ontologie OWL, capable de représenter le schéma de la base de données. Contrairement à certaines approches précédentes, cette méthode prend en compte les contraintes de cardinalité telles que NOT NULL, UNIQUE, les clés primaires, qui sont traduites en propriétés de type de données avec une car-
dinalité OWL = 1. Le processus est entièrement automatique et se déroule en trois étapes principales : l'extraction des informations de la base relationnelle ; création d'un MCO à partir des informations précédentes ; puis la génération de l'ontologie finale OWL à l'aide de règles de traduction. La méthode repose sur un ensemble de 8 (1 - 8) règles de traduction couvrant la conversion des tables, des attributs, des relations et des contraintes. L'évaluation réalisée est principalement de nature théorique, les auteurs présentent la robustesse du processus par rapport aux approches antérieures, mais sans expérimentations détaillées ni cas d'utilisation concrets.

Par ailleurs, plusieurs outils ont été conçus pour automatiser ce processus. En 2016 Mogotlane and Fonou-Dombeu (2016) (Voir ligne 11 tableau 1.1), proposent une analyse approfondie des outils permettant de convertir automatiquement des bases de données relationnelles en ontologies. Les auteurs se sont intéressés à deux plug-ins de l'éditeur d'ontologies Protégé, à savoir DataMaster [Csongor Nyulas (2008)] qui est un plug-in de Protégé qui importe automatiquement la structure et les données d'une base relationnelle via JDBC/ODBC pour générer une ontologie OWL et OntoBase [Len Yabloko (2009)], quant à lui, transforme le schéma d'une base relationnelle en ontologie OWL. Il permet la création de classes à partir des tables et l'interrogation directe de la base.

Pour les expérimentations, les auteurs ont utilisé une base de données relationnelles développée sous Oracle 11g, accessible directement via le pilote JDBC. Cette base de données, issue d'un système d'information municipal, comportait de multiples tables et relations complexes, permettant d'évaluer la robustesse des outils testés. Les plug-ins ont produit des ontologies au format OWL, analysées ensuite avec des outils de visualisation tels que OntoGraf[Sean Falconer (2010)], et documentées à l'aide du logiciel Parrot. Il convient de noter que les sorties produites sont des ontologies seules, c'est-à-dire des schémas, et non des graphes de connaissances. L'étude met également en évidence la prise en compte des contraintes de cardinalité dans la transformation, en traduisant les contraintes de type NULL et NOT NULL en restrictions sur les propriétés d'ontologies. La conversion repose sur l'application des règles (1 - 8) de traduction. L'évaluation a consisté en une analyse comparative détaillée des deux plug-ins sur un cas d'utilisation unique, la base de données municipale susmentionnée. Les résultats montrent que OntoBase respecte de manière rigoureuse les principes de trans-
formation par rapport à DataMaster, notamment en excluant correctement les
clés étrangères des propriétés de type de données et en générant des hiérarchies
conformes aux contraintes relationnelles. À l'inverse, DataMaster a tendance à
produire des propriétés et des classes supplémentaires, parfois redondantes, ce
qui s'écarte légèrement des recommandations théoriques.

La proposition de Hazber et al. (2016) (Voir ligne 12 tableau 1.1) porte sur une méthode de transformation BDR en ontologies. L'approche proposée utilise comme entrée un accès direct aux bases de données relationnelles via le moteur JDBC en Java, ainsi qu'un accès à la documentation du schéma de la base pour analyser les tables, colonnes, contraintes d'intégrité et relations. La sortie générée est une ontologie seule, représentée en OWL, ou une ontologie peuplée. L'une des caractéristiques majeures de cette méthode est la prise en compte des contraintes de cardinalité. Les clés primaires, les contraintes NOT NULL, UNIQUE, sont analysées et traduites en propriétés de type de données avec une cardinalité OWL = 1. La transformation est entièrement automatique et se déroule en deux phases principales : la génération de l'ontologie à partir du schéma relationnel, et le peuplement de l'ontologie avec des instances obtenues à partir des données de la base. Cette approche repose sur un ensemble des règles (1 - 8,11) de transformation bien définie, permettant de couvrir tous les concepts des modèles relationnels et d'éviter les ambiguïtés. Les auteurs ont utilisé Apache Jena, un framework Java pour le développement d'applications basées sur le Web sémantique. Un validateur RDFS ou OWL a été utilisé pour vérifier la conformité et la cohérence des ontologies générées. Enfin, l'évaluation de la méthode a été réalisée à l'aide des métriques classiques de précision, rappel et F-mesure sur un cas d'étude (RDBLAB). Les résultats obtenus ont montré une qualité en termes de correspondance et d'expressivité par rapport aux méthodes existantes, en particulier grâce à la prise en compte des contraintes complexes et des relations multiples dans les schémas relationnels.

Bouougada et al. (2021) (Voir ligne 5 tableau 1.1) propose une méthode de transformation des bases de données relationnelles en ontologies OWL reposant sur une approche basée sur les MDE Settings (Model-Driven Engineering) [Da Silva (2015)]. La méthode accède à la BDR sous la forme d'un fichier SQL contenant à la fois la structure (tables et attributs) et les données (tuples). Ce fichier est ensuite transformé en un modèle d'entrée compatible avec le processus
de transformation. À la sortie, l'approche génère une ontologie peuplée, c'est-
à-dire un graphe de connaissances qui inclut non seulement l'ontologie (classes,
propriétés d'objet, propriétés de type de données), mais également les données.
Il prend en compte les contraintes de cardinalité telles que les bornes minimales
et maximales définies dans la base relationnelle, en les traduisant en restrictions
OWL. La méthode est entièrement automatique. Elle s'appuie sur un moteur
de transformation implémenté en Eclipse, utilisant l'Eclipse Modeling Frame-
work (EMF) [Steinberg et al. (2008)] et le langage de transformation ATL (At-
las Transformation Language) [Jouault et al. (2006)]. L'outil développé dans le
cadre de cette recherche est décrit comme un prototype fonctionnel, bien qu'il
ne soit pas explicitement mis à disposition pour le téléchargement. Pour effec-
tuer la transformation, le système définit et applique un ensemble de 9 (1 - 6,9
- 11) règles de traduction qui permettent de transformer les éléments du mo-
dèle relationnel vers les composants OWL correspondants. Enfin, l'approche a
été évaluée à travers des expérimentations sur cinq bases de données relation-
nelles distinctes, en mesurant des indicateurs tels que la précision, le rappel et
le F-score.

Enfin Ben Mahria et al. (2021) (Voir ligne 6 tableau 1.1) proposent une mé-
thode qui extrait à la fois les tables et les instances d'un fichier SQL pour avoir
une ontologie finale peuplée. La méthode adoptée est principalement automa-
tique. Un algorithme implémenté permet de transformer le schéma relationnel
en un fichier OWL et d'acquérir les instances sous forme de triplets RDF. L'outil
développé pour cette transformation est mis à disposition sur un dépôt GitHub.
Il intègre un moteur d'extraction de métadonnées (DMEE) et un générateur de
mapping (MGE) pour automatiser la conversion SQL vers RDF. Le processus re-
pose sur un total de 9 (1 - 8,11) règles de traduction qui couvrent différents motifs
de transformation. Ces règles enrichissent la sémantique de l'ontologie générée.
L'évaluation de l'ontologie résultante se fait selon deux dimensions complémen-
taires :

* Classe, propriété de type de données, propriété d'objet : à travers des mé-
triques telles que l'Attribute Richness (AR) [Lourdusamy and John (2018)],
l'Inheritance Richness (IR) [Lourdusamy and John (2018)] et la Relation-
ship Richness (RR) [Tartir et al. (2005)], afin d'évaluer la richesse et la
profondeur du modèle conceptuel;
* Les données : à l'aide des indicateurs Class Richness (CR) [Sicilia et al. (2012)] et Average Population (AP) [Hlomani and Stacey (2014)], qui me-surent la distribution et la densité des instances dans l'ontologie.

L'expérimentation a été menée sur six bases de données e-commerce (North, Is-commerce, Ecommerce, EcommerceDB, Sakila, Northwind), permettant de va-lider la robustesse de la méthode et d'illustrer son efficacité pour produire des ontologies riches en connaissances.

### 1.2.4 Tableau de Synthèse

Le tableau 1.1 présente une synthèse des principaux articles de recherche portant sur la transformation des bases de données relationnelles en ontologies.
<table><caption>TABLE 1.1 : Tableau de synthèse des approches</caption><thead><tr><td>Listes des articles</td><td>Auteur</td><td>Année</td><td>Entrée</td><td>Sortie</td><td>Règles</td><td>Outil créé</td><td>Type</td></tr></thead><tbody><tr><td>R2O, an Extensible and Semantically Based Database to ontology Mapping Language</td><td>Jesús Barrasa et al.</td><td>2004</td><td>fichier sql de la bdr</td><td>une ontologie peuplée (fichier owl)</td><td>(1, 4, 6,11)</td><td>R2O</td><td>Automatique</td></tr><tr><td>Database to Ontology Mapping Generation for Semantic Interoperability</td><td>Raji Ghawi et al.</td><td>2007</td><td>schéma de la BDR</td><td>une ontologie non peuplée (fichier owl)</td><td>1-6</td><td>DB2OWL</td><td>Automatique</td></tr><tr><td>Direct Migration Method of RDB to Ontology while Keeping Semantics</td><td>Jamal Bakkas et al.</td><td>2013</td><td>Schéma de la bdr et les données</td><td>une ontologie peuplée (fichier owl)</td><td>1-6,11</td><td>-</td><td>Automatique</td></tr><tr><td>Architecture for Mapping Relational Database to OWL ontology : An approach to enrich ontology terminology Validated with Mutation Test</td><td>Cristiane A.G. Huve et al.</td><td>2019</td><td>Schéma de la bdr et les données</td><td>une ontologie peuplée (fichier owl)</td><td>1-6,11</td><td>-</td><td>Automatique</td></tr><tr><td>Mapping Relational Database to OWL Ontology Based on MDE Settings</td><td>Benamar Bouougada et al.</td><td>2021</td><td>Schéma de la bdr et les données en fichier sql</td><td>une ontologie peuplée (fichier owl)</td><td>1-6, 9-11</td><td>-</td><td>Automatique</td></tr><tr><td>A novel approach for learning ontology from relational database : from the construction to the evaluation</td><td>Bilal Ben Mahria et al.</td><td>2021</td><td>Schéma de la bdr et les données en fichier sql</td><td>une ontologie peuplée (fichier owl)</td><td>1-8, 11</td><td>-</td><td>Automatique</td></tr><tr><td>Learning ontology from relational DataBase</td><td>Man Li et al.</td><td>2005</td><td>Schéma de la bdr et les données</td><td>une ontologie peuplée (fichier owl)</td><td>1-8, 11</td><td>-</td><td>Automatique</td></tr><tr><td>Automatic Generation of Ontology Based on Database</td><td>Lei ZHANG et al.</td><td>2011</td><td>une BDR</td><td>une ontologie peuplée (fichier owl)</td><td>1-8, 11</td><td>OGSRD</td><td>Automatique</td></tr><tr><td>Mapping Relational Databases into OWL Ontology</td><td>Haiyun Ling et al.</td><td>2013</td><td>Schéma de la bdr et les données</td><td>une ontologie peuplée (fichier owl)</td><td>1-8, 11</td><td>-</td><td>Automatique</td></tr><tr><td>An Approach For Transforming of Relational Databases to OWL Ontology</td><td>Mona Dadjoo et al.</td><td>2015</td><td>Schéma de la bdr en fichier sql</td><td>une ontologie non peuplée (fichier owl)</td><td>1-8</td><td>-</td><td>Automatique</td></tr><tr><td>automatic conversion of relational databases into ontologies : a comparative analysis of protégé plug-ins performance</td><td>Kgotatso Desmond Mogotlane et al.</td><td>2016</td><td>Schéma de la bdr et les données</td><td>une ontologie peuplée (fichier owl)</td><td>1-7, 11</td><td>-</td><td>Automatique</td></tr><tr><td>Integration Mapping Rules : Transforming Relational Database to Semantic Web Ontology</td><td>Mohamed A. G. Hazber et al.</td><td>2016</td><td>Schéma de la bdr et les données</td><td>une ontologie peuplée (fichier owl)</td><td>1-8, 11</td><td>-</td><td>Automatique</td></tr><tr><td>Ontology learning from relational databases</td><td>Batool Lakzaei et al.</td><td>2021</td><td>Schéma de la bdr et les données</td><td>une ontologie peuplée (fichier owl)</td><td>1-8, 11</td><td>-</td><td>Automatique</td></tr></tbody></table>

## 1.3 Technologie du Web Sémantique

Le Web sémantique [Bertails et al. (2010)] constitue une évolution du Web traditionnel, initialement conçu comme un « Web de documents » où l'information était essentiellement présentée sous forme de pages HTML reliées entre elles par des hyperliens. Il repose sur un ensemble de technologies normalisées par le W3C
permettant de représenter, partager, structurer et relier les données.

Le RDF [Özsu (2016)], publié en 1999, constitue la base de ce système. Il décrit l'information sous la forme de triplets composés d'un sujet, d'un prédicat et d'un objet : le sujet correspond à l'entité décrite, le prédicat représente la relation, et l'objet est soit une valeur littérale, soit une autre ressource. Par exemple, le triplet <film/2014, rdfs :label, "The Shining"> exprime que la resource identifiée par film/2014 a pour titre The Shining. Les ressources sont généralement identifiées par des (URI), ce qui garantit leur unicité. Toutefois, (RDF) se limite à une description factuelle des relations, sans réelle sémantique. Pour introduire cette dimension, il est nécessaire de recourir à des schémas tels que RDF Schema et OWL.

* Le RDF Schema (RDFS) [Dan Brickley (2023)], publié en 1999 puis révisé en 2004, est une extension de RDF qui permet de construire des ontologies légères. Il introduit des mécanismes de modélisation et de hiérarchie, en définissant des classes, des sous-classes et des propriétés, ce qui facilite l'organisation sémantique des ressources. Certaines propriétés jouent un rôle fondamental dans la structuration du modèle, notamment rdfs :sub-ClassOf (relation d'héritage entre classes), rdfs :subPropertyOf (hiérarchie entre propriétés), rdf :type (liaison entre une ressource et sa classe), ainsi que rdfs :domain et rdfs :range (définissant respectivement le domaine et le co-domaine d'une propriété).

* Le Web Ontology Language (OWL) [Sean Bechhofer (2009)], publié en 2004, est une extension de RDFS offrant une expressivité bien plus riche pour la définition des ontologies. Grâce à l'intégration de la logique descriptive, OWL permet la déduction de nouvelles connaissances implicites à partir des données existantes.

Le Linked Open Data (LOD) [Bauer and Kaltenböck (2011)], vise à rendre les données non seulement librement accessibles, mais aussi interconnectées de manière cohérente et compréhensible par les machines, OWL joue un rôle central en garantissant l'operability et la reutilisation des ressources. Basé sur les standards du Web sémantique, notamment RDF et l'usage d'URI pour identifier les ressources, le LOD permet de relier différents jeux de données et de créer un véritable « Web de données ». Le modèle des cinq étoiles proposé par Tim
Berners-Lee illustre cette progression : publier les données sur le Web, les struc-
turer, utiliser des formats ouverts, leur attribuer des (URI), et enfin les relier à
d'autres sources pour accroître leur valeur. Cette approche favorise l'interopéra-
bilité entre systèmes, la transparence, la réutilisation optimale des informations
et la génération de nouvelles connaissances.

Enfin, cet écosystème peut être complété par des langages de contraintes tels
que SHACL [K Soman (2019)], standardisé par le W3C. SHACL permet d'ex-
primer et de vérifier des contraintes sur des graphes (RDF) en ajoutant un cadre
formel de validation et de contrôle des données, ce qui est particulièrement utile
dans les domaines où le respect de contraintes techniques et organisationnelles
est essentiel.

1.4 Synthèse

Des états de l’art comparent les approches étudiées. Sequeda et al. (2011) com-
parent sept méthodes de transformation SQL vers OWL ou RDF, en soulignant
l’importance des combinaisons entre clés primaires et étrangères, et les limites
des transformations directes pour refléter la sémantique métier.

Puis, Mosca et al. (2023) analyse treize approches selon la richesse des règles appliquées. Certaines, couvrent jusqu’à 9 règles, tandis que d’autres, se limitent à la transformation du schéma. Les méthodes récentes, dont celles de Ben Mahria et al. (2021); Lakzaei and Shamsfard (2021), apparaissent comme plus complètes. Cet état de l’art conclut à l’absence de standard, et recommande de consolider les meilleures règles existantes. La majorité des travaux précédemment men- tionnés opèrent directement à partir d’une base de donnée relationnelle pour la traduire automatiquement sans intervention humaine. De plus, ces approches ne permettent pas de réutiliser des ontologies de référence pour créer une nouvelle ontologie spécialisant ces éléments. Les articles utilisant les règles 7 et 8 reposent sur l’hypothèse du monde clos<fnref n="2" />, héritée des bases de données ce qui est incom- compatible à l’ontologie. Les ontologies OWL s’inscrivent dans une hypothèse du monde ouvert <fnref n="3" /> favorisant ainsi l’intégration de données. La méthodologie LOT propose un cadre pour le développement d’ontologies [Poveda-Villalón et al.

<footnote n="2">²(qui est l'hypothèse que ce qui n'est pas connu pour être vrai doit être faux. Ainsi ce qui est inscrit dans la base est vrai et ce qui n'est pas inscrit dans la base est faux.)</footnote>

<footnote n="3">³( "ce n'est pas parce qu'on ne connaît pas une information que cette information est fausse.")</footnote>
(2022)], en mettant l'accent sur la ré-utilisabilité. Nous partons de l'hypothèse que nous disposons d'un MCD. Cette hypothèse nous permet de proposer nos propres règles de transformation.
# Chapitre 2

## Solution proposée

### 2.1 Méthode outillée

<figure><img src="image_8.png" /><figcaption>FIGURE 2.1 : Architecture du Système</figcaption></figure>

La figure 2.1 présente notre approche, qui débute par la construction d'un Modèle Conceptuel de Données (MCD) par l'utilisateur, à l'aide de l'outil Drawio et du langage UML. Ce modèle représente les données actuellement stockées sous forme tabulée. Le MCD est ensuite automatiquement traduit grâce à un outil
de conversion et à un ensemble de règles que nous avons définies, afin de générer une version 0 du modèle graphe écrit à l'aide du langage graphique CHOWLK.

## 2.2 Règles de traduction des modèles

Nous allons travailler avec un Modèle Conceptuel de donnée, ainsi nous proposons les règles de transformation suivantes.

### 2.2.1 E2C : Entité vers Classe

Cette règle stipule qu'une entité du modèle conceptuel de la BDR est convertie en classe OWL. Le nom de l'entité est utilisé comme nom de la classe. Ainsi, son URI se compose du préfixe et du nom de l'entité avec la première lettre de chaque mot composant le nom de l'entité en majuscule (prefix :NomEntité). Cette construction se fait de façon automatique.

Exemple : Conversion d'entité figure 2.2

<figure><img src="image_9.png" /><figcaption>FIGURE 2.2 : Exemple de transformation entité vers Classe</figcaption></figure>

Dans notre exemple sur la gestion d'une conférence, l'entité Person se transforme de façon automatique en Classe avec comme URI conf:Person.

### 2.2.2 A2OP : Association vers propriété d'objet

Cette règle indique qu'une association de type entre 2 entités A et B dans le modèle conceptuel de la BDR est convertie en deux propriétés d'objet : une pour relier les individus de la classe A vers les individus de la classe B et sa propriété inverse qui relie les individus de la classe B vers les individus de la classe A.

* La classe A vers la classe B : on a la création d'une propriété d'objet qui relie la classe A à la classe B et qui a pour convention de nommage le préfixe, le mot Has et le nom de l'entité B avec la première lettre de chaque mot composant le nom de l'entité en majuscule (prefix :hasNomB).
* La classe B vers la classe A : on a la création d'une propriété d'objet qui relie la classe B à la classe A et qui a pour convention de nommage le préfixe, du mot Is..Of.., le nom de l'entité A et l'entité B avec la première lettre de chaque mot composant le nom de l'entité en majuscule (prefix :is-NomAOfNomB).

L'association porte des cardinalités différentes qui sont traduites en contrainte de cardinalité entre les individus des classes considérés. L'utilisateur devra vérifier le nom de la propriété d'objet proposé automatiquement par l'outil.

* Une cardinalité de type 0..* —> 0..* génère deux propriétés objet avec les contraintes :

- Une propriété objet avec une cardinalité minimale (MinCardinality) de 0 et une cardinalité maximale (MaxCardinality) de N;

- Et une autre propriété objet (dans le sens inverse) avec également une cardinalité minimale (MinCardinality) de 0 et une cardinalité maximum (MaxCardinality) de N.

* Une cardinalité de type 0..* —> 1..* génère deux propriétés objet avec les contraintes :

- Une propriété objet avec une cardinalité minimale (MinCardinality) de 0 et une cardinalité maximale (MaxCardinality) de N;

- Et une autre propriété objet (dans le sens inverse) avec également une cardinalité minimale (MinCardinality) de 1 et une cardinalité maximum (MaxCardinality) de N.

* Une cardinalité de type 1..* —> 1..* génère deux propriétés objet avec les contraintes :

- Une propriété objet avec une cardinalité minimale (MinCardinality) de 1 et une cardinalité maximale (MaxCardinality) de N;

- Et une autre propriété objet (dans le sens inverse) avec également une cardinalité minimale (MinCardinality) de 1 et une cardinalité maximum (MaxCardinality) de N.

* Une cardinalité de type 1 —> 0..* génère deux propriétés objet avec les contraintes :
- Une propriété objet avec une cardinalité minimale (MinCardinality) de 0 et une cardinalité maximale (MaxCardinality) de N;

- Et une autre propriété objet (dans le sens inverse) avec une cardinalité de 1.

* Une cardinalité de type $1 \rightarrow 1..*$ génère deux propriétés objet avec les contraintes :

- Une propriété objet avec une cardinalité minimale (MinCardinality) de 1 et une cardinalité maximale (MaxCardinality) de N;

- Et une autre propriété objet (dans le sens inverse) avec une cardinalité de 1.

Mais l'utilisateur avec une expérience, peut vérifier si le nom de la propriété d'objet correspond à ses attentes et modifier à sa convenance.

Exemple : Conversion de relation 2.3

<figure><img src="image_10.png" /><figcaption>FIGURE 2.3 : Exemple de transformation de relation vers propriété d'objet</figcaption></figure>

Dans notre exemple sur la gestion d'une conférence, la relation génère deux propriétés d'objet :

De "Document" vers "Person" conf :HasPerson(0..N) et dans le sens inverse de Personne vers Document conf :IsDocumentOfPerson(1..N) de façon automatique. Mais l'utilisateur avec une expérience, peut vérifier si le nom de la propriété d'objet correspond à ses attentes et modifie à sa convenance avec par exemple pour notre cas :

* prov :wasAttributed (0..N) à la place de HasPerson(0..N) avec pour contrainte de cardinalité maximale N et son inverse;
* prov :contributed (1..N) à la place de IsDocumentOfPerson(1..N) avec pour contrainte de cardinalité minimale de 1 et cardinalité maximale N.

### 2.2.3 I2S : Inclusion de clés primaires vers relation SubclassOf

Cette règle indique que si T est une spécialisation de l'entité A alors T sera convertie en une sous-classe de la classe correspondant à l'entité A. Et son URI sera constitué d'un Préfixe et du nom de l'entité **Prefix :NomEntité** de façon automatique, et sera relié avec la classe parente par la relation «rdfs:subClassOf».

Exemple : Conversion de l'Inclusion de clés primaires 2.4

<figure><img src="image_11.png" /><figcaption>FIGURE 2.4 : Exemple de transformation d'inclusion de clés primaires vers relation SubclassOf.</figcaption></figure>

### 2.2.4 A2DP : Attribut vers propriété de type de données

Cette règle indique qu'un Attribut devient une propriété de type de données ou propriété de type annotation

* Un attribut est interprété comme une propriété d'annotation lorsqu'il a pour fonction de documenter, commenter ou décrire un élément. Il ne porte pas de sémantique métier proprement dite, mais permet d'ajouter des données informatives destinées à l'utilisateur humain. Si le type correspond à des termes comme label, description, commentaire, note, texte ou leurs variantes, l'attribut est interprété comme une propriété d'annotation.

* Un attribut est interprété comme une propriété de type de données lorsqu'il représente une information propre à une instance, typiquement une valeur telle que un nombre ou une date. Il s'agit d'une donnée métier attachée à une entité, comme un nom, un identifiant, une taille ou une date de
naissance. Ce type d'attribut est souvent typé avec des classes de type XSD (xsd:string, xsd:integer, xsd date, etc.) dans le modèle graphe.

Cas Particulier : les attributs clé Primaire, Not NULL ou UNIQUE

* Si un attribut est clé Primaire, elle devient une propriété de type de donnée avec une cardinalité de 1 (minCardinality = 1 et maxCardinality = 1), Si cette clé primaire est de type number alors elle peut être abandonnée sinon elle peut être conservée;

* Si un attribut est Not NULL elle est transformée en une propriété OWL avec cardinalité minimale (minCardinality) = 1. Cela garantit que chaque instance de la classe possédant cette propriété doit obligatoirement avoir une valeur;

* Si un attribut est UNIQUE elle est transformée en propriété fonctionnelle (FunctionalProperty), elle est associée à une cardinalité maximale (max-Cardinality) = 1;

* Si un attribut a une borne minimale, cette borne se transforme en cardinalité minimale (minCardinality).

* Si un attribut a une borne maximale cette borne se transforme en cardinalité maximale (maxCardinality).

* Si un attribut a pour type Numérique ou Nombre alors ce type se transforme en xsd:float;

* Si un attribut a pour type Texte ou Description alors ce type se transforme en xsd:string.

Exemple : Conversion d'attribut figure 2.5

Dans notre exemple sur la gestion d'une conférence, les attributs Name et Age deviennent des propriétés de type de données (DataTypeProperty) de la classe Person et l'attribut Description devient une propriété d'annotation (An-notationProperty) car il est une étiquette ou un commentaire pour expliquer la classe Person.
<figure><img src="image_12.png" /><figcaption>FIGURE 2.5 : Exemple de transformation d'attribut vers propriété de type de données.</figcaption></figure>

### 2.2.5 Recommandation

* En relationnel un attribut appartient à une entité, mais en ontologie un datatype property n'appartient pas forcément à une classe donc dans notre cas nous considérons que l'attribut aura un range, mais pas un "domain".

* Dans un cas de spécialisation, il est nécessaire d'établir une relation entre les sous-classes et les classes qui sont en relation avec la classe parente.

Exemple : Conversion relation entre sous-classe et les autres classes figure 2.6

<figure><img src="image_13.png" /><figcaption>FIGURE 2.6 : Exemple de relation entre sous classe et les autres classes.</figcaption></figure>
Exemple : Dans un cas où nous établissons une relation entre les sous-classes Author & Editor et la classe Document respectivement conf :hasAuthor entre la sous-classe Author et la classe Document et conf :hasEditor entre la sous-classe Editor et la classe Document.
# Chapitre 3

# Développement de l'outil MCD2MCO

## 3.1 Présentation générale de la solution

Ce volet du projet s'inscrit dans une volonté d'automatiser la transformation d'un MCD en langage UML en un MCO en langage CHOWLK. CHOWLK constituant une extension du formalisme UML dédiée à la génération d'ontologies, cette étape intermédiaire vise à formaliser de manière explicite les relations, concepts et propriétés nécessaires à la création d'un graphe de connaissances.

L'idée fondatrice de cette démarche repose sur l'utilisation du modèle CHOWLK comme étape pivot entre la modélisation conceptuelle initiale et la génération finale d'une ontologie OWL. L'outil à développer devra ainsi faciliter cette transition en intégrant les règles de transformation définies, tout en garantissant la cohérence sémantique du graphe produit et sa compatibilité avec les standards du Web sémantique.

Le travail réalisé dans ce cadre consiste à concevoir un outil capable d'analyser un fichier .drawio contenant un MCD en UML, et de transformer automatiquement ses éléments afin de produire un nouveau fichier XML compatible avec le langage CHOWLK, tout en restant lisible et éditable dans l'interface de Draw.io. Cette étape est essentielle pour assurer la continuité du flux de modélisation, depuis une représentation intuitive jusqu'à une structure conforme aux exigences des ontologies du Web sémantique.

Pour ce faire, une approche basée sur Python a été adoptée, exploitant la structure du fichier XML non compressé généré par Draw.io. L'outil développé permet d'identifier les différentes entités, attributs et relations du diagramme UML, puis d'appliquer les règles de transformation nécessaires afin de structurer
l'ensemble selon le formalisme CHOWLK.

## 3.2 Structure des fichiers Draw.io en XML

Les fichiers produits par Draw.io (aussi appelé diagrams.net) peuvent être exportés au format XML non compressé, ce qui permet une lecture et une manipulation directe du contenu. Ce format est essentiel lorsqu'on souhaite automatiser des traitements, comme la transformation vers un modèle CHOWLK. Chaque entité UML est représentée par un objet XML contenant du texte, généralement structuré sur plusieurs lignes. Un fichier .drawio en XML repose sur les éléments suivants :

* `<mxGraphModel>` C'est l'élément racine. Il encapsule l'ensemble du diagramme. Il contient généralement un nœud `<root>` qui regroupe tous les éléments visuels;

* `<root>` Il contient tous les composants du diagramme sous forme de balises `<mxCell>`. Chaque mxCell représente un élément graphique du diagramme : classe, attribut, relation, texte, conteneur, etc;

* `<mxCell>` : l'unité de base Chaque élément graphique est représenté par une balise `<mxCell>`, dont les attributs déterminent le rôle et l'apparence de l'élément dans le diagramme. Ces cellules sont identifiables grâce à leurs attributs, notamment :

- id : identifiant unique de la cellule;

- value : texte visible dans le diagramme (par exemple, le nom d'une classe ou d'un attribut);

- vertex="1" qui indique que la cellule est un nœud (entité, attribut, cardinalité...) ou edge="1" : indique que la cellule représente une relation ou un lien entre deux objets (souvent avec les attributs source et target);

- style : l'attribut style joue un rôle fondamental, il encode visuellement (mais de façon textuelle) la nature de l'objet représenté. Il contient des informations sur la forme, la couleur, les flèches, etc.;
- parent : désigne l'élément auquel cette cellule est hiérarchiquement rattachée.

* `<mxGeometry>` Cette balise est imbriquée dans une `<mxCell>`. Elle contient des informations sur la position (x, y), la taille (width, height), et parfois la géométrie des connexions.

Dans le cadre de ce travail, pour **vertex="1"** certains éléments de style ont été exploités comme indicateurs pour distinguer les entités des attributs ou des cardinalités dans un MCD en UML. L'interprétation de ces styles est essentielle pour appliquer correctement les règles de transformation vers CHOWLK.

* **Swimlane** dans l'attribut style est utilisé pour représenter une entité principale. Ce style est généralement appliqué à un conteneur qui regroupe des attributs ou d'autres éléments internes ;

* **Text** : les éléments contenant le mot "text" dans le style sont utilisés pour représenter des attributs ;

* **EdgeLabel** : les éléments contenant ce mot dans le style sont utilisés pour représenter des cardinalités.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mxGraphModel>
  <root>
    <mxCell id="1" value="EntiteA" style="swimlane:fillColor=#fff2cc;" vertex="1" parent="0">
      <mxGeometry x="80" y="100" width="120" height="60" as="geometry"/>
    </mxCell>
    <mxCell id="2" value="EntiteB" style="swimlane:fillColor=#f8cecc;" vertex="1" parent="0">
      <mxGeometry x="300" y="100" width="120" height="60" as="geometry"/>
    </mxCell>
    <mxCell id="3" value="Relation" edge="1" source="1" target="2" style="endArrow=block;strokeColor=#000000;">
      <mxGeometry relative="1" as="geometry"/>
    </mxCell>
  </root>
</mxGraphModel>
```

<caption>FIGURE 3.1 : Exemple de fichier XML brut</caption>

## 3.3 Algorithme

Le script développé lit le fichier .drawio au format texte (XML) et procède comme suit :
3.3.2 Algorithme MCD2MCO

**Algorithm 2** MCD2MCO Entité attribut

Require: *fichierDrawio_xml_mcd*

Ensure: *fichierDrawio_xml_Chowlk*

1: **Variables** : *root*, *tree* ← *fichierDrawio_xml_mcd*

2: *rootElement* : *Element*

3: *mxcells* : *Liste*

4: *tabAttributs_dataType*, *tabAttributs annotation, : tableau

5: *prefix*, *concat_values* : *chaîne*

6: **Begin**

7: Demander à l'utilisateur : "Entrer le préfixe à utiliser"

8: Lire prefix

9: *rootElement* ← *root*.find('..//root')

10: *mxcells* ← *rootElement*.findall('mxCell')

11: # *max_id* représente l'id maximum de tout les ids du fichier

12: *max_id* ← *valeurmaxdesids*

13: **for** cell **in** *mxcells* **do**

14: *style* = *cell*.get('style')or""

15: # S'il y a le terme swimlane dans le style d'une balise alors on a une entité

16: **if** "swimlane" ∈ *style* **then**

17: *cell*.set("style", *NouveauStyleEntite*)

18: *cell*.set("value", prefix + " : "+ *valeurEntite*)

19: *id* ← *cell*.attrib["id"]

20: *tabAttributs_dataType* = []

21: *tabAttributs annotation* = []

22: # S'il y a le terme text dans le style d'une balise alors on a un attribut

23: **for** fils **in** *mxcells* **do**

24: **if** *fils*.get('parent') == *id* **then**

25: # s'il y a texte ou description dans le value d'un attribut alors c'est une annotation

26: **if** ("texte" or "description") **in** *fils*.get("value").lower() **then**

27: Ajouter *fils* à *tabAttributs annotation*

28: **else**

29: Ajouter *fils* à *tabAttributs_dataType*

30: **end if**

31: **end if**

32: **end for**

33: **end if**

34: **end for**

35: *tree* ← Sauvegarder(Ensure, UTF-8, déclaration_XML=True)
<caption>**Algorithm 3** MCD2MCO Entité attribut : suite</caption>

1: **for** cell **in** mxcells **do**
2:     style = cell.get('style') or"
3:     # S'il y a le terme swimlane dans le style d'une balise alors on a une entité
4:     **if** "swimlane" ∈ style **then**
5:         **for** attributAnnotation **in** tab_attrsets_annotation **do**
6:             fils_id = attributAnnotation.get("id")
7:             attributAnnotation.set("style", nouveau_style_attrs)
8:             valeurDeLarelation ← attributAnnotation.get('value') or"
9:         max_id ← max_id + 1
10:        new_edge ← creer_relation(max_id, fils_id, id, valeurDeLarelation)
11:        valeurAnnotation ← f"literal"^xsd : string'
12:        attributAnnotation.set('value', valeurAnnotation)
13:    **end for**
14:    concat_values ← ""
15:    **if** tab_attrsets_datatype **then**
16:        **for** attributDatatype **in** tab_attrsets_datatype **do**
17:            concat_values ← concat_values + prefix + " : "attributDatatype.get('value')
18:        **end for**
19:        premier_fils ← tab_attrsets_datatype[0]
20:        premier_fils.set("value", concat_values)
21:        **for** fils **in** tab_attrsets_datatype[1:] **do**
22:            **if** fils **in** root **then**
23:                root.remove(fils)
24:            **end if**
25:        **end for**
26:    **end if**
27:    **end if**
28: **end for**
29: tree ← Sauvegarder(Ensure, UTF-8, déclaration_XML=True)
**Algorithm 4** Function : creer_relation(max_id,fils_id,parent_id,valeurDeLarelation)

1: new\_edge ← CréerElementXML("mxCell", {
2: id : str(max\_id),
3: edge : "1",
4: parent : "1",
5: source : parent\_id,
6: target : fils\_id,
7: value : prefix + ":" + valeurDeLarelation\_sauf\_le\_type\_de\_donnée,
8: style : "endArrow = classic; strokeColor = #000000; dashed = 1;",
9: )
10: creerSousElementXML(new\_edge, "mxGeometry", {"relative" : "1", "as" : "geometry"})
11: return new\_edge
<caption>**Algorithm 5** MCD2MCO relation : suite</caption>

1: **for** cell **in** mxcells **do**
2:     style = cell.get('style') or"
3:     cell_id = cell.get('id')
4:     parent_id = cell.get('parent')
5:     # S'il y a l'attribut edge dans une balise mxCell alors on a une relation
6:     **if** cell.get('edge') = "1" **then**
7:         **if** "endArrow = none" ∈ style **and** "startArrow=none" ∈ style **then**
8:             valeurSource ←"
9:             valeurTarget ←"
10:        **for** cellSourceTarget **in** mxcells **do**
11:            **if** cellSourceTarget.get('id') == cell.get('source') **then**
12:                valeurSource ← cellSourceTarget.get('value')
13:            **end if**
14:            **if** cellSourceTarget.get('id') == cell.get('target') **then**
15:                valeurTarget ← cellSourceTarget.get('value')
16:            **end if**
17:        **end for**
18:        nouveau_style = style.replace("endArrow = none", "endArrow = classic")
19:        cell.set('style', nouveau_style)
20:        nouvelle_valeur_relation ← prefix + " : " + "is" + valeurSource + "of" + valeurTarget
21:        cell.set('value', nouvelle_valeur_relation)
22:        #Créer une relation inverse
23:        relation_inverse ← ClonerElementXML(cell){
24:            #Mettre à jour les attributs de relation_inverse avec l'id de la relation et un tiret 2 (-2)
25:            relation_inverse.id ← relation_id + "-2"
26:            #Inverser source et target dans la copie
27:            relation_inverse.source ← cell.target
28:            relation_inverse.target ← cell.source
29:            relation_inverse.style ← cell.style
30:            relation_inverse.value ← prefix + " : " + "has" + valeurTarget }
31:            Ajouter relation_inverse à root_element
32:        **end if**
33:    **end if**
34: **end for**
1: **for** cell **in** mxcells **do**
2:     # S'il y a l'attribut edge dans une balise mxCell alors on a une relation
3:     **if** cell.get('edge') = "1" **then**
4:         # Créer l'héritage
5:         **if** "endArrow=block" ∈ style **or** "startArrow=block" ∈ style **then**
6:             cell.style ← "endArrow = open; html = 1; dashed = 1; rounded = 0;"
7:             cell.value ← "&lt; &lt; rdfs : subClassOf &gt; &gt;;"
8:             **end if**
9:         **end if**
10:     # Supprimer les labels de cardinalité
11:     **if** "edgeLabel" ∈ style **then**
12:         Supprimer cell
13:     **end if**
14: **end for**
15: tree ← Sauvegarder(Ensure, UTF-8, déclaration_XML=True)

## 3.4 Difficultés rencontrées lors de la conception de l'outil

La mise en œuvre de l'outil de transformation d'un MCD vers une structure compatible avec CHOWLK a révélé plusieurs difficultés, tant au niveau technique que graphique. Ces limitations ont influencé les choix d'implémentation et restent, pour certaines, encore non résolues.

* Altération de l'affichage dans Draw.io après transformation : L'enrichissement du fichier XML d'origine par l'ajout de nouvelles relations et la modification des styles des attributs entraîne des dysfonctionnements d'affichage dans l'éditeur Draw.io. En particulier, on observe des déplacements invokontaires de regroupements, notamment lorsque des attributs sont modifiés ou transformés vers des structures CHOWLK. Ces déplacements nuisent à la lisibilité du schéma final, pourtant toujours techniquement valide. À ce stade du développement, aucune solution stable n'a encore été identifiée pour préserver la disposition initiale tout en appliquant les styles attendus pour la transformation CHOWLK.

* Positionnement de la flèche "inverse of" entre deux relations : Lorsqu'une relation est marquée comme l'inverse d'une autre, CHOWLK représente
ce lien par une flèche perpendiculaire reliant les deux relations concernées, souvent annotée inverseOf. La génération de cette relation supplémentaire pose deux problèmes :

- D'une part, le positionnement automatique de la flèche est difficile à calculer, car elle ne relie pas deux classes, mais deux relations (Ce que Draw.io ne gère pas nativement comme une connexion directe);

- D'autre part, en l'absence de coordonnées précises, la flèche "inverse of" se superpose parfois à d'autres éléments ou n'apparaît pas de manière lisible.

Jusqu'à présent, aucun positionnement automatique satisfaisant n'a pu être obtenu, en raison des contraintes du format XML et du moteur de rendu de Draw.io. Ce point reste ouvert et pourrait nécessiter une solution externe ou une manipulation manuelle dans le fichier final.

## 3.5 Implémentation technique en Python et Streamlit

L'outil a été développé en Python et Streamlit, pour sa simplicité de gestion des fichiers, de parsing XML, et sa compatibilité multi-plateforme.

<figure><img src="image_14.png" /><figcaption>FIGURE 3.2 : Images Python et Streamlit.</figcaption></figure>

## 3.6 Description des interfaces de l'outil

L'outil MCD2MCO intègre une interface graphique développée avec Streamlit, permettant à l'utilisateur de transformer de manière intuitive un fichier UML
au format drawio vers un fichier XML conforme au langage CHOWLK. Cette
interface vise à rendre le processus de transformation accessible à des utilisateurs
non-spécialistes du traitement XML ou du code.

Le dépôt GitHub du projet contient l'ensemble du code source et est acces-
sible à l'adresse suivante : MCD2MCO

**3.6.1 Interface d'accueil**

À l'ouverture de l'interface web, l'utilisateur est accueillis par un tableau de
bord simple et épuré, offrant les fonctionnalités suivantes :

* Téléversement du fichier XML : un champ dédié permet de charger un fichier .drawio.xml non compressé;

* Zone de saisie du préfixe d'ontologie : Une seconde zone est prévue pour saisir le préfixe de l'ontologie que l'utilisateur souhaite intégrer dans le fichier CHOWLK. Ce préfixe est utilisé pour nommer les classes et propriétés générées, garantissant une cohérence avec les conventions de nommage dans le Web sémantique;

* Bouton lancer le traitement : permet d'exécuter le traitement en arrière-plan.

<figure><img src="image_15.png" /><figcaption>FIGURE 3.3 : Image Interface d'accueil</figcaption></figure>
### 3.6.2 Interface de sortie

Une fois la transformation lancée, l'outil distingue deux cas selon la validité structurelle du fichier :

* Cas 1 : Fichier contenant des erreurs

L'algorithme vérifie automatiquement si les relations entre entités sont correctement positionnées et conformes aux règles de transformation (par exemple, si chaque relation dispose bien d'une source et d'un target valide). Lorsque des incohérences sont détectées, le système :

- Affiche un message d'erreur en rouge via l'interface Streamlit;

- Détaille les erreurs identifiées;

- Génère une version modifiée du fichier XML dans laquelle les éléments en erreur sont mis en évidence visuellement (en rouge) dans Draw.io, afin de faciliter leur correction.

<figure><img src="image_16.png" /><figcaption>FIGURE 3.4 : Image interface de sortie avec erreur</figcaption></figure>
* Cas 2 : Fichier sans erreur

Si aucune erreur n'est détectée, la transformation complète est effectuée automatiquement. Le fichier généré respecte alors les spécifications attendues pour le format CHOWLK, et peut directement être converti en ontologie OWL via le CHOWLK Converter.

<figure><img src="image_17.png" /><figcaption>FIGURE 3.5 : Image interface de sortie sans erreur</figcaption></figure>
* Téléchargement du fichier transformé :

Dans les deux cas (avec ou sans erreur), l'interface affiche un bouton de téléchargement permettant à l'utilisateur de récupérer le fichier .drawio.xml généré. Ce fichier peut être rouvert dans Draw.io pour vérification visuelle ou modification.
# Chapitre 4

## Résultats et Évaluation

L'évaluation du travail réalisé a été conduite en deux volets : d'une part, la production de modèles conceptuels à partir de jeux de données réels ; d'autre part, la validation des MCO par l'outil à travers des vérifications syntaxiques et des tests concrets sur des cas d'usage.

### 4.1 Production des Modèles Conceptuels de Données

Deux jeux de données ont été mobilisés pour construire les modèles conceptuels initiaux (MCD) utilisés dans les expérimentations :

#### 4.1.1 Cas d'usage 1 projet STAR

##### 4.1.1.1 contexte

Le projet est organisé autour d'une coordination opérationnelle assurée par un chef de projet et quatre responsables d'actions issus principalement de plusieurs partenaires.

Le projet met en œuvre une démarche structurée de gestion des données, centrée sur la normalisation, l'interopérabilité et la qualité des informations collectées. La collecte de données repose sur la mise en place de jeux de données issus de projets existants, ainsi que sur de nouvelles expérimentations menées par des expérimentateurs, qui exploitent des outils standardisés pour l'acquisition des données. Les données sont recueillies via des outils participatifs, des bases de données expérimentales et des plateformes numériques. Le traitement des données inclut leur harmonisation, leur vérification et leur enrichissement
automatisé par moissonnage. Des outils d'analyse standardisés, accessibles via R ou autres plateformes, facilitent l'analyse statistique et la visualisation. Enfin, le partage des données est encouragé par des dépôts ouverts (GitHub, HAL, recherche.data.gouv), permettant une réutilisation par des partenaires extérieurs, tout en respectant les règles de propriété intellectuelle et de confidentialité.

Dans le cadre de ce travail, Xavier Delpuech ingénieur agronome à l'IFV, a mis sur pied un Modèle Conceptuel de Données MCD à partir de l'ensemble de données fourni par le Projet STAR, dans le contexte d'un projet de recherche portant sur les solutions de biocontrôle. Cet ensemble de données, structurant des informations issues d'observations de terrain, de traitements appliqués aux cultures et de paramètres environnementaux, a été utilisé comme base pour formaliser un MCD dans Draw.io.

Le MCD ainsi conçu comprend plusieurs entités clé telles que les Unités Expérimentales, Observation, Variable, etc., ainsi que leurs relations logiques. Ce modèle a servi de cas d'étude central pour tester l'outil de transformation, depuis la modélisation graphique jusqu'à la génération automatique d'un fichier CHOWLK conforme.
<figure><img src="image_18.png" /><figcaption>FIGURE 4.1 : MCD partiel issue données STAR</figcaption></figure>

4.1.1.2 Résultat de la transformation du MCD du projet STAR

La figure 4.2 illustre le résultat de la transformation du MCD issu du projet
STAR en MCO, conformément aux règles de transformation définies dans ce
travail.
<figure><img src="image_19.png" /><figcaption>FIGURE 4.2 : Résultat du MCO sur le MCD du projet STAR</figcaption></figure>
Afin de mieux appréhender les effets de cette transformation, le tableau ci-dessous présente une comparaison quantitative entre les éléments du MCD et ceux du MCO généré.

<table><caption>TABLE 4.1 : tableau comparatif du MCD et MCO de STAR</caption><thead><tr><th>Élément modélisé</th><th>MCD</th><th>MCO</th></tr></thead><tbody><tr><td>Nombre de classes (entités)</td><td>13</td><td>13</td></tr><tr><td>Relations</td><td>15</td><td>28 propriétés d'objet</td></tr><tr><td>Attributs</td><td>33</td><td>10 Propriétés de type de données<br>23 Propriétés d'annotation</td></tr></tbody></table>

## 4.1.2 Cas d'usage 2 format de Données ICASA

### 4.1.2.1 Contexte

En complément des données STAR, un second cas d'usage a été mobilisé pour tester la robustesse de l'outil. Ce travail s'inscrit dans une démarche plus large visant à intégrer le format de donnée ICASA White et al. (2013) dans le système de gestion des données d'expérimentation OpenSILEX. Le format de donnée ICASA, reconnu internationalement comme étant le format d'échange standardisé pour la description des essais agricoles, offre une structuration fine des données expérimentales. Elle facilite l'échange, l'analyse et la comparaison des données expérimentales à travers l'utilisation de formats numériques variés tels que les fichiers texte, bases de données et feuilles de calcul. En assurant une structuration cohérente et flexible, ICASA facilite la reproduction des expériences, la modélisation des systèmes agricoles et la synthèse des résultats pour diverses disciplines. La norme est conçue pour s'adapter à divers besoins de recherche et peut évoluer pour inclure de nouvelles variables, comme la gestion des ravageurs ou la qualité des données.

Dans ce cadre, Farzaneh Kazemi Pour, ingénieur agronome à l'unité MIS-TEA, a élaboré un MCD à partir des spécifications du format ICASA, en présentant les différentes entités. Le modèle a été structuré sous forme de MCD dans Draw.io en respectant les conventions nécessaires à sa transformation en modèle CHOWLK.
<figure><img src="image_20.png" /><figcaption>FIGURE 4.3 : MCD Partiel issue des données ICASA</figcaption></figure>

4.1.2.2 Résultat de la transformation du MCD du format de Données ICASA

La figure 4.4 illustre le résultat de la transformation du MCD issu des données
ICASA en MCO, conformément aux règles de transformation définies dans ce
travail.
<figure><img src="image_21.png" /><figcaption>FIGURE 4.4 : Résultat du MCO sur le MCD du projet STAR</figcaption></figure>

Afin de mieux appréhender les effets de cette transformation, le tableau ci-dessous présente une comparaison quantitative entre les éléments du MCD et ceux du MCO généré.
<table><caption>TABLE 4.2 : tableau comparatif du MCD et MCO de ICASA</caption><thead><tr><th>Élément modélisé</th><th>MCD</th><th>MCO</th></tr></thead><tbody><tr><td>Nombre de classes (entités)</td><td>09</td><td>09</td></tr><tr><td>Relations</td><td>8</td><td>16 propriétés d'objet</td></tr><tr><td>Attributs</td><td>16</td><td>03 Propriétés de type de données<br>13 Propriétés d'annotation</td></tr></tbody></table>

## 4.2 Évaluation du MCO

Une fois les modèles conceptuels produits et transformés à l'aide de l'outil MCD2MCO, une phase d'évaluation a été réalisée afin de vérifier la validité du MCO généré et sa capacité à être utilisé dans le processus de génération d'ontologies OWL.

### 4.2.1 Évaluation syntaxique avec l'outil CHOWLK Converter

Les fichiers XML produits par l'outil ont été soumis au CHOWLK Converter [Chávez-Feria et al. (2021)], un convertisseur conforme aux spécifications du langage CHOWLKChávez-Feria et al. (2022) permettant de générer automatiquement une ontologie OWL à partir d'un graphe structuré. Cette étape a permis de vérifier la conformité syntaxique des MCO générés. Aucune erreur bloquante n'a été relevée lors du processus de conversion, ce qui atteste de la validité structurelle et formelle des fichiers en sortie de l'outil.

### 4.2.2 Évaluation par validation avec Protégé

Les cinq dernières lignes affichées dans la section "Object Property" de l'image 4.5 de Protégé montrent clairement que les propriétés d'annotation ont été incorrectement transformées en propriétés d'objet. Cette erreur indique une mauvaise transformation syntaxique de certains attributs lors de la génération du MCO par l'outil MCD2MCO. Ce qui affecte la qualité de l'ontologie produite.
<figure><img src="image_22.png" /><figcaption>FIGURE 4.5 : Exemple de résultat de l'ontologie OWL dans Protégé cas de STAR.</figcaption></figure>

4.2.3 Limites observées

Lors du processus de transformation du MCD en MCO, un point de blocage
récurrent a concerné la distinction entre les propriétés de type de données et les
propriétés d'annotation. En effet, certains attributs tels que les champs de type
texte, descriptions peuvent, selon le contexte, être interprétés soit comme des
propriétés de type de données, soit comme des propriétés d'annotation. Cette
distinction ne peut pas être tranchée automatiquement par l'outil, car elle dé-
pend de l'intention de modélisation. Par conséquent, une intervention humaine
est indispensable à cette étape, afin d'ajuster le MCO manuellement avant sa
conversion en OWL via CHOWLK converter. Ce besoin d'arbitrage confirme
que, malgré l'automatisation partielle du processus, l'expertise humaine reste
essentielle pour garantir la cohérence et la pertinence du modèle généré.
# Chapitre 5

## Conclusion et perspectives

### 5.1 Conclusion

Ce mémoire s'inscrit dans une démarche de valorisation et de structuration des données agronomiques en s'appuyant sur les technologies du Web sémantique. Il répond à un besoin croissant d'interopérabilité, de ré-utilisabilité et d'exploitation des données, dans un contexte où ces dernières sont souvent cachées, redondantes ou faiblement documentées.

L'objectif principal de ce travail était de proposer une méthode permettant de transformer un MCD en un MCO en langage CHOWLK, puis en une ontologie OWL. Pour ce faire, un outil spécifique appelé MCD2MCO a été développé en Python, avec une interface utilisateur réalisée à l'aide de Streamlit. Cet outil permet de traiter automatiquement des fichiers UML exportés depuis Draw.io en XML, et de produire un MCO conforme aux exigences du CHOWLK Converter.

Une attention particulière a été portée à la mise en place des règles de transformation entre les éléments du MCD et les concepts ontologiques (classes, propriétés). Ces règles ont été élaborées à partir d'une étude approfondie de la littérature et validée à travers deux cas d'usage concrets, le modèle de données du projet STAR et le format d'échange ICASA, tous deux issus de contextes agronomiques réels.

Les résultats obtenus ont permis de démontrer la faisabilité technique de cette approche, tout en mettant en évidence les limites de l'automatisation complète et la nécessité d'une intervention humaine ciblée dans certaines étapes du processus. Néanmoins, cette méthode contribue à réduire significativement la charge de travail manuel en facilitant la transformation du MCD en MCO, lequel pourra,
par la suite, être modifié selon les besoins de l'utilisateur, puis converti automa-
tiquement en ontologie OWL à l'aide du CHOWLK Converter. Cette ontologie
pourra ensuite être publiée, comme évoquée dans les perspectives, afin d'assurer
sa diffusion, sa ré-utilisabilité et sa pérennité dans un écosystème sémantique
ouvert.

5.2 Perspectives

Ce travail ouvre plusieurs pistes d'amélioration et d'extension :

* Une première amélioration envisagée concerne la gestion des propriétés d'annotation, dont certaines ont été incorrectement transformées en propriétés d'objet lors du processus de conversion en ontologie ;

* Ensuite dans une démarche alignée avec les principes de la méthode LOT, il devient essentiel de prévoir la publication des ontologies générées.

De ce fait l'architecture ci-dessous figure 5.1¹ [Choumele and Roussey (2025)] présente une perspective plus détaillée de notre travail, la première partie de cette architecture représente l'architecture de notre travail vue à la figure 2.1

<figure><img src="image_23.png" /><figcaption>FIGURE 5.1 : Perspectives de l'architecture</figcaption></figure>

Source : Choumele and Roussey (2025)

<footnote n="1">¹Une version plus grande de l'image est disponible sur https://forgemia.inra.fr/star_casdar/stagedigitag2025/-/blob/main/many_tomany-Page-10.png</footnote>
Le MCO en CHOWLK généré précédemment dans notre travail sera ensuite enrichi grâce à des ontologies de référence et validé manuellement par l’utilisateur. À l’issue de cette phase, deux artefacts seront produits :

* un fichier CSV (version D) contenant les labels des éléments de l'ontologie;

* un MCO (version A) écrit à l'aide du langage graphique CHOWLK.

Le MCO (version A) est converti en un fichier OWL (version X) de l'ontologie grâce à l'outil CHOWLK Converter. Ce processus d'enrichissement, de validation et de conversion sera répété en boucle, jusqu'à obtention d'une version du MCO en CHOWLK (version X) considéré comme complet et du fichier CSV (version D) associé.

Pour permettre la publication de l'ontologie, un certain nombre d'éléments doivent être mis en place. Le fichier CSV (version D) des annotations des éléments de l'ontologie et le MCO en CHOWLK (version X) sont utilisés comme entrée par un grand modèle de langages (LLM) tel que gpt4[Achiam et al. (2023)] ou mistral [Jiang et al. (2024)]. Le LLM génère automatiquement des propositions de définition pour chaque élément de l'ontologie et produit donc une nouvelle version du fichier CSV (version D + E) et de l'ontologie OWL (version X+Y). L'ontologie OWL est ensuite soumise à une validation humaine pour générer une version finale. Ce processus est également répété jusqu'à obtention d'une ontologie en OWL complète (version X+Y+Z).

Enfin, l'ontologie OWL (version X+Y+Z) est utilisée pour générer la documentation HTML de l'ontologie à l'aide de l'outil LODE [Peroni et al. (2012)]. Ce processus est également itératif jusqu'à obtention d'une documentation HTML et d'une ontologie complète (version X+Y+Z). À l'issue de l'ensemble de ces processus, nous pouvons publier la documentation HTML.
Bibliographie

Csongor Nyulas (2008). Datamaster. https://protegewiki.stanford.edu/wiki/OntoBase. Consulté en mai 2025.

Achiam, J., Adler, S., Agarwal, S., Ahmad, L., Akkaya, I., Aleman, F. L., Almeida, D., Altenschmidt, J., Altman, S., Anadkat, S., et al. (2023). Gpt-4 technical report. arXiv preprint arXiv:2303.08774.

Alobaid, A., Garijo, D., Poveda-Villalón, M., Santana-Perez, I., Fernández-Izquierdo, A., and Corcho, O. (2019). Automating ontology engineering support activities with ontology. Journal of Web Semantics, 57:100472.

Bakkas, J., Bahaj, M., and Marzouk, A. (2013). Direct migration method of rdb to ontology while keeping semantics. *International Journal of Computer Applications*, 65(3).

Barrasa, J., Corcho, O., and Gómez-Pérez, A. (2003). Fund finder : A case study of database-to-ontology mapping. In *Semantic Integration Workshop (SI-2003)*, volume 9.

Barrasa Rodríguez, J., Corcho, Ó., and Gómez-Pérez, A. (2004). R2o, an extensible and semantically based database-to-ontology mapping language.

Bauer, F. and Kaltenböck, M. (2011). Linked open data : The essentials. *Edition mono/monochrom*, Vienna, 710(21).

Bechhofer, S. (2018). Owl : Web ontology language. In *Encyclopedia of database systems*, pages 2640–2641. Springer.

Ben Mahria, B., Chaker, I., and Zahi, A. (2021). A novel approach for learning ontology from relational database : from the construction to the evaluation. *Journal of Big Data*, 8(1):25.
Bertails, A., Herman, I., and Hawke, S. (2010). Le web sémantique. In *Annales des Mines-Réalités industrielles*, volume 2010, pages 84-89. Eska.

Bouougada, B., Bouchiha, D., Rebhi, R., Kidar, A., Lorenzini, G., Bouziane, A., Ahmad, H., Menni, Y., et al. (2021). Mapping relational database to owl ontology based on mde settings. *Rev. d'Intelligence Artif.*, 35(3):217-222.

Chávez-Feria, S., García-Castro, R., and Poveda-Villalón, M. (2021). Converting uml-based ontology conceptualizations to owl with chowlk. In *European Semantic Web Conference*, pages 44-48. Springer.

Chávez-Feria, S., García-Castro, R., and Poveda-Villalón, M. (2022). Chowlk : from uml-based ontology conceptualizations to owl. In *European Semantic Web Conference*, pages 338-352. Springer.

Choumele, N. L. M. and Roussey, C. (2025). Construction d'ontologie à partir de modèle conceptuel de données. In *8ème édition de l'Atelier INtégration de sources/masses de données hétérogènes et Ontologies, dans le domaine des sciences du VIVant et de l'Environnement IN-OVIVE, adossé à la conférence Ingénierie des Connaissances@ PFIA*, page 6p.

Corman, J., Reutter, J. L., and Savković, O. (2018). Semantics and validation of recursive shacl. In *International Semantic Web Conference*, pages 318-336. Springer.

Da Silva, A. R. (2015). Model-driven engineering : A survey supported by the unified conceptual model. *Computer languages, systems & structures*, 43 :139-155.

Dadjoo, M. and Kheirkhah, E. (2015). An approach for transforming of relational databases to owl ontology. *arXiv preprint arXiv :1502.05844*.

Dan Brickley, R. G. (2023). Rdf schema. https://www.w3.org/TR/rdf-schema. Consulté en juillet 2025.

Fensel, D., Şimşek, U., Angele, K., Huaman, E., Kärle, E., Panasiuk, O., Toma, I., Umbrich, J., and Wahler, A. (2020). Introduction : what is a knowledge graph ? In *Knowledge graphs : Methodology, tools and selected use cases*, pages 1-10. Springer.
Fernández-Izquierdo, A. and García-Castro, R. (2019). Themis : a tool for validating ontologies through requirements. In *SEKE*, pages 573–753.

Fernández-López, M., Gómez-Pérez, A., and Juristo Juzgado, N. (1997). Metontology : from ontological art towards ontological engineering.

Ghani, R. and Cullot, N. (2007). Database-to-ontology mapping generation for semantic interoperability. In *Third international workshop on database interoperability (InterDB 2007)*, volume 91. Citeseer.

Hazber, M. A., Li, R., Gu, X., and Xu, G. (2016). Integration mapping rules : Transforming relational database to semantic web ontology. *Appl. Math*, 10(3) :1–21.

Hlomani, H. and Stacey, D. (2014). Approaches, methods, metrics, measures, and subjectivity in ontology evaluation : A survey. *Semantic Web Journal*, 1(5) :1–11.

Horridge, M., Gonçalves, R. S., Nyulas, C. I., Tudorache, T., and Musen, M. A. (2019). Webprotégé : A cloud-based ontology editor. In *Companion proceedings of the 2019 world wide web conference*, pages 686–689.

Huve, C. A. G., Porn, A. M., and Peres, L. M. (2019). Architecture for mapping relational database to owl ontology : An approach to enrich ontology terminology validated with mutation test. In *ICEIS (2)*, pages 320–327.

Jia, Y. and Harman, M. (2010). An analysis and survey of the development of mutation testing. *IEEE transactions on software engineering*, 37(5) :649–678.

Jiang, A. Q., Sablayrolles, A., Roux, A., Mensch, A., Savary, B., Bamford, C., Chaplot, D. S., Casas, D. d. l., Hanna, E. B., Bressand, F., et al. (2024). Mixtral of experts. *arXiv preprint arXiv :2401.04088*.

Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I., and Valduriez, P. (2006). Atl : a qvt-like transformation language. In *Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications*, pages 719–720.
K Soman, R. (2019). Modelling construction scheduling constraints using shapes constraint language (shacl). In *EC3 Conference 2019*, volume 1, pages 351–358. European Council on Computing in Construction.

Ketata, M. A., Lüdke, D., Schwinn, L., and Günnemann, S. (2025). Joint relational database generation via graph-conditional diffusion models. *arXiv preprint arXiv:2505.16527*.

Lakzaei, B. and Shamsfard, M. (2021). Ontology learning from relational databases. *Information Sciences*, 577:280–297.

Len Yabloko (2009). Ontobase. https://protegewiki.stanford.edu/wiki/OntoBase. Consulté en mai 2025.

Li, M., Du, X.-Y., and Wang, S. (2005). Learning ontology from relational database. In *2005 International conference on machine learning and cybernetics*, volume 6, pages 3410–3415. IEEE.

Ling, H. and Zhou, S. (2013). Mapping relational databases into owl ontology. *International Journal of Engineering and Technology*, 5(6):4735–4740.

Lourdusamy, R. and John, A. (2018). A review on metrics for ontology evaluation. In *2018 2nd International conference on inventive systems and control (ICISC)*, pages 1415–1421. IEEE.

Miles, A. and Pérez-Agüera, J. R. (2007). Skos: Simple knowledge organisation for the web. *Cataloging & Classification Quarterly*, 43(3-4):69–83.

Mogotlane, K. D. and Fonou-Dombeu, J. V. (2016). Automatic conversion of relational databases into ontologies: a comparative analysis of prot\'eg\'e plug-ins performances. *arXiv preprint arXiv:1611.02816*.

Mosca, R., De Santo, M., and Gaeta, R. (2023). Ontology learning from relational database: a review. *Journal of ambient intelligence and humanized computing*, 14(12):16841–16851.

Musen, M. A., Gennari, J. H., Eriksson, H., Tu, S. W., and Puerta, A. R. (1995). Protege-ii: computer support for development of intelligent systems from libraries of components. *Medinfo*, 8(Pt 1):766–770.
Noy, N. F., McGuinness, D. L., et al. (2001). Ontology development 101 : A guide to creating your first ontology.

Özsu, M. T. (2016). A survey of rdf data management systems. *Frontiers of Computer Science*, 10(3):418-432.

Pérez, J., Arenas, M., and Gutierrez, C. (2009). Semantics and complexity of sparql. *ACM Transactions on Database Systems (TODS)*, 34(3):1-45.

Peroni, S., Shotton, D., and Vitali, F. (2012). The live owl documentation environment : a tool for the automatic generation of ontology documentation. In *International Conference on Knowledge Engineering and Knowledge Management*, pages 398-412. Springer.

Posea, V. and Harzallah, M. (2004). Ontologies : Définition et applications. *Une*, 5:6.

Poveda-Villalón, M., Fernández-Izquierdo, A., Fernández-López, M., and García-Castro, R. (2022). Lot : An industrial oriented ontology engineering framework. *Engineering Applications of Artificial Intelligence*, 111:104755.

Poveda-Villalón, M., Gómez-Pérez, A., and Suárez-Figueroa, M. C. (2014). Oops!(ontology pitfall scanner!) : An on-line tool for ontology evaluation. *International Journal on Semantic Web and Information Systems (IJSWIS)*, 10(2):7-34.

Roques, P. (2021). *UML 2.5 par la pratique : Etudes de cas et exercices corrigés*. Editions Eyrolles.

Salem, N., Al-Tarawneh, K., Hudaib, A., Salem, H., Tareef, A., Salloum, H., and Mazzara, M. (2024). Generating database schema from requirement specification based on natural language processing and large language model. , 16(7):1703-1713.

Sean Bechhofer, Frank van Harmelen, J. H. I. H. D. L. M. P. F. P.-S. L. A. S. (2009). Owl. https://www.w3.org/TR/owl-ref/. Consulté en juillet 2025.

Sean Falconer (2010). Ontograf. https://protegewiki.stanford.edu/wiki/OntoGraf. Consulté en mai 2025.
Sequeda, J. F., Tirmizi, S. H., Corcho, O., and Miranker, D. P. (2011). Survey of directly mapping sql databases to the semantic web. *The Knowledge Engineering Review*, 26(4):445–486.

Sicilia, M.-Á., Rodríguez, D., García-Barriocanal, E., and Sánchez-Alonso, S. (2012). Empirical findings on ontology metrics. *Expert Systems with Applications*, 39(8):6706–6711.

Steinberg, D., Budinsky, F., Merks, E., and Paternostro, M. (2008). *EMF : eclipse modeling framework*. Pearson Education.

Suárez-Figueroa, M. C., Gómez-Pérez, A., and Fernández-López, M. (2011). The neon methodology for ontology engineering. In *Ontology engineering in a networked world*, pages 9–34. Springer.

Tartir, S., Arpinar, I. B., Moore, M., Sheth, A. P., and Aleman-Meza, B. (2005). *Ontoqa : Metric-based ontology quality analysis*.

White, J. W., Hunt, L., Boote, K. J., Jones, J. W., Koo, J., Kim, S., Porter, C. H., Wilkens, P. W., and Hoogenboom, G. (2013). Integrated description of agricultural field experiments and production : The icaSA version 2.0 data standards. *Computers and electronics in agriculture*, 96:1–12.

Zhang, L. and Li, J. (2011). Automatic generation of ontology based on database. *Journal of Computational Information Systems*, 7(4):1148–1154.