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.
Tout est dans le “pourrait théoriquement”. 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.
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.
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 ?
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éile, écrit comme ça, ça me semble présager des usages ou réduire l’opendata uniquement à la création de services “utiles” à la consommation immédiate. En fait je ne sais pas ce qu’est “l’usage de l’opendata”.
Si je prends les données sur la qualité de l’eau potable, je peux effectivement faire une appli qui me donne les résultats des dernières mesures près de chez moi, mais avec la série longue je peux calculer la régularité de cette qualité et son évolution dans le temps (ce qu’une appli pourrait aussi fournir comme info).
Certaines données perdent une partie de leur intérêt avec le temps, c’est sûr, sauf pour faire des stats.
A quoi bon conserver dans OpenEventDatabase l’ensemble des incidents sur le réseau RATP qui sont diffusés en temps réel ?
Et bien ça qui m’a permis de voir que la RATP a par exemple changé ses règles pour les “colis abandonnés”, dont le nombre a été divisé par 20 d’un mois sur l’autre en septembre 2017 si ma mémoire est bonne.
Présageons le moins possible de ce qui peut être fait des données ouvertes. C’est même souvent ces usages auxquels on ne pense pas à l’origine qui sont les plus intéressants.
Je vous rejoint totalement sur la question de l’authenticité des données… mais là, leur mode de diffusion actuel ne garantit pas grand chose.
Rares sont les jeux de données où l’on a un hash signé pour garantir intégrité et origine.
C’est justement dans cette logique d’archivage que nous avons développé notre “Data Library” chez nam.R. Cette bibliothèque a pour objectif de contenir l’ensemble des références open data puisés des quelques centaines de portails ouverts sur le territoire.
On a fait le choix de télécharger les fichiers et stocker les fichiers plutôt que de seulement faire référence aux métadonnées. Avoir en stock les fichiers permet de produire automatiquement des informations très utiles (comme extraire le poids du fichier, son extension, son schéma…) mais aussi de garantir son accessibilité !
Et c’est un véritable enjeu de pouvoir garantir qu’on pourra disposer à moyen terme des données qui sont potentiellement utilisées par nos Data Scientists.
C’est d’ailleurs la raison pour laquelle nous n’écrasons les fichiers étant mis à jour, et préférons millésimer les versions étant donné que ce travail ne sera pas forcément fait par le fournisseur.
Enfin, ces millésimes permettent, comme le dit @cquest d’établir des tendances qui peuvent être extrêmement intéressantes. Par exemple, l’annuaire de l’éducation qui est tenu à jour par le Ministère sur leur portail OpenDataSoft n’existe qu’en version live et ne permet pas d’identifier les créations et fermetures d’établissements.
Bonjour à tous et merci pour cet intéressant débat.
Sur l’aspect “sauvetage” de données mis en ligne (open data ou pas d’ailleurs) par la puissance publique par peur d’effacement pour raison technique ou politique, la démarche ne peut qu’honorer les citoyens qui s’y investissent.
Pour ce qui est de l’archivage en tant qu’archiviste j’ai le sentiment de revenir au début de ma carrière il y a 10 ans où nous devions apprendre à travailler avec les informaticiens pour la partie numérique de la production. Ce que je lis ici n’est pas un archivage mais une sauvegarde, et une mise à disposition en ligne. Qu’on ne se trompe pas j’estime que ceci est déjà beaucoup surtout quand on parle d’initiative privée. Mais ce n’est pas la même chose que l’archivage.
On peut voir que dans la plupart des messages que le sujet est traité de façon technique : quels outils, quels formats, quelles technologies etc… Ceci occulte donc le plus important dans un archivage : le travail humain et organisationnel.
En ce sens, je pense qu’il faut aller regarder du côté des États-Unis où suite à l’élection de D.Trump des groupes de citoyens ont archivé un maximum de données notamment liées à l’environnement avant que l’administration ne les supprime. Dans ces groupes étaient présents des bibliothécaires et des archivistes apportant leurs compétences en termes de gestion documentaire.
Sujet qui n’est pas soulevé ici et qui pourtant est au cœur de l’archivage : Que va-t-on éliminer / supprimer ? Un important débat a eu lieu en France sur la notion d’archives essentielles et il a fallu beaucoup de pédagogie pour expliquer au grand public que nous ne conservions pas tout mais en respectant de nombreuses règles (lois, circulaires,décrets, corpus professionnel). Donc navré de décevoir mais tout ne sera pas conservé par des services d’archives (publiques ou non) car ce n’est ni possible et qu’il est même sain de savoir éliminer.
Pour finir, je dirai qu’il y a un fort intérêt à ce que la puissance publique s’empare du sujet car quelque soit l’investissement de particulier il n’apporte aucune garantie dans le temps. Ce que permet un service d’archives c’est d’envisager la conservation sur le temps long et ceci en siècles.
Edit : une ressource sur une initiative citoyenne et archives aux USA Reclaim the records qui peut inspirer et nourrir la réflexion
bravo pour ce projet concret
Oui clairement c’est utile, ça fait penser au software heritage en effet.
Je crois aussi qu’il faudrait (moissonner et) archiver des documents et pas que l’open data, les délibérations, ou les dossiers de marchés publics.
Les “wget -r” s’enchaînent et les disques se remplissent petit à petit… et nettement plus vite avec la fibre
Je vais bientôt auto-héberger “data.cquest.org”, actuellement hébergé sur une dédibox, car le disque (1To de SSD) est quasi plein, et cela fera un serveur en moins à louer.
Budget à rebasculer sur la deuxième fibre et ma facture Enercoop
Histoire de prioriser l’archivage, quelles sont, selon vous, les jeux de données par lesquels commencer ?
Par exemple, les données de référence du Service Public de la Donnée, en partie déjà fait, à compléter, surtout sur la partie archive.
J’ai une copie en cours des données de la DILA… ce qui fait déjà un beau morceau et le débit est plutôt bon (dans les 60 à 100Mbps, visiblement pas volontairement limité).
Autre archivage en cours… les photos aériennes anciennes de l’IGN. Cela les rendra plus facilement accessibles, car aujourd’hui même si l’accès est libre, il n’est pas aisé (clicodrome).
Je ne connaissais pas cette fonctionnalité de Socrata, merci pour le partage. Néanmoins, ces « snapshots » restent une option qui doit être activée au cas par cas par le producteur, je suppose au moment de la publication, et pouvant être aussi supprimée à posteriori. Le cliquodrome limite aussi l’exploitation de ces « versions »… C’est mieux que rien, mais on est encore loin du versionnement systématique et aussi ouvert que les données elles-mêmes. Il me paraît en effet crucial de pouvoir accéder aux données brutes, et ce pour chaque étape où elles ont été modifiées, y compris avant que le portail n’ait transformé les données à l’import.
Techniquement, ce n’est pas anodin à implémenter et il me paraît compliqué et peu souhaitable de le faire pour les portails actuels, qui sont globalement assez monolithiques.
J’ai bon espoir que d’autres options puissent émerger, avec frontend et backend qui seraient découplés, où l’on pourrait plus facilement exploiter et valoriser les données dans un environnement, une interface et avec des technos adaptées, sans qu’elles restent enfermées là où elles ont été publiées avec des contraintes propres au portail.
J’ai profité du calme de l’été pour crâmer un peu de bande passante et d’espace disque.
L’archive des données publiées sur data.gouv.fr est fait, ainsi que la DILA (536Go) qui arrive second derrière le Géoportail de l’Urbanisme (538Go de ZIP avec beaucoup de PDF et une pincée de shapefile).
Total actuel: 5To (dédupliqué et compressé par ZFS)
Hier, j’ai démarré l’archivage des portails OpenDataSoft…
Les scripts d’archivage sont prévus pour fonctionner en mise à jour quotidienne.
Pour les portails OpenDataSoft, j’ai ajouté l’archivage de la version « géographique » des données, en récupérant aussi le fichier au format geojson lorsque c’est approprié. Il est quand même bien plus facilement exploitable que les CSV contenant des bouts de geojson
Autre ajout… l’exclusion des jeux de données qui ne sont que des extraits de référentiels nationaux:
base sirene (rarement à jour en plus)
répertoire national des élus
prévision de météo france
registre parcellaire graphique
etc…
Premier décompte:
14000 jeux de données
mais 8000 différents, il y a beaucoup de jeux qui semblent identiques disponibles sur plusieurs portails, mais il n’est pas facile de s’y retrouver pour ne garder que l’original
Next steps:
l’archivage des « pièces jointes », certains jeux de données comme les GTFS sont souvent publiés de cette façon.
pour les jeux de données qui en fait ne font que lister des URL de téléchargement de fichiers, archiver aussi ces fichiers. Certains GTFS sont publiés comme ça, mais aussi les dalles d’ortho-photographies ou des documents numérisés et le contenu utile du jeu de données se trouve au bout de ces liens… environ 500 jeux de données sont concernés.
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).
