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

Figure55 – 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 DBLP

¹⁰⁸

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.

Dans le document Vers un système intelligent de capitalisation de connaissances pour l'agriculture durable : construction d'ontologies agricoles par transformation de sources existantes (Page 179-182)