Gestion des connaissances dans une base de documents ...csidoc.insa-lyon.fr/these/2003/egyed_zsigmond/these.pdf · 1 1. Introduction 5 1.1. Motivation 5 1.2. Le projet RECIS 6 1.3

1

1. Introduction 5 1.1. Motivation 5

1.2. Le projet RECIS 6

1.3. Résultats obtenus 6

1.4. Plan du document 7

2. La gestion des connaissances dans une base de documents multimédias 9 2.1. Le document numérique 11

2.2. La représentation des documents numériques et de leurs usages… 14 2.2.1. Les documents textuels 14 2.2.2. Les images 15 2.2.3. Les documents sonores 17 2.2.4. Les documents vidéo 17 2.2.5. Les documents multimédias 18

2.3. Les tâches de manipulation de documents multimédias 20 2.3.1. Création de documents multimédias 20 2.3.2. Recherche dans des documents multimédias 21 2.3.3. Réutilisation de documents multimédias 25

2.4. L’annotation comme méthode de base pour les tâches de création, recherche et réutilisation de documents audiovisuels 28

2.4.1. Pourquoi l'annotation ? 28 2.4.2. Comment annoter ? 28 2.4.3. Quoi annoter ? 29 2.4.4. Avec quoi annoter ? 30

2.5. Travaux apparentés dans l’annotation de documents 33

2.6. L’assistance aux tâches liées à l’exploitation des documents audiovisuels 40 2.6.1. Critères de classification 40 2.6.2. Illustration de différents systèmes d’aide 41 2.6.3. Synthèse 43

2.7. L’assistance à l'annotation et à la recherche 45 2.7.1. Assistance structurée (ontologie) : 47 2.7.2. Assistance au cas par cas (analogie) 49 2.7.3. Assistance mixte 53

2.8. La nécessité d’un modèle prenant en compte les usages pour une assistance "en contexte" exploitant l'analogie de situations 54

3. Contribution : E-SIA 55 3.1. Un exemple introductif 57

3.2. Modèle de description de documents (Strates-IA) 59 3.2.1. Présentation des Strates-IA 60 3.2.2. Analyse critique du modèle des Strates-IA 63

3.3. Le modèle E-SIA 66 3.3.1. Objets de base 68 3.3.2. Documents et fragments 68 3.3.3. Annotations 70 3.3.4. Eléments de contrôle d’organisation et de documentation des annotations 73

3.4. Représentation formelle de E-SIA. 86 3.4.1. Le graphe 86 3.4.2. Specificités des objets E-SIA 87 3.4.3. Contraintes sur les objets et relations 92 3.4.4. Les graphes potentiels 99

3.5. Discussion 104

4. Modèle de traces d’utilisation 107 4.1. Le modèle Trèfle♣ 110

4.1.1. Présentation générale 110 4.1.2. Le graphe 114 4.1.3. Traces 121 4.1.4. Les épisodes 123 4.1.5. Réutilisation de l’expérience 131

4.2. Application à RECIS 140 4.2.1. Modèle d'utilisation 140 4.2.2. Modèle d'observation 141 4.2.3. Scénario et construction des épisodes 142

4.3. Discussion 147

5. Prototype 149 5.1. Objectifs 150

5.2. Cahier des charges 151

5.3. Architecture globale 152

5.4. Modules 152 5.4.1. Application centrale 152 5.4.2. Les interfaces homme machine 157 5.4.3. Les assistants 162

5.5. Graphes sérialisés 163 5.5.1. Représentation en XML des objets E-SIA 163 5.5.2. Graphes en Tables 165

5.6. Discussion 166

6. Conclusion 167

7. Références 171

8. Annexes 187 8.1. Architecture global du prototype 187

8.2. Application centrale, diagrammes de classes gérant les annotations 190

8.3. Présentation des procédures d’annotation 193

8.4. Les interfaces du site dynamique 196

8.5. Exemples de fichiers XML 201 8.5.1. Les documents XML contenant la base de connaissances 201 8.5.2. Les documents XML contenant les éléments d’annotation 202 8.5.3. Les documents XML contenant les arêtes du graphe 204

3

8.6. Choix de SGBD 206

8.7. Schémas de base de données 208

8.8. Communication 210 8.8.1. L'architecture à mettre en place sur le serveur 212 8.8.2. Architecture interne au module distant 214 8.8.3. Traitements courts 214 8.8.4. Traitements différés 214 8.8.5. Objets utilisés pour la gestion de session 216

EGYED-ZS. Előd Gestion de connaissances dans une base de documents multimédias

4

Introduction

5

1. Introduction

1.1. Motivation

Les images et vidéos numériques prolifèrent aussi bien dans les institutions que dans les foyers privés. Les problèmes liés à leur gestion commencent à apparaître. En effet il s’agit d’un nouveau type de document qui appartient à notre quotidien. La gestion de grandes quantités de documents est pourtant un problème déjà ancien, donc l’arrivé de l’informatique et l’apparition de ce que nous appelons aujourd’hui de do-cuments numériques ont profondément modifié la donne. Prenons par exemple la recherche d’images ou de vidéos numériques. Il est difficile de décrire ce que nous aimerions trouver. A partir, par exemple d'une image, d'une mélodie, d'un dialogue qu'il a en tête, un utilisateur d’un système de gestion de do-cuments voudrait retrouver le fragment de vidéo qui les contient. Pour faire compren-dre à un système informatique son souhait, celui-ci doit disposer d’interfaces de créa-tion de requêtes riches, multimodales, personnalisables. En effet il est bien différent d'entrer des mots clés dans un champ d’édition, de donner des descripteurs numéri-ques, de dessiner une esquisse ou bien de siffler une mélodie dans un microphone pour construire une requête. Comment de telles requêtes peuvent être exécutées ? Le nombre, la diversité d’usage des documents numériques est très grande ce qui né-cessite le classement, l’indexation et l’annotation pour en permettre une exploitation plus aisée. Les modèles d’organisation et d’enrichissement de documents numériques sont très variables et parfois peu documentés, rendant les tâches d’annotation pour classer, indexer, rechercher, partager, etc. d’autant plus complexes que ces documents sont multimédias et/ou audiovisuels. Aussi bien la recherche, que l'annotation passent par un processus de description. Dans le premier cas nous décrivons ce que nous aimerions trouver, dans le second la description porte sur ce que nous observons. Il est important que la description des documents audiovisuels soit homogène. Dans le cadre d’une émission sportive par exemple, si les participants à une course cycliste sont désignés parfois par les mots clés : cyclistes, coureurs ou encore concurrents, il serait beaucoup plus complexe de formuler une requête retrouvant toutes leurs occurrences que s’ils étaient identifiés toujours par le même mot clé. La complexité des tâches d’annotation et de recherche provient de la très grande va-riabilité potentielle des points de vues aussi bien pour décrire initialement (à l’archivage) un document que pour le décrire par la suite (pour une recherche, une analyse,…). Les descripteurs sont potentiellement infinis ce qui rend extrêmement difficile pour un utilisateur d’être cohérent et homogène avec d’autres annotations. Il est donc pertinent de mettre en place des assistants informatiques qui facilitent les tâ-ches de recherche et d’annotation et contribuent au bon déroulement des interactions homme-machine. Pour résumer la problématique : nous voulons enrichir les services de recherche et d’accès à l’information multimédia. Pour cela nous étudierons les méthodes de des-cription et d'exploitation de ces informations ainsi que l'assistance aux utilisateurs pour effectuer cette exploitation et description.


6

1.2. Le projet RECIS

Nos travaux de recherche se déroulent dans le cadre du projet RECIS soutenu par le Réseau National de Recherche en Télécommunications. Le projet se fait en commun avec France Télécom Recherche et Développement, le LIRIS (ex Laboratoire d'Ingé-nierie des Systèmes d'Information (LISI)) et le projet IMEDIA de l’INRIA. L'objectif de ce projet est d'étudier et de développer des outils permettant d’enrichir les services de recherche et d’accès au contenu multimédia. Il s'agit d'élaborer un sys-tème qui permette à l'utilisateur d'exprimer facilement et précisément une requête, un système qui trouve rapidement des résultats pertinents, puis propose des moyens pour raffiner la requête et qui mette à disposition de l’utilisateur plusieurs méthodes de vi-sualisation des résultats. Nos partenaires sont spécialisés dans le traitement des images, du son et de la vidéo. Ils élaborent des méthodes de découpage et indexation automatique. France Télécom R&D joue également le rôle de client industriel et met en place la stratégie d’application industrielle et commerciale des résultats du projet. Les travaux de notre équipe portent sur l’annotation de documents et sur l’étude de l’aide à l’utilisateur dans la mise en place et l’exploitation de ces annotations. Nous avons été également les « maîtres d’ouvrage » du prototype implantant les modèles théoriques. Nous avons intégré et permis exploitation des résultats, au niveau descrip-teurs extraits de manière automatique ou semi-automatique, de l’ensemble de parte-naires.

1.3. Résultats obtenus

Nos recherches ont abouti à la mise en place d’un modèle théorique d’annotation et d’exploitation de documents audiovisuels qui permet la gestion d’un grand nombre de documents par plusieurs personnes. Nous avons en effet identifié trois tâches principales qui se retrouvent dans la plupart des tâches d’un utilisateur : l’annotation d’un fragment de document, la recherche de fragments de document, la navigation entre fragments de documents. Nous avons donc cherché à mettre en place une modélisation des connaissances expliquant l’expérience utile pour assister ces trois tâches génériques dans le contexte des tâches réelles de l’utilisateur (nos résultats sur ce dernier point sont publiés dans [Egyed-Zs. et al. 2002, Egyed-Zs. et al. 2003] Le modèle permet de faciliter l’exploration des annotations posées par d’autres et soutient l’émergence de méthodes cohérentes de description. Cela est possible grâce aux structures qui documentent les manières d’annoter, tout en laissant une grande li-berté d’expression à ceux qui décrivent les documents. Le modèle représente dans un même graphe aussi bien les fragments de documents que les descripteurs et les élé-ments qui structurent les annotations. Pour démontrer la faisabilité de notre modèle théorique nous avons développé une application client-serveur qui permet d’annoter des vidéos et qui permet l’exploration ainsi que la recherche directe dans des annotations et les documents annotés. Nous avons également crée un modèle théorique qui élargit le graphe des annotations avec les traces des actions des utilisateurs qui annotent et recherchent. L’idée de base vient du constat que dans une application informatique nous pouvons considérer que

Introduction

7

des utilisateurs manipulent des objets à l’aide de procédés. Notre modèle regroupe de manière originale dans un même graphe aussi bien des nœuds représentant les utilisa-teurs et leurs sessions que les procédés mises à disposition par l’application et les ob-jets manipulés. Ainsi nous pouvons tracer de manière riche l’annotation et la recher-che de documents en contextualisant fortement chaque élément de la trace. Enfin nous proposons un cadre de mise en place d’un système d’aide à l’annotation et à la re-cherche de documents basé sur la réutilisation de l’expérience. Ce cadre utilise le graphe de traces comme conteneur de potentiels épisodes d’annotation et de recherche exploités comme des cas réutilisables selon le paradigme du raisonnement à partir des cas.

1.4. Plan du document

Nous commençons par présenter en général la gestion de connaissances dans une base de documents multimédias dans le chapitre 2 . Nous précisons le sens de chaque mot du titre, introduisons les notions de document numérique multimédia et introduisons la représentation des documents numériques et leurs usages. Les spécificités des do-cuments audiovisuels sont mises en avant, aussi bien du point de vue de leur traite-ment par les ordinateurs que du point de vue des tâches de manipulation de ces docu-ments par des utilisateurs humains. La tâche d’annotation est celle qui, selon notre point de vue, peut être considérée comme méthode de base pour l’ensemble de tâches de création, recherche et réutilisation de documents audiovisuels. La deuxième partie du chapitre 2 est consacrée à l’assistance aux tâches liées à l’exploitation de documents numériques. Nous présentons différentes manières d’assister l’utilisateur dans la réalisation de sa tâche et dressons une liste de caracté-ristiques pour les systèmes d’assistance. Le but de ce chapitre est de mettre en évi-dence la complexité de la manipulation de documents audiovisuels numériques, dû à leur structure et à leur caractère subjectif, sujet à interprétation. Puisque la manipula-tion de ces documents est complexe et fait intervenir souvent un effort créatif, une as-sistance à réaliser les différentes manipulations est nécessaire. Dans le chapitre 3 nous présentons le modèle SIA, constituant un point de départ de nos recherches puis décrivons en détails notre modèle, E-SIA, en énumérant les diffé-rents éléments : les annotations et les fragments de documents, les éléments organi-sant les annotations, l’outil d’exploitation qui est le graphe potentiel. Les éléments du modèle E-SIA, s’inscrivent dans un graphe connexe, orienté et étiqueté qui est décrit formellement dans la deuxième partie de ce chapitre. Le chapitre 4 décrit notre proposition de modèle de traces d’utilisation, Trèfle♣, qui prend sa genèse dans le modèle E-SIA mais qui est générique et peut être appliqué à d’autres systèmes informatiques que ceux visant la manipulation de documents. Trè-fle♣ formalise le suivi contextualisé des actions des utilisateurs qui manipulent des documents. Les traces sont représentées sous forme d’un graphe. Nous introduisons les notions de modèle d’utilisation et modèle d’observation qui font partie du graphe et qui structurent la construction de traces proprement dites. Nous expliquons la ma-nière dont le cadre d’observation de l’utilisation d’une application doit être mis en place, les méthodes de construction de traces d’utilisation contextualisées. Nous, nous appuyons sur ces traces pour proposer une méthode de construction dynamique


8

d’épisodes d’annotation selon le contexte de la tâche courante de l’utilisateur souhai-tant réutiliser l’expérience contenue dans les traces. Nous présentons par la suite l’application du modèle Trèfle♣ pour notre système d’annotation et de recherche de vidéos. Un modèle d’utilisation et un modèle d’observation spécifique sont construits et le scénario de construction de traces est défini. Après la description des modèles théoriques, le chapitre 5 décrit l’application mise en place pour démontrer la faisabilité du modèle d’annotation et d’exploitation. Ce pro-totype implante à travers une interface graphique et une architecture client serveur les notions traitées dans les chapitres précédents et constitue un cadre d’expérimentation pour nos futurs recherche. Dans la conclusion nous énumérons nos perspectives d’amélioration de nos modèles et des domaines dans lesquels nous considérons l’approfondissement des recherches menées.

Etat de l’art

9

2. La gestion des connaissances dans une base de

documents multimédias Ce chapitre présente un état de l’art de la gestion des connaissances et les documents. Nous commençons par donner quelques précisions sur ce qu’est un document multimédia en pré-sentant les différents types de documents numériques : documents textuels, images, sons, vi-déos. Une étude de leurs spécificités intrinsèques ainsi que les caractéristiques de leur mani-pulation sont énumérés. Nous étudions notamment leur création, exploitation par la recherche et la navigation et leur réutilisation. Nous continuons par une étude de l’annotation des docu-ments, considérée comme méthode de base pour les autres tâches de manipulation. Dans la deuxième partie nous traitons l’assistance à la manipulation de documents. Cette as-sistance utilise les connaissances liées aux documents, connaissances provenant directement du contenu ainsi que de la manipulation des documents. Nos travaux traitent de la gestion des connaissances dans une base de documents mul-timédias. Chaque mot de ce titre a besoin d’être éclairci. Que sont les documents, comment intervient la connaissance dans une base de documents ? Pour cela nous de-vons définir la notion de « base de documents ». Nous parlons des connaissances dans une base de documents. Que sont les connaissances, comment sont elles « cachées » dans des documents et comment les utilise-t-on ? Nous voulons renseigner, enrichir un document par l'usage. Nous voulons combiner, faire coexister le document et son utili-sation. L’informatique a bouleversé la notion de document : les informations étroitement et définitivement reliées à leurs supports (papier, pellicule, vinyle,…) migrent vers des documents numériques, stockant contenu et mode de visualisation sur un même sup-port, pouvant être combinés facilement et de manière ponctuelle. Dans ce chapitre nous passons en revue l’évolution des documents et de leur manipu-lation. Nous étudions le changement de rôle et de caractère des documents ainsi que la modification de comportement des « lecteurs » et des « auteurs » de documents. Nous allons voir que ces rôles ne sont plus aussi distincts qu’auparavant. Dans un premier temps, nous allons présenter les différents types de documents nu-mériques, en commençant par les documents textuels, les images, en passant par les documents audiovisuels pour arriver aux documents multimédias. La deuxième partie de l’état de l’art concerne la manipulation des documents et l’assistance à cette manipulation. Nous étudierons les tâches liées à la manipulation de ces documents, plus principalement : la création, la recherche et la réutilisation. L’annotation étant la méthode de base de ces différentes tâches, nous passerons en revue les travaux dédiés à l'annotation. Après avoir étudié les tâches de manipulation de documents, l’assistance à ces tâches est introduite, par une présentation de systèmes d’aide en général et nous terminerons


10

par l’étude de la question de l’assistance particulière à l’annotation en faisant une synthèse des travaux proches de notre thèse.

Etat de l’art

11

2.1. Le document numérique

Dans cette section nous introduisons la notion de document numérique, par quelques considérations générales, en insistant sur les différences par rapport aux documents papier « classiques ». Selon Umberto Eco [Eco 1985] les documents véhiculent trois significations : l’intentio auctoris, le sens que l’auteur a voulu transmettre, l’intentio operas le sens propre de l’œuvre et l’intentio lectoris le sens que le lecteur perçoit. En effet lorsque des idées, des faits sont traduits par l'auteur sur un support écrit, ils subissent un co-dage dû à la fois à la personnalité et l’interprétation de l’auteur et à la traduction des idées en lettres et mots. Lors de la lecture de ce document, le langage codé est inter-prété par le lecteur qui reconstruit des idées en les enrichissant et en changeant ainsi le sens propre du document. En parlant de documents nous pouvons dire qu’il y a un auteur qui veut faire passer un message à un lecteur. Ce message est codé, transposé sur un support et perçu dans un certain contexte par le lecteur. L’origine même du mot document, le verbe latin docere, veut dire instruire, ce qui laisse entendre que derrière un document il y a des actions, des méthodes et des pro-cédures à côté des données brutes. Le dictionnaire Le Petit Robert [Rey et al. 1992] définit néanmoins le premier sens du mot document comme étant un renseignement écrit ou objet servant de preuve, d’information ou de témoignage. Pour qu'un docu-ment puisse servir comme preuve, il doit être pérenne dans le temps. Cela était en grande partie vrai pour les documents papier ; les documents électroniques par contre sont par définition immatériels et leur pérennité pose question. Les méthodes de vi-sualisation, de présentation et donc d'interprétation des documents numériques sont variées. L’informatique a introduit plusieurs niveaux de codage [Bachimont 1999]. Alors que pour les documents « classiques » le système de codes est l’alphabet de la langue uti-lisée, et que le document textuel est représenté uniquement à l’aide de ces signes, un document numérique peut, certes, représenter une suite de lettres d’un alphabet, mais ces lettres sont codées dans « l'alphabet » de l'ordinateur – les bits-. La structure phy-sique et la structure logique [Michard 1999] des documents se distinguent. Les mê-mes informations, le « même document » se représentent différemment sur un écran couleur de haute résolution, sur des feuilles imprimées ou encore sur l’écran mono-chrome d’un téléphone portable. Les manières d’encoder et d’interpréter des docu-ments se démultiplient. Le document numérique perd ainsi le caractère de preuve que présente le document matérialisé. [Bachimont 1999] souligne qu’alors que les document textuels pouvaient se consul-ter à une vitesse propre au lecteur, avec l'apparition du cinéma d'abord et surtout avec l’évolution de l’informatique, des documents contenant à la fois du texte, des images, du son, des vidéos, se sont répandus. Ces documents multimédias introduisent la no-tion de temporalité. Une vidéo ou une symphonie de 30 minutes nécessitent exacte-ment 30 minutes pour être visionnées, écoutées par un humain.


12

Le multimédia et le support numérique rendent imprévisible le parcours du document. Pour lire un roman, écrit en français, nous commençons à la première page, nous par-courons le livre du début vers la fin, en suivant les mots de gauche à droite et de haut en bas pour terminer à la dernière page, en ayant parcouru tout ce qui est entre les deux. Dans le cas d’une page web ou d’un CD-ROM contenant des fragments de vi-déo, du son et des hyper liens, le lecteur a beaucoup plus de libertés pour choisir son parcours dans le document. Le parcours n'est plus obligatoirement linéaire comme pour la plupart des documents papier. Un document numérique peut être considéré comme un ensemble de données et des méthodes de présentation [Chaudiron et al. 2000]. Les méthodes de présentation peuvent être associées à des requêtes, à des filtres qui permettent de sélectionner une partie des données. Bien sûr, ces méthodes incluent les outils de présentation propre-ment dits aussi (feuilles de style, visionneuse de vidéo, lecteur de musique, …). Les informations formant le document peuvent se trouver sur différents supports (de même nature néanmoins). En effet il est facilement imaginable que sur un site web contenant du texte, des images et de la vidéo, le texte provienne de plusieurs serveurs distincts qui eux même ne sont pas les mêmes que ceux qui contiennent les images ou les vidéos. La page web affichée peut néanmoins être considérée comme un docu-ment. Pour exploiter les documents, on développe des méthodes de recherche qui permettent d’exploiter leur structure. Dans le cas de documents textuels l’unité de base est en général le mot. Les systèmes de recherche par mots clés (les moteurs de recherche sur le web : Google1, Altavista2,…) fonctionnent relativement bien. Etant donné le grand volume de documents disponibles, la recherche textuelle se fait rarement en temps ré-el, dans le texte entier. Les documents sont analysés régulièrement, des mots, des fragments jugés importants en sont extraits selon différentes méthodes. Ces fragments servent ensuite pour construire des index. Plusieurs travaux [Aguierre-Smith et al. 1992, Bachimont 1999, Bargeron et al. 1999, Corvaisier et al. 1999, Correia et al. 2000, Hürst 2002, Stotts et al. 2002] soulignent que l’unité du document numérique est difficile à définir : la différence en-tre fragment documentaire, document et corpus s’estompe, et ni les supports physi-ques (support et forme d’enregistrement), ni les modalités de consultation ne permet-tent de cerner précisément les frontières d’un document. D’un certain point de vue, c’est le lecteur, devenu co-auteur, qui construit un document unique à travers son propre parcours de lecture et ses éventuelles annotations impliquant un réseau de res-sources diverses. Toute trace de l’activité (de consultation et d’édition) peut à son tour prendre un caractère documentaire.

1 www.google.com (2002) 2 www.altavista.com (2002)

Etat de l’art

13

Nous pouvons dire après cette présentation que les documents numériques introdui-sent une nouvelle façon de gérer des informations et nécessitent des outils capables de prendre en compte leurs spécificités, leur quantité et leur complexité.


14

2.2. La représentation des documents numériques et de leurs usages…

Avant d’étudier les différentes tâches liées aux documents, il est important de regar-der d’un peu plus près comment ces documents sont représentés. Les documents véhiculent de l'information. Cette information, comme nous le ver-rons, peut être représentée sous la forme de texte, d'images, de son, de vidéo ou de la composition de ces différents « média ». [Scuturici 2002] définit le terme « média » comme un moyen de :

- diffusion massive de l'information : presse écrite, radio, télévision [Rey et al. 1992]

- représentation de l'information qui peut être diffusée par les médias cités aupa-ravant : le texte, le son, l'image fixe, la vidéo

- perception de l'information : vue, ouïe, … - stockage de l'information : papier, disque magnétique, …

Nous utilisons le sens de représentation de l’information par la suite. Dans ce chapitre nous allons parler de différents types de documents, en présentant l’évolution de leurs méthodes de codage numérique, tout en soulignant les spécificités de chaque media.

2.2.1. Les documents textuels

Les documents numériques subissent une évolution continue. Les documents textuels ont été les premiers à être numérisés. Un codage spécifique a été développé (ASCII3) basé sur les caractères de l'alphabet anglais. On s'est rendu compte rapidement que la représentation des caractères sur un octet ne suffisait pas et un autre système codant les caractères sur plusieurs octets (Unicode4) a été développé. ASCII et Unicode représentent un codage binaire des lettres et signes, cela ne suffit pas néanmoins pour avoir des documents numériques. Si les signes et les caractères sont codés, il reste à formaliser tout ce qui caractérise le document en tant que docu-ment : structure, présentation, sources, … Chaque logiciel qui permet de gérer des documents repose souvent sur un format spé-cifique (document MS Word, LaTex, rtf, HTML, pdf). Dans la plupart de ces repré-sentations, contenu proprement dit, structure et présentation sont codés au même ni-veau. Les informations sur le découpage d'un texte en chapitres, les indications sur la

3American Standard Code for Information Interchange, http://www.asciitable.com/ (2003) 4 http://www.unicode.org/ (2003)

Etat de l’art

15

taille des polices pour les titres et les paragraphes ainsi que le texte lui-même sont as-sociés dans une même unité de stockage (doc, rtf, pdf). C'est avec l'apparition de SGML [ISO 2001] et ses dérivés (XML [W3C 2002b], …) que les indications sur la présentation du document sont séparées du contenu du do-cument à l'aide de feuilles de style (CSS, XSL [W3C 2003a, W3C 2003b],…). Cette représentation permet d'attribuer à un même contenu plusieurs méthodes de présenta-tion. Avec la numérisation, la linéarité des documents textuels prend une dimension éten-due par rapport à leurs versions sur papier. L'utilisation des liens entre différentes parties des documents devient banale. Bien que les premiers systèmes que l'on peut appeler hypertextuels aient été conçus dès les années 1940 [Bush 1945], c'est plus tard que le numérique et notamment l'explosion du web avec la norme HTML (1992) [W3C 2002a] ont finalement fait entrer dans les habitudes la lecture non linéaire d'un document textuel. Les ordinateurs communiquent avec leurs utilisateurs encore essentiellement de ma-nière textuelle, grâce au clavier. C'est en effet encore le système de signes le mieux maîtrisé pour communiquer avec la machine, ou avec une autre personne à l'aide d'un ordinateur. Les travaux dans ce domaine, en commençant par les fiches Memex de Bush [Bush 1945] en passant par les travaux de Douglas Engelbart, le système Xana-du de Ted Nelson, Hypercard de Bill Atkinson, le HTML et SGML de Tim Berners-Lee et Robert Caillau pour arriver finalement à XML et ses dérivés, montrent une évolution qui tend à faciliter l'accès à l'information utile pour l'utilisateur sous la forme la mieux adaptée en permettant de prendre en compte des contextes de plus en plus complexes.

2.2.2. Les images

Les origines des documents numériques contenant des images remontent aux années 1950 [Bres et al. 1999]. En représentant les images de manière numérique il a fallu coder les couleurs à l'aide de valeurs discrètes. Une image numérique peut être représentée comme une matrice de pixels, mais il existe un autre type d'images numériques, les images vectorielles, dont le principe est de représenter, autant que cela est possible de le faire, les données de l'image par des formes géométriques qui vont pouvoir être décrites d'un point de vue formel. Les images vectorielles sont constituées d’un ensemble d’objets géométriques : des points, courbes, surfaces fermées, … décrites par des coordonnées et des équations et formules. Pour les présenter, il faut dessiner ces objets dans un système de coordon-nées et le projeter sur une surface. Cela peut être une matrice de pixels qui sera traité par la suite comme une image matricielle, mais les objets peuvent être directement dessinés sur un papier (traceurs, imprimantes postscript5) ou sur certains types d’écrans. L’intérêt des images vectorielles consiste dans :

5 http://www.adobe.com/products/postscript/ (2003)


16

- leur taille réduite (au lieur de stocker des informations pour chaque point de l’image, il suffit de stocker la description géométrique des objets),

- leur invariabilité face aux homotéties et modifications géométriques (il suffit de changer le système de coordonnées et redéssiner les objets)

- la facilité de sélectionner ou ignorer une partie de l’image (en effet les objets sont manipulables séparément).

Une image numérique matricielle est composée d'unités élémentaires (appelées pixels) qui représentent chacun une portion de l'image. Une image est définie par : le nombre de pixels qui la compose en largeur et en hauteur et l'étendue des teintes de gris ou des couleurs que peut prendre chaque pixel (on parle de dynamique de l'image) [Boudry 2002]. Ces points codent une couleur, selon une certaine méthode (RVB, YUV, …). Une image matricielle occupe beaucoup de place en mémoire (en général nombre de lignes * nombre de colonnes * nombre d'octets codant les couleurs de chaque pixel). Plusieurs algorithmes de codage de l'image ont été développés pour compresser les images matricielles. Cette compression peut s'effectuer sans (BMP, PCX, PNG, …) ou avec (JPG,..) perte d'information [Boudry 2002]. Les images numériques sont aujourd'hui disponibles en grande quantité, non seule-ment en milieu professionnel mais également pour des particuliers, grâce à la prolifé-ration des appareils photo numériques. Leur acquisition, archivage, recherche et pré-sentation constituent des tâches nouvelles. La manipulation des images passe par des méthodes et systèmes de traitement et de gestion d'images. Dans une image on peut typiquement identifier un fond ou arrière plan et des objets. Les objets sont délimités par un contour. De plus dans une image on peut définir des régions en identifiant leurs frontières. Les régions sont typique-ment des formes géométriques simples (rectangle, ellipse, ..) mais peuvent être défi-nies par les contours de différents objets. Des systèmes analysent les images numériques pour en extraire des signatures, des in-formations sur leurs textures, sur les couleurs dominantes, sur les contours, sur les objets présents, …[Hauptmann et al. 2002a] Ces informations sont codées sous forme numérique, lisible pour un ordinateur mais pas forcément pour un lecteur hu-main. Récemment les documents numériques images, se sont enrichis avec des méta-données textuelles incorporées (EXIF6). Ces méta-données permettent de stocker des informations non visuelles, telles que la date de création/modification, les éventuelles caractéristiques de prise de vue s’il s’agit d’images prises par des appareils photo numériques, … Pour leur classement, recherche et réutilisation les systèmes de mani-pulation d'images se servent de ces informations obtenues par l'analyse automatique, ainsi que des informations et descriptions concernant les images créées à la main. En effet lorsqu’une image est interprétée par un être humain, il la décrit par des mots ex-primés à l'aide de lettres. La subjectivité et l’hétérogénéité de ces interprétations sont donc élevées.

6 Exchangeable Image File Format, http://www.exif.org/ (2003)

Etat de l’art

17

2.2.3. Les documents sonores

Le son peut également être représenté de manière numérique. Les ondes sonores sont converties par un convertisseur analogique - numérique et les données ainsi obtenues sont quantifiées (représentés par des valeurs discrètes) aussi bien dans leur amplitude que dans le temps [Nahrstedt 2002]. Un son numérique est échantillonné à une cer-taine fréquence (le CD à 44100 Hz, le téléphone à 8000 Hz) et est caractérisé par son amplitude, le nombre de canaux (mono, stéréo, Dolby 5.1, …), ... Un document numérique sonore peut être composé d'une ou plusieurs voix, on parle dans ce cas de son mono- ou poly-phonique. Plusieurs codages existent [Bagwell 1998]. Les documents numériques sonores peu-vent être également compressés. Leur compression est assez difficile, c'est une des raisons pour lesquelles l'on assiste encore aujourd'hui à plusieurs méthodes proprié-taires ou semi-publiques (ma, RealAudio, mp3, …) qui se disputent le marché sans vraiment pouvoir prendre le dessus. Par rapport au texte et aux images fixes numériques le son introduit une autre dimen-sion qui est le temps. En effet par nature (le son est la perception d'une vibration) le son a une durée. Le son intemporel n'existe pas. La perception de l'information véhi-culée par les documents sonores nécessite un certain temps. Pour les documents numériques sonores, la notion de débit devient importante. En ef-fet pour pouvoir rejouer une musique ou un dialogue il faut disposer d'un certain dé-bit de données. En général ce débit est exprimé en kbit/secondes. Le débit typique d'un morceau enregistré sur CD audio est de 128 kbit/s. Dans un document numérique sonore, des séquences peuvent être identifiées en préci-sant leurs bornes temporelles sur l'échelle de temps du document. Sur un morceau de musique de 3 minutes, nous pouvons dire par exemple que nous nous intéressons à la séquence qui commence à la 30ème seconde et qui se termine à la 40ème seconde. Dans [Hsu et al. 2002] on peut trouver une comparaison de différentes méthodes de repré-sentation et de recherche de documents sonores.

2.2.4. Les documents vidéo

La vidéo est un flux temporel d'images. Les documents numériques vidéo contiennent un ensemble d'images et des informations sur la cadence avec laquelle ces images doivent être représentées dans un cadre pour qu'elles donnent l'impression de mou-vement. Un document numérique vidéo contient souvent également du son. Ce son est syn-chronisé avec les images dans le temps. Il peut avoir été enregistré en même temps que les images, ou bien leur être rajouté ensuite. Une séquence vidéo est une mise en ordre des éléments d’un document numérique vi-déo selon un ensemble de règles. Il s’agit d’images numériques disposées chronologi-quement avec éventuellement une bande son. Un document numérique vidéo peut être considéré comme une seule ou un ensemble de séquences vidéo. Une séquence vidéo est identifiée par ses instants de départ et de fin sur l’échelle de temps du document vidéo numérique. En général les documents vidéo sont le résultat d'un montage qui consiste à coller l'un après l'autre des plans avec d'éventuels effets de transition. Un plan est le résultat d'une prise sans couper la caméra. Lors du traitement automatique de vidéos on parle souvent de détection de plans, c'est à dire de détection des coupu-res dans la vidéo finale.


18

La taille des documents vidéo numériques non compressés est immense. En qualité professionnelle (NTSC HD, [Benoît 2002]) elle peut atteindre 1 Go pour une se-conde, d’où la nécessité de compression, surtout pour pouvoir les diffuser sur un ré-seau. Comme d’autres types de documents numériques, les vidéos numériques peu-vent être compressées selon plusieurs algorithmes (MPEG 1,2,4 [MPEG 2003] et des dérivés propriétaires : wmv, QuickTime, RealVideo7,…). Avec une compression en MPEG 2 équivalente au NTSC HD cité avant, le débit de la vidéo est de l’ordre de 80 Mo/seconde, ce qui implique un facteur de compression de plus de 12 à 1. Les documents numériques vidéo peuvent également inclure des méta-données tex-tuelles. Nous y reviendrons plus tard. Un document numérique vidéo a un certain nombre de caractéristiques physiques :

- le format qui indique le mode de représentation des données vidéo dans un fi-chier,

- le type de compression, est souvent lié au format et indique l’algorithme de compression utilisé (MPEG1, MPEG2, DivX, …),

- la taille en nombre d’octets, - la cadence en images par secondes ; le standard NTSC8 est de 30 images par se-

conde, - le débit en mégabits /seconde, - la définition de l’image représente le nombre de pixels affichés pour une

image ; la définition classique est de 625 par 400 pixels, - la durée, qui représente le temps nécessaire à un humain pour visionner en en-

tier le document vidéo numérique. Une vidéo est également un document temporel. Il peut être considéré en trois di-mensions : deux formées par les lignes et les colonnes d’une image et la troisième par le temps. En plus des séquences contenant des images entières il est imaginable d’identifier seulement des objets se trouvant sur des images pendant un certain temps. Le format de compression le plus adapté pour cette identification d’objets est MPEG-4 [MPEG 2002].

2.2.5. Les documents multimédias

Les documents multimédias numériques contiennent plusieurs types de média diffé-rents (texte, image, son, vidéo). Une vidéo numérique avec sa bande son peut déjà être considérée comme un document numérique multimédia. Il reste néanmoins un document temporel. Les documents multimédias ne sont pas toujours entièrement temporels. Un cédérom éducatif contient du texte, des séquences sonores et des morceaux de vidéo numéri-

7 http://www.microsoft.com/windows/windowsmedia/ , http://www.apple.com/quicktime/ , http://france.real.com/ (2003) 8 National Television System Commitee, standard américain pour la télévision analogique de 1953. Il fonctionne avec 525 lignes/cadre à la fréquence verticale de 60 Hz. Le système auropéen s’appelle Phase Alterning Line (PAL) de début des années 60 avec 625 lignes/cadres mais seulement 25 images/seconde. En France la norme utilisée est le Séquentiel Couleur Avec Mémoire (SECAM) qui diffère de la norme PAL dans la représentation des couleurs.

Etat de l’art

19

ques. Le son et les vidéos restent temporels mais ils constituent seulement une partie du document. Les différents types de média sont rassemblés en suivant des codages variés. Dans le cadre d’une vidéo avec du son, c’est l'encodage qui précise comment le son est syn-chronisé avec la vidéo. Dans le cas des documents hybrides, contenant des parties temporelles et non temporelles, des langages comme le HTML [W3C 2002a] ou SMIL[W3C 2000b] permettent de définir les relations spatiales et temporelles entre les divers médias. Ils permettent également la création d'hyper-documents multimé-dias. Dans un document multimédia les différentes composantes ont leur sens et parfois leur vitesse de lecture. L’ensemble peut avoir un ou plusieurs parcours possibles. La plupart des documents numériques aujourd’hui peuvent être considérés comme documents multimédias. Le numérique rend en effet facile le mélange des médias. Il est très aisé d’inclure des images dans du texte, de mélanger des images, du texte et des vidéos. De plus, les outils pour manipuler les documents numériques ont des in-terfaces combinant plusieurs médias.


20

2.3. Les tâches de manipulation de documents multimédias

Nous avons vu dans le chapitre précédent les différents types de documents numéri-ques. Leurs représentations ainsi que leurs utilisations sont extrêmement variées. Dans ce qui suit nous allons voir que la manipulation des documents numériques reste une tâche nouvelle pour le grand public. Certains travaux [Shneiderman 2002] proposent de regrouper les tâches liées à ces documents dans les catégories suivantes :

- leur récupération –collect information–, - leur mise en relation et distribution –relate, communications–, - leur création et re-création –create, innovation– et - leur distribution –donate, dissemination–.

Ces mêmes tâches peuvent être classées selon qu'elles concernent : - la création des documents, - leur recherche ou - leur réutilisation.

Ces catégories incluent en effet toutes les tâches citées précédemment. D'autres travaux distinguent la tâche de classification des documents et présentent la classification automatique des documents comme un domaine de recherche spécifique [Bolle et al. 1998, Hauptmann et al. 2002a]. Pour notre part, nous considérons cette tâche de classification comme une tâche de description particulière liée à une volonté de classement et qui donc se retrouve naturellement comme sous-tâche de chaque tâ-che listée précédemment – création, recherche ou réutilisation-. Nous allons montrer dans la suite que les différentes tâches liées aux documents nu-mériques sont dépendantes les unes des autres et se déroulent même en général les unes dans le contexte des autres.

2.3.1. Création de documents multimédias

La tâche de création se réfère dans un premier temps à la création initiale : prise de vue avec un appareil numérique, numérisation d'une photo argentique, tournage d'un film, écriture d'un texte. Il s’agit ici de la création primitive. La création d’un docu-ment numérique passe néanmoins souvent par la réutilisation d’autres documents. La créativité dans la création se manifeste conjointement dans les idées et donc les frag-ments originaux et de leur assemblage unique avec des morceaux de documents déjà existants [Auffret et al. 1999]. En ce qui concerne la vidéo, [Chiueh et al. 1998] dé-composent les tâches de création en capture, enregistrement, découpage et montage avec effets. En dehors de ces tâches, mais en étroite relation avec elles, les documents numériques doivent être annotés pour pouvoir être utilisés [Bachimont 1999, Nack et al. 1999, Benitez et al. 2000, Gordon 2000, Soares et al. 2000, Hauptmann et al. 2002a]. En effet il est indispensable de mettre des mots sur les images, créer des ré-sumés pour des textes, décrire les vidéos, les sons et les documents multimédias pour que leur visualisation, recherche, réutilisation soient aisées. La plupart des appareils photo numériques et caméscopes numériques annotent en effet automatiquement les

Etat de l’art

21

images et vidéos produites9. Nous traiterons la question de l'annotation dans la sec-tion 2.4. La tâche de création inclut l'archivage des documents. La façon de stocker les docu-ments est en effet très importante pour leur recherche et leur réutilisation. A cause de leur taille, les bases documentaires peuvent dépasser la capacité d'une seule machine; elles sont réparties sur plusieurs supports physiques. Les accès et les traitements sont alors distribués : les bases sont alimentées par plusieurs personnes et consultées par des utilisateurs étant physiquement éloignés. Ces caractéristiques rendent sensibles les bases documentaires aux stratégies de stockage et d'accès à distance. Il est d'usage aujourd'hui de stocker le contenu (fichier vidéo, image et son) et la structure (infor-mations sur la présentation, annotations, …) séparément [Kaplan 1997, MPEG 2000, Soares et al. 2000, NPTV 2001, Ossenbruggen et al. 2001],[El-Hadidy et al. 1999]. Cela permet par exemple d'adapter la qualité des flux transmis aux débits des réseaux. Il est possible d'utiliser une compression plus forte d'une vidéo ou d'un mor-ceau de musique pour un utilisateur se connectant à partir de son téléphone portable que pour un autre utilisateur consultant le même document sur un ordinateur de bu-reau. Bien sûr, la question de savoir s'il s'agit bien du même document dans les deux cas peut être posée. Les différents composants des documents ayant des supports de stockage distincts, il est important de mettre en place des règles de synchronisation et des règles de présentation : de nombreuses approches et langages ont été présentées pour exprimer ces règles [Thuong 1999, Celentano et al. 2002a, Celentano et al. 2002b, Aupetit et al. 2003],[Adobe 2002, Bes et al. 2002] pour pouvoir les présen-ter aux utilisateurs de manière cohérente.

2.3.2. Recherche dans des documents multimédias

Selon [Kokkoras et al. 2002] lors de la recherche d’information dans des documents numériques il y a trois aspects fondamentaux à prendre en compte : le choix de la re-présentation des documents dans lesquels la recherche se fait, les méthodes de formu-lation de requêtes et une fonction de comparaison qui détermine à quel degré un do-cument répond à la requête. En parlant de recherche dans des documents numériques, la première question à poser porte sur le type de média dans lequel la recherche se fait. En effet la recherche est à traiter différemment si les documents dans lesquels la recherche est faite sont consti-tués de textes, d'images, de vidéos, de sons ou encore de documents multimédias. Dans cette section nous allons évoquer les différentes manières de formuler les requê-tes ainsi que les différents types de résultats que ces requêtes, une fois exécutées sur des bases de documents, peuvent renvoyer.

9 Exchangeable Image File Format, http://www.exif.org/ (2003)


22

Puisque les mots constituent une composante fondamentale de la communication hu-maine, il est naturel de les utiliser pour exprimer des requêtes. Si utiliser des requêtes textuelles pour chercher du texte ne pose pas de problème particulier lié au codage des requêtes, il n'en est pas de même lorsqu'il s'agit de chercher des images, des sons ou des vidéos. Comme évoqué dans la section 2.2, décrire des images, des vidéos, des sons nécessite de franchir le fossé sémantique les séparant des structures textuelles, car leur manipulation passe par des moyens qui relèvent d'une autre structure que la leur. Il est pourtant habituel aujourd'hui d'utiliser des mots pour décrire et chercher des images, sons, vidéos plutôt que de donner des fragments de même type que le do-cument recherché. Il faut donc faire un saut interprétatif pour ramener les requêtes ou les descriptions formulées à l'aide de mots dans un format qui corresponde aux docu-ments. [Frohlich et al. 2002] tracent un bon état de l’art sur la recherche de docu-ments numériques en analysant les besoins d’un système de gestion de photos numé-riques, « photoware », mettant en avant la complexité de la recherche dans ce type de documents. Pour chercher des images sans utiliser des mots clés, plusieurs essais ont été faits : certains systèmes proposent des icônes comme briques de base des requêtes [Imagescape 2001], d'autres permettent de dessiner des esquisses [Imagescape 2001, IBM 2002] pour préciser ce que l'on veut trouver ou encore d'utiliser des images d'exemples pour chercher des images similaires [INRIA 2000, IBM 2002, INRIA 2002]. Là encore les critères de similarité sont très variés et souvent complexes dans le fond et portent souvent les noms des algorithmes mis au point. Il faut donc les « traduire » pour qu'ils deviennent compréhensibles pour le grand public. En effet la similarité peut être calculée sur les formes, les couleurs, les textures, leurs mélanges, appliquée à des régions dans l'image ou non [Bres et al. 1999]. Au-delà du fossé sémantique, les données (images, vidéos, son) peuvent bien sûr être décrites par des descripteurs textuels pour permettre la formulation des requêtes tex-tuelles pour leur recherche. Ces descripteurs peuvent être extraits de manière automa-tique en se basant sur des outils de traitement d'image et de son, ou bien posés à la main [NETRA 2000, Ditto 2002]. Plusieurs techniques de recherche d'images ont été développées. Sur le web existent au-jourd'hui beaucoup de moteurs de recherche qui les implantent. Les méthodes utilisées combinent divers critères de similarité d'images et des mots clés associés manuellement aux images. Ces mots clés peuvent être définis dans une base de données, quant il s'agit d'images stockées elles-mêmes sur un même serveur [Mediasite 2000, NETRA 2000, Imagescape 2001, Ditto 2002, SQUID 2002], ou bien les mots clés peuvent être extraits des pages HTML contenant les images [Amore 1997, Webseek 2002, Altavista 2003]. De cette dernière façon, des index couvrant plusieurs serveurs peuvent être construits, élargissant considérablement l'ensemble d'images concerné. Cette technique d'extrac-tion des mots clés des pages HTML peut s'appliquer aux éléments de tout type de mé-dia (son, vidéo, …) identifiables, contenus dans ces pages. D’un autre coté, les mots clés assignés manuellement sont souvent plus pertinents que ceux extraits automati-quement. Les techniques de similarité se basent sur l’histogramme des couleurs de l’image en-tière ou de régions de l’image, sur la texture, sur les contours, etc. Le choix des images exemple se fait de trois façons différentes :

Etat de l’art

23

- Choix d’une ou plusieurs images dans un ensemble proposé par le système [Amore 1997, INRIA 2000, NETRA 2000, IBM 2002, INRIA 2002]. Certains systèmes permettent une recherche par mot clé pour sélectionner les premières images exemple [Amore 1997, NETRA 2000, Webseek 2002].

- Indication de l'URL de la première image exemple. - L’utilisateur peut faire une esquisse de l’image souhaitée, avec [NETRA 2000,

Imagescape 2001, IBM 2002] ou sans [SQUID 2002] couleurs.

Une fois les premières images exemple données, la recherche se fait le plus souvent en plusieurs passes qui raffinent la requête. Ce raffinement se fait en général en indiquant des exemples positifs et négatifs dans l’ensemble d’images constituant le résultat et s'appelle bouclage de pertinence (La Figure 2 illustre un utilisateur qui spécifie une image requête, le système lui retourne un certain nombre de réponses parmi lesquelles l’utilisateur a la possibilité d’indiquer celles qui sont pertinentes ou non). Si la recher-che se fait également sur des mots clés, il est possible de compléter ou modifier l’ensemble des mots constituant la requête. Dans certains cas le système propose même différents mots à rajouter à la requête [Ditto 2002]. Dans ce dernier système un certain nombre de mots clés sont associés à chaque image, et pour raffiner la recherche, les mots clés les plus fréquents associés aux images résultat, sont proposés pour compléter la requête.

Figure 1 Interface graphique de [Imagescape 2001]

La partie gauche de la Figure 1 présente une interface où l'utilisateur dessine l'image qu'il aimerait trouver. La partie droite de la Figure 1 est l'interface d'un système de re-cherche d'image où l'utilisateur, en partant d'un ensemble d'images sélectionnées par sujet prédéfini, précise à chaque étape les images qu'il juge pertinentes et celles qui ne correspondent pas à ses attentes. [Mulhem et al. 2002] travaillent également sur un sys-tème d'annotation d'images qui combine des descripteurs de type image, sous la forme d'icônes étiquetées, avec des descripteurs textuels organisés en graphes conceptuels [Sowa 2000].


24

Figure 2 Interface graphique de Surfimage [INRIA 2000]

La recherche des documents audiovisuels (vidéos, musiques) se fait actuellement es-sentiellement par des mots clés [Mediasite 2000, Webseek 2002, Altavista 2003]. Ces systèmes mettent à disposition une recherche par mots clés sur le web. Plusieurs outils commerciaux [Mediasite 2000, Virage 2000] permettent l'annotation des vidéos. Plusieurs grands fournisseurs de contenu vidéo (ABCNews10, Metro Goldwyn Mayer11, CNN12, …) les utilisent pour mettre en ligne leurs émissions. Ces outils permettent le découpage semi-automatique de la vidéo en plans, et l’affectation manuelle de mots clés aux plans ainsi délimités. Il s'agit d'extraire des caractéristi-ques textuelles (mots clés) des documents audiovisuels, de les organiser dans des ba-ses de données dans lesquelles la recherche va s'effectuer. La présentation des résul-tats est également essentielle, [Celentano et al. 2002b] propose un langage semblable à SQL permettant la recherche dans des documents multimédias annotés et la mise en forme des résultats spatialement et temporellement cohérents. La recherche porte donc dans ces cas uniquement sur des mots clés. Il existe néanmoins des travaux étudiant la recherche de documents audiovisuels en se basant sur des requêtes non textuelles. [Thuong 1999], [Dagtas et al. 1999] présen-tent des systèmes qui permettent la recherche d'objets dans une vidéo selon leurs rela-tions spatio-temporelles, [Zhong 2000, Ng et al. 2003] ont élaboré des interfaces pour une recherche multimodale, c'est à dire fournissant la possibilité de chercher des documents multimédias, dans une base de journaux télévisés par exemple, selon l'en-droit du reportage, sur une carte du monde. [Hauptmann et al. 2002b] étudient les

10 http://abcnews.go.com/ (2000) 11 http://www.mgm.com/ (2000) 12 http://cgi.cnn.com/cgi-bin/virage (2000)

Etat de l’art

25

manières d'adapter les résultats obtenus dans la recherche d'images, notamment par IBM avec le système QBIC [IBM 2002] pour des vidéos. Pour combler le fossé sé-mantique, différentes stratégies ont été proposées, comme la création d'outils pour dé-finir des métaphores permettant de représenter des caractéristiques numériques [Costabile et al. 1998, Xiong et al. 1999]. Nous pouvons dire que des systèmes de recherche de documents multimédias exis-tent. Néanmoins ils ne sont pas encore très répandus et leurs résultats restent peu convaincants. En effet, les moteurs de recherche d'image, qui sont les plus nombreux, couvrent des bases composées de relativement peu d'objets (moins de 10 000 images). En ce qui concerne les documents audiovisuels, leur annotation automatique est peu pertinente (même la détection automatique des plans dans une vidéo n'est pas garantie à 100%), leur annotation manuelle est longue (il faut les regarder plusieurs fois) et surtout les outils d'annotations existants utilisent tous des formats propriétaires pour sauvegarder les descripteurs choisis, ce qui rend quasi-impossible leur réutilisation. Pour résumer les services passés en vue dans cette section, nous pouvons dire que pour pouvoir être recherchés, les documents multimédias doivent être annotés. L'an-notation de documents audiovisuels se fait manuellement pour des descripteurs de haut niveau d'abstraction (nom des personnages, actions, …) et automatiquement pour en extraire des caractéristiques de bas niveau (histogramme de couleur, découpage en plans, reconnaissance de texte, …). La recherche se fait souvent en combinant les mots clés, des images exemples et des esquisses simples qui peuvent être enrichies par des icônes métaphoriques. A l’image des documents, les requêtes doivent être multimédias. Des méthodes existent pour cacher la complexité mathématique et éviter l'utilisation des dénominations trop scientifiques pour caractériser des images (utilisa-tion d'icônes ou découpage automatique de l'image en régions pour détecter différen-tes textures, dessin de contours, …). Ces interfaces réduisent néanmoins l'expressivité de certaines approches. On contrôle moins finement les critères de recherche. Pour raffiner les requêtes plusieurs méthodes sont à notre disposition : le bouclage de pertinence : en spécifiant à chaque étape les bons et mauvais objets dans la liste d'images résultats, l'association de mots clés, ainsi que la proposition d’autres mots clés en se basant sur des requêtes mémorisées.

2.3.3. Réutilisation de documents multimédias

La réutilisation de documents ou de fragments de documents numériques est le but explicite ou implicite de leur création. La création et la recherche documentaire sont liées par cette finalité de réutilisation alors qu'il s'agit de tâches naturellement sépa-rées. Les documents sont souvent réutilisés pour créer d'autres documents. Les documents sont alors recomposés, partagés, réorganisés [Abiteboul 1999]. Cela peut se faire en recopiant des fragments, en y faisant référence, parfois en changeant le support et en combinant ces tâches. Par exemple une critique d'un film de cinéma peut être illustrée avec des images tirées du document vidéo. Les méthodes de mise en page des documents multimédia sont complexes, ce sujet est étudié dans plusieurs projets [Ossenbruggen et al. 2001, Bes et al. 2002],[Thuong 1999, Lemlouma et al. 2002]. La présentation des résultats est aussi importante que la facilité de construction de re-quêtes. En effet si les réponses à une requête contiennent plusieurs heures de docu-ments audiovisuels il est humainement impossible de tous les regarder/écouter.


26

[Ossenbruggen et al. 2001] définissent la démarche de construction de réponse à des requêtes sur une base de documents multimédias comme suit :

- choisir les morceaux, trouver le contenu, construire la forme, élaborer la struc-ture sémantique de la réponse,

- choisir l'interface de communication sur laquelle le résultat va être présenté, ainsi que la syntaxe de définition de disposition (HTML, SMIL, SVG, ..),

- définir le style de la présentation (comment construire visuellement les élé-ments),

- définir la qualité des différents composants (bande passante pour les vidéos, ré-solution pour les images, compression pour le texte pour une réception opti-male.

Plusieurs systèmes excellent dans la présentation variée des données pour faciliter la recherche, la visualisation des résultats et l'exploration. [Baldonado et al. 2000, Au-petit et al. 2003, LeBlanc et al. 2003] présentent plusieurs méthodes de visualisation de données : arbres hyperboliques, 3D, arbres coniques, calendrier spirale, mur de perspective [Rao et al. 1995], des métaphores visuelles se basant sur les données [Xiong et al. 1999], etc. En utilisant des standards tels que SMIL [W3C 2000b], il est possible d'afficher les annotations superposées à la vidéo. Boreczky et al. [Boreczky et al. 2000] ont travaillé sur la présentation d'un résumé de vidéo sous la forme de bande dessinée affichant des images clés des plans, avec des tailles différen-tes et des annotations superposées. Pour une bonne réutilisation il faut que les documents et les fragments déjà existants soient facilement trouvables, leur présentation soit conviviale et conforme aux requê-tes [Abiteboul 1999, Celentano et al. 2002a]. De plus il faut que les utilisateurs aient des outils et des méthodes pour facilement rassembler et présenter les fragments réutilisés. La manipulation des documents numériques est une tâche complexe. Par leur carac-tère temporel, leur quantité et la richesse de leurs méthodes de présentation les docu-ments numériques requièrent de nouveaux outils, de nouvelles méthodes et habitudes de manipulation. Les systèmes existants ne fournissent pas de solutions complètes. Des méthodes qui permettent une bonne coexistence entre documents, annotations, voir éventuellement des traces de manipulation, une bonne ressemblance avec des do-cuments « classiques » doivent apparaître pour que les utilisateurs humains puissent s'orienter dans les bases documentaires. La création, la recherche et la réutilisation des documents sont des tâches étroitement reliées. La réutilisation suppose une recherche aisée, la recherche est conditionnée par la création et l'archivage des documents. Toutes ces tâches impliquent une sous-tâche de description. Nous avons vu que la création de documents comporte une phase de description, d'annotation avec des mots clés ou des descripteurs plus complexes, pour faciliter la recherche. En effet tout document numérique est matérialisé par un ou plu-sieurs fichiers. En nommant ces fichiers, une première annotation est déjà faite. De plus les systèmes d’exploitation rajoutent des méta-données par défaut telles la date de création, l’utilisateur qui les a créées. Si la manipulation se fait par des interfaces dédiées les méta-données peuvent être bien plus complexes. Le processus de recherche peut lui-même être vu comme une description du document que l'on aimerait trouver et faire appel aux descripteurs déjà posés. La réutilisation passe également par la description de la manière d'identifier les frag-ments à réutiliser ainsi que de la manière de les présenter. Ainsi donc les actions de créer, de rechercher ou de réutiliser s'appuient toujours sur une capacité à décrire les

Etat de l’art

27

contenus impliqués dans la tâche. Toute description étant une annotation des docu-ments, nous allons étudier plus particulièrement ce processus d'annotation.


28

2.4. L’annotation comme méthode de base pour les tâches de création, recherche et réutilisation de documents audiovisuels

Créer des documents, décrire des documents, archiver les documents, présenter les documents, rechercher des documents, réutiliser des documents sont des tâches qui impliquent l'annotation. L'annotation peut consister en une simple description par des mots clés des documents, en passant par l'extraction de fragments, d'images, de mor-ceaux, d'objets clés, jusqu'à la mise en relation des documents. Toute description d'un document se révèle être une annotation alors que bien entendu toute annotation posée sur un document n'est pas obligatoirement une description.

2.4.1. Pourquoi l'annotation ?

L'annotation peut jouer le rôle de résumé, pour des grands documents. Cela est clas-sique pour de longs textes, mais également pour des documents images, sons ou vi-déos, ou des ensembles de documents. Les annotations permettent de cerner les carac-téristiques considérées comme importantes par celui qui annote pour « comprendre » tel ou tel aspect d'un document. Les annotations permettent de classer les documents. En effet, en utilisant un nombre fini de descripteurs, les documents peuvent être regroupés dans des classes ayant des implications sur leur archivage, recherche et réutilisation. Grâce aux annotations, les documents sont plus facilement identifiables. Des requêtes de recherche de documents peuvent se baser uniquement sur les annotations. Pour les images, sons et vidéos l'annotation textuelle permet de ramener des caracté-ristiques binaires à des caractéristiques exprimées par des mots, bien plus proches de la manière de pratiquer des utilisateurs humains et plus simples à manipuler, à recher-cher. Toute manipulation de document génère et utilise des annotations. Le fait de donner un nom au fichier est déjà une annotation. Annoter permet également de commenter, d'ajouter des détails, d'enrichir par des ré-férences, etc., et d'une manière générale de « tenir un discours » complémentaire sur le document. Ce type d'annotation prend une importance croissante dans le cadre de ce qu'il est convenu d’appeler le « Web Sémantique » [Decker et al. 2000].

2.4.2. Comment annoter ?

L'annotation peut se faire de deux manières : automatiquement et manuellement, cha-que méthode pouvant se dérouler selon plusieurs scénarios. L'annotation automatique se base sur des routines de traitement de texte, d'image et du son. Un document peut être annoté par des caractéristiques qui en sont extraites [Bres et al. 1999, Dagtas et al. 1999, Virage 2000, gettyimages 2002, IBM 2002,

Etat de l’art

29

INRIA 2002, Altavista 2003], ou bien en utilisant son contexte [Bradshaw et al. 2000, Google 2003]. Les méthodes d’obtention automatique d’annotations sont notamment :

- l'analyse des documents [IBM 2002, INRIA 2002, Altavista 2003], - l'analyse des sources HTML, des références ou du texte autour des images, sons

et vidéos [Bradshaw et al. 2000, Google 2003], - l'insertion de méta-données de création (appareils numériques (EXIF)), - l'observation des manipulations subies par le document.

Ces différentes méthodes peuvent bien sûr être combinées pour croiser les résultats et ainsi améliorer la pertinence des annotations obtenues [Goodrum 2000]. Pour des documents textuels sur le web, il est possible d'appliquer d'abord une extraction de mots clés contenus dans le document et vérifier ces résultats en traitant les mots clés figurant dans les liens vers le document sur d'autres pages. Pour des documents au-diovisuels les méta-données créées automatiquement peuvent aider dans le choix d'al-gorithmes de traitement d'image ou de son. L'utilisation du contexte des documents pour les décrire n'est pas purement un proces-sus automatique, car ce contexte peut contenir des informations créées par des utilisa-teurs humains. L'annotation manuelle consiste à faire appel à la capacité d'interprétation d'un utilisa-teur pour décrire un document. La plupart des systèmes d'annotation existants aident l'utilisateur en faisant un prétraitement automatique et en sollicitant l'utilisateur hu-main pour valider et compléter les résultats. Pour les vidéos, le découpage en plans se fait en général de manière automatique [Rehatschek et al. 1999, Boreczky et al. 2000, Correia et al. 2000, Virage 2000], et l'annotation manuelle se fait ensuite sur ces plans. L'utilisateur peut aussi avoir la possibilité de définir lui-même les frag-ments à décrire [Rehatschek et al. 1999, Thuong 1999, Soares et al. 2000, Kipp 2002, Lin et al. 2002, Scuturici 2002]. Dans certains systèmes l'utilisateur peut dé-crire avec ses propres termes, d'autres systèmes imposent un vocabulaire contrôlé. L'annotation manuelle se fait en général en désignant le fragment à annoter suivi par la création ou le choix des descripteurs à associer à ces fragments. Quand le fragment est le document entier, l'annotation peut être considérée souvent comme un classe-ment des documents. Des produits comme : Adobe Photoshop Album 1.013 ou encore ACDSee 5.014 permettent par exemple de classer des images numériques en catégories définies par des mots clés et pour ce faire d'attribuer des mots clés à plusieurs images à la fois par de simples glisser-déplacer.

2.4.3. Quoi annoter ?

Dans cette section nous parlons de l'identification des fragments de documents qui se-ront l'objet d'annotation.

13 http://www.adobe.com/products/photoshopalbum/ (2003) 14 http://www.acdsystems.com/English/Products/ACDSee/ (2003)


30

Pour des documents textuels la solution classique est d'identifier un fragment avec les numéros du premier et du dernier caractère. Encore faut-il savoir si l'on représente les caractères sur un ou sur plusieurs octets (Unicode). Cette approche est incompatible avec des documents qui évoluent. Ces standards se basent sur la représentation du do-cument. S'il s'agit d'un document bien structuré, suivant la syntaxe XML[W3C 2002b] par exemple, des outils comme XLink[W3C 2000c], XPointer[W3C 2002c] ou encore XPath[W3C 1999] peuvent être utilisés. Les projets Annotea [Kahan et al. 2001], RDF [W3C 2000a] ou Semantic Web [Decker et al. 2000] utilisent ces struc-tures pour mettre en relation des fragments de documents en ligne et pour permettre d'associer des méta-données aux documents. D'autres projets, comme HyperNews, CritLink, ThirdVoice, utilisent des méthodes propriétaires pour annoter des docu-ments mais ils convergent aujourd'hui vers les standards. Les standards d'identification de fragments existants sont mal adaptés aux documents non balisés, ainsi qu'aux documents qui changent souvent [Brush et al. 2002]. En ef-fet le problème d'ancrage d'annotations à des documents sujets à de fréquentes modi-fications est encore ouvert. Il y a néanmoins des systèmes qui en gérant des versions tentent de pallier ce problème. Nous retrouvons ici, le débat sur la nature d'un docu-ment numérique traité dans la section 2.1. L'identification des fragments de documents audiovisuels passe en général par l'utili-sation de bornes temporelles. L'unité atomique est l'image, ou encore un fragment de durée équivalent à la fréquence d'échantillonnage pour le son. Les fragments tempo-rels peuvent être structurés hiérarchiquement, les unités complexes contenant les uni-tés plus simples [Rehatschek et al. 1999], ou encore en strates [Aguierre-Smith et al. 1992, Prié 1999], structure n'imposant aucune contrainte temporelle entre les fragments. Les fragments ainsi définis peuvent ensuite être identifiés et mis en rela-tion avec des opérateurs sur des intervalles temporels [Allen 1983], [Kumar et al. 1998]. Des méthodes de représentation de documents telles que MPEG4 [MPEG 2002] permettent de ne pas considérer l'image comme l'unité atomique. Grâce à elle un objet ne remplissant pas entièrement l'image peut être identifié. Deux voitures ap-paraissant dans une vidéo peuvent être identifiées en tant que deux objets distincts. Selon [Bachimont 1999], il serait bien de pouvoir identifier une partie quelconque d'un document comme un fragment accessible de manière autonome, et ainsi pouvoir annoter des fragments avec d’autres fragments déjà annotés. Il faut pouvoir identifier un fragment avec toutes ses composantes : une page de texte avec une image et du son ou bien uniquement la partie visuelle d’une vidéo sans le son, ou encore un objet vidéo comme un personnage par exemple, indépendamment de l'arrière-plan [Nack et al. 2001].

2.4.4. Avec quoi annoter ?

Dans cette section nous parlons de différents types d'annotations : textuelles, images, documents multimédias et nous insistons particulièrement sur l'importance des anno-tations textuelles et de leur structuration. Quand on parle de l'annotation, on pense souvent à des mots clés, à des petites phra-ses associées à des fragments de texte. En effet les mots et les phrases sont des anno-tations, plus précisément des annotations textuelles. Ces annotations textuelles peu-vent être créées librement ou bien choisies dans un ensemble prédéfini.

Etat de l’art

31

L'ensemble prédéfini de mots clés, appelé encore vocabulaire d'annotation, réduit le nombre de mots différents qui peuvent caractériser un document permettant ainsi la construction de requêtes plus précises. Des structures de descripteurs textuels ont été mises en place pour annoter des docu-ments non numériques, les ouvrages présents dans une bibliothèque par exemple (le Dublin Core15). Avec l'arrivée des documents numériques et de l'internet, plusieurs langages structurant le vocabulaire de description ont vu le jour. Certains suivent une logique orientée objet (UML, DOM,[Amous et al. 2002]), d'autres permettent de dé-finir des ontologies (OIL, IEEE LOM,…) d'autres encore organisent les termes en graphes (RDF, RDFS[W3C 2000a], HyperProp[Soares et al. 2000], S-IA [Prié 1999]). Les méta-données peuvent servir à décomposer les documents multimédias ou encore à faciliter l'identification de fragments [Amous et al. 2002]. Grâce au numérique, la création d'annotations non textuelles est techniquement très facile. Des images, des sons, des vidéos peuvent être considérés comme annotations et d'une manière générale, tout document ou fragment de document multimédia peut être considéré comme annotation [Bachimont 1999, El-Hadidy et al. 1999, MPEG 2000, Soares et al. 2000]. Par exemple, un film peut annoter un roman et être à son tour annoté par les person-nages. L’index peut être considéré tantôt comme document, tantôt comme un moyen d’accès à son objet, et tout document peut éventuellement servir d’index [Bachimont 1999]. Comme précisé auparavant, les annotations ne jouent pas uniquement le rôle de descripteurs. [Bataille et al. 2002] mettent en place une approche ontologique pour définir l’ensemble des informations relatives aux documents : informations sur le type du document, sur son auteur, sur ses conditions d’usage, sur l’intérêt de sa consultation, sur le contexte dans lequel il peut être employé, sur la sémantique des rapports qu’il entretient avec d’autres documents, etc. L'approche ontologique néan-moins n'est pas une panacée. Le but n’est pas d’avoir un consensus universel, mais de pouvoir découvrir et utiliser plusieurs points de vues, plusieurs ontologies locales. Il faut permettre à chaque utilisateur de créer les articulations entre les différentes onto-logies. Pour cela il faut lui fournir les outils et assistants nécessaires [Bénel et al. 2001]. Dans la pratique la gestion des annotations non textuelles est un problème que le grand public découvre et qui n'est pas encore entré dans les habitudes de tous les jours. Même les annotations textuelles présentent bon nombre de problèmes. Les systèmes de recherche de documents audiovisuels actuellement fonctionnels sur le web ([Amore 1997, Mediasite 2000, NETRA 2000, Virage 2000, Imagescape 2001, Ditto 2002, INRIA 2002, SQUID 2002, Webseek 2002]) attribuent une sim-ple liste de mots clés aux documents audiovisuels pour permettre leur recherche. Ils

15 http://dublincore.org/ (1995-2003)


32

ne prévoient pas notamment des relations entre ces mots clés. Les travaux étudiant la création, structuration et modélisation des descripteurs [Prié 1999, Thuong 1999, Bird et al. 2000, Doorn et al. 2000, Soares et al. 2000] soutiennent par contre que c’est en organisant les descripteurs dans une structure de graphe que des requêtes complexes pourront être posées et satisfaites. Ainsi les services de recherche d’information multimédia deviennent plus riches. [Schreiber et al. 2001a] utilisent des structures hiérarchiques pour annoter des images. Ils étudient les modalités d'in-tégration des structures définies séparément pour trier un vocabulaire. Pour un voca-bulaire ayant une seule structure hiérarchique ils ajoutent des relations tirées de la base de données lexicales WordNet16, pour permettre une navigation selon de nou-veaux contextes. Les images, textes, vidéos, mis en relation forment des documents multimédias, qui à leur tour peuvent être mis en relation pour former d’autres documents multimédias. Les annotations peuvent contenir des méthodes de visualisation (SMIL [W3C 2000b]), des indices pour des algorithmes de recherche ou bien des descripteurs per-mettant la création de sommaires non temporels pour les documents audiovisuels, comme un ensemble d'image clés d'une vidéo par exemple [Correia et al. 2000]. Disposant d'un format suffisamment générique pour stocker les annotations, on peut les réorganiser, créer des vues optimisées pour des exploitations précises et spécifi-ques. Cela doit se faire néanmoins de manière à garder toujours les annotations réor-ganisées en relation avec celles à partir desquelles elles ont été extraites, pour pou-voir les tenir à jour facilement. Même si les annotations peuvent être constituées de n'importe quel fragment de do-cument, pratiquement elles sont souvent uniquement textuelles, organisées en arbres hiérarchiques, classes, graphes ou encore sans structure. Même lorsque d'autres mé-dias peuvent être utilisés pour annoter, c'est souvent à l'aide de mots clés textuels qu'ils seront manipulés. Les annotations textuelles peuvent être directement inclues dans des images, comme avec EXIF, ou RDFPic [Lafon et al. 2002]. Actuellement, les méthodes de représentation d'annotations issues de XML, comme MPEG-7 constituent les tendances fortes.

16 http://www.cogsci.princeton.edu/~wn/index.shtml (2003)

Etat de l’art

33

2.5. Travaux apparentés dans l’annotation de documents

Dans ce chapitre nous présentons des travaux qui se rapprochent particulièrement à nos objectifs d’annotation et de recherche de documents multimédias. Dans leur modèle d’annotation de vidéos, [Rehatschek et al. 1999] définissent deux catégories d’annotations : celles avec une sémantique basique fixe (concernant la structure temporelle hiérarchique d’une vidéo : plan, séquence, scène,…) et celles avec une sémantique dynamique (annotations de plus haut niveau d’abstraction posées sur les unités définies par les annotations structurelles). L’unité temporelle atomique est la partie de vidéo : un fragment matérialisé par un time-code, pouvant se résumer à une seule image. Les parties sont contenues temporellement dans des séquences, qui sont des fragments continus dans le temps. Une séquence peut contenir des par-ties ou d’autres séquences. L’unité discontinue dans le temps est appelée groupe. Un groupe est formé de parties et de séquences.

Figure 3 Structure logique d'un film

Toute unité définie ci-dessus (part, séquence, groupe) peut être annotée par des mots clés (Figure 3) définis dans des documents appelés : styles d’annotation. Ces styles d'annotations sont des définitions des thesauri, ainsi que des attributs et leur types, associés aux termes. Lors de l’annotation l’utilisateur peut donc choisir le style selon lequel il annote. Un point original du modèle est la différentiation des instances de différentes qualités d’une même vidéo. En fait toutes les annotations annotent en même temps plusieurs fichiers représentant la même vidéo en différents formats. Le modèle prévoit l’annotation par le réseau, il autorise donc à télécharger une version de taille (et donc de qualité) faible pour l’analyse, mais attribue les mêmes annota-tions aux versions plus détaillées restants sur le serveur. Lors de la recherche


34

l’utilisateur peut demander la visualisation d’un fragment de haute qualité, trouvé à l’aide des annotations posées sur la version « allégée » de la même vidéo. [Correia et al. 2000] élaborent un modèle d'annotation (AntV : Annotations in Vi-deo) afin de faciliter ce qu'ils appellent la visualisation active des vidéos, c'est à dire la réflexion active et critique pendant la visualisation d’une vidéo. Le système permet aux utilisateurs d'annoter les vidéos qu'ils regardent et de partager leurs annotations. Des annotations de type texte, images, vidéo et liens ont des dimensions spatiales et temporelles, c'est à dire qu’ils ont une certaine durée de vie sur l'axe de temps de la vidéo et une position spatiale sur le flux.

Figure 4 L'annotation et la visualisation dans le système AntV

Lors de la visualisation d'une vidéo avec les annotations celles-ci sont intégrées au flux (Figure 4). Les annotations sont stockées dans des fichiers appartenant à un utili-sateur, appelés collection d'annotations (Annotation Set). Les utilisateurs peuvent choisir les collections qui devront être combinées avec la vidéo. Cette intégration se fait à l'aide de SMIL17. L'originalité de ce modèle est la gestion des annotations: ca-pacité de les partager et d'en choisir plusieurs pour une visualisation simultanée. Le fait d'autoriser plusieurs médias pour l'annotation (texte, images, …) est également un point fort. [Doorn et al. 2000] définissent deux types de descripteurs (images+texte) : des Lo-gogens (un thesaurus textuel) et des Imagens (un thesaurus d'images). Une image est considérée comme un document, et les différentes régions de l'image sont assimilées à des concepts utilisés dans ce document. L'image est découpée en régions, ces ré-gions sont ensuite analysées selon différentes méthodes de traitement d'image et des

17 Synchronized Multimedia Integration Language <http://www.w3.org/AudioVideo/>

Etat de l’art

35

descripteurs numériques en sont extraits sous forme de vecteurs de réels. Ces descrip-teurs numériques sont assimilés à des mots du document décrivant des concepts. Une région peut être également décrite, manuellement par des mots clés. De cette fa-çon une image sera caractérisée par ces régions, décrites à l'aide de :

- l'imagette représentant la région ; - l'ensemble de descripteurs numériques, sous la forme de couples <méthode

d'analyse, vecteur de valeurs caractéristiques> ; - l'ensemble de mots clés affectés manuellement.

Par exemple un fragment d'image représentant un bout de champ, annoté par les mots clés : herbe, champ, plantes aura un vecteur caractéristique représentant son histo-gramme de couleur, un autre représentant des caractéristiques de texture selon une méthode d'analyse donnée. Cette représentation permet de cacher les descripteurs numériques, complexes pour les utilisateurs, derrière des fragments d'image et des mots clés. L'utilisateur formule sa requête à l'aide des fragments d'images. Le système les ana-lyse, en extrait les vecteurs caractéristiques, et effectue la recherche en les comparant aux vecteurs caractéristiques des images dans la base de données. Il propose ensuite des résultats et affiche également les mots clés associés aux vecteurs trouvés pour raf-finer la requête. Cette même méthode permet également d'enrichir la base d'images en facilitant une association cohérente des mots clés aux nouveaux fragments d'images introduits dans la base. Les données sont sauvegardées dans un SGBD relationnel, à l'aide d'une couche orientée objet. L'intérêt de cette représentation est dans sa façon d'aborder les requêtes sur les ima-ges. Elle présente une méthode intuitive et multimodale pour résoudre le problème complexe de construction des requêtes basées sur le contenu des images. Smart VideoText développé dans [Kokkoras et al. 2002] est un système d’annotation de vidéos, basé sur des graphes conceptuels [Sowa 2000]. Les termes et les fragments de vidéo forment les nœuds d’un graphe conceptuel. Les fragments sont identifiés par les numéros d’images, les annotations sont des termes libres. Ne traite pas l’utilisation collective. La similarité est basée sur des méthodes de traitement de la langue naturelle combinées avec une comparaison des relations dans le graphe conceptuel. Les requêtes sont aussi des graphes conceptuels. Pour la recherche des réponses à des requêtes le système utilise des connaissances du domaine, des connais-sances de l’application et des connaissances de système. Dans le modèle HyperProp [Soares et al. 2000] présentent une structure de représen-tation de documents hypermédias sous forme d’un hyper-graphe. Le modèle sert à la création et la présentation de documents. Il ne traite pas l’annotation dans un but de recherche ni la recherche dans les documents. Les nœuds de l’hyper-graphe représen-tent les fragments du document, les utilisateurs ainsi que différents événements liés aux fragments. Les nœuds représentant des fragments de documents peuvent contenir ou faire référence à d’autres nœuds de même type. Les relations de référence permet-tent de définir des parcours guidés au sein du document. Le modèle permet également de tracer l’historique d’un document en gardant les différentes versions des objets. Bien que HyperProp entre dans le cadre de modèles pour la présentation de docu-ments multimédias, l’idée de représentation en graphe est intéressante ainsi que l’inclusion de l’utilisateur dans ce même graphe.


36

L’Organisation Internationale de Standardisation (ISO) travaille sur une norme (MPEG7 [MPEG 2000]) qui définit un standard pour la description du contenu mul-timédia, appelé aussi Interface de description du contenu multimédia. Cette norme dé-finit un langage basé sur XML pour décrire les descripteurs, organisant ceux-ci dans des graphes. MPEG7 s’adresse à différentes applications et environnements. Elle doit donc fournir un cadre de description de données audiovisuelles flexible et extensible. Pour cette raison MPEG7 ne définit pas un système rigide d’annotation mais plutôt un ensemble de méthodes et outils pour les différentes phases de la description des documents multimédias. Le standard inclut :

- les Descripteurs MPEG7 (D): une représentation des caractéristiques du contenu multimédia. Un descripteur définit la syntaxe et la sémantique de la représen-tation d’une caractéristique ;

- les Schémas de description MPEG7 (SD): un SD spécifie la structure et la sé-mantique des relations entre ses composants, qui peuvent être aussi bien des Descripteurs MPEG7, que des Schémas de description MPEG7 ;

- un Langage de définition des descripteurs (DDL) : c’est un langage qui permet la création de nouveaux SD et D. Il permet également l’extension et la modifi-cation des SD existants. La syntaxe du DDL est basée sur XML, elle répond ainsi aux contraintes d’extensibilité, de pouvoir d’expression et de portabilité ;

- différentes façons de coder ces descriptions. La Figure 5 présente les principes d'une chaîne de traitement utilisant le standard MPEG 7. Cette chaîne inclut une extraction des caractéristiques (analyse), une phase de description (normalisée), et l’application qui exploite cette description (un moteur de recherche par exemple). La norme porte sur l'organisation des descripteurs.

MPEG 7

Extraction des caractéristiques Description Application

Figure 5 Chaîne de traitement vidéo avec Mpeg-7

Le DDL est un composant de base de MPEG7. Il fournit une base solide de descrip-tion à l’aide de laquelle les utilisateurs pourront créer leurs propres Schémas de Des-cription et Descripteurs. En effet, il définit les règles syntaxiques pour exprimer, mo-difier et combiner les Schémas de Description et les Descripteurs. Ainsi, les documents audiovisuels seront décrits par des descripteurs qui seront orga-nisés selon des Schémas de Description et représentés à l’aide d’un langage basé sur XML (DDL). Depuis le premier appel aux propositions MPEG7 (octobre 1998) le DDL a été fortement influencé par le langage des schémas XML de W3C [W3C 2000d, W3C 2000e, W3C 2000f] et par RDF [W3C 2000a]. L’ensemble des annota-tions avec les documents audiovisuels et les relations entre-eux forment des graphes. Ces graphes, ou des parties de ces graphes, peuvent s’interpréter comme des docu-ments multimédias. Les propos sémantiques de MPEG7 tentent de structurer les descripteurs des docu-ments audiovisuels. Ses descripteurs, décrivant le contenu des documents seront or-ganisés dans des ensembles structurés. MPEG7 propose un jeu d’outils et formalismes pour décrire, pour exprimer la sémantique portée par le contenu des documents au-diovisuels. Les principaux outils de description sont les différents schémas de des-

Etat de l’art

37

cription (SD) : le SD Sémantique, le SD des Entités Sémantiques (SemanticEntity DS), le SD des Aspects Sémantiques (SemanticFeature DS) et les relations sémanti-ques.

Semantic DS

SemanticEntity DS

AVContent captures

Narrative World

Object DS

Event DS

Abstract DS

Properties DS

SemanticState DS

SemanticTime DS

PersonObject DS

ObjectLocation DSUsageLabel DS

represents

SemanticRelation

…

Figure 6 :Relations entre différents outils de description sémantiques

Le SD Sémantique est les outils principaux, il permet de représenter le monde présen-té par le contenu audiovisuel (images, segments de vidéo) comme un ensemble d’entités sémantiques mises en relation. Ces relations sont illustrées sur la Figure 6. Les autres Schémas de Description (Entité, Aspect) ainsi que les relations font donc partie de la SD Sémantique, ils sont des SD spécialisés. Le SD Entité représente les entités qui existent ou se passent dans le monde narratif (entités percevables) ainsi que les abstractions, les attributs et interprétations de ces entités. Objets, personnes, localisations, événements, propriétés, concepts, états et le temps sont des types d’entités sémantiques (Figure 7).


38

Object DS Event DS Abstract DS

Properties DS

SemanticState DS SemanticTime DS

PersonObject DS

LocationObject DS

state change

time location

harmony

Narrative World

musician

interpretation, no perceivable

abstraction,non-perceivable

representsrepresents

represents

represents

interpretation, perceivable

Figure 7 :Relations entre différents SD sémantiques spécialisés et exemples d’entités sémantiques.

Le SD Aspect Sémantique permet la représentation de différents traits des entités sé-mantiques tels que : - le SD Occurrence Média (MediaOccurence DS) qui est en fait le lien des descrip-

teurs aux fichiers audiovisuels binaires, il décrit l’apparition d’une entité sémanti-que dans le média, ou

- le SD « Usage Label » spécifiant le niveau d’abstraction d’un ensemble d’entités. Les relations sémantiques sont introduites pour représenter les relations, autres que stricte hiérarchiques entre différents éléments des SD. Ainsi on peut différencier : - des relations génériques (comme sorte de, similaire, état de, exemple de, …), - des relations entre objets (comme partie de, membre de, matière première de, …), - des relations entre objets et événements (comme agent de, stimulus de, source

de,…), - des relations temps, événements (temps de), - des relations événement, événement (comme sommaire de, manière de, …) et - des relations entre segments et sémantiques (comme Symbole média de, Percep-

tion média de). Nous pouvons dire que la norme MPEG7, quand il sera largement utilisée, facilitera considérablement la manipulation des documents audiovisuels et rendra plus efficace et utilisable à plus grande échelle la recherche dans ces documents.

Etat de l’art

39

Au début de nos travaux, le standard MPEG-7 n’était pas encore sorti. Nous avons néanmoins suivi son évolution et essayé de rendre nos modèles compatibles avec ce standard. Les systèmes présentés ici, illustrent différentes manières d’aborder l’annotation de documents audiovisuels. Ils couvrent plusieurs méthodes de création automatique d’annotations : analyse d’image, fouille de texte, combinaison des deux. L’organisation de descripteurs varie de la structure figée de [Doorn et al. 2000], en passant par une organisation différée en hiérarchie temporelle figée et annotations stockés dynamiquement de [Rehatschek et al. 1999] pour arriver à des structures ba-sées sur des graphes laissant un grande liberté d’organisation des descripteurs [Prié 1999, Thuong 1999, Correia et al. 2000, Soares et al. 2000, Saddik et al. 2001]. La tendance de l’organisation des descripteurs montre une émergence des structures en graphe. Elles permettent en effet de représenter des annotations très interconnec-tées tout en gardant un cadre formel et bien exploitable mathématiquement. Nous avons pu constater que la tâche d’annotation et de recherche étant subjective et les systèmes étant multi-utilisateurs, il fallait gérer des profils d’utilisateur. Ainsi nous pouvons suivre les préférences de chacun, tout en fournissant des méthodes de mise en commun et de partage des points de vues, des méthodes de description, des structures d’annotations et des annotations elles-mêmes. Les théories de création, d’organisation et d’exploitation d’annotations de documents audiovisuels sont en pleine évolution. La démocratisation accélérée de ces documents aident à l’établissement d’usages et la cristallisation des exigences et méthodes.


40

2.6. L’assistance aux tâches liées à l’exploitation des documents audiovisuels

Dans cette partie nous passons en revue quelques théories et systèmes d’assistance à l’utilisateur dans sa tâche d’exploitation des documents numériques. Aujourd’hui nous sommes loin des aides de quelques lignes, expliquant les paramè-tres à mettre après une instruction dans la ligne de commande. Ces systèmes d’aide, si nous pouvons les appeler ainsi, étaient assez bien adaptés et efficaces pour des tâches très simples. Les tâches des systèmes, aussi bien que celles de l’utilisateur, ont évolué et peuvent être parfois extrêmement complexes. L’aide à l’utilisateur doit donc devenir de son côté plus performant.

2.6.1. Critères de classification

Les systèmes d’aide à l’utilisateur peuvent se caractériser selon de nombreux critères. Selker [Selker 1994] propose de séparer les systèmes d’aide en systèmes de type conseiller et systèmes de type assistant. Un système d’aide de type conseiller, donne des informations, propose des solutions mais n’intervient pas directement dans le travail de l’utilisateur. La plupart des sys-tèmes d’aide des logiciels sous Windows sont de ce type. Nous pouvons les consulter, ils nous conseillent parfois des solutions, comme le compagnon MS Office, sans mo-difier les documents sur lesquels nous travaillons. Les systèmes de type assistant font à notre place les tâches répétitives. C’est le cas typique des macros ou des aides fondées sur la prédiction des actions (compléter au-tomatiquement des mots clés, adresses, listes de paramètres, etc.). Selker [Selker 1994] et Lieberman [Lieberman 1997] distinguent des systèmes d’aide conversants et autonomes. Les systèmes d’aide conversants attendent nos questions, c’est le cas des aides traditionnelles. Nous parcourons ces aides chapitre par chapitre, lançons des recherches par mots clés ou nous posons des questions. Les systèmes autonomes fonctionnent en parallèle avec l’utilisateur et lui proposent de l’aide sans qu’il ait à faire appel à eux. Un autre critère de classification des systèmes d’aide est la capacité de s’enrichir [Lieberman et al. 1996],[Trousse et al. 1999]. Certains systèmes évoluent en effet en cours de leur utilisation. D’autres [Francisco-Revilla et al. 2000] s’adaptent cer-tes aux différentes situations par exemple en présentant l’aide selon différentes vues suivant la situation, mais leur savoir ne s’enrichit pas. L’enrichissement peut s’effectuer de manière manuelle ou automatique. En effet cer-tains environnements suivent les actions de l’utilisateur et les réponses du système pour apprendre les habitudes de l’utilisateur et adapter l’aide proposée [Selker 1994, Lieberman 1995, Jaczynski et al. 1998, Farrell et al. 2000]. D’autres systèmes permettent à l’utilisateur d’intervenir dans son processus d’apprentissage et le guider en précisant ses préférences [Lieberman 1993]. Une autre méthode d’enrichissement qui peut être manuelle ou semi-automatique est la possibilité de créer des macros [Lieberman et al. 1996, Macromedia 1999, Ruvini et al. 2000]. Des macros peu-

Etat de l’art

41

vent être créés en programmant, en réutilisant l’historique [Macromedia 1999, Der-thick et al. 2000] ou à l’aide d’enregistreurs de macros [Lieberman 1993, Pfister et al., Ruvini et al. 2000]. L’« apprentissage » de l’assistance peut exploiter des profils d’utilisateur [Trousse et al. 1999], des profils de situations (métaphore des salles) [Pfister et al. 1999], com-biner les deux, accumuler l’expérience d’un seul [Lieberman 1995] ou plusieurs [Jaczynski et al. 1998] utilisateurs. Ainsi l’assistance peut être adaptée selon le type d’utilisateur et de situation. Les systèmes peuvent employer différentes techniques de fouille de données pour calculer leurs recommandations [Trousse et al. 1999] : statistiques, raisonnement à partir de cas ou catégorisation des données. La tâche de manipulation des documents multimédias est très complexe et subjective, les critères de description et de recherche sont souvent flous, très variables et diffici-les à formuler, l’aide doit donc pouvoir s’adapter le plus possible à la situation et à l’utilisateur.

2.6.2. Illustration de différents systèmes d’aide

Dans cette section nous présentons quelques systèmes « intelligents » d’aide afin d’avoir une vue des méthodes utilisées par les systèmes d’aide pour s’adapter et ap-prendre. Nous essayerons de faire émerger des directives de conception pour un sys-tème intelligent d’aide à la manipulation des documents numériques multimédias. Le premier système est un système d’aide pour médecins. Le système MMA (Mars Medical Assistant) [Francisco-Revilla et al. 2000] est un « assistant » pour aider des médecins à accomplir une tâche médicale en fournissant l’information et les suggestions appropriées. Pour cela il modélise

- la situation, - l’utilisateur - la tâche.

Les informations et les suggestions sont regroupées dans des composants d’information caractérisés par leur type sémantique (description, exemple ou explication) et le type du média (image, son, texte, vidéo, etc.) Il essaye de donner des réponses aux questions suivantes :

- initier un dialogue ou attendre l’utilisateur ? - quelle interface présenter ? - quelles informations présenter ? - comment (quel type de média et dans quel ordre) ? - quelle quantité d’information montrer à la fois ?

Les conflits générés par des situations et préférences contradictoires sont gérés par un système à base de règles. Ce qui est intéressant dans ce système est la combinaison des modèles des tâches, d’utilisateurs et de situations ainsi que la catégorisation des décisions à prendre. Coach [Selker 1994] est un système qui enseigne la programmation. Ils essayent de comprendre au mieux le but de l’utilisateur, pour cela il construit des stéréotypes d’utilisateurs (de débutant à expert) qui complètent le modèle d’utilisateur basé sur des réseaux sémantiques. Il modélise également les choses à apprendre en leur attri-buant des caractéristiques comme le nombre de fois qu’on a fait appel à eux (expe-rience), le temps écoulé depuis leur dernière utilisation (latency), une mesure de per-


42

formances de l’utilisateur par rapport à cette chose à apprendre (goodness) ainsi que la variation de cette mesure (slope). Il conclut que les suggestions d’un système d’aide sont efficaces si l’utilisateur est peu familier avec la tâche, elles deviennent par contre perturbatrices si l’utilisateur a une expérience dans l’exécution d’une tâ-che. Nous présentons dans ce qui suit deux systèmes d’aide à la navigation sur le Web. Letizia [Lieberman 1995], élaboré au MIT est un système d’aide à la navigation sur Internet qui se base sur l’observation passive des actions de l’utilisateur en analysant le contenu des pages qu’il visite et en mesurant le temps passé sur ces pages. Il fonc-tionne en parallèle avec le navigateur de Netscape. C’ est un agent de type conseiller, autonome. En effet, les propositions de liens intéressants sont présentées continuel-lement dans une fenêtre séparée. En fonction du temps passé sur la page, et du nom-bre de passages, il extrait des mots clés et les sauvegarde dans une base de données en leur donnant une pondération. Il analyse les liens présents sur la page actuelle, té-lécharge les pages pointées, extrait les mots clés et vérifie s’ils sont présents dans la base de données. Pour proposer à l’utilisateur l’étape suivant, il trie les liens de la page actuelle en fonction du nombre de mots clés correspondants à ces liens dans les pages pointées. Letizia suit les principes suivants : suggérer plutôt que d’agir, il analyse les actions de l’utilisateur sans lui demander de donner des explications, il profite des pauses de l’utilisateur pour travailler et élaborer ses propositions. Pour la « mémorisation » des actions, Letizia se base sur un modèle de tâche de l’utilisateur. En fait toutes les ac-tions possibles avec le navigateur (suivre un lien, lancer une recherche, revenir, …) sont modélisées en prenant en compte à chaque fois le temps écoulé entre deux ac-tions successives. Broadway [Jaczynski et al. 1998] a les mêmes buts que Letizia, c’est à dire aider l’utilisateur à naviguer sur le Web. Il est basé sur le raisonnement à partir de cas (RàPC). Il suit un groupe d’utilisateurs et construit une base de cas à partir de leurs actions. Dans la structure d’un cas il prend en compte le chemin effectué par l’utilisateur ainsi que le temps. Pour calculer la similitude des cas il prend en compte l’adresse de la page, son contenu et des contraintes temporelles. Il travaille de façon semi-autonome. Il fait appel à l’utilisateur dans la phase de révision des cas, pour permettre leur apprentissage. Concrètement l’utilisateur doit indiquer s’il a atteint son but en visualisant une page, pour signaler la fin du cas courant. L’effort demandé n’est pas excessif, le tout étant facilité par une interface intuitive et simple à utiliser. Tandis que Letizia trie les liens de la page actuelle, Broadway recherche des cas de situations similaires dans sa base de cas et peut proposer des liens qui ne sont pas sur la page actuelle. Les systèmes suivants aident l’utilisateur en apprenant ses tâches répétitives à l’aide de la méthode de programmation par démonstration (Programming by Demonstartion) Mondrian [Lieberman 1993] est un éditeur graphique qui peut apprendre de nouvel-les opérations sur des objets graphiques par démonstration. Il utilise des métaphores pour manipuler des objets graphiques. C’est un système qui nécessite un apprentis-sage. L’utilisateur illustre une nouvelle opération sur un exemple concret, à l’aide d’une application interactive, qui enregistre ses actions. Cela fonctionne comme un enregistreur de macros. Un algorithme d’apprentissage généralise les séquences d’actions pour qu’ils puissent s’appliquer à d’autres cas. En fait chaque séquence

Etat de l’art

43

d’actions s’applique à un ensemble d’objets, qui constituent les paramètres d’entrée pour la nouvelle opération. Une fois généralisée, la suite d’actions peut s’appliquer à un autre ensemble d’objets (de même type). L’utilisateur peut intervenir dans ces pro-cessus de généralisation, pour contrôler l’interprétation de ses actions. La nouvelle opération prendra en entrée un objet, et construira par rapport à cet objet les autres objets en appliquant les opérations. APE (Adaptive Programming Environnement) [Ruvini et al. 2000] est un assistant de programmation qui apprend les tâches répétitives des utilisateurs. APE combine la programmation par démonstration et les LIA (Learning Interface Agents). Il codifie les actions dans des traces par des lettres pour faciliter le repérage des séquences ré-pétitives. Il doit être entraîné. En appliquant des méthodes statistiques sur les traces d’utilisation il détecte des tâches répétitives et apprend les habitudes de l’utilisateur. Il est autonome et de type conseiller. Le système Visage [Derthick et al. 2000] est centré sur la visualisation de données, dans des contextes temporels. Il permet de créer des arbres avec les états d’une appli-cation, en représentant les actions de faire/défaire sous la forme de branches. De cette façon aucune action ou état n’est écrasé dans l’historique, ce qui permet la re-mise du système dans un contexte passé tout en gardant les contextes créés aupara-vant. Chaque branche de l’arbre représentant l’historique est un scénario différent. L’arbre peut être projeté sur une échelle temporelle, permettant de mesurer la durée de chaque scénario. De cette façon on peut comparer les différents états finaux et comparer aussi les chemins d’actions qui mènent à eux. Il décrit certains scénarios qui peuvent être créés en recombinant différentes branches de l’arbre de l’historique. Visage présente une multitude de vues différentes sur une même base de données, et son système de gestion, combinant des vues contenant le temps et/ou l’espace et dif-férentes métaphores visuelles représentant les données. Trouver des métaphores vi-suelles adaptées pour représenter des données ou objets abstraits est un problème qui se situe entre la limite de la science et des arts. L’utilisation de ces métaphores peut simplifier considérablement la compréhension de structures complexes, facilite l’émergence des connaissances et favorise la créativité [Costabile et al. 1998]. Le dernier système que nous présentons, Task Critic [Farrell et al. 2000] est un assis-tant générique basé sur des modèles de tâches et applications. L’utilisateur doit sélec-tionner une tâche à accomplir parmi celles définies. Le système observe les actions de l’utilisateur et affiche des remarques si ces actions ne suivent pas le modèle prévu. Les tâches sont représentées sous la forme d’arbres, la racine contenant la tâche com-plète et à chaque niveau des sous-tâches séquentielles de plus en plus simples. Dès que l’action effectuée par l’utilisateur ne s’encadre plus dans un quelconque modèle de tâche, le système le signale. Task Critic travaille néanmoins de façon autonome. Ce système évite aux utilisateurs novices de « s’égarer » dans les menus et instruc-tions de l’application.

2.6.3. Synthèse

Dans cette section nous avons présenté des systèmes intelligents qui s’adaptent à l’utilisateur pour l’aider soit dans la réalisation des tâches répétitives, soit dans sa re-cherche d’information. Les systèmes d’aide cités, comme introduit dans la section 2.6.1 Critères de classifi-cation, se classent dans les catégories suivantes :


44

Assistant Conseiller Conversant Autonome Apprenant automatiquement Apprenant manuellement Modélise l’utilisateur (construit un profil) Ne modélise pas l’utilisateur

Bien que certains de ses systèmes ne s’appliquent pas directement aux documents au-diovisuels ou multimédias, en les étudiant nous avons pu dégager quelques directives de conception valables en général pour des systèmes d’aide intelligents pour la mani-pulation des documents numériques multimédias :

- Pour pouvoir s’adapter, il est conseillé de modéliser les tâches, les utilisateurs, voire même les contextes (situations) et les applications de telle façon qu’ils puissent être manipulés aussi bien par le système que par les utilisateurs.

- Il faut, si possible, concevoir des modèles de tâche (modèles d’utilisation) suf-fisamment génériques pour permettre de faire émerger de nouvelles façons d’utiliser .

- Si le système garde l’historique des opérations, son modèle doit être de préfé-rence arborescent et nous pouvons prévoir d’utiliser cet historique pour générer des macros, en rendant génériques (quand cela est possible) les suites d’opérations.

- Dans la plupart des cas il est avantageux de combiner des systèmes d’aide de type assistant et de type conseiller, qui agissent néanmoins sans interrompre l’utilisateur dans son travail.

- Quand c’est possible il faut profiter des pauses de l’utilisateur pour faire tra-vailler des assistants, donc créer des systèmes autonomes.

- Les systèmes d’aide doivent apprendre vite, donner des réponses rapides et in-telligibles.

- S’il s’agit d’un système qui apprend, il faut envisager l’apprentissage automa-tique combiné avec l’instruction et interventions de l’utilisateur.

- Pour permettre à l’utilisateur d’intervenir dans le processus d’apprentissage, celui-ci doit être représenté sous une forme lisible par l’homme.

- Il faut adapter le média, le type (exemple, explication, etc.) et la quantité de l’information mise à la disposition de l’utilisateur.

Etat de l’art

45

2.7. L’assistance à l'annotation et à la recherche

La recherche de documents est une tâche complexe qui comporte un certain nombre d'étapes (projet AIM-FIRE de IBM18) :

- stocker et annoter les documents, - implanter une méthode de recherche, - formuler la requête, - analyser les résultats - éventuellement raffiner la requête.

L'assistance à la recherche de documents peut concerner une ou plusieurs de ces éta-pes. L'aide peut porter sur deux types de problèmes : l'utilisation des systèmes, c'est à dire fournir de l'aide sur le « comment faire quelque chose ? » ou encore elle peut porter sur les questions de type « quoi faire ? ». Dans le premier cas, il s'agit de fournir des instructions sur l'utilisation des applica-tions ; dans le deuxième, l'aide porte sur le contenu des interactions homme machine. Par exemple, lors de la création d'une requête l’aide peut concerner le choix de mots clés, lors de l'annotation des documents, des assistants peuvent aider au choix des schémas de description par exemple. L'assistance à la rédaction d'un document est un cas typique d'aide sur le contenu. Pour fournir de l'aide sur le contenu il est important de tracer l'usage du système. En effet, montrer à des utilisateurs des usages similaires aux leurs peut s'avérer utile. Pour tracer les usages il faut modéliser les traces laissées par les utilisateurs lors de l’utilisation d’une application. Plusieurs travaux étudient la modélisation de traces : [Rossi et al. 2000] mettent en place un modèle orienté objet pour la construction des portails web afin de faciliter leur réutilisation. Ils distinguent le model conceptuel (au sens modèle objets/relation d’une base de données par exemple) du système qui alimente la page et le modèle de navigation qui contient les feuilles de style et les liens associés à des requêtes sur la base de données. Ces deux modèles servent à suivre la navigation sur un portail web (exemple choisi dans l’article : www.amazon.com) pour faire émerger des patrons de navigation afin de rendre réutilisables certains éléments de conception de portail. Le modèle orienté objet est utilisé également par [Güell et al. 2000] pour modéliser cette fois les interactions lors de l'utilisation d'un navigateur sur internet pour explo-rer une base de données. Des requêtes et attributs de présentation sont associés aux différentes étapes de navigation. [Derthick et al. 2000] créent des arbres avec les états de l’application, représentant les actions de faire/défaire pour pouvoir se remettre dans un contexte passé. L’état de l’application est caractérisé par un ensemble d’objets et les transitions entre état par des opérations qui manipulent ces objets. Chaque branche de l'arbre est un scénario

18 http://www.almaden.ibm.com/cs/user/aimfire/ (2001)


46

différent. Ils ordonnent cet arbre selon une échelle temporelle, permettant de mesurer la durée de chaque scénario. De cette façon les différents états finaux et les chemins d’actions qui mènent à eux sont comparables. Ils permettent d'associer l’historique de leur utilisation aux différents objets. [Soares et al. 2000] décrivent le modèle Hyper-Prop, qui permet également de tracer la manipulation d'objets et organise les traces en graphes. Des techniques de la programmation par démonstration sont également utilisés pour modéliser des traces d'utilisation [Ruvini et al. 2000]. [Chiueh et al. 1998], dans leurs travaux sur le système de création de documents multimédia Zodiac, proposent des modèles séparés pour l'utilisateur, l'utilisation et les tâches. Les tâches d'utilisation d'une application peuvent être représentées grâce à des arbres les découpant en sous-tâches [Chandrasekaran et al. 1998], [Schreiber et al. 2001a]. [Hlavacs et al. 1999], s'inspirent également des arbres de tâches en suivant les ac-tions de l'utilisateur à différents niveaux d'abstraction. Des systèmes tel que ITER [Kumar et al. 1998] ou Envisage [Nowell et al. 1996, Wang et al. 2002] étudient diverses interfaces basées sur le temps et sur des icônes graphiques pour représenter des résultats de recherche, fournissant ainsi de l'assis-tance pour l'analyse des résultats. La recherche de documents peut être encore assistée par des méthodes d'adaptation de requêtes, par des médiateurs automatiques. [Calado et al. 2002] présentent un sys-tème qui à partir d'une liste de mots clés, génère des requêtes structurées pour plu-sieurs moteurs de recherche. Il joue le rôle de méta moteur de recherche qui rassem-ble et trie les résultats avant de les présenter à l'utilisateur. Le raffinement des requêtes peut se baser sur des systèmes de recommandations, des systèmes de suggestion, des systèmes d'estimation ou encore des systèmes de com-mentaires ou de filtrage collaboratif (CF), comme énumérés dans [Schafer et al. 2002]. Nous avons vu que l'assistance à l'annotation et à la recherche de documents est un domaine complexe, qui s'inspire de quasiment toutes les branches de l'informatique. L'aide peut parfois être prévue à l'avance, en utilisant les connaissances du domaine. Cela donne de bons résultats lors des situations nécessitant peu de créativité : l'utilisation d'une interface graphique, l'exécution des tâches bien formalisées et permettant peu de degrés de liberté. D'autre part, dans des situations où l'utilisateur a davantage de libertés ou où l'inter-face est moins « déterministe » et les actions permises complexes, les contextes po-tentiels posant des problèmes sont bien moins faciles à prévoir. Dans ces cas l'aide ne peut pas être totalement prévue à l'avance, c'est à dire lors de la conception du sys-tème. Ici on a besoin de modéliser l'utilisation du système (actions, objets, utilisa-teurs,…) afin de pouvoir tracer l'utilisation et utiliser les informations ainsi recueil-lies pour donner des conseils ou fournir de l'aide à l'utilisateur. Dans la suite nous allons présenter ces deux types de systèmes d'aide : des systèmes structurés à l'avance se basant sur les connaissances du domaine et des systèmes cons-truisant leurs réponses au cas par cas en se basant sur des expériences acquises.

Etat de l’art

47

2.7.1. Assistance structurée (ontologie) :

Dans la section précédente nous avons introduit l'assistance à l'annotation et à la re-cherche de documents. Une des méthodes consiste à définir a priori des situations dans lesquelles de l'assistance peut être nécessaire. Cette définition consiste à modéli-ser les situations, donc à identifier les composantes qui jouent un rôle dans l'utilisa-tion du système et établir les relations qu'elles entretiennent. Nous pouvons regarder cette activité comme une activité de construction et de gestion d'une ontologie. En effet, pour la modélisation d'une application on peut créer des modèles pour les objets manipulés, pour les tâches qui les manipulent, pour les utili-sateurs. Les tâches ou les opérations effectuées sur les objets peuvent être considérées comme des événements, des transitions. On peut choisir de regarder l'évolution du système du point de vue des objets (cycle de vie des objets), du point de vue des opé-rations (suite d'événements) ou encore du point de vue de l'utilisateur (profil utilisa-teur et sessions d'utilisation). Dés lors que nous voulons modéliser des situations il faut se mettre d’accord sur les points de vues que nous aurons, sur les termes employés et sur leurs interprétations et relations. Nous abordons donc un problème d’ontologie. Les ontologies sont aujourd’hui présentées comme la panacée en informatique. Que ce soit dans les domaines des systèmes d’information, de l’informatique documen-taire, du génie logiciel ou de l’ingénierie des connaissances, ce sont elles qui, nous dit-on, vont régler les problèmes d’interopérabilité, de recherche d’information, de réutilisation et de structuration. De quoi s’agit-il ? De la récupération d’un concept philosophique : l’Ontologie, étude métaphysique de l’Etre ou, d’un point de vue plus pratique, structure a priori de ce qui existe. La légitimité de cet emprunt paraît telle-ment évidente que lorsqu’il y a discussion, celle-ci porte uniquement sur des aspects connexes comme les questions de coût [Menzies 1999]. Pourtant l’Ontologie, autant en informatique qu’en philosophie, fait figure « d’Arlésienne » [Bénel et al. 2001]. On connaît, certes, une multitude « d’ontologies locales » (si l’on peut dire), contradictoires entre elles et peu ou pas réutilisables [Charlet et al. 1996, Charlet 2003]. On connaît, également, des projets téméraires afin de trouver « La Grande Ontologie » (« top-level ontology» [Guarino 1997]) : des caté-gories d’Aristote à Ontolingua [Gruber 1993a] en passant par les catégories de Peirce. Cependant leur catalogue pléthorique [Lehmann 1994] ne peut nous empêcher, étant donné la qualité indéniable du travail de ces philosophes, logiciens ou informaticiens, de nous interroger sur la justesse des présupposés de l’approche ontologique elle même. Certains objecteront qu’il ne faut pas confondre l’Ontologie et ses aspects mé-taphysiques avec les ontologies qui seraient plus limitées et plus appliquées. Selon [Charlet 2003] l’Ontologie, comme science, produit des ensembles, les ontologies. Mais, comme nous le verrons, utiliser ne serait-ce que le terme « d’ontologie », c’est admettre son principe de connaissance a priori du réel. Toute communauté met en place un vocabulaire, un jargon commun qui est tiré du modèle de leur domaine. La communication au sein de cette communauté ou disci-pline se fait en conformité avec ce vocabulaire, définissant un thesaurus caractéristi-que. Le modèle du domaine définit le vocabulaire ainsi que la signification et les rela-tions qui unissent les termes. Le fait que choisir un mot clé et construire une requête soient des tâches de recherche de documents est une telle relation. On nomme sou-vent ces modèles : ontologies. Comme nous l’avons introduit dans les paragraphes


48

précédents, le terme n’est pas tout à fait exact, mais le mot ontologie est bien entré dans les mœurs comme : ensemble de termes, reconnus comme existants dans le do-maine [Charlet et al. 1996]. Ce sont ces termes du thesaurus qui sont souvent con-fondus avec les concepts qui constituent une ontologie. Une ontologie est d’ailleurs définie également comme spécification explicite et formelle d’une conceptualisation partagée (An ontology is a formal, explicit specification of a shared conceptualisation [Gruber 1993b]). La conceptualisation se rapporte à un modèle abstrait d'un certain phénomène du monde réel, et identifie les concepts appropriés de ce phénomène. Explicite veut dire que le type de concepts employés ainsi que les contraintes sur leur utilisation sont ex-plicitement définis. Formel se rapporte au fait que l'ontologie devrait être compréhen-sible par une machine. En pratique différents degrés de formalisation sont possibles. Les grandes thesaurus comme WordNet19, ou MESH [NLM 2003] fournissent un vo-cabulaire de plus de 100.000 termes expliqués en langage naturel, alors que d’autres comme la bibliothèque d’ontologies à Stanford [Gruber et al. 1994], le SUMO (Sug-gested Upper Merged Ontology) créé par le groupe Standard Upper Ontology de l’IEEE20 ou le système CYC21 fournissent des théories axiomatiques formelles pour plusieurs aspects de connaissance de sens commun. Des langages formelles de des-cription d’ontologies comme RDFS [W3C 2000a] ou OWL [Dean et al. 2003] s’imposent dans le cadre d’une nouvelle branche des études autour de l’interopérabilité et le web, appelé Web Semantique. Partagé reflète la notion qu'une ontologie capture la connaissance consensuelle, c’est à dire, ne se limite pas à un certain individu, mais est acceptée par un groupe. Fon-damentalement, le rôle des ontologies est de faciliter la construction d'un modèle de domaine. Une ontologie, au sens systèmes d’informations, fournit un vocabulaire, des termes et les relations pour modéliser le domaine. Puisque les ontologies visent la connaissance consensuelle du domaine, leur développement est souvent un processus coopératif faisant participer plusieurs personnes. En effet, pour communiquer il faut un système de signes avec un sens commun aux partenaires. Dans la vie courante il y a la langue comme base, et la culture de chaque individu comme raffinement. Dans l’informatique plusieurs formalismes tentent de définir et de décrire des ontologies afin de pouvoir effectuer des recherches, à réutili-ser, à créer des interfaces ou des protocoles de communication [Gomez-Perez 1999, Menzies 1999, W3C 2000a, Wache et al. 2001, Charlet 2003, Dean et al. 2003]. Il est extrêmement difficile de structurer un vocabulaire, de créer des ontologies de façon unique. Toujours selon [Menzies 1999], même dans des domaines bien définis (médecine, zoologie), les experts sont rarement d’accord en ce qui concerne les con-cepts bien établis de leur domaine. Que dire alors d’un modèle interdisciplinaire, d’une ontologie globale ?

19 http://www.cogsci.princeton.edu/~wn/ (Consulté le 13.07.2003) 20 http://suo.ieee.org/ (Consulté le 15.09.2003) 21 http://www.cyc.com/ ( Consulté le 13.07.2003)

Etat de l’art

49

Les ontologies posent des problèmes non résolus de nos jours, mais on ne peut pas s’en passer. Un individu dans le cadre d’une tâche donnée utilise une ontologie. Pour que deux individus puissent communiquer il faut que leurs ontologies se recouvrent suffisamment pour que la compréhension soit assurée. En communiquant les indivi-dus adaptent leur vision, leur interprétation du monde, ils agrandissent ainsi la partie commune de leurs ontologies locales. Ils commencent par découvrir, comprendre, apprendre, adapter, et finalement réutiliser des ontologies [Gomez-Perez 1999]. Ces tâches sont très complexes et difficilement réalisables. Dans le cadre de l’informatique, du point de vue formel, il y a plusieurs problèmes :

- plusieurs formalismes plus ou moins adaptés pour représenter des ontologies (Graphes Conceptuels, RDF, XML, [Charlet et al. 1996, Guarino 1997, Mitra et al. 2000, W3C 2000a, Wache et al. 2001, Gupta et al. 2002], … )

- pas de standards bien établis pour caractériser des ontologies du point de vue de l’utilisateur [Gomez-Perez 1999],

- le degré de détail des descriptions est divers. Les travaux liés aux ontologies ont néanmoins beaucoup fait avancer les modèles de représentation de structures de termes ayant un impact sur les modèles de tâches de l’utilisateur, des traces d’utilisation. La tendance actuelle est la représentation sous forme de graphes en partant des idées de [Farrell et al. 2000, Soares et al. 2000, Sowa 2000, Jing et al. 2002] mais dans le format OWL et RDFS imposés par les tra-vaux autour du Web Semantique22. Nous avons présenté ces questions liées aux ontologies pour souligner les difficultés de mettre en place un vocabulaire commun pour un groupe de personnes pour modéli-ser des tâches complexes. Tant qu'il s'agit de problèmes bien définis avec des solu-tions uniques, les modèles a priori peuvent être suffisamment simples pour pouvoir être utilisés et fournir de l'assistance à la résolution de ces problèmes [Chandrasekaran et al. 1998]. Si la question est : sur lequel des trois ou quatre bou-tons d'une interface graphique appuyer pour sauvegarder un document, un modèle qui définit les rôles de chaque bouton peut permettre de donner une réponse. Si par contre il s'agit d'aider le choix d'un mot clé pour une requête sur un ensemble de documents, les informations concernant les méta-données, les relations entre les éléments de ces documents constituent des structures trop complexes pour être utilisables. Dans ces cas il faut employer d'autres techniques.

2.7.2. Assistance au cas par cas (analogie)

Dans des situations où les utilisateurs se posent la question : « que faire ? » les sys-tèmes d’aide « classiques » sont impuissants. L’utilisateur peut très bien maîtriser l’outil mais manquer d’inspiration ou de connaissances sur le sujet de son travail. De

22 http://www.semanticweb.org/ (Consulté le 14.09.2003 ) , http://www.w3.org/2001/sw/ (Consulté le 14.09.2003)


50

plus, la tâche réelle de l'utilisateur est rarement identique à celle proposée par le sys-tème [Kanellos et al. 2000]. Une telle situation peut être par exemple apparaître lors de l’utilisation d’un traitement de texte pour la rédaction d’un CV, où l’utilisateur peut se poser des questions sur les informations à mettre dans le document. Un autre exemple est l’annotation de documents audiovisuels : la question peut porter sur le choix de mot clés qui correspondent mieux à ce que l’utilisateur ressent lors de la vi-sualisation du document. Dans ces cas, des systèmes qui cherchent à aider l’utilisateur en retrouvant des situa-tions passées similaires peuvent se révéler très utiles. Pour pouvoir retrouver des situations d’utilisation d’un logiciel de manière automati-que il faut modéliser ces situations. Une fois les situations modélisées, il faut mettre en place des méthodes de comparaison pour retrouver celle qui ressemble le plus à la situation actuelle de l’utilisateur qui demande de l’aide. Plusieurs théories traitent le problème en commençant par les cadres (frames) de Marvin Minsky [Minsky 1975], en passant par les scripts de Roger Shank [Shank et al. 1984] pour arriver aux théo-ries de raisonnement à partir de cas (case based reasoning) de [Aamodt et al. 1994, Mille 1998]. Les bases du raisonnement à partir de cas (noté RàPC) sont posées depuis la fin des années 70 avec la prise de conscience en psychologie cognitive de l’importance rela-tive de la mémoire épisodique par rapport à la mémoire sémantique, c’est à dire des connaissances contextualisées, sous forme de souvenirs ou d’expériences, par rapport aux connaissances générales et abstraites, sous forme de concepts ou règles [Champin 2002]. Le raisonnement à partir de cas est une approche de résolution de problèmes basée sur la réutilisation par analogie d'expériences passées appelées cas. Un cas est généralement indexé pour permettre de le retrouver suivant certaines ca-ractéristiques pertinentes et discriminantes, appelées indices; ces indices déterminent dans quelle situation (ou contexte) un cas peut être de nouveau réutilisé. Le raisonnement à partir de cas se décompose habituellement en cinq phases principa-les [Aamodt et al. 1994, Napoli et al. 1997] :

1. Phase d’élaboration de cas lors de laquelle le problème courant est formalisé en cas source

2. phase de recherche, dont le but est de rechercher des cas ayant des similarités (i.e. des indices similaires) avec le problème courant,

3. phase d’adaptation, permettant de construire une solution au problème courant en se basant sur les cas identifiés dans la phase précédente,

4. phase de révision de la solution qui permet de l'affiner grâce à un processus d'évaluation,

5. phase d'apprentissage, chargée de mettre à jour les éléments du raisonnement en prenant en compte l'expérience qui vient d'être réalisée et qui pourra ainsi être utilisée pour les raisonnements futurs.

Etat de l’art

51

Problème Nouveaucas

Casretrouvé

Cas etsolution

Casadapté

Casappris

élaborer retrouver

apparier

adapter

réviser

Base de caset

théorie dudomaine

apprendre

Figure 8 Le cycle de raisonnement à partir de cas selon [Aamodt et al. 1994, Napoli et al. 1997]

La Figure 8 présente le cycle classique de raisonnement à partir de cas en partant du problème réel qui donne lieu à un nouveau cas source, en passant par les étapes suc-cessives jusqu’à la proposition d’une solution basée sur un cas retrouvé et adapté et l’apprentissage du nouveau cas et de sa solution. Les expériences passées sont stockées dans des structures appelées cas. Un cas C est, le plus souvent, constitué de la description d'un problème, pb(C), et de la solu-tion à ce problème, sol(C). On notera C=(pb(C),sol(C)). Les cas sont stockés dans une base de cas. Les cas de la base de cas sont des cas réso-lus appelés cas sources, notés source, avec source=(pb(source),sol(source)). Un nouveau problème donne naissance à un cas à résoudre appelé cas cible, noté cible, tel que ci-ble=(pb(cible),sol(cible)), avec sol(cible) inconnue. Le RàPC peut alors être modélisé comme illustré sur la Figure 61, inspirée du diagramme connu sous le nom de carré d'analogie.

Pb(cible)Pb(source)

sol(source) sol(cible)

appariement

transfert

source cible

Pb(cible)Pb(source)

sol(source) sol(cible)

appariement

transfert

source cible

Figure 9: Réutilisation d’un cas par analogie

La première étape contient l’élaboration du cas source, c’est-à-dire la transformation du problème à résoudre en un cas comportant une partie source et une partie cible. La seconde étape, appelée étape de remémoration consiste à rechercher dans base-de-cas un cas source tel que pb(source) soit similaire à pb(cible). Ceci est réali-


52

sé grâce à un appariement des descriptions de problème cible et source. La troisième étape consiste à réutiliser la solution du cas remémoré pour trouver la solution du cas cible. Comme pb(cible) et pb(source) ne sont que similaires (et non identi-ques)23, la solution remémorée, sol(source), devra être adaptée, pour résoudre cible. Les deux principales phases du raisonnement à partir de cas sont donc la re-mémoration et l'adaptation. Outre les cas, contenant la connaissance épisodique, le RàPC exploite la connaissance du domaine représentée sous forme ontologique et sous forme de contraintes intrinsèques au domaine. L'ensemble constitue la base de connaissances [Mille 1998]. Plusieurs systèmes utilisent le raisonnement à partir de cas pour assister à l’utilisation de logiciels. Le système Broadway, assiste l’utilisateur dans sa navigation sur internet [Trousse et al. 1999, Trousse 2000]. Le système Letizia [Lieberman 1995] propose également un modèle d’observation pour assister la navigation sur internet. Tandis que Letizia trie les liens de la page actuelle fait une recherche de similarité dans une base de données comportant d’autres liens, Broadway recherche des cas de situations similaires dans sa base de cas et peut proposer des liens qui ne sont pas sur la page en consultation. Cette approche est intéressante pour aider l’exploration des documents et des descripteurs qui sont représentés comme un réseau d’annotations. [Takano et al. 2000] proposent un modèle de cas contenant uniquement les procédu-res exécutées par l’utilisateur. Ils mettent en place un modèle de tâches qui permet de capitaliser et de retrouver la suite de procédures qui ont été lancées pour obtenir un certain résultat. Les cas sont composés de listes de procédures lancées par les menus de l’interface graphique ainsi que les documents (images) résultant de ces procédures. La recherche de cas similaires se base sur des critères de similarité entre procédures accessibles par les menus définis a priori. Ils appliquent leurs résultats sur l’aide à l’utilisation de la suite graphique Adobe Photoshop24. Le système présenté par [Auriol et al. 1999] utilise deux approche pour construire des cas. Dans un premier temps des cas sont construits a priori en se basant sur les connaissances du domaine, ici le dépannage de robots, ensuite, lors de l’utilisation du système, d’autres cas sont mémorisés en observant les actions de l’utilisateur. L’aide est fourni sur le choix des documents à présenter pour une panne de robot donner à un utilisateur non expert afin qu’il puisse intervenir et effectuer la maintenance lui-même. Le raisonnement à partir de cas est une approche qui permet de fournir de l’assistance dans des cas nécessitant de la créativité et des connaissances spécifiques non prévues a priori. La mise en place de systèmes d’aide basés sur cette technique nécessite néan-moins une modélisation du système qui s’inspire aussi bien du domaine des ontologies que celui des modèles de tâches et modèles d’utilisateur. Il est important de bien forma-liser les cas, de trouver les bonnes méthodes et modèles pour enrichir la base de cas et finalement les fonctions de comparaison et d’adaptation sont à définir de manière adé-

23 Dans le cas où pb(cible) et pb(source) sont identiques, la réutilisation consiste en une simple copie de sol(source). 24 http://www.adobe.com (2003)

Etat de l’art

53

quate. Pour les modèles de cas il faut trouver un bon compromis entre richesse d’informations sur le contexte et la situation donnée et la complexité de la comparaison et de l’adaptation.

2.7.3. Assistance mixte

Dans les sections précédentes nous avons vu que pour assister l’utilisateur dans ses tâches complexes, il faut mettre en place des environnements qui exploitent plusieurs techniques d’aide : les systèmes définis a priori, qui proposent le plus souvent de l’aide pour l’utilisation d’un outil informatique et qui répondent à des questions de type « comment faire quelque chose ? ». D’autres systèmes mettent en place des mo-dèles pour pouvoir tracer les actions de l’utilisateur afin de pouvoir assister des tâ-ches plus complexes émanant des situations où l’utilisateur se pose la question « quoi faire ? ». En effet, rares sont les systèmes d’aide qui ne se servent que d’une seule méthode. La plupart définissent au moins des classes de problèmes a priori et à l’intérieur de ces classes appliquent l’assistance au cas par cas. Déjà, la modélisation des cas peut être considérée comme une définition a priori. La communauté du raisonnement à partir de cas s’inspire à la fois de l’ingénierie des connaissances et des modèles de tâches développés par celui-ci [Chandrasekaran et al. 1998, Farrell et al. 2000], des lin-guistes et des structures ontologiques développés par eux [Gomes et al. 2002] et d’autres branches de l’informatique. En effet, [Gomes et al. 2002] combinent des techniques du raisonnement à partir de cas et les relations ontologiques entre termes présents dans WordNet pour fournir de l’aide pour la conception de logiciels. [Smyth et al. 2001] définissent des hiérarchies de cas, créant des classes abstraites de cas permettant de créer, de retrouver et d’adapter des cas multiples à des niveaux d’abstraction plus ou moins élevés. [Hayes et al. 2002] modélisent le contexte d’un utilisateur qui écoute de la musique sur in-ternet et utilisent le raisonnement à partir de cas et le filtrage collaboratif pour com-poser un programme de radio personnalisé. Il est important de bien adapter l’aide fourni aux utilisateurs potentiels. Les systèmes d’aide doivent pouvoir s’adapter dans une certaine mesure de manière autonome à un utilisateur donné. En général nous pouvons dire qu’il faut prévoir le plus de situations possibles dès la conception d’un logiciel et en même temps mettre en place un modèle de capitalisation de l’expérience qui fournit au système une souplesse adaptée aux be-soins des utilisateurs.


54

2.8. La nécessité d’un modèle prenant en compte les usages pour une assistance "en contexte" exploitant l'analogie de situations

Lors des tâches subjectives, telles l’annotation et la recherche de documents, la prévi-sion a priori des problèmes qui peuvent surgir est complexe. En effet, mise à part l’utilisation du système et des interfaces graphiques, les questions lors de l’annotation et la recherche de documents portent sur l’emplois des annotations, la manière d’exprimer un souhait, construire et raffiner une requête. Chaque individu, par sa culture, a une approche différente. Les systèmes de description de documents propo-sent une multitude de structures d’annotations, par des mots clés, d’imagettes, du son, de fragments de documents, etc. comme présenté dans la section 2.4. Dans ces cas ce qui peut être utile est de montrer aux utilisateurs les résultats et les démarches d’autres utilisateurs ou leur rappeler leurs propres gestes passées. Il est donc néces-saire de créer des modèles qui prennent en compte les usages du système et qui modé-lisent aussi bien l’utilisateur, que les tâches et les objets du système. Les modèles et systèmes présentés dans ce chapitre couvrent par morceaux ces as-pects. Les modèles d’annotation de document fournissent des structures en arbores-cence ou en graphes qui sont assez riches pour représenter la complexité des façons de voir des documents. D’autres systèmes élaborent des interfaces qui s’adaptent à l’utilisateur et les modèles d’utilisateur et du domaine sur lesquels cette adaptation se repose. La capitalisation par traçage de l’expérience de l’utilisateur est également un sujet en plein essor. D’après nos connaissances, il n’y a pas eu dans la littérature des travaux qui proposent de modéliser en un même structure l’ensemble d’éléments en-trant en jeu lors de l’utilisation de l’ordinateur pour manipuler des documents, c’est à dire les utilisateurs, les documents et les fonctionnalités des logiciels. Le système HyperProp [Soares et al. 2000] ou Zodiac [Chiueh et al. 1998] modélise certes les tâches et les objets, ils ne mettent pas par contre en place un système d’aide au cas par cas. Les systèmes de raisonnement à partir de cas se concentrent en général sur des aspects précis, et n’incluent dans leurs cas à la fois les utilisateurs, les tâches et le objets manipulés.

E-SIA

55

3. Contribution : E-SIA E-SIA est le modèle de départ de nos recherches. Ce chapitre lui est consacré. Nous présen-tons dans un premier temps nos motivations à utiliser un graphe pour structurer les documents et les annotations. Nous présentons le modèle d’origine : Strates-IA, nous enchaînons avec la présentation en détailles du modèle étendu suivi de la description formelle des différents élé-ments. Dans ce chapitre, nous étudierons les modalités de description de données audiovi-suelles. En effet, comme nous l'avons illustré, l'organisation et l'exploitation de ces descripteurs sont fondamentales pour la recherche dans ce type de données. Il est éga-lement important de proposer des méthodes simples aux utilisateurs, qui exploitent les documents annotés, de découvrir la manière dont ceux-ci ont été annotés, afin de pouvoir mieux cibler leurs requêtes. Ils arriveront ainsi à de bons résultats en moins d’étapes et donc en moins de temps. Nous présenterons également différentes méthodes de recherche multimédia. Nous proposerons une formalisation de la tâche de manipulation de document multimédia en général. Cette formalisation est très importante, car la recherche de documents multimédias se révèle une tâche complexe. Il est en effet difficile de décrire ce qu'on aimerait trouver. A partir, par exemple d'une image, d'une mélodie, d'un dialogue qu'il a en tête, l'utilisateur voudrait retrouver le fragment de vidéo qui les contient. Pour faire comprendre au système son souhait, celui-ci doit proposer des interfaces de création de requêtes riches, multi-modales, personnalisables. En effet ce n’est pas la même chose de taper des mots clés dans un champ d’édition, de donner des descrip-teurs numériques, de dessiner une esquisse ou bien de siffler une mélodie dans un mi-crophone pour construire une requête. Il est utile également, dans ce cas, de savoir comment les documents dans lesquels la recherche s'effectue ont été annotés et com-ment ces annotations sont organisées. Si l’utilisateur connaît la manière dont l’annotation a été réalisée, il peut plus facilement poser des requêtes pertinentes. Aussi bien la recherche, que l'annotation passent par un processus de description. Dans le premier cas nous décrivons ce que nous aimerions trouver, dans le second la description porte sur ce que nous observons. Il est important que la description des documents audiovisuels soit homogène. Dans le cadre d’une émission sportive par exemple, si les participants à une course cycliste sont désignés parfois par les mots clés : Cyclistes, Concurrents ou encore Concurrents, il serait beaucoup plus compli-qué de formuler une requête retrouvant toutes leurs occurrences que s’ils étaient iden-tifiés toujours par le même mot clé. Les tâches de recherche et d'annotation sont complexes. La complexité de ces tâches provient de la très grande variabilité potentielle des points de vues aussi bien pour décrire initialement (à l’archivage) que pour décrire par la suite (pour une recherche, une analyse,…). Les descripteurs sont potentiellement infinis ce qui rend extrême-ment difficile pour un utilisateur d’être cohérent et homogène avec d’autres annota-


56

tions. Il est donc pertinent de mettre en place des assistants informatiques qui facili-tent les tâches de recherche et d’annotation et contribuent au bon déroulement des in-teractions homme-machine. Comme pour toute tâche complexe, une assistance peut considérablement accélérer l'atteinte de bons résultats. Ces résultats s’obtiennent sou-vent comme l’aboutissement d’une série d’interactions entre l’utilisateur et le sys-tème. Pour résumer la problématique : nous voulons enrichir les services de recherche et d’accès à l’information multimédia. Pour cela nous étudierons les méthodes de des-cription et d'exploitation de ces informations ainsi que l'assistance aux utilisateurs pour effectuer cette exploitation et description. Après un exemple introductif, nous évoquerons les travaux à l’origine de nos modèles (Strates-IA) pour présenter notre modèle de description de documents (E-SIA), ainsi que notre modèle d’observation d’utilisation du système et réutilisation de l’expérience (Trèfle). Le modèle E-SIA se propose de définir une syntaxe de représentation et un cadre sé-mantique pour les descripteurs. En extension du modèle E-SIA, nous avons mis en place le modèle Trèfle qui permet de représenter les actions de l’utilisateur. Autre-ment dit : le modèle formalise l'interaction entre les générateurs (documentalistes ou outils d’indexation automatique) et les utilisateurs des descripteurs de documents. En plus des descripteurs, le modèle permet de représenter, de sauvegarder et de réutiliser les actions de l'utilisateur à l'aide d'une même syntaxe. Les documents, leurs descrip-tions et les actions qui ont mené à la mise en place des descripteurs se fondent donc dans un seul capital d'expérience qui peut être valorisé pour faciliter les futurs mani-pulations (annotation, recherche, visualisation) de documents.

E-SIA

57

3.1. Un exemple introductif

Nous rappelons que l'objectif est d'étudier et de développer des outils permettant d’enrichir les services de recherche et d’accès à l’information multimédia. Il s'agit d'élaborer un système qui permette à l'utilisateur d'exprimer facilement et précisément sa requête, un système qui trouve rapidement des résultats pertinents, propose des moyens pour raffiner la requête et qui mette à disposition plusieurs méthodes de vi-sualisation des résultats. Imaginons par exemple un réalisateur d'émissions de télévision qui voudrait faire une rétrospective des chutes de Virenque lors de ses différentes courses cyclistes. Il veut donc retrouver tous les fragments vidéo contenant ces chutes. Supposons que les ar-chives de la chaîne de télévision soient numériques et qu'il existe un système de re-cherche dans ces archives. Pour effectuer sa recherche il peut se baser sur des mots clés : vélo, Virenque, etc. et sur des images exemples : un cycliste quelconque, un cy-cliste qui tombe, le portrait de Virenque, etc. Eventuellement il peut préciser le type d'émission dans lequel la recherche doit être menée (d'émissions de sport ou journaux télévisés dans notre cas). Après avoir effectué une première recherche par mots clés, le système lui retourne une centaine de vidéos, qui se révèlent être des extraits repré-sentant les principales courses cyclistes (Tour de France, Tour d’Espagne, les grandes classiques, …) couvertes par la chaîne, ainsi que les interviews accordées par Viren-que. Sur la lecture de la description associée à une séquence du Tour de France, il note que le mot clé course est assigné. Il re-formule alors sa requête en y rajoutant ce mot clé pour éliminer les interviews. Comme l'ensemble des résultats est encore trop volumineux (représente une centaine d'heures à regarder), il raffine sa requête en la précisant avec une image exemple. Cette image représente un cycliste qui tombe et réduit l'ensemble des vidéos trouvées à des séquences qui contiennent des images si-milaires à celle donnée comme exemple. Le nombre de résultats se réduit à une ving-taine, parmi lesquels certaines séquences se résument à des images, mais d'autres sont encore beaucoup trop longues. En dernière étape il précise que parmi les résultats ain-si trouvés il lui faut seulement les plans d'une durée inférieure à 15s. Lors de ses recherches le réalisateur d’émission a utilisé ses connaissances du do-maine des courses cyclistes pour préciser les premiers éléments de sa requête. Il s’est servi ensuite des possibilités offertes par le système et du caractère des résultats in-termédiaires pour raffiner sa demande jusqu’à ce qu’il aboutisse à un résultat utilisa-ble. Dans notre exemple l’utilisateur construit sa requête à partir des mots clés et des ima-ges exemples. Les mots clés sont pertinents si effectivement lors de l'archivage, les séquences au-diovisuelles ont été annotées par ces mêmes mots. Encore faut-il que les mots clés dé-signent des séquences pertinentes et limités à ce qui est recherché et non par exemple la vidéo entière, car ce serait trop imprécis et nécessiterait trop de temps pour effecti-vement localiser la bonne séquence. Il est important donc que les annotations soient


58

précises, bien organisées, homogènes et que le directeur d'émission puisse trouver fa-cilement les mots clés qui correspondent à sa requête. En ce qui concerne la recherche par image exemple : elle est lourde, les critères de similarité (valeurs numériques et noms techniques de méthodes de comparaison sur les textures, couleurs, contours) sont peu compréhensibles pour les utilisateurs et les résultats ne sont pas toujours pertinents. Dû à la lourdeur des calculs nous ne pouvons pas effectuer une recherche par image exemple en temps réel, à moins d'avoir des descripteurs pré-calculés des images (ce qui est d’ailleurs souvent le cas) pour accélé-rer les comparaisons. Au moment de l’annotation on peut effectuer une série de trai-tements sur les images extraites des documents pour avoir des signatures numériques plus concises, et au moment de la recherche effectuer ces mêmes calculs uniquement sur l’image exemple et comparer ensuite ses signatures à celles déjà calculées aupa-ravant. Dans notre illustration, si le réalisateur d'émission avait la possibilité de donner en même temps que l'image exemple, les mots clés, et préciser qu'il veut des plans de durées courtes, cela lui aurait économisé du temps. Le système aurait d'ailleurs pu classer les résultats automatiquement en cyclistes qui roulent et interviews en propo-sant des raffinements de requêtes pour les départager. Les services proposés par le système pouvaient être plus riches.

E-SIA

59

3.2. Modèle de description de documents (Strates-IA)

Le modèle Strates-IA fournit une représentation des documents et de leurs fragments annotés. Il inclut également la représentation des annotations elles-mêmes, ainsi qu’une formalisation d’outils destinés à contrôler et organiser les descripteurs et à documenter la manière d’annoter. Après l’introduction du modèle de description, nous décrivons les outils d’exploitation et de manipulation de ces descripteurs que nous avons mis en place. Pour clore le chapitre nous allons décrire la couche du modèle représentant les traces des actions de l’utilisateur lors de ses tâches d’annotation et de recherche de docu-ments. En se basant sur ce modèle de traces nous allons proposer des méthodes pour capitaliser et réutiliser son expérience. Le modèle présenté ici (E-SIA: Strates Interconnectées par les Annotations Etendues) se base sur celui proposé par Yannick Prié [Prié 1999] (Strates-IA) dans sa thèse. Le modèle Strates-IA permet d’offrir une couche intermédiaire entre les méthodes de traitement d'image, l’annotation manuelle et les applications qui exploitent les résul-tats de ces opérations (Figure 10). Autrement dit : le modèle formalise l'interaction entre les générateurs et les utilisateurs des descripteurs de documents. Strates-IA dé-finit un modèle d’annotation des documents par des termes, ces termes peuvent être reliés pour exprimer des contextes. Les fragments des documents, les annotations et le vocabulaire utilisé pur annoter forment un graphe. Dans sa thèse, Y. Prié introduit également des notions théoriques pour organiser et contraindre l’annotation.

Traitement d'image

Traitement de son

Indexeur humain

Autres outilsd'analyse documentaire

Modèle Strates-IAsyntaxe et sémantique des annotations,

primitives d'exploitation

Recherche, classement traitement de documents

Génération des descripteurs

Stockage et représentation des descripteurs

Exploitation des descripteurs

Figure 10 : Schéma situant l’utilisation du modèle Strates-IA dans la chaîne de traitement des do-

cuments


60

3.2.1. Présentation des Strates-IA

Dans cette section nous présentons brièvement le modèle Strates-IA, en nous concen-trant sur les notions de base. Nous reviendrons sur la plupart des notions présentées ici dans les chapitres décrivant le modèle E-SIA.

3.2.1.a) Le graphe

Strates-IA (Strates Interconnectées par les Annotations) est un modèle de représenta-tion et de structuration d’annotations de documents audiovisuels [Prié 1999]. Il pres-crit de décomposer un document audiovisuel en « strates » (fragments définis par des bornes temporelles). Des caractéristiques ou termes différents annotent des fragments temporellement situés dans le document audiovisuel. Les concepts sont tirés d’une base de connaissances leur donnant une hiérarchie sémantique. L’ensemble des anno-tations et la base de connaissances forment un graphe connexe orienté étiqueté. Un flux audiovisuel est un fichier informatique contenant des données audio et vidéo synchronisées, commençant à l'instant t0=0 et se terminant à un autre instant td.(td est la durée du document.) Une unité audiovisuelle (UAV) est une entité représentant un morceau quelconque du flux audiovisuel. Une UAV est déterminée par un flux audiovisuel ainsi que de deux instants t1 et t2 compris entre t0 et td permettant sans ambiguïté de situer le morceau de document au-diovisuel représenté par l'UAV. L'UAV prend naissance à partir du moment où elle a été repérée automatiquement ou manuellement. Une UAV existe dès lors qu'on lui a attaché une description. Toute UAV est donc annotée, c'est à dire associée à au moins une instance de terme.

est_annote_par(Ra-1)

annotation primitive

Annote( Ra)

UAV1t1 t2

Flux audiovisuelt0 td

EA

Figure 11 : Une unité audiovisuelle et l’annotation primitive qui la fonde

On appelle annotation primitive cette annotation première qui définit l'UAV (Figure 11). Un élément d’annotation EA est l’instance du concept qui annote une UAV (par exemple : Virenque sur la Figure 12). Il est en relation d’annotation Ra avec l’UAV1. Un EA a des attributs qui enrichissent son pouvoir descriptif (par exemple une réfé-rence à une image représentative, …). On met en place des relations entre les EA afin de structurer l’annotation. Ces rela-tions entre EA se résument à la relation élémentaire Re. Les relations plus complexes (ayant une signification pour l’utilisateur) se forment en introduisant des éléments d’annotations de relation (EA :Agent dans la Figure 12). Ces éléments d’annotations

E-SIA

61

fournissent la possibilité de donner une sémantique à ces relations (Virenque est quelqu’un qui tombe). Un élément d’annotation résulte de l’inscription dans le flux d’éléments d’annotation abstraits EAA décrits dans une base de connaissance BC (par exemple : EAA:Virenque ). Cette base de connaissances définit le vocabulaire contrôlé, pouvant être utilisé pour décrire.

Ra

tomber

Ra

Agent

Ra

Re

Re

Virenque

EAA:Virenque

EAA:Personne

EAA:Agent

EAA:tomber

EAA:Armstrong

EAA: All

Rspec

Rspec

Rspec

Rspec

Rspec

Rif Rif

Rif

EA

EAA

UAV1

UAV2

2'30'' 3'53''

2'50'' 3'35''

Base deConnaissances

Rd Rd

Rd

EAA:rouler

Rspec

UAV

Légende

Figure 12 Structuration de l’annotation

Les EAA définissent un thesaurus structuré dans le cadre des Strates-IA. Un EAA est en relation d’inscription dans le flux Rif avec les EA qui lui sont liés. Les EA sont en relation de décontextualisation Rd avec l’EAA dont ils sont instances. Par exemple <Virenque>Rd<EAA:Virenque> et < EAA:Virenque>Rif<Virenque> (Figure 12). La base de connaissances possède des relations qui permettent de structurer son conte-nu. Il s’agit des relations conceptuelles : de spécialisation, d’abstraction, de synonymie, etc. Ce réseau avec l’ensemble des EA et UAV et les relations entre eux forme un gra-phe connexe orienté étiqueté. Ce qui suit définit formellement les relations qui peuvent exister entre les différents éléments dans Strates-IA. Les relations peuvent être internes si elles mettent en rela-tion deux éléments se trouvant dans le même document ou externes si elles relient deux éléments se trouvant dans des documents différents.


62

EA -> UAV : Ra relation d’annotation UAV -> EA : Ra

-1 relation d’annotation inverse EA -> EA : Re relation élémentaire (ou bien Re-1) EA -> EAA : Rd relation de décontextualisation EAA -> EA : Rif = Rd

-1 relation d’inscription dans le flux EAA -> EAA : relations conceptuelles diverses (relations de spécialisation, d’abstraction,…), internes à la base de connaissance (relations internes Ri) Le graphe Strates-IA est donc constitué des nœuds de type : UAV, EA ou EAA, et des relations de type Ra, Rspec, Rabs, Rif, Rd qui relient ces nœuds. Y. Prié introduit également les notions de dimension d’analyse (DA), pour regrouper des termes (EAA) et de schéma de description (SD), pour contrôler la structure des annotations sans en donner de définition formelle. Nous allons revenir sur ces notions lors de la présentation du modèle étendu (E-SIA).

3.2.1.b) Opérationnalisation

Pour définir les requêtes sur la base d’annotations, Y. Prié a introduit la notion de Graphe Potentiel (GP). Celui-ci est un graphe contenant des nœuds typés (UAV, EA, EAA) mais pas forcément totalement spécifiés, une partie de ces sommets peut être rendue générique en laissant certains attributs non renseignés. Pour traduire la requête « Trouver Virenque » nous construisons le GP de la Figure 13. Le nœud de départ est le terme (EAA:Virenque). Nous cherchons toutes les UAV qui sont annotées par un EA instance de cet EAA. Les sommets 1 et 2 sont rendus génériques (on ne précise pas leur nom). Une fois la requête traduite en GP, nous recherchons les sous-graphes de la base d’annotations qui lui sont isomorphes. Nous faisons une instanciation du GP dans le graphe global en utilisant l’algorithme de multipropagation. [Prié et al. 2000].

*

*

Ra

Rd

Nom: trouver_virenque

1

2

3 EAA:Virenque

Figure 13 : Graphe potentiel

Les graphes potentiels permettent de traduire des requêtes en graphes, fournissant ainsi un outil d’exploitation adapté au modèle. En plus de la traduction des requêtes, les graphes potentiels permettent de représenter des contextes génériques de diffé-rents nœuds.

E-SIA

63

3.2.1.c) Organisation et documentation de l’annotation

Y. Prié introduit la notion de Dimension d’Analyse (DA) pour permettre de regrouper des termes en dehors de la hiérarchie imposée par la structure de la base de connais-sances. Une dimension d’analyse (DA) est définie en Strates-IA, comme un ensemble de termes (EAA), désignés concrètement, ainsi qu’un ensemble de « méthodes de dé-signation ». Les DA permettent de regrouper les termes désignant des objets d’intérêt de même type. Les méthodes de désignation sont des graphes potentiels exploitant la hiérarchie de la base de connaissances et permettant la sélection d’un ensemble d’EAA. La Figure 14 illustre une méthode de désignation permettant de choisir les termes décrivant des personnes. L’instantiation de cette méthode de désignation dans la base de connaissances de la Figure 12 donne les EAA : Virenque et Armstrong.

EAA: *

EAA:Personne

Rspec

Figure 14 une méthode de désignation

Une vidéo peut être décrite selon différentes dimensions d’analyse. On peut par exemple considérer la dimension d’analyse liée au repérage des personnes, mais aussi des dimensions d’analyse liées par exemple à la recherche d’unités structurelles : Plan, Scène, Flux. Les dimensions d’analyse ne sont pas figées a priori et permettent de regrouper des termes de façon pertinente par rapport aux objectifs de l’analyse du document. Pour contraindre l’annotation, Y. Prié propose de créer des graphes de dimensions d’analyse. Ces graphes sont appelés Schémas de Description (SD). On dit qu’une vi-déo est annotée selon un schéma de description dans le cas où les annotations sont choisies dans les dimensions d’analyse qui forment le SD et que les relations prévues entre ces dimensions d’analyse sont respectées.

3.2.2. Analyse critique du modèle des Strates-IA

Strates-IA organise les documents et leurs annotations en graphe. Il définit 3 types de nœuds, des relations et des notions qui permettent d’exploiter et organiser ce graphe (DA et SD). Strates-IA établit un modèle théorique de principe. Nous avons commen-cé nos travaux par son implantation et donc son opérationnalisation. Nous avons for-malisé les objets, nous avons élaboré les représentations en XML, et tables de bases de données relationnelles et les modèles d’implantation orientée objet. Lors de l’implantation du système d’annotation et de recherche nous avons étudié et réalisé la répartition sur plusieurs sites des annotations et documents, traité des pro-blèmes de mise à jour, de propagation des modifications, des droits. Nous avons développé des interfaces graphiques pour l’annotation, la recherche et mis en place différentes couches logicielles pour l’implantation du modèle. Puisque la manipulation (annotation, recherche, exploration) des documents audiovi-suels est une tâche complexe, nous avons étendu le modèle de représentation des an-notations en modèle de traçage et capitalisation de l’expérience.


64

Des Strates-IA nous avons gardé l’idée du graphe de base : la représentation des an-notations sous forme de nœuds, attachés à d’autres nœuds représentant les fragments de documents. Nous avons formalisé les nœuds des Strates-IA en ensembles de couples <attributs, valeur>. Les UAV et EA sont bien formalisés dans Strates-IA, nous les avons simplement re-présentés en XML et créé les objets qui les concernaient. Nous avons repris également le concept théorique de vocabulaire contrôlé sans pré-server la structure hiérarchique arborescente du thesaurus. Nous considérons en effet qu’imposer une seule hiérarchie à un vocabulaire dont les usages ne sont pas fixés à avance et qui est susceptible de couvrir plusieurs domaines est utopiste. Les éléments d’annotation abstraits définissent les attributs, mais nous avons généralisé le caractère facultatif des attributs par des limites d’occurrences. Les termes (EAA) dans E-SIA permettent de préciser combien de fois un attribut qu’ils définissent doit être instancié par un élément d’annotation (EA) dérivé au minimum et au maximum, pour qu’il soit valide. Nous allons revenir sur ce point lors de la présentation détaillée de notre mo-dèle. Strates-IA introduisait les notions théoriques de dimension d’analyse et de schéma de description. Ces notions posaient les principes des structures indépendan-tes du graphe. Nous avons formalisé et transformé les dimensions d’analyse (DA) ainsi que les schémas de description (SD) en tant nœuds de graphe et les avons ajouté au même graphe que les annotations. Nous avons donc élargi l’ensemble des types de nœuds et des relations. E-SIA a évolué vers un modèle homogène, exploitable entiè-rement par des graphes potentiels. Les graphes potentiels se retrouvent sans changement majeur dans E-SIA. Nous avons introduit la notion de fonction de comparaison pour formaliser l’appariement des nœuds lors de la recherche d’instances d’un graphe potentiel. A chaque type d’attribut correspond une liste de fonctions de comparaison. Ces fonctions permettent de donner un degré de similarité entre deux attributs de même type. Aussi bien la liste des attri-buts possibles que la liste des fonctions de comparaison sont dynamiquement extensi-bles, conférant ainsi une grande liberté de description et d’exploitation des docu-ments. Nous illustrerons cette formalisation dans le chapitre sur les graphes potentiels (3.4.4). Nous avons donc étendu et implanté le modèle Strates-IA, formalisant les notions énoncées. Nous avons créé un système fonctionnel, distribué d’annotation et de re-cherche de documents audiovisuels.

E-SIA

65

Strates-IA E-SIA UAV théorique UAV représentation formelle en XML, table SQL et

objet. EA terme avec des attributs EA terme avec des attributs éventuellement multiples,

en fonction de leur définition dans les EAA. Représen-tation formelle en XML, table SQL et objet.

EAA définition de termes et attributs, un attribut peut être facultatif ou non

EAA définition de termes et attributs, un attribut a un nombre d’occurrences minimales et maximales. Repré-sentation en XML, table SQL et objet.

DA ensemble théorique de EAA.

DA nœud du graphe, relié aux EAA. Représentation en XML, table SQL et objet.

SD principe de graphe de DA pour contraindre l’annotation

SD : nœud du graphe, introduction des nœuds RDA, formalisation des relations entre les représentants de dimensions d’analyse ainsi que des contraintes entre les relations de SD et les relations entre les annotations qui leur sont conformes.

Graphe des annotations : ne comporte que 3 types de nœuds : UAV, EA, EAA

Graphe des annotations avec 6 types de nœuds : (UAV, EA, EAA, DA, RDA, SD). Graphe contenant tous les éléments faisant partie de l’annotation. Struc-ture globale et homogène.

Graphe potentiel Graphe potentiel comme dans Strates-IA, avec le sys-tème de fonctions de comparaison par type d’attributs, pour conférer une souplesse et une évolutivité au mo-dèle.

Tableau 1 Evolutions entre les éléments de Strates-IA et E-SIA


66

3.3. Le modèle E-SIA

Le système E-SIA prend ses origines dans Strates-IA. Il le modifie et le complète par des éléments de structuration de thesaurus et de documentation de la façon d’annoter. E-SIA introduit un cadre de modélisation des actions et de l’expérience de l’utilisateur avec des outils pour capitaliser, exploiter et réutiliser ces traces d’utilisations. Enfin, E-SIA définit un cadre formel de mise en place d’un système d’annotation et de recherche de documents audiovisuels basé sur le modèle théorique. Ce système est multi-site et multi-utilisateur. E-SIA se veut un système d’annotation et d’exploitation de documents multimédias fonctionnant sur des ressources distribuées sur un réseau (notamment sur Internet) of-frant le cadre de la mise en place d’une aide intelligente. Nous considérons qu'aussi bien les documents annotés que les annotations, sont dis-tribués. Plusieurs personnes consultent et alimentent cette base laissant des traces d'utilisation elles-mêmes distribuées. En ce qui concerne l'aide intelligente, nous entendons par cela un système qui facilite la tâche de l’utilisateur en l’observant, un système qui s’adapte à lui et qui soit donc fortement personnalisable et interactif.

Site 1

Documents

Annotations

Traces d'utilisation

Site 2

Documents

Site 4

Annotations


Site 3

Documents

Annotations


Site 5

Documents

Figure 15 : Architecture distribuée du modèle E-SIA.

La Figure 15 illustre la répartition des différents éléments sur le réseau. Les différents sites peuvent représenter par exemple des intranets, ou des réseaux locaux, voire, des machines individuelles.

E-SIA

67

Pour introduire notre modèle nous supposons que le document à annoter est une sé-quence d’une course cycliste où Virenque a fait une chute et des pompiers lui appor-tent les premiers secours. Dans E-SIA (Figure 16), les documents sont décrits par des éléments d’annotation (EA). Ces éléments d’annotations (EA) sont tirés d’un vocabu-laire utilisable pour l’annotation. Les termes, éléments d’annotation abstraits (EAA) constituant ce vocabulaire peuvent être regroupés dans des dimensions d’analyse (DA) formant ainsi des ensembles utiles dans le cadre d’une tâche d’annotation don-née. Les éléments d’annotation (EA) annotent des fragments de documents matériali-sés dans le graphe par des unités audiovisuelles (UAV). Les éléments d’annotation peuvent être contextualisés en les mettant en relation (au sein même de l’annotation) à l’aide d’une relation élémentaire (Re). L’ensemble des éléments forme un graphe connexe orienté étiqueté. Une tâche d’annotation est partiellement définie à l’aide d’une structure appelée schéma de description (SD). Cette structure permet d’imposer un cadre plus ou moins contraignant à l’annotation en précisant quelles sont les dimensions d’analyse à utili-ser, ainsi que les relations à mettre en place entre les descripteurs posés en instanciant des termes (EAA) de ces dimensions d’analyse. Nous parlons d’annotation « selon un schéma de description ». Les schémas de description permettent de documenter et de guider la façon de décrire un document. En pratique lors d’une annotation, l’utilisateur choisit un schéma de description, re-père dans le document à annoter les fragments intéressants et les annote en instan-ciant les termes (EAA) contenus dans les dimensions d’analyse composant le schéma de description. Dans notre exemple (Figure 16), le SD Premier Secours a été utilisé pour annoter une vidéo représentant des accidents dans des courses cyclistes. Une fois le schéma de description choisi, il faut spécifier des secouristes, des victimes et des opérations. L’utilisateur regarde la vidéo, repère les fragments contenant les diffé-rents objets d’intérêt et les annote par des annotations contenues dans les trois dimen-sions d’analyse.


68

VictimesSecouristesOpérations


Vérification

RifRif

RaRa

Massage

RifRif

RaRa

Dégagement

RifRif

RaRa

Re

ReReReRe

ReReReReRe

Re

ReRe

ReRe

Lt. Tonton

Virenque

ArmstrongVoisin

Massage

DégagementVérification

Tout

DA: Secouriste DA: VictimeDA: Opération

Graphe connexe orienté étiqueté

t0 tnLe flux vidéo (cyclistes - secourisme)

Virenque

RifRif

Ra

AA élément d’annotation abstraitEAA

EA élément d’annotationEA

UA unitée audiovisuelleUAV

AD dimension d’analyseDA

SD Premier Secours

SD: schéma de descriptionSD

Relations :• Ra: relation d’annotation• Re : relation élémentaire • Rif : relation d’inscription dans le flux• ...

Eléments :

RDA: Secouriste RDA: VictimeRDA: Opération

Lt. Tonton

RifRif

Ra

ReSD ReSD

RrepRrep

Rrep

AD représentant de dimension d’analyseRDA

Rcont RcontRcont

Rr

Rr

Rr

Rr

Rr

Figure 16 Exemple de graphe des différentes « couches » de l’annotation dans E-SIA (document

vidéo sur le secourisme)

3.3.1. Objets de base

Dans cette section nous présentons les « briques de base » du modèle d’annotation. Nous reprenons les objets de Strates-IA en les redéfinissant et nous introduisons de nouvelles notions. Nous construisons le modèle sous la forme d’un graphe, les différents objets consti-tuant les nœuds et arêtes de celui-ci. Certains nœuds représentent les fragments de documents et leurs annotations (objets concrets), alors que d’autres sont introduits pour expliquer cette annotation (objets abstraits). Les objets concrets sont toujours re-liés à un document et n’existent que grâce à lui. Les objets abstraits définissent le ca-dre pour l’annotation en général, ils ont une existence indépendante des documents. Tout nœud du graphe a un identificateur unique.

3.3.2. Documents et fragments

Pour annoter tout ou partie d’un document, le modèle définit un type de nœud qui permet de représenter le fragment annoté. Un document audiovisuel est un morceau de musique, une vidéo, ou tout autre document qui se déroule dans le temps. Les do-cuments audiovisuels ont une vitesse de lecture, un début et une fin. Ils ont également une certaine durée. Pour écouter un morceau de musique qui dure dix minutes, il nous faut dix minutes, pour visionner un film d’une heure et demi, pour un humain il faut prendre les quatre-vingt dix minutes. Le temps joue un rôle essentiel dans ces docu-

E-SIA

69

ments. Les documents audiovisuels véhiculent des informations, mais font également ressortir des sentiments, font passer des messages et pour cela, ils utilisent le temps comme outil, comme moyen de communication. Pour appréhender une série d’images fixes ou lire dix pages de texte, chacun d’entre nous a besoin d’une durée de temps différente. La quantité d’informations ne nous impose pas un rythme de consommation. Dans le cas des informations, sans vitesse de lecture imposée (un livre, des photos, …), nos pensées peuvent recréer des contextes, faire des associations, synthétiser à notre rythme, sans être soumis à des nouvelles in-formations dans l’instant qui suit. Dans le cas des documents audiovisuels, en plus des effets visuels nous avons leur succession, la vitesse à laquelle ils se déroulent qui nous imposent une certaine manière d’associer les pensées révélées par ces images. L’information véhiculée est d’une autre nature. D’un certain point de vue nous de-vons arrêter ou adapter fortement la partie associative et synthétique de notre cerveau pour pouvoir stocker en temps réel les informations perçues. En ce qui concerne le son, il ne peut pas exister sans le temps. Il est donc important de prendre en compte cet aspect temporel quand nous voulons décrire, annoter des documents. Quand nous voulons décrire un fragment d’un document audiovisuel nous nous réfé-rons à des fragments temporels. L’unité atomique est l’image quand il s’agit de vi-déos. Nous pouvons bien sûr descendre en dessous de l’image pour en désigner une partie, ou désigner des objets formés par une partie de l’image à travers le temps (une voiture dans une séquence vidéo, dans le style des objets MPEG4 [MPEG 2002]), mais dans notre modèle à l’état actuel nous ne considérons pas ces cas. Nous revien-drons par contre lors de la discussion. Le fragment de document, au sens E-SIA, contient donc, la totalité des informations contenues dans le document entre deux ins-tants, lors de sa visualisation ou écoute. Les deux instants peuvent être identiques dans le cas de documents vidéo, désignant ainsi une seule image, mais devront dési-gner au moins une période correspondant à la fréquence d’échantillonnage dans le cas de documents sonores. Le nœud représentant une séquence continue d’un document audiovisuel dans le mo-dèle E-SIA s’appelle unité audiovisuelle (UAV). Une UAV est définie par l’identificateur du document, et les bornes temporelles du fragment. Les bornes tem-porelles sont deux nombres (t1 et t2, t1≤t2) représentant les instants de début et de fin du fragment sur l’échelle du temps du document en milli-secondes. Une UAV peut représenter tout le document, dans ce cas t1=0 ms et t2=td où, td est la durée totale du document en milli-secondes. Soit D un document audiovisuel de durée td. On définit un nœud UAV du modèle E-SIA représentant un fragment continue du document D par : UAV = <ID,réfD, t1,t2> (0≤t1≤t2≤td) où ID est l’identificateur du nœud réfD est une référence vers le document (URI) t1 est l’instant de début du fragment sur l’échelle de temps du document t2 est l’instant de fin du fragment sur l’échelle de temps du document. Par exemple le triplet : <UAV-1,’http://ESIA.net/videos/accidentvelo.avi’, 124,13400> représente le fragment compris entre les instants de 124 ms et 13400 ms de la vidéo se trouvant à l’URI http://ESIA.net/videos/accidentvelo.avi.


70

t0=0 ms t1 t2 td

UAV1 (D, t1,t2)

D

t

Vérification

Ra

Annotation primitive

Unité audiovisuelle

Document (flux)

Echelle de temps du flux Figure 17 Unité audiovisuelle définie sur une vidéo de secourisme (le document D)

La Figure 17 illustre une unité audiovisuelle représentant la vérification, l’examen de l’état d’une victime d’un accident de vélo. Elle commence à l’instant t1, où sur la vi-déo le secouriste commence à vérifier l’état de la victime, et se termine à l’instant t2, où il y a par exemple une coupure de montage, la vidéo présentant les autres coureurs. Sa durée est donc de (t2-t1) ms. Une unité audiovisuelle accède à l’existence grâce à l’annotation. On identifie un fragment dans le document dans le but de l’annoter, et en lui attribuant une descrip-tion. C’est pour cette raison que dans E-SIA tout fragment de document est annoté ! Une même unité audiovisuelle peut être annotée par plusieurs annotations, nous par-lons alors de sur-annotation. Formellement cela se traduit par l’existence pour chaque nœud de type UAV d’au moins un nœud représentant une annotation avec lequel il est en relation, c’est l’annotation qui est à l’origine de l’UAV. Cette annotation est appelée annotation primitive de l’UAV. De point de vue du modèle théorique les fragments de documents de E-SIA sont iden-tiques aux UAV du modèle Strates-IA. En pratique nous avons construit une représentation des UAV en XML et nous avons mis en place les outils pour sa manipulation. Nous travaillons sur une généralisation des nœuds de type UAV de façon à pouvoir représenter tout fragment de document, audiovisuel ou non. Nous pourrons les appe-ler Objets d’intérêt et permettre la désignation des fragments d’un document texte, fragments d’images, la désignation d’un objet (de type MPEG4) dans un flux vidéo. Nous pourrons utiliser les XPointers pour identifier les fragments. Nous allons reve-nir sur ces propos dans la discussion.

3.3.3. Annotations

Les fragments de documents sont annotés par des annotations. En E-SIA une annota-tion est matérialisée par un nœud de type élément d’annotation (EA). Ce nœud est re-lié au nœud représentant le fragment de document (UAV) qu’il annote, par une rela-tion d’annotation Ra (Figure 18). A son tour, l’unité audiovisuelle est reliée à l’élément d’annotation par une relation est annotée par, notée : Ra

-1 (relation d’annotation inverse). Un élément d’annotation est le nœud matérialisant un mot clé, un terme qui décrit le fragment. Une annotation est un terme, avec un ensemble d’attributs. Un élément d’annotation est défini par son nom, un identificateur et une liste d’attributs et de leurs valeurs. Cette liste d’attributs contient obligatoirement un attribut nommé Primitif de valeur booléenne permettant de spécifier si l’EA est une annotation primitive. Pour des raisons de simplicité les nœuds sont identifiés sur les

E-SIA

71

figures à l’aide de leur attribut « Nom » (par exemple Flux) plutôt que par leur identi-ficateur qui est un code unique généré automatiquement. L’élément d’annotation Flux de la Figure 18 a le nom : Flux, un identificateur et trois attributs : Titre, Compres-sion et Image clé, avec les valeurs respectivement : Chute vélo, avi DivX et http://ESIA.net/image1.jpg. Cet EA annote le fragment de document représenté dans le graphe par le nœud UAV1.

UAV1


EA :FluxAttributs de l ’EATitre : Chute véloCompression : avi DivXImage Clé : http://ESIA.net/image1.jpgRa Ra

-1

Figure 18 Un élément d’annotation avec des attributs

Pour donner un autre exemple : l’annotation Vérification dans le cadre des vidéos de premier secours peut avoir des attributs tels que l’objet de la vérification (pouls, res-piration, saignement, conscience…), la technique employée (toucher, questions, …). Si nous annotons un fragment avec l’annotation Virenque les attributs potentiels sont par exemple l’âge, l’équipe, le numéro de maillot, … Nous avons le problème classi-que de conception de structures des classes et attributs. Prenons par exemple le cas de la Figure 19. Sur la partie a, l’équipe (ici : Domo) est une information qui figure en tant qu’attribut. Dans le cas de la partie b, l’équipe prend un statut d’annotation indé-pendant et elle est reliée à l’annotation Virenque par une relation élémentaire Re.

UAV1


EA : VirenqueAttributs de l ’EAÂge : 33Equipe : Domo

UAV1


EA : VirenqueAttributs de l ’EAÂge : 27

EA : DomoRe

a b

Ra Ra

Ra

Figure 19 Deux manières d’annoter avec les mêmes informations un fragment de document

Les relations élémentaires relient deux nœuds de type EA, et indiquent le fait que dans le cadre de la tâche d’annotation donnée, pour l’utilisateur qui effectue l’annotation les deux nœuds ont un lien. Nous n’imposons pas de sémantique spécifi-que. S’il y a une sémantique spécifique, elle découle du contexte plus large de l’annotation. S’agissant d’une vidéo représentant des chutes pendant des courses cy-clistes et des interventions des premiers secours, il est intuitif de penser que l’on spé-cifie l’équipe avec les coureurs, éventuellement que l’on spécifie une seule fois l’équipe et qui elle est reliée aux coureurs (Figure 20).


72

UAV1


EA : VirenqueEA : Telekom

EA : EquipeRe

Ra RaRa

EA : DomoRe

EA : Armstrong

RaRa

EA : Equipe

Ra

Re

EA : UlrichRa

Re

Re

Figure 20 EA relation : au lieu de relier directement les coureurs aux équipes, nous utilisons des

EA pour « nommer » la relation

Nous pouvons également utiliser des éléments d’annotation pour « mettre un nom » sur une relation élémentaire (Re). L’élément d’annotation Equipe de la Figure 21 peut être considéré comme un tel EA de relation. Dans le modèle néanmoins, nous n’imposons aucune règle sur leur interprétation ou utilisation. Sur le rôle et les rela-tions entre éléments d’annotations nous allons revenir dans le chapitre traitant des schémas de description.

UAV1


EA : VirenqueAttributs de l ’EAÂge : 27 EA : Domo

ReEA : Equipe Re

RaRa Ra

Figure 21 Utilisation d’un EA pour « nommer »un lien

Sur l’exemple de la Figure 22 nous représentons des annotations sur deux documents. Deux vidéos représentant des accidents de vélo, ayant comme titres : « Accident vélo 1 » et « Accident vélo 2 ». Sur un des documents c’est Virenque qui tombe, sur l’autre Ulrich. Grâce à l’élément d’annotation Voir aussi nous sommes capables d’expliciter ici une ressemblance, un intérêt commun entre les deux fragments repré-sentant les deux chutes. Puisque le nœud qui fait la liaison entre les deux flux (EA Voir aussi) est un élément d’annotation, il doit être relié à une unité audiovisuelle. Dans le cas de cet exemple nous avions le choix. L’EA aurait pu être relié à l’unité audiovisuelle UAV2 aussi. Ce lien entre les deux flux a été jugé utile par l’utilisateur qui a annoté les documents, et peut servir lors de l’exploration des annotations par navigation (nous allons détailler les différentes méthodes d’exploitation et explora-tion dans la suite). Dans la pratique c’est une question d’interface graphique propo-sant une vue spécifique ou de méthodes de spécifier le « sens de la phrase » représen-té par un élément d’annotation qui a ce rôle de lien.

E-SIA

73

UAV1

EA: FluxAttributs EATitre : Accident vélo 1

UAV2

EA: Virenque

EA: Chute

UAV3


UAV4

EA: UlrichEA: ChuteEA: Voir aussi

Ra

RaRa

Ra Ra RaRa

Re

Re

ReRe

Figure 22 Annotations de plusieurs documents

Les EA et les UAV forment dans E-SIA les nœuds concrets. C’est à dire les nœuds qui sont directement attachés à des documents et dont l’existence dépend de ceux-ci. Les documents et leurs annotations forment une couche inséparable dans notre mo-dèle. Le document audiovisuel annoté, donc enregistré dans le modèle, n’est visible qu’à travers les annotations. Bien sûr, d’un point de vue pratique cela ne présente au-cune contrainte. En effet dès qu’un document est introduit dans le système au moins deux nœuds sont créés par défaut : une unité audiovisuelle, désignant le document en-tier et un élément d’annotation nommé Flux, qui l’annote (Figure 23).

UAV1


Ra

Ra-1

Figure 23 Annotation par défaut

Pour résumer, nous récapitulons les éléments du modèle traités jusqu’à maintenant. Nous avons vu que le modèle représente les fragments de documents ainsi que les an-notations qui les décrivent sous la forme d’un graphe connexe orienté étiqueté. Il y a deux types de nœuds qui sont directement liés aux documents : les unités audiovisuel-les (UAV), matérialisant les fragments, et les éléments d’annotation (EA) qui repré-sentent les annotations. Les éléments d’annotations sont reliés aux unités audiovisuel-les par des relations d’annotations Ra et les UAV s’attachent aux EA par des relations d’annotation inverses Ra

-1. Pour enrichir l’expressivité du modèle sans pour autant le contraindre, nous avons introduit la possibilité de mettre des relations entre les élé-ments d’annotation. Ces relations élémentaires Re permettent de spécifier des liens entre des annotations et donc entre des fragments de documents. Les relations élé-mentaires Re ont leurs relations inverses Re

-1.

3.3.4. Eléments de contrôle d’organisation et de documentation des annotations

Nous avons vu, que les fragments de documents peuvent être annotés par des élé-ments d’annotation, qui ont un nom et des attributs. Pour garder l’annotation aussi homogène que possible, nous nous proposons de définir, contrôler le vocabulaire uti-lisé pour l’annotation, lui permettant toutefois une évolution aisée. Nous incluons dans le graphe également des éléments qui permettent de structurer ce vocabulaire


74

(dimensions d’analyse) ainsi que les schémas de description qui rendent possible la documentation de l’annotation tout en fournissant un cadre contraignant.

3.3.4.a) EAA

Nous introduisons dans le modèle E-SIA un nouveau type de nœud, appelé élément d’annotation abstrait (EAA), qui comme son nom l’indique permet de servir de défi-nition aux éléments d’annotation. Les éléments d’annotation (EA) sont des instances des éléments d’annotation abstraits (EAA). L’EA garde le nom de l’EAA et en ins-tancie les attributs définis. Un élément d’annotation abstrait (EAA) permet donc de définir un terme, une annotation générique et une liste d’attributs que les EA qui en dérivent doivent instancier. L’ensemble d’éléments d’annotation abstraits forme le vocabulaire que nous pouvons utiliser pour annoter. Dans le cas d’une annotation ma-nuelle l’utilisateur choisit des EAA, spécifie le fragment de document et l’annote en créant un élément d’annotation. Les éléments d’annotation abstraits (EAA) existent indépendamment de documents. Ils ne sont pas directement liés à eux. Ils nomment des concepts que l’on peut utiliser pour annoter n’importe quel document. Les EAA forment la première catégorie de ce que nous appelons des nœuds abstraits. Pour pouvoir annoter les documents librement un utilisateur peut éventuellement dé-finir de nouveaux EAA, enrichissant ainsi le vocabulaire. Il est bien sûr intéressant de réutiliser le plus possible les termes déjà définis et de garder les descriptions aussi homogènes que possible pour faciliter la recherche. En effet si pour annoter le même type de documents nous utilisons des synonymes pour désigner un même concept, pour retrouver tous les fragments il faudrait spécifier toutes les formes des mots. Nous allons revenir sur ce point dans les deux chapitres suivants. Le vocabulaire ainsi défini par les EAA doit pouvoir s’appliquer à tout type de docu-ment. Nous pouvons difficilement penser alors, que ce vocabulaire puisse être struc-turé en une seule hiérarchie. La notion de structure unique est irréaliste, car il s’agirait dans ce cas d’une ontologie universelle. Dans E-SIA nous éliminons donc la structure unique imposée, et transformons la Base de Connaissances des Strates-IA (voir section 3.2.1) en un ensemble de EAA, sans aucune relation fixe et définitive entre eux. Pour garder néanmoins la connexité du graphe, nous introduisons un EAA virtuel gé-néral (équivalent à l’EAA ‘ALL’ dans Strates-IA) et le mettons en relation directe avec tous les autres EAA (voir Figure 24). Nous gardons la connexité pour pouvoir appliquer l’algorithme d’instantiation de graphes potentiels.

EAA All

EAA1EAAn-1EAA2

EAAn

EAA3. ...

Figure 24 : Connexion à un EAA virtuel des éléments du thesaurus, pour garder la connexité du

graphe global

Un élément d’annotation abstrait est un nœud du graphe global, qui est défini par un identificateur unique, un nom et une série de définitions d’attributs. Une définition d’attribut spécifie le type de l’attribut, ainsi que ses occurrences, c’est-à-dire combien d’instances (au minimum et au maximum) faut-il créer de l’attribut pour qu’il soit va-lide. Le libellé type d’attribut sera repris comme son « nom » dans l’instance EA. Par exemple le type « Image clé » donnera son nom à toutes ces instances qui, bien en-

E-SIA

75

tendu, ont des identificateurs distincts. Pour chaque type d’attribut il faut en fait met-tre en place des méthodes de création, instanciation (saisie manuelle, construction au-tomatique), des méthodes de comparaison avec des attributs de même type et des mé-thodes de visualisation, interprétation. Prenons l’exemple de l’EAA Flux (Figure 25). Il est défini comme : <EAA2,Flux,(Titre,1,1)(Compression,0,1)(Image Clé,0,n)>. Son nom est : Flux, son identificateur : EAA2 et il définit trois attributs.

UAV1

EA: FluxAttributs EATitre : Accident vélo 1Compression: avi DivX Image Clé : http://ESIA.net/image1.jpgImage Clé : http://ESIA.net/image2.jpg

Ra

EAA:Flux Définition d’attributsTitre : 1,1Compression: 0,1Image clé : 0,n Rif

Rd

Ra-1

Figure 25 Définition et instances d’attributs

Le Titre doit être toujours instancié, tous les EA qui dérivent de l’EAA Flux doivent préciser le titre du flux. La spécification de la compression est facultative, mais doit être unique (un flux ne peut avoir deux compressions), alors que lors de la création d’un nœud de type EA dérivant de l’EAA Flux on peut spécifier plusieurs images clés. Les éléments d’annotation (EA) associent le terme défini par l’EAA à un fragment de document. On peut dire que l’on inscrit l’EAA dans le flux. Tout nœud EA est relié à un et un seul nœud EAA par une relation d’inscription dans le flux Rif. Un nœud EAA peut être relié à plusieurs nœuds EA. Chaque fois que l’on instancie un EAA, un nœud EA et des relations sont créés. Nous appelons la relation qui relie un nœud de type EA à un nœud de type EAA : relation de décontextualisation (Rd). La relation de décontextualisation (Rd) est la relation inverse de la relation d’inscription dans le flux (Rif).


76

UAV1


UAV2

EA: Virenque

EA: Chute

UAV3


UAV4

EA: Ulrich

EA: ChuteEA: Voir aussiRa

RaRa

Ra Ra RaRa

Re

Re

ReRe

EAA:Flux EAA:Chute

EAA:Voir aussi EAA:UlrichEAA:VirenqueRif

EAA:ALL

Rif

Rif

Rif

Rif

Rif

Rif

Définition d’attributsTitre : 1,1Compression: 0,1Image clé : 0,n

Figure 26 Graphe d’annotation contenant les éléments d’annotation abstraits

La Figure 26 présente un fragment du graphe d’annotations contenant deux flux, des annotations et les éléments d’annotation abstraits qui les définissent. Nous pouvons remarquer que pour les éléments d’annotation (EA) Flux, nous avons instancié seu-lement l’attribut Titre. En effet pour l’attribut Compression, la cardinalité minimale était nulle, ce qui rend son instanciation facultative.

3.3.4.b) Dimension d’Analyse

Comme nous l’avons défini dans le chapitre précédent les EAA, constituent un en-semble de termes non structuré. Bien que, en tant qu’humains, nous soyons incapa-bles de tout structurer, nous avons l’habitude de voir des « catégories d’objets ». Nous regroupons usuellement les objets en catégories de personnes, d’animaux, de verbes, de sujets, d’hommes, de femmes, de cyclistes, de secouristes, … Ces catégo-ries, ces groupes ne sont pas disjoints. Un terme peut appartenir à plusieurs d’entre eux. Nous utilisons également des catégories de termes quand nous décrivons des do-cuments. Dans l’annotation d’une vidéo de courses cyclistes, nous précisons quels sont les coureurs avec leurs noms, nous repérons les accidents, les interventions de premier secours, les victimes, les différentes phases, opérations de l’intervention, … Nous analysons les documents selon plusieurs dimensions, plusieurs facettes, plu-sieurs points de vue. Dans un premier temps nous voulons permettre dans E-SIA le regroupement des ter-mes selon les points de vue de l’analyse et de la description de documents. Permettre de préciser que Ulrich, Armstrong, Virenque sont des coureurs cyclistes, que Massage, Vérification du pouls, Dégagement sont des opérations. Un terme doit pouvoir appartenir à plusieurs « groupes ». Virenque est par exemple coureur cy-cliste, lorsqu’il est sur son vélo, mais au moment où survient un accident il devient également victime. Afin de permettre cette structuration partielle, donc peu contraignante du vocabulaire, nous introduisons dans le modèle E-SIA un nouveau type de nœud appelé dimension d’analyse (DA). Les DA sont utilisées pour exprimer le fait que dans un cadre donné, certains termes vont ensemble, forment une unité sémantique, « jouent le même rôle » dans le contexte de la description faite. Une dimension d'analyse (DA) est définie par

E-SIA

77

un ensemble d'EAA. Elle est caractérisée par un identificateur unique (comme tout nœud du graphe E-SIA), par un nom, par une description plus détaillée, ainsi que par un ensemble de liens vers les EAA concernés. Le fait qu’un nœud de type DA soit re-lié à un nœud de type EAA signifie, que le terme désigné par l’EAA fait partie de l’ensemble défini par le nœud dimension d’analyse. Un nœud de type EAA est relié à un nœud de type DA est une relation d’appartenance (Rapp). La relation entre un nœud de type DA et un nœud de type EAA est la relation d’appartenance inverse (Rapp

-1). La Figure 27 illustre le graphe d’annotation, selon une description des fragments d’une vidéo d’accidents dans laquelle nous avons cherché les opérations de premier secours que des secouristes effectuent sur des victimes. Nous pouvons remarquer que les EA Vérification, Massage, Dégagement ont été posées en tant qu’opérations, Lt. Tonton est un secouriste, alors que Virenque est une victime.


UAV1

UAV2

UAV3 UAV4 UAV5

EA: Vérification

Rif

Ra

EA: Massage

Rif

Ra

EA: Dégagement

Rif

Ra

Re

ReReReRe

Re

Lt. TontonVirenqueMassage


DA: SecouristeDA: VictimeDA: Opération


EA: Virenque

Rif

Ra

EA:Lt. Tonton

Rif

Ra

RappRappRapp

Rapp

Rapp

Figure 27 Annotation d’un flux selon des dimensions d’analyse

En créant les dimensions d’analyse, nous ne cherchons pas à introduire un système d’inférences fortes. Sur la Figure 28 nous présentons une organisation d’un ensemble de termes à l’aide des dimensions d’analyse (DA). Nous pouvons remarquer que Virenque est à la fois Victime, Coureur Cycliste et Français. Suivant le point de vue d’analyse du docu-ment le terme sera choisi dans une ou une autre dimension d’analyse.


78

Lt. Tonton

Virenque

ArmstrongVoisin

Massage


DA : Secouriste

DA : VictimeDA: Opération

Jalabert

DA : Français

DA : Coureur Cycliste

RappRapp

Rapp Rapp Rapp

Rapp

RappRapp Rapp Rapp

RappRapp

Rapp

Figure 28 Regroupement des EAA dans des Dimensions d’analyse (DA)

Lors de l’annotation un utilisateur choisi des EAA dans les dimensions d’analyse qu’il considère pertinentes pour sa description. Dans le modèle E-SIA nous allons créer un nœud de type DA, qui contient tous les termes. Nous l’appelons dimension d’analyse générale (DAG). Les utilisateurs peu familiers avec l’organisation du vocabulaire à un certain moment, pourront choisir dans tous les termes en précisant cette DAG comme ensemble de choix de termes. Lors de la gestion du vocabulaire, nous rencontrons le problème de définition d’ensembles et de valeurs. Nous avons, en effet, deux niveaux de définitions possi-bles : définir les DA et considérer des EAA comme ensembles de valeurs possibles. Nous pouvons aussi définir un EAA, comme nom d’un groupe de termes en précisant un attribut et laisser les EA donner des valeurs. Dans le modèle E-SIA nous n’avons pas de préférences, nous laissons la liberté d’organiser le vocabulaire comme les uti-lisateurs l’entendent. Nous fournissons par contre des outils pour documenter la ma-nière d’annoter.

3.3.4.c) Les schémas de description

Nous avons vu que dans E-SIA le vocabulaire est formé d’un ensemble de termes avec des attributs (EAA). Les termes de cet ensemble peuvent être regroupés selon leur rôle dans une tâche, selon les points de vues d’annotation définissant ainsi des dimensions d’analyse. E-SIA est un modèle d’annotation de documents audiovisuels, pour lequel nous supposons que plusieurs documents sont annotés par plusieurs utili-sateurs. Pour annoter, l’utilisateur doit trouver le bon terme (EAA) dans le vocabu-laire. Si le vocabulaire a une taille importante, contient plusieurs milliers de mots, donc des éléments de formes variées (conjugaisons, synonymes,…), la recherche du terme convenant peut être extrêmement fastidieuse. Pour permettre de documenter et de guider la manière d’annoter nous introduisons la notion de schéma de description (SD). Un schéma de description (SD) a un double rôle : d’une part il fournit un cadre pour documenter l’annotation et d’autre part nous pouvons nous en servir comme ou-til, procédure qui guide l’annotation. Un SD permet de préciser les dimensions d’analyse utilisées lors d’une annotation et permet également de représenter les rela-tions qui relient les annotations issues de ces dimensions d’analyse. Nous avons vu sur la Figure 27 dans le chapitre précédent que l’on a analysé la vidéo selon un certain nombre de dimensions d’analyse, et qu’on a créé cinq annotations. Si nous sommes dans un cadre d’usage privé, nous annotons un petit nombre de do-cuments, nous connaissons nos dimensions d’analyse et nous savons à peu près les-quelles nous avons utilisé quand nous avons annoté des vidéos relatant des accidents. S’il y a d’autres personnes qui recherchent dans nos annotations il serait intéressant

E-SIA

79

de leur fournir l’information sur les dimensions d’analyse utilisées pour l’annotation. Cela permettra de créer des requêtes plus précises, en réduisant le vocabulaire de re-cherche à l’ensemble des termes faisant partie des dimensions d’analyse concernées. Les schémas de description sont des nœuds du graphe d’annotation qui permettent de documenter et de guider, voire contraindre l’annotation. Un schéma de description (SD) définit une structure mettant en relation des dimensions d’analyse et des rela-tions entre elles. Il définit donc un graphe de dimensions d’analyse. Ce graphe fait partie du graphe global d’annotations. Pour des raisons de simplicité dans les traite-ments nous introduisons un nouveau type de nœud : représentant de dimension d’analyse (RDA). Les nœuds RDA et les relations qui les lient forment et définissent le schéma de description. Un nœud schéma de description est caractérisé par un identificateur unique, un nom et une description textuelle25. Le nœud de type SD est relié par des relations de conte-nance (Rcont) à des nœuds de type RDA (représentant de dimension d’analyse). La re-lation inverse est la Rcont

-1. Un nœud RDA est défini par un identificateur unique et un nom, qui est le même que celui du nœud de type DA que le RDA représente. Les nœuds de type RDA sont reliés à des nœuds de type DA par des relations de repré-sentation (Rrep). Chaque RDA représente une seule DA, par contre une dimension d’analyse (DA) peut faire partie de plusieurs schémas de description, donc peut être représentée (être en relation Rrep

-1) dans un ou plusieurs SD par un ou plusieurs RDA. La structure du schéma de description est donnée par les relations entre les représen-tants de dimension d’analyse. Ces relations peuvent être de plusieurs types, contrai-rement à la plupart des autres relations du modèle, qui sont définies par les types des nœuds qu’elles relient. Le schéma de description de la Figure 29 décrit et définit la structure des annotations de la Figure 27 (les annotations sont également rappelées sur la figure). Le nœud SD Premier Secours contient les RDA Secouriste, Opéra-tion, Victime qui représentent les DA de même nom. Le SD prévoit l’utilisation des trois dimensions d’analyse pour annoter, ainsi que la mise en relation de leurs instan-ces par des Re. La sémantique des nœuds RDA et SD est la suivante : nous disons qu’un document est annoté selon un schéma de description (SD). Les RDA du schéma de description indiquent les dimensions d’analyse dans lesquels il faut choisir les annotations pour que l’annotation soit conforme au schéma. Les relations qui relient les représentants de dimensions d’analyse (RDA) sont des relations avec une sémantique différente des autres relations du graphe. Elles imposent la mise en place d’autres relations. Elles ont des cardinalités de départ et d’arrivée. Ces cardinalités indiquent le nombre d’instances qu’il faut mettre en place pour suivre le schéma. La cardinalité de la rela-tion reliant les RDA Secouriste et Opération de la Figure 29 est de 1,1 au départ et 1,n à l’arrivée. La cardinalité 1,1 de départ traduit le fait que toute instance de la di-mension d’analyse Opération doit être mise en relation avec une instance de la di-mension d’analyse Secouriste. La cardinalité 1,n à l’arrivée de la relation indique qu’une instance de la dimension d’analyse Secouriste peut être mise en relation avec plusieurs instances de la DA Opération. Nous voyons en effet que l’EA Lt. Tonton,

25 Par exemple une page html


80

instance de la DA Secouriste est mise en relation avec les EA Massage, Vérifica-tion et Dégagement, qui sont des instances de la DA Opération. La relation entre les RDA est de type ReSD ce qui veut dire que les relations entre les instances doivent être spécifiées de manière explicite et doivent être des relations élémentaires Re. Les nœuds de type EA (les annotations) créés lors d’une annotation selon un schéma de description (SD) sont issus des dimensions d’analyses représentées dans le SD. En pratique, lors d’une annotation manuelle l’utilisateur, précise la vidéo à annoter, choi-sit le schéma de description et créé les instances des dimensions d’analyse représen-tées ainsi que les relations que le schéma impose. Pour indiquer qu’un élément d’annotation a été créé en « ayant le rôle » défini par la dimension d’analyse dont il a été tiré, nous introduisons un nouveau type de relation. Cette relation relie des nœuds de type EA à des nœuds de type RDA et signifie que le EA a été créée en jouant le rôle de la dimension d’analyse représentée par le RDA. Nous appelons ces relations : relations de rôle (Rr). Dans notre exemple, l’EA:Virenque représente une victime. Cette relation est importante lorsqu’un élé-ment d’annotation (EA) fait partie (par son élément d’annotation abstrait) de plu-sieurs dimensions d’analyse (DA), ce serait le cas lors d’une organisation du vocabu-laire, comme présenté sur la Figure 28. En effet, en utilisant la relation de rôle (Rr), nous pouvons savoir, si besoin, le rôle que l’annotation joue.

E-SIA

81

EA: Vérification

Rif

Ra

EA: Massage

Rif

Ra

EA: Dégagement

Rif

Ra

Re

ReReReRe

Re





EA: Virenque

Rif

Ra

EA:Lt. Tonton

Rif

Ra

SD Premier Secours

RDA: Secouriste RDA: Victime

RDA: OpérationRe_SD

Re_SD

Rcont RcontRcont

1,n

1,1 1,1

1,n

RrepRrep

Rrep

UAV1

UAV2

UAV3 UAV4 UAV5

RappRappRapp

Rapp

Rapp

Rr

Rr

Rr

Rr

Rr

Figure 29 Le Schéma de description : Premier Secours

Les Rr, en reliant des EA à des RDA donc à des schémas de description (SD), permet-tent de remonter à partir d’un flux, à l’ensemble de schémas de description utilisés lors de l’annotation de ce flux. Cela peut servir lors de l’exploration des bases de do-cuments annotés par des novices : en ayant la liste des SD qui ont servi à l’annotation des documents les utilisateurs ont un aperçu synthétique sur les méta-données et la structure des annotations, ils peuvent ainsi poser des requêtes plus pertinentes. Sur la Figure 29 l’EA:Lt. Tonton est un secouriste, il est relié au RDA : Secouriste par une relation de type Rr. Les relations entre les nœuds de type RDA peuvent être des relations élémentaires Re_SD ou des relations temporelles. Les relations temporelles ne doivent pas être mises explicitement, il faut simplement que les fragments de documents (UAV), que les ins-tances de ces RDA annotent, satisfassent les contraintes introduites par ces relations. Une relation temporelle particulière est la relation : annoter le même fragment (Ra_SD). Si deux nœuds de type RDA sont en relation Ra_SD, il faut que les annotations issues des dimensions d’analyse représentées annotent le même nœud UAV.


82

Les relations temporelles peuvent être les 13 relations de Allen [Allen 1983]. Ces re-lations sont explicitées sur la Figure 30. Sur cette figure nous illustrons les relations temporelles qui peuvent exister entre deux unités audiovisuelles : UAV1 (débutant à l’instant t1d et se terminant à l’instant t1f) et UAV2 (débutant à l’instant t2d et se ter-minant à l’instant t2f). Nous précisons les conditions sur les bornes temporelles pour que les deux fragments soient en relation. Sur l’exemple nous avons représenté seu-lement 7 relations, car mise à part la relation d’égalité temporelle entre segments, les autres sont les relations symétriques. Si deux nœuds de type RDA sont reliés par une relation temporelle, il faut que les fragments de document (UAV) annotés par les an-notations issues de ces RDA soient dans la relation précisée. Nous signalons que la relation d’égalité temporelle entre UAV n’est pas identique à la relation Ra_SD. En ef-fet si deux nœuds RDA sont en relation d’égalité temporelle Régalité_SD, les annotations (EA) issues des dimensions d’analyse représentées peuvent annoter un fragment ma-térialisé par deux nœuds UAV distincts. Si les bornes temporelles de ces deux nœuds sont identiques, la relation est satisfaite !

UAV2

t2d t

UAV1

t2ft1d t1f

0UAV1 touche UAV2 (meets) : t1f = t2d

UAV2

t2d t

UAV1

t2ft1d t1f

0UAV1 touche UAV2 (meets) : t1f = t2d

UAV1

t1dt

UAV2

t1ft2d t2f0

UAV1 contient UAV2 (contains) : t1d ≤ t2d & t2f ≤ t1f

UAV1

t1dt

UAV2

t1ft2d t2f0

UAV1

t1dt

UAV2

t1ft2d t2f0

UAV1 contient UAV2 (contains) : t1d ≤ t2d & t2f ≤ t1f

UAV2

t2dt

UAV1

t2ft1d t1f0

UAV1 avant UAV2 (before) : t1f < t2d

UAV2

t2dt

UAV1

t2ft1d t1f0

UAV1 avant UAV2 (before) : t1f < t2d

UAV1

t1dt

UAV2

t1ft2d t2f0

UAV1 recouvre UAV2 (overlaps) : t2d ≤ t1f & t1f ≤ t2f

UAV1

t1dt

UAV2

t1ft2d t2f0

UAV1 recouvre UAV2 (overlaps) : t2d ≤ t1f & t1f ≤ t2f

t1d

UAV1

t

UAV2

t1ft2d t2f

0UAV1 début avec UAV2 (begins) : t1d = t2d

t1d

UAV1

t

UAV2

t1ft2d t2f


UAV1

t

UAV2

t1ft2d t2f


UAV1

t1dt

UAV2

t1ft2d

t2f0UAV1 se termine avec UAV2 (finishes) : t1f = t2f

UAV1

t1dt

UAV2

t1ft2d

t2f0UAV1 se termine avec UAV2 (finishes) : t1f = t2f

UAV2

tt2ft2d0UAV1 égale UAV2 (equals) : t1d = t2d & t1f = t2f

t1ft1d

UAV1

UAV2

tt2ft2d0UAV1 égale UAV2 (equals) : t1d = t2d & t1f = t2f

t1ft1d

UAV1

Figure 30 Relations temporelles d’Allen

La Figure 31 présente un schéma de description semblable à celui de la Figure 29. Il prévoit la précision d’un secouriste, d’une victime et des opérations. Il rajoute une re-lation temporelle entre les RDA Secouriste1 et Opération1. Cette relation impose que le fragment annoté par une opération se passe pendant le fragment annoté par le secouriste. Ces cardinalités sont les mêmes que celles de l’autre relation (Re_SD) qui relie les deux mêmes RDA. En effet entre deux RDA il peut y avoir, une ou deux relations. Dans le deuxième cas, une des relations doit être la relation élémentaire Re_SD, car c’est la seule relation non temporelle, donc qui ne sera pas en contradiction

E-SIA

83

avec les autres. En effet si nous relions deux RDA par deux relations temporelles, l’annotation selon le schéma va être impossible car nous ne pouvons avoir deux UAV qui respectent à la fois deux relations temporelles d’Allen. Le schéma de description (SD) Premier Secours 1 prévoit également la spécifica-tion des images clés. Les annotations représentant des images clés doivent être reliées aux annotations issues des opérations par des relations élémentaires Re. De plus l’annotation représentant l’image clé doit annoter le même nœud UAV que l’annotation représentant une opération avec laquelle elle est en relation élémentaire. Les relations entre les nœuds RDA Opération1 et Image Clé ont comme cardinalité de départ 1,1 signifiant que chaque annotation issue de la DA Image Clé doit être re-liée à une et une seule annotation représentant une opération. La cardinalité d’arrivée de 0,n signifie que nous ne sommes pas obligés de spécifier d’images clés pour cha-que opération, mais que nous pouvons en spécifier plusieurs si c’est le cas.

Rif




SD Premier Secours 1

RDA: Secouriste1 RDA: Victime1

RDA: Opération1

ReSD ReSD

Rcont RcontRcont

1,n

1,1 1,1

1,nRrep

Rrep

Rrep

RappRappRapp

Rapp

Rapp

Rcontient_SD 1,n

1,1

RDA: Image Clé

Rcont

Rrep

ImageClé

DA: ImageClé

Rapp

RaSD1,1

0,n

0,n1,1ReSD

Figure 31 Schéma de description avec diverses relations

La Figure 32 présente un document annoté selon le schéma de description Premier Secours 1. Nous pouvons constater que pour l’EA Dégagement on a spécifié deux images clés, pour l’EA Massage, une seule image clé a été spécifiée, alors que l’EA Vérification est relié à aucune image clé.


84

EA: Vérification

Ra

EA: Massage

Ra

EA: Dégagement

Ra

Re

ReReReRe

Re


EA: Virenque

Ra

EA:Lt. Tonton

Ra

UAV1

UAV2

UAV3 UAV4 UAV5

EA: ImageClé

EA: ImageClé

EA: ImageClé

Ra Ra

Re

ReRe

Ra

Figure 32 Annotations en conformité avec le SD de la Figure 31

Les schémas de description permettent de contraindre l’annotation. Par contre dans le modèle E-SIA nous allons mettre en place un schéma de description général (SDG). Ce SD général (Figure 33) contient deux représentants de dimension d’analyse. Ces RDA représentent la même DA, la dimension d’analyse générale (DAG), celle qui contient tous les termes. Les deux RDA sont reliés par une relation ReSD. Les cardina-lités de départ et d’arrivée sont de 0,n ce qui veut dire que l’on n’impose rien. En an-notant selon ce schéma il n’y a aucune contrainte temporelle ni de mise en relation explicite. Les utilisateurs pourront toujours choisir ce schéma, qui leur laisse la liber-té totale pour annoter les documents à leur guise. Les SD permettent de documenter l’annotation. Imaginons que nous ayons accès à une vidéothéque contenant quelques milliers d’heures de documents, annotés par une équipe de documentalistes. Si nous ne sommes pas documentalistes experts, ou ne connaissons pas bien le vocabulaire utilisé pour annoter les documents, il nous sera difficile (surtout au début) de construire des requêtes pertinentes. Nous pourrons par contre avoir une vue des schémas de description utilisés pour annoter les documents. Ces schémas nous donnent des indications précises sur les annotations et leur struc-ture qui construisent la base de documents annotés.

EAA 1

DAG

SDG

RDA: DAG1

Rcont

Rrep

Rapp

EAA 2

Rapp

EAA 3

Rapp

EAA4

Rapp

EAA n-1

Rapp EAA n

Rapp

…..

SDG : schéma de description généralDAG : dimension d ’analyse générale

0,nReSD

0,nRDA: DAG

Rcont

Rrep

Figure 33 Le Schéma de description général

E-SIA

85

Le fait de pouvoir contraindre l’annotation s’avère particulièrement utile dans le ca-dre des institutions productrices d’annotations et de documents, telles que des chaînes de télévision, l’INA, des bibliothèques. Les SD permettent en effet d’homogénéiser les annotations, de mettre en place des canons de description. De cette manière nous pouvons éviter des descriptions ad hoc et faciliter ainsi la mise en place de requêtes pertinentes.


86

3.4. Représentation formelle de E-SIA.

E-SIA est un modèle de représentation d’annotations de documents audiovisuels. Il fournit un cadre pour structurer les annotations, ainsi que des outils pour les exploiter et manipuler.

Définition 1 : Ensembles Soient - TA l’ensemble de types d’attributs. Le type d’un attribut donne des indications sur

l’interprétation de sa valeur. Les objets peuvent par exemple avoir des attributs de type :Nom, TypeESIA, ID …

- TO l’ensemble de types d’objets TO={UAV, EA, EAA, DA, RDA, SD} - E l’ensemble de types d’étiquettes de relations - TV l’ensemble des valeurs d’attributs (cet ensemble est infini)

Définition 2 : Le modèle E-SIA Le modèle E-SIA est défini par un tuple

(O,R,TypeESIA,τA,v,va,α,β,ν) tel que : O est l’ensemble des objets du modèle E-SIA R⊆OxO est l’ensemble des relations du modèle E-SIA (relations binaires et orientés) TypeESIA :O→TO est la fonction qui associe à chaque objet oi∈O son type TypeESIA(oi) τA :O→TA est la fonction qui associe à chaque objet oi∈O l’ensemble de ses types d’attributs τA(oi) v :TA→TV est la fonction qui associe à chaque type d’attribut tai∈TA une valeur possible v(tai) va :OxTA→TV est la fonction qui associe à chaque objet oi∈O et un type d’attribut tai∈TA, la valeur de l’attribut a de type tai de l’objet oi va(oi,tai) α :R→O est une fonction qui à qui à chaque arête r∈R associe son sommet d’origine α(r) β :R→O est une fonction qui à qui à chaque arête r∈R associe son sommet de but β(r) ν :R→E est une fonction qui associe à chaque arête r∈R une étiquette ν(r)

3.4.1. Le graphe

Nous pouvons noter que le couple : G=<O,R>

définit un graphe connexe, orienté, étiqueté, dont les sommets sont les objets de O et les arcs les relations binaires orientés de R.

3.4.1.a) Les sommets

Les sommets oi ∈ O sont appelés objets E-SIA. Ils sont caractérisés par un ensemble d’attributs aj. Chaque attribut a un type et une valeur. Tout objet est formé par un ensemble d’attributs :

oi={aj, j∈[1..n]} avec aj=(τj,vj); τj∈TA, vj∈TV, Tout objet oi∈O est muni d’au moins deux attributs :

- un attribut de type TypeESIA désignant le type de l’objet, et

E-SIA

87

- un attribut de type ID26, désignant un identificateur unique du sommet représen-tant un objet dans le graphe.

Dans la suite la valeur de l’attribut ID sera fréquemment utilisée pour faire référence à l’objet en tant que tel.

Notation 1 : vtype(o) vtype(o) note la valeur de l’attribut a de l’objet o, vta(o) = va(o,ta).

Notation 2 : type(o) ID(o) = vID(o) est l’identificateur de l’objet o. TypeESIA(o) = vTypeESIA(o) est le type E-SIA de l’objet o. Pour rendre plus lisible l’écriture on notera type(o) note la valeur de l’attribut de type type de l’objet o :vtype(o), type∈TA. Par exemple en plus de ID(o) et TypeESIA(o), nous pouvons avoir : Nom(o), Description(o),…

3.4.1.b) Les arêtes

Les objets définis auparavant sont reliés par un ensemble d’arêtes pour former un graphe connecté. Les arêtes sont orientées et étiquetées. L’ensemble d’étiquettes de relations27 est défini comme : E={Ra, Ra

-1, Re, Re-1,Rd,Rif, Rabs, Rspec, Rapp, Rapp

-1,Rrep, Rrep-1, Rcont, Rcont

-1,Rr, Rr-1,

Ra_SD,Ra_SD-1,Re_SD,Re_SD

-1, Rcontains_SD, Rduring_SD, Rstarts_SD, Rstarted_by_SD, Rbefore_SD, Raf-

ter_SD, Rmeets_SD, Rmet_by_SD, Rfinishes_SD, Rfinished_by_SD, Roverlaps_SD, Roverlapped_by_SD, Re-

quals_SD } ∀r∈R, ν(r)∈E.

C’est à dire : toute relation est étiquetée par un élément de E.

3.4.2. Specificités des objets E-SIA

Dans la section précédente nous avons défini la structure du graphe E-SIA en général. Les différents sommets du graphe constitués par des objets E-SIA représentent des fragments de documents (UAV), des annotations (EA), des éléments de vocabulaire d’où les annotations sont tirées (EAA) et des objets qui permettent la structuration du vocabulaire et des annotations (DA, SD, RDA). Les objets ont des attributs différents en fonction de ce qu’ils représentent, c’est-à-dire en fonction de leur type E-SIA. Seuls les attributs de type ID et TypeESIA sont obligatoirement présents. Les sections suivantes décrivent les différents attributs spé-cifiques à chaque type d’objet. Les aspects sémantiques sont traités dans la section 3.4.3.

26 Le codage des valeurs et des attributs sera traité dans la section consacrée à l’implantation du modèle. 27 La sémantique de ces étiquettes est décrite dans les sections 3.2.1 et 3.4.3.


88

3.4.2.a) Unités audiovisuelles (UAV).

Une unité audiovisuelle représente un fragment de document audiovisuel : < (TypeESIA,UAV), (ID,v(ID)), (IdentificateurFlux, v(IdentificateurFlux)), (BornesTemporelles,v(BornesTemporelles)) > v(ID) est un identificateur unique du nœud UAV dans le graphe des annotations. v(IdentificateurFlux) est une référence (URL) vers le fichier vidéo dont l’UAV est ti-rée. v(BornesTemporelles) est un attribut représentant deux instants sur l’échelle de temps du flux, un time-code (exprimé par exemple en milli-secondes). Ces deux instants re-présentent le temps de début td et le temps de fin tf du fragment. Un exemple est illustré en Figure 34 par le nœud UAV-32 : < (TypeESIA,UAV), (ID,UAV-32), (IdentificateurFlux, http://ESIA.net/videos/course1.mpg), (BornesTemporelles,2340_10030)> Cet exemple désigne un fragment de la vidéo se trouvant à l’adresse : http://esia.net/videos/course1.mpg commençant à l’instant td=2340 ms et se termi-nant à l’instant tf= 10030 ms. L’identificateur de ce nœud est UAV-32.

UAV-32

td=2340 ms tf =10030 msFlux Audiovisuel: http://ESIA.net/videos/course1.mpg

t0 t(ms)

Figure 34 Exemple d’une UAV

3.4.2.b) Eléments d’annotation abstraits (EAA).

Un élément d’annotation abstrait matérialise la structure définissant un terme qui peut-être utilisé pour annoter un document. Formellement c’est un n-uplet < (TypeESIA,EAA), (ID,v(ID)), (Nom,v(Nom)), (DefAttr1,v(DefAttr1)), … (DefAttrn, v(DefAttrn))> L’attribut Nom a pour valeur le terme de caractérisation défini par l’EAA. L’attribut DefAttri permet de définir des attributs qui devront être instanciés par les éléments d’annotation (EA) qui dérivent de l’EAA. v(DefAttri), la valeur des défini-tions d’attributs fournit le type de l’attribut et ses cardinalités minimales et maxima-les. La cardinalité minimale d’un attribut représente le nombre minimal d’occurrences de valeurs pour l’attribut qu’un EA doit instancier pour être valide. La cardinalité

E-SIA

89

maximale représente le nombre maximal d’occurrences de valeurs d’attributs de ce type que les EA dérivés pourront instancier. Par exemple l’EAA-2 de la Figure 35 se décrit : < (TypeESIA,EAA), (ID,EAA-2), (Nom,Flux), (Def_Titre,Titre_1_1), (Def_Compression, Compression_0_1), (Def_ImageClé, ImageClé_0_n)>. Cet EAA définit le terme Flux qui devra avoir obligatoirement un et un seul titre (oc-currences : 1,1), dont nous pourrons préciser la compression (occurrences : 0,1), et éventuellement plusieurs images clés (occurrences : 0,n).

3.4.2.c) Eléments d’annotation (EA).

Un élément d’annotation est l’instance d’un terme associé à un fragment de docu-ment. C’est un n-uplet. < (TypeESIA,EA), (ID,v(ID)), (Nom, v(Nom)), (Attr1,v(Attr1)), … (Attrn,v(Attrn))> Un EA représente une instance d’un élément d’annotation abstrait (EAA). Son attribut Nom a pour valeur le terme de caractérisation de l’EA, ce nom corres-pond au nom de l’EAA dont l’EA dérive. Par exemple un EA dérivé de l’EAA donné en exemple dans la section 3.4.2.b) doit avoir un attribut Nom qui a comme valeur Flux. Les attributs sont définis dans l’EAA dont l’EA dérive. Leur nombre respecte les car-dinalités définies dans l’EAA. Ci dessous, un exemple d’EA dérivant de l’EAA-2 (Figure 35) : < (TypeESIA,EA), (ID,EA-142), (Nom, Flux), (Titre, Tour du Lyonnais), (Compression, avi DivX 4.0), (ImageClé, http://ESIA.net/image1.jpg, http://ESIA.net/image2.jpg)>


90

UAV1

EA: FluxType : EAID: EA-142Nom : FluxTitre : Tour du LyonnaisCompression: avi DivX 4.0Image Clé : http://ESIA.net/image1.jpg, http://ESIA.net/image2.jpg

Ra

EAA:FluxType : EAAID: EAA-2Nom : FluxDef_Titre : Titre_1_1Def_Compression: Compression_0_1Def_Image clé : Image Clé_0_n Rif

Rd

Ra-1

Type : UAVID: UAV-32IdentificateurFlux: http://ESIA.net/videos/course1.mpgBornesTemporelles : 2340_10030

Figure 35 Un fragment du graphe d’annotations avec des nœuds de type : UAV, EA et EAA, re-présentés avec leurs attributs et les relations qui les lient.

3.4.2.d) Dimension d’analyse (DA).

Une dimension d’analyse est représentée par : < (TypeESIA,DA), (ID,v(ID)), (Nom, v(Nom)), (Description, v(Description))> L’attribut Description peut servir pour fournir un commentaire sur les raisons de mise en place de la dimension d’analyse. Un exemple est donné par la DA suivante : < (TypeESIA,DA), (ID,DA-12), (Nom, Victime), (Description, Personnes figurant comme victimes d’accidents)>

3.4.2.e) Schéma de description (SD).

Un schéma de description est représenté par : < (TypeESIA,SD), (ID,v(ID)), (Nom, v(Nom)), (Description, v(Description))>

E-SIA

91

Le schéma de description représente un objet E-SIA qui permet de contraindre et de documenter l’annotation d’un flux. Dans l’attribut Description nous pouvons préciser le rôle et les propos du schéma. Par exemple : < (TypeESIA,SD), (ID,SD-12), (Nom, Premier secours), (Description, schéma pour la mise en place d’un secouriste qui effectue des opérations sur une victime)>

3.4.2.f) Représentants de dimensions d’analyse (RDA).

Un représentant de dimension d’analyse est représenté par : < (TypeESIA,RDA), (ID,v(ID)), (Nom, v(Nom)) (card_rel1,v(card_rel1)), … (card_reln,v(card_reln))>. Un RDA représente une dimension d’analyse dans un schéma de description (SD). Il reprend les caractéristiques minimales de la DA. Le Nom d’un RDA est identique au nom de la dimension d’analyse représentée. Les attributs de type card_rel1 indiquent les cardinalités des relations de schéma de des-cription. Les RDA reliés à un schéma de description forment un graphe. Les annotations se font en suivant un schéma de description. Le graphe des RDA définit la structure que les annotations devront avoir, comme présenté dans la section 3.3.4.c). Comme exemple, nous pouvons considérer le RDA suivant : < (TypeESIA,RDA), (ID,RDA-11), (Nom, Secouriste), (card_relRe,RDA-12_Re_1_1), (card_relRcontient,RDA-12_Rcontient_1_1)> Ce RDA, illustré sur la Figure 36, représente la dimension d’analyse ayant le nom : Victime, il est en relation élémentaire de schéma de description (Re_SD) avec le RDA-12 :Opération.


92

SD-1 Premier Secours 1

RDA-11: Secouriste

RDA-13: Victime

RDA-12: Opération

Re_SD

ReSD

Rcont Rcont

Rcont

1,n

1,1

1,1

1,n

Rcontient_SD

1,n

1,1

RDA-14: Image Clé

Rcont

Ra_SD

1,10,n

0,n

1,1 Re_SD

Figure 36 Exemple d’un schéma de description avec les RDA définissant le graphe de structure

d’annotations

Les cardinalités 1,1 expriment le fait que lors d’une annotation selon le schéma de description SD-1, dont RDA-11 fait partie, tout EA jouant le rôle d’opération, doit être en relation élémentaire avec exactement un et un seul EA jouant le rôle de secou-riste. Cette relation élémentaire exprime le fait que toute opération ne peut être effec-tuée que par un seul secouriste. La relation de contenance temporelle (Rcontient_SD) qui relie les RDA-11 et RDA-12 exprime le fait que le fragment de document annoté par un EA jouant le rôle d’opération doit être contenu dans un fragment annoté par un EA jouant le rôle de se-couriste. Dans cette section nous avons décrit les attributs spécifiques que les différents objets E-SIA doivent avoir. Le but était de donner la forme syntaxique des objets.

3.4.3. Contraintes sur les objets et relations

Cette partie précise la sémantique des objets du modèle. Le graphe G respecte un en-semble de contraintes C. Ces contraintes sont les suivantes (voir Figure 37 pour des illustrations) :

3.4.3.a) C1 (contraintes sur les relations) :

Soit r une arête de G. Les contraintes sur les étiquettes des relations en fonction du type des nœuds reliés sont représentées dans le Tableau 2. Les colonnes représentent pour une relation r∈R le numéro de contrainte, le type du nœud source, le type du nœud cible et l’étiquette de la relation ainsi contrainte. Ces contraintes sont formali-sées et expliquées par la suite.

N° C1.1 C1.2 C1.3 C1.4 C1.5 C1.6 C1.7 C1.8 C1.9 Type α(r) EA UAV EA EA EAA EAA EA DA DA Type β(r) UAV EA EA EAA EA EAA DA EAA RDA ν(r) Ra Ra

-1 Re , Re-1 Rd Rif Rabs,Rspec Rapp Rapp

-1 Rrep

E-SIA

93

N° C1.10 C1.11 C1.12 C1.13 C1.14 C1.15 Type α(r) RDA SD RDA RDA EA RDA Type β(r) DA RDA SD EA RDA RDA ν(r) Rrep

-1 Rcont Rcont-1 Rr

-1 Rr Rx_SD ∈ESD :Relations de schéma de description28

Tableau 2 contraintes sur les étiquettes d’une relation r∈R en fonction du type des nœuds reliés

- Ra Relation d’annotation

Si TypeESIA(α(r))= EA et TypeESIA(β(r))= UAV, alors ν(r)=Ra. Un nœud de type EA et un nœud de type UAV sont reliés par une relation éti-quetée Ra. Un élément d’annotation annote un fragment représenté par une uni-té audiovisuelle. Cela se traduit par l’existence d’une relation d’annotation Ra entre le nœud de type EA et le nœud de type UAV.

- Ra-1 Relation d’annotation inverse

Si TypeESIA(α(r))= UAV et TypeESIA(β(r))= EA, alors ν(r)=Ra-1.

Un nœud de type UAV est relié à un nœud de type EA par une relation d’annotation inverse Ra

-1.

- Re et Re

-1 Relation élémentaire et relation élémentaire inverse Si TypeESIA(α(r))= EA et TypeESIA(β(r))= EA, alors ν(r)∈{Re,Re

-1}. Les nœuds de type élément d’annotation (EA) peuvent être reliés par des rela-tions élémentaires (Re), ou leurs relations inverses (Re

-1).

- Rd Relation de décontextualisation Si TypeESIA(α(r))= EA et TypeESIA(β(r))= EAA, alors ν(r)=Rd .

Les nœuds de type élément d’annotation (EA) sont reliés aux nœuds de type élément d’annotation abstrait (EAA) par des relations de décontextualisation Rd.

- Rif Relation d’inscription dans le flux Si TypeESIA(α(r))= EAA et TypeESIA(β(r))=EA, alors ν(r)=Rif .

Les nœuds de type élément d’annotation abstrait (EAA) sont reliés aux éléments d’annotation (EA) par des relations d’inscription dans le flux Rif.

- Rabs, Rspec Relation d’abstraction et de spécialisation Si TypeESIA(α(r))= EAA et TypeESIA(β(r))=EAA, alors ν(r)∈{Rabs, Rspec} .

Les éléments d’annotation abstraits (EAA) sont reliés aux nœuds de type élé-ment d’annotation abstrait (EAA) par des relations d’abstraction ou de spéciali-sation Rabs, Rspec.

28 ESD={Ra_SD, Ra_SD-1, Re_SD,Re_SD

-1, Rcontains_SD, Rduring_SD, Rstarts_SD, Rstarted_by_SD, Rbefore_SD, Rafter_SD, Rmeets_SD, Rmet_by_SD, Rfinishes_SD, Rfinished_by_SD, Roverlaps_SD, Roverlapped_by_SD, Requals_SD }


94

- Rapp Relation d’appartenance à une DA Si TypeESIA(α(r))= EAA et TypeESIA(β(r))=DA, alors ν(r)=Rapp .

Les nœuds de type élément d’annotation abstrait (EAA) sont reliés aux nœuds de type dimension d’analyse (DA) par des relations d’appartenance Rapp.

- Rapp

-1 Relation d’appartenance inverse à une DA Si TypeESIA(α(r))= DA et TypeESIA(β(r))=EAA, alors ν(r)=Rapp

-1. Les nœuds de type dimension d’analyse (DA) sont reliés aux nœuds de type élément d’annotation abstrait (EAA) par des relations d’appartenance inverses Rapp

-1. - Rrep Relation de représentation de DA

Si TypeESIA(α(r))= DA et TypeESIA(β(r))=RDA, alors ν(r)=Rrep . Les nœuds de type dimension d’analyse (DA) sont reliés aux nœuds de type re-présentant de dimension d’analyse (RDA) par des relations de représentation Rrep .

- Rrep

-1 Relation de représentation inverse de DA Si TypeESIA(α(r))= RDA et TypeESIA(β(r))=DA, alors ν(r)=Rrep

-1 . Les nœuds de type représentant de dimension d’analyse (RDA) sont reliés aux nœuds de type dimension d’analyse (DA) par des relations de représentation in-verses Rrep

-1 .

- Rcont Relation de contenance d’un SD Si TypeESIA(α(r))= SD et TypeESIA(β(r))=RDA, alors ν(r)=Rcont .

Les nœuds de type schéma de description (SD) sont reliés aux nœuds de type représentant de dimension d’analyse (RDA) par des relations de contenance Rcont .

- Rcont

-1 Relation de contenance inverse Si TypeESIA(α(r))= RDA et TypeESIA(β(r))=SD, alors ν(r)=Rcont

-1 . Les nœuds de type représentant de dimension d’analyse (RDA) sont reliés aux nœuds de type schéma de description (SD) par des relations de contenance in-verse Rcont

-1. - Rr Relation de rôle

Si TypeESIA(α(r))= EA et TypeESIA(β(r))=RDA, alors ν(r)=Rr. Les nœuds de type élément d’annotation (EA) sont reliés aux nœuds de type re-présentant de dimension d’analyse (RDA) par des relations de rôle Rr.

- Rr

-1 Relation de rôle inverse Si TypeESIA(α(r))= RDA et TypeESIA(β(r))=EA, alors ν(r)=Rr

-1 . Les nœuds de type représentant de dimension d’analyse (RDA) sont reliés aux nœuds de type élément d’annotation (EA) par des relations de rôle Rr.

- RSD Relations de schéma de description (un SD est un ensemble de RDA)

Si TypeESIA(α(r))= RDA et TypeESIA(β(r))=RDA, alors ν(r)∈{Ra_SD, Ra_SD-1,

Re_SD,Re_SD-1, Rcontains_SD, Rduring_SD, Rstarts_SD, Rstarted_by_SD, Rbefore_SD, Rafter_SD, Rmeets_SD,

Rmet_by_SD, Rfinishes_SD, Rfinished_by_SD, Roverlaps_SD, Roverlapped_by_SD, Requals_SD }.

E-SIA

95

Les nœuds de type représentant de dimension d’analyse (RDA) sont reliés entre eux par des relations de schéma de description. Ces relations sont de la forme Rx_SD où x∈{a,e,ν(relation temporelle d’Allen)}, voir section 3.3.4.c).

Une arête ne peut relier que deux sommets de types cités ci dessous : ∀r∈R : (TypeESIA(α(r)), TypeESIA(β(r))) ∈ { (UAV,EA), (EA,UAV), (EA,EA), (EA,EAA), (EAA,EA), (EAA,EAA), (EAA,DA), (DA,EAA), (DA,RDA), (RDA,DA), (RDA,RDA), (RDA,SD), (SD,RDA), (EA,RDA), (RDA,EA) } Par exemple : une unité audiovisuelle (UAV) ne peut être reliée directement qu’à un élément d’annotation (EA) ; un élément d’annotation (EA) peut être relié à une unité audiovisuelle (UAV), à un autre élément d’annotation (EA), à un élément d’annotation abstrait (EAA) ou à un représentant de dimension d’analyse (RDA). Il est impossible par exemple de relier directement un sommet de type UAV à un sommet de type SD.

RaRa

RaRa

Ra

Ra Ra

Ra RaRa

SD RDA DA EAA EA UAV

Rr

Rr

Rr

Rr

Rr

Rr

Rr

Rr

RrRr

Rif

Rif

Rif

Rif

Rif

Rif

Rif

RifRif

Rif

Rpec

Rpec Rpec

Rpec

RappRappRapp

Rapp

Rapp

Rapp

RappRapp

Re

Re

Re

Re

Re

Re Re

Re

Re

ReRe

Re

Rrep

Rrep

RrepRrepRrep

RcontRcontRcont

Rcont

Rcont

RSDRSD

RSD

Figure 37 Illustration de différentes relations qui peuvent exister entre les nœuds du graphe


96

3.4.3.b) C2 (Contrainte d’existence d’annotation UAV/EA) :

∀o∈O, si TypeESIA(o) =UAV alors ∃ r∈R tel que α(r)=o et ν(r)=Ra. Tout nœud de type UAV est en relation d’annotation (Ra) avec au moins un nœud de type EA, c’est à dire, toute unité audiovisuelle est annotée par au moins un élé-ment d’annotation.

3.4.3.c) C3 (Contrainte d’unicité de fragment annoté EA/UAV) :

∀o∈O, si TypeESIA(o) =EA alors ∃! r∈R tel que α(r)=o et ν(r)=Ra-1.

Tout nœud de type EA est en relation d’annotation inverse (Ra-1) avec uniquement

un nœud de type UAV, c’est à dire, un élément d’annotation n’annote qu’une seule unité audiovisuelle.

3.4.3.d) C4 (Contrainte d’unicité de terme abstrait EAA/EA) :

∀o∈O, si TypeESIA(o)=EA alors ∃! r∈R tel que α(r)=o et ν(r)=Rd. De plus Nom(o)=Nom(β(r)).

Tout nœud de type EA est en relation de décontextualisation (Rd) avec exactement un nœud de type EAA ayant le même nom, tout élément d’annotation instancie un seul élément d’annotation abstrait.

3.4.3.e) C5 (Contrainte de connexité du vocabulaire) :

∀o∈O, si TypeESIA(o)=EAA et Nom(β(r))≠’EAA_All’ alors ∃! r∈R tel que α(r)=o et ν(r)=Rabs et Nom(β(r))=’EAA_All’

Tout nœud de type EAA est en relation d’abstraction (Rabs) avec un nœud de type EAA, nommé ‘EAA_All’, c’est à dire, il existe un terme (‘EAA_All’, terme géné-rique) dans le vocabulaire qui est relié à tous les autres.

3.4.3.f) C6 (Contrainte de non vacuité d’une DA DA/EAA) :

∀o∈O, si TypeESIA(o)=DA alors ∃ r∈R tel que α(r)=o et ν(r)=Rapp-1.

Tout nœud de type DA est en relation d’appartenance inverse (Rapp-1) avec au

moins un nœud de type EAA, c’est à dire, toute dimension d’analyse contient au moins un terme.

3.4.3.g) C7 (Contrainte d’unicité de représentation RDA/DA) :

∀o∈O, si TypeESIA(o)=RDA alors ∃! r∈R tel que α(r)=o et ν(r)=Rrep. Tout nœud de type RDA est en relation de représentation (Rrep) avec exactement un nœud de type DA, c’est à dire, un représentant de dimension d’analyse repré-sente une seule dimension d’analyse.

3.4.3.h) C8 (Contrainte d’unicité de contenance inverse RDA/SD) :

∀o∈O, si TypeESIA(o)=RDA alors ∃! r∈R tel que α(r)=o et ν(r)=Rcont-1.

Tout nœud de type RDA est en relation de contenance inverse (Rcont-1) avec uni-

quement un nœud de type SD, c’est à dire, tout représentant de dimension d’analyse appartient à un seul schéma de description.

E-SIA

97

3.4.3.i) C9 (Contrainte de non vacuité d’un SD SD/RDA) :

∀o∈O, si TypeESIA(o)=SD alors ∃ r∈R tel que α(r)=o et ν(r)=Rcont. Tout nœud de type SD est en relation de contenance (Rcont) avec au moins un nœud de type RDA, c’est à dire, tout schéma de description contient au moins un repré-sentant de dimension d’analyse.

Définition 3 : sous-grapheSD Nous désignons sous-grapheSD(oSD), le sous-graphe du graphe G formé par l’ensemble de nœuds de type RDA reliés à un même nœud de type SD (oSD)et les arêtes qui relient ces som-mets. sous-grapheSD(oSD) = <O1,R1,α,β,ν> où O1 = { o’ : ∃ r∈R tel que (ν(r)=Rcont et α(r)=oSD et β(r)=o’) } R1 = { r’ : α(r’)∈O1 et β(r’)∈O1 }

3.4.3.j) C10 (Contrainte de connexité des sous-graphes SD) :

∀o∈O, si TypeESIA(o)=SD alors sous-grapheSD(o) est un graphe connexe.

Un schéma de description définit un sous-graphe connexe de représentants de di-mensions d’analyse (RDA). Deux sous-grapheSD sont présentés sur la Figure 38.




SD Premier Secours 1

RDA: Secouriste1 RDA: Victime1

RDA: Opération1

ReSD ReSD

Rcont RcontRcont

1,n

1,1 1,1

1,n

Rrep Rrep Rrep

RappRappRapp

Rapp

Rapp

Rcontient_SD 1,n

1,1

RDA: Image Clé

Rcont

Rrep

ImageClé

DA: ImageClé

Rapp

RaSD1,1

0,n

0,n1,1ReSD

EAA 1

DAG

SDG

RDA: DAG1

Rcont

Rrep

Rapp

EAA 2

Rapp

EAA 3

Rapp

EAA4

Rapp

EAA n-1

Rapp EAA nRapp

…..

0,nReSD

0,nRDA: DAG

Rcont

Rrep

sous-grapheSD définis par :SD Premier Secours 1 et SDG

Figure 38 Sous graphes définis par les schémas de description

3.4.3.k) C11 (Contrainte de lien RDA/EA) :

∀o∈O, si TypeESIA(o)=EA alors ∃ r∈A tel que α(r)=o et ν(r)=Rr. Tout nœud de type EA est en relation de rôle (Rr) avec au moins un nœud de type RDA qui désigne la dimension d’analyse dont l’EA est issu. Le RDA précise le rôle de l’EA. Un EA peut avoir plusieurs rôles dans le cas où il a été réutilisé lors d’une annotation.

3.4.3.l) C12 (Contrainte d’unicité des relations) :

∀ r1,r2∈(R×R), si α(r1)=α(r2) et β(r1)=β(r2) alors ν(r1)≠ν(r2). Deux sommets ne peuvent être reliés par deux arêtes de même type.


98

Définition 4 : relations inverses Toute type de relation ν(r)∈E a son type de relation inverse ν(r)-1. Soient : E1={Ra, Re, Rd, Rabs, Rapp, Rrep, Rcont, Rr, Ra_SD, Re_SD, Rcontains_SD, Rstarts_SD, Rbefore_SD, Rmeets_SD, Rfinishes_SD, Roverlaps_SD, Requals_SD } et E2={Ra

-1, Re-1, Rif, Rspec, Rapp

-1, Rrep-1, Rcont

-1, Rr-1,Ra_SD

-1, Re_SD-1, Rduring_SD, Rstarted_by_SD,

Rafter_SD, Rmet_by_SD, Rfinished_by_SD, Roverlapped_by_SD, Requals_SD } ∀i∈[1..17], E1[i]=E2[i]-1. Par exemple Rd est la relation inverse de Rif, ou Roverlaps_SD est la relation inverse de Roverlap-

ped_by_SD. Le Tableau 3 présente dans ses colonnes les étiquettes des relations inverses. Ra Re Rd Rabs Rapp Rrep Rcont Rr Ra_SD Re_SD Rcontains_SD Ra

-1 Re-1 Rif Rspec Rapp

-1 Rrep-1 Rcont

-1 Rr-1 Ra_SD

-1 Re_SD-1 Rduring_SD

Rstarts_SD Rbefore_SD Rmeets_SD Rfinishes_SD Roverlaps_SD Requals_SD Rstarted_by_SD Rafter_SD Rmet_by_SD Rfinished_by_SD Roverlapped_by_SD Requals_SD

Tableau 3 Etiquettes de relations et les étiquettes des relations inverses

3.4.3.m) C13 (Contrainte de dualité des relations) :

∀r1∈R ∃! r2∈R tel que α(r1)=β(r2) et β(r1)=α(r2) et ν(r1)=ν(r2)-1. Chaque relation entre un couple de nœuds possède son inverse.

3.4.3.n) C14 (Contrainte de conformité des annotations à un SD) :

Toute annotation doit être conforme avec un schéma de description. Pour pouvoir formaliser cette contrainte l’introduction de quelques notations et des définitions sont nécessaires :

Notation 3 : cardmin(ν(rSD),ID(α(rSD)),ID(β(rSD))), cardmax(ν(rSD),ID(α(rSD)),ID(β(rSD))),

Nous notons de cette manière la cardinalité minimale/maximal de relation SD, pour une rela-tion SD : rSD, de type ν(rSD) et pour les identificateurs des nœuds qu’elle relie ID(α(rSD)), ID(β(rSD)). Par exemple : si rSD est la relation Re_SD, reliant le nœud RDA-11 au nœud RDA-12 de la Figure 36, alors cardmin(Re_SD,RDA-11,RDA-12)=1 cardmax(Re_SD,RDA-11,RDA-12)=1 si rSD est la relation Re_SD

-1, reliant le nœud RDA-12 au nœud RDA-11 de la même figure, alors cardmin(Re_SD

-1,RDA-12,RDA-11)=1 cardmax(Re_SD

-1,RDA-12,RDA-11)=n

Notation 4 : r_dérivée(rx_SD) Une relation r reliant deux nœuds de type EA est dite relation dérivée d’une relation de sché-ma de description r_dérivée(rx_SD) si

∃ rr1, rr1∈R, tel que α(rr1)=α(r), β(rr1)=α(rx_SD), α(rr2)=β(r), β(rr1)=β(rx_SD) et α(r),β(r) satisfont les contraintes sur les étiquettes imposées par rx_SD, c’est à dire :

si ν(rx_SD)=Rx_SD où Rx_SD est une étiquette de relation de schéma de description (voir la sec-tion 3.4.3.a)) alors ν(r)=Rx. Si la relation est temporelle alors les EA satisfont les contraintes

temporelles.

E-SIA

99

Définition 5 : sousgrapheEA(oSD) Le sousgrapheEA d’un objet de type SD est un graphe qui contient des éléments d’annotation en conformité avec le schéma de description. Nous considérons une annotation conforme à un schéma de description, quand les éléments d’annotation et les relations mises en jeu lors de cette annotation correspondent aux contrain-tes définies dans le schéma de description. Une annotation se fait toujours selon un schéma de description. Le schéma de description dé-finit la structure des annotations, il constitue une sorte de méta annotation. Soit sg_ann=<Oann, Rann> un sous graphe de G tel que ∀o∈sg_ann, TypeESIA(o)=EA. sg_ann contient des annotations. Soit oSD∈G tel que TypeESIA(oSD)=SD, un schéma de des-cription. Nous disons que sg_ann représente un graphe d’annotations conforme à oSD ou en-core que sg_ann est un sousgrapheEA(oSD) si : Tout élément d’annotation a un rôle défini dans le schéma de description. Tout EA du sg_ann est relié à un RDA su sougrapheSD(oSD) par une relation de rôle (Rr).

∀o∈Oann, ∃ r∈R, tel que α(r)=o et β(r)∈sousgrapheSD(oSD). Toute relation élémentaire du sg_ann est définie dans le schéma de description.

∀r∈Rann, ∃r’∈sousgrapheSD(oSD) tel que si EA1=α(r) et EA2=β(r) et RDA1=α(r’) et RDA2=β(r’) alors ∃r1,r2∈R, tel que ν(r1)=ν(r2)=Rr et α(r1)=EA1, β(r1)=RDA1 et α(r2)=EA2,

β(r2)=RDA2. Pour toute relation du schéma de description, les contraintes sur les étiquettes de sommets re-liés sont respectées dans sg_ann.

∀r∈sg_ann, ∃ rx_SD∈ sousgrapheSD(oSD), tel que r est r_dérivée(rx_SD) Pour toute relation du schéma de description, les contraintes sur les cardinalités de sommets reliés sont respectées dans sg_ann.

∀oRDA∈sousgrapheSD(oSD), ∀rSD tel que α(rSD)=oRDA, si

oEA1 est un élément d’annotation tel que ∃rr, tel que ν(rr)=Rr, α(rr)=oEA1 et β(rr)=oRDA si

oEA2 est un élément d’annotation tel que ∃rr, tel que ν(rr)=Rr, α(rr)=oEA2 et β(rr)=β(rSD) et si

RRDA={r | α(r)=oEA1 et β(rr)=oEA2} alors

cardmin(ν(rSD),ID(α(rSD)),ID(β(rSD))) ≤ |RRDA| ≤ cardmax(ν(rSD),ID(α(rSD)),ID(β(rSD))) Formellement la contrainte C14 donne la condition suivante :

∀oEA∈G, si TypeESIA(oEA)=EA, alors ∃ oSD∈G, tel que : TypeESIA(oSD)=SD et oEA∈sousgrapheEA(oSD)

Il est impossible d’annoter sans satisfaire les contraintes imposées par un SD. Si toutes ces contraintes sont respectées, alors le graphe global G est un graphe E-SIA valide, qui est connexe par définition.

3.4.4. Les graphes potentiels

La notion de graphe potentiel a été introduite par Y. Prié [Prié et al. 2000]. Un graphe potentiel exprime un contexte générique dans le graphe G. Il permet également d’exprimer des requêtes. En effet des nœuds du graphe potentiel peuvent être généri-ques, et comparables à des nœuds du graphe global. Un graphe potentiel s’instancie


100

ainsi dans le graphe global, fournissant des résultats à la requête qu’il représente. Formellement, un graphe potentiel est défini comme :

GP=<OGP,RGP,α,β,EGP,ν,Lfc> Avec :

- OGP : l’ensemble de sommets, objets génériques de Gp, - RGP⊆OGP x OGP est l’ensemble des relations du modèle E-SIA (relations bi-

naires et orientés)

- α :RGP→OGP est une fonction qui à qui à chaque arête r∈RGP associe son sommet d’origine α(r)

- β :RGP→OGP est une fonction qui à qui à chaque arête r∈RGP associe son sommet de but β(r)

- EGP : l’ensemble d’étiquettes de relations de graphe potentiel - ν :RGP→EGP est une fonction qui associe à chaque arête r∈RGP une étiquette

ν(r) - Lfc : La liste de fonctions de comparaison

Définition 6 : Fonction de comparaison fcτ Une fonction de comparaison, permet de comparer deux attributs de même type.

fcτ:(TV X TV)→{0,1} Ces fonctions interprètent les valeurs, les comparent selon une méthode et retournent un résul-tat de similarité qui est égal à 1 si les deux valeurs sont considérées similaires et 0 sinon. Il est possible de comparer les valeurs de 2 attributs de même type, selon plusieurs méthodes. Nous notons τ(fcτ) le type des attributs comparés par la fonction fcτ.

Définition 7 : Liste de fonctions de comparaison Lfc Lfc note la liste de tous les fonctions de comparaison. Lfc(τ) est une liste de fonctions de comparaison des valeurs de deux attributs de type τ. Par exemple si l’ensemble de types d’attributs est défini comme : TA = {Nom, Date, URLImage29}, nous pouvons définir : IV(Nom) = l’ensemble de chaînes de caractères de moins de 256 caractères ; IV(Date) = l’ensemble des dates codées selon le format : [aaaa-mm-jj] ; IV(URLImage) = l’ensemble des nom d’URL possibles. Nous pourrons considérer alors des attributs tels a1=(Nom, Virenque), a2=(Date, 2002-08-25) ou a3=(URLImage,http://esia.net/images/image1.jpg). Dans notre exemple la liste de fonctions de comparaison pour le type d’attribut Nom est : Lfc(Nom)={fcNom_exacte(as1, as2), fcNom_contenu(as1, as2), fcNom_commençant_par(as1, as2)} où as1 et as2 sont des valeurs de type Nom tel que : as1, as2∈IV(Nom).

29 URL : Universal Resource Locator

E-SIA

101

fcNom_exacte(as1,as2)=1 si as1 et as2 sont par exemple des chaînes de caractères identiques. fcNom_exacte(as1,as2)=0 sinon ffcNom_contenu(as1,as2)=1 si as1 contient as2. fcNom_contenu(as1,as2)=0 sinon. Par exemple : fcNom_contenu(abcd,bcd)=1 fcNom_commençant_par(as1,as2)=1 si as1 commence par as. Sinon fcNom_commençant_par(as1,as2)=0. Par exemple : fcNom_commençant_par(abcd,abc)=1. Il est possible d’imaginer pour les types d’attribut URLImage des fonctions qui comparent l’adresse des images, comme des chaînes de caractères, des fonctions qui vont chercher le contenu des images et les comparer pixel par pixel ou encore des fonctions qui calculent les histogrammes de couleurs de ces images et comparent ensuite ces valeurs numériques…

3.4.4.a) Les objets génériques, sommets du graphe potentiel

Un sommet du graphe potentiel est appelé également objet générique og. Il est carac-térisé par un ensemble d’attributs aj et par une méthode de comparaison mc.

OGP = { ogi, i∈[1..m]}. ogi=<{aj},mc>=<{(τj,vj)},{Lfc(τk)}>; τj∈TA, vj∈IV(τj), j∈[1..n]

Un nœud de graphe potentiel peut avoir un attribut caractérisation permettant de donner un nom spécifique au nœud au sein su graphe potentiel. La caractérisation sert à faire référence de manière intuitive pour un utilisateur humain, au nœud, en faisant abstraction de son identificateur généré automatiquement. En pratique la liste des nœuds correspondants dans le graphe global à un nœud de graphe potentiel est récu-pérée en donnant la caractérisation du nœud de graphe potentiel. Par exemple les nœuds correspondants au nœud N1 (N1 est la caractérisation) du graphe potentiel de la Figure 39 sont les nœuds UAV-1, UAV-2 et UAV-3. La méthode de comparaison mc est formée d’un ensemble de listes de fonctions de comparaison. Elle sert à comparer l’objet générique à des objets du graphe global. Lors de la comparaison d’un objet générique à un objet du graphe global, toutes les fonctions de la méthode de comparaison de l’objet générique sont évaluées. Si les deux objets ne contiennent pas des attributs de types prévus par les fonctions ils sont considérés non similaires, sinon les valeurs sont comparées et si toutes sont ju-gées similaires, alors les objets le sont aussi. La fonction de comparaison d’un objet générique à un objet du graphe global est illustrée par l’Algorithme 1. Fonction ComparaisonDeuxNoeuds(og,o)

Pour tout fc ∈ og.mc Si fc(vog(τ(fc),vo(τ(fc))=0 alors Retourner 0 Fin pour Retourner 1

Algorithme 1 comparaison d’un objet générique og et un objet o du graphe global

Tout objet ogi∈OGP est muni d’au moins un attribut de type ID_GP, désignant un identificateur unique du sommet représenté par l’objet dans le graphe potentiel. Dans la pratique, dans l’état actuel du modèle, les nœuds des graphes potentiel ont tous un attribut TypeESIA aussi.


102

3.4.4.b) Les arêtes de graphe potentiel

Les objets génériques définis auparavant sont reliés par un ensemble d’arêtes pour former un graphe connecté. Les arêtes sont orientées et étiquetées. L’ensemble des étiquettes de relations est défini comme : EGP={Ra, Ra

-1, Re, Re-1,Rd,Rif, Rabs, Rspec, Rapp, Rapp

-1,Rrep, Rrep-1, Rcont, Rcont

-1,Rr, Rr-1,

Ra_SD,Ra_SD-1,Re_SD,Re_SD

-1, Rcontains_SD, Rduring_SD, Rstarts_SD, Rstarted_by_SD, Rbefore_SD, Raf-

ter_SD, Rmeets_SD, Rmet_by_SD, Rfinishes_SD, Rfinished_by_SD, Roverlaps_SD, Roverlapped_by_SD, Re-

quals_SD, Rcontains, Rduring, Rstarts, Rstarted_by, Rbefore, Rafter, Rmeets, Rmet_by, Rfinishes, Rfinis-

hed_by, Roverlaps, Roverlapped_by, Requals, } ∀r∈RGP, ν(r)∈EGP.

Les arêtes des graphes potentiels étendent celles du graphe global. En plus des arêtes du graphe global, que l’on appelle des relations explicites, les sommets de type EA d’un graphe potentiel peuvent être reliés par des arêtes calculés. Ces arêtes expriment des relations temporelles entre les fragments de document (UAV) annotés par ces nœuds. Les 13 types d’arêtes de relations temporelles correspondent au type de rela-tions d’Allen [Allen 1983], présentés dans la section 3.3.4.c). Par exemple pour traduire la requête « trouver les séquences vidéo où Lt. Tonton ef-fectue une opération» nous construisons le graphe potentiel de la Figure 39. Les nœuds de départ sont le terme EAA Lt.Tonton et la dimension d’analyse DA Opéra-tion. Le nœud représentant l’unité audiovisuelle cherchée est N1. Ce nœud est un nœud caractérisé, représentant l’objet de notre requête.

EA: Vérification

Rif

Ra

EA: Massage

Rif

Ra

EA: Dégagement

Rif

Ra

Re

ReReReRe

Re




EA: Virenque

Rif

Ra

EA:Lt. Tonton

Rif

Ra

UAV-1

UAV-2

UAV-3 UAV-4 UAV-5

RappRappRapp

Rapp

Rapp

Lt Tonton

* *

*

DA: Opération

* N1N1

Rapp

RifRif

Re

Ra

Correspondances

de départ

Solutions

Graphe potentiel :trouver les séquences vidéo où Lt.

Tonton effectue une opération

Figure 39 Exemple d’un graphe potentiel et de ses correspondances dans le graphe

E-SIA

103

Une fois la requête traduite en graphe potentiel, nous recherchons les sous-graphes dans le graphe global qui lui sont isomorphes. L’instanciation du graphe potentiel dans le fragment de graphe global de la Figure 39 utilise un algorithme de multipro-pagation [Prié et al. 2000]. Les résultats sont illustrés sur la même figure par les sous graphes marqués par les formes foncées. Ici les UAV cherchées, correspondant au nœud N1 du graphe potentiel sont les : UAV-3, UAV-4 et UAV-5.


104

3.5. Discussion

Dans ce chapitre nous avons présenté un modèle d’annotation de documents audiovi-suels. Le modèle E-SIA met en place une organisation des annotations sous la forme d'un graphe et permet l'annotation et la recherche des documents annotés. Nous avons également mis en place une méthode robuste pour gérer un vocabulaire étendu et utilisé par plusieurs personnes ou plusieurs groupes. En introduisant les di-mensions d'analyse et les schémas de description nous laissons une liberté considéra-ble pour annoter, tout en permettant de documenter les diverses manières d'annoter. Des utilisateurs tiers peuvent avoir un aperçu rapide sur le vocabulaire et les structu-res utilisées pour annoter un ensemble de documents, les méta-données utilisées pou-vant être calculées et présentées dynamiquement. De cette manière, la construction de requêtes pertinentes devient plus rapide et le raffinement des requêtes plus efficace. Les utilisateurs novices sont libres d'annoter à leur guise, mais peuvent également s'encadrer dans les canons d'annotation déjà mis en place. De cette manière l'annota-tion est plus homogène et cohérente ce qui peut poser certes un problème d'ordre phi-losophique, mais facilite beaucoup l'exploitation de la base de documents annotés. Le modèle favorise en effet l’homogénéisation des manières de description ce qui peut être considéré comme une réduction de la créativité. Nous pensons néanmoins, que de point de vue de l’exploitation les avantages d’une description cohérente l’emportent sur la diversité. Le modèle E-SIA a été implanté dans un prototype avec les partenaires du projet dans lequel nos recherches se déroulaient (France Télécom R&D et INRIA). Ce prototype est présenté plus en détailles dans le chapitre 5. Pendant tout le déroulement de nos recherches nous avons suivi de près l’évolution du standard MPEG-7 [MPEG 2000]. La lenteur de la mise en place de la norme nous a néanmoins encourager de mener en parallèle nos travaux. Dans ses objectifs Mpeg-7 est assez proche de E-SIA. Les schémas de description E-SIA ainsi que l’ensemble des annotations peut être exporté dans un format MPEG-7. Alors que MPEG-7 se veut essentiellement un format d’échange et un standard de représentation des annotations, le modèle E-SIA définit une structure théorique qui permet de documenter et d’exploiter des annotations. Des schémas MPEG-7 peuvent à leur tour être intégrés dans le graphe E-SIA et devenir ainsi exploitables à l’aide des graphes potentiels. Dans le cadre du projet RECIS nous avons instrumentalisé un système d’annotation et d’exploitation de documents numériques ce qui peut être considéré comme une im-plantation de MPEG-7 qui est apparue néanmoins avec une légère avance que la norme elle-même. Le standard MPEG-7, comme présenté dans le chapitre 2.5 définit une syntaxe pour représenter des annotations et des schémas de description. Le modèle E-SIA reste plus générique, il n’y a pas d’énumération de types et descripteurs. Ce n’est pas non plus une structure dans lequel nous pouvons faire des inférences des héritages de ma-nière globale. E-SIA structure les descripteurs en graphe, il sépare par contre bien les annotations, le vocabulaire et les éléments de structure. Le modèle E-SIA met en place un outil d’exploitation, fournit donc une syntaxe, une sémantique, une opératio-nalisation et un prototype validant le modèle.

E-SIA

105

Comme nous allons voir dans le chapitre suivant, le modèle E-SIA a été étendu pour inclure en plus des annotations et schémas des éléments représentant leur manipula-tion devenant ainsi un modèle de système informatique. En ce qui concerne les perspectives, plusieurs pistes sont intéressantes à suivre. En effet, l’annotation et la recherche de documents reste un sujet très intéressant, le mo-dèle que nous avons mis en place constitue un bon point de départ qui nous a révélé une multitude de nouveaux problèmes à résoudre dont certains s’insèrent naturelle-ment dans la suite de nos études. Dans la suite nous allons évoquer quelques perspec-tives d’amélioration du modèle. Le modèle de description doit tendre vers un cadre qui permet l’annotation de tous types de fragments de documents. Il faudrait redéfinir pour cela les mécanismes d’ancrage des annotations dans le document. Des fragments tels les régions d’une image, un objet dans une vidéo doivent être identifiable. La norme XPointer [W3C 2002c] est à suivre. Dans ce cas les unités audiovisuelles deviendront une sorte de « objets audiovisuels » dans un premier temps, puis « fragments génériques ». Au niveau de la structure des annotations, la manipulation des schémas de description serait intéressant à étudier. Nous entendons par manipulation : la composition, la fu-sion, l’application ordonnée des schémas. Un ensemble de schémas de description avec l’ensemble de graphes potentiels qui ont été mis en place en s’inspirant de ces schémas avec des interfaces qui imposent un certain ordre dans l’annotation selon dif-férents schémas, qui permettent un affichage spécifique peut constituer un paquet que nous pourrons appeler service. Un service contient donc tous les éléments nécessaires à l’annotation et l’exploration des documents couvrant un certain sujet et peut être mis en place facilement sur le modèle E-SIA déjà existant. Toujours autour de la structuration du vocabulaire, il serait envisageable d’intégrer des structures externes (tel WordNet30) pour calculer des distances entre des termes et éventuellement faire des inférences de manière ponctuelle. Ces structures externes peuvent également aider à la construction de dimensions d’analyse et des schémas de description. Un autre axe de recherche peut s’orienter autour de l’analyse des résultats des requê-tes. En étudiant les résultats l’utilisateur peut avoir des idées sur la manière de préci-ser sa requête. Pour une meilleure représentation d’un grand nombre de résultats, on peut essayer de les regrouper selon plusieurs critères : définir des distances entre les sous graphes résultats, soit en rendant les fonctions de comparaison floues, qui per-mettent de classer des nœuds par leur similarité par rapport à cette fonction de simila-rité, soit en passant par l’étude des EAA en calculant les distances dans le vocabulaire (en utilisant par exemple le nombre de dimensions d’analyse dans lesquels deux EAA sont présents) entre eux.

30 http://www.cogsci.princeton.edu/~wn/index.shtml (2003)


106

Une idée dans cet aide à l’utilisateur dans sa tache de raffinement de requête est de regrouper les sous graphes résultats selon des critères de similarité (qui restent à défi-nir) en groupes (clustering). Eventuellement on peut considérer un certain seuil de nœuds différents, par sous graphe résultat (sGR), à partir duquel on dit que deux ré-sultats sont dans des groupes différents. En appliquant l’algorithme KNN ou M-KNN (Mutual K Nearest Neighbours) [Celeux et al. 1989] on pourra classer les sGR suivant plusieurs critères. Une solution représentative peut être alors choisie dans chaque groupe (préciser comment) et présentée à l’utilisateur. De même, l’utilisateur peut compléter sa requête par la partie commune des éléments d’un groupe d résultats.

Trèfle ♣

107

4. Modèle de traces d’utilisation Dans ce chapitre nous présentons notre modèle de traces d’utilisation appelé Trèfle♣ car il se base sur une structure de graphe en « trois feuilles » représentant les objets les procédés et les utilisateurs d’une application informatique. Après une description du principe, nous détaillons de manière générale les différentes parties du modèle et nous présentons son principe de fonctionnement : les démarches de modélisa-tion de l’application à assister, le traçage de l’utilisation et la phase de capitalisation et de réuti-lisation de l’expérience. Nous présentons ensuite l’application du modèle à un système d’annotation et de recherche de documents audiovisuels. L’ordinateur et plus généralement les systèmes informatiques en réseau sont utilisés pour des tâches extrêmement variées par un public de plus en plus large. Les « applications informatiques » généralistes31 sont devenues des supports de ces tâches et en particulier offrent l’accès à des ressources pour ces tâches (ressource = service délivrant des données, des connaissances, des traitements, …). La variabilité d’usage de ces logiciels pour des tâches très diverses par des publics très différents rend illu-soire la possibilité de développer des assistants qui a priori seront capables d’aider l’utilisateur dans sa tâche. En effet les systèmes permettent d’effectuer des tâches très complexes, en fournissant souvent un degré de liberté élevée aux utilisateurs. Par définition, donc, les concep-teurs de ces logiciels ne peuvent pas connaître précisément les tâches que leur outil va servir à exécuter. De plus la « démocratisation » des outils informatiques met entre les mains d’utilisateurs occasionnels des outils conçus pour permettre la manipulation de concepts et de méthodes mis au point par et pour des spécialistes. Bien que les ap-plications deviennent de plus en plus conviviales, les tâches pour lesquelles elles sont utilisées restent complexes. Ces applications sont utilisées par des utilisateurs ayant un degré d’expertise varié. Il est important donc que les interfaces et les applications sachent s’adapter, pour pouvoir être utilisées à leur meilleur rendement. Comme, les ordinateurs «n’oublient » pas, il est intéressant de garder les traces, convenablement modélisées, des sessions d’utilisation afin de pouvoir les réutiliser pour aider la réali-sation de nouvelles tâches. Ainsi, même dans le cas d’un système avec des possibili-tés infinies d’utilisations si on arrive à faire remonter des situations similaires, cela peut aider un utilisateur à réaliser sa propre tâche.

31 applications « bureautiques » typiquement…


108

Imaginons l’utilisation d’un système de traitement de texte. Nous voulons écrire un CV. C’est la première fois que nous avons cette tâche et nous ne savons pas très bien ce que ce genre de document doit contenir, ni du point de vue de la forme, ni de point de vue du contenu. Nous commençons par écrire un titre, préciser notre nom, âge et commençons par décrire nos expériences et notre formation. Imaginons maintenant que notre traitement de texte soit doté d’un système de capitalisation d’expérience, et qu’il ait été utilisé par plusieurs autres personnes (il a donc capitalisé leur expé-rience). Il peut alors, au bout de quelques lignes se rendre compte que nous sommes en train d’utiliser le logiciel de manière similaire à un autre épisode d’utilisation (probablement l’écriture d’un CV) et pourra nous proposer des exemples, faits par d’autres utilisateurs, et par exemple nous proposera de préciser au début également notre adresse, numéro de téléphone et email, et enfin nous proposer des styles de mise en forme. Après cet exemple de traitement de texte, considérons l’annotation de documents au-diovisuels. Dans ce cas il s’agit d’annoter des fragments de documents par des mots clés tirés d’un vocabulaire, tel que présenté dans le chapitre 3. Au début, cette tâche est ad-hoc et nous assignons des mots clés de manière personnelle et intuitive aux fragments de documents. Si le système est capable de capitaliser et de réutiliser l’expérience, il pourra guider l’annotation de manière à aboutir à des descriptions plus cohérentes et structurées de manière similaire. A partir des premiers mots clés posés, il peut retrouver d’autres documents annotés par ces mêmes mots ou par des mots similaires32 et proposer de compléter l’annotation en cours par les caractéristi-ques manquantes ou l’intégrer dans une des méthodes d’annotation prédéfinie. Les deux exemples évoqués illustrent deux manières d’aider la réalisation des tâches. L’aide dans ces cas ne se fait pas sur l’utilisation des outils, mais sur la réalisation des tâches, sur le contenu. Ce n’est pas l’utilisation de l’outil qui est facilitée mais des connaissances du domaine sont apportées pour aider la création des documents ou annotations. Le système cherche à réduire la complexité des tâches concrètes, lors de l’utilisation des outils qui laissent plusieurs degrés de liberté. L’aide porte sur les problèmes de type : « que faire ? » plutôt que sur des problèmes de type « comment faire ? ». Dans le cas du traitement de texte, la question n’est pas comment réaliser une mise en forme, mais quelle mise en forme réaliser, qu’écrire ? Dans le cas du système d’annotation, la difficulté majeure ne provient pas de la ma-nière d’utiliser l’outil, mais du contenu des documents, de la taille et richesse du vo-cabulaire et des schémas de description. Dans ce chapitre nous présentons un modèle qui permet la mémorisation des traces d’utilisation pour capitaliser l’expérience des utilisateurs et réutiliser cette expérience pour fournir de l’aide dans des situations non triviales, nécessitant de la créativité.

32 Similarité spécifique aux applications. Par exemple, dans RECIS deux mots clés (EAA) faisant partie de la même dimension d’analyse (DA) peuvent être considérés comme jouant le même rôle, donc similaires de ce point de vue.

Trèfle ♣

109

Notre modèle a pour vocation d’utiliser un paradigme tel que celui du raisonnement à partir de cas (RàPC) afin d’effectuer la réutilisation de l’expérience [Mille 1998]. Nous considérons, que dans une application informatique, des utilisateurs manipulent des objets à l'aide de procédés. Selon notre modèle nous mémorisons les traces de manipulation d’objets en représentant les sessions d’utilisation, les procédés et les ob-jets, tous étant connectés dans un graphe unique. Cela nous permet de mettre au point des techniques de réutilisation de l’expérience ainsi organisée.


110

4.1. Le modèle Trèfle♣

4.1.1. Présentation générale

L’ingénierie des connaissances étudie depuis longtemps le problème de la gestion et de la réutilisation de l’expérience d’utilisation d’un système informatique. Comme présenté dans le chapitre 2.7, plusieurs modèles de représentation de connaissances ont été mis au point [Bush 1945, Lehman et al. 1995, Charlet et al. 1996, Birnbaum et al. 1998, Chandrasekaran et al. 1998, Delgado et al. 1999, Dussaux et al. 2000, Farrell et al. 2000, Paternó 2000], traitant de la formalisation des tâches, profils de l’utilisateur, historiques de manipulations d’objets mais nous n’en avons pas trouvé qui tentait d’associer les trois points de vue dans un modèle unifié. Nous partons de l’idée que dans une application informatique, ce qui fait sens, c’est ce qui est interconnecté du point de vue de l'utilisateur lors de l’utilisation des objets disponibles. Au départ, cette interconnexion correspond33 à une intention34, tandis qu’au fur et à mesure des actions lors de l'utilisation de l'application elle se concrétise en un résultat35. L'utilisateur rend indirectement compte de ses différentes tâches en manipulant des objets à l’aide d’outils. Nous considérons que de manière générale l'utilisateur, lors d’une session d'utilisation d'une application informatique, manipule des objets, ces manipulations peuvent être décrites par des procédés (Figure 40). Un modèle de traçage et de gestion des utilisations est créé en se basant sur cette théorie. Nous proposons également des méthodes qui permettent de réutiliser l’expérience ainsi capitalisée pour aider les utilisateurs à réaliser des tâches répétiti-ves de manière semi-automatique, ou des tâches non triviales de manière assistée.

ObjetsUtilisateurs

Procédés

Figure 40 Schéma général du modèle Trèfle♣

33 Une interconnexion forme une signature de l’intention 34 L’intention exprime l’objectif à atteindre 35 Le résultat désigne l’objectif atteint

Trèfle ♣

111

4.1.1.a) Les objets

Dans l’ensemble des objets qui peuvent être manipulés, nous choisissons ceux qui forment le modèle d’utilisation.

Définition 8 : Modèle d’utilisation Le modèle d’utilisation contient l’ensemble d’objets que l’on a choisit d’observer parmi tous les objets qui peuvent être manipulés dans une application informatique ainsi que des relations qui peuvent le lier.

Ce sont des objets qui sont importants du point de vue de l’observation du système. Le modèle d’utilisation peut contenir également des relations entre les objets. Dans le cadre général nous appelons ces relations des : relations d’explication. Dans le mo-dèle Trèfle♣ actuel, nous nous résumons à des relations de type composi-tion/agrégation. Néanmoins nous pensons que d’autres types de relations reliant des objets peuvent avoir leur place dans un modèle d’utilisation. Dans le cas concret, dans les applications du modèle Trèfle♣ à des systèmes informa-tiques, les relations d’explication peuvent exprimer des liens de composition, d’appartenance ou toute autre relation entre des objets du système. Pour une application de traitement de texte (Figure 41), le modèle d’utilisation peut être par exemple composé de mots, phrases, paragraphes, figures, titres, modèles, do-cuments (Modèle générique, Modèle CV) et du document lui-même.

O:Document

O:Titre

O:Paragraphe générique

O:Phrase

O:Mot

O:Modèle CV

O:Paragr. Formation

O:Paragr. ExpériencesO:Paragr. Langues

O:Modèle générique

O:CaractèreRelation de contextualisation

O:zzz Objets

Figure 41 Exemple de modèle d’utilisation d’un traitement de texte

Dans ce cas les relations expriment le fait que des objets complexes sont composés d’objets moins complexes. Pour notre application de manipulation de documents audiovisuels les termes (EAA) et les différents éléments structurant le vocabulaire (DA, SD), peuvent être vus comme un modèle d’utilisation de cette application (Figure 42).


112

O:SD1

O:DA1

O:EAA_Lt. Tonton

O:SD2

O:EAA_Adjoint Pierre

O:DA3

O:EAA_Massage

O:EAA_Vérification

O:DA2

O:EAA_Dégagement

O:EAA_Homme en noirO:EAA_Cycliste

Relation de contextualisation

Objets

Figure 42 Exemple de modèle d’utilisation de notre application d’annotation de vidéos (RECIS)

Ici aussi, les relations sont des relations de composition : un SD est composé de DA. Une dimension d’analyse (DA) est composée d’éléments d’annotation abstraits (EAA). Lors de l'utilisation de l'application, les objets du modèle d'utilisation s'instancient, les instances reflétant les manipulations subies par des objets concrets à travers les actions de l'utilisateur. Pour notre application d’annotation de documents, nous considérons qu'un utilisateur peut créer, modifier, et visualiser36 un objet grâce à des procédés.

4.1.1.b) Les procédés

Si le modèle d’utilisation d’une application reprend tout ce qui peut être manipulé par un utilisateur (objets, états, opérations) alors un modèle de tâche serait défini par tout « ce qui fait sens » pour une tâche particulière. Nous appelons procédé, une manière d’utiliser les éléments d’un modèle d’utilisation pour un modèle de tâche plus spéci-fique. Nous l’appelons ainsi pour le différencier des modèles de tâches tels qu’ils sont définis en ingénierie des connaissances. Il s’agit d’un point de vue pragmatique sur les manipulations concrètes d’un système informatique. Nous pouvons représenter les différents liens entre procédés par des relations de dé-composition. Comme dans le cas des objets du modèle d’utilisation, la sémantique

36 La suppression des objets n’est pas prévu dans le modèle E-SIA. Dans Trèfle nous considérons que la suppression est une opération comme les autres, et le nœud représentant l’objet supprimé n’est pas effacé du graphe des traces, mais mis en relation avec le procédé qui représente la suppression, disparaissant ainsi de l’espace d’objets disponi-bles pour l’application.

Trèfle ♣

113

des relations entre procédés n’est pas prédéfinie. En général les relations de contex-tualisation expliquent le fait qu’un procédé est effectué dans le cadre d’un autre pro-cédé, ou que des procédés représentent une décomposition d’une tâche complexe en sous-tâches. Les procédés sont typiquement les actions accédées par des menus/ sous-menus, bou-tons ou icônes de l'interface graphique ou simplement en tapant des instructions. Les différents procédés disponibles au sein d'une application sont rarement entièrement indépendants les uns des autres. Par exemple dans RECIS, l'annotation d'un document suppose le choix d'un schéma de description, le choix des dimensions d’analyse et le choix des termes dans ces di-mensions d'analyse. La Figure 43 présente une représentation de cette décomposition.

P:Choisir DA

P:Choisir SD

P: Mettre en relation

P:Choisir EAA

P:zzz


Procédé

Figure 43 Un modèle de tâche de l’annotation d’un document dans RECIS

Dans un traitement de texte, la création d'un document passe par le choix d’un modèle de document (P :Choisir un modèle) et une suite de créations de paragraphes (P : Créer paragraphe) conformes au modèle. La Figure 44 présente deux décompositions arbitraires en procédés de ce modèle de tâches. Nous pouvons considérer que le pro-cédé de création de paragraphes se fait dans le cadre du procédé de choix de modèle, le choix de modèle se décompose donc en création de paragraphes, alors que le choix de modèle se fait dans le cadre de l’écriture de document. Nous pourrons également considérer que le procédé d’écriture de documents se décompose en procédés de choix de modèle et en procédés de création de paragraphes. Par soucie de lisibilité nous ne représenterons plus le sens des relations de décompo-sition, considérant que sur les figures les arcs partent toujours des procédés qui se trouvent au dessus.

P: Écrire un document

P: Créer des paragraphes

P:Choisir un modèle

P:zzz


ProcédéP: Écrire un document

P: Créer des paragraphes


Figure 44 deux décompositions d’un modèle de tâche de création d’un document dans un traite-

ment de texte

Nous considérons dans ces cas les procédés : choix de schéma de description, choix d’une dimension d’analyse, création d’un document texte, choix de modèle, etc. Les relations entre des procédés permettent d’exprimer le fait qu’un procédé soit lié d’une manière ou d’une autre à un autre procédé. Par exemple un procédé peut être lancé parce qu’un autre a déjà été exécuté. Nous pouvons nous servir des environne-ments de mise en place des modèles de tâches existants [Dukas 1998, Clarke 2001, Schreiber et al. 2001b, Protégé 2002] pour formaliser et construire des modèles de procé-


114

dés à tracer. Un modèle de procédés est un graphe contenant des nœuds représentant des procédés et des relations de décomposition qui les lient.

4.1.1.c) Les utilisateurs

Un utilisateur exploite des procédés à l’occasion d’une session d’utilisation. Notre objectif de réutilisation et de partage d’expérience donne à l’utilisateur une impor-tance singulière. Il pourrait s’agir d’un simple attribut d’une session d’utilisation mais il s’agit bien ici de tracer la session d’un utilisateur. Nous garderons donc la dé-nomination utilisateur pour représenter la notion de session utilisateur. Les procédés sont lancés par des utilisateurs. Ces utilisateurs peuvent avoir des droits différents, selon ces droits, ils ont accès à des procédés différents. Dans le modèle Trèfle♣, nous représentons les utilisateurs dont on veut suivre les actions, comme des sommets d’un graphe. Ils sont reliés aux procédés auxquels ils ont accès. Le modèle permet de suivre les actions des utilisateurs ainsi définis.

4.1.1.d) Application du modèle Trèfle♣ pour une application informatique

Pour appliquer le modèle Trèfle♣ à une application donnée, nous définissons tout d'abord l'ensemble des objets (tiré du modèle d’utilisation) dont nous désirons tracer la manipulation. L'ensemble des procédés (tiré du modèle de procédés) qui permettent d'effectuer ces manipulations doit ensuite être mis en place avec ses différentes rela-tions de décomposition. Les utilisateurs sont définis avec leurs contraintes sur l’exploitation des procédés disponibles. L'ensemble des procédés dont on a décidé le traçage, avec la représentation des utili-sateurs constitue le modèle d'observation : en effet, il s’agit d’indiquer quel point de vue on souhaite avoir sur l’utilisation de l’application informatique pour en former un modèle explicatif ciblé. Le modèle d’observation instaure un filtre à travers lequel l’utilisation du système est suivie. Les méthodes de calcul d’épisodes ainsi que les méthodes de comparaison et d’adaptation des épisodes d’utilisation doivent être mises en place. Nous allons in-troduire ces notions dans la section 4.1.5. Le modèle d’observation pour une application de traitement de texte peut être consti-tué par exemple des procédés de création d’un document, choix d’un modèle, et créa-tion de paragraphes. La création du document explique le choix d’un modèle ainsi que la création des paragraphes. A titre d’illustration, nous pouvons considérer que pour créer un document il faut choisir un modèle et créer les paragraphes en confor-mité avec ce modèle. Le modèle d’utilisation est constitué dans ce cas par : le docu-ment, le modèle de document, le paragraphe. Ainsi défini, cette application du modèle Trèfle♣ peut servir à tracer l’évolution d’une application de traitement de texte. Dans les sections suivantes nous parlerons plus amplement de l’application du modèle Trè-fle♣, en donnant d’autres exemples.

4.1.2. Le graphe

Nous avons choisi d'inclure dans le modèle Trèfle♣ les éléments nécessaires afin de tracer l'usage d'une application informatique : utilisateurs, procédés et objets. Nous avons choisi de représenter ces éléments sous la forme d’un graphe. Nous pouvons représenter ainsi les différents liens entre les utilisateurs, procédés et objets. Nous

Trèfle ♣

115

disposerons également des éléments du modèle dans une structure homogène et for-tement interconnectée. Dans le cadre des chapitres précédents nous avons déjà repré-senté les annotations de documents sous la forme de graphe, nous avons également mis au point des outils d’exploitation, tel le graphe potentiel, que nous souhaitons ainsi réutiliser. Nous représentons donc le modèle d’utilisation, le modèle d’observation et les traces observées sous la forme d'un graphe dont les nœuds sont des objets, procédés ou utilisateurs (Figure 45).

Oabs1

Oabs2 Oabs3Pabs2

Oconcr1,t2

Oconcr2,t4 Oconcr4,t8

Pabs3

Pabs1

Pabs4

Pconcr1,t1

Pconcr2,t3 Pconcr2,t5Oconcr3,t6

Pconcr3,t7Oconcr5,t10

Pconcr4,t9

Nœuds abstraits

Uabs1

Uconcr2,t5 ’

Uconcr1,t0

Oabs1 Objet Pabs1 Procédé

Uabs1 Utilisateur

Arête d’instanciationArête de création

Arête de contextualisation

Nœuds concrets

Nœud concret

Nœud abstrait

Figure 45 Exemple d’un graphe global

Nous allons donner dans la suite des exemples de graphe appliqués à des applications concrètes. Nous définissons le modèle Trèfle♣ en général, puis décrivons les différents types de nœuds et les relations qui peuvent les lier. Concrètement : une instance d’un modèle Trèfle♣ M est composée :

- du graphe G contenant les objets du modèle d'utilisation, les éléments du mo-dèle d'observation ainsi que la trace ;

- de l'ensemble des graphes potentiels {GP} permettant d'exploiter ce graphe. Plus précisément : Le graphe global Les différents éléments du modèle Trèfle♣ sont structurés dans un graphe global con-nexe, orienté étiqueté défini par :

G=<N,R> Avec :

N : l’ensemble de sommets de G R : l’ensemble des arêtes, disjoint de N Nous pouvons noter que l’on reprend les fonctions : α,β et ν de modèle E-SIA, ainsi que l’ensemble E comme étant : α et β sont deux applications de R dans N qui à chaque arête r associent son som-

met d’origine α(r) et son sommet de but β(r) E : l’ensemble des étiquettes de relations

ν est une application de R dans E qui associe à chaque arête r une étiquette ν(r)∈E, E étant l’ensemble des types de relations.


116

Le graphe G est défini formellement de la même manière que le graphe E-SIA (voir section 3.4.1). Les contraintes sur les nœuds et les relations sont néanmoins différen-tes. G est le graphe représentant l'ensemble des éléments N du modèle, mis en relation par l'ensemble de relations R. N=(U∪O∪P), un nœud peut donc être soit un utilisa-teur u∈U, soit un objet issu du modèle d'utilisation o∈O ou bien un procédé p∈P. La sémantique des arêtes est déterminée par les nœuds qu’elles relient.

4.1.2.a) Les nœuds

Un nœud a des attributs, et chaque attribut a une valeur. Chaque nœud a au moins deux attributs : ID : désignant un identificateur unique dans le graphe global G TypeTrefle : spécifiant le type du nœud. L’ensemble des valeurs d’un attribut de type TypeTrefle est décrit par, v(TypeTrefle) ∈ {Oa,Oc,Pa,Pc,Ua,Uc}. Un nœud peut donc être de type objet abstrait (Oa), objet concret (Oc), procédé abstrait (Pa), procédé concret (Pc), utilisateur abstrait (Ua) ou bien utilisateur concret (Uc). Un nœud abstrait est défini lors de l’application initiale du modèle, alors que les nœuds concrets forment la trace d'utilisation et sont créés lors de l'utilisation du sys-tème. Les nœuds concrets sont situés dans le temps.

Notation 5 : Nœuds concrets Les nœuds concrets seront notés : [type_nom,t] où nom est le nom du nœud abstrait dont il est l’instance et t est le time-code de sa création. Le time-code d’un nœud concret est le temps absolu de sa création.

Pour un nœud n∈N, si TypeTrefle(n) ∈ {Oc, Pc, Uc} alors le nœud n a également un attribut de type : t_creation contenant la valeur numérique de l’instant à laquelle il a été créé (time-code). Par exemple le nœud représentant le procédé concret Pconcr1 de la Figure 45 est noté : [Pconcr1,t1], l’objet concret qui a été créé par ce procédé est noté : [Oconcr1,t2]. Nous savons que le nœud représentant le procédé a été créé à l’instant t1, c’est à dire le procédé a été lancé à cet instant, et que l’objet a été créé à l’instant t2. Les nœuds concrets (objets et procédés) peuvent être ordonnés selon le temps, for-mant ainsi les traces linéaires d’utilisation, alors que les nœuds abstraits définissent des ensembles37 sans un ordre particulier par les relations qui les unissent. Chaque nœud concret est l’instance d’un nœud abstrait. Dans le graphe cette relation se matérialise par des arêtes d’instanciation entre les nœuds abstraits et concrets. Dans la suite nous précisons les différents types de nœuds : objets, procédés et utili-sateurs.

37 les nœuds abstraits définissent également des sous-graphes de manière inhérent au modèle, il est néanmoins im-possible de les trier.

Trèfle ♣

117

Définition 9 : Les objets Les objets sont les nœuds représentant tout ce que l'utilisateur peut manipuler et ma-nipule de façon explicite. Les objets du modèle Trèfle♣ sont des données du modèle d’utilisation dont on a décidé de tracer la manipulation. Typiquement tous les nœuds du modèle E-SIA (SD, DA, EAA, …) sont des objets. Deux sortes d’objets sont à considérer : les objets abstraits, et les objets concrets (instances). Un objet abstrait est un objet dont on a décidé de tracer la manipulation. A chaque objet abstrait correspond au moins un procédé abstrait qui permet de l'instancier. Un objet abstrait peut également être en relation avec plusieurs autres procédés abstraits qui permettent sa manipulation. En effet il peut avoir un ou plusieurs procédés qui peuvent créer l’objet. Il peut exister des procédés qui le réutilisent pour le visualiser ou modifier. Les objets abstraits peuvent être reliés à d’autres objets abstraits par des relations de composition. Dans l’état actuel de notre modèle, nous utilisons uniquement ce type de relation. Il est bien sûr imaginable d’avoir d’autres types de relations entre les objets. Définissant le modèle de manière générale, nous ne pouvons pas les spécifier. Nous étudions la mise en place d’une relation générique entre objets, dont la relation de composition serait une instance lors de l’application du modèle Trèfle♣. Par exemple pour un traitement de texte : le document, le modèle de document, ainsi que le paragraphe sont des objets abstraits. Nous pouvons considérer qu’un document a un modèle et est composé d’un titre et de paragraphes. Dans le cadre d’une application d’annotations de vidéos selon le modèle E-SIA le SD, DA, EAA sont des objets abstraits. Un SD contient des DA, alors que des DA sont composées de EAA.

Notation 6 : objets abstraits On note un objet abstrait « type : nom objet » (sur la Figure 45 les objets abstraits : « Oabs :1 », « Oabs :2 », … ou sur la Figure 46 « DA :Victime », « EAA :Homme en noir »).

Un objet concret est une instance d’objet abstrait, il a un type, c’est-à-dire il est relié à un seul objet abstrait par une relation d’instanciation. Tout objet concret a été créé par un procédé concret, sur l’initiative d’un utilisateur concret. Il peut être relié à d’autres procédés concrets qui le réutilisent pour le modifier ou le visualiser. Un objet concret (comme nœud concret) est noté [type nom, t]. Sur la Figure 45 l’objet [Oconcr1,t2] est une instance de l’objet abstrait « Oabs1 » et a été créé grâce au procédé concret [Pconcr1,t1] lui-même instance du procédé abstrait ||Pabs1|| (les nœuds de type procédé et leur notation sont expliqués dans ce qui suit). Sur la Figure 46 [EA : Homme en noir,t6] est un objet concret qui instancie l’objet abstrait « EAA :Homme en noir ».


118

O:DA_Victime

O:EAA_Homme en noir

O:DA_ Victime,t4

O: EA_Homme en noir,t6

P:Choisir DA,t3

P:Choisir EAA,t5

Objetsconcrets

P:Choisir DA

P:Choisir EAA

Procédésconcrets

Objetsabstraits

Procédésabstraits

Figure 46 Exemple de différents types de nœuds adaptés à E-SIA

Les relations entre les objets abstraits sont héritées par leurs instances concrètes. Ain-si l’objet concret [O :DA_Victime,t4] est en relation de contextualisation avec l’objet concret [O :EA_Homme en noir, t6]. Cette règle est valable d’ailleurs pour les procé-dés aussi.

Définition 10 : Les procédés Nous choisissons de considérer que toute utilisation d’une application informatique peut être décrite par des procédés. Un procédé est inclus dans le graphe parce que l'on choisit de tracer ses utilisations. L'utilisateur se sert obligatoirement des procédés pour manipuler les objets. Les procédés identifient des tâches spécifiques à une appli-cation, ils sont en relation étroite avec l’interface homme-machine de celle-ci. Un procédé, au sens Trèfle♣ du terme, n’est pas obligatoirement une opération où une tâ-che de l’application, mais bien une unité de traitement que l’on a choisi d’observer et qui permet de manipuler des objets du modèle d’utilisation. Dans notre modèle, un procédé peut être relié à un ou plusieurs objets par des rela-tions d’utilisation, de création, de visualisation. De leurs coté, chaque objet est relié à au moins un procédé. Un procédé abstrait est un type de procédé, et concerne des objets abstraits (on peut le considérer comme un opérateur, tandis que les objets abstraits sont les opérandes).

Notation 7 : Procédé abstrait Les procédés abstraits seront notés : ||P :nom procédé||.

Les procédés abstraits représentent des fonctionnalités (simples ou composées, expli-cites ou cachées) des interfaces homme-machine des applications. Nous désignons un procédé en choisissant un menu ou en cliquant sur une icône sur une barre de tâches ou, en tapant sur le clavier, … Les procédés abstraits peuvent être reliés entre eux par des arêtes de contextualisa-tion. Ces relations peuvent matérialiser des liens de prescription, par exemple le lan-cement d’un procédé abstrait implique le lancement d’un autre procédé abstrait. Les relations de contextualisation peuvent exprimer des liens de décomposition : un cer-tain procédé abstrait est exécuté dans le cadre d’un autre procédé abstrait. Ces rela-tions n’expriment pas des contraintes. Elles ne nous indiquent ni l’ordre ni le nombre des instances de ces procédés abstraits lors de l’utilisation de l’application.

Trèfle ♣

119

Sur la Figure 46 ||P :Choisir DA|| est un procédé abstrait. Il est relié au procédé abs-trait ||P :Choisir EAA|| puisque dans l’application d’annotation de vidéos une opéra-tion de choix de EAA se passe dans le cadre du choix d’une DA. Dans ce cas nous pouvons dire que ||P :Choisir DA|| est de plus haut niveau que ||P :Choisir EAA||. Les procédés peuvent représenter des arbres de tâches. Ces arbres de tâches peuvent représenter des démarches génériques : rédaction d’un texte sans modèle précis, anno-tation avec le SD général, ou bien des démarches plus spécifiques : utilisation d’un modèle de document précis (CV, Lettre,…) ou annotation selon un SD bien spécifi-que. Un procédé concret est une instance d’un procédé abstrait, située dans le temps et re-liée à un utilisateur concret. Il est également relié à au moins un objet concret. Les procédés concrets matérialisent les lancements de procédés abstraits. Ils représentent les traces, fortement contextualisées, laissées par l’exécution d’un procédé abstrait. Les procédés concrets peuvent être reliés entre eux par des relations d’explication. Ces relations sont héritées des procédés abstraits également et leur création doit être décidée lors de la mise en place du modèle d’observation pour l’application donnée. Il faut relier la création des objets et relations concrètes aux différentes actions de l’utilisateur, donc au différents points d’entrée sur l’interface homme-machine de l’application. Sur la Figure 46, le procédé concret [P :Choisir EAA,t5] est une instance de choix de EAA ||P :Choisir EAA|| et il est à l’origine de l’élément d’annotation [O :EA_Homme en noir, t6]. Nous pouvons également remarquer sur le graphe (fragment de trace Trèfle♣) de la Figure 45 que le procédé abstrait ||Pabs2|| a été lancé deux fois, aux instances : t3, par l’utilisateur [Uconcr1,t0], matérialisé par le nœud procédé concret [Pconcr2,t3] et t5, par l’utilisateur [Uconcr2,t5’], matérialisé par le nœud procédé concret [Pconcr2,t5] Ces deux lancements du procédé abstrait ||Pabs2|| sont à l’origine des objets concrets [Oconcr2,t4] et [Oconcr3,t6].

Définition 11 : Les utilisateurs Un nœud de type utilisateur est une représentation d’une session d’utilisation, d’un rôle d'utilisateur humain, qui utilise le système. Les utilisateurs sont en relation avec des procédés par des arêtes « est à l’origine de ». Un utilisateur abstrait est identifié par un identificateur ayant accès à un certain nombre de procédés abstraits pour manipuler des objets.

Notation 8 : Utilisateur abstrait Un utilisateur abstrait est noté <U :nom utilisateur>.

Un nœud de type utilisateur abstrait matérialise l’utilisateur enregistré du système. Cet utilisateur abstrait n’est pas forcément une personne physique. Une même per-sonne peut en effet avoir plusieurs comptes utilisateur. De la même manière il est dif-ficilement contrôlable que ce soit la même personne physique qui se connecte sous le même nom d’utilisateur. Un utilisateur peut se connecter, et ses actions pourront être identifiées grâce à ses sessions (matérialisés par des nœuds de type utilisateur concret). Chaque fois qu’un utilisateur se connecte un nouveau nœud de type utilisateur concret est créé. Ce nœud


120

est relié au nœud représentant l’utilisateur abstrait, ainsi qu’aux nœuds matérialisant les procédés qu’il a lancé pendant sa session. Un utilisateur concret est la matérialisation d’une session d’utilisation d’un utilisa-teur identifiée, qui manipule des objets concrets à l'aide des procédés concrets. Le time-code du nœud utilisateur concret précise l’ouverture de session, le time-code du dernier procédé relié à ce nœud la fin de la session. Sur la Figure 45 il n’y a qu’un utilisateur enregistré : <Uabs1>. Il a effectué deux ses-sions, matérialisées par les nœuds [Uconcr1,t0] et [Uconcr2,t5’]. Lors de sa première ses-sion il a lancé les procédés : [Pconcr1,t1], [Pconcr2,t3] et [Pconcr3,t7].

4.1.2.b) Les relations

Dans le graphe Trèfle♣ les relations sont étiquetées. Leur étiquette est déterminée par les types de nœuds qu’elles relient. Soit r une arête de G. Les contraintes sur les étiquettes des relations en fonction du type des nœuds reliés sont représentées dans le Tableau 4. Les colonnes représentent pour une relation r∈R le numéro de contrainte, le type du nœud source, le type du nœud cible et l’étiquette de la relation ainsi contrainte. Ces contraintes sont formali-sées et expliquées par la suite.

N° C2.1 C2.2 C2.3 C2.4 C2.5 C2.6 C2.7 Type α(r) Ox Px Oa Pa Ua Px Ux Type β(r) Ox Px Oc Pc Uc Ox Px ν(r) Rcotext Rcotext Rinst

Rinst Rinst Rcreat

Rorig

Tableau 4 contraintes sur les étiquettes d’une relation r∈R en fonction du type des nœuds reliés. x∈{‘a’,’c’} (‘a’ comme abstrait et ‘c’ comme concret)

- Rcotext

Relation de contextualisation Si TypeTrefle(α(r))= Ox et TypeTrefle(β(r))= Ox, où x∈{‘a’,’c’} alors ν(r)=Rcotext. Si TypeTrefle(α(r))= Px et TypeTrefle(β(r))= Px, où x∈{‘a’,’c’} alors ν(r)=Rcotext

. Deux nœuds de type objet ou deux nœuds de type procédé (abstrait ou concret) peuvent être reliés par des relations de contextualisation.

- Rinst, Relation d’instanciation Si TypeTrefle(α(r))= Xa et TypeTrefle(β(r))= Xc, où X∈{‘O’,’P’,’U’}, alors ν(r)=Rinst.

Les nœuds abstraits sont reliés aux nœuds concrets par des relations d’instanciation (Rinst).

- Rcreat, Relation de création/visualisation/utilisation Si TypeTrefle(α(r))= Px et TypeTrefle(β(r))= Ox, où X∈{‘a’,’c’}, alors ν(r)=Rcreat.

Les nœuds de type procédé sont reliés aux nœuds de type objet par des rela-tions de création/visualisation/utilisation (Rcreat).

- Rorig, Relation est à l’origine de Si TypeTrefle(α(r))= Ux et TypeTrefle(β(r))= Px, où X∈{‘a’,’c’}, alors ν(r)=Rorig.

Les nœuds de type utilisateur sont reliés aux nœuds de type procédé par des re-lations est à l’origine de (Rorig)

Trèfle ♣

121

Le modèle Trèfle♣ impose uniquement ces étiquettes, sans fournir de sémantique générale sur les relations.

4.1.2.c) Discussion

En ce qui concerne les utilisateurs il est envisageable de les organiser dans des grou-pes pour gérer leurs droits de manière plus simple. La construction des profils utilisa-teurs est une piste envisageable pour améliorer le modèle.

4.1.3. Traces

Après avoir présenté la structure du graphe formé par le modèle d’utilisation, le mo-dèle d’observation et les traces, nous présentons l’évolution de ces dernières lors de l’utilisation d’une application. Dans un premier temps nous illustrons la construction de la trace à travers un exem-ple générique. Nous présentons ensuite les graphes potentiels qui constituent les mé-thodes de calcul de traces linéaires et d’épisodes. Nous verrons que les traces peuvent être découpées en épisodes dépendants du mo-dèle d’utilisation, c’est à dire des spécificités de l’application informatique observée.

4.1.3.a) Construction de la trace

Pour illustrer la construction des traces, nous allons dans un premier temps présenter un exemple générique, suivi d’un exemple plus concret où le modèle Trèfle♣ est appliqué à un système de traitement de texte. Sur la Figure 47 nous présentons un exemple du graphe global G. Ce graphe repré-sente un système simple, dont l’utilisation a été suivie pendant deux sessions d’utilisation. Supposons que nous choisissons l’observation de la manipulation des objets abstraits : « Oabs1 », « Oabs2 » et « Oabs3 », qui font partie dans notre cas du modèle d’utilisation. Leur manipulation se fait à travers les procédés abstraits : ||Pabs1||, ||Pabs2||, ||Pabs3|| et ||Pabs4||. Cette utilisation est observée pour un seul utilisa-teur : <Uabs1>. L’ensemble des procédés observés ainsi que la représentation de l’utilisateur forment le modèle d’observation.


122

Modèle d’utilisation

Modèle d’observationOabs1

Oabs2 Oabs3Pabs2

Oconcr1,t2

Oconcr2,t4 Oconcr4,t8

Pabs3

Pabs1

Pabs4

Pconcr1,t1

Pconcr2,t3 Pconcr2,t5Oconcr3,t6

Pconcr3,t7Oconcr5,t10

Pconcr4,t9

Uabs1

Uconcr2,t5 ’

Uconcr1,t0

Oabs1 Objet Pabs1 Procédé

Uabs1 Utilisateur

Arête d’instanciation Arête de création


Nœud concret

Nœud abstrait

Trace brute

Figure 47 Découpage du graphe en modèle d’utilisation, modèle d’observation et les traces résul-

tant de l’observation de l’utilisation

Les traces de la Figure 47 nous indiquent que l'utilisateur a effectué deux sessions. Chaque session se traduit par la création d'un nœud session_utilisateur (utilisateur concret) : les nœuds [Uconcr1,t0] et [Uconcr2,t5’] qui sont situés dans le temps : la pre-mière session_utilisateur a débutée à l’instant t0, alors que la deuxième ses-sion_utilisateur a démarré à l’instant t5’. Lors de la première session l’utilisateur [Uconcr1,t0] a lancé le procédé ||Pabs1||, pour manipuler un objet « Oabs1 ». Cette mani-pulation se traduit dans la trace par la création des nœuds [Pconcr1,t1] et [Oconcr1,t2]. [Oconcr1,t2] est l'instance de l'objet « Oabs1 » manipulé (par exemple créé) au cours de la session_utilisateur [Uconcr1,t0] à travers le procédé [Pconcr1,t1]. [Pconcr1,t1] à l’instant t1. Ce procédé est situé dans le temps et il est relié au noeud représentant la session_utilisateur qui est à son origine ainsi qu'à l'instance de l'objet [Oconcr1,t2] qu'il manipule. Toujours lors de la première session, une instance de l’objet « Oabs2 » a été créé, par une instance du procédé ||Pabs2||, laissant la trace [Pconcr2,t3], [Oconcr2,t4] et les rela-tions qui leur sont adjacentes. Les actions de l'utilisateur faisant partie du modèle d'observation sont tracées par la création de nouveaux nœuds et arêtes dans le graphe. Ces nouveaux nœuds sont des nœuds concrets. Ils sont situés dans le temps et ensemble avec les arêtes qui les lient forment la trace brute (voir Figure 47 et Figure 48). La trace brute expliquée est l’ensemble du graphe global G. En général une trace est un sous-graphe du graphe global G contenant au moins un nœud concret. Les traces et les épisodes forment les points de départ de notre système d’aide à la ré-alisation des tâches. Ils permettent de constituer les cas qui pourront être réutilisés. Sur la Figure 48 nous représentons un exemple plus concret du graphe global. Le mo-dèle d’observation permet la suivie de rédaction de documents selon un modèle de procédés particulier. Le but de cet exemple est d’illustrer la construction de traces. Nous allons revenir dans la suite sur le choix du modèle d’observation et le modèle d’utilisation.

Trèfle ♣

123

Le modèle d’observation est composé d’un seul utilisateur abstrait (type d’utilisateur) et d’une structure de procédés qui précise que le procédé d’écriture de documents (||P :Ecrire un document||) est composé du procédé de choix du modèle de document (||P :Choisir un modèle||), à son tour composé de la création de paragraphes (||P :Créer paragraphe||), l’écriture de phrases (||P :Ecrire phrase||), qui sont composés de l’écriture de mots (||P :Ecrire mot||). Pour construire le modèle d’utilisation nous considérons que les objets : document, modèle générique, paragraphe, phrase, mot. L’exemple présente une seule session. Lors de laquelle l’utilisateur a créé un docu-ment selon le modèle générique contenant un paragraphe de deux phrases de deux mots chacun. Chaque opération de l’utilisateur se traduit par la création de nœuds concrets, situés dans le temps. Il se sert des procédés du modèle d’observation pour manipuler des objets laissant ainsi des traces composées de nœuds instances de ces procédés et objets abstraits.

Modèle d’utilisation Modèle

d’observation

Tracebrute

P:Écrire un document

P:Créer paragraphe

P:Écrire phrase

P:Écrire mot


U:Jean

O:Document

O:Paragraphe

O:Phrase

O:Mot

O:Modèle générique

P:Écrire un document,t1

P:Créer paragraphe,t5

P:Écrire phrase,t7

P:Écrire mot,t9

P:Choisir un modèle,t3

U:Jean,t0

O:Document,t2

O:Paragraphe,t6

O:Phrase,t8

O:Mot,t10

O:Modèle générique,t4

P:Écrire mot,t11

O:Mot,t12P:Écrire phrase,t13

O:Phrase,t14

O:Mot,t16

P:Écrire mot,t17

O:Mot,t18 P:Écrire mot,t15

Figure 48 Graphe global représentant une application de Trèfle♣ à un système de traitement de

texte

4.1.4. Les épisodes

Nous pouvons filtrer les traces, grâce à des graphes potentiels pour obtenir des épiso-des. Pour construire un épisode nous utilisons des graphes potentiels. Un graphe potentiel GP = <NGP,R> est composé de nœuds de graphe potentiel n∈NGP reliés par de relations r∈R. Les graphes potentiels reprennent les principes de ceux du modèle E-SIA décrite dans la section 3.4.4. Les nœuds peuvent être partiel-lement renseignés et peuvent se comparer aux nœuds du graphe global G. L'instancia-tion des graphes potentiels se fait en comparant les attributs renseignés de chaque nœud, par des fonctions de comparaison. Les arêtes sont de même type que les arêtes


124

du graphe G. Les graphes potentiels sont utilisés dans le modèle Trèfle♣ pour calcu-ler des traces, découper et adapter des épisodes d'utilisation. Un graphe potentiel a des nœuds caractérisés, définis dans la section 3.4.4.a). Les nœuds caractérisés sont notés Nti (nœud trace #i). Ils ont un attribut « caractérisation », ayant comme valeur la caractérisation du nœud (Nti). Ce sont des nœuds génériques dont on veut récupérer les correspondances dans le graphe global G, car ils constituent l’objet de la requête exprimée par le graphe potentiel. Dans le modèle Trèfle♣, les graphes potentiels sont des méthodes38 de calcul d’épisodes. Un épisode est une liste ordonnée de nœuds concrets du graphe global G, construite par l’instanciation d’un graphe potentiel et trié selon des critères sur les attributs des nœuds des graphes solutions (le temps par exemple). Des exemples d’épisodes sont représentés sur les Figure 49, Figure 51, Figure 52,… Dans la suite de la section nous présentons les différentes manières de calculer des épisodes. Les nœuds de la trace brute, triés selon le temps, constituent la trace linéaire brute. Elle contient tous les procédés et utilisateurs concrets triés selon l’ordre chronologi-que. Une façon de présenter les épisodes est de parler d’abord de ceux qui étaient cons-truits en utilisant uniquement la structure de base du modèle Trèfle♣ (épisodes géné-riques) et d’évoquer ensuite, en graduant la complexité, les épisodes pour lesquels les spécificités des modèles d’observation et d’utilisation ont été également prises en compte (épisodes spécifiques).

4.1.4.a) Episodes génériques

Nous appelons épisode générique, les épisodes qui sont construits à l’aide de graphes potentiels qui exploitent uniquement la structure du modèle Trèfle♣ en général, c’est à dire, qui ne se servent pas de la structure d’un modèle d’observation ou d’utilisation spécifique. De tels épisodes génériques sont les épisodes bruts d’un utilisateur, épisode brute d’une session, la trace linéaire brute entière,… Nous appelons épisode brut d’un utilisateur ou d’une session les nœuds de la trace linéaire brute en relation avec un utilisateur abstrait ou une session (utilisateur concret) donné. La liste de nœuds de la Figure 49 représente un tel épisode brut d’un utilisateur : engendré par les diverses sessions de l’utilisateur « Uabs1 ». Le graphe potentiel qui sert en général à retrouver l’épisode brut d’une session est re-présenté sur la Figure 50. Il permet de calculer l’épisode brut de la session [Uconcrx,t]. Ces graphes potentiels pourront être utilisés dans toutes les applications du modèle Trèfle♣ à des systèmes informatiques différentes. Les nœuds étiquetés par les labels Nti spécifient les nœuds dont les correspondances lors de l’instanciation du graphe potentiel devront faire partie de la trace. On les ap-pelle des nœuds trace. Pour construire des traces linéaires et des épisodes il faut ins-

38 Il s’agit ici de méthode au sens outil du terme et non pas au sens de l’approche objet.

Trèfle ♣

125

tancier des graphes potentiels dans le graphe global, dans les sous graphes résultants il faut récupérer les nœuds correspondant aux nœuds trace et les trier. Pour avoir la trace de la Figure 49, nous cherchons les correspondances des nœuds traces (Nt1 et Nt2) du graphe potentiel épisode brut <Uabs1> dans le graphe de la Figure 47. Ces correspondances sont ensuite triées selon leur temps de création.

t

Pconcr1,t1 Oconcr1,t2 Pconcr2,t3 Oconcr2,t4 Pconcr2,t5 Oconcr3,t6 Pconcr3,t7 Oconcr4,t8 Pconcr4,t9 Oconcr5,t10

graphe potentiel Trace linéaire brute <Uabs1>* Uabs1**Nt1

Nt2

l’épisode Figure 49 L’épisode brut d’un utilisateur et le graphe potentiel qui a permis de le construire

Cet exemple nous indique l'évolution du système dans le temps. Le premier objet ma-nipulé est [Oconcr1,t2], il est manipulé par le procédé [Pconcr1,t1], ils forment les pre-miers éléments de l’épisode, qui s'arrête avec la manipulation de l'objet [Oconcr5,t10].

Uconcrx* *Nt1 Nt2

Figure 50 Graphe potentiel permettant de récupérer l’épisode brute d’une session (Uconcrx,t)

La trace linéaire brute de la Figure 49 peut être découpée par exemple selon les ses-sions ou selon les procédés. La Figure 51 présente un découpage selon les sessions. Le graphe potentiel permet de récupérer les procédés et objets manipulés lors d’une seule session donnée. Comme il y avait deux sessions la trace se découpe en deux épisodes : l'un regroupant les procédés et les objets manipulés lors de la première ses-sion, l'autre ceux manipulés lors de la deuxième session.

t

Pconcr1,t1 Oconcr1,t2 Pconcr2,t3 Oconcr2,t4

Pconcr2,t5 Oconcr3,t6



* Uconcr1

Session1

Session2

* * Uconcr2*GP Session1 GP Session2

Figure 51 Graphes potentiels qui permettent la construction d’épisodes représentant des sessions

Le découpage selon les procédés constitue une méthode spécifique et sera traité dans la section suivante.

4.1.4.b) Episodes spécifiques

Le but du modèle est de fournir un cadre riche de traçage des actions de l’utilisateur pour capitaliser et réutiliser son expérience. Pour ce faire nous construisons à partir des traces des épisodes qui pourront devenir des cas réutilisables dans le cadre d’un système basé sur le raisonnement à partir de cas (RàPC) [Mille 1998]. Pour construire des épisodes spécifiques nous faisons des graphes potentiels qui ex-ploitent les relations qui lient les éléments du graphe. Cette extraction d’épisodes


126

peut se baser sur le modèle d’observation représenté par les relations d'explication en-tre les procédés abstraits, elle peut également se faire en se basant sur les relations qui lient les objets abstraits, se servir des instances de sessions d’utilisation ou bien encore exploiter n’importe quelle autre relation ou spécificité des nœuds du graphe global G. Pour construire les épisodes nous considérons non plus seulement la trace linéaire brute mais aussi différents contextes39 de chaque nœud qui la compose. Les objets ainsi que les procédés du graphe peuvent avoir des relations. Ces relations expriment des liens fonctionnels ou procéduraux spécifiques à l'application. Par exemple si nous avons les objets : document, paragraphe et titre, nous pouvons dire qu'un document est composé d'un titre et de paragraphes. Dans le cadre de notre ap-plication d’annotation de vidéos nous savons que l'annotation selon un schéma de description passe par le choix d'un terme dans une dimension d'analyse, nous pouvons donc mettre en relation les représentants de ces objets dans le modèle d’utilisation. Ces liens peuvent être matérialisés dans le graphe sous la forme de relations de contextualisation (Figure 47). Ces relations peuvent servir à découper les traces en épisodes sémantiquement disjoints. Nous allons d’abord illustrer la calcul d’épisodes spécifiques sur le modèle général, puis l’appliquer sur un exemple concret.

Calcul d’épisodes spécifiques de manière générale La Figure 52 présente un découpage de la trace de la Figure 49 selon le modèle d’observation. Le modèle de procédés de la Figure 47 indique que le procédé ||Pabs1|| contextualise les procédés ||Pabs2|| et ||Pabs3||. Cela peut par exemple représenter le fait que le procédé ||Pabs1|| impose l'exécution des procédés ||Pabs2|| et ||Pabs3||. Pour la construction des épisodes basés sur le modèle de procédés, nous avons donc mis en place un graphe potentiel (GP Pabs1) qui exploite les relations d’explication adjacentes au procédé abstrait ||Pabs1||. Les épisodes calculés par ce graphe potentiel représentent les objets manipulés par l’utilisateur « Uabs1 », lors de ses sessions dans le cadre du procédé abstrait ||Pabs1||, ainsi que les procédés qui ont servi leur manipu-lation. Ce graphe potentiel utilise les spécificités su modèle d’observation, il exploite des relations de contextualisation. Il est utilisable seulement dans le cadre du modèle d’observation de la Figure 47. Dans ce cas l'épisode qui commence par l'instanciation du procédé ||Pabs1||, se termine avec la dernière instance d'objet qui a été manipulé par un procédé qui compose ||Pabs1||, dans notre cas [Oconcr4,t8], manipulé par [Pconcr3,t7], instance de ||Pabs3||.

39 Nous rappelons que sous contexte d’un nœud nous entendons un sous graphe connexe du graphe global qui con-tient le nœud en question. Il s’agit d’un voisinage dans le graphe.

Trèfle ♣

127

*

Pabs1

*

*

Uabs1

*

*

*

t

Pconcr1,t1 Oconcr1,t2 Pconcr2,t3 Oconcr2,t4 Pconcr2,t5 Oconcr3,t6 Pconcr3,t7 Oconcr4,t8 Pconcr4,t9 Oconcr5,t10

GP Pabs1

Figure 52 Graphe potentiel qui permet la construction des épisodes selon le modèle de tâches :

procédés et objets dans le cadre du procédé Pabs1

En créant des graphes potentiels exploitant la structure de procédés, nous pouvons construire des épisodes contenant des suites de nœuds correspondant à toute une sous tâche. Avec les graphes potentiels nous pouvons calculer plusieurs types de traces et en se basant sur des relations de composition et d'explication nous pouvons calculer, ex-ploiter une même trace avec des granularités différentes. Nous pouvons choisir d'in-clure dans l’épisode seulement la création d'objets complexes, sans nous occuper des détails, ou bien au contraire nous pouvons inclure les procédés et objets les plus fins de notre modèle d'utilisation et modèle d'observation.

Calcul d’épisodes spécifiques à une application de traitement de texte Par exemple, si nous considérons le cas d’une application de traitement de texte. Nous pouvons imaginer que l’on construit le modèle d’observation de la Figure 53. Dans cet exemple nous avons choisi de relier les différents procédés pour représenter les liens de tâche/sous-tâche. L’écriture des mots se fait dans le cadre de l’écriture des phrases, qui elle-même est une sous-tâche de la création des paragraphes et ainsi de suite. Nous pouvons remarquer que le choix du modèle de document a été repré-senté comme une sous-tâche de l’écriture de documents.


P:Créer paragraphe

P:Écrire phrase

P:Écrire mot


U:Jean


Arête de création

Figure 53 modèle d’observation d’une application de traitement de texte

Le modèle d’observation s’ajoute au modèle d’utilisation représenté sur la Figure 54. Ce modèle d’utilisation est minimaliste, il fait correspondre à chaque procédé abstrait un ou plusieurs types d’objet (objet abstrait). Selon ces modèles d’observation et d’utilisation il est possible de suivre l’utilisation de l’application de traitement de texte qui se passe de la manière suivante : on choisit


128

d’écrire un document, ensuite on choisit un modèle de document dans le contexte d’une écriture de document, les mots auront été choisis dans le contexte de l’écriture d’une phrase particulier, elle même dans le contexte d’un paragraphe spécifique. Ce paragraphe a été choisi dans le contexte d’un modèle de document, ici un CV ou une lettre.


P:Créer paragraphe

P:Écrire phrase

P:Écrire mot


U:Jean

O:Document

O:Paragraphe

O:Phrase

O:Mot

O:Modèle CVO:Modèle générique

O:Paragr. Formation

O:Paragr. Expériences

O:Paragr. Langues


Arête de création

Figure 54 modèle d’utilisation et modèle d’observation d’une application de traitement de texte

Lors de l’utilisation de l’application ainsi modélisée, nous imaginons que l’interface permet d’écrire des documents en se référant au choix d’un modèle, permettant en-suite de créer des paragraphes par des phrases qui elle mêmes se composent de mots. Les traces laissées rendent compte des contraintes imposées par l’interface et peuvent être considérées comme un ensemble d’arbres représentant chacun la création d’un document. Prenons la trace brute de la Figure 55. Un utilisateur a créé un document selon le Modèle générique, contenant un paragraphe de deux phrases de deux mots chacun. Les objets concrets ainsi que les procédés concrets qui sont à leur origine tracés lors de cette session forment un arbre en suivant les relations de contextualisation héritées du modèle d’utilisation de la Figure 54. Tous les nœuds du graphe de cette figure dé-rivent des nœuds abstraits du modèle d’observation et d’utilisation de la Figure 54.



P:Écrire phrase,t7

P:Écrire mot,t9


U:Jean,t0

O:Document,t2

O:Paragraphe,t6

O:Phrase,t8

O:Mot,t10


P:Écrire mot,t11

O:Mot,t12P:Écrire phrase,t13

O:Phrase,t14

O:Mot,t16

P:Écrire mot,t17

O:Mot,t18P:Écrire mot,t15

Relations de composition

Figure 55 la trace brute d’une session d’utilisation de l’application de traitement de texte observée

La trace linéaire brute donne l’épisode de la Figure 56. L’ordre des nœuds est égale-ment indiqué par leur signature temporelle.

Trèfle ♣

129

P:Écrire un document,t1 O:Document,t2 P:Choisir un modèle,t3 O:Modèle générique,t4 P:Créer paragraphe,t5

O:Paragraphe,t6 P:Écrire phrase,t7 O:Phrase,t8 P:Écrire mot,t9 O:Mot,t10 P:Écrire mot,t11 O:Mot,t12

P:Écrire phrase,t13 O:Phrase,t14 P:Écrire mot,t15 O:Mot,t16 P:Écrire mot,t17 O:Mot,t18

t Figure 56 trace linéaire brute de la trace de la Figure 55

Nous pouvons, en utilisant le modèle d’observation créer des graphes potentiels spé-cifiques à cette application qui permettent de calculer des traces de différents degrés de granularité. Le graphe potentiel GP1 de la Figure 57 permet de récupérer uniquement les mots ta-pés lors d’une session de création de document. Son instanciation donne la trace tra-ceGP1 de la Figure 58. Le graphe potentiel GP2 de la Figure 57 permet de récupérer et les mots et les phrases d’une session : trace traceGP2 de la Figure 58. Ces graphes po-tentiels exploitent la structure du modèle d’observation.

P:Écrire mot U:Jean

**

*Nt1

P:Écrire phrase

* *

Nt2

GP1 GP2

P:Écrire mot U:Jean

**

*Nt1

Figure 57 Graphes potentiels spécifiques au modèle d’observation de la Figure 54

Le graphe potentiel GP2 de la Figure 57 est une extension du graphe potentiel GP1 de la même figure. En suivant la structure du modèle des procédés nous avons choisi d’inclure dans les épisodes non seulement les mots mais également des informations sur l’écriture des paragraphes.

O:Phrase,t8

O:Mot,t10 Mot,t12

O:Phrase,t14

O:Mot,t16 O:Mot,t18t

O:Mot,t10 O:Mot,t12 O:Mot,t16 O:Mot,t18t

traceGP1

traceGP2

Figure 58 traces calculées grâce aux graphes potentiels de la Figure 57

Nous pouvons calculer des traces qui comportent également les procédés, voire ex-clusivement des procédés concrets. Nous avons également la possibilité de calculer des traces qui sont composés d’objets manipulés par des procédés à une certaine distance d’un autre procédé. A l’aide du graphe potentiel GP_mots de la Figure 60 nous retrouvons la trace traceGP1 de la Figure 58. Les mots sont les objets atomiques du modèle d’utilisation dans ce cas. Le graphe potentiel GP_phrases permet de récupérer la trace traceGP_phrases de la Figure 59. Le degré de granularité de ce graphe potentiel est moins fin que celui du GP_mots.


130

O:Phrase,t8 O:Phrase,t14t

traceGP_phrases

t

traceGP_paragraphes

O:Paragraphe,t6

Figure 59 Traces calculées à l’aide des graphes potentiels de la Figure 60

Toujours en se basant sur la structure du modèle d’observation, nous pouvons créer un graphe potentiel qui suit seulement la création des paragraphes. Il s’agit du graphe potentiel GP_paragraphes de la Figure 60. Cette trace ne contient qu’un seul nœud, mais si nous considérons les traces laissées durant plusieurs sessions de création de documents il est possible de calculer :

- des épisodes qui ne contiennent que les paragraphes manipulés durant toutes les sessions,

- nous pouvons également calculer les épisodes contenant les mots, ou phrases ou paragraphes par session,

- ainsi que d’en inclure que les mots et les paragraphes, voire tous les objets.

*

* *

Nt1

*


* *

Nt1

*


GP_paragraphes

GP_phrases

*

*

* *

Nt1

*


GP_mots Figure 60 graphes potentiels permettant de récupérer les objets manipulés par des procédés à une

distance de 1,2 et 3 nœuds de la procédé ||P :Choisir un modèle||

Lors de l’application du modèle Trèfle♣ à une application informatique donnée, il faut mettre en place un ensemble de méthodes de calcul de traces qui permettent l’extraction des épisodes avec des degrés de granularité différents.

4.1.4.c) Discussion

Nous avons énuméré ces exemples afin de donner un aperçu de la multiplicité des mé-thodes de calcul d’épisodes. Nous allons revenir sur leur utilisation dans les sections suivantes. Il y a des méthodes de calcul d’épisodes qui sont génériques, n’exploitant que la structure intrinsèque du modèle Trèfle♣ (les GP de calcul de trace linéaire brute ou des épisodes représentant des sessions par exemple). D’autres méthodes de calcul d’épisodes utilisent par contre la structure du modèle d’utilisation et d’observation. Ils sont spécialisés donc susceptibles de donner des ré-sultats qui seront plus adaptés à la mise en place d’une aide spécifique à l’application donnée.

Trèfle ♣

131

Il est également possible de combiner les méthodes c’est à dire de calculer des épiso-des contenant des éléments spécifiques au modèle d’observation, pour une session. On ne trace pas la création et la modification des objets, procédés et utilisateurs abs-traits, comme on ne trace pas la manipulation des procédés concrets non plus. En ef-fet le but du modèle Trèfle♣ est de permettre l’aide lors de l’utilisation quotidienne d’un système. La gestion du modèle d’utilisation et d’observation sont des tâches d’administration, c’est pour cela que leur observation n’est pas incluse dans le mo-dèle. De plus si la manipulation du modèle d’observation est elle-même observée, ce-la se passe à travers un autre modèle d’observation, nous entrons alors dans une suite infinie de modèles qui s’observent.

4.1.5. Réutilisation de l’expérience

Un système doté du modèle Trèfle♣ pour aider la réalisation des tâches peut fonc-tionner de deux manières :

- comme assistant : en suivant en temps réel le travail de l’utilisateur et en cher-chant à lui proposer de l’aide après chaque action ;

- comme conseiller : en traçant simplement le travail de l’utilisateur et en inter-venant seulement à la demande de celui-ci.

Dans les deux cas il s’agit de retrouver des cas d’utilisations similaires pour s’inspirer des solutions déjà trouvées. La réalisation des tâches est soutenue par le raisonnement à partir des cas.

4.1.5.a) Le raisonnement à partir des cas

Pour aider l’utilisateur nous nous basons sur le raisonnement à partir des cas. La mise en œuvre d’une telle technique impose un certain nombre de formalisations. Dans la suite nous rappelons le paradigme du RàPC (A. MILLE [Mille 1998]). Les expériences passées sont stockées dans des structures appelées cas. Un cas C est, le plus souvent, constitué de la description d'un problème, pb(C), et de la solu-tion à ce problème, sol(C). On notera C=(pb(C),sol(C)). Les cas sont stockés dans une base de cas base-de-cas. Les cas de base-de-cas sont des cas résolus appelés cas sources, notés : source, avec source=(pb(source),sol(source)). Un nouveau problème donne naissance à un cas à résoudre appelé cas cible, noté cible, tel que ci-ble=(pb(cible),sol(cible)), avec sol(cible) inconnue. Le RàPC com-porte deux phases principales, comme le montre la Figure 61, inspirée du diagramme connu sous le nom de carré d'analogie.


132

sol(source)sol(source) sol(cible)sol(cible)

Pb(source)Pb(source)

source

Pb(cible)Pb(cible)

cibleappariement

adaptation

Phase de remémoration

Phase de réutilisation

Figure 61: Réutilisation d’un cas par analogie

La première phase, appelée phase de remémoration, consiste à rechercher dans base-de-cas, un cas source tel que pb(source) soit similaire à pb(cible). Ceci est réalisé grâce à un appariement des descriptions de problème cible et source. La seconde phase consiste à réutiliser la solution du cas remémoré, pour trouver la solution du cas cible. Comme pb(cible) et pb(source) ne sont que similaires (et non identiques)40, la solution remémorée, sol(source), devra être adaptée, pour résoudre cible. Les deux principales phases du raisonnement à partir de cas sont donc la remémoration et l'adaptation. Outre les cas, contenant la connaissance épisodique, le RàPC exploite la connaissance du domaine représentée sous forme on-tologique et sous forme de contraintes intrinsèques au domaine. Dans notre cas ce sont les différentes arêtes du graphe ainsi que la structure et les informations stockés dans les nœuds. L'ensemble constitue la base de connaissances. Le principe de fonctionnement d’un système doté du modèle Trèfle♣ est d’observer sans cesse les actions de l’utilisateur, grâce au modèle d’observation. En utilisant les informations stockées dans le modèle d’observation il faut essayer de se rendre compte quand une tâche donnée commence et se termine, et chercher dans la trace capitalisée des cas similaires, pour pouvoir proposer des réponses à des questions de type : « Que faire maintenant ? » « Est ce que quelque chose manque à ma créa-tion ? ». Le modèle Trèfle♣ peut également servir à mettre en place des assistants qui permet-tent de terminer automatiquement des tâches commencées. En effet si pendant l’utilisation de l’application, le système cherche des cas similaires dans la base de cas en temps réel et peut proposer des suites possibles à effectuer automatiquement.

4.1.5.b) Les cas dans le modèle Trèfle♣

Dans la section 4.1.3 nous avons présenté différentes méthodes pour calculer des épi-sodes dans le modèle Trèfle♣. En effet dans le modèle Trèfle♣, tout épisode est un cas. Ces épisodes constituent aussi bien le problème que la solution. Une première partie d’un épisode peut être le problème, alors que sa suite est la solution.

40 Dans le cas où pb(cible) et pb(source) sont identiques, la réutilisation consiste en une simple copie de sol(source).

Trèfle ♣

133

Dans le modèle Trèfle♣, l’identification du problème et de la solution se fait au mo-ment de la requête d’aide. En général le problème est la partie de l’épisode que l’utilisateur viens de faire et la solution est constituée par les prochaines étapes pos-sibles de sa session. L’application du modèle Trèfle♣ nécessite que les modèles d’utilisation et d’observation permettent un traçage qui facilite l’identification des couples : pro-blème/solution. Il est nécessaire de savoir comparer les épisodes afin de retrouver ra-pidement et précisément des cas déjà résolus, similaires à un problème encore non élucidé. Nous utilisons des séries de graphes potentiels qui permettent de calculer des épisodes de granularités différentes. A l’aide de ces graphes potentiels nous calculons des épisodes qui représentent le contexte de travail actuel en prenant en compte des explications de plus en plus éloignées et une période de temps de plus en plus longue. Pour illustrer notre démarche, prenons la trace laissée par une session de création d’un document, par un utilisateur. Cette trace, représentée sur la Figure 62 correspond au modèle d’observation de la Figure 54. La session identifiée par le nœud [U :Jean,t40] a commencé par le lancement de l’écriture du document par le procédé [P :Ecrire un document,t41], a continué par le choix du modèle générique, la création de deux paragraphes d’une phrase chacune, et par l’écriture de mots « Formation » et « DEA » pour la première phrase et « Expérience » et « Stage1 » pour la deuxième.



P:Écrire phrase,t47

P:Écrire mot,t49


U:Jean,t40

O:Document,t42

O:Paragraphe,t46

O:Phrase,t48

O:Formation,t50


P:Écrire mot,t51

O:DEA,t52

P:Écrire phrase,t55

O:Phrase,t56

O:Expérience,t58

P:Écrire mot,t59

O:Stage1,t60

P:Écrire mot,t57

O:Paragraphe,t54


Figure 62 Traces laissées par une session de création d’un document

A l’instant où l’utilisateur vient d’écrire son dernier mot [Stage,t60], il demande de l’aide au système sur la suite à prendre. Les épisodes qui caractérisent son contexte de travail sont calculés à partir de ce nœud. Ils sont ceux représentés sur la Figure 63 et Figure 64. Ces figures reprennent uniquement les nœuds de type objet de la trace de la Figure 62. Une manière de considérer les épisodes est celle illustrée sur la Figure 63. Ici le temps et la composition des procédés sont également pris en compte. L’épisode com-posé des nœuds du rectangle E1 constitue l’épisode le plus petit et le plus détaillé. Les épisodes E2, E3 et E4 prennent en compte une plage de temps de plus en plus étendue. Les épisodes E21, E22, E23 représentent des épisodes équivalants à E1, E2 et E3, mais font partie d’une autre branche de l’arbre. Ils correspondent à une autre sous-tâche.


134

Document,t42

Paragraphe,t46

Phrase,t48

Formation,t50

Modèle générique,t44

DEA,t52

Phrase,t56

Expérience,t58 Stage1,t60

Paragraphe,t54

E1

E2

E3

E21

E22

E23

E4

E5

Figure 63 Episodes emboîtés calculés sur une trace

Une autre manière de calculer les épisodes est de considérer tous les objets d’un même niveau de granularité. En effet si le graphe potentiel GP_mots de la Figure 60 est instancié dans les traces, le résultat sera l’épisode E’1 de la Figure 64. Le graphe potentiel GP_Phrases donne l’épisode E’22 et ainsi de suite. Pour avoir les épisodes E’2, E’3, E4 et E5 les graphes potentiels de la Figure 71 sont utilisés.

Document,t42

Paragraphe,t46

Phrase,t48

Formation,t50


DEA,t52

Phrase,t56


Paragraphe,t54

E ’22

E ’1

E ’2

E ’3

E4

E5

E ’23


Pour notre exemple les épisodes E1, E’1, E2, E3, … constituent les cas cibles poten-tiels. Pour comparer deux épisodes nous utilisons des fonctions de similarité. Ces fonctions comparent les différents attributs des nœuds composant l’épisode. Les traces laissées lors de la session d’utilisation en cours sont filtrées par plusieurs méthodes de calcul d’épisodes, ces mêmes filtres servent à extraire, à partir des traces capitalisées, des épisodes comparables. Pour chaque méthode de calcul d’épisodes il faut mettre en place un seuil, aussi bien sur le degré de similarité de chaque nœud formant l’épisode que sur le nombre mini-mal de nœuds que le cas cible doit contenir pour qu’il puisse être considéré comme similaire à un cas source. Les cas sources sont triés par degré de similarité par rapport au cas cible. Parmi les cas les plus similaires, il faut ensuite choisir celui que l’on va adapter. A ce moment on peut solliciter l’intervention de l’utilisateur, en lui proposant éventuelle-ment plusieurs choix. L’utilisateur pourrait même intervenir dans le choix de métho-des de calcul de traces. Il y a des fortes chances que les cas calculés avec des méthodes de granularités fines soient plus précis, plus proches de ce que fait l’utilisateur. Il est également probable que la similarité des épisodes contenant les « détails » d’une session (objets manipulés par des procédés de granularité fines), et la diffé-

Trèfle ♣

135

rence des épisodes plus complexes favorise l’adaptation, comme présenté dans la sec-tion suivante. En effet si lors de deux sessions on a écrit les mêmes mots mais dans le cadre des modèles de documents différents il est probable due l’un des modèle soit plus adapté aux mots écrits. Prenons maintenant les traces laissées toujours selon le modèle d’observation de la Figure 54, représentées sur la Figure 65. Nous considérons qu’un utilisateur a lancé une session [U :Pierre,t0] lors de laquelle il a créé un document selon le modèle CV, il a mis en place deux paragraphes, un pour la formation et un autre pour les langues. Comme formation il a mentionné son DEA et le DEUG, comme langues il a précisé le français, l’anglais et l’allemand. Les traces laissées par cette création sont capitali-sées au moment où l’autre utilisateur, [U :Jean,t40], de la Figure 62 commence sa session.

U:Pierre,t0


P: Créer paragraphe,t5

P: Écrire phrase,t7

P: Écrire mot,t9


O:Document,t2

O:Phrase,t8

O:Formation,t10

O:ModèleCV,t4

O:Paragr. Formation,t6

O:Paragr. Langues1t16

P:Écrire mot,t11O:DEA,t12

P:Écrire mot,t13O:DEUG,t14

P: Créer paragraphe,t15

O:Phrase,t18

O:Langues,t20

O:Français,t22

O:Anglais,t24

P: Écrire mot,t19

P: Écrire mot,t21

P: Écrire mot,t23

P: Écrire phrase,t17

O:Allemand,t26

P: Écrire mot,t25

Figure 65 Traces laissées par une session de création d’un CV

Quand l’utilisateur [U :Jean,t40] de la Figure 62 demande de l’aide au système, des épisodes sont construits à partir des traces laissées. Si les mêmes méthodes de construction sont appliquées aux traces laissées par Pierre, que celles appliquées sur les traces de la Figure 62, on obtient les épisodes de la Figure 66 et Figure 67.

Document,t2

Phrase,t8

Formation,t10

ModèleCV,t4

Paragr. Formation,t6 Paragr. Langues1t16

DEA,t12 DEUG,t14

Phrase,t18

Langues,t20 Français,t22 Anglais,t24 Allemand,t26

E31

E32

E33

E41

E42

E43

E34

E35



136

Document,t2

Phrase,t8

Formation,t10

ModèleCV,t4


DEA,t12 DEUG,t14

Phrase,t18

Langues,t20 Français,t22 Anglais,t24 Allemand,t26

E ’41

E ’32

E ’33

E34

E35

E ’42

E ’43


Lors de la comparaison de ces épisodes, on se rend compte que plusieurs entre eux peuvent être considérés comme similaires. Sur la Figure 68 nous avons représenté les deux épisodes considérés comme étant des cas similaires. E’1 est l’épisode le plus réduit qui contient le dernier nœud du contexte actuel [Stage1,t60] et qui a un épisode similaire : E’41 dans les traces capitalisées. Les deux épisodes sont calculés à l’aide d’un même graphe potentiel GP_mots de la Figure 71.

Formation,t50 DEA,t52 Expérience,t58 Stage1,t60E ’1

Formation,t10 DEA,t12 DEUG,t14 Langues,t20 Français,t22 Anglais,t24 Allemand,t26E ’41 Figure 68 Deux épisodes extraits de la trace laissée par les deux sessions

Les épisodes E’32 et E’2, représentés sur la Figure 69, peuvent être également consi-dérés comme similaires. Ils représentent des contextes plus larges. En effet nous pou-vons constater que la partie encadrée, contient des éléments identiques : chaque fois une Phrase suivi des mots : « Formation » et « DEA ». Cela suffit dans notre cas pour juger ces deux épisodes comme similaires.

Phrase,t8 Formation,t10 DEA,t12 DEUG,t14 Phrase,t18 Langues,t20 Français,t22 Anglais,t24 Allemand,t26

Phrase,t48 Formation,t50 DEA,t52 Phrase,t56 Expérience,t58 Stage1,t60E ’2

E ’32

Figure 69 Deux épisodes extraits de la trace laissée par les deux sessions

Dans ces cas les parties encadrés constituent les problèmes source et cible, alors que les suites des épisodes constituent la solution. Nous pouvons remarquer que l’épisode E’2 représentant le problème cible contient également des éléments qui ne font pas partie du problème cible. Cela aura des effets sur l’adaptation, traitée dans la suite.

4.1.5.c) Adaptation des cas

Une fois des cas similaires trouvés, plusieurs démarches sont possibles. Si lors des calculs, des épisodes présentant des « parties problème » identiques sont trouvés, le système peut proposer des éléments pour terminer la tâche en cours de l’utilisateur en proposant les éléments de la solution source. S’il y a des différences entre les problèmes, diverses méthodes d’adaptation peuvent être appliquées.

Trèfle ♣

137

Une solution générale est de présenter les cas similaires à l’utilisateur et de lui laisser décider de la suite de ses opérations. Puisqu’il s’agit de l’aide sur la réalisation d’une tâche, montrer aux utilisateurs des cas similaires au sien, peut lui donner les idées pour résoudre son problème. Cela peut se résumer à montrer les objets manipulés lors du cas similaire : ici le document de type CV. La manière dont les cas similaires sont présentés est important. Il faut en effet que l’utilisateur puisse repérer rapidement les différences et les similarités importantes entre le cas proposé et son contexte de travail courant. La Figure 70 présente les parties similaires (a1,a2) et différentes (b1,b2) des épisodes calculés dans la section précédente (Figure 64, Figure 67).

Document,t42

Paragraphe,t46

Phrase,t48

Formation,t50


DEA,t52

Phrase,t56


Paragraphe,t54

E ’22

E ’1

E ’2

E ’3

E4

E5

E ’23

Document,t2

Phrase,t8

Formation,t10

ModèleCV,t4


DEA,t12 DEUG,t14

Phrase,t18

Langues,t20 Français,t22 Anglais,t24 Allemand,t26E ’41

E ’32

E ’33

E34

E35

E ’42

E ’43

a1 a2

b1 b2

Figure 70 parties similaire (a) et parties différents, à adapter (b) des cas

Le système peut proposer dans le cas de l’écriture de document traité ci-dessus, à l’utilisateur Jean d’utiliser le modèle CV et donc de compléter sa rédaction par un pa-ragraphe expériences. Dans notre exemple d’utilisation d’une application de traitement de texte, épisodes similaires les plus longs sont E’32 (rectangle a1 de la Figure 70) et E’2 (rectangle a2 de la Figure 70). Quand le modèle d’observation contient des structures complexes de procédés, il est possible de calculer des traces avec des granularités décroissantes. Plus un procédé est bas dans la structure, plus il est considéré comme étant de granularité fine. Dans le cas du modèle d’observation de la Figure 54, le procédé : ||P :Ecrire mot|| est le procédé de granularité la plus fine, le procédé ||P :Ecrire un document|| est celui de granularité la moins fine. Dans ce cas, la recherche des cas similaires peut partir des épisodes ne contenant que les détailles des opérations, sans éléments encadrants : dans notre cas seulement les mots. Si des épisodes similaires sont trouvés à ce niveau, il faut chercher des épisodes qui contiennent aussi bien les parties similaires que leurs contextes jusqu’au dernier élément du problème cible. Dans notre cas ce sont les élé-ments de l’épisode E1 qui doivent figurer dans l’épisode constituant le problème ci-ble. La recherche des cas similaires est commencée par la comparaison des épisodes avec des granularités très fines : ici ceux contenant exclusivement les mots, calculés à l’aide du graphe potentiel GP_mots de la Figure 71. Ces épisodes sont ceux indiqués par les labels E’1 et E’41 sur les figures Figure 64 et Figure 67. Leur granularité est dite fine car ils représentent des objets manipulés par les procédés qui sont en bas de la structure de procédés décrite dans le modèle d’observation. Ce premier calcul fait ressortir deux épisodes avec des débuts similaires : E’1 et E’41.


138

*

*

* *

Nt1

*


GP_mots

*

*

* *

Nt1

*


GP_phrases_et_mots

* *

Nt2*

*

* *

Nt1

*


GP_paragraphes_phrases_mots

**

Nt2

* *

Nt3*

*

* *

Nt1

*


GP_modèles_paragraphes _phrases_mots

**

Nt2

* *

Nt3

**Nt4

Figure 71 graphes potentiels de granularité décroissantes

Il faut maintenant trouver les épisodes les plus proches de E’1 et E’41 qui les con-tiennent et qui sont différents. Ce seront ces cas là, que l’on va essayer d’adapter. En partant de ces épisodes « de détailles » que sont E’1 et E’41, les calculs continuent en relâchant la finesse de granularité des graphes potentiels. Le graphe potentiel GP_phrases_et_mots de la Figure 71 suit le GP_mots en finesse, c’est donc lui qui est utilisé pour la deuxième étape de recherche de cas adaptables. Il donne les épisodes E’2 et E’32, qui contiennent les épisodes E’1 et E’41. Ces épisodes sont tou-jours similaires. Pour le calcul des prochaines épisodes, des procédés encore plus complexes (incluant la création des paragraphes) sont pris en compte : le graphe potentiel GP_paragraphes_phrases_mots est utilisé pour trouver les épisodes E’3 et E’33. Ces épisodes sont différents, nous avons donc trouvé les premiers candidats à l’adaptation : Figure 72.

Phrase,t8 Formation,t10 DEA,t12 DEUG,t14 Phrase,t18 Langues,t20 Français,t22

Phrase,t48 Formation,t50 DEA,t52 Phrase,t56 Expérience,t58 Stage1,t60E ’3

E ’33 Paragr. Formation,t6 Paragr. Langues1t16

Paragraphe,t46 Paragraphe,t54

Adaptation Adaptation

…..

Figure 72 cas candidats pour une adaptation

Les éléments à adapter sont les types de paragraphes. Lors de la session_utilisateur [U :Pierre,t0] un paragraphe de type formation a été créé, alors que lors de la ses-sion_utilisateur courant [U :Jean,t40] le cas candidat débute par la création d’un pa-ragraphe générique. L’utilisateur actuel peut donc décider de changer de type de pa-ragraphe, mais le modèle de procédés lui interdit sauf s’il change également de modèle de document. Il faut donc remonter encore un niveau pour avoir des cas con-tenant le choix du modèle aussi. A ce moment l’utilisateur peut donc demander de voir un contexte encore plus large du problème source, c’est à dire l’épisode E34, donné par le graphe potentiel GP_modèles_paragraphes_phrases_mots , qui commence par le choix du modèle de document CV. A ce moment il peut choisir de changer le modèle de son document de modèle générique en CV et en regardant l’épisode E34 où le résultat de la session [U :Pierre,t0] il peut également créer une paragraphe : langues et changer le type du paragraphe [O :Paragraphe,t54] en paragraphe de type expériences. Des méthodes d’adaptation automatiques devront pouvoir être mises en place pour des modèles d’observation qui le permettent. Dans notre exemple ce n’est pas le cas, car la partie problème du cas cible ne contient pas tous les éléments du cas. Dans cet

Trèfle ♣

139

exemple nous avons illustré, comment dans des cas particuliers le modèle Trèfle♣ peut servir à trouver des cas sources facilement adaptables pour un problème cible donné. Dans cette démarche la structure du modèle d’utilisation et d’observation a été largement exploitée aussi bien dans la phase de calcul et comparaison des épisodes et cas, que dans la phase d’adaptation.

4.1.5.d) Discussion

Les fonctions de similarité d’épisodes pourraient également prendre en compte diffé-rents contextes des nœuds en se basant sur les graphes potentiels qui ont servi à calculer l’épisode. Pour l’adaptation on se sert non seulement des traces mais également des graphes po-tentiels, notamment pour remonter à des niveaux de granularité moins fines. Si le modèle de tâche du cas cible est plus générique que le modèle de tâche du cas source, on peut proposer à l’utilisateur de se conformer au modèle de tâche plus spécifique (s’il a commencé de rédiger un CV sans utiliser le modèle, ou s’il a commencé d’annoter selon le SD général). Certains applications permettent en effet de définir des modèles de procédés que l’on peut considérer comme fournissant plus d’informations sur la tâche de l’utilisateur que d’autres. La rédaction d’un document en utilisant le modèle générique est moins parlante que si on utilise le modèle lettre ou le modèle CV. Dans ce dernier cas nous avons plus d’informations sur la structure du document, qui n’est plus une simple suite de paragraphes génériques mais comporte une partie formation, une partie expé-rience, une partie langues … Dans le cas ou les modèles d’observation permettent de hiérarchiser ainsi les structu-res de procédés, l’aide peut aller plus loin que le simple présentation des cas similai-res à l’utilisateur. Si le problème cible correspond à une structure de procédés moins spécifique que le problème source, le système peut proposer une adaptation du par-cours pour adopter la démarche choisie dans le problème source. Par exemple dans le cas de l’utilisateur Jean, qui a commencé d’écrire son document en choisissant le mo-dèle générique, donc a opté pour un parcours plus générique que l’utilisateur Pierre, le système peut lui proposer de revenir en arrière et préciser qu’il est en fait en train de rédiger un CV. Le système lui permet ainsi de réduire ses efforts créatifs et de ren-dre son travail plus cohérent avec ce qui a déjà été fait. Nous avons vu qu’il est possible d’extraire des traces des arbres représentant des ob-jets ou des procédés manipulés lors d’une sous-tâche. Il serait intéressant de considé-rer ces arbres, et non seulement les épisodes qui en découlent, comme des cas. Il fau-drait définir des mesures de similarité entre arbres et leurs sous arbres. Pour trouver quel épisode est le plus similaire, on peut prendre en compte le nombre de nœuds similaires, la longueur totale des cas, la généralité des graphes potentiels utilisés. En effet il faut trouver l’épisode le plus long qui soit similaire à l’épisode de même niveaux se terminant par les derniers nœuds du problème cible. Dans notre exemple il est plus intéressant de choisir comme cas similaires les cas E4 et E34 que les cas E21 et E41. En effet dans le premier cas l’utilisateur Jean a pu adapter sa ré-daction selon le modèle CV alors que dans le second cas il aurait su seulement que Pierre a précisé également son DEUG sans le cadre de sa formation.


140

4.2. Application à RECIS

Dans cette section nous présentons un cas concret de mise en place du modèle Trè-fle♣, depuis l’application du modèle à ce système particulier jusqu'aux étapes de ré-utilisation de l'expérience. L'exemple s'applique à notre étude d'annotation de vidéos. L'aide du système consiste à amener les utilisateurs à annoter les vidéos d'une ma-nière cohérente, et leur faciliter le choix des annotations à poser. Comme expliqué dans le chapitre 0, nous supposons que les vidéos peuvent être anno-tées en suivant des schémas de description. Dans ce système plusieurs utilisateurs an-notent un grand nombre de vidéos. Ils existent de nombreuses manières, formalisées en schémas de description, de décrire ces documents. Il est donc difficile à un utilisa-teur novice de trouver dès le départ précisément le bon schéma. En plus de la mécon-naissance des méthodes d’annotation, le plus souvent l’utilisateur qui annote n’a pas encore vu le document qu’il veut décrire. Il lui est donc autant plus difficile de pré-dire le schéma qui va lui correspondre au mieux. Notre exemple illustre le cas où l’utilisateur commence à visionner le document, pose quelques annotations dans le cadre du schéma de description général, c’est à dire sans contraintes. En fonction de ces annotations le système va essayer de trouver les schémas de description plus spécifiques qui correspondent au mieux au document et aux intentions de l’utilisateur en se basant sur des sessions d’annotations passées, ca-pitalisées dans la base de cas.

4.2.1. Modèle d'utilisation

Pour notre exemple nous choisissons le traçage de l'annotation. Les exemples étaient choisis dans le cas où des vidéos de premier secours sont annotées. Le vocabulaire contient donc des termes adaptés, qui sont regroupés dans des dimensions d’analyses telles que : Victime, Opération, Secouriste. Le modèle d'utilisation est composé des objets suivants (Figure 73):

- un schéma de description « SD premier Secours », ainsi que d'un « SD géné-ral » (SDG) selon lesquels les utilisateurs peuvent annoter la vidéo,

- des dimensions d'analyse : « DA Victime », « DA Opération » et « DA Secou-riste » dans lesquels les termes doivent être choisis, complétés par une « DA générale » (DAG) contenant tous les termes,

- ainsi que les termes eux-mêmes : Homme en noir, Cycliste, Massage, … et - la relation élémentaire : Re qui permet de relier des instances de termes (élé-

ments d'annotation). En effet il existe toujours un schéma de description général qui ne contraint pas l’annotation (il permet la mise en place libre de termes et de relations), de la même façon il existe toujours une dimension d’analyse générale regroupant tous les termes. Dans cet exemple on se résume à ces deux schémas de description pour faciliter la compréhension de la réutilisation de l’expérience. Les schémas de description sont reliés aux dimensions d'analyse par des relations de composition tout comme les dimensions d'analyse aux termes. Dans la pratique ce modèle d'utilisation décrit une application qui permet d'annoter soit selon un schéma prédéfini « SD premier secours » qui impose la mise en place

Trèfle ♣

141

d'un secouriste, d'une victime et d’une opération, soit une annotation sans contrainte qui suit le « SD général ».

O:SDG

O:DAG

O:DA_Secouriste

O:EAA_Lt. Tonton

O:SD premier secours


O:DA_Opération

O:EAA_Massage

O:EAA_Vérification

O:ReO:DA_Victime

O:EAA_Dégagement

O:EAA_Homme en noir

O:EAA_Cycliste

Figure 73 Modèle d'utilisation

4.2.2. Modèle d'observation

Le modèle d'observation contient les utilisateurs, ainsi que les procédés qui permet-tent de créer les objets. (Figure 74). Nous traçons ainsi l'annotation depuis le choix du schéma de description (dans notre cas, le « SD premier secours » ou le « SD géné-ral »), en passant par le choix de la dimension d'analyse, la mise en place ou réutilisa-tion des éléments d’annotation et leur mise en relation. Le modèle d'observation indi-que que le procédé de choix de SD se décompose dans les procédés de choix de dimension d'analyse et le procédé de mise en relation. Dans la pratique dans l'inter-face de l'application le choix d'un SD pour annoter implique le choix des termes (EAA) dans des dimensions d'analyse, et leur mise en relation. Dans l’application elle-même un utilisateur a le choix d'annoter une vidéo, soit selon le « SD général », soit selon le« SD premier secours ».

P:Choisir DA

P:Choisir SD

P:Mettre en relationP:Choisir EAA

Uabs1

Uabs2

Figure 74 Modèle d'observation

Ces procédés du modèle d'observation sont reliés par des relations de créa-tion/utilisation aux objets du modèle d'utilisation (Figure 75).


142

P:Choisir DA

P:Choisir SD

P:Mettre en relation

P:Choisir EAA

O:SDG

O:DAG

O:DA_Secouriste

O:EAA_Lt. Tonton



O:DA_Opération

O:EAA_Massage

O:EAA_Vérification

O:ReO:DA_Victime

O:EAA_Dégagement

O:EAA_Homme en noir

O:EAA_Cycliste

Figure 75 Fragment du graphe global G représentant des relations entre le modèle d'utilisation et

le modèle d'observation

Le procédé : ||P :Choisir SD|| est en relation de création avec les « SD général » et « SD premier secours », le procédé ||P :Choisir DA|| est en relation de création avec les dimensions d'analyse, les procédés ||P :Choisir EAA|| et ||P :Mettre en relation|| sont reliés à tous les termes. Le procédé ||P :Mettre en relation|| est relié de plus à l'objet Re et lors de son instanciation il sera relié à trois objets concrets : l'instance de Re et les instances des deux termes que l'on met en relation avec Re. Une partie de ces relations est représentée sur la Figure 75. Le modèle d'utilisation et le modèle d'observation ainsi définis, nous pouvons étudier le fonctionnement du système. Dans les sections suivantes nous allons dérouler une première annotation selon le « SD premier secours », suivi d'une deuxième session, d'un autre utilisateur qui annote selon le « SD général », et qui sera dirigé par le sys-tème vers le « SD premier secours » après avoir posé ses premières annotations.

4.2.3. Scénario et construction des épisodes

Nous allons suivre l'évolution du système du point de vue du modèle Trèfle♣ pendant la mise en place des annotations en indiquant les méthodes de construction de traces ainsi que leur découpage et leur réutilisation pour proposer de l'aide à l'utilisateur. La Figure 76 présente les trois premières étapes de la première session. L'utilisateur 1 se connecte, créant ainsi le nœud [Uconcr1,t0]. Il choisit le « SD premier secours » laissant la trace formée par les nœuds procédé concret [P :ChoisirSD,t1] et l'objet concret [SD premier secours,t2], reliés entre eux. Ensuite l'utilisateur choisit la di-mension d'analyse « DA Victime » et l'« EAA Homme en noir », laissant les traces [P :ChoisirDA,t3][DA :Victime,t4] et [P :ChoisirEAA,t5][Homme en noir,t6]. La Figure 77 présente la trace linéaire brute des trois premières étapes de cette première session. Après cela il annote en choisissant un terme de la « DA opération » : [Vérifica-tion,t7] et le met en relation avec le terme [Homme en noir,t6] (Figure 78).

Trèfle ♣

143

P:Choisir EAA

P:Choisir DA

P:Choisir SD

O:SD premier Secours,t2 P:Choisir SD,t1

Uabs1

Uconcr1,t0


O:DA_Victime

O:EAA_Homme en noir

O:DA_Victime,t4

O:EA_Homme en noir,t6

P:Choisir DA,t3

Nœuds concrets et relations formant les traces

P:Choisir EAA,t5

O:DA_SecouristeO:DA_Opération

Figure 76 Fragment du graphe global G représentant les traces laissées par premières pas de

l'annotation

P:Choisir SD,t1 O:SD premier Secours,t2 P:Choisir DA,t3 O:DA_Victime,t4 P:Choisir EAA,t5 O:EA_Homme en noir,t6

t Figure 77 Trace linéaire brute des premières pas de l’annotation


Uconcr1


O:Re


O:EA_Vérification,t10

O:Re,t12

P:Mettre en relation,t11

P:Choisir SD

O:EAA_Vérification

O:DA_Victime

O:EAA_Homme en noir

O:DA_Opération

Figure 78 Traces laissées par la mise en relation

Finalement il précise une opération [Vérification,t10] (Figure 78) et le met en relation avec la victime [Homme en noir,t6]. Chaque fois laissant des traces comme pour la mise en place de l’EA [Homme en noir,t6]. Pour récupérer des épisodes représentant seul les procédés employés ou seuls les ob-jets manipulés, nous construisons les graphes potentiels de la Figure 79. Nous les ins-tancions, nous trions les résultats en ordre chronologique et nous obtenons les épiso-des de la Figure 80

Uconcr1* *Uconcr1*

a bNt Nt

Figure 79 Graphes potentiels pour le calcul des traces linéaires

En effet le graphe potentiel Figure 79 (a), permet de récupérer les procédés concrets effectués par un utilisateur donné. Le nœud caractérisé (Nt :Nœud de trace) du graphe potentiel désigne ces procédés. En triant ces procédés concrets pour notre utilisateur en ordre chronologique nous obtenons l’épisode de la Figure 80 (a). En instanciant le


144

graphe potentiel Figure 79 (b) pour avoir les objets manipulés par l'utilisateur [Uconcr1], nous aurons, après un tri l’épisode de la Figure 80 (b).

P:Choisir SD,t1 P:Choisir DA,t3 P:Choisir EAA,t5 P:Choisir DA,t7

P: Mettre en relation,t11 P:Choisir DA,t13 P:Choisir EAA,t15

O:SD premier Secours,t2 O:DA_Victime,t4 O:EA_Homme en noir,t6 O:DA_Opération,t8

O:EA_Vérification,t10 O:Re,t12

P: Mettre en relation,t17

P:Choisir EAA,t9

O:DA_Secouriste,t14 O:EA_Lt. Tonton,t16 O:Re,t18

a

b

t

t Figure 80 Traces linéaires calculées

En fonction de type d'aide que l'on désire fournir, nous pouvons mettre en place diffé-rentes méthodes de calcul d’épisodes.

P:Choisir DA

P:Choisir SD

Mettre en relationP:Choisir EAA

O:SDG,t21

P:Choisir SD,t20

Uconcr2

O:SDG

O:DAG

O:EAA_Lt. Tonton


O:EAA_Massage

Vérification

O:Re

O:EAA_Dégagement

O:EAA_Homme en noir

Cycliste

O:DAG,t23


P:Choisir DA,t22

P:Choisir EAA,t24

Uabs2

P:Choisir DA,t26

O:DAG,t27

O:EA_Vérification,t29

P:Choisir EAA,t28

Re,t30Mettre en relation,t29

Nœuds concrets etrelations

formant les traces

Figure 81 Fragment du graphe global G, représentant de traces laissées par une annotation selon

le « SD générique »

Supposons maintenant qu'un deuxième utilisateur commence l'annotation d'une autre vidéo. Il ne connaît pas le « SD premier secours », il choisit donc le « SD général ». En regardant la vidéo il l'annote avec le terme « Homme en noir », choisi dans la « DA générale », avec le terme « Vérification » choisi toujours dans la « DA géné-rale », les met en relation et demande le système s'il y a d'autres termes, avec lesquels il pourra décrire sa vidéo. En faisant ses annotations il laisse les traces de la Figure 81. En plus des graphes potentiels qui exploitent la structure du modèle général Trèfle♣ (ceux de la Figure 79), nous pouvons mettre en places des graphes potentiels exploi-tant la structure spécifique du modèle d’utilisation et d’observation de l’application dont nous traçons l’utilisation. Ces graphes potentiels peuvent exploiter la structure du modèle de tâches ainsi que les relations entre les objets du modèle d’utilisation.

Trèfle ♣

145

Pour construire nos épisodes nous mettons en place le graphe potentiel de la Figure 82. Ce graphe potentiel permet de récupérer la trace formée par les annotations po-sées par un utilisateur selon un schéma de description.

P:Choisir DA

P:Choisir SD

P:Choisir EAA

*

*

*

*

Nt1

*


*

Nt2*

Figure 82 Graphe potentiel pour calculer des traces : « Annotations posées par un utilisateur »

Dans notre cas, l’instanciation du graphe potentiel « Annotations posées par un utili-sateur » appliqué au premier utilisateur dans le graphe global G et le tri chronologi-que du résultat donne la trace de la Figure 83.

O:EA_Homme en noir,t6 O:EA_Vérification,t10 O:Re,t12

t

O:EA_Lt. Tonton,t16 O:Re,t18

Figure 83 Trace calculée à l’aide du GP « Annotations posées par un utilisateur » pour

l’utilisateur Uconcr1

Nous pouvons remarquer que nous nous intéressons seulement aux annotations. En exploitant le modèle de tâches de l’application, nous récupérons grâce à ce graphe po-tentiel seulement les objets de type EA et Re, c’est à dire les annotations proprement dites, et les relations sans tenir compte des autres objets (SD, DA) qui ont été manipulés en même temps. De cette manière nous pouvons nous concentrer sur la fi-nalité de l’action de l’utilisateur, c’est à dire sur les annotations posées en ignorant les méthodes par lesquels ils ont été obtenus. Nous faisons cela pour pouvoir retrou-ver des cas d’utilisation quand ces mêmes annotations ont été utilisées pour décrire un document, mais dans le cas d’un autre schéma de description. Si l’on applique le même graphe potentiel aux traces laissées par le deuxième utilisa-teur (Figure 81) nous trouvons la trace calculée de la Figure 84 Comme nous pouvons le constater les épisodes calculés dans les figures Figure 83 et Figure 84 commencent avec des instances des mêmes objets.

O:EA_Homme en noir,t25 O:EA_Vérification,t29 Re,t30

t Figure 84 Trace calculée à l’aide du GP « Annotations posées par un utilisateur » pour

l’utilisateur Uconcr2


146

Après comparaison des épisodes ainsi calculés le système propose au deuxième utili-sateur d'annoter sa vidéo selon le « SD premiers secours » et donc de préciser encore une victime et la mettre en relation avec [Vérification,t29]. De cette façon nous obte-nons des annotations cohérentes. Il peut lui montrer les traces laissées par le premier utilisateur, pour qu’il puisse décider si oui ou non il adopte la démarche de celui-ci.

Trèfle ♣

147

4.3. Discussion

Nous avons présenté un modèle de mise en place de traces d'utilisation qui permet de suivre l'utilisation d'une application en mettant en contexte aussi bien les objets ma-nipulés que les procédés grâce auxquels cette manipulation a eu lieu ainsi que les uti-lisateurs qui ont œuvré. Nous avons défini les outils pour pouvoir tracer l’utilisation d’applications complexes pour fournir de l’aide pour la réalisation des tâches où l’expérience est importante. Grâce à ce modèle nous pouvons facilement récupérer les actions d’un utilisateur, ses sessions, mais également le contexte observé de son tra-vail. Ainsi nous pouvons calculer, identifier, comparer, adapter et réutiliser des épi-sodes selon plusieurs critères. Le modèle Trèfle♣ permet de modéliser les tâches, les utilisateurs, les contextes d’utilisation et les applications d’une façon transparente aussi bien pour le système que pour les utilisateurs. Il permet également de faire émerger de nouvelles façons d’utiliser une application. Il peut être implanté aussi bien sous la forme d’un système d’aide de type assistant que de type conseiller (voir section 2.6.1). Finalement il s’agit d’un modèle qui s’enrichit avec l’utilisation et qui laisse la possibilité d’intervention de l’utilisateur dans la manière dont ces actions sont tracées et réutili-sées. Le modèle se propose, donc de définir une syntaxe de représentation et un cadre sé-mantique des descripteurs. En plus des descripteurs le modèle permet de représenter, de sauvegarder et de réutiliser les actions de l'utilisateur à l'aide d'une même syntaxe. Les documents, leurs descriptions et les actions qui ont mené à la mise en place des descripteurs se fondent donc dans un seul capital d'expérience qui peut être revalorisé pour faciliter les futurs manipulations (annotation, recherche, visualisation) de docu-ments. Nous pensons que le modèle Trèfle♣ peut s’adapter à une large gamme d’applications permettant ainsi de représenter leurs traces d’utilisation sous la forme d’un graphe et d’utiliser les outils fondés sur la théorie de graphes pour exploiter ces traces. L’inclusion de nouveaux types de procédés dans le modèle d’utilisation afin de pou-voir suivre toutes les opérations du modèle E-SIA est une perspective de recherche à envisager. Nous construisons le modèle d’observation qui permet de tracer la naviga-tion dans les annotations et documents, la création et le raffinement de requêtes [Egyed-Zs. 2001]. Nous continuons également la formalisation des fonctions de similarité entre épiso-des, ainsi que les recherches sur les méthodes de présentation des cas jugés similaires. Il est important que l’utilisateur puisse repérer rapidement les différences entre les cas, ainsi que les meilleurs façons d’adaptation. Il serait intéressant d’étudier les différentes moyens dont un utilisateur peut disposer pour intervenir dans le calcul des traces. Ces problèmes relèvent des questions sur les interfaces homme machine. Des études pourront être faits également sur les différentes manières dont le système peut aider l’utilisateur. Nous pensons ici notamment sur la modification de l’interface de l’application en fonction du profil, de l’expérience et de la tâche de l’utilisateur, qui peut se concrétiser par le changement de l’ordre dans les menus, l’apparition d’icônes,…


148

Une autre piste d’amélioration du modèle peut être l’étude de la prise en compte de « l’ancienneté » des épisodes. En effet la distance dans le temps entre deux épisodes peut jouer sur leur similitude. Nous pourrons mettre en place une gestion un peu plus complexe des utilisateurs : gérer des groupes, créer de profils d’utilisateur et de groupe. Prendre en compte ses information lors du calcul de similarité entre épisodes. Nous envisageons d’implanter le modèle Trèfle♣ sur notre prototype d’annotation et recherche de vidéos présenté dans le chapitre 5. L’étude de la généralisation du modèle pour la prise en compte de l’exploitation, la manipulation et la recomposition de documents numériques peut être une piste inté-ressante. De même une des perspectives du modèle est de permettre le partage de l’expérience pour échanger des connaissances sur des documents numériques. Par les méthodes de traçage, il peut également servir dans des systèmes de flux de documents et flux de travail (workflow) ainsi que dans des systèmes de travail coopératif. En ef-fet le modèle Trèfle♣ permet de faire émerger des pratiques communes, des habitudes implicites des usages non prévus qui peuvent servir à améliorer des interfaces, des ordonnancements des méthodes, des conceptions. Le modèle Trèfle♣, par son caractère de structure de description de documents, peut être considéré comme un dépôt de souvenirs qui peuvent être partagés. Il peut être utilisé pour chercher les personnes qui savent quelque chose, chercher des personnes qui ont des expériences semblables au nôtres… D’un point de vue pratique nous suivons les travaux du groupe MPEG-2141 et ceux de l’équipe Experience On Demand42 du CMU.

41 http://mpeg.telecomitalialab.com/standards/mpeg-21/mpeg-21.htm (2002) 42 http://www.informedia.cs.cmu.edu/eod/ (2000)

Prototype

149

5. Prototype Ce chapitre décrit le prototype d’annotation et de recherche de vidéos développé autour du modèle E-SIA. Nous commençons par la présentation des objectifs du prototype. Nous continuons avec la description de l’architecture globale et la présentation des différents modules. Nous consacrons une section à la description de la représentation du graphe d’annotations en XML et en tables relationnelles, aspects détaillés plus amplement dans les annexes. Le travail de cette thèse a été réalisé dans le cadre d’un projet en collaboration avec France Télécom Recherche et Développement et INRIA. Ce projet est exploratoire, donc donne lieu à des recherches théoriques, présentés dans les chapitres précédents, mais vu son caractère industriel, il a nécessité la validation pratique des modèles et théories. Nous avons donc développé un prototype qui nous permettait d’un coté de faire des expériences sur nos modèles et d’un autre coté de valider ces modèles et démontrer leur faisabilité et utilité. Pendant les trois ans, que le projet RECIS a duré, nous avons eu des réunions trimes-trielles au cours desquelles de nouvelles fonctionnalités, solutions ont été présentées et de nouveaux problèmes et exigences posés. L'objectif de ce projet est d'étudier et de développer des outils permettant d’enrichir les services de recherche et d’accès à l’information multimédia. Il s'agit d'élaborer un système qui permette à l'utilisateur d'exprimer facilement et précisément sa requête, un système qui trouve rapidement des résultats pertinents, propose des moyens pour raffiner la requête et qui mette à disposition plusieurs méthodes de visualisation des résultats. Dans ce chapitre nous allons présenter le système développé, en insistant sur les as-pects d’innovation. La manipulation de documents audiovisuels la capitalisation et la réutilisation de l’expérience sont des domaines où il y a encore peu de systèmes in-formatiques fonctionnels. La plupart du temps, la validation n’était pas simplement du travail d’ingénieur car il fallait partir de modèles théoriques tout à fait inhabituels pour les outils informatiques. Il fallait construire, inventer des solutions pour mettre en œuvre ces modèles théoriques. Après une brève présentation des objectifs du prototype et du cahier des charges, cen-trés sur les technologies dont nous souhaitons démontrer la faisabilité, nous allons décrire comment le graphe du modèle théorique E-SIA a été implanté. Nous allons ensuite décrire le système qui a permis d’alimenter et de manipuler ce graphe ainsi que les premières pas de la couche d’observation et de capitalisation de l’expérience.


150

5.1. Objectifs

Les objectifs du prototype sont de démontrer la faisabilité des modèles théoriques créés et d’illustrer les techniques développées par les différents partenaires du projet RECIS. Dans le cadre de ce projet, France Télécom Recherche et Développement a apporté des techniques de traitement de vidéos, INRIA a fournit des solutions concer-nant l’indexation et la recherche des images. Le LISI, c’est à dire notre laboratoire a été chargé des aspects de structuration et exploitation des descripteurs de documents ainsi que de la capitalisation et réutilisation de l’expérience de l’utilisateur. Nous étions également les maîtres d’œuvres du prototype, France Télécom Recherche et Développement ayant le rôle du client industriel. Les techniques à implanter étaient :

- l’opérationnalisation et implantation du modèle E-SIA - l’annotation et la recherche de documents selon le modèle E-SIA - la gestion du vocabulaire et des éléments de structuration - la gestion des outils développés par les différents partenaires et leur fonction-

nement au sein d’une seule application - la mise à disposition des services de recherche et annotation de documents sur

le réseau.

L’un des objectifs du projet RECIS, qui est d’offrir une interface Homme-Machine multimédia, se traduit par la nécessité de concevoir un formalisme commun de des-cription d’une requête utilisateur et des séquences audiovisuelles. Il s’agit donc de concevoir et valider un modèle de description de haut niveau d’abstraction adapté d’une part à une séquence audiovisuelle et, d’autre part, à une requête utilisateur. Dans ce but, les recherches sont orientées selon les axes suivants :

- Elaboration de nouvelles interfaces de dialogue et perfectionnement de l’aide à l’utilisateur : celui-ci doit pouvoir formuler facilement ses requêtes et se pro-mener interactivement dans des séquences audiovisuelles. Les formulaires de requêtes qui seront définis devront être compréhensibles par le grand public. L’aide à l’utilisateur sera améliorée au moyen des techniques de bouclage de pertinence et de raisonnement à partir de cas.

- Conception des outils permettant de traduire les requêtes dans une forme exploitable par le processus de recherche.

- Extraction automatique des descripteurs de séquences audiovisuelles : descrip-teurs du son d’images et de la vidéo.

- Conception des schémas de description spécifiques aux données audio et vidéo. - Etude des processus de recherche dans les informations audiovisuelles, défini-

tion des mesures de similarité et de distance pour la mise en correspondance des images et du son.

Prototype

151

5.2. Cahier des charges

Suite aux premières discussions avec nos partenaires, nous avons mis en place un ca-hier de charges ainsi qu’une liste de contraintes. Le prototype doit permettre :

- la création d’éléments d’annotation abstraits (EAA), la création de dimensions d’analyse (DA) et de schémas de description (SD)

- l’annotation de vidéos à l’aide du vocabulaire et selon les schémas de descrip-tions

- la mise en place de requêtes basées sur les graphes potentiels - l’exécution de ces requêtes et l’affichage des résultats - ces fonctionnalités doivent pouvoir se faire à travers différents interfaces, dont

une interface accessible par internet - les descripteurs extraits de documents par les assistants développés par les dif-

férents partenaires doivent pouvoir s’intégrer automatiquement à celles posées à la main.

- Les contraintes les plus importantes sont :

- le module central de l’application doit être écrit en MS Visual C++ - les descripteurs doivent être stockés dans une base de données, mais doivent

pouvoir être exportés ou importés vers des représentations basées sur XML - les différents assistants se trouvent sur des sites différents reliés à internet et

accessibles via le protocole http uniquement (à cause de pare feux) - le prototype doit être modulaire et permettre l’ajout de nouveaux assistants

d’extraction de descripteurs de manière aisée


152

5.3. Architecture globale

Prenant en compte ces contraintes nous avons développé un prototype qui se compose de plusieurs modules. Les différents modules peuvent se trouver sur des ordinateurs distincts. L’architecture globale du prototype est présentée sur la Figure 85. Le dé-monstrateur est composé de 3 grandes parties différentes :

- l’application centrale - les interfaces homme machine - les assistants d’annotation

Serveur

Vidéos

Lt. Tonton

Verification

Massage

Freeing

cook

Lt. Tontoncook

CyclistNeighbor

Massage

FreeingVerification

All

AD: FiremanAD: VictimAD: Operation

ThesaurusFire

Fire

DS:Accident

AD: Fireman

AD: Operation

AD:Victim

Annotations

Images

Base dedonnées

Application centrale

WebServer

Client

Navigateur

Requêtes http(CGI - XML)CGI scripts

Assistants automatiquesd ’analyse d ’images, de

vidéos et du son

Interface decontrôle locale

Figure 85 Architecture globale du prototype

Dans l’annexe 8.1 nous avons mis d’autres schémas détaillant différents modules. Les modules communiquent entre elles à l’aide d’un protocole basé sur XML utilisant le protocole http. Au sein de chaque module il y a des sous-modules de traitement ainsi que des sous-modules de communication. Dans la suite nous allons présenter un peu plus en détailles ces trois modules.

5.4. Modules

5.4.1. Application centrale

Le module central du prototype est développé en Visual C++, en utilisant des contrô-les ActiveX et des bibliothèques téléchargés de l’internet :

Prototype

153

- XML4C d’IBM < http://www.alphaWorks.ibm.com/ > pour gérer les documents SML

- LEDA < http://www.mpi-sb.mpg.de/LEDA/leda.HTML > bibliothèque généri-que fournissant un ensemble d‘outils pour la gestion des graphes en mémoire

- MS Windows Media Player Control <http://agent.microsoft.com/directx/dxm/help/ds/amocx/amocx_intro.htm > pour visionner les vidéos.

L ‘application centrale est composée des sous modules suivants :

1. gestionnaire du graphe d’annotations 2. couche de liaison avec la base de données 3. interface homme machine de contrôle 4. couche de communication pour les assistants et les clients réseau

5.4.1.a) Gestionnaire du graphe d’annotations

Nous avons élaboré des représentations basées sur XML du graphe des annotations. Nous avons créé des objets C++ qui manipulent ce graphe (voir annexe 8.2). Nous avons également mis en place une structure de tables relationnelles pour stocker les graphes dans un système de gestion de bases de données. Nous allons détailler ces re-présentations dans la section 5.5. Le module de gestion du graphe est pilotable à tra-vers une interface de programmation (API) basé sur XML.

5.4.1.b) Gestionnaire de liaison avec la base de données

La couche de liaison avec la base de données implante les opérations de modification et recherche des annotations. Il est fondé sur les technologies ADO (ActiveX Data-base Objects) et ODBC (Object Oriented Database Connection) et permet une com-munication basé toujours sur XML avec le SGBD.

Lt. Tonton

Verification

Massage

Freeing

cook

Lt. Tontoncook

CyclistNeighbor

Massage

FreeingVerification

All

AD: FiremanAD: VictimAD: Operation

ThesaurusFire

Fire

DS:Accident

AD: Fireman

AD: Operation

AD:Victim

1. Module degestion desannotations

Base dedonnées

Application centrale

ODBC, ADO

Requêtes SQL et fragments XML

3. IHM

4. Couche decommunication

Ports decommunicationsocket

2. Module de liaisonavec la BdD

Figure 86 sous modules de l’application centrale


154

5.4.1.c) L’interface homme machine de contrôle

L’interface homme machine de contrôle, fournit la possibilité de contrôler l’évolution du système, les différentes requêtes des clients, les accès à la base de données et l’état des annotations. Elle permet également d’effectuer les opérations de base sur le gra-phe d’annotations. Un module d’annotation et de recherche a été également créé. Sur la Figure 87 nous présentons l'interface de l’application centrale du prototype E-SIA lorsqu'elle est utilisée pour annoter. L'annotation se fait soit de façon manuelle, soit de façon automatique grâce aux assistants développés par nos partenaires pour l'inclusion d'assistants basés sur le traitement d'image pour générer automatiquement des annotations. Lors de l’annotation manuelle à travers cette interface, l’utilisateur choisit une vidéo, la regarde et peut associer des termes de la base de connaissances à des fragments. Sur l’interface nous avons une vue de la base de connaissances (à gauche), une fenê-tre pour annoter la vidéo (en haut à droite) une vue permettant l’exploration du gra-phe (au milieu à droite) ainsi qu’une vue temporelle des fragments et des annotations (en bas).

Figure 87 Interface du prototype E-SIA en phase d'annotation

La Figure 88 présente la même interface en phase d'exploitation. Une requête est construite et lancée, et le résultat est affiché. En effet, nous avons la possibilité de construire des graphes potentiels, de les instancier et de regarder les sous-graphes qui leurs correspondent. L’interface présente une multitude de vues du graphe d’annotations. Nous avons in-troduit la notion d’élément actuel (la fenêtre en bas à gauche) qui trace indépendam-ment des vues les éléments sélectionnés et permet de les faire apparaître dans des vues différentes fournissant ainsi des possibilités de navigation multi-modales dans le graphe.

Prototype

155

Figure 88 Interface du prototype en phase d'exploitation

L’interface homme machine permet également de suivre l’activité type serveur de l’application centrale. Les requêtes passées par les utilisateurs et les assistants sont tracés et affichés en temps réel dans une fenêtre dédié. Des interfaces plus conviviales et évoluées de manipulation des annotations et créa-tions de requêtes ont été développées sous la forme de clients accessibles par un na-vigateur internet. Ils seront présentés dans la section 5.4.2.

5.4.1.d) Couche de communication pour les assistants et les clients réseau

La couche de communication contient les méthodes permettant à l’application cen-trale d’interagir avec les assistants et les interfaces homme machine distante. La communication repose sur deux technologies.

- Pour les interactions sur une même machine, nous utilisons la technique des Sockets, communication directe entre deux partenaires (peer to peer) permettant l’envoie et la réception des chaînes de caractères. Nous avons développé un protocole de communication basé sur XML.

- Pour les interactions entre des modules se trouvant sur des machines différentes les messages passent en utilisant le protocole http (HyperText Transfer Proto-col). Cela suppose la présence d’un serveur web sur les machines qui doivent recevoir des messages.

La Figure 89 présente l’architecture du serveur central, la machine contenant l’application centrale, la base de données, un serveur web et un ensemble de scripts CGI (Common Gateway Interface).


156

•

Gestiondes

sessions

Couche de communication par

Sockets (applicationslocales) et HTTP

(scripts CGI distants)

Gestion des annotations

Script CGI

Assistants

Client : Navigateur

Web

IHM de contrôle

du serveur

Script CGIScript CGIScript CGI

Communication HTTPCommunication parSocket

2

4

1

3

Script CGIScript CGIScript CGI

Script CGI

Communication au seinde l’application

BdD

Serveur central

Serveur Web

Serv

eur W

eb

56

Figure 89 les modules du serveur central

1. Couche de communication par sockets et HTTP : 1. Gère les communications entre tous les processus de l’application centrale 2. Reçoit, au travers de scripts CGI, les requêtes clients 3. Envoie des requêtes aux autres modules par communication HTTP directe

et reçoit leurs réponses par l’intermédiaire de scripts CGI 4. Transforme les réponses en XML et HTML

2. Processus de Gestion de Session : Identifie les utilisateurs et gère tous les traitements effectués par chaque utilisateur ( garde trace de l ’avancement des traitements en cours, des traitements déjà effectués …).

3. Processus de gestion des annotations : permet de stocker et d ’exploiter les annotations au format ESIA dans la base de données.

4. Interface Homme Machine de contrôle : doit permettre l ’observation directe des opérations effectuées sur le module 5 afin de contrôler le comportement du serveur.

5. Les scripts CGI pour les interfaces homme machine : servent de passerelles pour distribuer à l’application les requêtes des clients et pour renvoyer aux clients les résultats sous forme de pages HTML ou documents XML.

6. Les scripts CGI pour les des assistants : Les assistants sont lancés à l’aide d’appels de scripts CGI et quand ils ont terminé les traitements, ils appellent à leur tour les scripts CGI du serveur central pour lui envoyer leurs résultats sous forme de documents XML passés comme paramètre CGI.

Nous donnons plus de détailles sur la mise en œuvre de la communication dans l’annexe 8.8.

Prototype

157

5.4.2. Les interfaces homme machine

Pour pouvoir utiliser l’application à distance, nous avons mis en place un ensemble d’interfaces basées sur des navigateurs internet. Cet ensemble se compose d’une ap-plication graphique en java et d’un site interactif basé sur des formulaires en HTML. L’application java reprend les fonctionnalités expertes de base : manipulation du vo-cabulaire, des schémas de description, annotation des vidéos, création de requêtes. Le site dynamique fournit une approche plus simple, cache la complexité du modèle en fournissants une série de parcours prédéfinis pour la mise en place des annotations et l’exploration des documents annotés.

5.4.2.a) L’application java

Cette application se lance à partir d’un navigateur internet. Pour communiquer avec le serveur, il utilise le protocole http pour envoyer des requêtes en XML. Les traces de manipulation de l’utilisateur ainsi que les réponses du serveur sont traduites d’abord en XML avant d’être envoyés. L’interface permet d’explorer les annotations sous la forme d’un graphe (Figure 90). Une vue temporelle des unités audiovisuelles est éga-lement disponible. Dans chaque vue nous avons la possibilité de voir les détailles des nœuds. Par exemple s’il s’agit d’un élément d’annotation, nous pouvons voir ces at-tributs, s’il s’agit d’une unité audiovisuelle nous pouvons la visualiser. Nous avons également la possibilité d’implanter des vues spécifiques pour certains annotations, comme les images clés par exemple.

Figure 90 Interface graphique d'exploitation des annotations (applet java)

Une vue dans des listes a été également implantée (Figure 91) pour voir les éléments du graphe regroupés par leur type. Ces vues en liste peuvent exploiter certains rela-


158

tions du graphe. Il est possible par exemple de relier la liste des éléments d’annotations abstraits (EAA° à la liste des dimensions d’analyse (DA) ainsi lors de la sélection d’une dimension d’analyse, la liste des EAA se met à jour automatique-ment en affichant uniquement les termes contenus dans la dimension d’analyse sélec-tionnée. De la même manière il est possible de relier les listes SD et DA, EAA et EA et EA et UAV.

Figure 91 Interface d'exploitation des annotations 2 (applet java)

Prototype

159

Figure 92 Interface Java en phase d’annotation selon un SD

L’application java permet l’annotation d’un flux selon un schéma de description (Figure 92). En effet après avoir choisi le flux et le schéma de description l’utilisateur a une vue de ce dernier (à droite sur la figure). Il peut choisir dans la liste des dimen-sions d’analyse inclues dans le schéma de description un élément d’annotation, préci-ser le début et la fin du fragment vidéo auquel il veut l’associer et poser l’annotation (en bas à gauche sur la figure). Les annotations créées sont également affichées dans une vue de graphe (en haut à gauche) pour que d’éventuelles relations puissent être mises en place. L’annotation ne peut être sauvegardée seulement si elle est conforme au schéma de description. Nous avons mis en place un système de vérification qui in-dique précisément les éventuels incohérences, les éléments ou relations en trop ou manquants.

5.4.2.b) Le site dynamique

Pour les utilisateurs novices, nous avons mis en place un site web dynamique qui permet d’annoter et de rechercher des vidéos à travers des pages contenant des formu-laires spécifiques. Ce site permet uniquement une utilisation prédéfini. Il est en effet utile dans le cadre d’annotation de documents au sein des institutions qui ont un cer-tain nombre de types de documents et des manières bien définies de les annoter. Nous avons créé des procédures d’annotation (PA) pour imposer une démarche à sui-vre lors de l’annotation d’un document. Une procédure d’annotation est une suite opérations effectuées à l’aide d’assistants manuels ou automatiques qui sont appli-qués un après l’autre sur un document. Par exemple une procédure d’annotation peut être composée des opérations suivantes :


160

- découpage en plan de la vidéo - extraction des images clés de chaque plan - indexation de ces images clés - transcription de la bande de son par reconnaissance de la parole.

L’utilisation du site web dynamique est basée sur les sessions. La Figure 93 présente le diagramme de transition entre les différentes fenêtres. Les cercles représentent les types de fenêtres, les arcs les événements qui mènent d’une fenêtre à l’autre. Un utilisateur doit d’abord se connecter (1). Le centre de cette interface homme ma-chine est la page d'accueil (2, Figure 94). Ici sont proposés à un utilisateur identifié tous les opérations qui peuvent être effectués : lancer une nouvelle annotation ou bien continuer une procédure d'annotation déjà commencée, effectuer une recherche. En effet les sessions sont sauvegardées et suivies par le système. Un utilisateur peut lancer plusieurs procédures d’annotation sur des documents en parallèle. Comme l’exécution de certains assistants peut durer plusieurs heures, le système gère automa-tiquement l’évolution des procédures et indique à l’utilisateur l ‘état actuel de ses dif-férentes opérations. Une fois une opération d’une procédure d’annotation terminée, le système peut demander sa validation manuelle par l’utilisateur ou bien passer à l’opération suivante. En effet, comme les résultats d’outils automatiques ne sont pas 100% fiables il est intéressant de proposer à l’utilisateur une interface à travers la-quelle il peut valider ou modifier ces résultats. Par exemple lors de la détection des plans d’une vidéo, certains coupures sont ignorées43, dans d’autres cas des mouve-ments brusques sont interprétés par l’outil comme étant des coupures. Après un dé-coupage automatique en plans une interface permettant de fusionner ou découper à la main les plans mal détectés peut considérablement améliorer la pertinence des résul-tats. Bine sûr une intervention manuelle n’est pas envisageable lors du traitement de grandes quantités de vidéos. Le système de procédures d’annotation permet de confi-gurer librement le passage entre différentes opérations.

43 Des coupures avec effets visuels, comme des fondus enchaînés, sont difficiles à détecter

Prototype

161

1 Login

2 Paged'accueil

3 Choix du fluxà annoter

4 Choix de PA

5 Présentation de la PAavec l’opération actuelle

mise en avant

6 Paged’Erreur deconnexion

RechercherAssistant

Login OK

Annotation

Login error

lien directe

Recherche

Lancer Annotation

Continuer une PA Active

Lancer traitementavec interaction

Traitement terminé

Déconnexion

Déconnexion

Déconnexion

Annuler

Annuler

Annuler

Déconnexion

Lancer traitement long

Figure 93 Diagramme de transition entre les différentes pages

Figure 94 Page d’accueil du site dynamique

Sur la Figure 94 nous représentons la page d’accueil d’un utilisateur qui a déjà lancé la procédure d’annotations « PA test annotation manuelle Acteurs… » et qui peut an-noter une nouvelle vidéo, avoir des détailles sur la procédure d’annotation qu’il a déjà lancé, continuer ou annuler l’exécution de la procédure d’annotation. Une fois une


162

procédure d’annotation terminée, elle est effacée du tableau de la page d’accueil. Nous donnons plus de détailles sur le site dynamique dans l’annexe 8.4.

5.4.3. Les assistants

Dans le cadre du projet RECIS, nos partenaires ont créé des assistants de traitement automatique de documents audiovisuels. Ainsi l’équipe de France Télécom Recherche et développement a mis en place des outils qui permettent de détecter les coupures de plan dans une vidéo, d’en extraire des images, de suivre des objets ou encore recher-cher des mots dans une bande de son. A l’INRIA l’équipe de recherche a mis en place un système d’indexation et de recherche d’images. D’autres assistants sont susceptibles de voir le jour dans le futur. Une partie de ces applications doivent s’exécuter sur les machines de nos partenaires, dans leurs lo-caux, pour des raisons techniques et politiques. Il fallait donc mettre en œuvre un sys-tème qui a permis de piloter les applications à distance. Nous avons conçu une couche de communication utilisant uniquement le protocole http pour dialoguer avec les as-sistants, leurs transmettre les instructions, les données et de récupérer leurs résultats. Coté application centrale nous avons créé une interface de programmation normalisée (voir Annexe ) pour que les assistants aient accès à des fonctions d’intégration de ré-sultats et d’exploration des annotations. En plus de cette interface un utilitaire d’enregistrement de nouveaux assistants a été développé. Actuellement nous avons les assistants suivants :

- détecteur de coupures de plan dans une vidéo - extracteur automatique d’images clés de plans d’une vidéo - extracteur manuel d’images d’une vidéo - inscription, analyse et recherche d’une image dans une base d’images (la re-

cherche se fait à l’aide d’images exemples).

Prototype

163

5.5. Graphes sérialisés

Après le premier développement du modèle Strates-IA, par Y. Prié [Prié 1999] la question de l’implantation s’est posé. A l’époque nous avons étudié plusieurs repré-sentation du modèle théorique à l’aide d’un formalisme compréhensible par l’ordinateur [Egyed-Zs. 1999], et nous sommes arrivées à un modèle basé sur XML. Avec l’évolution des Strates-IA en E-SIA, la structure du graphe a changé, modifiant ainsi les contraintes sur la représentation. Nous avons mis en place une nouvelle re-présentation, toujours basé sur XML. En même temps, un schéma relationnelle pou-vant stocker les données XML a été également développé et implanté. Ainsi le graphe d’annotation et actuellement géré à l’aide d’un système de gestion de bases de don-nées relationnelles tout en gardant la possibilité d’être exporté ou importé à partir d’une représentation en XML. Dans cette section nous allons d’abord présenter la sérialisation du graphe des annota-tions en XML puis décrire la structure de la base de données relationnelles.

5.5.1. Représentation en XML des objets E-SIA

La sérialisation du graphe E-SIA dans un langage basé sur XML était une de nos premières préoccupations. Nous avons un graphe qui représente des annotations (STRATES-IA). Nous avons un langage de balises (XML) qui permet de créer des documents structurés. Nous avons un algorithme qui permet de rechercher des sous-graphes dans cette représentation d’annotations (multipropagation). Il faut représenter le graphe dans un langage pour que l’algorithme s’applique le plus facilement et de façon optimale. Le tout dans le but de développer un support pour un futur cadre de création, d’utilisation et d’exploitation de ces annotations. Nous avons étudié d’abord les possibilités de découper le graphe, ensuite nous avons cherché les structures syntaxiques dérivant de XML les plus adaptées pour sa repré-sentation. Plusieurs groupes de travail proposent des solutions, des langages spécialisés pour re-présenter des graphes en XML, par exemple : GXL (Graph Exchange Language) [Schürr 2000], XGMML (eXtensible Graph Markup and Modeling Language) [Punin et al. 2000], GraphXML [Herman et al. 2000], XLink [W3C 2000c], RDF (Re-source Description Framework) [W3C 2000a], [Hunter et al. 1998] ,[Layman], [Liechti et al. 1998], [Auffret et al. 1999]. Certains de ces travaux, considèrent la représentation du graphe comme un seul document, d’autres permettent sa répartition. Nous avons finalement construit des modèles représentatifs des différentes solutions. Nous avons défini des critères de comparaison et nous avons étudié les modèles pro-posés selon ces critères. En effet pour pouvoir être manipulé, le graphe des annota-tions devait être représenté sous une forme compréhensible par un ordinateur. Nous avons Nous avons élaboré plusieurs modèles [Egyed-Zs. 1999, Egyed-Zs. et al. 1999b, Egyed-Zs. et al. 1999a, Egyed-Zs. et al. 2000] de représentation du graphe E-SIA en XML pour finalement arriver à une solution multi-document avec les liens externes. Le découpage a été fait de la façon suivante :


164

1. Nous avons mis en place un ensemble de documents XML pour la base de connaissances.

2. Pour chaque flux annoté nous créons également un ensemble de documents XML.

Dans chaque ensemble ainsi créé, un document contient les nœuds (EA et UAV pour les flux, EAA pour la base de connaissance), sans liens. Un document « liens » est créé pour chaque couple de documents contenant des nœuds. Ainsi les relations entre la base de connaissance et les annotations du flux « Flux1 » seront sauvegardées dans le document « Liens_BdC_Flux1.xml », les relations internes à la base de connais-sances dans le document « Liens_BdC_BdC.xml ». Dans chaque ensemble il y a un document contenant la liste des documents liens. Nous avons choisi cette représenta-tion multi-documents pour pouvoir éclater les annotations sur plusieurs sites physi-ques. En effet puisque les annotations, liens et le vocabulaire sont dans des fichiers distincts ils peuvent se trouver sur distribués sur un réseau. Pour la base de connaissances (voir Figure 95), un document contient les EAA-s (BdC.xml, voir structure (DTD) dans l’annexe 8.5.1.a)). La liste des fichiers « liens » est contenue dans le document « Liste_BdC.xml ». Les liens sont représentés dans des documents séparés (voir structure (DTD) dans l’annexe 8.5.3.a)).

BdC.xml

EAA

EAA

EAA

EAA

EAA

Fichier_Liens

Liste_BdC.xml

Liens_BdC_Flux1.xml

LiensSortants

LiensSortantsLiensSortants

Fichier_Liens

Liens_BdC_Flux2.xml

LiensSortants

LiensSortants

LiensSortants

vers les EA-s de Flux1

vers les EA-s de Flux2

Liens_BdC_BdC.xml

LiensSortants

Liens internesreliant lenoeud racine virtuel aux

autres termes

Fichier_Liens

Figure 95 : Structure des documents représentant la Base de Connaissances et ses relations

La Figure 96 présente l’ensemble de documents représentant les annotations du flux « Flux1 ». On retrouve le document XML contenant les sommets du graphe (Flux1.xml) ainsi que les documents contenant les liens.

Prototype

165

Flux1.xml

EA

UAVEA

EAUAV

Fichier_Liens

Liste_Flux1.xml

Liens_Flux1_BdC.xml

LiensSortants

LiensSortantsLiensSortants

Fichier_Liens

Liens_Flux1_Flux2.xml

LiensSortants

LiensSortants

vers les EAA-s de la basede connaissances

vers les EA-s de Flux2,relations élémentaires

Liens_Flux1_Flux1.xml

LiensSortants

Liens internes reliant les EA-s et lesUAV-s (Ra et Ra

-1)

Fichier_Liens

LiensSortants

Figure 96 : Structure des documents représentant les annotations du Flux1

L’ensemble de documents XML ainsi créés peut être représenté comme un graphe connexe. Nous donnons les DTD et des exemples de documents dans l’annexe 8.5.

5.5.2. Graphes en Tables

La validation des modules logiciels développés dans le cadre de ce projet nécessite le stockage d’un volume important de données complexes (séquences audiovisuelles, descripteurs). Le simple stockage d’information dans un ensemble de fichiers n’étant pas satisfaisant (pas de gestion des accès, contraintes d’intégrités difficiles à gérer, …), une approche de type SGBD s’est imposée. Une étude, qui consiste à confronter trois approches en concurrence (l’approche rela-tionnelle, l’approche orientée objet et l’approche semi-structurée) aux besoins spéci-fiques du projet RECIS a été effectué avec Soizic Donnet [Donnet 2002] . Cette con-frontation fait apparaître les limites de chaque approche. Une fois le choix du type de SGBD effectué, nous avons conçu le schéma de base de données de façon à le con-former au modèle E-SIA (voir annexe 8.7). Nous avons choisi de stocker le graphe des annotations dans des tables relationnelles à l’aide du système de gestion de bases de données de Microsoft, SQL Server 2000. Nous présentons plus de détailles sur le choix du SGBD dans l’annexe 8.6. Actuellement le prototype gère les annotations à l’aide de système de gestion de base de données.


166

5.6. Discussion

Dans ce chapitre nous avons présenté le prototype développé pour opérationnaliser le modèle E-SIA, ainsi que pour démontrer la faisabilité d’un système d’annotation et de recherche de documents multimédias basé sur ce modèle. L’objectif a été atteint. Nous avons mis en place une application qui permet l’annotation et la recherche des fragments de vidéos, repose sur le modèle E-SIA. De plus elle permet d’intégrer les résultats d’outils d’analyse de documents semi-automatiques et met à la disposition des utilisateurs l’accès aux documents et annota-tions à travers des interfaces web. Lors de la conception de l’application nous avons veillé à garder une modularité et une évolutivité. Les interfaces sont basées sur des standards (http, XML, sockets), les protocoles de communication simples et documentés. Nous ne pouvons dire néanmoins qu’il s’agit d’un produit fini. Le modèle théorique est toujours un pas en avance sur l’implantation, il reste donc à mettre en place un suivi et une capitalisation complète des actions de l’utilisateur, pour pouvoir mettre en place les méthodes de réutilisation de l’expérience présentées dans le chapitre 4. Nous prévoyons de faire une interface capable de lire et de produire des documents au format MPEG7. Nous avons suivi depuis le début l’évolution de ce standard, ce qui nous avait conduit à adopter XML comme format d’échange. Nous étudions également la mise en place de nouvelles interfaces, basées sur les nor-mes : SVG, SMIL, Flash, … ainsi que la génération automatique d’interfaces de pré-sentation. Un exemple concret est de générer une présentation en SMIL qui affichera les annotations textuelles sous la forme de sous-titres sur une vidéo. Pour cela nous mettrons en place des feuilles de style XSL pouvant produire une multitude de for-mats de sortie, contenant des résultats de requêtes, différentes vues des annotations ou encore des requêtes. Une piste concrète dans cette direction est l’étude de métho-des de présentation liées aux schémas de description. En effet, puisqu’un schéma de description définit une structure d’annotation, il est facilement imaginable que les an-notations ayant cette structure puissent se représenter de manière spécifique.

Conclusion

167

6. Conclusion L’objectif de nos recherches était de proposer des représentations, des méthodes et des outils pour enrichir les services d’accès au contenu multimédia et plus particuliè-rement aux contenus audiovisuels disponibles sur un réseau. Pour élaborer ces propo-sitions, nous avons étudié les systèmes existants de manipulation de documents mul-timédias et nous avons pris la parti d’aborder les choses par la gestion des connaissances dans une base de documents multimédias, car c’est en utilisant les connaissances issues aussi bien des documents que des actions de l’utilisateur que nous pouvons enrichir les services liés à ces documents. Les documents contiennent de manière intrinsèque des connaissances, qui ont besoin d’être formalisées et explicitées pour pouvoir être utilisables aussi bien par la ma-chine que par les utilisateurs humains. Puisqu’il s’agit de documents multimédias-audiovisuels, la formalisation et l’explicitation doivent jouer un rôle de synthèse, de résumé pour l’utilisateur humain. En effet par leur taille et par leur caractère temporel pour les documents audiovisuels, un utilisateur humain n’a pas le temps physique pour les exploiter in extenso. Dans un premier temps nous avons étudié les méthodes pour « résumer » les docu-ments par des annotations. Nous avons mis en place un modèle de description, le mo-dèle E-SIA qui permet d’organiser les annotations et les éléments qui les structurent en un graphe orienté, étiqueté et connexe. Nous avons opté pour l’utilisation d’un vo-cabulaire contrôlé, contenant les termes (éléments d’annotation abstraits EAA) avec lesquels les documents peuvent être annotés. Ce vocabulaire est extensible par les uti-lisateurs. Il n’y a pas de structure globale entre les termes, ils forment un ensemble « plat ». Les EAA peuvent avoir des attributs. Un attribut peut être aussi bien textuel, qu’image, son, vecteur, objet, … n’importe quel type défini au préalable et doté des méthodes de visualisation ainsi que d’une liste de fonctions de similarité. Les EAA définissent donc les termes avec des attributs qui peuvent être instanciés pour annoter des fragments de documents. Nous avons introduit des éléments qui permettent une structuration locale du vocabu-laire permettant de regrouper des termes en ensembles pour former des hiérarchies lo-cales pour une tâche d’annotation donnée. Ces structures (dimensions d’analyse DA, schémas de description SD) permettent de définir des méta-données pour documenter et guider l’annotation. Cela est important car une description manuelle de documents multimédias peut être extrêmement variée et subjective. En consultant uniquement les schémas de description utilisés pour annoter un grand volume de documents, un utili-sateur peut avoir un résumé précis des termes et structures utilisés tant pour annoter que pour formuler des requêtes pertinentes. Nous avons implanté un outil d’exploitation, appelé graphe potentiel qui permet de faire des recherches dans les annotations ou encore naviguer de manière contextuelle, créer des vues, des projections, etc. Nous avons implanté ce modèle dans un prototype client-serveur qui permet l’annotation manuelle et automatique de documents ainsi que l’exploitation des anno-tations, la construction et exécution des requêtes. Ce prototype client serveur intègre les outils de traitement automatique de vidéos et images de nos partenaires dans le projet RNRT RECIS de nos recherches. Cette première partie de nos travaux de recherche nous offre la possibilité d’expérimenter et de valider l’annotation et la recherche de documents audiovisuels selon nos modèles. Nous avons pu constater les difficultés et la complexité de la des-


168

cription de vidéos et d’images à l’aide de termes. Nous avons étudié par la suite les modalités pour assister les utilisateurs humains dans leur tâche d’annotation et de re-cherche afin de faciliter l’exploitation des documents. Nous avons cherché à mettre en place des méthodes pour guider l’annotation et le raffinement des requêtes pour aboutir rapidement à des résultats de recherche pertinents. Le deuxième volet de nos recherches concerne le traçage de l’utilisation de l’application d’annotation et de recherche de documents numériques en vue de capita-liser et de réutiliser l’expérience des utilisateurs. Le caractère subjectif des documents multimédia, le fossé sémantique qu’ils représen-tent pour les utilisateurs humains nous a amené à créer un modèle qui prend en compte les usages pour une assistance « en contexte » exploitant l'analogie de situa-tions. Ce modèle permet au système de détecter les similarités entre les manières dont les utilisateurs décrivent les documents afin de les guider vers une description plus homogène ou bien les aider dans le raffinement de leurs requêtes. Au-delà des systèmes de gestion de contenus audiovisuels l’idée de base de notre mo-dèle est le fait que dans une application informatique des utilisateurs manipulent des objets à travers des procédés. En ayant mis en place une structure de graphe pour les annotations de documents avec un outil souple et robuste pour l’exploiter, que sont les graphes potentiels, nous avons naturellement continué d’utiliser le graphe comme structure de base pour notre modèle. Nous avons étendu le graphe d’annotations en lui rajoutant deux autres « feuilles » (familles de nœuds) formées par des nœuds re-présentant les utilisateurs et les procédés. Ainsi les annotations, les fragments de do-cuments et les éléments de structuration sont considérés comme des objets, les diffé-rentes fonctions et actions possibles de l’application forment les procédés et des identificateurs d’utilisateurs et de groupes constituent les nœuds représentant les uti-lisateurs. Cette nouvelle structure regroupant dans un graphe connexe, orienté et éti-queté ces trois familles de nœuds donne naissance au modèle Trèfle♣. Ce modèle permet de tracer d’une manière contextuelle l’utilisation d’une application permettant ainsi un calcul d’épisodes d’utilisation alimentant une base de cas réutilisables au sens du raisonnement à partir des cas. Dans la pratique le modèle Trèfle♣ doit être appliqué à un logiciel pour lequel nous voulons fournir de l’aide. Dans un premier temps il faut définir le modèle d’utilisation c’est à dire l’ensemble des objets manipulables par le système dont nous désirons tracer la manipulation. Dans le cas de notre application d’annotation et de recherche de documents multimédias le modèle d’utilisation est formé par les termes (EAA) et les éléments de structuration de vocabulaire (DA, RDA et SD). La deuxième étape est la définition du modèle d’observation. Ce modèle composé de l’ensemble d’opérations que nous traçons ainsi que des structures représentant les uti-lisateurs et les groupes définit une sorte de filtre à travers lequel le système est obser-vé. Nous devons enfin mettre en place les suites de méthodes de calcul, de comparai-son et d’adaptation de traces à l’aide de graphes potentiels. Une fois ces éléments définis le modèle Trèfle♣ peut être considéré comme appliqué à un système et le traçage des actions de l’utilisateur et la réutilisation de l’expérience ainsi capitalisée peuvent démarrer. Chaque session d’un utilisateur se traduit par la création d’un ensemble de nœuds du graphe représentant les opérations qu’il a lan-cées et les objets manipulés. Les nœuds ainsi créés sont appelés également des nœuds concrets par opposition aux nœuds abstraits formant les modèles d’utilisation et d’observation. Les nœuds concrets sont situés dans le temps, nous savons à quel ins-tant ils ont été créés (lancés pour les nœuds de type procédé, manipulés pour les

Conclusion

169

nœuds de type objet ou connectés pour les nœuds de type utilisateur) et ils dérivent d’un nœud abstrait. Des traces d’utilisation peuvent être calculées de plusieurs maniè-res en utilisant les graphes potentiels et les relations multiples du graphe de traces. Nous pouvons par exemple calculer l’ensemble des opérations effectuées ou l’ensemble des objets manipulés par un utilisateur lors d’une session d’utilisation. Nous pouvons calculer toutes les manipulations subies par un objet ou un type d’objet ou encore la fréquence d’utilisation d’un certain procédé. De cette façon des situa-tions similaires peuvent être repérées facilement et un utilisateur qui a besoin d’aide peut être assisté en se basant sur les expériences d’autres utilisateurs. Le modèle Trèfle♣ devrait être applicable non seulement aux systèmes d’annotation et de recherche de documents audiovisuels mais à bien d’autres logiciels pour les-quels nous pouvons définir un modèle d’utilisation et d’observation et pour lesquels la mise en place d’un système d’aide et d'assistance basé sur la réutilisation de l’expérience est utile. Pour résumer : nos recherches se sont déroulées dans le cadre d’un projet RNRT ap-pelé RECIS en collaboration avec France Télécom R&D et INRIA. Le but de ce pro-jet est d’étudier les modalités pour enrichir les services d’accès au contenu multimé-dia. Nous avons mis en place un modèle d’annotation de documents audiovisuels : E-SIA. Ce modèle représente les fragments de documents, les annotations ainsi que les élé-ments de structuration des annotations en un graphe. Ce modèle permet de documen-ter et de guider l’annotation tout en laissant une grande liberté aux utilisateurs. Nous avons implanté un outil robuste d’exploitation, les graphes potentiels. Pour valider ce modèle nous avons développé un prototype client serveur qui permet l’annotation manuelle et automatique de documents ainsi que la navigation et la recherche dans les annotations. Pour l’annotation automatique nous avons intégré des outils de traite-ment d’image, du son et de la vidéo crées par nos partenaires dans le projet RECIS. Nous avons étendu notre modèle d’annotations pour créer un cadre de traçage, de ca-pitalisation et de réutilisation de l’expérience : Trèfle♣. Ce modèle permet de tracer l’utilisation d’un logiciel de manière contextuel à travers un modèle d’utilisation et d’un modèle d’observation.


170

Références

171

7. Références

[Aamodt et al. 1994] A. AamodtE. Plaza, 1994, Case-Based Reasoning: Foundational Is-sues, Methodological Variations, and System Approaches, AI Communications, 1994, Vol. 7, No. 1, pp. 39-59.

[Abiteboul 1999] S. Abiteboul, 1999. On Views and XML, PODS ‘99, Philadelphia USA, 1999, pp. 1-9

[Adobe 2002] Adobe, 2002, Premiere 6.0 (Logiciel), http://www.adobe.com/products/premiere/main.html , Consulté le 13.01.2002

[Aguierre-Smith et al. 1992] T. G. Aguierre-SmithG. Davenport, 1992. The stratification system, a design environment for random access video, Network and Operating System Support for Digital Audio and Video - 3rd International Workshop, San Diego, USA, 1992, pp. 250-261

[Allen 1983] J. Allen, 1983. Maintaining temporal knowledge about temporal intervals, ACM, 1983, pp. 832-843

[Altavista 2003] Altavista, 2003, Altavista, [en ligne] http://www.altavista.com/, Consulté le: 01.10.2003.

[Amore 1997] Amore, 1997, Amore, [en ligne] http://www.ccrl.com/amore/, Consulté le: 01.10.2002.

[Amous et al. 2002] I. AmousA. Jedidi, 2002. Modélisation des métadonnées pour une re-composition dynamique des documents, INFORSID, Nantes (F), 2002, pp. 243-258

[Auffret et al. 1999] G. Auffret, J. Carrive, O. Chevet, T. Dechilly, R. Ronfard, B. Bachi-mont, 1999. Audiovisual-based hypermedia authoring : using structured repre-sentations for efficient access to AV documents, ACM Hypertext'99, Darmstadt, DE, 1999, pp. 169-178

[Aupetit et al. 2003] S. Aupetit, N. Monmarché, C. Guinot, G. VenturiniM. Slimane, 2003. Exploration de données multimédia par réalité virtuelle, Extraction et ges-tion des connaissances (EGC), Lyon, Fr, 2003, pp. 71-82

[Auriol et al. 1999] E. Auriol, R. M. Crowder, R. MacKendrick, R. Row, T. Knudsen, 1999, Integrating Case-Based Reasoning and Hypermedia Documentation: An Application for the Diagnosis of a Welding Robot at Odense Steel Shipyard, Lec-ture Notes in Computer Science, 1999, Vol. 1650, No. 1, pp. 372-384.


172

[Bachimont 1999] B. Bachimont, 1999, Bibliothèques numériques audiovisuelles : des en-jeux scientifiques et techniques., Document Numérique, 1999, Vol. No. 2, pp. 219-242.

[Bagwell 1998] C. Bagwell, 1998, Audio File Formats FAQ, [en ligne] http://home.attbi.com/~chris.bagwell/AudioFormats.html, Consulté le: 10.03.2003.

[Baldonado et al. 2000] M. Q. W. Baldonado, A. Woodruff, A. Kuchinsky, 2000. Guideli-nes for Using Multiple Views in Information Visualization, Advanced Visual In-terfaces, 2000, pp. 110-119

[Bargeron et al. 1999] D. Bargeron, A. Gupta, J. Grudin, E. Sanocki, A. Mendelzon, 1999, Annotations for streaming video on the Web: system design and usage studies, Computer networks, 1999, Vol. 31, No. 11-16, pp. 1139-1153.

[Bataille et al. 2002] E. Bataille, M. Oussalah, P. Tchounikine, 2002. Relations sémanti-ques pour l'ingénierie documentaire, INFORSID, Nantes, F, 2002, pp. 89-106

[Bénel et al. 2001] A. Bénel, E. Egyed-Zs., Y. Prié, S. Calabretto, A. Mille, I. Andréa, P. Jean-Marie, 2001. Truth in the Digital Library: From Ontological to Hermeneu-tical Systems, ECDL 2001 European Conference on Research and Advanced Technology for Digital Libraries, Darmstadt (D), 2001, pp. 366-377

[Benitez et al. 2000] A. B. Benitez, S. PaekS.-F. Chang, 2000, Object-Based Multimedia Description Schemes and Applications for MPEG-7, Image Communications Journal, 2000, Vol. 16, No. 1, pp. 235-264.

[Benoît 2002] H. Benoît, 2002, La télévision numérique. Paris: Dunod, 2002, 232 p.

[Bes et al. 2002] F. BesC. Roisin, 2002. A Presentation Language for Controlling the Formatting Process in Multimedia Presentations, ACM Symposium on Docu-ment Engineering, McLean, Virginia, USA, 2002, pp. 2-9

[Bird et al. 2000] S. BirdM. Lieberman, 2000. A Formal Framework for Linguistic Anno-tation, University of Pennsylvania Tech Report MS-CIS-99-01, Dept of Compu-ter and Information Science 30p. 2000

[Birnbaum et al. 1998] L. Birnbaum, R. Bareiss, T. HinrichsC. Johnson, 1998. Interface Design Based on Standardized Task Models, ACM Intelligent User Interfaces, San Francisco CA, USA, 1998, pp. 65-72

[Bolle et al. 1998] R. M. Bolle, B.-L. YeoM. M. Yeung, 1998, Video query: Research di-rections, IBM Journal of Research and Development, 1998, Vol. 42, No. 2 Mul-timedia Systems, pp. 233-252.

Références

173

[Boreczky et al. 2000] J. Boreczky, A. Girgensohn, G. GolovchinskyS. Uchihashi, 2000. An interactive comic book presentation for exploring video, CHI 2000 conference on Human factors in computing systems, The Hague Netherlands, 2000, pp. 185-192

[Boudry 2002] C. Boudry, 2002, En savoir plus sur les images numériques, [en ligne] http://web.ccr.jussieu.fr/urfist/image_numerique/Image_numerique1.htm, Consulté le: 01.10.2003.

[Bradshaw et al. 2000] S. Bradshaw, A. Scheinkman, K. Hammond, 2000. Guiding people to information: providing an interface to a digital library using reference as a basis for indexing, ACM International Conference on Intelligent User Interfaces, New Orleans, LA USA, 2000, pp. 37 - 43

[Bres et al. 1999] S. Bres, P.-A. Champin, J.-M. Heraud, V. Herilier, J.-M. Jolion, E. Lou-pias, 1999, TeleSUN A world wide multimedia TELEteaching System for UNiver-sities, [en ligne] http://telesun.insa-lyon.fr/, Consulté le: 01.10.2003.

[Brush et al. 2002] A. J. B. Brush, D. Bargeron, A. Gupta, J. Grudin, 2002. Notification for shared annotation of digital documents, CHI 2002, Minneapolis, Minnesota, USA, 2002, pp. 89-96

[Bush 1945] V. Bush, 1945, As we may think, Atlantic Monthly, 1945, Vol. 176, No. 1, pp. 101-108.

[Calado et al. 2002] P. Calado, A. S. d. Silva, R. C. Vieira, A. H. F. Laender, B. A. Ribei-ro-Neto, 2002. Searching web databases by structuring keyword-based queries, Eleventh international conference on Information and knowledge management, McLean, Virginia, USA, 2002, pp. 26-33

[Celentano et al. 2002a] A. Celentano, O. Gaggi, 2002a. Schema modelling for automatic generation of multimedia presentations, 14th international conference on Soft-ware engineering and knowledge engineering, Ischia, Italy, 2002a, pp. 593-600

[Celentano et al. 2002b] A. Celentano, O. Gaggi, M. L. Sapino, 2002b. Retrieving Consis-tent Multimedia Presentation Fragments, Workshop on Multimedia Information Systems, Tempe, It, 2002b, pp. 9p.

[Celeux et al. 1989] G. Celeux, E. Diday, Y. Lechevallier, H. Ralambondrainy, 1989, Classification automatique de données. Paris: Dunod, 1989, p.

[Champin 2002] P.-A. Champin, 2002, Modéliser l'expérience pour en assister la réutili-sation. De la Conception Assistée par Ordinateur au Web Sémantique, PhD, In-formatique, Université Claude Bernard - Lyon 1, 2002, 126 p.


174

[Chandrasekaran et al. 1998] B. Chandrasekaran, J. R. Josephson, V. R. Benjamins, 1998. Ontology of tasks and methods, Eleventh Workshop on Knowledge Acquisition, Modeling and Management (KAW '98), Banff, Canada, 1998, pp. 25p

[Charlet 2003] J. Charlet, 2003, L'ingénieurie des connaissances; Développements, résul-tats et perspectives pour le gestion des connaissances médicales, Habilitation à diriger des recherches, Informatique, Université Pierre et Marie Curie, Paris, 2003, 142 p.

[Charlet et al. 1996] J. Charlet, B. Bachimont, J. Bouaud, P. Zweigenbaum, 1996, Ontolo-gie et réutilisabilité: expérience et discussion, in N. Aussenac-Gilles and P. Lau-blet, Acquisition et Ingénierie des Connaissances, Toulouse: Cepadués. Vol. 1996, pp. 69-87

[Chaudiron et al. 2000] S. Chaudiron, F. Role, M. Ihadjadene, 2000. CodeX : un système pour la définition de vues multiples guidée par les usages, CIDE 2000, Lyon, FR, 2000, pp. 71-81

[Chiueh et al. 1998] T.-c. Chiueh, T. Mitra, A. Neogi, C.-K. Yang, 1998. Zodiac: A Histo-ry-Based Interactive Video Authoring System, ACM Multimedia '98, Bristol, En-gland, 1998, pp. 435-444

[Clarke 2001] T. Clarke, 2001, Epistemics PC-Pack, [en ligne] http://www.epistemics.co.uk/products/pcpack/tools/, Consulté le: 24.06.2002.

[Correia et al. 2000] N. Correia, T. Chambel, 2000. Active video watching using annota-tion, ACM International Conference on Intelligent User Interfaces, New Orleans, USA, 2000, pp. 151-154

[Corvaisier et al. 1999] F. Corvaisier, A. Mille, J.-M. Pinon, 1999, Recherche assistée de documents indexés sur l'expérience: mesures de similarité des épisodes de re-cherche sur le Web, in J. Charlet, M. Zacklad, G. Kassel and D. Bourigault, Ingé-nierie des connaissances, Paris: Eyrolles. Vol. 1999, 387-403 p.

[Costabile et al. 1998] M. F. Costabile, D. Malerba, M. Hemmje, A. Paradiso, 1998. Buil-ding Metaphors for Supporting User Interaction with Multimedia Databases - A Demonstration, 4th IFIP 2.6 Working Conference on Visual DataBase Systems - VDB 4, L'Aqulia, Italy, 1998, pp. 154-160

[Dagtas et al. 1999] S. Dagtas, A. Ghafoor, 1999. Indexing and Retrieval of Video based on Spatial Relation Sequences, ACM Multimedia ‘99, Orlando, FL, 1999, pp. 119-123

[Dean et al. 2003] M. Dean, G. Schreiber, 2003, OWL Web Ontology Language, [en ligne] http://www.w3.org/TR/owl-ref/, Consulté le: 15.09.2003.

Références

175

[Decker et al. 2000] S. Decker, F. v. Harmelen, J. Broekstra, M. Erdmann, D. Fensel, I. Horrocks, M. Klein, S. Melnik, 2000, The Semantic Web - on the Roles of XML and RDF, IEEE Internet Computing, 2000, Vol. 4, No. 5, pp. 63-81.

[Delgado et al. 1999] J. DelgadoN. Ishii, 1999. Formal Models for Learning User Prefe-rences, A Preliminary Report, International Joint Conference on Artificial Intelli-gence (IJCAI-99), Workshop on Learning about Users, Stockholm, Sweden, 1999, pp. 8p

[Derthick et al. 2000] M. DerthickS. F. Roth, 2000. Data exploration across temporal contexts, ACM International Conference on Intelligent User Interfaces, New Or-leans, LA USA, 2000, pp. 60 - 67

[Ditto 2002] Ditto, 2002, Ditto, [en ligne] http://www.ditto.com/, Consulté le: 01.10.2003.

[Donnet 2002] S. Donnet, 2002, Etude de la persistance de graphes représentés en XML, Mémoire d'ingénieur CNAM, CNAM, INSA de Lyon, 2002, 106 p.

[Doorn et al. 2000] M. G. L. M. v. Doorn, A. P. d. Vries, 2000. The psychology of multi-media databases, Fifth ACM conference on ACM 2000 digital libraries, San An-tonio, USA, 2000, pp. 1-9

[Dukas 1998] Dukas, 1998, Dukas Graphical Task Modeling Tool, [en ligne] http://www.cc.gatech.edu/gvu/user_interfaces/Mastermind/Dukas/, Consulté le: 01.10.2002.

[Dussaux et al. 2000] G. Dussaux, J.-P. Pécuchet, 2000. Création collective de bases de connaissances sur le Web. Indexation par l'usage des documents, CIDE 2000, Lyon, FR, 2000, pp. 185-203

[Eco 1985] U. Eco, 1985, Lector in fabula, le rôle du lecteur ou la coopération interpréta-tive dans les textes narratifs. Paris: Grasset et Fasquelle, 1985, 320 p.

[Egyed-Zs. 1999] E. Egyed-Zs., 1999, Représentation et exploitation de graphes de des-cription de documents multimédias dans un langage structuré, Mémoire de DEA, DEA Informatique de Lyon, INSA Lyon, 1999, 30 p.

[Egyed-Zs. 2001] E. Egyed-Zs., 2001. Manipulation des documents multimédia, idées d'application du RàPC pour une aide à l'utilisateur, Séminaire RàPC, Grenoble, F, 2001, pp. 73-78

[Egyed-Zs. et al. 2003] E. Egyed-Zs., A. Mille, Y. Prié, 2003. Club (Trèfle): a use trace model, ICCBR 03, Trondheim, 2003, pp. 146-160


176

[Egyed-Zs. et al. 2002] E. Egyed-Zs., A. Mille, Y. Prié, J.-M. Pinon, 2002. Trèfle : un modèle de traces d'utilisation, Ingénierie des Connaissances, Rouen, F, 2002, pp. 39-51

[Egyed-Zs. et al. 1999a] E. Egyed-Zs., Y. Prié, A. Mille, J.-M. Pinon, 1999a. Représenta-tion des annotations multimédias dans des langages structurés (XML) et leur ex-ploitation, Journée jeunes chercheurs GDR-PRC I3 et GRACQ, Paris, France, 1999a, pp. 8p

[Egyed-Zs. et al. 1999b] E. Egyed-Zs., Y. Prié, A. Mille, J.-M. Pinon, 1999b. Représenter un graphe d’annotations de documents multimédia réparti sur plusieurs sites à l’aide d’un langage dérivé de XML, Journée jeunes chercheurs GDR-PRC I3, Tours, France, 1999b, pp. 9p

[Egyed-Zs. et al. 2000] E. Egyed-Zs., Y. Prié, A. Mille, J.-M. Pinon, 2000. A graph based audio-visual document annotation and browsing system, RIAO 2000, Paris, France, 2000, pp. 1381-1389

[El-Hadidy et al. 1999] F. M. El-Hadidy, H. J. G. d. Poot, D. D. Velthausz, 1999. Multi-media information retrieval framework: From theory to practice, IFIP 8th wor-king conference on database semantics (DS-8), Rotorua, New Zealand, 1999, pp. 271-310

[Farrell et al. 2000] R. Farrell, P. Fairweather, E. Breimer, 2000. A task-based architec-ture for application-aware adjuncts, ACM International Conference on Intelli-gent User Interfaces, New Orleans, LA USA, 2000, pp. 82-85

[Francisco-Revilla et al. 2000] L. Francisco-Revilla, F. M. Shipman, 2000. Adaptive me-dical information delivery combining user, task and situation models, ACM In-ternational Conference on Intelligent User Interfaces, New Orleans, United Sta-tes, 2000, pp. 94 - 97

[Frohlich et al. 2002] D. Frohlich, A. Kuchinsky, C. Pering, A. Don, S. Ariss, 2002. Re-quirements for Photoware, ACM conference on Computer supported cooperative work (CSCW 2002), New Orleans, Louisiana, USA, 2002, pp. 166-175

[gettyimages 2002] gettyimages, 2002, gettyimages, [en ligne] www.gettyone.com, Con-sulté le: 01.10.2003.

[Gomes et al. 2002] P. Gomes, F. C. Pereira, P. Paiva, N. Seco, P. Carreiro, J. L. Ferreira, C. Bento, 2002. Case Retrieval of Software Designs using WordNet, 15th Euro-pean Conference on Artificial Intelligence, ECAI 2002, Lyon, FR, 2002, pp. 245-249

Références

177

[Gomez-Perez 1999] A. Gomez-Perez, 1999. Knowledge Sharing and Reuse : Ontologies and Applications, IJCAI, Stockholm, Sweden, 1999, pp. Tutoriel Invité 40p

[Goodrum 2000] A. Goodrum, 2000, Image information retrieval: An overview of current research, Informing Science, 2000, Vol. 3, No. 2, pp. 63-66.

[Google 2003] Google, 2003, Google, [en ligne] www.google.com, Consulté le: 01.10.2003.

[Gordon 2000] A. S. Gordon, 2000. Using annotated video as an information retrieval in-terface, ACM International Conference on Intelligent User Interfaces, New Or-leans, USA, 2000, pp. 133-140

[Gruber et al. 1994] T. Gruber, F. Gerbaux, 1994, Library of Ontologies, [en ligne] http://www-ksl.stanford.edu/knowledge-sharing/ontologies/html/index.html, Consulté le: 12.09.2003.

[Gruber 1993a] T. R. Gruber, 1993a. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. Palo Alto, CA, Stanford Knowledge Systems La-boratory 1993a

[Gruber 1993b] T. R. Gruber, 1993b, A Translation Approach to Portable Ontology Speci-fications, Knowledge Acquisition, 1993b, Vol. 5, No. 2, pp. 199-220.

[Guarino 1997] N. Guarino, 1997. Some organizing principles for a unified top-level onto-logy, First International Conference on Language Resources and Evaluation. ELRA - European Language Resources Association, Granada, Spain, 1997, pp. 527-534

[Güell et al. 2000] N. Güell, D. Schwabe, P. Vilain, 2000. Modeling Interactions and Na-vigation in Web Applications, World Wild Web and Conceptual Modeling'00 Workshop, Salt Lake City, USA, 2000, pp. 20

[Gupta et al. 2002] A. Gupta, B. Ludäscher, R. W. Moore, 2002. Ontology services for curriculum development in NSDL, second ACM/IEEE-CS joint conference on Digital libraries, Portland, Oregon, USA, 2002, pp. 219-220

[Hauptmann et al. 2002a] A. Hauptmann, R. Yan, Y. Qi, R. Jin, M. Christel, M. Derthick, M.-Y. Chen, R. Baron, W.-H. Lin, T. D. Ng., 2002a. Video Classification and Re-trieval with the Informedia Digital Video Library System, Text Retrieval Confe-rence (TREC02), Gaithersburg, USA, 2002a, pp. 11p

[Hauptmann et al. 2002b] A. G. Hauptmann, N. D. Papernick, 2002b. Video-cuebik: adap-ting image search to video shots, second ACM/IEEE-CS joint conference on Di-gital libraries, Portland, USA, 2002b, pp. 156-157


178

[Hayes et al. 2002] C. Hayes, P. Cunningham, P. Clerkin, M. Grimaldi, 2002. Programme driven music radio, 15th European Conference on Artificial Intelligence, ECAI 2002, Lyon, FR, 2002, pp. 633-637

[Herman et al. 2000] I. Herman, M. S. Marshall, 2000, GraphXML -- An XML based graph interchange format, [en ligne] http://www.cwi.nl/InfoVisu/GraphXML/, Consulté le: 12.10.2002.

[Hlavacs et al. 1999] H. Hlavacs, G. Kotsis, 1999. Modeling User Behaviour - A Layered Approach, Seventh International Symposium on Modeling, Analysis and Simula-tion of Computer and Telecommunication Systems, MASCOTS'99, Maryland, USA, 1999, pp. 218-226

[Hsu et al. 2002] J.-L. Hsu, A. L. P. Chen, H.-C. Chen, N.-H. Liu, 2002. The effectiveness study of various music information retrieval approaches, Eleventh international conference on Information and knowledge management, McLean, USA, 2002, pp. 422-429

[Hunter et al. 1998] J. Hunter, R. Iannella, 1998. The Application of Metadata Standards to Video Indexing, Second European Conference on Research and Advanced Technology for Digital Libraries, Crete, GR, 1998, pp. 15p

[Hürst 2002] W. Hürst, 2002. Indexing, searching, and retrieving of recorded live presen-tations with the AOF (authoring on the fly) search engine, Proceedings of the 25th annual international ACM SIGIR conference on Research and development in information retrieval, Tampere, Fi, 2002, pp. 447-457

[IBM 2002] IBM, 2002, QBIC Query By Image Content, [en ligne] http://wwwqbic.almaden.ibm.com/, Consulté le: 01.10.2003.

[Imagescape 2001] Imagescape, 2001, Imagescape, [en ligne] http://ind134a.wi.leidenuniv.nl:2001/imagesearch.html, Consulté le: 12.12.2001.

[INRIA 2000] INRIA, 2000, IMEDIA SurfImage, [en ligne] http://www-rocq.inria.fr/cgi-bin/imedia/ikona, Consulté le: 01.04.2002.

[INRIA 2002] INRIA, 2002, IKONA IMEDIA, [en ligne] http://www-rocq.inria.fr/imedia/ikona/index.html, Consulté le: 01.10.2003.

[ISO 2001] ISO, 2001, Standard Generalized Markup Language (SGML) ISO 8879, [en ligne] http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=16387, Consulté le: 01.10.2003.

Références

179

[Jaczynski et al. 1998] M. Jaczynski, B. Trousse, 1998. WWW Assisted Browsing by Reu-sing Past Navigations of a Group of Users, In Advanced in Case-based Reaos-ning, 4th European Workshop on Case-Based Reasoning, Dublin, EI, 1998, pp. 160-171

[Jing et al. 2002] Y. Jing, N. Taylor, K. Brown, 2002. An Intelligent Inference Approach for User Interaction Modeling in a Generic Agent Based Interface System, 15th European Conference on Artificial Intelligence, ECAI 2002, Lyon, FR, 2002, pp. 103-107

[Kahan et al. 2001] J. Kahan, M.-R. Koivunen, 2001. Annotea: an open RDF infrastruc-ture for shared Web annotations, The tenth international World Wide Web confe-rence on World Wide Web, Hong Kong, 2001, pp. 623-632

[Kanellos et al. 2000] I. Kanellos, T. Thilivitis, A. Léger, 2000. Indexation et recherche d'information imagée par le contenu: catégories de textes et catégories d'images dans le projet SemDex, CIDE 2000, Lyon, FR, 2000, pp. 171-183

[Kaplan 1997] R. M. Kaplan, 1997, Intelligent Multimedia Systems A handbook for crea-ting applications. Toronto: John Wiley & Sons, 1997, 494 p.

[Kipp 2002] M. Kipp, 2002, ANVIL Annotation of Video and Spoken Language, [en ligne] http://www.dfki.de/~kipp/anvil/, Consulté le: 01.10.2003.

[Kokkoras et al. 2002] F. Kokkoras, H. Jiang, I. Vlahavas, A. K. Elmagarmid, E. N. Hous-tis, W. G. Aref, 2002, Smart VideoText: a video data model based on conceptual graphs, Multimedia Systems, 2002, Vol. 8, No. 4, pp. 328-338.

[Kumar et al. 1998] V. Kumar, R. Furuta, R. B. Allen, 1998. Metadata Visualization for Digital Libraries: Interactive Timeline.Editing and Review, ACM Digital Libra-ries 98, Pittsburgh, USA, 1998, pp. 126-134

[Lafon et al. 2002] Y. Lafon, B. Bos, 2002, Describing and retrieving photos using RDF and HTTP (RDFPic), [en ligne] http://jigsaw.w3.org/rdfpic/, Consulté le: 01.10.2003.

[Layman 1998] A. Layman, 1998. XML Syntax Recommendation for Serializing Graphs of Data in QL'98, The Query Languages Workshop, Boston, USA, 1998, pp. [en li-gne] http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html, Consulté le 01.10.2003

[LeBlanc et al. 2003] B. LeBlanc, C. Obernesser, B. Claverie, 2003. Validation et évalusation congnitives de techniques de navigation et de visualisation de données, Extraction et gestion des connaissances (EGC), Lyon, Fr, 2003, pp. 93-104


180

[Lehman et al. 1995] J. F. Lehman, J. Laird, P. Rosenbloom, 1995, A Gentle Introduction to Soar, an Architecture for Human Cognition, [en ligne] http://ai.eecs.umich.edu/soar/docs/Gentle.pdf, Consulté le: 25.06.2002.

[Lehmann 1994] P. Lehmann, 1994. CCAT: The current status of the conceptual catalo-gue (Ontology) group with proposals, Fourth International Workshop on Peirce, "A conceptual Graph Workbench", Maryland, USA, 1994, pp. 18-28

[Lemlouma et al. 2002] T. Lemlouma, N. Layaïda, 2002. Content Adaptation and Genera-tion Principles for Heterogeneous Clients, W3C Workshop on Device Indepen-dent Authoring Techniques, 2002, pp. 9p

[Lieberman 1993] H. Lieberman, 1993, Mondrian: A Teachable Graphical Editor, in A. Cypher, Watch What I Do: Programming by Demonstration: MIT Press. Vol. 1993, 144p p.

[Lieberman 1995] H. Lieberman, 1995. Letizia: An Agent That Assists Web Browsing, Proceedings of the International Joint Conference on Artificial Intelligence, Mon-treal, Canada, 1995, pp. 924-929

[Lieberman 1997] H. Lieberman, 1997. Autonomous Interface Agents, ACM Conference on Human Factors and Computing Systems, Atlanta, GA, USA, 1997, pp. 67-74

[Lieberman et al. 1996] H. Lieberman, D. Maulsby, 1996, Instructible Agents: Software That Just Keeps Getting Better, IBM Systems Journal, 1996, Vol. 35, No. 1, pp. 20p.

[Liechti et al. 1998] O. Liechti, M. J. Sifer, T. Ichikawa, 1998. Structured graph format: XML metadata for describing Web site structure, Seventh International World-Wide Web Conference, Brisbane, Australia, 1998, pp.

[Lin et al. 2002] C.-Y. Lin, B. L. Tseng, J. R. Smith, 2002, VideoAnnEx Annotation Tool, [en ligne] http://www.research.ibm.com/VideoAnnEx/index.html, Consulté le: 11.10.2002.

[Macromedia 1999] Macromedia, 1999, Dreamweaver 3 (Logiciel), http://www.macromedia.com/

[Mediasite 2000] Mediasite, 2000, Mediasite, [en ligne] http://www.mediasite.com/, Con-sulté le: 29.09.2003.

[Menzies 1999] T. Menzies, 1999, Cost Benefits of Ontologies, intelligence: New Visions of AI in Practice, 1999, Vol. 10, No. 3, pp. 26-32.

Références

181

[Michard 1999] A. Michard, 1999, XML Langage et applications. Paris: Eyrolles, 1999, 361 p.

[Mille 1998] A. Mille, 1998, Experience et expertise: les connaissances mobilisés en coo-pération homme-machine pour la résolution de problème, Informatique, Univer-sité Claude Bernard - Lyon 1, 1998, 129 p.

[Minsky 1975] M. Minsky, 1975, A framework for representing knowledge, in P. Winston, The Psychology of Computer Vision, New York: McGraw-Hill. Vol. 1975, p.

[Mitra et al. 2000] P. Mitra, G. Wiederhold, M. Kersten, 2000. A Graph-Oriented Model for Articulation of Ontology Interdependencies, Conference on Extending Data-base Technology, (EDBT 2000), Konstanz, Germany, 2000, pp. 15 p.

[MPEG 2000] MPEG, 2000, MPEG7, [en ligne] http://ipsi.fraunhofer.de/delite/Projects/MPEG7/, Consulté le: 01.10.2003.

[MPEG 2002] MPEG, 2002, Overview of the MPEG-4 Standard, [en ligne] http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm, Consulté le: 01.10.2003.

[MPEG 2003] MPEG, 2003, The MPEG Home Page, [en ligne] http://mpeg.telecomitalialab.com/, Consulté le: 01.10.2003.

[Mulhem et al. 2002] P. Mulhem, J. H. Lim, 2002. Symbolic photograph content-based retrieval, Eleventh international conference on Information and knowledge ma-nagement, McLean, Virginia, USA, 2002, pp. 94-101

[Nack et al. 1999] F. Nack, A. T. Lindsay, 1999, Everything you wanted to know about MPEG-7, Part 1, IEEE Multimedia, 1999, Vol. 1070-986X/99, No. 1, pp. 65-77.

[Nack et al. 2001] F. Nack, W. Putz, 2001. Designing annotation before it's needed, Ninth ACM International Multimedia Conference, Ottawa, CA, 2001, pp. 251-260

[Nahrstedt 2002] K. Nahrstedt, 2002, Multimedia Systems CS314, [en ligne] http://www-courses.cs.uiuc.edu/~cs323/Lectures/7.Media/talk/talk.html, Consulté le: 01.02.2003.

[Napoli et al. 1997] A. Napoli, A. Mille, 1997. Aspects du raisonnement à partir de cas, 6 èmes journées nationales PRC-GDR Intelligence Artificielle, Grenoble, FR, 1997, pp. 261-288

[NETRA 2000] NETRA, 2000, NETRA, [en ligne] http://maya.ece.ucsb.edu/Netra/netra.html, Consulté le: 10.02.2002.


182

[Ng et al. 2003] T. D. Ng, M. G. Christel, A. G. Hauptmann, H. D. Wactlar, 2003. Colla-ges as Dynamic Summaries of Mined Video Content for Intelligent Multimedia Knowledge Management, AAAAI Spring Symposium Series on Intelligent Mul-timedia Knowledge Management, Palo Alto, CA, 2003, pp. 11

[NLM 2003] NLM, 2003, MESH, Medical Subject Headings, [en ligne] http://www.nlm.nih.gov/mesh/, Consulté le: 01.10.2003.

[Nowell et al. 1996] L. T. Nowell, R. K. France, D. Hix, L. S. Heath, E. A. Fox, 1996. Vi-sualizing Search Results: Some Alternatives To Query-Document Similarity, ACM SIGIR, Zurich Switzerland, 1996, pp. 67-75

[NPTV 2001] NPTV, 2001, Bando Suite, [en ligne] http://www.nptv.fr/bando/, Consulté le: 17.04.2001.

[Ossenbruggen et al. 2001] J. v. Ossenbruggen, J. Geurts, F. Cornelissen, L. Hardman, L. Rutledge, 2001. Towards second and third generation web-based multimedia, Tenth international conference on World Wide Web (WWW10), Hong Kong, 2001, pp. 479-488

[Paternó 2000] F. Paternó, 2000, Model-based design of interactive applications, intelli-gence, 2000, Vol. 11, No. 4, pp. 26-38.

[Pfister et al. 1999] H.-R. Pfister, M. Wessner, J. Beck-Wilson, 1999. Soziale und kogni-tive Orientierung in einer computergestützten kooperativen Lernumgebung, Software-Ergonomie '99. Design von Informationswelten, Stuttgart, DE, 1999, pp. 265-274

[Prié 1999] Y. Prié, 1999, Modélisation de documents audiovisuels en Strates Intercon-nectées par les annotations pour l'exploitation contextuelle, PhD, Informatique, INSA-Lyon, 1999, 270 p.

[Prié et al. 2000] Y. Prié, T. Limane, A. Mille, 2000. Isomorphisme de sous-graphe pour la recherche d'information audiovisuelle contextuelle, 12ème congrès Reconnais-sance de Formes et Intelligence Artificielle, RFIA2000, Paris, FR, 2000, pp. 277-286

[Protégé 2002] Protégé, 2002, Protégé 2000, [en ligne] http://protege.stanford.edu/, Con-sulté le: 01.10.2003.

[Punin et al. 2000] J. Punin, M. Krishnamoorthy, 2000, XGMML (eXtensible Graph Mar-kup and Modeling Language), [en ligne] http://www.cs.rpi.edu/~puninj/XGMML/, Consulté le: 01.10.2003.

Références

183

[Rao et al. 1995] R. Rao, J. O. Pedersen, M. A. Hearst, J. D. Mackinlay, S. K. Card, L. Masinter, P.-K. Halvorsen, G. G. Robertson, 1995, Rich Interaction in the Digital Library, COMMUNICATIONS OF THE ACM, 1995, Vol. 38, No. 4, pp. 39-40.

[Rehatschek et al. 1999] H. Rehatschek, H. Müller, 1999. A Generic Annotation for Video Databases, VISUAL 1999, Amsterdam, NL, 1999, pp. 383-390

[Rey et al. 1992] A. Rey, J. Rey-Debove, 1992, Le Petit Robert (Dictionnaire de la langue Française). Paris: Dictionnaires Robert, 1992, 2173 p.

[Rossi et al. 2000] G. Rossi, D. Schwabe, F. Lyardet, 2000. Abstraction and Reuse Me-chanisms in Web Application Models, World Wild Web and Conceptual Mode-ling'00 Workshop, Salt Lake City, USA, 2000, pp. 76-88

[Ruvini et al. 2000] J.-D. Ruvini, C. Dony, 2000. APE: learning user's habits to automate repetitive tasks, ACM International Conference on Intelligent User Interfaces, New Orleans, LA USA, 2000, pp. 229 - 232

[Saddik et al. 2001] A. E. Saddik, S. Fischer, R. Steinmetz, 2001, Reusable Multimedia Content in Web-Based Learning Systems, IEEE Multimedia, 2001, Vol. 8, No. 3, pp. 30-38.

[Schafer et al. 2002] J. B. Schafer, J. A. Konstan, J. Riedl, 2002. Meta-recommendation systems: user-controlled integration of diverse recommendations, Eleventh inter-national conference on Information and knowledge management, McLean, Virgi-nia, USA, 2002, pp. 43-51

[Schreiber et al. 2001a] A. T. Schreiber, B. Dubbeldam, J. Wielemaker, B. J. Wielinga, 2001a, Ontology-based photo annotation, IEEE Intelligent Systems, 2001a, Vol. May/June 2001, No. 1, pp. 2-10.

[Schreiber et al. 2001b] G. Schreiber, J. Wielemaker, 2001b, ModelDraw, [en ligne] http://www.commonkads.uva.nl/INFO/tools/modeldraw.html, Consulté le: 01.10.2003.

[Schürr 2000] A. Schürr, 2000. Looking for a Graph eXchange Language, APPLI-GRAPH-Subgroup Meeting on Exchange Formats for Graph Transformation, Pa-derborn, DE, 2000, pp. 51p

[Scuturici 2002] M. Scuturici, 2002, Contrinbution aux techniques orientée objet de ges-tion des séquences vidéo pour les serveurs Web, PhD, INSA Lyon, 2002, 118 p.

[Selker 1994] T. Selker, 1994, Coach: A teaching Agent that Learns, Communications of the ACM, 1994, Vol. 37, No. 1, pp. 92-99.


184

[Shank et al. 1984] R. C. Shank, P. Childers, 1984, The Cognitive Computer On Lan-guage, Learning and Artificial Intellugence. Don Mills, Ontario, Canada: Addi-son-Wesley Publishing Company, 1984, 268 p.

[Shneiderman 2002] B. Shneiderman, 2002, Meeting Human Needs with New Digital Imaging Technologies, IEEE Multimedia, 2002, Vol. 9, No. 4, pp. 8-14.

[Smyth et al. 2001] B. Smyth, M. T. Keane, P. Cunningham, 2001, Hierarchical case-based reasoning, IEEE Transactions on Knowledge & Data Engineering, 2001, Vol. 13, No. 1, pp. 793-812.

[Soares et al. 2000] L. F. Soares, R. F. Rodrigues, D. C. M. Saade, 2000, Modeling, au-thoring and formatting hypermedia documents in the HyperProp system, Multi-media Systems, 2000, Vol. 8, No. . pp. 118-134.

[Sowa 2000] J. F. Sowa, 2000, Knowledge Representation Logical, Philosophical and Computational Foundations. Pacific Grove, CA, USA: 2000, 594 p.

[SQUID 2002] SQUID, 2002, SQUID, [en ligne] http://www.ee.surrey.ac.uk/Research/VSSP/imagedb/demo.html, Consulté le: 01.10.2003.

[Stotts et al. 2002] D. Stotts, J. M. Smith, 2002. Semi-automated Hyperlink markup for archived video, Proceedings of the thirteenth conference on Hypertext and hy-permedia, College Park, Maryland, USA, 2002, pp. 105-106

[Takano et al. 2000] A. Takano, Y. Yurugi, A. Kanaegami, 2000. Procedure Based Help Desk System, ACM IUI 2000, New Orleans LA USA, 2000, pp. 264-272

[Thuong 1999] T. Thuong, 1999, DEA : Description de la structure des vidéos pour les applications multimédias, MSc, DEA Imagerie Vision et Robotique (IVR) Gre-noble, 1999, 30 p.

[Trousse 2000] B. Trousse, 2000. Evaluation of the Prediction Capability of a User beha-viour Mining Approach for Adapative Web Sites, In RIAO 2000, 6th Conference on "Content-Based Multimedia Information Access", Paris, 2000, pp. 1752-1761

[Trousse et al. 1999] B. Trousse, M. Jaczynski, R. Kanawati, 1999. Une approche fondée sur le raisonnement à partir de cas pour l'aide à la navigation dans un hypermé-dia, Hypertexte & Hypermedia : Products, Tools and Methods (H2PTM'99), Pa-ris, 1999, pp. [en ligne] http://www-sop.inria.fr/aid/papers/99h2ptm/99h2ptm.pdf , Consulté le 10.02.2003

[Virage 2000] Virage, 2000, Virage, [en ligne] http://www.virage.com, Consulté le: 30.09.2003.

Références

185

[W3C 1999] W3C, 1999, XML Path Language (XPath), [en ligne] http://www.w3.org/TR/xpath, Consulté le: 01.10.2003.

[W3C 2000a] W3C, 2000a, Resource Description Framework (RDF), [en ligne] http://www.w3.org/RDF/, Consulté le: 01.10.2003.

[W3C 2000b] W3C, 2000b, Synchronized Multimedia Integration Language (SMIL), [en ligne] http://www.w3.org/AudioVideo/, Consulté le: 01.10.2003.

[W3C 2000c] W3C, 2000c, XML Linking Language, [en ligne] http://www.w3.org/TR/xlink/, Consulté le: 01.10.2003.

[W3C 2000d] W3C, 2000d, XML Schema Part 0: Primer, W3C Working Draft, [en ligne] http://www.w3.org/TR/xmlschema-0/, Consulté le: 22.09.2003.

[W3C 2000e] W3C, 2000e, XML Schema Part 1: Structures, W3C Working Draft, [en li-gne] http://www.w3.org/TR/xmlschema-1/, Consulté le: 22.09.2003.

[W3C 2000f] W3C, 2000f, XML Schema Part 2: Datatypes, W3C Working Draft, [en li-gne] http://www.w3.org/TR/xmlschema-2/, Consulté le: 22.09.2003.

[W3C 2002a] W3C, 2002a, HyperText Markup Language (HTML), [en ligne] http://www.w3.org/MarkUp/, Consulté le: 01.10.2003.

[W3C 2002b] W3C, 2002b, XML Extensible Markup Language, [en ligne] http://www.w3.org/XML/, Consulté le: 01.10.2003.

[W3C 2002c] W3C, 2002c, XML Pointer Language (XPointer), [en ligne] http://www.w3.org/TR/xptr/, Consulté le: 01.10.2003.

[W3C 2003a] W3C, 2003a, CSS Cascading Style Sheets, [en ligne] http://www.w3.org/Style/CSS/, Consulté le: 01.10.2003.

[W3C 2003b] W3C, 2003b, The Extensible Stylesheet Language (XSL), [en ligne] http://www.w3.org/Style/XSL/, Consulté le: 01.10.2003.

[Wache et al. 2001] H. Wache, T. Vögele, U. Visser, H. Stuckenschmidt, G. Schuster, H. Neumann, S. Hübner, 2001. Ontology-Based Integration of Information - A Sur-vey of Existing Approaches, IJCAI-01 Workshop: Ontologies and Information Sharing, Seattle, WA, 2001, pp. 108-117

[Wang et al. 2002] J. Wang, A. Agrawal, A. Bazaza, S. Angle, E. A. Fox, C. North, 2002. Enhancing the ENVISION interface for digital libraries, second ACM/IEEE-CS joint conference on Digital libraries, Portland, Oregon, USA, 2002, pp. 275-276


186

[Webseek 2002] Webseek, 2002, Webseek, [en ligne] http://www.ctr.columbia.edu/webseek/, Consulté le: 01.10.2003.

[Xiong et al. 1999] R. Xiong, J. Donath, 1999. PeopleGarden: Creating Data Portraits for Users, ACM UIST ’99, Asheville, NC, USA, 1999, pp. 37-45

[Zhong 2000] Y. Zhong, 2000, Apply Multimodal Search and Relevance Feedback In a Digital Video Library (MsC thesis), MsC degree, CS, Carnegie Mellon Universi-ty, 2000, 40 p.

187

8. Annexes

8.1. Architecture global du prototype

La bibliothèque E-SIA_Lib est construite autour d’un noyau formé des bibliothèques de manipulation de XML (IBM XML4C) et de Graphes (LEDA) et des classes repré-sentant la structure interne de données. Le tout est implanté en C++ standard. Cette bibliothèque implante les fonctionnalités suivantes :

la mise en place des annotations ; la navigation dans les annotations ; la construction des requêtes ; la résolution des requêtes ;

la sauvegarde et rechargement des annotations ; Le prototype peut se découper en 5 modules de programmes, correspondant en partie aux différents collaborateurs (Modules 2,3,4) complétés par un module central (Mo-dule5) et un module client (Module1). Les 5 modules sont :

1. Interface client. (LISI) 2. Analyseur Vidéo ( FT R&D) 3. Analyseur Image ( INRIA) 4. Module d’annotation manuelle (LISI) 5. Serveur central (LISI)

Ana

lyse

urd

’imag

esServ

eur c

entra

l

Fich

ier

mpe

g1

2. C

hoix

d ’u

ne v

idéo

àan

note

r sel

on la

PA

choi

sie

1. C

hoix

d’u

n P

AN

1,S

ecou

riste

,1,1

N3,

Opé

ratio

n,3,

n

N2,

Vic

time,

2,1

ReS

D[1

,n]

ReS

D[n

,1]

Proc

édur

e d’

Ann

otat

ion

(PA

)

Ana

lyse

ur V

idéo

3. D

istri

butio

n de

stâ

ches

d ’a

nnot

atio

nse

lon

le P

A

3.2

Ana

lyse

auto

mat

ique

de

lavi

déo,

ext

ract

ion

d’im

ages

3.3

Ana

lyse

et

inde

xatio

n de

sim

ages

ext

raite

s

3.4

(Sur

)Ann

otat

ion

man

uelle

MO

DU

LE2

MO

DU

LE4

IHM

Jav

a

MO

DU

LE5

MO

DU

LE3

Mod

uleX

: Site

phy

siqu

e ou

virt

uelle

Inte

rface

logi

ciel

le (A

PI)

c

omm

uniq

uant

par

http

, tra

nsfé

rant

de

s do

nnée

s XM

L et

bin

aire

s (m

peg,

jpg,

…)

Pro

duct

ion

Fich

iers

mpe

g1

Fich

iers

mpe

g1

Imag

es

Imag

es

AFP

S

UA

V1

Seco

uris

te

Opé

ratio

nV

ictim

e

UA

V2

UA

V3

UA

V4

UA

V5

Dr J

ekyl

déga

gem

ent

véri

fica

tion

resp

irat

ion

véri

fica

tion

poul

s

Mr.

Ton

ton

EA

1

EA

2

EA

3

EA

5

EA

4

N1

N2

N3

N1

N3

N3

N3

N2

Ann

otat

ions

Des

crip

teur

s

MO

DU

LE1

IHM

gui

dé

Fi

gure

97

déco

upag

e en

mod

ules

du

dém

onst

rate

ur R

EC

IS

Assi

stan

ts

Inte

rnet

Inte

rface

s

Appl

icat

ion

cent

rale

Fi

gure

98

Illu

stra

tion

des d

iffér

ente

s int

erfa

ces h

omm

e-m

achi

ne


190

8.2. Application centrale, diagrammes de classes gérant les annotations

Le graphe des annotations est traduit dans un ensemble d’objets C++ qui permettent sa gestion. Il est matérialisé dans la mémoire sous la forme d’un objet graphe et d’objets vus sur ce graphe. Les Figure 99, Figure 100 et Figure 101 présentent le modèle OMT des classes for-mant le noyau du système, c’est à dire, les classes manipulant les données XML et créant la vue de graphe et ensuite de Base de Connaissance. Ces objets cachent en fait à l’utilisateur la structure physique des données et offrent une interface de pro-grammation confortable pour leur manipulation.

GraphePCm_PointDeCaracterisation : TypePointDeCaracterisationm_Instancie : intm_Nom : stringm_Type : stringm_NbNoeudsGenerique : int

Instancier()Validite()NoeudsCorrespondants()SerialiserXML()AjouterPointCaracterisation()EnleverPointCaracterisation()ChangerNomPtCaracterisation()GetFreeID()operator>>()operator<<()

GRAPH LEDA

GrapheGlobalm_Nom : stringm_ListeFlux : l ist < Flux* >m_pBC : BaseDeConnaissance*m_DicoCorrespID_Ptr : TypeDicIDPtr

CreerFlux()DetruireFlux()CreerBdC()DetruireBdC()RendereNoeudTotalementConnu()ChercherVoisinsTemporels()ChercherVoisinsR()ChercherVoisinsRSimilaire()NbRelSort()NbRelSortR()NbRelEntr()NbRelEntrR()SerialiserXML()GetTail le()GetNbFlux()GenererHasard()ExtraireAutoGP()operator>>()operator<<()

Figure 99 Classes représentant le Graphe Global et Graphe Potentiel

Annexes

191

BaseDeConnaissancem_ListeNodeEAA : TypeListeIDNoeudm_Nom : string

CreerEAA()DeplacerEAA()MiseEnRelationInterne()RenommerRelationInterne()RemplacerEAA()SupprimerRelationInterne()SupprimerEAA()Serial iserXML()GetFreeID()GetNbEAA()operator>>()operator<<()

Fluxm_Flux : stringm_Format : stringm_Duree : intm_NbEA : intm_ListeNodeUAV : TypeListeIDNoeud

CreerUAV()MettreEnRelationRe()CompleterUAV()SupprimerUAV()SupprimerEA()SupprimerRe()Serial iserXML()GetFreeID_EA()GetFreeID_UAV()GetNbUAV()GetNbTotalEA()GetNbEA()operator>>()operator<<()

Figure 100 Classes représentant des vues sur le Graphe Global


192

Noeudm_NombreAttr : intm_AttrList : l ist < two_tuple <TypeAttributSIA, list <string > > >m_Type : TypeNoeudType

GetAttrVal(type : TypeAttributSIA) : TypeListeValeurAttrSetAttrVal(type : TypeAttributSIA, valeur : string) : intGetAttrNbVal(type : TypeAttributSIA) : intSupprimerTypeAttribut(type : TypeAttributSIA) : intoperator>>()operator<<()SerialiserXML() : intGetID() : TypeIDSetID() : TypeID

UAVm_t1 : intm_Duree : int

SerialiserXML() : intoperator<<()operator>>()GetDuree() : intGetT1T2(t1 : int &, t2 : int &) : intUAV(nomFlux : string, t1 : int, t2 : int)

EAA

SerialiserXML() : intoperator<<()operator>>()GetNom() : stringEAA(nom : string)

EA

SerialiserXML()operator<<()operator>>()GetPrimitif()GetNom()SetAttrVal()EA()

NoeudGPm_ListeFnType : l ist < two_tupe < TypeAttributSIA , int >>m_ListeNoeudGGCorrespondants : TypeListeIDNoeudm_ID_GP : TypeID_GP

SerialiserXML() : intoperator<<()operator>>()Compare(noeudGG : Noeud*) : int

Figure 101 Classes implantant les différents Nœuds constituant le Graphe Global

Annexes

193

8.3. Présentation des procédures d’annotation

Nous proposons de mettre en place des structures décrivant les procédures d’annotation. Nous les appellerons Procédure d’Annotation (PA). Une procédure d’annotation peut être automatique ou manuelle, elle s’applique à un segment vidéo. Le but des PA-s est de spécifier pour le serveur les démarches à suivre. Une (ou plu-sieurs) PA est associé à un schéma de description. En sélectionnant un SD nous sélec-tionnons la PA qui sera traité par le serveur central.

Une PA automatique contient les informations suivantes - Description explicative textuelle, ou graphique (HTML, flash,…) - Référence vers le segment à annoter - Structure des annotations résultantes (SD) - Suite d’opérations à effectuer

Une opération est : • Adresse du serveur qui effectue l’opération (IP (+ N° port) de la machine CNET

par ex.) • Codes d’opérations à effectuer (nom de la routine CGI, ou identificateur de

l’algorithme de traitement d’image) • Liste des paramètres

- Instructions pour l’intégration des annotations résultantes. Une PA manuelle contient les informations :

- Description explicative textuelle, ou graphique (HTML, flash,…) - Référence vers le segment à annoter - Structure des annotations résultantes (SD) - Référence vers l’assistant et l’interface qui permettra l’annotation - Instructions pour l’intégration des annotations résultantes. Les opérations d’une PA automatique peuvent être des PA-s manuelles. De cette fa-çon nous pouvons définir des SD qui combinent des étapes d’annotation automatique et manuelle. Il faut prévoir des méthodes de définir d’éventuels liens entre les opérations. Sorte de pipe-s c’est à dire permettre à une opération de récupérer comme paramètre les résul-tats d’une opération précédente. Une procédure d’annotation est une suite d’assistants manuels ou automatiques qui sont appliqués un après l’autre sur un document. Voici l'ordre dans lequel se déroulent les opérations :

• Le client lance par CGI une PA. Le CGI appelle sur le module de communica-tion socket la méthode de création d'une PA active en lui passant le numéro d'utilisateur et l'identifiant de la PA à créer. L'application se charge ensuite des opérations de création comme suit :

• Elle crée un nouveau tuple dans la table PA active, insère dans la table Opera-tionsSession toutes les opérations qui vont composer la PA (en mettant tous les champs Etat à non commencé) puis lance la première opération en appelant le premier assistant d'opération, en lui passant l'identifiant de l'opération qui vient


194

d'être créé - correspondant au champs idOpSession dans la table OperationsSes-sion) ainsi que l’URL du Flux à traiter.

• L'assistant appelle sur le module distant les différents traitements (en ayant au préalable demandé tous les renseignements qui lui sont nécessaire à l'applica-tion), et cela toujours en passant le numéro d'opération obtenu lors de son appel.

• Lorsque ces traitements sont terminés, le CGI d'intégration des résultats corres-pondant à l'assistant est appelé. Il connaît toujours le numéro de l'opération et intègre tous ces résultats avec ce numéro. Il appelle ensuite la méthode de fin d'opération (par socket). Cette méthode crée les modifications dans la table OperationsSession et PAsActive puis se charge de lancer l'opération suivante si la PA active n'est pas terminée.

Exemple d'opérations suivant un lancement de PA : • Demande création PA par CGI, identifiant Utilisateur = 1, identifiant PA = 1 • La méthode CreerSession est appelée. Elle ajoute un tuple dans la table PAsAc-

tives, avec les champs : idSession : un identificateur unique (correspondant au nombre de PA Actives déjà existantes + 1) idPA : identifiant du type de PA auquel correspond la session Etat : -1 : non commencée flux : nom et emplacement du flux concerné idUtil : identificateur de l'utilisateur ayant demandé la création de la session NumPourUtilisateur : Numéro de la session vis-à-vis de l'utilisateur (nombre de sessions qu'il a déjà lancées + 1)

Dans la table OperationsSession, les CreerSession crée des tuples correspondant aux opérations composant la PA. Ainsi, si la PA est composé de deux opéra-tions, la méthode insérera deux tuples, avec des identifiants idOperation consé-cutifs aux opérations déjà existantes, et avec Etat à -1 (non commencée)

• La méthode CreerSession appelle la méthode LancerSession en lui passant le numéro de la session

• La méthode LancerSession récupère le numéro d'identification de la première opération de la session et le flux concerné, puis appelle avec ces 2 paramètres la méthode lancerOp qui se charge d'appeler la DLL correspondant à l'assistant re-lié à l'opération en lui passant le numéro d'identification de l'opération.

• A la fin de l'opération, le CGI d'intégration des résultats appelle la méthode Fi-nirOp (par socket, en utilisant l'identifiant correspondant à cette méthode) en lui passant l'identifiant de l'opération.

• La méthode FinirOp modifie la table OperationsSession en modifiant le champs Etat de l'opération correspondante (passe à 1, terminé). Puis vérifie s'il reste des opérations à effectuer dans la PA. Si oui, il les lance (méthode LancerOp). Si non, elle modifie la table PasActives en changeant le champs Etat ( 0 : terminé)

L’Exemple 1 illustre la représentation en XML d’une procédure d’annotation. En ef-fet il est possible de créer des procédures d’annotation simplement en énumérant les opérations qui en sont contenues et en passant le document XML qui les contient à l’application.

Annexes

195

<PA xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:noNamespaceSchemaLocation="C:\Users\Elod\These\RECIS_doc\reunions\2001_05_16\xml\PA.xsd"> <PA_Nom>Annotation_par_plans</PA_Nom> <PA_Description>Procédure d'Annotation appelant l'outil de découpage en plans du MO-DULE2</PA_Description> <MediaLocator>#FLUX</MediaLocator> <SchemaDeDescription>http://www.recis.net/SD1.xml</SchemaDeDescription> <Operation> <Assistant>DecoupEnPlansetSon<Assistant> </Operation> <Operation> <Methode>IndexeImages</Methode> </Operation> <Operation> <Methode>AjoutMotsClés</Methode> </Operation> </PA>

Exemple 1 Représentation en XML d’une procédure d’annotation


196

8.4. Les interfaces du site dynamique

Nous avons également mis en place un site web pour permettre l'accès aux divers as-sistants d'annotation. Cette interface trace les actions de l'utilisateur pour une réutili-sation future. Les figures suivantes illustrent un accès à un assistant via le web.

Figure 102 Page de connexion

Figure 103 Page d'accueil de l'utilisateur identifié, rappel des opérations lancées

Annexes

197

Figure 104 Début d'annotation, il faut choisir le document à annoter

Figure 105 Ensuite il faut préciser la manière dont l'annotation doit se faire


198

Figure 106 L'annotation est lancée, nous devons la valider sur la page d'accueil

Figure 107 Comme il s'agit d'une annotation semi-automatique, nos devons spécifier certains élé-

ments à la main

Annexes

199

Dans cet exemple nous exploitons des annotations posées selon une PA. L’interface utilisateur reste relativement simple. Le traitement du graphe potentiel devient par contre plus complexe.

N1

Son

*

*

*

Nom = "Lt.Toto"Flux

*N3

Contenu dans

ImageClé

*N4

MotClé

Image~ ’imag1.jpg’

Son~’son1.wav’

N2

Figure 108

Les UAV-s ont des images clés, des mots clés et pour ceux où il y a du son, un EA son leur a été attribué permettant la comparaison d’un fichier de son (wav) a la bande de son correspondant à l’UAV.


200

Figure 109 Résultats d’une recherche

Annexes

201

8.5. Exemples de fichiers XML

8.5.1. Les documents XML contenant la base de connaissances

8.5.1.a) DTD d’un fichier BdC.xml

<!ELEMENT BdC (EAA+)> <!ELEMENT EAA (Nom, DefinitionAttribut*)> <!ATTLIST EAA id CDATA #REQUIRED > <!ELEMENT Nom (#PCDATA)> <!ELEMENT DefinitionAttr (#PCDATA)> <!ATTLIST DefinitionAttr Max CDATA #REQUIRED Min CDATA #REQUIRED >

8.5.1.b) Exemple de fichier BdC.xml

<BdC> <EAA id="EAA_1____"> <Nom>Pompier</Nom> </EAA> <EAA id="EAA_2____"> <Nom>Lt. Tonton</Nom> </EAA> <EAA id="EAA_3____"> <Nom>Brigadier Jean</Nom> </EAA> <EAA id="EAA_4____"> <Nom>Vérification</Nom> </EAA> <EAA id="EAA_5____"> <Nom>Degagement</Nom> </EAA> <EAA id="EAA_6____"> <Nom>Massage</Nom> </EAA> <EAA id="EAA_7____"> <Nom>Zidane</Nom> </EAA> <EAA id="EAA_8____"> <Nom>Barthez</Nom> </EAA> <EAA id="EAA_9____">


202

<Nom>Petit</Nom> </EAA> <EAA id="EAA_10___"> <Nom>Incident</Nom> <DefAttr Max="3" Min="1">SIA_ImageRepresentative</ DefAttr> <DefAttr Max="1" Min="0">SIA_Texte</DefAttr> </EAA> <EAA id="EAA_All"> <Nom>All</Nom> </EAA> <EAA id="EAA_Flux"> <Nom>Stream</Nom> </EAA> </BdC>

8.5.2. Les documents XML contenant les éléments d’annotation

8.5.2.a) DTD d’un fichier Flux.xml

<!ELEMENT Flux (UAV,EA+)+> <!ATTLIST Flux href CDATA #REQUIRED duree CDATA #REQUIRED id CDATA #REQUIRED format CDATA #REQUIRED > <!ELEMENT UAV (t1_t2)> <!ATTLIST UAV id CDATA #REQUIRED > <!ELEMENT EA (Nom, Primitif, InstanceAttribut*)> <!ATTLIST EA id CDATA #REQUIRED > <!ELEMENT t1_t2 (#PCDATA)> <!ELEMENT Nom (#PCDATA)> <!ELEMENT Primitif (#PCDATA)> <!ELEMENT InstanceAttribut (NomAttribut, ValeurAttribut)> <!ELEMENT NomAttribut (#PCDATA)> <!ELEMENT ValeurAttribut (#PCDATA)>

8.5.2.b) Exemple de fichier Flux.xml

<Flux href="D:\utilisateurs\Elod\RECIS\AncienProjet\avans1proj\flux\nfeu.avi" duree="125479" format="mpeg" id="Flux1">

<UAV id="Flux1%UAV_1____"> <t1_t2>0 125479</t1_t2> </UAV> <UAV id="Flux1%UAV_2____"> <t1_t2>0 29989</t1_t2> </UAV> <UAV id="Flux1%UAV_3____"> <t1_t2>29989 69139</t1_t2>

Annexes

203

</UAV> <EA id="Flux1%EA_1____"> <Nom>Stream</Nom> <Primitif>1</Primitif> </EA> <EA id="Flux1%EA_2____"> <Nom>Incident</Nom> <Primitif>1</Primitif> <InstanceAttribut> <NomAttribut>SIA_ImageRepresentative</NomAttribut> <ValeurAttribut>image1-incident</ValeurAttribut> </InstanceAttribut> <InstanceAttribut> <NomAttribut>SIA_Texte</NomAttribut> <ValeurAttribut>texte1-incident</ValeurAttribut> </InstanceAttribut> </EA> <EA id="Flux1%EA_5____"> <Nom>Lt. Tonton</Nom> <Primitif>1</Primitif> </EA> <EA id="Flux1%EA_6____"> <Nom>Pompier</Nom> <Primitif>0</Primitif> </EA> </Flux>


204

DTD d’un fichier DA.xml <!ELEMENT DA (EAA+)> <!ATTLIST DA nom CDATA #REQUIRED id CDATA #REQUIRED > <!ELEMENT EAA EMPTY> <!ATTLIST EAA EAA_ref CDATA #REQUIRED >

Exemple de fichier DA.xml

<DA nom="Footballeur" id="Footballeur"> <EAA EAA_ref="EAA_7____" /> <EAA EAA_ref="EAA_8____" /> <EAA EAA_ref="EAA_9____" /> </DA>

8.5.3. Les documents XML contenant les arêtes du graphe

8.5.3.a) DTD d’un fichier Liste.xml

<!ELEMENT ListeLiens (FicLien+)> <!ELEMENT FicLien EMPTY> <!ATTLIST FicLien href CDATA #IMPLIED >

8.5.3.b) Exemple de fichier Liste.xml

<ListeLiens> <FicLien href="C:\annotations\Liens_BdC_BdC.xml" /> <FicLien href="C:\annotations\Liens_BdC_Flux0.xml" /> <FicLien href="C:\annotations\Liens_BdC_Flux1.xml" /> <FicLien href="C:\annotations\DA_Footballeur.xml" /> </ListeLiens>

8.5.3.c) DTD d’un fichier Lien.xml

<!ELEMENT Liens (LiensSortants+)> <!ELEMENT LiensSortants (Origine,Destination+)> <!ELEMENT Origine EMPTY> <!ATTLIST Origine href CDATA #REQUIRED > <!ELEMENT Destination EMPTY> <!ATTLIST Destination type CDATA #REQUIRED

Annexes

205

href CDATA #REQUIRED >

8.5.3.d) Exemple de fichier Lien.xml

<Liens> <LiensSortants> <Origine href="C:\annotations\BdC.xml#EAA_Flux" /> <Destination href="C:\annotations\Flux0.xml#Flux0%EA_1____" type="Rif" /> </LiensSortants> <LiensSortants> <Origine href="C:\annotations\BdC.xml#EAA_3___" /> <Destination href="C:\annotations\Flux0.xml#Flux0%EA_2____" type="Rif" /> </LiensSortants> <LiensSortants> <Origine href="C:\annotations\BdC.xml#EAA_10___" /> <Destination href="C:\annotations\Flux0.xml#Flux0%EA_3____" type="Rif" /> </LiensSortants> <LiensSortants> <Origine href="C:\annotations\BdC.xml#EAA_7____" /> <Destination href="C:\annotations\Flux0.xml#Flux0%EA_4____" type="Rif" /> </LiensSortants> <LiensSortants> <Origine href="C:\annotations\BdC.xml#EAA_9____" /> <Destination href="C:\annotations\Flux0.xml#Flux0%EA_5____" type="Rif" /> </LiensSortants> <LiensSortants> <Origine href="C:\annotations\BdC.xml#EAA_4____" /> <Destination href="C:\annotations\Flux0.xml#Flux0%EA_6____" type="Rif" /> </LiensSortants> </Liens>


206

8.6. Choix de SGBD

Si les solutions proposées par les SGBD en XML natif sont intéressantes, elles ne nous concernent que très peu. Dans notre cas XML n’est utilisé que comme un format d’échange de données, les données contenues dans les documents XML sont beau-coup plus importantes que la structure du document. Nous n’avons donc pas d’intérêt à conserver les documents XML dans leur intégralité, d’autant plus qu’il est très dif-ficile de faire une requête ou des jointures sur un document XML. J’ai donc choisi de mettre en place un SGBD traditionnel compatible XML. Pour cela nous avons examiné trois solutions disponibles sur le marché : DB2, Oracle 9i et SQL Server 2000. DB2 est édité par IBM, ce SGBD offre deux possibilités : le document XML et sa DTD peuvent être stockés dans une colonne de type XMLCLOB, XMLVARCHAR ou XMLFile ou alors, les données du document sont réparties dans les tables de la base de données et le document XML n’est pas conservé. Dans ce cas, les DTD sont map-pés sur le schéma relationnel à l’aide d’un langage de définition (Data Access Defini-tion) propre au SGBD. Ce langage permet d’intégrer et d’extraire des données XML de la base [XMLDB #3]. Oracle 9i est édité par Oracle, ce SGBD offre lui aussi plusieurs solutions pour stoc-ker des documents XML : le document XML peut être stocké dans son intégralité, dans une colonne de type XMLType ou CLOB/BLOB. Le document peut ensuite être extrait en utilisant la fonction Extract() fournie par Oracle. Cette fonction est de type XMLType. Le document peut aussi être décomposé en morceau, chacun étant consi-déré comme un objet et stocké dans les tables relationnelles. Le document XML est alors reconstitué en utilisant XML SQL Utility (XSU) ou les fonctions SQL associées aux packages. Pour accéder aux informations contenues dans un document, Oracle fournit un outil Oracle Text. Cet outil est basé sur les spécifications XPath du W3C. Il est aussi possible de créer une vue relationnelle sur les documents XML et d’accéder aux données à partir de requêtes SQL [XMLDB #4]. Quant à SQL Server 2000, édité par Microsoft, la seule solution qui est à notre dispo-sition actuellement, consiste à stocker les données contenues dans un document XML dans les colonnes des tables de la base de données relationnelle. SQL Server fournit un outil FOR XML qui permet d’extraire des documents XML à partir des données de la base. Trois formats d’extraction sont à notre disposition : RAW, AUTO et EXPLI-CIT. L’instruction OPENXML est utilisée pour effectuer des requêtes XML sur un document ainsi que pour insérer les données du document dans la base de données re-lationnelle. Il est possible d’utiliser une sorte de XMLSchema proposé par Microsoft pour “ mapper ” les documents XML sur la base relationnelle. Ce mapping est appelé Vue XML et permet d’accéder aux données de la base relationnelle en utilisant XPath [XMLDB #5]. Les solutions proposées par Oracle sont sensiblement de même nature que celles qui sont offertes par les SGBD en XML natif. Cette solution ne m’intéresse donc pas puisque je n’ai pas d’intérêt à conserver les documents XML dans leur intégralité. Quant aux solutions proposées par IBM et par Microsoft, elles sont très semblables,

Annexes

207

j’ai donc choisi Microsoft parce qu’il met à notre disposition plus d’outils compati-bles avec Visual C++ (interfaces graphiques, API) pour manipuler les documents XML. [XMLDB #1] Allora, XML Platform for Data Exchange,

http://www.hitsw.com/dsheets/allorahigh-ov.htm, Janvier 2002 [XMLDB #2] XML Transformation Server (XTS),

http://www.iwaysoftware.com/iWay_ebix.html, Janvier 2002 [XMLDB #3] Cheng, J., Xu, J., IBM DB2 XML Extender, An end-to-end solu-

tion for storing and retrieving XML documents, http ://www-3.ibm.com/software/data/db2/extenders/xmlext/xmlextbroch.pdf, Janvier 2002

[XMLDB #4] Drake, M. D., XML and the Database : storing XML with all your other critical data, http://otn.oracle.com/tech/xml/pdf/131.pdf, Jan-vier 2002

[XMLDB #5] Conrad, A., A Survey of Microsoft SQL Server 2000 XML Fea-tures, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml/html/xml07162001.asp, Janvier 2002

[XMLDB #6] Bourret, R., XML Database Products, http://www.rpbourret.com/xml/XMLDatabaseProds.htm, Janvier 2002

[XMLDB #7] Bourret, R., XML and Databases, http://www.rpbourret.com/xml/XMLAndDatabases.htm, Janvier 2002

[XMLDB #8] http://www.xmldb.org/index.html, Janvier 2002 [XMLDB #9] Andreas, L., Lars, M., XUpdate Working Draft,

http://www.xmldb.org/xupdate/xupdate-wd.html, Janvier 2002

http://www.xmldb.org/index.html

http://www.xmldb.org/xupdate/xupdate-wd.html


208

8.7. Schémas de base de données

Figure 110 schéma de la base donné contenant le graphe des annotations

Annexes

209

Figure 111 schéma de la base de données de gestion des sessions


210

8.8. Communication

Comme nous l’avons présenté dans l’annexe 8.1, le prototype est découpé en modu-les. Nous reprenons le schéma sur la Figure 112 pour illustrer le déroulement de quelques interactions de manière plus détaillée. Nous allons présenter les interactions lors d’une session d’annotation à travers les interfaces du site dynamique (présenté dans la section 5.4.2.b) et dans l’annexe 8.4).

Analyseurd ’images

Serveur central

Fichiermpeg1

2. Choix d ’une vidéo àannoter selon la PAchoisie

1. Choix d’un PAN1,Secouriste,1,1

N3,Opération,3,n

N2,Victime,2,1

ReSD

[1,n]

ReSD

[n,1] Procédure d’Annotation (PA)

Analyseur Vidéo

3. Distribution destâches d ’annotationselon le PA

3.2 Analyseautomatique de lavidéo, extractiond’images

3.3 Analyse etindexation desimages extraites

3.4 (Sur)Annotationmanuelle

MODULE2

MODULE4IHM Java

MODULE5

MODULE3

ModuleX: Site physique ou virtuelle Interface logicielle (API) communiquant par http, transférant des données XML et binaires (mpeg, jpg,…)

Production

Fichiersmpeg1

Fichiersmpeg1

Images

Images

AFPS

UAV1

Secouriste

OpérationVictim e

UAV2

UAV3 UAV4 UAV5

Dr Jekyl

dégagem ent

vérification respirationvérification pouls

Mr. Tonton

EA1

EA2

EA3

EA5

EA4

N1

N2N3

N1

N3

N3

N3

N2

Annotations

Descripteurs

MODULE1IHM guidé

Figure 112 découpage en modules du démonstrateur RECIS

La Figure 113 présente le diagramme de communication lors de l’exécution d’une procédure d’annotation. Les colonnes représentent les modules de la Figure 112. Les interactions commencent sur le module 1, la machine de l’utilisateur, qui se connecte au serveur central en accédant à la page d’accueil (pas 1,2). Il choisit de faire une an-notation (pas 3,4), choisit le flux et la procédure d’annotation qui se lance et fait dé-clencher une série d’interactions entre les différents modules.

Annexes

211

Lancement dunavigateur1

2

3

4

6

Traitement de laPA1

Connexion

Confirmation find'annotation

Annotation

Page d'Annotation

Demande dedécoupage

7

10

Confirmation des résultats du découpage

Choix PA et flux

PA1 et Flux1

Résultats dedécoupage

Intégration desrésultats

9

11

12

13

Demande d'indexation

Indexation

Résultats d'indexation


M1 M5 M2 M3

14

15

16

17

Demande d'indexation manuelle18

Mise en place des annotations

Résultats de découpage


19

20

21

22

M4

Choix type de traitement

Première page

5

Figure 113 Diagramme de communication lors d’une annotation.

La Figure 114 présente le même dialogue lors d'un traitement long. En fait cela peut également s'appliquer à des traitements plus courts. Dans ce cas le Module 5 en appe-lant le script CGI 2_1 (opérations 1-2) lance le traitement (opération 3) et revient avec une confirmation de lancement (op. 5-6-7). Le script CGI 2_1 se connecte à l'application M2 par TCP/IP (socket) (op.3), précise le traitement à effectuer, lui passe l'URL du flux à traiter, attend que l'application ait commencé le téléchargement


212

(pour vérifier la validité de l'URL) et s'arrête avec une confirmation de début de trai-tements. L'application M2 récupère le flux à traiter (op. 4,8), effectue le traitement (op. 9). Pour passer les résultats des traitements au module 5 l'application M2 appelle un script CGI sur le module 5 (op. 10,11) avec, en paramètre le document XML conte-nant le découpage. Ce script (CGI 5_1) interprète le document XML (op.12) et ap-pelle les fonctions de création d'annotations de l'application centrale (op. 13,14).

Applicatoin centrale

Serveur Web 5 Serveur Web 2 Script CGI 2_1 Appli M2Script CGI 5_1

1 Appel de Script CGI 2_1 (URL Flux)2 Lancement Script 3 Lancement du traitement

6 Traitement lancé7 LancementOK

4 Chargement de données

8 Fin chargement

9 Traitement (découpage)

5 Traitement lancé

10 Appel CGI 5_1 Réponse (XML)11 Réponse (XML)

12 Interprétation de la réponse

13 Appels d'intégration

15 Intégration OK16 Intégration OK

14 Intégration OK

Module 5 Module 2

Figure 114 Partie 2 de la Figure 113 lors d'un traitement long (temps différé)

Dans le cas où le Module 5 et le Module 2 se trouvent sur une même machine (pour des questions de temps de transfert de vidéo) les pas 4 et 8 sont à ignorer. En effet il n’y a pas besoin de transférer la vidéo pour le découper.

8.8.1. L'architecture à mettre en place sur le serveur

Nous partirons du principe que l'application qui effectue le traitement que l'on désire ajouter est placée sur une machine distante.

Annexes

213

Le serveur principal du projet est composé d'une application principale doté d'un mo-dule d'écoute et de communication socket. La base de données de Gestion de Session contient une table Assistants contenant les informations nécessaires aux assistants. L'API de gestion de session offre aux assis-tants des méthodes pour récupérer les informations concernant l'assistant (description, Adresse de connexion, Port de communication …) Pour créer un assistant, il est nécessaire d'implanter les modules suivants sur le ser-veur :

• une DLL qui sera appelée par l'application et qui lancera sur une machine (dis-tante) les traitements adéquats (comment sont appelés ces traitements est du ressort de l'auteur de l'assistant). Cette DLL doit exporter une fonction ayant une déclaration définie (cf. plus bas). Si cet assistant a besoin de plus d'infor-mations qu'il ne lui est déjà fourni (par le biais de son appel), il lui est possi-ble de se connecter par socket à l'application et de demander ces informations (liste des flux disponibles …)

• Un script CGI qui se connectera au module de communication socket de l'appli-cation et effectuera, par le biais des opérations basiques mises à la disposition des clients (API d’intégration), l'intégration des résultats produits par le trai-tement (ajout de nœuds dans le graphe global, ajout d'UAV …)

Ainsi, l'architecture à mettre en place est de la forme suivante :

Module de traitement distant

ApplicationPrincipale

Module decommunication Sockets

AssistantDLL

Serveur Principal

CGI deréception etd'intégrationdes résultats

Traitement ….

Module à mettre en place pour chaque Assistant

Modules permanents et définitifs de l'application

Communication HTTP

Communication par Sockets Figure 115 : Architecture globale d'un assistant


214

8.8.2. Architecture interne au module distant

En ce qui concerne l'architecture interne au module distant, la décision est laissée aux créateurs d'assistants. Cependant, deux types d'architectures semblent les plus à même d'être utilisé dans le cadre du projet : une architecture pour traitements courts effec-tués au sein d'un CGI, et une architecture pour traitements différés effectués par une application.

8.8.3. Traitements courts

Si les traitements proposés par l'assistant sont courts, c'est à dire dans ce contexte qu'ils peuvent être réalisés au cours d'une durée de vie d'un script CGI (qui est géné-ralement d'à peu près 2 à 3 minutes), il est possible d'implanter sur le module distant un seul, ou plusieurs, scripts CGI qui effectueront le traitement et enverront la ré-ponse au Module5 (serveur central). Il ne faut pas oublier cependant qu'il est impéra-tif de créer la DLL assistant qui se chargera d'appeler le CGI sur le module distant et un CGI d'intégration des résultats (ces 2 modules se plaçant sur le serveur central).



AssistantDLL

Serveur Principal


Traitement effectuédans un CGI


Modules permanents et définitifs de l'application

Communication HTTP

Communication par Sockets


Figure 116 : Architecture pour un assistant effectuant des traitements courts

8.8.4. Traitements différés

Annexes

215

Si l'assistant doit effectuer des traitements qui ne peuvent être inscrits dans la durée de vie d'un CGI, il faut à ce moment utiliser une architecture basée sur une communi-cation entre des scripts CGI et une application. Le moyen le plus flexible par rapport à de tels besoin est l'utilisation de sockets.

L'architecture à mettre en place ressemble à la suivante :




AssistantDLL

Serveur Principal


Script CGI d'appelde traitement


Modules permanent et définitifs de l'application

Communication HTTP

Communication par Sockets

Application effectuant letraitement possédant unsocket d'écoute.

Figure 117 : Architecture pour traitements différés


216

8.8.5. Objets utilisés pour la gestion de session

ESIA_SESSION_GestionSessionm_indexUt il : intm_indexPA : intm_indexOp : ints_indexPA : ints_indexUti l : ints_indexOp : int

ESIA_SESSION_GestionSession()<<virtual>> ~ESIA_SESSION_GestionSession()GetIdentUt il(login : CString, pwd : CString) : CStringGetGroupUt il(id_Ut il : int) : CStringGetSessionsUtil(id_util : int) : CStringGetDetailsPA(id_PA : int) : CStringGetSession(id_PA : int) : CStringCreerSession(id_util : int, id_PA : int, flux : CString) : CStringLancerOp(id_uti l : int, nom_Assistant : CString, flux : CString) : BOOLFinirOp(id_op : int) : CStringGetTableOperations(id_Util : CString) : CTableOperations*GetAssistant(id_op : int) : CString

ESIA_SESSION_UtilisateursSetm_idGroupem_nomm_idUtilm_password

ESIA_SESSION_GroupesSetm_idGroupem_nom

Pour chaque méthode de ESIA_GestionSession, les objets d'accès a la base de données sont créés lorsque nécessaires et détruits immédiatement (les connexions BD ne sont ouvertes que lorsque la requête a utiliser à été mise dans l'objet).NB : Tous les objets d'accès données dérivent de CRecordSet ESIA_SESSION_

PAsAct ivesSetm_idSessionm_idPAm_fluxm_idUtilm_Etat

CPAsSetm_idPAm_nomm_description

ESIA_SESSION_PAsGroupeSet

m_idGroupem_idPA

ESIA_SESSION_AssistantsSet

m_idAssistantm_nomAssistantm_descriptionm_nomDLLm_adresseIP

ESIA_SESSION_OperationsSessionSetm_idAssistantm_idSessionm_idOperationm_Etat

ESIA_SESSION_AssistantsPASetm_idAssistantm_idPA

Figure 118 : Description en UML des objets gestion de Session

L'objet principal de le Gestion de Session est l'objet ESIA_SESSION_GestionSession (Figure 118). Un objet de ce type est crée pour chaque serveur socket crée par l'appli-cation (c'est-à-dire qu'à chaque fois que la classe ClistenerSocket reçoit un événement OnAccept(), elle crée un objet CserverCommunicator et que cet objet possède un at-tribut instance de la classe ESIA_SESSION_GestionSession). C'est dans cet objet que sont définies toutes les méthodes de récupération et de modification d'informations.

Les autres classes servent uniquement à faire le lien entre chaque table de la base de données (une classe par table de la base) et l'application. Elles dérivent toutes de la classe MFC permettant ces fonctionnalités : CRecordSet. Pour ne pas charger en mémoire tout le contenu d'une table, on ne lance les requêtes sur ces tables qu'après avoir spécififé les paramètres de la requête (attribut m_strFilter de la classe CrecordSet). De plus, chaque connexion est ouverte unique-ment lors d'accès à la base de données et refermée immédiatement après.