Archiver les données ouvertes ?

1

Cela fait quelques temps que l’idée d’archiver les données publiées en opendata me trotte dans la tête.

Pourquoi ?

La stabilité de publication de certaines données est plus qu’aléatoire.

On a déjà vu des jeux de données dé-publiés.
Deux exemples:

  • les données des ventes et achats de pesticides (pression des lobbys et du Ministère de l’Agriculture)
  • données des points de captage d’eau potable et des périmètres de protection (elles étaient en opendata et “à cause de la menace terroriste” elles ont été dépubliées)

On a tous aussi été victime d’un changement de site où le ménage a plus ou moins été fait au passage, considérant que de vieilles données n’étaient plus utiles.

Il y a aussi les portails où l’on ne publie que les versions les plus récentes, ce qui ne permet pas de faire des comparaisons sur de longues séries. Parfois ce ménage est fait pour des raisons de coûts, parfois pour publier à minima ce qu’on est obligé de publier (je pense aux contrôles d’hygiène où les textes réglementaires obligent à publier le dernier contrôle pendant un an, mais n’interdit pas de publier plus que ça !).

Il y a aussi le jeu de piste… les données sont publiées mais en fonction du millésime c’est à un endroit différent. Je pense au Registre Parcellaire Graphique où certaines années sont téléchargeables sur data.gouv, d’autres sur le site de l’IGN, etc…

Je passe ce qui est publié uniquement par API… ou récupéré par scrapping (OpenEventDatabase m’a beaucoup appris pour ça).

Bref, depuis quelques temps déjà, je garde pas mal de choses sur data.cquest.org mais j’envisage de passer à la vitesse supérieure… archiver tout ce qui peut l’être “au cas où”, en attendant que les services officiels chargés des archives prennent le relais.

Comment ?

data.gouv publie désormais le catalogue des jeux de données, ce qui doit permettre d’automatiser les récupération de ce qui y est catalogué sans se limiter à ça.

Il faut ensuite télécharger et stocker, or, louer des serveurs ou de l’espace de stockage revient vite cher, du coup j’envisage du “fait maison”.

La fibre devrait être installé chez moi (enfin) la semaine prochaine (si tout va bien, car c’est la première du quartier).
Ceci va permettre à mon micro-datacenter, de devenir un mini-datacenter :wink:

J’ai pour cela complété dernièrement mon mini-datacenter maison par des serveurs de stockage. Tout est composé de matériel recyclé ou d’occasion sauf exception. Les prix sont donc très bas.
J’ai un peu plus de 100To de disponibles (moins en faisant de la redondance).

Je n’ai par contre pas encore réfléchit à la façon de rendre le contenu accessible et explorable.

Il faudra faire mieux que http://data.cquest.org !

Qu’en pensez-vous ?

5 « J'aime »
2

Dépôts Git ? :innocent:

3

Super projet @cquest !

J’ai un cas d’usage avec la base Transparence-Santé, pour laquelle j’aimerais beaucoup conserver l’historique.

Je vois ce projet comme le pendant de Software Heritage pour les code sources.

Si l’on met les données dans des dépôts git publics, on peut déjà utiliser la solution Software Heritage, sans aucun effort.

Il serait bon de se rapprocher de l’équipe pour en parler, car il y a beaucoup de synergies. Ils ont peut-être déjà des solutions pour archiver les données, puisque leur système fonctionne avec tout type de fichiers.

Cependant, utiliser git pour versionner des données posera des difficultés pour les gros jeux de données, ou pour les fichiers non textuels (chaque diff = ensemble du fichier).
Les dépôt de plusieurs gigaoctets posent problème. C’est en tout cas les limites types qui empêchent de les cloner sur gitlab.com ou github.com avec un forfait gratuit.

Un outil à regarder serait Pachyderm, mais je n’ai pas creusé.

4

Oui bien évidemment Git a vocation à être utilisé pour du texte mais de toute façon le binaire et l’open data ne feront jamais bon ménage. :wink: D’expérience, les limites de Git sont très malléables et on les atteint rarement avec plusieurs milliers de fichiers et 100 Mo dans un dépôt. Pour du CSV, cela laisse de la marge. Il restera toujours des cas à gérer pour des données qui devront être stockées ailleurs, mais si cela reste marginal…

Non ma proposition, que d’aucuns qualifieraient de trollesque, trouve davantage ses limites dans l’interface proposée aux utilisateurs finaux. Mais pour moi la publication et la valorisation sont des métiers différents qui doivent être découplés, ce qui n’est pas le cas actuellement (logique de portails).

Le cas d’usage présenté par @cquest, selon moi s’y prête bien : orienté vers le stockage, le versionnement et la publication de données brutes, et auquel pourraient se brancher des interfaces correspondant à d’autres cas d’usages de valorisation (sites statiques, visualisation, cartographies, etc.).

Alors, à quand un gitlab.cquest.org ? :yum:

Un outil à regarder serait Pachyderm, mais je n’ai pas creusé.

On s’y est pas mal intéressé avec @cbenz. On regarde aussi beaucoup du côté du décentralisé, et à ce jeu-là dat tient le haut du pavé. :heart_eyes:

1 « J'aime »
5

Bonne idée !
Est-ce qu’un système basé sur l’IPFS ne faciliterait pas, à terme, la collaboration autour d’un tel projet. Genre open data citoyen décentralisé ?

6

Dans un premier temps, il me semble plus simple de partir sur du stockage s’appuyant sur des technos basiques car c’est avant tout la conservation d’une copie des données qui importe.

Après, ce qu’on en fera, la façon d’y accéder de les exploiter pourra s’envisager, mais sans données tout ça n’a que peu d’intérêt :wink:

git… j’avais testé en publiant BANO de cette façon et c’est vraiment pas gérable sur le long terme.
pachyderm mérite une analyse approfondie, est-ce que quelqu’un a déjà testé/utilisé ?
dat semble répondre à la synchronisation de données distribuées.
ipfs est intéressant, mais encore bien expérimental et exotique… assez proche de dat en terme de fonctionnalités.

Je note que vous n’avez pas réagit sur le “pourquoi”… donc tout le monde d’accord ?

7

Article récent sur le sujet :

Malgré les centaines de millions de dollars qui financent le projet, je n’ai encore rien vu de tangible réalisé avec ce protocole.

A comparer avec Dat, au budget probablement 1000 fois moindre, et pourtant infiniment plus ouvert et aux spécifications mieux définies, et surtout avec des implémentations déjà concrètes même si elles sont encore très expérimentales :

https://datprotocol.github.io/how-dat-works/

https://unwalled.garden/

1 « J'aime »
8

Sur le pourquoi, j’interprète cela comme une initiative similaire à Wayback, d’Internet Archive ou, plus tôt et avec un périmètre plus limité, à DOI. Les raisons qui ont poussé DOI et IA à exister (archivage, versionnage, référencement univoque et partagé) se justifient avec une acuité particulièrement forte pour les données ouvertes (publiques, enjeux citoyens, redevabilité sur l’action de l’Etat, potentiellement sensibles politiquement…).
Ceci dit, cela pose la question : est-ce que les bases que vous mentionnez (Transparence-Santé, registre parcelaire graphique, autres IGN, contrôles d’hygiène, ventes de pesticides…) ne sont pas déjà archivées par IA et accessibles via l’outil Wayback?

9

J’en doute fort… les volumes peuvent être très conséquents (des To pour les photos aériennes) et archive.org est malheureusement très loin de tout archiver surtout pour des données en évolution continue ou accessibles uniquement via API.

Exemple:

Il m’arrive souvent de demander l’archivage d’une page web, qui n’a jamais été archivée bien qu’elle existe depuis plusieurs mois.

Exemple… https://web.archive.org/web/20180826081937/https://nosdemarches.gouv.fr/

Les données publiées par ce site, sont toujours archivées par mes scripts quotidiens: http://data.cquest.org/dinsic/nosdemarches/

1 « J'aime »
10

Il me semble qu’en matière d’archivage on peut considérer les images, et les binaires lourds en général, comme des cas méritant un traitement spécifique et une discussion à part, non ?
L’open data c’est quand même 80-90 % de CSV, du texte, etc. donc des données relativement légères à archiver.
Je ne crois pas qu’il soit pertinent de chercher une solution technique parfaite et couvrant les 2 cas d’usages en même temps.

11

Oui, bien sûr…

On a des données très volumineuses, mais qui ne changent qu’avec un cycle de 3 à 5 ans (cas des photos aériennes), et puis on a des données moins volumineuses mais qui changent en permanence (SIRENE est un bon exemple). Au milieu de ça, il y a des données pas très volumineuses et millésimées ou pas (publication unique).

Tout est utile, enfin je pense. La méthode pour traiter ces différents cas sera sûrement différente.

Pour l’instant j’expérimente en mode artisanal pour voir les différents cas présents sur data.gouv :wink:

12

Bonjour,

Bien sûr qu’il faut archiver les données ouvertes ! Et ces données doivent être collectées par les services publics d’archives car elles ont le statut d’archives publiques.
Vos exemples illustrent le paradoxe né de l’opposition entretenue entre Open data et archivage, entre données dites fraiches et données archivées ou périmées, et donc inutiles pour des usages innovants :slight_smile:
Mais l’archivage a justement un supplément d’âme, celui de donner une profondeur historique et donc temporelle aux données.
A la condition que l’archivage soit pensé comme un service : il ne s’agit pas seulement d’organiser le stockage des données mais aussi (et surtout), de les contextualiser, de les mettre en lien avec d’autres données et documents produits par les collectivités, d’organiser leur accès dans le temps et leur pérennisation.

Il devient urgent de réfléchir à l’articulation entre les plateformes Open data et les SAE (systèmes d’archivage électronique).
Longtemps j’ai eu l’illusion qu’on pourrait verser les jeux de données dans le SAE à la source, c’est-à-dire en même temps que leur dépôt sur les plateformes Open data, avec une sorte de double aiguillage.
Je crois aujourd’hui qu’il faut que les archivistes considèrent les jeux de données en Open data comme de nouvelles formes d’archives à collecter, depuis les plateformes Open data.
La question de l’archivage des données ne peut pas être traitée sous le seul angle technique des outils. Mais pour cela, il nous reste à penser les multiples usages des données comme un continuum, depuis leur production dans les systèmes d’information métier jusqu’à leur accès dans le temps, en passant par leur archivage et leur politique de diffusion et valorisation.

Céline Guyon
@earchiviste

3 « J'aime »
13

C’est vrai que le vocabulaire employé jusqu’ici pouvait entrainer une confusion sur la notion d’archivage (stocker des données dans une base Postgres par exemple), qui d’un point de vue technique est différente de la notion de versionnement (avec Git ou Dat par exemple). Les deux sont souhaitables, mais dépendent de choix techniques. Vous faites bien de clarifier ça, justement pour que le débat de porte pas uniquement sur des choix techniques. :slight_smile:

Cela rejoint mon message précédent qui distinguait les choix techniques à faire concernant la publication des données, qui est davantage une infrastructure, un backend, là où l’utilisation, la valorisation, est une interface avec le public, un frontend.
L’interface de type portail, la plus courante actuellement, est un frontend, et n’a pas vocation à archiver ou versionner les données. Il faut une étape supplémentaire, préalable, au plus près des métiers si possible, et interne à l’organisation qui produit les données.

14

petite réaction de détail à :

L’interface de type portail, la plus courante actuellement, est un frontend, et n’a pas vocation à archiver ou versionner les données

Ça ne me semble pas entièrement exact, ou plutôt c’est exact pour data.gouv/udata (qui est un catalogue), sans doute aussi pour CKAN (encore que), mais moins me semble-t-il pour ODS, qui n’est pas qu’un outil de catalogage mais repose aussi sur un modèle de données (ce qui permet l’APIfication par exemple), et pourrait donc théoriquement tout à fait archiver et versionner les jeux de données. Après, je ne sais pas si ça fait partie de leur roadmap (@jean-marc.lazard ?) et comment ça s’articule avec leur modèle d’affaire.

15

Tout est dans le “pourrait théoriquement”. :wink: Oui il n’y a aucune raison particulière pour laquelle ces différentes technos de portails ne pourraient pas ajouter ces fonctionnalités de versionnement (aucun ne le fait actuellement, en tout cas pas de façon puissante, cf. Git, Dat et d’autres encore) et/ou d’archivage (accès aux données brutes d’origine, sans transformation, modification, écrasement ou suppression ultérieure).

Le fait est qu’elles ne le font pas car ce n’est pas ce qu’on leur demande de faire. Cette situation, et la raison même de ce thread, est dûe au fait que l’open data est très souvent considéré comme une petite lucarne sur l’administration, autorisant à certaines conditions un accès bien encadré et après de nombreuses étapes de traitement et d’intermédiation, et rarement un accès le plus direct possible et sans filtre aux données brutes et aux métiers qui les produisent, avec possibilité d’échanger avec eux. Ce qu’il devrait être non ?

Dans certains cas les portails ne stockent même pas les données, il n’y a que des liens vers la source des données, ou (pire insulte) des échantillons.

16

Je précise un peu mon post initial…

Oui, qu’ils soient locaux ou nationaux, les services d’archives devraient se charger d’archiver les données publiques… mais aujourd’hui ce n’est clairement pas fait.

Oui, les portails opendata où sont publiées les données pourraient gérer aussi l’accès aux millésimes anciens. C’est rarement fait, pour des histoires d’espace, de coût, quand ce n’est pas une volonté de publier “à minima”.

C’est pour cela que je souhaite agir, sans attendre pour préserver (même en mode bidouille) ce qui peut l’être, le temps que quelque chose se mette en place.

J’ai déjà automatisé certains archivages et continué ce week-end dans cette voie avec:

Un script bash (update.sh) récupère la description json du jeu de données sur data.gouv, l’archive quand elle change, puis récupère les jeux de données en les historisant eux aussi.

Je préfère partir de cas pratiques, trouver comment les traiter, puis voir ce qui peut s’industrialiser et être mis en commun.

17

Pour le coté accessibilité et explorabilité, pourquoi ne pas utiliser uData ? Cela faciliterait la synchronisation avec data.gouv.fr.

18

Voici une autre implémentation de récupération scriptée, hors data.gouv:

Là, pas d’API, pas de moissonnage possible à part par scrapping.

Par exemple pour AdminExpress, la fiche sur data.gouv renvoie vers une page web, il n’y a que la version “COG” qui est indiquée en ressource.

19

Pour être clair, je ne suis absolument pas en désaccord ni avec ce que tu dis, ni avec la proposition de @cquest - bien au contraire, je trouve cet archivage citoyen absolument nécessaire. Au passage c’est régulièrement discuté sur #TOD, voir par exemple : Comment rendre l'open data résilient aux changements politiques ?

2 « J'aime »
20

C’est aussi parce qu’on est dans une forme de présentisme et qu’on perd de vue l’importance de la profondeur du temps pour révéler la valeur ajoutée des données.
Je pense sincèrement qu’il faut penser en termes d’usages ; le portail Open data n’a pas vocation pour moi à archiver les données mais à mettre à disposition des données dans le cadre d’un usage, celui de l’Open data ; on peut tout à fait imaginer d’autres usages à partir de ces mêmes jeux de données ; il faut donc penser l’éco-système de l’open data avec l’écosystème de l’archivage et voir les SAE comme des réceptacles de données ouverts et non comme des espaces clos (ou des cimetières de données). L’intérêt de verser les jeux de données dans un SAE n’est pas tant de gérer leur versionnement (ce que pourrait faire une plateforme) que d’apporter des garanties quant à la qualité des données grâce notamment à leur description, contextualisation et leur rapprochement avec d’autres données. Dans le temps long, l’enjeu est celui de l’authenticité des données.
Il est vraiment nécessaire de se mobiliser (tous professionnels de tous horizons) pour faire émerger une vraie politique en la matière.

Céline Guyon

2 « J'aime »