La recherche de mots ou la prise en charge éventuelle de mots pré-encodés dans les sources est un composant essentiel de TXM.

Sa stratégie est décrite dans cette page.

Elle peut déléguer certains calculs de mots, décrits dans la page Spécification de l'annotation lexicale automatique.

Elle doit tenir compte du contexte linguistique, décrit dans la page Spécification de la prise en charge linguistique.

Il y a différentes façons de déterminer les mots dans les textes dans TXM. Pour les sources XML, cela tient compte notamment des plans textuels définis par certains modules d'import.

Une fois déterminés, les mots servent par exemple aux index du moteur CQP mais également à la relation entre ces index et les éditions de textes (pour le retour au texte). Cette relation est gérée par un identifiant de mot unique obéissant à une politique de gestion d'identifiants propre à TXM. Si des sources XML respectent cette politique, TXM peut tenir compte d'identifiants pré-encodés dans les sources.

Pour les sources en texte brut (TXT) TXM a un contrôle total sur la détection des mots et sur leur équipement, notamment en identifiants xml:id pour la gestion (interne) du retour au texte.

Pour les sources XML, il y a quatre cas de figure de gestion des mots :

• la tokenisation est activée :
  • A) TXM trouve et crée des mots dont il a le contrôle total, notamment en identifiants xml:id pour la gestion du retour au texte
  • B) TXM trouve des mots pré-encodés : dans ce cas TXM doit forcer l'équipement en identifiants xml:id pour la gestion du retour au texte, et éventuellement déplacer des xml:id pré-encodés dans un attribut de sauvegarde 'fn-id' (l'association du forçage des identifiants avec la segmentation lexicale est importante parce qu'elle permet de gérer le cas où tous les mots sont pré-encodés mais l'utilisateur n'a pas explicitement demandé à en tenir compte de façon exclusive et les identifiants de mots peuvent ne pas respecter la politique de gestion des identifiants de TXM).
• la tokenisation n'est pas activée : TXM délègue la détection des mots à l'encodage XML, deux cas de figure :
  • C) la génération d'identifiants est activée : TXM force l'équipement en identifiants xml:id pour la gestion du retour au texte, et éventuellement déplace des xml:id pré-encodés dans un attribut de sauvegarde 'fn-id'
  • D) la génération d'identifiants n'est pas activée : TXM prend les attributs xml:id présents et affiche un message d'erreur s'il n'y a pas d'attribut xml:id dans un mot
    • dans ce cas de figure, la responsabilité du respect de la politique de gestion des identifiants de mots est déléguée aux sources XML. Si la politique n'est pas respectée, le comportement de TXM à l'exploitation du corpus n'est pas défini.

Pour les modules d'import de sources XML, la stratégie ci-dessus est appliquée à l'aide de deux options (deux paramètres d'import) :

• “Ne pas segmenter en unités lexicales”/“Do not tokenize in lexical units”
• “Ne pas générer d'identifiants de mots”/“Do not generate word identifiers”
  (cette option n'est active que si la précédente est active)

Il faut gérer les clitiques :

• avez-vous : OK
• est t-il : ???

Il faut gérer des caractères avec espaces avant et après dans l'édition :

• 'GP de visages de prisonniers- Pano sur un libéré marchant sur une route de campagne' → 'GP de visages de prisonniers - Pano sur un libéré marchant sur une route de campagne'

Il faudrait gérer des caractères dont la gestion typographique dans la source est différente de cette réalisée dans l'édition par défaut :

• 'GP de visages de prisonniers- Pano sur un libéré marchant sur une route de campagne' → 'GP de visages de prisonniers- Pano sur un libéré marchant sur une route de campagne'

Il existe plusieurs Tokenizers :

• SimpleTokenizerXml* : utilisé par tous les modules sauf XML-TEI-BFM
• TeiTokenizer : réécriture plus générique du tokenizer (filtre) de la BFM pour la TEI.
• TokenizerXML : règles de Tokenisation (avant,après, …)
• TTTokenizer : réécriture non-terminée du tokenizer TreeTagger (tokenize.pl)
• TranscriberTokenizer* : Tokenize les entités nommées (Event=XXX) et les marques spéciale d'oralité (ex : !)
• Tokeniser* (et OneTagPerLine) : filtre de tokenisation utilisé par l'import BFM

* : tokenizer couramment utilisé par les modules d'import

• Lucene
• OpenNLP
• Flex ou JavaCC
• Unitex
• … à compléter

• fichier XML
• pas de w ou w pré-encode certains ou tous les mots;
  • quand w :
    • les attributs w@PP deviennent des propriétés de mots
    • attention, si existant, l’attribut @id doit être conforme au format XML-TXM

• fichier XML
• w encode tous les mots (pour indexation)
  • les attributs encodent les propriétés de mots
  • l’attribut @id des w créés est forgé (cf format XML-TXM).

Pour améliorer la lemmatisation TreeTagger pour les langues (en, fr, ga et it).

Faire évoluer le tokenizer XML de TXM en intégrant les règles de tokenization des clitiques des langues (en, fr, ga et it) du script Perl de tokenisation TreeTagger.

La langue de tokenisation est réglée dans le formulaire d'import (fichier import.xml).

La langue “fro” est ajoutée pour gérer les différences entre les clitics “fro” et les clitics “fr”.

Dans le cas, où le tokenizer ne trouve pas de règles pour la langue, il utilise les 2 premières lettres de la langue indiquée (ex : frp → fr) pour pouvoir déclencher la tokenisation propre à une langue tout en ayant des variantes de fichiers paramètres TreeTagger pour une même langue (eg tous les fichiers paramètres du français - partageant les mêmes règles de segmentation du français - doivent avoir un nom commençant par 'fr').

On découpe le flux de caractères par les classes suivantes pour obtenir les mots :

• Caractères séparateurs
  • Espaces
  • Ponctuations
• Caractères d'élision
• Caractères de fin de phrase

Il faut au moins qu'une classe de séparateur soit définie.

Si une classe n'est pas défini, on ne l'utilise pas pour découper le flux (ticket #1878).

Établir un corpus de test stable qui contient tous les cas que l'on souhaite :

• plans textuels : hors texte
• ponctuations
• nombres
• mot pré-balisés
• blancs séparateurs de mots
• clitiques : it, fr et en

le résultat de la tokenisation du corpus stable doivent être sauvegardés pour pouvoir être comparés quand le code du tokenizer changera.

• Vérifier que les enclitiques fr et en de TreeTagger sont bien tokenisés :
  • EN (en priorité) avec le corpus NYSAMPLE (import XML/w+CSV, sources et binaire déposés dans SpUV/NY) :
    • FClitic = '(s|re|ve|d|m|em|ll)|n\'t

Plus tard :

• FR (ensuite) avec le corpus GRAAL (import XML/w) :
  • FClitic = '-t-elles?|-t-ils?|-t-on|-ce|-elles?|-ils?|-je|-la|-les?|-leur|-lui|-mmes?|-m\'|-moi|-nous|-on|-toi|-tu|-t\'|-vous|-en|-y|-ci|-l'