Interoperabilità

Eccoci ai sistemi differenti capaci di parlare tra loro. Finora abbiamo organizzato i dati, li abbiamo resi aperti, abbiamo mostrato come uno stesso dato possa essere utilizzato per molti servizi. Rimane però un problema fondamentale: i dati vengono prodotti da soggetti differenti:

• Comune.
• Regione.
• Enti culturali.
• Gestori della mobilità.
• Operatori.
• Università.
• Organizzatori di eventi.
• Altri soggetti pubblici e privati.

Ognuno può utilizzare software, database, classificazioni e procedure differenti. Come possiamo costruire una conoscenza comune senza obbligare tutti a utilizzare lo stesso sistema?

La risposta è: interoperabilità.

Che cosa significa interoperabilità

Possiamo definirla in maniera molto semplice: la capacità di sistemi differenti di scambiarsi informazioni e di comprenderne correttamente il significato.

Non basta quindi trasferire un file. Se un sistema invia TIPO = 04 e l'altro non sa cosa significhi “04”, abbiamo trasferito un dato ma non abbiamo trasferito conoscenza. L'interoperabilità richiede che entrambi comprendano:

• cosa rappresenta;
• come è strutturato;
• quali regole utilizza;
• a quale entità si riferisce.

Parlare non significa capirsi

Due persone possono utilizzare la stessa lingua e non comprendersi se attribuiscono significati differenti alle parole e lo stesso accade tra sistemi informatici.

Un database può chiamare luogo ciò che un altro chiama punto di interesse. Un terzo: attrattore. Un quarto: POI.

Il problema non consiste necessariamente nell'utilizzare parole differenti ma è importante sapere che, in determinati casi, quelle categorie descrivono lo stesso concetto o concetti collegabili. Interoperabilità significa quindi anche costruire corrispondenze di significato.

Non dobbiamo uniformare tutto

Questo punto è essenziale. Interoperabilità non significa che tutti debbano utilizzare:

• lo stesso software;
• lo stesso database;
• lo stesso sito;
• la stessa organizzazione interna.

Il gestore del trasporto deve poter utilizzare gli strumenti più adatti alla mobilità. Un museo quelli più adatti alla gestione culturale. La Regione i propri sistemi. Il Comune i propri. GiraSalerno i propri.

L'obiettivo non è uniformare le organizzazioni ma stabilire punti di comunicazione condivisi.

L'esempio delle prese elettriche

Possiamo utilizzare una metafora. Non abbiamo bisogno di conoscere il funzionamento interno di una centrale elettrica per collegare un apparecchio alla rete. Abbiamo bisogno di uno standard.

La presa, la tensione. le caratteristiche della rete, dispositivi costruiti da produttori differenti possono funzionare perché rispettano alcune regole comuni.

Un principio analogo vale per i dati. I sistemi possono essere completamente differenti al loro interno, devono però concordare come scambiarsi determinate informazioni.

Quattro livelli dell'interoperabilità

Per comprenderla meglio possiamo distinguere almeno quattro dimensioni.

Interoperabilità tecnica Come avviene lo scambio?

Interoperabilità sintattica In quale formato vengono rappresentati i dati?

Interoperabilità semantica Che cosa significano?

Interoperabilità organizzativa Chi produce, aggiorna, verifica e rende disponibile l'informazione?

Se manca uno di questi livelli, il collegamento può funzionare soltanto parzialmente.

Interoperabilità tecnica

È il livello più immediato. Due sistemi devono avere un modo per comunicare.

Può avvenire attraverso:

• file;
• feed;
• API;
• servizi web;
• altri protocolli standard.

Ad esempio, un sistema può chiedere “quali eventi sono programmati domani?” e ricevere automaticamente la risposta. Non serve copiare manualmente gli eventi da una pagina web.

Interoperabilità sintattica

Dopo aver stabilito il canale dobbiamo stabilire il formato. Se un sistema invia una data come 2026-08-29 e l'altro sa che rappresenta 29 agosto 2026 la comunicazione funziona.

Se uno interpreta il primo numero come giorno e l'altro come mese, nasce un errore.

Formati standard come CSV, JSON, XML o GeoJSON possono facilitare lo scambio perché possiedono regole conosciute e documentabili ma il formato da solo non basta.

Interoperabilità semantica

Supponiamo che due sistemi abbiano entrambi un campo: accessibile = sì

Sembrano perfettamente interoperabili ma cosa significa “accessibile”?

• Accesso senza gradini?
• Servizi igienici accessibili?
• Ascensore?
• Accessibilità sensoriale?
• Accessibilità complessiva?

Se i due sistemi utilizzano definizioni differenti, il dato tecnicamente identico può produrre informazioni sbagliate. L'interoperabilità semantica riguarda quindi il significato condiviso dei dati.

Interoperabilità organizzativa

Infine dobbiamo sapere chi fa cosa.

• Chi aggiorna l'orario?
• Chi comunica una modifica?
• Chi verifica una segnalazione?
• Chi mantiene l'API?
• Cosa succede se la fonte non è disponibile?
• Con quale frequenza viene aggiornato il dato?

Un collegamento tecnicamente perfetto può diventare inutile se nessuno possiede la responsabilità di mantenere l'informazione.

L'interoperabilità è quindi anche organizzazione.

Una quinta dimensione: quella giuridica

Possiamo aggiungere un'altra dimensione particolarmente importante quando parliamo di dati pubblici e privati.

Il dato può essere tecnicamente disponibile ma abbiamo il diritto di utilizzarlo? La licenza permette il riuso? Contiene dati personali? Esistono limitazioni?

Lo scambio tra sistemi deve avvenire anche all'interno di regole giuridiche comprensibili. L'interoperabilità non può ignorare:

• privacy;
• licenze;
• diritti;
• responsabilità.

L'identificatore comune

Uno degli strumenti più importanti per far dialogare sistemi differenti è l'identificatore. Torniamo al Castello di Arechi. Un sistema può chiamarlo Castello di Arechi, un altro Castello Arechi, un servizio in inglese Arechi Castle.

Se utilizziamo soltanto il nome, dobbiamo continuamente verificare se stiamo parlando dello stesso luogo ma se esiste un identificatore stabile, possiamo sapere che le differenti denominazioni fanno riferimento alla stessa entità. Il nome serve alle persone. L'identificatore aiuta i sistemi a riconoscere l'identità.

Non inventare identificatori quando esistono già

Anche qui vale il principio del riuso. Se una fonte autorevole possiede già un identificatore stabile e pubblico, dovremmo valutare di utilizzarlo o collegarlo.

Creare continuamente nuovi codici locali può produrre un nuovo problema. Potremmo avere:

identificatore comunale;

identificatore regionale;

identificatore del portale turistico;

identificatore del museo;

identificatore di GiraSalerno.

Non sempre possiamo evitarlo ma possiamo costruire relazioni tra gli identificatori.

Lo stesso luogo in sistemi differenti

Possiamo immaginare una tabella di corrispondenza:

Entità locale: luogo_00125
Identificatore regionale: ...
Identificatore comunale: ...
Identificatore esterno: ...

In questo modo non obblighiamo tutti a cambiare i propri sistemi.

Questo è un principio fondamentale dell'interoperabilità: collegare prima di sostituire.

Vocabolari condivisi

Lo stesso vale per le categorie:

Museo.

• Monumento.
• Area archeologica.
• Teatro.
• Biblioteca.
• Parco.
• Struttura ricettiva.
• Evento.
• Fermata.
• Servizio.

Utilizzare vocabolari documentati permette ai sistemi di comprendere meglio il significato delle informazioni. Quando possibile, dovrebbero essere utilizzate classificazioni già esistenti a livello nazionale, europeo o internazionale.

Le categorie locali dovrebbero essere introdotte soltanto quando realmente necessarie e comunque documentate.

Una città non deve reinventare il linguaggio dei dati

Ogni volta che inventiamo localmente:

• un formato;
• una classificazione;
• un vocabolario;
• un protocollo;

aumentiamo il lavoro necessario per comunicare con il resto del mondo.

L'innovazione non consiste nel creare uno standard diverso da tutti gli altri. Spesso consiste nel utilizzare bene ciò che esiste già.

Questo vale particolarmente per il turismo, che per sua natura attraversa territori, istituzioni e sistemi differenti.

Salerno non è un'isola informativa

Un visitatore che arriva a Salerno può provenire da qualsiasi parte del mondo. Può arrivare attraverso:

• aeroporto;
• ferrovia;
• porto;
• autostrada;
• trasporto regionale.

Può soggiornare in città e visitare:

• Costiera Amalfitana;
• Paestum;
• Cilento;
• altri territori.

Oppure può pernottare altrove e trascorrere una giornata a Salerno. La conoscenza turistica non coincide quindi con i confini amministrativi ed i sistemi informativi devono essere capaci di collegarsi anche oltre il territorio comunale.

La destinazione reale può superare il confine amministrativo

Questo introduce una distinzione importante:

• Il Comune è un confine amministrativo.
• L'esperienza del visitatore non necessariamente lo è.

Una persona può dormire a Salerno, visitare Paestum durante il giorno e tornare la sera, un'altra può arrivare a Salerno e proseguire verso la Costiera, un'altra ancora può utilizzare la città come punto di accesso a un territorio più ampio.

Per conoscere questi comportamenti abbiamo bisogno di dati e sistemi capaci di attraversare differenti scale territoriali.

Interoperabilità verticale

Possiamo chiamare verticale la capacità di collegare livelli istituzionali differenti:

• Comune.
• Provincia o area vasta, dove pertinente.
• Regione.
• Stato.
• Unione Europea.

Un dato prodotto localmente può diventare utile a un sistema regionale  -->  Un dato regionale può alimentare un servizio comunale  -->  Un sistema nazionale può fornire standard utilizzabili localmente.

L'informazione deve poter viaggiare tra livelli differenti.

Interoperabilità orizzontale

Esiste poi un'interoperabilità orizzontale:

• Turismo.
• Cultura.
• Mobilità.
• Ambiente.
• Commercio.
• Urbanistica.
• Accessibilità.
• Lavoro.
• Eventi.

sono ambiti amministrativi differenti ma descrivono parti della stessa esperienza urbana.

Se i sistemi non comunicano, anche la conoscenza rimane divisa secondo l'organizzazione degli uffici.

La città reale, invece, non funziona per assessorati.

Il turista attraversa i settori

• Un visitatore arriva in stazione.
• Utilizza un autobus.
• Visita un museo.
• Mangia in un ristorante.
• Partecipa a un evento.
• Passeggia sul lungomare.
• Rientra in albergo.

Per l'amministrazione queste attività possono appartenere a sistemi differenti invece per la persona costituiscono un'unica esperienza. L'interoperabilità permette di avvicinare l'organizzazione dell'informazione alla realtà dell'esperienza.

L'interoperabilità riduce il lavoro manuale

Senza interoperabilità, una parte enorme del lavoro consiste nel trasferire informazioni.

• Scaricare.
• Copiare.
• Incollare.
• Convertire.
• Correggere.
• Reinserire.
• Ripetere.

ogni passaggio manuale richiede tempo e introduce possibilità di errore.

Se i sistemi comunicano automaticamente, le persone possono dedicare più tempo a:

• verificare;
• analizzare;
• interpretare;
• progettare servizi.

L'automazione dovrebbe eliminare il lavoro ripetitivo, non la responsabilità umana.

Aggiornare alla fonte

Il principio fondamentale rimane: aggiornare alla fonte, riutilizzare ovunque.

Supponiamo che l'orario di un museo cambi. Nel modello frammentato:

• il museo aggiorna il proprio sito;
• qualcuno aggiorna il portale culturale;
• qualcuno il portale turistico;
• qualcuno GiraSalerno;
• qualcuno un'app.

Nel modello interoperabile:

fonte → aggiornamento → sistemi collegati.

È più semplice, economico, affidabile.

Ma cosa succede se la fonte sbaglia?

L'interoperabilità non elimina gli errori anzi può perfino propagarli più velocemente. Per questo occorre associare allo scambio dei dati anche un sistema di:

• segnalazione;
• verifica;
• correzione;
• tracciabilità.

Se un utilizzatore individua un errore deve poterlo comunicare alla fonte.

L'ecosistema deve essere bidirezionale fonte → utilizzatore ma anche utilizzatore → segnalazione → fonte.

La provenienza deve viaggiare insieme al dato

Quando un sistema riceve un'informazione dovrebbe sapere anche:

• da dove arriva;
• quando è stata aggiornata;
• quale licenza possiede;
• eventualmente quale livello di affidabilità ha.

Se separiamo il dato dalla provenienza perdiamo una parte essenziale della conoscenza. La fonte dovrebbe quindi accompagnare il dato lungo tutta la catena del riuso.

API: una lingua di servizio

Le API possono essere uno degli strumenti principali dell'interoperabilità. Immaginiamo che un sistema pubblico esponga un servizio capace di rispondere a richieste come:

• dammi i luoghi culturali di Salerno;
• dammi gli eventi tra due date;
• dammi le informazioni relative a questo luogo.

Un'applicazione esterna può utilizzare le risposte automaticamente e non ha bisogno di conoscere il database interno. Deve conoscere soltanto le regole dell'API.

L'API deve essere documentata

Un'API senza documentazione può essere tecnicamente aperta e praticamente inutilizzabile. Occorre spiegare:

• quali richieste sono possibili;
• quali parametri utilizzare;
• quali dati vengono restituiti;
• quali codici vengono utilizzati;
• quali limiti esistono;
• come vengono gestiti gli errori;
• quanto spesso cambiano le specifiche.

Ancora una volta la documentazione diventa parte dell'infrastruttura.

Le API devono essere stabili

Se un servizio cambia continuamente struttura senza avvisare gli utilizzatori, tutte le applicazioni collegate possono smettere di funzionare. Occorre quindi pensare anche alla stabilità.

• Versioni.
• Compatibilità.
• Periodi di transizione.
• Comunicazione delle modifiche.

l'interoperabilità richiede un patto minimo tra chi produce e chi utilizza il servizio.

Non sempre serve un collegamento in tempo reale

Anche qui dobbiamo evitare il tecnicismo fine a se stesso.

• Per gli orari dei trasporti potrebbe essere importante un aggiornamento molto frequente.
• Per un elenco di beni culturali può essere sufficiente un aggiornamento periodico.
• Per una serie statistica annuale non serve una sincronizzazione ogni minuto.

l'interoperabilità deve essere proporzionata alla natura del dato.

Il tempo reale non è automaticamente migliore

• Un dato aggiornato ogni secondo può essere inutile se è poco affidabile.
• Un dataset annuale può essere preziosissimo se è completo, documentato e confrontabile per vent'anni.

La qualità non si misura soltanto attraverso la velocità. Dipende dalla domanda alla quale vogliamo rispondere.

Eventi: interoperabilità invece di copia

Gli eventi costituiscono ancora una volta un esempio particolarmente chiaro. Immaginiamo che ogni organizzatore possa produrre un evento attraverso una struttura condivisa:

• titolo;
• data;
• orario;
• luogo;
• categoria;
• accessibilità;
• costo;
• fonte;
• link.

Il Comune potrebbe mostrarlo, GiraSalerno potrebbe mostrarlo, una newsletter potrebbe utilizzarlo, un'applicazione potrebbe inserirlo in una mappa, un albergo potrebbe visualizzare gli eventi vicini.

L'evento viene descritto una sola volta ma molti sistemi lo utilizzano.

Mobilità: il dato deve attraversare i servizi

La mobilità mostra un livello ancora più avanzato. Un servizio turistico non dovrebbe essere costretto a mantenere manualmente:

• fermate;
• percorsi;
• orari;
• variazioni.

Dovrebbe, quando possibile, utilizzare dati prodotti dai soggetti competenti. Il sistema turistico diventa quindi utilizzatore dell'infrastruttura informativa della mobilità e la mobilità può utilizzare dati sugli eventi per prevedere o gestire meglio determinati flussi.

Lo scambio può diventare reciproco.

Cultura e turismo non devono duplicarsi

Lo stesso vale per cultura e turismo. Un luogo culturale non dovrebbe avere necessariamente:

• una scheda culturale;
• una scheda turistica;
• una scheda eventi;
• una scheda cartografica
• completamente indipendenti.

Possiamo avere un'unica entità di base e differenti rappresentazioni.

Il settore culturale mantiene le informazioni di propria competenza e il sistema turistico le riutilizza nel proprio contesto.

Accessibilità come dato trasversale

L'accessibilità è forse uno degli esempi migliori di interoperabilità orizzontale e non appartiene esclusivamente al turismo. Riguarda:

• mobilità;
• spazio pubblico;
• edifici;
• cultura;
• eventi;
• servizi.

Una persona ha bisogno di conoscere l'intera catena dell'esperienza.

Un museo perfettamente accessibile serve poco se il percorso per raggiungerlo presenta barriere insuperabili.

Collegare i dati permette di passare dall'accessibilità del singolo luogo all'accessibilità del percorso.

Interoperabilità e partecipazione

Anche il sistema di ascolto costruito nella Parte II deve poter dialogare con l'infrastruttura dei dati.

• Una segnalazione relativa a un luogo dovrebbe poter essere associata all'identificatore di quel luogo.
• Una segnalazione sulla mobilità a una fermata o a un percorso.
• Una segnalazione su un evento all'evento corrispondente.

In questo modo la partecipazione non produce un archivio separato di commenti ma informazioni collegabili alla conoscenza della città.

Interoperabilità e Open Data

Open Data e interoperabilità sono concetti vicini ma non identici. Un dato può essere aperto senza essere facilmente interoperabile. Possiamo scaricarlo, ma dobbiamo lavorare molto per collegarlo ad altri dati.

Un dato interoperabile è invece progettato affinché possa essere compreso e utilizzato all'interno di un ecosistema più ampio. L'obiettivo dovrebbe quindi essere: aperto + documentato + collegabile.

Interoperabilità e autonomia

Potrebbe sembrare che adottare standard comuni riduca l'autonomia ma spesso accade il contrario.

• Se un'organizzazione utilizza un formato proprietario comprensibile soltanto da un particolare software, dipende da quel software.
• Se utilizza standard aperti, può cambiare strumento mantenendo la capacità di comunicare.

Gli standard condivisi possono quindi aumentare l'autonomia dei singoli soggetti.

Nessun monopolio tecnologico

Un ecosistema interoperabile non richiede che tutti utilizzino lo stesso fornitore:

• Un soggetto può usare Drupal.
• Un altro un diverso CMS.
• Un altro un'applicazione specialistica.
• Un altro un database dedicato.

Se rispettano interfacce e standard comuni, possono continuare a dialogare. Questo riduce il rischio che la conoscenza della città venga legata a una singola piattaforma.

Interoperabilità contro il lock-in

Il termine vendor lock-in indica una situazione nella quale cambiare fornitore diventa estremamente difficile perché dati, procedure o servizi dipendono fortemente da una tecnologia proprietaria. L'interoperabilità aiuta a ridurre questo rischio. Se possiamo:

• esportare i dati;
• documentarne la struttura;
• utilizzare API standard;
• migrare verso altri strumenti;

la città mantiene maggiore controllo sul proprio patrimonio informativo.

L'appalto non dovrebbe acquistare una prigione

Quando un ente acquista un sistema digitale, non dovrebbe valutare soltanto:

• funzioni;
• prezzo;
• interfaccia.

Dovrebbe chiedersi anche:

• possiamo esportare tutti i nostri dati?
• in quale formato?
• esistono API?
• sono documentate?
• possiamo migrare?
• possiamo collegare altri sistemi?
• chi controlla il modello dei dati?

Un software può essere molto efficiente oggi e diventare un problema domani se impedisce alla conoscenza di uscire dal proprio contenitore.

Interoperabilità by design

Come per gli Open Data, anche l'interoperabilità dovrebbe essere pensata fin dall'inizio e non costruire un sistema chiuso e chiedersi successivamente “come possiamo collegarlo agli altri?” Bisogna progettare subito:

• identificatori;
• formati;
• API;
• vocabolari;
• metadati;
• procedure di scambio.

Possiamo chiamare questo principio: interoperabilità by design.

Il modello di Salerno Turismo Aperto

Possiamo ora rappresentare in modo più preciso l'architettura concettuale proposta:

fonte

↓

dato originale

↓

normalizzazione

↓

dato strutturato

↓

metadati e provenienza

↓

standard e identificatori

↓

Open Data / API

↓

servizi

Da questo punto possono nascere:

• portali;
• mappe;
• applicazioni;
• analisi;
• dashboard;
• ricerche;
• itinerari;
• servizi civici;
• strumenti di partecipazione.

Normalizzare non significa alterare

Nel passaggio abbiamo introdotto la parola normalizzazione. È importante chiarirla.

Una fonte può indicare una data in un formato, un'altra in un formato differente. Normalizzare significa trasformarle in una rappresentazione comune mantenendo il significato originale.

La fonte non viene cancellata, il dato originale può essere conservato, il sistema produce una forma coerente che facilita il collegamento.

Conservare originale e normalizzato

Quando possibile può essere utile distinguere dato originale e dato normalizzato perchè permette di verificare la trasformazione.

Se scopriamo un errore nella procedura, possiamo tornare alla fonte. La tracciabilità deve accompagnare l'intero processo.

GiraSalerno come nodo, non come centro

Questa architettura permette anche di definire meglio il ruolo di GiraSalerno.

GiraSalerno non dovrebbe diventare il database centrale al quale tutti devono adeguarsi.

Dovrebbe essere uno dei nodi dell'ecosistema.

• Capace di prendere dati da fonti differenti.
• Normalizzarli quando necessario.
• Collegarli.
• Utilizzarli.
• Rendere disponibili i dati prodotti direttamente dal progetto.
• Permettere ad altri di riutilizzarli.

Il successo di GiraSalerno può essere misurato anche da ciò che non copia

Questa è una conseguenza interessante. Potremmo essere tentati di misurare il successo del dimostratore contando:

• pagine;
• schede;
• contenuti.

Ma un indicatore più significativo potrebbe essere: quanta informazione riesce a utilizzare senza doverla ricopiare manualmente? Più il sistema riutilizza fonti interoperabili, più dimostra concretamente la validità del modello.

Un ecosistema, non un portale

A questo punto emerge chiaramente la differenza tra due modelli.

Modello portale

• Un soggetto raccoglie informazioni.
• Le copia.
• Le pubblica.
• Le mantiene.
• Gli altri consultano.

Modello ecosistema

• Molti soggetti producono dati.
• Le fonti rimangono riconoscibili.
• Gli standard permettono lo scambio.
• Molti soggetti costruiscono servizi.
• Le correzioni possono tornare alle fonti.

Il secondo modello è più complesso da progettare ma può essere molto più sostenibile nel tempo.

Una città capace di parlare digitalmente con se stessa

L'interoperabilità può sembrare una questione informatica mentre in realtà descrive qualcosa di molto più importante. Una città nella quale:

• cultura non conosce mobilità;
• turismo non conosce ambiente;
• eventi non comunicano con trasporti;
• servizi non comunicano con territorio;

produce inevitabilmente una conoscenza frammentata.

L'interoperabilità digitale può diventare uno strumento per superare almeno una parte di queste separazioni. Potremmo definirla come la capacità della città di parlare digitalmente con se stessa.

E di parlare con l'esterno

Ma Salerno non deve dialogare soltanto al proprio interno. Deve poter dialogare con:

• sistemi regionali;
• piattaforme nazionali;
• altri territori;
• servizi europei;
• ricerca;
• imprese;
• sviluppatori.

Più utilizziamo standard aperti, più diminuisce il costo necessario per costruire questi collegamenti.

Il problema della durata

Un'infrastruttura turistica deve poter durare molti anni. In questo periodo cambieranno:

• software;
• fornitori;
• amministrazioni;
• tecnologie;
• interfacce.

Per questo dobbiamo costruire qualcosa che possa sopravvivere a questi cambiamenti.

• I dati.
• Gli standard.
• La documentazione.
• I modelli.

sono spesso più duraturi delle applicazioni che li utilizzano.

Prima l'architettura, poi la piattaforma

Possiamo quindi ribadire un principio già incontrato: prima definiamo come deve circolare la conoscenza; poi scegliamo gli strumenti che devono farla circolare.

Invertire l'ordine significa rischiare di adattare l'intero progetto ai limiti del software acquistato.

La tecnologia deve poter essere sostituita

Un buon sistema non è quello che non cambieremo mai ma quello che possiamo cambiare senza perdere ciò che abbiamo costruito. Se domani sostituiamo:

• CMS;
• database;
• strumenti di visualizzazione;
• applicazioni;

il patrimonio informativo dovrebbe poter continuare a esistere. È una delle caratteristiche fondamentali dell'autonomia digitale.

Il passo successivo

A questo punto emerge una nuova domanda. Abbiamo parlato di:

• standard aperti;
• formati documentati;
• autonomia;
• portabilità;
• riduzione della dipendenza dai fornitori;
• controllo della tecnologia.

Ma quale modello tecnologico è maggiormente coerente con questi principi?

Come possiamo costruire infrastrutture pubbliche che siano verificabili, modificabili, riutilizzabili e non dipendano completamente da un singolo soggetto?

È qui che entra in gioco uno dei principi fondamentali di Salerno Turismo Aperto il Software Libero.

Non come scelta ideologica separata dal progetto ma come componente di una strategia più ampia di autonomia digitale.

È il tema del prossimo capitolo.