Nous avons présenté dans la section précédente la qualité des candidats générés et
l’impact de la fonction de calcul de la confiance consensuelle sur le filtrage des candidats.
Nous n’avons pas considéré dans ces calculs la génération d’une extension et l’intérêt de
l’utilisation d’une fonction de confiance consensuelle dans un processus de validation des
candidats.
Nous allons présenté ici nos expérimentations concernant la création d’une extension
sur le domaine de la taxonomie des blés. Pour cela nous générons une extension et nous
demandons à un expert de valider chaque candidat sommet contenu dans l’extension. Si
un des candidats sommets de l’extension n’est pas validé par l’expert alors une nouvelle
extension est recherchée en imposant d’inclure tous les candidats déjà validés et en
excluant tous les candidats invalidés. Le processus s’arrête lorsque l’expert a validé tous
les candidats d’une extension. Nous allons montrer qu’un expert a besoin de moins
d’interactions (action de valider ou invalider un candidat) pour trouver l’extension
optimale (extension dont tous les candidats sont validés) lorsque nous prenons en compte
le calcul de confiance des candidats. Cette confiance est utilisée dans la fonction objective
pour trouver une extension mais aussi pour trier les candidats à valider dans une extension.
Ce tri permet de présenter à l’expert en premier les candidats le plus susceptibles d’être
validés. Dans ces expérimentations nous allons considérer uniquement la fonction de
calcultrust
choquet.
La génération d’une extension étant un processus qui prend d’autant plus de temps
qu’il y a d’incompatibilités il ne nous a pas été possible d’effectuer cette évaluation
sur la totalité des candidats sommets générés. Effectivement nous avons générés au
total 212 candidats sommets, avec environ 1500 incompatibilités entre ces candidats. La
génération d’une extension a duré 6h sur une machine standard
105 et a permis d’obtenir
une extension contenant 17 candidats. Néanmoins ce processus devant être exécuté chaque
fois qu’un candidat n’est pas validé par l’expert, il n’était pas envisageable d’évaluer la
génération d’une extension sur la totalité des candidats sommets générés.
Nous avons fais le choix de ne considérer que les candidats sommets ayant un score
de confiance supérieur à 0.45. De cette manière nous obtenons 100 candidats avec 1150
incompatibilités et une extension est calculée en moins de 3 minutes.
Le tableau 26permet d’observer les résultats obtenus lors de nos expérimentations. La
première ligne considère la génération d’une extension avec comme fonction objective
la maximisation du nombre de candidats. La deuxième ligne présente les résultats en
utilisant la fonction objective maximisant la somme des scores de confiances des candidats
comme présenté dans la section 4.5.4du chapitre III.
Le tableau 26 présente, pour les deux fonctions objectives définies, d’abord le nombre
de candidats dans l’extension maximumext
max. Cette extension est la première extension
trouvée par le système, elle représente l’extension qui maximise la fonction objective
sans considération de validation de candidats. En d’autres termes, si nous ne faisions pas
l’étape de validation avec l’expert, c’est cette extension que nous aurions considérée. Ce
Fnct Obj. |ext
max| |ext
opti| Nb interactions
Nb. Cands 10 7 55
Confiance 10 7 25
Table 26 – Résultats des expérimentations sur la recherche d’une extension optimale
tableau présente aussi le nombre de candidats présents dans l’extension optimale ext
opti.
Cette extension est celle obtenue à la fin du processus de validation avec l’expert. Nous
savons que cette extension contient uniquement des candidats validés par l’expert. Enfin
le tableau présente le nombre d’interactions qui ont été nécessaire à l’expert pour obtenir
l’extension optimale. Nous considérons ici une interaction comme l’action de définir qu’un
candidat est valide ou invalide.
Nous pouvons observer qu’en utilisant les deux fonctions objectives nous obtenons
la même extension maximale, contenant 10 candidats. Nous pouvons remarquer aussi
que l’extension optimale est aussi la même avec 7 candidats. Cette similarité est moins
étonnante puisque ce sont les candidats validés par l’expert. Par contre nous pouvons
voir que l’extension optimale contient 3 candidats de moins que l’extension maximale.
Ceci est due au fait que 3 des candidats de l’extension maximale et tous les candidats
incompatibles à ces candidats n’ont pas été validés par l’expert. Ce qui signifie qu’un
filtre sur le score de confiance et la considération des incompatibilités ne sont pas suffisant
pour garantir des candidats valides. Il est toujours nécessaire de passer par une phase de
validation manuelle par un expert pour s’assurer de la qualité du résultat.
Ce qui nous intéresse particulièrement dans le tableau 26 ce sont les nombres
d’in-teractions qui ont été nécessaire à l’expert pour découvrir l’extension optimale. Nous
considérons ici un ensemble de 100 candidats avant la recherche d’extension. Si nous
avions demandé à un expert de valider ces candidats sans considérer les incompatibilités,
celui-ci aurait eu besoin de 100 interactions pour tous les valider. En considérant les
incompatibilités et une fonction objective maximisant le nombre de candidats dans
l’ex-tension, l’expert n’a eu besoin que de 55 interactions. Ce sont donc 45% des candidats qui
n’ont pas eu besoin d’être validé puisqu’ils sont incompatibles avec les candidats validés.
La phase de validation demandée à l’expert est donc particulièrement simplifiée. Si nous
observons ensuite le nombre d’interactions nécessaire lors d’une utilisation d’une fonction
objective maximisant la somme des scores de confiances, ce nombre d’interactions passe
à 25. En ne validant que 25% des candidats, l’extension optimale a été découverte. Cette
extension étant la même que l’extension obtenue avec une fonction objective maximisant
le nombre de candidats, nous ne perdons pas en qualité du résultat obtenu.
En observant les résultats obtenus lors de ces évaluations nous pouvons en conclure
trois aspects importants sur la qualité des candidats générés. Tout d’abord nous avons
observé que le filtrage des candidats sur le score de confiance et la considération des
incompatibilités ne sont pas suffisants pour valider les candidats. Il est nécessaire de passer
par une validation manuelle pour obtenir un bon résultat. Ensuite nous avons vu que
l’utilisation des incompatibilités a permis de diminuer le nombre d’interactions nécessaires
pour obtenir un ensemble de candidats compatibles tous validés. La considération des
incompatibilités permet ici de simplifier le travail de validation de l’expert. Le dernier
aspect est l’utilisation des scores de confiance dans la découverte de l’extension. Cette
considération a permis de diminuer de moitié le nombre d’interactions qui ont été
nécessaire à l’expert pour trouver l’extension optimale. Ceci permet de montrer que le
score de confiance calculé permet de donner une bonne intuition sur la validité d’un
candidat.
2. Expérimentations sur un jeu de données issu du Web de
données liées
Après avoir expérimenté notre approche sur le domaine de la taxonomie des blés, nous
avons souhaité montrer la généricité de notre approche. Pour cela, nous avons appliqué
notre méthodologie à un domaine totalement différent. Nous avons voulu analyser les
résultats de notre approche sur un jeu de données plus volumineux que la taxonomie des
blés et qui n’aurait pas été construit dans l’objectif d’être utilisé dans notre approche.
De plus, nous considérons des sources qui sont déjà des bases de connaissances et non
des sources non-ontologiques.
Pour cela, nous avons utilisé le jeu de données fourni pour la campagne d’évaluation
des systèmes d’alignement OAEI. Cette campagne d’évaluation comprend une tâche
dont l’objectif est d’évaluer et de comparer les systèmes d’alignement en analysant la
pertinence des correspondances générées par les systèmes pour reformuler des requêtes
SPARQL. L’idée est de s’appuyer sur les correspondances générées par le système pour
traduire une requête SPARQL posée initialement sur une première base en une requête
SPARQL équivalente posée sur une deuxième base. Notre objectif n’est pas de nous
positionner par rapport aux systèmes d’alignements car notre méthodologie a un but
différent. Nous cherchons à montrer que notre méthodologie permet de fusionner les bases
de connaissances considérées et de retrouver en une requête SPARQL sur la base résultant
de la fusion l’ensemble des réponses présentes dans les différentes bases initiale. Dans un
premier temps, nous allons présenter la campagne d’évaluation des systèmes d’alignement.
Nous présenterons ensuite comment nous avons pu appliquer notre proposition au jeu
de données de cette campagne. Nous finirons cette section en présentant la stratégie
d’évaluation et les résultats obtenus par Muskca dans ce contexte.
2.1. Présentation de la tâche QA4OA de l’OAEI
Nous avons considéré la campagne d’évaluation de systèmes d’alignements OAEI
106.
Cette campagne propose, depuis 2005, une méthode pour évaluer les systèmes d’alignement
d’ontologies. Plusieurs tâches permettent de tester plusieurs aspects d’un système
d’aligne-ment. Nous retrouvons par exemple des tâches spécialisées dans les systèmes d’alignements
multilingues (Multifarm) ou pour l’alignement d’individus (Instance Matching). Nous nous
sommes particulièrement intéressé à la tâche QA4OA (Question Answering for Ontology
Alignment - https://www.cs.ox.ac.uk/isg/projects/Optique/oaei/oa4qa/).
Cette tâche propose une nouvelle forme d’évaluation depuis 2014. Les autres tâches
proposant de comparer les correspondances générées par les systèmes avec des
corres-pondances de références (définies manuellement), celle-ci préfère passer par un système
d’interrogation. La tâche considère sept sources ou bases de connaissances et 18 requêtes
SPARQL chacune écrite pour au moins une des sept sources. Les organisateurs de la
tâche ont développé un système de reformulation de requêtes prenant en entrée une
requête SPARQL écrite pour une base de connaissances et un ensemble de
correspon-dances établies entre cette base et une deuxième (ces corresponcorrespon-dances étant générées par
les systèmes d’alignement concourant dans la tâche). Le système fournit en sortie une
nouvelle requête à exécuter sur la deuxième base, le contenu de cette requête ayant été
obtenu automatiquement à partir des correspondances fournies en entrée. Les résultats
retournés par chacune des requêtes sont ensuite comparés aux résultats de référence. Ces
résultats de référence sont obtenus en utilisant ce même système de reformulation, mais
en prenant cette fois-ci des correspondances de références générées manuellement.
Cette tâche permet de prendre en considération des correspondances qui ne seraient
pas identiques aux correspondances de référence, mais qui permettraient tout de même
d’obtenir des résultats équivalents par des requêtes.
Prenons par exemple la première requête SPARQL proposée dans la tâche :
SELECT DISTINCT ?x
WHERE {
?x rdf:type [
a owl:Class;
owl:unionOf (
confof:Trip
confof:Banquet
confof:Reception
)
] .
?x rdf:type owl:NamedIndividual.
}
Cette requête propose de récupérer tous les individus de type "Trip", "Banquet" ou
"Reception" de la base de connaissances "confof".
Considérons qu’un système d’alignement établit la correspondance suivante entre la
base "confof et la base "ekaw".
(au format RDF Alignment
107) :
<map>
<Cell>
<entity1 rdf:resource="http://confOf#Banquet"/>
<entity2 rdf:resource="http://ekaw#Conference_Banquet"/>
<measure rdf:datatype="xsd:float">1.0</measure>
107. http://alignapi.gforge.inria.fr/format.html
<relation>=</relation>
</Cell>
</map>
La requête réécrite pour être adaptée à la source "ekaw" sera alors :
SELECT DISTINCT ?x
WHERE {
?x rdf:type [
a owl:Class;
owl:unionOf (
confof:Trip
ekaw:Conference_Banquet
confof:Reception
)
] .
?x rdf:type owl:NamedIndividual.
}
Afin d’évaluer les résultats obtenus pour un système d’alignement, la campagne propose
d’interroger chaque couple de sources en exploitant les alignements entre ces deux sources.
Le résultat de la requête obtenu en utilisant les correspondances de référence sont
comparés aux résultats obtenus avec les correspondances générées. Un calcul de précision,
rappel et f-mesure est effectué pour chaque couple de source et pour chaque requête.
Il est possible d’accéder aux résultats des systèmes d’alignement ayant participé à
cette tâche en 2014 à l’adresse suivante : https://www.cs.ox.ac.uk/isg/projects/
Optique/oaei/oa4qa/2014/results.html. Nous pouvons remarquer que LogMap (qui
est le système que nous utilisons dans Muskca) est celui qui a obtenu les meilleurs
résultats.
