dipendenti-pubblici: valutare estensione serie storica BDAP 2010-2020

[Gabrymi93]

Obiettivo

Estendere il candidate dipendenti-pubblici per coprire anche la serie storica OpenBDAP / RGS 2010-2020, senza aprire un nuovo intake separato.

Contesto

Il candidate attuale copre bene il triennio 2021-2023 e il bisogno informativo recente, ma resta aperto un gap reale sulla copertura temporale.

Dallo scouting BDAP emerge che:

• esistono package storici dal 2010
• il catalogo e' frammentato tra dataset distinti (occupazione e turnover, conto annuale, assunzioni)
• il prossimo passo corretto non e' un nuovo filone, ma un allargamento prudente del candidate esistente

Cosa fare

• mappare gli ID/package OpenBDAP storici rilevanti per 2010-2020
• verificare quali annualita' sono davvero recuperabili in modo stabile
• valutare se la serie storica puo' entrare nello stesso candidate senza rompere il perimetro attuale
• documentare in notes.md limiti, copertura reale e scelta di integrazione

Non fare in questa issue

• non aprire un nuovo candidate
• non promettere gia' analisi di "efficienza locale"
• non allargare subito il mart a tutti i sotto-dataset BDAP se prima non e' chiara la copertura minima

Output atteso

• decisione chiara su integrazione 2010-2020 nel candidate dipendenti-pubblici
• lista minima di package/ID storici riusabili
• eventuale piano tecnico piccolo per estendere raw/clean/mart

Riferimenti

• candidate: dataset-incubator/candidates/dipendenti-pubblici/

[matteocavo]

Verifica fonte BDAP 2010-2020

Sondaggio completato (2026-04-07). Risultati:

URL pattern

Il pattern usato nel candidate per 2021-2023 funziona anche per tutti gli anni storici:

https://bdap-opendata.rgs.mef.gov.it/export/csv/{anno}---Dipendenti-Pubblici---Occupazione-e-Turnover---Dati-analitici-per-Ente.csv

Probe HTTP anni 2010-2020

Anno	HTTP	Dimensione
2010	200	~9.3 MB
2011	200	~9.3 MB
2012	200	~9.2 MB
2013	200	~9.1 MB
2014	200	~9.2 MB
2015	200	~9.0 MB
2016	200	~9.1 MB
2017	200	~8.9 MB
2018	200	~8.0 MB
2019	200	~8.3 MB
2020	200	~8.2 MB

Tutti gli anni rispondono con file reali. Nessun redirect o placeholder.

Schema

Header identico tra 2010 e 2020: 23 colonne, delimitatore ;, stesso ordine. Unica differenza: il 2020 ha un trailing semicolon finale nell’header — non blocca il parsing con header: true.

---

Decisione

L’integrazione tecnica è possibile e diretta. Non serve un nuovo candidate: basta espandere years in dataset.yml da [2021, 2022, 2023] a [2010, 2011, ..., 2023].

Tuttavia: il candidate dipendenti-pubblici in DI è già stato promosso a dataciviclab/analisi/dipendenti-pubblici (issue #131). Il notes.md del candidate lo conferma: “il pacchetto tecnico non viene più mantenuto qui”.

L’estensione 2010-2020 va quindi aperta come task nel filone già promosso, non qui nell’incubator. Questa issue può chiudersi come “verifica completata — fonte stabile, lavoro da continuare in dataciviclab”.

Proposta prossimo passo: aprire una issue in dataciviclab per estendere la serie a 2010-2023 con il pattern URL verificato. Nessun cambio al clean.sql previsto: il campo Anno Rilevazione gestisce già la granularità per anno.

[Gabrymi93]

Ottimo, il contratto tecnico lo avevamo spostato in dataset-incubator, prima mi sembra fosse in DCL, quindi possiamo estendere solo il contratto tecnico, l'analisi in DCL possiamo tenerla su quel periodo o estenderla un domani.
Quindi, non c'è issue da aprire in DCL, solo aggiunta anni e nuovo run, se non c'è drift su colonne per gli anni precedenti, perfetto.
Vediamo se qualcuno se ne vuole prendere carico, aggiungo anche label GFI