title: Opendata et liens cassés
slug: opendata-liens-casses
date: 2016-02-26
chapo: Le Web est un mandala sur lequel on souffle en continu.
*Ceci est un résumé de mon intervention à [Confoo](https://confoo.ca).*
> The quantity and variety of information we now produce has outpaced our ability to preserve it for the future. Librarians are the only ones who are making sure that our collective memory is preserved. And they, along with small teams of digital historians elsewhere, are still trying to understand the scope of myriad challenges involved in modern preservation. If today’s born-digital news stories are not automatically put into library storehouses, these stories are unlikely to survive in an accessible way.
>
> *[The Irony of Writing About Digital Preservation](http://www.theatlantic.com/technology/archive/2015/11/the-irony-of-writing-about-digital-preservation/416184/)* ([cache](/david/cache/b74e15baff22ce27ad96166f56bdff36/))
**Le Web est un mandala sur lequel on souffle en continu.** Nous serons potentiellement tous jugés pour crime contre le Web à force de participer à des [datacides](/david/biologeek/archives/20091202-discussions-sur-les-applications-web-libres/) en cassant volontairement des liens. Que faire individuellement et collectivement pour en prendre conscience et inverser la tendance ?
## Obsolescence numérique
> In addition to improving the usability of the temporal web and helping to ensure the preservation of collective cultural heritage, designing for archivability will also tend to optimize your website for access by other crawlers, boost website performance, enhance usability for contemporary users, and improve the likelihood that you’ll be able to refer to and/or recover historical versions of your own web content.
>
> *[Stanford University Libraries](https://library.stanford.edu/projects/web-archiving/archivability)* ([cache](/david/cache/5aa82a2b410df7ea8a2debd82d0502c4/))
Je ne vais pas reprendre les arguments [déjà détaillés par ailleurs](/david/blog/2014/un-web-omni-present/), la question n’est plus de savoir si vos données vont être hackées et/ou perdues mais quand. Est-ce qu’il s’agira d’un accident ? D’une attaque frontale ? D’un manque de soin apporté aux données ? D’une décision stratégico-économique ? D’une revente ?
Quelle qu’en soit la raison, il faut apprendre à vivre avec.
## Cacher le Web
> The ability to follow links down and around and through an idea, landing hours later on some random Wikipedia page about fungi you cannot recall how you discovered, is one of the great modes of the web. It is, I’ll go so far to propose, one of the great modes of human thinking.
>
> *[Follow the links](http://aworkinglibrary.com/writing/follow-the-links/)* ([cache](/david/cache/cbbb6529f7412868ba45d5e8b32323a5/))
Il existe [des outils permettant](http://archive.is/) de [cacher une page web](https://archive.org/web/), et même d’y accéder avec [un navigateur de l’époque](http://oldweb.today/) ou [d’y voyager](http://timetravel.mementoweb.org/). Cela fait maintenant [plus d’un an](/david/stream/2015/01/05/) que je mets en cache les articles qui sont liés sur cet espace les considérant comme importants pour la réflexion qu’ils initient. Il est depuis possible d’installer [un plugin Wordpress/Drupal](http://amberlink.org/) qui semble faire la même chose.
La question des [productions non textuelles](http://aworkinglibrary.com/writing/hypertext-for-all/) ([cache](/david/cache/ebd8dc34d8feec38a2810883d6741189/)) reste de mise et nécessiterait d’augmenter la taille du cache de plusieurs ordres de grandeurs. Celle [du design](http://wolfslittlestore.be/2012/11/archivability-of-the-web/) ([cache](/david/cache/76bd309dac6c1ddcb4dc3ee097a1bcb5/)) également et pose une vraie contrainte technique quand aux moteurs de rendus qui évoluent.
Que se passerait-il si cela devenait une pratique courante ? À quel point les [service workers](/david/stream/2015/11/24/) vont-ils permettre d’automatiser cela ? **Cacher une page non pas pour un rendu hors-ligne mais pour un rendu pérenne et/ou versionné.**
*Je me demande par exemple si l’intégration de [jsdiff](https://github.com/kpdecker/jsdiff) permettrait d’afficher les évolutions du [lexique](/david/lexique/) de manière personnalisée à partir de la version précédemment mise en cache.*
## Informer et éduquer
> The aim of this project is to provide a way to check HTTP resources: hunting 404s, updating redirections and so on.
>
> For instance, given a website that stores a list of external resources (html, images or documents), this product allows the owner to send its URLs in bulk and retrieve information for each URL fetched in background (status code and useful headers for now). This way he can be informed of dead links or outdated resources and acts accordingly.
>
> *[Croquemort](https://github.com/davidbgk/croquemort)*
Je travaille sur [data.gouv.fr](https://www.data.gouv.fr/fr/) depuis un an. La stratégie de la dernière version était de référencer plus que de dupliquer les données déjà hébergées par ailleurs. Nous manquions cruellement de visibilité sur la disponibilité de ces ressources distantes et nous avons décidé de développer un outil qui nous permette d’avoir des métriques à ce sujet. Ces données nous permettent d’avertir les producteurs en cas d’indisponibilité, d’informer les visiteurs de la non-disponibilité d’une ressource de manière quasi-synchrone et d’avoir un tableau de bord avec un score par producteur.
Croquemort va [croquer les orteils des liens](/david/blog/2015/croquer-liens/) à intervalles réguliers pour s’assurer qu’ils retournent toujours un *status code* pertinent. Il ne s’agit pas de culpabiliser ou de blamer les producteurs mais de les sensibiliser et de les responsabiliser pour avoir une discussion sur les origines de ces indisponibilités et trouver une solution ensemble.
## 5 ♥ de l’Opendata
Après les [5 ★ de Tim Berners-Lee](http://5stardata.info/en/), qui ont [bientôt 6 ans](https://www.w3.org/DesignIssues/LinkedData.html) ([cache](/david/cache/8df6b7af9ac944275a13f0d0e97ad7d7/)), il est temps de passer aux 5 ♥ plus contemporains (merci Twitter). Voici mes modestes propositions à challenger :
* **★ données disponibles (PDF) → ♥ pour longtemps** : il ne s’agit plus de rendre uniquement les données disponibles à un instant t mais d’assurer une disponibilité dans le temps et le cas échéant les redirections appropriées.
* **★★ données structurées (XLS) → ♥♥ et (ré)utilisées** : plus que leur structuration, c’est [la garantie](https://github.com/Quartz/bad-data-guide) qu’elles sont déjà (ré)utilisées en interne qui leur donne de la valeur.
* **★★★ données non-propriétaires (CSV) → ♥♥♥ et documentées** : si le format permet de *parser* plus rapidement les données, leur documentation permet de les comprendre plus rapidement et donc de les (ré)utiliser.
* **★★★★ données avec URI (RDF) → ♥♥♥♥ et redondantes** : le fait d’introduire des URI donne une grande responsabilité aux producteurs, un cache décentralisant doit être mis en place pour assurer la continuité de *liaison*.
* **★★★★★ données avec liens (LOD) → ♥♥♥♥♥ et versionnées** : les relations évoluent dans le temps et il faut penser le graphe des données en 3D dès son initiation, les [outils](https://www.mercurial-scm.org/) [techniques](http://git-scm.com/) existent pour avoir une traçabilité et un historique des modifications.
Avec cette itération des recommandations, l’accent est mis sur la qualité des données plus que leur quantité. Trop de portails Opendata exposent des données inutilisables. **L’objectif de l’Opendata n’est pas de publier des données mais de [créer des synergies](/david/blog/2013/opendata-citoyennete/) entre les citoyens, les administrations et les entreprises.**
## Date de péremption
> “Les traces que les utilisateurs laissent derrière eux sont radioactives, elles continuent à pouvoir avoir un effet négatif jusque des années plus tard.” La plupart des données échappent à tout contrôle sérieux. “Elles sont échangées, modifiées, revendues. Mais surtout, comme les déchets nucléaires, elles restent.”
>
> *[Faut-il une date de péremption pour les données ?](http://www.internetactu.net/2015/10/20/faut-il-une-date-de-peremption-pour-les-donnees/)* ([cache](/david/cache/8f33334066da6322f51118b15e39e482/))
D’un autre côté, il y a des données que l’on voudrait oublier et qui persistent, à notre insu. Comment introduire les notions de version et de temporalité dans les liens ? Cette question reste ouverte à ce jour et je ne connais pas d’initiative pour proposer un standard sur le sujet. Les [journaux évoluent](/david/stream/2015/10/21/) et vont devoir se poser ces questions s’ils vont [vers de la co-construction](/david/blog/2014/avenir-liberation/).
## Parfaitement cassé
> In closing, there’s a great book called *Small Pieces, Loosely Joined*. It’s about the web, and it’s about how the web is, by David Weinberger, who wrote this phrase, “the web is perfectly broken,” which I think is an interesting phrase, “perfectly broken,” because it’s messy deliberately. It’s not meant to be simple or easy; uniform and centralize. It’s supposed to be hacked together, distributed, customized, and remixed. It’s supposed to be human.
>
> *[Let’s Move Beyond Open Data Portals](https://medium.com/civic-technology/rethinking-data-portals-30b66f00585d)* ([cache](/david/cache/75c259bed30f5a31bf42e01f5d11fe6a/))
Son impermanence est peut-être aussi ce qui fait la beauté du Web au même titre que l’éphémérité de la vie. Une donnée est là et du jour au lendemain elle traverse la rue et son lien est rompu. C’est fini et il fallait l’apprécier alors qu’elle était encore disponible. La bonne nouvelle c’est que le clonage de données est (presque) gratuit si l’on sait s’y prendre à l’avance ;-).
## Résilience
> Can the web *now* be a proper archive? No. You can’t have a permanent access (stable URLs) to the data released (by WikiLeaks). Once you have piece of human knowledge, how do you keep it? How do you share it?
>
> Julian Assange, [Entretiens du Nouveau Monde Industriel](/david/blog/2015/enmi/)
Avoir une connexion permanente et rapide n’est pas suffisamment contraignante pour que l’on innove dans ce domaine. La résilience du réseau sera peut-être à trouver du côté des innovation issues de la contrainte dans le pays qui [ne disposent pas de connexions permanentes](http://www.lowtechmagazine.com/2015/10/how-to-build-a-low-tech-internet.html) ([cache](/david/cache/d629418c0d8fcf72c54e0a3c27d29ea6/)). Dans ces contextes, la mise en cache est beaucoup plus agressive et le réseau davantage distribué. Il serait tellement intéressant que la solution émerge de ces pratiques là…
## Et la suite ?
> But while HTTP has achieved many things, it’s usefulness as a foundation for the distribution and persistence of the sum of human knowledge isn’t just showing some cracks, it’s crumbling to pieces right in front of us. The way HTTP distributes content is **fundamentally flawed**, and no amount of performance tuneups or forcing broken CA SSL or whatever are going to fix that. HTTP/2 is a welcome improvement, but it’s a conservative update to a technology that’s beginning to show its age. To have a better future for the web, we need more than a spiced up version of HTTP, we need a new foundation. And per the governance model of cyberspace, that means we need a new protocol. IPFS, I’m strongly hoping, becomes that new protocol.
>
> *[HTTP is obsolete. It’s time for the distributed, permanent web](https://blog.neocities.org/its-time-for-the-permanent-web.html)* ([cache](/david/cache/3faaf2e57b062c8f0c8dd1fcb47faa58/))
[IPFS](https://ipfs.io/) (InterPlanetary File System) est une solution possible, la question étant toujours de savoir si ça passe à l’échelle en terme de performance et de bande passante pour avoir des contenus récents et/ou mis à jour. Je ne sais pas non plus quelle pourrait être la démarche d’adoption d’un tel protocole quand on voit l’inertie qu’il peut y avoir pour IPv6 par exemple…
**La solution sera probablement multiple. Expérimentez, documentez et échangez. Apprenez. Recommencez.** Même de petites expériences insignifiantes peuvent avoir le pouvoir d’actionner de nouvelles idées chez d’autres personnes. C’est aussi cela la force du Web.
*Il y avait une vingtaine de personnes durant la session et voici [les retours](/static/david/blog/opendata-liens-casses-retours.pdf) proposés par Confoo dans l’heure qui suit (!) par email.*