VisualLuciaBuilder : construction interactive de dispositifs LUCIA

Après avoir extrait avec Memlabor, des lexies d’un ensemble documentaire et les avoir re-groupées en domaines avec ThemeEditor, nous proposons à l’utilisateur de décrire chacun de ces domaines selon le modèle LUCIA.

108

Ces domaines sont : la justice (24 lexies), la religion (29 lexies), la violence (21 lexies), l’éducation (29 lexies), l’agriculture (36 lexies), la circulation routière (46 lexies), l’aviation (41 lexies), la mer (40 lexies), le dopage (24 lexies), l’économie (56 lexies), la politique (57 lexies), l’espace (43 lexies), la guerre (31 lexies), l’informatique (48 lexies), la pollution (17 lexies), le sport (34 lexies), la télévision (37 lexies) et le travail (33 lexies).

109

Chapitre 3. Instrumentation logicielle du modèle

Pour cela, nous proposons l’outil interactif VisualLuciaBuilder permettant un grand nombre d’opérations de création et de révision de dispositifs110

. À la suite de l’outil LUCIABuilder [Perlerin, 2004, pages 151 à 159] (figure 3.7) développé par Vincent Perlerin, nous avons déve-loppé l’outil VisualLuciaBuilder dans un objectif similaire : celui d’assister l’utilisateur dans la construction de dispositifs LUCIA. Les motivations de ce développement sont liées aux limites constatées sur l’outil original.

Fig.3.7 – LUCIABuilder : Interface montrant la phase de remplissage d’une table d’un dispositif. Tout d’abord, LUCIABuilder oblige l’utilisateur à une élaboration séquentielle de ses dis-positifs, en définissant, tout d’abord les attributs et valeurs d’attributs, puis les tables, puis l’organisation des tables entre elles au sein du dispositif. De nombreux « aller-retours » sont pourtant nécessaires dans l’élaboration des dispositifs. Par exemple, il faut pouvoir revenir à tout moment sur les attributs et les valeurs définies, en ajoutant ou en supprimant un attribut et/ou une valeur. De telles modifications sont ensuite répercutées sur les tables possédant les attributs concernés, comme nous le verrons par la suite à travers un exemple. Hormis cette vue séquentielle de la phase de construction d’un dispositif, LUCIABuilder donne une vision assez locale sur les tables. Ainsi, il n’est pas possible pour l’utilisateur de visualiser à la fois le contenu de tables du dispositif et les liens entre les tables. Pourtant, une telle vue conjointe sur le contenu des tables et leurs liens serait particulièrement utile afin de mieux appréhender les descriptions déjà réalisées.

La réalisation de l’outil VisualLuciaBuilder a donc été principalement guidée par ces idées d’offrir à l’utilisateur à la fois plus d’interactivité et une vue globale durant la phase de construc-tion des dispositifs. Le développement de ce logiciel a commencé dans le cadre d’un projet d’étudiants en Master première année d’informatique à l’Université de Caen durant l’année uni-versitaire 2005-2006. Ce projet, mené par Kahina Hamadache et Matthieu Vernier, a conduit à l’élaboration d’une première version utilisable de l’outil [Hamadache et Vernier, 2006]. Après avoir poursuivi ce développement afin de corriger les dernières imperfections et d’intégrer quelques améliorations, nous avons pu stabiliser une version de l’outil VisualLuciaBuilder, outil présenté en figure 3.8.

110

À noter, tout de même, que ce dernier peut être utilisé directement. L’utilisation des outils précédents permet d’amorcer très utilement la phase de construction de dispositifs LUCIA, cependant l’utilisation de Memlabor et de ThemeEditor n’est pas une obligation pour l’utilisateur, l’outil VisualLuciaBuilder pouvant s’utiliser de façon autonome (il en est de même pour tous les outils que nous proposons).

3.2. Aides logicielles à la construction de RTO personnelles

Zone 1

Zone 2

Zone 3

Fig. 3.8 – VisualLuciaBuilder : Interface illustrant les principales zones numérotées manuelle-ment de 1 à 3. Le dispositif sélectionné représente le domaine de la guerre. Il décrit et met en relation les lexies d’une liste constituée à l’aide des outils MemLabor et ThemeEditor à partir de l’ensemble documentaire abordé précédemment.

L’interface de l’outil comporte des zones distinctes marquées de 1 à 3 sur la figure précédente. La zone 1 contient une ou plusieurs listes de lexies sélectionnées par l’utilisateur dans le cadre d’études précédentes. L’outil permet de charger aussi bien des fichiers XML de lexies produits par Memlabor que des fichiers XML de domaines produits par ThemeEditor, dans ce cas les catégories sont bien évidemment conservées dans l’affichage du lexique qui se fait sous forme d’arbre. L’utilisateur peut ainsi ajouter de nouvelles lexies, modifier et supprimer des lexies existantes. Également, il est possible de partir de zéro en saisissant les lexies à la main dans la zone dédiée. L’interface permet de saisir des formes fléchies de ces lexies pertinentes pour l’utilisateur. Si ces formes sont déjà présentes (par exemple, si l’utilisateur a utilisé la fonctionnalité de ThemeEditor associant automatiquement, à chaque lexie, ses formes fléchies associées présentes dans la base BDLex ), ce dernier peut modifier et/ou compléter les flexions existantes. Pour chaque lexie de la zone, un clic droit avec la souris ouvre un menu contextuel offrant la possibilité d’aller voir la définition de la lexie proposée par Wikipédia111

, de mettre en contexte la lexie dans un ensemble documentaire via FlexiSemContext (voir partie suivante) et d’obtenir des synonymes avec le dictionnaire des synonymes de l’Université de Caen112. Le but recherché, en proposant à l’utilisateur ces différents liens, est de lui permettre de relier sa ressource à un espace hypertextuel (encyclopédie et dictionnaire de synonymes) et à un espace intertextuel (concordancier). En reliant la ressource de l’utilisateur à une encyclopédie et à un dictionnaire de synonymes, nous lui proposons en quelque sorte de reprendre à son compte certains éléménts de « consensus » proposés par les auteurs de l’encyclopédie et du dictionnaire. Le but visé est ainsi de permettre à l’utilisateur un éventuel complément de sa propre ressource avec de nouveaux éléments pertinents de son point de vue auxquels il n’aurait pas encore fait référence.

111

http://www.wikipedia.fr(page consultée le 25 janvier 2007). 112

Chapitre 3. Instrumentation logicielle du modèle

Ces différentes fonctionnalités peuvent permettre d’enrichir les listes avec des lexies auxquelles l’utilisateur n’aurait pas pensé jusqu’à présent. Un moteur de recherche dans le lexique est également disponible, afin de rechercher si une lexie ou l’une de ses formes fléchies est bien présente dans les listes. Une fois les listes de lexies stabilisées, l’utilisateur peut les sauvegarder dans un fichier au format XML afin de permettre une exploitation future par l’outil. La figure 3.9 illustre différentes fonctionalités offertes par VisualLuciaBuilder lors de la phase de chargement du lexique.

Fig. 3.9 – VisualLuciaBuilder : Recherche de la lexie « rougeole » dans les listes. Une fois la lexie trouvée, elle est automatiquement sélectionnée. Un clic droit sur la lexie permet d’obtenir différentes informations par l’intermédiaire de Wikipédia, d’un dictionnaire des synonymes ou encore d’un outil de mise en contexte dans l’ensemble documentaire.

La zone 2 représente une ou plusieurs listes d’attributs et de valeurs d’attributs définis par l’utilisateur. Là encore, l’utilisateur peut soit charger et modifier une liste d’attributs construite lors d’une précédente utilisation de l’outil, ou bien partir d’une liste vierge et saisir de nouveaux attributs et de nouvelles valeurs. Tout comme pour la zone 1, un module de recherche est dispo-nible afin de retrouver et de sélectionner directement un attribut ou une valeur d’attribut donné. Des valeurs d’attributs prenant la forme d’images ou d’icônes sont définissables. L’application Vi-sualLuciaBuilder contient un ensemble d’images (répertoire « images » à la racine du répertoire contenant l’application) pré-sélectionnées. Il est bien sûr possible d’ajouter ses propres images. Ceci n’est pas qu’une fonctionnalité supplémentaire de l’interface mais cela constitue un premier pas vers une sémiotique différente du lexical, utilisée dans un même but : pouvoir exprimer des différences. La figure 3.10 illustre l’usage de telles images comme valeur d’un attribut. La sau-vegarde dans un fichier au format XML du dictionnaire d’attributs est proposée à l’utilisateur quand ce dernier a stabilisé la liste des attributs à faire intervenir dans la description de ses domaines.

Enfin, la zone 3 est une zone où l’utilisateur « dessine » son dispositif. Il crée de nouvelles tables par un simple clic droit dans la zone de dessin, puis nomme les tables comme il le souhaite. L’utilisateur peut alors glisser interactivement au sein des tables les attributs (zone 2) qu’il estime décrire les tables concernées. Un tel ajout entraîne la création dans la table d’autant de colonnes qu’il y a d’attributs, et d’autant de lignes qu’il y a de combinaisons des différentes valeurs des attributs choisis. Ensuite, l’utilisateur peut remplir les tables en glissant les lexies de la zone 1

3.2. Aides logicielles à la construction de RTO personnelles

Fig. 3.10 – VisualLuciaBuilder : Des images (smileys) ont été utilisés pour définir l’attribut « évaluation ». De telles images se retrouvent ensuite dans les tables concernées dans le dispositif (dans l’exemple, il s’agit d’un dispositif sur le domaine de la guerre).

dans les cases des tables qu’il juge pertinentes. L’utilisateur dessine également les liens d’héritage entre tables en traçant tout simplement un trait entre la ligne de la table parente et le nom de la table fille. Les différentes tables sont déplaçables dans la zone de dessin, mais l’utilisateur peut utiliser la fonction de placement automatique pour disposer le mieux possible les tables dans la zone de dessin.

Une fonction de zoom est disponible dans la zone de dessin afin, par exemple, de mettre l’accent sur une table donnée ou, au contraire, pour garder une vue très globale sur le dispositif durant son élaboration. La création de plusieurs dispositifs en parallèle est également possible, un onglet de la zone de dessin est alors associé à chaque dispositif. L’application intègre un module de recherche dans la zone de dessin. Ce module permet de localiser une lexie dans un dispositif, mais aussi de faire ressortir les différents attributs et valeurs d’attributs portés par la lexie (cf. figure 3.11).

Une opération un peu plus complexe de modification d’un dispositif est la suppression d’un attribut (i.e. une colonne d’une table). Une telle suppression implique le regroupement des lexies séparées par l’une des valeurs de l’attribut (cf. 3.12 pour une illustration de cette opération). De la même manière, nous avons décidé que lors de la suppression de lexies et d’attributs dans leurs dictionnaires respectifs, ces suppressions se répercutent dans le dispositif : les lexies supprimées dans le lexique disparaissent des tables dans lesquelles elles étaient positionnées. Les attributs et valeurs d’attributs retirés du dictionnaire d’attributs sont supprimés des tables de la même manière que pour le retrait de lexies.

Dès que l’utilisateur considère ses dispositifs stabilisés, du moins momentanément, leur en-registrement sous forme de fichiers XML est réalisé. Un fichier XML est alors associé à chaque dispositif. Ce fichier reprend les identifiants des lexies et des attributs présents dans les fichiers XML décrivant ces listes respectives. L’enregistrement d’un ensemble de dispositifs, appelé une session, est également possible. Un fichier XML est alors utilisé pour décrire ces éléments. Plus concrètement, ce fichier contient des pointeurs vers les différents fichiers XML des dispositifs, des dictionnaires d’attributs et des lexiques utilisés pour décrire les domaines de l’utilisateur (des extraits de tels fichiers XML sont présentés en annexe A de cette thèse).

Chapitre 3. Instrumentation logicielle du modèle

Fig. 3.11 – VisualLuciaBuilder : Résultat de la recherche de la lexie radiation dans le dispositif représentant le domaine de la guerre. La lexie a été entourée et reliée à ses attributs manuellement sur la figure.

Fig. 3.12 – VisualLuciaBuilder : Suppression de l’attribut fonction de la table des activités du domaine de la guerre.

3.2. Aides logicielles à la construction de RTO personnelles Des sorties SVG des dispositifs sont également retournées par VisualLuciaBuilder, de telles sorties permettent de visualiser les dispositifs de façon interactive en dehors d’une utilisation du logiciel, par exemple, dans une page d’un site Internet113.

Dans notre exemple d’utilisation sur un ensemble documentaire constitué d’articles de presse, nous avions obtenu à l’issue de l’utilisation de ThemeEditor, 18 domaines, chacun étant décrit en moyenne par une trentaine de lexies. Ce premier regroupement en domaines constitue, non seulement un préliminaire particulièrement intéressant à l’élaboration de dispositifs LUCIA, mais permet aussi d’obtenir des ensembles de lexies directement projetables dans l’ensemble documen-taire par la plate-forme ProxiDocs, comme nous le verrons par la suite. À partir de 4 de ces 18 domaines, nous avons élaboré des dispositifs LUCIA qui pourront, par exemple, nous servir à une étude plus poussée du contenu de l’ensemble documentaire par rapport aux domaines ainsi représentés (ces quatre domaines sont les suivants : la télévision, la guerre, l’espace et la justice). Ces dispositifs pourront également être projetés dans l’ensemble documentaire par ProxiDocs, les projections donnant, dans ce cas, plus d’informations à l’utilisateur.