Nicolas Hernandez

2012-01-16T05:43:00.000-08:00

Depuis septembre 2010, j'anime au sein de l'équipe des rencontres "Outils et instruments logiciels pour le TAL" connues aussi sous le nom de "réunions logiciels".

J'utilise ce post pour rappel du principe et les commentaires pour présenter les différentes interventions qui ont lieu.

La motivation de ces rencontres sont l'échange de connaissances
et l'entraide pour la prise en main d'un nouveau logiciel.

L'objectif pour le présentateur est simple : faire connaître un
logiciel et donner un aperçu de l'utilisation de celui-ci. La présentation prend la forme d'une
démonstration d'un cas d'utilisation. Suivant le logiciel, cela prend
15 à 30 minutes questions comprises.

Il faut prendre logiciel (au sens très large) [2] : cela peut concerner un
développement personnel, une bibliothèque, une application, un analyseur
particulier de données...

Je vous invite à vous proposer pour présenter un logiciel que vous pensez être
pertinent pour l'équipe (même si vous n'en connaissez que quelques fonctions),
ainsi qu'à émettre des demandes de démonstration. Je me propose de
coordonner pour trouver un intervenant dans le cas de demandes. On pourra
discuter plus tard sur les modalités d'ouverture de ces réunions à des
participants hors équipe.

Les rencontres sont au rythme d'une demi-heure tous les mois voire toutes les 6 semaines.
Elles sont planifiées sur l'agenda de l'équipe (aussi consultable en ligne sur [1]).

[1] agenda des réunions de l'équipe TALN
[2] Instrument, outil, utilitaire et ressource
http://www.revue-texto.net/Corpus/Publications/Habert/Habert_Portrait.html#2.1.

Définition d'un descripteur primitif d'Analysis Engine

2012-01-05T09:18:00.001-08:00

Ce post est en lien avec le post Développer son premier composant UIMA : l'Analysis Engine (AE)

La dernière étape consister à créer un descripteur indiquant au framework UIMA comment utiliser le composant. En particulier il définit la classe métier de l'Annotator, le Type System manipulé, les Types qui sont utilisés comme input et ceux qui seront des output. C'est aussi ici que sont déclarés les paramètres et les ressources partagées utilisés si il y a lieu.

La création du descripteur du composant est facilitée à travers Eclipse et les plugins installés. Dans le répertoire desc/opinionRecognizer du projet (ou seulement desc si vous n'avez pas packagé votre projet) :

Créer le fichier descripteur du composant, opinionRecognizerAE.xml en cliquant dessus avec le bouton droit et New - Other - UIMA - Analysis Engine Descriptor File.
Sur la première page (onglet Overview accessible au bas du cadre) spécifier le nom de la classe qui implémente votre code métier (i.e. opinionRecognizer.OpinionRecognizerAE).
Sous l'onglet Type System, ajouter (Add) par nom (by name) le type system défini pour votre composant (i.e. desc/opinionRecognizer/opinionRecognizerTS.xml).
Enfin sous l'onglet Capabilities, spécifiez les types des annotations qui doivent apparaître en sortie (i.e. SentenceAnnotation, TokenAnnotation et Opinion).

Si en cliquant sur ce fichier pour l'ouvrir, vous n'accédez qu'à son contenu XML, alors demandez d'ouvrir avec le Component Descriptor Editor en cliquant sur le fichier avec le bouton droit.

Implémenter le code métier d'un composant Analysis Engine

2012-01-05T09:16:00.001-08:00

Ce post est en lien avec le post Développer son premier composant UIMA : l'Analysis Engine (AE)

La seconde étape correspond au développement du code métier du composant.

Le code métier d'un AE est à minima constitué d'une classe dite Annotator qui étend la classe JCasAnnotator_ImplBase du framework UIMA. En particulier, on trouve le code métier dans une méthode surchargée appelée process qui est automatiquement appelée à l'exécution pour chaque CAS traitée. La méthode process a accès au CAS et via l'API d'UIMA elle peut manipuler l'artifact ou les (index d') annotations qui ont été précédemment ajoutées ou bien en ajouter de nouvelles.

La classe JCasAnnotator_ImplBase est une implémentation par défaut de la classe AnalysisComponent. Cette implémentation par défaut implémente toutes les méthodes exceptée la méthode process. En général on travaille directement à partir de celle-ci quitte à surcharger les méthodes déjà implémentées.

La classe AnalysisComponent a plusieurs méthodes dont les plus importantes sont initialize, process et collectionProcessComplete. La méthode initialize est appelée une fois par le framework UIMA à la création de la première instance de la classe Annotator ; elle sert par exemple à récupérer la valeur de paramètres ou à charger des ressources qui seront partagées par les différentes instances de la classe. La méthode process est donc appélée une fois par item traité. La méthode collectionProcessComplete est appelée quand l'entière collection a été traitée et sert à produire des résultats relatifs à toute la collection.

Dans cet exercice, vous n'aurez besoin que d'implémenter la méthode process.

Création de la classe Annotator

Dans le répertoire src, créer le package opinionRecognizer.
Au sein du package, créer la classe OpinionRecognizerAE. Par convention les classes Annotator se termineront par le suffixe AE.
Faire étendre la classe de JCasAnnotator_ImplBase
et surcharger la méthode process.

Cela doit donner quelque chose comme :

package opinionRecognizer;
import
org.apache.uima.analysis_component.JCasAnnotator_ImplBase;
import org.apache.uima.jcas.JCas;
import opinionRecognizer.types.*;
public class OpinionRecognizerAE extends JCasAnnotator_ImplBase{
public void process(JCas aJCas) {
// Faire quelque chose
}
}

Création du code métier au sein de la méthode process

La méthode process reçoit en argument une instance de JCas laquelle constitue le document analysé ainsi que toutes les annotations qui y ont été associées lors d'éventuelles précédentes analyses. Le JCas fournit une approche JNI (Java Native Interface) pour la manipulation des objets CAS et de leur propriétés (i.e.~avec des new, des getter/setter, ... Le framework UIMA se charge de passer le CAS d'un composant à un autre.

Pour cet exercice, l'analyseur devra ajouter une nouvelle annotation Opinion délimitée aux offsets (begin et end) de toutes les phrases SentenceAnnotation contenant des mots TokenAnnotation qui sont des verbes (posTag débutant par "vb" égal à "bez") ou dont la forme de surface coveredText est "we" ou "our". On ajoutera aussi le nombre de mots contenu dans l'opinion length.

L'algorithme que je propose d'implémenter est le suivant :

récupération d'un index de phrases SentenceAnnotation
parcourir l'index de phrases et pour chacune,

récupérer un sous index de mots TokenAnnotation
parcourir l'index de mots et pour chaque mot

définir un booléen à vrai si un mot a son trait posTag débutant par "vb" égal à "bez"
définir un booléen à vrai si un mot a son trait forme de surface coveredText est "we" ou "our".
incrémenter un compteur de mots

si les deux booléens sont vrais alors

créer une nouvelle annotation Opinion aux offsets (begin et end) de la phrase courante
initialiser les valeurs begin, end et length de cette annotation

La récupération d'un index de phrases SentenceAnnotation peut se réaliser à l'aide de la méthode getAnnotationIndex appliquée au JCas et qui prend en argument le type d'annotation souhaité. Le parcourir de l'index de phrases peut se réaliser à l'aider d'un Iterator.

Cela doit donner quelque chose comme :

AnnotationIndex<annotation> aSentenceAnnotationAnnotationIndex = aJCas.getAnnotationIndex(SentenceAnnotation.type);
Iterator<annotation> aSentenceAnnotationIterator = aSentenceAnnotationAnnotationIndex.iterator();
while (aSentenceAnnotationIterator.hasNext()) {
SentenceAnnotation aSentenceAnnotation = (SentenceAnnotation) aSentenceAnnotationIterator.next();
// Faire quelque chose
}

L'ajout du précédent code lève des erreurs de dépendances non importées (AnnotationIndex, Iterator, SentenceAnnotation). Elles se résolvent très facilement par un left-click sur la petite croix rouge dans la marge de gauche au niveau de chaque erreur détectée et en optant pour le bon import.
Cette action sera à reproduire avec le code à venir.

La récupération d'un index d'annotations couvertes par une autre annotation peut se faire à l'aide de la méthode subiterator qui s'applique sur un index d'annotations et qui prend en argument l'annotation recouvrante.
Elle requiert la création d'un index d'annotations. Pour notre besoin, un index de mots TokenAnnotation peut suffire. Il se construit comme l'index de phrases vu ci-dessus. On décide de récupérer l'index de toutes les annotations pour varier les plaisirs. Il faudra alors ne considérer que les annotations mots qui nous intéressent.
L'instruction suivante réalise cela. On la place au même niveau que la construction d'index de phrases.

AnnotationIndex<annotation> anAnnotationIndex = aJCas.getAnnotationIndex();

A l'intérieur de la boucle, pour chaque phrase on récupère un FSIterator (qui est un iterator un peu spécial sur ce type de structure) sur les annotations couvertes par la phrase courant aSentenceAnnotation.

Cela donne

FSIterator<annotation> anySubSentenceAnnotationFSIterator = anAnnotationIndex.subiterator(aSentenceAnnotation);
while (anySubSentenceAnnotationFSIterator.hasNext()) {
Annotation aSubSentenceAnnotation = (Annotation) anySubSentenceAnnotationFSIterator.next();
// Faire quelque chose
}

Si l'annotation couverte courante aSubSentenceAnnotation est un TokenAnnotation alors on teste si un mot a son trait posTag débutant par "vb" égal à "bez" et si un mot a son trait forme de surface coveredText est "we" ou "our" et l'on compte le mot.
Cela correspond au code ci-dessous

if (aSubSentenceAnnotation.getClass().getName().equalsIgnoreCase("org.apache.uima.TokenAnnotation")) {
TokenAnnotation aWord = (TokenAnnotation) aSubSentenceAnnotation;
if (aWord.getPosTag().toLowerCase().startsWith("vb") || aWord.getPosTag().equalsIgnoreCase("bez")) {
containsAVerb = true;
}
if (aWord.getCoveredText().equalsIgnoreCase("our") || aWord.getCoveredText().equalsIgnoreCase("we")) {
containsAKeyword = true;
}
wordCounter++;
}

Pour que ce code fonctionne il faut rajouter quelques déclarations de variables avant la boucle de parcours des annotations couvertes par l'annotation phrase courante.

boolean containsAVerb = false;
boolean containsAKeyword = false;
int wordCounter = 0;

Pour chaque phrase aSentenceAnnotation parcourue on teste si les présences d'un mot clef et d'un verbe sont confirmées. Dans la positive, on créer une nouvelle annotation Opinion. On définit ses traits begin et end en fonction des begin et end de la phrase courante. On définit aussi la longueur length de l'opinion. Et au final on ajoute l'annotation ainsi créée à l'index des annotations à l'aide de la méthode addToIndexes.
Ce qui donne le code suivant :

if ((containsAKeyword) && (containsAVerb)) { Opinion aOpinion = new Opinion(aJCas); aOpinion.setBegin(aSentenceAnnotation.getBegin()); aOpinion.setEnd(aSentenceAnnotation.getEnd()); aOpinion.setLength(wordCounter); aOpinion.addToIndexes();}

Définir les types de données (type system) à manipuler au sein d'un composant UIMA

2012-01-05T09:13:00.000-08:00

Ce post est en lien avec le post Développer son premier composant UIMA : l'Analysis Engine (AE)

La première étape pour développer un composant est de définir les types de données qu'il va manipuler.

Création du descripteur et des types de données à manipuler

En lien avec notre exercice, nous allons définir le type d'annotation opinionRecognizer.types.Opinion qui correspondra au type des annotations produites par notre composant d'analyse. On lui ajoutera un trait (feature) length qui indiquera le nombre de mots contenu dans l'annotation Opinion courante. Par simplicité nous ne rappellerons pas par la suite le nom de package (opinionRecognizer.types) qui précède le nom du type.

D'abord créons le fichier descripteur :

Les fichiers descripteurs de systèmes de types et d'AE se placent dans le répertoire desc. Pour s'y retrouver ultérieurement parmi les descripteurs qui seront disponibles dans le CLASSPATH, je vous conseille de créer un sous répertoire portant le nom de votre projet (en respectant les conventions de nommage Java), par exemple ici : opinionRecognizer.

Faire un clic-droit sur le répertoire desc (ou sur le sous-répertoire que vous venez de créer si vous avez suivi mon conseil).
Choisir le menu 'New'-'Other...'-'UIMA'-'Type System Descriptor File'.
A l'écran suivant, donner un nom au fichier descripteur de types par exemple opinionRecognizerTS.xml. Là encore par convention et pour s'y retrouver plus tard je vous conseille d'utiliser le suffixe TS pour vos noms de fichier descripteur de systèmes de types.

Ensuite, une fois le fichier créé, ajoutons le type désiré opinionRecognizer.types.Opinion :

Dans l'onglet Type System du descripteur, ajouter un type avec le bouton Add Type.
Donner lui le nom de opinionRecognizer.types.Opinion
Le faire hériter du type uima.tcas.Annotation défini par le framework UIMA et qui permet d'hériter des traits begin, end et coveredText. Le trait coveredText est un trait un peu particulier parce que l'on ne peut y accéder qu'en lecture. Il retourne le texte de l'artifact couvert entre les offsets délimités par les valeurs entières begin et end.

Ajoutons aussi une feature au type :

En sélectionnant le type, cliquer sur le bouton Add...
Donner lui le nom de length qui indiquera le nombre de mots contenu
Faire hériter du type simple Integer.

Puisque nous manipulons aussi les types mot, org.apache.uima.TokenAnnotation, et phrase, org.apache.uima.SentenceAnnotation, qui sont des uima.tcas.Annotation et le trait posTag (String) du type TokenAnnotation dont les annotations auront été produits par les composants de prétraitement, il nous faut aussi ajouter ces types. Le faire.

Génération automatique des l'API JAVA du système de types

Une fois le fichier de descripteur de systèmes de type créé et sauvé, une API java permettant de manipuler les types (et les traits) est automatiquement générée.

Si jamais vous craignez que cette API ne soit pas générer ou que vous vouliez forcer sa re-génération, cliquer sur le bouton JCasGen présent dans l'éditeur du fichier Système de Type.

Les fichiers Opinion.java et Opinion_Type.java sont générés dans le sous répertoire opinionRecognizer.types du répertoire src du projet.

Le fichier Opinion.java contient le constructeur de type. Noter la présence d'accesseurs pour modifier la valeur des attributs du type Opinion (par exemple les méthodes getLength() et setLength(int v)).

Développer son premier composant UIMA : l'Analysis Engine (AE)

2012-01-04T09:11:00.000-08:00

Objectifs
Ce post présente ce qu'est le composant élémentaire de toute chaîne de traitement d'analyse UIMA à savoir l'Analysis Engine (AE). Il explique de quoi il se compose techniquement, et comment développer ses différentes parties.
Il s'agit entre autres de prendre en main l'API et les outils UIMA pour réaliser des opérations classiques : telles que définir des types d'annotation, générer automatiquement l'API pour manipuler les types d'annotations définis, récupérer des annotations posées par d'autres annotateurs, consulter et définir les valeurs de traits d'une annotation, créer une nouvelle annotation, créer un fichier XML descripteur et tester un composant.
Pour illustrer cet exercice de développement on cherchera à développer la fonction de reconnaissance de phrases qui expriment une opinion. On posera l'hypothèse qu'une phrase qui contient des verbes et des mots dont la forme de surface comme "we" ou "our" est une expression d'opinion... On utilisera pour cela quelques AE disponibles dans les Apache Uima Addons. On testera l'AE sur les textes présents dans le répertoire UIMA_HOME/examples/data notamment Apache_UIMA.txt. De fait nous travaillerons sur l'anglais pour cet exercice.

Prérequis

Il est nécessaire d'avoir réaliser les tutoriels suivant :

Savoir construire une chaîne de traitement sous Eclipse sous la forme d'un Aggregate d'Analysis Engine (AAE)
Savoir exécuter une chaîne de traitement (sous Eclipse, en ligne de commande ou via le DocumentAnalyzer GUI)

Tel que l'explique ces précédents posts, il faudra avoir au préalable construit et avoir à disposition une chaîne que nous appellerons de pré-traitement et qui sera composée des Apache UIMA addons suivant :

WhiteSpaceTokenizer qui découpe en mots, TokenAnnotation, et phrases, SentenceAnnotation, un texte fourni en entrée
Tagger qui rajoute un trait posTag aux TokenAnnotation

Qu'est ce qu'un composant UIMA de type Analysis Engine et à quoi cela sert ?

Un Analysis Engine (AE) est le composant élémentaire d'une chaîne de traitements UIMA. Il a généralement pour objet une tâche d'analyse (par exemple reconnaître si une phrase est une expression d'une opinion) sur ce que l'on appelle un artifact (par exemple un texte). Il reçoit les résultats d'analyse de précédents composants (par exemple un découpage en phrases, en mots, la reconnaissance des étiquettes grammaticales (nom, verbe, adjectif...)) qui lui servent de base pour ses traitements afin qu'il puisse à son tour associer à l'artifact le résultat d'analyse qu'il produit (par exemple les opinions). On appelle les résultats d'analyse, des meta-données ou des annotations. L'ensemble formé par l'artifact et les méta-données constitue la structure commune d'analyse (CAS ou Common Analysis Structure) et est LA structure de donnée qui transite d'un composant à un autre.

De quoi est constitué un composant UIMA ?

Un composant UIMA est logiquement constitué de trois éléments :

la définition des types des données que le composant manipule (lit et crée), on appelle cela le système de types (TS ou type system),
le code métier qui réalise la fonction souhaitée,
un descripteur indiquant au framework UIMA comment utiliser le composant.

Le système de types et le descripteur du composant sont des fichiers XML que l'on peut éditer avec des interfaces graphiques via les plugins Eclipse de UIMA. La définition du système de type entraîne la génération automatique d'une API pour manipuler les types de données définis au sein du code métier.

L'ensemble de ces éléments doit se trouver accessible via le CLASSPATH de l'application qui exécute. En général, on encapsule ces éléments au sein d'une même archive Jar.

Préparer un projet Java sous Eclipse pour accueillir le développement de votre composant

Il vous faut un projet Java sous Eclipse pour accueillir le développement de votre composant. Différentes options :

vous pouvez utiliser celui précédemment créé pour la chaîne de prétraitement
ou bien vous créez un nouveau projet comme indiquer ici mais il vous faudra alors déclarer une dépendance vers soit le projet qui contient votre chaîne de prétraitement soit vers le jar que vous aurez exporté à partir de celle-ci. Pour déclarer la dépendance au projet, Click droit sur le projet, Build path, Configure build path, Onglet Projects, Add les projets, Ok, OK...

Les étapes du développement

Exécuter votre AE au sein d'un Aggregate

Au sein du répertoire desc/opinionRecognizer créer un descripteur aggregate qui ajoute en pipeline le descripteur de pretraitement et le descripteur de votre AE. N'oubliez pas de changer les capabilities.
Et exécutez le.

Pour aller plus loin

la création et la récupération de vues,
la définition des paramètres au sein du descripteur et leur accès au sein du code,
la déclaration et la manipulation de ressources partagées par plusieurs instances d'un même AE,
le parcours d'index d'annotations à l'aide de contraintes

Remerciement

Le contenu décrit sur cette page s'inspire, adapte, étend le support créé pour le tutoriel qui a eu lieu à UIMA@RMLL'09 ainsi que le tutoriel Getting started de la documentation d'Apache UIMA.

Je vous invite à consulter ces différentes sources pour des informations complémentaires

Mise en correspondance de vues via un Aggregate pour interconnecter des composants UIMA (view et sofa name mapping)

2011-12-10T15:58:00.000-08:00

Après avoir rappelé quelques notions (que le lecteur averti peut ne pas lire), le post expose brièvement le problème et présente avec un exemple la mise en oeuvre d'une solution de mise en correspondance de vues au sein d'un Aggregate.

Bref rappel de quelques notions

Les chapitres 5 et 6 de la documentation UIMA tutorials_and_users_guides [1;2] rappellent les définitions des notions d'Artifact, Sofa et View.
Brièvement l'Artifact est la chose non structurée que l'on souhaite analyser. Le Sofa (Subject of Analysis) est une représentation de l'Artifact (e.g. HTML). Une annotation metadata est de l'information associée à un Sofa particulier pour en décrire une sous région. La notion de View simplifie les choses quand plusieurs versions de l'Artifact sont nécessaire à différentes étapes de l'analyse (e.g. une version sans balise d'un document XML). Les notions de Sofa et de CAS View sont liées. Dans l'implémentation Apache actuelle (2.4), à chaque Sofa est associé une seule View et à chaque View un seul Sofa. Le nom qui désigne une vue particulière est Sofa name pour des raisons historiques mais cela s'applique indifféremment à View aussi.

L'analyse d'un composant UIMA (AE - Analysis Engine) porte toujours sur une vue. Il peut y en avoir plusieurs. L'AE peut en créer. Les résultats d'analyse peuvent être associés sur les vues traitées ou bien sur les vues créées.

Un AE qui travaille seulement sur une seule vue est appelée "single-view component" et dans le cas contraire "multi-view/multi-sofa component".
Par défaut, si rien n'est spécifié il y a qu'une seule view et celle-ci a le sofa name de "_InitialView".

Problème d'interopérabilité pour interconnecter des composants développés indépendamment
Le développeur d'AE est libre de choisir le nom qu'il souhaite pour désigner ses vues d'entrée et ses vues de sortie.
Cela conduit naturellement à quelques petits soucis lorsque l'on veut interconnecter des composants ayant des noms de vue différents.

Le mécanisme de mise en correspondance des vues au niveau d'un Aggregate
La section 6.4 de la documentation explique et présente différentes situations de mises en correspondance : au sein d'un Aggregate, d'un CPE, d'une application UIMA, pour des services distants. Je rapporte et illustre la solution au sein d'un AE Aggregate.

Pour cela, j'utilise deux composants : l'XmlDetagger présent dans les exemples fournis avec Apache UIMA [4] et le Whitespace Tokenizer des addons de la Sandbox d'Apache UIMA [5].

L'XmlDetagger est un composant multiple vues qui retire les balises d'un document XML. Il lit l'XML d'une vue input nommée "xmlDocument". Le contenu textuel est écrit dans une nouvelle vue output appelée "plainTextDocument".
Le Whitespace Tokenizer est un composant simple vue qui travaille sur la vue par défaut (i.e. "_InitialView") et qui ajoute à celle-ci des annotations de phrases et de tokens.

Rapidement, je mets en place un projet Java sous Eclipse. J'y ajoute la UIMA Nature, déclare les répertoires desc et resources dans le build path ainsi que les bibliothèques de UIMA [6]. Je rajoute au le build path les bibliothèques uima-examples [10] et addon whitespace tokenizer [9] qui vont servir pour notre chaîne.

Je crée un descripteur d'AE Aggregate [7] et j'y ajoute by name en pipeline : d'abord l'XmlDetagger puis le Whitespace Tokenizer (je déclare les bons types à produire en output dans les capabilities).

A la sauvegarde le message suivant s'affiche

Error in AE Descriptor
The Descriptor is invalid for the following reason:
ResourceInitializationException: The output Sofa "plainTextDocument" in component "XmlDetagger" is not mapped to any output Sofa in its containing aggregate, "demoSofaNameMappingAAE". (Descriptor path ...)

Ce n'est pas réellement une erreur si l'on sait ce que l'on fait. Une vue qui n'est pas utilisée par exemple n'a pas besoin d'être mise en correspondance dans l'Aggregate.
En l'état si on exécute cet AE avec le DocumentAnalyzer [8] sur un document XML quelconque, on obtiendra l'erreur suivante :

org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator processing failed. Caused by: org.apache.uima.cas.CASRuntimeException: No sofaFS with name xmlDocument found.

Vraissemblablement ici il y a des vues qui requièrent d'être mise en correspondance et cela va se faire au niveau de l'Aggregate.

La première chose à faire est d'indiquer que la vue sur laquelle travaille en entrée XmlDetagger, à savoir xmlDocument, correspond à _InitialView dans l'Aggregate. Autrement dit, la vue d'entrée par défaut de l'Aggregate, _InitialView, doit être mise en correspondance avec la vue d'entrée, xmlDocument, de l'XmlDetagger.
Au sein du descripteur de l'Aggregate, c'est dans la section capabilities que l'on déclare les vues sur lesquelles on travaille (sous section component capabilities) et celles entre lesquelles on réalise des mises en correspondance (sous section sofaMappings).
On ajoute d'abord la vue xmlDocument comme input (entrée) en faisant un add sofa dans la component capabilities.
Ensuite on indique dans la sous section sofaMappings que pour le composant (componentKey) XmlDetagger sa vue (componentSofaName) xmlDocument correspond à la vue dans l'aggregate (aggregateSofaName) _InitialView.
Par les éléments componentKey et componentSofaName on désigne le composant et la vue souhaitée chez celui-ci comme devant intervenir dans un mapping. L'élément aggregateSofaName est la clé partagée entre les éléments sofaMapping.
Cette dernière opération doit se faire pour partie à la main en éditant le source (personnellement je n'y arrive pas via l'éditeur du formulaire). Cela donne

<capability>
...
<inputSofas>
<sofaName>xmlDocument</sofaName>
</inputSofas>
...

<sofaMappings>
<sofaMapping>
<componentKey>XmlDetagger</componentKey>
<componentSofaName>xmlDocument</componentSofaName>
<aggregateSofaName>_InitialView</aggregateSofaName>
</sofaMapping>
</sofaMappings>

Si on réexécute l'AE on se rend compte que ce n'est pas encore l'idéal car le Whitespace Tokenizer travaille sur l'_InitialView par défaut et traite donc ce qui correspond à l'xmlDocument au lieu du plainTextDocument.
On rajoute dans l'élément inputSofas

<sofaName>_InitialView</sofaName>

et l'élément suivant

<sofaMapping>
<componentKey>WhitespaceTokenizer</componentKey>
<componentSofaName>_InitialView</componentSofaName>
<aggregateSofaName>plainTextDocument</aggregateSofaName>
</sofaMapping>

La vue plainTextDocument du XmlDetagger n'a pas été redéfinie dans l'Aggregate, il n'y a pas d'ambiguité. Ce que produit le XmlDetagger au sein de sa vue output plainTextDocument est accessible sous ce même nom au sein de l'Aggregate qui le met en correspondance avec la vue input du
WhitespaceTokenizer.
L'exécution fonctionne comme attendu finalement.

Quelques commentaires supplémentaires

Au niveau de l'Aggregate après mise en correspondance, le nom de la vue du componentSofaName
sera renommé en le nom de la vue déclarée dans aggregateSofaName.
Les vues avec leur nom précédent ne seront plus accessibles. Une fois sérialisée en XMI, on constatera sela en cherchant la valeur de l'attribut sofaID.
Les composants d'Apache OpenNLP sont des composants multiples vues et requièrent en général l'usage de mises en correspondance.

Liens

[1] 5. Annotations, Artifacts & Sofas
[2] 6. Multiple CAS Views
[3] 6.4. Sofa Name Mapping
[4] UIMA_HOME/examples/descriptors/analysis_engine/XmlDetagger.xml
[5] http://uima.apache.org/sandbox.html#whitespace.tokenizer
[6] Créer un projet Eclipse pour le développement d'un composant UIMA
[7] Construire une chaîne de traitement UIMA à partir de composants existants
[8] Exécuter un traitement ou une chaîne de traitement sous UIMA (avec UIMAJ et en local)
[9] UIMA_HOME/addons/annotator/WhitespaceTokenizer/lib/uima-an-wst.jar
[10] UIMA_HOME/lib/uima-examples.jar

Création d'un portail collaboratif "Texte, Discours et Document"

2011-12-07T15:04:00.000-08:00

Partisan du travail collaboratif au niveau scientifique, je tente la création d’un (Google) document publié sur le Web et visible en édition par tous (sans nécessité de compte) pour construire un portail de ressources ayant trait à l’étude, la modélisation, la reconnaissance automatique et les exploitations applicatives des mécanismes d’organisation de l’information au niveau du ”Texte, Discours et Document”.

Cette page est avant tout un outil personnel. Peut être cela servira t elle à d’autres ? J’invite dans tous les cas toute personne intéressée à contribuer !

Par ressources, j’entends appels à communication, journaux majeurs, (web|bibli)ographie, personnes, équipes, projets, outils, corpus, etc.

Les objectifs sont la veille au niveau national et international et la cartographie du domaine selon les disciplines (traitement automatique des langues, linguistique, psycholinguistique, ingénierie des documents...) et courants théoriques.

Les approches ayant une visée de traitement automatique seront privilégiées.

Le portail se trouve ici !

Ajouter un dépot (repository) Maven à votre forge Google Code grâce à Subversion

2011-12-07T13:25:00.000-08:00

Discutés aux deux adresses ci-dessous mais l'alternative d'utiliser un dépot public est conseillée

Mesurer le nombre de visites sur votre projet hébergé sous Google Code grâce à Google Analytics

2011-12-07T13:20:00.000-08:00

Ce post décrit la procédure pour "track visits to Google code projects in Google Analytics".

Anyone may sign up for a free Google Analytics account. Once you have an account
Add a profile for a new domain and specify URL http://code.google.com/
Edit the profile that you just created to change its Website URL to http://code.google.com/p/votre-nom-de-projet/
Paste your Google Analytics profile's Web Property ID below and save changes.
About 24 hours after you add your Web Property ID, your profile should begin to indicate that it is receiving data.

Publier une Javadoc sous forge Google Code

2011-12-07T13:11:00.000-08:00

La procédure est la suivante

Récupérez la racine du projet

svn checkout https://votre-nom-de-projet.googlecode.com/svn/ votre-nom-de-projet --username votre.username
cd votre-nom-de-projet

Ajoutez un répertoire javadoc au versionning

svn mkdir javadoc

Réalisez l'export de la javadoc via Eclipse se sera plus simple
Ajoutez les fichiers javadoc au versionning

svn add javadoc/*

Ajoutez les propriétés adéquates pour que svn interprète les fichiers de la javadoc avec le bon type mime

find javadoc -name "*.html" -exec svn propset svn:mime-type text/html {} + ;
find javadoc -name "*.css" -exec svn propset svn:mime-type text/css {} + ;
find javadoc -name "*.jpeg" -exec svn propset svn:mime-type image/jpeg {} + ;

Commitez vos ajouts

svn commit javadoc/ -m "ajout de la javadoc"

Votre javadoc devrait être désormais accessible via l'url http://votre-nom-de-projet.googlecode.com/svn/javadoc/index.html ; ajoutez ce lien dans la section de links de Administer > Project Summary

Publier sur le Web et partager les droits d'édition à tous d'un Google document

2011-12-07T08:37:00.000-08:00

Dans la quête de la recherche d'outils facilitant le travail collaboratif je tente d'utiliser un Google Document qui désormais offrent des fonctionnalités de partage des droits d'édition à tous (sans nécessité de posséder un compte) ainsi que de publication Web.

La procédure ci-dessous est légèrement différente de celle trouvée sur des réponses officielles (publication de vos documents et publication sur le web). Peut être est ce dû à un retard de mise à jour de la documentation ?

La procédure a été testée avec un Google Document, mais reste valable a priori pour tout type de documents (document, feuille de calcul, présentation...). Ici vous trouverez un exemple de Google Document publié et ouvert à l'édition (il s'agit d'un site sérieux merci de ne pas le modifier à moins que vous souhaitiez y contribuer).

Les deux actions, partage de la visibilité et publication sur le web, supposent que vous venez d'ouvrir ou de créer votre Google Document.

Pour partager la visibilité (notamment en édition)

Cliquer sur l'icone "Share". Une fenêtre de configuration intitulée "Share settings" apparaît.
Cliquer sur "Change" au niveau de la première ligne du tableau "Who has access" (par défaut l'accès est limité : "Private - Only the people listed below can access"). Une fenêtre intitulée "Visibility options" apparaît
Sélectionner "Public on the web. Anyone on the Internet can find and access. No sign-in required."
Et enfin changer l'accès de "Can view" à "Can edit" au niveau de la ligne "Access:Anyone (no sign-in required)" qui a dû apparaître.

Pour publier sur le Web un Google document

Dans le menu File, cliquer sur "Publish to the Web". Une fenêtre "Control publishing" s'affiche.
Laisser coché "Automatically republish when changes are made".
Cliquer sur "Start publishing" et confirmer. Vous obtiendrez un lien vers le document publié
Par ailleurs, le lien par lequel vous éditiez votre document est désormais public. Vous pouvez le faire circuler.

Remarques

Attention, il est important de noter que la publication sur le Web et sa visibilité sont deux concepts indépendants.
Les contributeurs du Web n'auront pas accès aux options de partage mais pourront intervenir sur la publication.
Ils n'auront pas non plus accès à l'historique des modifications ("File > Revision history")
Ils pourront télécharger le document dans divers formats (notamment PDF)
Ils ne pourront pas changer les notifications qui sont propres à un compte à moins qu'ils ne soient connectés.

Sélection d'articles de TALN'2011

2011-07-22T08:35:00.000-07:00

Le programme de la conférence est disponible à http://taln2011.org/

Les articles suivant ont été sélectionnés pour leurs accointances avec le traitement automatique du discours

Laurence Danlos. Analyse discursive et informations de factivité
Patrick Saint-Dizier. TextCoop: un analyseur de discours basé sur les grammaires logiques
Charlotte Roze. Vers une algèbre des relations de discours pour la comparaison de structures discursives
Laurence Longo (Université de Strasbourg), Amalia Todirascu (Université de Strasbourg). RefGen, outil d'identification automatique des chaînes de référence en français
Delphine Bernhard and Anne-Laure Ligozat. Analyse automatique de la modalité et du niveau de certitude : application au domaine médical
Laurence Danlos and Charlotte Roze. Traduction (automatique) des connecteurs de discours
Maxime Amblard, Michel Musiol and Manuel Rebuschi. Une analyse basée sur la S-DRT pour la modélisation de dialogues pathologiques
Yann Mathet (Université de Caen), Antoine Widlöcher (Université de Caen). GlozzQL : un langage de requêtes incrémental pour les textes annotés
Marion Laignelet, Mouna Kamel and Nathalie Aussenac-Gilles. Enrichir la notion de patron par la prise en compte de la structure textuelle - Application à la construction d'ontologie

UIMA sur HADOOP

2011-06-08T06:09:00.000-07:00

Faire tourner des applications UIMA sur HADOOP.

http://www.isabel-drost.de/hadoop/slides/uimaHadoopHofer.pdf (dans http://wiki.apache.org/hadoop/HadoopPresentations ; illustration avec une application simple et UIMA 2.2.1)
https://cwiki.apache.org/UIMA/running-uima-apps-on-hadoop.html
Behemoth (is an Apache Licensed open source platform for large scale document processing which allows deploying UIMA applications within Hadoop)

En Février dernier (2011), IBM a fait un gros coup de pub avec son système Watson qui a gagné le jeu Jeopardy aux Etats-Unis contre des joueurs humains (il s'agit de retrouver la question à partir d'une réponse soumise). Le système utilisait UIMA et HADOOP...

https://blogs.apache.org/foundation/entry/apache_innovation_bolsters_ibm_s (annonce officielle)
http://blog.reddit.com/2011/02/ibm-watson-research-team-answers-your.html, http://www.enterpriseirregulars.com/32391/beyond-jeopardy-with-ibm-watson-%E2%80%93-quick-analysis (Question/Réponses sur Watson)

Pour aller plus loin

http://www.quora.com/IBM-Watson/Whats-the-system-architecture-of-the-IBM-Watson (une comparaison des architectures entre Watson et Wolfram)
http://maggon.posterous.com/uima-and-gate-applications-over-hadoop (UIMA et GATE sur HADOOP)

Construire des modélisations du French Treebank pour le UIMA HMM Tagger

2011-05-25T08:29:00.000-07:00

Mise à jour le 1 juin. Précision sur le traitement des mots composés du French Treebank

Ce post décrit la procédure que j'ai mise en place pour construire des modélisations de type HMM (Hidden Markov Model) utilisées par le Tagger de la UIMA sandbox à partir d'un corpus XML qui porte des annotations sur des tokens mots, à savoir le corpus French Treebank.

Ci-dessous je présente

les données d'entraînement utilisées
la procédure d'entraînement et sa mise en oeuvre
les composants requis
le paramétrage des composants
le contenu d'un projet Eclipse autonome que je distribue et qui illustre la phase d'entraînement de modélisations et la phase d'étiquetage à partir de modélisations construites.
les opérations à réaliser au sein du projet Eclipse pour entraîner une modélisation ou étiqueter des textes à partir d'une modélisation existante
des problèmes qu'il reste à rêgler pour améliorer les modélisations
une FAQ

Le projet Eclipse est téléchargeable ici. Il s'agit de l'importer dans Eclipse. La donnée d'entraînement n'est pas distribuée (consulter la page dédiée au corpus pour cela, seul un exemple que j'ai construit est distribué). Les modélisations construites à partir du corpus sont présentes et sont distribuées sous licence Apache v2. Toutes les dépendances requises à l'exécution sont présentes.

Corpus d'entraînement : le French Treebank (training data set)
J'ai utilisé une version UTF-8 de Juillet 2010 du corpus French Treebank. Ce corpus a été construit à l'Université de Paris 7. Consulter Abeille et al, 2003, Building a treebank for French, in Treebanks, Kluwer pour plus de détails. Contacter A. Abeille pour obtenir une version de ce corpus.

L'information annotée dans ce corpus permet de construire (entre autres) des modélisations pour l'analyse morphosyntaxique de token mots telles que de

l'étiquetage grammatical (part of speech (pos) tagging),
de la morphologie flexionnelle (inflection analysis (mph)),
de la sous-catégorisation grammaticale (subcategorization analysis (subcat))
et de la lemmatisation (lemmatization (lemma)).

Je précise que la procédure décrite ici est indépendante du format XML de la donnée d'entraînement dans la mesure où la seule contrainte soit que l'annotation à apprendre doit être décrite à l'aide d'un balisage en ligne XML (c'est-à-dire couvrant la zone de texte annotée). Le composant d'importation (uima-connectors) que j'utilise me permet cela.

Procédure de construction de modélisation (training process)
La procédure de construction de modélisation est la suivante

importation des informations portées par les éléments et attributs XML en annotations génériques au sein d'un CAS représentant le document.
entraînement d'une modélisation HMM à partir de ces annotations

La mise en oeuvre de la procédure

utilise un composant générique pour l'importation des informations XML -les informations sont importées sous la forme d'annotations génériques- et implique l'utilisation d'un composant assurant la transformation des annotations génériques en annotations à même d'être prise en compte par le composant suivant d'apprentissage.
utilise les paramètres des différents composants pour spécifier

les vues sur lesquelles travailler : la vue dans laquelle est chargée le document XML et celle où se trouve seulement le contenu textuel avec les annotations importées
les featurePath qui pointent le trait de l'annotation dont il faut considérer la valeur pour l'apprentissage

Composants utilisés (components)

En pratique j'ai utilisé trois Analysis Engines (AE) appartenant à trois projets distincts pour la phase de construction

le premier, XML2CAS de uima-connectors, permet de parcourir des documents XML et de transformer les éléments et attributs XML en annotations des zones de texte couvertes.
le second, annotationMapper de uima-type-mapper, permet de sélectionner et transformer les annotations produites par le uima-connectors en annotations que prendra en entrée le dernier composant d'entraînement (ce projet est aussi appelé uima-annotation-mapper)
le troisième, hmmModelTrainer de uima-tagger de la sandbox Apache UIMA, permet d'entraîner une modélisation.

Et j'ai utilisé deux AE distincts pour la phase d'étiquetage

le premier, whitespaceTokenizer de whitespace tokenizer, permet de découper un texte en phrases et mots.
le second, tagger de uima-tagger de la sandbox Apache UIMA, permet d'étiqueter un texte à l'aide d'une modélisation.

A propos de l'Apache UIMA Sandbox HMM Tagger

J'ai utilisé la version présente dans UIMA Annotator Addons 2.3.1 qui corrige une anomalie https://issues.apache.org/jira/browse/UIMA-2106 (rapport d'anomalie + correctif). Cette version qui applique le correctif n'est pas encore distribuée à l'heure de l'écriture de ce message, mais se trouve présente dans le répertoire subversion du Tagger dès la version 1088626. Une version compilée avec les sources est fournie.
La partie apprentissage portée par l'AE hmmModelTrainer permet de spécifier le trait de l'annotation (featurePath) à prendre en compte pour l'entraînement. Néanmoins celui-ci ne permet pas de spécifier des contraintes notamment sur la valeur d'autres traits présents dans l'annotation dont on a défini le featurePath. Or ici nous en avons besoin pour sélectionner seulement certaines des annotations produites par le XML2CAS.
La partie étiquetage portée par l'AE tagger ne permet pas à l'heure actuelle de spécifier le trait à annoter. En l'état, quelle que soit la modélisation, le Tagger affecte la valeur prédite au featurePath suivant org.apache.uima.TokenAnnotation:posTag. Ce n'est pas très embêtant si l'on sait ce que l'on fait. Le patch https://issues.apache.org/jira/browse/UIMA-2110 soumis à Apache vise à rendre plus générique le Tagger et résoudre notamment cette limite. Entre autre il permet de spécifier sous forme d'un featurePath le trait de l'annotation auquel il faut donner la valeur prédite par la modélisation. Ce patch n'a pas encore accepté par Apache.

Paramétrage des composants utilisés (parameter settings)

L'AE XML2CASAE

produit des annotations XMLElementAnnotation et XMLAttributeAnnotation pour chaque élément XML rencontré.

Les traits de XMLElementAnnotation permettent de connaître le nom de l'élément XML et les noms et les valeurs de ses attributs. Deux structures de données sont disponibles pour cela, l'une d'elle est un tableau de référence vers des annotations XMLAttributeAnnotation correspondant à chacun de leurs attributs. Les XMLAttributeAnnotation correspondent à une annotation pour chaque attribut. Elles déclarent le nom de l'élément XML qu'elles caractérisent ainsi que le nom et la valeur de l'attribut.

prend les paramètres suivants

nom de la vue à créer avec seulement le contenu textuel du document XML (PlainTextOutputView). La vue où se trouve le document textuel peut aussi être spécifiée si elle est différente de celle par défaut. Ici PlainTextDocument
nom des éléments XML à transformer en annotations dans le CAS (XmlTagsToTurnIntoAnnotation). Ici w, qui correspond à la balise du French Treebank pour mot.

L'AE annotationMapper

prend en paramètre un fichier de règles qui assurent la transformation d'une annotation en une autre (RulesFile).
Globalement ici la règle permet d'une part de sélectionner les annotations XMLAttributeAnnotation qui correspondent à des attributs de mots (balises w) et qui ont un attribut non nul dont on désire utiliser la valeur comme base d'apprentissage (cat, subcat, lemma, mph, ee, ...), et d'autre part de créer pour chacune de ces annotations une annotation manipulable par le composant d'apprentissage avec un trait initialisé à la valeur à apprendre.
Ici la règle crée des org.apache.uima.TokenAnnotation et instancie la valeur du trait posTag. On pourrait pour chaque caractéristique apprise changer le trait à considérer. Ce n'est pas très pertinent pour notre construction. Un même trait peut acceillir tour à tour les valeurs du corpus pour chaque entraînement.
A noter qu'il est possible de spécifier avec le hmmModelTrainer le featurePath à considérer comme base d'entraînement. Néanmoins celui-ci ne permet pas de spécifier des contraintes notamment sur la valeur d'autres traits présents dans l'annotation dont on a défini le featurePath. Or ici nous en avons besoin pour sélectionner un sous ensemble des XMLAttributeAnnotation parmi celles produites par le XML2CAS. C'est cette situation qui justifie notamment l'utilisation de l'annotationMapper.

L'AE hmmModelTrainer

prend en paramètre

le featurePath qui pointe le trait de l'annotation dont il faut considérer la valeur pour l'apprentissage (FeaturePathPOS)
le nom et chemin du fichier de modélisation à créer (ModelExportFile)

L'AE tagger

prend en paramètre

le featurePath qui pointe le trait de l'annotation qu'il faut instancier avec la valeur prédite par la modélisation (TokenFeaturePath)
le nom et chemin du fichier de modélisation à utiliser (ModelFile)

Le descripteur qui met en oeuvre cet AE l'utilise plusieurs fois consécutivement avec des jeux de valeurs différentes pour appliquer les différents modélisations.
Nous avons étendu le type org.apache.uima.TokenAnnotation à cet effet. Consulter le fichier desc/FrenchTreebankTS.xml

Contenu du projet Eclipse (Eclipse project description)

Le projet Eclipse est globalement un projet java ayant la UIMA Nature et ses sous répertoires desc et resources déclarés comme appartenant au build path. Le post suivant décrit comment créer un projet Eclipse en rajoutant dans le build path les dépendances minimales UIMA requises pour exécuter une chaîne de traitement UIMA.

Le répertoire lib contient toutes les dépendances requises, celles de uima, celles des AE de notre chaîne (uima-common, uima-connectors, jxpath et uima-type-mapper) avec notamment le whitespace tokenizer(uima-an-wst) de la UIMA Sandbox et la version patchée du HMMTagger (uima-an-tagger). Ces dépendances ont été déclarées dans le .classpath. Elles seront accessibles lors de l'import du projet.
Le répertoire data/input contient un sous répertoire FrenchTreebank avec un fichier exemple qui reprend la structure XML d'un fichier du corpus original. Ce fichier a en fait été construit a posteriori à partir d'analyses produites. Il peut dans le cas présent servir de base d'exemple de la chaîne d'entraînement. Le répertoire contient aussi un sous répertoire text-fr avec des textes en français qui peuvent servir pour tester l'étiquetage à partir des modélisations construites.
Le répertoire data/output accueille les résultats d'exécution des chaînes de traitement, aussi bien les xmi (xmi) que les modélisations (models).
Le répertoire resources/models contient les modélisations construites sur le corpus FrenchTreebank (les jeux d'étiquettes (ou tagset) sont décrits ici)

FrenchTreebankPosUimaHmmTaggerModel.dat: part of speech (pos) tagging ('cat' attribute in the French Treebank)
FrenchTreebankMphUimaHmmTaggerModel.dat: inflection analysis
FrenchTreebankSubcatUimaHmmTaggerModel.dat: subcategorization analysis
FrenchTreebankEeUimaHmmTaggerModel.dat: combination of part of speech (pos) tagging, subcategorization analysis and inflection analysis
FrenchTreebankLemmaUimaHmmTaggerModel.dat: lemmatization

Le répertoire resources contient aussi un fichier de règle pour la transformation d'annotations en autres. Cela permet de faire le pont entre le composant d'importation et le HMMTrainer. Son nom ici est XML2CAS-to-HMMTagger_annotationMapperRules.xml
Le répertoire desc contient

le descripteur de la chaîne utile pour la construction des modélisations à savoir XML2CAS-annotationMapper-HMMTrainModel-FrenchTreeBank-AAE.xml
un descripteurs de chaîne pour l'étiquetage à partir d'une modélisation à savoir wst-FrenchTreebank-HmmTagger-AAE.xml. Celle disponible par défaut dans l'addon convient très bien mais requiert quelques manipulations pour spécifier le bon fichier de modélisation et étiquetera toujours le featurePath org.apache.uima.TokenAnnotation:posTag
un descripteur qui sert pour déclarer l'importation d'un Type System étendant le type TokenAnnotation avec de nouveaux attributs susceptibles d'accueillir le résultat d'étiquetage de différentes modélisations (morphologie, lemmatisation, ...) à savoir FrenchTreebankAE.xml qui importe FrenchTreebankTS.xml.

Réaliser la construction d'une modélisation (running the training process)
Le post suivant explique comment exécuter une chaîne de traitement UIMA.

Pour réaliser la construction d'une modélisation, utiliser le descripteur desc/XML2CAS-annotationMapper-HMMTrainModel-FrenchTreeBank-AAE.xml qui constitue un aggregate d'AE présentés ci-dessus en pipeline.

Placer votre corpus sous la forme d'un seul fichier dans le répertoire data/input/FrenchTreebank. Un fichier exemple est fourni. Une manipulation est décrite ci-dessous pour produire un seul fichier à partir des différents fichiers du French Treebank.
Spécifier dans le fichier de règles de l'annotationMapper le nom de l'attribut XML du corpus French Treebank sur lequel vous souhaitez réaliser l'apprentissage (cat, subcat, lemma, mph, ee, ...)
Spécifier le nom du fichier de modélisation à produire dans le paramètre du descripteur
Lancer le documentAnalyzer (par exemple) pour exécuter la chaîne en spécifiant surtout l'input

Réaliser l'étiquetage à partir d'une modélisation (running the tagging process)

Pour cela utiliser le descripteur desc/wst-FrenchTreebank-HmmTagger-AAE.xml

Les données traitées doivent être des fichiers textes
Spécifier le fichier de modélisation dans le paramètre du descripteur
Spécifier le featurePath de l'annotation à créer avec la valeur prédite par la modélisation
Lancer le documentAnalyzer (par exemple) pour exécuter la chaîne

Limites actuelles des modélisations

Le corpus compte des mots simples et des mots composés, tout deux balisés avec le même élément. Les mots composés imbriquent des mots simples. Ceux-ci n'ont pas avec les mêmes traits que leurs homologues non imbriqués. La construction de ces modélisations a considéré les mots composés mais non les mots simples imbriqués.

Les mots composés sont de la forme suivante

<w cat="D" ee="D-def-fp" ei="Dfp" lemma="le" mph="fp" subcat="def"></w> <w cat="N" ee="N-C-fp" ei="NCfp" lemma="banque centrale" mph="fp" subcat="C"> <w catint="N">banques</w> <w catint="A">centrales</w> </w>

ou bien

<w cat="ADV" ee="ADV" ei="ADV" lemma="à tout prix"> <w catint="P">à</w> <w catint="D">tout</w> <w catint="N">prix</w> </w>

La règle de sélection utilisée par l'annotation mapper met des contraintes sur la présence de certains traits. Pour rappel, la contrainte est

<Contrainte>.[@elementName='w' and @attributeName='cat' and @attributeValue!=""]</Contrainte>

En conséquence, les mots simples composants les mots composés ne sont pas considérés.

A l'inverse, si l'on ne souhaite pas considérer les mots composés mais les mots simples on peut écrire une contrainte comme celle-ci (on filtre sur la présence d'un caractère blanc)

<Contrainte>.[@elementName='w' and not(contains(@coveredText,' '))]</Contrainte>

Mais là effectivement nous n'avons plus accès aux traits du mots composés. Cela ne pose pas de problème pour de l'entrainement de découpeur en mots ou en phrases.

L'apprentissage d'un étiqueteur morphosyntaxique sur des mots composés ne semble pas non plus poser problème.

Si vraiment on voulait ne pas considérer les mots simples, on pourrait imaginer une contrainte avec alternative qui exclurait les mots composés et considèrerait les traits des mots simples mais cela ne concernerait pas tous les traits (ici seulement les étiquettes grammaticales : cat et catint).

Le processus de lemmatisation via l'algorithme utilisé présente des abérations lorsqu'il ne connaît pas le mot à lemmatiser. En effet, il va lui affecter le lemme d'un mot qu'il connaît et avec lequel il partage le plus grand suffixe commun.
...

Un seul "gros" fichier d'entraînement

Le corpus French Treebank est un ensemble de fichiers XML. Utilisant un AE et non un Collection Reader (CR) de uima-connector, il me fallait un seul fichier XML contenant toute la collection. Une petite ligne de shell me résoud le problème

echo '<?xml version="1.0" encoding="UTF-8"?>' > frenchTreebank.xml ; echo "<ftb>" >> frenchTreebank.xml ; for f in `ls lmf*.xml`; do echo $f; export HEAD=`head -1 $f`; if [ "$HEAD" == '<?xml version="1.0" encoding="UTF-8"?><text>' ]; then echo "<text>" >> frenchTreebank.xml; fi; cat $f |grep -v "xml version" >> frenchTreebank.xml; done ; echo "</ftb>" >> frenchTreebank.xml

Environnement d'exécution

J'ai réalisé mes traitements sur un système linux via Eclipse.

J'ai eu à augmenter les capacités de la machine virtuelle Java lors de l'exécution de la chaîne de traitement. Via Eclipse, j'ai rajouté la valeur -Xmx2048m dans le menu Run Configurations > Arguments > VM Arguments.

La machine que j'utilisais offre 16 Go de RAM et un processeur Intel Xeon W3565 @ 3.20GHz.

Implémentation de l'algorithme Viterbi du HMM Tagger

L'implémentation actuelle (src/main/java/org/apache/uima/examples/tagger/Viterbi.java) fonctionne grosso modo de la sorte (il y a ici d'autres détails techniques cachés) :
Pour chaque mot phrase d'une phrase on cherche à lui attribuer une probabilité d'étiquette pour cela :

on regarde si on connaît la probabilité du mot ou de sa forme en minuscule sinon on cherche le suffixe le plus long en commun avec un mot connu sinon on lui attribue la probabilité d'un mot prédéfini.

Sélection d'articles de COLING'2010

2011-03-28T05:36:00.000-07:00

Le programme entier est disponible à http://nlp.stanford.edu/coling10/full-program.html
Les articles téléchargeables de http://www.aclweb.org/anthology/C/C10/

Deux sessions de 4 présentations chacune sur le Discours. Des communications aussi lors de la session poster. Importance des questions de modélisation des structures (générale du discours et en particulier temporel) et de la résolution des anaphores/co-référence. On trouve notamment 2 contextes applicatifs du moment : Opinion Mining et Event Extraction. Au moins 2 articles (outils, protocoles d'annotation) sur le PDT (Prague Dependency Treebank - corpus Czech).

Quelques articles qui m'intéressent

C10-1001 [bib]: Stergos Afantenos; Nicholas Asher Testing SDRT’s Right Frontier
C10-2118 [bib]: Rashmi Prasad; Aravind Joshi; Bonnie Webber Realization of Discourse Relations by Other Means: Alternative Lexicalizations
C10-2172 [bib]: Zhi-Min Zhou; Yu Xu; Zheng-Yu Niu; Man Lan; Jian Su; Chew Lim Tan Predicting Discourse Connectives for Implicit Discourse Relation Recognition
C10-1087 [bib]: Shachar Mirkin; Jonathan Berant; Ido Dagan; Eyal Shnarch Recognising Entailment within Discourse

Utiliser TextMarker au sein d'un Analysis Engine (i.e. hors Eclipse)

2011-03-16T06:13:00.002-07:00

Ce post vient compléter le post précédent où je traduisais les manipulations à réaliser pour installer et utiliser TextMarker au sein d'Eclipse. Vous n'avez pas besoin de lire ce précédent post pour comprendre et réaliser les opérations décrites dans le présent post.

TextMarker est avant tout une bibliothèque libre (licence LGPL) pour le développement d'applications d'extraction d'information à base de règles sur des éléments de surface et des annotations existantes. En tant que bibliothèque il peut s'utiliser relativement simplement au sein d'un Analysis Engine (AE) d'Apache UIMA.

C'est aussi un environnement de développement au sein d'Eclipse base sur le framework DLTK

(Dynamic Languages Toolkit) qui offre via ses plugins un éditeur de règles, des composants pour l'explication de l'inférence des règles et un processus de construction d'Analysis Engines et Systemes de Types.

Il est développé par Peter Kluegl and Martin Atzmueller and Frank Puppe à l'université de Wuerzburg (de).

La FAQ de TextMarker indique comment développer une application Java qui utilise TextMarker. De l'explication, on en déduit certains éléments pour utiliser au sein d'un AE.

DEUX PRE-REQUIS : des bibliothèques et le projet exemple
L'utilisation de TextMarker requiert deux bibliothèques. Il s'agit de

AntLR 3.1.3
de.uniwue.tm.textmarker.engine

AntLR se trouve disponible soit directement sur le site officiel soit dans le plugin Eclipse de TextMarker via l'update site mais pas dans l'archive dédiée à l'installation manuelle (tout au moins il semble manquer des éléments dans le jar supposé plugins/de.uniwue.dltk.textmarker.antlr_3.1.3.201102241433.jar car j'obtiens un java.lang.ClassNotFoundException: org.antlr.runtime.CharStream) .
Pour rappel, on ajoute un update site à Eclipse via le menu Help > Install new softwares (sélectionner et installer les éléments présentés).
La bibliothèque de.uniwue.tm.textmarker.engine se trouve disponible indifféremment via Eclipse update site ou via l'archive pour l'installation manuelle (la première est en générale plus récente). Ces bibliothèques se trouveront dans le répertoire ECLIPSE_HOME/plugins.

Le projet exemple fournit des exemples de descripteurs d'AE et de TS. Le récupérer. Je vous invite à consulter les différents fichiers du répertoire script et bien entendu la documentation en ligne (menu de gauche chapitre Langage) pour comprendre. Globalement l'ensemble de scripts sert à annoter différents éléments d'un référence bibliographique...

VOTRE PREMIER AE AVEC TEXTMARKER
Afin de réaliser un premier AE, le plus simple est de

créer dans Eclipse un Java Project
y copier les répertoires descriptor, script, resources, input et output du projet Exemple
ajouter dans le build path les bibliothèques d'UIMA habituelle pour faire fonctionner un AE (dans UIMA_HOME/lib, sélectionner uima-core, uima-cpe, uima-document-annotation, uima-tools)
ajouter dans le build path les deux bibliothèques requises par TextMarker et qui ont été récupérés selon la manipulation décrite ci-dessus. Ci l'on s'appuie sur l
ECLIPSE_HOME/plugins/de.uniwue.dltk.textmarker.antlr_3.1.3.201103101605/antlr-3.1.3.jar
ECLIPSE_HOME/plugins/de.uniwue.tm.textmarker.engine_1.0.0.201103101605.jar
ajouter dans le build path les répertoires descriptor, script et resources

Avant d'exécuter, je jète un oeil aux descripteurs d'AE en ouvrant avant le Component Descriptor Editor et constate une erreur...
Les descripteurs se trouvent dans descriptor.de.uniwue.example. Il s'agit de

AuthorEngine.xml, MainEngine.xml, TestEngine.xml, TitleEngine.xml, YearEngine.xml

Seul TestEngine s'édite sans souci...
... Les autres se plaignent qu'il manque la déclaration du configurationParameter "descriptorPaths", je le rajoute donc pour chacun à la mano à l'aide du Text Editor
   <configurationParameter>
   <name>descriptorPaths</name>
   <type>String</type>
   <multiValued>true</multiValued>
   <mandatory>false</mandatory>
   </configurationParameter>
et le place sous l'élément

   <configurationParameters searchStrategy="language_fallback">
Je lance enfin l'exécution à l'aide du documentAnalyser en spécifiant l'input et l'output. Tour à tour je teste les différents descripteurs. Ceux ci peuvent s'exécuter indépendamment les uns des autres.

AuthorEngine.xml et TitleEngine.xml fonctionne directement sans souci, des annotations peuvent être visualisées dans le XMI produit.
YearEngine.xml et MainEngine.xml requièrent de modifier leurs capabilities dans leur descripteur afin de spécifier les types des annotations que je désire visualiser... il y en a pas mal.
TestEngine.xml, ne fonctionne pas (null exception)

POUR ALLER PLUS LOIN

TODO

Comment créer son propre AE utilisant TextMarker ?

http://tmwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=AnalysisEngine

Comment écrire un script TextMarker ?

Menu de gauche Langage avec la première section http://tmwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=Introduction
http://tmwiki.informatik.uni-wuerzburg.de/Wiki.jsp?page=Dictionaries

Rédaction d'un rapport de stage

2011-03-14T09:03:00.000-07:00

Mise à jour le 23 mars 2011
Ce document doit encore être modifié notamment pour indiquer les livrables attendues à chaque étape du déroulement d'un projet.

A l'attention de mes étudiants, une compilation de conseils que j'ai glanés ces dernières années (merci à mes collègues).

Conseils de rédaction

Faites des phrases courtes ou des listes plutôt que des longues phrases.
Pour chaque phrase ou paragraphe, réfléchissez à l'effet que vous voulez produire sur le lecteur. Mettez vous à sa place et demandez vous si ce que vous avez écrit lui permet de comprendre le message que vous souhaitez lui faire passer.
Faites suivre systématiquement la première apparition d'un terme spécifique à votre domaine d'une définition et d'un exemple illustrant ce qui tombe sous votre définition et ce qui n'est pas couvert par votre définition
Expliquez toujours un acronyme lors de sa première occurrence
Des schémas sont toujours bon car ils permettent souvent de comprendre plus rapidement.
Pensez à faire des schémas assez légers. Les gros schémas peuvent toujours être simplifiés en regroupant des parties qui sont explicitées/détaillées ailleurs.
Vous pouvez être amené à décrire le travail réalisé par quelqu'un d'autre que vous. Il faut que cela soit clairement dit. Vous avez le droit de faire des citations et le devoir de citer les sources dans une bibliographie en fin de votre document.
La compréhension de votre rapport principal ne doit pas nécessiter de se reporter constamment aux annexes.
N'hésitez pas à mettre quelques notes de bas de page. Ceux-ci ne doivent pas contenir des informations nécessaires à la compréhension seulement des complémentaires.
Chaque figure doit avoir un titre (éventuellement une légende explicative), un numéro, et être référencée dans le texte. Une figure non citée par la suite fait perdre la piste de lecture.
Préférez une numérotation des titres avec des chiffres plutôt que farfelue qui mélange lettres, chiffres et numération romaine
Ayez un style sobre, aéré et consistant (choisissez vous une norme dès le départ, par exemple : ligne de code en "Courier New" ou "DejaVu sans mono" taille 10 aligné à gauche, texte normal en "arial" taille 10 ou 11 justifié, etc.).
Numérotez vos pages.
en tête et pied de page bien venu avec nom du projet (éventuellement abrégé) et noms des étudiants
Pensez à faire une table des matières (éventuellement deux : une sommaire au début et complète à la fin)
Faites un glossaire si nécessaire
Ne recopiez pas introduction, résumé en français et en anglais, présentation de l'entreprise, conclusion d'anciens rapports de stage. Le plus souvent, ce sont de très mauvais textes qui sont recopiés !
N'écrivez pas des choses que vous ne comprenez pas.

Contenu d'un rapport
Pour mes étudiants en DUT 2eme année, 30 pages environ.

Page de garde

titre de votre projet
date de réalisation (éventuellement numéro de version)
noms des étudiants et leur groupe
nom de l'encadrant
logo des entités encadrantes ou commanditaires

Introduction
Globalement 1 page avec un paragraphe par item.

contexte du projet
présentation du sujet qui doit être compréhensible pour quelqu'un qui n'est pas du domaine
annonce du plan du rapport

Environnement

1-2 pages

Situation de l'établissement où vous avez fait votre stage, au sein de l'entreprise
Fonctionnalités de cet établissement (production, administration, etc.)
Situation du service où vous avez fait votre stage, au sein de l'établissement de l'entreprise où vous avez fait votre stage
Environnement matériel et logiciel dans lequel vous avez travaillé

Expression du besoin

Autour de 5 pages (essentiellement sur le détail de l'expression du besoin)

Contexte détaillé : problèmes ayant amenés le client à proposer ce sujet, enjeux qui pourraient être solutionnés par votre travail
Présentation de l'existant et de ses limites
Situation de ce que vous avez réalisé au sein des applications existantes dans la solution utilisée auparavant par l'entreprise
Brève description de ce qui vous a été fourni : documents ? ressources logicielles ?
L'expression des besoins qui vous a été fournie. Si celle-ci vous a été donnée sous forme écrite, la fournir entre guillemets.
L'environnement matériel et logiciel que vous deviez utiliser

Spécification (documents d'analyse)
10-12 pages

Choix d'orientation : ce que vous avez décidé de faire/ne pas faire dans le projet, et la justification (faisabilité, temps, coût, complexité,...)
Couche/package de votre architecture en dissociant les aspects métiers, IHM et interaction avec la base de donnée
Modèle des données
Modèle des objets :

1 ou + diagrammes de classe (découpage en package). Les attributs et rôles en français, les invariants en français. Si certaines relations d'héritage nécessitent des commentaires, vous pouvez les insérer dans le document

Prototypage de l'interface homme machine
Cas d'utilisation : 1 ou + diagrammes de cas d'utilisation
Scénarios d'utilisation : diagrammes de séquence (scénario normal, avec alternatives et avec erreurs). Tests d'acceptation (suite d'opérations et résultats attendus dans une situation donnée)
Diagramme d'états pour modéliser le comportement de chaque algo important

Conception
5-7 pages

Choix d'implantation :

comment se traduit la spécification formelle en terme de langage objet ; pour chaque élément de l'analyse (classe, opération, relations), décrivez comment il sera réalisé (attribut de classe, méthode d'objet, méthode statique, instance de classe existante, nouvelle classe, etc.)

chaque classe de l'analyse doit être identifiée avec soit une nouvelle classe, soit une classe existante
chaque opération doit être associée à une classe pour en faire une méthode

de même pour la mise en oeuvre au niveau de la base de donnée
et de la conception de l'IHM

Structure de fichiers du projet, les fichiers les plus importants
Diagrammes d'interaction : pour chaque cas d'utilisation, donner 1 ou + diagrammes de séquence en utilisant les classes et méthodes définies dans les choix d'implantation.
Description des opérations : pour chaque méthode critique, décrire son fonctionnement en pseudo-code ou en utilisant une machine à états.
Description des cycles de vie : pour chaque classe qui le nécessite (dès l'instant que le cycle de vie n'est pas trivial), décrire le cycle de vie de ses objets par une machine à états.
Tests unitaires : pour chaque classe, donner un jeu de test unitaire et de tests d'intégration. Préciser aussi l'ordre d'intégration des classes

Test de votre logiciel
0-4 pages

Test boîte blanche vs test boîte noire, stratégie de test. Comment ont été constitués les jeux de test. Qui les a constitué ? Résultat des tests.
Tests unitaires : trace d'exécution (ne doivent apparaître que les erreurs) + commentaires
Tests de scénarios de l'analyse : mise à jour et complément éventuels des scénarios + résultats des tests + commentaires
Synthèse : analyse de l'ensemble des tests, comparaison des résultats avec ce qui était prévu dans l'analyse et la conception

Démarche que vous avez suivie

2-4 pages

La démarche de travail que vous avez suivi entre vous et avec votre encadrant
Répartition formelle : qui est sensé faire quoi dans le groupe de projet, description précise du découpage des tâches pour la phase en cours
Répartition effective : qui a fait quoi et quand (soit de manière hebdomadaire soit en découpant en 4 périodes : "avant le début officiel du projet en janvier au retour des vacances de noël", "depuis début Janvier et avant la semaine dédiée au projet et les vacances d'Hiver", "durant la semaine de projet", "après la semaine de projet et avant le rendu du rapport" . Si vous travaillez séparément, désignez un coordinateur.
Compte rendu sur l'activité d'analyse, de conception, de codage et de test

notamment les difficultés rencontrées : problèmes qui vous ont particulièrement gêné pendant l'analyse, la conception, la réalisation et les tests, autres

Compte rendu sur le travail général

Conclusion
1 à 3 pages

bilan de ce qui a été réalisé en regard de l'existant et de ce qui était attendu

analyse et conception réalisée
développement produit
test réalisé
efforts pour la communication et la réutilisation

commentaire du code
packaging
documentation produite (javadoc, guide utilisateur, ...)
site web mise en place
vidéo démo (sous ubuntu réalisable simplement à l'aide de recordmydesktop)

perspectives pour poursuivre

Annexes

Eventuellement le cahier des charges
Manuel Utilisateur

Description des procédures pour réaliser

l'installation,
la configuration
et l'utilisation de l'application

les aspects généraux de(s) l'interface(s) ou bien intégration des copies d'écran
les différentes opérations disponibles dans l'application et comment les exécuter

Description des problèmes courants
Mini foire aux questions
Paquetage des fichiers sources

Livrables
une archive contenant

les sources du code src,
javadoc (documentez avec la syntaxe JAVADOC chaque classe, attribut, méthode ou exception. Générez la doc HTML et empaquetez le tout (doc + classes squelettes))
doc/userGuide (binaire et source)
doc/rapport (binaire et source)

tar zcf

-`date +%Y%m%d`-`date +%H%M`.tgz projet/

Utiliser le Regular Expression Annotator (Apache addon)

2011-02-23T03:52:00.000-08:00

Mise à jour : 29/07/2011

Ce post fait partie d'une série destinée à présenter les instruments d'analyse disponibles avec UIMA et utiles en Traitement Automatique des Langues (TAL). Parmi les instruments de cette catégorie on peut trouver des projections de dictionnaires (DictionnaryAnnotator, ConceptMapper), des analyseurs à base de règles, notamment pour reconnaître des motifs d'annotations (TypeMapper) et des analyseurs à base d'apprentissage automatique (ClearTK...).

1. Le RegexAnnotator qu'est ce que c'est ?
Le Regular Expression Annotator d'Apache (aussi appelé RegexAnnotator) est un analyseur qui permet de reconnaître des motifs de chaines de caractères qui peuvent être décrits à l'aide d'expressions régulières tels que les emails, les urls, les numéros de téléphones, certaines entités nommées...

Utiliser le RegexAnnotator revient à écrire un (ou plusieurs) fichiers de définition de concepts et les déclarer dans le paramètre dédié du composant (appelé conceptFiles).
Définir un concept revient à écrire une ou plusieurs règles de reconnaissance de motifs décrivant le concept et à associer une opération de création d'annotations ou de mise à jour de valeurs des traits d'une annotation à réaliser lorsqu'un motif est reconnu.

2. Où se trouve la documentation de référence ?

en ligne http://uima.apache.org/downloads/sandbox/RegexAnnotatorUserGuide/RegexAnnotatorUserGuide.html
en local après installation du composant UIMA_HOME/addons/annotator/RegularExpressionAnnotator/docs/html/RegexAnnotatorUserGuide/RegexAnnotatorUserGuide.html

3. Récupérer le composant
Le composant se trouve dans la distribution des "UIMA Annotator Addons & Simple Server & Pear packaging tools".
Ceux-ci s'installe (désarchive) dans le répertoire de UIMA_HOME. Le binaire suffit pour l'utilisation.

le binaire et les sources de la distribution http://uima.apache.org/downloads.cgi
le dépot svn des sources du composant http://svn.apache.org/repos/asf/uima/sandbox/trunk/RegularExpressionAnnotator

4. Utiliser le composant
L'explication est donnée via Eclipse mais peut se faire sans.
4.1. Créer un projet Eclipse

Créer un nouveau projet Eclipse en suivant les consignes suivantes
Ajouter ensuite à votre build_path le jar du RegexAnnotator qui se trouve à cette adresse UIMA_HOME/addons/annotator/RegularExpressionAnnotator/lib
Créer ensuite un descripteur d'AE dans votre repertoire desc.
Editez le descripteur et déclarez le en aggregate (premier onglet), ajoutez le descripteur du RegexAnnotator.xml (onglet aggregate), étendez le paramètre conceptFiles (onglet parameter), et indiquez le chemin vers le nom des fichiers de vos concepts (onglet parameter settings), définissez le système de type que vous utilisez dans la définition de vos concepts (onglet type system), et déclarez les dans les capabilities du composant (onglet capabilities).

Ici la démarche expliquée pour d'autres composants http://enicolashernandez.blogspot.com/2010/03/construire-une-chaine-de-traitement.html

4.2. Spécifier les paramètres du composant
Les concepts sont déclarés dans des fichiers XML qui doivent être accessibles dans le classpath (ou build path lorsqu'on travaille sous Eclipse). On indique ensuite le chemin relatif de ces fichiers dans le parameter conceptFiles du descripteur du composant. Généralement on ajoute le répertoire resources dans le buildpath, on place les fichiers de règles dans ce répertoire et on indique simplement le nom de ces fichiers au niveau du parametre conceptFiles.

4.3. Executer la chaîne construite (regarder la section Executer via Eclipse)

5. Définir des concepts
Afin d'illustrer la définition de concepts et la construction de règles de reconnaissance associées, nous chercherons à définir le concept de "lieu" et construire une règle de reconnaissance selon le motif "prépositions de lieu suivi d'un nom propre (mot débutant par une majuscule)" e.g. à Paris, en Aquitaine...

Les concepts sont déclarés dans des fichiers XML. Le repertoire UIMA_HOME/addons/annotator/RegularExpressionAnnotator/resources de l'addon fournit le XSCHEMA (concepts.xsd) de ce type de fichier ainsi qu'un fichier exemple (concepts.xml).
Vous pouvez y jeter un oeil rapidement sur les versions en ligne du svn http://svn.apache.org/repos/asf/uima/sandbox/trunk/RegularExpressionAnnotator/resources/.
Le format du fichier est bien explicité dans la documentation en voici une brève synthèse pour une première prise en main.

La définition des concepts est cadrée par un élément racine conceptSet :

<?xml version="1.0" encoding="UTF-8"?>

Un concept a un jeu de règles associées ainsi qu'une opération de création ou de mise à jour définie lors de la reconnaissance d'un motif par une des règles. Ici je ne montre qu'un exemple de création d'annotation.
<concept name="XXX" processAllRules="true">
<rules>
<rule ruleId="XXX"
regEx="XXX"
matchStrategy="matchAll" matchType="XXX" />
</rules>
<createAnnotations>
<annotation type="XXX">
<begin group="0" />
<end group="0" />
</annotation>
</createAnnotations>
</concept>

5.1. Dans un premier temps, il s'agit de définir les éléments du motif requis à minima dans une règle. Dans le cas de notre exemple il s'agit de

locationPreposition À|à|aux?|enLa définition étant une alternative il conviendra de la mettre entre parenthèse dans le motif afin d'éviter d'inclure d'autres parties du motif comme des éléments des alternatives d'extrémité.
properName \p{Lu}\p{Ll}\p{Ll}* Lettre unicode en majuscule, suivi d'une lettre unicode en minuscule et de zéro ou plusieurs lettre unicode en minuscule ; on pourrait discuter de l'intérêt de spécifier ou non la casse pour les caractères suivant le premier \p{L}

On choisit de séparer nos éléments obligatoires par un whitespace character ([ \t\n\x0B\f\r]) qui peut être répété zéro ou n fois (*) ; on utilise la classe prédéfinie \s pour le désigner. Ce qui donne le concept suivant. Le nom (name) du concept est arbitraire. Le nom de la règle (ruleId) est aussi arbitraire mais peut être récupéré au niveau de la manipulation de l'annotation créée/mise à jour. L'attribut regex accueille la définition du motif recherchée. MatchType défini l'espace de recherche et donc d'application de la règle, il s'agit d'une annotation uima.tcas.Annotation avec un begin et un end. Le type d'annotation déclare l'annotation à créer. Celle-ci est supposée être définie dans un type système accessible au composant. La valeur 0 dans l'attribut group des éléments begin et end déclare que l'annotation à créer couvrira la zone délimitée par le motif reconnu.

<concept name="location" processAllRules="true">
<rules>
<rule ruleId="locationPreposition_properName"
regEx="(À|à|aux?|en)\s*\p{Lu}\p{Ll}\p{Ll}*"
matchStrategy="matchAll" matchType="uima.tcas.DocumentAnnotation" />
</rules>
<createAnnotations>
<annotation type="fr.univnantes.lina.uima.types.NamedEntity">
<begin group="0" />
<end group="0" />
</annotation>
</createAnnotations>
</concept>

Le concept ainsi défini fonctionne relativement bien même si l'on constate quelques effets de bord. En effet nos règles ramènent les cas suivants

Le Stade Toulousain enlève la quatrième Heineken Cup de son histoire.

Julien Peyrelongue sur une récupération dans un ruck, trouve une très belle touche dans les 22 mètres toulousains.

5.2. On peut spécifier notre motif aux bornes pour éviter ces effets de bord. Par exemple en ajoutant [\p{Punct}\p{Space}] ou [\P{L}] (noter le grand P pour désigner les caractères complémentaires (cad ici ceux qui ne sont pas des Letters)) au début du regex. Là encore il faudrait réfléchir pour traiter aussi le cas de la reconnaissance de ce motif en début de fichier...
Désormais les cas précédents ne sont plus reconnus néanmoins un caractère contextuel est nouvellement inclu dans la zone couverte par l'annotation créée ; ce qui ne nous convient pas bien entendu...

5.3. Pour annoter seulement la partie du motif qui nous intéresse (et exclure les caractères contextuels par exemple) on peut utiliser la notion de groupe pour cadrer les parties qui nous intéresse. Un groupe de caractères se définit à l'aide d'un parenthésage. Chaque groupe hérite d'un indice qui permet de s'y référer par la suite. Il suffit de faire précéder la parenthèse ouvrante par ?: pour ne pas comptabiliser un groupe.
Ainsi l'on peut définir les sous motifs suivants (?:À|à|aux?|en) et (\p{Lu}\p{Ll}\p{Ll}*), et déclarer la valeur 1 pour l'attribut group des éléments begin et end.
La valeur du regex sera donc regEx="[\P{L}](?:À|à|aux?|en)\s*(\p{Lu}\p{Ll}\p{Ll}*)"

5.4. Il est possible d'utiliser des variables pour simplifier la lecture du regex. En amont et au même niveau des définitions de concepts il s'agit de déclarer des variables (des éléments variable au sein d'un élément variables)

    <variables> 

    <variable name="locPrep" value="À|à|aux?|en" />

    </variables>

On pourra faire appel à la variable locutionPreposition dans la regex à l'aide de l'écriture \v{locutionPreposition} où locutionPreposition est le nom d'une variable définie.
Lorsque les variables désigneront des mots dont la casse n'est pas descriminante on pourra placer le flag (?iu) pour spécifier de ne pas tenir compte de la casse (i, case-insensitive) pour le groupe courant et ce pour n'importe quel caractère unicode (u, unicode).
Ce flag s'ajoutera naturellement à celui de ne pas comptabiliser ce groupe ce qui donnera (?:(?iu)\v{locutionPreposition})

Si l'on rajoute aussi la variable suivante

<variable name="compoundProperName" value="(?:\p{Lu}(?:\p{Lu}|\p{Ll})(?:(?:\p{Lu}|\p{Ll}|-|')*(?:\p{Lu}|\p{Ll}))?)(?:(?:(?:\s*(?:(?iu)des?|de\s*la|de\s*l'|du|d'|van|von|of|da|dal|della|el|al|al-))?)\s*(?:\p{Lu}(?:\p{Lu}|\p{Ll})(?:(?:\p{Lu}|\p{Ll}|-|')*(?:\p{Lu}|\p{Ll}))?))*" />
On obtient

 <variables> 

  <variable name="locutionPreposition" value="À|à|aux?|en" />

  <variable name="compoundProperName" value="(?:\p{Lu}(?:\p{Lu}|\p{Ll})(?:(?:\p{Lu}|\p{Ll}|-|')*(?:\p{Lu}|\p{Ll}))?)(?:(?:(?:\s*(?:(?iu)des?|de\s*la|de\s*l'|du|d'|van|von|of|da|dal|della|el|al|al-))?)\s*(?:\p{Lu}(?:\p{Lu}|\p{Ll})(?:(?:\p{Lu}|\p{Ll}|-|')*(?:\p{Lu}|\p{Ll}))?))*" />

 </variables> 

Ce qui donne au niveau de la regex

    regEx="[\P{L}](?:(?iu)\v{locutionPreposition})\s*(\v{compoundProperName})"

Attention de penser à placer aussi des flags "ne comptabilise pas" au sein des définitions des variables lorsque l'on utilise des groupes en leur sein.

5.5. On peut affecter des valeurs statiques à des traits de l'annotation à créer (autres que begin et end). Ces traits (features) doivent être définis dans le système de type utilisé (ici de fr.univnantes.lina.uima.types.NamedEntity)
Au même niveau que les éléments begin et end d'annotations... On peut rajouter des lignes comme la suivante, laquelle attribue la valeur "location" à un trait category de type String.

       <setFeature name="category" type="String" normalization="Trim">location</setFeature>

5.6. On peut affecter des valeurs à des traits de l'annotation à créer à partir de valeurs correspondant à des sous-chaînes du motif reconnu. Pour ce faire il s'agit de préfixer les groupes de la regex dont on souhaite récupérer la valeur par \m{locationValue} où ici locationValue correspond au nom que l'on a choisi pour désigner cette zone là. Pour faire référence ensuite à cette valeur, on utilisera l'écriture ${locationValue}. Ci-dessous la regex avec le préfixe

    regEx="[\P{L](?:(?iu)\v{locutionPreposition})\s*\m{locationValue}(\v{compoundProperName})"

Et là un exemple d'utilisation
<setFeature name="value" type="String" normalization="Trim">${locationValue}</setFeature>

5.7. On peut récupérer le nom de la règle qui a reconnu le concept. Pour cela il faut que votre Type system déclare l'attribut ruleId dans votre annotation à créer. Vous pouvez alors récupérer la valeur de la règle qui a matché avec un setFeature via le type RuleId.

<setFeature name="ruleId" type="RuleId"/>

Au final vous obtenez

 <variables> 

  <variable name="locutionPreposition" value="À|à|aux?|en" />

  <variable name="compoundProperName" value="(?:\p{Lu}(?:\p{Lu}|\p{Ll})(?:(?:\p{Lu}|\p{Ll}|-|')*(?:\p{Lu}|\p{Ll}))?)(?:(?:(?:\s*(?:(?iu)des?|de\s*la|de\s*l'|du|d'|van|von|of|da|dal|della|el|al|al-))?)\s*(?:\p{Lu}(?:\p{Lu}|\p{Ll})(?:(?:\p{Lu}|\p{Ll}|-|')*(?:\p{Lu}|\p{Ll}))?))*" />

 </variables> 

 <concept name="location" processAllRules="true">

  <rules>

   <rule ruleId="locationPreposition_properName"

    regEx="[\P{L}](?:(?iu)\v{locutionPreposition})\s*\m{locationValue}(\v{compoundProperName})"

    matchStrategy="matchAll" matchType="uima.tcas.DocumentAnnotation" />

  </rules>

  <createAnnotations>

   <annotation type="fr.univnantes.lina.uima.types.NamedEntity">

    <begin group="1" />

    <end group="1" />

    <setFeature name="category" type="String" normalization="Trim">location</setFeature>

    <setFeature name="value" type="String" normalization="Trim">${locationValue}</setFeature>

    <setFeature name="ruleId" type="RuleId"/>

   </annotation>

  </createAnnotations>

 </concept>

5.8. Il est possible d'établir un ordre de priorité entre les règles d'un même concept. Le RegexAnnotator prévoit deux mécanismes. Le premier permet effectivement de commander l'exécution d'une règle plutôt qu'une autre. Le second exécute toutes les règles et laisse le travail de filtrage à réaliser ultérieusement dans d'autres composants... à développer. En ce sens, le second n'est qu'une ébauche.

Le premier mécanisme fonctionne à l'aide de l'attribut booléen processAllRules de l'élément concept. Quand il est à vrai alors toutes les règles sont appliquées, et quand il est faux les règles sont appliquées par ordre d'apparition jusqu'à ce qu'une reconnaisse un motif. La valeur par défaut est faux.

La priorisation est utile si l'on construit des motifs de règles avec différents niveaux de fiabilité. Dans l'exemple que nous avons manipuler, on pourrait construire une règle avec le seul motif équivalent à la variable properName qui aurait un plus grand rappel mais une moins bonne précision que celle que nous venons de définir. On pourrait alors établir un ordre dans la déclaration de ces règles ; cette dernière règle construite apparaissant effectivement en dernier dans l'ordre d'apparition.

Le RegexAnnotator prévoit un second mécanisme à l'aide de l'attribut confidence de l'élément rule. Sa valeur est en effet affectée à une feature du même nom lors de la création d'annotation, et ce de manière analogue à l'attribut ruleId. De manière similaire il faut aussi créer manuellement la feature dans le système de type que l'on utilise. Cette feature doit être de type uima.cas.Float. Le RegexAnnotator ne gère pas de priorisation de validité d'annotations en fonction de cette feature, il laisse à l'utilisateur de développer un composant de post-traitement "qui saura quoi faire" de cette valeur de confiance pour chaque annotation qui aura été posée.

Les Match Type Filter, les Rules Exception et le mécanisme d'Annotation Validation peuvent éventuellement être des moyens détournées d'établir des priorités de manière détournée. Consulter la documentation pour cela.

5.9. De manière détournée, on peut utiliser le RegexAnnotator comme un projecteur de dictionnaires. Pour cela, on peut considérer les entrées du dictionnaire comme différentes valeurs alternatives dans une variable. La règle reprenant cette variable éventuellement on contraignant un peu le contexte d'occurrence.
Il y aura bien entendu des problèmes de performances suivant la taille des dictionnaires et du fait que cela reste de la recherche d'expressions régulières.

5.10. Que peut vous apporter la documentation officielle après ce tutoriel ?

D'autres notions sont présentées parmi lesquelles : l'attribut matchStrategy de l'élément rule, les Match Type Filter, les opérations de mise à jour d'annotations (updateMatchTypeAnnotation), la gestion d'exceptions de règles (Rules Exception), la prévalidation d'annotation avant leur création à l'aide de code java (Annotation Validation), la définition d'une zone d'annotation par rapport à des positions à l'intérieur d'un groupe (Annotation Boundaries)...

6. Quelles limites présentent le composant ?

Par définition, il fait seulement de la reconnaissance de motif de chaîne de caractères et non de motifs qui incluent des contraintes sur la présences d'annotations
Le composant offre au plus deux-trois niveaux d'analyse. Les regex variables sont le premier niveau d'analyse motif textuel, les rules (qui s'appuient sur les regex variables) sont un second niveau d'analyse. On peut éventuellement considérer les capturing groups (lesquels sont définis autour de parties des motifs des règles et servent pour définir certaines valeurs de features d'annotations à créer/mettre à jour) comme un autre niveau.
Il est possible d'établir un ordre de priorité entre les règles d'un même concept mais pas entre concepts. Si l'on a des concepts distincts (nom de personne et nom d'entreprise ou nom de lieu par exemples) qui peuvent avoir des motifs de reconnaissance similaires on ne peut établir de priorités entre eux. Une première solution est de les concidérer comme un unique concept et arbitraitement d'établir des priorités entre les règles de reconnaissance. Outre le côté arbitraire, le concept et le fichier de concept peuvent devenir très complexes. Une seconde solution est de réaliser un post-traitement, c'est-à-dire développer un composant) qui "saura" quoi faire pour deux annotations posées sur la même zone...
La notion de variable peut jouer le rôle de dictionnaires ou lexiques d'éléments possibles pour certains champs variables des règles. La valeur d'une variable est une regex. On peut utiliser l'alternative | pour indiquer différents éléments du lexique ; les éléments pouvant eux-mêmes être des regex. La gestion au sein d'un même fichier des règles et des lexiques n'est pas évidente dans un mode édition ou bien dans un souci de maintenance.
Il n'est pas possible de définir une seule fois des variables et de les faire partager entre plusieurs fichiers de règles.

7. Pour mettre au point vos expressions régulières en java
Le présent post suppose une connaissance de l'écriture des regex notamment la notion de classes de caractères, les constructions spéciales (non capturante de groupe)... Pour en savoir plus :

Installer LeJOS NXJ 8.5beta sous Linux Ubuntu 10.04 LTS (Lynx Lucide) via usb/bluetooth

2011-02-10T02:45:00.000-08:00

Cette page décrit les opérations qu'il m'a fallu réaliser pour flasher ma brique lego NXT afin d'installer le firmware LEJOS à partir d'un système Linux Ubuntu 10.04. Le cas échant je précise les droits qu'il faut pour réaliser les opérations.

Attention bien que je décrive complètement toutes les opérations, il est important de consulter avant tout la page officielle

http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/GettingStartedLinux.htm qui explique et que je complète (et non remplace) avant tout

Outre la page officielle et mon expérience personnelle, cette page s'appuie aussi sur le site suivant

http://videmos.blogspot.com/2009/01/lejos-nxj-installation-on-linux.html.
et celle-ci pour la partie bluetooth http://vikram.eggwall.com/computers/nxt-bluetooth-setup.html

Les pages précédentes contiennent des éléments pour l'installation du plugin Eclipse. Voir aussi les liens suivant

RCX http://www.pobot.org/Java-pour-Mindstorms-RCX.html
NXT (sous windows) http://www.bartneck.de/2008/03/04/java-lego-nxt-eclipse-tutorial/

Prérequis

(requiert des droits sudo ou root pour installer)

1. Avoir un Java Development Kit (JDK) 1.5 ou 1.6 installé sur sa machine et non un Java Runtime Environment (JRE) qui n'est pas suffisant car ne vous permet pas de compiler des programmes java. Conseille le 1.6 pour certains exemples et testé seulement sur le JDK sun.

aptitude install sun-java6-jdk

Mettre à jour ces variables d'environnement PATH pour pointer vers le répertoire JDK bin (Setting up environment variables) ainsi que JAVA_HOME où se trouve installé le JDK

2. Le programme ant permettra la compilation de LeJOS (il peut être rapproché de make)

aptitude install ant

3. Afin de pouvoir compiler sans souci et utiliser les connexions usb et bluetooth, assurez vous aussi d'avoir les dépendances (principalement des driver/pilotes) suivantes installées

aptitude install libusb libusb-dev bluez libbluetooth-dev

A noter que

bluez n'est utile que si on utilise le driver NXTCommBluez à la place de celui par default NXTCommBluecove. La documentation officielle http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/GettingStartedLinux.htm signale que l'on peut le retirer du build/build.xml si l'on n' en a pas besoin. Perso je l'ai compilé aussi.

Installation de Lejos
(ce qui suit peut se réaliser dans un simple compte utilisateur)

1. Récupérez et désarchivez l'archive lejos_NXJ_0_8_5beta.tar.gz (http://lejos.sourceforge.net/nxj-downloads.php) ;

tar -xvzf lejos_NXJ_0_8_5beta.tar.gz

vous obtenez le répertoire lejos_nxj

2. Donnez les droits d'exécution au sous répertoire bin

cd lejos_nxj

chmod a+x bin

3. Puis compilez

cd build

ant

Cette opération copie deux drivers créés, libjbluez.so et libjlibnxt.so, dans le répertoire lejos_nxj/bin. D'autres résultats de compilation peuvent se trouver les répertoires lejos_nxj_native/src (jbluez libnxt nxtvm).

4. Après compilation il vous faut déclarer et mettre à jour quelques variables d'environnement (si vous êtes toujours dans le répertoire lejos_nxj et que vous ne travaillerez que dans ce terminal jusqu'à sa fermeture

export NXJ_HOME=`pwd`

export PATH=${NXJ_HOME}/bin:${PATH}

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH":${NXJ_HOME}/bin

Pour péreniser la modification, éditer votre fichier ~/.bashrc et rajouter les lignes ci-dessus en changeant la valeur de NXJ_HOME par la valeur réelle du chemin. Désormais ces variables seront définies pour tout nouveau terminal ouvert. N'oubliez pas de faire un source ~/.bashrc si vous souhaitez bénéficier de ces modifications dans le terminal où vous venez de faire ces manipulations.

5. L'étape suivante consiste à flasher votre brique lego, en tapant dans un terminal

nxjflash

Si vous obtenez le message suivant

VM file:/.../lejos_nxj/bin/lejos_nxt_rom.bin
Menu file: /.../lejos_nxj/bin/StartUpText.bin
VM size: 52752 bytes.
Menu size: 38016 bytes.
Total image size 91008/94208 bytes.
Locating device in firmware update mode.
No devices in firmware update mode were found.
Searching for other NXT devices.
No NXT found. Please check that the device is turned on and connected.
Alors branchez le cable usb de votre machine à la brique...

Si vous obtenez l'erreur suivante
Error Cannot load a comm driver
Alors réinitaliser la brique manuellement en pressant le bouton caché dans un des trous d'emboitement à l'arrière en haut à gauche de la brique. Puis tapez la commande pendant le toc répétitif.

Si maintenant vous obtenez l'erreur suivante
Error: Failed to open %%NXT-SAMBA%% in SAMBA mode
Alors réalisez l'opération en tant que root (n'oubliez pas de déclarer les variables d'environnement).

Si la manipulation en tant que root ne fonctionne pas
Alors, avec l'aide du post suivant http://ubuntuforums.org/showthread.php?t=1123633, réalisez en tant que root les commandes suivantes

rmmod cdc_acm

nxjflash

modprobe -i cdc_acm

Vous obtiendrez un beau Lejos sur votre brique si tout a bien fonctionné.

Tester votre installation

Rajouter les lignes suivantes à la suite de votre ~/.bashrc en réalisant les opérations de pérénisation décrites ci-dessus.

export CLASSPATH=${NXJ_HOME}/lib/classes.jar:${NXJ_HOME}/lib/jtools.jar:${NXJ_HOME}/lib/pccomm.jar:${NXJ_HOME}/lib/pctools.jar:${CLASSPATH}

export CLASSPATH=${NXJ_HOME}/3rdparty/lib/bcel.jar:${NXJ_HOME}/3rdparty/lib/bluecove-gpl.jar:${NXJ_HOME}/3rdparty/lib/bluecove.jar:${NXJ_HOME}/3rdparty/lib/commons-cli.jar:${NXJ_HOME}/3rdparty/lib/cpptasks.jar:${CLASSPATH}

Compilez un programme (ici le programme View qui permet de tester les moteurs et les capteurs via une interaction directe sur la brique) avec

cd projects/samples/View

nxjc View.java

Téléchargez le programme compilé sur la brique avec

nxj -r View

Si vous obtenez le message suivant via une connexion usb (en supposant que le bluetooth n'est pas activé)
leJOS NXJ> Linking...
leJOS NXJ> Uploading...
leJOS NXJ> Searching for any NXT using Bluetooth inquiry
BlueCove version 2.1.0 on bluez
leJOS NXJ> Failed to find any NXTs
leJOS NXJ> Failed to connect to any NXT
an error occurred: No NXT found - is it switched on and plugged in (for USB)?
BlueCove stack shutdown completed

Alors recommencer la manipulation en tant que root...
ou bien rajouter des un groupe qui a des droits sur le port usb (la doc officielle indique comment)
Il vous faudra recompiler le programme en tant que root (donner les droits d'écriture/exécution sur le répertoire et fichiers).

Via bluetooth, après avoir

installé les paquets bluez et libbluetooth-dev
compilé lego_nxt
déclaré les variables d'environnement ci-dessus
et allumé et activé le bluetooth > power et la visibility sur la brique

Cela (nxjc et nxj) fonctionnent en simple utilisateur...
... lors de l'upload avec nxj il faudra indiquer le pin (défini dans le menu bluetooth de la brique, par défaut 1234)
Et voilà

Pour utiliser le programme

Sur la brique

Bouton orange pour allumer et sélectionner une option qui s'affiche sur l'écran (descend dans l'arborescence)
les flèches de gauche et de droite pour naviguer dans le menu
le bouton rectangulaire pour revenir en arrière (remonter dans l'arborescence) et éteindre si vous êtes au niveau le plus haut

Dans Files vous verrez les programmes disponibles sur la brique (il y en a 1 qui s'appelle "view"), il peut être mis en "default"

Quand vous exécutez "view", vous pourrez tester les sensors et les motors. Allez y ca marche !

Le mode bluetooth est à activer si besoin est !

Le volume du son peut être fixé et coupé.

Ne toucher à qu'il y a dans system si seulement vous savez ce que vous faites !!!

D'autres programmes

http://lejos.sourceforge.net/nxt/nxj/tutorial/WheeledVehicles/WheeledVehicles.htm

Nombre d'occurrences et fréquence d'un terme

2010-11-21T06:15:00.000-08:00

Le nombre d'occurrences d'une forme (dans un document, une collection) correspond au nombre de fois que cette forme apparaît.

La fréquence (sous entendu d'occurrence) d'une forme d'un document correspond au nombre d'occurrences de la forme dans le document relativement à la somme du nombre d'occurrences de toutes les formes (éventuellement * 100 pour avoir un poucentage) du document (on pourrait changer document par collection)

Souvent la notion de fréquence est abusivement confondue avec le nombre d'occurrences.

La somme du nombre d'occurrences de toutes les formes constitue une normalisation du nombre d'occurrences. Le nombre d'occurrence rend compte de "l'importance" d'un terme. La normalisation du nombre d'occurrences d'un terme rend possible la comparaison de deux documents de longueurs différentes.

On peut aussi normaliser par un $log_10$ : de [1 occurrence;+inf) dans [0;4[ (à peu près).

Alimenter son LinkedIn, Twitter, Dokuwiki... avec un flux RSS

2010-10-21T14:40:00.000-07:00

Dernière mise à jour : vendredi 22 octobre 2010

En tant que chercheur il est important de communiquer sur ses activités aux différentes communautés auxquelles on appartient.

Le propre du Web 2.0 est de facilement diffuser du contenu et d'en construire de nouveaux à partir d'existants (ainsi que d'en modifier aisément leur forme). C'est le principe de base des réseaux sociaux. LinkedIn, Twitter et Dokuwiki font parties de ces vecteurs de communication du moment.

Néanmoins on ne peut passer son temps à alimenter ces vecteurs, a fortiori quand il s'agit de diffuser la même information sur chacun d'eux !

La solution que j'ai choisie pour communiquer et éviter de perdre du temps dans la recopie des informations que je souhaite communiquer est de tenir ce blog et d'offrir un accès à son contenu à l'aide d'une syndication RSS que j'inscris aux différents réseaux sociaux que j'utilise.

Une seule entrée et autant de sorties que les applications le permettent. Une bonne application web 2.0 doit pouvoir se nourrir de flux RSS (éventuellement filtrés par le biais des tags) ainsi que pouvoir alimenter d'autres applications.

Pour LinkedIn : au moins deux moyens

soit avec l'application blog link
soit en créant un groupe, et par le menu "Manage News Feeds" ajouter le flux RSS que vous souhaitez "manger"

Pour twitter http://twitterfeed.com/
Pour Dokuwiki, il suffit d'insérer le code suivant {{rss>http://enicolashernandez.blogspot.com/feeds/posts/default 8 author date 1h }}

Ici 6 raisons qui font de votre blog votre meilleur outil social et là quelques passerelles entre d'autres outils sociaux

Conférences et journaux sur les aspects ingénierie de la langue

2010-10-14T07:48:00.000-07:00

Une version statique et perenne de ce post ici.

Conférences

ICTAI : International Conference on Tools with Artificial Intelligence
IAAI: Innovative Applications in AI
DocEng: ACM Symposium on Document Engineering
LREC: Language Resources and Evaluation Conference
AIMSA: Artificial Intelligence: Methodology, Systems, Applications
IJAIT: International Journal on Artificial Intelligence Tools (rang 2)

Journaux

Natural Language Engineering meets the needs of professionals and researchers working in all areas of computerised language processing, whether from the perspective of theoretical or descriptive linguistics, lexicology, computer science or engineering. Its aim is to bridge the gap between traditional computational linguistics research and the implementation of practical applications with potential real-world use. As well as publishing research articles on a broad range of topics ¿ from text analysis, machine translation, information retrieval and speech analysis and generation to integrated systems and multi modal interfaces ¿ it also publishes special issues on specific areas and technologies within these topics, an industry watch column and book reviews.
Language Resources and Evaluation is the first publication devoted to the acquisition, creation, annotation, and use of language resources, together with methods for evaluation of resources, technologies, and applications. Language resources include language data and descriptions in machine readable form used to assist and augment language processing applications, such as written or spoken corpora and lexica, multimodal resources, grammars, terminology or domain specific databases and dictionaries, ontologies, multimedia databases, etc., as well as basic software tools for their acquisition, preparation, annotation, management, customization, and use. Evaluation of language resources concerns assessing the state-of-the-art for a given technology, comparing different approaches to a given problem, assessing the availability of resources and technologies for a given application, benchmarking, and assessing system usability and user satisfaction.
La revue Document Numérique publie des articles qui concernent la gestion des documents. Dans ce cadre, il s'agit des documents vus comme supports ou comme finalité d'un processus. Cet aspect concerne les étapes du processus éditorial technique de workflow et de groupware et de reengineering des processus… Les documents sont considérés sous leurs représentations les plus diverses : document image, document révisable, document structuré, document composé d'objets. Les supports jouent un rôle important. Les outils nécessaires à chacune des étapes du processus éditorial sont décrits, ainsi que les aspects juridiques des documents numériques et les méthodes de mise en oeuvre. http://dn.revuesonline.com/ (Hermes / Lavoisier - http://www.revuesonline.com/)
La revue d'Ingénierie des Systèmes d'Information (ISI) est constituée de numéros thématiques faisant chacun le point sur un aspect traditionnel ou émergent dans le domaine des bases de données et des systèmes d'information. Le domaine des systèmes d'information représente « l'étude des utilisations efficaces de l'information et de son impact potentiel sur les systèmes logiciels et sur les technologies de l'information sur le monde des humains, de l'organisation et du social » (Cushing et Lucas, 1990). La revue d'Ingénierie des Systèmes d'Information est donc destinée à faire le point plusieurs fois par an sur un aspect spécifique des systèmes d'information. Dans cette optique, une personnalité reconnue du domaine sera sollicitée pour prendre la responsabilité d'un numéro spécial. http://isi.revuesonline.com/Publication en français et en anglais (Hermes / Lavoisier - http://www.revuesonline.com/ ; Revues des Sciences et Technologies de l'Information (RSTI))
Revue pluridisciplinaire destinée à offrir un outil de synthèse aux chercheurs et industriels français en informatique, la revue de Technique et Science Informatiques (TSI) favorise la publication rapide des travaux et fournit un support de transfert bidirectionnel des connaissances entre recherche et industrie. Les articles sont regroupés en trois rubriques scientifiques : synthèse, application et recherche. TSI, la seule revue française de haut niveau en informatique scientifique et technique : rend compte plus rapidement des évolutions scientifiques, couvre de manière plus active les différents champs de connaissance : architectures, bases de données et de connaissances, intelligence artificielle, génie logiciel, concurrence, communication, parallélisme,… réalise des numéros thématiques qui présentent systématiquement des synthèses des domaines scientifiques concernés. http://tsi.revuesonline.com/ (Hermes / Lavoisier - http://www.revuesonline.com/ ; Revues des Sciences et Technologies de l'Information (RSTI))

Sélection d'articles de ACL'2010

2010-10-14T07:39:00.000-07:00

Sélection d'articles d'ACL'2010 sur l'analyse du discours en général

Discours

P10-2028 [bib]: Minwoo Jeong; Ivan Titov Unsupervised Discourse Segmentation of Documents with Inherently Parallel Structure
P10-1120 [bib]: Amit Dubey The Influence of Discourse on Syntax: A Psycholinguistic Model of Sentence Processing
P10-1073 [bib]: WenTing Wang; Jian Su; Chew Lim Tan Kernel Based Discourse Relation Recognition with Temporal Ordering Information
P10-5003 [bib]: Bonnie Webber; Markus Egg; Valia Kordoni Discourse Structure: Theory, Practice and Use

Co-reference

P10-1142 [bib]: Vincent Ng Supervised Noun Phrase Coreference Research: The First Fifteen Years
P10-1144 [bib]: Marta Recasens; Eduard Hovy Coreference Resolution across Corpora: Languages, Coding Schemes, and Preprocessing Information
P10-1143 [bib]: Cosmin Bejan; Sanda Harabagiu Unsupervised Event Coreference Resolution with Rich Linguistic Features
P10-1128 [bib]: Ryu Iida; Syumpei Kobayashi; Takenobu Tokunaga Incorporating Extra-Linguistic Information into Reference Resolution in Collaborative Task Dialogue

Réutiliser des outils externes via des commandes shell dans un composant UIMA

2010-10-04T22:25:00.000-07:00

Parce que de nombreux outils de TAL non-natifs UIMA sont utilisés par la communauté, parce que ces outils ont souvent requis des investissements conséquents en fonds financiers et en temps de développement, il est nécessaire de se poser la question de la possibilité de réutilisation de ces outils au sein de chaînes de traitement UIMA avant d'en développer des équivalents en natif.

Le présent composant UIMA shell a pour objet l'implémentation d'un Analysis Engine permettant l'exécution d'une commande shell sur un élément du CAS (Common Analysis Structure) et l'enrichissement du CAS avec le résultat du traitement. L'entrée de la commande peut être soit le SofaDataString d'une vue spécifiée, soit le texte couvert par un type d'annotation (lesquelles elles-même apparaîssent optionnellement dans certains contextes marqués par un autre type annotation). La sortie peut être produite soit sous la forme d'un SofaDataString d'une nouvelle vue créée pour l'occasion ou bien comme valeur d'une feature de type String d'une annotation spécifiée elle aussi créée pour l'occasion.

Son principal objectif est donc de permettre d'utiliser au sein d'une chaîne UIMA des outils accessibles en ligne de commande, lesquels réalisent leur traitement soit sur l'entrée standard (stdin) soit sur un fichier via son nom passé en argument et produisent leur résultat sur la sortie standard (stdout).

L'implémentation présente les caractéristiques suivantes :

utilisation de l'API shell de F Martini (distribuée sous licence CeCILL-C), laquelle permet de simplifier l'exécution de programme et de ligne de commande depuis Java
gestion de multiples formats des commandes à exécuter où la donnée à traiter peut aussi bien provenir de l'entrée standard ou constituer un fichier texte passé en argument, être récupéré du système de fichier, pipé, redirigé...
traitement de la commande shell sous forme d'un thread
paramétrage libre et générique des éléments du CAS (view/annotation/feature) d'entrée (à traiter) et de sortie (à créer) notamment à l'aide de l'API java.lang.reflect (constitue des exemples de code générique)

La suite de ce travail pourra être la conception d'un composant type connecteur permettant de récupérer sous forme de types des informations structurées contenues dans des fichiers au format CSV-like (Comma Separated Value), XML... quelle que soit la sémantique de leur structure.

Le code source du composant est disponible sur http://code.google.com/p/uima-shell/

UIMA Type mapping

2010-10-03T14:27:00.000-07:00

Lorsque l'on souhaite développer un composant à l'aide de l'architecture Apache UIMA, celle-ci requiert de définir les types d'information que l'on souhaite manipuler ainsi que leur organisation ; on appelle cela définir son système de types. D'un point de vue conception de logiciel, cela permet notamment de réaliser un contrôle syntaxique des entrées et des sorties des composants.

Apache UIMA offre la liberté de définir son propre système de types et par conséquent plusieurs systèmes de types peuvent être proposés pour modéliser les mêmes informations. Cette liberté de définition de systèmes de types peut donc conduire à des problèmes d'interopérabilité entre des composants manipulant des informations conceptuellement identiques mais étant en pratique définies par des modélisations distinctes.

Par exemple, word, mot voire token sont des noms différents qui peuvent éventuellement être utilisés pour désigner le même type d'information.

Le uima-type-mapper est un composant qui offre un moyen de conversion d'annotations définies par un système de type donné (appelé type source) vers des annotations définies par un autre système de types (appelés types cibles). En pratique, il permet de faire le pont entre des composants manipulant des annotations ayant des types d'information conceptuellement identiques mais de noms distincts. Les annotations produites par un premier composant peuvent être utilisées en entrée d'un second via notre composant qui réalise la conversion.

Les conversions sont déclarées à l'aide de règles qui spécifient pour des types source donnés de réaliser une opération de création d'une ou plusieurs annotations de types cible aux offsets des annotations de type source rencontrées. Il est possible de spécifier des contraintes sur les caractéristiques de annotations de type source. La cohérence sémantique des types à convertir est laissée libre à l'utilisateur.

En pratique, l'implémentation repose sur

W3C XPath comme langage déclaratif d'expression des contraintes sur la structure des types des annotations source
Apache JXPath comme moteur qui implémente le traitement des règles
java.lang.reflect API pour rendre générique le composant en autorisant la désignation de tout type héritant de uima.tcas.Annotation pour faire l'objet de conversion

La fonction de spécification de contraintes sur les annotations à convertir peut conduire à utiliser ce composant comme un composant d'analyse à base de règles des structures sémantiques UIMA. En effet, le composant peut être utilisé pour réaliser de la reconnaissance de motifs d'annotations au sein d'une structure d'annotations UIMA et de la réalisation d'opérations sur les(/relativement aux) motifs reconnus telles que la création d'annotations, la mise à jour d'annotations, et la suppression d'annotations. Actuellement seule la première opération est gérée, mais les fonctions déjà implémentées dans le composant en font de lui une preuve de concept.

Si vous utilisez ce travail dans vos travaux de recherche, merci de citer l'article suivant

Nicolas Hernandez, Fabien Poulard, Matthieu Vernier, Jérôme Rocheteau, "Building a French-speaking community around UIMA, gathering research, education and industrial partners, mainly in Natural Language Processing and Speech Recognizing domains", LREC 2010 Workshop 'New Challenges for NLP Frameworks', La Valleta : Malta

Le code source du composant disponible sur http://code.google.com/p/uima-type-mapper/

Sélection d'articles de LREC'2010

2010-05-20T05:53:00.000-07:00

En général avant chaque participation à un colloque, je sélectionne une série d'articles qui couvrent mes intérêts de recherche.

Par ailleurs depuis le début de l'année universitaire 2010, nous essayons toutes les trois semaines environ de faire un point biblio sur un colloque du moment. Chacun lit un article en prévision de la rencontre et éventuellement après un rapide tour de table des articles lus, si l'assistance le souhaite le présente pendant une dizaine de minutes. Ces réunions sont informelles, interactives et durent 30 à 45 minutes.

Autant faire partager ce travail. Parmi les thèmes qui m'intéressent il y a l'analyse du discours, les architectures de TAL et les outils d'analyse générique, et l'extraction d'information/connaissances.

J'essayerai d'être systématique sur le thème de l'analyse de discours.

Ci-dessous une première sélection issue de LREC'2010

58 Nathanael Chambers and Dan Jurafsky A Database of Narrative Schemas
330 Raffaella Bernardi, Manuel Kirschner and Zorana Ratkovic Context Fusion: The role of Discourse Structure and Centering Theory
184 Sara Tonelli, Giuseppe Riccardi, Rashmi Prasad and Aravind Joshi Annotation of Discourse Relations for Conversational Spoken Dialogs
336 Xuchen Yao, Irina Borisova and Mehwish Alam The PDTB XML: the XMLization of the Penn Discourse Treebank 2.0
479 Amal Al-Saif and Katja Markert The Leeds Arabic Discourse Treebank: Annotating Discourse Connectives for Arabic
481 Ioana Vasilescu, Sophie Rosset and Martine Adda-Decker On the role of discourse markers in interactive spoken question answering systems
582 Stergos Afantenos, Pascal Denis and Philippe Muller Learning Recursive Segments for Discourse Parsing
796 Markus Egg and Gisela Redeker How complex is discourse structure?
820 Rui Wang and Caroline Sporleder Constructing a Textual Semantic Relation Corpus Using a Discourse Treebank
935 Rashmi Prasad and Aravind Joshi Shallow Discourse Parsing: Exploiting Sentence Position and Paragraph Structure for Classifying Connectives and Identifying their Arguments

Dans quel repertoire deposer ses ressources UIMA ?

2010-04-22T07:11:00.000-07:00

Où déposer ses ressources ? Le post suit un rapport des répertoires de ressources UIMA existants.

Le CMU est un répertoire public. Il est possible de déposer/retirer des pears de 25 Mo maximum. Ceux-ci sont automatiquement vérifiés comme étant des pears. Cela marche avec Apache UIMA 2.3. Un service de dépot de ressources autres est indiqué mais ne semble pas fonctionner/ être disponible.

Concenant le répertoire Apache, il est possible de déposer une contribution chez Apache moyennant le respect de certaines conditions et en suivant une certaine procédure.

Les 3 répertoires suivants, DKPro, Julie lab, et U-Compare
sont privés. On ne peut faire que de la récupération de l'existant.

Le répertoire de uima-fr.org accueille indifféremment tout type de ressources (outils, composants, documentation, ...) dans différents formats. Il n'offre pour l'instant pas d'outil automatique de soumission et de gestion de ressoures et il convient de contacter les coordinateurs pour déposer une ressource.

Repertoires de ressources UIMA (outils, composants, documentations)

2010-04-16T07:43:00.000-07:00

Un bref coup d'oeil sur les dépots de ressources UIMA existant dans le monde. J'en compte disponibles en Allemagne, au Royaume Uni, au Japon, aux USA et depuis peu en France.

the LTI repository at the Carnegie Mellon University
the Apache repository
the DKPro repository at the Darmstadt University *
the Julie lab repository at the Jena University **
the U-Compare project repository ***
et bien entendu le depot de uima-fr.org promu notamment par le LINA de l'Université de Nantes ****

* Iryna Gurevych, Max Mühlhäuser, Christof Müller, Jürgen Steimle, Markus Weimer, and Torsten Zesch and. 2007. Darmstadt knowledge processing repository based on uima. In Proceedings of the First Workshop on Unstructured Information Management Architecture at Biannual Conference of the Society for Computational Linguistics and Language Technology, Tübingen, Germany.

** Udo Hahn, Ekaterina Buyko, Katrin Tomanek, Scott Piao, John McNaught, Yoshimasa Tsuruoka, and Sophia Ananiadou. 2007. An annotation type system for a datadriven nlp pipeline. In The LAW at ACL 2007 – Proceedings of the Linguistic Annotation Workshop, pages 33– 40. Prague, Czech Republic, June 28-29, 2007. Stroudsburg, PA: Association for Computational Linguistics.

*** Yoshinobu Kano, Luke McCrohon, Sophia Ananiadou, and Junichi Tsujii. 2009. Integrated NLP evaluation system for pluggable evaluation metrics with extensive interoperable toolkit. In Proceedings of the Workshop on Software Engineering, Testing, and Quality Assurance for Natural Language Processing (SETQA-NLP 2009), pages 22–30, Boulder, Colorado, June. Association for Computational Linguistics.

**** Nicolas Hernandez, Fabien Poulard, Matthieu Vernier, et Jérôme Rocheteau. 2010. Building a French-speaking community around UIMA, gathering research, education and industrial partners, mainly in Natural Language Processing and Speech Recognizing domains. To appear in LREC Proceedings 2010, Malta.

Modifier le Build Path de votre projet Eclipse

2010-03-26T14:54:00.001-07:00

Le Build Path peut se définir à la création du projet

Créer un nouveau Projet Java : File > New > Java Project >
Donner un Project Name et vérifier le JRE (>=1.5) > Next > Libraries (vous pourrez toujours modifier par la suite ces déclarations grâce au menu Properties de votre projet, voir ci-dessous)

Par la suite, vous pouvez le modifier selon différentes alternatives

Dans la vue Package Explorer cliquer droit sur

la racine projet >

Properties > Java Build Path > Libraries
ou Build Path > Configure Build Path > Libraries

Referenced Libraries > Build Path > Configure Build Path > Libraries

Dans Libraries, vous pouvez ajouter les packages

soit par Add External Jar

soit par Variable qu'il vous faudra étendre voire définir le répertoire qu'elle désigne. Préférez cette démarche qui faciliter la portabilité du projet au sein de différents workspaces

Créer un projet Eclipse pour le développement d'un composant UIMA

2010-03-26T08:43:00.000-07:00

Jérôme Rocheteau décrit en détail comment mettre en place un projet Eclipse pour le développement d'un composant UIMA en expliquant comment activer la gestion de dépendances vers les bibliothèques uimaj-core et uimaj-tools avec Maven.

L'usage de Maven est utilisé par les gens d'Apache. Il est recommandé lorsqu'on fait du développement conséquent. Mais il requiert l'installation de plugin et un accès réseau au moins à la création pour la récupération des dépendances.

Je détaille ici une approche sans Maven, en particulier l'étape de création du projet, l'ajout de la UIMA Nature (qui requiert elle aussi l'installation de plugins eclipse disponibles dans un sous répertoire de votre UIMA_HOME depuis la 2.3) ainsi que la déclaration manuelle les dépendances qui vont bien dans le projet Eclipse et la déclaration des répertoires qui peut être utilise à ajouter au build path.

CREER UN PROJET ECLIPSE POUR LE DÉVELOPPEMENT D'UN COMPOSANT UIMA

Créer un nouveau Projet Java : File > New > Java Project >
Donner un Project Name et vérifier le JRE (>=1.5) > Next > Libraries (vous pourrez toujours modifier le Build Path de votre projet Eclipse)
Ajouter les dépendances uima-core, uima-tools, uima-cpe et uima-document-annotation présentes dans UIMA_HOME/lib :

soit par Add External Jar
soit par Variable qu'il vous faudra étendre voire définir le répertoire qu'elle désigne. Préférez cette démarche qui facilite la portabilité du projet au sein de différents workspaces
Cette manipulation n'est pas nécessaire quand vous utilisez Maven

Finish
Ajouter la UIMA Nature : Dans la vue Package Explorer cliquer droit sur le projet > Add UIMA Nature
Ajouter les répertoires desc et resources au build path (Bouton droit sur les répertoires et Build Path > Add to Build Path)

Construire une chaîne de traitement UIMA à partir de composants existants

2010-03-26T07:20:00.000-07:00

Mis à jour le 5 Janvier 2012

Apache UIMA utilise le même type de fichier de description pour désigner un composant ou une chaîne de traitement. On peut d'ailleurs voir un composant comme une chaîne de traitement qui a minima ne compte qu'un seul composant à exécuter. Le fichier descripteur est

soit configuré comme primitif si il désigne un traitement élémentaire. La classe implémentant le traitement sera alors désignée.
soit configuré comme aggregate si le descripteur référence d'autres descripteurs de fichiers primitif ou aggregate.

C'est de cette manière que l'on peut réaliser de l'encapsulation de traitement.

Le lien suivant explique comment exécuter une chaîne de traitement existantes avec UIMA (en ligne de commande, par un GUI hors Eclipse, au sein d'Eclipse).

Ces utilisations sont illustrées avec des descripteurs présents dans les exemples de code fourni avec UIMAJ. Dans le cadre de ce post nous allons utiliser des composants UIMA Annotator Addons, à savoir le

WhiteSpaceTokenizer qui découpe en mots, TokenAnnotation, et phrases, SentenceAnnotation, un texte fourni en entrée
SnowballAnnotator qui effectue une racinisation des TokenAnnotations et rajoute un trait stem aux TokenAnnotation
Tagger qui rajoute un trait posTag aux TokenAnnotation

Le lien suivant explique comment installer les Apache UIMA Addons Annotators et Tools (en gros il s'agit de récupérer le binary des addons de la page http://uima.apache.org/downloads.cgi et de le désarchiver dans UIMA_HOME).

Nous réaliserons la construction de notre chaîne à partir d'Eclipse qui offre, à travers ses plugins, les éditeurs de descripteurs qui nous facilitent la tâche.

Créer un projet Eclipse pour le développement d'un composant UIMA
Rendre accessible à votre projet les jar des composants que vous souhaitez utiliser :

ajouter dans votre build path les jars des composants des composants que vous souhaitez manipuler. Personnellement je le fais en étendant la variable UIMA_HOME et en parcourant le répertoire addons/annotator... mais cela suppose que vous ayez installer les addons dans le répertoire d'installation de UIMA.
Les jars des addons contiennent en général les descripteurs qui permettent d'utiliser les composants. Le build path rend accessible "by name" les descripteurs... Cela est nécessaire pour spécifier par la suite à notre chaine de traitement quels sont les composants à utiliser.
Vous n'avez pas de à placer les ressources de ces composants dans le répertoire resource, elles sont elles aussi accessible via le build path.

Dans la vue Package Explorer cliquer droit sur le répertoire desc du projet > New > Other > UIMA > optez pour "Analysis Engine Descriptor File" > Donner lui un nom

Astuce : je crée un sous-répertoire dans desc qui porte le nom du projet (cela aide à s'y retrouver lorsqu'il y a plusieurs des descripteurs définis dans un CLASSPATH).
Astuce : je spécifie le nom des descripteur d'Analysis Engine avec le suffixe AE pour les distinguer des descripteurs de Type System (suffixe TS) par exemple.

Dans la vue Package Explorer cliquer droit sur le fichier descripteur que vous venez de créer > Open With > Component Descriptor Editor
Sur l'onglet "Overview", spécifier l'engine type : Aggregate
Sur l'onglet "Aggregate",

le bouton "Add" permet d'ajouter des composants présents dans le build path de votre projet. Par exemple les CR/CC de uima-tools. Privilégiez des import "By name". "By Location" permet d'ajouter des composants n'importe où sur votre système de fichier moyennant la spécification ultérieur de son descripteur.
Le bouton "Find AE" permet de chercher tous les descripteurs des composants développés sous forme de projet Eclipse actuellement "ouvert" dans votre Workspace y compris le projet courant. Sans spécification, il retourne tous les descripteurs. Privilégiez des import "By name".
Le Bouton "Add Remote" permet d'ajouter des composants déployés sur des machines distantes
Ajouter les descripteurs "WhiteSpaceTokenizer", "SnowballAnnotator" et "HmmTagger"dans cet ordre avec le boutton "Add"

Sur l'onglet "Capabilities", cliquer sur "add Type" et cliquer sur les cases in/out de chaque type.
Exécuter la chaîne (voir la section Exécuter sous Eclipse)

TODO

Installer et utiliser des composants par runPearInstaller.sh
Déployer un composant pour un accès distant et ajouter des composants distants dans une chaîne locale
Utiliser le flow controler
Utiliser les UIMA Annotators Addons : OpenCalais Annotator s'interface avec un service web ; Dictionnary et RegExp Annotator requièrent l'ajout de ressources

Gestion du temps - lois et degrés de priorité

2010-03-13T01:36:00.000-08:00

D'après les commentaires et l'adaptation de Pierre STOUFF d'un document qu'il a reçu lors d'une formation sur la gestion du temps

LOIS
Loi de Carlson ou loi des séquences homogènes de travail

" Tout travail interrompu sera moins efficace et prendra plus de temps que s'il était effectué de manière continue"

Loi de Parkinson ou loi de la tendance à l'auto-inflation du temps dépensé

"Le temps investi dans un travail en fonction du temps disponible"

LOI D'ILLITCH ou loi de la contre-productivité du temps investi au-delà d'un certain seuil

"Au delà d'un certain seuil horaire, la productivité du temps investi décroit puis devient négative"

UNE ACTIVITE EST URGENTE SI

"Une activité est urgente si... sa non réalisation immédiate entraîne (avec une forte probabilité) des conséquences nuisibles, irréversibles, irrémédiables. L'urgence est souvent provoquée par l'extérieur."

UNE ACTIVITE EST IMPORTANTE SI

"Une activité est importante si... elle contribue à la réalisation des objectifs de la fonction"

ORGANISER C'EST

"Organiser, c'est remettre régulièrement en cause ce qui existe pour l'améliorer."

LES DEGRES DE PRIORITE

Se concentrer sur un nombre limité de priorités (3 à 5 dans la plupart des cas), privilégier l'importance (contributions, résultats) par rapport à ce qui est urgent (délai, échéance).

= IMPORTANT ET URGENT (doit être fait cette semaine)
= IMPORTANT (peut attendre à la semaine suivante)
= URGENT (à faire prochainement)

Installer et utiliser UIMA TextMarker

2010-02-16T10:45:00.000-08:00

Mise à jour le 15 Mars 2011

Ce post fut initialement écrit pour la version TextMarker_1.0.0.201002031959.

Il a été révisé pour la version courante qui est TextMarker_1.0.0.201102241433

La prochaine version est attendue pour... ?

TextMarker est avant tout une bibliothèque libre (licence LGPL) pour le développement d'applications d'extraction d'information à base de règles

sur des éléments de surface et des annotations existantes

. En tant que bibliothèque il peut s'utiliser relativement simplement au sein d'un Analysis Engine d'Apache UIMA.

C'est aussi un environnement de développement au sein d'Eclipse base sur le framework DLTK

(Dynamic Languages Toolkit)

qui offre via ses plugins un éditeur de règles, des composants pour l'explication de l'inférence des règles et un processus de construction d'Analysis Engines et Systemes de Types.

Il est développé par Peter Kluegl and Martin Atzmueller and Frank Puppe à l'unversité de Wuerzburg (de).

La documentation s'est enrichi considérablement entre 2010/02 et 2011/02. Un certain nombre de dépendances, et de possibilités d'utilisation font que ce n'est pas toujours évident de comprendre comment le faire fonctionner.

Il est possible de l'utiliser hors Eclipse (cf. FAQ), voir pour cela le post Utiliser UIMA TextMarker au sein d'un Analysis Engine (i.e. hors Eclipse).

INSTALLER AU SEIN D'ECLIPSE
La page d'installation référence deux approches possibles soit automatiquement via des sites updates soit manuellement en copiant manuellement les bons plugins et features dans les sous répertoires d'Eclipse.

Installation automatique au sein d'Eclipse 3.5 via les updates sites
Un update site se déclare via le menu (Help > Install new softwares). Il peut être utile (si des problèmes sont rencontrés) de redémarrer Eclipse entre chaque installation à l'aide de la commande eclipse -clean.

Ajouter http://www.apache.org/dist/uima/eclipse-update-site UIMA (version 2.3) Update site ;
Ajouter http://download.eclipse.org/technology/dltk/updates-dev/1.0 DLTK Core Framework (version 1.X) update site pour plugins ; Attention TextMarker utilise actuellement DLTK 1.0 et Eclipse 3.6 update site fournit seulement DLTK 2.0
Ajouter http://download.eclipse.org/releases/galileo Eclipse Modeling Framework (EMF) ; (probablement déjà disponible dans vos Available Sofware Sites) ;

L'installation de TextMarker ci-dessous conduira Eclipse à récupérer ce qu'il faut sur les updates site ajoutés ci-dessus.

Ajouter http://ki.informatik.uni-wuerzburg.de/~pkluegl/updatesite TextMarker update site ; sélectionner "Work with", déselectionner "Group items by category" et sélectionner "Contact all update sites during install to find required software", sélectionner le TextMarker feature. Le CEV feature est déjà contenu dans le TextMarker feature.
Optionnel : Si vous désirez des visualisations HTML alors installer aussi le CEV HTML feature présenté lors de l'update de TextMarker. Par contre ajouter d'abord les XPCom puis XULRunner features http://ftp.mozilla.org/pub/mozilla.org/xulrunner/eclipse/
Personnellement lors de l'installation de 2011/02 XPCom a pu s'installer mais pas XULRunner, il manquait des dépendances dans les update sites.

Installation manuelle au sein d'Eclipse 3.5

L'installation peut aussi être manuelle en copiant le contenu des répertoires plugins et features de l'archive de TextMarker dans les répertoires de même nom d'Eclipse (contient CEV feature et HTML feature). Ce que j'ai finalement fait en 2011/02.

UTILISER TEXTMARKER AU SEIN D'ECLIPSE

A partir du Getting Started on déduit les étapes suivantes

Initialiser avec

Importer le projet exemple dans votre workspace
Ouvrir la perspective TextMarker (Window > Open Perspective)
Stopper la construction automatique, nettoyer et relancer la construction afin de configurer les bons chemins dans tous les composants générés (Project > Stop Build Automatically and do Clean)

Exécuter avec

Vous pouvez ouvrir les fichiers.tm présents dans scripts avec le TextMarker Source Editor (Ouvrir avec > TextMarker Source Editor) ; mais ce ne sont que des fichiers textes
Supprimer les fichiers présents dans output
Lancer TextMarker en cliquant bouton droit Run As > Text Marker et en selectionnant Main.tm ; rien d'apparent ne se produit, mais le répertoire output se remplit à nouveau

Constater que cela marche

Le répertoire output se remplit
Faire un open with Web Browser sur les fichiers html du répertoire output pour visualiser le résultat du traitement
Le mieux est de lancer un annotation viewer pour visualiser les annotations contenus dans le XMI ; un simple éditeur XML peut faire cela aussi sinon : Run as > Run configurations > Java Applications > org.apache.uima.tools.AnnotationViewerMain en spécifiant en input le répertoire output de TM et en spéciant comme TypeSystem le descriptors/de/uniwue/example/MainTypeSystem.xml. Attention il se peut que vous ayez besoin de lancer cela d'un projet java où les lib de UIMA sont déclarés et avec une copie du répertoire descripteurs de TM déclaré en répertoire source (éventuellement un jcasgen dans le MainEngine.xml)

Si des problèmes se produisent,

Problème avec le data path lors de l'exécution, vous pouvez effectuer ce que la note suivante indique

Clean and rebuild the example project in order to set the correct paths in all generated components (also the path to the main script location). If the builder preference "import by name" is activated, then a new TextMarker project should rather be created in order to automatically include the correct UIMA datapath. Simply copy all elements into the newly created project afterwards.

A noter que

Pour spécifier un data path à utiliser pour trouver une resource by name faire sur le projet bouton droit > Properties > UIMA CDE Property page > entrer autant de chemins absolus que souhaités séparés par le séparateur de classpath
Pour configurer la résolution des imports à la création des descripteurs ou pour utiliser des imports by name à la création des descripteurs faire Window > Preferences > TextMarker > Builder

Problème de "Interpreter installation TextMarker Interpreter does not exist" lors de l'exécution

non résolu... je cherchais éventuellement à modifier le build path pour lui indiquer les deux bibliothèques importantes, mais cela ne semble pas fonctionner.

Pour aller plus loin dans la compréhension du projet exemple

LIENS

Téléchargement : https://sourceforge.net/projects/textmarker/)
Documentation : http://tmwiki.informatik.uni-wuerzburg.de

Récupérer des plugins Eclipse hors IDE

2010-02-14T12:40:00.000-08:00

Souhaitant automatiser la procédure de récupération et d'installation d'Eclipse, j'ai aussi cherché à récupérer automatiquement les plugins à partir du web.

Cela m'a conduit à produire le script get-and-install-eclipse-plugins.sh

Ce script prend en entrée l'url d'un site distributeur de plugins eclipse, le nom sous lequel vous souhaitez archiver les plugins récupérés et optionnellement la racine du répertoire d'Eclipse dans lequel vous souhaitez installer les plugins.
Le script récupére le fichier artifacts.xml sur lequel il s'appuie pour récupérer les jar plugins et features correspondants au plugin spécifié.
Si plusieurs versions des jars sont disponibles, il récupère la plus récente.
Le script fonctionne sous Ubuntu avec Bash et Perl.

Télécharger sur http://e.nicolas.hernandez.free.fr/pro/doku.php?id=misc:software:get-and-install-eclipse-plugins

Scripts de téléchargement et d'installation d'un environnement pour utiliser Apache UIMA (>2.3) et développer avec sous Eclipse

2010-02-07T14:58:00.000-08:00

Afin de me faciliter la vie, ainsi celles de mes étudiants, j'ai mis en place un environnement qui regroupe tous les pré-requis pour utiliser Apache UIMA et développer avec sous Eclipse.

FEATURES

Scripts pour assister le téléchargement et l'installation d'un environnement pour utiliser Apache UIMA et développer avec sous Eclipse.
La configuration est centralisée pour faciliter la prise en compte les futures mise à jour des outils requis pour l'environnement
Ces outils requis sont Java JDK Sun, Eclipse, plugins eclipse (UIMA, Subversion et Maven), Apache UIMA (UIMAJ, UIMA-AS, UIMACPP, Addons), Apache tomcat, OpenNLP, maven, ant, subversion
Les scripts sont distribués sous licence GPLv3 (liberté de modifier et redistribuer le travail, redistribution des travaux dérivés sous la même licence, mise à disposition du code source)
Testés sous Ubuntu 8.10 - Hardy et 9.04 - Jaunty Jackalope

VERSION

La version datée du 7/02/2010 intègre les versions suivantes des outils

Java Sun Development Kit (jdk-6u17-linux-i586)
Eclipse Galileo (3.5)
Plugins UIMA, subversion subeclipse, maven m2eclipse
Apache UIMA 2.3.0-incubating
OpenNLP v1.3
Apache Tomcat 6.0.20

TELECHARGEMENT

Télécharger ici les scripts d'installation d'un environnement d'utilisation et développement Apache UIMA

Installer Apache Tomcat (6.0.20 Binary)

2010-01-14T15:24:00.000-08:00

QU'EST CE QUE C'EST ?
Apache Tomcat est une implémentation open source des technologies Java Servlet et JavaServer Pages (JSP), on dit aussi que c'est un conteneur de servlet.
Différentes versions d'Apache Tomcat sont disponibles pour différentes version de spécifications de Servlet et de JSP.

Servlet/JSP Spec. 2.5/2.1 works with Apache Tomcat version 6.0.X
Servlet/JSP Spec. 2.4/2.0 works with Apache Tomcat version 5.5.X

RECUPERER APACHE TOMCAT
Apache Tomcat est disponible à l'adresse http://tomcat.apache.org

export APACHETOMCATNAME=apache-tomcat
export APACHETOMCATVERSION=-6.0.20
export APACHETOMCATARCHIVEEXT=.zip
wget http://mir2.ovh.net/ftp.apache.org/dist/tomcat/tomcat-6/v6.0.20/bin/"${APACHETOMCATNAME}${APACHETOMCATVERSION}${APACHETOMCATARCHIVEEXT}"

INSTALLER ET CONFIGURER
Configurer la variable APPLIDIR qui indique votre répertoire d'installation.

# Set APPLIDIR

export APPLIDIR=.

unzip "${APACHETOMCATNAME}${APACHETOMCATVERSION}${APACHETOMCATARCHIVEEXT}" -d $APPLIDIR
ln -s "${APACHETOMCATNAME}${APACHETOMCATVERSION}" "$APPLIDIR/${APACHETOMCATNAME}"

Il s'agit maintenant de rajouter à votre .bashrc la variable d'environnement CATALINA_HOME et de la faire pointer vers la racine d'Apache Tomcat désarchivé.

export CATALINA_HOME="$APPLIDIR/${APACHETOMCATNAME}"

Le fichier RUNNING.txt à la racine de votre installation indique comment configurer plusieurs instances de Tomcat, pour cela vous aurez besoin de déclarer la variable d'environnement CATALINA_BASE. Si nécessaire lui donner la valeur de CATALINA_HOME.

DOCUMENTATION
La documentation informe sur comment installer et configurer, créer une première application web, la déployer, gérer les applications web présentes, gérer la sécurité (connexion SSL, droits d'accès...), accéder à une base de données...

EXECUTER
La documentation en ligne et le fichier RUNNING.txt à la racine de votre installation fournissent des informations complémentaires. Le 1er pour éxecuter Tomcat comme démon, le second pour éxecuter Tomcat à la main.
Démarrer Tomcat avec

$CATALINA_HOME/bin/startup.sh

Après démarrage, les applications par défaut incluses dans Tomcat seront disponibles en visitant

http://localhost:8080/

Arrêter Tomcat à l'aide de

$CATALINA_HOME/bin/shutdown.sh

DEPLOYER
http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
...

MANAGER
Le manager est une application web (installée par défaut dans le context path /manager) qui permet de gérer les autres applications : les déployer, recharger, undéployer, démarrer, arrêter...
Par défaut, l'application Manager est désactivée. Si vous n'avez pas configuré $CATALINA_BASE/conf/server.xml pour sélectionner un fichier de définition des utilisateurs, des passwords et des rôles autres que $CATALINA_BASE/conf/tomcat-users.xml, alors éditez le et associer le avec role manager avec une combinaison username/password (la créer ou utiliser une existante). Cela doit donner quelque chose comme :

role rolename="manager"user username="tomcat" password="s3cret" roles="manager"

Pour utiliser le manager se rendre sur

http://localhost:8080/manager/html/

...

Installer les UIMA Addons Annotators & tools

2010-01-12T14:16:00.000-08:00

Mise à jour 2011 04 26 : Version courante des addons est toujours la 2.3.0-incubating

INSTALLATION
Rien de plus simple pour installer les UIMA Annotator Addons and tools

1. Récupérer l'archive addons (celles ci contient tout ce qui est annoncé dans le titre) disponible sur http://uima.apache.org/downloads.cgi

export UIMAADDONSDISTANTDIR=uimaj-annotator-addons-2.3.0-incubating
export UIMAADDONSARCHIVEFILE=uimaj-annotator-addons-2.3.0-incubating-bin.zip
wget "http://mirror.mkhelif.fr/apache/incubator/uima/binaries/${UIMAADDONSDISTANTDIR}/${UIMAADDONSARCHIVEFILE}"

2. Puis l'installer en la désarchivant dans votre le répertoire parent de votre UIMA_HOME car l'archive contient le répertoire apache-uima qui contient le répertoire addons. De cette manière addons se retrouvera dans votre apache-uima.

unzip "${UIMAADDONSARCHIVEFILE}" -d "$UIMA_HOME/.."

CONFIGURATIONS

Apache UIMAJ Version 2.2.2-incubating contient

les annotators suivant DictionaryAnnotator, RegularExpressionAnnotator, Tagger, WhitespaceTokenizer dans apache-uima/addons/annotator
les outils suivant SimpleServer, PearPackagingAntTask, PearPackagingMavenPlugin dans apache-uima/addons

Apache UIMAJ Version 2.3.0-incubating contient

les annotators suivant BSFAnnotator, Lucas, Tagger, ConceptMapper, OpenCalaisAnnotator, TikaAnnotator, ConfigurableFeatureExtractor, RegularExpressionAnnotator WhitespaceTokenizer, DictionaryAnnotator, SnowballAnnotator dans apache-uima/addons/annotator
les outils suivant SimpleServer, FsVariables PearPackagingAntTask dans apache-uima/addons

Exécuter un traitement ou une chaîne de traitement sous UIMA (avec UIMAJ et en local)

2009-12-18T10:31:00.000-08:00

Update 20100326: Définition de traitement et chaînes de traitement + précision de l'utilisation d'Eclipse pour l'exécution Update 20100212: Validé pour Apache UIMAJ 2.2.*-incubating et UIMAJ 2.3.*-incubating

Apache UIMA ne distingue pas la notion de traitement de celle de chaîne de traitement. Il ne manipule que des chaînes de traitement qui a minima ne compte qu'un seul traitement/composant à exécuter. La description de la chaîne est réalisée à partir d'un fichier descripteur qui est

soit configuré comme primitif si il désigne un traitement élémentaire. La classe implémentant le traitement sera alors désignée.
soit configuré comme aggregate si il désigne une chaîne de traitement. Dans ce cas il référencera d'autres descripteurs de fichiers primitif ou Aggregate.

C'est de cette manière que l'on peut réaliser de l'encapsulation de traitement.

Les différentes manières d'exécuter un traitement sont illustrés avec des descripteurs présents dans les exemples de code fourni avec UIMAJ.

$UIMA_HOME/examples/descriptors/analysis_engine/

EN LIGNE DE COMMANDE
Le UIMA_HOME/README indique comment réaliser un test d'installation. Il s'agit d'exécuter un AnnotatorEngine et d'observer si le résultat correspond au traitement attendu à l'aide de l'outil $UIMA_HOME/bin/runAE.sh

Argument 1, on indique un descripteur d'AnnotatorEngine, par exemple : PersonTitleAnnotator.xml, SimpleTokenAndSentenceAnnotator.xml, SimpleNameRecognizer_RegEx_TAE.xml
Argument 2, un répertoire source où se trouve des fichiers .txt à traiter
Argument 2, un répertoire de destination des résultats produits

$UIMA_HOME/bin/runAE.sh $UIMA_HOME/examples/descriptors/analysis_engine/SimpleTokenAndSentenceAnnotator.xml $UIMA_HOME/examples/data/ $UIMA_HOME/examples/data/processed

A TRAVERS UN GUI HORS ECLIPSE
Par exemple à l'aide de la commande $UIMA_HOME/bin/documentAnalyzer.sh

InputDirectory doit diriger vers : applications/apache-uimaj/examples/data
OutputDirectory doit diriger vers : applications/apache-uimaj/examples/data/processed
Location of Analysis Engine XML Descriptor : applications/apache-uimaj/examples/descriptors/analysis_engine/SimpleTokenAndSentenceAnnotator.xml

Puis Run et double cliquer sur un fichier pour lancer le Java Viewer (en ligne de commande il s'agit du programme annotationViewer.sh)

L'exécution GUI hors eclipse peut aussi se faire avec le cpeGui.sh qui requiert de spécifier des descripteurs de composant d'import et d'export des données à traiter (à savoir un collection reader et des cas consummer). Des exemples sont disponibles dans le répertoire exemples de UIMA. Si vous exporter en XMI, il vous faudra aussi lancer à la main l'annotation viewer pour visualiser les résultats.

AU SEIN D'ECLIPSE

Cela requiert de créer un projet Eclipse pour le développement d'un composant UIMA
Pour exécuter les outils veiller à ajouter dans les libraries du projet en plus de uima-core et uima-tools, uima-cpe ! Tous ces packages se trouvent dans UIMA_HOME/lib
Cliquer sur le projet avec le bouton droit dans la vue Package Explorer > Run as > Run Configurations > Java Application
Puis

Dans Name: donnez le nom que vous souhaitez à la place New_configuration, par exemple DocumentAnalyser
Dans Project: vérifiez que vous êtes dans le bon projet Eclipse
Dans Main Class: cherchez la classe DocumentAnalyzer, vous devez trouver (si vous avez bien ajouter le package uima-tools) org.apache.uima.tools.docanalyzer.DocumentAnalyzer

Apply > Run ; le DocumentAnalyser exportera les résultats en XMI et exécutera l'Annotation Viewer

Pour visualiser les fichiers XMI préalablement générés

réalisez la même démarche avec la classe Annotation Viewer

Installer et utiliser OpenNLP au sein de UIMA (Version 1.3. sous linux)

2009-12-18T09:58:00.000-08:00

OpenNLP est à la fois

un regroupement de projets libres liés au traitement automatique des langues (TAL)
et un ensemble d'outils de TAL développés en Java, qui utilisent la bibliothèque d'apprentissage automatique OpenNLP Maxent et qui permettent les traitements suivant : le découpage en phrases, la détection d'entités nommées, la résolution de la coréférence...

Nous parlons ici de l'ensemble d'outils de TAL qui utilisent la bibliothèque Maxent.

En dec 2009, avec la version apache uima java 2.2.2 en incubation, seuls des wrappers pour la version opennlp-1.3.0 sont disponibles malgré le fait que opennlp en soit à la version 1.4.3.

Pour cette version seuls deux modèles de langue sont disponibles : anglais et espagnol. La version 1.4.3 possède en plus des modèles pour l'allemand et le thai. Les sources s'accompagnent de scripts qui montrent comment entrainer le POS tagger.

1. Récupération et installation de OpenNLP

Une documentation expliquant comment compiler, configurer, exécuter, entrainer... est disponible en version HTML dans l'archive docs/README.html ou en ligne).

Il faut d'une part récupérer les outils (opennlp-tools) et les modèles (opennlp-models). Les modèles doivent restés compressés, ils seront utilisés en l'état.

wget http://prdownloads.sourceforge.net/opennlp/opennlp-tools-1.3.0.tgz?download
wget -rc http://opennlp.sourceforge.net/models-1.3/
find opennlp.sourceforge.net/models-1.3/ -name "index*" -exec rm {} + ;
mv opennlp.sourceforge.net/models-1.3 opennlp-models-1.3.0
zip -r opennlp-models-1.3.0.zip opennlp-models-1.3.0
rm -r opennlp.sourceforge.net

Ensuite il faut compiler les outils (requiert JAVA_HOME, ant est dispo dans lib/). Après avoir migrer les deux archives dans votre répertoire d'applications (ici $APPLI).

tar -xvzf opennlp-tools-1.3.0.tgz
ln -s opennlp-tools-1.3.0 opennlp
cd opennlp
./build.sh

Une bibliothèque java d'outils a été générée dans le répertoire output.

Par la même occasion on désarchive les modèles dans le répertoire de opennlp

export OPENNLP_HOME=$APPLI/opennlp
unzip opennlp-models-1.3.0.zip -d $OPENNLP_HOME
ln -s opennlp-models-1.3.0 $OPENNLP_HOME/models

2. Utilisation en ligne de commande

Il est nécessaire de rajouter cette nouvelle bibliothèque ainsi que d'autres utiles pour faire tourner les outils.

Si ce n'est pas déjà fait rajouter à la fin de votre ~/.bashrc les lignes suivantes (n'oubliez pas ensuite de faire un "source ~/.bashrc" afin de rendre effectif ces changements pour votre terminal courant) .

export OPENNLP_HOME=$APPLI/opennlp
export CLASSPATH=${OPENNLP_HOME}/lib/ant.jar:${OPENNLP_HOME}/lib/jakarta-ant-optional.jar:${OPENNLP_HOME}/lib/jwnl-1.3.3.jar:${OPENNLP_HOME}/lib/maxent-2.4.0.jar:${OPENNLP_HOME}/lib/trove.jar:${OPENNLP_HOME}/output/opennlp-tools-1.3.0.jar:${CLASSPATH}

Chaque outil de la bibliothèque opennlp-tools est décrit par une classe qui contient un "main" qui réalise le traitement correspondant. Certains de ces outils supposent le traitement d'autres pour pouvoir fonctionner. La plupart prennent un argument, le chemin vers le modèle qu'ils exploitent. Le parser requiert un répertoire de modèles et le namefinder une liste de modèles.

Des exemples sont disponibles dans le fichier docs/README.html ou en ligne.

echo "Jules Verne was a French author who helped pioneer the science-fiction genre. He was born in the bustling harbor city of Nantes in Western France in 1828." > /tmp/text ;
java opennlp.tools.lang.english.SentenceDetector \
${OPENNLP_HOME}/models/english/sentdetect/EnglishSD.bin.gz < /tmp/text |
java -Xmx400m opennlp.tools.lang.english.NameFinder \
${OPENNLP_HOME}/models/english/namefind/*.bin.gz

3. Utilisation au sein d'Apache UIMA

(dernière section en cours d'écriture)

Les wrappers sont disponibles dans le répertoire UIMA_HOME/examples/oppennlp_wrappers/

Dans Eclipse, il s'agit de donner accès aux descripteurs de ces wrappers et de déclarer les bibliothèques requises pour les exécuter

Déclarer en répertoire source le répertoire oppennlp_wrappers/src en cliquant bouton droit et Build Path > Use As Source Folder
Cliquer sur le projet examples avec le bouton droit puis Properties > Java Build Path > Add Variables > OPENNLP_HOME > Extend > et ajouter les bibliothèques

Installer l'implémentation Java d'Apache UIMA (uimaj)

2009-12-16T15:07:00.000-08:00

AVERTISSEMENT

Cette page avait été écrit pour décrire l'installation de l'implémentation Java d'Apache UIMA (uimaj) Version Binary 2.2.2-incubating sous Linux.

Depuis j'ai produit un ensemble de scripts pour gérer automatiquement le téléchargement et l'installation d'un environnement pour utiliser Apache UIMA (>2.3) et développer avec sous Eclipse.

INTRODUCTION
La documentation officielle référence deux guides

l'UIMA overview and SDK Setup
le Getting started (une page ciblée sur l'installation de Java UIMA )

Jérôme Rocheteau décrit comment installer Apache UIMA Java en récupérant les sources sur le dépôts subversion et en les installant avec Maven.

Ci-dessous nous rapportons une synthèse en français des grandes étapes pour la version d'Apache UIMA 2.2.2-incubating et d'Eclipse Galileo 3.5.1; cela comprend l'application du correctif hf1.

1. Installation d'Eclipse et de ses plugins
Eclipse n'est pas nécessaire pour l'installation et l'utilisation du framework Apache UIMA ou du SDK. Les outils Apache sont utilisables hors IDE même si la tendance serait à privilégier leur intégration seulement au sein de celui-ci (voir le CAS Editor).
Eclipse est néanmoins recommandé pour le développement de composants UIMA.
Nous renvoyons au billet http://enicolashernandez.blogspot.com/2009/12/comment-installer-eclipse-galileo-351.html pour l'installation d'Eclipse et de ses plugins. Nous supposons l'installation de Eclipse Galileo 3.5.1

2. Installation du framework Apache UIMA, de son SDK et des codes exemples

1. Sur http://incubator.apache.org/uima/downloads.cgi récupérer les archives des versions binaires pour Linux des latest official releases de

UIMA Java framework and SDK à savoir uimaj-2.2.2-incubating-bin.zip
UIMA core hotfix 1
UIMA Annotator Addons & Simple Server & Pear packaging tools

2. Désarchiver l'archive "UIMA Java framework and SDK" dans le répertoire de votre choix. Pour ce qui suit nous supposons l'existance d'un répertoire d'applications désigné par la variable d'environnement $APPLI

Au passage, je crée un lien symbolique pour me permettre de changer aisément de version à l'avenir.

cd $APPLI
unzip uimaj-2.2.2-incubating-bin.zip

mv apache-uima apache-uimaj-2.2.2-incubating-bin
ln -s apache-uimaj-2.2.2-incubating-bin apache-uimaj

3. Fixer les variables d'environnement. Pour cela je suis les consignes du fichier README présent dans l'archive.

Set JAVA_HOME to the directory of your JRE installation you would like to use for UIMA.
Set UIMA_HOME to the apache-uima directory of your unpacked Apache UIMA distribution
Append UIMA_HOME/bin to your PATH
Please run the script UIMA_HOME/bin/adjustExamplePaths.sh (or .sh), to update emacs .bashrc

#-- UIMA
export UIMA_HOME=${APPLI}/apache-uimaj
export PATH=${UIMA_HOME}/bin:$PATH
#export UIMA_CLASSPATH=/dir/to/my/component.jar
#export UIMA_LOGGER_CONFIG_FILE=$UIMA_HOME/config/myLoggerConfig.properties

4. Un test d'installation

Afin de réaliser ce test consulter la page "Comment exécuter des chaînes de traitement avec UIMA " notamment la section "Exécution d'une chaîne de traitement en ligne de commande".

5. Désarchiver le UIMA core hotfix 1 (correctif sur la gestion mémoire) et placer la bibliothèque uima-core.jar fournie dans $UIMA_HOME/lib à la place de celle existante.

6. Importer le répertoire de codes exemples UIMA_HOME/examples au sein d'Eclipse

Cliquer onglet File > Import ; Sélectionner "General/Existing Project into Workspace" ; Cliquer "Next" ; Cliquer "Browse" et naviguer jusqu'au répertoire UIMA_HOME

7. Définir la variable UIMA_HOME au sein d'Eclipse

Cliquer onglet Window > Preferences > Java > Build Path > Classpath Variables > Faire New (Name: UIMA_HOME et Path: Folder... > vers "applications/apache-uima") > Ok > Ok > Yes (rebuild)

8. Un test d'installation au sein d'Eclipse

Afin de réaliser ce test consulter la page "Comment exécuter des chaînes de traitement avec UIMA " notamment la section "Exécuter une chaîne de traitement au sein d'Eclipse".

9. L'ajout des addons...
est décrit dans ce post.

Créer un projet sous GoogleCode

2009-12-16T14:55:00.000-08:00

Dernière mise à jour : 1 mars 2011

La page "A quick guide to getting started with project hosting on Google Code" explique comment contribuer à ou créer un projet sous GoogleCode (par exemple comment choisir la licence d'un nouveau projet).

En quelques cliques...

Créer un projet en cliquant sur Create Project et remplir le formulaire

nom, résumé et description du projet, mais aussi des choix comme (ici avec des valeurs exemples que j'utilise en général)

Project name: si votre nom est composé alors séparer chaque mot par un tiret (e.g. votre-nom-de-projet)
Version control system: Subversion
Source code license: Apache License v2.0

Configurer le projet (à l'aide de l'onglet Administer de la barre de menu horizontale. Le fait de cliquer dessus fait apparaître un sous menu.)

Définir les membres en cliquant sur Project Members (les owners ont tous les droits, les committers peuvent travailler sur le projet mais ne peuvent pas le configurer.)
(Optionnel) Sous l'onglet Project Summary, spécifier la notification des modifications de la forge en déclarant le nom de votre liste de discussion ou google groupe (qui servira aussi d'alias dans nos échanges mails) dans la section Activity notifications de Administer puis Issue Tracking. (Pour créer un google groupe se rendre sur http://groups.google.fr/groups/create)
(Optionnel) Sous l'onglet Project Summary, spécifier le Web Property ID de Google Analytics afin de pouvoir obtenir des statistiques de visistes via Google Analytics (la note Learn more, rappelé plus bas, vous indique la démarche).

Services à disposition et menu de gestion du projet

La barre d'onglets horizontale offre différents services : Project Home, Downloads, Wiki, Issues, Source, Administer

Downloads permet de uploader des fichiers avec le lien New download
Wiki permet de rédiger des pages avec le lien New page
Issues permet de signaler des observations sur le projet pour aider à son bon développement. Elles émanent des utilisateurs comme des développeurs.

Cela se fait avec New issue et en spécifiant entre autres le Type de l'issue -Defect (défaut du logiciel), -Enhancement (amélioration demandée sur quelque chose qui existe), -Task (quelque chose de nouveau à développer)... et sa priorité
Par la suite, les développeurs consultent les issues et agissent en conséquence. Une issue peut recevoir plusieurs commentaires de différentes personnes. Suivant leurs traitements, les développeurs changeront leur Status (Accepté (le problème est confirmé), Fixed (defect réparée), Invalid (issue invalide), Done (task effectuée)...

Source indique les commandes à taper pour récupérer avec un client subversion (svn) depuis un poste linux les sources du projets afin de contribuer ou seulement de les consulter.

si vous vous trouvez derrière un proxy, alors éditer le fichier ~/.subversion/servers et à la fin, décommenter les lignes suivantes en indiquant les bonnes valeurs

# http-proxy-host = defaultproxy.whatever.com
# http-proxy-port = 7000

Utiliser le dépot svn

Votre dépot svn est accessible à une adresse similaire à celle-ci https://votre-nom-de-projet.googlecode.com/svn ; où par défaut 3 sous répertoires sont disponibles : trunk (version principale en cours de développement), tags (précédentes versions stables), branches (évolutions différentes du tronc ou corrections de bugs).
L'onglet source vous indique comment récupérer le trunk...
Pour commencer à travailler, faites un checkout pour commencer à travailler sur votre projet. Bien entendu la première version récupérée sera vide mais s'accompagne de fichiers qui permettront de synchroniser votre copie locale avec le référentiel subversion.

Publier une Javadoc sous forge Google Code

Mesurer le nombre de visites sur votre projet hébergé sous Google Code grâce à Google Analytics

Ajouter un dépot (repository) Maven à votre forge Google Code grâce à Subversion

TODO Liens vers mon cours de svn, notamment pour faire des tags... Choisir sa licence...

Installer Eclipse et ses plugins pour UIMA

2009-12-16T08:54:00.000-08:00

Mise à jour le 111130 : (lien update eclipse uima)

INSTALLER ECLIPSE

http://www.eclipse.org/downloads/

Récupération de la version suivante d'eclipse

Eclipse IDE for Java EE Developers (188 MB) Tools for Java developers creating Java EE and Web applications, including a Java IDE, tools for Java EE, JPA, JSF, Mylyn and others. More...
Eclipse 3.5.1. / Galileo / eclipse-jee-galileo-SR1-linux-gtk
http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/galileosr1

INSTALLER LES PLUGINS ECLIPSE PAR L'IDE
Installation des plugins de Maven, Subversion, et UIMA

Le post suivant explique la manipulation générale :
http://jerome.rocheteau.free.fr/index/post/2009/10/29/Comment-configurer-Eclipse-pour-UIMA
Le présent post détaille la manipulation.

1. Sites de téléchargement respectifs

subversion http://subclipse.tigris.org/update_1.6.x

maven http://m2eclipse.sonatype.org/update

UIMA http://www.apache.org/dist/uima/eclipse-update-site

2. Démarche d'installation pour chaque plugin

Help > Software updates | Install New software > onglet "Software Available" > Add site location
Cocher le nouveau site ajouté et ceux qui sont apparus en même temps, éventuellement les autres aussi pour les mettre à jour.
Puis cliquer sur installer
Commence une étape de résolution de dépendances, il est possible qu'il faille cocher plus de sites afin de permettre cette résolution, il est possible qu'il faille faire des install un à un des sites, et il est possible qu'il faille commencer par ceux natifs d'eclipse. Quelques refresh.

3. Vérifier l'installation en observant la présence de ...**

SVN : cliquer sur package (fenêtre de gauche) avec bouton droit > New > Other > SVN
MVN : cliquer sur package (fenêtre de gauche) avec bouton droit > Maven m2
UIMA : cliquer sur un projet présent dans package (fenêtre de gauche) avec bouton droit > Add UIMA Nature

INSTALLER LES PLUGINS ECLIPSE EN LIGNE DE COMMANDE
Il est possible d'installer les plugins à la main, vous trouverez dans l'archive suivante un script qui se charge de l'installation des plugins Eclipse (attention il requiert le lancement d'eclipse -clean) entre chaque installation.

CONFIGURATIONS D'INSTALLATION
1. Eclipse Galileo 3.5.1 et Apache UIMA 2.2.2-incubating

Plugin Eclipse Maven

Maven requiert d'abord d'installer le site http://download.eclipse.org/tools/ajdt/35/update/

(vu sur http://docs.codehaus.org/display/M2ECLIPSE/Installation+Requirements#InstallationRequirements-AJDT)

Plugin UIMA
Le site propose deux ressources

Apache UIMA Eclipse tooling and runtime support
Apache UIMA-AS Eclipse tooling

Installer d'abord le 1er

Puis pour permettre l'install du second : http://www.mail-archive.com/uima-user@incubator.apache.org/msg02554.html

Problem by using a new installation of Eclipse 3.5.1.
I think the problem is that the Eclipse Update Manager cannot find the jar
for the Deployment Descriptor Editor in the update site(s).

To avoid this problem, Apache UIMA should provide an "archived" update site
file so that the user can download and "locally" install the plug-ins
instead of completely depend on the mirror/download sites.

Here is an alternative way to install the Deployment Descriptor Editor:
1. Download the UIMA-AS
http://www.bizdirusa.com/mirrors/apache/incubator/uima/binaries/uima-as-2.2.2-incubating/uima-as-2.2.2-incubating-bin.zip

2. Unzip and copy the following 2 jars to your Eclipse's "dropins" directory
(like for example eclipse\dropins):
- eclipsePlugins/org.apache.uima.deployeditor_2.2.2.incubating.jar
- eclipsePlugins/org.apache.uima.runtime-deployeditor_2.2.2.incubating.jar

3. Restart your Eclipse with -clean option.

2. Eclipse Galileo 3.5.1 et Apache UIMA 2.3.0-incubating

Même démarche sauf que cette fois-ci Maven ne requiert pas d'installer au préalable d'autres plugins

A SUIVRE...

Déclarer la variable UIMA_HOME au sein d'Eclipse
Importer le projet UIMA_HOME/examples
Créer un projet d'Annotator Engine au sein d'Eclipse

Démarrer avec UIMA

2009-12-12T10:15:00.000-08:00

Désormais une page statique dédiée a été créée http://enicolashernandez.blogspot.com/p/uima.html

Lancer U-compare

2009-11-03T14:05:00.000-08:00

Après une ou deux tentatives infructueuses ces dernières semaines pour lancer U-Compare, j'ai finalement réussi à le lancer.
Ce qui a fait la différence : un java sun jdk mis à jour.

Mon système

$ cat /proc/version
Linux version 2.6.27-15-generic (buildd@vernadsky) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Tue Oct 20 06:52:09 UTC 2009
$ cat /etc/issue
Ubuntu 8.10 \n \l

Un java sdk 1.6.0 ne suffisait pas mais avec un java sdk 1.6.0_17 s'est passé (avec un 1.6.0_16 s'est passé aussi)

$ java -version
java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

Pour installer ou changer de Java sous Ubuntu.

Finalement pour lancer, j'ai suivi l'option avec téléchargement de la classe UCLoader.class, puis exécution en ligne de commande de

$ java -Xms700m -Xmx1000m UCLoader

Au premier lancement, un répertoire d'installation est créé (avec entre autres la récupération d'un certain nombre de bibliothèques)

$ ls ${HOME}/.U-Compare/

Le Type System de U-Compare est disponible dans jars/u-compare.jar au chemin suivant org/u_compare/U_compareTypeSystem.xml

Installer Java sous Ubuntu

2009-11-02T15:13:00.000-08:00

Pour mettre à jour son java (l'installer et changer celui par défaut) :

sudo aptitude install sun-java6-jdk
sudo update-alternatives --config java

On peut aussi l'installer à la mano en le récupérant sur le site de sun

chmod a+x jdk-6u17-linux-i586.bin
./jdk-6u17-linux-i586.bin