Mise en place d’un système de normalisation

La chaîne de traitement SxPipe

Ensuite, nous voulons être capable d’analyser de nombreuses altérations différentes les unes des autres. Nous avons donc mis en place des systèmes de normalisation (décrits dans les chapitres 5 et 6) relativement génériques mais qui sont conçus uniquement pour traiter des altérations plus classiques, accessibles à une normalisation reposant sur un système d’apprentissage de règles par analogie. Par conséquent, si une altération est créée volontairement à l’aide d’un procédé spécifique, sa normalisation pourra être moins évidente à réaliser pour ces systèmes.

Toutefois, ces altérations peuvent résulter de procédés aisés à détecter et à normaliser par d’autres moyens. Par exemple, les tokens noooooooooooon ou dégon-flé, qui correspondent respectivement à non et dégonflé, sont détectables par la régularité et la singularité des procédés qui ont permis leur création. Ajouter un ou plusieurs systèmes prenant en compte ces différents types de mécanismes est une stratégie plus fiable que tenter de les analyser à l’aide de systèmes de normalisation génériques.

Le système présenté ici s’intègre dans une chaîne de traitement modulaire : SxPipe (Sagot et Boullier, 2008). Comme nous l’expliquerons ci-dessous, cette chaîne de traitement est générique. Nous l’avons par conséquent reprise et adaptée à nos besoins afin de la rendre apte à réaliser des tâches de normalisation, notamment sur nos corpus.

Nous commencerons ainsi ce chapitre en expliquant ce choix et le fonctionnement global de cet outil (section 4.1), puis nous détaillerons à la section 4.2 les différents systèmes de normalisation mis en place pour les altérations spécifiques, stables et régulières qui sont fréquemment attestées, enfin nous décrirons dans les sections 4.3, 4.4 et 4.5 les diverses stratégies que nous avons mises en place afin d’écarter les inconnus ne correspondant pas à des altérations. 

La chaîne de traitement SxPipe

Avant de présenter la chaîne de traitement SxPipe (Sagot et Boullier, 2008), il nous semble important d’expliquer les raisons qui nous ont poussée à la choisir. Tout d’abord, SxPipe est un outil sous licence Cecill-C 2 (compatible LGPL). Il est donc librement accessible, utilisable, modifiable et redistribuable y compris au sein d’une entreprise comme viavoo. Bien que cette chaîne de traitement soit générique, nous pouvons l’adapter à nos besoins.

Cela est d’autant plus réalisable que SxPipe est modulaire. Il nous est ainsi possible de choisir les modules que nous voulons appliquer et leur paramétrage. Par ailleurs, si nous voulons personnaliser certains des modules appartenant à SxPipe, nous pouvons le faire, son code étant accessible et modifiable. Enfin, nous voulons mettre en place un système capable de traiter des textes en français, en anglais, en allemand et en espagnol, il est donc important de souligner le caractère multilingue de SxPipe, lequel est ainsi

en mesure de traiter toutes ces langues

Pour ce faire, SxPipe s’appuie sur des lexiques Alexina (Sagot, 2010) tel que le Lefff présenté section 1.2.2. 

Format utilisé par SxPipe

Pour réaliser leur analyse, Sagot et Boullier (2008) s’appuient sur plusieurs notions telles que celles de forme simple et composée, de token ou encore d’amalgame, que nous avons déjà évoqué en section 1.1 (page 12). Ainsi, lors du découpage d’une phrase, tous les tokens qui y sont contenus obtiennent un identifiant unique indiquant leur position dans la chaîne de caractères initiale.

Ils peuvent être ensuite rattachés à une forme simple ou composée ou à plusieurs formes amalgamées. Les auteurs ont par ailleurs introduit la notion de forme spéciale afin d’abstraire un motif donné (composé d’une ou plusieurs formes) que l’on ne souhaite pas analyser, syntaxiquement parlant, autrement qu’en bloc. Nous illustrons ces différents cas dans la suite de cette section et dans la table 4.1 

Lorsqu’une phrase est donnée à SxPipe, les tokens la composant sont alors stockés en commentaire, entre accolades, avec leur identifiant. Cet identifiant, représenté par un élément XML, se présente de la sorte : {token}. Les indices i et j correspondent ici respectivement au numéro de la phrase et au numéro du token dans cette dernière. Pour des questions de lisibilité, un tel token pourra être représenté comme ceci {tokenj}. Le token en commentaire est ensuite suivi de la forme qui lui est rattachée.