Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |
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 nest pas essentielle pour bien comprendre les enjeux de linterface, 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 lEBSI, 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 quil existait au mois daoû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 linformation à lintérieur de ces documents. Il ne sappuie sur aucune norme ou aucun format déjà établi, mais se veut plus général et tente de définir tout ce quil est possible de faire avec de tels documents.
La représentation des documents du modèle Marcoux se fait à laide dun 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 sagit 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 dunifier 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 lensemble de résultats dune recherche constitue toujours un sous-ensemble de la base de documents, et ce sous-ensemble peut sexprimer à laide dun 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 dune complexité et dune 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 dun noeud, et par le fait même une requête de recherche exploitant la structure. Dun autre côté, lutilisation 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 dexemple dinterrogation 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), lutilisation de relations entre différents noeuds (deuxièmes chapitres dun 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.
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 cest 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.
Lutilisation de la norme SGML est de plus en plus répandue, et on retrouve aujourdhui 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 linterface de manière à transcender ce choix et à demeurer général, mais certains aspects sont toutefois influencés. Par contre, linterface est assez générale pour servir dinstrument de vérification et dexpérimentation du modèle Marcoux, et dans ce sens elle joue parfaitement son rôle.
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 dinterrogation. Bien sûr, ces deux composantes respectent certaines règles afin quelles 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 sagit de léditeur de la base de données, du producteur du logiciel dinterrogation et de lusager. Léditeur sera habituellement responsable du contenu intellectuel de linformation, le producteur du logiciel sassurera de permettre à lusager dinterroger efficacement les informations et ce dernier tentera de se familiariser avec lenvironnement 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 den faire un outil de recherche intéressant et simple à construire. Mais il ne faut pas perdre de vue ces rôles, et cest pourquoi nous y reviendrons dans la partie discussion de ce rapport.
Dans ERIS, le rôle de léditeur et celui de lusager ont été réduits à zéro. En effet, l'usager ne peut pas personnaliser son environnement de recherche. De plus, lenvironnement de recherche ne permet d'interroger quune seule base de documents. Il sagit donc dun bloc monolithique sans souplesse véritable, ni pour léditeur ni pour lusager. 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 à lensemble 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".
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 dinterrogation, soit linterface 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 linterface 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 dadapter le processus à un autre ensemble de documents. Toutefois, pour y arriver il faudrait modifier certaines sections de linterface, cest-à-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 doutils de développement, nous avons choisi dimplanter le prototype sur un micro-ordinateur fonctionnant avec le système dexploitation MS-DOS 6.22 et le système de fenêtrage Windows 3.11 (voir détails techniques en annexe A, page 125). Dautres environnements graphiques auraient pu savé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 linterface et lajout de linformation à la base de données. Ces outils étaient à la fois peu coûteux et simples à utiliser, tout en offrant une bonne flexibilité, ce qui savérait des qualités suffisantes pour ce projet de recherche.
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.
Linterface 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 quil é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é darriver à un prototype qui fonctionne minimalement et de mettre laccent sur les parties qui comportent des éléments dinterface particuliers aux documents structurés. Ainsi, nous avons laissé de côté certains éléments dinterface qui, même sils sont souvent essentiels, ne posaient pas de défis particulier par rapport aux documents structurés. Nous pensons entre autres à laide en ligne et aux barres doutils et de statut. De plus, nous navons 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, puisquon 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 linterface présente en permanence une barre de menus. On y retrouve le menu "Fichier", qui permet de quitter linterface 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 dappeler les bordereaux de saisie des requêtes, de même que lhistorique et la présentation des résultats. Le menu "Informations" permet quant à lui dobtenir de linformation sur la structure et le contenu de la base de documents. Un menu "Aide" permet dafficher 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 | |