2.2 Mise en place du cadre expérimental
2.2.1 Module ontologique pour la tâche QA4OA - OAEI
] . ?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.
2.2. Mise en place du cadre expérimental
Pour utiliser cette campagne d’évaluation avec notre méthodologie, nous avons besoin de définir plusieurs éléments. Il est nécessaire de proposer la partie haute d’un module ontologique permettant de définir les bornes du domaine et la modélisation souhaitée. Cette partie haute doit pouvoir couvrir les éléments qui sont interrogés dans les requêtes utilisées dans la campagne. Après avoir présenté cette partie haute d’un module ontolo-gique, nous présenterons la transformation des sept sources de la campagne en fonction de ce module pour obtenir les SKB associées. Enfin, nous présenterons le paramétrage de Muskca pour l’utiliser sur ce jeu de données ainsi que les résultats obtenus
2.2.1. Module ontologique pour la tâche QA4OA - OAEI
Pour construire la partie haute du module ontologique, nous avons utilisé les 18 requêtes de la campagne comme spécifications. Ces questions représentent les besoins de la base
Figure 55 – Partie haute du module ontologique pour la tâche QA4OA - OAEI
de connaissances finale sous la forme de questions auxquelles la base de connaissances devra répondre (Cf. section3 du chapitreI). La partie haute du module ontologique est présentée dans la figure55.
Nous n’avons pas représenté les propriétés sur ce schéma mais, d’après les requêtes considérées, uniquement deux sont nécessaires :
hasAuthor : Permet de spécifier qu’un article est écrit par un auteur
reviewWrittenBy : Permet de spécifier qu’une review a été écrite par une personne 2.2.2. Sources
Les sept sources proposées dans cette campagne concernent toutes le même domaine : les conférences. Chacune des sources répertorie les connaissances liées à une conférence ou un ensemble de conférences sur l’informatique.
Voici la liste des sept sources présentes dans la campagne : Cmt : http://msrcmt.research.microsoft.com/cmt ConfOf : http://www.conftool.net/ Edas : http://edas.info/ Ekaw : http://ekaw.vse.cz/ Iasted : http://iasted.com/conferences/2005/cancun/ms.htm Sigkdd : http://www.acm.org/sigs/sigkdd/kdd2006
Conference : Ontologie créee à la main et peuplée à partir de DBLP108
Nous n’avons pas besoin d’effectuer une transformation syntaxique puisque les sources sont déjà en RDF. Néanmoins, il est nécessaire d’effectuer une extraction et un change-ment de la modélisation pour que ces sources soient adaptées à la partie haute du module ontologique défini précédemment. Pour cela, nous avons défini un patron de transfor-mation générique pour toutes les sources. Celui-ci est disponible à l’adresse suivante :
https://github.com/Murloc6/OAEIConf2RKB. Cet algorithme, applicable aux bases de connaissances, prend un ensemble de correspondances entre la source et le module et extrait toutes les spécialisations de ces correspondances. En d’autres termes, seront extraits grâce à ce patron toutes les classes qui sont des spécialisations des classes mises en correspondance, tous les individus de ces classes, tous les labels associés aux classes et aux individus extraits et toutes les relations sélectionnées qui relient les individus extraits.
Le tableau27 présente la quantité d’éléments extraits de chaque source. Source Classes Individus Relations Labels
Cmt 31 1581 293 1612 ConfOf 17 960 96 977 Edas 16 1049 69 1065 Ekaw 46 1157 108 1202 Iasted 57 1445 290 1502 Sigkdd 21 1248 567 1269 Conference 24 1350 69 1374
Table 27 – Nombre d’éléments extraits des sources de la campagne QA4OA
Nous pouvons observer qu’il y a autant de labels dans chaque source que d’éléments ontologiques (classes + individus). Ceci s’explique par une action supplémentaire qui a été effectuée par le patron de transformation. Aucun label n’était défini a priori dans les sources de la campagne QA4OA. Comme les systèmes d’alignement utilisent ces labels pour faciliter l’alignement, nous avons récupéré le fragment d’URI de chaque élément ontologique que nous avons ajouté comme label de l’élément. Considérer ces labels nous permet depuis de pouvoir générer des candidats labels par notre approche.
Prenons par exemple l’URI d’un individu de type "Person" provenant de la source Ekaw :
http://xmlns.com/foaf/0.1#AnastasiaAnalyti
Nous retrouvons ici la base URI qui est : "xmlns.com/foaf/0.1#". Cette base permet de définir l’ontologie FOAF qui a été utilisée ici pour définir une personne. Le fragment d’URI de cette URI est : "AnastasiaAnalyti". Si nous appliquons notre extraction de terme fondée sur la syntaxe du "Camel Case" nous pouvons ajouter le label suivant :
Candidats sommets Candidats arcs
4818 18330
Individus Classes Labels Relations Types
4669 149 9461 2933 5936
Table 28 – Nombre de candidats générés QA4OA
"Anastasia Analyti". De cette manière, nous ajoutons un label pour chaque élément ontologique extrait des sources.
Nous pouvons également constater, à partir du tableau27, que les individus sont le type d’éléments le plus présent dans ces bases. Nous avons donc repris LogMap comme système d’alignement utilisé par notre approche. Afin d’analyser a priori les éléments partagés par les sources, nous avons analysé le nombre de correspondances établies par cet outil entre les différentes source. Nous avons constaté que peu de correspondances sont établies entre les individus des différentes sources alors que la quasi-totalité des classes sont alignées. C’est par exemple le cas entre les sources EKAW et Iasted dont LogMap n’a découvert que 297 correspondances entre individus et 36 correspondances entre classes. Si nous comparons ce nombre de correspondances par rapport au nombre d’éléments extraits des sources dans le tableau 27, le ratio d’individus communs entre les deux sources est très faible. Ceci met en évidence que sur ce jeu de données, peu d’individus sont partagés par les sources. Ceci s’explique par le fait que chaque source est consacrée à la représentations des données liées à des conférences différentes ou à la même conférence mais ayant eu lieu sur des années différentes. A priori, notre approche qui exploite les éléments communs des sources ne sera pas dans ce cadre-là testée sur un jeu de données idéal. En revanche, nous pensons que cette évaluation a un intérêt car à l’échelle du LOD, ce cas de figure est fréquent puisque les jeux de données publiés reposent sur des vocabulaires similaires mais qui ont chacun pour objectif de représenter des jeux de données spécifiques.