OK
AJAX error!

Les forumsTribune libreCorpus historiques et phonétisation

Corpus historiques et phonétisation

Je réponds avec un peu de délai, pour une raison un peu hors du sujet de ce fil, mais qui justifie mon intérêt pour le format hunspell ducange.enc.sorbonne.fr… Retrouver les “bons hommes” (Boni Homines, Bonorum hominum…) dans un dictionnaire de latin médiéval. Avec la V4, je vais essayer dans les semaines à venir de faire la même chose sur un corpus de français du XVIe (en orthographe originale elec.enc.sorbonne.fr…). Sans toucher au dictionnaire et aux affixes, il s'agirait de jouer sur les règles de suggestion pour que “avoit” corresponde à “avait>avoir”.

Je note avec intérêt l'idée de compacter les définitions de drapeaux. Je suis dans un contexte applicatif où la mémoire a aussi un coût (j'ai rencontré un retard de développement parce que les dictionnaires étaient répliqués pour différents corpus). Je vais donc implémenter les commandes AF dès que je peux.

Ceci ne retire pas, à l'avenir, l'intérêt d'un export de dicollecte-fr en clair, du moins si cela ne coûte pas trop dans les scripts.
le 30 novembre 2010 à 10:05

Sans toucher au dictionnaire et aux affixes, il s'agirait de jouer sur les règles de suggestion pour que “avoit” corresponde à “avait>avoir”.


REP oit ait
REP ait oit

Ceci ne retire pas, à l'avenir, l'intérêt d'un export de dicollecte-fr en clair, du moins si cela ne coûte pas trop dans les scripts.


Il faudra me le demander, si besoin, c’est une option que je donne avant de lancer l’usine à gaz qui génère tout.
le 01 décembre 2010 à 01:51


REP oit ait
REP ait oit



Pour l'instant je n'ai pas implémenté les règles REP, elles me semblent très coûteuses. Soit par exemple la forme “açassein”. Retrouver “assassin” demande à tester toute la combinatoire “assassein”, “assaçein”, “açaçein”, “assaçin”... C'est improbable pour des textes actuels, pas pour des textes plus anciens. La logique PHONE (ou du moins ce que j'en comprends) me semble beaucoup plus rapide. Avec des règles du genre ss > s, ç > s, ein > i, “assassin” et “açassein” sont tous deux ramenés à “asasin” (mauvaise graphie mais bonne clé pour rapprocher les formes). J'ai tenté d'attirer l'expertise de Németh László sur mon problème, je serais heureux que quelqu'un de plus persuasif sache en obtenir une opinion (PHONE or REP ?).

le 01 décembre 2010 à 14:04
Je me trompe peut-être, mais je pense que REP est la commande la plus rapide/efficace, puisque les REP sont les règles prioritaires qui ne sont appliquées que sur un seul niveau de recherche. Le problème, c’est que ce n’est fonctionnel que si le mot ne contient qu’une seule erreur. Si REP ne permet pas de trouver une forme correcte, l’usine à gaz démarre, et Hunspell ne tient plus compte de REP. Si je souviens bien, les règles MAP sont très coûteuses.
Quant à PHONE, je n’ai jamais rien lu ou expérimenté à ce sujet, mais à mon avis, c’est du lourd, très lourd, parce qu’il faut rechercher des correspondances en modifiant toutes les formes fléchies. Si j’ai bien compris, Aspell, d’où vient l’algorithme, compilait les résultats et les stockait. J’ignore si Hunspell le fait.
le 01 décembre 2010 à 14:13
Merci pour ces confirmations. Pour le corpus XVIe indiqué ci-dessus, 5500 formes différentes, 3050 ne sont pas reconnues par le dictionnaire du français actuel, mais les mots ont des équivalents quasi exacts (ex : “paciffication”). Il serait bête de produire un pseudo dictionnaire du XVIe, alors qu'il ne s'agit que de conventions orthographiques différentes, variables selon les transcriptions, et automatisables en grande partie. Dans les hautes fréquences, on trouve : nostre, noz, ilz, ceulx, estre, esté, roy, ny, faict, tres, edict, present, subjectz, aprés… L'approche REP (pour une seule erreur) est certainement raisonnable pour un correcteur orthographique, mais pour un stemeur, elle sera vite mise en défaut. Il faudrait au moins la coupler avec une désaccentuation. Les permutations MAP me semblent coûteuses en temps. La clé phonétique me semble ce qu'il y a de mieux en temps, à condition de ne pas tout perdre en mémoire. Dans l'implémentation que j'en ai, je ne stocke pas toutes les formes (600 000 pour le français, 2 millions pour le latin, et en hongrois ? et en allemand ? infini ?), je ne vérifie que les lemmes du fichier dic. Resteraient quelques problèmes, en partie solubles avec une table d'affixes phonétisés (ex : avoient, subjectz). Les dernière difficultés se situent dans les règles à la jonction du lemme et de l'affixe, en scannant une liste de fréquence, je ne vois pas où cela peut arriver. Suite de la discussion sur ton fil PHONE (que je dois encore implémenter).
le 02 décembre 2010 à 12:55
J’ai charcuté le fil, parce que je déteste quand les discussions partent dans tous les sens. :)
Il y a plus de liberté en Tribune libre.
le 02 décembre 2010 à 13:35
Ce fil pourrait être renommé « corpus historiques et phonétisation ». Le problème est spécifique, mais bien étudié, si bien qu'il peut permettre de tirer des enseignements pour une correction automatisée plus fiable de l’orthographe. Par contre, j'en arrive (avec grand regret), à la conclusion que ces explorations ne peuvent pas directement entrer dans une distribution hunspell pour OOo.

Sur le corpus des “édits de pacification” (elec.enc.sorbonne.fr… qui mettent fin aux guerres de religion), 3050 formes ne sont pas bien “orthographiées” selon dicollecte-fr. Avec une trentaine de règles, il en reste ~1000, sans toucher au dictionnaire de lemmes et aux affixes. Quant à la syntaxe PHONE proposée par Hunspell, elle relève les bons besoins, mais elle est pénible à implémenter, et surtout, à écrire. Qui a encore l'œil pour ces automates du siècle dernier ? Les expressions régulières sont devenues l'espéranto du traitement de caractères, voir par exemple sur wikipedia fr.wikipedia.org… Restait un mécanisme à siginifier, le besoin que le résultat d’une règle ne soit pas affecté par les suivantes. J'ai obtenu ce résultat en jouant avec la casse, en mettant en minuscules ce qui sort de ces règles.

PHONEKEY 28
PHONEKEY ngno NNA # congnoissance
PHONEKEY ng$ N # ung
PHONEKEY estre ÊTRE # estre
PHONEKEY ^est ÉT # estoient
PHONEKEY oient$ AIENT # AIENT, protégé contre ai e
PHONEKEY oit$ AIT # AIT, protégé contre ai e
PHONEKEY ois$ AIS # AIS, protégé contre ai e
PHONEKEY ([bcdeflpt])\1 $1 # quelques lettres doubles, eedict
PHONEKEY [ïîy] i # roy, païs
PHONEKEY ([aeiou])s([bcdfgjklmnpqrtvwxz]) $1$2 # nostre, feste, chasteau, aoust
PHONEKEY [éèê] e # tres, aprés, reformée
PHONEKEY ect et # effect, mectre, secrectz
PHONEKEY ict it # faict, edict
PHONEKEY eulx EUX # ceulx
PHONEKEY [çz] s # ilz
PHONEKEY c([ei]) s$1 # receu
PHONEKEY eu u # pourveu, seureté
PHONEKEY â a # grace
PHONEKEY aul au # generaulx
PHONEKEY b([vzsj]) $1 # doibvent, subjectz
PHONEKEY lt t # communaultez, oultre
PHONEKEY nct nt # poinct, contrainctz
PHONEKEY ens$ ent # presens
PHONEKEY ans$ ant # lieutenans
PHONEKEY cq$ c # publicq
PHONEKEY ph f # protéger les ph
PHONEKEY ch CH # protéger les ch
PHONEKEY h 0 # supprimer les h

Implémenter une phonétisation est simple sur toutes les formes fléchies d'une langue, mais beaucoup plus subtil quand lemmes et affixes sont séparés, surtout sur les mots les moins réguliers (avec du strip). Exemple : “pourroient”. Avec les règles oient > aient, et rr > r, cela devient “pouraient”. Retirer l'affixe “aient” ne permet pas de retrouver “pouvoir” (même si pouvoir est dans une table phonétisée). Je ne suis pas encore sûr d'avoir trouver le bon réglage.

le 05 décembre 2010 à 15:53

Notification par e-mail    0