Td corrigé thèse - Clips-Imag pdf

thèse - Clips-Imag

Merci à Mutsuko et à Aree pour m'avoir aidé à corriger le texte japonais et thaï. ...... Ambassador est un logiciel commercial qui a connu une grande réussite, mais ...... On les « étiquette » par des énoncés IF, et on valide ensuite par examen ..... de traduction soit encore plus satisfaisant, on peut coupler l' interlingua général ...




part of the document



Pourtant, le problème principal reste : le coût de traduction et de révision d’un document multilingue croît linéairement en fonction du nombre de langues. Pour le résoudre, nous proposons de produire ces documents multilingues par traduction automatique (TA), de partager le travail de révision entre les langues, et de réviser incrémentalement, à la demande et en mode coopératif.
Notre solution est fondée sur l’utilisation d’un système de TA à « pivot », et reprend l’idée de « coédition » utilisée dans certains systèmes de génération multilingue. Pour des raisons développées en détail, UNL (Universal Networking Language) semble le meilleur langage pivot pour un tel système. Dans notre approche, l’utilisateur peut non seulement éditer directement le texte, mais aussi « coéditer » le graphe à travers le texte. Pour cela, une heuristique construit automatiquement une correspondance fine entre le texte et le graphe UNL en n’utilisant que des ressources disponibles gratuitement pour beaucoup de langues (segmenteurs, lemmatiseurs, dictionnaires). Pour chaque fragment de texte ainsi relié au graphe, on peut construire un menu dont chaque item est formé d’une annotation dans le texte et d’une action sur le graphe. Le graphe modifié peut être ensuite déconverti dans plusieurs langues, qui bénéficient toutes des corrections effectuées. Une maquette permet de démontrer un scénario dans lequel l’utilisateur alterne entre lecture (monolingue) et coédition.
Mots-Clés : Traduction Automatique, partage de révision, langage pivot, interlingua, coédition, UNL, correspondances entre structures, génération multilingue.
Abstract
As the demand for multilingual communication increases, the need to generate and to maintain multilingual documents becomes more and more important, for both international firms and ordinary Internet users. However, the main problem remains : the cost of translation and postediting of multilingual documents increases linearly with the number of the languages involved. To solve this problem, we propose to produce multilingual documents by machine translation (MT), to share the task of revision among languages, and to postedit incrementally on demand and in cooperative mode.
Our solution is based on using a “pivot” MT system, and building on the idea of the “co-edition” as used in some multilingual generation systems. As detailed in the thesis, UNL (Universal Networking Language) seems to be the best pivot language for such a system. Users can not only directly edit the text, but also “co-edit” the graph through the text. In order to achieve this, a heuristic method is proposed to construct automatically a fine-grained correspondence between the text and the UNL graph by using only freely available resources for many languages (segmenters, lemmatisers, and dictionaries). For each segment of the text linked to the graph in this way, we can construct a menu, in which each item consists of an annotation of the text and an action on the graph. The modified graph can then be deconverted into several languages, all of which benefit from the corrections. A prototype demonstrates a scenario where the user switches between reading mode (monolingual) and co-editiing mode.
Key words : Machine translation, postediting sharing, pivot language, interlingua, co-edition, UNL, correspondences between structures, multilingual generation.



Remerciements

En premier lieu, je remercie profondément le directeur de ma thèse, le professeur Christian BOITET, qui m’a toujours poussé jusqu’au bout et m’a toujours soutenu aux moments les plus difficiles. C’est lui qui m’a montré et appris la persistance et la précision indispensables pour être un chercheur. Je suis toujours impressionné par son exigence et sa passion pour la TA.
Je remercie mes rapporteurs, le professeur Paul SABATIER et le professeur Patrice POGNAN, qui ont accepté d’être rapporteurs de ma thèse à une période très chargée. Je remercie le professeur Marie-France BRUANDET et le professeur Marc DYMETMAN pour accepter d’être le président et l’examinateur de ma thèse.
Je remercie le professeur Etienne BLANC, qui m’a guidé dans la TA sur ARIANE et UNL. Je remercie aussi le professeur Gilles SÉRASSET, Mr. Youcef BEY, et Mr. Stéphane HELME pour leur aide et leur contribution à la programmation de la maquette.
Je remercie monsieur Hiroshi UCHIDA pour avoir inventé l’UNL, et toute la communauté UNL, surtout le professeur Igor BOGUSLAVSKY, le professeur Jésus CARDEÑOSA, et le professeur Irina PRODANOF, pour m’avoir aidé sur la déconversion du russe, de l’espagnol et de l’italien.
Je remercie aussi l’ensemble de l’équipe GETA qui m’a accueilli et aidé durant ces années à Grenoble. Merci à Mutsuko et à Aree pour m’avoir aidé à corriger le texte japonais et thaï. Et surtout merci à Karën, Christophe, Mathieu pour leur amitié.
Je remercie le professeur François TCHEOU, qui m’a accueilli chaleureusement quand je venais d’arriver à Grenoble, et m’a soutenu tout au long de mon séjour en France, et m’a toujours fait confiance.
Je tiens à remercier Mr. John Kent de Londres et Madame Christina Cross de Lodi, Californie, pour leur soutien psychologique, qui m’a beaucoup aidé à mieux me comprendre.
Enfin et surtout, mes remerciements vont à vous, ma famille à Taiwan, ma Grande-mère, mes parents et Yi-Chia, sans vos soutiens cette thèse n’aurait pas été possible. La conversation téléphonique hebdomadaire avec vous m’a été très importante et chère. Merci encore pour votre patience et votre écoute. Vous êtes toujours dans mon cœur.

I would like to thank Mr. John Kent from London and Ms. Christina Cross from Lodi, California, without your insights, encouragement, and long-term support, I wouldn’t be able to come this far, and would probably still be entangled in the push-and-pull of my emotions. It is the dialogue with you that keeps me conscious and opens me up to the spiritual and psychological world. I appreciate a lot the tools and the lessons you brought me and hope that I can still keep on making the conscious choices in both scientific and psychological fields, stop jumping on one foot and find the keys which are out there in the dark, beyond the light of the lamp.
b„‰a‹hTåwLˆYeˆc(Wb[R†O0RÕl WBf
\b±qÃ_„vgqg˜åNÊScŒ~f}b„vŸõRŒT
\b„vý€›R„vøváO0
bg‰a‹„v/fb„v¶[ºN ÿvYvY8r8r½Z½ZŒTœ[¶[ ÿ’l g`OP„vSb#lÊS¾|^y/eôcÇ{֊‡e/f
NïSý€Œ[b„v0‹‹`OP(WÏk1„vŠ mû–qŠ
N€Ã_„v¾P}€ŒTú^p‹0Yux[u¯mæSY„v6ekz/f“‹bôfñm;R0WԚg†N`OP„vzfga ÿb„vy#l ÿª‰Å`„v«n–fŒT͑‰0ߎWñmä’ ÿbB}¼e†N㉆N0
gŒ_ ÿck‚Ys–KNé…@bŠ ÿ‰a‹„vºNŒT‹N*YY ÿ@båNb‹)Y0

Table des matières

 TOC \o "1-5" \h \z  HYPERLINK \l "_Toc72864233" Résumé  PAGEREF _Toc72864233 \h i
 HYPERLINK \l "_Toc72864234" Abstract  PAGEREF _Toc72864234 \h i
 HYPERLINK \l "_Toc72864235" Remerciements  PAGEREF _Toc72864235 \h iii
 HYPERLINK \l "_Toc72864236" Table des matières  PAGEREF _Toc72864236 \h v
 HYPERLINK \l "_Toc72864237" Liste des figures  PAGEREF _Toc72864237 \h xiii
 HYPERLINK \l "_Toc72864238" Liste des tableaux  PAGEREF _Toc72864238 \h xvii
 HYPERLINK \l "_Toc72864239" Introduction  PAGEREF _Toc72864239 \h 1
 HYPERLINK \l "_Toc72864240" Situation et motivations  PAGEREF _Toc72864240 \h 1
 HYPERLINK \l "_Toc72864241" Intérêt de notre travail  PAGEREF _Toc72864241 \h 2
 HYPERLINK \l "_Toc72864242" Organisation de la thèse  PAGEREF _Toc72864242 \h 3
 HYPERLINK \l "_Toc72864243" A. Contexte et motivations  PAGEREF _Toc72864243 \h 5
 HYPERLINK \l "_Toc72864244" Introduction  PAGEREF _Toc72864244 \h 5
 HYPERLINK \l "_Toc72864245" 1. Position du problème et motivation du paradigme de la coédition de textes multilingues  PAGEREF _Toc72864245 \h 7
 HYPERLINK \l "_Toc72864246" 1.1 Problème de la TA « classique »  PAGEREF _Toc72864246 \h 7
 HYPERLINK \l "_Toc72864247" 1.2 Pour la TA multisource et multicible, une architecture à pivot interlingue est nécessaire  PAGEREF _Toc72864247 \h 8
 HYPERLINK \l "_Toc72864248" 1.3 Diminution des coûts par partage de la révision /post-édition en TA multilingue - l’idée de la coédition  PAGEREF _Toc72864248 \h 9
 HYPERLINK \l "_Toc72864249" 1.4 Utilisabilité par des non-spécialistes et des bénévoles  PAGEREF _Toc72864249 \h 10
 HYPERLINK \l "_Toc72864250" 2. Définition des notions principales concernant la coédition  PAGEREF _Toc72864250 \h 11
 HYPERLINK \l "_Toc72864251" 2.1 Présentation de quelques systèmes utiles pour préciser la notion de coédition  PAGEREF _Toc72864251 \h 11
 HYPERLINK \l "_Toc72864252" 2.1.1 LIDIA (Large Internationalisation des Documents par Interaction avec l’Auteur)  PAGEREF _Toc72864252 \h 11
 HYPERLINK \l "_Toc72864253" 2.1.1.1 Fiche d’identité  PAGEREF _Toc72864253 \h 14
 HYPERLINK \l "_Toc72864254" 2.1.1.2 Remarque  PAGEREF _Toc72864254 \h 15
 HYPERLINK \l "_Toc72864255" 2.1.2 MODEX  PAGEREF _Toc72864255 \h 15
 HYPERLINK \l "_Toc72864256" 2.1.2.1 Fiche d’identité  PAGEREF _Toc72864256 \h 16
 HYPERLINK \l "_Toc72864257" 2.1.2.2 Remarque  PAGEREF _Toc72864257 \h 17
 HYPERLINK \l "_Toc72864258" 2.1.3 DRAFTER  PAGEREF _Toc72864258 \h 17
 HYPERLINK \l "_Toc72864259" 2.1.3.1 Fiche d’identité  PAGEREF _Toc72864259 \h 17
 HYPERLINK \l "_Toc72864260" 2.1.3.2 Remarque  PAGEREF _Toc72864260 \h 18
 HYPERLINK \l "_Toc72864261" 2.1.4 Ambassador  PAGEREF _Toc72864261 \h 18
 HYPERLINK \l "_Toc72864262" 2.1.4.1 Fiche d’identité  PAGEREF _Toc72864262 \h 20
 HYPERLINK \l "_Toc72864263" 2.1.4.2 Remarque  PAGEREF _Toc72864263 \h 20
 HYPERLINK \l "_Toc72864264" 2.1.5 L’approche WYSIWYM (What you See Is What You Meant)  PAGEREF _Toc72864264 \h 20
 HYPERLINK \l "_Toc72864265" 2.1.5.1 Fiche d’identité  PAGEREF _Toc72864265 \h 22
 HYPERLINK \l "_Toc72864266" 2.1.5.2 Remarque  PAGEREF _Toc72864266 \h 23
 HYPERLINK \l "_Toc72864267" 2.1.6 Multimeteo  PAGEREF _Toc72864267 \h 23
 HYPERLINK \l "_Toc72864268" 2.1.6.1 Fiche d’identité  PAGEREF _Toc72864268 \h 25
 HYPERLINK \l "_Toc72864269" 2.1.6.2 Remarque  PAGEREF _Toc72864269 \h 26
 HYPERLINK \l "_Toc72864270" 2.1.7 MDA (Multilingual Document Authoring)  PAGEREF _Toc72864270 \h 26
 HYPERLINK \l "_Toc72864271" 2.1.7.1 Fiche d’identité  PAGEREF _Toc72864271 \h 26
 HYPERLINK \l "_Toc72864272" 2.1.7.2 Remarque  PAGEREF _Toc72864272 \h 27
 HYPERLINK \l "_Toc72864273" 2.2 Aspect principaux  PAGEREF _Toc72864273 \h 27
 HYPERLINK \l "_Toc72864274" 2.2.1 Définitions  PAGEREF _Toc72864274 \h 27
 HYPERLINK \l "_Toc72864275" 2.2.2 Application de cette taxonomie aux systèmes étudiés  PAGEREF _Toc72864275 \h 28
 HYPERLINK \l "_Toc72864276" 2.2.3 Comparaison synthétique  PAGEREF _Toc72864276 \h 29
 HYPERLINK \l "_Toc72864277" 2.3 Types de coédition souhaitables  PAGEREF _Toc72864277 \h 29
 HYPERLINK \l "_Toc72864278" 3. Comment adapter l’idée de coédition à la communication multilingue écrite/orale  PAGEREF _Toc72864278 \h 30
 HYPERLINK \l "_Toc72864279" 3.1 Architecture linguistique générale “à pivot”  PAGEREF _Toc72864279 \h 30
 HYPERLINK \l "_Toc72864280" 3.1.1 Utilisation d’une représentation interlingue pivot  PAGEREF _Toc72864280 \h 30
 HYPERLINK \l "_Toc72864281" 3.1.2 Production automatique ou semi-manuelle du pivot  PAGEREF _Toc72864281 \h 31
 HYPERLINK \l "_Toc72864282" 3.1.3 Coédition séparée/indépendante des langues analysées  PAGEREF _Toc72864282 \h 31
 HYPERLINK \l "_Toc72864283" 3.2 Insertion dans des systèmes d’information  PAGEREF _Toc72864283 \h 31
 HYPERLINK \l "_Toc72864284" 3.2.1 Aspect décentralisé  PAGEREF _Toc72864284 \h 31
 HYPERLINK \l "_Toc72864285" 3.2.2 Traitement local avec ressources minimales  PAGEREF _Toc72864285 \h 31
 HYPERLINK \l "_Toc72864286" 3.2.3 Disponibilité sur Internet et Intranet  PAGEREF _Toc72864286 \h 31
 HYPERLINK \l "_Toc72864287" 3.3 Ingrédients d’une solution à pivot du point de vue des systèmes d’information  PAGEREF _Toc72864287 \h 32
 HYPERLINK \l "_Toc72864288" 3.3.1 Un document maître XML-isé  PAGEREF _Toc72864288 \h 32
 HYPERLINK \l "_Toc72864289" 3.3.2 Passage aisé entre deux modes de coédition - naïf et professionnel  PAGEREF _Toc72864289 \h 32
 HYPERLINK \l "_Toc72864290" 3.3.3 Choix de correction proposé par le système  PAGEREF _Toc72864290 \h 32
 HYPERLINK \l "_Toc72864291" 3.3.4 Établissement a posteriori des correspondances  PAGEREF _Toc72864291 \h 32
 HYPERLINK \l "_Toc72864292" 3.3.5 Intégration de ressources gratuites  PAGEREF _Toc72864292 \h 33
 HYPERLINK \l "_Toc72864293" 3.3.5.1 PILAF (Procédures Interactives Linguistiques Appliquées au Français)  PAGEREF _Toc72864293 \h 33
 HYPERLINK \l "_Toc72864294" 3.3.5.2 Autotag de CKIP  PAGEREF _Toc72864294 \h 34
 HYPERLINK \l "_Toc72864295" 3.3.5.3 MeCab  PAGEREF _Toc72864295 \h 36
 HYPERLINK \l "_Toc72864296" 3.3.5.4 Remarques sur les résultats d’analyse morpho-syntaxique  PAGEREF _Toc72864296 \h 37
 HYPERLINK \l "_Toc72864297" B. Quel langage pivot choisir?  PAGEREF _Toc72864297 \h 43
 HYPERLINK \l "_Toc72864298" Introduction  PAGEREF _Toc72864298 \h 43
 HYPERLINK \l "_Toc72864299" 1. État de l’art sur les pivots utilisés et utilisables en TA  PAGEREF _Toc72864299 \h 45
 HYPERLINK \l "_Toc72864300" 1.1 Introduction à la notion de pivot  PAGEREF _Toc72864300 \h 45
 HYPERLINK \l "_Toc72864301" 1.1.1 Pivot architectural  PAGEREF _Toc72864301 \h 45
 HYPERLINK \l "_Toc72864302" 1.1.2 Degré d’abstraction et de “sémanticité”  PAGEREF _Toc72864302 \h 45
 HYPERLINK \l "_Toc72864303" 1.2 Systèmes de TA utilisant l’architecture pivot et leurs pivots  PAGEREF _Toc72864303 \h 47
 HYPERLINK \l "_Toc72864304" 1.2.1 “PIVOT-I” du CETA (pivot “hybride” à la Shaumyan) (1963-1970) (propriétés et relations sémantiques et logiques)  PAGEREF _Toc72864304 \h 48
 HYPERLINK \l "_Toc72864305" 1.2.1.1 Historique du système  PAGEREF _Toc72864305 \h 48
 HYPERLINK \l "_Toc72864306" 1.2.1.2 Description du pivot  PAGEREF _Toc72864306 \h 48
 HYPERLINK \l "_Toc72864307" 1.2.1.3 Exemples du pivot  PAGEREF _Toc72864307 \h 50
 HYPERLINK \l "_Toc72864308" 1.2.1.4 Remarques  PAGEREF _Toc72864308 \h 50
 HYPERLINK \l "_Toc72864309" 1.2.2 Titus IV de l’Institut Textile de France (1973-1995) (pivot fortement sémantique et LN contrôlée)  PAGEREF _Toc72864309 \h 51
 HYPERLINK \l "_Toc72864310" 1.2.2.1 Historique du système  PAGEREF _Toc72864310 \h 51
 HYPERLINK \l "_Toc72864311" 1.2.2.2 Description du pivot  PAGEREF _Toc72864311 \h 52
 HYPERLINK \l "_Toc72864312" 1.2.2.3 Remarque  PAGEREF _Toc72864312 \h 53
 HYPERLINK \l "_Toc72864313" 1.2.3 ALTAS-II de Fujitsu(1989- ) (interlingua sémantique général)  PAGEREF _Toc72864313 \h 53
 HYPERLINK \l "_Toc72864314" 1.2.3.1 Historique du système  PAGEREF _Toc72864314 \h 53
 HYPERLINK \l "_Toc72864315" 1.2.3.2 Description du pivot  PAGEREF _Toc72864315 \h 54
 HYPERLINK \l "_Toc72864316" 1.2.3.3 Exemples du pivot  PAGEREF _Toc72864316 \h 56
 HYPERLINK \l "_Toc72864317" 1.2.3.4 Remarque  PAGEREF _Toc72864317 \h 56
 HYPERLINK \l "_Toc72864318" 1.2.4 PIVOT de NEC (1989- ) (interlingua sémantique général)  PAGEREF _Toc72864318 \h 56
 HYPERLINK \l "_Toc72864319" 1.2.4.1 Historique du système  PAGEREF _Toc72864319 \h 56
 HYPERLINK \l "_Toc72864320" 1.2.4.2 Aspect interactif dans le système PIVOT  PAGEREF _Toc72864320 \h 57
 HYPERLINK \l "_Toc72864321" 1.2.5 Espéranto parenthésé/balisé dans le projet DLT (1982-1989) (LN+balises)  PAGEREF _Toc72864321 \h 58
 HYPERLINK \l "_Toc72864322" 1.2.5.1 Historique du système  PAGEREF _Toc72864322 \h 58
 HYPERLINK \l "_Toc72864323" 1.2.5.2 Description du pivot  PAGEREF _Toc72864323 \h 59
 HYPERLINK \l "_Toc72864324" 1.2.5.3 Exemples du pivot  PAGEREF _Toc72864324 \h 62
 HYPERLINK \l "_Toc72864325" 1.2.5.4 Remarque  PAGEREF _Toc72864325 \h 62
 HYPERLINK \l "_Toc72864326" 1.2.6 KBMT-89 (par CMU) (1987-1989) (Interlingua général avec ontologie)  PAGEREF _Toc72864326 \h 62
 HYPERLINK \l "_Toc72864327" 1.2.6.1 Historique du système  PAGEREF _Toc72864327 \h 63
 HYPERLINK \l "_Toc72864328" 1.2.6.2 Description du pivot  PAGEREF _Toc72864328 \h 66
 HYPERLINK \l "_Toc72864329" 1.2.6.3 Exemples du pivot  PAGEREF _Toc72864329 \h 68
 HYPERLINK \l "_Toc72864330" 1.2.6.4 Remarque  PAGEREF _Toc72864330 \h 71
 HYPERLINK \l "_Toc72864331" 1.2.7 IF dans les projets C-STAR et NESPOLE! (1996- ) (Interlingua spécialisé)  PAGEREF _Toc72864331 \h 71
 HYPERLINK \l "_Toc72864332" 1.2.7.1 Historique du système  PAGEREF _Toc72864332 \h 71
 HYPERLINK \l "_Toc72864333" 1.2.7.2 Description du pivot  PAGEREF _Toc72864333 \h 74
 HYPERLINK \l "_Toc72864334" 1.2.7.3 Construction et validation de la spécification de l’IF  PAGEREF _Toc72864334 \h 74
 HYPERLINK \l "_Toc72864335" 1.2.7.4 Exemples du pivot « IF »  PAGEREF _Toc72864335 \h 75
 HYPERLINK \l "_Toc72864336" 1.2.7.5 Remarque  PAGEREF _Toc72864336 \h 76
 HYPERLINK \l "_Toc72864337" 1.2.8 UNL (1996- ) (interlingua linguistico-sémantique général)  PAGEREF _Toc72864337 \h 76
 HYPERLINK \l "_Toc72864338" 1.2.8.1 Historique du système  PAGEREF _Toc72864338 \h 76
 HYPERLINK \l "_Toc72864339" 1.2.8.2 Description du pivot  PAGEREF _Toc72864339 \h 78
 HYPERLINK \l "_Toc72864340" 1.2.8.3 Exemples du pivot  PAGEREF _Toc72864340 \h 81
 HYPERLINK \l "_Toc72864341" 1.3 Pivots candidats pour la coédition multilingue  PAGEREF _Toc72864341 \h 84
 HYPERLINK \l "_Toc72864342" 1.3.1 Une LN  PAGEREF _Toc72864342 \h 84
 HYPERLINK \l "_Toc72864343" 1.3.2 Une LN « balisée »  PAGEREF _Toc72864343 \h 84
 HYPERLINK \l "_Toc72864344" 1.3.3 Interlingua spécialisé  PAGEREF _Toc72864344 \h 85
 HYPERLINK \l "_Toc72864345" 1.3.4 Interlingua général  PAGEREF _Toc72864345 \h 85
 HYPERLINK \l "_Toc72864346" 1.3.5 Sept critères de choix  PAGEREF _Toc72864346 \h 85
 HYPERLINK \l "_Toc72864347" 2. Le langage UNL comme pivot pour la coédition  PAGEREF _Toc72864347 \h 86
 HYPERLINK \l "_Toc72864348" 2.1 Pourquoi UNL?  PAGEREF _Toc72864348 \h 86
 HYPERLINK \l "_Toc72864349" 2.2 Ressource construites  PAGEREF _Toc72864349 \h 87
 HYPERLINK \l "_Toc72864350" 2.2.1 Pour la transformation entre la langue naturelle et le graphe UNL  PAGEREF _Toc72864350 \h 87
 HYPERLINK \l "_Toc72864351" 2.2.2 Pour l’intégration de la connaissance du monde réel  PAGEREF _Toc72864351 \h 88
 HYPERLINK \l "_Toc72864352" 2.2.3 Pour la génération du graphe UNL  PAGEREF _Toc72864352 \h 90
 HYPERLINK \l "_Toc72864353" 2.2.4 Pour l’utilisation sur le web  PAGEREF _Toc72864353 \h 92
 HYPERLINK \l "_Toc72864354" 2.3 Le langage UNL  PAGEREF _Toc72864354 \h 93
 HYPERLINK \l "_Toc72864355" 2.3.1 Relations, UW, scope  PAGEREF _Toc72864355 \h 93
 HYPERLINK \l "_Toc72864356" 2.3.2 Problème de sous-spécification  PAGEREF _Toc72864356 \h 96
 HYPERLINK \l "_Toc72864357" 2.3.3 Nécessité d’une « normalisation » de la méthode de représentation des phénomènes linguistiques en UNL  PAGEREF _Toc72864357 \h 97
 HYPERLINK \l "_Toc72864358" 2.3.4 Nécessité de « normalisation » de la procédure de l’encodage entre les équipes  PAGEREF _Toc72864358 \h 98
 HYPERLINK \l "_Toc72864359" 2.3.4.1 Problème  PAGEREF _Toc72864359 \h 98
 HYPERLINK \l "_Toc72864360" 2.3.4.2 Projet FB2004  PAGEREF _Toc72864360 \h 98
 HYPERLINK \l "_Toc72864361" 2.4 Formats de documents UNL et outils associés  PAGEREF _Toc72864361 \h 100
 HYPERLINK \l "_Toc72864362" 2.4.1 UNL-html.1 et UNL-html.2  PAGEREF _Toc72864362 \h 100
 HYPERLINK \l "_Toc72864363" 2.4.2 Visualiser un UNL document sur le web  PAGEREF _Toc72864363 \h 104
 HYPERLINK \l "_Toc72864364" 2.4.2.1 UNL Viewer - pour voir un document UNL-html.1  PAGEREF _Toc72864364 \h 104
 HYPERLINK \l "_Toc72864365" 3. Conception générale d’un système de coédition fondé sur UNL  PAGEREF _Toc72864365 \h 107
 HYPERLINK \l "_Toc72864366" 3.1 Scénarios  PAGEREF _Toc72864366 \h 107
 HYPERLINK \l "_Toc72864367" 3.1.1 Étape 1 : lecture normale  PAGEREF _Toc72864367 \h 107
 HYPERLINK \l "_Toc72864368" 3.1.2 Étape 2 : un passage manque  PAGEREF _Toc72864368 \h 107
 HYPERLINK \l "_Toc72864369" 3.1.3 Étape 3 : lecture « multilingue »  PAGEREF _Toc72864369 \h 107
 HYPERLINK \l "_Toc72864370" 3.1.4 Étape 4 : postédition sans coédition  PAGEREF _Toc72864370 \h 108
 HYPERLINK \l "_Toc72864371" 3.1.5 Étape 5 : postédition avec coédition  PAGEREF _Toc72864371 \h 108
 HYPERLINK \l "_Toc72864372" 3.1.6 Étape 6 : postédition avec coédition plus visualisation du graphe UNL  PAGEREF _Toc72864372 \h 108
 HYPERLINK \l "_Toc72864373" 3.1.7 Étape 7 : postédition avec coédition plus correction du graphe UNL  PAGEREF _Toc72864373 \h 108
 HYPERLINK \l "_Toc72864374" 3.1.8 Étape 8 : retour au contexte de lecture  PAGEREF _Toc72864374 \h 108
 HYPERLINK \l "_Toc72864375" 3.2 Structure du système de coédition utilisant UNL  PAGEREF _Toc72864375 \h 108
 HYPERLINK \l "_Toc72864376" 3.2.1 Le mode de lecture  PAGEREF _Toc72864376 \h 109
 HYPERLINK \l "_Toc72864377" 3.2.2 Le mode d’édition normale (pour non-spécialistes)  PAGEREF _Toc72864377 \h 109
 HYPERLINK \l "_Toc72864378" 3.2.3 Le mode d’édition avancée pour les experts  PAGEREF _Toc72864378 \h 109
 HYPERLINK \l "_Toc72864379" 3.2.4 Erreurs corrigibles et non corrigibles  PAGEREF _Toc72864379 \h 109
 HYPERLINK \l "_Toc72864380" 3.3 Architecture interne à quatre niveaux  PAGEREF _Toc72864380 \h 110
 HYPERLINK \l "_Toc72864381" 3.3.1 Graphe-UNL  PAGEREF _Toc72864381 \h 110
 HYPERLINK \l "_Toc72864382" 3.3.2 Texte  PAGEREF _Toc72864382 \h 110
 HYPERLINK \l "_Toc72864383" 3.3.3 Treillis-LMS  PAGEREF _Toc72864383 \h 110
 HYPERLINK \l "_Toc72864384" 3.3.4 Arbre-UNL  PAGEREF _Toc72864384 \h 111
 HYPERLINK \l "_Toc72864385" 3.4 Résumé de la démarche  PAGEREF _Toc72864385 \h 111
 HYPERLINK \l "_Toc72864386" C. Étude des correspondances UNL-texte  PAGEREF _Toc72864386 \h 113
 HYPERLINK \l "_Toc72864387" Introduction  PAGEREF _Toc72864387 \h 113
 HYPERLINK \l "_Toc72864388" 1. Modélisations de correspondances entre structures  PAGEREF _Toc72864388 \h 115
 HYPERLINK \l "_Toc72864389" 1.1 Grammaire statique (Chappuy 1983, Vauquois et Chappuy 1985)  PAGEREF _Toc72864389 \h 115
 HYPERLINK \l "_Toc72864390" 1.2 String-Tree Correspondence Grammars « STCG » (Zaharin, 1987)  PAGEREF _Toc72864390 \h 119
 HYPERLINK \l "_Toc72864391" 1.3 Structured String-Tree Correspondences « SSTC » (Boitet & Zaharin, 1988)  PAGEREF _Toc72864391 \h 122
 HYPERLINK \l "_Toc72864392" 1.4 Synchronous SSTC « S-SSTC » (Tang & Mosleh, 1999)  PAGEREF _Toc72864392 \h 126
 HYPERLINK \l "_Toc72864393" 1.5 Grammaire Transductive Syntaxique (Sylvain Kahane 2000)  PAGEREF _Toc72864393 \h 133
 HYPERLINK \l "_Toc72864394" 2. Étude des correspondances UNL-énoncé dans les corpus disponibles  PAGEREF _Toc72864394 \h 138
 HYPERLINK \l "_Toc72864395" 2.1 Présentation des corpus  PAGEREF _Toc72864395 \h 138
 HYPERLINK \l "_Toc72864396" 2.1.1 Babel Tower  PAGEREF _Toc72864396 \h 140
 HYPERLINK \l "_Toc72864397" 2.1.2 Love  PAGEREF _Toc72864397 \h 141
 HYPERLINK \l "_Toc72864398" 2.1.3 Sport  PAGEREF _Toc72864398 \h 141
 HYPERLINK \l "_Toc72864399" 2.1.4 Org-Explorer  PAGEREF _Toc72864399 \h 143
 HYPERLINK \l "_Toc72864400" 2.1.5 Genève 2001  PAGEREF _Toc72864400 \h 145
 HYPERLINK \l "_Toc72864401" 2.1.6 UNL News  PAGEREF _Toc72864401 \h 146
 HYPERLINK \l "_Toc72864402" 2.1.7 FB2004  PAGEREF _Toc72864402 \h 148
 HYPERLINK \l "_Toc72864403" 2.1.8 La main à la pâte  PAGEREF _Toc72864403 \h 150
 HYPERLINK \l "_Toc72864404" 2.1.9 UNL-HEREIN  PAGEREF _Toc72864404 \h 154
 HYPERLINK \l "_Toc72864405" 2.2 Hiérarchie dans la modélisation d’une correspondance graphe-texte  PAGEREF _Toc72864405 \h 157
 HYPERLINK \l "_Toc72864406" 2.2.1 Côté texte: phrase ( mot ( lemme/affixe ( information grammaticale  PAGEREF _Toc72864406 \h 157
 HYPERLINK \l "_Toc72864407" 2.2.2 Côté graphe: graphe/sous-graphe/scope ( arc ( nœud/relation ( UW/restriction/ attribut  PAGEREF _Toc72864407 \h 157
 HYPERLINK \l "_Toc72864408" 2.2.3 Les correspondances identifiées  PAGEREF _Toc72864408 \h 157
 HYPERLINK \l "_Toc72864409" 2.3 Correspondances lexicales  PAGEREF _Toc72864409 \h 158
 HYPERLINK \l "_Toc72864410" 2.3.1 Graphe / mot  PAGEREF _Toc72864410 \h 158
 HYPERLINK \l "_Toc72864411" 2.3.2 Arc / mot  PAGEREF _Toc72864411 \h 158
 HYPERLINK \l "_Toc72864412" 2.3.3 Relation / mot  PAGEREF _Toc72864412 \h 159
 HYPERLINK \l "_Toc72864413" 2.3.4 Nœud + relation / mot  PAGEREF _Toc72864413 \h 159
 HYPERLINK \l "_Toc72864414" 2.3.5 Nœud / mot  PAGEREF _Toc72864414 \h 159
 HYPERLINK \l "_Toc72864415" 2.3.6 UW / mot  PAGEREF _Toc72864415 \h 160
 HYPERLINK \l "_Toc72864416" 2.3.7 Restriction / mot  PAGEREF _Toc72864416 \h 160
 HYPERLINK \l "_Toc72864417" 2.3.8 Attribut / mot  PAGEREF _Toc72864417 \h 160
 HYPERLINK \l "_Toc72864418" 2.4 Correspondances d’attributs  PAGEREF _Toc72864418 \h 161
 HYPERLINK \l "_Toc72864419" 2.4.1 Headword, UW, nœud / lemme  PAGEREF _Toc72864419 \h 161
 HYPERLINK \l "_Toc72864420" 2.4.2 Relation / lemme  PAGEREF _Toc72864420 \h 161
 HYPERLINK \l "_Toc72864421" 2.4.3 Relation / affixe  PAGEREF _Toc72864421 \h 162
 HYPERLINK \l "_Toc72864422" 2.4.4 Relation / information grammaticale  PAGEREF _Toc72864422 \h 162
 HYPERLINK \l "_Toc72864423" 2.4.5 Restriction / information grammaticale  PAGEREF _Toc72864423 \h 162
 HYPERLINK \l "_Toc72864424" 2.4.6 Attribut / information grammaticale  PAGEREF _Toc72864424 \h 163
 HYPERLINK \l "_Toc72864425" 2.5 Correspondances structurales  PAGEREF _Toc72864425 \h 163
 HYPERLINK \l "_Toc72864426" 2.5.1 Graphe entier / phrase entière  PAGEREF _Toc72864426 \h 163
 HYPERLINK \l "_Toc72864427" 2.5.2 Sous-graphe quelconque / sous-chaîne  PAGEREF _Toc72864427 \h 163
 HYPERLINK \l "_Toc72864428" 2.5.3 Scope / sous-chaîne  PAGEREF _Toc72864428 \h 164
 HYPERLINK \l "_Toc72864429" 2.5.4 Arc / sous-chaîne  PAGEREF _Toc72864429 \h 164
 HYPERLINK \l "_Toc72864430" 2.6 Remarques sur les correspondances  PAGEREF _Toc72864430 \h 164
 HYPERLINK \l "_Toc72864431" 3. Formalisation et calcul possible des correspondances graphe-texte  PAGEREF _Toc72864431 \h 165
 HYPERLINK \l "_Toc72864432" 3.1 Contraintes sur la représentation et le calcul des correspondances  PAGEREF _Toc72864432 \h 165
 HYPERLINK \l "_Toc72864433" 3.2 Correspondance entre texte et treillis LMS  PAGEREF _Toc72864433 \h 166
 HYPERLINK \l "_Toc72864434" 3.2.1 Notions de base  PAGEREF _Toc72864434 \h 166
 HYPERLINK \l "_Toc72864435" 3.2.2 Définition formelle et formalisation possible  PAGEREF _Toc72864435 \h 168
 HYPERLINK \l "_Toc72864436" 3.2.3 Structure de données et calcul possible  PAGEREF _Toc72864436 \h 169
 HYPERLINK \l "_Toc72864437" 3.3 Correspondance entre graphe UNL et arbre UNL  PAGEREF _Toc72864437 \h 173
 HYPERLINK \l "_Toc72864438" 3.3.1 Définition formelle et formalisation possible  PAGEREF _Toc72864438 \h 173
 HYPERLINK \l "_Toc72864439" 3.3.2 Description de l’algorithme  PAGEREF _Toc72864439 \h 174
 HYPERLINK \l "_Toc72864440" 3.3.2.1 Graphe simple  PAGEREF _Toc72864440 \h 177
 HYPERLINK \l "_Toc72864441" 3.3.2.2 Graphe non arborescent  PAGEREF _Toc72864441 \h 178
 HYPERLINK \l "_Toc72864442" 3.3.2.3 Graphe avec scope  PAGEREF _Toc72864442 \h 180
 HYPERLINK \l "_Toc72864443" 3.3.3 Structure de données et calcul possible  PAGEREF _Toc72864443 \h 182
 HYPERLINK \l "_Toc72864444" 3.4 Correspondance entre arbre UNL et treillis LMS  PAGEREF _Toc72864444 \h 188
 HYPERLINK \l "_Toc72864445" 3.4.1 Définition formelle et formalisation possible  PAGEREF _Toc72864445 \h 189
 HYPERLINK \l "_Toc72864446" 3.4.2 Étude préliminaire du problème  PAGEREF _Toc72864446 \h 189
 HYPERLINK \l "_Toc72864447" 3.4.3 Description de l’algorithme  PAGEREF _Toc72864447 \h 191
 HYPERLINK \l "_Toc72864448" 3.4.4 Structure de données et calcul possible  PAGEREF _Toc72864448 \h 195
 HYPERLINK \l "_Toc72864449" 3.4.4.1 Définition et détection de croisement  PAGEREF _Toc72864449 \h 195
 HYPERLINK \l "_Toc72864450" 3.4.4.2 Profils de liaisons L23  PAGEREF _Toc72864450 \h 196
 HYPERLINK \l "_Toc72864451" 3.4.4.3 Construction de liaisons lexicales  PAGEREF _Toc72864451 \h 198
 HYPERLINK \l "_Toc72864452" 3.4.4.4 Calcul de pénalité de croisement  PAGEREF _Toc72864452 \h 199
 HYPERLINK \l "_Toc72864453" 3.4.4.5 Enrichir la correspondance et calculer le poids  PAGEREF _Toc72864453 \h 201
 HYPERLINK \l "_Toc72864454" D. Implémentation de la plate-forme SWIIVRE-UNL  PAGEREF _Toc72864454 \h 205
 HYPERLINK \l "_Toc72864455" Introduction  PAGEREF _Toc72864455 \h 205
 HYPERLINK \l "_Toc72864456" 1. Contexte et objectifs  PAGEREF _Toc72864456 \h 207
 HYPERLINK \l "_Toc72864457" 1.1 Objectifs et motivations  PAGEREF _Toc72864457 \h 207
 HYPERLINK \l "_Toc72864458" 1.1.1 Motivations  PAGEREF _Toc72864458 \h 207
 HYPERLINK \l "_Toc72864459" 1.1.2 Cinq objectifs  PAGEREF _Toc72864459 \h 207
 HYPERLINK \l "_Toc72864460" 1.2 Cahier des charges  PAGEREF _Toc72864460 \h 208
 HYPERLINK \l "_Toc72864461" 1.2.1 Aspects généraux  PAGEREF _Toc72864461 \h 208
 HYPERLINK \l "_Toc72864462" 1.2.2 Ressources à récupérer et étapes de la récupération  PAGEREF _Toc72864462 \h 208
 HYPERLINK \l "_Toc72864463" 1.2.3 Descriptions des interactions et sorties  PAGEREF _Toc72864463 \h 208
 HYPERLINK \l "_Toc72864464" 1.3 Type de scénarios d’utilisation  PAGEREF _Toc72864464 \h 209
 HYPERLINK \l "_Toc72864465" 1.3.1 Accès au site  PAGEREF _Toc72864465 \h 209
 HYPERLINK \l "_Toc72864466" 1.3.2 Choix de la langue de commande  PAGEREF _Toc72864466 \h 209
 HYPERLINK \l "_Toc72864467" 1.3.3 Recherche des informations sur UNL  PAGEREF _Toc72864467 \h 210
 HYPERLINK \l "_Toc72864468" 1.3.4 Initiation sur UNL  PAGEREF _Toc72864468 \h 210
 HYPERLINK \l "_Toc72864469" 1.3.5 Essai et expérimentation de graphes UNL  PAGEREF _Toc72864469 \h 210
 HYPERLINK \l "_Toc72864470" 1.3.6 Usage avancé  PAGEREF _Toc72864470 \h 211
 HYPERLINK \l "_Toc72864471" 1.4 Réalisation  PAGEREF _Toc72864471 \h 211
 HYPERLINK \l "_Toc72864472" 1.4.1 Méthodologie  PAGEREF _Toc72864472 \h 211
 HYPERLINK \l "_Toc72864473" 1.4.2 Étape 0 : fonctionnalités statiques de base  PAGEREF _Toc72864473 \h 212
 HYPERLINK \l "_Toc72864474" 1.4.3 Étape I : déconversion multilingue, éditeur UNL de base  PAGEREF _Toc72864474 \h 214
 HYPERLINK \l "_Toc72864475" 1.4.4 Étape II : première réalisation de la maquette de coédition  PAGEREF _Toc72864475 \h 215
 HYPERLINK \l "_Toc72864476" 1.4.5 Étape III : coopération avec « La main à la pâte »  PAGEREF _Toc72864476 \h 217
 HYPERLINK \l "_Toc72864477" 1.5 État courant du site SWIIVRE-UNL (version 3)  PAGEREF _Toc72864477 \h 219
 HYPERLINK \l "_Toc72864478" 2. Implémentation  PAGEREF _Toc72864478 \h 221
 HYPERLINK \l "_Toc72864479" 2.1 Modules sur le site SWIIVRE  PAGEREF _Toc72864479 \h 221
 HYPERLINK \l "_Toc72864480" 2.1.1 Détection de l’état des déconvertisseurs  PAGEREF _Toc72864480 \h 221
 HYPERLINK \l "_Toc72864481" 2.1.2 Test d’un graphe UNL aléatoire  PAGEREF _Toc72864481 \h 223
 HYPERLINK \l "_Toc72864482" 2.1.3 Editeur UNL de base et éditeur UNL graphique  PAGEREF _Toc72864482 \h 224
 HYPERLINK \l "_Toc72864483" 2.1.4 Déconvertisseur multilingue synchrone  PAGEREF _Toc72864483 \h 227
 HYPERLINK \l "_Toc72864484" 2.1.5 Consultation de dictionnaires UNL-LN  PAGEREF _Toc72864484 \h 230
 HYPERLINK \l "_Toc72864485" 2.1.6 XML-isation de documents UNL  PAGEREF _Toc72864485 \h 230
 HYPERLINK \l "_Toc72864486" 2.1.6.1 Document UNL-xml  PAGEREF _Toc72864486 \h 231
 HYPERLINK \l "_Toc72864487" 2.1.6.2 Visualisation d’un document UNL-xml  PAGEREF _Toc72864487 \h 234
 HYPERLINK \l "_Toc72864488" 2.1.7 Documents UNL sur le web  PAGEREF _Toc72864488 \h 238
 HYPERLINK \l "_Toc72864489" 2.2 Maquette de coédition  PAGEREF _Toc72864489 \h 242
 HYPERLINK \l "_Toc72864490" 2.2.1 Évolution de la maquette  PAGEREF _Toc72864490 \h 242
 HYPERLINK \l "_Toc72864491" 2.2.2 Introduction à la version ²  PAGEREF _Toc72864491 \h 243
 HYPERLINK \l "_Toc72864492" 2.2.3 Architecture interne et classes principales  PAGEREF _Toc72864492 \h 252
 HYPERLINK \l "_Toc72864493" 2.2.4 Évaluation et points à améliorer dans la version ² de la maquette  PAGEREF _Toc72864493 \h 254
 HYPERLINK \l "_Toc72864494" 2.2.5 Quelques mots sur la proposition de correction  PAGEREF _Toc72864494 \h 254
 HYPERLINK \l "_Toc72864495" 2.2.6 Nouvelle maquette  PAGEREF _Toc72864495 \h 256
 HYPERLINK \l "_Toc72864496" 3. Bilan et conclusion  PAGEREF _Toc72864496 \h 258
 HYPERLINK \l "_Toc72864497" 3.1 Amélioration dans la nouvelle déconversion  PAGEREF _Toc72864497 \h 258
 HYPERLINK \l "_Toc72864498" 3.2 Conclusion  PAGEREF _Toc72864498 \h 262
 HYPERLINK \l "_Toc72864499" Conclusion  PAGEREF _Toc72864499 \h 263
 HYPERLINK \l "_Toc72864500" Rappel de la situation et du problème  PAGEREF _Toc72864500 \h 263
 HYPERLINK \l "_Toc72864501" Apports de cette thèse  PAGEREF _Toc72864501 \h 263
 HYPERLINK \l "_Toc72864502" Perspectives de recherche  PAGEREF _Toc72864502 \h 264
 HYPERLINK \l "_Toc72864503" Bibliographie  PAGEREF _Toc72864503 \h 267
 HYPERLINK \l "_Toc72864504" Signets  PAGEREF _Toc72864504 \h 281
 HYPERLINK \l "_Toc72864505" Annexe A : Spécifications d’UNL  PAGEREF _Toc72864505 \h 283
 HYPERLINK \l "_Toc72864506" Syntaxe d’un document UNL en expression BNF (UNL-html.1)  PAGEREF _Toc72864506 \h 283
 HYPERLINK \l "_Toc72864507" Syntaxe d’UW en EBNF (Extended BNF, BNF étendue)  PAGEREF _Toc72864507 \h 284
 HYPERLINK \l "_Toc72864508" Syntaxe des relations binaires en EBNF  PAGEREF _Toc72864508 \h 284
 HYPERLINK \l "_Toc72864509" Liste des relations UNL  PAGEREF _Toc72864509 \h 285
 HYPERLINK \l "_Toc72864510" Liste d’attributs  PAGEREF _Toc72864510 \h 286
 HYPERLINK \l "_Toc72864511" Annexe B : DTD et schéma d’UNL-xml  PAGEREF _Toc72864511 \h 291
 HYPERLINK \l "_Toc72864512" DTD d’UNL-xml  PAGEREF _Toc72864512 \h 291
 HYPERLINK \l "_Toc72864513" schéma d’UNL-XML  PAGEREF _Toc72864513 \h 292
 HYPERLINK \l "_Toc72864514" Annexe C : Corpus UNL  PAGEREF _Toc72864514 \h 296
 HYPERLINK \l "_Toc72864515" Exemple d’un document UNL-xml  PAGEREF _Toc72864515 \h 296
 HYPERLINK \l "_Toc72864516" Annexe D : Variables de PILAF et AUTOTAG  PAGEREF _Toc72864516 \h 298
 HYPERLINK \l "_Toc72864517" Table des catégories morphosyntaxiques de Pilaf  PAGEREF _Toc72864517 \h 298
 HYPERLINK \l "_Toc72864518" Table des variables morphologiques de Pilaf  PAGEREF _Toc72864518 \h 299
 HYPERLINK \l "_Toc72864519" Variables syntaxiques  PAGEREF _Toc72864519 \h 299
 HYPERLINK \l "_Toc72864520" Exemple de sortie de PILAF  PAGEREF _Toc72864520 \h 299
 HYPERLINK \l "_Toc72864521" Table de catégories du chinois moderne (utilisé par « AUTOTAG »)  PAGEREF _Toc72864521 \h 300
 HYPERLINK \l "_Toc72864522" Table de catégories du segmenteur AUTOTAG  PAGEREF _Toc72864522 \h 301
 HYPERLINK \l "_Toc72864523" Annexe E : Page extraite du dictionnaire unl-geta_fr_unl.unl  PAGEREF _Toc72864523 \h 303
 HYPERLINK \l "_Toc72864524" Annexe F : Exemple complet de planche de grammaire statique  PAGEREF _Toc72864524 \h 305
 HYPERLINK \l "_Toc72864525" Annexe H : Exemple complet de l’ILT de KBMT-89  PAGEREF _Toc72864525 \h 307



Liste des figures

 TOC \h \z \c "Fig."  HYPERLINK \l "_Toc72866657" Fig. A1 Partage de révision  PAGEREF _Toc72866657 \h 10
 HYPERLINK \l "_Toc72866658" Fig. A2 Interface (HyperCard) de démarrage de LIDIA-I  PAGEREF _Toc72866658 \h 12
 HYPERLINK \l "_Toc72866659" Fig. A3 Organisation générale du processus de traduction en LIDIA-I  PAGEREF _Toc72866659 \h 13
 HYPERLINK \l "_Toc72866660" Fig. A4 Dialogue avec paraphrasage et accès à des explications  PAGEREF _Toc72866660 \h 14
 HYPERLINK \l "_Toc72866661" Fig. A5 Explications pour l’ambiguïté de construction argumentaire du verbe  PAGEREF _Toc72866661 \h 14
 HYPERLINK \l "_Toc72866662" Fig. A6 Image de MODEX  PAGEREF _Toc72866662 \h 16
 HYPERLINK \l "_Toc72866663" Fig. A7 Interface de DRAFTER  PAGEREF _Toc72866663 \h 17
 HYPERLINK \l "_Toc72866664" Fig. A8 Ambassador vue I – Edition d’une lettre de « demande d’enquête »  PAGEREF _Toc72866664 \h 19
 HYPERLINK \l "_Toc72866665" Fig. A9 Ambassador vue II – choix au côté japonais  PAGEREF _Toc72866665 \h 19
 HYPERLINK \l "_Toc72866666" Fig. A10 Début d’édition d’un document (système WYSIWYM)  PAGEREF _Toc72866666 \h 21
 HYPERLINK \l "_Toc72866667" Fig. A11 Fin d'édition d'un document (système WYSIWYM)  PAGEREF _Toc72866667 \h 22
 HYPERLINK \l "_Toc72866668" Fig. A12 Interface de Multimétéo  PAGEREF _Toc72866668 \h 24
 HYPERLINK \l "_Toc72866669" Fig. A13 Procédure d’édition du système Multimétéo  PAGEREF _Toc72866669 \h 24
 HYPERLINK \l "_Toc72866670" Fig. A14 Structure générale du système Multimétéo  PAGEREF _Toc72866670 \h 25
 HYPERLINK \l "_Toc72866671" Fig. A15 Interface de MDA  PAGEREF _Toc72866671 \h 26
 HYPERLINK \l "_Toc72866672" Fig. A16 Interface du système PILAF  PAGEREF _Toc72866672 \h 34
 HYPERLINK \l "_Toc72866673" Fig. A17 Interface du système Autotag  PAGEREF _Toc72866673 \h 36
 HYPERLINK \l "_Toc72866674" Fig. A18 Sortie de MeCab  PAGEREF _Toc72866674 \h 37
 HYPERLINK \l "_Toc72866675" Fig. A19 Analyse d’une phrase française en représentation par treillis  PAGEREF _Toc72866675 \h 38
 HYPERLINK \l "_Toc72866676" Fig. A20 Sortie de MeCab en représentation par treillis  PAGEREF _Toc72866676 \h 39
 HYPERLINK \l "_Toc72866677" Fig. A21 Analyse d’une phrase chinoise en représentation par treillis  PAGEREF _Toc72866677 \h 39
 HYPERLINK \l "_Toc72866678" Fig. B1 Architecture « pivot » d’un système de TA  PAGEREF _Toc72866678 \h 45
 HYPERLINK \l "_Toc72866679" Fig. B2 Système idéal à pivot  PAGEREF _Toc72866679 \h 46
 HYPERLINK \l "_Toc72866680" Fig. B3 Arbre d’analyse multiniveau  PAGEREF _Toc72866680 \h 51
 HYPERLINK \l "_Toc72866681" Fig. B4 Structure de TITUS-IV  PAGEREF _Toc72866681 \h 52
 HYPERLINK \l "_Toc72866682" Fig. B5 Correction de dépendance dans le système PIVOT  PAGEREF _Toc72866682 \h 57
 HYPERLINK \l "_Toc72866683" Fig. B6 Correction de cas sémantique dans le système PIVOT  PAGEREF _Toc72866683 \h 58
 HYPERLINK \l "_Toc72866684" Fig. B7 Structure du système KBMT-89  PAGEREF _Toc72866684 \h 64
 HYPERLINK \l "_Toc72866685" Fig. B8 Interaction entre utilisateur et système KBMT-89  PAGEREF _Toc72866685 \h 65
 HYPERLINK \l "_Toc72866686" Fig. B9 Procédure de traduction du système KBMT-89  PAGEREF _Toc72866686 \h 68
 HYPERLINK \l "_Toc72866687" Fig. B10 Structure de Nespole!  PAGEREF _Toc72866687 \h 73
 HYPERLINK \l "_Toc72866688" Fig. B11 Serveur HLT spécifique de Nespole!  PAGEREF _Toc72866688 \h 73
 HYPERLINK \l "_Toc72866689" Fig. B12 Enconversion et déconversion avec UNL  PAGEREF _Toc72866689 \h 77
 HYPERLINK \l "_Toc72866690" Fig. B13 Structure du système UNL  PAGEREF _Toc72866690 \h 78
 HYPERLINK \l "_Toc72866691" Fig. B14 Exemple d’un graphe UNL complet  PAGEREF _Toc72866691 \h 80
 HYPERLINK \l "_Toc72866692" Fig. B15 Cadre de « Master Definition »  PAGEREF _Toc72866692 \h 81
 HYPERLINK \l "_Toc72866693" Fig. B16 Héritage de «Master Definition »  PAGEREF _Toc72866693 \h 81
 HYPERLINK \l "_Toc72866694" Fig. B17 Représentation graphique d’un graphe UNL  PAGEREF _Toc72866694 \h 82
 HYPERLINK \l "_Toc72866695" Fig. B18 Document « UNL-html »  PAGEREF _Toc72866695 \h 87
 HYPERLINK \l "_Toc72866696" Fig. B19 La KB présentée sur le site du centre UNL  PAGEREF _Toc72866696 \h 89
 HYPERLINK \l "_Toc72866697" Fig. B20 Éditeur UNL de l’équipe indonésienne (I)  PAGEREF _Toc72866697 \h 90
 HYPERLINK \l "_Toc72866698" Fig. B21 Éditeur UNL de l’équipe indonésienne (II)  PAGEREF _Toc72866698 \h 91
 HYPERLINK \l "_Toc72866699" Fig. B22 Vérificateur UNL  PAGEREF _Toc72866699 \h 92
 HYPERLINK \l "_Toc72866700" Fig. B23 UNL proxy  PAGEREF _Toc72866700 \h 92
 HYPERLINK \l "_Toc72866701" Fig. B24- Scope avec arc allant vers l'extérieur  PAGEREF _Toc72866701 \h 96
 HYPERLINK \l "_Toc72866702" Fig. B25 Un document UNL-html.1  PAGEREF _Toc72866702 \h 101
 HYPERLINK \l "_Toc72866703" Fig. B26 Structure d’un document UNL-html.1  PAGEREF _Toc72866703 \h 102
 HYPERLINK \l "_Toc72866704" Fig. B27 Un document UNL-html.2 sous Notepad  PAGEREF _Toc72866704 \h 103
 HYPERLINK \l "_Toc72866705" Fig. B28 Un document UNL-html.2 sous Internet Explorer  PAGEREF _Toc72866705 \h 103
 HYPERLINK \l "_Toc72866706" Fig. B29 Structure du visualiseur « UNL Viewer »  PAGEREF _Toc72866706 \h 104
 HYPERLINK \l "_Toc72866707" Fig. B30 Interface du visualiseur « UNL Viewer »  PAGEREF _Toc72866707 \h 105
 HYPERLINK \l "_Toc72866708" Fig. B31 Configuration du visualiseur « UNL Viewer »  PAGEREF _Toc72866708 \h 106
 HYPERLINK \l "_Toc72866709" Fig. B32 Configuration du déconvertisseur français  PAGEREF _Toc72866709 \h 106
 HYPERLINK \l "_Toc72866710" Fig. B33 Visualisation en chinois sous « UNL Viewer »  PAGEREF _Toc72866710 \h 107
 HYPERLINK \l "_Toc72866711" Fig. C1 Zone 1 de Grammaire Statique  PAGEREF _Toc72866711 \h 116
 HYPERLINK \l "_Toc72866712" Fig. C2 Zone 2 de Grammaire Statique  PAGEREF _Toc72866712 \h 116
 HYPERLINK \l "_Toc72866713" Fig. C3 Première partie d’une zone 3 de Grammaire Statique  PAGEREF _Toc72866713 \h 117
 HYPERLINK \l "_Toc72866714" Fig. C4 Deuxième partie d’une zone 3 de Grammaire Statique  PAGEREF _Toc72866714 \h 117
 HYPERLINK \l "_Toc72866715" Fig. C5 En-tête d’une planche  PAGEREF _Toc72866715 \h 117
 HYPERLINK \l "_Toc72866716" Fig. C6 Hiérarchie des planches  PAGEREF _Toc72866716 \h 118
 HYPERLINK \l "_Toc72866717" Fig. C7 Utilisation idéale d’une GS pour construire des analyseurs  PAGEREF _Toc72866717 \h 118
 HYPERLINK \l "_Toc72866718" Fig. C8 Mise au point d’un analyseur à la main  PAGEREF _Toc72866718 \h 119
 HYPERLINK \l "_Toc72866719" Fig. C9 Une planche de STCG  PAGEREF _Toc72866719 \h 120
 HYPERLINK \l "_Toc72866720" Fig. C10 Syntaxe d’une règle de STCG  PAGEREF _Toc72866720 \h 120
 HYPERLINK \l "_Toc72866721" Fig. C11 3 planches de STCG pour le groupe nominal  PAGEREF _Toc72866721 \h 121
 HYPERLINK \l "_Toc72866722" Fig. C12 Correspondance dans un cas de fusion de deux nœuds  PAGEREF _Toc72866722 \h 122
 HYPERLINK \l "_Toc72866723" Fig. C13 Correspondance dans le cas d’une élision  PAGEREF _Toc72866723 \h 123
 HYPERLINK \l "_Toc72866724" Fig. C14 Dépendance croisée  PAGEREF _Toc72866724 \h 124
 HYPERLINK \l "_Toc72866725" Fig. C15 Dépendance croisée et fusion des nœuds  PAGEREF _Toc72866725 \h 124
 HYPERLINK \l "_Toc72866726" Fig. C16 Exemple de SSTC pour une correspondance non-standard  PAGEREF _Toc72866726 \h 125
 HYPERLINK \l "_Toc72866727" Fig. C17 SSTC pour un arbre syntagmatique  PAGEREF _Toc72866727 \h 126
 HYPERLINK \l "_Toc72866728" Fig. C18 Quelques correspondances non-standard entre deux langues  PAGEREF _Toc72866728 \h 127
 HYPERLINK \l "_Toc72866729" Fig. C19 Exemple de S-SSTC  PAGEREF _Toc72866729 \h 128
 HYPERLINK \l "_Toc72866730" Fig. C20 S-SSTC pour une correspondance non-injective  PAGEREF _Toc72866730 \h 129
 HYPERLINK \l "_Toc72866731" Fig. C21 S-SSTC pour l’inversion de dépendance  PAGEREF _Toc72866731 \h 129
 HYPERLINK \l "_Toc72866732" Fig. C22 S-SSTC pour l’élimination de dépendance  PAGEREF _Toc72866732 \h 130
 HYPERLINK \l "_Toc72866733" Fig. C23 S-SSTC pour un élément discontinu  PAGEREF _Toc72866733 \h 131
 HYPERLINK \l "_Toc72866734" Fig. C24 S-SSTC d’un exemple de MSR  PAGEREF _Toc72866734 \h 132
 HYPERLINK \l "_Toc72866735" Fig. C25 Editeur de S-SSTC (I)  PAGEREF _Toc72866735 \h 133
 HYPERLINK \l "_Toc72866736" Fig. C26 Editeur de S-SSTC (II)  PAGEREF _Toc72866736 \h 133
 HYPERLINK \l "_Toc72866737" Fig. C27 Trois niveaux de représentations dans la TST  PAGEREF _Toc72866737 \h 134
 HYPERLINK \l "_Toc72866738" Fig. C28 Deux structures de « Peter eats red beans »  PAGEREF _Toc72866738 \h 135
 HYPERLINK \l "_Toc72866739" Fig. C29 Règles de ”0 dans le style de la TST  PAGEREF _Toc72866739 \h 135
 HYPERLINK \l "_Toc72866740" Fig. C30 G0 utilisée comme grammaire transductive en synthèse  PAGEREF _Toc72866740 \h 136
 HYPERLINK \l "_Toc72866741" Fig. C31 G0 utilisée comme grammaire transductive en analyse  PAGEREF _Toc72866741 \h 136
 HYPERLINK \l "_Toc72866742" Fig. C32 Trois patrons dans la « Pattern-Based Translation » de Takeda  PAGEREF _Toc72866742 \h 137
 HYPERLINK \l "_Toc72866743" Fig. C33 Interface de Watanabe pour présenter la correspondance entre deux arbres  PAGEREF _Toc72866743 \h 138
 HYPERLINK \l "_Toc72866744" Fig. C34 Structure d’Org-Explorer  PAGEREF _Toc72866744 \h 143
 HYPERLINK \l "_Toc72866745" Fig. C35 Org-Information sous Notepad  PAGEREF _Toc72866745 \h 144
 HYPERLINK \l "_Toc72866746" Fig. C36 Corpus Org-Information en format UNL-xml sous Notepad  PAGEREF _Toc72866746 \h 144
 HYPERLINK \l "_Toc72866747" Fig. C37 Page d’accueil de UNL News  PAGEREF _Toc72866747 \h 147
 HYPERLINK \l "_Toc72866748" Fig. C38 Page d’accueil du projet FB2004  PAGEREF _Toc72866748 \h 149
 HYPERLINK \l "_Toc72866749" Fig. C39 Page d’accueil du site « La main à la pâte »  PAGEREF _Toc72866749 \h 151
 HYPERLINK \l "_Toc72866750" Fig. C40 page web de « European Heritage » à encoder en UNL  PAGEREF _Toc72866750 \h 155
 HYPERLINK \l "_Toc72866751" Fig. C41 Page correspondant à l’extrait du corpus  PAGEREF _Toc72866751 \h 155
 HYPERLINK \l "_Toc72866752" Fig. C42 Graphe UNL de l’exemple (I)  PAGEREF _Toc72866752 \h 167
 HYPERLINK \l "_Toc72866753" Fig. C43 Graphe UNL de l’exemple (II) avec deux nœuds « sea »  PAGEREF _Toc72866753 \h 168
 HYPERLINK \l "_Toc72866754" Fig. C44 Sortie de PILAF de l’exemple (I)  PAGEREF _Toc72866754 \h 170
 HYPERLINK \l "_Toc72866755" Fig. C45 Sortie de PILAF de l’exemple (II)  PAGEREF _Toc72866755 \h 170
 HYPERLINK \l "_Toc72866756" Fig. C46 Treillis étendu exemple (I)  PAGEREF _Toc72866756 \h 172
 HYPERLINK \l "_Toc72866757" Fig. C47 Treillis étendu exemple (II)  PAGEREF _Toc72866757 \h 172
 HYPERLINK \l "_Toc72866758" Fig. C48 L12 de l’exemple (I)  PAGEREF _Toc72866758 \h 173
 HYPERLINK \l "_Toc72866759" Fig. C49 Procédure pour la déconversion UNL(français  PAGEREF _Toc72866759 \h 174
 HYPERLINK \l "_Toc72866760" Fig. C50 Arbre ARIANE-G5 et étiquettes des nœuds  PAGEREF _Toc72866760 \h 175
 HYPERLINK \l "_Toc72866761" Fig. C51 algorithme de transformation d’un graphe UNL en un arbre UNL (d’après G. Sérasset)  PAGEREF _Toc72866761 \h 176
 HYPERLINK \l "_Toc72866762" Fig. C52 Inversion d’un arc (z –> z-1) et duplication d’un nœud (c)  PAGEREF _Toc72866762 \h 176
 HYPERLINK \l "_Toc72866763" Fig. C53 Transformation d’un graphe UNL simple en un arbre ARIANE  PAGEREF _Toc72866763 \h 177
 HYPERLINK \l "_Toc72866764" Fig. C54 Transformation d’un graphe UNL non arborescent en un arbre ARIANE  PAGEREF _Toc72866764 \h 179
 HYPERLINK \l "_Toc72866765" Fig. C55 Transformation d’un graphe UNL avec scope (en haut) en un arbre ARIANE (en bas)  PAGEREF _Toc72866765 \h 181
 HYPERLINK \l "_Toc72866766" Fig. C56 Graphe UNL avec les arcs et les nœuds numérotés exemple (I)  PAGEREF _Toc72866766 \h 183
 HYPERLINK \l "_Toc72866767" Fig. C57 Graphe UNL avec les arcs et les nœuds numérotés exemple (II)  PAGEREF _Toc72866767 \h 184
 HYPERLINK \l "_Toc72866768" Fig. C58 Arbre UNL francisé numéroté exempls (I)  PAGEREF _Toc72866768 \h 186
 HYPERLINK \l "_Toc72866769" Fig. C59 Arbre UNL francisé numéroté exempls (II)  PAGEREF _Toc72866769 \h 186
 HYPERLINK \l "_Toc72866770" Fig. C60 L34 de l’exemple (I)  PAGEREF _Toc72866770 \h 187
 HYPERLINK \l "_Toc72866771" Fig. C61 L34 de l’exemple (II)  PAGEREF _Toc72866771 \h 188
 HYPERLINK \l "_Toc72866772" Fig. C62 Un graphe UNL assez compliqué  PAGEREF _Toc72866772 \h 190
 HYPERLINK \l "_Toc72866773" Fig. C63 Trajectoires provisoires de l’exemple (II)  PAGEREF _Toc72866773 \h 192
 HYPERLINK \l "_Toc72866774" Fig. C64 Arbre de recherche  PAGEREF _Toc72866774 \h 192
 HYPERLINK \l "_Toc72866775" Fig. C65 Liaisons lexicales (I), pénalité de croisement = 2  PAGEREF _Toc72866775 \h 193
 HYPERLINK \l "_Toc72866776" Fig. C66 Liaisons lexicales (II), pénalité de croisement = 5  PAGEREF _Toc72866776 \h 193
 HYPERLINK \l "_Toc72866777" Fig. C67 Trajectoires provisoires de l’exemple (I)  PAGEREF _Toc72866777 \h 194
 HYPERLINK \l "_Toc72866778" Fig. C68 Croisement dans la correspondance arbre – chaîne (I)  PAGEREF _Toc72866778 \h 195
 HYPERLINK \l "_Toc72866779" Fig. C69 Croisement dans la correspondance arbre – chaîne (II)  PAGEREF _Toc72866779 \h 196
 HYPERLINK \l "_Toc72866780" Fig. C70 Structures des nœuds de treillis et d’arbre  PAGEREF _Toc72866780 \h 198
 HYPERLINK \l "_Toc72866781" Fig. C71 Correspondance enrichie  PAGEREF _Toc72866781 \h 203
 HYPERLINK \l "_Toc72866782" Fig. C72 Procédure pour établir la correspondance texte - graphe UNL  PAGEREF _Toc72866782 \h 204
 HYPERLINK \l "_Toc72866783" Fig. D1 Interface du site SWIIVRE (version 1)  PAGEREF _Toc72866783 \h 213
 HYPERLINK \l "_Toc72866784" Fig. D2 Déconvertisseur multilingue synchrone  PAGEREF _Toc72866784 \h 214
 HYPERLINK \l "_Toc72866785" Fig. D3 Interface de l’éditeur UNL de base  PAGEREF _Toc72866785 \h 215
 HYPERLINK \l "_Toc72866786" Fig. D4 Applet de coédition  PAGEREF _Toc72866786 \h 216
 HYPERLINK \l "_Toc72866787" Fig. D5 Page d’accueil de SWIIVRE-UNL (version 2)  PAGEREF _Toc72866787 \h 217
 HYPERLINK \l "_Toc72866788" Fig. D6 Editeur UNL graphique  PAGEREF _Toc72866788 \h 219
 HYPERLINK \l "_Toc72866789" Fig. D7 Tester les états des déconvertisseurs  PAGEREF _Toc72866789 \h 221
 HYPERLINK \l "_Toc72866790" Fig. D8 Statistiques sur les déconvertisseurs  PAGEREF _Toc72866790 \h 223
 HYPERLINK \l "_Toc72866791" Fig. D9 Structure de l’éditeur UNL de base  PAGEREF _Toc72866791 \h 225
 HYPERLINK \l "_Toc72866792" Fig. D10 Information sur un nœud  PAGEREF _Toc72866792 \h 226
 HYPERLINK \l "_Toc72866793" Fig. D11 Génération du format UNL-xml  PAGEREF _Toc72866793 \h 226
 HYPERLINK \l "_Toc72866794" Fig. D12 UW proposées par l’éditeur UNL graphique  PAGEREF _Toc72866794 \h 227
 HYPERLINK \l "_Toc72866795" Fig. D13 Structure du déconvertisseur multilingue synchrone  PAGEREF _Toc72866795 \h 228
 HYPERLINK \l "_Toc72866796" Fig. D14 Déconvertisseur multilingue synchrone  PAGEREF _Toc72866796 \h 229
 HYPERLINK \l "_Toc72866797" Fig. D15 Résultat de déconversion multilingue synchrone  PAGEREF _Toc72866797 \h 229
 HYPERLINK \l "_Toc72866798" Fig. D16 Consultation du dictionnaire UNL-russe  PAGEREF _Toc72866798 \h 230
 HYPERLINK \l "_Toc72866799" Fig. D17 Structure d’un document UNL-xml.1  PAGEREF _Toc72866799 \h 231
 HYPERLINK \l "_Toc72866800" Fig. D18 document UNL-xml.2 visualisé tel quel  PAGEREF _Toc72866800 \h 232
 HYPERLINK \l "_Toc72866801" Fig. D19 un document UNL-xml.2 visualisé par IE.6  PAGEREF _Toc72866801 \h 233
 HYPERLINK \l "_Toc72866802" Fig. D20 document UNL-xml.2 balisé plus en détail pour la maquette de coédition  PAGEREF _Toc72866802 \h 234
 HYPERLINK \l "_Toc72866803" Fig. D21 Structure du visualiseur UNL-xml  PAGEREF _Toc72866803 \h 235
 HYPERLINK \l "_Toc72866804" Fig. D22 Visualisation d’un document UNL-xml en thaï  PAGEREF _Toc72866804 \h 235
 HYPERLINK \l "_Toc72866805" Fig. D23 Visualisation d’un document UNL-xml en arabe  PAGEREF _Toc72866805 \h 236
 HYPERLINK \l "_Toc72866806" Fig. D24 Visualisation d’un document UNL-xml entier  PAGEREF _Toc72866806 \h 236
 HYPERLINK \l "_Toc72866807" Fig. D25 Transformation d’un document UNL-html.1 en UNL-xml.2  PAGEREF _Toc72866807 \h 239
 HYPERLINK \l "_Toc72866808" Fig. D26 Résultat : document UNL-xml.2  PAGEREF _Toc72866808 \h 240
 HYPERLINK \l "_Toc72866809" Fig. D27 Première interface de coédition  PAGEREF _Toc72866809 \h 242
 HYPERLINK \l "_Toc72866810" Fig. D28 Documents UNL-xml à choisir  PAGEREF _Toc72866810 \h 244
 HYPERLINK \l "_Toc72866811" Fig. D29 Lecture en français d’un document UNL-xml multilingue  PAGEREF _Toc72866811 \h 244
 HYPERLINK \l "_Toc72866812" Fig. D30 Sélection d’un fragment à coéditer  PAGEREF _Toc72866812 \h 245
 HYPERLINK \l "_Toc72866813" Fig. D31 État initial de la coédition de trois phrases  PAGEREF _Toc72866813 \h 246
 HYPERLINK \l "_Toc72866814" Fig. D32 Trois cadres dans l’environnement de coédition  PAGEREF _Toc72866814 \h 246
 HYPERLINK \l "_Toc72866815" Fig. D33 Choix de visualisation des autres langues  PAGEREF _Toc72866815 \h 247
 HYPERLINK \l "_Toc72866816" Fig. D34 Insertion manuelle  PAGEREF _Toc72866816 \h 247
 HYPERLINK \l "_Toc72866817" Fig. D35 Modifications possibles proposées par le système  PAGEREF _Toc72866817 \h 248
 HYPERLINK \l "_Toc72866818" Fig. D36 Modification faite  PAGEREF _Toc72866818 \h 248
 HYPERLINK \l "_Toc72866819" Fig. D37 Récupération de la nouvelle déconversion  PAGEREF _Toc72866819 \h 249
 HYPERLINK \l "_Toc72866820" Fig. D38 Propositions pour modifier un verbe  PAGEREF _Toc72866820 \h 250
 HYPERLINK \l "_Toc72866821" Fig. D39 Lecture de nouveau texte  PAGEREF _Toc72866821 \h 250
 HYPERLINK \l "_Toc72866822" Fig. D40 Déconversion vers espagnol  PAGEREF _Toc72866822 \h 251
 HYPERLINK \l "_Toc72866823" Fig. D41 Vue générale de la maquette  PAGEREF _Toc72866823 \h 252
 HYPERLINK \l "_Toc72866824" Fig. D42 Page web principale du serveur de déconvertisseur UNL-français  PAGEREF _Toc72866824 \h 256
 HYPERLINK \l "_Toc72866825" Fig. D43 Vue générale de la nouvelle maquette  PAGEREF _Toc72866825 \h 258


Liste des tableaux

 TOC \h \z \c "Tableau"  HYPERLINK \l "_Toc73625028" Tableau A1 Taxonomie de la coédition  PAGEREF _Toc73625028 \h 28
 HYPERLINK \l "_Toc73625029" Tableau A2 Taxonomie des systèmes étudiés  PAGEREF _Toc73625029 \h 29
 HYPERLINK \l "_Toc73625030" Tableau A3 Outils gratuits de traitement de langues naturelles sur Internet  PAGEREF _Toc73625030 \h 41
 HYPERLINK \l "_Toc73625031" Tableau B1 Relations semantiques du système ATLAS-II  PAGEREF _Toc73625031 \h 55
 HYPERLINK \l "_Toc73625032" Tableau B2 Exempls d’IF  PAGEREF _Toc73625032 \h 75
 HYPERLINK \l "_Toc73625033" Tableau B3 Table pour l’échange d’UW dans projet FB2004  PAGEREF _Toc73625033 \h 100
 HYPERLINK \l "_Toc73625034" Tableau C1 Corpus UNL traités  PAGEREF _Toc73625034 \h 139
 HYPERLINK \l "_Toc73625035" Tableau C2 Types de correspondance entre graphe UNL et LN  PAGEREF _Toc73625035 \h 158
 HYPERLINK \l "_Toc73625036" Tableau C3 Notions de base pour les correspondances texte-graphe UNL  PAGEREF _Toc73625036 \h 167
 HYPERLINK \l "_Toc73625037" Tableau C4 Définitions formelles pour les correspondances texte-treillis  PAGEREF _Toc73625037 \h 169
 HYPERLINK \l "_Toc73625038" Tableau C5 Table de compatibilité pour treillis étendu  PAGEREF _Toc73625038 \h 171
 HYPERLINK \l "_Toc73625039" Tableau C6 Définitions formelles pour les correspondances graphe-arbre  PAGEREF _Toc73625039 \h 174
 HYPERLINK \l "_Toc73625040" Tableau C7 Table de compatibilité pour arbre étendu  PAGEREF _Toc73625040 \h 185
 HYPERLINK \l "_Toc73625041" Tableau C8 Définition formelle de la correspondance arbre-treillis  PAGEREF _Toc73625041 \h 189
 HYPERLINK \l "_Toc73625042" Tableau C9 Types de correspondance entre le français et le graphe UNL  PAGEREF _Toc73625042 \h 197
 HYPERLINK \l "_Toc73625043" Tableau C10 Table de compatibilité  PAGEREF _Toc73625043 \h 202
 HYPERLINK \l "_Toc73625044" Tableau C11 Liste des liaisons trouvées  PAGEREF _Toc73625044 \h 203
 HYPERLINK \l "_Toc73625045" Tableau D1 Fonctionnalités du site web SWIIVRE  PAGEREF _Toc73625045 \h 220
 HYPERLINK \l "_Toc73625046" Tableau D2 Formats de document UNL  PAGEREF _Toc73625046 \h 232
 HYPERLINK \l "_Toc73625047" Tableau D3 Propagation de modifications  PAGEREF _Toc73625047 \h 260




Introduction
Situation et motivations
Il est de plus en plus nécessaire de créer et de maintenir des documents multilingues. Nous pensons surtout aux entreprises internationales comme HP, Cisco, Bull, Aix, etc. qui ont le besoin de communiquer avec le grand public en plusieurs langues. Par exemple, HP a 200.000 notices en anglais sur son site web, et Cisco produit 40.000 pages de documents chaque mois en langues CJK (chinois, japonais, coréen). Pour le maintien de ces documents multilingues et la gestion de versions, A. Assimi [Assimi 00] a montré comment « réaligner » des documents parallèles décentralisés et leur appliquer ensuite sa méthodologie de production d’un nouvel original en langue source, et de traduction vers les langues cibles des parties modifiées.
Le problème général reste : aussi bien les traductions que les révisions ont un coût croissant linéairement en fonction du nombre de langues. Cela reste vrai même si on se limite, dans le cas de l’évolution de documents multilingues, à ne retraduire (et donc réviser) que les parties qui ont changé.
Ce que nous aimerions, c’est produire ces documents multilingues par la TA, et faire en sorte que le travail de révision puisse être partagé entre les langues, quels que soient le domaine et le contexte.
Nos trois idées principales sont :
(1) Mutualisation et collaboration : les utilisateurs révisent sur Internet une bonne partie des textes de documents multilingues traduits par la machine. Nous visons la révision et l’amélioration de la communication multilingue écrite sur Internet, dans un domaine ouvert, où la qualité de traduction peut être non-professionnelle.
(2) Révision à la demande : on ne révise pas tout, mais seulement le plus important, c’est-à-dire les endroits où l’utilisateur pense que cela en vaut la peine.
(3) Partage de la révision entre les différentes langues : c’est le problème le plus difficile mais avec une grande économie potentielle.
Bien sûr, on ne peut pas garantir la qualité de la révision faite par un utilisateur quelconque, mais on peut limiter le type de correction si on construit un environnement « guidé ». Dans la pratique, il n’est pas nécessaire que la qualité d’un document traduit soit uniforme. C’est pourquoi nous proposons de faire la révision « à la demande ».
Il est clairement impossible de refléter les changements sur un fichier en langue L0 dans les fichiers en langues L1,… Ln automatiquement et fidèlement, sans une structure intermédiaire pour faire le pont, car il faudrait au moins un aligneur parfait à granularité très fine dans le cas simple d'un changement d'article ou de nom (et encore, en supposant que le genre et le nombre restent les mêmes dans chaque version Li). Dans le cas du remplacement d'un verbe par un autre verbe ayant un régime différent dans une langue cible Li, il faudrait réanalyser la phrase en Li, la transformer en conséquence, et la regénérer sans introduire de nouvelle erreur ou imprécision, tout en gardant les améliorations manuelles éventuellement apportées lors de révisions précédentes. Ou bien, il faudrait disposer d'un système de TA plus que parfait, à savoir capable d'analyser l'énoncé modifié en L0, de le transférer, et de générer un énoncé aussi proche que possible de l'énoncé précédent en Li, toujours en supposant que celui-ci pourrait avoir été amélioré manuellement lors d'une étape précédente.
L'approche la meilleure et la plus simple nous semble être d'utiliser un interlingua formel IL et :
de répercuter les modifications de L0 vers l'IL,
de regénérer vers L1,… Ln depuis l'IL.
Il faudra cependant permettre des améliorations manuelles, car la forme interlingue ne sera pas toujours présente, ou pas assez améliorable par défaut d'expressivité, et les générateurs ne seront jamais parfaits.
Intérêt de notre travail
L’intérêt de notre travail est que cette nouvelle idée de correction d’une structure intermédiaire à travers une version textuelle pourra permettre d’améliorer les autres versions dans d’autres langues, et donc, pour la première fois dans l’histoire de la traduction, de « partager le travail de révision ».
Un autre point intéressant est que nous nous plaçons dans un cadre collaboratif, sur Internet. Ainsi, ce sont les lecteurs des documents qui détermineront les passages où la qualité est la plus importante, et les réviseront. D’où une troisième idée, celle d’une amélioration incrémentale et à la demande.
Enfin, nous utilisons la génération de texte (la plupart de temps limitée à des domaines restreints) dans le domaine général, et visons des utilisateurs ordinaires et pas seulement des experts.
La mise en œuvre de ces idées impose d’approfondir un certain nombre de points :
quelle « structure intermédiaire » choisir ? Après un étude assez large, notre choix s’est porté sur UNL (Universal Networking Language), langage d’hypergraphes linguistico-sémantiques décrivant des structures abstraites d’énoncés reflétés en anglais.
Comment faire modifier une structure intermédiaire de ce genre par des utilisateurs « naïfs » ? Nous proposerons une « coédition » de cette structure à travers un texte, c’est-à-dire une annotation d’éléments d’un texte provoquant les modifications désirées sur la structure, qui peut rester cachée, sauf dans un mode « expert ».
Pour réaliser une telle coédition à partir d’un couple (texte, structure), comment établir une correspondance fine entre le texte et la structure, sans disposer d’analyseur ni de générateur, ni a fortiori d’une spécification formelle de cette correspondance ? Nous introduirons là aussi une méthode originale fondée sur l’utilisation de ressources disponibles gratuitement pour beaucoup de langues.
Organisation de la thèse
Nous divisons cette thèse en quatre parties :
Partie A (Contexte et motivations) : nous commencerons par une étude de plusieurs systèmes de TA et de génération automatique de langue naturelle pour clarifier l’idée de « coédition ». Nous définirons nos critères, notre terminologie, et les aspects linguistiques et informatiques souhaitables dans un système de coédition. Nous décrirons aussi comment l’idée de coédition pourra s’intégrer dans un système d’information.
Partie B (Quel langage pivot choisir ?) : nous étudierons plusieurs systèmes existants qui ont exploité un interlingua, et concluons que l’interlingua qui nous convient le mieux est UNL. Nous donnerons nos raisons et encore plus de détails sur l’état courant de ce langage et du projet international de recherche organisé autour de ce langage. Nous décrirons un scénario d’un système de coédition utilisant UNL et comment construire un tel système, étant données les caractéristiques d’UNL.
Partie C (Étude des correspondances UNL-texte) : nous étudions divers modèles permettant de décrire la correspondance entre deux structures, et présentons notre algorithme heuristique pour créer la correspondance entre un texte et un graphe UNL
Partie D (Implémentation de la plate-forme SWIIVRE) : nous présentons la plate-forme que nous avons construite pour les expériences sur UNL et sur la coédition. Nous montrons aussi le résultat d’une maquette que nous avons réalisée.


Contexte et motivations
Introduction
Nous commençons cette partie en précisant le contexte dans lequel nous nous plaçons, - en bref, la communication multilingue écrite sur Internet - et les trois axes qui devraient permettre d’augmenter la qualité « utile » de cette communication, tout en en réduisant fortement les coûts : technique de partage de l’effort de révision par « coédition », mutualisation et bénévolat dans ce travail de révision, et diminution de l’effort à tous les stades par « amélioration à la demande ».
Nous cherchons ensuite à préciser quel type de « coédition » sera le plus adapté dans ce contexte. Pour cela, nous étudions un certain nombre de systèmes récents permettant de « coéditer » deux textes parallèles, ou plusieurs textes générés dans des langues différentes à partir d’une même structure interne, etc. Nous aurons ainsi une taxonomie des systèmes de coédition, menant à la définition d’une terminologie précise, ainsi qu’à une comparaison entre les différents types de systèmes.
Enfin, nous déterminons le type de coédition à employer pour la communication multilingue écrite sur Internet, et plus généralement les caractéristiques souhaitables pour un systèmes d’information multilingue organisé autour de ces idées.

Position du problème et motivation du paradigme de la coédition de textes multilingues
Problème de la TA « classique »
Puisque nous nous plaçons dans le contexte de la communication multilingue écrite sur Internet, il nous faut d’abord préciser de quel type de communication il s’agit, et du rôle que peut jouer la TAO sous ses différentes formes.
D’abord, nous visons aussi bien la communication professionnelle que privée. Dans le premier cas, il s’agit de rendre disponible à faible coût et à qualité « suffisante » aussi bien de la littérature « grise » comme des notices d’installation ou des aides en ligne que des manuels d’utilisation ou des pages web de musées et autres sites culturels. Dans le second, il peut s’agir de courriels, ou de petits documents, mais pas (pour l’instant) de dialogues ni de « tchats » pour lesquels il ne semble pas utile d’augmenter la qualité de traduction après coup (sauf peut-être pour établir des PV de discussions). En tout cas, nous supposons que, quelle que soit la méthode de traduction utilisée, le résultat n’est ni parfait ni totalement désambiguïsé.
Que peut-on attendre de la TAO « classique » disponible commercialement, pour répondre à ces besoins ?
Grâce aux services (gratuits ou payants) de TA en ligne, l’expérience des systèmes de TA n’est plus le privilège des experts. Mais le lecteur internaute moyen est souvent frustré par la pauvreté des résultats. En effet, le lecteur peut très facilement trouver des erreurs dans les phrases produites par la machine dans sa langue.
Peut-on espérer que les « traducteurs web » s’améliorent rapidement et deviennent utilisable pour de la communication multilingue de qualité ?
D’après [Hutchins 02], les changements principaux dans le domaine de traduction automatique depuis les années 90, sont dus aux facteurs suivants :
l’utilisation croissante de la TA par les grandes entreprises
l’exploitation des mémoires de traduction et d’autres outils constituant des poste de travail de traduction
les besoins croissants en localisation
la croissance de l’usage des ordinateurs personnels
l’impact d’Internet
la traduction en ligne
l’intégration de la TA et des autres activités de TALN (traitement automatique de langue naturelle)
la recherche de méthodes basées sur les corpus (TA statistique, TA par l’exemple), à mi-chemin entre les mémoires de traduction et la TA fondée sur des connaissances explicites (linguistiques et sémantiques).
Rien dans l’évolution indiquée ne permet d’espérer une augmentation significative de la qualité en domaine ouvert. L’architecture binaire de la plupart des systèmes garantit aussi que la très grande majorité des couples de langues ne pourra pas être couverte, sauf par composition de deux systèmes, menant à une qualité encore plus faible. Il nous faut autre chose que la TAO actuelle.
Pour la TA multisource et multicible, une architecture à pivot interlingue est nécessaire
Pour créer et maintenir un document multilingue, en permettant d’augmenter incrémentalement sa qualité par partage du travail de révision, la meilleure approche nous semble être d'utiliser un « interlingua formel (IL) » et:
de répercuter les modifications d’une langue naturelle L0 vers l'IL,
de régénérer vers les autres langues naturelles L1, … Ln depuis l'IL (L0,..,Ln sont les langues naturelles dans le système).
Dans un système de traduction multilingue, si nous utilisons une structure pivot, le nombre des dictionnaires est 2 N, N étant le nombre des langues dans le système. Mais il faut aussi considérer que le coût de construire un dictionnaire pivot-LN est sans doute 3 fois plus élevé que celui de LN-LN [Boitet 90d]. Avec cette hypothèse, le coût principal d’un tel système est 3*2*N=6 N.
D'autre part, dans un système à transfert, l’idée reçue selon laquelle le nombre des composants serait quadratique n’est pas correcte. Supposons par exemple qu’on utilise comme « pivot non-interlingue », les structures-uma (unisolution, multiniveau et abstraites) d’une langue particulière. On peut réaliser toutes les traductions entre N langues avec 2N-2 transferts. Sur les N(N-1) couples, 2N-2 seront réalisés par transfert lexical simple et (N-1)(N-2) par transfert lexical double. Notons qu’il y a toujours double transfert lexical dans une approche à pivot « interlingue » [Boitet 88b].
Dans la pire architecture à transfert possible, avec N(N-1) transferts, si nous comparons le coût des composants de ce système à pivot (6N) et le coût d’un système de transfert (N(N-1)), le système à pivot est moins cher seulement quand N est plus grand ou égal à 8 (quand N(N-1)-6N>0).
Cela dit, l’architecture à N(N-1) transferts est trop naïve et personne ne l’utilise. On prend plutôt les résultats d’analyse d’une langue par le système comme « langue pivot ». Dans ce cas, le coût principal d’un tel système sera 2(N-1). Mais dans la réalité, on n’a pas de très gros corpus ni assez de linguistes compétents sur la structure de surface de la langue pivot, surtout quand la couverture dépasse les langues bien dotées. Si on prend l’anglais (une classe de structures d’analyse de l’anglais) comme pivot, il faut des développeurs connaissant très bien l’anglais et une théorie linguistique de la structure syntaxique de l’anglais. Cela est infaisable pour beaucoup de langues.
En bref, quand il s’agit de la structure (intermédiaire) de surface d’une langue naturelle, par exemple un pivot syntaxique, le transfert sera très compliqué et on aura du mal à trouver des développeurs. C’est pour cela qu’on a besoin d’une « structure abstraite » la plus interlingue possible, et pas d’une « structure concrète » d’une langue particulière.
Enfin, la structure pivot est plus efficace quand il s'agit d'un système fortement multilingue (N ”! N langues). En effet, il est plus facile d ajouter une nouvelle langue dans un système à pivot interlingue, car il n y a en principe pas de « transfert structural » à écrire, alors qu il faut en écrire deux si on utilise un « pivot linguistique » comme les structures multiniveau de l’anglais.
Diminution des coûts par partage de la révision /post-édition en TA multilingue - l’idée de la coédition
Il est incontestable qu’on n’obtient de bons résultats en TAO qu’avec des systèmes à domaine fixé, à préédition ou entrée contrôlée, et/ou de type KBMT (knowledge-based machine translation). Mais nous visons d’autres contextes, et ne pouvons utiliser ce type d’approche. Nous visons en effet un système de domaine général et utilisable par l’utilisateur ordinaire. Or, on ne peut pas demander à un utilisateur ordinaire sans entraînement d’écrire en langage contrôlé. De plus, même dans le système CATALYST de CMU-Caterpillar à domaine fixé et à entrée contrôlée, et utilisant une ontologie, la postédition (révision) est toujours nécessaire pour obtenir un résultat précis [Hutchins 02]. Il nous semble donc que la postédition sera toujours indispensable pour obtenir une bonne ou très bonne qualité.
L’innovation majeure que nous apportons est un moyen de ne faire la révision qu’une seule fois et, dans une seule langue cible, pour chaque passage révisé (mais peut-être dans deux langues différentes pour deux passages différents), et d’en faire bénéficier automatiquement les autres langues cibles.
En quoi consiste au juste la post-édition de TA ? La post-édition n’avait pas été prévue dans les systèmes de TA du tout début, qui devaient remplacer le traducteur. On avait simplement oublié que, en traduction professionnelle, le travail du traducteur, même excellent, est toujours révisé par un « senior ». Dans la pratique, il existe comme on l’a dit des systèmes de TA assez spécialisés pour qu’on puisse utiliser leurs résultats comme des premiers jets de traducteurs humains et les soumettre à des réviseurs.
Dans la pratique, le temps pour la révision humaine d’un document issu de TA est environ un tiers de celui de la traduction humaine. Chaque page standard de 250 mots demande environ une heure pour la traduction. Prenons 30 pages standard de 250 mots. Pour traduire et réviser ces pages en N langues à la main, le temps estimé est (30+10)N=40N heures (traduction + révision). Dans un autre cas extrême où la TA du réviseur (TAO-R) est disponible, le temps demandé sera 10N (seulement le temps de révision). Bien sûr, le temps pour les autres moyens (THAM, par exemple) se situe au milieu. On a donc l’équation suivante : (pour 30 pages standard, soit 7500 mots, ou 42000 caractères) :
TAO-R(10N) < THAM < THum(40N)
Si on a une structure pivot sur laquelle on peut réviser à travers une langue naturelle, et si la modification peut ensuite se propager dans les autres langues par génération, on n’a besoin de réviser qu’une seule fois, comme dans la  REF _Ref61435420 \h Fig. A1. On peut éliminer la variable N. Même si la révision prenait plus de temps dans cet environnement (peut-être à cause de l’environnement guidé, ou à cause du fait que le texte de surface est lié à la structure interne), par exemple, s’il augmente de 50% (une demi-heure soit 15 heures pour 30 pages), l’approche serait quand même très rentable, et cela d’autant plus qu’il y a beaucoup de langues dans le système (N grand).
Coédition (15) < TAO-R(10N) < THAM < THum(40N)
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 1 Partage de révision
Il faut noter que l’idée de « partager la révision » par coédition, ou autrement, est tout--à-fait nouvelle. Elle n’a pu émerger qu’à cause des progrès de la TA par pivot.
Utilisabilité par des non-spécialistes et des bénévoles
L’idée ici est que chacun peut être le réviseur ou le correcteur d'un document dans sa langue maternelle. Nous ne savons pas toujours pourquoi une phrase est incorrecte, mais nous avons toujours la capacité de donner une phrase similaire mais plus correcte. Dans un environnement bien guidé et contrôlé, tout un chacun devrait pouvoir utiliser des outils pour corriger un document dans la langue qu'il connaît. Notre idée est que la révision ne sera pas faite que par des professionnels, mais bien plus par les lecteurs eux-mêmes, et particulièrement sur les fragments jugés en valoir la peine.
D’où viendront ces « bénévoles de la coédition » ? Nous pensons qu’il y en aura, comme pour le développement de Linux, des outils du W3C et des shareware sur Internet. Les communautés internautes auxquelles nous pensons sont des groupes d’utilisateurs de produits grand public (matériels, logiciels, etc.) aussi bien que des groupes de discussion (Yahoo Clubs, MSN groupes, Lycos, Geocities, etc.). Peut-être arrivera-t-on donc aussi à motiver des internautes pour aider bénévolement à postéditer et coéditer.
Nous avons expliqué notre situation et les raisons pour lesquelles nous pensons utiliser la « coédition ». Nous allons maintenant examiner plusieurs systèmes de coédition/édition et leurs interactions avec l’utilisateur pour avoir une idée plus concrète sur le concept même de « coédition ».
Définition des notions principales concernant la coédition
Nous avons choisi sept systèmes de TA ou de génération automatique de langue naturelle. Le critère de choix est que ces systèmes doivent avoir deux objets à manipuler. Cela nous permettra de proposer une taxonomie des systèmes de coédition, puis de spécifier les caractéristiques désirables de notre système de coédition.
Présentation de quelques systèmes utiles pour préciser la notion de coédition
LIDIA (Large Internationalisation des Documents par Interaction avec l’Auteur)
Début 1990, la TAO (Traduction Automatique par Ordinateur) pour le rédacteur, ou « TAO personnelle » était un nouveau concept dont l’émergence avait été rendue possible tant par l’expérience acquise en « TAO lourde » (pour le veilleur ou pour le réviseur) que par l’évolution de la bureautique vers des outils très interactifs et multimédia (hypertextes) disponibles sur des postes de travail bon marché, connectables à des serveurs puissants.
Au lieu de réviser (postéditer) les traductions brutes produites en langue(s) cible(s), l’idée est de prééditer (indirectement) le texte source grâce à un dialogue du système avec l’auteur, dialogue visant tant à standardiser l’entrée (langage « guidé ») qu’à la clarifier (ambiguïté, ellipses, etc.). La structure profonde ainsi obtenue, étant correcte sur tous les plans (morphologique, sémantique, pragmatique), doit permettre de produire des traductions de grande qualité. La maquette LIDIA-I a été produite en 1994 au GETA pour valider ce concept [Blanchon 94].
L’architecture physique est un système distribué dans lequel les stations de rédaction (les machines Macintosh) communiquent avec un serveur de traduction. Le typage des unités à traduire, la correction orthographique, la standardisation terminologique, les mesures stylistiques et traitement des formules figées sont des tâches de la standardisation confiées à la station de rédaction. Les phases d’analyse, de transfert et de génération sont effectuées sur le serveur de traduction.
Blanchon a choisi de réaliser la station de rédaction comme une extension du logiciel de création d’hypertextes Hypercard, très largement disponible, à un coût très faible, et d’ores et déjà employé en documentation technique et industrielle (Renault, etc.) et en création personnelle multimédia. Dans un premier temps, un environnement de traduction de piles Hypercard vers le russe, l’anglais, et l’allemand a été créé. Le français était la seule langue source. Le serveur de traduction était un linguiciel de TAO multicible avec rétrotraductions (pour le contrôle) écrit dans l’environnement Ariane-G5 du GETA.
Voici un image de l’interface de démarrage sur la station de rédaction.

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 2 Interface (HyperCard) de démarrage de LIDIA-I
Les traitements principaux sont illustrés dans la figure A.2. Citons [Blanchon 94] :
Le texte français est d’abord standardisé sur la station de rédaction.
Le texte standardisé est alors analysé sur le serveur. La mmc-structure source produite (multisolution, multiniveau et concrète) est transformée en une forme portable (en lisp) et lisible (directement par les développeurs) et envoyée au Macintosh.
La mmc-structure source est utilisée pour produire le dialogue de désambiguïsation sur le Macintosh. Le processus de désambiguïsation la transforme en une umc-structure source non-ambiguë (unisolution, multiniveau et concrète) correspondant à l’analyse choisie par l’auteur.
Cette umc-structure source est alors « abstraite », ou « réduite » à une uma-structure source (unisolution, multiniveau et abstraite).
A partir de la uma-structure source, le système Ariane-G5 produit les gma-structures cibles (génératives, multiniveau, et abstraites), en utilisant les transferts adéquats. Une gma-structure est plus « générale » et plus « générative » qu’une uma-structure, car ses niveaux de surface (fonctions syntaxiques, catégories syntagmatiques, etc.) peuvent être vides, et sinon ne sont que des préférence indiquées par le transfert.
Pour chaque langue cible, la génération structurale produit à partir de la gma-structure cible une uma-structure cible homogène avec ce que serait le résultat de l’analyse (et de la désambiguïsation) du texte cible qui sera généré. Cette étape consiste à choisir la paraphrase à générer en calculant les niveaux de surface et à choisir une première approximation de l’ordre des mots à partir des niveaux plus profonds (relations logiques et sémantiques, traits sémantiques, etc.).
Le processus de traduction se termine par les générations syntaxique et morphologique. Quand tous les objets ont été traduits, on obtient la ou les piles images dans la ou les langues cibles.
Les uma-structures cibles peuvent être utilisées comme point de départ de rétrotraductions permettant à l’auteur (monolingue) de contrôler les traductions.

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 3 Organisation générale du processus de traduction en LIDIA-I
Le dialogue de désambiguïsation entre le système et l’utilisateur peut être sans ou avec explications selon le besoin et le niveau de l’utilisateur.
Voici une fenêtre de dialogue, sans explication. L’utilisateur peut cliquer sur le bouton pour demander plus d’explication.

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 4 Dialogue avec paraphrasage et accès à des explications
Voici une figure qui montre la désambiguïsation avec explications. Quand l’utilisateur finit de lire l’explication, il peut retourner au dialogue et faire son choix.

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 5 Explications pour l’ambiguïté de construction argumentaire du verbe
Analysons maintenant cette maquette pour dégager les aspects les plus pertinents de la notion de « coédition ».
Fiche d’identité
ObjectifSystème de la TA et désambiguïsation interactive Date1994Source ou descriptionThèse de H. Blanchon "LIDIA-1: Une Première Maquette vers la TA Interactive pour TOUS"ResponsableGETA, Hervé BlanchonLangue sourcefrançaisInterfaceMenu et fenêtre de dialogueLangue d'interfaceFrançaisCréation de la structure interneAprès le parsage de la phrase d'entrée, le système obtient plusieurs structures internes possibles, le système pose des questions à l’utilisateur en sa propre langue et l’utilisateur choisit la bonne structure Structure interneArbres Ariane et données linguistiquesLangues ciblesrusse, allemand, anglais (avec rétrotraduction en français)DomainegénéralSite webhttp://www-clips.imag.fr/geta/herve.blanchonUtilisabilitéTout le mondeRemarque
Bien que la structure interne et le texte de surface existent, LIDIA-I n’est pas un système de coédition, parce qu’il n’y a pas de modification en couple. Le processus de désambiguïsation interactive revient à choisir une structure parmi plusieurs structures possibles et l’utilisateur ne peut ni modifier la structure choisie ni les textes produits en différentes langues.
Il n’y a donc pas d’édition ni de coédition dans LIDIA-I.
MODEX
MODEX, développé par la compagnie CoGenTex Inc., est un produit de génération automatique de langue naturelle. L’intérêt de MODEX est qu’il montre dans un même projet 4 objets : le diagramme d’objets “OO” (object oriented), le plan du texte, le texte pour la validation du diagramme OO et le texte pour la documentation.
L’utilisateur prépare son texte par l’interface d’édition (planification du texte) et produit le diagramme OO comme représentation de connaissance.
Quand l’utilisateur veut vérifier le digramme OO, qui pourrait être difficile à comprendre, il peut demander de le sortir en texte (texte pour la vérification).
Dans le texte pour explication, l’utilisateur peut cliquer sur l’hypertexte (lié à une icône ou un identificateur de connaissance) pour voir plus d’explications sur ce mot, mais il ne peut pas éditer directement dessus. L’utilisateur est obligé de retourner à l’interface d’édition. Une fois satisfait, l’utilisateur peut produire le texte final.
Voici une vue du diagramme OO et une vue du texte pour la validation:

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 6 Image de MODEX
Fiche d’identité
ObjectifProduire des descriptions textuelles à partir d'un graphe d’objets. Les auteurs constatent qu’un diagramme d’objets est en fait plus difficile à lire qu’une description simple. Donc, ils ont besoin d'un système pour produire le texte explicatif.DateProposé en 1997, maintenant commercialiséArticle“Customizable Descriptions of Object-Oriented Models”, Proceedings of the fifth Conference on Applied Natural Language Processing, Washington DC, pp. 265-268ResponsableLavoie, Benoit; Rambow Owen; Reiter EhudInterfaceIl y a trois vues: le diagramme OO, la description pour validation, et le plan du texte. Langue d'interfaceanglaisCréation de la structure interneManuellement avec l'aide de l'interface. Le système peut lire un diagramme OO puis y ajouter les données entrées par utilisateur sur ce diagrammeStructure interneModèle OO (structure sémantique, non syntaxique)Langue cibleanglaisDomaineNon-spécifiqueApplication sur autre domainepossible, mais toujours domaine fixeUtilisabilitéExpert du domaineSite webhttp://www.cogentex.com/research/modex/index.shtmlRemarque
Il n’y a pas de coédition dans le système MODEX. L’utilisateur ne peut que manipuler l’objet du plan de texte, et le système ne fournit aucun lien entre les autres objets. L’utilisateur ne peut pas voir le résultat de son édition tout de suite, il faut toujours attendre que le plan de texte soit terminé pour que le système puisse générer les autres objets.
DRAFTER
DRAFTER est un générateur destiné à produire des manuels multilingues de logiciel. Avec l’aide de l’interface, l’utilisateur crée la structure interne (objet O1) et finalement produit le texte de sortie (objet O2). L’intérêt de ce système est qu’il fournit à l’utilisateur la souplesse de définir ses propres classes de connaissances, en plus de ce qui est déjà défini dans la base de connaissances.
Voici l'interface de DRAFTER:

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 7 Interface de DRAFTER
Fiche d’identité
ObjectifProduction de manuels multilingues de logicielsDateMars, 1997Source ou descriptionHartley, A.F. et Paris, C (1997) “Multilingual document production: from support for translating to support for authoring”, Machine Translation, Special Issue on New Tools for Human Translators, Vol. 12, no. 1-2, pp. 109-129ResponsableITRIInterfaceMenu, copier & coller objetsLangue d'interfaceAnglaisCréation de la structure interneManuellement avec l'aide de l'interface. L'utilisateur crée la structure interne en même temps qu’il édite l'interface graphiqueStructure interneReprésentation conceptuelleLangue cibleAnglais, françaisDomaineManuels de logicielsApplication sur autre domainepossible, mais toujours sur un domaine fixé et restreintUtilisabilitéExpert du domaine Site webhttp://www.itri.bton.ac.uk/projectsindex.htmlRemarqueSuivi par le projet AGILE (Automatic Generation of Instructions in Languages of Eastern Europe), qui s'étend au russe, au bulgare et au tchèqueRemarque
DRAFTER n’est pas un système de coédition, parce qu’une fois que le texte est créé, le processus est terminé. Nous ne pouvons pas prendre un texte et recommencer son édition ni faire de coédition.
Ambassador
Ambassador est un logiciel commercial qui a connu une grande réussite, mais ce n’est ni un système de traduction automatique ni un processeur de texte, C’est plutôt un système de traitement documents bilingues ou un système de coédition [Horn 95].
L’utilisateur choisit un patron de lettre. Deux lettres semi-finies s’ouvrent alors sur l’écran, l’une en français, l’autre en japonais. Le système permet à l’utilisateur de choisir dans les champs, avec des choix proposés par le système, ou d’entrer des données dans des zones libres. L’utilisateur peut choisir du côté français (objet O1) ou du côté japonais (objet O2) selon sa connaissance de chaque langue, et la modification faite se répercute tout de suite dans l’autre langue. Il existe aussi un petit dictionnaire dans le système et l’utilisateur peut ajouter de nouveaux mots.
Dans la  REF _Ref61351177 Fig. A8, nous voyons que l’utilisateur a tapé le nom du destinataire en français, mais il n’est pas encore affiché en japonais. Dans la même figure, nous pouvons constater qu’Ambassador ne traite pas la dépendance sémantique dans un document, à cause de l’inconsistance des sujets “je” et “nous” dans le document.
Ambassador vue I – Edition d’une lettre de “demande d’enquête”

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 8 Ambassador vue I – Edition d’une lettre de « demande d’enquête »
Ambassador vue II – choix des phrases japonaises. Une fois que le choix est fait, la modification du côté français est immédiate.

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 9 Ambassador vue II – choix au côté japonais
Fiche d’identité
ObjectifSystème bilingue commercial pour produire les lettres d’affairesDate1995Source ou descriptionPlus disponibleResponsableLanguage Engineering Corporation, USAInterfaceMenu à choisir, et champs et zones libres à remplir Langue d'interfaceAnglais, japonais, français, espagnolCréation de la structure interneTout est encodé dans le systèmeStructure interneinvisibleLangue cibleAnglais, japonais, français, espagnolDomaineProduction de lettres d’affairesApplication sur autre domainepossible, mais toujours domaine fixeUtilisabilitéTout le mondeSite webPas disponibleRemarque
Nous n’avons pas trouvé d’information sur la structure interne d’Ambassador. Mais l’observation ci-dessus montre que ce système est fortement contrôlé en entrée. Le système n’a pas beaucoup de souplesse, mais il est très rapide et correct. Ambassador est un des systèmes de coédition les plus anciens.
Le fonctionnement de ce système nous mène à l’hypothèse suivante : il y a sans doute une structure interne qui se réduit à une table de correspondance. Un champ cliquable peut correspondre à plusieurs variables (choix possibles) et une variable peut apparaître dans plusieurs champs cliquables. Chaque variable établit une correspondance entre un segment de l’énoncé français et un segment de l’énoncé japonais.
L’utilisateur peut éditer l’objet O1 ou l’objet O2 dans Ambassador, et donc Ambassador est un système de coédition symétrique.
L’approche WYSIWYM (What you See Is What You Meant)
L’idée de l’approche WYSIWYM est que le système lie le texte de sortie et la structure interne. Donc, quand l’utilisateur édite le texte, il est en fait en train de créer ou d’éditer la structure interne. Nous disons que c’est de la coédition, parce que l’utilisateur édite un objet (la structure interne, objet O1) à partir d’un autre (le texte, objet O2).
Nous prenons comme exemple le premier système qui a utilisé l’idée WYSIWYM, DRAFTER II.
Pour créer un document, on remplit des textes cliquables en couleur proposés par le système. Le texte en rouge est nécessaire et le texte en vert est facultatif. Quand l’édition s’achève au bout de l’arbre de décision, le texte devient noir et il n’est plus possible de le changer. Chaque fois que l’utilisateur clique sur un texte en couleur, le système lui propose des choix possibles dans ce contexte après avoir consulté sa base de connaissances.
Voici une image de l’interface WYSIWYM au début de l’édition d’un document. Il y a deux cadres, le texte d’édition en haut et la structure interne en bas. Il est aussi possible d’éditer directement la structure interne avec des actions limitées, par exemple, copier et coller.

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 10 Début d’édition d’un document (système WYSIWYM)
Quand il n’y a plus de texte rouge, l’édition peut se terminer.

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 11 Fin d'édition d'un document (système WYSIWYM)
Fiche d’identité
ObjectifProduire les instructions pour utiliser un traitement de texte et un gestionnaire d'agendaDate1996-Source ou descriptionR. Power, D. Scott and R. Evans (1998). What You See Is What You Meant: direct knowledge editing with natural language feedback. Proceedings of the 13th Biennial European Conference on Artificial Intelligence (ECAI 98), Brighton, UKResponsableITRIInterfaceInterface graphique avec menu et texte cliquable.Langue d'interfaceItalien, français, anglaisStructure interneReprésentation conceptuelleLangue cibleItalien, français, anglaisDomaineProduction de manuelsApplication sur autre domainePossible, mais toujours avec un domaine restreint UtilisabilitéUtilisateur ordinaireSite webhttp://www.itri.bton.ac.uk/projectsindex.htmlRemarqueA part DRAFTER-II, il existe aussi d'autres systèmes qui emploient l'idée de WYSIWYM, comme PILLS, CLIME, et ICONOCLAST. Toutes les informations sur ces systèmes se trouvent sur le site d’ITRI ci-dessus.Remarque
L idée de WYSIWYM est un bon exemple de coédition dans le sens texte ’! structure interne. Le texte est traité comme l interface d édition de la structure interne. Donc, quand l utilisateur édite la structure interne (objet O2), il l édite en fait à travers le texte (objet O1).
Le point fort de WYSIWYM est que l utilisateur édite directement le texte généré, donc il voit bien le résultat. Dans les systèmes précédents, l utilisateur était obligé d éditer une représentation à base d icônes et de graphes, qui ne sont pas proches de langue naturelle, et donc ce n’était pas utilisable par tout le monde.
Bien sûr, derrière cette interface textuelle, il existe une structure représentative de connaissances.
Enfin, l’utilisateur peut aussi changer la langue de travail à tout moment, et obtient les autres versions, car le système a un générateur multilingue assez puissant.
Après DRAFTER II, l’idée de WYSIWYM a aussi été appliquée dans les projets PILLS [Bouayad-Agha 02], CLIME [CLIME] , et ICONOCLAST [ICONOCLAST].
Le système PILLS produit des descriptions de médicaments et le système CLIME produit de la documentation judiciaire.
ICONOCLAST (Integrating Constraints in Layout and Style) est un projet qui intègre la génération automatique de langue naturelle et les contraintes de style et de mise en forme. Avec ICONOCLAST, on peut sauvegarder un document et le rééditer plus tard, ce qui est un progrès par rapport aux systèmes DRAFTER, PILLS et CLIMS, qui sont plutôt destinés à la création de documents.
Multimeteo
Dans Multimétéo, le système produit un bulletin météorologique semi-fini à partir des données (il existe déjà plusieurs systèmes pour la génération automatique de bulletins météorologiques multilingues, comme FoG, MLWFA, etc.).
L'utilisateur affine ce bulletin brut a posteriori en cliquant sur le texte en rouge. Le système lui propose alors des choix possibles. L’utilisateur édite donc un interlingua à travers le GUI (Graphical User Interface).

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 12 Interface de Multimétéo
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 13 Procédure d’édition du système Multimétéo
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 14 Structure générale du système Multimétéo
Fiche d’identité
ObjectifProduire interactivement un document multilingue de prévision météorologiqueDateMultimétéo II 1999- Source ou description(2001) José Coch, Karine Chevreau, "Interactive Multilingual Generation" CICLing-2001 (Computational Linguistics and Intelligent Text Processing), Mexico, February 2001ResponsableMétéo-France, INM, ZAMG, IRM & LexiQuestInterfaceMenu et description textuelle avec des mots cliquables.Langue d'interfaceAnglais, espagnol, français, allemand (néerlandais, catalan, galicien, basque à venir)Structure interneReprésentation conceptuelleLangue cibleAnglais, espagnol, français, allemand (néerlandais, catalan, galicien, basque à venir)DomaineBulletin météorologiqueApplication sur autre domainePossible, mais toujours sur un domaine restreintUtilisabilitéInterface facile à utiliser par un utilisateur ordinaireSite webhttp://www.knmi.nl/hirlam/NewsLetters/35/OperationalEs/mmeteo/Multimeteo.htmlRemarqueRemarque
Multimeteo est aussi un bon exemple de coédition. L’utilisateur édite directement le texte (objet O1) et la modification est faite sur la structure interne (objet O2) et le texte (objet O1) lui-même, comme pour WYSIWYM. C’est pourquoi nous appelons ce genre de coédition « coédition double ».
MDA (Multilingual Document Authoring)
MDA est un système de composition de documents multilingues qui a été appliqué à la production de modes d’emploi de médicaments. L’interface est une sorte d’union de celle d’Ambassador et de celle de WYSIWYM :
La mise en forme du document est décidée au début comme avec Ambassador.
La structure de document peut évoluer au cours de l’édition comme avec WYSIWYM, mais avec des choix plus sophistiqués et aussi une dépendance syntaxique plus stricte.
La structure interne est aussi différente (DTD enrichie).
Voici une image d’interface de MDA :

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 15 Interface de MDA
Fiche d’identité
ObjectifProduire des modes d’emploi multilingues de médicamentsDate2002-Source ou description"Document Structure and Multilingual Authoring", Caroline Brun, Marc Dymetman, Veronika Lux, Proc INLG'2000, Mitzpe Ramon, Israël, pp 24-31ResponsableXRCEInterfacemenuLangue d'interfaceAnglais, français, allemandStructure interneDTD enrichieLangue cibleAnglais, français, allemandDomaineModes d’emploi multilingues de médicamentsApplication sur autre domainePossible, mais toujours sur un domaine restreintSite webhttp://www.xrce.xerox.com/competencies/content-analysis/dcm/demo/mda-demo.htmlUtilisabilitéUtilisateur ordinaireRemarqueMise en relief d’un document sémantiquement correctRemarque
Nous remarquons qu’il y a aussi deux cadres dans l’interface. Mais, au lieu de montrer deux structures comme WYSIWYM, MDA montre le texte en français et en anglais dans deux cadres.
On ne peut pas éditer directement la structure interne, mais cela n’empêche pas MDA d’être un bel exemple de coédition double.
MDA offre aussi le moyen d’exprimer des contraintes sémantiques très fortes, par exemple, la compatibilité sémantique entre les champs remplis.
Aspects principaux
L’étude des systèmes précédents nous a amené à dégager quelques concepts utiles, dont nous tentons maintenant de donner une définition précise.
Définitions
Nous nous plaçons dans la situation où on veut modifier deux ou plusieurs objets fortement reliés entre eux, comme un texte et sa (ou ses) structure(s) abstraite(s). Il ne s’agit pas d’éditer un objet unique à travers plusieurs vues sémantiquement équivalentes (comme par exemple les vues « normales », « page », et « plan » de Word). En effet,
une même structure interne peut en général correspondre à un nombre variable de textes (paraphrases) plus ou moins exactement synonymes,
un même texte peut aussi correspondre à des structures internes différentes et d’interprétations différentes (pas d’ambiguïté).
Nous prenons le cas le plus simple, où il n’existe que deux objets et nous appelons ces deux objets « O1 » et « O2 » dans les définitions suivantes :
Définitions
coédition - édition de O2 à travers O1.
édition - modification de O1 ou O2 par un série de modifications locales.
localité - portée d’une modification (normalement, inférieure à l’énoncé).
coédition double - édition de O2 et de O1 à travers O1.
coédition simple - édition de O2 et pas de O1 à travers O1.
coédition pseudo-double - édition de O2 et pas de O1, à travers O1, puis mise à jour produisant (sur demande) O1’ sous une forme montrant les différences entre O1 et O1’ de façon analogue à ce qu'aurait pu produire une édition de O1.
coédition symétrique – on peut coéditer O1 à travers O2 de la même manière qu’on coédite O2 à travers O1.
coédition contrainte/libre – l’utilisateur ne peut éditer que certaines parties du document (dans O2), ou l’utilisateur peut éditer n’importe quelle partie du document (dans O2).
génération immédiate - une édition sur O1 se propage immédiatement à O2 (ici en général, O1 est la structure interne).
Tableau  STYLEREF 1 \s A SEQ Tableau \* ARABIC \s 1 1 Taxonomie de la coédition
Application de cette taxonomie aux systèmes étudiés
Voici un tableau résumant les définitions, et le type de coédition offert par les systèmes présentés ci-dessus :
Nature et opérationCoédition simple
Coédition pseudo-double
(si pas de coédition double)Objet 1Objet 2simpledoublesymét-riqueLIDIAEnsemble d’arbres à sélectionnerTexte génération totalenonnonnonnonAmbassadorTexte d’édition contrainteTexte d’édition contrainteouiouiouiMODEXTexte/objet d’édition libreTexte génération totalenonnonnonnonDRAFTERObjet d’édition contrainteTexte génération totalenonnonnonnonWYSIWYMTexte d’édition contrainteStructure interneouiouinonMultimeteoTexte d’édition contrainteStructure interneouiouinonMDATexte d’édition contrainteDTD enrichieouiouinonTableau  STYLEREF 1 \s A SEQ Tableau \* ARABIC \s 1 2 Taxonomie des systèmes étudiés
Comparaison synthétique
Une brève comparaison des systèmes de coédition précédents sera utile pour définir l’architecture adaptée à nos besoins.
Ambassador est le moins souple, mais il est précis et rapide, et facile à utiliser. En effet, toutes les correspondances possibles entre le texte et la structure interne sont établies a priori.
DRAFTER II (WYSIWYM) est également rapide et facile à utiliser, mais il est contraint par la nécessité d’une base de connaissances. Un autre défaut est que le texte sorti manque un peu de style. Ce défaut est amélioré dans le système ICONOCLAST. Le feedback textuel peut paraître peu naturel, par exemple : « do some action by some method ».
Multimeteo et MDA peuvent produire des textes assez bons mais ne sont applicables qu’à un domaine fixé. L’interface de coédition est presque en langue naturelle, donc ils sont assez faciles à utiliser.
Tous ces systèmes visent un domaine fixe. Ainsi, les correspondances entre le texte et la structure interne peuvent être encodées à l’avance. C’est grâce à cette restriction qu’on peut obtenir un résultat assez satisfaisant, mais c’est aussi à cause de cette restriction qu’il est impossible d’étendre ces systèmes au domaine général.
Nous constatons aussi qu’aucun des systèmes vus ici ne permet aux utilisateurs d’entrer du texte libre. Les utilisateurs ne peuvent que choisir parmi les choix proposés par les systèmes. En effet, dans ce type d’interaction homme-machine, il est sans doute impossible pour la machine de comprendre ce que veut dire l’homme, et il est aussi plus efficace pour la machine de proposer des modifications possibles selon la structure interne et le contexte, au lieu de comparer pour trouver la correction faite par l’homme. Donc, nous pouvons pour l’instant supposer que ce genre d’interaction (l’homme choisit, la machine propose) sera utilisé dans tous les systèmes.
Types de coédition souhaitables
Nous nous situons toujours dans la perspective d’un système à large couverture, non restreint à un domaine et un type de documents particuliers, et utilisable par le grand public (en mode non expert).  :
coédition – Nous souhaitons un système de coédition, surtout dans le sens texte ’! structure interne. Pour l utilisateur ordinaire, le texte est en effet le moyen le plus naturel de s exprimer et d éditer (ou d annoter).
coédition double  La coédition double est souhaitable, parce que plus rapide, mais elle n’est pas indispensable. En effet, l’objet (O1) au travers duquel on édite l’autre objet (O2) sera régénéré à l’étape suivante à partir de la forme interne. D’autre part, système de coédition double est plutôt difficile à construire, sauf quand toutes les correspondances sont prévues.
coédition symétrique – Un système de coédition symétrique n’est pas indispensable, parce que, pour la plupart des utilisateurs, la structure interne reste difficile à comprendre, et il est donc presque impossible de l’éditer directement. Le seul intérêt de la coédition symétrique est pour les experts. De plus, un système de coédition symétrique est encore plus difficile à construire si les deux objets sont hétérogènes, ce qui est notre cas.
coédition pseudo double – Ce genre de système peut être intéressant pour simplement montrer les traces de correction, mais cette fonctionnalité ne paraît pas indispensable.
coédition libre / contrainte – Nous souhaitons que l’utilisateur de notre système ait la liberté de modifier n’importe où dans le document. La portée de toutes les modifications est alors locale, et donc l’édition est plus simple et légère pour l’utilisateur ordinaire.
domaine – Un objectif essentiel est que notre système puisse traiter le domaine général. Il est alors sans doute impossible de prévoir toutes les correspondances et les connaissances. C’est pourquoi nous nous proposons de construire les correspondances a posteriori pour faire la coédition.

En bref, un système de coédition idéal serait un système qui s’appliquerait au domaine général, et qui permettrait la coédition double, symétrique et libre. Comment adapter l’idée de coédition à la communication multilingue écrite/orale
Architecture linguistique générale “à pivot”
Utilisation d’une représentation interlingue pivot
Puisque nous voulons produire un système multilingue, une représentation pivot (intermédiaire) est plus commode et souple pour ajouter une autre langue dans le système. Pour un système de coédition, selon notre discussion précédente, il n’est probablement pas possible de coéditer deux langues naturelles comme deux objets de coédition, car cela est trop compliqué. Il faut donc avoir un pivot servant de base d’édition.
Production automatique ou semi-manuelle du pivot
Quelle que soit la représentation intermédiaire que nous utiliserons comme « pivot », ce sera une représentation abstraite d’un ou de plusieurs énoncés, difficile à lire et donc cachée aux utilisateurs non experts.
Dans notre système, pour les utilisateurs qui ne connaîtront pas cette représentation pivot, il devra y avoir des modules qui feront le transfert de LN vers le pivot automatiquement. Bien sûr, la qualité d’une représentation de pivot produite automatiquement ne pourra pas être parfaite, ce qui rendra la postédition (par coédition !) très utile, voire indispensable.
D’un autre côté, il faut garder la souplesse et permettre aux experts de produire ce pivot semi-manuellement pour que la représentation pivot soit la meilleure possible. Cela va de techniques d’analyse multiple suivie de désambiguïsation interactive à la construction manuelle assistée pas un environnement adéquat (manipulation directe de la structure, vérifications automatiques de cohérence).
Coédition séparée/indépendante des langues analysées
On souhaite pouvoir coéditer depuis toutes les langues dans le système, pas seulement depuis une langue spécifique. Il faut donc que le pivot ne soit pas lié à une seule langue, mais soit réellement interlingue.
Insertion dans des systèmes d’information
Aspect décentralisé
Pour inclure autant d’utilisateurs que possible, le système doit être décentralisé. En effet, nous ne pouvons pas construire un système centralisé qui inclut toutes les langues possibles.
Le système doit lui-même se présenter comme un module qui aide à la traduction. Ce module et donc ce module, par exemple, une applet Java, devra donc être facile à télécharger et être utilisable sur des plates-formes différentes.
Traitement local avec ressources minimales
On ne peut pas supposer que les utilisateurs disposeront d’analyseurs et de générateurs complets au moment de la coédition.
Il faudra donc que le système de coédition puisse fonctionner en n’utilisant que des ressources disponibles partout, comme
de simples dictionnaires LN-anglais,
des analyseurs morpho-syntaxiques.
Disponibilité sur Internet et Intranet
Le but final est de mettre notre système mise sur le réseau, Internet ou Intranet, pour qu’il soit ouvert à tout le monde. Bien entendu, la capacité de communication sur le réseau et la programmation du réseau seront très importantes dans notre conception du système.
En particulier, il faut implémenter une technique simple permettant à plusieurs utilisateurs d’améliorer le même document en même temps, sans créer de conflits.
D’où l’idée de ne jamais rien effacer dans le document maître, mais d’y enregistrer les modifications de chacun comme des versions (monotonie).
Ingrédients d’une solution à pivot du point de vue des systèmes d’information
Un document maître XML-isé
Notre premier « ingrédient » sera donc l’utilisation d’un unique fichier multilingue en XML, ou « document maître XML-isé ». Ce document contiendra, pour chaque phrase, une ou plusieurs versions dans chaque langue, et une ou plusieurs versions sous forme pivot. Ce document maître sera bien sûr en Unicode. A partir d’un tel document, on pourra facilement produire des vues monolingues, ainsi que des documents monolingues (ou multilingues alignés) dans différents formats et codages.
Passage aisé entre deux modes de coédition - naïf et professionnel
Puisque notre système est destiné non seulement à l’utilisateur ordinaire mais aussi à l’expert, ces deux modes d’exploitation seront disponibles à tout instant et le passage entre ces deux modes devra être facile, pour encourager et attirer plus d’utilisateurs à participer et à entrer dans les détails de problème.
Bien entendu, le passage entre l’activité de lecture et celle de coédition doit lui aussi être rapide et non perturbant.
Choix de correction proposé par le système
Nous ne voulons pas laisser l’utilisateur éditer directement le texte, car ses modifications pourraient être incomplètes (par exemple, mise au pluriel d’un sujet et oubli de le faire pour le verbe) et surtout car il est très difficile d’interpréter des modifications textuelles à un niveau abstrait sans réanalyse totale. Mais c’est ce que nous voulons justement éviter !
D’où l’idée de proposer à l’utilisateur les modifications possibles sur la forme pivot, en les associant aux éléments correspondants du texte. Ainsi, si le curseur passe sur un mot, le système devrait proposer les modifications des parties correspondantes de la forme pivot, en les présentant comme des corrections à l’intention d’un typographe, c’est-à-dire comme des indications de « ce qu’il faudrait faire » (e.g., « mettre au pluriel »).
Établissement a posteriori des correspondances
Dans notre analyse sur les systèmes de coédition, nous avons vu que, pour un système de domaine général, on ne peut pas garder les correspondances tout le temps, parce que c’est trop compliqué. Par contre, les correspondances sont gardées dans les systèmes contrôlés, à domaine restreint, parce que dans ce cas, la syntaxe et le vocabulaire sont limités et gérables.
Il nous semble donc qu’établir les correspondances a posteriori après chaque génération du texte est viable pour un système du domaine général.
Intégration de ressources gratuites
Comme il est très coûteux de construire des ressources linguistiques, nous concevrons notre système de façon à utiliser les ressources gratuites disponibles sur le web.
Nous limitons donc les ressources utilisables à
des dictionnaires et lexiques monolingues,
des dictionnaires bilingues, l’autre langue étant presque toujours l’anglais,
des segmenteurs et/ou baliseurs (tagger),
des analyseurs morphologiques.
Tous ces outils peuvent être accédés par le web où on peut faire une requête et recevoir le résultat par un CGI. Il est aussi souvent possible de télécharger une copie de ces programmes et les faire tourner localement, voire même d’accéder à leur source et de les modifier pour les intégrer dans un autre système.
A titre d’exemple, nous présentons maintenant trois outils gratuits de catégories différentes, concernant trois langues, et décrivons les informations qu’ils nous fournissent.
PILAF (Procédures Interactives Linguistiques Appliquées au Français)
PILAF [PILAF] est un analyseur morphologique et lemmatiseur gratuit du GETA, CLIPS. Il se trouve sur le web et on peut y accéder par une page web et donc par une requête http, ou en lui envoyant une requête dans un courrier électronique. Il est aussi possible de télécharger le logiciel (code source en C) et de le faire tourner sous Unix ou Windows.
PILAF prend une phrase française en entrée et produit en sortie les formes fléchies, les lemmes, les catégories grammaticales, et les variables grammaticales, sans désambiguïsation contextuelle syntaxique. Ainsi, dans l’exemple suivant, « une » donne deux résultats (article et article substantivé – « le » ne l’est pas : « une est venue » mais pas *« le est venu »).
Voici l’interface de PILAF et la sortie de la phrase « une cité retrouvera une zone côtière après un forum » :

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 16 Interface du système PILAF
PILAF donne tous les lemmes candidats et leurs informations grammaticales, à savoir la catégorie grammaticale et les variables grammaticales. La liste complète de ces informations se trouve en Annexe D.
Autotag de CKIP
Autotag [Autotag CKIP -N‡eêÕR·e^Šû|q}] est un segmenteur et baliseur du chinois traditionnel développé par le groupe « Chinese Knowledge Information Processing » de l Academia Sinica à Taiwan. On peut le télécharger. Il y a deux versions, pour Unix et Windows. Il prend une phrase chinoise (simple ou complexe, terminée par un point chinois « 0 ») en entrée, et la sortie est une phrase segmentée en mots avec les catégories grammaticales. L analyse est basée sur un dictionnaire de 100.000 entrées intégré au programme.
Il est dommage qu Autotag ne fournisse qu’un seul résultat de segmentation, parce qu’une phrase peut souvent avoir plusieurs segmentations. En plus, en chinois, la catégorie grammaticale n’est pas facile à juger : un mot peut être un verbe, un nom ou même un adjectif selon le contexte. Donc l’analyse de catégorie grammaticale a besoin d’une retouche plus précise. Par contre, le résultat de segmentation est assez correct.
Voici un texte chinois entré :
"zlp‹(W†Þ]"jŠNI˜bޞ(WUNL„v|vU\ ÿ9hÚd P0beu„v¹eTŒT(Wƒ[„v|vU\ŒTèr„v¡{t0
Il est extrait du corpus UNL  UNLNews1 , obtenu par déconversion à partir d un graphe UNL, et grammaticalement pas tout à fait correct.
Le texte original en anglais était :
The "Resolution in Suzhou" marks a turning point in the development of the UNL, both in terms of the strategic direction and in the management of its development and deployment.
Le texte traduit par la machine en français est :
La "résolution à Suzhou" marque un tournant dans le développement de l'UNL, en termes de direction stratégique et de gestion de son développement et de son déploiement.
Le résultat de segmentation est le suivant. Pour mieux comprendre, nous avons ajouté la prononciation et la signification de chaque mot chinois. Chaque mot chinois segmenté est donc suivi d un triplet (catégorie grammaticale, prononciation, traduction française)  :
1.00(PERIODCATEGORY)0"(FW)0zlp‹(Na, jue2yi4, résolution)0(W(P, zai4, à)0†Þ](Nc, su1zhou1, Suzhou)0"(FW)0jŠ(VC, biao1ji4, marquer)0N(Neu, yi1, un)0I˜bޞ(Na, zhuan3zhe2dian3, tournant)0(W(P, zai4, à)0UNL(FW, unl, UNL)0„v(DE, de, de)0|vU\(VC, fa1zhan3, développement)0 ÿ(COMMACATEGORY)
***********************************************
2.0 ÿ(COMMACATEGORY)09hÚd(P, gen1ju4, selon)0(Nep, zhe4, ce)0 P(Nf, ge, classificateur)00beu(Na, zhan4lue4, stratégie)0„v(DE, de, de)0¹eT(Na, fang1xiang4, direction)0ŒT(Caa, he2, avec)0(W(P, zai4, à)0ƒ[(Nh, ta1, il)0„v(DE, de, de)0|vU\(Na, fa1zhan3, développement)0ŒT(Caa, he2, avec)0èr(VC,bu4shu3, déploiement)0„v(DE, de, de)0¡{t(Na, guan3li3, gestion)00(PERIODCATEGORY)
***********************************************
(P pour préposition, Na pour nom commun, Nc pour nom géographique, VC pour verbe transitif d action, Nh pour pronom, FW mot étranger, etc. Nous donnons une liste de ces catégories en Annexe D.)
Par rapport à PILAF, Autotag ne donne que les catégories grammaticales, puisqu’en chinois, il n’y a pas de conjugaison ni de déclinaison.
Voici l’interface d’Autotag. Le texte entré est dans le cadre du haut et le cadre du bas contient le résultat de segmentation :

Fig.  STYLEREF 1 \s A SEQ Fig. \* ARABIC \s 1 17 Interface du système Autotag
Les autres segmenteurs similaires du chinois sont Jasmine de l’université Chinoise de Hong Kong [Jasmine] et ICTCLAS (Institute of Computing Technology, Chinese Lexical Analysis System) [ICTCLAS]de l’Académie des Sciences Chinoise (CAS) à Pékin.
MeCab
MeCab est un analyseur morphologique du japonais développé par Université de Nara (NAIST). Il a été élaboré à partir de l’analyseur morphologique ChaSen et maintenant il est indépendant de ChaSen et a une vitesse plus élevée que ChaSen. MeCab s’exécute sur Unix et Windows. MeCab prend un énoncé en entrée. Sa sortie est textuelle et peut donc être enregistrée dans un fichier. L’utilisateur peut choisir une sortie sans ou avec les catégories grammaticales, et avec les N meilleures segmentations (N e"1). Voici un exemple d analyse sous Unix.
Le texte japonais entré est le suivant :
*Yΐo0S0n0,g’0ŒNΐ’0‹‰_0sY'`k0!nW0_00
La traduction en français est : « Taro a passé ce livre à la femme qui a vu Niro ».
Nous donnons après chaque mot japonais segmenté par MeCab sa prononciation, sa catégorie grammaticale et sa traduction française : *Yΐ (tarou, nom propre, Taro) o0 (wa, postposition, marqueur d agent) S0n0 (kono, déterminant, ce) ,g (hon, nom, livre) ’0 (wo, postposition, marqueur d objet) ŒNΐ (nirou, nom propre, Niro) ’0 (wo, postposition, marqueur d objet) ‹‰ (mi, verbe, voir) _0 (ta, auxiliaire, marqueur de l action achevée) sY'` (jyosei, nom, femme) k0 (ni, postposition, marqueur de cas datif) !nW0 (watashi, verbe, passer) _0 (ta, auxiliaire, marqueur de l action achevée)
Voici un extrait de l écran de MeCab sous Unix. La première ligne est la commande sous Unix ; la deuxième ligne est la phrase entrée et les suivantes donnent la sortie, avec sur chaque ligne un lemme et les informations grammaticales associées (catégorie grammaticale, sous-catégorie grammaticale, type de conjugaison, orthographe, orthographe en kana et prononciation).

% mecab
*Yΐo0S0n0,g’0ŒNΐ’0‹‰_0sY'`k0!nW0_00
*Yΐ
T^Š,úV g
T^Š,ºN
T,
T,*,*,*Yΐ,¿0í0¦0,¿0í0ü0
o0 ©R^Š,ÂO©R^Š,*,*,*,*,o0,Ï0,ï0
S0n0 #SO^Š,*,*,*,*,*,S0n0,³0Î0,³0Î0
,g
T^Š,N,‚,*,*,*,*,,g,{Û0ó0/â0È0},{Û0ó0/â0È0}
’0 ©R^Š,do, agt>person)" couvre seulement les sens de traiter, travailler sur, etc.
Les attributs sont le nombre (sémantique), le sexe, le temps sémantique, l'aspect, la modalité, etc., et les 41 relations sémantiques sont des "cas profonds" traditionnels comme l'agent, l'objet (profond), le lieu, le but, le temps, etc. Chaque graphe et chaque scope ont un unique nœud d’entrée marqué par l’attribut « .@entry » qui spécifie son centre sémantique. Une liste de restrictions et d’attributs et les spécification d’UNL sont données en Annexe A.
Une façon de voir un graphe UNL correspondant à un énoncé dans la langue L est de dire qu'il représente la structure abstraite d'un énoncé anglais équivalent "vu depuis L", c'est à dire où les attributs sémantiques non nécessairement exprimés en L peuvent être absents (par exemple, l'aspect si l'on vient du français, la détermination si l'on vient du japonais, etc.).
Voici un exemple d’une relation binaire UNL (un arc) :

agt(drink(icl>do).@entry.@progress, dog.@indef)

Un chien est en train de boire.
Dans cet exemple, deux nœuds portant les UW « drink(icl>do).@entry.@progress » et « dog.@indef », sont reliés par la relation « agt » (agent). Chaque nœud porte une UW (Universal Word), et des attributs.
Une UW est composée d’une « tête » (Headword) et d’une liste de restrictions. Ici, « drink » et « dog » sont deux têtes. « drink » a une restriction « (icl>do) » pour préciser qu’il s’agit du sens du verbe d’action. Enfin, chaque attribut est précédé de « .@ ». Ici « .@progress » exprime l’aspect progressif de l’action.
Pour construire un graphe UNL, il faut choisir des UW pour représenter les sens des mots, et les relier de façon cohérente. La KB (Knowledge Base) sert à définir l’ensemble des UW et les relations possibles entre deux UW. Bien qu’une UW représente en général un ensemble de sens, on l’appelle souvent « concept » par abus de langage.
Voici un exemple complet de graphe UNL, avec les énoncés correspondants en français et en anglais, et la représentation graphique.

{unl}
agt(regret(icl>do).@entry, he)
obj(regret(icl>do).@entry, :01)
agt:01(come(agt>human,gol>place).@entry.@future.@not, you)
and(regret(icl>do).@entry, know(agt>human,icl>event))
agt(know(agt>human,icl>event), he)
obj(know(agt>human,icl>event), :01)
{/unl}
anglais:”He knows that you will not come and he regrets it.”
français :« il sait que tu ne viendras pas et il le regrette. »
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 14 Exemple d’un graphe UNL complet
La KB définit aussi une hiérarchie entre ces concepts. Les concepts appartiennent à l’une des catégories suivantes :
- concept verbal, noté par la restriction (icl>do)
- concept nominal, noté par la restriction (icl>thing)
- concept adjectival, noté par la restriction (modhow)
Cette hiérarchie est définie par 3 relations : « icl (included » définit la relation d’inclusion des concepts, « iof (instance of ») définit la relation d’instance, « equ (equal to) » définit la relation de synonymie.
Bien sûr, il est impossible de définir en extension toutes les relations entre toutes les paires de concepts. On profite de la hiérarchie de la KB pour réduire le nombre des relations. Les concepts héritent des caractéristiques de ceux placés plus haut ; les concepts du haut peuvent éventuellement remplacer les concepts du bas.
Les relations possibles entre deux UW sont définies dans la MD (Master Definition).
Voici une figure qui explique la fenêtre de la MD [Uchida 01] :

Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 15 Cadre de « Master Definition »
Nous utilisons la figure suivante pour expliquer la relation entre la KB et la MD : dans la hiérarchie de la KB, le sommet est « UW » (Universal Word), qui domine quatre catégories. Les concepts nominaux héritent automatiquement la MD de « UW » (MD1), et ont leur propre MD (ici MD2). Donc la MD des concepts nominaux est en fait ({MD1} MD2). Les accolades signifient que MD1 est facultative, puisque « noun concept » est fils de « UW ». De même, UW2 et UW1 sont tous descendants des concepts nominaux, et donc ils héritent MD1 de UW et MD2 des concepts nominaux. En plus, UW2 hérite aussi la MD3 de UW1, et sa MD est donc ({MD1+MD2+MD3} MD4).
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 16 Héritage de «Master Definition »
Pour les spécifications de la KB et des MD, voir l’Annexe A.
Exemples du pivot
Il y a deux formes d’écriture linéaire du graphe UNL : tableau et liste.
Voici un exemple sur un graphe signifiant :

en anglais : “I can hear a dog barking outside.”
en français : « Je peux entendre un chien aboyer dehors. »
(I) forme tableau

{unl}
aoj(hear(icl>perceive(agt>thing,obj>thing)).@entry.@ability, I)
obj(hear(icl>perceive(agt>thing,obj>thing)).@entry.@ability, :01)
agt:01(bark(agt>dog).@entry, dog(icl>mammal))
plc:01(bark(agt>dog).@entry, outside(icl>place))
{/unl}
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 17 Représentation graphique d’un graphe UNL

(II) forme liste (nous marquons dans la  REF _Ref61872536 \h Fig. B17 le numéro de chaque nœud)

{unl}
[W]
I:01
hear(icl>perceive(agt>thing,obj>thing)).@entry.@ability:02
dog(icl>mammal):03
bark(agt>dog).@entry:04
outside(icl>place):05
:01:06
[/W]
[R]
02aoj01
02obj06
04agt:0103
04plc:0105
[/R]
{/unl}

Voici un extrait des premières lignes de la KB:

Universal Word
uw{(equ>Universal Word)}
adjective concept{(icl>uw)}
uw(aoj>thing{,and>uw(aoj>thing),ben>thing,cao>thing,cnt>uw(aoj>thing),cob>thing,con>uw(aoj>thing),con>do,con>occur,coo>uw(aoj>thing),coo>do,coo>occur,dur>period,man>how,obj>thing,or>uw(aoj>thing),plc>thing,plf>thing,plt>thing,rsn>uw(aoj>thing),rsn>do,icl>adjective concept})
Afghan({icl>uw()aoj>thing{}})
African({icl>uw()aoj>thing{}})

Bien entendu, ces deux dernières UW héritent automatiquement de toutes les caractéristiques de l’UW du concept adjectival (« adjective concept »).
Voici un autre exemple de KB qui montre sa hiérarchie :

phenomenon(icl>event{>abstract thing})
accident(icl>phenomenon{>event})
contingency(icl>accident{>phenomenon})
aging(icl>phenomenon{>event})
aging of population{(icl>aging>phenomenon)}
brain death{(icl>phenomenon>event)}
cerebral death{(icl>brain death)}
bustle(icl>phenomenon{>event})
change(icl>phenomenon{>event})
circulation(icl>phenomenon{>event})
climate(icl>phenomenon{>event})
weather(icl>climate{>phenomenon})
rain(icl>weather{>climate})
hail(icl>rain{>weather})
shower(icl>rain{>weather})
snow(icl>rain{>weather})
conformity(icl>phenomenon{>event})
contact(icl>phenomenon{>event})
contingency(icl>phenomenon{>event})
convergence(icl>phenomenon{>event})
current(icl>phenomenon{>event})
electric current{(icl>current>phenomenon)}
ocean current{(icl>current>phenomenon)}
East Africa Coast current{(icl>ocean current)}
East Australia current{(icl>ocean current)}
East Greenland current{(icl>ocean current)}
equatorial current{(icl>ocean current)}
existence(icl>phenomenon{>event})
explosion(icl>phenomenon{>event})
extinction(icl>phenomenon{>event})
impact(icl>phenomenon{>event})
incidence(icl>phenomenon{>event})
increment(icl>phenomenon{>event})
life(icl>phenomenon{>event})
light(icl>phenomenon{>event})
logical phenomenon{(icl>phenomenon>event)}
natural phenomenon{(icl>phenomenon>event)}
heavenly phenomenon{(icl>natural phenomenon)}
day(icl>heavenly phenomenon)
daytime(icl>day{>heavenly phenomenon})
evening(icl>heavenly phenomenon)
dusk(icl>evening{>heavenly phenomenon})
morning(icl>heavenly phenomenon)
dawn(icl>morning{>heavenly phenomenon})
sunrise(icl>morning{>heavenly phenomenon})
night(icl>heavenly phenomenon)
physical phenomenon{(icl>phenomenon>event)}
physiological phenomenon{(icl>phenomenon>event)}
breath(icl>physiological phenomenon)
gasp(icl>breath{>physiological phenomenon})
sigh(icl>breath{>physiological phenomenon})
reappearance(icl>phenomenon{>event})
La KB est une partie essentielle du « système UNL ». Le centre UNL s’occupe de sa maintenance et de sa création. Les autres équipes de développement peuvent regarder la KB avec un navigateur de web par l’interface (UW Gate) fournie par le centre UNL.
Pivots candidats pour la coédition multilingue
Nous avons vu au total 8 systèmes à pivot, dont 5 à pivot interlingue. Voyons maintenant les avantages des différents types de pivot, pour déterminer le plus adapté à notre projet.
Une LN
L’avantage est que l’utilisateur peut comprendre facilement “le langage pivot” s’il connaît cette langue.
Mais cela n’aide pas la TA, car le problème intrinsèque d'ambiguïté pour chaque langue naturelle est très fort. Prenons l’exemple de Systran : si nous utilisons les modules de français-anglais et anglais-allemand pour faire la traduction français-allemand, le résultat est très pauvre.
Le seul projet exploitant une langue naturelle (sans « parenthèses cachées » comme dans DLT) comme pivot a été ATAMIRI [Guzman de Rojas 88]. L’idée initiale étant que l’aymara était une langue naturelle non ambiguë. Bien entendu, c’est faux, et le projet a rencontré toutes les difficultés prévisibles liées à l’ambiguïté intrinsèque de toute langue naturelle.
De toutes façons, en ce qui concerne la coédition multilingue, une langue naturelle n’est pas une candidate idéale pour être le pivot, car on n’a jamais eu la possibilité ou la capacité de coéditer deux langues naturelles, sauf pour des énoncés « à trous » comme dans Ambasaddor..
Une LN « balisée »
C’est l’approche de DLT. L’avantage est le même que celui de la langue naturelle.
De plus, en ajoutant des balises, on peut en fait décrire une structure « concrète » désambiguïsée.
Le problème est qu’une structure concrète reflète nécessairement la structure de surface de la langue, même si elle est « multiniveau ». Il faut donc très bien connaître la structure de surface de la langue en question pour pouvoir utiliser cette structure. Or ce n’est pas le cas pour la plupart des développeurs.
Interlingua spécialisé
Ce type de pivot peut être très précis, puisqu’il est conçu pour exprimer des concepts d’un domaine restreint. Il profite aussi des spécificités des énoncés relatifs aux tâches envisagées dans ce domaine. Il convient pour des domaines assez restreints, mais pas pour le domaine général.
Prenons l’exemple du langage IF dans le projet NESPOLE!: il encode beaucoup d’actions du domaine. Il y a beaucoup de connaissances du domaine codées et sous-entendues dans cet interlingua. Mais, si on passe au domaine général, et à des énoncés plus variés, on n’arrive plus à représenter les énoncés dans un tel IF. Selon [Boitet 01], l’expérience de l’extension d’IF en C-STAR II au domaine général a été un échec. Il y a eu des dizaines de changements de spécifications, et on avait des représentations ambiguës et malgré tout incomplètes.
Chaque domaine a ses caractéristiques. Par exemple, dans le domaine des manuels de maintenance, l’expression temporelle est presque toute le temps absente, car il s’agit de l’expression de connaissances objectives. Par contre, dans le domaine de la réservation d’hôtel, il y a beaucoup de formes de politesse, et la connaissance subjective joue un rôle important. Il est difficile de passer à un domaine trop éloigné.
Bien que la portabilité de ce genre de pivot soit possible [Lavie 01a], il s’agira toujours d’un autre domaine restreint. L’IF est un interlingua « orienté vers la tâche » (task-oriented) et il semble impossible d’étendre sa puissance descriptive au domaine général.
Interlingua général
Pour que le résultat de traduction soit encore plus satisfaisant, on peut coupler l’interlingua général avec un modèle du monde (KB « Knowledge Base » ou une vraie ontologie « généraliste »).
Mais un tel modèle est très difficile et coûteux à construire et à maintenir.
Sept critères de choix
Nous avons trouvé dans la littérature deux critères pour qu’un interlingua soit bon:
« Un bon interlingua est fait pour exprimer non seulement ce qui est dit, mais aussi comment les choses sont dites. Donc il faut lui donner la capacité d’exprimer les connaissances subjectives » [Uchida 80].
Selon [Schubert 88], un interlingua doit satisfaire au moins trois critères : autonomie (indépendance des langues naturelles), expressivité, et régularité.
Partant de là, nous proposons les sept critères suivants :
Simplicité : Si ce pivot s’utilise avec une architecture distribuée, c’est-à-dire si les sites locaux peuvent produire leur document en pivot avec une certaine consistance, ce pivot doit être facile à maintenir et à comprendre.
Généralité : Nous voulons que ce pivot ne soit pas restreint à certains domaines, mais puisse exprimer avec assez de précision des énoncés non restreints à un domaine ou une tâche particuliers.
Expressivité : Nous voulons que ce pivot soit capable d'exprimer tous les concepts des énoncés dans toutes les langues naturelles, y compris le plus possible des aspects « subjectifs » (type d’énoncé, attitude du locuteur, etc.).
Intégralité : Puisque nous voulons coéditer le texte et le pivot, il est souhaitable que le pivot puisse porter toutes les informations au niveau considéré, qu’il s’agisse de sémantique, de pragmatique, ou de référence. Si toutes les informations possibles ne sont pas présentes dans une représentation pivot, on dira qu’il est « sous-spécifié ». Par exemple, la détermination abstraite (deixis) sera souvent absente si la forme pivot résulte d’une analyse d’un énoncé dans une langue sans article (russe, japonais, chinois, thaï, etc.).
Lisibilité : Ce pivot devrait être facile à lire et à comprendre, au moins avec un entraînement minimal, et un expert devrait pouvoir produire un document dans ce pivot sans trop de peine.
Indépendance : Ce pivot devrait utiliser un vocabulaire indépendant de toutes les langues naturelles, notant l’union des « acceptions » (sens de mots) des différentes langues.
Facilité de production : Ce pivot doit pouvoir être généré automatiquement par la machine, ou au moins semi-automatiquement par des experts dans un environnement adapté.
Le langage UNL comme pivot pour la coédition
La discussion ci-dessus nous mène à choisir UNL comme pivot pour notre système de coédition. Nous revenons en détail sur les raisons de ce choix, puis présentons les ressources déjà développées pour UNL.
Pourquoi UNL?
UNL est un bon pivot dans un système de coédition pour les raisons suivantes :
il est spécialement conçu pour le traitement linguistique et sémantique par ordinateur,
il a été dérivé avec beaucoup d'améliorations du langage pivot de H. Uchida utilisé dans ATLAS-II de Fujitsu ADDIN ENRfu , toujours évalué comme le système de TA anglais-japonais de meilleure qualité, avec une très grande couverture (plus d’un million d’entrées par langue),
les participants du projet UNL ont construit des "déconvertisseurs" d'UNL vers environ 12 langues, parmi lesquels au moins ceux allant vers l'arabe, l'indonésien, l'italien, le français, le russe, l'espagnol et le thaï étaient accessibles pour l'expérimentation fin 2003,
bien qu'ils soient de nature formelle, les graphes UNL (voir ci-dessous) sont assez simples à comprendre avec peu de formation et peuvent être présentés de façon localisée à des utilisateurs "naïfs" en traduisant les symboles (relations sémantiques, attributs) et les lexèmes du langage UNL par des symboles et des lexèmes de leur langue,
le projet UNL a défini un format "UNL-html" intégré à html pour des fichiers contenant un document multilingue complet aligné au niveau des énoncés, et a produit un "visualiseur" qui transforme un fichier dans ce format en autant de fichiers html que de langues, et les envoie à n'importe quel navigateur web.
Nous montrons ensuite ce format du document « UNL-html » et nous discuterons l’exploitation de ce format plus tard dans la section B.2.4.

[D:dn=Mar Aral version final,on=UNL Spain,mid=carde@opera.dia.fi.upm.es]
[P:1] [S:1]
{org:es}Yo corri ayer en el parque.{/org}
{unl}
agt(run.@entry.@past,i)
plc(run.@entry.@past,park.@def)
tim(run.@entry.@past,yesterday)
{/unl}
{cn}b(f)Y(WlQWáˆÑek{/cn}
{de}{/de}
{el}Yesterday I ran in the park. {/el}
{es}Yo corri ayer en el parque.{/es}
{fr}J ai couru hier dans le parc.{/fr}
[/S][/P][/D]
Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 18 Document « UNL-html »
Ressource construites
Nous présentons maintenant les modules d’UNL construits par le centre UNL (UC, UNL Center) et par les centres de langues (LC, Language Center). Ainsi, nous aurons une vision globale de ce projet et de son environnement.
Pour la transformation entre la langue naturelle et le graphe UNL
Un déconvertisseur transforme un graphe UNL en un énoncé en langue naturelle. Les déconvertisseurs sont développés par les LC, sauf les déconvertisseurs anglais et japonais qui sont développés par UC. Les déconvertisseurs développés avec les outils de UC sont copiés sur le serveur de UC. Dans le centre UNL tournent les déonvertisseurs arabe, chinois, anglais, hindi, italien, indonésien, japonais, portugais, russe (version de 2001), espagnol et thaï (version de 2002). Sur les LC, il y a les déconvertisseurs arabe, français, italien, russe, espagnol, et thaï. Il existe aussi une autre version du déconvertisseur chinois, que nous pouvons télécharger depuis le site UNL-chinois.
Le centre UNL fournit un langage spécialisé, DeCo, qui est indépendant de la langue naturelle et spécialement conçu pour la déconversion [UNL DeConverter 97]. DeCo se compose d’un compilateur et d’un moteur. DeCo s’occupe de la génération sémantique, syntaxique et morphologique en même temps.
Tous les centres locaux n’utilisent pas forcément DeCo. Selon [Sérasset 99], DeCo est trop simpliste pour les langues fortement fléchies comme le français et donc les centres français et russe ont utilisé leurs propres systèmes pour la déconversion. Dans [Nunes 01] il y a une explication détaillée pour la réalisation de ce module et l’écriture des règles.
Un enconvertisseur transforme un énoncé d’une langue naturelle en un graphe UNL. Pour l’instant, seul l’enconvertisseur de l’arabe est accessible sur Internet. D’autres (russe, espagnol, français, japonais) existent à l’état de prototypes sur les sites locaux.
Le centre UNL fournit aussi le langage spécialisé EnCo qui permet d’écrire des enconvertisseurs. Il peut aussi faire la désambiguïsation basé sur la KB et le contexte [Uchida 01].
UDS (UNL Development Set) est l’ensemble des outils fournis par le centre UNL pour faciliter la production de composants UNL. Il comprend DeCo, EnCo, et des outils pour construire le dictionnaire. Cela rend le projet assez modulaire. Pour ajouter une nouvelle langue dans le projet, il suffit d’écrire les règles de grammaire de cette langue en EnCo et DeCo, et le dictionnaire dans le format UNL.
Un déconvertisseur synchrone multilingue peut envoyer un graphe UNL à plusieurs déconvertisseurs et afficher les résultats obtenus en parallèle. Ce programme a été réalisé sous la direction de l’auteur par une étudiante pendant son stage de maîtrise [Jitkue 01]. Ce programme se trouve sur le site web SWIIVRE [SWIIVRE].
Pour l’intégration de la connaissance du monde réel
KB (Knowledge Base) est la « base de connaissances » du projet UNL. Ses concepteurs pensent qu’elle exprime les connaissances du monde réel, et fonctionne comme l’ontologie dans les systèmes de KBMT (Knowledge-based Machine Translation). C’est exagéré, car cette KB ne fait que définir la hiérarchie des UW, mais ne comporte absolument aucune des possibilités classiques (cadres, attributs, méthodes, typage, mécanismes d’inférence, etc.). La KB décrit aussi les relations sémantiques possibles entre 2 UW, et la hiérarchie de ces UW. Cette simplicité permet d’envisager d’atteindre une taille importante, nécessaire pour l’usage attendu, qui est la désambiguïsation. Le but de H. Uchida est d’arriver à 1,5 millions d’entrées, beaucoup plus que les 8000 concepts d’ONTOS par exemple, ou que les 6000 classes sémantiques d’ALT/JE. C’est sans doute une bonne voie, car ici la quantité prime sur la finesse de description.
La KB est accessible en lecture sur le site web du centre UNL. Voici une image de la KB.

Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 19 La KB présentée sur le site du centre UNL
Le Master Dictionary est l’ensemble des dictionnaires. Il est intégré et géré par le centre UNL. On peut le consulter soit par headword, soit par UW, ou par un mot en langue naturelle. Le résultat est l’ensemble de tous les mots dans toutes les langues naturelles qui sont liés à cette UW.
Pour chaque langue Lg, il y a au moins un dictionnaire UNL-Lg. On peut utiliser le Dictionary Builder, qui se trouve au centre UNL, pour faciliter la maintenance et la construction de ce dictionnaire.
Chaque entrée de ce dictionnaire est de la forme « [lemme-Lg]{infos-Lg}”UW”;commentaire ». Voici un exemple :

« [aborder]{CAT(CATV), AUX(AVOIR), VAL1(GN)}"address(icl>do(obj>thing)"; »

Chaque ligne représente une entrée, comprenant un lemme de la langue Lg placé entre crochets, puis les informations linguistiques associées entre accolades. On trouve ensuite l’UW correspondante entre guillemets, et finalement un point-virgule éventuellement suivi d’un commentaire. Une page extraite du dictionnaire UNL-français est donnée en Annexe E.
Des copies des dictionnaires UNL-Lg se trouvent sur le site du centre UNL et dans les centres locaux. Au GETA, nous avons le dictionnaire UNL-français maître, qui comptait 38723 lemmes simples ou composés en octobre 2003, et des copies des dictionnaires UNL-Lg pour plusieurs autres langues. Nous les gérons à travers une base de données utilisable à travers le site Dicoweb [Dicoweb]
Selon les besoins des divers projets, de plus petits dictionnaires sont fabriqués. Le plus gros d’entre eux est le dictionnaire médical français-allemand-anglais-UNL qui compte 2045 entrées.
Au centre UNL, on trouve aussi, entre autres, les dictionnaires japonais-UNL avec 168766 entrées, russe-UNL avec 27484 entrées, et italien-UNL avec 21239 entrées.
Pour la génération du graphe UNL
Éditeur de Graphe UNL: au moins trois éditeurs ont été développés par les équipes française (trois versions), indonésienne, espagnole.
Nous montrons d’abord ici l’interface de l’éditeur UNL de l’équipe indonésienne. Cet éditeur a été créé à la demande du centre UNL. Il est écrit en Java. Pour créer un graphe UNL, il faut d’abord enregistrer les informations de ce graphe.

Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 20 Éditeur UNL de l’équipe indonésienne (I)
Puis l’utilisateur peut cliquer sur un nœud pour éditer les informations sur ce nœud ou visualiser le graphe UNL sous forme textuelle. L’éditeur permet aussi les manipulations sur un graphe, par exemple, ajouter un sous-nœud, supprimer un graphe, etc.
Cet éditeur peut prendre un document UNL entier et naviguer dans le document phrase par phrase. La distribution de cet éditeur est limitée aux membres d’UNL.

Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 21 Éditeur UNL de l’équipe indonésienne (II)
A part cet éditeur, il y a aussi plusieurs autres éditeurs de l’équipe française et de l’équipe espagnole. Ils sont tous réservés à l’usage interne.
Des corpus UNL sont collectés sur le site SWIIVRE (voir Partie C. Section 2.1 pour plus de détails sur ces corpus).
Un vérificateur UNL vérifie la syntaxe d’un graphe UNL ou de tout un document. Ce programme se trouve sur le site du centre UNL [UNL]. De plus, tous les déconvertisseurs intègrent un parseur et donc un vérificateur de graphe UNL. Par exemple, les déconvertisseurs français et russe affichent un message d’erreur quand le graphe UNL entré n’est pas légal.

Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 22 Vérificateur UNL
Pour l’utilisation sur le web
Nous avons construit le site web SWIIVRE [SWIIVRE] pour fournir des informations sur UNL et nous servir de plate-forme d’expérimentation de la coédition et de son utilisation sur le web.
L’UNL viewer du centre UNL permet de la visualisation d’un document UNL et la connexion entre l’utilisateur et les serveurs de langue. Nous discuterons plus en détail deux approches principales pour visualiser un document UNL dans la section B. REF _Ref64290171 \n 2.4.2.
L’UNL proxy sert à visualiser des pages web en UNL. C’est un programme client écrit en Java installé sur un PC. Il fonctionne comme un filtre avant le navigateur pour extraire la langue spécifiée par l’utilisateur s’il s’agit d’une page web en UNL. Sinon, il transmet telle quelle la page web au navigateur. L’utilisateur peut aussi remplir les données de tous les déconvertisseurs et enconvertisseurs sur le web et l’UNL-proxy pour les contacter pour la déconversion ou l’enconversion.
Voici une figure de la structure d’UNL-Proxy [Hasan 01]:
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 23 UNL proxy
Une bonne part de ces modules est conçue pour l’environnement web+Windows+PC+chercheurs du projet UNL. Ils ne sont donc pas accessibles par tout le monde depuis toutes les plates-formes. Le centre UNL ne fait pas de promotion pour ces modules et donc ils restent seulement connus entre les membres de la société UNL (UNL Society). Beaucoup d’entre eux sont conçus sans penser à l’utilisabilité et sans une maintenance continue. Il y a encore des problèmes comme le versionnage, le codage, etc. qui ne sont pas abordés. L’intégration de ces outils et la conception d’un environnement pour l’utilisateur ordinaire sont en cours.
Le langage UNL
Ici nous entrons dans le détail pour présenter ce que sont les graphes UNL et leurs avantages pour la coédition.
Relations, UW, scope
La base du langage UNL est la relation binaire. Une relation binaire se compose de deux UW (Universal Word) munies d’attributs et d’une relation. Une relation correspond un peu près à un cas profond (sémantique). Dans la version des spécifications la plus récente (datée du 12/2002), il y a 41 relations. A part cela, il y a aussi 3 relations réservées à la KB et à la définition de la hiérarchie des UW : icl, iof, equ. Une liste complète de toutes les relations se trouve en Annexe A.
Les attributs sont destinés à exprimer les informations subjectives d’un graphe UNL. Il s’agit de la perspective du locuteur, de l’aspect ou des temps (abstraits), du mode, et aussi de l’acte de parole, de l’attitude propositionnelle, et de la valeur logique (truth value).
Dans les spécifications d’UNL (version 3 édition 1 datée du 20/02/2003), il y a 72 attributs divisés en 7 catégories :
temps (abstraits) – présent, passé, futur
aspect d’une action – achevée, inachevée, progressive, itérative, durative, fréquentative, etc.
référentielle – générique, définitive ou négative
centre d’énoncé – centre sémantique, mise en relief, titre, thème, etc.
attitude du locuteur – confirmation, ordre, politesse, interrogation, etc.
perspective du locuteur – capacité, possibilité, condition, conséquence, etc.
convention – marques de ponctuation

Une UW représente un concept simple ou un concept composé [Uchida 01]. Chaque UW se compose d’une chaîne de caractères (un mot ou terme anglais) suivie par une liste de restrictions. Il y a trois catégories d’UW : basique, restreinte, et spéciale.
Une UW basique est représentée par un mot/un mot composé/une phrase/un énoncé anglais, qui exprime un concept proche de celui exprimé par cette chaîne de caractères en anglais. Elle peut donc être ambiguë.
Une UW restreinte est une UW basique désambiguïsée par une liste de restrictions. Nous trouvons les exemples suivants dans [Uchida 01] :
L’UW basique « state » peut avoir plusieurs sens, parce que le symbole « state » a plusieurs sens en anglais. Pour la désambiguïser, il suffit d’ajouter une liste de restrictions après elle, et on obtient les UW restreintes suivantes :

state(icl>do(obj>thing)) – représente le verbe « constater » en français
state(icl>nation) – représente la nation ou l’État
state(icl>situation) – représente la situation ou le stade
state(icl>government) – représente le gouvernement.
une liste de restrictions peut aussi préciser le sens d’un mot qui a un sens plus vague :

orange(icl>tree) – oranger
orange(icl>fruit) – orange
orange(icl>colour) – orangé
On utilise aussi les UW contraintes quand le symbole n’est pas ambigu en anglais, mais correspond à plusieurs mots ressentis comme de sens différents dans une autre langue, par exemple :
« marry(icl>do) » (se marier) n’est pas ambigu en anglais, mais, en russe ou en chinois, il y a deux mots selon qu un homme ou une femme se marie. Donc il faut ajouter une restriction :

marry(agt>male)  « 65=8BLAO » (russe), « 6Z qu3 » (chinois)
marry(agt>female)  « 2KE>48BL 70activity, obj>flower) – art floral japonais
samba(icl>dance) – genre de danse
soufflé(icl>food, pof>egg) – aliment fabriqué avec des œufs

Enfin, on peut indiquer indirectement la catégorie (sémantico-pragmatique) de l’UW, pour économiser le nombre des symboles et exprimer plus de sens :

answer(icl>do) – « do », donc prédicat (verbe « répondre », « to answer »)
answer(icl>thing) – « thing », donc entité (substantif, « réponse »)

weekly(icl>how) – par semaine
weekly(modoccur).@past.@entry.@not, river.@def.@pl)
man(flow(icl>occur).@past.@entry.@not, almost)
rsn(flow(icl>occur).@past.@entry.@not, :01)
obj:01(block(icl>do).@past.@entry, river.@def.@pl)
agt:01(block(icl>do).@past.@entry, dam.@pl)
{/unl}
{fr}Bloquées par des barrages, les rivières ne coulaient presque plus.{/fr}
{el}Blocked by the dams, the rivers almost stopped flowing.{/el}
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 24- Scope avec arc allant vers l'extérieur
Problème de sous-spécification
Comme déjà constaté dans [Boitet 88b], le problème de sous-spécification est très connu en TA multilingue. Un projet multilingue comme UNL, qui couvre plusieurs langues très éloignées, ne peut pas y échapper.
Un graphe UNL correspond à un énoncé dans la langue L exprimé en anglais. Dans un graphe créé par un locuteur chinois, la détermination est très souvent sous-spécifiée parce qu’il n’existe pas d’article en chinois. Les nœuds correspondant aux noms dans un graphe UNL créé à partir du chinois n’auront donc le plus souvent pas d’attribut de détermination, et donc le graphe sera sous-spécifié de ce point de vue par rapport aux langues à articles.
De même, pour déconvertir en arabe, il faut l’indication du duel, absente si le graphe est produit à partir d’une langue sans duel.
Même si un graphe UNL provient d’une langue assez proche de l’anglais, il est difficile de le rendre neutre et complet. Nous avons vu des graphes UNL « à l’espagnole » et « à la française ». On constate que l’exploitation de l’article ou du pluriel dans les représentations UNL de ces langues est différente, et cela peut créer des ambiguïtés.
Pour résoudre cela, il faut d’abord établir un consensus sur les spécifications pour avoir la possibilité d’ajouter autant d’attributs que nécessaire, tout en restant dans des limites raisonnables. Mais, même si les spécifications d’UNL permettaient aux utilisateurs de spécifier tous les phénomènes de langue, les enconvertisseurs, même aidés par les utilisateurs, risqueraient de ne pas toujours bien mettre tous les renseignements dans le graphe, simplement parce qu’ils ignorent que certains renseignement sont cruciaux dans la déconversion vers d’autres langues. Il faut donc pouvoir les ajouter a posteriori, après la déconversion, quand les erreurs dans le texte sont constatées.
Pour l’instant, les relations et attributs ne sont pas suffisants pour exprimer tous les phénomènes de langue. En fait, on doute fortement qu’un tel interlingua complet puisse un jour exister. Mais nous pouvons ajouter des attributs pour améliorer l’expressivité d’UNL. Avec la grande couverture et la variété des langues qu’il couvre, UNL est d’ailleurs bien placé pour constater les manques et y remédier.
Nécessité d’une « normalisation » de la méthode de représentation des phénomènes linguistiques en UNL
Bien que les relations UNL correspondent à peu près aux rôles sémantiques, l’expérience montre qu’il est impossible d’avoir une interprétation consistante des relations argumentaires (valences logiques fortes) par ces 41 relations. Le fait qu’il y a 15 groupes de participants venant de pays différents complique encore l’interprétation de ces relations UNL.
Un comité a donc été établi en 2000 après le symposium UNL à Genève pour examiner les spécifications d’UNL et pour promouvoir un « bon encodage » en UNL. Ensuite, le projet FB2004 [FB2004] a expérimenté l’encodage proposé par une procédure d’expérimentation et de débat public.
Selon les conclusions de ces projets, publiées dans plusieurs colloques UNL [Boguslavsky 02a, 02b] [Boitet 02d], la correction et la non-ambiguïté d’une expression UNL ne suffisent pas pour une déconversion correcte vers autres langues ; on doit chercher à produire des expressions UNL adéquates. Une expression UNL adéquate doit non seulement préserver le sens du texte original, mais aussi être facile à utiliser dans les applications, y compris la déconversion vers d’autres langues.
Les problèmes principaux qui empêchent l’encodage dans une forme adéquate sont les suivants :
Les UW composées de plusieurs mots : par exemple « International Monetary Fund », « Ministery of foreign affairs », etc. Les noms propres de ce genre sont innombrables et donc il est impossible de créer une entrée dans le dictionnaire pour chacun comme fait le centre UNL.
Les verbes support : UNL utilise des symboles issus de l’anglais, mais les verbes support ne sont en général pas les mêmes dans les autres langues. Par exemple, pour exprimer « prendre une douche », en anglais « take a shower », le verbe support est « take ». Mais le verbe support en russe sera « recevoir », et en chinois « se laver ». Idem pour les verbes composés « take an action », « give a lecture », « make an impression », etc. Il est difficile de déconvertir correctement si on ne considère que le verbe lui-même. Il faut donc que l’analyse reconnaisse les cas où un verbe est verbe support, et alors le traduise dans l’UW correspondant au verbe support anglais, ou bien traduise tout le prédicat composé en une UW adéquate.
Les relations prédicat-argument : les spécifications UNL ne permettent pas de spécifier les arguments d’un prédicat, ni dans le dictionnaire ni dans les graphes.
Le problème de la distinction entre restrictif et non-restrictif – par exemple, dans la phrase anglaise « Wise Greek diluted the wine with water », « Greek » peut être restrictif (seulement les Grecs intelligents diluent le vin dans l’eau, les stupides non) ou non-restrictif (généralement les Grecs sont intelligents et ils diluent le vin dans l’eau). Dans les spécifications UNL, il n’y a pas de moyen de faire cette distinction. Or, c’est important en français de distinguer « Les Grecs » et « Des Grecs », ou encore, « Les Grecs intelligents, » (épithète) et « Les Grecs, intelligents, » (attribut).
Les conventions sur les attributs : on n’est pas sûr si par exemple, une UW sans marque « .@def » a pour valeur « indéfini », ou simplement si l’encodeur ou l’enconvertisseur n’a pas pu ou voulu la noter ou pu la calculer. De plus, il y a des mots anglais qui ont des sens différents au singulier et au pluriel, et dans ce cas un attribut « .@pl » attaché à l’UW associée peut être ambigu.
Le problème des anaphores : il est important pour des langues comme le français d’avoir cette information, souvent inter phrastique, pour décider le genre des noms anaphoriques, mais elle est absente d’UNL qui n’a pas d’attribut .@eld permettant de mettre à la place de l’UW « it », « he », « the », l’UW référée, qu’elle soit ou non dans la même phrase.
De façon générale, comme un graphe UNL correspond à une seule phrase, les informations inter phrastiques ne peuvent pas être exprimées.
Plusieurs solutions ont aussi été proposées dans ces articles pour résoudre ces problèmes. Il faudra voir dans les projets futurs si ces propositions peuvent être respectées et améliorer de la qualité des expressions UNL.
Nécessité de « normalisation » de la procédure de l’encodage entre les équipes
Problème
En plus de la normalisation de l’expression en UNL que nous avons discutée ci-dessus, il y a aussi le développement des UW d’UNL qui retient l’attention. Il s’agit de la synchronisation des dictionnaires des différentes équipes. Chaque équipe doit mettre au point non seulement son déconvertisseur, mais aussi son dictionnaire.
En théorie, le vocabulaire UNL devrait être centralisé dans la KB, et chaque groupe devrait s’assurer que ses UW sont cohérentes avec celles des autres groupes. Mais malheureusement ce n’est pas le cas. Les entrées dans la KB n’arrivent jamais à couvrir le vocabulaire dont les équipes locales ont besoin.
Par contre, on est arrivé à une telle homogénéisation dans le sous-projet FB2004, avec seulement 5 langues, et une organisation pratique beaucoup plus efficace que celle de la KB.
Projet FB2004
Disons donc quelques mots de ce projet. FB2004 signifie « Forum Barcelona 2004 ». Dans le projet FB2004-UNL, il s’agissait de préparer un démonstration. Le projet fut lancé en avril 2001. Les textes originaux sont en espagnol et en anglais, et le contenu est l’introduction du festival écrite par le directeur de l’UNESCO. Cela constitue un corpus d’environ 2800 mots (11 pages environ). Cinq équipes ont participé à ce projet : espagnole, italienne, russe, française, et indienne.
Ce projet avait aussi pour but de développer une méthode de coopération entre les équipes.
Le projet a eu deux phases : dans la première phase, les équipes française, espagnole, italienne et indienne ont partagé l’enconversion de 30 phrases parmi les 122 phrases du document, et l’équipe russe a été l’intermédiaire pour le débat et la discussion de l’encodage du graphe UNL. Toutes les équipes devaient aussi commenter les graphes enconvertis par les autres équipes. Un forum web a été établi pour cela. Une fois que tout le monde a été d’accord avec les graphes enconvertis, les graphes ont été déconvertis dans les 5 langues.
Deux articles écrits par Boguslavsky [Boguslavsky 01a, 01b] contenant les conseils de bon encodage et sont disponibles sur le site du projet [FB2004]. Dans la phase II, la même procédure a été appliquée aux 92 phrases restantes.
La procédure d’encodage coopératif entre les équipes a été définie comme suit [Cardeñosa 01a, 01b] :
étape 1 : soumission du code UNL.
étape 2 : soumission par courriel.
étape 3 : collecte des UW.
étape 4 : collecte des données sur les coûts d’encodage.
étape 5 : inspection du code UNL.
étape 6 : discussion sur le forum du site web du projet FB2004-UNL.
étape 7 : correction du code UNL avec le tableau d’UW de la dernière version.
étape 8 : inspection du graphe UNL avec le résultat de la déconversion.
étape 9 : collecte des données des coûts de la déconversion.
étape 10 : collecte des données des coûts de la post-édition.
L’intérêt de ce projet est que, pour la première fois, des équipes locales se sont unies pour évaluer la qualité des graphes UNL et discuter de la façon d’arriver à un bon encodage.
On a essayé d’évaluer le coût d’encodage et de déconversion, bien que le résultat ne soit pas listé sur le site. On a aussi proposé une méthode pour collecter les UW pour que la procédure d’encodage soit plus efficace.
La procédure d’unification des UW est assez simple : le fournisseur du texte original fournit une liste des UW des expressions UNL du projet avec le texte original et les graphes UNL. Dans cette liste, on spécifie les UW existantes, les UW proches mais pas identiques, et les UW qui n’existent pas encore. Les autres équipes remplissent cette liste en liant ces UW à des mots dans leurs langues.
Voici un extrait de cette liste d’UW [Cardeñosa 01a, 01b] :






Sentence numbers
(sentences where the UW appears)Headword (Translation to English)Universal wordSpanish
Headword (in the native language)French Headword (in the native language)Russian Headwordremark93transformationtransformationtransformacióntransformation(à remplir)93, 94, 97urbanurbanurbanaurban93carry outcarry_out(icl>do)llevar a caboréaliser93buildbuild(icl>do)construirconstruire93sitesite(icl>thing)escenariosite93, 97, 98forumforumfórumforum93satisfysatisfy(icl>do)responder asatisfaire93effectivelyeffectivelyforma eficazeffectivement93needneed(icl>thing)necesidadesbesoin93, 94, 97, 99citycityciudadcitéTableau  STYLEREF 1 \s B SEQ Tableau \* ARABIC \s 1 3 Table pour l’échange d’UW dans projet FB2004
Avec la normalisation de l’encodage des énoncés de langue naturelle en UNL et la normalisation de la procédure d’encodage entre les équipes, nous espérons pouvoir simplifier les calculs des centres locaux pour trouver les bons mots. A plus long terme, le centre UNL devrait reprendre cette méthode et modifier les spécifications et la procédure de travail.
A part la TA, le langage UNL a aussi été appliqué au résumé de texte [Sornlertlamvanich 01], à l’analyse de texte [Choudhary 01], et à l’annotation sémantique de lexiques [Sornlertlamvanich 00].
Formats de documents UNL et outils associés
Des le début du projet UNL, le centre UNL a défini le format UNL-html, que nous appelons ici UNL-html.1.
UNL-html.1 et UNL-html.2
Un document UNL-html est un document multilingue balisé basé sur html, avec des balises non-html (entre [] et {}), utilisées pour marquer les informations spécifiques à UNL. Il y a deux types de balises : les crochets [] délimitent la segmentation du document (phrase, paragraphe et document). Les accolades {} délimitent les données linguistiques comme le graphe UNL et la version de langue.
Nous distinguons deux types de format UNL-html et nous les nommons UNL-html.1 et UNL-html.2. Le format UNL-html.1 est le format défini par le centre UNL.
Voici un document UNL-html.1 visualisé sous un éditeur textuel (Notepad de Microsoft).


Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 25 Un document UNL-html.1
Un document UNL-html a une hiérarchie arborescente comme le montre la figure ( REF _Ref64287882 Fig. B26). Chaque document se trouve entre les balises de document [D] et [/D]. Dans un document, il y a au moins un paragraphe et dans un paragraphe il y a au moins une phrase. Les balises de paragraphe et de phrase sont [P] [/P] et [S] [/S].
Dans une phrase, il y a un graphe UNL (éventuellement vide s’il n’a pas été construit) et le texte original, d’où ce graphe est enconverti et la/les version(s) de langue(s) déconvertie(s). Les balises sont : {unl}{/unl} pour le graphe UNL ; {org}{/org} pour le texte original. Pour les langues déconverties, on utilise des balises correspondant au code ISO à deux caractères de chaque langue. Par exemple, {ab}{/ab} encadrent un texte arabe et {cn}{/cn} un texte chinois, etc.
Dans les balises (sauf au niveau de paragraphe), on peut ajouter une liste d’attributs pour noter certaines informations, comme le nom du document, l’auteur, la date, l’adresse électronique de l’auteur, le codage du texte, etc. Syntaxiquement, les attributs sont des paires « nom=valeur » séparées par des virgules, et deux points « : » indique le début de la liste d’attributs.
Il y a deux exceptions à cette syntaxe. La première est qu’un chiffre avec deux points peut être attaché directement après P et S pour indiquer le numéro du paragraphe ou de la phrase. La deuxième est que le codage des caractères est attaché directement après l’étiquette de langue, suivie de « = ».
Voici une figure représentant la structure arborescente d’un document UNL-html.1.
 EMBED Word.Picture.8 
Fig.  STYLEREF 1 \s B SEQ Fig. \* ARABIC \s 1 26 Structure d’un document UNL-html.1
Le format UNL-html.1 a été conçu avant l’avènement de XML, et ne permet pas d’utiliser directement les outils développés pour XML ; il faut à chaque fois développer une application spécifique (comme le UNL-viewer).
Ce n’est pas non plus un format à montrer à l’utilisateur. Pour lire le document dans la langue d’un utilisateur, il faut d’abord extraire du fichier UNL-html.1 un fichier html « normal » ne contenant que la langue en question. Enfin, comme les parties en différentes langues d’un document UNL-html.1 sont dans différents encodages et pas en Unicode, on ne peut pas visualiser toutes les langues à la fois (par exemple, en colonnes synchronisées) avec les éditeurs et navigateurs du commerce. Par exemple, la version russe dans la  REF _Ref64287934 Fig. B25 est illisible parce que la police d’éditeur de l’auteur est par défaut Big5 qui ne contient pas les caractères cyrilliques.
Cependant, si on ajoute des balises html contenant l’attribut d’encodage, on peut visualiser directement un fichier UNL-html sous un navigateur quelconque, à condition bien sûr que toutes les polices nécessaires soient installées.
Il y a donc deux formes légèrement différentes d’un document UNL-html. La première, publiée par le centre UNL, suppose que tous les caractères significatifs sont implicitement échappés. On laisse donc « moddo(obj>thing)).@entry.@pred.@past,long ago)
mod(city(icl>region).@def,babylon(icl>country))
plc(begin(icl>do(obj>thing)).@entry.@pred.@past,city(icl>region).@def)
agt(begin(icl>do(obj>thing)).@entry.@pred.@past,people(icl>person).@def)
obj(begin(icl>do(obj>thing)).@entry.@pred.@past,build(icl>construct).@pred)
agt(build(icl>construct).@pred,people(icl>person).@def)
obj(build(icl>construct).@pred,tower(icl>building).@indef)
aoj(huge(aoj>thing),tower(icl>building).@indef)
aoj(seem(aoj>person,obj>thing).@pred.@past,tower(icl>building).@indef)
obj(seem(aoj>person,obj>thing).@pred.@past,reach(icl>do(gol>thing)).@pred.@begin-soon)
obj(reach(icl>do(gol>thing)).@pred.@begin-soon,tower(icl>building).@indef)
gol(reach(icl>do(gol>thing)).@pred.@begin-soon,heaven(icl>region).@def.@pl)
[/S]
Serveur :
Le peuple a commencé à construire une énorme tour a semblé qu'elle est atteinte les cieux dans la cité d'une Babylone jadis
Nous pouvons constater que, le projet étant à peine commencé, on n’avait pas encore bien maîtrisé l’usage des balises UNL. On ne faisait pas attention, et il manque des balises pour marquer la version de langue. Aussi, les spécifications n’étaient pas tout à fait les mêmes qu’aujourd’hui. On utilisait la restriction « .@pred » qu’on n’utilise plus.
Notons que la traduction est fausse parce que le graphe est douteux : « tower(icl>building) » est analysé comme objet (obj) de « reach(icl>do(gol>thing)) », alors que ce devrait être l’agent (agt), puisque la restriction « icl>do » sur reach indique un verbe transitif anglais. Il est vrai que les spécifications réservent agt pour « agent volitif ». On devrait alors avoir « icl>occur ». Il y a une autre erreur (« a semblé qu’elle » au lieu de « qui semblait »), sans doute imputable à la déconversion et corrigeable.
Cet exemple montre bien la nécessité de la normalisation de l’usage d’UNL, telle qu’elle est faite (et progresse) depuis le projet FB2004 (voir plus bas).
Love
LOVE est un corpus de 14 phrases courtes parlant d’amour. Le français a été produit par le déconvertisseur du GETA, à l’automne 1999. A la même époque, il y avait aussi les corpus great.unl, plan.unl, etc. Ces corpus ont été produits par le centre UNL comme un exercice de déconversion.
Voici un extrait de ce corpus :
[S]
;
agt(adore(icl>love).@entry.@present,he)
obj(adore(icl>love).@entry.@present,brother(icl>kinfolk))
pos(brother(icl>kinfolk),he)
mod(brother(icl>kinfolk),elder(mod>person))
[/S]
{el} he adores his elder brother {/el}
{fr} il adore son frère ainé {/fr}

[S]
;
obj(be beloved(icl>love).@entry.@present,she.@topic)
agt(be beloved(icl>love).@entry.@present,friend(icl>comrade).@pl)
pos(friend(icl>comrade).@pl,she)
mod(friend(icl>comrade).@pl,all)
qua(friend(icl>comrade).@pl,many)
mod(many,many)
[/S]
[el] She is beloved by all her many, many friends.{/el}
{fr} tous ses nombreux amis l’aiment {/fr}

Nous pouvons constater que l’encodage du graphe UNL n’était pas assez sophistiqué. Ainsi, la deuxième phrase a été codée selon la syntaxe de surface de l’anglais.
Sport
Sport est un corpus préparé pour une démonstration au Symposium UNL qui a eu lieu aux Nations Unies, à New York, en novembre 1998. Comme c’était juste après la coup du monde de football (gagnée par la France), on avait choisi des phrases dans des articles de presse sur le sujet, dans différentes langues.
Voici un extrait de ce corpus :
[S]
;Play restarts when the ball touches the ground.
obj(restart(icl>begin,man>anew,obj>process).@pred.@entry,play(fld>sport,icl>period))
tim(restart(icl>begin,man>anew,obj>process).@pred.@entry,touch(cob>thing,icl>contact,man>physically,obj>thing).@pred)
agt(touch(cob>thing,icl>contact,man>physically,obj>thing).@pred,ball(fld>soccer,icl>tool).@def)
obj(touch(cob>thing,icl>contact,man>physically,obj>thing).@pred,ground(icl>place).@def)
[/S]
{fr} Redemarre un jeu quand le ballon touche le sol.{/fr}

[S]
;The ball is dropped again: if it is touched by a player before it makes contact with the ground.
obj(drop(agt>person,icl>#event,obj>thing).@pred.@entry,ball(fld>soccer,icl>tool):01.@theme.@def)
man(drop(agt>person,icl>#event,obj>thing).@pred.@entry,again(icl>once more))
con(drop(agt>person,icl>#event,obj>thing).@pred.@entry,touch(agt>part of body,icl>contact,man>physically,obj>thing):01.@pred.@past.@complete)
agt(touch(agt>part of body, icl>contact, man>physically, obj>thing):01.@pred.@past.@complete, player(fld>soccer, icl>sportsman))
obj(touch(agt>part of body,icl>contact,man>physically,obj>thing):01.@pred.@past.@complete,ball(fld>soccer,icl>tool):03.@def)
tim(touch(agt>part of body,icl>contact,man>physically,obj>thing):01.@pred.@past.@complete,before(obj>time))
obj(before(obj>time),touch(cob>thing,icl>contact,man>physically,obj>thing):02.@pred.@past.@complete)
agt(touch(cob>thing,icl>contact,man>physically,obj>thing):02.@pred.@past.@complete,ball(fld>soccer,icl>tool):02.@def)
obj(touch(cob>thing,icl>contact,man>physically,obj>thing):02.@pred.@past.@complete,ground(icl>place).@def)
[/S]
{fr} Le ballon est encore lance si un joueur a avant que le ballon ait touche le sol touche le ballon. {/fr}
Nous remarquons que les restrictions dans ce corpus sont plutôt précises et compliquées. Dans les spécifications ultérieures, les types de relation décrivant la hiérarchie ont été réduits à trois : icl, pof, mod. En plus, la hiérarchie de la KB a été changée plusieurs fois au cours du développement du projet. Donc, nous ne trouvons plus les UW ci-dessus dans la KB d’aujourd’hui. Il est probable que cette partie de KB a été produite exprès pour cette démonstration.
C’est aussi la première fois que le centre UNL a commencé à organiser des démonstrations multilingues pour promouvoir UNL.
Org-Explorer
Org-Explorer est un corpus qui comprend 322 phrases. Il a été créé pour montrer les fonctionnalités d’Org-explorer, qui est une application proposée par le centre UNL pour montrer le multilinguisme d’UNL. Le contenu est l’introduction à l’ONU, et présente sa hiérarchie, les responsables et les fonctionnalités de tous les départements en plusieurs langues.
19 phrases sont vraiment multilingues, avec des versions en 14 langues. Les autres phrases sont au moins en japonais et en anglais.
Nous avons réuni ces 19 phrases dans un autre corpus qui s’appelle Org-Information. Les phrases n’y sont donc pas reliées l’une à l’autre. Selon l’auteur, il y a des versions linguistiques qui ont vraiment été produites par déconversion, et d’autres non.
Voici une image de la conception de cet Org-Explorer :

Fig.  STYLEREF 1 \s C SEQ Fig. \* ARABIC \s 1 34 Structure d’Org-Explorer
Ce corpus comprend plusieurs codages. Voici une partie de ce corpus sous Notepad. Notons qu’il n’existe pas d’outil qui permette de visualiser tous les caractères de ces codages. C’est une des raisons qui nous ont poussé à définir le format UNL-xml et à imposer la normalisation du codage dans ce format (Unicode/UTF-8).

Fig.  STYLEREF 1 \s C SEQ Fig. \* ARABIC \s 1 35 Org-Information sous Notepad
Ce corpus a donc été transformé par nos soins en UNL-xml. Voici la même partie de corpus. Avec Unicode, nous pouvons voir toutes les versions.

Fig.  STYLEREF 1 \s C SEQ Fig. \* ARABIC \s 1 36 Corpus Org-Information en format UNL-xml sous Notepad
Plusieurs équipes ont tenté de montrer correctement le texte en évitant les caractères spéciaux ou les accents. Par exemple, les équipe allemande et italienne n’utilisent pas du tout les lettres accentuées. Les Umlaut en allemand ont été remplacés par le tréma, par exemple, ü ’!u . Les accents graves ont été remplacés par une apostrophe, è ’!e . Pour tous les corpus, l équipe indienne abandonne l alphabet dévanagari et utilise l alphabet romain.
Avec ce corpus, plein de noms propres et de noms d’organisations (par exemple, United Nations University, UNU Programme for Biotechnology in Latin America and the Caribbean, Conference of Directors, UNU Institute for Software Technology, etc.), on a commencé à identifier le problème du nom propre (ou nom composé). Le nombre de noms propres de ce genre est illimité et donc on ne peut pas créer pour chacun une UW. Il faut avoir un algorithme pour calculer ces noms. Plusieurs solutions possibles ont été proposées dans [Boitet 02d] et [Boguslavsky 02a, 02b].
Genève 2001
Genève 2001 comprend trois articles choisis séparément par les équipes russe, italienne et espagnole, enconvertis manuellement, puis déconvertis dans ces trois langues. Il s’agissait de montrer la qualité de la déconversion. Cet effort a été organisé par le centre espagnol pendant le symposium UNL 2001 à Genève. Toutes les phrases ont été produites par les déconvertisseurs. Les trois articles comprennent au total 59 phrases.
Voici un extrait de ce corpus.

[D:dn=Mar Aral version final,on=UNL Spain, mid=carde@opera.dia.fi.upm.es]
[P:1]
[S:1]
{org:es}
El mar Aral, situado entre las repúblicas de Uzbekistán y Kazajstán, era el cuarto mar interior más grande del mundo.
{/org}
{unl}
nam(sea:01.@def, Aral)
obj(locate(icl>do).@present, sea:01.@def)
man(locate(icl>do).@present, between(icl>manner))
obj(between(icl>manner), republic:01.@def)
and(republic:01.@def, republic:02.@def)
nam(republic:01.@def, Uzbekistan)
nam(republic:02.@def, Kazakhstan)
aoj(sea:02.@def.@entry.@past, sea:01.@def)
mod(sea:02.@def.@entry.@past, inland(mod
 :