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

LE Web des données étend le Web en associant à une adresse Web unique (un URI) un document RDF (Resource Description Framework) [37]. Par exemple, l’URI http://f r.dbpedia.org/page/La_Naissance_de_Vénus_(Botticelli) renvoie un document RDF décrivant le tableau «La naissance de Vénus» selon DBpedia. Ce document RDF contient un ensemble de faits décrivant ce tableau. Un fait est représenté sous forme d’un triplet : ﹤ sujet, prédicat, objet ﹥.

Sujet : http://fr.dbpedia.org/page/La_Naissance_de_Vénus_(Botticelli)
Prédicat : http://dbpedia.org/ontology/author
Objet : http://fr.dbpedia.org/page/Sandro_Botticelli

Le fait ci-dessus établit donc que le tableau «La Naissance de Venus» a été peint par Sandro Botticelli. En déréférençant http://fr.dbpedia.org/page/Sandro_Botticelli, on obtient un document RDF décrivant le peintre Sandro Botticelli selon DBpedia. En déréférençant http://dbpedia.org/ontology/author, on obtient la définition du prédicat «author» elle-même exprimée en RDF. À l’image du Web classique, le Web des données est donc navigable. Il peut être exploré aussi bien par un humain que par une machine. Le Web des données est un multi-graphe orienté et étiqueté, distribué à travers un grand nombre de serveurs Web indépendants et autonomes. Chaque triplet correspond à un arc orienté où le label est le prédicat, le sujet est le nœud source et l’objet le nœud cible.

Les données en bleu sont extraites de DBpediaFr et les données en vert sont extraites de Geonames. DBpedia nous apprend que «La Naissance de Venus» est exposée dans la galerie des offices à Florence. Elle nous apprend également que «Florence» est aussi définie sur Geonames avec comme identifiant geodata:317659. Ainsi, en naviguant de DBpedia à Geonames, il est possible de découvrir les coordonnées GPS de Florence.

PREFIX dpedia−owl: <http://dbpedia.org/ontology/museum>
PREFIX dbpedia−fr: <http://fr.dbpedia.org/resource/>
PREFIX prop−fr: <http://fr.dbpedia.org/property/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX geodata: <http://sws.geonames.org/>

dbpedia−fr:La_Naissance_de_Vénus_(Botticelli) prop−fr:titre « La Naissance de Vénus @fr » .
dbpedia−fr:La_Naissance_de_Vénus_(Botticelli) dbpedia−owl:museum dbpedia− fr:Galerie_des_Offices .
dbpedia−fr:La_Naissance_de_Vénus_(Botticelli) dbpedia−owl:author dbpedia− fr:Sandro_Botticelli.
dbpedia−fr:Galerie_des_Offices dbpedia−owl:architect dbpedia−fr: Giorgo_Vasari .
dbpedia−fr:Galerie_des_Offices prop−fr:commune dbpedia−fr:Florence .
dbpedia−fr:Sandro_Botticelli prop−fr:nom « Sandro Botticelli @fr » .
dbpedia−fr:Sandro_Botticelli dbpedia−owl:birthDate « 1444_03_01+02:00 (xsd :date) ».

L’ensemble de ce graphe au format N-triples est décrit dans le listing 1.1. L’association entre Florence et les données de GeoNames est réalisée sur le site DBpedia avec le fait : dbpedia-fr:Florence owl:sameAs geodata:317659. En suivant les principes des données liées [10], les producteurs de données ont mis à disposition des milliards de triples sur le Web, nombre en constante augmentation [51]. Les principes ont été énoncés par Tim Berners-Lee de la manière suivante :
• Utiliser des URIs pour nommer les «choses».
• Utiliser des URIs HTTP pour que les personnes puissent les consulter.
• Les URIs fournissent des informations utiles en suivant les standards du Web (RDF, SPARQL).
• Inclure des liens vers d’autres URIs, pour découvrir d’autres «choses».

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 efectuer 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.

Approche

Dans cette thèse, nous nous concentrons sur l’approche «médiateur». Les médiateurs [65] sont définis dans le cadre des bases de données fédérées [54] et plus particulièrement des moteurs de requêtes fédérées [1, 53]. Dans notre contexte, un médiateur permet d’exécuter des requêtes SPARQL sur un ensemble de serveurs hébergeant des données RDF et offrant tous la même interface : SPARQL ou un sous-ensemble de SPARQL. La requête n’est donc pas exécutée sur l’ensemble du Web des données mais sur un sous-ensemble déclaré par l’utilisateur final et envers lequel il a confiance. Ces moteurs s’exécutent sur les machines des utilisateurs finaux ou d’intermédiaires à travers des portails. Dans cette approche «médiateur», on considère que l’hétérogénéité sémantique entre les différentes sources est suffisamment faible pour ne pas recourir à des méthodes d’alignement et de réécriture de requêtes [20]. Aujourd’hui, un médiateur est devenu si compact qu’il peut fonctionner au sein d’un navigateur Web [63]. Il est donc tout à fait possible d’avoir, à un moment donné, des milliers de médiateurs exécutant des requêtes SPARQL sur les mêmes sources de données. Si les sources de données se retrouvent surchargées, alors les données ne seront plus disponibles. Il existe un compromis entre performances des requêtes et disponibilité des données [63]. Suivant les opérations exécutées au sein des médiateurs et celles déléguées aux sources de données, on obtient des solutions qui ménagent les serveurs mais dégradent les performances ou des solutions qui améliorent les performances mais limitent la disponibilité des données. Cependant, ce compromis entre performance et disponibilité est établi avec l’hypothèse qu’un médiateur ne communique pas avec un autre. Dans cette thèse, nous nous posons la question suivante : Si les médiateurs collaborent en partageant leurs ressources en : espace disque, capacité de calcul et bande passante ; est-il possible d’obtenir un meilleur compromis entre performances et disponibilité des données ?

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

Télécharger le rapport complet