Jump to: navigation, search

Meeting DevelopmentTeam SK 30 01 20154

Presenti (via Skype)

  • IREA: Oggioni, Pavesi, Pepe, Tagliolato
  • ISMAR: Menegon

Ordine del Giorno

  • integrazione EDI-NG in SK
  • decisioni su EDI server (e integrazione in SK)
  • serie temporali e batch import in SK

Link Utili

https://github.com/SP7-Ritmare/EDI-NG_client

https://github.com/SP7-Ritmare/EDI-NG_server

https://jena.apache.org/

https://joinup.ec.europa.eu/catalogue/repository/eu-semantic-interoperability-catalogue

https://github.com/GeoNode/geonode/blob/master/geonode/layers/utils.py

Minute

SK 2.0

Dopo breve discussione ci si rende presto conto che oltre a EDI-NG client ci sono diversi altri nuovi elementi da integrare in SK che riguardano non solo la gestione dei metadati ma anche dei sensori e dei dati, e che portano alla configurazione di una vera e propria nuova release di SK 2.0, la quale vedrà l'integrazione di:

  1. GeoNode nuova versione
  2. 52N versione nuova di SOS (4.1)
  3. Client SOS per inserimento osservazioni (Paolo e AleO)
  4. Client SOS per visualizzazione osservazioni (Stefano, Paolo e AleO)
  5. Visualizzazione sensori con D3
  6. EDI-NG_client
  7. EDI-NG_server

Per quanto riguarda il punto 1, la versione viene rilasciata in questi giorni e non si prevede che la comunità di sviluppatori manterrà piu' la vecchia versione. Inoltre ci sarà possibilità di upgrade delle distribuzione con nuovo Ubuntu.

Per il punto 2, non è strettamente necessario ma auspicabile; si deve però prima terminare una fase di testing per verificare che la nuova versione SOS 4.1 di 52N non riservi brutte sorprese; AleO e Paolo stanno verificando.

Per i punti 3, 4 e 5 se ne occuperà Stefano, con supporto di AleO e Paolo per quanto riguarda l'ultimo punto.

Per i punti 6 e 7 si apre un lungo e approfondito dibattito sull'opportunità di inserire anche il server EDI e non solo il client EDI-NG in SK e alle opportunità future dell'utilizzo di EDI-NG_server in una architettura federata. Fabio introduce l'idea di utilizzare per EDI-NG_server le possibilità implementative offerte dal framework Apache Jena, nonché dal triple store ad esso collegato - TBD - per archiviare gli EDIML, come suggeritogli da Paolo e Cristiano. (Sarebbe possibile anche recuperare tutti gli EDIML finora creati, perché oltre che sul server sono già salvati anche in locale). Questo tipo di storage in formato RDF aprirebbe orizzonti sia per la discovery semantica che per la creazione di template orientati al web semantico e linked data, magari anche svincolandoci dall'utilizzo di Virtuoso e potendo creare noi soluzioni di registry e catalogo. (Si rimpiange l'assenza di Cristiano e il suo contributo per questi aspetti). Starebbe poi alla configurazione locale di SK con integrato il server EDI se inviare gli EDIML ad un registry, ad un catalogo (tramite trasformazione in XML), ad entrambi o prefigurare diversi scenari di utilizzo dei metadati in funzione del profilo e della comunità di appartenenza, nonché delle relative data policy. Per il momento, ovvero per la release 2 di SK, Fabio si occuperà di verificare se l'attuale implementazione di EDI-NG_server, che gira sotto jboss, possa essere agevolmente servita anche con Apache-Tomcat, in modo da essere integrabile in SK senza dover attivare un secondo application server (n.d.r. "spero di non aver scritto stupidaggini"). NOTA: integrate ed emendate questa parte, grazie

Migrazione vecchi SK

Per l'upgrade degli SK già distribuiti, dopo una fase di testing sul nodo sperimentale di Venezia, percui non si prevedono grandi difficoltà, si dovrebbe portare sugli altri nodi RITMARE. Dopo breve discussione si arriva a definire uno scenario che prevede l'intervento del development team in modo manuale su ciascun nodo; perché una procedura automatizzata richiederebbe un ulteriore sforzo implementativo, di cui non si vede necessità, dato il limitato numero di nodi e l'elevato controllo degli stessi.

Feedback utenti

C'è una breve interruzione da parte di Stefano Guerzoni che ci chiede a quale data considereremo finita la fase di raccolta feedback dai nostri nodi sperimentali di SK e quando uscirà la nuova versione. Dovremo tener presente i feedback degli utenti, per quanto possibile, nella nuova implementazione.

Batch import

Fabio, Stefano e Monica rimangono a discutere di questo ultimo punto. Si tratta di importare risorse che appartengono a serie temporali e che quindi, dal punto di vista del relativo metadato, differiscono per un solo elemento, ovvero la data di creazione. Dato che GeoNode prevede la possibilità di caricamento di risorsa + metadato in batch (ref). Una soluzione piuttosto diretta è quindi utilizzare un meccanismo esterno di duplicazione degli XML (basta un comando di shell), sulla base di folder structure e naming convention prefissate, e uno sfruttamento di questa funzionalità di importazione di GeoNode. Più avanti si potranno valutare scenari più raffinati e generalizzabili, con la possibilità per l'utente SK di configurare i parametri di importazione e la duplicazione dei metadati anche in EDIML.