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

Puis Bill Gates, pillant l’idée à Steve Jobs (voir le film « Pirates of Silicon Valley« ), qui lui même avait du la piller à quelqu’un d’autre, décida de séparer les programmes de la machine, et de se concentrer sur le software (en français, le logiciel). Le software était devenu indépendant de la machine. Les données étaient alors partie intégrante des applications (impossible de « prendre » les données d’une application pour les copier vers une autre).

Aujourd’hui, avec l’avénement du web et les besoins qu’il engendre d’interopérabilité et d’échange entre acteurs ou entre applications, nous entrons dans l’ére du dataware, c’est-à-dire dans un moment où les données sont autonomes des applications. Il est désormais possible de travailler sur les données en elle-mêmes et pour elle-mêmes, indépendamment de l’application qui va les utiliser, elle-même indépendante de la machine sur laquelle elle s’éxecutera. Une même application peut-être installée sur plusieurs machines, une même donnée pourra être consommée par plusieurs applications.

Le dataware est un concept forgé par Ars Industrialis et Christian Fauré. Ce dernier nous rappelle que « -ware » vient d’un mot écossais signifiant « objet de soin ». Je propose la définition suivante de « dataware » : le « Dataware » est la sous-partie de l’industrie informatique qui s’intéresse aux données (les data), dans leur dimension autonome des applications. C’est-à-dire en ce qu’elles sont échangées, publiées, envoyées, récupérées, consommées, etc. Cette dernière précision me semble importante, car elle permet de distinguer la gestion des data d’une application propriétaire et fermée, et la gestion des data pour elles-mêmes.

A partir du moment où on commence à cerner les limites d’un sous-ensemble autonome de problématiques sur les données, on peut imaginer tous les métiers qui vont avec, et parler d’ingénierie des données, d’éditeur ou de fabricants de données, de consultants en données, etc.

—
* : certes la citation est controversée, cependant les chiffres de ventes du modèle IBM 701 en 1953 sont d’à peine une vingtaine d’unités, ce qui montre bien que la demande à cette époque se comptait en quelques unités perdues disséminées dans les labos de recherche.

Cet article Le dataware est apparu en premier sur Sparna Blog.