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

Ils nous permettront de chercher la meilleure solution possiblepour tout d’abord organiser le stockage des donn´ees massives et volumineuses dans un syst`eme de gestion de base donn´ees

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’HONNEURJ’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les données et les résultatsqui y sont présentés sont exacts et n’ont jamais été publiés ailleurs La source des informations citéesdans ce mémoire a été bien précisée.

LỜI CAM ĐOANTô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

Je tiens `a remercier dans un premier temps, toute l’´equipe p´edagogique de l’Institut FrancophoneInternational (IFI) de Hano¨ı et les intervenants professionnels responsable de la formation en master derecherche 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 etReponsbale de l’axe de donn´ees de l’Institut de Biologie Computationnelle, Mme Anne TIREAU qui esting´enieur `a l’INRA Montpellier SupAgro dans l’UMR MISTEA, pour leur encardrement sans faille, lesuivi qu’ils ont apport´e `a mon stage, leurs conseils, les nombreuses discussions que nous avons pu avoirtout au long de la r´ealisation de ce stage, aussi pour l’inspiration et pour le temps qui’ils ont bien voulu

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

R´ esum´ e

Depuis quelques ann´ees, le d´eluge de donn´ees dans plusieurs domaines de la recherche scientifiquesoul`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 recherches´emantique sur les donn´ees dans un contexte de recherche agronomique Ces approches s´emantiquespermettent 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 derequˆetes et d’autre part avec la mat´erialisation de donn´ees en triplets RDF Un ´etat de l’art nous apermis d’identifier et d’´evaluer les diff´erentes m´ethodes se rapportant aux approches mentionn´ees Enpratique, seule l’approche de mat´erialisation de donn´ees a ´et´e choisie pour continuer `a travailler Lesdonn´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 dechacun et de choisir le meilleur syst`eme pour notre ´etude de cas

Mot-cl´es : Base de connaissance, Ontologie, Raisonnement, Inf´erence, SPARQL, xR2RML, mark, NoSql, BigData, TripleStore

In the recent years, the data deluge in many areas of scientific research brings challenges in the ment and improvement of farm data Research in bioinformatics field does not outside this trend Thisthesis 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 userexperiments on the data obtained in this research by the engine automatic inference of new knowledge

treat-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 datatransformation 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 processingthe triplets because our current data are heterogeneous The data obtained for triplets are larger thatregular triplestore could manage So we evaluate some of them thus we can compare the benefits anddrawbacks of each and choose the best system for our problem

Keyworks : Knowledge base, Ontology, Reasoning, Inference, SPARQL, xR2RML, Benchmark, NoSQL,Big Data, Triplestore

Table des mati` eres

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

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

Liste d’abr´ eviations

API Application Programming Interface

CRUD Create, Read, Update, Delete

DFS Distributed files system

IBC Institut de Biologie Computationelle

INRA Institut National de la Recherche Agronomique

JSON Javascript Object Notation

JSON-LD JSON for Linking Data

ODBA Ontology-Based Data Access

OWL 2 RL Web Ontology Rule Language

R2RML Relational Databases to RDF Mapping Language

RDF Resource Description Framework

RDFS Resource Description Framework Schema

SPARQL Protocol and RDF Query Langage

xR2RML Relational and Non-Relational Databases to RDF Mapping Language

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

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

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

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 leclimat Aujourd’hui, de plus en plus de laboratoires ont effectu´e des ´etudes sur les plantes et ont obtenusdes r´esultats importants Les donn´ees de ces ´etudes sont des ressources utiles pour que les scientifiquespuissent les exploiter et les partager avec les autres Aujourd’hui, il y existe une diversit´e d’outils qui sontd´evelopp´es pour g´erer ces donn´ees Mais chaque ´etude poss`ede des caract´eristiques diff´erentes qui sontdifficiles `a capturer dans des applications g´en´eriques De plus, ces donn´ees ne cessent d’augmenter danschaque 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 entreces 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 webs´emantique et celui des donn´ees massives Ils nous permettront de chercher la meilleure solution possiblepour 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 deg´en´erer de nouvelles connaissances Les connaissances dans le domaine de web s´emantique fournissent desmod`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 laboratoiresIBC et INRA, leurs projets de recherche actuels, les probl´ematiques du stage et les concepts existantsdans le domaine du web s´emantique et des donn´ees massives La deuxi`eme partie fait un ´etat de l’artsur les solutions actuelles et leurs applications dans le cas de nos donn´ees La troisi`eme partie consiste `apr´esenter la solution propos´ee et les travaux mis en oeuvre pour la r´ealiser La quatri`eme partie pr´esente lessyst`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 : lechargement de donn´ees, la recherche de donn´ees et l’inf´erence de donn´ees

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 vantes et des logiciels pour analyser, int´egrer et contextualiser les donn´ees biologiques massives dans lesdomaines 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 (agentspathog`enes, le cancer, les cellules souches), l’agronomie (g´enomique des plantes, de l’agriculture tropicale),

inno-et de l’environnement (dynamique des populations, biodiversit´e) L’IBC est divis´e en cinq work-packagesqui 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 vers le projet “Investissements d’Avenir” L’IBC implique actuellement 56 chercheurs multidisciplinairespermanents, issus de quatorze laboratoires de Montpellier l’IBC a pour objectif de devenir un lieu derencontre privil´egi´e pour les chercheurs en biologie et en bio-informatique, mais aussi une importantecommunaut´e de chercheurs, universitaires et industriel au niveau r´egional, national et international Lesactivit´es de l’IBC amnitionnent de collaborer avec des chercheurs de renommee mondiale, d’organiser desmanifestations scientifiques, de former de jeunes chercheurs, et de promouvoir les r´esultats et ´echangerdes informations avec des partenaires industriels

tra-La recherche sur le riz est un des mod`eles d’´etude abord´e par les chercheurs de l’IBC notamment `atravers le projet BIOeSAI (Biological electronic System Assistant Index) Ce projet a pour objectif deg´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 comprendreles processus biologiques, par exemple : le d´eveloppement et la plasticit´e de la plante, la r´esistance auxmaladies Ces ´etudes requi`erent la manipulation d’un volume important de donn´ees h´et´erog`enes Cesdonn´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´eespar 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, ´equilibredans la gestion des territoires sont autant d’enjeux qui positionnent l’agronomie comme fondatrice d’und´eveloppement harmonieux sur les plans ´economique, social et environnemental

L’INRA produit des connaissances fondamentales et construit, grˆace `a elles, des innovations et dessavoir-faire pour la soci´et´e Il met son expertise au service de la d´ecision publique Les grandes missionsconfi´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 d´ebit de plantes cultiv´ees Son objectif est de mesurer des caract`eres agronomiques de plantes soumises `adiff´erents sc´enarios environnementaux et en particulier les conditions de stress hydrique C’est un projetsur huit ans regroupant neuf plates-formes r´eparties sur sept sites d’´etudes en France

haut-Les ´etudes couvrent `a la fois des probl´ematiques de recherche fondamentale en g´en´etique et de cherche appliqu´ee pour la s´election de plantes adapt´ees `a des contextes climatiques particuliers

re-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´eesgrˆ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

ˆ 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 environnementsnon 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 vironnement sur la plante Par cons´equent, pour l’ensemble des exp´erimentations r´ealis´ees, les donn´eesissues des capteurs environnementaux sont primordiales Ces donn´ees sont `a la fois h´et´erog`enes en termes

l’en-de formats, l’en-de s´emantique, etc et volumineuses (plusieurs t´eraoctets par mois) Elles sont de plus reli´eesentre 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 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´esultatsd’analyse et de calculs doivent ´egalement ˆetre reli´es aux donn´ees

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 sontconduites 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 ronnement sur les plantes La caract´eristique commune entre ces deux projets est la manipulation d’unimportant volume de donn´ees h´et´erog`enes Ces donn´ees sont organis´ees dans des syst`emes de gestion debase de donn´ees relationnelles ou des syst`emes de gestion de base de donn´ees NoSQL (MongoDB) Dans

l’envi-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 MongoDBincluant ´egalement la gestion des m´etadonn´ees et des tags Toutefois, la m´ethode mise en place ne permetpas 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 logies du Web S´emantique en s’appuyant sur les articles de synth`ese du domaine [2] Par ailleurs, nousr´ealiserons un ´etat de l’art sur les probl`emes d’organisation des donn´ees massives et de l’augmentation de

techno-la capacit´e de recherche sur les donn´ees Plus particuli`erement, sur la capacit´e d’inf´erence et de ment sur les donn´ees Un des objectifs du travail dans ce sujet sera de construire un base de connaissancesur les donn´ees existantes

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´ererces donn´ees[1] L’´emergence des syst`emes de gestion de base de donn´ees NoSQL orient´e-document (e.g

MongoDB) semble mieux adapt´e [3] toutefois ces systemes sont depourvus d’une capacit´e de recherches´emantique sur les donn´ees ce qui existent seulement sur les donn´ees RDF par utiliser par le languageSPARQL.

Les bases de donn´ees de type “triplestore” sont mieux adapt´ees pour faire des inf´erences ou desraisonnements sur les donn´ees Toutefois, elles passent moins bien `a l’´echelle sur des gros volumes dedonn´ees En effet, la recherche ou l’inf´erence sur un grand volume de donn´ees RDF peuvent prendrebeaucoup de temps L’enjeu dans la gestion de ce type de donn´ees est d’utiliser les capacit´es d’inf´erences´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 estl’objectif principal 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 gigantesquesqu’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 analyseetc Les prochains enjeux de ce si`ecle sont d’extraire du sens de ces masses d’information qui circulent surles r´eseaux Dans ce domaine, c’est avec la g´enomique et le ph´enotypage que la biologie est d´ej`a entr´eedans le monde des big data Certes, l’imagerie ou la mod´elisation m´etabolisme produisaient des donn´eesnum´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 legrand d´efi des big data en sciences de la vie : rattraper le foss´e grandissant entre production massive dedonn´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´eespour en tirer du sens Ces analyses sont appel´ees Big Analytics ou “broyage de donn´ees” Elles portentsur 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 endevient difficile de travailler avec des outils classiques des gestion de base de donn´ees ou de gestion del’information Les Big Data sont souvent d´efinis en utilisant l’acronyme 3V pour Volume, V´elocit´e etVari´et´e [4]

La volume se r´ef`ere `a des quantit´es massives de donn´ees qui sont disponibles, le volume des donn´eesstock´ees est en pleine expansion : les donn´ees num´eriques cr´e´ees dans le monde seraient pass´ees de 1,2zettaoctets par an en 2010 `a 1,8 zettaoctets en 2011, puis 2,8 zettaoctets en 2012 et s’´el`everont `a 40zettaoctets en 2020[5] `A titre d’exemple, Twitter g´en´erait en janvier 2013, 7 teraoctets de donn´eeschaque 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 utiliserles 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

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´eescomplexes provenant du web, au format texte et images Elles peuvent ˆetre publiques (Open Data, Webdes 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 libreservice sur des ressources informatiques partag´ees et configurables Les services les plus connus sontceux 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 Francedans 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 surune seule machine car la quantit´e `a stocker est beaucoup trop importante Les donn´ees, les fichierssont “d´ecoup´es” en morceaux d’une taille d´efinie et chaque morceau est envoy´e sur une machinebien pr´ecise utilisant du stockage local Le stockage local est pr´ef´er´e au stockage SAN (Storage AreaNetwork)/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 bienplus cher pour des performances bien moindres Dans les syst`emes de stockage distribu´e pour leBig Data, l’on introduit le principe de “Data locality” Les donn´ees sont sauvegard´ees l`a o`u ellespeuvent ˆ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 lesvolum´etries en jeu Ces technologies, dites de Business Analytics, Optimization permettent de g´erer desbases 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 frameworkHadoop 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´ecemmentMicrosoft Les acteurs du march´e s’appuient sur des syst`emes `a forte scalabilit´e horizontale et sur dessolutions 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 ˆetrer´esolu avec les syst`emes de gestion de base de donn´ees relationnelles Ces syst`emes deviennent lourds etlents sur ces types de donn´ees Ces derni`eres ann´ees, ont vu l’´emergence d’une diversit´e de syst`emes degestion de base de donn´ees que l’on appelle NoSQL Ces syst`emes NoSQL, proposent plusieurs modelespour organiser et stocker les donn´ees (la table 1.1)

Type de base de donn´ees 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, QizxOrient´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 cesdonn´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 tempsd’analyse des donn´ees, la capacit´e `a analyser l’ensemble des donn´ees et non seulement un ´echantillon decelles-ci ou la r´ecup´eration et la centralisation de nouvelles sources de donn´ees `a analyser afin d’identifierdes sources de valeur Alors, sur la base des caract´eristiques des donn´ees, on va d´ecider quel syst`eme degestion 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´esqui leur sont rattach´ees Ce mod`ele facilite la repr´esentation du monde r´eel, ce qui le rend adapt´e autraitement 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”,

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 longtempsvont enfin se concr´etiser ”[7] [8], le web s´emantique ´emerge comme la meilleure solution pour traiterdes donn´ees directes ou indirectes par des machines, partager et r´eutiliser des donn´ees entre plusieursapplications 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 allonsfocaliser sur les trois parties principales suivantes : Le repr´esentation de donn´ees en RDF, les requˆetesavec 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 traitementautomatique par des machines RDF donne une description par triplet <Sujet, Pr´edicat, Objet> Le sujetrepr´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 endiff´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 Undocument RDF ainsi form´e correspond `a un multi-graphe orient´e ´etiquet´e Ici, chaque triplet correspondalors `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, ets’appuient sur structure sous la forme de triplets En cela, il est diff´erent du classique SQL, mais s’eninspire clairement dans sa syntaxe et ses fonctionnalit´es Le SPARQL permet d’exprimer des requˆetesinterrogatives ou constructives : une requˆete SELECT, de type interrogative, permet d’extraire du grapheRDF un sous-graphe correspondant `a un ensemble de ressources v´erifiant les conditions d´efinies dans une

clause WHERE ; une requˆete CONSTRUCT, de type constructive, engendre un nouveau graphe quicompl`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 formations, que ce soit par les m´etadonn´ees d’un espace de noms, ou les ´el´ements d’un domaine deconnaissances L’ontologie constitue en soi un mod`ele de donn´ees repr´esentatif d’un ensemble de conceptsdans un domaine, ainsi que des relations entre ces concepts Elle est employ´ee pour raisonner `a propos desobjets du domaine concern´e Plus simplement, nous pouvons aussi dire que l’ “ontologie est aux donn´ees

d’in-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 desdonn´ees, ou la gestion des connaissances sur le web en g´en´eral Les Techniques `a base d’inf´erence sontaussi 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´eespour ˆetre consid´er´ees peuvent inclure la relation (HaiPhong isPartOf the North Vietnam) Une ontologiepeut d´eclarer que “The North of VietNam isPartof Vietnam” Cela signifie que d’un programme de Webs´emantique comprendre la notion de “X ispartOf Y” peut ajouter la d´eclaration “HaiPhong isPartOfVietnam” `a l’ensemble des relations, bien que cela ne faisait pas partie des donn´ees originales On peutdire 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 relationsentre les ressources “l’Inf´erence” signifie que les proc´edures automatiques peuvent g´en´erer de nouvellesrelations fond´ees sur les donn´ees et sur la base des informations suppl´ementaires sous la forme d’unvocabulaire, un ensemble de r`egles Que les nouvelles relations sont explicitement ajout´ees `a l’ensembledes 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 term´ediaire de vocabulaires ou ensembles de r`egles Ces deux approches font appel aux techniques derepr´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

l’in-individuelles peuvent ˆetre associes `a ces classes, et de caract´eriser les relations entre les classes et leurs tances D’autre part, les r`egles se concentrent sur la d´efinition d’un m´ecanisme g´en´eral sur la d´ecouverte

ins-et la g´en´eration de nouvelles relations fond´ees sur celles qui existent d´ej`a tout comme les programmeslogiques, tel Prolog Dans la famille du Web s´emantique li´e aux recommandations de World Wide WebConsortium (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, alorsque Rule Interchange Format (RIF) a ´et´e d´evelopp´e pour couvrir les approches bas´ees sur des r`egles

Chapitre 2

´

Etat de l’art

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´eessont acquises chaque jour, par exemple sur le plateau technique PhenoArch, environ 1600 plantes sontsuivies 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 `ades configuration et des r´esultats d’analyse d’image sous la forme de JSON Chaque document JSONest environ 40 champs Pour les g´erer, les informaticiens ont d´ej`a construits un syst`eme d’informationappel´e Phenotyping Hybrid Information System (PHIS)1 Les donn´ees permettant l’exploitation de laplateforme sont stock´ees dans une base de donn´ees relationnelles Avec les limitations de base de donn´eesrelationnelles, ces donn´ees doivent ˆetre migr´ees dans une base MongoDB pour am´eliorer le temps deperformance 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`emed’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 documentMongoDB

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 performancesup´erieure AllegroGraph est un framework de base de donn´ees et d’outils pour construire des applicationsWeb s´emantique Il peut stocker des donn´ees et des m´eta-donn´ees, il permet aussi d’interroger ces triplets `a

1 http ://lps-phis.supagro.inra.fr/phis/index.php

2 http ://vmbioesai-dev.ird.fr :8080/Syspherice

travers diff´erentes APIs comme SPARQL et Prolog De plus, il fourni des fonctionnalit´es de raisonnementRDFS++ avec son raisonneur int´egr´e AllegroGraph inclut ´egalement une librairie d’analyse de r´eseauxsociaux (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 estlimit´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 quepar 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 interfaceavec MongoDB, que l’on appelle MongoGraph Celle-ci permet d’offrir aux programmeurs MongoDB lescapacit´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ˆeteMongoDB 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, surlesquelles nous pouvons r´ealiser facilement des requˆetes SPARQL, et aussi effectuer des inf´erences sur cesdonn´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 neuses Le mod`ele du syst`eme g´en´eral de MongoDB et de AllegroGraph est mis en oeuvre Figure 2.1

volumi-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 RDFMapping Language (xR2RML) pour les convertir automatiquement On utilise les seulement les attributsimportants dans les documents D’ailleurs, une ontologie est utilis´ee pour l’organisation s´emantique destriplets cr´e´es Cette ontologie permet l’inf´erence en exploitant les relations entre les triplets Ainsi lemoteur d’inf´erence peut cr´eer de nouvelles relations sur la base de l’ontologie d´efinie.

(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 lesrequˆetes et l’inf´erence, nous avons pris un exemple sur les donn´ees existantes du projet BIOeSAI Ce projetcontient une ontologie sur les relations entre le lieu d’origine des plantes et les images exp´erimentales surles 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 peutvoir les d´etails des donn´ees JSON dans MongodDB, des donn´ees RDF qui ont ´et´e li´es aux documentsMongoDB et l’ontologie de r´ef´erences dans Figure 2.2

Nous pouvons faciliter l’importation des donn´ees RDF dans AllegroGraph en utilisant la forme d’und´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 der`egles d’inf´erence RDFS et l’autre supporte Web Ontology Rule Language (OWL 2 RL) Le premier estappel´e le raisonneur RDFS++ dynamique car il g´en`ere les triplets inf´er´es `a l’ex´ecution de l’inf´erence etn’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 tripletscourante Pour notre exemple, le second moteur d’inf´erence est choisi pour toutes les donn´ees Apr`esavoir ex´ecut´e, nous avons les nouveaux triplets sont stock´es de mani`ere p´erenne sur le disque comme lestriplets 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 graphe AllegroGraph a longtemps soutenu l’utilisation de “Magic Predicat” pour permettre les requˆetes

sous-en texte libre et pour interfacer Solr et MongoDB Dans la requˆete Figure 2.3, le syst`eme va effectuerdeux requˆetes dans deux syst`emes diff´erents pour obtenir les r´esultats Les requˆetes seront ex´ecut´ees dansMongoDB pour trouver les r´esultats sous le format de JSON, et les r´esultats finaux (les triplets) seronttrouv´es dans AllegroGraph

Figure 2.3: Une requˆete SPARQL associ´ee `a une requˆete de MongoDBAvantages

ˆ 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

ˆ Pas de synchronisation entre les deux, quand nous mettons `a jour au MongoDB, nous devons lefaire 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 lesdonn´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´eesstock´ees dans la base assurant un parall´elisme direct avec les donn´ees elles-mˆemes En d’autres termes, `amesure 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 tives, car elle en ´evite de coˆuteuses jointures Structured Query Language (SQL) Les requˆetes peuventg´erer de ce fait plus facilement un large ensemble de donn´ees Les parcours utilisent un langage simple

associa-de parcours associa-des connections L’absence associa-de mod´elisation rigide, rend Neo4j bien adapt´e `a la gestion dedonn´ees changeantes et de sch´emas ´evoluant fr´equemment

Les caract´eristiques typiques de donn´ees pour Neo4j sont la structuration des donn´ees optionnellesqui sont peuvent absenter, une facilit´e de changement du sch´ema et des migrations de donn´ees sanscontraintes, la mod´elisation facile de jeux de donn´ees de domaines complexes et cas d’utilisation typiquedans des domaines tels que le Web s´emantique et RDF, le Web de donn´ees, l’analyse du g´enome, lamod´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 legraphe via un m´eta-mod`ele, obtenir une impl´ementation de RDF TripleStore compatible SPARQL Parexemple, avec deux plugins Neo-rdf-sail3et 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”

3 https ://github.com/neo4j-contrib/neo4j-rdf-sail

4 https ://github.com/niclashoyer/neo4j-sparql-extension

Figure 2.4 D’ailleurs, le langage de requˆete Cypher est utilis´e pour manipuler les donn´ees C’est unlangage 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 approchepermet l’optimisation des requˆetes

Figure 2.5: Les commandes pour cr´eer un graphe simpleAvantages

ˆ Gestion de base de donn´ees pour le Big Data sous la forme de graphes, donc amelioration de laperformance 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´eesdans 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 enfonction 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 lierdes 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 Webdes donn´ees les ´etend pour partager ´egalement l’information entre machines Cela permet d’interrogerautomatiquement 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 utilisationpermet `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 desdonn´ees li´ees dans les moteurs de stockage `a base de JSON Actuellement, JSON-LD est compatible avecJSON, 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

ˆ 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 unautre 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´eesavec 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 nologies de donn´ees li´ees comme SPARQL Les projets qui ont besoin de traiter les donn´ees comme desgraphes RDF vont trouver une solution avec la forme de JSON-LD En d´etail, le document JSON-LD est

tech-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´eesRDF Cependant, JSON-LD ´etend le mod`ele de donn´ees RDF pour s´erialiser des ensembles de donn´eesRDF

Figure 2.7: Le mod`ele de composantsdans 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,

le base de donn´ees orient´ee documents et la base de triplets dans m´emoire temporelle Ici, les op´erationsCRUD vont s’ex´ecuter dans MongoDB et les recherches sont r´ealis´ees dans le graphe RDF Alors, unecouche 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´eesRDF Nous pouvons donc profiter de la puissance de MongoDB dans le traitement de probl`eme dedonn´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 coup de temps Les mises `a jour sur les donn´ees de graphes RDFs sont d´ependantes de la base dedonn´ees dans MongoDB

beau-ˆ Le probl`eme de m´emoire temporelle avec les grands graphes RDFs, la puissance mat´erielle estimportante 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 coucheconceptuelle est exprim´ee sous la forme d’une ontologie qui d´efinit un sch´ema global de haut niveau etfournit des vocabulaires pour des requˆetes d’utilisateurs Les donn´ees sont stock´ees dans des bases dedonn´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 mappingsqui 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 MappingLanguage (R2RML)5 de l’organisation W3C Cette graphe virtuelle peut ˆetre interrog´ee `a l’aide d’unlangage 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

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 duprocessus 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 dedonn´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 ontd´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 dedonn´ees relationnelles) Ontop est capable de g´en´erer efficacement et de mani`ere optimis´e des requˆetesSQL [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 derequˆ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

Figure 2.9: La comparaison des approches des raisonnements dans une application

5 http ://www.w3.org/TR/r2rml/

6 http ://optique-project.eu/

L’approche classique converti les bases de donn´ees en triplets Ensuite, les requˆetes, les inf´erencesseront r´ealis´ees sur ces donn´ees Avec l’approche de QUEST, un nouveau paradigme sur les donn´ees estcr´e´e, ici, les structures de base de donn´ees ne sont pas bris´ees Les donn´ees sont stock´ees dans un seulsyst`eme.

Figure 2.10: L’architecture du syst`eme avec l’association de MongoDB et le

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 deduplication 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 relationnellesInconv´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 degestion de base de donn´ees orient´es graphe Neo4j ou des syst`emes bases de donn´ees orient´es documentsMongoDB ou des syst`emes hybrides d’association de MongoDB et des syst`emes de gestion de base dedonn´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 approcheest 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 connaissancescomme RDF il existe d´ej`a une base de donn´ees Pour que l’on puisse utiliser les donn´ees en RDF, il faut

les traduire en triplets Il existe plusieurs m´ethodes mais la plus utilis´ee est la suivante : Database ToRDF (D2R)7 a pour but de traduire toutes les donn´ees contenues dans une base de donn´ees en tripletsRDF D2R fonctionne avec un fichier de mapping et une ou plusieurs ontologies Le fichier de mappingsert `a faire la liaison entre les tables et les champs contenus dans ces tables et les classes et les propri´et´esdont 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 parl’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

7 http ://d2rq.org/

8 http ://www.w3.org/TR/r2rml/

9 http ://www.w3.org/TR/rdb-direct-mapping/

sont bas´es sur le langage de mapping R2RML et Morph-RDB qui est une impl´ementation du langage

de mapping R2RML pour les donn´ees relationnelles, pour d´evelopper xR2RML qui est s’applique auxbases de donn´ees orient´ees documents comme MongoDB

En particulier, xR2RML est une extension de la langage de mapping R2RML et s’appuie sur certainespropri´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 desdonn´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 dedonn´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

10 https ://github.com/oeg-upm/morph-rdb

Dans ce chapitre, nous aborderons dans la premi`ere section le choix de la repr´esentation du mod`eledonn´ees et la mani`ere de le g´en´erer Ensuite, dans la section suivante sera abord´ee une d´emarche entreprisepour transformer des donn´ees du mod`ele relationnel aux format JSON De plus, une ontologie serapr´esent´ee pour d´ecrire les vocabulaires n´ecessaires dans la la conception du modele RDFs En fin, lelangage de transformation de donn´ees en RDF sera introduit avec les syntaxes pour cr´eer les mapping etconvertir 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 laperformance des triplestores sur de gros volume donn´ees Les syst`emes actuels stockant de gros volumessont 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 leurprovenance 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 mappingxR2RML et l’outil d´evelopp´e par les auteurs [14] Les vocabulaires et les r`egles de transformation detriplets sont fournis par une ontologie Cette ontologie est importante pour r´ealiser des recherches avanc´eessur 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 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`emesavec des donn´ees volumineuses Ainsi, r´ealiserons les tests de ces syst`emes sur la capacit´e de gestion de

focali-donn´ees RDF afin d’optimiser le stockage et pour la r´ecup´eration de ces triplets `a l’aide du langage derequˆete SPARQL.

Le moteur de recherche va consister `a utiliser la capacit´e d’inf´erence sur la base contenant l’ontologie etles donn´ees RDF Une interface est fournie pour effectuer les requˆetes sur ces donn´ees Les interrogationssous la forme de langage SPARQL sont utilis´ees pour chercher les donn´ees n´ecessaires dans la base dedonn´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

Mon-goDB

Dans le projet Phenome (INRA), plusieurs syst`emes de capteurs alimentent des bases de donn´eesrelationnelles en permanence Il y a une fort besoin de synchronisation de ces donn´ees avec le syst`emecourant L’´etape de transformation de donn´ees en documents JSON est r´ealis´ees afin d’int´egrer plusieursressources dans un meme entrepˆot Dans la suite du memoire nous nous concentrons seulement sur lesdonn´ees obtenues dans sur les processus d’imageries, d’arrosage, de pes´ees ceux que les chercheur ontr´ealis´es quotidiennement

Afin de garantir la coh´erence des donn´ees entre les ressources et les processus qui les g´en`erent, desmod`eles ont ´et´e d´efinis La d´efinition des mod`eles JSON est r´ealis´ee pour mapper les propri´et´es deplusieurs tables de base de donn´ees relationnelles avec les cl´es - valeurs dans les documents JSON Seulesles 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 tablesdiff´erentes : Images, Imgacqcameraprofiles et Imagacstationprofiles Ces tables correspondent comme leurnom 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 documentJSON sont repr´esent´es des donn´ees fix´ees par les syst`emes existants et des nouvelles donn´ees calcul´ees a

partir de traitements resultant de leur int´egration.

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 convertirautomatique toutes les donn´ees dans la base de donn´ees relationnelles aux document de JSON sur labase d’un mod`ele d´efini comme la figure 3.2 Les donn´ees, qui seront concern´ees par les processus demesures 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’AnnexeA

Aujourd’hui, toutes les donn´ees obtenues apr`es la transformation seront synchronis´ees et stock´eesdans 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

1 https ://github.com/lengocluyen/phenowaredb-to-mongodb-convertor

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 devocabulaires pour les d´ecrire Dans cette section, nous nous focalisons sur des vocabulaires de descriptiondes 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´ecessairepour 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] parexemple, EXIF2 est le format d’images de la plupart des appareils photo num´eriques Il contient des

2 https ://fr.wikipedia.org/wiki/Exchangeable imag file format