Difference between revisions of "Prototype next steps"

Latest revision as of 11:19, 4 February 2014

Proposta operativa

• definizione attività per la release del prototipo finale e suddivisione di queste tra necessarie e opzionali
• individuazione di chi se ne può occupare, delle possibili sovrapposizioni di persone e delle eventuali precedenze tra attività
• quantificazione effort necessario in maniera astratta (es. da 1 a 5) da parte delle persone individuate al punto precedente
• suddivisione attività in gruppi di funzionalità da realizzarsi in un lasso di tempo (es. nell'arco di una settimana)
• verifica/aggiustamento dello stato di avanzamento, dei tempi e delle attività da portare a termine con scadenza fissa (ogni settimana)

Unificazione degli Starter Kit

TUTTI i partecipanti (Pepe, Fugazza, Pavesi, Oggioni, Bastianini, Menegon, Basoni) concordano sul fatto che lo StarterKit (SK) diventi unico. Non vengono individuate problematiche relative alla compatibilità software.

Attività ad alta priorità

• CF+AO: modifica dell'insieme di metadati richiesti dall'interfaccia (modifica dei template)
  • CF: creazione codelist mancanti
  • AO: eliminazione o ridenominazione campi in SensorML
  • CF+AO+MP: revisione etichette del form ed eventuale biliguismo
  • CF+AO+MP: inserire campi help nei template EDI sia opzionali che mandatori
  • FP: eventuali modifiche al codice (foglio di stile, javascript, java):
    • AO+FP: definire se occorre utilizzare per il prototipo caratteristiche di campi nidificati
  • SM: verifica dell'allineamento tra la versione aggiornata dei metadati e il record pyCSW che viene generato
    • domanda: questo dipende dalla presenza e/o dalla posizione nell ISO dell'id generato da GeoNode? è sufficente per garantire allineamento?
    • AO: verificare se il SensorML esteso prodotto dal template sia utilizzabile per la request RegisterSensor di 52°N

Alcune osservazioni: A noi interessa mantenere, anche nelle revisioni successive, la componente semantica (gli URI) che sono assenti nell'XML ISO ma che si trovano nella quasi-copia del template che viene attualizzato con le scelte dell'utente (e che si troverà sia lato-client che lato-server). Quindi, l'unica possibilità mi pare quella di costruire l'interfaccia (la seconda e successive volte) con i metadati già inseriti a partire da questo file. Di qui la proposta:

Action (Cristiano + Fabio): studiare una estensione della sintassi del template che possa esprimere questa informazione.

A questo punto, EDI potrebbe ricevere come parametro l'id del metadato o del dato, che se precedentemente utilizzato per nominare il file suddetto, potrebbe essere sufficente a fornire a EDI i dati necessari. Vi pare manchi qualcosa?

• gestione autenticazione utente
  • modifica profilo utente (potrebbe essere considerato a bassa priorità sse avremo modo di aggiornare le installazioni di Starter Kit da remoto)

Dalla discussione post-meeting di mercoledì 29/1, una autenticazione centralizzata pare il modo migliore di evitare il proliferare incontrollato (cioè senza l'accetazione da parte nostra a seguito della risposta alla call da parte del content provider) di installazioni. Dato che esiste cmq l'esigenza di lasciare ai gestori di un nodo periferico la possibilità di creare account in locale (senza accesso alla futura infrastruttura e senza possibilità di aggiungere dati e metadati, altrimenti siamo punto e a capo), converrebbe vedere se le due cose si possano combinare in modo elegante, ad esempio integrando una qualche forma di autenticazione federata con i nostri requisiti aggiuntivi. Propongo quindi:

Action (Cristiano + Stefano): veloce survey dei sistemi di autenticazione federata, esame di come avviene l'autenticazione in GeoNode e studio di una soluzione appropriata.

Alternativa: il seguente paper descrive un sistema di autenticazione RESTful che consentirebbe anche di associare fin dagli Starter Kit l'autenticazione dell'utente al suo descrittore FOAF. Potremmo restringere la creazione di account sugli Starter Kit alla sola ricerca/visualizzazione di risorse (non consentendo cioè di inserire nuovi dati e relativi metadati) e appoggiarci sulla autenticazione centralizzata per le attività di data entry. Che ne pensate? Varrebbe forse la pena verificarne l'evoluzione da quando è stata formulata.

• SM: verifica discovery attraverso pyCSW
• SM: modifica CSS per distinguere campi mandatori e opzionali
• AO: verifica registry SensorML 52N da locale e da remoto (come dice Cristiano) o lato-client e lato-server (come dice Monica)
• SM: validazione formati di input GSK (manca prj? -> repository, nome file sbagliato?, proiezione mancante nel geotiff? ecc.)
• AO: validazione fogli di calcolo di input per OSK
  • collegamento con editing metadati delle osservazioni
• FP: modifica sintassi URN: contrariamente a quanto specificato da RNDT, gli URN iniziano sempre con la stringa "urn:", quindi la sintassi finale dovrebbe essere "urn:" + iPA + ":" + cod_ente + ":" + timestamp + ":" + numero progressivo
  • verificare la compilazione automatica degli URN nel template di SensorML (es. "urn:" + iPA + ":" + cod_ente + ":" + timestamp + ":" + numero progressivo + ":" + nome parametro input/output)
  • CF: verificare che le parti iPA e cod_ente siano correttamente specificate nella descr. progetto in RDF
• CF: verificare se gli URN in "identificatore del file" (il metadato) e "identificatore" (il dato) non debbano essere differenti (a livello di validazione ISO potrebbero non esserlo)
  • si potrebbe eliminare il problema assegnando a "identificatore" il parametro "uid" passato da GeoNode (attualmente, pare, assegnato a "identificatore del file")
• FP: campi multipli (non annidati)
• CF+FP: punti di contatto esterni a Ritmare (non supportati cioè da base di dati RDF)
• CF+FP: keyword da vocabolari controllati
  • CF+tutti i partner interessati: individuazione thesauri di riferimento e loro codifica in SKOS
  • verificare in SeaDataNet quali possono fare al caso (verificare quali sono i vocabolari usati da Elena Partescano nella compilazione del SensorML di Mambo1)
  • unità di misura verificando se il vocabolario controllato usato è anche compatibile con CF/unidata (chiedere Cristina Tronconi)

• (T) FP: import generalizzato di metadati esistenti
• (T) CF+FP: items dipendenti da altri valori selezionati (es. website dipendente dalla scelta dell'istituto associato all'utente)

Nota: mantenendo un solo istituto per ogni persona in Ritmare, potremmo spostare l'attività tra quelle a bassa priorità me per altri campi dei metadati (es. keyword da vocabolari controllati) il problema si riproporrebbe.

• (T) FP+SM: duplicazione record di metadati per metadatare dataset o sensore simile
• (T) FP: il testo dell'help dovrebbe essere o sempre subito dopo il nome o sempre subito dopo il campo da editare
• (T) FP: implementare datatype dateRange (anche valido per SensorML)
• (T) FP+AO: importazione dati osservativi attraverso fogli elettronici (evitare campi predefiniti, importazione campi da altri form, ecc.)
  • raccogliere informazioni quali URN sensore e Nome parametro in output da SensorML, mentre unità di misura da lista controllata
  • per gli altri campi (Time, Value, X, Y e LongName Station) menù a tendina che permette all'untente di scegliere dal proprio file
• (T) PC: definire la call for application (fine Marzo) e lanciarla
• (T) FP+SM: integrazione definitiva tra EDI e GeoStarterKit
• (T) FP: aggiunta backdoor sugli starter kit per monitoring e gestione metadati per harvesting

Attività a bassa priorità

• estensione knowledge base per specifiche direttiva Inspire in altre lingue (necessario per definire metadati in un'altra lingua): possibile limitarsi a it ed en?
  • modifica conseguente del template RNDT
  • compilazione campo dipendente dalla scelta lingua
  • attualizzazione termini da codelist conseguente a cambiamento lingua metadati
  • verificare implementazione del multiliguismo nel seguente documento
    • verificare se, modificato un metadato per includere elementi in un'altra lingua secondo il documento, questo venga a) digerito cmq da GeoNode e b) funzioni la discovery secondo i termini nella lingua addizionale.
• creare XML Schema per creazione template
• caricamento TIN???
• verifica esistenza metadati propri di O&M
• (T) versione multilingue (bilingue?) dell'interfaccia
• (T) versione multilingue (bilingue?) dei metadati
• (T) navigazione gerarchica dei termini nei campi di tipo autocompletion
• (T) validazione ISO e/o INSPIRE e/o RNDT

Nota: una volta che i metadati vengono correttamete processati dai cataloghi di rifermento (GeoNode, 52N) potremmo ritenerci a posto. Se cmq l'attività passasse ad alta priorità, sarebbe meglio.

• (T) items annidati

Nota: l'attività diviene ad alta priorità se i campi annidati sono necessari a sensori "atomci", che non rappresentino cioé gruppi di sensori (vedi item che segue).

• (T) granularità sensori e loro combinazione in gruppi: analogia con series e timeseries (AO: NON CAPISCO???)

Spiega: era emersa la necessità di avere descrizioni per gruppi di sensori (es. una intera piattaforma, la dotazione di una nave, ecc.) ma anche di metadatare il singolo sensore come entità specifica (CF: oppure ho capito male io?). Mi pare di aver capito che SensorML possa rappresentare gli uni e gli altri, ma vorrei capire quanto, escludendo uno dei casi, si possa ridurre le modifiche necessarie a EDI per gestire campi annidati. Infatti, per la parte GSK, abbiamo accettato l'approccio di GeoNode dove tutti i dati sono flat e rimandato la gestione di series e timeseries a livello infrastruttura. Mi chiedevo se, applicando il medesimo approccio ai sensori, non fosse possibile rimandare la gestione di gruppi di sensori.

• (T) Interfacce di MD con miglioramento dell'automatizzazione