Adaptation des fonctions de calculs

Nous avons vu comment nous adaptons les requêtes pour qu’elles permettent d’inter-roger notre base de connaissances finale. Nous avons ensuite présenté l’adaptation du jeu de données de référence pour qu’il permette la considération de toutes les sources simultanément. Nous allons présenter maintenant les fonctions de calculs que nous avons utilisées pour calculer la précision et le rappel sur ces requêtes adaptées et en fonction du jeu de données de référence adapté.

La précision permet d’évaluer la pertinence des résultats à partir du ratio entre le nombre d’éléments générés par le système qui sont aussi présents dans le jeu de données de référence et le nombre d’éléments dans le résultat. Nous étendons ce calcul de la précision en ajoutant une considération de la redondance des résultats. Chaque candidat retourné par la requête adaptée à Muskca est composé de plusieurs éléments ontologiques. Lors de l’extraction de ces éléments ontologiques pour obtenir la liste des URI à comparer avec le jeu de données de référence, il est possible qu’il y ait des URI redondantes. En effet, des éléments ontologiques peuvent apparaître dans plusieurs candidats (dans le cas d’incompatibilités). Afin de prendre en compte cette redondance dans le calcul de la précision, nous considérons le ratio entre les URI distinctes du résultat présents dans le jeu de données de référence sur le nombre total d’URI du résultat. De cette manière, si un élément ontologique est présent dans plusieurs candidats, il ne sera comptabilisé qu’une seule fois au numérateur mais plusieurs fois au dénominateur.

Le rappel et la f-mesure sont calculés de façon standard.

L’ensemble du processus d’expérimentation est schématisé dans la figure 56.

2.4. Résultats

Le tableau29présente les résultats obtenus avec les différentes requêtes de la campagne d’évaluation QA4OA. Nous pouvons observer sur ce tableau que la plupart des requêtes ont des scores très elevés. Ceci s’explique par le fait que nous avons réutilisé les requêtes de la campagne pour générer notre module et que nous avons ensuite effectué des alignements manuellement entre ce module et les sources considérées. Il est donc normal que nous obtenions des résultats aussi élevés. Néanmoins, nous pouvons aussi observer qu’en utilisant une source intermédiaire (ici la partie haute du module ontologique) et un alignement manuel uniquement sur cette source, nous obtenons de très bons résultats. Cet aspect est particulièrement intéressant pour une application comme le Web de données liées qui se développe rapidement au fil des années. Ce Web de données liées encourage la réutilisation de vocabulaires pour définir de nombreuses données factuelles. L’ontologie

Figure 56 – Stratégie d’expérimentation de Muskca sur la campagne d’évaluation QA4OA

Requête Précision Rappel F-Mesure qa1 0,99 1 0,99 qa2 1 0,33 0,5 qa3 0,04 1 0,08 qa4 1 1 1 qa5 1 0,99 0,99 qb1 1 1 1 qb2 1 1 1 qb3 0,08 1 0,16 qb4 1 1 1 qb5 1 1 1 qb6 0,5 1 1 qv1 0,75 0,99 0,85 qv2 1 0,99 0,99 qv3 1 1 1 qv4 1 1 1 qv5 1 0,99 0,99 qv6 1 0,99 0,99 qv7 1 0,99 0,99

Table 29 – Résultats de l’évaluation de Muskca sur la campagne d’évaluation QA4OA

Foaf est par exemple largement utilisée sur le Web de données liées. Il est donc de plus en plus courant de trouver sur le Web de données liées des sources ayant des vocabulaires (ou ontologies) similaires mais des données factuelles différentes.

Un second fait notable sur ce tableau réside dans les résultats des requêtes qa3 et qb3 qui ont des précisions particulièrement basses bien que les rappels soient à 1. En observant les résultats, nous avons pu remarquer que cette précision basse est en grande partie due à la redondance des URI récupérées. En d’autres termes, les candidats récupérés par la requête qa3 et qb3 partagent un grand nombre d’éléments ontologiques. Ces deux requêtes permettent de récupérer des "Reviews", l’une par son type (qb3) et l’autre par la relation "reviewWrittenBy" (qa3). Comme pour les autres éléments ontologiques des différentes sources, les reviews n’ont pas de labels définis dans les sources. De plus, les fragments d’URI que nous avons utilisés pour générer des labels sont de type "review1", "review2", etc. De ce fait, le système d’alignement génère beaucoup de correspondances erronées, ce qui implique la génération de beaucoup de candidats qui partagent des éléments ontologiques. Si nous observons les résultats pour ces deux requêtes en utilisant des seuils pour filtrer les candidats, nous obtenons les résultats présentés dans le tableau30.

Ce tableau permet d’observer que la précision augmente significativement lorsque nous filtrons les candidats. La requête qa3 utilise la relation "reviewWrittenBy" pour récupérer l’ensemble des Reviews des sources. Dans certaines sources, cette relation n’est pas définie aussi précisément. L’auteur d’une Review est représenté par une relation du

qa3 qb3

Seuils Précision Rappel F-Mesure Précision Rappel F-Mesure

0,05 0,04 0,95 0,08 0,08 0,97 0,15 0,1 0,04 0,95 0,08 0,08 0,97 0,15 0,15 0,15 0,88 0,26 0,29 0,84 0,43 0,2 0,33 0,19 0,24 0,6 0,17 0,27 0,25 0,5 0,015 0,02 1 0,015 0,03 0,3 0 0 0 0 0 0

Table 30 – Résultats pour les requêtes qa3 et qb3 avec seuils de filtrage

type "hasAuthor" qui est plus générique et qui peut être aussi utilisée pour représenter l’auteur d’un article. De ce fait, l’ensemble des résultats récupérés par la requête qa3 ne sont pas bons en raison de cette ambiguïté dans certaines sources, ce qui explique qu’avec un seuil de 0,25, la précision n’est que de 0,5 alors qu’elle est de 1 pour la requête qb3. Cette requête qb3, quant à elle, ne contient aucun mauvais résultat, même sans filtrage des candidats. La précision basse est uniquement due aux doublons présents dans le partage des éléments ontologiques entre candidats, comme nous l’avons expliqué précédemment. L’utilisation des incompatibilités entre candidats peut ici permettre une augmentation significative de la précision pour ces deux requêtes.

Nous pouvons aussi remarquer qu’avec un seuil à 0,3, il n’y a plus aucun résultat pour aucune des deux requêtes. Ce phénomène est observable pour toutes les autres requêtes dès le seuil est à 0,05. Cette absence de résultat peut s’expliquer par le fait que les sources ne partagent que très peu, voire pas du tout, d’éléments.