Un dato, molti utilizzi

Quando pensiamo a un'informazione turistica, spesso immaginiamo immediatamente il luogo nel quale verrà pubblicata:

• Una pagina web.
• Una brochure.
• Una mappa.
• Un'applicazione.
• Un pannello informativo.

Questo modo di procedere produce facilmente duplicazioni perchè ogni nuovo servizio costruisce la propria copia dell'informazione.

• Il sito turistico possiede un elenco dei musei.
• Il portale culturale ne possiede un altro.
• Una mappa ne utilizza un terzo.
• Un'applicazione ne crea un quarto.

Gli stessi luoghi vengono descritti più volte, spesso attraverso archivi che non comunicano tra loro, quando cambia un orario, bisogna ricordarsi di modificare tutte le copie, quando una modifica viene dimenticata, cominciano le incongruenze.

La prospettiva che proponiamo è opposta: prima organizziamo il dato, poi costruiamo i servizi che lo utilizzano.

Una sola informazione, molte rappresentazioni

Prendiamo un luogo culturale. Possiamo descriverlo attraverso dati strutturati:

• nome;
• tipologia;
• indirizzo;
• coordinate;
• orari;
• contatti;
• accessibilità;
• descrizione;
• immagini;
• servizi;
• fonte;
• ultimo aggiornamento.

Una volta organizzate correttamente, queste informazioni possono essere utilizzate per costruire molti prodotti differenti come:

• Una pagina web.
• Una scheda mobile.
• Una mappa.
• Un itinerario.
• Una guida accessibile.
• Un calendario.
• Un'applicazione.
• Un servizio vocale.
• Un dataset Open Data.
• Un'API.

Il dato rimane lo stesso mentre quello che cambia è il modo nel quale viene presentato e utilizzato.

Separare contenuto e contenitore

Questo introduce una distinzione fondamentale: il contenuto non deve coincidere con il contenitore che lo mostra.

Se l'informazione su un museo esiste soltanto all'interno del testo di una pagina web, per utilizzarla altrove dobbiamo estrarla o riscriverla, se invece quell'informazione esiste come dato strutturato, la pagina web diventa soltanto una delle possibili rappresentazioni. È un cambiamento apparentemente tecnico che modifica profondamente il modo nel quale una città può organizzare la propria informazione.

Non costruiamo più pagina → informazione ma dato → molti servizi

L'esempio più semplice: un indirizzo

Supponiamo che l'indirizzo di un luogo sia scritto all'interno della descrizione: “Il museo si trova in Via X numero 15, nel centro storico.”

Un lettore lo comprende ma per creare automaticamente una mappa dobbiamo estrarre quell'informazione dal testo.

Se invece possediamo campi distinti:

via: Via X
numero civico: 15
CAP: ...
Comune: Salerno
coordinate: ...

possiamo utilizzare la stessa informazione per:

• mostrare l'indirizzo;
• posizionare il luogo sulla mappa;
• calcolare una distanza;
• trovare una fermata vicina;
• costruire un itinerario;
• filtrare i luoghi per zona.

La struttura del dato moltiplica gli utilizzi possibili.

L'orario come dato

Lo stesso principio vale per gli orari. Scrivere “aperto dal martedì alla domenica dalle 9 alle 19” è perfettamente comprensibile per una persona ma un sistema che voglia rispondere alla domanda “quali musei sono aperti adesso?” ha bisogno di informazioni strutturate.

• Giorno.
• Ora di apertura.
• Ora di chiusura.
• Eventuali intervalli.
• Festività.
• Eccezioni.

Una volta strutturato, lo stesso orario può apparire su una pagina oppure diventare il criterio attraverso il quale un servizio seleziona automaticamente i luoghi disponibili.

L'accessibilità come informazione riutilizzabile

Anche il concetto di accessibilità dimostra bene la differenza. Una frase generica come “struttura accessibile” fornisce poca informazione.

• Accessibile a chi?
• In quale modo?

Potremmo invece descrivere separatamente:

• accesso senza gradini;
• presenza di rampa;
• ascensore;
• larghezza dell'ingresso;
• servizi igienici accessibili;
• posti riservati;
• informazioni tattili;
• supporti audio;
• altre caratteristiche.

Questi dati possono alimentare una normale pagina informativa ma possono anche permettere a una persona di cercare:

soltanto i luoghi compatibili con le proprie esigenze.

Il dato non cambia il servizio radicalmente si.

Un evento, molti canali

Pensiamo ora a un evento.

• Titolo.
• Data.
• Ora.
• Luogo.
• Organizzatore.
• Categoria.
• Descrizione.
• Costo.
• Modalità di prenotazione.
• Accessibilità.
• Immagine.

Se queste informazioni vengono inserite una sola volta in forma strutturata, possono alimentare automaticamente:

• il calendario generale;
• la pagina dell'organizzatore;
• la pagina del luogo;
• una newsletter;
• una mappa degli eventi;
• una selezione degli eventi gratuiti;
• una selezione per famiglie;
• un'applicazione;
• un feed esterno;
• un servizio turistico.

Un'unica operazione di aggiornamento può modificare molti servizi.

Scrivere una volta, utilizzare molte volte

Il principio può essere sintetizzato così: creare una volta, aggiornare alla fonte, utilizzare molte volte.

Non significa che la stessa descrizione debba necessariamente apparire identica ovunque.

• Un'applicazione può aver bisogno di una versione breve.
• Un portale culturale di una descrizione più approfondita.
• Un assistente vocale di un testo adatto alla lettura.

Ma gli elementi fondamentali - luogo, data, orario, coordinate, accessibilità, fonte - non dovrebbero essere riscritti ogni volta.

Duplicare significa moltiplicare gli errori

Ogni copia crea un problema di manutenzione. Se un'informazione è presente in dieci sistemi, abbiamo dieci punti nei quali può diventare obsoleta. Possiamo rappresentare il modello tradizionale così:

fonte → copia A
fonte → copia B
fonte → copia C
fonte → copia D

Quando il dato cambia, tutte le copie devono essere aggiornate.

Nel modello interoperabile: fonte → dato strutturato → servizi A, B, C, D

Il cambiamento avviene una volta e può propagarsi ai diversi utilizzatori.

L'aggiornamento diventa parte del servizio

Questa differenza è particolarmente importante per informazioni che cambiano frequentemente:

• Eventi.
• Orari.
• Trasporti.
• Aperture straordinarie.
• Servizi.

Quando queste informazioni vengono gestite manualmente da molti soggetti, l'errore diventa quasi inevitabile. Certamente l'automazione non elimina tutti gli errori, permette però di eliminare una grande quantità di copie manuali inutili.

Una fonte autorevole

Perché questo modello funzioni dobbiamo sapere chi è responsabile dell'informazione.

• Chi stabilisce l'orario del museo? Il museo.
• Chi conosce il percorso dell'autobus? Il gestore del trasporto.
• Chi comunica la data di un evento? L'organizzatore.
• Chi certifica determinati dati amministrativi? L'ente competente.

Il sistema non deve necessariamente sostituirsi a questi soggetti; deve essere invece capace di riconoscerli come fonti autorevoli e utilizzare le loro informazioni.

La fonte autorevole non deve essere necessariamente centrale

Questo ci riporta al modello federato. Non immaginiamo una gigantesca redazione centrale incaricata di controllare continuamente ogni dato turistico della città perchè sarebbe costoso e difficilmente sostenibile.

Possiamo invece distribuire la responsabilità dove ogni soggetto mantiene ciò che conosce meglio. Il sistema stabilisce regole comuni che permettono alle informazioni di essere utilizzate insieme.

Responsabilità distribuita, conoscenza condivisa.

Molti produttori, molti utilizzatori

La stessa organizzazione può essere contemporaneamente produttrice e utilizzatrice di dati.

Un museo produce:

• orari;
• eventi;
• servizi.
• Ma utilizza:
• trasporti;
• mappe;
• informazioni territoriali.

Una struttura ricettiva produce alcune informazioni sulla propria attività e contemporaneamente utilizza dati su:

• eventi;
• mobilità;
• luoghi culturali;
• servizi.

Il Comune produce dati amministrativi e utilizza dati regionali  -->  La Regione produce dataset e utilizza informazioni provenienti dai territori.

L'ecosistema non è una piramide ma è una rete di scambi.

Un dato pubblico può generare servizi che non avevamo previsto

Questo è uno degli aspetti più interessanti degli Open Data. Chi pubblica un dato non deve necessariamente immaginare tutti i possibili utilizzi perchè una volta disponibile, qualcun altro può combinarlo con informazioni differenti e creare qualcosa di nuovo.

Un dataset sui luoghi culturali può essere collegato:

• alle fermate del trasporto pubblico;
• alle pendenze stradali;
• alle informazioni di accessibilità;
• agli eventi;
• alla presenza di parcheggi;
• alle fontanelle;
• agli spazi verdi.

Nascono servizi che il produttore originario del dataset potrebbe non aver mai immaginato.

L'innovazione nasce spesso dalle combinazioni

Il valore di un dato isolato può essere limitato mentre aumenta quando lo colleghiamo ad altri dati.

Possiamo immaginare:

luoghi culturali + mobilità per indicare come raggiungerli;

eventi + trasporto pubblico per programmare gli spostamenti;

ricettività + quartieri per studiare la distribuzione territoriale;

accessibilità + luoghi + percorsi per costruire itinerari accessibili;

eventi + presenze + mobilità per analizzare gli impatti;

turismo + commercio per comprendere la distribuzione economica;

turismo + ambiente per misurare pressioni e sostenibilità.

La conoscenza cresce attraverso la relazione.

Lo stesso dato per turisti e residenti

Non dobbiamo inoltre pensare che ogni dato turistico serva soltanto al turista. Un calendario degli eventi - ad esempio - interessa anche chi vive a Salerno. Le informazioni sulla mobilità servono a residenti, visitatori e lavoratori.

L'accessibilità riguarda chiunque utilizzi la città ed una mappa dei servizi può essere utilizzata da chi arriva per un giorno e da chi abita nello stesso quartiere da quarant'anni.

Questo rafforza uno dei principi del progetto: costruire servizi per la città, non una città separata per il turista.

Lo stesso dato per finalità differenti

Prendiamo la localizzazione delle strutture ricettive:

• Per il turista serve a trovare un alloggio.
• Per l'amministrazione può servire a studiare la distribuzione dell'offerta.
• Per il ricercatore può mostrare le trasformazioni nel tempo.
• Per un residente può aiutare a comprendere i cambiamenti del proprio quartiere.
• Per un'impresa può essere un'informazione di mercato.
• Per la pianificazione può essere collegata alle dinamiche abitative.

Il dato è identico ma la domanda cambia.

Dal servizio all'analisi

Questa distinzione è importante anche per GiraSalerno. Una banca dati di luoghi non serve soltanto a costruire una guida turistica. Gli stessi dati possono alimentare anche strumenti di analisi. Ad esempio:

• quanti luoghi culturali sono presenti in ciascuna zona?
• quanti risultano accessibili?
• quali sono raggiungibili facilmente con il trasporto pubblico?
• quali quartieri dispongono di pochi servizi informativi?

La stessa infrastruttura può quindi sostenere contemporaneamente servizi al pubblico e conoscenza per la programmazione.

Dal dato operativo al dato statistico

Un'altra possibilità nasce dall'aggregazione. Supponiamo di avere informazioni strutturate sui singoli eventi. Possiamo utilizzarle per mostrare il calendario ma possiamo anche aggregarle per sapere:

• quanti eventi si svolgono ogni mese;
• quali categorie sono prevalenti;
• in quali zone si concentrano;
• quanti sono gratuiti;
• quanti possiedono informazioni sull'accessibilità.

Il dato operativo utilizzato per il servizio può diventare anche una fonte per l'analisi.

Attenzione: ciò che esiste nel database non coincide sempre con la realtà

Dobbiamo però mantenere una distinzione metodologica importante. Se il database contiene 300 eventi, non possiamo automaticamente affermare che in città si siano svolti soltanto 300 eventi perchè potrebbero essercene stati altri non registrati.

La banca dati descrive ciò che riesce a rappresentare. Per questo occorre sempre conoscere la copertura della fonte.

Un sistema trasparente deve dichiararne i limiti.

Il dato amministrativo può avere una seconda vita

Molti dati vengono prodotti per una ragione amministrativa:

• Autorizzare.
• Registrare.
• Riscuotere.
• Controllare.

Una volta adeguatamente anonimizzati e aggregati, alcuni di questi dati possono assumere una seconda funzione: conoscere la città.

Il dato nato per amministrare può diventare anche dato per analizzare.

Naturalmente non tutto ciò che esiste nei sistemi amministrativi può o deve diventare pubblico ma il potenziale di riuso dovrebbe essere valutato fin dalla progettazione.

Non chiedere due volte la stessa informazione

Il principio del riuso dovrebbe valere anche nei rapporti tra amministrazione e cittadini o imprese. Se un'informazione è già disponibile presso una fonte pubblica affidabile e può essere legittimamente riutilizzata, dovremmo evitare di richiederla nuovamente senza necessità. Il dato può viaggiare tra sistemi. Le persone non dovrebbero diventare il mezzo attraverso il quale amministrazioni non comunicanti si trasferiscono continuamente le stesse informazioni.

Non far lavorare l'utente al posto dei sistemi

Pensiamo a una situazione frequente:

• Un turista legge un'informazione su un sito.
• Deve poi cercare autonomamente l'indirizzo su una mappa.
• Successivamente controlla il trasporto su un altro servizio.
• Poi verifica gli orari su un terzo.

Il problema non è necessariamente che le informazioni non esistano ma che è l'utente a doverle integrare manualmente. Un'infrastruttura ben progettata può effettuare almeno una parte di questa integrazione automaticamente.

Dal dato al percorso

Supponiamo che una persona voglia visitare tre luoghi. Se possediamo dati strutturati possiamo mettere in relazione:

• posizione;
• orari;
• tempi di percorrenza;
• trasporti;
• accessibilità;
• eventi.

Il sistema può aiutare a costruire un percorso compatibile con il tempo disponibile. In questo caso non abbiamo prodotto nuove informazioni ma abbiamo creato nuovo valore combinando informazioni già esistenti.

Dal dato alla personalizzazione, senza sorveglianza

Lo stesso principio può permettere servizi personalizzati. Una persona può chiedere:

• luoghi accessibili;
• eventi gratuiti;
• percorsi a piedi;
• attività per bambini;
• luoghi aperti la sera;
• itinerari raggiungibili con il trasporto pubblico.

Non è necessario costruire un profilo permanente dell'individuo perchè possiamo rispondere alla richiesta utilizzando i criteri scelti in quel momento. La personalizzazione del servizio non deve necessariamente trasformarsi in profilazione della persona.

Dal dato all'informazione multilingue

Se una scheda è strutturata correttamente, possiamo distinguere gli elementi che non richiedono traduzione da quelli che la richiedono.

Coordinate, date, orari, numeri e identificatori rimangono gli stessi mentre Titoli e descrizioni possono essere tradotti: una sola entità può quindi alimentare servizi in più lingue senza creare database separati per ciascuna lingua.

Anche questo riduce duplicazioni.

Dal dato all'informazione accessibile

Una base informativa strutturata permette inoltre di presentare lo stesso contenuto in forme diverse.

• Testo.
• Audio.
• Interfacce semplificate.
• Mappe.
• Servizi compatibili con tecnologie assistive.

Il principio “un dato, molti utilizzi” riguarda quindi anche le diverse modalità di accesso all'informazione.

Dal dato all'intelligenza artificiale

Sempre più spesso le persone cercano informazioni attraverso assistenti digitali e sistemi di intelligenza artificiale. Anche questi strumenti hanno bisogno di fonti affidabili: se l'informazione pubblica è dispersa, contraddittoria e non strutturata, aumenta il rischio che vengano fornite risposte errate o obsolete.

Una città che organizza bene i propri dati non costruisce soltanto servizi per il presente ma crea fonti migliori anche per nuove forme di accesso alla conoscenza.

La qualità alla fonte diventa ancora più importante

Più volte un dato viene riutilizzato, più importante diventa la sua qualità:

• Un errore presente in una pagina produce un errore.
• Un errore presente nella fonte utilizzata da dieci servizi può propagarsi dieci volte.

L'architettura del riuso aumenta quindi contemporaneamente il valore del dato corretto e l'impatto del dato sbagliato.

Per questo servono procedure di verifica e correzione.

Correggere una volta, migliorare molti servizi

Il vantaggio opposto è enorme.

• Se una coordinata viene corretta alla fonte, tutte le applicazioni che utilizzano quel dato possono ricevere la correzione.
• Se un'informazione sull'accessibilità viene aggiornata, molti servizi possono migliorare simultaneamente.
• Se cambia l'orario, non occorre modificare dieci pagine.

La correzione stessa diventa riutilizzabile.

La partecipazione moltiplica il proprio effetto

Questo offre una nuova prospettiva anche alla partecipazione.

• Un cittadino segnala un errore.
• L'errore viene verificato.
• La fonte viene corretta.
• Tutti i servizi collegati ricevono la nuova informazione.
• Una singola segnalazione non migliora soltanto una pagina.

Questo può migliorare l'intero ecosistema che utilizza quel dato.

Anche la verifica può essere condivisa

Possiamo immaginare diversi soggetti che contribuiscono al controllo della qualità.

• I responsabili delle fonti.
• Gli operatori.
• Le associazioni.
• I cittadini.
• Gli utilizzatori dei servizi.
• Gli sviluppatori.

Ogni soggetto osserva il dato da una prospettiva differente. Il riuso genera quindi non soltanto nuovi servizi, ma anche nuove occasioni di verifica.

La documentazione viene riutilizzata anch'essa

Non riutilizziamo soltanto il valore del dato. Possiamo riutilizzare:

• definizioni;
• metadati;
• vocabolari;
• classificazioni;
• licenze;
• metodologie.

Se definiamo una volta in maniera chiara cosa intendiamo per una determinata categoria, non dobbiamo reinventare la definizione in ogni progetto. Anche la documentazione è parte dell'infrastruttura condivisa.

Un vocabolario, molti sistemi

Pensiamo alla categoria: museo.

Se ogni portale utilizza classificazioni differenti, collegare i dati diventa complicato. Un sistema potrebbe avere “musei”, un altro “cultura”, un altro ancora “attrazioni”.

Non è necessario che tutte le interfacce mostrino le stesse parole ma dietro le interfacce possiamo costruire corrispondenze e vocabolari condivisi. In questo modo l'utente può vedere il termine più adatto ed i sistemi possono continuare a comprendersi.

Un identificatore, molti nomi

Lo stesso luogo può avere:

• nome ufficiale;
• nome comune;
• nome storico;
• traduzioni.

L'identificatore stabile permette di mantenere l'unità. Possiamo quindi avere: un'entità → molti nomi senza creare duplicati. Questo è particolarmente importante per una città turistica, nella quale le informazioni devono essere utilizzate in più lingue e contesti.

Il dato può essere migliorato senza rompere i servizi

Un buon modello deve poter evolvere. Oggi possiamo sapere soltanto se un luogo è genericamente accessibile mentre domani possiamo aggiungere informazioni più dettagliate.

Se il modello è progettato correttamente, i servizi esistenti possono continuare a funzionare mentre quelli nuovi utilizzano i campi aggiuntivi. L'infrastruttura deve poter crescere senza dover essere continuamente ricostruita da zero.

Non tutti devono utilizzare tutto

Aprire una grande quantità di dati non significa che ogni applicazione debba utilizzarli tutti. Un servizio molto semplice può aver bisogno soltanto di:

• nome;
• coordinate;
• orario.

Un'applicazione specialistica può utilizzare decine di attributi. Il valore di una base comune consiste proprio nel permettere a ciascun utilizzatore di prendere soltanto ciò che gli serve.

API come porte, non come destinazione

Nel capitolo precedente abbiamo introdotto le API e possiamo ora comprenderne meglio la funzione. L'API non è il servizio finale ma una porta attraverso la quale altri servizi possono chiedere informazioni.

• Una mappa può utilizzarla.
• Un'applicazione può utilizzarla.
• Un sito può utilizzarla.
• Un ricercatore può utilizzarla.

L'API permette al dato di viaggiare senza imporre in anticipo il modo nel quale dovrà essere presentato.

Un esempio per GiraSalerno

Immaginiamo che GiraSalerno disponga di un insieme strutturato di luoghi. Lo stesso archivio potrebbe alimentare: /luoghi

• con l'elenco generale;
• una mappa;
• una ricerca per quartiere;
• una ricerca per categoria;
• una ricerca per accessibilità;
• gli itinerari;
• una sezione dedicata agli eventi nei singoli luoghi;
• un'API pubblica.

Non sono sette archivi ma sette modi di interrogare lo stesso patrimonio informativo.

Un sito migliore perché contiene meno copie

Può sembrare paradossale. Siamo abituati a valutare un portale dal numero di pagine ma un sistema informativo maturo potrebbe essere migliore proprio perché contiene meno duplicazioni.

• Una pagina può essere generata utilizzando dati condivisi.
• Una mappa può aggiornarsi automaticamente.
• Una scheda non deve essere riscritta in ogni sezione.

Il valore non sta nella quantità di contenuto replicato ma nella qualità della struttura sottostante.

Il principio vale oltre GiraSalerno

GiraSalerno sarà soltanto un dimostratore. Il modello ha senso se altri soggetti possono utilizzare gli stessi dati.

• Un'associazione potrebbe costruire una mappa tematica.
• Un'università un'analisi.
• Un'impresa un'applicazione.
• Un Comune un proprio servizio.
• Una scuola un progetto didattico.
• Una guida un itinerario.

La Banca Dati raggiunge realmente il proprio obiettivo quando non possiamo prevedere tutti i suoi utilizzatori futuri.

Il dato come infrastruttura pubblica

Possiamo allora paragonare il dato a un'infrastruttura.

Una strada non viene costruita per una sola automobile, una rete elettrica non viene progettata per un singolo elettrodomestico ed allo stesso modo una buona infrastruttura informativa non dovrebbe essere creata esclusivamente per una pagina web.

Deve permettere il passaggio di molti servizi. Naturalmente il paragone ha dei limiti ma aiuta a comprendere il principio: il dato pubblico acquista valore quando può essere utilizzato da molti soggetti per molte finalità.

Riutilizzare significa anche risparmiare

La duplicazione non produce soltanto errori ma anche costi. Ogni soggetto che ricostruisce lo stesso elenco deve:

• raccogliere;
• copiare;
• controllare;
• aggiornare;
• correggere.

Una parte consistente del lavoro potrebbe essere evitata se il dato fosse già disponibile in forma affidabile e riutilizzabile. Open Data e interoperabilità non sono quindi soltanto principi di trasparenza ma anche strumenti di efficienza amministrativa ed economica.

Investire sulla fonte

Se dieci servizi utilizzano lo stesso dataset, diventa molto conveniente investire sulla qualità di quella fonte perchè migliorarla produce benefici multipli. Questo cambia anche il modo nel quale possiamo pensare alla spesa pubblica digitale.

Invece di finanziare dieci volte la raccolta della stessa informazione, possiamo finanziare meglio:

• la fonte;
• la documentazione;
• l'aggiornamento;
• l'interoperabilità.

Dal progetto all'ecosistema

Un progetto tradizionale spesso produce:

• un sito;
• alcuni contenuti;
• un periodo di manutenzione.

Poi termina.

Un ecosistema produce invece:

• dati;
• regole;
• standard;
• relazioni;
• servizi;
• possibilità di nuovi riusi.

Il primo costruisce un prodotto mentre il secondo costruisce capacità. Salerno Turismo Aperto deve tendere al secondo modello.

La conoscenza non deve avere un unico proprietario

Se il patrimonio informativo può essere utilizzato soltanto dal soggetto che gestisce una piattaforma, abbiamo costruito una nuova forma di chiusura. Una vera infrastruttura pubblica deve permettere, nei limiti stabiliti dalla legge e dalle licenze, che soggetti diversi possano accedere e costruire servizi. Il dato non deve essere ostaggio dell'applicazione che per prima lo utilizza.

Il servizio può scomparire, il dato deve rimanere

• Un'applicazione può diventare obsoleta.
• Un sito può essere rifatto.
• Una tecnologia può essere sostituita.
• Un progetto può terminare.

ma la conoscenza costruita nel frattempo non dovrebbe andare perduta e separare dati e servizi permette proprio questo. Possiamo sostituire l'interfaccia conservando il patrimonio sottostante.

Standard aperti per rendere possibile il riuso

Perché un dato possa essere utilizzato da molti sistemi servono regole comuni:

• Formati.
• Vocabolari.
• Identificatori.
• Modelli.
• Protocolli.

Non devono necessariamente essere inventati localmente e quando esistono standard consolidati è preferibile utilizzarli. Un linguaggio condiviso riduce il lavoro necessario per collegare sistemi differenti.

Il vero salto: da molti utilizzi a molti sistemi

Finora abbiamo immaginato molti utilizzi dello stesso dato all'interno di una singola infrastruttura ma il passo successivo è ancora più importante. Fare in modo che:

• il sistema regionale;
• il Comune;
• un portale culturale;
• un gestore della mobilità;
• GiraSalerno;
• un'applicazione privata

possano scambiarsi informazioni mantenendo ciascuno la propria autonomia. A quel punto non stiamo più parlando soltanto di riuso ma di interoperabilità.

Non un grande sistema unico

La conclusione può sembrare controintuitiva. Per utilizzare gli stessi dati in molti modi non abbiamo necessariamente bisogno di un enorme sistema informatico centrale ma soprattutto di sistemi capaci di dialogare.

• Le fonti possono rimanere distribuite.
• I servizi possono essere differenti.
• Le tecnologie possono essere differenti.

Ciò che deve esistere è una base comune sufficiente per permettere alle informazioni di attraversare questi confini.

Dal riuso all'interoperabilità

Possiamo quindi rappresentare il percorso compiuto nella Parte III:

informazioni disperse

↓

dati organizzati

↓

Banca Dati Turistica Aperta

↓

Open Data realmente riutilizzabili

↓

un dato, molti utilizzi

Ma resta ancora un problema: Come facciamo a permettere a sistemi costruiti da organizzazioni differenti, con tecnologie differenti e finalità differenti, di comprendere e utilizzare reciprocamente i propri dati?

È il passaggio successivo e lo vedremo nel prossimo capitolo.