Le projet LogMap est un système permettant la génération de correspondances entre
deux bases de connaissances. Le processus global de ce projet est présenté dans la figure18.
Ce processus est constitué de cinq étapes :
Indexation terminologique et structurelle (Lexical and Structural Indexation) : La
première étape est l’indexation terminologique des éléments constituant les
ontolo-gies en entrée. Elle indexe non seulement les chaînes de caractères associées aux
63. http://oaei.ontologymatching.org/2014/
64. http://islab.di.unimi.it/im_oaei_2014/index.html
Figure 18 – Processus LogMap [Jiménez-Ruiz and Grau, 2011]
éléments mais aussi les éléments hiérarchiquement au-dessus et en-dessous de
l’élé-ment. Une représentation de type "interval labelling schema" [Agrawal et al., 1989]
permet de repérer facilement et rapidement si un élément est une spécialisation ou
une généralisation d’un autre.
Génération des ancres initiales (Compute Initial Anchors) : En utilisant une
tech-nique de comparaison de chaînes de caractères, des ancres sont générées entre les
deux ontologies. La comparaison utilisée ici est la similarité exacte des chaînes
de caractères. De cette manière, des correspondances avec une forte fiabilité sont
générées et serviront de point d’entrée pour les prochaines étapes.
Réparation des correspondances (Mapping Repair) : En utilisant un raisonneur,
Log-Map essaie de déterminer les correspondances apportant un incohérence
(particuliè-rement en utilisant les classes disjointes). De cette manière, des correspondances
sont supprimées pour éliminer ces incohérences.
Découverte des correspondances (Mapping Discovery) : S’il existe encore des
voi-sins non étudiés (condition "Expand"), alors chaque paire de voivoi-sins des éléments
déjà étudiés est étudiée à son tour afin de déterminer s’il existe une correspondance
entre-eux. Cette correspondance est définie à partir d’une comparaison
terminolo-gique des éléments, mais aussi grâce à une comparaison structurelle en utilisant la
hiérarchie de généralisation et de spécialisation associée aux éléments. S’il existe une
correspondance entre deux nouveaux éléments, alors cette correspondance est
ajou-tée dans la base des correspondances et les éléments sont ajoutés dans les éléments
à étudier. Un score de fiabilité est associé à chacune des correspondances suivant les
similarités terminologique et structurelle. L’étape de réparation des correspondances
est de nouveau effectuée avec cette nouvelle base de correspondances.
Calcul de l’intersection (Compute Overlapping) : Lorsqu’il n’existe plus de paire
d’éléments à étudier dans le voisinage des éléments actifs, alors deux sous-ensembles
(un pour chaque ontologie) sont générés. Ces sous-ensembles représentent les
élé-ments qui n’ont pas été mis en correspondance dans les étapes précédentes. De
cette manière, un expert peut intervenir uniquement sur ces sous-ensembles pour
ajouter des correspondances.
L’outil LogMap permet de répondre aux besoins de notre processus. En effet, cet
outil permet non seulement de mettre en correspondance des classes de l’ontologie mais
également des individus dans la partie assertionnelle. De plus, la participation de cet outil
à la campagne d’évaluation OAEI a permis de mettre en évidence ses bons résultats. Après
exprimentation de l’outil, nous avons pu observer qu’un seul type de correspondances
était détecté : les équivalences. Nous considérerons donc dans la suite de ce manuscrit
que les correspondances obtenues par l’outil LogMap ne sont que des équivalences.
Ces correspondances nous permettent de détecter les éléments communs à plusieurs
sources. Nous cherchons alors à fusionner ces éléments pour obtenir l’élement qui sera
présent dans la base de connaissances finale à représenter.
3. Fusion de bases de connaissances
3.1. Fusion d’ontologies
Nous considérerons dans ce manuscrit la définition de fusion telle qu’elle est définie
dans les travaux [Pottinger and Bernstein, 2003] :
En considérant deux modèles A et B et un ensemble de correspondances
M ap
AB, le processus de fusion génère un troisième modèle représentant l’union
sans doublon des modèles de A et B conformément aux correspondances de
M ap
AB.
Cette définition est suffisamment générique pour considérer comme modèle plusieurs
types de sources, telles que des bases de données, des diagrammes UML ou encore des
ontologies. La notion de "union sans doublon" est particulièrement importante dans cette
définition. Eliminer les doublons lors d’une fusion de deux modèles peut être un processus
complexe. Prenons un exemple simple de définition du nom d’une personne. Si le modèle
A définit le nom comme un seul attribut alors que le modèle B définit le nom de famille
et le prénom, la fusion naïve de ces attributs peut amener à avoir les trois attributs dans
le modèle final.
Afin d’étudier les travaux traitant de cette notion de fusion de bases de connaissances,
nous avons défini quatre critères :
Symétrique : La notion de fusion symétrique implique que les deux modèles à
fu-sionner ont la même importance. Il est possible d’utiliser une technique de fusion
asymétrique pour privilégier un modèle plutôt qu’un autre lors de choix à faire
dans la modélisation du modèle résultat.
Processus d’alignement inclus (Align.) : Certains travaux impliquent le processus
d’alignement des modèles dans leur processus alors que d’autres considèrent les
correspondances comme une entrée du système.
Conflits : Certains travaux prennent en compte la notion de conflits pouvant exister,
un conflit étant une fusion impliquant une incohérence dans le modèle.
Projet Symétrique Align. Conflits Confiance
Vanilla
oui non oui non
[Pottinger and Bernstein, 2003]
Prompt
oui oui oui non
[Noy and Musen, 2003]
Atom
non non oui non
[Raunich and Rahm, 2014]
Table 11 – Travaux sur la fusion
Confiance : Suivant le processus de fusion appliqué, une confiance peut être associée
aux éléments fusionnés.
Nous pouvons remarquer sur le tableau 11 que seul le projet Atom présenté dans
[Raunich and Rahm, 2014] propose un processus asymétrique lors de la fusion. Ce
pro-cessus asymétrique permet de définir un modèle prioritaire par rapport à l’autre. De
cette façon, certaines ambiguïtés susceptibles d’apparaître lors de la fusion peuvent être
résolues automatiquement. C’est par exemple le cas pour notre exemple de définition
du nom d’une personne. Si le modèle B est privilégié par rapport au modèle A, alors
le modèle final aura deux attributs "prénom" et "nom de famille". Nous remarquons
également sur le tableau11 que seul le projet Prompt propose un système d’alignement
intégré au processus de fusion. Comme nous l’avons vu dans la section précédente, il
existe de nombreux systèmes d’alignement permettant d’obtenir des correspondances
entre ontologies. Il n’est ici pas nécessaire de proposer un nouveau processus d’alignement
mais plutôt de réutiliser des travaux existants et éprouvés.
Un point important figurant sur ce tableau est que tous les travaux proposent une gestion
des conflits. Les travaux de [Pottinger and Bernstein, 2003] proposent une catégorisation
des types de conflits pouvant apparaître lors du processus de fusion :
Représentation : un conflit de représentation apparaît quand le même élément du
monde réel est modélisé sous deux formes différentes dans les deux modèles à
fusionner (c’est par exemple le cas de la représentation du nom d’une personne
dans notre exemple précédent)
Modèle : un conflit lié au modèle apparaît lorsque la fusion apporte une incohérence
liée au modèle utilisé.
Fondamentale : un conflit fondamental apparaît lorsque la fusion apporte une
inco-hérence par rapport à la représentation des données. Par exemple un élément ne
peut être que d’un seul type fondamental (entier, chaîne de caractères, ...).
Les travaux sur Prompt [Noy and Musen, 2003] définissent les conflits de la même
manière et proposent une interface spécifique pour résoudre ces conflits. Les travaux
sur Vanilla [Pottinger and Bernstein, 2003] s’intéressent particulièrement à la dernière
catégorie. Pour cela, les auteurs proposent un ensemble de règles permettant de résoudre
ces conflits de manière générique. Ils partent de l’hypothèse que ce type de conflits est
présent quel que soit le type de modèle utilisé (bases de données, ontologies ou autres).
Les travaux sur Atom [Raunich and Rahm, 2014] traitent spécifiquement des conflits du
premier type : représentation. Pour cela, les auteurs utilisent un processus asymétrique
afin de privilégier une modélisation plutôt qu’une autre lors du processus de fusion
d’ontologies.
Nous remarquons enfin que les processus de fusion présentés ici ne traitent pas de la
notion de confiance. La problématique de fusion étant toujours considérée entre deux
modèles, la confiance ne peut pas apparaître puisqu’il n’y a qu’une alternative possible. La
notion d’asymétrie est donc suffisante dans ce cas-là. Néanmoins, lorsque nous considérons
la notion de fusion avec plus de deux sources à fusionner, nous pouvons généraliser la
notion d’asymétrie en considérant l’importance des sources dans ce processus. Apparaît
dans ce cas la notion de confiance d’un élément en fonction des sources impliquées et
particulièrement de leurs qualités respectives.
