Jump to: navigation, search

Difference between revisions of "Meeting DevelopmentTeam SK 30 01 20154"

(Minute)
(Minute)
Line 15: Line 15:
  
 
==Minute==
 
==Minute==
 
+
=== SK 2.0===
 
Si introduce subito il fatto che oltre a EDI-NG client ci sono diversi altri nuovi elementi da integrare riguardo alla gestione non solo 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, che possa integri:
 
Si introduce subito il fatto che oltre a EDI-NG client ci sono diversi altri nuovi elementi da integrare riguardo alla gestione non solo 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, che possa integri:
  
Line 33: Line 33:
 
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 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 server in federazione.  
+
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 server in una architettura federata.  
Fabio introduce l'idea di utilizzare per EDI Server le possibilità offerte dal framework Apache Jena, nonché dal triple store ad esso collegato - TBD - per archiviare gli EDIML.  
+
Fabio introduce l'idea di utilizzare per EDI Server le possibilità implementative offerte dal framework Apache Jena, nonché dal triple store ad esso collegato - TBD - per archiviare gli EDIML, come suggerito 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. (Si rimpiange l'assenza di Cristiano e il contributo a questi aspetti).
+
(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. (Si rimpiange l'assenza di Cristiano e il contributo a 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 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 cavolate").
 +
NOTA: integrate ed emendate questa parte, grazie
 +
===Migrazione vecchi SK===
 +
Per l'upgrade degli SK già distribuiti, dovremo farlo noi in modo manuale, 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.
  
  
Per l'upgrade degli SK già distribuiti, dovremo farlo noi in modo manuale, 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.
 
 
EDI server su Tomcat con SK?
 
Gli EDIML creati nei nodi SK sono salvati anche in locale.
 
  
 
Integrazione SOS client visualizzazione in geo node nuovo
 
Integrazione SOS client visualizzazione in geo node nuovo

Revision as of 18:00, 2 February 2015

Presenti

  • 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://jena.apache.org/

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

Minute

SK 2.0

Si introduce subito il fatto che oltre a EDI-NG client ci sono diversi altri nuovi elementi da integrare riguardo alla gestione non solo 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, che possa integri:

  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 server (se funziona anche su Tomcat)

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 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 server in una architettura federata. Fabio introduce l'idea di utilizzare per EDI Server le possibilità implementative offerte dal framework Apache Jena, nonché dal triple store ad esso collegato - TBD - per archiviare gli EDIML, come suggerito 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. (Si rimpiange l'assenza di Cristiano e il contributo a 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 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 cavolate"). NOTA: integrate ed emendate questa parte, grazie

Migrazione vecchi SK

Per l'upgrade degli SK già distribuiti, dovremo farlo noi in modo manuale, 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.


Integrazione SOS client visualizzazione in geo node nuovo Integrazione EDI Integrazione SOS client inserimento osservazione 52N ver 4.1 Migrazione vecchi starter kit Creazione automatica MD se server locale Evoluzione di EDI con Jena per avere EDIML in una struttura dati RDF in un RDF DB

Quando finiamo la fase di feedback