Interface d’utilisation de l’environnement d’aide à l’analyse géovisuelle

Comme nous l’avons présenté précédemment, l’interface entre un système à base de connaissances (système expert, PSE, SAD, etc.) est aussi importante que les connaissances elles-mêmes : c’est en effet cette IHM (interface homme-machine) qui permet la communication entre la formalisation et l’utilisateur. Elle doit donc être claire, simple d’utilisation et intuitive (Gallopoulos et al. 1992 ; Jackson 1999), afin de ne pas être un premier frein pour la future utilisation des solutions proposées. Le but de l’interface relative à l’EAAG que nous proposons doit donc servir de module de recherche de visualisations adaptées et de sélection : elle permet donc de lire différents objets de l’ontologie et d’en introduire de nouveaux, afin de lancer un raisonnement propre au cas d’utilisation. La Figure 4-7 présente les cas d’utilisation d’une telle interface par un diagramme UML : ces cas sont basés sur les concepts développés dans l’ontologie, qui définissent une situation (profil d’utilisateur, but d’utilisation et tâches, données, etc).

Figure 4-7. Cas d’utilisation pour l’interface entre l’utilisateur et l’ontologie au sein d’un environnement d’aide à l’analyse géovisuelle

De manière à pouvoir exploiter un tel prototype au sein de la plateforme web FishEye, nous avons choisi de développer un outil qui soit utilisable à la fois de manière indépendante (standalone) ou bien sur le web, par un appel de fonction. La prochaine sous-partie présente donc les choix techniques pour le développement d’une telle interface pour l’utilisation d’un système à base de connaissances, fondés sur les ontologies.

4.1.3.1. Développement du module de sélection

Nous avons fait le choix d’utiliser une architecture client-serveur pour le développement d’une telle application, afin de pouvoir facilement gérer l’ontologie côté client par des mises à jours régulières, ainsi que de permettre une utilisation locale depuis le terminal d’un client pour lire les concepts et ajouter de nouveaux objets propres à la situation. En effet, les informations relatives à la situation, ou cas d’utilisation, ne doivent pas être écrites de manière permanente : il est alors plus simple de récupérer l’ontologie « à distance » dans un fichier temporaire et local à chaque exécution, puis de modifier ce fichier selon la requête de l’utilisateur. Afin d’enregistrer les détails de chaque exécution, ces données sont ensuite envoyées sur le serveur, qui exécute alors un script pour stocker celles-ci. Pour une telle architecture, trois composantes principales ont été identifiées :

 Le client informatique, qui est amené à utiliser le prototype via son navigateur web, et ainsi envoyer des requêtes sur le serveur web.

 Le serveur web, qui reçoit les requêtes HTTP et transfère les requêtes reçues au serveur d’applications, transmet les résultats, qui sont ensuite affichées.

 Le serveur d’applications, qui contient les applications à exécuter et les données (ontologie). Il traite la requête en exécutant l’action choisie par le client et en manipulant les données stockées dans les fichiers, puis il envoie au serveur web le résultat.

Figure 4-8. Architecture du module d’utilisation de la base de connaissances

4.1.3.1.2. La librairie Java OWL API

Afin de pouvoir gérer la lecture, l’écriture de concepts et d’instances dans une ontologie, ainsi que de contrôler le processus de raisonnement, la bibliothèque Java OWL API a été utilisée lors du développement de cette interface. Cette bibliothèque de code est open-source et propose une interface de programmation d’application (API) qui peut être utilisée afin de créer des classes et des méthodes, qui lisent, écrivent et enregistrent des fichiers OWL. Initiée en 2003, cette bibliothèque est aujourd’hui activement maintenue par l’université d’Ulm et par l’entreprise Clark & Parsia. Elle est encore utilisée dans de nombreux projets, tels que l’éditeur d’ontologies Protégé (dans sa version 4.3).

Cette API peut également être utilisée afin de traiter, modéliser et manipuler des données OWL, ainsi que pour effectuer une analyse fondée sur la logique (inférence qui analyse la sémantique des données contenues dans le fichier OWL). Pour cela, la bibliothèque OWL API est principalement utilisée pour développer des composants et des applications autonomes.

De plus, OWL API permet de mener un raisonnement à partir d’une ontologie, grâce à l’intégration de différents moteurs d’inférence, tels que Fact++, Pellet, Racer Pro, etc. Précédemment, lors de la présentation des règles SWRL et du processus de raisonnement, nous avons souligné notre choix pour le raisonneur Pellet, qui permet entre autres un raisonnement incrémental.

Les travaux de stage effectués au CRC par El Moussawi (El Moussawi 2014) nous ont permis de développer un module fondé sur Java, qui va rechercher l’ontologie OWL sur un serveur, la copier localement, la lire via une interface de consultation, et y intégrer de nouveaux objets. Les informations sur l’utilisation effectuée localement est ensuite envoyée, lors de la sélection des méthodes, via un protocole HTTP par des fichiers XML et le JDOM API (Java Document Object Model).

Les détails de cette solution d’échange d’informations sont expliqués dans le rapport de stage (El Moussawi 2014).

L’interface de ce module Java est présentée sur la Figure 4-9. On y retrouve les informations qui permettent de définir un objet Situation dans l’ontologie. Un premier cadre permet de saisir les informations relatives à l’utilisateur : un champ de texte pour décrire sa profession (à but de stockage et d’analyse) (zone 1), le choix d’un environnement de travail prédéfini dans l’ontologie (zone 2), ainsi que les informations sur son profil (barre de choix de la zone 3). Le choix de cette interface permet de simplifier le processus de modélisation d’un utilisateur, et ainsi tester plusieurs profils différents pour évaluer l’impact sur la sélection des visualisations. L’utilisation de cette interface est donc subjective, l’utilisateur jugeant par lui-même son niveau sur les différents axes proposés. Comme nous le verrons plus tard, cette modélisation du profil utilisateur peut être plus complexe.

Un second cadre permet de sélectionner les termes de l’ontologie qui décrivent l’analyse à mener. Cela correspond aux concepts Risk, Goal et Task, dont des instances sont définies au sein de l’ontologie. Par des menus déroulants, l’utilisateur peut ainsi choisir un type de risque à étudier (zone 4), ou bien préciser un but d’utilisation (zone 5) ou une tâche d’exploration précise (zone 6).

Comme nous l’avons décrit lors de la phase de modélisation, ces trois concepts successifs dépendent successivement du concept plus général. Ainsi, lors de la sélection d’un terme dans l’un de ces menus déroulants, les objets des niveaux suivants sont alors filtrés (voir la Figure 4-10). Dans la partie basse de cette interface, une place est laissée afin d’afficher les données nécessaires à ces opérations d’exploration et d’analyse. Celles-ci sont affichées lors de la sélection de l’opération à mener par la visualisation, et peuvent être sélectionnées par l’utilisateur selon la disponibilité de ces données. Le bouton au bas de cette interface permet alors de valider la description du cas d’utilisation. Cette première étape de sélection correspond à la lecture de l’ontologie, tandis que la validation permet ensuite une écriture dans l’ontologie, enregistrée localement, sous la forme d’une nouvelle instance du concept Situation.

Figure 4-9. Interface Java pour l’utilisation de la base de connaissances

Figure 4-10. Sélection du but d’utilisation Analyse de comportement de pêche, puis affichage des différentes tâches et données correspondantes

Une fois la nouvelle instance Situation ajoutée dans l’ontologie locale, le processus de raisonnement est exécuté, grâce à ces nouvelles informations. Le résultat de cette démarche est alors une nouvelle fenêtre qui présente les méthodes de visualisation qui peuvent être utilisées, afin de définir un environnement complet d’analyse géovisuelle. Ces méthodes sont présentées sous plusieurs onglets méthodologiques, les trois espaces de Peuquet : géographique, temps et sémantique. Ce choix d’onglets a été fait afin de distinguer les méthodes selon cette triple taxonomie présentée dans les parties précédentes, et non pas selon une sémantique plus complexe qui aurait demandé une modélisation encore plus approfondie des méthodes de visualisation. Ces trois grandes classes de

visualisations n’étant pas exclusives, des méthodes peuvent se retrouver dans un ou plusieurs onglets à la fois, selon les données de base qu’elles utilisent.

Sur cette interface, seules les méthodes retenues sont représentées en couleur. Les autres méthodes, non sélectionnées par le système à base de connaissances, sont laissées en noir et blanc (voir Figure 4-11). Ces méthodes sont représentées par des icônes fixes, et non pas sur les données réellement étudiées. En passant la souris au-dessus de ces icônes, les images sont agrandies afin d’avoir une meilleure compréhension de la visualisation utilisée, et des détails relatifs à cette méthode sont données en commentaire (nom, description).

Figure 4-11. Fenêtre de choix des méthodes de visualisation après exécution du raisonneur dans l’ontologie

L’utilisateur peut alors choisir les méthodes de son choix à partir de cette interface, pour ensuite les utiliser sur les données réelles qu’il étudie. La plus grande partie des méthodes ainsi présentées sont intégrées dans la plateforme FishEye, par différents menus déroulants. Cette interface permet donc de conseiller quant à leur utilisation, selon l’analyse à mener. Un lien dynamique entre le choix de la méthode sur l’interface Java, et son application sur l’interface de FishEye, a pu être développé pour certaines de ces méthodes, comme preuve de concept. Toutefois, les méthodes ainsi modélisées sont parfois issues d’autres travaux de recherches, ou d’outils propriétaires, que nous n’avons pas pu intégrer à notre plateforme web. Parmi les 31 méthodes formalisées dans l’ontologie, 17 méthodes ont pu être intégrées sur cette plateforme d’analyse de données maritimes. La liste de ces méthodes de visualisations est présentées dans les annexes de ce manuscrit (voir l’annexe 2. Liste des

visualisations formalisées, p.234). Celles-ci ont essentiellement été développées à partir des librairies JavaScript disponibles pour la visualisation d’information, libres et gratuites, telles que les librairies Ext, GeoExt ou D3. Les autres méthodes ont été testées indépendamment de l’application FishEye, car obéissant à des logiciels différents.

De par son langage de développement, cette interface Java peut alors être intégrée à un environnement web. La sous-partie suivante présente l’intégration de cette interface d’utilisation de l’environnement d’aide à l’analyse géovisuelle, dans la plateforme FishEye pour l’analyse des données maritimes.

4.1.3.2. Intégration du module à FishEye

Dans l’environnement FishEye, nous proposons trois manières d’accéder à cet outil d’aide à l’analyse géovisuelle. L’outil peut soit être chargé sans prendre en compte de données à étudier, depuis la barre d’outils (Geovisual Analytics Support). Toutefois, il est possible de sélectionner au préalable des données depuis la carte, afin que les méthodes choisies par la suite soient directement appliquées à ces données. Ainsi, nous permettons le choix d’une zone géographique ou d’un navire à analyser. La première option est possible en dessinant une zone (outil Geovisual Analytics of Zone, Figure 4-12 a), qui est alors considérée comme paramètre pour l’application des visualisations prochainement sélectionnées. La deuxième option est alors accessible par un clic droit sur un navire (Figure 4-12 b), dont on souhaite étudier le mouvement à l’aide des méthodes qui seront choisies par la suite.

(a) (b)

Figure 4-12. Accès à l’outil d’aide à l’analyse géovisuelle depuis FishEye : (a) par le menu général, (b) par un menu contextuel

Ce contrôle depuis l’interface de FishEye ouvre alors un lien vers le téléchargement de l’application Java. Celle-çi est alors copiée localement avec l’ontologie sur l’espace temporaire du client. Selon le choix de contrôle effectué, les informations relatives à la zone (étendue, coordonnées) ou au navire (coordonnées, types, etc.) sont gardées dans la mémoire de l’application web, qui les transfère à l’application Java. Une fois l’EAAG utilisé et les méthodes sélectionnées, celles-ci sont alors éxécutées dans l’interface de FishEye, afin d’étudier l’objet d’intérêt.

Afin d’intégrer une telle application à une page web et l’exécuter du côté client, Java dispose de deux technologies : les Applets et le Java Web Start. Une applet Java est un type particulier de programme Java qu’un navigateur compatible avec Java peut télécharger et exécuter. Une applet est typiquement incorporée à l’intérieur d’une page web et s’exécute dans le contexte d’un navigateur. A contrario, le Java Web Start permet de télécharger et d’exécuter des applications Java à partir du web. Le logiciel Java Web Start propose les avantages suivants :

 Il garantit l’exécution de la version la plus récente de l’application

 Il ne fait pas appel à des procédures d’installation ou de mise à niveau compliquées

Grâce au Java Web Start, les utilisateurs peuvent donc lancer une application Java en cliquant sur un lien dans une page web. Le lien pointe vers un fichier JNLP (Java Network Launch Protocol), qui indique à Java Web Start comment télécharger, cacher et exécuter l’application.

Les applets ne peuvent pas effectuer certaines opérations, telles que l’accès aux ressources des clients en mode écriture ; ce dont nous avons besoin pour cette application. Notre choix s’est donc porté sur la technologie Java Web Start qui permet de résoudre ce problème d’accès, tout en préservant la sécurité et l’intégrité du système (El Moussawi 2014). La Figure 4-13 montre le type de message que l’utilisation du JNLP fait alors apparaitre, avant de télécharger et exécuter l’application Java. Cette nouvelle fenêtre n’est donc pas une fenêtre du navigateur Internet, mais est une fenêtre indépendante. Grâce à JNLP, nous pouvons tout de même envoyer des informations d’une application à l’autre, via le serveur.

Dans cette partie, nous avons présenté l’interface homme-machine qui est fondamentale dans la définition de cet environnement d’aide à l’analyse géovisuelle : maintenant, nous présentons son utilisation et ses avantages. Dans la partie suivante, nous présentons donc un scénario d’intérêt pour l’exploration et l’analyse des données de mouvement dans le trafic maritime, pour lequel l’analyse géovisuelle et cet EAAG jouent un rôle fondamental.