Open Data e Linked Open Data, a classificarli (e promuoverli) ci ha pensato Tim Berners-Lee con il suo famoso ranking definendo cinque “voti” o stelle da assegnare ad un dataset quando questo viene pubblicato online. Come si fa però a valutare l’effettiva “adesione” dei dati e della loro modalità di pubblicazione ai principi di Berners-Lee?
Una checklist ben lungi dall’essere definitiva, ma subito utilizzabile per verificare e riflettere (in caso) su quanto vi è di pubblicato online.
La scalata verso l’interoperabilità dei Linked Open Data è fatta di tanti passaggi intermedi, di piccoli passi che conducono ad ogni stella; tali passi possono esser considerati come check (non consecutivi ma necessari al superamento di ogni obbiettivo) da spuntare e da utilizzare come mezzo di verifica e di valutazione dello stato della pubblicazione, mezzo utile sia per chi consulta che per chi pubblica i dati.
Da pubblicatore ed utilizzatore di dati propongo una possibile checklist, estendibile e modificabile in ogni sua parte, delle attività e verifiche necessarie al raggiungimento dei diversi livelli di interoperabilità.
★ Available on the web (whatever format) but with an open licence, to be Open Data
- specificare la data di riferimento dei contenuti pubblicati
- specificare la data di pubblicazione del dataset
- specificare se si tratta di dati “chiusi” o se prevedono un aggiornamento
- specificare chiaramente la licenza di riuso dei dati
★★ Available as machine-readable structured data (e.g. excel instead of image scan of a table)
- fornire informazioni sulla struttura dei dati
con un intervento minimo fare in modo che questi si autodefiniscano e che non siano ambigui (es. chiamando le colonne di un Excel in maniera del tutto chiara)
★★★ as (2) plus non-proprietary format (e.g. CSV instead of excel)
- tenere ben presente che un formato non proprietario non significa semplicemente “leggibile” come file di testo
un KML di google Place è un formato proprietario perché, anche se in XML, contiene informazioni necessarie (e utili solo) a google per generare la sua visualizzazione a mappa, altra cosa sarebbe pubblicare i luoghi citati corredandoli di coordinate geospaziali, e delle altre specifiche informazioni del dataset, in una qualsiasi struttura XML
★★★★ All the above plus, Use open standards from W3C (RDF and SPARQL) to identify things, so that people can point at your stuff
- verificare che la URI sia raggiungibile online
un indirizzo http://.. non è una URI utile se questo non punta a qualcosa di reale - verificare che l’accesso alla URI sia compatibile con le specifiche W3C sul content negotiation relative al formato RDF
l’utente che utilizza un browser web deve poter accedere ad una risorsa HTML; chi invece usa un client diverso e richiede un JSON deve poter accedere al formato JSON (e così via) - utilizzare URI unicamente sulla porta 80
molti enti ed istituzioni non hanno accesso a porte “non standard” come l’8890 o la 8080; di conseguenza non hanno accesso ai dati pubblicati (a meno di non cambiare i principi di sicurezza da loro definiti) - verificare di essere nelle condizioni (tecniche ed amministrative) di mantenere indefinitamente raggiungibili le proprie risorse attraverso le URI pubblicate
le redirect sono benvenute, gli errori “pagina non trovata” no - pubblicare l’ontologia descrittiva utilizzata per il proprio dataset
★★★★★ All the above, plus: Link your data to other people’s data to provide context
- utilizzare proprietà di tipo owl:sameAs anche verso dbpedia.org
considerando dbpedia.org come cuore de facto della Linked Open Data cloud, linkare le proprie risorse verso di essa significa acquisire link indiretti verso una indefinita molteplicità di altre risorse presenti oggi ed in futuro online - fornire un endpoint SPARQL per l’accesso alle proprie risorse
per consentire agli altri partecipanti alla Linked Open Data cloud di analizzare i dati pubblicati e di creare owl:sameAs verso le proprie risorse è indispensabile fornire un punto di accesso che consenta l’utilizzo di query ed API standard
