Mise en place de la base de connaissances lexicales

Avant de développer le modèle relationnel de la base de connaissances lexicales, nous avons d‘abord tenu à expliciter les informations concernées. En partant du modèle ensembliste présenté en 6.3, nous avons visualisé ces informations dans un diagramme UML. La figure 48 montre la version de développement qui a servi à expliciter les liens entre les différentes informations concernées : elle contient les informations des lexiques et celles des grammaires qui sont en interaction directe avec les ressources lexicales. Ce diagramme ne contient pas de conteneurs de classes, comme les classes grammaire ou lexique. Les couleurs ne font pas partie de la modélisation UML standard, mais nous les avons ajoutées pour découper le schéma en parties liées selon la couche de traitements. Ainsi les classes des grammaires sont indiquées en jaune, les objets verts sont des objets morphosyntaxiques et les objets liés à la sémantique de surface sont lavande.

lexique txt lexique csv LKB Interface client Interface client Interface client

164

Figure 48 : Le diagramme UML des informations lexicales

Une fois les relations entre les informations tirées au clair, nous avons créé le modèle relationnel. Ce modèle est le résultat d‘un processus de test et de réflexion pour trouver un modèle efficace et adapté à nos besoins.

La figure 49 montre le schéma relationnel final¹⁰². Il comporte 9 tables, dont 3 tables de jointure, c‘est-à-dire des tables qui servent à exprimer des relations « plusieurs-à-plusieurs » par l‘utilisation de clés étrangères.

165

Figure 49 : Schéma relationnel de la base de données

La table « Formes » est la table centrale du modèle. Elle contient le mot-forme, son identifiant, et l‘identifiant du lemme associé. Le mot-forme n‘est pas unique, contrairement à son identifiant. Si un mot-forme est ambigu, il apparaîtra donc dans plusieurs enregistrements. Les identifiants des formes qui sont des lemmes sont listés dans l‘entité Lemmes. Si le lemme est ambigu, le bon identifiant de forme est choisi grâce à la catégorie grammaticale.

A titre d‘exemple, on voit dans la figure 50 que le mot-forme manger est ambigu comme nom et comme verbe. L‘identifiant de ce même mot-forme figure ensuite dans le champ de lemme des formes fléchies. Ainsi l‘identifiant de lemme de mangeais est 197711, ce qui nous ramène vers le verbe à l‘infinitif manger. La colonne « code_etiquettes » n‘a qu‘une valeur informative, les valeurs réelles étant codés dans la table de jointure « Etiqueter ».

166

Figure 50 : Extrait de la table « Formes »

La provenance de chaque entrée est marquée par la table « Fichiers » qui associe un nom de fichier à chaque identifiant de mot-forme afin qu‘on puisse soit retrouver facilement le fichier physique qui contient le mot-forme soit filtrer sur cette information.

L‘entité « Etiquettes » contient toutes les étiquettes morphosyntaxiques et sémantiques avec leur définition. La figure 51 montre un exemple où on voit les étiquettes POS, PPR et PPS avec le début de leur définition. Une table de jointure, appelé « Etiqueter », lie les identifiants de mots-formes avec ces étiquettes. Le type fait référence au rang de l‘étiquette, primaire (= catégorie grammaticale), secondaire (= trait morphosyntaxique) ou tertiaire (trait sémantique).

Figure 51 : Extrait de la table « Etiquettes »

De la même façon que « Etiquettes » contient les définitions des étiquettes morphosyntaxiques et sémantiques, « Desc_sem » contient les définitions des descripteurs thématiques. Ces descripteurs sont décrits par des chiffres de 1 à 810 et sont associés aux lemmes par la table de jointure « Signifier ». La figure 52 montre un exemple pour les descripteurs 310 à 312, avec leur définition.

Figure 52 : Extrait de la table « Desc_sem »

L‘entité « Lien_ling » (figure 53) contient les 4 types d‘associations qui existent dans nos lexiques et qui représentent des renvois simples ou doubles. Les types sont exploités dans la table de jointure « Ass_ling » où ils sont associés à deux ou plusieurs id de lemme. Ces entités sont illustrées dans la figure 54 et la figure 55. See Also désigne un renvoi simple. L‘indice dans « Ass_ling » indique la direction du lien. Les exemples ci-dessous illustrent le lien de

167 nominalisation entre abasourdir et abasourdissement. Leurs identifiants de lemme sont liés dans « Ass_ling ».

Figure 53 : La table « Lien_ling »

Figure 54 : La table « Ass_ling »

Figure 55 : La table « Formes »

Les quatre liens linguistiques sont bien ceux proposés dans le diagramme UML avec la différence que les liens entre lemmes ou entre formes ne sont pas distingués. En effet, ils ont tous été implémentés comme des liens entre lemmes. Selon l‘exploitation faite de ces informations, il n‘y a pas de réelle différence entre les deux puisque les mots-formes sont pris en compte comme des lemmes. Dans l‘absolu, il est vrai que les équivalences de variation orthographique et d‘acronymie se situent au niveau des formes, mais cela revient en pratique au même si on les considère au niveau de la forme ou au niveau de lemme. Ainsi l‘ensemble des équivalences clé / clef et clés / clefs égale l‘équivalence entre lemmes clé / clef, sachant qu‘il existe les lemmatisations clé pour clé/clés et clef pour clef/clefs.

Pour l‘instant, aucune base pour une langue compositionnelle n‘a été mise en place. Si c‘était le cas, il faudrait complexifier légèrement le modèle pour ajouter les composants des mots composés dont la décomposition est codée dans le lexique. Cela ne concerne que quelques mots composés qui ne sont pas couverts par la grammaire de décomposition ou des mots composés dont la décomposition par les règles est ambiguë et erronée. Quelques exemples en allemand de mots composés non couverts par la règle sont donnés en 8.3.2.2c et concernent la composition avec des mots trop courts pour être pris en compte par les règles générales, comme les mots Ei et Öl.

La question de savoir comment nous pouvions intégrer les règles dans la base de connaissances lexicales était particulièrement difficile à résoudre. Les automates étant des structures complexes en XML, leur ajout dans base de connaissances lexicales nous a paru absurde. Le besoin qui existe est de savoir pour chaque mot-forme s‘il existe une règle

168 associée à ce mot-forme, pour éviter que la modification ou la suppression d‘un mot-forme ne rende la règle caduque. A défaut d‘accrocher des références de règles à des entrées lexicales, nous avons mis en place une solution qui allège le modèle plutôt que de le complexifier. Les règles ne sont pas chargées dans la base de connaissances lexicales, mais nous avons introduit la possibilité de vérifier l‘existence des connaissances utilisées dans les règles dans la base de connaissances lexicales. Cette vérification repose sur le client et sera abordée dans le point suivant (7.2.4).