lundi 28 mars 2011

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


mercredi 16 mars 2011

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

lundi 14 mars 2011

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
  • 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/  

mercredi 23 février 2011

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 ?
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.
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}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 :

jeudi 10 février 2011

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

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
Outre la page officielle et mon expérience personnelle, cette page s'appuie aussi sur le site suivant
Les pages précédentes contiennent des éléments pour l'installation du plugin Eclipse. Voir aussi les liens suivant

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 
Installation de Lejos
(ce qui suit peut se réaliser dans un simple compte utilisateur)

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