efficacement un ensemble de bases RDF
Pierre Maillot
1,2, Thomas Raimbault
1, David Genest
2, Stéphane Loiseau
21. De Vinci Technology Lab, ESILV, Pôle Universitaire Léonard De Vinci 92916 Paris La Défense Cedex
{pierre.maillot,thomas.raimbault}@devinci.fr 2. LERIA, UFR Sciences, Université d’Angers
4 boulevard Lavoisier 49000 Angers {genest,loiseau}@info.univ-angers.fr
RÉSUMÉ.Dans le cadre duweb sémantique,nous proposons une approche de recherche d’in- formation basée sur une version compacte d’une base de triplets RDF, appeléeaperçu de re- cherche, agissant comme une vue d’ensemble de cette base. Les aperçus de recherche permettent d’écarter rapidement et de façon sûre une base du spectre des recherches si celle-ci ne contient pas d’éléments satisfaisant à une requête donnée. L’intérêt d’utiliser un aperçu est – d’un point de vue performance – qu’il n’est pas nécessaire d’interroger la base associée toute entière et – d’un point de vue pratique – que l’interrogation d’un aperçu passe par des moyens classiques SPARQL. Nous avons évalué notre approche sur des données RDF réelles, extraites de DBPe- dia, selon un jeu de requêtes choisies parmi celles couramment envoyées à DBPedia.
ABSTRACT.In the context of information retrieval in the Web of Data, we propose a kind of com- pact version of a RDF triplestore, that acts as an overview on this base of RDF triples. An overview is not only more compact that the initial triplestore, but also SPARQL can be used on it. An overview is built in such a way that if a SPARQL query on overview has no result, then there is no result too to this query into the initial triplestore. So, querying overviews is a more efficient solution than querying the whole triplestores when the query has often no result from these RDF databases. It is usually the case when a user query triplestores on the web of data.
Our solution has been evaluated using RDF bases extracted from DBPedia and queries extrac- ted either from the most common used on DBPedia or because of their resolution complexity.
MOTS-CLÉS :web sémantique, recherche d’information, résumé de données, indexation, triples- tores RDF, SPARQL, Big data, Linked Data.
KEYWORDS:semantic web, information retrieval, data summary, RDF indexation, SPARQL, Big Data, Linked Data.
DOI:10.3166/DN.17.2.9-32 © 2014 Lavoisier
1. Introduction
Le paradigme duweb sémantique (Berners-Leeet al., 2001) est de fournir un cadre commun pour le partage et la réutilisation de données à travers le web. Pour atteindre ce but, le contenu (i.e.les données) du web est accompagné de métadonnées offrant un ensemble d’informations structurelles permettant d’aider à traiter de manière au- tomatique ce contenu. Le caractère global, car distribué, des données nécessite une structuration beaucoup plus souple des données que dans des bases de données clas- siques relationnelles. Ainsi, le web sémantique propose des langages spécialement conçus, essentiellement RDF (Klyne, Carroll, 2004) pour la description des données, et RDFS (Brickley, Guha, 2004) ou OWL (Bechhofer, Sean et al., 2004) pour la défi- nition d’ontologies,i.e.pour la structuration des données RDF.
Le web sémantique actuel est – au sens duLinked Data1– constitué de milliers de triplestores2 inter-liés formant un vaste réseau de milliards detriplets RDF.Une grande problématique actuelle du web sémantique est de pouvoir rechercher de ma- nière pertinente de l’information dans ce « web des données3» structurées et réparties.
Si SPARQL (Prudhommeaux, Seaborne, 2008) est le langage et protocole standard du W3C4pour l’interrogation de données RDF, l’évaluation d’une requête SPARQL est connue pour être NP-difficile (Pérez et al., 2009). Face à cette problématique, des techniques en base de données et recherche d’information traditionnelles voir en recherche d’information sémantique (RIS) sont reprises, adaptées pourindexerouré- sumerles multiples sources du web sémantique.
Dans le domaine de l’indexation, un état de l’art récent de plusieurs catégories d’indexation est présenté dans (Umbrich et al., 2011). Les approches ditesInverted URI Indexingindexent toutes les URI apparaissant dans chaque source, pour ensuite pouvoir pointer vers les sources concernées lors d’une interrogation. Les approches Schema Level Indexingindexent les sources en fonctions des classes et prédicats qui y apparaissent (par plusieurs tables de hachage par exemple). Les approchesMulti- Dimensional HistogramouQTreereposent sur la transformation d’un triplet en co- ordonnées sur 3 dimensions par une fonction de hachage. Un espace de stockage est séparé en régions en 3 dimensions et dans chaque région une structure (histogramme ou arbre) stocke le nombre de triplets présents par source. Si les deux méthodes MDH et QT sont montrées comme étant plus efficaces pour les scénarios demandant une réponse rapide et non exhaustive, celles IUI et SLI sont plus indiquées pour des ré- ponses exhaustives et lorsque le nombre de sources et de données est grand.
Dans un autre contexte, l’approche de (Tranet al., 2010), qui étend le travail de (Vuet al., 2008), propose une indexation paramétrable au niveau des données ou au niveau du schéma. Les mots-clés d’une requête sont donc routés selon leur nature dans les sources (e.g.individus, relations ou types) vers ces sources indexées.
1. http://linkeddata.org/
2. On parle aussi de bases RDF, sources RDF ou simplement de documents RDF.
3. Autre nom du web sémantique (web of data) donné par son auteur lui-même, Tim Berners-Lee.
4. World Wide Web Consortium. http://www.w3.org/
Dans le domaine des résumés pour le web sémantique, (Zhanget al., 2007) propose une méthode de construction de résumés d’ontologies (sans individu) pour faciliter le parcours de l’ontologie par un utilisateur. Cette méthode est basée sur la génération de résumés textuels par le regroupement de triplets RDF en « phrases RDF ». L’approche de (Fokoueet al., 2006) permet de créer un résumé des assertions d’une Abox (don- nées) en fusionnant en un individu tous les individus de même classe selon la TBox (ontologie) associée. Ce résumé sert ensuite à vérifier la consistance d’une base.
Notre travail se situe à l’interaction de l’indexation et du résumé : il résume des tri- plestores en vue d’un requêtage rapide. Notre travail se positionne dans la génération originale de versions compactes de triplestores RDF, appelés aperçus de recherche ou simplementaperçus,offrant une certaine granularité quant au taux de compression en termes de nombre de triplets par rapport à la source associée. Ce travail étend et améliore celui présenté dans (Raimbault, Maillot, 2013), en permettant une réduction des littéraux.
Notre contribution sur les aperçus est double. D’une part, un aperçu d’une base RDF a pour objectif de permettre de déterminer rapidement si la base associée peut être pertinente ou non au regard d’une requête donnée : c’est une première passe. En effet, un aperçu est construit de façon à être capable d’écarterde façon sûreune base qui ne serait pas en rapport avec les éléments recherchés. Dans le cas contraire, il est nécessaire d’aller interroger, dans une seconde passe, la base réelle qui est alors sus- ceptible de fournir une réponse (cf.schéma de principe en figure 1). Un aperçu étant de taille (beaucoup) plus petite que la base associée, l’interrogation de celui-ci peut se faire localement et rapidement contrairement aux bases du Linked Data Cloud acces- sibles via le réseau. D’autre part, un aperçu (d’une base RDF) est un document RDF à part entière. Ainsi l’exploitation d’un aperçu peut passer par l’utilisation d’approches classiques de manipulation de documents RDF (e.g.SPARQL). Autrement dit, l’uti- lisation d’un aperçu pour déterminer si la base associée est pertinente ou non pour une requête donnée ne nécessite pas de passer par une méthode ad-hoc propre à un système d’interrogation comme on trouve dans l’état de l’art (e.g.table de hachage ou autre structure dédiée).
Figure 1. Schéma de principe : interrogation de l’aperçu en premier, puis si la base semble pertinente interrogation de celle-ci
Notons que ce travail est motivé par la disposition propre des données dans le web sémantique, où face à la multitude de bases (et sous-bases) de données RDF la réponse à une requête est généralement présente dans seulement quelques sources.
Ainsi, il est intéressant de pouvoir écarter rapidement les bases non pertinentes. De façon schématique, si par exemple une requête traite de « personnes qui conduisent des
voitures », les aperçus permettent d’écarter immédiatement et catégoriquement (i.e.
sans nécessité d’interroger les bases dans leur globalité) les sources qui ne traiteraient ni de personne, ni de voiture.
Cet article est organisé comme suit. La section 2 positionne le cadre du web sé- mantique, en termes de données factuelles RDF, d’éléments structurels RDFS et de l’environnement d’interrogation SPARQL. La section 3 présente notre travail de gé- nération et d’utilisation d’aperçus d’un point de vue théorique et fournit quelques exemples. La section 4 évalue en pratique notre démarche en l’exploitant au moyen de sources RDF issues de DBPedia à l’aide de requêtes choisies dans la littérature.
2. Web sémantique
Cette section est fournie pour les lecteurs ne connaissant ni RDFS, ni SPARQL.
Le web sémantique est un mouvement collaboratif mené par le W3C qui favorise des méthodes communes pour stocker, partager, trouver et combiner de l’information. Des langages spécialement conçus sont proposés : RDF pour la description des données, RDFS5ou OWL6pour la définition d’ontologies (i.e.vocabulaires destinés à structu- rer des ressources RDF), ou encore XML –eXtensible Markup Language– comme format de sérialisation (on parle par exemple de RDF/XML).
2.1. Modèle RDF
RDF –Resource Description Framework– (Klyne, Carroll, 2004) est un modèle de représentation destiné à décrire et structurer les ressources du Web de façon for- melle. Un document RDF est composé d’un ensemble de triplets, où chaque triplet s’exprime sous la forme de <sujet,prédicat,objet>. Le sujet représente la ressource à décrire, le prédicat représente une propriété (i.e.une relation) applicable à cette res- source, enfin l’objet représente une autre ressource ou un littéral7(i.e.une donnée) : c’est la valeur de la propriété. Le sujet, et l’objet dans le cas d’une ressource, sont iden- tifiés soit par une URI (i.e.identifiant unique) soit par unnœud blanc(i.e.ressource anonyme). Le prédicat est nécessairement identifié par une URI. Les littéraux consti- tuent les valeurs de typesprimitifs, tels que les nombres (entiers, réels), les chaînes de caractères (string), les dates,etc.
Notons qu’un document RDF peut-être vu comme un multigraphe labellisé décri- vant les ressources et leurs relations : les sujets et objets constituent les nœuds, les prédicats forment lesarcs. Par convention d’usage, les ressources sont représentées dans des cercles, les littéraux dans des rectangles.
Dans un souci de lisibilité, nous écrirons une URI selon un formatage composé d’un préfixe abrégé. Par exemple l’URI http://www.exemple.com/foo#bar peut être
5. RDFS et OWL eux-mêmes décrits en RDF.
6. OWL –Web Ontology Language– est un langage RDF d’ontologie plus expressif que RDFS.
7. Un littéral n’est donc pas une ressource et ne peut donc pas être en sujet d’un triplet.
écrite de manière plus compacte en ex:baren utilisant le préfixeex:signifiant http://
www.exemple.com/foo#. Concernant les nœuds blancs, ils peuvent être numérotés et préfixés par_: (i.e._:1,_:2, ...).
Un exemple de document RDF est présenté, sous sa forme de graphe, en figure 2.
Ce document est constitué de 9 triplets factuels, ici en noir sur fond blanc (<Bob,
soigne,Alice>, <Fred,parent,Alice>, <Fred,nom,« Dupont »>,etc.), qui relatent des liens entre médecins et patients, ainsi que certains liens d’affinité entre personnes. Les élé- ments en gris constituent les types des différentes ressources factuelles. Chaque indi- vidu est ici explicitement typé (via une relationrdf:typeà son type), ainsi que chaque littéral (où le type figure à côté de la valeur après le double caractère^^). La définition des types d’individus et des types de relations se fait en RDFS (cf.section suivante), généralement dans un document séparé. Les types primitifs des littéraux sont ici ceux du métamodèle XSD8des documents XML.
Figure 2. Document RDF typé selon l’ontologie RDFS en figure 3 et les types XSD
2.2. Métamodèle RDFS
RDFS –RDF Schema– (Brickley, Guha, 2004) fournit des éléments de base pour la définition d’ontologies destinées à structurer des ressources RDF. On parle de méta- données pour ces éléments structuraux.
RDFS permet donc (i) de déclarer des types de ressources appelésclasses(rdfs:- Class) et leurspropriétésbinaires (i.e.types de relations,rdf:Property) ; (ii) de préciser la signature des propriétés, c’est-à-dire le type en sujet (le domaine,rdfs:domain) et le type en objet (le co-domaine,rdfs:range) ; (iii) de spécifier les liens hiérarchiques entre classes et entre propriétés, via respectivement les relations transitivesrdfs:subClassOfet
rdfs:subPropertyOf(une classe peut hériter de plusieurs autres,idempour une propriété).
Les deux préfixesrdf:etrdfs:font respectivement référence au vocabulaire officiel du W3C des deux langages RDF et RDFS.
8. http://www.w3.org/XML/Schema.html
La figure 3 décrit et hiérarchise des classes et propriétés, ainsi que le sens des pro- priétés selon leurs domaine et co-domaine. Par exemple, la classe spécialiséeex:Pédia-
treest une sous-classe de la classe plus généraleex:Médecin, qui elle même est sous- classe deex:Personne. Ceci signifie qu’un individu de typeex:Pédiatresera aussi consi- déré comme une instance deex:Médecinet deex:Personne. La propriétéex:soignedécrit un type de relation, tel qu’une relation de ce type liera un individu de typeex:Médecin à un individu de typeex:Personne.
Figure 3. Classes et propriétés RDFS
2.3. Triplestores et interrogation SPARQL
Untriplestore– base de triplets – est un environnement spécialement conçu pour le stockage et la récupération de données RDF. Pour interroger les triplets RDF d’une base, SPARQL –Sparql Protocol and RDF Query Language– (Prudhommeaux, Sea- borne, 2008) est le langage actuel faisant consensus (i.e.principalement les requêtes de typesSELECTetASKcomme exploitées ici). Notons que les données d’un triplestore peuvent tout simplement être vues comme un seul (gros) document RDF.
D’un point de vue syntaxique, une requête SPARQL s’écrit à la manière d’une requête SQL, à la différence principale de l’absence en général de clauseFROM. En effet, il est théoriquement possible d’accéder à toutes les données du Web avec ce standard. Il n’est donc, toujours en théorie, pas nécessaire de préciser dans quelles sources (dans quels graphes, ou dans quelles tables, par analogie en SQL) chercher les données.
La Requête 1 est un exemple de requête SPARQL qui demande : « Qui est un médecin, et qui est son (ses) collègue(s) si cela est précisé ? ». Le mot-cléPREFIXper- met de définir des préfixes d’URI pour ensuite simplifier l’écriture de la requête. Le nom d’une variable commence par un point d’interrogation (?). La clauseSELECTpré- cise pour quelles variables il faut fournir les valeurs lors du résultat. La clauseWHERE
constitue la requête à proprement parler, sous la forme d’un ensemble de triplets dont il faut considérer leur conjonction. Un triplet se termine par un point (.), et chacune de ses composantes (sujet, prédicat et objet) est séparée d’un espace. La partieFILTER
(non illustrée ici) permet de contraindre finement les éléments recherchés. La partie
OPTIONALpermet de compléter la réponse si l’information est trouvée, mais cette in- formation n’est pas nécessaire pour constituer un résultat, contrairement aux éléments à la racine de la clauseWHERE.
Il existe aujourd’hui plusieurs moteurs SPARQL. Parmi eux9, Jena10est une plate- forme reconnue qui fournit une API Java pour manipuler (extraction, écriture, sto- ckage) des documents (graphes) RDF. Jena fournit aussi un moteur d’inférence à base de règles et un moteur d’interrogation SPARQL, prenant tous deux en compte la struc- ture RDFS (ou OWL) des documents RDF.
La dualité application de règles et interrogation de données est essentielle dans la mesure où toute une partie des informations implicites contenues dans les données sont généralement recherchées elles aussi. Par exemple, en considérant sur la figure 2 la personne identifiée parex:Fred, Jena déduira qu’il s’agit plus spécifiquement d’une instance de la classeex:Médecincar en partie gauche d’une relationex:collègue(collègue de l’individu ex:Bob) ; la propriété ex:collègue étant définie dans l’ontologie comme ayant pour domaine unex:Médecin.
Ainsi, le résultat de la Requête 1 sur les données en figure 2 produira le résultat indiqué en figure 4. On visualise queex:Fredfait bien partie des médecins, de même que les pédiatres (i.e.individus instances deex:Pédiatre) puisque la classeex:Pédiatre
est une sous-classe de ex:Médecin. On constate aussi que la partie optionnelle de la requête n’est pas renseignée lorsque l’information n’est pas présente (explicitement ou implicitement) dans la base et n’a donc pas été trouvée ici.
SELECT ?med ?col WHERE {
?med rdf:type ex:Médecin.
OPTIONAL {
?med ex:collègue ?col.
} }
---
| med | col |
======================
| ex:Marie | ex:Bob |
| ex:Bob | ex:Jean |
| ex:Jean | |
| ex:Fred | ex:Bob | ---
Requête 1 Résultat
Figure 4. Exemple de requête SPARQL et son résultat sur les données en figure 2
3. Aperçu d’une base de triplets RDF
L’idée pour générer des aperçus de recherche d’un document RDF est d’une part de fusionner des individus selon leur type et d’autre part de réduire le nombre de litté- raux en les remplaçant par des littéraux de substitution. La définition d’un aperçu est donnée en section 3.1. Un aperçu d’un document RDF est lui même un document RDF et une requête sur un aperçu d’une base retournant une réponse négative garantie que
9. http://www.w3.org/wiki/SparqlImplementations 10. http://jena.apache.org/
la requête aura également une réponse négative sur le document d’origine de l’aperçu.
Ceci est montré dans la section 3.2 qui porte sur les théorèmes. La partie 3.3 illustre notre démarche sur des exemples d’utilisation.
3.1. Définitions
DÉFINITION 1 (Document RDF explicitement et simplement typé (REST)). — Un document REST est un document RDF où (i) chaque individu est explicitement typé par une ou plusieurs classes RDFS ; (ii) l’ensemble des individus et leurs types sont disjoints ; (iii) chaque littéral est explicitement typé.
En d’autres termes, un document REST décrit des individus, des littéraux, leurs relations et leurs types ; de plus, un individu (i.e.instance d’une classe) ne peut pas être à son tour un type pour d’autres individus11(à l’exception bien sûr de la définition des classes et propriétés qui en RDF sontpar constructiondes instances derdfs:Class
etrdf:Property). La figure 2 est un exemple de document REST.
Notons que pour une ontologie RDFS12 la classe universelle, c’est à dire la plus générale de toutes, estrdfs:Resource. Ainsi, si un individu n’est pas explicitement typé, il peut l’être par cette classe universelle.
DÉFINITION 2 (Ligne de compression d’individus). — Soient C l’ensemble des classes d’une ontologie RDFS donnée, etLun sous-ensemble non vide deC.Lest appelée uneligne de compressiondeCsi :
– pour toute classec∈Cqui n’a pas de sous-classe, soitcest un élément deL, soit il existe une classec′plus générale quecqui est un élément deL;
– tous les éléments deLsont deux à deux hiérarchiquement incomparables (i.e. il n’y a pas deux classes liées par la relation transitiverdfs:subClassOf).
En d’autres termes, dans une ligne de compression toutes les classes de l’ontologie sont représentées une et une seule fois, de manière directe (la classe est un élément de L) ou indirecte (il existe une classe plus générale élément deL).
Une ligne de compression constituée de toutes les classes les plus spécialisées d’une ontologie (i.e.les classes n’ayant pas de sous-classe) est appelée ligne de com- pressionmaximale. Une ligne de compression constituée uniquement des classes les plus générales (e.g.le singletonrdfs:Resource) est appelée ligne de compressionmini- male.
Par exemple sur l’ontologie en figure 3, les trois seules lignes de compression pos- sibles sont : {ex:Personne}, {ex:Enfant,ex:Médecin} et {ex:Enfant,ex:Pédiatre,ex:Chirurgien} (cf.figure 5, la ligne de compression n°1 minimale, la ligne de compression n°2 et la ligne de compression n°3 maximale).
11. D’où le terme « simplement » de REST
12. En OWL,owl:Thingconstitue la classe universelle,rdfs:Literalla classe de littéral la plus générale.
Figure 5. Lignes de compression possibles de l’ontologie RDFS en figure 3
La ligne de compression détermine des ensembles de classes dont les individus sont fusionnés ensemble lors de la génération de l’aperçu. Ces individus sont ceux dont les types sont sur ou « en dessous » de la ligne de compression. Ces fusions ré- duisent fortement le nombre d’individus dans le document RDF tout en lui conservant certaines particularités (cf.section 3.2).
Dans un document RDF, les informations factuelles sont portées par les litté- raux (e.g. noms, dates, chiffres, etc) associés aux individus. Les littéraux sont ty- pés par des types dits primitifs, organisés dans une hiérarchie définie par la norme XSD (Biron, Malhotra, 2004). En OWL, on différencie les propriétés liant les indi- vidus entre eux (owl:ObjectProperty) et les propriétés liant les individus à des littéraux (owl:DatatypeProperty). Notons que les littéraux d’un même type sont totalement com- parables entre eux.
DÉFINITION 3 (Ensemble des cardinalités de types de littéraux). — Soit T un en- semble des types de littéraux.
Un ensembleRdéfini surT ×Ntel que∀(t, n) ∈ R,∄(t, n′) ∈ Roùn 6= n′ est appeléensemble des cardinalités deT .
Un tel ensemble indique pour chaque type primitif le nombre de littéraux résultants dans l’aperçu.
DÉFINITION 4 (Fonction de substitution de littéraux de typet). — Soittun type de littéraux, soientPtun ensemble des littéraux de typetetPt⊆Ptun sous-ensemble dePt, et soitn∈Nle nombre de littéraux de substitution pour le typet.
La fonctionsnt(p) :Pt→Pttelle que :
– ∀p, p′∈Pt, sip < p′alorssnt(p)≤snt(p′);
– si0 < n < |Pt|alors|Pt| =net∀p∈ Pt,∃p∈ Pttel quesnt(p) = p(i.e.
propriété surjective);
– sinonsnt(p) =p(i.e. propriété identique).
est appeléefonction de substitution de littéraux de typet.
Cette fonctionsnt remplace tous les littéraux de typetparnlittéraux de substitu- tion de telle façon que les inégalités partielles sont conservées entre les littéraux de substitution. Par exemple pour les littérauxe,metwde typestring, selon une fonc- tions2string, l’image deeetmseraitaet l’image dewseraitp(où on aa < pde même quee<wetm<w). Dans un exemple plus concret, dans un document traitant
de l’histoire de France qui détaillerait particulièrement les guerres napoléoniennes, la fonction de substitution pourrait regrouper toutes les dates des guerres napoléoniennes dans plusieurs groupes afin de garder une certaine finesse dans les détails et répartir les autres dates dans seulement quelques groupes. Ainsi, la définition d’une fonction de substitution permet d’adapter la granularité de la réduction de littéraux pour un type particulier, voire sur une plage de valeurs données. D’autres exemples de fonctions de substitution pourraient être le remplacement des chaînes de caractères par leur pre- mière lettre, les dates par leur année ou les chiffres par le multiple de 100 inférieur le plus proche.
DÉFINITION 5 (Aperçu de recherche). — Soient D un document REST défini sur une ontologie RDFSO donnée,Lune ligne de compression d’individus deO,Run ensemble des cardinalités des types de littéraux deD, et un ensembleS de fonctions de substitutionsntiidéfinies pour tout(ti, ni)∈R.
Unaperçu de recherchedeDselonL,R etS est défini par dérivation deDen appliquant les règles ci-dessous , lesrègles de réduction, appliquées jusqu’à réduction maximale (i.e. jusqu’à ce qu’aucune règle ne puisse plus être appliquée) :
r1 spécialiser un individu typé plus généralement qu’un élément deL(i.e. un in- dividuide typet1, oùt1est une classe plus générale qu’un élémentt2deL, alorsi devient (aussi) de typet2par ajout d’un triplet de prédicatrdf:typeentreiett2).
r2 fusionner deux individus distincts (*) ayant un même type.
r3 fusionner deux individus distincts (*) dont les types appartiennent àL(i.e. sit1 ett2sont respectivement les types des individusi1eti2tel quet1∈Lett2∈L).
r4 supprimer une relation redondante : dupliquée ou plus générale (i.e. supprimer les triplets contenant une relation entre deux nœuds13tel qu’il existe une autre relation de même type ou d’un type plus spécifique entre ces deux mêmes nœuds).
r5 supprimer un type plus général d’un individu (i.e. supprimer les triplets de pré- dicatrdf:typeentre l’individuiet la classet1, s’il existe une autre relationrdf:typeentre iet une classet2plus spécifique quet1)
r6 remplacer chaque littérallde typetpar son littéral de remplacementl′tel que si(t, n)∈Ralorsl′ =snt(l)sinonl′ =l.
(*) Deux individus distincts (i.e. d’URIs différentes, deux nœuds blancs différents, ou l’un possède une URI et l’autre est un nœud blanc) fusionnés signifie qu’ils sont remplacés par un même nœud blanc dans tous les triplets deD.
On appellera les règles r1 à r5 lesrègles de réduction d’individuet la règles r6 la règle de réduction de littéraux. On notera que la règle r6 peut également être appliquée une seule fois en phase d’initialisation.
13. Rappel : un nœud est soit un individu soit un littéral
3.2. Théorèmes
La construction selon la définition 5 d’un aperçu d’un document REST conduit immédiatement aux théorèmes suivants.
THÉORÈME6. —Un aperçu (d’un document REST) est un document REST.
Cette caractéristique, conservée par construction, présente un avantage majeur dans l’exploitation d’un aperçu en recherche d’information. En effet, la manipula- tion et plus particulièrement l’interrogation d’un aperçu peut passer par les approches RDF classiques, tels que le langage SPARQL et le moteur Jena.
THÉORÈME7. —La taille d’un aperçu d’un document REST est plus petite ou égale que la taille du document.
Nous désignons par taille d’un document (graphe) RDF – et donc d’un document REST – le nombre de ses triplets.
THÉORÈME8. — SoientDun document REST,V un aperçu deD, etQune requête SPARQL. SoitQ⋆la réécriture deQselon les étapes suivantes : (i) chaque URI d’in- dividu (donc ni URI de prédicat, ni URI de type) est remplacée par une variable qui lui est propre ; (ii) un filtre qui contient une variable non existante dans la clauseWHERE est supprimé ; (iii) un filtre qui contient un test d’inégalité stricte (i.e.>ou<) entre deux élément est respectivement remplacé par un test d’inégalité large>=ou<=. (iv) un filtre qui contient un test d’inégalité (i.e.! =) entre 2 éléments est supprimé ; (v) les clausesOPTIONALet « Solution Modifiers » sont enlevées ; (vi) les littéraux sont remplacés selon la même fonction de substitution que celle utilisée dansV.
Si l’interrogation par Q⋆ surV retourne comme résultat l’ensemble vide, alors le résultat de l’interrogation parQsurDest l’ensemble vide.
Notons que l’ensemble vide comme résultat à une interrogation signifie que le document (la base de données) RDF ne contient pas d’élément conforme à la requête.
Éléments de preuve :
– une variable peut correspondre (i.e.coïncider, matcher) à toute instance (nœud blanc ou individu identifié par une URI), hors considération du/des types ;
– une instance d’un typet2peut matcher avec une instance de typet1, oùt1est plus général quet2;
– les littéraux sont substitués de façon à ce que les inégalités larges entres littéraux soient conservées pour leurs substituts.
En d’autres termes, la requêteQ⋆est plus générale queQ.
Nous arrivons ici au cœur de l’article, où face à la multitude de bases RDF pré- sentes sur le web sémantique notre approche consiste d’abord à interroger les aperçus des bases pour en déterminer si une source est pertinente (i.e.écarter les bases qui ne peuvent contenir de réponses) avant de l’interroger concrètement et totalement (cf.
schéma de principe en figure 1).
Les «Solution Modifiers14 » (e.g.ORDER BY,LIMITouOFFSET) dans une requête SPARQL servent uniquement à la présentation des résultats. Ainsi, la réécriture deQ⋆ en épurant de Qses «Solution Modifiers » présente une optimisation simple quant au temps d’interrogation deQ⋆ au vue de l’usage que nous souhaitons faire d’une aperçu : savoir si la source est non pertinente selon la requête. De plus le nombre de résultats à une requêteQenvoyée à un document RDF, si il y en a, est très supérieur au nombre de résultats deQdans son aperçu, du fait de la réduction des individus, donc lesSolution Modifiersmodifiant le nombre de résultats à afficher (i.e.LIMITet
OFFSET) sont inutiles dansQ⋆.
LEMME9. — Soient D un document REST,V un aperçu deD, etQune requête SPARQL. Soit A⋆ la réécriture deQsuivant les mêmes étapes du Théorème 8 avec l’étape supplémentaire : (vii) la clauseSELECTest supprimée et le mot-cléWHEREest remplacé parASK. Si l’interrogation parA⋆surV est négative (retournefalse), alors le résultat de l’interrogation parQsurDest vide.
En SPARQL, une interrogation de typeASKa juste vocation à répondre partrue
oufalsesi il y a un résultat à l’interrogation ou non. Cette caractéristique coïncide exactement à l’utilisation que nous souhaitons faire d’un aperçu. Ainsi, le temps d’exé- cution pour obtenir une réponse en interrogation une base par une requêteASKest plus rapide que pour « la même » requêteSELECT.
Notons que certaines contraintes commeDISTINCTou encoreOPTIONALn’ont pas besoin d’être évaluées dans ce type de requête (ASK), ce qui induit un gain de temps supplémentaire (par rapport à une interrogation en « versionSELECT».
Le schéma global en figure 1 de fonctionnement de notre approche en recherche d’information peut donc être légèrement revu et optimisé en adoptant cette fois-ci le schéma global en figure 6.
Figure 6. Schéma global d’utilisation d’un aperçu, « versionASK»
3.3. Exemples
Pour illustrer la génération et l’utilisation d’aperçus pour l’interrogation de do- cuments RDF, nous présentons trois séries d’exemples pédagogiques, d’abord des exemples de génération d’aperçus en laissant de côté la réduction des littéraux, en-
14. http://www.w3.org/TR/sparql11-query/#solutionModifiers
suite un exemple de réduction de littéraux et enfin des exemples d’interrogations de document RDF passant par les aperçus générés précédemment.
3.3.1. Exemples de générations d’aperçus par application des règles de réduction d’individu (Définition 5)
La partie du bas en figure 7 présente l’aperçu dérivé du document REST en figure 2 (repris ici en partie haute, oùex:Fredest maintenant aussi décrit de typeex:Médecinpar inférence vue en section 2.3) selon la ligne de compression minimale {ex:Personne}.
En effet, par application des règles :
r2 ⇒les individusex:Bobetex:Jean, tous deux de typeex:Pédiatre, sont fusionnés en un même nœud blanc, numéroté ici par1(i.e._:1) ;
r2 ⇒de même pour les individusex:Marieetex:Fredde typeex:Médecinqui sont fusionnés en_:2;
r4 ⇒une des deux relationsrdf:typeentre_:1etex:Pédiatreest supprimée ; r4 ⇒de même entre_:2etex:Médecin;
r4 ⇒la relationex:affinitéentre_:2et_:1est supprimée car il existe une relation plus spécifiqueex:collègueentre ces deux individus ;
r5 ⇒pour l’individu_:2son typeex:Personneplus général queex:Médecinest sup- primé (i.e.la relationrdf:type, mais aussi la classeex:Personnepuisque restant isolée).
Figure 7. Aperçu selon la ligne de compression minimale {ex:Personne} (n°1)
La figure 8 présente l’aperçu dérivé du document REST en figure 2 (toujours avec
ex:Fredaussi de typeex:Médecin) selon la ligne de compression {ex:Enfant,ex:Médecin}.
Cette fois-ci par rapport à l’aperçu précédente, la règle r3peut en plus être appli- quée :
r3 ⇒les individus ex:Marie,ex:Fredet ex:Alice sont fusionnés en un même nœud blanc (_:2), car leurs typesex:Enfantouex:Médecinappartiennent à la ligne de compres- sion ;
Il en résulte que la règle r4 peut s’appliquer de nouveau par rapport à l’exemple précédent :
r4 ⇒une des deux relationsex:soigneentre_:2et_:2est supprimée ;
r4 ⇒une des deux relationsex:nomentre_:2et le littéral« Dupont »est supprimée.
Figure 8. Aperçu selon la ligne de compression {ex:Enfant,ex:Médecin} (n°2) La figure 9 présente le dernier aperçu possible, celui dérivé selon la ligne de compres- sion maximale {ex:Enfant,ex:Pédiatre,ex:Chirurgien}. Cette fois-ci par rapport à l’aperçu précédent, la règler1peut en plus être appliquée :
r1 ⇒les individusex:Marieetex:Fred, initialement de typeex:Médecin, sont tous les deux typés enex:Pédiatre;
r1 ⇒idem, mais cette fois-ci avec le typeex:Chirurgien(ex:Marieetex:Fredsont donc multi-typés enex:Pédiatreetex:Chirurgienà cette étape).
Cette fois-ci, les règlesr2,r3etr4peuvent encore s’appliquer de sorte que tous les individus soient fusionnés en un seul et même nœud blanc (_:1). Enfin, l’application des règlesr3etr4suppriment les relations redondantes et types trop généraux.
Figure 9. Aperçu selon ligne de compression maximale {ex:Enfant,ex:Pédiatre,
ex:Chirurgien} (n°3)
3.3.2. Exemple de génération d’aperçu par application de la règle de réduction de littéraux (Définition 5)
Supposons que la partie gauche de la figure 10 soit le résultat intermédiaire de l’aperçu (par application des règles de réduction d’individu) d’un document RDF dé- crivant 3 personnes (individus de type ex:Personnepour lesquels sont renseignés les noms et prénoms). La partie droite de la figure 10 est le résultat final de la généra- tion de l’aperçu, en tenant compte en plus de la règle de réduction de littéraux. Ici la
Figure 10. Résultat de la fusion de 3 individus de typeex:Person) avec réduction des littéraux en 2 groupes, à gauche avant réduction et à droite après réduction
fonction de substitution utilisée pour la réduction est décrite en tableau 1 : une fois tous les littéraux triés par ordre croissant et répartis en deux groupes, chaque littéral du document est remplacé (substitué) par le premier littéral de son groupe.
r6 ⇒ Les littéraux ex:Alain, ex:Claude et ex:Dupont sont substitués par le littéral
ex:Alain.
r6 ⇒Les littérauxex:Lambertetex:Moreausont substitués par le littéralex:Lambert. r4 ⇒Suppression des relations redondantes.
Par ces substitutions sur ce simple exemple, le nombre de relations liant l’individu à des littéraux a diminué (passant de 5 à 3).
Tableau 1. Description de la fonction de substitution de littéraux utilisée en figure 10
Groupe 1 Groupe 2 Alain Lambert Claude Moreau Dupont
3.3.3. Exemples d’interrogations de bases RDF passant par leurs aperçus associés (Lemme 9)
Dans les exemples suivants d’interrogations, le document RDFDest celui repré- senté en figure 2. Ces exemples détaillent l’interrogation de D via ses aperçus (cf.
section 3.3.1). Pour cela, deux requêtes sont utilisées, l’uneQ1 pour laquelleDne contient par de résultat et l’autreQ2pour laquelleDcontient des résultats.
3.3.3.1. Interrogation par une requêteQ1sans résultats dansD
L’interrogation deD par la requêteQ1(figure 11) passe donc par l’interrogation intermédiaire d’un aperçu (figure 1 et figure 6). Considérons maintenant l’aperçu de D généré selon la ligne de compression minimale, que l’on appellera aperçu n°1, représenté en figure 7. La requêteQ1est au préalable réécrite enQ⋆1(non représentée ici) selon leThéorème 8, puis enA⋆1(cf.figure 12) selon leLemme 9. L’interrogation de l’aperçu n°1 parA⋆1retourne une réponse négative (false). On en conclut (toujours
SELECT ?sujet ?objet
WHERE { ?sujet rdf:type ex:Médecin .
?objet rdf:type ex:Pédiatre .
?sujet ex:soigne ?objet . }
Figure 11. Requête SPARQLQ1(à droite, sa représentation graphique) : Médecins soignants des pédiatres
ASK { ?sujet rdf:type ex:Médecin .
?objet rdf:type ex:Pédiatre .
?sujet ex:soigne ?objet . }
Figure 12. RequêteQ1réécrite enA⋆1
par leLemme 9) qu’il n’y a pas de résultat àQ1 dansD. On peut en effet constater qu’il n’y a pas de résultat àQ1dansD.
Considérons ensuite l’aperçu deDgénéré selon la ligne de compression {ex:Enfant,
ex:Médecin}, que l’on appellera aperçu n°2, représenté en figure 8. De même que pour l’aperçu n°1, l’interrogation de l’aperçu n°2 par A⋆1 retourne une réponse négative qui permet de conclure qu’il n’y a pas de résultats àQ1 dans D. Il n’est donc pas nécessaire d’interrogerD.
Considérons enfin l’aperçu généré selon la ligne de compression maximale, que l’on appellera aperçu n°3, représentée en figure 9. L’interrogation de l’aperçu n°3 parA⋆1retourne une réponse positive (true). On en conclut la présencepossiblede résultats à Q1 dansD bien qu’il n’y en ait pas. Nous appelons ceci unfaux positif.
Remarquons que la génération de cet aperçu a fusionné tous les individus en un seul, typé à la fois parex:Médecinetex:Chirurgienet lié à lui-même par une relationex:soigne. La figure 13 montre le résultat de l’interrogation de l’aperçu n°3 par la requêteQ⋆1.
Figure 13. Résultats (en traits épais) de la RequêteQ1dans l’aperçu n°3 deD
3.3.3.2. Interrogation par une requêteQ2avec résultats dans la baseD
Quelle que soit la ligne de compression, l’interrogation de chacun des trois aperçus deDparA⋆2(en figure 15), réécriture deQ2(en figure 14), retourne une réponse po- sitive qui signale la présence possible de résultats à la requêteQ2. La figure 16 permet de visualiser les résultats de l’envoi de la requêteQ⋆2sur ces aperçus. L’interrogation du documentDreprésenté en figure 2 par la requête Q2 (figure 14) fournit en effet deux résultats (figure 17).
SELECT ?sujet ?objet
WHERE { ?sujet rdf:type ex:Médecin .
?objet rdf:type ex:Pédiatre .
?sujet ex:collègue ?objet . }
Figure 14. Requête SPARQLQ2(à droite, sa représentation graphique) : Médecins collègues de pédiatres
ASK { ?sujet rdf:type ex:Médecin .
?objet rdf:type ex:Pédiatre .
?sujet ex:collègue ?objet . }
Figure 15. RequêteQ2réécrite enA⋆2
Figure 16. Résultats deQ⋆2dans les différentes aperçus (lignes n°1, 2 et 3)
---
| ?sujet | ?objet |
|===================|
| ex:Bob | ex:Jean |
| ex:Fred | ex:Bob | ---
Figure 17. Résultats de la requêteQ2dans la baseD
4. Expérimentation
Pour évaluer notre approche en recherche d’information utilisant des aperçus, en l’absence de benchmark SPARQL reconnu adapté au web sémantique, nous en avons mis un en place.
Une implémentation de générateur d’aperçus de recherche est disponible à l’URL suivante : http://der3i.labs.esilv.fr/download/OverviewRDF.zip, incluant les sources et un fichierREADME.txtindiquant notamment comment reproduire les tests effec- tués. Notons que le générateur proposé ici est mono-processus, bien que le processus de génération d’aperçus soit facilement parallélisable.
4.1. Jeu de données
Afin d’éviter tout biais dû aux aléas des temps d’accès réseau, mais ne pouvant pas charger en mémoire sur une machine standard aujourd’hui l’intégralité duLinked Data Cloud, nous avons extrait un sous-ensemble de la base généraliste DBPedia15. Ce sous-ensemble a ensuite été réparti en 200 bases composées chacune d’environ 10 000 triplets, contenant des informations plus ou moins diversifiées autour des sept théma- tiques suivantes (i.e.centrées autour des classes) :dbpedia:CelestialBody,dbpedia:City,db-
pedia:Country,dbpedia:Event,dbpedia:Film,dbpedia:Organisationetdbpedia:Person. Notons que ces bases ont été extraites selon la méthode d’extraction détaillée dans (Maillot et al., 2014) afin de créer une sorte demini-Linked Data, chargeable en mémoire. Les requêtes utilisées ont été choisies afin d’évaluer les performances des aperçus dans les situations les pluscourantes(Gallegoet al., 2011) et en situation de résolution de requêtes ditesdifficiles(Pérezet al., 2009 ; Schmidtet al., 2010).
Pour chaque base, nous avons généré trois aperçus différents selon trois lignes de compressions (représentées en figure 18) passant à des profondeurs différentes dans la hiérarchie des classes :
– La ligne de profondeur minimale contenant uniquement la classeowl:Thing la plus générale de l’ontologie, dont les aperçus seront appelésaperçusA.
15. http://dbpedia.org
– La ligne de profondeur 1 contenant les classesdbpedia:CelestialBody,dbpedia:City,
dbpedia:Country,dbpedia:Event,dbpedia:Film,dbpedia:Organisation, dont les aperçus seront appelésaperçusB.
– La ligne de profondeur 2 contenant la dernière thématiquedbpedia:Filmet toutes les sous-classes des classes de la ligne de profondeur 1, dont les aperçus seront appelés aperçusC.
Figure 18. Représentation (partielle) des lignes de compressions utilisées sur l’ontologie DBPedia
Le tableau 2 montre par thématique le nombre moyen de triplets dans les bases et dans les aperçus associés. On observe que les aperçus de profondeur 1 et 2 peuvent parfois être de taille légèrement plus grande que celles des aperçus de profondeurs minimum. Cela est dû aux spécialisations apportées par la règle de réductionr1, qui ajoute de nouvelles relations de typage dans la base en fonction de la ligne de com- pression (la ligneCcontient les 53 sous-classes des classes de la ligneB).
4.2. Requêtes SPARQL
Les requêtes SPARQL utilisées sont listées dans le tableau 3. Elles peuvent être séparées en deux groupes et trois catégories :
– Les requêtes « courantes », comme les requêtes 1 à 3, selon l’étude faite par (Gallegoet al., 2011) sur des requêtes soumises à DBPedia pendant un an. Ces re- quêtes utilisent des motifs dits en étoile, recherchant les informations autour d’un individu central ; le nombre de triplets qu’elles contiennent est compris entre 1 et 5.
– Les requêtes « difficiles » d’après les articles (Pérezet al., 2009 ; Schmidtet al., 2010), comme
- les requêtes 4 à 6 contenant le mot-cléUNION. - les requêtes 7 et 8 contenant le mot-cléOPTIONAL.
La résolution de ces requêtes SPARQL contenant des (conjonctions de) disjonc- tions portées par les opérateursUNIONetOPTIONALa été prouvée dans (Schmidtet al., 2010) comme étant co-NP-complète.
Tableau 2. Informations sur les bases de test et leurs aperçus Thématiques
principales des bases
Nb. moyen de triplets dans les bases
Nb.
moyen de triplets dans les aperçus A
Nb.
moyen de triplets dans les aperçus B
Nb.
moyen de triplets dans les aperçus C
Taux de com- pression moyen par thé- matique Celestial-
Body
10 313 386 409 417 97,77 %
City 10 759 883 888 893 94,82 %
Country 11 373 1 041 1 053 1 062 94,47 %
Event 11 804 910 918 923 95,58 %
Film 13 607 795 793 797 96,85 %
Organisation 13 149 1 273 598 1 278 94,53 %
Person 12 052 1 319 1 323 1 332 94,09 %
Total 2 376 565 190 054 191 447 192 652
Taux de compression moyen ( %) 92,00 % 91,94 % 91,89 %
4.3. Mise en place des tests
Chacune des 200 bases RDF a été montée avec ses aperçus sur un serveur dédié, où bases et aperçus sont accessibles par unendpoint16SPARQL propre.
Pour chaque requête listée au tableau 3, les bases ont été interrogées une à une via son aperçuA(minimal) selon le schéma de principe en figure 6, puis de même avec l’aperçuB, et enfin avec l’aperçuC.
Afin d’écarter de nos mesures les temps d’accès réseau, tous ces serveurs ont été hébergés sur une même machine physique17, donc exploitable en local. Notons qu’en plus de cela, puisque l’on utilise un protocole réseau pour interroger les bases, les temps d’accès – bien que minimes – aux aperçus et aux bases n’ont pas été pris en compte (i.e.temps soustraits des temps d’interrogation) afin de ne retenir que les temps calculatoires d’interrogation.
4.4. Résultats
Les temps totaux d’exécution, hors temps d’accès réseau, des différentes requêtes sur les aperçus et les bases sont présentés dans le tableau 4. Pour chaque sorte d’aperçu
16. Un endpoint SPARQL est un Web service pour l’interrogation d’une base RDF donnée selon le proto- cole SPARQL.
17. Machine comportant un processeur Intel Core 2 cadencé à 2,40GHz, 4Go de mémoire RAM, et tournant sous Ubuntu 12.04.
Tableau 3. Requêtes utilisées pour l’évaluation de notre approche
Requête originaleQ RequêteA⋆
q1 SELECT DISTINCT ?cible ?pred ?sujet WHERE { ?cible ?pred ?sujet .
FILTER( isLiteral(?sujet) ) }
ASK { ?cible ?pred ?sujet . } q2
SELECT DISTINCT ?name
WHERE { ?cible dbp:name ?name .
?cible dbp:starring ?actor .
FILTER(?actor = db:Robert_Downey,_Jr.) }
ASK { ?cible dbp:name ?name .
?cible dbp:starring ?actor . } q3
SELECT DISTINCT
?abstract ?death ?birth ?quote
WHERE { ?person dbp:name "Lucretius"@en .
?person dbo:abstract ?abstract .
?person dbo:deathYear ?death .
?person dbo:birthYear ?birth .
?person dbp:quote ?quote . }
ASK { ?person dbp:name "Lucretius"@en .
?person dbo:abstract ?abstract .
?person dbo:deathYear ?death .
?person dbo:birthYear ?birth .
?person dbp:quote ?quote . } q4
SELECT DISTINCT
?cible ?pred ?sujet
WHERE { ?cible ?pred ?sujet . { ?cible a dbo:Person .
?sujet a dbo:City . } UNION { ?sujet a dbo:Person .
?cible a dbo:City . } }
ASK { ?cible ?pred ?sujet . { ?cible a dbo:Person .
?sujet a dbo:City . } UNION { ?sujet a dbo:Person .
?cible a dbo:City . } } q5
SELECT DISTINCT
?cible ?pred ?sujet ?syno WHERE { ?cible ?pred ?sujet .
{ ?cible dbp:placeOfDeath ?sujet . } UNION { ?cible dbp:leaderName ?sujet .
OPTIONAL {
?sujet owl:sameAs ?syno . } } }
ASK { ?cible ?pred ?sujet .
{ ?cible dbp:placeOfDeath ?sujet . } UNION {
?cible dbp:leaderName ?sujet . } }
q6 SELECT DISTINCT
?cible ?pred ?sujet
WHERE { ?cible ?pred ?sujet .
{ ?cible dbp:placeOfDeath ?sujet . } UNION {
?cible dbp:leaderName ?sujet . } }
ASK { ?cible ?pred ?sujet .
{ ?cible dbp:placeOfDeath ?sujet . } UNION {
?cible dbp:leaderName ?sujet . } } q7
SELECT DISTINCT
?cible ?pred ?sujet
WHERE { ?cible ?pred ?sujet .
?cible dbp:placeOfDeath ?sujet . OPTIONAL {
?cible dbp:leaderName ?sujet. } }
ASK { ?cible ?pred ?sujet .
?cible dbp:placeOfDeath ?sujet . }
q8 SELECT DISTINCT
?cible ?pred ?sujet
WHERE { ?cible ?pred ?sujet .
?cible a dbo:Person .
?sujet a dbo:City .
OPTIONAL { ?sujet a dbo:Person .
?cible a dbo:City . } }
ASK { ?cible ?pred ?sujet .
?cible a dbo:Person .
?sujet a dbo:City . }
A,BouC, le tableau 5 recense le nombre de bases dont on a pu éviter l’interrogation car sans réponse à la requête donnée (cf.schéma de principe en figure 6).
Si l’on observe le seul tableau 4, on constate globalement que l’utilisation des aperçus (en première passe) lors de l’interrogation de bases RDF n’a pas d’influence sur les performances, c’est à dire n’apporte ni vraiment gain de temps (max.−9 %) ni vraiment perte de temps (max.+12 %) dans l’exécution d’une requête SPARQL.
Deux autres remarques sont à faire sur ces tableaux. D’une part, de manière pré- visible, on observe une dégradation des performances, en temps et en pourcentage de bases écartées, lors de la descente de la ligne de compression dans la hiérarchie de l’ontologie. En effet, le nombre de faux positifs est plus grand via les aperçusC, où le nombre d’individus dans un tel aperçu est de seulement 4 contre 7 individus en moyenne (compris entre 5 et 10) pour un aperçuA. D’autre part, on remarque que les systèmes d’indexation utilisés par le moteur Jena sont plutôt performants dans la mesure où le temps d’exécution d’une requête dépend peu de la taille de la base (à l’exception de requêtes avecUNIONdont la résolution reste co-NP-difficile).
Tableau 4. Temps d’exécution des requêtes, hors temps d’accès réseau N° Requête Temps
sans uti- lisation d’aperçu
Temps via aperçus A minimaux
Temps via aperçusB
Temps via aperçusC
Nombre de résul- tats dans les bases
1 q1 2:24,85 2:31,18 2:30,88 2:30,92 1 122 670
2 q2 0:06,65 0:07,15 0:07,16 0:07,07 13
3 q3 0:06,32 0:06,83 0:06,97 0:06,88 0
4 q4 1:05,66 1:05,26 1:09,08 1:09,27 2 680
5 q5 1:27,42 1:19,52 1:19,71 1:20,18 9 558
6 q6 1:24,74 1:18,42 1:18,20 1:18,54 9 546
7 q7 4:20,66 4:26,90 4:26,76 4:26,75 1 477 402
8 q8 0:08,80 0:09,48 0:10,78 0:10,79 1 962
Considérons maintenant le tableau 5. On constate qu’un certain nombre de bases n’ont pas eu besoin d’être interrogées car l’interrogation d’un aperçu associé a permis de l’éviter. Cela est d’autant plus vrai si la requête porte sur une thématique particu- lière où peu de bases sont susceptibles de contenir une réponse. Notons que face à une requête très (trop) généraliste, lorsque toutes les bases contiennent une réponse, l’affichage de «0 %base écartée » n’est pas précisé.
Dans le cadre réel duLinked Data Cloud où les bases sont distribuées, et où les temps d’accès réseau ne sont donc pas négligeables, ces résultats apportent une vraie contribution.
Tableau 5. Précision de l’interrogation passant par les aperçus N° Requête Nombre de
bases sans réponse
% de bases écartées via aperçusA
% de bases écartées via aperçusB
% de bases écartées via aperçuC
1 q1 0 — — —
2 q2 190 90,00 % 90,00 % 90,00 %
3 q3 200 88,00 % 88,00 % 88,00 %
4 q4 137 77,37 % 58,39 % 57,66 %
5 q5 89 100,00 % 100,00 % 100,00 %
6 q6 89 100,00 % 100,00 % 100,00 %
7 q7 0 — — —
8 q8 161 92,55 % 73,91 % 73,29 %
5. Conclusion
Dans cet article nous présentons la notion d’aperçu de recherche, qui en recherche d’information dans le web sémantique permet, pour une requête SPARQL donnée, d’écarter du spectre de recherche les bases RDF non pertinentes à cette requête parmi l’ensemble des bases du web sémantique. Il s’agit d’une sorte de version compacte d’une base RDF, réduite d’environ 90 % en nombre d’individus et de littéraux. La génération d’un aperçu est faite de façon à ce qu’une requête SPARQL qui n’a pas de réponse dans l’aperçu n’a pas de réponse dans sa base d’origine.
Nous avons évalué notre approche par des expérimentations sur des données et des requêtes SPARQL réelles, issues de DBPedia. Les résultats de ces expérimentations montrent l’apport qu’offre l’interrogation en premier lieu d’un aperçu de recherche plutôt que d’interroger directement sa base RDF associée par une requête SPARQL.
Sachant la diversité thématique des bases duLinked Data Cloud, cet apport est ap- préciable afin d’éviter de solliciter inutilement les bases non pertinentes car les temps d’accès réseau sont loin d’être négligeables dans cet environnement distribué.
De par la très petite taille d’un aperçu au regard de la base associée, nous en- visageons dans un travail futur de constituer localement de manière centralisée une plateforme de distribution (une sorte dehub) composée d’un aperçu de chaque base duLinked Data Cloud. Ainsi, pour une requête donnée, chaque aperçu de la plate- forme sera interrogé, et selon les résultats de cette première passe, seules les bases potentiellement pertinentes seront interrogées en seconde passe à travers le réseau. Au cours des expérimentations qui suivront, nous espérons trouver les paramétrages de réduction sur les individus et les littéraux les plus performants (hauteur de la ligne de compression dans l’ontologie, cardinalités et fonction de substitution).
Remerciements
Le présent travail a bénéficié du soutien de l’École Supérieure d’Ingénieur Léonard de Vinci (ESILV), dans le cadre du projet coopératif TIMCO du Pôle de Compétitivité Systematic (FUI 13).
Bibliographie
Bechhofer, Sean et al. (2004). OWL web ontology language reference.
(http://www.w3.org/TR/owl-ref/)
Berners-Lee T., Hendler J., Lassila O. (2001). The SemanticWeb. Scientific American, vol. 279, n° 5, p. 34-43.
Biron P., Malhotra A. (2004, October). XML Schema part 2: Datatypes second edition.
(http://www.w3.org/TR/xmlschema-2/)
Brickley D., Guha R. V. (2004). RDF Vocabulary Description Language 1.0: RDF Schema. (http://www.w3.org/TR/rdf-schema/)
Fokoue A., Kershenbaum A., Ma L., Schonberg E., Srinivas K. (2006). The summary abox: Cutting ontologies down to size. Proc. of the Internat. Semantic Web Conference (ISWC’06),vol. 4273, p. 343-356. Springer.
Gallego M. A., Fernández J. D., Martínez-Prieto M. A., Fuente P. de la. (2011). An empirical study of real-world sparql queries. Internat. Workshop on Usage Analysis and the Web of Data (USEWOD’2011). ACM.
Klyne G., Carroll J. J. (2004). Resource Description Framework (RDF): Concepts and Abstract Syntax. (http://www.w3.org/TR/rdf-concepts/)
Maillot P., Raimbault T., Genest D., Loiseau S. (2014). Targeted Linked Data Extractor.
Proc. of the internat. conference on agents and artificial intelligence (ICAART’14).
Pérez J., Arenas M., Gutierrez C. (2009). Semantics and complexity of sparql.
Transactions on Database Systems (TODS), vol. 34, n° 3, p. 16.
Prudhommeaux E., Seaborne A. (2008). SPARQL Query Language for RDF.
(http://www.w3.org/TR/rdf-sparql-query/)
Raimbault T., Maillot P. (2013). Vues d’ensembles de documents rdf. Actes du 31e congrès INFORSID, p. 387-402.
Schmidt M., Meier M., Lausen G. (2010). Foundations of sparql query optimization.
Proc. of the Internat. Conference on Database Theory (ICDT’10), p. 4-33. ACM.
Tran T., Zhang L., Studer R. (2010). Summary models for routing keywords to linked data sources. Proc. of the Internat. Semantic Web Conference (ISWC’10), p. 781-797.
Springer.
Umbrich J., Hose K., Karnstedt M., Harth A., Polleres A. (2011). Comparing data summaries for processing live queries over Linked Data. World Wide Web, vol. 14, p. 495-544.
Vu Q., Ooi B., Papadias D., Tung A. (2008). A graph method for keyword-based selection of the top-k databases. Proc. of SIGMOD on management of data, p. 915-926.
Springer.
Zhang X., Cheng G., Qu Y. (2007). Ontology summarization based on rdf sentence graph.
Proc. of the Internat. World Wide Web Conference (WWW’07), p. 707-716. ACM.
