Le développement de l'industrie informatique se réduisait à ses débuts…
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/
Previous Post: Open data et web de données : convergence ?
RDF ne permet de parler que de faits simples. Considérer que les entitées ne sont que des URIs est à mon avis une erreur (ce n’est pas votre propos, je commente juste de manière générale). La communauté doit revenir à la notion fondamentale de ressource pour parler de Linked Data. Ensuite, HTTP fournit déjà tout ce qu’il faut pour parler de « diachronicité » et même de versionnement. Il n’y a aucun besoin d’ajouter cette information au niveau RDF, et ça serait même une erreur à mon avis.
Pour ce qui est d’API ou de rendre la vie du développeur plus simple, je pense que LDP http://www.w3.org/2012/ldp/charter va dans la bonne direction.
Bonjour Alexandre, merci pour votre commentaire, pour y répondre :
Merci pour le pointeur vers le LDP, je vois qu’effectivement cela va dans la bonne direction.
Quand vous dites « Considérer que les entitées ne sont que des URIs est à mon avis une erreur », comment faudrait-il à votre avis les considérer ?
Sur l’aspect temporel, effectivement, HTTP fourni déjà la possibilité de faire une négociation de contenu en fonction de la date d’une ressource, c’est ce qu’exploite le framework mememtoweb en définissant le header « Accept-datetime », qui pourrait se généraliser à un numéro de version. Cela fournit/fournirait donc un moyen pour un client de récupérer l’état d’une ressource à une date donnée. Cependant pour pouvoir renvoyer une représentation des ressources d’un système à n’importe quelle date, il faut, dans le backend sous-jacent, avoir la capacité d’exprimer le fait que chaque triplet est associé à une certaine plage de validité. Cette possibilité n’est pas donnée par RDF, ce qui exclut de systèmes à base de RDF (sauf extensions propriétaires) dans ces backends. Sans parler de la possibilité d’interroger un endpoint SPARQL en lui demandant d’executer la requête avec l’état des données à un instant t.
En gros, par rapport à la temporalité, quand je disais que tous les projets demandent maintenant des fonctions de prise en compte des évolutions dans le temps, on rencontre les besoins suivants :
– besoin d’avoir une pise d’audit (savoir qui a fait quoi quand) (ce qui est adressé par le PROV-WG)
– besoin d’accéder à l’état d’une ressource à un instant arbitraire
– besoin d’interroger les données telles qu’elles étaient à un instant t arbitraire
– besoin de « tagger » des versions de données et de pouvoir accéder à une version précise des données