Collaboration dans une fédération de consommateurs de données liées

Interroger le Web des données

Le langage SPARQL (Simple Protocol And RDF Query Language) [48] permet d’interroger des données RDF.
PREFIX dcterms: <http://purl.org/dc/terms/>
SELECT ?titre
WHERE {
?oeuvre dcterms:subject <http://fr.dbpedia.org/resource/Catégorie:
Œuvre_conservée_à_la_Galerie_des_Offices> .
?oeuvre prop−fr:titre ?titre .
?oeuvre dbpedia−owl:author dbpedia−fr:Sandro_Botticelli
}
La requête SPARQL du listing 1.2 retourne les œuvres de Sandro Botticelli qui sont conservées à la Galerie des Oces. Si on exécute cette requête sur le serveur SPARQL disponible à l’adresse suivante : http://fr.dbpedia.org/sparql, cette requête retourne les résultats suivants :
« Pallas et le Centaure »@fr
« La Vierge à la grenade »@fr
« Portrait d’homme avec médaille de Cosme l’ancien »@fr
« La Naissance de Vénus »@fr
« La Calomnie d’Apelle »@fr
« Le Printemps »@fr
« L’Adoration des mages »@fr
« L’Annonciation du Cestello »@fr
« La Madone du Magnificat »@fr
« La Découverte du cadavre d’Holopherne »@fr
« Le Retour de Judith à Béthulie »@fr
« Botticelli 1444/45−1510″@fr
« Botticelli, in I protagonisti dell’arte italiana »@fr
« Botticelli. De Laurent le Magnifique à Savonarole »@fr
« Saint Augustin dans son cabinet de travail »@fr
« La Force »@fr
« La Vierge de la loggia »@fr
« La Vierge et l’Enfant dans une gloire de séraphins »@fr
« La Vierge à la roseraie »@fr
« Retable de Saint−Ambroise »@fr
« Le retable de San Marco »@fr
« ou Couronnement de la Vierge »@fr
« L’Annonciation de San Martino alla Scala »@fr
Pour pouvoir exécuter cette requête, l’ensemble des faits RDF disponibles sur le site fr.dbpedia a été, au préalable, inséré dans une base de données RDF (Virtuoso dans ce cas) par les hébergeurs du site fr.dbepdia.org. Les résultats sont donc complets si l’on ne considère que les données de fr.dbpedia.org. Ils ne le sont peut-être pas si l’on doit considérer l’ensemble du Web des données. En fait, l’évaluation de requêtes SPARQL sur le Web des données pose plusieurs problèmes complexes : Localisation des données Le premier est de définir un périmètre sur lequel exécuter les requêtes. Le périmètre est l’ensemble des sites Web à considérer pour évaluer une requête. Faut-il prendre le Web des données dans son ensemble ou juste considérer un sous-ensemble des données ; par exemple : données bio-médicales, données gouvernementales, etc. Performances et passage à l’échelle Sur le Web des données, le volume des données ainsi que le nombre de requêtes par seconde peuvent être très élevé. De plus, SPARQL est un langage de requête très expressif dont l’évaluation peut être coûteuse. Enfin, les données sont naturellement distribuées et partitionnées par site Web. Selon les infrastructures considérées pour évaluer les requêtes, il va exister un compromis entre performances et passage à l’échelle/disponibilité des données. Ce compromis existe également sur le coût financier de l’évaluation des requêtes. L’évaluation est-elle exclusivement à la charge des producteurs de données ? Ou des consommateurs de données ? Et/ou d’éventuels médiateurs entre producteurs de données et consommateurs de données ? Hétérogénéité sémantique Si le Web des données est homogène dans les formats utilisés pour représenter les données, il est hétérogène d’un point de vue sémantique. En effet, le Web des données ne définit pas un schéma strict permettant d’écrire une requête. Rien ne dit qu’une personne sera décrite en RDF de la même manière par un site et par un autre. Dans ce contexte, comment faire pour écrire une requête ? Confiance Selon les sources sélectionnées pour effectuer la requête, un utilisateur peut avoir plus ou moins confiance envers telle ou telle source. Si l’utilisateur ne peut pas choisir les sources sur lesquelles il effectue ses requêtes, peut-il alors faire confiance aux résultats retournés ? Usage Selon que les données sont répliquées ou non, un producteur de données voit ou pas les requêtes effectuées sur ses données. Si l’utilisateur interroge les données originales, c’est-à-dire sur le serveur de celui qui a autorité sur les données, le producteur de données peut savoir comment sont utilisées ses données. Fraîcheur et cohérence des données Il est important que lorsque l’utilisateur effectue ses requêtes les données soient à jour et cohérentes avec les données originales, s’il s’agit de copies. Dans une certaine mesure ces problèmes sont liés. On peut en effet considérer que plus le périmètre d’une requête est grand, plus l’hétérogénéité sémantique est grande et plus les problèmes de passage à l’échelle sont importants. Il existe plusieurs approches pour pouvoir interroger en SPARQL le Web des données : entrepôt de données, indexes centralisés, médiateurs, gestion de données sur réseaux pair-à-pair. Ces différentes approches offrent différents compromis entre périmètre de la requête, performances, passage à l’échelle, hétérogénéité sémantique, confiance, usage, fraîcheur et cohérence des données.

Impact de la taille du jeu de données sur le cache décentralisé

La taille du jeu de données peut impacter les performances du cache décentralisé, car un jeu de données plus conséquent augmente la diversité du cache temporel.
Objectif : Est-ce que le nombre de triplets d’un jeu de données peut dégrader les performances du cache décentralisé ?
Description : Pour cette expérimentation, trois jeux de données sont utilisés, BSBM avec 1M de triplets, BSBM avec 10M de triplets et BSBM avec 100M de triplets. Un cache local de 1000 entrées, un profil de taille 10 et 10 clients TPF. Comme dans l’expérience précédente, les vues sont fixées à V ueRP S = 4 et V ueCON = 9.
Résultats : La figure 3.4 montre le pourcentage d’appels résolus par le cache local, le cache des voisins et le serveur TPF avec les différents jeux de données. Les appels dans le cache local dépendent considérablement de la taille du jeux de données, le cache hit est de 47% avec le jeux de données BSBM 1M et descend à 4% avec BSBM 100M. De même, les appels au cache décentralisé sont liés à la taille du jeu de données, avec un cache hit autour de 19% pour BSBM 1M et 10M et une descente à 9% pour BSBM 100M.
Explication : La différence du pourcentage de réutilisation du cache local entre BSBM 1M et BSBM 100M est due à la taille limitée du cache. Le nombre de triplets dans le jeu de données augmente, mais pas la taille du cache local des clients. De plus, les localités temporelles du cache réduisent l’utilité du cache décentralisé. Cette explication est également valable pour le cache décentralisé dont l’utilité est réduite entre BSBM 10M et BSBM 100M.

Impact de la taille du profil sur les communautés du réseau superposé communautaire

Un client établit si un autre client est similaire à lui grâce aux profils. Les clients similaires forment ainsi des communautés.
Objectif : Est-ce que la précision du profil impacte la définition des communautés ?
Description : Comme dans les expériences précédentes, nous mettons en place deux jeux de données BSBM 1M avec 50 clients par jeu de données. Nous varions la taille des profils à 5, 10 et 30 prédicats.
Résultats : Dans la figure 3.8, le graphe connecté représente le réseau superposé communautaire, où un nœud représente un client dans le réseau et les arcs représentent une connexion entre deux clients. Par exemple, l’arc 1 → 2 signifie que le client 1 a le client 2 dans sa vue CON. La figure 3.8 montre clairement que CyCLaDEs est capable de construire deux communautés pour les deux valeurs de la taille du profil.
Explication : Comme on peut le voir dans la figure 3.8b, un profil avec une taille plus grande améliore la définition des communautés, c’est-à-dire que seuls les clients avec des profils similaires reçoivent des demandes pour récupérer des fragments.

Analyse de coût de CyCLaDEs

Dans CyCLaDEs, nous nous sommes focalisés sur l’ecacité du cache collaboratif. Nous n’avons pas mesuré l’impact en terme de temps d’exécution des requêtes. La latence du cache collaboratif est : 2×l, où l est la latence du voisin le plus rapide, la première fois pour envoyer la requête et la deuxième fois pour recevoir la réponse. Le temps d’exécution des requêtes est dégradé si les serveurs sont peu chargés. Si la charge des serveurs augmente, alors la meilleure disponibilité des données doit compenser le surcoût d’accès au cache collaboratif. Mesurer dans quelles conditions les temps d’exécution des requêtes s’améliorent avec un cache collaboratif est une perspective intéressante. CyCLaDEs ne tient pas compte des latences réseaux entre les médiateurs et entre les médiateurs et les sources de données. Intégrer les latences réseaux dans le profil d’un médiateur doit permettre d’obtenir un meilleur voisinage.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

1 Introduction
1.1 Interroger le Web des données
1.2 Approche
1.3 Contributions
1.4 Plan du manuscrit
1.5 Publications
2 État de l’art
2.1 Index centralisé
2.2 Parcours des liens
2.3 Serveurs SPARQL avec autorité
2.4 Serveurs SPARQL sans autorité
2.5 Requêtes sur réseaux pair-à-pair
2.5.1 Edutella
2.5.2 RDFPeers
2.5.3 Piazza
2.6 Approche médiateurs et fédération de données
2.6.1 Médiateurs et bases de données fédérées
2.6.2 Moteurs de requêtes fédérées et serveurs SPARQL
2.6.3 Triple Pattern Fragment (TPF)
2.7 Synthèse et positionnement de l’approche
3 CyCLaDEs : un cache collaboratif décentralisé pour les fragments de triplet
3.1 État de l’art
3.2 Motivation et approche de CyCLaDEs
3.3 Modèle de CyCLaDEs
3.3.1 Réseau d’échantillonnage aléatoire des pairs (RPS)
3.3.2 Profil des clients TPF
3.3.3 Réseau communautaire et mesure de similarité
3.4 Étude expérimentale
3.4.1 Environnement d’expérimentation
3.4.2 Résultats
3.5 Conclusion
4 Ladda : délégation de requêtes dans une fédération de consommateurs de données liées
4.1 Contexte et Motivation
4.2 Définitions et énoncé du problème
4.3 Approche de Ladda
4.3.1 Limites de parallélisation
4.3.2 Est-ce que la localité est importante ?
4.3.3 Algorithmes
4.3.4 Coût de Ladda
4.4 Étude expérimentale
4.4.1 Environnement d’expérimentation
4.4.2 Résultats
4.5 État de l’art
4.6 Conclusion
5 Conclusion
5.1 Résumé des contributions
5.1.1 Cache collaboratif décentralisé
5.1.2 Délégation de requêtes
5.2 Perspectives
5.2.1 Analyse de coût de CyCLaDEs
5.2.2 Délégation de requêtes en environnement réel
5.2.3 Combiner le cache collaboratif décentralisé et la délégation de requête
5.2.4 Matérialisation de fragment
A Résultats d’expérimentation complémentaires de Ladda
A.1 Nombre de requêtes exécutées par minute
A.2 Distribution des requêtes déléguées
A.3 Temps local d’exécution