Abbiamo costruito un modello, inserito i primi dati e verificato che le stesse informazioni possano alimentare ricerca, mappe, relazioni tra luoghi e altri servizi.
Ma rimane una domanda fondamentale:
chi può utilizzare questa conoscenza?
Se la risposta fosse soltanto “chi visita GiraSalerno.it”, avremmo realizzato un sito più strutturato, ma non avremmo ancora applicato pienamente uno dei principi centrali di Salerno Turismo Aperto.
La conoscenza deve poter uscire dall'applicazione che l'ha prodotta.
È qui che entrano in gioco Open Data e API.
Aprire non significa soltanto permettere di scaricare
Nel linguaggio comune si tende spesso a considerare “aperto” qualsiasi dato disponibile su Internet.
Un PDF pubblicato sul sito di un ente è certamente accessibile. Una tabella inserita dentro una pagina web può essere letta. Un documento può essere scaricato e consultato.
Ma l'apertura dei dati richiede qualcosa di più.
Se vogliamo che un'informazione possa essere realmente riutilizzata da altri sistemi, dobbiamo renderla disponibile in una forma che permetta di comprenderne la struttura e il significato.
Un elenco di luoghi scritto dentro un PDF è leggibile da una persona.
Una distribuzione strutturata degli stessi luoghi può essere elaborata anche da un programma.
È la differenza già incontrata nella Parte III di questo Piano:
pubblicare un dato non significa necessariamente renderlo riutilizzabile.
GiraSalerno ha provato a trasformare questo principio in una funzione concreta.
Il dato non appartiene alla pagina
Torniamo ancora una volta al nostro Punto di interesse.
Quando apriamo la pagina dedicata a un luogo vediamo una rappresentazione pensata per una persona: titoli, testi, collegamenti e informazioni organizzate graficamente.
Ma il POI esiste nel sistema indipendentemente da quella particolare rappresentazione.
Questa separazione permette di utilizzare la stessa conoscenza in modi differenti.
Possiamo costruire una pagina web.
Possiamo collocare il luogo su una mappa.
Possiamo utilizzarlo in una ricerca.
Possiamo inserirlo in un itinerario.
E possiamo fornire i suoi dati a un altro programma.
La pagina smette così di essere il punto finale obbligato dell'informazione.
Le distribuzioni Open Data
GiraSalerno mette a disposizione una rappresentazione pubblica dei Punti di interesse attraverso distribuzioni Open Data.
Nella sperimentazione sono stati utilizzati due formati:
JSON e CSV.
Non occorre conoscere la programmazione per comprenderne il ruolo.
Il CSV può essere immaginato, con qualche semplificazione, come una tabella: righe e colonne che possono essere elaborate attraverso numerosi strumenti.
JSON permette invece di rappresentare con maggiore naturalezza informazioni strutturate e viene utilizzato molto frequentemente nello scambio di dati tra applicazioni.
I due formati non creano due banche dati differenti.
Sono due rappresentazioni della stessa base informativa pubblicabile.
Questa distinzione è importante.
Il processo corretto non consiste nel mantenere manualmente un file CSV, poi aggiornare separatamente un JSON e infine modificare le pagine del sito.
Le distribuzioni devono essere generate a partire dalla conoscenza mantenuta nel sistema.
In questo modo si riduce il rischio che nascano versioni divergenti della stessa informazione.
Il CSV non è il database
Questo ci permette anche di correggere un equivoco frequente.
Quando un ente pubblica un file CSV, quel file viene spesso identificato con “il dataset”.
Dal punto di vista dell'utilizzatore può essere una definizione comprensibile. Ma, nel modello di GiraSalerno, il file rappresenta piuttosto una distribuzione del dataset.
La conoscenza viene mantenuta nella struttura informativa principale.
Da quella struttura possiamo produrre differenti rappresentazioni destinate a differenti utilizzi.
Se domani fosse necessario aggiungere un altro formato, non dovremmo teoricamente costruire una nuova banca dati.
Dovremmo produrre una nuova rappresentazione della conoscenza già disponibile.
Che cosa sono le API
Accanto alle distribuzioni Open Data esiste un secondo strumento: le API, Application Programming Interface.
Il nome può sembrare tecnico, ma il concetto di base è semplice.
Una API permette a un programma di fare una richiesta a un altro sistema e ricevere una risposta strutturata.
Una persona potrebbe aprire GiraSalerno e cercare un luogo.
Un'applicazione potrebbe invece chiedere direttamente al sistema:
“forniscimi i Punti di interesse disponibili”
oppure:
“forniscimi questo specifico Punto di interesse”.
La risposta non è necessariamente una pagina costruita per essere letta visivamente.
È informazione organizzata affinché un altro software possa interpretarla.
L'API diventa quindi una porta di accesso applicativa alla conoscenza.
Le API sperimentate da GiraSalerno
Il dimostratore dispone di un'interfaccia dedicata ai Punti di interesse.
È possibile ottenere la collezione dei POI oppure richiedere uno specifico luogo attraverso un identificatore pubblico.
È stata inoltre sperimentata un'interfaccia per la ricerca dei Punti di interesse nelle vicinanze, utilizzando la componente geografica dei dati.
Accanto a questa API specificamente costruita per GiraSalerno rimane disponibile anche l'interfaccia JSON:API fornita dal sistema di gestione dei contenuti.
Le due cose non devono essere confuse.
JSON:API espone più direttamente il modello delle entità gestite dall'applicazione.
L'API di GiraSalerno può invece costruire una rappresentazione maggiormente orientata al dominio turistico e agli utilizzi che vogliamo offrire all'esterno.
È un'altra applicazione di un principio già incontrato:
la struttura interna di un programma e l'interfaccia pubblica con la quale decidiamo di presentare i dati non devono necessariamente coincidere.
Un'identità utilizzabile anche all'esterno
Quando due sistemi devono dialogare, l'identificazione degli elementi diventa fondamentale.
Un programma deve poter sapere che il luogo richiesto oggi è lo stesso luogo al quale farà riferimento domani.
GiraSalerno utilizza per la propria API dedicata un identificatore UUID per il singolo Punto di interesse.
All'interno del sistema esistono anche identificatori tecnici necessari a Drupal, mentre può essere conservato separatamente l'eventuale identificativo che il luogo possiede nella fonte dalla quale è stato acquisito.
Sono tre concetti differenti.
L'identificatore interno serve al funzionamento dell'applicazione.
L'UUID permette di identificare il POI nell'interfaccia pubblica prevista.
L'identificativo della fonte permette di mantenere un collegamento con un sistema esterno quando questo esiste.
Distinguere questi livelli prepara il terreno per una reale interoperabilità.
Una sola logica, più uscite
Durante la costruzione del dimostratore è stata posta attenzione anche a un altro problema: evitare che ogni uscita dei dati sviluppi una propria interpretazione indipendente.
Per questo una parte della logica utilizzata per costruire le informazioni pubblicabili dei POI viene condivisa tra differenti funzioni.
L'obiettivo non è semplicemente risparmiare codice.
È ridurre il rischio che, per esempio, la stessa proprietà venga interpretata in un modo nell'API e in un altro modo nella distribuzione Open Data.
Non significa che JSON, CSV e API debbano essere identici.
Formati e finalità differenti possono richiedere rappresentazioni differenti.
Devono però derivare, per quanto possibile, da una stessa interpretazione della conoscenza.
Anche i metadati sono dati
Un file contenente cento Punti di interesse non è sufficiente se chi lo riceve non sa che cosa rappresenti.
Per questo l'apertura richiede anche metadati e documentazione.
Chi produce il dataset?
Quale territorio descrive?
Quale versione dello schema stiamo utilizzando?
Quando è stata generata la distribuzione?
Quali condizioni di riuso si applicano?
Dove troviamo la documentazione?
Sono informazioni necessarie per utilizzare responsabilmente i dati.
GiraSalerno accompagna quindi le proprie distribuzioni con informazioni descrittive e una pagina di documentazione.
È un aspetto che può sembrare secondario finché siamo noi stessi a utilizzare i nostri dati.
Diventa essenziale quando quei dati escono dal loro contesto originario.
Un dato aperto senza il contesto necessario a comprenderlo rischia di essere tecnicamente disponibile ma semanticamente povero.
La data del file non è la data del dato
La presenza dei metadati permette di evidenziare un'altra distinzione importante.
Supponiamo di generare oggi una nuova distribuzione Open Data.
La data di generazione ci dice quando è stato prodotto il file.
Non ci dice automaticamente quando ciascuna informazione contenuta nel file sia stata verificata.
Un POI potrebbe essere stato controllato ieri e un altro settimane prima.
Per questo il modello mantiene, quando previsto, informazioni relative all'acquisizione e alla verifica dei singoli dati o record.
Data di generazione della distribuzione e data di verifica della conoscenza non sono la stessa cosa.
È una distinzione fondamentale per valutare l'attualità di informazioni che cambiano nel tempo.
Aprire conservando la provenienza
Uno dei rischi dell'Open Data è che, quando il dato viene estratto dal sistema originario, perda il proprio contesto.
Un numero, una classificazione o un'informazione diventano molto meno affidabili se non sappiamo più da dove provengano.
Per questo il modello di GiraSalerno cerca di conservare anche nella rappresentazione pubblica le informazioni necessarie a ricostruire la provenienza.
Come abbiamo visto nel capitolo precedente, il livello attuale di granularità delle fonti può ancora essere migliorato.
Ma il principio rimane:
il dato dovrebbe poter viaggiare senza perdere la propria storia.
L'interoperabilità non consiste soltanto nel trasferire valori da un programma all'altro.
Consiste nel trasferirli cercando di conservarne il significato.
Non tutto ciò che esiste deve diventare Open Data
Un'infrastruttura aperta non è un'infrastruttura che pubblica indiscriminatamente ogni informazione contenuta al proprio interno.
GiraSalerno distingue tra ciò che appartiene alla conoscenza destinata al riuso pubblico e ciò che appartiene ai processi interni.
Le Segnalazioni dei cittadini, per esempio, non vengono inserite nelle distribuzioni Open Data dei POI.
Una segnalazione può contenere un'informazione da verificare. Fino a quando il processo editoriale non la trasforma eventualmente in un dato verificato, rimane parte del processo di manutenzione della conoscenza.
Anche i Media sono attualmente esclusi dalle distribuzioni dei POI.
Il sistema può gestire immagini con autore, fonte, licenza e attribuzione, ma la loro apertura richiede di rispettare condizioni specifiche che non coincidono necessariamente con quelle applicate ai dati.
Questa scelta esprime un principio:
aprire ciò che è destinato al riuso, non esportare indiscriminatamente tutto ciò che contiene il sistema.
Un sito ufficiale non è una fonte e una fonte non è un servizio
Quando i dati escono dal sito, le distinzioni semantiche diventano ancora più importanti.
In una pagina destinata a una persona possiamo forse comprendere dal contesto che un collegamento porta al sito ufficiale, un altro alla fonte utilizzata e un altro ancora a un servizio esterno.
Un'applicazione non può affidarsi allo stesso livello di intuizione.
Per questo GiraSalerno distingue il ruolo dei collegamenti.
Il sito ufficiale identifica una risorsa ufficiale pertinente al luogo.
La fonte documenta l'informazione.
L'approfondimento offre contenuti ulteriori.
Un servizio esterno porta a una funzione operativa.
Preservare queste differenze aumenta il valore dei dati quando vengono riutilizzati.
Una versione, non una promessa di immobilità
Le interfacce pubbliche del dimostratore sono identificate come versione 1.
La presenza di una versione è importante perché riconosce che anche un'API e uno schema Open Data possono evolvere.
Nuove esigenze potrebbero richiedere nuovi campi, differenti rappresentazioni o ulteriori funzioni.
La sigla v1 non significa però che sia già stata definita una completa politica futura di compatibilità, migrazione e dismissione delle versioni.
Questa sarà necessaria se il progetto crescerà e verrà utilizzato stabilmente da applicazioni esterne.
Per ora la versione indica soprattutto una cosa:
l'interfaccia pubblica è qualcosa che deve essere riconoscibile e la sua evoluzione non dovrebbe avvenire silenziosamente.
Open Data non significa Software Libero
È utile ribadire anche una distinzione affrontata precedentemente nel Piano.
GiraSalerno utilizza Software Libero e produce Open Data.
Le due scelte sono coerenti tra loro, ma non sono la stessa cosa.
Il Software Libero riguarda il codice e le libertà connesse al suo utilizzo, studio, modifica e redistribuzione secondo la relativa licenza.
L'Open Data riguarda i dati e le condizioni che ne permettono il riuso.
Un'immagine, infine, può avere ancora una licenza differente.
Un sistema realmente aperto deve conoscere queste differenze, non nasconderle sotto un'unica etichetta.
L'Open Data come processo automatico
La sperimentazione suggerisce anche una conseguenza organizzativa importante.
L'Open Data non dovrebbe essere pensato come un'attività separata da svolgere ogni tanto:
“ora prepariamo il file da pubblicare”.
Se i dati vengono mantenuti correttamente nella base di conoscenza, le distribuzioni pubbliche possono essere generate a partire da quella stessa base.
In questo modo l'apertura diventa parte del processo ordinario di gestione dell'informazione.
Il principio può essere espresso così:
non mantenere una banca dati per il sito e un'altra banca dati per gli Open Data.
Mantenere una conoscenza sufficientemente strutturata da poter produrre differenti servizi e differenti distribuzioni.
È esattamente il contrario della frammentazione che abbiamo descritto nella prima parte di questo Piano.
L'interoperabilità comincia dal significato
Possiamo quindi tornare alla parola che abbiamo incontrato più volte: interoperabilità.
Due sistemi non diventano realmente interoperabili soltanto perché riescono a scambiarsi un file.
Devono poter comprendere, con sufficiente precisione, ciò che stanno scambiando.
Che cosa significa questa categoria?
A che cosa si riferisce questa fonte?
Che tipo di collegamento è questo?
Quando è stata verificata questa informazione?
Quale identificatore sto utilizzando?
Quali condizioni si applicano al riuso?
Sono domande semantiche prima ancora che informatiche.
Per questo Open Data, API, modello dei dati, tassonomie, documentazione e fonti non sono pezzi separati del progetto.
Sono parti dello stesso problema.
La conoscenza può lasciare GiraSalerno
Arriviamo così al risultato che volevamo verificare.
Un Punto di interesse inserito in GiraSalerno non deve necessariamente rimanere dentro GiraSalerno.
La sua conoscenza strutturata può essere utilizzata per generare una pagina, alimentare una mappa, partecipare a una ricerca e, attraverso le interfacce pubbliche, essere utilizzata anche altrove.
È un passaggio fondamentale per Salerno Turismo Aperto.
Perché un'infrastruttura pubblica della conoscenza turistica non dovrebbe chiedere:
“Come facciamo a portare tutti dentro il nostro portale?”
Dovrebbe chiedere anche:
“Come facciamo a permettere alla conoscenza di arrivare dove può essere utile?”
È questa la differenza tra costruire un contenitore e costruire un'infrastruttura.
E quando i dati strutturati incontrano la dimensione geografica, da questa infrastruttura possono nascere servizi immediatamente comprensibili anche a chi non sa nulla di database, JSON o API.
È ciò che vedremo nel prossimo capitolo.