La piattaforma Data Analytics Framework, o DAF, a differenza di altri progetti, è stata realizzata da zero dal Team Digitale, fin dalla concezione. Il fronte dei dati per la pubblica amministrazione è stato quindi quello dove il Team è potuto intervenire senza eredità dal passato.
E’ quindi di particolare rilievo analizzare il DAF in questi che sono giorni di bilancio per il Team per la Trasformazione Digitale, l’organo di commissariamento – appena rinnovato di un anno, ma in attesa di un nuovo Commissario – voluto dal governo Renzi (coerentemente con le sue visioni decisioniste), per dare impulso all’innovazione digitale nel paese.
Piattaforme abilitanti (come ad esempio il sistema di pagamenti verso la PA, PagoPA, o quello per l’identità digitale, SPID) e varie linee guida per rendere, tra l’altro, mobile friendly la PA sono alcuni degli altri obiettivi a cui ha lavorato e ancora lavora il Team.
La piattaforma Data Analytics Framework
Premetto subito che farò una disamina piuttosto soggettiva, da informatico che proviene da una lunga esperienza con un particolare dominio di gestione dati, quello dei dati scientifici e biologici, e che ha seguito per passione, quindi compatibilmente con altri impegni, il lavoro del Team sui dati e ne ha recentemente studiato la relativa piattaforma. In altre parole, posso valutare le cose con l’ottica di utente consumatore di dati, esperto nei dati consumati e relative tecnologie, ma non esperto di DAF e connessi, come chi ha potuto seguirne gli sviluppi da più vicino. In più, come si vedrà, sono un utente con specifiche esigenze di modellazione semantica ed interoperabilità, cose su cui le PA, italiana e non, sono ancora indietro rispetto ad altri settori.
Piattaforma DAF, cos’è e come si usa
Il DAF risponde all’importante esigenza per ogni paese di dotarsi di una strategia e di strumenti concreti per raccogliere e condividere dati aperti e pubblici. Fin dallo schema generale della piattaforma, si capisce che è un progetto molto orientato ai big data, in cui grandi quantità di dati, potenzialmente eterogenei per formato e struttura, possono essere stoccate in ciò che anche la documentazione del Team chiama data lake. Per fare questo, anche il DAF impiega una serie di tecnologie recenti, quali Hadoop/HDFS, per distribuire tenere file di dati in un sistema distribuito basato su architettura cloud, sistemi altrettanto distribuiti di elaborazione dati (es, Spark) e di accesso di base ad essi (es, Hive). La piattaforma mette a disposizione strumenti moderni e in questo momento molto popolari anche a livello più astratto, ovvero quello dedicato agli utenti consumatori di dati, compresi quelli meno tecnici. Un data portal consente all’utente di popolare il proprio profilo con dati di interesse, pescati dal DAF. I dati sono ricercabili con i classici metodi basati su parole chiave, tag e attributi, con le interfacce del ben noto software CKAN, usato per costruire portali di dati, orientato all’idea di dati come insieme di file. CKAN è appunto integrato col DAF stesso, ed inoltre dalla piattaforma si possono seguire i link verso il sito web dell’amministrazione di provenienza.
In queste funzionalità gioca un ruolo chiave il lavoro, fatto soprattutto da AgID, per adottare un formato comune, il cosiddetto DCAT (e la sua versione italiana), nel descrivere le caratteristiche generali di un data set e dei file che lo compongono. Per gli utenti più avanzati, dal Data Portal si può accedere ad applicazioni come Metabase, che consente di recuperare dati con un linguaggio simile ad SQL. Inoltre, si possono fare analisi attraverso l’applicazione Jupyter, col metodo che, in tempi di storytelling, viene appunto chiamato delle storie, in pratica, documenti dinamici, nei quali il testo in linguaggio naturale si alterna a piccoli programmi (è molto usato Python) che recuperano dati dal DAF, li elaborano e preparano risultati come istogrammi e altri grafici, anche questi inseribili in un documento-storia, e tutto è aggiornabile dinamicamente quando vengono aggiornati i dati sottostanti. Questa parte del DAF purtroppo non è ancora accessibile a tutti, ma i primi esempi sono promettenti.
Infine, per l’utente più geek, l’architettura prevede accessi programmatici a data set e dati, come ormai consuetudine, attraverso il metodo delle API basate su tecnologia web (e sul formato JSON).
Pro e contro della Data & analytics framework
Quanto descritto fin qui è piuttosto positivo, se lo considera di per sé, come una serie di semi per fare passi avanti nella disponibilità di dati aperti nella pubblica amministrazione italiana, e non come la panacea di problemi molto più ampi, che non sono soltanto tecnici. Il DAF appare già fin d’ora a disposizione delle amministrazioni meglio attrezzate sulla gestione dei dati aperti (es., ISTAT, regioni come Lombardia o Trentino), come soluzione installabile più ricca di sistemi quali CKAN (tra l’altro, DAF è installabile via Docker, un altro recente metodo di deployment del software molto popolare nei sistemi cloud e in ambito big data).
Per il resto, restano aperte questioni alle quali, come dicevo all’inizio, sono particolarmente interessato io. Provo a spiegarmi meglio su quest’ultimo punto con un esempio concreto. Usando il DAF, ho scaricato un po’ di file che elencano opere d’arte disponibili in varie regioni e siti (il piccolo progetto è su GitHub). Poi ho convertito tutto in linked data, usando Cultural-ON, lo schema/ontologia recentemente pubblicato dal MIBACT, il ministero della cultura. In questo modo, ho ottenuto un deposito uniforme, in cui posso fare giochini su tutti i dati, a prescindere da chi li ha prodotti (ho usato Fuseki, ma ci sono molti strumenti del genere). Ad esempio, questa interrogazione fa un conteggio delle opere per regione, e con i suoi risultati ho potuto ricavare questo istogramma. Un esempio simile è questa mappa. Questo è un esempio molto local, ci sono schemi come schema.org che consentono di ottenere anche vantaggi semantici, ovvero ritrovarsi questi dati ben indicizzati da motori come Google e con visualizzazioni di impatto, grazie all’uso di un linguaggio comune anche al livello del significato dei dati. Per mettere subito le mani avanti con quelli che ‘ma i linked data sono difficili’, il punto non è lavorare direttamente con le cose che ho citato, ma seguirne i principi. Per esempio, fare come hanno fatto per GTFS, che è uno schema per descrivere i trasporti pubblici (se riusciamo a vedere che bus prendere su Google Map, lo dobbiamo anche a questo) interamente basato su CSV, ma non su ‘quattro CSV in croce’ (cit), bensì su schemi predefiniti, studiati a tavolino e proposti ad una intera comunità, a cui, quando serve, si possono aggiungere identificatori comuni (es, codici IPA) e vocabolari/tassonomie (oppure, nei casi avanzati, ontologie), di uso comune (es, il vocabolario di ISTAT Ateco, per classificare le attività economiche).
I dettagli sono importanti
Tutti quelli che si occupano di dati sono ormai consapevoli dell’utilità di questa impostazione, ma è ben più difficile mettersi d’accordo su una serie di dettagli, che purtroppo sono dettagli spesso cruciali: quali schemi condividere, come usarli per standardizzare i dati, come farlo digerire alle masse. Lo stesso Team e l’AgID sanno bene che queste cose sono importanti, e infatti hanno iniziato a farle almeno per i metadati, i descrittori dei data set e dei file (il DCAT citato sopra). Lavoro da cui sono scaturite interessanti informazioni, ma che è quasi letteralmente la punta di un iceberg, sotto ci sono i vari domini applicativi e il merito dei dati stessi. Tanto è vero che sono in corso vari sforzi per produrre ontologie di dominio (significativo è il lavoro iniziato con OntoPiA) e nello stesso DAF è prevista una procedura di annotazione automatica basata su ontologie, codici e vocabolari. Per fare un altro esempio, nel caso culturale illustrato prima, guardando ai dati si capisce che il MIBACT è riuscito a diffondere un tracciato record, riscontrabile nei file di diverse regioni. La notizia meno buona è che questo sembra non avere molto a che fare con la citata Cultural-ON, anche questa promossa dal MIBACT. Sia nel caso di Cultural-ON, che in quello di OntoPiA, abbiamo visto iniziare ad applicare un metodo di lavoro che, per il contesto della pubblica amministrazione, è stata una piccola rivoluzione, comprendente la condivisione di codici e documenti con strumenti quali GitHub o ReadTheDocs, anche se, secondo la mia personale opinione, i successi sperati sono stati variabili, per una serie di oggettive difficoltà.
Per chiarire, questo genere di coinvolgimento richiede molto impegno fin dalle prime fasi di un progetto e spesso richiede un lavoro aperto e ben promosso fin dall’inizio. Iniziare lavorando in un ambito più ristretto, istituzionale, rischia di non ottenere larghi riscontri quando poi ci si rivolge ad una platea più ampia. A questo punto, in cui resta comunque del lavoro da fare con schemi ed ontologie, varrebbe probabilmente la pena dedicarsi di più all’engagement, collaborare con chi produce e usa i dati, organizzare workshop e hackathon per annotarli con le ontologie che si stanno sviluppando, sviluppare strumenti intermedi come template Excel o form web, anche questi basati sulle tali ontologie, costruire applicazioni sopra dati ben annotati ed integrati.
Altri limiti: paniere dinamico e qualità dei dati
Sempre a causa di problematiche ben più ampie di quelle che poteva affrontare il Team, non si può non notare altri limiti dei risultati che hanno prodotto. Ad esempio, un ambizioso obiettivo che è stato definito prima di loro è quello del paniere dinamico, ovvero la lista dei desiderata, un elenco di tipi di dati ritenuti particolarmente utili per vari motivi, di cui si afferma l’interesse e l’impegno alla cura e pubblicazione. La somma di dati che hanno il DAF e il sito www.dati.gov.it risulta in una quantità notevole di dati, ma stando all’ultimo resoconto in merito, quelli interessanti per il paniere sono meno della metà. Tra l’altro, si capisce abbastanza chiaramente che i due sono sistemi abbastanza ridondanti e nel lungo termine bisognerà razionalizzare le cose puntando ad una soluzione unificata, probabilmente basata sul DAF. A questo ci sarebbe da aggiungere qualche considerazione su qualità, completezza e stato di aggiornamento dei dati che si trovano in queste risorse, anche se non fanno parte del paniere. Non conosco analisi sistematiche di questo aspetto, ma una prima occhiata a qualche file a caso non è esattamente incoraggiante. Il che, senza voler far polemiche, mi fa chiedere se, in questa situazione, la priorità doveva essere quella del contenitore, una moderna struttura orientata ai big data, o se non si dovesse quantomeno mettere più energie anche nei contenuti, nonché nella sensibilità generale per queste cose. Perlomeno, come detto, questo è il mio punto di vista di consumatore dei dati, è ben possibile che lo sviluppo della piattaforma sia stato suggerito dalla necessità di adeguare gli strumenti tecnici, anche in relazione all’obiettivo di ridurre la pletora di data center in giro per il regno.
Considerazioni sul futuro
In ogni caso, nel complesso il Team ha fatto un lavoro apprezzabile e, cosa non scontata in Italia, si è confermata l’eccellenza tecnica delle persone chiamate a farne parte, e lo dice uno che è tuttora critico verso il metodo del commissariamento e il contesto politico in cui questa esperienza è nata. Un lavoro di semina e di prototipazione, non per questo poco significativo, anzi. Ma ora che proprio il contesto politico è completamente cambiato, il rischio maggiore è che i semi non crescano e si finisca per disperdere i risultati positivi raggiunti, un problema già visto altre volte e, pensando a qualche progetto IT finanziato con i Programmi Quadro, non solo in Italia. Una prima cosa che si potrebbe fare per scongiurare questo rischio è approfittare della natura aperta del lavoro fatto e rendersi più indipendenti dai piani alti, adottando un punto di vista pragmatico sulle cose che sono utili in ogni caso, e considerare sia aspetti concreti come codici e documentazione, che le esperienze di collaborazione innescate, un patrimonio a disposizione di tutti i livelli della pubblica amministrazione, come pure di privati e comunità di civic hacker. Un’altra cosa possibile, per quanto riguarda i dati, è ripartire dalle criticità che ho qui cercato di illustrare. Ad esempio, oltre a quanto detto sopra sulle ontologie, iniziare a pubblicare una serie di script di conversione di dati pubblici di interesse verso schemi/ontologie comuni è un’operazione che non ha bisogno di grandi spinte strategiche ed istituzionali, e, allo stesso tempo, verrebbe ancora meglio se nella PA ci si sta già muovendo in modo simile.
Ringraziamenti
Un sentito grazie va a Giorgia Lodi, sia per il lavoro fatto di cui ho parlato, sia per gli utili suggerimenti dati, anche pubblicamente, alle questioni che gli ho posto durante la preparazione di questo testo.
