Salta al contenuto principale

Open Data: pubblicare non basta

Inviato da tuxsa il

Negli ultimi anni molte amministrazioni hanno iniziato a pubblicare quantità crescenti di dati avviando un cambiamento importante; ma pubblicare un'informazione non significa automaticamente renderla realmente aperta. Possiamo trovare un dato:

  • su una pagina web;
  • all'interno di un PDF;
  • in una tabella;
  • in un file scaricabile;
  • in un portale Open Data;
  • attraverso un'API.

Tutte queste forme rendono disponibile un'informazione ma non tutte permettono lo stesso livello di utilizzo. La prima distinzione fondamentale è quindi: un dato visibile non è necessariamente un dato riutilizzabile.


Che cosa intendiamo per Open Data

Un dato realmente aperto dovrebbe poter essere:

trovato;
compreso;
scaricato;
elaborato;
combinato con altri dati;
riutilizzato secondo condizioni chiare.

L'apertura riguarda quindi almeno tre dimensioni.

Giuridica Possiamo utilizzare il dato?

Tecnica Possiamo elaborarlo con strumenti informatici?

Informativa Sappiamo cosa significa?

Se manca anche soltanto una di queste dimensioni, il riuso diventa più difficile.


Il primo ostacolo: trovare il dato

Un dataset può essere perfettamente aperto ma praticamente invisibile.

  • Magari è pubblicato in una sezione poco conosciuta.
  • Oppure il titolo non corrisponde alle parole utilizzate normalmente da chi lo cerca.
  • Oppure compare soltanto attraverso un motore di ricerca esterno.

Questo significa che l'apertura deve cominciare dalla trovabilità. Un catalogo dovrebbe permettere di cercare per:

  • tema;
  • territorio;
  • fonte;
  • periodo;
  • formato;
  • parole chiave.

Se per trovare un dato dobbiamo già sapere esattamente dove si trova, il sistema funziona soltanto per chi lo conosce in anticipo.


Il nome del dataset deve essere comprensibile

Anche il titolo conta. Un dataset denominato con una sigla amministrativa può essere perfettamente corretto per chi lavora nell'ente e completamente incomprensibile per un cittadino. Il titolo dovrebbe permettere di capire immediatamente il contenuto.

Ad esempio Strutture ricettive nel Comune di Salerno è più immediato di una denominazione costruita esclusivamente attraverso codici interni. Le sigle possono rimanere ma dovrebbero essere accompagnate da descrizioni comprensibili.


La descrizione deve rispondere alle domande essenziali

Prima ancora di scaricare un file dovremmo poter sapere:

  • che cosa contiene?
  • chi lo produce?
  • a quale territorio si riferisce?
  • qual è il periodo coperto?
  • quando viene aggiornato?
  • quali sono i principali campi?
  • quale metodologia utilizza?
  • quali limiti possiede?

Un dataset senza descrizione obbliga ogni nuovo utilizzatore a ricominciare da zero. La documentazione riduce enormemente il costo del riuso.


Il problema dei PDF

Il PDF è uno strumento eccellente per leggere un rapporto perchè permette di mantenere impaginazione, grafici, tabelle e commenti., ma se la tabella contenuta nel rapporto è l'unica forma nella quale il dato viene pubblicato, il riuso diventa difficile.

  • Un ricercatore deve copiarla.
  • Un giornalista deve trascriverla.
  • Uno sviluppatore deve estrarla.
  • Un'associazione deve ricostruirla.

Molte persone ripetono lo stesso lavoro ma il problema non è il PDF. Il problema è il PDF come unico contenitore del dato.


Rapporto e dataset devono convivere

Il modello più utile è semplice. Pubblicare un rapporto leggibile dalle persone e contemporaneamente un dataset leggibile dalle macchine.

Il rapporto spiega mentre il dataset permette di verificare, elaborare e riutilizzare. Sono due prodotti complementari.


La tabella sul web è già un passo avanti, ma non sempre basta

Una tabella HTML permette spesso di copiare più facilmente i dati ma anche qui dobbiamo chiederci se sia possibile scaricarli in formato strutturato. Se una tabella contiene migliaia di righe, costringere l'utente a copiarle manualmente significa porre una barriera inutile.

Meglio affiancare un pulsante Scarica CSV oppure fornire un accesso tramite API.


CSV: semplice ma potentissimo

Il formato CSV è uno degli strumenti più semplici per pubblicare dati tabellari. Può essere letto da:

  • fogli di calcolo;
  • software statistici;
  • linguaggi di programmazione;
  • strumenti GIS;
  • database.

Non è sofisticato e proprio per questo è estremamente utile. Un CSV ben documentato e aggiornato regolarmente può essere molto più prezioso di una piattaforma complessa difficile da utilizzare.


JSON e API

Quando i dati devono essere utilizzati automaticamente da applicazioni e servizi, formati come JSON e accessi tramite API diventano particolarmente utili. Un'API permette a un sistema di chiedere “dammi gli eventi di oggi” oppure “dammi i luoghi culturali entro questa area” ed anche “dammi le strutture con determinate caratteristiche”.

Il dato può essere integrato direttamente nei servizi senza essere scaricato e ricopiato manualmente il che rende possibile aggiornare l'informazione alla fonte e distribuirla automaticamente.


Non tutto necessita immediatamente di un'API

L'obiettivo però non deve diventare una corsa tecnologica. Un piccolo dataset aggiornato una volta all'anno può essere perfettamente utile in CSV. Creare una complessa API per un dato statico potrebbe essere inutile. La tecnologia deve essere proporzionata al bisogno.

Possiamo immaginare diversi livelli:

pagina informativa;
file scaricabile;
dataset strutturato;
aggiornamento automatico;
API.

Non tutti i dati devono raggiungere immediatamente l'ultimo livello.


Il formato deve essere aperto

L'accesso ai dati non dovrebbe dipendere obbligatoriamente dall'acquisto di un particolare software. Per questo i formati aperti sono importanti:

  • CSV.
  • JSON.
  • GeoJSON.
  • XML.
  • altri standard pubblicamente documentati.

Un formato proprietario può eventualmente essere offerto come opzione aggiuntiva ma non dovrebbe essere mai l'unico modo di accedere all'informazione.


Una licenza chiara

Possiamo scaricare il dato, ma possiamo riutilizzarlo? Una licenza deve rendere questa risposta chiara. Senza indicazioni precise, un soggetto può decidere di non utilizzare il dataset per timore di violare diritti.

Questo produce un paradosso: il dato è pubblicamente disponibile ma il suo riuso rimane incerto.

La licenza deve quindi spiegare chiaramente:

  • se il dato può essere copiato;
  • modificato;
  • redistribuito;
  • utilizzato anche in servizi commerciali;
  • quale attribuzione deve essere mantenuta.

Citare la fonte è un valore

L'obbligo di attribuzione, quando previsto dalla licenza, non dovrebbe essere considerato un ostacolo perchè conservare la fonte aumenta la qualità dell'informazione e permette a chi utilizza un servizio di capire:

  • da dove arriva il dato;
  • chi ne è responsabile;
  • dove verificarlo.

La provenienza non deve perdersi nel processo di riuso.


I metadati rendono comprensibile il dataset

Immaginiamo un file con queste colonne: COD_TIP, DEN, CAP, PLET, ACC Chi conosce il sistema può comprenderle ma un utente esterno probabilmente no.

Serve quindi un dizionario dei dati che spieghi, ad esempio:

  • COD_TIP: codice della tipologia;
  • DEN: denominazione;
  • CAP: capacità;
  • e così via.

Il nome del campo è un dato tecnico. La sua definizione è conoscenza.


Anche i valori devono essere documentati

Lo stesso problema può verificarsi all'interno delle colonne.

Supponiamo di trovare: Accessibilità = 1

  • Che cosa significa?
  • Completamente accessibile?
  • Parzialmente?
  • Presenza di una determinata struttura?

Un valore numerico senza legenda può essere inutilizzabile. Ogni codice deve quindi essere accompagnato da una spiegazione pubblica.


Le date devono avere un formato coerente

Anche un dettaglio apparentemente banale può creare problemi.

Una data può apparire come:

  • 29/08/2026
  • 2026-08-29
  • 29 agosto 2026
  • 29-8-26

Per una persona sono forme equivalenti mentre per l'elaborazione automatica possono creare difficoltà. Utilizzare formati standard rende molto più semplice collegare dataset differenti. Gli standard non sono una complicazione burocratica ma sono quelli che permettono ai sistemi di capirsi senza intervento manuale.


Le coordinate geografiche

Per un luogo turistico, un indirizzo è utile ma una posizione geografica strutturata può esserlo ancora di più. Coordinate correttamente pubblicate permettono di:

  • creare mappe;
  • calcolare distanze;
  • individuare servizi vicini;
  • analizzare la distribuzione territoriale;
  • costruire itinerari.

Anche qui occorre specificare il sistema di riferimento utilizzato e garantire una qualità sufficiente.


Il dato deve essere aggiornato

Uno dei problemi più seri degli Open Data è il dataset abbandonato spesso pubblicato una volta e mai più aggiornato. Formalmente continua a essere disponibile ma la sua utilità diminuisce rapidamente.

Per questo ogni dataset dovrebbe dichiarare frequenza prevista di aggiornamento e data dell'ultimo aggiornamento effettivo.

Le due cose non sono equivalenti.


Dichiarare anche quando l'aggiornamento si interrompe

Può accadere che un dataset non venga più prodotto. Non c'è nulla di necessariamente scorretto perchè:

  • Il fenomeno può non essere più rilevato.
  • La fonte può essere stata sostituita.
  • La metodologia può essere cambiata.

L'errore è lasciare il dataset online senza spiegazioni, facendo pensare che sia ancora attuale. Meglio indicare chiaramente serie conclusa al 2024 oppure dataset sostituito da…

La trasparenza vale anche quando un dato smette di essere aggiornato.


Conservare le versioni precedenti

Aggiornare non significa necessariamente cancellare. Per alcune informazioni è utile mantenere un archivio delle versioni.

Pensiamo alle strutture ricettive:

  • Un file aggiornato ci dice la situazione attuale.
  • Le versioni degli anni precedenti permettono di studiare l'evoluzione.

Un sistema Open Data maturo dovrebbe quindi valutare quando sia importante preservare anche la storia del dataset.


Un identificatore per ogni dataset

Anche i dataset stessi dovrebbero possedere identificatori stabili.

  • Il titolo può essere modificato.
  • La descrizione migliorata.
  • Il sistema di pubblicazione sostituito.

ma l'identità della serie dovrebbe rimanere riconoscibile. Questo facilita citazioni, collegamenti e aggiornamenti automatici.


Un dato deve poter essere collegato

Supponiamo di avere:

  • un dataset delle strutture ricettive;
  • uno dei quartieri;
  • uno delle fermate;
  • uno degli eventi.

Se ogni dataset utilizza nomi differenti per identificare lo stesso luogo, il collegamento diventa difficile. La vera apertura deve quindi favorire anche la possibilità di mettere in relazione dati provenienti da fonti differenti. Ed è qui che Open Data e interoperabilità iniziano a incontrarsi.


Pubblicare dati senza standard può creare nuove isole

Esiste infatti un paradosso: possiamo aprire moltissimi dataset e continuare ad avere una conoscenza frammentata.

Ogni ente pubblica:

  • formati propri;
  • categorie proprie;
  • codici propri;
  • nomi propri.

I dati sono aperti ma unirli richiede ogni volta un grande lavoro. Abbiamo trasformato i silos chiusi in silos aperti, è certamente un progresso, ma non è ancora il risultato finale.


La qualità deve poter essere misurata

Un dataset può essere valutato attraverso diversi aspetti.

Completezza Quanti valori mancano?

Accuratezza Quanto sono affidabili?

Aggiornamento Quanto sono recenti?

Coerenza Le categorie vengono utilizzate sempre nello stesso modo?

Copertura Quale parte del fenomeno rappresentano?

Accessibilità Quanto è facile ottenere il dato?

Pensare alla qualità in questi termini permette di migliorare progressivamente il patrimonio informativo.


Pubblicare gli errori corretti

Anche i dataset possono contenere errori ma non è necessariamente un fallimento.

Un sistema affidabile dovrebbe permettere di:

  • segnalare;
  • verificare;
  • correggere;
  • documentare quando necessario.

La capacità di correggere è più importante della pretesa di pubblicare dati perfetti.


La comunità può migliorare i dati

Gli Open Data generano un vantaggio particolare perchè quando molte persone utilizzano un dataset aumentano anche le possibilità che qualcuno individui un problema.

  • Uno sviluppatore trova una coordinata errata.
  • Un'associazione scopre un luogo mancante.
  • Un ricercatore individua un'incoerenza.
  • Un residente segnala un nome sbagliato.

L'apertura permette quindi anche una forma di controllo distribuito della qualità.


Ma deve esistere un canale per segnalare

Se individuiamo un errore e non sappiamo a chi comunicarlo, perdiamo questa opportunità.

Ogni dataset dovrebbe idealmente indicare:

  • responsabile;
  • contatto;
  • procedura per segnalazioni o correzioni.

Il dato aperto non deve essere soltanto scaricabile bensì entrare in un ciclo di miglioramento.


Misurare il riuso

Una domanda particolarmente interessante è: qualcuno utilizza realmente questi dati? Possiamo pubblicare centinaia di dataset senza sapere se abbiano generato valore. Sarebbe utile conoscere, almeno in parte:

  • download;
  • applicazioni sviluppate;
  • ricerche;
  • visualizzazioni;
  • servizi;
  • analisi giornalistiche;
  • riusi da parte di altre amministrazioni.

Non per stabilire che un dataset poco scaricato sia inutile - perchè alcuni dati specialistici avranno inevitabilmente pochi utenti - ma per comprendere come il patrimonio informativo viene utilizzato.


Il riuso pubblico

Un'amministrazione può diventare essa stessa utilizzatrice dei propri Open Data. Questa è una prova particolarmente significativa.

Se i dati pubblicati sono abbastanza affidabili da alimentare:

  • mappe comunali;
  • dashboard;
  • portali;
  • analisi interne;
  • servizi turistici;

significa che apertura e qualità stanno procedendo insieme.

Se invece l'ente pubblica un dataset ma continua a utilizzare internamente un archivio completamente diverso, può nascere una distanza tra dato pubblicato e dato realmente operativo.


Il riuso economico

I dati aperti possono generare anche nuove attività:

  • Un'impresa può costruire un'applicazione.
  • Una startup può sviluppare un servizio.
  • Un operatore può creare nuovi itinerari.
  • Un professionista può produrre analisi.

La pubblica amministrazione non deve necessariamente costruire ogni possibile servizio ma può creare la materia prima informativa che permette ad altri di innovare.


Il riuso civico

Esiste poi un valore meno economico ma altrettanto importante.

  • Un'associazione può analizzare la distribuzione delle strutture ricettive.
  • Un cittadino può controllare gli indicatori del Piano.
  • Un giornalista può verificare un'affermazione pubblica.
  • Un comitato di quartiere può studiare la propria zona.

Gli Open Data diventano quindi strumenti di partecipazione e controllo democratico.


Il riuso scientifico

Università e centri di ricerca possono utilizzare dati strutturati per:

  • analisi longitudinali;
  • confronti territoriali;
  • modelli;
  • studi sull'impatto del turismo;
  • ricerche sulla mobilità;
  • economia;
  • ambiente;
  • società.

Se ogni ricercatore deve prima ricostruire manualmente i dati, una parte significativa delle risorse viene spesa semplicemente per prepararli. Un'infrastruttura aperta riduce questo costo.


Il valore cresce con il riuso

Un'infrastruttura fisica tende a consumarsi quando viene utilizzata invece un dato possiede una caratteristica quasi opposta. Può essere utilizzato contemporaneamente da:

  • Comune;
  • ricercatore;
  • impresa;
  • cittadino;
  • sviluppatore;

senza consumarsi ed anzi, spesso, acquista valore proprio attraverso nuovi utilizzi.

Per questo i dati pubblici possono essere considerati un'infrastruttura ad alto potenziale moltiplicativo.


Open by default, ma con responsabilità

L'orientamento generale dovrebbe essere: quando un dato pubblico può essere aperto senza violare diritti o interessi legittimi, l'apertura dovrebbe essere la condizione normale.

Ma questo principio non deve diventare automatismo. Dobbiamo sempre verificare:

  • privacy;
  • sicurezza;
  • riservatezza;
  • segreto statistico;
  • rischio di identificazione indiretta.

Aprire responsabilmente significa anche sapere quando non aprire il dato individuale e pubblicare soltanto quello aggregato.


Aggregare senza perdere utilità

Supponiamo di raccogliere informazioni sulla spesa dei visitatori. Non abbiamo bisogno di pubblicare quanto ha speso una singola persona. Possiamo pubblicare:

  • medie;
  • fasce;
  • distribuzioni;
  • categorie;
  • aggregazioni temporali e territoriali sufficientemente ampie.

L'obiettivo è conoscere il fenomeno preservando la riservatezza.


Apertura e privacy non sono avversarie

Talvolta vengono presentate come due principi in conflitto ma in realtà possono convivere se il sistema viene progettato correttamente. I dati personali devono essere protetti mentre i dati aggregati e non personali possono essere resi disponibili quando appropriato.

La soluzione non è chiudere tutto ma distinguere accuratamente ciò che appartiene alla persona da ciò che descrive il fenomeno collettivo.


Dati leggibili anche dalle persone

L'apertura tecnica non deve farci dimenticare chi non utilizza strumenti specialistici. Un file CSV può essere perfetto per un ricercatore e poco immediato per un cittadino. Per questo agli Open Data dovrebbero affiancarsi:

  • grafici;
  • mappe;
  • dashboard;
  • spiegazioni;
  • indicatori.

Non come sostituti del dataset ma come porte di accesso differenti alla stessa conoscenza.


Una sola fonte, molte rappresentazioni

Il modello ideale diventa quindi: dataset strutturato → API → tabella → mappa → grafico → pagina informativa → servizio

Non sono dati differenti ma modi diversi di utilizzare e rappresentare la stessa fonte informativa. Questo riduce incoerenze e duplicazioni.


Open Data come politica, non come sezione del sito

Un errore frequente consiste nel considerare gli Open Data una pagina dell'amministrazione.

Esiste il portale, esiste l'elenco dei dataset:  il requisito sembra soddisfatto.

Ma una vera politica Open Data riguarda come l'intera organizzazione produce e gestisce le informazioni. Quando nasce un nuovo sistema informatico dobbiamo già chiederci:

  • i dati potranno essere esportati?
  • utilizza standard?
  • possono essere pubblicati?
  • possono dialogare con altri sistemi?
  • chi ne detiene il controllo?

L'apertura deve essere progettata all'origine.


Open Data by design

Possiamo chiamare questo principio: Open Data by design

Non raccogliere informazioni in sistemi chiusi e chiedersi anni dopo come estrarle ma progettare fin dall'inizio:

  • struttura;
  • metadati;
  • licenze;
  • formati;
  • API;
  • procedure di aggiornamento;
  • archiviazione storica.

In questo modo pubblicare diventa una funzione normale del sistema e non un lavoro straordinario.


Anche gli acquisti tecnologici sono una scelta sui dati

Se una pubblica amministrazione acquista un software che memorizza i dati in formati difficili da esportare, ha già compiuto una scelta sulla futura apertura; allo stesso modo se sceglie una piattaforma nella quale soltanto il fornitore può accedere pienamente ai dati, ha creato una dipendenza. Le specifiche degli appalti e delle forniture tecnologiche dovrebbero quindi considerare anche:

  • portabilità;
  • esportazione;
  • API;
  • standard aperti;
  • documentazione.

La politica dei dati comincia prima dell'acquisto del software.


Gli Open Data devono sopravvivere alla piattaforma

  • Un portale può essere sostituito.
  • Un CMS può cambiare.
  • Un fornitore può cessare l'attività.
  • La città continuerà però ad avere bisogno dei propri dati.

Per questo il patrimonio informativo deve poter essere esportato e trasferito. L'infrastruttura deve sopravvivere allo strumento utilizzato per pubblicarla.


L'autonomia digitale passa dai dati

Una città che non può facilmente estrarre, comprendere e riutilizzare i propri dati dipende dal sistema che li contiene. Una città che utilizza formati documentati e standard aperti può invece cambiare tecnologie mantenendo il proprio patrimonio.

L'Open Data assume quindi anche una dimensione di autonomia digitale.


Un possibile indicatore: quanto è davvero aperto un dataset?

Per ogni dataset potremmo porre una serie di domande molto semplici:

  • È facile da trovare?
  • Possiede una descrizione?
  • La fonte è indicata?
  • La licenza è chiara?
  • È scaricabile?
  • Utilizza un formato aperto?
  • I campi sono documentati?
  • È aggiornato?
  • Conserva le serie storiche?
  • Possiede un contatto?
  • Può essere collegato con altri dati?
  • È già stato riutilizzato?

In questo modo possiamo smettere di misurare soltanto “quanti dataset abbiamo pubblicato?” e iniziare a chiederci “quanto sono realmente utilizzabili i dati che abbiamo aperto?”


Dal numero dei dataset alla qualità dell'ecosistema

Pubblicare mille dataset non significa necessariamente avere un sistema migliore di chi ne pubblica cento. Se quei cento sono:

  • aggiornati;
  • documentati;
  • interoperabili;
  • utilizzati;
  • collegabili;
  • facili da trovare;

possono produrre un valore molto maggiore. La quantità rimane un indicatore ma non può essere l'obiettivo principale.


La Banca Dati Turistica Aperta come laboratorio

La Banca Dati descritta nel capitolo precedente può diventare anche il luogo nel quale sperimentare questi principi. Ogni dataset dovrebbe essere accompagnato da:

  • metadati;
  • licenza;
  • fonte;
  • stato di aggiornamento;
  • documentazione;
  • modalità di accesso;
  • eventuali limiti.

Non soltanto un pulsante: Download. Ma un contesto che permetta di capire cosa stiamo scaricando.


GiraSalerno come dimostrazione del riuso

Anche GiraSalerno può svolgere un ruolo importante:

  • Se utilizza un dataset aperto regionale sulle strutture ricettive, deve mostrare concretamente che quel dato può generare un servizio.
  • Se utilizza dati sugli eventi, può dimostrare che una singola fonte strutturata può alimentare più visualizzazioni.
  • Se rende disponibili API proprie per dati prodotti dal progetto, può permettere ad altri di costruire ulteriori servizi.

Il dimostratore diventa così una verifica pratica del principio: il valore dell'Open Data emerge quando qualcuno lo riutilizza.


Pubblicare è l'inizio, non la fine

Possiamo allora riassumere l'intero capitolo in una sequenza:

  • Produrre.
  • Documentare.
  • Aprire.
  • Far trovare.
  • Permettere il riuso.
  • Collegare.
  • Aggiornare.
  • Correggere.
  • Misurare il riuso.
  • Migliorare.

La pubblicazione è soltanto uno dei passaggi.


Una cultura dell'apertura

La vera trasformazione non consiste nel creare una nuova sezione Open Data ma nel cambiare una domanda.

Invece di chiedere “dobbiamo pubblicare questo dato?” una pubblica amministrazione matura dovrebbe sempre più spesso chiedersi “esiste una ragione legittima per cui questo dato pubblico non possa essere aperto e riutilizzato?”

Naturalmente nel rispetto della legge, della privacy e della sicurezza. È una diversa cultura dell'informazione.


Dall'apertura al riuso

A questo punto abbiamo:

  • Dati aperti.
  • Documentati.
  • Aggiornati.
  • Tecnicamente accessibili.

ma rimane una domanda:  Che cosa succede dopo?

Lo stesso dataset può alimentare una pagina web, un'applicazione, una mappa, una ricerca, un sistema di analisi, un servizio commerciale o uno strumento civico. Il valore non sta soltanto nel dato ma nella capacità di utilizzarlo molte volte senza doverlo ricreare.