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 apAB, 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 apAB.
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.