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 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
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 :
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).
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>
<!--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. |
<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
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.
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
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
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.
6. Quelles limites présentent le composant ?
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 :
<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 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.
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 :
