APICulture et DataCulture à la lumière du facteur temps

by Christian on 19 décembre, 2012

Lors de la conférence APIdays qui s’est tenue les 3 et 4 décembre 2012 (merci à faberNovel et Webshell), j’ai profité de mon intervention pour revenir sur la distinction entre OpenAPI et OpenData, entre APIculture et DataCulture.

J’ai rappelé que les deux approches s’inscrivaient toutes deux dans une logique de publication “pour les machines” et que donc l’enjeu commun passe par la publication d’un catalogue.

Le catalogue est l’interface.

Dès lors l’alternative entre OpenAPI et OpenData peut être formulée de la manière suivante : dois-je publier une liste descriptive des données ou une liste des requêtes ?

J’ai donc proposé quelques critères pour répondre à cette question.

Le premier concerne la richesse des données : plus la richesse des données et des liens entre ces données est importante, plus on privilégiera l’approche OpenData en s’appuyant sur des formats capables de supporter richesse des données et richesse des requêtes (RDF).

APIdays - APIculture DataCulture.014-001

C’est hélas le malheur des initiatives OpenData portées par la puissance publique (nationale et territoriale) que d’avoir opté pour l’approche publication des données avec une qualité des données trop pauvre pour être exploitable par les machines. Chacun connaît le résultat : on a publié des ordures de données, ce qui nuit à l’Open Data et à l’émergence du web de données.

Je sais bien qu’il y a des étoiles qui valorisent l’intérêt de publier des données, mais certains en ont déduit que publier des corpus de données avec une ou deux étoiles était “mieux que rien”. Eh bien non, je dis dis que si on n’a pas au minimum 4 étoiles on ne doit pas publier ses données si on veut s’inscrire dans le web of data.

 

Autre critère de choix : la rapidité du service et la scalabilité des architectures logicielles. Si ces questions sont premières, alors il faut privilégier les API, ce qui implique souvent que le nombre de types de requêtes est faible et qu’on les connaît par avance, ce qui est rarement le cas avec des corpus de données riches.

Avant dernier critère : si le catalogue qui est ainsi publié nécessite des fonctions d’écriture, de modification et d’enrichissements des données par le public, alors il faut oublier l’OpenData (un jour peut-être..)

Dernier critière sur lequel je suis revenu, le facteur temps, que j’ai illustré par le schéma ci-après :

Ce shéma représente en abscisses le facteur temps, du temps réel au temps long. L’axe des ordonnées représente la valeur croissance de ces données. Ce schéma n’est pas scientifique, c’est une représentation symbolique de la manière dont je comprends l’articulation entre APICulture et DataCulture au regard de leur valeur d’économique qui évolue dans le temps.

Plus on va vers des données publiées il y a longtemps plus il y a une prédominance d’une économie de la mémoire qui relève d’une culture de type encyclopédique. A l’inverse, plus on est dans le diktat du temps réel et de la fraîcheur de la publication, plus on est dans une économie de l’attention et une culture marchande.

Enfin, j’ai mis deux couleurs différentes à la valeur économique selon que l’on est dans l’APIculture (Bleue) ou dans la DataCulture (Verte) pour signifier que la valeur économique de l’une est une valeur d’usage là où l’autre est une valeur pratique. Cette distinction est fondée sur la distinction entre usage et pratique, sur laquelle il faudra que je revienne (cf Distinguer les usages des pratiques).

Enfin, j’ai rappelé que, quelque soit le mode de publication choisi, puisqu’il s’agit d’une publication sur des architecture logicielles distribuées, l’interface reste fortement dépendante des messages échangés : si toute la richesse des données ne peut pas être véhiculée “dans le message”, personne n’en saura jamais rien. Aussi faut-il rappeler que le message est l’interface.

Print Friendly

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 France License.

Signaler sur Twitter

{ 4 comments… read them below or add one }

Leave a Comment

{ 3 trackbacks }

Previous post:

Next post: