Una Banca Dati Turistica Aperta

Non un archivio, ma un'infrastruttura

Nel capitolo precedente abbiamo distinto tra dato, informazione e conoscenza ed abbiamo visto che raccogliere molti dati non basta. Occorre descriverli, collegarli, conservarne la provenienza, comprenderne il significato e renderli utilizzabili nel tempo.

A questo punto possiamo dare una prima forma concreta a questa esigenza. La chiameremo: Banca Dati Turistica Aperta di Salerno

Il nome può far pensare immediatamente a un grande database centrale nel quale copiare tutto ciò che esiste ma non è questo il modello che proponiamo. La Banca Dati Turistica Aperta deve essere soprattutto un'infrastruttura di conoscenza, capace di collegare fonti differenti e di rendere accessibili, documentati e riutilizzabili i dati necessari alla comprensione del turismo.

Perché serve una banca dati

Oggi molte informazioni utili esistono già:

• Alcune sono pubblicate dal Comune.
• Altre dalla Regione.
• Altre da ISTAT.
• Altre dalla Camera di Commercio.
• Altre da soggetti culturali.
• Altre dai gestori della mobilità.
• Altre ancora derivano da studi, indagini o sistemi amministrativi.

Il problema non è quindi soltanto produrre nuovi dati ma sapere:

quali dati esistono;
dove si trovano;
chi li produce;
quanto sono aggiornati;
in quale formato sono disponibili;
come possono essere collegati;
come possono essere riutilizzati.

La Banca Dati nasce per rispondere a queste domande.

Prima regola: non duplicare ciò che esiste

Se la Regione pubblica un dataset ufficiale sulle strutture ricettive, non ha senso costruirne una copia indipendente e aggiornarla manualmente. Se il gestore del trasporto pubblico pubblica le proprie fermate, la nostra infrastruttura non dovrebbe diventare la nuova fonte ufficiale delle fermate. Se un museo mantiene i propri orari, dovrebbe rimanere responsabile di quell'informazione.

Il principio deve essere: la fonte autorevole mantiene il dato; il sistema lo collega e lo riutilizza.

Questo riduce duplicazioni, errori e costi di manutenzione.

Un modello federato

Possiamo quindi immaginare la Banca Dati come una rete.

• Alcuni dati possono essere conservati direttamente.
• Altri possono essere collegati attraverso API.
• Altri scaricati periodicamente da dataset pubblici.
• Altri ancora semplicemente catalogati indicando dove si trovano.

Il sistema non deve necessariamente possedere tutto ma deve sapere come raggiungere ciò che serve.

È un modello federato: le fonti rimangono distribuite e la conoscenza diventa collegata.

Tre livelli differenti

Per capire meglio il modello possiamo distinguere tre livelli.

1. Catalogo

Descrive quali dati esistono:

• Fonte.
• Responsabile.
• Formato.
• Licenza.
• Periodo.
• Territorio.
• Frequenza di aggiornamento.

2. Dati

Contiene o collega i dataset veri e propri.

3. Servizi

Utilizza quei dati per costruire mappe, analisi, dashboard, itinerari, applicazioni e strumenti di partecipazione.

Questi livelli non devono essere confusi. Un buon sistema può iniziare anche soltanto dal catalogo perchè sapere quali dati esistono è già un enorme passo avanti.

Il catalogo come punto di partenza

Immaginiamo una scheda per ogni dataset.

Potrebbe contenere:

Titolo: Strutture ricettive del Comune di Salerno
Fonte: Regione Campania
Origine: sistema TurismoWeb
Territorio: Comune di Salerno
Formato: CSV, JSON
Licenza: indicata dalla fonte
Aggiornamento: periodico
Campi: denominazione, tipologia, indirizzo, posti letto, accessibilità e altri
Accesso: link al dataset/API
Ultima verifica: data
Note: eventuali limiti o caratteristiche

Una scheda del genere consente a chiunque di capire rapidamente cosa esiste e come utilizzarlo. È una forma di conoscenza ancora prima di scaricare il dato.

Sapere anche cosa manca

Il catalogo dovrebbe contenere anche un'altra informazione: esiste o non esiste il dato che stiamo cercando?

Supponiamo di voler conoscere:

• numero di visitatori giornalieri;
• percorsi realmente effettuati;
• impatto del turismo sull'abitare;
• accessibilità effettiva dei luoghi.

Se non troviamo dataset affidabili, la lacuna deve essere registrata.

La Banca Dati deve quindi documentare non soltanto ciò che possediamo ma anche ciò che non possediamo ancora.

Questo permette di trasformare le lacune in priorità di ricerca.

Il dataset non è una pagina web

Un errore molto comune consiste nel confondere informazione pubblicata e dato riutilizzabile. Una pagina web può dire: “Il museo è aperto dalle 9 alle 18.” Un essere umano la comprende immediatamente ma un software molto meno.

Se vogliamo che quella stessa informazione possa alimentare:

• una mappa;
• un'app;
• un itinerario;
• un assistente digitale;
• un sistema di accessibilità;
• un portale;

dobbiamo rappresentarla in maniera strutturata.

Ad esempio:

luogo: Museo X
giorno: martedì
apertura: 09:00
chiusura: 18:00

La Banca Dati deve quindi favorire il passaggio da informazioni scritte per essere lette a dati organizzati per poter essere riutilizzati.

Ogni luogo come entità

Possiamo introdurre un concetto fondamentale. Un museo, una chiesa, un albergo, una fermata, una piazza o un parcheggio non dovrebbero essere semplicemente testi presenti in pagine differenti ma dovrebbero diventare entità riconoscibili.

Un luogo potrebbe avere:

• un identificatore;
• un nome;
• coordinate geografiche;
• indirizzo;
• categoria;
• descrizione;
• informazioni di accessibilità;
• fonti;
• relazioni con altri luoghi.

In questo modo differenti sistemi possono capire che stanno parlando dello stesso oggetto.

L'identificatore stabile

Immaginiamo che un luogo sia chiamato in modi leggermente diversi:

• Castello di Arechi
• Castello Arechi
• Arechi Castle

Per una persona è evidente che si tratta dello stesso luogo ma per un sistema informatico potrebbe non esserlo.

Per diventarlo questo serve un identificatore stabile. Ad esempio: luogo_000145

• Il nome può cambiare.
• La traduzione può cambiare.
• La descrizione può essere aggiornata.
• L'identità del luogo rimane.

Gli identificatori sono una delle fondamenta dell'interoperabilità.

Le relazioni sono parte dei dati

Una Banca Dati non deve contenere soltanto oggetti isolati ma deve rappresentare relazioni.

Un museo:

• si trova in un quartiere;
• è raggiungibile tramite determinate fermate;
• ospita eventi;
• fa parte di un itinerario;
• è vicino a altri luoghi;
• possiede caratteristiche di accessibilità.

Un evento:

• si svolge in un luogo;
• inizia a una certa ora;
• termina a un'altra;
• appartiene a una categoria;
• è organizzato da un soggetto.

La conoscenza nasce anche da queste relazioni.

Eventi: uno dei casi più evidenti

Gli eventi mostrano molto bene il problema della frammentazione.

Lo stesso evento può apparire:

• sul sito del Comune;
• sui social dell'organizzatore;
• su una locandina;
• su un portale culturale;
• su un sito turistico;
• su una piattaforma di prenotazione.

Ogni soggetto riscrive:

• titolo;
• data;
• luogo;
• orario;
• descrizione.

Poi l'orario cambia. Una copia viene aggiornata ma non le altre e questo genera confusione. Un modello basato su dati strutturati permetterebbe invece di aggiornare l'informazione alla fonte e riutilizzarla nei diversi servizi.

La provenienza non deve sparire

Supponiamo che la Banca Dati mostri l'orario di un museo.

• Chi lo ha fornito?
• Il museo?
• Il Comune?
• Un operatore?
• Una segnalazione?

La risposta deve essere visibile.

Ogni informazione dovrebbe poter conservare almeno:

fonte;
data di aggiornamento;
data di verifica;
eventuale licenza;
stato di affidabilità.

La trasparenza della provenienza è parte della qualità del dato.

Dato ufficiale, dato verificato, dato segnalato

Non tutte le informazioni devono essere presentate come equivalenti.

Potremmo distinguere, ad esempio:

• dato ufficiale prodotto dalla fonte competente;
• dato verificato controllato attraverso fonti affidabili;
• dato derivato calcolato partendo da altri dati;
• dato partecipativo prodotto attraverso questionari o processi di partecipazione;
• dato segnalato in attesa di verifica.

Queste categorie rendono il sistema più trasparente.

La data conta quanto il valore

Un dato può essere corretto e contemporaneamente non essere più attuale. Per questo dobbiamo distinguere almeno tre date:

• data del fenomeno quando ciò che misuriamo è avvenuto;
• data di aggiornamento quando il dataset è stato aggiornato;
• data di pubblicazione quando è stato reso disponibile.

Supponiamo di leggere nel 2028 un dato relativo al 2025 pubblicato nel 2026. Se vediamo soltanto la data di pubblicazione rischiamo di interpretarlo erroneamente come un'informazione recente. Il tempo deve essere parte esplicita della conoscenza.

La geografia deve essere precisa

La stessa attenzione vale per il territorio. Un dato può riferirsi a:

• Comune di Salerno;
• Provincia di Salerno;
• area della Costiera;
• sistema provinciale;
• Regione Campania;
• singolo quartiere;
• specifica zona urbana.

Un numero provinciale non può essere automaticamente utilizzato per descrivere la città. La Banca Dati deve rendere esplicita la scala geografica.

Conservare le serie storiche

Una delle funzioni più importanti della Banca Dati dovrebbe essere la conservazione della memoria. Se ogni aggiornamento cancella il precedente, perdiamo la possibilità di osservare il cambiamento. Pensiamo al numero delle strutture ricettive.

Se conserviamo soltanto il valore attuale sappiamo quanti operatori esistono oggi. Se conserviamo una serie storica possiamo osservare:

• crescita;
• riduzione;
• trasformazioni;
• distribuzione territoriale;
• cambiamento delle tipologie.

La serie storica trasforma una fotografia in evoluzione.

Non tutto deve essere pubblico

La parola “aperta” non significa che qualsiasi informazione debba essere pubblicata. Esistono limiti necessari:

• Privacy.
• Segreto statistico.
• Informazioni commercialmente sensibili.
• Sicurezza.
• Dati personali.

La Banca Dati deve distinguere almeno tra:

dati pubblici;
dati aggregati;
dati ad accesso limitato;
dati non pubblicabili.

L'apertura deve essere compatibile con i diritti delle persone.

Aperta significa anche documentata

Un dataset disponibile online ma incomprensibile non è realmente facile da riutilizzare. Occorre documentare:

• significato dei campi;
• unità di misura;
• codici utilizzati;
• valori ammessi;
• origine;
• frequenza di aggiornamento;
• eventuali limiti.

Se un campo contiene:

1, 2, 3, 4

dobbiamo sapere cosa significano quei numeri.

La documentazione è parte integrante del dato.

Aperta significa anche accessibile tecnicamente

Idealmente un dato dovrebbe poter essere ottenuto attraverso formati standard:

• CSV.
• JSON.
• GeoJSON.
• API.
• Altri formati aperti e documentati.

Questo non significa imporre immediatamente la soluzione tecnicamente più avanzata a ogni soggetto. Possiamo procedere gradualmente. Una scala possibile è: PDF → tabella scaricabile → CSV documentato → dataset aggiornato → API.

Ogni passaggio aumenta la possibilità di riuso.

Il PDF continua ad avere valore

Questo non significa che il PDF debba scomparire. Un rapporto PDF può essere eccellente per leggere:

• analisi;
• commenti;
• grafici;
• conclusioni.

Il problema nasce quando il PDF diventa l'unico modo di accedere ai dati.

Il modello migliore può essere: rapporto per le persone + dataset per le macchine.

Entrambi utili ma con funzioni differenti.

Licenze chiare

Un altro elemento essenziale è sapere se il dato può essere riutilizzato. Un dataset pubblicato senza indicazioni chiare sulla licenza crea incertezza.

• Posso ripubblicarlo?
• Posso modificarlo?
• Posso costruire un servizio commerciale?
• Devo citare la fonte?

Una Banca Dati Aperta deve quindi registrare anche le condizioni di riuso. L'apertura giuridica è importante quanto quella tecnica.

La qualità come attributo del dato

Ogni dataset può avere problemi.

• Campi mancanti.
• Aggiornamenti irregolari.
• Valori incoerenti.
• Duplicati.
• Geolocalizzazioni errate.

La Banca Dati non deve nasconderli. Può invece rendere visibile un livello di qualità.

Ad esempio:

completezza;
aggiornamento;
copertura territoriale;
affidabilità della fonte.

In questo modo chi utilizza il dato conosce anche i suoi limiti.

Correggere attraverso la partecipazione

Qui il modello può incontrare il sistema di ascolto costruito nella Parte II. Supponiamo che un cittadino segnali: “Questo ingresso non è accessibile.” Oppure: “L'orario indicato è sbagliato.”

La segnalazione viene registrata, non modifica immediatamente il dato ed entra in uno stato: da verificare.

Dopo la verifica può essere:

• confermata;
• respinta;
• trasmessa alla fonte;
• utilizzata per aggiornare l'informazione.

La partecipazione può quindi diventare anche meccanismo di miglioramento della qualità dei dati.

Correggere alla fonte

Il principio resta però fondamentale. Se l'orario ufficiale di un museo è errato, non dovremmo limitarci a correggerlo nella nostra banca dati ma dovremmo segnalare l'errore al soggetto che ne è responsabile.

Il percorso ideale è: segnalazione → verifica → fonte → correzione → aggiornamento automatico dei servizi.

In questo modo l'intero ecosistema migliora.

Chi può utilizzare la Banca Dati?

Una vera Banca Dati Turistica Aperta non dovrebbe essere progettata soltanto per l'amministrazione. Può servire a:

• cittadini, per conoscere;
• turisti, attraverso servizi e applicazioni;
• operatori, per costruire prodotti;
• imprese, per analizzare opportunità;
• giornalisti, per verificare fenomeni;
• ricercatori, per studiare;
• associazioni, per partecipare;
• sviluppatori, per creare servizi;
• istituzioni, per programmare.

Quanto più il dato viene riutilizzato, tanto maggiore diventa il valore dell'investimento pubblico necessario per produrlo.

Un esempio: l'accessibilità

Immaginiamo di voler costruire un servizio dedicato all'accessibilità. Potremmo avere dati su:

• presenza di gradini;
• ascensori;
• rampe;
• servizi igienici accessibili;
• percorsi;
• parcheggi;
• fermate;
• ingressi;
• orari.

Se queste informazioni sono strutturate, lo stesso patrimonio può alimentare:

• una pagina web;
• una mappa;
• un'applicazione;
• un itinerario personalizzato;
• un dataset Open Data;
• un servizio esterno.

Un'unica raccolta informativa genera molti utilizzi.

Un esempio: gli eventi

Lo stesso modello può valere per gli eventi. Un record strutturato potrebbe contenere:

• titolo;
• descrizione;
• data;
• ora;
• luogo;
• organizzatore;
• categoria;
• costo;
• accessibilità;
• link;
• coordinate;
• fonte;
• ultimo aggiornamento.

Quel record può alimentare:

• calendario;
• mappa;
• newsletter;
• portale turistico;
• app;
• schermi informativi;
• servizi esterni.

Non serve riscrivere l'evento ogni volta.

Un esempio: le strutture ricettive

Per le strutture ricettive possiamo riutilizzare ciò che già viene prodotto dai sistemi regionali. La Banca Dati può collegare:

• denominazione;
• tipologia;
• localizzazione;
• capacità;
• classificazione;
• informazioni di accessibilità;
• codici identificativi;
• altri dati pubblicabili.

Poi questi dati possono essere arricchiti, quando possibile, con altri dataset:

• quartiere;
• trasporto pubblico;
• distanza dai servizi;
• distribuzione territoriale.

La conoscenza cresce attraverso relazioni, non duplicazioni.

Dati pubblici e dati prodotti dal Piano

Non tutte le informazioni arriveranno dall'esterno. Il sistema di ascolto potrà produrre nuovi dati.

• Questionari ai visitatori.
• Panel dei residenti.
• Indagini sugli operatori.
• Rilevazioni sulle competenze.
• Analisi territoriali.

questi dataset potranno entrare nella Banca Dati in forma aggregata e anonimizzata. In questo modo la partecipazione non produce soltanto rapporti ma nuovo patrimonio conoscitivo pubblico.

Anche gli indicatori sono dati

Quando in seguito costruiremo gli indicatori del Piano, essi non dovranno vivere in un documento separato ma dovranno collegarsi ai dataset dai quali derivano. Ad esempio permanenza media deve indicare:

• formula;
• fonte;
• periodo;
• territorio;
• serie storica.

Così ogni indicatore diventa verificabile.

Una Banca Dati che cresce nel tempo

Non dobbiamo pensare di costruire tutto immediatamente. Possiamo iniziare da pochi domini prioritari. Ad esempio:

• ricettività;
• luoghi culturali;
• eventi;
• mobilità;
• accessibilità.

Poi aggiungere progressivamente:

• economia;
• residenti;
• lavoro;
• ambiente;
• flussi;
• questionari;
• indicatori.

La crescita deve essere graduale ma coerente.

Meglio una piccola infrastruttura ben documentata che un enorme archivio impossibile da mantenere.

Un catalogo pubblico delle priorità

Anche lo sviluppo della Banca Dati potrebbe essere trasparente. Per ogni dominio potremmo indicare:

disponibile;
parzialmente disponibile;
da integrare;
da verificare;
non disponibile.

Questo permetterebbe di vedere non soltanto ciò che il progetto ha realizzato, ma anche ciò che rimane da fare.

La lacuna diventa parte della programmazione.

Chi mantiene il sistema?

Una banca dati senza manutenzione diventa rapidamente un archivio obsoleto e per questo ogni dataset deve avere almeno:

una fonte;
un responsabile;
una frequenza di aggiornamento;
una procedura di verifica.

Se nessuno sa chi deve aggiornare un dato, prima o poi quel dato smetterà di essere affidabile. La governance della conoscenza è quindi importante quanto la tecnologia.

Una responsabilità distribuita

Anche qui non tutto deve ricadere su un unico soggetto.

• Il museo mantiene i propri dati.
• Il gestore dei trasporti i propri.
• La Regione i propri dataset.
• Il Comune le informazioni di propria competenza.
• La Banca Dati coordina, collega, cataloga e documenta.

È un modello di responsabilità distribuita.

Il ruolo di GiraSalerno

GiraSalerno potrà essere il luogo nel quale questo modello viene sperimentato concretamente. Non dovrà diventare la banca dati definitiva della città ma potrà dimostrare che è possibile:

• riutilizzare dataset esistenti;
• normalizzarli;
• collegarli;
• documentarne la provenienza;
• esporli attraverso servizi;
• permettere correzioni;
• costruire mappe e applicazioni.

Il valore del dimostratore non sarà quindi nel numero di pagine pubblicate ma nella qualità dell'architettura informativa.

Drupal non è la Banca Dati

Poiché GiraSalerno utilizza Drupal, è importante distinguere lo strumento dal modello. Drupal può aiutarci a:

• gestire contenuti strutturati;
• costruire tassonomie;
• creare relazioni;
• pubblicare API;
• gestire utenti e workflow.

Ma la Banca Dati Turistica Aperta non deve essere identificata con Drupal perchè domani potremmo utilizzare strumenti differenti. Se i dati sono basati su standard aperti e modelli documentati, la conoscenza può sopravvivere alla tecnologia.

Software Libero come garanzia di autonomia

Per un'infrastruttura destinata a durare anni, la possibilità di controllare gli strumenti utilizzati è importante.

Il Software Libero permette:

• verifica del codice;
• adattamento;
• migrazione;
• riuso;
• collaborazione;
• riduzione della dipendenza da un singolo fornitore.

Non significa che qualsiasi soluzione libera sia automaticamente migliore ma che l'autonomia tecnologica deve essere considerata un criterio di progettazione.

Standard prima del software

Ancora più importante del singolo programma sono gli standard. Se definiamo:

• formati;
• identificatori;
• API;
• vocabolari;
• metadati;
• modello delle relazioni;

possiamo sostituire più facilmente gli strumenti.

Se invece costruiamo tutto attorno alle caratteristiche proprietarie di una singola piattaforma, la migrazione diventa difficile. Il principio dovrebbe essere: prima il modello dei dati, poi il software che lo implementa.

La Banca Dati come bene comune

Arriviamo così al significato più ampio della proposta: una Banca Dati Turistica Aperta non è semplicemente un progetto informatico ma un bene comune informativo.

Viene costruita attraverso dati prodotti da istituzioni, operatori, ricerca e partecipazione.

Viene documentata. Può essere verificata. Può essere riutilizzata. Cresce nel tempo.

Non appartiene a una singola amministrazione né a una singola piattaforma. Appartiene alla città come patrimonio di conoscenza.

Aprire non basta

Ma proprio qui dobbiamo evitare un'altra semplificazione. Potremmo costruire una banca dati formalmente aperta e continuare a produrre pochissimo valore.

• Dataset difficili da trovare.
• Formati incomprensibili.
• Aggiornamenti irregolari.
• Licenze poco chiare.
• Campi non documentati.
• Dati pubblicati una volta e poi abbandonati.
• Tecnicamente aperti.
• Praticamente inutilizzabili.

Per questo la domanda del prossimo capitolo sarà quando possiamo dire che un dato è davvero aperto? e soprattutto che cosa serve perché venga effettivamente trovato, compreso e riutilizzato?