Interrogation récursive du Web sémantique - CoDE - Université ...

Interrogation récursive
du Web sémantique
Mémoire présenté en vue de l’obtention du diplôme de
Ingénieur civil informaticien
Pierre GEWELT
Promoteur
Professeur Esteban Zimányi
Superviseur
Boris Verhaegen
Service
CoDE-­‐WIT
Année académique
2011-­‐2012

Remerciements
Je tiens à remercier tout particulièrement mon superviseur Boris Verhaegen, pour tout
le temps qu’il m’a consacré durant la réalisation de ce mémoire, pour son soutien, pour
ses relectures, et pour les nombreux conseils et feedbacks qu’il a pu me donner tout au
long de sa rédaction.
Je remercie également mon promoteur Esteban Zimányi pour ses conseils, relectures
et retours.
Merci aussi à ma famille et à mes amis pour leur soutien, leur support et leurs en-
couragements durant la réalisation de ce travail, en particulier à Carla Colomina, Eric
Gewelt et Michèle Colassin.
Enfin, un second merci à Michèle Colassin pour ses multiples relectures et corrections.
2

TABLE DES MATIÈRES 3
Table des matières
1 Introduction 5
2 Contexte 7
2.1 Évolution du Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Web sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Linked Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Linking Open Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Standards, protocoles et outils 20
3.1 Ressource Description Framework (RDF) . . . . . . . . . . . . . . . . . . 20
3.2 RDF Schema (RDFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Les Triple Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Le langage d’interrogation SPARQL . . . . . . . . . . . . . . . . . . . . . 26
3.5.1 SPARQL endpoint, une interface d’interrogation . . . . . . . . . . 28
3.6 Le framework Jena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Le moteur d’interrogation ARQ . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Stockage et interrogation des données 31
4.1 Les entrepôts de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Les moteurs de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 La fédération de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 La fédération de requêtes avec découverte active (ADQF) . . . . . . . . . 36
4.5 Le Link Traversal, une approche d’interrogation récursive . . . . . . . . . 37

TABLE DES MATIÈRES 4
5 Analyse de SQUIN, un outil d’interrogation 40
5.1 La librairie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Son utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Version stand-alone . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.2 Version standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Ses principes de fonctionnement et son architecture . . . . . . . . . . . . . 42
5.3.1 Fonctionnement par chaîne d’itérateurs . . . . . . . . . . . . . . . 44
5.3.2 Architecture de la librairie . . . . . . . . . . . . . . . . . . . . . . . 50
6 Amélioration du temps de réponse 55
6.1 Parallélisation des branches d’interrogation . . . . . . . . . . . . . . . . . 56
6.2 Ordre d’évaluation des Triple Patterns . . . . . . . . . . . . . . . . . . . . 58
6.3 Interrogation parallèle régulière du QLD . . . . . . . . . . . . . . . . . . . 58
7 Résultats de l’amélioration 63
7.1 Méthode d’analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2 Requête 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3 Requête 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.4 Conclusions sur les résultats . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8 Perspectives futures 71
8.1 Adaptation en temps réel du plan d’exécution . . . . . . . . . . . . . . . . 71
8.2 Intégration de requêtes vers des moteurs de recherche . . . . . . . . . . . 72
8.3 Fusion et nettoyage des données locales . . . . . . . . . . . . . . . . . . . 73
9 Conclusions 74
A Résulats complets des tests effectués 79

Chapitre 1
Introduction
Le Web sémantique connaît à l’heure actuelle une forte croissance, et cette tendance
est amenée à s’accentuer dans les années à venir. La grande quantité de données qui
y est déjà disponible est en croissance exponentielle, c’est pourquoi il sera de plus en
plus primordial de proposer des méthodes d’interrogation efficaces et rapides du Web
sémantique, capables de gérer convenablement cette énorme quantité de données.
Le but de ce mémoire est d’analyser les méthodes d’interrogation traditionnelles et
novatrices du Web sémantique, d’analyser une librairie existante permettant de l’inter-
roger de manière décentralisée et récursive, d’optimiser cette librairie afin de réduire le
temps d’attente des résultats lors d’une requête, et de proposer des pistes d’investigation
supplémentaires en vue d’améliorer davantage l’expérience du Web sémantique pour les
utilisateurs dans les années à venir.
Pour ce faire, nous découperons ce mémoire en plusieurs parties. Dans un premier
temps, nous présenterons un état de l’art du Web sémantique et de son contexte, des
standards et protocoles existants qui permettent d’en faire usage, et des méthodes de
stockage et d’interrogation des données qui y sont publiées. Après cela, nous analyserons
la librairie SQUIN, un outil d’interrogation du Web sémantique basé sur une approche
d’interrogation récursive novatrice appelée Link Traversal, permettant d’effectuer des
requêtes décentralisées sur le Web de données. Ensuite, nous présenterons les pistes de
recherche investiguées dans le cadre de ce mémoire afin de réduire le temps d’attente des
utilisateurs lors d’une requête, ainsi que les résultats obtenus grâce à ces investigations.
Enfin, nous terminerons en citant quelques perspectives futures et d’autres pistes de
recherche qui pourraient être approfondies par la suite.
5

Le deuxième chapitre présente le contexte général dans lequel nous nous situons.
Nous commencerons par une introduction au Web sémantique et au Web de données, au
concept de Linked Data et à ses principes et objectifs, ainsi qu’au projet communautaire
collectif Linking Open Data visant à créer de plus en plus de liens entre les données
publiées sur ce nouveau Web.
Le troisième chapitre est consacré à l’étude des standards, outils et protocoles qui
existent dans ce domaine. Ceux-ci définissent notamment des schémas de données et des
protocoles d’interrogation.
Le quatrième chapitre offre une comparaison de cinq méthodes d’interrogation du
Web sémantique, tantôt traditionnelles, tantôt novatrices. La cinquième, citée plus haut
et dénommée Link Traversal, y est détaillée plus particulièrement puisque cette approche
est un des éléments centraux de ce mémoire.
Le cinquième chapitre consiste en une analyse de la librairie SQUIN, une interface
d’interrogation du Web de données pour les sources adhérant aux principes de Linked
Data. Cette librairie implémente les principes du Link Traversal définis au chapitre
quatre.
Le sixième chapitre détaille les trois pistes investiguées dans le cadre de ce mémoire,
celles-ci ayant pour but de réduire le temps d’attente des utilisateurs lorsqu’ils effectuent
une requête grâce à SQUIN. En effet, le nombre de données disponibles sur le Web
sémantique étant en croissance exponentielle et amené à conserver cette tendance dans les
années à venir, il sera d’autant plus nécessaire d’en optimiser les méthodes d’interrogation
de cette énorme quantité de données.
Les deux premières pistes de recherche décrites au chapitre six se sont avérées in-
fructueuses, mais la troisième a en revanche produit de très bons résultats. Le septième
chapitre présente les résultats obtenus grâce à l’implémentation concrète de cette troi-
sième piste. Une conclusion sur les résultats présentés y est également donnée.
Le huitième chapitre analyse les perspectives futures et propose des pistes d’investi-
gation supplémentaires afin d’optimiser davantage l’exécution des requêtes via SQUIN.
Le neuvième et dernier chapitre présente les conclusions que l’on peut tirer des ré-
sultats obtenus, un point sur le développement personnel que m’a apporté ce travail, et
une conclusion générale sur le sujet présenté dans ce mémoire.
6

Chapitre 2
Contexte
Actuellement, les serveurs d’hébergement permettent le stockage et la mise à dispo-
sition de l’information, le réseau Internet permet le transfert de cette information et les
ordinateurs personnels permettent son affichage à destination de l’utilisateur final. Le
matériel informatique (infrastructure, machines) ne sert donc actuellement que de moyen
de transfert de l’information, et il est impossible pour les machines d’en comprendre le
contenu. En effet, ce n’est qu’à la phase finale du procédé, lorsque l’information est affi-
chée à l’écran de l’utilisateur, que ce dernier l’interprète et comprend ce qu’elle signifie.
Il est donc le seul à en connaître la sémantique.
Une interprétation de l’information par les ordinateurs est actuellement très difficile,
car celle-ci est stockée de manière non structurée. En effet, une page Web n’est qu’un
ensemble de caractères qui se suivent, formant des phrases que seuls les humains sont
capables d’interpréter. Les seuls liens sémantiques sont les liens hypertextes entre docu-
ments. Cette utilisation actuelle du Web est qualifiée de document-centric, car il s’agit
davantage d’un stockage de documents liés entre eux, par opposition à un stockage de
données liées entre elles. On l’appelle de ce fait le “Web de documents” (Web of Docu-
ments).
Afin de rendre l’information interprétable par les ordinateurs, il faut ajouter une sé-
mantique aux données, et rendre l’information structurée (ou du moins semi-structurée).
C’est l’objet du Web sémantique (aussi appelé Web 3.0), projet initié à l’époque par Tim
Berners Lee en 2001 [1].
7

2.1 Évolution du Web 8
Nous allons d’abord brièvement citer les évolutions principales du Web, pour ensuite
nous pencher sur l’étude du Web sémantique.
Contenu
2.1 Évolution du Web . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Web sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Linked Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Linking Open Data . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Évolution du Web
Lors des débuts du Web, celui-ci était principalement utilisé afin de transférer de
l’information de manière unidirectionnelle, c’est-à-dire des créateurs de contenu vers les
internautes. En effet, les possesseurs de sites Web étaient les principaux créateurs de
contenu sur le Web, et les internautes se servaient du Web à des fins consultatives. L’in-
ternaute moyen n’ayant pas de connaissances en matière de création de sites Web, il se
voyait rapidement confronté à des difficultés techniques s’il désirait mettre de l’informa-
tion à la disposition publique des autres internautes.
Par la suite, une nouvelle tendance s’est fait jour, aidée par l’apparition de nouvelles
technologies (AJAX, etc.), afin de permettre à l’utilisateur lambda non seulement d’ac-
céder au contenu, mais également d’en créer. Cette tendance a été appelée le Web 2.0,
ou Web social, et l’on y retrouve quelques grands concepts et acteurs connus, comme les
services de blog (Skyblog 1 , etc.), d’hébergement vidéo (YouTube 2 , DailyMotion 3 , etc.),
d’hébergement de photos (Picasa 4 , FlickR 5 , etc.), et surtout les réseaux sociaux (Face-
book 6 , LinkedIn 7 , etc.). Cette tendance s’est donc traduite par une forte augmentation
des interactions internaute—site web et internaute—internaute.
Nous pouvons constater que le Web est en évolution permanente, et une nouvelle
tendance est actuellement en train de se répandre progressivement, celle du Web séman-
tique, comme expliqué précédemment.
1. http://www.skyrock.com/blog/
2. http://www.youtube.com/
3. http://www.dailymotion.com/
4. http://picasa.google.com/
5. http://www.flickr.com/
6. http://www.facebook.com/
7. http://www.linkedin.com/

2.2 Web sémantique 9
2.2 Web sémantique
Le Web sémantique est le Web des données (Web of Data), par opposition au Web
de documents (Web of Documents). Dans le Web de documents, il n’y a pas de liaisons
sémantiques entre les données. Chaque application possède ses propres données et infor-
mations, chaque site Web possède son information et l’affiche sous forme visuelle grâce
aux pages Web, mais il n’y a aucune convention mise en place afin de représenter les
données de manière standardisée, ce qui permettrait aux différentes applications et aux
différents sites Web de pouvoir chacun se baser sur les informations fournies par un(e)
autre. En d’autres mots, les données ne sont donc pas connectées entre elles.
Certaines approches du Web de documents tendent à rajouter de la sémantique dans
le Web de documents, c’est par exemple typiquement le cas des encadrés que l’on peut
trouver en haut à droite des pages Wikipédia. Cependant, le Web de données offre un
potentiel beaucoup plus important en termes de liaisons entre les données, grâce à ses
liens sémantiques explicites.
Avant d’aller plus loin, prenons un exemple de cas pratique illustrant l’utilité d’un
Web où les données sont connectées entre elles. Admettons par exemple que l’on veuille
planifier le prochain voyage de vacances. Nous ne connaissons pas encore la destination
qui conviendrait le mieux, mais nous avons certaines exigences quant au pays :
– il doit être composé de minimum 20% de surface forestière ;
– il doit au minimum comprendre l’anglais comme langue véhiculaire ;
– le prix moyen du pain dans la devise locale doit être inférieur ou égal à l’équivalent
de 1e, afin de s’assurer que le coût de la vie n’y soit pas trop élevé.
On peut rapidement se rendre compte que ce type de requête est totalement irréalisable
avec la structure du Web de documents actuel. En effet, actuellement nous serions obligés
de trouver les informations nous-mêmes grâce aux moteurs de recherche traditionnels,
et d’ensuite en agréger les données et ne garder que celles répondant aux contraintes
posées, car nous seuls connaissons la sémantique de ces informations et contraintes. Avec
l’apparition d’un Web où les données sont liées entre elles par des liens sémantiques, un
tel type d’interrogation devient réalisable.
Le Web de données a ainsi été conçu en vue de permettre une meilleure intégration
des données et d’offrir la possibilité d’interroger plusieurs sources de données. En résumé,
c’est un unique espace de données mondialement distribué. Contrairement au Web de
documents qui est conçu à la base pour être lisible par des humains et pas spécialement
par des machines, le Web de données, quant à lui, est imaginé pour être non seulement

2.2 Web sémantique 10
interprétable par des humains, mais également par les machines grâce à l’ajout de liens
sémantiques.
On voit là des possibilités techniques beaucoup plus vastes vis-à-vis du traitement
de l’information, car dès lors que les machines sont capables de comprendre le sens, la
sémantique des données, elles peuvent alors les traiter et également inférer de nouvelles
informations. Les possibilités d’inférence des données seront détaillées plus loin, dans les
sections 3.2 (RDFS) et 3.3 (OWL). Cela est possible grâce à la sémantique explicite de
l’information publiée sur le Web de données. Sur ce dernier, les liens sont typés, là où le
Web de documents possède des liens non typés.
Il est bon de signaler que, les moyens de représentation brute de l’information du
Web sémantique n’étant pas aussi aisés à interpréter visuellement par les humains, il
existe de plus en plus d’outils de visualisation et de présentation des données du Web
sémantique [2].
Le principe de base du Web sémantique est de représenter les données sous forme
de triplets (ou triples). Un triplet est un ensemble de trois informations : un sujet,
un prédicat et un objet. On pourrait y voir une analogie avec la syntaxe de la langue
française, où l’ensemble des informations serait représenté par une multitude de phrases
simples de type sujet-verbe-complément.
être :
– Le sujet est la ressource au sujet de laquelle une information va être définie. Il est
représenté par une URI 8 . Une ressource est, de manière simplifiée, une “chose” sur
Internet, physique ou abstraite. Elle peut représenter une ville, une catégorie de
plantes, une personne, un concept, ...
– Le prédicat est le type d’information qui va être définie à propos du sujet. Il est
également représenté par une URI.
– L’objet est la valeur du prédicat du sujet. Il peut être soit une URI ou un identi-
fiant local (c’est-à-dire qu’il pointe vers une autre ressource), soit un littéral (une
information textuelle concrète, telle qu’une chaîne de caractères ou un nombre).
Un exemple de triplet (en pseudo-code, utilisant un littéral comme objet) pourrait
1989
8. Uniform Resource Identifier [3], identifiant la ressource en question. Plus d’informations à ce sujet
dans la section 2.3.

2.2 Web sémantique 11
De même, un exemple de triplet (utilisant une URI comme objet) pourrait être :
Ces triplets, liés entre eux, peuvent ensuite être représentés sous la forme d’un graphe
connectant les entités entre eux. La figure 2.1 illustre le graphe représentant l’ensemble
des deux triplets donnés en exemple ci-dessus. Plus d’informations sur les triplets et leur
représentation seront données à la section 3.1.
Figure 2.1 – Représentation graphique d’un ensemble de triplets.
Cette représentation de l’information fournit donc des données semi-structurées, par
opposition à des données structurées ou non structurées. Pour rappel :
– Des données non structurées sont par exemple le texte libre contenu et affiché
sur une page Web. C’est une information interprétable par les humains, mais une
machine n’a aucune information sur cette donnée.
– Des données semi-structurées sont des informations liées entre elles, interpré-
tables par une machine. C’est le cas des triplets du Web sémantique. Néanmoins,
il n’est pas possible de savoir à l’avance quels seront les attributs (les prédicats) qui
seront définis au sujet d’une ressource. En effet, le système des triplets permet de
définir n’importe quelle information au sujet d’une ressource donnée (dans notre
exemple : l’âge et la ville natale d’une personne), et il n’est donc pas possible pour
une machine de connaître une liste finie des autres informations qui pourraient être
données au sujet de cette même ressource.
– Des données structurées sont des informations au sujet desquelles la structure
est connue d’avance. C’est le cas par exemple des bases de données, dans lesquelles
les tables ont une structure prédéfinie, et où l’on sait exactement quelles sont les

2.2 Web sémantique 12
données qui peuvent être définies au sujet d’une entrée, puisque la structure de la
table est connue.
Pour exploiter tout le potentiel d’un tel Web de données, il est cependant nécessaire
que toutes les sources de contenu s’accordent à parler un seul et même langage de repré-
sentation des données, afin qu’une source puisse être capable d’interpréter la sémantique
du contenu des autres sources. Par exemple, il faut être capable d’indiquer que deux res-
sources informatiques présentes sur le Web de données représentent en réalité le même
concept physique, et qu’elles doivent être traitées comme une seule entité. C’est l’objet
des vocabulaires et ontologies 9 , ils seront détaillés plus loin dans ce mémoire.
Afin d’encourager la publication de données sémantiques sur le Web, un nouveau
concept est également apparu : celui des Semantic Wikis 10 . Ceux-ci sont des wikis
qui permettent d’enregistrer de l’information semi-structurée pour le Web de données,
contrairement aux Wikis traditionnels qui ne permettaient que de publier de l’informa-
tion non structurée. Ceux-ci ont l’avantage de combiner les forces du Web sémantique
(interprétation par les machines, intégration des données, requêtes complexes) et celles
des Wikis (simplicité d’utilisation et de contribution, forte interconnexion, collabora-
tion). Concrètement, les créateurs de contenu y ont la possibilité de définir des concepts
(ressources du Web sémantique) ainsi que des propriétés (prédicats) liant ces concepts
entre eux ou à des littéraux. Cette approche contribue donc également à alimenter le
Web de données.
On peut résumer comme suit les différences et l’évolution du Web de documents vers
le Web de données [4] :
Web de documents Web de données
Analogie Système de fichiers distribué Base de données distribuée
Objets principaux Documents Données
Liens entre Documents Données et documents
Types de liens Non typés Typés
Informations Déconnectées Liées entre elles
Niveau de structure Faible Élevé
Sémantique Implicite Explicite
Conçu pour Un traitement humain Un traitement machine
9. http://semanticweb.org/wiki/Ontology
10. http://km.aifb.kit.edu/ws/semwiki2006/
et humain

2.3 Linked Data 13
Ceci conclut les principes généraux du Web sémantique. Afin d’implémenter concrè-
tement ce système, il faut tout d’abord définir un moyen concret de publier ce type
d’information sur Internet, et c’est l’objet de Linked Data, décrit au chapitre suivant.
2.3 Linked Data
L’objectif de Linked Data 11 est d’utiliser le Web pour faciliter la création de liens
entre des données connexes qui n’étaient pas encore liées, ou qui l’étaient déjà via d’autres
méthodes. On y retrouve un ensemble de pratiques recommandées pour exposer, par-
tager et connecter des morceaux de données, informations et connaissances sur le Web
sémantique grâce à l’utilisation des URI et de RDF. Linked Data décrit donc une mé-
thode de publication de données semi-structurées sur le Web de données, afin de lier les
données et de les rendre plus accessibles, augmentant ainsi l’utilisation que l’on peut en
faire.
Le Web de données est basé sur trois technologies (sémantiques) du Web : le protocole
HTTP, les URI, et le framework RDF.
– Hyper Text Transfer Protocol, ou HTTP, est le protocole le plus largement utilisé
pour le transfert de documents sur Internet et la consultation de sites Web. Le
Web de données veut faire usage de ce protocole existant et ne nécessite pas la
création d’un nouveau protocole de communication.
– Une Uniform Resource Identifier, ou URI, est une chaîne de caractères permettant
d’identifier une ressource sur un réseau (Internet dans le cas du Web). Une ressource
identifiée par une URI doit l’être de manière permanente, même si celle-ci venait
à être déplacée ou supprimée. Comme illustré à la figure 2.2, on retrouve deux
ensembles quasi-disjoints au sein des URI : les URL (Uniform Resource Locator)
et les URN (Uniform Resource Name).
• Une URL est la forme la plus connue des URI, elle indique comment obtenir plus
d’informations au sujet de la ressource. Un exemple d’URL est http://www.
ulb.ac.be, et permet d’indiquer qu’il est possible d’obtenir des informations
sur la ressource en utilisant le protocole HTTP pour accéder à la ressource
www.ulb.ac.be.
• Une URN est une forme moins connue d’URI, elle identifie une ressource au
sein d’un espace de noms 12 (namespace). Un numéro ISBN peut par exemple
11. http://linkeddata.org/
12. Cette notion sera détaillée plus loin dans la section 3.1 (RDF).

2.3 Linked Data 14
être représenté sous la forme urn:isbn:0-123-45678-9. Dans ce cas, l’espace
de noms est isbn, et l’identificateur 0-123-45678-9 identifie une ressource (le
livre) de manière unique au sein des numéros ISBN.
– Resource Description Framework, ou RDF, est un modèle de données générique
basé sur la théorie des graphes, permettant de représenter de l’information avec
des triplets de la forme (sujet,prédicat,objet), comme décrit brièvement en 2.2. Un
ensemble de triplets forme donc un graphe RDF. Les trois éléments d’un triplet
RDF peuvent être représentés chacun par une URI. L’objet peut également être
URLs, URIs, URNs, and IRIs
un littéral (chaîne de caractères ou nombre). RDF sera explicité plus en détails à
la section 3.1.
URL URN
URI
Figure • A Uniform 2.2 – Resource Représentation Identifier desis ensembles either a URLURI, or a URL URN, et or both URN [5].
It takes the form scheme:scheme-specific-part
Afin de permettre l’utilisation de ces technologies Web pour publier et lier des données
• Conventions about use of /, #, and ?
sur le Web, Tim Berners-Lee, directeur du World Wide Web Consortium (W3C), a
formulé les principes de Linked Data en 2006 [6], principes qui ont permis la création du
Web de données. Les principes, énoncés dans leur langue d’origine, sont les suivants :
1. Use URIs as names for things.
2. Use HTTP URIs so that people can look up those names.
3. When someone looks up a URI, provide useful RDF information, using the stan-
dards (RDF, SPARQL, ...).
4. Include RDF statements that link to other URIs so that they can discover related
things.
Les premier et deuxième principes indiquent qu’une entité (ressource) doit être iden-
tifiée par une unique URI basée sur le protocole HTTP. De cette manière, cette URI
sert, d’une part, d’identifiant unique pour la ressource, mais elle offre également, d’autre
part, un accès HTTP à une représentation de données structurées au sujet de ladite res-
source. Ainsi, il est possible d’effectuer un look-up (ou déréférencement) de cette URI,
c’est-à-dire qu’une requête HTTP vers cette URI recevra en réponse de l’information
31 / 76

2.3 Linked Data 15
concernant la ressource identifiée par l’URI. Le troisième principe veut que cette infor-
mation soit représentée de manière interprétable par les machines, c’est-à-dire selon le
standard RDF pour la représentation des données, et selon le standard SPARQL pour
l’adressage de requêtes (détaillé à la section 3.5). De même, selon le quatrième principe,
il est demandé de fournir des références (liens) vers d’autres URI dans les résultats ren-
voyés, de manière à permettre aux utilisateurs et aux machines d’effectuer un processus
itératif lors de leur recherche d’information.
Toujours dans le but de pouvoir lier les informations entre elles, il est fort probable,
dans un système en pleine évolution comme celui-ci, d’avoir deux sources de données
(ou plus) possédant des informations sur des ressources représentant un même concept
réel. Ces ressources se trouvant sur des espaces de noms différents, elles possèdent des
URI différentes et sont donc virtuellement considérées comme des concepts différents,
alors qu’en réalité elles représentent toutes un seul et même concept réel. Afin de pallier
ce problème, des liens spéciaux tels que sameAs et refersTo ont été définis [7] dans le
langage d’ontologies OWL, permettant d’indiquer qu’une ressource représente en réalité
le même concept physique qu’une autre ressource. Ces concepts seront abordés plus loin
dans ce mémoire.
Figure 2.3 – Recommandation d’application des principes de Linked Data [6].
À terme, l’application de ces principes en vue de faire grandir et d’alimenter le Web
de données devra permettre l’apparition de navigateurs Linked Data, de mashups Linked
Data et de moteurs de recherche Linked Data.

2.4 Linking Open Data 16
Mois et année Nombre de triplets RDF Nombre de liens RDF
Mai 2007 500.000.000 120.000
Avril 2008 2.000.000.000 3.000.000
Septembre 2011 31.000.000.000 504.000.000
Table 2.1 – Évolution des ensembles de données publiés grâce à Linking Open Data
2.4 Linking Open Data
Linking Open Data est un projet communautaire collectif visant à publier un maxi-
mum de données libres de droits sur le Web de données selon les principes de Linked
Data, en interconnectant des données de différentes sources de données [8, 9]. Une source
de données centrale très populée est DBpedia, l’équivalent de Wikipédia pour le Web de
données. Une fois ce réseau de sources de données créé, il est alors intéressant de dévelop-
per des clients Linked Data permettant de naviguer parmi ces données interconnectées.
Il existe actuellement déjà des outils de navigation interactive des données permettant
cela. Les organisations participant à la publication de ce contenu sont, d’une part, des
universités (principalement des États-Unis, d’Allemagne et du Royaume-Uni en 2008)
et, d’autre part, des sociétés (telles que la BBC, Renault, etc) [4].
Il est intéressant d’observer l’évolution des ensembles de données publiés grâce au
projet au fil du temps, illustrée à la table 2.4. Des représentations graphiques de ces en-
sembles de données interconnectés (linked datasets, ou LDS) ont été réalisées, comme il
est possible de le voir à la figure 2.6. Chaque flèche liant deux sources de données indique
que ces sources ont été liées entre elles, et ont défini un ensemble de liens sameAs, afin
de signifier à l’utilisateur qu’une ressource définie par la première source est conceptuel-
lement équivalente à une autre ressource définie par la deuxième source.
Le projet vise à connecter un maximum de sources de données entre elles, afin d’ob-
tenir “UN” grand et unique Web de données. Les sources de données peuvent cependant
être regroupées par noeuds ou clusters, c’est-à-dire par thématique. Par exemple, toutes
les sources contenant de l’information sur les génomes peuvent être regroupées en un
cluster propre à ce thème, toutes les sources à vocation cinématographique dans un clus-
ter spécifique au cinéma, etc. Si l’on observe la figure 2.6, on remarque que les cercles
représentant les sources ont chacun une couleur de fond. Ces couleurs représentent les
clusters cités ci-dessus.
Il est fort intéressant d’observer l’évolution au cours du temps des sources de données
interconnectées grâce au projet Linking Open Data. Les graphes représentant les sources

2.4 Linking Open Data 17
de données connectées d’année en année de 2007 à 2011 sont représentés dans l’ordre aux
figures 2.4, 2.5, 2.6, 2.7 et 2.8. Ce qui est très intéressant à remarquer, c’est la croissance
exponentielle du nombre de sources de données interconnectées, et donc du nombre
de données publiées sur le Web de données. Face à une telle croissance, il deviendra
primordial de proposer des méthodes efficaces et rapides d’interrogation de ces données.
C’est l’objet de ce mémoire comme nous le verrons par la suite à partir du chapitre 4.
Figure 2.4 – Représentation des sources de données interconnectées grâce à Linking
Open Data (en septembre 2007).

2.4 Linking Open Data 18
Figure 2.5 – Représentation des sources de données interconnectées grâce à Linking
Open Data (en septembre 2008).
Figure 2.6 – Représentation des sources de données interconnectées grâce à Linking
Open Data (en juillet 2009).

2.4 Linking Open Data 19
Figure 2.7 – Représentation des sources de données interconnectées grâce à Linking
Open Data (en septembre 2010).
Figure 2.8 – Représentation des sources de données interconnectées grâce à Linking
Open Data (en septembre 2011).

Chapitre 3
Standards, protocoles et outils
Nous avons vu au chapitre précédent les principes généraux qui régissent le Web
sémantique. Ceux-ci reposent sur des standards et des schémas de données bien définis,
tels que RDF, RDFS et OWL. De même, afin de permettre une implémentation concrète
de l’accessibilité aux données, il est nécessaire de mettre en place des serveurs de stockage
des données et de définir des protocoles d’interrogation de ces serveurs. Ce chapitre définit
ces différentes notions.
Contenu
3.1 Ressource Description Framework (RDF) . . . . . . . . . . . . 20
3.2 RDF Schema (RDFS) . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . 24
3.4 Les Triple Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Le langage d’interrogation SPARQL . . . . . . . . . . . . . . . 26
3.6 Le framework Jena . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Le moteur d’interrogation ARQ . . . . . . . . . . . . . . . . . . 30
3.1 Ressource Description Framework (RDF)
Comme énoncé précédemment, Resource Description Framework (RDF) est un mo-
dèle de données générique basé sur la théorie des graphes, permettant de représenter de
l’information avec des triplets de la forme (sujet,prédicat,objet). C’est le modèle standard
pour l’échange de données sur le Web de données. Il facilite l’intégration des données de
sources variées et permet une évolution des schémas de données au cours du temps sans
20

3.1 Ressource Description Framework (RDF) 21
que cela ne nécessite une modification au niveau des clients du Web de données [10]. Il
est en certains points semblable au modèle entité-relation.
Pour rappel, un triplet est un ensemble de trois informations liées (cf. section 2.2) :
– Le sujet (la ressource au sujet de laquelle une information va être définie, repré-
senté par une URI).
– Le prédicat (le type d’information qui va être définie à propos du sujet, représenté
par une URI).
– L’objet (la valeur du prédicat du sujet, étant soit une URI ou un identifiant local,
soit un littéral).
Pour mettre cela en relation avec le modèle de graphes RDF, un sommet représente
une entité (ressource identifiée par une URL ou entité locale identifiée par un identifiant
local), et une arrête représente un triplet RDF, c’est-à-dire le prédicat qui lie le sujet à
l’objet. Un ensemble de triplets RDF constitue donc un graphe dirigé étiqueté (directed
labelled graph).
2
1A--64B-

3.1 Ressource Description Framework (RDF) 22
– Deuxièmement les littéraux, représentés par un contour rectangulaire. Il va de soi
que les objets littéraux ne se trouvent qu’en extrémité de graphe.
Il existe également des quadruplets (quads), une extension des triplets rajoutant le
contexte (la provenance de l’information) comme quatrième information au triplet.
Sérialisation de triplets RDF
RDF définit une méthode de représentation de l’information sous forme de triplets.
Après avoir décrit le modèle conceptuel à la section précédente, il est utile de s’intéresser
à la manière de sérialiser cette information. Pour rappel, la sérialisation est le processus
d’encodage d’une information (comme un modèle ou un graphe RDF) physiquement sous
forme d’octets ou de bits, permettant ainsi un stockage sur disque ou un transfert sur le
réseau.
Afin de procéder à la sérialisation de triplets RDF, il existe plusieurs syntaxes de
sérialisation des graphes RDF : RDF/XML, N-Triple, Turtle, et Notation3 (N3). Cepen-
dant, il semble que RDF/XML et Turtle soient les plus utilisés.
Avant de détailler cela, il est nécessaire d’introduire la notion d’espace de noms
(namespace). Une source A pourrait décrire une ressource dont elle choisira X comme
identifiant. Une source B pourrait décrire une autre ressource, dont elle choisira égale-
ment X comme identifiant. X est donc un identifiant unique d’une ressource au sein
de sa source (i.e. unique au sein de A, et unique au sein de B), mais pas un identifiant
unique sur le Web (puisque le X de A ne représente pas le même concept que le X de
B). On dit alors que X est un identifiant au sein d’un espace de noms, en l’occurrence
l’espace de noms de A ou celui de B. Lors de la sérialisation ou de l’écriture de triplets,
que ce soit en RDF/XML ou en Turtle, il est en général préférable de définir à l’avance
les différents espaces de noms qui vont être définis, et d’attribuer à chaque espace de
noms un “nom local”, beaucoup plus court, afin d’abréger l’écriture des triplets et de les
rendre plus lisibles.
RDF/XML RDF/XML est une représentation d’un graphe RDF sous forme XML.
Cette syntaxe est plus difficilement lisible par des humains, mais présente l’avantage
d’être basée sur le standard XML, et donc facilement parsable par une machine.
Un exemple de sérialisation en RDF/XML pourrait être le suivant, dont l’illustration
est donnée à la figure 3.2 :

3.1 Ressource Description Framework (RDF) 23
1989
Bruxelles
Figure 3.2 – Représentation graphique d’un ensemble de triplets.
Turtle Il existe trois syntaxes fort similaires ayant pour but d’être plus facilement
lisibles par les humains que RDF/XML : N-Triple, Turtle et Notation3 (N3). N-Triple
est un sous-ensemble de Turtle, qui est lui-même un sous-ensemble de Notation3. Turtle
étant le plus utilisé, c’est lui qui va être décrit ici.
Turtle a pour but d’être une sérialisation de graphes RDF beaucoup plus facile à écrire
et à interpréter par un humain. Son écriture est beaucoup plus directe et plus proche
du modèle conceptuel de triplets. La même information que celle décrite ci-dessus en
RDF/XML s’écrit de cette manière en Turtle :
@prefix predicats: .
predicats:AnneeDeNaissance "1989" .
predicats:VilleNatale "Bruxelles" .

3.2 RDF Schema (RDFS) 24
3.2 RDF Schema (RDFS)
RDF Schema (RDFS) est un langage permettant de représenter de simples voca-
bulaires RDF sur le Web de données [12]. La sémantique des prédicats et les classes
d’entités peuvent être définies grâce aux vocabulaires et aux ontologies. Ceux-ci laissent
notamment la possibilité de créer des règles d’inférence, via un mécanisme de classes
et de propriétés, permettant ainsi de générer une grande quantité d’information et de
triplets dérivés des triplets existants. Cela permet d’augmenter les capacités de raison-
nement que peuvent avoir les machines et les programmes traitant les données du Web
sémantique.
RDFS permet notamment de définir des classes et sous-classes de ressources. Ainsi,
si l’on définit que B est une sous-classe de A, alors toute ressource X ayant pour triplet
(X rdf:type B), c’est-à-dire étant de type B, est automatiquement également de type
A.
De même, il est possible de définir le type de donnée du sujet et de l’objet d’un
prédicat. Par exemple, si l’on définit que le prédicat estMariéÀ a pour sujet une ressource
de type Personne et a pour objet également une ressource de type Personne, alors si l’on
définit le triplet (Romeo estMariéÀ Juliette), le système peut automatiquement
inférer que les ressources Romeo et Juliette sont toutes deux de type Personne.
Au dessus de la couche “vocabulaire RDF” qu’est RDFS, il existe des ontologies pour
le Web sémantique comme expliqué précédemment, offrant encore plus de possibilités
d’inférence de données. Le langage d’ontologies le plus connu est OWL et sera détaillé à
la section suivante.
3.3 Web Ontology Language (OWL)
Web Ontology Language, dont l’acronyme est OWL, est un langage d’ontologie pour
le Web sémantique, avec une sémantique formellement définie [13]. OWL permet donc
d’étendre les possibilités de raisonnement déjà offertes par RDFS. Elle exprime des classes
et propriétés, stockées elles-mêmes sous forme de documents au format RDF par exemple,
publiées donc sur le Web de données.
OWL existe lui-même en 3 sous-langages [5] : OWL Full, OWL DL 1 et OWL Lite.
1. Description Logic

3.4 Les Triple Stores 25
En complément de RDFS, OWL 2 permet de définir des propriétés supplémentaires,
comme déclarer des classes disjointes (e.g. aucune ressource représentant une personne
ne peut appartenir à la fois à la classe Homme et à la classe Femme). Il est également
possible de déclarer des propriétés spécifiques sur les prédicats, comme la transitivité,
l’unicité, l’inverse ou la symétrie.
Par exemple, si l’on définit que le prédicat estUnAnc^etreDe est une propriété transi-
tive, alors s’il existe un triplet (A estUnAnc^etreDe B) et un triplet (B estUnAnc^etreDe
C), on peut automatiquement inférer le triplet (A estUnAnc^etreDe C). L’unicité ex-
prime que si l’on définit que le prédicat aPourPèreBiologique est une propriété unique,
alors on garantit qu’aucune ressource n’aura deux pères (biologiques) déclarés. Il est
également possible d’exprimer des propriétés inverses, par exemple définir les prédicats
estParentDe et estEnfantDe comme propriétés inverses l’une de l’autre. Quant à la
symétrie, il est possible de déclarer un prédicat (e.g. estMariéÀ) comme symétrique,
créant alors un lien à double sens entre le sujet et l’objet.
Les ontologies ont un pouvoir d’expression relativement fort, car comme nous l’avons
vu, elles permettent de déclarer un ensemble de règles concernant les données, d’inférer
de nouvelles données sur base des données existantes, etc. Cependant, cela en augmente
grandement la complexité de calculs et la décidabilité. Au vu du nombre de données
disponibles sur le Web de données, et puisque ce nombre est amené à grandir expo-
nentiellement dans les années à venir, l’utilisation de RDFS est privilégiée pour le Web
sémantique, même si cela réduit les possibilités d’exploitation du potentiel du Web de
données.
3.4 Les Triple Stores
Un Triple Store est une base de données conçue pour le stockage de triplets RDF. On
pourrait comparer cela à une table d’une base de données relationnelle traditionnelle,
contenant simplement trois colonnes (sujet — prédicat — objet), et une grande quantité
d’entrées. Cependant, contrairement à une base de données traditionnelle, le Triple Store
est optimisé pour un fonctionnement basé sur le stockage et la récupération des triplets
RDF, avec notamment les mécanismes d’indexation qui en découlent.
Son interfaçage est cependant relativement semblable à celui des bases de données
traditionnelles : afin d’écrire ou de récupérer des données du Triple Store, il est nécessaire
de formaliser la requête par l’utilisation d’un langage d’interrogation. Dans le cas du Web

3.5 Le langage d’interrogation SPARQL 26
sémantique, le langage d’interrogation utilisé communément est SPARQL, qui sera décrit
plus en détails à la section 3.5.
Un triple store permet de stocker de l’information semi-structurée pour le Web sé-
mantique, mais encore faut-il avoir la possibilité de l’interroger afin de récupérer cette
information. Cela peut notamment se faire via un SPARQL endpoint jouant le rôle d’in-
terface de requêtes. Cette notion sera détaillée plus en profondeur dans la section 3.5.1.
Parmi les implémentations de Triple Stores, on peut citer entre autres Virtuoso 2
(proposant une version open-source de son outil), Jena SDB 3 , AllegroGraph 4 ou encore
Mulgara 5 .
3.5 Le langage d’interrogation SPARQL
Stocker une quantité énorme d’information de manière structurée n’aurait aucune
utilité s’il était impossible d’accéder à cette information. Pour cela, il est nécessaire
d’avoir un langage de requêtes, tout comme il existe des langages comme SQL et autres
pour accéder aux données d’une base de données traditionnelle. Dans le cas du Web
sémantique, c’est SPARQL qui est le langage standard d’interrogation du Web séman-
tique, plus particulièrement de graphes RDF. SPARQL est un acronyme pour Simple
Protocol And RDF Query Language.
Le composant de base d’une requête SPARQL est un BGP (Basic Graph Pattern),
qui peut être vu comme un ensemble de morceaux de requête élémentaires, appelés TP
(Triple Pattern). Un TP s’exprime sous la forme d’un triplet RDF, pouvant contenir
une ou plusieurs variables en tant que sujet, prédicat ou objet [11]. Une variable est
caractérisée par le fait qu’elle commence par un point d’interrogation dans le TP.
Un exemple d’une requête SPARQL pourrait être le suivant :
SELECT DISTINCT ?person ?name
WHERE {
}
foaf:knows ?person .
?person foaf:name ?name .
2. http://virtuoso.openlinksw.com/
3. http://jena.apache.org/documentation/sdb/
4. http://www.franz.com/agraph/allegrograph/
5. http://mulgara.org/

3.5 Le langage d’interrogation SPARQL 27
!""#$%%&'("")'(*%+(,+)-.+/*0 *&(*+,'&-% !"#$%&' *&(*+'()# !'()#
Fig. 2 Graph representation of a basic graph pattern (BGP) consisting of two triple patterns with query variables ?person and ?name.
Figure 3.3 – Représentation visuelle d’un BGP sous forme d’un graphe RDF [11].
?person ?name
“Orri Erling”
“Yves Raimond”
“Axel Polleres”
Table 1 Tabular presentation of solutions
for the sample BGP (cf. Figure 2)
in the sample RDF graph (cf. Figure 1).
Une représentation sous forme d’un graphe RDF est donnée à la figure 3.3. Dans cet
exemple, le premier TP est
The predicate ( URI in an RDF triple specifies the foaf:knows tive RDF ?person) stores and wrappers over relational databases
relationship between the subject and the object of the or over Web APIs. Some wrappers materialize the cre-
triple. For example, the triple (, foaf:name, introduisant “JohnScott”) une première states that variable the person ?person, aspouvant a response (à to cette URIétape-ci look-up requests. de la requête)
identifiedprendre by the given la valeur subject deURI n’importe is calledquelle John Scott ressource du graphe interrogé (figure 3.1), ?person
In addition to publishing a linked dataset following
and (, foaf:knows, ) states that he knows
another person Le second identified TP by est the (?person given object foaf:name URI. The ?name), an RDF introduisant dump or a SPARQL une nouvelle endpoint variable for their linked
datasets. An RDF dump is a large RDF document that
semantics?name. of predicate CetteURIs nouvelle as well variable as classes est liée of enti- à la précédente : ?name doit prendre la valeur de
contains the RDF graph which makes up the whole
ties are defined
l’objet
in
du
vocabularies.
triplet liant
The
la ressource
RDF Vocabulary
représentée linked par ?person dataset. par A SPARQL le prédicat endpoint foaf:name. is an HTTP-based Fi-
Definition Language (RDFS) [9] and the Web Ontology
Language nalement, (OWL) on [31] obtiendra allow users comme to résultats define such de la requête query service les noms thatde executes toutes SPARQL les personnes queries (etover
the
vocabularies. URISince des ressources RDFS andreprésentant OWL allow toces represent personnes)
linked
que
dataset. SPARQL [27], the query language for
RDF, is based on RDF graph patterns and subgraph
the definition connaît. of a vocabulary in the form of an RDF
matching.
graph, vocabularies can also be published as Linked
Data on the Web. Les résultats The termsd’une introduced requête in vocabularies SPARQL peuvent The être basic exprimés buildingsous block la from formewhich d’un to enconstruct
should besemble identified de résultats, with dereferencable comme présenté HTTP URIs. à la table more 3.1, complex ou sousSPARQL la formequery d’un (sous-)graphe
patterns is called basic
This practice enables a Linked Data aware application graph pattern (BGP). A BGP is a set of triple pat-
to retrieve
RDF.
and
Chaque
utilize the
solution
definition
est
of
donc
terms
une
used
correspondance
in
(matching) du BGP, c’est-à-dire un
terns which are RDF triples that may contain query
the currently ensemble processed définissant data. une valeur pour chaque variable variables de at the la requête, subject, predicate, tel que si and toutes object ces position
The Linked variables Data sont principles remplacées require parto larespond valeur qui to leur (cf. est Figure donnée 2). Solutions dans la in solution, SPARQL la are solution defined in the
a URI look-up request with an RDF graph that con- context of BGP matching: Each solution is a set of
est un sous-graphe du graphe RDF que l’on a interrogé. Par exemple, les sous-graphes
tains data about the entity identified by the URI; how- variable bindings that, basically, represents a match-
de la figure 3.1 mis en surbrillance sont les sous-graphes
ever, the principles do not prescribe what such an RDF ing subgraphcorrespondant in the queried RDF à la requête graph. For ex- instance,
graph should primée lookci-dessus. like, what data Ces mêmes is necessary, résultats what vo- sont repris the subgraphs sous forme highlighted de tableau in Figure à la 1figure match3.1 the sample
cabularies[11]. should be used, etc. Nonetheless, a common BGP in Figure 2; the solutions in Table 1 correspond
practice is to provide a set of RDF triples that contain to these subgraphs. More complex query patterns are
the requested URI ?person or that are closely related to them. represented by SPARQL ?name algebra expressions that pro-
However, the principles require that the provided RDF cess BGP solutions to calculate
“Orri Erling”
the result of a SPARQL
graphs should include RDF links pointing to data from query.
“Yves Raimond”
other data sources on the Web. An RDF link is an RDF
Applications may access “AxelLinked Polleres” Data on the Web by
triple where the subject is a URI in the namespace of
querying the SPARQL endpoint provided for a linked
one data provider andTable the object 3.1 is– another Ensemble URIde inrésultats the
dataset. d’uneWhile requête such SPARQL an access[11]. may already provide the
namespace of another provider. By connecting data of
application with valuable data, this approach ignores
different sources via RDF links the Web evolves into
Des requêtes plus complexes peuvent bien évidemment the great potential être exprimées of the Web grâce of àData; SPARQL, it does not
a platform where self-describing data of any type can
exploit the possibilities of this huge dataspace that in-
be posted, comme consumed, l’illustre and integrated par exemple in alastandardized figure 3.4. SPARQL offre également des possibilités d’extegrates
a large number of interlinked datasets. These
manner.
possibilities can be achieved by the execution of com-
Usually, the RDF graphs that can be retrieved by plex, structured queries over data spanning multiple
looking up a URI on the Web of Data are part of a datasets; i.e., answers to such queries correspond to sub-
linked dataset which is an RDF graph that contains graphs of the union of multiple linked datasets. In the
data about multiple entities. Typical approaches to cre- remainder of this article we discuss different approaches
ate a linked dataset are Linked Data interfaces over na- that enable the execution of such queries.
3

3.5 Le langage d’interrogation SPARQL 28
primer des contraintes (TP) requises ou optionnelles, ainsi que leurs conjonctions et
disjonctions éventuelles.
SELECT DISTINCT ?author ?phone
WHERE {
}
swc:hasPart ?pub .
?pub swc:hasTopic ?topic .
?topic rdfs:label ?topicLabel .
FILTER regex( str(?topicLabel), "ontology engineering", "i" ) .
?pub swrc:author ?author .
{?author owl:sameAs ?authAlt} UNION {?authAlt owl:sameAs ?author} .
?authAlt foaf:phone ?phone .
Figure 3.4 – Exemple de requête SPARQL [14].
La requête illustrée à la figure 3.4 traduite en langue française donnerait ceci : Quels
sont le nom et le numéro de téléphone des personnes ayant publié un article concernant
l’ingénierie des ontologies lors de la European Semantic Web Conference de 2009 ?. La
conférence est représentée par l’URI
http://data.semanticweb.org/conference/eswc/2009/proceedings>
et s’ensuit un ensemble de liens définis entre les variables de la requête. De plus, cer-
tains opérateurs spéciaux sont utilisés, comme l’opérateur FILTER permettant d’appliquer
une contrainte d’expression régulière sur la variable ?topicLabel, ou encore l’opérateur
UNION permettant d’unifier deux ensembles de résultats.
Comme nous le verrons plus loin au chapitre 4, SPARQL peut être utilisé pour
exprimer des requêtes auprès de plusieurs sources de données, que les données soient
physiquement stockées sous forme de graphe RDF ou non [15]. En effet, il est tout à fait
possible d’avoir une base de données qui ne soit pas un Triple Store, mais d’y adjoindre
un convertisseur intermédiaire (wrapper) qui prend en charge la traduction des données
physiques en un graphe RDF.
3.5.1 SPARQL endpoint, une interface d’interrogation
Lorsqu’une requête SPARQL est formulée, elle doit alors être adressée à une interface
qui prendra en charge l’exécution de la requête, ainsi que le renvoi des résultats de
celle-ci. Cette interface est appelée un point d’accès SPARQL (SPARQL endpoint) et

3.6 Le framework Jena 29
est donc un service Web d’interrogation basé sur le protocole HTTP. Un Triple Store
est généralement couplé à un SPARQL endpoint, afin d’offrir une interface capable de
recevoir les requêtes SPARQL et de renvoyer le contenu du Triple Store correspondant.
3.6 Le framework Jena
Afin de pouvoir concrètement interroger les sources de données citées précédemment
dans ce mémoire (points d’accès SPARQL, interfaces Linked Data, etc.), il est généra-
lement utile de recourir à des frameworks conçus à cet effet. C’est le cas notamment de
Jena, un élément important pour la suite de ce mémoire.
Jena est un framework Java permettant la création d’applications pour le Web séman-
tique et fournit un ensemble d’outils et librairies Java afin de faciliter le développement
d’applications liées au Web sémantique et aux concepts de Linked Data. 6 Il en existe
d’autres, tels que Redland 7 , Sesame 8 ou RDFLib 9 . Il utilise notamment les librairies de
ARQ 10 , un moteur d’interrogation du Web sémantique capable de traiter des requêtes
SPARQL, décrit à la section 3.7.
Ce framework est la librairie sous-jacente directe de l’outil SQUIN qui sera détaillé
au chapitre 5. Un exemple d’utilisation de Jena est donné à la figure 3.5. Le modèle m
qui y est créé représente l’exemple donné à la section 2.2.
Model m = ModelFactory.createDefaultModel();
/* RESSOURCES */
Resource pg = m.createResource("http://ulb.ac.be/Pierre_Gewelt");
Resource bxl = m.createResource("http://villes.org/Bruxelles");
/* PROPRIÉTÉS */
Property an = m.createProperty("http://predicats.org/AnneeDeNaissance");
Property vn = m.createProperty("http://predicats.org/VilleNatale");
/* TRIPLETS RDF */
pg.addLiteral(an, "1989");
pg.addProperty(vn, bxl);
Figure 3.5 – Exemple de création d’un modèle Jena.
6. http://incubator.apache.org/jena/
7. http://librdf.org/
8. http://www.openrdf.org/doc/sesame2/users/
9. http://www.rdflib.net
10. http://incubator.apache.org/jena/documentation/query/index.html

3.7 Le moteur d’interrogation ARQ 30
Le graphe RDF représentant ce modèle a été précédemment illustré à la figure 3.2.
3.7 Le moteur d’interrogation ARQ
ARQ 11 est un moteur d’interrogation permettant d’exécuter des requêtes SPARQL
sur un modèle Jena. Il est également développé par l’Apache Foundation Software, étant
donné qu’il est un élément constitutif de la librairie Jena.
Son utilisation est relativement simple, un exemple en est donné à la figure 3.6 [16].
Plusieurs moteurs d’interrogation dérivés de ARQ ont été développés, comme DARQ 12
par exemple.
import com.hp.hpl.jena.query.* ;
Model model = ... ; // Notre modèle Jena
String queryString = "SELECT ... WHERE { ... }" ; // Notre requ^ete SPARQL
Query query = QueryFactory.create(queryString) ; // Objet de la requ^ete
QueryExecution qexec = QueryExecutionFactory.create(query, model) ;
// Instance d’exécution
try {
ResultSet results = qexec.execSelect() ; // Ensemble de résultats
for ( ; results.hasNext() ; )
{
QuerySolution soln = results.nextSolution() ; // Solution courante
RDFNode x = soln.get("maVariable") ; // Valeur de maVariable...
Resource r = soln.getResource("VarR") ; // ...comme ressource
Literal l = soln.getLiteral("VarL") ; // ...comme litéral
}
} finally { qexec.close() ; }
Figure 3.6 – Exemple d’exécution d’une requête SPARQL avec ARQ [16].
Nous avons vu dans ce chapitre un ensemble d’outils permettant la mise en appli-
cation concrète du Web sémantique et de ses principes. Comme nous l’avons observé
précédemment au point 2.4, la quantité de données publiées sur le Web de données est
en croissance exponentielle, et il est donc nécessaire de mettre en place des méthodes
d’interrogation efficaces. Au chapitre 4, nous allons étudier différentes méthodes d’inter-
rogation du Web sémantique et comparer leurs différences.
11. http://jena.apache.org/documentation/query/
12. http://darq.sourceforge.net/

Chapitre 4
Stockage et interrogation des
données
Nous avons vu au chapitre 2 les tendances et concepts généraux du Web semantique,
et avons analysé plus en profondeur les standards et outils existants permettant l’uti-
lisation concrète de ce Web de données. Pour que ce dernier puisse être utilisable par
tout un chacun, il est bien sûr nécessaire de mettre en place des systèmes de stockage
des données sémantiques et des triplets RDF. En effet, sans ces éléments centraux que
sont les sources de données, l’interrogation du Web de données perdrait tout son sens.
Dans ce chapitre, nous allons nous intéresser à plusieurs méthodes d’interrogation du web
sémantique, dont le Link Traversal, une approche centrale dans le cadre de ce mémoire.
Contenu
4.1 Les entrepôts de données . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Les moteurs de recherche . . . . . . . . . . . . . . . . . . . . . . 35
4.3 La fédération de requêtes . . . . . . . . . . . . . . . . . . . . . . 35
4.4 La fédération de requêtes avec découverte active (ADQF) . . 36
4.5 Le Link Traversal, une approche d’interrogation récursive . . 37
Comme expliqué ci-dessus, nous allons dans ce chapitre faire une analyse compara-
tive de cinq différentes méthodes d’interrogation du web sémantique. Le contenu de ce
chapitre est principalement inspiré de la publication [11] d’Olaf Hartig et al.
Il est possible de regrouper ces méthodes en deux catégories : les méthodes d’interro-
gation traditionnelles d’une part, telles que l’interrogation d’un entrepôt de données, les
moteurs de recherche ou encore la fédération de requêtes et, d’autre part, des méthodes
31

! "#$%&'($)!*&!
*+##,&)!
"#)&9:8&!*&!
*+##,&)!
3#$&%%+;&2:8&)!
//?)!2.@!
*+##,&)!
*A+%3;3#&!
B$%./$.%&)!*&!
*+##,&)!
7&9')!*&!
%,'+#)&!
!"##$%&'()$*
+,-).$%&'
%#&%809%&'!%'
!"##$%&':7;'
0)13&'
-+$&.%)!*&!
%&/0&%/0&!
/%0'!%'
!"##$%&'
1,*,%2$3+#!
*&)!
%&4.5$&)!
&"1)+%&'
+"##1%&'
-)023)-2)%'

sur base de l’ensemble de triplets).
Accès aux données d’origine Cette propriété indique si la méthode d’interroga-
tion utilise directement les données publiées à leur source (typiquement dans le cas de
requêtes distribuées) ou si elle passe par une mémoire cache intermédiaire (comme un
entrepôt de données ou une mémoire d’indexation des données).
Structures de données Cela représente les structures de données utilisées conte-
nant des informations sur celles-ci (indexation, statistiques, etc.), offrant ainsi la pos-
sibilité d’avoir des informations préalables sur l’exécution de la requête (ce qui permet
par exemple d’optimiser la requête ou d’estimer le temps et le nombre de résultats de
celle-ci).
Temps de réponse Il y a deux données à cela : d’une part le temps écoulé entre
le début de la requête et le premier résultat renvoyé, et d’autre part le temps écoulé
jusqu’à l’exécution complète de la requête (dernier résultat). Typiquement, les requêtes
distribuées présenteront un écart plus grand entre le premier et le dernier résultat que
les requêtes centralisées.
Exhaustivité L’exhaustivité représente la quantité de résultats renvoyés une fois la
requête terminée par rapport à la quantité totale des résultats potentiellement trouvables
(i.e. vis-à-vis de l’ensemble de données interrogeables). De manière générale, les méthodes
ayant le Web de données tout entier comme ensemble de données interrogeables auront
une exhaustivité plus petite que 100%, puisqu’une exhaustivité de 100% nécessiterait
d’interroger la totalité des sources du Web de données, ce qui serait infaisable en pratique
car beaucoup trop long.
Données à jour Cette information détermine dans quelle mesure les données utili-
sées lors du traitement de la requête sont à jour. Typiquement, les méthodes interrogeant
les sources d’origine des données sont (par définition) à jour, là où une méthode utilisant
une mise en cache intermédiaire de l’information le seront moins.
L’explication des critères ayant été donnée, nous pouvons maintenant aborder cha-
cune des cinq méthodes d’interrogation décrites à la table 4.1. Dans tous les cas, nous
considérons SPARQL comme le langage utilisé pour formuler les requêtes exécutées.
33

4.1 Les entrepôts de données 34
4.1 Les entrepôts de données
Dans cette méthode d’interrogation, les données sont collectées et stockées dans un
entrepôt de données (data warehouse) central, et les requêtes sont effectuées uniquement
sur l’ensemble des données contenues dans cet entrepôt de données. Ce dernier peut être
utilisé comme mémoire cache, en y préchargeant une multitude d’ensembles de données
interconnectés (linked datasets, ou LDS). Pour rappel, les principes de Linked Data
veulent non seulement que l’on mette à disposition des ensembles de données (datasets),
mais également qu’on les lie entre eux (linked) grâce à des liens de type sameAs ou
refersTo, afin que le tout forme un seul ensemble de données connectées (comme illustré
à la figure 2.6).
Les entrepôts de données offrent donc un temps de réponse très rapide, car tout est
centralisé, et des accès réseaux ne sont pas nécessaires à l’exécution de la requête (ce
qui la rendrait plus longue). En terme de performance, c’est donc la méthode la plus
efficace [11]. En effet, les accès réseau réduisent considérablement le temps d’une requête ;
comme nous le verrons plus loin, le temps de calculs CPU est court par rapport au temps
d’accès réseau. Puisque toutes les données sont stockées localement, il est donc possible
de préétablir des index et statistiques sur les données, permettant d’accélérer le temps
de requête. Cependant, le nombre de données publiées sur le Web de données connaît
une croissance exponentielle (comme expliqué à la section 2.4) et cela pourrait devenir
problématique dans le futur pour une méthode d’interrogation de grands entrepôts de
données. Afin de pallier cela, il existe d’autres approches telles que le Link Traversal,
élément central de ce mémoire.
Il existe plusieurs manières d’alimenter un entrepôt de données. La plus simple
consiste à charger des ensembles de triplets RDF bruts (RDF dumps). Chaque LDS
est identifié par une URI, ce qui permet d’obtenir un ensemble de graphes nommés
(named graphs) [11, 17] et de pouvoir tracer la provenance des données contenues dans
l’entrepôt de données. Il est également possible d’interroger des points d’accès SPARQL
(SPARQL endpoints) pour récupérer des données, ou encore de déréférencer (look-up)
les URI des ressources déjà présentes.
Si le préchargement des données permet d’améliorer le temps de requête, il a comme
conséquence en contrepartie que les données sont susceptibles de ne pas être à jour
lors d’une requête. En effet, lorsqu’une source de données met à jour ces dernières, ces
modifications ne sont pas reflétées directement dans les entrepôts de données en aval
de ces sources. Il existe cependant des approches permettant de garder les données de
l’entrepôt synchronisées avec celles de la source [11, 18].

4.2 Les moteurs de recherche 35
Pour conclure, le renvoi de résultats est donc très rapide (aussi bien pour le premier
résultat que pour le dernier), mais ceux-ci sont limités uniquement aux données sto-
ckées dans l’entrepôt de données et n’offrent donc pas d’exhaustivité vis-à-vis de toute
l’information publiée sur le Web de données.
4.2 Les moteurs de recherche
Les moteurs de recherche du Web sémantique fonctionnent de manière similaire aux
moteurs de recherche traditionnels. Ils explorent le Web de données en suivant récursi-
vement les liens RDF rencontrés durant le processus, et indexent au fur et à mesure les
données découvertes. Ils offrent également une interface publique, afin que tout un cha-
cun puisse effectuer des recherches sur ces données indexées. On peut citer entre autres
Swoogle, Sindice ou Falcons [11, 19, 20].
Ils offrent cependant des fonctionnalités supplémentaires par rapport aux moteurs de
recherche traditionnels :
– En plus de renvoyer des résultats au format HTML pour lecture par un humain,
ils possèdent de par leur nature davantage de liens entre les données et sont donc à
même de renvoyer également des résultats au format RDF, permettant donc aussi
à des machines et programmes d’effectuer des requêtes directement via leur API 1 .
– En plus de permettre une recherche traditionnelle basée sur une simple chaîne de
caractères, il est parfois possible d’effectuer des requêtes avancées par triple pattern
matching.
Leur ensemble de données interrogeables est le Web de données complet, puisque par
définition ces moteurs explorent en permanence les LDS. Cependant, il peut exister un
certain délai entre la mise à jour d’une donnée à sa source et la mise à jour de l’indexation
correspondante dans le moteur de recherche. Pour cette raison, leur exhaustivité est
inférieure à 100%.
4.3 La fédération de requêtes
La fédération de requêtes est une approche distribuée, permettant de répartir l’exé-
cution de la requête sur plusieurs sources de données autonomes. Un premier serveur
analyse la requête et la décompose en plusieurs sous-requêtes. Ces dernières sont en-
suite envoyées chacune à une source de données autonome différente, et ces sources
1. Application Programming Interface

4.4 La fédération de requêtes avec découverte active (ADQF) 36
renvoient alors les résultats correspondants. Le premier serveur peut alors agréger ces
sous-résultats et renvoyer les résultats finaux à l’utilisateur. C’est donc une exécution
distribuée et non centralisée, comme c’était le cas pour les entrepôts de données et les
moteurs de recherche.
Cette méthode présente l’avantage qu’il n’est plus nécessaire de garder les données
copiées synchronisées, puisque l’on accède directement à la source. De plus, cela ne
nécessite pas d’espace disque supplémentaire redondant. Elle est en revanche beaucoup
plus lente, puisqu’elle nécessite beaucoup d’accès réseau, ce qui ralentit considérablement
le temps de la requête. De plus, l’ensemble de données interrogeables de cette méthode
est limité aux sources de données connues.
L’exhaustivité de la fédération de requêtes est de 100%, sauf dans le cas où l’interface
d’un LDS est inaccessible sur le réseau (panne, etc.). L’interrogation de ces LDS s’exprime
généralement par une requête SPARQL et se fait typiquement via leur point d’accès
SPARQL.
L’exécution d’une telle requête SPARQL implique souvent beaucoup de jointures (une
par Triple Pattern dans le pire des cas), or ces jointures allongent drastiquement le temps
de requête, puisqu’effectuées sur un accès réseau. Au vu de la croissance des données pu-
bliées sur le Web de données, et vu la complexité potentielle des requêtes SPARQL,
il est donc nécessaire d’établir des méthodes d’optimisation pour pallier cette lenteur.
Les méthodes d’optimisation traditionnelles de bases de données ne sont pas spéciale-
ment applicables dans le cas du Web de données, car elles reposent sur la connaissance
préalable de la structure des données contenues dans les sources de données distantes.
Mais alors que les bases de données possèdent des données structurées (les schémas
sont connus d’avance), le Web de données présente des données semi-structurées, et il
n’existe donc pas de tel schéma. Il est donc nécessaire d’établir de nouveaux algorithmes
d’optimisation, et des recherches sont actuellement effectuées en ce sens [11, 21, 22].
4.4 La fédération de requêtes avec découverte active (ADQF)
Les trois approches présentées précédemment impliquent la connaissance préalable
des sources de données que l’on va interroger, ce qui restreint la portée des applications
développées, puisque celles-ci sont limitées à l’utilisation de ces sources connues. Afin
d’utiliser tout le potentiel du Web de données, il est donc nécessaire d’implémenter des
méthodes de découverte active des sources de données, permettant ainsi de découvrir de
nouvelles sources durant l’exécution de la requête elle-même.

4.5 Le Link Traversal, une approche d’interrogation récursive 37
Une première approche dans ce sens est la fédération de requêtes avec découverte ac-
tive (Active Discovery Query Federation, ou ADQF). Elle est basée sur le même principe
que la fédération de requêtes présentées ci-dessus, mais rajoute à cela une découverte
active de nouveaux LDS non connus exposés par un point d’accès SPARQL, qui seraient
alors interrogeables en plus des sources de données connues d’avance.
Cette méthode présente les avantages de la fédération de requêtes (distribution de la
requête, non-redondance de l’information) et offre en outre des résultats plus complets
grâce à la découverte active de nouvelles sources. Cette découverte de nouvelles sources
peut se faire soit au moment de la requête elle-même, soit à l’avance de manière pro-
active (plus proche du fonctionnement d’un moteur de recherche, sauf qu’il n’y a ici pas
d’indexation ni de stockage des données, mais seulement des points d’accès SPARQL).
Elle peut soit s’opérer via l’interrogation d’un dépôt central (comme l’interrogation d’un
moteur de recherche par exemple), soit en suivant les liens RDF précédemment décou-
verts.
En contrepartie, l’ADQF présente le même problème que la fédération de requêtes,
c’est-à-dire la non-connaissance préalable de la structure et de la quantité de données
contenues dans les sources de données. Pour y remédier, il faudrait récupérer ces infor-
mations au moment de la requête et adapter le plan d’exécution en fonction, par exemple
en découpant la requête en un nombre encore plus élevé de sous-requêtes, afin de la dis-
tribuer davantage. Cette nécessité est valable pour la fédération de requêtes passive et
active, mais est d’autant plus vraie dans le cas de la découverte active.
Selon Olaf Hartig [11], il n’existe pas encore d’implémentation complète de cette
approche. Cependant, ce dernier pose déjà les bases théoriques de son fonctionnement.
4.5 Le Link Traversal, une approche d’interrogation récur-
sive
Comme expliqué au début du point précédent, les trois premières approches présen-
tées limitent les données interrogées aux sources de données connues, et il est nécessaire
d’implémenter des méthodes de découverte active de sources de données pour profiter
de tout le potentiel du Web de données. L’ADQF en est une et la traversée de liens
(Link Traversal) en est une autre, encore plus distribuée que la précédente. Dans la
suite de ce mémoire, nous appellerons cette approche par sa dénomination anglophone,
Link Traversal.

4.5 Le Link Traversal, une approche d’interrogation récursive 38
Le Link Traversal est une approche totalement basée sur le parcours de liens RDF
et ne nécessite aucunement la connaissance préalable de sources de données sémantiques
[23]. Elle est partie du concept d’une navigation manuelle des liens RDF, implémentée
par le navigateur Tabulator, un projet de navigateur de données RDF [11, 24]. Le Link
Traversal offre une navigation automatisée de ce concept et permet ainsi l’exécution de
requêtes SPARQL sur le Web de données, sans la nécessité de points d’accès SPARQL
pour autant. En effet, cela nécessite seulement que les URI identifiant les ressources
soient déréférençables (i.e. par application des principes de Linked Data [6], le déréfé-
rencement de l’URI d’une ressource par une requête HTTP renvoie des triplets RDF
contenant de l’information sur la ressource en question). Ainsi, chaque ressource ren-
voie une quantité d’informations limitée, mais très pertinente puisque ces informations
concernent la ressource en question.
La méthode d’interrogation du Link Traversal est la suivante [14] : lors de l’exécution
d’une requête, l’algorithme alterne en permanence entre la résolution d’un Triple Pattern
(TP) de la requête et le déréférencement de nouvelles URI découvertes durant l’exécution
de la requête. Cela permet d’augmenter en permanence l’ensemble de données récupérées
localement le temps de la requête, en y ajoutant des données ayant une forte probabilité
d’être pertinentes pour l’exécution de cette requête. Le temps d’accès réseau étant un
facteur dominant pour le temps d’exécution de la requête, il ne serait pas de bon ton
de déréférencer toutes les URI découvertes lors de déréférencements précédents, car bon
nombre d’entre elles ne seraient peut-être pas pertinentes pour la requête courante.
Ainsi, l’algorithme ne déréférence que les URI contenues dans les solutions intermédiaires
produites au fur et à mesure de l’évaluation de la requête (un exemple illustrant cela est
donné plus bas).
Le Link Traversal a pour avantage de profiter totalement du potentiel du Web sé-
mantique et permet d’obtenir, avec peu de triplets RDF, beaucoup d’informations utiles
pour la résolution de la requête. On peut donc obtenir des résultats pertinents en un
temps raisonnable. Par contre, le temps nécessaire avant d’obtenir le dernier résultat
peut être très long comparé aux autres méthodes. Son exhaustivité est inférieure à 100%
puisque, comme dit précédemment, il serait impensable d’interroger l’entièreté du Web
de données avant d’exécuter la requête.
Exemple d’application du Link Traversal
Un exemple d’application du Link Traversal est donné plus loin à la section 5.3.1.
Cet exemple montrera concrètement que l’ensemble de données local est continuellement

4.5 Le Link Traversal, une approche d’interrogation récursive 39
alimenté de données potentiellement intéressantes au fur et à mesure de l’exécution de
la requête, que la découverte de nouvelles informations peut se faire grâce au déréfé-
rencement des URI découvertes, ramenant de nouvelles données de plusieurs espaces de
noms (donc en général de plusieurs sources différentes), et que chaque source a référencé
des liens vers d’autres sources potentiellement pertinentes, permettant à l’utilisateur de
n’avoir eu aucune connaissance préalable des sources de données.

Chapitre 5
Analyse de SQUIN, un outil
d’interrogation
Comme nous l’avons vu précédemment, la méthode d’interrogation du Link Traversal
est un nouveau paradigme d’exécution et offre un haut potentiel d’exploitation du Web
de données. Afin de concrétiser cet algorithme, Hartig et al. ont développé un outil
d’interrogation nommé SQUIN 1 , basé sur les principes du Link Traversal [14].
SQUIN est une interface d’interrogation du Web de données, pour les sources adhé-
rant aux principes de Linked Data. Cette librairie, dont le nom est un acronyme de
Semantic web QUery INterface, permet d’exécuter une requête SPARQL en la résolvant
par la méthode du Link Traversal.
Trouvant l’approche du Link Traversal et l’outil SQUIN très intéressants grâce à leur
énorme potentiel d’exploitation, j’ai décidé, dans le cadre de mon mémoire, d’analyser
dans un premier temps cette librairie pour ensuite tenter de trouver des améliorations à
lui apporter en vue de diminuer le temps nécessaire à l’obtention des résultats. En effet,
la librairie étant basée sur une approche totalement distribuée, les temps d’exécution
peuvent être parfois très longs (de l’ordre de plusieurs minutes facilement), et un gain en
temps serait appréciable pour les utilisateurs de l’outil. Cependant, je n’avais aucune cer-
titude quant à la faisabilité de cette amélioration. C’est pourquoi la suite de ce mémoire
de recherche est composée en trois parties : d’abord une analyse de l’outil (d’un point
de vue utilisation ainsi qu’implémentation), suivie des différentes pistes que j’ai inves-
tiguées afin d’améliorer l’outil et leurs résultats, et enfin diverses idées supplémentaires
1. http://squin.sourceforge.net/
40

5.1 La librairie 41
d’amélioration qu’il aurait été trop long d’approfondir dans le cadre de ce mémoire. La
suite de ce chapitre décrit la première partie, l’analyse de l’outil.
Contenu
5.1 La librairie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Son utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Ses principes de fonctionnement et son architecture . . . . . 42
5.1 La librairie
La librairie SQUIN, écrite en Java, a été développée par Olaf Hartig et Juan Sequeda.
Le projet a débuté fin 2008 et la dernière mise à jour date de juin 2011. La librairie est
basée sur deux frameworks sous-jacents : Jena et ARQ. Ces derniers ont été décrits
précédemment, respectivement aux sections 3.6 et 3.7.
SQUIN utilise Jena afin de créer des modèles RDF pour représenter les données
qu’elle traite. ARQ est quant à lui utilisé afin d’exécuter la requête SPARQL sur le
modèle créé avec Jena. Comme nous l’avons vu précédemment, le modèle Jena ne cessera
de s’enrichir au fur et à mesure de l’exécution de la requête. La librairie est publiée sous
deux versions : une version standard et une version stand-alone.
La version standard possède le moteur d’interrogation de SQUIN et est récupérable
via un dépôt Subversion (https://squin.svn.sourceforge.net/svnroot/squin). Afin
de l’utiliser, il faut l’intégrer dans un projet Java et l’appeler via les méthodes Java pu-
bliques de la librairie. C’est ce code source-là que j’ai repris afin de l’améliorer.
La version stand-alone est un exécutable Java, pouvant être lancé sans qu’il soit
nécessaire d’intégrer la librairie dans un projet Java personnel. Elle intègre un serveur
HTTP (Jetty) et une interface Web afin d’exécuter les requêtes. Une fois l’exécutable
lancé, le serveur HTTP Jetty écoute localement et il suffit donc d’utiliser un navigateur
à l’adresse http://localhost:8890/SQUIN afin de pouvoir exécuter une requête à l’aide
de SQUIN. Cette version est plus pratique pour les personnes désirant simplement utiliser
la librairie telle qu’elle est. La mise en place de ces deux versions est détaillée à la section
5.2.

5.2 Son utilisation 42
5.2 Son utilisation
Nous allons ici donner une explication sur la manière d’utiliser concrètement ces deux
librairies.
5.2.1 Version stand-alone
Pour mettre en place la version stand-alone, la procédure est relativement directe.
1. Installer Jetty au préalable (distribué par Apache).
2. Récupérer la version stand-alone sur la page Web du projet 2 .
3. Ouvrir un terminal et se placer dans le répertoire racine du projet.
4. Exécuter la commande bin/squinserver.sh start . Cela va alors lancer un ser-
veur HTTP Jetty écoutant localement sur le port 8890.
5. Ouvrir un navigateur web et aller sur http://localhost:8890/SQUIN afin d’ob-
tenir l’interface Web de SQUIN, comme illustré à la figure 5.1.
6. Il est alors loisible à l’utilisateur d’y exécuter une requête SPARQL et d’en récu-
pérer les résultats.
5.2.2 Version standard
L’utilisation de la version standard demande un peu plus de manipulations. Après
l’avoir téléchargée sur le site Web du projet (http://squin.sourceforge.net/), il faut
en incorporer les sources dans un projet Java créé au préalable. Une fois cela fait, voici ci-
dessous un exemple de code Java constituant un squelette de base permettant d’exécuter
une requête SPARQL grâce à l’outil SQUIN. Des informations sur certaines des classes
citées dans l’exemple seront données dans la section 5.3.2.
5.3 Ses principes de fonctionnement et son architecture
Dans cette section, nous aborderons les aspects d’architecture et d’implémentation de
SQUIN. La première partie est une analyse et explication du mécanisme fondamental de
SQUIN pour appliquer les principes du Link Traversal, à savoir un fonctionnement par
chaîne d’itérateurs. La deuxième partie est une analyse de la librairie Java en elle-même,
et des classes principales utilisées lors de son exécution.
2. http://squin.sourceforge.net/

5.3 Ses principes de fonctionnement et son architecture 43
Figure 5.1 – Interface Web de SQUIN en version stand-alone.
String queryString = "SELECT ... WHERE { ... }"; // La requ^ete SPARQL
LinkTraversalBasedQueryEngine.register();
QueriedDataset qds = new QueriedDatasetImpl();
JenaIOBasedQueriedDataset qdsWrapper = new JenaIOBasedQueriedDataset( qds );
JenaIOBasedLinkedDataCache ldcache = new JenaIOBasedLinkedDataCache( qdsWrapper );
Dataset dsARQ = new LinkedDataCacheWrappingDataset( ldcache );
QueryExecution qe = QueryExecutionFactory.create(queryString, dsARQ);
ResultSet results = qe.execSelect(); // Initialise la requ^ete
while (results.hasNext()) { // Exécute l’algorithme itératif
System.out.println("Résultat : ");
QuerySolution s = results.nextSolution(); // Un résultat
System.out.println(s.toString()); // Par exemple, on l’affiche
}
try {
ldcache.shutdownNow(4000);
} catch (Exception e) { ... }
Figure 5.2 – Exemple de code Java pour l’utilisation de SQUIN.

5.3 Ses principes de fonctionnement et son architecture 44
5.3.1 Fonctionnement par chaîne d’itérateurs
Comme dit précédemment, SQUIN est un outil implémentant les principes du Link
Traversal. Concrètement, il est basé sur une chaîne d’itérateurs de TP (Triple Pattern),
dont le mécanisme est le suivant. Prenons en exemple la requête illustrée à la figure 5.3.
?p ex:affiliated_with
?p ex:interested_in ?b
?b rdf:type
Figure 5.3 – Exemple de requête SPARQL pour SQUIN (intérieur de la clause WHERE)
[23].
On a donc une requête composée de trois Triple Patterns (TP). Lors de la création
de la requête, l’outil crée une chaîne d’itérateurs, chaque itérateur étant responsable de
"#$%&'()*+(,-)"#(.+/012)3'$2
l’évaluation d’un TP. On aura donc ici trois itérateurs, respectivement I1, I2 et I3,
comme illustré à la figure 5.4.
!"#$%
!"!!!"#$%&&'('%)"*+,')-!!!.-))/$001110234%56
!"!!!"#$'7)"3"8)"*+'7! !#
!#!!!3*&$)9/"!!!.-))/$001110:22;6
)/ B !=!>!!"!?!"#$%&&'('%)"*+,')-!?!.-))/$001110234%56@ ! 5
)/ < !=!>!!"!?!"#$'7)"3"8)"*+'7!?!!#!@ ! !
)/ A !=!>!!#!?!3*&$)9/"!?!.-))/$001110:22;6!@ ! 4
!"#$%&#'()*%+%,-'.+/0.1"-2*-%34-'5%6"#00)0*%$.'%#0%7(-'#(.'%789"-8-0(#().0%.$%:)0;%#"%?#>-2%34-'5%@A-B4().0 CD
Figure 5.4 – Chaîne de trois itérateurs pour l’évaluation de la requête [23].
Le fonctionnement d’un itérateur In de la chaîne est le suivant. Chaque itérateur
In a connaissance de l’itérateur In−1 qui le précède (à l’exception de I1 qui n’a pas de
prédécesseur).

5.3 Ses principes de fonctionnement et son architecture 45
En sortie, un itérateur In produit un solution (binding). Une solution partielle (resp.
complète) est définie comme une association (mapping) de valeur à une partie des (resp.
à toutes les) variables de la requête. Le dernier itérateur produira donc des solutions
complètes, et les autres des solutions partielles ou complètes. En effet, dans le cas où le
dernier itérateur n’introduit pas de nouvelle variable, toute solution produite par l’avant-
dernier itérateur est une solution complète potentielle (“potentielle”car ce n’est pas parce
qu’une solution est complète qu’elle répond pour autant à la requête complète, il faut
pour cela encore que le dernier itérateur valide la solution potentielle vis-à-vis du TP
dont il est responsable).
En entrée, un itérateur In consomme la solution partielle produite par son prédéces-
seur In−1. Dans le cas particulier de I1, celui-ci consomme en entrée une solution initiale
dans laquelle aucune variable n’a de valeur associée.
Lors d’une première demande de solution, un itérateur In va demander une solution
partielle à In−1 (appellons-la solutionPartielleActuelle). Par la suite, à chaque appel
de la fonction de sortie de In, celui-ci va renvoyer la solution suivante de solutionPar-
tielleActuelle qui répond positivement au TP dont il est responsable. Lorsqu’une telle
solution suivante n’existe plus, In va alors demander à In−1 une nouvelle solution d’en-
trée, qu’il sauve dans solutionPartielleActuelle. Il peut alors recommencer l’évaluation
de son TP sur base de cette nouvelle solution d’entrée. Cette boucle se termine lorsqu’In
reçoit la valeur symbolique FIN de In−1 comme solution d’entrée, auquel cas In renvoie
alors également FIN en sortie. La chaîne d’itérateurs complète se termine donc lorsqu’I1
n’a plus de solution initiale répondant au premier TP.
Revenons maintenant à notre exemple, et voyons ce qu’il se passe concrètement lors
de l’exécution de la requête. Au début de la requête, le programme principal commence
par créer la chaîne d’itérateurs, puis interroge le dernier itérateur I3 et lui demande une
(première) solution (complète, puisqu’I3 est le dernier itérateur de la chaîne). I3 va alors
demander une solution intermédiaire à I2, qui fera de même envers I1. Ce dernier n’ayant
pas de prédécesseur, il va alors procéder directement à l’évaluation de son TP sur base de
l’ensemble de données local (query-local dataset, que l’on appellera QLD par simplicité).
Avant de procéder à cette évaluation, I1 va commencer par déréférencer les URI
présentes dans son TP, en l’occurrence http://.../orgaX, et rajouter ces données dans
le QLD, comme illustré à la figure 5.5.
Parmi ces données ajoutées au QLD, il y a notamment le triplet :
ex:affiliated_with

)%#*+%,*!-+.#/!0$#12%3,4!56+4
5.3 Ses principes de fonctionnement et son architecture 46
CD(-4E?:F>?
/>!>.(!
!" = $%$&$!"$'$()*>33+?+>!(/0@+!6$'$56!!"*778887:-A>B-2%34-'5%@A-B4().0 CD
! 7

5.3 Ses principes de fonctionnement et son architecture 47
I2 va alors consommer la solution partielle renvoyée par I1. Pour cela, I2 crée un
TP secondaire tp ′ 2 dans lequel les variables du TP dont il est responsable (tp2) ont été
remplacées par les valeurs données par la solution partielle de I1. De cette manière, ?p
aura été remplacé par http://.../alice>, donnant ainsi le TP temporaire tp ′ 2 illustré
à la figure 5.6.
I2 va alors procéder au déréférencement des URI contenues dans son TP temporaire,
i.e. l’URI http://.../alice, et stocker dans le QLD les données récupérées. Parmi
celles-ci, on trouve le triplet :
ex:interested_in
Ce triplet donnant une correspondance positive avec le TP temporaire (tp ′ 2 ) de I2, ce
dernier va renvoyer à I3 une solution associant la valeur à la variable
*&$+,&-+".,/$0"1%$23&4-5"67,5
?b (en plus de l’association précédente de à ?p donnée par I1),
comme illustré à la figure 5.7.
HI(7@J.6=+.
/+!+G(!
8
!" # $%$&$!"$'$()*+,,-.-+!(/01-!2$'$32!!"*445554678+9:$; ! !
!" E $%$&$!"$'$()*-F!(7(G!(/0-F$'$!#$;
32!!"*445554D#:$$7/,*!@"($$32!!"*445554A66B:
!" E C$%$&$32!!"*445554+.-=(:$'$()*-F!(7(G!(/0-F$'$!#$;
, donnant ainsi le TP temporaire tp ′ 3 illustré
à la figure 5.7.
! )
! (

5.3 Ses principes de fonctionnement et son architecture 48
I3 va alors procéder au déréférencement des URI contenues dans son TP tempo-
raire, i.e. l’URI http://.../b1, et stocker dans le QLD les données récupérées. Celles-ci
comportent notamment le triplet :
rdf:type
I3 va alors procéder à l’évaluation de son TP temporaire tp ′ 3 . Cependant, le TP de I3
est différent de ceux des itérateurs précédents. En effet, celui-ci ne lie pas une variable
à une autre, mais ne fait que poser une contrainte sur l’unique variable qui le compose
(?b). C’est donc un TP beaucoup plus restrictif que les deux autres, puisqu’il ne produit
pas plus de résultats en sortie que ce qu’il reçoit en entrée. Sa seule responsabilité est de
laisser passer ou non les solutions reçues de I2.
Dans le cas de notre exemple, le triplet ci-dessus récupéré donne une correspondance
positive avec le TP temporaire (tp ′ 3 ) de I3, comme illustré la figure 5.7. Dans ce cas-ci, on
a donc un comportement de “filtre passant”. I3 va alors pouvoir renvoyer la solution reçue
de I2 (qui est une solution complète, puisqu’elle associe une valeur à toutes les variable
!"#$%"&$'(%)#*'+,#-."/&0'12%0
de la requête, i.e. ?p et ?b), et l’utilisateur aura une première solution retournée, comme
illustré à la figure 5.8.
HI/

5.3 Ses principes de fonctionnement et son architecture 49
se caractérisera par le fait que I1 n’aura plus de résultat à proposer sur base de l’état
actuel du QLD. En effet, I3 va demander une solution suivante à I2, qui va demander une
solution suivante à I1. I1 étant à court de solution, il va renvoyer une solution symbolique
FIN à I2, qui fera de même envers I3, qui fera de même envers l’utilisateur, comme illustré
à la figure 5.9. Ce dernier saura alors que l’exécution de la requête est terminée.
Figure 5.9 – Fin de l’exécution d’une requête [23].
Une analyse séquentielle simplifiée des messages échangés durant le processus est
illustrée à la figure 5.10. Simplifiée, notamment car les tâches de déréférencement sont
en réalité exécutées de manière asynchrone et préventive [14].
Comme illustré sur la figure, la demande évolue progressivemment du dernier ité-
rateur au premier itérateur. Un ensemble de messages et de solutions intermédiaires
s’échangent de manière transparente aux yeux de l’utilisateur, et ce n’est que quand une
solution complète est acceptée par le dernier itérateur que celui-ci la renvoie à l’utili-
sateur. Ensuite, l’utilisateur redemande au dernier itérateur une solution suivante, et le
processus recommence (à l’exception du fait qu’il ne faut plus déréférencer les URI déjà
contenues dans le QLD).
Ceci conclut donc l’algorithme d’exécution d’une requête SQUIN selon les principes
du Link Traversal. Nous allons maintenant analyser certains éléments de la structure de
la librairie SQUIN.

5.3 Ses principes de fonctionnement et son architecture 50
Figure 5.10 – Diagramme de séquence de l’exécution d’une requête SQUIN normale.
5.3.2 Architecture de la librairie
Dans cette section, nous analyserons les principaux objets intervenant, aux yeux de
l’utilisateur, lors de la création et de l’exécution d’une requête SPARQL avec SQUIN.
5.3.2.1 Ensemble de données local
L’architecture de la gestion de l’ensemble de données local (query-local dataset, ou
QLD) est illustrée à la figure 5.11 et est à mettre en correspondance directe avec l’exemple
de requête donné à la figure 5.2.

5.3 Ses principes de fonctionnement et son architecture 51
Figure 5.11 – Principales classes utilisées aux yeux de l’utilisateur pour créer une requête
SQUIN.
5.2 :
En effet, ceci représente les objets principaux manipulés dans le cas de la requête
1. Dans un premier temps, un objet de type QueriedDatasetImpl est créé, mais est
vu comme son interface QueriedDataset . Cet objet possède le QLD qui va être
alimenté progressivement, mais n’implémente que des méthodes de lecture et d’in-
terrogation du QLD. C’est donc un QLD passif, n’effectuant aucun déréférencement
actif des URI rencontrées.
2. Ensuite, un objet de type JenaIOBasedQueriedDataset est créé, ayant égale-
ment QueriedDataset pour interface. Ce nouvel objet encapsule le premier objet

5.3 Ses principes de fonctionnement et son architecture 52
QueriedDatasetImpl, mais y ajoute des fonctionnalités permettant l’utilisation
du framework Jena afin de charger et de parser les données RDF qui doivent être
ajoutées au QLD.
3. Suite à cela, un objet de type JenaIOBasedLinkedDataCache est créé, encapsulant
l’objet JenaIOBasedQueriedDataset fraichement créé. Ce nouvel objet ajoute au
précédent des fonctionnalités d’alimentation active du QLD, grâce à la détection
de nouvelles URI identifiant des ressources, et peut alors se charger de déréférencer
les nouvelles URI pertinentes afin d’augmenter les informations contenues dans le
QLD. Ceci en fait donc un QLD actif.
4. Finalement, un objet de type LinkedDataCacheWrappingDataset est créé, encap-
sulant le précédent, et implémente l’interface Dataset définie par Jena/ARQ.
À l’exception de l’interface Dataset, toutes les autres classes/interfaces appartiennent
à la librairie de SQUIN et sont donc inconnues d’ARQ. Afin que le moteur d’interroga-
tion ARQ puisse évaluer la requête SPARQL sur le QLD actif implémenté par SQUIN,
il faut donc qu’un objet de SQUIN soit vu par ARQ comme une une interface définie
par ARQ, et c’est la fonction que remplit le dernier objet créé.
Suite à cela, ARQ peut alors lancer l’exécution de la reqête SPARQL. C’est l’objet
de la section 5.3.2.2.
5.3.2.2 Exécution d’une requête
Comme expliqué à la section précédente, un objet de SQUIN implémentant l’interface
Dataset de ARQ est créé, afin qu’ARQ puisse ensuite lancer l’exécution de la requête
SPARQL.
Pour cela, un premier objet de type QueryExecution, dont la classe appartient à
ARQ, est créé, comme illustré à la figure 5.12. Ce dernier a connaissance de la re-
quête SPARQL, ainsi que du QLD représenté par l’interface Dataset. Il offre des mé-
thodes permettant de lancer l’évaluation de la requête SPARQL, dont la principale est
execSelect().
L’appel de cette méthode a deux principales utilités. Dans un premier temps, celle-ci
commence par déréférencer les URI contenues dans la requête SPARQL, afin d’effectuer
une alimentation initiale de triplets RDF dans le QLD. Une fois cela fait, elle renvoie
alors un objet de type ResultSet, qui permettra d’obtenir l’ensemble des résultats de
la requête.

5.3 Ses principes de fonctionnement et son architecture 53
Figure 5.12 – Principales classes utilisées aux yeux de l’utilisateur pour exécuter une
requête SQUIN.
Il est bon de noter que cette méthode ne fait que déréférencer les URI initiales (seed
URIs), mais ne lance en rien l’exécution de la requête SPARQL et la chaîne d’itérateurs
décrite à la section 5.3.1.
L’exécution de la requête SPARQL en elle-même se fait alors dans un second temps
par l’utilisation de l’objet ResultSet créé précédemment. Cet objet fonctionne comme
un simple itérateur de résultats, au sens générique du terme (par opposition aux itéra-
teurs décrits dans la section 5.3.1). Son utilisation de base est simple, et basée sur deux
méthodes principales : hasNext() et next().

5.3 Ses principes de fonctionnement et son architecture 54
hasNext() permet de (re)lancer la chaîne d’itérateur, avec les mécanismes de dé-
référencements et solutions intermédiaires décrits à la section 5.3.1, et renvoie true dès
qu’une solution complète est trouvée, ou false lorsque la chaîne d’itérateurs indique
qu’il n’y a plus de résultats disponibles.
next() permet quant à elle de récupérer le résultat suivant disponible, suite à
un renvoi true de la méthode hasNext(), et renvoie un objet de type QuerySolution,
comme illustré à la figure 5.12.
L’objet QuerySolution renvoyé représente une solution complète à la requête SPARQL,
associant par définition une valeur (ressource ou littéral) à chaque variable indiquée dans
la clause SELECT de la requête. L’utilisateur peut alors afficher les résultats au fur et à
mesure qu’ils sont indiqués disponibles par hasNext().

Chapitre 6
Amélioration du temps de
réponse
Nous avons vu jusqu’ici les principes et standards du Web sémantique, comparé dif-
férentes méthodes de stockage et d’interrogation des sources de données, et analysé plus
en profondeur SQUIN, une librairie permettant d’effectuer une interrogation récursive
du Web sémantique selon les principes du Link Traversal.
Au vu de la croissance exponentielle du nombre de données publiées sur le Web de
données, il est primordial de proposer des approches efficaces d’interrogation du Web
sémantique afin d’obtenir des résultats pertinents en un temps raisonnable. L’apparition
de nouvelles méthodes d’interrogation basées sur une décentralisation des sources de
données m’a paru être un sujet de recherche très intéressant, c’est pourquoi je me suis
penché sur l’analyse de la librairie SQUIN et des paradigmes d’exécution sous-jacents
que constitue le Link Traversal.
Toujours dans cette optique d’une recherche d’un temps de réponse minimal pour ob-
tenir relativement rapidement des premiers résultats pertinents, j’ai décidé de m’atteler
à la recherche d’améliorations potentielles que je pourrais apporter à la librairie SQUIN
afin d’optimiser son temps de réponse, sans aucunement savoir si la recherche serait
fructueuse et mènerait ou non à des résultats intéressants. En particulier, j’ai recherché
des alternatives à certains processus de l’exécution qui pourraient permettre d’afficher
plus rapidement des premiers résultats de la requête à l’utilisateur.
Pour ce faire, j’ai investigué trois pistes, lesquelles sont décrites ci-dessous. Alors que
les deux premières se sont avérées infructueuses, la troisième en revanche a produit des
55

6.1 Parallélisation des branches d’interrogation 56
résultats de grand intérêt, qui seront analysés au chapitre 7.
Contenu
6.1 Parallélisation des branches d’interrogation . . . . . . . . . . . 56
6.2 Ordre d’évaluation des Triple Patterns . . . . . . . . . . . . . 58
6.3 Interrogation parallèle régulière du QLD . . . . . . . . . . . . 58
6.1 Parallélisation des branches d’interrogation
La première piste de recherche a consisté à analyser la possibilité de paralléliser
les branches d’exécution partant du premier itérateur. En effet, bien que la chaîne de
demandes de solutions (intermédiaires) soit initiée par le dernier itérateur, la production
concrète de résultats s’effectue dans l’autre sens, et peut être vue comme une division
en branches de résultats partant du premier itérateur et terminant au dernier itérateur
de la chaîne.
Cette séquence d’action est illustrée à la figure 6.1. Comme nous pouvons le voir sur la
figure, un ensemble d’échanges de messages et d’évaluations de résultats intermédiaires a
lieu durant ce processus avant que l’utilisateur ne recoive un résultat. Pendant ce temps-
là, le système n’avance aucunement dans l’exécution des branches partant des autres
résultats initiaux de I1. De plus, lors de l’appel suivant de la foncion next() sur I3, le
système reprend l’exécution de la chaîne dans l’état où il l’avait “laissée”, c’est-à-dire
qu’il va continuer l’exécution des sous-branches de la branche du premier résultat d’I1
(section en bleu sur la figure 6.1). C’est seulement bien plus tard que l’exécution de la
branche du deuxième résultat initial de I1 commencera, illustré par le deuxième cadre
mauve de la figure 6.1.
Une première idée qui m’est venue à l’esprit était de paralléliser à l’aide de threads
l’exécution des branches de résultats qui partent du premier itérateur. Cela revient à
lancer en parallèle les appels de méthodes illustrés en mauve sur la figure 6.1.
Si la structure et la complexité des branches d’exécution de chaque itérateur étaient
les mêmes pour toutes, une telle parallélisation n’apporterait aucune amélioration du
temps de réponse. Cependant, certaines branches d’exécution sont parfois beaucoup plus
petites que d’autres, et une exécution parallèle des branches du l’itérateur I1 permettrait
de terminer rapidement les petites branches (avec les résultats produits qui en découlent,
obtenus rapidement donc), et de continuer ensuite l’exécution des grandes branches pour
l’obtention des derniers résultats.

6.1 Parallélisation des branches d’interrogation 57
Figure 6.1 – Diagramme de séquence de l’exécution d’une requête SQUIN avec mise en
évidence des branches d’exécution parallélisables du premier itérateur de la chaîne.
Afin de mettre en oeuvre cette piste de recherche, j’ai créé une structure permettant
le lancement de tâches parallèles, chacune étant responsable de l’exécution d’une branche
de résultats. Cependant, au vu des erreurs obtenues, je me suis rapidement rendu compte
que cela nécessiterait une réécriture de fond en comble de la librairie, afin d’y rajouter
des mécanismes de gestion de zones critiques (mutexes) à certains endroits. En effet,

6.2 Ordre d’évaluation des Triple Patterns 58
il n’existe qu’une seule instance de chaque itérateur de la chaîne, et ces itérateurs ne
sont pas du tout pensés pour être utilisés au même moment par deux (ou plus) threads
différents.
J’ai donc décidé d’abandonner cette piste de recherche, mais elle a toutefois fait
naître une nouvelle idée d’amélioration potentielle pour le futur : il s’agirait d’analyser
le temps ayant été nécessaire à l’exécution des branches déjà parcourues, et d’utiliser les
informations qui en découlent pour adapter en temps réel le plan d’exécution au moment
de cette exécution. Cette idée sera décrite à la section 8.1.
6.2 Ordre d’évaluation des Triple Patterns
La deuxième piste de recherche était d’analyser le comportement de la librairie en
évaluant toutes les combinaisons possibles d’ordre des itérateurs de la chaîne, afin de
pouvoir en dégager un algorithme d’optimisation du plan d’exécution. Cependant, j’ai
également abandonné cette piste de recherche pour deux raisons [23] :
– d’une part, car le changement de l’ordre d’évaluation des Triple Patterns pourrait
dans certains cas en modifier les résultats renvoyés ;
– d’autre part, car la librairie effectue déjà une optimisation de cet ordre, dans une
mesure telle qu’elle ne modifie pas les résultats produits.
Pour ces raisons, j’ai donc également arrêté l’investigation de cette piste de recherche,
pour me pencher sur la troisième idée, décrite à la section 6.3.
6.3 Interrogation parallèle régulière du QLD
La troisième piste de recherche que j’ai voulu approfondir a été d’effectuer une inter-
rogation parallèle du QLD durant l’exécution de SQUIN. En effet, après avoir analysé
la séquence des actions effectuées par SQUIN lors de son exécution (cf. figure 5.10),
j’ai remarqué qu’il existait un temps entre l’intégration de nouvelles données dans le
QLD suite aux déréférencements et le moment où ces données étaient interrogées afin de
potentiellement produire un résultat, comme illustré dans le premier cadre rouge de la
figure 6.2.
J’ai donc décidé de créer un module exécuté en parallèle avec l’exécution de SQUIN,
ayant pour fonction d’interroger à intervalle régulier et fréquent le QLD dans son état
actuel (deuxième cadre rouge de la figure 6.2), afin que l’utilisateur puisse recevoir de

6.3 Interrogation parallèle régulière du QLD 59
Figure 6.2 – Diagramme de séquence de l’exécution d’une requête SQUIN avec inter-
rogation parallèle du QLD.
nouveaux résultats dès l’instant où les triplets nécessaires à l’obtention de ce résultat
sont présents dans le QLD. Cette approche permet donc de supprimer le temps qui existe
entre l’intégration des nouvelles données et l’affichage des résultats qu’elles permettent
de produire.
Les principales classes intervenant dans ce processus parallèle sont illustrées à la
figure 6.3. Voici ci-dessous les fonctions de chacune.
Tout d’abord, un objet LTBQueryExecutor est créé par l’utilisateur, chargé de l’exé-
cution générale du programme. Cet objet va alors principalement effectuer deux actions :
1. Créer les objets nécessaires à l’exécution normale de la librairie, telle que décrite
à la section 5.3.2. Cela implique notamment la création des objets de type Que-
riedDatasetImpl, JenaIOBasedQueriedDataset, JenaIOBasedLinkedDa-
taCache et LinkedDataCacheWrappingDataset. L’objet JenaIOBasedLin-

6.3 Interrogation parallèle régulière du QLD 60
Figure 6.3 – Nouvelles classes mises en place pour l’interrogation parallèle du QLD.
kedDataCache en particulier sera intéressant pour le module d’interrogation pa-
rallèle.
2. Créer un objet de type LTBDatasetQuerier, qui sera chargé d’effectuer l’inter-
rogation régulière du QLD, parallèlement à l’exécution normale de la librairie.
Une fois l’objet LTBQueryExecutor créé, il ne reste qu’à appeler sa méthode execute(int)
pour lancer l’exécution des deux processus décrits ci-dessus.
L’objet LTBDatasetQuerier hérite de la classe Thread, afin de pouvoir être lancé
en parallèle via sa méthode héritée start() (qui lance alors sa méthode propre run()).

6.3 Interrogation parallèle régulière du QLD 61
Ce thread va alors interroger régulièrement le QLD dans son état actuel, et évaluer la
requête SPARQL sur ce QLD grâce au moteur d’interrogation ARQ. Dès lors que des
nouveaux résultats seront disponibles, ceux-ci seront affichés dans une fenêtre gérée par
un objet de type LTBDatasetQuerierFrame, dont un exemple du rendu est ilustré à
la figure 6.4 (le but de ce module étant de démontrer l’utilité d’une telle interrogation
parallèle, le design graphique de la fenêtre n’a pas été très approfondi).
Figure 6.4 – Interface d’affichage brut des résultats de l’interrogation parallèle du QLD.
Afin que le LTBDatasetQuerier puisse exécuter cette interrogation, il faut bien en-
tendu qu’il ait accès au QLD. Cependant, il faut qu’il puisse interroger le QLD de manière
passive, c’est-à-dire en contournant les méthodes d’alimentation active du QLD lors de
l’exécution. En effet, les méthodes définies par un ensemble d’objets de la librairie SQUIN
ont pour fonction de déréférencer les nouvelles URI nécessaires au moment où une re-
quête est faite sur le QLD. Il est donc primordial que l’interrogation parallèle se fasse
de manière passive, c’est-à-dire en s’affranchissant un maximum des objets définis par
SQUIN, afin de rester le plus proche d’une utilisation directe des objets de Jena/ARQ.
C’est pourquoi l’objet LTBDatasetQuerier a connaissance de l’objet JenaIOBased-
LinkedDataCache créé précédemment par l’objet LTBQueryExecutor. Cet objet JenaIO-
BasedLinkedDataCache possède notamment une méthode asJenaGraph(), qui renvoie un
objet de type GraphBase ayant pour interface Graph (tous deux définis par Jena et non
pas par SQUIN), un graphe représentant l’état actuel du modèle de données contenu
dans le QLD. Ce graphe est donc totalement passif, et affranchi de toute alimentation
active du QLD par SQUIN. Une fois cet objet Graph récupéré, le module parallèle peut
alors évaluer la requête SPARQL sur le graphe renvoyé sans qu’aucun déréférencement
ne soit effectué, et détecter directement la présence d’éventuels nouveaux résultats.

6.3 Interrogation parallèle régulière du QLD 62
Pour terminer, il m’a fallu mettre en place un module permettant de comparer les
temps nécessaires entre l’affichage des résultats par le module d’interrogation parallèle
et l’affichage de ces mêmes résultats par l’exécution normale de SQUIN. C’est pourquoi
j’ai également créé un objet de type LTBResultsAnalyzer, qui a pour fonction d’être
informé dès l’apparition d’un nouveau résultat aussi bien de la part du module d’interro-
gation parallèle (méthode addQuerierResult()) que de la part de l’exécution normale
de SQUIN (méthode addNormalResult()). De plus, cet objet implémente un mécanisme
d’indexation des résultats dans un double objectif : d’une part, afin d’être capable de
faire la correspondance entre un résultat produit par l’interrogation parallèle et le même
résultat produit par l’exécution normale et, d’autre part, afin d’éviter les doublons dans
le cas où le même résultat serait obtenu par deux sources différentes (ou plus).
Pour de ne pas fausser les résultats, la méthode setStartTime() de l’objet LTBRe-
sultsAnalyzer est appelée une seule fois au lancement de l’exécution des processus (par
LTBQueryExecutor.execute()), afin d’utiliser le même temps de départ pour l’exécu-
tion normale et l’interrogation parallèle.
A la fin de l’exécution normale du programme, il faut alors exporter les résul-
tats obtenus en vue de pouvoir les analyser. C’est l’objet des fonctions toString() et
toCSVString(). La première permet d’afficher une comparaison des résultats de manière
facilement lisible pour un humain. La deuxième crée quant à elle une string au format
CSV contenant beaucoup plus d’informations, destinée à être sauvée dans un fichier CSV
pour une analyse ultérieure. Ces informations par résultat sont les suivantes :
– les temps absolu et relatif de l’obtention du résultat par le module d’interrogation
parallèle ;
– les temps absolu et relatif de l’obtention du résultat par l’exécution normale de
SQUIN ;
– les différences absolue et relative entre les entre les temps des deux méthodes ;
– la représentation textuelle de la solution.
Les temps absolus sont le temps (en seconde) renvoyé par la fonction time() du système.
Les temps relatifs sont le temps écoulé depuis le début de l’exécution de la requête.
J’ai alors effectué un benchmark de l’exécution de quelques requêtes avec ces deux
modules, afin de savoir si l’implémentation de ce module d’interrogation parallèle pouvait
contribuer à une réduction du temps nécessaire à l’affichage des résultats aux yeux de
l’utilisateur. Les résultats de ce benchmark sont analysés au chapitre 7.

Chapitre 7
Résultats de l’amélioration
Nous avons vu au chapitre précédent les trois pistes de recherche que j’ai investiguées
dans le cadre de mon mémoire. Si les deux premières n’ont pas donné de résultats satis-
faisants, la troisième en revanche a abouti à des résultats très intéressants comme nous
allons le voir dans ce chapitre.
Il faut cependant savoir ces résultats sont très aléatoires. Ils dépendent en effet de
multiples paramètres sur lesquels je n’ai aucun contrôle et qui influent fortement sur le
temps d’exécution du processus d’origine. On peut citer entre autres le temps de réponse
des communications effectuées sur le réseau Internet (qui est parfois très variable) et la
disponibilité des serveurs interrogés (car certains ne répondent parfois pas, menant ainsi
à un nombre de résultats plus faible).
Dans ce chapitre, je vais dans un premier temps expliquer la méthode que j’ai ap-
pliquée pour analyser les résultats, puis je présenterai les différentes requêtes effectuées
ainsi leurs résultats concrets, et je terminerai par les conclusions que l’on peut tirer de
ces résultats.
Contenu
7.1 Méthode d’analyse des résultats . . . . . . . . . . . . . . . . . 64
7.2 Requête 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3 Requête 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.4 Conclusions sur les résultats . . . . . . . . . . . . . . . . . . . . 67
63

7.1 Méthode d’analyse des résultats 64
7.1 Méthode d’analyse des résultats
Afin de tester concrètement l’efficacité du module d’interrogation parallèle, j’ai écrit
deux requêtes de référence, puis j’ai effectué un benchmark de plusieurs dizaines d’exécu-
tions de chaque requête, afin d’en sauver les résultats produits grâce à la fonctionnalité
d’exportation CSV décrite à la section 6.3. Les résultats bruts sont repris dans l’annexe
A. Une fois ceux-ci produits, je les ai aggrégés par requête et par solution, afin d’en
retirer les informations intéressantes.
Comme expliqué à la fin de la section 6.3, chaque exécution produit plusieurs infor-
mations au sujet des résultats : pour chaque solution, on a les temps absolu et relatif
de l’obtention des résultats avec chacune des deux méthodes, ainsi que les différences
absolue et relative entre les temps de chaque méthode. Cependant, pour l’analyse des
résultats, seule la différence de temps absolue est réellement pertinente. La différence de
temps relative l’est partiellement, et les autres ne le sont pas. En effet :
– Les temps absolus (fonction time() du système) des deux méthodes ne sont utiles
qu’à calculer les temps relatifs respectifs.
– Les temps relatifs (temps écoulé depuis le début de l’exécution de la requête)
peuvent varier fortement d’une exécution à l’autre, car l’ordre d’évaluation des
résultats intermédiaires dépend de l’ordre dans lequel les nouveaux triplets sont
ajoutés au QLD. Ainsi, il suffit qu’un seul déréférencement prenne plus de temps
que prévu (traffic sur le réseau, paquet perdu, surcharge du serveur distant, pas
de réponse du serveur distant, etc.) pour que l’ordre d’exécution des branches
d’interrogation en soit changé. Dès lors, un même résultat peut tantôt arriver
en premier, tantôt arriver en dernier, ce qui génère des temps relatifs totalement
aléatoires, rendant cette information peu pertinente.
– Pour une exécution particulière, la différence absolue entre les temps des deux
méthodes est par contre la donnée la plus pertinente, puisqu’elle caractérise le
temps gagné grâce à l’interrogation parallèle du QLD. L’inconvénient du point
précédent n’est donc plus présent ici, puisqu’on compare des informations ayant
exactement le même ordre d’exécution.
– La différence relative entre les temps des deux méthodes, c’est-à-dire le rapport
différence absolue entre les temps des deux méthodes
temps relatif de la méthode normale , n’est que partiellement pertinente.
Du côté pertinent, elle indique le pourcentage de temps gagné grâce au module
d’interrogation parallèle et donne une idée du gain apporté par ce module. Du
côté non pertinent, un même gain absolu obtenu pour la branche d’exécution du
premier résultat correspondra à un gain relatif le plus élevé, alors que si ce même

7.2 Requête 1 65
gain absolu avait été obtenu pour la branche d’exécution du dernier résultat, son
gain relatif correspondant en aurait été fortement diminué.
La différence de temps absolue étant la donnée la plus pertinente, c’est donc celle-là
qui a été aggrégée afin d’en retirer des statistiques.
7.2 Requête 1
La première requête effectuée est donnée à la figure 7.1. Exprimée en français, celle-
ci signifierait Quels sont le nom et le numéro de téléphonne de toutes les personnes
distinctes ayant publié un article lors de la European Semantic Web Conference de 2009 ?
PREFIX rdf:
PREFIX rdfs:
PREFIX owl:
PREFIX foaf:
PREFIX swrc:
PREFIX swc:
SELECT DISTINCT ?author ?phone
WHERE {
?pub swc:isPartOf .
?pub swc:hasTopic ?topic .
?topic rdfs:label ?topicLabel .
?pub swrc:author ?author .
{ ?author owl:sameAs ?authorAlt } UNION { ?authorAlt owl:sameAs ?author }
?authorAlt foaf:phone ?phone
}
Figure 7.1 – Requête 1 exécutée lors des tests.
Cette requête produit 4 résultats et a été exécutée 40 fois. Son temps moyen d’exé-
cution est de 316 secondes, soit environ 5 minutes. Les résultats bruts sont repris dans
l’annexe A avec pour titre “Requête 1”. Les résultats aggrégés concernant la différence
de temps absolue pour chaque solution sont repris dans à table 7.1.
Solution Moyenne abs. Écart type abs. Maximum abs. Moyenne rel. Maximum rel.
Solution 1 2,4 s. 2,6 s. 13 s. 2,48 % 7,41 %
Solution 2 4,8 s. 3,9 s. 16 s. 2,38 % 11,76 %
Solution 3 10,9 s. 13,0 s. 42 s. 4,05 % 19,75 %
Solution 4 2,9 s. 3,3 s. 12 s. 2,35 % 12,50 %
Table 7.1 – Résultats aggrégés des différences de temps absolues de la requête 1.

7.2 Requête 1 66
Afin d’obtenir une visualisation graphique des résultats, j’ai décidé de les représenter
sous forme de box plots, car je trouve que ce type de graphique donne une très bonne vue
d’ensemble des résultats en une seule figure. Cette représentation est donnée à la figure
7.2.
Figure 7.2 – Résultats de l’interrogation parallèle : différence de temps absolue entre
les résultats des deux méthodes, pour les 4 solutions de la requête 1.
Comme nous pouvons le voir sur cette figure, certaines solutions (e.g. la solution
1) sont la plupart du temps affichées presque directement par la méthode normale dès
qu’elles sont disponibles dans le QLD (hauteur du box très petite), alors que d’autres (e.g.
la solution 3) présentent parfois un temps de “stagnation” dans le QLD beaucoup plus
grand avant d’être affichés par la méthode normale (hauteur du box relativement grande).
Le module d’interrogation parallèle du QLD permet d’économiser cette différence de
temps.
Nous voyons donc que dans le cas de cette première requête, les gains ne sont en
moyenne pas énormes (les gains relatifs sont pour la plupart compris entre 0% et 10%),
mais que de temps en temps ils peuvent être significatifs. Cependant, ce résultat est
propre à la requête 1 et peut différer sensiblement dans le cas d’une autre requête,
comme dans le cas de la deuxième requête décrite à la section 7.3.

7.3 Requête 2 67
7.3 Requête 2
La deuxième requête effectuée est donnée à la figure 7.3. Exprimée en français, celle-
ci signifierait Quels sont les prénoms distincts des personnes vivant dans un pays dans
lequel au moins un membre de l’université de Stanford réside ?
PREFIX rdf:
PREFIX rdfs:
PREFIX owl:
PREFIX foaf:
SELECT DISTINCT ?citizenName WHERE {" +
foaf:member ?stanfordMember .
?stanfordMember foaf:based_near ?country .
?citizen foaf:based_near ?country .
?citizen foaf:firstName ?citizenName .
}
Figure 7.3 – Requête 2 exécutée lors des tests.
Cette requête produit 27 résultats, et a été exécutée 100 fois. Son temps moyen
d’exécution est de 47 secondes, ce qui explique pourquoi j’ai pu me permettre d’effectuer
plus d’exécution de cette requête. Les résultats bruts sont repris dans l’annexe A avec
pour titre “Requête 2”. Les résultats aggrégés concernant la différence de temps absolue
pour chaque solution sont repris dans à table 7.2.
La représentation graphique sous forme de box plots est donnée à la figure 7.4. J’ai
cette fois choisi d’utiliser une disposition horizontale pour les box plots, vu le plus grand
nombre de résultats à représenter.
Comme nous pouvons le constater grâce au tableau de résultats et au graphique, cette
requête offre en moyenne des résultats bien meilleurs que ceux obtenus avec la première
requête. En effet, le temps moyen d’exécution de cette requête étant de 47 secondes et
le gain absolu moyen étant de 30 secondes, l’ajout du module d’interrogation parallèle
offre ici en moyenne une réduction de 58% du temps nécessaire à l’affichage des résultats,
allant même dans le meilleur des cas jusqu’à une réduction de 87% ! Dans le cas de cette
requête, le module d’interrogation parallèle apporte donc une contribution significative.
7.4 Conclusions sur les résultats
Les résultats obtenus grâce aux benchmarks réalisés permettent de tirer plusieurs
conclusions. Tout d’abord, cela confirme que les résultats sont extrêmement variables

7.4 Conclusions sur les résultats 68
Solution Moyenne abs. Écart type abs. Maximum abs. Moyenne rel. Maximum rel.
Solution 1 44,8 s. 6,5 s. 63 s. 80,85 % 87,50 %
Solution 2 39,4 s. 5,5 s. 53 s. 71,56 % 81,82 %
Solution 3 44,4 s. 6,4 s. 63 s. 80,18 % 87,32 %
Solution 4 28,0 s. 6,6 s. 46 s. 50,23 % 64,79 %
Solution 5 39,9 s. 5,9 s. 57 s. 72,01 % 80,36 %
Solution 6 22,4 s. 5,6 s. 40 s. 40,04 % 56,34 %
Solution 7 38,6 s. 6,7 s. 56 s. 69,52 % 77,46 %
Solution 8 28,1 s. 6,8 s. 47 s. 50,41 % 64,38 %
Solution 9 44,8 s. 6,2 s. 62 s. 80,81 % 87,32 %
Solution 10 21,1 s. 5,7 s. 39 s. 37,70 % 54,93 %
Solution 11 28,5 s. 7,5 s. 50 s. 51,14 % 68,49 %
Solution 12 33,1 s. 4,5 s. 41 s. 73,90 % 83,33 %
Solution 13 33,2 s. 4,6 s. 42 s. 74,12 % 80,95 %
Solution 14 28,4 s. 6,5 s. 48 s. 50,76 % 66,20 %
Solution 15 33,1 s. 4,2 s. 42 s. 73,97 % 78,57 %
Solution 16 33,1 s. 4,2 s. 42 s. 73,97 % 78,57 %
Solution 17 33,1 s. 4,2 s. 42 s. 73,97 % 78,57 %
Solution 18 37,8 s. 6,1 s. 56 s. 68,19 % 76,71 %
Solution 19 21,7 s. 5,0 s. 37 s. 38,83 % 50,68 %
Solution 20 27,7 s. 6,2 s. 47 s. 49,59 % 66,20 %
Solution 21 20,8 s. 5,3 s. 37 s. 37,23 % 52,11 %
Solution 22 26,9 s. 5,9 s. 46 s. 48,37 % 64,79 %
Solution 23 13,0 s. 5,1 s. 28 s. 23,10 % 40,82 %
Solution 24 21,1 s. 5,7 s. 39 s. 37,70 % 54,93 %
Solution 25 27,1 s. 5,8 s. 45 s. 48,58 % 63,38 %
Solution 26 24,6 s. 5,2 s. 34 s. 54,96 % 67,57 %
Solution 27 26,1 s. 6,0 s. 44 s. 46,69 % 61,97 %
Moyenne 30,5 s. 5,8 s. 46 s. 57,69 % 69,43 %
Table 7.2 – Résultats aggrégés des différences de temps absolues de la requête 2.
à cause des aléas du réseau Internet, ce qui rend une mesure précise relativement dif-
ficile. En effet, les résultats dépendent de l’état du réseau, des sources interrogées et
d’autres paramètres indépendants de la plateforme d’exécution. Cela confirme égale-
ment que chaque requête s’exécutera selon un plan d’exécution qui lui est propre et que
la récupération des informations se déroule rarement deux fois de la même manière.
De plus, dans un souci de rigueur scientifique, j’ai également relancé ces mêmes
requêtes en désactivant totalement le module d’interrogation parallèle lors de l’exécution
normale de la requête, afin de savoir dans quelle mesure ce module la ralentissait. Dans
les deux cas de requêtes, j’ai observé un léger gain de l’ordre du pourcent, soit une
différence négligeable. Cela confirme donc bien que le temps consommé par le CPU est

7.4 Conclusions sur les résultats 69
minime comparé au temps nécessaire aux déréférencements des URI sur le réseau.
Pour terminer, les résultats démontrent que le module d’interrogation parallèle peut
dans certains cas faire bénéficier l’utilisateur d’une très grosse réduction du temps néces-
saire à l’affichage des résultats. Ce module apporte donc une contribution significative.

7.4 Conclusions sur les résultats 70
Figure 7.4 – Résultats de l’interrogation parallèle : différence de temps absolue entre
les résultats des deux méthodes, pour les 27 solutions de la requête 2.

Chapitre 8
Perspectives futures
Dans le chapitre 7, j’ai présenté les résultats positifs obtenus grâce au module d’in-
terrogation parallèle. Néanmoins, la librairie SQUIN pourrait encore être optimisée da-
vantage. Dans ce chapitre, j’expose trois pistes d’améliorations de la librairie qui permet-
traient une telle optimisation, que ce soit par la réduction du temps de réponse moyen ou
par l’augmentation du nombre de résultats pertinents obtenus en un temps raisonnable.
Contenu
8.1 Adaptation en temps réel du plan d’exécution . . . . . . . . . 71
8.2 Intégration de requêtes vers des moteurs de recherche . . . . 72
8.3 Fusion et nettoyage des données locales . . . . . . . . . . . . . 73
8.1 Adaptation en temps réel du plan d’exécution
La première amélioration consisterait en une adaptation en temps réel du plan d’exé-
cution de la requête. En effet, de par la nature décentralisée du Link Traversal, il est
impossible de connaître à l’avance la totalité des informations qui caractériseront l’exécu-
tion de la requête. En particulier, la librairie n’a aucune idée préalable du temps qui sera
nécessaire à l’exécution de chaque branche/sous-branche d’interrogation des résultats
intermédiaires. L’amélioration pourrait se faire selon deux approches.
La première approche serait d’optimiser en temps réel l’ordre d’exécution des ité-
rateurs de la chaîne. Cela pourrait se faire par exemple en mesurant une donnée telle
71

8.2 Intégration de requêtes vers des moteurs de recherche 72
que le nombre de résultats renvoyés par celui-ci ou le nombre de sous-branches de ré-
sultats qu’il a générées (caractérisant ainsi sa restrictivité). Suite à cela, un algorithme
d’optimisation du plan d’exécution pourrait être investigué.
La deuxième approche serait d’optimiser en temps réel l’ordre d’évaluation des branches
d’exécution de la requête. En effet, on ne peut pas savoir à l’avance si une branche d’exé-
cution correspondant à un résultat intermédiaire nécessitera beaucoup de temps ou non.
Dans le cas où une branche correspondant à un résultat R1 nécessiterait beaucoup de
temps et où les branches correspondant aux résultats R2 et R3 en nécessiteraient peu,
l’exécution de la branche de R1 ferait obtenir à l’utilisateur les résultats de R2 et R3
fort tard. Si en revanche la librairie était prévue pour exécuter plusieurs branches un
parallèle, les branches nécessitant peu de temps pourraient donc rapidement produire
les résultats qu’elles génèrent et laisser alors place à l’exécution de nouvelles branches
d’exécution. Cependant, une telle modification nécessiterait la réécriture d’une bonne
partie de la librairie, car les itérateurs implémentés par celle-ci ne sont pas prévus pour
être interrogés de manière parallélisée.
8.2 Intégration de requêtes vers des moteurs de recherche
La deuxième amélioration consisterait en l’intégration d’une fonctionnalité d’inter-
rogation de moteurs de recherche sémantiques durant l’exécution de la requête. En ef-
fet, dans l’état actuel de la librairie, celle-ci ne commence par interroger que les URI
contenues dans la requête SPARQL et n’interroge par la suite que les nouvelles URI
découvertes durant l’exécution. Dès lors :
– si la requête SPARQL ne contient aucune URI, l’exécution de la librairie ne produit
aucun résultat ;
– dans le cas contraire, l’exécution peut avoir lieu mais peut dans certains cas se ter-
miner rapidement, même si des informations supplémentaires pertinentes existent
sur le Web de données.
C’est pourquoi une interaction avec des moteurs de recherche sémantiques pourrait
s’avérer très utile. D’une part, cela permettrait d’alimenter le QLD avant l’exécution de
la requête avec des données probablement pertinentes dans le contexte de la requête.
D’autre part, on pourrait imaginer de continuer d’interroger ces moteurs de recherche
au fur et à mesure de l’exécution de la requête, en vue de récupérer en permanence des
informations potentiellement pertinentes.

8.3 Fusion et nettoyage des données locales 73
8.3 Fusion et nettoyage des données locales
La troisième et dernière amélioration consisterait en une gestion plus intelligente des
données contenues dans le QLD, afin de profiter pleinement du potentiel du Web sé-
mantique. En effet, au fur et à mesure de l’exécution de la requête, le QLD se remplit
progressivement de données, et l’on constate petit à petit l’apparition de données redon-
dantes. En particulier, OWL définit des liens de type sameAs et refersTo définis à la
section 3.3, permettant d’indiquer que deux ressources du Web de données représentent
en réalité le même concept.
Dans le cas de la librairie SQUIN, celle-ci prend partiellement en compte ces liens du
fait qu’elle réréférence automatiquement les URI renseignées par ces liens. Cependant,
aucune fusion des triplets équivalents n’est effectuée, ce qui a pour conséquence que lors
d’une interrogation du QLD, la librairie n’utilise que partiellement l’information qui y
est contenue. Une fusion des données sur base des liens cités ci-dessus pourrait donc
mener, d’une part, à une augmentation du nombre de résultats produits et, d’autre part,
à une réduction de la taille du QLD (ce qui aurait pour conséquence de réduire son temps
d’interrogation).
De plus, toujours dans une optique de nettoyage des données, il pourrait être intéres-
sant d’y ajouter un module vérifiant l’existance de données contradictoires dans le QLD.
Cela pourrait ensuite être par exemple signalé à l’utilisateur, ou simplement supprimé
du QLD afin d’éviter de fournir des résultats erronés.

Chapitre 9
Conclusions
Le chapitre 5 nous a permis d’analyser la librairie SQUIN, et d’en comprendre les
mécanismes sous-jacents. Nous avons ensuite détaillé au chapitre 6 les pistes de recherche
que j’ai investiguées dans le cadre de ce mémoire afin d’optimiser le temps de réponse
nécessaire à l’obtention des résultats. Parmi ces pistes, les deux premières se sont avérées
infructueuses mais la troisième, qui consistait en la création d’un module d’interrogation
parallèle du QLD, a présenté des résultats fort intéressants. Nous avons alors analysé au
chapitre 7 les résultats obtenus grâce à ce module, et avons prouvé que ce dernier pouvait
apporter une réduction significative du temps de réponse. Pour terminer, nous avons vu
diverses pistes d’améliorations futures que je considère pertinentes en vue d’améliorer
davantage l’efficacité de la librairie, tant en termes de rapidité d’obtention des résultats
qu’en termes de nombre de résultats pertinents obtenus.
Avec la réalisation du module d’interrogation parallèle, nous avons mis en évidence
la grande variabilité des résultats due aux aléas du réseau Internet et à sa dépendance à
un ensemble de facteurs externes propres aux serveurs distants interrogés et à l’état du
réseau. Nous avons également confirmé que le temps consommé pour effectuer l’évalua-
tion locale d’une requête était négligeable face au temps nécessaire aux déréférencements
des URI rencontrées lors de l’exécution de la requête. Dès lors, l’ajout d’une interroga-
tion parallèle du QLD permet dans certains cas de réduire considérablement le temps de
réponse nécessaire à l’affichage des résultats aux yeux de l’utilisateur.
D’un point de vue de développement personnel, la réalisation de ce mémoire m’a ap-
porté un apprentissage très intéressant, complémentaire au cursus d’études poursuivi
jusqu’ici. La difficulté principale que j’ai rencontrée est que l’analyse de la librairie
SQUIN est de loin la partie qui a occupé la majorité de mon temps, car celle-ci est
74

elativement complexe et n’est pas énormément documentée, ce qui ne facilite pas la
tâche. Cette phase d’analyse ne débouchant sur aucune production concrète de code
ou de résultats, cela m’a donné l’impression d’être improductif et de ne pas avancer.
Pourtant, cela est inhérent au travail d’un ingénieur informaticien, et cette expérience
me sera probablement fort utile plus tard dans ma vie professionnelle. J’ai également
appris, dans le cadre de ce mémoire, un ensemble de concepts qui n’avaient pas été vus
durant le cursus d’ingénieur civil informaticien et qui pourtant s’avèreront très utiles
par la suite. De plus, ce mémoire a été une bonne initiation au monde de la recherche.
La plus grande frustration rencontrée a été le fait d’investiguer des pistes de recherche,
pour ensuite se rendre compte qu’elles étaient stériles et ne menaient à rien. Je présume
que c’est pour cela que l’on parle de “chercheurs” et non pas de “trouveurs”.
Nous avons vu au chapitre 2 l’évolution du Web sémantique depuis sa création, et
en particulier la croissance exponentielle du nombre de données publiées sur le Web de
données, comme nous l’avons vu à la section 2.4. Cette croissance étant amenée à aug-
menter dans les années à venir, il deviendra donc de plus en plus important d’optimiser
les méthodes d’interrogation du Web sémantique afin de gérer convenablement l’énorme
quantité de données disponibles, et les approches novatrices décentralisées offriront une
bonne alternative aux méthodes traditionnelles de stockage et d’interrogation tels que les
entrepôts de données. Le Link Traversal et son implémentation SQUIN illustrent parfai-
tement cette tendance de décentralisation et permettent ainsi de maintenir une exécution
rapide des requêtes, en phase avec la croissance permanente du Web de données.
75

Acronymes et abréviations
ADQF Active Discovery Query Federation
BGP Basic Graph Pattern
IRI Internationalized Resource Identifier
LD Linked Data
LDS Linked Dataset(s)
LOD Linked Open Data
OWL Web Ontology Language
SPARQL SPARQL Protocol and RDF Query Language
RDF Ressource Description Framework
RDFS RDF Schema
QF Query Federation
QLD Query-local Dataset (ensemble de données local)
TP Triple Pattern
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
W3C World Wide Web Consortium
WS Web sémantique
76

BIBLIOGRAPHIE 77
Bibliographie
[1] T. Berners-Lee, J. Hendler, O. Lassila, et al. The semantic web. Scientific American,
284(5) :34–43, 2001.
[2] E. Pietriga, C. Bizer, D. Karger, and R. Lee. Fresnel - a browser-independent pre-
sentation vocabulary for RDF. In Proceedings of the Second International Workshop
on Interaction Design and the Semantic Web, pages 158–171. Springer, 2006.
[3] L. Masinter, T. Berners-Lee, and R.T. Fielding. Uniform resource identifier (URI) :
Generic syntax, 2005.
[4] C. Bizer, T. Heath, K. Idehen, and T. Berners-Lee. Linked data on the web
(LDOW2008). In Proceeding of the 17th international conference on World Wide
Web, pages 1265–1266. ACM, 2008.
[5] S. Vansummeren. XML technologies (Université Libre de Bruxelles, INFO-H-509
course), 2011. http://dpt-ti.ulb.ac.be/public/teaching/infoh509.
[6] T. Berners-Lee. Design issues : Linked data., 2009. http://www.w3.org/
DesignIssues/LinkedData.html.
[7] W3C OWL Working Group. OWL Web Ontology Language Reference. W3C Re-
commendation, 2004. http://www.w3.org/TR/owl-ref/".
[8] K. Alexander, R. Cyganiak, M. Hausenblas, and J. Zhao. Describing linked datasets.
In Proceedings of the 2nd Workshop on Linked Data on the Web (LDOW2009), 2009.
[9] C. Bizer, T. Heath, D. Ayers, and Y. Raymond. Linking open data. In Proceedings
of the Poster Session at the 4th European Semantic Web Conference, 2007.
[10] F. Manola and E. Miller. Resource Description Framework Primer. W3C Descrip-
tion, 2004. http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.
[11] O. Hartig and A. Langegger. A database perspective on consuming linked data on
the web, 2012.

BIBLIOGRAPHIE 78
[12] D. Brickley and R.V. Guha. RDF Vocabulary Description Language 1.0 : RDF
Schema. W3C Recommendation, 2004. http://www.w3.org/TR/rdf-schema/.
[13] W3C OWL Working Group. OWL 2 Web Ontology Language Document Overview.
W3C Recommendation, 2009. http://www.w3.org/TR/owl2-overview/.
[14] O. Hartig, C. Bizer, and J.C. Freytag. Executing SPARQL queries over the web of
linked data. The Semantic Web-ISWC 2009, pages 293–309, 2009.
[15] E. Prud’hommeaux and A. Seaborne. SPARQL Query Language for RDF. W3C
Recommendation, 2008. http://www.w3.org/TR/rdf-sparql-query/.
[16] A. Seaborne. ARQ - a SPARQL processor for jena. Obtained through the Internet
[accessed 1/5/2010], 2010. http://jena.sourceforge.net/ARQ/.
[17] J.J. Carroll, C. Bizer, P. Hayes, and P. Stickler. Named graphs. Web Semantics :
Science, Services and Agents on the World Wide Web, 3(4) :247–267, 2005.
[18] J. Umbrich, M. Hausenblas, A. Hogan, A. Polleres, and S. Decker. Towards dataset
dynamics : Change frequency of linked open data sources. 2010.
[19] E. Oren, R. Delbru, M. Catasta, R. Cyganiak, H. Stenzhorn, and G. Tummarello.
Sindice. com : a document-oriented lookup index for open linked data. International
Journal of Metadata, Semantics and Ontologies, 3(1) :37–52, 2008.
[20] G. Cheng and Y. Qu. Searching linked objects with falcons : Approach, implemen-
tation and evaluation. International Journal on Semantic Web and Information
Systems (IJSWIS), 5(3) :49–70, 2009.
[21] B. Quilitz and U. Leser. Querying distributed RDF data sources with SPARQL.
The Semantic Web : Research and Applications, pages 524–538, 2008.
[22] A. Langegger. A flexible architecture for virtual information integration based on
semantic web concepts. PhD thesis, Dissertation, J. Kepler University Linz, 2010.
[23] O. Hartig. Zero-knowledge query planning for an iterator implementation of link
traversal based query execution. In Grigoris Antoniou, Marko Grobelnik, Elena
Simperl, Bijan Parsia, Dimitris Plexousakis, Pieter De Leenheer, and Jeff Pan,
editors, The Semantic Web : Research and Applications, volume 6643 of Lecture
Notes in Computer Science, pages 154–169. Springer Berlin / Heidelberg, 2011.
http://videolectures.net/eswc2011_hartig_zero/.
[24] T. Berners-Lee, Y. Chen, L. Chilton, D. Connolly, R. Dhanaraj, J. Hollenbach,
A. Lerer, and D. Sheets. Tabulator : Exploring and analyzing linked data on the se-
mantic web. In Proceedings of the 3rd International Semantic Web User Interaction
Workshop, 2006.

Annexe A
Résulats complets des tests
effectués
Les résultats bruts des benchmarks effectués sont repris dans les pages qui suivent.
Chaque page de résultats correspond à une solution particulière d’une requête particu-
lière, lesquelles sont précisées en haut à gauche de la page.
79

Requête 1
Solution 1: ( ?author = ) ( ?phone = )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337079855 112 1337079856 113 1 0,88%
1337088148 90 1337088151 93 3 3,23%
1337088570 162 1337088574 166 4 2,41%
1337088852 89 1337088854 91 2 2,20%
1337089102 19 1337089103 20 1 5,00%
1337089513 103 1337089515 105 2 1,90%
1337089863 102 1337089869 108 6 5,56%
1337090429 246 1337090431 248 2 0,81%
1337090720 118 1337090726 124 6 4,84%
1337091037 40 1337091040 43 3 6,98%
1337091612 225 1337091625 238 13 5,46%
1337080194 150 1337080196 152 2 1,32%
1337091890 153 1337091895 158 5 3,16%
1337092202 27 1337092204 29 2 6,90%
1337092707 160 1337092708 161 1 0,62%
1337093336 361 1337093338 363 2 0,55%
1337093716 326 1337093719 329 3 0,91%
1337093873 80 1337093875 82 2 2,44%
1337094344 164 1337094346 166 2 1,20%
1337094722 114 1337094724 116 2 1,72%
1337095308 289 1337095309 290 1 0,34%
1337095574 178 1337095579 183 5 2,73%
1337080561 133 1337080563 135 2 1,48%
1337095834 42 1337095835 43 1 2,33%
1337096297 131 1337096297 131 0 0,00%
1337096652 125 1337096654 127 2 1,57%
1337097250 43 1337097251 44 1 2,27%
1337097667 95 1337097670 98 3 3,06%
1337098042 35 1337098042 35 0 0,00%
1337098851 25 1337098853 27 2 7,41%
1337080913 121 1337080918 126 5 3,97%
1337081459 155 1337081461 157 2 1,27%
1337082052 372 1337082050 370 -­‐2 -­‐0,54%
1337082202 112 1337082205 115 3 2,61%
1337082932 371 1337082930 369 -­‐2 -­‐0,54%
1337083008 29 1337083009 30 1 3,33%
Moyenne 141,58 144,03 2,44 2,48%
Écart type 99,22 99,09 2,56 2,11%
Maximum 372 370 13 7,41%

Requête 1
Solution 2: ( ?author = ) ( ?phone = )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337079957 214 1337079958 215 1 0,47%
1337088275 217 1337088278 220 3 1,36%
1337088696 288 1337088699 291 3 1,03%
1337088954 191 1337088955 192 1 0,52%
1337089234 151 1337089236 153 2 1,31%
1337089597 187 1337089599 189 2 1,06%
1337090011 250 1337090013 252 2 0,79%
1337090525 342 1337090539 356 14 3,93%
1337090929 327 1337090941 339 12 3,54%
1337091220 223 1337091229 232 9 3,88%
1337091642 255 1337091654 267 12 4,49%
1337080234 190 1337080235 191 1 0,52%
1337092017 280 1337092023 286 6 2,10%
1337092434 259 1337092436 261 2 0,77%
1337092884 337 1337092887 340 3 0,88%
1337093140 165 1337093143 168 3 1,79%
1337093420 30 1337093424 34 4 11,76%
1337094005 212 1337094014 221 9 4,07%
1337094455 275 1337094459 279 4 1,43%
1337094827 219 1337094833 225 6 2,67%
1337095232 213 1337095235 216 3 1,39%
1337095704 308 1337095709 313 5 1,60%
1337080689 261 1337080690 262 1 0,38%
1337095983 191 1337095983 191 0 0,00%
1337096356 190 1337096362 196 6 3,06%
1337096755 228 1337096761 234 6 2,56%
1337097049 159 1337097055 165 6 3,64%
1337097482 275 1337097486 279 4 1,43%
1337097849 277 1337097853 281 4 1,42%
1337098084 77 1337098090 83 6 7,23%
1337098562 170 1337098566 174 4 2,30%
1337099027 201 1337099031 205 4 1,95%
1337081065 273 1337081070 278 5 1,80%
1337081498 194 1337081507 203 9 4,43%
1337081926 246 1337081926 246 0 0,00%
1337082459 369 1337082457 367 -­‐2 -­‐0,54%
1337082709 148 1337082714 153 5 3,27%
1337083223 244 1337083239 260 16 6,15%
Moyenne 227,26 232,03 4,76 2,38%
Écart type 69,06 69,62 3,95 2,32%
Maximum 369 367 16 11,76%

Requête 1
Solution 3: ( ?author = ) ( ?phone = )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337079977 234 1337080010 267 33 12,36%
1337088284 226 1337088287 229 3 1,31%
1337088708 300 1337088713 305 5 1,64%
1337088977 214 1337088979 216 2 0,93%
1337089268 185 1337089269 186 1 0,54%
1337089637 227 1337089638 228 1 0,44%
1337090021 260 1337090022 261 1 0,38%
1337090542 359 1337090545 362 3 0,83%
1337090959 357 1337090962 360 3 0,83%
1337091251 254 1337091253 256 2 0,78%
1337091658 271 1337091659 272 1 0,37%
1337080258 214 1337080291 247 33 13,36%
1337092040 303 1337092041 304 1 0,33%
1337092434 259 1337092442 267 8 3,00%
1337092871 324 1337092879 332 8 2,41%
1337093164 189 1337093169 194 5 2,58%
1337093447 57 1337093450 60 3 5,00%
1337094027 234 1337094032 239 5 2,09%
1337094468 288 1337094483 303 15 4,95%
1337094872 264 1337094878 270 6 2,22%
1337095246 227 1337095251 232 5 2,16%
1337095714 318 1337095714 318 0 0,00%
1337080699 271 1337080733 305 34 11,15%
1337096011 219 1337096016 224 5 2,23%
1337096374 208 1337096379 213 5 2,35%
1337096764 237 1337096766 239 2 0,84%
1337097064 174 1337097067 177 3 1,69%
1337097482 275 1337097491 284 9 3,17%
1337097860 288 1337097864 292 4 1,37%
1337098221 214 1337098229 222 8 3,60%
1337098608 216 1337098608 216 0 0,00%
1337099074 248 1337099074 248 0 0,00%
1337081161 369 1337081203 411 42 10,22%
1337081542 238 1337081571 267 29 10,86%
1337081936 256 1337081968 288 32 11,11%
1337082481 391 1337082512 422 31 7,35%
1337082691 130 1337082723 162 32 19,75%
1337083281 302 1337083314 335 33 9,85%
Moyenne 252,63 263,50 10,87 4,05%
Écart type 64,86 68,36 13,06 4,79%
Maximum 391 422 42 19,75%

Requête 1
Solution 4: ( ?author = ) ( ?phone = )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337079922 179 1337079922 179 0 0,00%
1337088375 317 1337088377 319 2 0,63%
1337088673 265 1337088680 272 7 2,57%
1337088796 33 1337088796 33 0 0,00%
1337089240 157 1337089244 161 4 2,48%
1337089693 283 1337089695 285 2 0,70%
1337090086 325 1337090086 325 0 0,00%
1337090206 23 1337090207 24 1 4,17%
1337090776 174 1337090775 173 -­‐1 -­‐0,58%
1337091135 138 1337091138 141 3 2,13%
1337091612 225 1337091616 229 4 1,75%
1337080143 99 1337080144 100 1 1,00%
1337092107 370 1337092110 373 3 0,80%
1337092383 208 1337092386 211 3 1,42%
1337092843 296 1337092846 299 3 1,00%
1337092996 21 1337092999 24 3 12,50%
1337093467 77 1337093467 77 0 0,00%
1337094120 327 1337094131 338 11 3,25%
1337094549 369 1337094544 364 -­‐5 -­‐1,37%
1337094872 264 1337094879 271 7 2,58%
1337095324 305 1337095329 310 5 1,61%
1337095681 285 1337095681 285 0 0,00%
1337080650 222 1337080654 226 4 1,77%
1337095820 28 1337095822 30 2 6,67%
1337096494 328 1337096495 329 1 0,30%
1337096563 36 1337096564 37 1 2,70%
1337097086 196 1337097089 199 3 1,51%
1337097524 317 1337097529 322 5 1,55%
1337097819 247 1337097820 248 1 0,40%
1337098154 147 1337098157 150 3 2,00%
1337098510 118 1337098522 130 12 9,23%
1337098897 71 1337098897 71 0 0,00%
1337080834 42 1337080835 43 1 2,33%
1337081542 238 1337081544 240 2 0,83%
1337081781 101 1337081786 106 5 4,72%
1337082382 292 1337082392 302 10 3,31%
1337082699 138 1337082705 144 6 4,17%
1337083003 24 1337083006 27 3 11,11%
Moyenne 191,71 194,66 2,95 2,35%
Écart type 111,74 112,20 3,34 3,04%
Maximum 370 373 12 12,50%

Requête 2
Solution 1: ( ?name = "Adam" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738885 8 1337738919 42 34 80,95%
1337740196 10 1337740227 41 31 75,61%
1337740240 11 1337740284 55 44 80,00%
1337740300 14 1337740343 57 43 75,44%
1337740353 8 1337740400 55 47 85,45%
1337740414 10 1337740454 50 40 80,00%
1337740466 10 1337740504 48 38 79,17%
1337740518 9 1337740568 59 50 84,75%
1337740580 11 1337740627 58 47 81,03%
1337740640 12 1337740684 56 44 78,57%
1337740696 11 1337740735 50 39 78,00%
1337738932 11 1337738975 54 43 79,63%
1337740747 10 1337740786 49 39 79,59%
1337740799 11 1337740847 59 48 81,36%
1337740858 9 1337740900 51 42 82,35%
1337740912 10 1337740956 54 44 81,48%
1337740969 11 1337741017 59 48 81,36%
1337741029 10 1337741084 65 55 84,62%
1337741095 9 1337741153 67 58 86,57%
1337741168 13 1337741211 56 43 76,79%
1337741223 10 1337741258 45 35 77,78%
1337741294 10 1337741340 56 46 82,14%
1337738987 10 1337739028 51 41 80,39%
1337741354 10 1337741415 71 61 85,92%
1337741429 10 1337741492 73 63 86,30%
1337741502 7 1337741551 56 49 87,50%
1337741563 11 1337741606 54 43 79,63%
1337741619 11 1337741670 62 51 82,26%
1337741682 10 1337741732 60 50 83,33%
1337741746 12 1337741790 56 44 78,57%
1337741801 9 1337741844 52 43 82,69%
1337741856 10 1337741903 57 47 82,46%
1337741915 10 1337741966 61 51 83,61%
1337739871 20 1337739902 51 31 60,78%
1337741978 10 1337742029 61 51 83,61%
1337742040 10 1337742084 54 44 81,48%
1337742096 10 1337742141 55 45 81,82%
1337742154 11 1337742195 52 41 78,85%
1337742208 11 1337742254 57 46 80,70%
1337742265 10 1337742316 61 51 83,61%
1337742328 10 1337742376 58 48 82,76%
1337742388 11 1337742431 54 43 79,63%
1337742443 10 1337742482 49 39 79,59%
1337742498 11 1337742542 55 44 80,00%
1337739922 11 1337739959 48 37 77,08%
1337742553 10 1337742596 53 43 81,13%
1337739971 10 1337740018 57 47 82,46%
1337740031 10 1337740076 55 45 81,82%
1337740088 11 1337740132 55 44 80,00%
1337740143 9 1337740184 50 41 82,00%
Moyenne 10,46 55,28 44,82 80,85%
Écart type 1,80 6,18 6,47 3,96%
Maximum 20 73 63 87,50%

Requête 2
Solution 2: ( ?name = "Clement" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738894 17 1337738919 42 25 59,52%
1337740201 15 1337740227 41 26 63,41%
1337740245 16 1337740284 55 39 70,91%
1337740304 18 1337740343 57 39 68,42%
1337740355 10 1337740400 55 45 81,82%
1337740420 16 1337740454 50 34 68,00%
1337740470 14 1337740504 48 34 70,83%
1337740523 14 1337740568 59 45 76,27%
1337740585 16 1337740627 58 42 72,41%
1337740644 16 1337740684 56 40 71,43%
1337740700 15 1337740735 50 35 70,00%
1337738936 15 1337738975 54 39 72,22%
1337740751 14 1337740786 49 35 71,43%
1337740809 21 1337740847 59 38 64,41%
1337740865 16 1337740900 51 35 68,63%
1337740916 14 1337740956 54 40 74,07%
1337740973 15 1337741017 59 44 74,58%
1337741037 18 1337741084 65 47 72,31%
1337741102 16 1337741153 67 51 76,12%
1337741171 16 1337741211 56 40 71,43%
1337741230 17 1337741258 45 28 62,22%
1337741303 19 1337741340 56 37 66,07%
1337738992 15 1337739028 51 36 70,59%
1337741359 15 1337741396 52 37 71,15%
1337741439 20 1337741492 73 53 72,60%
1337741507 12 1337741551 56 44 78,57%
1337741568 16 1337741606 54 38 70,37%
1337741625 17 1337741670 62 45 72,58%
1337741686 14 1337741731 59 45 76,27%
1337741750 16 1337741790 56 40 71,43%
1337741805 13 1337741844 52 39 75,00%
1337741862 16 1337741903 57 41 71,93%
1337741920 15 1337741966 61 46 75,41%
1337739866 15 1337739902 51 36 70,59%
1337741983 15 1337742029 61 46 75,41%
1337742046 16 1337742084 54 38 70,37%
1337742101 15 1337742141 55 40 72,73%
1337742159 16 1337742195 52 36 69,23%
1337742214 17 1337742254 57 40 70,18%
1337742269 14 1337742316 61 47 77,05%
1337742332 14 1337742376 58 44 75,86%
1337742392 15 1337742431 54 39 72,22%
1337742447 14 1337742482 49 35 71,43%
1337742503 16 1337742542 55 39 70,91%
1337739926 15 1337739959 48 33 68,75%
1337742558 15 1337742596 53 38 71,70%
1337739977 16 1337740018 57 41 71,93%
1337740036 15 1337740076 55 40 72,73%
1337740092 15 1337740132 55 40 72,73%
1337740148 14 1337740184 50 36 72,00%
Moyenne 15,48 54,88 39,40 71,56%
Écart type 1,81 5,75 5,51 3,96%
Maximum 21 73 53 81,82%

Requête 2
Solution 3: ( ?name = "Collin" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738886 9 1337738919 42 33 78,57%
1337740196 10 1337740227 41 31 75,61%
1337740241 12 1337740284 55 43 78,18%
1337740299 13 1337740343 57 44 77,19%
1337740353 8 1337740400 55 47 85,45%
1337740414 10 1337740454 50 40 80,00%
1337740465 9 1337740504 48 39 81,25%
1337740519 10 1337740568 59 49 83,05%
1337740581 12 1337740627 58 46 79,31%
1337740639 11 1337740684 56 45 80,36%
1337740697 12 1337740735 50 38 76,00%
1337738931 10 1337738975 54 44 81,48%
1337740746 9 1337740786 49 40 81,63%
1337740800 12 1337740847 59 47 79,66%
1337740860 11 1337740900 51 40 78,43%
1337740912 10 1337740956 54 44 81,48%
1337740968 10 1337741017 59 49 83,05%
1337741029 10 1337741084 65 55 84,62%
1337741096 10 1337741153 67 57 85,07%
1337741181 26 1337741211 56 30 53,57%
1337741222 9 1337741258 45 36 80,00%
1337741296 12 1337741340 56 44 78,57%
1337738987 10 1337739028 51 41 80,39%
1337741353 9 1337741415 71 62 87,32%
1337741429 10 1337741492 73 63 86,30%
1337741503 8 1337741551 56 48 85,71%
1337741565 13 1337741606 54 41 75,93%
1337741626 18 1337741670 62 44 70,97%
1337741682 10 1337741732 60 50 83,33%
1337741745 11 1337741790 56 45 80,36%
1337741802 10 1337741844 52 42 80,77%
1337741856 10 1337741903 57 47 82,46%
1337741921 16 1337741966 61 45 73,77%
1337739862 11 1337739902 51 40 78,43%
1337741980 12 1337742029 61 49 80,33%
1337742041 11 1337742084 54 43 79,63%
1337742095 9 1337742141 55 46 83,64%
1337742153 10 1337742195 52 42 80,77%
1337742207 10 1337742254 57 47 82,46%
1337742264 9 1337742316 61 52 85,25%
1337742328 10 1337742376 58 48 82,76%
1337742388 11 1337742431 54 43 79,63%
1337742442 9 1337742482 49 40 81,63%
1337742497 10 1337742542 55 45 81,82%
1337739921 10 1337739959 48 38 79,17%
1337742554 11 1337742596 53 42 79,25%
1337739971 10 1337740018 57 47 82,46%
1337740031 10 1337740076 55 45 81,82%
1337740088 11 1337740132 55 44 80,00%
1337740144 10 1337740184 50 40 80,00%
Moyenne 10,88 55,28 44,40 80,18%
Écart type 2,80 6,18 6,40 4,97%
Maximum 26 73 63 87,32%

Requête 2
Solution 4: ( ?name = "Csongor" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738896 19 1337738919 42 23 54,76%
1337740209 23 1337740227 41 18 43,90%
1337740259 30 1337740284 55 25 45,45%
1337740317 31 1337740343 57 26 45,61%
1337740366 21 1337740400 55 34 61,82%
1337740430 26 1337740454 50 24 48,00%
1337740480 24 1337740504 48 24 50,00%
1337740533 24 1337740568 59 35 59,32%
1337740596 27 1337740627 58 31 53,45%
1337740655 27 1337740684 56 29 51,79%
1337740712 27 1337740735 50 23 46,00%
1337738948 27 1337738975 54 27 50,00%
1337740759 22 1337740786 49 27 55,10%
1337740815 27 1337740847 59 32 54,24%
1337740874 25 1337740900 51 26 50,98%
1337740938 36 1337740956 54 18 33,33%
1337740987 29 1337741017 59 30 50,85%
1337741044 25 1337741084 65 40 61,54%
1337741117 31 1337741153 67 36 53,73%
1337741183 28 1337741211 56 28 50,00%
1337741240 27 1337741258 45 18 40,00%
1337741312 28 1337741340 56 28 50,00%
1337739002 25 1337739028 51 26 50,98%
1337741369 25 1337741415 71 46 64,79%
1337741446 27 1337741492 73 46 63,01%
1337741519 24 1337741551 56 32 57,14%
1337741581 29 1337741606 54 25 46,30%
1337741656 48 1337741670 62 14 22,58%
1337741700 28 1337741732 60 32 53,33%
1337741761 27 1337741790 56 29 51,79%
1337741821 29 1337741844 52 23 44,23%
1337741877 31 1337741903 57 26 45,61%
1337741930 25 1337741966 61 36 59,02%
1337739880 29 1337739902 51 22 43,14%
1337741995 27 1337742029 61 34 55,74%
1337742056 26 1337742084 54 28 51,85%
1337742113 27 1337742141 55 28 50,91%
1337742181 38 1337742195 52 14 26,92%
1337742226 29 1337742254 57 28 49,12%
1337742283 28 1337742316 61 33 54,10%
1337742343 25 1337742376 58 33 56,90%
1337742400 23 1337742431 54 31 57,41%
1337742457 24 1337742482 49 25 51,02%
1337742513 26 1337742542 55 29 52,73%
1337739939 28 1337739959 48 20 41,67%
1337742570 27 1337742596 53 26 49,06%
1337739987 26 1337740018 57 31 54,39%
1337740046 25 1337740076 55 30 54,55%
1337740107 30 1337740132 55 25 45,45%
1337740160 26 1337740184 50 24 48,00%
Moyenne 27,32 55,28 27,96 50,23%
Écart type 4,41 6,18 6,62 8,03%
Maximum 48 73 46 64,79%

Requête 2
Solution: ( ?name = "Daniel" )
Informations sur l'écart différentiel absolu (absolute delta time)
Moyenne: 39,94 secondes
Ecart type: 5,905410871 secondes
Maximum: 57 secondes
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738888 11 1337738919 42 31 73,81%
1337740201 15 1337740227 41 26 63,41%
1337740245 16 1337740284 55 39 70,91%
1337740306 20 1337740343 57 37 64,91%
1337740361 16 1337740400 55 39 70,91%
1337740420 16 1337740454 50 34 68,00%
1337740470 14 1337740504 48 34 70,83%
1337740525 16 1337740568 59 43 72,88%
1337740585 16 1337740627 58 42 72,41%
1337740644 16 1337740684 56 40 71,43%
1337740700 15 1337740735 50 35 70,00%
1337738935 14 1337738975 54 40 74,07%
1337740752 15 1337740786 49 34 69,39%
1337740805 17 1337740847 59 42 71,19%
1337740864 15 1337740900 51 36 70,59%
1337740918 16 1337740956 54 38 70,37%
1337740974 16 1337741017 59 43 72,88%
1337741035 16 1337741084 65 49 75,38%
1337741104 18 1337741153 67 49 73,13%
1337741169 14 1337741211 56 42 75,00%
1337741227 14 1337741258 45 31 68,89%
1337741301 17 1337741340 56 39 69,64%
1337738991 14 1337739028 51 37 72,55%
1337741359 15 1337741415 71 56 78,87%
1337741435 16 1337741492 73 57 78,08%
1337741506 11 1337741551 56 45 80,36%
1337741567 15 1337741606 54 39 72,22%
1337741624 16 1337741670 62 46 74,19%
1337741686 14 1337741732 60 46 76,67%
1337741750 16 1337741790 56 40 71,43%
1337741811 19 1337741844 52 33 63,46%
1337741861 15 1337741903 57 42 73,68%
1337741919 14 1337741966 61 47 77,05%
1337739868 17 1337739902 51 34 66,67%
1337741984 16 1337742029 61 45 73,77%
1337742046 16 1337742084 54 38 70,37%
1337742101 15 1337742141 55 40 72,73%
1337742158 15 1337742195 52 37 71,15%
1337742212 15 1337742254 57 42 73,68%
1337742270 15 1337742316 61 46 75,41%
1337742332 14 1337742376 58 44 75,86%
1337742392 15 1337742431 54 39 72,22%
1337742446 13 1337742482 49 36 73,47%
1337742503 16 1337742542 55 39 70,91%
1337739927 16 1337739959 48 32 66,67%
1337742557 14 1337742596 53 39 73,58%
1337739978 17 1337740018 57 40 70,18%
1337740035 14 1337740076 55 41 74,55%
1337740093 16 1337740132 55 39 70,91%
1337740149 15 1337740184 50 35 70,00%
Moyenne 15,34 55,28 39,94 72,01%
Écart type 1,59 6,18 5,91 3,51%
Maximum 20 73 57 80,36%

Requête 2
Solution 6: ( ?name = "Das" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738902 25 1337738919 42 17 40,48%
1337740213 27 1337740228 42 15 35,71%
1337740263 34 1337740284 55 21 38,18%
1337740325 39 1337740343 57 18 31,58%
1337740374 29 1337740400 55 26 47,27%
1337740438 34 1337740454 50 16 32,00%
1337740485 29 1337740504 48 19 39,58%
1337740540 31 1337740568 59 28 47,46%
1337740603 34 1337740627 58 24 41,38%
1337740661 33 1337740684 56 23 41,07%
1337740718 33 1337740735 50 17 34,00%
1337738954 33 1337738975 54 21 38,89%
1337740762 25 1337740786 49 24 48,98%
1337740822 34 1337740847 59 25 42,37%
1337740878 29 1337740900 51 22 43,14%
1337740932 30 1337740956 54 24 44,44%
1337740995 37 1337741017 59 22 37,29%
1337741051 32 1337741084 65 33 50,77%
1337741122 36 1337741153 67 31 46,27%
1337741191 36 1337741211 56 20 35,71%
1337741245 32 1337741258 45 13 28,89%
1337741321 37 1337741340 56 19 33,93%
1337739011 34 1337739028 51 17 33,33%
1337741375 31 1337741415 71 40 56,34%
1337741453 34 1337741492 73 39 53,42%
1337741524 29 1337741551 56 27 48,21%
1337741586 34 1337741606 54 20 37,04%
1337741644 36 1337741670 62 26 41,94%
1337741705 33 1337741732 60 27 45,00%
1337741770 36 1337741790 56 20 35,71%
1337741828 36 1337741844 52 16 30,77%
1337741881 35 1337741903 57 22 38,60%
1337741939 34 1337741966 61 27 44,26%
1337739886 35 1337739902 51 16 31,37%
1337742002 34 1337742029 61 27 44,26%
1337742062 32 1337742084 54 22 40,74%
1337742118 32 1337742141 55 23 41,82%
1337742176 33 1337742195 52 19 36,54%
1337742232 35 1337742254 57 22 38,60%
1337742293 38 1337742316 61 23 37,70%
1337742350 32 1337742376 58 26 44,83%
1337742405 28 1337742431 54 26 48,15%
1337742465 32 1337742482 49 17 34,69%
1337742523 36 1337742542 55 19 34,55%
1337739947 36 1337739959 48 12 25,00%
1337742575 32 1337742596 53 21 39,62%
1337739993 32 1337740018 57 25 43,86%
1337740053 32 1337740076 55 23 41,82%
1337740113 36 1337740132 55 19 34,55%
1337740164 30 1337740184 50 20 40,00%
Moyenne 32,92 55,30 22,38 40,04%
Écart type 3,11 6,14 5,64 6,42%
Maximum 39 73 40 56,34%

Requête 2
Solution 7: ( ?name = "Deborah" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738889 12 1337738919 42 30 71,43%
1337740202 16 1337740227 41 25 60,98%
1337740246 17 1337740284 55 38 69,09%
1337740305 19 1337740343 57 38 66,67%
1337740361 16 1337740400 55 39 70,91%
1337740419 15 1337740454 50 35 70,00%
1337740471 15 1337740504 48 33 68,75%
1337740523 14 1337740568 59 45 76,27%
1337740586 17 1337740627 58 41 70,69%
1337740644 16 1337740684 56 40 71,43%
1337740701 16 1337740735 50 34 68,00%
1337738938 17 1337738975 54 37 68,52%
1337740753 16 1337740786 49 33 67,35%
1337740804 16 1337740847 59 43 72,88%
1337740865 16 1337740900 51 35 68,63%
1337740917 15 1337740956 54 39 72,22%
1337740975 17 1337741017 59 42 71,19%
1337741039 20 1337741084 65 45 69,23%
1337741103 17 1337741153 67 50 74,63%
1337741171 16 1337741211 56 40 71,43%
1337741227 14 1337741258 45 31 68,89%
1337741302 18 1337741340 56 38 67,86%
1337738993 16 1337739028 51 35 68,63%
1337741360 16 1337741415 71 55 77,46%
1337741436 17 1337741492 73 56 76,71%
1337741509 14 1337741551 56 42 75,00%
1337741574 22 1337741606 54 32 59,26%
1337741625 17 1337741670 62 45 72,58%
1337741691 19 1337741732 60 41 68,33%
1337741751 17 1337741790 56 39 69,64%
1337741805 13 1337741844 52 39 75,00%
1337741862 16 1337741903 57 41 71,93%
1337741920 15 1337741966 61 46 75,41%
1337739870 19 1337739902 51 32 62,75%
1337741987 19 1337742029 61 42 68,85%
1337742047 17 1337742084 54 37 68,52%
1337742103 17 1337742141 55 38 69,09%
1337742160 17 1337742195 52 35 67,31%
1337742213 16 1337742254 57 41 71,93%
1337742270 15 1337742316 61 46 75,41%
1337742334 16 1337742376 58 42 72,41%
1337742391 14 1337742431 54 40 74,07%
1337742454 21 1337742482 49 28 57,14%
1337742503 16 1337742542 55 39 70,91%
1337739943 32 1337739959 48 16 33,33%
1337742558 15 1337742596 53 38 71,70%
1337739976 15 1337740018 57 42 73,68%
1337740037 16 1337740076 55 39 70,91%
1337740093 16 1337740132 55 39 70,91%
1337740149 15 1337740184 50 35 70,00%
Moyenne 16,66 55,28 38,62 69,52%
Écart type 2,90 6,18 6,74 6,62%
Maximum 32 73 56 77,46%

Requête 2
Solution 8: ( ?name = "Georgia" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738897 20 1337738919 42 22 52,38%
1337740209 23 1337740227 41 18 43,90%
1337740259 30 1337740284 55 25 45,45%
1337740317 31 1337740343 57 26 45,61%
1337740366 21 1337740400 55 34 61,82%
1337740430 26 1337740454 50 24 48,00%
1337740481 25 1337740504 48 23 47,92%
1337740534 25 1337740568 59 34 57,63%
1337740595 26 1337740627 58 32 55,17%
1337740653 25 1337740684 56 31 55,36%
1337740711 26 1337740735 50 24 48,00%
1337738947 26 1337738975 54 28 51,85%
1337740759 22 1337740786 49 27 55,10%
1337740814 26 1337740847 59 33 55,93%
1337740874 25 1337740900 51 26 50,98%
1337740930 28 1337740956 54 26 48,15%
1337740986 28 1337741017 59 31 52,54%
1337741045 26 1337741084 65 39 60,00%
1337741114 28 1337741153 67 39 58,21%
1337741184 29 1337741211 56 27 48,21%
1337741249 36 1337741258 45 9 20,00%
1337741312 28 1337741340 56 28 50,00%
1337739020 43 1337739028 51 8 15,69%
1337741379 35 1337741415 71 36 50,70%
1337741445 26 1337741492 73 47 64,38%
1337741519 24 1337741551 56 32 57,14%
1337741580 28 1337741606 54 26 48,15%
1337741640 32 1337741670 62 30 48,39%
1337741700 28 1337741732 60 32 53,33%
1337741759 25 1337741790 56 31 55,36%
1337741821 29 1337741844 52 23 44,23%
1337741877 31 1337741903 57 26 45,61%
1337741929 24 1337741966 61 37 60,66%
1337739880 29 1337739902 51 22 43,14%
1337741995 27 1337742029 61 34 55,74%
1337742055 25 1337742084 54 29 53,70%
1337742112 26 1337742141 55 29 52,73%
1337742173 30 1337742195 52 22 42,31%
1337742224 27 1337742254 57 30 52,63%
1337742282 27 1337742316 61 34 55,74%
1337742343 25 1337742376 58 33 56,90%
1337742400 23 1337742431 54 31 57,41%
1337742465 32 1337742482 49 17 34,69%
1337742513 26 1337742542 55 29 52,73%
1337739937 26 1337739959 48 22 45,83%
1337742568 25 1337742596 53 28 52,83%
1337739988 27 1337740018 57 30 52,63%
1337740047 26 1337740076 55 29 52,73%
1337740104 27 1337740132 55 28 50,91%
1337740158 24 1337740184 50 26 52,00%
Moyenne 27,14 55,28 28,14 50,41%
Écart type 3,86 6,18 6,83 8,72%
Maximum 43 73 47 64,38%

Requête 2
Solution 9: ( ?name = "Hamid" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738885 8 1337738919 42 34 80,95%
1337740197 11 1337740227 41 30 73,17%
1337740241 12 1337740284 55 43 78,18%
1337740301 15 1337740343 57 42 73,68%
1337740354 9 1337740400 55 46 83,64%
1337740415 11 1337740454 50 39 78,00%
1337740465 9 1337740504 48 39 81,25%
1337740518 9 1337740568 59 50 84,75%
1337740581 12 1337740627 58 46 79,31%
1337740639 11 1337740684 56 45 80,36%
1337740695 10 1337740735 50 40 80,00%
1337738932 11 1337738975 54 43 79,63%
1337740747 10 1337740786 49 39 79,59%
1337740799 11 1337740847 59 48 81,36%
1337740862 13 1337740900 51 38 74,51%
1337740912 10 1337740956 54 44 81,48%
1337740967 9 1337741017 59 50 84,75%
1337741029 10 1337741084 65 55 84,62%
1337741096 10 1337741153 67 57 85,07%
1337741169 14 1337741211 56 42 75,00%
1337741224 11 1337741258 45 34 75,56%
1337741294 10 1337741340 56 46 82,14%
1337738986 9 1337739028 51 42 82,35%
1337741353 9 1337741415 71 62 87,32%
1337741431 12 1337741492 73 61 83,56%
1337741504 9 1337741551 56 47 83,93%
1337741564 12 1337741606 54 42 77,78%
1337741618 10 1337741670 62 52 83,87%
1337741682 10 1337741732 60 50 83,33%
1337741745 11 1337741790 56 45 80,36%
1337741801 9 1337741844 52 43 82,69%
1337741856 10 1337741903 57 47 82,46%
1337741916 11 1337741966 61 50 81,97%
1337739862 11 1337739902 51 40 78,43%
1337741980 12 1337742029 61 49 80,33%
1337742040 10 1337742084 54 44 81,48%
1337742096 10 1337742141 55 45 81,82%
1337742154 11 1337742195 52 41 78,85%
1337742209 12 1337742254 57 45 78,95%
1337742265 10 1337742316 61 51 83,61%
1337742328 10 1337742376 58 48 82,76%
1337742388 11 1337742431 54 43 79,63%
1337742442 9 1337742482 49 40 81,63%
1337742498 11 1337742542 55 44 80,00%
1337739921 10 1337739959 48 38 79,17%
1337742552 9 1337742596 53 44 83,02%
1337739971 10 1337740018 57 47 82,46%
1337740031 10 1337740076 55 45 81,82%
1337740088 11 1337740132 55 44 80,00%
1337740144 10 1337740184 50 40 80,00%
Moyenne 10,50 55,28 44,78 80,81%
Écart type 1,34 6,18 6,17 3,00%
Maximum 15 73 62 87,32%

Requête 2
Solution 10: ( ?name = "Hassanpour" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738902 25 1337738919 42 17 40,48%
1337740212 26 1337740228 42 16 38,10%
1337740265 36 1337740284 55 19 34,55%
1337740325 39 1337740343 57 18 31,58%
1337740375 30 1337740400 55 25 45,45%
1337740436 32 1337740454 50 18 36,00%
1337740489 33 1337740504 48 15 31,25%
1337740543 34 1337740568 59 25 42,37%
1337740603 34 1337740627 58 24 41,38%
1337740673 45 1337740684 56 11 19,64%
1337740720 35 1337740735 50 15 30,00%
1337738954 33 1337738975 54 21 38,89%
1337740762 25 1337740786 49 24 48,98%
1337740824 36 1337740847 59 23 38,98%
1337740880 31 1337740900 51 20 39,22%
1337740934 32 1337740956 54 22 40,74%
1337740996 38 1337741017 59 21 35,59%
1337741053 34 1337741084 65 31 47,69%
1337741122 36 1337741153 67 31 46,27%
1337741189 34 1337741211 56 22 39,29%
1337741245 32 1337741258 45 13 28,89%
1337741321 37 1337741340 56 19 33,93%
1337739012 35 1337739028 51 16 31,37%
1337741376 32 1337741415 71 39 54,93%
1337741457 38 1337741492 73 35 47,95%
1337741527 32 1337741551 56 24 42,86%
1337741588 36 1337741606 54 18 33,33%
1337741642 34 1337741670 62 28 45,16%
1337741706 34 1337741732 60 26 43,33%
1337741772 38 1337741790 56 18 32,14%
1337741829 37 1337741844 52 15 28,85%
1337741882 36 1337741903 57 21 36,84%
1337741939 34 1337741966 61 27 44,26%
1337739889 38 1337739902 51 13 25,49%
1337742002 34 1337742029 61 27 44,26%
1337742071 41 1337742084 54 13 24,07%
1337742118 32 1337742141 55 23 41,82%
1337742177 34 1337742195 52 18 34,62%
1337742232 35 1337742254 57 22 38,60%
1337742291 36 1337742316 61 25 40,98%
1337742352 34 1337742376 58 24 41,38%
1337742409 32 1337742431 54 22 40,74%
1337742464 31 1337742482 49 18 36,73%
1337742523 36 1337742542 55 19 34,55%
1337739943 32 1337739959 48 16 33,33%
1337742575 32 1337742596 53 21 39,62%
1337739997 36 1337740018 57 21 36,84%
1337740055 34 1337740076 55 21 38,18%
1337740117 40 1337740132 55 15 27,27%
1337740166 32 1337740184 50 18 36,00%
Moyenne 34,24 55,30 21,06 37,70%
Écart type 3,63 6,14 5,65 6,86%
Maximum 45 73 39 54,93%

Requête 2
Solution 11: ( ?name = "Jure" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738896 19 1337738919 42 23 54,76%
1337740209 23 1337740227 41 18 43,90%
1337740256 27 1337740284 55 28 50,91%
1337740315 29 1337740343 57 28 49,12%
1337740366 21 1337740400 55 34 61,82%
1337740429 25 1337740454 50 25 50,00%
1337740478 22 1337740504 48 26 54,17%
1337740549 40 1337740568 59 19 32,20%
1337740594 25 1337740627 58 33 56,90%
1337740654 26 1337740684 56 30 53,57%
1337740711 26 1337740735 50 24 48,00%
1337738946 25 1337738975 54 29 53,70%
1337740757 20 1337740786 49 29 59,18%
1337740813 25 1337740847 59 34 57,63%
1337740887 38 1337740900 51 13 25,49%
1337740926 24 1337740956 54 30 55,56%
1337740984 26 1337741017 59 33 55,93%
1337741045 26 1337741084 65 39 60,00%
1337741111 25 1337741153 67 42 62,69%
1337741179 24 1337741211 56 32 57,14%
1337741236 23 1337741258 45 22 48,89%
1337741312 28 1337741340 56 28 50,00%
1337739003 26 1337739028 51 25 49,02%
1337741372 28 1337741415 71 43 60,56%
1337741442 23 1337741492 73 50 68,49%
1337741518 23 1337741551 56 33 58,93%
1337741579 27 1337741606 54 27 50,00%
1337741637 29 1337741670 62 33 53,23%
1337741698 26 1337741732 60 34 56,67%
1337741784 50 1337741790 56 6 10,71%
1337741821 29 1337741844 52 23 44,23%
1337741876 30 1337741903 57 27 47,37%
1337741929 24 1337741966 61 37 60,66%
1337739882 31 1337739902 51 20 39,22%
1337741992 24 1337742029 61 37 60,66%
1337742054 24 1337742084 54 30 55,56%
1337742114 28 1337742141 55 27 49,09%
1337742170 27 1337742195 52 25 48,08%
1337742224 27 1337742254 57 30 52,63%
1337742282 27 1337742316 61 34 55,74%
1337742357 39 1337742376 58 19 32,76%
1337742404 27 1337742431 54 27 50,00%
1337742460 27 1337742482 49 22 44,90%
1337742513 26 1337742542 55 29 52,73%
1337739937 26 1337739959 48 22 45,83%
1337742568 25 1337742596 53 28 52,83%
1337739986 25 1337740018 57 32 56,14%
1337740046 25 1337740076 55 30 54,55%
1337740103 26 1337740132 55 29 52,73%
1337740158 24 1337740184 50 26 52,00%
Moyenne 26,80 55,28 28,48 51,14%
Écart type 5,22 6,18 7,46 9,78%
Maximum 50 73 50 68,49%

Requête 2
Solution 12: ( ?name = "Li" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738888 11 1337738914 37 26 70,27%
1337740197 11 1337740222 36 25 69,44%
1337740242 13 1337740275 46 33 71,74%
1337740301 15 1337740340 54 39 72,22%
1337740354 9 1337740384 39 30 76,92%
1337740415 11 1337740444 40 29 72,50%
1337740467 11 1337740496 40 29 72,50%
1337740520 11 1337740555 46 35 76,09%
1337740582 13 1337740612 43 30 69,77%
1337740640 12 1337740674 46 34 73,91%
1337740697 12 1337740728 43 31 72,09%
1337738933 12 1337738964 43 31 72,09%
1337740749 12 1337740767 30 18 60,00%
1337740800 12 1337740832 44 32 72,73%
1337740859 10 1337740888 39 29 74,36%
1337740913 11 1337740949 47 36 76,60%
1337740969 11 1337741008 50 39 78,00%
1337741029 10 1337741062 43 33 76,74%
1337741096 10 1337741136 50 40 80,00%
1337741172 17 1337741199 44 27 61,36%
1337741225 12 1337741253 40 28 70,00%
1337741295 11 1337741333 49 38 77,55%
1337738987 10 1337739020 43 33 76,74%
1337741356 12 1337741387 43 31 72,09%
1337741431 12 1337741465 46 34 73,91%
1337741502 7 1337741537 42 35 83,33%
1337741565 13 1337741597 45 32 71,11%
1337741620 12 1337741660 52 40 76,92%
1337741685 13 1337741720 48 35 72,92%
1337741745 11 1337741781 47 36 76,60%
1337741802 10 1337741838 46 36 78,26%
1337741858 12 1337741891 45 33 73,33%
1337741916 11 1337741950 45 34 75,56%
1337739862 11 1337739898 47 36 76,60%
1337741982 14 1337742022 54 40 74,07%
1337742042 12 1337742076 46 34 73,91%
1337742098 12 1337742133 47 35 74,47%
1337742154 11 1337742187 44 33 75,00%
1337742209 12 1337742247 50 38 76,00%
1337742265 10 1337742302 47 37 78,72%
1337742330 12 1337742368 50 38 76,00%
1337742388 11 1337742421 44 33 75,00%
1337742443 10 1337742476 43 33 76,74%
1337742498 11 1337742532 45 34 75,56%
1337739923 12 1337739950 39 27 69,23%
1337742555 12 1337742583 40 28 70,00%
1337739977 16 1337740007 46 30 65,22%
1337740032 11 1337740065 44 33 75,00%
1337740088 11 1337740129 52 41 78,85%
1337740144 10 1337740177 43 33 76,74%
Moyenne 11,56 44,64 33,08 73,90%
Écart type 1,63 4,58 4,47 4,23%
Maximum 17 54 41 83,33%

Requête 2
Solution 13: ( ?name = "Mark" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738886 9 1337738914 37 28 75,68%
1337740197 11 1337740222 36 25 69,44%
1337740242 13 1337740275 46 33 71,74%
1337740301 15 1337740340 54 39 72,22%
1337740354 9 1337740384 39 30 76,92%
1337740415 11 1337740444 40 29 72,50%
1337740470 14 1337740496 40 26 65,00%
1337740519 10 1337740555 46 36 78,26%
1337740582 13 1337740612 43 30 69,77%
1337740639 11 1337740674 46 35 76,09%
1337740697 12 1337740728 43 31 72,09%
1337738931 10 1337738964 43 33 76,74%
1337740747 10 1337740767 30 20 66,67%
1337740801 13 1337740832 44 31 70,45%
1337740861 12 1337740888 39 27 69,23%
1337740913 11 1337740949 47 36 76,60%
1337740970 12 1337741008 50 38 76,00%
1337741029 10 1337741062 43 33 76,74%
1337741096 10 1337741136 50 40 80,00%
1337741176 21 1337741199 44 23 52,27%
1337741222 9 1337741253 40 31 77,50%
1337741296 12 1337741333 49 37 75,51%
1337738988 11 1337739020 43 32 74,42%
1337741354 10 1337741387 43 33 76,74%
1337741430 11 1337741465 46 35 76,09%
1337741503 8 1337741537 42 34 80,95%
1337741564 12 1337741597 45 33 73,33%
1337741621 13 1337741660 52 39 75,00%
1337741683 11 1337741720 48 37 77,08%
1337741746 12 1337741781 47 35 74,47%
1337741805 13 1337741838 46 33 71,74%
1337741858 12 1337741891 45 33 73,33%
1337741915 10 1337741950 45 35 77,78%
1337739869 18 1337739898 47 29 61,70%
1337741980 12 1337742022 54 42 77,78%
1337742041 11 1337742076 46 35 76,09%
1337742097 11 1337742133 47 36 76,60%
1337742155 12 1337742187 44 32 72,73%
1337742209 12 1337742247 50 38 76,00%
1337742266 11 1337742302 47 36 76,60%
1337742328 10 1337742368 50 40 80,00%
1337742388 11 1337742421 44 33 75,00%
1337742443 10 1337742476 43 33 76,74%
1337742498 11 1337742532 45 34 75,56%
1337739923 12 1337739950 39 27 69,23%
1337742554 11 1337742583 40 29 72,50%
1337739971 10 1337740007 46 36 78,26%
1337740030 9 1337740065 44 35 79,55%
1337740088 11 1337740129 52 41 78,85%
1337740145 11 1337740177 43 32 74,42%
Moyenne 11,48 44,64 33,16 74,12%
Écart type 2,16 4,58 4,58 5,01%
Maximum 21 54 42 80,95%

Requête 2
Solution 14: ( ?name = "Martin" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738900 23 1337738919 42 19 45,24%
1337740210 24 1337740227 41 17 41,46%
1337740257 28 1337740284 55 27 49,09%
1337740316 30 1337740343 57 27 47,37%
1337740367 22 1337740400 55 33 60,00%
1337740432 28 1337740454 50 22 44,00%
1337740480 24 1337740504 48 24 50,00%
1337740535 26 1337740568 59 33 55,93%
1337740596 27 1337740627 58 31 53,45%
1337740654 26 1337740684 56 30 53,57%
1337740712 27 1337740735 50 23 46,00%
1337738948 27 1337738975 54 27 50,00%
1337740759 22 1337740786 49 27 55,10%
1337740816 28 1337740847 59 31 52,54%
1337740875 26 1337740900 51 25 49,02%
1337740927 25 1337740956 54 29 53,70%
1337740986 28 1337741017 59 31 52,54%
1337741045 26 1337741084 65 39 60,00%
1337741114 28 1337741153 67 39 58,21%
1337741182 27 1337741211 56 29 51,79%
1337741244 31 1337741258 45 14 31,11%
1337741315 31 1337741340 56 25 44,64%
1337739006 29 1337739028 51 22 43,14%
1337741368 24 1337741415 71 47 66,20%
1337741444 25 1337741492 73 48 65,75%
1337741519 24 1337741551 56 32 57,14%
1337741582 30 1337741606 54 24 44,44%
1337741634 26 1337741670 62 36 58,06%
1337741700 28 1337741732 60 32 53,33%
1337741763 29 1337741790 56 27 48,21%
1337741822 30 1337741844 52 22 42,31%
1337741877 31 1337741903 57 26 45,61%
1337741930 25 1337741966 61 36 59,02%
1337739881 30 1337739902 51 21 41,18%
1337741996 28 1337742029 61 33 54,10%
1337742056 26 1337742084 54 28 51,85%
1337742112 26 1337742141 55 29 52,73%
1337742168 25 1337742195 52 27 51,92%
1337742224 27 1337742254 57 30 52,63%
1337742283 28 1337742316 61 33 54,10%
1337742345 27 1337742376 58 31 53,45%
1337742401 24 1337742431 54 30 55,56%
1337742457 24 1337742482 49 25 51,02%
1337742514 27 1337742542 55 28 50,91%
1337739940 29 1337739959 48 19 39,58%
1337742569 26 1337742596 53 27 50,94%
1337739994 33 1337740018 57 24 42,11%
1337740047 26 1337740076 55 29 52,73%
1337740106 29 1337740132 55 26 47,27%
1337740160 26 1337740184 50 24 48,00%
Moyenne 26,92 55,28 28,36 50,76%
Écart type 2,43 6,18 6,51 6,61%
Maximum 33 73 48 66,20%

Requête 2
Solution 15: ( ?name = "Natalya" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738885 8 1337738914 37 29 78,38%
1337740197 11 1337740222 36 25 69,44%
1337740241 12 1337740275 46 34 73,91%
1337740301 15 1337740340 54 39 72,22%
1337740354 9 1337740384 39 30 76,92%
1337740417 13 1337740444 40 27 67,50%
1337740466 10 1337740496 40 30 75,00%
1337740519 10 1337740555 46 36 78,26%
1337740583 14 1337740612 43 29 67,44%
1337740640 12 1337740674 46 34 73,91%
1337740697 12 1337740728 43 31 72,09%
1337738932 11 1337738964 43 32 74,42%
1337740749 12 1337740767 30 18 60,00%
1337740800 12 1337740832 44 32 72,73%
1337740859 10 1337740888 39 29 74,36%
1337740914 12 1337740949 47 35 74,47%
1337740970 12 1337741008 50 38 76,00%
1337741031 12 1337741062 43 31 72,09%
1337741098 12 1337741136 50 38 76,00%
1337741167 12 1337741199 44 32 72,73%
1337741224 11 1337741253 40 29 72,50%
1337741296 12 1337741333 49 37 75,51%
1337738988 11 1337739020 43 32 74,42%
1337741356 12 1337741387 43 31 72,09%
1337741430 11 1337741465 46 35 76,09%
1337741504 9 1337741537 42 33 78,57%
1337741564 12 1337741597 45 33 73,33%
1337741621 13 1337741660 52 39 75,00%
1337741683 11 1337741720 48 37 77,08%
1337741746 12 1337741781 47 35 74,47%
1337741804 12 1337741838 46 34 73,91%
1337741857 11 1337741891 45 34 75,56%
1337741916 11 1337741950 45 34 75,56%
1337739862 11 1337739898 47 36 76,60%
1337741980 12 1337742022 54 42 77,78%
1337742042 12 1337742076 46 34 73,91%
1337742097 11 1337742133 47 36 76,60%
1337742157 14 1337742187 44 30 68,18%
1337742210 13 1337742247 50 37 74,00%
1337742266 11 1337742302 47 36 76,60%
1337742331 13 1337742368 50 37 74,00%
1337742389 12 1337742421 44 32 72,73%
1337742443 10 1337742476 43 33 76,74%
1337742499 12 1337742532 45 33 73,33%
1337739924 13 1337739950 39 26 66,67%
1337742553 10 1337742583 40 30 75,00%
1337739971 10 1337740007 46 36 78,26%
1337740032 11 1337740065 44 33 75,00%
1337740089 12 1337740129 52 40 76,92%
1337740145 11 1337740177 43 32 74,42%
Moyenne 11,54 44,64 33,10 73,97%
Écart type 1,30 4,58 4,21 3,44%
Maximum 15 54 42 78,57%

Requête 2
Solution 16: ( ?name = "Natasha F." )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738885 8 1337738914 37 29 78,38%
1337740197 11 1337740222 36 25 69,44%
1337740241 12 1337740275 46 34 73,91%
1337740301 15 1337740340 54 39 72,22%
1337740354 9 1337740384 39 30 76,92%
1337740417 13 1337740444 40 27 67,50%
1337740466 10 1337740496 40 30 75,00%
1337740519 10 1337740555 46 36 78,26%
1337740583 14 1337740612 43 29 67,44%
1337740640 12 1337740674 46 34 73,91%
1337740697 12 1337740728 43 31 72,09%
1337738932 11 1337738964 43 32 74,42%
1337740749 12 1337740767 30 18 60,00%
1337740800 12 1337740832 44 32 72,73%
1337740859 10 1337740888 39 29 74,36%
1337740914 12 1337740949 47 35 74,47%
1337740970 12 1337741008 50 38 76,00%
1337741031 12 1337741062 43 31 72,09%
1337741098 12 1337741136 50 38 76,00%
1337741167 12 1337741199 44 32 72,73%
1337741224 11 1337741253 40 29 72,50%
1337741296 12 1337741333 49 37 75,51%
1337738988 11 1337739020 43 32 74,42%
1337741356 12 1337741387 43 31 72,09%
1337741430 11 1337741465 46 35 76,09%
1337741504 9 1337741537 42 33 78,57%
1337741564 12 1337741597 45 33 73,33%
1337741621 13 1337741660 52 39 75,00%
1337741683 11 1337741720 48 37 77,08%
1337741746 12 1337741781 47 35 74,47%
1337741804 12 1337741838 46 34 73,91%
1337741857 11 1337741891 45 34 75,56%
1337741916 11 1337741950 45 34 75,56%
1337739862 11 1337739898 47 36 76,60%
1337741980 12 1337742022 54 42 77,78%
1337742042 12 1337742076 46 34 73,91%
1337742097 11 1337742133 47 36 76,60%
1337742157 14 1337742187 44 30 68,18%
1337742210 13 1337742247 50 37 74,00%
1337742266 11 1337742302 47 36 76,60%
1337742331 13 1337742368 50 37 74,00%
1337742389 12 1337742421 44 32 72,73%
1337742443 10 1337742476 43 33 76,74%
1337742499 12 1337742532 45 33 73,33%
1337739924 13 1337739950 39 26 66,67%
1337742553 10 1337742583 40 30 75,00%
1337739971 10 1337740007 46 36 78,26%
1337740032 11 1337740065 44 33 75,00%
1337740089 12 1337740129 52 40 76,92%
1337740145 11 1337740177 43 32 74,42%
Moyenne 11,54 44,64 33,10 73,97%
Écart type 1,30 4,58 4,21 3,44%
Maximum 15 54 42 78,57%

Requête 2
Solution 17: ( ?name = "Natasha" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738885 8 1337738914 37 29 78,38%
1337740197 11 1337740222 36 25 69,44%
1337740241 12 1337740275 46 34 73,91%
1337740301 15 1337740340 54 39 72,22%
1337740354 9 1337740384 39 30 76,92%
1337740417 13 1337740444 40 27 67,50%
1337740466 10 1337740496 40 30 75,00%
1337740519 10 1337740555 46 36 78,26%
1337740583 14 1337740612 43 29 67,44%
1337740640 12 1337740674 46 34 73,91%
1337740697 12 1337740728 43 31 72,09%
1337738932 11 1337738964 43 32 74,42%
1337740749 12 1337740767 30 18 60,00%
1337740800 12 1337740832 44 32 72,73%
1337740859 10 1337740888 39 29 74,36%
1337740914 12 1337740949 47 35 74,47%
1337740970 12 1337741008 50 38 76,00%
1337741031 12 1337741062 43 31 72,09%
1337741098 12 1337741136 50 38 76,00%
1337741167 12 1337741199 44 32 72,73%
1337741224 11 1337741253 40 29 72,50%
1337741296 12 1337741333 49 37 75,51%
1337738988 11 1337739020 43 32 74,42%
1337741356 12 1337741387 43 31 72,09%
1337741430 11 1337741465 46 35 76,09%
1337741504 9 1337741537 42 33 78,57%
1337741564 12 1337741597 45 33 73,33%
1337741621 13 1337741660 52 39 75,00%
1337741683 11 1337741720 48 37 77,08%
1337741746 12 1337741781 47 35 74,47%
1337741804 12 1337741838 46 34 73,91%
1337741857 11 1337741891 45 34 75,56%
1337741916 11 1337741950 45 34 75,56%
1337739862 11 1337739898 47 36 76,60%
1337741980 12 1337742022 54 42 77,78%
1337742042 12 1337742076 46 34 73,91%
1337742097 11 1337742133 47 36 76,60%
1337742157 14 1337742187 44 30 68,18%
1337742210 13 1337742247 50 37 74,00%
1337742266 11 1337742302 47 36 76,60%
1337742331 13 1337742368 50 37 74,00%
1337742389 12 1337742421 44 32 72,73%
1337742443 10 1337742476 43 33 76,74%
1337742499 12 1337742532 45 33 73,33%
1337739924 13 1337739950 39 26 66,67%
1337742553 10 1337742583 40 30 75,00%
1337739971 10 1337740007 46 36 78,26%
1337740032 11 1337740065 44 33 75,00%
1337740089 12 1337740129 52 40 76,92%
1337740145 11 1337740177 43 32 74,42%
Moyenne 11,54 44,64 33,10 73,97%
Écart type 1,30 4,58 4,21 3,44%
Maximum 15 54 42 78,57%

Requête 2
Solution 18: ( ?name = "Nigam" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738891 14 1337738919 42 28 66,67%
1337740202 16 1337740227 41 25 60,98%
1337740247 18 1337740284 55 37 67,27%
1337740307 21 1337740343 57 36 63,16%
1337740362 17 1337740400 55 38 69,09%
1337740420 16 1337740454 50 34 68,00%
1337740472 16 1337740504 48 32 66,67%
1337740523 14 1337740568 59 45 76,27%
1337740588 19 1337740627 58 39 67,24%
1337740645 17 1337740684 56 39 69,64%
1337740703 18 1337740735 50 32 64,00%
1337738936 15 1337738975 54 39 72,22%
1337740753 16 1337740786 49 33 67,35%
1337740805 17 1337740847 59 42 71,19%
1337740867 18 1337740900 51 33 64,71%
1337740918 16 1337740956 54 38 70,37%
1337740983 25 1337741017 59 34 57,63%
1337741038 19 1337741084 65 46 70,77%
1337741103 17 1337741153 67 50 74,63%
1337741171 16 1337741211 56 40 71,43%
1337741228 15 1337741258 45 30 66,67%
1337741303 19 1337741340 56 37 66,07%
1337738993 16 1337739028 51 35 68,63%
1337741362 18 1337741415 71 53 74,65%
1337741436 17 1337741492 73 56 76,71%
1337741509 14 1337741551 56 42 75,00%
1337741570 18 1337741606 54 36 66,67%
1337741627 19 1337741670 62 43 69,35%
1337741690 18 1337741732 60 42 70,00%
1337741751 17 1337741790 56 39 69,64%
1337741814 22 1337741844 52 30 57,69%
1337741863 17 1337741903 57 40 70,18%
1337741923 18 1337741966 61 43 70,49%
1337739870 19 1337739902 51 32 62,75%
1337741985 17 1337742029 61 44 72,13%
1337742057 27 1337742084 54 27 50,00%
1337742103 17 1337742141 55 38 69,09%
1337742160 17 1337742195 52 35 67,31%
1337742215 18 1337742254 57 39 68,42%
1337742270 15 1337742316 61 46 75,41%
1337742335 17 1337742376 58 41 70,69%
1337742395 18 1337742431 54 36 66,67%
1337742448 15 1337742482 49 34 69,39%
1337742503 16 1337742542 55 39 70,91%
1337739926 15 1337739959 48 33 68,75%
1337742560 17 1337742596 53 36 67,92%
1337739979 18 1337740018 57 39 68,42%
1337740037 16 1337740076 55 39 70,91%
1337740097 20 1337740132 55 35 63,64%
1337740151 17 1337740184 50 33 66,00%
Moyenne 17,44 55,28 37,84 68,19%
Écart type 2,43 6,18 6,14 4,86%
Maximum 27 73 56 76,71%

Requête 2
Solution 19: ( ?name = "O'Connor" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738905 28 1337738919 42 14 33,33%
1337740213 27 1337740228 42 15 35,71%
1337740265 36 1337740284 55 19 34,55%
1337740324 38 1337740343 57 19 33,33%
1337740374 29 1337740400 55 26 47,27%
1337740436 32 1337740454 50 18 36,00%
1337740485 29 1337740504 48 19 39,58%
1337740540 31 1337740568 59 28 47,46%
1337740603 34 1337740627 58 24 41,38%
1337740664 36 1337740684 56 20 35,71%
1337740719 34 1337740735 50 16 32,00%
1337738954 33 1337738975 54 21 38,89%
1337740762 25 1337740786 49 24 48,98%
1337740822 34 1337740847 59 25 42,37%
1337740879 30 1337740900 51 21 41,18%
1337740933 31 1337740956 54 23 42,59%
1337740995 37 1337741017 59 22 37,29%
1337741054 35 1337741084 65 30 46,15%
1337741122 36 1337741153 67 31 46,27%
1337741190 35 1337741211 56 21 37,50%
1337741244 31 1337741258 45 14 31,11%
1337741321 37 1337741340 56 19 33,93%
1337739009 32 1337739028 51 19 37,25%
1337741385 41 1337741415 71 30 42,25%
1337741455 36 1337741492 73 37 50,68%
1337741525 30 1337741551 56 26 46,43%
1337741586 34 1337741606 54 20 37,04%
1337741644 36 1337741670 62 26 41,94%
1337741705 33 1337741732 60 27 45,00%
1337741770 36 1337741790 56 20 35,71%
1337741829 37 1337741844 52 15 28,85%
1337741881 35 1337741903 57 22 38,60%
1337741937 32 1337741966 61 29 47,54%
1337739887 36 1337739902 51 15 29,41%
1337742002 34 1337742029 61 27 44,26%
1337742063 33 1337742084 54 21 38,89%
1337742119 33 1337742141 55 22 40,00%
1337742176 33 1337742195 52 19 36,54%
1337742231 34 1337742254 57 23 40,35%
1337742293 38 1337742316 61 23 37,70%
1337742353 35 1337742376 58 23 39,66%
1337742408 31 1337742431 54 23 42,59%
1337742466 33 1337742482 49 16 32,65%
1337742530 43 1337742542 55 12 21,82%
1337739943 32 1337739959 48 16 33,33%
1337742575 32 1337742596 53 21 39,62%
1337739994 33 1337740018 57 24 42,11%
1337740056 35 1337740076 55 20 36,36%
1337740112 35 1337740132 55 20 36,36%
1337740166 32 1337740184 50 18 36,00%
Moyenne 33,64 55,30 21,66 38,83%
Écart type 3,29 6,14 5,01 5,75%
Maximum 43 73 37 50,68%

Requête 2
Solution 20: ( ?name = "Paea" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738899 22 1337738919 42 20 47,62%
1337740210 24 1337740227 41 17 41,46%
1337740258 29 1337740284 55 26 47,27%
1337740317 31 1337740343 57 26 45,61%
1337740367 22 1337740400 55 33 60,00%
1337740431 27 1337740454 50 23 46,00%
1337740486 30 1337740504 48 18 37,50%
1337740535 26 1337740568 59 33 55,93%
1337740596 27 1337740627 58 31 53,45%
1337740654 26 1337740684 56 30 53,57%
1337740713 28 1337740735 50 22 44,00%
1337738948 27 1337738975 54 27 50,00%
1337740759 22 1337740786 49 27 55,10%
1337740817 29 1337740847 59 30 50,85%
1337740877 28 1337740900 51 23 45,10%
1337740928 26 1337740956 54 28 51,85%
1337740989 31 1337741017 59 28 47,46%
1337741046 27 1337741084 65 38 58,46%
1337741114 28 1337741153 67 39 58,21%
1337741183 28 1337741211 56 28 50,00%
1337741239 26 1337741258 45 19 42,22%
1337741316 32 1337741340 56 24 42,86%
1337739001 24 1337739028 51 27 52,94%
1337741368 24 1337741415 71 47 66,20%
1337741447 28 1337741492 73 45 61,64%
1337741519 24 1337741551 56 32 57,14%
1337741581 29 1337741606 54 25 46,30%
1337741635 27 1337741670 62 35 56,45%
1337741701 29 1337741732 60 31 51,67%
1337741763 29 1337741790 56 27 48,21%
1337741822 30 1337741844 52 22 42,31%
1337741878 32 1337741903 57 25 43,86%
1337741932 27 1337741966 61 34 55,74%
1337739881 30 1337739902 51 21 41,18%
1337741997 29 1337742029 61 32 52,46%
1337742056 26 1337742084 54 28 51,85%
1337742119 33 1337742141 55 22 40,00%
1337742169 26 1337742195 52 26 50,00%
1337742225 28 1337742254 57 29 50,88%
1337742283 28 1337742316 61 33 54,10%
1337742347 29 1337742376 58 29 50,00%
1337742405 28 1337742431 54 26 48,15%
1337742461 28 1337742482 49 21 42,86%
1337742519 32 1337742542 55 23 41,82%
1337739940 29 1337739959 48 19 39,58%
1337742569 26 1337742596 53 27 50,94%
1337739988 27 1337740018 57 30 52,63%
1337740047 26 1337740076 55 29 52,73%
1337740107 30 1337740132 55 25 45,45%
1337740160 26 1337740184 50 24 48,00%
Moyenne 27,60 55,28 27,68 49,59%
Écart type 2,56 6,18 6,23 6,23%
Maximum 33 73 47 66,20%

Requête 2
Solution 21: ( ?name = "Parag" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738907 30 1337738919 42 12 28,57%
1337740214 28 1337740228 42 14 33,33%
1337740265 36 1337740284 55 19 34,55%
1337740325 39 1337740343 57 18 31,58%
1337740383 38 1337740400 55 17 30,91%
1337740438 34 1337740454 50 16 32,00%
1337740487 31 1337740504 48 17 35,42%
1337740542 33 1337740568 59 26 44,07%
1337740603 34 1337740627 58 24 41,38%
1337740664 36 1337740684 56 20 35,71%
1337740719 34 1337740735 50 16 32,00%
1337738954 33 1337738975 54 21 38,89%
1337740762 25 1337740786 49 24 48,98%
1337740823 35 1337740847 59 24 40,68%
1337740880 31 1337740900 51 20 39,22%
1337740935 33 1337740956 54 21 38,89%
1337740998 40 1337741017 59 19 32,20%
1337741054 35 1337741084 65 30 46,15%
1337741124 38 1337741153 67 29 43,28%
1337741189 34 1337741211 56 22 39,29%
1337741245 32 1337741258 45 13 28,89%
1337741321 37 1337741340 56 19 33,93%
1337739013 36 1337739028 51 15 29,41%
1337741378 34 1337741415 71 37 52,11%
1337741457 38 1337741492 73 35 47,95%
1337741528 33 1337741551 56 23 41,07%
1337741588 36 1337741606 54 18 33,33%
1337741644 36 1337741670 62 26 41,94%
1337741705 33 1337741732 60 27 45,00%
1337741772 38 1337741790 56 18 32,14%
1337741830 38 1337741844 52 14 26,92%
1337741882 36 1337741903 57 21 36,84%
1337741939 34 1337741966 61 27 44,26%
1337739889 38 1337739902 51 13 25,49%
1337742004 36 1337742029 61 25 40,98%
1337742066 36 1337742084 54 18 33,33%
1337742121 35 1337742141 55 20 36,36%
1337742176 33 1337742195 52 19 36,54%
1337742234 37 1337742254 57 20 35,09%
1337742290 35 1337742316 61 26 42,62%
1337742352 34 1337742376 58 24 41,38%
1337742409 32 1337742431 54 22 40,74%
1337742464 31 1337742482 49 18 36,73%
1337742523 36 1337742542 55 19 34,55%
1337739944 33 1337739959 48 15 31,25%
1337742573 30 1337742596 53 23 43,40%
1337739999 38 1337740018 57 19 33,33%
1337740055 34 1337740076 55 21 38,18%
1337740113 36 1337740132 55 19 34,55%
1337740166 32 1337740184 50 18 36,00%
Moyenne 34,48 55,30 20,82 37,23%
Écart type 2,92 6,14 5,25 5,90%
Maximum 40 73 37 52,11%

Requête 2
Solution 22: ( ?name = "Paul" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738897 20 1337738919 42 22 52,38%
1337740210 24 1337740228 42 18 42,86%
1337740259 30 1337740284 55 25 45,45%
1337740318 32 1337740343 57 25 43,86%
1337740368 23 1337740400 55 32 58,18%
1337740432 28 1337740454 50 22 44,00%
1337740482 26 1337740504 48 22 45,83%
1337740536 27 1337740568 59 32 54,24%
1337740597 28 1337740627 58 30 51,72%
1337740656 28 1337740684 56 28 50,00%
1337740712 27 1337740735 50 23 46,00%
1337738950 29 1337738975 54 25 46,30%
1337740759 22 1337740786 49 27 55,10%
1337740831 43 1337740847 59 16 27,12%
1337740875 26 1337740900 51 25 49,02%
1337740928 26 1337740956 54 28 51,85%
1337740988 30 1337741017 59 29 49,15%
1337741047 28 1337741084 65 37 56,92%
1337741115 29 1337741153 67 38 56,72%
1337741182 27 1337741211 56 29 51,79%
1337741239 26 1337741258 45 19 42,22%
1337741316 32 1337741340 56 24 42,86%
1337739004 27 1337739028 51 24 47,06%
1337741369 25 1337741415 71 46 64,79%
1337741448 29 1337741492 73 44 60,27%
1337741521 26 1337741551 56 30 53,57%
1337741582 30 1337741606 54 24 44,44%
1337741636 28 1337741670 62 34 54,84%
1337741700 28 1337741732 60 32 53,33%
1337741763 29 1337741790 56 27 48,21%
1337741823 31 1337741844 52 21 40,38%
1337741879 33 1337741903 57 24 42,11%
1337741938 33 1337741966 61 28 45,90%
1337739882 31 1337739902 51 20 39,22%
1337741995 27 1337742029 61 34 55,74%
1337742057 27 1337742084 54 27 50,00%
1337742113 27 1337742141 55 28 50,91%
1337742170 27 1337742195 52 25 48,08%
1337742227 30 1337742254 57 27 47,37%
1337742294 39 1337742316 61 22 36,07%
1337742347 29 1337742376 58 29 50,00%
1337742402 25 1337742431 54 29 53,70%
1337742458 25 1337742482 49 24 48,98%
1337742518 31 1337742542 55 24 43,64%
1337739939 28 1337739959 48 20 41,67%
1337742571 28 1337742596 53 25 47,17%
1337739988 27 1337740018 57 30 52,63%
1337740049 28 1337740076 55 27 49,09%
1337740108 31 1337740132 55 24 43,64%
1337740163 29 1337740184 50 21 42,00%
Moyenne 28,38 55,30 26,92 48,37%
Écart type 3,71 6,14 5,94 6,55%
Maximum 43 73 46 64,79%

Requête 2
Solution 23: ( ?name = "Robert" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738912 35 1337738919 42 7 16,67%
1337740221 35 1337740228 42 7 16,67%
1337740275 46 1337740284 55 9 16,36%
1337740331 45 1337740343 57 12 21,05%
1337740383 38 1337740400 55 17 30,91%
1337740444 40 1337740454 50 10 20,00%
1337740496 40 1337740504 48 8 16,67%
1337740549 40 1337740568 59 19 32,20%
1337740611 42 1337740627 58 16 27,59%
1337740671 43 1337740684 56 13 23,21%
1337740726 41 1337740735 50 9 18,00%
1337738963 42 1337738975 54 12 22,22%
1337740766 29 1337740786 49 20 40,82%
1337740832 44 1337740847 59 15 25,42%
1337740887 38 1337740900 51 13 25,49%
1337740944 42 1337740956 54 12 22,22%
1337741005 47 1337741017 59 12 20,34%
1337741062 43 1337741084 65 22 33,85%
1337741130 44 1337741153 67 23 34,33%
1337741198 43 1337741211 56 13 23,21%
1337741252 39 1337741258 45 6 13,33%
1337741332 48 1337741340 56 8 14,29%
1337739019 42 1337739028 51 9 17,65%
1337741387 43 1337741415 71 28 39,44%
1337741464 45 1337741492 73 28 38,36%
1337741534 39 1337741551 56 17 30,36%
1337741596 44 1337741606 54 10 18,52%
1337741654 46 1337741670 62 16 25,81%
1337741715 43 1337741732 60 17 28,33%
1337741780 46 1337741790 56 10 17,86%
1337741838 46 1337741844 52 6 11,54%
1337741889 43 1337741903 57 14 24,56%
1337741949 44 1337741966 61 17 27,87%
1337739897 46 1337739902 51 5 9,80%
1337742012 44 1337742029 61 17 27,87%
1337742074 44 1337742084 54 10 18,52%
1337742129 43 1337742141 55 12 21,82%
1337742185 42 1337742195 52 10 19,23%
1337742240 43 1337742254 57 14 24,56%
1337742301 46 1337742316 61 15 24,59%
1337742366 48 1337742376 58 10 17,24%
1337742416 39 1337742431 54 15 27,78%
1337742473 40 1337742482 49 9 18,37%
1337742530 43 1337742542 55 12 21,82%
1337739949 38 1337739959 48 10 20,83%
1337742582 39 1337742596 53 14 26,42%
1337740006 45 1337740018 57 12 21,05%
1337740064 43 1337740076 55 12 21,82%
1337740121 44 1337740132 55 11 20,00%
1337740175 41 1337740184 50 9 18,00%
Moyenne 42,26 55,30 13,04 23,10%
Écart type 3,57 6,14 5,09 6,89%
Maximum 48 73 28 40,82%

Requête 2
Solution 24: ( ?name = "Saeed" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738902 25 1337738919 42 17 40,48%
1337740212 26 1337740228 42 16 38,10%
1337740265 36 1337740284 55 19 34,55%
1337740325 39 1337740343 57 18 31,58%
1337740375 30 1337740400 55 25 45,45%
1337740436 32 1337740454 50 18 36,00%
1337740489 33 1337740504 48 15 31,25%
1337740543 34 1337740568 59 25 42,37%
1337740603 34 1337740627 58 24 41,38%
1337740673 45 1337740684 56 11 19,64%
1337740720 35 1337740735 50 15 30,00%
1337738954 33 1337738975 54 21 38,89%
1337740762 25 1337740786 49 24 48,98%
1337740824 36 1337740847 59 23 38,98%
1337740880 31 1337740900 51 20 39,22%
1337740934 32 1337740956 54 22 40,74%
1337740996 38 1337741017 59 21 35,59%
1337741053 34 1337741084 65 31 47,69%
1337741122 36 1337741153 67 31 46,27%
1337741189 34 1337741211 56 22 39,29%
1337741245 32 1337741258 45 13 28,89%
1337741321 37 1337741340 56 19 33,93%
1337739012 35 1337739028 51 16 31,37%
1337741376 32 1337741415 71 39 54,93%
1337741457 38 1337741492 73 35 47,95%
1337741527 32 1337741551 56 24 42,86%
1337741588 36 1337741606 54 18 33,33%
1337741642 34 1337741670 62 28 45,16%
1337741706 34 1337741732 60 26 43,33%
1337741772 38 1337741790 56 18 32,14%
1337741829 37 1337741844 52 15 28,85%
1337741882 36 1337741903 57 21 36,84%
1337741939 34 1337741966 61 27 44,26%
1337739889 38 1337739902 51 13 25,49%
1337742002 34 1337742029 61 27 44,26%
1337742071 41 1337742084 54 13 24,07%
1337742118 32 1337742141 55 23 41,82%
1337742177 34 1337742195 52 18 34,62%
1337742232 35 1337742254 57 22 38,60%
1337742291 36 1337742316 61 25 40,98%
1337742352 34 1337742376 58 24 41,38%
1337742409 32 1337742431 54 22 40,74%
1337742464 31 1337742482 49 18 36,73%
1337742523 36 1337742542 55 19 34,55%
1337739943 32 1337739959 48 16 33,33%
1337742575 32 1337742596 53 21 39,62%
1337739997 36 1337740018 57 21 36,84%
1337740055 34 1337740076 55 21 38,18%
1337740117 40 1337740132 55 15 27,27%
1337740166 32 1337740184 50 18 36,00%
Moyenne 34,24 55,30 21,06 37,70%
Écart type 3,63 6,14 5,65 6,86%
Maximum 45 73 39 54,93%

Requête 2
Solution 25: ( ?name = "Sean" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738897 20 1337738919 42 22 52,38%
1337740210 24 1337740228 42 18 42,86%
1337740260 31 1337740284 55 24 43,64%
1337740319 33 1337740343 57 24 42,11%
1337740368 23 1337740400 55 32 58,18%
1337740433 29 1337740454 50 21 42,00%
1337740481 25 1337740504 48 23 47,92%
1337740536 27 1337740568 59 32 54,24%
1337740597 28 1337740627 58 30 51,72%
1337740658 30 1337740684 56 26 46,43%
1337740718 33 1337740735 50 17 34,00%
1337738950 29 1337738975 54 25 46,30%
1337740759 22 1337740786 49 27 55,10%
1337740818 30 1337740847 59 29 49,15%
1337740875 26 1337740900 51 25 49,02%
1337740928 26 1337740956 54 28 51,85%
1337740990 32 1337741017 59 27 45,76%
1337741047 28 1337741084 65 37 56,92%
1337741116 30 1337741153 67 37 55,22%
1337741184 29 1337741211 56 27 48,21%
1337741239 26 1337741258 45 19 42,22%
1337741316 32 1337741340 56 24 42,86%
1337739003 26 1337739028 51 25 49,02%
1337741370 26 1337741415 71 45 63,38%
1337741449 30 1337741492 73 43 58,90%
1337741520 25 1337741551 56 31 55,36%
1337741583 31 1337741606 54 23 42,59%
1337741636 28 1337741670 62 34 54,84%
1337741701 29 1337741732 60 31 51,67%
1337741762 28 1337741790 56 28 50,00%
1337741824 32 1337741844 52 20 38,46%
1337741879 33 1337741903 57 24 42,11%
1337741932 27 1337741966 61 34 55,74%
1337739882 31 1337739902 51 20 39,22%
1337742000 32 1337742029 61 29 47,54%
1337742057 27 1337742084 54 27 50,00%
1337742114 28 1337742141 55 27 49,09%
1337742170 27 1337742195 52 25 48,08%
1337742224 27 1337742254 57 30 52,63%
1337742284 29 1337742316 61 32 52,46%
1337742346 28 1337742376 58 30 51,72%
1337742401 24 1337742431 54 30 55,56%
1337742462 29 1337742482 49 20 40,82%
1337742518 31 1337742542 55 24 43,64%
1337739940 29 1337739959 48 19 39,58%
1337742570 27 1337742596 53 26 49,06%
1337739989 28 1337740018 57 29 50,88%
1337740050 29 1337740076 55 26 47,27%
1337740107 30 1337740132 55 25 45,45%
1337740161 27 1337740184 50 23 46,00%
Moyenne 28,22 55,30 27,08 48,58%
Écart type 2,87 6,14 5,83 6,04%
Maximum 33 73 45 63,38%

Requête 2
Solution 26: ( ?name = "Tania" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738889 12 1337738914 37 25 67,57%
1337740205 19 1337740222 36 17 47,22%
1337740274 45 1337740275 46 1 2,17%
1337740307 21 1337740340 54 33 61,11%
1337740363 18 1337740384 39 21 53,85%
1337740423 19 1337740444 40 21 52,50%
1337740473 17 1337740496 40 23 57,50%
1337740527 18 1337740555 46 28 60,87%
1337740592 23 1337740612 43 20 46,51%
1337740647 19 1337740674 46 27 58,70%
1337740705 20 1337740728 43 23 53,49%
1337738940 19 1337738964 43 24 55,81%
1337740755 18 1337740767 30 12 40,00%
1337740806 18 1337740832 44 26 59,09%
1337740868 19 1337740888 39 20 51,28%
1337740921 19 1337740949 47 28 59,57%
1337740983 25 1337741008 50 25 50,00%
1337741036 17 1337741062 43 26 60,47%
1337741106 20 1337741136 50 30 60,00%
1337741176 21 1337741199 44 23 52,27%
1337741231 18 1337741253 40 22 55,00%
1337741312 28 1337741333 49 21 42,86%
1337738997 20 1337739020 43 23 53,49%
1337741363 19 1337741387 43 24 55,81%
1337741439 20 1337741465 46 26 56,52%
1337741512 17 1337741537 42 25 59,52%
1337741572 20 1337741597 45 25 55,56%
1337741628 20 1337741660 52 32 61,54%
1337741692 20 1337741720 48 28 58,33%
1337741753 19 1337741781 47 28 59,57%
1337741814 22 1337741838 46 24 52,17%
1337741864 18 1337741891 45 27 60,00%
1337741926 21 1337741950 45 24 53,33%
1337739872 21 1337739898 47 26 55,32%
1337741988 20 1337742022 54 34 62,96%
1337742050 20 1337742076 46 26 56,52%
1337742105 19 1337742133 47 28 59,57%
1337742164 21 1337742187 44 23 52,27%
1337742218 21 1337742247 50 29 58,00%
1337742276 21 1337742302 47 26 55,32%
1337742338 20 1337742368 50 30 60,00%
1337742394 17 1337742421 44 27 61,36%
1337742452 19 1337742476 43 24 55,81%
1337742506 19 1337742532 45 26 57,78%
1337739930 19 1337739950 39 20 51,28%
1337742562 19 1337742583 40 21 52,50%
1337739981 20 1337740007 46 26 56,52%
1337740040 19 1337740065 44 25 56,82%
1337740097 20 1337740129 52 32 61,54%
1337740151 17 1337740177 43 26 60,47%
Moyenne 20,02 44,64 24,62 54,96%
Écart type 4,24 4,58 5,25 9,15%
Maximum 45 54 34 67,57%

Requête 2
Solution 27: ( ?name = "Timothy" )
Absolute querier time Relative querier time Absolute normal time Relative normal time Absolute delta time Relative delta time
1337738903 26 1337738919 42 16 38,10%
1337740210 24 1337740228 42 18 42,86%
1337740261 32 1337740284 55 23 41,82%
1337740319 33 1337740343 57 24 42,11%
1337740369 24 1337740400 55 31 56,36%
1337740432 28 1337740454 50 22 44,00%
1337740481 25 1337740504 48 23 47,92%
1337740537 28 1337740568 59 31 52,54%
1337740597 28 1337740627 58 30 51,72%
1337740658 30 1337740684 56 26 46,43%
1337740715 30 1337740735 50 20 40,00%
1337738950 29 1337738975 54 25 46,30%
1337740760 23 1337740786 49 26 53,06%
1337740818 30 1337740847 59 29 49,15%
1337740874 25 1337740900 51 26 50,98%
1337740928 26 1337740956 54 28 51,85%
1337740991 33 1337741017 59 26 44,07%
1337741050 31 1337741084 65 34 52,31%
1337741116 30 1337741153 67 37 55,22%
1337741191 36 1337741211 56 20 35,71%
1337741239 26 1337741258 45 19 42,22%
1337741316 32 1337741340 56 24 42,86%
1337739006 29 1337739028 51 22 43,14%
1337741371 27 1337741415 71 44 61,97%
1337741450 31 1337741492 73 42 57,53%
1337741520 25 1337741551 56 31 55,36%
1337741583 31 1337741606 54 23 42,59%
1337741636 28 1337741670 62 34 54,84%
1337741701 29 1337741732 60 31 51,67%
1337741763 29 1337741790 56 27 48,21%
1337741825 33 1337741844 52 19 36,54%
1337741879 33 1337741903 57 24 42,11%
1337741934 29 1337741966 61 32 52,46%
1337739882 31 1337739902 51 20 39,22%
1337741999 31 1337742029 61 30 49,18%
1337742064 34 1337742084 54 20 37,04%
1337742126 40 1337742141 55 15 27,27%
1337742172 29 1337742195 52 23 44,23%
1337742227 30 1337742254 57 27 47,37%
1337742288 33 1337742316 61 28 45,90%
1337742346 28 1337742376 58 30 51,72%
1337742402 25 1337742431 54 29 53,70%
1337742460 27 1337742482 49 22 44,90%
1337742518 31 1337742542 55 24 43,64%
1337739940 29 1337739959 48 19 39,58%
1337742571 28 1337742596 53 25 47,17%
1337739989 28 1337740018 57 29 50,88%
1337740050 29 1337740076 55 26 47,27%
1337740108 31 1337740132 55 24 43,64%
1337740160 26 1337740184 50 24 48,00%
Moyenne 29,26 55,30 26,04 46,69%
Écart type 3,27 6,14 5,95 6,56%
Maximum 40 73 44 61,97%