Afin de conserver les attributs typographiques des documents originels, nous avons conçu dans WordPerfect 5.1 une macro permettant de convertir les codes WordPerfect propres à l'ouverture et à la fermeture des caractères gras, italiques, de soulignement et de double soulignement, en des séquences de caractères ASCII que l'on pourrait qualifier de balises d'ouverture et de fermeture. Ces balises, incidemment, ont la forme de balises SGML (i.e.: <g>...</g>), mais ne doivent pas être confondues avec les balises de styles que l'on retrouve dans l'extrant SGML final. Elles ne sont, à cette étape du processus de conversion, qu'une façon de conserver l'information relative aux attributs typographiques des portions de textes concernées en prévision d'une conversion des fichiers WordPerfect en fichiers texte (ASCII). Les fichiers obtenus après l'exécution de la macro sont sauvegardés en format WordPerfect 5.1.

Une fois les fichiers de loi débarrassés de leurs codes WordPerfect d'attributs typographiques - maintenant que l'information est encodée sous forme de séquences de caractères ASCII -, il est possible de les sauvegarder entièrement en format ASCII. Cette étape permet en outre d'éliminer l'information axée sur la restitution papier du document. En effet, les en-têtes et pieds de page où figure par exemple le nom de l'organe de publication des lois ("Le Journal du Mali"), la pagination, de même que certaines informations enclavées dans les codes WordPerfect d'origine telles les polices de caractères employées, la taille des caractères, les sauts de page, etc., sont automatiquement perdus lors de la conversion. Aucun traitement supplémentaire n'a donc dû être prévu en amont (macro WordPerfect) ou en aval (programme de "conversion enrichie" de OmniMark) de cette étape pour faire disparaître ces informations jugées superflues. Toutefois, nous avons dû utiliser un outil supplémentaire, soit WordPerfect 6.0 pour Windows, pour effectuer la sauvegarde des fichiers en format ASCII (plus précisément en format "texte délimité ASCII"). En effet, cette version du logiciel - contrairement à la version 5.1 pour DOS - permet une sauvegarde où seules figurent les marques de retour à la ligne que l'on retrouve dans le texte original, c'est-à-dire une sauvegarde qui n'ajoute pas de marques de retour à la ligne supplémentaires aux endroits où le traitement de texte a inséré des retours de chariot afin de pouvoir cadrer la totalité du texte à l'écran. Ceci s'est avéré nécessaire parce que nombre d'éléments SGML, dans l'étape suivante de "conversion enrichie", se définissent comme étant terminés par un retour à la ligne (ex.: un paragraphe, un titre, etc.).

Haut de la page

Cette étape, qui constitue le coeur du processus de "SGMLisation" du corpus, est celle qui a exigé le plus de travail. Avant d'en exposer les caractéristiques techniques, nous aimerions tout d'abord présenter l'outil utilisé, soit le convertisseur OmniMark, en raison de son rôle prépondérant.

OmniMark est un convertisseur apte à traiter à la fois du SGML et du non-SGML. Dans un processus de "conversion enrichie" (traduction libre de up-conversion), le traitement du non-SGML est accompli grâce à un puissant langage d'expressions régulières. Le traitement du texte est effectué en étroite relation avec le parseur SGML interne à l'outil, de sorte que la reconnaissance de patrons peut être dépendante du contexte SGML. Ces patrons, tout comme les autres variables (compteurs (counters), commutateurs (switches) et canaux (streams)), peuvent être nommés puis réutilisés, ce qui permet des constructions complexes. À l'inverse des langages de programmation les plus connus (perl, C++, etc.), qui se définissent comme étant des langages procéduraux, OmniMark est un langage basé sur des règles (rule-based language). Il convient tout à fait au traitement du texte et plus particulièrement au SGML, puisque celui-ci nécessite l'exécution d'une action lorsqu'un événement particulier est rencontré. Ces actions étant dictées sous forme de règles, l'essentiel d'un programme OmniMark est donc composé d'une suite de règles de reconnaissance d'événements, auxquelles on fait correspondre une/des action(s) en fonction de conditions données.

Telles que retrouvées dans le programme de "conversion enrichie", les différentes règles de reconnaissance des patrons de constituants logiques présents dans les fichiers d'intrant s'appuient sur une analyse très poussée de la structure des 37 lois étudiées, jusque dans les moindres aspects de celle-ci. Le détail de la description de chacun des patrons a pris en compte la totalité du corpus et nous avons veillé à inclure la reconnaissance d'un maximum de syntaxes alternatives pour un constituant logique donné, tout en s'assurant de n'être pas trop permissives, ce qui aurait pu causer des reconnaissances erronées au point de vue de la sémantique des éléments SGML.

Nous donnons ici, à titre d'exemple uniquement, la règle relative à la reconnaissance du type d'acte (qui deviendra l'élément <typeacte>), lequel est suivi du numéro de l'acte (élément <numacte>):

find (LINE-START WHEN OPEN ELEMENT IS intitule)
(stylble "L" styles UL "o" styles UL "i" stylble) = loi
((UL "n")? styles ("%248#" OR UL "o")? stylble
((DIGIT OR "-" OR "_") stylble)+ "/"? stylble
("AN-RM" OR "P-RM")? ) = numero
OUTPUT "<typeacte>"
process-text loi
OUTPUT "<numacte>"
process-text numero
DEACTIVATE avant-loi
ACTIVATE deb-portant

En gros, cette règle prévoit la reconnaissance du mot "Loi" où seule la première lettre est obligatoirement en majuscule, suivi éventuellement de la lettre "n" maj/min, suivi éventuellement de "o" maj/min ou "°" selon la syntaxe employée, suivi d'une chaîne composée uniquement de caractères numériques, ainsi que des caractères "-" ou "_", suivi de l'éventuel caractère de délimitation "/", suivi enfin éventuellement des chaînes "AN-RM" ou "P-RM". La justesse de la reconnaissance est renforcée par une condition qui prévoit que l'élément parent de la chaîne de caractères qui répond au patron de reconnaissance doit être l'élément <intitule>. Le commutateur [avant-loi] est désactivé, ce qui clôt la portion de texte marquée comme étant localisée avant le texte de la loi comme tel. La macro [process-text], dont le détail ne figure pas ici car elle est définie en début de programme, sert à traiter caractère par caractère le contenu des portions de textes récupérées dans les variables [loi] et [numero]. On peut ainsi identifier les séquences de caractères ASCII relatives aux attributs typographiques et baliser les portions de textes correspondantes conformément à la DTD, c'est-à-dire selon une hiérarchie parentale entre les éléments de styles: d'abord un élément <g> (gras), puis <i> (italique), puis <s> (soulignement), puis enfin <ds> (double soulignement). Les commutateurs [avant-loi] et [deb-portant] sont respectivement désactivé et activé. L'état des commutateurs constitue une condition booléenne sur laquelle s'appuie la reconnaissance de certains autres éléments.

Haut de la page

Comme nous désirions, à des fins d'indexation, faire une certaine utilisation de la macro-structure des textes telle que reflétée par le balisage SGML, il nous a fallu rendre cette information lisible par le logiciel SATO. Nous avons envisagé cette possibilité conformément à un principe de base de la philosophie SGML, qui veut que l'information, une fois balisée en SGML, puisse être réutilisée plusieurs fois et selon diverses variantes quant à la portion d'information réemployée et à la forme du contenant (format particulier). Cette opération, où l'information passe d'un format SGML à un format non-SGML, est appelée "conversion appauvrie" (traduction libre de down-conversion). OmniMark était l'outil tout désigné pour accomplir cette tâche puisqu'il permet d'effectuer - en plus des "conversions enrichies" - ce genre de "conversions appauvries". En outre, à cette étape du processus nous étions devenues beaucoup plus familières avec son langage de programmation.

Dans un programme de "conversion appauvrie", les règles sont dirigées vers le traitement du contenu des éléments SGML. Nous avons fait en sorte que soit versé intégralement à l'extrant le balisage SGML et que soient également ajoutées les séquences de caractères définissant des propriétés SATO nécessaires pour le choix ultérieur des candidats-descripteurs. L'exemple que nous donnons ici, tiré du programme employé dans le prototype, concerne l'élément <numchap> dont le contenu sémantique correspond au numéro de chapitre.

element numchap
INCREMENT chapitre BY 1
OUTPUT "<%lq> *chapitre=p%d(partie)t%d(titre)c%2fzd(chapitre) %c</%lq>"
PUT symbo-chapitre "p%d(partie)t%d(titre)c%2fzd(chapitre) "

En bref, pour chaque élément <numchap> rencontré dans l'ordre d'apparition naturel de lecture du texte, le compteur chapitre est incrémenté d'une unité. On verse à l'extrant [OUTPUT] le contenu intégral [%c] du texte de l'élément <numchap>, précédé d'une propriété SATO [*chapitre=] dont la valeur correspond à une clé unique [p%d(partie)t%d(titre)c%2fzd(chapitre)] identifiant du même coup le numéro de la partie, du titre et du chapitre dont il est question. Les chiffres qui composent cette clé correspondent à la valeur des compteurs mis en place. Le tout est encadré par des balises d'ouverture [<%lq>] et de fermeture [</%lq>] possédant le même nom que l'élément d'origine, i.e. <numchap>. Enfin, la variable symbo-chapitre se voit attribuer une valeur identique à la valeur de la propriété SATO définie plus haut [p%d(partie)t%d(titre)c%2fzd(chapitre)], ceci afin que son contenu puisse être redirigé, au moment du traitement d'un autre élément, ailleurs dans l'extrant (en l'occurrence au sein d'une liste de l'ensemble des valeurs prises par cette propriété SATO devant figurer au tout début du fichier).

Haut de la page

Cette étape consiste en un "nettoyage", à l'aide d'un bref programme OmniMark de "conversion croisée", des fichiers d'extrant fournis par SATO. Cette opération s'avère nécessaire afin de pouvoir soumettre les fichiers d'extrant SATO à une dernière étape de "conversion appauvrie" permettant d'intégrer les descripteurs obtenus suite au processus d'indexation au balisage SGML. Essentiellement, le programme de "conversion croisée" prévoit l'élimination de différents éléments insérés automatiquement dans les fichiers par SATO: espaces supplémentaires en fin de ligne, doubles astérisques ("**") servant à briser les lignes trop longues et préambule indiquant les différentes propriétés SATO susceptibles d'être retrouvées dans les textes analysés. Enfin, comme le traitement effectué sur les textes de lois à l'aide de SATO engendre le "blocage" des lexies complexes (c'est-à-dire que les divers constituants de ces dernières sont liés par des traits de soulignement de manière à être analysés comme une même entité par le logiciel), nous avons jugé bon à cette étape de procéder à un "déblocage" du corpus en convertissant les caractères de soulignement en espaces (ex: aéronautique_civile -> aéronautique civile). Mentionnons que ce type de conversion ne fait pas usage du parseur SGML interne à OmniMark.

Cette étape utilise un programme de "conversion appauvrie" pour intégrer au balisage SGML les candidats-descripteurs identifiés, dans les fichiers d'extrant, par une suite de propriétés SATO. Ces propriétés sont au nombre de quatre. Les trois premières indiquent, pour un descripteur donné, le niveau d'indexation concerné, la ou les raison(s) à l'origine du choix et la forme lemmatisée. Une dernière propriété "bidon", enfin, sert à marquer la fin de la suite de propriétés SATO. La conversion effectuée consiste à repérer les candidats-descripteurs et à déterminer à quelle(s) subdivision(s) ils se rattachent en fonction de la valeur de la propriété SATO correspondante (ex: loi et/ou partie), puis à inscrire, là où le prévoit la DTD - c'est-à-dire au tout début de l'énoncé d'une subdivision -, la forme lemmatisée du candidat-descripteur dans un élément SGML réservé à cette fin, soit <desc>. Cet élément possède un attribut nommé "raison" (correspondant à la propriété SATO similaire), qui peut être constitué d’une des valeurs suivantes ou d'une combinaison de plusieurs d'entre elles (voir également la section Choix des candidats-descripteurs avec SATO de la méthodologie relative au volet indexation):

• chi2 (candidat-descripteur retenu en fonction de sa valeur de Chi²);
• discri (candidat-descripteur retenu en fonction de sa valeur discriminante);
• int (candidat-descripteur retenu en fonction de sa présence dans un intitulé textuel);
• freqtot (candidat-descripteur retenu en fonction de sa fréquence totale d'apparition).

Les propriétés SATO étant inscrites dans les fichiers d'extrant à la suite de chacune des occurences d'un même candidat-descripteur, nous avons implanté, au niveau de ce programme, un mécanisme d'élimination des doublons pour faire en sorte que la suite de descripteurs obtenue au début de chaque subdivision indexée ne comporte pas de répétitions.