Con le API, il dato come servizio

Oggi parliamo di “dato come servizio” (Daas, Data as a Service) e lo facciamo attraverso un esempio prendendo in considerazione i dati cosiddetti “in tempo reale”, dati cioè che cambiano continuamente nel tempo. Come esempio prendiamo i dati relativi alla infomobilità cittadina. Tutti immagino abbiamo avuto l’esperienza di aspettare un autobus del trasporto pubblico urbano e vedere segnalati sulla palina i minuti che dobbiamo ancora attendere prima di vederlo arrivare. Questo è un esempio di dato “in tempo reale”. Quando questo servizio viene fornito, gli autobus sono attrezzati in maniera tale da segnalare ad ogni istante la loro posizione sul percorso previsto, consentendo di calcolare il tempo necessario per poter raggiungere la fermata in questione.

La palina “intelligente” che troviamo alla fermata dell’autobus riesce ad accedere e visualizzare il dato in quanto è uno degli elementi del sistema informativo cittadino di infomobilità. In altre parole sulla palina viene visualizzato un dato che non è pubblico ma è disponibile soltanto all’interno del sistema di monitoraggio delle linee di trasporto urbane. Supponiamo però il comune attraverso l’azienda dei trasporti voglia rilasciare pubblicamente questo dato come Open Data. Il dato è “live”, cambia ad ogni istante di tempo sulla base della posizione dei vari bus nella città. Proprio il tipo di dato che può essere rilasciato soltanto sotto forma di servizio.

Ci sono vari modi per poterlo fare. Uno di questi è attraverso quelle che vengono chiamate API Rest.

API sta per Application Programming Interface, sono delle “interfacce” a cui è possibile connettersi per accedere ai dati. Di fatto si tratta di un URL a cui è possibile “passare” una serie di parametri. L’URL non restituisce però una pagina web bensì un file di dati in un formato adatto ad essere letto da programmi software. In altre parole, utilizzando questo URL all’interno di una applicazione, il dato richiesto verrà scaricato ogni volta che l’applicazione viene utilizzata. Il dato che diventa così servizio e diventa servizio on-demand.

Ovviamente questo non è un concetto dell’ultim’ora, ma è negli ultimi tempi che è cresciuta l’importanza che i servizi web stanno avendo nelle modalità di rilascio e diffusione dei dati. Il comune di Roma e il comune di Bari già lo stanno facendo proprio su infomobilità. (Qui ad esempio l’api che mostra i bus in arrivo in questo momento alla palina numero 081290 a Bari. Se usate Chrome o Firefox potete installare l’add-on JSONView per capire meglio la struttura del dato)

Le API consentono quindi di connettere le applicazioni ai dati. E funzionano molto bene anche per dati non in tempo reale. In questo caso le api funzioneranno in modalità asincrona. Il dato cambia ad un dato istante ma l’api mostra il dato aggiornato dopo un tot di tempo. L’importante però è che i dati cambiano nel tempo. Quando i dati cambiano, l’applicazione che li utilizza si troverà in modo del tutto automatico con i nuovi dati.

E’ quello che accade ad esempio con il portale dati.gov.it, il metacatalogo dei dataset pubblicati come Open Data dalle Pubbliche Amministrazioni centrali e dagli Enti Locali. Gli enti che pubblicano il loro catalogo su una piattaforma CKAN/DKAN (es dati.lazio.it) espongono di default le api native della piattaforma stessa. Ad esempio, la lista dei dataset pubblicati su dati.lazio.it viene fuori da una chiamata di questo tipo http://dati.lazio.it/catalog/api/3/action/package_list.

Altri enti produttori di dati che utilizzano un loro sistema di diffusione dati ne hanno sviluppate di proprie, come ad esempio Inps oppure Istat, che attraverso il seguente url fornisce la lista dei dataset pubblicati su dati.istat.it

Queste API non forniscono dati “veri” bensì alcune metainformazioni relative ai singoli dataset pubblicati dall’Ente. Queste metainformazioni venivano raccolte in modo automatico dal portale Open Data nazionale dati.gov.it per mantenere aggiornato il proprio metacatalogo. Ho detto “venivano” in quanto al momento questa operazione è ferma sia perchè in attesa dell’attivazione della procedura sulla nuova versione di dati.gov.it ma anche a causa del rilascio da parte di Agid del vocabolario DCAT-AP-IT, versione italiana del vocabolario DCAT-AP a cui i vari portali Open Data dovranno adeguarsi. Fare in modo che i singoli portali Open Data parlino la stessa lingua nel trasmettere automaticamente i propri contenuti diventa infatti essenziale per il mantenimento del portale Open Data nazionale ed europeo.

E dove non arriva ancora la Pubblica Amministrazione, ci pensano gli hacker civici. OpenPuglia raccoglie ogni giorno i dati relativi al monitoraggio della qualità dell’aria pubblicati da ArpaPuglia. Sono dati relativi a tutti gli inquinanti monitorati giornalmente da tutte le centraline della rete regionale che vengono raccolti automaticamente da uno scraper e consolidati all’interno di un database OpenPuglia. ArpaPuglia non rilascia Api, che sono state invece costruite a loro insaputa proprio per permettere di accedere facilmente ai dati contenuti nel database. In questo esempio l’Api che restituisce i valori medi giornalieri di PM10 rilevati da tutte le centraline del comune di Taranto negli ultimi 300 giorni. I dati restituiti possono essere ovviamente visualizzati, cosa che abbiamo fatto attraverso questo widget. Le Api, tra le altre cose, consentono di mantenere separata la parte di acquisizione dati dal loro utilizzo. Chiunque, utilizzando la stessa API e quindi gli stessi dati può infatti costruirsi la sua propria visualizzazione. E’ inutile dire che i parametri sull’url sono modificabili. Se al posto di Taranto ci scrivo Lecce avrò l’andamento del PM10 per tutte le centraline di Lecce. Se al posto di PM10 ci scrivo PM2.5 avrò l’andamento del PM2.5 e così via. Dovrò decidermi a scrivere l’help delle API in modo da dare una volta per tutte le indicazioni necessarie per un corretto utilizzo.

Per concludere: le API non hanno senso se dietro non c’è un processo di aggiornamento costante del dato. Non ha senso pubblicare un dataset, renderlo accessibile attraverso API e poi quel dataset resta immutabile nel tempo. Ancora una volta quello che conta sono i processi interni alla pubblica amministrazione che generano quel dato. Mettere in piedi processi di qualità che non solo rilasciano dataset ma fanno soprattutto manutenzione costante dei dataset pubblicati è quello che serve veramente.