Accès à des services de traduction interactive fondée sur le dialogue à travers un éditeur XML

Transcription

1 Mémoire de Master de Recherches d Informatique (2ème année) Option: Intelligence, Interaction, Information Titre Accès à des services de traduction interactive fondée sur le dialogue à travers un éditeur XML soutenu par Ali CHOUMANE le 21 juin 2005 Responsables du projet : Hervé BLANCHON : Equipe GETA 1 Cécile ROISIN : Equipe WAM 2 Composition du jury : Hervé Blanchon Jean Caelen Yves Demazeau Marc Dymetman Cécile Roisin Jean-Marc Vincent 1. Groupe d Etude pour la Tradution Automatique, CLIPS 2. Web Adaptation Multimédia, INRIA Rhône-Alpes

2 ii

3 iii À mes parents

4 iv

5 v REMERCIEMENTS Je remercie Monsieur Hervé Blanchon et Madame Cécile Roisin pour m avoir encadré et encouragé durant ce stage et pour avoir fait preuve d une grande disponibilité. Je les remercie également pour leurs remarques très enrichissantes et constructives sur différents aspects des idées exposées dans ce mémoire, ainsi que pour l intérêt qu ils ont porté à mon travail. J exprime aussi ma reconnaissance à Madame Irène Vatton pour son aide et ses bons conseils. Un grand merci également à Monsieur Christian Boitet, Monsieur Nabil Layaïda et Monsieur Vincent Quint pour leurs remarques indispensables. Je tiens à remercier Monsieur Stéphane Gully pour son aide. Je souhaite remercier à nouveau Monsieur Christian Boitet et Monsieur Vincent Quint pour m avoir accueilli dans leur équipe et m avoir permis de réaliser le stage que je souhaitais faire. Je voudrais également remercier les membres du jury d avoir accepter de juger mon travail. Enfin, un grand merci à mes parents qui me soutiennent toujours.

6 vi

7 vii Résumé Dans ce mémoire nous rappelons les principes de base de la Traduction Automatique Fondée sur le Dialogue (TAFD), et leur mise en oeuvre dans le projet LIDIA. Puis, nous montrons le lien étroit qui réuni la TAFD et le domaine de l édition de documents électroniques. Nous présentons ensuite les motivations de la maquette LIDIA-3, dans laquelle l environnement d accès aux services LIDIA (client) est intégré dans un éditeur de documents structurés. En TAFD, on considère que celui qui veut traduire un document source est son auteur. Afin d obtenir une traduction de qualité, l auteur devra aider le système à "comprendre" le document au moyen d une étape de désambiguïsation interactive (DI). Nous étudions les conséquences de l intégration des services LIDIA, dans un tel éditeur, à la fois sur la représentation du document source augmenté (Document LIDIA) des informations collectées lors des différentes étapes de la traduction (trace de la DI en particuliers) et sur l architecture d un tel système. Nous montrons aussi comment construire et visualiser ce que l on appelle un Document Auto-Explicatif (DAE). Un DAE permet de montrer à un lecteur la localisation des ambiguïtés qu il contient et, pour chacune, l interprétation à retenir. Nous présentons alors la nouvelle structure du document LIDIA qui répond aux services de désambiguïsation et d édition. Enfin, nous présentons notre maquette construite au-dessus de l éditeur Amaya ainsi qu un scénario de notre application.

8 viii

9 Table des matières 1 Introduction 1 2 État de l art Traduction Automatique Fondée sur le dialogue Bref rappel historique sur la TA interactive Le projet LIDIA Vers les Documents Auto-Explicatif Édition de document électronique Formats de document Contrôle de structure à l édition Modes d édition Synthèse Rappel des objectifs Vers un nouveau cahier des charges de LIDIA Processus de LIDIA Découpage en rôle Le rôle Auteur Le rôle Lecteur Choix d interaction Lancement de connexion Désambiguïsation Interactive (DI) Filtrage et visualisation de Document Auto-Explicatif Nouvelle structure de document Cohabitation des structures Structure LIDIA Spécification de l environnement de travail Présentation d Amaya Motivations pour le choix d Amaya Architecture d Amaya Représentation des documents dans Amaya Les langages de Thot Comment étendre Amaya? ix

10 TABLE DES MATIÈRES x 5 Spécification et réalisation de la maquette LIDIA Partie étendue Construction du document LIDIA Scénario d application Problème d Incohérence des données Conclusion Objectifs Contribution Perspectives de recherche A Triangle de Vauquois 55 B Schéma XML de documents LIDIA 57 C Exemple du document LIDIA 61 D Exemple du document LIDIA (invalide) 63 E Document LIDIA enrichi 65

11 Table des figures 2.1 Architecture linguistique de LIDIA Architecture informatique LIDIA Architecture informatique LIDIA-1.mail Moteur et linguiciels pour des modules de désambiguïsation interactive Instance d un module de désambiguïsation particuliers Vue externe de la construction d un arbre de questions Architecture informatique de LIDIA Architecture linguicielle de LIDIA avec intégration de la construction de DAE Une classification des systèmes d édition Schéma fonctionnel simplifié Fenêtre de document LIDIA-2 (après analyse) Première question de désambiguïsation de la phrase en exemple Seconde question de désambiguïsation de la phrase en exemple Fin de la session de désambiguïsation de la phrase en exemple Interface de visualiseur de DAE dans LIDIA Affichage de la lecture à retenir pour la phrase sélectionnée Partage de document édité entre deux structures différentes Modèle de document LIDIA (premier niveau) Modèle de document LIDIA (deuxième niveau) Architecture simplifiée d Amaya Cheminement d un document Web sous Amaya Menu "LIDIA" et ses items Schéma fonctionnels détaillé Document édité sous Amaya avec le source XHTML correspondant Le document édité à la fin de la phase de désambiguïsation (retour de l arbre de questions) xi

12 TABLE DES FIGURES xii 5.5 Première question de désambiguïsation de la deuxième phrase ambiguë en exemple Deuxième question de désambiguïsation de la deuxième phrase ambiguë en exemple A.1 Triangle de Vauquois C.1 Document LIDIA: résultat d une transformation D.1 Exemple du document LIDIA invalide

13 Chapitre 1 Introduction Les demandes croissantes de l échange des documents sur l Internet et le désir de chaque auteur de rédiger dans sa langue maternelle, et de diffuser ses textes ont stimulé le problème de traduction des documents. Dans le contexte de la TAO 1, seule la technique de TAFD 2 permettra d aboutir à des systèmes de "Traduction Automatique pour tous". Grâce à un dialogue homme-machine de clarification, un auteur pourrait être traduit de façon très correcte dans plusieurs langues, sans révision, et sans compréhension explicite de sa part des différentes langues cibles [8]. Un système de TAFD effectue d abord une analyse automatique des énoncés à traduire. Si un énoncé est ambigu, plusieurs analyses sont produites, le système prépare un arbre de questions de désambiguïsation. L auteur précise le sens de chaque fragment ambigu en parcourant un chemin dans l arbre de questions depuis la racine jusqu à une feuille. Il choisit ainsi la solution qui correspond à la bonne interprétation. La traduction se poursuit alors de manière autonome. Le projet LIDIA 3, met en œuvre les idées de la TAFD. Ce projet consiste en trois composantes, deux composantes applicatives : celle comprenant les serveurs d analyse, de désambiguïsation et de traduction, et celle côté client constituée de l environnement d édition. La troixième composante est un serveur de communication entre les deux premières. Mon travail consiste à concevoir une nouvelle maquette côté client pour mieux intégrer les services d édition et de désambiguïsation offerts à l utilisateur. Ils s agit donc d étudier les conséquences de cette intégration en terme de modélisation et d architecture pour franchir une nouvelle étape dans la réalisation d un environnement LIDIA qui puisse permettre de produire des documents plus riches, de visualiser leur version auto-explicative, et de les traduire interactivement. 1. Traduction Automatique par l Ordinateur 2. Traduction Automatique Fondée sur le Dialogue 3. Large Internationalisation des Documents par Interaction avec l Auteur. 1

14 Introduction 2 Ce mémoire est organisé en trois parties. Après l introduction, le chapitre 2 décrit un état de l art qui regroupe les deux domaines : la traduction automatique dans lequel on étudie plus particulièrement le domaine de la TAFD et le projet LIDIA. l édition des documents structurés et les caractéristiques des éditeurs de ces documents. Nous présentons ensuite, dans le chapitre 3, nos propositions de contributions pour la maquette LIDIA-3 : description complète de son architecture et nouvelle structure de "document LIDIA". Le chapitre 4 présente la spécification de l environnement de travail, et fournit les raisons du choix d Amaya. Le chapitre 5 présente la spécification et une première étape vers la réalisation de la maquette LIDIA-3. Nous détaillons à cette occasion un scénario qui montre le déroulement d une session et les problèmes qui peuvent se présenter. Enfin la conclusion résume le travail présenté, et ouvre des perspectives pour aller plus loin dans la réalisation de la nouvelle maquette LIDIA.

15 Chapitre 2 État de l art La Traduction Automatique (TA) n est ni une science, ni une collection de recettes, c est plutôt une technologie scientifique. Elle comprend un ensemble de méthodes qui progressent par intégration de nouvelles idées et par amélioration incrémentale de savoir-faire. Certaines améliorations sont aussi liées à l évolution des formats et des outils de traitement des documents électroniques. Mon travail en DEA recouvre les deux domaines suivants : le domaine de TA et le domaine du traitements des documents électroniques, qui constituent les deux grandes parties de mon état de l art. Il est plus détaillé en ce qui concerne ce dernier thème, notre objectif étant de permettre l accès à des services de TA à travers un éditeur XML Traduction Automatique Fondée sur le dialogue Les recherches et développement en TAFD sont motivés par la limitation des paradigmes actuels, par exemple, la TAO du réviseur dans laquelle on veut produire des traductions "brutes", destinées à être révisées [2], est loin de pouvoir répondre à tous les besoins. Outre le fait qu elle demande évidemment autant de révision que de langues cibles, elle reste trop chère pour des usages légers. En plus, on peut observer l importance croissante des langues nationales dans le contexte de l internationalisation, et le désire de chaque auteur de rédiger dans sa langue maternelle, et transmettre ses textes dans des langues qu il ne maîtrise éventuellement pas. En plus, ces motivation sont liée aux récents progrès méthodologique et technologiques, en effet l idée de la TAFD date des années soixante [21], et a été incorporée à plusieurs maquettes ou prototypes dans les années soixante-dix et quatre-vingts dans les universités Brigham Young, Carnergie Mellon, Manchester et Sheffield. Si ces travaux n ont pas donné lieu à des systèmes utilisables 1. Extensible Markup Language 3

16 État de l art 4 en pratique, c est que les dialogues devaient être conduits par des spécialistes, que la couverture linguistique était trop limitée, et que l on ne disposait pas encore d environnements interactifs conviviaux. La méthodologie s est raffinée ces dernières années. Tout d abord, l utilisateur envisagé n est plus un spécialiste, mais un rédacteur ou plutôt un auteur [8]. D autre part, l informatique personnelle à fait des progrès. On dispose maintenant d ordinateurs personnels très puissants et bon marché, d environnements conviviaux, de l intégration du multimédia, et d outils de télécommunication permettant le recours à des serveurs. Le plus gros problème auquel les systèmes sont confrontés est l ambiguïté. Pour obtenir une bonne traduction, il faut soit que les systèmes fassent une désambiguïsation automatique efficace, soit qu ils puissent demander l assistance de l auteur lors d une étape de désambiguïsation interactive Bref rappel historique sur la TA interactive La TA interactive est un courant qui est né dans les années 60 [21]. [5] propose un état de l art complet de ce courant de recherche jusqu en Trois classes de systèmes sont identifiées : les systèmes pionniers, les systèmes dans lesquels l interaction est ajoutée a posteriori et les systèmes dans lesquels l interaction est intégrée comme "ingrédient" de base. Les systèmes pionnièrs L un des premiers projets en traitement automatique des langues naturelles (TALN) fut le projet MIND ( ) [21, 18] qui devait être une boîte à outils permettant de réaliser différents types de systèmes, depuis des testeurs de grammaires jusqu à des systèmes de traduction automatique en passant par des systèmes de question-réponse. Avec le système MIND, on a la première apparition de l idée d un processus de Désambiguïsation Interactive (DI). Ce projet est resté une expérience de laboratoire limitée. Plus tard, le projet ITS ( ) visait au développement d un système interactif pour traduire des textes en anglais vers le français, l espagnol, le portugais, l allemand et le chinois [25]. Dans ce système, parmi les questions posées pour résoudre une ambiguïté, certaines d entre-elles font intervenir une connaissance très précise du modèle linguistique. L utilisateur doit donc être un linguiste spécialiste de ce système. De plus, pour répondre aux questions posées pendant la phrase de transfert (Triangle de vanquois, cf. Annexe A), l utilisateur doit aussi avoir une connaissance de la langue cible.

17 État de l art 5 Les systèmes dans lesquels l interaction est ajoutée a posteriori Le projet KBMT-89( ) [12] avait pour objectif la réalisation d une maquette d un système de traduction fondé sur les connaissances pour traduire des manuels d installation et de maintenance de microordinateurs de l anglais vers le japonais et inversement. L un des avantages atteint dans ce système, c est que pour répondre aux questions posées lors de la phase de désambiguïsation interactive, l utilisateur n a pas besoin d avoir des connaissances de linguiste. Le système LMT (1989) [23, 24] est un système de traduction automatique expérimental ( de l anglais vers l allemand, l espagnol et le danois, de l allemand vers l anglais, et du danois vers l anglais) pour tester l utilisation de la programmation logique en TALN. LMT-89 a été testé sur un corpus de 500 phrases. 95% des traductions produites pouvaient être lues et comprises par un lecteur allemand. Les systèmes dans lesquels l interaction est integrée Le projet DLT ( ) avait pour objectif de construire un système de traduction par pivot (Triangle de vanquois, cf. Annexe A) entre les langues européennes (anglais, français, allemand, italien) [30]. DLT est conçu comme un système interactif multilingue fonctionnant sur un réseau d ordinateurs. Chaque ordinateur se comporte comme un traducteur depuis et vers une langue seulement. Donc c est un système distribué, puisque les processus d analyse et de génération ne sont pas exécutés sur le même terminal. Le projet ITS-2 [31] est un prototype de système interactif de traduction de phrases, qui accepte des phrases prises dans un sous-ensemble de la grammaire du français pour les traduire en anglais. ITS propose différents modes de dialogue. Le système peut travailler en mode autonome et en mode interactif où l interaction se fait déjà en langue source Le projet LIDIA L idée de base est de remplacer les postéditions (une par langue cible) de la TA du réviseur par une seule préeditions (étape de DI) avec une TA pour l auteur [8]. Il convient de prévoir la présentation du texte ambigu par des marques de désambiguïsation. Ces marques sont des annotations qui comprenne des méta-donnés et des traitements possibles de ce texte. Dans [2], quatre critères pour choisir la TAFD sont proposés : la qualité visée doit être élevée, la révision est impossible ou très coûteuse, le contexte doit être fortement multilingue, l entrée ou le domaine ne doivent pas être trop contrôlés, et les utilisateurs doivent être prêts à

18 État de l art 6 participer à des dialogues de désambiguïsation. Le concept de TAFD est mise en œuvre dans le cadre de projet LI- DIA par l équipe GETA-CLIPS, dans laquelle trois maquettes ont été réalisées jusqu à présent : LIDIA-1 et LIDIA-2 et LIDIA-3. Mes travaux concernent cette dernière maquette. Voici maintenant, résumée, l évolution des différentes maquettes LIDIA à ce jour. 1. LIDIA-1 (89-95) Architecture linguistique Le fait que TAFD suppose un dialogue avec l auteur permet d envisager de nouvelles possibilités au niveau des traitements linguistiques. Il ne s agit pas de solutions radicalement nouvelles, mais, comme souvent dans un domaine technique, de nouveaux compromis, et de voies intermédiaires nouvelles. Illustrons les étapes du processus de traduction dans LIDIA à partir de la Figure 2.1 ci-dessous. Une phrase du texte en langue source est d abord analysée pour produire la structure mmc-source (multisolution, multiniveau, concrète). Cette structure mmc sera utilisée pour construire un arbre des questions qui seront posées à l auteur. A partir de l étape de désambiguïsation interactive, le système obtient la structure umc-source (unisolution, multiniveau, concrète) non ambiguë choisie par l auteur. Cette structure est ensuite abstraite en une structure uma-source (unisolution, multiniveau, abstraite). La structure uma est transférée vers une structure gma-cible (génératrice, multiniveau, abstraite) à partir d une composante de transfert lexical et structural. La composante de sélection de paraphrasage produit une structure uma-cible et après le processus de traduction se termine avec les générations syntaxique et morphologique. Le retour vers la langue source par rétro-traduction est possible en faisant la même chose, à partir de la structure uma-cible, que dans le sens de génération de la langue 1.

19 État de l art 7 Fig. 2.1 Architecture linguistique de LIDIA Architecture informatique La maquette LIDIA-1 [5, 7], permet de traduire un document Hypercard en français illustrant différentes ambiguïtés du français vers le russe, l anglais et l allemand. HyperCard est un environnement de production de documents hypertexte dont les pages sont des "cartes". Les cartes contiennent différents types d objets, dont les champs textuels. L environnement de rédaction est une extension de HyperCard [3, 6], qui était largement disponible, à un coût très faible. Dans cette maquette, on utilise d Ariane-G5 qui est un générateur de systèmes de TAO, fondé sur 5 langages spécialisés pour la programmation linguistique (LSPL). Cet environnement fonctionne sur IBM, il permet de réaliser les différentes étapes de traduction [6]. Deux implémentation ont été réalisées dans LIDIA-1 : la maquette LIDIA et LIDIA-1.mail. LIDIA La première version de la maquette LIDIA-1 [5] était implémentée comme illustré dans la Figure 2.2 ci-dessous. Dans cette architecture la station de l auteur hébergeait l environ-

20 État de l art 8 Fig. 2.2 Architecture informatique LIDIA nement de rédaction (HyperCard) qui communiquait avec un environnement de programmation en Lisp dans lequel étaient programmés un superviseur de traitement et un module de désambiguïsation interactive. Une autre machine hébergeait une carte d émulation de terminal 3270 reliée avec le serveur de traduction (ARIANE- G5). La station de rédaction et de communication échangeant des informations par AppleScript. LIDIA-1.mail L utilisation de l émulation dans LIDIA permettait la communication avec le serveur de traduction au moyen d un protocole complexe et peu robuste. La maquette LIDIA-1.mail devait permettre d utiliser le protocole SMTP pour faire communiquer la station de rédaction et le serveur de traduction. Elle est composée de trois modules (Figure 2.3) : le module de rédaction basé sur HyperCard. le module de désambiguïsation interactive écrit en Macintosh common Lisp. le serveur de traduction hébergé par un IBM. La communication entre la partie Macintosh et la partie IBM se fait par échange de courriers électroniques, alors qu elle se faisait par connexion directe dans la maquette LIDIA

21 État de l art 9 Fig. 2.3 Architecture informatique LIDIA-1.mail 2. LIDIA-2 (95-03) et LIDIA-3 (04-) Nouvelle architecture pour la DI Dans la nouvelle architecture proposée [4], le module de désambiguïsation est constitué de deux composantes : un moteur de désambiguïsation et un linguiciel de désambiguïsation. Le moteur est indépendant de la langue et du corpus à traiter. Il sera utilisé pour tous les modules de désambiguïsation à développer. Par contre le linguiciel dépend de la langue et des ambiguïtés présentes dans le corpus à traiter. Le moteur peut être associé à différents linguiciels (Figure 2.4) pour composer des modules de désambiguïsation particuliers. La Figure 2.5 ci-dessous montre une instance de module de désambiguïsation propre à une application donnée, et comme nous l avons déjà mentionné, il est l association d un linguiciel particuliers et du moteur. Le linguiciel permet de décrire les ambiguïtés à résoudre et la construction des items de questions qui permettront leur résolution. Le moteur utilise alors le linguiciel pour réaliser le processus de DI. Le moteur donc fournir une méthode de reconnaissance des ambiguïtés décrites dans le linguiciel, un ensemble d opérateurs à

22 État de l art 10 Fig. 2.4 Moteur et linguiciels pour des modules de désambiguïsation interactive Fig. 2.5 Instance d un module de désambiguïsation particuliers

23 État de l art 11 utiliser pour décrire la formation des items de question, l ordre dans lequel les ambiguïtés seront résolues et des méthodes de préparation des questions. Un module de désambiguïsation reçoit en entrée une structure mmc, qui contient un ensemble de solutions, et produit en sortie un arbre de questions. A chaque itération, le processus de construction de l arbre de question produit une partition de l ensemble des solutions. Un item de question est construit pour chaque ensemble. Chaque nouvel ensemble de solution est alors utilisé pour y chercher une nouvelle ambiguïté. Si l ensemble est réduit à une seule solution, le processus s arrête, comme le montre la Figure 2.6. Fig. 2.6 Vue externe de la construction d un arbre de questions Nouvelle architecture informatique : vers plus de distribution L expérience du GETA dans le consortium C-STAR II a montré l intérêt de faire communiquer, au moyen d un serveur de communication sous le protocole telnet, des modules développés sur des plates-formes différentes. La nouvelle architecture de LIDIA-2 est donc inspirée de celle de C-STAR II. Dans cette maquette, l architecture logicielle est améliorée, en terme de protocole de communication et de structure des documents manipulés. La nouvelle architecture proposée (Figure 2.7) comprend 3 composantes: un environnement de rédaction et d accès aux services LIDIA, un serveur d analyse et de traduction, et un serveur de désambiguïsation qui communiquent via un serveur de communi-

24 État de l art 12 cation (CS) [2]. Fig. 2.7 Architecture informatique de LIDIA-2 Dans cette maquette la notion de "document miroir" est introduite, il contient une trace de l étape de DI avec l auteur, c est à dire, le sens choisit par l auteur. Un document auto-explicatifs (DAE), est obtenu après filtrage du document miroir [3]. Nous développons plus en détail cette idée dans le prochain paragraphe. Les deux documents miroir et DAE sont au format XML. Une première version de cette nouvelle architecture a été réalisée en 2001 [1] avec un client LIDIA écrit en langage Tcl/Tk. Une seconde version de la maquette LIDIA-2 à été produite en 2003 avec un client LIDIA en java [3, 3] Vers les Documents Auto-Explicatif Les informations fournies par l auteur lors de l étape de DI fournissent le "sens" des segments ambigus. Ces informations ne sont pas seulement utiles en vue d obtenir une traduction de qualité, elles pourraient être utilisées pour "montrer" à un lecteur le sens à retenir pour les segments ambigus du document source. On obtient ainsi un "Document Auto- Explicatif" noté DAE. Un DAE contient donc le texte du document source, désambiguïsé et augmenté d une mémoire des ambiguïtés qu il contient ainsi qu une trace du processus de désambiguïsation interactive [2]. La production d un DAE en langue source requiert uniquement que l auteur fasse une désambiguïsation interactive du document. On peut

25 État de l art 13 donc imaginer que l auteur ne souhaite pas produire de traduction du document source, mais uniquement un DAE pour permettre qu il soit lu sans risque d incompréhension. Si l auteur choisi de faire une traduction, on peut aussi envisager la création d un DAE en langue cible. Elle ne nécessite pas une intervention humaine [2]. L étape de génération produit une structure intermédiaire équivalente à une structure d analyse désambiguïsée (umc). Il suffit alors, pour créer un DAE en langue cible, de faire une analyse multiple (mmc) de chaque phrase effectivement générée, puis de construire un arbre des questions concernant ces phrases. On pourra ensuite calculer automatiquement les réponses aux questions de désambiguïsations qui permettent d obtenir la structure umc par le générateur. Les changements à effectuer dans l architecture linguicielle LIDIA en intégrant le processus de production de DAE sont illustrés dans le schéma suivant : Fig. 2.8 Architecture linguicielle de LIDIA avec intégration de la construction de DAE

26 État de l art Édition de document électronique Puisque l objectif de notre travail est d offrir des services de TAFD au sein d un éditeur, nous étudions ici les systèmes d édition tout d abord selon le format de document qu ils manipulent, puis selon les services de contrôle et d interaction qu ils offrent Formats de document Les fichiers de données sont stockés sous l une de ces deux formes : fichiers binaires ou fichiers texte [17]. Les fichiers textuels peuvent être linéaires ou structurés. Un fichier binaire, dans sa forme la plus simple est une suite de bits (des 1 et des 0). C est à l application ayant créé un tel fichier de comprendre ce que signifient ces bits. Le gros avantage des formats de fichiers binaires est qu il est très facile à l ordinateur de comprendre ces codes binaires, ce qui signifie qu ils peuvent être traités plus vite et qu ils sont parfaitement adaptés au stockage de ces métadonnées. L inconvénient est que, ces formats de fichiers binaires sont "propriétaires" 2. Comme les fichiers binaires, les fichiers texte constituent également des suites de bits. Dans un fichier texte, ces bits sont cependant regroupés afin de toujours représenter des nombres selon un standard spécifique. Grâce à ces standards, les fichiers texte peuvent être lus par de très nombreuses applications. Cela facilite grandement le partage de l information. Depuis que les ordinateurs existent, les programmeurs ont toujours tenté de trouver des moyens pour échanger des informations. SGML 3 constitue la première tentative de définition d un format dont l objectif est de permettre, l échange de données textuelles ainsi que de leurs structures entre systèmes informatiques. Il s agit d un langage de type texte s utilisant pour baliser des données (leur ajouter des métadonnées). L application la plus célèbre du SGML est HTML 4. Celui-ci est un langage universel de balisage destiné à l affichage des informations, ainsi qu à mise en relation de différents fragments d informations situés sur l Internet. L idée est que tout document HTML (ou page web) doit pouvoir être présenté dans n importe quelle application (navigateur) capable de comprendre HTML. Ce navigateur doit être encore capable de récupérer à la demande les cibles des liens hypertexte que contient la page 2. Il est le plus souvent impossible d ouvrir un fichier binaire créé par une application dans une autre application 3. Standard Generalized Markup Language 4. HyperText Markup Language

27 État de l art 15 web courante. SGML reste un langage complexe, il n est pas bien adapté à l échange de données sur le Web. Et même si HTML a rencontré un succès, sa seule fonction étant l affichage des informations dans un navigateur, il est possible de créer un document HTML présentant des informations sur une personne, mais cela ne va pas plus loin. Il ne peut être établi à partir du document quelles sont, par exemple, les informations relatives au prénom ou au nom de la personne. XML a été créé pour cette raison. C est un sous-ensemble de SGML, possédant les mêmes objectifs. D un point de vue technique, un document SGML doit toujours être valide au regard d une DTD, ce qui n est pas le cas avec XML. Cette validation permet de s assurer que l information est saisie ou générée conformément au modèle et que l on peut donc lui appliquer des traitements automatisés sans avoir à valider la structure du document au préalable. Par contre, un document XML peut être valide ou non. On peut, par exemple, échanger des documents XML sans leur attacher une DTD. L avantage de ce relâchement, est qu un document XML peut avoir plusieurs DTD en fonctions de l application. D autres mécanismes peu utilisés existaient, comme ceux d inclusion et d exclusion. Ils n ont pas été jugés utiles dans XML, car apportant de la complexité aux traitements sans pour autant faciliter la vie du rédacteur. Il existe des outils (XMLSpy, Oxygen, etc) permettant la manipulation des dialectes XML (XHTML 5, SMIL 6, etc.). La disponibilité d une syntaxe standard et d outils de traitement réduit significativement le coût de développement, permettant à des programmes de modifier et de valider, des documents écrits dans ces langages. Dans le contexte de l édition des documents, on différencie deux classes des formats de représentation de documents [9] : Un document peut être représenté comme un flot d informations dans la continuité du flux de caractères constituant une page de texte. La granularité allant du pixel, au paragraphe (exemple Word). Les modèles qui définissent cette représentation des documents sont dits linéaires. Les documents numérisés sont des images représentées par des matrices des points (une matrice est représentée par une suite des lignes), le contenu textuel d un tel document n apparaissait pas explicitement. La représentation des documents formatés utilise également un modèle linéaire dans lequel le contenu textuel est entrecoupé d indications de changement de format du 5. Extensible HyperText Markup Language 6. Synchronized Multimedia Integration Language

28 État de l art 16 flot de texte, comme dans les formats Postscript et PDF 7. Enfin, le format de représentation utilisé dans les outils d édition interactifs classiques comme Word, s appuie sur une structure de séquences de paragraphes auxquels l utilisateur peut attacher des styles. Contrairement aux formes des documents linéaires, les documents structurés sont fondés sur les relations entre les différents composants du document plutôt que sur leur apparence et leur position dans la page. Ainsi, un document structuré est une collection d éléments typés composés entre eux selon des relations hiérarchiques. Une telle hiérarchie défini ce qu on l appelle la structure logique de document. La structure physique d un document est représentée par les propriétés de production de ce document, telles que la dimension des pages, la couleur, la taille des caractères, etc. [28]. Donc, les informations de présentation ne sont pas incluses dans le document comme c est le cas pour les documents linéaires mais elles sont définies relativement à sa structure logique. A ce stade nous citons le langage de présentation CSS 8. À un document structuré on peut associer une grammaire. Elle contient les règles syntaxiques que doit respecter le document, elle est également utilisée pour valider un document structuré. Tout se passe comme pour un programme que l on écrit dans un langage de programmation : le langage a une grammaire, qui décrit les structures syntaxiques permises pour un programme et les mots réservés que l on emploiera. Les grammaires des documents XML peuvent être décrites par des DTD 9 ou des schémas XML. Ils définissent les balises utilisées, leurs attributs, ainsi que leurs imbrications (relations) autorisées. Un document peut référencer sa DTD (son Schéma) par une URI 10 ou la contenir dans son entête. L un des avantages de XML Schema, est l existence de certains éléments qui permettent d exprimer des contraintes d unicité et de référencement par rapport au contenu de plusieurs éléments et attributs XML. Dans le cadre de notre projet, nous nous intéressons au format de document structuré, puisque nous serons amenés à représenter des structures complexes pour couvrir à la fois les besoins de représentation de données de l édition par l auteur, et ceux nécessaire pour la désambiguïsation, et 7. Portable Document Format 8. Cascading Style Sheets 9. Document Type Definition 10. Uniform Resource Identifier

29 État de l art 17 la traduction Contrôle de structure à l édition Dans les systèmes d édition des documents structurés, les éditeurs qui ne contrôlent pas les documents interactivement, dans ces éditeurs, lorsque le document est saisi, en intégrant éventuellement des informations de formatage (Tex) ou de structure (HTML, XML), aucun aide à l édition n est disponible. L auteur doit assurer lui-même la conformité de son document avec le format choisi. Il doit donc vérifier éventuellement pendant les différentes étapes d édition la validité de son document. Un cas particulier est la structuration d éléments importés [9], qui consiste à adopter un document non structuré dans un formalisme structuré. Cette opération appelée "structuration à posteriori" implique la déduction de types des éléments et de leur organisation logique de telle sorte qu ils soient conformes au modèle de document souhaité. En fait, le plus souvent, l auteur doit vérifier manuellement la cohérence de son document, ce qui peut être une lourde tâche Par contre, certains éditeurs permettent l édition avec un contrôle interactif des documents comme XMLSpy [41] et Thot [33]. Ils proposent à l auteur les éléments possibles qu il peut éditer en fonction de la sélection courante et du modèle du document édité, d aider l auteur et de lui éviter de faire des erreurs syntaxiques. Par conséquent les documents manipulés par ces systèmes d édition sont à tout moment de l édition conformes au modèle associé. D autres éditeurs, tels que XMetaL [40], qui fournissent un environnement d édition structuré. Ils utilisent tous la DTD associée au document XML et contraignent l édition du document pour qu il soit conforme aux modèles définis dans la DTD. XMetaL permet à l interface d être adaptée aux besoins du client par l intermédiaire des feuilles de styles CSS. Dans [15], une méthode formelle pour contrôler l édition interactivement est présentée. Les grammaires, comme DTD et XML schéma se concentrent en général sur la structure d un document, mais elles peuvent être employées pour guider l auteur pendant la production de cette structure. Cette approche montre comment un système d édition peut détecter automatiquement les conséquences des choix déjà faits par l auteur afin de ne lui proposer, lors de la prochaine étape d édition, que les choix qui peuvent mener à un document valide. Cette approche considère au début le cas d écriture des documents linéaires contrôlés par une grammaire hors-contexte (Context-free grammar), puis elle montre une généralisation vers le contrôle de documents structurés par une grammaire régulière.

30 État de l art 18 Dans le domaine de multilinguisme, nous pouvons citer MDA [13] un système interactif pour aider les auteurs monolingues dans la production de documents multilingues en domaine contraint (spécialisé). La représentation de documents est basée sur une grammaire hors-contexte similaire à une DTD. Ce système offre en plus d une vue de l arbre sémantique abstrait représentant le contenu des documents, une contrôle au niveau des zone active [22], qui sont des portions de texte associé à des objets sémantiques déjà présents dans la structure abstraite du document courant. La sélection d une zone active entraîne l affichage d un menu présentant l ensemble des valeurs possibles pour l instanciation de l objet sémantique correspondant. De nos jours, un document n est pas uniquement constitué du texte, il comprend différents types d objets à manipuler, par exemple, les formules mathématiques, les images et d autres éléments graphiques. Des modèles permettent de couvrir les besoins de représentation de ces objets (ex : MathML 11, SVG 12 ), mais les outils d édition associés sont plus complexes. Nous parlons d une complexité, c est au niveau de fonctionnement des ces outils d édition. Un tel éditeur et lors d un tel étapes d édition doit garantir la gestion des documents et maintenir la cohérence entre la structure logique et la structure physique de document, en appliquant implicitement un certain types de transformation à son version logique Modes d édition Dans cette partie, nous abordons les différents modes d édition existants pour couvrir des besoins de perception, parce que les documents sont complexes. Dans ce contexte, on différencie : les éditeurs syntaxiques, WYSIWYG et partiellement WYSIWYG. Notons que la plupart des éditeurs de documents struturés comprennent la notion de multi-vues, ils offrent à l utilisateur la possibilité de choisir le mode d édition que lui convient. Pour cela on remarque qu un même éditeur peut offrir une édition syntaxique et WYSIWYG. Éditeur Syntaxique Les éditeurs syntaxiques qui ne comprennent pas le service d édition avec un contrôle interactif (comme TeXnicCenter, emacs, etc.) permettent la manipulation d entités textuelles. Les fonctions d éditions fournies par de tels éditeurs incluent des opérations pour insérer et supprimer des caractères, des mots ou des lignes, pour effectuer la recherche 11. Mathematical Markup Language 12. Mathematical Markup Language

31 État de l art 19 d une chaîne de caractères, et permettent de mettre en évidence des éléments particuliers comme des mots-clés. Ce type d édition est le plus complexe, parce qu il pose un problème de la validation (compilation) et de la correction manuelle par l auteur. En plus, les éditeurs syntaxiques qui comprennent le service d édition avec un contrôle interactif (comme XMLSpy, Oxygen, etc.), permettent de mettre en évidence des fonctions syntaxiques liés à la structure : l ajout des balises fermantes automatiquement, proposition des choix possibles à un endroit donné, etc. Ce type d édition est plus facile que celui que nous avons expliqué précédemment. Éditeur WYSIWYG Les éditeurs WYSIWYG 13 permettent une édition structurée tout en cachant à l auteur la syntaxe de description de la structure (les balises). Ils offrent un environnement graphique qui aide l utilisateur à visualiser son document pendant toute la phase de création, identiquement à la représentation d impression. Ils permettent de manipuler dynamiquement des objets graphiques. Par exemple il y a des éditeurs WYSIWYG qui permettent d intégrer des formules mathématiques graphiquement comme AMAYA que je développerai dans le quatrième chapitre. Un autre exemple est l éditeur/formateur Quill [11], qui est un éditeur WY- SIWYG pour la manipulation des documents structurés composites. Il intègre l approche de structure de SGML, avec une interface de manipulation directe avec un système WYSIWYG. L utilisateur de Quill peut modifier la structure logique d un document, par une application des "tags" sur un certain segment de document. Il peut encore modifier la structure physique de document par une insertion, suppression, déplacement et copie d une section de texte. L éditeur/formateur Grif [16], puis Thot [33], est un éditeur WYSIWYG qui permet l édition des documents structurés avec un contrôle interactif. De plus le formatteur de Grif permet la transformation des documents vers des différents formats externe (troff, TEX, LATEX, Mint et SGML). Éditeur partiellement WYSIWYG Les éditeurs partiellement WYSIWYG sont ceux qui donnent une perception partielle du résultat de formatage final du document. Cette perception partielle peut avoir plusieurs origines, comme : le besoin de représenter le temps, les documents actifs (l interaction que l auteur peut faire), et les documents dont la présentation dépend du contexte du restitution (exemple : la langue). Par exemple, dans les éditeurs de documents multimédias le principe du WYSIWYG ne peut pas s appliquer à l édition de ces documents. En effet, le caractère dynamique 13. What You See Is What You Get

32 État de l art 20 de certains objets de base et le fait qu on veut ordonner dans le temps ces objets rendent impossible la fusion des phases d édition et de présentation. Les éditeurs Grins [14] et Madeus [19] permettent l édition et la présentation des documents multimédia de façon interactive. Ces systèmes permettent une spécification efficace d un scénario à l aide de différentes vues spatiales, structurels et temporelle et adaptent l intégration de la phase d édition et de la phase de présentation. Un autre cas où l éditeur WYSIWYG n est pas pertinent pour l auteur est l édition des documents qui ont des sorties MultiPlates-formes. C est le cas où on peut pas montrer à l auteur un très grand nombre sorties en même temps, due à l existence des versions cachées de documents qu il faut présenter à l auteur en fonction de ses actions, donc en fonction de l état courant de la présentation Synthèse Système d édition Edition des doc. Structurés Edition des doc. Linéaires Edition avec contrôle interactif Edition avec contrôle non interactif Editeurs WYSIWYG (Word,...) Editeurs Syntaxiques Editeurs WYSIWYG (TeXnicCenter, emacs,...) (Amaya, FrontPage,...) Editeurs Syntaxiques (XMLSpy, Oxygen,...) Editeurs partiellement WYSIWYG (LimSee, Madeus,...) Editeurs WYSIWYG (Grif, Amaya,...) Fig. 2.9 Une classification des systèmes d édition La figure 2.9 ci-dessus montre les relations entre les différents types d éditeurs et ceux des documents dont nous avons déjà parlé. Par exemple, XMLSpy l environnement de développement XML qui offre au développeur tout ce dont il peut avoir besoin dans ses développements XML, il fournit quatre points de vue sur les documents : une vue améliorée de l architecture pour une édition structurée, un point de vue sur les tables de données qui montre les éléments répétitifs sous forme de tableau, une visualisation de texte pour un travail de bas niveau avec coloration de

33 État de l art 21 la syntaxe, et une vue par un navigateur intégré qui supporte les deux types de feuilles de style CSS et XSL. Donc il peut être utilisé comme un éditeur syntaxique des documents structurés, en plus il offre un environnement d édition avec contrôle interactif. L éditeur Grif dont nous avons déjà parlé comme un éditeur WYSIWYG avec contrôle interactif. Nous remarquons que Amaya présente comme un éditeur WYSIWYG qui contrôle interactivement et en même qui ne l est pas. En effet, il est un éditeur WYSIWYG multi-vues dans lequel l édition peut se faire de deux manières : la première est le cas d édition avec l emploi des menus et de barres de boutons, ce n est pas nécessaire d entrer dans le code HTML pour créer et éditer un document. C est l édition avec contrôle interactif "implicite". La deuxième est le cas d édition direct de code HTML, c est l édition avec contrôle non interactif. 2.3 Rappel des objectifs Nous rappelons que notre objectif est d intégrer un service de TAFD dans un environnement d édition et de production de documents structurés qui offre certains avantages que nous décrivons dans la suite de ce mémoire. C est pourquoi nous avons abordé dans ce chapitre ces deux domaines, et que nous nous sommes focalisé sur les idées et principes qui nous amèneront à choisir l environnement d édition convenable. Les caractéristiques d un tel environnement sont spécifiées dans les deux prochains chapitres.

34 État de l art 22

35 Chapitre 3 Vers un nouveau cahier des charges de LIDIA-3 Dans la maquette LIDIA-2 l éditeur de document est un micro-éditeur XML. Il est nécessaire d aller plus loin en intégrant les services LIDIA dans un vrai éditeur XML extensible, pour pouvoir utiliser toutes les fonctionnalités, et transformer le document LIDIA en un document actif [26]. Dans ce chapitre nous présentons les choix qui vont permettre de développer une nouvelle maquette "LIDIA-3". Ce travail a commencé l année dernière lors du stage de fin d année de DUT d Informatique de Nicolas Romier [29]. Le travail n a pas été satisfaisant du fait de la durée temps du stage était trop restreinte et donc en terme du résultat obtenu. Finalement ce stage a permis de définir une première spécification de document et d architecture mais aucune implémentation n avait été faite. Le but est de réaliser un environnement LIDIA qui puisse permettre au premier temps de produire des documents XML (document LIDIA) riches, pour qu ils contiennent toutes les informations utiles aux services de traduction, visualisation et édition. L environnement doit aussi permettre de les désambiguïser interactivement et éventuellement de les traduire, et finalement de produire une forme de document autoexplicatif qui puisse être visualisée à la demande. Avec ces nouvelles perspectives, il sera d une part nécessaire de faire évoluer le modèle de document XML, et d autre part de considérer les modes d interaction et de visualisation à mettre en place. Nous développons ci-dessous les différents problèmes, choix et difficultés rencontrés, afin de bien positionner les solutions proposées dans les chapitres suivants. 23

36 Vers un nouveau cahier des charges de LIDIA-3 24 Processus interactif Edition reédition Processus autonome Analyse du document reédition auteur Désambiguïsation Interactive lecteur DAE source filtrage Document LIDIA Traduction auteur lecteur Document(s) cible(s) Fig. 3.1 Schéma fonctionnel simplifié 3.1 Processus de LIDIA-3 Le processus de LIDIA-3 est montré dans la figure 3.1 simplifié, dans lequel on ne montre que les grandes étapes à suivre pour obtenir son document en langue cible. Ces étapes sont les suivantes : Edition Dans un premier temps, l utilisateur commence par éditer le texte qu il envisage de traduire. La figure 3.1 montre qu on conserve le pouvoir d édition après l analyse et la désambiguïsation interactive. Le point délicat de cette permission, c est l édition entre la phase d analyse et la phase de désambiguïsation interactive. On développera le problème d incohérences éventuelles dans le dernier chapitre.

37 Vers un nouveau cahier des charges de LIDIA-3 25 Désambiguïsations Interactive Après l analyse du document par le serveur et le retour de l arbre de questions, l utilisateur peut lancer la phase de DI, pour désambiguïser le document par l un des moyens que doit lui offre la maquette. Traduction La dernière étape est le lancement de traduction du document, qui se déroule d une manière autonome, et qui fournit le(s) document(s) cible(s). 3.2 Découpage en rôle Nous présentons le découpage en rôle dans l environnement LIDIA en fonction des processus décrits ci-dessus. On distingue deux rôles d utilisateurs accédant aux services LIDIA. Ce découpage permet de formaliser les problèmes rencontrés Le rôle Auteur L auteur est l utilisateur du système, le créateur des documents qui a comme but de désambiguïser un texte (un document) et de le traduire pour le diffuser éventuellement. Il peut éditer son texte directement au sein de l éditeur et l enregistrer, soit l importer à partir d un fichier existant. Les deux cas sont représentés par le processus d édition montré dans la figure 3.1. Ensuite, l auteur doit lancer la phase de désambiguïsation de ce texte (document) qui necéssite l initialisation d une connexion avec le serveur de désambiguïsation. Ensuite, l auteur doit répondre aux questions de DI afin d éliminer les ambiguïtés, et enfin il peut éventuellement lancer la traduction, qui se déroule de manière autonome Le rôle Lecteur Le lecteur est l utilisateur des documents, qui est soit : Le lecteur de DAE source, dont le but est de comprendre le texte en langue source, il accède donc aux choix qu a fait l auteur, et qui sont enregistrés dans le DAE, pour comprendre son intention. Le lecteur d une traduction du texte source. Ce lecteur peut exploiter le DAE généré dans la langue cible (cf section 2.1.3), s il est disponible, pour améliorer sa compréhension du document.

38 Vers un nouveau cahier des charges de LIDIA Choix d interaction Lancement de connexion Dans l architecture informatique LIDIA-2, pour s engager dans une phase de désambiguïsation ou de traduction, l auteur doit établir la connexion avec le serveur de communication afin de lancer l analyse ou la traduction d un texte. Dans cette maquette, une connexion Telnet avait été utilisée. Les messages échangés entre le client (Auteur) et les serveurs étaient des flots de données textuelles. Dans la nouvelle maquette, on veut envoyer des données structurées en XML. Si ce n est pas nécessaire, aucune connexion n est établie entre l environnement de rédaction et le serveur de communication. Dans le cas où l auteur lance l analyse d un texte (ou sa traduction) et si la connexion n est pas encore établie, le système doit réagir par un feedback, c est-àdire, un retour d information immédiat de l état pertinent du système afin de proposer à l auteur de se connecter Désambiguïsation Interactive (DI) L un des objectifs du projet LIDIA est l étude des possibilités d interaction entre le système de TAO et l auteur. On part de l hypothèse que l auteur est monolingue, il n a aucune connaissance particulière en linguistique. Donc il ne pourra pas réviser la traduction, donc le système devra produire une traduction de qualité. Cette qualité envisagée est garantie par la phase de désambiguïsation interactive [5]. D abord nous clarifions certaines notions qui dépendent du processus de DI et que nous n avons pas mentionnées dans le premier chapitre. La reconnaissance des ambiguïtés est associée à l existence d au moins deux analyses grammaticales pour une même phrase. Une reformulation 1 d une phrase est associée à une ou plusieurs analyses. Une question est définie par le choix entre les reformulations pour une même phrase. Le principe simple de DI, est que le système pose une question ou une succession de questions sous forme non ambiguë à l auteur. Nous présentons la mise en œuvre de l étape de DI dans la maquette LIDIA-2 en proposant de nouvelles idées pour l amélioration de "l ergonomie" de cette étape. Dans LIDIA-2, version java de l environnement d accès aux services de TAFD, les phrases ambiguës sont colorées en brun et les phrases non ambiguës en vert (Figure 3.2 tirée de [3]). Lorsque l auteur clique deux fois sur une phrase ambiguë, le dialogue de désambiguïsation, relatif à 1. il correspond à un item dans les anciennes maquette