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

4. Vue d’ensemble de la démarche et du prototype

4.1 Les concepts fondamentaux du projet de recherche

4.1.1 Modèle de structure et de recherche

Le prototype décrit dans ce rapport fut conçu afin de tester et explorer un modèle de documents structurés présentement en élaboration. Une connaissance approfondie de ce modèle n’est pas essentielle pour bien comprendre les enjeux de l’interface, mais nous allons tout de même en exposer les faits saillants afin de faciliter la lecture. À noter que le modèle est une création du professeur Yves Marcoux de l’EBSI, et ne fait pas partie de cette recherche comme telle. Il est très important de noter que la description informelle faite ici donne un aperçu du modèle tel qu’il existait au mois d’août 1995.

Le modèle de documents structurés en élaboration, appelé par la suite "modèle Marcoux", touche à la fois à la représentation de la structure logique des documents et au repérage de l’information à l’intérieur de ces documents. Il ne s’appuie sur aucune norme ou aucun format déjà établi, mais se veut plus général et tente de définir tout ce qu’il est possible de faire avec de tels documents.

La représentation des documents du modèle Marcoux se fait à l’aide d’un ensemble de noeuds, ces noeuds pouvant être reliés les uns aux autres; ils constituent donc un réseau. Ces noeuds et ces relations forment une base de documents. Une "définition de base de documents" précise le contexte dans lequel on peut utiliser les noeuds, les relations possibles, et ainsi de suite. Il s’agit donc de règles strictes définissant un modèle de données et énoncées selon un certain formalisme.

Le modèle Marcoux admet les réseaux arbitraires de noeuds, et non seulement des hiérarchies. C'est la définition de base de documents qui détermine la topologie admise. Ce mécanisme permet d’unifier le concept de lien hypertextuel et celui de lien hiérarchiques.

Autre fait marquant du modèle Marcoux, le même formalisme peut servir à la fois de langage de définition de la structure (définition de la base de documents) et de langage de recherche dans la base de documents. En effet, le modèle unifie les concepts de représentation des documents et de recherche en partant du principe que l’ensemble de résultats d’une recherche constitue toujours un sous-ensemble de la base de documents, et ce sous-ensemble peut s’exprimer à l’aide d’un cas particulier des règles de définition des documents. Les noeuds respectant ce cas particulier formeront un résultat de recherche. Une des conséquences de cette façon de procéder est que seuls des ensembles de noeuds pourront constituer un résultat de recherche.

Un tel modèle de recherche dans les documents structurés permettra des recherches d’une complexité et d’une précision inouïes, tout en pouvant exprimer des recherches de base simplement. En effet, le formalisme permet de définir précisément la structure d’un noeud, et par le fait même une requête de recherche exploitant la structure. D’un autre côté, l’utilisation de critères de recherche textuels habituels (booléens, proximité, etc.) pour retrouver des noeuds selon leur contenu seront possibles. La combinaison de ces deux fonctions permet un ensemble de requêtes très grand.

À titre d’exemple d’interrogation de la structure, mentionnons la possibilité de questionner sur la présence d’éléments de structure logique dans un certain contexte (sections possédant au moins une figure), la quantification des éléments de structure (chapitres possédant exactement quatre sections), l’utilisation de relations entre différents noeuds (deuxièmes chapitres d’un livre dont le premier contient le mot "Informatique" dans son titre), etc. Ce ne sont que quelques exemples de recherche, mais ils sont suffisants pour donner un bon aperçu.

4.1.2 SGML et le modèle Marcoux

La norme SGML permet de définir des documents structurés. Dans ce sens, elle poursuit un peu les mêmes objectifs que le modèle Marcoux et c’est pourquoi elle constitue un cas particulier du modèle plus général. Toutefois, certaines distinctions sont à faire.

Les documents SGML constituent une hiérarchie stricte d'éléments, et non un réseau arbitraire de noeuds. De plus, on peut associer des attributs aux éléments. Mentionnons également que le concept de lien hypertextuel ne fait pas partie de la norme SGML. Toutefois, il est relativement facile de construire une DTD de façon à ce qu'on puisse définir des liens hypertextuels dans un document SGML, et par la suite dicter à une application SGML comment se comporter en face d'un élément (ou attribut) représentant un lien hypertextuel.

De plus, la norme SGML ne prévoit aucun mécanisme de recherche dans les documents qui la respectent. Cette fonction est laissée aux applications, et ce sont les concepteurs d'applications SGML qui décident du genre de recherche qu'ils veulent permettre à leurs usagers.

L’utilisation de la norme SGML est de plus en plus répandue, et on retrouve aujourd’hui de nombreux documents définis selon une DTD SGML. Pour cette raison, mais aussi parce que SGML constitue un cas particulier très intéressant du modèle Marcoux, le prototype décrit dans ce rapport de recherche exploitera des documents structurés respectant une DTD SGML, donc des documents SGML.

Nous avons tenté de concevoir l’interface de manière à transcender ce choix et à demeurer général, mais certains aspects sont toutefois influencés. Par contre, l’interface est assez générale pour servir d’instrument de vérification et d’expérimentation du modèle Marcoux, et dans ce sens elle joue parfaitement son rôle.

4.2 Les différents rôles joués par les concepteurs d'ERIS

Les gens qui utilisent des bases de données en texte intégral utilisent en fait un système composé de deux grandes parties: des documents et un logiciel d’interrogation. Bien sûr, ces deux composantes respectent certaines règles afin qu’elles puissent bien fonctionner ensemble, et pour arriver à un environnement intéressant, plusieurs intervenants sont nécessaires. Afin de bien situer le prototype conçu dans le cadre de ce projet de recherche, il est bien important de comprendre le rôle de ces intervenants et les décisions que nous avons prises à leur sujet.

En général, il existe au moins trois intervenants dans un système de gestion de bases de données, même si le même individu peut jouer les trois rôles. Il s’agit de l’éditeur de la base de données, du producteur du logiciel d’interrogation et de l’usager. L’éditeur sera habituellement responsable du contenu intellectuel de l’information, le producteur du logiciel s’assurera de permettre à l’usager d’interroger efficacement les informations et ce dernier tentera de se familiariser avec l’environnement de recherche et, si possible, de le personnaliser.

Pour ERIS, nous avons joué les trois rôles. En effet, nous agissons en tant qu’éditeur, producteur du logiciel et usager, afin de bien contrôler toutes les variables et d’en faire un outil de recherche intéressant et simple à construire. Mais il ne faut pas perdre de vue ces rôles, et c’est pourquoi nous y reviendrons dans la partie discussion de ce rapport.

Dans ERIS, le rôle de l’éditeur et celui de l’usager ont été réduits à zéro. En effet, l'usager ne peut pas personnaliser son environnement de recherche. De plus, l’environnement de recherche ne permet d'interroger qu’une seule base de documents. Il s’agit donc d’un bloc monolithique sans souplesse véritable, ni pour l’éditeur ni pour l’usager. Pour modifier le fonctionnement des parties du logiciel, il faut intervenir au niveau de la programmation.

Ainsi, dans le reste du document, le terme "prototype" ou "ERIS" fera référence à l’ensemble du système, soit les documents compilés en une base de données et le logiciel permettant de les interroger. De plus, lorsque nous voudrons faire référence au logiciel en particulier, nous utiliserons le terme "interface".

4.3 Conception

Deux grandes opérations ont caractérisé la réalisation technique du prototype (étape 5 de la méthodologie). Dans un premier temps, il a fallu trouver un ensemble de documents appropriés et les inclure dans une base de données relationnelle. Ensuite, nous avons conçu un logiciel d’interrogation, soit l’interface entre des usagers et les documents.

Les deux parties (base de données et interface) ont évolué en parallèle, car des changements techniques au niveau du fonctionnement de l’interface pouvaient avoir des incidences sur la structure de la base de données. Nous avons atteint un point où les deux fonctionnent très bien ensemble, et il serait relativement facile d’adapter le processus à un autre ensemble de documents. Toutefois, pour y arriver il faudrait modifier certaines sections de l’interface, c’est-à-dire intervenir au niveau de la programmation. En effet, afin de simplifier la programmation de certaines parties de l'interface, nous n'avons pas cherché à la rendre totalement indépendante de la base de documents qu'elle interroge.

Pour des raisons de disponibilité, de coûts et de choix d’outils de développement, nous avons choisi d’implanter le prototype sur un micro-ordinateur fonctionnant avec le système d’exploitation MS-DOS 6.22 et le système de fenêtrage Windows 3.11 (voir détails techniques en annexe A, page 125). D’autres environnements graphiques auraient pu s’avérer adéquats (Macintosh, Unix), et la présence d'une telle interface graphique constituait le principal critère.

Les outils de développement utilisés (voir annexe A) sont relativement courants: Microsoft Access pour la gestion de la base de données, Omnimark pour la traduction des documents SGML dans un format "relationnel" et Visual Basic pour la programmation de l’interface et l’ajout de l’information à la base de données. Ces outils étaient à la fois peu coûteux et simples à utiliser, tout en offrant une bonne flexibilité, ce qui s’avérait des qualités suffisantes pour ce projet de recherche.

4.4 Les différentes parties de l'interface et leur intégration

Un des résultats importants de notre réflexion autour des éléments d'interface nécessaires à l'interrogation d'une base de documents structurés a été d'identifier la nécessité de prévoir trois grandes fonctions dans un tel logiciel:

L'environnement de recherche permettra à l'usager de composer des requêtes de recherche, de les modifier, de les gérer, etc. L'environnement de consultation et de navigation doit permettre de consulter soit la base au complet ou encore certaines de ses parties. Il doit inclure des fonctions de navigation hypertextuelle et structurée (tables des matières, signets, etc.). Enfin, les fonctions d'aide à la recherche doivent aider l'usager à bien connaître la base, à formuler de bonnes requêtes et à exploiter la structure des documents à cette fin.

L’interface conçue dans le cadre de ce projet de recherche ne constitue pas un logiciel complet d'interrogation de documents structurés. D'abord parce que le modèle de documents structurés qui sous-tend son développement n'était pas entièrement spécifié au moment de la conception. Ensuite parce qu’il était impossible de réaliser toutes les parties dans les délais prescrits. Nous avons dû faire des choix, et ces choix étaient basés sur notre volonté d’arriver à un prototype qui fonctionne minimalement et de mettre l’accent sur les parties qui comportent des éléments d’interface particuliers aux documents structurés. Ainsi, nous avons laissé de côté certains éléments d’interface qui, même s’ils sont souvent essentiels, ne posaient pas de défis particulier par rapport aux documents structurés. Nous pensons entre autres à l’aide en ligne et aux barres d’outils et de statut. De plus, nous n’avons pas cherché à optimiser les performances générales d'ERIS, notamment en recherche.

ERIS comprend donc les parties suivantes:

Environnement de recherche:

La gestion de l'historique des recherches, trois bordereaux de recherche, mais seulement un qui est opérationnel puisque les deux autres correspondent à des fonctions du moteur de recherche qui n'ont pas encore été développées.

Environnement de consultation:

De cet environnement, on retrouve seulement la présentation des résultats de recherche. Le module de consultation en lui-même était trop complexe pour être réalisé dans le cadre de ce projet, et ce genre d'interface se retrouve déjà dans les logiciels de consultation de documents structurés.

Fonctions d'aide à la recherche:

Il s'agit de la partie la plus développée du logiciel, puisqu’on retrouve deux guides de la structure (sommaire et détaillé) utilisant des approches très différentes, la consultation des index de même que la description des identificateurs génériques ou noms d'attribut.

Ces environnements et ces fonctions sont constitués d'une ou de plusieurs fenêtres. Afin de bien montrer qu'ils ne s'agit pas de modules distincts, chaque fenêtre peut être montrée en permanence à l'écran. On peut donc utiliser différents environnements ou fonctions en même temps. En fait, les seules fenêtres qui ne peuvent être affichées en permanence sont les fenêtres de dialogue demandant à l'usager de faire un choix.

Mentionnons également que l’interface présente en permanence une barre de menus. On y retrouve le menu "Fichier", qui permet de quitter l’interface et de fermer la fenêtre active. Le menu "Édition" est inactif et on le maintient seulement par souci de conformité avec d'autres applications courantes. Le menu "Recherche" permet d’appeler les bordereaux de saisie des requêtes, de même que l’historique et la présentation des résultats. Le menu "Informations" permet quant à lui d’obtenir de l’information sur la structure et le contenu de la base de documents. Un menu "Aide" permet d’afficher une fenêtre "À propos du logiciel". En terminant, soulignons que lorsque la fenêtre du guide détaillé de la structure est affichée, un menu "Structure" apparaît; il sera expliqué plus loin.


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