Stabiliamo una regola fondamentale: i dati prodotti dal Piano devono essere, per quanto possibile, aperti, documentati e riutilizzabili. Non semplicemente consultabili, non soltanto visibili dentro una mappa, non rinchiusi in PDF. Ma aperti.

Questo significa che cittadini, tecnici, ricercatori, giornalisti, scuole, associazioni e sviluppatori devono poter prendere quei dati, analizzarli, confrontarli e riutilizzarli. Per Salerno Verde gli Open Data non sono quindi un servizio accessorio ma sono una componente della trasparenza democratica del Piano.

Open by default

Il principio di fondo dovrebbe essere:

Open by default

Tutto ciò che può essere pubblicato legalmente e senza compromettere privacy, sicurezza o altri interessi tutelati dovrebbe essere considerato, in partenza, pubblicabile. L'eccezione deve essere motivata, non il contrario. Questo cambia profondamente il modo di pensare l'informazione pubblica. Non: “possiamo pubblicarlo?” ma: “esiste un motivo concreto per non pubblicarlo?”

Pubblico non significa aperto

Un errore molto comune consiste nel confondere: dato pubblico e Open Data.

Un'informazione può essere disponibile online e rimanere praticamente inutilizzabile. Per esempio:

• una tabella dentro un PDF;
• una mappa consultabile soltanto graficamente;
• un'immagine;
• un file senza licenza;
• un dataset privo di metadati.

Il cittadino può guardarlo. Ma difficilmente può:

• scaricarlo;
• analizzarlo;
• incrociarlo;
• aggiornarlo;
• riutilizzarlo.

Open Data significa andare oltre la semplice pubblicazione.

Il PDF non è il dato

Il PDF rimane utilissimo per:

• relazioni;
• rapporti;
• documenti;
• sintesi.

Ma se pubblichiamo un elenco di migliaia di alberi soltanto dentro un PDF abbiamo prodotto principalmente un documento da leggere non un dataset. Il dato dovrebbe essere disponibile anche, quando appropriato, in formati come:

• CSV;
• JSON;
• GeoJSON;
• GeoPackage;
• altri formati aperti e documentati.

Il PDF può accompagnare il dato. Non deve sostituirlo.

Dati geografici realmente utilizzabili

Salerno Verde sarà fortemente basato su informazioni territoriali per questo dobbiamo prestare particolare attenzione ai formati geografici. Possiamo prevedere, secondo il tipo di dataset:

• GeoJSON;
• GeoPackage;
• CSV con coordinate;
• servizi standard interoperabili.

L'obiettivo deve essere semplice: un utente deve poter scaricare un dataset e aprirlo facilmente con Software Libero come QGIS.

Evitare dipendenze inutili

Questo non significa demonizzare ogni formato proprietario. In alcuni contesti amministrativi potrà ancora essere utilizzato ma la pubblicazione deve offrire almeno una versione in formato aperto o ampiamente interoperabile. Un cittadino non dovrebbe essere obbligato ad acquistare un particolare software per utilizzare un dato pubblico.

Open Data significa licenza

Un file scaricabile senza indicazioni sulla licenza non è davvero aperto. L'utente deve sapere chiaramente:

• posso riutilizzarlo?
• posso modificarlo?
• posso redistribuirlo?
• devo citare la fonte?

Ogni dataset dovrà quindi avere una licenza esplicita e per quanto compatibile con la normativa e la natura del dato, dovremmo privilegiare licenze aperte che favoriscano il riuso.

Una politica delle licenze

Salerno Verde dovrebbe adottare una semplice:

Politica delle Licenze Aperte

che definisca criteri comuni per:

• dati;
• cartografie;
• documentazione;
• fotografie;
• codice.

L'obiettivo è evitare che ogni ufficio scelga una soluzione differente o, peggio, non ne scelga nessuna.

Il dato deve avere una fonte

Ogni dataset deve indicare chiaramente:

• chi lo produce;
• chi lo aggiorna;
• quando;
• con quale metodologia;
• con quale livello di affidabilità.

Non basta scrivere: “Comune di Salerno”.

Serve una responsabilità informativa più precisa. Il dato aperto deve essere tracciabile.

I metadati

Ogni dataset dovrebbe avere almeno:

• titolo;
• descrizione;
• responsabile;
• data di aggiornamento;
• frequenza prevista;
• copertura territoriale;
• formato;
• licenza;
• sistema di riferimento geografico quando necessario;
• metodologia;
• limitazioni note.

I metadati sono parte integrante del dato. Senza di essi un file può essere tecnicamente scaricabile ma difficile da comprendere correttamente.

La data di aggiornamento deve essere evidente

Uno dei problemi peggiori degli Open Data è il dato apparentemente attuale ma in realtà fermo da anni. Ogni pagina deve quindi mostrare chiaramente: Ultimo aggiornamento: ... e, quando possibile: Prossimo aggiornamento previsto: ...

Il cittadino deve poter distinguere un dato corrente da uno storico.

Dataset vivi e dataset storici

Non tutti i dati devono essere aggiornati frequentemente. Una ortofoto storica può essere preziosissima pur non cambiando. La distinzione deve quindi essere esplicita:

• Dataset operativo viene aggiornato regolarmente.
• Dataset periodico viene aggiornato con frequenza definita.
• Dataset storico fotografa una situazione conclusa.

Non è un problema che un dato sia vecchio. È un problema non sapere che lo è.

Quali dati aprire per primi

Salerno Verde non deve tentare di pubblicare tutto contemporaneamente.

Nella prima fase si propone una scelta di priorità:

PRIORITÀ 1 – Catasto Arboreo pubblico

Per quanto disponibile e verificato:

• identificativo;
• posizione;
• specie;
• principali informazioni pubblicabili;
• stato.

PRIORITÀ 2 – Parchi e giardini

• Perimetri;
• superficie;
• accessi;
• informazioni di base.

PRIORITÀ 3 – Interventi Salerno Verde

• Progetti;
• stato;
• costo;
• responsabile;
• scadenze.

PRIORITÀ 4 – Suolo e permeabilità

Dati utilizzati per la baseline.

PRIORITÀ 5 – Scuole Verdi

Interventi e indicatori.

PRIORITÀ 6 – Segnalazioni aggregate e anonimizzate

Dove compatibile con privacy e sicurezza.

Pochi dataset di qualità prima di una lunga lista di file inutilizzabili.

Il Catasto Arboreo come dataset simbolico

Il primo grande test potrebbe essere proprio il patrimonio arboreo. Un cittadino dovrebbe poter scaricare il dataset e capire:

• dove sono gli alberi pubblici censiti;
• quali specie;
• quali aree hanno maggiore o minore presenza.

Potrebbe poi utilizzare quei dati per:

• ricerca;
• visualizzazioni;
• didattica;
• controllo civico.

Il dato amministrativo acquista una seconda vita.

Dati derivati

Non tutti i dataset devono essere raccolti manualmente. Salerno Verde produrrà anche dati derivati. Per esempio:

• copertura arborea;
• distanza dal verde;
• indice di priorità;
• statistiche per quartiere.

In questi casi la pubblicazione deve spiegare chiaramente:

• quale dato di base è stato utilizzato;
• quale metodo;
• quale versione dello script;
• quale data.

Così il risultato può essere replicato.

Pubblicare anche il metodo

Questo è uno degli elementi che caratterizzano il progetto. Non basta pubblicare: “Quartiere X: indice 7,2”

Dobbiamo spiegare: 

• come è stato calcolato?
• Quali pesi?
• Quali variabili?

Il metodo può essere contestato e migliorato e deve essere parte del dibattito pubblico.

Codice e dati insieme

Quando un indicatore viene prodotto attraverso uno script, Salerno Verde dovrebbe cercare di pubblicare entrambi:

dataset e codice di elaborazione.

Un ricercatore può così verificare il calcolo. Una scuola può utilizzarlo. Un altro Comune può adattarlo.

Qui Open Data e Software Libero si incontrano direttamente.

L'API pubblica

Per i dati più dinamici non possiamo pensare soltanto al download manuale dei file.

Potrebbe essere utile esporre una:

API Salerno Verde

attraverso la quale interrogare, per esempio:

• alberi;
• parchi;
• interventi;
• indicatori.

Non serve costruire subito una API gigantesca ma partire dai dati realmente utilizzati.

API documentata

Una API senza documentazione è quasi inutilizzabile. Dovrà quindi spiegare:

• endpoint;
• campi;
• filtri;
• formati;
• limiti;
• versioni;
• licenza.
• Esempi pratici.

Anche qui la semplicità deve venire prima della sofisticazione.

Non obbligare a usare l'API

L'API è utile soprattutto a sviluppatori e ricercatori.

Il cittadino meno tecnico deve poter comunque scaricare:

• CSV;
• GeoJSON;
• altri file.

Gli Open Data devono essere utilizzabili a più livelli di competenza.

Download semplice

Il portale dovrebbe permettere, idealmente: Visualizza --> Scarica --> Interroga via API

Tre livelli differenti:

• La mappa serve a vedere.
• Il download serve ad analizzare.
• L'API serve a integrare.

Versionamento

Quando un dataset cambia, dobbiamo conservare la possibilità di sapere cosa c'era prima. Questo è essenziale soprattutto per:

• alberi;
• consumo di suolo;
• progetti;
• indicatori.

Potremmo quindi mantenere versioni periodiche o uno storico delle modifiche. Il cittadino non vuole soltanto sapere: come è Salerno oggi? Potrebbe voler sapere: come è cambiata?

Un archivio Open Data storico

Salerno Verde dovrebbe quindi conservare anche gli snapshot significativi. Per esempio:

• Catasto Arboreo 2027;
• 2030;

Non necessariamente una copia completa ogni giorno mana strategia di versionamento proporzionata al dato. Questo costruisce una vera memoria digitale del territorio.

L'immutabilità degli atti storici

Alcuni dati non devono essere sovrascritti. Un progetto completato nel 2030 deve continuare a mostrare:

• costo finale;
• tempi reali;
• indicatori.

Non deve essere aggiornato come se fosse ancora in corso. Lo storico deve essere trattato come patrimonio documentale.

Un identificativo stabile

Per rendere i dati collegabili nel tempo servono identificativi persistenti:

• Un albero.
• Un parco.
• Una scuola.
• Un progetto.

dovrebbero conservare lo stesso identificativo nel tempo.

In questo modo dataset differenti possono essere incrociati. Per esempio:

• SV-ALB-000123
• SV-PAR-00008
• SV-PROG-2030-004

Le sigle sono puramente esemplificative. Il principio è importante.

Linked data? Solo se serve

Potremmo essere tentati di utilizzare tecnologie molto avanzate.

• Linked Open Data.
• Ontologie complesse.
• Knowledge graph.

Possono avere grande valore in alcuni contesti ma applichiamo il principio di realismo. Se un CSV ben documentato risolve il problema, non abbiamo bisogno di costruire immediatamente un'infrastruttura semantica complessa.

Prima il dato utile. Poi, se esiste una reale necessità, possiamo evolvere.

Un catalogo leggibile anche dagli esseri umani

Il portale Open Data non deve essere soltanto un catalogo tecnico. Per ogni dataset dovrebbe esserci una breve spiegazione:

• che cosa racconta;
• a cosa può servire;
• quali limiti possiede.

Per esempio:

Questo dataset contiene gli alberi pubblici censiti. Non rappresenta necessariamente la totalità del patrimonio arboreo privato della città.

Una frase può evitare molte interpretazioni sbagliate.

Qualità del dato

Aprire un dato sbagliato non produce automaticamente trasparenza. Dobbiamo quindi associare progressivamente indicatori di qualità:

• Completezza.
• Aggiornamento.
• Accuratezza.
• Copertura.

Potremmo persino usare semplici livelli:

• Completo
• Parziale
• In aggiornamento
• Sperimentale

Il cittadino deve poter capire quanto fidarsi.

Il diritto di segnalare errori

Ogni dataset dovrebbe avere anche un meccanismo per segnalare:

• errori;
• duplicazioni;
• coordinate sbagliate;
• informazioni obsolete.

Un cittadino potrebbe accorgersi che un albero presente nella mappa non esiste più. Quindi:

• Segnala.
• Il dato viene verificato.
• Eventualmente corretto.

Gli Open Data diventano così anche collaborativi nella qualità, pur mantenendo la validazione pubblica.

Non modificare direttamente il dato ufficiale

La collaborazione non significa permettere a chiunque di modificare il database comunale.

La procedura deve essere: SEGNALA → VERIFICA → CORREGGI.

Il dato ufficiale rimane responsabilità dell'ente. Il cittadino contribuisce alla sua qualità.

Privacy

Le segnalazioni civiche possono contenere:

• nomi;
• indirizzi email;
• fotografie;
• informazioni personali.

Questi elementi non devono automaticamente entrare negli Open Data. Il dataset pubblico può invece contenere, quando utile:

• localizzazione;
• categoria;
• stato;
• data;
• esito,

anonimizzando o escludendo ciò che non è necessario.

Sicurezza

Anche alcuni dati territoriali potrebbero richiedere valutazioni specifiche. Open by default non significa: pubblicare qualunque informazione interna.

La regola corretta è: massima apertura compatibile con legge, privacy, sicurezza e interesse pubblico.

Ma le eccezioni dovrebbero essere motivate e circoscritte.

Accessibilità digitale

Un portale Open Data realmente pubblico deve essere utilizzabile anche da persone con disabilità.

• Navigazione.
• Contrasto.
• Testi alternativi.
• Tabelle.
• Tastiera.

La trasparenza non è completa se lo strumento che la realizza è inaccessibile.

Nessuna registrazione obbligatoria per scaricare

Per i dataset realmente aperti eviterei, salvo necessità specifiche, l'obbligo di:

• registrarsi;
• fornire email;
• creare account.

Il cittadino dovrebbe poter scaricare direttamente: Open Data significa anche ridurre le barriere al riuso.

Statistiche di utilizzo

Possiamo comunque conoscere in forma aggregata:

• quali dataset vengono scaricati;
• quali API vengono utilizzate;
• quali pagine consultate.

Questo può aiutarci a capire dove investire ma senza trasformare il portale Open Data in uno strumento invasivo di tracciamento degli utenti.

Scuole e Open Data

Gli Open Data possono avere un enorme valore educativo. Una classe potrebbe analizzare:

• gli alberi intorno alla scuola;
• la distanza dal parco;
• la temperatura;
• il consumo di suolo.

Non dati inventati per l'esercizio ma  Dati reali della propria città. La cultura del dato diventa educazione civica.

Università e ricerca

Per l'università un sistema stabile di Open Data territoriali può produrre:

• tesi;
• ricerche;
• modelli;
• analisi.

E il risultato di queste ricerche può tornare alla città. Salerno Verde diventa una piattaforma di conoscenza aperta anche per la ricerca locale.

Giornalismo e controllo pubblico

Anche la stampa può utilizzare i dati.

• Quanti alberi sono stati abbattuti?
• Quanto è costato un programma?
• Quali quartieri hanno ricevuto più interventi?

Il controllo giornalistico può diventare molto più solido quando non dipende soltanto da comunicati ufficiali. Questo è un beneficio, non una minaccia.

Il cittadino può costruire un'app migliore della nostra

Se i dati e le API sono aperti, qualcuno potrebbe sviluppare un servizio migliore dell'interfaccia comunale. Benissimo.

Una applicazione per:

• gli alberi;
• i parchi;
• i percorsi ombreggiati;
• le fontanelle.

Il Comune non deve necessariamente sviluppare ogni possibile servizio ma deve costruire la piattaforma informativa che rende possibile farlo.

Ecosistema, non monopolio del portale

Questa è una differenza fondamentale. Un modello chiuso dice:

per usare i nostri dati devi utilizzare la nostra applicazione.

Un modello aperto dice:

questa è la fonte pubblica; costruisci pure il servizio che ritieni utile.

È una concezione molto più ricca dell'innovazione civica.

Hackathon? Solo se producono qualcosa di utile

Open Data può portare anche a iniziative come hackathon o laboratori. Possono essere interessanti ma non devono diventare eventi celebrativi. Se li organizziamo, chiediamo risultati riusabili:

• prototipi;
• visualizzazioni;
• analisi;
• documentazione;
• codice libero.

Meglio pochi progetti realmente continuati che decine di prototipi abbandonati il giorno successivo.

Data Challenge civiche

Un'alternativa interessante potrebbe essere proporre specifiche domande. Per esempio:

• Quali sono i percorsi scolastici con minore copertura arborea?
• Quali quartieri hanno il maggiore deficit di verde?

Mettere a disposizione dati e invitare:

• università;
• scuole;
• cittadini;
• professionisti

a proporre analisi.

Il dato aperto diventa strumento di intelligenza collettiva.

Il Comune deve riutilizzare i propri Open Data

Una prova molto semplice della qualità del sistema è questa: gli stessi uffici riescono a utilizzare i dati pubblicati?

Se il dataset Open Data è talmente difficile o incompleto che persino il Comune continua a utilizzare una copia privata differente, abbiamo un problema. La pubblicazione dovrebbe derivare dalla stessa fonte autorevole utilizzata internamente.

Open Data by design

Questo ci porta a un principio importante: non dobbiamo creare il dato internamente e chiederci solo alla fine come pubblicarlo.

Quando progettiamo una nuova banca dati dobbiamo già pensare:

• quali campi saranno pubblici?
• quale licenza?
• quale formato?
• quale API?
• quale aggiornamento?

La pubblicazione deve nascere insieme al sistema.

Appalti Open Data by default

Questa regola deve entrare anche negli affidamenti. Se una società viene incaricata di censire gli alberi, il contratto deve stabilire:

• formato di consegna;
• schema dati;
• diritti;
• licenza;
• documentazione;
• modalità di aggiornamento.

Non accettare soltanto: un bel PDF finale e un file utilizzabile esclusivamente con il software del fornitore.

Nessun dato pagato due volte

Se un dataset è stato prodotto con risorse pubbliche e può essere legalmente aperto, non dovremmo dover pagare nuovamente un fornitore per estrarlo dal sistema che abbiamo finanziato. La portabilità deve essere garantita dal contratto. È un principio semplice ma importantissimo.

Public Money, Public Data

Accanto a: Public Money, Public Code

Salerno Verde può assumere un principio parallelo:

Public Money, Public Data

Naturalmente nel rispetto delle eccezioni previste.

Se una rilevazione viene realizzata con risorse pubbliche e descrive un bene pubblico, il dato dovrebbe tendenzialmente tornare alla comunità in forma aperta.

Open Data non significa costo zero

Anche qui dobbiamo essere realistici. Pubblicare dati bene richiede:

• persone;
• server;
• documentazione;
• controlli;
• aggiornamento;
• sicurezza.

Il vero costo non è mettere online il file. È tenerlo affidabile nel tempo. Per questo gli Open Data devono entrare nel bilancio ordinario del sistema informativo.

Pochi ma vivi

Una delle regole che proporrei è: meglio 20 dataset aggiornati che 200 dataset abbandonati.

Il numero dei dataset non deve essere utilizzato come indicatore principale del successo e la qualità deve prevalere sempre sulla quantità.

Un indicatore di aggiornamento

Il cruscotto interno potrebbe mostrare:

• dataset previsti;
• dataset aggiornati entro la frequenza stabilita;
• dataset scaduti.

In questo modo anche gli Open Data diventano una responsabilità misurabile.

Il catalogo delle richieste

I cittadini potrebbero anche proporre nuovi dataset da aprire.

Una sezione:

Quale dato ti serve?

Le richieste vengono:

• registrate;
• valutate;
• classificate.

Il Comune potrebbe rispondere:

• dato disponibile – pubblicazione prevista;
• dato non disponibile;
• dato non pubblicabile;
• dato da produrre.

Anche qui partecipazione tracciabile.

Motivare il dato non aperto

Quando un dataset importante non può essere pubblicato, sarebbe utile spiegare sinteticamente il motivo:

• Privacy.
• Copyright.
• Sicurezza.
• Dato non disponibile.
• Vincolo contrattuale da superare.

questo è molto più trasparente del semplice silenzio.

La cultura interna dell'apertura

La maggiore difficoltà potrebbe non essere tecnologica ma culturale. In molti uffici il dato viene ancora percepito come qualcosa che appartiene al settore che lo produce.

Salerno Verde propone invece: il settore è responsabile del dato; il dato appartiene al sistema pubblico.

Questo cambiamento richiederà tempo e formazione.

Formazione Open Data

I dipendenti coinvolti dovrebbero conoscere almeno:

• principi;
• licenze;
• formati;
• metadati;
• privacy;
• qualità.

Non tutti devono diventare data scientist ma devono comprendere perché un file denominato:

alberi_finale_definitivo2.xlsx

non rappresenta una buona strategia informativa per i prossimi venticinque anni.

Standardizzare

Molti problemi possono essere evitati definendo fin dall'inizio:

• nomi dei campi;
• codici;
• date;
• coordinate;
• identificativi;
• valori ammessi.

Uno standard interno produce automaticamente Open Data migliori.

Il dizionario dei dati

Il Sistema Informativo dovrebbe quindi possedere un:

Dizionario dei Dati Salerno Verde

Per ogni campo:

• nome;
• descrizione;
• tipo;
• unità di misura;
• valori possibili.

Per esempio:

canopy_area_m2

Superficie stimata della chioma in metri quadrati. La documentazione diventa patrimonio riusabile.

Anche le API devono avere versioni

Se un'applicazione esterna utilizza la nostra API, non possiamo cambiarne improvvisamente la struttura senza avvisare. Servirà quindi un semplice sistema di versionamento:

• v1.
• v2.
• Periodo di transizione.

Ancora una volta: non serve complessità eccessiva. Serve prevedibilità.

Un portale che non nasconde il download

Un dettaglio apparentemente banale.

Il portale pubblico non deve costringere l'utente a cercare per dieci minuti il file originale.

Vicino alla mappa: Scarica i dati.

Vicino al grafico: Fonte e dataset.

Vicino all'indicatore: Metodologia.

La trasparenza deve essere progettata anche nell'interfaccia.

Ogni grafico deve portare alla fonte

Se il Cruscotto Salerno Verde mostra: “Copertura arborea: 18,7%”

il cittadino dovrebbe poter raggiungere:

• dataset;
• metodo;
• data;
• script quando appropriato.

Il numero non deve diventare un atto di fede.

Le mappe scaricabili

Anche gli elaborati cartografici principali del Piano dovrebbero essere disponibili in forma riusabile, quando possibile.

• Carta della Struttura Ecologica.
• Carta dei 300 metri.
• Carta delle Chiome.
• Carta della Permeabilità.

Non soltanto immagini ma nche dati geografici di base e metodologia.

Distinguere dato e proposta

Questo sarà particolarmente importante per le carte progettuali. Una superficie può essere:

verde esistente oppure verde proposto. La codifica deve essere chiara.

Lo stesso vale per i corridoi. Una cartografia aperta non deve perdere le distinzioni metodologiche fondamentali.

Open Data e memoria politica

Gli Open Data hanno anche una funzione politica nel senso più ampio. Tra dieci anni sarà possibile verificare:

quale era la copertura arborea nel 2027;

• quali aree risultavano permeabili;
• quali progetti erano previsti;
• cosa è cambiato.

La memoria della città non dipende più soltanto dalle dichiarazioni ma anche dalle serie storiche pubbliche.

Proteggere i dati dalla riscrittura

Naturalmente gli errori devono poter essere corretti ma le versioni storiche devono restare disponibili. Se un dato del 2027 viene corretto nel 2029, possiamo indicarlo.

La trasparenza non significa rendere il dato immutabile ma rendere tracciabile la sua evoluzione.

Un'infrastruttura democratica

Arriviamo così al significato più importante: Gli Open Data non sono soltanto tecnologia.

Permettono ai cittadini di non dipendere interamente dall'interpretazione dell'Amministrazione. Possono:

• contare;
• confrontare;
• mappare;
• contestare;
• confermare.

La relazione tra istituzione e cittadino diventa più equilibrata.

Il cittadino non deve chiedere ogni volta il permesso di conoscere

Per i dati già pubblicabili, il modello dovrebbe evitare che ogni domanda richieda:

• istanza;
• PEC;
• attesa;
• risposta.

L'accesso agli atti rimane fondamentale per ciò che non è già pubblicato ma una politica Open Data ben costruita riduce drasticamente la necessità di chiedere informazioni che il Comune può rendere disponibili in modo permanente.

Dalla trasparenza reattiva alla trasparenza preventiva

Questa è la trasformazione che proponiamo.

Non: il cittadino chiede → il Comune risponde.

Ma, sempre più: il Comune pubblica prima → il cittadino utilizza.

Possiamo chiamarla:

Trasparenza preventiva

È perfettamente coerente con la filosofia politica di Salerno Verde.

La comunità può vedere prima

Questo è particolarmente importante per le trasformazioni territoriali. Se cartografie, progetti, stato degli interventi e dati urbanistici pubblicabili sono facilmente disponibili, associazioni e cittadini possono accorgersi prima di:

• cambiamenti;
• criticità;
• opportunità.

La partecipazione diventa meno tardiva.

Open Data e fiducia

La trasparenza non elimina automaticamente la diffidenza ma modifica il terreno sul quale avviene il confronto.

L'Amministrazione può dire: questi sono i dati.

Il cittadino può controllarli. Se emerge un errore, può essere corretto.

La fiducia non viene chiesta. Viene costruita attraverso verificabilità.

Non pubblicare soltanto buone notizie

Il portale deve mostrare anche:

• alberi abbattuti;
• progetti annullati;
• target mancati;
• riduzioni di superficie permeabile;
• ritardi.

Open Data non è comunicazione istituzionale è informazione.

Anche le perdite vanno misurate

Se nel 2030 guadagniamo 10.000 m² deimpermeabilizzati ma nello stesso anno ne impermeabilizziamo 30.000, il dato deve mostrarlo.

Non soltanto il risultato positivo. La misura deve essere del saldo reale.

Un Patto Open Data Salerno Verde

Potremmo sintetizzare il capitolo in un piccolo patto. Salerno Verde si impegna, per quanto possibile, a pubblicare dati:

APERTI riutilizzabili.

DOCUMENTATI comprensibili.

AGGIORNATI con frequenze dichiarate.

VERSIONATI per conservare la memoria.

INTEROPERABILI senza dipendenza da un software specifico.

LICENZIATI con condizioni chiare.

VERIFICABILI insieme alla metodologia.

ACCESSIBILI anche alle persone con disabilità.

Il dato come bene comune digitale

Un albero pubblico è patrimonio della città, un parco è patrimonio della città, anche il dato che descrive quell'albero o quel parco può diventare, quando pubblicabile, parte del patrimonio informativo collettivo.

• Può essere copiato senza consumarsi.
• Riutilizzato senza sottrarlo a qualcuno.
• Migliorato.
• Incrociato.

Questo rende il dato una risorsa pubblica particolarmente potente.

Dal dato aperto alla città aperta

Il vero obiettivo non è quindi possedere un buon portale Open Data. È molto più grande. Costruire una città nella quale la conoscenza del territorio sia progressivamente:

• meno concentrata;
• meno dipendente dagli uffici;
• meno dipendente dai fornitori;
• più condivisa;
• più verificabile.

Gli Open Data diventano così una condizione della partecipazione attiva.

Perché un cittadino può partecipare davvero soltanto se possiede anche gli strumenti per conoscere ciò su cui è chiamato a intervenire.

La regola finale

Per ogni nuovo dataset prodotto da Salerno Verde dovremo quindi porci una domanda: perché questo dato non dovrebbe essere aperto?

Se esiste una ragione legittima, la rispetteremo ma se non esiste, lo pubblicheremo.

• Con formato aperto.
• Licenza.
• Metadati.
• Aggiornamento.
• Metodo.

Perché l'informazione prodotta dal Piano non deve fermarsi nel computer di chi la crea m deve poter tornare alla comunità che l'ha finanziata e che quella città la vive.

Open by default. Non come slogan tecnologico ma come principio democratico di Salerno Verde.