Les petites cases

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