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 }

Mike Amundsen (@mamund) décembre 19, 2012 à 11:27

(Please pardon my reply in English)
Interesting post. Regretfully, I think I missed your talk at APIDays. This notion of choosing between OpenAPI and OpenData, while in common practice today, need not be so. In fact, it is my opinion that failure to merge the two (programming interface and data access) will mean a serious failure for all.

Instead, I suggest that, as your post claims: « The message IS the interface » In most Web-based HTTP OpenAPIs today, there is no message, just function. In most RDF-based OpenData today there is no message, just data. The *message* (e.g. the response to a request) should include both data and function. That is to say the response should represent both the « what  » and the « how. » To date, the best way to accomplish this is to include hypermedia controls (query guides and write templates) in the response *with* the data. Until this becomes common again, it is my opinion that we will continue to see trade-offs and compromises in creating usable data on the Web.

Cheers.

Répondre

Christian décembre 20, 2012 à 9:00

Yes Mike, I learnt this from you. Including the fact that RDF do not need an API but an appropriate hypermedia type.
Thanks for the comment

Répondre

ht décembre 20, 2012 à 10:56

Le problème c’est que personne n’aime RDF. Pas grand monde en tout cas. Les apôtres du Web Sémantique, oui, mais les data hackers, non. Trop complexe, trop verbeux, trop illisible, trop lourd.

J’étais récemment à la conf STRATA, et j’ai assisté à une présentation de datamarket.com. Ses concepteurs revendiquaient 3.5 stars, qu’ils définissaient, en gros, comme l’utilisation de CSV correctement structuré et documenté. Je ne dis pas que c’est un exemple à suivre, mais clairement ça illustre le découragement de beaucoup devant une utilisation grandeur nature de RDF.

Répondre

Christian décembre 20, 2012 à 11:35

Ce n’est pas RDF qui est le problème, c’est bien sa sérialisation et le mediatype utilisé.
J’ai quand même des doutes sur l’intérêt d’utiliser CSV. HTML 5 est quand même ce vers quoi je tendrai plus facilement en ce moment.

Les slides de la conférence à STRATA que vous évoquez : http://blog.datamarket.com/2012/10/25/presentation-at-strata-ny-october-2012/
Merci pour le commentaire

Répondre

Leave a Comment

{ 3 trackbacks }

Previous post:

Next post: