Nous allons maintenant voir comment construire des DRSs pour les phrases engendrées par la grammaire précédente dans le formalisme de Muskens. Comme nous l’avons indiqué lors de la présentation de ce formalisme, celui-ci peut associer des représentations distinctes à deux occurrences distinctes d’une même entrée lexicale. Cela se produit par exemple pour les déter-minants, chacune de leurs occurrences étant supposée annotée de façon unique par un nombre qui est utilisé pour générer un référent de discours, lui aussi unique.
Or, nous avons expliqué au chapitre 2 comment il est possible de faire en sorte queNessie construise des représentations différentes pour une même entrée lexicale. Il suffit de donner aux feuilles correspondant aux entrées lexicales dont les occurrences doivent être distinguées des ar-guments qui seront vus comme des constantes et pourront à ce titre figurer dans la représentation de la feuille correspondante. Cependant, les arbres syntaxiques construits par la grammaire que nous utilisons ne permettent pas, pour le moment, de distinguer deux occurrences d’un détermi-nant. Par exemple, l’arbre produit par notre grammaire lors de l’analyse de la phrase « A man loves a woman. » est le suivant :
unary(t,
binary(s,
binary(np,
leaf(indef, det),
unary(n, leaf(man, noun)) ),
binary(vp,
leaf(love, tv), binary(np,
leaf(indef, det),
unary(n, leaf(woman, noun)) )
) )
)
Comme on peut le constater, les deux occurrences du déterminant indéfini sont représen-tées par la même feuilleleaf(indef, det), ce qui supprime toute possibilité pourNessie de distinguer les occurrences entre elles et donc de produire des représentations spécifiques à chaque occurrence. Notre première tâche est donc de résoudre ce problème et de faire en sorte que l’arbre syntaxique soit porteur d’informations permettant de distinguer les occurrences des lexèmes pour lesquels on souhaite construire une représentation distincte pour chaque occur-rence.
Ce résultat peut être obtenu grâce à un prédicatProlog procédant à l’annotation d’arbres syntaxiques. Ce prédicat prend en entrée un arbre tel que celui que nous venons de montrer et renvoie en sortie un arbre dont les feuilles portant des déterminants ont un argument, cet argu-ment étant propre à chaque feuille. Pour garantir l’unicité de l’arguargu-ment, les feuilles contenant des déterminants sont comptées et lai-ième feuille reçoit l’argumentui.
Si nous appelons ce prédicat d’annotation sur l’arbre précédent, nous obtenons en sortie l’arbre suivant :
unary(t,
binary(s,
binary(np,
leaf(indef, det,u1), unary(n, leaf(man, noun)) ),
binary(vp,
leaf(love, tv), binary(np,
leaf(indef, det,u2),
unary(n, leaf(woman, noun)) )
) )
)
Cette fois, les feuilles représentant les deux occurrences du déterminant indéfini sont bien distinctes l’une de l’autre, puisque la première reçoit comme argumentu1tandis que la seconde reçoit en argumentu2. Notons que toutes les feuilles appartenant à la famille des déterminants sont ainsi comptées et annotées, ce qui signifie que, conformément aux préconisations de Mus-kens, on distingue non seulement toutes les occurrences des déterminants indéfinis, mais aussi toutes celles des déterminants universels et des déterminants négatifs.
Nous pouvons maintenant passer au lexique. Comme nous l’avons vu lorsque nous avons pré-senté l’approche de Muskens, il est indispensable de n’utiliser dans le lexique que les formes abrégées des λ-termes. En effet, si l’on ne se plie pas à cette discipline, les termes que l’on obtient sont non seulement quasi-illisibles, mais encore impossibles à simplifier, puisque la pro-cédure de fusion de DRSs ne peut s’appliquer qu’aux formes abrégées. Nous commençons par déclarer les types dont nous avons besoin :
type e; # Entities type pi; # Registers type s; # States
type drs = s -> s -> t; type condition = s -> t;
Viennent ensuite les déclarations de plusieurs symboles utiles : l’égalité et la différence entre entités, la constanteV permettant de trouver le contenu d’un registre dans un état donné, l’égalité entre états (dont une définition extensionnelle est donnée) et la propriété pour deux états de différer en au plus un registre, dont nous aurons besoin par la suite :
const eq : e -> e -> t; const neq : e -> e -> t; const V : pi -> s -> e; const seq : s -> s-> t :=
lam s1, s2 : s.
forall delta : pi. (V(delta,s1) = V(delta,s2)); const diff1 : s -> s -> pi -> t :=
forall delta : pi.
(delta != delta0 => V(delta,s1) = V(delta,s2));
Le lexique se poursuit par la déclaration de constantes qui peuvent être vues comme des constructeurs de DRSs et de conditions, au sens donné à ce terme lorsque nous avons introduit le langageOCamlau chapitre 21.Comme on va le voir, la plupart de ces constructeurs reflètent fidèlement les abréviations introduites par Muskens et dont nous avons laissé les références en commentaires lorsque cela était pertinent. Voici donc ces constructeurs :
const drs_of_dr : pi -> drs :=
lam u : pi. lam s1, s2 : s. (diff1(s1,s2,u)); const drs_of_condition : condition -> drs :=
lam c : condition. lam i, j : s.
(seq(i,j) && c(j));
const merge : drs -> drs -> drs := # ABB4 lam D1, D2 : drs.
lam i, j : s. exists k : s.
(D1(i,k) && D2(k,j));
const condition_of_urel : (e -> t) -> pi -> condition := # ABB1 lam P : e -> t. lam v : pi. lam i : s.
( P(V(v,i)) );
const condition_of_brel :
(e -> e -> t) -> pi -> pi -> condition := # ABB1 lam P : e -> e -> t. lam v1, v2 : pi. lam i : s. ( P(V(v1,i),V(v2,i)) );
const drsnot : drs -> condition := # ABB2 lam D : drs.
lam i : s. ! exists j : s. (D(i,j));
const drsor : drs -> drs -> condition := # ABB2 lam D1, D2 : drs.
lam i : s. exists j : s. (D1(i,j) || D2(i,j));
const drsimp : drs -> drs -> condition := # ABB2 lam D1, D2 : drs.
lam i : s. forall j : s.
(D1(i,j) => (exists k : s. (D2(j,k))));
Les deux premières constantes permettent de construire des DRSs contenant soit un référent de discours, soit une condition. Ainsi, siu1est un référent de discours etγ1une condition, alors la DRS notée[u1|]par Muskens sera représentée dans notre lexique par le terme
1Il faut cependant remarquer que les constructeurs dont il est ici question ne permettent pas de filtrage et ne défi-nissent d’ailleurs pas un type inductif.
drs_of_dr(u1), tandis que la DRS que Muskens note[|γ1]sera représentée dans notre lexique par le terme
drs_of_condition(gamma1). La troisième constante,merge, permet de construire une DRS à partir de deux DRSs existantes. Elle correspond en fait à l’opérateur ;de Muskens, et nous aurions donc tout aussi bien pu l’appeler seqpour indiquer qu’elle représente la séquence de deux DRSs. Le nommergene nous paraît cependant pas tout à fait illégitime, puisque les deux DRSs qui sont ainsi « séquencées » sont appelées à être fusionnées.
Les deux constantes suivantes,condition_of_ureletcondition_of_brelpermettent de construire des conditions atomiques à partir de relations unaires et binaires. Ces constructions sont des cas particuliers de l’abréviation 1 de Muskens. Ces deux constantes sont suffisantes, car les seules relations utilisées en pratique sont unaires ou binaires.
Enfin, les trois dernières constantes permettent de construire des conditions à partir de DRSs. Le lexique se poursuit par la définition des constantesimplicationetdisjunctionque nous avons introduites dans la section précédente. Rappelons que ces constantes apparaissent dans les arbres d’analyse produits pour les phrases du type « if ... then... » et « either ... or ... ». Ces constantes sont définies de la façon suivante :
const implication : drs -> drs -> drs := lam D1, D2 : drs. (drs_of_condition(drsimp(D1,D2))); const disjunction : drs -> drs -> drs := lam D1, D2 : drs. (drs_of_condition(drsor(D1,D2)));
Enfin, le lexique se termine par la déclaration de toutes les familles et de tous les lemmes nécessaires. Il s’agit en fait des mêmes familles et des mêmes lemmes que ceux rencontrés au chapitre 3, puisque la grammaire utilisée est la même. Seules les représentations associées aux lemmes changent, mais sans réserver de surprises particulières. Contentons-nous donc de présenter les représentations des déterminants, qui utilisent les arguments d’occurrences issus de l’étape d’annotation d’arbres syntaxiques mentionnée plus haut.
family det; lemma indef { family = det; const $1 : pi; term = lam P0, P : pi->drs. ( merge(drs_of_dr($1),merge(P0($1),P($1))) ) }; lemma uni { family = det; const $1 : pi; term = lam P0, P : pi->drs. ( drs_of_condition(drsimp(merge(drs_of_dr($1),P0($1)),P($1))) ) };
lemma neg { family = det; const $1 : pi; term = lam P0, P : pi->drs. ( drs_of_condition( drsnot(merge(drs_of_dr($1),merge(P0($1),P($1))))) ) };
On le voit, les termes associés aux trois lemmes sont des traductions fidèles de ceux proposés par Muskens dans (Muskens, 1996c).
Pour en terminer vraiment avec les remarques se rapportant au lexique, signalons que les observations relatives aux coordinations qui ont été faites au chapitre 3 restent de mise et que le traitement des coordinations qui est proposé ici est une adaptation à la théorie de Muskens de celui que nous avons utilisé au chapitre 3, à savoir que nous utilisons autant de familles de coordinations qu’il y a de catégories syntaxiques pouvant être coordonnées, donc ici une pour les noms, une pour les groupes nominaux et une pour les groupes verbaux.
Grâce à ce lexique, à la grammaire et au prédicat d’annotation d’arbres qui ont été présentés précédemment, nous sommes enfin en mesure de calculer automatiquement une représentation sémantique pour la phrase sur laquelle se sont appuyés nos exemples jusqu’ici, à savoir « A man loves a woman. ». Si nous transmettons son arbre syntaxique annoté àNessieet demandons à ce dernier d’afficher son résultat sous la forme d’un termeProlog, voici ce que nous obtenons : merge( drs_of_dr(u1), merge( drs_of_condition(condition_of_urel(man,u1)), merge( drs_of_dr(u2), merge( drs_of_condition(condition_of_urel(woman,u2)), drs_of_condition(condition_of_brel(love,u1,u2)) ) ) ) ).
Bien qu’il soit possible, au prix d’un petit effort, de se convaincre que ce terme représente bien la DRS recherchée, on ne peut s’empêcher de ressentir, en le contemplant, une certaine frustration. En effet, ce terme est complexe, surtout au vu de la phrase au demeurant fort simple dont il est sensé représenter le sens ! En effet, si une phrase aussi simple que « A man loves a woman. » produit un terme si peu lisible que celui-ci, qu’en sera-t-il pour des phrases plus complexes, eta fortioripour de véritables discours tels que ceux que l’on peut rencontrer dans le cadre d’applications réalistes ? Heureusement, la situation n’est pas aussi désespérée qu’il y paraît. En effet, en observant bien le terme que nous venons d’obtenir, on s’aperçoit qu’il contient plusieurs occurrences de la constantemergequi représente la fusion des deux DRSs
qu’elle reçoit en argument. Or, comme nous l’avons vu précédemment, sous certaines conditions deux DRSs peuvent être fusionnées, la DRS obtenue regroupant tous les référents de discours et toutes les conditions présents dans les DRSs à fusionner. En outre, nous avons vu que la simplification de DRS que Muskens utilise dans son algorithme de traduction fait intervenir non seulement laβ-réduction, mais aussi cette règle de fusion de DRSs. En d’autres termes, avec la représentation que nous venons d’obtenir, nous pourrions dire que nous n’avons parcouru que la moitié du chemin conduisant à une DRS telle qu’envisagée par Muskens. En effet, la seule règle qui a été exploitée pour simplifier les DRSs est laβ-réduction. La règle permettant de fusionner des DRSs n’a, pour sa part, pas encore été utilisée.
Il nous faut donc trouver un moyen d’appliquer cette règle jusqu’à ce que la DRS obtenue ne contienne plus d’occurrence du symbolemerge. Pour ce travail, il est clair queNessiene peut nous être d’aucune utilité. En effet, la seule règle de réécriture connue de Nessieest la
β-réduction et, on vient de le dire, la fusion de DRSs ne peut être obtenue par l’intermédiaire de
β-réductions. Nous devons donc trouver un autre moyen de simplifier les DRSs. Pour y parvenir, nous allons utiliserProlog, qui permet de manipuler facilement des termes tels que celui que nous venons de présenter.
Nous allons procéder en deux passes successives. Lors d’une première passe, nous allons procéder à une simplification (ou normalisation) des DRSs visant à faciliter leur fusion, réalisée pendant la seconde passe. Pour comprendre ce que nous entendons par simplification, il convient de réfléchir à la fusion de DRSs proprement dite. Comme nous l’avons indiqué, fusionner deux DRSs revient essentiellement à fusionner leurs ensembles de référents de discours d’une part, et leurs ensembles de conditions d’autre part. Pour que cela soit faisable, nous avons besoin d’exprimer toutes les DRSs « atomiques » en termes d’ensembles de référents de discours et de conditions, et cela de sorte que les DRSs ainsi exprimées soient faciles à utiliser dans le contexte d’une fusion.
Or, les DRSs produites par la phase de construction sémantique ne sont pas exprimées en termes d’ensembles de référents de discours et de conditions. Ou du moins, cette information n’est pas donnée de façon explicite. La première passe consiste donc essentiellement à rendre explicite les ensembles de référents de discours et de conditions constituant chaque DRS. Pour y parvenir, nous choisissons de représenter une DRS par un termePrologayant pour foncteur drsd’arité2. Les arguments de ce foncteur seront deux listes, la première étant une liste de ré-férents de discours, la seconde une liste de conditions. On l’aura compris, il s’agit ici d’adopter une notation qui s’approche des abréviations utilisées par Muskens. Le but de la première passe est donc de transformer des représentations sémantiques telles que celle qui a été vue précédem-ment en des représentations faisant intervenirdrs/2. Voici les règlesPrologque nous utilisons pour parvenir à ce résultat :
simplifyDrs(drs_of_dr(X),drs([X],[])). simplifyDrs(drs_of_condition(C),D) :- !, simplifyCondition(C,Cout), D = drs([],[Cout]). simplifyDrs(merge(D1,D2),D) :- !, simplifyDrs(D1,D1out), simplifyDrs(D2,D2out),
D = merge(D1out,D2out). simplifyCondition(condition_of_urel(P,A),Cout) :- !, Cout =.. [P,A]. simplifyCondition(condition_of_brel(P,X,Y),Cout) :- !, Cout =.. [P,X,Y]. simplifyCondition(drsimp(D1,D2),C) :- !, simplifyDrs(D1,D1out), simplifyDrs(D2,D2out), C = drsimp(D1out,D2out). simplifyCondition(drsor(D1,D2),C) :- !, simplifyDrs(D1,D1out), simplifyDrs(D2,D2out), C = drsor(D1out,D2out). simplifyCondition(drsnot(D),Cout) :- !, simplifyDrs(D,Dout), Cout = drsnot(Dout).
Les deux premières clauses définissantsimplifyDrssont celles simplifiant les DRSs ato-miques. Ce sont ces clauses, ainsi que celles où figurent les constantescondition_of_urelet condition_of_brelqui font effectivement quelque chose, les autres clauses ne servant qu’à traverser récursivement les DRSs et conditions. Si nous utilisons les prédicats que nous venons de définir sur la représentation sémantique précédemment construite, voici la DRS que nous obtenons :
merge(drs([u1], []), merge(drs([], [man(u1)]), merge(drs([u2], []), merge(drs([], [woman(u2)]), drs([], [love(u1, u2)]))))).
Nous remarquons que le terme ainsi obtenu est déjà plus simple que le précédent. Et sur-tout : ce terme montre — peut-être encore mieux que le précédent — sur-tout le bénéfice que l’on pourra tirer de la fusion de DRSs et à quel point fusionner les DRSs peut conduire à une sim-plification de la représentation obtenue. Avant de montrer comment cette simsim-plification est réa-lisée, il convient cependant de faire remarquer que, lors de notre première passe, nous nous sommes délibérément affranchis des contraintes de typage. Considérons en effet les trois sous-termesman(u1),woman(u2)etlove(u1,u2)apparaissant dans le terme simplifié. Dans le lexique qui a été utilisé pour la construction sémantique, man et woman ont été déclarés comme étant de la famille des noms et sont donc des prédicats de type e → t. De la même façon, loveétant un lemme de la famille des verbes transitifs, la constante qu’il introduit est de type
e→e→t. Du point de vue du typage, les applications de ces prédicats à des registres (de type
π) sont donc illicites. Nous faisons cependant le choix d’y recourir, pour obtenir des termes plus simples. Si nous avions voulu garder des termes typables tout au long du processus de simpli-fication de DRSs, il aurait fallu continuer d’utiliser les constructeurscondition_of_urelet condition_of_brel, et cela n’aurait pas été suffisant. Il aurait aussi fallu faire en sorte que le symboledrspuisse être typé. Or, quel type associer àdrs? Dans un système de types permet-tant le polymorphisme, on pourrait apporter à cette question une réponse simple :drsprend en
arguments une liste de référents de discours, une liste de conditions et renvoie une DRS. Ceci n’est cependant pas exprimable ainsi dans TYn. La seule solution que l’on pourrait apporter à ce problème dans TYnconsisterait à déclarer deux types de listes spécialisées, à savoir un type pour les listes de référents de discours et un autre type pour les listes de conditions, chacun de ces types devant fournir ses propres constructeurs « liste vide » et « ajout d’un élément à une liste ».
Tout cela est possible, certes, mais nous pensons que, compte tenu du but qui est le nôtre ici, nous n’avons pas un grand intérêt à garder à tout prix des termes typés tout au long du processus de simplification de DRSs. Nous passons donc à la deuxième étape de simplification, à savoir la fusion de DRSs proprement dite. Celle-ci est implantée à l’aide de trois prédicatsProlog: mergeDrs/2 qui procède à toutes les fusions de DRSs possibles en une étape de réécriture, hasMerge/1qui teste si un terme contient ou non des occurrences du symbolemerge, et enfin rewriteDrs/2 qui utilise les deux prédicats précédents pour réécrire une DRS tant qu’elle contient au moins une occurrence du symbolemerge. Voici les clausesPrologdéfinissant ces trois prédicats :
mergeDrs(merge(drs(Dr1,C1),drs(Dr2,C2)),drs(Dr,C)) :- !, appendLists(Dr1,Dr2,Dr),
appendLists(C1,C2,C).
mergeDrs(Term1,Term2) :- var(Term1), !, Term1=Term2. mergeDrs(Term1,Term2) :-nonvar(Term1), !, Term1 =.. [F|Args], maplist(mergeDrs,Args,NewArgs), Term2 =.. [F|NewArgs]. hasMerge(merge(_,_)). hasMerge(Term) :-nonvar(Term), !, Term =.. [_|Args], hasMergeList(Args). hasMergeList([]) :- fail.
hasMergeList([X|Xs]) :- hasMerge(X); hasMergeList(Xs). rewriteMerge(Term1,Term3)
:-hasMerge(Term1) ->
( mergeDrs(Term1,Term2), rewriteMerge(Term2,Term3) ); Term1 = Term3.
La première clause définissantmergeDrsest celle effectuant la réécriture proprement dite. La seconde clause permet de gérer correctement les variables et la troisième permet le parcours récursif des termes. Il est nécessaire d’appeler plusieurs fois le prédicatmergeDrsparce que des occurrences imbriquées demergene peuvent être simplifiées par un seul appel. Pour parachever ce travail de simplification, nous ajoutons des prédicats permettant d’afficher des DRSs sous une forme condensée qui s’inspire de celle utilisée par Muskens. En d’autres termes, un terme Prologde la formedrs([u1,u2],[c1,c2])est affiché[u1,u2|c1,c2].
Ainsi, la représentation de « A man loves a woman. » que nous obtenons après les deux passes de simplification est la suivante :
[u1,u2|man(u1),woman(u2),love(u1, u2)].
Cette représentation est, bien sûr, bien plus facile à lire que celle obtenue avant la simplifica-tion. Elle correspond très exactement à celle que Muskens propose, mais a cependant été obtenue automatiquement. Forts de ce premier succès, nous nous empressons de calculer d’autres DRSs : Pour la phrase « Every man loves a woman. » nous obtenons :
[|drsimp([u1|man(u1)], [u2|woman(u2),love(u1, u2)])].
Ou, pour un exemple un petit peu plus compliqué encore, nous pouvons calculer la représentation de « If every man loves mia then vincent loves mia ». Nous obtenons :
[|
drsimp([|
drsimp([u1|man(u1)], [|love(u1, mia)])], [|love(vincent, mia)]
) ].
Nous sommes donc parvenus à construire exactement les représentations proposées par Mus-kens. En plus deNessie, nous avons dû recourir pour atteindre ce résultat à un prétraitement des arbres syntaxiques pour en annoter les feuilles contenant des déterminants, et à de la réécriture pour réaliser les fusions de DRSs.