Spécifications de la Plateforme OrphaMine
publicité
Spécifications de la Plateforme OrphaMine Chedy Raïssi 24 juillet 2013 1 Table des matières 1 Présentation de la plateforme OrphaMine 1.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Les contraintes . . . . . . . . . . . . . . . . . . . . . . 2 2 3 2 État de l’art 2.1 Gestion des données . 2.2 Fouille de données . . . 2.3 Visualisation . . . . . . 2.3.1 Les étapes de la . . . . 4 4 6 6 7 . . . . 7 8 9 10 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . visualisation de 3 Orphamine 3.1 CouchDB . . . . . . . . . . . . . 3.2 Fouille de Données . . . . . . . . 3.2.1 Extraction de motifs . . . 3.2.2 Énumération des cliques et . . . . . . . . . . . . . . . données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . des quasi-cliques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Visualisation de Données 12 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1 Modèles de Représentation . . . . . . . . . . . . . . . . 13 4.1.2 Diagramme Cordal . . . . . . . . . . . . . . . . . . . . 13 5 Conclusion et Perspectives 15 1 Présentation de la plateforme OrphaMine Dans le cadre du projet ANR Hybride, l’équipe-projet ORPAILLEUR a décidé après concertation avec les différents partenaire du projet de développer une plateforme de web services qui permet la visualisation ainsi que l’intégration de données et des algorithmes de fouille. Les données étudiées traitent des maladies orphelines. Mais l’objectif à long terme est le développement d’outils offrant le plus d’abstraction possible du type de données étudiées afin de gérer une masse de données hétérogènes. Le but premier du portail OrphaMine est de fournir des outils d’analyses ouverts au public ainsi qu’aux médecins ou d’autres chercheurs. La visualisation des données est une étape importante dans leur compréhension. Celle-ci doit être intelligente et réfléchie afin que l’utilisateur puisse en tirer les informations recherchées. L’objectif principal est de permettre la mise en évidence de ces informations alors que le jeu de données est très vaste. Pour permettre un apport de connaissances de ces données, la visualisation se base sur des résultats issus d’algorithmes de fouille de données. Ainsi, les informations extraites des différentes recherches (généralement des motifs fréquents dans les données) sont utilisées dans ce but. 1.1 Objectifs L’enjeu pour l’équipe ORPAILLEUR et le projet Hybride Le premier but recherché est de permettre un affichage des données présentes dans une ontologie appelée OrphaData (http://www.orpha.net). Cet ensemble de données est issu du projet Orphanet coordonné par l’INSERM dont le but est de rassembler toutes les informations concernant les maladies orphelines. Ces maladies rares sont encore très peu connues et beaucoup de données scientifiques restent encore floues ou incorrectes. Cette ontologie, uniquement disponible au format XML 1 , n’offre pas de visualisation et ne permet donc pas une compréhension aisée aux utilisateurs, généralement des médecins qui n’ont pas forcément de base en informatique. De plus, sous le format actuel, il est impossible d’interagir avec les données de manière simple et rapide. 1. XML : l’Extensible Markup Language est un langage informatique utilisé pour l’échange de données. 2 Le deuxième but, plus ancré dans le projet ANR Hybride, est de permettre l’intégration des algorithmes de fouilles des différentes équipes et acteurs du projet dans une plateforme ouverte et facilement accessible afin de permettre l’échange et l’analyse dans le cadre du projet. L’enjeu est donc la mise en place d’un véritable portail collaboratif qui servira aux différents acteurs du projet Hybride avec : – Une visualisation générale des données OrphaData pour les médecins qui travaillent, mettent à jour et développent cette base. – Une intégration des algorithmes de fouilles développés par les différents acteurs académiques. – L’utilisation de ces algorithmes afin d’améliorer OrphaData. Les objectifs pour arriver à la mise en place de ce portail sont dans un premier temps le développement d’une API 2 sous forme d’un service web ergonomique et disposant d’une forte abstraction du type de données dont il va permettre l’accès. Cette API pourra servir aux développeurs et différents chercheurs, afin de récupérer des données sous un format précis pour la mise en place et l’utilisation d’algorithmes de fouille de données. Mais aussi, pour le développement même du portail sous la forme d’un site Internet de nouvelle génération (HTML5) qui pourra être facilement visionné sur des tablettes tactiles et smartphones, qui sont de plus en plus utilisés. Ce site se base intégralement sur des web services. Ainsi il est important de mettre un fort accent sur la conception de l’API qui sera réutilisé avec d’autres projets et non uniquement pour les données d’OrphaData (pérennité du développement). 1.1.1 Les contraintes Pour arriver à ce résultat, plusieurs contraintes doivent être respectées : du fait que l’API sera un point d’accès à un grand volume de données très diverses, il est important de veiller à garder une flexibilité et une abstraction lors de leurs traitements. Par la suite, il est aussi nécessaire de comprendre les algorithmes de fouilles intégrés au portail afin de permettre une interactivité et une visualisation adaptée. De plus, comme nous souhaitons offrir une visualisation dynamique à l’utilisateur, des contraintes de rapidité et de facilité d’accès sont aussi impliquées. 2. API : Application Programing Interface 3 2 État de l’art Afin de mieux comprendre les enjeux et défis pour le développement du portail OrphaMine, nous allons décrire l’état actuel des techniques utilisées dans les différents domaines en relation avec le développement de notre plateforme. Cette description permettra d’introduire certains concepts nécessaire à la compréhension de la suite de ce rapport. Les domaines étudiés sont dans un premier temps le stockage des données où nous parlerons du type de système de gestion de base de données (SGBD) qui sera utilisé. Puis des différentes techniques de fouilles employées et enfin nous aborderons certains concepts de visualisations. Cette partie mènera à une discussion sur les différents choix qui ont été effectués pour chacun de ces domaines. 2.1 Gestion des données Le choix de la méthode de stockage des données est la première étape logique dans la conception d’une API visant le traitement de données à relativement grande échelle. Ce choix dépend bien évidemment du type et de la quantité de données à stocker, et nous nous retrouvons ici dans le cas de données hétérogènes et diverses, que nous pouvons qualifier de non structurées, dans un volume relativement important. Il est donc primordial de disposer d’une base de données flexible qui sera en mesure de stocker toutes nouvelles données issues de fouilles, ou de ressources qui seraient intégrées au jeu déjà existant. C’est pour répondre à ce type de nouveau besoin que le NoSQL a été introduit assez récemment [Cou]. Le NoSQL est un type de stockage des données employées par certains SGBD au même titre que le modèle relationnel. Le modèle de données entre l’approche relationnelle et NoSQL est très différent. Dans le cas d’un modèle relationnel, les données sont séparées dans une multitude de tables liées entre elles par un schéma logique. Ces relations sont stockées dans des tables par le biais de clés étrangères. Ainsi, lors de la récupération des données, cellesci doivent être collectées dans plusieurs endroits et combinées avant d’être présentées à l’utilisateur. Une base de données NoSQL orientée documents procède différemment. Les données y sont stockées au sein de documents souvent au format JSON 3 3. JSON : JavaScript Object Notation 4 Figure 1 – Exemple de stockage d’un élément dans un document d’une base NoSQL et dans des tables d’une base relationnelle. qui sont eux-mêmes séparés en objets utilisables par l’application finale. Un document pourrait par exemple représenter un utilisateur qui, dans une base relationnelle, serait séparé en une multitude de tables (cf. Figure 1). Cette approche a le désavantage d’être moins efficace en terme de stockage, à cause de la redondance de certaines informations. Cependant, ce désavantage est mineur quand au gain de performances au niveau de la lecture et écriture de données. Une autre grande différence entre une base relationnelle et une NoSQL est l’absence de schéma de données dans cette dernière. Alors qu’il est très difficile dans une base de données relationnelle de changer la structure des tables une fois que des données sont déjà présentes, cette difficulté n’existe pas dans une base NoSQL où l’ajout de nouveaux types de données est très aisé. De plus, une base de données NoSQL reste facilement extensible, ce qui lui permet une gestion rapide d’un grand volume de données (Big Data). Alors que le modèle relationnel n’est que facilement extensible de façon verticale (par une augmentation de la puissance du serveur généralement très couteuse), les technologies NoSQL permettent une extensibilité horizontale, par une augmentation du nombre de serveurs. Afin de permettre la création d’une RIA 4 utilisant les données de notre base, la partie cliente utilise une architecture en AJAX 5 . Cette architecture est caractérisée par son fonctionnement en asynchrone. Ce fonctionnement 4. RIA : Rich Internet Application 5. AJAX : Asynchronous JavaScript And XML 5 permet la récupération des données du serveur après le chargement de la page web de la RIA. Cette approche, où les données sont dynamiquement intégrées à la page, permet d’éviter au client d’avoir à recharger la page complète. Couplé aux technologies mises en place par l’HTML5 tel que le SVG 6 , l’AJAX permet la réalisation d’une RIA dynamique et fonctionnelle. 2.2 Fouille de données Le domaine de la fouille de données, aussi appelée exploration de données, permet d’extraire des connaissances d’un grand jeu de données. L’une des applications souvent utilisée est la recherche de motifs fréquents dans les données [eHW10]. Ce domaine de recherche est entièrement en adéquation avec la problématique du projet ANR Hybride, où l’on va rechercher des éléments communs entre différentes maladies (des motifs) parmi le jeu de données d’OrphaData (vu conceptuellement comme un grand graphe). Ces motifs présents dans les données vont nous permettre de comprendre, une fois extraits par la fouille, une partie de la base de données. Ce mode de recherche se rapproche beaucoup de la méthode naturelle qu’une personne ferait pour comprendre un grand volume d’informations, à savoir le regroupement des données proches pour permettre une vision plus globale du problème. Au même titre que la recherche de motifs, la fouille de données peut aussi rechercher ce que l’on appelle des cliques, ou graphes complets 7 . Ces cliques vont nous indiquer des groupes de nœuds fortement liés. On parle aussi de quasi-cliques dans le cas de graphes quasi-complets, c’est-à-dire un graphe complet auquel il manquerait un nombre γ d’arêtes. 2.3 Visualisation Le choix du type de visualisation à utiliser pour un jeu de données se base sur plusieurs facteurs, tel que le type des données à afficher (que ce soit un arbre avec une hiérarchie par exemple, ou des données temporelles etc.), ainsi que les informations recherchées. Il est important, d’autant plus si le jeu de données est volumineux, de bien identifier le but de la visualisation. Cela revient à trouver la question 6. SVG : Scalable Vector Graphics 7. Graphe complet : graphe où tous les nœuds sont reliés entre eux 6 à laquelle nous voulons répondre par le biais de l’affichage. Bien évidement, du fait que toutes les données collectées sont riches et diverses, il est normal de vouloir mettre en place un affichage flexible. La démarche à adopter reste la même, soit la mise en évidence d’éléments clés. Il faut alors identifier plusieurs problèmes auxquels cette visualisation pourra répondre de façon claire, en supprimant les détails superflus. 2.3.1 Les étapes de la visualisation de données Le processus permettant d’arriver à la compréhension des données passe par plusieurs étapes [Fry08] : • L’acquisition : que ce soit à partir d’une base de données sur Internet, ou de publications. • L’analyse : afin de donner une structure aux données de façon à les stocker en fonction de leur signification. • Le filtrage : pour ne garder que les données qui nous intéressent. • La fouille : appliquer les méthodes de fouille de données de façon à faire apparaitre des motifs. • Symboliser : choisir un modèle visuel basique afin de représenter les données, tel qu’un diagramme de barres, ou un arbre. • Raffiner : adapter ce modèle basique de façon à ce qu’il soit le plus clair et le plus attrayant possible. • Interagir : rajouter des moyens de manipuler les données, ou de contrôler les caractéristiques représentées. Ces étapes sont chacune d’une importance variable en fonction des données traitées. Par exemple, lors de la récupération des données OrphaData, la phase d’analyse ne sera que très courte du fait que les données sont déjà présentes sous forme d’une ontologie. De plus, chaque étape peut influencer les autres si bien que l’affichage final est en fait un processus itératif comme illustré sur la figure 2. Cet exemple montre (entre autre) que l’étape d’interaction a modifiée l’étape de raffinage. Ce qui peut s’illustrer par une mise en évidence des éléments avec lesquels l’utilisateur interagit. 3 Orphamine La réalisation du portail passe par une API dont les appels sont traités presque intégralement par le serveur de base de données. Cette API est sous 7 Figure 2 – Exemple d’interactions entre les différentes étapes de la visualisation des données. la forme d’un service web de type REST 8 . Son accès est donc simplifié afin de permettre une utilisation intuitive aux différents acteurs participant au développement. Ce choix a été déterminé par l’orientation très “données" du web service. 3.1 CouchDB La base de données est implémentée par le SGBD CouchDB. Cette base est de type NoSQL orienté document. C’est-à-dire que les tables sont représentées par des documents au format JSON accessibles par l’intermédiaire de fonctions de map et de mapreduce. Ces fonctions sont l’équivalent des vues d’une base de données classique. Les vues sont l’unique moyen d’accéder aux données (cf. Figure 3). Contrairement à une base de données relationnelle, elles sont indispensables afin de filtrer et d’organiser les données qui ne sont pas structurées. Les vues sont définies par des fonctions en langage JavaScript. Une vue prend un document JSON en tant que paramètre et fait tout le traitement nécessaire afin de déterminer et de rendre les données à renvoyer accessibles. Toutefois, la génération d’une vue est très consommatrice en temps et en ressources et ne devrait pas être une opération que le système réalise à chaque requête d’un client. Afin de permettre un temps de réponse court, le résultat des vues est sauvegardé (mis en cache) lors de sa première exécution. Ce procédé est permis par la génération d’un index de vues par CouchDB qui est mis à jour à chaque changement des données. Concrètement, le SGBD va en fait mettre en cache les résultats de l’analyse des documents JSON de façon à ne pas avoir à le refaire pour chaque requête utilisateur. 8. REST : REpresentational State Transfer 8 Figure 3 – Interaction des éléments de l’API de type REST L’un des grands avantages lors de l’utilisation de CouchDB est la flexibilité du format des données au moment de la récupération d’une vue. Cet avantage est mis à disposition par les fonctions appelées de liste et nous permet d’acquérir l’abstraction souhaitée du type de données stockées en base (leur nom vient de leur fonctionnement : elles récupèrent une liste de données à traiter). Ces fonctions peuvent être utilisées indépendamment de la vue et sont exécutées à la demande du client pour permettre une transformation aisée des données dans une multitude de format. Dans OrphaMine, ces fonctions sont utilisées notamment pour obtenir des données se prêtant à l’utilisation dans des pages webs de type HTML5 permettant un affichage direct dans le portail. Mais le format CSV 9 est aussi utilisé afin de les rendre compatibles aux données d’entré de certains algorithmes de fouilles. Comme illustré sur la figure 4, les fonctions de liste sont situées en amont des vues. Elles récupèrent les données qui auraient été reçues par le client sans leur appel et permettent la transformation de ce résultat. 3.2 Fouille de Données L’intégration des algorithmes de fouille au portail web est une partie très importante du développement du portail OrphaMine et cette intégration continuera pendant toute la durée du projet ANR Hybride. Les algorithmes présentés en tant que web services vont fouiller dans les données 9. CSV : Comma-Separated Values 9 Figure 4 – Illustration de la flexibilité de l’API présentes dans la base (préalablement formatées pour satisfaire les besoins de l’algorithme comme énoncé plus tôt). Cette Intégration a comme but de permettre l’utilisation par les médecins, et même par un certain public averti, des différentes analyses de données possibles. Par la suite, afin de permettre une intégration aisée, les résultats issus de cette fouille vont être stockés dans une nouvelle base de données. Ce mode de fonctionnement nous permet de profiter de tous les avantages des fonctions list, tout en copiant le mode opératoire des vues de CouchDB qui ne s’exécutent qu’une seule fois. Cette approche nous permet de réaliser le traitement en avance et nous est utile dans le cas de fouilles mettant beaucoup de temps de traitement. La suite de cette partie va expliquer les apports et le fonctionnement des algorithmes de fouille incorporés au portail actuel. 3.2.1 Extraction de motifs L’extraction de motifs est appliquée ici pour rechercher des groupes de maladies au sein des données de OrphaData. Les motifs indiquent des relations avec les gènes et les signes cliniques en commun entre les maladies. Ainsi un groupe de maladies résultant de cette fouille présentera toujours 10 des maladies possédants beaucoup de points en commun (comme des gènes en communs ou des signes cliniques identiques). L’extraction de ces groupes n’a que peu d’intérêt dans cet état brut. Nous pouvons éventuellement les utiliser dans le but de les comparer aux familles de maladies déjà identifiées et aider ainsi à corriger d’éventuels points flous dans le développement de l’ontologie OrphaData. Mais là où l’analyse montre tout son potentiel, est lors de l’ajout du paramètre de bruit, qui représente un seuil d’écart autorisé entre chaque maladie d’un groupe par rapport aux autres maladies de ce groupe, lors de la recherche. Concrètement, cette nouvelle notion nous permet d’obtenir des groupes de maladies où certaines relations sont inexistantes, mais autorisées par l’algorithme. De ce fait, si nous comparons ces résultats aux données déjà existantes dans la base de données OrphaData, nous pouvons relever des relations qui potentiellement n’auraient pas encore été découvertes par les médecins (le portail permet actuellement de comparer ces résultats avec l’ensemble des publications médicales pubmed http://www.ncbi.nlm.nih. gov/pubmed). 3.2.2 Énumération des cliques et des quasi-cliques La recherche de cliques (et de quasi-cliques), ou de graphes complets (et quasi-complets), permet d’identifier des nœuds fortement liés. Le résultat souhaité est donc identique à la fouille précédente, cependant le procédé utilisé est différent et permet de rajouter les contraintes structurelles aux données traitées. L’analyse de graphe a pour même objectif de trouver des données qui pourraient ne pas avoir encore été découvertes dans la base de OrphaData. Par rapport à l’algorithme de fouille classique précédent, cette fouille de données prend en considération la structure des données et les différents liens entre maladies, gênes, signes cliniques et hiérarchies médicales. Cette caractéristique permet de subsumer 10 les nœuds (ici les maladies) par leur classification (leur famille). Cet algorithme prend en paramètre un graphe de maladies afin d’en rechercher des sous graphes complets. Les liaisons entre les maladies sont déterminées par les gènes qu’elles ont en commun. Une relation entre un gène est une maladie est identifiée lorsque les médecins prouvent que ce gène a un rôle sur la présence de la maladie chez les patients. Le résultat de la 10. Subsumer : généraliser un ou plusieurs concepts précis, par un autre plus global 11 fouille est donc un ensemble de cliques qui va nous indiquer des groupes de maladies possédant beaucoup de points en commun. En autorisant, comme avec l’algorithme précédent, une certaine tolérance au bruit, nous pouvons identifier des relations potentiellement existantes, mais encore inconnues par les médecins. Cette tolérance au bruit est décrite d’une manière différente toutefois. Elle ne va plus représenter les écarts autorisés dans la pondération des relations entre les nœuds, mais elle va autoriser un certain nombre de liaisons qui ne devraient pas être présentes. 4 4.1 Visualisation de Données Introduction Afin de permettre une visualisation adaptée aux résultats des fouilles précédentes (ainsi que des données brutes), il est primordial de se concentrer sur l’aspect étudié de façon à pouvoir choisir un modèle de représentation en rapport. Cependant, les informations recherchées par les utilisateurs peuvent être différentes. Par exemple, un médecin rechercherait sans doute des informations différentes qu’une personne de la famille d’un patient. De façon à pouvoir mettre en place un portail adapté à un maximum de personnes il faut donc laisser le choix de la visualisation à l’utilisateur. Dans cette partie nous verrons les visualisations déjà implémentées et utilisées dans le portail. Et pour chaque modèle de représentation, nous discuterons de l’objectif visé ainsi que des interactions possibles. Mais avant cela, faisons un point sur la mise en place technique de cette partie. La visualisation est une part importante du portail. Afin de permettre un affichage dynamique et au maximum compatible avec les nouveaux terminaux, elle est intégralement réalisée en HTML5 grâce au format SVG. Afin de développer le plus simplement possible les différents modèles de représentation des données que nous souhaitons rendre disponibles aux utilisateurs, nous utilisons la bibliothèque appelée Data-Driven Documents, abrégée d3js (http://wwwd3js.org). Cette bibliothèque est libre et permet la création de graphiques SVG en fonction des données qu’elle reçoit en paramètre. Le pont entre d3js et le serveur se fait par l’intermédiaire de requêtes asynchrones via AJAX. Les données reçues sont formatées par la base de données de façon à ce que la partie cliente n’ait que l’affichage à gérer. 12 4.1.1 Modèles de Représentation Graphe La première représentation des données qui fut utilisée est un affichage en graphe tel qu’il est représenté en Figure 5. Ce choix, se rapprochant le plus de la structure originaire des données brutes, était le premier choix logique. Chaque nœud du graphe représente un élément unique où la couleur indique son type (ici, le rose représente les maladies, le vert les signes cliniques et le gris les gènes). La taille du nœud apporte aussi une indication (ici, la taille représente le nombre de liens que le nœud possède). Enfin les liens entre les nœuds montrent une relation où la couleur va indiquer ses caractéristiques. L’objectif de ce type de visualisation est de permettre d’identifier très facilement tous les éléments d’un jeu de données. L’obtention d’informations telles que l’importance de chaque élément est aussi mis en avant par plusieurs paramètres comme la taille ou la couleur des nœuds. L’un des avantages de cette visualisation est qu’il est très facile de jouer sur les paramètres d’affichage des nœuds (par exemple : taille, couleur, transparence, etc...) en fonction des souhaits de l’utilisateur. Dans notre exemple, la taille des nœuds représente le nombre de liens que le nœud possède. Mais il serait peut-être intéressant de visualiser d’autres informations telles que la prévalence des maladies par ce paramètre, afin d’identifier d’un seul coup d’œil les maladies les plus communes. Toutefois, cette représentation des données oblige de calculer la position des nœuds de façon à ce qu’ils ne se chevauchent pas. Ce calcul se fait par une simulation de gravité où chaque noeud est attiré vers le centre du schéma (de façon à ce qu’ils soient tous regroupés), mais où aussi ils se repoussent tous (de façon à ce qu’ils ne se chevauchent pas). Il est aussi important de noter que ce mode de représentation n’est pas adapté à une visualisation efficace des relations entre les nœuds. L’information peut paraitre vite confuse dans le cas d’un jeu de données disposant de beaucoup de liaisons entre les nœuds tel que dans le cas de la fouille de cliques observée dans la partie 3.2.2. 4.1.2 Diagramme Cordal Diagramme Cordal Cette seconde représentation des données est complémentaire d’une visualisation en graphe. Les éléments y sont représentés par des traits positionnés sur une sphère comme illustré en figure 6. La couleur, de la même façon que pour le graphe, va indiquer ici le type du nœud. 13 Figure 5 – Visualisation d’un résultat de fouille sous la forme d’un graphe. Figure 6 – Visualisation d’un résultat de fouille sous la forme d’un diagramme cordal. 14 Mais cette fois-ci les relations sont indiquées par des traits beaucoup plus gros entre chaque nœud. Le souhait est clairement d’apporter des informations sur les relations entre les nœuds. Ainsi, les relations mises en avant par une fouille apparaissent tout de suite et il est facile pour l’utilisateur d’identifier les nœuds concernés. Cette affichage reprend plusieurs éléments du graphe en remplacent la place centrale des nœuds par les relations. Le principal avantage de cette visualisation est, de la même façon que pour l’affichage en graphe, qu’il est possible de jouer sur plusieurs caractéristiques tel quel la taille et la couleur des traits. Cependant, les informations mises en évidence concernent maintenant les relations. Il est ainsi possible de pondérer certaines relations en spécifiant une taille plus ou moins importante du trait. De cette manière il serait possible, par exemple, de repérer tous les signes cliniques d’une maladie en fonction de leur fréquence si on adapte la caractéristique de la taille à cette donnée. Cette représentation est cependant limitée par le nombre de nœuds représentés. L’identification des nœuds concernés par les relations mises en avant devient difficile lorsque leur nombre est important. 5 Conclusion et Perspectives Beaucoup de travail doit encore être fait pour le portail OrphaMine. L’un des prochains objectifs est de permettre une évaluation automatique de la pertinence des résultats d’une fouille, en analysant directement la présence des données concernées dans les publications des médecins. Ainsi, si une relation potentiellement manquante apparaît comme probable par les médecins, nous pourrions orienter les recherches à mener dans cette direction. Cette action s’inscrit complètement dans l’orientation du projet ANR Hybride qui prône l’utilisation d’outils de traitement de la langue afin de mieux aiguiller ou orienter le processus d’analyse de données. D’un point de vu ergonomique, le rendu du site sur terminaux mobiles doit encore être amélioré, ainsi que l’esthétique globale, du fait que l’accent a été mis en premier lieu sur la conception et la réalisation d’une API complète. La base fonctionnelle de l’API, et le portail, est présente. Cependant, il reste encore beaucoup de chemin à parcourir afin d’implémenter de nouvelles fonctionnalités qui seront souhaitées par les médecins et chercheurs au fur et à mesure de la progression du projet. 15 Figure 7 – Quelques exemples de pages du portail actuel OrphaMine. 16 Figure 8 – Quelques exemples d’analyses de données sur le portail actuel OrphaMine. 17 Références [Cou] Couchbase. Why nosql ? Website. http ://www.couchbase.com/why-nosql/nosql-database. [eHW10] Charu C. Aggarwal et Haixun Wang. Managin and Mining Graph Data. Springer, 2010. [Fry08] Ben Fry. Visualizing Data. O’REILLY, 2008. [Tou11] Yannick Toussaint. Hybride, présentation de projet, 2011. 18
