Spécifications de la Plateforme OrphaMine

Spécifications de la Plateforme OrphaMine
Chedy Raïssi
24 juillet 2013
1

Table des matières
1 Présentation de la plateforme OrphaMine 2
1.1 Objectifs.............................. 2
1.1.1 Les contraintes . . . . . . . . . . . . . . . . . . . . . . 3
2 État de l’art 4
2.1 Gestion des données . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Fouillededonnées......................... 6
2.3 Visualisation............................ 6
2.3.1 Les étapes de la visualisation de données . . . . . . . . 7
3 Orphamine 7
3.1 CouchDB ............................. 8
3.2 FouilledeDonnées ........................ 9
3.2.1 Extraction de motifs . . . . . . . . . . . . . . . . . . . 10
3.2.2 Énumération des cliques et des quasi-cliques . . . . . . 11
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éve-
lopper 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éve-
loppement 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 visualisa-
tion 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 2sous 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 interac-
tivité 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 plate-
forme. 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 à rela-
tivement 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 don-
né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, celles-
ci 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