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