Ce mémoire présente des approches pour résoudre le problème des données volumineuses en bioinformatique, en intégrant la capacité de recherche sémantique sur des données issues de la recherche agronomique. Deux principales approches sont décrites : la réécriture de requêtes et la matérialisation de données en triplets RDF, avec un focus sur cette dernière pour le développement pratique. Un benchmark a été réalisé sur divers systèmes de gestion de triplets pour évaluer le meilleur système en fonction des avantages et inconvénients identifiés.

1. 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

2. Remerciements
Je tiens `a remercier dans un premier temps, toute l’´equipe p´edagogique 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´e la partie th´eorique de celle-ci.
Je tiens `a exprimer toute ma reconnaissance `a M. Pierre LARMANDE qui est chercheur `a l’IRD et
Reponsbale de l’axe de donn´ees de l’Institut de Biologie Computationnelle, Mme. Anne TIREAU qui est
ing´enieur `a l’INRA Montpellier SupAgro dans l’UMR MISTEA, pour leur encardrement sans faille, le
suivi qu’ils ont apport´e `a mon stage, leurs conseils, les nombreuses discussions que nous avons pu avoir
tout au long de la r´ealisation 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´ejour de six mois en France.
Je tiens `a remercie ´egalement Mlle Caroline BENOIST secr´etaire du LIRMM, et Mlle NGUYEN Thi
Van Tu, secr´etaire de l’IFI pour ses aides `a 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´e avec eux durant
ces deux ans `a l’IFI.
Je voudrais aussi remercier aussi les confr`eres de l’Universit´e de Da Lat o`u je suis en train de travailler,
qui m’ont donn´e les meilleures conditions pour que je puisse bien passer ma scolarit´e `a l’IFI.
Enfin, j’adresse mes plus sinc`eres remerciements `a mes parents, mes fr`eres qui m’a toujours soutenue
et encourag´ee dans les moments les plus difficiles de ma scolarit´e `a l’IFI.
Merci `a tous et `a toutes
LE Ngoc Luyen
Da Lat - Viet Nam, automne 2015
i

3. R´esum´e
Depuis quelques ann´ees, le d´eluge de donn´ees dans plusieurs domaines de la recherche scientifique
soul`eve des d´efis dans le traitement et l’exploitation des donn´ees. La recherche dans le domaine bioinforma-
tique n’est pas ´epargn´ee par ce ph´enom`ene. Ce m´emoire pr´esente des approches pour r´esoudre le probl`eme
de donn´ees volumineuses stock´ees dans des entrepˆots NoSQL en y associant la capacit´e de recherche
s´emantique sur les donn´ees dans un contexte de recherche agronomique. Ces approches s´emantiques
permettent d’aider `a enrichir les donn´ees issues d’exp´eriences grˆace aux moteurs d’inf´erence g´en´erant
de nouvelles connaissances. Nous pouvons r´esumer ces deux approches d’une part avec la r´e´ecriture de
requˆetes et d’autre part avec la mat´erialisation de donn´ees en triplets RDF. Un ´etat de l’art nous a
permis d’identifier et d’´evaluer les diff´erentes m´ethodes se rapportant aux approches mentionn´ees. En
pratique, seule l’approche de mat´erialisation de donn´ees a ´et´e choisie pour continuer `a travailler. Les
donn´ees triplets obtenues ´etant volumineuses, nous avons r´ealis´e un benchmark sur diff´erents syst`emes
de gestion de base de donn´ees de triplets afin de pouvoir comparer les avantages et les inconv´enients de
chacun et de choisir le meilleur syst`eme pour notre ´etude de cas.
Mot-cl´es : Base de connaissance, Ontologie, Raisonnement, Inf´erence, SPARQL, xR2RML, Bench-
mark, NoSql, BigData, TripleStore
ii

4. 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

5. Table des mati`eres
Remerciements i
R´esum´e ii
Abstract iii
Table des mati`eres iv
Liste d’abr´eviations vi
Table des figures vii
Liste des tableaux ix
INTRODUCTION 1
Chapitre 1 Pr´esentation G´en´erale 2
1.1 Pr´esentation de l’´etablissement d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Pr´esentation de l’Institut de Biologie Computationelle (IBC) . . . . . . . . . . . . 2
1.1.2 Pr´esentation de l’Institut National de la Recherche Agronomique (INRA) . . . . . 3
1.2 Description du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Probl´ematiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Contexte de donn´ees massives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Contexte de recherche s´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapitre 2 ´Etat de l’art 11
2.1 Existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Analyse et ´evaluation des solutions courantes . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 MongoGraph - une association du Mongodb et AllegroGraph . . . . . . . . . . . . 11
2.2.2 Base de donn´ees orient´ee 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´erialisation de donn´ees en triplets RDF . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapitre 3 Solution propos´ee 23
iv

6. 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Mod`ele g´en´eral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Transformation et synchronisation de donn´ees dans MongoDB . . . . . . . . . . . . . . . . 24
3.4 Ontologies et domaine applicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 xR2RML et Transformation de donn´ees en triplets . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1 Le langage de mapping de donn´ees xR2RML . . . . . . . . . . . . . . . . . . . . . 27
3.5.2 Transformation de donn´ees en triplets . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapitre 4 Stockage et Indexation de donn´ees RDF 31
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Approche native et non-native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Vue g´en´erale des syst`emes 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´ementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapitre 5 Exp´erimentation, Comparaison et Analyse 42
5.1 Pr´eparation des donn´ees et du Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Benchmarking des platformes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Chargement de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.2 Recherche de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.3 Inf´erence sur les donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Evaluation et Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
CONCLUSION 53
R´EF´ERENCES 55
Annexe A Mod`ele de document JSON A.1
Annexe B Mappage de donn´ees JSON aux triplets par xR2RML B.5
Annexe C Point d’acc`es C.8

7. Liste d’abr´eviations
API Application Programming Interface
CRUD Create, Read, Update, Delete
D2R Database To RDF
DFS Distributed files 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

8. Liste des figures
1.1 L’architecture du web s´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 L’exemple d’un triplet Resource Description Framework (RDF). . . . . . . . . . . . . . . . 8
1.3 L’exemple d’une requˆete Protocol and RDF Query Langage (SPARQL). . . . . . . . . . . 8
2.1 Le mod`ele de composants dans un syst`eme MongoGraph . . . . . . . . . . . . . . . . . . . 12
2.2 Les donn´ees pr´esent´ees dans cet exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Une requˆete SPARQL associ´ee `a une requˆete de MongoDB . . . . . . . . . . . . . . . . . . 14
2.4 La graphe de donn´ees dans Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Les commandes pour cr´eer un graphe simple . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Les triplets sont stock´ees dans MongoDB sous la forme de JSON-LD . . . . . . . . . . . . 17
2.7 Le mod`ele de composants dans un syst`eme d’association de MongoDB et JSON-LD –
Create, Read, Update, Delete (CRUD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Le processus de requˆete dans le syst`eme d’ODBA . . . . . . . . . . . . . . . . . . . . . . . 19
2.9 La comparaison des approches des raisonnements dans une application . . . . . . . . . . . 19
2.10 L’architecture du syst`eme avec l’association de MongoDB et le mod`ele d’ODBA . . . . . . 20
2.11 Les deux tables et sa relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.12 Les informations d´efinies pour le mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.13 Les donn´ees RDF apr`es de la transformation . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Le mod`ele g´en´eral du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Le mod`ele JSON cr´e´e `a partir des bases d’imageries . . . . . . . . . . . . . . . . . . . . . 25
3.3 L’ontologie de l’annotation d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Un exemple de donn´ees dans MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Le triplet g´en´er´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Le mapping de xR2RML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Le Mapping de donn´ees JSON en triplets . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 La classificaiton des types de syst`eme 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´en´erale 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`eme d’interaction avec les donn´ees RDF . . . . . . . . . . . . . . . . . . 39
vii

9. 5.1 La comparaison du temps de chargement sur diff´erents TripleStores . . . . . . . . . . . . . 43
5.2 L’exemple de requˆete num´ero 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 L’evaluation de la requˆete num´ero 1 sous forme de courbe graphique . . . . . . . . . . . . 44
5.4 L’exemple de requˆetes num´ero 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5 L’evaluation de la requˆete num´ero 2 sous forme de courbe graphique . . . . . . . . . . . . 45
5.6 L’exemple de requˆete num´ero 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7 L’evaluation de la requˆete num´ero 3 sous forme de courbe graphique . . . . . . . . . . . . 46
5.8 L’exemple de troisi`eme requˆetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.9 L’evaluation de la requˆete num´ero 4 sous forme de courbe graphique . . . . . . . . . . . . 47
5.10 Les relations inf´er´ees sur l’ontologie dans le premier exemple . . . . . . . . . . . . . . . . . 48
5.11 La requˆete du premi`ere exemple d’inf´erence . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.12 Le temps d’ex´ecution de la premi`ere inf´erence sous forme de graphique . . . . . . . . . . . 49
5.13 Les relations inf´er´ees sur l’ontologie dans le deuxi`eme exemple d’inf´erence . . . . . . . . . 49
5.14 L’exemple de la deuxi`eme inf´erence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.15 Le temps d’ex´ecution de la deuxi`eme inf´erence sous forme de graphique . . . . . . . . . . 50

10. Liste des tableaux
1.1 La liste des types et des syst`eme de gestion de base de donn´ees dans Not Only SQL (NoSQL) 7
4.1 Les TripleStores et le type de stockage support´e . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Les encodages sp´eciaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Les comparaison de certaines fonctionnalit´es des diff´erents TripleStores . . . . . . . . . . . 40
5.1 La configuration du serveur exp´erimental . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 La comparaison du temps de chargement sur diff´erents TripleStores en millisecondes . . . 43
5.3 L’evaluation de la requˆete num´ero 1 (temps en millisecondes) . . . . . . . . . . . . . . . . 44
5.4 L’evaluation de la requˆete num´ero 2 (temps en millisecondes) . . . . . . . . . . . . . . . . 45
5.5 L’evaluation de la requˆete num´ero 3 (temps en millisecondes) . . . . . . . . . . . . . . . . 46
5.6 L’evaluation de la requˆete num´ero 4 (temps en millisecondes) . . . . . . . . . . . . . . . . 47
5.7 L’evaluation de la premi`ere inf´erence (temps en millisecondes) . . . . . . . . . . . . . . . 49
5.8 L’evaluation de la deuxi`eme inf´erence (temps en millisecondes) . . . . . . . . . . . . . . . 50
C.1 Les exemples de point d’acc`es de TripleStore . . . . . . . . . . . . . . . . . . . . . . . . . C.8
ix

11. Introduction
Les ´etudes sur les plantes ont toujours pris un rˆole important pour am´eliorer la productivit´e, la capacit´e
de r´esistance des plantes aux maladies, la r´eduction d’influence des changements de l’environnement et le
climat. Aujourd’hui, de plus en plus de laboratoires ont effectu´e des ´etudes sur les plantes et ont obtenus
des r´esultats importants. Les donn´ees de ces ´etudes sont des ressources utiles pour que les scientifiques
puissent les exploiter et les partager avec les autres. Aujourd’hui, il y existe une diversit´e d’outils qui sont
d´evelopp´es pour g´erer ces donn´ees. Mais chaque ´etude poss`ede des caract´eristiques diff´erentes qui sont
difficiles `a capturer dans des applications g´en´eriques. De plus, ces donn´ees ne cessent d’augmenter dans
chaque jour. Les tˆaches de gestion de donn´ees demandent des m´ethodes d’organisation optimis´ees.
Dans la carde du sujet de stage, deux projets d’´etudes sur les plantes sont r´ealis´es dans deux labora-
toires differents. L’un fait la recherche sur le ph´enotypage et le g´enotypage du riz asiatique. L’autre fait
la recherche sur le ph´enotypage et le g´enotypage du ma¨ıs en France. La caract´eristique commune entre
ces deux projets concerne la gestion et l’exploitation de gros volumes de donn´ees de mani`ere plus efficace.
Les travaux dans ce stage se focaliseront sur la recherche de solutions associant les domaines du web
s´emantique et celui des donn´ees massives. Ils nous permettront de chercher la meilleure solution possible
pour tout d’abord organiser le stockage des donn´ees massives et volumineuses dans un syst`eme de gestion
de base donn´ees sp´ecialis´e et ensuite renforcer la capacit´e de recherche s´emantique des donn´ees afin de
g´en´erer de nouvelles connaissances. Les connaissances dans le domaine de web s´emantique fournissent des
mod`eles pour structurer les donn´ees sous la forme de bases de reconnaissance et permettent la recherche
de donn´ees grˆace a des m´ecanismes de d’inf´erence et de raisonnement. Aujourd’hui, le probl`eme de gestion
de donn´ees massives a besoin de traiter avec l’optimisation du temps d’ex´ecution et le temps de recherche.
Ce pr´esent rapport se divise en cinq grandes parties. La premi`ere partie pr´esente les deux laboratoires
IBC et INRA, leurs projets de recherche actuels, les probl´ematiques du stage et les concepts existants
dans le domaine du web s´emantique et des donn´ees massives. La deuxi`eme partie fait un ´etat de l’art
sur les solutions actuelles et leurs applications dans le cas de nos donn´ees. La troisi`eme partie consiste `a
pr´esenter la solution propos´ee et les travaux mis en oeuvre pour la r´ealiser. La quatri`eme partie pr´esente les
syst`emes de gestion de base de donn´ees de triplets actuels. La cinqui`eme partie concerne l’exp´erimentation,
la comparaison et l’analyse des r´esultats dans un benchmark de ces syst`emes selon trois crit`eres : le
chargement de donn´ees, la recherche de donn´ees et l’inf´erence de donn´ees.
1

12. Chapitre 1
Pr´esentation G´en´erale
1.1 Pr´esentation de l’´etablissement d’accueil
1.1.1 Pr´esentation de l’IBC
L’Institut de Biologie Computationnelle a ´et´e cr´e´ee dans le but de d´evelopper des m´ethodes inno-
vantes et des logiciels pour analyser, int´egrer et contextualiser les donn´ees biologiques massives dans les
domaines de la sant´e, de l’agronomie et de l’environnement. Plusieurs branches de recherche y sont com-
bin´ees : l’algorithmique (combinatoire, num´erique, massivement parall`ele, stochastique), la mod´elisation
(discr`ete, qualitative, quantitative, probabiliste), et la gestion des donn´ees (int´egration, workflows, cloud).
Les concepts et les outils seront valid´es `a l’aide des applications cl´es en biologie fondamentale (transcrip-
tomique, la structure et la fonction des prot´eines, le d´eveloppement et la morphogen`ese), la sant´e (agents
pathog`enes, le cancer, les cellules souches), l’agronomie (g´enomique des plantes, de l’agriculture tropicale),
et de l’environnement (dynamique des populations, biodiversit´e). L’IBC est divis´e en cinq work-packages
qui comprennent les aspects principaux du traitement des donn´ees biologiques massives :
ˆ WP1-HTS : M´ethodes d’analyse de s´equen¸cage `a haut d´ebit
ˆ WP2-Evolution : Passage `a l’´echelle des analyses ´evolutives
ˆ WP3-Annotation :Annotation fonctionnelle et structurelle des prot´eomes
ˆ WP4-Imaging : Int´egration de l’imagerie cellulaire et tissulaire avec des donn´ees omiques
ˆ WP5-Databases : Donn´ees biologiques et int´egration des connaissances
L’IBC est un projet multidisciplinaire soutenu pendant cinq ans (2012-2017) par l’´etat Fran¸cais `a 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´egi´e pour les chercheurs en biologie et en bio-informatique, mais aussi une importante
communaut´e de chercheurs, universitaires et industriel au niveau r´egional, national et international. Les
activit´es 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´esultats et ´echanger
des informations avec des partenaires industriels.
2

13. La recherche sur le riz est un des mod`eles d’´etude abord´e par les chercheurs de l’IBC notamment `a
travers le projet BIOeSAI (Biological electronic System Assistant Index). Ce projet a pour objectif de
g´erer des ´etudes de diversit´e g´enotypique et ph´enotypique de vari´et´es traditionnelles de riz vietnamien
(Oryza sativa). L’objectif de ces ´etudes est d’identifier des g`enes d’int´erˆet pour qu’on puisse comprendre
les processus biologiques, par exemple : le d´eveloppement et la plasticit´e de la plante, la r´esistance aux
maladies. Ces ´etudes requi`erent la manipulation d’un volume important de donn´ees h´et´erog`enes. Ces
donn´ees peuvent ˆetre stock´ees sous des formes diff´erentes : fichier Excel, fichier texte structur´e, images
ou bases de donn´ees relationnelles.
1.1.2 Pr´esentation de l’INRA
L’INRA est un organisme de recherche fran¸cais pour l’agronomie fond´e en 1946. Les recherches men´ees
par l’INRA sont guid´ees par les questionnements scientifiques en lien aux d´efis plan´etaires pos´es par l’ali-
mentation, l’environnement et la valorisation des territoires. Changement climatique, nutrition humaine,
comp´etition entre cultures alimentaires et non alimentaires, ´epuisement des ressources fossiles, ´equilibre
dans la gestion des territoires sont autant d’enjeux qui positionnent l’agronomie comme fondatrice d’un
d´eveloppement harmonieux sur les plans ´economique, social et environnemental.
L’INRA produit des connaissances fondamentales et construit, grˆace `a elles, des innovations et des
savoir-faire pour la soci´et´e. Il met son expertise au service de la d´ecision publique. Les grandes missions
confi´ees `a l’INRA sont les suivantes :
ˆ Produire et diffuser des connaissances scientifiques.
ˆ Concevoir des innovations et des savoir-faire pour la soci´et´e.
ˆ ´Eclairer, par son expertise, les d´ecisions des acteurs publics et priv´es.
ˆ D´evelopper la culture scientifique et technique et participer au d´ebat science-soci´et´e.
ˆ Former `a la recherche et par la recherche.
Le centre INRA de Montpellier coordonne Ph´enome, un projet de plate-formes de ph´enotypage haut-
d´ebit de plantes cultiv´ees. Son objectif est de mesurer des caract`eres agronomiques de plantes soumises `a
diff´erents sc´enarios environnementaux et en particulier les conditions de stress hydrique. C’est un projet
sur huit ans regroupant neuf plates-formes r´eparties sur sept sites d’´etudes en France.
Les ´etudes couvrent `a la fois des probl´ematiques de recherche fondamentale en g´en´etique et de re-
cherche appliqu´ee pour la s´election de plantes adapt´ees `a des contextes climatiques particuliers.
Sur la plate-forme de Montpellier se trouve trois plateaux techniques diff´erents permettant de mesurer
la croissance de plantes en fonction de l’environnement :
ˆ Ph´enoPsis qui permet de peser et photographier plus de cinq cent plantes (Arabidopsis thaliana,
une plante mod`ele pour l’agronomie)
ˆ Ph´enoArch o`u plus de mille six cent plantes (ma¨ıs et autres c´er´eales, vigne, pommiers) sont d´eplac´ees
grˆace `a un automate afin de proc´eder `a diff´erentes mesures, portant notamment sur l’architecture
de la plante, et d’ˆetre photographi´ees dans des cabines d’imageries 3D.
3

14. ˆ Ph´enoDyn o`u 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´esentent des environnements
non contrˆol´es, avec des exp´erimentations en champ. Les donn´ees ph´enotypiques sont alors acquises grˆace
`a une Ph´enomobile (robot mobile autonome ´equip´e de capteurs embarqu´es) ou `a des drones.
Ces plate-formes sont sp´ecialis´ees en ´ecophysiologie, c’est-`a-dire dans l’´etude de l’influence de l’en-
vironnement sur la plante. Par cons´equent, pour l’ensemble des exp´erimentations r´ealis´ees, les donn´ees
issues des capteurs environnementaux sont primordiales. Ces donn´ees sont `a la fois h´et´erog`enes en termes
de formats, de s´emantique, etc. et volumineuses (plusieurs t´eraoctets par mois). Elles sont de plus reli´ees
entre elles au sein d’une experience et doivent pouvoir ˆetre trac´ees dans le temps.
Dans le contexte de Phenome, ces tr`es nombreuses donn´ees doivent ˆetre conserv´ees, partag´ees et ana-
lys´ees. Il faudra en effet ˆetre capable de les retrouver dans plusieurs ann´ees. De mˆeme, elles doivent pou-
voir ˆetre consult´ees et utilis´ees indiff´eremment par l’ensemble des neuf plates-formes. Enfin, les r´esultats
d’analyse et de calculs doivent ´egalement ˆetre reli´es aux donn´ees.
1.2 Description du stage
Dans le cadre du projet de l’´equipe G´enome et D´eveloppement des Riz, du LMI RICE (Hano¨ı), des
´etudes de la diversit´e g´enotypique et ph´enotypique de vari´et´es traditionnelles de riz vietnamien sont
conduites dans le but d’identifier des g`enes d’int´erˆet pour la compr´ehension de processus biologiques.
De la mˆeme mani`ere, les recherches du laboratoire INRA `a Montpellier ´evaluent les influences de l’envi-
ronnement sur les plantes. La caract´eristique commune entre ces deux projets est la manipulation d’un
important volume de donn´ees h´et´erog`enes. Ces donn´ees sont organis´ees dans des syst`emes de gestion de
base de donn´ees relationnelles ou des syst`emes de gestion de base de donn´ees NoSQL (MongoDB). Dans
ce contexte, les ´equipes souhaitent r´eorganiser leurs propres jeux de donn´ees afin de pouvoir naviguer,
partager, annoter et rechercher ces derni`eres afin de les exploiter au mieux.
Un syst`eme d’information a ´et´e impl´ement´e lors d’un stage de Master 1 en 2014[1] pour le projet
du LMI RICE (BIOeSAI). Ce syst`eme est bas´e sur un syst`eme de gestion base de donn´ees MongoDB
incluant ´egalement la gestion des m´etadonn´ees et des tags. Toutefois, la m´ethode mise en place ne permet
pas de d´etecter des relations explicites/implicites entre les donn´ees g´er´ees par le syst`eme.
L’objectif du stage propos´e sera d’´evaluer la faisabilit´e de gestion des BIG DATA coupl´e au techno-
logies du Web S´emantique en s’appuyant sur les articles de synth`ese du domaine [2]. Par ailleurs, nous
r´ealiserons un ´etat de l’art sur les probl`emes d’organisation des donn´ees massives et de l’augmentation de
la capacit´e de recherche sur les donn´ees. Plus particuli`erement, sur la capacit´e d’inf´erence et de raisonne-
ment sur les donn´ees. Un des objectifs du travail dans ce sujet sera de construire un base de connaissance
sur les donn´ees existantes.
1.3 Probl´ematiques
Les donn´ees biologiques existantes sont volumineuses et elles ne cessent d’augmenter chaque jour.
L’utilisation des syst`emes de gestion de base donn´ees relationnelles est aujourd’hui mal adapt´e pour g´erer
ces donn´ees[1]. L’´emergence des syst`emes de gestion de base de donn´ees NoSQL orient´e-document (e.g.
4

15. MongoDB) semble mieux adapt´e [3] toutefois ces systemes sont depourvus d’une capacit´e de recherche
s´emantique sur les donn´ees ce qui existent seulement sur les donn´ees RDF par utiliser par le language
SPARQL.
Les bases de donn´ees de type “triplestore” sont mieux adapt´ees pour faire des inf´erences ou des
raisonnements sur les donn´ees. Toutefois, elles passent moins bien `a l’´echelle sur des gros volumes de
donn´ees. En effet, la recherche ou l’inf´erence sur un grand volume de donn´ees RDF peuvent prendre
beaucoup de temps. L’enjeu dans la gestion de ce type de donn´ees est d’utiliser les capacit´es d’inf´erence
s´emantique avec de gros volumes de donn´ees.
L’association entre un syst`eme de donn´ees massives et les capacit´es de recherche s´emantique est
l’objectif principal du sujet.
1.4 Contexte du sujet
1.4.1 Contexte de donn´ees massives
Aujourd’hui, nous entrons dans l’`ere des Big Data. Des ensembles de donn´ees tellement gigantesques
qu’ils n´ecessitent de nouveaux outils techniques et scientifiques pour les comprendre et en tirer du sens.
Un d´eluge de donn´ees qui pose des questions profondes sur leur collecte, leur interpr´etation, leur analyse
etc. Les prochains enjeux de ce si`ecle sont d’extraire du sens de ces masses d’information qui circulent sur
les r´eseaux. Dans ce domaine, c’est avec la g´enomique et le ph´enotypage que la biologie est d´ej`a entr´ee
dans le monde des big data. Certes, l’imagerie ou la mod´elisation m´etabolisme produisaient des donn´ees
num´eriques, mais la question de leur gestion et de leur exploitation ne se posait pas de la mˆeme fa¸con.
En termes d’exploitation des donn´ees, beaucoup reste `a faire en biologie. C’est mˆeme l`a que se situe le
grand d´efi des big data en sciences de la vie : rattraper le foss´e grandissant entre production massive de
donn´ees et la capacit´e `a en extraire une information, voir une connaissance.
Le Big Data s’accompagne du d´eveloppement d’applications `a vis´ee analytique, qui traitent les donn´ees
pour en tirer du sens. Ces analyses sont appel´ees Big Analytics ou “broyage de donn´ees”. Elles portent
sur des donn´ees quantitatives complexes avec des m´ethodes de calcul distribu´e.
En effet, les donn´ees massives d´esignent des ensembles de donn´ees tellement volumineux qu’il en
devient difficile de travailler avec des outils classiques des gestion de base de donn´ees ou de gestion de
l’information. Les Big Data sont souvent d´efinis en utilisant l’acronyme 3V pour Volume, V´elocit´e et
Vari´et´e [4].
La volume se r´ef`ere `a des quantit´es massives de donn´ees qui sont disponibles, le volume des donn´ees
stock´ees est en pleine expansion : les donn´ees num´eriques cr´e´ees dans le monde seraient pass´ees de 1,2
zettaoctets par an en 2010 `a 1,8 zettaoctets en 2011, puis 2,8 zettaoctets en 2012 et s’´el`everont `a 40
zettaoctets en 2020[5]. `A titre d’exemple, Twitter g´en´erait en janvier 2013, 7 teraoctets de donn´ees
chaque jour et Facebook 10 teraoctets[6].
La v´elocit´e repr´esente `a la fois la fr´equence `a laquelle les donn´ees sont g´en´er´ees, captur´ees et partag´ees
et mises `a jour. Quelquefois, la v´elocit´e se r´ef`ere `a la v´elocit´e n´ecessaire pour traiter, analyser et utiliser
les donn´ees.
Le volume des Big Data met les data centers devant un r´eel d´efi : la vari´et´e des donn´ees. Il ne s’agit pas
5

16. de donn´ees relationnelles traditionnelles, ces donn´ees sont brutes, semi-structur´ees voire non structur´ees
(cependant, les donn´ees non-structur´ees devront, pour utilisation, ˆetre structur´ees). Ce sont des donn´ees
complexes provenant du web, au format texte et images. Elles peuvent ˆetre publiques (Open Data, Web
des donn´ees), g´eo-d´emographiques par ˆılot (adresses IP), ou relever de la propri´et´e des consommateurs.
Ce qui les rend difficilement utilisables avec les outils traditionnels.
Pour r´epondre aux probl´ematiques Big Data l’architecture de stockage des syst`emes doit ˆetre repens´ee
et les mod`eles de stockage se multiplient en cons´equence :
ˆ Cloud computing : l’acc`es se fait via le r´eseau, les services sont accessibles `a la demande et en libre
service sur des ressources informatiques partag´ees 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`emes de fichiers distribu´ees Distributed files system (DFS) : les donn´ees ne sont plus stock´ees sur
une seule machine car la quantit´e `a stocker est beaucoup trop importante. Les donn´ees, les fichiers
sont “d´ecoup´es” en morceaux d’une taille d´efinie et chaque morceau est envoy´e sur une machine
bien pr´ecise utilisant du stockage local. Le stockage local est pr´ef´er´e au stockage SAN (Storage Area
Network)/NAS (Network attached storage) pour des raisons de goulots d’´etranglement au niveau
du r´eseau et des interfaces r´eseaux des SAN. De plus, utiliser un stockage de type SAN coˆute bien
plus cher pour des performances bien moindres. Dans les syst`emes de stockage distribu´e pour le
Big Data, l’on introduit le principe de “Data locality”. Les donn´ees sont sauvegard´ees l`a o`u elles
peuvent ˆetre trait´ees.
Les bases de donn´ees relationnelles classiques ne permettent pas de g´erer les volumes de donn´ees
du Big Data. De nouveaux mod`eles de repr´esentation permettent de garantir les performances sur les
volum´etries en jeu. Ces technologies, dites de Business Analytics, Optimization permettent de g´erer des
bases massivement parall`eles. Des patrons d’architecture “Big Data Architecture framework” sont pro-
pos´es par les acteurs de ce march´e comme MapReduce d´evelopp´e par Google et utilis´e dans le framework
Hadoop. Avec ce syst`eme les requˆetes sont s´epar´ees et distribu´ees `a des nœuds parall´elis´es, puis ex´ecut´ees
en parall`eles . Les r´esultats sont ensuite rassembl´es et r´ecuper´es. Teradata, Oracle ou EMC proposent
´egalement de telles structures, bas´ees sur des serveurs standards dont les configurations sont optimis´ees.
Ils sont concurrenc´es par des ´editeurs comme SAP (Systems, Applications, et Products) et plus r´ecemment
Microsoft. Les acteurs du march´e s’appuient sur des syst`emes `a forte scalabilit´e horizontale et sur des
solutions bas´ees sur du NoSQL plutˆot que sur des bases de donn´ees relationnelles classiques.
Avec les donn´ees dans nos laboratoires, le probl`eme de gestion des donn´ees massives ne peut pas ˆetre
r´esolu avec les syst`emes de gestion de base de donn´ees relationnelles. Ces syst`emes deviennent lourds et
lents sur ces types de donn´ees. Ces derni`eres ann´ees, ont vu l’´emergence d’une diversit´e de syst`emes de
gestion de base de donn´ees que l’on appelle NoSQL. Ces syst`emes NoSQL, proposent plusieurs modeles
pour organiser et stocker les donn´ees (la table 1.1).
6

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

18. qui devrait rendre cela possible, n’a pas encore ´emerg´e, mais quand ce jour sera atteint, les m´ecanismes
de dialogue entre les machines sera facilite. Les “agents intelligents” qu’on nous promet depuis longtemps
vont enfin se concr´etiser”[7] [8], le web s´emantique ´emerge comme la meilleure solution pour traiter
des donn´ees directes ou indirectes par des machines, partager et r´eutiliser des donn´ees entre plusieurs
applications et aider les utilisateurs `a cr´eer de nouvelles connaissances.
Dans le contexte d’application orient´e web s´emantique et la gestion de donn´ees biologiques, nous allons
focaliser sur les trois parties principales suivantes : Le repr´esentation de donn´ees en RDF, les requˆetes
avec SPARQL et les inf´erences, 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`ele de graphe destin´e `a d´ecrire la donn´ee de fa¸con `a permettre son traitement
automatique par des machines. RDF donne une description par triplet <Sujet, Pr´edicat, Objet>. Le sujet
repr´esente la ressource `a d´ecrire, le pr´edicat repr´esente un type de propri´et´e applicable `a cette ressource,
et l’objet repr´esente une donn´ee ou une autre ressource. Les documents RDF peuvent ˆetre ´ecrits en
diff´erents 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´ees constitu´ee de nœuds et organis´ee en graphe. Un
document RDF ainsi form´e correspond `a un multi-graphe orient´e ´etiquet´e. Ici, chaque triplet correspond
alors `a un arc orient´e dont le label est le pr´edicat, 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ˆete SPARQL.
Le SPARQL est un langage de requˆetes pour interroger des donn´ees qui sont stock´ees en respectant
le mod`ele RDF. Les requˆetes SPARQL sont adapt´ees `a la structure sp´ecifique des graphes RDF, et
s’appuient sur structure sous la forme de triplets. En cela, il est diff´erent du classique SQL, mais s’en
inspire clairement dans sa syntaxe et ses fonctionnalit´es. Le SPARQL permet d’exprimer des requˆetes
interrogatives ou constructives : une requˆete SELECT, de type interrogative, permet d’extraire du graphe
RDF un sous-graphe correspondant `a un ensemble de ressources v´erifiant les conditions d´efinies dans une
8

19. clause WHERE ; une requˆete CONSTRUCT, de type constructive, engendre un nouveau graphe qui
compl`ete le graphe interrog´e.
L’Ontologie
L’Ontologie est un ensemble structur´e de termes et concepts repr´esentant le sens d’un champ d’in-
formations, que ce soit par les m´etadonn´ees d’un espace de noms, ou les ´el´ements d’un domaine de
connaissances. L’ontologie constitue en soi un mod`ele de donn´ees repr´esentatif d’un ensemble de concepts
dans un domaine, ainsi que des relations entre ces concepts. Elle est employ´ee pour raisonner `a propos des
objets du domaine concern´e. Plus simplement, nous pouvons aussi dire que l’ “ontologie est aux donn´ees
ce que la grammaire est au langage”.
Les conceptions utilisent pour d´ecrire d’une ontologies g´en´erales :
ˆ Individus : les objets de base
ˆ Classes : ensembles, collections, ou types d’objets
ˆ Attributs : propri´et´es, fonctionnalit´es, caract´eristiques ou param`etres que les objets peuvent poss´eder
et partager
ˆ Relations : les liens que les objets peuvent avoir entre eux
ˆ Ev´enements : changements subits par des attributs ou des relations
ˆ M´eta-classes : des collections de classes qui partagent certaines caract´eristiques
L’inf´erence, le raisonnement
L’inf´erence sur le Web s´emantique est l’un des outils de choix pour am´eliorer la qualit´e de l’int´egration
de donn´ees sur le web, en d´ecouvrant de nouvelles relations, analyse automatiquement le contenu des
donn´ees, ou la gestion des connaissances sur le web en g´en´eral. Les Techniques `a base d’inf´erence sont
aussi importante dans la d´ecouverte d’´eventuelles incoh´erences dans les donn´ees int´egr´ees.
Un exemple simple peut aider `a bien comprendre `a la conception de l’inf´erence. Les donn´ees fix´ees
pour ˆetre consid´er´ees peuvent inclure la relation (HaiPhong isPartOf the North Vietnam). Une ontologie
peut d´eclarer que “The North of VietNam isPartof Vietnam”. Cela signifie que d’un programme de Web
s´emantique comprendre la notion de “X ispartOf Y” peut ajouter la d´eclaration “HaiPhong isPartOf
Vietnam” `a l’ensemble des relations, bien que cela ne faisait pas partie des donn´ees originales. On peut
dire aussi que la nouvelle relation a ´et´e “d´ecouverte”.
D’une mani`ere g´en´erale, Les inf´erences sur le web s´emantique peut ˆetre caract´eris´ee par la d´ecouverte
de nouvelles relations. Sur le Web s´emantique, les donn´ees sont mod´elis´ees comme un ensemble de relations
entre les ressources. “l’Inf´erence” signifie que les proc´edures automatiques peuvent g´en´erer de nouvelles
relations fond´ees sur les donn´ees et sur la base des informations suppl´ementaires sous la forme d’un
vocabulaire, un ensemble de r`egles. Que les nouvelles relations sont explicitement ajout´ees `a l’ensemble
des donn´ees, ou sont retourn´ees au moment de la requˆete, est une question de mise en oeuvre.
Sur le Web s´emantique, la source de telles informations suppl´ementaires peut ˆetre d´efinie par l’in-
term´ediaire de vocabulaires ou ensembles de r`egles. Ces deux approches font appel aux techniques de
repr´esentation des connaissances. En g´en´eral, les ontologies se concentrent sur les m´ethodes de classifica-
tion, en mettant l’accent sur la d´efinition de de “classes”, “sous-classes”, sur la fa¸con dont les ressources
9

20. individuelles peuvent ˆetre associes `a ces classes, et de caract´eriser les relations entre les classes et leurs ins-
tances. D’autre part, les r`egles se concentrent sur la d´efinition d’un m´ecanisme g´en´eral sur la d´ecouverte
et la g´en´eration de nouvelles relations fond´ees sur celles qui existent d´ej`a tout comme les programmes
logiques, tel Prolog. Dans la famille du Web s´emantique li´e 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´efinir des ontologies, alors
que Rule Interchange Format (RIF) a ´et´e d´evelopp´e pour couvrir les approches bas´ees sur des r`egles.
10

21. Chapitre 2
´Etat de l’art
2.1 Existants
Depuis plusieurs ann´ees des ´etudes en ph´enotypage haut-d´ebit des plantes sont r´ealis´ees `a l’INRA.
Il existe donc un grand nombre de donn´ees de ph´enotypage et de g´enotype des plantes. Ces donn´ees
sont acquises chaque jour, par exemple sur le plateau technique PhenoArch, environ 1600 plantes sont
suivies pendant deux `a trois mois. Chaque jours elles sont photographi´ees sous trois `a treize angles,
ce cycle journalier d’imagerie produit donc environ 20800 images stock´ees. Celles-ci sont associ´ees `a
des configuration et des r´esultats d’analyse d’image sous la forme de JSON. Chaque document JSON
est environ 40 champs. Pour les g´erer, les informaticiens ont d´ej`a construits un syst`eme d’information
appel´e Phenotyping Hybrid Information System (PHIS)1
. Les donn´ees permettant l’exploitation de la
plateforme sont stock´ees dans une base de donn´ees relationnelles. Avec les limitations de base de donn´ees
relationnelles, ces donn´ees doivent ˆetre migr´ees dans une base MongoDB pour am´eliorer le temps de
performance du syst`eme.
La mˆeme fa¸con, le projet BIOeSAI est entr´ee dans une deuxi`eme phase `a partir de 2015 `a 2018.
Les ´etudes de la premi`ere phase ont ´et´e r´ealis´ees sur riz (O.SATIVA). Ce sont des donn´ees h´et´erog`enes
et volumineuses sur le ph´enotypages et g´enotypes du riz. Le laboratoire a aussi construit un syst`eme
d’information pour g´erer les donn´ees Syspherice2
[1]. Ces donn´ees sont organis´ees et stock´ees sous la forme
de document JSON. Elles sont g´er´ees par le syst`eme de gestion de base de donn´ees orient´e document
MongoDB.
2.2 Analyse et ´evaluation des solutions courantes
2.2.1 MongoGraph - une association du Mongodb et AllegroGraph
AllegroGraph est une base de donn´ees de graphe RDF persistante. Il utilise le stockage sur sur disque,
ce qui lui permet de passer `a l’´echelle des milliards de triplets, tout en maintenant une performance
sup´erieure. AllegroGraph est un framework de base de donn´ees et d’outils pour construire des applications
Web s´emantique. Il peut stocker des donn´ees et des m´eta-donn´ees, il permet aussi d’interroger ces triplets `a
1http ://lps-phis.supagro.inra.fr/phis/index.php
2http ://vmbioesai-dev.ird.fr :8080/Syspherice
11

22. travers diff´erentes APIs comme SPARQL et Prolog. De plus, il fourni des fonctionnalit´es de raisonnement
RDFS++ avec son raisonneur int´egr´e. AllegroGraph inclut ´egalement une librairie d’analyse de r´eseaux
sociaux (SNA) et il permet de stocker et raisonner sur des donn´ees temporelles et g´eospatiales.
Actuellement, il existe diff´erentes ´editions d’AllegroGraph : une ´edition gratuite o`u stockage RDF est
limit´ee `a moins de 5 millions de triplets, une ´edition d´eveloppeur capable de stocker un maximum de
50 millions de triplets et une ´edition d’entreprise avec une capacit´e de stockage qui n’est limit´ees 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´ees `a l’application de Web s´emantique, AllegroGraph impl´emente une interface
avec MongoDB, que l’on appelle MongoGraph. Celle-ci permet d’offrir aux programmeurs MongoDB les
capacit´e du Web s´emantique. En utilisant cette approche, les objets Javascript Object Notation (JSON)
sont automatiquement convertis en triplets et ils peuvent ˆetre interrog´es `a la fois par le langage de requˆete
MongoDB et par SPARQL.
Figure 2.1: Le mod`ele de composants dans un syst`eme MongoGraph
MongoDB est une base de donn´ees
orient´ees documents NoSQL de haute
performance et Open Source. MongoDB
fournit un stockage bas´e sur des docu-
ments en forme de JSON avec comme
fonctionnalit´es l’indexation en texte
int´egral, la r´eplication, la r´epartition des
de donn´ees (sharding), le calcul Map/Re-
duce et un langage de requˆete riche `a base
de documents. Toutefois, il ne fournit pas
un bon support pour les jointures com-
plexes, le liage de donn´ees (linked data),
l’analyse de graphe et l’inf´erence ou le
raisonnement.
En connectant AllegroGraph `a Mon-
goDB, il est possible d’interroger des
donn´ees li´ees en graphe et dans une
base de donn´ees orient´ees documents en
une seule requˆetes. Avec MongoDB, les
donn´ees sont organis´ees en forme des do-
cuments JSON, ils sont g´er´ees par un
syst`eme de gestion de base de donn´ees
orient´ees documents des plus efficace [9]. Avec AllgroGraph, les donn´ees sont organis´ees en graphe, sur
lesquelles nous pouvons r´ealiser facilement des requˆetes SPARQL, et aussi effectuer des inf´erences sur ces
donn´ees.
Avec les caract´eristiques des deux syst`emes de gestion de base de donn´ees, il est possible de construire
un syst`eme qui a des capacit´es de requˆetes du Web s´emantique et qui peut traiter des donn´ees volumi-
neuses. Le mod`ele du syst`eme g´en´eral de MongoDB et de AllegroGraph est mis en oeuvre Figure 2.1.
12

23. Ici, les donn´ees d’origines restent stock´ees dans MongoDB sous le format documents dans des collections.
Les nouveaux triplets mis en relation avec les documents MongoDB sont import´es dans AllegroGraph.
Pour cr´eer 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´ee pour l’organisation s´emantique des
triplets cr´e´es. Cette ontologie permet l’inf´erence en exploitant les relations entre les triplets. Ainsi le
moteur d’inf´erence peut cr´eer de nouvelles relations sur la base de l’ontologie d´efinie.
(a) Les donn´ees JSON dans MongoDB (b) Les donn´ees RDF dans AllegroGraph
(c) L’ontologie de lieu origine de plante
Figure 2.2: Les donn´ees pr´esent´ees dans cet exemple
Pour mieux comprendre la solution d’association de MongoDB et de AllegroGraph et illustrer les
requˆetes et l’inf´erence, nous avons pris un exemple sur les donn´ees existantes du projet BIOeSAI. Ce projet
contient une ontologie sur les relations entre le lieu d’origine des plantes et les images exp´erimentales sur
les plantes. Les triplets sont cr´e´es `a 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´etails des donn´ees JSON dans MongodDB, des donn´ees RDF qui ont ´et´e li´es aux documents
MongoDB et l’ontologie de r´ef´erences dans Figure 2.2.
13

24. Nous pouvons faciliter l’importation des donn´ees RDF dans AllegroGraph en utilisant la forme d’un
d´epˆot, “Repository”. La cr´eation d’une connexion avec MongoDB est effectu´e dans l’interface de Allegro-
Graph. Ici, les informations de la base de donn´ees MongoDB doivent ˆetre rempli, par exemple : le nom
et port du serveur, le nom de la base de donn´ees et la collection choisie.
AllegroGraph poss`ede deux types diff´erents de moteur d’inf´erence : l’un supporte un sur-ensemble de
r`egles d’inf´erence RDFS et l’autre supporte Web Ontology Rule Language (OWL 2 RL). Le premier est
appel´e le raisonneur RDFS++ dynamique car il g´en`ere les triplets inf´er´es `a l’ex´ecution de l’inf´erence et
n’enregistre pas les triples nouveaux cr´e´es. Le second moteur d’inf´erence fait de la mat´erialisation OWL
2 RL. Il utilise de r`egles d’inf´erence pour g´en´erer de nouveaux triplets et les ajoute `a la base de triplets
courante. Pour notre exemple, le second moteur d’inf´erence est choisi pour toutes les donn´ees. Apr`es
avoir ex´ecut´e, nous avons les nouveaux triplets sont stock´es de mani`ere p´erenne sur le disque comme les
triplets d’origine. Cela est le mieux pour les syst`emes qui ont plusieurs requˆetes.
Les requˆetes sont r´ealis´ees grˆace au langage SPARQL int´egrant des requˆetes MongoDB (Figure 2.3).
Cette association est effectu´ee par l’utilisation d’une approche que l’on appelle “Magic Predicat”. C’est
un pr´edicat d’une requˆete SPARQL qui permet une liaison, diff´erente d’un simple appariement de sous-
graphe. AllegroGraph a longtemps soutenu l’utilisation de “Magic Predicat” pour permettre les requˆetes
en texte libre et pour interfacer Solr et MongoDB. Dans la requˆete Figure 2.3, le syst`eme va effectuer
deux requˆetes dans deux syst`emes diff´erents pour obtenir les r´esultats. Les requˆetes seront ex´ecut´ees dans
MongoDB pour trouver les r´esultats sous le format de JSON, et les r´esultats finaux (les triplets) seront
trouv´es dans AllegroGraph.
Figure 2.3: Une requˆete SPARQL associ´ee `a une requˆete de MongoDB
Avantages
ˆ AllegroGraph permet de r´ealiser des inf´erences sur des donn´ees massives
ˆ Selection possible des propri´et´es importantes et donc r´eduction du nombre de triplets dans la base
de donn´ees.
ˆ Gestion de base de donn´ees massives avec MongoDB
Inconvenients
ˆ Un syst`eme plus complexe avec plusieurs ´etapes de requˆetes
ˆ Mapping manuel des donn´ees entre les deux syst`emes MongoDB et AllegroGraph
14

25. ˆ Pas de synchronisation entre les deux, quand nous mettons `a jour au MongoDB, nous devons le
faire aussi sur Allegograph
2.2.2 Base de donn´ees orient´ee graphe Neo4j
Neo4j est un syst`eme de gestion de base de donn´ees orient´e graphe, ce qui permet de repr´esenter les
donn´ees en tant qu’objet reli´e par un ensemble de relations, chaque objet poss´edant ses propres propri´et´es.
La base de donn´ees de graphes, permet au d´eveloppeur de commencer directement le codage, les donn´ees
stock´ees dans la base assurant un parall´elisme direct avec les donn´ees elles-mˆemes. En d’autres termes, `a
mesure que l’organisation des donn´ees se peaufineront, les programmes suivront.
Une base Neo4j est cens´ee ˆetre plusieurs milliers de fois plus rapide pour traiter les donn´ees associa-
tives, car elle en ´evite de coˆuteuses jointures Structured Query Language (SQL). Les requˆetes peuvent
g´erer de ce fait plus facilement un large ensemble de donn´ees. Les parcours utilisent un langage simple
de parcours des connections. L’absence de mod´elisation rigide, rend Neo4j bien adapt´e `a la gestion de
donn´ees changeantes et de sch´emas ´evoluant fr´equemment.
Les caract´eristiques typiques de donn´ees pour Neo4j sont la structuration des donn´ees optionnelles
qui sont peuvent absenter, une facilit´e de changement du sch´ema et des migrations de donn´ees sans
contraintes, la mod´elisation facile de jeux de donn´ees de domaines complexes et cas d’utilisation typique
dans des domaines tels que le Web s´emantique et RDF, le Web de donn´ees, l’analyse du g´enome, la
mod´elisation de donn´ees de r´eseaux sociaux etc.
Neo4j a des composants optionnels qui viennent en compl´ement du noyau. On peut ainsi structurer le
graphe via un m´eta-mod`ele, obtenir une impl´ementation 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´ees dans Neo4j
Les graphes de donn´ees dans Neo4j sont illustr´es par les concepts de ”Nodes” et de ”Relations”
3https ://github.com/neo4j-contrib/neo4j-rdf-sail
4https ://github.com/niclashoyer/neo4j-sparql-extension
15

26. Figure 2.4. D’ailleurs, le langage de requˆete Cypher est utilis´e pour manipuler les donn´ees. C’est un
langage d´eclaratif de requˆete graphique qui permet de r´ealiser efficacement et rapidement des requˆetes
et des mis `a jour sur les donn´ees. En d´etail, le langage Cypher se concentre sur la clart´e d’expression de
ce que l’on veut r´ecup´erer `a partir d’un graphique et pas sur la fa¸con de le r´ecup´erer. Cette approche
permet l’optimisation des requˆetes.
Figure 2.5: Les commandes pour cr´eer un graphe simple
Avantages
ˆ Gestion de base de donn´ees pour le Big Data sous la forme de graphes, donc amelioration de la
performance du syst`eme par des requˆetes bas´ees sur des relations entre les objets.
ˆ L’organisation de donn´ees sous forme de graphe est presque similaire `a l’organisation des donn´ees
dans les ontologies et les instances donn´ees RDF.
Inconv´enients
ˆ Les donn´ees doivent ˆetre re-organiser sous la forme d’un graphe, cela prendre plus de temps en
fonction de la complexit´e et de la taille de donn´ees.
ˆ Les donn´ees ne sont pas en RDF directement, donc pour faire des requˆetes SPARQL nous utilisons
un plugin int´egr´e qui ne supporte pas enti`erement le language SPARQL.
2.2.3 JSON-LD et MongoDB
Les donn´ees li´ees se r´ef`erent `a un ensemble de bonnes pratiques `a mettre en oeuvre pour publier et lier
des donn´ees structur´ees sur le web. Elles s’appuient sur les standards du Web, tels que HTTP et URI -
mais plutˆot qu’utiliser ces standards uniquement pour faciliter la navigation par les ˆetres humains, le Web
des donn´ees les ´etend pour partager ´egalement l’information entre machines. Cela permet d’interroger
automatiquement les donn´ees, quels que soient leurs lieux de stockage et sans avoir `a les dupliquer.
JSON-LD est une syntaxe l´eg`ere pour s´erialiser des donn´ees li´ees de la forme de JSON. Son utilisation
permet `a des donn´ees JSON d’ˆetre interpr´et´ees comme des donn´ees li´ees avec des changements minimes.
JSON-LD est principalement destin´e `a ˆetre un moyen d’utiliser les donn´ees li´ees dans des environnements
de programmation bas´es sur le Web, pour construire des services Web interop´erables, et pour stocker des
donn´ees li´ees dans les moteurs de stockage `a base de JSON. Actuellement, JSON-LD est compatible avec
JSON, un grand nombre de parseurs JSON et de biblioth`eques sont disponibles aujourd’hui et peuvent
ˆetre r´eutilis´es. En plus de toutes les fonctionnalit´es JSON, JSON-LD introduit :
ˆ Un m´ecanisme d’identifiant universel pour les objets JSON via l’utilisation d’IRIs
16

27. ˆ Un moyen de lever l’ambigu¨ıt´e de cl´es partag´ees entre des documents diff´erents par des mappings
en IRI via un contexte
ˆ Un m´ecanisme dans lequel une valeur dans un objet JSON peut se r´ef´erer `a un objet JSON sur un
autre site sur le web
ˆ La possibilit´e d’annotation des chaˆınes de caract`eres avec la langue et d’associer les types de donn´ees
avec des valeurs telles que la date et l’heure
ˆ La facilit´e d’exprimer un ou plusieurs graphes orient´es comme un r´eseau social en un seul document.
JSON-LD est destin´e `a ˆetre utilisable directement comme JSON qui ne contient pas des connaissances
de RDF. Il est ´egalement con¸cu pour ˆetre utilisable comme RDF. On peut l’utiliser avec d’autres tech-
nologies de donn´ees li´ees comme SPARQL. Les projets qui ont besoin de traiter les donn´ees comme des
graphes RDF vont trouver une solution avec la forme de JSON-LD. En d´etail, le document JSON-LD est
Figure 2.6: Les triplets sont stock´ees dans MongoDB sous la forme de JSON-LD
`a la fois un document RDF et un document de JSON et repr´esente une instance d’un mod`ele de donn´ees
RDF. Cependant, JSON-LD ´etend le mod`ele de donn´ees RDF pour s´erialiser des ensembles de donn´ees
RDF.
Figure 2.7: Le mod`ele de composants
dans un syst`eme d’association de Mon-
goDB et JSON-LD – CRUD
Le format de donn´ees RDF est organis´e en JSON-LD, ce qui
convient au format JSON utilis´e dans MongoDB. Alors, nous
pouvons profiter de la puissance de MongoDB pour r´esoudre
le probl`eme de grandes donn´ees. D’ailleurs, nous facilitons la
s´erialisation des donn´ees de graphes RDF dans MongoDB.
La graphe de donn´ees RDF peut ˆetre organis´e et stock´e dans
la m´emoire 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ˆetes
et appliquer des r`egles et faire des inf´erences sur les donn´ees. Les
recherches vont directement se faire sur les graphes RDF qui sont
s´erialis´es (charg´es) `a partir des donn´ees dans MongoDB, cette ´etape
va prendre du temps. Nous avons alors besoin d’une m´ethode pour
organiser les donn´ees importantes. Cette ´etape est importante pour
optimiser le temps ex´ecution du syst`eme. En effet, nous avons les deux bases de donn´ees dans le syst`eme,
17

28. le base de donn´ees orient´ee documents et la base de triplets dans m´emoire temporelle. Ici, les op´erations
CRUD vont s’ex´ecuter dans MongoDB et les recherches sont r´ealis´ees dans le graphe RDF. Alors, une
couche m´ediane est n´ecessaire pour synchroniser les deux bases de donn´ees.
Avantages
ˆ Le stockage des donn´ees dans MongoDB sous la forme de JSON-LD est aussi la forme de donn´ees
RDF. Nous pouvons donc profiter de la puissance de MongoDB dans le traitement de probl`eme de
donn´ees volumineuses.
ˆ Les op´erations de CRUD vont ˆetre rapidement r´ealis´ees sur les donn´ees dans MongoDB.
ˆ Les requˆetes en langage SPARQL sont utilis´ees pour faire des recherches de donn´ees dans le syst`eme.
Inconv´enients
ˆ L’existence de deux base de donn´ees va augmenter la complexit´e du syst`eme.
ˆ L’´etape de chargement des donn´ees de graphes RDF dans la m´emoire temporelle va prendre beau-
coup de temps. Les mises `a jour sur les donn´ees de graphes RDFs sont d´ependantes de la base de
donn´ees dans MongoDB.
ˆ Le probl`eme de m´emoire temporelle avec les grands graphes RDFs, la puissance mat´erielle est
importante pour ce syst`eme avec un besoin fort de m´emoires temporelles.
2.2.4 ODBA et frameworks Ontop
L’ODBA est consid´er´ee comme un ´el´ement cl´e pour la nouvelle g´en´eration de syst`emes d’information,
en particulier pour les applications du Web s´emantique qui impliquent une grandes quantit´es de donn´ees.
L’ODBA est un paradigme d’acc`es `a des donn´ees par une couche conceptuelle. G´en´eralement, la couche
conceptuelle est exprim´ee sous la forme d’une ontologie qui d´efinit un sch´ema global de haut niveau et
fournit des vocabulaires pour des requˆetes d’utilisateurs. Les donn´ees sont stock´ees dans des bases de
donn´ees relationnelles, des bases de triplets etc [10].
Les termes de la couche conceptuelle sont mapp´ees sur la couche de donn´ees en utilisant les mappings
qui associent `a chaque ´el´ement de la couche conceptuelle, une requˆete sur les sources de donn´ees. Main-
tenant, les mappings ont ´et´e formalis´ees dans la r´ecente norme Relational Databases to RDF Mapping
Language (R2RML) 5
de l’organisation W3C. Cette graphe virtuelle peut ˆetre interrog´ee `a l’aide d’un
langage de requˆete sur les donn´ees RDF tels que SPARQL.
Un syst`eme ODBA est un triple : O = <T , S, M>, o`u[11] :
ˆ T est consid´er´e comme les ontologies formalis´ees dans les Logiques de Description (DL), o`u T est
un DL TBOX.
ˆ S est un sch´ema des sources.
ˆ M est un ensemble d’assertions des mappings, chacun de la forme : Φ(x) ← Ψ(x)
Φ(x) est une requˆete sur S, retourner des tuples de valeurs pour x
Ψ(x) est une requˆete sur T dont les variables libres sont de x
18

29. Figure 2.8: Le processus de requˆete dans le syst`eme d’ODBA
Les syst`emes d’ODBA sont orient´e pour r´epondre aux requˆetes. Une description sch´ematique du
processus de transformation de requˆete illustre dans la figure 2.8. Ici, les requˆetes pos´ees au niveau de
la couche conceptuelle sont traduites dans un langage de requˆete qui peut ˆetre trait´e par la couche de
donn´ees. La traduction est ind´ependante des donn´ees r´eelles dans la couche de donn´ees. De cette fa¸con,
l’´evaluation de requˆete peut ˆetre d´el´egu´ee au syst`eme de gestion des sources de donn´ees.
Sur la base de la conception d’ODBA, les chercheurs de l’Universti´e Bozen-Bolzano en Italie ont
d´evelopp´e un Framework ODBA du nom d’Ontop. Il est utilis´e actuellement sur l’application Optique6
r´esoudre les probl`emes de Big Data.
Le noyau de Ontop est le moteur de requˆete SPARQL QUEST qui impl´emente RDFS et OWL 2 QL
en r´e-´ecrivant les requˆetes SPARQL sur le graphe RDF virtuelle en des requˆetes SQL (sur la base de
donn´ees relationnelles). Ontop est capable de g´en´erer efficacement et de mani`ere optimis´e des requˆetes
SQL [12]. Le Framwork Ontop peut ˆetre utilis´e comme :
ˆ Un plugin pour Prot´eg´e 4 qui fournit une interface pour la r´edaction de mappings et l’ex´ecution de
requˆetes SPARQL.
ˆ Une biblioth`eque Java qui impl´emente OWL API et les interfaces API de Sesame.
ˆ Un point d’acc`es 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

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

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

32. sont bas´es sur le langage de mapping R2RML et Morph-RDB10
qui est une impl´ementation du langage
de mapping R2RML pour les donn´ees relationnelles, pour d´evelopper xR2RML qui est s’applique aux
bases de donn´ees orient´ees documents comme MongoDB.
En particulier, xR2RML est une extension de la langage de mapping R2RML et s’appuie sur certaines
propri´et´es du langage de mapping RDF Mapping Language (RML) [15] et. R2RML porte sur les mappings
de base de donn´ees relationnelles aux triplets RDF. RML ´etend R2RML pour aborder les mappings sur des
donn´ees h´et´erog`enes (XML, JSON, CSV) avec des triplets RDF. xR2RML ´etend ce champ d’application
`a un plus large ´eventail de base de donn´ees non-relationnelles.
Avantages
ˆ Les donn´ees sont converties en triplets. Nous pouvons donc utiliser les syst`emes de gestion de base
de donn´ees RDF sp´ecifiques.
ˆ Les interrogations sur les donn´ees sont r´ealis´ees par langage de requˆete SPARQL
ˆ Les capacit´es de raisonnement sont parfaitement soutenues par ces syst`emes de gestion de base de
donn´ees RDF.
Inconv´enients
ˆ L’´etape de transformation de donn´ees est coˆuteuse en temps : r´e-organisation des donn´ees en graphe
ˆ Le nouveau syst`eme avec ses donn´ees a besoin d’une nouvelle architecture pour ˆetre mis en œuvre.
Le syst`eme est ind´ependant de l’existant.
ˆ On rencontre des probl`emes de performance avec les donn´ees volumineuses
2.3 Conclusion
Dans cette partie, nous avons fait l’´etat de l’art des approches pour r´esoudre le probl`eme de donn´ees
massives et des recherches au niveau Web s´emantique. Pour r´esumer il y a deux approches principales :
la transformation de donn´ees 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ˆetes ou la r´e-´ecriture des requˆetes avec ODBA et Ontop Framework. On peut
voir que pour chaque approche il existe des avantages et des inconv´enients. Il faudra donc, sur la base des
caract´eristiques de l’organisation des donn´ees et de l’objectif d’utilisation de donn´ees, choisir la meilleure
solution pour les donn´ees.
10https ://github.com/oeg-upm/morph-rdb
22

33. Chapitre 3
Solution propos´ee
3.1 Introduction
La partie pr´ec´edente donne une vue g´en´erale de diff´erentes solutions pour aider `a traiter un gros
volume de donn´ees et renforcer la capacit´e d’association en structurant les donn´ees aux triplets RDF
pour que le but final soit l’am´elioration de capacit´e de partage, d’int´egration et de recherche des donn´ees.
Dans cette partie, nous allons pr´esenter la solution sur la base d’une mat´erialisation de donn´ees sous
forme de triplets.
Dans ce chapitre, nous aborderons dans la premi`ere section le choix de la repr´esentation du mod`ele
donn´ees et la mani`ere de le g´en´erer. Ensuite, dans la section suivante sera abord´ee une d´emarche entreprise
pour transformer des donn´ees du mod`ele relationnel aux format JSON. De plus, une ontologie sera
pr´esent´ee pour d´ecrire les vocabulaires n´ecessaires dans la la conception du modele RDFs. En fin, le
langage de transformation de donn´ees en RDF sera introduit avec les syntaxes pour cr´eer les mapping et
convertir des documents JSON en triplets RDF.
3.2 Mod`ele g´en´eral
L’approche de mat´erialisation de donn´ees en triplets RDF a ´et´e choisie afin de tester l’organisation et la
performance des triplestores sur de gros volume donn´ees. Les syst`emes actuels stockant de gros volumes
sont en majorit´e partag´es entre des syst`emes NoSQL (e.g : Mongodb), relationnels et divers format.
L’un des objectifs de ce travail ´etait l’organisation et la synchronisation des donn´ees en conservant leur
provenance et les syst`emes existants en ayant MongoDB comme stockage interm´ediaire.
Par la suite, les donn´ees seront converties en triplets RDF grace a l’utilisation du langage de mapping
xR2RML et l’outil d´evelopp´e par les auteurs [14]. Les vocabulaires et les r`egles de transformation de
triplets sont fournis par une ontologie. Cette ontologie est importante pour r´ealiser des recherches avanc´ees
sur les relations et les hi´erarchies existantes .
Aujourd’hui, il existe diff´erents syst`emes qui permettent de g´erer les donn´ees RDF. Nous allons focali-
ser notre etude sur cinq syst`emes : 4Store, Sesame, Virtuoso, Stardog, GraphDB(OWLIM) et Jena Fuseki.
Leurs m´ecanismes d’action et d’indexation de donn´ees ´etant diff´erents, nous allons tester ces syst`emes
avec des donn´ees volumineuses. Ainsi, r´ealiserons les tests de ces syst`emes sur la capacit´e de gestion de
23

34. donn´ees RDF afin d’optimiser le stockage et pour la r´ecup´eration de ces triplets `a l’aide du langage de
requˆete SPARQL.
Le moteur de recherche va consister `a utiliser la capacit´e d’inf´erence sur la base contenant l’ontologie et
les donn´ees RDF. Une interface est fournie pour effectuer les requˆetes sur ces donn´ees. Les interrogations
sous la forme de langage SPARQL sont utilis´ees pour chercher les donn´ees n´ecessaires dans la base de
donn´ees. L’illustration d´etaill´ee du mod`ele est pr´esent´e dans la figure 3.1 suivante :
Figure 3.1: Le mod`ele g´en´eral du syst`eme
3.3 Transformation et synchronisation de donn´ees dans Mon-
goDB
Dans le projet Phenome (INRA), plusieurs syst`emes de capteurs alimentent des bases de donn´ees
relationnelles en permanence. Il y a une fort besoin de synchronisation de ces donn´ees avec le syst`eme
courant. L’´etape de transformation de donn´ees en documents JSON est r´ealis´ees afin d’int´egrer plusieurs
ressources dans un meme entrepˆot. Dans la suite du memoire nous nous concentrons seulement sur les
donn´ees obtenues dans sur les processus d’imageries, d’arrosage, de pes´ees ceux que les chercheur ont
r´ealis´es quotidiennement.
Afin de garantir la coh´erence des donn´ees entre les ressources et les processus qui les g´en`erent, des
mod`eles ont ´et´e d´efinis. La d´efinition des mod`eles JSON est r´ealis´ee pour mapper les propri´et´es de
plusieurs tables de base de donn´ees relationnelles avec les cl´es - valeurs dans les documents JSON. Seules
les propri´et´es importantes et les relations entre les tables ont ´et´e conserv´ees. La figure 3.2, repr´esente
un exemple de mod`ele d´efini en JSON pour les donn´ees imageries construits `a partir les trois tables
diff´erentes : Images, Imgacqcameraprofiles et Imagacstationprofiles. Ces tables correspondent comme leur
nom l’indique aux donn´ees images (horodatage, format, etc), aux profils cam´era (balance des blancs,
saturation, etc,) ainsi qu’aux profils des cabines d’imageries (lumi`eres, etc ..). Dans ce nouveau document
JSON sont repr´esent´es des donn´ees fix´ees par les syst`emes existants et des nouvelles donn´ees calcul´ees a
24

35. partir de traitements resultant de leur int´egration.
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`ele JSON cr´e´e `a partir des bases d’imageries
Dans quelques semaines `a l’issus de ce stage, une application1
sera mise en œuvre pour convertir
automatique toutes les donn´ees dans la base de donn´ees relationnelles aux document de JSON sur la
base d’un mod`ele d´efini comme la figure 3.2. Les donn´ees, qui seront concern´ees par les processus de
mesures des plantes selon trois aspects d’imageries, d’arrosages, de pes´ees, seront converties sous forme
de documents de JSON. On peut voir les autres mod`eles qui sont compl`etement d´efinies dans l’Annexe
A.
Aujourd’hui, toutes les donn´ees obtenues apr`es la transformation seront synchronis´ees et stock´ees
dans le syst`eme MongoDB. La centralisation de donn´ees dans un seul syst`eme nous aide commod´ement
`a d´efinir les mod`eles g´en´eraux pour la transformation de donn´ees en RDF.
1https ://github.com/lengocluyen/phenowaredb-to-mongodb-convertor
25

36. 3.4 Ontologies et domaine applicatif
Figure 3.3: L’ontologie de l’annotation d’images
Les diff´erences entre des processus d’imageries, d’arrosage et de pes´ees demandent un diversit´e de
vocabulaires pour les d´ecrire. Dans cette section, nous nous focalisons sur des vocabulaires de description
des donn´ees, des m´eta-donn´ees du processus d’imageries. Dans ce processus, de tr`es nombreuses images
de plantes sont cr´e´ees et doivent ˆetre stock´ees et ˆetre partag´ees. Une annotation d’images est n´ecessaire
pour fournir les m´eta-donn´ees afin d’aider compr´ehension et l’interpr´etation de l’image.
En g´en´eral, plusieurs vocabulaires sont d´ej`a 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´eriques. Il contient des
2https ://fr.wikipedia.org/wiki/Exchangeable imag file format
26

37. m´eta-donn´ees pour la date, l’heure, la localisation etc . Dublin Core3
fournit des vocabulaire de taille
r´eduite pour la description de ressources multim´edia. Il recouvre ainsi les concepts de titre, cr´eateur,
date, format etc. Ces vocabulaires fournissent les ´el´ements n´ecessaires pour d´efinir un mod`ele, mais ne
conviennent pas compl`etement pour les images trait´ees dans ce projet.
Afin de prendre en compte ces sp´ecificit´es l’´equipe INRA a construit une ontologie d’annotation
d’images [17]. On peut voir en d´etail le sch´ema de cette ontologie dans la figure 3.3.
3.5 xR2RML et Transformation de donn´ees en triplets
3.5.1 Le langage de mapping de donn´ees xR2RML
Apr`es l’´etape de transformation de donn´ees en JSON et leur importation dans MongoDB, il est
n´ecessaire de les transformer en triplets RDF. Pour cela, nous allons utiliser le langage de mapping
xR2RML pour transformer ces donn´ees en triplets RDF. Dans la partie de ”Mat´erialisation de donn´ees
aux triplets” du chapitre pr´ec´edant, nous avons introduit ce langage. Nous verrons plus en detail dans
cette section la syntaxes pour cr´eer le mapping entre un document JSON et la declaration des triplets
RDF.
Un mapping de triplet de xR2RML utilise une r´ef´erence sur la source logique au lieu d’une table
logique dans R2RML. En particulier, le mapping xR2RML consist `a :
ˆ Une propri´et´e xrr :logicalSource. Son objet est une source logique qui sp´ecifie une table ou un
r´esultat de requˆete pour ˆetre mapp´e avec un triplet.
ˆ Un mapping de sujet qui pr´ecise comment g´en´erer un sujet pour chaque ´el´ement de donn´ees de la
source logique (par exemple : une ligne de table, un document de collection, un ensemble d’´el´ements
XML etc). Ce mapping peut ˆetre sp´ecifi´e dans deux fa¸cons suivantes :
En utilisant la propri´et´e rr :SubjectMap, dont la valeur doit ˆetre le mapping de sujet
En utilisant la propri´et´e constante rr :subject
ˆ Sans, une ou plusieurs propri´et´es rr :predicateObjectMap, dont les valeurs doivent ˆetre le mapping
de pr´edicate - objet. Ces mapping pr´ecisent les paires pr´edicat et objet qui, avec les sujets g´en´er´es
par le mapping de sujet, peuvent former un ou plusieurs triplets RDF pour chaque ´el´ement de
donn´ees.
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´ees dans MongoDB
3https ://fr.wikipedia.org/wiki/Dublin Core
27

38. 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´en´er´e
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´ees JSON stock´ees dans MongoDB,
la d´efinition du mapping des propri´et´es et les r´esultats obtenus. Dans le mapping de donn´ees, il y a des
termes qui sont d´efinies dans R2RML ou xR2RML que l’on peut l’identifier par le pr´efixe : rr :, rrx : etc.
Dans xR2RML, le mapping de terme (Term maps) est d´efini comme une fonction qui g´en`ere des
termes RDF `a partir d’une ligne de la table logique. Il est soit un mapping de sujet, de pr´edicat, d’objet
ou de graphe. En particulier, un mapping de terme peuvent ˆetre exactement l’un des suivants : une valeur
constante (la propri´et´e rr :constant), une valeur de colonne (la propri´et´e rr :column elle peut se remplacer
par rml :reference ) et une valeur du template (la propri´et´e rr :template). Il existe plusieurs mappings
de termes que l’on peut enti`erement voir dans [14].
Avec les caract´eristiques de ce langage, un outil4
est d´evelopp´e pour transformer automatiquement des
donn´ees relationnelles en triplets sur la meme base de mapping entre les deux. Cet outil est un syst`eme
qui, ´etant donn´ee un mapping xR2RML et une base de donn´ees d’entr´ee, fournit un acc`es `a la sortie
d’ensemble de donn´ees RDF. Il a l’acc`es `a un environnement d’ex´ecution comprenant : une connexion `a
la base de donn´ees d’entr´ee. Une formulation de r´ef´erence applicable aux r´esultats des requˆetes ex´ecut´ees
sur la connexion.
3.5.2 Transformation de donn´ees en triplets
Sur la base du langage de mapping xR2RML et l’outil d´evelopp´e, La d´efinition du mapping est cr´e´e
pour mapper les propri´et´es d’un document JSON avec des triplets. les vocabulaires de ces triplets sont
4https ://github.com/frmichel/morph-xr2rml/releases
28

39. fournis par l’ontologies ci-dessus. Dans la figure 3.7, les propri´et´es du document JSON d’images (les autres
sont d´efinis dans l’Annexe B) vont ˆetre mapp´ees aux sujets, pr´edicat et objet du triplet.
Apr`es cette ´etape, nous avons obtenu 45 de millions de triplets pour l’annotation d’images `a partir
d’environ 3.5 millions d’images contenues dans le syst`eme MongoDB. Cette transformation `a n´ecessit´e
beaucoup de temps d’execution cot´e serveur `a l’INRA (environ 20 heures). Ces donn´ees 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 ];
18 rr: predicateObjectMap [
19 rr:predicate ia:aboutEntity ;
20 rr:objectMap [ xrr:reference "$.context.plant
"; ];
21 rr:class ia:Plant;
22 ];
23 rr: predicateObjectMap [
24 rr:predicate ia:timeStamp;
25 rr:objectMap [ xrr:reference "$.date "; ];
26 rr:datatype xsd:date;
27 ];
28 rr: predicateObjectMap [
29 rr:predicate ia:hasFileName ;
30 rr:objectMap [ xrr:reference "$.fileName "; ];
31 rr:datatype xsd:string;
32 ];
33 rr: predicateObjectMap [
34 rr:predicate ia:hasPlateau;
35 rr:objectMap [ xrr:reference "$.context.
technicalPlateau "; ];
36 rr:class ia: TechnicalPlateau ;
37 ];
38 rr: predicateObjectMap [
39 rr:predicate ia: inImagingCycle ;
40 rr:objectMap [ xrr:reference "$. configuration .
taskid "; ];
41 rr:datatype xsd:integer;
42 ];
43 rr: predicateObjectMap [
44 rr:predicate ia:hasPlateau;
45 rr:objectMap [ xrr:reference "$.context.
technicalPlateau "; ];
46 rr:class ia: TechnicalPlateau ;
47 ];
48 rr: predicateObjectMap [
49 rr:predicate ia: inImagingCycle ;
50 rr:objectMap [ xrr:reference "$. configuration .
taskid "; ];
51 rr:datatype xsd:integer;
52 ];
53 rr: predicateObjectMap [
54 rr:predicate ia: inAutomatonStudy ;
55 rr:objectMap [ xrr:reference "$. configuration .
studyname "; ];
56 ];
57 rr: predicateObjectMap [
58 rr:predicate ia: inExperiment ;
59 rr:objectMap [ xrr:reference "$.context.
experiment "; ];
60 rr:class ia:Experiment;
61 ];
62 rr: predicateObjectMap [
63 rr:predicate ia: hasCameraAngle ;
64 rr:objectMap [xrr:reference "$. cameraAngle ";];
65 rr:datatype xsd:integer;
66 ];
67 rr: predicateObjectMap [
68 rr:predicate ia:hasViewType;
69 rr:objectMap [ xrr:reference "$.viewType "; ];
70 ];
71 rr: predicateObjectMap [
72 rr:predicate ia: isReferenceImage ;
73 rr:objectMap [ xrr:reference "$.
isReferenceImage "; ];
74 rr:datatype xsd:boolean;
75 ];
76 rr: predicateObjectMap [
77 rr:predicate ia: hasCameraProfile ;
78 rr:objectMap [ xrr:reference "$.
imageCameraProfile "; ];
79 rr:class ia: CameraProfile ;
80 ];
81 rr: predicateObjectMap [
82 rr:predicate ia: hasAcquisitionStationProfile ;
83 rr:objectMap [ xrr:reference "$.
imageStationProfile "; ];
84 rr:class ia: AcquisitionStationProfile ;
85 ].
Figure 3.7: Le Mapping de donn´ees JSON en triplets
29

40. 3.6 Conclusion
Dans cette partie, la d´efinition du mod`ele de solution propos´ee est pr´esent´ee avec les ´etapes que
nous allons r´ealiser pour la construction d’un syst`eme de connaissance. En d´eveloppant l’outil de trans-
formations de donn´ees relationnelles en document JSON stock´ees dans MongoDB et en utilisant l’outil
xR2RML pour la transformation de donn´ees JSON en triplets, nous avons obtenu des graphes RDF tr`es
volumineuses. Avec ces graphes, nous avons besoin d’un syst`eme de gestion de base de donn´ees pour le
g´erer de mani`ere efficace. Ceci sera pr´esent´e dans la partie prochaine.
30

41. Chapitre 4
Stockage et Indexation de donn´ees
RDF
4.1 Introduction
Avec les donn´ees obtenues dans la chapitre pr´ec´edent, on a besoin d’avoir un meilleur syst`eme pour les
organiser et les stocker. Il existe actuellement plusieurs syst`emes d´evelopp´es pour les donn´ees RDF mais
chaque syst`eme a des caract´eristiques sp´ecialis´ees concernant l’organisation et l’indexation des donn´ees.
Alors, on a besoin d’effectuer des tests sur la capacit´e de stockage, sur l’indexation, sur la performance,
sur l’optimisation du processus de chargement, des requˆetes et des raisonnements de ces syst`emes.
Ce chapitre introduit des m´ethodes d’organisation pour stocker et indexer les donn´ees RDF et
l’impl´ementation de ces donn´ees dans quelques syst`emes courants. Plus pr´ecis´ement, la premi`ere sec-
tion pr´esentera les deux approches d’organisation de donn´ees : sous la forme native qui construit un
nouveau syst`eme pour g´erer les donn´ees par soi-mˆeme et sous la forme non-native qui utilise un syst`eme
de gestion de donn´ees existant pour stocker les donn´ees. Dans la deuxi`eme partie, il y aura une intro-
duction `a des entrepˆots de donn´ees RDF ou “TripleStore” r´ecents : l’architecture, les caract´eristiques de
chaque syst`eme et aussi l’impl´ementation du stockage des donn´ees ces syst`emes. Enfin, la repr´esentation
d’une application pour acc´eder `a des donn´ees issues de plusieurs sources sur la base d’un point d’acc`es.
4.2 Approche native et non-native
L’approche native fournit un moyen pour stocker des donn´ees RDF plus proche du mod`ele de donn´ees.
Il utilise la nature des triplets RDF et permet d’aborder les sp´ecificit´es de son approche en graphe, tels
que la capacit´e `a g´erer la parcimonie des donn´ees et l’aspect dynamique de son sch´ema. Ces syst`emes
peuvent ˆetre class´es en deux types de stockage (la figure 4.1) : `a base de disque qui est persistant ou `a base
de m´emoire qui est volatile. Le stockage persistant sur le disque est un moyen de stocker en permanence
des donn´ees RDF sur un syst`eme de fichiers. Ces impl´ementations peuvent utiliser des structures d’index
comme des arbres B+ par exemple.
N´eanmoins, l’´ecriture et la lecture sur les disques peuvent provoquer un ph´enom`ene de goulot d’´etranglement
31

42. dans le syst`eme. Alors, la solution de stockage des donn´ees en m´emoire est `a consid´erer pour ´eviter ce
ph´enom`ene. Le stockage des donn´ees RDF en m´emoire alloue une certaine quantit´e de la m´emoire 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´ees stock´ees dans la
m´emoire, certaines op´erations seront coˆuteuses en temps : le chargement, l’analyse ou ”parsing” de fi-
chier de donn´ees RDF et aussi la cr´eation d’index. Par cons´equent, un Triplestore RDF doit avoir une
repr´esentation de donn´ees en m´emoire efficace qui laisse suffisamment d’espace pour les op´erations de
requˆetes et de gestion de donn´ees.
Figure 4.1: La classificaiton des types de syst`eme de stockage RDF
L’approche non-native utilise un syst`eme de gestion de base de donn´ees pour stocker des donn´ees RDF
de fa¸con permanente. On profite du d´eveloppement de plusieurs ann´ees de ces syst`emes, par exemple, la
capacit´e de transactions ou de s´ecurit´e. Avec les syst`emes de gestion de base de donn´ees relationnelles, on
peut distinguer la base de donn´ees avec sch´ema et la base de donn´ees sans sch´ema. Avec la base de donn´ees
avec sch´ema, les caract´eristiques du sch´ema sont utilis´ees pour s´eparer des triplets en diff´erentes tables.
Cette s´eparation peut ˆetre organis´ee sur la base de structure intrins`eque de triplets : le sujet, le pr´edicat
et l’objet, ou fond´ee sur les propri´et´es, les classes RDFS ou OWL. On a les trois fa¸cons d’organisation
de sch´ema : partitionnement vertical, table de propri´et´es et table de propri´et´es hi´erarchiques. Avec la
base de donn´ees sans sch´ema, 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`eres ann´ees, les syst`emes de gestion
de base de donn´ees ´emergent comme une bonne approche pour les donn´ees massives avec plusieurs
mani`eres d’organisation de donn´ees : cl´e-valeur, orient´e document, orient´e colonne, orient´e graphe, etc.
La motivation principale est de r´epondre `a la distribution de grands ensembles de donn´ees sur un cluster
de mat´eriel.
Dans l’approche non-native, les triplets sont parfaitement stock´ees avec l’impl´ementation d’indexa-
tion, le support des propri´et´es ACID (Atomicit´e, Coh´erence, Isolation et Durabilit´e) et les optimisations
de requˆetes de chaque syst`eme (SQL pour les base de donn´ees relationnelles, Cypher pour Neo4J etc).
N´eanmoins, l’association de deux mod`eles de donn´ees (par exemple mod`ele en graphe et mod`ele relation-
nelle) a besoin de manipulations, de la synchronisation entre eux, on par exemple de transformation de
donn´ees, des requˆetes SPARQL en SQL. Cela est coˆuteux en temps d’ex´ecution et de transformation de
requˆetes. On a encore des limitations sur la capacit´e d’inf´erence sur les donn´ees. Dans l’approche native,
on utilise des syst`emes de gestion de base de donn´ees sp´ecialis´es pour les donn´ees RDF. Les donn´ees sont
32

43. index´ees selon l’organisation origine des donn´ees (en graphe). A cot´e, il fournit des capacit´es d’inf´erence,
et bien sˆure le langage de requˆete SPARQL. Alors, avec ces d´esavantages de l’approche non-native et les
avantages de l’approche native, on va focaliser sur l’approche native pour stocker et indexer les donn´ees.
Pour tester les syst`emes de gestion de donn´ees de triplets, on va consid´erer les six TripleStores suivants :
Sesame, 4Store, Virtuoso, Stardog, GraphDB Ontotext et Jena Fuseki.
TripleStore
Native Non-native
M´emoire Disque GBDR NoSQL
Sesame X X MySQL, PostgreSQL
4Store X
Virtuoso X X
Stardog X
Graphdb Ontotext X
Jena Fuseki X X
Tableau 4.1: Les TripleStores et le type de stockage support´e
4.3 Vue g´en´erale des syst`emes de gestion de triplets
4.3.1 TripleStore Sesame
Sesame est un framework Open Source ´ecrit en Java pour le stockage et l’interrogation des donn´ees
RDF. Il est extensible et configurable en ce qui concerne les m´ecanismes de stockage, les inf´erences, les
formats de fichiers RDF, les formats de r´esultats obtenus et les langages de requˆete. Sesame propose une
API comme JDBC, une interface de service de web RESTful qui permet les requˆetes SPARQL.
Figure 4.2: Les composants dans l’architecture de Sesame
Sur la figure 4.2, l’architecture de Sesame, la partie au fond est un mod`ele RDF, c’est le fondement
du framework Sesame. Toutes les autres parties de Sesame sont extensives et d´ependantes `a ce mod`ele.
Dans le mod`ele RDF, nous avons d´efinir les interfaces et l’impl´ementation de toutes les entit´es RDF de
base par exemple : des URIs, des nœuds anonymes, des litt´eraux et des triplets ou ”statements”.
Ensuite, la partie RIO, qui signifie “RDF I/O”, est constitu´e d’un ensemble d’analyseur et de writers
pour la diversit´e des formats de fichiers RDF. Les analyseurs peuvent ˆetre utilis´es pour traduire des
fichiers RDF en ensembles de statements et les writers pour l’op´eration inverse. RIO peut ´egalement
ˆetre utilis´e ind´ependamment du reste de Sesame. L’autre cot´e, l’API SAIL (the Stockage And Inference
Layer) est une API pour les RDF stores et les inf´erences. Son but est de faire abstraction du stockage
33

44. et de l’inf´erence. Plus pr´ecis´ement, il permet d’utiliser diff´erents types de stockage et d’inf´erences. L’API
SAIL est le principal int´erˆet pour ceux qui d´eveloppent des impl´ementation de SAIL (les d´eveloppeur
de TripleStore) ; pour les autres, il suffit de savoir comment on peut les cr´eer et les configurer. Il existe
plusieurs impl´ementation de l’API SAIL, par exemple le stockage en m´emoire (MemoryStore) ou le
stockage sur le disque (NativeStore).
L’API Repository est une API de niveau sup´erieur qui offre un grand nombre de m´ethodes de
d´eveloppements orient´es pour le traitement des donn´ees RDF. L’objectif principal de cette API est d’ai-
der des d´eveloppeurs d’applications. Il propose diverses m´ethodes pour le t´el´echargement de fichiers de
donn´ees, l’interrogation et l’extraction et la manipulation des donn´ees. Il existe plusieurs impl´ementations
de cette API par exemple SailRepository, HTTPRepository.
Enfin, la partie sup´erieure de cette figure correspond au serveur HTTP. Il est constitu´e d’un certain
nombre de Servlets Java qui impl´ementent un protocole d’acc`es aux r´ef´erentiels de Sesame sur HTTP. Le
HTTPClient qui est utilis´e par le HTTPRepository.
Le stockage de Sesame utilise l’arbre B pour l’indexation des triplets, o`u la cl´e d’index se compose
de quatre champs : sujet (s), pr´edicat (p), objet (o), contexte (c). L’ordre dans lequel chacun de ces
domaines est utilis´e dans la cl´e d´etermine l’utilisation d’un index sur un patron de requˆetes de triplet
pr´ecis´e : rechercher les triplets avec un sujet sp´ecifique dans un index qui a le sujet comme premier champ
est plus rapide que de rechercher ces mˆemes triplets dans un index o`u le champ de l’objet est deuxi`eme
ou troisi`eme. Dans le pire des cas, le patron de triplet ”mauvais” se traduira par un mod`ele s´equentiel
sur l’ensemble des triplets. Les indexes peuvent ˆetre sp´ecifi´es en cr´eant des mots de quatre caract`eres.
Plusieurs indices peuvent ˆetre sp´ecifi´ees en s´eparant ces mots par des virgules, des espaces et/ou des
tabulations. Par exemple, la chaˆıne ”spoc, posc” sp´ecifie deux indices ; un index sujet-pr´edicat-objet-
contexte et un index pr´edicat-objet-sujet-contexte.
4.3.2 TripleStore 4Store
Le projet DataPatrol est une application en ligne pour v´erifier la fuite dans le domaine public des
informations personnelles par la soci´et´e Garlik1
. 4Store a ´et´e con¸cu principalement pour fournir le stockage
backend de ce projet. Puis derni`erement, 4Store a ´et´e mis en œuvre sur un cluster en r´eseau `a faible coˆut
avec des dizaines de serveurs supportant un fonctionnement 24x7.
Dans ce projet, nous avons des besoins en performance et efficacit´e des mat´eriaux courants. Alors,
l’approche de segmentation de donn´ees dans plusieurs cluster est utilis´es [18]. Ici, les donn´ees sont divis´es
entre un certain nombre de segments avec un ou plusieurs segments sur chaque nœud de stockage comme
le montre la figure 4.3. Ces nœuds consistent en nœuds de traitements et en nœuds de stockages. Il
est ´egalement possible d’ex´ecuter 4Store sur un nœud unique, ex´ecutant le traitement frontal et un ou
plusieurs nœuds de stockage pour le backend sur une seule machine.
Le mod`ele de segmentation dans 4Store utilise un entier RID (Identifiant de Ressources) qui est
utilis´e comme un codage de symbole pour des valeurs de ressources. Les RIDs sont le entiers 64 bits qui
repr´esentent les URIs, les litt´eraux, les nœuds vides en utlisant un espace de valeur disjointes. Les une
ou deux bits significatifs MSB2
de la valeur RID d´eterminent si l’encodage RID concerne une URI, un
1http ://www.garlik.com/
2MSB : Most Significant Bit
34

45. litt´eral ou un nœud vide. Le num´ero de segment est ensuite calcul´ee de telle sorte que :
segment = RID(subjet) mod segments
MSB1 MSB2 Encodages
0 Litt´eral
1 0 Nœud vide
1 1 URI
Tableau 4.2: Les encodages
sp´eciaux
Dans 4Store, les triplets RDF sont repr´esent´es en forme de quads :
Mod`ele, Sujet, Pr´edicat, Objet o`u le mod`ele est un peu analogue `a un graphe
SPARQL. Les principales diff´erences entre un graphe de SPARQL et un
mod`ele sont dans le traitement des graphes vides et dans le comportement du
graphe par d´efaut. Les triplets assign´es au graphe par d´efaut sont plac´es dans
un mod`ele particulier, qui est utilis´e pour l’ex´ecution des requˆetes lorsque le
comportement de graphe par d´efaut SPARQL est activ´ee.
Figure 4.3: L’architecture principale de 4Store
Dans l’indexation de donn´ees dans 4Store, chaque quad dans un segment particulier est stock´e dans
trois indexes. Nous pouvons les voir dans la figure 4.5 avec les noms : P index, R index et M index.
En d´etail, l’index R est utilis´e pour les stockages de valeur lexicale des ressources RDF comme URI, les
litt´eraux et les nœuds vides. Ceux-ci sont pr´esent´es comme des 3-tuples de (rid, attr, valeur lexical) avec
comme rid et attr des entiers calcul´es comme RID. La valeur lexicale est une chaˆıne de texte. Ensuite, les
graphes sont index´es avec l’index M en utilisant une table de hachage qui pointe vers une liste de lignes
de triplets. Son but principal est de permettre des requˆetes de la forme suivante :
SELECT * WHERE { GRAPH some-graph { ? s ?p ?o } }
Un effet secondaire de cet index est qu’il permet d’enlever d’un graphe des triplets pour ˆetre effectu´e
plus efficacement. Le derni`ere index dans 4Store s’appelle l’index P. Les indexes P sont constitu´es d’un
ensemble d’arbre radix [19], les deux pour chaque pr´edicat, en utilisant les quatre bits pour le radix.
La cl´e pour l’arbre radix est le sujet ou l’objet des quads pour ˆetre index´e. Le graphe et le sujet, objet
sont stock´es dans une liste des lignes, point´es par l’entr´ee de la feuille dans l’arbre radix. Avec l’arbre
radix dans le pire cas, la performance est O(k) o`u k est la taille de cl´e, par rapport `a O(logn) d’arbre
35

46. B. Cependant, les cl´es dans ce cas ont ´et´e mapp´e avec un entier 64 bits. Donc, ils sont fini et de courte
longueur.
4.3.3 TripleStore Virtuoso
En g´en´eral, Virtuoso est un middleware et un moteur hybride de base de donn´ees qui combine dans
un seul syst`eme les fonctionnalit´es d’un syst`eme de gestion base de donn´ees relationnelles et d’un syst`eme
de base de donn´ees objet-relationnels, d’un base de donn´ees virtuelles, RDF, XML, texte libre et une
application web serveur, une fonctionnalit´e de serveur de fichiers. Plutˆot que d’avoir des serveurs d´edi´es
pour chacun des domaines de fonctionnalit´es susmentionn´ees, Virtuoso est un ”Seveur universel”. Il
impl´emente un seul processus de serveur multithread d’utiliser des protocoles multiples. L’´edition Open
Source de Virtuoso Universal Server a ´et´e d´evelopp´e par OpenLink Software.
Figure 4.4: L’architecture g´en´erale de Virtuoso
Dans notre cas, on utilise l’´edition Open Source et les donn´ees RDF. Alors, des ´el´ements qui concernent
les triplets sont consid´er´es. En d´etail, un triplet est stock´e dans une table comme une ligne avec des
colonnes de G pour graphe, P pour pr´edicat, S pour sujet et O pour Objet. Les colonnes P, G, S sont les
l’ID IRI, ce sont des entiers 32 ou 64 bits. La colonne O a le type de donn´ees ANY dans SQL, ce peut
ˆetre de type scalaire, tableau ou d´efini par l’utilisateur de l’instance de ce type. L’indexation soutient un
ordre lexicographique de type ANY, ce qui signifie, qu’avec deux ´el´ements de type compatible, l’ordre est
celui du type de donn´ees dans la question avec classement par d´efaut.
Sur les donn´ees RDF, on peut faire des requˆetes avec le langage SPARQL mais les donn´ees sont
organis´ees dans les tables, Alors, les transformations de requˆetes SPARQL au SQL devront ˆetre ex´ecut´ees
dans le temps d’analyse de la requˆete. Un point d’acc`es est fourni pour acc´eder aux donn´ees RDF sur le
protocole HTTP. Sur les inf´erences, Virtuso supporte les inf´erences TBox en base comme les sous-classes
et sous-propri´et´es.
36

47. 4.3.4 TripleStore Jena Fuseki
Jena est l’un des premiers frameworks qui sont mis en œuvre pour web s´emantique en g´en´eral et
pour les donn´ees RDF en particulier. Il est d´evelopp´e en JAVA pour fournir une collection d’outils et
de la documentation pour d´evelopper avec le web s´emantique, les donn´ees li´ees, etc. Jena Fuseki est un
composant dans l’architecture g´en´eral de Jena. Alors on va consid´erer tous les composants de Jena pour
avoir une vue g´en´erale sur ce syst`eme.
Figure 4.5: Les composants dans l’architecture de Jena
Jena stocke les donn´ees RDF comme
des graphes orient´es, et permet de modi-
fier, supprimer, manipuler, stocker et pu-
blier ces donn´ees. Dans Jena, les donn´ees
RDF peuvent ˆetre stock´e dans plusieurs
formes par exemple dans la m´emoire,
dans les syst`emes de gestion de base de
donn´ees relationnelles (SDB), ou dans
la forme native de donn´ees (TDB). Il
y a quelques diff´erences sur le nom des
concepts qui sont utilis´es dans Jena :
instance le “Mod`ele” pour repr´esenter
un graphe RDF, “Statement” pour mon-
trer un triplet RDF, etc. Avec les APIs
RDF, on peut facilement ex´ecuter des
op´erations d’ajout, de suppression des tri-
plets sur des graphes ou faire des re-
cherches des triplets qui correspondent `a
des mod`eles particuliers. Ici, les sources RDF externes peuvent ˆetre utilis´ees si les fichiers ou les URL
s´erialisent une forme de graphe.
Une caract´eristique d’une application du web s´emantique est que les r`egles s´emantiques de RDF, RDFS
et OWL peuvent ˆetre utilis´ees pour inf´erer des informations qui ne sont pas explicitement indiqu´ees dans
le graphe. L’API d’inf´erence de Jena fournit des moyens pour le faire. En effet, Il y a certains moteurs
de r`egles pour effecteur ces inf´erences, soit en utilisant les ensembles de r`egles int´egr´ees pour OWL et
RDFS, ou en utilisant de r`egles optionnels. Ces APIs peuvent ˆetre connect´e `a un raisonneur externe,
telles que la moteur de description logique, pour effectuer le mˆeme travail avec diff´erents algorithmes de
raisonnement.
Avec les requˆetes SPARQL, Jena se conforme `a tous les standards publi´es de ce langage. La manipu-
lation SPARQL, `a la fois pour la requˆete et la mise `a jour, est de la responsabilit´e de l’API SPARQL.
D’ailleurs, l’API Ontologie fournit des m´ethodes commodes qui connaissent les formes de repr´esentation
disponibles pour des applications `a travers deux langages d’ontologie pour le RDF : OWL et RDFS.
Les applications peuvent directement acc´eder aux fonctionnalit´es Jena API par des API Java. Actuel-
lement, la publication de donn´ees sur Internet est une exigence commune dans les applications modernes.
Alors, Jena Fuseki est un serveur de publication de donn´ees, qui peut pr´esenter, et mettre `a jour, les
37

48. mod`eles RDF sur le Web en utilisant SPARQL et HTTP.
4.3.5 TripleStore Stardog
Stardog est un TripleStore commerciale, avec trois ´editions pour les groupes d’utilisateurs diff´erents :
Communaut´es, D´eveloppeurs, Entreprises. Stardog supporte les base de donn´ees de graphe s´emantique, et
est disponible pour du client-serveur, du middleware et des modes int´egr´es. Ce TripleStore est directement
construit pour les donn´ees RDF. Alors, il impl´emente parfaitement le langage SPARQL, OWL, les r`egles
d´efinies par l’utilisateur pour l’inf´erence et l’analyse de donn´ees et un point d’acc`es pour que l’on peut
acc´eder via HTTP.
Comme les autres TripleStore, Stardog supporte l’indexation de donn´ees sur des quads avec le graphe,
le sujet, le pr´edicat et l’objet. L’utilisateur peut configurer pour choisir ces indexes. Si la configuration
demande le moins de champs pour indexations, elle nous permet d’am´eliorer le temps de cr´eation de base
de donn´ees et aussi le temps de mise `a jour sur les graphes de donn´ees. Par d´efaut Stardog cr´ee un index
suppl´ementaire pour les graphes nomm´es. Ces indexes suppl´ementaires sont utilis´es lorsque les requˆetes
SPARQL pr´ecisent les ensembles de donn´ees pour utiliser “FROM” et “FROM NAMED”.
Stardog effectue un raisonnement d’une fa¸con paresseuse et late-binding. Il ne fait pas les mat´erialisations
des inf´erences bas´ees sur l’avant-chaˆınage. Ici, le raisonnement est effectu´e au moment de la requˆete selon
un type de raisonnement sp´ecifi´e par l’utilisateur. Cette approche permet une flexibilit´e maximale, tout
en maintenant une performance optimis´ee.
4.3.6 TripleStore GraphDB
GraphDB ontotext est un TripleStore commerciale comme Stardog et il existe dans plusieurs ´editions
pour les utilisateurs. Dans notre cas, nous consid´erons l’´edition de standard. Dans la th´eorie, GraphDB
Standard permet d’organiser les nombres de triplets RDF jusqu’`a 10 billions de triplets dans un seul
serveur. Les triplets RDF peuvent ˆetre charg´e et interrog´es `a une ´echelle simultan´ement.
Figure 4.6: Les composants dans l’architecture de GraphDB
GraphDB ontotext est d´evelopp´e sur la base
de la platforme d’Ontotext avec quelques fonc-
tions suppl´ementaires. Cependant le moteur
principale de ces platformes est OWLIM avec son
nom “OWLMemSchemaRepository SAIL em-
ball´e for Sesame”. En g´en´eral, l’OWLIM est
un d´epˆot s´emantique de haute performance,
d´evelopp´e en Java et encapsul´e comme une
couche de stockage et d’inf´erence (SAIL) pour
les base de donn´ees RDF dans Sesame. Il h´erite
et utilise plusieurs fonctionnalit´es et l’infrastruc-
ture de Sesame, par exemple le mod`ele RDF, les
analyseurs RDF et les moteurs de requˆetes. Les
inf´erences sont effectu´ees dans le moteur TRREE (Triple Reasoning and Rule Entailment Engine). En
d´etail, le TRREE fait les raisonnements bas´es sur l’avant-chaˆınage des r`egles d’implication via les patrons
38

49. de triplets RDF avec les variables, o`u les triplets explicit´es et inf´er´es sont stock´es dans des structures
de donn´ees hautement optimis´ees qui sont conserv´ees dans la m´emoire pour les inf´erences prochaines. A
cˆot´e, l’ORDI est un framework neutre de langage d’ontologie pour aider le d´eveloppement d’application
d’ontologie. Ses principaux objectifs sont l’int´egration de base de donn´ees et d’autres sources de donn´ees
structur´ees et le support aux raisonneurs h´et´erog`enes.
L’OWLIM impl´emente l’interface de Sesame SAIL de sorte qu’il peut ˆetre int´egr´e avec le reste du
framework Sesame, par exemple les moteurs de requˆetes et de l’interface d’utilisateur web. Une application
utilisateur peut ˆetre d´esign´ee pour utiliser directement l’OWLIM `a travers l’API Sesame SAIL ou via
les interfaces fonctionnelles niveau sup´erieur. Quand un d´epˆot OWLIM est expos´e en utilisant le serveur
Sesame, l’utilisateur peut g´erer le d´epˆot via l’application Sesame Workbench ou avec d’autres outils
int´egr´es `a Sesame, par exemple l’´editeur d’ontologies Prot´eg´e.
4.4 Impl´ementation
Actuellement, des applications dans des syst`emes distribu´es ou centralis´es fournissent l’acc`es `a des
fonctionnalit´es en g´en´erale et des donn´ees en particulier via le protocole HTTP. Cette m´ethode de commu-
nication est de plus en plus importante et devient une demande obligatoire dans l’architecture d´evelopp´ee
de ces applications.
Figure 4.7: L’interface du syst`eme d’interaction avec les donn´ees RDF
Comme nous avons pr´esent´e au-dessus, toutes les bases de donn´ees RDF des platformes sont fournis
39

50. avec un point d’acc`es sur la base du protocole HTTP. Alors, une application est d´evelopp´ee pour aider
`a centraliser les interactions avec les bases de donn´ees dans des Platformes. Avec cette application, nous
pouvons faciliter des lancements de requˆetes en langage SPARQL sur les bases de donn´ees RDF en
choisissant un lien qui fournit est par les TripleStores. Et bien sur, les utilisateur peuvent ajouter les
nouvelles liens pour connecter au point d’acc`es des bases de donn´ees RDF. Sur les exemples de point
d’acc`es de donn´ees, nous pouvons les voir dans l’Annexe C
4.5 Conclusion
La compr´ehension des structures des composantes de ces TripleStores nous permet de r´ealiser compl`etement
les op´erations test´ees sur nos donn´ees RDF. En r´esum´e, une comparaison des caract´eristiques principales
de ces outils est cit´ee dans la table 4.3. Il y a plusieurs diff´erences entre les capacit´es de ces TripleS-
tores. Mais nous n’avons pas encore les bases stables pour confirmer quel TripleStrore convient avec nos
donn´ees.
Exigence Sesame 4Store Virtuoso Fuseki Stardog GraphDB
Open Source Oui Oui Oui/Non Oui Non Non
´Edition gratuit Oui Oui Oui Oui Oui Oui
10 billion triplets Non Oui Oui Non Oui Oui
Clustering Non Oui Oui Non Oui Oui
SPARQL 1.0 Oui Oui Oui Oui Oui Oui
SPARQL 1.1 Partiel Partiel Partiel Oui Oui Oui
SPARQL update Oui Oui Non Oui Oui Oui
Support Oui Non Oui Oui Oui Oui
´Ev´enements Oui Non Oui Oui Non Oui
Raisonnement Faible Add-on R`egles R`egles OWL + R`egles R`egles
Contraintes Non Non Non Non Oui Non
S´ecurit´e au niveau triplet Non Non Arrivant Non Non Non
Point d’ac`es Oui Oui Oui Oui Oui Oui
Live Backup Oui Oui Oui Oui Oui Oui
Embeddable Oui Oui Oui Oui Oui Oui
Tableau 4.3: Les comparaison de certaines fonctionnalit´es des diff´erents TripleStores
Dans ce chapitre, les travaux pratiques pour installer ces outils sont effectu´es sur un serveur de l’INRA.
Des d´eveloppements d’importation de donn´ees sont effectu´es pour avoir des premi`eres exp´erimentations.
En d´etail, nous avons import´e les donn´ees par les deux moyens : par utilisation de l’interface qui est
40

51. fourni de ces outils, et par l’utilisation des APIs disponibles pour cr´eer, acc´eder, importer les donn´ees
dans ces platformes. Et bien sur, nous avons lanc´e les requˆetes en langage SPARQL.
41

52. Chapitre 5
Exp´erimentation, Comparaison et
Analyse
5.1 Pr´eparation des donn´ees et du Serveur
Avec environs 45 millions de triplets obtenus dans l’´etape de transformation de donn´ees RDF decrite
dans le chapitre 3, nous avons divises cet ensemble de donn´ees en 5 groupes de 100.000 triplets, de 1
millions, de 10 millions, de 20 millions et de 40 millions de triplets. Les donn´ees des 4 premiers groupes
sont distinctes, tandis que le dernier groupe est une collection de toutes des donn´ees. Ces groupes vont
nous permettre d’exp´erimenter les performance des TripleStores pr´esent´es dans le chapitre pr´ec´edent. Ici,
nous nous focalisons sur trois crit`eres de performance : le chargement, les requˆetes, les raisonnements.
Ces exp´erimentations ont ´et´e effectu´ees sur un Serveur de l’INRA avec comme syst`eme d’exploitation
Ubuntu Server. Ci-dessous, nous pouvons voir la configuration d´etaill´ee de ce syst`eme :
Processeur Intel(R) Xeon(R) CPU L5420 @ 2.50GHz
Front side bus 1333 MHz
Cache L2 12M
M´emoire vivre 32GB
Stockage 160GB
Tableau 5.1: La configuration du serveur exp´erimental
5.2 Benchmarking des platformes
5.2.1 Chargement de donn´ees
Avec les fichiers RDF volumineux g´en´er´es, le test d’importation de donn´ees dans les TripleStore va
nous donner une vue particuli`ere sur la performance de chargement de donn´ees. Chaque syst`eme a une
fa¸con particuli`ere d’organiser l’indexation des donn´ees ce qui impacte le m´ecanisme de chargement des
42

53. donn´ees. Certains TripleStores permettent aux utilisateurs de param´etrer diff´erentes configurations par
exemple les champs des index, l’ordre de priorit´e pour faire l’index, les m´emoires maximales utilis´e etc ..
Par ailleurs, il y a des syst`emes qui ne peuvent pas charger directement de grands fichiers (par exemple
avec Sesame, Virtuoso). Dans ces cas, un syst`eme a ´et´e mis en place sp´ecifiquement pour d´ecouper les
fichiers en taille plus r´eduite. D’autres syst`emes comme Fuseki, Stardog et GraphDB fournissent des outils
facilitant le chargement de grands fichiers.
Figure 5.1: La comparaison du temps de chargement sur diff´erents TripleStores
Nombre de triplets
TripleStore
Sesame 4Store Virtuoso Fuseki Stardog GraphDB
100,000 3,291 13 5,029 1,990 2,648 4,752
1,000,000 26,674 7,724 45,699 10,210 7,674 85,919
10,000,000 361,188 87,347 584,430 104,700 64,163 898,014
20,000,000 1,045,045 236,572 2,407,238 417,650 155,122 1,984,853
40,000,000 2,943,355 648,780 4,359,881 1,205,740 695,549 3,876,903
Tableau 5.2: La comparaison du temps de chargement sur diff´erents TripleStores en millisecondes
Les r´esultats de benchmark sur le temps de chargement de donn´ees sont obtenus avec le meilleur
temps pour 4Store, tandis que le syst`eme Virtuoso est le plus lent. Nous pouvons l’expliquer grˆace `a
leurs diff´erences sur la structure des index et le stockage de donn´ees. Chez Virtuoso, l’import de triplets
est r´ealis´e dans des tables de RDBMS en utilisant le protocole ODBC, alors que dans le cas de 4Store
l’import ne n´ecessite pas de transformation car la structure de stockage est un arbre.
5.2.2 Recherche de donn´ees
La partie la plus importante dans un syst`eme de gestion de donn´ees est la performance des requˆetes.
L’exp´erimentation des requˆetes permet d’´evaluer en d´etail un syst`eme. C’est pourquoi, nous avons mis
en place le deuxi`eme benchmark pour tester la capacit´e de recherche des donn´ees dans ces syst`emes.
Afin de s’assurer d’une ´egalit´e entre des syst`emes interrog´es, toutes des requˆetes sont lanc´ees via des
points d’acc`es disponibles dans tous les triplets. Nous avons d´efinis plusieurs types de recherche pour
tester les cas possible.
43

54. L’exemple de requˆete num´ero 1
Dans cette requˆete, on veut trouver les informations de l’image avec la date cr´e´ee, le type de prise de
vue (`a cˆot´e et en haut), et l’angle de la cam´era. Pour limiter les r´esultats obtenus, nous avons utilis´e un
filtrage sur l’angle de la cam´era avec des valeurs sup´erieures `a 300° ou inf´erieures `a 100°.
1 PREFIX rdf: <http:// www.w3.org/1999/02/22-rdf -syntax -ns#>
2 PREFIX ia: <http://www.mistea.supagro.inra.fr/ontologies/2015/03/ imageAnnotation #>
3 SELECT ?Image ?Date ?ViewType ? hasCameraAngle WHERE {
4 ?Image rdf:type ia:Image .
5 ?Image ia:timeStamp ?Date .
6 ?Image ia: hasViewType ?ViewType.
7 ?Image ia: hasCameraAngle ? hasCameraAngle .
8 FILTER (? hasCameraAngle < 100 || ? hasCameraAngle >300)
9 }
Figure 5.2: L’exemple de requˆete num´ero 1
Figure 5.3: L’evaluation de la requˆete num´ero 1 sous forme de courbe graphique
Nombre de triplets
TripleStore
Sesame 4Store Virtuoso Fuseki Stardog GraphDB
100,000 1,215 930 1,267 1,334 1,165 1,141
1,000,000 2,046 1,019 5,552 3,830 2,306 1,962
10,000,000 22,392 2,109 50,230 37,905 25,316 2,324
20,000,000 83,001 3,356 151,629 57,839 22,715 69,776
40,000,000 104,444 5,836 153,385 126,860 60,968 154,858
Tableau 5.3: L’evaluation de la requˆete num´ero 1 (temps en millisecondes)
Pour cette requˆete, le meilleur r´esultat est obtenu avec 4Store alors que le moins performant est
Virtuoso. La diff´erente du temps d’ex´ecution entre les syst`emes est tr`es grande. En g´en´eral, les syst`emes
ont un temps d’augmentation lin´eaire sur l’ensemble des jeux de donn´ees. En particulier, pour des jeux
de donn´ees de petites tailles (100.000 triplets et 1 millions de triplets), le temps d’ex´ecution des syst`emes
n’est pas tr`es diff´erent mais il est significatif avec des jeux de donn´ees tr`es grands.
44

55. L’exemple de requˆete num´ero 2
La deuxi`eme requˆete est construite sur la base de la premi`ere avec une partie additionnelle sur l’ar-
rangement des donn´ees obtenues sur le champ de l’angle du cam´era et la date cr´e´ee de l’image. Cette
requˆete nous permet de tester la capacit´e de recherche de donn´ees et l’arrangement de donn´ees avec la
commande ORDER BY.
1 PREFIX rdf: <http:// www.w3.org/1999/02/22-rdf -syntax -ns#>
2 PREFIX ia: <http://www.mistea.supagro.inra.fr/ontologies/2015/03/ imageAnnotation #>
3 SELECT ?Image ?Date ?ViewType ? hasCameraAngle WHERE {
4 ?Image rdf:type ia:Image .
5 ?Image ia:timeStamp ?Date .
6 ?Image ia: hasViewType ?ViewType.
7 ?Image ia: hasCameraAngle ? hasCameraAngle .
8 FILTER (? hasCameraAngle < 100 || ? hasCameraAngle >300)
9 }
10 ORDER BY ? hasCameraAngle ?Date
Figure 5.4: L’exemple de requˆetes num´ero 2
Figure 5.5: L’evaluation de la requˆete num´ero 2 sous forme de courbe graphique
Nombre de triplets
TripleStore
Sesame 4Store Virtuoso Fuseki Stardog GraphDB
100,000 1,433 1,018 1,381 1,557 1,228 1,497
1,000,000 3,549 3,733 4,621 5,961 2,676 2,967
10,000,000 46,563 45,622 7,6373 62,134 34,671 41,087
20,000,000 108,824 68,844 252,532 69,103 27,913 86,922
40,000,000 127,654 109,274 312,421 171,694 79,169 191,211
Tableau 5.4: L’evaluation de la requˆete num´ero 2 (temps en millisecondes)
Dans ce cas, il n’y a pas de changement dans le classement pour Virtuoso qui a encore pris beaucoup
de temps pour r´ealiser cette requˆete. N´eanmoins, l’outil qui a donn´e le meilleur r´esultat dans ce cas
est Stardog. Comme la requˆete pr´ec´edente, les syst`emes r´epondent tous tr`es bien sur des petits jeux de
45

56. donn´ees. Avec des outils 4Store, Sesame, Fuseki et GraphDB, le temps d’ex´ecution est assez proche. Cela
peut s’expliquer car ils ont tous une organisation de donn´ees sous forme d’arbre alors que Virtuoso les
stockent dans des tables relationnelles.
L’exemple de requˆete num´ero 3
Cette requˆete teste la capacit´e de recherche des donn´ees d’image avec la date cr´e´es et l’angle de la
cam´era en associant plusieurs patterns diff´erents grˆace `a la commande UNION. Cela permet d’´elargir les
r´esultats obtenus a d’autres graphes ou des valeurs diff´erentes.
1 PREFIX ia: <http://www.mistea.supagro.inra.fr/ontologies/2015/03/ imageAnnotation #>
2 SELECT ?Image ?Date ? hasCameraAngle WHERE {
3 {
4 ?Image rdf:type ia:Image . ?Image ia: hasCameraAngle ? hasCameraAngle .
5 FILTER (? hasCameraAngle < 100)
6 } UNION {
7 ?Image rdf:type ia:Image . ?Image ia: hasCameraAngle ? hasCameraAngle .
8 FILTER (? hasCameraAngle > 200)
9 }
10 }
Figure 5.6: L’exemple de requˆete num´ero 3
Figure 5.7: L’evaluation de la requˆete num´ero 3 sous forme de courbe graphique
Nombre de triplets
TripleStore
Sesame 4Store Virtuoso Fuseki Stardog GraphDB
100,000 1,472 946 1,279 1,398 1,184 1,261
1,000,000 3,376 1,187 3,472 4,297 2,400 3,141
10,000,000 34,376 3,512 55,702 42,020 33,374 36,169
20,000,000 72,014 5,548 15,113 65,627 26,765 81,045
40,000,000 149,574 11,407 77,747 148,608 71,726 186,391
Tableau 5.5: L’evaluation de la requˆete num´ero 3 (temps en millisecondes)
Dans cette requˆete, 4Store est le meilleur outil car le plus rapide dans l’ex´ecution des requˆetes. Au
46

57. contraire, GraphDB est l’outil qui sera le plus long dans l’ex´ecution suivie de peu par Sesame et Fuseki.
Nous pouvons voir ´egalement qu’il y une irr´egularit´e dans la vitesse d’ex´ecution sur les deux ensembles
de donn´ees 10 et 20 millions de triplets clairement illustr´e avec Virtuoso et Stardog. Cette diff´erence
s’explique par le fait qu’il y a deux ensembles de donn´ees distincts dans l’´evaluation.
L’exemple de requˆete num´ero 4
Dans le derni`ere requˆete, nous avons compt´e le nombre de triplets dans les syst`emes par utiliser la
commande COUNT. Nous avons utilis´e un filtrage sur le type de vue et l’angle du cam´era pour limiter
des nombres triplets dans le r´esultat.
1 PREFIX rdf: <http:// www.w3.org/1999/02/22-rdf -syntax -ns#>
2 PREFIX ia: <http://www.mistea.supagro.inra.fr/ontologies/2015/03/ imageAnnotation #>
3 SELECT (count (? Image) as ?ima) WHERE{
4 ?Image rdf:type ia:Image .
5 ?Image ia: hasViewType ? hasViewType .
6 ?Image ia: hasCameraAngle ? hasCameraAngle .
7 FILTER (? hasViewType = "side" || ?hasViewType = "Side" && ? hasCameraAngle > 200 )
8 }
Figure 5.8: L’exemple de troisi`eme requˆetes
Figure 5.9: L’evaluation de la requˆete num´ero 4 sous forme de courbe graphique
Nombre de triplets
TripleStore
Sesame 4Store Virtuoso Fuseki Stardog GraphDB
100,000 1,114 951 994 1,068 970 1,065
1,000,000 2,273 1,307 1,550 2,186 1,115 1,224
10,000,000 18,558 -1,0 7,765 10,633 21,994 12,419
20,000,000 36,237 -1,0 18,281 43,402 4,003 24,986
40,000,000 73,750 -1,0 32,413 82,783 8,479 58,806
Tableau 5.6: L’evaluation de la requˆete num´ero 4 (temps en millisecondes)
Il y a une erreur sur l’ex´ecution de l’outil 4Store avec les jeux de donn´ees sup´erieurs `a 10 millions
47

58. de triplets. Nous avons indiqu´e la valeur -1.0 pour signaler cette erreur. Le meilleur outil dans cette
´evaluation est Stardog au contraire de Virtuoso qui obtient le plus long temps d’ex´ecution.
5.2.3 Inf´erence sur les donn´ees
Dans cette section nous souhaitons ´evaluer la capacit´e d’inf´erence et de raisonnement des diff´erents
Triplestores. Nous utilisons une ontologie d´evelopp´ee sp´ecifiquement par l’´equipe INRA pour g´erer les
donn´ees d’image.
Les inf´erences sont d´efinies au niveau g´en´eral pour que nous puissions les lancer dans tous les TripleS-
tores. En effet, il y a des diff´erences dans le support de la capacit´e des outils (Le tableau 4.3). Par exemple,
4Store n’integre pas de moteur d’inf´erence par d´efaut mais n´ecessite d’installer un module ´etendu 4sr1
.
Certains TripleStores soutiennent seulement les inf´erences au niveau RDFS comme 4Store et Sesame. Les
autres soutiennent les inf´erences au niveau RDFS et OWL comme Stardog, GraphDB, et Virtuoso. Dans
notre benchmark, nous utiliserons deux types de raisonnement pour distinguer la capacit´e d’inf´erence des
TripleStore.
Premi`ere exemple d’inf´erence
Cet exemple a ´et´e r´ealis´e pour ´evaluer le raisonnement sur les relations des propri´et´es qui sont d´efinies
dans RDFS. Ici, la relation “rdfs :subPropertyOf ” est utilis´ee pour montrer les deux propri´et´es “comes-
FromPlateau” et “hasSource”. Ainsi, la requˆete sur l’object “Data” peut inf´erer des nouvelles donn´ees
dans “Image” et aussi les donn´ees “TechicalPlateau” peuvent ˆetre trouv´ees par l’objet “Source”.
Figure 5.10: Les relations inf´er´ees sur l’ontologie dans le premier exemple
1 PREFIX : <http://www.mistea.supagro.inra.fr/ontologies/2015/03/ imageAnnotation #>
2 SELECT ?data ?source ?hasViewType WHERE {
3 ?data :hasSource ?source .
4 ?data :hasViewType ?hasViewType .
5 FILTER regex (? hasViewType , "side","i")
6 }
Figure 5.11: La requˆete du premi`ere exemple d’inf´erence
Puisque les r´esultats obtenus dans ces exemples d’inf´erences sont tr`es diff´erents entre les TripleStores,
nous avons utilis´e une fonction logarithmique pour illustrer les valeurs du temps d’ex´ecution. En g´en´eral,
nous avons de bons r´esultats avec des ensembles de donn´ees de petites tailles dans tous les TripleStores
1https ://github.com/msalvadores/4sr/wiki
48

59. Figure 5.12: Le temps d’ex´ecution de la premi`ere inf´erence sous forme de graphique
Nombre de triplets
TripleStore
Sesame 4Store Virtuoso Fuseki Stardog GraphDB
100,000 2,137 3,510 2,467 5,914 1,017 1,967
1,000,000 7,171 38,569 2,960 56,845 14,701 4,735
10,000,000 71,985 10,384,120 27,109 657,830 134,716 35,378
20,000,000 126,246 17,160,243 62,054 1,100,466 379,949 52,208
40,000,000 229,328 53,684,948 81,083 33,644,938 611,286 73,099
Tableau 5.7: L’evaluation de la premi`ere inf´erence (temps en millisecondes)
mais les diff´erences sur la performance se creusent avec les ensembles de triplets volumineux. Dans ce
cas, les r´esultats en d´etail montrent que 4Store et Jena Fuseki sont les plus lents pour r´ealiser l’inf´erence.
Au contraire, les TripleStores GraphDB et Virutoso donnent les meilleurs temps d’ex´ecution.
Figure 5.13: Les relations inf´er´ees sur l’ontologie dans le deuxi`eme
exemple d’inf´erence
Requˆete du deuxi`eme exemple
Dans cet exemple, nous avons continu´e
`a tester la capacit´e d’inf´erence au
niveau RDFS sur le domaine et le
range des valeurs des objets. En fait,
cette inf´erence utilise la relation que
nous d´efinissons comme dans le pre-
mier exemple. N´eanmoins, le point im-
portant de cette inf´erence est bas´e sur
des donn´ees particuli`eres. Nous pouvons
le voir en d´etail dans la figure 5.13
49

60. 1 PREFIX rdf: <http:// www.w3.org/1999/02/22-rdf -syntax -ns#>
2 PREFIX : <http://www.mistea.supagro.inra.fr/ontologies/2015/03/ imageAnnotation #>
3 SELECT ?image ?Source ?hasViewType WHERE {
4 ?image :hasSource ?Source .
5 ?image rdf:type :Image .
6 ?image :hasViewType ? hasViewType .
7 FILTER (? Source =" http://www.phenome -fppn.fr/m3p/phenoarch ") .
8 FILTER REGEX (? hasViewType , "top","i")
9 }
Figure 5.14: L’exemple de la deuxi`eme inf´erence
Figure 5.15: Le temps d’ex´ecution de la deuxi`eme inf´erence sous forme de graphique
Nombre de triplets
TripleStore
Sesame 4Store Virtuoso Fuseki Stardog GraphDB
100,000 2,479 3,193 17,713 5,619 989 2,497
1,000,000 8,215 11,483 18,178 56,960 1,923 3,308
10,000,000 71,829 4,578,915 15,632 648,863 13,198 23,359
20,000,000 123,991 15,195,516 37,506 1,044,958 20,723 38,792
40,000,000 216,465 39,261,745 43,957 29,045,934 51,223 63,312
Tableau 5.8: L’evaluation de la deuxi`eme inf´erence (temps en millisecondes)
50

61. Cet exemple nous permet de confirmer que les deux TripleStore 4Store et Jena Fuseki sont tr`es lents
pour executer les inf´erences sur des donn´ees volumineuses. Les trois TripleStore Stardog, GraphDB et
Virtuoso obtiennent de bons temps d’ex´ecution. Sesame dans les deux inf´erences obtient des r´esultats
moins bon mais tr`es correct pour un syst`eme de gestions de base de donn´ees de triplets OpenSource.
Dans certains cas, il donne des r´esultats meilleurs que les TripleStores commerciaux.
5.3 Evaluation et Analyse
L’´evaluation des TripleStores donne une vue g´en´erale sur la capacit´e d’ex´ecution et la performance de
ces syst`emes. Chaque syst`eme a des diff´erences dans l’organisation et dans l’indexation des triplets, par
exemple Virtuoso utilise des tables relationnelles, 4Store utilise la structure de l’arbre radix, tandis que
Sesame, Jena Fuseki et GraphDB appliquent la structure de l’arbre B ou B+ [20] [21]. Ces diff´erences sont
des ´el´ements importants qui impactent sur leurs performances. N´eanmoins, nous devons aussi consid´erer
les fonctionnalit´es supports n´ecessaires pour un syst`eme de gestion de base de donn´ees de triplets. La
fonctionnalit´e la plus importante est la capacit´e de raisonnement sur les donn´ees au niveau RDFS ou
OWL. De plus, avec les bases de donn´ees sur de gros volumes, la distribution des processus sur plusieurs
machines, peut faciliter le raisonnement sur de grands graphes de donn´ees RDF. Dans ce contexte, les
TripleStores ont besoin de soutenir le regroupement les bases de donn´ees reparties sur un r´eseau de
plusieurs machines pour communiquer et ´echanger les donn´ees [22] [23] [24] [25]. Ci-dessus, nous ´evaluons
les trois crit`eres les plus importants pour un syst`eme de gestion de base de donn´ees triplets : Chargement
de donn´ees, Recherche de donn´ees et Inf´erence de donn´ees.
Avec 4Store, les avantages de l’indexation de donn´ees, selon l’arbre radix nous fournissent un bon outil
pour les op´erations de chargement et recherche de donn´ees. Il est toujours un des meilleurs outils avec le
temps d’ex´ecution le plus rapide. De plus, l’architecture de 4Store permet de faire le regroupement les
donn´ees distribu´ee et d’utiliser dans plusieurs machines dans un mˆeme temps. Toutefois, la fonction de
recherche dans 4Store est encore perfectible, nous pouvons constater qu’il a des erreurs dans quelques cas
(dans l’exemple de recherche num´ero 4). De plus, l’interface d’interaction a plusieurs limitations. Mais
plus grand inconv´enient est le support de la fonctionnalit´e de raisonnement. En r´ealit´e, le moteur de
raisonnement est un module ´etendu nomm´e 4sr qui est une branche du projet 4Store mise en œuvre pour
faire le raisonnement arri`ere pour 4Store. Ce module supporte une capacit´e d’inf´erence tr`es faible avec
les relations : rdfs :subClassOf, rdfs :subPropertyOf, rdfs :domain et rdfs :range dans RDFS. Le choix de
4Store pour construire le syst`eme avec de gros volume de donn´ees d´ependra du besoin en raisonnement.
S’il n’y a pas besoin d’inf´erer sur les donn´ees, 4Store est peut-ˆetre le bon choix.
Sesame est l’un des deux premiers outils qui est mis en œuvre pour g´erer les donn´ees RDF. Avec
cet outil, les r´esultats restent moyens dans les benchmarks sur le chargement, la recherche et l’inf´erence
de donn´ees. Ces r´esultats sont acceptables pour un outil Opensource. Toutefois, Sesame poss`ede des
inconv´enients dans la gestion de donn´ees volumineuses. Tout d’abord, il ne peux pas ˆetre d´eploy´e en
cluster de machines avec un grand graphe reparti, mais plutˆot permet que de cr´eer un base de donn´ees
f´ed´er´e avec des graphes qui sont compl`etement s´epar´ees. Ensuite, la modele de donn´ees en RDF natif dans
Sesame est optimise pour les jeux de donn´ees de taille moyenne. Ses limites en termes d’utilisabilit´e sont
51

62. autour de 100 `a 150 millions de triplets2
(Cela d´epend beaucoup du mat´eriel ainsi que des caract´eristiques
de l’ensemble de donn´ees). Enfin, le m´ecanisme d’inf´erence de Sesame cr´ee beaucoup de nouveaux triplets
et cela augmente la taille de la base de donn´ees. Ceci est g´erable pour des graphes de taille moyenne mais
atteint ses limites pour des grands graphes.
Le Virtuoso est uniquement construit sur la base de l’architecture du syst`eme de gestion bases de
donn´ees relationnelles. Ceci peut expliquer ses mauvais de r´esultats sur les temps d’ex´ecution de charge-
ment de donn´ees et quelques exemples de recherches. Par contre, Virtuoso a des avantages dans la capacit´e
d’inf´erence de donn´ees. Il peut effectuer des raisonnements avec les donn´ees d´efinies par le RDFS ou OWL.
Dans les Triplestores ´evalu´es, Virtuoso est le meilleur outil Opensource qui soutient compl`etement des
composants essentiels d’un syst`eme de gestion de base de donn´ees, comme les transactions de l’ACID, la
s´ecurit´e ou l’interface d’interaction pour l’utilisateur etc. De plus, il nous permet de mettre en œuvre un
syst`eme avec un fort support de raisonnement. Enfin Virtuoso permet de d´eployer les bases de donn´ees
sur plusieurs clusters de machines. Toutefois, cette fonctionnalit´e n’est support´ee que dans la version
commerciale.
L’outil Jena Fuseki est d´evelopp´e sur la base du framework Jena. Il apporte les caract´eristiques du
premier framework qui est construit pour les donn´ees RDF. Notre benchmark est effectu´e avec le stockage
selon l’architecture de Jena TDB et l’indexation utilise la structure de l’arbre B+. Dans les ´evaluations,
Jena montre de bons r´esultats dans le chargement de donn´ees. Toutefois, la recherche de donn´ees et les
inf´erences avec Jena Fuseki ont toujours pris beaucoup de temps d’ex´ecution. Aujourd’hui, Jena peut
fonctionner sur un cluster de plusieurs machines selon diff´erentes architectures. Voir quelques exemples
d´efinis dans cet article [20]. D’ailleurs, Jena fournit des APIs (Apache Jena Elephas) qui permettent
d’´ecrire des applications int´egr´e dans Apache Hadoop. D’apr`es les r´esultats nous pouvons dire que Jena
Fuseki convient pour des bases de donn´ees RDF de taille moyenne.
Le GraphDB Ontotext est construit `a partir du framework Sesame dans le but de fournir des ca-
ract´eristiques manquantes `a ce dernier. Les am´eliorations de GraphDB se focalisent sur la capacit´e de
raisonnement, l’interface utilisateur et l’architecture cluster de donn´ees. Dans presque tous les cas des
´evaluations, nous pouvons voir que GraphDB donne un temps d’ex´ecution plus performant que Sesame no-
tamment dans la recherche de donn´ees et les inf´erences. En fait, il y a moins diff´erence dans le m´ecanisme
d’indexation de GraphDB et Sesame ce qui explique la faible diff´erence dans le temps d’ex´ecution. Avec
son moteur d’inference, GraphDB soutient des raisonnements au niveau RDFS et OWL. Grace `a la ver-
sion entreprise de GraphDB (que nous avons test´e pour un mois), il est possible de g´erer de gros volumes
donn´ees RDF.
Le dernier outil dans notre ´evaluation est Stardog. Cet outil donne des r´esultats impressionnants sur
les trois crit`eres compar´ees : Chargement de donn´ees, Recherche de donn´ees et Inf´erence de donn´ees. Il
est toujours dans les meilleurs outils qui sont les plus performants. Pour le raisonnement, il supporte
des inf´erences dans RDFS et OWL. De plus il est permet de cr´eer des clusters de au niveau haut de
performance. Nous pouvons dire que Stardog est le meilleur outil dans la liste de tous les outils de notre
Benchmark.
2http ://www.rivuli-development.com/further-reading/sesame-cookbook/loading-large-file-in-sesame-native/
52

63. Conclusion
L’organisation et la gestion de donn´ees scientifiques sont de plus en plus importantes dans le processus
de r´ealisation des ´etudes biologiques. La recherche d’une m´ethode de gestion de donn´ees peut aider `a les
utiliser et `a les exploiter de la meilleure fa¸con dans le but d’´economiser du temps et aussi d’augmenter
la performance des syst`emes de gestion. Le probl`eme que nous avons rencontr´e au cours de ce stage est
la taille de ces donn´ees. Les m´ethodes ordinaires ne permettent pas de g´erer ces donn´ees correctement.
De plus, le besoin d’utiliser la s´emantique dans la recherche et l’utilisation des donn´ees nous oblige `a
trouver une m´ethode d’organisation adapt´ee. Compte tenu de ces deux probl´ematiques, l’´etat de l’art,
dans le chapitre 2 de ce rapport, nous fournit une vue g´en´erale des solutions possibles. En fait, chaque
solution d´ecrite est l’association d’une ou de plusieurs m´ethodes diff´erentes. En g´en´eral, nous pouvons
r´esumer ces solutions en deux directions : la transformation des requˆetes (ou r´e-´ecriture ), la transfor-
mation des donn´ees en triplets RDF (ou mat´erialisation). Chaque direction contient des avantages et des
inconv´enients particuliers. Au cours de ce stage, nous avons fait le choix de la mat´erialisation de donn´ees
en RDF. Ce choix nous a permis de faciliter la recherche s´emantique sur les donn´ees. Accompagnant
ce choix, nous avons dˆu d´efinir de nouveaux mod`eles des donn´ees dans une forme unifi´ee pour trans-
former des donn´ees exp´erimentales en RDF. Pour ce faire, un programme a ´et´e ´ecrit pour transformer
des donn´ees sous la forme de documents JSON stock´es dans MongoDB en triplets RDF. Afin de g´erer
ces grands graphes de triplets de mani`ere optimale, nous avons ´evalu´e plusieurs syst`emes de gestion de
bases de donn´ees de triplets RDF. Les TripleStores 4Store, Sesame, Virtuoso, Jena Fuseki, GraphDB et
Stardog ont ´et´e choisis pour r´ealiser un benchmark sur diff´erents crit`eres : les capacit´es de chargement de
donn´ees, de recherche de donn´ees et d’inf´erence de donn´ees. Ce benchmark n’est pas exhaustif, il manque
en effet quelques syst`emes comme AllegroGraph, BlazeGraph etc. N´eanmoins, dans les r´esultats obtenus,
nous pouvons voir une diff´erence entre deux groupes : Open source (4Store, Sesame, Jena Fuseki) et Com-
mercial (GraphDB, Stardog, Virtuoso). En g´en´eral, la performance du groupe commercial est meilleure.
Particuli`erement Stardog qui obtient de bons r´esultats dans presque touts les crit`eres compar´es. Cela est
bien-sur du au fait que ces syst`emes sont d´evelopp´es par des soci´et´es sp´ecialis´es au lieu d’un communaut´e
acad´emique dans les syst`eme Open Source.
L’approche de mat´erialisation de donn´ees en triplets RDF convient pour augmenter la capacit´e de re-
cherche s´emantique sur les donn´ees. Plus pr´ecis´ement, au niveau des inf´erences de nouvelles connaissances
bas´es sur des ontologies qui sont automatiquement r´ealis´ees dans triplestores. Toutefois, cette approche
poss`ede encore des inconv´enients notamment sur la gestion de donn´ees volumineuses, car jusqu’`a pr´esent
seuls certains triplestores peuvent supporter de gros volumes de donn´ees de mani`ere ´equivalente aux
syst`emes NoSQL. Nous pensons que dans le futur, les travaux sur les approches de transformation de
53

64. requˆetes (NoSQL-SPARQL) pourront nous aider `a comparer des avantages et des d´esavantages de ces
deux approches.
54

65. R´ef´erences
[1] L. LE Ngoc, “D´eveloppement d’un syst`eme de gestion de donn´ees de ph´enotypage chez le riz
(o.sativa),” Cours : Travail Personnel Encardr´e, Institut de la Francophonie pour l’Informatique,
2014.
[2] A. Shiri, “Linked data meets big data : A knowledge organization systems perspective,” pp. 16–20,
2014.
[3] L. LE Ngoc, S. JOUNANIC, P. GANTET, and P. LARMANDE, “D´eveloppement d’un ou-
til g´en´etique d’indexation pour optimiser l’exploitation des donn´ees biologiques,” JOBIM 2015,
Journ´ees Ouvertes en Biologie, Informatique et Math´ematiques, 2015.
[4] Laney, “3d data management : Controlling data volume, velocity, and variety,”
http ://blogs.gartner.com/doug-laney/files/2012/01/ad949- 3D-Data-Management-Controlling-
Data-Volume-Velocity-and- Variety.pdf, 2011.
[5] V. Rometty, “Extracting value from chaos,” IDC Analyze the Future, no. 42, p. P.4, 2013.
[6] CNRS, “The big data r´evolution,” Le Journal, no. 28, 2013.
[7] T. Berners-Lee, ““the semantic web”, scientific american magazine,” 2001.
[8] T. Berners-Lee, Fischetti, and Mark, “Weaving the web,” 1999.
[9] C. End Point, “Benchmarking top nosql databases : Apache cassandra, couchbase, hbase, and mon-
godb,” 2015.
[10] M. Rodriguez-Muro, R. Kontchakov, and M. Zakharyaschev, “Ontology-based data access ontop of
database,” The Semantic Web - ISWC 2013, vol. 8218 of the series Lecture Notes in Computer
Science, pp. 558–573, 2013.
[11] T. Bagosi, D. Calvanese, J. Hardi, and S. Komla-Ebri, “The ontop framework for ontology based data
access,” The Semantic Web and Web Science - ISWC 2014, vol. 480 of the series Communications
in Computer and Information Science, pp. 67–77, 2014.
[12] M. Rodriguez-muro, D. Rezk, M. Slusnys, T. Bagosi, and D. Calvanese, “Evaluating sparql-to-sql
translation in ontop,” CEUR Workshop Proceedings, vol. 1015, p. 94–100, 2013.
[13] S. Das, S. Sundara, and R. Cyganiak, “R2rml : Rdb to rdf mapping language,” 2012.
55

66. [14] F. Michel, L. Djimenou, C. Faron-Zucker, and J. Montagnat, “R2rml : Relational and non-relational
databases to rdf mapping language,” https ://hal.archives-ouvertes.fr/hal-01066663v3, 2014.
[15] A. Dimou, M. Vander Sande, P. Colpaert, R. Verborgh, E. Mannens, and R. Van de Walle, “Rml : A
generic language for integrated rdf mappings of heterogeneous data,” Proceedings of the 7th Workshop
on Linked Data on the Web (LDOW2014), 2014.
[16] J. Van Ossenbruggen, R. Troncy, G. Stamou, and J. Pan, “Image : Annotation on the semantic web,”
W3C Incubator Group Report, 2007.
[17] M. SIVERA, “Rapport de stage : Annotation s´emantique d’images,” 2015.
[18] S. Harris, N. Lamb, and N. Shadbolt, “4store : The design and implementation of a clustered
rdf store,” The 5th International Workshop onScalable Semantic Web Knowledge BaseSystems
(SSWS2009), 2009.
[19] D. Morrison, “Practical algorithm to retrieve information coded in alphanumeric,” Journal of the
ACM (JACM), vol. 15, pp. 514–534, 1968.
[20] A. Owens, A. Seaborne, and N. Gibbins, “Clustered tdb : A clustered triple store for jena,” 2009.
[21] M. Hepp, P. De Leenheer, A. De Moor, and Y. Sure, Ontology Management : Semantic Web, Semantic
Web Services and Business Applications, ch. 4 : Ontology Reasoning with large data repositories,
p. 92. Springer, 2008.
[22] I. Filali, F. Bongiovanni, F. Huet, and F. Baude, “A survey of structured p2p system for rdf data sto-
rage and retrieval,” Transactions on Large-Scale Data and Knowledge Centered Systems III, pp. 20–
55, 2011.
[23] N. Papailiou, I. Konstantinou, D. Tsoumakos, P. Karras, and N. Kowiris, “H2rdf+ : High-
performance distributed joins over large-scale rdf graphs,” Big Data, 2013 IEEE International Confe-
rence on, pp. 255–263, 2013.
[24] R. Punnoose, A. Crainiceanu, and D. Rapp, “Rya : A scalable rdf triple store for the clouds,”
Proceedings of the 1st International Workshop on Cloud Intelligence, pp. 4 :1–4 :8, 2012.
[25] B. Wu, Y. Zhou, P. Yuan, H. Jin, and L. Liu, “Semstore : A semantic-preserving distributed rdf
triple store,” Proceedings of the 23rd ACM International Conference on Conference on Information
and Knowledge Management, pp. 509–518, 2014.
56

67. Annexe A
Mod`ele de document JSON
Dans la liste ci-dessous, ce sont des documents du mod`ele JSON qui sont d´efinis pour servir le but
de transformation de base de donn´ees relationnelles aux des documents JSON qui vont ˆetre stock´es dans
MongoDB.
Le Mod`ele JSON pour le profil du Cam´era qui va ˆetre stock´e des informations de configurations, de
descriptions et de r´eglages du cam´era :
1 ImageCameraProfile {
2 " configuration " : {
3 "provider" : " phenowaredb",
4 "stationid" : int,
5 " imgacqcameraprofileid " : int,
6 " imgacqcameraprofilename " : string,
7 " validatedProfile " : boolean,
8 " deletedProfile " : boolean,
9 " interfaceacqtype " : int
10 },
11 " description " : string,
12 "settings" :{
13 "viewType" : string,
14 "viewCount" : int,
15 "width" : int,
16 "height" : int,
17 "triggerMode " : int,
18 "shutter" : int,
19 "gain" : int,
20 "brightness" : int,
21 "hue" : int,
22 "gamma" : int,
23 "saturation" : int,
24 "sharpness" : int,
25 " whiteBalance " : int,
26 "pixelFormat " : string
27 }
28 }
Le document JSON pour le profil de la cabine qui va ˆetre stock´e des informations de configurations, de
descriptions et de r´eglages de la cabine :
1 ImageStationProfile
2 {
3 " configuration " : {
A.1

68. 4 "provider" : " phenowaredb",
5 "stationid" : int,
6 " imgacqstationprofileid " : int,
7 " imgacqstationprofilename " : string,
8 " validatedProfile " : boolean,
9 " deletedProfile " : boolean,
10 " interfaceacqtype " : int
11 },
12 " description " : string,
13 "settings" :{
14 " verticalPosition " : int,
15 "topLight" : int,
16 "sideLight" : int,
17 "zoom" : int,
18 "focus" : int,
19 "aperture" : int,
20 " rotationSpeed " : long,
21 " topViewCount " : int,
22 " sideViewCount " : int
23 }
24
25 }
Le document JSON de donn´ees du processus d’arrosage.
1 Watering{
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 "wateringid" : int,
17 "plantid" : int,
18 "studyname" : string,
19 "taskid" : int,
20 "calibration " : int,
21 "stationid" : int,
22 "usedscaleid " : int,
23 "usedpumpid" : int,
24 " nextLocation " : {
25 "lane" : int,
26 "rank" : int,
27 "level" : int,
28 }
29 },
30 " automatonSuccess " : boolean,
31 " userValidation " : boolean,
32 "setpoints" : {
33 "product" : string,
34 "scaleType" : string,
35 "pumpType" : string,
36 " targetWeight " : int,
A.2

69. 37 " targetQuantity " : int,
38 "pumpSpeed" : int,
39 "maxQuantity " : int,
40 "minWeight" : int,
41 "movePerch" : boolean,
42 },
43 "product" : string,
44 "scaleType" : string,
45 "pumpType" : string,
46 "pumpSpeed" : int,
47 "measures" : {
48 " weightBefore " : {
49 "value" : int,
50 "unity" : string,
51 "type" : "automatic",
52 "confidence" : "unspecified "
53 },
54 "weightAfter " : {
55 "value" : int,
56 "unity" : string,
57 "type" : "automatic",
58 "confidence" : "unspecified "
59 },
60 " weightAmount " : {
61 "value" : int, -- weightAfter - weightBefore
62 "unity" : string,
63 "type" : "computed",
64 "confidence" : "unspecified "
65 }
66 }
67 }
Le document JSON de donn´ees du processus de pess´ees
1 Weighing{
2 platform: string URI,
3 technicalPlateau : URI,
4 experiment: URI,
5 experimentAlias : string,
6 study: string,
7 studyAlias: string,
8 plant: URI,
9 plantAlias: string,
10 genotype: URI,
11 genotypeAlias : string,
12 date: date,
13 timestamp: int, --seconds
14 configurations :{
15 provider: " phenowaredb "
16 weighingid: objectid,
17 studyname: string,
18 taskid: objecid,
19 plantid: integer,
20 usedstationid : int,
21 usedscaleid: int,
22 nextLocation :{
23 lane: integer,
24 rank: integer,
25 level: integer
26 }
27 }
A.3

70. 28 automatonSuccess : boolean,
29 userValidation : boolean,
30 setpoints:{
31 scaleType: string,
32 }
33 scaleType: string,
34 weighingType : string,
35 measures:{
36 weightBefore :{
37 value: int,
38 unity: string,
39 type: "automatic",
40 confidence: string
41 }
42 weightAfter:{
43 value: int,
44 unity: string,
45 type: "automatic",
46 confidence: string
47 }
48 weight:{
49 value: int, --absolute (weightafter - weightbefore )
50 unity: string,
51 type: "computed",
52 confidence: string
53 }
54 }
55 }
A.4

71. Annexe B
Mappage de donn´ees JSON aux
triplets par xR2RML
Le mappage de document JSON aux triplets de la collection de profil du cam´era
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 <#StationProfile >
11 a rr:TriplesMap;
12 xrr: logicalSource [
13 xrr:query """db. stationprofile .find( { ’_id ’ : {$exists:true} } )""";
14 ];
15 rr:subjectMap [
16 rr:template "{$.uri}";
17 rr:class ia: AcquisitionStationProfile ;
18 ];
19 rr: predicateObjectMap [
20 rr:predicate ia: acquisitionStationProfileName ;
21 rr:objectMap [ xrr:reference "$. configuration . imgacqstationprofilename "; ];
22 ];
23 rr: predicateObjectMap [
24 rr:predicate ia: acquisitionStationProfileDescription ;
25 rr:objectMap [ xrr:reference "$.description "; ];
26 ];
27 rr: predicateObjectMap [
28 rr:predicate ia: isProfileOfStation ;
29 rr:objectMap [ xrr:reference "$. configuration .stationid "; ];
30 ];
31 rr: predicateObjectMap [
32 rr:predicate ia:indexer;
33 rr:objectMap [ xrr:reference "$.settings. verticalPosition "; ];
34 ];
35 rr: predicateObjectMap [
36 rr:predicate ia:topLight;
37 rr:objectMap [ xrr:reference "$.settings.topLight "; ];
38 ];
B.5

72. 39 rr: predicateObjectMap [
40 rr:predicate ia:sideLight;
41 rr:objectMap [ xrr:reference "$.settings.sideLight "; ];
42 ];
43 rr: predicateObjectMap [
44 rr:predicate ia:focus;
45 rr:objectMap [ xrr:reference "$.settings.focus "; ];
46 ];
47 rr: predicateObjectMap [
48 rr:predicate ia:zoom;
49 rr:objectMap [ xrr:reference "$.settings.zoom "; ];
50 ];
51 rr: predicateObjectMap [
52 rr:predicate ia:aperture;
53 rr:objectMap [ xrr:reference "$.settings.aperture "; ];
54 ];
55 rr: predicateObjectMap [
56 rr:predicate ia: rotationSpeed ;
57 rr:objectMap [ xrr:reference "$.settings. rotationSpeed "; ];
58 ];
59 rr: predicateObjectMap [
60 rr:predicate ia: topViewCount ;
61 rr:objectMap [ xrr:reference "$.settings. topViewCount "; ];
62 ];
63 rr: predicateObjectMap [
64 rr:predicate ia: sideViewCount ;
65 rr:objectMap [ xrr:reference "$.settings. sideViewCount "; ];
66 ].
Le mappage de document JSON aux triplets de la collection de profil de la cabine
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 <#CameraProfile >
11 a rr:TriplesMap;
12 xrr: logicalSource [
13 xrr:query """db. cameraprofile .find( { ’_id ’ : {$exists:true} } )""";
14 ];
15 rr:subjectMap [
16 rr:template "{$.uri}";
17 rr:class ia: CameraProfile ;
18 ];
19 rr: predicateObjectMap [
20 rr:predicate ia: whiteBalance ;
21 rr:objectMap [ xrr:reference "$.settings. whiteBalance "; ];
22 ];
23 rr: predicateObjectMap [
24 rr:predicate ia:brightness;
25 rr:objectMap [ xrr:reference "$.settings.brightness "; ];
26 ];
27 rr: predicateObjectMap [
28 rr:predicate ia: cameraProfileDescription ;
29 rr:objectMap [ xrr:reference "$.description "; ];
30 ];
B.6

73. 31 rr: predicateObjectMap [
32 rr:predicate ia:gain;
33 rr:objectMap [ xrr:reference "$.settings.gain "; ];
34 ];
35 rr: predicateObjectMap [
36 rr:predicate ia:gamma;
37 rr:objectMap [ xrr:reference "$.settings.gamma "; ];
38 ];
39 rr: predicateObjectMap [
40 rr:predicate ia:hue;
41 rr:objectMap [ xrr:reference "$.settings.hue"; ];
42 ];
43 rr: predicateObjectMap [
44 rr:predicate ia:pixelFormat ;
45 rr:objectMap [ xrr:reference "$.settings.pixelFormat "; ];
46 ];
47 rr: predicateObjectMap [
48 rr:predicate ia:saturation;
49 rr:objectMap [ xrr:reference "$.settings.saturation "; ];
50 ];
51 rr: predicateObjectMap [
52 rr:predicate ia:sharpness;
53 rr:objectMap [ xrr:reference "$.settings.sharpness "; ];
54 ];
55 rr: predicateObjectMap [
56 rr:predicate ia:shutter;
57 rr:objectMap [ xrr:reference "$.settings.shutter "; ];
58 ];
59 rr: predicateObjectMap [
60 rr:predicate ia:triggerMode ;
61 rr:objectMap [ xrr:reference "$.settings.triggerMode "; ];
62 ];
63 rr: predicateObjectMap [
64 rr:predicate ia:viewCount;
65 rr:objectMap [ xrr:reference "$.settings.viewCount "; ];
66 ];
67 rr: predicateObjectMap [
68 rr:predicate ia:viewType;
69 rr:objectMap [ xrr:reference "$.settings.viewType "; ];
70 ];
71 rr: predicateObjectMap [
72 rr:predicate ia:width;
73 rr:objectMap [ xrr:reference "$.settings.width "; ];
74 ];
75 rr: predicateObjectMap [
76 rr:predicate ia:height;
77 rr:objectMap [ xrr:reference "$.settings.height "; ];
78 ].
B.7

74. Annexe C
Point d’acc`es
La table suivante cite des point d’acc`es via protocole HTTP pour acc´eder des donn´ees RDF
TripleStore Point d’acc`es
Sesame http ://147.99.7.154 :8080/openrdf-sesame/repositories/phis40mnative
4Store http ://147.99.7.154 :9000/sparql/ ?soft-limit=-1
Virtuoso http ://147.99.7.154 :8890/sparql
Fuseki http ://147.99.7.154 :3030/phis40m/query
Stardog http ://147.99.7.154 :5820/phis40m/query
GraphDB http ://147.99.7.154 :8080/graphdb-workbench-se/repositories/ontotextphis40m
Tableau C.1: Les exemples de point d’acc`es de TripleStore
C.8