Prototype next steps

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)

Attività

• 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)
  • verificare che le parti iPA e cod_ente siano correttamente specificate nella descr. progetto in RDF
• 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")
• campi opzionali in RNDT e SensorML
  • modifiche ai template
    • creazione codelist "MD_CharacterSetCode" per elemento "Set di caratteri dei metadati"
  • eventuali modifiche al codice (foglio di stile, javascript, java):
    • indicare in forma diversa il campo mandatorio
    • inserire in SensorML Template i campi help
• campi multipli (non annidati)
• punti di contatto esterni a Ritmare (non supportati cioè da base di dati RDF)
• keyword da vocabolari controllati
  • 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)
• autenticazione utente (anche per OSK!)
  • modifica profilo utente
  • account limitati al nodo periferico (es. per studenti)
• versione multilingue (bilingue?) dell'interfaccia
• versione multilingue (bilingue?) dei metadati
• import generalizzato di metadati esistenti
• items dipendenti da altri valori selezionati (es. website dipendente dalla scelta dell'istituto associato all'utente)
• items annidati
• eliminazione o ridenominazione campi in SensorML
• 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.

• duplicazione record di metadati per metadatare dataset o sensore simile
• metadatazione RNDT delle osservazioni di sensori -> possibile intergrare i due starter kit? ripercussioni su tutto il lavoro lato OSK
• navigazione gerarchica dei termini nei campi di tipo autocompletion
• validazione ISO e/o INSPIRE e/o RNDT
• il testo dell'help dovrebbe essere o sempre subito dopo il nome o sempre subito dopo il campo da editare
• implementare datatype dateRange (anche valido per SensorML)
• 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
• revisione etichette del form e biliguismo
• inserire campi help nei template EDI sia opzionali che mandatori
• definire la call for application (fine Marzo) e lanciarla
• integrazione definitiva tra EDI e GeoStarterKit
• Interfacce di MD con miglioramento dell'automatizzazione
• aggiunta backdoor sugli starter kit per monitoring e gestione metadati per harvesting

Attività ad alta priorità

• modifica metadati esistenti
  • verifica allineamento nuova versione metadati - record pyCSW
    • domanda: questo dipende da posizione nell ISO dell'id generato da GeoNode? è sufficente per garantire allineamento?

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

Dalla discussione post-meeting di mercoledì 29/1, una autenticazione centralizzata pare il modo migliore di evitare il proliferare incontrollato (cioè senza l'imprimatur della call da parte nostra) 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.

• verifica discovery attraverso pyCSW
• modifica CSS per distinguere campi mandatori e opzionali
• verifica registry SensorML 52N da locale e da remoto (come dice Cristiano) o lato-client e lato-server (come dice Monica)
• validazione formati di input GSK (manca prj? -> repository, nome file sbagliato?, proiezione mancante nel geotiff? ecc.)
• validazione fogli di calcolo di input per OSK
  • collegamento con editing metadati delle osservazioni

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