Conclusion

Dans ce chapitre, nous avons présentéNessie, un outil permettant de construire automati- quement la représentation sémantique de textes à partir des représentations des mots et d’arbres permettant de les combiner. Comme nous l’avons vu à la section 1.1, l’idée d’utiliser des arbres abstraits pour guider la construction sémantique est due à Montague et n’est donc pas nouvelle.

Or, les formalismes habituels (et en tout cas ceux qui utilisent des constituants) font partie gé- néralement de la classe des langages faiblement sensibles au contexte (middly context-sensitive languages), ce qui signifie en particulier qu’ils on t une structure de dérivation qui est un arbre de grammaire hors-contexte. C’est donc une structure privilégiée pour la construction sémantique.

Cependant, si cette idée structure semble largement admise par la communauté, la façon précise

dont il convient de combiner les représentations sémantiques des sous-arbres pour obtenir celle d’un arbre complet n’a pas, quant à elle, fait l’objet d’un consensus jusqu’à présent. Comme cela est expliqué dans (Heim et Kratzer, 1998), deux approches ont été proposées pour résoudre ce problème. La première consiste à associer à chaque nœud de l’arbre abstrait une règle spécifiant comment combiner les représentations de ses sous-arbres. La seconde approche préconise quant à elle que ce soient les types qui guident la combinaison des représentations sémantiques, avec pour avantage qu’il n’est plus nécessaire d’associer à chaque nœud une règle de construction explicite. Pour notre part, nous trouvons ces deux approches séduisantes et, surtout, nous ne les concevons pas comme antinomiques. C’est ainsi que, dansNessie, nous avons souhaité conci- lier les deux approches. La première est mise en œuvre grâce à l’utilisation d’arbresn-aires auxquels sont associés desλ-termes spécifiant comment combiner les représentations séman- tiques des sous-arbres. La seconde est partiellement mise en œuvre par l’utilisation des arbres binaires. En effet, lorsque ceux-ci sont utilisés, il n’est pas nécessaire de fournir une règle de combinaison explicite. En outre, nous aimerions faire remarquer qu’il serait facile, compte tenu de l’architecture qui est celle deNessie, d’ajouter d’autres règles permettant, à partir des types, d’inférer comment une représentation sémantique doit être construite.

Une telle extension deNessien’est cependant pas urgente. En effet, comme nous allons le montrer dans les chapitres suivants,Nessie, dans son état actuel, peut déjà être utilisé en sé- mantique computationnelle. Ainsi, nous commencerons par en montrer le bon fonctionnement dans le chapitre suivant, avant de l’utiliser dans l’étude de phénomènes sémantiques plus com- plexes, à savoir la construction de représentations temporelles pour les verbes du polonais et la construction compositionnelle de la sémantique de discours comportant plusieurs phrases, et cela en utilisant deux formalismes bien distincts.

Intégration de Nessie à Curt

Au début du chapitre précédent, nous avons expliqué queCurtavait été conçu surtout à des fins pédagogiques et ne nous semblait pas très bien adapté à une utilisation en vue d’explorer la construction sémantique pour différentes théories. Nous avions cependant annoncé, en sec- tion 1.3, que nous n’abandonnerions pas pour autantCurtdans cette thèse et que, au contraire, une fois en possession d’un outil capable de construire des représentations sémantiques dans TYnà partir de lexiques et d’arbres, nous ferions en sorte d’intégrer cet outil à l’architecture de Curt, de sorte à pouvoir profiter de sa DCG et de sa composante inférentielle.Nessieayant été présenté au chapitre précédent, il est donc temps de voir comment il peut être intégré à l’architecture deCurt, et c’est à cette tâche que nous allons nous consacrer maintenant.

L’objectif que nous poursuivons dans ce chapitre est double. Premièrement, nous souhaitons montrer queNessiefonctionne bien, et c’est cette raison qui nous pousse à l’intégrer àCurt. Notre démarche pour atteindre ce premier objectif va en effet consister à montrer que les re- présentations sémantiques construites par Nessie sont les mêmes que celles construites par Curt, ce qui nous permettra de nous convaincre queNessiefonctionne de façon satisfaisante.

Deuxièmement, nous cherchons dans ce chapitre à poser des bases qui nous seront utiles dans la suite de cette thèse, et cela de deux façons. D’une part, nous voudrions, comme nous l’avons an- noncé précédemment, être capables de construire pour une phrase reconnue par une grammaire des représentations sémantiques dans plusieurs formalismes différents, comme par exemple la DRT compositionnelle de (Muskens, 1996c) et le traitement compositionnel de la dynamicité de (de Groote, 2006). L’intégration de Nessie à Curt est un pré-requis indispensable à de telles expérimentations. Une fois celle-ci réalisée, il devrait en effet suffire d’écrire un lexique Nessiepour chaque théorie sémantique considérée, la construction sémantique pouvant alors être faite automatiquement (nous verrons au chapitre 6 qu’en réalité, écrire un lexiqueNessie n’est pas suffisant, mais cela ne change rien au fait que le travail d’intégration de Nessie à l’architecture deCurtmené à bien dans ce chapitre est nécessaire). Les travaux de ce chapitre servent donc de base aux implantations de (Muskens, 1996c) et (de Groote, 2006) qui seront réalisées au chapitre 6. D’autre part, ce chapitre a une portée méthodologique : il montre com- ment modifier une grammaire existante de sorte qu’elle produise des arbres d’analyse utilisables parNessie. Les enseignements tirés de ce travail d’adaptation faciliteront grandement le dé- veloppement, au chapitre suivant, d’une DCG reconnaissant des phrases polonaises simples, ce développement permettant quant à lui une première étude des conséquences du passage à la logique d’ordre supérieur sur l’inférence.

Nous commençons par discuter, dans la section 3.1, des différentes possibilités disponibles pour testerNessie. La section 3.2 détaille la mise en œuvre de la procédure de test choisie sur

les cas les plus simples. Nous nous intéressons ensuite à deux phénomènes sémantiques particu- liers : les coordinations (section 3.3) et les questions 3.4, l’étude des coordinations conduisant à une première confrontation avec les limites expressives de la famille de logiques TYn.

3.1 Procédure de test

Nous l’avons vu au chapitre 2,Nessieest un programme complexe. Il est composé de plu- sieurs modules et fait intervenir des structures de données complexes. En outre, comme nous l’avons montré, le processus permettant de construire une représentation sémantiqueβ-réduite à partir d’un lexique et d’un arbre est long et fait intervenir plusieurs étapes de calcul, dont certaines relativement raffinées.

Il paraît donc légitime, une fois un tel outil écrit et avant son utilisation dans des applications réalistes, de s’assurer que le fonctionnement de l’outil correspond bien à sa spécification telle que donnée au chapitre précédent. Ceci pose une question méthodologique : comment pouvons- nous être sûr queNessiefait bien ce qui est attendu et qu’il peut être utilisé en toute confiance en construction sémantique ?

Deux pistes sont communément proposées pour répondre à cette question. Une première piste consiste à prouver la correction deNessieà l’aide de logiciels d’aide à la preuve. Il s’agit dans ce cas de spécifier formellement chaque étape de calcul, de définir les fonctions réalisant le calcul et de prouver sur machine que les fonctions ainsi définies vérifient les propriétés attendues. Un outil d’extraction permet ensuite d’obtenir à partir des définitions de fonctions et des preuves as- sociées du code certifié correct¹. Une seconde possibilité consiste à vérifier les résultats produits par un programme. La manière de procéder à cette vérification dépend alors du programme que l’on étudie. Si le programme résout des équations, on peut par exemple vérifier que les solutions qu’il produit sont bien des solutions de l’équation initiale. Il est aussi possible de comparer les résultats fournis par le programme à tester à ceux fournis par d’autres programmes semblables existant depuis longtemps et dont on peut se convaincre qu’ils produisent les résultats attendus.

Bien sûr, la première méthode est plus puissante, dans la mesure où ce qui est prouvé est la correction de l’algorithme. Une fois la preuve faite, il n’est plus besoin de procéder à aucune vérification supplémentaire des résultats : ils sont corrects parce que l’algorithme qui les produit l’est. Cependant, étant donné les outils disponibles pour développer des programmes certifiés, prouver la correction d’un programme tel queNessieserait une tâche extrêmement complexe compte tenu de sa taille.

Donc, bien que le travail de certification d’algorithmes soit en lui-même enrichissant et ins- tructif (la formalisation oblige à comprendre les algorithmes et leurs preuves de correction avec une granularité bien plus fine que celle avec laquelle peuvent se faire les preuves sur le papier), nous y avons renoncé d’une part à cause de sa longueur, d’autre part parce qu’il nous aurait conduit, nous semble-t-il, bien loin des préoccupations linguistiques qui sont les nôtres dans cette thèse.

On l’aura compris, c’est donc la deuxième méthode, moins générique mais plus facile à mettre en œuvre sur un projet de ce type, que nous allons utiliser. Plus précisément, les tests vont

1Cette approche est explorée et mise en œuvre dans (Letouzey, 2004).

consister à comparer les résultats produits parNessieà ceux d’un programme existant et plus éprouvé que lui, en l’occurrenceCurt, qui a été introduit en section 1.3.

Le test que nous envisageons de mettre en place consiste à vérifier que, étant donné une phrase reconnue par Curt, il est possible d’en construire une représentation sémantique à l’aide de Nessie. En outre, il s’agit de vérifier que cette représentation sémantique produite parNessie est équivalente à celle construite parCurt. Reproduire ce test pour un nombre de phrases rela- tivement important est, à notre avis, une bonne façon de vérifier queNessiefonctionne bien.

Certes, cela ne suffit pas à prouver l’absence d’erreurs de conception ou de programmation, mais le test n’en demeure pas moins intéressant à notre avis.

La grammaire deCurtpermet de reconnaître des phrases déclaratives simples ainsi que des questions. En outre, phrases déclaratives et questions peuvent inclure des coordinations disjonc- tives et conjonctives. Dans la section 3.2, nous montrerons comment mettre en place le test évoqué ci-dessus. Nous ne nous intéresserons dans cette section qu’aux phrases déclaratives sans coordination. Les phrases avec coordinations seront quant à elles l’objet d’un traitement séparé, tout comme les questions, ces deux classes de phrases conduisant à des discussions qui nous paraissent importantes.