Http://data.cquest.org/ des archives et un peu plus

Certains jeux de données ne sont publiés que dans leurs versions récentes, voire uniquement une version “actuelle”.

Parmi ceux-ci, il y en a où conserver les anciennes données disponibles est fort utile, soit pour voir l’évolution de ce que décrivent ces données, soit parce que l’on perd de l’information.

Exemple: les contrôles sanitaires.

Les textes réglementaires ne prévoient la diffusion que limitée au résultat du dernier contrôle et pendant un an et pas plus.

Un établissement mal noté subit souvent un second contrôle et cette mauvaise note disparaît donc rapidement… depuis bientôt un an, j’archive donc le fichier mis à jour quotidiennement.

Dans d’autres domaines, il est compliqué de s’y retrouver car les données ont été diffusées sur des plateformes changeantes au fil des années, les liens ne sont pas stables ou manquent de cohérence. C’est le cas du Registre Parcellaire Graphique, c’est à dire les cultures subventionnées par la PAC.

Je rediffuse pas mal de données, soit archivées, soit remises en cohérence, reformatées pour être plus faciles à utiliser, géocodées ou autre… mais tout ça s’est accumulé sans cohérence jusqu’à hier :wink:

J’ai remis un peu d’ordre et tout au même endroit: http://data.cquest.org/ et je vais compléter au fur et à mesure de mes fouilles dans mes To de disques :sunglasses:

L’essentiel des données fraîches est alimenté automatiquement par des scripts quotidiens publiés sur github.

8 Likes

C’est super !

Tout à fait d’accord. En économie c’est très utile de pouvoir retrouver la donnée telle qu’on la connaissait dans le passé. Par exemple, que connaissait-on du PIB en 2014, sur l’année 2013 ? Et en 2015, toujours sur 2013 ?

Je travaille sur le projet DBnomics qui archive des données d’économie dans des dépôts Git afin de conserver l’historique justement.
Par exemple, ce commit du 2 mars 2018 montre l’ajout de données sur le cours des métaux précieux.

2 Likes

Cette approche d’utiliser Git pour les données est poussée notamment par le programme Frictionless Data d’Open Knowledge International, avec les data packages.

J’ai aussi tenté la gitification, mais ce n’est adapté que pour des données de faible volume.

Exemple: https://github.com/cquest/data-alim-confiance

Chaque fichier CSV quotidien est dans un commit, du coup on peut facilement voir ce qui change :wink:

Ici, on voit qu’un nouveau contrôle a permis de passer cet établissement de “A améliorer” à “Satisfaisant”.

Très belle initiative ! Ca en fait des données à explorer … :smiley:

Cool, on est confronté aussi à ce problème, pour l’instant on archive les vieux fichiers dans un zip “archives”.

Le cas sur lequel on a le plus de demande, reste le découpage antérieur des bureaux de vote, afin de les faire correspondre aux résultats d’élections précédentes…

1 Like

Le problème c’est surtout côté producteur je pense qui pour des raisons que je ne comprends pas trop ne publient pas ces données d’archive.

Problème de volumétrie ?

De ce que je vois dans notre collectivité, il ne s’agit pas d’un problème de volumétrie.

Soit on parle d’une donnée type “statistique” ou “connaissance” alors là elle est archivée, soit c’est une donnée plutôt “patrimoine” gérée via un prologiciel souvent en GMAO et seul la connaissance actuelle est importante, ils est inutile de savoir combien il y avait de passage piéton en 2006 ou la localisation des PAV en 2008 !

Super boulot @cquest, évidemment très utile à la communauté.
De notre côté on avait envie de tester la pertinence du protocole Dat pour ce genre de problématiques, ça te tenterait qu’on fasse une petite exploration à partir de ton dépôt ?

1 Like

L’historique ne sert peut être pas aux métiers à l’origine des données, mais reste intéressant pour les réutilisations.

Si l’on veut étudier l’évolution des PAV sur 10 ans, il faut bien avoir les données de 2008 :wink:

Bonjour, cet échange montre bien tout l’enjeu de se préoccuper de la question de la pérennité et donc de l’accès dans le temps aux données, et pas seulement aux données “fraîches”. Et c’est bien l’objet d’une plateforme d’archivage électronique d’assurer cette conservation des données “qui ont perdu de leur fraîcheur”. Nous sommes plusieurs à penser qu’il faut réfléchir à l’articulation entre SAE (système d’archivage électronique) et plateforme Open data pour justement permettre cette profondeur historique dans l’accès aux données.

3 Likes

Bonjour à tous,

La pérennisation (donc l’archivage) des données en Open Data est une problématique qui a notamment connu un moment critique suite à l’élection de Trump aux Etats-Unis. Des professionnels de l’informations (archivistes, bibliothécaires…) se sont mobilisés pour sauver des tera de données notamment de recherches sur le climat.

La réflexion sur le lien entre archives et Open Data, si elle n’est pas encore assez développée, n’est pas non plus inexistante chez les archivistes.

Je citerai notamment deux articles sur ce sujet

Le premier montre par une analyse de data mining que les institutions suédoises en charge de l’archivage et de l’Open Data utilisent des vocables différents pour parler des mêmes objets. Et que donc les deux ont des actions sur les mêmes choses.

Le second est un retour d’expérience espagnol dans lequel le service archive est chargé de la mise en place de l’Open Data. En partant de l’identification des jeux de données à libérer et jusqu’à la mise en place d’une pérennisation des set de données en utilisant deux structures différentes.

Récemment des retours ont été fait sur le fait que suite à des modifications institutionnelles (exemple : fusion des régions) des liens vers des données Open Data se retrouvent cassés. Cette problématique est traitée par les institutions culturelles notamment via l’utilisation de lien ARK.

Les liens existent, le partage d’expertise aussi. Ce n’est pas par hasard si l’Association des archivistes français multiplient les contacts avec des experts de l’Open Data. D’ailleurs le 30 mars une rencontre est organisée par l’association : Open data et protection des données personnelles : où en sommes-nous ?

3 Likes

Bonjour,

Il y a un exemple fameux de la pertinence de conserver des versions “historiques” d’un jeu de données sur Bordeaux : un délégataire de service n’était chargé que de fournir les données d’usage des vélos en libre-service, donc en “temps réel”. Un réutilisateur a eu l’idée de conserver ces informations au fil des mises à jour. Une fois chargées dans une base de données, ces informations corrélées ont permis d’identifier les stations dans lesquelles les vélos étaient les plus empruntés, les moins disponibles, etc… depuis cette information est conservée par le délégataire qui s’en sert pour identifier les secteurs de création de nouvelles stations d’emprunt de vélo et le réutilisateur a été embauché :slight_smile:

Dans bien des cas, ce que l’on appelle “Big data” est un mélange de données “fraîches” et de données historiques et d’un côté on peut effectivement s’étonner qu’une donnée en chasse une autre sur les portails des producteurs, de l’autre on peut s’étonner que les archivistes ne s’intéressent pas plus aux bases de données.

Les informations stockées dans ces bases sont plus difficiles à saisir en terme de valeur juridique mais d’un autre côté on peut parier qu’il y a dans ces bases les matériaux de la recherche historique de demain.
Le format SIARD qui est proposé par la communauté archivistique pour conserver les base de données dans un format ouvert avec le modèle de données peut-être mis en regard des efforts de la communauté open data pour rendre plus “intelligent” les fichiers csv.

Tout cela milite effectivement pour un rapprochement dans les collectivités et administrations entre les fonctions d’archivistes électroniques et de CDO ou de responsable de projet open data.

3 Likes

Ajouté sur http://data.cquest.org/ :

dgfip_rei : fichiers de recensement des éléments d’imposition à la fiscalité directe locale (REI), disponibles sur https://www.data.gouv.fr/fr/datasets/impots-locaux-fichier-de-recensement-des-elements-dimposition-a-la-fiscalite-directe-locale-rei-3/ mais uniquement au format XLS et en plusieurs feuilles… donc remis en CSV

On y trouve les différents taux des taxes et autres impôts commune par commune, depuis 2009 à 2016.

1 Like

Encore un peu de neuf… la BPE 2016, Base Permanente des Equipements de l’INSEE.

Remise en CSV “normal” (virgules, UTF8) au lieu de fichiers DBF à l’encodage limite EBCDIC…

http://data.cquest.org/insee_bpe/

1 Like