République Tunisienne

Ministère De l’Enseignement Supérieur Et De La Recherche Scientifique

Université De Tunis El Manar
Faculté Des Sciences De Tunis

Département Des Sciences de l’Informatique

arXiv:2006.02862v1 [cs.DB] 30 May 2020

MÉMOIRE DE MASTÈRE

Présenté en vue de l’obtention du

Diplôme de Mastère de recherche en Informatique

Emna JEBRI
Licence Fondamentale en Informatique de Gestion
Faculté des Sciences Économiques et de Gestion de Tunis

PROPOSITION D’UNE NOUVELLE

MÉTHODE DE GÉNÉRATION DE
REQUÊTES SPARQL A PARTIR DE
GRAPHES RDF

Soutenu le 21/02/2018 devant le jury composé de :

Président M. Faouzi MOUSSA, Professeur à la FST

Rapporteur M. Sami ZGHAL, Maître-Assistant à la FSEGJ
Directeur M. Sadok BEN YAHIA, Professeur à la FST

Laboratoire en Informatique en Programmation Algorithmique et

Heuristique - LIPAH -
2017 - 2018
 À moi-même
À mon père
À ma mère
À toute ma famille
Et mes amis
 REMERCIEMENTS

Je remercie Monsieur Sadok BEN YAHIA, Professeur à la Faculté des Sciences de Tunis,
de m’avoir guidé tout au long de ce mémoire, de m’avoir apporté ses précieuses lumières, et
surtout de m’avoir appris à mener par moi-même un travail de recherche. Sans ses conseils,
ce mémoire n’aurait tout simplement pas existé.

Je remercie également Monsieur Faouzi MOUSSA, Professeur à la Faculté des Sciences

de Tunis, de m’avoir fait l’honneur de présider le jury de ma soutenance.

Je tiens à remercier Monsieur Sami ZGHAL, Maître-Assistant à la Faculté des Sciences

juridique Économique et de Gestion de Jendouba, d’avoir accepté d’être membre du jury en
tant que rapporteur.
Table des matières

Table des figures iv

Liste des tableaux vi

Introduction Générale 1

1 Fondement du Web sémantique 4

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 L’évolution du Web sémantique . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Les défis du Web sémantique . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Les objectifs du Web sémantique . . . . . . . . . . . . . . . . . . . . 8
1.3 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Revue sur les définitions d’une ontologie . . . . . . . . . . . . . . . . 9
1.3.2 Constituants d’une ontologie . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2.1 Connaissances et domaine de connaissances . . . . . . . . . 11
1.3.2.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2.3 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2.4 Axiomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Langages de représentation des ontologies . . . . . . . . . . . . . . . . . . . . 15
1.4.1 XML et XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.2 RDF et RDF Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.3 OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.3.1 OWL 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.3.2 OWL 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Types d’hétérogénéité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Revue sur l’interrogation des graphes RDF 22

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Définitions : Standards, Protocoles et Outils . . . . . . . . . . . . . . . . . . 22
2.2.1 Stockage des données RDF . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1.1 Bases de données RDF (BD-RDF) . . . . . . . . . . . . . . 23
2.2.1.1.a Historique des BD-RDF . . . . . . . . . . . . . . . . 25

i
 2.2.1.1.b RDF stores . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1.1.c BD-RDF non natives . . . . . . . . . . . . . . . . . . 27
2.2.1.1.d BD-RDF natives . . . . . . . . . . . . . . . . . . . . 28
2.2.1.1.e Différences entre RDF Store et BD-RDF . . . . . . . 29
2.2.2 Moteurs de raisonnement et saturation de données . . . . . . . . . . . 30
2.2.2.1 Saturation des données . . . . . . . . . . . . . . . . . . . . . 30
2.2.2.2 Reformulation des requêtes . . . . . . . . . . . . . . . . . . 31
2.2.3 Le langage d’interrogation de graphes RDF : SPARQL . . . . . . . . 31
2.2.3.1 Patron de triplet (TP) et patron de graphe (BGP) . . . . . 32
2.2.3.1.a Définition formelle d’un patron de triplet et d’un pa-
tron de graphe . . . . . . . . . . . . . . . . . . . . . 33
2.2.3.2 Avantages de SPARQL . . . . . . . . . . . . . . . . . . . . . 33
2.2.3.3 Limitations de SPARQL . . . . . . . . . . . . . . . . . . . . 33
2.3 Revue sur les différents travaux de comparaison des BD-RDF . . . . . . . . . 35
2.4 Revue sur les méthodes existantes pour l’interrogation par des requêtes SPARQL
des graphes RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.1 Quelques approches existantes pour l’interrogation par mots-clés . . . 50
2.5 Discussion et Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3 Proposition d’une nouvelle approche de génération de requêtes SPARQL

à partir de graphes RDF 56
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2 Problématique et motivations dans le contexte d’interrogation des graphes RDF 56
3.3 La base de données graphique Neo4j . . . . . . . . . . . . . . . . . . . . . . 57
3.3.1 Architecture de Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.1.1 Nœuds et relations . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.1.2 APIs de Neo4j et le langage Cypher . . . . . . . . . . . . . 59
3.3.1.2.a API kernel . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.1.2.b Core API . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.1.2.c Le traversal Framework . . . . . . . . . . . . . . . . . 60
3.3.1.2.d Cypher . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.2 Avantages de Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4 Description de la nouvelle méthode d’interrogation OntoNeo . . . . . . . . 61
3.4.1 Phase 1 : Analyse (Parsing) de l’ontologie . . . . . . . . . . . . . . . 62
3.4.2 Phase 2 : Génération des triplets RDF . . . . . . . . . . . . . . . . . 63
3.4.3 Phase 3 : Chargement des triplets RDF dans Neo4j . . . . . . . . . . 66
3.4.4 Phase 4 : Interrogation de la BD Neo4j . . . . . . . . . . . . . . . . . 67
3.4.4.1 Étape de l’analyse de la requête utilisateur . . . . . . . . . 68
3.4.4.2 Étape de la génération de requêtes SPARQL-DL . . . . . . 70
3.4.4.3 Étape de transformation/équivalence des requêtes SPARQL-
DL en des requêtes Cypher . . . . . . . . . . . . . . . . . . 71
3.5 Interface de recherche et les différentes approches de réponse aux requêtes . . 73
3.5.1 Interface de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

ii
 3.5.2 Les approches de réponse aux requêtes . . . . . . . . . . . . . . . . . 74
3.5.2.1 Affichage de toutes les informations à l’utilisateur . . . . . . 74
3.5.2.1.a Le cas d’un seul mot-clé . . . . . . . . . . . . . . . . 75
3.5.2.1.b Le cas de deux mots-clés . . . . . . . . . . . . . . . . 76
3.5.2.1.c Le cas de trois mots-clés . . . . . . . . . . . . . . . . 77
3.5.2.2 La recherche à facettes . . . . . . . . . . . . . . . . . . . . . 86
3.5.2.3 Interrogation de plus d’une ontologie . . . . . . . . . . . . . 87
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4 Résultats expérimentaux et discussions 93

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2 Environnement d’expérimentation et outils . . . . . . . . . . . . . . . . . . . 93
4.3 Métriques d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4 Évaluation de l’approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.4.1 Avec de petites à moyennes ontologies . . . . . . . . . . . . . . . . . . 95
4.4.1.1 Pizza et la base « Anatomy » . . . . . . . . . . . . . . . . . 95
4.4.2 Avec de grandes ontologies . . . . . . . . . . . . . . . . . . . . . . . . 95
4.4.2.1 Présentation de la base « Large Biomedical Ontologies » . . 95
4.4.3 Résultats et interprétations . . . . . . . . . . . . . . . . . . . . . . . 96
4.4.3.1 Interrogation d’une seule ontologie - retour de toutes les in-
formations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.4.3.2 Une seule ontologie - raffinement du résultat . . . . . . . . . 104
4.4.3.3 Traitement et interrogation de plusieurs ontologies . . . . . 106
4.5 L’apport de notre travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Conclusion Générale 109

Bibliographie 116
Table des figures

1.1 L’évolution du Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 La structure d’un triplet RDF . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Un échantillon d’un graphe social . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Modèle graphique étiqueté par des propriétés . . . . . . . . . . . . . . . . . 24
2.3 Modèle RDF simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Fonctionnalités du stockage des données RDF (Angles (2012)) . . . . . . . . 37
2.5 Fonctionnalités de manipulation et d’opération (Angles (2012)) . . . . . . . 37
2.6 BD graphiques actuelles et leur support pour des requêtes essentielles (Angles
(2012)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7 Mapping des objets OWL en des triplets RDF (Kollia et al. (2011)) . . . . . 45
2.8 Les principales phases de traitement de requêtes (Kollia et al. (2011)) . . . . 45
2.9 Le modèle basé sur la génération de requêtes SPARQL (Unger et al. (2012)) 46

3.1 Arichtecture de Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2 Un exemple d’un graphe Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3 Création d’un petit graphe Neo4j . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4 Vue logique des APIs dans Neo4j . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5 Triplets des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.6 Triplets des propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.7 Triplets des instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.8 Domaines et Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.9 Parsing de l’ontologie, génération et chargement du graphe RDF dans Neo4j 67
3.10 Processus d’interrogation de la BD Neo4j . . . . . . . . . . . . . . . . . . . 68
3.11 Architecture générale de notre système . . . . . . . . . . . . . . . . . . . . . 72
3.12 Exemple de requête SPARQL-DL . . . . . . . . . . . . . . . . . . . . . . . . 73
3.13 Exemple de requête Cypher . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.14 Interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.15 Requête utilisateur en LN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.16 Résultats de la requête en LN en utilisant SPARQL-DL (1) . . . . . . . . . 81
3.17 Résultats de la requête en LN en utiliant SPARQL-DL (2) . . . . . . . . . . 82
3.18 Résultats de la requête en LN en utilisant SPARQL-DL (3) . . . . . . . . . 83
3.19 Résultats de la requête en LN en utilisant SPARQL-DL (4) . . . . . . . . . 83
3.20 Résultats de la requête en utilisant Cypher (par équivalence) (1) . . . . . . 84
3.21 Résultats de la requête en utilisant Cypher (par équivalence) (2) . . . . . . 85

iv
3.22 Résultats de la requête en utilisant Cypher (par équivalence) (3) . . . . . . 85
3.23 Interface à facettes (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.24 Interface à facettes (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.25 Architecture générale du processus du traitement de plusieurs ontologies . . 88
3.26 Interrogation de plusieurs ontologies . . . . . . . . . . . . . . . . . . . . . . 89
3.27 Résultats des requêtes Cypher (1) . . . . . . . . . . . . . . . . . . . . . . . 90
3.28 Résultats des requêtes Cypher (2) . . . . . . . . . . . . . . . . . . . . . . . 91
3.29 Résultats des requêtes Cypher (3) . . . . . . . . . . . . . . . . . . . . . . . 92

4.1 Temps du parsing et du chargement . . . . . . . . . . . . . . . . . . . . . . 100

4.2 Temps de réponse aux requêtes Cypher (par équivalence) . . . . . . . . . . 103
4.3 Temps de réponse aux requêtes SPARQL-DL . . . . . . . . . . . . . . . . . 103

v
Liste des tableaux

3.1 Cas de recherche d’un seul mot-clé . . . . . . . . . . . . . . . . . . . . . . . 76

3.2 Cas de recherche de deux mots-clés . . . . . . . . . . . . . . . . . . . . . . . 77
3.3 Cas de recherche de trois mots-clés . . . . . . . . . . . . . . . . . . . . . . . 78

4.1 Présentation de Pizza et la base « Anatomy » . . . . . . . . . . . . . . . . . 95

4.2 Présentation de la base « LargeBio » . . . . . . . . . . . . . . . . . . . . . . 96
4.3 Temps d’exécution de Pizza et de la base « Anatomy » avec retour de toutes
les informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.4 Temps d’exécution de la base « LargeBio(small) » avec retour de toutes les
informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.5 Temps d’exécution de la base « LargeBio(medium) » avec retour de toutes
les informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.6 Temps d’exécution de la base « LargeBio(whole) » avec retour de toutes les
informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.7 Temps de réponse minimums en utilisant les interfaces à facettes . . . . . . 106
4.8 Temps minimums de l’interrogation des deux ontologies Mouse et «FMA-
small» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

vi
Introduction Générale

Le Web sémantique permet aux machines de comprendre la sémantique, le sens de l’infor-

mation sur le Web. Il permet aux agents logiciels d’accéder plus intelligemment aux diverses
sources de données existantes sur le Web. Ainsi, la sémantique du contenu des ressources
dans le Web tente à rendre les données sous une représentation formelle et standardisée. La
description de la sémantique dans le contexte du Web sémantique est effectuée par l’inter-
médiaire des ontologies (ou bases de connaissances). L’ontologie est la base et l’appui de ce
que nous appelons la description de connaissances.

Les ontologies ont été reconnues comme une composante essentielle pour le partage des
connaissances et la concrétisation de la vision du Web sémantique. En définissant les concepts
associés à des domaines particuliers, elles permettent à la fois de décrire le contenu des sources
à intégrer et d’expliciter le vocabulaire à travers des requêtes lancées par des utilisateurs.

Les objets ainsi que les relations dans l’univers du discours sont conceptualisés dans le but
de les décrire sous une forme utilisable par des machines. Une des caractéristiques impor-
tantes du WS, est son hétérogénéité qui décrit à la fois sa richesse et son ambiguïté. Cette
hétérogénéité s’explique par le fait que les informations et les connaissances peuvent être
produites à partir de plusieurs sources diverses. De même, elles peuvent être exprimées dans
des différents formats.

Le nombre croissant des ensembles de données publiés sur le Web, offre à la fois des possi-
bilités de disponibilité élevée des données, ainsi que des défis inhérents lors de l’interrogation
de ces données dans un environnement sémantiquement hétérogène et distribué.
De même, RDF s’est imposé comme un modèle de données standard. De considérables quan-
tités de données RDF sont désormais disponibles.

Pour interroger les données liées sur le Web aujourd’hui, les utilisateurs doivent d’abord
savoir quels ensembles de données exposés contiennent potentiellement les données qu’ils sou-
haitent avoir, et quel modèle de données décrit ces ensembles de données, pour qu’ils puissent
utiliser cette information afin de créer des requêtes structurées.
En plus de la connaissance du modèle de données, les utilisateurs qui interrogent des infor-
mations liées, doivent maîtriser la syntaxe des langages d’interrogation hautement spécifiques
tels que SPARQL.

Ces difficultés d’interrogation des données peuvent nous amener au problème suivant :

1
alors que les usagers souhaitent avoir des réponses à leurs besoins, et même des réponses de
qualité, il n’en obtiennent aucunes.

Vis-à-vis de ce problème, l’utilisateur ne peut pas réellement savoir si sa requête est mal
formulée, trop sélective ou bien si le résultat souhaité n’existe tout simplement pas dans l’on-
tologie. Il peut ainsi se lancer dans un processus d’essai et d’erreur pendant lequel il tente de
modifier et de remettre optionnelles les conditions de sa requête. Ainsi, il analyse les résultats
obtenus, afin d’aboutir à une reformulation lui permettant d’avoir des résultats satisfaisants.
Ce processus semble long et fastidieux, ainsi que les résultats retrouvés peuvent ne pas être
ceux souhaités. Cela peut également causer une frustration des utilisateurs étant donné que
ces derniers ne comprennent même pas pourquoi, avec un aussi grand volume de données,
leurs requêtes ne retournent aucun résultat. Alors, nous estimons que les utilisateurs ont
besoin d’un appui afin de formuler des requêtes significatives et de retrouver des réponses
satisfaisantes. Pour l’utilisateur, les requêtes en langage naturel apparaissent comme une al-
ternative simple et intuitive.

D’un autre côté, avec l’avènement des bases de données NoSQL, d’autres pistes de prises
en charge ont été conçues. En particulier, les BD graphiques sont maintenant utilisées dans
des secteurs aussi divers que la santé, le commerce de détail, le pétrole et le gaz, les médias,
les jeux vidéo et bien d’autres.

Parmi les avantages des BD, nous pouvons citer : évolutivité, efficacité de stockage, struc-
turation idéale permettant un temps optimal d’exécution de requêtes utilisateurs, gestion des
droits d’accès. Les BD offrent aussi des mécanismes de contrôle et de sécurité.

Structure de ce mémoire

Les résultats de nos travaux de recherche sont synthétisés dans ce mémoire qui est
composé de quatre chapitres :

Le premier chapitre introduit les notions de base pour limiter le champ d’étude. En
fait, nous allons présenter une étude bibliographique sur les différentes étapes de l’évolution
du Web, et plus précisément le Web sémantique, l’ontologie, ses composants ainsi que les lan-
gages avec lesquels elle est représentée. La dernière section élucide la notion d’hétérogénéité
et liste brièvement ses divers types.

Le deuxième chapitre décrit les standards, protocoles et outils utilisés pour le stockage
et l’interrogation des données RDF. Ensuite, une description détaillée sur les BD-RDF et
le langage SPARQL, a été présentée. Enfin, nous avons présenté une revue sur les différents
travaux de comparaison de BD-RDF ainsi que sur quelques méthodes existantes pour l’in-
terrogation SPARQL de graphes RDF.

Le troisième chapitre est consacré à la description de notre nouvelle vision d’interroga-

2
tion de graphe RDF généré à partir d’une ontologie d’entrée. Il présente les différentes phases
constituants notre méthode, avec quelques exemples d’exécution.

Le quatrième chapitre décrit les expérimentations effectuées ainsi que l’environnement

de réalisation de la méthode développée. Enfin, une description détaillée sur les mesures re-
trouvées, a été présentée.

Le mémoire se termine par une conclusion générale qui récapitule l’ensemble de nos travaux
et présente également quelques perspectives futures de recherche.

3
Chapitre 1

Fondement du Web sémantique

1.1 Introduction
Avec l’évolution du Web et l’explosion du volume d’information, les ontologies sont deve-
nues un concept primordial pour le Web sémantique. Elles cherchent à exporter les données
sous une forme structurée (limite semi-structurée) avec une sémantique bien définie. Cela
permet aux agents de consommer ces données et de les utiliser d’une manière plus intelli-
gente. Les ontologies ont pour objectif, aussi, de permettre aux programmes d’assurer des
inférences basées sur des règles afin de déduire des faits, faire des raisonnements ou examiner
la cohérence de l’ensemble de données.

Le reste de ce chapitre est organisé comme suit : d’abord, nous allons définir le Web
sémantique, voir ses défis et ses objectifs. Ensuite, nous rappellerons la définition du terme
ontologie. Enfin, nous détaillerons les langages de représentation de cette dernière.

1.2 L’évolution du Web sémantique

Dés sa création, au début des années 90, l’objectif du Web se basait essentiellement sur
l’accès et le partage d’un grand volume d’information, sans aucune maîtrise/connaissance du
contenu.
Sa nature, sa structure et son usage ont évolué au fil du temps. Dans ce contexte, nous citons
les quatre étapes de son évolution [Sareh Aghaei and Farsani, 2012] :

- Web 1.0, ou encore Web traditionnel. C’est un Web statique (ou de documents) qui se
caractérisait par des sites web orientés produits et par un contenu plutôt limité (en général de
type texte et multimédia), créé surtout par des utilisateurs professionnels. Il nécessite aucune
intervention utilisateur. L’utilisateur n’était qu’un consommateur passif.
En effet, le Web « read only » était très consultatif et à sens unique. Le lecteur n’intervenait
que d’une façon très minime et ne pouvait pas réagir en temps réel ou contribuer au contenu
qu’il abordait. C’était une sorte de magazine énorme en ligne à consulter.

4
- Web 2.0, appelé également Web social (Vickery andWunsch-Vincent (2007)), et change
totalement de perspective. Il favorise plutôt la dimension du partage et d’échange d’infor-
mations et de contenus. Le Web se dynamise. Il se caractérise par un contenu plutôt illimité
créé par des utilisateurs professionnels et amateurs.

Ce Web est devenu à double sens. En effet, l’usager devient co-développeur, i.e. à la fois
consommateur et acteur. Mais pour être précis, seule une minorité prend le rôle du pro-
ducteur (read et write), car la majorité se contente de consulter et partager (read et share).
Ainsi l’utilisateur intervient énormément : il peut consulter, réagir en temps réel, partager, et
contribuer au contenu qu’il aborde, etc. Il devient la source du contenu (même professionnel),
et éventuellement la source de l’évolution de ce contenu (il peut modifier le contenu). Citons
comme exemple, Youtube qui, avec lequel, l’utilisateur peut envoyer des vidéos (du contenu),
et également, les modifier (adapter le contenu).

Il y a aussi une émergence des applications participatives, surtout les UGC s (les contenus
créés par les utilisateurs) pour communiquer, partager, tagger, et stocker du contenu (comme
les blogs, les sites e-commerce, les forums, et les réseaux sociaux, etc).
L’avis de l’utilisateur est constamment sollicité, ainsi, nous avons vu apparaître les com-
mentaires et les notes sur les articles, preuve qu’il est fondamental de tenir en considération
l’impression du lecteur.
le Web s’est transformé d’un espace pour la simple consultation des données, à un lieu d’ex-
pression riche.

- Web 3.0, initié à l’époque par Berners-Lee et al.(2001) comme le Web sémantique (ou
Smart Web). C’est un Web focalisé sur le savoir. Il consiste à rendre les ressources Web, non
seulement compréhensibles par les humains, mais également par les machines. Il tente de
fournir un sens aux données afin de répondre aux besoins des utilisateurs mobiles toujours
connectés à travers une multitude de supports d’application.

- Web 4.0, et également connu comme étant le Web symbiotique ou Web intelligent. C’est
un Web qui connectera l’intelligence. Il est orienté interaction individus/objets, et ses don-
nées vont évoluer vers des standards ouverts et un langage universel. Il vise à tout innover
grâce aux connexions intelligentes, et à immerger l’individu dans un environnement Web de
plus en plus prégnant. Il est appelé Web symbiotique car il est prévu que l’esprit humain
et les machines vont interagir en symbiose, i.e. l’utilisateur deviendra créateur en constante
symbiose avec son environnement.
Il représente une continuité de la voie du Web 3.0, tout en posant de considérables questions
telles que la protection de la vie privée, le contrôle des données, etc.

5
 La figure 1.1 1 montre les différentes étapes précitées de l’évolution du Web.
Au stade du Web 1.0, nous remarquons que le volume d’information reste minime et propor-
tionnel à la productivité, ainsi qu’au nombre d’utilisateurs.
A l’arrivée du Web 2.0, le volume d’information produite accroît suivant l’accroissement du
nombre d’internautes.
Avec l’apparition du Web 3.0, nous constatons l’augmentation du nombre d’utilisateurs et du
volume de données produites (e.g. un accroissement énorme du nombre de sites (555 millions
de sites + 300 millions nouveaux en 2011), une augmentation du nombre d’usagers Face-
book (200 millions nouveaux au même date), etc). Par conséquent, les moteurs de recherche
traditionnels ne suffisaient plus.
Finalement, avec l’avènement du Web 4.0, nous remarquons l’existence des agents intelli-
gents. Cette vision reste futuriste.

Figure 1.1 – L’évolution du Web

1.2.1 Définition
Le Web sémantique est un web intelligent qui permet, non seulement de stocker les infor-
mations, mais également de les rendre compréhensibles par les ordinateurs et réutilisables par
différentes applications. C’est une nouvelle génération du Web où l’information est structurée
par les connaissances. Ceci permet les agents logiciels d’effectuer des actions complexes pour
leurs utilisateurs, grâce à une inter-opération des services Web.

De la même manière que le Web actuel, le Web sémantique est construit principale-
ment autour des identifiants (URI s : Uniform Resource Identifier) et du protocole HTTP
(HyperText Transfer Protocol), mais il est par contre basé sur le langage RDF (Resource
Description Framework) et non plus sur HTML (HyperText Markup Language). Cela est
1. http ://www.camillejourdain.fr/schemas-evolution-du-web/ Consulté le 11/10/2017

6
pour but de séparer l’information qui décrit le sens et le contexte des données, de l’infor-
mation qui décrit la présentation des données. Il est basé principalement sur les bases de
connaissances et non plus sur les bases de données. La recherche aussi va s’affecter et devenir
une recherche par concept, non plus par mot-clé.

Dans le Web sémantique, toutes les données du Web, textuelles ou multimédia, doivent
être annotées sémantiquement par des méta-données pertinentes, car les machines ne peuvent
traiter les ressources Web qu’à travers une explication plus spécifique de leur contenu et cela
en utilisant un mark-up sémantique nommé « méta-données » qui aidera les agents logiciels
à comprendre les données et à prendre des décisions. L’annotation de ces ressources d’infor-
mation repose sur l’accès à des représentations de connaissances (des ontologies) échangées
sur le Web et qui sont en train de s’intégrer de plus en plus dans les applications Web, sans
même que les utilisateurs ne le sachent.

Pour conclure, l’objectif principal du Web sémantique est de transformer la masse non-
maîtrisable des pages Web, en un énorme index hiérarchisé afin de garantir un réel partage
de connaissances.

1.2.2 Historique
Le Web sémantique n’est pas pour autant une nouvelle idée. La notion a été décrite pre-
mièrement dans les années 1990. En 1993, Tim Berners-Lee fournit une solution au problème
du partage de connaissances entre les applications Web, à l’aide d’un mécanisme à base d’on-
tologies qui structure les données d’une manière compréhensible par la machine.

Le vrai départ du Web sémantique a eu lieu en 2001 par Berners-Lee et al.

Le mot sémantique tente de faire référence à la définition traitée par le domaine de la logique
de descriptions, dont le but est de faire apparaître du sens à travers la structuration des
informations et l’expression de la logique qui les relie.

Alors, quelles sont les défis relevés par le Web sémantique ?

1.2.3 Les défis du Web sémantique

Afin d’être à la hauteur de ses promesses, le Web sémantique doit faire face à toutes ces
questions [Jridi, 2014] :

Immensité : le World Wide Web contient plusieurs milliards de pages. A l’arrivée du Web
sémantique, tous les systèmes de raisonnement automatisé devraient gérer une quantité de
données vraiment immense.

Imprécision : il existe des notions imprécises comme "grand" ou "jeune". Ceci est produit
de l’imprécision des requêtes des utilisateurs. La logique floue est le remède pour faire face à

7
ce défi.

Incertitude : il peut exister des concepts précis avec des valeurs incertaines. A titre d’exemple,
un patient expose un ensemble de symptômes qui conviennent avec un certain nombre de
diagnostics différents, chacun avec une probabilité différente.

Incohérence : ce sont des contradictions logiques qui apparaissent fatalement au cours du

développement des grandes ontologies venant de sources diverses.

1.2.4 Les objectifs du Web sémantique

De nos jours, le souci du Web n’est plus vraiment l’augmentation continuelle de sa taille
d’informations, mais plutôt l’amélioration de la recherche dans cette énorme masse d’infor-
mations, et la réalisation de systèmes permettant de filtrer et délivrer les informations de
façon « intelligente ».

Le Web actuel est un ensemble de documents (données et pages) dédié aux humains, stocké
et manipulé d’une façon purement syntaxique. Les deux principaux problèmes du Web actuel
sont :
- D’une part, il y a énormément de sources de données, du fait que n’importe qui peut fa-
cilement publier un contenu (sachant qu’il n’a pas la moindre idée sur la probabilité que ce
contenu soit trouvé par autrui) ; il n’a qu’à l’annoter. Ainsi, les moteurs de recherche à base
de mot-clé auront la tâche de l’indexer pour pouvoir l’afficher aux utilisateurs lorsqu’ils font
une recherche. Par conséquent, l’information sur Internet est tellement énorme que l’utilisa-
teur a beaucoup de difficultés à la retrouver.

- D’une autre part, les résultats de recherche sont imprécis, très sensibles au vocabulaire, et
assez longs à trouver. En effet, les moteurs de recherche ne sont capables de répondre qu’à
deux questions principales :
Quelles sont les pages contenant ce terme ? et ;
Quelles sont les pages les plus populaires à ce sujet ?

Le Web est essentiellement syntaxique, et l’Homme est le seul à pouvoir interpréter le contenu
(des documents et des ressources) inaccessible et non interprétable par la machine. Lui seul
doté de la capacité de comprendre ce qu’il a trouvé et décider en quoi cela se rapporte à ce
qu’il veut vraiment chercher. Finalement, nous ne pourrons pas se passer de l’intervention
humaine pour naviguer, chercher, faire le tri de documents manuellement, interpréter et com-
biner les résultats.

L’affaire principale du Web sémantique est de diriger l’évolution du Web afin de per-
mettre aux utilisateurs de trouver, partager et arranger l’information plus aisément et sans
avoir recours à un intermédiaire. Il autorise également l’accès aux données entre différentes
applications.
Les machines ne peuvent pas effectuer toutes les tâches telles que, la réservation d’un billet

8
du train, l’allocation d’une voiture etc, sans assistance humaine, parce que les pages Web
sont faites pour être lues uniquement par les humains.
Par conséquent, avec le Web sémantique, il s’avère possible d’effectuer des travaux rigoureux
et automatiques par les machines. Il représente un système permettant aux agents de "com-
prendre" et de répondre aux requêtes complexes des utilisateurs. Cette "compréhension"
exige que la sémantique des sources d’informations existantes, soit structurée à l’avance.

Le but ultime du Web de la 3ème génération est de permettre aux utilisateurs d’exploiter
tout le potentiel du Web en s’aidant par les machines qui pourront accomplir les tâches
encore réalisées par l’Homme comme la recherche ou l’association d’informations, et ainsi
atteindre un Web intelligent qui regroupera l’information de manière utile et qui apportera
à l’utilisateur ce qui cherche vraiment.

1.3 Ontologies
Les ontologies existent afin de pouvoir présenter et partager les connaissances d’un do-
maine, ainsi que pour créer un consensus.
Elles sont les concepts clés du Web sémantique. Leur apparition a eu lieu au début des années
1990 dans la communauté de l’ingénierie de connaissances (IC).

Les ontologies font partie intégrante des normes du W3C pour le Web sémantique, car elles
sont indispensables pour représenter la sémantique des documents, i.e. les connaissances qui
coexistent dans le Web, en structurant et en définissant la signification des termes actuelle-
ment collectées et normalisées.

De nombreuses applications telles que la recherche d’informations, la réponse aux requêtes,

la recherche documentaire, la synthèse de texte, etc, sont réalisées en utilisant les ontologies
(de domaine). Elles peuvent être utilisées aussi dans des services pour publier des bases de
connaissances réutilisables, ou pour faciliter l’interopérabilité entre plusieurs systèmes hé-
térogènes et bases de données. Ainsi, nous pouvons considérer les ontologies comme une
représentation pivot qui a pour but d’intégrer les sources de données hétérogènes pour dé-
crire le contenu du Web.

Les ontologies sont nommées avec un IRI (Internationalized Resource Identifier), et puis-
qu’elles sont des documents Web, elles sont ainsi référencées par un URI (Uniform Resource
Identifier : IRI physique) qui doit pointer sur la localisation de l’URL (Uniform Resource
Locator) choisi pour les publier.

1.3.1 Revue sur les définitions d’une ontologie

Une des premières définitions de l’ontologie a été attribuée par Neches et al. (1991) : "Une
ontologie définit les termes et les relations de base comportant le vocabulaire d’un domaine,

9
aussi bien les règles pour combiner ces termes et ces relations, afin de définir des extensions
du vocabulaire."
D’après cette définition, nous comprenons qu’une ontologie désigne les termes et les relations
de base d’un domaine donné. La combinaison de ces derniers s’effectue en se basant sur des
règles bien déterminées. Selon cette définition descriptive, nous saisissons également qu’une
ontologie inclut de plus un volume informationnel, inféré des termes qu’elle peut caractériser.

Toutefois, la définition la plus adoptée et la plus utilisée dans le contexte du Web séman-
tique, est celle de Gruber (1993) [Guarino et al., 2009] : " Une ontologie est une spécification
explicite et formelle d’une conceptualisation d’un domaine de connaissances". La conceptua-
lisation est le dénouement d’une analyse ontologique du domaine exploré. Cette conceptua-
lisation est exprimée dans une forme concrète, dite spécification. En fait, une spécification
n’est qu’une représentation formelle des concepts et des relations, ainsi que les contraintes
imposées dessus.

Guarino et Giaretta (1995) dans [Corcho, 2004], ont étudié et collecté sept définitions
d’une ontologie :

- Une ontologie est vue comme un exercice philosophique ;

- Une ontologie est un système conceptuel informel ;
- Une ontologie est un compte, ou récit sémantique formel ;
- Une ontologie est une spécification d’une conceptualisation ;
- Une ontologie est une représentation d’un système conceptuel à partir d’une théorie logique ;
- Une ontologie est un vocabulaire utilisé par une théorie logique ;
- Une ontologie est considérée comme un méta-niveau d’une spécification, d’une théorie lo-
gique.

Borst (1997) dans [Guarino et al., 2009], a légèrement modifié la définition de Gruber
(1993) et il a proposé la suivante : "Les ontologies sont définies comme une spécification for-
melle d’une conceptualisation partagée". Les définitions de Gruber (1993) et Borst (1997) ont
été alliées par Studer et al.(1998) comme suit : "Une ontologie est une spécification formelle
et explicite d’une conceptualisation partagée". Selon Borst (1997), une conceptualisation se
rapporte à un modèle abstrait retraçant un phénomène quelconque du monde réel. L’abs-
traction se fait grâce à la détermination des concepts de ce phénomène. Le terme "explicite",
provient du fait que les types de concepts et les contraintes de leur usage, doivent être expli-
citement définis. Ainsi, le terme "formelle" signifie qu’une ontologie doit être compréhensible
et lisible par la machine. Finalement, le mot "partagée", montre qu’une ontologie doit couvrir
un centre d’intérêt de façon à la rendre abordable, par tous les usagers de toute communauté.

Nous avons récapitulé les définitions les plus pertinentes du terme ontologie, et qui reflètent
des points de vue à la fois complémentaires et différents. En effet, nous pouvons conclure que
les ontologies sont crées et inventées à la base pour modifier les connaissances consensuelles
d’une façon générique.
En somme, les ontologies matérialisent les principes du partage et de la réutilisation de l’in-

10
formation.

Dans la littérature, nous listons plusieurs types d’ontologies selon différentes classifications.
Malgré cette variété, toutes ces ontologies partagent quasiment les mêmes composants afin de
décrire un certain domaine, et qui sont : connaissances et domaine de connaissances, concepts,
relations et axiomes.

1.3.2 Constituants d’une ontologie

Les ontologies ne peuvent être construites, qu’à travers leurs éléments de base. Cette sous-
section décrit les principaux constituants d’une ontologie.

1.3.2.1 Connaissances et domaine de connaissances

La signification de plusieurs termes diffère d’un domaine à un autre. C’est pourquoi, une
ontologie ne peut être bâtie que dans le cadre d’un domaine particulier de connaissances (Ba-
chimont (1999)). En plus, il faut associer une sémantique claire à l’ontologie construite. Un
domaine de connaissances est composé par des termes du domaine et par un contexte d’uti-
lisation de ces termes (Bachimont (1999)). En outre, certaines connaissances, qui peuvent
constituer en elles-mêmes un domaine, sont employées dans tous les autres domaines. De
plus, les connaissances humaines s’étendent et se développent suivant plusieurs dimensions.
Elles peuvent être développées, non seulement sur la réalité, mais aussi sur un domaine de
connaissances (i.e. méta-connaissances).

Tout objet sur le Web possède une méta-donnée (étiquette) qui le représente fidèlement,
et qui peut être lue par les agents logiciels aussi bien que par les agents humains. Les méta-
données ou bien les méta-connaissances sont des informations sur les données décrivant les
connaissances contenues dans les ressources. Ainsi, cerner le domaine de connaissances à re-
présenter, suscite une délimitation précise et explicite de l’objectif opérationnel de l’ontologie.
Dans le domaine de l’ingénierie de connaissance, la représentation de connaissances se traduit
par une description à base des faits et des règles. Nous pouvons considérer, qu’il n’y a de
connaissances que lorsque l’information présentée dans la machine prenne un sens, et que ce
sens soit le même pour tous les utilisateurs (Charlet (2001)). Ainsi, une ontologie doit être
représentée à partir d’un champ de connaissances bien déterminé pour un objectif opéra-
tionnel non ambigüe. Elle doit se baser sur des connaissances objectives, dont la sémantique
puisse être scrupuleusement et formellement exprimée. Ces connaissances sont représentées
dans l’ontologie sous forme de concepts, de relations et finalement d’axiomes. Dans ce qui
suit, nous décrivons la notion de concepts.

1.3.2.2 Concepts
Les concepts constituent le centre d’intérêt de plusieurs ontologies, et représentent en réa-
lité des objets sur qui porte une connaissance. Ils peuvent représenter un objet matériel, une
notion ou une idée (Ushold and Jasper (1999)). Un concept peut être décomposé en trois
parties qui sont : un ou plusieurs termes, une notion et un ensemble d’objets. La notion est

11
appelée également intention du concept. Elle contient la signification du concept exprimée en
termes de règles et de contraintes, de propriétés et d’attributs. L’ensemble d’objets est appelé
aussi extension du concept ou encore instance du concept. Il regroupe les objets manipulés à
travers un concept.
Les deux aspects d’un concept (intention et extension) sont assez différents dans plusieurs
mesures. En effet, deux extensions peuvent ne pas être disjointes, alors que deux intentions
s’excluent réciproquement par au moins une propriété. Un concept peut avoir une extension
vide, c’est le cas d’un concept générique, cela est généralement pour se référer à une notion
abstraite, e.g. le concept "fonctionnel" pris dans le sens de "ce qui est fonctionnel" et non
pas du "degré de fonctionnalité". Deux concepts peuvent avoir la même extension sans pour
autant posséder la même intention. Par exemple, le cas des concepts "directeurs" et "em-
ployés" qui peuvent partager quelques extensions.

Dans le langage naturel, il existe de nombreux termes désignant plusieurs concepts séman-
tiquement différents, et qui ne sont pas gérables par la machine. Par exemple, la "souris" est
un animal et la même expression représente aussi un matériel d’ordinateur. La limitation à un
domaine de connaissances bien déterminé permet de remédier à ce problème et alors d’éviter
les homonymes des concepts. Néanmoins, il est préférable de gérer la synonymie et l’hypo-
nymie pour garantir plus de souplesse dans l’usage de l’ontologie (Gómez Pérez et al. (1996)).

Les concepts sont reliés par des propriétés conceptuelles. Ces propriétés se divisent en
deux critères [Zghal, 2010]. La première catégorie regroupe les propriétés associées à un seul
concept. La seconde rassemble les propriétés associées à deux concepts. La majorité des pro-
priétés portant sur un seul concept sont proposées par Guarino and Giaretta (1995) et elles
sont constituées par :

- Généricité : un concept est dit générique s’il n’admet pas d’extensions, i.e. d’instances
(e.g. la vérité est un concept générique) ;
- Identité : un concept a une propriété d’identité si cette dernière permet de différencier une
instance d’une autre (e.g. le concept "étudiant" porte une propriété d’identité liée au numéro
de l’étudiant, deux étudiants sont identiques s’ils ont le même numéro) ;
- Rigidité : un concept est considéré rigide si toute instance de ce concept en demeure
instance dans tous les domaines possibles (e.g. humain est un concept rigide) ;
- Anti-rigidité : un concept est dit anti-rigide si toute instance de ce concept est principa-
lement définie par son appartenance à l’extension d’un autre concept (e.g. "enseignant" est
un concept anti-rigide car l’enseignant est avant tout un humain) ;
- Unité : un concept s’avère unité si pour chacune de ses instances, les différentes parties de
l’instance sont attachées par une relation qui ne lie pas d’autres instances de concepts (e.g.
les deux parties d’un couteau, manche et lame sont liées par une relation "emmanché" qui
ne relie que cette lame et cette manche).

Les propriétés portant sur deux concepts sont :

- Équivalence : deux concepts sont équivalents s’ils aient les mêmes extensions ;

12
- Disjonction : deux concepts sont disjoints si leurs extensions sont disjointes (e.g. homme
et femme) ;
- Dépendance : un concept C1 est dépendant d’un concept C2, si pour toute instance de
C1, il existe une instance de C2 qui ne soit ni partie ni constituant de l’instance de C2 (e.g.
le concept "parent" est un concept dépendant du concept "enfant" et inversement).

Les concepts, dans une ontologie, sont bien évidemment liés. Cette liaison se fait grâce à des
relations.

1.3.2.3 Relations
Les relations permettent d’associer des instances de concepts, ou des concepts génériques.
Elles sont particularisées par un terme (ou plusieurs) et une signature (Gómez-Pérez et al.
(1996)). La signature décrit le nombre d’instances de concepts que la relation lie, leurs types
et l’ordre des concepts (la direction dont la relation doit être lue). Par exemple, la relation "dé-
veloppe" lie une instance du concept "développeur" à une instance du concept "programme",
dans cet ordre. Elles sont formellement définies comme une fonction N-aire tandis que les
ontologies contiennent généralement des relations binaires afin d’exprimer la sémantique qui
relie chaque deux concepts, tel que le premier argument est le domaine et le deuxième argu-
ment correspond au Co-domaine (il peut être un type de donnée défini, tel que, « String »,
« Integer », etc.).

Les relations peuvent également être caractérisées par des propriétés [Zghal, 2010], et qui
sont de trois types : les propriétés intrinsèques à une relation, les propriétés qui lient deux
relations et les propriétés qui lient une relation à un concept.

Nous citons les propriétés intrinsèques à une relation :

- Propriétés algébriques : comme la transitivité, symétrie, etc. ;

- Cardinalité : elle précise le nombre possible de relations de ce type entre les mêmes
concepts (ou instances de concepts).

Les propriétés liant deux relations sont comme suit :

- Incompatibilité : deux relations sont considérées incompatibles si elles ne peuvent pas lier
les mêmes instances de concepts (e.g. les relations "être à l’extérieur" et "être à l’intérieur"
sont incompatibles) ;
- Inverse : deux relations binaires sont inverses l’une de l’autre si, lorsque l’une lie deux
instances I1 et I2, l’autre lie I2 et I1 (e.g. les relations "a pour père" et "a pour enfant"
sont inverses) ;
- Exclusivité : deux relations sont dites exclusives si, quand l’une lie des instances de
concepts, l’autre ne lie pas ces instances, et vice-versa. L’exclusivité soulève l’incompatibilité.

Les propriétés liant une relation à un concept ont été proposées par Kassel and Perpette

13
(1999) :

- Lien relationnel : il existe un lien relationnel entre une relation L et deux concepts C1
et C2 si, pour tout couple d’instances des concepts C1 et C2, il existe une relation de type
L qui lie les deux instances de C1 et C2 ;
- Restriction de relation : il peut avoir une restriction de relation entre une relation R et
un concept C, si pour tout concept de type C, et toute relation de type R liant C, les autres
concepts liés par la relation sont d’un type imposé. La relation "mange" portant sur une
"personne" et un "aliment", lie alors une instance de "végétarien", qui est un concept sub-
sumé par "personne", et l’instance de "aliment", qui est forcément une instance de "végétaux".

Les concepts et les relations permettent de représenter une ontologie légère basée sur
une simple taxonomie de classes. Cependant, les ontologies lourdes contiennent de plus des
concepts et des relations, des axiomes (Fürst and Trichet (2005)). Dans ce qui suit, nous
expliquons la notion d’axiomes, comme étant l’un des composants d’une ontologie.

1.3.2.4 Axiomes
Décrire les connaissances dans une ontologie ne suffit pas pour atteindre l’objectif opé-
rationnel d’un Système à Base de Connaissances (SBC). En effet, le plus important n’est
pas d’avoir des connaissances sur un domaine, mais plutôt de leur mise en œuvre dans une
action, afin d’atteindre un objectif particulier (Teuliet and Girard (2001)) [Jridi, 2014]. Il
s’agit, également, d’avantager les systèmes informatiques de la possibilité d’inférer de nou-
velles connaissances à partir d’autres déjà existantes (Bachimont (2000)).

Les axiomes logiques constituent des assertions liées aux entités. Au lieu de compter sur
les labels et les termes des entités (qui sont destinés aux humains) pour transmettre la sé-
mantique, le concepteur d’ontologies doit contraindre l’interprétation possible des entités à
travers une utilisation judicieuse d’axiomes logiques pour rende leurs sens beaucoup plus
précis.
Ils sont aussi utilisés pour vérifier la consistance de l’ontologie, car ils permettent à un raison-
neur d’inférer des connaissances additionnelles qui ne sont pas déclarées directement. Plus
les axiomes exprimées dans les ontologies sont complexes, plus elles transportent des connais-
sances implicites qui peuvent être inférées par le raisonneur.

Les connaissances opérationnelles peuvent être des faits, des règles, ou des contraintes.
Un fait peut être une affirmation vraie et cognitive ou, un axiome qui aide à la description du
monde cognitif dans lequel s’inscrit le système à base de connaissances. L’énoncé "la classe
contient 32 étudiants" est un exemple de fait.
Une règle permet d’inférer de nouvelles connaissances, elle incarne une implication.
Les contraintes spécifient les impossibilités ou les obligations.

Le choix entre l’utilisation d’une règle ou d’une contrainte pour la représentation d’une
connaissance, n’est pas toujours facile. Il dépend de la manière dont les connaissances vont

14
être utilisées au niveau opérationnel. Certains considèrent que ces types de connaissances
doivent être incorporés dans les propriétés des concepts, des relations ou des instances de
concepts.
Une règle apparaît plutôt comme une propriété d’un concept ou d’une règle, elle ne porte
pas sur les instances.
Les contraintes peuvent se porter aussi bien sur les concepts et les relations que sur les ins-
tances.

Alors, les axiomes servent d’une part, à modéliser les énoncés qui sont toujours vrais, et
d’autre part, à vérifier la consistance de l’ontologie elle-même. En effet, ils sont très avanta-
geux pour inférer de nouvelles connaissances.

Pour résumer, selon Kalfoglou, et al. (2003), une approche algébrique plus formelle, iden-
tifie une ontologie comme étant une paire <S, A>, où S est la signature des entités de
l’ontologie (modélisée par une structure mathématique comme un treillis ou un ensemble
non structuré) et A est l’ensemble des axiomes ontologiques qui spécifient l’interprétation
voulue de la signature dans un domaine donné.

Selon Udrea, et al. (2007), les ontologies modélisent la structure des données (i.e. les en-
sembles de classes et des propriétés), la sémantique des données (sous la forme de contraintes
(axiomes) telles que les relations d’héritage ou les contraintes sur les propriétés), et les ins-
tances des données (les individus). Ainsi, les ontologies se composent d’une partie « structure
», et d’une partie « donnée ».

D’après Zhang, et al. (2017), une ontologie est un modèle à base d’arbre, à cause du
principe de l’hyponymie (la subsomption is-a) qui fait que chaque entité (classe ou propriété)
soit héritée d’une seule super-entité directe, formant ainsi une structure de graphe acyclique
enracinée.
Afin que les données d’une ontologie puissent être utiles et traitables par des machines,
elles doivent être décrites à travers des notations concrètes en utilisant des langages formels.
Dans la section suivante, nous allons présenter ces langages ontologiques.

1.4 Langages de représentation des ontologies

Nous avons fait une revue sur les différentes définitions d’une ontologie ainsi que ses consti-
tuants de base. Les ontologies constituent le principe général qui régit le Web sémantique.
Leur représentation repose sur des standards et des schémas de données bien définis, on note
RDF, RDFS et OWL, etc.

Les langages de représentation des ontologies, sont les appuis pour la mise en place des
ontologies dans le Web. Ils constituent les standards qui régissent l’architecture du Web
sémantique et qui, également, assurent une interopérabilité sémantique entre les différents

15
intervenants.

1.4.1 XML et XML Schema

Le langage XML [Lacot, 2005] procure une syntaxe pour les documents structurés d’une
manière hiérarchique. Par contre, ce langage n’exige aucune contrainte sémantique et alors
il n’apporte aucune signification aux documents. Il n’existe pas de normes pour la recherche
intelligente, l’échange de données et la présentation adaptable.
En outre, XML est un langage à balises pouvant contenir également des informations sup-
plémentaires (méta-données) qui sont incorporées dans le texte à présenter.

Un schéma XML, noté XML(S), est une description du type d’un document XML. Il
comporte un ensemble de contraintes sur la structure et le contenu du document. Ainsi, un
document XML doit respecter cet ensemble de règles afin d’être considéré valide.

L’espace de noms (namespace) est un contexte ou un conteneur abstrait contenant des

noms, des termes ou des mots qui représentent des objets, des concepts dans le monde réel.
Un nom défini dans un espace de noms correspond à un et seulement un objet, alors que
deux objets ou concepts différents sont référencés par deux noms différents dans un même
espace de noms.

1.4.2 RDF et RDF Schema

RDF [Lacot, 2005], est un modèle de méta-données ayant pour objectif de référencer des
objets (ressources) et décrire les liens entre eux afin de rendre plus "structuré" les données
nécessaires aux moteurs de recherche. Dans ce modèle, les ressources sont référencées par les
URIs.

L’URI ressemble à une étiquette/label numérique (chaînes de caractères) permettant de

représenter à la fois l’adresse d’une ressource sur un réseau, quand il est considéré sous sa
forme d’URL (Uniform Ressource Locator), et/ou le « nom propre » de cette ressource, quand
il est estimé sous sa forme d’URN (Uniform Ressource Name). Une URL est alors un URI
qui sert à identifier l’emplacement d’une ressource, alors qu’un URN est un URI qui aide à
désigner ou à nommer n’importe quelle ressource sur le Web.

Linked Data permet d’utiliser le Web pour faciliter la construction de liens entre des
données dépendantes qui n’étaient pas encore liées, ou qui l’étaient auparavant via d’autres
méthodes. On y retrouve un ensemble de pratiques recommandées pour exposer, échanger et
relier des fragments de données, informations et connaissances sur le Web sémantique grâce
à l’usage des URI et de RDF.
Linked Data définit alors un moyen de publication de données semi-structurées sur le Web
de données, dans le but de lier les données et de les rendre plus accessibles.
Elles sont un espace de données global, composé de sources de données structurées et distri-
buées publiées dans le Web en langage RDF, sous forme de triplets RDF (sujet -> prédicat

16
-> objet), et inter-liées explicitement.

Linked Open Data (LOD) : ont connu une croissance rapide au cours des dernières
années. Elles se constituent de 1 163 data sets lisibles par machine (en 2017) ayant plus de
31 milliards de triplets RDF (en 2011) inter-liés par environ 504 millions liaisons (en 2011).
Les data sets du LOD sont principalement classés en neuf domaines : le domaine transversal
(e.g. DBpedia : la version « Linked Data » de Wikipedia), la géographie (e.g. Geonames),
le gouvernement, les sciences de la vie, la linguistique, les médias (e.g. NYTimes, et Lin-
kedMDB), les publications, les réseaux sociaux (e.g. FOAF), et le contenu généré par les
utilisateurs.

RDF est basé sur la théorie de graphes, qui permet de représenter les données sous forme
de triplets RDF. C’est le modèle standard pour le partage et l’échange des informations
sur le Web.
Un triplet RDF est un ensemble de trois informations liées <sujet, prédicat, objet>
comme l’indique la figure 1.2. Ce type de représentation est facile à interpréter parce qu’il
est un modèle mental assez simple.
- Le sujet est la ressource ou l’objet à modéliser, il est représenté par une URI.
- Le prédicat exprime un lien ou une relation entre le sujet et l’objet, représenté par une
URI également.
- L’objet est la valeur du prédicat du sujet, il peut être une URI, un identifiant local, ou
un littéral.

Figure 1.2 – La structure d’un triplet RDF

Entailment : une caractéristique importante est la représentation de triplets implicites

qui ne sont pas explicitement modélisés dans un graphe mais ils font partie de celui-ci. Le
W3C appelle RDF entailment, le mécanisme avec lequel les triplets implicites sont engendrés
(ou dérivés) grâce aux triplets déjà existants (explicites) d’un graphe, ainsi que grâce à des
règles d’entailment.

Sérialisation RDF : comme RDF a été conçu principalement pour représenter des res-
sources Web, sa syntaxe formelle utilise ordinairement XML (on appelle alors cette forme
RDF/XML). Cependant, cette dernière devient vite fastidieuse à lire pour les agents humains.

17
Pour rendre un document RDF plus accessible, le W3C offre des notations plus abstraites
que sont N3 et N-Triples (N-Triples étant un sous-ensemble de N3).

En ce sens, bien que RDF soit très flexible (donne la possibilité d’assembler n’importe
quoi, n’importe comment, à la description d’une ressource), les représentations dans ce for-
mat sont assez abstraites, platoniques et sans grande profondeur sémantique (faible degré de
hiérarchisation des descriptions). Pour couvrir cette lacune, un vocabulaire élémentaire a été
développé : RDFS (RDF Vocabulary Language).

RDF Schema est un langage pour décrire de simples vocabulaires dans le modèle RDF.
Ainsi, il n’est qu’une extension sémantique de RDF. Grâce à ce vocabulaire, la sémantique
des prédicats et les classes d’entités peuvent être définis. Cela laisse, entre autre, la possibilité
de déterminer des règles d’inférence afin de générer une grande quantité de triplets dérivés
de ceux existants, ce qui augmente, par conséquent, la capacité du raisonnement que peut
avoir les agents logiciels et les programmes qui traitent les données sur le Web sémantique.
RDFS permet notamment de définir des liens de "Subsomption" entre des classes et des re-
lations en utilisant les primitives rdfs :sub ClassOf et rdfs :subPropertyOf. Ces primitives sont
les liens de "Spécialisation" ou "is-a", qui permettent aux classes et aux relations d’hériter
des caractéristiques de leurs classes (ou de leurs relations) mères.

1.4.3 OWL
Le langage OWL (Schreiber et Dean) a vu le jour en 2004, dans la même période que RDF
et RDFS. Il a, par la suite, été étendu, dans l’année 2009, dans la norme OWL 2 (OWL
Working Group).
Il est, tout comme RDF, un langage profitant de l’universalité syntaxique de XML.

Ce standard a été conçu également pour réutiliser des concepts et des propriétés déjà dé-
finis dans RDF et RDFS. En ce sens, une base de connaissances OWL peut alors être écrite
comme une collection de triplets RDF.
OWL permet aux applications, qui l’utilisent, de pouvoir effectuer des inférences sur les don-
nées cumulées. Pour ce faire, il offre des opérateurs issus de la logique descriptive.

A part sa capacité de définir et de décrire des classes, des propriétés, et des individus
de classes, OWL permet aussi de définir des relations entre les classes (union, intersection,
disjonction, équivalence, subsomption etc.), des contraintes de cardinalité pour les valeurs
des propriétés (minimum, maximum, nombre exact), des relations spéciales pour les pro-
priétés (transitive, symétrique, fonctionnelle, inverse, réflexive, etc.), et des restrictions sur
le domaine et le co-domaine des propriétés, etc. Par conséquent, OWL possède une logique
très développée qui permet le raisonnement sémantique sur ces règles à l’aide d’un raisonneur.

En outre, OWL est capable de décrire formellement la signification de la terminologie em-

ployée dans les documents Web, constituant ainsi le premier niveau indispensable du Web
sémantique après RDF. Ainsi, apprêter les machines d’une capacité à mener des raisonne-

18
ments appropriés sur les documents, revient à fournir un langage de qui la sémantique dépasse
celle du schéma RDF.

Le langage OWL diffère du couple RDF/RDFS en ceci que, contrairement à RDF, il est
précisément un langage d’ontologies. Les langages RDF et RDFS fournissent à l’utilisateur
la capacité de représenter des classes (i.e. avec des constructeurs) et des propriétés.
⇒ OWL offre aux machines une plus grande capacité d’interprétation du contenu Web que
RDF et RDFS, grâce à une vraie sémantique formelle et à un vocabulaire plus riche.

OWL est composé de trois parties :

- Classe : est un groupe d’individus (instances) possédant des caractéristiques similaires.
Les classes peuvent être organisées hiérarchiquement selon une taxonomie.
Les classes définies par l’utilisateur sont toutes des enfants de la super-classe ”owl :Thing” et
des parents de la sous-classe ”owl :Nothing”.

- Propriété : permet de définir des faits ou des relations entre les individus. Il existe en
OWL deux types de propriétés : les propriétés d’objet et celles de types de données.

- Instance : est un objet particulier instancié par les classes à l’aide de la relation prédéfinie
"Instance-Of". Elles peuplent les classes et véhiculent les connaissance à propos du domaine
en question.

1.4.3.1 OWL 1
Le langage OWL 1 détermine trois sous-langages, du moins expressif au plus expressif, à
savoir : OWL-Lite, OWL-DL et OWL-Full [Lacot, 2005].

- OWL-Lite est le premier sous langage de OWL et le plus simple. Il est dédié aux usagers
qui n’ont besoin que d’une hiérarchie simple de concepts. OWL-Lite est adapté, par exemple,
aux migrations rapides depuis un ancien thésaurus vers une représentation sous forme d’on-
tologies.

- OWL-DL est plus complexe qu’OWL-Lite, fournissant une expressivité bien plus impor-
tante. OWL-DL (OWL Description Logic) est fondé sur la logique descriptive, assurant alors
une adaptation au raisonnement automatisé. Malgré sa complexité relative face à OWL-Lite,
OWL-DL garantit la complétude des raisonnements (toutes les inférences sont calculables)
et leur décidabilité (leur calcul se fait en une durée finie).

- OWL-Full est la version la plus complexe et complète d’OWL, mais également celle qui
permet d’avoir le plus haut niveau d’expressivité. Il garantit la complétude et la décidabi-
lité des calculs liés à l’ontologie. OWL-Full fournit toutefois des mécanismes intéressants,
comme la possibilité d’étendre le vocabulaire par défaut de OWL. Il existe, entre ces trois
sous langages, une dépendance de nature hiérarchique : toute ontologie OWL-Lite valide est

19
également une ontologie OWL-DL valide, et toute ontologie OWL-DL valide est alors une
ontologie OWL-Full valide.

Ainsi, les développeurs d’ontologies choisissant OWL, devraient estimer quel sous-langage
convient le mieux à leurs besoins.

1.4.3.2 OWL 2
OWL 2 reprend les caractéristiques de sa version précédente en ajoutant quelques com-
posants supplémentaires. La principale contribution d’OWL 2 est de déterminer des profils,
des sous-langages de OWL 2, qui imposent et limitent les expressions exploitables selon l’uti-
lisation voulue de l’ontologie.
A l’opposé des sous-ensembles OWL-Lite, DL et FULL, les profils de OWL 2 sont indépen-
dants.
La norme OWL 2 détermine trois profils : OWL-EL, OWL-RL et OWL-QL [MAILLOT, 2015].
L’expressivité de ces langages proposés par OWL 2 est réglée en fonction de l’exploitation
voulue, de la complexité et également du niveau de raisonnement désirés.

1.5 Types d’hétérogénéité

La diversité du monde réel est une source de richesse et d’hétérogénéité. En effet, dans les
systèmes ouverts et distribués, tel que le Web sémantique, l’hétérogénéité ne peut pas être
évitée parce que les acteurs ont des intérêts et des habitudes différentes, et utilisent des
connaissances et des outils différents, avec des niveaux de détails différents. Toutes ces rai-
sons mènent à diverses formes d’hétérogénéité.
L’hétérogénéité ne repose pas seulement sur les différences entre les buts des applications
pour lesquelles elles ont été désignées, ou sur les formalismes d’expression par lesquelles les
ontologies ont été codées.

Prenons l’exemple du domaine biomédical. Il y a neuf ontologies qui décrivent une maladie
neurologique, allant des ontologies très spécifiques couvrant une seule maladie (e.g. l’épilep-
sie, l’Alzheimer) à des ontologies couvrant toutes sortes de maladies telles que la « Disease
Ontology ». Il en résulte plusieurs ontologies qui décrivent les mêmes concepts sous des mo-
dèles légèrement différents.

On distingue quatre types d’hétérogénéité principales :

• L’hétérogénéité syntaxique se produit quand deux ontologies ne sont pas exprimées

avec le même langage. Cela se produit également quand deux ontologies sont construites en
utilisant différents formalismes de représentation de connaissances, e.g. OWL et F-logic. Ce
type de différence (mismatch) est généralement résolu au niveau théorique quand on établit
des équivalences entre les constructeurs / les primitifs des différents langages. Ainsi, il est
parfois possible de traduire les ontologies en d’autres langages tout en préservant leurs sens.

20
 • L’hétérogénéité terminologique se produit à cause des variations des noms utilisés
pour faire référence aux mêmes entités dans différentes ontologies. Ceci peut être causé par
l’utilisation de différents langages naturels, e.g. Paper vs. Articulo, ou différents sous-langages
techniques spécifiques à un domaine de connaissances bien déterminé, e.g. Paper vs. Memo,
ou l’utilisation de synonymes, e.g. Paper vs. Article.

• L’hétérogénéité conceptuelle, nommée aussi hétérogénéité sémantique ou différence

(mismatch) logique, concerne les différences dans la modélisation d’un même domaine. Cela
peut se produire à cause de l’utilisation de différents axiomes dans la définition des concepts,
ou à cause de l’utilisation de concepts totalement différents. Voici les trois différences concep-
tuelles majeures :

- La différence de convergence : elle survient lorsque deux ontologies décrivent différentes

connaissances avec le même niveau de détail pour une unique perspective.
- La différence de granularité : elle se produit quand deux ontologies décrivent le même
domaine avec une même perspective mais avec différents degrés d’expression des détails.
- La différence de perspectives : elle se manifeste quand deux ontologies décrivent un
même domaine, avec un même degré d’expression des détails mais avec des points de vue et
des perspectives différents.

• L’hétérogénéité sémiotique, nommée aussi l’hétérogénéité pragmatique, concerne la

manière dont les entités sont interprétées par les utilisateurs. En effet, les entités, qui ont
exactement la même interprétation sémantique, sont souvent interprétées par les humains
relativement au contexte et au domaine d’application, e.g. relativement à la manière dont
elles vont être utilisées au final. Ce type d’hétérogénéité est difficile à détecter par la machine,
et encore plus difficile à résoudre, parce qu’il est hors de sa portée. L’utilisation future des
entités a toujours un grand impact sur leur interprétation.

1.6 Conclusion
Enfin, le volume des ontologies ne cesse pas d’augmenter avec les connaissances dans
différents domaines. Cette croissance, fait apparaître les limitations des anciennes méthodes
de gestion et de manipulation des ontologies et de graphes RDF, ce qui nous oblige de
concevoir des nouvelles méthodes pour cet effet.

21
Chapitre 2

Revue sur l’interrogation des graphes

RDF

2.1 Introduction
La sémantique du contenu des ressources dans le Web sémantique, vise à rendre l’infor-
mation explicite pour les machines dans une représentation formelle et standardisée. Cette
standardisation peut aider différents programmes et divers intervenants à inter-opérer ainsi
qu’à échanger des données. La description de la sémantique, dans le cadre du Web séman-
tique, est effectuée par l’intermédiaire des ontologies. Les objets ainsi que les relations, dans
l’univers du discours, sont conceptualisés afin d’être exploitables par les machines. Une des
caractéristiques du Web sémantique, est son hétérogénéité, qui décrit à la fois sa richesse et
son ambiguïté. Cette hétérogénéité reflète la diversité du monde réel, où les connaissances et
les informations peuvent provenir de plusieurs sources différentes. Ainsi, elles peuvent être
représentées dans divers formats. De même, dans le Web sémantique, l’hétérogénéité ne sera
pas une caractéristique exceptionnelle. Alors, le recours à des ontologies s’avère une bonne
solution, mais il ne permet pas d’atteindre une interopérabilité complète à cause de certains
handicaps, tels que le volume, la langue naturelle, etc. La récupération des données devient de
plus en plus difficile, dans le cadre du Web sémantique, en raison de l’hétérogénéité ainsi que
de l’énorme quantité de données qui circulent sur le Web. D’autre part, les utilisateurs ordi-
naires ne peuvent pas gérer les langages d’interrogation hautement spécifiques (e.g. SPARQL)
ou les techniques basées sur la gestion des connaissances.

2.2 Définitions : Standards, Protocoles et Outils

Il y a, de plus en plus, un réel besoin d’outils efficaces pour le stockage et l’interrogation
des connaissances utilisant des ontologies et des ressources connexes. Dans ce contexte, le
stockage des données non structurées est devenu une nécessité afin d’augmenter l’efficacité
du traitement des requêtes.

22
2.2.1 Stockage des données RDF
Avec l’énorme volume des données à sauvegarder, les fichiers (ceux qui stockent les re-
présentations textuelles des données) deviennent vite illisibles pour les utilisateurs et diffici-
lement exploitables. C’est dans ce cadre que les bases de données RDF (BD-RDF), ou
Triple-Stores, sont apparus.

2.2.1.1 Bases de données RDF (BD-RDF)

Nous allons commencer cette partie en expliquant la théorie de graphes [Baas, 2012].
La naissance de la théorie de graphes est attribuée au mathématicien suisse Leonhard Euler,
qui a d’abord résolu le problème des Sept Ponts de Konigsberg en 1736.
Formellement, un graphe est une collection de sommets et d’arcs et réellement, il représente
des entités, en tant que des nœuds, ainsi que la manière dont ces entités reflètent (relient) le
monde réel, ceci est représentée comme des relations. Tous cela forme ce qu’on appelle des
triplets.
"Les graphes ont l’avantage de pouvoir conserver toutes les informations sur une entité, dans
un seul nœud et de représenter des informations connexes par des arcs connectés" (Paredaens
et al. (1995)).

Figure 2.1 – Un échantillon d’un graphe social

Cette structure expressive polyvalente nous permet de modéliser tout sorte de scénarios, de
la construction d’une fusée spatiale à un système de routes, de la chaîne d’approvisionnement
ou de la provenance des aliments, à l’histoire médicale des populations, etc (e.g. les données
de Twitter sont facilement représentées en tant qu’un graphe). La figure 2.1 montre un petit
réseau des utilisateurs Twitter dont chaque nœud est étiqueté User, indiquant son rôle. Ces
nœuds sont alors connectés grâce à des relations, ce qui aide à établir, davantage, le contexte
sémantique : à savoir que Billy FOLLOWS Harry et que Harry, à son tour, FOLLOWS Billy,
etc.

23
. Modèle graphique étiqueté par des propriétés (i.e. Labeled Property Graph
Model) (figure 2.2) 1 , est le plus populaire des modèles. Il suit les caractéristiques suivantes
[Barrasa, 2017] :
- Il contient des nœuds et des relations (dont chaque nœud possède un ID unique) ;
- Les nœuds contiennent des propriétés (des paires clé-valeur) ;
- Les nœuds peuvent être étiquetés par un ou plusieurs labels (ces labels caractérisent les
différents rôles d’un domaine) ;
- Les relations sont nommées et orientées, et toujours, possèdent un nœud de début et un
autre de fin ;
- Les relations peuvent aussi contenir des propriétés.

Ce modèle a été développé par un groupe suédois, dont leur principale motivation ne se
basait pas essentiellement sur l’échange et la publication de données, mais plutôt sur un
stockage efficace de ces données connectées afin d’assurer une interrogation et un parcours
rapides du graphe.
Pour comparer un modèle RDF simple et un modèle graphique étiqueté par des propriétés,
nous pouvons dire que le premier est conçu spécialement pour l’échange des données, alors
que le deuxième est conçu principalement pour le stockage et l’interrogation [Barrasa, 2017].

Figure 2.2 – Modèle graphique étiqueté par des propriétés

Pour le modèle RDF simple, un sommet est soit un sujet soit un objet, ainsi qu’un arc
décrit le prédicat qui les relie. Ce modèle ne possède pas une structure interne (i.e. un en-
semble de propriétés), comme l’indique la figure 2.3 2 .

1. https ://neo4j.com/blog/rdf-triple-store-vs-labeled-property-graph-difference/ Consulté le 12/10/2017

2. https ://neo4j.com/blog/rdf-triple-store-vs-labeled-property-graph-difference/ Consulté le 12/10/2017

24
 Figure 2.3 – Modèle RDF simple

2.2.1.1.a Historique des BD-RDF

L’activité autour des bases de données graphiques s’est épanouie dans la première moitié
des années 90, puis le sujet a presque disparu. Les raisons de ce déclin sont multiples : la com-
munauté de base de données s’est déplacée vers des données semi-structurées, l’émergence de
XML a capturé toute l’attention, etc.

En 2008, Angles et Gutierrez ont réalisé une enquête sur l’historique des modèles de bases
de données graphiques [et Claudio Gutierrez, 2008].
Dans une première approche, Roussopoulos et Mylopoulos (1975), face à l’échec des systèmes
de cette époque à prendre en compte la sémantique des bases de données, ont proposé un
réseau sémantique pour le stockage des données. Une structure implicite des graphes pour les
données elles-mêmes, a été présentée dans le modèle de données fonctionnelles par Shipman
(1981), dont le but était de fournir une interface de base de données « conceptuellement
naturelle ».

Une approche différente décrit le modèle logique de données (MLD) (Kuper et Vardi (1984)),
où un modèle explicite de base de données graphique avait pour but de généraliser les mo-
dèles relationnels, hiérarchiques et de réseau. Plus tard, Kunii (1987) a proposé un modèle
de base de données graphiques appelé G-Base permettant de représenter des structures de
connaissances complexes.

Lécluse et al. (1988) ont présenté O2 qui est un modèle de base de données orientées objet,
basé sur une structure de graphe. Dans le même contexte, GOOD (Gyssens et al. (1990))
est un modèle d’objet orienté graphe, destiné à devenir une base théorique pour les systèmes
dans lesquels la manipulation ainsi que la représentation sont basées sur des graphes trans-
parents.

Guting (1994) a proposé GraphDB, destiné à modéliser et interroger des graphes dans des
bases de données orientées objet, et motivé par la gestion de l’information dans les réseaux
de transport.

Silberschatz et al. (1996) a défini un modèle de base données (db-model ) comme "une col-
lection d’outils conceptuels utilisés pour modéliser des représentations des entités du monde

25
réel, ainsi que les relations entre elles". Pour les BD graphiques, les outils conceptuels qui
font un db.model, doivent au moins s’adresser à la structuration des données, la description,
la maintenance et la manière avec laquelle s’effectue la récupération ou l’interrogation des
données.

Le projet GRAS (Kiesel et al (1996)) utilise les graphes attribués afin de modéliser des in-
formations complexes à partir de projets d’ingénierie logicielle. L’OEM (Papakonstantinou
et al. (1995)) vise à fournir un accès intégré à des sources d’information hétérogènes, en
mettant l’accent sur l’échange des informations.

Newman (2003) [et Claudio Gutierrez, 2008] a divisé les bases de données graphiques en
quatre catégories :
- Réseaux sociaux : où les nœuds sont des personnes ou des groupes, tandis que les liens
représentent les relations ou les flux entre les nœuds (e.g. l’amitié, les relations d’affaires, les
réseaux de recherche, etc).
- Réseaux d’information : où les relations représentent le flux d’information, comme les
citations entre les papiers académiques, les relations entre les classes de mot dans un thésau-
rus, etc.
- Réseaux technologiques : dont les aspects géographiques et spatiaux de la structure sont
les plus importants, e.g. Internet (comme un réseau d’ordinateurs), réseaux téléphoniques,
réseau de livraison (bureau de poste), etc.
- Réseaux biologiques : représentent des informations biologiques dont le volume, la gestion
et l’analyse sont devenus un problème, en raison de l’automatisation du processus de collecte
de données (e.g. réseaux alimentaires, réseaux de neurones, etc).

2.2.1.1.b RDF stores

Un RDF Store (magasin RDF / Triples Store) est une base de données qui sert à stocker
et à interroger des données RDF, ainsi que des méta-données RDF en utilisant un langage
d’interrogation. Parmi les Triples Stores nous citons Filament, G-Store, Redis-graph, Ver-
texDB, CloudGraph, etc. Ces derniers possèdent une capacité de stockage même de milliards
de triplets.

Récemment, il y a eu des développements majeurs au niveau des techniques de stockage

et de traitement des requêtes à partir des magasins RDF. Certains magasins RDF sont
construits à partir de zéro (section 2.2.1.1.d, page 28), tandis que d’autres s’appuient sur des
SGBDR existants (section 2.2.1.1.c, page 27).

Un Triple Store est considéré comme un système de gestion de base de données RDF, dont
une de ses caractéristiques clés est sa capacité de mener des inférences. Les Triples Stores
(encore non pas tous) offrent, en plus du chargement et du stockage de données, la possibilité
de traiter l’occurrence, la sécurité, la récupération, les mises à jour, etc.

Les systèmes de gestion de données RDF peuvent être divisés en deux catégories en fonc-

26
tion de leur capacité à être conformes au modèle RDF : les natives (resp. non natives) qui
sont (resp. ne sont pas) conformes à un modèle RDF. Nous allons détailler ces deux types de
BD-RDF en indiquant leurs différences dans ce qui suit.

2.2.1.1.c BD-RDF non natives

La principale fonctionnalité des BD-RDF non natives est leur architecture. Ces bases de
données RDF sont implémentées au-dessus d’un système de gestion de base de données rela-
tionnel (SGBDR), et c’est pour cette raison qu’elles sont appelées non natives. En effet, les
BD-RDF non natives permettent de bénéficier de l’efficacité des SGBDR. Pour ce faire, il
y a trois techniques de stockage pour les BD-RDF non-natives : la représentation verticale,
la représentation binaire et la représentation horizontale [PELAP, 2016]. Les performances
de ces représentations peuvent changées dépendamment des données RDF et des requêtes
appliquées sur ces données.

- Représentation verticale
Les données sont stockées dans une unique table de trois colonnes qui correspond chacune
au sujet, prédicat, ou objet, respectivement.
Alors, afin d’interroger ces données, les requêtes doivent être traduites en SQL. Pour amé-
liorer la traduction d’un langage d’interrogation RDF (tel que SPARQL ; section 2.2.3, page
31) vers le langage SQL, il est possible de créer d’autres tables auxiliaires.
Ce type de BD-RDF emploient également des outils d’optimisation de requête, e.g. les vues
matérialisées et les indexs, afin de précipiter l’exécution des requêtes SQL. Parmi les BD-
RDF utilisant cette représentation, nous citons 3Store, RDFStore, etc.
Inconvénient : cette représentation est coûteuse pour l’interrogation des bases de données,
vu le besoin d’effectuer un grand nombre d’auto-jointures. De même, les mises à jour néces-
sitent, dans la majorité du temps, la modification de l’ensemble de triplets.

- Représentation binaire
Cette représentation fait correspondre chaque prédicat à une table de deux colonnes (sujet,
objet), contenant les sujets possédant au moins une valeur pour ce prédicat, ainsi que pour
chaque sujet, le ou les objets correspondants pour ce prédicat. Alors, une table est créée pour
chaque propriété. Parmi les BD-RDF qui utilisent cette représentation, nous pouvons citer
4Store et JenaSDB (qui peut être couplé avec PostgreSQL et MySQL).

- Représentation horizontale
Permet de créer une table à chaque classe, possédant pour colonnes les propriétés de la classe.
Elle utilise le constructeur rdfs :Class afin de construire les tables associées aux différentes
classes (e.g. ontoDB ). Afin d’identifier les propriétés des classes, nous utilisons le construc-
teur rdfs :Domain.

⇒ Pour conclure, les relations dans les BDR existent seulement pour la modélisation
du temps comme un moyen de joindre des tables. Cependant, nous avons besoin souvent
de désambiguïser la sémantique des relations qui relient les entités. Et comme les données

27
aberrantes se multiplient et que la structure globale de l’ensemble de données devient plus
complexe et moins uniforme, la connectivité également se traduit, dans le monde relationnel,
par des jointures accrues. Tous cela influence les performances et rend difficile l’évolution
d’une base de données existante (en réponse à l’évolution des besoins). De même, la plupart
des BD NoSQL (i.e. clé-valeur, de document ou de colonnes) stockent des ensembles de
documents/valeurs/colonnes, déconnectés. Cela rend difficile leur utilisation pour des données
et des graphes connectés.

2.2.1.1.d BD-RDF natives

Ces BD-RDF offrent un stockage spécifique qui ne repose pas sur un SGBDR (e.g. Alle-
groGraph, HyperGraphDB, DEX, InfiniteGraph, Neo4j, Sones, etc). D’après [PELAP, 2016],
elles sont groupées en deux types :
• Les BD-RDF in-memory : dès le lancement de l’application, l’ontologie est stockée en
mémoire principale. Cette méthode peut ne pas être efficace dans le cas du stockage d’un de
données extrêmement énorme.
• Les BD-RDF non-memory : l’ontologie ainsi que les données sont stockées sur disque.

Nous pouvons citer quelques exemples de BD-RDF natives :

AllegroGraph (2005) : est une BD graphique moderne et persistante pour le stockage et
l’interrogation des données RDF. Elle utilise le stockage sur disque et donc elle peut stocker
des milliards de triplets. AllegroGraph fournit une API Java très puissante.

DEX (2007) : son objectif est d’assurer de bonne performance dans la gestion de très
grands graphes. Elle permet même l’intégration de diverses sources de données. Elle a un
bon modèle d’intégrité pour la gestion de graphes temporaires et persistants. Les opérations
comme l’analyse des liens, l’analyse du réseau social, la reconnaissance des patrons et la re-
cherche par mots-clés, peuvent être réalisées grâce à son API Java.

Neo4j (2007 ) : est une BD graphique open source, implémentée en Java. Elle est intégrée
et basée sur disque. Elle est capable de représenter les données d’une manière facilement
accessible. Dans Neo4j, un graphe peut être considéré comme une structure richement inter-
connectée.

La puissance des bases de données graphiques (i.e. BD-RDF natives) [PELAP, 2016] :
• Performance : les performances des BD graphiques restent relativement constantes,
même lorsque l’ensemble de données augmente. C’est parce que les requêtes sont localisées
sur une partie du graphe. Par conséquent, le temps d’exécution pour chaque requête est pro-
portionnel uniquement à la taille de la partie du graphe traversée pour traiter cette requête,
et non pas à la taille du graphe global.

• Flexibilité : les graphes sont de nature additifs, ce qui signifie que nous pouvons
ajouter de nouveaux types de relations, de nouveaux nœuds, de nouvelles étiquettes et de
nouveaux sous-graphes à une structure existante, sans perturber les fonctionnalités d’une

28
application. Nous n’avons pas à modéliser notre domaine de manière exhaustive à l’avance.
La flexibilité du modèle graphique signifie également que nous pouvons effectuer moins de
migrations, ce qui réduit alors les risques et les frais généraux de maintenance.

• Agilité : la nature sans schéma du modèle de données graphiques, associée à la na-

ture testable de l’API d’une base de données graphiques, ainsi qu’au langage d’interrogation,
nous permet de faire évoluer notre application de manière contrôlée en fonction des environ-
nements métier changeants.

La description de données dans les BD-RDF natives, différencie d’une BD-RDF à une
autre. En effet, la représentation de données est interne et propre à chaque DB-RDF native.
Nous pouvons ainsi distinguer les BD-RDF à partir des structures de données utilisées.

2.2.1.1.e Différences entre RDF Store et BD-RDF

Même si ses derniers ont été conçus afin de stocker des données inter-connectées (Linked
Data), sachant que RDF est un type particulier de Linked Data, il y a quelques différences
entre eux et qui sont comme suit :

- Les bases de données graphiques sont plus polyvalentes avec les langages d’interrogation ;
- Les bases de données graphiques peuvent stocker divers types de graphes, notamment les
graphes non orientés, les hypergraphes, etc. Par contre, les Triples Stores se concentrent uni-
quement sur le stockage de rangées de triplets RDF. Ils ont pour but de stocker des données
RDF qui représentent un type particulier de graphes : graphe étiqueté orienté ;
- Les bases de données graphiques sont basées sur les nœuds et les propriétés alors que les
Triples Stores sont centrés arcs ;
- Les Triples Stores fournissent également des inférences sur les données tandis que les bases
de données orientées graphe ne le font pas ;
- Les bases de données graphiques peuvent assurer une très haute performance au niveau de
l’accessibilité et la navigation (e.g. la récupération du chemin le plus court entre deux nœuds,
ou bien la détermination de la manière dont n’importe quels deux nœuds sont connectés).

D’après [Angles, 2012] et en considérant le niveau de maturité des bases de données gra-
phiques en termes d’équipements offerts par le système de gestion de base de données, il
existe deux types de développements :
- Bases de données graphiques : elles doivent fournir les composants majeurs d’un système
de gestion de base de données ;
- Magasins graphiques (graph stores) : regroupe des implémentations offrant des fonctionna-
lités de base pour stocker et interroger des graphes.

Puisque RDFS permet de raisonner sur les données RDF, quelques BD-RDF utilisent
un moteur de raisonnement. Nous allons voir dans la sous-section suivante, les techniques
existantes destinées à réaliser des raisonnements sur les BD-RDF.

29
2.2.2 Moteurs de raisonnement et saturation de données
Appelés également moteurs d’inférence ou raisonneurs, ils permettent d’effectuer des in-
férences sur un ensemble de données RDF. Leur principal rôle est de générer de nouvelles
données sous forme de triplets, ou également de vérifier la validité de l’ensemble de données,
tout cela en appliquant des règles d’inférences. La plupart des BD-RDF possèdent un rai-
sonneur (e.g. Hermit, Pellet, Racer, etc).

- Validation de données : consiste à vérifier s’il n’existe pas de données inconsistantes.

Une donnée inconsistante peut, par exemple, être une restriction qui spécifie qu’une classe
doit hériter de deux classes disjointes. Ainsi, cette information ne peut être jamais effectuer
en suivant les règles établies par le schéma d’ontologies. Le moteur d’inférence affichera alors
une incohérence.

- Inférence : la seconde caractéristique du raisonneur consiste à créer un modèle de données

dérivées (inférées), tout en se basant sur le modèle de base ainsi que sur des restrictions et
des règles définies par l’ontologie.

Les moteurs d’inférence procèdent avec deux principales techniques : le chaînage avant et
le chaînage arrière. Ces dernières sont très coûteuses en termes du temps par rapport aux
règles d’inférence utilisées et à la taille des données à inférer. Par conséquent, ce raisonnement
peut être effectué avant l’exécution des requêtes, on appelle cela saturation des données, ou
bien lors de l’interrogation de données, c’est la reformulation des requêtes [PELAP, 2016].

2.2.2.1 Saturation des données

C’est la production de quasiment tous les triplets possibles en appliquant toutes les règles
d’inférence sur les données RDF. Ces triplets sont appelés alors triplets inférés, et c’est le rôle
du moteur de raisonnement de les produire. Ces triplets dérivés seront rajoutés à l’ensemble
de données de départ, et à ce moment là, nous pouvons dire que l’ensemble de données RDF
est saturé.

Pendant la saturation, chaque triplet inféré peut participer à l’inférence d’autres triplets
jusqu’à ce qu’un point fixe soit atteint (i.e. pas de nouveaux faits peuvent être inférés).
Ensuite, la réponse à la requête est réduite à une simple évaluation de la requête sur cet
ensemble de données saturé.
Par conséquent, la saturation fournit un support efficace pour le traitement de requêtes.
Cependant, elle nécessite beaucoup du temps pour qu’elle soit calculée, et beaucoup d’espace
de stockage pour le sauvegarde des données inférées, également un effort important pour le
maintien ou le re-calcul de la fermeture après les mises à jour.
De même, toute modification des données RDF nécessite de refaire la saturation (car du
moment où l’ensemble de données est saturé, aucun nouveau triplet ne peut être inféré
avec une ou plusieurs règles d’inférence). Afin de résoudre ce problème, en particulier si les
données RDF sont dynamiques, quelques BD-RDF proposent la technique de reformulation
de requêtes.

30
2.2.2.2 Reformulation des requêtes
C’est une alternative à la technique de saturation de données et consiste à réécrire la
requête (au moment de son exécution) en prenant en considération un ensemble de règles
d’inférence. Le langage d’interrogation SPARQL (section 2.2.3) dispose de beaucoup de ré-
gimes d’inférence sous lesquels une requête peut être exécutée. Parmi les régimes d’inférence
de SPARQL, nous pouvons citer le régime d’inférence RDFS.
De même, pour les utilisateurs et les systèmes qui désirent définir eux-mêmes leurs règles
d’inférences, le langage d’interrogation SPARQL propose un régime d’inférence RIF (Rules
Interchanged Format) permettant de représenter et prendre en considération des règles d’in-
férence non prédéfinies dans SPARQL.

Le principal inconvénient de la reformulation réside dans le fait que les requêtes refor-
mulées ont tendance à être syntaxiquement complexes. Cela augmente généralement et de
manière significative, le coût de l’évaluation.

Afin d’exploiter les données RDF stockées dans les BD-RDF, qu’elles sont saturées ou
non, des langages d’interrogation ont été proposés. Ces derniers sont de différents types.
Nous pouvons citer, par exemple, la catégorie de langages qui traitent les données sous forme
de triplets sans prendre en compte la sémantique (qui est associée aux éléments des triplets),
e.g. le langage SPARQL, RDQL, SquishQL, etc. Dans une autre catégorie de langages, la
séparation entre le schéma de données et de l’ontologie est bien mentionnée au moment
de l’interrogation (e.g. le langage RQL, SeRQL et OntoQL). Il existe également une autre
famille de langages qui sont inspirés de XPath ou XQuery afin d’interroger des données et
des ontologies (e.g. RDF-Path et Versa).

2.2.3 Le langage d’interrogation de graphes RDF : SPARQL

Stocker une quantité immense de données de façon structurée n’aurait aucun intérêt s’il
était irréalisable et impossible de pouvoir accéder à ces données. Alors, il est indispensable
d’avoir un langage d’interrogation, à l’instar des autres langages tels que SQL. Pour le Web sé-
mantique, c’est SPARQL qui représente le langage standard d’interrogation de graphes RDF.

SPARQL, est l’acronyme de Simple Protocol And RDF Query Language, est une recom-
mandation du W3C depuis 15 janvier 2008. Il joue le rôle d’un pont entre les technologies
du Web sémantique (dont RDF ), et les plateformes Web déjà existantes. Il est une API
universelle d’accès aux données.

SPARQL est, d’une part, un protocole et un langage de requête permettant l’accès aux don-
nées RDF. Il est aussi un protocole d’accès comme un service Web (SOAP : Simple Object
Access Protocol), et également, un langage de présentation des résultats (XML).

Il ne prend pas en charge l’inférence en elle-même. Il ne fait rien de plus que de prendre les
descriptions de ce que l’application veut, sous la forme d’une requête, et renvoie le résultat

31
sous forme de graphe RDF. Par ailleurs, SPARQL peut être utiliser afin d’exprimer des re-
quêtes sur différentes sources de données.

La requête SPARQL officielle adopte quatre formes diverses :

- Requête de la forme SELECT , renvoie la valeur de la variable, qui peut être attachée par
un modèle de requête équivalent/correspondant ;
- Requête ayant la forme ASK , renvoie vrai si la requête correspond aux données et faux
sinon ;
- Requête de la forme CONSTRUCT , retourne les réponses qui satisfont un ensemble de
contraintes, sous forme de graphe RDF. La structure du graphe retourné est décrite par un
patron (ou template) dans la requête. Elle est comparable à une vue matérialisée dans les
SGBDR ;
- Requête de la forme DESCRIBE , renvoie un graphe RDF décrivant une ressource RDF
particulière.

Parmi les fonctionnalités du langage SPARQL, nous citons :

- FILTERS : contraint les résultats de la requête à uniquement ceux où l’expression du filtre
est évaluée à TRUE ;
- OPTIONAL : puisque les données RDF sont des données semi-structurées, lorsqu’une
requête est exécutée, elle n’échoue jamais même si les données n’existent pas. Ceci est réalisé
grâce à la clause OPTIONAL ;
- LIMIT : met une limite au nombre de résultats de requête retournés ;
- ORDER BY : cette clause est utilisée pour classer (dans l’ordre croissant ou décroissant)
les résultats de la requête ;
- DISTINCT : est utilisée pour éliminer les doublons présents dans le résultat de la requête ;
- REGEX : cet opérateur appelle la fonction de correspondance pour faire correspondre le
texte avec un patron d’expression régulière ;
- UNION : combine des patrons graphiques.

Modification : La norme SPARQL 1.1 introduit, entre autres, les requêtes SPARQL
d’ajout ou de suppression de triplets dans une base de données RDF grâce aux clauses
INSERT et DELETE. Ces requêtes permettent de créer de nouveaux triplets suivant un
patron de graphe (i.e. TP, section 2.2.3.1). Elles peuvent utiliser une clause WHERE afin
d’insérer des données qui sont générées à partir des données existantes.

2.2.3.1 Patron de triplet (TP) et patron de graphe (BGP)

L’élément de base d’une requête SPARQL est le BGP (Basic Graph Pattern) (i.e. patron
de graphe), qui peut être considéré comme un ensemble de fragments de requête élémentaires,
appelés TP (Triple Pattern). Un TP est représenté sous la forme d’un triplet RDF, pouvant
comporter une ou plusieurs variables (i.e. un identifiant alphanumérique commençant par
" ?") en tant que sujet, prédicat ou objet. Les sujets et les prédicats peuvent être des URIs,
des nœuds blancs ou des variables, alors que les objets peuvent, en plus, être des littéraux. Le
patron de triplet (TP ) permet de trouver les triplets RDF, à partir d’un graphe, qui satisfont

32
le modèle qu’il définit, ce processus est appelé matching.
Dans un patron de graphe (BGP ), les variables qui sont partagées par au moins deux
patrons de triplets (TP ), sont nommées variables de jointures. Ainsi, interroger un graphe
RDF avec un BGP, revient à chercher des valeurs pour chacune des variables du patron de
graphe pour que le graphe RDF obtenu (en remplaçant les variables par ces valeurs) soit un
sous-graphe du graphe RDF global.

2.2.3.1.a Définition formelle d’un patron de triplet et d’un patron de graphe

Dans SPARQL, un graphe RDF est vu comme un ensemble de triplets RDF. Pour un
graphe G, nous supposons que :
- U, l’ensemble des URIs associés à G ;
- L, l’ensemble des littéraux dans G ;
- B, l’ensemble des nœuds blancs / anonymes de G.

Un triplet RDF est, formellement, un élément de l’ensemble (U ∪ B) × U × (U ∪ B ∪ L).

Comme nous venons de le dire, un patron de triplet (TP) est un triplet RDF qui peut
contenir des variables. Ainsi, un patron de triplet (TP) peut être défini comme un élément
de l’ensemble (U ∪ V ) × (U ∪ V ) × (U ∪ V ∪ L) ; où V est un ensemble de variables disjoint de
U, L et B. On supposera que var(t) est l’ensemble des variables d’un patron de triplet (TP).
Un patron de graphe (BGP) est interprété comme une conjonction de patron de triplets, i.e.
si Q est un patron de graphe, ainsi, Q = t1 ∧ t2 ∧ ... ∧ tn ; où chaque ti (tel que 1 ≤ i ≤ n)
est un patron de triplet. On notera alors | Q | le nombre de patrons de triplets (TP) d’un
patron de graphe (BGP). Tout comme pour var(t), on note var(Q), l’ensemble des variables
distinctes des patrons de triplet de Q.

2.2.3.2 Avantages de SPARQL

Avec les services Web 2.0 existants, les Web services sont bien évidemment disponibles,
alors qu’ils ne sont pas normalisés. Il faut donc savoir les méthodes du Web services et la
structure des données afin de pouvoir les interroger.

⊕ Avec SPARQL, nous n’avons pas besoin de connaître à l’avance la structure et le contenu
des informations afin de pouvoir les récupérer. En fait, SPARQL permet d’interroger n’im-
porte quel constituant d’un triplet admettant la forme Sujet-Prédicat->Objet.

⊕ Une base de données graphique, qui peut être interrogée par des requêtes SPARQL via
Internet, propose un point d’accès, appelé endpoint SPARQL, où l’envoie de requêtes se fait
via HTTP (i.e. Hyper Text Transfer Protocol).

2.2.3.3 Limitations de SPARQL

SPARQL est une technologie jeune, la spécification du W3C en cours possède en-
core quelques limites. Ces limitations deviennent claires lorsqu’on compare SPARQL à des

33
langages d’interrogation stables et établis, à l’instar de SQL ou XQuery. La liste suivante
présente les caractéristiques manquantes dans SPARQL.

Agrégation : la spécification courante ne prend pas en charge les fonctions d’agrégation,

comme l’addition des valeurs numériques, le calcul de la moyenne, etc ;

Négation : SPARQL ne supporte pas bien la "négation", e.g. trouver toutes les per-
sonnes qui sont les amis de Bob mais qui ne connaissent pas Alice ;

Les prédicats ne peuvent pas avoir des propriétés : Cela peut être une limitation
RDF héritée par SPARQL, puisque RDF représente tout dans des triplets. Il est facile d’im-
plémenter les propriétés d’un nœud en utilisant des triplets supplémentaires. En revanche, il
est très difficile d’implémenter des propriétés dans des arcs. Dans SPARQL, il n’existe aucun
moyen d’attacher une propriété à un prédicat, e.g. Bob connaît Peter depuis 5 ans ;

Support des correspondances floues avec des résultats classés : SPARQL est
basé sur un modèle de requête booléen conçu pour une correspondance exacte. Exprimer une
correspondance floue avec un résultat classé, est très difficile. Par exemple, retrouvez les 20
premiers postes "similaires" à ce poste et classés par degré de similarité ;

Expressions de chemin : SPARQL ne traite pas la spécification des expressions de

chemin, e.g. à partir d’une seule requête SPARQL, il est impossible de calculer la fermeture
transitive d’un graphe ou bien d’extraire tous les nœuds qui sont accessibles à partir d’un
nœud donné. Cette lacune a été plusieurs fois identifiée dans des publications précédentes.
Ainsi, différentes propositions pour l’intégration des expressions de chemin dans le langage,
ont été proposées par Pérez et al., (2009), Kochut et Janik, (2007) et Alkhateeb et al., (2009) ;

Vues : dans les langages d’interrogation traditionnels tels que SQL, des vues logiques sur
les données jouent un rôle considérable. Ils sont indispensables pour la conception de base de
données et pour la gestion de l’accessibilité. SPARQL ne prend en ce moment pas en charge
la spécification de vues logiques sur les données ;

Prise en charge des contraintes : le mécanisme d’affirmation et de vérification des

contraintes d’intégrité dans les bases de données RDF, n’est pas géré au niveau de la spéci-
fication actuelle de SPARQL.

En somme, les ontologies et les technologies liées à ces dernières, telles que le langage
SPARQL, sont encore inconnues ou peu maîtrisées par des utilisateurs non-experts. Ces
utilisateurs peuvent alors avoir besoin d’un appui ou d’une assistance lors de l’exploitation de
ces données. Par ailleurs, les ontologies contiennent des données hétérogènes et dynamiques,
pouvant rapidement évoluer avec le temps et rendre, par la suite, les connaissances des usagers
obsolètes pour l’exploitation de ces données RDF. Ce manque de connaissance des utilisateurs
sur les données des RDF, est l’un des causes des formulations incomplètes ou incorrectes
des requêtes qui renverront, par conséquent, des réponses insatisfaisantes aux utilisateurs.

34
Pour éviter cela, les usagers ont besoin d’être accompagnés et soutenus dans la construction
des requêtes et/ou dans le traitement de ces dernières. Pour palier ce problème, plusieurs
approches coopératives ont ainsi été développées afin de proposer des solutions alternatives
aux utilisateurs.

2.3 Revue sur les différents travaux de comparaison des

BD-RDF
Rohloff et al. (2007) dans [Rohloff et al., 2007], ont évalué les nouvelles technologies des
Triples Stores les plus prometteurs du Web sémantique. Cette étude se concentre sur les
préoccupations particulières de l’application client telles que, le volume de données, les me-
sures de performance fondamentales (temps du chargement et vitesse de l’interrogation), et
les inférences de base. Cette étude tire parti du benchmark LUBM (i.e. Lehigh University
BenchMark ). Les triples stores évalués dans cette étude sont : MySQL, DAML BL, Swif-
tOWLIM, et BigOWLIM, et qui supportent différents langages d’interrogation (e.g. SPARQL,
SeRQL). Idéalement, un Triple Store doit avoir un temps de réponse qui n’augmente pas (ou
à la limite augmente faiblement), quand le nombre de triplets à charger accroît. Ceci n’était
pas le cas avec les bases de données graphiques testées.

Les métriques prises en considération sont :

- Temps du chargement accumulé : le temps mesuré en heure, pour charger les fichiers OWL
décrivant les départements universitaires, dans des triples stores, pour un nombre donné de
triplets ;
- Temps de réponse à la requête : est calculé comme la moyenne des temps d’exécution pour
chacune des quatre requêtes identifiées ;
- Les exigences d’espace disque : la quantité d’espace disque demandée pour charger les don-
nées d’évaluation, etc.

Stegmaier et al. en 2009 ont évalué les bases de données RDF existantes à ce moment-là,
et qui supportent le langage d’interrogation SPARQL, tout en se basant sur quelques critères
[Stegmaier et al., 2009] :
- L’extensibilité : ce qui permet l’intégration de nouvelles fonctionnalités ;
- Aperçu architectural ;
- Disponibilité de langages d’interrogation (i.e. si elles supportent d’autres langages d’inter-
rogation) ;
- Interprétation des formats de données RDF ;
- L’expressivité de SPARQL et la performance des frameworks/applications.

En 2011, Morsey et al. ont proposé une méthodologie de création de Benchmark SPARQL
générique appelée DBPSB (i.e. DBPedia SPARQL Benchmark), afin d’évaluer la perfor-
mance et la capacité des Triples Stores les plus populaires : Virtuoso, Sesame, Jena-TDB
et BigOWLIM [Morsey et al., 2011]. Pour ce faire, ils ont utilisé 24 modèles de requête
SPARQL, couvrant les caractéristiques de SPARQL les plus couramment utilisées, et conte-

35
nant toutes les fonctionnalités de ce dernier (e.g. FILTER, REGEX, etc.)
Leur méthodologie suit les quatre exigences clés pour les Benchmarks spécifiques au domaine :
- Pertinence : le test des opérations typiques dans un domaine spécifique ;
- Portabilité : le Benchmark doit être exécutable sur différentes plateformes ;
- Évolution : il est possible d’évaluer ce Benchmark sur de petits et de très grands ensembles
de données ;
- Compréhensible.
Virtuoso était clairement le plus rapide, suivi par BigOWLIM, Sesame et JenaTDB. Il y
avait en moyenne une baisse linéaire de la performance de la requête avec l’augmentation de
la taille de l’ensemble de données. Virtuoso a été le seul qui a répondu à toutes les requêtes
à temps, et celui qui a pu évoluer sur le DBPSB.

D’après Angles (2012) dans [Angles, 2012], une base de données graphique doit fournir :
- Des interfaces externes (interfaces utilisateur ou API ) ;
- Des langages de base de données (pour la définition, la manipulation et l’interrogation de
données) ;
- Un optimiseur de requêtes ;
- Un moteur de base de données (modèle de niveau intermédiaire) ;
- Un moteur de stockage (modèle de bas niveau) ;
- Un moteur de transaction ;
- Des fonctionnalités d’opération et de gestion (pour le réglage, la sauvegarde, la récupéra-
tion, etc).
Parmi les BD graphiques qui respectent ces conditions, il a cité, AllegroGraph, DEX, Hyper-
GraphDB, InifiniteGraph, Neo4j et Sones.

Par la suite, il a examiné le support de trois schémas/manières de stockage (à savoir, la

mémoire principale, la mémoire externe et le stockage principal) des différentes BD graphiques
citées auparavant, ainsi que la mise en œuvre des indexs (figure 2.4). Il est important de
souligner que la gestion d’une énorme quantité de données est une exigence importante dans
les applications de la vie réelle pour les bases de données graphiques. Par conséquent, la prise
en charge du stockage en mémoire externe est une exigence principale. De plus, les indexs
sont importants pour améliorer les opérations de récupération de données.

36
 Figure 2.4 – Fonctionnalités du stockage des données RDF (Angles (2012))

Du point de vue fonctionnement et manipulation des données (figure 2.5), il a évalué si une
base de données graphique implémente des langages de base de données, des interfaces de
programmation d’application (API) et des interfaces graphiques utilisateur (GUI). Il a consi-
déré trois langages de base de données :
- Le langage de définition de données (Data Definition Language), qui permet de modifier
le schéma de la base de données en ajoutant, modifiant ou supprimant ses objets ;
- Le langage de manipulation de données (Data Manipulation Language), qui permet d’in-
sérer, de supprimer et de mettre à jour des données dans la BD ;
- Le langage d’interrogation (Query Language), qui permet d’extraire des données.

Figure 2.5 – Fonctionnalités de manipulation et d’opération (Angles (2012))

Il a constaté, également, que les contraintes d’intégrité sont mal étudiées par les BD gra-
phiques. Il a, entre autres, considéré plusieurs contraintes d’intégrité :
- La vérification des types, pour tester la cohérence d’une instance par rapport aux définitions
dans le schéma ;

37
- L’identité de nœud / de relation, pour vérifier qu’une entité ou une relation peut être iden-
tifiée par une valeur (e.g. un nom ou un ID) ou par les valeurs de ses attributs (e.g. une
identification de voisinage) ;
- L’intégrité référentielle, pour vérifier que seules les entités existantes sont référencées ;
- Vérification de cardinalité, pour vérifier l’unicité des propriétés ou des relations ;
- Dépendance fonctionnelle, pour tester qu’un élément du graphe détermine la valeur d’un
autre ;
- Contraintes du patron graphique pour vérifier une restriction structurelle (e.g. des contraintes
de chemin).

Il a finalement conclu que la prise en charge des schémas évolutifs est la caractéristique des
bases de données graphiques couramment utilisées pour justifier l’absence de contraintes d’in-
tégrité. Cela n’est pas un argument valide, sachant que que la cohérence des données, dans
une base de données, est égale ou même plus importante qu’un schéma flexible.

Il a testé la puissance des bases de données graphiques à résoudre plusieurs types requêtes,
qui peuvent être considérées essentielles (figure 2.6).

Figure 2.6 – BD graphiques actuelles et leur support pour des requêtes essentielles (Angles
(2012))

1. Requêtes d’adjacence :
Deux nœuds sont adjacents (voisins), s’il existe un arc qui les relie. De même, deux arcs
sont dits adjacents s’ils relient un nœud en commun. Quelques requêtes typiques dans ce
groupe sont, l’adjacence de nœud/arc de base, afin de tester si deux nœuds sont adjacents,
de calculer les k-voisins d’un nœud, de lister tous les voisins d’un nœud, etc.

38
2. Requêtes d’accessibilité :
Ce type de requêtes est caractérisé par les problèmes de chemin et de parcours. Il a considéré
deux types de chemins :

- Les chemins à longueur fixe : contiennent un nombre fixe de nœuds et d’arcs.

- Les chemins simples réguliers : qui fournissent certaines restrictions de nœud et d’arc.
Dans ce contexte, un problème plus complexe consiste à trouver le plus court chemin entre
deux nœuds.

3. Requêtes de correspondance de patrons (pattern matching) :

Elles permettent de trouver tous les sous-graphes d’un graphe de données, qui sont isomorphes
au patron graphique. Elles traitent deux problèmes :

- Le problème d’isomorphisme graphique qui a une complexité de calcul inconnue.

- Le problème d’isomorphisme sous-graphique qui est un problème NP-complet.

4. Requêtes de synthèse :
Ces requêtes ne sont pas censées consulter la structure du graphe. Cependant, elles sont ba-
sées sur des fonctions spéciales qui permettent de résumer ou d’opérer sur les résultats de
la requête, renvoyant normalement une seule valeur. Les fonctions agrégées (e.g. moyenne,
count, maximum, etc) sont incluses dans ce groupe.

De plus, Angles a considéré des fonctions pour calculer certaines propriétés d’un graphe ainsi
que ses éléments. Par exemple :

- L’ordre du graphe (i.e. le nombre de sommets) ;

- Le degré d’un nœud (i.e. le nombre de voisins d’un nœud) ;
- Le minimum, le maximum et le degré moyen dans le graphe ;
- La longueur d’un chemin (i.e. le nombre d’arêtes dans le chemin) ;
- La distance entre les nœuds (la longueur du plus court chemin entre les nœuds) ;
- Le diamètre du graphe (la plus grande distance entre deux nœuds quelconques), etc.

Sachant que la plupart des bases de données graphiques implémentent une API au lieu d’un
langage d’interrogation, il a, ainsi, évalué si une API peut répondre à une requête essentielle.

D’un autre côté, et puisque il n’existe pas de langages standards pour l’interrogation de
graphes RDF (l’absence d’un langage d’interrogation standard est un inconvénient des bases
de données graphiques actuelles), en 2012 Mike Buerli a divisé les modèles de bases de don-
nées graphiques par langage [Buerli and Obispo, 2012] :
- Bases de données graphiques ;
- BD graphiques distribuées (e.g. Horton (2010) créée par Microsoft, InfiniteGraph (2010)) ;
- Bases de données graphiques à clé-valeur (e.g. VertexDB (2009), CloudGraph (2010)) ;
- Bases de données de documents (e.g. Orientdb (2009), CouchDB) ;
- Bases de données graphiques SQL (e.g. Filament (2010), G-Store (2010)) ;

39
- Bases de données graphiques Map/Reduce (e.g. Pregel (2009), Phoebus (2010), Giraph
(2011)).

Dans un graphe, les arcs, définis entre les paires de sommets, forment la topologie de ce
dernier. Ainsi, une base de données graphique doit être efficace pour exploiter les informa-
tions topologiques. Elle doit fournir un moyen rapide et efficace pour traverser les graphes.
Lorsqu’on traite des problèmes de parcours du graphe, l’approche habituelle consiste à char-
ger les données du graphe dans la mémoire principale, et à effectuer la (les) opération (s) de
traversée, tout en gardant la structure entière dans la mémoire.

Cependant, cette approche impose une limite à la taille du graphe. Les solutions, pour par-
courir le graphe sur les supports persistants, ne sont pas courantes, car le coût des accès
aléatoires à un support persistant est problématique. C’est un grand défi pour les bases de
données graphiques, où un utilisateur s’attend à la persistance des données et à la prise en
charge des opérations de parcours rapides. C’est la caractéristique principale qui distingue
les bases de données graphiques des autres systèmes de gestion de données.

Du point de vue performance et capacité d’effectuer des opérations de parcours sur la struc-
ture graphique, Ciglan et al. (2012) dans [Ciglan et al., 2012], ont développé un benchmark de
parcours afin de tester la capacité des bases de données graphiques, Neo4J, DEX, OrientDB,
le référentiel RDF natif (NativeSail ) et le prototype de recherche SGDB8, à :
- Effectuer des traversées locales à partir d’un ou plusieurs sommets, et explorer leur voisinage
k-hop ;
- Effectuer des parcours de tout le graphe ;
- Tester les cas où le graphe entier ne peut pas être mis en cache dans la mémoire principale.

La conclusion des résultats préliminaires est que les traversées locales dans un grand réseau,
sont plus adaptées aux systèmes testés, que ceux nécessitant des traversées de toute la struc-
ture du graphe.

Jouili et al. (2013) ont évalué, dans leur travail [Jouili and Vansteenberghe, 2013], quatre
BD graphiques (Neo4j, Titan, OrientDB et DEX ). Ils ont mis l’accent sur l’utilisation des
Blueprints (une API Java générique pour les bases de données graphiques) dans les applica-
tions, ce qui permet de changer de base de données graphique sans des efforts d’adaptation.
Ils ont également utilisé, pour leur comparaison, GDB (i.e. Graph Database Benchmark) qui
est un cadre d’analyse comparative distribué, open-source sous Java. Son principal objectif
est de comparer les bases de données graphiques en utilisant des opérations graphiques ha-
bituelles telles que, l’exploration des voisins d’un nœud, la découverte du plus court chemin
entre deux nœuds, ou simplement l’obtention de tous les sommets qui partagent une propriété
spécifique.

Ils ont voulu aussi analyser l’impact de la taille d’un graphe sur les performances d’une base
de données, les parcours et les opérations intensives. Ils ont alors utilisé deux graphes : l’un
ayant 250 000 sommets (1 250 000 arcs), et l’autre ayant 500 000 sommets (2 500 000 arcs).

40
 Lissandriniet et al. en 2017 [Lissandrini et al., 2017] ont fourni une évaluation systéma-
tique et complète des bases de données graphiques les plus modernes ArangoDB et BlazeGraph
(qui sont les BD graphiques les plus récentes), Neo4J, OrientDB, Sparksee (DEX) et Titan.
Leurs expérimentations ont été réalisées sur 28 millions nœuds et 31 millions arcs, par op-
position aux travaux existants (250 000 nœuds et 2.2 millions arcs). Ils ont utilisé plusieurs
bases de test telles que yeast, Frb-S, Mico et ldbc. Ils ont évalué pour chaque BD :

- Le chargement de données :
Le temps du chargement : pour tous les ensembles de données, ArangoBD avait le temps
le plus court, suivi par Neo4j. Sur l’ensemble de données le plus grand (Frb-L), ArangoDB
était encore une fois le plus rapide. Neo4j (v.3.0) est juste quelques minutes plus lent, suivi
par Neo4j (v.1.9).
L’espace du chargement : ils ont mesuré la taille du disque occupée par les données
pour chaque système.
- Taux d’achèvement : puisque les bases de données graphiques sont souvent utilisées pour
les applications en ligne, il est important de s’assurer que les requêtes s’exécutent dans un
délai raisonnable.
- Insertion, mis à jour et suppression : les tests montrent des performances extrêmement
rapides pour Sparksee, Neo4j (v.1.9) et ArangoDB.
- Les sélections générales : BlazeGraph est le plus lent, avec des performances autour de
500 ms pour la recherche des nœuds, et 4 secondes ou plus pour la recherche des arêtes. Neo4j
(v.1.9), OrientDB et Sparksee retournent un résultat dans environ 10 ms.
- Les performances globales : ils ont comparé le temps cumulé pris par chaque système
pour compléter l’ensemble des requêtes.

2.4 Revue sur les méthodes existantes pour l’interroga-

tion par des requêtes SPARQL des graphes RDF
Dans la littérature, plusieurs approches ont essayé d’exploiter et de mettre en œuvre les
notions précédemment introduites.

Ainsi, avoir des données sémantiques sur le Web et compréhensibles par les machines, ne
suffit pas. Il est nécessaire d’avoir des outils pour traiter les informations, les transformer et
faire des raisonnements au-dessus.

Le travail de Hartig et Heese (2007) dans [Hartig and Heese, 2007], est fondé sur un modèle
graphique de requête SPARQL, appelé SQGM (SPARQL Query Graph Model). Au-dessus
du SQGM, ils ont défini des règles de transformation afin de faciliter et de réécrire la requête
en une autre sémantiquement équivalente. Le SQGM est utilisé pour stocker les informations
sur la requête en cours de traitement.

41
Les éléments de base d’un SQGM sont les opérateurs et les flux de données. Un opérateur
traite les données, et un flux de données connecte l’entrée et la sortie de deux opérateurs. Un
SQGM peut être interprété comme étant un graphe étiqueté orienté avec des sommets et des
arcs représentant des opérateurs et des flux de données, respectivement. Les opérateurs ont
une tête, un corps et des annotations supplémentaires. Un arc symbolise le flux de données
entre deux opérateurs indiquant qu’un opérateur consomme la sortie d’un autre opérateur.
Un flux de données permet également de transférer les données fournies par l’un des opéra-
teurs et consommées par un autre.
Ils ont défini un ensemble de types d’opérateurs afin de pouvoir couvrir les structures du
langage SPARQL. Parmi ces opérateurs, il existe l’opérateur du patron graphique (BGP) qui
est définit dans la spécification SPARQL. Dans la représentation graphique d’un opérateur
du patron graphique, la tête liste les noms des variables liées par l’opérateur, alors que le
corps contient les propriétés de l’opérateur.

Une autre idée pour l’interrogation en utilisant SPARQL a été présentée dans le travail de
Quilitz et Leser (2008), où ils ont développé DARQ [Quilitz and Leser, 2008]. Ce système
fournit un accès de requête transparent à plusieurs services SPARQL, c’est-à-dire qu’il donne
à l’utilisateur l’impression d’interroger un seul graphe RDF malgré la distribution de données
sur le Web.
Le moteur de recherche décompose une requête en sous-requêtes, auxquelles chaque service
peut répondre. Un optimiseur de requêtes prend les sous-requêtes et construit un plan d’exé-
cution optimisé. Enfin, les sous-requêtes sont envoyées aux sources de données et les résultats
sont intégrés.

Les données RDF sont considérées comme un graphe orienté étiqueté, et le résumé du
graphe est représenté comme une structure d’index, où certains nœuds sont fusionnés tout en
conservant tous les arcs. Plus une requête est optimisée, moins il faut du temps pour trouver
une réponse correspondante. L’efficacité de la requête joue un rôle important lorsqu’il s’agit
de données à grande échelle.
Dans ce cadre, Nguyen et al., ont examiné les approches récentes pour l’évaluation des re-
quêtes [Nguyen et al., ]. La plupart de ces approches récupèrent des sous-graphes (i.e. des
données RDF) pour chaque patron de triplet dans la requête. Puis, les données RDF sont
jointes (fusionnées) pour trouver une réponse correspondante. Ainsi, le nombre des opéra-
tions de jointure augmente avec le nombre de patrons de triplets. Cette approche entraîne un
grand nombre de données intermédiaires inutiles pour chaque requête, et nécessite un temps
considérable pour générer et traiter des données qui ne contribueront pas aux résultats de
la requête. Lorsque l’ensemble de données RDF évolue, le volume de résultats intermédiaires
peut avoir un effet significatif sur les performances d’une requête.
Pour cette raison, ils ont adopté un nouvel index structurel permettant d’améliorer le sto-
ckage et la récupération des données pour le traitement des requêtes SPARQL.

Le moteur d’interrogation proposé, possède trois sous-composants :

- Query Parser : reçoit les requêtes d’entrée des utilisateurs, extrait leurs BGPs pour les
envoyer par la suite à l’optimiseur de requête. Il crée, également, une liste de variables pour

42
l’étape du traitement des requêtes ;
- Query Optimizer : génère un plan d’exécution pour la requête. Les patrons de triplets sont
disposés dans un ordre, tel que le résultat de correspondance d’un patron sert d’entrée pour
le patron suivant dans le plan. Comme le résultat de chaque patron est vérifié pour sa validité
à chaque étape de traitement, le nombre de résultats intermédiaires est sensiblement réduit ;
- Query Processor : consiste à trouver les points de correspondance avec les variables de
la requête, à vérifier ces derniers et ensuite à les combiner pour retrouver l’ensemble de la
réponse pour toute la requête.

En 2009, Tzoganis et al. [Tzoganis et al., 2009] ont déployé une application orientée utili-
sateur pour l’interrogation des ontologies. L’utilisateur peut facilement charger une ontologie
existante et proposer des requêtes écrites en langage d’interrogation SPARQL-DL. Leur ap-
plication Web peut s’exécuter à partir de n’importe quel navigateur Web majeur. Elle a été
développée avec Google Web Toolkit (GWT).
Google Web Toolkit permet aux développeurs d’écrire une interface AJAX avec le langage
de programmation JAVA, puis de compiler ce code source JAVA en JavaScript. Il peut faci-
lement être combiné avec plusieurs outils de développement JAVA comme Eclipse. Ainsi, il
offre un environnement de développement facile à gérer qui facilite également de déboguer le
code JAVA.
AJAX est un ensemble de technologies existantes (e.g. HTML, CSS, JavaScript, XML, etc.)
qui viennent ensembles afin de construire des applications Web modernes.

La fonctionnalité de leur application devient disponible via son interface. Elle est très simple
et minimaliste. Elle se compose de deux parties principales, dont la 1ère prend l’entrée de
l’utilisateur (i.e. l’ontologie et la requête), ainsi que la 2ème (nommée « résultats ») affiche la
réponse à l’utilisateur.
Le moteur d’interrogation SPARQL-DL de Pellet (le raisonneur utilisé) effectue le pré-
traitement de la requête. Cela inclut la suppression des atomes redondants et l’élimination
des atomes « sameAs » avec les b-nœuds : « bnodes » (ils s’agissent des nœuds vides ou de
ressources anonymes ou bien ils peuvent être des nœuds dans un graphe RDF qui ne sont ni
identifiés par un URI ni ils sont des littéraux). L’étape du pré-traitement suivante consiste
à supprimer les atomes triviaux e.g. SubClassOf (C, C) et SubClassOf (C, owl :Thing). La
dernière étape du pré-traitement consiste à diviser la requête en composants connectés afin
d’éviter le calcul croisé de leurs résultats.

Dans la même année, Hartig et al. ont proposé une approche qui, durant l’exécution d’une
requête, permet de découvrir les sources de données qui peuvent être pertinentes pour ré-
pondre à cette requête [Hartig et al., 2009]. Parce que quelques requêtes ne peuvent pas être
répondues depuis un seul ensemble de données, le moteur d’interrogation exécute chaque
requête à partir d’un ensemble croissant de données pertinentes retrouvées du Web.
Cette approche a plusieurs limitations :
- Besoin des URIs initiaux dans les requêtes afin de pouvoir traverser les liens ;
- Découverte de liens infinis ;
- Dé-référencement d’URI qui est une tâche longue ;

43
- Les serveurs du Linked Data mettent des restrictions aux clients, comme ne servant qu’un
nombre limité de requêtes par seconde.

Une méthode qui a été déployée par Huang et al. en 2011 dans [Huang et al., 2011], four-
nit un système de BD-RDF en cluster, parce que vue la quantité de données RDF est en
augmentation permanente, il n’est plus possible de stocker ni d’accéder à toutes ces données
sur une seule machine tout en assurant des performances raisonnables. Par conséquent, au
lieu d’affecter aléatoirement les triplets aux partitions, ils ont utilisé un algorithme de parti-
tionnement de graphes qui permet aux triplets (qui sont proches dans le graphe RDF ) d’être
stockés sur la même partition, pour enfin paralléliser l’accès à ces machines au moment de
l’interrogation. Ils ont introduit une méthode automatique permettant la décomposition des
requêtes à des morceaux qui peuvent être exécutés indépendamment sans aucune communi-
cation réseau.

Kollia et al., en 2011, ont pensé à développer un nouvel algorithme [Kollia et al., 2011]
qui permet de :
- Répondre aux requêtes SPARQL sous OWL 2 (désormais SPARQL-OWL) ;
- Décrire une implémentation basée sur le raisonnement HermiT ;
- Utiliser cette implémentation pour étudier une gamme de techniques d’optimisation, amé-
liorant les performances de réponse aux requêtes SPARQL-OWL.

Ainsi, comme SPARQL est un langage d’interrogation RDF basé sur des triplets, ils ont
montré brièvement comment les objets OWL peuvent être mappés en des triplets RDF. La
figure 2.7 montre une représentation RDF des axiomes (1), (3) et (4) dans la syntaxe de
Turtle.
Les axiomes OWL qui utilisent uniquement l’expressivité du schéma RDF, par exemple les
restrictions de domaine et d’image, aboutissent généralement à une traduction directe. Par
exemple, l’axiome (3) est mappé au triplet (3’).
Les expressions complexes de classe, telles que la super-classe dans l’axiome (1), nécessitent
généralement des nœuds vides auxiliaires, e.g. le nœud vide auxiliaire - : x (axiome (1’)),
pour l’expression de la super-classe, qui est ensuite utilisé comme sujet des triplets suivants.
Dans la traduction de l’axiome (4), ils ont utilisé le constructeur de nœud vide de Turtle [ ]
et ( ) comme raccourci pour les listes dans RDF (axiome (4’)).

44
 Figure 2.7 – Mapping des objets OWL en des triplets RDF (Kollia et al. (2011))

Ils ont utilisé la bibliothèque ARQ3 du Jena Semantic Web Toolkit pour analyser la requête et
pour les opérations d’algèbre SPARQL. Le BGP (basic graph pattern) est analysé et mappé
dans des modèles d’axiomes en utilisant l’extension OWL API. Les modèles d’axiomes résul-
tants sont ensuite transmis à un optimiseur de requête. Ce dernier applique la réécriture du
modèle d’axiome, puis recherche un bon plan d’exécution pour la requête, en se basant sur
les statistiques fournies par le raisonneur (figure 2.8).

Figure 2.8 – Les principales phases de traitement de requêtes (Kollia et al. (2011))

En effet, le défi principal est de développer des interfaces permettant d’exploiter l’expres-
sivité du modèle de données sous-jacent et du langage d’interrogation, tout en diminuant leur
complexité. Ainsi, il est indispensable d’avoir une approche pour la réponse aux questions

45
permettant aux utilisateurs d’exprimer, d’une manière arbitraire, leurs besoins en information
complexe en langage naturel sans les obliger à connaître le schéma sous-jacent, le vocabulaire
ou le langage d’interrogation.

Plusieurs systèmes de réponse aux questions pour les données RDF ont été proposés, e.g.
Aqualog, Power-Aqua, NLP-Reduce et FREyA. La plupart de ces systèmes permettent de
transformer la requête du langage naturel en une représentation à base de triplets. Ensuite,
avec l’application des métriques de similarité et des heuristiques de recherche, ils vont retrou-
ver les correspondances des sous-graphes à partir des référentiels RDF. Cependant, parfois la
structure sémantique originale de la question ne peut pas être fidèlement capturée en utilisant
des triplets.

C’est pour cette raison que Unger et al. (2012) dans [Unger et al., 2012], ont proposé une
nouvelle approche, qui permet de générer tous les modèles de requête SPARQL. Cela se fait
en capturant la structure sémantique du besoin en information de l’utilisateur ainsi qu’en
ne laissant ouverts que des emplacements spécifiques pour les ressources, les classes et les
propriétés. Ces emplacements doivent être déterminés par rapport à l’ensemble de données
sous-jacent (i.e. doivent être traités avec des URIs), en utilisant l’extension WordNet (figure
2.9).

Figure 2.9 – Le modèle basé sur la génération de requêtes SPARQL (Unger et al. (2012))

Ils ont essayé de générer tous les modèles possibles. Par la suite, ils ont sélectionné celui
qui capture le mieux la structure des données considérées. Pour ce faire, ils ont adopté le

46
mécanisme de l’analyse (parsing) et de la construction du sens du système de réponse aux
questions Pythia, car il s’adapte tout simplement avec leurs buts. Le processus du parsing
de Pythia repose sur un lexique qui spécifie, pour chaque expression, une représentation syn-
taxique et une sémantique.

Une fois une liste de requêtes SPARQL est disponible, ils doivent décider laquelle doit être
exécutée par rapport au Triple Store (TP). Cependant, cela ne garantit pas que la combi-
naison des patrons de triplets, dans une requête, est significative et mène à un résultat non
vide. Par conséquent, il est nécessaire d’exécuter et de tester les requêtes avant de retourner
un résultat à l’utilisateur. Leur système retourne la requête ayant le score le plus élevé avec
un résultat non vide.

Le principal obstacle que l’utilisateur rencontre, est quand il essaie de formuler une re-
quête, pourtant il n’a aucune information sur la structure sous-jacente et le vocabulaire de
données. Dans ce cadre, une méthode a été présentée dans le travail de Campinas et al. en
2012 [Campinas et al., 2012], basée sur un résumé du graphe de données et assiste l’utilisa-
teur pendant la formulation de sa requête, par la recommandation des éléments de requêtes
structurels possibles, tout en se basant sur l’état actuel de la requête. Ce modèle assure la
synthèse du graphe et contient trois couches :
- Une couche d’entité et une autre d’ensemble de données : elles représentent les ensembles
de données, les entités et leurs relations ;
- Une couche de collection de nœuds : représente les collections de nœuds et leurs relations.

Ils ont développé un éditeur SPARQL, qui est une application tirant partie du résumé du
graphe de données afin d’aider l’utilisateur dans la formulation efficace de requêtes SPARQL,
même sans une connaissance préalable de la structure et le vocabulaire des sources de données.
Cet éditeur supporte quatre types de recommandations : la classe, le prédicat, les relations
entre les variables, et les graphes nommées.

Pendant la formulation de la requête, cet éditeur fournit à l’utilisateur un parmi ces différents
types de recommandations en se basant sur l’état de la requête modifiée. L’état de la requête
modifiée est composé d’un patron graphique incomplet, ainsi que de la position du curseur.
Ils ont également développé un arbre de syntaxe abstrait (Abstract Syntax Tree : AST), qui
est une structure de données utilisée par le système, afin de traduire les besoins courants de
l’utilisateur en des recommandations possibles.

Makris et al. (2012) ont déployé SPARQL-RW [Makris et al., 2012], qui est un système
supportant l’interrogation transparente des ensembles de données, gérés par différentes or-
ganisations. En utilisant cette infrastructure, les utilisateurs peuvent exprimer des requêtes
SPARQL en se basant sur leur propre schéma RDF/S et accéder automatiquement aux don-
nées grâce à une fédération de ressources RDF dans le Web. Formellement, étant donné une
ontologie source (Os ), une autre cible (Or ), et un ensemble de correspondances M entre (Os )
et (Or ) ; SPARQL-RW, prend en entrée une requête SPARQL exprimée sur (Os ) et la réécrit
en une autre requête correspondante à elle sémantiquement exprimée sur (Or ), tout en res-

47
pectant M.

Le système est composé des éléments de base :

- L’analyseur et le composeur de la requête : analysent la requête d’entrée et composent une
autre réécrite ;
- L’analyseur de correspondance (mapping parser) : analyse les correspondances prédéfinies ;
- Élément qui détermine le type de correspondances : identifie le type de chaque correspon-
dance afin d’être exploitée par le processus de la réécriture ;
- Logiciel de réécriture : réécrit le patron graphique de la requête SPARQL d’entrée en se
basant sur les correspondances prédéfinies.

Yahya et al. (2012) [Yahya et al., 2012] ont développé DEANNA (DEep Answers for
maNy Natural Asked questions) qui est une méthode basée sur un programme linéaire entier
(ILP ), afin de résoudre plusieurs tâches de désambiguïsation. Cette méthode assure la seg-
mentation des questions du langage naturel en éléments, le mapping de ces éléments en des
entités, classes et relations sémantiques. Enfin, la construction des patrons de triplet (TP)
SPARQL.
L’ILP utilise la richesse des bases de connaissances larges comme Yago2, qui possède des
informations non seulement sur les entités et les relations, mais également sur les noms de
surface et les patrons textuels par lesquels les sources Web se réfèrent à eux (e.g. Yago2 sait
que « Casablanca » peut se référer à une ville ou à un film, et « joué dans » est un patron
qui peut désigner une relation).

Les travaux existants de question/réponse RDF, prennent en considération deux ap-

proches : la compréhension de la question (afin de traiter la désambiguïsation des phrases du
langage naturel) et l’évaluation de la requête.
La difficulté dans la tâche de question/réponse en RDF, est dans l’ambiguïté du langage
naturel. Afin de traduire N en SPARQL, chaque terme doit être transformé en un élément
sémantique (i.e. une entité, une classe ou un prédicat) dans le graphe RDF (G). La désa-
mbiguïsation d’un seul terme dans N, peut influencer le mapping du reste des termes. Les
méthodes existantes de désambiguïsation considèrent que la sémantique de la question, ce
qui engendre alors un coût élevé dans l’étape de la compréhension de la requête.

Dans ce contexte, Zou et al. (2014) ont proposé de traiter la désambiguïsation, plutôt
au niveau de l’étape d’évaluation de la requête (i.e. 2ème étape) au lieu de la 1ère étape
[Zou et al., 2014]. Cela permet d’éviter le processus de désambiguïsation coûteux de l’étape
de la compréhension de la question, ainsi d’accélérer la totalité de la performance (i.e. la
précision et le temps de réponse). Plus précisément, ils ont permis que les termes (dans N )
puissent correspondre à plusieurs éléments sémantiques (i.e. sujets, objets et prédicats) dans
le graphe RDF G, au niveau de l’étape de la compréhension de la question.

Ils ont proposé un graphe de requête sémantique Qs (représente l’intention de la requête

utilisateur), afin de décrire la sémantique de la question N. Il faut tout d’abord extraire les
relations sémantiques impliquées de la question N. Les relations sémantiques sont la base sur

48
lesquelles ils ont construit le graphe de requête sémantique Qs .
Intuitivement, une correspondance d’une question N à partir d’un graphe RDF, G, est une
correspondance du sous-graphe sémantique Qs avec G.

Plusieurs recherches et outils commerciaux offrent des gestionnaires de données RDF cen-
tralisés, tandis que l’accroissement des données exige des stockages distribués et de l’indexa-
tion. Dans ce cadre, Papailiou et al. (2014) ont développé H2RDF+ [Papailiou et al., 2014],
qui est un système de gestion de données RDF (s’applique sur une infrastructure Cloud),
open source, assurant une forte efficacité. Il utilise HBase pour l’indexation des triplets. Ils ont
permis aux utilisateurs de choisir un ensemble de données à charger et à indexer. Également,
ils ont permis aux utilisateurs d’écrire leur propre requête SPARQL ou bien de sélectionner
une prédéfinie.

En 2015, Hammoud et al., ont présenté DREAM (Distributed RDF Engine with Adaptive
Query Planner and Minimal Communication) qui est un moteur RDF distribué avec un pla-
nificateur de requêtes adaptatif et une communication minimale. Il conserve les avantages des
systèmes RDF centralisés et distribués, et évite leurs inconvénients [Hammoud et al., 2015].
DREAM stocke un ensemble de données intacte sur chaque machine du cluster, et utilise un
planificateur de requêtes qui partitionne efficacement n’importe quelle requête SPARQL. En
effet, le planificateur de requêtes transforme Q en un graphe G. Il décompose G en plusieurs
ensembles de sous-graphes, et mappe chaque ensemble sur une machine séparée. Ensuite,
toutes les machines traitent leurs ensembles de sous-graphes en parallèle et se coordonnent
les unes avec les autres pour produire le résultat final de la requête.

DREAM sélectionne, de manière adaptative, différents nombres de machines pour différentes

requêtes SPARQL (en fonction de leurs complexités).

Allocca et al. (2016) ont développé un outil de recommandation de requête SPARQL, ap-
pelé SQUIRE [Allocca et al., 2016] qui, sur la base d’un ensemble de critères permettant de
mesurer la similarité entre la requête initiale et les recommandations, démontre la faisabilité
du processus de reformulation des requêtes sous-jacentes. SQUIRE classe les requêtes recom-
mandées et offre un support précieux pour les recommandations de requêtes sur un ensemble
de données RDF cible, inconnu et non mappé. Alors, non seulement il aide l’utilisateur à
apprendre le modèle de données et le contenu d’un ensemble de données RDF, mais aussi il
n’exige pas de l’utilisateur une connaissance intrinsèque des données.
Étant donné une requête SPARQL Qo , qui est satisfaisante avec un ensemble de données
RDF source (Ds ), SQUIRE fournit des recommandations de requête en reformulant auto-
matiquement Qo en d’autres Qr qui sont satisfaisantes avec un ensemble de données RDF
cible (Dt ).

SQUIRE permet aux utilisateurs de se référer à un ensemble de données RDF source, écrire
la requête Q, et spécifier l’ensemble de données RDF cible. Une fois l’utilisateur clique sur le
bouton « Recommend », SQUIRE retourne une liste de requêtes recommandées, classées de
haut en bas. Ces dernières, non seulement sont exprimées en termes de l’ensemble de données

49
cible, mais sont également garanties être satisfaisantes (i.e. l’ensemble de résultats n’est pas
vide).

Pour résumer, SQUIRE vise à recommander des requêtes dont les reformulations :
- Reflètent autant que possible la même signification, la même structure, le même type de
résultats et la même taille de résultat que la requête initiale et ;
- Ne nécessitent pas de faire la correspondance entre les deux ensembles de données.

La recherche facettée est devenue une approche de recherche exploratoire dans de nom-
breuses applications en ligne. Elle a été dernièrement proposée comme un paradigme appro-
prié pour l’interrogation des données RDF.
Pour cette raison, Arenas et al.(2016) ont proposé SemFacet qui est un cadre théorique
rigoureux pour la recherche facettée dans le contexte des graphes de connaissances basés sur
RDF [Arenas et al., 2016]. Ils ont développé une interface de requête simple et puissante pour
les non-experts. Cette interface permet la navigation à travers les collections inter-connectées
des entités, auxquelles ils ont défini une ontologie comme un ensemble fini de règles et de
faits et ils ont capturé les facettes qui sont pertinentes pour cette ontologie. Ils ont formalisé
leurs notions de « interface facettée » et « requête facettée », dont les requêtes à facettes sont
décrites par des « termes » de la logique du premier ordre et par des fragments du langage
de requête SPARQL. Cette requête est également guidée par les valeurs sélectionnées dans
l’interface.

Les méthodes existantes d’interrogation exigent, non seulement que l’utilisateur ait une
connaissance approfondie sur le schéma du graphe RDF, mais aussi se concentrent sur la
similarité structurelle du graphe et ne considèrent pas la similarité sémantique. Cependant,
nous pouvons trouver deux patrons de graphe (BGP ) qui possèdent une large différence
structurelle, mais qui ont une signification sémantique identique. C’est dans ce cadre que
Zheng et al. (2016) étaient les premiers à proposer une nouvelle mesure de similarité appe-
lée la distance d’édition du graphe sémantique. Cette mesure permet de mesurer la
similarité entre les graphes RDF (réellement entre le graphe G et la requête Q pour en-
fin renvoyer les "top-k" sous-graphes de G comme des candidats à Q). Ils ont également
conçu un nouvel index « résumé sémantique du graphe » permettant de résumer le graphe
de connaissances afin de réduire l’espace de recherche, ce qui améliore les performances de
l’interrogation [Zheng et al., 2016].

2.4.1 Quelques approches existantes pour l’interrogation par mots-

clés
Wang et al., en 2008 [Wang et al., 2008], ont implémenté une interface pour les mots-clés,
appelée Q2Semantic. Ils ont considéré des termes extraits de Wikipédia pour enrichir les
littéraux décrits dans les données RDF d’origine. De cette manière, les utilisateurs n’ont
pas besoin d’utiliser des mots-clés qui correspondent exactement aux données RDF. Lorsque
le premier mot-clé soit entré, Q2Semantic génère automatiquement une liste d’expressions
contenant ces mots-clés, parmi lesquels l’utilisateur peut choisir. Q2Semantic prend en charge

50
la traduction des mots-clés utilisateurs en des requêtes formelles.

Ils ont également adopté plusieurs mécanismes pour le classement des requêtes, car le pro-
cessus de construction de la requête peut aboutir à de nombreuses requêtes, i.e. les inter-
prétations possibles des mots-clés. Alors, un schéma de classement est bien nécessaire pour
envoyer les requêtes qui correspondent le plus à la signification voulue par l’utilisateur. Ce
classement prend en compte de nombreux facteurs pertinents, tels que la longueur de la re-
quête, la pertinence des éléments des ontologies.

Ils ont proposé un algorithme d’exploration et une nouvelle structure de données graphique
appelée RACK, qui ne représente qu’un résumé de l’ontologie ou des données RDF d’origine.
Cela réduit l’espace de données pertinent pour l’exploration.

Les résultats expérimentaux montrent de bonnes performances sur de nombreux ensembles

de données de différentes tailles. Cependant, ce travail supporte que les mots-clés qui corres-
pondent aux littéraux et aux concepts contenus dans les données RDF. Il ne prend pas en
charge les mots-clés sous la forme de relations et d’attributs.

La recherche par mot-clé offre l’avantage de la facilité d’utilisation, mais présente des défis
en raison de leur nature souvent laconique et ambigüe. Dans ce cas, chaque mot-clé doit être
interprété, et la requête entière doit être mappée à un ensemble d’expressions conditionnelles,
i.e. clause WHERE et clause RETURN. Cependant, il n’est pas toujours facile de trouver un
mappage unique. Alors, le problème devient celui d’identifier les K interprétations souhaitées
par l’utilisateur.

C’est dans ce cadre que Anyanwu et al., en 2011, ont abordé le problème de la génération
d’interprétations de requêtes (mots-clés) sur les BD-RDF, en utilisant des informations pro-
venant de l’historique des requêtes de l’utilisateur [Fu and Anyanwu, 2011]. Les utilisateurs
posent, souvent, une série de questions connexes, en particulier dans des scénarios explora-
toires. Dans ces scénarios, les informations sur les requêtes précédentes peuvent être utilisées
pour influencer l’interprétation d’une requête plus récente.
Ils ont fait face à deux principaux défis :
- Capturer et représenter efficacement l’historique des requêtes ;
- Exploiter efficacement l’historique des requêtes pendant l’interprétation de cette dernière.

Ils ont proposé et mis en œuvre :

- Un modèle de graphe de synthèse pondéré dynamique, qui est utilisé pour capturer, de
façon concise, les caractéristiques essentielles de l’historique des requêtes d’un utilisateur.
- Une fonction de pondération dynamique qui assigne des pondérations aux éléments du
graphe récapitulatif de manière à capturer leur pertinence par rapport au contexte d’inter-
rogation actuel.
→ Il ont finalement présenté une évaluation complète de leur approche en utilisant un sous-
ensemble de DBpedia.

51
 En 2011, Elbassuoni et al., ont proposé un modèle d’interrogation utilisant des requêtes par
mot-clé sur les graphes RDF [Elbassuoni and Blanco, 2011]. Ce modèle récupère un ensemble
de sous-graphes correspondants aux mots-clés de la requête, ainsi qu’il les classe en se basant
sur le modèle du langage statistique (LMs). Leur base de connaissances est constituée d’un
ensemble de triplets S-P-O. Pour pouvoir traiter les requêtes par mot-clé, ils ont construit
un document virtuel pour chaque triplet ti , qu’ils l’ont appelé Di .
Di contient un ensemble de mots-clés qui sont extraits du sujet et de l’objet des triplets, et
des mots-clés représentatifs pour les prédicats.

Ils ont stocké tous les termes du document Di dans un index inversé. Alors, étant donnée
une requête par mot-clé, ils ont utilisé cet index inversé pour récupérer, pour chaque mot-clé
d’une requête, une liste de triplets correspondants. Ils ont rejoint ensuite les triplets à partir
des listes différentes en fonction de leurs sujets et objets pour récupérer des sous-graphes
avec un ou plusieurs triplets.
Afin d’éviter de récupérer des sous-graphes arbitrairement longs, ils ont limité les sous-graphes
récupérés pour avoir les deux propriétés suivantes :
- Les sous-graphes doivent être uniques et maximaux, i.e. chaque sous-graphe récupéré ne
doit pas être un sous-ensemble de tout autre sous-graphe récupéré ;
- Les sous-graphes doivent contenir des triplets correspondants à différents ensembles de
mots-clés. Autrement dit, aucun triplet, dans le même sous-graphe, ne correspond exacte-
ment au même ensemble de mots-clés. Si deux triplets correspondent au même ensemble de
mots-clés, alors ils font partie de deux différents résultats possibles de la requête utilisateur,
et doivent être considérés comme des parties de deux sous-graphes distincts.

Selon Shekarpour et al (2015) [Shekarpour et al., 2015], le développement de systèmes de

recherche par mot-clé est difficile pour trois raisons :
- Les ressources proviennent de différents ensembles de données ;
- Différents ensembles de données utilisent des schémas hétérogènes et chacun d’entre eux ne
peut contenir qu’une partie de la réponse pour une certaine requête utilisateur ;
- La création d’une requête formelle fédérée à partir de mots-clés sur différents ensembles
de données, nécessitent l’exploitation de liens entre différents ensembles de données sur les
niveaux de schéma et d’instance.

C’est dans ce cadre qu’ils ont présenté SINA. Il est un système de recherche par mot-clé (ou
requête en LN) fournis par l’utilisateur, et traduits en requête SPARQL conjonctives, qui sont
exécutées sur un ensemble de sources de données inter-connectées. SINA utilise un modèle de
Markov caché pour déterminer les ressources les plus appropriées pour une requête, à partir
de différents ensembles de données.
SINA est capable également de construire des requêtes fédérées en exploitant les liens entre
les ressources.
Ce système a été évalué sur trois ensembles de données différents. Il a pu répondre exacte-
ment à 25 requêtes du QALD-1 (i.e. Question Answering over Linked Data). De même, ils
ont étudié l’exécution de Sina dans ses implémentations mono-cœurs et parallèles.

52
 La plupart des approches disponibles, exploitent le parcours du graphe en temps réel afin
d’identifier les sous-graphes appropriés. Certaines d’entre elles fournissent des résultats ap-
proximatifs parce que le parcours des graphes RDF avec des millions ou des milliards de
données est très coûteux et prend beaucoup du temps. Par conséquent, il est nécessaire de
fournir des méthodes pouvant réduire la traversée du graphe, dans le temps de génération de
requête.

Dudhani et al. (2016) [Rashmi Dudhani, 2016] ont proposé une technique de « segmentation
profonde » pour l’interrogation par mots-clés, traitée sur des bases de données RDF. Cette
approche réalise un élagage agressif des interprétations non pertinentes à partir de l’espace
des interprétations considéré.
Ils ont conçu les premiers algorithmes efficaces permettant d’énumérer toutes les réponses
dans l’ordre, afin de calculer les "top-k" réponses (selon certains critères de classement), où
chaque réponse est une sous-structure du graphe contenant tous les mots-clés saisis.
Ils ont présenté également un schéma d’indexation pour RDF qui décrit les caractéristiques
structurelles du graphe, ses chemins et les informations sur l’accessibilité des nœuds, afin
d’accélérer la récupération des sous-structures représentant les résultats de la requête. En
outre, l’index permet de faciliter les opérations de maintenance au cas où l’ensemble de
données évolue.

2.5 Discussion et Synthèse

La considération de RDF comme étant un modèle de base de données à part entière, la
conception ainsi que les primitives d’un langage d’interrogation, sont un sujet moins déve-
loppé. Il constitue un parmi les besoins si nous voulons profiter de l’intégralité des potentia-
lités du modèle de données RDF (i.e. l’optimisation de requêtes, la réécriture de requêtes,
les vues, les mises à jour).

Dans ce contexte, certains travaux précédents de stockage, de gestion et d’interrogation

de graphes RDF volumineux, se limitaient sur le processus de question/réponses à partir des
données RDF inter-connectées sur le Web. Ils fournissent des interfaces, avec lesquelles l’uti-
lisateur n’a qu’à saisir ses mots-clés en langage naturel décrivant son besoin en informations.
La plupart de ces systèmes permettent de transformer la question du langage naturel en une
représentation à base de triplets. Ensuite, avec l’application des métriques de similarité et
des heuristiques de recherche, ils vont retrouver les correspondances des sous-graphes à partir
des graphes RDF.

D’autres travaux ont laissé la tâche d’écriture des requêtes SPARQL à l’utilisateur (même
pour les non-experts), mais en lui fournissant un appui et une assistance au moment de
l’écriture de ces dernières. Parmi les autres méthodes développées, nous trouvons celles qui
permettent d’optimiser les requêtes SPARQL (e.g. en éliminant les triplets redondants, en
réorganisant les clauses de la requête, en proposant un résumé du graphe RDF, etc).

53
 D’autres approches se sont concentrées sur le stockage des données RDF dans des BD-
RDF, ou des Triples Stores, et ensuite ils ont fourni des méthodes et des algorithmes permet-
tant d’assurer une interrogation rapide et efficace de ces données, en utilisant des requêtes
SPARQL. Entre autres, la plupart des méthodes existantes s’appuient sur des applications
Web (interface depuis un point d’accès : endpoint : permet d’effectuer des requêtes SPARQL
sur une base de connaissances. Une manière de transfert des requêtes SPARQL des clients
à un service Web capable de les exécuter et de renvoyer les résultats via HTTP). Alors, ils
n’assurent pas une gestion persistante des données RDF, permettant de stocker et d’accéder
aux données graphiques sur un support persistant.

Les solutions pour parcourir un graphe RDF sur les supports persistants, ne sont pas cou-
rantes car le coût des accès aléatoires à un support persistant est problématique. C’est un
grand défi pour les BD graphiques, où l’utilisateur s’attend à la persistance des données et à
la prise en charge des opérations de parcours rapides.

Certaines méthodes existantes, non seulement elles exigent que l’utilisateur ait une connais-
sance approfondie sur le schéma du graphe RDF, mais aussi, l’utilisateur ne peut interroger
qu’une seule ontologie, à la fois, stockée dans une BD-RDF.

D’autres approches se sont concentrées sur l’indexation des données RDF, et comme le
stockage et l’interrogation des données fortement indexées peuvent être efficaces et faisables
pour des requêtes simples, ils sont, par contre, pas conseillés et difficiles à manipuler en exé-
cutant des requêtes compliquées.

En outre, le problème de passage à l’échelle est parmi les causes des limites de perfor-
mance des systèmes réalisant les travaux d’interrogation. En effet, les solutions offertes par
les Triples Stores dépassent leur capacité de stockage. Ceci donne l’opportunité d’améliorer
les capacités des algorithmes d’interrogation et de recherche.

Dans ce contexte, et afin de simplifier le processus d’interrogation, une solution envisa-

geable est la génération automatique de requêtes SPARQL à partir de graphes RDF, basée
sur des mots-clés fournis par l’utilisateur.

2.6 Conclusion
RDF et RDFS utilisent, pour décrire des connaissances, une structure particulière (i.e.
graphe), dans laquelle les nœuds sont des concepts représentés par des propriétés et les arcs
sont des prédicats décrivant les relations entre ces concepts. Ils permettent également de
formuler des règles de raisonnement qui peuvent être employées afin d’inférer de nouvelles
connaissances. Dans ce chapitre nous avons expliqué le stockage et l’interrogation des connais-
sances à partir des BD-RDF. Certaines sont dites non-natives (i.e. s’appuient sur les SGBDR)
alors que d’autres sont natives et elles utilisent la structure en graphe pour la représentation
des connaissances. Certaines BD-RDF se chargent, dans leur système, d’un moteur de raison-

54
nement qui est capable de fonctionner sous deux modes différents, la saturation des données
et la reformulation des requêtes. Les requêtes exprimées sur ces connaissances sont représen-
tées grâce aux langages d’interrogation adaptés, dont le plus utilisé est SPARQL. Nous avons
effectué une étude d’art sur quelques méthodes de stockage des données RDF existantes,
ainsi que sur les différentes approches qui visent à générer, d’une manière automatique ou
semi-automatique, des requêtes formelles à partir de mots-clés ou de phrases exprimés par
l’utilisateur en langage naturel.

55
Chapitre 3

Proposition d’une nouvelle approche de

génération de requêtes SPARQL à partir
de graphes RDF

3.1 Introduction
La récupération des données de la gigantesque masse disponible, devient de plus en plus
difficile dans le cadre du Web sémantique, ainsi que l’accès aux données représente, de plus
en plus, un réel besoin pour les utilisateurs. Comme il est très difficile pour un utilisateur
final de surmonter et maîtriser la complexité des langages et des schémas des connaissances,
la mise à disposition des interfaces des moteurs SPARQL, est devenue une nécessité : afin
de pouvoir former une requête valide sur les bases de connaissances du Web sémantique,
l’utilisateur doit avoir une idée sur le langage SPARQL, les ontologies employées, ainsi que,
la forme ou la structure des graphes RDF considérés.
Pour simplifier le processus d’interrogation, une solution envisageable est la génération auto-
matique de requêtes SPARQL basée sur les mots-clés fournis par l’utilisateur. Notre travail
se place dans ce contexte de recherche, i.e. comment pouvons-nous interpréter et élucider
une requête en langage naturel et la traduire en une requête SPARQL ?

3.2 Problématique et motivations dans le contexte d’in-

terrogation des graphes RDF
Dans la littérature, la pertinence et l’efficacité des interfaces en langage naturel ont été lar-
gement étudiés, sans que l’on atteigne une conclusion finale. Quelques travaux [Pradel et al., 2013],
évaluent l’utilisation des interfaces qui permettent d’assurer, aux utilisateurs, un accès aux
connaissances en utilisant la langage naturel.

De ce fait, ils déterminent trois problèmes majeurs dans ces interfaces :

- Les ambiguïtés du langage naturel sont le principal problème, et qui est dû à la variabilité
linguistique, i.e. les diverses façons d’exprimer une même requête ;

56
- La barrière adaptative et qui fait que les interfaces assurant de bonnes performances de
recherche, ne sont malheureusement pas très portables : la plupart du temps, ces systèmes
sont dépendants du domaine et par conséquent, difficiles à adapter à d’autres contextes ;
- Le problème de l’habitabilité : lorsqu’on donne trop de liberté à l’utilisateur pour exprimer
ses requêtes, il peut les exprimer au-delà des capacités du système. Par conséquent, une inter-
face doit exiger des structures à l’utilisateur pour l’aider pendant le processus de formulation
de sa requête ;

Un autre problème qui nous intéresse est celui du passage à l’échelle des méthodes de stockage
et d’interrogation des données RDF.

3.3 La base de données graphique Neo4j

La version stable actuelle de Neo4j est 3.2.5 (Septembre 2017), et elle est sous licence
GPLv3. Elle est écrite en java et son objectif principal est de stocker les données d’une
manière consistante, permanente et efficace. Elle fournit des interfaces permettant aux ap-
plications et aux utilisateurs d’accéder, d’évaluer, de modifier et de gérer des ensembles de
données RDF. Les requêtes peuvent être envoyées via le protocole HTTP / REST ou direc-
tement en Java. Neo4j est une BD "intégrable" (i.e. embeddable) car elle peut être ajoutée
à une application et utilisée comme toute autre bibliothèque.

Avantages du mode intégré :

⊕ Faible latence : parce que l’application communique directement avec la BD, il n’y a pas
de surcharge réseau. Afin de réduire la latence, Neo4j fournit deux niveaux de mise en cache :

Système de fichiers : est une zone de mémoire libre, ou RAM, qui n’a été allouée à aucun
processus. Lorsqu’un processus demande un fichier ou une partie d’un fichier, ce fichier est
chargé en mémoire dans la cache dy système de fichiers.
Cache d’objet : parce que Neo4j s’exécute dans une JVM, il gère les nœuds et les rela-
tions en tant que objets Java en mémoire.

⊕ Choix des APIs : nous avons accès à toute la gamme d’API s pour créer et interroger des
données ;
⊕ Transactions explicites : grâce au Core API (section 3.3.1.2.b, page 60), nous pouvons
contrôler le cycle de vie transactionnel en exécutant une séquence de commandes arbitraire-
ment complexes sur la BD dans le contexte d’une transaction unique, etc.

⇔ Lors de l’exécution en mode intégré, nous devons garder à l’esprit ce qui suit :
- JVM (Java Virtuel machine) : uniquement Neo4j est une BD JVM. Beaucoup de ses APIs
sont, alors, accessibles uniquement à partir d’un langage basé sur JVM. Puisque Neo4j est
écrit en Java, et comme toutes autres applications écrites en Java, nous devons configurer la
JVM pour avoir des performances optimales ;
- Le comportement du GC (Garbage Collector) : lors de l’exécution en mode intégré, Neo4j

57
est soumis au comportement de récupération de place (GC) de l’application hôte. Les longues
pauses GC peuvent affecter le temps d’interrogation ;
∗ Cycle de vie de la BD : l’application est responsable du contrôle du cycle de vie de la BD,
ce qui inclut le démarrage et la fermeture en toute sécurité.

• Neo4j embedded peut être mis en cluster pour une haute disponibilité ainsi
qu’une mise à l’échelle horizontale.

3.3.1 Architecture de Neo4j

Figure 3.1 – Arichtecture de Neo4j

Comme le montre la figure 3.1, Neo4j stocke les données graphiques dans un certain
nombre de différents fichiers de stockage. Chaque fichier de stockage contient les données
d’une partie spécifique d’un graphe. La répartition des responsabilités de stockage facilite les
parcours performants de graphes. Cela signifie que la vue de l’utilisateur sur le graphe et les
enregistrements sur le disque, sont structurellement dissemblables.

3.3.1.1 Nœuds et relations

Neo4j utilise le modèle de données de graphe de propriété. Ce modèle garantit que les arcs
soient dirigés, les sommets et les arcs soient étiquetés, les sommets et les arcs possèdent des
données de paires clé/valeurs associés (i.e. des propriétés) où la clé est une chaîne, ainsi que
les valeurs de propriété peuvent être une primitive Java ou un tableau (e.g. les valeurs String,
int et int[] sont valides). Il peut y avoir plusieurs arêtes entre deux sommets. Dans Neo4j,
les sommets attribués sont appelés "nœuds" et les arêtes attribuées dirigées sont appelées
"relations". les valeurs attribuées elles-mêmes sont nommées "propriétés". La combinaison

58
des nœuds, les relations entre eux et les propriétés, forment un espace de nœuds (i.e. un
réseau cohérent représentant les données du graphe (Neo Technology 2006 )).

Figure 3.2 – Un exemple d’un graphe Neo4j

La figure 3.2 montre les composants d’un graphe de propriété simple. Neo4j utilise, égale-
ment, ce modèle pour le stockage des données, dont tous les nœuds ont des identifiants (ID)
et toutes les relations sont dirigées et ont un type (e.g. records, have, etc).
La figure 3.3 décrit comment créer un petit graphe, sous Java, composé de deux nœuds
connectés avec une relation et quelques propriétés.

Figure 3.3 – Création d’un petit graphe Neo4j

3.3.1.2 APIs de Neo4j et le langage Cypher

Bien que le système de fichiers et les infrastructures de mise en cache soient fascinants,
les développeurs interagissent rarement directement avec eux. Cependant, ils manipulent une
BD graphique via un langage d’interrogation, qui peut être impératif ou déclaratif, à noter
le langage Cypher (propre à Neo4j ). Toutefois, d’autres APIs existent (figure 3.4). Toutes

59
les BD graphiques n’ont pas forcément le même nombre de couches, ni nécessairement les
couches qui se comportent et interagissent exactement de la même manière.

Figure 3.4 – Vue logique des APIs dans Neo4j

3.3.1.2.a API kernel

Au niveau le plus bas se trouve les gestionnaires d’événements de transactions de Kernel.
Ceux-ci permettent au code utilisateur d’écouter les transactions, et ensuite de réagir (ou
non) en fonction du contenu des données et de l’étape du cycle de vie de la transaction.

3.3.1.2.b Core API

Une API Java impérative qui expose les primitives de graphes de nœuds, de relations, de
propriétés et des étiquettes, à l’utilisateur. Pour l’écriture, le Core API fournit des fonction-
nalités de gestion de transactions afin d’assurer une persistance atomique, cohérente, isolée
et durable.

3.3.1.2.c Le traversal Framework

Une API Java déclarative. Elle permet à l’utilisateur de spécifier un ensemble de contraintes
qui limitent les parties du graphe que la traversée est autorisée à visiter. Nous pouvons spé-
cifier les types de relations à suivre et dans quelle direction (en spécifiant efficacement les
filtres de relation). Nous pouvons également indiquer si nous voulons que la traversée soit
effectuée en largeur ou en profondeur, etc.

3.3.1.2.d Cypher
Il est un langage d’interrogation déclaratif, inspiré de SQL et SPARQL. Il assure une
interrogation et une mise à jour efficaces du Triples Store. Neo4j prend en charge aussi le
langage d’interrogation impératif Gremlin (il était au départ le langage par défaut de Neo4j,
mais Neo Technology a décidé de créer Cypher pour faciliter la mise en main, la lecture et
l’écriture des requêtes).

60
Les requêtes Cypher suivent une certaine syntaxe, et les clauses les plus importantes sont :

- MATCH : retourne toutes les données ayant la forme du sous-graphe décrit ;

- CREATE : crée des nœuds ou des relations ;
- DELETE : supprime des nœuds, des relations et des propriétés ;
- DETACH DELETE : supprime un nœud et tous les arcs connectés à lui ;
- SET : modifie ou met à jour une pair clé/valeurs ;
- REMOVE : supprime une pair clé/valeurs ;
- WHERE : définit les propriétés d’un graphe et le résultat, fournit des critères pour filtrer
les résultats de la correspondance du patron graphique ;
- RETURN : définit les valeurs retournées ;
- START : spécifie un ou plusieurs points de départ (nœuds ou relations) dans le graphe ;
- UNION : fusionne les résultats de deux ou plusieurs requêtes ;
- ORDER BY : dans la commande MATCH pour ordonner les résultats renvoyés ;
- LIMIT et SKIP : pour limiter ou filtrer le nombre de lignes retournées.

En outre, Neo4j prend en charge des indexs en utilisant Apache Lucene. Un index porte sur
l’attribut d’un nœud et permet de parcourir aisément les nœuds d’un graphe afin d’appliquer
des requêtes efficaces avec le langage Cypher.

3.3.2 Avantages de Neo4j

Parmi les avantages de Neo4j, nous citons :
⊕ Neo4j fournit un modèle de données flexible, simple mais puissant, qui peut être facilement
modifié en fonction des applications et des industries ;
⊕ Neo4j est hautement disponible pour les applications en temps réel de grandes entreprises
avec des garanties transactionnelles ;
⊕ Avec Neo4j, nous pouvons facilement représenter des données connectées et semi-structurées ;
⊕ Elle fournit son propre langage d’interrogation Cypher ;
⊕ Neo4j n’exige pas de jointures complexes pour récupérer les données connectées, car il est
très facile de récupérer les détails d’un nœud ou d’une relation sans jointures ou index ;
⊕ Neo4j prend en charge les contraintes / règles ACID ;
⊕ Nous pouvons mettre à l’échelle la BD en augmentant le nombre de lectures / écritures et
le volume des informations, sans affecter la vitesse du traitement de requêtes et l’intégrité de
données ;
⊕ Neo4j prend également en charge la réplication de données pour assurer la sécurité et la
fiabilité de ces dernières.

3.4 Description de la nouvelle méthode d’interrogation

OntoNeo
Notre processus de question/réponse à des mots-clés utilisateurs à partir du graphe RDF
stocké dans Neo4j (dont ce graphe est déduit à partir de l’ontologie de départ), est décrit

61
dans l’algorithme 1. Il prend en entrée une ontologie ou plusieurs (section 3.5.2.3, page 87),
et retourne une réponse à une requête utilisateur écrite en langage naturel. Dans ce qui suit,
nous allons décrire chaque phase séparément.

1
2 Entrée : Une ontologie, O.
3 Sortie : Une réponse à une requête (mots-clés) utilisateur en LN, Q.
1: Analyse de l’ontologie O en des ensembles d’entités ;
2: Extraction des triplets RDF (S,P,O) à partir de ces ensembles d’entités ;
3: Chargement des triplets RDF dans Neo4j ;
4: Interrogation de la base de données graphique Neo4j ;
Algorithme 1 : Algorithme récapitulatif des différentes phases de notre processus

3.4.1 Phase 1 : Analyse (Parsing) de l’ontologie

Notre système admet en entrée l’ontologie du domaine qui englobe divers types d’infor-
mations : taxonomie de concepts de même type modélisés par la relation is-a, thésaurus de
concepts de différents types liés par les relations Object-Property et Data-Type-Property, etc.

- Il retourne comme sorties les éléments suivants :

. Les entités de l’ontologie : celles-là représentent la partie la plus importante ;
. Les types de ces entités, et qui peuvent être des classes, des instances, des propriétés d’objet
ou des propriétés de type de données.

Le parsing en détail :
• On parse les classes de(des) l’ontologie(s) d’entrée et on extrait pour chaque classe
ses annotations (ses labels, ses commentaires), ses sous-classes, ses classes équivalentes, et
disjointes ;
• On parse les propriétés d’objet/ de type de données de(s) l’ontologie(s) d’entrée et
on extrait pour chaque propriété ses annotations, ses sous-propriétés, ses super-propriétés,
ses domaines, ses images, ses propriétés inverses (seulement pour les propriétés d’objet),
équivalentes, disjointes, et son type (fonctionnelle, symétrique, etc) ;
• On parse les instances et on extrait pour chacune ses annotations, ses classes qui
l’instancient, ses "Same" et "Different" instances.

⇔ Pour le parsing, nous avons choisi d’utiliser OWL API qui est une API performante,
reconnue et professionnelle. Nous avons utilisé également le raisonneur Hermit, qui est un
raisonneur d’ontologies écrites en OWL, et dont son utilisation n’est pas obligatoire, car
OWL API a aussi un raisonneur par défaut. Hermit permet de déterminer si l’ontologie est
cohérente, identifier les relations de subsomption entre les classes, déduire des inférences, etc.

62
 Nous avons choisi d’effectuer le raisonnement pendant le parsing de l’ontologie, et donc
avant l’exécution des requêtes, en appliquant la technique de la saturation de données.

3.4.2 Phase 2 : Génération des triplets RDF

Dans cette phase se fait la création des triplets RDF (à partir de l’ensemble d’entités déjà
généré dans la première phase), afin de traduire la séquence précédente vers un ensemble de
triplets RDF sous la forme < Sujet, Prédicat, Objet >. Cela aboutit à deux types de triplets :

Triplets de type primitives OWL :

Pour les classes, figure 3.5 :

- Le sujet est une classe ;

- L’objet peut être une classe, une instance, un label, un commentaire ;
- Le prédicat existe de différents types : Sub-Class-Of, Equivalent-Class, Disjoint-Class,
Instance-Of, Has-Label, Has-Comment.

Les concepts sont organisés hiérarchiquement à travers la relation conceptuelle « Sub-

Class-Of » ou « is-a » d’héritage ou de spécialisation, utilisée pour construire une taxonomie
/ hiérarchie de concepts. D’autres relations prédéfinies telles que l’équivalence et la disjonc-
tion peuvent également lier les concepts pour véhiculer plus de sémantique.

Figure 3.5 – Triplets des classes

Pour les propriétés d’objet/de type de données (figure 3.6) :

63
 - Le sujet est une propriété ;
- L’objet est une propriété, un label ou un commentaire ;
- Le prédicat peut être de divers types : Type-Property, Sub-Property, Equivalent-Property,
Disjoint-Property, Inverse-Of, Has-Label, Has-Comment.

Il n’y a pas de propriétés inverses pour les propriétés de types de données.

Il existe en OWL deux types de propriétés : les propriétés d’objet et celles de types de
données.
Une propriété d’objet qui définit une relation entre deux individus d’une classe ou de plu-
sieurs classes, et aussi, une propriété de type de données qui est une relation entre un individu
d’une classe et une valeur ou une donnée. Les propriétés d’objet et de type de données, dé-
finies par l’utilisateur, sont toutes (respectivement) des enfants de ”owl :TopObjectProperty”
et ”owl :TopDataProperty”, et des parents des sous-propriétés ”owl :BottomObjectProperty”
et ”owl :BottomDataProperty”. Les propriétés d’annotation telles que « owl :versionInfo »,
« rdfs :label », « rdfs :comment », « rdfs :seeAlso », « owl :priorVersion », etc. sont des
constructeurs intégrés dans OWL.
Les propriétés peuvent aussi être organisées hiérarchiquement et liées par des relations concep-
tuelles prédéfinies, telles que l’équivalence, la disjonction et beaucoup d’autres.

Figure 3.6 – Triplets des propriétés

Pour les instances, figure 3.7 :

- Le sujet est obligatoirement une instance ;

- L’objet est une instance, label ou commentaire ;
- Le prédicat existe de quatre types : Same-As, Different-From, Has-Label, Has-Comment.

64
 Une instance est un objet particulier instancié par les classes à l’aide de la relation prédé-
finie "Instance-Of".
Un individu peut ne pas avoir de classe(s) qui l’instancie(nt), dans ce cas, il sera implicitement
une instance de la classe « owl :Thing ».

Figure 3.7 – Triplets des instances

Triplets dont les prédicats sont les propriétés elles-mêmes :

Dans ce cas, le sujet est le domaine (qui représente la classe source ou bien l’individu
d’une classe), ainsi que l’objet est le co-domaine et qui est la classe cible (ou bien il peut
être une valeur de données quand le prédicat s’agit d’une propriété de type de données).
Le domaine et l’image sont reliés par l’intermédiaire des propriétés (d’objet ou de type de
données) extraites déjà à partir de l’ontologie du départ.

- Nous avons déterminé les propriétés d’objet définies pour chaque classe, puis les images de
chacune de ces propriétés (si elles existent).

- Pour les propriétés de type de données, nous avons extrait pour chaque instance (i.e. do-
maine), sa valeur de données qui est un littéral (i.e. co-domaine).

Tout cela nous a permis d’avoir des triplets de type :

« Domaine - Propriété(s) -> Co-domaine(s) ».

Nous pouvons trouver un domaine relié à plusieurs images à travers différentes propriétés
(figure 3.8). En outre, un domaine dans un triplet peut être une image dans un autre triplet.

65
 Figure 3.8 – Domaines et Images

Remarque : la technique de saturation de données permet de produire quasiment tous

les triplets possibles en appliquant toutes les règles d’inférence sur les données RDF. C’est le
rôle du moteur de raisonnement (Hermit dans notre cas) de les produire. Ces triplets dérivés
(inférés) sont rajoutés à l’ensemble de données générés. Pendant la saturation, chaque donnée
inférée peut participer à l’inférence d’autres données, jusqu’à ce qu’un point fixe soit atteint
(i.e. pas de nouveaux faits peuvent être inférés). Ensuite, la réponse à la requête est réduite
à une simple évaluation de la requête sur cet ensemble de données saturé.

3.4.3 Phase 3 : Chargement des triplets RDF dans Neo4j

Cette phase consiste à stocker les triplets RDF dans la BD graphique Neo4j, où le sujet et
l’objet sont des nœuds, ainsi que les prédicats sont les relations qui les relient (elles peuvent
être de type primitive OWL ; e.g. Sub-Class-Of, Equivalent-Object-Property, Same-As, etc,
ou bien des propriétés de l’ontologie ; telles que hasBase, UNDEFINED-part-of, etc). Les
nœuds et les relations, dans Neo4j, peuvent être étiquetés et attribués.

Cette phase s’effectue au fur et à mesure avec le parsing de l’ontologie (figure 3.9).

66
Figure 3.9 – Parsing de l’ontologie, génération et chargement du graphe RDF dans Neo4j

3.4.4 Phase 4 : Interrogation de la BD Neo4j

Afin d’interroger la BD graphique Neo4j, la requête utilisateur, initialement formulée en
langage naturel, doit passer par différentes étapes de traitement (Figure 3.10).

Ces étapes comportent :

- L’analyse de la requête utilisateur ;
- L’identification du type de chaque entité saisie ;
- La génération des différentes liaisons sémantiques possibles entre les composants de la re-
quête ;
- La génération des requêtes SPARQL-DL afin de les exécuter sur l’ontologie ;
- Équivalence de langages afin d’aboutir à des requêtes Cypher ;
- Exécution des requêtes Cypher (à partir de la BD graphique Neo4j) ;
- Comparaison des résultats de ces derniers.

67
 Figure 3.10 – Processus d’interrogation de la BD Neo4j

3.4.4.1 Étape de l’analyse de la requête utilisateur

Cette étape consiste à segmenter / décomposer la requête saisie par l’utilisateur afin d’iden-
tifier ses différents composants (i.e. entités nommées).

Il arrive que l’utilisateur ne saisit pas le nom de l’entité mais plutôt son synonyme, son
hyperonyme et/ou son hyponyme. Par conséquent, nous avons eu recours à la base de don-
nées lexicale WordNet, avec laquelle, et dans le cadre de ce travail, nous avons utilisé juste
les synonymes, car ils sont au même niveau, dans l’ontologie, que l’entité saisie. Cependant
les hyperonymes et les hyponymes sont de niveau supérieur et inférieur, respectivement. Cela

68
veut dire que l’hyperonyme est considéré comme la super-entité de l’entité saisie, ainsi que
l’hyponyme est sa sous-entité. Ce qui signifie qu’ils ne possèdent pas forcément les mêmes
informations (cette étape reste à améliorer en prenant également en considération les hyper-
onymes et les hyponymes).
La requête d’entrée passe par trois étapes de pré-traitement, et c’est WordNet qui assure ces
étapes :
- Tokenization ;
- Suppression des mots vides ;
- Lemmatisation du mot : déterminer le lemme des mots-clés restants.

Alors, après avoir terminé le pré-traitement de la requête en LN, il faut préciser et dé-
terminer si les mots-clés saisis sont les noms prédéfinis des entités, ou bien ils se référent à
leurs synonymes. Pour ce faire, et au moment du chargement dans la phase précédente, des
triplets RDF (dans lesquels le sujet est soit une classe, une propriété ou une instance), nous
avons stocké également tous les synonymes de chaque sujet. Nous avons, au même temps, relié
chaque synonyme d’un sujet à tous les objets de ce sujet par le biais des mêmes relations (e.g.
Sub-Class-Of, hasIngredientOf, etc), afin de former un sorte de graphe de synonymes. Réel-
lement, nous avons considéré les synonymes comme étant les noms des entités eux-mêmes.
Par exemple, nous supposons que l’utilisateur a saisi " What are FishTopping and thermal ?",
tel que "FishTopping" est le nom d’une classe, ainsi que thermal est le synonyme de la classe
"Hot" ; ces deux classes font parties de l’ontologie Pizza. Notre système va devoir répondre
à cette requête.

Cependant, la majorité des noms des entités dans les ontologies que nous avons utilisées, se
composent de deux parties ou voire plus (e.g. VegetableTopping, ThinandCrispyPizza, etc).
Dans ce cas, le moteur de WordNet segmente ces noms (e.g. il va segmenter "VegetableTop-
ping" en Vegetable et Topping), puis il détermine les synonymes de chaque partie du nom,
à part. Cependant, nous pouvons trouver deux noms de deux entités différentes qui se com-
posent de quelques parties similaires, tels que "OliveTopping" et "VegetableTopping". Ainsi,
nous allons stocker les synonymes de Vegetable reliés à tous les objets de VegetableTopping,
et de même pour Topping, nous allons charger tous ses synonymes associés à tous les objets
de VegetableToping.
Dans ce cas, si jamais l’utilisateur saisit un synonyme de Topping, le système va lui retourner
des informations sur les deux classes OliveTopping et VegetableTopping. Cela veut dire que
notre système va comprendre que ces deux entités partagent des informations en commun
et par conséquent, il va stocker pour chaque nœud (correspondant à une entité) quelques
informations de l’autre entité.
En somme, ces informations stockées ne sont pas forcément correctes sémantiquement.

D’autre part, nous pouvons trouver des ontologies dans lesquelles les noms des entités
peuvent contenir des chiffres et des symboles. Ces noms n’ont pas de synonymes dans Word-
Net, par exemple, MA-0001480, MA-0001435, etc, de l’ontologie Mouse.
Dans ce cas, nous avons proposé d’utiliser les labels des entités au lieu de leurs noms (i.e.
l’utilisateur pourra saisir le synonyme du label d’une entité). cependant, les entités ne pos-

69
sèdent pas toutes des labels. En gros, ce deux points restent à améliorer.

Enfin, un module de correspondance permet essentiellement de correspondre chaque com-

posant avec les entités de l’ontologie déjà parsée, afin d’identifier et de distinguer la nature
de chaque entité de la requête en LN. Pour ce faire, le système de stockage comprend quatre
premières listes, une stocke les classes, et les trois autres stockent les propriétés d’objet, de
type de données et les instances, respectivement. Les quatre autres listes comprennent les
synonymes de chaque type d’entités (i.e. classes, propriétés d’objet, propriétés de type de
données et instances). Il suffit alors de comparer chaque composant de ces mots-clés avec
chaque liste afin d’identifier sa nature / son type.

3.4.4.2 Étape de la génération de requêtes SPARQL-DL

SPARQL-DL est un sous-ensemble important de SPARQL. Il est un langage expressif
qui permet de mélanger des requêtes T-Box (i.e. axiomes décrivant les concepts et le relations
entre eux), A-Box (i.e. représentent les instances) et R-Box.
SPARQL-DL s’avère être un langage d’interrogation qui peut soutenir l’expressivité avancée
d’OWL 2. Il se diffère de SPARQL au niveau de la syntaxe, en outre, SPARQL fournit plus de
fonctionnalités lors de l’interrogation d’ontologies (e.g. la possibilité d’interroger un graphe
via le Web).
La cause pour laquelle nous avons utilisé SPARQL-DL au lieu de SPARQL, est parce que
OWL API n’a aucun support natif pour SPARQL. En effet, OWL API ne fonctionne pas
au niveau RDF où SPARQL le fait, mais plutôt au niveau OWL abstrait. SPARQL est un
langage standardisé pour interroger des données d’un graphe exprimé en RDF et non pas des
ontologies écrites en OWL.

Les mots-clés décomposés auparavant permettent de générer plusieurs sous-requêtes SPARQL-

DL. Il reste enfin à traduire / mapper les mots-clés saisis et décomposés au cours de l’étape
précédente, en des requêtes en langage d’interrogation SPARQL-DL (i.e. en un ensemble
de Triple Pattern TP, formant un BGP : Basic Graph Pattern). Une correspondance d’une
requête utilisateur N à partir d’une ontologie, est finalement une correspondance du BGP
avec l’ontologie O.
Alors, pour chaque type d’entité, nous allons exécuter un ensemble de requêtes SPARQL-DL
permettant de retourner les informations qui sont liées à elle. Nous utilisons un ensemble
de modèles de patrons graphiques (BGP ) de base prédéfinis (pour chaque type d’entité),
permettant de déterminer les interprétations possibles et adéquates des requêtes utilisateurs.
Ceci est réalisé en obtenant les listes des identifiants des entités (i.e. des mots-clés fournis)
et par la suite en injectant ces identifiants dans les positions appropriées dans les TP, de
telle sorte que les TP obtenus suite à cette injection, soient des sous-ensembles de l’ontologie
globale.

Ainsi, si nous exécutons directement les requêtes SPARQL-DL générées, les résultats se-
raient retournés à partir de l’ontologie. Cependant, notre but est d’interroger la BD Neo4j.

70
3.4.4.3 Étape de transformation/équivalence des requêtes SPARQL-DL en des
requêtes Cypher
En effet, l’utilisateur va fournir une requête en langage naturel et il n’a pas à se soucier
et ne lui intéresse pas réellement d’où vient le résultat à sa requête. Il saisit ses mots-clés
décrivant son besoin en information et il attend un résultat qui lui satisfait en un temps court.
Alors pourquoi faire une équivalence (une sorte de transformation) entre les deux langages ?

Tout d’abord, parce que notre but dès le départ est d’interroger un graphe RDF stocké
dans une BD graphique, alors que nous pouvons pas accéder aux graphes RDF avec le langage
SPARQL-DL. En outre et ce qui est le plus important, cela nous permettrait de changer de
BD-RDF tout en gardant le travail de la génération des requêtes SPARQL-DL à partir des
mots-clés, intacte. Cela veut dire que l’avantage de cette équivalence est qu’elle nous permet
d’implémenter l’architecture de notre système au-dessus d’une grande variété de BD-RDF
implémentant leurs langages d’interrogation, sans changer aucun des autres composants du
système. Alors, en changeant de BD-RDF, il suffirait juste de stocker les triplets existants
(déjà). Ensuite, il faut changer les requêtes du langage Cypher par des requêtes écrites en
langage propre à la nouvelle BD-RDF utilisée. Ainsi, l’équivalence reste applicable entre
SPARQL-DL et le nouveau langage.

Le but également (comme le montre la figure 3.11) est :

- Interroger en premier lieu l’ontologie elle-même directement en utilisant SPARQL-DL ;

- Interroger, par la suite, les données stockées dans la BD Neo4j en utilisant Cypher, plus
précisément, en passant par SPARQL-DL et en faisant l’équivalence.

⇒ Comparer les résultats de ces derniers : il faut absolument trouver les mêmes
résultats. Cela signifie que le passage d’une ontologie à un graphe RDF n’influence pas la
précision des résultats, et que les données d’une ontologie sont converties convenablement
et proprement vers un graphe RDF. Ces données reflètent fidèlement la sémantique décrite
dans l’ontologie.

71
 Figure 3.11 – Architecture générale de notre système

Alors, après avoir modélisé les requêtes SPARQL-DL d’une requête initialement formulée
par l’utilisateur, il faut maintenant passer à la phase de réécriture afin d’avoir des requêtes
Cypher. Les requêtes SPARQL-DL seront transformées en d’autres équivalentes à elles sé-
mantiquement afin de pouvoir accéder à Neo4j. Il est nécessaire, pour la réécriture de la
requête, que l’application de la transformation n’influence pas le résultat final de la requête.

Notre système vise à réécrire les requêtes SPARQL-DL (en d’autres Cypher ) en s’assurant
que les reformulations reflètent autant que possible la même signification, la même structure,
le même type de résultats et la même taille de résultat que les requêtes SPARQL-DL initiales.

Remarque : véritablement, il n’y a pas une manière universelle permettant de mesurer

la distance ou/et la similarité entre deux requêtes formelles.

Par conséquent, afin d’assurer cette équivalence :

- Nous avons pris chaque deux requêtes (SPARQL-DL et Cypher ) renvoyant, normalement,
les mêmes résultats ;
- Nous avons essayé d’identifier de chaque côté, les parties similaires (qui se répètent) entre
chaque deux requêtes SPARQL-DL et Cypher ;
- Afin de générer des requêtes Cypher à partir de celles SPARQL-DL, nous avons gardé les

72
parties similaires syntaxiquement des deux requêtes et nous avons écrasé les autres parties
(différentes) des requêtes SPARQL-DL et les fait remplacer par leurs correspondantes du
langage Cypher. Les figures 3.12 et 3.13 montrent des exemples de requête SPARQL-DL et
Cypher ayant pour but de déterminer les sous-classes d’une classe donnée. En analysant ces
deux requêtes, on constate que les deux langages sont presque totalement différents syntaxi-
quement, et par conséquent, il n’y avait pas de grandes équivalences dégagées.

Figure 3.12 – Exemple de requête SPARQL-DL

Figure 3.13 – Exemple de requête Cypher

Toutes les variables qui apparaissent dans les TP de la requête SPARQL-DL, apparaissent
également dans la requête Cypher.

Dans les requêtes SPARQL et SPARQL-DL, nous utilisons le mécanisme des espaces de
noms pour définir les préfixes afin de rendre les requêtes plus lisibles. Un IRI (Internationalised
Resource Identifier) d’une entité, est composé d’un "IRI de préfixe" suivi du symbole "#"
puis du "nom" de l’entité. En général, la partie "IRI de préfixe" de l’entité, est exactement
l’IRI de l’ontologie.

3.5 Interface de recherche et les différentes approches de

réponse aux requêtes
3.5.1 Interface de recherche
C’est une interface simple pour l’utilisateur donnée par figure 3.14. La 1ère partie intitulée
"Enter Your KeyWords", consiste à une zone du texte où l’utilisateur tape le nom des entités

73
appartenant aux ontologies considérées. L’utilisateur doit saisir des noms valides et la zone du
texte ne doit pas rester vide, sinon un message d’erreur s’affiche. Une fois le bouton "Search"
soit cliqué, le résultat s’affiche dans la zone du texte en lecture seule "The Answer is".

Figure 3.14 – Interface utilisateur

3.5.2 Les approches de réponse aux requêtes

3.5.2.1 Affichage de toutes les informations à l’utilisateur
Pour ce faire, il faut tout d’abord effectuer des combinaisons entre les mots-clés décompo-
sés de la requête en LN de l’utilisateur, afin d’établir les liaisons sémantiques possibles entre
eux. On doit alors pouvoir extraire une représentation sémantique du contenu de la requête
(N) en LN, qui nous permettra de générer la (ou les) requête(s) SPARQL-DL, et par la suite
les requêtes Cypher correspondantes. Chaque requête Cypher représente un sous-graphe du
graphe RDF global.

Parce que N est une donnée non structurée et G est un graphe contenant des données
structurées, nous avons dû combler l’écart entre deux types de données pour avoir une repré-
sentation graphique de N. Pour ce faire, il faut tout d’abord extraire les relations sémantiques
(i.e. les propriétés) impliquées de la question N ; dont chaque relation sémantique est un tri-
plet (arg1 , rel, arg2 ) où rel est la relation, arg1 , arg2 sont les éléments reliés par rel.

En effet, nous avons étudié le cas de un à trois mots-clés maximums, sinon ça va être
beaucoup de combinaisons à déterminer. Au delà de 3 mots-clés, notre système retourne les

74
informations de chaque entité à part sans effectuer des combinaisons sémantiques entre elles.

Au moment où l’utilisateur saisit un (ou plusieurs) mot-clé, toutes les informations pri-
mitives de l’entité saisie (Sub-Class-Of, Equivalent-Property, etc.), en plus, les résultats des
combinaisons des mots-clés vont être affichés.

3.5.2.1.a Le cas d’un seul mot-clé

C’est le cas le plus facile à traiter, dont le mot-clé peut être une classe, une propriété
(d’objet ou de type de donnés) ou bien une instance (tableau 3.1).

L’utilisateur saisit le nom (ou bien le synonyme du nom) d’une entité appartenant à l’on-
tologie en question (ou bien au graphe RDF de cette ontologie et qui est stocké dans Neo4j)
et il ne précise pas l’information qu’il veut avoir en retour. Ce mot-clé entré va être compa-
rer à toutes les structures existantes afin de déterminer sa nature (i.e. classe, propriété ou
instance). Ensuite, le système lui retourne toutes les informations liées à l’entité fournie.

Le saisi d’une seule entité signifie que deux composants du triplet RDF sont vides. Les
informations qui s’afficheront à l’utilisateur sont les résultats des requêtes SPARQL-DL (sur
l’ontologie) et ceux des requêtes Cypher par équivalence (sur le graphe RDF).

Un mot-clé est valide et pertinent, s’il peut être mis dans un patron de triplet (respec-
tivement, dans une requête Cypher) et que ce dernier soit un sous-ensemble de l’ontologie
considérée (respectivement, un sous-graphe du graphe RDF généré), ainsi qu’il retourne un
résultat. Même une valeur de 0 est prise en considération car cela peut signifier que la clause
WHERE de la requête SPARQL-DL et de la requête Cypher, ne produit aucune correspon-
dance ni dans l’ontologie ni dans le graphe RDF.

75
 Mot-clé Résultats attendus
∗ Ses classes équivalentes ;
Classe ∗ Ses classes disjointes ;
∗ Ses sous-classes ;
∗ Ses instances (s’il y en a) ;
∗ Son label et son commentaire.
∗ Ses propriétés équivalentes ;
Propriété ∗ Ses propriétés disjointes ;
∗ Ses sous-propriétés ;
∗ Ses propriétés inverses (que pour les propriétés d’objet) ;
∗ Son label et son commentaire ;
∗ Son domaine (classe source) ;
∗ Son image (classe cible).
⇒ qui sont reliés par la propriété donnée :
? → propriété X → ?
∗ Ses instances équivalentes
Instance ∗ Ses instances différentes
∗ Son label et son commentaire
∗ Déterminer la classe à laquelle l’instance (saisie) appartient,
via la relation Instance-Of :
Instance → Instance-Of → ?

Table 3.1 – Cas de recherche d’un seul mot-clé

3.5.2.1.b Le cas de deux mots-clés

Dans ce cas, il y en a six combinaisons à déterminer (tableau 3.2).

Par exemple, si les deux entités saisies sont des classes, alors le problème devient celui de
déterminer une relation qui peut relier ces deux classes. Cette relation est le prédicat, qui
peut être de type primitive OWL (i.e. Sub-Class-Of, Equivalent-Class-Of, etc), ou bien une
propriété d’objet.
Le système retourne également toutes les informations (citées dans le cas précédent) de ces
deux classes.

Le cas le plus compliqué est quand l’utilisateur fournit deux arguments dont l’un est une
classe et l’autre est une propriété. Tout d’abord, le système considère la classe saisie comme
étant le domaine (le sujet du triplet) et il détermine alors son (ses) co-domaine(s) tout en
considérant la propriété fournie comme un prédicat. Ensuite, cette fois le système met la classe

76
à la place de l’objet du triplet RDF (i.e. comme étant une image), et alors il doit déterminer
son (ses) domaine(s) par le biais de la propriété initialement fournie par l’utilisateur.
Les informations de chacune de ces entités à part, s’afficheront également à l’utilisateur.

Mots-clés Résultats attendus

Deux classes ∗ Retourner les informations (déjà mentionnées dans
le cas précédent) de chacune de ces deux classes.
La (les) relation(s) qui relie(ent) ces deux classes (s’il y en a).
∗ Retourner les informations (déjà mentionnées dans
Deux propriétés le cas précédent) de chacune de ces deux
propriétés +
∗ Leurs domaines et leurs images.
∗ Les informations (déjà mentionnées dans le 1er
Deux instances cas) de chacune de ces deux instances +
∗ La (les) classe(s) qui les instancie(ent).
∗ Les informations de chaque entité saisie ;
Une classe-Une propriété ∗ Au début, on considère la classe (donnée) comme
un domaine (classe source) et donc on va déterminer le
co-domaine (la classe cible) et qui sont reliées à
elle par l’intermédiaire de la propriété saisie :
Domaine (classe saisie) → propriété saisie → ?
∗ Dans un 2ème lieu, soit la classe saisie une image (classe
cible), et donc on va rechercher sa (ses) classe(s) source(s)
(domaines), sachant que le prédicat est la propriété saisie.
? → propriété saisie → Image (classe saisie)
∗ En plus de déterminer les informations de chacune,
Une classe-Une instance le système va aussi retourner si la classe saisie
par l’utilisateur contient l’instance donnée.
Une propriété-Une instance ∗ Dans ce cas, on va déterminer juste les informations de
la propriété et de l’instance données.

Table 3.2 – Cas de recherche de deux mots-clés

3.5.2.1.c Le cas de trois mots-clés

Cela impliquera dix combinaisons à produire (tableau 3.3).

Les mots-clés saisis doivent être regroupés ensembles en des segments. Pour chaque seg-
ment, des informations appropriées sont alors déterminées. Un segment valide est un segment
pour lequel au moins une information peut être trouvée dans le graphe RDF sous-jacent. Notre
algorithme montre une approche naïve pour trouver tous les segments valides, en considérant
l’ordre des mots-clés. Il commence par le 1er mot-clé dans la requête donnée en tant que 1er
segment, puis ajoute le mot-clé suivant au segment en cours et vérifie si cet ajout rendrait
le nouveau segment invalide. Ce processus est répété jusqu’à ce qu’il atteigne la fin de la
requête (i.e. toutes les combinaisons possibles).

77
Mots-clés Résultats attendus
Trois classes ∗ Déterminer leurs informations respectivement.
Trois propriétés ∗ Déterminer leurs informations, ainsi que leurs
domaines et leurs images :
? → propriété X → ?.
Trois instances ∗ Déterminer leurs informations et à quelle(s)
classe(s) elles appartiennent.
∗ Les informations des entités saisies +
Deux classes-Une propriété ∗ Domaine(s) et image(s) de la propriété saisie +
∗ Image(s) de chacune des classes via la propriété
saisie +
∗ Domaine(s) de chacune des classes via
la propriété saisie.
∗ Les informations de chacune des entités saisies +
Deux classes-Une instance ∗ A quelle classe appartient l’instance saisie +
∗ Déterminer si l’une des classes (entrées) contient
l’instance donnée.
∗ L’ensemble des informations des entités saisies +
Deux propriétés-Une classe ∗ Domaine(s) et image(s) de chacune des propriétés +
∗ Domaine(s) de la classe saisie via les deux propriétés
données (une par une)
? → P1 → C
? → P2 → C
∗ Image(s) de la classe saisie via les
deux propriétés données.
C → P1 → ?
C → P2 → ?
2 propriétés-Une instance ∗ Juste affichage des informations de chaque entité
entrée.
∗ Informations de ces entités +
Deux instances-Une classe ∗ Déterminer la(les) classe(s) auxquelles les instances
saisies appartiennent.
2 instances-Une propriété ∗ Détermination des informations de chaque entité
entrée.
1 instance- 1 propriété- 1 classe ∗ Détermination des informations de chaque entité.

Table 3.3 – Cas de recherche de trois mots-clés

78
 Exemple d’exécution

On suppose que l’utilisateur a saisi la requête en LN (dans la figure 3.15) qui comporte
un nom d’une classe et un nom d’une propriété ⇒ le résultat va contenir les informations
de type primitives OWL de ces entités, de plus, les résultats des combinaisons de ces deux
mots-clés, i.e. :
- Les informations de la classe et de la propriété saisies +
- Le domaine et l’image de la propriété saisie +
- L’image (respectivement le domaine) de la classe saisie tout en considérant à chaque fois la
propriété fournie comme étant le prédicat.

Figure 3.15 – Requête utilisateur en LN

Dans cet exemple, nous travaillions sur l’ontologie Pizza (nous allons définir cette ontologie
dans le chapitre suivant). Après la décomposition de la requête, nous saisissons que l’utilisa-
teur a fourni deux noms de deux entités : « Country » qui est une classe et « hasBase » qui
représente une propriété d’objet. Nous supposons que l’utilisateur ne connait ni la nature des
entités saisies ni la structure du graphe interrogé.

(Remarque : nous avons utilisé l’ontologie Pizza dans cet exemple parce qu’elle est riche
en informations. Elle comporte des classes, des propriétés d’objet et de type de données ainsi
que des instances. Alors, elle nous permet d’évaluer l’exhaustivité de notre travail.)

79
 Les figures 3.15, 3.16, 3.17, 3.18 et 3.19 présentent les résultats de cette requête utilisateur
en exécutant (tout d’abord) des requêtes SPARQL-DL sur l’ontologie.
La figure 3.16 montre les sous-classes et les classes équivalentes de celle saisie par l’utili-
sateur, tout en précisant le type de l’entité Country. Nous constatons la présence du préfixe
qu’on en a déjà parlé (pour les requêtes SPARQL-DL, le préfixe est une chose indispensable
dans l’écriture de la requête puisqu’il permet de déterminer l’IRI de l’ontologie cible à in-
terroger et ce qui est logique vu qu’on interroge l’ontologie directement, ainsi qu’il s’affiche
également dans les résultats, mais cela ne change rien).

La classe "Nothing" est la sous-classe de toutes les classes dans l’ontologie, c’est pour
cette raison qu’on remarque sa présence à chaque fois qu’on demande les sous-classes d’une
certaine classe.
De même, nous constatons que le moteur d’interrogation de SPARQL-DL suppose toujours
qu’une classe est équivalente sémantiquement à elle-même (i.e. la classe Country possède
qu’une seule classe équivalente, qui est Country elle-même). Dans ce contexte, la règle dit
qu’un axiome EquivalentClasses (C1 C2 ) entre 2 entités est formellement équivalent à 2
axiomes de subsomption réciproques :

- SubClassOf (C1 C2 ) ;
- SubClassOf (C2 C1 ).

Cela veut dire que, puisque Country est équivalente à elle-même alors elle est, suivant la
règle, une sous-classe à elle-même. Ces informations sont inférées par le raisonneur et elles
me semblaient triviales que je ne les ai pas stocké dans Neo4j, c’est pour cette raison qu’elles
ne sont pas affichées en appliquant les requêtes Cypher par équivalence (figure 3.20, page 84).

80
 Figure 3.16 – Résultats de la requête en LN en utilisant SPARQL-DL (1)

Ensuite, l’annotation (le label ainsi que le commentaire) de la classe saisie et ses instances,
sont présentés dans la figure 3.17.

81
 Figure 3.17 – Résultats de la requête en LN en utiliant SPARQL-DL (2)

Après avoir affiché toutes les informations de la classe saisie, il faut maintenant afficher
celles de la propriété. La figure 3.18 montre les sous-propriétés et les propriétés équivalentes
de « hasBase ». Finalement, cette propriété ne possède pas d’annotation comme le montre
la figure 3.19.

De même, la propriété d’objet hasBase ne possède qu’une seule propriété équivalente, qui
est hasBase elle-même. Par conséquent, hasBase est une sous-propriété à elle-même (suivant
la règle précédemment définie).
La sous-propriété BottomObjectProperty est la sous-propriété d’objet de toutes les propriétés
d’objet de l’ontologie.

82
Figure 3.18 – Résultats de la requête en LN en utilisant SPARQL-DL (3)

Figure 3.19 – Résultats de la requête en LN en utilisant SPARQL-DL (4)

83
 Maintenant, nous devons afficher à l’utilisateur, également, les résultats de sa requête (en
LN) en utilisant Cypher (en passant par l’équivalence définie auparavant). La figure 3.20
présente les sous-classes, classes équivalentes, annotation et instances de la classe « Country
» saisie. On constate l’absence du préfixe dans les résultats et c’est parce que nous les avons
enlevé lors du chargement dans la BD.

Figure 3.20 – Résultats de la requête en utilisant Cypher (par équivalence) (1)

La figure 3.21 indique les domaines et les co-domaines de la propriété « hasBase », ainsi
que ses propriétés équivalentes, ses sous-propriétés et ses annotations (qu’elle ne les possède
pas).
Dans la figure 3.22, nous constatons que notre système a affiché les résultats des combinaisons
entre les entités saisies. Dans notre exemple, il nous a renvoyé l’image (respectivement, le
domaine) de la classe « Country » via la propriété « hasBase » (i.e. il a considéré hasBase
comme un prédicat).

84
Figure 3.21 – Résultats de la requête en utilisant Cypher (par équivalence) (2)

Figure 3.22 – Résultats de la requête en utilisant Cypher (par équivalence) (3)

85
Nous avons obtenu les mêmes résultats que ce soit en utilisant SPARQL-DL tout court ou
bien en appliquant Cypher (tout en passant par SPARQL-DL). Les mêmes résultats s’af-
fichent également dans l’interface, cependant nous avons choisi de faire des imprimes d’écran
du console pour réduire le nombre de captures.

Cette technique s’avère bonne pour des requêtes simples mais ce n’est pas le cas pour
des requêtes plus compliquées, car le système doit parcourir les données sur tout le graphe
RDF (respectivement, les données de l’ontologie) au moment de l’interrogation, afin de le
faire correspondre aux requêtes Cypher complexes (respectivement, aux patrons SPARQL-
DL complexes).

3.5.2.2 La recherche à facettes

En appliquant la méthode précédente, et qui permet de déterminer toutes les informations
sur le(s) mot(s)-clé(s) utilisateur, et de générer toutes les combinaisons sémantiques entre
eux, ce qui aboutit à un nouveau ensemble de requêtes, afin de déterminer le maximum
d’informations sur la question utilisateur, on constate que le résultat est long et parfois très
long, parce que on ne sait pas ce que l’utilisateur cherche exactement et du coup, on lui
affiche tous sur sa requête.
Afin de palier ce problème, nous avons proposé d’appliquer ce qu’on appelle de la « recherche
facettée ».
Ce sont des interfaces qui s’enchaînent, un dialogue avec l’utilisateur lui permettant de raffiner
l’interprétation de son besoin en informations, afin de mieux le satisfaire.

Figure 3.23 – Interface à facettes (1)

86
 En saisissant ses mots-clés et en cliquant sur le bouton « Search », une 2ème interface
(figure 3.23) s’affiche à l’utilisateur contenant les différents choix possibles. Cette interface
marque le début du processus de navigation. L’utilisateur peut sélectionner alors son besoin
en information et le système réagit à ces actions en mettant à jour les résultats de la re-
cherche. Nous avons capturé les facettes qui sont pertinentes pour chaque entité.

Une fois l’utilisateur fait son choix (parmi ces choix, nous trouvons le bouton « ALL »
qui nous permet d’afficher toutes les informations sur les entités saisies), une 3ème interface
(figure 3.24) s’affiche indiquant à l’utilisateur qu’il peut choisir avec quel langage il préfère
avoir les résultats.

Avec cette méthode qui assure la navigation à travers les collections inter-connectées des
entités, les utilisateurs peuvent diminuer les résultats de recherche. Nous devons alors tra-
duire les mots-clés et les choix de l’utilisateur en un ensemble de Triples Pattern (requête
SPARQL-DL).

Figure 3.24 – Interface à facettes (2)

3.5.2.3 Interrogation de plus d’une ontologie

L’utilisateur (en saisissant sa requête en LN), normalement il n’est pas obligé de savoir
quelle entité est de quelle ontologie. Par conséquent, il n’a pas à se soucier si son entré com-
porte des entités de différentes ontologies.

87
 Alors, un défi, est que l’information permettant de répondre à une certaine question, puisse
exister entre différents graphes RDF. Afin de répondre à ce défi, notre approche ressemble à
une recherche horizontale, où chaque composant d’une requête d’entrée est comparé à tous
les ensembles de données disponibles afin de déterminer à quelle ontologie il appartient.

Alors, après avoir parsé les ontologies, extrait les triplets RDF et les stocké dans Neo4j
(figure 3.25), on aura la possibilité d’interroger, au même temps, soit ces ontologies direc-
tement (en utilisant SPARQL-DL), soit leurs graphes RDF à partir de Neo4j (en utilisant
Cypher par équivalence), tout en donnant, à l’utilisateur, l’impression d’interroger un seul
graphe RDF (i.e. l’utilisateur peut saisir, à la fois, N entités de N ontologies différentes).

Figure 3.25 – Architecture générale du processus du traitement de plusieurs ontologies

Exemple :
La question d’entrée formulée par l’utilisateur en LN (e.g. figure 3.26), est d’abord traitée et
analysée. L’étape suivante consiste à identifier la nature des entités décomposées, afin de les
placer dans les partons de triplet (TP) SPARQL-DL correspondants (respectivement, dans

88
les requêtes Cypher correspondantes). Ces patrons de requêtes contiennent des emplacements
vides (pour les préfixes, puisque nous ne pouvons interroger une ontologie, avec le langage
SPARQL-DL, que si en indiquant son IRI, et vu que nous sommes en train d’interroger plu-
sieurs ontologies en même temps, ces emplacements restent vides jusqu’à la détermination
des ontologies qui contiennent les différentes entités saisies).
En somme, ces emplacements, qui sont des éléments manquants de la requête, doivent être
traités par des IRIs par rapport aux ontologies interrogées.

Figure 3.26 – Interrogation de plusieurs ontologies

Après que le système décompose la requête, nous obtenons trois noms d’entités qui sont :
- TomatoTopping ;
- MA-0001480 ;
- hasIngredient.

Le système doit déterminer d’abord à quelles ontologies appartienne chacune de ces entités.
Cela se fait en comparant chacune d’elles avec les listes stockant les noms des classes, proprié-
tés d’objet, propriétés de type de données et instances, respectivement. Ces listes stockent
juste les noms des différentes entités de chaque ontologie, et ont pour intérêt d’aider à la
découverte de l’appartenance de chaque entité fournie. Par exemple, dans notre cas, notre
algorithme va déterminer que TomatoTopping et hasIngredient appartiennent à l’ontologie
Pizza, ainsi que MA-0001480 appartient à l’ontologie Mouse.

89
Une fois cette étape soit terminée, nous devons maintenant reconnaître la nature de chaque
entité saisie pour savoir quelles requêtes devons nous exécuter.
Revenons à notre exemple, le système va reconnaître que TomatoTopping et MA-0001480
sont des classes, ainsi que hasIngredient est une propriété d’objet.
Enfin, les emplacements vides vont être remplis par les préfixes (IRIs) des deux ontologies en
question, et les requêtes SPARQL-DL vont être exécutées, générant par la suite des requêtes
Cypher.

La figure 3.27 indique les résultats correspondants à la classe TomatoTopping. Ces résultats
sont retournés suite à l’exécution des requêtes Cypher sur le graphe RDF de l’ontologie Pizza.

Figure 3.27 – Résultats des requêtes Cypher (1)

La figure 3.28 affiche les informations de la propriété d’objet fournie (hasIngredient), suite
à l’exécution des requêtes Cypher par équivalence sur le graphe RDF de l’ontologie Pizza.

90
 Figure 3.28 – Résultats des requêtes Cypher (2)

Enfin, la figure 3.29 détermine la réponse correspondante à la classe MA-0001480. Cette

réponse est le résultat des requêtes Cypher sur le graphe RDF de l’ontologie Mouse.

91
 Figure 3.29 – Résultats des requêtes Cypher (3)

3.6 Conclusion
En somme, les Triples Stores constituent de plus en plus la base de plusieurs applications.
Il est alors très important que, pendant l’implémentation de n’importe quelle application,
d’avoir une idée claire sur les forces et les faiblesses des implémentations des TS actuels.
L’efficacité de données joue un rôle important lorsqu’il s’agit de données à grande échelle. En
outre, c’est évident qu’il est difficile pour les utilisateurs (même pour les professionnels) de
concevoir des requêtes SPARQL compliquées.

Dans ce contexte, notre application fournit un outil pratique permettant de récupérer des
données à partir des graphes RDF. Notre interface de recherche rend la procédure d’inter-
rogation d’un graphe RDF suffisamment conviviale. Nous avons utilisé SPARQL-DL comme
langage d’interrogation, qui est conforme aux recommandations du W3C et qui s’avère être
un langage de requête pouvant soutenir l’expressivité avancée d’OWL 2. Hermit lui-même
s’avère être efficace pour soutenir cette expressivité. Sans oublier Neo4j qui offre un accès
et une gestion de données performants, ainsi qu’une fluidité de représentation guidée par le
besoin.
Notre application effectue une récupération de données RDF de manière efficace avec des
temps d’exécution encourageants.

92
Chapitre 4

Résultats expérimentaux et discussions

4.1 Introduction
Le chapitre précédent a fait l’objet d’une description détaillée de notre méthode d’inter-
rogation de la BD Neo4j. Dans ce chapitre, nous allons mettre l’accent sur l’évaluation et
l’expérimentation de notre approche. Notre méthode est réalisée en utilisant un ensemble de
métriques d’évaluation. Ces dernières permettent d’estimer la qualité des résultats de l’inter-
rogation. L’expérimentation a été effectuée sur plusieurs types d’ontologies.

Ce chapitre est organisé comme suit : la première partie décrit l’environnement d’expéri-
mentation et les outils utilisés afin d’implémenter notre méthode. La deuxième partie présente
les métriques d’évaluation permettant d’estimer l’efficacité de notre approche. Par la suite,
une évaluation sur différentes ontologies de différentes tailles, ainsi qu’une discussion, on été
présentées.

4.2 Environnement d’expérimentation et outils

Nous allons dans cette section, étudier les différents composants de l’environnement ma-
tériel et logiciel avec lesquels nous avons réalisé une étude expérimentale.

Notre algorithme a été implémenté en langage Java en utilisant l’OWL API 3.4.8. Afin
d’ajouter de l’intelligence aux données, il faut passer par une phase d’enrichissement de
connaissances dans laquelle une ontologie joue un rôle fondamental. Grâce à ces données
intelligentes, n’importe quel système peut réaliser des déductions, qui ne semblent pas évi-
dentes pour un être humain (e.g. extraction de résumés, recommandations, détection de
conflits, etc). C’est dans ce cadre que OWL API a été développée. Il s’agit d’un ensemble
d’interfaces riches en fonctionnalité, assurant une manipulation flexible des ontologies. Elle
nous a permis de parser (analyser) les ontologies d’entrée ainsi d’identifier leurs différentes
entités.

Tout ce travail a été réalisé sous l’environnement de développement Eclipse KELPER.

93
L’environnement Eclipse garantie la réutilisation ou la modification de quelques modules fai-
sant partie de notre méthode.

Pour le raisonnement sur les ontologies, nous avons utilisé la dernière version officielle,
stable et la plus récente Hermit 1.3.8. Concernant l’interrogation de l’ontologie directement,
avons avons travaillé avec la version 1.0.0 de SPARQL-DL.
Nous avons également eu recours à la version 3.1.2 de la BD graphique Neo4j, afin de stocker
les triplets RDF (graphe RDF). Il suffit de l’intégrer en Java sous forme d’une bibliothèque
(library).

Afin de se connecter à la BD graphique Neo4j, nous devons :

- Définir un type énuméré implémentant la classe RelationshipType (pour décrire, manuel-
lement et à notre choix, toutes les relations possibles entre les nœuds du graphe RDF) ;
- Créer une fonction registerShutDownHook chargée de fermer la connexion en cas de
problème ;
- Effectuer la connexion (i.e. créer le graphe grâce à la fonction GraphDatabaseFactory ).
→ Les opérations de mise à jour de la BD, se font dans un bloc « try ... finally ».

L’ensemble de tests a été réalisé sur un PC doté d’un système d’exploitation Windows 7
professionnel muni d’un processeur Intel Core i3, avec une horloge ayant une fréquence 2.30
GHz et 6 Go de RAM.

Nous avons intégré la version 2.0 de la base de données lexicale WordNet pour le traitement
des requêtes en langage naturel des utilisateurs.

4.3 Métriques d’évaluation

Dans le but de mesurer l’efficacité de notre méthode d’interrogation, un ensemble de
métriques d’évaluation est bien nécessaire. Ces mesures d’évaluation incluent le temps du
parsing, le temps du stockage et le temps de réponse.

- Le temps du parsing : c’est le temps nécessaire pour que toutes les informations de
l’ontologie soient analysées et parsées ;

- Le temps du stockage : c’est le temps nécessaire pour générer tous les triplets RDF à
partir de l’ensemble d’entités résultant de l’étape du parsing, ainsi pour les sauvegarder dans
la base de données graphique Neo4j.

Le stockage se fait au fur et à mesure avec le parsing, alors nous allons les fusionner en une
seule mesure : temps du parsing et du chargement ;

- Le temps de réponse : c’est le temps nécessaire pour que notre système réponde à
une requête utilisateur formulée en langage naturel.

94
 Dans tous les cas de mesures, nous allons évaluer la performance de notre méthode en
utilisant Hermit et sans l’utilisation de Hermit (i.e. raisonnement par défaut de OWL API) ;
avec des requêtes simples et d’autres compliquées ; avec SPARQL-DL tout court et avec
Cypher (tout en passant par l’équivalence décrite dans le précédent chapitre). Enfin, nous
allons analyser l’impact de la taille du graphe sur les performances de la BD graphique Neo4j,
en particulier sur le temps du parsing (de l’ontologie) et du chargement (du graphe RDF),
ainsi que sur le temps de réponse à une requête utilisateur.

4.4 Évaluation de l’approche

Afin d’évaluer la performance et la faisabilité de notre algorithme, nous allons utiliser
différentes ontologies de différentes tailles. Dans un premier temps, nous décrivons les ca-
ractéristiques des ontologies utilisées. Après, nous notons les résultats obtenus et nous les
discutons afin de mettre en relief les points forts et les points faibles de notre méthode.

4.4.1 Avec de petites à moyennes ontologies

4.4.1.1 Pizza et la base « Anatomy »
• Pizza est une ontologie bien connue dans la communauté du Web sémantique. Elle a été
développée pour des fins éducatives, par l’université de Manchester, qui est une université
leader dans le développement des technologies sémantiques.
• La base « Anatomy » est composée de deux ontologies de taille moyenne : « Mouse » qui dé-
crit l’anatomie de la souris adulte, et « Human » qui décrit l’anatomie humaine, (Tableau 4.1)

Ontologies Classes Propriétés d’objet Propriétés de type de données Instances

Pizza 100 8 0 5
Mouse 2744 3 0 0
Human 3304 2 0 0

Table 4.1 – Présentation de Pizza et la base « Anatomy »

4.4.2 Avec de grandes ontologies

4.4.2.1 Présentation de la base « Large Biomedical Ontologies »
Dans le contexte du passage à l’échelle (scalabilité), nous avons choisi d’implémenter les
ontologies appartenant à la base « Large Biomedical Ontologies », afin d’étudier l’influence
de la taille des ontologies sur l’efficacité et la performance de notre système.
Cette base contient des ontologies qui sont sémantiquement riches et contiennent de dizaines

95
de milliers de concepts (classes), tableau 4.2.
La base LargeBio se catégorise en trois classes de taille croissante :
- FMA-NCI small overlapping ;
- FMA-NCI extended (medium) overlapping ;
- FMA-NCI whole overlapping (la catégorie la plus complète).

Ontologies Classes Prop objet Prop data Instances

FMA (small) 3696 0 24 0
NCI (small) 6488 63 0 0
SNOMED (small) 13 412 18 0 0
FMA (medium) 10 157 0 24 0
NCI (medium) 23 958 82 0 0
SNOMED (medium) 51 128 51 0 0
FMA (whole) 78 988 0 54 0
NCI (whole) 66 724 123 67 0
SNOMED (whole) 122 464 55 0 0

Table 4.2 – Présentation de la base « LargeBio »

4.4.3 Résultats et interprétations

4.4.3.1 Interrogation d’une seule ontologie - retour de toutes les informations
Nous allons tout d’abord dégager les temps d’exécution suite à l’interrogation d’une seule
ontologie avec le retour de toutes les informations des mots-clés saisis (tableau 4.3, page 97 ;
tableau 4.4, page 98 ; tableau 4.5, page 101 et tableau 4.6, page 104). Pour ce faire, nous avons
effectué cinq exécutions simultanées, et nous avons calculé la moyenne de ces cinq mesures à
chaque fois en milli-secondes et en minutes.

Nous allons, dans ce qui suit, utiliser les ontologies selon ces numérotations. Nous les avons
numéroté par ordre croissant :
1) Oei-FMA-small-overlapping-nci.owl (3696 classes) ;
2) Oei-NCI-small-overlapping-fma.owl (6488 classes) ;
3) SNOMED-small-overlapping-fma.owl (13 412 classes) ;
4) Oei-FMA-small-overlapping-snomed.owl (10 157 classes) ;
5) Oei-NCI-small-overlapping-snomed.owl (23 958 classes) ;
6) Oei-SNOMED-small-overlapping-nci.owl (51 128 classes) ;
7) Oei-FMA-whole-ontology.owl (78 988 classes) ;

96
 Temps parsing et stockage Temps de réponse
Ontologie No exé avec Hermit sans Hermit avec SPARQL-DL avec Cypher

1. 2450 ms 1688 ms 63 ms 2773 ms

Pizza
2. 2405 ms 1624 ms 64 ms 2762 ms
3. 2419 ms 1682 ms 79 ms 2712 ms
4. 2559 ms 1655 ms 63 ms 2781 ms
5. 2781 ms 1701 ms 93 ms 2733 ms
2522 ms 1670 ms 72 ms 2752 ms
Moy
0.042 min 0.027 min 0.0012 min 0.045 min

1. 3512 ms 1983 ms 47 ms 3669 ms

Human
2. 3420 ms 1764 ms 50 ms 3506 ms
3. 3325 ms 1888 ms 32 ms 3056 ms
4. 3403 ms 1889 ms 16 ms 1359 ms
5. 3434 ms 1904 ms 63 ms 2826 ms
3418 ms 1885 ms 41 ms 2883 ms
Moy
0.056 min 0.031 min 0.0006 min 0.048 min

1. 3200 ms 1420 ms 47 ms 3310 ms

Mouse
2. 3185 ms 1499 ms 47 ms 3154 ms
3. 3387 ms 1624 ms 31 ms 3208 ms
4. 3262 ms 1608 ms 75 ms 3230 ms
5. 3231 ms 1670 ms 48 ms 3294 ms
3253 ms 1564 ms 49 ms 3239 ms
Moy
0.054 min 0.026 min 0.00082 min 0.053 min

Table 4.3 – Temps d’exécution de Pizza et de la base « Anatomy » avec retour de toutes
les informations

8) Oei-NCI-whole-ontology.owl (66 724 classes).

97
 Temps parsing et stockage Temps de réponse
Ontologie No exé avec Hermit sans Hermit avec SPARQL-DL avec Cypher

1. 5009 ms 5836 ms 47 ms 5249 ms

1)
2. 4962 ms 5621 ms 48 ms 7539 ms
3. 5367 ms 5541 ms 16 ms 7385 ms
4. 5181 ms 5561 ms 48 ms 7347 ms
5. 5149 ms 5380 ms 50 ms 5089 ms
5133 ms 27 939 ms 41 ms 6521 ms
Moy
0.085 min 0.465 min 0.00069 min 0.108 min

1. 4681 ms 15 227 ms 50 ms 5760 ms

2)
2. 2746 ms 15 529 ms 47 ms 5245 ms
3. 2621 ms 16 085 ms 32 ms 5151 ms
4. 2527 ms 15 622 ms 62 ms 5446 ms
5. 2574 ms 16 087 ms 31 ms 5229 ms
3029 ms 15 710 ms 44 ms 5366 ms
Moy
0.050 min 0.261 min 0.00074 min 0.089 min

1. 3868 ms 5119 ms 32 ms 8220 ms

3)
2. 5429 ms 4665 ms 31 ms 7560 ms
3. 7348 ms 4979 ms 48 ms 7586 ms
4. 4712 ms 4854 ms 48 ms 7773 ms
5. 3947 ms 4433 ms 31 ms 8632 ms
5060 ms 4810 ms 38 ms 7954 ms
Moy
0.084 min 0.080 min 0.00063 min 0.132 min

Table 4.4 – Temps d’exécution de la base « LargeBio(small) » avec retour de toutes les
informations

98
99
 Les valeurs en gras représentent les mesures minimales de tous les temps des cinq exécu-
tions.

Pour les ontologies de petites à moyennes tailles (Pizza, Human et Mouse), le temps du
parsing et du chargement avec le raisonneur par défaut, est visiblement plus petit, dans
tous les essais d’exécution, que celui en utilisant le raisonneur Hermit. Le temps du parsing
et du chargement sont différents (par rapport au raisonneur) dus aux résultats du parsing
différents. Nous constatons que Hermit est un raisonneur très performant qui donne des ré-
sultats inférés, pour laquelle il prend largement du temps (il déduit des connaissances, i.e.
la hiérarchie inférée de l’ontologie, les classes équivalentes, etc). Par contre, le raisonneur
hiérarchique d’OWL API est beaucoup plus rapide car il donne des résultats non inférés, i.e.
des résultats en se basant uniquement sur les assertions écrites dans l’ontologie et il déduit
juste la hiérarchie de l’ontologie telle qu’elle est définie.

Pour les grandes ontologies, et d’après la comparaison entre le "parsing et le chargement

avec Hermit" et le "parsing et le chargement sans Hermit", nous remarquons que le rai-
sonneur n’affecte pas le temps d’analyse et du stockage, c’est une différence aussi minime et
négligeable que dans la plupart du temps, le parsing et le stockage sans Hermit dépasse ceux
avec Hermit (comme pour l’ontologie no 2). Alors, c’est comme s’il n’y avait aucune différence
si nous utilisons un raisonneur ou pas.

Nous pouvons dire aussi que le temps du chargement dans Neo4j dépend du nombre de
triplets chargés (i.e. la taille du graphe RDF à stocker), comme le prouve l’ontologie no 7 et
l’ontologie no 8, qui contiennent 78 988 et 66 724 concepts (respectivement), et qui ont pris
le plus du temps pour le parsing et le chargement, comme l’indique plus clairement la figure
4.1 (tableau 4.6, page 104). Cela est probablement lié à la réorganisation des données sur
disque, qui commence à un moment spécifique lors du chargement de l’ensemble de triplets
RDF.

Figure 4.1 – Temps du parsing et du chargement

100
 Temps parsing et stockage Temps de réponse

Ontologie No exé avec Hermit sans Hermit avec SPARQL-DL avec Cypher

1. 3714 ms 3091 ms 31 ms 3825 ms

4)
2. 3554 ms 3214 ms 31 ms 3670 ms

3. 3448 ms 3185 ms 31 ms 3934 ms

4. 3417 ms 3347 ms 31 ms 3950 ms

5. 3449 ms 3214 ms 31 ms 3887 ms

3516 ms 3210 ms 31 ms 3853 ms

Moy
0.058 min 0.053 min 0.00051 min 0.064 min

1. 6755 ms 7020 ms 125 ms 25 628 ms

5)
2. 6914 ms 6991 ms 49 ms 14 227 ms

3. 7005 ms 7022 ms 31 ms 13 496 ms

4. 7144 ms 6989 ms 31 ms 13 928 ms

5. 7052 ms 6848 ms 31 ms 16 739 ms

6974 ms 6974 ms 53 ms 16 803 ms

Moy
0.116 min 0.116 min 0.00089 min 0.280 min

1. 17 116 ms 30 579 ms 62 ms 3164 ms

6)
2. 11 903 ms 32 826 ms 47 ms 3059 ms

3. 12 717 ms 29 670 ms 47 ms 3075 ms

4. 11 981 ms 30 249 ms 64 ms 3090 ms

5. 12 074 ms 30 144 ms 173 ms 7787 ms

13 158 ms 30 693 ms 78 ms 4035 ms

Moy
0.219 min 0.511 min 0.0013 min 0.067 min

Table 4.5 – Temps d’exécution de la base « LargeBio(medium) » avec retour de toutes les
informations

101
 Il y a une autre ontologie qu’on n’a pas mentionné ici (nommée oaei-SNOMED-extended-
overlapping-fma.owl ), elle contient 122 464 concepts et elle est la plus grande de toutes les
ontologies de la base "LargeBio", et qu’on n’a pas parvenu à l’exécuter. Nous avons estimé
que Neo4j demande plus de heap space afin de fonctionner sur de grands ensembles de don-
nées (i.e. Neo4j n’arrive pas à charger tous les triplets). Plusieurs réglages ont été faits sur
les options de JVM afin d’allouer plus de heap space. Cette allocation a permis Neo4j de
fonctionner au moins aussi longtemps avant de s’arrêter en raison d’une erreur de mémoire
insuffisante.

En fait, Noe4j stocke les données en mémoire, mais au cas où la mémoire est insuffisante,
Neo4j fera de son mieux pour charger les données (qui sont fréquemment consultées) en mé-
moire et le reste sur disque. En outre, puisque Neo4j est écrit en Java, et comme toutes les
autres applications écrites en Java, nous devons configurer la JVM pour assurer des perfor-
mances optimales.
Remarque : fournir trop de mémoire pour la JVM peut impliquer des dégradations de
performances qui sont dus aux pauses causées par les longs cycles du GC. Cela se produit
également avec un espace mémoire trop petit. Plus le heap space est grand, plus le GC pren-
dra du temps pour s’exécuter.

En somme, nous pouvons conclure que l’inférence augmente, le plus souvent, le temps du
parsing. La taille du graphe a un impact sur les performances de la BD graphique Neo4j
(elle fonctionne bien avec des données de petites quantités, mais elle reste restreinte avec
des données de grandes tailles). L’inférence est un support efficace pour le traitement des
requêtes, mais elle nécessite beaucoup d’espace de stockage pour le sauvegarde des données
inférées.

Concernant la comparaison entre le temps d’interrogation en utilisant SPARQL-DL et celui

en utilisant Cypher (par équivalence), pour des requêtes simples ainsi que pour des requêtes
compliquées, nous constatons que le temps de réponse à des requêtes Cypher est toujours
plus grand que celui à des requêtes SPARQL-DL. Cela est à cause de la correspondance des
fragments de la requête Cypher, qui consiste à déterminer s’il existe une correspondance entre
ces fragments (sous-graphes) et le graphe global dans la base de données RDF. De même, les
parcours nécessitent l’analyse de grandes parties du graphe, ce qui explique les valeurs plus
ou moins élevées des temps de réponse aux requêtes Cypher.
Nous pouvons dire aussi que ces mesures plus ou moins élevées sont dues à l’équivalence et
à la transformation des requêtes SPARQL-DL en des requêtes Cypher.

Nous remarquons également que la performance ne dégrade pas toujours par rapport à la
taille du graphe interrogé parce que, pour l’ontologie no 5, le temps de réponse à des requêtes
Cypher, est plus grand que celui des ontologies no 6, no 7 et no 8, qui sont plus grandes qu’elle
(figure 4.2). Alors, nous pouvons dire que peut être la performance d’une requête Cypher
dépend de la façon dont elle est formulée. Cela peut être due, également, au fait que les
requêtes Cypher prennent du temps à choisir un plan d’exécution favorable.

102
 Figure 4.2 – Temps de réponse aux requêtes Cypher (par équivalence)

Pour toutes les ontologies, nous avons utilisé le raisonneur Hermit, sauf pour les ontologies
no 6,no 7 et no 8, parce qu’elles nous posaient des problèmes de mémoire durant le stockage,
vu que le raisonneur infère beaucoup de nouvelles données. Cela peut expliquer les valeurs
retrouvées des temps de réponse en utilisant Cypher de ces ontologies, qui sont très courtes
en les comparant à des valeurs d’autres ontologies plus petites.

En ce qui concerne la génération et la réponse à des requêtes SPARQL-DL, les résul-

tats observés sont prévisibles. N’oublions pas que la génération de requêtes SPARQL-DL est
logiquement très coûteuse car elle s’adresse à résoudre le problème de segmentation et de
correspondance de mots-clés. Cela n’est pas le cas dans notre travail, tel que les résultats des
temps de réponse aux requêtes SPARQL-DL sont très encourageants et ils ne dépassaient
pas les milli-secondes (figure 4.3).

Finalement, nous pouvons déduire que l’augmentation de l’ensemble de données à inter-

roger, n’entraine que des diminutions de performance relativement faibles.

Figure 4.3 – Temps de réponse aux requêtes SPARQL-DL

103
 Temps parsing et stockage Temps de réponse
Ontologie No exé avec Hermit sans Hermit avec SPARQL-DL avec Cypher

1. 18 565 ms 26 581 ms 47 ms 6044 ms

7)
2. 20 263 ms 18 659 ms 31 ms 2311 ms
3. 20 426 ms 19 035 ms 15 ms 2311 ms
4. 20 216 ms 19 009 ms 95 ms 11 498 ms
5. 20 965 ms 18 833 ms 31 ms 2326 ms
20 087 ms 20 423 ms 43 ms 4898 ms
Moy
0.334 min 0.340 min 0.00073 min 0.081 min

1. 21 252 ms 19 768 ms 32 ms 3246 ms

8)
2. 21 652 ms 19 798 ms 48 ms 3343 ms
3. 19 582 ms 19 456 ms 43 ms 3213 ms
4. 19 446 ms 19 534 ms 34 ms 3163 ms
5. 18 352 ms 19 907 ms 56 ms 3243 ms
20 056 ms 19 692 ms 42 ms 3241 ms
Moy
0.334 min 0.328 min 0.00071 min 0.054 min

Table 4.6 – Temps d’exécution de la base « LargeBio(whole) » avec retour de toutes les
informations

4.4.3.2 Une seule ontologie - raffinement du résultat

Le tableau récapitulatif (tableau 4.7, page 106) englobe toutes les mesures minimales trou-
vées des temps de réponse pour chaque ontologie (i.e. « pizza », la base « Anatomy » («
mouse » et « human »), et la base LargeBio (« FMA », « NCI », et « SNOMED »)).

Nous n’avons pas recalculé les temps du parsing et du chargement parce qu’ils restent les
mêmes (que ce soit avec ou sans raisonneur). La seule chose qui diffère ici, c’est le temps de
réponse. L’utilisateur peut interagir avec le système, sans connaître la façon / le schéma dont
les données sont stockées dans la BD graphique Neo4j, il peut réduire l’espace de recherche.
Au lieu d’exécuter toutes les requêtes, ce qui entraîne le parcours d’une grande partie du
graphe RDF, l’utilisateur et en choisissant son besoin en informations, peut réduire la tra-
versée du graphe et donc le temps de réponse.

Ceci explique les mesures trouvées et qui ne diffèrent pas trop de celles de la première

104
version. Cependant, cela n’empêche qu’il y a une amélioration, comme par exemple le temps
de réponse à des requêtes Cypher à partir du graphe RDF de l’ontologie no 5 (NCI-medium),
a réduit de 16 803 ms à 9107 ms, et c’est parce que le moteur d’interrogation ne traverse
que la partie du graphe contenant le choix de l’utilisateur et non pas tout le graphe ni une
grande partie de ce dernier.

105
```
``` ms / min
```
avec SPARQL-DL avec Cypher
ontologie ```
```
63 ms 2169 ms
Pizza
0.001 min 0.036 min
31 ms 2341 ms
Human
0.0005 min 0.039 min
47 ms 2216 ms
Mouse
0.0007 min 0.036 min
48 ms 2376 ms
1. FMA-small
0.0008 min 0.039 min
25 ms 3798 ms
2. NCI-small
0.0004 min 0.063 min
47 ms 2591 ms
3. SNOMED-small
0.0007 min 0.043 min
16 ms 2514 ms
4. FMA-medium
0.0002 min 0.041 min
78 ms 9107 ms
5. NCI-medium
0.0013 min 0.151 min
94 ms 2745 ms
6. SNOMED-medium
0.0015 min 0.045 min
48 ms 3090 ms
7. FMA-whole
0.0008 min 0.051 min
79 ms 7488 ms
8. NCI-whole
0.0013 min 0.124 min

Table 4.7 – Temps de réponse minimums en utilisant les interfaces à facettes

4.4.3.3 Traitement et interrogation de plusieurs ontologies

Pour les deux ontologies FMA-small et Mouse, nous avons fait le même travail (i.e. le
parsing et le chargement dans deux BD-RDF Neo4j différentes). Nous constatons d’après le
tableau 4.8 (page 108), que le parsing et le chargement de l’ontologie FMA-small de la base

106
LargeBio, prennent plus du temps. Cela est visiblement dû au fait que FMA-small est une
ontologie plus grande que Mouse, et peut être qu’elle demande plus d’inférence.

Ces mesures ont été prises suite à l’exécution de la requête en langage naturel suivante :
"What are Sacrum MA-0001480 and Lobe-of-prostate" ; dont MA-0001480 appartient à l’on-
tologie Mouse, ainsi que Lobe-of-prostate et Sacrum sont deux entités qui appartiennent à
l’ontologie FMA-small.

D’un autre côté, le temps de génération de graphe RDF diffère d’une ontologie à une autre.
Du coup, nous pouvons trouver deux ontologies qui ont la même taille mais il y a une qui
nécessite plus du temps pour la génération de son graphe RDF. C’est parce que la première
contient, par exemple, des classes qui utilisent plusieurs propriétés d’objet et la deuxième
contient des classes qui utilisent que quelques propriétés d’objet. La génération des triplets
de la première demande forcément plus du temps que la deuxième. Cela a un impact sur le
temps global du parsing et du chargement.

Pour l’interrogation, et en comparant les temps de réponse, nous trouvons que la réponse
à partir du premier graphe (contenant les données RDF de l’ontologie FMA-small ) prend
plus du temps par rapport à la réponse à partir du deuxième graphe (contenant les triplets de
Mouse). Cela est apparemment dû au fait que le premier graphe nécessite plus de parcours,
vu qu’il est plus grand.

Nous avons expérimenté plusieurs exemples de requêtes afin d’examiner l’efficacité de

notre méthode et l’exactitude des résultats, et nous avons estimé que l’efficacité (en terme du
temps) augmente légèrement surtout quand les requêtes contiennent un nombre important
d’entités qui appartiennent à différentes ontologies (ou graphes RDF). Cela n’empêche pas
que le temps d’exécution global est satisfaisant.

107
 Temps Parsing et stockage Temps de réponse
```
```Ontologie
```
o FMA-small Mouse Graphe 1 Graphe 2
N éxecution ```
`` `

1. 8488 ms 2856 ms 16 449 ms 515 ms

2. 8331 ms 3434 ms 16 401 ms 577 ms

3. 8303 ms 2888 ms 12 408 ms 858 ms

4. 7036 ms 2904 ms 7709 ms 687 ms

5. 8441 ms 2841 ms 22 241 ms 703 ms

8119 ms 2984 ms 15 041 ms 668 ms

Moy
0.135 min 0.049 min 0.250 min 0.011 min

Table 4.8 – Temps minimums de l’interrogation des deux ontologies Mouse et «FMA-small»

4.5 L’apport de notre travail

- Utilisation de Neo4j ce qui assure une gestion persistante et efficace des données RDF.
Avec Neo4j, le fonctionnement en cluster est possible afin de répartir la charge sur plusieurs
machines. De plus, Neo4j respecte les propriétés ACID qui garantissent une transaction infor-
matique fiable. Avec Neo4j, nous pouvons gérer des milliards de données grâce à sa structure
en graphe qui s’accompagne d’une rapidité de traitement des requêtes beaucoup plus im-
portante que les SGBD classiques. En outre, Neo4j fournit un moteur puissant accessible
facilement, ainsi qu’un langage d’interrogation (Cypher) assez visuel.

- Utilisateur non-expert en langage d’interrogation, peut requêter des données structurées,

en utilisant le langage naturel.

- Notre framework est automatique tel qu’il prend en entrée n’importe quelle ontologie, avec
laquelle il produira son graphe RDF et le stocke dans Neo4j. Le graphe RDF résultant est
complet et reflète fidèlement la sémantique décrite dans l’ontologie.

- Notre méthode est solide et exhaustive, dans le sens qu’elle est complète car elle retourne
toutes les réponses correctes à une requête en langage naturel, et elle est également saine

108
parce qu’elle ne retourne que des réponses correctes à une requête utilisateur.

- Nous donnons la possibilité à l’utilisateur de choisir son besoin en information grâce à un

dialogue / une interaction Homme-Machine, et également de choisir avec quel langage il sou-
haite avoir ses résultats.

- Nous donnons la possibilité aux développeurs de pouvoir changer de base de données. Ceci
se fait grâce à l’équivalence qui nous permet d’implémenter l’architecture de notre système
au-dessus d’une grande variété de BD-RDF implémentant leurs langages d’interrogation, sans
changer aucun des autres composants du système.

- Nous avons étudié sur les interprétations possibles et souhaitées de la requête utilisateur,
afin de mieux le satisfaire. Cela se fait en effectuant toutes les différentes liaisons possibles
entre les entités initialement fournies par l’utilisateur.

- Possibilité d’interroger l’ontologie directement (avec des requêtes SPARQL-DL), et / ou

son graphe RDF dans Neo4j (avec des requêtes Cypher).

- Temps d’exécution très court et résultats très encourageants.

4.6 Conclusion
Dans ce chapitre, nous avons décrit une étude expérimentale menée avec notre méthode
proposée pour l’interrogation des graphes RDF. La solution proposée cherche à contourner
le problème de la taille des ensembles de concepts pris comme une entrée pour l’outil d’inter-
rogation. La solution offerte par Neo4j dépasse parfois sa capacité de stockage. Les mesures
des temps d’exécution prouvent l’efficacité de notre méthode et l’exactitude des résultats
retournés.

109
Conclusion Générale

La nécessité de gérer des données structurées et annotées sémantiquement, d’une manière

efficace, se fait de plus en plus pressante.
La gestion des données RDF, leur maintenance et le raisonnement qui se fait dessus, sont de-
venus des travaux coûteux et même irréalisables. Alors, il est devenu indispensable de fournir
des solutions pour le stockage des données RDF et l’interrogation pertinente de ces dernières.

Une revue sur quelques méthodes existantes, nous a permis de mettre en relief les exigences
des utilisateurs non-experts en termes de stockage et de formulation de requêtes significatives
avec des langages d’interrogation hautement spécifiques tels que SPARQL.

Dans ce contexte, nous avons développé une méthode pour un stockage et une interroga-
tion efficaces des données RDF. Cette approche permet aux utilisateurs finaux d’interroger
des bases de connaissances et des graphes RDF. L’approche guide l’interprétation de la ques-
tion utilisateur formulée en langage naturel, ainsi que sa traduction en langage formel.

Le but des travaux, qui ont été réalisés dans le cadre de ce mémoire, est de proposer une
nouvelle approche d’interrogation d’ontologies (qui sont elle-mêmes stockées sous forme de
graphes RDF, dans la base de données graphique Neo4j ). Cette méthode devrait surpas-
ser certains handicaps tels que le volume de données, la langue naturelle, l’hétérogénéité qui
explique que les informations et les connaissances peuvent provenir de sources différentes, etc.

L’utilisation de bases de données graphiques montre plusieurs avantages, tels qu’elles im-
plémentent leurs langages d’interrogation, des interfaces de programmation (API), etc. Elles
fournissent également un moyen efficace permettant de représenter des informations inter-
connectées ainsi de décrire des structures de données complexes.

Nous avons mené une étude expérimentale afin de démontrer la pertinence et l’efficacité
de notre approche en termes du temps d’exécution et d’exactitude de résultats.

Perspectives :

- Bien que les résultats expérimentaux soient très encourageants, le problème du passage à
l’échelle a un impact sur la performance des systèmes qui réalisent les travaux de stockage et
d’interrogation, en particulier Neo4j. De même, puisque la quantité de données RDF continue
à augmenter, il n’est plus possible de stocker ni d’accéder à toutes ces données sur une seule

110
machine, tout en assurant des performances raisonnables. Alors, il est nécessaire d’améliorer
les capacités de notre algorithme de stockage et d’interrogation, par l’adoption de paradigmes
de distribution (Spark Streaming).

- Améliorer la phase d’intégration de WordNet par l’ajout des hyperonymes et des hypo-
nymes.

111
Bibliographie

[Allani et al., 2016] Allani, S., Yeferny, T., Chbeir, R., and Ben Yahia, S. (2016). Dpms :
A swift data dissemination protocol based on map splitting. In 2016 IEEE 40th Annual
Computer Software and Applications Conference (COMPSAC), volume 1, pages 817–822.
IEEE.
[Allocca et al., 2016] Allocca, C., Adamou, A., d’Aquin, M., and Motta, E. (2016). Sparql
query recommendations by example. In International Semantic Web Conference, pages
128–133. Springer.
[Angles, 2012] Angles, R. (2012). A comparison of current graph database models. In Data
Engineering Workshops (ICDEW), 2012 IEEE 28th International Conference on, pages
171–177. IEEE.
[Arenas et al., 2016] Arenas, M., Grau, B. C., Kharlamov, E., Marciuška, Š., and Zheleznya-
kov, D. (2016). Faceted search over rdf-based knowledge graphs. Web Semantics : Science,
Services and Agents on the World Wide Web, 37 :55–74.
[Ayouni et al., 2011] Ayouni, S., Ben Yahia, S., and Laurent, A. (2011). Extracting compact
and information lossless sets of fuzzy association rules. Fuzzy Sets and Systems, 183(1) :1–
25.
[Baas, 2012] Baas, B. (2012). Nosql spatial. Master’s thesis, Universiteit Utrecht.
[Barrasa, 2017] Barrasa, J. (2017). Rdf triple stores vs. labeled property graphs.
[Ben Yahia and Jaoua, 2000] Ben Yahia, S. and Jaoua, A. (2000). A top-down approach for
mining fuzzy association rules. In Proc. 8th Int. Conf. Information Processing Management
of Uncertainty Knowledge-Based Systems, pages 952–959.
[Brahmi et al., 2012] Brahmi, H., Brahmi, I., and Ben Yahia, S. (2012). Omc-ids : at the
cross-roads of olap mining and intrusion detection. In Pacific-Asia Conference on Know-
ledge Discovery and Data Mining, pages 13–24. Springer.
[Buerli and Obispo, 2012] Buerli, M. and Obispo, C. (2012). The current state of graph
databases. Department of Computer Science, Cal Poly San Luis Obispo, mbuerli@ calpoly.
edu, 32(3) :67–83.
[Campinas et al., 2012] Campinas, S., Perry, T. E., Ceccarelli, D., Delbru, R., and Tum-
marello, G. (2012). Introducing rdf graph summary with application to assisted sparql
formulation. In Database and Expert Systems Applications (DEXA), 2012 23rd Interna-
tional Workshop on, pages 261–266. IEEE.

112
[Ciglan et al., 2012] Ciglan, M., Averbuch, A., and Hluchy, L. (2012). Benchmarking traversal
operations over graph databases. In Data Engineering Workshops (ICDEW), 2012 IEEE
28th International Conference on, pages 186–189. IEEE.
[Corcho, 2004] Corcho, O. (2004). A Layered Declarative Approach to Ontology Translation
with Knwoledge Preservation. PhD thesis.
[Djeddi et al., 2014] Djeddi, W. E., Khadir, M. T., and Ben Yahia, S. (2014). Xmap++ :
results for oaei 2014. In OM, pages 163–169. Citeseer.
[Elbassuoni and Blanco, 2011] Elbassuoni, S. and Blanco, R. (2011). Keyword search over
rdf graphs. In Proceedings of the 20th ACM international conference on Information and
knowledge management, pages 237–242. ACM.
[et Claudio Gutierrez, 2008] et Claudio Gutierrez, R. A. (2008). Survey of graph database
models. ACM Computing Surveys (CSUR).
[Fu and Anyanwu, 2011] Fu, H. and Anyanwu, K. (2011). Effectively interpreting keyword
queries on rdf databases with a rear view. The Semantic Web–ISWC 2011, pages 193–208.
[Gasmi et al., 2006] Gasmi, G., Ben Yahia, S., Nguifo, E. M., and Slimani, Y. (2006). Igb :
une nouvelle base générique informative des regles d’association. Revue I3 (Information-
Interaction-Intelligence), 6(1) :31–67.
[Guarino et al., 2009] Guarino, N., Oberle, D., and Staab, S. (2009). What is an ontology ?
In Handbook on ontologies, pages 1–17. Springer.
[Hamdi et al., 2013] Hamdi, S., Bouzeghoub, A., Gancarski, A. L., and Ben Yahia, S. (2013).
Trust inference computation for online social networks. In 2013 12th IEEE International
Conference on Trust, Security and Privacy in Computing and Communications, pages
210–217. IEEE.
[Hamdi et al., 2012] Hamdi, S., Gancarski, A. L., Bouzeghoub, A., and Ben Yahia, S. (2012).
Iris : A novel method of direct trust computation for generating trusted social networks.
In 2012 IEEE 11th International Conference on Trust, Security and Privacy in Computing
and Communications, pages 616–623. IEEE.
[Hamdi et al., 2016] Hamdi, S., Gancarski, A. L., Bouzeghoub, A., and Ben Yahia, S. (2016).
Tison : Trust inference in trust-oriented social networks. ACM Transactions on Information
Systems (TOIS), 34(3) :1–32.
[Hammoud et al., 2015] Hammoud, M., Rabbou, D. A., Nouri, R., Beheshti, S.-M.-R., and
Sakr, S. (2015). Dream : distributed rdf engine with adaptive query planner and minimal
communication. Proceedings of the VLDB Endowment, 8(6) :654–665.
[Hamrouni et al., 2006] Hamrouni, T., Ben Yahia, S., and Nguifo, E. M. (2006). Succinct
system of minimal generators : A thorough study, limitations and new definitions. In In-
ternational Conference on Concept Lattices and Their Applications, pages 80–95. Springer.
[Hamrouni et al., 2010] Hamrouni, T., Ben Yahia, S., and Nguifo, E. M. (2010). Genera-
lization of association rules through disjunction. Annals of Mathematics and Artificial
Intelligence, 59(2) :201–222.
[Hamrouni et al., 2013] Hamrouni, T., Ben Yahia, S., and Nguifo, E. M. (2013). Looking
for a structural characterization of the sparseness measure of (frequent closed) itemset
contexts. Information Sciences, 222 :343–361.

113
[Hamrouni et al., 2005] Hamrouni, T., Ben Yahia, S., and Slimani, Y. (2005). Avoiding the
itemset closure computation “pitfall”. In CLA, volume 2005, pages 46–59.
[Hartig et al., 2009] Hartig, O., Bizer, C., and Freytag, J.-C. (2009). Executing sparql queries
over the web of linked data. The Semantic Web-ISWC 2009, pages 293–309.
[Hartig and Heese, 2007] Hartig, O. and Heese, R. (2007). The sparql query graph model for
query optimization. The Semantic Web : Research and Applications, pages 564–578.
[Huang et al., 2011] Huang, J., Abadi, D. J., and Ren, K. (2011). Scalable sparql querying
of large rdf graphs. Proceedings of the VLDB Endowment, 4(11) :1123–1134.
[Jelassi et al., 2014] Jelassi, M. N., Largeron, C., and Ben Yahia, S. (2014). Efficient unveiling
of multi-members in a social network. Journal of Systems and Software, 94 :30–38.
[Jouili and Vansteenberghe, 2013] Jouili, S. and Vansteenberghe, V. (2013). An empirical
comparison of graph databases. In Social Computing (SocialCom), 2013 International
Conference on, pages 708–715. IEEE.
[Jridi, 2014] Jridi, M. A. (2014). Proposition d’une nouvelle méthode d’alignement d’onto-
logies distribué. Master’s thesis, Faculté des sciences de Tunis.
[Kachroudi et al., 2017] Kachroudi, M., Diallo, G., and Ben Yahia, S. (2017). Oaei 2017
results of KEPLER. In OM@ ISWC, pages 138–145.
[Kachroudi et al., 2011] Kachroudi, M., Moussa, E. B., Zghal, S., and Ben Yahia, S. (2011).
Ldoa results for oaei 2011. In Proceedings of the 6th International Conference on Ontology
Matching-Volume 814, pages 148–155. CEUR-WS. org.
[Kollia et al., 2011] Kollia, I., Glimm, B., and Horrocks, I. (2011). Sparql query answering
over owl ontologies. The Semantic Web : Research and Applications, pages 382–396.
[Lacot, 2005] Lacot, X. (2005). Introduction à owl, un langage xml d’ontologies web.
[Lissandrini et al., 2017] Lissandrini, M., Brugnara, M., and Velegrakis, Y. (2017). An eva-
luation methodology and experimental comparison of graph databases.
[MAILLOT, 2015] MAILLOT, P. (2015). Nouvelles méthodes pour l’évaluation, l’évolution
et l’interrogation des bases du Web des données. PhD thesis, Université de Nantes Angers
Le Mans.
[Makris et al., 2012] Makris, K., Bikakis, N., Gioldasis, N., and Christodoulakis, S. (2012).
Sparql-rw : transparent query access over mapped rdf data sources. In Proceedings of the
15th International Conference on Extending Database Technology, pages 610–613. ACM.
[Morsey et al., 2011] Morsey, M., Lehmann, J., Auer, S., and Ngomo, A.-C. N. (2011). Db-
pedia sparql benchmark–performance assessment with real queries on real data. In Inter-
national Semantic Web Conference, pages 454–469. Springer.
[Mouakher and Ben Yahia, 2016] Mouakher, A. and Ben Yahia, S. (2016). Qualitycover : Ef-
ficient binary relation coverage guided by induced knowledge quality. Information Sciences,
355 :58–73.
[Nguyen et al., ] Nguyen, M. D., Lee, M. S., Oh, S., and Fox, G. C. Sparql query optimization
for structural indexed rdf data.

114
[Papailiou et al., 2014] Papailiou, N., Tsoumakos, D., Konstantinou, I., Karras, P., and Ko-
ziris, N. (2014). H 2 rdf+ : an efficient data management system for big rdf graphs. In
Proceedings of the 2014 ACM SIGMOD international conference on Management of data,
pages 909–912. ACM.
[PELAP, 2016] PELAP, G. F. (2016). Conception d’un framework pour la relaxation des re-
quêtes SPARQL. PhD thesis, École Nationale Supérieure de mécanique et d’aérotechnique.
[Pradel et al., 2013] Pradel, C., Haemmerlé, O., and Hernandez, N. (2013). Passage de la
langue naturelle à une requête sparql dans le système swip. In IC-24èmes Journées fran-
cophones d’Ingénierie des Connaissances.
[Quilitz and Leser, 2008] Quilitz, B. and Leser, U. (2008). Querying distributed rdf data
sources with sparql. In European Semantic Web Conference, pages 524–538. Springer.
[Rashmi Dudhani, 2016] Rashmi Dudhani, C. K. (2016). A sparql query generation mecha-
nism on rdf. International Journal of Computer Science and Mobile Computing.
[Rohloff et al., 2007] Rohloff, K., Dean, M., Emmons, I., Ryder, D., and Sumner, J. (2007).
An evaluation of triple-store technologies for large data stores. In On the Move to Mea-
ningful Internet Systems 2007 : OTM 2007 Workshops, pages 1105–1114. Springer.
[Samet et al., 2014] Samet, A., Lefevre, E., and Ben Yahia, S. (2014). Mining frequent item-
sets in evidential database. In Knowledge and Systems Engineering, pages 377–388. Sprin-
ger.
[Samet et al., 2016] Samet, A., Lefèvre, E., and Ben Yahia, S. (2016). Evidential data
mining : precise support and confidence. Journal of Intelligent Information Systems,
47(1) :135–163.
[Sareh Aghaei and Farsani, 2012] Sareh Aghaei, M. A. N. and Farsani, H. K. (2012). EVO-
LUTION OF THE WORLD WIDE WEB : FROM WEB 1.0 TO WEB 4.0. International
Journal of Web and Semantic Technology (IJWesT) Vol.3, No.1.
[Shekarpour et al., 2015] Shekarpour, S., Marx, E., Ngomo, A.-C. N., and Auer, S. (2015).
Sina : Semantic interpretation of user queries for question answering on interlinked data.
Web Semantics : Science, Services and Agents on the World Wide Web, 30 :39–51.
[Stegmaier et al., 2009] Stegmaier, F., Gröbner, U., Döller, M., Kosch, H., and Baese, G.
(2009). Evaluation of current rdf database solutions. In Proceedings of the 10th In-
ternational Workshop on Semantic Multimedia Database Technologies (SeMuDaTe), 4th
International Conference on Semantics And Digital Media Technologies (SAMT), pages
39–55.
[Trabelsi et al., 2010] Trabelsi, C., Jrad, A. B., and Ben Yahia, S. (2010). Bridging folk-
sonomies and domain ontologies : Getting out non-taxonomic relations. In 2010 IEEE
International Conference on Data Mining Workshops, pages 369–379. IEEE.
[Tzoganis et al., 2009] Tzoganis, G., Koutsomitropoulos, D., and Papatheodorou, T. S.
(2009). Querying ontologies : Retrieving knowledge from semantic web documents. In
Proc. of the 3d Panhellenic Student Conference on Informatics, Related Technologies and
Applications.

115
[Unger et al., 2012] Unger, C., Bühmann, L., Lehmann, J., Ngonga Ngomo, A.-C., Gerber,
D., and Cimiano, P. (2012). Template-based question answering over rdf data. In Procee-
dings of the 21st international conference on World Wide Web, pages 639–648. ACM.
[Wang et al., 2008] Wang, H., Zhang, K., Liu, Q., Tran, T., and Yu, Y. (2008). Q2semantic :
A lightweight keyword interface to semantic search. The Semantic Web : Research and
Applications, pages 584–598.
[Yahya et al., 2012] Yahya, M., Berberich, K., Elbassuoni, S., Ramanath, M., Tresp, V., and
Weikum, G. (2012). Natural language questions for the web of data. In Proceedings
of the 2012 Joint Conference on Empirical Methods in Natural Language Processing and
Computational Natural Language Learning, pages 379–390. Association for Computational
Linguistics.
[Younes et al., 2010] Younes, N. B., Hamrouni, T., and Ben Yahia, S. (2010). Bridging
conjunctive and disjunctive search spaces for mining a new concise and exact represen-
tation of correlated patterns. In International Conference on Discovery Science, pages
189–204. Springer.
[Zghal, 2010] Zghal, S. (2010). Contributions à l’alignement d’ontologies OWL par agrégation
de similarités. PhD thesis, ISG Tunis, Tunisie.
[Zghal et al., 2007a] Zghal, S., Ben Yahia, S., Nguifo, E. M., and Slimani, Y. (2007a). Soda :
an owl-dl based ontology matching system. In Proceedings of the 2nd International Confe-
rence on Ontology Matching-Volume 304, pages 261–267. CEUR-WS. org.
[Zghal et al., 2007b] Zghal, S., Ben Yahia, S., Nguifo, E. M., and Slimani, Y. (2007b). Soda :
Une approche structurelle pour l’alignement d’ontologies owl-dl. ZFO.
[Zheng et al., 2016] Zheng, W., Zou, L., Peng, W., Yan, X., Song, S., and Zhao, D. (2016).
Semantic sparql similarity search over rdf knowledge graphs. Proceedings of the VLDB
Endowment, 9(11) :840–851.
[Zou et al., 2014] Zou, L., Huang, R., Wang, H., Yu, J. X., He, W., and Zhao, D. (2014).
Natural language question answering over rdf : a graph data driven approach. In Procee-
dings of the 2014 ACM SIGMOD international conference on Management of data, pages
313–324. ACM.

116
Résumé :

Ce travail est accompli dans le cadre d’un projet de mémoire de recherche. L’objectif est
de générer des requêtes SPARQL en se basant sur des mots-clés fournis par l’utilisateur, afin
d’interroger des graphes RDF. Pour ce faire, nous avons, tout d’abord, transformé l’ontologie
d’entrée en un graphe RDF qui reflète la sémantique représentée dans l’ontologie. Par la suite,
nous avons stocké ce graphe RDF dans la base de données graphique Neo4j, afin d’assurer
une gestion efficace et persistante des données RDF. Au moment de l’interrogation, nous
avons étudié les différentes interprétations possibles et souhaitées de la requête initialement
formulée par l’utilisateur. Nous avons proposé également d’effectuer une sorte de transfor-
mation entre les deux langages d’interrogation SPARQL et Cypher, qui est propre à Neo4j.
Ceci nous permet d’implémenter l’architecture de notre système au-dessus d’une grande va-
riété de BD-RDF fournissant leurs langages d’interrogation, sans changer aucun des autres
composants du système. Enfin, nous avons testé et évalué notre outil à l’aide de différentes
bases de test, et il s’est avéré que notre outil est exhaustive, efficace, et assez performant.

Mot clés : Ontologie, Graphe RDF, Interrogation des ontologies, Interrogation des graphes
RDF, Langages d’interrogation, Bases de données graphiques, Génération de requêtes, Triples
Stores.

Abstract :

This work is done as part of a research master’s thesis project. The goal is to generate
SPARQL queries based on user-supplied keywords to query RDF graphs. To do this, we first
transformed the input ontology into an RDF graph that reflects the semantics represented
in the ontology. Subsequently, we stored this RDF graph in the Neo4j graphical database to
ensure efficient and persistent management of RDF data. At the time of the interrogation,
we studied the different possible and desired interpretations of the request originally made by
the user. We have also proposed to carry out a sort of transformation between the two query
languages SPARQL and Cypher, which is specific to Neo4j. This allows us to implement the
architecture of our system over a wide variety of BD-RDFs providing their query languages,
without changing any of the other components of the system. Finally, we tested and evaluated
our tool using different test bases, and it turned out that our tool is comprehensive, effective,
and powerful enough.

Keywords : Ontology, RDF Graph, Query ontologies, Query RDF Graphs, Query Lan-
guages, Graphical Databases, Query Generation, Triples Stores.