thesis

UNIVERSITÉ NATIONALE DU VIETNAM À HANO¨I
INSTITUT FRANCOPHONE INTERNATIONAL
UNIVERSITÉ DE LA ROCHELLE
Mémoire de fin d’études
MASTER DE RECHERCHE EN INFORMATIQUE
OPTION : SYSTÈMES INTELLIGENTS ET MULTIMÉDIA
DÉVELOPPEMENT D’UN SYSTÈME
CONNAISANCES POUR BIG DATA
APPLICATION AUX DONNÉES DE
PHÉNOTYPAGE CHEZ LE RIZ
(O. SATIVA)
Rédigé par : LE Ngoc Luyen
Promotion: XVIII
Sous l’encadrement de:
Dr Pierre LARMANDE, Ingénieur IRD, Responsable de l’axe intégration de données de l’IBC
Anne TIREAU, Ingénieur INRA à Montpellier SupAgro
Montpellier, septembre 2015

Remerciements
Je tiens à remercier dans un premier temps, toute l’équipe pédagogique de l’Institut Francophone
International (IFI) de Hano¨ı et les intervenants professionnels responsable de la formation en master de
recherche en informatique, pour avoir assuré la partie théorique de celle-ci.
Je tiens à exprimer toute ma reconnaissance à M. Pierre LARMANDE qui est chercheur à l’IRD et
Reponsbale de l’axe de données de l’Institut de Biologie Computationnelle, Mme. Anne TIREAU qui est
ingénieur à l’INRA Montpellier SupAgro dans l’UMR MISTEA, pour leur encardrement sans faille, le
suivi qu’ils ont apporté à mon stage, leurs conseils, les nombreuses discussions que nous avons pu avoir
tout au long de la réalisation de ce stage, aussi pour l’inspiration et pour le temps qui’ils ont bien voulu
me consacrer.
Je souhaite remercie la famille de Pierre LARMANDE et la famille Fran¸cois PHAN pour leurs aides
chaleureuses pendant mon séjour de six mois en France.
Je tiens à remercie également Mlle Caroline BENOIST secrétaire du LIRMM, et Mlle NGUYEN Thi
Van Tu, secrétaire de l’IFI pour ses aides à plusieurs reprises.
Depuis mes premiers jours dans cet institut, j’ai re¸cu beaucoup d’aides, de conseils et d’encourage-
ments de mes amis, en particulier ceux de la promotion 18. Tout cela m’a permis de murir chaque jour.
Je les remercie et je ne pourrais jamais oublier les souvenirs gais et tristes que j’ai passé avec eux durant
ces deux ans à l’IFI.
Je voudrais aussi remercier aussi les confrères de l’Université de Da Lat où je suis en train de travailler,
qui m’ont donné les meilleures conditions pour que je puisse bien passer ma scolarité à l’IFI.
Enfin, j’adresse mes plus sincères remerciements à mes parents, mes frères qui m’a toujours soutenue
et encouragée dans les moments les plus difficiles de ma scolarité à l’IFI.
Merci à tous et à toutes
LE Ngoc Luyen
Da Lat - Viet Nam, automne 2015
i

Résumé
Depuis quelques années, le déluge de données dans plusieurs domaines de la recherche scientifique
soulève des défis dans le traitement et l’exploitation des données. La recherche dans le domaine bioinforma-
tique n’est pas épargnée par ce phénomène. Ce mémoire présente des approches pour résoudre le problème
de données volumineuses stockées dans des entrepôts NoSQL en y associant la capacité de recherche
sémantique sur les données dans un contexte de recherche agronomique. Ces approches sémantiques
permettent d’aider à enrichir les données issues d’expériences grâce aux moteurs d’inférence générant
de nouvelles connaissances. Nous pouvons résumer ces deux approches d’une part avec la réécriture de
requêtes et d’autre part avec la matérialisation de données en triplets RDF. Un état de l’art nous a
permis d’identifier et d’évaluer les différentes méthodes se rapportant aux approches mentionnées. En
pratique, seule l’approche de matérialisation de données a été choisie pour continuer à travailler. Les
données triplets obtenues étant volumineuses, nous avons réalisé un benchmark sur différents systèmes
de gestion de base de données de triplets afin de pouvoir comparer les avantages et les inconvénients de
chacun et de choisir le meilleur système pour notre étude de cas.
Mot-clés : Base de connaissance, Ontologie, Raisonnement, Inférence, SPARQL, xR2RML, Bench-
mark, NoSql, BigData, TripleStore
ii

Abstract
In the recent years, the data deluge in many areas of scientific research brings challenges in the treat-
ment and improvement of farm data. Research in bioinformatics field does not outside this trend. This
thesis presents some approaches aiming to solve the big Data problem by combining the increase in se-
mantic search capacity on existing data in the plant research laboratories. This helps us to strengthen user
experiments on the data obtained in this research by the engine automatic inference of new knowledge.
To achieve this, each approach has different characteristics and using different platforms. Nevertheless,
we can summarize it in two main directions : the transformation of query or Re-write requests and data
transformation to triples. In reality, we can solve the problem from origin of increasing capacity on seman-
tic data with triplets. Thus, the triplets to data transformation direction is chosen to continue working
in the practical part. However, the synchronization data in the same format is required before processing
the triplets because our current data are heterogeneous. The data obtained for triplets are larger that
regular triplestore could manage. So we evaluate some of them thus we can compare the benefits and
drawbacks of each and choose the best system for our problem.
Keyworks : Knowledge base, Ontology, Reasoning, Inference, SPARQL, xR2RML, Benchmark, NoSQL,
Big Data, Triplestore
iii

Table des matières
Remerciements i
Résumé ii
Abstract iii
Table des matières iv
Liste d’abréviations vi
Table des figures vii
Liste des tableaux ix
INTRODUCTION 1
Chapitre 1 Présentation Générale 2
1.1 Présentation de l’établissement d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Présentation de l’Institut de Biologie Computationelle (IBC) . . . . . . . . . . . . 2
1.1.2 Présentation de l’Institut National de la Recherche Agronomique (INRA) . . . . . 3
1.2 Description du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Contexte de données massives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Contexte de recherche sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapitre 2 État de l’art 11
2.1 Existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Analyse et évaluation des solutions courantes . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 MongoGraph - une association du Mongodb et AllegroGraph . . . . . . . . . . . . 11
2.2.2 Base de données orientée graphe Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 JSON for Linking Data (JSON-LD) et MongoDB . . . . . . . . . . . . . . . . . . . 16
2.2.4 Ontology-Based Data Access (ODBA) et frameworks Ontop . . . . . . . . . . . . . 18
2.2.5 Matérialisation de données en triplets RDF . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapitre 3 Solution proposée 23
iv

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Modèle général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Transformation et synchronisation de données dans MongoDB . . . . . . . . . . . . . . . . 24
3.4 Ontologies et domaine applicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 xR2RML et Transformation de données en triplets . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1 Le langage de mapping de données xR2RML . . . . . . . . . . . . . . . . . . . . . 27
3.5.2 Transformation de données en triplets . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapitre 4 Stockage et Indexation de données RDF 31
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Approche native et non-native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Vue générale des systèmes de gestion de triplets . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 TripleStore Sesame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2 TripleStore 4Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.3 TripleStore Virtuoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.4 TripleStore Jena Fuseki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.5 TripleStore Stardog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.6 TripleStore GraphDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapitre 5 Expérimentation, Comparaison et Analyse 42
5.1 Préparation des données et du Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Benchmarking des platformes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Chargement de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.2 Recherche de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.3 Inférence sur les données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Evaluation et Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
CONCLUSION 53
RÉFÉRENCES 55
Annexe A Modèle de document JSON A.1
Annexe B Mappage de données JSON aux triplets par xR2RML B.5
Annexe C Point d’accès C.8

Liste d’abr´eviations
API Application Programming Interface
CRUD Create, Read, Update, Delete
D2R Database To RDF
DFS Distributed ﬁles system
DL Logiques de Description
IBC Institut de Biologie Computationelle
INRA Institut National de la Recherche Agronomique
JSON Javascript Object Notation
JSON-LD JSON for Linking Data
NoSQL Not Only SQL
ODBA Ontology-Based Data Access
OWL Web Ontology Language
OWL 2 RL Web Ontology Rule Language
R2RML Relational Databases to RDF Mapping Language
RDF Resource Description Framework
RDFS Resource Description Framework Schema
RML RDF Mapping Language
SPARQL Protocol and RDF Query Langage
SQL Structured Query Language
W3C World Wide Web Consortium
xR2RML Relational and Non-Relational Databases to RDF Mapping Language
vi

Liste des figures
1.1 L’architecture du web sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 L’exemple d’un triplet Resource Description Framework (RDF). . . . . . . . . . . . . . . . 8
1.3 L’exemple d’une requête Protocol and RDF Query Langage (SPARQL). . . . . . . . . . . 8
2.1 Le modèle de composants dans un système MongoGraph . . . . . . . . . . . . . . . . . . . 12
2.2 Les données présentées dans cet exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Une requête SPARQL associée à une requête de MongoDB . . . . . . . . . . . . . . . . . . 14
2.4 La graphe de données dans Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Les commandes pour créer un graphe simple . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Les triplets sont stockées dans MongoDB sous la forme de JSON-LD . . . . . . . . . . . . 17
2.7 Le modèle de composants dans un système d’association de MongoDB et JSON-LD –
Create, Read, Update, Delete (CRUD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Le processus de requête dans le système d’ODBA . . . . . . . . . . . . . . . . . . . . . . . 19
2.9 La comparaison des approches des raisonnements dans une application . . . . . . . . . . . 19
2.10 L’architecture du système avec l’association de MongoDB et le modèle d’ODBA . . . . . . 20
2.11 Les deux tables et sa relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.12 Les informations définies pour le mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.13 Les données RDF après de la transformation . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Le modèle général du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Le modèle JSON créé à partir des bases d’imageries . . . . . . . . . . . . . . . . . . . . . 25
3.3 L’ontologie de l’annotation d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Un exemple de données dans MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Le triplet généré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Le mapping de xR2RML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Le Mapping de données JSON en triplets . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 La classificaiton des types de système de stockage RDF . . . . . . . . . . . . . . . . . . . 32
4.2 Les composants dans l’architecture de Sesame . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 L’architecture principale de 4Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 L’architecture générale de Virtuoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Les composants dans l’architecture de Jena . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Les composants dans l’architecture de GraphDB . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 L’interface du système d’interaction avec les données RDF . . . . . . . . . . . . . . . . . . 39
vii

5.1 La comparaison du temps de chargement sur différents TripleStores . . . . . . . . . . . . . 43
5.2 L’exemple de requête numéro 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 L’evaluation de la requête numéro 1 sous forme de courbe graphique . . . . . . . . . . . . 44
5.4 L’exemple de requêtes numéro 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.6 L’exemple de requête numéro 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 L’exemple de troisième requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.10 Les relations inférées sur l’ontologie dans le premier exemple . . . . . . . . . . . . . . . . . 48
5.11 La requête du première exemple d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.12 Le temps d’exécution de la première inférence sous forme de graphique . . . . . . . . . . . 49
5.13 Les relations inférées sur l’ontologie dans le deuxième exemple d’inférence . . . . . . . . . 49
5.14 L’exemple de la deuxième inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.15 Le temps d’exécution de la deuxième inférence sous forme de graphique . . . . . . . . . . 50

Liste des tableaux
1.1 La liste des types et des système de gestion de base de données dans Not Only SQL (NoSQL) 7
4.1 Les TripleStores et le type de stockage supporté . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Les encodages spéciaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Les comparaison de certaines fonctionnalités des différents TripleStores . . . . . . . . . . . 40
5.1 La configuration du serveur expérimental . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 La comparaison du temps de chargement sur différents TripleStores en millisecondes . . . 43
5.3 L’evaluation de la requête numéro 1 (temps en millisecondes) . . . . . . . . . . . . . . . . 44
5.7 L’evaluation de la première inférence (temps en millisecondes) . . . . . . . . . . . . . . . 49
5.8 L’evaluation de la deuxième inférence (temps en millisecondes) . . . . . . . . . . . . . . . 50
C.1 Les exemples de point d’accès de TripleStore . . . . . . . . . . . . . . . . . . . . . . . . . C.8
ix

Introduction
Les études sur les plantes ont toujours pris un rôle important pour améliorer la productivité, la capacité
de résistance des plantes aux maladies, la réduction d’influence des changements de l’environnement et le
climat. Aujourd’hui, de plus en plus de laboratoires ont effectué des études sur les plantes et ont obtenus
des résultats importants. Les données de ces études sont des ressources utiles pour que les scientifiques
puissent les exploiter et les partager avec les autres. Aujourd’hui, il y existe une diversité d’outils qui sont
développés pour gérer ces données. Mais chaque étude possède des caractéristiques différentes qui sont
difficiles à capturer dans des applications génériques. De plus, ces données ne cessent d’augmenter dans
chaque jour. Les tâches de gestion de données demandent des méthodes d’organisation optimisées.
Dans la carde du sujet de stage, deux projets d’études sur les plantes sont réalisés dans deux labora-
toires differents. L’un fait la recherche sur le phénotypage et le génotypage du riz asiatique. L’autre fait
la recherche sur le phénotypage et le génotypage du ma¨ıs en France. La caractéristique commune entre
ces deux projets concerne la gestion et l’exploitation de gros volumes de données de manière plus efficace.
Les travaux dans ce stage se focaliseront sur la recherche de solutions associant les domaines du web
sémantique et celui des données massives. Ils nous permettront de chercher la meilleure solution possible
pour tout d’abord organiser le stockage des données massives et volumineuses dans un système de gestion
de base données spécialisé et ensuite renforcer la capacité de recherche sémantique des données afin de
générer de nouvelles connaissances. Les connaissances dans le domaine de web sémantique fournissent des
modèles pour structurer les données sous la forme de bases de reconnaissance et permettent la recherche
de données grâce a des mécanismes de d’inférence et de raisonnement. Aujourd’hui, le problème de gestion
de données massives a besoin de traiter avec l’optimisation du temps d’exécution et le temps de recherche.
Ce présent rapport se divise en cinq grandes parties. La première partie présente les deux laboratoires
IBC et INRA, leurs projets de recherche actuels, les problématiques du stage et les concepts existants
dans le domaine du web sémantique et des données massives. La deuxième partie fait un état de l’art
sur les solutions actuelles et leurs applications dans le cas de nos données. La troisième partie consiste à
présenter la solution proposée et les travaux mis en oeuvre pour la réaliser. La quatrième partie présente les
systèmes de gestion de base de données de triplets actuels. La cinquième partie concerne l’expérimentation,
la comparaison et l’analyse des résultats dans un benchmark de ces systèmes selon trois critères : le
chargement de données, la recherche de données et l’inférence de données.
1

Chapitre 1
Présentation Générale
1.1 Présentation de l’établissement d’accueil
1.1.1 Présentation de l’IBC
L’Institut de Biologie Computationnelle a été créée dans le but de développer des méthodes inno-
vantes et des logiciels pour analyser, intégrer et contextualiser les données biologiques massives dans les
domaines de la santé, de l’agronomie et de l’environnement. Plusieurs branches de recherche y sont com-
binées : l’algorithmique (combinatoire, numérique, massivement parallèle, stochastique), la modélisation
(discrète, qualitative, quantitative, probabiliste), et la gestion des données (intégration, workflows, cloud).
Les concepts et les outils seront validés à l’aide des applications clés en biologie fondamentale (transcrip-
tomique, la structure et la fonction des protéines, le développement et la morphogenèse), la santé (agents
pathogènes, le cancer, les cellules souches), l’agronomie (génomique des plantes, de l’agriculture tropicale),
et de l’environnement (dynamique des populations, biodiversité). L’IBC est divisé en cinq work-packages
qui comprennent les aspects principaux du traitement des données biologiques massives :
ˆ WP1-HTS : Méthodes d’analyse de séquen¸cage à haut débit
ˆ WP2-Evolution : Passage à l’échelle des analyses évolutives
ˆ WP3-Annotation :Annotation fonctionnelle et structurelle des protéomes
ˆ WP4-Imaging : Intégration de l’imagerie cellulaire et tissulaire avec des données omiques
ˆ WP5-Databases : Données biologiques et intégration des connaissances
L’IBC est un projet multidisciplinaire soutenu pendant cinq ans (2012-2017) par l’état Fran¸cais à tra-
vers le projet “Investissements d’Avenir”. L’IBC implique actuellement 56 chercheurs multidisciplinaires
permanents, issus de quatorze laboratoires de Montpellier. l’IBC a pour objectif de devenir un lieu de
rencontre privilégié pour les chercheurs en biologie et en bio-informatique, mais aussi une importante
communauté de chercheurs, universitaires et industriel au niveau régional, national et international. Les
activités de l’IBC amnitionnent de collaborer avec des chercheurs de renommee mondiale, d’organiser des
manifestations scientifiques, de former de jeunes chercheurs, et de promouvoir les résultats et échanger
des informations avec des partenaires industriels.
2

La recherche sur le riz est un des modèles d’étude abordé par les chercheurs de l’IBC notamment à
travers le projet BIOeSAI (Biological electronic System Assistant Index). Ce projet a pour objectif de
gérer des études de diversité génotypique et phénotypique de variétés traditionnelles de riz vietnamien
(Oryza sativa). L’objectif de ces études est d’identifier des gènes d’intérêt pour qu’on puisse comprendre
les processus biologiques, par exemple : le développement et la plasticité de la plante, la résistance aux
maladies. Ces études requièrent la manipulation d’un volume important de données hétérogènes. Ces
données peuvent être stockées sous des formes différentes : fichier Excel, fichier texte structuré, images
ou bases de données relationnelles.
1.1.2 Présentation de l’INRA
L’INRA est un organisme de recherche fran¸cais pour l’agronomie fondé en 1946. Les recherches menées
par l’INRA sont guidées par les questionnements scientifiques en lien aux défis planétaires posés par l’ali-
mentation, l’environnement et la valorisation des territoires. Changement climatique, nutrition humaine,
compétition entre cultures alimentaires et non alimentaires, épuisement des ressources fossiles, équilibre
dans la gestion des territoires sont autant d’enjeux qui positionnent l’agronomie comme fondatrice d’un
développement harmonieux sur les plans économique, social et environnemental.
L’INRA produit des connaissances fondamentales et construit, grâce à elles, des innovations et des
savoir-faire pour la société. Il met son expertise au service de la décision publique. Les grandes missions
confiées à l’INRA sont les suivantes :
ˆ Produire et diffuser des connaissances scientifiques.
ˆ Concevoir des innovations et des savoir-faire pour la société.
ˆ Éclairer, par son expertise, les décisions des acteurs publics et privés.
ˆ Développer la culture scientifique et technique et participer au débat science-société.
ˆ Former à la recherche et par la recherche.
Le centre INRA de Montpellier coordonne Phénome, un projet de plate-formes de phénotypage haut-
débit de plantes cultivées. Son objectif est de mesurer des caractères agronomiques de plantes soumises à
différents scénarios environnementaux et en particulier les conditions de stress hydrique. C’est un projet
sur huit ans regroupant neuf plates-formes réparties sur sept sites d’études en France.
Les études couvrent à la fois des problématiques de recherche fondamentale en génétique et de re-
cherche appliquée pour la sélection de plantes adaptées à des contextes climatiques particuliers.
Sur la plate-forme de Montpellier se trouve trois plateaux techniques différents permettant de mesurer
la croissance de plantes en fonction de l’environnement :
ˆ PhénoPsis qui permet de peser et photographier plus de cinq cent plantes (Arabidopsis thaliana,
une plante modèle pour l’agronomie)
ˆ PhénoArch où plus de mille six cent plantes (ma¨ıs et autres céréales, vigne, pommiers) sont déplacées
grâce à un automate afin de procéder à différentes mesures, portant notamment sur l’architecture
de la plante, et d’être photographiées dans des cabines d’imageries 3D.
3

ˆ PhénoDyn où l’on mesure en particulier la transpiration et la croissance des feuilles des plantes.
D’autres plate-formes, comme celles de Toulouse, Dijon ou Mauguio, présentent des environnements
non contrôlés, avec des expérimentations en champ. Les données phénotypiques sont alors acquises grâce
à une Phénomobile (robot mobile autonome équipé de capteurs embarqués) ou à des drones.
Ces plate-formes sont spécialisées en écophysiologie, c’est-à-dire dans l’étude de l’influence de l’en-
vironnement sur la plante. Par conséquent, pour l’ensemble des expérimentations réalisées, les données
issues des capteurs environnementaux sont primordiales. Ces données sont à la fois hétérogènes en termes
de formats, de sémantique, etc. et volumineuses (plusieurs téraoctets par mois). Elles sont de plus reliées
entre elles au sein d’une experience et doivent pouvoir être tracées dans le temps.
Dans le contexte de Phenome, ces très nombreuses données doivent être conservées, partagées et ana-
lysées. Il faudra en effet être capable de les retrouver dans plusieurs années. De même, elles doivent pou-
voir être consultées et utilisées indifféremment par l’ensemble des neuf plates-formes. Enfin, les résultats
d’analyse et de calculs doivent également être reliés aux données.
1.2 Description du stage
Dans le cadre du projet de l’équipe Génome et Développement des Riz, du LMI RICE (Hano¨ı), des
études de la diversité génotypique et phénotypique de variétés traditionnelles de riz vietnamien sont
conduites dans le but d’identifier des gènes d’intérêt pour la compréhension de processus biologiques.
De la même manière, les recherches du laboratoire INRA à Montpellier évaluent les influences de l’envi-
ronnement sur les plantes. La caractéristique commune entre ces deux projets est la manipulation d’un
important volume de données hétérogènes. Ces données sont organisées dans des systèmes de gestion de
base de données relationnelles ou des systèmes de gestion de base de données NoSQL (MongoDB). Dans
ce contexte, les équipes souhaitent réorganiser leurs propres jeux de données afin de pouvoir naviguer,
partager, annoter et rechercher ces dernières afin de les exploiter au mieux.
Un système d’information a été implémenté lors d’un stage de Master 1 en 2014[1] pour le projet
du LMI RICE (BIOeSAI). Ce système est basé sur un système de gestion base de données MongoDB
incluant également la gestion des métadonnées et des tags. Toutefois, la méthode mise en place ne permet
pas de détecter des relations explicites/implicites entre les données gérées par le système.
L’objectif du stage proposé sera d’évaluer la faisabilité de gestion des BIG DATA couplé au techno-
logies du Web Sémantique en s’appuyant sur les articles de synthèse du domaine [2]. Par ailleurs, nous
réaliserons un état de l’art sur les problèmes d’organisation des données massives et de l’augmentation de
la capacité de recherche sur les données. Plus particulièrement, sur la capacité d’inférence et de raisonne-
ment sur les données. Un des objectifs du travail dans ce sujet sera de construire un base de connaissance
sur les données existantes.
1.3 Problématiques
Les données biologiques existantes sont volumineuses et elles ne cessent d’augmenter chaque jour.
L’utilisation des systèmes de gestion de base données relationnelles est aujourd’hui mal adapté pour gérer
ces données[1]. L’émergence des systèmes de gestion de base de données NoSQL orienté-document (e.g.
4

MongoDB) semble mieux adapté [3] toutefois ces systemes sont depourvus d’une capacité de recherche
sémantique sur les données ce qui existent seulement sur les données RDF par utiliser par le language
SPARQL.
Les bases de données de type “triplestore” sont mieux adaptées pour faire des inférences ou des
raisonnements sur les données. Toutefois, elles passent moins bien à l’échelle sur des gros volumes de
données. En effet, la recherche ou l’inférence sur un grand volume de données RDF peuvent prendre
beaucoup de temps. L’enjeu dans la gestion de ce type de données est d’utiliser les capacités d’inférence
sémantique avec de gros volumes de données.
L’association entre un système de données massives et les capacités de recherche sémantique est
l’objectif principal du sujet.
1.4 Contexte du sujet
1.4.1 Contexte de données massives
Aujourd’hui, nous entrons dans l’ère des Big Data. Des ensembles de données tellement gigantesques
qu’ils nécessitent de nouveaux outils techniques et scientifiques pour les comprendre et en tirer du sens.
Un déluge de données qui pose des questions profondes sur leur collecte, leur interprétation, leur analyse
etc. Les prochains enjeux de ce siècle sont d’extraire du sens de ces masses d’information qui circulent sur
les réseaux. Dans ce domaine, c’est avec la génomique et le phénotypage que la biologie est déjà entrée
dans le monde des big data. Certes, l’imagerie ou la modélisation métabolisme produisaient des données
numériques, mais la question de leur gestion et de leur exploitation ne se posait pas de la même fa¸con.
En termes d’exploitation des données, beaucoup reste à faire en biologie. C’est même là que se situe le
grand défi des big data en sciences de la vie : rattraper le fossé grandissant entre production massive de
données et la capacité à en extraire une information, voir une connaissance.
Le Big Data s’accompagne du développement d’applications à visée analytique, qui traitent les données
pour en tirer du sens. Ces analyses sont appelées Big Analytics ou “broyage de données”. Elles portent
sur des données quantitatives complexes avec des méthodes de calcul distribué.
En effet, les données massives désignent des ensembles de données tellement volumineux qu’il en
devient difficile de travailler avec des outils classiques des gestion de base de données ou de gestion de
l’information. Les Big Data sont souvent définis en utilisant l’acronyme 3V pour Volume, Vélocité et
Variété [4].
La volume se réfère à des quantités massives de données qui sont disponibles, le volume des données
stockées est en pleine expansion : les données numériques créées dans le monde seraient passées de 1,2
zettaoctets par an en 2010 à 1,8 zettaoctets en 2011, puis 2,8 zettaoctets en 2012 et s’élèveront à 40
zettaoctets en 2020[5]. À titre d’exemple, Twitter générait en janvier 2013, 7 teraoctets de données
chaque jour et Facebook 10 teraoctets[6].
La vélocité représente à la fois la fréquence à laquelle les données sont générées, capturées et partagées
et mises à jour. Quelquefois, la vélocité se réfère à la vélocité nécessaire pour traiter, analyser et utiliser
les données.
Le volume des Big Data met les data centers devant un réel défi : la variété des données. Il ne s’agit pas
5

de données relationnelles traditionnelles, ces données sont brutes, semi-structurées voire non structurées
(cependant, les données non-structurées devront, pour utilisation, être structurées). Ce sont des données
complexes provenant du web, au format texte et images. Elles peuvent être publiques (Open Data, Web
des données), géo-démographiques par ˆılot (adresses IP), ou relever de la propriété des consommateurs.
Ce qui les rend difficilement utilisables avec les outils traditionnels.
Pour répondre aux problématiques Big Data l’architecture de stockage des systèmes doit être repensée
et les modèles de stockage se multiplient en conséquence :
ˆ Cloud computing : l’accès se fait via le réseau, les services sont accessibles à la demande et en libre
service sur des ressources informatiques partagées et configurables. Les services les plus connus sont
ceux de Google BigQuery, Big Data on Amazon Web Services, Microsoft Windows Azure.
ˆ Super calculateurs hybrides : Les HPC pour High Performance Computing, qu’on retrouve en France
dans les centres nationaux de calculs universitaire tels quel’IDRIS, le CINES, mais aussi au CEA
ou encore le HPC-LR
ˆ Systèmes de fichiers distribuées Distributed files system (DFS) : les données ne sont plus stockées sur
une seule machine car la quantité à stocker est beaucoup trop importante. Les données, les fichiers
sont “découpés” en morceaux d’une taille définie et chaque morceau est envoyé sur une machine
bien précise utilisant du stockage local. Le stockage local est préféré au stockage SAN (Storage Area
Network)/NAS (Network attached storage) pour des raisons de goulots d’étranglement au niveau
du réseau et des interfaces réseaux des SAN. De plus, utiliser un stockage de type SAN coûte bien
plus cher pour des performances bien moindres. Dans les systèmes de stockage distribué pour le
Big Data, l’on introduit le principe de “Data locality”. Les données sont sauvegardées là où elles
peuvent être traitées.
Les bases de données relationnelles classiques ne permettent pas de gérer les volumes de données
du Big Data. De nouveaux modèles de représentation permettent de garantir les performances sur les
volumétries en jeu. Ces technologies, dites de Business Analytics, Optimization permettent de gérer des
bases massivement parallèles. Des patrons d’architecture “Big Data Architecture framework” sont pro-
posés par les acteurs de ce marché comme MapReduce développé par Google et utilisé dans le framework
Hadoop. Avec ce système les requêtes sont séparées et distribuées à des nœuds parallélisés, puis exécutées
en parallèles . Les résultats sont ensuite rassemblés et récuperés. Teradata, Oracle ou EMC proposent
également de telles structures, basées sur des serveurs standards dont les configurations sont optimisées.
Ils sont concurrencés par des éditeurs comme SAP (Systems, Applications, et Products) et plus récemment
Microsoft. Les acteurs du marché s’appuient sur des systèmes à forte scalabilité horizontale et sur des
solutions basées sur du NoSQL plutôt que sur des bases de données relationnelles classiques.
Avec les données dans nos laboratoires, le problème de gestion des données massives ne peut pas être
résolu avec les systèmes de gestion de base de données relationnelles. Ces systèmes deviennent lourds et
lents sur ces types de données. Ces dernières années, ont vu l’émergence d’une diversité de systèmes de
gestion de base de données que l’on appelle NoSQL. Ces systèmes NoSQL, proposent plusieurs modeles
pour organiser et stocker les données (la table 1.1).
6

Type de base de données1
Liste des systèmes utilisés
Clé - valeur CouchDB, Oracle NoSQL Database, Dynamo, FoundationDB, Hy-
perDex, MemcacheDB, Redis, Riak, FairCom c-treeACE, Aerospike,
OrientDB, MUMPS
Orienté colonne Accumulo, Cassandra, Druid, HBase, Vertica
Orienté document MongoDB, Clusterpoint, Apache CouchDB, Couchbase, Docu-
mentDB, HyperDex, Lotus Notes, MarkLogic, OrientDB, Qizx
Orienté Graphe Allegro, Neo4J, InfiniteGraph, OrientDB, Virtuoso, Stardog
Multi-modèle OrientDB, FoundationDB, ArangoDB, Alchemy Database, CortexDB
Tableau 1.1: La liste des types et des système de gestion de base de données dans NoSQL
Dans le domaine des données scientifique, il existe également de réels besoins d’exploitation de ces
données, en raison notamment de la forte augmentation de leur volume des dernières années. Le big data
et les technologies associées permettent de répondre à différents enjeux tels que l’accélération des temps
d’analyse des données, la capacité à analyser l’ensemble des données et non seulement un échantillon de
celles-ci ou la récupération et la centralisation de nouvelles sources de données à analyser afin d’identifier
des sources de valeur. Alors, sur la base des caractéristiques des données, on va décider quel système de
gestion de données utiliser. Par exemple avec les données qui ont plusieurs relations, nous pouvons choisir
le type de base de donnée orienté graphe. Il s’appuie sur la notion de noeuds, de relations et de propriétés
qui leur sont rattachées. Ce modèle facilite la représentation du monde réel, ce qui le rend adapté au
traitement des données des réseaux sociaux etc.
1.4.2 Contexte de recherche sémantique
Figure 1.1: L’architecture du web sémantique
Organiser les données afin de
mieux les comprendre, les utiliser et
les partager, est un objectif de longue
date. Mais le développement de l’ère
digitale a provoque une avalanche de
données dont le traitement requiert
de nouvelles méthodes. L’enjeu de
la recherche informatique est d’ex-
traire du sens dans cette masse d’in-
formation notamment à travers des
méthodes de fouilles de données ou
des algorithmes d’apprentissage auto-
matique scannant le web. Toutefois,
les problèmes ne sont pas résolu pour
autant. Pourtant, a partir de l’idée de
Tim Berners-Lee : “J’ai fait un rêve
pour le Web [dans lequel les ordinateurs] deviennent capables d’analyser toutes les données sur le Web
- le contenu, les liens, et les transactions entre les personnes et les ordinateurs. Un “Web Sémantique”,
7

qui devrait rendre cela possible, n’a pas encore émergé, mais quand ce jour sera atteint, les mécanismes
de dialogue entre les machines sera facilite. Les “agents intelligents” qu’on nous promet depuis longtemps
vont enfin se concrétiser”[7] [8], le web sémantique émerge comme la meilleure solution pour traiter
des données directes ou indirectes par des machines, partager et réutiliser des données entre plusieurs
applications et aider les utilisateurs à créer de nouvelles connaissances.
Dans le contexte d’application orienté web sémantique et la gestion de données biologiques, nous allons
focaliser sur les trois parties principales suivantes : Le représentation de données en RDF, les requêtes
avec SPARQL et les inférences, les raisonnements pour trouver de nouvelles connaissances.
La description de ressources (RDF)
Figure 1.2: L’exemple d’un triplet RDF.
La RDF est un modèle de graphe destiné à décrire la donnée de fa¸con à permettre son traitement
automatique par des machines. RDF donne une description par triplet <Sujet, Prédicat, Objet>. Le sujet
représente la ressource à décrire, le prédicat représente un type de propriété applicable à cette ressource,
et l’objet représente une donnée ou une autre ressource. Les documents RDF peuvent être écrits en
différents syntaxes ainsi, il peuvent exister sous plusieurs formats : RDF/XML, N3, N-Triples, TURTLE,
JSON-LD etc
La RDF est donc simplement une structure de données constituée de nœuds et organisée en graphe. Un
document RDF ainsi formé correspond à un multi-graphe orienté étiqueté. Ici, chaque triplet correspond
alors à un arc orienté dont le label est le prédicat, le nœud source est le sujet et le nœud cible est l’objet.
L’Interrogation de graphes RDF
Figure 1.3: L’exemple d’une requête SPARQL.
Le SPARQL est un langage de requêtes pour interroger des données qui sont stockées en respectant
le modèle RDF. Les requêtes SPARQL sont adaptées à la structure spécifique des graphes RDF, et
s’appuient sur structure sous la forme de triplets. En cela, il est différent du classique SQL, mais s’en
inspire clairement dans sa syntaxe et ses fonctionnalités. Le SPARQL permet d’exprimer des requêtes
interrogatives ou constructives : une requête SELECT, de type interrogative, permet d’extraire du graphe
RDF un sous-graphe correspondant à un ensemble de ressources vérifiant les conditions définies dans une
8

clause WHERE ; une requête CONSTRUCT, de type constructive, engendre un nouveau graphe qui
complète le graphe interrogé.
L’Ontologie
L’Ontologie est un ensemble structuré de termes et concepts représentant le sens d’un champ d’in-
formations, que ce soit par les métadonnées d’un espace de noms, ou les éléments d’un domaine de
connaissances. L’ontologie constitue en soi un modèle de données représentatif d’un ensemble de concepts
dans un domaine, ainsi que des relations entre ces concepts. Elle est employée pour raisonner à propos des
objets du domaine concerné. Plus simplement, nous pouvons aussi dire que l’ “ontologie est aux données
ce que la grammaire est au langage”.
Les conceptions utilisent pour décrire d’une ontologies générales :
ˆ Individus : les objets de base
ˆ Classes : ensembles, collections, ou types d’objets
ˆ Attributs : propriétés, fonctionnalités, caractéristiques ou paramètres que les objets peuvent posséder
et partager
ˆ Relations : les liens que les objets peuvent avoir entre eux
ˆ Evénements : changements subits par des attributs ou des relations
ˆ Méta-classes : des collections de classes qui partagent certaines caractéristiques
L’inférence, le raisonnement
L’inférence sur le Web sémantique est l’un des outils de choix pour améliorer la qualité de l’intégration
de données sur le web, en découvrant de nouvelles relations, analyse automatiquement le contenu des
données, ou la gestion des connaissances sur le web en général. Les Techniques à base d’inférence sont
aussi importante dans la découverte d’éventuelles incohérences dans les données intégrées.
Un exemple simple peut aider à bien comprendre à la conception de l’inférence. Les données fixées
pour être considérées peuvent inclure la relation (HaiPhong isPartOf the North Vietnam). Une ontologie
peut déclarer que “The North of VietNam isPartof Vietnam”. Cela signifie que d’un programme de Web
sémantique comprendre la notion de “X ispartOf Y” peut ajouter la déclaration “HaiPhong isPartOf
Vietnam” à l’ensemble des relations, bien que cela ne faisait pas partie des données originales. On peut
dire aussi que la nouvelle relation a été “découverte”.
D’une manière générale, Les inférences sur le web sémantique peut être caractérisée par la découverte
de nouvelles relations. Sur le Web sémantique, les données sont modélisées comme un ensemble de relations
entre les ressources. “l’Inférence” signifie que les procédures automatiques peuvent générer de nouvelles
relations fondées sur les données et sur la base des informations supplémentaires sous la forme d’un
vocabulaire, un ensemble de règles. Que les nouvelles relations sont explicitement ajoutées à l’ensemble
des données, ou sont retournées au moment de la requête, est une question de mise en oeuvre.
Sur le Web sémantique, la source de telles informations supplémentaires peut être définie par l’in-
termédiaire de vocabulaires ou ensembles de règles. Ces deux approches font appel aux techniques de
représentation des connaissances. En général, les ontologies se concentrent sur les méthodes de classifica-
tion, en mettant l’accent sur la définition de de “classes”, “sous-classes”, sur la fa¸con dont les ressources
9

individuelles peuvent être associes à ces classes, et de caractériser les relations entre les classes et leurs ins-
tances. D’autre part, les règles se concentrent sur la définition d’un mécanisme général sur la découverte
et la génération de nouvelles relations fondées sur celles qui existent déjà tout comme les programmes
logiques, tel Prolog. Dans la famille du Web sémantique lié aux recommandations de World Wide Web
Consortium (W3C) : Resource Description Framework Schema (RDFS), Web Ontology Language (OWL),
Simple Knowledge Organization System (SKOS) sont des outils de choix pour définir des ontologies, alors
que Rule Interchange Format (RIF) a été développé pour couvrir les approches basées sur des règles.
10

Chapitre 2
État de l’art
2.1 Existants
Depuis plusieurs années des études en phénotypage haut-débit des plantes sont réalisées à l’INRA.
Il existe donc un grand nombre de données de phénotypage et de génotype des plantes. Ces données
sont acquises chaque jour, par exemple sur le plateau technique PhenoArch, environ 1600 plantes sont
suivies pendant deux à trois mois. Chaque jours elles sont photographiées sous trois à treize angles,
ce cycle journalier d’imagerie produit donc environ 20800 images stockées. Celles-ci sont associées à
des configuration et des résultats d’analyse d’image sous la forme de JSON. Chaque document JSON
est environ 40 champs. Pour les gérer, les informaticiens ont déjà construits un système d’information
appelé Phenotyping Hybrid Information System (PHIS)1
. Les données permettant l’exploitation de la
plateforme sont stockées dans une base de données relationnelles. Avec les limitations de base de données
relationnelles, ces données doivent être migrées dans une base MongoDB pour améliorer le temps de
performance du système.
La même fa¸con, le projet BIOeSAI est entrée dans une deuxième phase à partir de 2015 à 2018.
Les études de la première phase ont été réalisées sur riz (O.SATIVA). Ce sont des données hétérogènes
et volumineuses sur le phénotypages et génotypes du riz. Le laboratoire a aussi construit un système
d’information pour gérer les données Syspherice2
[1]. Ces données sont organisées et stockées sous la forme
de document JSON. Elles sont gérées par le système de gestion de base de données orienté document
MongoDB.
2.2 Analyse et évaluation des solutions courantes
2.2.1 MongoGraph - une association du Mongodb et AllegroGraph
AllegroGraph est une base de données de graphe RDF persistante. Il utilise le stockage sur sur disque,
ce qui lui permet de passer à l’échelle des milliards de triplets, tout en maintenant une performance
supérieure. AllegroGraph est un framework de base de données et d’outils pour construire des applications
Web sémantique. Il peut stocker des données et des méta-données, il permet aussi d’interroger ces triplets à
1http ://lps-phis.supagro.inra.fr/phis/index.php
2http ://vmbioesai-dev.ird.fr :8080/Syspherice
11

travers différentes APIs comme SPARQL et Prolog. De plus, il fourni des fonctionnalités de raisonnement
RDFS++ avec son raisonneur intégré. AllegroGraph inclut également une librairie d’analyse de réseaux
sociaux (SNA) et il permet de stocker et raisonner sur des données temporelles et géospatiales.
Actuellement, il existe différentes éditions d’AllegroGraph : une édition gratuite où stockage RDF est
limitée à moins de 5 millions de triplets, une édition développeur capable de stocker un maximum de
50 millions de triplets et une édition d’entreprise avec une capacité de stockage qui n’est limitées que
par l’infrastructure de serveur. Des clients sont disponibles pour Java, Python, Lisp, Clojure, Ruby, Perl,
Csharp et Scala.
En plus des fonctions liées à l’application de Web sémantique, AllegroGraph implémente une interface
avec MongoDB, que l’on appelle MongoGraph. Celle-ci permet d’offrir aux programmeurs MongoDB les
capacité du Web sémantique. En utilisant cette approche, les objets Javascript Object Notation (JSON)
sont automatiquement convertis en triplets et ils peuvent être interrogés à la fois par le langage de requête
MongoDB et par SPARQL.
Figure 2.1: Le modèle de composants dans un système MongoGraph
MongoDB est une base de données
orientées documents NoSQL de haute
performance et Open Source. MongoDB
fournit un stockage basé sur des docu-
ments en forme de JSON avec comme
fonctionnalités l’indexation en texte
intégral, la réplication, la répartition des
de données (sharding), le calcul Map/Re-
duce et un langage de requête riche à base
de documents. Toutefois, il ne fournit pas
un bon support pour les jointures com-
plexes, le liage de données (linked data),
l’analyse de graphe et l’inférence ou le
raisonnement.
En connectant AllegroGraph à Mon-
goDB, il est possible d’interroger des
données liées en graphe et dans une
base de données orientées documents en
une seule requêtes. Avec MongoDB, les
données sont organisées en forme des do-
cuments JSON, ils sont gérées par un
système de gestion de base de données
orientées documents des plus efficace [9]. Avec AllgroGraph, les données sont organisées en graphe, sur
lesquelles nous pouvons réaliser facilement des requêtes SPARQL, et aussi effectuer des inférences sur ces
données.
Avec les caractéristiques des deux systèmes de gestion de base de données, il est possible de construire
un système qui a des capacités de requêtes du Web sémantique et qui peut traiter des données volumi-
neuses. Le modèle du système général de MongoDB et de AllegroGraph est mis en oeuvre Figure 2.1.
12

Ici, les données d’origines restent stockées dans MongoDB sous le format documents dans des collections.
Les nouveaux triplets mis en relation avec les documents MongoDB sont importés dans AllegroGraph.
Pour créer manuellement des triplets ou utiliser l’outil Relational and Non-Relational Databases to RDF
Mapping Language (xR2RML) pour les convertir automatiquement. On utilise les seulement les attributs
importants dans les documents. D’ailleurs, une ontologie est utilisée pour l’organisation sémantique des
triplets créés. Cette ontologie permet l’inférence en exploitant les relations entre les triplets. Ainsi le
moteur d’inférence peut créer de nouvelles relations sur la base de l’ontologie définie.
(a) Les données JSON dans MongoDB (b) Les données RDF dans AllegroGraph
(c) L’ontologie de lieu origine de plante
Figure 2.2: Les données présentées dans cet exemple
Pour mieux comprendre la solution d’association de MongoDB et de AllegroGraph et illustrer les
requêtes et l’inférence, nous avons pris un exemple sur les données existantes du projet BIOeSAI. Ce projet
contient une ontologie sur les relations entre le lieu d’origine des plantes et les images expérimentales sur
les plantes. Les triplets sont créés à partir des documents MongoDB, dans ce cas, en utilisant les attributs
de l’identification du document, les informations sur l’origine des plante et du nom des plantes. On peut
voir les détails des données JSON dans MongodDB, des données RDF qui ont été liés aux documents
MongoDB et l’ontologie de références dans Figure 2.2.
13

Nous pouvons faciliter l’importation des données RDF dans AllegroGraph en utilisant la forme d’un
dépôt, “Repository”. La création d’une connexion avec MongoDB est effectué dans l’interface de Allegro-
Graph. Ici, les informations de la base de données MongoDB doivent être rempli, par exemple : le nom
et port du serveur, le nom de la base de données et la collection choisie.
AllegroGraph possède deux types différents de moteur d’inférence : l’un supporte un sur-ensemble de
règles d’inférence RDFS et l’autre supporte Web Ontology Rule Language (OWL 2 RL). Le premier est
appelé le raisonneur RDFS++ dynamique car il génère les triplets inférés à l’exécution de l’inférence et
n’enregistre pas les triples nouveaux créés. Le second moteur d’inférence fait de la matérialisation OWL
2 RL. Il utilise de règles d’inférence pour générer de nouveaux triplets et les ajoute à la base de triplets
courante. Pour notre exemple, le second moteur d’inférence est choisi pour toutes les données. Après
avoir exécuté, nous avons les nouveaux triplets sont stockés de manière pérenne sur le disque comme les
triplets d’origine. Cela est le mieux pour les systèmes qui ont plusieurs requêtes.
Les requêtes sont réalisées grâce au langage SPARQL intégrant des requêtes MongoDB (Figure 2.3).
Cette association est effectuée par l’utilisation d’une approche que l’on appelle “Magic Predicat”. C’est
un prédicat d’une requête SPARQL qui permet une liaison, différente d’un simple appariement de sous-
graphe. AllegroGraph a longtemps soutenu l’utilisation de “Magic Predicat” pour permettre les requêtes
en texte libre et pour interfacer Solr et MongoDB. Dans la requête Figure 2.3, le système va effectuer
deux requêtes dans deux systèmes différents pour obtenir les résultats. Les requêtes seront exécutées dans
MongoDB pour trouver les résultats sous le format de JSON, et les résultats finaux (les triplets) seront
trouvés dans AllegroGraph.
Figure 2.3: Une requête SPARQL associée à une requête de MongoDB
Avantages
ˆ AllegroGraph permet de réaliser des inférences sur des données massives
ˆ Selection possible des propriétés importantes et donc réduction du nombre de triplets dans la base
de données.
ˆ Gestion de base de données massives avec MongoDB
Inconvenients
ˆ Un système plus complexe avec plusieurs étapes de requêtes
ˆ Mapping manuel des données entre les deux systèmes MongoDB et AllegroGraph
14

ˆ Pas de synchronisation entre les deux, quand nous mettons à jour au MongoDB, nous devons le
faire aussi sur Allegograph
2.2.2 Base de données orientée graphe Neo4j
Neo4j est un système de gestion de base de données orienté graphe, ce qui permet de représenter les
données en tant qu’objet relié par un ensemble de relations, chaque objet possédant ses propres propriétés.
La base de données de graphes, permet au développeur de commencer directement le codage, les données
stockées dans la base assurant un parallélisme direct avec les données elles-mêmes. En d’autres termes, à
mesure que l’organisation des données se peaufineront, les programmes suivront.
Une base Neo4j est censée être plusieurs milliers de fois plus rapide pour traiter les données associa-
tives, car elle en évite de coûteuses jointures Structured Query Language (SQL). Les requêtes peuvent
gérer de ce fait plus facilement un large ensemble de données. Les parcours utilisent un langage simple
de parcours des connections. L’absence de modélisation rigide, rend Neo4j bien adapté à la gestion de
données changeantes et de schémas évoluant fréquemment.
Les caractéristiques typiques de données pour Neo4j sont la structuration des données optionnelles
qui sont peuvent absenter, une facilité de changement du schéma et des migrations de données sans
contraintes, la modélisation facile de jeux de données de domaines complexes et cas d’utilisation typique
dans des domaines tels que le Web sémantique et RDF, le Web de données, l’analyse du génome, la
modélisation de données de réseaux sociaux etc.
Neo4j a des composants optionnels qui viennent en complément du noyau. On peut ainsi structurer le
graphe via un méta-modèle, obtenir une implémentation de RDF TripleStore compatible SPARQL. Par
exemple, avec deux plugins Neo-rdf-sail 3
et Neo4j-sparql-extension4
.
Figure 2.4: La graphe de données dans Neo4j
Les graphes de données dans Neo4j sont illustrés par les concepts de ”Nodes” et de ”Relations”
3https ://github.com/neo4j-contrib/neo4j-rdf-sail
4https ://github.com/niclashoyer/neo4j-sparql-extension
15

Figure 2.4. D’ailleurs, le langage de requête Cypher est utilisé pour manipuler les données. C’est un
langage déclaratif de requête graphique qui permet de réaliser efficacement et rapidement des requêtes
et des mis à jour sur les données. En détail, le langage Cypher se concentre sur la clarté d’expression de
ce que l’on veut récupérer à partir d’un graphique et pas sur la fa¸con de le récupérer. Cette approche
permet l’optimisation des requêtes.
Figure 2.5: Les commandes pour créer un graphe simple
Avantages
ˆ Gestion de base de données pour le Big Data sous la forme de graphes, donc amelioration de la
performance du système par des requêtes basées sur des relations entre les objets.
ˆ L’organisation de données sous forme de graphe est presque similaire à l’organisation des données
dans les ontologies et les instances données RDF.
Inconvénients
ˆ Les données doivent être re-organiser sous la forme d’un graphe, cela prendre plus de temps en
fonction de la complexité et de la taille de données.
ˆ Les données ne sont pas en RDF directement, donc pour faire des requêtes SPARQL nous utilisons
un plugin intégré qui ne supporte pas entièrement le language SPARQL.
2.2.3 JSON-LD et MongoDB
Les données liées se réfèrent à un ensemble de bonnes pratiques à mettre en oeuvre pour publier et lier
des données structurées sur le web. Elles s’appuient sur les standards du Web, tels que HTTP et URI -
mais plutôt qu’utiliser ces standards uniquement pour faciliter la navigation par les êtres humains, le Web
des données les étend pour partager également l’information entre machines. Cela permet d’interroger
automatiquement les données, quels que soient leurs lieux de stockage et sans avoir à les dupliquer.
JSON-LD est une syntaxe légère pour sérialiser des données liées de la forme de JSON. Son utilisation
permet à des données JSON d’être interprétées comme des données liées avec des changements minimes.
JSON-LD est principalement destiné à être un moyen d’utiliser les données liées dans des environnements
de programmation basés sur le Web, pour construire des services Web interopérables, et pour stocker des
données liées dans les moteurs de stockage à base de JSON. Actuellement, JSON-LD est compatible avec
JSON, un grand nombre de parseurs JSON et de bibliothèques sont disponibles aujourd’hui et peuvent
être réutilisés. En plus de toutes les fonctionnalités JSON, JSON-LD introduit :
ˆ Un mécanisme d’identifiant universel pour les objets JSON via l’utilisation d’IRIs
16

ˆ Un moyen de lever l’ambigu¨ıté de clés partagées entre des documents différents par des mappings
en IRI via un contexte
ˆ Un mécanisme dans lequel une valeur dans un objet JSON peut se référer à un objet JSON sur un
autre site sur le web
ˆ La possibilité d’annotation des chaˆınes de caractères avec la langue et d’associer les types de données
avec des valeurs telles que la date et l’heure
ˆ La facilité d’exprimer un ou plusieurs graphes orientés comme un réseau social en un seul document.
JSON-LD est destiné à être utilisable directement comme JSON qui ne contient pas des connaissances
de RDF. Il est également con¸cu pour être utilisable comme RDF. On peut l’utiliser avec d’autres tech-
nologies de données liées comme SPARQL. Les projets qui ont besoin de traiter les données comme des
graphes RDF vont trouver une solution avec la forme de JSON-LD. En détail, le document JSON-LD est
Figure 2.6: Les triplets sont stockées dans MongoDB sous la forme de JSON-LD
à la fois un document RDF et un document de JSON et représente une instance d’un modèle de données
RDF. Cependant, JSON-LD étend le modèle de données RDF pour sérialiser des ensembles de données
RDF.
Figure 2.7: Le modèle de composants
dans un système d’association de Mon-
goDB et JSON-LD – CRUD
Le format de données RDF est organisé en JSON-LD, ce qui
convient au format JSON utilisé dans MongoDB. Alors, nous
pouvons profiter de la puissance de MongoDB pour résoudre
le problème de grandes données. D’ailleurs, nous facilitons la
sérialisation des données de graphes RDF dans MongoDB.
La graphe de données RDF peut être organisé et stocké dans
la mémoire temporelle avec le support d’Application Programming
Interface (API) disponibles tels que Sesame ou Jena. Ces APIs
permettent d’utiliser le langage de SPARQL pour faire des requêtes
et appliquer des règles et faire des inférences sur les données. Les
recherches vont directement se faire sur les graphes RDF qui sont
sérialisés (chargés) à partir des données dans MongoDB, cette étape
va prendre du temps. Nous avons alors besoin d’une méthode pour
organiser les données importantes. Cette étape est importante pour
optimiser le temps exécution du système. En effet, nous avons les deux bases de données dans le système,
17

le base de données orientée documents et la base de triplets dans mémoire temporelle. Ici, les opérations
CRUD vont s’exécuter dans MongoDB et les recherches sont réalisées dans le graphe RDF. Alors, une
couche médiane est nécessaire pour synchroniser les deux bases de données.
Avantages
ˆ Le stockage des données dans MongoDB sous la forme de JSON-LD est aussi la forme de données
RDF. Nous pouvons donc profiter de la puissance de MongoDB dans le traitement de problème de
données volumineuses.
ˆ Les opérations de CRUD vont être rapidement réalisées sur les données dans MongoDB.
ˆ Les requêtes en langage SPARQL sont utilisées pour faire des recherches de données dans le système.
Inconvénients
ˆ L’existence de deux base de données va augmenter la complexité du système.
ˆ L’étape de chargement des données de graphes RDF dans la mémoire temporelle va prendre beau-
coup de temps. Les mises à jour sur les données de graphes RDFs sont dépendantes de la base de
données dans MongoDB.
ˆ Le problème de mémoire temporelle avec les grands graphes RDFs, la puissance matérielle est
importante pour ce système avec un besoin fort de mémoires temporelles.
2.2.4 ODBA et frameworks Ontop
L’ODBA est considérée comme un élément clé pour la nouvelle génération de systèmes d’information,
en particulier pour les applications du Web sémantique qui impliquent une grandes quantités de données.
L’ODBA est un paradigme d’accès à des données par une couche conceptuelle. Généralement, la couche
conceptuelle est exprimée sous la forme d’une ontologie qui définit un schéma global de haut niveau et
fournit des vocabulaires pour des requêtes d’utilisateurs. Les données sont stockées dans des bases de
données relationnelles, des bases de triplets etc [10].
Les termes de la couche conceptuelle sont mappées sur la couche de données en utilisant les mappings
qui associent à chaque élément de la couche conceptuelle, une requête sur les sources de données. Main-
tenant, les mappings ont été formalisées dans la récente norme Relational Databases to RDF Mapping
Language (R2RML) 5
de l’organisation W3C. Cette graphe virtuelle peut être interrogée à l’aide d’un
langage de requête sur les données RDF tels que SPARQL.
Un système ODBA est un triple : O = <T , S, M>, où[11] :
ˆ T est considéré comme les ontologies formalisées dans les Logiques de Description (DL), où T est
un DL TBOX.
ˆ S est un schéma des sources.
ˆ M est un ensemble d’assertions des mappings, chacun de la forme : Φ(x) ← Ψ(x)
Φ(x) est une requête sur S, retourner des tuples de valeurs pour x
Ψ(x) est une requête sur T dont les variables libres sont de x
18

Figure 2.8: Le processus de requête dans le système d’ODBA
Les systèmes d’ODBA sont orienté pour répondre aux requêtes. Une description schématique du
processus de transformation de requête illustre dans la figure 2.8. Ici, les requêtes posées au niveau de
la couche conceptuelle sont traduites dans un langage de requête qui peut être traité par la couche de
données. La traduction est indépendante des données réelles dans la couche de données. De cette fa¸con,
l’évaluation de requête peut être déléguée au système de gestion des sources de données.
Sur la base de la conception d’ODBA, les chercheurs de l’Universtié Bozen-Bolzano en Italie ont
développé un Framework ODBA du nom d’Ontop. Il est utilisé actuellement sur l’application Optique6
résoudre les problèmes de Big Data.
Le noyau de Ontop est le moteur de requête SPARQL QUEST qui implémente RDFS et OWL 2 QL
en ré-écrivant les requêtes SPARQL sur le graphe RDF virtuelle en des requêtes SQL (sur la base de
données relationnelles). Ontop est capable de générer efficacement et de manière optimisé des requêtes
SQL [12]. Le Framwork Ontop peut être utilisé comme :
ˆ Un plugin pour Protégé 4 qui fournit une interface pour la rédaction de mappings et l’exécution de
requêtes SPARQL.
ˆ Une bibliothèque Java qui implémente OWL API et les interfaces API de Sesame.
ˆ Un point d’accès SPARQL sur Sesame.
(a) L’approche classique des raisonnements (b) L’approche de QUEST des raisonnements
Figure 2.9: La comparaison des approches des raisonnements dans une application
5http ://www.w3.org/TR/r2rml/
6http ://optique-project.eu/
19

L’approche classique converti les bases de données en triplets. Ensuite, les requêtes, les inférences
seront réalisées sur ces données. Avec l’approche de QUEST, un nouveau paradigme sur les données est
créé, ici, les structures de base de données ne sont pas brisées. Les données sont stockées dans un seul
système.
Figure 2.10: L’architecture du système avec l’association de MongoDB et le
modèle d’ODBA
Avec les limitations des
bases de données relationnelles
pour ls données massives, une
solution proposée est l’associa-
tion du modèle ODBA avec
le système de gestion de base
données MongoDB. Avec cette
approche, nous allons profiter
des avantages des MongoDB
pour la gestion de grands jeux
de données et du modèle ODBA
pour créer des mappings entre
les données et l’ontologie. Ainsi
nous pourrons faire des requêtes
et utiliser du raisonnement.
Avantages
ˆ La structure de données est gardée dans le système de gestion de base de données. Il n’y a pas de
duplication de données sous forme de triplet pour faire des raisonnements.
ˆ Les interrogations sur les données sont réalisées dans langage de requête SPARQL
ˆ La capacité de compatibilité avec plusieurs systèmes de gestion base de données relationnelles
Inconvénients
ˆ La complexité du système va augmentent avec l’organisation des modèles d’ODBA
ˆ L’augmentation du temps et de l’argent pour construire le système.
2.2.5 Matérialisation de données en triplets RDF
Dans toutes les approches ci-dessus, les données sont organisées et stockées dans des systèmes de
gestion de base de données orientés graphe Neo4j ou des systèmes bases de données orientés documents
MongoDB ou des systèmes hybrides d’association de MongoDB et des systèmes de gestion de base de
données de triplets RDF. Toutefois, l’implémentation de requêtes sur les données avec le langage SPARQL
a plusieurs limitations. Dans cette partie, nous allons découvrir une autre approche sur les données. C’est
la matérialisation de données en triplets. Les données seront converties en triplets RDF. Cette approche
est maintenant la meilleure solution pour l’organisation des données avec des capacités de raisonnements.
Le plus souvent, lorsque l’on commence à vouloir publier des données sur des bases de connaissances
comme RDF il existe déjà une base de données. Pour que l’on puisse utiliser les données en RDF, il faut
20

les traduire en triplets. Il existe plusieurs méthodes mais la plus utilisée est la suivante : Database To
RDF (D2R)7
a pour but de traduire toutes les données contenues dans une base de données en triplets
RDF. D2R fonctionne avec un fichier de mapping et une ou plusieurs ontologies. Le fichier de mapping
sert à faire la liaison entre les tables et les champs contenus dans ces tables et les classes et les propriétés
dont sont composées ou les ontologies que l’on utilise. Ainsi, après le mapping, les données correspondront
à la ou les ontologies spécifiées et, ensuite seront disponibles sur une application Web sémantique par
l’intermédiaire d’une interface Web et d’un point d’accès SPARQL
Figure 2.11: Les deux tables et sa relation
Figure 2.12: Les informations définies pour le mapping
Figure 2.13: Les données RDF après de la transformation
Il existe maintenant deux méthodes pour map-
per une base de données : R2RML8
et Direct
Mapping9
. Ainsi avec ces deux méthodes il est
possible d’intégrer toutes les données d’une base
SQL au Web de données, de les manipuler avec
SPARQL et de les interconnecter avec d’autres
jeux de données présents sur le Web de données.
Le Direct Mapping définit une transfor-
mation simple, fournissant une base pour la
définition et la comparaison des transformations
plus complexes. Il peut également être utilisé
pour matérialiser des graphes RDF ou définir des
graphes virtuels. Ces graphes peuvent être in-
terrogés en SPARQL ou grâce à une API RDF.
En ce qui concerne R2RML [13], c’est un lan-
gage pour exprimer des mappings à partir d’une
base de données relationnelles et des ensembles de
données RDF. Ces mappings fournissent des ca-
pacité de visualisation des données relationnelles
existantes en représentation RDF. Avec les trois
figures dans cette section, nous pouvons voir un
exemple de ces mappings de données relation-
nelles et de triplets. Ici, sur la base des relations
entre les tables (Figure 2.11), nous allons définir
un fichier pour mapper des informations dans et
entre les tables (Figure 2.12) aux sujet, prédicat
et objet de triplets (Figure 2.13).
Toutefois, ces deux approches existe seulement
pour des bases données relationnelles. Donc, il y
a la nécessité d’utiliser la même idée pour mapper
des triplets RDF avec des bases de données orientées documents. Franck Michel et ses collèges [14] se
7http ://d2rq.org/
8http ://www.w3.org/TR/r2rml/
9http ://www.w3.org/TR/rdb-direct-mapping/
21

sont basés sur le langage de mapping R2RML et Morph-RDB10
qui est une implémentation du langage
de mapping R2RML pour les données relationnelles, pour développer xR2RML qui est s’applique aux
bases de données orientées documents comme MongoDB.
En particulier, xR2RML est une extension de la langage de mapping R2RML et s’appuie sur certaines
propriétés du langage de mapping RDF Mapping Language (RML) [15] et. R2RML porte sur les mappings
de base de données relationnelles aux triplets RDF. RML étend R2RML pour aborder les mappings sur des
données hétérogènes (XML, JSON, CSV) avec des triplets RDF. xR2RML étend ce champ d’application
à un plus large éventail de base de données non-relationnelles.
Avantages
ˆ Les données sont converties en triplets. Nous pouvons donc utiliser les systèmes de gestion de base
de données RDF spécifiques.
ˆ Les interrogations sur les données sont réalisées par langage de requête SPARQL
ˆ Les capacités de raisonnement sont parfaitement soutenues par ces systèmes de gestion de base de
données RDF.
Inconvénients
ˆ L’étape de transformation de données est coûteuse en temps : ré-organisation des données en graphe
ˆ Le nouveau système avec ses données a besoin d’une nouvelle architecture pour être mis en œuvre.
Le système est indépendant de l’existant.
ˆ On rencontre des problèmes de performance avec les données volumineuses
2.3 Conclusion
Dans cette partie, nous avons fait l’état de l’art des approches pour résoudre le problème de données
massives et des recherches au niveau Web sémantique. Pour résumer il y a deux approches principales :
la transformation de données en triplets RDF avec l’association de AllegroGraph et de MongoDB, de
Neo4J, de JSOn-LD et de MongoDB. Il y a aussi l’utilisation d’un langage de mapping comme xR2RML
et la transformation de requêtes ou la ré-écriture des requêtes avec ODBA et Ontop Framework. On peut
voir que pour chaque approche il existe des avantages et des inconvénients. Il faudra donc, sur la base des
caractéristiques de l’organisation des données et de l’objectif d’utilisation de données, choisir la meilleure
solution pour les données.
10https ://github.com/oeg-upm/morph-rdb
22

Chapitre 3
Solution proposée
3.1 Introduction
La partie précédente donne une vue générale de différentes solutions pour aider à traiter un gros
volume de données et renforcer la capacité d’association en structurant les données aux triplets RDF
pour que le but final soit l’amélioration de capacité de partage, d’intégration et de recherche des données.
Dans cette partie, nous allons présenter la solution sur la base d’une matérialisation de données sous
forme de triplets.
Dans ce chapitre, nous aborderons dans la première section le choix de la représentation du modèle
données et la manière de le générer. Ensuite, dans la section suivante sera abordée une démarche entreprise
pour transformer des données du modèle relationnel aux format JSON. De plus, une ontologie sera
présentée pour décrire les vocabulaires nécessaires dans la la conception du modele RDFs. En fin, le
langage de transformation de données en RDF sera introduit avec les syntaxes pour créer les mapping et
convertir des documents JSON en triplets RDF.
3.2 Modèle général
L’approche de matérialisation de données en triplets RDF a été choisie afin de tester l’organisation et la
performance des triplestores sur de gros volume données. Les systèmes actuels stockant de gros volumes
sont en majorité partagés entre des systèmes NoSQL (e.g : Mongodb), relationnels et divers format.
L’un des objectifs de ce travail était l’organisation et la synchronisation des données en conservant leur
provenance et les systèmes existants en ayant MongoDB comme stockage intermédiaire.
Par la suite, les données seront converties en triplets RDF grace a l’utilisation du langage de mapping
xR2RML et l’outil développé par les auteurs [14]. Les vocabulaires et les règles de transformation de
triplets sont fournis par une ontologie. Cette ontologie est importante pour réaliser des recherches avancées
sur les relations et les hiérarchies existantes .
Aujourd’hui, il existe différents systèmes qui permettent de gérer les données RDF. Nous allons focali-
ser notre etude sur cinq systèmes : 4Store, Sesame, Virtuoso, Stardog, GraphDB(OWLIM) et Jena Fuseki.
Leurs mécanismes d’action et d’indexation de données étant différents, nous allons tester ces systèmes
avec des données volumineuses. Ainsi, réaliserons les tests de ces systèmes sur la capacité de gestion de
23

données RDF afin d’optimiser le stockage et pour la récupération de ces triplets à l’aide du langage de
requête SPARQL.
Le moteur de recherche va consister à utiliser la capacité d’inférence sur la base contenant l’ontologie et
les données RDF. Une interface est fournie pour effectuer les requêtes sur ces données. Les interrogations
sous la forme de langage SPARQL sont utilisées pour chercher les données nécessaires dans la base de
données. L’illustration détaillée du modèle est présenté dans la figure 3.1 suivante :
Figure 3.1: Le modèle général du système
3.3 Transformation et synchronisation de données dans Mon-
goDB
Dans le projet Phenome (INRA), plusieurs systèmes de capteurs alimentent des bases de données
relationnelles en permanence. Il y a une fort besoin de synchronisation de ces données avec le système
courant. L’étape de transformation de données en documents JSON est réalisées afin d’intégrer plusieurs
ressources dans un meme entrepôt. Dans la suite du memoire nous nous concentrons seulement sur les
données obtenues dans sur les processus d’imageries, d’arrosage, de pesées ceux que les chercheur ont
réalisés quotidiennement.
Afin de garantir la cohérence des données entre les ressources et les processus qui les génèrent, des
modèles ont été définis. La définition des modèles JSON est réalisée pour mapper les propriétés de
plusieurs tables de base de données relationnelles avec les clés - valeurs dans les documents JSON. Seules
les propriétés importantes et les relations entre les tables ont été conservées. La figure 3.2, représente
un exemple de modèle défini en JSON pour les données imageries construits à partir les trois tables
différentes : Images, Imgacqcameraprofiles et Imagacstationprofiles. Ces tables correspondent comme leur
nom l’indique aux données images (horodatage, format, etc), aux profils caméra (balance des blancs,
saturation, etc,) ainsi qu’aux profils des cabines d’imageries (lumières, etc ..). Dans ce nouveau document
JSON sont représentés des données fixées par les systèmes existants et des nouvelles données calculées a
24

partir de traitements resultant de leur intégration.
1 Image{
2 "plant" : URI,
3 "plantAlias" : string,
4 "genotype" : URI,
5 " genotypeAlias " : string,
6 "experiment" : URI,
7 " experimentAlias " : string,
8 "study" : URI,
9 "studyAlias" : string,
10 "platform" : "http:// www.phenome -fppn.fr/m3p/",
11 " technicalPlateau " : "http:// www.phenome -fppn.fr/m3p/",
12 "timestamp" : int,
13 "date" : date,
14 " configuration " : {
15 "provider" : " phenowaredb",
16 "imgid" : int,
17 "plantid" : int,
18 "studyname" : string,
19 "taskid" : int,
20 "stationid" : int,
21 " imgacqprofileid " : int,
22 " nextLocation " : {
23 "lane" : int,
24 "rank" : int,
25 "level" : int,
26 }
27 },
28 " userValidation " : boolean,
29 " isReferenceImage " : boolean,
30 "viewType" : string,
31 " cameraAngle " : int,
32 "fileName" : string,
33 "serverPath" : "http://stck -lespe.supagro.inra.fr/",
34 " imageServerPath " : URI,
35 " imageWebPath " : URI,
36 " thumbServerPath " : URI,
37 " thumbWebPath " : URI,
38 " binaryServerPath " : " unspecified ",
39 " binaryWebPath " : "unspecified",
40 }
Figure 3.2: Le modèle JSON créé à partir des bases d’imageries
Dans quelques semaines à l’issus de ce stage, une application1
sera mise en œuvre pour convertir
automatique toutes les données dans la base de données relationnelles aux document de JSON sur la
base d’un modèle défini comme la figure 3.2. Les données, qui seront concernées par les processus de
mesures des plantes selon trois aspects d’imageries, d’arrosages, de pesées, seront converties sous forme
de documents de JSON. On peut voir les autres modèles qui sont complètement définies dans l’Annexe
A.
Aujourd’hui, toutes les données obtenues après la transformation seront synchronisées et stockées
dans le système MongoDB. La centralisation de données dans un seul système nous aide commodément
à définir les modèles généraux pour la transformation de données en RDF.
1https ://github.com/lengocluyen/phenowaredb-to-mongodb-convertor
25

3.4 Ontologies et domaine applicatif
Figure 3.3: L’ontologie de l’annotation d’images
Les différences entre des processus d’imageries, d’arrosage et de pesées demandent un diversité de
vocabulaires pour les décrire. Dans cette section, nous nous focalisons sur des vocabulaires de description
des données, des méta-données du processus d’imageries. Dans ce processus, de très nombreuses images
de plantes sont créées et doivent être stockées et être partagées. Une annotation d’images est nécessaire
pour fournir les méta-données afin d’aider compréhension et l’interprétation de l’image.
En général, plusieurs vocabulaires sont déjà disponibles pour faire de l’annotation d’images [16]. par
exemple, EXIF 2
est le format d’images de la plupart des appareils photo numériques. Il contient des
2https ://fr.wikipedia.org/wiki/Exchangeable imag file format
26

méta-données pour la date, l’heure, la localisation etc . Dublin Core3
fournit des vocabulaire de taille
réduite pour la description de ressources multimédia. Il recouvre ainsi les concepts de titre, créateur,
date, format etc. Ces vocabulaires fournissent les éléments nécessaires pour définir un modèle, mais ne
conviennent pas complètement pour les images traitées dans ce projet.
Afin de prendre en compte ces spécificités l’équipe INRA a construit une ontologie d’annotation
d’images [17]. On peut voir en détail le schéma de cette ontologie dans la figure 3.3.
3.5 xR2RML et Transformation de données en triplets
3.5.1 Le langage de mapping de données xR2RML
Après l’étape de transformation de données en JSON et leur importation dans MongoDB, il est
nécessaire de les transformer en triplets RDF. Pour cela, nous allons utiliser le langage de mapping
xR2RML pour transformer ces données en triplets RDF. Dans la partie de ”Matérialisation de données
aux triplets” du chapitre précédant, nous avons introduit ce langage. Nous verrons plus en detail dans
cette section la syntaxes pour créer le mapping entre un document JSON et la declaration des triplets
RDF.
Un mapping de triplet de xR2RML utilise une référence sur la source logique au lieu d’une table
logique dans R2RML. En particulier, le mapping xR2RML consist à :
ˆ Une propriété xrr :logicalSource. Son objet est une source logique qui spécifie une table ou un
résultat de requête pour être mappé avec un triplet.
ˆ Un mapping de sujet qui précise comment générer un sujet pour chaque élément de données de la
source logique (par exemple : une ligne de table, un document de collection, un ensemble d’éléments
XML etc). Ce mapping peut être spécifié dans deux fa¸cons suivantes :
En utilisant la propriété rr :SubjectMap, dont la valeur doit être le mapping de sujet
En utilisant la propriété constante rr :subject
ˆ Sans, une ou plusieurs propriétés rr :predicateObjectMap, dont les valeurs doivent être le mapping
de prédicate - objet. Ces mapping précisent les paires prédicat et objet qui, avec les sujets générés
par le mapping de sujet, peuvent former un ou plusieurs triplets RDF pour chaque élément de
données.
1 { "studyid": 10,
2 "acronym": "CAC2010",
3 "centres": [ {
4 "centreid": 4,
5 "name": "Hopital Lapeyronie"
6 },{
7 "centreid": 6,
8 "name": " Pontchaillou " }
9 ]
10 }
Figure 3.4: Un exemple de données dans MongoDB
3https ://fr.wikipedia.org/wiki/Dublin Core
27

1 <http:// example.org/study#10> st:involves
2 [ a rdf:Seq;
3 rdf:_1 "Hopital Lapeyronie ";
4 rdf:_2 " Pontchaillou ";
5 ].
Figure 3.5: Le triplet généré
43 <#Study >
44 xrr: logicalSource [
45 xrr:query ’’’db.studies.find(
46 { studyid:{ $exists:true } }) ’’’;
47 xrr:format xrr:JSON;
48 ];
49 rr:subjectMap [
50 rr:class st:study;
51 rr:template "http:// example.org/study#{$.studyid}";
52 ];
53 rr: predicateObjectMap [
54 rr:predicate st:involves;
55 rr:objectMap [
56 xrr:reference "$.centres .*. name" ];
57 rr:termType xrr:RdfSeq;
58 ];
Figure 3.6: Le mapping de xR2RML
Les figures 3.4, 3.5, 3.6 illustrent un exemple simple sur les données JSON stockées dans MongoDB,
la définition du mapping des propriétés et les résultats obtenus. Dans le mapping de données, il y a des
termes qui sont définies dans R2RML ou xR2RML que l’on peut l’identifier par le préfixe : rr :, rrx : etc.
Dans xR2RML, le mapping de terme (Term maps) est défini comme une fonction qui génère des
termes RDF à partir d’une ligne de la table logique. Il est soit un mapping de sujet, de prédicat, d’objet
ou de graphe. En particulier, un mapping de terme peuvent être exactement l’un des suivants : une valeur
constante (la propriété rr :constant), une valeur de colonne (la propriété rr :column elle peut se remplacer
par rml :reference ) et une valeur du template (la propriété rr :template). Il existe plusieurs mappings
de termes que l’on peut entièrement voir dans [14].
Avec les caractéristiques de ce langage, un outil4
est développé pour transformer automatiquement des
données relationnelles en triplets sur la meme base de mapping entre les deux. Cet outil est un système
qui, étant donnée un mapping xR2RML et une base de données d’entrée, fournit un accès à la sortie
d’ensemble de données RDF. Il a l’accès à un environnement d’exécution comprenant : une connexion à
la base de données d’entrée. Une formulation de référence applicable aux résultats des requêtes exécutées
sur la connexion.
3.5.2 Transformation de données en triplets
Sur la base du langage de mapping xR2RML et l’outil développé, La définition du mapping est créé
pour mapper les propriétés d’un document JSON avec des triplets. les vocabulaires de ces triplets sont
4https ://github.com/frmichel/morph-xr2rml/releases
28

fournis par l’ontologies ci-dessus. Dans la figure 3.7, les propriétés du document JSON d’images (les autres
sont définis dans l’Annexe B) vont être mappées aux sujets, prédicat et objet du triplet.
Après cette étape, nous avons obtenu 45 de millions de triplets pour l’annotation d’images à partir
d’environ 3.5 millions d’images contenues dans le système MongoDB. Cette transformation à nécessité
beaucoup de temps d’execution coté serveur à l’INRA (environ 20 heures). Ces données existent sous la
forme d’un graphe avec plusieurs instances.
1 @prefix xrr: <http://i3s.unice.fr/xr2rml#> .
2 @prefix rr: <http://www.w3.org/ns/r2rml#> .
3 @prefix ex: <http:// example.com/> .
4 @prefix rml: <http:// semweb.mmlab.be/ns/rml#> .
5 @prefix xsd: <http:// www.w3.org/2001/XMLSchema
#> .
6 @prefix rdfs: <http://www.w3.org/2000/01/rdf -
schema#> .
7 @prefix rdf: <http:// www.w3.org/1999/02/22-rdf -
syntax -ns#> .
8 @prefix f: <http://www.franz.com/> .
9 @prefix ia: <http:// www.mistea.supagro.inra.fr/
ontologies/2015/03/ imageAnnotation #> .
10 <#Image > a rr:TriplesMap;
11 xrr: logicalSource [
12 xrr:query """db.image.find({ ’configuration .
imgid ’ : {$exists: true} } )""";
13 ];
14 rr:subjectMap [
15 rr:template "{$.uri}";
16 rr:class ia:Image;
17 ];
19 rr:predicate ia:aboutEntity ;
20 rr:objectMap [ xrr:reference "$.context.plant
"; ];
21 rr:class ia:Plant;
22 ];
24 rr:predicate ia:timeStamp;
25 rr:objectMap [ xrr:reference "$.date "; ];
26 rr:datatype xsd:date;
27 ];
29 rr:predicate ia:hasFileName ;
30 rr:objectMap [ xrr:reference "$.fileName "; ];
31 rr:datatype xsd:string;
32 ];
34 rr:predicate ia:hasPlateau;
35 rr:objectMap [ xrr:reference "$.context.
technicalPlateau "; ];
36 rr:class ia: TechnicalPlateau ;
37 ];
39 rr:predicate ia: inImagingCycle ;
40 rr:objectMap [ xrr:reference "$. configuration .
taskid "; ];
41 rr:datatype xsd:integer;
42 ];
44 rr:predicate ia:hasPlateau;
technicalPlateau "; ];
46 rr:class ia: TechnicalPlateau ;
47 ];
49 rr:predicate ia: inImagingCycle ;
taskid "; ];
52 ];
54 rr:predicate ia: inAutomatonStudy ;
studyname "; ];
56 ];
58 rr:predicate ia: inExperiment ;
experiment "; ];
60 rr:class ia:Experiment;
61 ];
63 rr:predicate ia: hasCameraAngle ;
64 rr:objectMap [xrr:reference "$. cameraAngle ";];
66 ];
68 rr:predicate ia:hasViewType;
69 rr:objectMap [ xrr:reference "$.viewType "; ];
70 ];
72 rr:predicate ia: isReferenceImage ;
73 rr:objectMap [ xrr:reference "$.
isReferenceImage "; ];
74 rr:datatype xsd:boolean;
75 ];
77 rr:predicate ia: hasCameraProfile ;
imageCameraProfile "; ];
79 rr:class ia: CameraProfile ;
80 ];
82 rr:predicate ia: hasAcquisitionStationProfile ;
imageStationProfile "; ];
84 rr:class ia: AcquisitionStationProfile ;
85 ].
Figure 3.7: Le Mapping de données JSON en triplets
29

3.6 Conclusion
Dans cette partie, la définition du modèle de solution proposée est présentée avec les étapes que
nous allons réaliser pour la construction d’un système de connaissance. En développant l’outil de trans-
formations de données relationnelles en document JSON stockées dans MongoDB et en utilisant l’outil
xR2RML pour la transformation de données JSON en triplets, nous avons obtenu des graphes RDF très
volumineuses. Avec ces graphes, nous avons besoin d’un système de gestion de base de données pour le
gérer de manière efficace. Ceci sera présenté dans la partie prochaine.
30

Chapitre 4
Stockage et Indexation de données
RDF
4.1 Introduction
Avec les données obtenues dans la chapitre précédent, on a besoin d’avoir un meilleur système pour les
organiser et les stocker. Il existe actuellement plusieurs systèmes développés pour les données RDF mais
chaque système a des caractéristiques spécialisées concernant l’organisation et l’indexation des données.
Alors, on a besoin d’effectuer des tests sur la capacité de stockage, sur l’indexation, sur la performance,
sur l’optimisation du processus de chargement, des requêtes et des raisonnements de ces systèmes.
Ce chapitre introduit des méthodes d’organisation pour stocker et indexer les données RDF et
l’implémentation de ces données dans quelques systèmes courants. Plus précisément, la première sec-
tion présentera les deux approches d’organisation de données : sous la forme native qui construit un
nouveau système pour gérer les données par soi-même et sous la forme non-native qui utilise un système
de gestion de données existant pour stocker les données. Dans la deuxième partie, il y aura une intro-
duction à des entrepôts de données RDF ou “TripleStore” récents : l’architecture, les caractéristiques de
chaque système et aussi l’implémentation du stockage des données ces systèmes. Enfin, la représentation
d’une application pour accéder à des données issues de plusieurs sources sur la base d’un point d’accès.
4.2 Approche native et non-native
L’approche native fournit un moyen pour stocker des données RDF plus proche du modèle de données.
Il utilise la nature des triplets RDF et permet d’aborder les spécificités de son approche en graphe, tels
que la capacité à gérer la parcimonie des données et l’aspect dynamique de son schéma. Ces systèmes
peuvent être classés en deux types de stockage (la figure 4.1) : à base de disque qui est persistant ou à base
de mémoire qui est volatile. Le stockage persistant sur le disque est un moyen de stocker en permanence
des données RDF sur un système de fichiers. Ces implémentations peuvent utiliser des structures d’index
comme des arbres B+ par exemple.
Néanmoins, l’écriture et la lecture sur les disques peuvent provoquer un phénomène de goulot d’étranglement
31

dans le système. Alors, la solution de stockage des données en mémoire est à considérer pour éviter ce
phénomène. Le stockage des données RDF en mémoire alloue une certaine quantité de la mémoire prin-
cipale disponible pour stocker l’ensemble de la structure de graphe RDF. Comme le stockage persistant
sur le disque, ce stockage repose sur des techniques d’indexation. Avec les données stockées dans la
mémoire, certaines opérations seront coûteuses en temps : le chargement, l’analyse ou ”parsing” de fi-
chier de données RDF et aussi la création d’index. Par conséquent, un Triplestore RDF doit avoir une
représentation de données en mémoire efficace qui laisse suffisamment d’espace pour les opérations de
requêtes et de gestion de données.
Figure 4.1: La classificaiton des types de système de stockage RDF
L’approche non-native utilise un système de gestion de base de données pour stocker des données RDF
de fa¸con permanente. On profite du développement de plusieurs années de ces systèmes, par exemple, la
capacité de transactions ou de sécurité. Avec les systèmes de gestion de base de données relationnelles, on
peut distinguer la base de données avec schéma et la base de données sans schéma. Avec la base de données
avec schéma, les caractéristiques du schéma sont utilisées pour séparer des triplets en différentes tables.
Cette séparation peut être organisée sur la base de structure intrinsèque de triplets : le sujet, le prédicat
et l’objet, ou fondée sur les propriétés, les classes RDFS ou OWL. On a les trois fa¸cons d’organisation
de schéma : partitionnement vertical, table de propriétés et table de propriétés hiérarchiques. Avec la
base de données sans schéma, on utilise seulement des tables qui sont responsables du stockage de tous
les triplets, c’est ce que l’on appelle une table de triplet. Ces dernières années, les systèmes de gestion
de base de données émergent comme une bonne approche pour les données massives avec plusieurs
manières d’organisation de données : clé-valeur, orienté document, orienté colonne, orienté graphe, etc.
La motivation principale est de répondre à la distribution de grands ensembles de données sur un cluster
de matériel.
Dans l’approche non-native, les triplets sont parfaitement stockées avec l’implémentation d’indexa-
tion, le support des propriétés ACID (Atomicité, Cohérence, Isolation et Durabilité) et les optimisations
de requêtes de chaque système (SQL pour les base de données relationnelles, Cypher pour Neo4J etc).
Néanmoins, l’association de deux modèles de données (par exemple modèle en graphe et modèle relation-
nelle) a besoin de manipulations, de la synchronisation entre eux, on par exemple de transformation de
données, des requêtes SPARQL en SQL. Cela est coûteux en temps d’exécution et de transformation de
requêtes. On a encore des limitations sur la capacité d’inférence sur les données. Dans l’approche native,
on utilise des systèmes de gestion de base de données spécialisés pour les données RDF. Les données sont
32

thesis

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a thesis

Semelhante a thesis (20)

Mais de LE Ngoc Luyen

Mais de LE Ngoc Luyen (7)

thesis