Open Data versus API

Un billet publié récemment par Christian Fauré comparant les approches d’ouverture des données par rapport à la mise à disposition d’une API [1] m’inspire quelques marques d’accord et de désaccord :

• Principal hochement de tête approbateur : le concept de dataware et d’autonomisation des données, les données en elles-même et pour elles-mêmes, comme dans mon précédent billet. Avec ce que cela implique de bouleversement dans la façon de concevoir les systèmes et les interactions au sein du SI.

• Principale grimace de désaccord : la notion de « vérité éternelle des données ». Je crois que c’est une vue de l’esprit qui n’a pas cours dans la réalité. Tous les projets de gestion d’ontologies, de thesaurus, de catalogues, demandent et requièrent maintenant des fonctions de versionnement et de prise en compte des évolutions des données dans le temps. Toutes les données changent dans le temps. Toutes. Même le classement d’un catalogue d’archives évolue dans le temps. On s’étonnera que cette notion d’évolution dans le temps des données (« diachronicité des données ») n’ait pas été prise en compte au niveau le plus bas des standards du web, RDF, ou même les URI (et on consultera le projet memento [2] avec intérêt si on est titillé par le sujet). Quel orgeuil, quand on y pense, de croire que les éléments d’information que l’on encode à un certain instant sont obligatoirement les bons, ou qu’ils resteront valides éternellement.

• Bref. Pour passer à un autre point, effectivement, le principe de base du Linked Data est que la connaissance de l’identifiant d’une chose suffit pour accéder à une représentation de cette chose; inutile de connaitre une API, ou de passer par le biais d’une interface pour accéder à cette représentation.

• Ce n’est pas étonnant que l’ouverture des systèmes à travers des API soit plus populaire que l’ouverture des données « tout court » : l’API est pensée pour le développeur, elle prend en compte ses cas d’usage pour les simplifier, là où le Linked Data se garde bien de lui faciliter la tâche car justement, cette approche se concentre sur les données en elles-mêmes, sans préjuger de leur mode de réutilisation. Pour un développeur, il est bien plus facile de développer des applications à partir d’une API qu’à partir de données brutes; comment faire pour implémenter un simple écran de liste (de lieux, de bâtiments, de n’importe quoi) uniquement à partir des URIs des données ? cela nécessite plusieurs appels et un parsing du résultat non trivial. Là où une API fournira un seul appel, renvoyant uniquement les données utiles, dans un format simple.

• On en arrive donc à dire que publier des données sous forme de Linked Data ne permet pas leur réutilisation simple. C’est paradoxal, puisque c’est l’objectif affiché. Il faut que l’ouverture des données fasse un pas de plus vers le développeur. Des outils comme Elda [3] et la proposition du Linked Data API [4] sont exactement là pour franchir ce pas : »For some web developers the need to understand the RDF data model and associated serializations and query language (SPARQL) has proved a barrier to adoption of linked data. [The Linked Data API project] seeks to develop APIs, data formats and supporting tools to overcome this barrier. Including, but not limited to, accessing linked data via a developer-friendly JSON format. »

—

[1] DataCulture et APICulture : http://www.christian-faure.net/2012/09/20/dataculture-et-apiculture
[2] Memento project : http://mementoweb.org/
[3] Elda : http://code.google.com/p/elda/
[4] Linked Data API : http://code.google.com/p/linked-data-api/