Open Data, tutta colpa di un “not available”

Ogni tanto nel mondo digitale ci sono dei temi caldi che catalizzano l’attenzione degli addetti ai lavori che poi però scompaiono dalle scene magicamente, così come magicamente c’erano arrivati. Sembra che il tema degli Open Data sia tra questi, in netta flessione; qualche annetto fa era uno dei temi caldi nazionali, ma ora appare un po’ più marginale, forse a causa di modelli di business ipotetici che poi non si sono materializzati a sufficienza.

Eppure di cose di cui parlare ce ne sarebbero. Andiamo per gradi.

Quello che qui si descrive è un approccio ai dati meno teorico, anche poco profetico, per concentrare l’attenzione sullo stereotipo per eccellenza: quello del mettere l’utente al centro, azione promessa da sviluppatori, politici, strateghi in genere di cui spesso si fatica a estrarne il vero significato.

Il compito di professionisti che, come me, si occupano di Accessibilità, Standard per il web, UserExperience, Strategie Digitali in genere, non è quello di supportare le pubbliche amministrazioni (e anche le aziende) nei processi di apertura dei propri dati, né quello di stabilire modalità e forme in cui ciò debba avvenire. Lo sguardo sul mondo digitale parte sempre da punti di vista propri che sono la base di processo, la strategia, con cui una specifica attività digitale può essere interessante per l’utente. Capire come queste attività possano essere implementate in processi di business o in utility che l’utente possa percepire come risorse utilizzabili è ciò che siamo chiamati a fare giornalmente.

Insomma, i dati sono determinanti perché possono, anzi sono, la base strutturale su cui un servizio web, o un’applicazione per il mobile, può essere pensato o sviluppato. Ciò che serve è capire quale sia l’esigenza che un utente può avere, e nel contempo individuare le modalità con cui fornirgli un adeguato servizio. L’obiettivo è quello di creare un ambiente che fornisca il massimo della potenzialità e dell’efficienza, in modo che l’esperienza d’uso possa essere la migliore possibile. È inutile che un’applicazione abbia una UX eccezionale se poi la base dati su cui poggia non fornisce certezza di contenuto o, peggio ancora, fornisce dati non affidabili. L’esperienza che l’utente potrà avere in quell’ambiente sarà sicuramente non ottimale.

Dati e metadati

Esistono due livelli di inefficienza del dato, quelli riferibili ai metadati e quella ai dati in se. Sono ragionamenti molto diversi ma strettamente correlati, proviamo a distinguerli per fare più chiarezza utilizzando un caso reale per cercare di delineare meglio il problema.

Nei giorni scorsi con alcuni colleghi si progettava un’applicazione web per la fornitura di servizi turistici legati alle attività ricettive regionali. Il nostro modello di business era supportato proprio da una base dati aperta della Regione Umbria che meritoriamente ha aperto, seppure parzialmente, i propri dati mettendoli a disposizione su un apposito progetto web.

Il progetto completo avrebbe dovuto fornire un servizio abbastanza semplice ma efficace e intuitivo, per guidare l’utente tra storia e servizi di accoglienza. Il committente voleva un servizio di base ma di facilissimo uso ed efficiente, ma l’intero impianto ha necessitato di un ripensamento a causa di diverse problematiche a carico dei dati che si sarebbero voluto utilizzare.

L’inefficienza dei dati

In primo luogo chi utilizza i dati per manipolarli e crearne utilità o servizi, deve poter essere certo che il dato che sta utilizzando sia valido e aggiornato. E fin qui può sembrare tutto semplice perché basta fidarsi di chi pubblica i dati. Anni fa si parlava di “filiera della fiducia” nella progettazione per il web. Questo assunto ne fa parte, anche perché chi utilizza dei dati rilasciati da terzi non ha quasi mai la possibilità di verificarne la bontà.
In questi anni di utilizzo professionale di dati si è rilevato però un andamento un po’ preoccupante. Spesso si intuisce un pensiero non rassicurante, alla base dell’apertura del dato, ovvero: “ok, sono stati rilasciati dati liberi e gratis, pretendete pure che siano perfetti?”.
Insomma, una libera interpretazione molto al ribasso dello spirito di base degli Open Data: “aprire i dati, meglio pochi e in forma embrionale che niente”.

In qualche caso però, prima di fare affidamento alla fiducia e con un po’ di esperienza, è possibile analizzare un dataset per rilevarne sommariamente le qualità e talvolta i risultati non sono incoraggianti.

Per esempio, ai dataset di cui parlavo poco sopra, si era data piena fiducia, sembravano completi e adatti allo scopo, fino a quando analizzando nel dettaglio alcuni test preliminari, ci siamo accorti che uno dei campi era talvolta valorizzato da informazioni sul periodo di chiusura della struttura selezionata, indicante archi temporali vecchi di un anno. Provate a immaginare un’applicazione che, utilizzando tali dati, vi avesse comunicato che l’albergo da voi scelto fosse stato chiuso a natale di due anni prima. Probabilmente avreste pensato di utilizzare a un’applicazione poco affidabile, perché ovviamente l’utente non ha modo di capire come sono fatte le applicazioni, su cosa si basano, come fanno a funzionare.

Ma le insidie nei dati sono anche molto particolari: cosa può significare quando in un dataset come questo (strutture ricettive) manca un campo, per esempio l’email? Che la struttura non ha un indirizzo email? Decisamente poco verosimile nel settore specifico, ancora più inverosimile se il campo precedente contenente l’indirizzo web è valorizzato da una URL valida: si deve desumere che la struttura, pur avendo un proprio sito internet non utilizza una email? L’analisi si complica, quando il campo URL è valorizzato da un dominio proprietario (www.miaazienda.est) e il campo email da un indirizzo email fornito da un provider che offre free email (es. [email protected]), cosa si deve desumere? Che la struttura pur avendo un dominio proprietario preferisce utilizzare un altro indirizzo email? Oppure magari che il dato non è del tutto aggiornato e si riferisce a un vecchio indirizzo email? Se per questo tipo di dati il campanello d’allarme sulla qualità suona attraverso queste valutazioni empiriche, come ci si potrà fidare di altri dati per i quali non si ha alcuna possibilità di valutazione, come denominazioni, indirizzi, telefoni, numeri civici ecc.

L’inefficienza dei metadati

Le considerazioni relative ai metadati sono ancora più importanti. I metadati sono un set di informazioni che descrivono i dati rilasciati. Descrivono chi li ha rilasciati, quando, con quale licenza, i riferimenti geografici e altre cose. In questo elenco di metadati ce ne sono alcuni di particolare importanza ai quali si lega tutto il ragionamento fatto fin qui.

Analizziamone uno: la frequenza di aggiornamento. La frequenza di aggiornamento è un dato determinante per rendere un dataset utilizzabile in applicazioni reali ed efficienti. Riferendoci sempre all’esempio fatto in precedenza, il dataset non è supportato da questo dato, appunto Not Available. Se poi alla mancanza del dato sulla frequenza di aggiornamento si associa il dato riferibile alla data di pubblicazione del dataset, scoprendo che i dati sono stati pubblicati un anno e mezzo prima, si arriva alla considerazione finale che quei metadati ci dicono che di fatto quei dati sono inutilizzabili, perché è impensabile che tali informazioni così datate non abbia avuto bisogno di essere aggiornate e che, oltretutto, non sia previsto un aggiornamento costante nel tempo.

Basta quindi un unico elemento di cui non si è presa piena consapevolezza per rendere un set di dati inutile, o comunque non adatto come base di lavoro per la creazione di servizi di vera utilità per l’utente finale.

I dati sono infrastrutture

Si è parlato tanto di creare processi di apertura dei dati per la PA per favorire la nascita di progetti di business o di utility, soprattutto nel settore turistico, soprattutto in regioni come l’Umbria dove il turismo è (o vorrebbe essere) il core dello sviluppo futuro.
Ma quale investimento si può fare su prodotti o servizi se non si ha la certezza assoluta che il dato usato come base strutturale è di qualità, completo, utilizzabile e soprattutto duraturo nel tempo?

I dati aperti sono una infrastruttura e non un servizio. Per creare servizi servono infrastrutture solide, efficienti e con programmi di manutenzione e aggiornamento certi e dichiarati.

Non dico che l’intero sistema di pubblicazione dei dati sia coinvolto nelle problematiche che descritte fino ad ora. Magari la maggior parte dei dati pubblicati è di qualità e prevede forme di mantenimento adeguate. Il problema è che spesso non abbiamo alcuna possibilità di valutare la bontà dei dati, e nessuna applicazione pratica potrà fornire esperienze significative se sarà minata alla base da una base dati problematica.
È per questo che molto spesso le applicazioni, seppure nate sotto l’insegna de “l’utente al centro”, diventano fine a se stesse e al centro ci rimangono soltanto le potenzialità non espresse.

Non è facile capire di chi sia “la colpa” di queste inefficienze, dei titolari dei dati, delle varie fasi di raccolta ed elaborazione, dei processi che poi portano ai vari portali Open Data, delle strategie generali che stanno a monte. Fatto sta che quello che manca è proprio la filiera della fiducia in tutto questo processo.

Non tutto è perduto

Ci sono però iniziative molto importanti che meritano di avere più spazi di visibilità e più utilizzazioni. Esiste per esempio una norma sulla qualità dei dati, che è diventata uno standard internazionale

Se si volesse davvero procedere con la pubblicazione di dati di qualità basterebbe richiedere a ISO tale norma e procedere con una applicazione della norma stessa. La domanda “come faccio a pubblicare dati di qualità?” ha quindi una risposta certa, o almeno una traccia certa da poter seguire.

Anche sul fronte dei metadati ci sono cose importanti, anche se ancora in corso d’opera. Un gruppo di lavoro in Agenzia per l’Italia Digitale sta mettendo in piedi un profilo che descrive con quali metadati dovranno essere pubblicati i dataset. Il lavoro è ancora in fase di pre-pubblicazione ed è prevista per metà gennaio 2016 la fase di consultazione pubblica durante la quale si potranno fare commenti e proporre modifiche. Chiaramente, i metadati relativi alla frequenza di aggiornamento dei dati di cui abbiamo parlato prima è previsto come campo obbligatorio.

Insomma, parlare di applicazioni “che mettono al centro l’utente” non è una questione di grafica né soltanto di comportamenti. È un discorso ben più complesso che parte proprio dai dati che vengono usati per creare le applicazioni.

Aggiornamento: in data 28 gennaio 2016 è stata aperta la preannunciata fase di consultazione pubblica sul profilo italiano dei metadati per i dati pubblici. Tutti i dettagli sono disponibili a questo link.