Les petites cases

Dbpedia en action la suite

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"

Poster un nouveau commentaire

Le contenu de ce champ ne sera pas montré publiquement.
  • Les adresses de pages web et de messagerie électronique sont transformées en liens automatiquement.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.

Plus d'informations sur les options de formatage

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
11 + 1 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.