• 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. »

—

Cet article Open Data versus API est apparu en premier sur Sparna Blog.

Les mouvements du « Data Is King »

Le principe « Data is King » sous-tend les mouvements suivants :

L’Open Data : l’ouverture des données (publiques avec data.gouv.fr ou privées) induit une structuration de l’écosystème des acteurs en deux : d’un côté ceux qui produisent la donnée, de l’autre côté ceux qui l’utilisent ou la réutilise (par une posture de neutralité nécessaire, le producteur de la donnée ne peut pas être celui qui illustre son utilisation dans une application, sous peine de perdre cette impartialité quant à la donnée). Cette structuration illustre parfaitement la notion de réutilisation des données dans plusieurs applications.

Le Web de données, ou sémantique : la notion de web de données, tout en étant antérieure dans le temps à la notion d’Open Data, en est en fait l’aboutissement, la dernière marche au niveau qualitatif. Un peu comme si, se rendant compte que la barre du web sémantique avait été mise trop haut, les architectes du web avaient mis là une marche intermédiaire : publiez vos données d’abord, peu importe le format. Pour ce qui est des aspects propres au web de données, à savoir l’identification des concepts avec des URI et les relations avec d’autres données, hé bien, on verra plus tard, une fois que cette marche aura été franchie. Sous cette problématique se retrouve là encore le « Data is King », les promesses du web en plus : décentralisation, liens, accès par tous et partage par tous.

Gestion du contenu et SEO. Finit le SEO à base des quelques mots-clés mis au bon endroit dans la page. Depuis schema.org, ce qu’il faut pour « ranker », ce sont des données structurées. La promesse de remonter dans les résultats de recherche va inciter les web agencies et les producteurs de contenu à publier leurs métadonnées, voire à produire lorsqu’elles n’y sont pas. On va pouvoir se passer de moteur de recherche dans les systèmes, se contenter de publier de la donnée structurée, et tout faire reposer sur Google pour l’indexation.

L’autre buzzword du moment, Big Data, n’est pour moi pas lié à cette philosophie « Data Is King ». Le Big Data, c’est d’abord de gros algorithmes permettant de traiter beaucoup de données, l’accent est plus mis sur l’infrastructure, la performance, et la scalabilité, que sur les données elles-mêmes.

Les échelles du « Data Is King »

Le principe « Data is King » se retrouve à plusieurs échelles. A l’échelle des applications d’abord, où l’on va privilégier la modélisation claire des schémas de données, et – au minimum – s’assurer que les données ne sont pas prisonnières des applications, voire privilégier dès le départ une politique d’ouverture des données des applications. On le voit avec un peu de recul, les applications passent, les données restent, il est donc capital de faire en sorte que les données ne sont pas propres aux applications, qu’elles peuvent être réutilisées dans d’autres contextes. On ne développe plus des applications, on développe des données; d’autres développeront les applications qui viendront tirer avantage de ses données. La donnée fait partie du capital de l’entreprise, l’application n’en fait pas partie.

A l’échelle des architectures applicatives ensuite, où l’on passe d’architectures orientées services (SOA) à des architectures orientées données, qu’on pourrait appeler DOA par jeu d’opposition. Cela est directement lié aux architectures REST, mais va un peu au-delà, dans la mesure où REST, bien que nécessitant d’identifier des ressources par des URIs, ne privilégie pas nécessairement les données sur le document. Il est plus facile de décentraliser les données et de centraliser les services que de décentraliser les services et de centraliser les données. La promesse d’interopérabilité du SOA et de SOAP est d’emblée dépassée par les architectures REST.

A l’échelle du web enfin, où l’on est en train d’ajouter au web des documents un web des données. Les liens de cette nouvelle couche de la toile ne se font plus de page à page, mais de données à données. Les données sont publiées, interreliées, interprétables par les machines, réutilisables.

Vive le roi Data !

Cet article Data Is King ! est apparu en premier sur Sparna Blog.