Présentation

Cette boîte à outils a été conçu dans le cadre plurital, cours en commun entre les universités de Paris3, Paris10 et de l'INALCO.

Introduction

L'ojectif est de se créer des outils qui nous permettront de manipuler aisément une arborescence de fichiers assez homogène et de leur faire subir une série de traitement qui sont : du filtrage, de l'étiquetage et une recherche par patrons syntaxique de candidats-termes pour réaliser une terminologie. Enfin, nous présenterons les candits-termes trouvés sous-forme de graphe.

Dans le cadre de ce cours, mon but est de réaliser une terminologie à partir de corpus alignés anglais-japonais. Aussi ai-je pris en compte la possibilité de pouvoir changer d'analyseur facilement. J'utilise chasen comme analyseur morphologique du japonais et treetagger pour l'anglais. En français, nous utiliserons essentiellement treetagger et cordial. Ce dernier n'étant pas libre de droit, et non utilisable en ligne de commande, sera donc moins exploité. Nous pourrions également avoir recours à d'autres étiqueteurs comme Brill.

Pour la recherche de patron syntaxique, on commencera par dévopper des outils élémentaires, on pourrait ensuite utiliser des analyseurs flexionnels comme Flemm ou des analyseurs syntaxiques comme Unitex.

Les outils que nous allons créés seront écris en perl sous forme de modules. Le programme boatouti.pl permet de lancer toutes les opérations de la boîte à outils.

(voir le manuel) (voir l'algorithme)

Les résultats seront sous forme XML et nous aurons recours à des feuilles de style XSLT et CSS pour l'affichage.

Parcours de l'arborescence de fichiers

L'idée est de faire un moteur réutilisable, pour parcourir toutes l'arborescence d'un dossier, c'est à dire tous les fichiers qu'il contient directement ou contenu dans ces fichiers descendants.

Il faut que le contenu du dossier soit assez homogène(même type de fichier comme XML ou même famille de fichier comme une liste de formats d'images(gif, jpeg...) mais ce n'est pas notre propos). J'ai donc ajouter un filtre pour ne traiter que les fichiers vérifiants les extensions choisies.

On utilisera la fonction tttArborescence du module tttDossier.pm pour accomplir cette tâche. Elle prend en paramètre le dossier à traiter, la fonction à appliquer sur l'arborescence, et une liste d'extensions pour filtrer les fichiers à traiter en option.

Dans le cas présent, il sagit de fichiers XML. Cependant, en y regardant de plus près, on s'aperçoit qu'une bonne majorité des fichiers est encodés en iso-latin-1 et qu'un petit groupe est encodé en unicode utf-8.(voir la list des fichiers avec leur encodage)

On ne peut donc pas traiter brutalement tous les fichier d'une façon uniforme. Il faut prendre l'encodage de chaque fichier en considération pour ne pas avoir de problème d'affichage de charactèes en fin de chaine de traitement.

Nous nous occuperons donc de l'encodage pendant l'opération de filtrage.

Filtrage du contenu d'un fichier XML

Nous désirons filtrer ce qui est contenu entre certaines balises dans chaque fichier XML. Dans notre cas, nous traitons des fichiers qui sont des fils de presse dont la partie à extraire se trouve entre les balises description. On peut aussi prévoir les cas où l'on cherche d'autres tags ou bien les cas où l'information recherchée est disséminée dans des parties contenant des tags différents.

La fonction filtrageXML du module filtrage.pm permet de filtrer les balises dont les noms correpondent aux tags d'une liste donnée en argument.

La requète du contenu à filtrer peut s'avérer plus complexe que tout le contenu texte d'une balise. Dans ce cas un parser de type DOM ou SAX serait bien utile. J'utilise un parser DOM rudimentaire que j'ai écrit pour d'autres besoins pour chercher le contenu à filtrer. C'est lui qui se chargera d'ouvrir le fichier au bon format. Cependant le traitement sur un très gros corpus de plusieurs dizaines de mégas commencerait à être un peu long. Dans ce cas là, on utilisera un parser SAX.

boatouti -f description -x -i arbo-fils -o resuFiltrage.xml

Gestion des problèmes d'encodage

Avant de lancer un analyseur, il faut s'assurer que le contenu à analyser est correctement formaté pour l'analyseur. Dans les fichiers XML, on retrouve souvent des entités nommés que l'analyseur ne reconnaît pas. Il faut donc les retransformer en les charactères correpondants.

Nous avions vu plus haut, que le rique d'avoir des fichiers encodés différemment est grand, et que dans notre cas, nous sommes en présence d'ISO-8859 et d'utf-8. Dans la mesure où nous désirons concaténer le résultat du traitement de chaque fichier, nous sommes obligés de faire une conversion pour ne pas avoir d'encodage mixte dans le même fichier.Car cela se manifesterait par des erreurs d'affichage des charactères non ASCII issus des fichiers de l'encodage minoritaire dans le meilleur des cas.

Il faut donc opérer une conversion des données avant de les mélanger, et veiller en la concordance de l'encodage du fichier de sortie, de l'encodage des données que l'on manipule et de l'encoding que l'on spécifie dans l'en-tête XML.

Le plus simple est d'utiliser un encodage universel et robuste tel qu'UTF-8. Pour faire la conversion de l'iso-latin-1 vers l'utf-8, le parser regarde la première ligne d'en-tête XML, et l'ouvre dans le format spécifié. Il est donc correctement convertit dans le format propre à Perl est peut être recopié en utf-8 dans un autre fichier.

Il nous reste cetains soucis avec le résultat de l'étiquetage de treetagger en utf8. Il semblerait que se soit interne à treetagger. Cela ne concerne que les lemmes des verbes qui restent encodés en iso latin-1

Pour réoudre ce problème, on conserve l'usage du format iso-8859-1 pour les fichiers temporaires du module de treetagger.

La segmentation d'un texte

Segmenter un texte en token est très courant. En général on spécifie les charactères qui sont des séparateurs comme par exemple les charactères de ponctuation. Cependant, le français comme toute langue naturelle regorge d'ambiguïtés, et même les délimiteurs de mots ne dérogent pas à la règle.

Nous ne reviendrons pas sur les sempiternelles histoires à propos de la définition d'un mot. Cependant, il faut être averti que les choix que nous faisons à ce niveaux se répercuteront aux niveaux plus haut. Il est devenu comme une norme de prendre tous les charactères potentiellement délimiteurs comme toujours délimiteurs et donc de tronquer les mots composés à la romane comprenant des espaces comme pomme de terre ou ceux avec un tiret.

En effet, il est difficile de savoir sans dictionnaire (qui ne sont jamais complets) si l'on a affaire à un mot composé ou non. On peut néanmoins faire des prétraitements utiles.

Par exemple, l'apostrophe étant rarement ambigu, on peut éviter de décomposer la classe fermée des mots en comprenant un, comme par exemple aujourd'hui. Dans le cas de mots composés liés avec un autre délimiteurs, c'est au niveau supérieur, essentiellement au niveau morpho-syntaxique que l'on pourra faire des recompositions

Pour l'instant, nous nous borneront à la liste des charactères désignés comme séparateur usuelle(voir la fonction). Si l'envie nous prenait de faire une meilleure tokenisation, nous pourrions utiliser des tokenizers existant. Il existe notamment une version de treetagger libre de droit, en tout cas sur linux, qui comprend un tokenizer, et donc de faire d'une pierre deux coups.

L'étiquetage des catégories lexicales ou morphologiques des contenus

La qualité de l'étiquetage dépend de l'analyseur que nous allons choisir. Pour le français, dans le cadre de ce projet, nous en avons testé deux : treetagger et cordial.

Il en existe d'autres libres sur le français, comme le segmenteur Brill.

Le premier est libre de droit sous linux, j'ai donc choisi de travailler sur cette plateforme. De plus, il s'utilise en ligne de commande et est donc propice à l'écriture de script. Ce sont des avantages indéniables sur son concurrent.

Si nous étions pressé, nous aurions pu utiliser des outils déjà fait comme treetagger-simple-FR.sh. Ce script écrit par le ERSS, segemente un texte, l'analyse avec treetagger et peut même donner le résultat en XML comme nous le voulons. Bien sûr, ce projet est à but pédagogique donc nous éviterons de recourir à des programmes déjà tout fait.

L'étape en sortie consiste à formater les résultats des étiqueteurs en XML, pour les afficher sur internet ou de les uniformiser pour les traitements postérieurs. Il suffit de trouver les règles du formatage de sortie de l'étiqueteur, d'identifier les informations qui nous intéressent et de les recopier avec les balises correspondantes dans un fichier. Nous utiliserons des expressions rationnnelles pour cela.

Le module ttgFr.pm permet de faire l'analyse avec treetagger en français. On peut l'utiliser en ligne de commande :

boatouti -f description -a treetagger -x -i arbo-fils -o etikTreetagger.xml

Cordial, en tant qu'application commercial, est un produit fini, de bonne manufacture avec une interface conviviale. Mais il n'existe pas sous Linux et n'est pas utilisable en ligne de commande. Cette fois nous serons donc contraint d'utiliser windows.

Pour faire le même traitement sous cordial, nous devons regrouper les étapes en 3 parties :

• le parcours, le filtrage, et la résolution de l'encodage
• l'analyse
• le formatage

Le fait d'avoir fait des options indépendantes prend tout son sens.

boatouti -f description -i arbo-fils -o pourCodial.txt sortira un fichier à analyser avec cordial.

On analyse manuellement ce fichier avec cordial. Dans le volet de configuration, ll faut au moins cocher les cases ligne de titre en début de fichier, afficher l'introducteur et le termineur de phrase. La catégorie lemme aussi est obligatoire car c'est un champs de sortie. Toutes les autres options peuvent être utilisées mais ne seront pas prises en comptes dans le fichier xml en sortie. Cependant en modifiant la table de hachage %element du module cordial.pm on peut changer les options prises en compte.

boatouti -a cordial -i etik.cnr -o etikCordial.xml donnera le résultat attendu.

Le module cordial.pm sert à transformer la sortie cordial en xml.

La recherche par patrons syntaxiques

Le module termino.pl permet de faire la recherche de candidats-termes à partir d'un fichier de patrons. Il fait la recherche sur les fichiers étiquetés au format xml car uniformes. On segmente le texte en chunk avant d'essayer de matcher avec les patrons. C'est une précaution pour ne pas risquer de charger la mémoire au cas où l'on travaillerait sur des très gros corpus.

boatouti -c patrons.txt -i etik.xml -o listeCandidats est la commande a effectuée pour cette tâche

(voir le fichier des patrons) (voir la liste des candidats-termes)

Affichage des candidats en graphe

Nous allons faire l'affichage des candidats trouvés ci-dessus sous forme de graphe avec pajek. Ce graphe permettra de visualiser les liens entre les candidats qui sont composés des mêmes mots.

Pajek est une application windows, mais on peut l'utiliser sous linux avec l'émulateur wine.

Le module candidat2graf.pm contient toutes les fonctions pour ce traitement. Cependant je n'ai pas pris en compte windows. Le moteur XSLT en ligne de commande que j'utilise n'est pas sous windows. Il faudrait en utiliser un autre sous cet OS.

Affichage des résultats en xml

Pour effectuer l'affichage des résultats, nous recourons à des feuilles de style xsl et css que vous pouvez consulter via le menu.