Open data in Italia: aperti sulla carta, inusabili nella pratica

Risposta diretta: in Italia i dati di interesse pubblico, quando esistono, sono spesso tenuti male: «aperti» sulla carta ma tecnicamente difficili da usare. Integrandoli per Open·Parlamento ci siamo scontrati, fonte dopo fonte, con barriere che non dovrebbero esistere: portali che rispondono zero byte ai programmi, endpoint «ufficiali» vuoti, certificati di sicurezza rotti, link spuntati anche dove l'API c'è, e progetti civici fermi da anni. Questo articolo le documenta una per una — non per polemica, ma perché la differenza tra «pubblicato» e «usabile» è enorme.

TL;DR

• Corte Costituzionale: a un programma che non finge di essere un browser risponde con zero byte; i dati arrivano in ZIP annidati con encoding anni '90 (cp1252). E lo SPARQL «ufficiale» risponde 200 vuoto.
• Cassazione: nessuna API documentata; i domini .giustizia.it hanno certificati TLS incompleti che fanno fallire le connessioni standard.
• ISTAT: prima irraggiungibile (HTTP 000), poi tornata ma limitata a 5 richieste al minuto (con blocco IP se superi).
• data.europa.eu: l'API c'è, ma i link ai dataset arrivano rotti (un campo «identificativo» restituito come lista).
• Progetti civici abbandonati: bilanci comunali fermi al 2021/22, Open Municipio senza aggiornamenti dal 2017.
• CKAN: ci sono ~950–2000 istanze nel mondo, ma molte sono datate; il valore reale è in poche eccezioni ben tenute.

«Aperto» non vuol dire «usabile»

C'è una differenza che la retorica dell'open data tende a nascondere: un dataset può essere pubblicato — spuntando la casella della trasparenza — senza essere usabile da un programma. È la distanza tra un PDF scannerizzato e un'API documentata. In Italia questa distanza è spesso enorme, e ricade su chi vorrebbe davvero usare quei dati: ricercatori, giornalisti, sviluppatori civici.

Quella che segue non è un'opinione: è il registro dei problemi reali che abbiamo incontrato costruendo i connettori, con i workaround che abbiamo dovuto implementare.

Le porte chiuse ai programmi (bot-gating)

Il portale open-data della Corte Costituzionale, a un client che non invia uno User-Agent da browser, risponde con zero byte. Per ottenere i dati abbiamo dovuto far finta di essere un browser (Mozilla/5.0). Una volta dentro, i dati arrivano in archivi ZIP annidati (zip dentro zip), con codifiche di testo cp1252 degli anni '90: serve un unzip ricorsivo e un decode multi-encoding.

È paradossale: dati pubblici, formalmente aperti, ma di fatto blindati contro l'unico modo sensato di consumarli su larga scala — un programma.

I motori ufficiali morti

Più di un endpoint SPARQL «ufficiale» italiano, interrogato da script, risponde 200 ma vuoto. La Corte Costituzionale ne è l'esempio: «SPARQL ufficiale risponde 200 vuoto da script → inutilizzabile». La soluzione è ripiegare sui dataset JSON grezzi invece che sull'endpoint pensato apposta per le query. Quando l'infrastruttura ufficiale è una facciata, il lavoro vero lo fa chi scarica i dump.

Le «API» che non ci sono e i certificati rotti

La ricerca delle sentenze di Cassazione non ha un'interfaccia pubblica documentata: il backend reale (Solr) non è pubblicizzato. E i siti .giustizia.it presentano una catena di certificati TLS incompleta, che manda in errore (CERTIFICATE_VERIFY_FAILED) qualsiasi connessione standard. Per leggere dati pubblici read-only abbiamo dovuto gestire esplicitamente l'eccezione TLS — qualcosa che su un servizio dello Stato non dovrebbe mai servire.

I limiti nascosti, anche dove l'API c'è

• ISTAT. L'endpoint statistico (SDMX) prima rispondeva HTTP 000 (irraggiungibile), poi è tornato su ma limitato a 5 richieste al minuto, con blocco dell'IP per 1–2 giorni se superi la soglia. Risultato pratico: inutilizzabile per integrazioni serie — abbiamo usato Eurostat, che gli stessi indicatori chiave li espone senza queste barriere.
• data.europa.eu (il portale UE). L'API esiste, ma i collegamenti ai dataset arrivavano rotti: il campo identifier tornava come lista invece che come stringa, producendo URL spuntati che abbiamo dovuto ricostruire lato connettore.
• Serie storiche non dichiarate. Un CSV «pulito» dell'accoglienza migranti conteneva in realtà 7 snapshot annuali sovrapposti (2018–2024): se non deduplichi, conti tutto sette volte. Niente nello schema lo segnalava.

I progetti civici abbandonati

Le iniziative migliori spesso si fermano. I bilanci comunali open erano aggiornati solo fino al 2021/22, senza API, accessibili solo via dump o scraping. Open Municipio, una piattaforma pensata per la trasparenza dei consigli comunali, è ferma dal 2017 e va installata comune per comune. Dati preziosi che, senza manutenzione, diventano lentamente inservibili.

E CKAN? Lo standard c'è, la cura no

CKAN è lo standard de facto dei cataloghi open data: ne esistono ~950–2000 istanze attive nel mondo. È una buona notizia — un solo connettore apre centinaia di portali. La cattiva notizia è che avere un portale CKAN non significa tenerlo aggiornato: molti cataloghi italiani sono datati, popolati una volta «per la trasparenza» e poi lasciati a invecchiare. Il valore reale si concentra in poche eccezioni ben mantenute (alcuni portali regionali e cittadini, e il portale europeo per i dataset armonizzati). Il resto è spesso vetrina: aperto sulla carta, fermo nei fatti.

Perché conta

Non è un dettaglio tecnico. È il motivo per cui dati che dovrebbero essere di tutti restano, di fatto, accessibili solo a chi ha tempo e competenze per «addomesticarli». La trasparenza dichiarata non basta: senza manutenzione, documentazione e formati usabili, l'open data resta un'etichetta. Il lavoro di Open·Parlamento è esattamente questo livello intermedio — rendere interrogabili fonti che, da sole, non lo sono — citando sempre l'originale.

FAQ

I dati pubblici italiani non sono open per legge?

Molti lo sono formalmente: pubblicati, con una licenza aperta. Ma «pubblicato» non significa «usabile da un programma»: tra un endpoint che risponde vuoto, certificati rotti e link spuntati, l'accessibilità reale è spesso molto peggiore di quella dichiarata.

Qual è il problema più comune?

Non ce n'è uno solo: bot-gating verso i client non-browser, SPARQL ufficiali morti, TLS rotto, encoding legacy, ZIP annidati, rate-limit nascosti, link rotti anche dove l'API esiste e progetti civici abbandonati. Il pattern di fondo è la mancanza di manutenzione.

Come si rendono usabili davvero?

Serve un layer che sondi e «addomestichi» ogni fonte: User-Agent corretti, fallback ai dump quando l'endpoint è vuoto, gestione degli encoding, deduplica delle serie storiche, ricostruzione degli URL. È il lavoro, poco glamour ma decisivo, che separa il dato pubblicato dal dato usabile.

---

Trasformiamo fonti pubbliche difficili in dati e knowledge graph davvero interrogabili — citando sempre l'originale. Vedi come funziona Open·Parlamento e i suoi open data, oppure parliamone.