• Aucun résultat trouvé

Chapitre 7 Faciliter la mise à jour des ressources

7.2 Un accès unique et global aux ressources lexicales

7.2.4 Fonctionnalités et interface

La conception de l‘interface et de ses fonctionnalités sont le fruit de notre collaboration avec le stagiaire que nous avons encadré pendant trois. Nous ne présentons que brièvement les fonctionnalités de l‘interface. Plus de détails peuvent être trouvés dans le rapport de stage [Guerra, 2006] qui contient le compte rendu, le manuel de l‘interface et une API complète en pseudo-code. Cet API est constituée d‘une soixantaine de pages et décrit toutes les opérations possibles sur la base de données.

L‘interface permet trois types d‘interactions entre l‘utilisateur et la base de connaissances lexicales (LKB) : la consultation, l‘exportation et la validation. Ces interactions sont illustrées dans la figure 56.

Figure 56 : Interactions avec l'utilisateur

a. Fonctions de consultation

Une fenêtre permet à l‘utilisateur de spécifier les critères de filtrage. Les filtres peuvent être mono- ou multicritères et sont listés dans la figure 57. Le filtre se transforme alors en requête SQL qu‘il est possible de visualiser et de modifier dans une fenêtre d‘édition libre.

LKB Interface client exportation consultation lexique validation automate lexique

169

Figure 57 : Fenêtre d'édition de filtre : on requête le lemme manger comme verbe.

L‘affichage des résultats est proche de la visualisation de l‘éditeur de texte mais gagne en clarté puisqu‘il est structuré : il y a des colonnes différentes pour le mot-forme, le lemme et les différents types d‘informations. La figure 58 montre le résultat de la requête illustrée en figure 57 qui sélectionne le lemme manger et le restreint au verbe. L‘interface prévoit un champ de recherche qui s‘exécute sur toutes les informations affichées, ce qui permet de retrouver toutes les entrées correspondant à la requête. Sur la copie d‘écran de la figure 58 la requête est mangeait.

Si on garde le pointeur de la souris sur les colonnes Etiquettes et Descripteurs, une fenêtre surgissante montre la documentation associée aux codes utilisés. Une copie d‘écran dans l‘Annexe E (figure 87) illustre cet affichage pour les informations sémantiques (colonne « Descripteurs ») du mot avocat. Cette même copie d‘écran affiche son équivalent féminin avocate qui lui est associé avec une relation See Also dans la colonne « Associations ».

170

Figure 58 : Fenêtre des résultats

Avec un minimum de connaissances en SQL, l‘extraction d‘un ensemble de mots répondant à plusieurs contraintes devient un jeu d‘enfant alors qu‘en comparaison l‘écriture d‘un script aurait été relativement longue. Il est ainsi possible d‘écrire un filtre pour extraire tous les mots qui sont codés uniquement au singulier ou ceux uniquement au pluriel. Si ce codage est justifié dans un nombre restreint de cas, ils peuvent aussi être indicateurs d‘un manque ou d‘une erreur.

Les filtres ne doivent pas forcément être compliqués pour être utiles. Ainsi, la sélection de toutes les formes d‘un même lemme est une fonctionnalité précieuse qui demandait auparavant de jongler avec un script et des fichiers de sortie.

b. Fonction d’exportation

Une fenêtre permet de sélectionner les informations et de les mettre en forme selon les souhaits de l‘utilisateur. Une copie d‘écran illustre cette fenêtre d‘édition de la mise en forme en Annexe E (figure 88).

c. Fonctions de validation

Une première validation des données se fait à l‘importation des données. Contrairement aux fichiers texte qui acceptent un format libre, l‘importation dans la base de données ne peut être faite que si la syntaxe textuelle est respectée. S‘y ajoutent d‘autres contraintes telles que l‘existence du lemme comme forme, la conformité des étiquettes au référentiel. Celle-ci est aussi utilisée pour contrôler que la description de chaque forme contient au moins une étiquette indiquant sa catégorie grammaticale. Ces contraintes sont génériques alors que d‘autres sont spécifiques au type de données importées, comme le fait de contrôler les nominalisations sur la présence d‘un verbe et d‘un nom d‘après les informations déjà présentes dans la base. Cela implique évidemment de suivre un certain ordre de chargement des informations.

171 Les entrées lexicales qui ne correspondent pas strictement aux contraintes ne sont pas importées et sont marquées dans un log d‘erreurs. Ces logs sont ensuite repris pour la correction des entrées incriminées.

Nous n‘avons pas chargé les grammaires dans la base de données, mais prévu un mécanisme pour contrôler la validité des informations présentes dans les grammaires. La validation lexicale d‘une grammaire revient à contrôler que toutes les informations lexicales des règles existent dans la base de connaissances lexicales. Le mécanisme est intégré à l‘interface pour la validation lexicale des automates : après indication de l‘ensemble de données à prendre en compte, l‘interface liste toutes les informations lexicales présentes dans les règles et indique si elles ont été retrouvées dans la base de connaissances lexicales. Leur absence dans la base n‘indique pas forcément une erreur, donc il faut vérifier la liste manuellement. Cette validation lexicale d‘automates est particulièrement utile pour tracer des erreurs qui seraient noyées dans la masse d‘informations autrement.

La validation lexicale du modèle de langage a été réalisée sur le même modèle sans avoir été intégrée à l‘interface. Le modèle de langage est utilisé pour la désambiguïsation morphosyntaxique du lexique et contient un lexique et une grammaire. Les informations lexicales de la grammaire étant présentes dans le lexique, il suffit de soumettre ce dernier à une validation lexicale. Le lexique du modèle de langage se présente comme un ensemble de mots-formes avec leur catégorie grammaticale. Chaque combinaison est contrôlée en vérifiant la présence de ces éléments dans la base de connaissances lexicales.

En ce qui concerne les autres grammaires, notamment celles pour la désambiguïsation grammaticale à la requête, la question de la validation lexicale est de même importance, mais comme elles sont codées directement dans le code source, il est impossible d‘automatiser la validation lexicale de la même façon.