Moi, je ne le comprends pas comme ça. Je comprends qu'il ne faut pas supprimer le logo Onlyoffice pour y mettre le tien. Rien ne t'interdit de changer le code pour faire l'interface que tu veux (y compris, déplacer ou supprimer le champ contenant le logo), du moment que tu ne t'appropries pas la marque et que tu laisses, quelque part dans ton interface (même dans une boite "à propos") le logo original d'Onlyoffice.
C'est de AGPL3, une sorte de GPL qui t'oblige à garder la source, un peu comme Flowplayer, Pydio etc… Après, on s'habitue vite à des licenses sans aucune contrepartie, mais vue l'ampleur du travail réalisé, je trouve juste de leur accorder un minimum de respect/hommage.
Tu dis: "Le correcteur ne sait pas où chercher une conjugaison adéquate. Pour parfaire le système de suggestion, il faudrait établir des passerelles entre tous les mots grammaticalement distincts sur leurs liens phonétiques éventuels."
Il me semble qu'il existe dans les entrées du dictionnaire un représentation phonétique de chaque mot (sinon, ces dictionnaires existent en opensource, par exemple chez eSpeak pour la synthèse vocale, LLIUM pour la reconnaissance vocale, etc…).
Du coup, en ajoutant une n-ième passe au préprocesseur (lors de la détection d'une erreur), qui aurait pour entrée l'index des mots en "phonétique" qui, par définition est un mapping 1:n, pourrait lors d'un mot incongru (Il s'en "fou"), chercher si un des résultats pour l'entrée phonétique "fu" pourrait convenir. Dans ce cas aussi simple, il trouverait immédiatement le verbe conjugué, et n'aurait plus qu'à choisir la bonne conjugaison parmi "fous, fout".
Après, avec un TernarySearchTree indexé sur les clés phonétiques, on pourrait même envisager une recherche approximative (type Levenshtein, distance de Hamming) pour trouver des mots dont la phonétique est "proche" de l'item erroné - Cela ne donnerait pas de faux positif puisque ceci démarrerait uniquement sur détection d'une erreur, tel qu'actuellement. On est alors clairement dans l'aide à l'utilisateur, au lieu de détecter une erreur et de ne pas savoir quoi suggérer, on pourrait envisager un menu "Ils son faux." => "son" est erroné, vouliez vous dire "sont", "sonnent" etc…
Concernant "Il est aller à la mairie", je pense qu'une dernière passe de pre-processing utilisant la technique des n-gram, (c'est à dire la découpe en entités de 3/4 lettres), puis comparaison avec un modèle statistique du langage (tel que fournis par Google en opensource), repèrerait l'incongruité statistique de la suite "est aller". C'est ce que fait Google pour ses suggestions de correction de recherche. Il faut définir des seuils (donc risque de faux positifs) quitte à laisser le seuil à 0 par défaut et laisser les utilisateurs aventureux à monter le seuil.
[^] # Re: Licence intéressante
Posté par xryl669 . En réponse à la dépêche Publication des éditeurs de documents en ligne de OnlyOffice. Évalué à 3.
Moi, je ne le comprends pas comme ça. Je comprends qu'il ne faut pas supprimer le logo Onlyoffice pour y mettre le tien. Rien ne t'interdit de changer le code pour faire l'interface que tu veux (y compris, déplacer ou supprimer le champ contenant le logo), du moment que tu ne t'appropries pas la marque et que tu laisses, quelque part dans ton interface (même dans une boite "à propos") le logo original d'Onlyoffice.
C'est de AGPL3, une sorte de GPL qui t'oblige à garder la source, un peu comme Flowplayer, Pydio etc… Après, on s'habitue vite à des licenses sans aucune contrepartie, mais vue l'ampleur du travail réalisé, je trouve juste de leur accorder un minimum de respect/hommage.
# Recherche par index phonetique
Posté par xryl669 . En réponse à la dépêche Grammalecte, correcteur grammatical. Évalué à 5. Dernière modification le 22 avril 2015 à 14:17.
Tu dis: "Le correcteur ne sait pas où chercher une conjugaison adéquate. Pour parfaire le système de suggestion, il faudrait établir des passerelles entre tous les mots grammaticalement distincts sur leurs liens phonétiques éventuels."
Il me semble qu'il existe dans les entrées du dictionnaire un représentation phonétique de chaque mot (sinon, ces dictionnaires existent en opensource, par exemple chez eSpeak pour la synthèse vocale, LLIUM pour la reconnaissance vocale, etc…).
Du coup, en ajoutant une n-ième passe au préprocesseur (lors de la détection d'une erreur), qui aurait pour entrée l'index des mots en "phonétique" qui, par définition est un mapping 1:n, pourrait lors d'un mot incongru (Il s'en "fou"), chercher si un des résultats pour l'entrée phonétique "fu" pourrait convenir. Dans ce cas aussi simple, il trouverait immédiatement le verbe conjugué, et n'aurait plus qu'à choisir la bonne conjugaison parmi "fous, fout".
Après, avec un TernarySearchTree indexé sur les clés phonétiques, on pourrait même envisager une recherche approximative (type Levenshtein, distance de Hamming) pour trouver des mots dont la phonétique est "proche" de l'item erroné - Cela ne donnerait pas de faux positif puisque ceci démarrerait uniquement sur détection d'une erreur, tel qu'actuellement. On est alors clairement dans l'aide à l'utilisateur, au lieu de détecter une erreur et de ne pas savoir quoi suggérer, on pourrait envisager un menu "Ils son faux." => "son" est erroné, vouliez vous dire "sont", "sonnent" etc…
Concernant "Il est aller à la mairie", je pense qu'une dernière passe de pre-processing utilisant la technique des n-gram, (c'est à dire la découpe en entités de 3/4 lettres), puis comparaison avec un modèle statistique du langage (tel que fournis par Google en opensource), repèrerait l'incongruité statistique de la suite "est aller". C'est ce que fait Google pour ses suggestions de correction de recherche. Il faut définir des seuils (donc risque de faux positifs) quitte à laisser le seuil à 0 par défaut et laisser les utilisateurs aventureux à monter le seuil.