Dans ce chapitre nous avons présenté le protocole CorDis qui permet de réduire l’hétérogénéité sémantique liée aux disparités entre pairs. Ce travail a été présenté à la conférence Globe en 2011 [CCL11a]. Nous avons aussi proposé un certain nombre de stratégies que peuvent utiliser les pairs dans le cas où ils apprennent une nouvelle correspondance incohé-
0.75 0.8 0.85 0.9 0.95 1 0 100 200 300 400 500 600 700 HDispAPMoy Nombre de cycles 0% 0,27% 0,83% 8,33%
Figure 6.10 – Évolution de HDapAPMoy dans des systèmes dynamiques de 500 pairs
utilisant93 ontologies.
rente avec leurs ontologies. Cette partie a été acceptée dans la revue Tran- sactions on Large-Scale Data- and Knowledge-Centered Systems (TLDKS) en 2012 [CCL12c].
Dans l’article publié à Globe 2011, nous avons utilisé un autre jeu de données : les ontologies et les alignements sont issus de la collection Onto- Farm [vSB+05]. Cette collection est utilisée dans la campagne d’évaluation de méthodes d’alignement d’ontologies OAEI (Ontology Alignment Eva- luation Initiative4). Elle contient seulement 15 ontologies. C’est pour cette
raison que nous avons considéré un autre ensemble d’ontologies pour confirmer les résultats obtenus. Nous ne présentons pas les résultats ob- tenu avec la collection OntoFarm car ils sont moins convaiquants (du fait du nombre d’ontologies) et les observations sont similaires.
La partie relative à la présence d’incohérence n’est pas réellement éva- luée puisque nous n’étudions pas et ne comparons pas les différentes stra- tégies proposées. Hormis le fait que ce type d’expérimentation est long à mettre en place, nous sommes confronté au problème lié au manque de données. En effet nous ne possédons pas d’ensemble de correspondances dont certaines sont correctes pour tous les pairs, certaines sont sources de conflit pour tous les pairs, et certaines sont correctes pour certains pairs et sources de conflit pour d’autres. Nous pourrions introduire ce type de correspondances dans l’ensemble que nous possédons déjà mais cela n’est pas trivial. En effet, dans quelle proportion doit-on introduire des cor- respondances “douteuses” ? Combien doivent impliquer des concepts qui sont contenus dans des correspondances correctes ?
Dans l’ensemble des expérimentations que nous avons menées, nous avons utilisé les mesures que nous avons définies dans le cha- pitre 5 (page 69). Elle nous permettent d’évaluer notre protocole indépen- damment d’un jeu de requêtes, et sans le comparer à d’autres méthodes. Il serait néanmoins intéressant de comparer notre approche à d’autres approches qui visent également à réduire l’hétérogénéité liée aux dis- parités entre pairs, mais à notre connaissance il n’existe pas de telles méthodes. Nous pourrions éventuellement comparer la version actuelle de CorDis avec une autre version utilisant un autre mode de dissémina-
tion des correspondances (par ex. inondation du système avec toutes les correspondances). Dans ce cas, nous verrions s’il est préférable d’utiliser un protocole épidémique pour disséminer les correspondances, ou s’il vaut mieux utiliser une autre approche. Cette étude fait partie de nos perspectives de travail.
Nous pensons qu’il serait également intéressant d’optimiser le proto- cole afin de réduire le volume de correspondances qui transitent sur le réseau. Il est sans doute envisageable de mettre en place un mécanisme permettant de ne pas envoyer plusieurs fois la même correspondance au même pair. Du point de vue de l’hétérogénéité, cela ne devrait pas être pénalisant. Il faut évidemment étudier quels sont les coûts d’un tel méca- nisme (par ex. les coûts liés au stockage et au maintient d’un historique), et quels sont les bénéfices.
Par ailleurs nous envisageons d’étudier le cas où certains pairs du sys- tème sont malveillants, c’est-à-dire qu’ils transmettent volontairement des correspondances erronées. Dans ce cas, nous envisageons de proposer un mécanisme permettant, de manière décentralisée, d’identifier de tels pairs et de faire en sorte de les exclure du système. Encore une fois des expé- rimentations devront être menées pour tester l’efficacité de ce mécanisme et également tester sa tolérance : c’est-à-dire déterminer jusqu’à quelle proportion de pairs malveillants il reste efficace.
7
l’hétérogénéité liée à la
topologie du système
D
ans ce chapitre nous présentons le protocole GoOD-TA qui a pour objectif de réduire l’hétérogénéité sémantique liée à la topologie du système. GoOD-TA ré-organise le système de manière à rapprocher les pairs proches sémantiquement, c’est-à-dire ceux qui utilisent une même ontologie, ou ceux pour lesquels il existe de nombreuses correspondances entre leurs ontologies. Nous proposons deux versions de ce protocole. La première est assez simple et a l’avantage de considérer peu de données : les coûts en espace de stockage et en trafic réseau sont faibles. La seconde version est plus complexe mais permet de gérer des cas d’hétérogénéité plus difficiles. Nous proposons des mécanismes permettant de gérer la dynamicité du système (c.-à-d. le fait que des pairs peuvent rejoindre ou quitter le système à tout moment), de gérer l’évolution des connaissances sémantiques des pairs : changement d’ontologie, évolution de leur ontolo- gies, découverte de nouvelles correspondances, et de réduire de manière importante le trafic réseau généré par le protocole. Nous avons mené des expérimentations pour vérifier que GoOD-TA permet effectivement de ré- duire de manière importante certaines facettes de l’hétérogénéité. Les ex- périmentations montrent également qu’il est efficace dans des systèmes dynamiques, et dans des systèmes dans lesquels les pairs peuvent être amenés à changer d’ontologie. Nous portons également une attention par- ticulière au volume de données qui transitent sur le réseau. Ces travaux ont été présentés à la conférence P2P Computing en 2012 [CCL12a].7.1 Problématique et objectifs
Dans ce chapitre, nous considérons le même contexte de travail que dans le chapitre précédent : différents pairs interagissent au sein d’un sys- tème P2P, et utilisent des ontologies (une chacun) pour représenter leurs données. Dans la section 5.3 (page 75), nous avons vu que l’hétérogénéité sémantique dépend en partie de l’organisation des pairs du système. Cette facette de l’hétérogénéité est un frein important à l’interopérabilité, et plus précisément à la recherche d’information. En effet, lorsqu’un pair émet une requête, il la transmet à un certain nombre de pairs du système. Ty- piquement, la requête est envoyée à ses voisins, qui eux-mêmes la trans- mettent à leurs voisins, etc. La requête est donc envoyée autour du pair initiateur dans un certain “rayon“ (aussi appelé TTL). Le voisinage d’un pair représente un ensemble d’interlocuteurs privilégiés. Il est donc cru- cial que celui-ci soit composé de pairs capables de traiter ses requêtes. Nous nous focalisons sur le fait qu’une requête peut être incomprise lors de la réception car les deux pairs (l’émetteur et le récepteur) n’utilisent pas la même ontologie. La présence de correspondances entre les ontologies des pairs peut permettre de traduire (au moins partiellement) les requêtes. Néanmoins il semble préférable que si des pairs utilisent la même ontolo- gie que l’émetteur, ceux-ci soient en position de la recevoir, c.-à-d. qu’ils se trouvent dans son voisinage. La problématique que nous abordons dans ce chapitre est la suivante : Comment réduire l’hétérogénéité sémantique liée à la topologie d’un système P2P non-structuré ?
Nous avons pour objectif de proposer une solution permettant de ré- duire l’hétérogénéité sémantique liée à la topologie en respectant un cer- tain nombre de contraintes :
– elle doit être adaptée à la dynamicité des systèmes P2P, c’est-à-dire qu’elle doit permettre aux pairs de rejoindre ou quitter le système ; – elle doit supporter l’évolution des connaissances sémantiques des
pairs : le fait qu’un pair change d’ontologie ou découvre de nou- velles correspondances doit être considéré ;
– elle ne doit pas générer un trafic réseau déraisonnable.
Pour répondre à la problématique formulée ci-dessus, nous proposons le protocole GoOD-TA1.
Ce chapitre est organisé comme suit. Dans la section 7.2 nous pré- sentons le protocole GoOD-TA qui intègre des mécanismes pour gérer la dynamicité des systèmes, l’évolution des connaissances sémantiques des pairs et pour limiter le trafic réseau. Ensuite, la section 7.3 présente une analyse théorique des coûts engendrés par GoOD-TA en termes de volume de stockage et de trafic réseau. Enfin la section 7.4 présente les résultats d’expérimentations menées avec un ensemble d’ontologies utilisées dans domaine biomédical.