Il dato disperso

Avere i dati non significa poterli usare. Nei capitoli precedenti abbiamo incontrato una situazione apparentemente contraddittoria.

Da una parte esistono molti dati sul turismo: statistiche, elenchi di strutture ricettive, informazioni fiscali, movimenti portuali, dati sulla mobilità, luoghi culturali, eventi, studi e ricerche. Dall'altra, quando proviamo a rispondere a domande anche relativamente semplici, la ricostruzione diventa difficile.

Il problema non riguarda quindi soltanto quanti dati possediamo ma anche dove sono, come sono pubblicati e quanto riescono a dialogare tra loro.

Un'informazione può essere pubblica e contemporaneamente difficile da trovare. Può essere disponibile e non essere riutilizzabile. Può essere aggiornata ma non conservare la propria storia. Può essere corretta ma impossibile da collegare ad altre informazioni. Può esistere contemporaneamente in più sistemi con valori differenti.

È ciò che possiamo definire dato disperso.

Una città, molti contenitori

Immaginiamo di voler costruire una fotografia completa di un singolo luogo turistico di Salerno.

Potremmo aver bisogno di conoscere:

• denominazione ufficiale;
• descrizione;
• posizione geografica;
• indirizzo;
• orari;
• modalità di accesso;
• accessibilità;
• contatti;
• fotografie;
• servizi disponibili;
• trasporto pubblico;
• eventi ospitati;
• numero dei visitatori;
• eventuale costo d'ingresso.

Non è affatto scontato che queste informazioni si trovino nello stesso sistema.

• La descrizione può essere sul sito del Comune.
• Gli eventi su un portale dedicato.
• Le coordinate in una banca dati geografica.
• Gli orari su un'altra pagina.
• Le fermate del trasporto pubblico nel sistema del gestore.
• Le informazioni sull'accessibilità in un documento.
• I dati sui visitatori negli archivi del soggetto che gestisce il luogo.

Ognuna di queste informazioni può essere corretta ma per il cittadino, il turista, il ricercatore o un'applicazione digitale il risultato rimane lo stesso: la conoscenza deve essere ricostruita ogni volta.

La frammentazione non riguarda soltanto Salerno

È importante evitare un equivoco. La frammentazione dei dati non è un'anomalia esclusivamente salernitana.

Le amministrazioni pubbliche sono storicamente organizzate per competenze, procedimenti e settori. Ogni ufficio utilizza gli strumenti necessari allo svolgimento delle proprie funzioni. Sistemi informativi costruiti in periodi differenti possono utilizzare tecnologie, classificazioni e strutture differenti. Lo stesso avviene tra enti diversi. Comune, Regione, amministrazioni statali, Camera di Commercio, gestori dei trasporti e soggetti privati non sono nati per alimentare un'unica banca dati turistica.

La frammentazione ha quindi ragioni storiche e organizzative comprensibili. Il problema nasce quando questa situazione viene considerata immutabile.

Le tecnologie attuali permettono infatti di collegare sistemi differenti senza necessariamente sostituirli o concentrare tutto in un unico archivio. La domanda non dovrebbe essere “come costruiamo un gigantesco database che contenga tutto?” ma “come permettiamo a informazioni prodotte in luoghi differenti di essere riconosciute e utilizzate insieme?”

Il PDF: pubblico, leggibile, ma spesso poco riutilizzabile

Uno degli esempi più semplici riguarda i documenti PDF. Il PDF è uno strumento prezioso, permette di conservare l'aspetto di un documento, distribuirlo facilmente, archiviarlo e renderlo consultabile indipendentemente dal programma con il quale è stato prodotto. Il problema nasce quando viene utilizzato come unico modo per pubblicare dati strutturati.

Immaginiamo un elenco di cento strutture ricettive. Se viene pubblicato soltanto in PDF, una persona può leggerlo.

Ma se vogliamo:

• ordinarlo automaticamente;
• filtrarlo per quartiere;
• rappresentarlo su una mappa;
• confrontarlo con l'anno precedente;
• utilizzarlo in un'applicazione;
• collegarlo alle fermate degli autobus;

dobbiamo prima estrarre e ricostruire le informazioni.

Se lo stesso elenco è disponibile anche in un formato strutturato, queste operazioni possono essere automatizzate. La differenza non è quindi tra un formato “buono” e uno “cattivo”. Un'amministrazione può perfettamente pubblicare il PDF destinato alla lettura umana e contemporaneamente il dataset destinato al riuso.

Anche una pagina web può essere un contenitore chiuso

Lo stesso problema può presentarsi con un sito moderno e graficamente efficace. Una pagina può mostrare perfettamente:

Museo — indirizzo — orario — descrizione — fotografia.

Ma se quelle informazioni sono memorizzate come un unico testo, un'altra applicazione non sa necessariamente distinguere l'indirizzo dall'orario o il nome del museo dalla descrizione.

Per una persona la pagina è comprensibile mentre per una macchina molto meno. È qui che entra in gioco il concetto di dato strutturato.

Invece di memorizzare: “Il Museo X si trova in via Y ed è aperto dalle 9 alle 18”,

il sistema conserva separatamente:

nome: Museo X
indirizzo: via Y
apertura: 09:00
chiusura: 18:00

La pagina web potrà poi ricomporre questi elementi e mostrarli esattamente come prima ma gli stessi dati potranno essere utilizzati anche da una mappa, da un'applicazione o da un altro servizio. È un cambiamento apparentemente tecnico che produce conseguenze molto concrete.

Copiare non significa integrare

Quando sistemi differenti non dialogano, la soluzione più frequente è molto semplice: copiare l'informazione.

• Un ufficio pubblica un evento.
• Un altro sito lo ricopia.
• Un portale turistico lo inserisce nuovamente.
• Un'associazione fa lo stesso.
• Una struttura ricettiva lo riporta sul proprio sito.

finché l'informazione non cambia, tutto funziona. 

Poi l'orario viene modificato e la fonte originale viene aggiornata.

• Una copia rimane vecchia.
• Un'altra viene corretta.
• Una terza scompare.

nascono così molte versioni della stessa realtà.

La duplicazione genera un costo nascosto: ogni copia deve essere mantenuta. E più copie esistono, maggiore diventa la probabilità di trovare informazioni contraddittorie. Un sistema realmente integrato dovrebbe tendere al principio: aggiornare alla fonte, riutilizzare ovunque.

Qual è la fonte?

Questo porta a una domanda fondamentale: chi è responsabile di una determinata informazione?

Per l'orario di un museo, probabilmente il soggetto che lo gestisce, per una fermata dell'autobus, il gestore o l'autorità competente, per la classificazione di una struttura ricettiva, l'amministrazione che detiene il dato ufficiale, per un evento, l'organizzatore o il soggetto istituzionale che ne gestisce il calendario. Ogni informazione dovrebbe poter conservare il legame con la propria fonte autorevole. Questo permette di sapere:

• da dove proviene;
• chi può correggerla;
• quando è stata aggiornata;
• quale grado di affidabilità possiede.

Senza provenienza, un dato può essere corretto ma non verificabile. E una conoscenza pubblica dovrebbe essere, per quanto possibile, verificabile.

Il problema delle date

Un'informazione senza data può diventare rapidamente pericolosa.

• Un documento pubblicato online può contenere dati riferiti a cinque anni prima.
• Una pagina può essere ancora raggiungibile dai motori di ricerca pur descrivendo un servizio non più esistente.
• Un dataset può essere stato pubblicato recentemente ma contenere informazioni riferite a un periodo molto precedente.

Per questo occorre distinguere almeno:

data del fenomeno,
data di aggiornamento,
data di pubblicazione.

Non sono la stessa cosa. Un dataset pubblicato nel 2026 può descrivere il 2024. Un dato aggiornato oggi può riferirsi agli arrivi del mese scorso. La qualità della conoscenza dipende anche dalla capacità di rendere visibile questa distinzione.

Perdere il passato aggiornando il presente

Esiste poi il problema opposto. Immaginiamo un elenco di strutture ricettive che venga aggiornato ogni mese sostituendo il file precedente. Conosceremo molto bene la situazione attuale ma dopo cinque anni sarà difficile sapere come siamo arrivati fin qui.

• Quante strutture c'erano?
• Dove erano concentrate?
• Quali tipologie sono cresciute?
• Quali sono diminuite?

L'aggiornamento non dovrebbe quindi cancellare necessariamente la storia. Per molti dati turistici occorre conservare serie temporali e versioni precedenti perché una politica pubblica ha bisogno non soltanto di conoscere lo stato attuale, ma di comprendere il cambiamento.

Lo stesso luogo può avere molti nomi

Un altro problema apparentemente minore riguarda l'identificazione. Un luogo può essere indicato in sistemi differenti con nomi leggermente diversi. Abbreviazioni, denominazioni storiche, traduzioni, errori di scrittura o variazioni nella toponomastica possono far apparire come differenti informazioni che si riferiscono allo stesso oggetto.

Il problema cresce quando migliaia di record devono essere collegati automaticamente per questo una moderna infrastruttura della conoscenza utilizza identificatori stabili.

Un museo non è identificato soltanto dal proprio nome ma possiede un codice che rimane lo stesso anche se cambia denominazione.

Lo stesso principio può essere applicato a luoghi, eventi, strutture, fermate, quartieri e altri elementi. È ciò che permette ai sistemi di riconoscere che stanno parlando della stessa cosa.

Anche le categorie devono parlare la stessa lingua

Supponiamo che un sistema utilizzi la categoria Bed & Breakfast, un altro B&B, un altro Bed and Breakfast e un quarto struttura extralberghiera.

Per una persona la relazione può essere evidente. Per un sistema automatico non necessariamente.

Il problema riguarda classificazioni, categorie, territori, tipologie di eventi, servizi, accessibilità e molte altre informazioni. Per rendere interoperabili i dati servono quindi vocabolari e classificazioni condivise, o almeno regole capaci di tradurre una classificazione nell'altra.

Non significa imporre a tutti lo stesso software. Significa permettere a software differenti di comprendere il significato dei dati che si scambiano.

Comune, provincia, destinazione: anche il territorio può disperdere il dato

La dispersione non è soltanto tecnologica. È anche geografica. Una statistica può riferirsi al Comune di Salerno, un'altra alla provincia, na terza alla DMO e una quarta a un sistema territoriale più ampio.

Se queste scale non vengono dichiarate chiaramente, confrontare i numeri può produrre conclusioni sbagliate. Per questo ogni dato dovrebbe conservare non soltanto cosa misura, ma anche dove lo misura. Il territorio è parte del dato.

Il problema degli archivi invisibili

Esistono poi informazioni che non sono pubblicate sul web ma rimangono nei sistemi interni.

• Fogli di calcolo.
• Database gestionali.
• Registri.
• Archivi amministrativi.
• Report prodotti periodicamente.

Non significa necessariamente che debbano essere resi integralmente pubblici.

Possono contenere dati personali, informazioni riservate o elementi che non hanno alcuna utilità esterna ma una politica della conoscenza dovrebbe almeno sapere quali patrimoni informativi esistono. Non si può decidere cosa aprire, aggregare o utilizzare se prima non si conosce ciò che viene già raccolto.

Il catalogo dei dati deve quindi precedere la pubblicazione dei dati.

Il dato che esiste ma nessuno sa che esiste

C'è una forma di dispersione ancora più paradossale. Un dataset può essere perfettamente pubblico, aggiornato e riutilizzabile ma se nessuno sa che esiste, il suo valore rimane minimo.

• Può trovarsi in una sezione poco conosciuta di un portale.
• Avere un titolo tecnico difficile da cercare.
• Essere descritto attraverso metadati insufficienti.
• Oppure essere noto soltanto agli addetti ai lavori.

Per questo un'infrastruttura della conoscenza ha bisogno anche di un catalogo. Non necessariamente deve contenere fisicamente tutti i dati ma deve almeno permettere di sapere: il dato esiste, si trova qui, è prodotto da questo soggetto, riguarda questo periodo, utilizza questa licenza ed è disponibile in questo formato.

A volte la prima forma di integrazione consiste semplicemente nel rendere trovabile ciò che già esiste.

Il dato aperto che non viene riutilizzato

Abbiamo già visto che la Regione Campania pubblica dataset turistici in formato aperto. Questo ci permette di introdurre una distinzione importante:pubblicare Open Data è necessario, ma non sufficiente. Possiamo avere un portale con centinaia di dataset che vengono scaricati raramente e non alimentano alcun servizio.

In quel caso abbiamo realizzato l'apertura formale del dato, ma non ancora il suo pieno valore sociale.

Il ciclo dovrebbe essere più lungo: produzione → pubblicazione → scoperta → riuso → servizio → nuovo valore.

Il successo di una politica Open Data non dovrebbe quindi essere misurato soltanto contando quanti dataset sono stati pubblicati.

Dovrebbe essere osservato anche attraverso ciò che quei dati hanno permesso di realizzare.

L'interoperabilità non significa costruire un unico sistema

Questo punto è particolarmente importante. Quando parliamo di superare la frammentazione potremmo immaginare un'enorme banca dati centrale nella quale trasferire tutto. Non è necessariamente la soluzione migliore.

I dati possono continuare a essere mantenuti dai soggetti che ne hanno competenza.

• Il museo aggiorna i propri orari.
• Il gestore del trasporto aggiorna le fermate.
• La Regione mantiene l'elenco delle strutture ricettive.
• Il Comune gestisce le proprie informazioni.
• La DMO produce altri dati.

Ciò che serve è la capacità dei sistemi di scambiarsi e comprendere le informazioni. È il principio dell'interoperabilità. In termini semplici: non è necessario che tutti utilizzino lo stesso computer; è necessario che i loro computer sappiano parlare tra loro.

API: una porta tra sistemi

Uno degli strumenti attraverso i quali questo dialogo può avvenire è rappresentato dalle API, le interfacce che permettono a un programma di chiedere informazioni a un altro programma secondo regole definite.

Immaginiamo che la fonte ufficiale di un evento esponga i propri dati attraverso un'API.

• GiraSalerno potrebbe utilizzarli.
• Un'applicazione mobile potrebbe fare lo stesso.
• Una struttura ricettiva potrebbe mostrarli sul proprio sito.
• Una mappa potrebbe rappresentarli.

Quando l'orario dell'evento cambia alla fonte, tutti i servizi potrebbero ricevere l'informazione aggiornata senza doverla ricopiare manualmente. L'API non è quindi una raffinatezza destinata esclusivamente agli informatici.

È uno degli strumenti che permettono di applicare concretamente il principio: aggiornare una volta, utilizzare molte volte.

E quando l'API non esiste?

La realtà, naturalmente, non è ideale e molte fonti non dispongono di API.

• Alcune offrono file scaricabili.
• Altre feed.
• Altre ancora soltanto pagine web o documenti.

Un'infrastruttura realistica deve quindi essere capace di lavorare con livelli differenti di maturità.

L'obiettivo non può essere: “tutto deve essere perfetto prima di cominciare”.

Deve essere piuttosto: migliorare progressivamente la qualità e l'interoperabilità delle fonti.

Anche un semplice CSV aggiornato regolarmente e documentato può rappresentare un enorme miglioramento rispetto a una tabella ricopiata manualmente.

La dispersione produce costi

La frammentazione può sembrare un problema esclusivamente informatico. Non lo è.

Produce costi molto concreti. Ogni volta che la stessa informazione viene inserita manualmente in cinque sistemi differenti, cinque persone o cinque organizzazioni impiegano tempo.

• Ogni volta che cambia, deve essere aggiornata cinque volte.
• Ogni errore deve essere corretto cinque volte.
• Ogni nuovo servizio deve ricostruire da capo la stessa base informativa.

La mancata interoperabilità significa quindi: duplicazione del lavoro, maggiori costi di manutenzione, maggiore probabilità di errore e minore capacità di innovazione.

È anche per questo che l'apertura e la standardizzazione dei dati devono essere considerate una questione di buona amministrazione e non soltanto di tecnologia.

La dispersione produce anche dipendenza

Quando i dati pubblici non sono facilmente utilizzabili, spesso intervengono soggetti privati che li raccolgono, li organizzano e li trasformano in servizi. Questo può produrre innovazione ed è spesso positivo. Il problema nasce quando la comunità finisce per dipendere completamente da piattaforme esterne persino per conoscere fenomeni che riguardano il proprio territorio.

La distinzione è importante: un servizio può essere privato; la conoscenza di base della città non dovrebbe dipendere esclusivamente da un soggetto privato.

Un ecosistema sano permette a imprese e sviluppatori di costruire servizi innovativi proprio perché esiste una base informativa aperta, affidabile e condivisa.

Dalla frammentazione alla rete

Possiamo quindi rappresentare la situazione tradizionale così:

Comune → propri dati
Regione → propri dati
trasporti → propri dati
cultura → propri dati
porto → propri dati
operatori → propri dati
DMO → propri dati

Ognuno possiede un pezzo della realtà.

Il modello che dobbiamo immaginare è diverso: Comune ↔ Regione ↔ cultura ↔ mobilità ↔ porto ↔ operatori ↔ DMO

Non significa che tutti possano vedere tutto ma che ogni informazione diventi pubblica. Significa che le informazioni che possono legittimamente essere condivise dispongano delle condizioni tecniche, giuridiche e organizzative per esserlo.

Cinque condizioni per uscire dalla dispersione

Da quanto abbiamo osservato possiamo ricavare cinque requisiti elementari.

Trovabilità.
Dobbiamo sapere che un dato esiste e dove trovarlo.

Provenienza.
Dobbiamo conoscere la fonte e il soggetto responsabile.

Struttura.
Il dato deve poter essere interpretato senza ricostruirlo ogni volta manualmente.

Interoperabilità.
Deve poter essere collegato, quando possibile, ad altre informazioni.

Continuità.
Deve essere aggiornato e, quando necessario, conservarne la storia.

A queste condizioni ne aggiungeremo successivamente altre: qualità, licenze, privacy, sicurezza, documentazione.

Ma già queste cinque permettono di comprendere quanto sia differente pubblicare informazioni dal costruire conoscenza.

Non serve un altro contenitore

Questo punto ci riporta direttamente alla ragione per cui è nato Salerno Turismo Aperto. Di fronte alla dispersione, la tentazione più semplice sarebbe costruire un altro portale.

• Prendere informazioni dal Comune.
• Copiarne altre dalla Regione.
• Aggiungere eventi.
• Scrivere nuove descrizioni.
• Creare mappe.
• Pubblicare tutto con una grafica moderna.

Avremmo probabilmente un sito migliore ma avremmo anche creato un nuovo contenitore da mantenere. Alla prima modifica di un orario, di un contatto o di una classificazione, ricomincerebbe il problema.

Per questo la questione non è costruire un portale che contenga più informazioni degli altri ma costruire un modello nel quale le informazioni possano circolare.

Ed è anche la ragione per cui GiraSalerno, quando entrerà nel nostro percorso, dovrà essere giudicato non dal numero delle sue pagine ma dalla quantità di informazioni che riesce a utilizzare senza doverle duplicare.

Dal dato disperso al dato condiviso

I primi capitoli di questa Parte ci hanno condotto progressivamente a una conclusione. All'inizio ci siamo chiesti quanto conoscessimo realmente il turismo di Salerno.

Abbiamo scoperto che molti soggetti producono dati.

Abbiamo visto che una quantità significativa di informazioni esiste già.

Abbiamo individuato le domande alle quali ancora non sappiamo rispondere.

Ora emerge un ulteriore problema: anche una città ricca di dati può essere povera di conoscenza se quei dati rimangono separati, difficili da trovare, non confrontabili o non riutilizzabili.

La risposta alla frammentazione non è necessariamente concentrare tutto ma creare relazioni:

• Tra fonti.
• Tra sistemi.
• Tra amministrazioni.
• Tra dati pubblici e conoscenza prodotta dagli operatori.
• Tra presente e passato.
• Tra informazioni e territorio.

perché il dato isolato descrive un frammento. Il dato collegato comincia a raccontare la città.

Ed è proprio questa consapevolezza che ci permette ora di guardare indietro. Salerno non comincia oggi a interrogarsi sul proprio turismo: studi, indagini e persino un Piano strategico esistevano già quasi trent'anni fa.

Capire che cosa avevamo già compreso allora, che cosa è cambiato e che cosa invece è rimasto irrisolto sarà il tema del prossimo capitolo: “Trent'anni di studi sul turismo a Salerno”.