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.