Implémentation de ces critères

Les données des critères précédents sont stockées dans des relations distinctes des données de l’entrepôt. Pour l’instant, chaque critère donne lieu à une relation. La nomenclature automatique et normalisée de la relation permet d’ajouter ou supprimer un critère sans le coder statiquement (« en dur »). Cependant, les opérations pour modifier les valeurs sont dépendantes du critère.

L’application du critère d’utilisation peut se faire { deux niveaux : au niveau du serveur, les procédures stockées métier permettent d’encapsuler ces opérations en toute transparence. On peut paramétrer l’API pour activer ou désactiver cette fonctionnalité. Lors de la construction initiale de l’entrepôt, ou lors de mises { jour, on désactive cette fonction. Lorsque l’application cliente souhaite stocker au niveau du serveur le critère d’utilisation (pour mutualiser l’usage au sein d’un laboratoire par exemple), le développeur l’active. Ces opérations peuvent aussi être directement encapsulées dans les interactions du client graphique :

- elles peuvent être spécifiques à une application,

- elles peuvent être affinées en fonction de l’interaction réalisée dans l’application cliente et pas simplement de l’opération d’accès ou de modification présente dans l’API,

- elle est applicable lorsque l’on ne dispose pas d’un serveur et donc pas de procédures stockées.

6.5 Synthèse

Nous venons de présenter la couche interactive de notre environnement. Elle répond aux principaux besoins que nous avons énumérés dans la section 6.2.1. En positionnant des points fixes, on peut dessiner les différentes parties d’une cellule, et leur rattacher des mots clés et les gènes correspondant. Le fond de carte, figé ou non, peut être différent du graphe dessiné par- dessus. La projection de données multidimensionnelles nous est apparue satisfaisante du point de vue du respect des distances et du voisinage. L’évolution de la vue est dynamique : l’utilisateur peut interagir en continu pour filtrer les données, annoter des éléments, etc. Des contrôleurs permettent d’adapter la vue et de la faire évoluer en fonction des besoins. Les feuilles de styles permettent de spécifier le contenu que l’on souhaite visualiser et d’homogénéiser les interfaces des utilisateurs, qu’il s’agisse de clients riches ou de portails.

Les données systèmes d’information du domaine peuvent être intégrées et visualisées en lien avec les données expérimentales du chercheur. Les lentilles métiers permettent de proposer des « requêtes interactives », une alternative visuelle aux systèmes à base de liens et aux langages de requêtes traditionnels.

La boîte { outils est extensible, sa mise en œuvre est simple et en lien avec les données de l’entrepôt. Pour fédérer le développeur, elle propose de nombreuses fonctionnalités pour accéder aux systèmes d’information externes, gérer des vues multiples, des sélections, exporter des données (captures d’écrans, export vers des tableurs, etc.). La plupart des graphes que nous visualisons ont un nombre d’arêtes linéaires en fonction du nombre de nœuds, ce qui permet de visualiser des graphes de l’ordre de plusieurs milliers de nœuds avec fluidité.

La quantité de données présentes dans l’entrepôt est nettement supérieure aux capacités de notre boîte { outils et ces données sont difficilement manipulables par l’utilisateur. Nous avons mis en œuvre un mécanisme d’extraction de carte permettant { partir d’un algorithme d’analyse de lien d’isoler une portion utile de l’entrepôt. Les données sont adaptées à une station de travail courante et à la boîte à outils graphique, mais il subsiste une surcharge cognitive pour l’utilisateur. Des mécanismes d’adaptabilité complémentaires sont proposés, et qui permettent de prendre en compte :

- les préférences de l’utilisateur au niveau des métadonnées, - la distribution des données,

- les interactions de l’utilisateur, - des critères de pertinence.

Tous ces critères d’adaptabilité s’intègrent correctement dans la méthode de visualisation qui permet une adaptation de la vue continue. L’application de ces mécanismes n’est pas sans rappeler le fonctionnement d’une lentille et une requête sous-forme de chemin. XSL(T) permet de transformer une structure de documents XML et pas uniquement de définir un « style ». De la même façon, nous prévoyons d’adapter ou d’étendre la syntaxe d’une feuille de style afin que le développeur puisse définir un patron pour l’extraction d’une carte, et pour la restriction de la propagation d’un critère.

Nous n’avons pas mené d’évaluation précise de ces critères d’adaptabilité, mais leur utilisation passée dans des moteurs de recherche comme Google, ou encore dans des indices d’intérêt (Impact factor) ont montré leur robustesse. Le chapitre suivant présente les résultats graphiques et des cas d’utilisations dans deux contextes applicatifs : l’analyse de données d’expression et l’ingénierie terminologique et ontologique. Ces résultats sont commentés et discutés.

CHAPITRE 7

Applications et résultats visuels

« Interfaces emerge when the system is used »

KARI KUUTTI

7.1 Introduction ... 191

7.2 I²DEE comme support à l’ingénierie terminologique et ontologique ... 191

7.2.1 Principes généraux de conception de RTO ... 192

7.2.2 Environnements intégrés d’édition formelle et d’évaluation ... 194

7.2.3 Pertinence de l’approche I²DEE ... 195

7.2.4 Résultats visuels ... 195

7.2.5 Bilan ... 200

7.3 I²DEE utilisé en analyse de données d’expression ... 201

7.3.1 Le besoin... 201

7.3.2 Résultats visuels ... 203

7.3.3 Bilan ... 213

7.1 Introduction

Dans ce qui précède, nous avons présenté l’environnement I²DEE suivant différents niveaux : niveau général, conceptuel, architectural ou encore au niveau de l’implémentation. Nous avons décrit I²DEE comme une approche visuelle souple, extensible, capable de s’adapter dans des contextes variés pour réaliser diverses tâches. Pour témoigner de cette capacité d’adaptation et de la pertinence de notre approche, nous proposons dans ce chapitre d’explorer deux contextes applicatifs très différents correspondant { des besoins identifiés d’utilisateurs :

- l’ingénierie terminologique et ontologique [Jalabert, Ranwez et al. 2006], - et l’analyse de données d’expression de gènes [Jalabert, Ranwez et al. 2006].

La première application cible un utilisateur bioinformaticien, terminologue ayant des connaissances en biologie et maitrisant la modélisation. Cet utilisateur peut être amené à construire des ontologies spécifiques. Cependant, de nombreuses ressources existent déjà et couvrent une partie de son problème. I²DEE doit lui permettre de construire une ontologie plus rapidement en réutilisant des ressources existantes et de gagner en qualité de résultat (confiance et cohérence) dans la mesure du possible.

La seconde application cible un utilisateur biologiste souhaitant analyser des données d’expression de gènes obtenues via un dispositif haut débit. Il souhaite procéder à un regroupement automatique des gènes puis en explorer les résultats afin d’extraire un petit ensemble de gènes d’intérêt. L’application lui permet de visualiser deux regroupements simultanément (cf. section 6.2.1) et doit permettre { l’utilisateur de consulter rapidement la connaissance du domaine de façon contextuelle. Ce chapitre présente ces deux applications, discute les résultats obtenus, et dresse un bilan de ces deux expériences.