Les petites cases

Sparql, maillon essentiel du « Web of data »

Avec l'initiative Linked data dont Dbpedia est l'exemple le plus représentatif, nous disposons d'une masse de données structurées de plus en plus importantes. Peu à peu se constituent sur le Web des entrepôts de données décentralisées, mais reliées par l'utilisation de RDF et de la propriété OWL « sameAs ».

Par exemple : la notice Paris dans Dbpedia est reliée à la notice Paris dans Geonames via le triple suivant :

<rdf:Description rdf:about="http://dbpedia.org/resource/Paris">
<owl:sameAs rdf:about="http://sws.geonames.org/2988507/"/>
</rdf:Description>

De cette façon, vous pouvez interroger de toutes les informations de Dbpedia et de Geonames sur la ressource « Paris ». Les applications sont très nombreuses, comme par exemple ma knowledge box (qui semble fonctionner cahin-caha, il faudra que je regarde cela) ou d'autres, comme le montre cet article.

Vous allez me dire : « C'est bien joli, mais quelle est la différence avec un Flick'r, un Google Maps et autres services Web 2.0 ? Ils exposent leurs données via des Web services qu'on peut aussi réutiliser pour créer des Mashup. »

C'est entièrement vrai. Il existe néanmoins une différence et elle est de taille. Dans le cas des services Web 2.0 actuels, les Web services sont certes disponibles, mais ne sont pas normalisés, il faut donc connaître les méthodes du Web services et la structure des données pour les interroger. Ce n'est pas le cas des entrepôts de données exposés en RDF, puisqu'on dispose alors d'un langage de requêtes et d'un protocole unique : le Sparql (prononcé « sparkoeule »), actuellement en cours de normalisation au W3C.

Je vous entends d'ici : « Mais, tu nous répètes à longueur de billets que RDF, c'est souple, générique et qu'on peut associer autant de propriétés qu'on veut à une ressource. Comment, dans ces conditions, peut-on connaître les propriétés utilisées dans tel ou tel entrepôt ou pour telle ou telle ressource ? »

Très bonne remarque, cher lecteur, je vois que tu suis. C'est là qu'entre en jeu toute la puissance de Sparql. On n'a pas besoin de connaître a priori la structure et le contenu des données pour pouvoir les interroger avec ce langage de requêtes. En effet, Sparql permet d'interroger n'importe quel composant d'un triple qui, je le rappelle, ont la forme Sujet-Prédicat-Objet.

Exemple : si vous voulez connaître tous les triples qui composent mon fichier FOAF, sans rien connaître a priori des ressources décrites, des propriétés utilisés ou du contenu, on effectue la requête suivante :

SELECT ?sujet ?predicat ?objet 
{
?sujet ?predicat ?objet
}

Autre exemple : je veux connaître tous les prédicats/propriétés pour décrire la ressource Paris ou pour lesquels la ressource Paris est l'objet dans Dbpedia :

SELECT DISTINCT ?predicat
{
{<http://dbpedia.org/resource/Paris> ?predicat ?objet.}
UNION {
?sujet ?predicat <http://dbpedia.org/resource/Paris>.
}
}

Dernier exemple : maintenant que je connais les propriétés décrivant la ressource Paris, je veux connaître toutes les personnes qui sont nés à Paris :

SELECT DISTINCT ?personne
{
{?personne <http://dbpedia.org/property/cityofbirth> <http://dbpedia.org/resource/Paris>.}
UNION {
?personne <http://dbpedia.org/property/birthPlace> <http://dbpedia.org/resource/Paris>.
}
UNION {
?personne <http://dbpedia.org/property/birthplace> <http://dbpedia.org/resource/Paris>.
}
UNION {
?personne <http://dbpedia.org/property/placeofbirth> <http://dbpedia.org/resource/Paris>.
}
UNION {
?personne <http://dbpedia.org/property/placeOfBirth> <http://dbpedia.org/resource/Paris>.
}
UNION {
?personne <http://dbpedia.org/property/placebirth> <http://dbpedia.org/resource/Paris>.
}
UNION {
?personne <http://dbpedia.org/property/placeBirth> <http://dbpedia.org/resource/Paris>.
}
}

Cet exemple montre, au passage, qu'il reste encore pas mal de travail à Dbpedia pour harmoniser les propriétés de leur entrepôt (cf. les commentaires pour plus de renseignements).

Je pense que vous avez compris le principe général. C'est une véritable avancée par rapport au système des Web services et encore plus au SQL qui ne permet pas de faire une requête du type « SELECT * FROM * » (ce serait en quelque sorte un équivalent) (MAJ. cf. le commentaire de Nicolas). De plus, Sparql peut renvoyer les réponses en XML selon un schéma normalisé, alors que chaque Web service définit son propre schéma XML pour répondre à une requête.

Et là, Manue me dit : « c'est comme l'OAI, tu peux savoir la structure de l'entrepôt grâce aux verbes ListMetadataFormats pour lister les schémas de métadonnées utilisées et ListSets pour lister les ensembles de l'entrepôt OAI. »

Le principe est à peu près équivalent, mais il va bien plus loin, puisque, dans le cas de Sparql, vous ne vous contentez pas de récupérer le nom du schéma de métadonnées et le lien vers sa grammaire, vous récupérez la structure complète. De même, vous n'avez pas besoin de différents verbes qui sont limités à un seul type d'actions, RDF pour exprimer les données et Sparql pour les interroger sont suffisamment puissants et génériques pour effectuer à peu près tous les types d'interrogations sur un entrepôt de données avec une seule méthode et un seul langage de requêtes.

RDF Sparql Geekeries Linked Data — 

Commentaires

Je pense effectivement que SPARQL doit être LA valeur ajouté de RDF. RDF est loin de casser trois pattes à un canard en tant que telle, son utilisation dans les cadres que tu décris est elle intéressante. Cependant j'ai deux remarques dans ce que tu dis.

Ta dernière requête est dégueulasse. Si tu dis que le problème vient de dbpedia je veux bien, mais bon la bonne requête c'est (en français) : « je veux savoir combien de gens sont nés à Paris d'après la Base DBPedia » et pas « Je veux savoir combien de gens sont nés à Paris d'après la base DBPedia, ainsi que combien de gens ont Paris pour lieu de naissance selon la base DBPedia, ajoutez moi aussi les gens dont la naissance s'est effectué à Paris selon la base DBPedia. » Non franchement c'est pas sérieux, j'espère que le problème est vraiment chez DBPedia sinon ça fait un peu frémir sur l'implémentation de SPARQL et RDF.

Ensuite, je sais bien que tu n'aimes pas SQL ni les bases de données relationnelles, mais tu leur fais un faux procès, parce qu'ils ne sont pas fait pour faire la même chose que RDF, et ne fonctionnent pas de la même manière. Ce que tu mets en avant c'est qu'avec SPARQL on peut taper quelque part sans savoir ce qu'il y a dedans, ok c'est intéressant, mais c'est le minimum que l'on puisse demander au langage en fonction de ce pourquoi il a été prévu. Dans une base de donnée relationnelle normalement tu SAIS quelles sont tes relations et tes clefs, parce que se sont TES données, si ce n'est pas le cas, il y a un problème, mais tu peux encore utiliser (en MySQL) des commandes comme SHOW ou DESCRIBE pour comprendre comment la base est foutue de la même manière que tu fais tes requêtes sur ton fichier RDF. Franchement personne ne veut faire un SELECT * FROM * en SQL, cela n'a pas de sens. Si tu veux dire par là que SPARQL est vachement plus élégant et simple que SQL, je te renvoie à ma première remarque, ce que tu montres est poussif et pas plus simple.

Bisous !

Quand tu dis que RDF ne casse pas trois pattes à un canard, en surface peut-être, mais quand tu fouilles un peu, tu t'aperçois que c'est diablement efficace et que les choses simples sont toujours les plus complexes à obtenir. Le principe de l'utilisation des URI et des espaces de noms sont d'une importance capitale dans l'utilisation de la logique des prédicats. Je pense qu'on sous-estime à tort le potentiel de RDF en lui-même.

Pour la requête, tu peux me faire confiance, que diable ;-) J'ai hésité avant d'afficher cette requête, car, effectivement, elle rend pas hommage à Sparql. Mais, j'ai préféré être honnête et montrer le travail qui reste encore à accomplir par Dbpedia. Il faut comprendre que ces différentes propriétés désignent la même chose, mais cela provient des données hétérogènes récupérées de Wikipedia. J'aurais dû prendre une requête plus simple. C'est mon honnêteté qui a pris le dessus.

Pour le SQL, tu dois avoir raison, je me suis laissé emporter par mon a priori négatif (mais je reconnais l'avantage des BD relationnelles ;-) ). Je vais retirer cette partie qui est confuse et n'apporte rien (Merci !) et me contenter de la comparaison avec les Web-services. Mon propos est bien de montrer que tu n'as pas besoin de connaître une modélisation pour attaquer les données. Or, avec un Web service, tu es obligé de connaître tes verbes et ta structure de données pour faire une interrogation. Ça me semble un vrai avantage pour Sparql.

Quant à la syntaxe, il faudra que je retrouve une référence qui comparait une requête en SQL et en Sparql pour interroger certaines données. Dans des cas assez complexes avec l'équivalent de jointures..., Sparql reste plus simple et plus facile à maîtriser que SQL. Ce sera pour un prochain billet.

Ho par pas casser trois pattes à un canard, je voulais surtout dire que ça servait a pas grand chose tout seul, pas que c'était pas bien. Disons que c'est un peu comme XML, tout seul ça vaut pas tripette, c'est l'ensemble des technologies qu'il y a autour qui rende le tout intéressant. Et en fait, je n'avais pas regardé du côté de SPARQL, donc j'ai trouvé cool de pouvoir en avoir une petite approche par ton billet :-).

Pour les comparatifs c'est pas forcément utiles, j'ai l'habitude des hackers d'un langage qui montrent comment son langage est supérieur à un autre et qui met d'un côté un code très tuné et de l'autre un truc qu'un débutant du langage n'oserait pas faire. Les mecs de MS avaient voulu comparer leur super shell à celui d'UNIX comme ça. Bon c'est dommage, ils auraient dû apprendre à utiliser le shell UNIX avant. Cela ne fait pas de leur shell un mauvais shell, mais de leur article un article pas très intéressant. Maintenant si SPARQL évite les écueils de langages de requête précédents, je ne peux que le féliciter.
Sans rentrer dans un débat SPARQL / SQL je suis assez d'accord avec Got sur le fait que poser une requête SPARQL est plus simple qu'en SQL. Ou plus généralement que raisonner sous forme de graphes RDF est plus simple et intuitif que de penser structure de données (au sens SQL). Admettons que je veuille récupérer sur une plate-forme de blog tous les posts de l'utilisateur X postés il y a moins de 3 jours. Dans le cas de SQL, il faut avoir connaissance du modèle de BD de l'appli qu'on utilise et donc voir comment sont organisés les tables entre elles, etc ... Avec l'autre inconvénient que pour chaque outil, on va devoir refaire le travail. A l'opposé avec SPARQL, on raisonne en terme de modélisation des connaissances sans se soucier de l'appli, puisque le graphe RDF et la requêtes SPARQL correspondent de façon assez naturelle à ce que l'on souhaite exprimer. En fait, le seul travail est d'adapter sa requête à une modélisation en triplets. Dans ce cas, transcrire "tous les posts de X de moins de trois jours" en "récuperer Y tel que Y est un post, Y a pour auteur X, Y a une date inférieure à J-3". Une fois ce travail fait, la requête SPARQL peut s'ecrire sans douleur, si bien sur on sait qu'il faut utiliser SIOC / FOAF ou l'ontologie X pour exprimer telle propriété. (mais la aussi, cette ontologie dépent des données et pas de la façon dont elles sont stockées). Et la requête peut ensuite être appliquée sur n'importes quelles données modélisées avec les mêmes vocabulaires. Pour la requête sur Dbpedia, rassures toi, c'est en général plus homogène :) Mais le cas de DBpedia est différent puisque les propriétés sont extraites par un algo qui pour le moment ne fait pas de matching ou de définition de sous-propriétés entre celles-ci. Dans un cas idéal bien entendu on ferait la requête avec une unique propriété.
Je ne pense pas qu'on puisse dissocier SPARQL à SQL. SPARQL permet d'exprimer des requêtes independemment de la représentation physique des données (XML, base de données relationnelle/Object, etc.). Les bases de données sémantiques qui apparaisseront, suivant leur representation interne, devront offrir des entrées SPARQL sur leurs données. Et un moteur interne devrait permettre de convertir les requêtes SPARQL dans le langage d'interrogation interne. Par exemple, pour une base de données relationnelle, on aura un mapping SPARQL/SQL. Il y a des solutions qui existent sur le net comme virtuoso, d2R server qui permettent de faire des requêtes SPARQL sur des BD Relationnelles. Ces solutions sont très interessantes au sens ou elles permettent d'extraire le schema des tables des bases données relationnelles et de les convertir sous forme de classes d'une ontologie. L'administrateur a la possibilité de mapper ces classes avec une ou plusieurs ontologies partagées (FOAF/SIOC, etc.). J'encourage vraiment à les tester et en parler autour. Car je pense, si on veut que le web de données soit une realite, ca sera par ce type d'outil vu que les données des entreprises sont representer pour la plupart dans des BD Relationnelles.
Très intéressant ce commentaire. Tim Berners Lee y fait allusion dans l'entretien accordé à la recherche quand il parle de D2R, de l'université libre de Berlin (http://sites.wiwiss.fu-berlin.de/suhl/bizer/d2r-server/), comme d'une "moulinette". Je pensais que cette approche se faisait en mode "batch" pour basculer dans une représentation des données en RDF, mais qu'elle n'impliquait pas un couplage permanent "SPARQL/SQL" ou le mapping se ferait au fil de l'eau et en fonction des requêtes. A la relecture des specs de D2R il s'avère que ce couplage se fait bien au fil de l'eau. Ce qui est à la fois intéressant car on garde l'existant, mais pose des questions au point de vue du temps de réponse et de la performance globale. Heureusement que Got va rapidement faire des essais pour nous dire :-)
Jusqu'à quel point peut-on dire que l'on peut interroger un end point sans rien en connaître ? - Dans le cas le plus générique ou je ne connais rien du end point, un DESCRIBRE est peut-être plus opportun qu'un SELECT pour décrouvir la structure et el contenu des données - Pour les autre exemples il faut à minima une bonne connaissance des URIs, que tu as a propos de DBPedia - Personnellement je ne savais pas qu'il y avait tous ces CityOfBirth, PlaceOfBirth, etc. donc j'aurai formulé une requête sûrement très incomplète. In fine : comment savoir que l'on a réellement une réponse exhaustive à la question que l'on se posait ? Avoir des premières réponses est bien mais ne pas savoir si ces réponses sont exhaustives implique quand même une bonne connaissance de la structure et du contenu des données. Là, tout de suite, je n'ai pas de réponse, mais il doit y avoir des "méthodes de test" à lancer après une requête SPARQL pour vérifier que l'on est pas passé à côté d'une information importante. La liberté peut être un piège.

Je dirai que, d'un point de vue théorique, SPARQL permet de connaître toutes les données d'un RDF store, c'est à dire que la syntaxe et langage de requêtes en lui même offre cette possibilité. Dans les faits, c'est effectivement beaucoup plus complexe. Cela dépend évidemment de la taille du RDF store, mais dans le cas de Dbpedia, il m'a fallu quelques heures de découverte avant de commencer à bien maîtriser le RDF store. Pour ne donner qu'un exemple, je me suis aperçu que Dbpedia limitait le nombre de réponses renvoyés en faisant une requête limitant le nombre de réponses avec LIMIT et en naviguant entre les différentes pages de réponses avec OFFSET...

Bref, ce n'est pas encore gagné, c'est vrai, mais je suis persuadé qu'il n'est pas compliqué de mettre au point une application qui attaque n'importe quel sparql end point pour déterminer automatiquement la structure des données et le contenu.