IMOS 2014: lessons learnt
Contents
Infrastruttura IMOS
Il portale è accessibile al seguente 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 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 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 è 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 con un libro che io stesso gli ho passato) 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’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 Semantic Sensor Network Ontology e dalla 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 cmq 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, cmq 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