Quanto sono davvero aperti gli “open data”?

Dati “aperti”: cosa sono?

Oggi si fa un gran parlare di open data: concetto molto importante e prezioso, in un mondo nel quale forte è la pressione a mettere i dati sotto tutela, e soprattutto quelli sulla cui base si possono prendere decisioni importanti per la salute o il reddito dei cittadini.

Ma cosa sono, di preciso, i “dati aperti”, almeno qui in Italia? Una risposta, pragmatica, è: quelli resi disponibili dalla Pubblica Amministrazione e da altri soggetti, coperti dalla licenza IODL (Italian Open Data License), il cui testo aggiornato è disponibile alla URL https://www.dati.gov.it/content/italian-open-data-license-v20 .

Ad una prima lettura (superficiale) della licenza, mi sembra di poter dire che il suo scopo principale è di rendere i dati liberamente accessibili da parte di chiunque.

In questo articolo cercheremo di comprendere se il libero accesso è, anche, accompagnato da libero uso, e in caso negativo quali ne siano gli ostacoli, e le possibili contromisure.

Open-data come open-source?

Esistono altre licenze utilizzate per garantire la diffusione libera di dati (ad esempio la Creative Commons), me tutte si rifanno, a quanto comprendo, ad un sottofondo comune, simile, a prima vista, a quello per il software open source.

Simile, ma non identico. C’è infatti una differenza importantissima tra un software disponibile in forma di sorgente, e “dati” numerici.

Nel primo caso, il sorgente costituisce una sorta di specifica di ultima istanza, non ambigua e deterministicamente associabile al software in questione. Si può supporre che almeno una parte degli utenti finali abbia le competenze, il tempo e la voglia per comprendere ill funzionamento della cosa, giudicarne della sua adeguatezza ai propri casi in base alla propria esperienza, ed eventualmente apportare le correzioni del caso.

Con i dati, nulla di tutto ciò è possibile. C’è un’asimmetria ineliminabile di potere, in questo caso, tra chi quei dati li ha prodotti, e chi li usa. Con chi, poi, li ha raccolti e resi disponibili nel mezzo.

Se non si fa attenzione a ciò che si fa, la diffusione di open data potrebbe, così, costituire uno dei più colossali ed efficaci veicoli di propagazione di fake news.

Un esempio, tra i tantissimi esistenti

Come esempio di dati aperti, prendiamo le temperature rilevate in città nel 2018 rese disponibili dal Comune di Milano alla URL http://dati.comune.milano.it/dataset/ds686-rilevazione-temperature-anno-2018.

Come spesso accade la pagina di accesso non si limita ai link per lo scarico dei dati, ma contiene una tabella di metadati. Questi contribuiscono a rendere fruibili i dati, o dovrebbero farlo.

Dalla pagina dei metadati vediamo che:

  • La copertura dei dati va dall’1 Dicembre 2019 al 12 Dicembre 2019 (dato che oggi siamo al 7 Aprile 2019, presumo che queste due date siano nate da un refuso, e che i dati vadano dal primo di Gennaio 2018 al 31 Dicembre 2018.
  • L’editore del “data set” è il Comune di Milano.
  • Il titolare dei dati è ARPA Lombardia.
  • Il creatore dei dati è il SIAD – Unità Sviluppo Open Data, sempre del Comune di Milano a giudicare dalla partita IVA.

Più in basso, nella pagina dei metadati, vediamo che la loro origine è tacciabile alla pagina di scarico del sito di ARPA Lombardia, di cui è riportata la URL.

Quanto ai dati veri e propri, selezionando l’opzione “download” nel bottone di scarico possiamo farli comparire in una pagina testuale, dalla quale possiamo selezionarli, copiarli nella schermata di un editor di testo, e salvarli in un archivio CSV, per usarli con calma.

Queste le prime righe:

Zone;Id Sensore;Data-Ora;Media
Lambrate;2001;01/01/2018 00:00;3,5
Zavattari;5920;01/01/2018 00:00;3,2
Juvara;5909;01/01/2018 00:00;4
Feltre;8162;01/01/2018 00:00;3,2
Brera;5897;01/01/2018 00:00;3,6
Marche;5911;01/01/2018 00:00;3,8
Lambrate;2001;01/01/2018 01:00;3,3
Zavattari;5920;01/01/2018 01:00;3,1
Juvara;5909;01/01/2018 01:00;3,8
Feltre;8162;01/01/2018 01:00;3,2
Brera;5897;01/01/2018 01:00;3,4
Marche;5911;01/01/2018 01:00;3,5

Ci sono tutti. Ed è confortante vedere che, in effetti, partono dalle ore 00 del giorno 01. 01. 2019, e non dal 01. 12. 2019 come dichiarato nella pagina dei metadati.

Il fatto che i dati siano tutti presenti, però, porta con sé anche una difficoltà: per il modo in cui sono ordinati nel file, ogni riga una singola stazione, non è possibile utilizzarli direttamente, ad esempio per farne una serie storica.

E le righe sono tante. In un anno ci sono 8760 ore (24 in più, se bisestile). Per sei stazioni, il totale arriva a 52560.  Troppe, per poterle prendere in esame una ad una.

Sarebbe decisamente meglio, se invece che in un singolo file contenente tutti i dati di tutte le stazioni, vi fosse invece un file per stazione.

Ma se desideriamo porre i dati in questa nuova, e più utilizzabile forma, dobbiamo fare un certo lavoro. Per esempio, scrivere e usare uno script R come questo:

get.comune <- function() {

# Read Milan's open data to a data frame, and complement # it with time stamps
d <- read.csv2("Temp_2018_ComuneMilano.csv",
   stringsAsFactors = FALSE)
yr <- substring(d$Data.Ora, first=7, last=10)
mo <- substring(d$Data.Ora, first=4, last=5)
dy <- substring(d$Data.Ora, first=1, last=2)
tm <- paste(substring(d$Data.Ora, first=12),
   "00", sep=":")
date.time <- paste(yr,"-",mo,"-",dy," ",tm, sep="")
d$Time.Stamp <- as.POSIXct(date.time, tz="UTC")

# Remove now-unused columns, and arrange the 
# remaining ones in better user-order
d <- d[c(5,1,2,4)]
names(d) <- c("Time.Stamp", "Zone", "Sensor.ID", "Temp")

# Partition data to (for example) separate files,
# one per station
stations <- unique(d$Zone)
for(station.name in stations) {
  file.name <- paste("Temp_", station.name, "_2018.csv", sep="")
  e <- d[d$Zone==station.name,]
  e$Zone <- NULL
  write.csv2(e, file=file.name, row.names=FALSE)
}

# Leave (yielding back the transformed data set,
# for debug if needed)
return(d)

}

Piccoli (ma forse grandissimi) problemi concreti

Interessante, dover fare del lavoro non banale, per accedere a dei dati “aperti”. Il cittadino che desiderasse accedere ai dati di via Zavattari dovrebbe assumere un perito informatico, oppure imparare a programmare in R.

Ma in effetti nella pratica professionale accade sempre di dover “pulire” dati di provenienza esterna, prima di riuscire ad utilizzarli. Un professionista, però, ha dalla sua strumenti di lavoro, conoscenze, pratica: cioè, il risultato di lunghi ed ingenti investimenti. Nel caso, il concetto di dati “aperti” risulta un ossimoro: se al professionista i dati risultano non soddisfacenti, avrà sempre modo se necessario di “scassinarli” e, con opportune martellate informatiche, rimetterli in squadra.

L’utente finale, però, questa possibilità non ce l’ha.

Forse, l’origine del problema va ricercata in una mancanza di comunicazione e, da parte di chi rilascia le informazioni e detiene grazie a ciò una posizione di potere, assenza di empatia.

Intanto, tra necessità proprie e mentalità di chi i dati li ha preparati (e che magari non è nemmeno una persona umana) intercorre un abisso insondabile di non-detto, ma solo, nell’ipotesi migliore, immaginato, in modo quasi certamente divergente tra le due parti.

La responsabilità di colmare questo abisso sta a chi sa di più: la parte debole, nell’interazione, non sa di non sapere, e non ha alcuno strumento concettuale per porsi domande, concettuali od operative.

E i dati del Comune di Milano non fanno eccezione.

Colpevole, dunque, il Comune di Milano? Di sicuro, di non aver pensato abbastanza, prima di diffondere informazioni che potrebbero essere usate contro di lui.

Specchio, però, di un malvezzo molto diffuso, radicato in una profonda ignoranza dei mezzi informatici, a sua volta tacciabile all’arretratezza cultural del nostro Paese. Basti pensare alla valanga di siti, di Banche o della Pubblica Amministrazione, realizzati in modo incomprensibile. Come la pagina di una nota banca che, per indurre i Clienti a passare ad una nuova tecnologia di autenticazione, permette dalla stessa schermata di scaricare un’app per Android, o per iOS, o per Windows, pretendendo che gli utenti (spesso persone anziane sole, sappiano cos’hanno tra le mani, e che l’applicazione va scaricata sul telefono, invece che sul computer: questo, ai tempi di HTML5 e dei siti “adattivi”).

Il problema tutto sommato veniale incontrato per caso sugli open data del Comune di Milano ne solleva forse un altro, di portata immensamente maggiore e più pericolosa: di una classe dirigente che usa a piene mani le tecnologie informatiche, senza comprenderne minimamene pericoli ed opportunità, e senza alcuna possibilità di svolgere il suo compito di guida. Come, se ricordate, decenni e decenni fa, i responsabili del Fronte Polisario (i Tuareg!) che avevano acquistato dei caccia Mirage, salvo constatare che sulla sabbia del deserto non potevano atterrare. O che,  casomai lo facessero, restavano impantanati e non ripartivano più. Con il risultato di una spesa ingente, che non ha comportato alcun risultato apprezzabile: quegli aerei non hanno fatto alcun danno al nemico, e se per quello non hanno mai nemmeno consegnato una cartolina postale.

Il Principio della Trota.

Sono le ore 15:21 del 28 Aprile 1979, e, evento importantissimo nella nostra storia, il signor M.R. ha pescato un’alborella. Una sola, per quanto alla foce del Tresa tra Luino e Germignaga ai tempi qualcuna ce ne fosse ancora.

Alle 16:30, l’alborella nel cestino era ancora da sola, e contava tristissima le alghe, che la Tresa di tanto in tanto portava verso il Lago Maggiore.

Alle 17, il signor M.R. decise che ne aveva abbastanza di dover spiegare come mai il cestino fosse ancora così desolatamente casi vuoto, liberò la sua preda prima che morisse di tristezza, e si incamminò verso il bar.

E lì, racconta che ti racconta, l’alborella subì una misteriosa, quanto comune, trasformazione. Già nel racconto di M.R. era divenuta due volte più grande che nella realtà. E, forzutissime.

Ma il suo amico S.D. (un po’ sordo) capì “trota bella” invece che “alborella”, con il che il pesciolino raddoppiò ancora la sua lunghezza.

Al quarto passaggio, l’alborella era divenuta un mostro marino, un capodoglio forse, che per un misterioso accidente della Natura, e sospinto da un’ammirevole forza di volontà, aveva superato (con una bella shakerata e qualche danno per l’orgoglio) la turbina Kaplan dell’impianto di Tornavento, risalendo il Ticino sino a Somma, Angera, ed oltre…

Questo fenomeno, che in società è molto comune, e che nell’arte della pesca assume una curiosa proclività verso l’aumentare e mai diminuire, si chiama “distorsione semantica”, ed avviene ogni volta che tra le due parti impegnate nel trasferimento di informazioni intercorre una differenza esperienziale. Maggiore la distanza, più evidenti le distorsioni.

Se poi andiamo ad analizzare in dettaglio cosa accade (e proprio tra i dettagli, com’è noto, si nasconde il Diavolo), vediamo che qualche volta le informazioni passano, ma ripetute con le parole di chi le ha ricevute, diverse nel senso da quelle di chi le ha emesse. Qualche altra volta, informazioni che chi riceve considera irrilevanti, e che magari non lo erano, vengono pietosamente omesse. Altre volte ancora, chi riceve ritiene l’informazione ricevuta non adatta, pur avendone compreso il senso, e a ristruttura in una forma che ritiene più comoda. Oppure ancora, chi riceve ha tra le mani qualcosa di incompleto, ma non ha modo di sapere dell’incompletezza, e diffonde i dati ricevuti come fossero completi ed esaustivi.

Per dirla in breve: persino informazioni “oggettive” come dati misurati corrono il rischio d’essere sottoposti ad un pesante, ed inconsapevole, processo di invenzione creativa che ne modifica il significato.

Adesso, che abbiamo finalmente il nostro script di ordinamento, possiamo finalmente dividere i dati per stazione, e verificare se qualche distorsione c’è stata anche nel caso dei nostri dati.

La stazione più vicina alla casa dei miei è quella di Milano Zavattari: decido di puntare l’attenzione su di essa, e come prima operazione ne conto i dati.

Sorpresa!

Le righe non sono 8760! Dovrebbero essere proprio tante così, dal momento che il 2018 non era bisestile, per cui 365 per 24 fa 8760 e…

Ma i dati che ho ricevuto sono di meno: 8737. Ne mancano ventitrè.

Una rapida scorsa ad uno dei file rivela il problema: i dati arrivano, in effetti, sino al 31 Dicembre 2018, ma, si fermano alle ore 00! Quelli dalle 01 alle 23 non ci sono proprio.

Chi ha predisposto i dati, con ogni probabilità, lo ha fatto usando la pagina di scarico di ARPA Lombardia, passando come date estreme

  2018-01-01,  2018-12-31

dimenticandosi che 2018-12-31 vuol dire in realtà 2018-12-31 00:00:00. Un errore classico, da neofiti, o da chi ha poco tempo. Gli estremi corretti erano (forse in modo poco intuitivo)

2018-01-01,  2019-01-01

Ma, ormai, tant’è: i dati “open” sono capitozzati irreversibilmente, almeno sino a quando il Comune di Milano provvederà alla sperata correzione.

Tra i metadati dell’apposita pagina compaiono, anche, i nomi della persona che ha materialmente predisposto il file con i dati, e del dirigente cui questa fa capo.

Fossimo gente di corte vedute ci verrebbe spontaneo gettar la croce addosso a queste due, addossando loro ogni colpa per questi, e presumibilmente altri, errori, e pretendendo, se non la correzione degli stessi, almeno immediata soddisfazione.

Ritengo però più costruttivo, ed interessante, affrontare il problema in modo più sistematico, avendo ravvisato in esso caratteri che trascendono il Comune di Milano, e gettano una luce (sinistra, in parte) sulla natura stessa degli “open data”.

Sono, questi “open data” del Comune di Milano, in effetti dati riportati. Che qualcuno ha preparato, e qualcun altro ha preso in carico, trasformato in base a fini che nei metadati non mi risultano dichiarati (magari mi sbaglio), impacchettato, e distribuito in modo più o meno conveniente secondo a propria visione soggettiva.

In quanto “open data”, il focus, l’attenzione, è andata sull’apertura, sulla ampia diffusione.

Però, all’apparenza, ha trascurato molti altri aspetti. Ha assunto una visione, per così dire, “a trapano”, lasciando perdere il contesto generale.

In questo modo, ha anche involontariamente indirizzato le inevitabili omissioni e distorsioni, che si verificano quando un insieme di dati sia trasformato e ri-distribuito, in una direzione di massima efficienza, ma, possibilmente, minimo senso – e, difficile fruibilità: vedi il mio script R.

Se volessimo andare alla radice del problema, dovremmo forse dirigere la nostra attenzione agli organi politici che hanno deciso di produrre gli “open data”, allocato risorse (insufficienti?), deliberato azioni, senza dare un preciso mandato tecnico a chi poi avrebbe dovuto fare, ed anzi, delegando a questi ogni scelta operativa, con la solita possibilità di facile sconfessione in caso di problemi. E, malvezzo comune della politica italiana, evitando accuratamente di lasciarsi indicare per nome e cognome nella pagina dei metadati.

Ma. Siamo sicur* di aver definito interamente i termini del problema?

Forse, no. Potrebbe esserci dietro qualcosa di molto più profondo, e meno controllabile, che una manciata di refusi facili da sanare.

Qualcosa che, in perfetta buona fede, ma in modo profondissimamente sbagliato, stiamo facendo tutti insieme, con le nostre azioni, ed anche, concedetemi, con le nostre aspettative. Qualcosa, che cozza contro una realtà di fatto, dura come al solito, radicata nelle leggi della fisica e della matematica.

Andiamo all’origine?

I dati “open” di temperatura del Comune di Milano vengono, per ammissione dello stesso, da ARPA Lombardia. Ed anche lì, in fondo, sono dati “open”: aperti, accessibilissimi, tramite una pagina di scarico di facile impiego (salvo il significato della data “finale”).

Prendiamo, allora, i dati della stazione ARPA di Zavattari, facendo l’interrogazione così come la condurrebbe una persona comune, e cioè chiedendo quelli orari, in formato CSV, dal giorno 2018-01-01 al 2018-12-31.

Dopo qualche minuto dalla richiesta, all’indirizzo di posta elettronica che abbiamo indicato giunge un messaggio contenente, in allegato, i dati richiesti.

Che sono, nel caso della temperatura, composti da due file: i dati veri e propri, e la legenda.

Vediamola, perché è interessante:

Legenda
-999 Valore mancante o invalido

Riepilogo estrazione
Id_Stazione,Nome_Stazione,Id_Sensore,Nome_Sensore,Unita_Misura,Periodo_Dal,Periodo_Al,Operatore
503,Milano P.zza Zavattari,5920,Temperatura,°C,2018/01/01 00:00,2018/12/31 00:00,Media

La seconda riga, interessantissima, ci dice che esiste un valore speciale che rappresenta i dati invalidi.

Questa informazione, non rilasciata esplicitamente dal Comune di Milano, che per i suoi “open data” ha scelto una via diversa: i dati invalidi sono lasciati vuoti.

Una piccola, insignificante differenza. Che, però,  ha reso i dati in teoria aperti, la cui origine è attribuita ad ARPA Lombardia, diversi dagli originali.

Le righe successive, invece, hanno una funzione per lo più contabile: la richiesta di dati avrebbe potuto riguardare più sensori, e qui avremmo trovato i riferimenti a ciascuno di essi, insieme al suo significato complessivo. Noi di sensore ne abbiamo richiesto uno solo, e la riga che gli compete ci può sembrare poco importante.

Veniamo ai dati. Quelli di ARPA Lombardia sono fatti così:

Id Sensore,Data-Ora, Media
5920,2018/01/01 00:00,3.2
5920,2018/01/01 01:00,3.1
5920,2018/01/01 02:00,2.8
5920,2018/01/01 03:00,2.4
5920,2018/01/01 04:00,2.5
5920,2018/01/01 05:00,2.8

Interessante. Qui, 2018/01/01. Nei dati “aperti” del Comune di Milano, 01/01/2018. La stessa data, espressa però in due forme diverse. Prova, questa, che il Comune di Milano non ha soltanto acquisito i dati ARPA per riversarli come sono. Li ha, invece, letti, magari filtrati, e riscritti in una forma certamente diversa. Ci sono altre piccole differenze: il separatore decimale (la virgola, all’italiana, invece che il punto; il punto e virgola come separatore di campo invece della virgola.

Quanto pesante è stato il filtraggio? Non ne ho idea. Nei metadati non se ne parla.

Se andiamo a prendere i primi valori generati dal mio script per Zavattari, troviamo queste prime righe:

"Time.Stamp";"Sensor.ID";"Temp"
2018-01-01 00:00:00;5920;3,2
2018-01-01 01:00:00;5920;3,1
2018-01-01 02:00:00;5920;2,8
2018-01-01 03:00:00;5920;2,4
2018-01-01 04:00:00;5920;2,5
2018-01-01 05:00:00;5920;2,8

I valori di temperatura coincidono, quindi, “ci siamo”.

Se guardiamo all’intera serie dei dati, vediamo che i valori dei dati validi coincidono con quelli ARPA. Il che, però, non dice alcunché di universale: un anno diverso, o un’altra stazione, e magari qualche differenza si vedrebbe. Sarebbe molto più comodo, però, se qualcuno si fosse preso la briga di confermare questa uguaglianza.

Se, poi, andiamo in fondo al file ARPA, troviamo queste righe:

5920,2018/12/30 19:00,12.1
5920,2018/12/30 20:00,11.2
5920,2018/12/30 21:00,11.0
5920,2018/12/30 22:00,10.6
5920,2018/12/30 23:00,8.1
5920,2018/12/31 00:00,6.1

E’ così confermato, che richiedendo i dati al sito ARPA sino al 31 Dicembre, l’insieme che otteniamo a quell’ora si ferma.

Il significato delle marche temporali

La legenda ci conferma su una cosa che avevamo intuito, ma che sino ad ora non avevo resa esplicita. Le temperature che compaiono nei file sono medie orarie.

Medie, di che? Di misure elementari. Quali, di preciso?

Se i numeri sono medie orarie, allora si riferiscono  ad un intervallo temporale lungo un’ora. Intervallo, a rigore, contraddistinto da due marche temporali, una di inizio e una di fine.

L’unica marca temporale che correda ogni dato di provenienza ARPA Lombardia si riferisce per convenzione all’istante finale dell’intervallo di mediazione.

A priori, avrebbe potuto essere qualsiasi altro valore entro l’ora: l’inizio, la metà, o, appunto, la fine. O, qualsiasi altro valore, possibilmente stabilito da una qualche regola.

Quindi, la marca 2018-01-01 00:00:00 si riferisce all’intervallo di tempo che va dalle ore 23:00:00 del giorno 2017-12-31 alle 00:00:00 del 2018-01-01. E così, per tutte le altre righe dell’insieme di dati.

Comode da generare (per chi costruisce i sistemi di acquisizione dei dati), le marche temporali posticipate sono però in grado di suscitare una certa confusione. Molte persone considerano più intuitive le marche temporali anticipate. Alcune altre (ed io tra di loro) preferirebbero come marca temporale il centro dell’intervallo di mediazione.

Tutte scelte legittime, con propri vantaggi e svantaggi. Non esiste alcuna ragione, gusto estetico soggettivo a parte, per preferire l’una all’altra. Ciò che mi preme osservare, è che non esiste consenso circa le marche temporali di periodo, cosicché, se non fosse disponibile l’informazione a priori che la marca dei dati è posticipata, si rischierebbe di compiere un errore grave nell’interpretazione della posizione dei dati nel tempo.

Se al momento della distribuzione dei dati “aperti” questa informazione chiave è omessa, la loro comprensione finisce minata, e l’uso più difficile.

Certo, un’utente molto capace, e molto fortunata, potrebbe notare che il massimo del giorno-tipo delle temperature non occorre a mezzodì, ma sfasato di un’ora, ed avrebbe modo di attribuire ai dati una marca temporale per lei più sensata.

Ma dovrebbe, appunto, essere capace e fortunata.

O disporre di informazioni da insider trader, come quella che vi ho data io.

Dietro un numero

Ambiguità del linguaggio naturale

I dati di temperatura, lo abbiamo già visto, sono “medie”.

Basta, questa parola, per caratterizzarne in modo esaustivo natura e proprietà dei nostri “open data”, e darci elementi che ci permettano a priori di prevederne il valore?

La risposta breve è, “No”.

Ma, vediamo i particolari.

Partiamo, intanto, da un’ipotesi di lavoro. Quando la legenda dei dati ARPA parla di “media”, immaginiamoci di intendere “media aritmetica”. Qualcosa, insomma, di simile a questa formula:

\[ \overline{x}=\frac{1}{n}\sum_{i=1}^{n}x_{i} \]

Questa è la definizione più comune del termine “media”, ed è ciò che ci immaginiamo quando pensiamo ai polli di Trilussa, e ricordiamo sin dalle scuole medie.

A priori ci sarebbero anche altri tipi di “media”. Ad esempio, la “media armonica”,

\[ x_{h}=\frac{n}{\sum_{i=1}^{n}\frac{1}{x_{i}} } \]

Oppure, la “media geometrica”:

\[ x_{g}=\left(\prod_{i=1}^{n}x_{i}\right)^\frac{1}{n} \]

Oppure, altri tipi di “media” più esoterici, come ad esempio l’uscita di un filtro autoregressivo nel dominio del tempo.

La mia ipotesi che per “media” debba proprio intendersi quella aritmetica affonda le sue radici nell’ambiguità intrinseca del linguaggio naturale, che, a differenza dei linguaggi artificiali più diffusi (ad esempio i linguaggi di programmazione) richiede in modo esplicito l’intervento di un’intelligenza che nella miriade di possibili significati sappia scegliere quello, o quelli, più sensati in base al caso.

A volte, come nel caso che stiamo analizzando, il contesto tecnico non da alcun appiglio ad una intelligenza puramente neutrale. Infatti, a priori non ci sarebbe alcuna ragione di preferire una media armonica, o geometrica, a quella aritmetica.

La mia scelta a favore della media aritmetica, in fondo, non si basa su dati puramente tecnici, ma sulla psicologia e sulla tradizione: da un lato, i meteorologi sono abituati alla media aritmetica, e storcerebbero il naso di fronte a qualcos’altro; dall’altro, le “medie” sono prodotte direttamente dai sistemi automatici di registrazione dati che compongono, insieme agli strumenti, una stazione meteorologica: e chi costruisce sistemi automatici di registrazione dati, quasi sempre adotta dandola per scontata e senza nemmeno dirne la “media aritmetica”.

A priori, non è detto che l’utente dei dati aperti” condivida questo background, e potrebbe così immaginarsi qualcosa d’altro. Aspettativa legittima, sintantoché nessuno gli dice in modo esplicito che media è stata realmente utilizzata.

“Ma che importa,” chiederà a questo punto qualcuno, “sapere com’è stata calcolata la media?”

Vero, rispondo. In alcuni casi, sapere come sono state ottenute le medie non è così importante. Precisamente, nei casi in cui il dato “non ha un’importanza critica”, ma solo un interesse, per così dire, indicativo e qualitativo.

Esistono, però, altri casi, nei quali il dato ha un’importanza critica. Ad esempio, nelle cause legali, nei contratti, nella ricerca scientifica, nella meccanica di precisione ed in altri innumerevoli campi dell’ingegneria. Ed altrove ancora.

Lì, sapere se i dati sono stati ottenuti usando una media aritmetica (quindi uno stimatore del valore atteso di un processo casuale che sta dietro alla manifestazione visibile delle “misure” che hanno formato i dati) piuttosto che di altro tipo (con qualche altra proprietà profonda desiderabile) non è per nulla indifferente: conoscere o meno questo dettaglio permette, o no, di fare sulle “medie” delle affermazioni “forti”, del tipo, “Le cose stanno così, e ti spiego perché.”

Oltre i dati “aperti”?

Quanto gli “open data” del Comune di Milano hanno evidenziato potrebbe indicare un fatto importante, ed una potenzialità preoccupante.

La diffusione di dati “aperti” è un’intrapresa essenzialmente informatica.

Utile, ma, ad oggi, non per tutti. Come abbiamo veduto, il loro utilizzo reale comporta l’impiego di mezzi sofisticati, e conoscenze non banali perché tutto ciò dia luogo ad interpretazioni sensate.

Cosa manca?

Secondo me, due cose importanti:

  • Metadati accurati ed esaustivi, e,
  • Cultura.

A queste, mi permetto di aggiungerne una terza, non meno importante, ma di carattere sistemico, e a differenza delle due qui sopra, di difficile soluzione:

  • Consapevolezza tecnica ed eccellenza da parte della classe dirigente.

Nel caso esempio specifico, ai metadati, e ad una formazione più accurata dei dati da distribuire, può senz’altro provvedere, con le risorse disponibili e con poco sforzo, il Comune di Milano.

Più in generale: ma siamo sicuri* che i dati “aperti” siano sufficienti?

Soprattutto adesso, con la valanga di numeri che l’Internet delle Cose potrebbe riversare su di noi. Sull’apertura, ho pochi dubbi che ci sarà.

Ma che dire, della qualità? Dell’usabilità?

Già oggi è difficile validare i dati acquisiti per via convenzionale: fondi e risorse scarseggiano. Ma domani, o dopodomani, sarà materialmente ancora possibile farlo?

Si parla, di questi tempi, di big data. Di “identificazione proattiva dei guasti”. Di machine learning.

Ma chi garantirà che i numeri che ci inonderanno abbiano un rapporto preciso e raccontabile della realtà?

La risposta, forse, è nell’andare oltre.

Dai dati “aperti”, ai dati trasparenti.

Corredati da metadati che dicano tutto ciò che c’è da sapere al dettaglio necessario, e che non si possano disgiungere dai dati.

Magari, ad un “livello di qualità” dei dati, con una classificazione del tipo “usabili da utenti finali”, “usabili con cautela da professionisti”, “potenziale spazzatura”.

Un’eventuale licenza sui “transparent data” afferirebbe, inevitabilmente, non solo ai dati in quanto tali, ma all’intera catena che li produce. Hardware e software inclusi.

A Servizi Territorio srl stiamo, ad esempio, lavorando ad una nuova famiglia di sensori intelligenti con diffusione dei dati tramite IoT. Rispetto ai sensori intelligenti comunemente reperibili sul mercato, questi pongono l’attenzione non sulla diffusione veloce di numeri, ma sulla distribuzione di dati di qualità definita.

Che si possano usare, ad esempio, in uno studio sull’isola di calore. O più in generale, quando i dati abbiano davvero un valore, e la natura della loro formazione non sia indifferente.

Molto ancora, però, c’è da fare. Incluso, cambiare la percezione comune, ed in certo modo elevarla rispetto allo stato attuale, sufficiente forse nel secolo scorso, ma non più adatto per sopravvivere in tempi globali ed incerti.

Cominciando, magari, a riflettere tutti (cittadin*-utenti inclus*) su una licenza per dati trasparenti, che siano davvero utilizzabili senza problemi da parte di (potenzialmente) chiunque.

 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *