1.2 Procédure de Traitement de l’Information

Cette procédure a comme tâche l’extraction des SN et leur organisation dans une structure de façon à faciliter et rendre plus rapide la recherche d’information.

Le choix des syntagmes nominaux comme moyen d’accès à l’information oblige que la Procédure de Traitement de l’Information contienne un analyseur morpho-syntaxique. C’est la manière la plus indiquée pour la reconnaissance des syntagmes nominaux car il faut reconnaître les unités lexicales qui leur appartiennent. Chaque unité lexicale a ses caractéristiques spécifiques et peut se combiner avec d’autres unités de manière à constituer un syntagme nominal. Le modèle que nous allons montrer dans les chapitres 10 et 11 est la base de cet analyseur.

Dans la figure 8.2 nous montrons la composition de la Procédure de Traitement d’Information (PTI). Cette procédure est composée, donc, par deux grands modules : 1) Module de Reconnaissance et d’Extraction de SN ; et 2) Module d’Indexation des SN.

Le Module de Reconnaissance et d’Extraction de SN est la procédure responsable par la lecture des documents, par la segmentation des textes, par la normalisation de textes et finalement par l’analyse morpho-syntaxique. Ce module utilise des informations de la base de données LEXIQUE pour la reconnaissance des unités lexicales. La flèche a été mise dans les deux sens parce que ce module peut non seulement prendre les informations des unités lexicales dans la base, mais elle peut aussi faire la mise à jour de nouvelles unités lexicales qui ne se trouvent pas encore dans la base. En ce cas, il faut les ajouter à la base, en ajoutant aussi leurs informations (variables / règles de contraints). La normalisation de texte correspond au pré-traitement des unités lexicales. En effet, autant le pré-traitement des unités lexicales que la base de données LEXIQUE seront discutés, de manière plus détaillée, dans le prochain chapitre, lors de la présentation du modèle.

La partie plus importante de ce module est l’analyseur morpho-syntaxique lequel sera le responsable effectivement pour la reconnaissance et l’extraction des SN d’un document. Pourtant, nous n’allons pas le détailler dans le cours de cette thèse. La prise de cette décision est justifiée à cause de l’avance de la technologie de l’information et de la communication. Le scénario technologique change très vite et le champ du traitement automatique de langue naturelle suit ce développement. On risque, donc, de se tromper ou de proposer une solution inadéquate à la technologie du moment du développement du SRI. Pourtant, il faut faire quelques considérations pour donner des repères à celui qui va développer ce système. Ces repères peuvent aussi être importants dans le processus de choix de la technologie qui sera utilisée dans le développement du SRI.

A suivre nous présentons ces considérations :

• Utiliser une base de données contenant les unités lexicales et leurs informations (base de données LEXIQUE). La décision d’utilisation de cette approche est justifiée dans le prochain chapitre ;
• Le module de reconnaissance et d’extraction de SN doit être capable de reconnaître d’abord le SN maximal. C’est-à-dire, le SN plus grand, ce qui ne peut pas appartenir à d’autres SN. A partir de ce SN, l’analyseur doit être capable aussi de reconnaître tous les autres SN qui y sont présents ;
• Le module de reconnaissance et d’extraction doit être capable de reconnaître les SN avec double rection et les SN qui font partie de chaque complément.
• Après la reconnaissance du SN maximal et la reconnaissance de tous les SN qui y sont présents, ce module doit les passer dans la même suite que dans le texte, avec une signalisation indiquant le début et la fin de chaque SN. On peut utiliser les parenthèses pour faire cette signalisation. Ainsi, le module d’indexation sera capable de prendre chaque syntagme nominal et aussi bien de déterminer son niveau respectif.

La module d’indexation automatique est la partie responsable pour créer, mettre à jour et organiser les syntagmes nominaux dans une structure qui puisse permettre aux usagers de trouver l’information désirée. Cette structure sera composée par les fichiers INDICES. C’est-à-dire, la structure de données qui soutiendra les syntagmes nominaux est composée non seulement par un fichier, mais par un ensemble de fichiers.

Ce module est activé par le module de reconnaissance et d’extraction de SN par le biais du passage d’une chaîne de caractères ayant la séquence de textes contenant le(s) syntagme(s) nominal(aux). Selon une des considérations qu’on a faites plus haut, cette séquence de textes a le format suivant :

(x)

Où x est un syntagme nominal et peut être composé par la forme suivante :

x = y (x₁) | y (x₁) y (x₂)

Où y est un ensemble de mots, x₁ et x₂ sont des syntagmes nominaux. Le symbole « | » indique une forme alternative. C’est-à-dire, un syntagme nominal « x » peut être composé soit par un autre syntagme nominal « x₁ » ou soit par deux autres syntagmes nominaux disposé séquentiellement comme dans un syntagme nominal avec double rection. Ce sont des formes récursives. C’est-à-dire, les syntagmes nominaux peuvent aussi être composés par des syntagmes nominaux emboîtés. Ensuite nos présentons quelques exemples pour une meilleure visualisation de cette proposition :

1. (L’analyse d’information)
2. (l’étude de (l’analyse d’information))
3. (l’acceptation de (l’information stratégique) dans (la définition de (l’avenir de (l’entreprise))))

Dans l’exemple 2 on voit un exemple de syntagmes nominaux emboîtés, c’est-à-dire un syntagme nominal dans un autre syntagme nominal. Et, dans l’exemple 3 on voit le cas de syntagme nominal avec une double rection.

Un autre aspect à prendre en compte est la détermination du niveau de chaque syntagme nominal. Nous avons déjà établi cela dans la maquette construite dans le cours de cette thèse. L’énumération de chaque syntagme nominal est attribuée en ordre décroissant du syntagme maximal aux syntagmes plus petits qui sont dans ce syntagme maximal. Nous allons suivre, donc, la même approche adoptée dans la maquette. Pour exemplifier, nous allons prendre l’exemple 3, étant donné son aspect particulier d’avoir une double rection.

Etant donné que ce syntagme contient une double rection, il faut repérer le niveau du syntagme nominal maximal par rapport au syntagme nominal plus petit de chaque rection. C’est-à-dire, selon ce qui nous avons déjà défini dans la maquette, nous proposons que le syntagme nominal, en ce cas, appartienne à deux niveaux distincts à cause de ses rections. Ainsi, nous avons le calcul suivant :

(l’acceptation de (l’information stratégique) dans (la définition de (l’avenir de (l’entreprise))))

Ce syntagme nominal est composé de deux branches de syntagmes :

Ainsi, le syntagme plus grand :

« (l’acceptation de (l’information stratégique) dans (la définition de (l’avenir de (l’entreprise))) »

Il doit être définit comme étant un syntagme de deuxième niveau par rapport au syntagme « (l’information stratégique) » et de quatrième niveau par rapport au syntagme « (la définition de (l’avenir de (l’entreprise))) ».

La procédure d’indexation doit, donc, en utilisant les marques qui délimitent les syntagmes nominaux présents dans la chaîne repassée par le module de reconnaissance et d’extraction de SN, déterminer le niveau de chaque syntagme nominal extrait.

L’extraction de chaque SN et la détermination du niveau de chaque SN n’est pas trop difficile. Il suffit d’extraire chaque SN interne, en vérifiant l’ouverture et la correspondante fermeture de parenthèses. Chaque ensemble d'ouverture et fermeture de parenthèses détermine la présence d’un SN. On sait d’abord que la chaîne de caractères repassée par le module de reconnaissance et d’extraction de SN est déjà un SN maximal, c’est le plus grand.

L’extraction de chaque SN et la détermination du niveau de chaque SN doit être faite en même temps. Au fur et à mesure qu’on extrait chaque SN, on les met dans une pile, aussi appelée dans la discipline de structure de données LIFO (Last In First Out), c’est-à-dire, dernier-entré-premier-sorti. Selon Christine FROIDEVAUX et al., ‘ « une bonne image pour se représenter une pile est une... pile d’assiettes : c’est en haut de la pile qu’il faut prendre ou mettre une assiette ! » ’ ⁹⁶ . Ainsi, dans notre cas, l’assiette est représentée par le syntagme nominal.

Dans le cas de SN avec double rection il faut créer le nombre de piles égal au nombre de rections. Dans notre exemple, nous aurons deux piles parce que nous avons deux compléments, comme nous pouvons dans la figure 8.3.

Le schéma de la figure 8.3 montre une structure intermédiaire qui doit être utilisée lors de l’extraction de chaque SN et la détermination de leur niveau. Le même schéma montre aussi que le niveau est donné de manière croissante du SN plus petit ou le plus interne au SN le plus grand, soit le SN maximal. Ce même schéma montre aussi que dans un SN avec double rection, il y aura deux piles car dans ce SN il y a deux rections. Cela nous montre que, en ce cas, le SN maximal est déterminé comme un SN de deuxième niveau par rapport au SN plus petit, « l’information stratégique ». Et, le même SN maximal est du quatrième niveau par rapport au SN plus petit, de la deuxième rection, « l’entreprise ». Cela montre que, dans la structure de données qui va stocker les indices, le SN maximal, en cas de double rection, doit apparaître autant de fois que le nombre de rections. Là, il doit apparaître autant dans la structure de rapport entre les SN de deuxième niveau que dans celle de quatrième niveau.

Les algorithmes pour créer, empiler et dépiler une pile sont déjà bien connus dans le milieu informatique, et ils sont aussi très simples à implémenter. Nous n’allons pas les expliciter ici. On peut les trouver dans l’ouvrage de Christine FROIDAUX et al., « Types de Données et Algorithmes », aux pages 74-76.

Le prochain pas est la construction des structures de données pour stocker les syntagmes nominaux, ceux qui vont supporter la navigation pour la recherche d’information. Tout d’abord, nous avons confirmé la faisabilité de développer un Système de Recherche d’Information assistée par Ordinateur basé sur un logiciel de gestion de bases de données relationnelles. Les tableaux avec les rapports entre les plusieurs niveaux de syntagmes nominaux ont été montrés dans le chapitre 4 - Développement de la maquette, de cette thèse.

La maquette a été développée en utilisant le logiciel Access de la Microsoft. Ce logiciel a dans son corps des routines de mise à jour des tables et des fichiers. Il n’y a pas de problèmes de mise à jour. Pourtant, ce logiciel est trop limité pour faire un système professionnel de recherche d’information. Il vaut mieux construire un système en utilisant des langages de haut niveau comme le C++ ou Java. Pour cela il faut construire toutes les structures de données à l’aide d’une méthode d’accès comme l’ISAM (Indexed Sequential Access Methode) ou l’arbre binaire ou d’autres méthodes performantes existantes dans le marché. Cette méthode permettra de faire l’accès à l’information directement, sans faire une lecture séquentielle à chaque syntagme nominal. Normalement on trouve ces méthodes dans les logiciels de gestion de fichiers. Nous n’allons pas faire du souci au problème d’accès en disque à l’information parce que nous pouvons trouver dans le marché de bons logiciels de gestion de fichiers. Ce sont des outils de développement. Ils sont déjà bien connus. Par contre, il faut dessiner les structures de données, comment on fait les liaisons entre chaque structure, et comment se fait le rapport entre les SN d’un niveau donné avec d’autres SN d’un niveau plus haut. C’est dans ce cadre là qu’on doit travailler maintenant.

Une fois connus les syntagmes nominaux et leur niveau, il faut déterminer le centre du syntagme nominal de premier niveau. La détermination du centre de syntagme nominal de premier niveau est importante en ce moment là parce que la recherche d’information, dans le modèle proposé, commence par ce centre. Les indications de comment déterminer ce centre seront données dans le chapitre 10, dans la section 3.3.7. Dans cette section, nous discutons le problème de détermination du centre de syntagme nominal du premier niveau lorsque avons un syntagme composé par une expansion prépositionnelle.

L’ensemble de structures de données nécessaires pour stocker et organiser les syntagmes nominaux a comme base trois fichiers principaux (voir la figure 8.4), définis comme étant :

• SYNTAGMES - Ce fichier contient tous les syntagmes nominaux extraits des documents qui appartiennent à la base de données. Il contient les champs suivants : le code d’identification de syntagme nominal (CISN), le syntagme nominal. La clé primaire est le syntagme nominal (SYNO) ;
• CENTRES - Ce fichier contient les centres de syntagme nominal de premier niveau. Ce fichier contient les champs suivants : le code d’identification de centre de syntagme nominal de premier niveau (CISP), le centre de syntagme nominal de premier niveau (CSPN). La clé primaire est le champ CISP ;
• MOTS - Ce fichier contient les mots équivalents ou synonymes des centres de syntagme nominal de premier niveau. Il contient les champs suivants : le mot, le CISP. La clé primaire est le mot.

Les autres structures de données sont générées pour soutenir la recherche d’information. Ils sont donc créés à partir des données stockées dans les fichiers SYNTAGMES et CENTRES et aussi à partir des données présentes dans les piles. Les piles donnent des informations sur le rapport entre les syntagmes nominaux présents dans chaque pile.

La recherche commence par le centre de syntagme nominal fourni. En effet, l’usager peut fournir un mot qui ne se trouve pas parmi les centres de syntagme nominal, mais peut être équivalent ou synonyme. C’est pour cela que nous avons défini un fichier appelé MOTS. Ce fichier comme nous avons déjà dit contient des mots qui sont équivalents ou synonymes d’un centre de syntagme nominal. C’est pour cela que la recherche, en effet commence par trouver le CISP (code d’identification d’un centre de syntagme nominal) en faisant accès au mot dans le fichier MOTS.

A partir de ce CISP, le système doit faire un accès à une structure qui fait le rapport entre les centres de syntagme nominal de premier niveau et les SN de premier niveau. C’est pour cela qu’il faut avoir un fichier ayant le CISP et le CISN comme clé primaire. Ainsi, nous avons dessiné le fichier appelé CES_SN1 - Rapport entre les centres de syntagme nominal et les syntagmes nominaux de premier niveau. Ce fichier contient les champs suivants : CISP - code d’identification de centre de syntagme nominal de premier niveau, CISN - code d’identification de syntagme nominal, CEDO - code de l’ensemble de documents d’où on a extrait un syntagme nominal donné.

Dans la figure 8.5 nous montrons la spécification des fichiers CES_SN1 et SN1_SN2. Le fichier SN1_SN2 contient le rapport entre les syntagmes nominaux de premier niveau avec les syntagmes nominaux du deuxième niveau. Ce fichier permettra au système de retrouver, à partir d’un SN de premier donné, les SN de deuxième niveau. Les deux fichiers sont pareils ainsi que les autres fichiers de rapport entre les syntagmes nominaux.

Dans les figures 8.6, nous montrons respectivement le fichier avec le rapport entre les SN de deuxième niveau et ceux de troisième niveau et le fichier avec le rapport entre les SN de troisième niveau et ceux de quatrième niveau. De même, dans la figure 8.7 nous montrons le fichier qui contient le rapport entre les SN de quatrième niveau et ceux de cinquième niveau. Et, finalement, nous montrons aussi le fichier qui contient le rapport entre les SN de cinquième niveau et ceux de sixième niveau. Comme nous pouvons constater, les spécifications sont pareilles, il n’y a aucune différence, sauf les niveaux des SN, mais les codes sont toujours les mêmes, ceux qui identifient les syntagmes nominaux.

De la même façon que le fichier SN1_SN2 permet au système retrouver tous les SN de deuxième niveau, à partir d’un SN de premier niveau donné, le fichier SN2_SN3 permet au système de retrouver tous les SN de troisième niveau, à partir d’un SN de deuxième niveau donné. Cette idée est valide pour tous les fichiers de rapport entre les SN d’un niveau donné et les SN de niveau supérieur consécutif.

Dans tous les fichiers la mise à jour est faite à la fin du fichier. C’est-à-dire, les inclusions de nouveaux codes d’identification de syntagmes nominaux sont faites à la fin.

Le code d’identification de centre de syntagme nominal de premier niveau (CISP) et le code d’identification de syntagme nominal (CISN) sont de numéros séquentiels. Ainsi, les inclusions de nouveaux syntagmes nominaux et de nouveaux centres de syntagmes nominaux de premier niveau sont aussi faites à la fin de leur fichier respectif.

De plus, il faut avoir un fichier où seront stockés les numéros de chaque document d’où les syntagmes nominaux ont été extraits, appelé ENS_DOC. Ce fichier permettra au système de retrouver les documents à partir d’un SN donné. C’est à dire, à partir d’un SN le système pourra rencontrer les documents d’où ce SN a été extrait. Ce fichier contient les champs suivants : CEDO - le code d’identification d’ensemble de documents, NDOC - le nombre de documents d’où on a extrait un SN donné, CIDO - code d’identification de document. Le champ CIDO est répété autant de fois que le nombre de documents d’où on a extrait un SN donné. La figure 8.8 montre la spécification de ce fichier.

Le code CEDO est un code séquentiel et il est aussi la clé primaire de ce fichier. La mise à jour se fait toujours à la fin du fichier, et l’inclusion d’un nouveau document pour un syntagme nominal donné est faite toujours à la fin de chaque registre.

Il est claire qu’on ne pourra pas inclure indéfiniment des nouveaux CIDO dans un registre du fichier ENS_DOC. C’est pour cela que nous avons prévu une insertion de « n » CIDO par registre. C’est-à-dire, on peut enregistrer, au maximum, « n » documents contenant un SN donné, dans chaque registre. La valeur de « n » dépend de la taille du registre de ce fichier. Nous ne pouvons pas établi maintenant la valeur pour cette taille. C’est un détail de projet de fichier et dépend des caractéristiques du gestionnaire de fichiers choisi. Si on trouve plus de n documents contenant un SN donné, il faut remplir le champ CICO pour indiquer la continuation de ce registre dans le fichier ENS_DOC_BIS. Le CICO, code d’identification de continuation d’enregistrement de CIDO, est un code séquentiel et aussi la clé primaire de ce fichier.

Le fichier ENS_DOC_BIS a comme but stocker les CIDO qui ne pourraient pas être enregistrés dans le fichier ENS_DOC. La spécification de ce fichier est montrée dans la figure 8.9.

Le fichier ENS_DOC_BIS est composé de registres contenant les champs : CICO - code d’identification de continuation d’enregistrement de CIDO, CIDO et d’un champ de liaison pour la continuation éventuelle d’enregistrement de CIDO, dans un nouveau registre dans le même fichier. Le code CIDO peut être répété « m » fois dont la valeur dépend de la taille du registre. Si la quantité de CIDO à être enregistrée est plus grand que « m », le système doit alors créer un autre registre dans le même fichier pour continuer d’enregistrer les CIDO, comme on a montré dans la figure 8.9. Le champ CICO_K — ce qui fait la liaison à d’autres registres, ce qui se trouve à la fin du registre — du dernier registre de cette séquence de CIDO a comme valeur zéro (0). Cette valeur signale qu’il ne fait aucune liaison à d’autres registres. Elle indique aussi que ce registre est le dernier pour un de l’ensemble de documents d’où on a extrait un SN donné. La création de ce fichier résout les possibles contraintes dues à la quantité de documents qui puissent avoir un SN donné.

Nous allons présenter maintenant une autre structure de données laquelle a une fonction auxiliaire. Elle n’est pas liée directement à la recherche d’information, mais elle est très important pour aider les usagers à visualiser un SN donné dans les documents trouvés. C’est-à-dire, il est intéressant aux usagers de voir, dans les documents trouvés à partir d’une recherche d’information, les endroits d’où a été extrait le SN qu’il a utilisé pour retrouver ce document. Ces informations peuvent être utiles à l’usager pour savoir le(s) endroit(s), dans un document retrouvé dans une recherche, où se concentre le SN utilisé dans la recherche. Une autre application de ces informations est dans les champs de la recherche d’information. Les parties où se concentra un SN donné peut être utiles pour l’établissement de l’unité d’un document. C’est-à-dire, l’usage de ces informations peut nous amener à prendre en compte comme un registre d’information, non le document total (livre, article etc.), mais partie(s) de ce document dont l’occurrence d’un SN donné est plus concentrée. Une autre application d’utilisation de ces informations est la détermination d’ordre de pertinence d’un document par rapport au pourcentage d’occurrence d’un SN donné. C’est une chose pareille à ce que les modèles traditionnels d’indexation font pour les mots. Le calcul d’ordre de pertinence en utilisant l’occurrence de mots dans un document.

Ainsi, nous proposons que le module de reconnaissance et d’extraction de SN fasse le repérage du numéro de la ligne, du document, d’où un SN donné a été extrait et le repasse au module d’indexation. Ce module à son tour l’enregistre dans le fichier POS_SN. Ce fichier aura comme clé primaire le code CISN - code d’identification de Syntagme nominal. De plus, ce fichier ne gardera que des numéros de lignes (NL) d’où le respectif SN a été extrait. Etant qu’il aura des SN qui auront beaucoup d’occurrence dans un document, il est nécessaire la création d’un fichier de continuation d’enregistrement de ces adresses (numéros de ligne d’où le SN a été extrait), NL. La structure de donnée nécessaire pour supporter ces informations est pareille à celle présenté dans les figures 8.8 et 8.9.

Pour une question de clarté nous montrons dans les figures 8.10 et 8.11 les fichiers qui font partie de la structure de données dessinées pour gardes les adresses des SN de la base de données. Dans ces fichiers, CINL indique la liaison d’un registre au registre de continuation d’enregistrement de numéros de lignes. CINL est aussi la clé primaire du fichier POS_SN_BIS.

FIG08-11.gif

En ce moment, nous n’allons pas faire du souci aux problèmes de tailles des divers codes et ni des divers registres de chaque fichier. Ce problème doit être réglé lors de l’implémentation car il faut connaître le système opérationnel, même le gestionnaire de fichiers et bien aussi la plate-forme de hardware pour laquelle sera développé ce nouveau SRI. Ce n’est pas le moment, donc, de calculer les paramètres relatifs aux tailles des fichiers et aussi de champs.

Il manque, maintenant le fichier qui contient les textes des documents dans la base de données. Ce fichier est composé par les champs : CIDO - code d’identification de document, le texte du document. Ici, nous pouvons avoir aussi, au lieu du texte du document, une référence du fichier qui le contient. Mais cela dépend du système de gestion de fichier, c’est-à-dire des limitations du gestionnaire car il est fort probable que la taille des textes de documents sera trop grand. De toute façon, il me semble que la solution de mettre une référence à un fichier qui contient le document est une solution plus générique et indépendante du système de gestion de fichiers.