La transformation de graphes

1.1 Généralités

Une méthode permettant l’enrichissement et la modification de relations de dépendances commence à se répandre dans le domaine du traitement automatique des langues : la transformation (ou réécriture) de graphes.

En effet, pour analyser et annoter des relations sémantiques ou des relations syntaxiques profondes pour le français, le FTB en dépendances de surface constitue une base très utilisée et sa structure en arbres, qui est un type spécifique de graphes, est donc idéale pour ce type de transformation.

Le principe de la réécriture de graphes est de modifier un sous-graphe dans l’arborescence générale pour qu’il corresponde à la structure finale voulue. Ces modifications peuvent s’appliquer au niveau des nœuds, des arcs, des attributs (au niveau des nœuds) et des types (nom de la relation au niveau des arcs). [Ribeyre, 2013]. La transformation de graphes permet donc beaucoup de liberté sur les types de transformations souhaitées. C’est pour cette raison que nous nous sommes tournés vers ce procédé de réécriture de graphe pour l’application de notre conversion en dépendances profondes.

Dans le domaine du TAL, deux outils ont été directement conçus dans le but d’enrichir une structure en dépendances de surface, soit avec des annotations sémantiques : Grew [Bonfante et al., 2010] , soit avec des dépendances profondes : Ogre [Ribeyre, 2012].

1.2 Grew

L’outil Grew21 a pour objectif d’annoter automatiquement au niveau sémantique un corpus analysé en dépendances, plus particulièrement le FTB [Abeillé et al., 2003]. Le choix de ce formalisme s’est justifié par le format de structure sémantique adopté : la DMRS (Dependency Minimal Recursion Semantics) [Copestake, 2006] qui fournit des graphes de dépendances sémantiques cycliques.

21

52 Chaque règle de réécriture R est composée de trois éléments (Figure 16). Le premier élément est le « patron positif », qui est le graphe qui sera testé sur G, le graphe à transformer (1 sur la figure). Puis, les « patrons négatifs » (facultatifs) représentent les NAC (negative application condition) pour lesquels la règle ne s’appliquera pas, malgré le fait que le patron positif soit vérifié (2 sur la figure). Enfin, des « commandes » vont opérer les transformations sur les arcs, les nœuds, les attributs de G pour obtenir le résultat attendu (3 sur la figure). Au final, nous avons donc un système qui « cherche à apparier le patron positif de la règle […] avec une partie du graphe, et [qui] vérifie que l’appariement ne peut être étendu en un appariement pour aucun des patterns négatifs ». [Guillaume et al., 2012 : 5]

Figure 16 : Exemple d’une règle qui « transforme les actants syntaxiques en actants sémantiques » [Guillaume et al., 2012 : 5]

Des règles sont organisées et appliquées par modules ordonnés pour éviter les interactions non souhaitées. Des paramètres supplémentaires peuvent également entrer en ligne de compte pour préciser des traits : des lemmes, etc. au niveau des patrons et des commandes. Enfin, des filtres sont créés pour éliminer les incohérences générées par la transformation, ou encore permettre d’écrire des règles simplifiées en supprimant les surgénération dans cette phase [Guillaume et al., 2012]

53 Malgré toutes ces spécificités qui semblent adaptées à notre projet, ce système n’a pu être adopté car les seules versions disponibles sont pour Linux et Mac OS X, lorsque les ordinateurs de l’entreprise fonctionnent sous Windows.

1.3 Ogre

Le système Ogre [Ribeyre, 2012] présente un fonctionnement différent de celui de Grew que nous avons présenté en section 1.2. Le principe de base reste la réécriture de graphes, mais l’accent est mis sur l’utilisation d’une approche dite de « propagation de contraintes » au niveau des arcs. Il a été conçu dans le but d’insérer des relations de dépendances profondes à une analyse de surface. Les règles produites se veulent génériques afin de pouvoir s’adapter à différents analyseurs syntaxiques [Ribeyre, 2013].

Le langage créé spécialement pour cette transformation de graphe est nommé GrQL (Graph Query Language). A partir d’un patron constitué d’un graphe comportant nœuds, arcs et traits (au niveau des nœuds et des arcs), ce langage permet d’exécuter des commandes classiques du type ajout / suppression d’arc (ex : « add_node(F) » où F désigne la structure de traits), ajout / suppression de nœuds, etc., tout en autorisant la négation dans les motifs. L’ordre des règles est établi de manière automatique via un compilateur, les règles les plus spécifiques (Figure 17) étant appliquées avant les plus générales (Figure 18).

Figure 17 : Motif plus spécifique [Ribeyre, 2012 : 35]

Figure 18 : Motif plus général [Ribeyre, 2012 : 35]

Le compilateur permet également de remonter les conflits potentiels à l’utilisateur, en cas de règles présentant des arcs en commun et des transformations

54 contradictoires. Par exemple, si deux règles de réécriture s’appliquent sur un même arc, l’une pour supprimer l’arc et l’autre pour en changer la cible, il y a un conflit à signaler [Ribeyre, 2012].

Ogre donne la possibilité d’ajouter des contraintes sur les arcs, permettant ainsi de traiter des cas plus complexes d’opérations, et de produire des règles génériques tout en en maitrisant le nombre. Ces contraintes se déclenchent après la première partie de réécriture de graphe, en fonction du contexte des arcs et des nœuds. Elles permettent d’ajouter des relations profondes à la structure et sont au nombre de quatre (un exemple est donné en Figure 19, avec une contrainte utilisée pour « faire remonter les arcs sortants de y » [Ribeyre, 2012 : 48]).

Figure 19: Contrainte Redirect up [Ribeyre, 2012 : 49]

Au final, un filtre est appliqué pour supprimer, parmi les relations créées, celles qui n’ont pas de signification linguistique.

Les paramètres que l’on peut spécifier, la possibilité d’utiliser la négation et les définitions des contraintes sont des éléments totalement adapté à notre projet. Cependant, ce système n’est actuellement pas mis à disposition par son auteur.

Les deux approches exposées brièvement ici vont donc dans le sens de notre projet mais ne sont pas exploitables pour le moment. Nous nous sommes alors tournés vers un outil de transformation de graphes non spécifique au domaine du TAL, que nous présentons dans la section 2).

55