UNIVERSITÉ NATIONALE DU VIETNAM À HANO¨I
INSTITUT FRANCOPHONE INTERNATIONAL
UNIVERSITÉ DE LA ROCHELLE
Mémoire de fin d’étu...
Remerciements
Je tiens `a remercier dans un premier temps, toute l’´equipe p´edagogique de l’Institut Francophone
Internat...
R´esum´e
Depuis quelques ann´ees, le d´eluge de donn´ees dans plusieurs domaines de la recherche scientifique
soul`eve des ...
Abstract
In the recent years, the data deluge in many areas of scientific research brings challenges in the treat-
ment and...
Table des mati`eres
Remerciements i
R´esum´e ii
Abstract iii
Table des mati`eres iv
Liste d’abr´eviations vi
Table des figu...
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Mod`ele g´...
Liste d’abr´eviations
API Application Programming Interface
CRUD Create, Read, Update, Delete
D2R Database To RDF
DFS Dist...
Liste des figures
1.1 L’architecture du web s´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1...
5.1 La comparaison du temps de chargement sur diff´erents TripleStores . . . . . . . . . . . . . 43
5.2 L’exemple de requˆe...
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 L...
Introduction
Les ´etudes sur les plantes ont toujours pris un rˆole important pour am´eliorer la productivit´e, la capacit...
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’Institu...
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 BI...
ˆ Ph´enoDyn o`u l’on mesure en particulier la transpiration et la croissance des feuilles des plantes.
D’autres plate-form...
MongoDB) semble mieux adapt´e [3] toutefois ces systemes sont depourvus d’une capacit´e de recherche
s´emantique sur les d...
de donn´ees relationnelles traditionnelles, ces donn´ees sont brutes, semi-structur´ees voire non structur´ees
(cependant,...
Type de base de donn´ees1
Liste des syst`emes utilis´es
Cl´e - valeur CouchDB, Oracle NoSQL Database, Dynamo, FoundationDB...
qui devrait rendre cela possible, n’a pas encore ´emerg´e, mais quand ce jour sera atteint, les m´ecanismes
de dialogue en...
clause WHERE ; une requˆete CONSTRUCT, de type constructive, engendre un nouveau graphe qui
compl`ete le graphe interrog´e...
individuelles peuvent ˆetre associes `a ces classes, et de caract´eriser les relations entre les classes et leurs ins-
tan...
Chapitre 2
´Etat de l’art
2.1 Existants
Depuis plusieurs ann´ees des ´etudes en ph´enotypage haut-d´ebit des plantes sont ...
travers diff´erentes APIs comme SPARQL et Prolog. De plus, il fourni des fonctionnalit´es de raisonnement
RDFS++ avec son r...
Ici, les donn´ees d’origines restent stock´ees dans MongoDB sous le format documents dans des collections.
Les nouveaux tr...
Nous pouvons faciliter l’importation des donn´ees RDF dans AllegroGraph en utilisant la forme d’un
d´epˆot, “Repository”. ...
ˆ Pas de synchronisation entre les deux, quand nous mettons `a jour au MongoDB, nous devons le
faire aussi sur Allegograph...
Figure 2.4. D’ailleurs, le langage de requˆete Cypher est utilis´e pour manipuler les donn´ees. C’est un
langage d´eclarat...
ˆ 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 contex...
le base de donn´ees orient´ee documents et la base de triplets dans m´emoire temporelle. Ici, les op´erations
CRUD vont s’...
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ˆet...
L’approche classique converti les bases de donn´ees en triplets. Ensuite, les requˆetes, les inf´erences
seront r´ealis´ee...
les traduire en triplets. Il existe plusieurs m´ethodes mais la plus utilis´ee est la suivante : Database To
RDF (D2R)7
a ...
sont bas´es sur le langage de mapping R2RML et Morph-RDB10
qui est une impl´ementation du langage
de mapping R2RML pour le...
Chapitre 3
Solution propos´ee
3.1 Introduction
La partie pr´ec´edente donne une vue g´en´erale de diff´erentes solutions po...
donn´ees RDF afin d’optimiser le stockage et pour la r´ecup´eration de ces triplets `a l’aide du langage de
requˆete SPARQL...
partir de traitements resultant de leur int´egration.
1 Image{
2 "plant" : URI,
3 "plantAlias" : string,
4 "genotype" : UR...
3.4 Ontologies et domaine applicatif
Figure 3.3: L’ontologie de l’annotation d’images
Les diff´erences entre des processus ...
m´eta-donn´ees pour la date, l’heure, la localisation etc . Dublin Core3
fournit des vocabulaire de taille
r´eduite pour l...
1 <http:// example.org/study#10> st:involves
2 [ a rdf:Seq;
3 rdf:_1 "Hopital Lapeyronie ";
4 rdf:_2 " Pontchaillou ";
5 ]...
fournis par l’ontologies ci-dessus. Dans la figure 3.7, les propri´et´es du document JSON d’images (les autres
sont d´efinis...
3.6 Conclusion
Dans cette partie, la d´efinition du mod`ele de solution propos´ee est pr´esent´ee avec les ´etapes que
nous...
Chapitre 4
Stockage et Indexation de donn´ees
RDF
4.1 Introduction
Avec les donn´ees obtenues dans la chapitre pr´ec´edent...
dans le syst`eme. Alors, la solution de stockage des donn´ees en m´emoire est `a consid´erer pour ´eviter ce
ph´enom`ene. ...
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
thesis
Prochain SlideShare
Chargement dans…5
×

thesis

159 vues

Publié le

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
159
Sur SlideShare
0
Issues des intégrations
0
Intégrations
8
Actions
Partages
0
Téléchargements
7
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

thesis

  1. 1. UNIVERSITÉ NATIONALE DU VIETNAM À HANO¨I INSTITUT FRANCOPHONE INTERNATIONAL UNIVERSITÉ DE LA ROCHELLE Mémoire de fin d’études MASTER DE RECHERCHE EN INFORMATIQUE OPTION : SYSTÈMES INTELLIGENTS ET MULTIMÉDIA DÉVELOPPEMENT D’UN SYSTÈME CONNAISANCES POUR BIG DATA APPLICATION AUX DONNÉES DE PHÉNOTYPAGE CHEZ LE RIZ (O. SATIVA) Rédigé par : LE Ngoc Luyen Promotion: XVIII Sous l’encadrement de: Dr Pierre LARMANDE, Ingénieur IRD, Responsable de l’axe intégration de données de l’IBC Anne TIREAU, Ingénieur INRA à Montpellier SupAgro Montpellier, septembre 2015
  2. 2. Remerciements Je tiens `a remercier dans un premier temps, toute l’´equipe p´edagogique de l’Institut Francophone International (IFI) de Hano¨ı et les intervenants professionnels responsable de la formation en master de recherche en informatique, pour avoir assur´e la partie th´eorique de celle-ci. Je tiens `a exprimer toute ma reconnaissance `a M. Pierre LARMANDE qui est chercheur `a l’IRD et Reponsbale de l’axe de donn´ees de l’Institut de Biologie Computationnelle, Mme. Anne TIREAU qui est ing´enieur `a l’INRA Montpellier SupAgro dans l’UMR MISTEA, pour leur encardrement sans faille, le suivi qu’ils ont apport´e `a mon stage, leurs conseils, les nombreuses discussions que nous avons pu avoir tout au long de la r´ealisation de ce stage, aussi pour l’inspiration et pour le temps qui’ils ont bien voulu me consacrer. Je souhaite remercie la famille de Pierre LARMANDE et la famille Fran¸cois PHAN pour leurs aides chaleureuses pendant mon s´ejour de six mois en France. Je tiens `a remercie ´egalement Mlle Caroline BENOIST secr´etaire du LIRMM, et Mlle NGUYEN Thi Van Tu, secr´etaire de l’IFI pour ses aides `a plusieurs reprises. Depuis mes premiers jours dans cet institut, j’ai re¸cu beaucoup d’aides, de conseils et d’encourage- ments de mes amis, en particulier ceux de la promotion 18. Tout cela m’a permis de murir chaque jour. Je les remercie et je ne pourrais jamais oublier les souvenirs gais et tristes que j’ai pass´e avec eux durant ces deux ans `a l’IFI. Je voudrais aussi remercier aussi les confr`eres de l’Universit´e de Da Lat o`u je suis en train de travailler, qui m’ont donn´e les meilleures conditions pour que je puisse bien passer ma scolarit´e `a l’IFI. Enfin, j’adresse mes plus sinc`eres remerciements `a mes parents, mes fr`eres qui m’a toujours soutenue et encourag´ee dans les moments les plus difficiles de ma scolarit´e `a l’IFI. Merci `a tous et `a toutes LE Ngoc Luyen Da Lat - Viet Nam, automne 2015 i
  3. 3. R´esum´e Depuis quelques ann´ees, le d´eluge de donn´ees dans plusieurs domaines de la recherche scientifique soul`eve des d´efis dans le traitement et l’exploitation des donn´ees. La recherche dans le domaine bioinforma- tique n’est pas ´epargn´ee par ce ph´enom`ene. Ce m´emoire pr´esente des approches pour r´esoudre le probl`eme de donn´ees volumineuses stock´ees dans des entrepˆots NoSQL en y associant la capacit´e de recherche s´emantique sur les donn´ees dans un contexte de recherche agronomique. Ces approches s´emantiques permettent d’aider `a enrichir les donn´ees issues d’exp´eriences grˆace aux moteurs d’inf´erence g´en´erant de nouvelles connaissances. Nous pouvons r´esumer ces deux approches d’une part avec la r´e´ecriture de requˆetes et d’autre part avec la mat´erialisation de donn´ees en triplets RDF. Un ´etat de l’art nous a permis d’identifier et d’´evaluer les diff´erentes m´ethodes se rapportant aux approches mentionn´ees. En pratique, seule l’approche de mat´erialisation de donn´ees a ´et´e choisie pour continuer `a travailler. Les donn´ees triplets obtenues ´etant volumineuses, nous avons r´ealis´e un benchmark sur diff´erents syst`emes de gestion de base de donn´ees de triplets afin de pouvoir comparer les avantages et les inconv´enients de chacun et de choisir le meilleur syst`eme pour notre ´etude de cas. Mot-cl´es : Base de connaissance, Ontologie, Raisonnement, Inf´erence, SPARQL, xR2RML, Bench- mark, NoSql, BigData, TripleStore ii
  4. 4. Abstract In the recent years, the data deluge in many areas of scientific research brings challenges in the treat- ment and improvement of farm data. Research in bioinformatics field does not outside this trend. This thesis presents some approaches aiming to solve the big Data problem by combining the increase in se- mantic search capacity on existing data in the plant research laboratories. This helps us to strengthen user experiments on the data obtained in this research by the engine automatic inference of new knowledge. To achieve this, each approach has different characteristics and using different platforms. Nevertheless, we can summarize it in two main directions : the transformation of query or Re-write requests and data transformation to triples. In reality, we can solve the problem from origin of increasing capacity on seman- tic data with triplets. Thus, the triplets to data transformation direction is chosen to continue working in the practical part. However, the synchronization data in the same format is required before processing the triplets because our current data are heterogeneous. The data obtained for triplets are larger that regular triplestore could manage. So we evaluate some of them thus we can compare the benefits and drawbacks of each and choose the best system for our problem. Keyworks : Knowledge base, Ontology, Reasoning, Inference, SPARQL, xR2RML, Benchmark, NoSQL, Big Data, Triplestore iii
  5. 5. Table des mati`eres Remerciements i R´esum´e ii Abstract iii Table des mati`eres iv Liste d’abr´eviations vi Table des figures vii Liste des tableaux ix INTRODUCTION 1 Chapitre 1 Pr´esentation G´en´erale 2 1.1 Pr´esentation de l’´etablissement d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Pr´esentation de l’Institut de Biologie Computationelle (IBC) . . . . . . . . . . . . 2 1.1.2 Pr´esentation de l’Institut National de la Recherche Agronomique (INRA) . . . . . 3 1.2 Description du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Probl´ematiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Contexte du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1 Contexte de donn´ees massives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.2 Contexte de recherche s´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Chapitre 2 ´Etat de l’art 11 2.1 Existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Analyse et ´evaluation des solutions courantes . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 MongoGraph - une association du Mongodb et AllegroGraph . . . . . . . . . . . . 11 2.2.2 Base de donn´ees orient´ee graphe Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.3 JSON for Linking Data (JSON-LD) et MongoDB . . . . . . . . . . . . . . . . . . . 16 2.2.4 Ontology-Based Data Access (ODBA) et frameworks Ontop . . . . . . . . . . . . . 18 2.2.5 Mat´erialisation de donn´ees en triplets RDF . . . . . . . . . . . . . . . . . . . . . . 20 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Chapitre 3 Solution propos´ee 23 iv
  6. 6. 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 Mod`ele g´en´eral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3 Transformation et synchronisation de donn´ees dans MongoDB . . . . . . . . . . . . . . . . 24 3.4 Ontologies et domaine applicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5 xR2RML et Transformation de donn´ees en triplets . . . . . . . . . . . . . . . . . . . . . . 27 3.5.1 Le langage de mapping de donn´ees xR2RML . . . . . . . . . . . . . . . . . . . . . 27 3.5.2 Transformation de donn´ees en triplets . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Chapitre 4 Stockage et Indexation de donn´ees RDF 31 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Approche native et non-native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 Vue g´en´erale des syst`emes de gestion de triplets . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1 TripleStore Sesame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.2 TripleStore 4Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3.3 TripleStore Virtuoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.4 TripleStore Jena Fuseki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3.5 TripleStore Stardog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.6 TripleStore GraphDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4 Impl´ementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Chapitre 5 Exp´erimentation, Comparaison et Analyse 42 5.1 Pr´eparation des donn´ees et du Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2 Benchmarking des platformes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.1 Chargement de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.2 Recherche de donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.3 Inf´erence sur les donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3 Evaluation et Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 CONCLUSION 53 R´EF´ERENCES 55 Annexe A Mod`ele de document JSON A.1 Annexe B Mappage de donn´ees JSON aux triplets par xR2RML B.5 Annexe C Point d’acc`es C.8
  7. 7. Liste d’abr´eviations API Application Programming Interface CRUD Create, Read, Update, Delete D2R Database To RDF DFS Distributed files system DL Logiques de Description IBC Institut de Biologie Computationelle INRA Institut National de la Recherche Agronomique JSON Javascript Object Notation JSON-LD JSON for Linking Data NoSQL Not Only SQL ODBA Ontology-Based Data Access OWL Web Ontology Language OWL 2 RL Web Ontology Rule Language R2RML Relational Databases to RDF Mapping Language RDF Resource Description Framework RDFS Resource Description Framework Schema RML RDF Mapping Language SPARQL Protocol and RDF Query Langage SQL Structured Query Language W3C World Wide Web Consortium xR2RML Relational and Non-Relational Databases to RDF Mapping Language vi
  8. 8. Liste des figures 1.1 L’architecture du web s´emantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 L’exemple d’un triplet Resource Description Framework (RDF). . . . . . . . . . . . . . . . 8 1.3 L’exemple d’une requˆete Protocol and RDF Query Langage (SPARQL). . . . . . . . . . . 8 2.1 Le mod`ele de composants dans un syst`eme MongoGraph . . . . . . . . . . . . . . . . . . . 12 2.2 Les donn´ees pr´esent´ees dans cet exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Une requˆete SPARQL associ´ee `a une requˆete de MongoDB . . . . . . . . . . . . . . . . . . 14 2.4 La graphe de donn´ees dans Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5 Les commandes pour cr´eer un graphe simple . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.6 Les triplets sont stock´ees dans MongoDB sous la forme de JSON-LD . . . . . . . . . . . . 17 2.7 Le mod`ele de composants dans un syst`eme d’association de MongoDB et JSON-LD – Create, Read, Update, Delete (CRUD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.8 Le processus de requˆete dans le syst`eme d’ODBA . . . . . . . . . . . . . . . . . . . . . . . 19 2.9 La comparaison des approches des raisonnements dans une application . . . . . . . . . . . 19 2.10 L’architecture du syst`eme avec l’association de MongoDB et le mod`ele d’ODBA . . . . . . 20 2.11 Les deux tables et sa relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.12 Les informations d´efinies pour le mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.13 Les donn´ees RDF apr`es de la transformation . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1 Le mod`ele g´en´eral du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 Le mod`ele JSON cr´e´e `a partir des bases d’imageries . . . . . . . . . . . . . . . . . . . . . 25 3.3 L’ontologie de l’annotation d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Un exemple de donn´ees dans MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.5 Le triplet g´en´er´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6 Le mapping de xR2RML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7 Le Mapping de donn´ees JSON en triplets . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1 La classificaiton des types de syst`eme de stockage RDF . . . . . . . . . . . . . . . . . . . 32 4.2 Les composants dans l’architecture de Sesame . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3 L’architecture principale de 4Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4 L’architecture g´en´erale de Virtuoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.5 Les composants dans l’architecture de Jena . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.6 Les composants dans l’architecture de GraphDB . . . . . . . . . . . . . . . . . . . . . . . 38 4.7 L’interface du syst`eme d’interaction avec les donn´ees RDF . . . . . . . . . . . . . . . . . . 39 vii
  9. 9. 5.1 La comparaison du temps de chargement sur diff´erents TripleStores . . . . . . . . . . . . . 43 5.2 L’exemple de requˆete num´ero 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.3 L’evaluation de la requˆete num´ero 1 sous forme de courbe graphique . . . . . . . . . . . . 44 5.4 L’exemple de requˆetes num´ero 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.5 L’evaluation de la requˆete num´ero 2 sous forme de courbe graphique . . . . . . . . . . . . 45 5.6 L’exemple de requˆete num´ero 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.7 L’evaluation de la requˆete num´ero 3 sous forme de courbe graphique . . . . . . . . . . . . 46 5.8 L’exemple de troisi`eme requˆetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.9 L’evaluation de la requˆete num´ero 4 sous forme de courbe graphique . . . . . . . . . . . . 47 5.10 Les relations inf´er´ees sur l’ontologie dans le premier exemple . . . . . . . . . . . . . . . . . 48 5.11 La requˆete du premi`ere exemple d’inf´erence . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.12 Le temps d’ex´ecution de la premi`ere inf´erence sous forme de graphique . . . . . . . . . . . 49 5.13 Les relations inf´er´ees sur l’ontologie dans le deuxi`eme exemple d’inf´erence . . . . . . . . . 49 5.14 L’exemple de la deuxi`eme inf´erence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.15 Le temps d’ex´ecution de la deuxi`eme inf´erence sous forme de graphique . . . . . . . . . . 50
  10. 10. Liste des tableaux 1.1 La liste des types et des syst`eme de gestion de base de donn´ees dans Not Only SQL (NoSQL) 7 4.1 Les TripleStores et le type de stockage support´e . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Les encodages sp´eciaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3 Les comparaison de certaines fonctionnalit´es des diff´erents TripleStores . . . . . . . . . . . 40 5.1 La configuration du serveur exp´erimental . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2 La comparaison du temps de chargement sur diff´erents TripleStores en millisecondes . . . 43 5.3 L’evaluation de la requˆete num´ero 1 (temps en millisecondes) . . . . . . . . . . . . . . . . 44 5.4 L’evaluation de la requˆete num´ero 2 (temps en millisecondes) . . . . . . . . . . . . . . . . 45 5.5 L’evaluation de la requˆete num´ero 3 (temps en millisecondes) . . . . . . . . . . . . . . . . 46 5.6 L’evaluation de la requˆete num´ero 4 (temps en millisecondes) . . . . . . . . . . . . . . . . 47 5.7 L’evaluation de la premi`ere inf´erence (temps en millisecondes) . . . . . . . . . . . . . . . 49 5.8 L’evaluation de la deuxi`eme inf´erence (temps en millisecondes) . . . . . . . . . . . . . . . 50 C.1 Les exemples de point d’acc`es de TripleStore . . . . . . . . . . . . . . . . . . . . . . . . . C.8 ix
  11. 11. Introduction Les ´etudes sur les plantes ont toujours pris un rˆole important pour am´eliorer la productivit´e, la capacit´e de r´esistance des plantes aux maladies, la r´eduction d’influence des changements de l’environnement et le climat. Aujourd’hui, de plus en plus de laboratoires ont effectu´e des ´etudes sur les plantes et ont obtenus des r´esultats importants. Les donn´ees de ces ´etudes sont des ressources utiles pour que les scientifiques puissent les exploiter et les partager avec les autres. Aujourd’hui, il y existe une diversit´e d’outils qui sont d´evelopp´es pour g´erer ces donn´ees. Mais chaque ´etude poss`ede des caract´eristiques diff´erentes qui sont difficiles `a capturer dans des applications g´en´eriques. De plus, ces donn´ees ne cessent d’augmenter dans chaque jour. Les tˆaches de gestion de donn´ees demandent des m´ethodes d’organisation optimis´ees. Dans la carde du sujet de stage, deux projets d’´etudes sur les plantes sont r´ealis´es dans deux labora- toires differents. L’un fait la recherche sur le ph´enotypage et le g´enotypage du riz asiatique. L’autre fait la recherche sur le ph´enotypage et le g´enotypage du ma¨ıs en France. La caract´eristique commune entre ces deux projets concerne la gestion et l’exploitation de gros volumes de donn´ees de mani`ere plus efficace. Les travaux dans ce stage se focaliseront sur la recherche de solutions associant les domaines du web s´emantique et celui des donn´ees massives. Ils nous permettront de chercher la meilleure solution possible pour tout d’abord organiser le stockage des donn´ees massives et volumineuses dans un syst`eme de gestion de base donn´ees sp´ecialis´e et ensuite renforcer la capacit´e de recherche s´emantique des donn´ees afin de g´en´erer de nouvelles connaissances. Les connaissances dans le domaine de web s´emantique fournissent des mod`eles pour structurer les donn´ees sous la forme de bases de reconnaissance et permettent la recherche de donn´ees grˆace a des m´ecanismes de d’inf´erence et de raisonnement. Aujourd’hui, le probl`eme de gestion de donn´ees massives a besoin de traiter avec l’optimisation du temps d’ex´ecution et le temps de recherche. Ce pr´esent rapport se divise en cinq grandes parties. La premi`ere partie pr´esente les deux laboratoires IBC et INRA, leurs projets de recherche actuels, les probl´ematiques du stage et les concepts existants dans le domaine du web s´emantique et des donn´ees massives. La deuxi`eme partie fait un ´etat de l’art sur les solutions actuelles et leurs applications dans le cas de nos donn´ees. La troisi`eme partie consiste `a pr´esenter la solution propos´ee et les travaux mis en oeuvre pour la r´ealiser. La quatri`eme partie pr´esente les syst`emes de gestion de base de donn´ees de triplets actuels. La cinqui`eme partie concerne l’exp´erimentation, la comparaison et l’analyse des r´esultats dans un benchmark de ces syst`emes selon trois crit`eres : le chargement de donn´ees, la recherche de donn´ees et l’inf´erence de donn´ees. 1
  12. 12. Chapitre 1 Pr´esentation G´en´erale 1.1 Pr´esentation de l’´etablissement d’accueil 1.1.1 Pr´esentation de l’IBC L’Institut de Biologie Computationnelle a ´et´e cr´e´ee dans le but de d´evelopper des m´ethodes inno- vantes et des logiciels pour analyser, int´egrer et contextualiser les donn´ees biologiques massives dans les domaines de la sant´e, de l’agronomie et de l’environnement. Plusieurs branches de recherche y sont com- bin´ees : l’algorithmique (combinatoire, num´erique, massivement parall`ele, stochastique), la mod´elisation (discr`ete, qualitative, quantitative, probabiliste), et la gestion des donn´ees (int´egration, workflows, cloud). Les concepts et les outils seront valid´es `a l’aide des applications cl´es en biologie fondamentale (transcrip- tomique, la structure et la fonction des prot´eines, le d´eveloppement et la morphogen`ese), la sant´e (agents pathog`enes, le cancer, les cellules souches), l’agronomie (g´enomique des plantes, de l’agriculture tropicale), et de l’environnement (dynamique des populations, biodiversit´e). L’IBC est divis´e en cinq work-packages qui comprennent les aspects principaux du traitement des donn´ees biologiques massives : ˆ WP1-HTS : M´ethodes d’analyse de s´equen¸cage `a haut d´ebit ˆ WP2-Evolution : Passage `a l’´echelle des analyses ´evolutives ˆ WP3-Annotation :Annotation fonctionnelle et structurelle des prot´eomes ˆ WP4-Imaging : Int´egration de l’imagerie cellulaire et tissulaire avec des donn´ees omiques ˆ WP5-Databases : Donn´ees biologiques et int´egration des connaissances L’IBC est un projet multidisciplinaire soutenu pendant cinq ans (2012-2017) par l’´etat Fran¸cais `a tra- vers le projet “Investissements d’Avenir”. L’IBC implique actuellement 56 chercheurs multidisciplinaires permanents, issus de quatorze laboratoires de Montpellier. l’IBC a pour objectif de devenir un lieu de rencontre privil´egi´e pour les chercheurs en biologie et en bio-informatique, mais aussi une importante communaut´e de chercheurs, universitaires et industriel au niveau r´egional, national et international. Les activit´es de l’IBC amnitionnent de collaborer avec des chercheurs de renommee mondiale, d’organiser des manifestations scientifiques, de former de jeunes chercheurs, et de promouvoir les r´esultats et ´echanger des informations avec des partenaires industriels. 2
  13. 13. La recherche sur le riz est un des mod`eles d’´etude abord´e par les chercheurs de l’IBC notamment `a travers le projet BIOeSAI (Biological electronic System Assistant Index). Ce projet a pour objectif de g´erer des ´etudes de diversit´e g´enotypique et ph´enotypique de vari´et´es traditionnelles de riz vietnamien (Oryza sativa). L’objectif de ces ´etudes est d’identifier des g`enes d’int´erˆet pour qu’on puisse comprendre les processus biologiques, par exemple : le d´eveloppement et la plasticit´e de la plante, la r´esistance aux maladies. Ces ´etudes requi`erent la manipulation d’un volume important de donn´ees h´et´erog`enes. Ces donn´ees peuvent ˆetre stock´ees sous des formes diff´erentes : fichier Excel, fichier texte structur´e, images ou bases de donn´ees relationnelles. 1.1.2 Pr´esentation de l’INRA L’INRA est un organisme de recherche fran¸cais pour l’agronomie fond´e en 1946. Les recherches men´ees par l’INRA sont guid´ees par les questionnements scientifiques en lien aux d´efis plan´etaires pos´es par l’ali- mentation, l’environnement et la valorisation des territoires. Changement climatique, nutrition humaine, comp´etition entre cultures alimentaires et non alimentaires, ´epuisement des ressources fossiles, ´equilibre dans la gestion des territoires sont autant d’enjeux qui positionnent l’agronomie comme fondatrice d’un d´eveloppement harmonieux sur les plans ´economique, social et environnemental. L’INRA produit des connaissances fondamentales et construit, grˆace `a elles, des innovations et des savoir-faire pour la soci´et´e. Il met son expertise au service de la d´ecision publique. Les grandes missions confi´ees `a l’INRA sont les suivantes : ˆ Produire et diffuser des connaissances scientifiques. ˆ Concevoir des innovations et des savoir-faire pour la soci´et´e. ˆ ´Eclairer, par son expertise, les d´ecisions des acteurs publics et priv´es. ˆ D´evelopper la culture scientifique et technique et participer au d´ebat science-soci´et´e. ˆ Former `a la recherche et par la recherche. Le centre INRA de Montpellier coordonne Ph´enome, un projet de plate-formes de ph´enotypage haut- d´ebit de plantes cultiv´ees. Son objectif est de mesurer des caract`eres agronomiques de plantes soumises `a diff´erents sc´enarios environnementaux et en particulier les conditions de stress hydrique. C’est un projet sur huit ans regroupant neuf plates-formes r´eparties sur sept sites d’´etudes en France. Les ´etudes couvrent `a la fois des probl´ematiques de recherche fondamentale en g´en´etique et de re- cherche appliqu´ee pour la s´election de plantes adapt´ees `a des contextes climatiques particuliers. Sur la plate-forme de Montpellier se trouve trois plateaux techniques diff´erents permettant de mesurer la croissance de plantes en fonction de l’environnement : ˆ Ph´enoPsis qui permet de peser et photographier plus de cinq cent plantes (Arabidopsis thaliana, une plante mod`ele pour l’agronomie) ˆ Ph´enoArch o`u plus de mille six cent plantes (ma¨ıs et autres c´er´eales, vigne, pommiers) sont d´eplac´ees grˆace `a un automate afin de proc´eder `a diff´erentes mesures, portant notamment sur l’architecture de la plante, et d’ˆetre photographi´ees dans des cabines d’imageries 3D. 3
  14. 14. ˆ Ph´enoDyn o`u l’on mesure en particulier la transpiration et la croissance des feuilles des plantes. D’autres plate-formes, comme celles de Toulouse, Dijon ou Mauguio, pr´esentent des environnements non contrˆol´es, avec des exp´erimentations en champ. Les donn´ees ph´enotypiques sont alors acquises grˆace `a une Ph´enomobile (robot mobile autonome ´equip´e de capteurs embarqu´es) ou `a des drones. Ces plate-formes sont sp´ecialis´ees en ´ecophysiologie, c’est-`a-dire dans l’´etude de l’influence de l’en- vironnement sur la plante. Par cons´equent, pour l’ensemble des exp´erimentations r´ealis´ees, les donn´ees issues des capteurs environnementaux sont primordiales. Ces donn´ees sont `a la fois h´et´erog`enes en termes de formats, de s´emantique, etc. et volumineuses (plusieurs t´eraoctets par mois). Elles sont de plus reli´ees entre elles au sein d’une experience et doivent pouvoir ˆetre trac´ees dans le temps. Dans le contexte de Phenome, ces tr`es nombreuses donn´ees doivent ˆetre conserv´ees, partag´ees et ana- lys´ees. Il faudra en effet ˆetre capable de les retrouver dans plusieurs ann´ees. De mˆeme, elles doivent pou- voir ˆetre consult´ees et utilis´ees indiff´eremment par l’ensemble des neuf plates-formes. Enfin, les r´esultats d’analyse et de calculs doivent ´egalement ˆetre reli´es aux donn´ees. 1.2 Description du stage Dans le cadre du projet de l’´equipe G´enome et D´eveloppement des Riz, du LMI RICE (Hano¨ı), des ´etudes de la diversit´e g´enotypique et ph´enotypique de vari´et´es traditionnelles de riz vietnamien sont conduites dans le but d’identifier des g`enes d’int´erˆet pour la compr´ehension de processus biologiques. De la mˆeme mani`ere, les recherches du laboratoire INRA `a Montpellier ´evaluent les influences de l’envi- ronnement sur les plantes. La caract´eristique commune entre ces deux projets est la manipulation d’un important volume de donn´ees h´et´erog`enes. Ces donn´ees sont organis´ees dans des syst`emes de gestion de base de donn´ees relationnelles ou des syst`emes de gestion de base de donn´ees NoSQL (MongoDB). Dans ce contexte, les ´equipes souhaitent r´eorganiser leurs propres jeux de donn´ees afin de pouvoir naviguer, partager, annoter et rechercher ces derni`eres afin de les exploiter au mieux. Un syst`eme d’information a ´et´e impl´ement´e lors d’un stage de Master 1 en 2014[1] pour le projet du LMI RICE (BIOeSAI). Ce syst`eme est bas´e sur un syst`eme de gestion base de donn´ees MongoDB incluant ´egalement la gestion des m´etadonn´ees et des tags. Toutefois, la m´ethode mise en place ne permet pas de d´etecter des relations explicites/implicites entre les donn´ees g´er´ees par le syst`eme. L’objectif du stage propos´e sera d’´evaluer la faisabilit´e de gestion des BIG DATA coupl´e au techno- logies du Web S´emantique en s’appuyant sur les articles de synth`ese du domaine [2]. Par ailleurs, nous r´ealiserons un ´etat de l’art sur les probl`emes d’organisation des donn´ees massives et de l’augmentation de la capacit´e de recherche sur les donn´ees. Plus particuli`erement, sur la capacit´e d’inf´erence et de raisonne- ment sur les donn´ees. Un des objectifs du travail dans ce sujet sera de construire un base de connaissance sur les donn´ees existantes. 1.3 Probl´ematiques Les donn´ees biologiques existantes sont volumineuses et elles ne cessent d’augmenter chaque jour. L’utilisation des syst`emes de gestion de base donn´ees relationnelles est aujourd’hui mal adapt´e pour g´erer ces donn´ees[1]. L’´emergence des syst`emes de gestion de base de donn´ees NoSQL orient´e-document (e.g. 4
  15. 15. MongoDB) semble mieux adapt´e [3] toutefois ces systemes sont depourvus d’une capacit´e de recherche s´emantique sur les donn´ees ce qui existent seulement sur les donn´ees RDF par utiliser par le language SPARQL. Les bases de donn´ees de type “triplestore” sont mieux adapt´ees pour faire des inf´erences ou des raisonnements sur les donn´ees. Toutefois, elles passent moins bien `a l’´echelle sur des gros volumes de donn´ees. En effet, la recherche ou l’inf´erence sur un grand volume de donn´ees RDF peuvent prendre beaucoup de temps. L’enjeu dans la gestion de ce type de donn´ees est d’utiliser les capacit´es d’inf´erence s´emantique avec de gros volumes de donn´ees. L’association entre un syst`eme de donn´ees massives et les capacit´es de recherche s´emantique est l’objectif principal du sujet. 1.4 Contexte du sujet 1.4.1 Contexte de donn´ees massives Aujourd’hui, nous entrons dans l’`ere des Big Data. Des ensembles de donn´ees tellement gigantesques qu’ils n´ecessitent de nouveaux outils techniques et scientifiques pour les comprendre et en tirer du sens. Un d´eluge de donn´ees qui pose des questions profondes sur leur collecte, leur interpr´etation, leur analyse etc. Les prochains enjeux de ce si`ecle sont d’extraire du sens de ces masses d’information qui circulent sur les r´eseaux. Dans ce domaine, c’est avec la g´enomique et le ph´enotypage que la biologie est d´ej`a entr´ee dans le monde des big data. Certes, l’imagerie ou la mod´elisation m´etabolisme produisaient des donn´ees num´eriques, mais la question de leur gestion et de leur exploitation ne se posait pas de la mˆeme fa¸con. En termes d’exploitation des donn´ees, beaucoup reste `a faire en biologie. C’est mˆeme l`a que se situe le grand d´efi des big data en sciences de la vie : rattraper le foss´e grandissant entre production massive de donn´ees et la capacit´e `a en extraire une information, voir une connaissance. Le Big Data s’accompagne du d´eveloppement d’applications `a vis´ee analytique, qui traitent les donn´ees pour en tirer du sens. Ces analyses sont appel´ees Big Analytics ou “broyage de donn´ees”. Elles portent sur des donn´ees quantitatives complexes avec des m´ethodes de calcul distribu´e. En effet, les donn´ees massives d´esignent des ensembles de donn´ees tellement volumineux qu’il en devient difficile de travailler avec des outils classiques des gestion de base de donn´ees ou de gestion de l’information. Les Big Data sont souvent d´efinis en utilisant l’acronyme 3V pour Volume, V´elocit´e et Vari´et´e [4]. La volume se r´ef`ere `a des quantit´es massives de donn´ees qui sont disponibles, le volume des donn´ees stock´ees est en pleine expansion : les donn´ees num´eriques cr´e´ees dans le monde seraient pass´ees de 1,2 zettaoctets par an en 2010 `a 1,8 zettaoctets en 2011, puis 2,8 zettaoctets en 2012 et s’´el`everont `a 40 zettaoctets en 2020[5]. `A titre d’exemple, Twitter g´en´erait en janvier 2013, 7 teraoctets de donn´ees chaque jour et Facebook 10 teraoctets[6]. La v´elocit´e repr´esente `a la fois la fr´equence `a laquelle les donn´ees sont g´en´er´ees, captur´ees et partag´ees et mises `a jour. Quelquefois, la v´elocit´e se r´ef`ere `a la v´elocit´e n´ecessaire pour traiter, analyser et utiliser les donn´ees. Le volume des Big Data met les data centers devant un r´eel d´efi : la vari´et´e des donn´ees. Il ne s’agit pas 5
  16. 16. de donn´ees relationnelles traditionnelles, ces donn´ees sont brutes, semi-structur´ees voire non structur´ees (cependant, les donn´ees non-structur´ees devront, pour utilisation, ˆetre structur´ees). Ce sont des donn´ees complexes provenant du web, au format texte et images. Elles peuvent ˆetre publiques (Open Data, Web des donn´ees), g´eo-d´emographiques par ˆılot (adresses IP), ou relever de la propri´et´e des consommateurs. Ce qui les rend difficilement utilisables avec les outils traditionnels. Pour r´epondre aux probl´ematiques Big Data l’architecture de stockage des syst`emes doit ˆetre repens´ee et les mod`eles de stockage se multiplient en cons´equence : ˆ Cloud computing : l’acc`es se fait via le r´eseau, les services sont accessibles `a la demande et en libre service sur des ressources informatiques partag´ees et configurables. Les services les plus connus sont ceux de Google BigQuery, Big Data on Amazon Web Services, Microsoft Windows Azure. ˆ Super calculateurs hybrides : Les HPC pour High Performance Computing, qu’on retrouve en France dans les centres nationaux de calculs universitaire tels quel’IDRIS, le CINES, mais aussi au CEA ou encore le HPC-LR ˆ Syst`emes de fichiers distribu´ees Distributed files system (DFS) : les donn´ees ne sont plus stock´ees sur une seule machine car la quantit´e `a stocker est beaucoup trop importante. Les donn´ees, les fichiers sont “d´ecoup´es” en morceaux d’une taille d´efinie et chaque morceau est envoy´e sur une machine bien pr´ecise utilisant du stockage local. Le stockage local est pr´ef´er´e au stockage SAN (Storage Area Network)/NAS (Network attached storage) pour des raisons de goulots d’´etranglement au niveau du r´eseau et des interfaces r´eseaux des SAN. De plus, utiliser un stockage de type SAN coˆute bien plus cher pour des performances bien moindres. Dans les syst`emes de stockage distribu´e pour le Big Data, l’on introduit le principe de “Data locality”. Les donn´ees sont sauvegard´ees l`a o`u elles peuvent ˆetre trait´ees. Les bases de donn´ees relationnelles classiques ne permettent pas de g´erer les volumes de donn´ees du Big Data. De nouveaux mod`eles de repr´esentation permettent de garantir les performances sur les volum´etries en jeu. Ces technologies, dites de Business Analytics, Optimization permettent de g´erer des bases massivement parall`eles. Des patrons d’architecture “Big Data Architecture framework” sont pro- pos´es par les acteurs de ce march´e comme MapReduce d´evelopp´e par Google et utilis´e dans le framework Hadoop. Avec ce syst`eme les requˆetes sont s´epar´ees et distribu´ees `a des nœuds parall´elis´es, puis ex´ecut´ees en parall`eles . Les r´esultats sont ensuite rassembl´es et r´ecuper´es. Teradata, Oracle ou EMC proposent ´egalement de telles structures, bas´ees sur des serveurs standards dont les configurations sont optimis´ees. Ils sont concurrenc´es par des ´editeurs comme SAP (Systems, Applications, et Products) et plus r´ecemment Microsoft. Les acteurs du march´e s’appuient sur des syst`emes `a forte scalabilit´e horizontale et sur des solutions bas´ees sur du NoSQL plutˆot que sur des bases de donn´ees relationnelles classiques. Avec les donn´ees dans nos laboratoires, le probl`eme de gestion des donn´ees massives ne peut pas ˆetre r´esolu avec les syst`emes de gestion de base de donn´ees relationnelles. Ces syst`emes deviennent lourds et lents sur ces types de donn´ees. Ces derni`eres ann´ees, ont vu l’´emergence d’une diversit´e de syst`emes de gestion de base de donn´ees que l’on appelle NoSQL. Ces syst`emes NoSQL, proposent plusieurs modeles pour organiser et stocker les donn´ees (la table 1.1). 6
  17. 17. Type de base de donn´ees1 Liste des syst`emes utilis´es Cl´e - valeur CouchDB, Oracle NoSQL Database, Dynamo, FoundationDB, Hy- perDex, MemcacheDB, Redis, Riak, FairCom c-treeACE, Aerospike, OrientDB, MUMPS Orient´e colonne Accumulo, Cassandra, Druid, HBase, Vertica Orient´e document MongoDB, Clusterpoint, Apache CouchDB, Couchbase, Docu- mentDB, HyperDex, Lotus Notes, MarkLogic, OrientDB, Qizx Orient´e Graphe Allegro, Neo4J, InfiniteGraph, OrientDB, Virtuoso, Stardog Multi-mod`ele OrientDB, FoundationDB, ArangoDB, Alchemy Database, CortexDB Tableau 1.1: La liste des types et des syst`eme de gestion de base de donn´ees dans NoSQL Dans le domaine des donn´ees scientifique, il existe ´egalement de r´eels besoins d’exploitation de ces donn´ees, en raison notamment de la forte augmentation de leur volume des derni`eres ann´ees. Le big data et les technologies associ´ees permettent de r´epondre `a diff´erents enjeux tels que l’acc´el´eration des temps d’analyse des donn´ees, la capacit´e `a analyser l’ensemble des donn´ees et non seulement un ´echantillon de celles-ci ou la r´ecup´eration et la centralisation de nouvelles sources de donn´ees `a analyser afin d’identifier des sources de valeur. Alors, sur la base des caract´eristiques des donn´ees, on va d´ecider quel syst`eme de gestion de donn´ees utiliser. Par exemple avec les donn´ees qui ont plusieurs relations, nous pouvons choisir le type de base de donn´ee orient´e graphe. Il s’appuie sur la notion de noeuds, de relations et de propri´et´es qui leur sont rattach´ees. Ce mod`ele facilite la repr´esentation du monde r´eel, ce qui le rend adapt´e au traitement des donn´ees des r´eseaux sociaux etc. 1.4.2 Contexte de recherche s´emantique Figure 1.1: L’architecture du web s´emantique Organiser les donn´ees afin de mieux les comprendre, les utiliser et les partager, est un objectif de longue date. Mais le d´eveloppement de l’`ere digitale a provoque une avalanche de donn´ees dont le traitement requiert de nouvelles m´ethodes. L’enjeu de la recherche informatique est d’ex- traire du sens dans cette masse d’in- formation notamment `a travers des m´ethodes de fouilles de donn´ees ou des algorithmes d’apprentissage auto- matique scannant le web. Toutefois, les probl`emes ne sont pas r´esolu pour autant. Pourtant, a partir de l’id´ee de Tim Berners-Lee : “J’ai fait un rˆeve pour le Web [dans lequel les ordinateurs] deviennent capables d’analyser toutes les donn´ees sur le Web - le contenu, les liens, et les transactions entre les personnes et les ordinateurs. Un “Web S´emantique”, 7
  18. 18. qui devrait rendre cela possible, n’a pas encore ´emerg´e, mais quand ce jour sera atteint, les m´ecanismes de dialogue entre les machines sera facilite. Les “agents intelligents” qu’on nous promet depuis longtemps vont enfin se concr´etiser”[7] [8], le web s´emantique ´emerge comme la meilleure solution pour traiter des donn´ees directes ou indirectes par des machines, partager et r´eutiliser des donn´ees entre plusieurs applications et aider les utilisateurs `a cr´eer de nouvelles connaissances. Dans le contexte d’application orient´e web s´emantique et la gestion de donn´ees biologiques, nous allons focaliser sur les trois parties principales suivantes : Le repr´esentation de donn´ees en RDF, les requˆetes avec SPARQL et les inf´erences, les raisonnements pour trouver de nouvelles connaissances. La description de ressources (RDF) Figure 1.2: L’exemple d’un triplet RDF. La RDF est un mod`ele de graphe destin´e `a d´ecrire la donn´ee de fa¸con `a permettre son traitement automatique par des machines. RDF donne une description par triplet <Sujet, Pr´edicat, Objet>. Le sujet repr´esente la ressource `a d´ecrire, le pr´edicat repr´esente un type de propri´et´e applicable `a cette ressource, et l’objet repr´esente une donn´ee ou une autre ressource. Les documents RDF peuvent ˆetre ´ecrits en diff´erents syntaxes ainsi, il peuvent exister sous plusieurs formats : RDF/XML, N3, N-Triples, TURTLE, JSON-LD etc La RDF est donc simplement une structure de donn´ees constitu´ee de nœuds et organis´ee en graphe. Un document RDF ainsi form´e correspond `a un multi-graphe orient´e ´etiquet´e. Ici, chaque triplet correspond alors `a un arc orient´e dont le label est le pr´edicat, le nœud source est le sujet et le nœud cible est l’objet. L’Interrogation de graphes RDF Figure 1.3: L’exemple d’une requˆete SPARQL. Le SPARQL est un langage de requˆetes pour interroger des donn´ees qui sont stock´ees en respectant le mod`ele RDF. Les requˆetes SPARQL sont adapt´ees `a la structure sp´ecifique des graphes RDF, et s’appuient sur structure sous la forme de triplets. En cela, il est diff´erent du classique SQL, mais s’en inspire clairement dans sa syntaxe et ses fonctionnalit´es. Le SPARQL permet d’exprimer des requˆetes interrogatives ou constructives : une requˆete SELECT, de type interrogative, permet d’extraire du graphe RDF un sous-graphe correspondant `a un ensemble de ressources v´erifiant les conditions d´efinies dans une 8
  19. 19. clause WHERE ; une requˆete CONSTRUCT, de type constructive, engendre un nouveau graphe qui compl`ete le graphe interrog´e. L’Ontologie L’Ontologie est un ensemble structur´e de termes et concepts repr´esentant le sens d’un champ d’in- formations, que ce soit par les m´etadonn´ees d’un espace de noms, ou les ´el´ements d’un domaine de connaissances. L’ontologie constitue en soi un mod`ele de donn´ees repr´esentatif d’un ensemble de concepts dans un domaine, ainsi que des relations entre ces concepts. Elle est employ´ee pour raisonner `a propos des objets du domaine concern´e. Plus simplement, nous pouvons aussi dire que l’ “ontologie est aux donn´ees ce que la grammaire est au langage”. Les conceptions utilisent pour d´ecrire d’une ontologies g´en´erales : ˆ Individus : les objets de base ˆ Classes : ensembles, collections, ou types d’objets ˆ Attributs : propri´et´es, fonctionnalit´es, caract´eristiques ou param`etres que les objets peuvent poss´eder et partager ˆ Relations : les liens que les objets peuvent avoir entre eux ˆ Ev´enements : changements subits par des attributs ou des relations ˆ M´eta-classes : des collections de classes qui partagent certaines caract´eristiques L’inf´erence, le raisonnement L’inf´erence sur le Web s´emantique est l’un des outils de choix pour am´eliorer la qualit´e de l’int´egration de donn´ees sur le web, en d´ecouvrant de nouvelles relations, analyse automatiquement le contenu des donn´ees, ou la gestion des connaissances sur le web en g´en´eral. Les Techniques `a base d’inf´erence sont aussi importante dans la d´ecouverte d’´eventuelles incoh´erences dans les donn´ees int´egr´ees. Un exemple simple peut aider `a bien comprendre `a la conception de l’inf´erence. Les donn´ees fix´ees pour ˆetre consid´er´ees peuvent inclure la relation (HaiPhong isPartOf the North Vietnam). Une ontologie peut d´eclarer que “The North of VietNam isPartof Vietnam”. Cela signifie que d’un programme de Web s´emantique comprendre la notion de “X ispartOf Y” peut ajouter la d´eclaration “HaiPhong isPartOf Vietnam” `a l’ensemble des relations, bien que cela ne faisait pas partie des donn´ees originales. On peut dire aussi que la nouvelle relation a ´et´e “d´ecouverte”. D’une mani`ere g´en´erale, Les inf´erences sur le web s´emantique peut ˆetre caract´eris´ee par la d´ecouverte de nouvelles relations. Sur le Web s´emantique, les donn´ees sont mod´elis´ees comme un ensemble de relations entre les ressources. “l’Inf´erence” signifie que les proc´edures automatiques peuvent g´en´erer de nouvelles relations fond´ees sur les donn´ees et sur la base des informations suppl´ementaires sous la forme d’un vocabulaire, un ensemble de r`egles. Que les nouvelles relations sont explicitement ajout´ees `a l’ensemble des donn´ees, ou sont retourn´ees au moment de la requˆete, est une question de mise en oeuvre. Sur le Web s´emantique, la source de telles informations suppl´ementaires peut ˆetre d´efinie par l’in- term´ediaire de vocabulaires ou ensembles de r`egles. Ces deux approches font appel aux techniques de repr´esentation des connaissances. En g´en´eral, les ontologies se concentrent sur les m´ethodes de classifica- tion, en mettant l’accent sur la d´efinition de de “classes”, “sous-classes”, sur la fa¸con dont les ressources 9
  20. 20. individuelles peuvent ˆetre associes `a ces classes, et de caract´eriser les relations entre les classes et leurs ins- tances. D’autre part, les r`egles se concentrent sur la d´efinition d’un m´ecanisme g´en´eral sur la d´ecouverte et la g´en´eration de nouvelles relations fond´ees sur celles qui existent d´ej`a tout comme les programmes logiques, tel Prolog. Dans la famille du Web s´emantique li´e aux recommandations de World Wide Web Consortium (W3C) : Resource Description Framework Schema (RDFS), Web Ontology Language (OWL), Simple Knowledge Organization System (SKOS) sont des outils de choix pour d´efinir des ontologies, alors que Rule Interchange Format (RIF) a ´et´e d´evelopp´e pour couvrir les approches bas´ees sur des r`egles. 10
  21. 21. Chapitre 2 ´Etat de l’art 2.1 Existants Depuis plusieurs ann´ees des ´etudes en ph´enotypage haut-d´ebit des plantes sont r´ealis´ees `a l’INRA. Il existe donc un grand nombre de donn´ees de ph´enotypage et de g´enotype des plantes. Ces donn´ees sont acquises chaque jour, par exemple sur le plateau technique PhenoArch, environ 1600 plantes sont suivies pendant deux `a trois mois. Chaque jours elles sont photographi´ees sous trois `a treize angles, ce cycle journalier d’imagerie produit donc environ 20800 images stock´ees. Celles-ci sont associ´ees `a des configuration et des r´esultats d’analyse d’image sous la forme de JSON. Chaque document JSON est environ 40 champs. Pour les g´erer, les informaticiens ont d´ej`a construits un syst`eme d’information appel´e Phenotyping Hybrid Information System (PHIS)1 . Les donn´ees permettant l’exploitation de la plateforme sont stock´ees dans une base de donn´ees relationnelles. Avec les limitations de base de donn´ees relationnelles, ces donn´ees doivent ˆetre migr´ees dans une base MongoDB pour am´eliorer le temps de performance du syst`eme. La mˆeme fa¸con, le projet BIOeSAI est entr´ee dans une deuxi`eme phase `a partir de 2015 `a 2018. Les ´etudes de la premi`ere phase ont ´et´e r´ealis´ees sur riz (O.SATIVA). Ce sont des donn´ees h´et´erog`enes et volumineuses sur le ph´enotypages et g´enotypes du riz. Le laboratoire a aussi construit un syst`eme d’information pour g´erer les donn´ees Syspherice2 [1]. Ces donn´ees sont organis´ees et stock´ees sous la forme de document JSON. Elles sont g´er´ees par le syst`eme de gestion de base de donn´ees orient´e document MongoDB. 2.2 Analyse et ´evaluation des solutions courantes 2.2.1 MongoGraph - une association du Mongodb et AllegroGraph AllegroGraph est une base de donn´ees de graphe RDF persistante. Il utilise le stockage sur sur disque, ce qui lui permet de passer `a l’´echelle des milliards de triplets, tout en maintenant une performance sup´erieure. AllegroGraph est un framework de base de donn´ees et d’outils pour construire des applications Web s´emantique. Il peut stocker des donn´ees et des m´eta-donn´ees, il permet aussi d’interroger ces triplets `a 1http ://lps-phis.supagro.inra.fr/phis/index.php 2http ://vmbioesai-dev.ird.fr :8080/Syspherice 11
  22. 22. travers diff´erentes APIs comme SPARQL et Prolog. De plus, il fourni des fonctionnalit´es de raisonnement RDFS++ avec son raisonneur int´egr´e. AllegroGraph inclut ´egalement une librairie d’analyse de r´eseaux sociaux (SNA) et il permet de stocker et raisonner sur des donn´ees temporelles et g´eospatiales. Actuellement, il existe diff´erentes ´editions d’AllegroGraph : une ´edition gratuite o`u stockage RDF est limit´ee `a moins de 5 millions de triplets, une ´edition d´eveloppeur capable de stocker un maximum de 50 millions de triplets et une ´edition d’entreprise avec une capacit´e de stockage qui n’est limit´ees que par l’infrastructure de serveur. Des clients sont disponibles pour Java, Python, Lisp, Clojure, Ruby, Perl, Csharp et Scala. En plus des fonctions li´ees `a l’application de Web s´emantique, AllegroGraph impl´emente une interface avec MongoDB, que l’on appelle MongoGraph. Celle-ci permet d’offrir aux programmeurs MongoDB les capacit´e du Web s´emantique. En utilisant cette approche, les objets Javascript Object Notation (JSON) sont automatiquement convertis en triplets et ils peuvent ˆetre interrog´es `a la fois par le langage de requˆete MongoDB et par SPARQL. Figure 2.1: Le mod`ele de composants dans un syst`eme MongoGraph MongoDB est une base de donn´ees orient´ees documents NoSQL de haute performance et Open Source. MongoDB fournit un stockage bas´e sur des docu- ments en forme de JSON avec comme fonctionnalit´es l’indexation en texte int´egral, la r´eplication, la r´epartition des de donn´ees (sharding), le calcul Map/Re- duce et un langage de requˆete riche `a base de documents. Toutefois, il ne fournit pas un bon support pour les jointures com- plexes, le liage de donn´ees (linked data), l’analyse de graphe et l’inf´erence ou le raisonnement. En connectant AllegroGraph `a Mon- goDB, il est possible d’interroger des donn´ees li´ees en graphe et dans une base de donn´ees orient´ees documents en une seule requˆetes. Avec MongoDB, les donn´ees sont organis´ees en forme des do- cuments JSON, ils sont g´er´ees par un syst`eme de gestion de base de donn´ees orient´ees documents des plus efficace [9]. Avec AllgroGraph, les donn´ees sont organis´ees en graphe, sur lesquelles nous pouvons r´ealiser facilement des requˆetes SPARQL, et aussi effectuer des inf´erences sur ces donn´ees. Avec les caract´eristiques des deux syst`emes de gestion de base de donn´ees, il est possible de construire un syst`eme qui a des capacit´es de requˆetes du Web s´emantique et qui peut traiter des donn´ees volumi- neuses. Le mod`ele du syst`eme g´en´eral de MongoDB et de AllegroGraph est mis en oeuvre Figure 2.1. 12
  23. 23. Ici, les donn´ees d’origines restent stock´ees dans MongoDB sous le format documents dans des collections. Les nouveaux triplets mis en relation avec les documents MongoDB sont import´es dans AllegroGraph. Pour cr´eer manuellement des triplets ou utiliser l’outil Relational and Non-Relational Databases to RDF Mapping Language (xR2RML) pour les convertir automatiquement. On utilise les seulement les attributs importants dans les documents. D’ailleurs, une ontologie est utilis´ee pour l’organisation s´emantique des triplets cr´e´es. Cette ontologie permet l’inf´erence en exploitant les relations entre les triplets. Ainsi le moteur d’inf´erence peut cr´eer de nouvelles relations sur la base de l’ontologie d´efinie. (a) Les donn´ees JSON dans MongoDB (b) Les donn´ees RDF dans AllegroGraph (c) L’ontologie de lieu origine de plante Figure 2.2: Les donn´ees pr´esent´ees dans cet exemple Pour mieux comprendre la solution d’association de MongoDB et de AllegroGraph et illustrer les requˆetes et l’inf´erence, nous avons pris un exemple sur les donn´ees existantes du projet BIOeSAI. Ce projet contient une ontologie sur les relations entre le lieu d’origine des plantes et les images exp´erimentales sur les plantes. Les triplets sont cr´e´es `a partir des documents MongoDB, dans ce cas, en utilisant les attributs de l’identification du document, les informations sur l’origine des plante et du nom des plantes. On peut voir les d´etails des donn´ees JSON dans MongodDB, des donn´ees RDF qui ont ´et´e li´es aux documents MongoDB et l’ontologie de r´ef´erences dans Figure 2.2. 13
  24. 24. Nous pouvons faciliter l’importation des donn´ees RDF dans AllegroGraph en utilisant la forme d’un d´epˆot, “Repository”. La cr´eation d’une connexion avec MongoDB est effectu´e dans l’interface de Allegro- Graph. Ici, les informations de la base de donn´ees MongoDB doivent ˆetre rempli, par exemple : le nom et port du serveur, le nom de la base de donn´ees et la collection choisie. AllegroGraph poss`ede deux types diff´erents de moteur d’inf´erence : l’un supporte un sur-ensemble de r`egles d’inf´erence RDFS et l’autre supporte Web Ontology Rule Language (OWL 2 RL). Le premier est appel´e le raisonneur RDFS++ dynamique car il g´en`ere les triplets inf´er´es `a l’ex´ecution de l’inf´erence et n’enregistre pas les triples nouveaux cr´e´es. Le second moteur d’inf´erence fait de la mat´erialisation OWL 2 RL. Il utilise de r`egles d’inf´erence pour g´en´erer de nouveaux triplets et les ajoute `a la base de triplets courante. Pour notre exemple, le second moteur d’inf´erence est choisi pour toutes les donn´ees. Apr`es avoir ex´ecut´e, nous avons les nouveaux triplets sont stock´es de mani`ere p´erenne sur le disque comme les triplets d’origine. Cela est le mieux pour les syst`emes qui ont plusieurs requˆetes. Les requˆetes sont r´ealis´ees grˆace au langage SPARQL int´egrant des requˆetes MongoDB (Figure 2.3). Cette association est effectu´ee par l’utilisation d’une approche que l’on appelle “Magic Predicat”. C’est un pr´edicat d’une requˆete SPARQL qui permet une liaison, diff´erente d’un simple appariement de sous- graphe. AllegroGraph a longtemps soutenu l’utilisation de “Magic Predicat” pour permettre les requˆetes en texte libre et pour interfacer Solr et MongoDB. Dans la requˆete Figure 2.3, le syst`eme va effectuer deux requˆetes dans deux syst`emes diff´erents pour obtenir les r´esultats. Les requˆetes seront ex´ecut´ees dans MongoDB pour trouver les r´esultats sous le format de JSON, et les r´esultats finaux (les triplets) seront trouv´es dans AllegroGraph. Figure 2.3: Une requˆete SPARQL associ´ee `a une requˆete de MongoDB Avantages ˆ AllegroGraph permet de r´ealiser des inf´erences sur des donn´ees massives ˆ Selection possible des propri´et´es importantes et donc r´eduction du nombre de triplets dans la base de donn´ees. ˆ Gestion de base de donn´ees massives avec MongoDB Inconvenients ˆ Un syst`eme plus complexe avec plusieurs ´etapes de requˆetes ˆ Mapping manuel des donn´ees entre les deux syst`emes MongoDB et AllegroGraph 14
  25. 25. ˆ Pas de synchronisation entre les deux, quand nous mettons `a jour au MongoDB, nous devons le faire aussi sur Allegograph 2.2.2 Base de donn´ees orient´ee graphe Neo4j Neo4j est un syst`eme de gestion de base de donn´ees orient´e graphe, ce qui permet de repr´esenter les donn´ees en tant qu’objet reli´e par un ensemble de relations, chaque objet poss´edant ses propres propri´et´es. La base de donn´ees de graphes, permet au d´eveloppeur de commencer directement le codage, les donn´ees stock´ees dans la base assurant un parall´elisme direct avec les donn´ees elles-mˆemes. En d’autres termes, `a mesure que l’organisation des donn´ees se peaufineront, les programmes suivront. Une base Neo4j est cens´ee ˆetre plusieurs milliers de fois plus rapide pour traiter les donn´ees associa- tives, car elle en ´evite de coˆuteuses jointures Structured Query Language (SQL). Les requˆetes peuvent g´erer de ce fait plus facilement un large ensemble de donn´ees. Les parcours utilisent un langage simple de parcours des connections. L’absence de mod´elisation rigide, rend Neo4j bien adapt´e `a la gestion de donn´ees changeantes et de sch´emas ´evoluant fr´equemment. Les caract´eristiques typiques de donn´ees pour Neo4j sont la structuration des donn´ees optionnelles qui sont peuvent absenter, une facilit´e de changement du sch´ema et des migrations de donn´ees sans contraintes, la mod´elisation facile de jeux de donn´ees de domaines complexes et cas d’utilisation typique dans des domaines tels que le Web s´emantique et RDF, le Web de donn´ees, l’analyse du g´enome, la mod´elisation de donn´ees de r´eseaux sociaux etc. Neo4j a des composants optionnels qui viennent en compl´ement du noyau. On peut ainsi structurer le graphe via un m´eta-mod`ele, obtenir une impl´ementation de RDF TripleStore compatible SPARQL. Par exemple, avec deux plugins Neo-rdf-sail 3 et Neo4j-sparql-extension4 . Figure 2.4: La graphe de donn´ees dans Neo4j Les graphes de donn´ees dans Neo4j sont illustr´es par les concepts de ”Nodes” et de ”Relations” 3https ://github.com/neo4j-contrib/neo4j-rdf-sail 4https ://github.com/niclashoyer/neo4j-sparql-extension 15
  26. 26. Figure 2.4. D’ailleurs, le langage de requˆete Cypher est utilis´e pour manipuler les donn´ees. C’est un langage d´eclaratif de requˆete graphique qui permet de r´ealiser efficacement et rapidement des requˆetes et des mis `a jour sur les donn´ees. En d´etail, le langage Cypher se concentre sur la clart´e d’expression de ce que l’on veut r´ecup´erer `a partir d’un graphique et pas sur la fa¸con de le r´ecup´erer. Cette approche permet l’optimisation des requˆetes. Figure 2.5: Les commandes pour cr´eer un graphe simple Avantages ˆ Gestion de base de donn´ees pour le Big Data sous la forme de graphes, donc amelioration de la performance du syst`eme par des requˆetes bas´ees sur des relations entre les objets. ˆ L’organisation de donn´ees sous forme de graphe est presque similaire `a l’organisation des donn´ees dans les ontologies et les instances donn´ees RDF. Inconv´enients ˆ Les donn´ees doivent ˆetre re-organiser sous la forme d’un graphe, cela prendre plus de temps en fonction de la complexit´e et de la taille de donn´ees. ˆ Les donn´ees ne sont pas en RDF directement, donc pour faire des requˆetes SPARQL nous utilisons un plugin int´egr´e qui ne supporte pas enti`erement le language SPARQL. 2.2.3 JSON-LD et MongoDB Les donn´ees li´ees se r´ef`erent `a un ensemble de bonnes pratiques `a mettre en oeuvre pour publier et lier des donn´ees structur´ees sur le web. Elles s’appuient sur les standards du Web, tels que HTTP et URI - mais plutˆot qu’utiliser ces standards uniquement pour faciliter la navigation par les ˆetres humains, le Web des donn´ees les ´etend pour partager ´egalement l’information entre machines. Cela permet d’interroger automatiquement les donn´ees, quels que soient leurs lieux de stockage et sans avoir `a les dupliquer. JSON-LD est une syntaxe l´eg`ere pour s´erialiser des donn´ees li´ees de la forme de JSON. Son utilisation permet `a des donn´ees JSON d’ˆetre interpr´et´ees comme des donn´ees li´ees avec des changements minimes. JSON-LD est principalement destin´e `a ˆetre un moyen d’utiliser les donn´ees li´ees dans des environnements de programmation bas´es sur le Web, pour construire des services Web interop´erables, et pour stocker des donn´ees li´ees dans les moteurs de stockage `a base de JSON. Actuellement, JSON-LD est compatible avec JSON, un grand nombre de parseurs JSON et de biblioth`eques sont disponibles aujourd’hui et peuvent ˆetre r´eutilis´es. En plus de toutes les fonctionnalit´es JSON, JSON-LD introduit : ˆ Un m´ecanisme d’identifiant universel pour les objets JSON via l’utilisation d’IRIs 16
  27. 27. ˆ Un moyen de lever l’ambigu¨ıt´e de cl´es partag´ees entre des documents diff´erents par des mappings en IRI via un contexte ˆ Un m´ecanisme dans lequel une valeur dans un objet JSON peut se r´ef´erer `a un objet JSON sur un autre site sur le web ˆ La possibilit´e d’annotation des chaˆınes de caract`eres avec la langue et d’associer les types de donn´ees avec des valeurs telles que la date et l’heure ˆ La facilit´e d’exprimer un ou plusieurs graphes orient´es comme un r´eseau social en un seul document. JSON-LD est destin´e `a ˆetre utilisable directement comme JSON qui ne contient pas des connaissances de RDF. Il est ´egalement con¸cu pour ˆetre utilisable comme RDF. On peut l’utiliser avec d’autres tech- nologies de donn´ees li´ees comme SPARQL. Les projets qui ont besoin de traiter les donn´ees comme des graphes RDF vont trouver une solution avec la forme de JSON-LD. En d´etail, le document JSON-LD est Figure 2.6: Les triplets sont stock´ees dans MongoDB sous la forme de JSON-LD `a la fois un document RDF et un document de JSON et repr´esente une instance d’un mod`ele de donn´ees RDF. Cependant, JSON-LD ´etend le mod`ele de donn´ees RDF pour s´erialiser des ensembles de donn´ees RDF. Figure 2.7: Le mod`ele de composants dans un syst`eme d’association de Mon- goDB et JSON-LD – CRUD Le format de donn´ees RDF est organis´e en JSON-LD, ce qui convient au format JSON utilis´e dans MongoDB. Alors, nous pouvons profiter de la puissance de MongoDB pour r´esoudre le probl`eme de grandes donn´ees. D’ailleurs, nous facilitons la s´erialisation des donn´ees de graphes RDF dans MongoDB. La graphe de donn´ees RDF peut ˆetre organis´e et stock´e dans la m´emoire temporelle avec le support d’Application Programming Interface (API) disponibles tels que Sesame ou Jena. Ces APIs permettent d’utiliser le langage de SPARQL pour faire des requˆetes et appliquer des r`egles et faire des inf´erences sur les donn´ees. Les recherches vont directement se faire sur les graphes RDF qui sont s´erialis´es (charg´es) `a partir des donn´ees dans MongoDB, cette ´etape va prendre du temps. Nous avons alors besoin d’une m´ethode pour organiser les donn´ees importantes. Cette ´etape est importante pour optimiser le temps ex´ecution du syst`eme. En effet, nous avons les deux bases de donn´ees dans le syst`eme, 17
  28. 28. le base de donn´ees orient´ee documents et la base de triplets dans m´emoire temporelle. Ici, les op´erations CRUD vont s’ex´ecuter dans MongoDB et les recherches sont r´ealis´ees dans le graphe RDF. Alors, une couche m´ediane est n´ecessaire pour synchroniser les deux bases de donn´ees. Avantages ˆ Le stockage des donn´ees dans MongoDB sous la forme de JSON-LD est aussi la forme de donn´ees RDF. Nous pouvons donc profiter de la puissance de MongoDB dans le traitement de probl`eme de donn´ees volumineuses. ˆ Les op´erations de CRUD vont ˆetre rapidement r´ealis´ees sur les donn´ees dans MongoDB. ˆ Les requˆetes en langage SPARQL sont utilis´ees pour faire des recherches de donn´ees dans le syst`eme. Inconv´enients ˆ L’existence de deux base de donn´ees va augmenter la complexit´e du syst`eme. ˆ L’´etape de chargement des donn´ees de graphes RDF dans la m´emoire temporelle va prendre beau- coup de temps. Les mises `a jour sur les donn´ees de graphes RDFs sont d´ependantes de la base de donn´ees dans MongoDB. ˆ Le probl`eme de m´emoire temporelle avec les grands graphes RDFs, la puissance mat´erielle est importante pour ce syst`eme avec un besoin fort de m´emoires temporelles. 2.2.4 ODBA et frameworks Ontop L’ODBA est consid´er´ee comme un ´el´ement cl´e pour la nouvelle g´en´eration de syst`emes d’information, en particulier pour les applications du Web s´emantique qui impliquent une grandes quantit´es de donn´ees. L’ODBA est un paradigme d’acc`es `a des donn´ees par une couche conceptuelle. G´en´eralement, la couche conceptuelle est exprim´ee sous la forme d’une ontologie qui d´efinit un sch´ema global de haut niveau et fournit des vocabulaires pour des requˆetes d’utilisateurs. Les donn´ees sont stock´ees dans des bases de donn´ees relationnelles, des bases de triplets etc [10]. Les termes de la couche conceptuelle sont mapp´ees sur la couche de donn´ees en utilisant les mappings qui associent `a chaque ´el´ement de la couche conceptuelle, une requˆete sur les sources de donn´ees. Main- tenant, les mappings ont ´et´e formalis´ees dans la r´ecente norme Relational Databases to RDF Mapping Language (R2RML) 5 de l’organisation W3C. Cette graphe virtuelle peut ˆetre interrog´ee `a l’aide d’un langage de requˆete sur les donn´ees RDF tels que SPARQL. Un syst`eme ODBA est un triple : O = <T , S, M>, o`u[11] : ˆ T est consid´er´e comme les ontologies formalis´ees dans les Logiques de Description (DL), o`u T est un DL TBOX. ˆ S est un sch´ema des sources. ˆ M est un ensemble d’assertions des mappings, chacun de la forme : Φ(x) ← Ψ(x) Φ(x) est une requˆete sur S, retourner des tuples de valeurs pour x Ψ(x) est une requˆete sur T dont les variables libres sont de x 18
  29. 29. Figure 2.8: Le processus de requˆete dans le syst`eme d’ODBA Les syst`emes d’ODBA sont orient´e pour r´epondre aux requˆetes. Une description sch´ematique du processus de transformation de requˆete illustre dans la figure 2.8. Ici, les requˆetes pos´ees au niveau de la couche conceptuelle sont traduites dans un langage de requˆete qui peut ˆetre trait´e par la couche de donn´ees. La traduction est ind´ependante des donn´ees r´eelles dans la couche de donn´ees. De cette fa¸con, l’´evaluation de requˆete peut ˆetre d´el´egu´ee au syst`eme de gestion des sources de donn´ees. Sur la base de la conception d’ODBA, les chercheurs de l’Universti´e Bozen-Bolzano en Italie ont d´evelopp´e un Framework ODBA du nom d’Ontop. Il est utilis´e actuellement sur l’application Optique6 r´esoudre les probl`emes de Big Data. Le noyau de Ontop est le moteur de requˆete SPARQL QUEST qui impl´emente RDFS et OWL 2 QL en r´e-´ecrivant les requˆetes SPARQL sur le graphe RDF virtuelle en des requˆetes SQL (sur la base de donn´ees relationnelles). Ontop est capable de g´en´erer efficacement et de mani`ere optimis´e des requˆetes SQL [12]. Le Framwork Ontop peut ˆetre utilis´e comme : ˆ Un plugin pour Prot´eg´e 4 qui fournit une interface pour la r´edaction de mappings et l’ex´ecution de requˆetes SPARQL. ˆ Une biblioth`eque Java qui impl´emente OWL API et les interfaces API de Sesame. ˆ Un point d’acc`es SPARQL sur Sesame. (a) L’approche classique des raisonnements (b) L’approche de QUEST des raisonnements Figure 2.9: La comparaison des approches des raisonnements dans une application 5http ://www.w3.org/TR/r2rml/ 6http ://optique-project.eu/ 19
  30. 30. L’approche classique converti les bases de donn´ees en triplets. Ensuite, les requˆetes, les inf´erences seront r´ealis´ees sur ces donn´ees. Avec l’approche de QUEST, un nouveau paradigme sur les donn´ees est cr´e´e, ici, les structures de base de donn´ees ne sont pas bris´ees. Les donn´ees sont stock´ees dans un seul syst`eme. Figure 2.10: L’architecture du syst`eme avec l’association de MongoDB et le mod`ele d’ODBA Avec les limitations des bases de donn´ees relationnelles pour ls donn´ees massives, une solution propos´ee est l’associa- tion du mod`ele ODBA avec le syst`eme de gestion de base donn´ees MongoDB. Avec cette approche, nous allons profiter des avantages des MongoDB pour la gestion de grands jeux de donn´ees et du mod`ele ODBA pour cr´eer des mappings entre les donn´ees et l’ontologie. Ainsi nous pourrons faire des requˆetes et utiliser du raisonnement. Avantages ˆ La structure de donn´ees est gard´ee dans le syst`eme de gestion de base de donn´ees. Il n’y a pas de duplication de donn´ees sous forme de triplet pour faire des raisonnements. ˆ Les interrogations sur les donn´ees sont r´ealis´ees dans langage de requˆete SPARQL ˆ La capacit´e de compatibilit´e avec plusieurs syst`emes de gestion base de donn´ees relationnelles Inconv´enients ˆ La complexit´e du syst`eme va augmentent avec l’organisation des mod`eles d’ODBA ˆ L’augmentation du temps et de l’argent pour construire le syst`eme. 2.2.5 Mat´erialisation de donn´ees en triplets RDF Dans toutes les approches ci-dessus, les donn´ees sont organis´ees et stock´ees dans des syst`emes de gestion de base de donn´ees orient´es graphe Neo4j ou des syst`emes bases de donn´ees orient´es documents MongoDB ou des syst`emes hybrides d’association de MongoDB et des syst`emes de gestion de base de donn´ees de triplets RDF. Toutefois, l’impl´ementation de requˆetes sur les donn´ees avec le langage SPARQL a plusieurs limitations. Dans cette partie, nous allons d´ecouvrir une autre approche sur les donn´ees. C’est la mat´erialisation de donn´ees en triplets. Les donn´ees seront converties en triplets RDF. Cette approche est maintenant la meilleure solution pour l’organisation des donn´ees avec des capacit´es de raisonnements. Le plus souvent, lorsque l’on commence `a vouloir publier des donn´ees sur des bases de connaissances comme RDF il existe d´ej`a une base de donn´ees. Pour que l’on puisse utiliser les donn´ees en RDF, il faut 20
  31. 31. les traduire en triplets. Il existe plusieurs m´ethodes mais la plus utilis´ee est la suivante : Database To RDF (D2R)7 a pour but de traduire toutes les donn´ees contenues dans une base de donn´ees en triplets RDF. D2R fonctionne avec un fichier de mapping et une ou plusieurs ontologies. Le fichier de mapping sert `a faire la liaison entre les tables et les champs contenus dans ces tables et les classes et les propri´et´es dont sont compos´ees ou les ontologies que l’on utilise. Ainsi, apr`es le mapping, les donn´ees correspondront `a la ou les ontologies sp´ecifi´ees et, ensuite seront disponibles sur une application Web s´emantique par l’interm´ediaire d’une interface Web et d’un point d’acc`es SPARQL Figure 2.11: Les deux tables et sa relation Figure 2.12: Les informations d´efinies pour le mapping Figure 2.13: Les donn´ees RDF apr`es de la transformation Il existe maintenant deux m´ethodes pour map- per une base de donn´ees : R2RML8 et Direct Mapping9 . Ainsi avec ces deux m´ethodes il est possible d’int´egrer toutes les donn´ees d’une base SQL au Web de donn´ees, de les manipuler avec SPARQL et de les interconnecter avec d’autres jeux de donn´ees pr´esents sur le Web de donn´ees. Le Direct Mapping d´efinit une transfor- mation simple, fournissant une base pour la d´efinition et la comparaison des transformations plus complexes. Il peut ´egalement ˆetre utilis´e pour mat´erialiser des graphes RDF ou d´efinir des graphes virtuels. Ces graphes peuvent ˆetre in- terrog´es en SPARQL ou grˆace `a une API RDF. En ce qui concerne R2RML [13], c’est un lan- gage pour exprimer des mappings `a partir d’une base de donn´ees relationnelles et des ensembles de donn´ees RDF. Ces mappings fournissent des ca- pacit´e de visualisation des donn´ees relationnelles existantes en repr´esentation RDF. Avec les trois figures dans cette section, nous pouvons voir un exemple de ces mappings de donn´ees relation- nelles et de triplets. Ici, sur la base des relations entre les tables (Figure 2.11), nous allons d´efinir un fichier pour mapper des informations dans et entre les tables (Figure 2.12) aux sujet, pr´edicat et objet de triplets (Figure 2.13). Toutefois, ces deux approches existe seulement pour des bases donn´ees relationnelles. Donc, il y a la n´ecessit´e d’utiliser la mˆeme id´ee pour mapper des triplets RDF avec des bases de donn´ees orient´ees documents. Franck Michel et ses coll`eges [14] se 7http ://d2rq.org/ 8http ://www.w3.org/TR/r2rml/ 9http ://www.w3.org/TR/rdb-direct-mapping/ 21
  32. 32. sont bas´es sur le langage de mapping R2RML et Morph-RDB10 qui est une impl´ementation du langage de mapping R2RML pour les donn´ees relationnelles, pour d´evelopper xR2RML qui est s’applique aux bases de donn´ees orient´ees documents comme MongoDB. En particulier, xR2RML est une extension de la langage de mapping R2RML et s’appuie sur certaines propri´et´es du langage de mapping RDF Mapping Language (RML) [15] et. R2RML porte sur les mappings de base de donn´ees relationnelles aux triplets RDF. RML ´etend R2RML pour aborder les mappings sur des donn´ees h´et´erog`enes (XML, JSON, CSV) avec des triplets RDF. xR2RML ´etend ce champ d’application `a un plus large ´eventail de base de donn´ees non-relationnelles. Avantages ˆ Les donn´ees sont converties en triplets. Nous pouvons donc utiliser les syst`emes de gestion de base de donn´ees RDF sp´ecifiques. ˆ Les interrogations sur les donn´ees sont r´ealis´ees par langage de requˆete SPARQL ˆ Les capacit´es de raisonnement sont parfaitement soutenues par ces syst`emes de gestion de base de donn´ees RDF. Inconv´enients ˆ L’´etape de transformation de donn´ees est coˆuteuse en temps : r´e-organisation des donn´ees en graphe ˆ Le nouveau syst`eme avec ses donn´ees a besoin d’une nouvelle architecture pour ˆetre mis en œuvre. Le syst`eme est ind´ependant de l’existant. ˆ On rencontre des probl`emes de performance avec les donn´ees volumineuses 2.3 Conclusion Dans cette partie, nous avons fait l’´etat de l’art des approches pour r´esoudre le probl`eme de donn´ees massives et des recherches au niveau Web s´emantique. Pour r´esumer il y a deux approches principales : la transformation de donn´ees en triplets RDF avec l’association de AllegroGraph et de MongoDB, de Neo4J, de JSOn-LD et de MongoDB. Il y a aussi l’utilisation d’un langage de mapping comme xR2RML et la transformation de requˆetes ou la r´e-´ecriture des requˆetes avec ODBA et Ontop Framework. On peut voir que pour chaque approche il existe des avantages et des inconv´enients. Il faudra donc, sur la base des caract´eristiques de l’organisation des donn´ees et de l’objectif d’utilisation de donn´ees, choisir la meilleure solution pour les donn´ees. 10https ://github.com/oeg-upm/morph-rdb 22
  33. 33. Chapitre 3 Solution propos´ee 3.1 Introduction La partie pr´ec´edente donne une vue g´en´erale de diff´erentes solutions pour aider `a traiter un gros volume de donn´ees et renforcer la capacit´e d’association en structurant les donn´ees aux triplets RDF pour que le but final soit l’am´elioration de capacit´e de partage, d’int´egration et de recherche des donn´ees. Dans cette partie, nous allons pr´esenter la solution sur la base d’une mat´erialisation de donn´ees sous forme de triplets. Dans ce chapitre, nous aborderons dans la premi`ere section le choix de la repr´esentation du mod`ele donn´ees et la mani`ere de le g´en´erer. Ensuite, dans la section suivante sera abord´ee une d´emarche entreprise pour transformer des donn´ees du mod`ele relationnel aux format JSON. De plus, une ontologie sera pr´esent´ee pour d´ecrire les vocabulaires n´ecessaires dans la la conception du modele RDFs. En fin, le langage de transformation de donn´ees en RDF sera introduit avec les syntaxes pour cr´eer les mapping et convertir des documents JSON en triplets RDF. 3.2 Mod`ele g´en´eral L’approche de mat´erialisation de donn´ees en triplets RDF a ´et´e choisie afin de tester l’organisation et la performance des triplestores sur de gros volume donn´ees. Les syst`emes actuels stockant de gros volumes sont en majorit´e partag´es entre des syst`emes NoSQL (e.g : Mongodb), relationnels et divers format. L’un des objectifs de ce travail ´etait l’organisation et la synchronisation des donn´ees en conservant leur provenance et les syst`emes existants en ayant MongoDB comme stockage interm´ediaire. Par la suite, les donn´ees seront converties en triplets RDF grace a l’utilisation du langage de mapping xR2RML et l’outil d´evelopp´e par les auteurs [14]. Les vocabulaires et les r`egles de transformation de triplets sont fournis par une ontologie. Cette ontologie est importante pour r´ealiser des recherches avanc´ees sur les relations et les hi´erarchies existantes . Aujourd’hui, il existe diff´erents syst`emes qui permettent de g´erer les donn´ees RDF. Nous allons focali- ser notre etude sur cinq syst`emes : 4Store, Sesame, Virtuoso, Stardog, GraphDB(OWLIM) et Jena Fuseki. Leurs m´ecanismes d’action et d’indexation de donn´ees ´etant diff´erents, nous allons tester ces syst`emes avec des donn´ees volumineuses. Ainsi, r´ealiserons les tests de ces syst`emes sur la capacit´e de gestion de 23
  34. 34. donn´ees RDF afin d’optimiser le stockage et pour la r´ecup´eration de ces triplets `a l’aide du langage de requˆete SPARQL. Le moteur de recherche va consister `a utiliser la capacit´e d’inf´erence sur la base contenant l’ontologie et les donn´ees RDF. Une interface est fournie pour effectuer les requˆetes sur ces donn´ees. Les interrogations sous la forme de langage SPARQL sont utilis´ees pour chercher les donn´ees n´ecessaires dans la base de donn´ees. L’illustration d´etaill´ee du mod`ele est pr´esent´e dans la figure 3.1 suivante : Figure 3.1: Le mod`ele g´en´eral du syst`eme 3.3 Transformation et synchronisation de donn´ees dans Mon- goDB Dans le projet Phenome (INRA), plusieurs syst`emes de capteurs alimentent des bases de donn´ees relationnelles en permanence. Il y a une fort besoin de synchronisation de ces donn´ees avec le syst`eme courant. L’´etape de transformation de donn´ees en documents JSON est r´ealis´ees afin d’int´egrer plusieurs ressources dans un meme entrepˆot. Dans la suite du memoire nous nous concentrons seulement sur les donn´ees obtenues dans sur les processus d’imageries, d’arrosage, de pes´ees ceux que les chercheur ont r´ealis´es quotidiennement. Afin de garantir la coh´erence des donn´ees entre les ressources et les processus qui les g´en`erent, des mod`eles ont ´et´e d´efinis. La d´efinition des mod`eles JSON est r´ealis´ee pour mapper les propri´et´es de plusieurs tables de base de donn´ees relationnelles avec les cl´es - valeurs dans les documents JSON. Seules les propri´et´es importantes et les relations entre les tables ont ´et´e conserv´ees. La figure 3.2, repr´esente un exemple de mod`ele d´efini en JSON pour les donn´ees imageries construits `a partir les trois tables diff´erentes : Images, Imgacqcameraprofiles et Imagacstationprofiles. Ces tables correspondent comme leur nom l’indique aux donn´ees images (horodatage, format, etc), aux profils cam´era (balance des blancs, saturation, etc,) ainsi qu’aux profils des cabines d’imageries (lumi`eres, etc ..). Dans ce nouveau document JSON sont repr´esent´es des donn´ees fix´ees par les syst`emes existants et des nouvelles donn´ees calcul´ees a 24
  35. 35. partir de traitements resultant de leur int´egration. 1 Image{ 2 "plant" : URI, 3 "plantAlias" : string, 4 "genotype" : URI, 5 " genotypeAlias " : string, 6 "experiment" : URI, 7 " experimentAlias " : string, 8 "study" : URI, 9 "studyAlias" : string, 10 "platform" : "http:// www.phenome -fppn.fr/m3p/", 11 " technicalPlateau " : "http:// www.phenome -fppn.fr/m3p/", 12 "timestamp" : int, 13 "date" : date, 14 " configuration " : { 15 "provider" : " phenowaredb", 16 "imgid" : int, 17 "plantid" : int, 18 "studyname" : string, 19 "taskid" : int, 20 "stationid" : int, 21 " imgacqprofileid " : int, 22 " nextLocation " : { 23 "lane" : int, 24 "rank" : int, 25 "level" : int, 26 } 27 }, 28 " userValidation " : boolean, 29 " isReferenceImage " : boolean, 30 "viewType" : string, 31 " cameraAngle " : int, 32 "fileName" : string, 33 "serverPath" : "http://stck -lespe.supagro.inra.fr/", 34 " imageServerPath " : URI, 35 " imageWebPath " : URI, 36 " thumbServerPath " : URI, 37 " thumbWebPath " : URI, 38 " binaryServerPath " : " unspecified ", 39 " binaryWebPath " : "unspecified", 40 } Figure 3.2: Le mod`ele JSON cr´e´e `a partir des bases d’imageries Dans quelques semaines `a l’issus de ce stage, une application1 sera mise en œuvre pour convertir automatique toutes les donn´ees dans la base de donn´ees relationnelles aux document de JSON sur la base d’un mod`ele d´efini comme la figure 3.2. Les donn´ees, qui seront concern´ees par les processus de mesures des plantes selon trois aspects d’imageries, d’arrosages, de pes´ees, seront converties sous forme de documents de JSON. On peut voir les autres mod`eles qui sont compl`etement d´efinies dans l’Annexe A. Aujourd’hui, toutes les donn´ees obtenues apr`es la transformation seront synchronis´ees et stock´ees dans le syst`eme MongoDB. La centralisation de donn´ees dans un seul syst`eme nous aide commod´ement `a d´efinir les mod`eles g´en´eraux pour la transformation de donn´ees en RDF. 1https ://github.com/lengocluyen/phenowaredb-to-mongodb-convertor 25
  36. 36. 3.4 Ontologies et domaine applicatif Figure 3.3: L’ontologie de l’annotation d’images Les diff´erences entre des processus d’imageries, d’arrosage et de pes´ees demandent un diversit´e de vocabulaires pour les d´ecrire. Dans cette section, nous nous focalisons sur des vocabulaires de description des donn´ees, des m´eta-donn´ees du processus d’imageries. Dans ce processus, de tr`es nombreuses images de plantes sont cr´e´ees et doivent ˆetre stock´ees et ˆetre partag´ees. Une annotation d’images est n´ecessaire pour fournir les m´eta-donn´ees afin d’aider compr´ehension et l’interpr´etation de l’image. En g´en´eral, plusieurs vocabulaires sont d´ej`a disponibles pour faire de l’annotation d’images [16]. par exemple, EXIF 2 est le format d’images de la plupart des appareils photo num´eriques. Il contient des 2https ://fr.wikipedia.org/wiki/Exchangeable imag file format 26
  37. 37. m´eta-donn´ees pour la date, l’heure, la localisation etc . Dublin Core3 fournit des vocabulaire de taille r´eduite pour la description de ressources multim´edia. Il recouvre ainsi les concepts de titre, cr´eateur, date, format etc. Ces vocabulaires fournissent les ´el´ements n´ecessaires pour d´efinir un mod`ele, mais ne conviennent pas compl`etement pour les images trait´ees dans ce projet. Afin de prendre en compte ces sp´ecificit´es l’´equipe INRA a construit une ontologie d’annotation d’images [17]. On peut voir en d´etail le sch´ema de cette ontologie dans la figure 3.3. 3.5 xR2RML et Transformation de donn´ees en triplets 3.5.1 Le langage de mapping de donn´ees xR2RML Apr`es l’´etape de transformation de donn´ees en JSON et leur importation dans MongoDB, il est n´ecessaire de les transformer en triplets RDF. Pour cela, nous allons utiliser le langage de mapping xR2RML pour transformer ces donn´ees en triplets RDF. Dans la partie de ”Mat´erialisation de donn´ees aux triplets” du chapitre pr´ec´edant, nous avons introduit ce langage. Nous verrons plus en detail dans cette section la syntaxes pour cr´eer le mapping entre un document JSON et la declaration des triplets RDF. Un mapping de triplet de xR2RML utilise une r´ef´erence sur la source logique au lieu d’une table logique dans R2RML. En particulier, le mapping xR2RML consist `a : ˆ Une propri´et´e xrr :logicalSource. Son objet est une source logique qui sp´ecifie une table ou un r´esultat de requˆete pour ˆetre mapp´e avec un triplet. ˆ Un mapping de sujet qui pr´ecise comment g´en´erer un sujet pour chaque ´el´ement de donn´ees de la source logique (par exemple : une ligne de table, un document de collection, un ensemble d’´el´ements XML etc). Ce mapping peut ˆetre sp´ecifi´e dans deux fa¸cons suivantes : En utilisant la propri´et´e rr :SubjectMap, dont la valeur doit ˆetre le mapping de sujet En utilisant la propri´et´e constante rr :subject ˆ Sans, une ou plusieurs propri´et´es rr :predicateObjectMap, dont les valeurs doivent ˆetre le mapping de pr´edicate - objet. Ces mapping pr´ecisent les paires pr´edicat et objet qui, avec les sujets g´en´er´es par le mapping de sujet, peuvent former un ou plusieurs triplets RDF pour chaque ´el´ement de donn´ees. 1 { "studyid": 10, 2 "acronym": "CAC2010", 3 "centres": [ { 4 "centreid": 4, 5 "name": "Hopital Lapeyronie" 6 },{ 7 "centreid": 6, 8 "name": " Pontchaillou " } 9 ] 10 } Figure 3.4: Un exemple de donn´ees dans MongoDB 3https ://fr.wikipedia.org/wiki/Dublin Core 27
  38. 38. 1 <http:// example.org/study#10> st:involves 2 [ a rdf:Seq; 3 rdf:_1 "Hopital Lapeyronie "; 4 rdf:_2 " Pontchaillou "; 5 ]. Figure 3.5: Le triplet g´en´er´e 43 <#Study > 44 xrr: logicalSource [ 45 xrr:query ’’’db.studies.find( 46 { studyid:{ $exists:true } }) ’’’; 47 xrr:format xrr:JSON; 48 ]; 49 rr:subjectMap [ 50 rr:class st:study; 51 rr:template "http:// example.org/study#{$.studyid}"; 52 ]; 53 rr: predicateObjectMap [ 54 rr:predicate st:involves; 55 rr:objectMap [ 56 xrr:reference "$.centres .*. name" ]; 57 rr:termType xrr:RdfSeq; 58 ]; Figure 3.6: Le mapping de xR2RML Les figures 3.4, 3.5, 3.6 illustrent un exemple simple sur les donn´ees JSON stock´ees dans MongoDB, la d´efinition du mapping des propri´et´es et les r´esultats obtenus. Dans le mapping de donn´ees, il y a des termes qui sont d´efinies dans R2RML ou xR2RML que l’on peut l’identifier par le pr´efixe : rr :, rrx : etc. Dans xR2RML, le mapping de terme (Term maps) est d´efini comme une fonction qui g´en`ere des termes RDF `a partir d’une ligne de la table logique. Il est soit un mapping de sujet, de pr´edicat, d’objet ou de graphe. En particulier, un mapping de terme peuvent ˆetre exactement l’un des suivants : une valeur constante (la propri´et´e rr :constant), une valeur de colonne (la propri´et´e rr :column elle peut se remplacer par rml :reference ) et une valeur du template (la propri´et´e rr :template). Il existe plusieurs mappings de termes que l’on peut enti`erement voir dans [14]. Avec les caract´eristiques de ce langage, un outil4 est d´evelopp´e pour transformer automatiquement des donn´ees relationnelles en triplets sur la meme base de mapping entre les deux. Cet outil est un syst`eme qui, ´etant donn´ee un mapping xR2RML et une base de donn´ees d’entr´ee, fournit un acc`es `a la sortie d’ensemble de donn´ees RDF. Il a l’acc`es `a un environnement d’ex´ecution comprenant : une connexion `a la base de donn´ees d’entr´ee. Une formulation de r´ef´erence applicable aux r´esultats des requˆetes ex´ecut´ees sur la connexion. 3.5.2 Transformation de donn´ees en triplets Sur la base du langage de mapping xR2RML et l’outil d´evelopp´e, La d´efinition du mapping est cr´e´e pour mapper les propri´et´es d’un document JSON avec des triplets. les vocabulaires de ces triplets sont 4https ://github.com/frmichel/morph-xr2rml/releases 28
  39. 39. fournis par l’ontologies ci-dessus. Dans la figure 3.7, les propri´et´es du document JSON d’images (les autres sont d´efinis dans l’Annexe B) vont ˆetre mapp´ees aux sujets, pr´edicat et objet du triplet. Apr`es cette ´etape, nous avons obtenu 45 de millions de triplets pour l’annotation d’images `a partir d’environ 3.5 millions d’images contenues dans le syst`eme MongoDB. Cette transformation `a n´ecessit´e beaucoup de temps d’execution cot´e serveur `a l’INRA (environ 20 heures). Ces donn´ees existent sous la forme d’un graphe avec plusieurs instances. 1 @prefix xrr: <http://i3s.unice.fr/xr2rml#> . 2 @prefix rr: <http://www.w3.org/ns/r2rml#> . 3 @prefix ex: <http:// example.com/> . 4 @prefix rml: <http:// semweb.mmlab.be/ns/rml#> . 5 @prefix xsd: <http:// www.w3.org/2001/XMLSchema #> . 6 @prefix rdfs: <http://www.w3.org/2000/01/rdf - schema#> . 7 @prefix rdf: <http:// www.w3.org/1999/02/22-rdf - syntax -ns#> . 8 @prefix f: <http://www.franz.com/> . 9 @prefix ia: <http:// www.mistea.supagro.inra.fr/ ontologies/2015/03/ imageAnnotation #> . 10 <#Image > a rr:TriplesMap; 11 xrr: logicalSource [ 12 xrr:query """db.image.find({ ’configuration . imgid ’ : {$exists: true} } )"""; 13 ]; 14 rr:subjectMap [ 15 rr:template "{$.uri}"; 16 rr:class ia:Image; 17 ]; 18 rr: predicateObjectMap [ 19 rr:predicate ia:aboutEntity ; 20 rr:objectMap [ xrr:reference "$.context.plant "; ]; 21 rr:class ia:Plant; 22 ]; 23 rr: predicateObjectMap [ 24 rr:predicate ia:timeStamp; 25 rr:objectMap [ xrr:reference "$.date "; ]; 26 rr:datatype xsd:date; 27 ]; 28 rr: predicateObjectMap [ 29 rr:predicate ia:hasFileName ; 30 rr:objectMap [ xrr:reference "$.fileName "; ]; 31 rr:datatype xsd:string; 32 ]; 33 rr: predicateObjectMap [ 34 rr:predicate ia:hasPlateau; 35 rr:objectMap [ xrr:reference "$.context. technicalPlateau "; ]; 36 rr:class ia: TechnicalPlateau ; 37 ]; 38 rr: predicateObjectMap [ 39 rr:predicate ia: inImagingCycle ; 40 rr:objectMap [ xrr:reference "$. configuration . taskid "; ]; 41 rr:datatype xsd:integer; 42 ]; 43 rr: predicateObjectMap [ 44 rr:predicate ia:hasPlateau; 45 rr:objectMap [ xrr:reference "$.context. technicalPlateau "; ]; 46 rr:class ia: TechnicalPlateau ; 47 ]; 48 rr: predicateObjectMap [ 49 rr:predicate ia: inImagingCycle ; 50 rr:objectMap [ xrr:reference "$. configuration . taskid "; ]; 51 rr:datatype xsd:integer; 52 ]; 53 rr: predicateObjectMap [ 54 rr:predicate ia: inAutomatonStudy ; 55 rr:objectMap [ xrr:reference "$. configuration . studyname "; ]; 56 ]; 57 rr: predicateObjectMap [ 58 rr:predicate ia: inExperiment ; 59 rr:objectMap [ xrr:reference "$.context. experiment "; ]; 60 rr:class ia:Experiment; 61 ]; 62 rr: predicateObjectMap [ 63 rr:predicate ia: hasCameraAngle ; 64 rr:objectMap [xrr:reference "$. cameraAngle ";]; 65 rr:datatype xsd:integer; 66 ]; 67 rr: predicateObjectMap [ 68 rr:predicate ia:hasViewType; 69 rr:objectMap [ xrr:reference "$.viewType "; ]; 70 ]; 71 rr: predicateObjectMap [ 72 rr:predicate ia: isReferenceImage ; 73 rr:objectMap [ xrr:reference "$. isReferenceImage "; ]; 74 rr:datatype xsd:boolean; 75 ]; 76 rr: predicateObjectMap [ 77 rr:predicate ia: hasCameraProfile ; 78 rr:objectMap [ xrr:reference "$. imageCameraProfile "; ]; 79 rr:class ia: CameraProfile ; 80 ]; 81 rr: predicateObjectMap [ 82 rr:predicate ia: hasAcquisitionStationProfile ; 83 rr:objectMap [ xrr:reference "$. imageStationProfile "; ]; 84 rr:class ia: AcquisitionStationProfile ; 85 ]. Figure 3.7: Le Mapping de donn´ees JSON en triplets 29
  40. 40. 3.6 Conclusion Dans cette partie, la d´efinition du mod`ele de solution propos´ee est pr´esent´ee avec les ´etapes que nous allons r´ealiser pour la construction d’un syst`eme de connaissance. En d´eveloppant l’outil de trans- formations de donn´ees relationnelles en document JSON stock´ees dans MongoDB et en utilisant l’outil xR2RML pour la transformation de donn´ees JSON en triplets, nous avons obtenu des graphes RDF tr`es volumineuses. Avec ces graphes, nous avons besoin d’un syst`eme de gestion de base de donn´ees pour le g´erer de mani`ere efficace. Ceci sera pr´esent´e dans la partie prochaine. 30
  41. 41. Chapitre 4 Stockage et Indexation de donn´ees RDF 4.1 Introduction Avec les donn´ees obtenues dans la chapitre pr´ec´edent, on a besoin d’avoir un meilleur syst`eme pour les organiser et les stocker. Il existe actuellement plusieurs syst`emes d´evelopp´es pour les donn´ees RDF mais chaque syst`eme a des caract´eristiques sp´ecialis´ees concernant l’organisation et l’indexation des donn´ees. Alors, on a besoin d’effectuer des tests sur la capacit´e de stockage, sur l’indexation, sur la performance, sur l’optimisation du processus de chargement, des requˆetes et des raisonnements de ces syst`emes. Ce chapitre introduit des m´ethodes d’organisation pour stocker et indexer les donn´ees RDF et l’impl´ementation de ces donn´ees dans quelques syst`emes courants. Plus pr´ecis´ement, la premi`ere sec- tion pr´esentera les deux approches d’organisation de donn´ees : sous la forme native qui construit un nouveau syst`eme pour g´erer les donn´ees par soi-mˆeme et sous la forme non-native qui utilise un syst`eme de gestion de donn´ees existant pour stocker les donn´ees. Dans la deuxi`eme partie, il y aura une intro- duction `a des entrepˆots de donn´ees RDF ou “TripleStore” r´ecents : l’architecture, les caract´eristiques de chaque syst`eme et aussi l’impl´ementation du stockage des donn´ees ces syst`emes. Enfin, la repr´esentation d’une application pour acc´eder `a des donn´ees issues de plusieurs sources sur la base d’un point d’acc`es. 4.2 Approche native et non-native L’approche native fournit un moyen pour stocker des donn´ees RDF plus proche du mod`ele de donn´ees. Il utilise la nature des triplets RDF et permet d’aborder les sp´ecificit´es de son approche en graphe, tels que la capacit´e `a g´erer la parcimonie des donn´ees et l’aspect dynamique de son sch´ema. Ces syst`emes peuvent ˆetre class´es en deux types de stockage (la figure 4.1) : `a base de disque qui est persistant ou `a base de m´emoire qui est volatile. Le stockage persistant sur le disque est un moyen de stocker en permanence des donn´ees RDF sur un syst`eme de fichiers. Ces impl´ementations peuvent utiliser des structures d’index comme des arbres B+ par exemple. N´eanmoins, l’´ecriture et la lecture sur les disques peuvent provoquer un ph´enom`ene de goulot d’´etranglement 31
  42. 42. dans le syst`eme. Alors, la solution de stockage des donn´ees en m´emoire est `a consid´erer pour ´eviter ce ph´enom`ene. Le stockage des donn´ees RDF en m´emoire alloue une certaine quantit´e de la m´emoire prin- cipale disponible pour stocker l’ensemble de la structure de graphe RDF. Comme le stockage persistant sur le disque, ce stockage repose sur des techniques d’indexation. Avec les donn´ees stock´ees dans la m´emoire, certaines op´erations seront coˆuteuses en temps : le chargement, l’analyse ou ”parsing” de fi- chier de donn´ees RDF et aussi la cr´eation d’index. Par cons´equent, un Triplestore RDF doit avoir une repr´esentation de donn´ees en m´emoire efficace qui laisse suffisamment d’espace pour les op´erations de requˆetes et de gestion de donn´ees. Figure 4.1: La classificaiton des types de syst`eme de stockage RDF L’approche non-native utilise un syst`eme de gestion de base de donn´ees pour stocker des donn´ees RDF de fa¸con permanente. On profite du d´eveloppement de plusieurs ann´ees de ces syst`emes, par exemple, la capacit´e de transactions ou de s´ecurit´e. Avec les syst`emes de gestion de base de donn´ees relationnelles, on peut distinguer la base de donn´ees avec sch´ema et la base de donn´ees sans sch´ema. Avec la base de donn´ees avec sch´ema, les caract´eristiques du sch´ema sont utilis´ees pour s´eparer des triplets en diff´erentes tables. Cette s´eparation peut ˆetre organis´ee sur la base de structure intrins`eque de triplets : le sujet, le pr´edicat et l’objet, ou fond´ee sur les propri´et´es, les classes RDFS ou OWL. On a les trois fa¸cons d’organisation de sch´ema : partitionnement vertical, table de propri´et´es et table de propri´et´es hi´erarchiques. Avec la base de donn´ees sans sch´ema, on utilise seulement des tables qui sont responsables du stockage de tous les triplets, c’est ce que l’on appelle une table de triplet. Ces derni`eres ann´ees, les syst`emes de gestion de base de donn´ees ´emergent comme une bonne approche pour les donn´ees massives avec plusieurs mani`eres d’organisation de donn´ees : cl´e-valeur, orient´e document, orient´e colonne, orient´e graphe, etc. La motivation principale est de r´epondre `a la distribution de grands ensembles de donn´ees sur un cluster de mat´eriel. Dans l’approche non-native, les triplets sont parfaitement stock´ees avec l’impl´ementation d’indexa- tion, le support des propri´et´es ACID (Atomicit´e, Coh´erence, Isolation et Durabilit´e) et les optimisations de requˆetes de chaque syst`eme (SQL pour les base de donn´ees relationnelles, Cypher pour Neo4J etc). N´eanmoins, l’association de deux mod`eles de donn´ees (par exemple mod`ele en graphe et mod`ele relation- nelle) a besoin de manipulations, de la synchronisation entre eux, on par exemple de transformation de donn´ees, des requˆetes SPARQL en SQL. Cela est coˆuteux en temps d’ex´ecution et de transformation de requˆetes. On a encore des limitations sur la capacit´e d’inf´erence sur les donn´ees. Dans l’approche native, on utilise des syst`emes de gestion de base de donn´ees sp´ecialis´es pour les donn´ees RDF. Les donn´ees sont 32

×