Difference between revisions of "Meeting DevelopmentTeam SK - 06- 05-2014"

Latest revision as of 16:34, 6 May 2014

Pavesi se uno scrive in uno l'altro viene svuotato, non ci possono essere entrambi, manca la verifica dell'obbligatorietà del campo nel suo complesso; mancano controlli (che sia data...ecc); mentre manca l'altro aspetto: modifica di un EDIML esistente funziona con la modifica per i campi singoli, manca la generazione dei campi nuovi quando vi è la possibilità di metterne più di uno (multipli). Conta di terminare questi aspetti per oggi.

Viene chiesto se sia possibile verificare la conformità con gli standard dei MD, sì ma dopo questa ultimo deployment di oggi (aggiornare il sistema su IREA). Manca ultimo miglio validazione ml generati(quando finito fai sapere che così Fugazza e Pepe lo testano); e manca sensor ML quando Oggioni rilascai il template. Bisogna controllare inoltre errori in EDI, help su firefox si vede su crome no. Da verificare. Da controllare anche i punti di domanda al posto degli accenti ma problema di maquillage che si affronterà alla fine. Ci serve una versione definitiva per il pre test utente "stupido" (da sottoporre a Basoni, Carrara) ideale sarebbe per il 13 - 14 maggio e per il test di validazione (da sottoporre a Fugazza Pepe).

Oggioni proposta di nuovo workflow: non più differenziazione tra la pagina che appare all'utente di registrazione del sensore, inserimento di osservazioni, ma c'è un elenco di sensori esistenti e da lì si accede alla pagina di EDI con registrazione del sensore oppure scorrendo una lista di sensori esistenti aggiungerlo.

Menegon: è d'accordo con proposta di Oggioni su nuovo workflow. ci sono le librerie (get capabilities, describe sensors), sperimentato JSON per un core di base, nella nuova release 52 N 4.0 (nonostante la versione è stata però dichiarata stabile), adesso bloccata perché ci sono dei problemi sul ricevere correttamente i risultati di describe sensor, difficoltà a far funzionare il server, è il server che non risponde alla request adeguatamente. Si devono fare ancora prove e poi, in caso scrivere alla lista per avere informazioni. Discussione in merito ai costi del "piano b" ovvero tornare alla soluzione precedente che va integrata in SK. Viene ribadito che ha un costo non trascurabile tornare indietro. Si sottolinea come se dobbiamo fare una recovery bisogna farla entro il 15 maggio.

Autentificazione Server

gestione anagrafica controllata da EDI: elenco filtrato attraverso una API che richiede il filtro al servizio, che è passato all'editor che risiede sullo starter kit questo ha bisogno dell'autenticazione, ma potrebbe essere la stessa API che riceve la chiave più pratico metterlo nel JavaScript che chiama Virtuoso e genera l'editor; che aiuta controllo su IP;

proposta di Stefano: che lo faccia il server che chiama EDI nello starter kit, dall'IP del server richiesta sull'API con la chiave, così controllo sull'IP Persone coinvolte: Stefano e Fabio

Stato autenticazione

Proposta: aggiungere la possibilità di inserimento esterni (Maggi, Proctor) trattati come utenti di Ritmare con un virtuoso dedicato cambiando l'end point, oppure stesso virtuoso e cambio tesauro a cui punta; nel primo caso solo una variabile; per ora priorità abilitare l'inserimento in EDI dell'esterno. Persone coinvolte: Fabio, con supporto di Stefano e di chiunque si candidi Deadline: dopo aver finito con EDI

Help e supporto a SK

Stato: in sviluppo: Basoni e Pepe ci lavoreranno durante il viaggio per Venezia

help

stato: pending, si concluderà quando i template dei MD saranno definitivi priorità su sensorML Persone coinvolte: Monica, Anna B.

supporto agli SK

Stato: in sviluppo

Licenza SK

Stato: pending
Si fa seguito alla proposta di Carrara durante la riunione del 23.04 scorso, di semplificare la proposta iniziale foggiando la licenza sullo stile di OpenLocast-Web del MIT (https://github.com/mitmel/OpenLocast-Web) e completandola con i disclaimer riguardanti le responsabilità dei gestori del nodo. Persone coinvolte: Carrara & Oggioni
Pepe informa che Seadatanet si è dotata di una licenza e policy (durante presentazione a EGU) controllare il loro flusso di dati, accesso non diretto ma filtrato, non solo autentificazione ma anche richiesta.

Stato call of participation

Generata in tempo reale la versione in inglese http://sp7.irea.cnr.it/cfp/index_en.html Al momento ci sono state sottoposte on-line (call for participation results) 6 candidature: OGS
CINFAI Università di Camerino (Carlo Bisci)
CNR-ISMAR u.o.s. La Spezia

CNR - ISMAR U.O.S. di Pozzuolo di Lerici (SP)

ISMAR Lesina

ISMAR Bologna

Riepilogo elenco papabili aderenti alla call con tutorship
Mancanti (eventualmente da sollecitare)

ISMAR Venezia pta e boe, tutor Minuzzo e Bastianini
ISMAR Venezia Comune livello acqua alta, resp Papa, tutor Bastianini Minuzzo (chiedere a Mauro che solleciti)
ISMAR Bologna, dati batimetrie Matricardo-Campiani, resp Matricardo; tutor Sarretta-Menegon
ISMAR Venezia Adriplan, dati stakeholder, resp Barbanti; tutor Sarretta-Menegon (chiedere a Sarretta di sollecitare Barbanti)
IREA Napoli, dati subsidenze, resp Fornaro; tutor Tagliolato & Oggioni; i dati sono stati inviati e sono all'esame di Oggioni & Tagliolato
IREA Milano, dati costa Oristano; resp Giardino; tutor Criscuolo/Pepe
ISSIA Bari, resp Patrizia Adamo; tutor Tagliolato (sollecita Pepe)
Scardi (alias Marine Strategy): da valutare se sollecitare perché a seguire potrebbero aggregarsi tutte le università, con problemi di sostenibilità

Registrati:

ISMAR Lesina, resp Raffaele D'Adamo; tutor Vianello
ISMAR La Spezia, resp Mantovani, rete dei radar costieri
ISMAR Lerici, YO Yo, dati Canale di Corsica, resp. Catia Chiappini, tutor Oggioni
ISMAR Bologna(dati anche crociera Bortoluzzi, resp Ravaioli, tutor Sarretta, Oggioni

Varie ed eventuali

Aggiornamento su Griffa, Corgnati

Da definire prossima riunione, se si riesce a Venezia.

@@ Line 1: / Line 1: @@
 === Presenti (via skype) ===
-* IREA: Carrara, Fugazza, Oggioni, Pavesi, Pepe
+* IREA: Basoni, Carrara, Fugazza, Oggioni, Pavesi, Pepe
 * ISMAR: Menegon
 === Ordine del Giorno ===
-# Aggiornamenti Partecipazione evento Venezia: Basoni (9 maggio), Pepe (8 maggio), Menegon, Carrara, Fugazza, Pavesi, Tagliolato (entrambi i giorni); A. Oggioni provvede a prenotare albergo
+# Partecipazione incontri Venezia
 # stato EDI (in particolare editing di EDIML pre-esistenti e “nuovo” SensorML)
-# stato integrazione EDI in SK
-# stato integrazione SOS in SK (con nuova implementazione 52N)
 # stato tool di autenticazione
 # stato help e supporto
 # stato licenza
 # stato call of participation e decisioni relative
+=== Partecipazione incontri Venezia ===
+* Basoni, Pepe (9 maggio), Menegon, Carrara, Fugazza, Oggioni, Pavesi, Tagliolato (entrambi i giorni); A. Oggioni provvede a prenotare albergo per tutti
 === stato EDI ===
-* Pavesi se uno scrive in uno l'altro viene svuotato, non ci possono essere entrambi, manca la verifica dell'obbligatorietà del campo nel suo complesso; mancano controlli (che sia data...ecc); mentre manca l'altro aspetto:  modifica di un ml esistente funziona con la modifica con i campi singoli, manca generare quando sono multipli.
+* Pavesi se uno scrive in uno l'altro viene svuotato, non ci possono essere entrambi, manca la verifica dell'obbligatorietà del campo nel suo complesso; mancano controlli (che sia data...ecc); mentre manca l'altro aspetto:  modifica di un EDIML esistente funziona con la modifica per i campi singoli, manca la generazione dei campi nuovi quando vi è la possibilità di metterne più di uno (multipli). Conta di terminare questi aspetti per oggi.
-Conta di terminarlo per oggi. deve aggiornare il sistema in IREA.
+Viene chiesto se sia possibile verificare la conformità con gli standard dei MD, sì ma dopo questa ultimo deployment di oggi (aggiornare il sistema su IREA). Manca ultimo miglio validazione ml generati(quando finito fai sapere che così Fugazza e Pepe lo testano); e manca sensor ML quando Oggioni rilascai il template.
-Manca ultimo miglio (quando finito fai sapere che così Fugazza e Pepe lo testano); bisogna  controllare errori in EDI, help su firefox si vede su crome no.
+Bisogna  controllare inoltre errori in EDI, help su firefox si vede su crome no. Da verificare.
+Da controllare anche i punti di domanda al posto degli accenti ma problema di maquillage che si affronterà alla fine.
+Ci serve una versione definitiva per il pre test utente "stupido" (da sottoporre a Basoni, Carrara) ideale sarebbe per il 13 - 14 maggio e per il test di
+validazione (da sottoporre a Fugazza Pepe).
-* Oggioni proposta di workflow
+* Oggioni proposta di nuovo workflow: non più differenziazione tra la pagina che appare all'utente di registrazione del sensore, inserimento di osservazioni, ma c'è un elenco di sensori esistenti e da lì si accede alla pagina di EDI con registrazione del sensore oppure scorrendo una lista di sensori esistenti aggiungerlo.
-Menegon: ok ci sono le librerie, sperimentata in JS nuova release 4.0, adesso bloccata perché ci sono dei problemi sul ricevere correttamente i risultati di describe sensor, difficoltà a far funzionare il server, d'accordo con AO su work flow. è il server che non risponde alla request. ancora prove e poi scrivere alla lista. piano b è la soluzione precedente che va integrata in SK. ha un suo costo tornare indietro.
+Menegon: è d'accordo con proposta di Oggioni su nuovo workflow. ci sono le librerie (get capabilities, describe sensors), sperimentato JSON per un core di base, nella nuova release 52 N 4.0 (nonostante la versione è stata però dichiarata stabile), adesso bloccata perché ci sono dei problemi sul ricevere correttamente i risultati di describe sensor, difficoltà a far funzionare il server, è il server che non risponde alla request adeguatamente. Si devono fare ancora prove e poi, in caso scrivere alla lista per avere informazioni. Discussione in merito ai costi del "piano b" ovvero tornare alla soluzione precedente che va integrata in SK. Viene ribadito che ha un costo non trascurabile tornare indietro.
+Si sottolinea come se dobbiamo fare una recovery bisogna farla entro il 15 maggio.
 === Autentificazione Server ===
@@ Line 25: / Line 31: @@
 proposta di Stefano: che lo faccia il server che chiama EDI nello starter kit, dall'IP del server richiesta sull'API con la chiave, così controllo sull'IP
 Persone coinvolte: Stefano e Fabio
-* Implementazione modulo compilazione
-stato: task in chiusura
-manca: gestione campi alternativi
-priorità: alta
-tempi: martedì 29 per RNDT, TBD per SensorML
-Passo successivo: validazione metadati RNDT (ISO e INSPIRE), loro gestione in PyCSW, validazione SensorML
-Persone coinvolte: Fabio, Cristiano, Monica, Alessandro
-*  Editing di EDIML pre-esistenti
-stato: task in chiusura
-Soluzione adottata: dalla generazione di un XML viene memorizzato l'EDIML, aggiunta di un URI all'interno del DB di EDI lato server in modo che il client lo possa richiamare, il lato di reperimento lato server è pronto
-Manca: creazione dell'interfaccia di editing e la richiesta da parte del thin client dell'URI via JS, come URL (''NDR: aiuto Fabio, ho scritto malissimo!''), da decidere (vedi sotto) se da remoto o in locale (perché anche in locale avviene la archiviazione degli EDIML compilati)
-Passo successivo: integrazione in SK
-Persone coinvolte: Fabio, Stefano
-==  Stato integrazione EDI in SK ==
-stato: in sviluppo e a cascata da [[http://sp7.irea.cnr.it/wiki/index.php/Meeting_DevelopmentTeam_SK_-_23-04-2014#Stato_EDI]]
-Soluzione attuale:
-* meccanismo di post con un proxy, dove si innesta anche la verifica del certificato dell'autenticazione del nodo sul server centrale
-* quindi inserimento dei XML generati nel CSW e archiviazione di EDIML nel repository locale
-Nel momento dell'integrazione del re-editing di MD bisognea decidere se effettuarlo sul EDIML del nodo periferico o centrale. La filosofia finora è stata quella di privilegiare il nodo centrale, per assicurare eventuali recovery (che però possono essere anche dai nodi periferici al centrale).
-Passo successivo: Controllo CSW
-In discussione: Attualmente l'inserimento di XML di datasets popola il CSW e crea i campi ISO a Geonode per funzionalità proprie come ricerca per categorie. Si discute brevemente di questo e della possibilità di intervenire sul search interno di Geonode che funziona sulle Categorie Tematiche ISO (''NDR: ho controllato in geosk ma non ho trovato riscontro: la linea di costa risulta boundary come categoria geonode, ma Oceani come Categoria tematica nel suo MD'')
-Difficile intervenire nel meccanismo di search di Geonode che è piuttosto cablato (eventualmente si può mascherarne parte), keywords a testo libero, possono essere utilizzati i temi INSPIRE. Il problema cmq non si pone, anzi che la discovery locale in GeoNode rimanga ristretta, perché la discovery principale e più completa sarà quella dell'infrastruttura centrale.
-Persone coinvolte: Stefano, Fabio
-Deadline: ???
-==  Stato integrazione SOS in SK ==
-Stato:
-subtask:
-* explore SOS per la visualizzazione dei metadati del SOS locale: completato
-* sensor registration per la registrazione sensore tramite compilazione SensorML relativo
-* upload observation per il caricamento delle osservazioni
-manca:
-* sensor registration: da EDI del nuovo SensorML
-* upload observation: ereditato dalla prima implementazione OSK (di Alessandro e Fabio) bisogna decidere se direttamente in "SQL" sul DB locale o passando dalla chiamata SOS ''InsertObservation'' con XML relativo
-In discussione: disaccoppiamento delle chiamate SOS 2.0 con un proxy server che supporta il client (''NDR: aggiungete pure'')
-Deadline: la comunicheranno Alessandro e Stefano via mail
 ==  Stato autenticazione ==
-Stato: pending, funziona la certificazione lato client (ovvero il client vede il certificato del server) ma non viceversa e non si hanno indicazioni sul perché
+Proposta: aggiungere la possibilità di inserimento esterni (Maggi, Proctor)
-Proposta: trovare una soluzione alternativa del tipo OpenID o OAuth, che fra l'altro sono abilitati già in locale su SK (in SK c'è la parte client di Python social auth che li supporta entrambi https://github.com/omab/python-social-auth)
+trattati come utenti di Ritmare con un virtuoso dedicato cambiando l'end point, oppure stesso virtuoso e cambio tesauro a cui punta; nel primo caso solo una variabile; per ora priorità abilitare l'inserimento in EDI dell'esterno.
 Persone coinvolte: Fabio, con supporto di Stefano e di chiunque si candidi
 Deadline: dopo aver finito con EDI
 ==  Help e supporto a SK ==
-Stato: in sviluppo
+Stato: in sviluppo: Basoni e Pepe ci lavoreranno durante il viaggio per Venezia
 * help
-stato: pennding, si concluderà quando i template dei MD saranno definitivi
+stato: pending, si concluderà quando i template dei MD saranno definitivi
-considerare le due lingua IT e inglese, considerando anche l'utenza internazionale
+priorità su sensorML
 Persone coinvolte: Monica, Anna B.
 * supporto agli SK
 Stato: in sviluppo
-Proposta: gestione manuale del ticketing da parte di un front-end umano (Anna Basoni), che ridiriga le questioni alle persone di riferimento adeguate e che tenga traccia dell'apertura e della chiusura degli incidenti. Obiettivo è di non intralciare chi si occupa attivamente dello sviluppo del progetto tramite:
+==  Licenza SK ==
-- gestione di un incidente per volta
+Stato: pending<br />
-- cercare di ridirezionare il più possibile gliutenti alle pagine wiki dedicate e a tutta la documentazione fornita
+Si fa seguito alla proposta di Carrara durante la riunione del 23.04 scorso, di semplificare la proposta iniziale foggiando la licenza sullo stile di OpenLocast-Web del MIT (https://github.com/mitmel/OpenLocast-Web) e completandola con i disclaimer riguardanti le responsabilità dei gestori del nodo.
-- introdurre un tutoring da parte di personale non direttamente coinvolto nello sviluppo
+Persone coinvolte: Carrara & Oggioni<br />
+Pepe informa che Seadatanet si è dotata di una licenza e policy (durante presentazione a EGU)
+controllare il loro flusso di dati, accesso non diretto ma filtrato, non solo autentificazione ma anche richiesta.
-Discussione: utilizzo di un forum oltre che di wiki?
-la possibilità di utilizzare gli strumenti di github (che fanno anche ticketing), può essere interessante e aiutare anche il coinvolgimento di realtà esterne a RITMARE; non è un vero e proprio forum ed è pubblico.
-Si decide che comunque è una buona soluzione, dato che github verrà usato anche per la distribuzione.
-Persone coinvolte: Anna, Monica e Paola (controllo qualità), ma con supporto di tutto il team
-Deadline: ???
-==  Licenza SK ==
-Stato: pending
-Discussione: La questione si fa urgente, non solo per l'imminente rilascio, ma anche per i contatti con ODIP e le collaborazioni in atto con lo stesso ed IMOS.
-Paola propone di semplificare la proposta iniziale foggiando la licenza sullo stile di OpenLocast-Web del MIT (https://github.com/mitmel/OpenLocast-Web) e completandola con i disclaimer riguardanti le responsabilità dei gestori del nodo.
 ==  Stato call of participation ==
-Al momento ci sono state sottoposte on-line ([http://sp7.irea.cnr.it/cfp/registrations.json call for participation results]) 7 candidature (OGS , CINFAI Università di Camerino, CNR-ISMAR u.o.s. La Spezia, CNR - ISMAR U.O.S. di Pozzuolo di Lerici (SP)), ma sappiamo si aggiungerà ISMAR Lesina, e poi Comune di Venezia e ARPAV
+Generata in tempo reale la versione in inglese http://sp7.irea.cnr.it/cfp/index_en.html
+Al momento ci sono state sottoposte on-line ([http://sp7.irea.cnr.it/cfp/registrations.json call for participation results]) 6 candidature:
+OGS<br />
+CINFAI Università di Camerino (Carlo Bisci)<br />
+CNR-ISMAR u.o.s. La Spezia<br />
+CNR - ISMAR U.O.S. di Pozzuolo di Lerici (SP)<br />
+ISMAR Lesina<br />
+ISMAR Bologna
+Riepilogo elenco papabili aderenti alla call con tutorship<br />
+Mancanti (eventualmente da sollecitare)
+* ISMAR Venezia pta e boe, tutor Minuzzo e Bastianini
+* ISMAR Venezia Comune livello acqua alta, resp Papa, tutor Bastianini Minuzzo (chiedere a Mauro che solleciti)
+* ISMAR Bologna, dati batimetrie Matricardo-Campiani, resp Matricardo; tutor Sarretta-Menegon
+* ISMAR Venezia Adriplan, dati stakeholder, resp Barbanti; tutor Sarretta-Menegon (chiedere a Sarretta di sollecitare Barbanti)
+* IREA Napoli, dati subsidenze, resp Fornaro; tutor Tagliolato & Oggioni; i dati sono stati inviati e sono all'esame di Oggioni & Tagliolato
+* IREA Milano, dati costa Oristano; resp Giardino; tutor Criscuolo/Pepe
+* ISSIA Bari, resp Patrizia Adamo; tutor Tagliolato (sollecita Pepe)
+* Scardi (alias Marine Strategy): da valutare se sollecitare perché a seguire potrebbero aggregarsi tutte le università, con problemi di sostenibilità
+Registrati:
+* ISMAR Lesina, resp Raffaele D'Adamo; tutor Vianello
+* ISMAR La Spezia, resp Mantovani, rete dei radar costieri
+* ISMAR Lerici, YO Yo, dati Canale di Corsica, resp. Catia Chiappini, tutor Oggioni
+* ISMAR Bologna(dati anche crociera Bortoluzzi, resp Ravaioli, tutor Sarretta, Oggioni
 ==  Varie ed eventuali ==
-Si propone
+Aggiornamento su Griffa, Corgnati
+Da definire prossima riunione, se si riesce a Venezia.
 [[Category:Meeting pubblici]]

Difference between revisions of "Meeting DevelopmentTeam SK - 06- 05-2014"

Latest revision as of 16:34, 6 May 2014

Contents

Presenti (via skype)

Ordine del Giorno

Partecipazione incontri Venezia