Les petites cases

Dbpedia en action la suite

Saviez-vous qu'Emma Watson, alias Hermione Granger dans les adaptations au cinéma d'Harry Potter, est née à Paris ?

Pour ma part, je l'ai découvert en mettant au point une autre série d'exemples d'utilisation de Dbpedia, en m'interressant cette fois-ci aux personnes. Le principe est simple, vous choisissez dans la liste la ville qui vous intéresse, par exemple, Paris et vous découvrirez les différentes personnes nées dans cette ville et présentes dans Dbpedia, c'est à dire dans Wikipédia. La mise en forme et la navigation dans la page de résultat est assurée par l'excellent logiciel/script du projet Simile, Exhibit. J'ai volontairement limité la liste des villes, car le principe est toujours le même. J'en ai profité pour placer un lien directe vers cette page depuis la carte des capitales européennes.

A l'issue de cette deuxième série de tests, deux constats s'imposent :

  • le manque de structuration et de cohérence de Wikipedia apparaît clairement voire cruellement et l'initiative Dbpedia représente un moyen d'y remédier, en mettant en avant les problèmes 
  • Dbpedia limite automatiquement le nombre de résultats renvoyés pour les requêtes (j'imagine pour des raisons de ressources et de performance au niveau des machines) ce qui empêche d'avoir une vue complète et exhaustive des ressources stockées, c'est un peu dommage, même si c'est compréhensible 

Malgré ces constats, je reste époustouflé par le travail accompli à la fois par Wikipedia et par les équipes qui ont mis au point Dbpedia. Il existe tellement de possibilités pour exploiter toutes ces données que ça en donne le tournis. Pour ne donner qu'un exemple trivial, il y a moyen de faire un formidable site sur l'histoire du football, puisque vous trouvez l'ensemble des joueurs, clubs, championnats, finales des différentes compétitions avec leurs résultats... Il n'y a guère que votre imagination et quelques petites connaissances en programmation (si peu, vraiment) qui vous limiteront.

Pour ma part, je vais encore mettre au point un exemple que j'ai promis à Manue pour l'aider dans sa quête du Web sémantique en bibliothèque et je m'arrêterai là. Je pense que je pourrais y passer des heures et des heures (pleins de données dans des petites cases, vous pensez bien que ça me plaît ;-) ), mais cela ne servirait que peu mon but initial qui était de montrer l'intérêt des technologies du Web sémantique (est-ce que c'est un peu plus clair maintenant avec des exemples précis ? N'hésitez pas à demander si vous voulez que je décortique un des exemples). Ce sera donc à votre tour d'exploiter toutes ces données.

Sparql Wikipedia Geekeries Linked Data — 

Commentaires

"Je pourrais y passer des heures et des heures" : ya qu'à voir l'heure à laquelle il a posté ce billet. Et ne me dites pas que moi je suis matinale, ya école ce matin.
Pour moi le principal avantage de SPARQL est de permettre de joindre des sources de données hétérogènes (ne respectant pas le même vocabulaire) très facilement. Tu ne devrais donc pas te limiter à Dbpedia comme source de données, sinon le potentiel de pouvoir lier des graphes n'apparait pas. L'autre point génial de SPARQL est de pouvoir retourner un graphe en résultat que tu as ensuite la possibilité de pouvoir browser! Tu n'es plus juste limité à un bête resultset à plat, mais tu obtiens un graphe dans lequel les relations d'origine (et possiblement des nouvelles) sont présentes. Cerise sur le gateau, la requête SPARQL a pu te servir à unifier les vocabulaires hétérogènes de tes sources de données vers un vocabulaire (ontologie) métier. Le problème avec Dbpedia, et plus particulièrement avec les enpoints SPARQL qui implémentent le protocole SPARQL (http://www.w3.org/TR/rdf-sparql-protocol/), est qu'actuellement ils ne peuvent pas être intérrogés en même temps qu'une autre source RDF par une seule et même requête : SPARQL ne le permet pas, la syntaxe ne le permet pas. Une fois que cette limitation sera levée, nul doute que les processeurs SPARQL adaptés fleuriront.

Merci pour ton commentaire. Je suis d'accord avec toi sur l'avantage de SPARQL que tu cites, même si il ne représente pas le principal à mes yeux. Mais, j'avoue ne pas m'être plongé dans cette possibilité de SPARQL.

En revanche, je suis en désaccord avec la fin de ton commentaire, il est déjà possible d'interroger deux sources de données différentes avec une seule requête, même si c'est encore très expérimental. La syntaxe le permet via la fonction GRAPH voici un test avec Geonames et Dbpedia :

Lien vers le résultat de la requête

Et la requête sparql correspondante :

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX geonames: <http://www.geonames.org/ontology#>
SELECT ?francais ?grec ?population ?abstract
FROM <http://sws.geonames.org/2988507/about.rdf>
WHERE
{
<http://sws.geonames.org/2988507/> geonames:alternateName ?grec.
<http://sws.geonames.org/2988507/> geonames:name ?francais.
<http://sws.geonames.org/2988507/> geonames:population ?population.
<http://sws.geonames.org/2988507/> owl:sameAs ?lieu.
GRAPH ?lieu {
  ?lieu <http://dbpedia.org/property/abstract> ?abstract.
}
FILTER (lang(?grec)="el")
FILTER (lang(?abstract)="fr")
}

Un autre exemple avec Dbpedia et les données du recensement américain de 2000 : Les résultats de la requêtes

La requête correspondante :

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>
PREFIX census: <tag:govshare.info,2005:rdf/census/>
PREFIX dbpedia2: <http://dbpedia.org/property/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?state ?nb ?superficie
WHERE
{
?state owl:sameAs ?etat.
?state skos:subject <http://dbpedia.org/resource/Category:States_of_the_United_States>
GRAPH ?etat {
?etat census:population ?nb.
?etat census:landArea ?superficie
}
FILTER regex(str(?etat), "usgov")
}
Intéressant! mais tu contournes le problème :) Tes requêtes marchent seulement parce que tu utilises le endpoint dBpedia pour les executer. Dans ce cas, le processeur SPARQL qui execute la requête voit le graphe RDF de dbpedia comme local et peut donc y accéder directement. Le graphe de dbpedia est le dataset par défaut, tu ne le précises ni dans un FROM, FROM NAMED ou GRAPH. D'ailleurs dans ta 1ère requête, le graphe distant précisé dans le FROM est un "document" RDF, de même que dans le GRAPH de ta 2ième requête. Jamais tu n'indiques par exemple un autre endpoint SPARQL comme seconde source. De plus, si tu utilisais ton propre processeur SPARQL pour executer ta requète (et pas celui de dbpedia), tu n'aurais pas la possibilité d'interroger à la fois dbpedia et une autre source RDF. En gros tu ne pourrais pas mettre dans un FROM "http://dbpedia.org/sparql/" ... bon ok je sais pas si je suis plus clair cette fois... Remarque que cette liimitation se comprend : les graphes RDF précisés dans un FROM , GRAPH, etc... sont chargés localement dans la mémoire où se trouve le processeur SPARQL. On imagine mal charger localement en mémoire le graphe complet de dbpedia : au mieux on peut charger des sous graphes comme la ville de Paris... Le endpoint de dbpedia est un triple store capable de comprendre le protocole SPARQL. Personnellement j'utilise Jena pour mes requêtes SPARQL. Le processeur SPARQL de Jena (ARQ) comprend une syntaxe SPARQL modifiée qui lui permet d'éxécuter une requête à la fois sur un endpoint et une autre source RDF (http://seaborne.blogspot.com/2007/07/basic-federated-sparql-query.html).

"mais tu contournes le problème :)" : j'avoue dans un certain sens, mais je pense que je n'avais pas compris ta remarque comme tu l'entendais.

Je comprends mieux ce que tu veux dire, maintenant. Il n'est pas possible depuis un processeur sparql quelconque d'interroger deux sources de données et c'est tout à fait juste.

Dans mes exemples, je profite du owl:sameAs qui est tout l'intérêt du projet Linking of data, donc effectivement, j'interroge une ressource et pas un autre entrepôt RDF. Mais comme tu le fais remarquer, il faudrait mettre en mémoire tout l'entrepôt ce qui n'est pas possible.

J'aime bien cette idée de sparql endpoint, car ils renvoient vraiment à la notion de données structurées décentralisées mis à disposition directement sur le Web et cela évite d'avoir à utiliser un processeur Sparql, c'est un simple Web service.

Merci pour ton commentaire et la référence, c'est vraiment intéressant (et ça m'a permis de mieux comprendre ce que tu voulais dire ;-) ).

"J'aime bien cette idée de sparql endpoint, car ils renvoient vraiment à la notion de données structurées décentralisées mis à disposition directement sur le Web et cela évite d'avoir à utiliser un processeur Sparql, c'est un simple Web service." : Effectivement! c'est bien pour ça que j'ai commencé mon commentaire par "intéressant!" Travaillant avec mon propre processeur Sparql, je n'avais pas pensé à utiliser un endpoint comme un processeur sparql mais seulement comme une source RDF.... C'est clair que ca donne la possibilité à n'importe qui de bâtir une application SPARQL! Pas besoin d'un hébergeur particulier etc... Par contre une entreprise ne peut pas se reposer sur un processeur tierce pour ses applications. Et du coup l'accès aux données RDF de ce endpoint se trouve limité. Néanmoins on voit que ce n'est qu'une question de temps pour qu'une évolution de la norme SPARQL(?) permette ces accès mutliples.
Héhé, ton enthousiasme vis-à-vis de DBpedia ­- RDF ­- SPARQL me fait penser à quelques chose entre Jérôme Bonaldi, Science et vie Junior et Jean fourastié.
Je ne sais pas si je dois bien le prendre et il faudra que tu m'expliques ce que vient faire Jean Fourastié dans cette histoire... Et puis, si personne n'apprend rien, ne voit pas l'intérêt de ces exemples, au moins je me serais bien amusé.
Ho ! Il ne faut pas mal le prendre, je disais ça d'un ton amusé et pas méchant du tout. Tu me fais penser aux grands enthousiastes du progrès plein d'optimismes dans le futur et les nouvelles choses, ce à quoi correspondent dans ma tête les personnes et entités que j'ai évoqué. Il ne faut pas chercher plus loin, c'était un commentaire léger, désolé d'avoir été ambiguë.
Je confirme pour le captcha : a changer tout de suite. DBpedia peut attendre, pas le captcha !
Je ne sais plus si tu l'as écrit quelque part mais tu utilises quel client SPARQL pour faire tes requêtes ?

Comme la réponse est simple et rapide, tu y as le droit ce soir : j'utilise la classe RAP, RDF API for PHP : http://sites.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/ qui fut la première initiative des créateurs de Dbpedia pour le Web sémantique. Comme quoi ces types ont de la suite dans les idées !!

salut les gars je trouve vos post assez interessant mais si vous souhaitez faire de l'interrogation sur plusieurs sources differentes vous pouvez le faire depuis java avec JENA la methode de la classe QueryExecutionFactory sparqlService permet de le faire (API ARQ) vous pouvez voir la doc ici "http://jena.sourceforge.net/ARQ/javadoc/index.html"