Sfrutto questo post per approfondire alcuni elementi della sessione che ho tenuto qualche settimana fa a SOD19 (visto che anche Erika ha condiviso i suoi materiali). Avevo cominciato a riflettere su queste cose con il post chedati.(g0v).it  -  come gestire la domanda di Open Data nel 2019? che, da qui in poi, darò per scontato sia stato letto.

Cosa è emerso in lista SOD in merito alla domanda di dati prima del mio intervento

Ho condiviso in mailing-list il post su chedati.(g0v).it qualche giorno prima del raduno ed è emerso uno spunto di riflessione che vale la pena riprendere. Sto parlando del requestathon. Alfredo Serafini mi ha ricordato che una delle proposte di hackathon per SOD19 ipotizzate ad ottobre scorso era proprio il requestathon, ovvero un hackathon per lavorare in maniera specifica sulle richieste di dati. La cosa non è poi andata in porto, ma è uno spunto utile da cui partire. Alfredo l’aveva sepolto in un p.s. di una discussione (il grassetto è mio):

sarebbe carino rilanciare la community con una specie di “requestathon” :-) Cioè creare dei gruppi (apertissimi ai non tecnici) per ribaltare la chiave di lettura che ultimamente va di moda: invece che partire dal dataset (di solito un unico tabellone megagalattico, tipicamente ben poco utile al di là dei soliti giocattoloni visti 50 volte) e fare le analisi fiche, proviamo a raccogliere le richieste degli utenti e creiamo la mappa dei puntini da collegare per ottenere alcuni obiettivi dichiarati.

Nel commento di questi giorni ha integrato, chiarendo maggiormente quello che intendeva:

Manca a mio avviso tutt’ora una “mappa” in evoluzione delle richieste di varie tipologie di utenti (cittadini, imprese, PA, analisti, etc), tale da rendere possibile una individuazione dei gap, per orientare sia la produzione che il riuso mirato dei dati. Credo che averla consentirebbe anche un certo risparmio di risorse, che potrebbero essere più proficuamente destinate a cose di cui sia più semplice verificare l’efficacia.

Cercando il termine requestathon in lista, ho trovato un rilancio di Guido Romeo del settembre 2012 sotto forma di proposta di hackathon per il decennale della giornata mondiale per il diritto di accesso all’informazione. Si trattava di un periodo storico diverso, ma non troppo. Avevamo meno possibilità normative di accesso rispetto ad oggi e anche meno Open Data disponibili, quindi era naturale partire dal favorire la domanda di dati. Un altro risultato lo si trova in un thread sul (mancato) impatto della pubblicazione degli Open Data sulla corruzione di metà settembre 2015, in una risposta di Marco Montanari (il grassetto è mio):

In tutto il nostro (non solo italiano) pontificare sui dati aperti, abbiamo puntato sulle città medio-grandi, sulle regioni, raccontando che qualsiasi cosa pubblicassero sarebbe stato importante (cosa vera, in sé, falsa se si finisce per pubblicare tutto di argomenti interstiziali), ma poi non abbiamo iniziato a spingere con delle vere check-list sui dati puntuali, delle tempistiche di rilascio, dei formati standard minimali, la verifica delle tempistiche, il naming&shaming delle amministrazioni inadempienti ecc… Ad esempio, AGID ha pubblicato i famosi dati promessi? nei tempi? Abbiamo visto l’impatto del non pubblicarli: ZERO.

Vista con gli occhi di oggi, questa critica è assolutamente attuale e sono convinto che vada ripresa, interpretandola con tutto quello che abbiamo imparato nel frattempo.

Cosa ho raccontato a SOD19

Ci sono due slide in particolare su cui vorrei soffermarmi: la prima è relativa ai retroscena dell’idea del servizio (immaginario) chedati.(g0v).it.

L'ecosistema attorno al servizio chedati.(g0v).it

Esplodo alcune di queste parole chiave, nel caso non fossero chiare.

  • Progettazione guidata dai bisogni dell’utente: progettare un servizio simile richiede un’attenzione estrema ai bisogni dell’utente. Non dovrebbe mostrare gli aspetti burocratici, tecnici e tecnologici legati alla richiesta di dati, ma dovrebbe nasconderli il più possibile. Un piccolo esempio da cui prendere spunto è il servizio http://www.foiapop.it che aiuta nella creazione di richieste di accesso civico.
  • Interoperabilità: dal sito di FOIApop possiamo estrapolare un paio di buone prassi (spesso assenti nei servizi gestiti dalla PA italiana). La prima è l’aver integrato dati già a disposizione dei cittadini, la seconda buona prassi è aver sfruttato quei dati per velocizzare la creazione della richiesta di accesso (ossia, l’aspetto centrale del servizio). Mi riferisco, in particolare, ai dati di contatto delle amministrazioni pubbliche: al posto di doverli cercare e inserire manualmente, chi ha progettato il servizio ha pensato che l’utente potesse trovare nel servizio stesso dei suggerimenti a seconda di quello che è stato digitato nella casella di ricerca.

    Un esempio di interoperabilità intelligente nel servizio FOIApop

  • Titolarità degli ambiti e dei dati: se un dato è errato, incompleto o del tutto mancante, abbiamo un problema da risolvere. A chi ci rivolgiamo? Chi è il titolare di quel dato? Se il dato è pubblicato, ad esempio nel portale dei dati aperti italiani (dati.gov.it), uno dei metadati del catalogo ci dovrebbe dire chi è il titolare di quel dato. Ma se è un dataset che dobbiamo chiedere? Si tratta di un’informazione chiave: ci aiuterebbe a fare un’eventuale richiesta di accesso civico. Se chi è titolare dei dati (anche non ancora aperti) fosse un dato disponibile come API o come dataset aggiornato, quel dato potrebbe essere (ri)usato per mostrare gli ambiti dei dataset (salute, ambiente, …) in relazione agli enti presenti nell’indicePA (l’indice dei domicili digitali delle Pubbliche Amministrazioni e dei gestori di pubblici servizi).
  • Seguire il principio della PA come piattaforma abilitante (di cosa sia questo principio, Erika ne ha parlato qualche mese fa). Non è detto che un servizio come chedati.(g0v).it debba essere gestito e sviluppato direttamente da un ente pubblico. È il motivo per cui ho inserito le parentesi tonde e g0v con lo zero (e non con la o). Se ci fosse chiarezza nel legame tra dati e rispettive titolarità, potrebbe essere la società civile, ad esempio una collaborazione pubblico-privata, ad offrirsi per gestire il lato della domanda. Anzi, sarebbe auspicabile. Chiaramente, questo tipo di collaborazione non servirebbe a molto se non venisse poi interpretato e gestito anche da un forte commitment della PA: non sto consigliando un lavoro consulenziale oneroso e poco efficace che non cambia di una virgola le dinamiche delle Amministrazioni Pubbliche.
  • La necessità di essere ‘accountable’ nella gestione delle richieste. In questo caso ci sono molte esperienze da cui prendere spunto, sia come società civile che come amministrazione pubblica. Mi vengono in mente i servizi promossi da mySociety sulla piattaforma software ‘Alavateli’ e i servizi come ‘IRIS’ per il comune di Venezia. L’elemento chiave è la condivisione pubblica e visibile delle richieste, del loro stato e delle eventuali risposte pubbliche. Questa condivisione è importante per almeno due motivi. Da una parte, responsabilizza l’attore che deve rispondere, sia nei tempi che nei contenuti. Dall’altra, riduce la possibilità che più persone ripetano le stesse richieste, perché possono integrare quelle esistenti con altre informazioni o più dettagli. Anche Alberto Cottica - uno dei fondatori di Spaghetti Open Data - ha usato un servizio basato su Alavateli (asktheeu.org) nella richiesta di dati per l’accesso alle proposte di finanziamento H2020 che non sono state approvate.

La seconda slide su cui vorrei soffermarmi è l’ultima, quella sull’open-washing (di open-washing, ne abbiamo parlato nel primo numero della newsletter del 2019 di #CivicHackingIT):

Se non vanno dati i dati è una questione di potere: il resto è open-washing

Vediamo di spiegarla: da un lato, la Pubblica Amministrazione nel 2019 ha interiorizzato la necessità di gestire e pubblicare Open Data, rendendo più burocratico tutto il processo (anche per necessità normative, non solo per volontà delle singole amministrazioni). Il dettaglio del come gestire e pubblicare i dati è nascosto in ennemila risorse (piano triennale, piani di azione di OGP, iniziative guidate dai consulenti, etc…). Dall’altro lato, la società civile è frammentata come non mai su questo tema, complice la difficoltà di uscire dal momento di stallo, dopo la fase di entusiasmo iniziale del movimento italiano.
Tornare a ragionare sulla domanda senza venire fagocitati dai meccanismi amministrativi - che non sono e non dovrebbero essere un onere della società civile - è una delle vie di uscita da questa impasse. L’altra è riconoscere che molte iniziative degli enti pubblici legate agli Open Data sono solo operazioni di facciata, operazioni di open-washing che riducono la percezione del valore associato agli Open Data da parte delle persone che non conoscono l’argomento.
Tornare a chiedere dati che non troviamo e pretendere una maggiore trasparenza quando si tratta di (mancata) pubblicazione dei dati sono soltanto due delle cose da fare. Assieme, però. Le azioni fortemente individuali (come quelle dei soliti noti che, ad esempio, continuano a popolare il canale di forum.italia.it) non sono efficaci. L’abbiamo visto su più fronti. Dobbiamo tornare a muoverci assieme e fare più squadra.

E se ci fosse il portale dei NON DATI degli Open Data italiani?

Durante la discussione a SOD19 sono emersi diversi spunti (grazie soprattutto a Daniele Crespi e a Alessio Cimarelli). I due su cui ci siamo soffermati di più li riporto per continuare il confronto.

  1. Il vantaggio di essere nel 2019 è quello di avere già degli Open Data pubblicati dalle amministrazioni. Una parte dei dati a cui possiamo avere accesso è già chiara, proprio perché ci sono enti che già li pubblicano. Se un ente di pari livello amministrativo non ha pubblicato ancora quel dato, ricordargli che dovrebbe farlo è una questione di pochi istanti (far presente attraverso una richiesta di accesso o un tweet, ad esempio, al proprio comune di residenza che nel comune vicino i dati ci sono potrebbe essere piuttosto efficace). L’impatto potenziale di un’azione del genere è l’aumento della copertura di quel dato (la copertura a macchia di leopardo è una problematica di qualità del dato che ne riduce il potenziale di riuso).
  2. Invece di ragionare sul come gestire una domanda centralizzata di dati, perché non pensare ad un portale che mostri i NON DATI italiani, anche in maniera provocatoria? Ossia, tutti quei dati non compresi nel punto 1 che dovrebbero essere Open Data, ma ancora non lo sono. Evidenziare questo tipo di dati potrebbe far crescere una maggiore consapevolezza della loro utilità nella società civile, ma anche nelle Amministrazioni Pubbliche.

    Uno scambio interessante su Twitter a proposito di dati non dati

Una cosa che non ho avuto tempo di dire

È utile ricordare che i premi legati alle performance dei dirigenti pubblici iniziano ad essere associati anche ai risultati della pubblicazione di Open Data: la scelta di quali dati inserire nel piano dell’attività di pubblicazione diventa fondamentale. Questa scelta dovrebbe dipendere dalla domanda di dati e non dalla volontà di pubblicare dati facili per raggiungere l’obiettivo. Non è qualcosa del tutto nuovo, tra l’altro. Se ne parlava già nel raduno di Spaghetti Open Data del 2014:

Qualsiasi azione in grado di aumentare la consapevolezza nella società civile dell’importanza di chiedere i dati di cui ha bisogno è essenziale. Che ne pensate?

Ps - per chi non lo sapesse, il sito di Spaghetti Open Data era il NON portale dei dati aperti italiani nel 2010. Oggi, a metà del 2019, pensare di lavorare al portale dei NON DATI ha qualcosa di affascinante e di ciclico (nel 2020 saranno dieci anni della comunità di SOD, tra l’altro).

L'immagine della cover del post è [Roadplant](https://www.flickr.com/photos/27496606@N08/2737388088) di [Brendan DeBrincat](https://www.flickr.com/photos/quacktaculous/) distribuita con [licenza CC BY](https://creativecommons.org/licenses/by/2.0/).