LE PROJET “AGRONOMIC LINKED DATA (AGROLD)” = dự án AgroLD (mô hình dữ liệu agronomic) luận văn ths công nghệ thông tin

UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL TAGNY NGOMPE GILDAS LE PROJET “AGRONOMIC LINKED DATA (AGROLD)” DỰ ÁN AGROLD (MÔ HÌNH DỮ LIỆU AGRONOMIC) MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE HANOI – 2015 UNIVERSITE NATIONALE DU VIETNAM, HANOI INSTITUT FRANCOPHONE INTERNATIONAL TAGNY NGOMPE GILDAS LE PROJET “AGRONOMIC LINKED DATA (AGROLD)” DỰ ÁN AGROLD (MÔ HÌNH DỮ LIỆU AGRONOMIC) Spécialité: Systèmes Intelligents et Multimédia Code: Programme pilote MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE Sous la direction de: Dr Pierre LARMANDE – Ingénieur IRD, responsable de l’AXE Intégration de Données de l’Institut de Biologie Computationnelle Dr Aravind VENKATESAN - Chercheur post-doctorant, IBC 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 TAGNY NGOMPE GILDAS Table des matières Table des matières Remerciements v vi Résumé vii Abstract viii Liste des figures x Liste des tableaux xi INTRODUCTION Chapitre PROBLÉMATIQUE DU PROJET AGROLD 1.1 Contexte 1.2 Système existant 1.3 Problématique du sujet 1.4 Contraintes et résultats attendus Chapitre PUBLICATION DES DONNÉES LIÉES ET OUVERTES 2.1 Le web des données liées et ouvertes 2.2 Publication de données des sciences du vivant 2.2.1 Données 2.2.2 Ontologies 10 11 2.3 Systèmes d’interrogation du web des données 2.3.1 Aide la construction de requêtes 2.3.2 Recherche d’informations spécifiques 11 12 14 2.4 Intégration de données de sources multiples 17 Chapitre SOLUTION PROPOSÉE 20 3.1 Modèle 3.1.1 Paradigmes de recherche sémantique 3.1.2 Architecture 20 20 21 3.2 Prototype implémenté 3.2.1 Intégration et adaptation de systèmes existants 3.2.2 Développement de nouvelles fonctionnalités 22 22 23 iv Chapitre EXPÉRIMENTATIONS ET ANALYSE DES RÉSULTATS 4.1 Utilisation de l’application web AgroLD par des utilisateurs humains 4.1.1 Entrée des requêtes et expressivité 4.1.2 Exécution des requêtes et temps de réponse 4.1.3 Présentation des résultats 28 28 29 31 31 4.2 Utilisation des informations de la base AgroLD dans des applications 4.2.1 Utilisation de l’API pour la programmation 4.2.2 Utilisation de l’API dans les workflows 32 32 33 CONCLUSION 36 Références 37 Annexes 40 v Remerciements Nous adressons nos remerciements tous ceux qui ont contribué la réalisation du travail présenté dans ce document, en particulier : — Pierre LARMANDE et Aravind VENKATESAN, nos superviseurs de stage ; — aux responsables et membres du personnel de notre établissement l’Institut Francophone International ; — aux structures qui nous ont encadré : l’Université Nationale du Vietnam Hanoï (UNVH), l’Université de Montpellier, l’Institut de Recherche pour le Développement (IRD), l’Institut de Biologie Computationnelle (IBC), le Laboratoire d’Informatique, de Robotique et de Micro-électronique de Montpellier (LIRMM), le Centre de coopération International en Recherche Agronomique pour le Développement (CIRAD) ; — Nordine El Hassouni, ingénieur du CIRAD vi Résumé Le web des données liées offre une grande opportunité d’intégration de données de sources et domaines divers Cependant, il présente une rareté des données issue de la recherche en biologie des plantes Des chercheurs de l’IBC construisent actuellement la base de connaissance AgroLD en convertissant les données de la base de données SouthGreen qu’ils lient des ontologies et d’autres sources de données du web des données AgroLD est destinée l’usage des biologistes et des bioinformaticiens Ces groupes d’utilisateurs présentent des niveaux de compétences variées par rapport aux technologies du web sémantique Il s’agissait principalement pour nous de leur proposer des moyens pour faciliter la recherche d’information dans AgroLD et dans des services externes Notre solution est de mettre leur disposition sur une même plateforme plusieurs fonctionnalités d’utilisabilité et d’expressivité différentes Les utilisateurs pourront choisir les systèmes de recherche qui leur conviennent et passer facilement de l’un l’autre Il a été aussi pris en compte l’activité de développement d’applications des bioinformaticiens Nous avons proposé une API de services REST pour exposer les informations correspondant des questions biologiques Cette API présente l’atout d’être facilement utilisable pour la programmation d’application et dans le gestionnaire de workflows bioinformatiques Galaxy Nous avons notamment utilisé cette API et d’autres services web pour faire de l’agrégation de connaissances au sein d’un formulaire dynamique dans notre prototype Mots clés : Intégration de données agronomiques, agrégation de connaissance, systèmes de recherche sémantique, interaction homme-machine, services REST vii Abstract The web of linked data provides great data integration opportunity from various sources and areas However, it lacks data of research in plant biology IBC’s researchers are currently building the knowledge base AgroLD converting data base SouthGreen data they bind to ontologies and other sources of web of data AgroLD is intended for use by biologists and bioinformaticians These users groups have different levels of skills by compared to semantic web technologies For us, It were about to suggest to them, ways to facilitate the search for information in AgroLD and external services Our solution is to provide them, on the same platform, several features with different usability and expressivity Users can choose which search systems that suit them and easily switch from one to another It was also considered the applications development activity of bioinformaticians We have proposed a REST service API to expose the information corresponding to biological questions This API has the advantage of being easily usable for application programming and in bioinformatics workflows manager Galaxy We used particularly the API and other web services to make knowledge aggregation in a dynamic form in our prototype Keywords : Integration of agronomic data, aggregation of knowledge, semantic search systems, human-computer interaction, REST services viii Liste des figures 1.1 1.2 Lien entre deux ressources de sources distantes et différentes sur AgroLD uri non déréférencé participant des triplets dans AgroLD 2.1 2.4 2.5 2.6 2.7 Exemple de graphe de données liées (source : http://linkedlifedata com/about) Ensembles de données des sciences de la vie dans le nuage des données liées et ouvertes (source : http://lod-cloud.net) Ressources biologiques RDF liées UniProtKB (uniprot.rdf), la base principale de UniProt Différence entre les filtres et la navigation facettes Avantages des services RESTful sur les services basées sur SOAP (WS-*) Architecture d’Open PHACTS Discovery Plateform Architecture standard des applications de données liées et ouvertes 3.1 3.2 3.3 3.4 Architecture proposée pour l’application web d’AgroLD Editeur de requêtes textuelles SPARQL Module serveur de l’API d’AgroLD Activités de navigation avec le formulaire dynamique 2.2 2.3 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Scénario : entrée de la requête Scénario : entrée de la requête dans le fomulaire dynamique Scénario : entrée de la requête dans l’éditeur de requête SPARQL Scénario : entrée de la requête dans le fomulaire dynamique Scénario : entrée de la requête Scénario : présentation des résultats avec la recherche rapide par mot-clé Scénario : présentation des résultats Scénario : présentation des résultats Scénario : Relations découvertes entre le gène "adenosylmethionine decarboxylase" (AT3G25570) et les deux pathways "spermine biosynthesis" et "spermidine biosynthesis" 4.10 Utilisation du service de recherche de gène par mot-clé dans un programme JavaScript 4.11 documentation du service de recherche des protéines associées un identifiant ontologique 5 10 10 14 16 17 18 21 24 25 27 29 29 30 30 30 31 32 32 33 33 34 ix 4.12 Intégration de la liste des gènes participant au pathway CALVIN-PWY dans Galaxy 34 4.13 Workflow d’extraction des colonnes 1, et d’un tableau dans Galaxy 35 4.14 Résultat de l’extraction des colonnes "geneId", "geneName" et "taxon_name" 35 x interativité permet aussi de tester les services et d’observer le comportement des services dans diverses situations Les services sont décrits dans un fichier JSON Ce dernier est utilisé par le framework SWAGGER (2.0) pour générer la page web de documentation (figure 4.11) — Une librairie cliente pour application JavaScript : elle est fournit par la librairie JavaScript swagger-client.js (de SWAGGER) partir de la description JSON des services web 3.2.2.3 Formulaire dynamique de recherche Il implémente la recherche par formulaire de notre architecture L’idée était de développer un formulaire dynamique basée sur l’API pour faire des recherches d’information dans AgroLD Le système proposé permet en plus d’explorer les informations fournies par les services A partir de la librairie cliente de l’API, nous l’avons implémenté en JavaScript et JSP pour cinq types d’entités : gène, protéine, QTL, pathway, classe d’ontologies L’exploration est représentée par le diagramme d’activité de la figure 3.4 Par exemple, après avoir trouvé un QTL, on peut découvrir les informations relatives aux protéines ou concepts ontologiques auxquels il est associé 3.2.2.4 Accès aux données partir de Galaxy Pour l’accès aux services web, Galaxy dispose du plugin webservice_toolsuite Ce dernier lit un fichier WADL (XML) décrivant les ressources RESTful disponibles et les rend accessibles dans Galaxy sous forme de sources de données webservice_toolsuite n’utilise que la méthode POST de HTTP C’est la raison principale pour laquelle nous avons défini la méthode POST pour les services de l’API au lieu de GET qui est plus indiqué lorsque les services font de la recherche d’information Nous avons décrit les services dans un fichier WADL Ensuite, tout utilisateur ayant installer l’outil webservice_toolsuite dans Galaxy peut passer par ses étapes d’intégration pour installer les ressources de l’API qu’il souhaite utiliser 3.2.2.5 Enrichissement de l’information d’AgroLD Dans notre travail, nous avons mis l’accent sur les résultats retournés l’utilisateur Nous proposons une intégration de services Web au niveau du formulaire dynamique L’avantage par rapport l’intégration des données directement dans AgroLD est de pouvoir utiliser aussi bien des données en RDF ou que dans un autre format Pour répondre aux questions nécessitant des données externes, nous avons enveloppé l’accès aux services externes dans des services de l’API (classe ExternalServices de la figure json Description de l’API d’AgroLD : http://volvestre.cirad.fr:8080/aldp/swagger/agrold http ://swagger.io/ https://toolshed.g2.bx.psu.edu/view/ganjoo/webservice_toolsuite/d5cd409b8a18 http://volvestre.cirad.fr:8080/agrold/agrold_api.wadl 26 Figure 3.4 – Activités de navigation avec le formulaire dynamique 3.3) Par exemple, pour la recherche de publications scientifiques relatives une protéine, l’API passe par deux services : G-Links : pour obtenir leur identifiant (résultats en JSON) ; puis Europe PubMed Central 10 pour obtenir leurs informations (en XML) : titre, auteurs, journal, année de publication, ; http://www.g-language.org/wiki/glinks 10 https://europepmc.org/RestfulWebService 27 Chapitre EXPÉRIMENTATIONS ET ANALYSE DES RÉSULTATS Pour analyser notre solution, nous avons distingué l’interaction avec les utilisateurs humains de celle avec des applications Ces deux interactions n’ont pas les mêmes exigences au niveau des interfaces de communication avec le système 4.1 Utilisation de l’application web AgroLD par des utilisateurs humains Pour l’évaluation des systèmes de recherche sémantique, Khadija Elbedweihy et al [34] recommandent une enquête auprès des utilisateurs partir de quelques requêtes soumettre au système Nous nous sommes basés sur cette approche pour intégrer notre application un formulaire de recueil des avis, remarques et suggestions des utilisateurs Le formulaire comprend quelques questions du modèle de questionnaires "System Usability Scale"(SUS) [35] et d’autres questions que nous avons jugées importantes Les trois principaux critères analysés sont l’utilisabilité qui concerne la facilité d’entrer la requête (nombre de tentatives, temps nécessaire) et, la présentation des résultats ; l’expressivité qui définit pour un système de recherche quelles requêtes un utilisateur est capable de poser ; la performance en rapport avec la capacité retourner rapidement des résultats corrects et complets En attendant les réponses, des utilisateurs, qui guideront l’évolution de l’application, nous analysons ici quelques scénarios d’utilisation des fonctionnalités de recherche du prototype implémenté : « recherche des entités liées au terme "plant height" » : c’est une requête général où l’utilisateur n’a pas une idée précise du type d’entité qu’il recherche ; « recherche des QTLs associés l’identifiant ontologique "EO :0007403" » : c’est une requête un plus précise mais plus complexe que la précédente ; 28 « recherche des publications relatives la protéine "TBP1" » : c’est une requête qui nécessite l’interrogation de services externes car la base AgroLD ne contient pas de publications « recherche des relations existantes entre le gène AT3G25570 et les deux pathways "spermine biosynthesis" et "spermidine biosynthesis" » Nous analysons surtout les moyens les plus pratiques d’obtenir des résultats Nous avons fait nos analyses avec l’instance en développement de notre prototype (http: //volvestre.cirad.fr:8080/aldp/) 4.1.1 Entrée des requêtes et expressivité Pour le scénario 1, il est plus facile de soumettre la requête par la fonctionnalité "Quick Search" que par "Advanced Search" et "SPARQL Query" Il suffit de saisir le mot clé et de cliquer sur le bouton "Search" (figure 4.1) Figure 4.1 – Scénario : entrée de la requête Par contre, pour les requêtes plus complexes, la simple recherche par mot-clé ("Quick Search") est moins facile manipuler que les deux autres Pour le scénario 2, l’absence de résultat par la recherche de "EO :0007403" dans "Quick Search", limite déjà l’utilisateur qui ne peut pas continuer la construction de sa requête Avec "Advanced Search", la construction de la requête se fera seulement en étapes (figure 4.2) : « trouver le concept ontologique "EO :0007403" » puis « accéder aux QTLs associés » Figure 4.2 – Scénario : entrée de la requête dans le fomulaire dynamique Mais pour préciser les types d’informations qu’on souhaite avoir sur ces QTLs, il serait préférable de passer par l’éditeur de requêtes SPARQL (figure 4.3) En plus cet éditeur peut être agrandi et il contient une assistance syntaxique(YASQUE [16]) pour un meilleur confort dans la saisie 29 Figure 4.3 – Scénario : entrée de la requête dans l’éditeur de requête SPARQL Les informations sur les publications n’étant pas accessibles depuis un point d’accès SPARQL, nous ne pouvons pas utiliser de requêtes SPARQL fédérées dans le scénario Par contre, avec "Advanced Search", après avoir trouver la protéine avec le mot clé "TBP1", l’utilisateur peut demander la recherche des publications concernant cette protéine (figure 4.4) Figure 4.4 – Scénario : entrée de la requête dans le fomulaire dynamique Dans le dernier scénario, il est possible d’utiliser une requête SPARQL, mais elle sera très difficile construire En utilisant la fonctionnalité de recherche de relations, l’utilisateur retrouve rapidement les ressources partir des noms du gène et des pathways, et soumet sa requête (figure 4.5) Figure 4.5 – Scénario : entrée de la requête 30 4.1.2 Exécution des requêtes et temps de réponse L’outil OpenLink Faceted utilisé par la fonctionnalité "Quick Search" retourne le temps de recherche effectué Nous observons que la requête du scénario s’exécute en environ 452 millisecondes ; un temps relativement proche de celui offert par les moteurs de recherche classiques Par contre Faceted ne fournit pas de moyen d’effectuer la recherche sur l’aspect sémantique (par exemple rechercher uniquement les gènes) La durée de l’exécution d’une requête par l’éditeur de requête SPARQL dépend des clauses de la requête et des performances du point d’accès SPARQL Plus la requête sera complexe (nombre de clauses, ou type de filtres, ) , plus ce temps sera long Nous avons noté que le temps d’exécution lors de la recherche par formulaire est de l’ordre de 18 secondes (13 puis pour les étapes) dans le scénario (recherche dans la base AgroLD) Il est de 24 secondes (20 puis pour les deux étapes) dans le scénario (interrogation de services web externes) Ce qui indique que la recherche par mot-clé prend beaucoup plus de temps par rapport aux autres actions que peut effectuer l’utilisateur pendant son exploration Nous n’avons pas recueilli le temps d’exécution de la recherche de relation, mais elle semble aussi rapide que le "Quick Search" Cependant, l’utilisateur doit patienter quelques secondes pendant l’affichage des relations qui se fait de manière séquentielle, l’une après l’autre 4.1.3 Présentation des résultats Dans le scénario avec "Quick Search", nous observons une bonne présentation (figure 4.6) sous forme de tableau avec les mot-clés mis en gras pour indiquer où ils ont été retrouvés Les liens hypertext sur les URIs permettent de continuer l’exploration des données (figure 4.6) Figure 4.6 – Scénario : présentation des résultats avec la recherche rapide par mot-clé Par contre l’utilisateur rencontrera beaucoup de difficultés parcourir tous les résultats retournés s’ils sont très nombreux (5537 pour le scénario 1) Par le scénarios 2, nous observons que ce problème peut être résolu en permettant l’utilisateur de préciser le type d’entité qu’il recherche, mais en faisant un choix 31 seulement parmi ceux qui sont proposés par la fonctionnalité "Advanced Search" Les résultats obtenus ici sont plus précis (figure 4.7) Figure 4.7 – Scénario : présentation des résultats La présentation des résultats dans "Advanced Search" et l’éditeur de requêtes SPARQL est aussi faite sous forme de tableaux pour une bonne lisibilité Des liens y sont disponibles pour obtenir des informations complémentaires (liens "display" et URLs dans la figure 4.7) La recherche par formulaire dynamique ("Advanced Search") propose aussi un lien pour une description de ressource dans l’éditeur SPARQL (lien "in SPARQL" dans la figure 4.7) Les résultats retournés dans le scénario sont présentés dans un style proche des citations de documents (figure 4.8) Ainsi la reconnaissance des différentes informations relatives la publication est intuitive Un lien associé permet de se rendre la source de ces informations pour plus de détails Figure 4.8 – Scénario : présentation des résultats Dans le dernier scénario, les relations sont observées sous forme d’arête entre les nœuds d’un graphe pour une plus rapide lisibilité et compréhension L’utilisateur peut filtrer les types de liens qu’il souhaite observer (les liens "type" sont cachés dans la figure 4.9) 4.2 Utilisation des informations de la base AgroLD dans des applications 4.2.1 Utilisation de l’API pour la programmation Le développement du formulaire dynamique était aussi l’occasion de démontrer l’utilisation en programmation de l’API d’AgroLD Comme nous l’avons mentionné 32 Figure 4.9 – Scénario : Relations découvertes entre le gène "adenosylmethionine decarboxylase" (AT3G25570) et les deux pathways "spermine biosynthesis" et "spermidine biosynthesis" dans le chapitre, la description JSON des services de l’API peut être utilisée avec une librairie cliente de SWAGGER (par exemple swagger-client.js pour le JavaScript) Avec swagger-client.js, il suffit de préciser l’URL du fichier JSON, puis les services de l’API peuvent être appelés comme les méthodes d’un objet (swagger.apis) sans se préoccuper des URLs des services ou de la méthode HTTP qu’ils supportent (figure 4.10) Figure 4.10 – Utilisation du service de recherche de gène par mot-clé dans un programme JavaScript En plus de cette facilité, la documentation interactive des services (figure 4.11) permet aux développeurs d’applications d’avoir toutes les informations sur chaque service pour savoir l’utiliser 4.2.2 Utilisation de l’API dans les workflows Dans cette section, nous démontrons comment extraire, dans un workflow, l’identifiant (geneId) et le nom (geneName) des gènes, ainsi que le nom des taxons (taxon_name) correspondant leur participation dans le pathway CALVIN-PWY 33 Figure 4.11 – documentation du service de recherche des protéines associées un identifiant ontologique Figure 4.12 – Intégration de la liste des gènes participant au pathway CALVIN-PWY dans Galaxy La figure 4.12 montre comment se fait la sélection des ressources (services) intégrer dans Galaxy Nous avons choisi le format TSV pour les ressources Nous avons conçu un simple workflow de traitement de données (figure 4.13) Son principe est d’extraire les colonnes geneId, geneName, et taxon_name qui nous intéressent dans notre scénario Il renvoie les colonnes extraites et le nombre ligne de résultats obtenus On peut observer le résultat obtenu dans la figure 4.14 Dans le tableau final (nommé 34 Figure 4.13 – Workflow d’extraction des colonnes 1, et d’un tableau dans Galaxy testResult.tsv), il ne reste plus que les colonnes extraites et 548 résultats ont été retournés Ces résultats démontrent que les ressources exposées par l’API d’AgroLD sont manipulables dans des workflows de Galaxy Figure 4.14 – Résultat de l’extraction des colonnes "geneId", "geneName" et "taxon_name" 35 CONCLUSION La base de connaissance AgroLD est en cours de développement au sein du projet IBC pour palier la rareté des données liées de la biologie des plantes L’objectif de notre travail était de proposer une couche applicative d’accès cette base Pour obtenir une solution pratique et capable de répondre aux besoins des biologistes et bioinformaticiens, nous avons choisi des systèmes existants ayant démontré leur efficacité A ces derniers, nous avons associé de nouvelles fonctionnalités de recherche sémantique Au final, nous proposons une solution avec plusieurs modes d’interrogation La recherche rapide par mot-clé permet une exploration rapide des données d’AgroLD mais reste limitée parce qu’elle s’effectue uniquement au niveau des chaines de caractères La recherche par formulaire dynamique répond aux questions biologiques, et met l’abri de toute connaissance du web sémantique Elle est néanmoins limitée par son expressivité définie par le nombre de fonctionnalités de recherche quelle fournit La découverte de relations entre entités représente un outil puissant pour rapidement observer le lien qui existe entre des ressources connues L’éditeur de requêtes SPARQL assiste les utilisateurs avec la vérification syntaxique, des exemples de requêtes et une présentation conviviale des résultats L’API de services REST fournit aux développeurs d’applications et de workflows bioinformatiques, un moyen d’utiliser les informations d’AgroLD partir de requêtes testées et vérifiées Nous osons croire que la disponibilité des ces systèmes, au sein d’une même plateforme, permettra aux utilisateurs de bénéficier des avantages des divers paradigmes qu’ils implémentent Nous avons effectué une large investigation pour déterminer les systèmes applicables dans notre cas Cependant, nous soutenons l’idée de prendre en compte les appréciations et attentes des utilisateurs potentiels pour guider les développements futurs Ainsi, nous avons intégré un formulaire d’enquête notre prototype Néanmoins, quelques voies d’évolution du projet sont possibles La mise en place d’un système de construction de requêtes visuelles peut accélérer l’édition de requêtes SPARQL D’autre part, il serait important de compléter le formulaire dynamique avec plus de concepts et de questions biologiques Ce formulaire a plus de valeur pour les experts biologistes car elle fait plus de l’agrégation de connaissance que de l’intégration des données Par ailleurs, l’API devrait être améliorée, pas seulement en augmentant le nombre de services offerts, mais aussi en gérant un cache et en optimisant les requêtes pour accélérer le temps d’exécution de ces services 36 Références [1] Sarah Cohen-Boulakia and Ulf Leser Next generation data integration for the life sciences ICDE, 2010 [2] Assia Rharbi, Khadija Amine, Zohra Bakkoury, Afaf Mikou, Anass Kettani, and Abdelkader Betari Lipoproteins - Role in Health and Diseases, chapter - Approaches to Access Biological Data Sources InTech, 2012 [3] Tom Health and Christian Bizer Linked Data : Evolving the Web into a Global Data Space Synthesis Lectures on the Semantic Web : Theory and Technology, 1-136 Morgan & Claypool, 2011 [4] Jeremy Goecks, Anton Nekrutenko, James Taylor, et al Galaxy : a comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences Genome Biol, 11(8) :R86, 2010 [5] Tim Berners-Lee, James Hendler, Ora Lassila, et al The semantic web Scientific american, 284(5) :28–37, 2001 [6] Tim Berners-Lee Linked data-design issues 2006 Disponible http://www.w3 org/DesignIssues/LinkedData.html [7] Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Frystyk, Larry Masinter, Paul Leach, and Tim Berners-Lee Hypertext transfer protocol–HTTP/1.1 Technical report, 1999 [8] Graham Klyne and Jeremy J Carroll Resource description framework (RDF) : Concepts and abstract syntax 2006 [9] Eric Prud’Hommeaux, Andy Seaborne, et al SPARQL query language for RDF W3C recommendation, 15, 2008 [10] Eric K Neumann, Eric Miller, and John Wilbanks What the semantic web could for the life sciences Drug Discovery Today : BIOSILICO, 2(6) :228–236, 2004 [11] UniProt Consortium et al The universal protein resource (UniProt) Nucleic acids research, 36(suppl 1) :D190–D195, 2008 [12] N Redaschi and the UniProt Consortium Uniprot in RDF : Tackling data integration and distributed annotation with the semantic web Nature Prec, 2009 [13] Marc-Alexandre Nolin, Peter Ansell, François Belleau, Kingsley Idehen, Philippe Rigault, Nicole Tourigny, Paul Roe, James M Hogan, and Michel Dumontier Bio2RDF network of linked data In Semantic Web Challenge ; International Semantic Web Conference (ISWC 2008), 2008 37 [14] Simon Jupp, James Malone, Jerven Bolleman, Marco Brandizi, Mark Davies, Leyla Garcia, Anna Gaulton, Sebastien Gehant, Camille Laibe, Nicole Redaschi, et al The EBI RDF platform : linked open data for the life sciences Bioinformatics, 30(9) :1338–1339, 2014 [15] Sébastien Ferré Expressive and scalable query-based faceted search over SPARQL endpoints In The Semantic Web–ISWC 2014, pages 438–453 Springer, 2014 [16] Laurens Rietveld and Rinke Hoekstra The YASGUI Family of SPARQL Clients Semantic Web Journal, 2015 [17] Maulik R Kamdar, Dimitris Zeginis, Ali Hasnain, Stefan Decker, and Helena F Deus ReVeaLD : A user-driven domain-specific interactive search platform for biomedical research Journal of biomedical informatics, 47 :112–130, 2014 [18] Florian Haag, Steffen Lohmann, Stephan Siek, and Thomas Ertl Visual querying of linked data with QueryVOWL In Joint Proceedings of SumPre 2015 and HSWI 2014-15 CEUR-WS, 2015,to appear [19] Dominik Schweiger, Zlatko Trajanoski, and Stephan Pabinger SPARQLGraph : a web-based platform for graphically querying biological Semantic Web databases BMC bioinformatics, 15(1) :279, 2014 [20] Jin-Dong Kim and K Bretonnel Cohen Natural language query processing for SPARQL generation : A prototype system for SNOMED CT In Proceedings of BioLINK, pages 32–38, 2013 [21] Kathryn Whitenton Filters vs Facets : Definitions, 16 Mars 2014 Disponible http://www.nngroup.com/articles/filters-vs-facets/ [22] Orri Erling and Ivan Mikhailov Faceted Views over Large-Scale Linked Data In LDOW, 2009 [23] Florian Haag, Steffen Lohmann, Steffen Bold, and Thomas Ertl Visual SPARQL Querying based on Extended Filter/Flow Graphs In Proceedings of the 12th International Working Conference on Advanced Visual Interfaces (AVI ’14), pages 305–312 New York, NY, USA : ACM, 2014 [24] Philipp Heim, Sebastian Hellmann, Jens Lehmann, Steffen Lohmann, and Timo Stegemann RelFinder : Revealing relationships in RDF knowledge bases In Semantic Multimedia, pages 182–187 Springer, 2009 [25] 3scale Networks S.L What is an API ? Your guide to the Internet Business (R)evolution, 2011 Disponible http://www.3scale.net/wp-content/uploads/ 2012/06/What-is-an-API-1.0.pdf [26] Cesare Pautasso RESTful Web Services : Principles, Patterns, Emerging Technologies Web Services Foundations, Springer Science+Business Media New York, pages 31–51, 2014 38 [27] R.T Fielding and R.N Taylor Principled design of the modern Web architecture ACM Transactions on Internet Technology, 2(2) :115–150, 2002 [28] Paul Groth, Antonis Loizou, Alasdair J.G Gray, Carole Goble, Lee Harland, and Steve Pettifer API-centric Linked Data integration : The Open PHACTS Discovery Platform case study Web Semantics : Science, Services and Agents on the World Wide Web, 29(0) :12 – 18, 2014 Life Science and e-Science [29] Alejandro González, Alison Callahan, José Cruz-Toledo, Adrian Garcia, M Egaña Aranguren, Michel Dumontier, and Mark D Wilkinson Automatically exposing OpenLifeData via SADI semantic Web Services J Biomed Semantics, 5(1) :46, 2014 [30] Mikel Egaña Aranguren, Alejandro Rodríguez González, and Mark D Wilkinson Executing SADI services in Galaxy Journal of biomedical semantics, 5(1) :42, 2014 [31] Olaf Hartig and Andreas Langegger A Database Perspective on Consuming Linked Data on the Web Datenbank-Spektrum, 2010 [32] Victoria Uren, Yuangui Lei, Vanessa Lopez, Haiming Liu, Enrico Motta, and Marina Giordanino The usability of semantic search tools : a review The Knowledge Engineering Review, 22(04) :361–377, 2007 [33] Miel Vander Sande, Pieter Colpaert, Davy Van Deursen, Erik Mannens, and Rik Van de Walle The datatank : an open data adapter with semantic output In 21st International Conference on World Wide Web, Proceedings, page Citeseer, 2012 [34] Khadija Elbedweihy, Stuart N Wrigley, Fabio Ciravegna, Dorothee Reinhard, and Abraham Bernstein Evaluating semantic search systems to identify future directions of research In The Semantic Web : ESWC 2012 Satellite Events, pages 148–162 Springer, 2012 [35] John Brooke Sus-a quick and dirty usability scale Usability evaluation in industry, 189(194) :4–7, 1996 39 Annexes Tableau A.1 – Comparaison de clients SPARQL 40 [...]... Ces modules organisés de manière séquentielle, 16 3scale : www.3scale.net 17 Figure 2.7 – Architecture standard des applications de données liées et ouvertes ont chacun un r le [3] important à jouer dans la chaîne d’intégration : — Le module d’accès web collecte les données du web : les architectures utilisées ici peuvent être : — le patron d’exploration ("the crawling pattern") qui explore le web à... déréférençables via le protocole HTTP [7] pour permettre qu’on puisse accéder aux descriptions des ressources identifiées — Lors de l’accès par ces URI, des métadonnées décrivant la ressource référencée doivent être retournées, en suivant les standards RDF [8] et SPARQL [9] Parmi les URI définis dans la base AgroLD, certaines ne sont pas encore déréférençables par le protocole HTTP comme présenté dans l’exemple... triplet, deux nœuds deux graphes distants l’un de l’autre, un graphe plus grand est établi Figure 2.1 – Exemple de graphe de données liées (source : http: // linkedlifedata com/ about ) SPARQL quant à lui est à la fois un protocole et un langage d’interrogation des bases RDF Sa syntaxe est proche de celle de SQL pour les bases de données relationnelles La requête suivante, par exemple, détermine les... aujourd’hui de publier leur données à travers les technologies web sémantiques Cela peut se faire soit en convertissant les bases existantes en base de triplets (materialisation des données [1]), soit en traduisant les requêtes SPARQL (réécriture des requêtes [1]) des utilisateurs dans le langage liée à la structure des données (par exemple SQL pour les base de données relationnelles) Les sciences de la... "timeout" : le délai maximal de temps pour l’exécution ; — "format" : le format dans lequel seront retournés les résultats (tableau HTML, XML, CSV, RDF/XML, RDF/Turtle, ) Certains publieurs de données améliorent l’utilisabilité de leurs clients SPARQL en intégrant des librairies d’édition de code (texte de la requête) et de gestion des résultats Par exemple, UniProt 5 et « linked life data » 6 joignent... propose plus de flexibilité dans la sélection des informations à retourner (QueryVOWL par exemple ne retourne pas des lignes de résultats où on peut voir la relation entre les différentes valeurs des variables de requête, mais uniquement le label du nœud sélectionné) SPARQLGraph 12 [19], comme ReVeaLD [17], a été développé dans le contexte des sciences du vivant en prenant en compte leur spécificité... services web sont généralement utilisées Dans ce cas, les services basées sur les principes RESTful présentent plus d’avantages (Figure 2.5 [26]) que les services dits WS-* (basés sur le protocole SOAP) REST (« REpresentational State Transfer ») [27] est un style architecture décrivant un ensemble de contraintes que doit respecter un service Web Le plus intéressant dans ce style est sa simplicité, la... l’utilisation possible de plusieurs formats existant pour retourner les résultats des requêtes Figure 2.5 – Avantages des services RESTful sur les services basées sur SOAP (WS-*) Dans le domaine de l’intégration de données liées, certains projets ont démontré les avantages de fournir l’accès aux données via des API de type RESTful Le projet Open PHACTS Discovery Plateform [28], par exemple, exploite les données... Ces modules sont décrits dans la section cidessous Les autres modules relevant du fonctionnement de l’API sont : — le médiateur qui est l’implémentation de l’API et donc effectue les requêtes SPARQL nécessaires vers la base de données et les services externes pour répondre aux requêtes venant des application tierces ; — les définitions déclaratives qui décrivent précisément les liens entres les services... incrémentale car chaque module a une fonction bien précise De plus, Open PHACTS Discovery Plateform dispose d’un contr le d’accès à travers le gestionnaire d’API, 3scale 16 , et d’un pilote pour l’intégration dans le système de Workflow KNIMES Le contr le d’accès peut être important lorsqu’on veut gérer des aspects comme [28] des services payants, le suivi de l’utilisation de l’API, ou encore le respect