View source for IMOS 2014: lessons learnt

= Infrastruttura IMOS =
Il portale è accessibile al seguente [http://imos.aodn.org.au indirizzo].

== Considerazioni generali ==
Nella nuova versione del portale, IMOS ha posto l’accento su due elementi che sono risultati critici nella precedente implementazione:
* l’usabilità del portale di accesso
* la facilità di scaricamento dei dataset individuati nella discovery
Credo che il risultato sia efficace dal punto di vista dell’usabilità. Una pecca il fatto che l’interfaccia non sia “responsive”, non si adatti cioé a device differenti dal browser per PC (anzi, per ora non è proprio visualizzabile sul browser di Android, ad Ale o Monica la verifica su iOS).
Lo sviluppo server-side si basa su [http://groovy.codehaus.org/ Groovy] (una versione “agile” di Python, simile a Django ma che viene eseguita nella JVM) con 7 sviluppatori che lavorano secondo la metodologia SCRUM con cicli di sviluppo di due settimane e un contatto abbastanza costante con l’utente finale che testa le varie release. L’architettura riportata sul portale non è del tutto aggiornata.
I metadati rispecchiano [http://www.aodc.gov.au/files/MarineCommunityProfilev1.4.pdf ISO 19115 Marine Community Profile] e vengono compilati con un editor non ai livelli di come sarà EDI nel prototipo ma comunque anni luce avanti rispetto a quello di AADC (to be described...).

== Discovery di risorse ==
La discovery viene articolata in tre fasi successive:
# selezione di un dataset specifico
# identificazione dell’eventuale sottoinsieme del dataset di interesse per l’utente
# scaricamento della risorsa

=== Selezione di un dataset specifico ===
La selezione avviene specificando uno e un solo elemento in uno o più dei cinque box che consentono di specificare:
* il parametro osservativo di interesse
* il fornitore del dato
* la piattaforma utilizzata per la raccolta del dati
* l’intervallo temporale di interesse
* il poligono di interesse su di una mappa
I primi tre elementi possono essere selezionati da una lista indicante il numero di dataset che corrisponde alla singola scelta. La selezione di un elemento da una delle liste produce l’aggiornamento delle altre. Il quarto elemento consiste in due datepicker (che mi sembrano efficaci anche per serie storiche, forse quelli di EDI non lo sono altrettanto, non riesco al momento a verificarlo). Il quinto consente di tracciare il poligono di interesse su di una mappa: questa funzionalità la considero più attinente alla “fase 2” dell’interfaccia, quella per la selezione di un subset, dato che tutti i dataset hanno la classica bbox rettangolare.

    Nota: la selezione del parametro:
In IMOS, il numero di parametri è ridotto, al punto di poter essere enumerato in una lista, e meditano di strutturarlo nel prossimo futuro in due livelli, in modo da non avere più di venti elementi sul primo livello. Questo era presumibile nell’interfaccia di discovery (dove si possono mostrare solo i parametri che corrispondono a dataset esistenti nel catalogo) ma risulta tale anche nell’interfaccia di editing dei metadati. 
Per il prototipo, noi consentiamo la selezione (via autocompletion, non tramite lista) tra circa 400 parametri, che costituiscono oltretutto il primo livello in quanto il secondo ne potrebbe contenere circa 80.000 (al momento il secondo livello non è incluso nel triple store perché a) si voleva massimizzare le prestazioni e b) si dovrebbe consentire il raffinamento della scelta del parametro in “passi” successivi, per non riempire la lista di termini suggeriti con istanze dello stesso parametro rilevato però con metodi differenti).

La sovrabbondanza dei parametri forniti da SeaDataNet è la causa principale della loro scelta di basarsi su di una lista di parametri personalizzata e ristretta al minimo; la stessa critica è stata mossa da altri (es. Scott Bainbridge), che meditano anche loro di utilizzare una lista di parametri altenativa e più limitata. Io non sono di questo avviso e penso invece che la maggiore interoperabilità che si può ottenere facendo riferimento a terminologie ben radicate nel dominio valga lo sforzo maggiore da parte dello sviluppatore nel trovare meccanismi di selezione del parametro che siano efficaci per l’utente (l’autocompletion gerarchica che Monica ed io abbiamo pensato sarebbe un meccanismo più che efficace per selezionare termini nelle terminologie SeaDataNet).

Bisogna poi considerare che i parametri proposti da IMOS sono contenuti in un tradizionale RDBMS secondo uno schema ad-hoc (il loro architetto software inizia solo ora a muovere i primi passi nel mondo di RDF) mentre noi, a fronte del maggiore sforzo di cui sopra, siamo in grado di utilizzare direttamente terminologie di SeaDataNet, con giusto qualche modifica nella strutturazione di thesauri e collezioni di termini.

    Nota: l’aggiunta di parametri e, in generale, entità nel triple store:
La scelta di IMOS di basarsi su di una shortlist di parametri implica che ci si possa facilmente trovare nelle condizioni di dover inserire un nuovo parametro (operazione eseguita dall’utente durante l’editing dei metadati). Questa resta comunque una eventualità possibile anche nel nostro caso e generalizzabile a mio giudizio all’inserimento di una nuova keyword da vocabolario controllato (in un ipotetico thesauro Ritmare, anziché inserire una keyword a testo libero), all’inserimento di un nuovo toponimo nel gazetteer (per ora largamente terrestre, non marino), all’inserimento di un nuovo istituto, di un nuovo individuo, ecc. 

Di fatto sono tutte informazioni nel medesimo formato (RDF) e nello stesso repository (il nostro triple store) che differiscono solo per lo schema di dati utilizzato.
Per la generalità della problematica, tenderei a riutilizzare una astrazione secondo template, analoga a quella utilizzata in EDI, che non produca in questo caso XML come output bensì una più generale query SPARQL che provveda a inserire o modificare una data entità nel triple store. Se fosse già solidificato uno schema di dati per rappresentare in RDF i metadati che EDI restituisce come RNDT e SensorML, si potrebbe realizzare al contempo la modifica di metadati RNDT e SensorML secondo lo stesso principio. Per questo è necessario:
* per RNDT: scoprire se il profilo INSPIRE per l’[https://open-data.europa.eu/en/data/ Open Data Portal] è pronto ed estenderlo fino a coprire tutti gli elementi di RNDT
* per SensorML: indagare le corrispondenze tra gli elementi previsti da SensorML e quelli previsti dalla [http://www.w3.org/2005/Incubator/ssn/ssnx/ssn Semantic Sensor Network Ontology] e dalla [http://ceur-ws.org/Vol-1063/paper4.pdf Sensor Cloud Ontology].

=== Identificazione di un sottoinsieme del dataset ===
La fase 2 della discovery ripropone essenzialmente il quarto e quinto elemento specificabili nella fase precedente. 

    Nota: discovery nell’interfaccia Ritmare
Secondo me è possibile (e necessario) fare di meglio nell’interfaccia di accesso alle risorse Ritmare. Innanzitutto abbiamo due modalità di accesso alternative, non necessariamente posizionabili in un workflow di fasi successive:
* accesso secondo il paradigma who-what-where-when dove:
** who: è predefinito secondo le credenziali di accesso dell’utente (elemento in grado di modificare il ranking dei risultati, non tanto l’insieme di questi) oppure nullo nel caso di accesso anonimo
** what: andrebbe selezionato tra i parametri disponibili (idealmente, il sottoinsieme di parametri per i quali esiste almeno un dataset corrispondente nel catalogo) e, nel caso la stringa inserita non corrisponda a nessuno di essi, che questa venga utilizzata per la semplice ricerca testuale nei metadati (anche nel caso venga identificato un parametro nel thesaurus di riferimento, questo dovrebbe comunque innescare una o più ricerche a testo libero nei metadati)
** where: personalmente non amo tracciare bbox o poligoni, riterrei più semplice scrivere “200km a sud di Venezia”, ottenendo una lista di opzioni (stile google maps) nel caso si riscontri ambiguità e magari visualizzare in una mappa a cosa corrisponda ciascuna opzione. Alcuni radio buttons potrebbero consentire di dimensionare la bbox che viene posizionata 200km a sud di Venezia secondo grandezze predefinite oppure, per i più precisini, si può consenitre il ridimensionamento e riposizionamento della bbox sulla mappa
** when: la selezione di un intervallo temporale con slider tarabili secondo giorni, mesi o anni mi pare efficace come user interaction, comunque anche i datepicker del portale IMOS sono molto efficaci nel consentire questa flessibilità
* accesso secondo i facet values che si possono ricavare dai metadati, una lista non esaustiva la seguente:
** lingua dei metadati e/o dei dati
** ente responsabile del metadato e/o del dato (in RNDT ci sono quattro entità di questo tipo, che mi sembrano troppe)
** formato di presentazione
** categoria tematica
** tema INSPIRE
** tipo di rappresentazione spaziale
** vincoli di accesso/fruibilità/sicurezza

=== Scaricamento della risorsa ===
La risorsa può a questo punto essere scaricata in tre formati differenti:
* CSV
* NetCDF (come ZIP contenente tutti i files)
* lista di URL ai file NetCDF


= Infrastruttura AADC =

Il portale è accessibile al seguente [http://data.aad.gov.au indirizzo] nella sezione “My science” e richiede registrazione.

== Considerazioni generali ==
Il gruppo di lavoro si occupa dei dati prodotti dall’Australian Antarctic Science Program e da altri quattro temi di minore entità. Eseguono un mix di lavoro tecnico e amministrativo. Il portale mette a disposizione poco più di 2.000 record di metadati, che non è poco ma nemmeno “big data”. Affermano che il 50% dello sforzo da loro sostenuto nella creazione dell’infrastruttura sia stato dedicato all’educazione degli utenti che hanno dovuto imparare ad utilizzare nuovi strumenti per mettere a disposizione dati e metadati.

Mettono a disposizione WMS e non hanno ancora servizi SOS. Contribuiscono al Tide Gauge Network attraverso GCMD (NASA) ma anche ad altri programmi (AODN, GBIF, OBIS). Gesticono sorgenti dati distribuite attraverso la piattaforma [http://sourceforge.net/projects/digir/ Distributed Generic Info Retrieval]. Da quello che ho capito, hanno un solo programmatore che si occupi dell’infrastruttura, sviluppata in Django.
== Data policy ==
Al di là dell’infrastruttura, che non mi è parsa degna di particolare nota, ho trovato interessante il fatto che prevedano penali (non ho capito se finanziarie o altro) per i data provider che non inseriscano i loro dati nell’infrastruttura entro i tempi prestabiliti. Mettono in relazione i dataset con le pubblicazioni che li riguardano e la pubblicazione di articoli da parte di chi ha raccolto i dati pone fine al periodo di “embargo” per i dati, che divengono quindi disponibili a terzi. L’assegnazione di un DOI ai dataset è utilizzata come incentivo per spingere i data provide a fornire i dati raccolti.
    Nota: Dati e pubblicazioni
Il legame che viene creato tra dati e pubblicazioni relative e il peso che questo ha nelle data policy è interessante. Può essere uno spunto per Ritmare?
== Metadati ==
Utilizzano il [http://www.dcc.ac.uk Directory Interchange Format], che dovrebbe essere compatibile con ISO. L’editor di metadati è orribile e molto poco user-friendly (al punto di concedere ai data provider l’opzione di fornire i metadati un un documento Word che viene poi trasferito nel formato XML di riferimento). Utilizzano però vocabolari controllati per parametri, piattaforme, strumenti, unità di misura presi da SeaDataNet. AADC ha predisposto un workflow specifico per l’inserimento di nuovi termini qualora, nella compilazione dei metadati, non venga trovato un termine adeguato. L’interfaccia è in grado di segnalare quali siano i termini da creare (immagino per quanto riguarda le keyword, non in testo libero come titolo o abstract).
    Nota: gestione di vocabolari controllati
Sia IMOS che AADC hanno parlato di inadeguatezza dei vocabolari controllati da loro utilizzati e quindi della necessità di complementarli con vocabolari proprietari. L’ipotesi di eliminare del tutto la nozione di free-text keyword da Ritmare è interessante e si lega a quanto detto nella precedentemente riguardo la creazione di nuove strutture dati RDF (delle quali i termini da vocabolari controllati sono una parte). Questo potrebbe avvenire durante l’editing di metadati oppure ex-post, segnalando la lista di free-text keyword che potrebbero entrare a far parte del vocabolario controllato di Ritmare.

= Chat w. Heiko Mueller @CSIRO =
La chiacchierata con Heiko Mueller è stata, da una parte, molto interessante per il panorama di prospettive sulla metadatazione di sensori che ha offerto. Dall’altra, il contatto è di scarso utilizzo per sviluppi futuri in quanto a giugno Heiko cambierà completamente contesto e non si santa quanto CSIRO abbia intenzione di proseguire il progetto che segue.
Heiko, insieme ad un collega che tuttavia era assente nei giorni in cui eravamo a Hobart, si occupa degli aspetti strettamente sistemistici della metadatazione di sensori. Utilizzano a questo proposito un database noSQL (MongoDB) all’interno del quale i record vengono memorizzati nel formato JSON e resi disponibili attraverso un servizio RESTful.

La ragione di questa scelta rispetto a SensorML è relativa all’eccessiva complessità di quest’ultimo: ritenendo poco utili ai loro scopi molti dei costrutti che SensorML prevede, hanno deciso di metadatare i sensori secondo un formato alternativo. Una alternativa che hanno nel tempo preso in considerazione è lo [http://portal.opengeospatial.org/files/?artifact_id=44438 *FL Starfish Fungus Language for Sensor Description].
Il motivo per preferire invece JSON rispetto ad un altro formato di codifica, in particolare RDF, è esclusivamente legato alle prestazioni (per quanto altre sedi di CSIRO, ad es. Camberra, utilizzino già RDF in modo estensivo per metadatare i sensori). Comunque, il formato JSON utilizzato può essere mappato sulla [http://ceur-ws.org/Vol-1063/paper4.pdf Sensor Cloud Ontology], di per se una estensione della [http://www.w3.org/2005/Incubator/ssn/ssnx/ssn Semantic Sensor Network Ontology] sviluppata dal W3C.

    Nota: una rappresentazione RDF dei sensori

A mio giudizio, rappresentare secondo un qualche formato RDF le informazioni relative ai sensori (codificate come SensorML nello SK) è importante perchè consentirebbe di utilizzare questa informazione anche a livello di repository centralizzato di RITMARE.
Ad esempio, volessimo utilizzare le informazioni relative a piattaforme/strumenti ecc. nella organizzazione di crociere (in RITMARE, piuttosto che nella proposta H2020 che ci si augura di organizzare con Roger Proctor) tornerebbe molto utile disporre di una simile rappresentazione.