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 calcul trustchoquet.
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 standard105 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 maximum extmax. 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. |extmax| |extopti| 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 extopti. 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 OAEI106. 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 Alignment107) : <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.