Resumé

Nous considérons la mise en place d'une base de données du Web sémantique, contenant à la fois
des données explicites encodées en triple RDF, et des données implicites, implicites dans la
sémantique RDF. Sur la base d'une charge de travail de requête, nous abordons le problème de la
sélection d'un ensemble de vues à matérialiser dans la base de données, en minimisant une
combinaison de traitement des requêtes, de stockage des vues et de coûts de maintenance des vues.
En partant d'une méthode de sélection de vues relationnelles existante, nous concevons de
nouveaux algorithmes pour recommander des ensembles de vues, et nous montrons qu'ils vont bien
au-delà des vues relationnelles existantes lorsqu'ils sont adaptés au contexte RDF. Pour tenir compte
des triples implicites dans les réponses aux requêtes, nous proposons un nouvel algorithme de
reformulation des requêtes RDF et une manière innovante de l'incorporer dans la sélection des vues
afin d'éviter une explosion combinatoire dans la complexité du processus de sélection. L'intérêt de
nos techniques est démontré par une série d'expériences.

Introduction

Un ingrédient clé de la vision du web sémantique [4] est un format de données permettant de
décrire des éléments du monde réel et numérique d'une manière exploitable par les machines. Le
cadre de description des ressources du W3C (RDF, en bref [26]) est un candidat de premier plan pour
ce rôle. À première vue, l'interrogation de RDF ressemble à l'interrogation de données relationnelles.
En effet, au cœur du langage d'interrogation SPARQL du W3C pour RDF [27] se trouve l'interrogation
de type relationnel conjonctif. Il existe cependant plusieurs différences importantes dans le modèle
de données. Tout d'abord, un ensemble de données RDF est un grand ensemble de triples,
contrairement à la base de données relationnelle classique qui comporte de nombreuses relations
avec un nombre variable d'attributs. Deuxièmement, les triples RDF peuvent comporter des nœuds
vides, représentant des constantes inconnues ou des URI ; une base de données RDF peut, par
exemple, indiquer que l'auteur de X est Janvier, alors que la date de X est le 4/1/2011, pour une
ressource inconnue donnée X. Cela contraste avec les bases de données relationnelles standard où
toutes les valeurs des attributs sont soit des constantes soit des orles. Enfin, dans les bases de
données relationnelles classiques, toutes les données sont explicites, alors que la sémantique de la
RDF implique un ensemble de triplets implicites qui doivent être reflétés dans les réponses aux
requêtes. Une source importante de triples implicites découle de l'utilisation d'une RDF (facultative)

L'autorisation de faire des copies numériques ou papier de tout ou partie de cette œuvre pour un
usage personnel ou en classe est accordée sans frais à condition que les copies ne soient pas faites
ou distribuées dans un but lucratif ou à des fins commerciales et que les copies portent la présente
notice et la citation complète en première page. La copie à d'autres fins, la republication, l'affichage
sur des serveurs ou la redistribution sur des listes nécessitent une autorisation spécifique préalable
et/ou une redevance. Les articles de ce volume ont été invités à présenter leurs résultats lors de la
38e conférence internationale sur les très grandes bases de données, du 27 au 31 août 2012, à
Istanbul, en Turquie.

De plus, nous proposons une méthode innovante de reformulation (appelée post-reformulation) qui
nous permet de prendre en compte efficacement les triples implicites dans notre approche de
sélection des vues. Les stratégies existantes de sélection de vues relationnelles [21] se développent
hors de la mémoire et ne parviennent pas à produire une solution lorsque le nombre d'atomes dans
la charge de travail de la requête augmente. Étant donné que les atomes RDF sont courts (seulement
trois attributs), les requêtes RDF sont aresyntaxiquement plus complexes (elles ont plus d'atomes)
que les requêtes relationnelles qui récupèrent les mêmes informations, ce qui rend cette échelle
particulièrement problématique pour RDF. Nous proposons un ensemble de nouvelles stratégies et
hiérachémismes qui améliorent considérablement l'extensibilité de la recherche.4 Nous étudions
l'efficacité et l'efficience des algo-rithmes ci-dessus, et leur amélioration par rapport aux approches
similaires existantes, par le biais d'un ensemble d'expériences.5 Cet article est organisé comme suit.
La section 2 formalise le problème que nous examinons. La section 3 présente le prob-ème de
sélection des vues comme un problème de recherche dans un espace d'états candidats, tandis que la
section 4 traite de l'inclusion de triples FDR implicites dans notre approche d'ap. La section 5 décrit
les stratégies de recherche et les heuristiques utilisées pour naviguer dans l'espace de recherche. La
section 6 présente notre évaluation expérimentale. La section 7 traites des travaux connexes, puis
nous concluons

ÉNONCÉ DU PROBLÈME

Conformément à la spécification RDF [26], nous considérons une base de données RDF comme un
ensemble de (s, p, o) triples, où le sujet, le bien et l'objet sont représentés. Les triples RDF sont bien
formés, c'est-à-dire que les sujets peuvent être des URI ou des nœuds vides, les propriétés sont des
URI, tandis que les objets peuvent être des URI, des nœuds vides ou des littéraux (c'est-à-dire des
valeurs). Les nœuds vides sont des emplacements pour les inconnues (URI ou littéraux) ; du point de
vue de la base de données, ils peuvent être considérés comme des variables existentielles dans les
données. Alors que les tuples relationnels, y compris les tulltoken, couramment utilisés pour
représenter les informations manquantes, ne se joignent pas (les nulldoes ne satisfont aucun
prédicat), les triples RDF se référant au même nœud vierge peuvent être joints pour construire des
résultats complexes, comme illustré dans l'introduction. Pour exprimer les requêtes RDF (et les vues),
nous considérons les requêtes de base de SPARQL [27], représentées par des logarithmes, comme un
cas spécial de requêtes conjonctives : des conjonctions d'atomes, dont les termes sont soit des
variables libres (alias variables de tête), soit des variables existentielles, soit des constantes. Nous
n'utilisons pas de représentation spécifique pour les noeuds blancs dans les requêtes, bien que
SPARQL le fasse, car ils se comportent en fait comme des variables existentielles