Blog de JP Gouigoux

Executive summary

Si vous n’avez pas le temps de lire cet article, un résumé en quelques points :

• OData est souvent comparé négativement à RDF, car plus limité dans ses ambitions.
• En pratique, RDF et SPARQL n’ont pas à ce jour réussi à faire leurs preuves pour de l’exposition de la donnée sur internet.
• Ils viennent d’une approche académique qui, sous couvert d’universalité des relations inter-sources, force pour son utilisation effective à reconstituer des ensembles de données couplées les unes aux autres.
• L’approche simplificatrice portée par REST, et donc OData qui en découle, apportera à mon sens plus vite des résultats en termes de valorisation de la donnée.

Le problème

L’origine de ce billet est dans la polémique existant ça et là sur la supériorité de RDF par rapport à OData pour l’exposition des données sur internet (voir également ici). Il y a, je trouve, beaucoup de subjectivité à déclarer qu’OData reproduit un modèle en silo, alors qu’il s’agit simplement d’un protocole. Pour moi, ça sent plutôt le rejet épidermique de développeurs qui n’ont pas changé leur façon de voir Microsoft depuis dix ans, alors que ces derniers ont réellement évolué dans leur approche de l’interopérabilité, du support des standards et de la relation à l’Open Source. Il y a pourtant plusieurs arguments à l’utilisation d’OData :

• OData est un protocole ouvert, licencié sous Open Specification Promise. Il a été proposé à la validation au consortium Oasis. SAP, IBM, et d’autres éditeurs majeurs supportent le protocole.
• RDF et SPARQL (le langage d’interrogation des datastores, bref le SQL de RDF) sont beaucoup plus compliqués à utiliser que le protocole OData, fondé sur une approche REST, favorisant la simplicité d’usage. N’importe qui peut utiliser un flux OData comme source de données dans une feuille Excel, tandis qu’il faut une personne formée spécialement pour écrire une requête SPARQL.
• Enfin, et c’est certainement le point le plus important, il n’y a pas d’incompatibilité entre les deux. Il est tout à fait possible de commencer par OData, puis de graduellement ajouter du RDF dans les sources.

RDF promet beaucoup, mais depuis dix ans, les mises en œuvre ont été très limitées. Le mouvement Open Data a poussé des technologies plus simples, comme OData ou GData. Pour moi, c’est un peu le même antagonisme qu’il y a entre les approches SOAP / WSDL / UDDI et les services REST. Les premières sont conceptuellement meilleures, mais le souci est qu’elles n’ont jamais donné leur mesure (UDDI est mort, par exemple, alors que cette norme d’annuaire de services était censé être la pierre angulaire de leur découplage), et c’est pour cette raison que REST a de plus en plus de succès : moins complexe, permettant d’obtenir des résultats rapidement, bref agile…

Décalage entre la théorie et la pratique

L’idée de RDF et du web sémantique est de créer des relations entre toutes les ressources disponibles sur le web, de façon que chaque URL puisse dynamiquement poursuivre sur une autre, qu’il soit possible d’appeler des contenus agrégés. Il devenait alors possible de parcourir n’importe quelle ressource de manière standard dans le monde, et le web devenait une gigantesque source de donnée semi-structurée. Inutile de recourir à des moteurs de recherche par indexation qui ne comprennent pas la sémantique des pages, mais parcourt bêtement des associations de mots… Le rêve. Mais ça, c’est la théorie.

Malheureusement, les choses se passent rarement comme prévues par les personnes qui inventent une technologie, et l’appropriation de celle-ci par ses utilisateurs sort souvent de ce qui était imaginé à l’origine. Pour le coup, c’est HTML qui a été le loup dans la bergerie. En mélangeant dans un langage à balise relativement simple le contenu et les liens entre les ressources, les URL pouvaient être incluses dans une page sans aucune sémantique. Encore pire, les informations qui auraient pu renvoyer à des URL, de façon à porter une information de manière formelle, n’étaient le plus souvent que mise en place sous forme de texte dans l’HTML.

Voici un bout d’HTML tout ce qu’il y a de plus banal :

C’est à peu près comme ça que sont écrites les milliards de page HTML en circulation dans le monde aujourd’hui. Le souci est que les partisans du web sémantique avaient en tête à l’origine que les développeurs écriraient quelque chose plutôt de ce genre :

Et encore, je ne vais pas au bout, car théoriquement, ce qu’on est censé écrire devrait aussi embarquer un lien pour la fameuse relation, par exemple pour la date :

Il est évident qu’avec une complexité pareille, tout est parti en sucette à la vitesse de l’éclair ! Comment ont-ils pu se tromper à ce point, et croire que les gens allaient créer du HTML parfaitement sémantisé ? Très simple : au début, l’internet était utilisé uniquement par des chercheurs, pour qui cette écriture extrêmement rigoureuse était simple, voire naturelle. Dès que les vannes de l’internet ont été ouvertes aux universitaires, puis au grand public, plus personne ne s’est soucié de ça. La course était plutôt à celui qui aurait le plus de couleurs dans sa homepage (pour les plus jeunes d’entre vous, la homepage était une sorte de blog, mais où on tapait tout le code HTML à la main, y compris la racine du site – voir ici pour un exemple, attention ça pique les yeux).

La fuite en avant

La suite, vous la connaissez : le web est un immense amas de données sans quasiment la moindre relation, et si on veut créer de la connaissance, il faut mettre en relation toutes ces données à la main. C’est là qu’interviennent tout un tas de méthodes pour essayer de reprendre la main :

• Les microformats : l’idée est de réintroduire à faible dose du RDF dans les pages HTML, en se basant comme je le faisais dans l’exemple plus haut sur certaines parties les plus importantes (la date de début de la conférence, le lieu, etc.). Les microformats sont, en gros, une manière simple d’écrire des triplettes dans un lien HTML. Il reste évidemment toutes les limites, à savoir la présence d’une ontologie normée. Surtout, la présence de microformats dépend du bon vouloir de l’auteur. Aujourd’hui, tous les navigateurs les supportent, mais c’est quand la dernière fois que vous avez vu une page annonçant une conférence, et votre navigateur qui vous propose de l’ajouter à votre calendrier car il a reconnu le microformat associé ?
• La norme HTML Microdata (http://www.w3.org/TR/microdata/), qui reprend là où les microformats ont échoué, en enlevant un peu de la complexité RDF, et ont du coup peut-être un peu plus de chance d’arriver à quelque chose. Surtout que ce coup-ci, il y a Microsoft, Google et de nombreuses autres grosses boites qui soutiennent cette utilisation.
• La Business Intelligence : l’approche de la BI est de dire “Moissonnons toute la donnée dont on a besoin, sur internet comme dans le SI, et faisons un énorme cube qui croise tout dans tous les sens à l’avance. Comme ça, quand on aura besoin de mesurer le taux de corrélation entre le nombre de babouins férus d’art néogothique japonais et le chiffre d’affaire de notre dernier logiciel, on pourra avoir les résultats super vite”. Je me suis déjà longuement exprimé sur la BI. Pour moi, la solution pour une BI réussie n’est pas un moteur de cube, mais se poser les questions sur ce qu’on veut savoir (ce qui est plus dur, mais apporte plus de valeur).
• Big Data : la BI ayant échoué, les constructeurs de machines avaient besoin d’une nouvelle embrouille technologie pour vendre du CPU. C’est le Big Data, dont l’approche pourrait être résumé, avec le brin de mauvaise foi qui caractérise votre serviteur, comme ceci : “La BI a planté, et au bout de 500 To, nous n’avons pas réussi à convaincre nos clients qu’il fallait encore plus de données dans le cube. De toute façon, nous avions déjà ratissé les fonds de tiroir chez eux… Donc, proposons-leur désormais d’aller croiser les données du babouin arty-nippon avec le nombre de tweets contenant le mot ‘néogothique’, ce qui nécessitera dix fois plus de machine pour un résultat aussi impressionnant”. Rendez-vous dans dix pour croiser le taux d’échecs des projets Big Data avec celui des projets BI. 82%, record à battre…
• Le web sémantique : je ne reviens pas sur ce point. L’échec était d’ouvrir le HTML (et même le web) à toute cette populace grossière qui n’a même pas un doctorat. Evidemment, on se retrouve avec de la donnée n’importe comment. Pour schématiser, c’est un peu comme si on laissait à des développeurs le rôle d’administrateur du réseau.
• L’internet des objets : de la même manière que l’arnaque BI est remplacée par l’arnaque Big Data, le web sémantique qui (après avoir annoncé son décollage immédiat depuis dix ans) commence à avoir plus que du plomb dans l’aile a trouvé son successeur : l’internet des objets. L’idée est de voir encore plus grand, avec tous les objets physiques de notre monde courant (du frigo au caleçon) équipés d’une adresse IPv6, et qui échangeront des données sémantisées en continu. Le rêve… Je vous laisse imaginer comment il finira : on n’a déjà pas réussi à se mettre d’accord pour sémantiser les dates et les auteurs des pages web, alors le faire pour chaque banane et bouton de culotte…

Le retour aux sources

Après ce (très) long exposé des problèmes autour du web sémantique, vous vous demandez certainement le rapport avec le comparatif OData / RDF que je vous ai infligé en entrée de ce billet… La réponse tient en un acronyme : REST.

REST représente le retour aux sources qui a apporté de la fraîcheur au web tel que nous le connaissons depuis quelques années. En repartant de la notion centrale de ressource, et en encourageant les développeurs à se réapproprier le sens des verbes HTTP, REST a participé, avec le renouveau de JavaScript, au Web 2.0, à la mise en place de services simples. Surtout, REST est resté sur le protocole, et n’a jamais prétendu à l’universalité des descriptions de ressources. Il est revenu aux fondamentaux : une ressource est identifiée par son URL, les verbes HTTP servent à la manipuler. Point. Pas de métadonnées superflues, pas de triplette, rien…

Les services de données doivent suivre cet exemple.

Comme le web sémantique, SOAP a connu l’échec (bien que dans des proportions bien moindres) car il était trop complexe. Pour un SI interne, ça passait car la lourdeur était supportable par rapport aux gains en termes de validation forte, mais pas sur internet. C’est pour ça que les services internet sont majoritairement en REST.

OData est un protocole basé sur REST.

C’est pour moi la force n°1 d’OData. Contrairement à RDF et SPARQL, qui cherchent à atteindre le Graal du web sémantique, OData ne fait pas le malin. Ce protocole se contente de réaliser de manière propre et standard le peu qu’il s’est fixé comme objectif. Mais il le fait bien, et surtout il est déjà largement assez puissant pour la grande majorité des usages de la donnée que nous allons avoir dans les dix prochaines années.

Le mur de la réalité

Pour revenir cette fois-ci tout à fait à notre problème original, OData a effectivement un problème de silo, bien qu’il ne soit pas constitutif du protocole, mais des sources existantes : les relations directes en OData sont limitées à la collection de données exposée. Par exemple, si un service de données expose la liste des communes, des départements, des groupements et des régions, il est tout à fait possible de faire porter au flux des relations entre les différentes entités. Par exemple, la notion de communes voisines pour une commune, ou la notion de région d’appartenance pour une commune. Mais cela s’arrête là, et si on souhaite connecter une ressource extérieure au service, il faut exposer son URL et prévoir une manipulation côté client pour la traiter.

C’est la promesse de RDF : des liens normalisés partout pour qu’une URL puisse suivre le lien sur une autre, et ainsi de suite. C’est ce qu’on appelle le Linked Data. C’est basé sur une approche sémantique forte. Et ça ne marche pas…

En tout cas, ça ne marche pas aujourd’hui. Alors oui, on peut espérer que ce n’est que transitoire, et que de plus de plus de liens vont se faire de manière normalisée. Mais aujourd’hui, et c’est la limite de la promesse de la sémantisation, les normes sont tellement peu nombreuses que le parcours des liens se fait obligatoirement par une interaction utilisateur ou logicielle, mais jamais automatique. Il est bien sûr possible de l’automatiser, mais ça se fait obligatoirement en connaissant la source de définition de la donnée sur laquelle on pointe. Bref, exactement la même limite en pratique que celle d’OData en théorie.

La réalité est que SPARQL et RDF sont des idées de laboratoire, bien trop compliquées pour croiser de la donnée au jour le jour. Quand on voit que même des articles de passionnés indiquent que l’inférence et le raisonnement automatique, bref les deux grandes forces de RDF, sont seulement “pour les plus braves”, ça doit faire réfléchir. Allez, une dernière preuve du manque d’efficacité de l’approche RDF : il faut un énième Working Group du W3C pour mettre en place le Linked Data. Rappelez-moi : ce n’était pas justement le but initial de RDF, puis de SPARQL ?

La route

Alors comment on avance en attendant ?

Déjà, on respecte scrupuleusement les enseignements de REST. C’est sûr que si des consommateurs voient dans les flux OData des identifiants comme ceux que produit OGDI par défaut, ça ne va pas aider à crédibiliser le protocole. Ceci par exemple est une horreur :

<id>http://datafeed.edmonton.ca/v1/coe/BusStops(PartitionKey=’1000′,RowKey=’3b57b81c-8a36-4eb7-ac7f-31163abf1737′)</id>

Le client qui consomme des arrêts de bus doit pouvoir accéder à sa donnée avec un identifiant qui fasse sens, comme par exemple :

<id>http://datafeed.edmonton.ca/v1/coe/BusStops(BusLine=’A21′,StopNumber=’3′)</id>

Ensuite, on ajoute le minimum de sémantique dans les flux pour que la valorisation soit au rendez-vous. Ce n’est pas compliqué de trouver des cas où les relations sont suffisamment simples pour qu’on pointe directement sur des URIs d’autres services.

Enfin, on fait attention à être cohérent dans les services de données. Pour cela, il suffit de garantir que les URI sont uniques et sont bien partagées entre les différents services, et pas seulement entre les différentes collections d’une même source.

En fait, le vrai travail est sur la structuration intelligente de la donnée et des services. L’exposition d’un format en elle-même représente moins de travail. Mais pour apporter de la valeur, c’est OData qui marchera dans les premières années, et peut-être au delà si RDF n’arrive pas à prouver sa valeur.

Ce n’est pas pour rien que Yahoo Pipes se base majoritairement sur du REST (voir test-drive de la technologie).

Bonus

Quelques références complémentaires :

• Le serveur Virtuoso, à surveiller sur ces sujets : http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/Ods
• Sur le même site, leur façon de publier des triplettes RDF sous forme de service OData : http://www.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtRDFODataExample
• La page DeveloperWorks (IBM) sur OData, comme toujours extrêmement bien documentée et avec une grande hauteur de vue sur le sujet : http://www.ibm.com/developerworks/webservices/library/standards-odata/