Boîte à outil 1 : constitution et mise en forme du corpus

Objectif

La première étape de ce projet vise à mettre en forme un corpus de textes à partir duquel on pourra par la suite extraire et analyser des patrons syntaxiques. Les documents sources sur lesquels nous travaillions sont issus des fils RSS du journal le Monde. À partir de ces fichiers en entrée, on souhaite obtenir après extraction, filtrage et nettoyage d'une partie de leur contenu textuel des fichiers au format texte ou XML.

Le format de données RSS

Les flux RSS ("Really Simple Syndication") sont constitués de documents XML généralement utilisés par les sites d'actualité ou les blogs pour présenter les titres des dernières informations consultables en ligne. Voici un exemple simple de document XML de type RSS présentant deux actualités publiées par Le Monde :

<?xml version="1.0" encoding="iso-8859-1"?>
<rss xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" version="2.0">
<channel>
<title>Le Monde.fr : A la une</title>
<link>http://www.lemonde.fr</link>
<description>Toute l'actualité au moment de la connexion</description>
<copyright>Copyright Le Monde.fr</copyright>
<pubDate>Tue, 01 Jan 2008 17:58:07 GMT</pubDate>
<item>
<title>Un document révèle l'étendue des fraudes électorales au Kenya</title>
<link>http://www.lemonde.fr/web/article/0,1-0@2-3212,36-994926,0.html?xtor=RSS-3208</link>
<description>Un document confidentiel, que s'est procuré "Le Monde", trace les contours du désastre entraîné par le scrutin du 27 décembre, qui vient de plonger le Kenya dans une vague de violences.</description>
<pubDate>Tue, 01 Jan 2008 15:06:05 GMT</pubDate>
</item>
<item>
<title>Mitt Romney et Mike Huckabee, les deux visages du Parti républicain</title>
<link>http://www.lemonde.fr/web/article/0,1-0@2-3222,36-994961,0.html?xtor=RSS-3208</link>
<description>La guerre pour l'investiture républicaine dans l'Iowa, dont le caucus du 3 janvier est capital, fait rage entre les deux hommes. M. Huckabee, qui a effectué une percée inattendue, est en tête selon les derniers sondages.</description>
<pubDate>Tue, 01 Jan 2008 15:15:19 GMT</pubDate>
</item>
</channel>
</rss>

Extraction du contenu textuel des fils RSS

À partir d'un document XML de ce type, on souhaite pour chaque <item> extraire le contenu des balises <title> et <description>. Pour cela, nous avons prévu deux méthodes :

avec un script Perl simple
avec un module Perl spécifique

Méthode 1 : extraction par expressions régulières

La première méthode consiste à tirer au maximum profit des commandes de base de langage de programmation Perl. Après avoir supprimé tous les éventuels retours à la ligne, on peut procéder à l'extraction du contenu textuel voulu à l'aide d'expressions régulières. Voici un script simple permettant d'effectuer cette tâche sur le fichier XML donné en exemple précédemment : extraction1.pl (Note: Afin que le contenu de certains documents comme les scripts soient consultable depuis le navigateur nous les avons convertis au format TXT)

Voici le résultat produit par ce script dans notre terminal :

Méthode 2 : utilisation du module XML::RSS

Un module Perl est un ensemble de fonctions regroupées dans un fichier qui peut permettre de faciliter l'écriture d'un script en faisant appelle à ces fonctions de manière très simple sans avoir à les écrire soi-même. Parmi les nombreux modules disponibles, il existe un module spécifique au traitement des fichiers XML de type RSS. Il s'agit du module XML::RSS dont les caractéristiques sont présentées sur le site du CPAN.

En utilisant les fonctions de ce module, il est possible de parser un document XML de type RSS pour obtenir une table de hachage contenant des référence vers d'autres tables de hachage dont la structure devient plus ou moins équivalente à celle d'un arbre XML. Voici un document représentant la strucutre obtenue après parsage de l'extrait du fil RSS précédent par le module XML::RSS : tablehachageRSS.txt (Note: Cet affichage a été obtenu depuis le terminal grâce à la fonction Dumper($rss) du module Data::Dumper)

Une fois une telle structure obtenue, il est alors possible d'accéder à la valeur initiale d'une balise en tirant profit de la syntaxe du langage Perl :
$rss->{racine}->{sous-racine}.

Voici un script basique faisant usage du module XML::RSS pour obtenir à partir du fichier extraitRSS.xml, le même résultat d'extraction que le script précédent : extraction2.pl

Filtrage des données extraites

Dans les flux RSS du site le Monde, l'actualité est présentée par rubrique (À la Une, Cinéma, Culture, Europe...). On veut pouvoir extraire le contenu textuel des balises <title> et <description> dans un document qui regroupe l'ensemble des rubriques, mais aussi dans des documents spécifiques à chaque rubrique. De plus, il est possible qu'un même article soit publié dans deux rubriques différentes (ex: À la Une + Europe) ou plusieurs fois dans la même rubrique. En plus d'un filtrage en fonction des rubriques, il est donc également nécessaire d'effectuer après l'extraction du contenu textuel un filtrage de ces données afin d'éviter qu'un même article soit présent plusieurs fois dans notre corpus de textes.

Filtrage des données par rubrique

Chaque document XML correspond à l'actualité d'une rubrique. Le titre de cette rubrique est indiqué dans la première balise <title> sous l'arborescence <channel>. Pour ce premier filtrage, nous avons prévu d'extraire au moment de la lecture d'un document XML le nom de la rubrique et de créer un fichier de sortie à son nom. Afin de s'assurer qu'on ne crée pas plusieurs fois un fichier pour une même rubrique, on passe par l'utilisation d'une table de hachage contenant le nom des rubriques déjà extraites. Si le nom d'une rubrique n'est pas présente dans cette table de hachage alors on crée un nouveau fichier de sortie à son nom. On pourra ensuite écrire dans ce fichier le contenu textuel extrait des articles classés dans cet rubrique.

En Perl, pour ouvrir un fichier ainsi que pour écrire dedans et le fermer, il est nécessaire de fournir les informations suivantes :

le nom du fichier
le chemin d'accès au fichier
un identifiant dans le script
d'autres informations : mode d'écriture, l'encodage...

La commande suivante permet ainsi d'ouvrir en mode écriture par concaténation, un fichier nommé sport.txt dans le dossier rubriques du répertoire courant, d'écrire dedans "Vive le sport !" et de fermer ce fichier :

if (!open (OUTPUT,"./rubriques/sports.txt")) { die "Pb a l'ouverture du fichier $rubriquetxt1"};
print "Vive le sport !";
close($FILEOUTRUBTXT);

Dans ce protocole, l'identifiant (ex: OUTPUT) est indispensable. Dans la méthode que nous avons mise en oeuvre pour filtrer les données par rubrique, la difficulté se situe justement au niveau du nom des identifiants pour chacun des fichiers créés. Il fallu trouver un moyen de sélectionner le bon identifiant à n'importe quel moment du script. Pour cela, nous avons choisi une convention simple dans laquelle l'identifiant d'un fichier rubrique est constitué du format de ce fichier (TXT ou XML) suivi du mot OUTPUT puis du nom de la rubrique (qui pour chaque nouveau fichier exploré est extrait dans la variable $rubrique). À n'importe quel moment du script, il devient alors possible d'obtenir l'identifiant du fichier dans lequel on souhaite écrire en passant par une variable recomposant cet identifiant. Cette méthode est illustrée dans le fichier suivant, où on expose la manière dont nous avons traité la création, l'édition et la fermeture des fichiers textes par rubrique.

Filtrage des articles publiés plusieurs fois

Lorsqu'un même article est publiés plusieurs fois dans des rubriques différentes ou dans une même rubrique, il faut trouver un moyen de filtrer cette information afin de ne pas avoir dans notre corpus des textes redondants. Pour cela, nous sommes une fois de plus passer par l'utilisation de tables de hachage. Une fois extrait dans des variables scalaires le contenu textuel des balises <title> et <description>, nous avons concaténé ces valeurs dans une même variable pour l'ajouter, si elle n'est pas déjà présente, dans une table de hachage que nous avons nommée %dicoDesAjoutsGlobal. Il est alors possible d'effectuer un test sur le contenu de cette table de hachage avant d'écrire dans le fichier de sortie global le contenu extrait d'un article. Si la table de hachage contient un élément composé du titre de cet article suivi de son résumé alors on ne le prend pas en compte dans l'écriture du fichier de sortie. Nous avons procédé de la même manière pour filtrer les articles redondant au sein d'une même rubrique en concaténant le nom de la rubrique au contenu du titre et du résumé de l'article avant de l'ajouter dans une table de hachage qu'on a nommée %dicoDesAjoutsRubriques. Voici un document présentant ces deux méthodes : filtrage des doublons

Nettoyage des données extraites

Le contenu textuel des fils RSS publiés par Le Monde est parfois composé d'entités HTML ou d'autres symboles qu'il est nécessaire de remplacer avant d'enregistrer ces données dans des fichiers de sortie. Pour cela nous avons écrit une simple fonction de nettoyage à base de substitution par expressions régulières des symboles à nettoyer (format UTF-8). Voici une liste des principales entités HTML : HTML Entities

Parcours de l'arborescence des fichiers XML

L'ensemble des documents XML sur lesquels doit porter l'extraction de données textuel est organisé selon l'arborescence de dossiers suivante :

2012

19-46-00

0,2-3208,1-0,0.txt
0,2-3208,1-0,0.xml
0,2-3210,1-0,0.txt
0,2-3210,1-0,0.xml
...

Un dossier 2012 contient un dossier par mois. Dans ces dossiers, on trouve un dossier par jour contenant un dossier dont le nom correspond à l'heure à laquelle les fichiers qu'il contient ont été enregistrés. On a alors un fichier XML et un fichier texte par rubrique.

Pour parcourir l'ensemble des dossiers et des fichiers XML qu'on doit prendre en compte dans notre chaîne de traitement semi-automatique, on a récupéré la fonction suivante : parcoursarborescance

Test sur un échantillon représentatif de flux RSS

Les archives de 2012 contiennent un nombre trop important de données pour pouvoir tester notre chaîne de traitement de manière efficace. Pour cela, nous avons d'abord testé nos scripts sur un extrait des archives de 2008. Une comparaison manuelle entre le contenu des fichiers sources et les résultats présents dans nos fichiers de sorties nous a permi de s'assurer du bon fonctionnement de nos scripts. Pour faire cette comparaison, nous avons systématiquement extrait en plus du titre des articles et de leur résumé, leur date de publication ainsi que leur rubrique d'origine. Pour contrôler le filtrage des doublons, nous avons aussi mentionné dans nos fichiers de sortie les cas où le contenu d'un article apparaît plusieurs fois.

Une archive contenant les scripts ainsi que les résultats de ces tests est téléchargeable ici.

Problèmes rencontrés

Nous avons rencontré quelques problèmes au cours de la mise en place de cette première boîte à outil. La principale difficulté que nous avons eu concerne l'encodage des fichiers. On verra aussi plus loin que des erreurs qui ne s'étaient pas produites sur l'échantillon des archives de 2008 ont eu lieu pour le traitement de l'archive de 2012.

Problème d'encodage

On a constaté de nombreux problèmes d'encodage dans nos fichiers de sortie, l'objectif étant d'obtenir des données au format UTF-8 quel que soit l'encodage des fichiers en entrée. Dans notre chaîne de traitement la prise en compte de l'encodage des données textuels peut avoir lieu à plusieurs niveaux :

Au niveau du terminal dans l'encodage par défaut
Au niveau de l'ouverture des fichiers depuis le script
Au niveau de l'édition d'un fichier
Au niveau de l'encodage du script (en particulier lorsqu'on fait appelle à la fonction print)
Au niveau des modules Perl utilisés

Pour ce travail, nous avons réglé l'encodage de notre terminal en UTF-8. Les scripts sont également encodés en UTF-8 et contiennent des caractères non ASCII. Les deux seuls modules que nous avons utilisés sont XML::RSS et Unicode::String. En Perl, il est possible d'indiquer l'encodage d'un fichier au moment de son ouverture ainsi qu'on moment de son édition. Comme nous ne parvenions pas à comprendre comment tous ces paramètres influaient sur l'encodage de nos fichiers de sortie, nous avons mis au point un série de tests.

À partir de trois fichiers XML encodés respectivement en ISO-8859-1, en MacRoman et en UTF-8, nous avons préparé un script d'extraction de base qui fait varier tour à tour les paramètres suivants :

indication ou non de l'encodage à l'ouverture du fichier d'entrée (A vs A')
conversion ou non des données extraites si elles ne sont pas en UTF-8 à l'aide du module Unicode::String (B vs B')
indication ou non de l'encodage à l'édition du fichier de sortie (C vs C')

Nous avons volontairement ajouté dans ces scripts une fonction print contenant un caractère non ASCII (il s'agit du e accentué). Pour chacun des trois fichiers en entrée, on obtient huit fichiers tests en sortie dont on peut comparer l'encodage :

Configuration 1 : A B C
Configuration 2 : A B' C
Configuration 3 : A B C'
Configuration 4 : A B' C'
Configuration 5 : A' B C
Configuration 6 : A' B' C
Configuration 7 : A' B C'
Configuration 8 : A' B' C'

Voici les résultats obtenus :

Configurations	ISO-8859-1	MacRoman	UTF-8
Configuration 1	texte: surencodage UTF-8 script: surencodage UTF-8	texte: surencodage UTF-8 script: surencodage UTF-8	texte: surencodage UTF-8 script: surencodage UTF-8
Configuration 2	texte: UTF-8 script: surencodage UTF-8	texte: UTF-8 script: surencodage UTF-8	texte: UTF-8 script: surencodage UTF-8
Configuration 3	texte: UTF-8 script: UTF-8	texte: UTF-8 script: UTF-8	texte: ISO-8859-1 script: UTF-8
Configuration 4	texte: ISO-8859-1 script: UTF-8	texte: ISO-8859-1 script: UTF-8	texte: ISO-8859-1 script: UTF-8
Configuration 5	texte: ASCII script: surencodage UTF-8	texte: ASCII script: surencodage UTF-8	texte: surencodage UTF-8 script: surencodage UTF-8
Configuration 6	texte: UTF-8 script: surencodage UTF-8	texte: ASCII script: surencodage UTF-8	texte: surencodage UTF-8 script: surencodage UTF-8
Configuration 7	texte: ASCII script: UTF-8	texte: ASCII script: UTF-8	texte: UTF-8 script: UTF-8
Configuration 8	texte: ISO-8859-1 script: UTF-8	texte: MacRoman script: UTF-8	texte: UTF-8 script: UTF-8

Dans ce tableau, chaque case représente l'encodage textuel du fichier de sortie en fonction de l'encodage du fichier d'entrée et de la configuration du script. On distingue à chaque fois l'encodage du texte provenant de l'extraction du fichier d'entrée et le texte provenant d'une fonction print du script encodé en UTF-8 (ex: print "resumé :").

Parmi les erreurs d'encodage, on remarque parfois un phénomène qu'on a denommé surencodage UTF-8. Il s'agit des cas où un caractère non ASCII comme le e accentué se retrouve encodé par la suite d'octets C3 83 C2 A9. Si on prend comme exemple le cas de la configuration 1 avec un fichier XML en entrée encodé en ISO-8859, on peut faire l'hypothèse suivante pour reconstituer la chaîne de traitement et expliquer le résultat obtenu :

Les e accentués sont encodés par l'octet E9 dans le fichier en entrée et par les octets C3 A9 dans le script
Après extraction du contenu textuel, les "é" provenant du fichier d'entrée sont convertis en UTF-8 par la fonction utf8() du module Unicode::String. Ces "é" sont alors encodés par la même suite d'octet que les "é" provenant du script.
On force l'édition du fichier de sortie en UTF-8. Tous les caractères non ASCII sont alors réencodés comme s'ils étaient en ISO-8859-1 (???). En effet, la suite d'octets C3 A9 correspond en ISO-8859 aux caractères Ã et © qui s'encode en UTF-8 par la suite d'octet C3 83 et C2 A9.

Lorsque nous avons indiqué la mention ASCII dans une case du tableau, cela signifie que tous les caractères non ASCII comme le e accentué ont été supprimés dans le fichier de sortie. Les détails de ces tests (scripts + inputs + outputs) sont disponibles dans l'archive suivante : testencodage1.zip

La principale remarque qu'on peut faire en comparant les résultats est qu'aucune de nos configurations ne fonctionne indépendamment de l'encodage. La configuration 3 qui fonctionne bien pour des fichiers d'entrée en ISO-8859-1 et MacRoman ne fonctionne malheureusement pas pour un fichier d'entrée en UTF-8. Sans qu'on puisse en expliquer la raison le contenu textuel extrait de ce dernier fichier est alors encodé en ISO-8859 dans le fichier de sortie ! Si on décide d'utiliser la fonction utf8() du module Unicode::String sur ce contenu, l'ensemble du fichier de sortie sera bien encodé en UTF-8. Pour mettre en oeuvre la première méthode d'extraction des données textuels, nous avons donc retenu dans notre script la configuration suivante :

indication l'encodage à l'ouverture du fichier d'entrée (A)
conversion des données extraites à l'aide du module Unicode::String (B) (même si elles sont déjà encodés en UTF-8)
Non indication de l'encodage à l'édition du fichier de sortie (C')

Nous avons également mis en place quelques tests pour la méthode avec l'usage du module XML::RSS. Seule l'indication de l'encodage à l'édition du fichier de sortie semble nécessaire. Nous n'avons pas fait usage du module Unicode::String dans ce cas et il n'a pas été nécessaire de prendre en compte l'encodage du fichier d'entrée. D'après le CPAN, l'encodage par défaut du module est l'UTF-8. Bien que le résultat de ces tests puissent paraître étranges, on constatera dans l'archive téléchargeable sur cet page que les fichiers obtenus par cette méthode sont alors correctement encodés en UTF-8.

Les résultats

Une fois les tests terminés, nous avons lancé le programme sur l'archive des flux RSS de 2012. Nous nous sommes rapidement aperçus de quelques différences avec l'archive de 2008, notamment dans le contenu des balises </title> pour les rubriques. Nous avons donc retoucher une dernière fois les scripts. Parmi les changement, on ne mentionne plus dans les fichiers de sortie les cas où on parcours un même article pour la seconde fois. Les doublons sont simplement ignorés. La présentation du fichier de sortie au format texte a été simplifié puisqu'on ne garde désormais que le contenu textuel des titres et des résumés.

Les fichiers de sortie ainsi que les scripts des méthodes 1 et 2 sont téléchargeables dans les archives suivantes :

Comparaison entre les deux méthodes

Nous n'avons pas obtenu les mêmes résultats avec les deux méthodes. La méthode 1 à base d'expressions régulières a permi d'analyser 6092 fichiers XML soit plus de 136339 articles dont 21621 ont été extraits. La méthode 2 n'a analysé que 1102 fichiers XML soit un peu plus 48011 articles dont seulement 8652 ont été retenus. Ces différences sont dûes à des erreurs que nous n'avions pas constaté sur l'échantillon du corpus de 2008 qui avait servi de test à nos scripts.

Erreurs constatées pour la méthode 1

La structure XML des fils RSS compte deux balises <title>. La balise située sous l'arborescence <channel> correspond au nom de la rubrique et celle située sous l'arborescence <item> correspond au titre d'un article.

Dans les fichiers de sortie par rubrique, on compte 80 cas où des fichiers texte ou XML ont été créés à partir du titre d'un article et non du titre d'une rubrique. Ce qui peut paraître curieux, c'est que tous ces fichiers sont vides et que les articles corresponant à ces noms de fichiers ont tous bien été extraits dans les fichiers de sortie globaux ou dans le fichier de sortie correspondant à leur rubrique.

On peut en déduire que l'expression régulière qui devait permettre d'extraire le nom d'une rubrique pour nommer de nouveaux fichiers de sortie n'est pas assez sélective :

if ($texte =~/<title>(.+?)<\/title>/) {$rubrique=$1;}
$rubrique =~ s/Le Monde.fr : //;
$rubrique =~ s/ - LeMonde.fr//;

Cette expression régulière doit normalement permettre de récupérer dans la concaténation d'un fichier XML des archives de 2012 le contenu textuel de la première attestation d'une balise <title>.

Prenons alors dans les fichiers de sortie par rubrique le cas du fichier Soirée_music-hall_au_Royal_Palace_de_Kirrwiller>.txt . Son contenu est vide et une recherche dans le fichier de sortie global permet de voir qu'un article portant le même titre a bien été extrait (numero 190 dans la rubrique Vous du 30 Mars 2012). On trouve aussi cet article dans le fichier de sortie de la rubrique Vous. On peut donc dire que cette erreur n'a pas d'influence sur l'extraction des données. Mais cela signifie qu'il existe dans les archives de 2012, un fichier XML dont la première balise <title> contient ce même titre.

Nous nous sommes apperçus que contrairement à l'échantillon des archives de 2008, les archives de 2012 contiennent en plus des fils RSS des fichiers XML archivant le décompte des mots des articles par jour. Or dans le dossier correspondant au 3 Avril 2012, le fichier fil1333472475-v2.xml contient à ligne 4153 l'information suivante :

Il s'agit bien de la première balise <title> de ce document et la fonction de nettoyage que nous avions prévue dans notre script permet d'expliquer pourquoi le nom du fichier est Soirée_music-hall_au_Royal_Palace_de_Kirrwiller>.txt

Cette erreur qui n'a heureusement pas eu d'influence sur l'extraction des données aurait pu être évitée en améliorant la précision de l'expression régulière servant à repérer le nom des rubriques. Puisque les fichiers de décompte des mots ne contiennent pas de balises <channel>, on pourrait proposer la solution suivante :

if ($texte =~/<channel><title>(.+?)<\/title>/) {$rubrique=$1;}
$rubrique =~ s/Le Monde.fr : //;
$rubrique =~ s/ - LeMonde.fr//;

Parmi les autres erreurs constastées dans la méthode 1, la fonction de nettoyage du nom des rubriques pour le nommage des fichiers de sortie n'a pas fonctionné comme voulu. Les espaces ont bien été remplacés par le symbole "_", mais les lettres accentuées n'ont pas été remplacées par leur équivalent sans accent. Cela veut dire qu'on obtient en sortie des fichiers comporant des symboles non ASCII, ce qui peut être un problème pour plus tard. Il y a aussi le risque lorsque le titre d'une rubrique n'a pas toujours été saisie de la même manière de se retrouver avec plusieurs fichiers de sortie pour cette rubrique comme c'est le cas avec les fichiers suivants : Economie.xml et Économie.xml .

Dans la fonction de nettoyage du contenu textuel, on a oublié de prendre en compte certain cas comme la présence du symbole NO-BREAK SPACE (utf-8: C2 A0) qu'on aurait pu remplacer par un simple SPACE. L'ensemble des problèmes d'encodage a bien été réglé à quelques exceptions prêts.

Erreurs constatées pour la méthode 2

On a relevé trois principales cause de différences des résultats lorsqu'on a utilisé dans notre script le module XML::RSS à la place des expressions régulières pour extraire le contenu textuel des balises des fil RSS.

la présence de balises vides de contenu
la présence de fichiers XML pas au format RSS
la présence de fichiers XML vides

Lorsqu'on compare le décompte des articles dans la sortie globale de la méthode 1 et de la méthode 2, on constate un décalage à partir de l'article numéro 73. Voici les résultats pour la méthode 1 :

Voici les résultats pour la méthode 2 :

Avec la méthode 2 XML::RSS, le contenu de la balise <title> de l'article 73 est vide tout comme dans le document XML source :

Le contenu de la balise <description> a quant à lui été entièrement effacé par la fonction de nettoyage. Avec la méthode 1, la balise autofermante <title/> n'est pas matchée par notre expression régulière d'extraction du contenu des balise <title> et <description> :

$texte =~/<item><title>(.+?)<\/title>.+?<description>(.+?)<\/description>/g

Afin d'éviter ce décalage dans le décompte des articles entre les deux méthodes, il aurait fallu prévoir le cas ou le contenu textuel d'une balise renvoyé grâce au module XML::RSS est nul...

Au déroulement du script 2, deux types d'erreur s'affichent dans le terminal :

Le premier type d'erreur, Use of uninitialized value, est dû à la présence dans les archives 2012 de documents XML qui ne sont pas des fichiers RSS et qui ne peuvent pas être traités correctement par le module XML:RSS. Il s'agit des fichiers de décompte de fréquence des mots servant à la création de nuage de mots.

Le deuxième type d'erreur est beaucoup plus grâve car il stoppe le déroulement du script. Les fichiers de sortie XML ne sont donc pas valide puisque certaines balises restent ouverte. Cette erreur est dû à la présence de fichiers XML vides de contenu. C'est par exemple le cas du fichier 0,2-3224,1-0,0.xml dans le dossier du 15 décembre.

Ces erreurs qui n'avaient pas eu lieu dans les tests que nous avions effectués sur un extrait des archives de 2008 expliquent les très mauvais résultats obtenus au moyen de notre deuxième script à base du module XML::RSS. Il faudrait prévoir dans un futur script de vérifier avant l'utilisation de ce module que le contenu du fichier XML est bien de type RSS et qu'il n'est pas vide.

Vu le temps d'exécution des programmes sur les archives de 2012, nous avons finalement préféré pour la suite de nos travaux travailler avec uniquement avec les résultats obtenus par la méthode 1. Pour cela, nous avons supprimé manuellement les 80 fichiers d'erreur dans le dossier RUBRIQUE.

Boîte à Outils