DÉVELOPPEMENT D’UN SYSTÈME CONNAISSANCE POUR BIG DATA APPLICATION AUX DONNÉES DE PHÉNOTYPAGE CHEZ LE RIZ (o SATIVA)

UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL

LÊ NGỌC LUYỆN

DÉVELOPPEMENT D’UN SYSTÈME CONNAISSANCE POUR
BIG DATA APPLICATION AUX DONNÉES DE
PHÉNOTYPAGE CHEZ LE RIZ (O. SATIVA)
PHÁT TRIỂN MỘT HỆ NHẬN DẠNG CHO DỮ LIỆU LỚN:
ỨNG DỤNG CHO DỮ LIỆU PHENOTYPING VỀ LÚA
(O. SATIVA)

MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE

HANOI – 2015


UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL

LÊ NGỌC LUYỆN

DÉVELOPPEMENT D’UN SYSTÈME CONNAISSANCE POUR
BIG DATA APPLICATION AUX DONNÉES DE
PHÉNOTYPAGE CHEZ LE RIZ (O. SATIVA)
PHÁT TRIỂN MỘT HỆ NHẬN DẠNG CHO DỮ LIỆU LỚN:
ỨNG DỤNG CHO DỮ LIỆU PHENOTYPING VỀ LÚA
(O. SATIVA)

Spécialité: Systèmes intelligents et Multimédia
Code: Programme pilote

MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE

Sous la direction de:
Ingénieur IRD, responsable de l’AXE Intégration de données de
l’Institut de Biologie Computationnelle, Dr. Pierre LARMANDE
Ingénieur INRA, Mme. Anne TIREAU

HANOI – 2015


ATTESTATION SUR L’HONNEUR
J’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les données et les résultats
qui y sont présentés sont exacts et n’ont jamais été publiés ailleurs. La source des informations citées
dans ce mémoire a été bien précisée.

LỜI CAM ĐOAN
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả nêu trong Luận văn là trung thực và chưa từng được ai công bố trong bất kỳ
công trình nào khác. Các thông tin trích dẫn trong Luận văn đã được chỉ rõ nguồn gốc.

Fait à Hano¨ı, le 20 octobre 2015
Hà nội, Ngày 20 tháng 10 năm 2015

Lê Ngọc Luyện

i


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’encouragements 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

ii


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 bioinformatique 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, Benchmark, NoSql, BigData, TripleStore

iii


Abstract
In the recent years, the data deluge in many areas of scientific research brings challenges in the treatment 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 semantic 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 semantic 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

iv


Table des mati`
eres
Remerciements

ii

R´
esum´

e

iii

Abstract

iv

Table des mati`
eres

v

Liste d’abr´
eviations

vii

Table des figures

viii

Liste des tableaux

x

INTRODUCTION

1

Chapitre 1

2

1.1

Pr´
esentation G´
en´
erale

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

Chapitre 3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Solution propos´
ee

22
23

v


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

Chapitre 4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Stockage et Indexation de donn´
ees RDF

30
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

Evaluation et Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.3

CONCLUSION

53

´ ERENCES
´
REF

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

vi


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
vii


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 mod`ele g´en´eral du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

viii


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

ix


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

x


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 laboratoires 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


Chapitre 1

Pr´
esentation G´
en´
erale
1.1
1.1.1

Pr´
esentation de l’´
etablissement d’accueil
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 innovantes 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 combin´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 (transcriptomique, 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 travers 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


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’alimentation, 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 hautd´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 recherche 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


❼ 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’environnement 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 analys´ees. Il faudra en effet ˆetre capable de les retrouver dans plusieurs ann´ees. De mˆeme, elles doivent pouvoir ˆ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’environnement 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 technologies 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 raisonnement 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


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
1.4.1

Contexte du sujet
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
` titre d’exemple, Twitter g´en´erait en janvier 2013, 7 teraoctets de donn´ees
zettaoctets en 2020[5]. A
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


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 propos´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


Type de base de donn´
ees1

Liste des syst`
emes utilis´
es

Cl´e - valeur

CouchDB, Oracle NoSQL Database, Dynamo, FoundationDB, HyperDex, 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, DocumentDB, 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

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’extraire du sens dans cette masse d’information notamment `
a travers des
m´ethodes de fouilles de donn´ees ou
des algorithmes d’apprentissage automatique scannant le web. Toutefois,
les probl`emes ne sont pas r´esolu pour
autant. Pourtant, a partir de l’id´ee de

Figure 1.1: L’architecture du web s´
emantique

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


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


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’informations, 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’interm´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 classification, en mettant l’accent sur la d´efinition de de “classes”, “sous-classes”, sur la fa¸con dont les ressources
9


individuelles peuvent ˆetre associes `
a ces classes, et de caract´eriser les relations entre les classes et leurs instances. 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

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

2.2.1

Analyse et ´
evaluation des solutions courantes
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
1 http
2 http

://lps-phis.supagro.inra.fr/phis/index.php
://vmbioesai-dev.ird.fr :8080/Syspherice

11


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.
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 documents 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/Reduce et un langage de requˆete riche `
a base
de documents. Toutefois, il ne fournit pas
un bon support pour les jointures complexes, le liage de donn´ees (linked data),
l’analyse de graphe et l’inf´erence ou le
raisonnement.
En connectant AllegroGraph `
a MongoDB, 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 documents JSON, ils sont g´er´ees par un

Figure 2.1: Le mod`
ele de composants dans un syst`eme MongoGraph

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 volumineuses. Le mod`ele du syst`eme g´en´eral de MongoDB et de AllegroGraph est mis en oeuvre Figure 2.1.
12


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