Vous préférez un jeu de données par année ou un jeu de données avec plusieurs années?

Bonjour à toutes et tous,

La facturation de la solution technique n’étant plus basé sur un quota de nombre de jeux de données. Une question qui m’a été posé « Vous préférez un jeu de données par année ou un jeu de données avec plusieurs années ? ». J’ai ma petite idée.

J’aimerai bien avoir votre avis en tant qu’utilisateur de l’open data.

C’est un peu vague comme question, sans connaitre :

  • le volume de données (total et par année)
  • la fréquence de mise à jour et si elle se fait sur des anciennes années
  • le nombre d’années disponibles
  • la facilité d’exploitation de la date (est-ce qu’il n’y en a qu’une, est-ce qu’elle est facilement manipulable, bien remplie…)
  • la manière dont le jeu de données est mis à disposition

Après, rien n’empêche de proposer un fichier par année, et un fichier consolidé à coté…

2 Likes

Oui, la volumétrie me semble la première raison pour séparer ainsi que la mise à jour (données passées stables).

Le nombre d’années me semble être un facteur indirect, lié à la volumétrie.

1 Like

Je dirais qu’il n’y a pas forcément de « meilleure » réponse qui conviendrait à tout le monde, mais que le tout est que ce soit 1/ bien documenté et explicite (avec un champ indiquant l’année) 2/ cohérent. Il est important aussi je crois de bien historiciser les données (qu’un millésime n’écrase pas les précédents).
Ce jeu de données par exemple est multi-années et je ne trouve pas du tout ça gênant : Budget participatif - Les projets lauréats — Paris Data

1 Like

C’est un bon exemple où la volumétrie est faible et donc un jeu global ne pose aucun problème (au contraire même).

Autres raisons de séparer:

  • lorsque la structure change (le moins possible SVP)
  • quand la méthode de collecte des données, leurs exhaustivité ou autre change

Par conséquence une année n’est plus directement comparable à une autre et il vaut mieux séparer (et docmuenter les changements bien sûr pour ceux qui voudraient ré-agréger).

2 Likes

Merci :pray: pour vos réponses @GuillaumeD, @joel et @cquest

Je vais être plus précis. Mes collègues dépose une fois par an sur open.urssaf.fr des jeux de données sur les marchés :
JDD sur les marchés

Volumétrie par année : assez faible (sauf si demain c’est x22 car toutes les Urssaf mettent les données)

=> Une question qui me vient. A-t-on une idée précise de la taille à partir de laquelle il vaut mieux scinder. Dépend probablement de l’utilisateur (si utilise Excel ou API + BI ou autre)

Structure : pour l’instant c’est la même après ce serait bien de se rapprocher du schéma proposer par data.gouv

Charge interne : je me dis que c’est, peut-être, plus simple pour la documentation et le reste d’avoir un seul jeu avec plusieurs années

Après @GuillaumeD sur ta proposition de faire un fichier par année et un consolidé je me demande si sur la charge interne ça va peser et si c’est vertueux en terme de sobriété numérique. Aucune idée.

Encore merci pour les réponses. C’est top et ça fait réfléchir :slight_smile:

Sur ce cas précis on coche:

  • petite volumétrie (même x22),
  • même structure,
  • contenu comparable d’une année à l’autre

Trois bonnes raisons pour n’avoir qu’un jeu de données de mon point de vue.
Il est plus simple de filtrer que d’agréger, surtout sur un portail ODS.

1 Like

même avis que @cquest. Sur un jeu comme ça je ne vois pas l’intérêt à double publier, ça induit de la confusion, des risques d’écart/erreurs et c’est simple de filtrer avec ODS.

Par contre @DavidG le « schéma » auquel tu fais référence n’est pas « proposé par data.gouv » mais obligatoire de par la loi : schema.data.gouv.fr. Ça n’empêche pas de publier autre chose à côté mais a minima cette obligation devrait être satisfaire…

2 Likes

Tu as un lien vers un texte qui précise cette obligation. J’avais échangé on m’avais plutôt dit que c’était une préconisation.

Merci Christian. Mon intuition me disait aussi de partir sur cette vision. C’est bien de pouvoir échanger et d’avoir des avis sur le sujet.

Le lien vers l’arrêté figure sur

https://www.legifrance.gouv.fr/loda/id/JORFTEXT000038318675

C’est précisé dans le lien que je t’ai mis : arrêté du 22 mars 2019, pris en application de l’article R2196-1 du Code de la commande publique, lui-même pris en application de l’article L2196-2 du même code.

2 Likes

par ailleurs je m’écarte du sujet mais 1/ néanmoins les DECP (ou certaines ?) remontent bien dans la consolidation nationale (voir db: decp: 101 lignes où where acheteur.id = 18003501600054 sorted by rowid), donc elles doivent être diffusées au format règlementaire, sans doute via e-marchespublics ? 2/ la licence ODBL appliquée à ce jeu de données paraît inutilement restrictive car comme le rappelle souvent @cquest s’agissant de données d’autorité comment pourraient-elles être corrigées par des tiers ?

2 Likes

Merci Joel. Je regarde le point 1/ et pour le 2/ La licence n’est pas géré jeu de données par jeu de données. Elle est valable pour l’ensemble des JDD. On reste ouvert à des évolutions la maturité et les échanges aidant.

1 Like

Si je résume nos échanges en tentant des propositions « pièces à casser » :

Critères pour partager un JDD multi-année ou année par année :

• Le volume de données

Proposition : si au-dessus de 1 500 000 lignes alors fichier séparé

• La fréquence de mise à jour

Proposition : si les mises à jours conduisent sur la période à dépasser 1 500 000 lignes alors fichier séparé

• Mise à jour de l’historique

Proposition : si la mise à jour du fichier multi-année conduit à revoir l’historique et que cela nuise à l’utilisateur alors fichier séparé

• Comparabilité entre années n’est plus possible (changement de structure, méthode de collecte, …)

Documenter les changements pour permettre les re-agrégations

La mise à disposition d’un fichier multi-année doit être facilité par :
• un champ indiquant l’année dans le jeu de donnée
• permettre une mise à disposition de tout ou partie (filtre) et selon des modes d’export adapté (Excel, Csv, API …)