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

UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL LÊ NGỌC LUYỆN DÉVELOPPEMENT D’UN SYSTÈME CONNAISSANCE POUR BIG DATA APPLICATION AUX DONNÉES DE PHÉNOTYPAGE CHEZ LE RIZ (O SATIVA) PHÁT TRIỂN MỘT HỆ NHẬN DẠNG CHO DỮ LIỆU LỚN: ỨNG DỤNG CHO DỮ LIỆU PHENOTYPING VỀ LÚA (O SATIVA) MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE HANOI – 2015 UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL LÊ NGỌC LUYỆN DÉVELOPPEMENT D’UN SYSTÈME CONNAISSANCE POUR BIG DATA APPLICATION AUX DONNÉES DE PHÉNOTYPAGE CHEZ LE RIZ (O SATIVA) PHÁT TRIỂN MỘT HỆ NHẬN DẠNG CHO DỮ LIỆU LỚN: ỨNG DỤNG CHO DỮ LIỆU PHENOTYPING VỀ LÚA (O SATIVA) Spécialité: Systèmes intelligents et Multimédia Code: Programme pilote MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE Sous la direction de: Ingénieur IRD, responsable de l’AXE Intégration de données de l’Institut de Biologie Computationnelle, Dr Pierre LARMANDE Ingénieur INRA, Mme Anne TIREAU HANOI – 2015 ATTESTATION SUR L’HONNEUR J’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les données et les résultats qui y sont présentés sont exacts et n’ont jamais été publiés ailleurs La source des informations citées dans ce mémoire a été bien précisée LỜI CAM ĐOAN Tôi cam đoan công trình nghiên cứu riêng Các số liệu, kết nêu Luận văn trung thực chưa công bố công trình khác Các thông tin trích dẫn Luận văn rõ nguồn gốc Fait Hano¨ı, le 20 octobre 2015 Hà nội, Ngày 20 tháng 10 năm 2015 Lê Ngọc Luyện i Remerciements Je tiens ` a remercier dans un premier temps, toute l’´equipe p´edagogique de l’Institut Francophone International (IFI) de Hano¨ı et les intervenants professionnels responsable de la formation en master de recherche en informatique, pour avoir assur´e la partie th´eorique de celle-ci Je tiens ` a exprimer toute ma reconnaissance `a M Pierre LARMANDE qui est chercheur `a l’IRD et Reponsbale de l’axe de donn´ees de l’Institut de Biologie Computationnelle, Mme Anne TIREAU qui est ing´enieur ` a l’INRA Montpellier SupAgro dans l’UMR MISTEA, pour leur encardrement sans faille, le suivi qu’ils ont apport´e ` a mon stage, leurs conseils, les nombreuses discussions que nous avons pu avoir tout au long de la r´ealisation de ce stage, aussi pour l’inspiration et pour le temps qui’ils ont bien voulu me consacrer Je souhaite remercie la famille de Pierre LARMANDE et la famille Fran¸cois PHAN pour leurs aides chaleureuses pendant mon s´ejour de six mois en France Je tiens ` a remercie ´egalement Mlle Caroline BENOIST secr´etaire du LIRMM, et Mlle NGUYEN Thi Van Tu, secr´etaire de l’IFI pour ses aides `a plusieurs reprises Depuis mes premiers jours dans cet institut, j’ai re¸cu beaucoup d’aides, de conseils et d’encouragements de mes amis, en particulier ceux de la promotion 18 Tout cela m’a permis de murir chaque jour Je les remercie et je ne pourrais jamais oublier les souvenirs gais et tristes que j’ai pass´e avec eux durant ces deux ans ` a l’IFI Je voudrais aussi remercier aussi les confr`eres de l’Universit´e de Da Lat o` u je suis en train de travailler, qui m’ont donn´e les meilleures conditions pour que je puisse bien passer ma scolarit´e `a l’IFI Enfin, j’adresse mes plus sinc`eres remerciements `a mes parents, mes fr`eres qui m’a toujours soutenue et encourag´ee dans les moments les plus difficiles de ma scolarit´e `a l’IFI Merci ` a tous et ` a toutes LE Ngoc Luyen Da Lat - Viet Nam, automne 2015 ii R´ esum´ e Depuis quelques ann´ees, le d´eluge de donn´ees dans plusieurs domaines de la recherche scientifique soul`eve des d´efis dans le traitement et l’exploitation des donn´ees La recherche dans le domaine bioinformatique n’est pas ´epargn´ee par ce ph´enom`ene Ce m´emoire pr´esente des approches pour r´esoudre le probl`eme de donn´ees volumineuses stock´ees dans des entrepˆots NoSQL en y associant la capacit´e de recherche s´emantique sur les donn´ees dans un contexte de recherche agronomique Ces approches s´emantiques permettent d’aider ` a enrichir les donn´ees issues d’exp´eriences grˆace aux moteurs d’inf´erence g´en´erant de nouvelles connaissances Nous pouvons r´esumer ces deux approches d’une part avec la r´e´ecriture de requˆetes et d’autre part avec la mat´erialisation de donn´ees en triplets RDF Un ´etat de l’art nous a permis d’identifier et d’´evaluer les diff´erentes m´ethodes se rapportant aux approches mentionn´ees En pratique, seule l’approche de mat´erialisation de donn´ees a ´et´e choisie pour continuer `a travailler Les donn´ees triplets obtenues ´etant volumineuses, nous avons r´ealis´e un benchmark sur diff´erents syst`emes de gestion de base de donn´ees de triplets afin de pouvoir comparer les avantages et les inconv´enients de chacun et de choisir le meilleur syst`eme pour notre ´etude de cas Mot-cl´ es : Base de connaissance, Ontologie, Raisonnement, Inf´erence, SPARQL, xR2RML, Benchmark, NoSql, BigData, TripleStore iii Abstract In the recent years, the data deluge in many areas of scientific research brings challenges in the treatment and improvement of farm data Research in bioinformatics field does not outside this trend This thesis presents some approaches aiming to solve the big Data problem by combining the increase in semantic search capacity on existing data in the plant research laboratories This helps us to strengthen user experiments on the data obtained in this research by the engine automatic inference of new knowledge To achieve this, each approach has different characteristics and using different platforms Nevertheless, we can summarize it in two main directions : the transformation of query or Re-write requests and data transformation to triples In reality, we can solve the problem from origin of increasing capacity on semantic data with triplets Thus, the triplets to data transformation direction is chosen to continue working in the practical part However, the synchronization data in the same format is required before processing the triplets because our current data are heterogeneous The data obtained for triplets are larger that regular triplestore could manage So we evaluate some of them thus we can compare the benefits and drawbacks of each and choose the best system for our problem Keyworks : Knowledge base, Ontology, Reasoning, Inference, SPARQL, xR2RML, Benchmark, NoSQL, Big Data, Triplestore iv Table des mati` eres Remerciements ii R´ esum´ e iii Abstract iv Table des mati` eres v Liste d’abr´ eviations vii Table des figures viii Liste des tableaux x INTRODUCTION Chapitre 1.1 Pr´ esentation G´ en´ erale Pr´esentation de l’´etablissement d’accueil 1.1.1 Pr´esentation de l’Institut de Biologie Computationelle (IBC) 1.1.2 Pr´esentation de l’Institut National de la Recherche Agronomique (INRA) 1.2 Description du stage 1.3 Probl´ematiques 1.4 Contexte du sujet 1.4.1 Contexte de donn´ees massives 1.4.2 Contexte de recherche s´emantique Chapitre ´ Etat de l’art 11 2.1 Existants 11 2.2 Analyse et ´evaluation des solutions courantes 11 2.2.1 MongoGraph - une association du Mongodb et AllegroGraph 11 2.2.2 Base de donn´ees orient´ee graphe Neo4j 15 2.2.3 JSON for Linking Data (JSON-LD) et MongoDB 16 2.2.4 Ontology-Based Data Access (ODBA) et frameworks Ontop 18 2.2.5 Mat´erialisation de donn´ees en triplets RDF 20 2.3 Conclusion Chapitre Solution propos´ ee 22 23 v 3.1 Introduction 23 3.2 Mod`ele g´en´eral 23 3.3 Transformation et synchronisation de donn´ees dans MongoDB 24 3.4 Ontologies et domaine applicatif 26 3.5 xR2RML et Transformation de donn´ees en triplets 27 3.5.1 Le langage de mapping de donn´ees xR2RML 27 3.5.2 Transformation de donn´ees en triplets 28 3.6 Conclusion Chapitre Stockage et Indexation de donn´ ees RDF 30 31 4.1 Introduction 31 4.2 Approche native et non-native 31 4.3 Vue g´en´erale des syst`emes de gestion de triplets 33 4.3.1 TripleStore Sesame 33 4.3.2 TripleStore 4Store 34 4.3.3 TripleStore Virtuoso 36 4.3.4 TripleStore Jena Fuseki 37 4.3.5 TripleStore Stardog 38 4.3.6 TripleStore GraphDB 38 4.4 Impl´ementation 39 4.5 Conclusion 40 Chapitre Exp´ erimentation, Comparaison et Analyse 42 5.1 Pr´eparation des donn´ees et du Serveur 42 5.2 Benchmarking des platformes 42 5.2.1 Chargement de donn´ees 42 5.2.2 Recherche de donn´ees 43 5.2.3 Inf´erence sur les donn´ees 48 Evaluation et Analyse 51 5.3 CONCLUSION 53 ´ ERENCES ´ REF 55 Annexe A Mod` ele de document JSON A.1 Annexe B Mappage de donn´ ees JSON aux triplets par xR2RML B.5 Annexe C Point d’acc` es C.8 vi Liste d’abr´ eviations API Application Programming Interface CRUD Create, Read, Update, Delete D2R Database To RDF DFS Distributed files system DL Logiques de Description IBC Institut de Biologie Computationelle INRA Institut National de la Recherche Agronomique JSON Javascript Object Notation JSON-LD JSON for Linking Data NoSQL Not Only SQL ODBA Ontology-Based Data Access OWL Web Ontology Language OWL RL Web Ontology Rule Language R2RML Relational Databases to RDF Mapping Language RDF Resource Description Framework RDFS Resource Description Framework Schema RML RDF Mapping Language SPARQL Protocol and RDF Query Langage SQL Structured Query Language W3C World Wide Web Consortium xR2RML Relational and Non-Relational Databases to RDF Mapping Language vii Liste des figures 1.1 L’architecture du web s´emantique 1.2 L’exemple d’un triplet Resource Description Framework (RDF) 1.3 L’exemple d’une requˆete Protocol and RDF Query Langage (SPARQL) 2.1 Le mod`ele de composants dans un syst`eme MongoGraph 12 2.2 Les donn´ees pr´esent´ees dans cet exemple 13 2.3 Une requˆete SPARQL associ´ee `a une requˆete de MongoDB 14 2.4 La graphe de donn´ees dans Neo4j 15 2.5 Les commandes pour cr´eer un graphe simple 16 2.6 Les triplets sont stock´ees dans MongoDB sous la forme de JSON-LD 17 2.7 Le mod`ele de composants dans un syst`eme d’association de MongoDB et JSON-LD – Create, Read, Update, Delete (CRUD) 17 2.8 Le processus de requˆete dans le syst`eme d’ODBA 19 2.9 La comparaison des approches des raisonnements dans une application 19 2.10 L’architecture du syst`eme avec l’association de MongoDB et le mod`ele d’ODBA 20 2.11 Les deux tables et sa relation 21 2.12 Les informations d´efinies pour le mapping 21 2.13 Les donn´ees RDF apr`es de la transformation 21 3.1 Le mod`ele g´en´eral du syst`eme 24 3.2 Le mod`ele JSON cr´e´e ` a partir des bases d’imageries 25 3.3 L’ontologie de l’annotation d’images 26 3.4 Un exemple de donn´ees dans MongoDB 27 3.5 Le triplet g´en´er´e 28 3.6 Le mapping de xR2RML 28 3.7 Le mod`ele g´en´eral du syst`eme 29 4.1 La classificaiton des types de syst`eme de stockage RDF 32 4.2 Les composants dans l’architecture de Sesame 33 4.3 L’architecture principale de 4Store 35 4.4 L’architecture g´en´erale de Virtuoso 36 4.5 Les composants dans l’architecture de Jena 37 4.6 Les composants dans l’architecture de GraphDB 38 4.7 L’interface du syst`eme d’interaction avec les donn´ees RDF 39 viii PREFIX rdf : < http : // www w org / 9 / / 2 - rdf - syntax - ns # > PREFIX : < http : // www mistea supagro inra fr / ontologies / / / i ma ge An n ot at i on # > SELECT ? image ? Source ? hasViewType WHERE { ? image : hasSource ? Source ? image rdf : type : Image ? image : hasViewType ? hasViewType FILTER (? Source =" http : // www phenome - fppn fr / m p / phenoarch ") FILTER REGEX (? hasViewType , " top " , " i ") } Figure 5.14: L’exemple de la deuxi` eme inf´erence Figure 5.15: Le temps d’ex´ ecution de la deuxi`eme inf´erence sous forme de graphique TripleStore Sesame 4Store Virtuoso Fuseki Stardog GraphDB 100,000 2,479 3,193 17,713 5,619 989 2,497 1,000,000 8,215 11,483 18,178 56,960 1,923 3,308 10,000,000 71,829 4,578,915 15,632 648,863 13,198 23,359 20,000,000 123,991 15,195,516 37,506 1,044,958 20,723 38,792 40,000,000 216,465 39,261,745 43,957 29,045,934 51,223 63,312 Nombre de triplets Tableau 5.8: L’evaluation de la deuxi` eme inf´erence (temps en millisecondes) 50 Cet exemple nous permet de confirmer que les deux TripleStore 4Store et Jena Fuseki sont tr`es lents pour executer les inf´erences sur des donn´ees volumineuses Les trois TripleStore Stardog, GraphDB et Virtuoso obtiennent de bons temps d’ex´ecution Sesame dans les deux inf´erences obtient des r´esultats moins bon mais tr`es correct pour un syst`eme de gestions de base de donn´ees de triplets OpenSource Dans certains cas, il donne des r´esultats meilleurs que les TripleStores commerciaux 5.3 Evaluation et Analyse L’´evaluation des TripleStores donne une vue g´en´erale sur la capacit´e d’ex´ecution et la performance de ces syst`emes Chaque syst`eme a des diff´erences dans l’organisation et dans l’indexation des triplets, par exemple Virtuoso utilise des tables relationnelles, 4Store utilise la structure de l’arbre radix, tandis que Sesame, Jena Fuseki et GraphDB appliquent la structure de l’arbre B ou B+ [20] [21] Ces diff´erences sont des ´el´ements importants qui impactent sur leurs performances N´eanmoins, nous devons aussi consid´erer les fonctionnalit´es supports n´ecessaires pour un syst`eme de gestion de base de donn´ees de triplets La fonctionnalit´e la plus importante est la capacit´e de raisonnement sur les donn´ees au niveau RDFS ou OWL De plus, avec les bases de donn´ees sur de gros volumes, la distribution des processus sur plusieurs machines, peut faciliter le raisonnement sur de grands graphes de donn´ees RDF Dans ce contexte, les TripleStores ont besoin de soutenir le regroupement les bases de donn´ees reparties sur un r´eseau de plusieurs machines pour communiquer et ´echanger les donn´ees [22] [23] [24] [25] Ci-dessus, nous ´evaluons les trois crit`eres les plus importants pour un syst`eme de gestion de base de donn´ees triplets : Chargement de donn´ees, Recherche de donn´ees et Inf´erence de donn´ees Avec 4Store, les avantages de l’indexation de donn´ees, selon l’arbre radix nous fournissent un bon outil pour les op´erations de chargement et recherche de donn´ees Il est toujours un des meilleurs outils avec le temps d’ex´ecution le plus rapide De plus, l’architecture de 4Store permet de faire le regroupement les donn´ees distribu´ee et d’utiliser dans plusieurs machines dans un mˆeme temps Toutefois, la fonction de recherche dans 4Store est encore perfectible, nous pouvons constater qu’il a des erreurs dans quelques cas (dans l’exemple de recherche num´ero 4) De plus, l’interface d’interaction a plusieurs limitations Mais plus grand inconv´enient est le support de la fonctionnalit´e de raisonnement En r´ealit´e, le moteur de raisonnement est un module ´etendu nomm´e 4sr qui est une branche du projet 4Store mise en œuvre pour faire le raisonnement arri`ere pour 4Store Ce module supporte une capacit´e d’inf´erence tr`es faible avec les relations : rdfs :subClassOf, rdfs :subPropertyOf, rdfs :domain et rdfs :range dans RDFS Le choix de 4Store pour construire le syst`eme avec de gros volume de donn´ees d´ependra du besoin en raisonnement S’il n’y a pas besoin d’inf´erer sur les donn´ees, 4Store est peut-ˆetre le bon choix Sesame est l’un des deux premiers outils qui est mis en œuvre pour g´erer les donn´ees RDF Avec cet outil, les r´esultats restent moyens dans les benchmarks sur le chargement, la recherche et l’inf´erence de donn´ees Ces r´esultats sont acceptables pour un outil Opensource Toutefois, Sesame poss`ede des inconv´enients dans la gestion de donn´ees volumineuses Tout d’abord, il ne peux pas ˆetre d´eploy´e en cluster de machines avec un grand graphe reparti, mais plutˆot permet que de cr´eer un base de donn´ees f´ed´er´e avec des graphes qui sont compl`etement s´epar´ees Ensuite, la modele de donn´ees en RDF natif dans Sesame est optimise pour les jeux de donn´ees de taille moyenne Ses limites en termes d’utilisabilit´e sont 51 autour de 100 ` a 150 millions de triplets2 (Cela d´epend beaucoup du mat´eriel ainsi que des caract´eristiques de l’ensemble de donn´ees) Enfin, le m´ecanisme d’inf´erence de Sesame cr´ee beaucoup de nouveaux triplets et cela augmente la taille de la base de donn´ees Ceci est g´erable pour des graphes de taille moyenne mais atteint ses limites pour des grands graphes Le Virtuoso est uniquement construit sur la base de l’architecture du syst`eme de gestion bases de donn´ees relationnelles Ceci peut expliquer ses mauvais de r´esultats sur les temps d’ex´ecution de chargement de donn´ees et quelques exemples de recherches Par contre, Virtuoso a des avantages dans la capacit´e d’inf´erence de donn´ees Il peut effectuer des raisonnements avec les donn´ees d´efinies par le RDFS ou OWL Dans les Triplestores ´evalu´es, Virtuoso est le meilleur outil Opensource qui soutient compl`etement des composants essentiels d’un syst`eme de gestion de base de donn´ees, comme les transactions de l’ACID, la s´ecurit´e ou l’interface d’interaction pour l’utilisateur etc De plus, il nous permet de mettre en œuvre un syst`eme avec un fort support de raisonnement Enfin Virtuoso permet de d´eployer les bases de donn´ees sur plusieurs clusters de machines Toutefois, cette fonctionnalit´e n’est support´ee que dans la version commerciale L’outil Jena Fuseki est d´evelopp´e sur la base du framework Jena Il apporte les caract´eristiques du premier framework qui est construit pour les donn´ees RDF Notre benchmark est effectu´e avec le stockage selon l’architecture de Jena TDB et l’indexation utilise la structure de l’arbre B+ Dans les ´evaluations, Jena montre de bons r´esultats dans le chargement de donn´ees Toutefois, la recherche de donn´ees et les inf´erences avec Jena Fuseki ont toujours pris beaucoup de temps d’ex´ecution Aujourd’hui, Jena peut fonctionner sur un cluster de plusieurs machines selon diff´erentes architectures Voir quelques exemples d´efinis dans cet article [20] D’ailleurs, Jena fournit des APIs (Apache Jena Elephas) qui permettent d’´ecrire des applications int´egr´e dans Apache Hadoop D’apr`es les r´esultats nous pouvons dire que Jena Fuseki convient pour des bases de donn´ees RDF de taille moyenne Le GraphDB Ontotext est construit `a partir du framework Sesame dans le but de fournir des caract´eristiques manquantes ` a ce dernier Les am´eliorations de GraphDB se focalisent sur la capacit´e de raisonnement, l’interface utilisateur et l’architecture cluster de donn´ees Dans presque tous les cas des ´evaluations, nous pouvons voir que GraphDB donne un temps d’ex´ecution plus performant que Sesame notamment dans la recherche de donn´ees et les inf´erences En fait, il y a moins diff´erence dans le m´ecanisme d’indexation de GraphDB et Sesame ce qui explique la faible diff´erence dans le temps d’ex´ecution Avec son moteur d’inference, GraphDB soutient des raisonnements au niveau RDFS et OWL Grace `a la version entreprise de GraphDB (que nous avons test´e pour un mois), il est possible de g´erer de gros volumes donn´ees RDF Le dernier outil dans notre ´evaluation est Stardog Cet outil donne des r´esultats impressionnants sur les trois crit`eres compar´ees : Chargement de donn´ees, Recherche de donn´ees et Inf´erence de donn´ees Il est toujours dans les meilleurs outils qui sont les plus performants Pour le raisonnement, il supporte des inf´erences dans RDFS et OWL De plus il est permet de cr´eer des clusters de au niveau haut de performance Nous pouvons dire que Stardog est le meilleur outil dans la liste de tous les outils de notre Benchmark http ://www.rivuli-development.com/further-reading/sesame-cookbook/loading-large-file-in-sesame-native/ 52 Conclusion L’organisation et la gestion de donn´ees scientifiques sont de plus en plus importantes dans le processus de r´ealisation des ´etudes biologiques La recherche d’une m´ethode de gestion de donn´ees peut aider ` a les utiliser et ` a les exploiter de la meilleure fa¸con dans le but d’´economiser du temps et aussi d’augmenter la performance des syst`emes de gestion Le probl`eme que nous avons rencontr´e au cours de ce stage est la taille de ces donn´ees Les m´ethodes ordinaires ne permettent pas de g´erer ces donn´ees correctement De plus, le besoin d’utiliser la s´emantique dans la recherche et l’utilisation des donn´ees nous oblige ` a trouver une m´ethode d’organisation adapt´ee Compte tenu de ces deux probl´ematiques, l’´etat de l’art, dans le chapitre de ce rapport, nous fournit une vue g´en´erale des solutions possibles En fait, chaque solution d´ecrite est l’association d’une ou de plusieurs m´ethodes diff´erentes En g´en´eral, nous pouvons r´esumer ces solutions en deux directions : la transformation des requˆetes (ou r´e-´ecriture ), la transformation des donn´ees en triplets RDF (ou mat´erialisation) Chaque direction contient des avantages et des inconv´enients particuliers Au cours de ce stage, nous avons fait le choix de la mat´erialisation de donn´ees en RDF Ce choix nous a permis de faciliter la recherche s´emantique sur les donn´ees Accompagnant ce choix, nous avons dˆ u d´efinir de nouveaux mod`eles des donn´ees dans une forme unifi´ee pour transformer des donn´ees exp´erimentales en RDF Pour ce faire, un programme a ´et´e ´ecrit pour transformer des donn´ees sous la forme de documents JSON stock´es dans MongoDB en triplets RDF Afin de g´erer ces grands graphes de triplets de mani`ere optimale, nous avons ´evalu´e plusieurs syst`emes de gestion de bases de donn´ees de triplets RDF Les TripleStores 4Store, Sesame, Virtuoso, Jena Fuseki, GraphDB et Stardog ont ´et´e choisis pour r´ealiser un benchmark sur diff´erents crit`eres : les capacit´es de chargement de donn´ees, de recherche de donn´ees et d’inf´erence de donn´ees Ce benchmark n’est pas exhaustif, il manque en effet quelques syst`emes comme AllegroGraph, BlazeGraph etc N´eanmoins, dans les r´esultats obtenus, nous pouvons voir une diff´erence entre deux groupes : Open source (4Store, Sesame, Jena Fuseki) et Commercial (GraphDB, Stardog, Virtuoso) En g´en´eral, la performance du groupe commercial est meilleure Particuli`erement Stardog qui obtient de bons r´esultats dans presque touts les crit`eres compar´es Cela est bien-sur du au fait que ces syst`emes sont d´evelopp´es par des soci´et´es sp´ecialis´es au lieu d’un communaut´e acad´emique dans les syst`eme Open Source L’approche de mat´erialisation de donn´ees en triplets RDF convient pour augmenter la capacit´e de recherche s´emantique sur les donn´ees Plus pr´ecis´ement, au niveau des inf´erences de nouvelles connaissances bas´es sur des ontologies qui sont automatiquement r´ealis´ees dans triplestores Toutefois, cette approche poss`ede encore des inconv´enients notamment sur la gestion de donn´ees volumineuses, car jusqu’`a pr´esent seuls certains triplestores peuvent supporter de gros volumes de donn´ees de mani`ere ´equivalente aux syst`emes NoSQL Nous pensons que dans le futur, les travaux sur les approches de transformation de 53 requˆetes (NoSQL-SPARQL) pourront nous aider `a comparer des avantages et des d´esavantages de ces deux approches 54 R´ ef´ erences [1] L LE Ngoc, “D´eveloppement d’un syst`eme de gestion de donn´ees de ph´enotypage chez le riz (o.sativa),” Cours : Travail Personnel Encardr´e, Institut de la Francophonie pour l’Informatique, 2014 [2] A Shiri, “Linked data meets big data : A knowledge organization systems perspective,” pp 16–20, 2014 [3] L LE Ngoc, S JOUNANIC, P GANTET, and P LARMANDE, “D´eveloppement d’un outil g´en´etique d’indexation pour optimiser l’exploitation des donn´ees biologiques,” JOBIM 2015, Journ´ees Ouvertes en Biologie, Informatique et Math´ematiques, 2015 [4] Laney, http “3d data management : Controlling data volume, ://blogs.gartner.com/doug-laney/files/2012/01/ad949- velocity, and variety,” 3D-Data-Management-Controlling- Data-Volume-Velocity-and- Variety.pdf, 2011 [5] V Rometty, “Extracting value from chaos,” IDC Analyze the Future, no 42, p P.4, 2013 [6] CNRS, “The big data r´evolution,” Le Journal, no 28, 2013 [7] T Berners-Lee, ““the semantic web”, scientific american magazine,” 2001 [8] T Berners-Lee, Fischetti, and Mark, “Weaving the web,” 1999 [9] C End Point, “Benchmarking top nosql databases : Apache cassandra, couchbase, hbase, and mongodb,” 2015 [10] M Rodriguez-Muro, R Kontchakov, and M Zakharyaschev, “Ontology-based data access ontop of database,” The Semantic Web - ISWC 2013, vol 8218 of the series Lecture Notes in Computer Science, pp 558–573, 2013 [11] T Bagosi, D Calvanese, J Hardi, and S Komla-Ebri, “The ontop framework for ontology based data access,” The Semantic Web and Web Science - ISWC 2014, vol 480 of the series Communications in Computer and Information Science, pp 67–77, 2014 [12] M Rodriguez-muro, D Rezk, M Slusnys, T Bagosi, and D Calvanese, “Evaluating sparql-to-sql translation in ontop,” CEUR Workshop Proceedings, vol 1015, p 94–100, 2013 [13] S Das, S Sundara, and R Cyganiak, “R2rml : Rdb to rdf mapping language,” 2012 55 [14] F Michel, L Djimenou, C Faron-Zucker, and J Montagnat, “R2rml : Relational and non-relational databases to rdf mapping language,” https ://hal.archives-ouvertes.fr/hal-01066663v3, 2014 [15] A Dimou, M Vander Sande, P Colpaert, R Verborgh, E Mannens, and R Van de Walle, “Rml : A generic language for integrated rdf mappings of heterogeneous data,” Proceedings of the 7th Workshop on Linked Data on the Web (LDOW2014), 2014 [16] J Van Ossenbruggen, R Troncy, G Stamou, and J Pan, “Image : Annotation on the semantic web,” W3C Incubator Group Report, 2007 [17] M SIVERA, “Rapport de stage : Annotation s´emantique d’images,” 2015 [18] S Harris, N Lamb, and N Shadbolt, “4store : The design and implementation of a clustered rdf store,” The 5th International Workshop onScalable Semantic Web Knowledge BaseSystems (SSWS2009), 2009 [19] D Morrison, “Practical algorithm to retrieve information coded in alphanumeric,” Journal of the ACM (JACM), vol 15, pp 514–534, 1968 [20] A Owens, A Seaborne, and N Gibbins, “Clustered tdb : A clustered triple store for jena,” 2009 [21] M Hepp, P De Leenheer, A De Moor, and Y Sure, Ontology Management : Semantic Web, Semantic Web Services and Business Applications, ch : Ontology Reasoning with large data repositories, p 92 Springer, 2008 [22] I Filali, F Bongiovanni, F Huet, and F Baude, “A survey of structured p2p system for rdf data storage and retrieval,” Transactions on Large-Scale Data and Knowledge Centered Systems III, pp 20– 55, 2011 [23] N Papailiou, I Konstantinou, D Tsoumakos, P Karras, and N Kowiris, “H2rdf+ : Highperformance distributed joins over large-scale rdf graphs,” Big Data, 2013 IEEE International Conference on, pp 255–263, 2013 [24] R Punnoose, A Crainiceanu, and D Rapp, “Rya : A scalable rdf triple store for the clouds,” Proceedings of the 1st International Workshop on Cloud Intelligence, pp :1–4 :8, 2012 [25] B Wu, Y Zhou, P Yuan, H Jin, and L Liu, “Semstore : A semantic-preserving distributed rdf triple store,” Proceedings of the 23rd ACM International Conference on Conference on Information and Knowledge Management, pp 509–518, 2014 56 Annexe A Mod` ele de document JSON Dans la liste ci-dessous, ce sont des documents du mod`ele JSON qui sont d´efinis pour servir le but de transformation de base de donn´ees relationnelles aux des documents JSON qui vont ˆetre stock´es dans MongoDB Le Mod`ele JSON pour le profil du Cam´era qui va ˆetre stock´e des informations de configurations, de descriptions et de r´eglages du cam´era : I ma g eC am e r a P r o f i l e { " configuration " : { " provider " : " phenowaredb " , " stationid " : int , " i m g a c q c a m e r a p r o f i l e i d " : int , " i m g a c q c a m e r a p r o f i l e n a m e " : string , " v a l i d a t e d P r o f i l e " : boolean , " del etedPro file " : boolean , " i n t e r f a c e a c q t y p e " : int 10 }, 11 " description " : string , 12 " settings " :{ 13 " viewType " : string , 14 " viewCount " : int , 15 " width " : int , 16 " height " : int , 17 " triggerMode " : int , 18 " shutter " : int , 19 " gain " : int , 20 " brightness " : int , 21 " hue " : int , 22 " gamma " : int , 23 " saturation " : int , 24 " sharpness " : int , 25 " whiteBalance " : int , 26 " pixelFormat " : string } 27 28 } Le document JSON pour le profil de la cabine qui va ˆetre stock´e des informations de configurations, de descriptions et de r´eglages de la cabine : I m a g e St a t i o n P r o f i l e { " configuration " : { A.1 " provider " : " phenowaredb " , " stationid " : int , " i m g a c q s t a t i o n p r o f i l e i d " : int , " i m g a c q s t a t i o n p r o f i l e n a m e " : string , " v a l i d a t e d P r o f i l e " : boolean , " del etedPro file " : boolean , 10 " i n t e r f a c e a c q t y p e " : int 11 }, 12 " description " : string , 13 " settings " :{ 14 " v e r t i c a l P o s i t i o n " : int , 15 " topLight " : int , 16 " sideLight " : int , 17 " zoom " : int , 18 " focus " : int , 19 " aperture " : int , 20 " rotationSpeed " : long , 21 " topViewCount " : int , 22 23 " sideViewCount " : int } 24 25 } Le document JSON de donn´ees du processus d’arrosage Watering { " plant " : URI , " plantAlias " : string , " genotype " : URI , " genotypeAlias " : string , " experiment " : URI , " ex pe r im en t Al ia s " : string , " study " : URI , " studyAlias " : string , 10 " platform " : " http : // www phenome - fppn fr / m p /" , 11 " t e c h n i c a l P l a t e a u " : " http : // www phenome - fppn fr / m p /" , 12 " timestamp " : int , 13 " date " : date , 14 " configuration " : { 15 " provider " : " phenowaredb " , 16 " wateringid " : int , 17 " plantid " : int , 18 " studyname " : string , 19 " taskid " : int , 20 " calibration " : int , 21 " stationid " : int , 22 " usedscaleid " : int , 23 " usedpumpid " : int , 24 " nextLocation " : { 25 " lane " : int , 26 " rank " : int , 27 " level " : int , } 28 29 }, 30 " a u t o m a t o n S u c c e s s " : boolean , 31 " us erValid ation " : boolean , 32 " setpoints " : { 33 " product " : string , 34 " scaleType " : string , 35 " pumpType " : string , 36 " targetWeight " : int , A.2 37 " tar getQuan tity " : int , 38 " pumpSpeed " : int , 39 " maxQuantity " : int , 40 " minWeight " : int , 41 " movePerch " : boolean , 42 }, 43 " product " : string , 44 " scaleType " : string , 45 " pumpType " : string , 46 " pumpSpeed " : int , 47 " measures " : { " weightBefore " : { 48 49 " value " : int , 50 " unity " : string , 51 " type " : " automatic " , 52 " confidence " : " unspecified " 53 }, 54 " weightAfter " : { 55 " value " : int , 56 " unity " : string , 57 " type " : " automatic " , 58 " confidence " : " unspecified " 59 }, 60 " weightAmount " : { 61 " value " : int , 62 " unity " : string , 63 " type " : " computed " , 64 weightAfter - weightBefore " confidence " : " unspecified " } 65 } 66 67 } Le document JSON de donn´ees du processus de pess´ees Weighing { platform : string URI , te c h n i c a l P l a t e a u : experiment : URI , URI , exp er im e nt Al ia s : string , study : string , studyAlias : string , plant : URI , 10 plantAlias : string , genotype : URI , 11 genotypeAlias : string , 12 date : date , 13 timestamp : int , 14 conf igurati ons :{ 15 seconds provider : " phenowaredb " 16 weighingid : objectid , 17 studyname : string , 18 taskid : objecid , 19 plantid : integer , 20 usedstationid : int , 21 usedscaleid : int , 22 nextLocation :{ 23 lane : integer , 24 rank : integer , 25 level : integer } 26 27 } A.3 28 au t o m a t o n S u c c e s s : boolean , 29 user Validat ion : boolean , 30 setpoints :{ 31 scaleType : string , 32 } 33 scaleType : string , 34 weighingType : string , 35 measures :{ 36 weightBefore :{ 37 value : int , 38 unity : string , 39 type : " automatic " , 40 confidence : string 41 } 42 weightAfter :{ 43 value : int , 44 unity : string , 45 type : " automatic " , 46 confidence : string 47 } 48 weight :{ 49 value : int , absolute ( weightafter - weightbefore ) 50 unity : string , 51 type : " computed " , 52 confidence : string } 53 54 } 55 } A.4 Annexe B Mappage de donn´ ees JSON aux triplets par xR2RML Le mappage de document JSON aux triplets de la collection de profil du cam´era @prefix xrr : < http : // i s unice fr / xr rml # > @prefix rr : < http : // www w org / ns / r rml # > @prefix ex : < http : // example com / > @prefix rml : < http : // semweb mmlab be / ns / rml # > @prefix xsd : < http : // www w org / 0 / XMLSchema # > @prefix rdfs : < http : // www w org / 0 / / rdf - schema # > @prefix rdf : < http : // www w org / 9 / / 2 -rdf - syntax - ns # > @prefix f : < http : // www franz com / > @prefix ia : < http : // www mistea supagro inra fr / ontologies / / / im ag e An no ta t io n # > 10 11 a rr : TriplesMap ; 12 xrr : logicalSource [ xrr : query """ db st ationpr ofile find ( { ’_id ’ : { ✩ exists : true } } ) """; 13 14 ]; 15 rr : subjectMap [ rr : template "{ ✩ uri }"; 16 17 rr : class ia : A c q u i s i t i o n S t a t i o n P r o f i l e ; 18 ]; 19 rr : p r e d i c a t e O b j e c t M a p [ 20 rr : predicate ia : a c q u i s i t i o n S t a t i o n P r o f i l e N a m e ; rr : objectMap [ xrr : reference " ✩ configuration i m g a c q s t a t i o n p r o f i l e n a m e "; ] ; 21 22 ]; 23 rr : p r e d i c a t e O b j e c t M a p [ 24 rr : predicate ia : a c q u i s i t i o n S t a t i o n P r o f i l e D e s c r i p t i o n ; rr : objectMap [ xrr : reference " ✩ description "; ] ; 25 26 ]; 27 rr : p r e d i c a t e O b j e c t M a p [ 28 rr : predicate ia : i s P r o f i l e O f S t a t i o n ; rr : objectMap [ xrr : reference " ✩ configuration stationid "; ] ; 29 30 ]; 31 rr : p r e d i c a t e O b j e c t M a p [ 32 rr : predicate ia : indexer ; rr : objectMap [ xrr : reference " ✩ settings v e r t i c a l P o s i t i o n "; ] ; 33 34 ]; 35 rr : p r e d i c a t e O b j e c t M a p [ 36 rr : predicate ia : topLight ; rr : objectMap [ xrr : reference " ✩ settings topLight "; ] ; 37 38 ]; B.5 39 rr : p r e d i c a t e O b j e c t M a p [ 40 rr : predicate ia : sideLight ; rr : objectMap [ xrr : reference " ✩ settings sideLight "; ] ; 41 42 ]; 43 rr : p r e d i c a t e O b j e c t M a p [ 44 rr : predicate ia : focus ; rr : objectMap [ xrr : reference " ✩ settings focus "; ] ; 45 46 ]; 47 rr : p r e d i c a t e O b j e c t M a p [ 48 rr : predicate ia : zoom ; rr : objectMap [ xrr : reference " ✩ settings zoom "; ] ; 49 50 ]; 51 rr : p r e d i c a t e O b j e c t M a p [ 52 rr : predicate ia : aperture ; rr : objectMap [ xrr : reference " ✩ settings aperture "; ] ; 53 54 ]; 55 rr : p r e d i c a t e O b j e c t M a p [ 56 rr : predicate ia : rotationSpeed ; rr : objectMap [ xrr : reference " ✩ settings rotationSpeed "; ] ; 57 58 ]; 59 rr : p r e d i c a t e O b j e c t M a p [ 60 rr : predicate ia : topViewCount ; rr : objectMap [ xrr : reference " ✩ settings topViewCount "; ] ; 61 62 ]; 63 rr : p r e d i c a t e O b j e c t M a p [ 64 rr : predicate ia : sideViewCount ; rr : objectMap [ xrr : reference " ✩ settings sideViewCount "; ] ; 65 66 ] Le mappage de document JSON aux triplets de la collection de profil de la cabine @prefix xrr : < http : // i s unice fr / xr rml # > @prefix rr : < http : // www w org / ns / r rml # > @prefix ex : < http : // example com / > @prefix rml : < http : // semweb mmlab be / ns / rml # > @prefix xsd : < http : // www w org / 0 / XMLSchema # > @prefix rdfs : < http : // www w org / 0 / / rdf - schema # > @prefix rdf : < http : // www w org / 9 / / 2 -rdf - syntax - ns # > @prefix f : < http : // www franz com / > @prefix ia : < http : // www mistea supagro inra fr / ontologies / / / im ag e An no ta t io n # > 10 11 a rr : TriplesMap ; 12 xrr : logicalSource [ xrr : query """ db cameraprofile find ( { ’_id ’ : { ✩ exists : true } } ) """; 13 14 ]; 15 rr : subjectMap [ rr : template "{ ✩ uri }"; 16 17 rr : class ia : CameraProfile ; 18 ]; 19 rr : p r e d i c a t e O b j e c t M a p [ 20 rr : predicate ia : whiteBalance ; rr : objectMap [ xrr : reference " ✩ settings whiteBalance "; ] ; 21 22 ]; 23 rr : p r e d i c a t e O b j e c t M a p [ 24 rr : predicate ia : brightness ; rr : objectMap [ xrr : reference " ✩ settings brightness "; ] ; 25 26 ]; 27 rr : p r e d i c a t e O b j e c t M a p [ 28 rr : predicate ia : c a m e r a P r o f i l e D e s c r i p t i o n ; rr : objectMap [ xrr : reference " ✩ description "; ] ; 29 30 ]; B.6 31 rr : p r e d i c a t e O b j e c t M a p [ 32 rr : predicate ia : gain ; rr : objectMap [ xrr : reference " ✩ settings gain "; ] ; 33 34 ]; 35 rr : p r e d i c a t e O b j e c t M a p [ 36 rr : predicate ia : gamma ; rr : objectMap [ xrr : reference " ✩ settings gamma "; ] ; 37 38 ]; 39 rr : p r e d i c a t e O b j e c t M a p [ 40 rr : predicate ia : hue ; rr : objectMap [ xrr : reference " ✩ settings hue "; ] ; 41 42 ]; 43 rr : p r e d i c a t e O b j e c t M a p [ 44 rr : predicate ia : pixelFormat ; rr : objectMap [ xrr : reference " ✩ settings pixelFormat "; ] ; 45 46 ]; 47 rr : p r e d i c a t e O b j e c t M a p [ 48 rr : predicate ia : saturation ; rr : objectMap [ xrr : reference " ✩ settings saturation "; ] ; 49 50 ]; 51 rr : p r e d i c a t e O b j e c t M a p [ 52 rr : predicate ia : sharpness ; rr : objectMap [ xrr : reference " ✩ settings sharpness "; ] ; 53 54 ]; 55 rr : p r e d i c a t e O b j e c t M a p [ 56 rr : predicate ia : shutter ; rr : objectMap [ xrr : reference " ✩ settings shutter "; ] ; 57 58 ]; 59 rr : p r e d i c a t e O b j e c t M a p [ 60 rr : predicate ia : triggerMode ; rr : objectMap [ xrr : reference " ✩ settings triggerMode "; ] ; 61 62 ]; 63 rr : p r e d i c a t e O b j e c t M a p [ 64 rr : predicate ia : viewCount ; rr : objectMap [ xrr : reference " ✩ settings viewCount "; ] ; 65 66 ]; 67 rr : p r e d i c a t e O b j e c t M a p [ 68 rr : predicate ia : viewType ; rr : objectMap [ xrr : reference " ✩ settings viewType "; ] ; 69 70 ]; 71 rr : p r e d i c a t e O b j e c t M a p [ 72 rr : predicate ia : width ; rr : objectMap [ xrr : reference " ✩ settings width "; ] ; 73 74 ]; 75 rr : p r e d i c a t e O b j e c t M a p [ 76 rr : predicate ia : height ; rr : objectMap [ xrr : reference " ✩ settings height "; ] ; 77 78 ] B.7 Annexe C Point d’acc` es La table suivante cite des point d’acc`es via protocole HTTP pour acc´eder des donn´ees RDF TripleStore Point d’acc` es Sesame http ://147.99.7.154 :8080/openrdf-sesame/repositories/phis40mnative 4Store http ://147.99.7.154 :9000/sparql/ ?soft-limit=-1 Virtuoso http ://147.99.7.154 :8890/sparql Fuseki http ://147.99.7.154 :3030/phis40m/query Stardog http ://147.99.7.154 :5820/phis40m/query GraphDB http ://147.99.7.154 :8080/graphdb-workbench-se/repositories/ontotextphis40m Tableau C.1: Les exemples de point d’acc` es de TripleStore C.8