PROCESSUS D’ÉVOLUTION DE LA RESSOURCE TERMINOONTOLOGIQUE

Télécharger le fichier pdf d’un mémoire de fin d’études

Une méthode de référence pour la gestion des changements

Dans cette thèse, nous nous intéressons principalement au problème d’évolution d’ontologie suite à des changements du domaine ou à une nouvelle conceptualisation (les deux premiers cas précédents). Plus précisément, nous nous focalisons sur les cas où l’ontologie est liée à un corpus de documents textuels qui évolue, et que cette ontologie sert à annoter. Nous souhaitons prendre en compte tous les effets potentiels des changements effectués sur les entités ontologiques et vérifier la cohérence de l’ontologie après l’application de ces changements. Un autre point très important est de respecter la validité des applications utilisant l’ontologie après sa mise à jour et ce à travers la propagation des changements vers les données de ces applications. Dans notre cas, ces données sont les annotations sémantiques des documents basées sur l’ontologie.
Nous avons également l’intention de garder une trace de chaque changement dans l’ontologie et des scénarios considérés pour la faire évoluer. Dans cette perspective, plusieurs approches ont été proposées. Dans la suite, nous présentons tout d’abord des méthodologies existantes qui présentent un processus – plus ou moins global – d’évolution d’ontologie [Stojanovic et al., 2002a] [Stojanovic et al., 2002b] [Klein, 2004]. Ensuite, nous nous concentrons sur quelques approches qui traitent de problématiques particulières de gestion de changement telles que le processus d’évolution, la représentation d’un changement, la gestion de ses effets et de sa propagation vers les applications dépendantes.

Le Méta-modèle de RTO dans Dynamo

Dans DYNAMO, nous nous intéressons à l’utilisation et l’évolution de Ressources Termino-Ontologiques. Dans le cadre du projet, les ressources termino-ontologiques suivent un méta-modèle comportant non seulement une représentation des concepts du domaine et de leurs relations, mais aussi une représentation dédiée aux termes associés (termes désignant les concepts). Ainsi, la manifestation de chaque concept dans les documents est représentée dans l’ontologie sous forme de lexicalisations spécifiques. Ce méta-modèle est construit à partir de deux méta-classes.

Les méta-classes du méta-modèle

Afin de représenter les deux composantes d’une RTO et pour être conforme avec le standard le plus populaire pour représenter les ontologies, à savoir OWL19, [Reymonet et al., 2007a] ont défini un premier méta-modèle en OWL-DL, capable de représenter des termes.
Cependant, certains choix opérationnels avaient rendu le modèle peu satisfaisant du point de vue théorique [Reymonet et al., 2007b]. C’est pourquoi les auteurs ont apporté un certain nombre de modifications en se basant sur les primitives de méta-modélisation disponibles en OWL-Full. Le plus haut niveau d’abstraction du modèle définit deux sous-classes de la classe owl:Class : la classe Concept et la classe Term (figure III-3). Le méta-modèle permet ainsi de faire la distinction entre un objet de type concept, représenté par une sous-classe de DomainThing instance de Concept, et un objet de type terme, représenté par une sous-classe de TermOccurrence qui est par ailleurs instance de la méta-classe Term. Nous décrivons dans les sections suivantes chacun de ces objets ainsi que les liens qui existent entre eux.

La représentation d’un concept

En OWL, les éléments de base d’une ontologie sont matérialisés de la façon suivante :
les concepts de l’ontologie sous forme de sous-classes de owl:Thing, instances de owl:Class,
les attributs de concepts sous forme d’instances de owl:DatatypeProperty,
les relations entre concepts sous forme d’instances de owl:ObjectProperty
Dans la partie ontologique de la RTO de Dynamo, les concepts sont, de manière classique pour une ontologie, organisés dans une hiérarchie selon des relations subClassOf (classe/sousclasse), et décrits par des relations sémantiques autres que subClassOf (dites relations transverses). Dans le méta-modèle, chaque concept est représenté par une sous-classe de la classe DomainThing.

La représentation d’un terme

Dans une RTO de DYNAMO, les termes qui sont associés à un concept sont utilisés pour produire les annotations sémantiques décrivant le contenu des textes. L’annotation est posée lors de la reconnaissance dans les textes des termes qui dénotent des concepts de la composante ontologique de la RTO. De façon à pouvoir revenir aux textes pour lesquels une annotation a été produite, le méta-modèle permet de représenter à la fois les termes et leurs occurrences dans les textes.
Selon le modèle de RTO de [Reymonet, 2008] un objet de type Terme est une sous-classe de la classe TermOccurrence et instance de la méta-classe Term. Ce choix de modélisation s’avère pratique car il permet d’assimiler une occurrence de terme à une instance de la classe représentant le terme. Dans l’exemple de la figure III-3, les termes T37 et T49 ont comme propriétés les éléments suivants : la forme sous laquelle le terme est repéré et leur catégorie syntaxique et morphologique sous forme de owl:DatatypeProperty.

La modélisation des liens terme-concept

Selon le méta-modèle de la RTO, les concepts et les termes sont des instances de deux méta-classes adaptées de owl:Class. Pour les relier, Reymonet [Reymonet, 2008] a défini la propriété dénote ayant pour domaine la classe Term T et pour co-domaine la classe Concept C. La relation dénote permet de relier un ou plusieurs termes avec un ou plusieurs concepts.
De plus, chaque instance de terme (en fait de TermOccurrence) est reliée à une instance d’un concept par la relation désigne. Dans l’exemple de la figure III-3, l’occurrence du terme fumer dans le document txt52 est représentée comme l’instanceT49occ6 et désigne l’instance du concept Fumée à savoir l’instance Fumée f1. Une autre relation contains ajoutée au modèle de la RTO permet de lier un document aux occurrences de termes et aux instances des  concepts.

Le processus d’annotation sémantique dans Dynamo

Comme nous l’avons vu, le méta-modèle permet de représenter les liens entre la RTO et les documents considérés, et constitue ainsi un méta-modèle adapté pour représenter des annotations sémantiques faites à l’aide d’une RTO. Dans cette section, nous détaillons ce processus d’annotation sémantique qui exploite les textes et la RTO pour produire des annotations, tel qu’il est défini dans [Reymonet, 2008].

Génération des graphes d’annotations

La dernière étape du processus automatique d’annotation sémantique consiste, à construire un ou plusieurs graphes d’annotation (i.e. à retrouver les relations sémantiques existant entre deux instances de concepts) à partir de l’ensemble des instances de concepts associées à un document. Dans la figure III-3, la relation affecte entre Fumée F1, instance de concept Fumée, et Motorisation M1, instance de concept Motorisation est un exemple de relation.
Pour construire les graphes d’annotations, le système doit créer des relations entre les instances de concepts identifiées. Contrairement à l’identification des instances de concepts, qui s’appuie sur leur lexicalisation, aucun indice linguistique n’est ici utilisé. En effet, les textes ne comportent pas souvent dans nos applications de formulation explicite des relations.
Pour trouver ces relations entre instances de concepts, différentes heuristiques ont été définies [Thomas et al., 2010]. Certaines sont basées sur la proximité dans le document des occurrences de termes désignant les deux instances de concepts que l’on cherche à mettre en relation. D’autres heuristiques sont basées sur la cardinalité des relations, comme la suivante : « pour chacune des instances de concept découverte dans le document, pour chacune des relations ayant pour domaine ce concept et ayant une cardinalité minimale de 1, nous créons une instance du concept  co-domaine. Les restrictions sur les relations prennent ici toute leur importance pour créer des instances aussi spécifiques que possible. »

TextViz : éditeur d’ontologie et d’annotation

Le projet Dynamo a donné lieu à un prototype TextViz [Reymonet et al, 2009] qui a été développé comme un plug-in de Protégé. Il bénéficie ainsi des interfaces de Protégé qui ont été enrichies pour répondre aux besoins du projet. Ainsi, TextViz permet la gestion de RTO (les interfaces de Protégé ont été adaptées de manière à gérer les termes en plus des concepts et relations). TextViz permet également de visualiser les documents textuels du corpus ainsi que leurs annotations.

Exemples de scénario d’évolution dans Dynamo

Comme décrit dans la section 4.1, le projet Dynamo définit deux scénarios typiques menant à une évolution dans la RTO. Nous donnons dans cette section un exemple pour chacun d’entre-eux. Notons bien que la propagation vers les annotations sémantiques se fait dans les deux cas et sera détaillée dans le chapitre VI.

Evolution de la RTO suite à l’ajout de nouveaux documents

Tous les documents de la collection sont annotés en se basant sur la RTO. L’évolution du corpus (ajout, modification de documents), comme l’évolution de la RTO, amène à annoter ou ré-annoter les documents dans le cas où les annotations sont non valides.
La démarche prévue dans Dynamo (figure IV-2) est d’annoter automatiquement à partir du module dédié ces nouveaux documents. Cependant la RTO peut ne plus être en adéquation avec le corpus, ce qui mènerait à la création automatique d’annotations incomplètes ou fausses. Une annotation est incomplète si elle ne respecte pas les critères d’adéquation entre RTO et documents, choisis au préalable par l’ontologue (par exemple un nombre minimal d’annotations, une couverture minimale du texte et un ensemble de concepts à retrouver dans chaque document (voir section 6.5). Pour chaque document, un score est défini et permet d’évaluer dans quelle mesure les critères sont vérifiés par les annotations qui ont été produites à partir de son analyse. Finalement, l’ontologue peut parcourir la liste des documents en commençant par ceux dont le score de vérification des critères est faible. Bien que ce processus soit manuel, il est efficace parce qu’il permet de guider l’ontologue rapidement vers des fiches mal annotées(celles qui ont un score faible). Or une mauvaise annotation correspond en général à l’identification de concepts ou de termes manquants dans la RTO. Il faut itérer sur l’utilisation du module d’évolution de la RTO jusqu’à obtenir une annotation satisfaisante pour l’ontologue. Celui-ci peut décider alors d’effectuer des changements, soit, dans la RTO, en général l’ajout de nouveaux termes pour les concepts existants ou l’ajout de nouveaux concepts qui sont des sous-classes des concepts attendus dans les critères d’annotation, soit, par la modification manuelle des annotations.

Modification directe de la RTO par l’ontologue

Dans ce deuxième scénario, l’ontologue décide directement d’effectuer des changements dans la RTO, en général l’ajout, la suppression, la modification, la fusion, la division … des concepts et/ou des relations, l’ajout de nouveaux termes pour des concepts existants ou la suppression de termes…La liste des changements possibles est présentée dans les sections 5.4.4 et 5.4.5. Ce choix de l’ontologue peut provenir par exemple de modifications ou d’évolutions dans le domaine concerné par la RTO ou bien de choix de modélisation différents comme dans l’exemple ci-dessous.
La démarche prévue pour ce scénario (figure IV-7) est de modifier la RTO existante en utilisant EvOnto le module d’évolution de la RTO.

EvOnto : approche semi-automatique pour aider d’une manière interactive l’utilisateur

Gérer l’application des changements tout en maintenant la cohérence au sein des différentes ressources est une tâche coûteuse en termes de temps. La complexité de la tâche peut aussi être une source d’erreurs.
Pour assister l’ontologue dans cette tâche, nous avons défini une méthode de gestion de changement EvOnto (EVOlutionONTOlogie) avec un logiciel associé. Nous proposons un processus semi-automatisé permettant d’aider de manière interactive l’utilisateur et de conduire l’application des changements tout en maintenant la cohérence entre la RTO modifiée et les annotations sémantiques de collections documentaires.

Dans le contexte de modification de la RTO

Dans le contexte de la RTO elle-même, l’évolution peut être motivée par deux raisons principales. La première raison correspond au cas où l’ontologue se rend compte d’erreurs de représentation dans la RTO (un terme n’a pas été associé au bon concept, la signature d’une propriété n’est pas correcte, deux concepts devraient être fusionnés etc.). Il peut aussi vouloir préciser la modélisation : un exemple de ce type de changement est présenté dans la section précédente (figure V-2), nous avons fait une opération de division du concept Interface en sous-concepts User_Interface et Screen.
L’autre raison correspond au cas où le domaine représenté dans la RTO évolue (apparition d’un nouveau terme, modification du sens d’un terme, etc.). Par le biais de l’éditeur d’ontologies du système, l’ontologue apportera la modification souhaitée. Un exemple de changement est présenté dans la section précédente (figure V-2), nous avons fait une opération de déplacement de lien de dénotation du terme T_Properties pour dénoter un nouveau concept ConfigFile. Pour information, Le concept ConfigFile exprime un fichier de configuration et le terme T_Properties exprime un type de fichier dans lequel on peut stocker des informations de paramétrage pour pouvoir les modifier sans avoir à recompiler.

Typologies des changements

Pour exprimer l’évolution, nous avons besoin de recenser l’ensemble des modifications que l’on peut apporter aux ressources termino-ontologiques. Cette typologie est essentiellement un ensemble des changements typés, chaque changement ayant une signification bien précise.
Les changements peuvent être élémentaires, comme l’ajout ou l’effacement d’une entité de la RTO et comme nous l’avons présenté dans le chapitre IV, un changement élémentaire est celui qui peut être identifié en analysant uniquement la structure conceptuelle (concept, relation, attribut) ou lexicale (terme) de la RTO.
Les changements peuvent être aussi complexes, comme le déplacement ou la fusion d’une ou plusieurs entités de la RTO et comme nous l’avons présenté dans le chapitre IV, chaque changement complexe est la conséquence de l’association de deux ou plusieurs changements élémentaires. Théoriquement, l’ensemble de changements complexes est infini, parce que le nombre de combinaisons possibles est aussi infini.
Selon [Rogozan, 2008], les changements complexes possèdent une sémantique plus importante que les élémentaires. Par exemple, la sémantique d’un changement complexe de division SplitConcept est clairement plus riche que l’ensemble de changements élémentaires formé d’un seul DeleteConcept et de plusieurs AddConcept. De ce fait, les changements complexes peuvent mieux capter l’intention exacte des acteurs ayant fait évoluer la RTO et peuvent, par la suite, offrir une vue pertinente sur la vraie signification de l’évolution.
En partant du modèle de RTO [Reymonet et al., 2007], nous proposons une typologie des changements applicables [Tissaoui, 2009] [Tissaoui et al., 2011] [Tissaoui et al., 2013] à une RTO définie selon ce modèle. Cette typologie élargit la conceptualisation de [Stojanovic, 2004] et [Luong, 2007], par l’ajout d’un certain nombre de caractéristiques dont la plus notable est la prise en compte du lexique de la RTO qui peut évoluer à cause des changements portant sur les termes et les liens de dénotations. Nous avons aussi introduit un certain nombre de caractéristiques afin de mieux spécifier le type et l’effet de chaque changement sur la RTO (discutées en détail dans section 5.6).
Avant de mettre en oeuvre un changement, nous proposons de vérifier les pré-conditions associées au changement et définies dans la typologie, afin de présenter à l’ontologue l’éventueles incohérences provoquées par la mise en oeuvre du changement.
Nous proposons de définir deux types de changement : les changements élémentaires et les changements complexes.
Tout d’abord, lorsque l’ontologue choisit d’effectuer un changement complexe le système pourra lui présenter directement les conséquences de ce changement au lieu de laisser imaginer l’enchainement des conséquences des changements élémentaires composant le changement complexe. Prenons l’exemple de MergeConcept qui permet de fusionner deux concepts dans la hiérarchie des concepts. L’opération MergeConcept est une séquence de changements élémentaires à savoir plusieurs DeleteConcept et un seul AddConcept. Prenons l’exemple ci-dessus (section 5.3), l’ontologue décide de fusionner les concepts Unzoom_Function et Zoom_Function, en un seul concept Display_Function. Dans un premier temps, l’ontologue doit supprimer les concepts Unzoom_Function et Zoom_Function ; dans un deuxième temps, il crée le concept Display_Function comme concept fils du concept Function.
Par conséquent, avec EvOnto et en utilisant notre typologie de changements, l’ontologue peut visualiser une seule opération, à savoir MergeConcept au lieu de visualiser deux ou plusieurs opérations telles que plusieurs DeleteConcept et un seul AddConcept.

Table des matières

Chapitre 1 : INTRODUCTION GÉNÉRALE
1.1 Contexte de la thèse
1.1.1 Contexte scientifique
1.1.2 Contexte applicatif
1.2 Problématique posée
1.3 Contributions apportées
1.4 Organisation du manuscrit
PARTIE 1 : ÉTAT DE L’ART : ÉVOLUTION D’ONTOLOGIES ET D’ANNOTATIONS SÉMANTIQUES
Chapitre 2 : ÉVOLUTIONS
2.1 Introduction
2.2 Évolution d’ontologie : gestion du changement
2.2.1 Définition
2.2.2 Origines des changements d’une ontologie
2.2.3 Une méthode de référence pour la gestion des changements
2.2.3.1 Modèle d’une ontologie
2.2.3.2 Évolution d’ontologie selon Stojanovic
2.2.4 Autres approches d’évolution d’ontologie
2.2.4.1 Evolution et gestion de versions
2.2.4.2 Evolution d’une ontologie dans un contexte d’annotation [Rogozan et Paquette, 2005] et [Rogozan, 2008]
2.2.4.3 Evolution d’ontologie adaptée de la méthode KAON [Djedidi et Aufaure, 2008a], [Djedidi, 2009] et [Djedidi et Aufaure, 2009]
2.2.4.4 Tracer les évolutions [Luong, 2007], [Luong et Dieng-Kuntz, 2007]
2.2.4.5 Evolution d’ontologie à partir de données multimédia [Castano, 2006], [Castano et al., 2007]
2.2.4.6 Approches logiques de l’évolution d’ontologie
2.2.5 Représentation des changements
2.2.5.1 Représentation des changements selon Klein [Klein et Noy, 2003] et [Klein, 2004]
2.2.5.2 Représentation des changements dans l’ontologie CHAO [Noy et al., 2006]
2.2.5.3 Modélisation formelle des changements [Luong, 2007] [Luong et Dieng-Kuntz, 2007]
2.2.5.4 Représentation des changements selon Rogozan [Rogozan, 2008] [Rogozan et Paquette, 2005]
2.2.6 Effets des changements
2.3 Gestion de la dynamique des annotations sémantiques
2.3.1 Dynamique des annotations dans la plateforme NEON [Maynard et al., 2007]
2.3.2 CoSWEM : évolution d’annotations suite à l’évolution d’ontologie [Luong, 2007] [Luong et Dieng-Kuntz, 2007]
2.3.3 SAM : modifier les annotations à partir d’un journal d’évolution [Rogozan et Paquette, 2005] [Rogozan, 2008]
2.4 Logiciels d’aide à l’évolution d’ontologie
2.4.1 Gestion des évolutions dans les éditeurs d’ontologie
2.4.2 Logiciels dédiés à l’évolution d’ontologie
2.4.2.1 Gestion des évolutions dans KAON [Stojanovic et al., 2002a], [Maedche et Staab, 2003] et [Gabel et al., 2004]
2.4.2.2 EVOLVA [Zablith, 2011], [Zablith et al., 2010], [Zablith et al., 2010], [Zablith et al., 2009]} et [Zablith, 2009]
2.4.2.3 ONTO-EVOAL [Djedidi et Aufaure, 2008a], [Djedidi, 2009], [Djedidi et Aufaure, 2009] et [Djedidi et Aufaure, 2010]
2.5 Logiciels gérant l’évolution d’annotations sémantiques
2.5.1 TextViz [Reymonet et al., 2007], [Reymonet et al., 2009] et [Reymonet et al., 2010]
2.5.2 Éditeur ECCO et outil CoSWEM [Luong et al., 2007], [Luong et Dieng-Kuntz, 2007] et [Luong, 2007]
2.6 Discussion
2.7 Conclusion
PARTIE 2 : EVONTO – UNE APPROCHE POUR L’ÉVOLUTION DES RTO ET DES ANNOTATIONS SÉMANTIQUES
Chapitre 3 : LE PROJET DYNAMO : ONTOLOGIES DYNAMIQUES POUR L’ANNOTATION SÉMANTIQUE
3.1 Introduction
3.2 Le projet Dynamo
3.2.1 Contexte
3.2.2 Caractère novateur
3.2.3 Les applications dans Dynamo
3.3 Le Méta-modèle de RTO dans Dynamo
3.3.1 Les méta-classes du méta-modèle
3.3.2 La représentation d’un concept
3.3.3 La représentation d’un terme
3.3.4 Représentation d’une occurrence de terme
3.3.5 La modélisation des liens terme-concept
3.4 Le processus d’annotation sémantique dans Dynamo
3.4.1 Représentation des annotations
3.4.2 Pose des annotations
3.4.3 Génération des graphes d’annotations
3.5 TextViz : éditeur d’ontologie et d’annotation
3.6 Conclusion
Chapitre 4 : LA MÉTHODE EVONTO : CONTEXTE ET PRÉSENTATION GÉNÉRALE
4.1 Introduction
4.2 Problématiques d’évolution dans Dynamo
4.2.1 Besoin en évolution
4.2.2 Exemples de scénario d’évolution dans Dynamo
4.2.2.1 Evolution de la RTO suite à l’ajout de nouveaux documents
4.2.2.2 Modification directe de la RTO par l’ontologue
4.3 EvOnto : approche semi-automatique pour aider d’une manière interactive l’utilisateur
4.3.1 Aspects importants de l’évolution
4.3.2 Vue unifiée de l’approche EvOnto : méthodologie
4.4 Conclusion
Chapitre 5 : PROCESSUS D’ÉVOLUTION DE LA RESSOURCE TERMINOONTOLOGIQUE
5.1 Introduction
5.2 Modèle de la RTO
5.3 Exemple illustratif
5.4 Expression d’un changement
5.4.1 Dans le contexte de modification de la RTO
5.4.2 Dans le contexte de vérification des annotations
5.4.3 Typologies des changements
5.4.4 Changements élémentaires
5.4.5 Changements complexes
5.5 Présentation des stratégies et simulation de leurs conséquences
5.5.1 Stratégie d’évolution de la ressource termino-ontologique
5.5.2 Exemple de stratégie d’évolution
5.6 Choix de la stratégie et ajustement des conséquences
5.7 Application du changement à la RTO
5.8 Conclusion
Chapitre 6 : PROCESSUS D’ÉVOLUTION D’ANNOTATIONS SÉMANTIQUES
6.1 Introduction
6.2 Exemple illustratif
6.3 Contexte d’évolution
6.4 Propagation des changements aux annotations
6.4.1 Détection des annotations incohérentes
6.4.1.1 Interrogation des graphes d’annotations
6.4.1.2 Rechercher les occurrences des termes
6.4.2 Rectification des annotations incohérentes
6.4.3 Mise à jour interactive de la base d’annotations
6.5 Evaluation de la qualité des annotations
6.5.1 Contexte
6.5.2 Aide à l’évaluation d’annotations
6.6 Conclusion
PARTIE 3 : UTILISATION ET ÉVALUATION D’EVONTO
Chapitre 7 : ÉVALUATION DU SYSTEME EVONTO
7.1 Introduction
7.2 Scénario d’utilisation de l’outil EvOnto
7.2.1 Dans le contexte d’évolution de la RTO et d’annotations sémantiques
7.2.2 Dans le contexte d’évaluation de la qualité d’annotations
7.3 Techniques d’évaluation des systèmes
7.3.1 Critères d’évaluation
7.3.2 Approche qualitative pour l’évaluation du prototype
7.4 Démarche d’évaluation du système EvOnto
7.4.1 Participants à l’évaluation
7.4.2 Procédure d’évaluation
7.4.2.1 Présentation d’EvOnto
7.4.2.2 Phase « d’entrainement » avec EvOnto
7.4.2.3 Évaluation du système EvOnto
7.4.3 Résultats d’évaluation
7.4.3.1 Expérimentation avec les données d’ARTAL
7.4.3.2 Expérimentation avec les données d’ACTIA
7.5 Analyse des résultats
7.6 Bilan d’évaluation de la qualité d’EvOnto
7.7 Conclusion
Chapitre 8 : CONCLUSION ET PERSPECTIVES
8.1 L’évolution d’ontologie : une question insuffisamment étudiée
8.2 Synthèse des contributions
8.2.1 Processus d’évolution de la ressource termino-ontologique
8.2.1.1 Typologie des changements
8.8.1.2 Stratégies d’évolution et ajustement
8.2.2 Processus d’évolution des annotations
8.2.3 Résultat d’évaluation d’EvOnto
8.3 Perspectives à court terme
8.4 Perspectives à plus long terme pour EvOnto
8.4.1 Aide à la découverte de nouveaux termes
8.4.2 Situer les nouvelles entités dans l’ontologie existante
Bibliographie personnelle
Bibliographie

Télécharger le rapport complet