UIMA sur HADOOP

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

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

1. 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.
2. 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.

1. 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.
2. 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, ...)
3. Spécifier le nom du fichier de modélisation à produire dans le paramètre du descripteur 
4. 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

1. Les données traitées doivent être des fichiers textes
2. Spécifier le fichier de modélisation dans le paramètre du descripteur
3. Spécifier le featurePath de l'annotation à créer avec la valeur prédite par la modélisation
4. 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

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)

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

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)

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"?> 

<conceptSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://incubator.apache.org/uima/regex" xsi:schemaLocation="concept.xsd">
  <!--ici la définition des concepts... -->
</conceptSet>

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 :

• http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html
• http://download.oracle.com/javase/6/docs/api/java/lang/Character.html
• http://www.regular-expressions.info/unicode.html