Agnes Souque

The end of my work on French grammar checking

I have finished my first work on LanguageTool. I have adapted the tool to French grammar checking. The following resume presents the end of this work.
You can download the report ( M�moire) and the slides ( Soutenance). They are written in French.

Work on rules

As I explained previously, at the beginning of the French grammar checker project, Myriam Lechelt has worked on An Gramad�ir. She has written many disambiguation and correction rules. Since An Gramad�ir was limited and did not really suit to French, it was abandoned.

During my work, I have converted An Gramad�ir's rules to LanguageTool. Thanks to Marcin Miłkowski who implemented a disambiguator, according to my instructions, I could import disambiguation rules as well as correction rules. Moreover, I simplified them a lot and I considerably reduced their number thanks to the XML language.

Then, I have analysed a corpus of mistakes (V. Lucci et A. Millet, 1994, L'orthographe de tous les jours, enqu�te sur les pratiques orthographiques des fran�ais, Editions Champion) and I have extracted new grammar rules from it.

LanguageTool can detect the following kind of mistakes :

phonetic proximity (confusion of homophones like ont and on, �a and sa, etc.)

mistakes in verb phrases (confusion between infinitive and past participle, conjugated form and past participle, etc.)

subject-verb agreement (personal pronoun or noun phrase with only a determiner and a noun)

Limits of the formalism

While working on the rules, I made tests that showed me the limits of the formalism of LanguageTool. Because of the rigid pattern matching on which it is based, if the patterns described in the rules do not exactly match the text, the rules become inefficient and prevent some mistakes from being detected. Moreover, it is necessary to foresee every wrong combination of words to describe them in the rules. It leads to a combinatory explosion of the number of rules, especially in noun phrases.

The formalism also generates lots of wrong alarms, because of ambiguities or wrong tags. Some mistakes can be detected simultaneously several times by different rules. And when a word is wrong, it can cause wrong alarms on nearby words, since the rules are based on the context.

New formalism

I have developed a new formalism to improve French grammar checking in LanguageTool. It is based on chunks and unification of features structures (see An alternative with chunks and unification). I mix a contextual syntactic theory (chunks, Abney) and a generative syntactic theory (unification, Chomsky). This is not a typical combination, but it makes possible to go further in grammar checking by delimiting an area in the sentence where all words must agree. It is then no longer necessary to describe all wrong combinations of words. Instead of listing agreement mistakes, inconsistencies are detected in phrases.

Conclusion

Thanks to my work for my MPhil, French grammar checking is available for OpenOffice.org. But there is still a lot of work left. It is necessary to create a tool compatible with the new formalism, and to build and analyse a corpus of mistakes to write new grammar rules.

A new approach for grammar checking

To improve grammar checking, I am considering another method which consists in doing at the same time the morphosyntactic analysis and the grammar checking, while the sentence is read. This "left-right" method is based on the principle of latencies (Tesni�res, 1959). With the declaration of what is expected after a word or a phrase, inconsistencies can be detected, instead of listing all possible mistakes.
This approach will also solve the problem of the vicious circle in grammar checking. Indeed, for mistakes to be detected, the tagging must not be wrong. But for it to be correct, the text must not contain any mistake...

M�moire et slides (Correction grammaticale du fran�ais)

Voici mon m�moire de recherche ainsi que les slides de soutenance.

Le travail que j'ai effectu� est integr� � LanguageTool et utilisable dans OpenOffice.org en tant qu'extension. Le fichier ainsi que les instructions d'installation sont disponibles sur le site de LanguageTool.

D'autres personnes ont commenc� � �crire de nouvelles r�gles pour le fran�ais, pour augmenter la couverture de correction de LanguageTool. La base de r�gles �volue donc r�guli�rement.

Il reste encore beaucoup de travail...

Bilan du travail sur le correcteur grammatical LanguageTool

J'ai termin� mon premier travail sur LanguageTool, qui consistait � adapter cet outil � la correction grammaticale du fran�ais. Voici un r�sum� qui pr�sente la fin de ce travail.

Travail sur les r�gles

Gr�ce � Marcin Miłkowski qui a d�velopp� un d�sambigu�seur selon mes indications, j'ai pu convertir au formalisme de LanguageTool toutes les r�gles de d�sambigu�sation et de correction �crites pour An Gramad�ir. Le langage XML m'a permis de beaucoup simplifier les r�gles et de r�duire leur nombre en faisant des regroupements.

J'ai par la suite analys� un corpus de fautes (V. Lucci et A. Millet, 1994, L'orthographe de tous les jours, enqu�te sur les pratiques orthographiques des fran�ais, �ditions Champion) afin d'en extraire de nouvelles r�gles de correction.

LanguageTool d�tecte actuellement des erreurs :

de proximit� phon�tique (confusion d'homophones : �a/sa, ont/on, cet/cette/c'est/ces, etc.)

d'accord dans le syntagme nominal (en genre et en nombre)

dans le groupe verbal (confusion infinitif et participe pass�, forme conjugu�e et participe pass�, etc.)

d'accord sujet-verbe (pronom personnel sujet ou syntagme nominal simple : d�terminant + nom)

Limites du formalisme

Avec des tests effectu�s lors du travail sur les r�gles, j'ai pu constater les faiblesses du formalisme de LanguageTool. Il se fonde sur le pattern-matching rigide, ce qui implique que si les mod�les d�crits dans les r�gles ne correspondent pas exactement au texte, au mot pr�s, les r�gles deviennent inefficaces et g�n�rent du silence dans la d�tection des fautes. Par ailleurs, il faut pr�voir toutes les combinaisons de mots erron�es. On obtient ainsi une explosion combinatoire des r�gles, surtout pour les syntagmes nominaux.
Le formalisme est aussi � l'origine de beaucoup de bruit (mauvaises d�tections). Les mots mal �tiquet�s ou ambigus, par exemple, provoquent des fausses alarmes. Nous avons des d�tections redondantes lorsque certaines erreurs sont d�tect�es par plusieurs r�gles diff�rentes simultan�ment. Enfin, les r�gles se fondant sur le contexte imm�diat des mots, une erreur sur un mot peut entrainer de fausses d�tections en cascade sur les autres mots du contexte.

Nouveau formalisme

Pour d�passer les limites de LanguageTool, j'ai d�velopp� un nouveau formalisme, fond� sur la segmentation en chunks et l'unification de structures de traits. Je m�le ici une th�orie syntaxique contextuelle (chunks, Abney) et une th�orie syntaxique g�n�rativiste (grammaire d'unification, Chomsky). Cette combinaison est atypique, mais elle permet d'aller plus loin dans la correction grammaticale, en d�limitant des zones de calculs � l'int�rieur desquelles tout doit s'accorder. Il n'est alors plus n�cessaire de d�crire toutes les combinaisons de mots erron�es. Au lieu d'�num�rer les fautes d'accord, nous d�tectons les incoh�rences au sein des syntagmes.

Conclusion

Mon travail de m�moire de Master Recherche permet de doter OpenOffice.org de la correction grammaticale pour le fran�ais. Il reste cependant beaucoup de travail en perspective. Il faut notamment d�velopper un outil capable de prendre en charge le nouveau formalisme, et �galement constituer et analyser un corpus de fautes pour mod�liser de nouvelles r�gles de correction.

Vers une autre approche de la correction grammaticale

Pour am�liorer encore la correction grammaticale, j'envisage une autre approche. Elle consiste � effectuer simultan�ment l'analyse morphosyntaxique et la correction grammaticale au fur et � mesure de la lecture de la phrase. C'est une approche gauche-droite qui se fonde sur le principe de latences (Tesni�res, 1959). Elle permet de d�clarer ce qui est attendu apr�s un mot ou un syntagme et de d�tecter ainsi les incoh�rences, au lieu d'�num�rer les fautes possibles.
Cette approche permet aussi de sortir du cercle vicieux en correction grammaticale. En effet, pour que les fautes soient bien d�tect�es, les mots doivent �tre bien �tiquet�s morphosyntaxiquement. Mais pour que le calcul des �tiquettes soit correct, le texte ne doit pas contenir de fautes...

Transcription des r�gles d'erreurs, de An Gramad�ir vers LanguageTool

Transcription des r�gles

Myriam a �crit un peu plus de 500 r�gles d'erreurs pour An Gramad�ir. Cette semaine, nous les avons import�es dans LanguageTool. Pour cela nous avons d� les r��crire en XML. Bien s�r, nous n'avons pas fait ce travail manuellement. Nous avons �crit un petit programme permettant de transcrire les r�gles automatiquement dans le bon formalisme.

Par exemple, la r�gle de An Gramad�ir du type :
    <DS>ANYTHING</DS> <JS>ANYTHING</JS> <NP>ANYTHING</NP>:NOMBRE

a �t� r��crite en :
    <rule>
       <pattern mark_from="2">
           <token postag="D .* s" postag_regexp="yes"/>
           <token postag="J .* s" postag_regexp="yes"/>
           <token postag="N .* p" postag_regexp="yes"/>
       </pattern>
       <message>Il y a une erreur d'accord en nombre</message>
       <example type="correct">le beau ch�teau</example>
       <example type="correct">les beaux ch�teaux</example>
       <example type="incorrect">le beau ch�teaux</example>
   </rule>

Quelques modifications

Nous avons d� par la suite retravailler un peu le fichier XML g�n�r�.
Pour la plupart des r�gles, nous avons personnalis� le message d'erreurs et les exemples.

Nous avons aussi effectu� plusieurs modifications sur les r�gles relatives aux syntagmes verbaux. Le formalisme XML est plus souple que celui de An Gramad�ir, ce qui nous a permis de faire des simplifications et de regrouper plusieurs r�gles en une seule.

Dans An Gramad�ir, il faut par exemple 4 r�gles pour dire qu'il y a une erreur si :

"je" est suivi d'un verbe � la 1�re personne du pluriel

[Jj]e <VUNP>ANYTHING</VUNP>:AGGREEMENT

"je" est suivi d'un verbe � la 3�me ou 4�me personne

[Jj]e <VUN>ANYTHING</VUN>:AGGREEMENT

"je" est suivi d'un mot quelconque, puis d'un verbe � la 1�re personne du pluriel

[Jj]e ANYTHING <VUNP>ANYTHING</VUNP>:AGGREEMENT

"je" est suivi d'un mot quelconque, puis d'un verbe � la 3�me ou 4�me personne

                    [Jj]e ANYTHING <VUN>ANYTHING</VUN>:AGGREEMENT

Dans LanguageTool, nous avons pu tout regrouper en une seule r�gle :
   <rule name="je + (x) + V">
       <pattern>
           <token postag="R pers suj 1 s" postag_regexp="yes" skip="1"/>
           <token postag="V .* 1 p|V .* 2 .*|V .* 3 .*" postag_regexp="yes"/>
       </pattern>
       <message>Le pronom personnel n'est pas accord� avec le verbe</message>
       <example type="correct">je travaille</example>
       <example type="incorrect">je travaillons</example>
   </rule>

Dans An Gramad�ir, nous pouvons aussi trouver une r�gle diff�rente pour "il", "elle", "on", "elles" et "ils". Il semblait plus logique de g�n�raliser ces r�gles pour les regrouper. Ainsi, les 5 pronoms sont trait�s dans seulement 2 r�gles qui concernent les pronoms personnels sujets, � la 3�me du singulier pour "il", "elle" et "on", ou bien du pluriel pour "ils" et "elles". Par ailleurs, nous avons rajout� les cas de "elle" et "elles" dans certaines r�gles car ils avaient �t� oubli�s.

Quelques tests

Apr�s ces modifications, nous avons effectu� quelques tests. Nous avons alors remarqu� plusieurs probl�mes.

Les r�gles sur les syntagmes nominaux g�n�rent des alarmes redondantes. Si nous �crivons par exemple : "*le couverture bleue d�chir�e", l'erreur d'accord en genre entre le d�terminant et le reste du syntagme va �tre signal�e 3 fois par 3 r�gles diff�rentes :
- une premi�re r�gle va s'appliquer � "le couverture" => Det + N
- une seconde r�gle va s'appliquer � "le couverture bleue" => Det + N + Adj
- une derni�re r�gle va s'appliquer � "le couverture bleue d�chir�e" => Det + N + Adj + Adj

Les mots �pic�nes et invariables ne sont pas pris en compte dans les r�gles. Dans une phrase comme "*Il va �pouser un c�l�bre actrice", aucune faute ne sera d�tect�e car "c�l�bre" est �pic�ne et aucune r�gle n'est pr�vue avec ce genre de mots.

L'absence de d�sambigu�sation g�n�re �norm�ment de fausses alarmes. Par exemple, "je vois" et "je mange" sont tous deux signal�s comme faux. Les deux verbes sont bien �tiquet�s "1�re personne du singulier", mais ils poss�dent aussi d'autres tags, dont respectivement celui de "2�me personne" et "3�me personne", ce qui est incompatible avec un pronom personnel � la 1�re personne.

Quelques ajouts possibles

Nous avons �tudi� un corpus d'erreurs � notre disposition. Nous avons d'abord �limin� les phrases contenant des fautes d'orthographe et non de grammaire. Nous avons ensuite fait un petit classement des phrases restantes, en 4 cat�gories :

les erreurs qui sont d�j� d�tect�es par les r�gles actuelles ("je ne doit pas �tre...")
les erreurs pour lesquelles nous pensons pouvoir cr�er des r�gles avec le formalisme actuel de LanguageTool ("on d�sir...")
les erreurs qui pourront �tre d�tect�es avec un nouveau formalisme utilisant les chunks et l'unification ("le monde m'appartenais...")
les erreurs qui nous semblent tr�s difficiles, voire impossibles � rep�rer ( "je serais" ≠ "je serai")

Pour le moment, nous allons nous concentrer sur la seconde cat�gorie. Nous avons vu que nous pourrions cr�er des r�gles sur la n�gation, rajouter des r�gles sur l'accord des participes pass�s apr�s le verbe �tre (par exemple : sont+ppa => le ppa doit �tre au pluriel), modifier les r�gles actuelles sur les accords des verbes pour qu'elles tiennent compte de l'insertion possible d'un ou plusieurs mots entre le sujet et le verbe, le verbe et le participe pass�, etc...

Un d�sambigu�seur pour bient�t ?

Marcin Milkowski a propos� de travailler sur l'implantation du d�sambigu�seur qui nous posait probl�me. Si tout va bien, nous devrions en disposer tr�s prochainement. Nous pourrons alors faire en sorte d'avoir un minimum de d�sambigu�sation pour pouvoir travailler sur les r�gles d'erreurs dans de meilleures conditions.

Resume about the french grammar checker project

I have recently started to work on the project of a free french grammar checker which could be implemented in OpenOffice.org.
Myriam Lechelt had initiated this project 2 years ago by adapting Gramadoir, a gaelic grammar checker developped by Kevin Scanell. But this tool appeared not to be very suitable for french grammar.
Myriam had also analyzed other grammar checker, amongst which LanguageTool. It is a rule-based style and grammar checker initially developped for English by Daniel Naber, and then extended to German, Polish or Hungarian. It was rejected at the time by Myriam, but it has progressed a lot. So we have decided to work on the new version for our french grammar checker.

In her work, Myriam has given leads to create a new grammar checker for French. For example, she advises to segment sentences in chunks, between the sentence and the word. She also suggests to use grammar unification and feature structure to find grammar mistakes.

How do grammar checkers work ?

First of all, a tokenizer segments the text into sentences and words. Then a tagger gives tag(s) to each token, containing morphosyntactic information like the gender, the number, the tense, the person, etc...

Many words have several tags, so a disambiguation is often necessary to eliminate inappropriate tags in certain contexts and to keep only the good tag. The method to disambiguate can either be statistic or rule based. The statistic methods needs a learning tagged corpus, and then the grammar checking is very dependent on this corpus. The rule-based method requires a large number of hand-made rules, describing the context in which a word must have a certain tag. This second method is easier to control.

Finally, a pattern matching with the text and rules is used in the grammar checking. It can either be grammar rules or error rules. The first describe what is good and everything that does not match them is considered as false. This can be very annoying since it can wrongly detect many errors if rules are not exhaustive. On the contrary, error rules describe what is wrong and everything that matches them is considered as false. But even if rules are very numerous, as it is impossible to anticipate all mistakes, there will always be not detected errors. But this is preferable to wrong detections.

About LanguageTool

LanguageTool is a style and grammar checker developped by Daniel Naber. It is composed of several parts in java successively proceeding to the tokenization in sentences and words, the tagging and the detection of grammar mistakes.

There is no disambiguation after the tagging, so many words can have more than one tag. But a disambiguator interface has been implemented for the languages for which it is a problem not to have disambiguation.

The detection of errors is based on error rules formalized in XML. Each rule has an identifier (id), a name, a pattern describing the context of the mistake, a message explaining the mistake, and examples to show a correct and incorrect sentence corresponding to the mistake.

Tests with French and problems encountered

We have tested the few rules ported from An Gramad�ir and written by Myriam Lechelt. We have immediately noticed that the absence of disambiguation would be an important problem for French checking. Indeed, the detection of mistakes almost always failed because of ambiguous words.
We have tried to get round this problem by modifying the rules to take ambiguity in account, but we realized that it would be very tedious to build every rule like that. The best solution is to implement a disambiguator after the tagging. That is what we will try to do.

We also became aware of the problem raised by the structure of the rules, and more precisely of the pattern in the rules and the method of rigid pattern matching. It requires the description of all contexts in which a mistake can be found, that is to say the description of all possible combinations of words, and a rule for each one. But it is just impossible to anticipate all of them. We could only write a very large number of rules which would never be exhaustive, and which would be costly for the processing.

An alternative with chunks and unification

According to Abney, "The typical chunk consists of a single content word surrounded by a constellation of function words, matching a fixed template" (S. P. Abney, 1991, Parsing by chunks).
The internal structure of a chunk is fixed, but function words inside are all dependant of the lexical head and agree with it. In the sentence, chunks agree whit each other, and they can easily permute, contrary to words in a chunk.

Feature structures describe each element in a sentence with a list of pairs feature-value. Unification consists in matching the feature structures of different elements. The matching failes if a feature does not have the same value in the feature structures of the different elements tested.

The use of both chunks and unification is a very interesting alternative. It can make grammar checking really easier. First, by unifying features only, and not grammatical category, we reduce considerably the number of necessary rules, since we do no more need to enumerate all possible combinations of words.
Then, the relations between chunks will be very helpful for some checkings, like the aggreement with the subject and the verbal chunk, or more generally for all agreement with distant words. Indeed, distant relations cannot be checked with a system only applying pattern matching on the immediate context.

Disambiguation

Myriam Lechelt has built many disambiguation rules for An Gramad�ir. We intended to port them to LanguageTool, so we have analyzed java files to see how we could add them, and we have thought about how to improve disambiguation.

It would be logical to rewrite the rules in XML, since it is the formalism used by LanguageTool for all rules. Moreover, XML rules can be more easily understood and maintained by linguists who are not necessarily computer scientists.

It could be preferable, in some cases, not to disambiguate a word totally, but only the grammatical category. Because of an ambiguity of features, some mistakes may not be detected, but with a bad disambiguation of features, wrong mistakes can be detected, which is much more annoying for the user.

We have thought about disambiguation, how to improve it and how to port rules to LanguageTool. But in fact, we have finally decided not to implement disambiguation now, since we lack time and it is more important for us to improve grammar checking. Instead, we will tag and disambiguate sentences from a corpus of mistakes, and we will use these sentences for the next step, that is to say the grammar checking.

Suite du travail sur LanguageTool

Ces derniers jours ont �t� consacr�s en partie � l'�tude des possibilit�s d'int�gration d'un d�sambigu�seur dans LanguageTool.

Nous avions parl�, dans le pr�c�dent billet, de r��crire les r�gles de d�sambigu�sation de An Gramad�ir dans le formalisme XML. Il y a bien s�r beaucoup de mani�res diff�rentes de repr�senter les r�gles en XML.

Voici deux propositions qui reprennent des r�gles �crites par Myriam Lechelt. Les deux premi�res r�gles sont tr�s proches de la repr�sentation des r�gles d'erreurs de LanguageTool. Dans les deux suivantes, nous avons ajout� un attribut "ambigu" � l'�l�ment token, pour sp�cifier quel est le token ambigu, et une balise "disambig" qui contient le tag � attribuer au token ambigu.

<rulegroup name="Pronoms personnels objets" id="Pro_Pers_Obj">
   <rule name="nous">
       <pattern>
           <token postag="R Pers"/>
           <token ambig="yes">nous</token>
       </pattern>
       <disambig token="nous" postag="R pers obj 1 p"/>
   </rule>
</rulegroup>
<rulegroup name="D ambig + N" id="D_ambig_N">
   <rule name ="Dms">
       <pattern>
           <token ambig="yes" postag="D m s"/>
           <token postag="N"/>
       </pattern>
       <disambig postag="D m s"/>
   </rule>
</rulegroup>

---------------------------------------------------

<rulegroup name="Pronoms personnels objets" id="Pro_Pers_Obj">
   <rule name="nous">
       <pattern mark_from="1">
           <token postag="R Pers"/>
           <token>nous</token>
       </pattern>
       <message><suggestion>R pers obj 1 p</suggestion></message>
   </rule>
</rulegroup>
<rulegroup name="D ambig + N" id="D_ambig_N">
   <rule name ="Dms">
       <pattern mark_to="-1">
           <token postag="D m s"/>
           <token postag="N"/>
       </pattern>
       <message><suggestion>D m s</suggestion></message>
   </rule>
</rulegroup>

Nous avons aussi "d�cortiqu�" un peu le code de LanguageTool pour voir comment sont g�r�es les r�gles d'erreurs, et nous en inspirer pour g�rer les r�gles de d�sambigu�sation. Nous avons donc vu qu'il nous faudrait adapter principalement 3 fichiers : PatternRule.java, PatternRuleLoader.java et XMLRuleHandler.java.

Cependant, par manque de temps, nous n'allons pas r�aliser ce travail d'implantation d'un d�sambigu�seur.
Nous allons donc passer directement � l'�tape du traitement des fautes de grammaire. Par contre, pour pouvoir travailler sur cette partie de LanguageTool, nous avons besoin de phrases correctement �tiquet�es, et donc d�sambigu�s�es. Nous avons donc extrait une centaine de phrases d'un corpus d'erreurs, utilis� dans l'ouvrage de V. Lucci & A. Millet (1994 ; L'orthographe de tous les jours, enqu�te sur les pratiques orthographiques des fran�ais, Champion), et nous allons les �tiqueter, en utilisant le tagset de LanguageTool.

Nous pourrons ensuite utiliser ces phrases �tiquet�es pour tester les r�gles d'erreurs �crites par Myriam pour An Gramad�ir, et que nous aurons pr�alablement import�es dans LanguageTool, ainsi que de nouvelles r�gles que nous pourrons ajouter � partir du corpus.

Nous verrons sans doute ainsi les limites du formalisme actuel et nous t�cherons de les d�passer.

R�flexions sur le "d�sambigu�seur"

J'ai commenc� � regarder d'un peu plus pr�s le code source de LanguageTool, le but �tant de mieux comprendre le fonctionnement du programme et de voir comment implanter un d�sambigu�seur. L'op�ration s'est r�v�l�e un peu laborieuse �tant donn� que je suis d�butante en Java et qu'il m'a fallu apprivoiser un peu ce langage...
J'ai essay� de voir comment utiliser l'interface "disambiguator", r�cemment ajout�e � LanguageTool (par Jozef Ličko). Elle permet l'implantation �ventuelle d'un d�sambigu�seur pour les diff�rentes langues support�es par le programme. Il nous reste donc � d�velopper ce d�sambigu�seur pour le fran�ais.

Pour ce qui est de la d�sambigu�sation en elle-m�me, nous allons reprendre les r�gles �crites par Myriam pour Gramadoir. Nous avons plusieurs possibilit�s pour les formaliser. Nous pourrions les �crire simplement au format texte, ou bien encore conserver leur formalisme actuel. Nous avons plut�t d�cid� de les r��crire dans un fichier au format XML. Ce formalisme a l'avantage d'�tre plus facilement lisible et modifiable par des linguistes, qui ne sont pas forc�ment informaticiens. Par ailleurs, nous restons ainsi coh�rents avec le programme qui utilise d�j� ce formalisme pour les r�gles d'erreurs.
Nous allons donc garder les r�gles �crites pour Gramadoir et conserver leur ordre. Cet ordre est essentiel et correspond � une pr�cision d�croissante des r�gles : il y a d'abord des r�gles particuli�res qui traitent des cas pr�cis, puis des r�gles par d�faut un peu plus g�n�rales, et enfin des r�gles brutes tr�s g�n�rales qui traitent tous les cas qui ne l'ont pas �t� par les pr�c�dentes r�gles.
Apr�s l'�tape du tagging, lorsque les mots ont re�u leur(s) �tiquette(s), il faut v�rifier si une r�gle de d�sambigu�sation dans le fichier XML peut s'appliquer � un mot ambigu. Plus pr�cis�ment, il faut passer toutes les r�gles en revue, dans l'ordre, jusqu'� ce que l'une d'entre elles soit applicable � un des tags, et ne conserver alors que le tag correspondant � cette r�gle.

Les classes java intervenant dans la d�tection des fautes de grammaire vont nous servir d'exemple et nous permettre de mieux voir comment construire notre d�sambigu�seur. M�me si le fonctionnement n'est pas vraiment identique, on retrouve le syst�me du "pattern matching" (concordance entre 2 �l�ments) entre des r�gles en XML, et des mots et leur contexte.

Des probl�mes � pr�voir

Les r�gles s'appuient sur le contexte du mot ambigu. Myriam a indiqu� � leur sujet que si le contexte est lui-m�me ambigu (au niveau des cat�gories morpho-syntaxiques), ces r�gles ne peuvent pas fonctionner. Nous allons nous aussi bien s�r �tre confront�s � ce probl�me.
Si la d�sambigu�sation est effectu�e lin�airement, au fur et � mesure, nous aurons alors un contexte gauche d�sambigu�s� et un contexte droit tr�s souvent encore ambigu. Or quelques r�gles (environ 1 sur 5) utilisent ce contexte droit. Il est donc � pr�voir qu'elles ne pourront, dans certains cas, pas s'appliquer. Pour ce qui est des r�gles qui portent sur le contexte gauche, elles sont d�pendantes de la bonne d�sambigu�sation de ce contexte. En cas d'erreur, la suite de la d�sambigu�sation peut �tre mal effectu�e.

Pour le moment, nous n'allons pas chercher � am�liorer la d�sambigu�sation. Nous n'en avons malheureusement pas le temps. Ceci fera probablement l'objet d'un travail ult�rieur. Nous avons tout de m�me r�fl�chi � des solutions. Il faudrait par exemple que le traitement ne se fasse pas lin�airement, mais plut�t en fonction des mots ambigus ou pas : commencer par d�sambigu�ser les mots qui peuvent l'�tre de mani�re s�re, ceux dont le contexte n'est pas ambigu par exemple, et continuer jusqu'� ce que tous les mots de la phrase soient trait�s, en gardant les cas les plus compliqu�s pour la fin.
Il faudrait aussi pouvoir revenir en arri�re pour pouvoir corriger une mauvaise d�sambigu�sation. Et comme nous l'avons d�j� vu, une segmentation en chunks pourrait �galement �tre utile.

D�sambigu�sation

Avant de nous lancer dans la conception d'un outil de d�sambigu�sation, prenons le temps de faire un petit point sur ce sujet. Nous verrons d'abord quelles sont les diff�rentes m�thodes existantes pour d�sambigu�ser les mots polycat�goriels (appartenant � plusieurs cat�gories morpho-syntaxiques). Nous parlerons ensuite de la m�thode choisie par Myriam, ainsi que des probl�mes qu'elle a rencontr�s, et pour finir nous ferons des suggestions pour r�soudre certaines difficult�s et am�liorer la d�sambigu�sation.

M�thodes de d�sambigu�sation

Les d�sambigu�seurs sont de deux types. Certains sont probabilistes et d'autres � base de r�gles. Ils ont tous deux des avantages et des inconv�nients.

1. M�thode statistique

Des probabilit�s sont calcul�es � partir d'un apprentissage sur un corpus �tiquet�. Selon le syst�me, les probabilit�s calcul�es sont celles de la contigu�t� de 3 tags (ex.: GRAC), de 2 tags (ex.: premi�re version de LanguageTool), ou celles que tel mot prenne tel tag.

Cette m�thode a l'avantage d'�tre automatique et donc relativement facile � mettre en place. Un outil probabiliste peut par ailleurs �tre facilement appliqu� � des langues diverses. Il suffit de fournir le corpus ad�quat pour l'apprentissage des probabilit�s.

Par contre, la d�sambigu�sation est par la suite enti�rement d�pendante du corpus sur lequel a �t� effectu� l'apprentissage. Ce corpus ne doit pas �tre trop sp�cialis� et doit �tre suffisamment grand pour contenir le maximum de structures, tout en ne pouvant jamais les contenir toutes. Qui plus est, il n'existe pas pour le fran�ais par exemple de corpus �tiquet� qui soit librement utilisable, ce qui constitue donc un obstacle.

Par ailleurs, en cas d'erreur de d�sambigu�sation, il n'y a aucun recours possible au texte. Cette m�thode n'est donc pas vraiment ma�trisable.

2. M�thode par r�gles

Les r�gles sont construites manuellement, elles se pr�sentent g�n�ralement sous forme d'expressions r�guli�res (ex.: Gramadoir) et portent sur le contexte imm�diat.
Comme les r�gles de d�tection d'erreurs, elles fonctionnent sur le syst�me du "pattern matching". Le mot et son contexte proche doivent donc correspondre exactement aux descriptions faites dans les r�gles pour pouvoir �tre d�sambigu�s�s.
Si les syst�mes appliquent les r�gles dans l'ordre o� elles apparaissent dans le fichier, elles doivent �tre ordonn�es (les plus g�n�rales en dernier).

L'avantage de cette m�thode, par rapport � la m�thode statistique, est qu'elle est bien plus maitr�sable. En cas d'erreur de d�sambigu�sation, il est facile de retrouver et modifier la r�gle qui pose probl�me. Il est par ailleurs possible de rajouter de nouvelles r�gles ou d'en supprimer selon les besoins.

Par contre, cette m�thode requiert la r�daction, longue et co�teuse, de nombreuses r�gles.

D�sambigu�sation pour Gramadoir

Myriam Lechelt a r�alis� un important travail sur la d�sambigu�sation dans le cadre de l'adaptation de Gramadoir au fran�ais.
Elle a r�alis� des r�gles de d�sambigu�sation dont elle a pu tester l'efficacit�, en terme de d�cision (nombre de mots d�sambigu�s�s) et de pr�cision (nombre de mots d�sambigu�s�s correctement), avec les outils de la campagne d'�valuation GRACE.

Ces r�gles sont de trois types :

Au d�but du fichier se trouvent les r�gles particuli�res, qui d�sambigu�sent des cas bien pr�cis. Ces r�gles ne fonctionnent que sur contexte non ambigu (au niveau de la cat�gorie morpho-syntaxique).
Viennent ensuite les r�gles par d�faut. Ces r�gles sont appliqu�es par exemple lorsque qu'un contexte ambigu emp�che l'application des r�gles particuli�res. L'utilisation de r�gles par d�faut est sugg�r�e par Jacques Vergne et Emmanuel Giguet (Regards th�oriques sur le tagging, 1998, GREYC, Universit� de Caen).
Pour finir, des r�gles brutes tr�s g�n�rales d�sambigu�sent tout (ou presque) ce qui n'a pas pu �tre d�sambigu�s� avec les r�gles pr�c�dentes. Ces r�gles sont n�cessaires pour que plus aucun mot ne soit ambigu, car sinon la correction �choue. Le syst�me de Gramadoir ne tol�re en effet aucune ambigu�t�.

Avec ses r�gles, Myriam a pu d�sambigu�ser 98,88% des mots (d�cision), dont 84,49% avec la bonne �tiquette (pr�cision), ce qui est plut�t encourageant m�me s'il reste encore beaucoup de travail et de probl�mes � r�soudre.

Par exemple, la d�sambigu�sation de la n�gation ne pas, ainsi que des modes et des personnes pour les verbes, pose un probl�me qui n'a pas �t� r�solu.
Ce probl�me est d� notamment au fait que la d�sambigu�sation utilise le contexte imm�diat du mot � d�sambigu�ser. Dans le cas des modes, le contexte imm�diat ne suffit pas et une analyse de la phrase enti�re est n�cessaire pour d�sambigu�ser.
Par ailleurs, le contexte peut parfois �tre inconnu, ambigu ou faux, et dans ce cas la d�sambigu�sation est mal ou pas du tout effectu�e. Une r�gle disant que "si pas est pr�c�d� de ne, alors pas est adverbe de n�gation" ne d�sambigu�sera que si elle trouve ne dans le contexte. Or, l'oubli de ne est justement une faute tr�s fr�quente en fran�ais.

Suggestions d'am�lioration

La d�sambigu�sation a pour but de d�finir pour chaque mot une �tiquette unique, parmi celles attribu�es par le tagger. Mais une d�sambigu�sation erron�e, conduisant donc � un mauvais �tiquetage, peut entra�ner de fausses d�tections lors de la v�rification grammaticale. Or, le bruit est tr�s g�nant pour l'utilisateur, bien plus que le silence.

Ne vaudrait-il pas mieux laisser plusieurs �tiquettes dans certains cas ? En particulier dans le cas d'une ambigu�t� au niveau des traits pour une m�me cat�gorie ? Nous pourrions limiter la d�sambigu�sation aux seules cat�gories, et non aux tags complets.

Par exemple, si l'utilisateur a �crit une livre, le d�sambigu�seur d�duira sans doute sans difficult�, gr�ce au d�terminant, que livre est ici un nom et non le verbe livrer. Mais une ambigu�t� persiste alors au niveau du genre de ce nom, puisqu'il peut �tre masculin ou f�minin. Si une r�gle par d�faut attribue le tag "N sing masc" � livre, lors de la d�tection d'erreurs, le syst�me va rep�rer un probl�me d'accord entre une et livre, alors que l'utilisateur n'avait en fait pas commis d'erreur. En laissant l'ambigu�t� au niveau du trait genre, aucune erreur n'aurait �t� d�tect�e.

L'avantage de cette m�thode est qu'elle privil�gie le silence au bruit. Elle peut en effet laisser passer de vraies fautes puisque l'�tiquetage est moins pr�cis, mais elle permet aussi de r�duire les mauvaises d�tections dues � un mauvais �tiquetage. La faute est d�tect�e seulement si aucune des �tiquettes ne convient.

L'int�r�t r�side aussi dans la r�solution partielle des probl�mes dus � un contexte faux. Il faut en effet garder � l'esprit que le tagging s'effectue sur des phrases potentiellement fausses, puisque le but est justement d'en v�rifier la grammaire. Ainsi, si nous avons le syntagme le plante, (plante pouvant �tre un nom ou un verbe) avec une r�gle qui dit que "si un nom f�minin singulier ambigu est pr�c�d� d'un d�terminant f�minin singulier, alors c'est un nom f�minin singulier", dans ce cas la r�gle ne correspond pas puisque le d�terminant est masculin. La d�sambigu�sation n'est donc pas effectu�e.
En ne travaillant qu'avec les cat�gories des mots ambigus, on aurait une r�gle du type : "si un nom ambigu est pr�c�d� d'un d�terminant, alors c'est un nom". Dans ce cas, la r�gle de d�sambigu�sation peut s'appliquer.

Par contre, LanguageTool fonctionne actuellement d'une mani�re diff�rente de celle que nous venons d'�voquer, � savoir la non application d'une r�gle d'erreur si un des tags ne lui correspond pas. En effet, lorsqu'il rencontre un mot ambigu (il n'a pas de d�sambigu�seur), il essaye d'appliquer les r�gles � tous les tags du mot. Il suffit qu'un seul d'entre eux corresponde � la r�gle pour qu'elle s'applique (cf. test des r�gles). Il faudrait au contraire que la r�gle ne s'applique que si tous les tags lui correspondent. Autrement dit, une seule �tiquette ne remplissant pas les conditions de la r�gle devrait suffire � emp�cher son application.

Par ailleurs, la d�sambigu�sation pourrait aussi �tre am�lior�e en utilisant des r�gles de d�duction n�gative, c'est-�-dire des r�gles permettant de dire que, dans tel contexte, un mot ne peut pas avoir telle �tiquette.
Gramadoir ne prend pas en charge ce genre de r�gles. Il n'utilise que la d�duction "affirmative", pour laquelle il est n�cessaire d'�crire des r�gles parfois nombreuses pour �num�rer tous les contextes dans lesquels tel mot prend tel tag. Il serait utile dans ces cas-l� de pouvoir utiliser des r�gles fonctionnant sur le principe de l'�limination.
Cependant, tout comme l'application des r�gles "affirmatives" d�pend du contexte imm�diat, les r�gles n�gatives d�pendent de l'exhaustivit� de la liste des tags attribu�s � chaque mot. En effet, il faut imp�rativement que l'�tiquette attendue fasse partie de la liste. Or les lexiques ne sont pas n�cessairement exhaustifs.

Conclusion

Nous voyons un peu mieux ce qu'il en est de la d�sambigu�sation, les diff�rentes mani�res de la r�aliser, avec leurs avantages et leurs inconv�nients, les probl�mes qui peuvent se poser, les solutions et am�liorations que l'on peut apporter.
Nous pouvons donc maintenant r�fl�chir plus s�rieusement � la mani�re dont nous allons construire le d�sambigu�seur que nous implanterons dans LanguageTool, pour traiter les nombreux cas d'ambigu�t� morpho-syntaxique que compte la langue fran�aise.

Int�r�t des chunks et de l'unification pour la correction grammaticale

L'int�r�t le plus �vident concerne les accords entre les divers �l�ments de la phrase. Il peut s'agir aussi bien d'accords dans un groupe nominal que d'accords entre le sujet et le verbe par exemple.

Correction "intra-chunk"

Les mots fonctionnels contenus dans un chunk sont d�pendants de la t�te du chunk et contraints de s'accorder avec elle. En attribuant des traits morpho-syntaxiques � tous les �l�ments d'un syntagme et en utilisant une m�thode d'unification des traits, il est assez facile, au niveau de la correction grammaticale, de d�tecter une erreur au sein d'un syntagme. Tous les �l�ments d'un chunk doivent avoir leurs traits qui s'unifient entre eux. Si �a n'est pas le cas, c'est qu'il y a une erreur.
Autrement dit, dans un chunk nominal qui serait du type "DET ADJ N" (ex: les grandes vacances), le d�terminant "DET" et l'adjectif "ADJ" doivent tous deux s'accorder avec le nom "N" qui est la t�te du chunk. Leurs traits doivent donc s'unifier.
En utilisant un d�coupage par chunks et l'unification de traits, on ne fait plus d'accord mot � mot et entre cat�gories de mots. On n'accorde plus un "d�terminant masculin singulier" avec un "nom masculin singulier", mais un �l�ment "masculin singulier" avec un autre "masculin singulier". En s'int�ressant aux traits et non plus aux cat�gories, on �vite ainsi d'avoir � pr�voir toutes les combinaisons de mots pouvant constituer un syntagme nominal par exemple ("DET NOM", "DET ADJ NOM", "DET NOM ADJ", "DET ADV ADJ NOM ADJ", etc).

Correction "inter-chunks"

La d�tection des fautes de grammaire passe ensuite par une bonne mise en relation des �l�ments dans la phrase. De la m�me mani�re que tous les �l�ments d'un chunk doivent s'unifier entre eux, tous les chunks d'une phrase doivent aussi s'unifier. La m�thode d'unification des traits peut donc permettre d'accorder facilement les syntagmes, en fonction des relations qu'ils entretiennent entre eux et avec le syntagme verbal.
Par exemple, si le chunk verbal a le trait "3�me pers sing", alors le chunk sujet doit obligatoirement avoir le trait "3�me pers sing" pour que l'unification des 2 chunks puisse se faire. Dans le cas contraire, une erreur d'accord sujet-verbe sera d�tect�e.
Les accords se font entre groupes. Il n'est plus n�cessaire de construire un nombre tr�s important de r�gles d�crivant toutes les combinaisons possibles. On �vite par exemple d'avoir � pr�voir toutes les combinaisons de mots que l'on peut trouver avant un verbe, en tant que sujet, ce qui est par ailleurs impossible. Les chunks permettent le traitement par groupes de mots, ayant chacun des r�gles sp�cifiques selon leur type, ce qui permet de beaucoup simplifier l'analyse syntaxique.

Correction dans les relations distantes

Ce type de traitement peut aussi s'av�rer utile pour traiter certaines relations de d�pendance distantes, qui posent beaucoup de probl�mes aux correcteurs grammaticaux. Un simple accord entre un sujet et un verbe �loign�s peut �tre tr�s difficile � v�rifier. Or, une propri�t� du chunk sujet est d'�tre g�n�ralement le premier syntagme � gauche du chunk verbal, � condition que ce syntagme soit nominal. Le d�coupage en chunks peut donc aider � r�soudre les probl�mes de d�tection de certaines fautes auxquels se heurtent une grande partie des correcteurs.

Aide � la d�sambigu�sation

Par ailleurs, la segmentation en syntagmes peut avoir un int�r�t au niveau de la d�sambigu�sation. Par exemple, m�me si cela semble �vident, un chunk nominal doit obligatoirement contenir un nom. Si un syntagme nominal ne contient pas de nom, le syst�me recherche dans le chunk un mot ambigu qui peut avoir le tag "nom" mais qui ne lui a pas �t� attribu�, et rectifie alors l'�tiquetage afin que le chunk contienne un nom. Un chunk nominal sans nom peut �tre d�fini lorsque le syst�me rencontre un d�terminant (condition d'ouverture d'un chunk nominal) et lorsque le nom qui le suit est ambigu (avec un verbe par exemple) et mal �tiquet�. On obtient ansi un chunk nominal constitu� d'un d�terminant, puis d'un verbe.

Conclusion

L'utilisation combin�e des chunks et de l'unification peut donc nous permettre de r�duire consid�rablement le nombre de r�gles n�cessaires � la bonne correction de la grammaire fran�aise. Elle peut aussi aider � la d�tection probl�matique de certaines fautes entre chunks distants, et �ventuellement compl�ter la d�sambigu�sation.

Chunks et unification

Nous avons pu noter, � travers quelques tests, que les points faibles de LanguageTool, pour la correction grammaticale du fran�ais en particulier, sont l'absence de d�sambigu�sation et les r�gles de d�tection des fautes.

Une partie de notre travail va donc consister � r�aliser un outil de d�sambigu�sation qui nous permettra de r�duire le nombre de tags des mots ambigus (sans toutefois le limiter n�cessairement � un tag unique). Nous pourrons nous aider pour cela des r�gles de d�sambigu�sation �crites par Myriam Lechelt pour Gramadoir.

Pour ce qui est des r�gles d'erreurs, nous allons utiliser l'approche propos�e par Myriam, � savoir la segmentation en chunks et l'unification de structures de traits. Voici une petite explication sur ce qui se cache derri�re ces deux notions.

Qu'est-ce qu'un chunk ?

Un chunk, ou syntagme, est "une unit� constitu�e d'une s�rie de mots tous contigus les uns aux autres et regroup�s autour d'une t�te lexicale, le plus souvent un nom ou un verbe, plus rarement un adverbe, un adjectif ou un pronom." (GIGUET, 1998).

Les chunks sont d�limit�s gr�ce aux mots grammaticaux, � la ponctuation ou aux marques morphologiques. En g�n�ral, un chunk commence par un mot grammatical ou juste apr�s une ponctuation, et se termine juste avant une ponctuation ou le mot grammatical suivant, qui marquent le d�but d'un nouveau syntagme.

Par exemple, un syntagme nominal contient obligatoirement un nom (t�te du chunk) et commence g�n�ralement par un d�terminant. Un syntagme verbal commence par un verbe, parfois un pronom personnel ou un adverbe de n�gation, et contient n�cessairement un verbe.

Un chunk d�pend g�n�ralement de son pr�d�cesseur, sauf dans le cas d'un chunk verbal. Ce dernier d�pend du chunk sujet, qui correspond en principe au premier syntagme � gauche, � condition qu'il soit nominal.

La structure interne d'un chunk est relativement fig�e. Les mots fonctionnels qu'il contient entretiennent des relations de d�pendance avec la t�te lexicale et les contraintes d'accords sont assez fortes. Par contre, au sein d'une phrase, les diff�rents chunks sont permutables. Dans l'exemple suivant extrait du Bourgeois Gentilhomme de Moli�re, nous pouvons voir que la phase est constitu�e de cinq syntagmes que l'on peut permuter, mais au sein desquels les �l�ments ont une place fixe :

[Belle Marquise], [vos beaux yeux] [me font] [mourir] [d'amour].
[D'amour] [mourir] [me font], [belle Marquise], [vos beaux yeux].
[Vos yeux beaux] [d'amour] [me font], [belle Marquise], [mourir].
[Mourir] [vos beaux yeux], [belle Marquise], [d'amour] [me font].
[Me font] [vos yeux beaux] [mourir], [belle Marquise], [d'amour].

Un chunk d�pend g�n�ralement de son pr�d�cesseur, sauf dans le cas d'un chunk verbal.

Qu'est-ce que l'unification de structure de traits ?

Les structures de traits d�crivent chaque �l�ment d'une phrase un �num�rant ses caract�ristiques linguistiques, syntaxiques ou s�mantiques, sous la forme de listes de couples trait-valeur.
Un trait peut avoir pour valeur un ou plusieurs couples trait-valeur. Dans ce cas, la structure de trait est dite r�cursive.

L'unification consiste � combiner les informations (sous forme de structures de traits) de deux �l�ments d'une phrase et permet de v�rifier leur compatibilit�.
Si 2 structures de traits ont les m�mes valeurs pour des traits identiques, alors elles peuvent s'unifier. Si 2 traits identiques n'ont pas la m�me valeur dans les 2 structures de traits, alors l'unification �choue. Si un trait n'est pr�sent que dans une des deux structures, cela n'influe pas sur l'unification, qui �choue dans le cas de valeurs contradictoires pour un m�me trait, mais pas dans le cas d'absence d'un trait.

Il y a unification entre les et chats dans l'exemple 1 ci-dessous, mais pas entre les et chat dans l'exemple 2, car les traits "nombre" ont deux valeurs contradictoires :

Test rapide de LanguageTool (sur le fran�ais)

Tests de r�gles existantes

Nous avons rapidement test� LanguageTool avec quelques r�gles en fran�ais, �crites par Myriam Lechelt pour Gramadoir, et adapt�es ensuite au formalisme de LanguageTool.

Cons�quences de l'absence de d�sambigu�sation

Nous avons alors pu remarquer beaucoup de probl�mes dans la d�tection des erreurs, dus principalement � l'absence de d�sambigu�sation apr�s le tagging. En effet, les mots ambigus ont plusieurs tags et lors de l'application des r�gles d'erreurs, il suffit qu'un des tags corresponde � une r�gle pour que celle-ci soit appliqu�e, m�me si un ou plusieurs autres tags du mot ne correspondent pas � cette r�gle.
On peut constater cela avec l'exemple suivant, portant sur la confusion entre sa et �a.

Nous disposons des deux r�gles suivantes :

si sa est suivi d'un verbe puis d'un mot quelconque, alors il y a une erreur et il faut remplacer sa par �a.
si �a est suivi d'un nom puis d'un mot quelconque, alors il y a une erreur et il faut remplacer �a par sa.

Prenons maintenant les deux phrases :

(a) Sa voiture est en panne.
(b)*�a voiture est en panne.

Le mot voiture est ambigu. Il peut s'agir du nom voiture ou du verbe voiturer. Le mot a donc 2 �tiquettes : "nom" et "verbe".

Lors de la v�rification des phrases, tous les tags d'un mot sont pris en compte pour l'application des r�gles.
La r�gle 1. s'applique donc (� tort) � la phrase (a) car elle trouve un tag "verbe" pour voiture, pr�c�d� de sa. Il est alors sugg�r� de remplacer sa par �a. Il aurait fallu ici que le tag "verbe" soit ignor� et que seul le tag "nom" soit pris en compte puisque c'est celui qui correspond au mot voiture dans cet exemple.

La r�gle 2. s'applique � la phrase (b) car elle trouve un tag "nom" pour voiture, pr�c�d� de �a. Il est alors sugg�r� de remplacer �a par sa. Ici, la d�tection est correcte. Il y a bien une faute.

Les �nonc�s (a) et (b) sont donc tous deux consid�r�s comme faux, chacun donnant l'autre comme correction, ce qui est contradictoire.

Tentative de contournement du probl�me...

Nous avons tent� de r�duire le bruit provoqu� par la r�gle 1. en la modifiant : �a suivi de 2 verbes au lieu d'un seul. Cela permet de pallier en partie le probl�me de l'ambigu�t� de voiture, mais nous r�alisons alors qu'il est n�cessaire d'avoir des r�gles plus complexes et pr�cises pour contourner l'absence de d�sambigu�sation et le fait que beaucoup de mots ont plus d'une �tiquette.

D'autres exemples sur ce probl�me

Les autres r�gles aussi entra�nent beaucoup de mauvaises d�tections d'erreurs, dues � l'ambigu�t� verbe-nom le plus souvent.
Par exemple :
La visite a dur� longtemps             est corrig� :     La visite � dur� longtemps            car le tag "verbe" de visite correspond � la r�gle.
Il se trompe toujours de num�ro    est corrig� :     Il ce trompe toujours de num�ro    car le tag "nom" de trompe correspond � la r�gle.
Tu peux utiliser ce t�l�phone         est corrig� :     Tu peux utiliser se t�l�phone        � cause du tag "verbe" de t�l�phone qui correspond � la r�gle.
Ces lignes ne sont pas droites        est corrig� :     Ces lignes ne son pas droites        car pas a le tag "nom" qui entraine l'application de la r�gle.
Il a publi� son livre                        est corrig� :     Il a publi� sont livre                    car le tag "verbe" de livre correspond � la r�gle.

Cr�ation de nouvelles r�gles

Nous avons aussi tent� de cr�er des r�gles nouvelles pour nous confronter aux probl�mes d'�criture de r�gles d'erreur.

La n�gation

Nous avons �crit une r�gle pour la d�tection d'erreur sur la n�gation, qui permet de d�tecter l'omission de la particule ne dans une phrase n�gative avec pas ou jamais.
Si dans une phrase un verbe n'est pas pr�c�d� de ne ou n', mais qu'il est suivi de pas ou jamais (eux-m�mes non pr�c�d�s d'un d�terminant pour �viter la confusion avec le nom pas), avec une suite quelconque de mots entre le verbe et pas, alors une faute est d�tect�e.

M�me si la r�gle fonctionne relativement bien, nous nous rendons compte l� encore qu'il est n�cessaire de contourner l'absence de d�sambigu�sation par des r�gles plus compliqu�es.

L'accord d�terminant-nom

Nous avons voulu faire une r�gle pour l'accord entre un d�terminant et un nom qui d�tecterait une erreur dans le cas o� un nom masculin singulier ne serait pas pr�c�d� d'un d�terminant autre que masculin singulier. Mais nous avons eu un souci avec l'expression r�guli�re qui n'a jamais voulu fonctionner...

Cependant, cela nous a quand m�me permis de prendre conscience du tr�s grand nombre de r�gles qu'il est n�cessaire de r�diger pour couvrir le plus de cas possibles. Dans son m�moire, Myriam avait calcul� le nombre de combinaisons possibles d�terminant, adjectif, nom et d�terminant, nom, adjectif. �tant donn� que chacune de ces cat�gories peut avoir trois genres (masculin, f�minin, �pic�ne) et trois nombres (singulier, pluriel, invariable), on obtient 1458 combinaisons possibles, donc presque autant de r�gles � r�diger (il faut enlever les combinaisons correctes puisque les r�gles d�crivent des erreurs).
Il y a bien s�r moyen de cr�er un programme qui g�n�re ces r�gles automatiquement, mais c'est un nombre tout de m�me tr�s important et qui correspond au traitement d'une petite partie de la syntaxe seulement. On voit donc que la liste de r�gles � cr�er peut vite devenir consid�rable, sans jamais pouvoir �tre exhaustive, car il n'est pas possible de pr�voir toutes les erreurs qui peuvent �tre commises dans un texte.

Conclusion

En conclusion de ces petits tests, nous pouvons dire que le principal probl�me que nous avons rencontr� est celui de l'absence de d�sambigu�sation, que nous allons essayer de combler. Nous allons par ailleurs modifier la m�thode actuelle de d�tection des fautes, qui n�cessite trop de r�gles, afin qu'elle soit plus adapt�e � la grammaire fran�aise.

Pr�sentation de LanguageTool

LanguageTool est un correcteur libre de style et de grammaire, d�velopp� initialement pour l'anglais par Daniel Naber et adapt� par la suite � d'autres langues comme l'allemand, le hongrois ou encore le polonais.

Il �tait � l'origine programm� en python mais a �t� enti�rement r��crit en java (pour un meilleur support du format XML utilis� notamment pour les fichiers de r�gles d'erreurs, comme nous allons le voir pas la suite).

Il est compos� de plusieurs modules qui effectuent successivement :

la segmentation du texte � v�rifier en phrases
la segmentation des phrases en mots
l'�tiquetage morpho-syntaxique des mots : les mots ambigus re�oivent plusieurs �tiquettes correspondant aux diverses cat�gories morpho-syntaxiques auxquelles ils peuvent appartenir ainsi qu'aux diff�rents traits qu'ils peuvent avoir dans une cat�gorie, et ils les conservent toutes car aucune d�sambigu�sation n'est effectu�e. Ainsi b�te aura les �tiquettes <nom f�minin singulier>, <adjectif masculin singulier> et <adjectif f�minin singulier>.
la d�tection des erreurs de grammaire : elle s'effectue par comparaison de chaque segment de phrase avec une base de r�gles d�crivant des erreurs. Si un segment correspond � une r�gle, alors une erreur est d�tect�e.

Les r�gles d'erreurs sont formalis�es en XML et sont compos�es de plusieurs �l�ments :

id et name : respectivement l'identifiant et le nom de la r�gle
pattern : mod�le de l'erreur
message : description de la r�gle � l'usage de l'utilisateur
example : exemple d'�nonc� correspondant � la faute commise. Il y a en g�n�ral au moins deux exemples : un exemple d'�nonc� correct et un exemple d'�nonc� incorrect.

L'�l�ment pattern est le plus important. C'est lui qui d�crit le mod�le de l'erreur et avec lui que les phrases sont compar�es lors de la d�tection. Le mod�le se pr�sente g�n�ralement sous la forme d'expression(s) r�guli�re(s).

Voici un exemple de r�gle en fran�ais :

<rule name="ma (m'a)" id="MA">
   <pattern mark_to="-1">
       <token>ma</token>
       <token postag="V.*" postag_regexp="yes"/>
   </pattern>
   <message>Voulez vous �crire<suggestion>m'a</suggestion>?</message>
   <example type="incorrect">Il <marker>ma</marker>r�pondu.</example>
   <example type="correct">Il <marker>m'a</marker>r�pondu.</example>
</rule>

Cette r�gle d�tecte une confusion dans l'utilisation des homophones m'a et ma. Si le texte � v�rifier contient ma suivi d'un verbe (V), suivi de n'importe quel mot (.*), alors il y a une erreur.

Fonctionnement d'un correcteur grammatical

Avant de d�crire la structure de LanguageTool, nous pouvons commencer par expliquer le fonctionnement des correcteurs grammaticaux de mani�re g�n�rale.

Le texte � v�rifier est d'abord d�coup� en phrases, puis les phrases en mots. C'est la tokenisation.

Vient ensuite la phase d'�tiquetage morpho-syntaxique (ou tagging). Chaque mot se voit attribuer une ou plusieurs �tiquettes (tags) contenant des informations telles que la cat�gorie morpho-syntaxique (verbe, nom, adjectif, pronom, etc), ainsi que le genre et le nombre (pour les noms, les adjectifs...), le temps, le mode, la personne, etc... pour les verbes.

Lors du tagging, les tr�s nombreux mots ambigus re�oivent plusieurs tags. Une d�sambigu�sation est n�cessaire pour limiter le nombre d'�tiquettes de chaque mot et am�liorer par la suite la d�tection de fautes de grammaire.
Certains correcteurs utilisent une m�thode probabiliste pour d�sambigu�ser les mots. Ils n�cessitent un corpus d'apprentissage sans erreurs et �tiquet� avec les informations morpho-syntaxiques. Ils calculent alors la probabilit� que tel mot ait tel tag plut�t qu'un autre, ou encore la probabilit� qu'un mot ait un certain tag en fonction des tags des mots qui l'entourent. Lors du tagging, ces probabilit�s sont appliqu�es aux mots du texte � analyser et chaque mot re�oit alors le tag qui correspond � la plus forte probabilit�.
Cette m�thode est contraignante dans la mesure o� la d�tection des fautes est tr�s d�pendante du corpus ayant servi � l'apprentissage. Par ailleurs, le corpus �tiquet� n�cessaire doit �tre le plus grand possible. Il n'en existe pas forc�ment de disponible ou de convenable, et la constitution d'un tel corpus est tr�s co�teuse.
Une autre m�thode consiste � utiliser des r�gles manuelles de d�sambigu�sation sous forme d'expressions r�guli�res, bas�es sur le contexte imm�diat. Cette m�thode est plus contr�lable que la m�thode statistique, mais elle n�cessite des r�gles descriptives qui doivent �tre suffisamment nombreuses pour couvrir le plus de cas possibles, des r�gles qui sont r�dig�es manuellement et donc longues � produire, et qui ne peuvent par ailleurs pas �tre exhaustives.
Certains correcteurs combinent les 2 m�thodes, d'autres ne font pas de d�sambigu�sation.

Une fois l'�tiquetage termin�, commence alors l'�tape de d�tection des erreurs. Il existe l� encore deux mani�res de proc�der.
Certains correcteurs utilisent des r�gles prescriptives et d'autres des r�gles d'erreurs. Les premiers comparent donc le texte avec une liste de formes correctes. Dans le cas o� ils ne trouvent pas de correspondance, ils d�tectent une erreur. Les seconds, au contraire, comparent le texte avec des r�gles d�crivant des erreurs. S'il y a correspondance, c'est qu'il y a une faute.
Dans les deux cas, plus il y a de r�gles, meilleure sera la d�tection. Mais il est impossible de pr�voir et donc de d�crire toutes les erreurs possibles. Il y aura donc potentiellement toujours des erreurs non d�crites dans les r�gles, non d�tectables par le correcteur, et donc beaucoup de silence.
Les r�gles de grammaire sont moins nombreuses mais tout de m�me difficiles � r�diger de mani�re exhaustive, et tout ce qui ne correspond pas � une r�gle �tant consid�r� comme une faute, il peut y avoir beaucoup de bruit, c'est-�-dire beaucoup de d�tections d'erreurs qui n'en sont pas.

R�sum� du travail de Myriam Lechelt

Je vais ici faire un r�sum� rapide de l'important travail effectu� par Myriam Lechelt sur le projet de correcteur grammatical dont je prends la suite.

Dans le cadre de son m�moire de DEA, Myriam a donc initi� un travail dont l'objectif est, � terme, de cr�er un outil de correction grammaticale libre pouvant �tre int�gr� � OpenOffice.org. Plut�t que de chercher � r�aliser enti�rement un nouvel outil, elle a r�alis� une analyse de plusieurs correcteurs grammaticaux libres d�j� existants, afin de d�terminer lequel serait le plus adaptable au fran�ais.

Parmi les correcteurs analys�s (GRAC , LanguageTool et An Gramadoir), c'est Gramadoir qui a �t� retenu pour �tre adapt� au fran�ais. Son adaptation s'est traduite par la d�finition d'un jeu d'�tiquettes pour l'�tiquetage morpho-syntaxique des mots ( tagging), par l'�criture de r�gles de d�sambigu�sation pour la phase du tagging, puis par la cr�ation de quelques r�gles pour la d�tection des fautes.

L'adaptation de Gramadoir au fran�ais n'a pas �t� achev�e, et malgr� des r�sultats plut�t satisfaisants lors des premiers tests, l'outil a montr� des limites pour le traitement du fran�ais.

Une approche alternative a finalement �t� propos�e, dans l'�ventualit� de la conception d'un nouveau correcteur. Elle consiste � introduire un niveau interm�diaire entre le mot et la phrase, le chunk (ou syntagme), lors de la segmentation des phrases et � utiliser le principe de l'unification de structures de traits au niveau de la v�rification grammaticale. Nous reviendrons ult�rieurement sur les notions de chunk et d'unification.

Les travaux de Myriam ayant montr� que le traitement du fran�ais par Gramadoir restera limit�, nous n'allons pas continuer � exploiter ce syst�me. Nous avons d�cid� par ailleurs de ne pas non plus concevoir un correcteur enti�rement nouveau. Nous allons plut�t r�aliser une adaptation de la derni�re version de LanguageTool. En effet, il y a eu beaucoup d'�volutions entre l'ancienne version rejet�e � l'�poque, et la nouvelle, qui semble mieux adaptable au fran�ais. Nous allons la compl�ter en suivant les pistes donn�es par Myriam pour la conception d'un nouveau correcteur.

Correcteur grammatical... la suite

Je suis �tudiante en 2�me ann�e de Master recherche Industries de la langue. Mon m�moire de recherche s'inscrit dans le prolongement du travail initi� par Myriam Lechelt en 2005, � savoir le projet de d�veloppement d'un correcteur grammatical libre pouvant �tre int�gr� � la suite OpenOffice.org.

Le travail effectu� par Myriam a permis de montrer les limites des outils Gramadoir (http://borel.slu.edu/gramadoir/) de Kevin Scannell et LanguageTool (http://www.danielnaber.de/languagetool/) de Daniel Naber pour leur adaptation � la correction grammaticale du fran�ais.
LanguageTool a entre temps beaucoup �volu� et la nouvelle version semble plus adaptable au fran�ais que ne l'�taient l'ancienne version et Gramadoir.

Mon travail va donc consister

� reprendre le travail de Myriam Lechelt, notamment sur les r�gles d'erreurs � compl�ter
� �tudier la nouvelle version de LanguageTool et lui apporter les modifications n�cessaires � une meilleure adaptation � la grammaire fran�aise,
dans le but d'obtenir un outil g�n�rique et libre adapt� au fran�ais et pouvant �tre int�gr� � OpenOffice.org ou � d'autres projets.

J'ai par ailleurs effectu� un stage au sein de la soci�t� Nuxeo-InDesko durant l'�t� 2006. L'objectif �tait la cr�ation d'un outil d'extraction automatique d'affixes � partir d'une liste de mots, afin de pouvoir g�n�rer automatiquement, pour toute langue, un fichier d'affixes et un dictionnaire compatibles avec le correcteur orthographique d'OpenOffice.org. Les fichiers actuels sont construits manuellement et tr�s co�teux � produire.
http://w3.u-grenoble3.fr/lebarbe/agnes/index.php