| Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |
L'objectif ultime de ce travail de recherche est de construire un prototype de logiciel d'interrogation qui fera le pont entre des usagers en quête d'information et l'information disponible dans des documents en format SGML. Pour arriver à ce résultat en apparence simple, nous avons choisi de traiter les documents afin de les rendre dans un format facile à interroger et de leur ajouter certaines informations qui faciliteront le travail du logiciel d'interrogation, et par le fait même celui des usagers. Cette conversion a nécessité plusieurs étapes dont voici une vue d'ensemble:
Il est important de noter que même si les étapes sont présentées de façon séquentielle, elles n'ont pas toujours été effectuées dans cet ordre. En effet, avec l'évolution de la conception du logiciel, certains éléments ont dû être ajoutés à la base de documents, habituellement pour permettre une plus grande efficacité. Les étapes 3 et 4 ont ainsi été effectuées en partie en parallèle.
Le choix des documents pour constituer la base de documents s'avérait une étape importante, puisque cette base allait permettre de tester à la fois le prototype et le modèle de recherche. Les critères de choix étaient les suivants:
Il est important de noter que ces critères étaient plutôt des préférences, aucun ne constituant une condition essentielle. De plus, il ne sont pas présentés ici selon un ordre d'importance. Des recherches sur l'Internet nous ont permis d'identifier un ensemble de documents répondant à tous ces critères. Il s'agit de la documentation en français du logiciel d'exploitation réseau Netware de Novell Inc. Cette société nous a aimablement donné la permission d’utiliser ces documents à des fins de recherche.
Ces documents SGML (DTD "Docbook" créée spécialement pour les manuels de logiciels par le groupe Davenport), étaient prévus pour être publiés avec le lecteur Dynatext. Il s'agit d'un ensemble de 12 livres qui font au total 8 Mega-octets (Mo) environ. Huit livres furent sélectionnés, pour une taille totale de 3 Mo, ou 2 Mo de texte une fois les balises SGML supprimées.
Tout le traitement initial des documents SGML fut effectué avec l'environnement de programmation Omnimark de Exoterica. Cet interpréteur/compilateur permet de créer des programmes pour manipuler des documents textuels, et en particulier des documents SGML.
Un programme Omnimark fut conçu, et ce programme devait prendre les documents SGML et en faire des fichiers de type "texte délimité" pouvant être lus directement avec le logiciel de gestion de bases de données relationnelles. Ce programme, présenté en annexe B (page 138), est relativement simple puisque tous les éléments reçoivent le même traitement. D'ailleurs, il serait facile de l'utiliser pour des documents SGML respectant une autre DTD.
Les documents furent donc traités afin de les représenter dans une base de données relationnelle. Les informations à inclure étaient les suivantes:
Le modèle de données utilisé est intéressant en lui-même, et nous allons le décrire brièvement ici afin d'en souligner les particularités. À noter que ce modèle fut conçu par le professeur Yves Marcoux, directeur de ce projet de recherche. Le lecteur trouvera à l'annexe F (page 169) la description détaillée de la structure de la base de données.
Deux entités importantes sont représentées par autant de tables dans la base de données: les noms d’attribut (table AttNom) et les identificateurs génériques (table IdenGene). Nous avons agi de la sorte car seulement quelques noms d'attribut et identificateurs génériques sont utilisés, mais en plusieurs occurrences. Les regrouper dans une table réduit la taille de la base de données, et permet également d'ajouter d'autres informations. Tous les enregistrements de ces tables possèdent un numéro identifiant uniquement le nom d'attribut ou l'identificateurs générique et on y retrouve également des informations supplémentaires qui sont utiles à différents endroits dans ERIS.
Un deuxième ensemble d'informations est celui des occurrences des éléments et des attributs dans le document. Ces occurrences sont représentées par deux tables, une pour les éléments (table Noeuds) et une pour les attributs (table Attributs). L'information qu'on y retrouve était fournie par le programme Omnimark, qui fonctionnait à peu près comme suit: à chaque fois qu'un élément SGML était "ouvert", une ligne était inscrite dans le fichier d'entrée de la table Noeuds. Ces éléments étaient comptés, permettant ainsi d'assigner une clé primaire numérique, et lorsqu'il y avait un contenu textuel, un nouvel élément (d’identificateur générique PCDATA) était créé et son contenu était inscrit dans un champ dédié (champ Contenu). Ceci était nécessaire afin de bien traiter les éléments à contenu mixte, qui contiennent à l'occasion du texte entre d’autres éléments.
Les occurrences d'attributs étaient gérées un peu de la même façon. Pour chaque élément, on insérait des lignes dans un fichier qui a servi d'entrée pour la table Attributs. Ces lignes contenaient le numéro unique de l'occurrence de l'attribut, un numéro identifiant le nom de l'attribut, et la valeur de cet attribut. Bien entendu, on y ajoutait le numéro de l'élément auquel était associé cet attribut.
Ces quatre tables furent complétées par la table Liens. Cette dernière est très importante, puisqu'elle contient toute l'information sur la structure (hiérarchique et hypertextuelle) de la base de documents. Ses deux champs principaux (Source et Cible) contiennent chacun un numéro d'élément (table Noeuds) et établissent une relation entre ces deux éléments. Cette relation peut être du type parent-enfant ou hypertextuelle; un champ booléen en précise le type. Finalement, dans le cas des types de liens parent-enfant, l'ordre des enfants d'un même parent est important, et pour chaque relation de ce type, un nombre est inscrit dans un champ afin d'indiquer cet ordre.
Toute l'information contenue dans les sources SGML se retrouve dans les cinq tables décrites précédemment. Plusieurs autres informations ont été ajoutées à ces tables et plusieurs autres tables furent ajoutées, mais à des fins de conception du prototype seulement; quelques-uns de ces ajouts sont décrits dans la prochaine section. Le lecteur est prié de consulter l'annexe F pour en savoir plus sur la structure finale, de même que la section suivante pour en savoir plus sur différents utilitaires qui furent employés pour rajouter de l'information à la base.
La base de données telle que nous venons de la décrire aurait pu être suffisante pour la construction d’une interface minimale pour l’interroger. En effet, toutes les informations des documents SGML s’y retrouvent. Toutefois, à la fois pour rendre ERIS plus performant et permettre certains éléments d’interface, nous avons ajouté un certain nombre d’informations à la base de données.
Le logiciel Omnimark permet de traiter les documents SGML parce qu’il "comprend" ces documents. Pour les comprendre, il parcourt les fichiers caractère par caractère, et reconnaît les ensembles de caractères qui doivent être interprétés d’une façon particulière. Il reconnaîtra ainsi le début et la fin des éléments, les attributs, les ancêtres des éléments, etc. Puisque cette lecture est faite caractère par caractère, il descend toujours le plus bas possible dans une hiérarchie avant d’en remonter.
Cette façon de procéder a une conséquence heureuse car les numéros d’élément dans la table Noeuds ont une signification: un élément et tous ses descendants seront nécessairement une suite continue de numéros d’éléments. Par exemple, l’étendue d’un élément pourrait être de l’élément 234 à l’élément 345. Mais elle ne pourrait pas être brisée, comme entre 123 et 432 puis 487 et 576.
Ainsi, nous pouvons assigner un numéro de "fin" pour chaque élément. Ceci nous dit sans équivoque que le début d’un élément se situe au numéro de cet élément, et que sa fin se situe à l’élément de "fin". Tous les éléments qu’on retrouve entre les deux (classés par ordre de numéro d’élément) sont des descendants de cet élément. De cette façon, il est extrêmement facile de savoir quels éléments se retrouvent à l’intérieur de quels autres, quelles occurrences de mots (voir les notes sur l’indexation plus loin) appartiennent à quels éléments, etc.
Pour trouver ces numéros de fin, nous avons conçu un petit programme (\VBCODE\UTIL\ETENDUE.MAK) qui, pour chaque élément, trouve l’élément suivant qui est soit au même niveau hiérarchique que lui, soit à un niveau hiérarchique plus élevé. L’élément précédant sera l’élément de fin. Il nous fallait donc l’information sur les niveaux hiérarchiques.
Pour l’obtenir, nous avons créé un autre programme (\VBCODE\UTIL\NIVEAUX.MAK) qui parcourt lui aussi l’ensemble des éléments et pour chacun note combien d’éléments ont été "ouverts" (et n'ont pas encore été fermés) depuis le premier. L’élément hiérarchique supérieur se verra donc attribuer le niveau un, ses enfants le numéro deux, et ainsi de suite.
Afin d'accélérer les recherches dans la base de documents, mais aussi pour permettre l'utilisation de certains éléments d'interface tels l'index de la base, nous avons décidé de créer un "fichier inversé" de la base de documents au complet. Les tables "Occurrences" et "Index" contiennent ce fichier inversé. Cette dernière contient tous les mots retrouvés dans la base, à l'exception de ceux qui figurent dans la table "Antidictionnaire" (liste des mots vides), alors que la table "Occurrences" contient les occurrences de ces mots, le numéro de l'élément où se trouve l'occurrence, de même que la position du mot.
Certains aspects du processus d'indexation méritent d'être mentionnés ici. Tout d'abord, l'antidictionnaire fut constitué à partir de listes de mots vides que l'on retrouve dans certains logiciels, avec des modifications. Aucune véritable recherche sur l'importance de la liste des mots vides ne fut effectuée, étant donné le caractère "accessoire" du processus d'indexation dans le projet de recherche.
Un seul index fut constitué pour l'ensemble de la base. Toutefois, en inscrivant les éléments où se retrouvent les occurrences de chaque mot, il est relativement aisé de générer un index particulier pour certains éléments de la base. D'ailleurs, l’interface effectue ce genre d'opérations dynamiquement, sur demande de l'utilisateur.
La position des mots dans le texte fut notée afin de permettre des recherches par proximité. Nous avons décidé de noter la position absolue des mots dans le texte, c'est-à-dire en commençant à un pour le premier mot et en continuant à compter jusqu'au dernier. Cette façon de faire a pour seul but de simplifier le moteur de recherche. De plus, nous n'avons pas compté les mots vides dans le calcul des positions.
Les mots retrouvés et conservés dans la table "Index" sont appauvris, c'est-à-dire qu'ils ne contiennent que des minuscules et des caractères non accentués. Il s'agit toutefois de la seule opération qui fut effectuée sur les mots du texte. La même routine qui a servi à transformer les mots pendant l'indexation est utilisée en recherche pour transformer les termes de recherche.
Le programme ayant servi à créer le fichier inversé est distribué sur la disquette accompagnant ce rapport (\VBCODE\UTIL\INDEX.MAK). Il faut noter que le processus d'indexation a pris un temps considérable, soit environ 50 heures.
Le prototype conçu dans le cadre de ce projet de recherche tente d'aider les usagers à exploiter la structure des documents. Afin d'y parvenir, plusieurs informations sur cette structure sont nécessaires et certaines furent "calculées" préalablement. Elles se retrouvent dans les tables "AttPoss", "Descendants" et "Enfants".
La table "AttPoss" contient tous les noms d'attribut que l'on peut retrouver pour chaque identificateur générique. La table "Enfants" contient tous les identificateurs génériques que l'on peut retrouver immédiatement au-dessous (d'un point de vue hiérarchique) de chaque identificateur générique. La table "Descendants" est similaire, sauf qu'elle contient les identificateurs génériques que l'on peut retrouver n'importe où au-dessous de chaque identificateur générique, pas nécessairement immédiatement au-dessous.
Un petit programme (\VBCODE\UTIL\DESCEND.MAK) permet d’alimenter ces tables.
| Travail dirigé de Martin Sévigny, ©1996 | Section précédente | Section suivante | Page d'accueil | |