Da dove vengono
questi dati
Questo prototipo è un concept di rifacimento del portale ufficiale elezioni.regione.sicilia.it gestito dal Servizio Elettorale dell'Assessorato Regionale delle Autonomie Locali. Non sostituisce la fonte ufficiale: la rispecchia con un livello di servizio moderno, accessibile e machine-readable.
Sorgente dati
| Pagina sorgente | Contenuto | Mapping |
|---|---|---|
| ReportTabellaAffluenza.html | 4 rilevamenti × 71 comuni | /api/v1/affluenza, /comune/[slug], home |
| ReportRisultati[PROV].html | Voti finali sindaci/liste | /comune/[slug] (in attesa scrutinio) |
| ReportCandidati[PROV].html | Voti candidato sindaco | /comune/[slug] § Candidati |
| ReportSeggi[PROV].html | Ripartizione seggi consiglio | /comune/[slug] § Seggi |
| regionali2022/rep_7/riepilogoRegionale.html | Storico: 6 candidati, liste, seggi | Home § Storico, /storico |
Pipeline di ingest
- Fetch: scraper Python (
ingest/scrape.py) scarica le pagineReport*.htmlcon decoding ISO-8859-15. - Parse: BeautifulSoup individua la tabella foglia per ciascun report; gli aggregati provinciali e regionali sono riconosciuti da pattern testuali stabili dal 2009.
- Normalize: output JSON in
web/public/data/{tornata}.jsoncon schema versionato (camposource.urlper ogni record). - Render: Next.js 15 SSG durante
npm run build; ISR a 60s consigliato in produzione per ricontrollare la fonte durante lo spoglio.
Due modalità di deploy
Il prototipo è progettato per affiancarsi al sistema esistente, non per sostituirlo. La pipeline descritta sopra può essere alimentata in due modi diversi, scelti al momento del deploy. La differenza tra le due determina quanto freschi arrivano i dati al pubblico, ed è il punto cardine della discussione che segue.
L'ingest Python scarica le pagine Report*.html del portale ufficiale ogni N minuti, normalizza in JSON e ricostruisce il sito. Nessuna modifica al backend dell'Assessorato. Funziona da mirror accessibile, ma la freschezza dipende dalla cadenza dello scrape e dalla velocità del portale-sorgente.
Il backend dell'Assessorato espone una REST/JSON seguendo lo schema già definito nei file del prototipo (es. /api/v1/comuni/{slug}/affluenza). L'ingest viene sostituito da chiamate dirette. Latenza nell'ordine dei secondi e API riusabile da chiunque, testate, ricercatori, altre PA.
Il vuoto nel panorama italiano
Una ricognizione su AgID, dati.gov.it, Eligendo del Ministero dell'Interno e su Eleweb (Pro Logic Informatica) ha confermato che, ad oggi, non esiste in Italia un'API REST pubblica, documentata e real-time per le elezioni regionali. Eligendo offre un archivio storico dal 1946 in formato file scaricabili[2] e un endpoint /opendata per le tornate in corso che risulta attualmente sospeso[1]; le API di Eleweb esistono ma sono riservate a partner contrattualizzati[3]; i portali regionali servono HTML.
| Fonte | Cosa offre | Limite |
|---|---|---|
| Eligendo (Min. Interno) | Storico 1946→oggi, file CSV/testo [2] | Niente real-time; /opendata tornate in corso sospeso [1] |
| dati.gov.it | API CKAN nazionale, dataset comunali [4] | Update post-elettorale |
| Eleweb (Pro Logic Informatica [3]) | Acquisizione scrutini + API real-time | API B2B/B2G chiuse |
| AgID | Linee guida 547/2021 [5], PDND | Non gestisce dati elettorali |
| Comuni (Milano, Messina, Bari…) | Open data locali | Frammentati, post-elettorali |
Quanto sono freschi i dati elettorali, oggi
Ritardo tipico tra chiusura urne e dato disponibile in formato machine-readable, per ciascuna fonte oggi disponibile. Il prototipo Sicilia in modalità B porterebbe il ritardo a < 60 secondi (refresh ISR di Next.js).
Cosa offre il prototipo che oggi manca
| Feature | Eligendo | dati.gov.it | Eleweb | Sicilia (mod. A) | Sicilia (mod. B) |
|---|---|---|---|---|---|
| API REST pubblica | — | ✓ CKAN | ✓ chiusa | ✓ derivata | ✓ aperta |
| Aggiornamento real-time | — | — | ✓ | ~ cadenza scrape | ✓ ISR 60 s |
| Schema documentato OpenAPI | — | parziale | contratto | ✓ versionato | ✓ versionato |
| Pubblicazione PDND | — | — | — | — (non istituzionale) | ✓ design-ready |
| Conformità WCAG 2.1 AA | parziale | — | n/d | ✓ | ✓ |
| Sorgente tracciabile (URL+hash) | — | — | — | ✓ source.url | ✓ source.url |
| Riuso interregionale | — | — | licenza B2G | ✓ MIT + EUPL | ✓ MIT + EUPL |
| Imprimatur istituzionale | ✓ | ✓ | ✓ | — | ✓ |
Modalità A copre quasi tutte le feature tecniche, ma resta un mirror non istituzionale: i dati non hanno il timbro della Regione e non sono pubblicabili su PDND. È il massimo che la società civile può fare da sola, è esattamente quello che oggi fanno onData e Openpolis. Solo la modalità B chiude il cerchio.
Il vantaggio competitivo non è tecnologico (le tecnologie sono tutte standard) ma politico: nessun altro ente regionale italiano ha ancora occupato questo spazio. La prima Regione che lo fa diventa il referente a cui si guarderà per i prossimi 5-10 anni.
Un dibattito già aperto
Il problema dei dati elettorali italiani non è una nostra constatazione: è denunciato da anni da Istat, FORUM PA, ActionAid, Transparency International, onData e Openpolis.
“La pubblicazione dei dati su Eligendo per la sola consultazione e la pubblicazione dei dati aperti nella sezione Open Data non è mai avvenuta simultaneamente.”
La newsletter “Liberiamoli tutti!” di datiBeneComune (promossa da ActionAid, onData e Transparency International) ha denunciato che i dati delle Europee 2024 erano “intrappolati in centinaia di pagine HTML” e pubblicati in formato leggibile meccanicamente solo settimane dopo, in violazione del D.Lgs. 36/2006 come novellato dal D.Lgs. 200/2021 (recepimento Direttiva UE 2019/1024 Open Data), che obbliga la PA a pubblicare i dati in formati aperti e riutilizzabili[7][8].
L'associazione onData, guidata da Andrea Borruso, ha pubblicato su GitHub i dataset normalizzati di Politiche 2022[9] e Europee 2024[10] con la stessa tecnica del nostro prototipo: scraping di Eligendo e ripubblicazione in CSV/JSON. È la “supplenza” della società civile alle inadempienze della PA.
Conformità
- Linee guida AgID 547/2021[5]: Bootstrap Italia 2.x come framework UI ufficiale PA.
- Font istituzionali: Titillium Web, Lora, Roboto Mono, il set ufficiale Designers Italia.
- WCAG 2.1 AA: contrasto, focus visibili, skip-link, semantica HTML, etichette ARIA su mappa.
- Performance: SSG, font con
display=swap, SVG inline, dati statici precompilati. - Open data: ogni endpoint frontend ha un equivalente JSON (vedi pagine commentate).
Limiti del prototipo
Note e fonti
- Ministero dell'Interno — DAIT. Servizio sospeso · Eligendo /opendata tornate in corso. elezioni.interno.gov.it/opendata [verificato giugno 2026].
- Ministero dell'Interno — DAIT. Open data · Eligendo Archivio storico 1946→oggi (CSV). elezionistorico.interno.gov.it/eligendo/opendata.php [verificato giugno 2026].
- Pro Logic Informatica S.r.l. Eleweb — sistema integrato per la gestione delle elezioni. pro-logic.it/eleweb-elezioni. Qualificato ACN come SaaS PA: acn.gov.it/portale/en/w/sa-6149.
- Presidenza del Consiglio dei Ministri — AgID. dati.gov.it · API CKAN. dati.gov.it/api.
- AgID. Determinazione n. 547 del 1° ottobre 2021 — Linee guida sull'interoperabilità tecnica delle Pubbliche Amministrazioni. trasparenza.agid.gov.it · comunicato AgID 5 ottobre 2021.
- Patruno, Vincenzo (Istat); Ragone, Morena. Elezioni e open data: una riflessione a urne chiuse. FORUM PA, 27 settembre 2022. forumpa.it.
- D.Lgs. 36/2006 come novellato dal D.Lgs. 200/2021 (recepimento Direttiva UE 2019/1024 Open Data e riutilizzo dell'informazione del settore pubblico). normattiva.it — testo vigente.
- datiBeneComune (ActionAid Italia, onData, Transparency International Italia). “Liberiamoli tutti!” — n. 6. Substack, 25 giugno 2024. datibenecomune.substack.com.
- onData (Borruso, Andrea et al.). elezioni-politiche-2022 — Dati politiche 2022 in CSV/JSON. GitHub. github.com/ondata/elezioni-politiche-2022.
- onData (Borruso, Andrea et al.). elezioni_europee_2024 — Scrutini Europee 2024 in CSV/JSON. GitHub. github.com/ondata/elezioni_europee_2024.