Travail dirigé de Martin Sévigny, ©1996 Section précédente | Section suivante | Page d'accueil |

11. Conclusion

Un travail de recherche bien mené n'est jamais complet en soi. Il mène naturellement vers des réponses, mais également vers des questions, de nouvelles pistes de recherche. Le projet présenté dans ces pages ne fait pas exception à la règle.

En effet, le lecteur attentif remarquera que la dernière recommandation de la partie précédente, soit celle de "permettre une représentation graphique des résultats et la formulation graphique des requêtes de recherche", ne fut pas vraiment exploitée dans ERIS. C'est pourquoi, en guise de conclusion, nous présentons des idées de recherche afin d’en connaître un peu plus sur ce sujet. Dans le but de bien souligner le caractère exploratoire des idées soulevées, nous allons les présenter sous la forme d’une proposition de recherche.

11.1 Vers un environnement graphique de repérage d'informations structurées

11.1.1 Problématique

Le repérage d’information dans les documents structurés permet d’effectuer des requêtes d’une rare complexité syntaxique et sémantique, exploitant ainsi à la fois le contenu des documents et leur structure logique. Afin de pouvoir exprimer clairement toutes ces possibilités, la définition d’un modèle tel que celui à la base de ce projet de recherche peut aider beaucoup.

Ce modèle devra prévoir un langage de recherche d’information structurée, bien entendu complet par rapport au modèle. Par conséquent, ce langage risque fort de sacrifier la simplicité au profit de la puissance. Heureusement, rien n’oblige les utilisateurs de logiciels d’interrogation à utiliser ce langage; il pourrait servir seulement pour l’interrogation du moteur de recherche, ce qui demande de traduire les requêtes des usagers dans ce langage, tâche pouvant être effectuée par le logiciel d’interrogation.

Plusieurs techniques peuvent être employées afin de cacher ce langage aux usagers. Dans notre projet, nous avons utilisé la plus simple à implanter et la plus connue, soit les bordereaux de saisie de requêtes. Ces bordereaux permettent aux usagers d’oublier la syntaxe exacte du langage de commande et d’entrer rapidement les informations nécessaires.

La méthode des bordereaux s’applique très bien aux requêtes simples et modérément complexes. Nous avons constaté lors de l’évaluation de notre prototype que les usagers étaient rapidement familiers avec le bordereau qu’on leur faisait utiliser. Très rapidement ils savaient comment l’utiliser et quel genre de résultats il produirait. On pourrait très bien imaginer des bordereaux permettant des requêtes un peu plus complexes et qui seraient encore efficaces.

Toutefois, il y a deux raisons principales pour lesquelles nous ne pouvons envisager les bordereaux comme une méthode universelle pour formuler les requêtes de recherche dans les documents structurés. Tout d’abord, il n’est pas évident que le bordereau soit un outil efficace pour exprimer des relations hiérarchiques entre des éléments considérés comme critères de recherche. Par exemple, il est difficile d’imaginer un bordereau efficace pour exprimer la requête suivante (formulée dans un langage "naturel"):

Trouver tous les chapitres qui ont au moins deux sections mais pas plus de cinq, et dont un des paragraphes contient l’expression "informatique documentaire". Le paragraphe précédent ou suivant ne doit toutefois pas contenir l’expression "bibliothéconomie". Retourner les titres de ces chapitres.

La deuxième raison pour rejeter les bordereaux comme solution universelle provient de la volonté de trouver une méthode qui présente un caractère de complétude par rapport au modèle de repérage. En effet, il faudrait arriver à obtenir un outil qui permette toutes les requêtes imaginables. Bien entendu, cela devrait être possible avec un certain nombre de bordereaux, mais certains seraient tellement complexes qu’il serait sûrement difficile de les utiliser.

La nature statique des bordereaux constitue leur principale limite, car il faut prévoir toutes les possibilités à l’avance. De son côté, un langage constitue une approche dynamique qui permet d’atteindre le même objectif, c’est-à-dire la complétude, mais au détriment de la facilité d’utilisation, en particulier pour les requêtes complexes. Ce qu’il nous faut, c’est un outil qui combine la simplicité d’utilisation des bordereaux et le dynamisme d’un langage de commande.

Pour réaliser cet outil, il faut se pencher sur le caractère même des objets manipulés par les requêtes. Les usagers cherchent de l’information, et cette information se retrouve dans des documents structurés, c’est-à-dire un réseau d’éléments. Leur requête constitue donc l’expression d’un sous-ensemble (possiblement vide) de ce réseau.

La façon la plus naturelle de présenter un réseau est par une méthode graphique. En effet, la plupart des êtres humains vont utiliser du papier et un crayon pour représenter des objets qui, avec des liens, constituent un réseau. C’est le cas des hiérarchies qui s’expriment très bien par un arbre inversé, où le noeud supérieur est présenté tout en haut et où on présente ses enfants en dessous, sur une même ligne, centrée par rapport au parent. D’ailleurs, il s’agissait de la méthode utilisée dans le guide détaillé de la structure et elle fut en général appréciée par les usagers.

La relation à faire est simple; comme une requête constitue l’expression d’un sous-ensemble d’un réseau, il faudrait pouvoir construire cette requête de façon graphique, c’est-à-dire en plaçant des objets dans une fenêtre, en leur donnant des propriétés, et en construisant des relations entre ces objets. Bien entendu, les résultats de recherche devraient également être présentés de façon graphique.

11.1.2 Points de départs

L’environnement graphique de repérage d’informations structurées (EGRIS) devrait tenir compte des travaux sur la représentation graphique de bases de données de même que sur les méthodes graphiques de formulation de requêtes. Même si la littérature sur ces deux sujets est relativement abondante, aucune étude recensée n’utilisait ces techniques dans un contexte de documents structurés.

Certains travaux méritent d’être mentionnés au sujet de la présentation graphique de l’information. Johnson et Shneiderman (1991) ont travaillé sur des "cartes hiérarchiques" (tree maps) dans le but de présenter de l’information hiérarchique dans un plan à deux dimensions, où tout l’espace est occupé. Cette méthode s’est avérée efficace avec des hiérarchies comme celles représentées par l’ensemble des fichiers d’un disque dur. Dans ce cas, tous les objets sont de même type; il faudrait voir les possibilités avec des réseaux contenant des objets hétéroclites.

De leur côté, les gens du Xerox PARC (Card et al., 1991) ont exploré le concept d’un environnement d’information ("information workspace") où l’information est présentée sous forme d'arbres à trois dimensions. Ces arbres peuvent être manipulés pour donner des vues différentes de l’information. L’aspect tridimensionnel est destiné à tirer un maximum de profit de la facilité naturelle de l’être humain à se représenter des objets dans l’espace.

Rivin et ses collègues (1994) ont défini une méthode pour extraire des informations sur la structure hiérarchique d’un corpus hypertextuel et ils se servent de ces informations pour situer l’usager par rapport à la base qu’il consulte. On a notamment tenté de présenter cette structure hiérarchique à l’aide des arbres hiérarchiques dont on a parlé plus haut.

Hemmje (1993) a utilisé les résultats du Xerox PARC (Card et al., 1991) dans le but de présenter une base de données bibliographiques (descriptions et résumés de documents). Son approche consiste à voir la base comme un réseau de documents et de termes, chaque terme étant associé à des documents et chaque document contenant des termes. L’usager peut consulter la base de données exprimée par un arbre conique tridimensionnel, dont les noeuds sont soit des documents ou encore des termes. Il peut naviguer dans la base en sélectionnant des noeuds. Pour les requêtes, l’usager doit spécifier un point de départ (entrer un terme ou choisir un document) et il effectue le reste en parcourant les arbres coniques.

Du côté de la formulation graphique de requêtes, plusieurs expériences ont été menées dans le contexte des bases de données relationnelles (voir notamment Kim et al., 1988) et certains résultats furent encourageants. Sans oublier le "Query by example" (voir par exemple Date, 1983), offert par de nombreux systèmes de gestion de bases de données relationnels. Young et Shneiderman (1993) ont également construit un prototype destiné à interroger une seule table relationnelle à l’aide d’opérations booléennes. Ce prototype, exploitant une métaphore de flux et de filtres, a donné de bons résultats lorsque testé avec des usagers. Weiland et Shneiderman (1993) ont poursuivi dans la même veine avec une technique basée sur des agrégations et des généralisations hiérarchiques. Mais dans les deux cas, les recherches booléennes permises étaient relativement limitées.

L’idée la plus intéressante vient peut-être d’une étude de Boyle et al. (1993), dont l’objectif était de présenter une base de données en biologie moléculaire. Ils ont adopté une approche à trois dimensions non seulement pour présenter les résultats, mais également pour "saisir" les requêtes. La base de données est toujours représentée par son schéma, c’est-à-dire une représentation graphique des entités et des relations entre ces entités. Pour construire sa requête, l’usager définit d’abord un ensemble de sous-requêtes en sélectionnant des entités et en leur donnant des attributs (qui posent des contraintes). Ces attributs sont spécifiés à l’aide d’un bordereau. Les entités ayant des contraintes sont présentées dans le schéma, et la requête constitue l’ensemble des sous-requêtes ainsi construites. Il semble que le fait que l’usager puisse "voir" sa requête se construire soit un ajout intéressant.

Finalement, mentionnons les travaux de Shneiderman (1994) ayant pour but de concevoir des interfaces pour l’interrogation dynamique et visuelle de bases de données. L’usager formule des requêtes en modifiant des valeurs de paramètres, et le logiciel répond dynamiquement en modifiant la représentation graphique des informations.

11.1.3 Solutions possibles pour EGRIS

Ce bref survol de la littérature nous permettrait de démarrer la conception de l’interface d’EGRIS sur des bases solides. Il faudrait notamment essayer des techniques comme la représentation spatiale (trois dimensions) de l’information, les requêtes dynamiques, etc.

Deux approches pourraient être envisagées. La première consiste à présenter à l’usager un schéma d’un sous-ensemble de la base, et l’usager construit ses requêtes en posant des contraintes sur ce schéma. Il s’agit tout simplement de l’approche préconisée par Boyle et ses collègues, mais appliquée aux documents structurés. Avec cette approche, il faut notamment permettre à l’usager de d’abord se constituer des sous-ensembles avec lesquels il peut construire des requêtes.

Une autre approche serait de s’inspirer des logiciels de dessin vectoriel, qui permettent de concevoir des images constituées d’objets. On choisit un type d’objet parmi une liste (boîte d’outils) et on place cet objet dans un espace. Il nous faudrait un objet pour les éléments, pour chaque type de relation, etc. De plus, il faudrait associer des propriétés aux objets afin de spécifier des paramètres comme leur contenu textuel.

Dans les deux cas, une représentation des résultats utilisant les mêmes objets graphiques devrait être présentée et mise à jour dynamiquement, c’est-à-dire à mesure que l’usager modifie sa requête en supprimant ou ajoutant des objets ou en modifiant les valeurs des propriétés ou contraintes. Il faudrait également explorer l’intérêt d’apporter une touche tridimensionnelle à cette méthode graphique.

Avec un tel langage d’interrogation, il serait probablement possible d’en arriver à une complétude par rapport au modèle Marcoux; il faudrait là aussi explorer cette possibilité. De plus, il faudrait mesurer l’efficacité de cette méthode de formulation de requêtes en la comparant à un langage de commande ou des bordereaux. Cette mesure devrait se faire sur différents types de requêtes, allant de requêtes très simples à d’autres très complexes.

Une chose est sûre, des recherches sont nécessaires afin d’explorer les éléments d’interface qui prendraient avantage des capacités de l’être humain de reconnaître et de manipuler des objets. Nous croyons que cela peut aller jusque dans la formulation des requêtes, et que cette méthode pourrait constituer un langage d’interrogation très "naturel", du moins pour certaines requêtes, probablement celles qui exploitent beaucoup la structure.

11.2 En terminant

Ce travail de recherche a permis de constater que non seulement il faut des outils spécifiques pour l’interrogation de documents structurés, mais que ces outils doivent présenter certains éléments d’interface particuliers. De plus, nous avons présenté un rôle que pourrait jouer les spécialistes dans la conception d’outils de recherche.

Nous avons donc atteint nos objectifs. Toutefois, le fait que ce rapport pose autant de questions qu’il formule de réponses est encore plus intéressant à nos yeux. En effet, cela montre que ce domaine d’activité est rempli de défis qui restent à relever, autant du point de vue de la recherche dans les documents structurés que des éléments d’interface pour réaliser ces recherches efficacement.

Il serait tentant de voir les recommandations formulées à la fin de ce rapport comme un constat d’échec du prototype. En effet, aucune de ces recommandations ne fut suivie à la lettre. Nous nous refusons d’exprimer un tel constat, car ce travail devait avant tout ouvrir la voie vers des endroits très peu fréquentés en recherche, soit les interfaces pour l’interrogation de documents structurés.

Maintenant que la voie est tracée, il reste à explorer les nouvelles possibilités soulevées dans ce rapport, et à les mettre en relation avec un modèle complet et bien défini pour la définition et le repérage de documents structurés. Il s’agit d’un calendrier de recherche fort motivant.


Travail dirigé de Martin Sévigny, ©1996 Section précédente | Section suivante | Page d'accueil |