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...

Le quotidien Le Monde a récemment fait paraître une interview du “Debian Project Leader”, Samuel Hocevar. La lecture de cette interview m’a passablement agacé, car d’une part elle propage à mon sens un certain nombre d’idées reçues sur le libre (“logiciels d’informaticiens pour informaticiens”) plutôt que d’en faire la promotion auprès d’un public assez large, et d’autre part elle s’attache plus à faire la promotion de Wikipedia que du logiciel libre.

Plutôt que de critiquer point par point les réponses de Samuel aux questions du journalistes, j’ai préféré refaire mes propres réponses à ces même questions.

Que pensez-vous du succès grandissant des logiciels Firefox ou OpenOffice ?

Le navigateur web Firefox et la suite bureautique OpenOffice.org partagent un certain nombre de caractéristiques qui expliquent leur succès actuel, auprès du grand public et de certaines administrations ou entreprises:

• Ce sont des logiciels qui répondent aux deux principaux besoins génériques des utilisateurs d’informatique: l’accès au Web et la bureautique.

• Ce sont des logiciels multi-plateformes: ils tournent à la fois sous Windows (qui reste la plateforme dominante du marché), sous Mac OS et sous Linux.

• Ce sont des projets matures: Firefox est issu de la base de code du navigateur Netscape développée dans les années 90, OpenOffice.org de la suite StarOffice dont le développement a démarré en 1994.

• De plus, il s’agit de projets qui disposent d’une force de travail importante, constituée en partie de personnel d’acteurs majeurs de l’informatique (IBM, Google, Sun, Novell…) qui ont un intérêt stratégique à contrer l’hégémonie de Microsoft sur le poste de travail.

• Il y a un lien très fort entre ces deux logiciels et les standards ouverts sous-jacents: les standards du Web pour Firefox, le standard ISO Open Document Format pour OpenOffice.org. La lutte de lobbying intense à laquelle Microsoft se livre depuis plus d’un an pour faire normaliser son propre standard “Open XML” auprès de l’ISO (en dépit du bon sens: pourquoi créer une deuxième norme alors qu’il en existe déjà une?) et selon des méthodes peu consensuelles montre l’importance stratégique des standards dans l’informatique actuelle.

Il faut noter cependant une différence importante: le principal concurrent de Firefox est Internet Explorer (et, dans une moindre mesure, sur plateformes Mac OS, Safari) qui est intégré comme navigateur par défaut dans les systèmes Windows de Microsoft, donc vu comme gratuit par les utilisateurs, alors qu’OpenOffice.org se positionne principalement face à la suite Office de Microsoft, qui est onéreuse:

• Pour arriver à convaincre une proportion significative d’utilisateurs d’installer Firefox plutôt que le navigateur par défaut, les développeurs de Mozilla doivent se différencier par la qualité et les fonctionnalités de leur produit. Ainsi, face à Microsoft qui, une fois qu’il a cru avoir gagné la “guerre des navigateurs” face à Netscape au début des années 2000, a cessé toute innovation sur son navigateur, Mozilla a introduit des dizaines d’innovations comme par exemple la navigation par onglets ou les bloqueurs de popups, innovations plébiscitées par les utilisateurs à tel point que Microsoft a été obligé de les copier dans IE 7.

• Dans le cas d’OpenOffice.org, la différenciation se fait le plus souvent par le prix: la suite Office 2007 de Microsoft coûte, typiquement pour une PME, de 500 à 950 euros par poste, ce qui est du même ordre de grandeur que le prix d’un ordinateur bureautique d’entrée voire de milieu de gamme. C’est un coût important qui rend tentante l’offre gratuite d’OpenOffice.org.

Justement, comment voyez-vous l’avenir des logiciels libres grand public ?

Le succès de logiciels comme Firefox, OpenOffice.org ou VLC (logiciel de lecture vidéo lui aussi multi-plateformes) montrent que des logiciels clefs, qui peuvent représenter jusqu’à 80 ou 90% de l’utilisation quotidienne de l’informatique par un grand nombre d’utilisateurs, peuvent être des logiciels libres.

Ce succès d’un petit nombre de logiciels généralistes, et d’une “longue traîne” de logiciels plus spécialisés, sur des plateformes comme Windows et Mac OS, permet d’éduquer le grand public sur l’existence et la qualité des logiciels libres, et peut en amener un certain nombre à vouloir également s’intéresser à Linux en tant que système d’exploitation pour postes de travail. Les principaux éditeurs de systèmes d’exploitations basés sur Linux - Red Hat, Novell, Mandriva, Ubuntu - constatent actuellement une demande du grand public, et de la grande distribution, sur ce secteur, et plusieurs indices, dont le “flop” du lancement de Vista, laissent à penser que 2008 sera l’année du décollage de Linux auprès d’une partie du grand public.

Signalons par ailleurs un autre facteur de diffusion des logiciels libre: le logiciels embarqués dans du matériel spécialisé. En France, la Freebox, la NeufBox et de nombreuses autres “appliances” intègrent déja depuis plusieurs années un noyau Linux et de nombreux logiciels libres. Dans les pays émergents, des initiatives comme le One Laptop Per Child sont également une façon de diffuser des logiciels libres auprès de millions d’utisateurs, qui ne connaissent pas Windows et qui sont donc vierges de tout a priori.

De plus en plus d’entreprises privées et d’administrations passent aux logiciels libres, désormais considérés comme des “concurrents” par Microsoft. Existe-t-il encore des freins à leur généralisation ?

Dans le domaine des logiciels d’entreprises, la donne est très différentes: il n’y a pas un seul acteur qui domine outrageusement le marché, mais plusieurs acteurs dominants: Microsoft certes, mais aussi SAP, IBM, Oracle, EMC, etc.

Sur ce secteur, et principalement dans le domaine des logiciels serveurs, d’abord au niveau des logiciels d’infrastructure (communication, bases de données, monitoring, etc.) et progressivement au niveau des logiciels applicatifs (CRM, ERP, GED, ECM, etc.) les logiciels libre se sont dans certains cas déja imposés (ex: Apache) et dans la plupart des autres, connaissent une progression rapide.

Un frein notable à cette progression est l’ensemble des pratiques anti-concurrentielles de Microsoft, dénoncées par l’ensemble de l’industrie, et qui lui ont valu de très nombreux procès et un certain nombre de condamnations.

A part cela, il est plus approprié de parler d’inertie que de freins, car il s’agit de faire changer les mentalités des décisionnaires, de former les informaticiens de terrain, et de remplacer des investissements qui s’amortissent sur de 5 à 10 ans.

Une chose est claire pour toute le monde cependant: le logiciel libre a changé la façon dont les logiciels sont développés par les éditeurs. Ceux-ci se reposent de plus en plus (31% en 2006, probablement plus de 50% en 2007 ou 2008) sur des “briques” logicielles libres, mais aussi “ouvrent” de plus en plus leur modèles de développement. D’ici 5 ans, je suis certain que la plupart des éditeurs de logiciels d’entreprises auront intégré, d’une façon ou d’une autre, une partie des méthodes du libre dans leurs développement.

Comment voyez-vous l’évolution de la distribution de contenus culturels ?

On est dans un cas d’école d’innovation disruptive, selon le modèle de Clayton Christensen:

• Les anciens acteurs dominants, les “majors”, s’accrochent à leur ancien modèle à présent obsolète et militent pour des législation drastiques dans ce domaine.

• Une partie du public à trop rapidement adopté les pratiques d’échange en pair à pair ou sur des sites de mise en ligne de contenus, sans intégrer les limites légales et morales de leurs pratiques: échanger des contenus libre et contribuer de manière communautaire à leur développement, c’est bien; échanger des contenus soumis à des restrictions d’usage en dehors du droit à la copie privée, c’est mal.

• Les pouvoir publics, faute d’une vision claire sur ce dossier, et sous l’influence des lobbies du passé, ont voté des lois très dures (DADVSI) visant à maintenir le statu quo.

• Un petit nombre d’acteurs, à commencer par Apple, a saisi au moment opportun la rupture technologique et s’en est servi pour reconfigurer la chaîne de valeur de la diffusion des contenus autour de leur offre de produits (ex: l’iPod) et de services (ex: iTunes), réalisant ainsi le “hold-up du siècle” sur l’industrie musicale, et bientôt sur l’industrie cinématographique.

A mon sens, l’un des rôle majeurs d’un projet comme Wikipedia, qui montre la force mais aussi les limites du modèle de développement coopératif, est d’éduquer le public sur ces questions de production communautaire de contenu et sur les questions de droits d’usage des contenus, de montrer qu’il y a plusieurs modèles possibles, chacun avec ses forces, ses faiblesses et ses tabous, et qu’il est important de les connaître pour se comporter de manière citoyenne.

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...

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

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 :

1. les erreurs qui sont déjà détectées par les règles actuelles ("je ne doit pas être...")
2. les erreurs pour lesquelles nous pensons pouvoir créer des règles avec le formalisme actuel de LanguageTool ("on désir...")
3. les erreurs qui pourront être détectées avec un nouveau formalisme utilisant les chunks et l'unification ("le monde m'appartenais...")
4. 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.

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.

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.

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.

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.

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.