Open data: bug e bugfix.

- Open Source

Se lancio una palla, da una parte, dall’altra per condurre un gioco secondo determinate regole ci deve essere qualcuno a raccoglierla, altrimenti il gesto perde di senso. È questo uno dei compiti degli open data: da una parte decentralizzare il potere, togliendolo dalle mani e dai cassetti di chi prima faceva del dato raw una merce di scambio per favori molto spesso personali. Il secondo compito, tuttavia, è quello come ho già detto in passato di stimolare gli hacker civici e la popolazione in generale a produrre valore aggiunto rispetto a questi dataset, attivando un meccanismo virtuoso che parte dal bit, e impatta sullo stile di vita della popolazione circostante.

Durante Green Open Data, poco prima della presentazione di TweetYourMEP, ci siamo imbattuti in qualcosa a cui onestamente io avevo già pensato, ma era qualcosa a cui non avevo osato dar sfogo: c’è stato chi l’ha fatto prima di me, chiedendo se non sia possibile stimolare le amministrazioni a produrre e liberare una serie di dataset “predefiniti”, a beneficio degli hacker interessati all’uso di questi dati. Le risposte sono state molto vaghe, e la più soddisfacente in buona sostanza recitava: “partiamo con le cose facili, perché obbligare un’amministrazione a fare questo vuol dire complicare lo scenario, e mettere i bastoni tra le ruote a chi vuole semplicemente liberare i propri dati”.

open gov data

Penso conosciate tutti Yoda. È la figura che in Star Wars esemplifica ed incarna la saggezza suprema, colui che grazie all’esperienza di una vita molto lunga, ha accumulato un bagaglio culturale tale da fare sempre la scelta giusta. Ne L’Impero Colpisce Ancora, Yoda si esibisce in una meravigliosa considerazione di stampo quasi taoista: “Do, or do not. There’s no try.” – sostanzialmente possiamo usare questa citazione per un grosso numero di esempi. Gli open data fanno al caso nostro per raccogliere la riflessione di Yoda: dobbiamo fare. Lo spazio per i tentativi è rimasto a zero, in una condizione come quella attuale, e per quanto la tematica sia calcata con passo incerto dalle amministrazioni, dobbiamo ammettere che è tardi per far rimanere gli open data un tema di nicchia ma non solo: qualcosa a cui gli sviluppatori credono e non credono.

Ad oggi infatti il viaggio di uno sviluppatore all’interno del panorama open data è pieno di incertezza: speriamo di trovare quel dataset, e speriamo di trovare le informazioni che mi servono. O al contrario, che figa questa informazione, adesso ci faccio un’applicazione ma, attenzione, speriamo per allargare il mio raggio d’azione che altre amministrazioni rendano disponibili dati dello stesso tipo. È tutto molto difficoltoso, e come detto da alcuni non è interessante in termini di ore/uomo che qualcuno sviluppi applicazioni su un modello così frammentato dove regna il caos più totale. Uno dei rischi di questo approccio per esempio è che arrivi Alfonso Fuggetta, e venga a dire che tutto quello che stiamo costruendo non funziona. È vero: non funziona. Ma diciamo (e lo dico da sistemista Linux, quindi avrei tutto l’interesse di dire il contrario) che molto del problema risiede nella prassi. Attraverso servizi come Singly possiamo facilmente costruire API che reggano il confronto con quelle di database ben più professionali. Con dei dataset così frammentati tuttavia è necessario uniformare l’esperienza di fruizione da parte del programmatore, rendendogli più facile la vita. In che modo?

  1. Stilare – e c’è chi ci sta già provando – un elenco di dataset che presumibilmente dovrebbero trovarsi in ogni amministrazione, o quantomeno che sarebbe buona creanza avere
  2. Effettuare un packaging di questi dati in una maniera universale (JSON può essere un modo) e interoperabile
  3. Aprire il dato avendo cura di aderire ad uno standard di nomenclatura in modo da consentirne un facile riuso e l’inclusione in algoritmi di ricerca per la creazione di API efficaci

Una volta messi in pratica questi tre punti, avremo una mole di conoscenza fruibile dagli hacker civici in maniera uniforme, ed un parco di potenziali applicativi molto più d’impatto del “greppatore di pini andati a fuoco durante l’incendio a Rocca Cannuccia”.

Bisogna smetterla di cercare scuse, e attivarsi affinché la rivoluzione del dato aperto trovi corrispondenza d’amorosi sensi (scusa Ugo per la citazione aggratise) proprio nella popolazione e presso ulteriori, potenziali hacker civici.

There’s no try.

Image courtesy of Justin Grimes

  • http://twitter.com/AlfonsoFuggetta Alfonso Fuggetta

    il problema non è costruire API su un dataset pubblicato che continua a replicare il dato sorgente: il punto è costruire API che esportino i servizi di un sistema informatico. Altrimenti la questione di fondo NON si risolve.

  • http://dottorblaster.it/ Bl@ster

    Mi fa piacere il tuo commento :)
    In medio stat virtus. Il modello attuale consente il rilascio di dati e conseguente riutilizzo in maniera sostanzialmente anarchica, regolata solo dalle licenze. La fornitura di una API per dataset in un certo qual modo federati secondo me può essere un primo passo per aumentarne l’uso e far emergere la necessità di questi dati.

    A quel punto, se ne può anche riparlare.

  • http://www.alfonsofuggetta.it/ Alfonso Fuggetta

    Senza dubbio avere una maggiore sistematicità e organicità nella gestione dei dataset serve ed è utile. Ma non incide sul problema strutturale: se l’obiettivo è sviluppare servizi evoluti integrati, serve vera interoperabilità.

  • http://dottorblaster.it/ Bl@ster

    Beh ma io trovo che questo non renda meno valide le tesi degli open data almeno come li concepisco io. Per quello che intendi tu, stiamo parlando di sovrastrutture da frapporre tra il dato e l’hacker e fra dato e dato.

    O sono scemo e non ci arrivo? – nel senso: se ogni dato avesse una propria API coordinata da un qualche tipo di standard (anche de facto ma per le amministrazioni italiane o una cosa è legge, o tenderanno a non integrarsi), allora si potrebbero evitare persino le copie statiche e le applicazioni diverrebbero interoperabili.

  • http://www.alfonsofuggetta.it/ Alfonso Fuggetta

    Beh certo, se esporti un servizio proprio del sistema, abbiamo risolto il problema. Ma a quel punto non ci sono più open data per come vengono definiti. É la differenza che ho cercato di illustrare nella figura del mio post.

  • http://www.alfonsofuggetta.it/ Alfonso Fuggetta

    Dai un’occhiata anche a questo: http://www.alfonsofuggetta.org/?p=16843

  • http://www.alfonsofuggetta.it/ Alfonso Fuggetta

    Ho letto ora questa cosa che ha scritto su un forum pubblico:

    > Ma infatti l’esimio prof Fugetta si
    > è scordato che opendata != egov/opengov, anzi,
    > ne è solo una parte. Opendata per me
    > è una significativa fetta di un framework
    > molto piú ampio.

    Primo, non sono esimio.
    Secondo, sono Fuggetta con due “g”.
    Terzo, non me lo sono scordato manco per nulla.

  • http://dottorblaster.it/ Bl@ster

    Mi scuso per l’errore che è stato ovviamente un typo. È strano però che allora venga assunto che i dati debbano costituire parte di un sistema più ampio, compito che personalmente trovo più adatto alla categoria opengov, che a quella del dato puro.

    Un dato raw è un dato raw, penso che andarselo a prendere tramite una API che lo tiri fuori “as is” da un sistema informatico anziché da un JSON generato precedentemente implichi che ci siano procedure per l’egovernment attive, piuttosto che la semplice liberazione del dato. E attenzione, non sto dicendo che non serva avere un sistema a cui fare chiamate, anzi. Solo che dovremmo considerarlo una maniera complemenetare – anche perché più costosa.

  • http://www.alfonsofuggetta.it/ Alfonso Fuggetta

    Il tema che io ho trattato è come si sviluppano servizi evoluti, come si può cercare di sbloccare una situazione che è bloccata. Tutti non fanno altro che ripetere che per fare queste cose (vedi il caso smartcity) servono open data. Ne parlano anche per l’ego, per tutto. Da qui nascono i miei post che, come si può verificare, non mancano mai di dire che open data per favorire la trasparenza sono appropriati. Ma non per fare tutto il resto.

  • http://www.alfonsofuggetta.it/ Alfonso Fuggetta

    l’egov, intendevo.

  • http://dottorblaster.it/ Bl@ster

    Beh su questo sono d’accordo. Mi riferivo a questo dicendo che gli open data fanno parte a sé di un framework più grande, dove io come hacker civico dispongo del “modulo sistema” come cittadino fruitore del servizio, e del “modulo dati” che fornisce a me sviluppatore la API riferita ad un dato con un determinato refresh rate. Che la situazione sia bloccata poi, ripeto, concordo, anche perché andando a monte molto spesso (come ho detto nel post) si liberano dati di cui agli sviluppatori non importa, tanto meno ai cittadini, tantomeno a nessuno seppure il dato fosse interessante e mancassero (come accade *sempre* a parte rari casi) delle API che possano facilitare i compiti, tra cui il compito del refresh da parte dell’applicazione del proprio database una volta che i dataset vengono aggiornati, e non solo.