Blog d'un jeune chercheur en TAL

Benoît XVI m'énerve profondément

Fabien Poulard — Sat, 04 Sep 2010 02:11:00 +0200

Je n'aime pas la religion, il s'agit à mon avis du pire système d'aliénation mis en place depuis l'existence de l'homme. Mon ressentiment est indifférent : je déteste les trois monothéismes principaux (qui reposent de toute façon sur le même Livre) avec la même vigueur, et par extension toute forme de gouvernance qui élève un être supérieur infaillible et qui décide de la morale et de la loi sans consulter le peuple. Je pense que l'apathéisme correspond le mieux à ma condition.

Vous voilà prévenus, ce n'est pas la peine de lire la suite si vous pensez qu'elle va vous blesser. Je respecte que chacun, en privé, pratique sa religion du moment qu'il ne cherche pas à propager ses croyances au reste de la société. Nul besoin de vous laisser offenser si vous êtes un fervent croyant, ce n'est pas mon but.

L'omniprésence de la religion musulmane telle que présentée par les médias (mais qui à mon avis n'est pas aussi marquée que cela) associée à l'érosion continue du christianisme en Europe déplaît à la paposphère. On savait Benoît XVI bien plus radical que ne l'était Jean-Paul II, il l'a démontré une fois de plus dans un message en amont de la 26e Journée Mondiale de la Jeunesse.

La quintessence du message transmis se résume en cette phrase :

il y a un fort courant « laïciste », qui veut supprimer Dieu de la vie des personnes et de la société, projetant et tentant de créer un «paradis» sans Lui. Or l’expérience enseigne qu’un monde sans Dieu est un «enfer» où prévalent les égoïsmes, les divisions dans les familles, la haine entre les personnes et les peuples, le manque d’amour, de joie et d’espérance.

Selon Benoît XVI il faut craindre le laïcisme qui cherche à "supprimer Dieu de la vie des personnes et de la société". Contrairement au christianisme qui appelle à répandre la bonne nouvelle (une forme de diffusion où l'on ne peut évidemment pas se permettre de jeter les pélerins dans une corbeille à spam), le laïcisme cherche uniquement à retirer Dieu de la société afin que chacun puisse choisir son Dieu et vivre sa religion en privé. La définition de wikipédia est très claire sur ce point :

Le laïcisme est un courant d'idées qui vise à protéger activement la vie publique de toute ingérence religieuse. Si la laïcité applique avec une certaine souplesse la séparation de l'État et des Églises, le laïcisme souhaite réduire la vie religieuse des citoyens à la seule sphère privée, hors de toute manifestation sociale et publique.

Benoît XVI fait usage ici de paralogisme et d'amalgame à des fins de manipulation. Ces discours manipulateurs sont malheureusement assez courants de nos jours.

La phrase qui m'a fait bondir et qui est à l'origine de ce billet (qui traîne en longueur) est celle-ci : "toutes les valeurs qui fondent la société proviennent de l'Évangile, comme le sens de la dignité de la personne, de la solidarité, du travail et de la famille". Mais bien sûr... Je me permets donc un petit rappel de catéchèse en piochant aléatoirement (enfin, pas vraiment, moi aussi j'ai envie de jouer un peu au manipulateur) :

à propos de la dignité de la personne, je citerais les versets 1R.21.28-29 : Alors la parole de Yahvé fut adressée à Élie le Tishbite en ces termes : " As-tu vu comme Achab s'est humilié devant moi ? Parce qu'il s'est humilié devant moi, je ne ferai pas venir le malheur pendant son temps ; c'est au temps de son fils que je ferai venir le malheur sur sa maison. ". Je ne suis pas sûr que la nécessité de s'humilier pour éviter un châtiment soit la meilleure leçon de dignité humaine. Je préfère l'article premier de la déclaration des droits de l'homme : Christianisme : 0 - République des Lumières : 1

à propos de la solidarité, je citerais les versets Gn.7.1 : Le Seigneur dit à Noé : « Entre dans l'arche, toi et ta famille, car j'ai constaté que tu es le seul parmi tes contemporains à m'être fidèle.. Je traduis : laisse tomber tes semblables et sauve ta peau. Là encore j'ai une préférence pour notre système de sécurité sociale (mutualisation des coûts de santé, retraites, ...) : Christianisme : 0 - République des Lumières : 2

à propos de la famille, je reprendrais les fameux versets concernant le sacrifice d'Isaac Gn.22.2 : Dieu reprit : « Prends ton fils Isaac, ton fils unique que tu aimes tant, va dans le pays de Moria, sur une montagne que je t'indiquerai, et là offre-le-moi en sacrifice. ». N'hésite pas à égorger ton fils unique comme un agneau pour l'amour de ton Dieu, score sans appel : Christianisme : 0 - République des Lumières : 3

puisque je suis sympa j'accorde une égalité sur le thème du travail avec le verset Sir.34.27 : C'est commettre un assassinat que de priver un ouvrier de son salaire.

Score final : Christianisme : 1 - République des Lumières : 4 ; victoire par KO de notre République. Ses valeurs sont majoritairement issues des réflexions philosophiques de Platon qui a vécu plus de 300 ans avant J.C., c-à-d bien avant l'évangélisation massive de l'Europe. Avant cette évangélisation (ces fameuses racines chrétiennes) la pax romana nous offrait les aqueducs, une infrastructure routière, l'hygiène (bains et latrines), des ingénieurs civils,... Suite à l'évangélisation nous avons eu droit à 1400 ans d'obscurantisme, de condamnation de la science et du progrès. Il faudra attendre les humanistes qui ont remis l'homme au centre du monde en piochant dans les préceptes antiques grecs. Le laïcisme est né de ce besoin de replacer l'homme au centre du monde, et c'est une bonne chose !

En guise de conclusion, je me permets de placer le verset Ma.3.5 :

le Seigneur de l'univers déclare : «Je viendrai au milieu de vous pour vous juger. Je m'empresserai d'accuser ceux qui pratiquent la magie, qui commettent l'adultère, qui prononcent de faux serments, qui retiennent le salaire des ouvriers, qui oppriment les veuves et les orphelins ou qui font du tort aux étrangers, tous ceux qui ne tiennent aucun compte de moi.» »

Notez que toutes ces fautes sont placées au même niveau. Rien sur l’assassinat... qui est tout de même l'atteinte la plus grave qui puisse être faite à un être humain... sans doute les meurtriers sont à classer dans ceux qui ne tiennent aucun compte de moi.

Calculer le recouvrement de deux textes avec NLTK

Fabien Poulard — Thu, 26 Aug 2010 19:00:00 +0200

Mon travail de thèse, sobrement intitulée Approches par calcul de similarité inter-documentaire pour la détection de dérivations de texte, consiste à évaluer la probabilité qu'un texte dérive d'un autre. Une des applications, que je déteste mais qui a l'avantage de parler à la plupart des gens, est la détection de plagiat.

Une approche, naïve mais simple à mettre en œuvre, consiste à calculer le nombre de mots que deux textes partagent. Voici une proposition d'implémentation d'une telle technique tirant partie de la bibliothèque NLTK.

Le calcul de la couverture en terme de mots de deux textes n'a rien de bien compliqué dans la mesure où :

il nous est possible de découper le texte en mots ;
nous savons compter le nombre de mots qu'ils ont en commun.

Pour le découpage en mots, nous allons utiliser la bibliothèque NLTK (j'utilise la version bêta de la 2.0) qui propose une méthode word_tokenize :

import nltk
nltk.word_tokenize(u"A sentence to be tokenized")
 
[u'A', u'sentence', u'to', u'be', u'tokenized']

Le tokeniseur est loin d'être parfait, notamment pour les textes qui ne sont pas de l'anglais, mais il fonctionne suffisamment bien pour l'utilisation que nous en avons. Ce serait beaucoup plus problématique pour une tâche de recherche d'information par exemple.

Nous passerons donc le contenu des fichiers à comparer à cette fonction qui nous retourne la liste des mots correspondant. Il nous faut alors calculer l'intersection des deux listes de mots.

Les objets set offrent une méthode intersection qui ferait l'affaire. Cependant la conversion en un ensemble va faire disparaître les doublons, or nous aimerions avoir un recouvrement aussi précis que possible. Nous définissons donc une fonction qui va calculer l'intersection de deux listes. Elle peut certainement être largement améliorée (ne pas hésiter à proposer une correction), mais suffira pour l'exemple :

def intersect_list(lst1, lst2):
	"""
	Calcule l'intersection entre deux listes
	"""
	# Intersection
	inter = []
	# Calcul des éléments en commun
	common = set(lst1).intersection(lst2)
	# Construction de la liste commune
	for e in common:
		nbe = min(lst1.count(e), lst2.count(e))
		for i in range(nbe):
			inter.append(e)
	return inter

Nous avons désormais en main tous les éléments nécessaire pour écrire un petit script qui calculera le taux de recouvrement en mots entre deux fichiers textes.

Voici le script complet pour ceux que ça intéresse :

#! /usr/bin/python
# -*- coding: utf-8 -*-
#
# Script permettant de calculer le taux de recouvrement en mots entre les
# deux textes passés en paramètre.
 
import nltk
import os.path
import sys
import codecs
 
def loadTxt(fic):
	"""
	Charge le contenu textuel du fichier en paramètre
	"""
	fh  = codecs.open(fic, "r", "utf-8", errors='ignore')
	txt = fh.read()
	fh.close()
	return txt
 
def intersect_list(lst1, lst2):
	"""
	Calcule l'intersection entre deux listes
	"""
	# Intersection
	inter = []
	# Calcul des éléments en commun
	common = set(lst1).intersection(lst2)
	# Construction de la liste commune
	for e in common:
		nbe = min(lst1.count(e), lst2.count(e))
		for i in range(nbe):
			inter.append(e)
	return inter
 
# Vérifie qu'il y a bien deux fichiers passés en paramètre du script
if len(sys.argv) == 3:
	# Charge les textes des fichiers
	txt1 = loadTxt(sys.argv[1])
	txt2 = loadTxt(sys.argv[2])
	# Tokenisation en mots
	txt1toks = nltk.word_tokenize(txt1)
	txt2toks = nltk.word_tokenize(txt2)
	# Calcul de la couverture
	incommon = intersect_list(txt1toks, txt2toks)
	# Affichage
	print "Couverture de %s par rapport à %s" % (sys.argv[1],sys.argv[2])
	print "\t%f" % (float(len(incommon))/len(txt1toks))
	print "Couverture de %s par rapport à %s" % (sys.argv[2],sys.argv[1])
	print "\t%f" % (float(len(incommon))/len(txt2toks))
else:
	print "Utilisation :"
	print "\t%s <fichier 1> <fichier 2>" % sys.argv[0]

Bien entendu, le taux de recouvrement en mots n'est pas très performant pour évaluer le degré de dérivation entre deux textes. Une manière de l'améliorer serait de calculer le taux de recouvrement de n-grammes plutôt. J'attends vos propositions :)

Migration...

Fabien Poulard — Wed, 25 Aug 2010 04:06:00 +0200

Je profite des "vacances" (cette période assez floue où je rédige ma thèse et où le reste du monde est en vacances) pour m'occuper de la migration de mon serveur. Je passe de l'offre originale Dédibox à la nouvelle offre premier prix d'Online (nouveau nom de Dédibox).

Il y aura certainement des petits soucis d'ici la fin de la migration...

Du bon usage des ressources dans UIMA

Fabien Poulard — Sat, 17 Jul 2010 01:46:00 +0200

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.

Installer Subclipse pour Eclipse Helios

Fabien Poulard — Tue, 13 Jul 2010 18:00:00 +0200

Installation d'Eclipse

Pour Debian Squeeze, Eclipse Helios n'est pas encore packagée. Je métais contenté de Galileo jusqu'à maintenant mais Subclipse a, pour une raison que je n'arrive toujours pas à m'expliquer, cessé de fonctionner. Après multiples vaines tentatives de retrouver un environnement de travail fonctionnel, j'ai aboutit à Eclipse Helios + Subclipse.

J'ai choisi d'installer Eclipse dans mon home, l'installation dans /opt ou un autre répertoire pour lequel mon utilisateur n'a pas les droits d'écriture s'étant avéré, encore une fois, problématique. Pour l'installation, rien de bien sorcier :

On récupère l'archive qui va bien sur le site d'Eclipse
On décompresse dans son répertoire personnel : tar -czvf eclipse-java-helios-linux-gtk-x86_64.tar.gz -C ~/

Suite à mes nombreuses expérimentations sans succès, je me suis permis de modifier plusieurs variables de configuration dans le eclipse.ini de sorte qu'il ressemble désormais à ça :

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.0.v20100503
-product
org.eclipse.epp.package.java.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-debug
-consoleLog
-vm
/usr/lib/jvm/java-6-sun/bin/java
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XX:MaxPermSize=256m
-Xms40m
-Xmx384m
-Djava.net.preferIPv4Stack=true
-Djava.library.path=/usr/lib/jni

Les éléments les plus importants étant :

-debug et -consoleLog pour afficher plein de jolis messages d'information lorsqu'on lance l'application depuis une console ;
-vm /usr/lib/jvm/java-6-sun/bin/java qui indiquer à Eclipse d'utiliser la JVM de Sun pour son exécution ;
-Djava.net.preferIPv4Stack=true pour parer ce petit problème ;
-Djava.library.path=/usr/lib/jni pour indiquer à la JVM où aller regarder pour les bibliothèques natives.

Ce dernier point est le plus important, il est nécessaire pour la détection correcte de javaHL par la suite.

Installation de Subclipse

Un truc vraiment sympa avec Eclipse Helios c'est l'apparition du Eclipse Marketplace !

Pour le lancer : Help > Eclipse Marketplace ...

Sélectionnez l'Eclipse Marketplace. Il est possible que l'installation fonctionne également avec le catalogue de Yoxos, mais je ne l'ai pas testé.
Dans le champs de recherche, tapez Subclipse
Dans la liste des résultats, sous l'entrée Subclipse, cliquez sur Install
... le reste suit la procédure habituelle d'installation de paquets, conservez toutes les entrées proposées.

Lorsque l'installation est terminée et avant de redémarrer Eclipse, vous devez installer la partie native de JavaHL. Pour ce faire, sous Debian Squeeze :

sudo aptitude install libsvn-java

Vérifiez bien que vous avez indiqué à la JVM comment accéder aux librairies natives : entrée -Djava.library.path=/usr/lib/jni dans le eclipse.ini

Vous pouvez désormais relancer Eclipse. Faites un clique-droit dans l'explorateur de projets, puis un Import. Vous devriez voir apparaître dans la liste un dossier SVN contenant une entrée Checkout Projects from SVN... vous n'avez plus qu'à suivre les instructions.

"Le réseau n'est pas accessible" incongrue dans Eclipse (ou n'importe quelle application Java)

Fabien Poulard — Tue, 29 Jun 2010 15:14:00 +0200

Depuis ma dernière mise-à-jour dans Debian Squeeze, je me suis aperçu qu'Eclipse (ou bien n'importe quelle application Java) n'était plus en mesure de se connecter au réseau. L'application retourne inéluctablement le message "Le réseau n'est pas accessible", quand bien même toutes les autres applications se connectent sans problème.

Apparemment ce comportement est dû à l'utilisation exclusive d'IPv6 dans Java (JVM Sun ou OpenJDK indifféremment)... ce qui sur les réseaux toujours en IPv4 ne mène à rien, et correspond effectivement à un réseau inaccessible.

La solution consiste à passer l'option -Djava.net.preferIPv4Stack=true à la JVM à son lancement. Pour Eclipse, il suffit d'ajouter cette ligne au fichier eclipse.ini (/etc/eclipse.ini) pour Debian.

La discussion concernant ce bug chez Debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560142

Debian : échec du lancement des applications graphiques en root

Fabien Poulard — Tue, 22 Jun 2010 21:05:00 +0200

Je viens tout juste de quitter Ubuntu qui commençait sérieusement à m'agacer avec ses versions pas vraiment finies et ses mises-à-jour de version qui plantent tout. Alors je suis revenu sous la distribution reine : Debian.

Le premier petit accroc que je viens de rencontrer concerne le lancement de l'outil update-manager. Lorsque que je le lance à partir de ma zone de notification, il m'invite à taper mon mot de passe afin de passer root et de s'exécuter, puis se crache lamentablement avec un Failed to run update-manager as user root, suivi d'un petit Failed to communicate with gksu-run-helper.

Le problème vient de l'utilisation de su pour l'authentification, il suffit de le remplacer par sudo. Pour ce faire :

Lancez l'outil de configuration gksu-properties (à partir d'une console)
Placez l'entrée Authentication mode sur sudo
Fermez, c'est corrigé :)

Je ne sais pas si c'est un problème dû à quelques fichiers de configurations restant d'Ubuntu dans mon home, mais c'est un peu gênant. Il faudrait peut-être le remonter aux développeurs Debian.

51e billet... un peu de fun : mettre en place une fausse webcam sous Ubuntu

Fabien Poulard — Fri, 02 Apr 2010 00:44:00 +0200

Pour mon 51e billet sur ce blog, je me suis dit que j'allais faire quelque chose d'un peu plus détendu que d'habitude. Voici un petit tutoriel pour installer une fausse webcam sous Ubuntu Karmic.

À quoi ça sert une fausse webcam ? Potentiellement à plusieurs choses :

Faire passer le flux de votre vraie webcam qui n'est pas reconnue par Flash dans une fausse reconnue elle par Flash (cherchez pas ^^)
Balancer votre dernier film de vacance en streaming à votre mamie par la webcam, sans mettre en place de choses compliquées
Faire croire à votre rencard internet que vous êtes Bard Pitt (ou Angelina Jolie... c'est selon le rencard)

Pour ce tour de passe-passe numérique j'utilise le logiciel WebcamStudio. Le principe est assez simple, ça crée un faux périphérique V4L qui transmet le flux vidéo que vous souhaitez.

La première étape est d'ajouter le dépôt qui va bien dans '/etc/apt/sources.list'' :

deb http://apt.dolphinaura.studenthotspot.net/ jaunty main

Même si c'est marqué jaunty, le paquet fonctionne pour Karmic. C'est l'avantage d'avoir assez peu de dépendances (gstreamer mis à part). Ensuite ajoutez la clé du développeur :

$ sudo apt-key adv --keyserver keys.gnupg.net --recv-keys 44F9E03A

Vous pouvez alors faire une mise à jour de la liste des paquets et vérifier que le paquet webcamstudio est présent :

$ sudo aptitude update
...
$ aptitude show webcamstudio

Vous pouvez maintenant l'installer :

$ sudo aptitude install webcamstudio

Une fois l'installation effectuée, ajoutez-vous au groupe video (manuellement en éditant /etc/group ou bien à l'aide des outils graphiques).

Vous pouvez alors l'application après vous êtes assuré que vous apparteniez bien au groupe video : soit en passant par le menu, soit en tapant webcamstudio dans une console.

Parcours des annotations couvertes par une autre annotation

Fabien Poulard — Thu, 01 Apr 2010 11:11:00 +0200

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 :

// Récupération des index
AnnotationIndex annAIdx = (AnnotationIndex) jcas.getAnnotationIndex(A.type);
AnnotationIndex annBIdx = (AnnotationIndex) jcas.getAnnotationIndex(B.type);
// On recherche ''A:3''
FSIterator annAIt = annAIdx.iterator();
while (annAIt.hasNext()) {
  A monA3 = (A) annAIt.next();
  // On récupére l'itérateur sur les annotations B couvertes par A3
  FSIterator annBSousA3It = annBIdx.subiterator(monA3);
  while (annBSousA3It.hasNext()) {
    // On récupére successivement B4, B5 et B6
    B annB = (B) annBSousA3It.next();
    System.out.println("Sous A3 : "+annB);
  }
}

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 :

/**
 * 
 * This method provides an iterator over typed annotations that either 
 * have an offset embedded in that of a given annotation in a document, 
 * or have the same offset as these annotation. 
 * 
 * @param theDocument  the document in which stand the source and
 *                                         target annotations
 * @param theAnnotation  the source annotation under which target 
 *                                         annotations that have to be drawn out
 * @param theType            the type of the target annotations that have 
 *                                         to be drawn out from the document under 
 *                                         the source annotation
 * @param isStrict              the boolean that defines the offset matching,
 *                                         offsets strictly equal if isStrict is true, begin 
 *                                         offsets greater or equal and end offsets less 
 *                                         or equal otherwise.  	
 * @return                           the iterator over the type theType annotations 
 *                                          which stand under the annotation theAnnotation 
 *                                          in the document theDocument 
 * 
 * @author Fabien Poulard
 * @author Jérôme Rocheteau
 * 
 * @license Apache 2.0
 */
public FSIterator subiterator(JCas theDocument, Annotation theAnnotation,Type theType,boolean isStrict) {
	// Ajout: déclaration de la variable type
	Type theAnnotationType = theAnnotation.getType();
	// On utilise le constraint factory
	ConstraintFactory theConstraints = theDocument.getConstraintFactory();
	// On définit les contraintes sur le début de l'annotation
	FSIntConstraint beginConstraint = theConstraints.createIntConstraint();
	if (isStrict) { 
		beginConstraint.eq(theAnnotation.getBegin());
	} else {
		beginConstraint.geq(theAnnotation.getBegin()); 
	}
	Feature beginFeature = theAnnotationType.getFeatureByBaseName("begin");
	FeaturePath beginPath = theDocument.createFeaturePath();
	beginPath.addFeature(beginFeature);
	FSMatchConstraint begin = theConstraints.embedConstraint(beginPath,beginConstraint);
	// ... puis sur la fin de l'annotation
	FSIntConstraint endConstraint = theConstraints.createIntConstraint();
	if (isStrict) {
		endConstraint.eq(theAnnotation.getEnd());
	} else {
		endConstraint.leq(theAnnotation.getEnd());
	}
	Feature endFeature = theAnnotationType.getFeatureByBaseName("end");
	FeaturePath endPath = theDocument.createFeaturePath();
	endPath.addFeature(endFeature);
	FSMatchConstraint end = theConstraints.embedConstraint(endPath, endConstraint);
	// JR: on définit une contrainte sur le type d'annotation
	FSTypeConstraint typeConstraint = theConstraints.createTypeConstraint();
	typeConstraint.add(theType); // 
	FeaturePath typePath = theDocument.createFeaturePath();
	FSMatchConstraint type = theConstraints.embedConstraint(typePath, typeConstraint);
	// On combine les contraintes
	FSMatchConstraint beginAndEnd = theConstraints.and(type,theConstraints.and(begin, end));
	// On génère un itérateur respectant ces contraintes
	FSIterator filteredIterator =
	theDocument.createFilteredIterator(theDocument.getAnnotationIndex().iterator(), beginAndEnd);
	return filteredIterator;
}

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.

Tests unitaires pour UIMA avec UUTUC

Fabien Poulard — Tue, 16 Mar 2010 15:45:00 +0100

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 :

AnalysisEngine engine = 
  AnalysisEngineFactory.createAnalysisEngineFromPath("descriptors/tutorial/ex1/RoomNumberAnnotator.xml");
JCas jCas = 
  AnalysisEngineFactory.process(engine, "data/WatsonConferenceRooms.txt");

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 :

import org.junit.Test;
import static org.junit.Assert.*;
...
/**
 * This class defines the tests for the main methods of the Shingle class.
 */
public class ShingleTest {
  ...
  /**
   * This method just checks that the isComplete method works
   * @throws InvalidShingleException 
   * @throws OverloadShingleException 
   */
  @Test
  public void completeness() throws InvalidShingleException, OverloadShingleException {
	Shingle s1 = new Shingle(2);
	assertFalse( s1.isComplete() ); // before any adding
	s1.add( theShingleItems[0] );
	assertFalse( s1.isComplete() ); // after a first adding
	s1.add( theShingleItems[0] );
	assertTrue( s1.isComplete() ); // should be complete by now
  }
  ...
}

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 :

/** Static data for testing */
private static String CAS_CONTENT = 
   "Suisse : inauguration d'une nouvelle synagogue, une première depuis 50 ans";
private static Integer[][] CAS_OFFSETS = { {0,6}, {9,21}, {22,24}, {24,27}, 
   {28,36}, {37,46}, {48,51}, {52,60}, {61,67}, {68,74} };
...
/**
 * This method is used to set up the testing environment, creating the
 * data necessary for the different tests methods.
 */
@Before 
public void setUp() throws UIMAException, IOException, ShinglingTestingException {
	// Set up a CAS with a couple of shingle items in
	TypeSystemDescription tsd = TypeSystemDescriptionFactory
			.createTypeSystemDescription("shingling-ts");
	theTestingCas = JCasFactory.createJCas(tsd);
	theTestingCas.setDocumentText(CAS_CONTENT);
	for(Integer[] idx: CAS_OFFSETS) {
		AnnotationFactory.createAnnotation(theTestingCas, 
						idx[0], idx[1], ShingleItem.class) );
	}
}

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 :

<repository>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
  <id>uutuc-googlecode</id>
  <name>uutuc Google Code repository</name>
  <url>http://uutuc.googlecode.com/svn/repo/</url>
</repository>
...
<!-- UUTUC for testing -->
<dependency>
  <groupId>org.uutuc</groupId>
  <artifactId>uutuc</artifactId>
  <version>0.9.10</version>
  <optional>false</optional>
  <scope>test</scope>
</dependency>
<!-- JUnit 4 for testing -->
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.3.1</version>
  <scope>test</scope>
</dependency>

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 :

<!-- Testing -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <reportFormat>brief</reportFormat>
    <useFile>false</useFile>
  </configuration>
</plugin>

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 ;)

Corpus des discours de Nicolas Sarkozy (MÀJ)

Fabien Poulard — Sat, 13 Mar 2010 23:08:00 +0100

Dans ce billet, j'avais distribué un corpus des discours de Nicolas Sarkozy. Depuis, le président a bien entendu prononcé un certain nombre de nouveaux discours. J'ai complété le corpus constitué à l'époque en conséquence.

Ces différents discours sont disponibles sur le site de l'Élysée, leur téléchargement, utilisation et distribution sont permis. En effet, les discours publics ne sont couverts par aucun droit d'auteur (cf. mentions légales d'Elysee.fr et article L.122-5 du Code de Propriété intellectuelle alinéa 3c).

Le corpus en lui-même est placé sous licence LGPL-LR en tant qu'œuvre dérivée des discours originaux. Merci donc de respecter cette licence et de me citer si jamais vous utilisez le corpus tel quel. Le corpus distribué contient :

les discours originaux au format PDF
une conversion propre des discours originaux en texte brut
un nettoyage et une structuration XML des discours (extraction des titres, de la date, ...)

Le tout réorganisé chronologiquement. Les fichiers sont en effet préfixés de la date de prononciation du discours.

Je distribue deux versions du corpus :

version complète (61Mo)
version sans les PDF (5,3MMo)

J'ai placé dans les fichiers d'archive un fichier contenant tous les liens vers les versions originales en PDF des discours sur le site de l'Élysée. Préférez donc la version sans PDF étant donné que vous pourrez facilement récupérer ces derniers sur le site de l'Élysée qui a une meilleur bande passante à mon avis !

Utiliser Bazaar au travers de Web DAV

Fabien Poulard — Tue, 09 Mar 2010 14:42:00 +0100

Dans le cadre de mon cours sur les outils pour le travail collaboratif, je fais travailler tous mes étudiants ensembles sur un même projet. Ces derniers sont alors invités (fortement) à utiliser plusieurs outils dans le cadre de leur collaboration : messagerie instantanée (IRC), wiki et gestionnaire de tickets (Trac) et un gestionnaire de version décentralisé (bazaar).

Avant je leur faisais utiliser subversion qui a un module Apache dédié et qui est pris en charge par défaut dans Trac. La nouveauté de cette année c'est l'utilisation de Bazaar...

Pourquoi un serveur pour Bazaar ?

Contrairement à subversion, Bazaar est un gestionnaire de version décentralisé, ce qui signifie qu'il n'existe pas a priori de dépôt de référence auquel se réfèrent tous les développeurs. Au contraire, chaque développeur possède son propre dépôt (sa propre branche) et l'échange de code entre développeurs se fait par des merge des branches des deux développeurs.

J'ai toutefois fait le choix de proposer aux étudiants de pouvoir héberger leur branche sur un serveur. Ces derniers sont en effet baladés entre les différentes salles de travaux pratiques et entre leurs machines personnelles. Il aurait été possible de leur faire placer leur dépôt sur une clef usb, mais le choix du serveur me semble plus pertinent pour plusieurs raisons :

Je garde une trace de toutes leurs activités, ce qui m'aide dans la notation du projet ;
Ils ne peuvent pas égarer le serveur, contrairement à la clé usb ;
Pédagogiquement ceci leur permet de se confronter aux notions de branches parentes et ainsi distinguer le push du commit.

Pourquoi Web DAV ?

Il existe plusieurs possibilités pour faire tourner un serveur bazaar, la plus simple étant très certainement d'encapsuler les commandes du protocole bazaar dans une connexion ssh. Toutefois cette solution n'était pas souhaitable pour deux raisons :

Les connexions ssh ne passent pas depuis les salles de TP ;
Je ne voulais pas offrir un accès ssh à mon serveur aux étudiants ;

Je me suis donc tourné vers l'encapsulation dans HTTP qui reste tout de même le protocole passe partout.

Mise en place

Activation de l'accès DAV

Tout d'abord, il faut activer l'accès DAV au répertoire qui contiendra les différentes branches bazaar. Ceci se fait dans Apache 2 en plusieurs temps.

Tout d'abord, il faut activer le module dav_fs qui est normalement installé par défaut (si ce n'est pas le cas, installez-le) :

$ sudo a2enmod dav_fs
 Considering dependency dav for dav_fs:
 Module dav already enabled
 Enabling module dav_fs.
$ sudo /etc/init.d/apache2 restart
...

Il faut ensuite déclarer le répertoire à exporter par DAV, en éditant le fichier de configuration de votre virtual host :

  #########
  #         Depots Bazaar
  Alias /bzr /home/www-data/bzr_repositories
  <Location /bzr>
    Dav On
    # Bzr specific
    DirectorySlash Off
    DavDepthInfinity on
    # Auth
    AuthName DAV
    AuthBasicProvider file
    AuthzGroupFileAuthoritative On
    AuthUserFile /vers/le/fichier/htpasswds
    AuthGroupFile /vers/le/fichier/htgroups
    # Only for authenticated users
    Require valid-user
   </Location>

et recharger la configuration d'Apache :

$ sudo /etc/init.d/apache2 reload

Attention pour que cette configuration fonctionne, il faut que l'URI /bzr soit accessible. Par exemple, si vous utilisez Trac et que ce dernier surveille l'URI racine /, vous ne pourrez jamais accéder à /bzr.

Dépôt partagé

Étant donné que les étudiants vont partager entre leurs branches une grosse partie du code, il semble pertinent de tirer parti d'un dépôt partagé. Ce dernier se crée directement sur le serveur :

$ cd racine/du/depot/
$ bzr init-repo --trees .

Personnellement bzr me retourne une erreur No handlers could be found for logger "bzr", mais elle semble sans incidence. Une fois le dépôt partagé créé, il faut créer les "véritables" dépôts :

$ cd racine/du/depot/
$ bzr init dev

Utilisation

Par défaut, bzr ne gère pas l'accès par WebDAV, il est nécessaire d'installer le plugin bzr.webdav :

$ sudo aptitude install bzr-webdav

ou si le paquet n'existe pas pour votre distribution :

$ bzr co lp:bzr.webdav
$ cd bzr.webdav
$ python setup.py build
...
$ cp -R cp -R build/lib/bzrlib/plugins/webdav/ ~/.bazaar/plugins/

Pour s'assurer que le plugin est bien détecté :

$ bzr plugins
...
webdav 1.12.1
    An http transport, using webdav to allow pushing.
...

À noter que ce dernier ne fonctionne que pour bzr >= 1.12.

Une fois le plugin installé, il devrait être possible d'utiliser le dépôt de manière assez transparente :

$ bzr checkout https+webdav://<username>:<password>@dev.fabienpoulard.info/bzr/miage2010/dev/
...
$ cd  dev/
$ touch README
$ bzr status
unknown:
  README
$ bzr add
adding README
$ bzr commit -m "Test"
HTTPS poulard-f@dev.fabienpoulard.info, Realm: 'Authentification BZR pour les miagistes 2010' password: ...
Committing to: https+webdav://poulard-f@dev.fabienpoulard.info/bzr/miage2010/dev/
added README
Committed revision 1.

Utilisation du CAS Editor

Fabien Poulard — Sat, 06 Mar 2010 19:21:00 +0100

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 :

...
  <repositories>
    <repository>
      <id>apache</id>
      <name>Apache UIMA</name>
      <layout>default</layout>
      <url>http://people.apache.org/repo/m2-incubating-repository/</url>
    </repository>
  </repositories>
  <pluginRepositories>
    <pluginRepository>
      <id>apache</id>
      <name>Apache UIMA</name>
      <url>http://people.apache.org/repo/m2-incubating-repository/</url>
      <layout>default</layout>
    </pluginRepository>
  </pluginRepositories>
  ...

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 :

Release du collection reader pour Wikipedia v.0.4

Fabien Poulard — Thu, 04 Mar 2010 13:39:00 +0100

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.

UIMA & Wikipédia (5) : Gestion du projet avec Maven

Fabien Poulard — Sun, 21 Feb 2010 17:56:00 +0100

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

<project 
   xmlns="http://maven.apache.org/POM/4.0.0" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"
>
  <modelVersion>4.0.0</modelVersion>
  <groupId>uima.wikipedia</groupId>
  <artifactId>uima-mediawiki-loader</artifactId>
  <version>0.4</version>
  <packaging>jar</packaging>
  <name>MediaWiki UIMA Loader</name>
  <description>This is a UIMA Collection Reader for the MediaWiki dumps (Wikipedia &amp; co).</description>
  <licenses>
    <license>
      <name>Apache 2</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
  </licenses>
  ...
</project>

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.

...
  <dependencies>
    <!-- Required to generate the Java classes -->
    <dependency>
      <groupId>org.apache.uima</groupId>
      <artifactId>uimaj-core</artifactId>
      <version>2.3.0-incubating</version>
      <scope>compile</scope>
    </dependency>
    <!-- DocumentAnnotation UIMA Type --> 
    <dependency>
      <groupId>org.apache.uima</groupId>
      <artifactId>uimaj-document-annotation</artifactId>
      <version>2.3.0-incubating</version>
      <scope>compile</scope>
    </dependency>
    <!-- WikiModel -->
    <dependency>
       <groupId>org.wikimodel</groupId>
       <artifactId>org.wikimodel.wem</artifactId>
       <version>2.0.7-SNAPSHOT</version>
    </dependency>
    <!-- WikiMedia Dumper -->
    <dependency>
        <groupId>org.wikimedia</groupId>
	<artifactId>mwdumper</artifactId>
	<version>1.16</version>
    </dependency>
  </dependencies>
  ...

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 :

...
  <repositories>
    <!-- Apache UIMA repository -->
    <repository>
      <id>apache</id>
      <name>Apache</name>
      <url>http://people.apache.org/repo/m2-incubating-repository</url>
    </repository>
  </repositories>
  ...

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.

...
  <build>
    <plugins>
      <!-- Java Compiler -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.0.2</version>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>
    <sourceDirectory>src</sourceDirectory>
    <outputDirectory>bin</outputDirectory>
    <resources>
      <resource>
        <directory>desc</directory>
      </resource>
    </resources>
  </build>
  ...

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 :

...
   <repository>
      <id>uima-fr.org</id>
      <name>UIMA Fr</name>
      <url>http://www.uima-fr.org/m2-repo/</url>
   </repository>
   ...

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 :

...
   <extensions>
      <!-- Enabling the use of SSH -->
      <extension>
        <groupId>org.apache.maven.wagon</groupId>
         <artifactId>wagon-ssh-external</artifactId>
         <version>1.0-beta-6</version>
      </extension>
   </extensions>
   <distributionManagement>
      <repository>
         <id>uimafr-repository</id>
         <url>scpexe://www.uima-fr.org//home/www-data/org_uima-fr_www/m2-repo</url>
      </repository>
   </distributionManagement>
   ...

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 :

<settings>
  <servers>
    <server>
      <id>uimafr-repository</id>
      <configuration>
        <sshExecutable>ssh</sshExecutable>
        <scpExecutable>scp</scpExecutable>
      </configuration>
    </server>
  </servers>
</settings>

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

Un peu de sécurité : renforcer SSH

Fabien Poulard — Fri, 19 Feb 2010 15:11:00 +0100

Après les annonces récentes concernant la sécurité des systèmes informatiques (ici ou là), je me suis dit que ce serait pas mal de m'intéresser un peu à la sécurité de mon serveur.

Je vais commencer par SSH étant donné qu'il s'agit du moyen le plus classique pour entrer sur le serveur.

Suis-je paranoïaque ?

Lorsque l'on s'intéresse à la sécurité informatique, on se demande toujours si l'on n'en fait pas un peu trop. Après tout je ne possède qu'un petit serveur personnel qui fait tourner quelques sites web et qui me sert à stocker des données diverses. Rien à voir avec les ordinateur du FBI, de la CIA ou de je ne sais quel super-ordinateur d'une compagnie pétrolière.

J'ai donc dans un premier temps estimé le risque réellement encouru par ma machine en étudiant le contenu des fichiers de log de l'authentification (/var/log/auth.log*). J'ai notamment recherché les messages de type Invalid user et Failed password qui concernent les tentatives d'intrusion par brute force :

$ grep "Invalid user" /var/log/auth.log*
...
/var/log/auth.log:Feb 19 09:21:06 persephone sshd[609]: Invalid user marine from 211.7.45.195
/var/log/auth.log:Feb 19 09:21:11 persephone sshd[611]: Invalid user marine from 211.7.45.195
/var/log/auth.log:Feb 19 09:21:15 persephone sshd[613]: Invalid user marine from 211.7.45.195
...
$ grep "Failed password" /var/log/auth.log*
...
/var/log/auth.log:Feb 19 09:21:08 persephone sshd[609]: Failed password for invalid user marine from 211.7.45.195 port 33591 ssh2
/var/log/auth.log:Feb 19 09:21:13 persephone sshd[611]: Failed password for invalid user marine from 211.7.45.195 port 34941 ssh2
/var/log/auth.log:Feb 19 09:21:17 persephone sshd[613]: Failed password for invalid user marine from 211.7.45.195 port 35827 ssh2
...

Et là j'ai un peu commencé à flipper ! 8 471 messages concernant une tentative de connexion avec un nom d'utilisateur invalide et 11 213 messages concernant une tentative de connexion avec un mauvais mot de passe, sur deux jours. J'ai développé un petit script python afin d'analyser ces tentatives d'intrusion.

Statistiques sur les noms d'utilisateur

En tout ce n'est pas moins de 3 158 noms d'utilisateurs différents qui ont été testé, dont moins d'1% correspondent à des noms d'utilisateurs existant réellement sur le système. Parmi les noms d'utilisateurs attaqués, on trouve les classiques Unix/Linux : root, postgresql, mysql, news, games, ...

Statistiques sur les dates

Sur deux jours il n'y a pas tellement d'intérêt à observer une évolution, et comme le montre le graphique ci-dessous, il n'y a pas tellement de période de la journée propice à une attaque.

Statistiques sur les attaquants

Finalement, ce qui est assez surprenant, mais tant mieux pour moi, c'est que la liste des attaquants soit assez stable. Il s'agit certainement de script-kiddies des US, de Colombie, Chine...

IP	Nb. tentatives
173.1.4.196	2416
18.239.6.7	2154
190.144.99.98	1901
222.247.37.141	1642
67.23.14.188	1157
160.80.97.45	789
212.174.28.15	304
124.137.4.142	292
88.191.74.61	173
202.140.41.206	168
59.108.230.130	66
202.98.244.20	26
222.68.194.69	21
86.34.201.30	16
202.165.177.203	16
202.108.77.139	15
88.44.214.142	15
81.7.171.41	15
88.191.69.60	11
203.150.104.182	8
211.7.45.195	6
200.69.106.147	1
80.13.112.50	1

Ce qui m'a surpris c'est que certaines venaient du très prestigieux MIT, du Centro di Calcolo e Documentazione de l'Universita' degli Studi di Roma "Tor Vergata" ou encore du réseau dédibox. Le nombre d'attaques étant important et l'origine identifiée, je me suis fendu d'un petit mail à destination des administrateurs. Pour tous les autres, une petite règle iptables permet de leur barrer la route :

$ sudo iptables -A INPUT -p tcp -s XXX.XXX.XXX.XXX --destination-port 22 -j DROP

Renforcer le point d'entrée : SSH

Toutes ces attaques ont été opérées sur mon serveur SSH. Autant dire qu'il s'agit du premier point à sécuriser.

La première chose à faire est d'aller renforcer un petit peu la sécurité côté serveur en modifiant quelques valeurs dans le /etc/ssh/sshd_config :

LoginGraceTime descendu à 30 secondes : au bout de 30 secondes si la connexion ne s'est pas concrétisée, le lien est rompu.
PermitRootLogin passé à no : l'utilisateur root ne peut pas se connecter par SSH, il s'agit du compte le plus attaqué (largement).
PermitEmptyPasswords passé à no : on ne sait jamais, un utilisateur suicidaire pourrait choisir de ne pas mettre de mot de passe !

Ensuite je me suis rendu compte que mon serveur SSH souffrait du problème de clés vulnérables (bug Debian). Il est possible d'identifier les clés vulnérables à l'aide de l'outil dédié :

$ sudo ssh-vulnkey -a

La clé RSA d'authentification de mon serveur (/etc/ssh/ssh_host_rsa_key.pub) étant vulnérable, je l'ai remplacée :

$ sudo ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
...

Voilà une première étape de sécurisation... mais il y aurait encore certainement à faire.

UIMA & Wikipédia (4) : Analyse de la syntaxe MediaWiki

Fabien Poulard — Sun, 14 Feb 2010 14:35:00 +0100

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.

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.

import org.wikimodel.wem.mediawiki.MediaWikiParser
import org.wikimodel.wem.IWemListener;
...
public class MediawikiCasConverter implements IWemListener {
 
  public MediawikiCasConverter() {
    theParser = new MediaWikiParser();
  }
 
  public void runParser(String rawWikiText) throws WikiParserException {
    // We use a string reader to parse the raw wiki texte
    StringReader reader = new StringReader(rawWikiText);
    // Parsing
    theParser.parse(reader, this);
  }
 
  // IWemListener methods below
  ...
}

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 :

/**
 * This method adds the string in parameter into the collected content
 * and then increment the offset by the size of this string.
 * 
 * @param str the string to be added to the content
 */
protected void addToContent(String str) {
  if ( str != null ) {
    theTextContent.append(str);
    theOffset += str.length();
  }
}
...
/** Called when a word is encountered */
public void onWord(String str) {
  addToContent(str);
}

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 :

/**
 * When we encounter a new header, we create an annotation for it.
 */
public void beginHeader(int headerLevel, WikiParameters params) {
  // Jump a line
  addToContent("

");
  // Create the annotation
  Header header = new Header(theCas);
  header.setLevel(headerLevel);
  header.setBegin( theOffset );
  // Add it to the list
  theHeadersAnnotations.add( header );
  // Add it as header of the last unclosed section
  if ( theUnclosedSections.size() > 0 ) {
    Section section = theUnclosedSections.get( theUnclosedSections.size()-1 );
    section.setTitle(header);
  }
}
 
/**
 * Add the ending value of the last started header.
 */
public void endHeader(int headerLevel, WikiParameters params) {
  // Retrieve the last header
  Header header = theHeadersAnnotations.get( theHeadersAnnotations.size()-1 );
  // Update its ending value
  header.setEnd( theOffset );
  // Jump a line
  addToContent("

");
}

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

UIMA & Wikipédia (3) : Filtrage des données à charger

Fabien Poulard — Fri, 12 Feb 2010 14:56:00 +0100

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.

Autres articles

UIMA & Wikipédia (2) : Chargement d'un dump Wikipedia

Fabien Poulard — Tue, 02 Feb 2010 14:05:00 +0100

Voici le second billet qui discute du chargement d'un dump XML de l'encyclopédie libre et la distribution du contenu sous forme de CAS.

Wikipédia, formats brutes

La base de données contenant toutes les pages de Wikipédia et autre sites de la fondation WikiMedia est automatiquement archivée très régulièrement. Les dumps de la base sont disponibles sur http://download.wikimedia.org/. Vous trouverez ainsi :

les archives de la Wikipédia française
les archives de WikiNews ou juste la partie en français
les archives de la Wikiversity ou juste la partie en français
les archives des WikiBooks

Il est également possible de télécharger l'intégralité de l'encyclopédie dépourvue des balises wiki : http://download.wikimedia.org/nowiki/.

Le billet Créer un miroir Wikipédia explique comment construire une copie locale de l'encyclopédie à partir de ces différents dumps. Nous nous donnons comme objectif d'exploiter ces dumps directement sans passer par une importation en base de données.

L'outil d'exportation et d'importation de MediaWiki : mwdump

MWDumper est un outil écrit en Java par les développeurs de MediaWiki qui permet d'importer/exporter une base MediaWiki à partir de/vers une base de données. Cet outil a l'avantage de travailler directement sur la version compressée du dump XML, réduisant ainsi le besoin en espace disque disponible. Cet outil s'utilise en ligne de commande et offre un certain nombre de paramètres permettant notamment de filtrer les articles à exporter ou bien le format SQL à prendre en charge.

Une version compilée de l'outil est disponible sur download.wikipedia.org, mais il y a de forte chance qu'elle soit dépassée. Le plus sûr est de compiler l'outil depuis les sources.

Une partie du code de cet outil va nous faciliter la tâche pour la réalisation d'un collection reader pour UIMA, notamment les classes :

org.mediawiki.importer.XmlDumpReader
org.mediawiki.importer.DumpWriter
org.mediawiki.importer.Page
org.mediawiki.importer.Revision

Il nous faut toutefois noter que XmlDumpReader repose sur un analyseur SAX, ce qui n'est pas directement utilisable dans un Collection Reader d'UIMA. En effet, dans UIMA c'est le Collection Reader qui contrôle l'exécution, alors qu'à l'opposé l'analyseur SAX contrôle sa propre exécution. La seule interaction avec le parseur est l'emploi des hooks.

L'idée est de faire tourner l'analyseur SAX dans un thread différent de celui du collection reader. Ensuite à l'aide d'un mécanisme de sémaphore (ou de monitor en Java), on contrôle l'exécution du parseur pour produire les CAS. Cette méthode permet d'utiliser presque directement l'outil de MediaWiki, ainsi si la syntaxe évolue, l'outil de MediaWiki évoluera également certainement et ce sera donc normalement transparent pour le collection reader.

Une première version de collection reader pour Wikipedia

Voici une première version du collection reader pour Wikipédia qui ne prend pas du tout en compte la syntaxe, mais charge seulement le contenu des pages dans un CAS. Il y a encore beaucoup de travail pour obtenir quelque chose d'intéressant et d'utilisable, d'où l'estampillage 0.1. Pour utiliser le composant, il est nécessaire d'avoir le jar de mwdumper dans le classpath.

Il y a tout un tas d'améliorations que j'aimerais apporter (filtrage, analyse de la syntaxe wiki, ...) mais l'idée est dans un premier temps de fournir une version brute de fonderie qui fonctionne pour qu'elle puisse être testée. Le jar contient notamment le code Java, donc il ne faut pas hésiter à y jeter un oeil.

Le descripteur est dans le Jar distribué, il ne prend en paramètre que le chemin vers le dump XML à charger. Peu importe l'extension (.gz, .bz, ...), il devrait pouvoir s'en sortir. Si ce n'est pas le cas, laissez un commentaire ! Je n'ai fait que peu de tests pour le moment, je ne sais pas trop comment le composant tient la route sur des gros dumps, mais la première remarque est qu'il est nécessaire d'augmenter la taille du tas de la jvm (-Xmx=512m pour commencer). En effet, certaines pages sont assez imposantes de par leur grand nombre de révisions, et pour l'instant toutes les révisions sont chargées dans chaque CAS.

Autres billets

UIMA & Wikipédia (1) : Proposition de Type System

Fabien Poulard — Mon, 01 Feb 2010 02:15:00 +0100

Voici le premier billet qui discute de la création d'un Type System approprié pour représenter les pages de Wikipedia.

Wikipédia, structuration des données

L'encyclopédie Wikipédia contient tout un tas d'informations mais je me concentrerai particulièrement sur le contenu même : les articles. Je propose de classer les informations concernant ces derniers en quatre grandes catégories :

Position de l'article dans l'encyclopédie (portail, catégories, ...)
Versions de l'article (révisions, ...)
Structuration de l'article (titre, sous-titre, ...)
Macros et mise en forme du texte (gras, italique, ...)

Position de l'article dans l'encyclopédie

On peut considérer la Wikipédia comme un ensemble de pages liées selon trois grandes relations :

Les catégories structurent l'encyclopédie à la manière d'une ontologie ou d'un thésaurus. Une page peut appartenir à une ou plusieurs catégories. De plus, les catégories sont hiérarchisées, l'appartenance à une catégorie implique l'appartenance à toutes les catégories parentes.

Les liens interlangues marquent les pages en relation de traduction avec la page courante.

Les liens internes permettent au sein d'une page de faire référence à d'autres pages de l'encyclopédie, il s'agit d'une structuration qui n'a qu'un impact local. La signification de ces références est très variable et difficilement identifiable.

Versions de l'article

Le principe de l'encyclopédie collaborative est que tout le monde peut modifier un article, ce qui amène à de multiples révisions de ces derniers. Lorsque vous cliquez sur l'onglet Historique d'un article, vous pouvez visionner ces différentes révisions, leur auteur, et éventuellement un commentaire précisant l'apport de la révision.

Structuration d'un article

Le contenu d'un article se structure à l'aide de titres, de paragraphes ainsi que de divers éléments de mise en forme : [tableaux], [formules], [listes], ...

Parmi les éléments de mise en forme, on peut également noter l'existence de plusieurs macros pour les [modèles], [dates], [liens interwiki], ...

Choix d'un Type System

Je ne crois personnellement pas à l'existence de Type Systems génériques pouvant être partagés par tous les composants. De mon point de vue, un Type System va être approprié au traitement d'une tâche particulière, chercher à en produire un suffisamment générique pour toutes les tâches seraient une perte de temps et mènerait certainement à un TS difficile à utiliser.

Personnellement, je vais utiliser Wikipedia dans le cadre de ma thèse sur la détection de dérivation de texte. Ce qui m'intéresse c'est donc de générer un CAS par article dans lequel on retrouvera les différentes révisions dudit article. Je m'intéresse donc :

à la notion d'article
aux notions de révision
à la structuration du contenu d'un article à l'aide des titres et des paragraphes
au texte

Après réflexion j'en suis donc arrivé à cette modélisation :

Cette modélisation ne correspond pas exactement aux besoins d'un TS UIMA. Ainsi, les relations de composition se manifestent par un phénomène de couverture des annotations, entraînant la disparition des attributs correspondant.

Vous trouverez le descripteurs correspondant à ce TS ici.