Bénéfices clés des technologies du web de données 1/2 – l’environnement distribué

Fondamentalement, les technologies du web de données (« linked data ») apportent 3 bénéfices : (i) elles permettent de manipuler ou de publier des données dans un environnement distribué, (ii) elles ne recquierent pas de modèle de données et (iii) elles permettent de faire de l’inférence, de trouver des nouveaux liens.

Par conséquent, les projets où le modèle de données est stable et qui n’ont ni besoin d’intégrer des données provenant d’autres systèmes, ni besoin de fournir leurs données à d’autres systèmes, n’ont pas de bénéfice à utiliser cette approche. Elle a tout son sens notamment dans les projets d’ouverture des données, d’open data (la donnée est distribuée et les modéles hétérogènes) mais il faut y sensibiliser les acteurs. J’examine dans ce premier post le premier de ces 3 bénéfices : un réseau de données décentralisées, distribuées.

L’environnement distribué, ADN du web

Tout comme l’hypertexte a révolutionné les contenus et les documents dans un contexte distribué (la façon de les écrire, de les diffuser, d’y naviguer), le web de données – on pourrait parler d’ « hyperdonnées » ou d’ « hyperdata » pour faire le paralelle – permet de prolonger encore cette approche en l’appliquant aux données des applications. C’est-à-dire en mettant en relation les données dans un environnement distribué.

Interrogation fédérée des données

Cet aspect distribué permet une interrogation fédérée des données. Plus la peine d’avoir toutes les données au même endroit pour les interroger. Dans le monde SGBD+SQL, pour interroger plusieurs sources de données, on doit forcément les avoir dans le même système. En RDF+SPARQL, le mot-clé SERVICE permet d’envoyer des critères de recherche à des sources de données différentes, et de combiner les résultats en une seule requête. Un exemple de requête sur le web de données est « donne-moi la date de naissance des acteurs de Star-Trek » (une première source de données a l’info des acteurs de Star-Trek, une source différente a leur date de naissance).

Interconnection des données

Cette approche distribuée permet également de combiner des données enfouies dans des systèmes propriétaires pour les réutiliser ensemble. Vous savez, c’est quand la comptable aimerait bien recouper des infos de facturation qui sont dans un CRM du genre SAP avec les feuilles de temps des employés qui sont dans une base Oracle… au XXème siècle on lui dit gentiment que ce n’est pas possible, au XXIème siècle on ajoute un middleware relationnel vers RDF, et hop, soit en utilisant une requête fédérée avec SERVICE (voir plus haut), soit en intégrant les données ainsi traduites dans un triplestore (voir le prochain post), le recoupement d’informations devient possible.

La même problématique se retrouve dans l’open data; comment utiliser ensemble des données sur les lycées, celles sur les collèges et les écoles, et d’autres sur la population pour créer une (hypothétique) application qui montrerait la carte scolaire ? en ayant normalisé ces données qui parlent de la même chose (« établissement », « nombre d’élèves », « latitude »,  « longitude », etc…), et en ayant fait des liens entre elles (« le collège se trouve dans le quartier X », et « le quartier X a tant d’habitants »). Notons que les bénéfices de cette mise en commun des données sont autant pour les utilisateurs des données que pour les collectivités elles-mêmes qui vont avoir accès en un point central à des données auparavant hétérogènes.

Enrichissement des données

L’interconnection des données permet de tirer parti des données qui viennent de l’extérieur du système développé. On peut ainsi enrichir un système interne qui utilise les technologies du web de données par des informations venant de sources de données externes : une photo provenant de DBPedia, une arborescence géographique provenant de Geonames (« France > Champagne-Ardenne > Marne > Arrondissement d’Epernay > Epernay »), les listes d’ouvrages d’un auteur provenent de la BNF, etc.

Qu’est-ce qui permet cet aspect distribué ?

Cette distribution n’est possible que parce qu’un certain nombre d’efforts ont été fait pour obtenir un accès unifié aux données. Cet accès unifié aux données passe notamment par :

• Une identification de chaque objet avec une URI, et la possibilité d’accéder aux données de cet objet simplement en « appellant » cette URI. Pas besoin d’une requête compliquée ou d’un protocole d’accès obscur, on utilise HTTP, le protocole du web; si on veut « référencer » un objet dans nos données, on indique simplement son URI;
• Un protocole d’interrogation standardisé : SPARQL. Attention, il y a bien non seulement le langage d’interrogation SPARQL, lui-même bien mieux normalisé que SQL dont les multiples variantes ne facilitent pas les migrations d’un outil vers un autre, mais également le protocole d’interrogation, qui permet d’interroger n’importe quelle source de données de façon standard, sans avoir besoin d’un quelconque « driver » comme en SQL.

Ces efforts de standardisation ont par ailleurs des « effets de bord » positifs :

• une plus grande indépendance vis-à-vis des outils. Si le protocole et le langage de requête sont standards, il est possible de commencer à utiliser des outils gratuits (Sesame, Jena) en phase de prototypage et de passer ensuite de façon transparente sur des outils commerciaux sans rien redévelopper;
• l’interrogation des données se faisant par le protocole HTTP, il est très facile de déployer un système de cache HTTP pour améliorer les temps de réponse. Ces outils de cache (par exemple Squid) sont largement connus et déployés par les administrateurs systèmes, là où les mécanismes de cache au niveau d’une base de données sont plus compliqués à mettre en oeuvre (outils propriétaires et plus bas niveau).

L’aspect décentralisé est dans l’ADN du web. Il est normal qu’il s’applique aux données après s’être appliqué aux documents. Il est également normal de parler de préférence de « web de données », et non pas de web « sémantique », adjectif vague, aux promesses floues qu’il faut sans cesse expliquer; le terme « web de données » est mieux défini et ses promesses plus concrètes.

Dans la deuxième partie j’examinerai les deux autres bénéfices clés des technologies du web de données : l’absence de schéma et les possibilités de raisonnement.