TECH | 25 Lug

Gli Open Data non bastano

Quali le migliori strategie per le Pubbliche Amministrazioni di apertura dei dati?

Sempre più spesso si sente parlare di Open Data come di elementi centrali per guidare l’innovazione e la trasparenza nella Pubblica Amministrazione. È verissimo: gli Open Data sono uno strumento formidabile per consentire alla cittadinanza di accedere a informazioni pubbliche in modo nuovo e attraverso app e piattaforme software realizzate da terze parti. Sono un eccezionale strumento, certamente necessario per raggiungere questi obiettivi, ma sfortunatamente non sufficiente.

Gli Open Data non bastano, fatevene una ragione

Gli Open Data non bastano perché quasi sempre si tratta di dati grezzi, pubblicati sotto forma di file (in formato CSV, quando va bene) che possono essere scaricati dal cittadino o dal programmatore per farci qualcosa.

Il cittadino che scarica un file CSV nel 99% dei casi lo aprirà con Excel per accedere direttamente all’informazione di cui ha bisogno, in questo caso allora sarebbe meglio fare una pagina web dedicata, magari alimentata dalla stessa fonte dati che ha generato il file CSV: meno complicazioni e più facilità nell’accedere all’informazione utile, con la possibilità di indicizzare e inserire link e immagini.

Il programmatore che scarica un file CSV lo fa perché quei dati serviranno ad una sua applicazione, sia essa un’app che analizza il rendiconto finanziario di un ente pubblico, o un sistema complesso che mette a disposizione musei e beni architettonici, o una mappa con l’elenco dei defibrillatori presenti su un territorio, o un servizio di allerta meteo basato su dati meteorologici in tempo reale. Per fortuna i dataset (le fonti dati) messi a disposizione dagli enti pubblici sono tantissimi e molte di più sono le possibili applicazioni che è possibile realizzare partendo da quei dati.

Il problema è che quel programmatore non potrà concentrarsi solo sulle funzionalità della sua applicazione, ma, al contrario, dovrà preoccuparsi di creare un apposito database, di caricarci sopra i dati provenienti dai diversi file CSV, magari scaricati da più enti pubblici diversi, dovrà preoccuparsi di garantire l’aggiornamento di quei dati monitorando costantemente gli enti di provenienza per verificare se esistono variazioni, correzioni o nuove versioni dei dataset stessi, nuove versioni che dovranno essere caricate e gestite ex novo.

Questo modello è superato e deve essere superato

Ne scrivevo già in questo articolo dell’Aprile 2012 su Nova 100: è il momento (anzi, era il momento, ma pazienza) di passare dalla logica Open Data a quella Open Services, dal modello “scarica e usa” al modello API (Application Programming Interface) che consente alle applicazioni di accedere direttamente ai dati, in real time, sui sistemi di provenienza.

Questo si può ottenere seguendo due strategie differenti ed alcuni semplici passi:

Strategia 1: realizzazione in casa di una infrastruttura Open Services

Smettere di produrre file CSV. Della coppia Open Data, la parola più difficile da accettare culturalmente è Open, ma una volta che un ente è entrato nell’ottica di mettere alcuni dati a disposizione della cittadinanza, il più è fatto. A questo punto la cosa da fare è NON realizzare tanti magnifici file CSV e di conseguenza NON pubblicarli in un’apposita sezione del portale dell’ente, ma procedere con il prossimo punto.

Esporre i dati utilizzando uno strato software di servizi ed API. Il programmatore vuole servizi per accedere ai dati, API sicure e certificate, formati e protocolli standard, in due parole: integrazione ed interoperabilità. Potendo accedere alle informazioni tramite servizi ed API, il programmatore non dovrà sobbarcarsi l’onere di creare, gestire e aggiornare un database completo contenente dati provenienti da fonti diverse, a volte da enti diversi e magari in formati diversi, ma potrà concentrarsi sulle funzionalità della sua applicazione. Il file CSV in questo caso sarà sempre e comunque disponibile, ma non come file fisico presente sui server dell’amministrazione, bensì come uno dei (tanti) formati in cui sarà possibile esportare i dati dei singoli dataset, magari precedentemente filtrati, ordinati o aggregati in funzione delle necessità.

Strategia 2: utilizzo di un’infrastruttura Open Services esistente

Quando l’ente non ha intenzione di dotarsi di una propria infrastruttura Open Services, esiste l’alternativa di affidarsi a una piattaforma esterna, dedicata e già pronta, come per esempio l’americana Data.World, focalizzata sull’obiettivo di diventare il più grande hub mondiale per la raccolta di dati di tipo pubblico e privato, oppure l’italianissima OpenRecordz, più orientata al concetto di Open Data come strumento per la realizzazione di una vera e propria smart city.
Con una piattaforma di questo tipo è possibile creare il proprio personale repository per i dati, come fa Data.World, oppure creare la propria Smart City, come fa OpenRecordz, definendo, pubblicando e popolando i propri dataset per poi poterli utilizzare con le applicazioni attraverso apposite API standard. OpenRecordz per esempio consente l’accesso diretto ai dati utilizzando API REST e con lo scambio dati in JSON, Data.World consente invece l’integrazione diretta con strumenti di BI e cruscotti.

Quali i vantaggi di Strategia 2?

Sarà più facile, per l’ente pubblico, liberare i dati sotto forma di Open Data. Non ci sarà più la necessità di preparare i file CSV, censirli, pubblicarli su un’apposita pagina del sito dell’ente e garantirne l’aggiornamento nel tempo. Se l’utente finale avrà la necessità di utilizzare i CSV, li troverà comunque tra i numerosi formati in cui sarà possibile esportare i singoli dataset.

Sarà più semplice realizzare applicazioni che utilizzino gli Open Data. Programmatori, start-up, PMI, grandi aziende che abbiano voglia di realizzare applicazioni di varia natura utilizzando gli Open Data, non dovranno fare altro che pensare alla propria applicazione, senza doversi curare degli aspetti tecnici legati alla gestione e all’aggiornamento degli Open Data.

Dati sempre aggiornati. I dati “liberati” dagli enti pubblici saranno sempre e costantemente aggiornati in modo automatico, non sarà necessario procedere ad aggiornamenti manuali dei flussi dati, né passare per formati fisici intermedi. In alcuni casi potrebbe essere necessario realizzare apposite funzionalità di allineamento per aggiornare i dati presenti su piattaforme Open Services di terze parti. Le applicazioni che li utilizzeranno non dovranno più preoccuparsi di quale sia il livello di aggiornamento dei dati, avendo la certezza che siano sempre aggiornati.

Controllo dell’utilizzo da parte dell’ente. Gli enti che lo vorranno potranno consentire l’accesso agli Open Services attraverso un’apposita chiave di accesso, simile a quella utilizzata per le applicazioni che vivono negli ecosistemi Facebook e Twitter. L’utilizzo di questo “accesso controllato” potrebbe essere utilissimo per capire quale applicazione esterna sta utilizzando i dati, quanto e come.

Open Data collaborativi. Spesso l’informazione contenuta in un record di un dataset Open Data non è sufficiente per gli utilizzi particolari di alcune applicazioni. In questi casi il problema è a monte e dipende dal fatto che, semplicemente, l’ente da cui quel dato proviene quelle informazioni non le ha.

Si tratta però di informazioni che potrebbero fare la differenza tra un dato utile ed uno utilissimo. In questi casi spesso le applicazioni che usano Open Data si preoccupano di arricchire il database inserendo altre informazioni provenienti da fonti esterne, oppure chiedendo agli utenti di arricchire quel dato con informazioni aggiuntive. Applicando questo modello, un ente potrebbe consentire ad API non solo di leggere il dato, ma anche di aggiungervi informazioni.

Si tratterebbe di informazioni non provenienti direttamente dall’ente, e quindi, in un certo senso, non certificate. Spesso però è meglio avere informazioni non certificate piuttosto che non avere alcuna informazione.

Un esempio di questa funzionalità? Tra i dataset rilasciati da alcuni comuni, spesso c’è la lista dei defibrillatori presenti sul territorio, accompagnata dalle coordinate geografiche e dal luogo nel quale tali defibrillatori si trovano. Provate a pensare di avere la necessità di un defibrillatore, recarvi nel luogo in cui questo dovrebbe essere e scoprire che è rotto, non è più disponibile oppure è lì in bella vista, ma il locale che lo gestisce è chiuso e voi non lo sapevate, e non sapete nemmeno chi contattare per farvi aprire le porte per prendere il defibrillatore e magari salvare una vita. Consentire all’utenza, che usa questi servizi, la possibilità di inserire informazioni aggiuntive come la disponibilità o meno del defibrillatore, gli orari di apertura, un contatto da utilizzare, permette l’arricchimento della base dati di partenza e questi dati saranno disponibili anche a tutte le altre applicazioni che utilizzino quel particolare dataset, il tutto senza spendere un solo euro di soldi pubblici ed eventualmente garantendo la qualità della base dati attraverso strumenti di versionamento del dato che consentano, in caso di vandalismo o di modifica incauta, il ripristino del dato corretto, il tutto in modo totalmente trasparente per le applicazioni che utilizzano quel dato.

Ecco perché gli Open Data non bastano: è necessario iniziare a ragionare in termini di Open Services e di interoperabilità; questo faciliterà la produzione dei dati stessi da parte dell’amministrazione pubblica e fornirà nuovi e più moderni strumenti che consentiranno di realizzare applicazioni di sicura utilità per la cittadinanza

Massimo Canducci