| Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |
À l’aube du XXIè siècle, certains prétendent que les sociétés auparavant "industrielles" entament leur transition vers des sociétés de l’information. Que cette transition soit déjà réalisée, soit en cours ou à venir importe peu. Même si elle ne devait jamais se produire, il en reste que nous vivons aujourd’hui dans un monde où l’information est omniprésente, dans une multitude de formats qui sont tous de plus en plus accessibles.
Cette omniprésence de l’information vient en partie de la démocratisation des moyens d’édition. Même si l’édition d’un journal quotidien à grand tirage n’est pas à la portée de tous et chacun, l’expérience de l’Internet, et en particulier le World Wide Web, nous montre que de plus en plus, les outils nécessaires pour se faire entendre par les autres sont disponibles, abordables et simples d’utilisation.
Augmenter la quantité d’information qui déferle sur chaque être humain peut sembler une amélioration de la qualité de vie, mais au-delà d’une certaine limite, des outils sont essentiels pour qu’il parvienne à digérer cette information, la comprendre, l’analyser, en tirer profit, en rejeter même.
Ce rapport de recherche, rédigé dans le cadre d’un travail dirigé pour l’obtention de la maîtrise en bibliothéconomie et sciences de l’information de l’Université de Montréal, constitue notre modeste contribution à ce champ d’intérêt si important et qui le deviendra encore plus: le repérage de l’information.
Nous nous sommes particulièrement intéressés aux possibilités de recherche offertes par le stockage des documents selon un format structuré, format qui tente de rapprocher les outils informatiques du raisonnement humain sous-tendant la création même des documents. Nous croyons que les formats structurés offrent des possibilités intéressantes, en autant que des outils adaptés soient conçus. Nous avons réalisé un prototype se rapprochant d’un tel outil, appelé ERIS (Environnement de Repérage d’Informations Structurées), et nous vous invitons à le découvrir dans ce rapport.
La structure de ce rapport offre au lecteur deux possibilités de lecture. Ceux qui sont soucieux des détails techniques entourant la réalisation de cette recherche sont invités à consulter régulièrement les annexes qui viennent enrichir le corps du texte. D’un autre côté, les lecteurs intéressés surtout aux résultats et aux idées qui sont issues de la recherche peuvent omettre les annexes. Le corps du texte sera amplement suffisant, et de plus il n’est pas submergé de détails qui pourraient alourdir la lecture.
Ce rapport de recherche est présenté de façon habituelle; ainsi on retrouve d'abord la problématique et les objectifs, ensuite la méthodologie, puis l'état de la question, les résultats de recherche et enfin une discussion. Pour bien suivre cette structure, il faut se rappeler que les idées d'interface utilisées, de même que l'approche préconisée pour la conception de la base de documents constituent les résultats de cette recherche.
Ce rapport est accompagné d'une disquette pour micro-ordinateurs compatibles IBM qui contient les répertoires suivants:
| VBCODE | PROTOTYP | UTIL | OMNICODE | BASE_DON
Le répertoire VBCODE contient les sources Visual Basic qui servent à compiler ERIS (sous-répertoire PROTOTYP) et les différents programmes utilitaires (sous-répertoire UTIL). Le répertoire OMNICODE contient le programme Omnimark qui a servi à la conversion des données SGML. Finalement, le répertoire BASE_DON contient la base de données Access destinée à recevoir la base de documents, mais vide de tout contenu. Elle permet toutefois d'avoir une idée complète de la structure de la base de données.
Soulignons également que le logiciel ne peut être exécuté à partir de la disquette, parce que les fichiers de contrôles et surtout la base de données ne sont pas inclus. Nous n’avons pu ajouter ces éléments essentiels d’abord pour des raisons de droits de distribution, mais aussi à cause de leur grande taille. On peut toutefois essayer ERIS sur l'ordinateur ayant servi à la réalisation de ce projet, situé à l’EBSI (Université de Montréal).
Ce projet de recherche s’intéresse au problème général des interfaces humains-ordinateurs pour des systèmes de repérage de l'information, en particulier lorsque cette information est consignée dans des documents structurés. Le rôle de ces derniers en repérage de l’information n’est pas encore parfaitement compris, et les recherches sur les éléments d'interface requis en sont encore aux premiers balbutiements. Ce travail a donc pour objectif général d’apporter des éléments de réponse à ces problèmes.
L’arrivée des CD-ROM et l’avancement des télécommunications ont tous deux contribués à multiplier le nombre de bases de données en texte intégral disponibles sur le marché. Une étude souligne qu’entre 1985 et 1995, la proportion des bases de données textuelles qui étaient en texte intégral est passé de 28% à 49% (Williams, 1995). D’ailleurs, il s’agit du seul type de bases de données textuelles à avoir connu une hausse significative pendant cette période.
Ainsi, de plus en plus, on ne se contente plus de distribuer la description bibliographique de corpus documentaires, on distribue ces corpus au complet. La disponibilité du texte intégral peut sembler un ajout qui favorise la recherche dans les bases de données, mais seulement si les outils de recherche savent en profiter sans entraîner de désavantages. Ces désavantages pourraient être une augmentation du bruit parce que les concepts recherchés risquent d’être exprimés plus fréquemment sans nécessairement être pertinents, ou encore une baisse de la précision des recherches parce que les réponses se trouvent dissiminées dans des unités documentaires (habituellement les documents) de plus en plus grandes.
Parmi ces outils, l'utilisation de documents structurés s'avère intéressant. Les documents structurés sont des documents électroniques représentés selon un format structuré, c'est-à-dire un format qui utilise des balises pour décrire la structure logique des documents. Cette structure logique d'un document "correspond à un type de structuration permettant de présenter de façon cohérente et logique le contenu des documents" (Marcoux, 1994, p. 60). Souvent, la structure logique d'un document sera sa division en parties, chapitres, sections, etc., de même que certaines autres unités telles des notes de bas de page ou des références bibliographiques.
Si, par exemple, il est possible de conjuguer des termes de recherche avec leur emplacement dans la structure logique du document (chapitres, sections, paragraphes, citations, etc.), la recherche d'information prend une nouvelle dimension. Nous pouvons même imaginer des requêtes qui ne posent aucun critère sur le contenu textuel des documents et qui n’exploitent que le contenu logique, soit la structure.
Il existe des normes internationales pour le stockage des documents dans un format qui respecte leur structure logique. Ces normes offrent aux concepteurs des possibilités d’échange et d’interopérabilité entre systèmes, ce qui confère un autre avantage aux documents structurés respectant ces normes par rapport aux document utilisant des formats propriétaires. De plus, l'utilisation importante et toujours croissante des documents structurés nous incite à les étudier et à mieux exploiter leurs possibilités.
L'interface-utilisateurs constitue le lien essentiel entre toute base de données (incluant son moteur de recherche) et ses utilisateurs. Dans le cas qui nous intéresse, la conception de l’interface doit s'articuler autour d'une double problématique. D'abord, s'assurer que l'interface offre à l'usager toutes les possibilités de recherche permises par la structure de la base de données et le langage d’interrogation. Ensuite, rendre l'interface simple mais puissante, facile à apprendre mais sophistiquée. Dans le langage ergonomique, il s’agit d’optimiser l’utilisabilité du logiciel d’interrogation de la base de données.
L'intérêt principal de ce projet de recherche réside dans la réflexion autour des outils d'interface nécessaires à l'exploitation des bases de données de documents structurés. Cette réflexion reposera sur des règles ergonomiques établies, sur les possibilités offertes par les outils de développement d'interface modernes, de même que sur les caractéristiques des systèmes d'exploitation récents avec interface graphique et manipulation directe d'objets. Par conséquent, le produit de cette recherche, soit le prototype, présentera certaines idées d’interface originales.
Un dernier aspect important du problème à résoudre concerne le rôle du spécialiste de l'information dans l'informatisation des systèmes d'information. Ce dernier est fréquemment mis à contribution lorsqu'il s'agit de consulter les bases de données, ou encore de former d'autres utilisateurs. Récemment, nous avons vu de plus en plus de spécialistes de l'information prendre en charge des projets de création de bases de données. Ces deux rôles traditionnels touchent surtout au traitement de l'information (création de la base de données, des index) et au repérage (ou formation au repérage). Mais il existe un domaine intermédiaire où le spécialiste de l'information est habituellement absent: la création des outils de recherche documentaire, c'est-à-dire les logiciels qui permettent l'interrogation des bases de données.
Et pourtant, par leur rôle de spécialiste du repérage et du traitement de l'information, les spécialistes de l'information pourraient apporter une contribution significative à la construction d'interface. Ils connaissent non seulement le "système" que l'interface permet de consulter (la base de données) mais également les utilisateurs, la clientèle.
C'est pourquoi la création d'un prototype de logiciel d’interrogation pour une base de données de documents structurés revêt une importance particulière lorsque réalisée par un étudiant en bibliothéconomie et sciences de l'information. À la fin de ce projet, nous pourrons mieux cerner l'impact de la présence du spécialiste de l'information à ce stade de la chaîne de l'information.
En bref, la problématique de ce projet de recherche peut s'articuler autour de deux thèmes majeurs: les outils de recherche nécessaires pour exploiter la structure des documents, parce que ces derniers offrent des possibilités de recherche intéressantes; ainsi que le rôle du spécialiste de l'information dans la création et la gestion de ces outils.
Deux objectifs opérationnels, exprimés par des questions de recherche, peuvent être définis pour ce projet de recherche:
Le but à atteindre est donc la création d’un prototype de logiciel d’interrogation, tout en réfléchissant à ces deux aspects.
L’objectif ultime de ce travail de recherche étant la conception d’un prototype de logiciel avec une attention particulière portée à son interface, l’approche méthodologique utilisée est issue à la fois du génie logiciel et de l’ergonomie: la conception centrée sur l’usager. Cette méthode de développement est présentée dans la section suivante, avec notamment les adaptations nécessaires.
Même si la conception d'ERIS constituait le coeur de ce projet, certaines tâches préliminaires ou connexes furent effectuées:
Pour ces tâches, seules les idées principales, qui présentent un caractère original, seront discutées dans le corps de ce rapport. Le lecteur est prié de consulter les annexes pour en savoir plus sur ces aspects.
Le développement "centré sur l'usager et sur les tâches", ou approche ergonomique, fut retenu pour la partie conception de ce projet. On peut schématiser cette démarche par quelques étapes préliminaires, un ensemble d'étapes réalisées itérativement et quelques étapes terminales (voir Figure 1: schéma de la méthodologie, page 8). Cette schématisation est tirée de Robert et Fiset (1992, p. 68).
Cette approche a inspiré la méthodologie utilisée pour le développement d'ERIS, mais certains ajustements ont dû être faits. Ainsi, l’analyse de la littérature fut effectuée en grande partie en début de projet, mais elle fut complétée vers le fin afin de tenir compte des nouveautés dans le domaine. À noter que cette étape s’inscrit naturellement dans tout projet de recherche.
Figure 1: schéma de la méthodologie
ÉTAPES PRÉLIMINAIRES
ÉTAPES ITÉRATIVES
--> Retour à l'étape 4, jusqu'à ce que le prototype soit satisfaisant ÉTAPES TERMINALES
|
L’analyse des possibilités techniques, peu critique pour un prototype destiné à la recherche seulement, fut effectuée au moment du choix des équipements et logiciels, sans méthodologie particulière.
De son côté, l’analyse des systèmes semblables n’a pu se faire en début de projet, puisque de tels systèmes n’étaient pas facilement accessibles à ce moment. Toutefois, trois logiciels intéressants furent rendus disponibles en cours de projet, et nous en ferons une brève analyse.
La recherche d'information est une tâche très diversifiée qui nécessite des logiciels d'une certaine complexité. Réaliser une analyse de tâche globale pour le prototype était difficile, et nous avons opté pour la segmentation du prototype en grandes fonctions. Une analyse de tâche fut effectuée pour chaque fonction, ainsi que pour leur intégration. Aucune description ou formulation précise ne fut utilisée; les tâches, pour la plupart parallèles, furent décrites en général. La présentation des résultats est d'ailleurs divisée selon ces fonctions, et les résultats de l'analyse de tâche s’y retrouvent sous la forme d’objectifs pour chaque grande fonction.
L’analyse des besoins a un caractère particulier dans ce projet. En effet, dans un contexte plus global, l’objectif était de permettre d’exploiter les possibilités de recherche d’un modèle en construction. Les besoins sont donc d’abord dictés par ce modèle, puis l’interface est conçue en fonction d’un certain type d’usagers, et non l’inverse. Le rôle d'ERIS n’est donc pas de répondre à un besoin précis chez une clientèle ciblée, mais bien de permettre des recherches d’information impossibles dans les autres systèmes. Les besoins seront donc exprimés dans la partie qui présente les fondements théoriques sur lesquels s'appuie ce prototype.
La troisième étape, qui consiste à élaborer le modèle général d'interface, fut réalisée à la suite d'une réflexion basée sur les résultats obtenus lors de la deuxième étape. Ainsi, un scénario général d'interface fut construit pour répondre aux besoins et réaliser les tâches nécessaires.
Les étapes 4 et 5 ont permis d'implanter le scénario obtenu, ce qui fut réalisé module par module. Une fois les différents modules conçus et "assemblés" de façon à fonctionner ensemble, ERIS fut évalué par des usagers (étape 6). Ces trois étapes, normalement itératives lorsqu'il s'agit de concevoir un logiciel complet, ne furent réalisées qu'une seule fois, puisque l'objectif était de réaliser un prototype seulement.
La norme ISO 8879, Standard Generalized Markup Language (SGML) permet de représenter tout type de document. Depuis son acceptation en tant que norme ISO (International Organization for Standardization) en 1986, de nombreux organismes l'ont utilisée comme base technologique pour leur gestion documentaire. C'est le cas notamment du Département de la défense américain.
Le prototype conçu dans le cadre de ce projet de recherche est destiné à interroger des documents structurés en format SGML. Une certaine connaissance des concepts associés à cette norme est donc nécessaire pour bien suivre ce travail. Dans cette courte section, nous allons présenter brièvement les concepts qui seront utilisés dans le travail. Le lecteur qui veut en savoir plus sur SGML peut consulter les documents de Marcoux (1995), Goldfarb (1990) ou Van Herwijnen (1995), présentés dans la bibliographie (page 122).
Les documents qui respectent la norme SGML sont des documents textuels (fichiers ASCII) qui utilisent la technique du balisage pour marquer certaines parties du texte. Ces balises sont définies dans une DTD (Document Type Definition), soit une grammaire qui définit rigoureusement quelles balises sont permises et dans quel contexte. Comme leur nom l'indique, les DTD sont habituellement associées à un type de document; on créera par exemple une DTD pour les livres, pour les articles, les mémos, etc.
Une façon simple de comprendre SGML est de voir cette norme comme une série de prescriptions permettant de concevoir des DTD. Ainsi, un document SGML sera un document textuel, balisé en respectant une DTD qui elle-même fut créée en respectant la norme SGML.
Un document SGML est composé essentiellement de trois parties: une déclaration SGML, qui définit certains paramètres, la DTD que respecte le document, et enfin l'instance du document comme telle, soit le texte balisé. Dans cette courte introduction, nous allons nous concentrer sur les deux dernières parties.
Les documents SGML utilisent trois concepts importants: des éléments, des attributs et des entités. Une façon simple de voir les entités est de les considérer comme des symboles qui représentent une autre chaîne de caractères. Lorsque les entités sont utilisées dans l'instance du document, on leur substitue tout simplement ce qu'elles représentent. Les entités permises de même que leur valeur sont bien entendues définies dans la DTD.
Les éléments constituent le coeur de tout document SGML. Chaque partie de texte est comprise à l'intérieur d'un élément d'un certain type. Le type d'un élément est déterminé par son identificateur générique. Les identificateurs génériques permis sont bien sûr définis dans la DTD, où on retrouve également un modèle de contenu ("content model") associé à chaque identificateur générique. Ce modèle de contenu détermine précisément le contenu que l'on peut retrouver à l'intérieur d'un élément de ce type, c'est-à-dire quels sont les types d'éléments permis, dans quel ordre ils peuvent se présenter, combien il peut y en avoir, et finalement s'ils peuvent contenir du texte.
Cette notion de modèle de contenu permet de réaliser que les documents SGML peuvent être vus comme des hiérarchies strictes d'éléments. En effet, il existe toujours un élément hiérarchique supérieur qui contient tous les autres. Chaque élément est entièrement contenu à l'intérieur d'un autre, d'où le caractère strict de la hiérarchie.
Le dernier concept important est celui des attributs. Les attributs sont une paire (nom=valeur) que l'on associe à un élément. Il existe donc des noms d'attribut et des valeurs d'attributs. Dans la DTD, on retrouve pour chaque élément les attributs qui sont permis, et parfois les valeurs qu'ils peuvent prendre. Les attributs viennent en quelque sorte qualifier les éléments auxquels ils sont identifiés.
Ces quelques remarques sur SGML sont suffisantes pour donner une bonne idée de la constitution d'un document SGML, mais nous devons également dire quelques mots sur la philosophie associée à cette norme. En effet, même si aucune prescription de la norme ne l'oblige, les DTD sont habituellement conçues de manière à représenter la structure logique des documents, soit leur division en chapitres, sections, paragraphes, etc., ou encore pour représenter le contenu des documents, soit le marquage de parties du texte comme des noms de personne, des expressions importantes, des adresses, etc. La plupart des DTD utilisent les deux approches à la fois.
Les documents SGML sont donc habituellement des documents structurés, et la norme se prête particulièrement bien à cette représentation. Ainsi, les documents contiennent très peu d'informations de formatage, c'est-à-dire destinés à indiquer à une application quelconque la façon de présenter le document (que ce soit sur papier, à l'écran, etc.). À la place, on retrouve des applications SGML qui permettent de traiter ces documents en fonction d'une opération particulière (impression, distribution électronique, etc.).
Cette indépendance de l'information que permet SGML par rapport au traitement effectué sur cette information constitue aujourd'hui une très bonne raison d'utiliser SGML pour la gestion documentaire, et de plus en plus d'institutions adoptent cette approche. Dans le cadre de ce travail, nous réfléchissons au repérage d'information dans des documents structurés, représentés à l'aide de SGML.
| Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |