OK
AJAX error!

Les forumsDictionnaireSegmentation (“tokenization”) sur l’apostrophe

Segmentation (“tokenization”) sur l’apostrophe

C'est sur l'invitation d'Olivier R. cf www.dicollecte.org… que je me permet d'ouvrir ce sujet.

Le traitement actuel de l'apostrophe dans le dictionnaire français dicollecte fonctionne parfaitement. Un tout petit détail permettra d'introduire la discussion avec une fonctionnalité qui peut intéresser tout le monde. Imaginons que vous aimiez le verbe ascagasser (qui n'a pas de raison d'être dans le dictionnaire dicollecte). Faîtes l'expérience vous-même sur la ligne ci dessous, ajoutez le verbe à votre dictionnaire personnel

Ça ascagasse... je l'ascagasse... il m'ascagasse...

il vous faudra ajouter non seulement “ascagasse”, mais aussi “l'ascagasse”, “m'ascagasse” (avec toutes les élisions). Ce comportement résulte de choix passés complètement justifiables, mais peut-être révisables désormais. Il faudrait pouvoir expliquer à hunspell qu'en français, l'apostrophe sépare parfois les mots “l'amour”, mais pas toujours “aujourd'hui”. Et bien ce programme est diablement bien fait, puisqu’après tests, il le permet. Il faut lui dire à peu près ceci


WORDCHARS ' # l'apostrophe peut être un caractère dans un mot
BREAK ' # l'apostrophe peut aussi couper un mot


Merci à Olivier (Admin?) pour le tuyau. Dans l'ordre le programme commence par chercher si “aujourd'hui” est au dictionnaire, et sinon, il regarde “aujourd” et “hui”. Cela permettrait aussi, dans l'interface dicollecte, que le “fléchisseur” www.dicollecte.org… n'affiche plus


n'aimer ne+ infi
qu'aimer que+ infi
d'aimer de+ infi
l'aimer le|la+ infi
m'aimer me+ infi
t'aimer te+ infi
s'aimer se+ infi


L'adoption d'une telle règle pourrait largement simplifier le fichier actuel d'affixes, avec cependant les risques que comportent toujours ces sortes de réformes (gros recherche/remplace).

PS : Mes motivations personnelles ne sont pas de pure esthétique. Je développe actuellement un programme (java) pour utiliser les lexiques hunspell/OOo dans des moteurs de recherche (un peu comme Google, chercher “journal” trouve aussi “journaux”). Passé la joie d'un premier prototype qui marche, je constate des pratiques très variables d'hunspell selon les langues.
le 25 novembre 2010 à 12:38
Pour voir qui je suis, il suffit de cliquer sur mon pseudo. ;)

J’ai renommé le fil, mais je ne suis pas sûr que «tokenization» soit le terme vraiment adéquat.

Le mieux, pour évaluer cette proposition, c’est encore de concevoir un prototype. Pour ça, je vais vous envoyer une version plus claire des fichiers et vous laisser faire.

Alors, voici ce qu’il y a à faire :

— supprimer les drapeaux a1 a2 a3 a4 a5, à remplacer par a0 dans le dictionnaire ;
— supprimer les drapeaux b1 b2 b3 b4 b5, à remplacer par b0 dans le dictionnaire ;
— supprimer les drapeaux c1 c2 c3 c4 c5, à remplacer par c0 dans le dictionnaire ;
— supprimer les drapeaux d1 d2 d3 d4 d5, à remplacer par d0 dans le dictionnaire ;
— supprimer les drapeaux f1 f2 f3 f4 f5, à remplacer par f0 dans le dictionnaire ;
— supprimer les drapeaux i1 i2, à remplacer par i0 dans le dictionnaire ;
— supprimer les drapeaux n' q' d' j' c' l' m' t' s', à effacer dans le dico et dans le fichier des affixes ;
— supprimer les drapeaux S* F* W* A* I* ;
— dans le dictionnaire, remplacer S*() par S., X* par X., A*() par A., I*() par I., F*() par F.(), W*() par W.() ;
— supprimer les drapeaux L' D' Q' Q* Qj Si, dans le fichier des affixes comme dans le dictionnaire ;
— il y a probablement encore quelques drapeaux doublons dans les verbes du 3e groupe : éliminer et regrouper.

Commandes dans le fichier des affixes :

WORDCHARS -'’

BREAK 3
BREAK -
BREAK '
BREAK ’

COMPOUNDMIN 1

Ensuite, il faut créer les drapeaux pour COMPOUNDBEGIN, COMPOUNDLAST, COMPOUNDMIDDLE et les apposer sur les entrées adéquates.
Par exemple :

COMPOUNDBEGIN (=
COMPOUNDMIDDLE ++
COMPOUNDLAST =)

Je vous laisse bidouiller avec les autres commandes, je n’ai pas trop le temps de m’occuper de ça.

Tenez-nous au courant ! :)
le 25 novembre 2010 à 20:11
Me voilà dedans jusqu'au cou, avec un départ difficile. Désolé d'être un œil extérieur dans ton travail. Quel est ton environnement de test, les “stress-textes” ? En hunspell direct, une première règle semble utile :

ICONV ‘ ' # convertir les apostrophes courbes en entrée, le dictionnaire est en apostrophes droites

Sans autres modifications, les règles WORDCHARS, BREAK et COMPOUNDMIN fonctionnent déjà. Autrement dit, s'il y a des oublis, ils n'ont pas l'air de bloquer quelque chose. Effet, sur “m'ascagasse”, la suggestion n'est pas très pertinente (“Madagascar”), mais comme prévu, ajouter “ascagasse” suffit.

Je ne comprend pas l'usage de la règle NEEDAFFIX (). Je la supposais pour des faux mots qui servent de support à des affixes, afin de ne pas faire des fautes d'orthographe, même s'ils sont dans le fichier *.dic. Il y a je suppose de l’historique, des contournements ?

Ces recherche/remplace massifs ont toujours leurs risques. Je me suis aperçu un temps trop tard que j'avais fait sauté les apostrophes dans le dictionnaire (ex : aujourd‘hui, d’emblée). La reprise manuelle m'a permis de mieux prendre contact avec ce lexique. Impressionnant, quel boulot. Je crois n'avoir vu qu'une seule règle qui était dans F* mais pas F., pour ouzbèke.

Avec les étiquettes, la ressource est d'excellente qualité ! C'est parfait pour nous, mais pour dicollecte ? Ici les fichiers après les opérations décrites plus haut :
developpements.enc.sorbonne.fr… developpements.enc.sorbonne.fr…

Pas encore de règles
COMPOUNDBEGIN (=
COMPOUNDMIDDLE ++
COMPOUNDLAST =)
Le but est d'éviter les erreurs de type “mots'justes''accrocchés'avec'des'apostrophes” ?
le 01 décembre 2010 à 00:38

Quel est ton environnement de test, les “stress-textes” ?


En fait, je n’ai quasiment jamais de problèmes. Globalement, j’utilise tout simplement OOo en éditant le fichier directement ou en le générant par script. Mais je n’ai que rarement des soucis sur ce point. Tout roule bien depuis 2 ans. Sinon, j’utilise aussi Hunspell en ligne de commande, mais c’est surtout pour vérifier des détails.

ICONV ‘ ' # convertir les apostrophes courbes en entrée, le dictionnaire est en apostrophes droites


En fait, OOo le fait tout seul. Mais si je te comprends bien, tu utilises Hunspell comme dépendance avec ton propre logiciel, c’est ça ?
Ce n’est pas mon cas sur ce site, je génère les morphologies avec du PHP. Le fichier des affixes est dans la base de données.

Je ne comprend pas l'usage de la règle NEEDAFFIX (). Je la supposais pour des faux mots qui servent de support à des affixes, afin de ne pas faire des fautes d'orthographe, même s'ils sont dans le fichier *.dic. Il y a je suppose de l’historique, des contournements ?


Je ne comprends pas totalement la question. Le drapeau NEEDAFFIX, c’est comme ouvrir un répertoire et exclure ce répertoire (qui porte le nom du lemme) des formes générées. Par exemple, je vois que tu as ôté le drapeau () des formes avec F*. C’est une erreur. Si tu analyses le mot ennemie, tu auras deux résultats :
ennemie po:nom
ennemie po:nom is:fem

Le premier résultat, c’est celui du lemme qui ne porte pas le tag fem.

Impressionnant, quel boulot.


Après des années dessus, il faut bien que ça commence à avoir de la gueule. ;)

Je crois n'avoir vu qu'une seule règle qui était dans F* mais pas F., pour ouzbèke.


Ah oui, je crois n’avoir pas forcément répliqué toutes les règles sur les drapeaux équivalents, histoire de ne pas charger la bête inutilement.

Le but est d'éviter les erreurs de type “mots'justes''accrocchés'avec'des'apostrophes” ?


Oui, éviter les combinaisons absurdes.
le 01 décembre 2010 à 01:39
Je n'utilise pas hunspell dans mon programme, du coup je risque les méprises sur les commandes. Ici, pour travailler sur le dictionnaire français, j'essaie de me donner un environnement dans l'esprit du dossier tests/ des sources de hunspell, pour diminuer le risque d’erreurs.

Si tu analyses le mot ennemie



Avec la commande analyze ? Je prend le réflexe. Pour la stricte correction orthographique, le drapeau NEEDAFFIX ne me semble pas nécessaire en français, sauf si quelqu'un avait par exemple fait le choix de prendre le radical des verbes comme entrée dans le fichier dic, pour simplifier les affixes (ex : aim/v1, SFX v1 0 er . is:infi, SFX v1 0 er . is:infi ; “aim” n'est pas un mot français). Par contre NEEDAFFIX augmente en effet la qualité linguistique de la ressource ! (ce qui ne peut que m'intéresser)

tu as ôté le drapeau () des formes avec F*



Je ne crois pas l'avoir fait volontairement, il faut faire son lot de boulettes avant de savoir contribuer intelligemment. J'ai trouvé ces seules lignes dans fr-moderne.aff où F. et F* n'est pas suivi de ().
libéralisante/F. po:adj
louvoyante/F. po:adj

éviter les combinaisons absurdes



L'utilisation de COMPOUNDBEGIN semble demander à semer des COMPOUNDFLAG sur tous les mots susceptibles d'être précédés d'un clitique, ce qui revient (presque) à la situation précédente. Après tests, les COMPOUNDRULE aussi.

Il me semble que pour l'utilisateur, ne pas remarquer des erreurs improbables comme “appeau’strophe” , “l’consonne” ou “jusqu’on” ; c'est un inconvénient mineur relativement à ce qu'apporte des règles plus simples à maintenir, et donc plus sûres.

Je dois me munir d'un “stress-texte” plus complet. Le dictionnaire avait déjà “l”, ou “j”, mais pas encore “quoiqu”. À bientôt pour une correction de ce post quand les fichiers corrigés seront en ligne.

le 01 décembre 2010 à 12:50

Avec la commande analyze ?


NEEDAFFIX élague les informations inutiles/incomplètes, lorsqu’on demande une analyse morphologique d’un mot.

Pour la stricte correction orthographique, le drapeau NEEDAFFIX ne me semble pas nécessaire en français


Effectivement.

Par contre NEEDAFFIX augmente en effet la qualité linguistique de la ressource !


C’est le but recherché pour le dico français.

J'ai trouvé ces seules lignes dans fr-moderne.aff où F. et F* n'est pas suivi de ().
libéralisante/F. po:adj
louvoyante/F. po:adj


Ah oui, merci, ce sont des erreurs.

Il me semble que pour l'utilisateur, ne pas remarquer des erreurs improbables comme “appeau’strophe” , “l’consonne” ou “jusqu’on” ; c'est un inconvénient mineur relativement à ce qu'apporte des règles plus simples à maintenir, et donc plus sûres.


Les règles ne sont pas dures à maintenir, elles l’ont juste été à écrire. Il est certain qu’il y a nombre de combinaisons absurdes faciles à voir, mais ce n’est pas le cas de toutes, pour les verbes, les h aspirés, etc.

S’il y a un avantage qui me fera adopter peut-être ce système, c’est le moindre coût en ressources lors de la recherche des graphies correctes.
le 01 décembre 2010 à 19:04
Test de performances.
Temps : sur une boucle x1000, commande hunspell sur un texte très court, mesure surtout le temps de chargement du dictionnaire, -17% pour BREAK sur apostrophe.
Mémoire : hunspell ligne de commande bloqué sur une faute, fr-moderne : 10,5Mo, fra : 9,6Mo.
Sensible, mais sans changement d'ordre de grandeur.

Considérer les clitiques comme des parties de mots composés est en fait une très mauvaise idée qui casse l'analyse linguistique. S'il y a une optimisation à trouver, ce n'est pas celle-ci.

Au fait, est-ce que les fichiers fr-moderne sont testés en hunspell ligne de commande (pour les linuxiens) ? J'ai l'impression qu'ils ne fonctionnent pas bien sur par exemple : “quoiqu’alors”, “qu'il” (mais pas de problème sur “l'arbre”, “s'endormir”).

Autre point, il serait utile d’ajouter les clitiques au dictionnaire, voir par exemple hunspell avec l'option « -m analyze the words of the input text » :
l’amour
l st:l po:nom is:mas is:inv
amour st:amour po:nom is:mas
le 02 décembre 2010 à 17:39
Effectivement, Hunspell en-ligne ne semble pas se comporter comme dans OOo, puisque dans le premier cas, l’apostrophe est considérée comme séparateur, alors que je ne spécifie rien de tel.

Considérer les clitiques comme des parties de mots composés est en fait une très mauvaise idée qui casse l'analyse linguistique. S'il y a une optimisation à trouver, ce n'est pas celle-ci.


N’exagérons pas. L’analyse d’un mot avec clitique renvoie la présence de celui-ci (dans le champ dp:).
Ex: www.dicollecte.org…

De toute façon, si je dois considérer l’apostrophe comme séparateur, ce ne sera pas pour le dictionnaire 4.0. Je ne vais pas tout changer peu de temps avant une publication, ça demande réflexion et prudence. Quoi qu’il en soit, les premiers tests avec le correcteur grammatical m’indiquent qu’il faut que je revoie certains aspects du système d’affixation. Mais je n’ai pas beaucoup de temps en ce moment pour ça.

Quoi qu’il en soit, je vous précise tout de même que ma priorité, c’est OpenOffice.org et la correction grammaticale pour ce logiciel, et que, si des choix doivent être faits, ce sera en fonction de ça en premier lieu. Si cela satisfait ceux qui veulent reprendre ce que nous faisons, tant mieux, sinon tant pis, il leur faudra adapter les dictionnaires à leurs besoins ou se baser sur les ressources plus adaptées, me semble-t-il, aux recherches académiques. Navré pour ce rappel un peu froid, mais je ne voudrais pas entretenir des espérances infondées ou vous tromper.
le 03 décembre 2010 à 09:50

ma priorité, c’est OpenOffice.org et la correction grammaticale pour ce logiciel



Le meilleur service pour le plus grand nombre, cela semble la meilleure règle pour conduire un projet libre. Dès lors que cette règle est comprise et respectée, est-ce nécessaire d'opposer un “nous” à “recherche académiques” ? Ne serait-ce pas le même problème avec “ingénieur pris dans l’urgence de son projet pour son client” ? Il me semble qu’un “fork” est toujours un échec qui éparpille les contributions et l'expertise. Saluons plutôt que le français a jusqu’ici réussi à se satisfaire d'un dictionnaire, contrairement à tous les “anglais” dont les dates de publication (AU:2008, CA:2002, GB:2006, NZ:2002, US:2006, ZA:2006) montrent surtout un très inégal dynamisme.

Si mon message n'était pas clair, je reformule autrement. La situation actuelle, avec les clitiques comme affixes, me semble pour l'instant la moins mauvaise solution. Le gain de performance ne paraît pas décisif. La proposition « BREAK ' », qui fait l'objet de ce fil, aboutit à ce que hunspell considère “l'arbre” comme un seul mot composé, ce qui risque de gêner l'exploitation grammaticale. Je n‘ai pas trouvé (existe-t'elle ?) la commande hunspell qui règlerait ce problème. Les segmenteurs pour le français (académiques, certes, mais avec déjà 20 ans d'expérience…) normalisent généralement “l'arbre” en “le arbre” avant d’étiqueter, afin de garder la succession “article singulier suivi de nom”, utile pour par exemple débusquer une faute de syntaxe comme “l'ardent petits buissons”. Souhaitons que le français puisse obtenir une solution d'hunspell, ou bien qu’un des dictionnaires anglais s'intéressent à la grammaire, et ne se satisfasse plus de solutions orthographiques où l'on trouve “isn't” dans le fichier dic.

Effectivement, Hunspell en-ligne ne semble pas se comporter comme dans OOo



Mauvais environnement de test, mais si par hasard quelqu’un avait une explication, ce serait pratique.
le 04 décembre 2010 à 15:48

Dès lors que cette règle est comprise et respectée, est-ce nécessaire d'opposer un “nous” à “recherche académiques” ? Ne serait-ce pas le même problème avec “ingénieur pris dans l’urgence de son projet pour son client” ?


Mon dessein n’est pas d’opposer. Je voulais seulement être explicite sur mes priorités. Du reste, comme je l’ai dit, pour l’instant, je ne suis ni pour ni contre l’apostrophe comme séparateur. ;)

La proposition « BREAK ' », qui fait l'objet de ce fil, aboutit à ce que hunspell considère “l'arbre” comme un seul mot composé, ce qui risque de gêner l'exploitation grammaticale. Je n‘ai pas trouvé (existe-t'elle ?) la commande hunspell qui réglerait ce problème.


Tu veux dire l’inverse, «BREAK '» sépare l’arbre en deux mots.

l’environnement de test ?


Il y a quelques mois, j’avais écrit une extension en Python qui analysait la morphologie des mots: cf. user.services.openoffice.org… (le menu déroulant). Mais cette extension ne fonctionne plus. J’ai ensuite modifié quelque chose, et plus rien n’a fonctionné, et je n’ai pas réussi à trouver où est le problème. Il faut dire que le débogage sous OOo/Python est extrêmement pénible, puisqu’on ne reçoit aucun message d’erreur. Je n’ai pas eu le temps de m’y recoller depuis lors.
Par contre, le bout de code en Basic, que tu trouveras dans ce même fil, devrait fonctionner. Il suffit d’associer la méthode avec un bouton, par exemple.

Maintenant, je peux faire des tests avec Grammalecte.
Mais ce n’est pas très commode. Là, il a fallu que je dise spécifiquement d’analyser «l’action» et de me renvoyer le résultat. Ça peut quand même servir.
le 04 décembre 2010 à 19:45
Bon, j’ai finalement réussi à refaire fonctionner cette saloperie d’extension :
dicollecte.free.fr…
(Programmée à l’arrache avec du code un peu bordélique, mais ça marche.)

Si tu installes ça avec le dictionnaire 4.0, l’extension, avec un clic droit sur un mot, te renvoie l’analyse morphologique.
(Il faut relancer OOo après l’installation.)

Allez, je vais bouquiner.
le 04 décembre 2010 à 23:51

cette saloperie d’extension



Super ! Ça marche parfaitement. Je me suis permis d'aller dans le code, pour comprendre ce qui se passait. Il s'agit d'un équivalent de la commande hunspell -m (analyze) ?
xHunspell.spell(u"%s" % word, xLocale, ())
Cela permet en tous cas de voir le comportement dans le logiciel cible.

Tu veux dire l’inverse, «BREAK '» sépare l’arbre en deux mots.



Je dois certainement m'emmêler, mais prenons un exemple concret. Dans la phrase : « Comment vas-tu ? », quand je clique droit sur “vas-tu”, l'analyse ne me donne rien, contrairement à “vas” ou à “tu” (remarque : analysé comme participe passé de taire). C'est pour cette raison que j'interprète la commande « BREAK - » (de la V4) comme un séparateur de mots composés. Si pour le dictionnaire orthographique, cela consiste à séparer la chaîne en deux mots à vérifier dans le dictionnaire, pour l'analyse grammaticale, j'ai l'impression que “vas-tu” est considéré comme un seul mot. Pour que le segmenteur coupe bien “vas” et “tu” sur le ‘-’ il faut supprimer la commande « WORDCHARS - », mais du coup, cela casse la correction orthographique des mots composés (qui sont coupés avant d'être testés contre le dictionnaire). Le problème relevé sur l'apostrophe pourrait donc aussi concerner le trait d'union.
le 06 décembre 2010 à 09:06
La ligne

xHunspell.spell(u"%s" % word, xLocale, ())


renvoie une analyse grâce à la commande passée sous forme de XML.

Mais attention, la tokenization sous OOo n’est pas celle de Hunspell. OOo tokenize, puis envoie les bouts à Hunspell (qui lui-même peut scinder encore si les commandes BREAK le lui demandent). Mais BREAK ne sert que pour la vérification orthographique de mots composés (il faudrait peut-être demander à ce que ce soit pris en compte pour la commande analyze).

Par ailleurs, dans l’extension, je ne me sers pas du tokenizer d’OOo, je me contente de chercher le mot sous le curseur et l’aller chercher ses limites avec des fonctions basiques (cf. getWord), puis de le renvoyer dans la commande ci-dessus. En fait, ici, Hunspell ne te renvoie rien de plus que ce qu’il fait avec la ligne de commande. vas-tu ne renvoie rien non plus avec Hunspell en-ligne.

Il n’agit donc ici aucunement du comportement du correcteur grammatical. Ce n’est qu’un petit outil perso. Il faudrait améliorer la fonction getWord, et scinder les mots avec tirets qui ne renvoient aucun résultat. :)

Le problème relevé sur l'apostrophe pourrait donc aussi concerner le trait d'union.


D’une certaine manière, oui. Il y a beaucoup de mots composés en français, mais aussi beaucoup de jointures typographiques. Par exemple:
— ces mots-là,
— les formes impératives : donne-moi ça ! donne-le-moi !
— les interrogations : voulez-vous ?
etc.
le 06 décembre 2010 à 09:54
[…]

Par contre, je suis gêné par l'intitulé « Derivational (suffix ou prefix) », cela me semble un abus pour un article comme “l'”, et surtout, cela limite un développement très prometteur, l'analyse dérivationnelle à laquelle invite la documentation Hunspell.

[…]

Exemple, “dérivationnel” n'est pas au dictionnaire, bien que cela semble une construction assez convenable en français, ce genre de néologie pourrait être factorisée avec une règle assez féconde en français. La documentation donne l'exemple suivant

analyze(dérivationnel) = st:dérivation po:nom is:fem ds:el po:adj

[…]

On se demande alors où est configuré ce tokenizer, et comment il interroge le dictionnaire hunspell. Je m'y perd un peu.

[…]

EDIT de Admin: Mille excuses, j’ai édité votre texte au lieu de le citer. J’ai replacé ce qu’il reste de votre message, mais le reste est perdu. Désolé.
le 06 décembre 2010 à 13:47

Par contre, je suis gêné par l'intitulé « Derivational (suffix ou prefix) », cela me semble un abus pour un article comme “l'”, et surtout, cela limite un développement très prometteur, l'analyse dérivationnelle à laquelle invite la documentation Hunspell.


Ce n’est pas faux, mais, en fait, je m’en foutais un peu. Il fallait bien que je mette ça quelque part. C’eût été mieux placé en préfixes «inflexionnels» peut-être ? Si ce n’est que ça, ça se corrige aisément.
(Un exemple utile de gérer les formes élidées par l’orthographe. Hunspell m’a signalé «ç’eût» comme une erreur. Très commode…)

Exemple, “dérivationnel” n'est pas au dictionnaire, bien que cela semble une construction assez convenable en français, ce genre de néologie pourrait être factorisée avec une règle assez féconde en français. La documentation donne l'exemple suivant

analyze(dérivationnel) = st:dérivation po:nom is:fem ds:el po:adj


Il y a une très grosse limite sur ce point. C’est que la forme fléchie ne perd pas l’étiquette POS (po:) du lemme. Je ne sais plus qui m’avait proposé de générer les adverbes à partir des adjectifs. J’ai refusé, parce que c’est loin d’être simple de faire quelque chose de cohérent, et que de surcroît les adverbes auraient été aussi étiquetés comme adjectifs, ce qui ne convient pas du tout.

Ensuite, on va me faire (encore) un procès su je me mets à générer des néologismes de la sorte en rafales. :)

On se demande alors où est configuré ce tokenizer, et comment il interroge le dictionnaire hunspell. Je m'y perd un peu.


Le rôle de Hunspell n’a jamais été de faire tokenizer. Myspell ne faisait que de la correction orthographique et ne tokenizait pas du tout, que je sache. C’était le rôle d’OOo. Puis Hunspell a remplacé Myspell, amenant avec lui de nouvelles possibilités. Je pense que la FSF hongroise a promu Hunspell parce que Myspell était trop limité pour le hongrois (Hunspell = Hungarian spellchecker), et c’est là que de nouvelles possibilités sont survenues, pour gérer aussi des tas de langues complexes.

Quant au fonctionnement du tokenizer, il faut demander sur la mailing-list lingu-dev, car ça dépasse mes connaissances.
le 06 décembre 2010 à 19:10
Je lis pas ailleurs vos urgences sur la V4, mes remarques seront tout à fait accessoires, je les note juste pour ne pas les oublier.

fonctionnement du tokenizer OOo



Je me demande si OOo n'utilise pas d'abord les règles d'“hyphénation” avant de soumettre un “token” à hunspell. Peu m'importe, c'est juste pour prévoir la différence entre OOo et hunspell ligne de commande.

générer les adverbes à partir des adjectifs



Personnellement cela m'irait (“m'irait”, tiens ? pourquoi une faute ici ?). À l'heure informatique, je suis agacé par ces entrées de dictionnaire qui n'ouvrent que sur des sorties (ex: diplocéphale « Qui est affecté de diplocéphalie. » francois.gannaz.free.fr…).

on va me faire (encore) un procès su je me mets à générer des néologismes



Tans qu'il n'y a pas de règle pour faire accepter “changeage”, je pourrais vivre avec “cautionnel” (qui n'est pas dans dicollecte).

la forme dérivée ne perd pas l’étiquette POS (po:) du stem



Vu que le modèle est promu par hunspell, j'imagine que la chaîne d'exploitation grammaticale saura s'en débrouiller, par exemple en prenant le dernier champ po. En tous cas c'est une règle importante de la dérivation, elle peut changer la nature d'un mot. Ce phénomène négligé dans nos langues est la règles dans d'autres. La racine arabe ou hébreu génère aussi bien des verbes que des noms. Pour ces langues, hunspell ne doit pas être pratique, car il ne s'agit pas d'affixes mais de voyelles intercalaires. Bientôt la généralisation d‘arspell ?

Probablement hors dicollecte, il y a des intérêts scientifiques et économiques pour un dictionnaire dérivationnel libre du français. Des ressources existent en partie, l'intérêt serait de diminuer grandement le nombre de stems en mémoire lors de l'analyse (ex : plus besoin d'adverbes), et surtout, de pouvoir facilement élargir une recherche aux dérivés (quelqu'un qui cherche le mot “constitution” peut être intéressé par l'adjectif “constitutionnel”). Hunspell supporte en partie la fonctionnalité :

SET UTF-8
SFX A Y 1
SFX A er tion/B uer po:nom
SFX B Y 1
SFX B 0 nel/C ion po:adj
SFX C Y 1
SFX C 0 lement nel po:adv # invisible

1
constituer/A

echo "constituer constitution constitutionnel constitutionnellement " | hunspell -m -d test
constituer st:constituer
constitution st:constituer po:nom
constitutionnel st:constituer po:nom po:adj
constitutionnellement

Il s'agirait alors d'un vrai “stemmer”. Reste la limitation “twofold” (le drapeau /C dans SFX B n'est pas suivi). J'ai tenté l'expérience de programmer un explorateur récursif des drapeaux pour conserver l'élégance d'une même règle de dérivation adverbiale pour “constitutionnel” et “réel”, il faut se garder des boucles infinies, j'ai compris pourquoi hunspell se limitait à 2. En informatique, 2 n'est pas toujours synonyme de plusieurs.

En résumé, hunspell comme stemmer est pensé pour non seulement l'affixation des flexions, mais aussi de la dérivation (moins pour l'apostrophe ou le tiret de liaison). Par contre, concevoir un dictionnaire qui pourrait satisfaire la correction orthographique aussi bine que la “racinisation” (stemisation) est une autre affaire.
le 08 décembre 2010 à 23:56

Je me demande si OOo n'utilise pas d'abord les règles d'“hyphénation” avant de soumettre un “token” à hunspell.


Non. Le tokenizer et le "césureur" sont deux modules différents.

(“m'irait”, tiens ? pourquoi une faute ici ?)


Un oubli de ma part dans le système d'affixation. Je viens de corriger.

la forme dérivée ne perd pas l’étiquette POS (po:) du stem


Vu que le modèle est promu par hunspell, j'imagine que la chaîne d'exploitation grammaticale saura s'en débrouiller, par exemple en prenant le dernier champ po.


Non, rien n'est prévu pour. Il faudrait le programmer dans le correcteur grammatical lui-même. Il faut comprendre qu'OOo ne fournit qu'une interface pour la correction grammaticale, un système qui permet de récupérer le texte, de dire où souligner et quel message afficher. C'est le correcteur grammatical (l'extension) qui interroge Hunspell, ou pas (LanguageTool dispose de son propre lexique et ne demande rien à Hunspell). Autrement dit, il faudrait alourdir l'analyse grammaticale elle-même pour trouver la bonne étiquette du mot dérivé, si on passe par Hunspell.

Avec un tel système, il vaudrait mieux créer les dérivés d'un mot à partir d'un lemme virtuel (c'est-à-dire que le correcteur ortho ne considérerait pas comme correct, cf. la commande NEEDAFFIX) sans étiquette grammaticale. Par exemple, on peut créer le lemme "virtuel" dérive, à partir duquel des drapeaux engendrerait dérive (à nouveau), dérivation, dérivationnel, dériver, etc., flexions qui ne posséderaient que leur propre étiquette grammaticale.

En tous cas c'est une règle importante de la dérivation, elle peut changer la nature d'un mot.


C'est pour ça que ça peut gêner la correction grammaticale. Si je demande ce qu'est le mot dérivassiez, je veux juste savoir que la racine, c'est dériver et qu'il s'agit d'un verbe. Je ne veux pas savoir que ça vient du mot dérive, nom féminin.

Par contre, concevoir un dictionnaire qui pourrait satisfaire la correction orthographique aussi bine que la “racinisation” (stemisation) est une autre affaire.


Oui. Par ailleurs, on ne peut choisir dans Hunspell que la double suffixation ou la double préfixation, pas les deux, ce qui posera peut-être problème pour créer certains mots préfixés.
Enfin, générer tous les formes fléchies dans une arborescence complexe ne peut qu'alourdir le processus de recherche de l'existence d'un mot et surtout d'une graphie correcte.

Ceci dit, au moment de créer le fichier des affixes actuel, ce qui a prévalu, c'est la simplicité d'usage pour la maintenance du dictionnaire. Auparavant, dans l'ancien système Myspell, il y avait des drapeaux pour la préfixation, permettant d'ajouter des préfixes comme anti-, contre-, dé-, in-, etc. Il fallait aussi plusieurs entrées pour gérer les verbes et les élisions. Ça compliquait énormément l'affaire. Il y avait des doublons, des mots erronés, on avait du mal à s'y retrouver, c'était un casse-tête sans fin. Il n'y a pas si longtemps, nous trouvions encore pas mal de débris de cette époque. Par exemple, on a effacé le mot déscolarité, il y a un mois ou deux.

En te lisant, je ne peux m'empêcher de penser : c'est bien beau tout ça, mais qui va le faire et comment (ça va demander probablement pas mal de temps et de travail), et une fois que c'est fait, qui va gérer ça ? Déjà, le système actuel, grandement simplifié par rapport à avant, n'est pas des plus limpides pour le néophyte qui débarque, il faut un minimum d'investissement à se documenter sur ce site, du temps pour comprendre et du temps connaître nos usages. Bref, ce n'est pas donné à tout le monde de participer. Mais si ton système est commode pour des études académiques sur la lemmatisation, l'est-il pour ceux qui voudront améliorer le système? S'il ne l'est pas, il risque de rester plutôt figé, faute de gens capables et désireux de s'investir dedans.
Actuellement, les choses te paraissent certainement globalement assez simples et claires, mais tu es informaticien, ce qui n'est pas le cas de tous ceux qui ont passé du temps à améliorer le dictionnaire. De même, tu arrives à un moment où le dictionnaire commence à être globalement propre, pas trop mal organisé, assez complet, sans trop d'erreurs. C'est encore très perfectible, certes, mais tu n'imagines probablement pas d'où nous venons. Il y 3-4 ans, le dictionnaire était bouffi d'erreurs, très lacunaire, ne disposait d'aucun étiquetage grammatical ou lexical, il y avait plusieurs versions qui se contredisaient, c'était un bordel difficile à imaginer, etc. Il avait d'ailleurs très mauvaise réputation, et les utilisateurs s'en plaignaient. Bref, si nous en sommes là aujourd'hui, c'est parce qu'il existe un système de mise à jour unifié (pour les différentes versions) et à peu près intelligible pour les gens qui prennent la peine de s'investir un peu. Bref, la très, très grande force de Dicollecte, c'est son évolutivité (OK, c'est peut-être la seule). Sans cela, qu'aurions-nous?
Certes, Dieu sait que le système lui-même est encore grandement perfectible et qu'il y a encore beaucoup à faire. Nous n'avons pas encore un lexique aussi parfait que Morphalou, Leff ou Lexique.org, et notre manière de faire n'est pas très académique (il y a des choses dont on se moque), mais il faut voir d'où on vient, le temps et l'effort qu'il a fallu pour arriver là, et quel est notre dessein. Finalement, peu à peu, nous comblons notre retard sur nos pairs, et peut-être ne sommes-nous pas trop loin de les égaler?

Autrement dit, la maintenabilité du dictionnaire est une fonctionnalité très importante à mes yeux, car celui qui fait seul son truc dans son coin ne réalise pas, au commencement, le nombre de détails infinis à régler, la minutie des choses à faire et tous les cas particuliers à gérer. Les informaticiens ont tendance à penser qu'on peut régler beaucoup de choses avec quelques scripts, et ne mesurent pas l'ampleur de la tâche et sa complexité. Certes, maintenant qu'il n'y plus guère qu'à se pencher pour ramasser le fruit, peut-être que ce que tu proposes peut se régler aisément par script – il faudrait essayer –, mais si ce n'est pas le cas, je crains que tu ne produises un beau dictionnaire, certes intéressant sur certains aspects, mais difficile à faire évoluer.

Pour en revenir à la tokenization sur l'apostrophe, on peut dire que celle-ci simplifierait assez la gestion du dictionnaire, mais au prix d'avoir à gérer la complexité des élisions autrement. Le gain ici vaut-il la perte ailleurs ? Je l'ignore encore, je n'ai pas le temps pour l'instant de me pencher sur cette affaire.
le 09 décembre 2010 à 13:39
Merci beaucoup pour ta réflexion générale sur dicollecte, elle est précieuse.

celui qui fait seul son truc dans son coin



La situation dans la recherche publique mène à tirer des conclusions analogues. Beaucoup de chercheurs sont précaires, les financements sont collectifs mais transitoires, enfin les curiosités changent. On aimerait ne pas être toute sa vie chargé de son algorithme, son programme, son corpus ou son lexique, sans en passer par un montage institutionnel pour qu'un projet ne meure pas. L'idéal, ce serait qu'une thèse ou une recherche puisse toujours profiter à la collectivité en enrichissant un projet libre. Personnellement, je ne suis pas dans un individualisme de pure théorie, j'ai toujours en vue l'application pratique et les performances. J'ai travaillé en entreprise, j'ai à cœur que les étudiants trouvent un travail, le logiciel libre peut être une bonne école.

peut-être ne sommes-nous pas trop loin de les égaler?



Vous avez à mes yeux une différence très intéressante, les formes sont générées par lemmes et règles d'affixes. Si un mot manque, il suffit d'ajouter son lemme avec un modèle de flexion :
Personal dictionaries are simple word lists […] A second word separated by a slash sets the affixation.
Foo/Simpson
La valeur de la ressource augmentera avec le perfectionnement des règles d'affixes. Une série de scripts Perl pour conjuguer les verbes français, c'est bien, mais des règles hunspell, c'est beaucoup plus indépendant des langages et des implémentations.
Sur l'étendue du lexique, Morphalou est limité au TLF, on n'y trouve pas pourriel. Lexique.org ne prétend pas non plus couvrir tous les mots.

[dictionnaire dérivationnel] c'est bien beau tout ça, mais qui va le faire et comment



Depuis peu, lexique.org à ajouter une colonne de dérivation (obtenue par un programme), avec par exemple “anti-constituer-ion-el”. Cela permet déjà d'obtenir un stemmer un peu brutal, mais évidemment, fonder la correction orthographique sur la reconstruction d'un arbre serait très imprudent.
le 13 décembre 2010 à 01:15

On aimerait ne pas être toute sa vie chargé de son algorithme, son programme, son corpus ou son lexique, sans en passer par un montage institutionnel pour qu'un projet ne meure pas. L'idéal, ce serait qu'une thèse ou une recherche puisse toujours profiter à la collectivité en enrichissant un projet libre.


Oui, enfin, il y a libre et libre. L’une des raisons pour lesquelles je n’ai pas pu récupérer les données de Morphalou ou de Lexique.org, c’est que les licences n’étaient pas assez permissives. Du coup, je me suis attelé à l’étiquetage grammatical par mes propres moyens. Notre dictionnaire devait avoir une licence très permissive pour être inclus dans OOo, Firefox, etc.

Vous avez à mes yeux une différence très intéressante, les formes sont générées par lemmes et règles d'affixes. Si un mot manque, il suffit d'ajouter son lemme avec un modèle de flexion.


Oui, c’est le choix que j’ai fait lorsque j’ai décidé de tout réécrire: mettre toute la complexité dans le fichier d’affixation, afin que la maintenabilité du dictionnaire soit la plus simple possible. Dans Myspell, il fallait 5 lemmes pour les verbes réguliers et, pour les irréguliers, il fallait mettre toutes les formes fléchies en vrac.

L’autre possibilité, qu’on m’avait enjoint de suivre, c’était d’enregistrer toutes les formes fléchies depuis les lexiques existants, puis de compresser le tout avec un script qui génère automatiquement les drapeaux. Cf. le script munch dans Hunspell. Mais comme j’étais seul sur le coup, je n’en ai fait qu’à ma tête. ;)
le 15 décembre 2010 à 17:19

Notification par e-mail    0