Informations
Abonnement
Membres
-
Fabien POULARD -
Jérôme Rocheteau
-
Laurent Audibert
-
Matthieu Vernier
-
Nicolas Hernandez
-
Nicolas Hernandez
Participer
Accès rapide aux derniers articles de la page
- 20/09/2010 : UIMA insights : le doigt dans le workflow
- 08/09/2010 : Un rapide tokeniseur en mots pour le français
- 17/07/2010 : Du bon usage des ressources dans UIMA
- 01/04/2010 : Parcours des annotations couvertes par une autre annotation
- 16/03/2010 : Tests unitaires pour UIMA avec UUTUC
- 06/03/2010 : Utilisation du CAS Editor
- 04/03/2010 : Release du collection reader pour Wikipedia v.0.4
- 21/02/2010 : UIMA & Wikipédia (5) : Gestion du projet avec Maven
- 14/02/2010 : UIMA & Wikipédia (4) : Analyse de la syntaxe MediaWiki
- 12/02/2010 : UIMA & Wikipédia (3) : Filtrage des données à charger
Les opérations logicielles en traitement automatique des langues sont souvent très importantes, très coûteuse, mais également parallélisables. C'est l'un des avantages indéniables d'UIMA, par le choix d'une architecture par composants, de permettre de paralléliser les traitements assez simplement.
La programmation d'un composant UIMA doit donc se faire avec en tête l'idée qu'il pourrait être déployé pour un traitement parallélisé. Lorsque comme moi on n'a pas cette habitude, on se heurte rapidement à des petits obstacles techniques. Dans le cas présent, il s'agissait de développer un composant qui exportait les résultats d'un calcul dans un fichier CSV.
Mon problème
La chaîne de traitement que j'utilise pour ma thèse calcule des scores de similarité entre des documents. Afin de simplifier l'évaluation de mon système, je souhaite réunir tous ces scores de similarité dans un même fichier CSV.
La solution naïve qui fonctionne presque consiste à ce que le composant ouvre un fichier et y écrive au fur et à mesure. Les systèmes ne rechignent pas à ce que plusieurs processus écrivent en même temps dans le même fichier... Malheureusement ils ne s'assurent pas non plus d'ordonnancer les requêtes d'écriture au risque que chacun écrive sur la copie de son voisin !
Voici le résultat que j'attends :
source-document00003.txt;suspicious-document00016.txt;not-derivative;0.0016992353 source-document00003.txt;suspicious-document00040.txt;not-derivative;0.23280424 source-document00267.txt;suspicious-document00055.txt;derivative;0.14148398
et voici ce que ça peut donner quand les différents processus décident d'écrire en même temps :
source-document00003.txt;suspicious-docsource-document00003.txt;suspicious-source-document00267.txt;suspicious-document00055.txt;derivative;0.14148398 ument00016.txt;not-derivative;0.0016992353 document00040.txt;not-derivative;0.23280424
Le workflow d'UIMA
J'avais déjà rapidement présenté le workflow d'UIMA dans mon billet sur les ressources. Un petit résumé des épisodes précédents ne sera peut-être pas de trop.
Comme d'habitude, pour simplifier, on va considérer qu'on utilise uniquement le flow controler par défaut qui fait s'enchaîner séquentiellement les composants. Cela revient à considérer que la sortie d'un composant alimente directement l'entrée du composant suivant, à la manière des pipes dans le monde Unix.
Dans cette configuration, UIMA regroupe les chaînes de CAS processors (les composants qui manipulent les CAS) dans autant de processing pipelines que l'attribut processingUnitThreadCount du CPE le demande, comme l'illustre le schéma ci-dessous :
l est nécessaire d'instancier les composants utilisés autant de fois qu'il y a de processing pipelines. Jusque-là, rien de bien nouveau en réalité. Mais ce que j'ai découvert récemment, douloureusement bien entendu, c'est que cette instanciation ne se faisait pas au sein des pipelines, mais au sein du thread principal du CPE. Soit la procédure suivante, pour chaque composant :
- Instanciation du composant dans le thread principal du CPE ;
- Appel de la méthode initialize() toujours dans le thread principal ;
- Création des threads des pipelines et rattachement des composants à ces derniers ;
- Appels successifs à process() au sein de ces threads ;
Ma solution
J'aurais certes pu faire le choix d'utiliser le système des ressources pour mon composant, comme je le préconise dans mon billet précédent. Toutefois, je n'ai pas eu le temps de manipuler le système des ressources et il est grand temps que j'en finisse avec ma thèse :) Je me suis donc tourné vers quelque chose de plus direct.
Mon choix s'est donc porté sur la création d'autant de fichiers qu'il y a d'instances de mon composant. Je suffixe tout simplement le nom du fichier par l'identifiant du thread courant. Cette méthode fonctionne suffisamment bien, mais nécessite bien entendu de concaténer l'ensemble des fichiers à la fin du traitement. De plus elle ne permet pas directement de garder une trace de l’ordonnancement des écritures ! Dans mon cas ce n'était pas un prérequis.
Pour la petite histoire, j'ai découvert que la méthode initialize() était appelée dans le thread principal car tous mes fichiers étaient suffixés par l'identifiant 1. J'ai donc simplement déplacé l'ouverture des fichiers dans la méthode process() en ajoutant un test pour s'assurer que cette initialisation n'avait pas déjà eu lieu.
Voici le code (synthétique) correspondant, toute l'astuce réside dans le Thread.currentThread().getId() :
public void process(JCas aJCas) throws AnalysisEngineProcessException { // Check the streams have been initialized if (theStream == null) { Long tid = Thread.currentThread().getId(); theStream =new PrintStream( new File( theExportSuffix + ".__" + tid), "utf-8"); } // Select the right view JCas view = aJCas.getView(theViewName); ...
Parmi les addons distribués avec UIMA, le composant WhitespaceTokenizer permet de découper les textes en "mots" en s'appuyant sur les espaces et autres blancs. Malheureusement si cette approche est acceptable pour l'anglais, elle est beaucoup plus problématique pour le français. Le découpage en mots n'est pas une tâche forcément évidente et qui nécessiterait un réel travail. Partagé entre la nécessité d'une tokenisation correcte et le peu de temps qui me reste pour terminer ma thèse, voici une proposition suffisamment acceptable pour mes besoins.
Idée et objectifs
Mon idée est d'exploiter la catégorie générale des caractère telles que définies dans la norme Unicode pour détecter les frontières des mots. Une rupture dans la catégorie des caractères indiquant vraisemblablement un changement de mot.
Je souhaite que mon composant soit en mesure d'identifier correctement tous les mots détectés par le WhitespaceTokenizer (c'est un minimum), ainsi que les cas problématiques tels que :
- les articles et pronoms contractés (l', d', j', m', ...)
- les composés lexicaux à apostrophe (aujourd'hui, ...)
- les composés lexicaux à traits d'union (arc-en-ciel, peut-être, sauve-qui-peut, ...)
- les valeurs numériques (14 000, 14,18, 30 %, ...)
- les acronymes (ASSEDIC, ASCII, ...) et les sigles (C-4, c-à-d, i.e., ...)
- les unités de mesure (A/m, km/h, ...)
Mise en œuvre
Catégories générales des caractères unicodes
La norme unicode offre sept catégories générales de caractère :
| Unicode | Java (getType) |
|---|---|
| les lettres (L) | |
| Ll | LOWERCASE_LETTER |
| Lu | UPPERCASE_LETTER |
| Lm | MODIFIER_LETTER |
| Lo | OTHER_LETTER |
| Lt | TITLECASE_LETTER |
| les marques (M) | |
| Mc | COMBINING_SPACING_MARK |
| Me | ENCLOSING_MARK |
| Mn | NON_SPACING_MARK |
| les nombres (N) | |
| Nd | DECIMAL_DIGIT_NUMBER |
| Nl | LETTER_NUMBER |
| No | OTHER_NUMBER |
| les ponctuations (P) | |
| Pc | CONNECTOR_PUNCTUATION |
| Pd | DASH_PUNCTUATION |
| Pe | END_PUNCTUATION |
| Pi | INITIAL_QUOTE_PUNCTUATION |
| Pf | FINAL_QUOTE_PUNCTUATION |
| Po | OTHER_PUNCTUATION |
| Ps | START_PUNCTUATION |
| les symboles (S) | |
| Sc | CURRENCY_SYMBOL |
| Sm | MATH_SYMBOL |
| Sk | MODIFIER_SYMBOL |
| So | OTHER_SYMBOL |
| les séparateurs (Z) | |
| Zl | LINE_SEPARATOR |
| Zp | PARAGRAPH_SEPARATOR |
| Zs | SPACE_SEPARATOR |
| divers (C) | |
| Cc | CONTROL |
| Cf | FORMAT |
| Co | PRIVATE_USE |
| Cs | SURROGATE |
| Cn | UNASSIGNED |
Le site Fileformat fournit une liste et une description exhaustive des caractères contenus dans ces différentes catégories.
Description des mots
Mots pleins
Les mots pleins sont ceux qui se composent uniquement d'une suite de caractères alphanumériques, on peut les reconnaître à l'aide de l'automate suivant :
Le cas de l'apostrophe
Les articles et pronoms contractés précédent un autre mot, ils se composent d'une seule lettre et d'un apostrophe. Les apostrophes appartiennent à la catégorie Po qui contient également le point d'exclamation, le dièse, ... ou bien à Lm. Il est préférable d'établir une liste des caractères correspondant. L'apostrophe (U+0027) et le modifieur apostrophe (U+02BC) sont les deux caractères qui semblent correspondre pour le français.
Les composés lexicaux à apostrophe sont quant à eux formés de deux séquences alphabétiques connectées par un apostrophe (aujourd'hui, ...).
L'automate permettant de reconnaître ces deux formes de mots :
Le cas du trait d'union
Le trait d'union est utilisé dans plusieurs configurations : pour les composés lexicaux (arc-en-ciel, peut-être, sauve-qui-peut, ...) et certains sigles sigles (C-4, c-à-d, ...). D'une manière générale certaines ponctuations sont employées au sein des mots : le point pour les abréviations (i.e., M., ...), ou le slash pour les unités de mesure (A/m, km/h, ...).
Les traits d'union sont regroupés dans la catégorie ''Punctuation, dash'' (''Pd''), les autres ponctuations (slash et point) sont placées dans ''Punctuation, other'' (''Po''). L'important c'est que ladite ponctuation soit placée entre deux séquences de lettres :
Les valeurs numériques particulières
Finalement le dernier cas particulier concerne les valeurs numériques complexes (14 000, 14,18, 30 %, -3, ...). La catégorie ''Symbol, Currency'' (''Sc'') nous intéresse particulièrement. Le symbole ''%'' se trouve dans la catégorie ''Punctuation, other' (''Po''), tandis que le point et la virgule décimale correspondent respectivement à U+002E et U+002C.
Algorithmie
La tokenisation s'effectue sur un flux continue de caractères. L'utilisation d'automates classiques tels que présentés précédemment n'est pas forcément possible car l'utilisation commune ne correspond pas forcément à une grammaire régulière et ils sont non déterministes. En gros nous pouvons nous retrouver dans ces cas de figure :
- Parfois l'espace sépare un mot, parfois il est contenu au sein d'un mot (entre le nombre et la monnaie par exemple) ;
- Parfois le passage d'un mot à un autre se fait en consommant un ou plusieurs caractères (espace), parfois le caractère de séparation appartient à l'un des deux mots (apostrophe) ;
- La consommation d'un caractère inattendu ne doit pas interrompre le fonctionnement : une décision doit être prise (couper le mot ou pas).
Ma proposition consiste à mettre en œuvre une sorte de transducteur à pile. La pile permet uniquement de conserver un historique des derniers caractères consommés afin de découper les mots à une position antérieure si nécessaire (symbole de monnaie non trouvé mais espace consommé par exemple). L'utilisation d'un transducteur permet d'enovyer des signaux indiquant si une coupure de mot doit avoir lieu ou non.
Les signaux envoyés par le système peuvent être les suivants :
- start_word un nouveau mot commence ;
- end_word le mot courant se termine, le caractère juste consommé n'en faisant pas parti ;
- end_words_prev le mot courant se termine au caractère anté-précédent ;
- switch_word le mot courant se termine sur le caractère consommé, le caractère courant appartient à un nouveau mot ;
- switch_word_prev le mot courant se termine au caractère anté-précédent, le caractère courant appartient à un nouveau mot ;
- nop aucune opération
L'automate ci-dessous correspond à ce transducteur :
- les états en N (orange) correspondent à l'automate de reconnaissance des valeurs numériques ;
- les états en L (bleu) correspondent à une combinaison des automates de reconnaissance des mots alphabétiques ;
- les transitions en rouge correspondent aux cas d'erreur où il faut prendre une décision ;
- les transitions en vert correspondent aux cas attendus de changement de mot.
Implémentation
J'ai recherché une bibliothèque Java pour manipuler des transducteurs... mais je n'ai rien trouvé. J'ai donc tout implémenté manuellement ce qui n'est pas formidable pour le maintient du code. J'ai donc implémenté également plusieurs tests unitaires.
Au final, les cas où les symboles monnétaires sont espacés des nombres par un espace pose problème, mais j'ai choisi de laisser tel quel car je ne vois pas de solution pratique (je ne vois plus grand chose en fait).
Chose intéressante, mon implémentation à base de transducteur est plus rapide de près de 40% que le composant WhitespaceTokenizer sur un petit corpus de test, mais d'autres tests donnent les deux annotateurs ex-aequo. La qualité du résultat est sans comparaison, comme l'illustre l'exemple ci-dessous :
"Le Roi a reçu en audience en début d’après-midi au Château
Résultat du WhitespaceTokenizer : {", Le, Roi, a, reçu, en, audience, en, début, d, ’, après, -, midi, au, Château}
Résultat de notre composant : {", Le, Roi, a, reçu, en, audience, en, début, d’, après-midi, au, Château}
Distribution
Les jar avec les sources et le descripteur sont disponibles ici.
J'ai également ouvert un dépôt sur github pour ceux qui voudraient contribuer.
Les ressources sont un aspect de UIMA que j'ai peu abordé et que j'ai très peu utilisé, sauf récemment lorsque l'on a entraîné un modèle français HMM pour le HMM Tagger (il faut que j'écrive un billet à ce sujet d'ailleurs). Pourtant les ressources, et leur rôle, sont assez mal compris au sein d'UIMA.
L'erreur de Jérôme
Je m'excuse par avance auprès de Jérôme pour construire toute mon argumentation et ce billet sur une erreur qu'il a faite :) Pour information, Jérôme travaille en tant qu'ingénieur de recherche au sein de notre équipe de recherche, et est très certainement la personne de l'équipe la plus impliquée et la plus compétente sur UIMA. Voilà pour la mise en garde, je peux désormais mettre en place l'inquisition et prononcer l'auto da fé de sa méthode !
L'erreur dont je parle est celle présentée dans ce billet. En gros, Jérôme nous explique dans ce billet que pour compter le nombre de mots dans tous les documents d'une collection, à l'aide d'un AE, on procède en en trois temps :
- dans la méthode initialize() on prépare la structure qui va nous permettre de collecter les données
- dans la méthode process() on compte les termes et on alimente la structure initialisée dans le initialize()
- dans la méthode collectionProcessComplete() on fait un bilan de ce que l'on a collecté dans la fameuse structure et on renvoie tout à l'utilisateur.
D'une manière générale, cela revient à dire que l'on peut définir une structure persistante dans un AE qui nous permette de stocker des informations relevant de tous les CAS. Ce raisonnement est entièrement faux, même s'il fonctionne en général.
Du CPE et des Processing pipelines
Tout d'abord il est peut-être nécessaire de rappeler ce qu'est un CPE. Il s'agit de l'ensemble des composants (collection reader, analysis engines et CAS consumers) agencés pour produire et traiter les différents CAS. On peut en quelque sorte considérer qu'un CPE est une chaîne de traitement instanciée.
Un CPE est orchestré par un CPM, ce dernier va se charger de la mise en œuvre de la chaîne : instanciation des composants, appel des méthodes de l'API, distribution des CAS, suivi des erreurs, collecte d'informations statistiques sur le déroulement du traitement.
Voilà donc pour la théorie générale, qui peut se résumer à ce schéma que j'emprunte gentiment aux gens d'Apache :
Au regard de ce schéma on pourrait penser que la méthode décrite par Jérôme fonctionne puisqu'on a l'impression que les CAS produits ne passent au travers que d'une seule instance des AE. Si tel était le cas, l'intérêt de UIMA en termes de déploiement serait limité puisque cela reviendrait à transmettre la sortie d'un composant à l'entrée du composant suivant dans la chaîne. Une sorte pipe entre les différentes briques logicielles.
Il faut se pencher un peu plus profondément dans la configuration du CPE pour se rendre compte que le fonctionnement est bien mieux pensé que cela. Ainsi, on trouve dans la section ''casProcessors'' des descripteurs (XML) de CPE, un attribut d'intérêt : processingUnitThreadCount.
L'attribut processingUnitThreadCount spécifie le nombre de Processing pipelines (trad: chaînes de traitement ?) répliquées. Une processing pipeline est composée de la séquence d'AE définissant le traitement à opérer. Ces séquences (et donc les AE associés) sont dupliqués autant de fois que le nombre précisé par l'attribut processingUnitThreadCount, chacune s'exécutant dans son propre thread indépendamment des autres.
Un petit schéma, encore une fois gentiment emprunté aux gens d'Apache, vaut mieux qu'un long discours :
Le CPM prélève les CAS produit par le collection reader, et stockées dans la queue d'entrée (de taille casPoolSize), et les distribue dans les différentes processing pipelines. Les CAS étant distribuées entre les différentes chaînes, un CAS donné ne passera que par une seule de ces chaînes : c'est ici que la méthode de Jérôme échoue ! En effet, chaque AE dupliqué ne traite qu'un sous ensemble des CAS produits et alimente sa propre structure interne, sans connaissance des informations stockées dans les structures des autres instances de ce même AE.
L'avènement des ressources externes
Au sein de l'équipe nous avons déjà discuté brièvement des ressources externes. Cependant le contenu des discussions se résumait plus au mois à les ressources on ne sait pas trop à quoi ça sert, par contre c'est ennuyeux car il faut éditer les descripteurs pour les préciser, donc on préfère les paramètres. Nous sommes passés à côté de l'essence même de ces dernières.
La section 1.5.4 de la documentation ''Tutorials and users guides'' décrit le fonctionnement et l'utilisation des ressources externes.
Sometimes you may want an annotator to read from an external file – for example, a long list of keys and values that you are going to build into a HashMap. You could, of course, just introduce a configuration parameter that holds the absolute path to this resource file, and build the HashMap in your annotator's initialize method. However, this is not the best solution for three reasons:
Les ressources externes ont deux avantages majeurs (à mon avis) :
- Elles sont partagées entre toutes les instances du même AE (cf. section 1.5.4.4);
- Elles peuvent implémenter une interface particulière et ainsi embarquer un comportement ;
Il serait donc préférable dans le cas de Jérôme :
- soit d'empêcher le déploiement en parallèle de plusieurs instances du même AE ;
- soit de passer par une ressource (une ArrayList par exemple)
J'ai la lâcheté de ne pas proposer de correction, mais l'objectif de ce billet était simplement d'expliquer pourquoi l'utilisation de ressources externes pouvait se justifier et pourquoi la combinaison de structures internes et d'appel à la méthode collectionProcessComplete n'était pas toujours suffisant.
Lorsque l'on travaille avec Apache UIMA et que l'on ajoute un nombre important d'annotations, il arrive un moment où l'on va vouloir filtrer certaines de ces annotations en fonction d'autres. Ainsi, assez couramment on éprouve le besoin de devoir récupérer des annotations qui couvrent la même zone de texte qu'une autre. Par exemple :
- récupérer les mots contenus dans une phrases ;
- récupérer les paragraphes dans un document ;
- …
Il y a au moins deux approches dans Apache UIMA qui permettent de répondre à ce besoin : le subiterator et le FSMatchConstraint.
Utilisation du subiterator
L'approche basée sur le subiterator ne peut fonctionner que si les types que l'on cherche à accéder sont couverts par le type couvrant au sens de UIMA, c-à-d en terme de priorité des types (cf. [la javadoc de TypePriorities] ou cet email).
Considérons une annotation A qui couvre des annotations B de la manière suivante :
Il y a du texte et les annotations sont sur ce texte ... [-----A:1-----] [---A:2---] [--------A:3--------] [B:1] [B:2] [B:3] [B:4] [B:5] [B:6]
Dans l'exemple ci-dessus, nous sommes intéressés par les annotations B couvertes par l'annotation A:3, en d'autres termes les annotations B:4, B:5 et B:6.
La méthode est la suivante :
- On récupère un pointeur sur l'annotation couvrante qui nous intéresse (A:3), à l'aide d'un itérateur par exemple ;
- On récupére l'index des annotations couvertes (les B) ;
- On appelle la méthode subiterator de l'index des annotations couvertes (B) en passant en paramètre l'annotation couvrante (A:3), la méthode nous retourne un itérateur sur les annotations B couvertes par A:3, soit B:4, B:5 et B:6.
Voici le code correspondant :
Utilisation des contraintes (FSMatchConstraint)
Lorsque l'on ne connaît pas les priorités des types ou bien qu'elles ne correspondent pas à ce que l'on souhaite faire, il est nécessaire de passer par un mécanisme plus complexe (mais beaucoup plus puissant) : le système de contraintes d'index.
Dans le cas présent, nous allons définir une contrainte imposant que les attributs begin et end d'une annotation d'un type donné correspondent à une certaine valeur : celle de l'annotation couvrante. Puis nous pourrons générer un itérateur qui retournera les annotations de l'index qui respectent cette contrainte.
Voici l'implémentation d'une méthode qui fait cela :
Cette méthode prend en paramètre le JCas dans lequel travailler, l'annotation couvrante (l'annotation A3 dans l'exemple précédent), le type d'annotation qui nous intéresse (le type B pour reprendre l'exemple précédent) et un booléen qui permet de préciser si l'on souhaite une correspondance exacte ou approximative des frontières.
La qualité du code développé dans le cadre des activités de recherche scientifique n'est pas toujours aussi bon qu'on pourrait l'espérer. Outre la nécessité (évidente à mes yeux) d'ouvrir le codes des activités scientifiques financées par l'État et les collectivités territoriales, il est également nécessaire de suivre de bonnes pratiques de programmation. L'écriture de tests unitaires et leur exécution régulière est une de ces bonnes pratiques.
Je présente dans ce billet un cas d'utilisation de la bibliothèque UUTUC, présentée lors du Workshop sur l'Ingénierie Logiciel, les Tests et l'Assurance Qualité pour le Traitement des Langues Naturelles (SETQA-NLP 2009), pour tester l'implémentation d'une bibliothèque développée et utilisée dans le cadre de ma thèse (tddts-uima-shingling).
Principe de UUTUC
UUTUC est une bibliothèque offrant un certain nombre de méthodes facilitant le processus de test des composants UIMA. On y trouve notamment un certain nombre de classes de type Factory qui facilitent la mise en place de chaînes de traitement simples pour expérimenter les composants.
À l'aide de ces classes, l'exécution d'un AE sur un simple fichier texte se résume à ces quelques lignes :
Le couplage de UUTUC avec JUnit permet de mettre en place un banc de tests unitaires :
- Afin de tester la conformité de l'implémentation avec les spécifications attendues ;
- Prévenir les problèmes de régression lors de l'évolution des composants
Écriture de tests unitaires
J'utilise le framework JUnit 4 pour les tests unitaires. Il suffit de faire précéder les méthodes considérées comme des tests par @Test pour qu'elles soient reconnues comme telles par JUnit. Exemple :
Combiné à UUTUC, il permet de mettre en place un environnement UIMA assez simplement. Ainsi dans l'exemple ci-dessous, nous définissons une méthode à exécuter avant chaque test (@Before) qui crée un JCas et y ajoute quelques annotations à l'aide des Factory de UUTUC :
Malheureusement il y a assez peu de documentation concernant UUTUC. Il est ainsi régulièrement nécessaire d'aller jeter un œil au code source qui heureusement est très bien écrit.
Intégration avec Maven
Maven modélisant toutes les étapes du cycle de développement, il intègre une étape test entre le compile et le package. La gestion des tests unitaires se faisant quant à eux au travers du plugin maven-surefire-plugin.
Il faut tout d'abord rajouter dans le pom.xml les informations de dépendance sur UUTUC et JUnit :
Il suffit ensuite de faire appel au plugin maven-surefire-plugin qui prend en charge tout ce qui concerne les tests, sous réserve que ces derniers soient bien présents dans src/test/java :
Il est alors possible de lancer l'exécution des tests avec Maven :
$ mvn test ... ------------------------------------------------------- T E S T S ------------------------------------------------------- Running tddts.uima.shingling.ShingleTest Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.992 sec Results : Tests run: 16, Failures: 0, Errors: 0, Skipped: 0 ...
Plus d'excuse pour ne pas tester votre code maintenant ! L'excuse de faire du prototypage pour la recherche n'en est pas une bonne dès que les résultats que vous publiez dépendent de la qualité dudit code. C'est votre intégrité et honnêteté scientifique qui est en jeux ;)
Il y a quelques temps j'avais écrit une documentation en interne dans mon laboratoire sur l'utilisation du ''CAS Editor''. À l'époque c'était assez éprouvant car ce dernier se présentait sous la forme d'une application RCP Eclipse.
Depuis la version 2.3.0, le CAS Editor a été intégré sous la forme d'un plugin Eclipse. L'occasion de remettre la doc au goût du jour et de la partager avec le reste du monde.
Avant propos
Avant toute chose il est nécessaire d'installer les plugins Eclipse de UIMA. Pour ce faire, il faut ajouter le dépôt Eclipse : http://www.apache.org/dist/incubator/uima/eclipse-update-site/ dans l'outil de gestion des plugins. Ensuite il suffit de rechercher UIMA et d'installer tous les plugins associés.
À noter que les personnes ayant installé les plugins des versions antérieures doivent simplement faire une mise-à-jour afin de faire apparaître le plugin CAS Editor qui n'était pas présent auparavant.
Un petit redémarrage d'Eclipse et vous devriez être paré pour la suite...
Initialiser un projet
Le fonctionnement du CAS Editor est lié à :
- une vue CAS Editor
- un projet CAS Editor
Ceci est spécifique à la version 2.3 d'UIMA et devrait évoluer dans les prochaines versions.
La vidéo ci-dessous illustre les étapes nécessaires à l'initialisation d'un projet et l'importation d'un corpus :
- Créer un projet CAS Editor
- Passe en vue CAS Editor afin d'accéder aux fonctionnalités spécifiques
- Créer un répertoire corpus
- Importer dans ce répertoire corpus des fichiers textes afin de les transformer en CAS
- Ouvrir et visualiser le contenu des fichiers (CAS) du corpus
Ajouter des annotations manuellement
Il n'est possible d'ajouter des annotations que si le type d'annotation à ajouter est présent dans le Type System. Si toutefois vous ajoutez des types d'annotation à un Type System qui est déjà utilisé par le projet CAS Editor, les nouveaux types ne vont pas apparaître. Il est nécessaire de fermer puis réouvrir le projet.
Il y a deux façons d'ajouter une annotation dans un CAS, l'une permet d'ajouter la même annotation par un simple appuie sur Entrée :
- Sélectionner le texte
- Sélectionner le type d'annotation dans le Feature View
- Appuyer sur Entrée
l'autre permet de choisir le type de chaque nouvelle annotation rajoutée :
- Sélectionner le texte
- Appuyer sur shift + entrée
- Choisir l'annotation à ajouter
La vidéo ci-dessous illustre ces deux méthodes :
Utiliser un AE pour ajouter des annotations
Il est tout à fait possible d'utiliser directement un Analysis Engine directement dans le CAS Editor afin d'ajouter des annotations aux CAS. La procédure est toutefois un peu contraignante et surtout peu intuitive. Je vais décrire l'approche qui consiste à utiliser un composant empaqueté dans un PEAR.
Construction et installation du PEAR
Pour l'exemple je vais prendre le WhitespaceTokenizer, ce dernier a deux avantages pour ce tutoriel :
- Il est simple d'utilisation (pas de paramètres) et n'a pas de dépendances sur d'autres composants
- Il fait parti officiellement d'UIMA et distribué sur le site : UIMA Annotator Addons & Simple Server & Pear packaging tools
Il nous faut la version source du paquet UIMA Annotator Addons & Simple Server & Pear packaging tools. Une fois téléchargée, décompressez là quelque part et placez-vous dans le répertoire uimaj-annotator-addons-2.3.0-incubating/WhitespaceTokenizer/.
Il nous faut modifier un peu le pom.xml afin d'y ajouter les dépôts qui sont normalement déclarés dans le pom parent :
Il est alors possible de créer le PEAR avec maven en lançant dans le répertoire du WhitespaceTokenizer :
$ mvn package
Le pear est alors créé dans le répertoire target/ sous le nom WhitespaceTokenizer.pear. Il faut l'installer à l'aide du PearInstaller.
Une fois le PEAR installé, il faut créer un répertoire processing dans le projet du CAS Editor, y importer le descripteur PEAR, l'intégrer à un composant Agregate. On peut alors le faire tourner sur une partie du corpus.
La vidéo ci-dessous présente ces dernières phases :
Visualiser et modifier les annotations
Le but du CAS Editor est tout de même de pouvoir visualiser et manipuler les annotations, ce qui se fait dans l'éditeur.
La visualisation des annotations est configurable par le menu contextuel Show annotations où l'on sélectionne les annotations à afficher. Le mode de mise en valeur de ces dernières se configure dans les propriétés du projet.
Le parcours des annotations s'opère de plusieurs manières :
- Par le menu contextuel, Mode permet de sélectionner la façon dont on parcours/sélectionne les annotations ;
- L'onglet Feature Structure View permet de sélectionner les types d'annotation à faire apparaître dans l'onglet Outline, il alors possible dans ce dernier de supprimer des annotations (croix rouge) ;
- Les onglets Edit View permettent quant à eux de modifier les valeurs des champs de l'annotation sélectionnée.
La vidéo ci-dessous illustre ces différentes manipulations :
Wikipedia est une incroyable source d’information, de données et plus généralement d’actes langagiers (utilisation du langage). C'est une ressource sans équivalent pour les chercheurs en traitement automatique des langues (TAL).
Le MediaWiki UIMA Loader est un composant UIMA, de type collection reader, permettant de tirer parti de Wikipédia pour la construction de corpus. La version 0.4 est la première release officiellement annoncée du composant.
Pour les impatients :
- Le jar du composant (et ses dépendances : mwdumper et wikimodel.wem)
- Les sources du composant
Présentation du composant
Le composant MediaWiki UIMA Loader est un collection reader permettant de charger des données issues d'un MediaWiki, notamment Wikipédia et ses projets dérivés ...
Le composant est distribué sous licence Apache 2. Vous pouvez donc l'utiliser dans le cadre d'un travail académique ou commercial. Dans les deux cas, si vous trouvez le composant utile, n'hésitez pas à me dire ce que vous en pensez, si vous souhaitez de nouvelles fonctionnalités ou si vous rencontrez des bugs.
Contrairement à plusieurs projets existant, le composant n'attaque pas directement les sites Wikipedia. Il ne nécessite pas non plus de créer un miroir local de la base de données MediaWiki. Il travaille directement à partir des dumps XML, ce qui présente les avantages suivant :
- Pas d'accès répétitifs aux serveurs des projets MediaWiki, préservant la bande passante et le temps de calcul de ces derniers ;
- Pas besoin de déployer un serveur de base de données en local et d'y importer les données de dump (si ça vous amuse, vous pouvez toujours suivre ce tutoriel) ;
- Limiter l'espace disque disponible pour stocker les informations en utilisant directement la version compressée des dumps ;
- Limiter la latence dans l'accès aux données provoquées par les requêtes réseau ou bien le serveur SQL.
Les fonctionnalités de cette version 0.4 sont les suivantes :
- Chargement à partir d'un dump XML compressé ou non ;
- Nombreuses options de filtrage (voir plus bas) concernant les pages et révisions à charger dans la chaîne de traitement ;
- Interprétation de la syntaxe wiki et annotation des Titres, Sections, Paragraphes et Liens (cf. ce billet pour plus d'informations).
Installation
Avant d'installer et d'utiliser le composant, il est nécessaire d'avoir un environnement UIMA installé. Si ce n'est pas le cas, se référer à ce tutoriel.
Le plus simple est de récupérer le jar du composant dans l'espace de téléchargement de uima-fr, ainsi que les dépendances : mwdumper et wikimodel.wem.
Si vous souhaitez reconstruire le jar vous mêmes, il vous faut télécharger les sources du composant, toujours dans l'espace de téléchargement de uima-fr,et les compiler à l'aide de maven :
$ tar -xzvf mediawiki-uima-loader-0.4.1.tar.gz ... $ cd mediawiki-uima-loader-0.4.1 $ mvn package ...
Le jar devrait être créé dans le répertoire target/, les dépendances quant à elles auront été téléchargées dans votre dépôt maven local.
Utilisation
Vous pouvez utiliser le composant dans n'importe quelle chaîne de traitement UIMA, de la même façon que vous utilisez un composant classique de type collection reader. La démarche ci-dessous concerne l'utilisation de l'outil cpeGui, mais elle devrait être similaire pour les autres outils du même type.
Le cpeGui n'est pas capable en l'état de charger un descripteur xml depuis un jar. Avant tout, il est donc nécessaire d'extraire le descripteur du composant du jar afin de le rendre accessible. Si vous avez compilé le composant vous même, le descripteur est présent dans le répertoire desc. Sinon, il suffit de l'extraire du jar :
$ jar -x wikipedia-cr.xml -f mediawiki-uima-loader-0.4.1.jar
Il est nécessaire de rajouter le jar du composant et de ses dépendances dans le UIMA_CLASSPATH, avant de lancer le cpeGui en ligne de commande. Pour l'exemple, nous considérerons que le jar du composant est dans le répertoire courant et que les dépendances sont dans le dépôt maven local :
$ export UIMA_CLASSPATH=$UIMA_CLASSPATH:~/.m2/repository/org/wikimedia/mwdumper/1.16/mwdumper-1.16.jar:~/.m2/repository/org/wikimodel/org.wikimodel.wem/2.0.7-SNAPSHOT/org.wikimodel.wem-2.0.7-SNAPSHOT.jar:mediawiki-uima-loader-0.4.1.jar $ cpeGui
Dans la partie de l'interface dédiée au Collection Reader, cliquez sur Browse et allez sélectionner le descripteur du composant que nous avons extrait du jar (wikipedia-cr.xml). L'interface se modifie afin d'offrir les champs de paramétrage du composant.
Le seul paramètre obligatoire est le champs Input Xml Dump. Vous devez renseigner dans ce dernier le chemin menant au dump XML de Wikipedia (ou tout autre dump MediaWiki) que vous souhaitez charger. Par exemple : ~/frwiki-20100111-pages-meta-history.xml.bz2. Le composant est capable de lire un dump, qu'il soit compressé ou non.
Les autres paramètres concernent le filtrage à mettre en place lors du chargement des données :
- Latest Revision Only, si vous cochez cette case seules la dernière révision disponible pour chaque article sera chargée, sinon toutes les révisions (présentes dans le dump) seront chargées ;
- Ignore Talks, si vous cochez cette case, les pages de type discussion seront ignorées, sinon elles seront également chargées ;
- Config Namespaces Filter, ce champs permet de spécifier les espaces de nom à considérer lors du chargement. S'il est laissé vide, tous les espaces de nom sont chargés. Pour wikipedia les espaces de nom disponibles sont :
- -2 : ressources de type média ;
- -1 : pages spéciales ;
- 0 : espace de nom principal où l'on trouve les articles de l'encyclopédie ;
- 1 : discussions à propos des articles ;
- 2 : pages des utilisateurs ;
- 3 : discussion à propos des utilisateurs ;
- 4 : espace Wikipédia (le projet)
- 5 : espace de discussion autour du projet Wikipédia
- 6 : fichiers
- 7 : discussion à propos des fichiers
- 8 : espace MédiaWiki (le logiciel)
- 9 : discussion à propos de MédiaWiki
- 10 : modèles
- 11 : discussion à propos des modèles
- 12 : aide
- 13 : discussion à propos de l'aide
- 14 : catégories
- 15 : discussion à propos des catégories
- 100 : portail
- 101 : discussion à propos du portail
- 102 : projets
- 103 : discussion autour des projets
- 104 : références
- 105 : discussion autour des références
Par exemple pour prendre en considération uniquement toutes les pages de discussion : 1,3,5,7,9,11,13,15,101,103,105, ou bien pour prendre en compte tous les espaces de nom excepté celui des catégories : !14 ;
- Config Title Match, ce champs permet à l'aide d'une expression rationnelle de filtrer les pages dont le titre valide l'expression rationnelle. Par exemple : A.* pour toutes les pages commençant dont le titre commence par A ;
- Config List Filter et Config Exact List Filter, ces champs permette d'indiquer en paramètre le chemin d'un fichier contenant un nom de page par ligne. Seules les pages précisées dans ce fichier seront chargées. Si c'est le paramétrage Exact qui est employé, le titre doit correspondre exactement, autrement le filtre vérifie s'il correspond au titre de l'article ou éventuellement de sa page de discussion ;
- Config Revision List Filter, ce champs permet de renseigner le chemin d'un fichier contenant en paramètre les numéros de révision à charger (une révision par ligne) ;
- Config Before Timestamp Filter et Config After Timestamp Filter, ces champs permettent de délimiter temporellement les données à importer en indiquant des dates limites de début et de fin au format yyyy-MM-dd'T'HH:mm:ss'Z'.
Une fois le composant paramétré, il suffit de renseigner les autres composants de la chaîne comme vous le faites habituellement et de lancer l'exécution.
Attention, si vous exportez le contenu traité par le composant, à l'aide du composant XmiWriter par exemple, à partir d'un dump compressé, prenez en compte que le volume de données risque d'être 20 à 100 fois supérieures à la taille originale du dump. Ainsi, il faut compter une vingtaine de Go minimum pour la version française de Wikipédia en ne considérant que les dernières révisions des articles.
La création de composants UIMA permettant d'accéder et tirer parti de Wikipédia offrirait de nouvelles perspectives au traitement des langues en offrant un accès aisé à cette formidable ressource que représente l'encyclopédie libre. Je compte m'atteler à la création de tels composants et vais tâcher de publier plusieurs billets décrivant ma démarche en cours.
Voici le cinquième billet, plus orienté technique de développement, qui discute de la gestion du projet avec Maven, permettant notamment de gérer automatiquement les dépendances à MWDumper et à Wikimodel.
Qu'est-ce que Maven ?
Maven est une sorte de super-gestionnaire de projet qui peut se charger d'à peu près tout : dépendances, compilation, packaging, lancement des tests unitaires, ... L'outil est disponible sur la plupart des distribution, pour ma part sous Ubuntu :
$ sudo aptitude install maven2
L'objectif de ce billet est d'expliquer comment, à l'aide de notre génial ingénieur de recherche, j'ai pu utilisé maven pour gérer la construction du collection reader pour Wikipedia.
Récupérer les dépendances
La première complication lorsque l'on souhaite compiler le collection reader ce sont les dépendances, il y en a trois :
- UIMA, mais ceux qui veulent utiliser le composant doivent d'ores et déjà avoir réglé ce problème ;
- le projet mwdumper de MediaWiki ;
- le sous-projet org.wikimodel.wem de WikiModel.
Par chance tous ces projets sont déjà gérés par maven ce qui va fortement nous faciliter la tâche. Les étapes à suivre sont les suivantes :
- Obtenir une version des sources de chacun des projets
- Les compiler avec maven
- Les installer dans le dépôt local de maven
Ainsi pour mwdumper :
$ svn co http://svn.wikimedia.org/svnroot/mediawiki/trunk/mwdumper ... $ cd mwdumper $ mvn compile ... $ mvn install ...
Une fois ces étapes terminées, un nouveau dossier doit apparaître dans votre dépôt local : ~/.m2/repository/org/wikimedia/mwdumper/ ; il doit contenir un dossier correspondant à la version compilée (1.16 pour moi) et dans ce dossier les fichiers suivants :
- mwdumper-1.16.jar
- mwdumper-1.16.pom
Il faut procéder de la même manière pour WikiModel :
$ svn co http://wikimodel.googlecode.com/svn/trunk/org.wikimodel.wem ... $ cd org.wikimodel.wem $ mvn compile ... $ mvn install ...
Vous devriez de la même manière voir apparaître dans votre dépôt local : ~/.m2/repository/org/wikimodel/org.wikimodel.wem/ ; il doit contenir une structure similaire.
Ces étapes sont nécessaires pour la suite car elles placent les dépendances dans le dépôt local de maven, là où il ira les chercher lors de la compilation.
Écriture du pom.xml
Revenons maintenant au composant UIMA. L'intelligence de Maven se configure dans un fichier à la racine du projet et nommé pom.xml.
Dans un premier temps, il faut définir le projet en lui donnant :
- Un identifiant de groupe (dans le cas où le projet appartiendrait à un groupe de projets) : groupId
- Un identifiant d'artefact, c-à-d de ce que le projet va produire : artifactId
- Spécifier une version : version
- Donner un nom et une description
- Renseigner les informations concernant les licences
- Spécifier le type de packaging que l'on souhaite obtenir
Dans un second temps, nous définissons les dépendances nécessaires à la construction de notre composant. Comme nous l'avons vu précédemment, il y en a plusieurs :
- UIMA, et plus précisément uimaj-core et uimaj-document-annotation
- WikiModel, et plus précisément org.wikimodel.wem
- MWdumper
Les dépendances se déclarent entre les tags <dependencies>, en indiquant notamment la version nécessaire.
Comme vous l'avez certainement remarqué, on a précisé que le projet dépendait d'UIMA, mais contrairement aux dépendances sur MWDumper et WikiModel, nous n'avons pas installé ces dernières dans le dépôt maven local. En fait Maven va être capable d'aller chercher tout seul ces dépendances grâce au dépôt maven mis en ligne par Apache UIMA. Il suffit de préciser l'existence de ce dépôt :
Finalement, on précise le processus de construction du composant entre les tags <build>. Dans nos cas cela revient tout simplement à préciser où aller chercher les sources, où placer les fichiers compilés et préciser ce qui doit être considérés comme des ressources et donc placé dans le Jar en plus des classes.
On utilisera de plus le plugin maven-compiler-plugin afin de préciser la version de Java que l'on souhaite pour la compilation.
Le pom.xml est suffisant à cette étape pour permettre de lancer la compilation du projet et le packaging.
$ mvn compile ...
Vous devriez constater que le dossier bin s'est peuplé des classes compilées.
$ mvn package ...
Vous devriez maintenant constater l'apparition d'un dossier target dans lequel vous trouverez notamment un Jar nommé : uima-mediawiki-loader-0.4.jar. Et voilà, dans l'état il est possible d'obtenir un Jar du projet à partir des sources sans trop de problèmes. Toutefois la première étape de récupération des dépendances me paraît trop contraignantes. Il est possible, à l'instar d'Apache UIMA, de mettre en place un dépôt contenant des versions compilées des dépendances afin que maven aille directement les chercher.
Mettre en place un dépôt pour les dépendances
Un dépôt maven ce n'est ni plus ni moins qu'un système de fichiers respectant une certaine structure et accessible par http (par exemple).
J'ai créé un dossier sur mon serveur que j'ai rendu accessible par http à l'aide d'Apache, puis j'y ai collé l'arborescence concernant mwdumper et wikimodel quiu était présente dans mon dépôt local :
- ~/.m2/repository//org/wikimedia/...
- ~/.m2/repository//org/wikimodel/...
Il y a une petite nuance tout de même, lorsque le dépôt est distant, les fichiers doivent être accompagnés de leurs checksums afin de vérifier que le téléchargement s'est bien déroulé. Le plus simple pour générer ces fichiers de checksums est de réitérer l'installation dans le dépôt maven local avec une option supplémentaire :
$ mvn install -DcreateChecksum=true ...
Vous trouverez alors dans le dépôt local les fichiers en *.md5 et *.sha1 qu'il faut également transférer sur le serveur.
Une fois que le dépôt distant est mis en place, il suffit de le déclarer dans le pom.xml :
Il est maintenant possible de compiler le composant sans avoir à récupérer les dépendances en amont. Tout se fait automatiquement et de manière transparente pour l'utilisateur... c'est assez plaisant.
Comme je suis un fainéant, je trouve que ce serait cool de pouvoir déployer automatiquement mon composant sur mon dépôt, c'est tellement pratique les dépôts !
Déployer le composant sur le dépôt
J'ai choisi de pouvoir déployer mon composant sur le dépôt par ssh, pour des questions de sécurité. Mais il est également possible de le faire par ftp. Le déploiement par ssh nécessite tout d'abord de pouvoir se connecter automatiquement au serveur par ssh à l'aide d'un échange de clé, puis il suffit de renseigner dans le pom.xml l'adresse du dépôt et dans ~/.m2/settings.xml de préciser les modalités de connexion au dépôt.
Connexion automatique par ssh
Je ne vais pas détailler ici comment déployer un serveur ssh et faire tourner un ssh-agent en local, il y a tout un tas de tutoriels disponibles sur internet pour ça. Ce qu'il faut juste retenir, c'est que maven ne se connectera au serveur ssh si les deux conditions suivantes sont remplies :
- Le serveur est connu de ssh (il est enregistré dans .ssh/know_hosts) ;
- La connexion peut se faire par échange de clés (pas de mot de passe).
Le plus simple pour s'assurer de tout cela est de se connecter directement manuellement au serveur :
- Si le serveur est inconnu, ssh demandera s'il doit être ajouté à la liste des hôtes connus : acceptez ;
- Si le serveur vous demande un mot de passe c'est qu'il ne connaît pas votre clé, il suffit de lui donner.
Copiez donc le contenu de votre clé publique que vous trouverez dans le fichier ~/.ssh/id_dsa.pub ou bien ~/.ssh/id_rsa.pub. Elle doit ressembler à quelque chose comme ceci :
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzqedhFIi8hy743U7pEvLMQvCEeAo/CxmLjF4jF2WguguN+U/4GsJrONvgoWMYXRn0zVMoHNpCEXQ+BT80ZTnv+MILu5elgFsE18bFA+7qjd454LwuZpoIoJOsCNyJKyGjy7ER5cZGN/z8G6cmSJTGauc270W7WJQELqKM3rfqPJH4FXPF9+WDP4UK/o7k54g36/3hHeBmqW++mpyEwkm0eT+GlBRlmP4NjVJACMoyYwl2S1Ep/m85aYR+95m3neHFZpUPmEyN52/Sod7ak28AHZ0M5oE/nRoUr1AAc0LzJw7BM327fAO6o7iHcfoIdo7pix2KLoteqT8tQIRQUmzxQ== grdscarabe@grdscarabe-desktop
Attention, cette clé se trouve sur le poste client à partir duquel maven se connaîtra !
Copiez donc cette clé dans le fichier ~/.ssh/authorized_keys, si ce fichier n'existe pas créez-le. Faites bien attention à ce qu'il soit dans le répertoire personnel de l'utilisateur que maven utilisera pour se connecter (le votre très certainement).
Une fois cette opération effectuée, vous devriez pouvoir vous connecter au serveur sans que ce dernier ne vous demande de mot de passe. Il se peut que si vous ayez protégé votre clé privée par un mot de passe, le ssh-agent vous le demande. Dans ce cas vous êtes de mon point de vue suffisamment au courant du problème pour ne pas lire cette section. Sinon vous êtes bien malin d'avoir mis un mot de passe :)
Déclaration du dépôt dans le pom.xml
Il suffit de déclarer dans le dépôt dans le pom.xml, nous l'appellerons ici uimafr-repository. Il est également nécessaire de charger l'extension wagon-ssh-external qui permet à maven de déployer par ssh :
Modalités de connexion au dépôt
Enfin, il faut localement configurer maven pour reconnaître le dépôt uimafr-repository. Cette configuration se fait par le fichier ~/.m2/settings.xml. S'il n'existe pas, créez-le puis copiez-collez y le contenu suivant :
En gros ce dernier permet de préciser quels sont les outils à utiliser pour la connexion ssh. Sous linux, nous utiliserons les outils ssh pour la connexion et scp pour le transfert de fichier.
Déploiement
Et voilà, maintenant pour déployer mon composant sur le dépôt, il me suffit de faire :
$ mvn deploy ...
Elle est pas belle la vie ?
Extensions possibles
Il y a bien des extensions possibles pour rendre maven encore plus pratique pour la gestion de ce projet. J'en vois notamment deux :
- La génération automatique des classes de types UIMA à partir de JCasGen ;
- L'empaquetage dans le même Jar du projet et des dépendances sur MWDumper et WikiModel.
Dans le premier cas, la solution au problème doit certainement se trouver du côté du ''exec-maven-plugin''. Dans le second cas, il faudrait aller voir du côté de ''maven-assembly-plugin''.
Nouvelle version du composant
Et je conclus ce looong billet en distribuant la nouvelle version, estampillée 0.4, du collection reader pour Wikipedia : par ici ! Vous trouverez les dépendances nécessaires à son fonctionnement dans le dépôt maven de uima-fr.
Vous pouvez tester le composant à l'aide du cpeGui :
$ UIMA_CLASSPATH=~/.m2/repository/uima/wikipedia/mwuima-loader/0.4/mwuima-loader-0.4.jar:~/.m2/repository/org/wikimedia/mwdumper/1.16/mwdumper-1.16.jar:~/.m2/repository/org/wikimodel/org.wikimodel.wem/2.0.7-SNAPSHOT/org.wikimodel.wem-2.0.7-SNAPSHOT.jar cpeGui
Bien sûr, si vous n'avez pas installé le composant avec maven, il faudra modifier en conséquence les chemins du UIMA_CLASSPATH.
Autres articles
Wikipedia est une incroyable source d'information, de données et plus généralement d'actes langagiers (utilisation du langage). Ce dernier point est très important pour nous autres chercheurs en traitement automatique des langues. En effet, nous avons besoin d'observer de très nombreux exemples d'utilisation du langage, que ce soit de manière automatique ou manuelle. Pour ce faire, nous compilons de vastes exemples d'utilisation du langage sous forme de corpus.
La création de composants UIMA permettant d'accéder et tirer parti de Wikipédia offrirait de nouvelles perspectives au traitement des langues en offrant un accès aisé à cette formidable ressource que représente l'encyclopédie libre. Je compte m'atteler à la création de tels composants et vais tâcher de publier plusieurs billets décrivant ma démarche en cours.
Voici le quatrième billet qui discute de l'analyse syntaxique du contenu des pages wiki pour la suppression des balises Wiki.
Analyse syntaxique des pages MediaWiki
Il existe plusieurs initiatives de programmes permettant d'interpréter la syntaxe de MediaWiki. Il y a le code PHP utilisé par MediaWiki et qui sert de référence, mais également plusieurs autres initiatives notamment en Java.
La plupart des initiatives Java ont pour objectif de produire des version XHTML ou PDF des pages en syntaxe wiki et ne donnent pas accès à l'arbre syntaxique de la page. Un programme en C basé sur Flex/Bison et développé dans le cadre du projet MediaWiki offre cette possibilité.
Parmi les initiatives en Java qui semblent intéressantes pour le collection reader UIMA :
- JAMWiki qui est plus ou moins une réécriture de MediaWiki en Java et dont l'analyseur syntaxique semble réutilisable ;
- WikiModel supporte plusieurs langages Wiki ;
- Bliki
J'ai tout d'abord essayé Bliki pour traiter la syntaxe de MediaWiki. Ce dernier s'est toutefois avéré assez complexe, notamment au niveau de son architecture, de telle façon que je n'ai pas réussi à obtenir ce que je voulais. Je me suis alors tourné vers WikiModel qui offre un analyseur syntaxique (Wiki Event Model (WEM)) au fonctionnement proche de SAX.
WikiModel pour MediaWiki
Le gros avantage de WikModel est qu'il offre directement un parseur pour MediaWiki : org.wikimodel.wem.mediawiki.MediaWikiParser. Le parseur analyse du code Wiki brute et, comme un parseur SAX classique, lance des évènements à une instance implémentant l'interface org.wikimodel.wem.IWemListener. J'ai choisi de créer une classe MediawikiCasConverter implémentant cette interface et gérant elle même le lancement du parseur sur les textes brutes extraits des révisions.
Les méthodes du IWemListener sont de deux types. Les premières sont des méthodes one shot, ie elles sont appelées une seule fois lorsqu'un élément est rencontré. Ce sont notamment celles qui concernent le texte et leur mise en forme :
- onEscape(String str)
- onSpace(String str)
- onSpecialSymbol(String str)
- onWord(String str)
- onReference(String str)
Les secondes sont des méthodes à la SAX en deux temps : begin et end. Ce sont notamment celles qui concernent la structuration du texte :
- beginHeader(int headerLevel, WikiParameters params)
- endHeader(int headerLevel, WikiParameters params)
- beginSection(int docLevel, int headerLevel, WikiParameters params)
- endSection(int docLevel, int headerLevel, WikiParameters params)
- beginParagraph(WikiParameters params)
- endParagraph(WikiParameters params)
- beginList(WikiParameters params, boolean ordered)
- endList(WikiParameters params, boolean ordered)
La plupart de ces méthodes ne font que des appels à une fonction de plus haut niveau qui collecte les données textuelles de la page et qui maintient l'index du CAS : addToContent. C'est notamment le cas pour la méthode onWord qui est appelée lorsque le parseur rencontre un nouveau mot :
J'ai choisi de transposer une partie des informations contenues dans les pages de Wikipedia sous la forme d'annotations. J'ai ainsi ajouté les types :
- Header pour les titres qui possède un attribut Level indiquant le niveau de titre ;
- Paragraph pour différencier les paragraphes ;
- Section pour repérer les sections même si je ne suis pas certain d'avoir bien compris le principe de section dans MediaWiki. Ce type possède les attributs Level pour le niveau de section (cf. niveau de titre), Parent pointant sur la section parente et Title pointant sur le Header correspondant à ladite section ;
- Link pour les liens divers et variés qui possède des attributs Label et Link pour respectivement l'étiquette du lien et son adresse.
En ce qui concerne les liens, j'ai choisi pour le moment d'ignorer les images qui me semblent apporter plus de bruit qu'autre chose.
La mise en place de ces annotations se fait assez facilement :
- Lors d'un appel à begin..., l'annotation est créée est stockée dans une liste, la plupart des informations excepté son index de fin est renseigné à ce moment ;
- Lors de l'appel correspondant à end..., la dernière annotation de la liste est récupérée et on fixe son index de fin (setEnd) ;
- Lorsque l'analyse est terminée, toutes les annotations sont accessibles par la méthode getAnnotations afin de les ajouter à l'index du CAS.
Cette approche permet de dédier toute la partie analyse à une classe. Si jamais l'on veut ignorer certaines annotations (ou toutes), il suffit de les filtrer au moment de leur récupérer par getAnnotations. L'extrait de code ci-dessous illustre ce fonctionnement pour les titres :
Je me suis rendu compte que le parseur posait des problèmes (heap overflow) sur des pages de certains espaces de noms. J'ai donc choisi de n'appliquer l'analyse syntaxique qu'aux pages de l'espace de nom 0 (espace de nom principal). Ceci est toutefois facilement modifiable dans la méthode uima.wikipedia.mwdumper.ThreadedMWDumper.writeStartPage.
Il reste pas mal d'améliorations possibles : prendre en compte toutes les mises en formes/structurations, prendre en charge les macros, rendre l'analyse syntaxique configurable. Toutefois, le composant est dans l'état actuel aussi complet et performant que je le souhaitais à l'origine. Il ne reste plus qu'à le tester de manière intensive. J'ai d'ailleurs deux trois cobayes en tête pour ça.
Nouvelle version du composant
Pas de nouvelle version du composant pour l'instant. Étant donné que les dépendances se sont multipliées, et que le composant est désormais suffisamment fonctionnel pour se voir estampillé 1.0 ou quelque chose du genre, je vais travailler un peu plus son packaging.
Autres articles
Wikipedia est une incroyable source d'information, de données et plus généralement d'actes langagiers (utilisation du langage). Ce dernier point est très important pour nous autres chercheurs en traitement automatique des langues. En effet, nous avons besoin d'observer de très nombreux exemples d'utilisation du langage, que ce soit de manière automatique ou manuelle. Pour ce faire, nous compilons de vastes exemples d'utilisation du langage sous forme de corpus.
La création de composants UIMA permettant d'accéder et tirer parti de Wikipédia offrirait de nouvelles perspectives au traitement des langues en offrant un accès aisé à cette formidable ressource que représente l'encyclopédie libre. Je compte m'atteler à la création de tels composants et vais tâcher de publier plusieurs billets décrivant ma démarche en cours.
Voici le troisième billet qui discute du filtrage des données à charger : articles, révision, ...
Filtres de MWDumper
L'outil mwdumper inclut un certain nombre de filtres commandables à partir de la ligne de commande :
- LatestFilter permet de ne conserver que la dernière révision d'une page ;
- NamespaceFilter permet de ne conserver que les articles qui appartiennent à un espace de nom particulier (passé en paramètre) ;
- NotalkFilter permet d'ignorer les pages de discussion ;
- TitleMatchFilter permet de ne conserver que les pages dont le titre valide une expression rationnelle donnée en paramètre ;
- ListFilter permet de ne conserver que les pages dont le titre de la page de données ou de discussion est présent dans un fichier passé en paramètre (un nom de page par ligne) ;
- ExactListFilter est identique au filtre précédent si ce n'est que son application est plus stricte car seul le titre de la page est considéré ;
- RevisionListFilter reprend le principe des filtres précédents si ce n'est qu'il s'applique aux identifiants de révisions ;
- BeforeTimeStampFilter ne conserve que les données produites avant une date passée en paramètre ;
- AfterTimeStampFilter ne conserve que les données produites après une date passée en paramètre ;
Voir le billet Insérer plusieurs copies locales de Wikipedia dans une base PostgreSQL pour un cas d'utilisation de ces filtres. La combinaison de ces filtres permet de contrôler avec précision les données à charger, nous allons donc nous en contenter.
Paramétrage du composant
On peut classer les filtres en deux familles : ceux qui nécessitent des paramètres et ceux qui n'en nécessitent pas. J'ai donc choisi pour le moment d'utiliser des paramètres booléens pour les filtres sans paramètre, et des paramètres chaînes de caractères pour les autres.
L'activation des paramètres booléens suffit à activer les filtres correspondant : IgnoreTalks et LatestRevisionOnly.
Pour activer les autres filtres il suffit de les configurer en renseignant les champs dédiés. Si les champs restent non renseignés alors les filtres ne sont pas activés : ConfigNamespacesFilter, ConfigTitleMatch, ConfigListFilter, ConfigExactListFilter, ConfigRevisionListFilter, ConfigBeforeTimestampFilter, ConfigAfterTimestampFilter.
Nouvelle version
Voici une nouvelle version du collection reader pour Wikipédia, estampillée 0.2, qui ne prend toujours pas en compte la syntaxe, mais qui permet de filtrer le type de contenu à charger à partir du dump XML. Pour utiliser le composant, il est nécessaire d'avoir le jar de mwdumper dans le classpath.
