Il concetto di dati aperti (open data) si riferisce generalmente all’idea che alcuni dati debbano essere liberamente disponibili a tutti, per poterli utilizzare e ripubblicare senza restrizioni, copyright, brevetti o altri meccanismi di controllo stretto. In particolare, secondo l’Open Definition[1] “una porzione di dati (dataset) è aperta se chiunque può liberamente accedervi, usarla, modificarla e condividerla per qualsiasi scopo (assoggettandosi, al massimo, ai requisiti che preservino la provenienza e l’apertura)”. Alcune caratteristiche devono essere garantite per la fornitura di dati aperti, ovvero (i) l’accessibilità – tutti i potenziali utenti possono liberamente accedere ai dati, per lo più gratuitamente o ad un costo molto basso, (ii) la leggibilità da parte di macchine e sistemi automatici – i dati devono poter essere naturalmente trattati, processati e “capiti” da macchine e sistemi software (machine readability), e (iii) i diritti – i dati vengono rilasciati con licenze che vincolano molto blandamente l’uso, la trasformazione e la ridistribuzione di tali dati.
Molto legata all’idea di dati aperti è quella di governo aperto (open government), ovvero la possibilità da parte dei cittadini di accedere ai documenti e alle procedure delle amministrazioni pubbliche per una supervisione efficace. Permettere ai cittadini interessati di essere maggiormente coinvolti nei processi, rendendo disponibili informazioni sui processi delle amministrazioni pubbliche come dati aperti machine readable, può facilitare trasparenza, responsabilità e partecipazione dei cittadini e delle imprese. L’apertura delle informazioni può anche favorire l’innovazione tecnologica e la crescita economica, permettendo a soggetti terzi di sviluppare nuovi tipi di applicazioni e servizi digitali. Nell’ottobre del 2015, l’Open Government Partnership (OGP), durante il suo vertice in Messico, ha lanciato la carta internazionale dei dati aperti, un insieme di principi e best practice per il rilascio di dati aperti governativi, formalmente adottata da diciassette paesi inclusa l’Italia[2].
Ma quali tecnologie e approcci può adottare un’amministrazione (in generale un’organizzazione) che voglia fornire dati aperti?
I metodi e le tecnologie del cosiddetto semantic web offrono una soluzione basata sull’idea di modellare il patrimonio informativo come un grafo che collega risorse disponibili sul Web (grafo RDF). Tecnologie quali OWL, RDF/RDFS e SPARQL sono alla base di questo approccio, ampiamente standardizzato dal W3C e supportato dalla maggior parte dei fornitori di tecnologie, in particolare da quelli che offrono strumenti per la gestione dei dati. Questo approccio viene indicato come LOD – Linked Open Data – qualora i dati siano forniti in formato open, o come Linked Data più in generale. La principale caratteristica dei LOD è la possibilità di inter-connessione tra dati di dataset differenti, anche appartenenti ad organizzazioni differenti. L’utilizzo di ontologie che modellano formalmente i domini di interesse facilita fortemente l’interconnessione tra i dataset. Esempi italiani di successo di tale approccio sono il portale LOD dell’ISTAT, cf. http://datiopen.istat.it, che offre come LOD (alcuni) dati del Censimento 2011, e le sperimentazioni, sempre dall’ISTAT effettuate, di interconnessione dei dati con quelli dell’ISPRA, ad esempio.
Un altro approccio interessante e potenzialmente utile è quello dei cosiddetti open services o open API[3]. Un’API – Application Programming Interface (talvolta anche chiamata servizio o servizio Web), è la possibilità di invocare funzionalità software esposte sul Web, che permettono l’accesso a procedure e funzioni di back-end dell’organizzazione che le espone. Si distingue tra weak open services – API semplici che sostanzialmente permettono l’accesso ai dati (e quindi molto simili agli open data), e full open services – vere e proprie transazioni e procedure di back-end esposte ai fini di integrazione di workflow e processi inter-organizzativi. Le tecnologie dei Web service (SOAP – oramai datato, e REST – molto in voga per la sua estrema semplicità di utilizzo) permettono lo sviluppo di tali servizi. Esempi italiani di tale approccio sono il nascente OpenTrasporti del Ministero delle Infrastrutture e Trasporti, in cui verranno offerte API per la fornitura di dati sul trasporto e procedure di journey planning, integrazione con eventi, ecc. Altro esempio in questa direzione è stato l’ecosistema E015.
La progettazione e la costruzione di uno stack tecnologico che utilizzi appieno le tecnologie del Web semantico è un processo di sviluppo complesso e che richiede molte competenze; a tempo d’esecuzione, le prestazioni ne possono risentire, almeno allo stato attuale dello sviluppo ICT. D’altro canto, con un’ontologia ben definita ed uno SPARQL endpoint, qualsiasi client (sia umano – attraverso un tool per scrivere query, che un programma software) può interrogare a proprio piacimento il dataset, anche in modalità non previste e progettate dal fornitore, realizzando quindi pienamente il concetto di openess (non a caso le classificazione di open data, sia quella proposta da Tim Berners Lee su una scala 1 – 5 stelle, che quella di AgID[4], assegnano il massimo solamente ai dati esposti in modo semantico).
Lo sviluppo di Open API è dichiarato essere più agile e veloce ma più “vincolante” nell’accesso ai dati. Solamente l’API esposta può essere invocata, e quindi il client recupera le informazioni guidato dalle operazioni esposte nell’API.
Si noti come va considerato anche l’utente ultimo dell’esposizione, se uno user umano o un software, e se si vuole offrire a questo utente piena libertà di accesso ai dati (dal punto di vista delle possibili interrogazioni) o lo si voglia limitare. Se in un progetto specifico, l’organizzazione che offre il dato ha già predefinite (in base a requisiti organizzativi, analisi dei possibili scenari di utilizzo, ecc.) le modalità di accesso e navigazione e deve garantire che gli utenti possano accedere solo in quello specifico modo, allora probabilmente il maggior costo di sviluppo della full openess potrebbe non essere giustificato, ed un approccio più a breve termine focalizzato su una specifica Open API potrebbe essere economicamente ed organizzativamente più vantaggioso (richiede meno investimenti). I progetti che sono attivi in ambito Pubblica Amministrazione possono a tal proposito costituire un utile bacino di lessons learned (sia quantitative che qualitative) rispetto a questa tematica, utile per indirizzare i prossimi sviluppi.
