Meeting SP7 - 14/15-11-2013

Agenda

Giorno 14 Novembre 2013

• 10:30 - 12:30 Introduzione generale riguardante:
  • scopi delle giornate di lavoro (presentazione IREA),
  • ragioni per la realizzazione degli Starter kit (presentazione IREA),
  • principali caratteristiche e funzionalità degli Starter kit (demo a cura di IREA e di ISMAR).
• 14:00 - 17:00 Metadati, creazione e gestione, all'interno di SP7 e degli Starter kit
  • introduzione generale riguardante i Metadati e il loro utilizzo semantico (presentazione IREA)
    • discussione riguardante le funzionalità che dovranno essere implementate nel prototipo,
    • collegamento a linked data (LD).

Giorno 14 Novembre 2013

a cura di A.Basoni

Partecipanti:Stefano Menegon, A. Oggioni, P. Carrara, G. Bordogna, A.Basoni, C.Fugazza,F.Pavesi, Tomas Kliment, Mauro Bastianini, in teleconferenza: Tiziano Minuzzo,Andrea Vianello e Giovanni Bortoluzzi (dalle 14.30 con Carrara e Giuseppe) per discutere la questione servizi accentrati o distribuiti). Mattina Vengono introdotti i partecipanti e si ricapitolano i temi della giornata. In particolare gli starter kit che hanno l’obiettivo di stimolare l’erogazione dei dati dalle periferie (ottica bottom up) con poche difficoltà e garantendo ai nodi periferici di farlo con un server e a SP7 che i dati vengano erogati con standard definito. Lo starter kit (SK) geografico (CIGNO – Ente responsabile: ISMARcoordinatore: S. Menegon) verrà testato con i dati – mappe relative alla tematica mare di IREA mentre lo starter kit osservativo (ENVEUROPE – Ente responsabile CNR IREA, coord: A. Oggioni) verrà testato con dati messi adisposizione da ISMAR. Viene sottolineata l’importanza di testare il prototipo e le relative funzionalità e individuarne di aggiuntive. A. Oggioni illustra la sua presentazione per quanto riguarda le funzionalità del kit osservativo la discovery di metadati dei sensori non è stato ancora fatto; viene sottolineato come per l’upload di osservazioni emisure verrà utilizzato uno schema fisso, già prefedinito, mutuato da modellodati OGC, a cui ci si deve adattare, si vorrebbe fare un importatore (per filexls, ecc) per facilitare gli utenti nell’inserimento dei propri dati soprattutto per coloro che non sono in grado di lavorare con insert observation standard. G. Bordogna sottolinea come sia allora necessario creare una mappatura delle applicazioni se ciascun utente ha un tipo diverso di organizzazione dei dati. Per ora non è pensato per tutte le esigenze ma è positivo avere un’interfaccia buona per non obbligarli a fare insert observation.

Viene posta attenzione sulle domande aperte, operative e viene stimolata la discussionein particolare sui seguenti temi:

• Come fornire supporto help desk per l’istallazione degli starter kit?
• Come regolare gli aggiornamenti delle versioni dello SK? All’inizio lo diamo come macchina virtuale se ci accorgiamo di un baco del DB come facciamo a aggiornare anche lo SK?
• Come garantire sicurezza e accesso ai servizi e alle funzionalità? Ad Es. centromaree che ha chiesto proprio questo…
• Come gestire un eventuale servizio hosting per nodi non autosufficienti (fino ad orasempre persone con ottima preparazione e disponibilità sistemisti) o nel casole persone non vogliano interagire con i sistemisti?
• Architettura cataloghi metadati: mantenerli distribuiti (nelle sedi) o accentrati?

Viene sottolineato come sia necessario attivare canali (web, email) per ricevere segnalazioni automatiche e/o manuali, si propone bug tracking digitato o altro esi chiede di aprire un indirizzo dedicato per assistenza per evitare che vadano sulla sua posta personale (S.Menegon). Si discute la possibilità di fare log per tracciare chi carica i dati, relativa frequenza con la finalità di monitorare quanto il servizio viene usato e anche permappare nodi critici. Per fare in modo che i server esterni depositino i log nel nostro occorre preparare un disclaimer che ogni partecipante dovrà sottoscrivere in modo da assicurarci che le informazioni ci arrivino e per tutelarci. Si propone di utilizzare github, a cui si deve aggiungereil logo di Ritmare, per gestire (documentazione, ricezione mail su bug, ecc.)e distribuire gli SK (F. Pavesi sottolinea come consista solo di un link ma non è il deployment delle macchine virtuali perché sarebbe troppo oneroso). Per le richieste di aiuto occorrerà attivare un help desk, se github lo permette, altrimenti si va verso altre soluzioni. Siamo aperti ad altri suggerimenti. Viene sottolineato come si debba registrarsi su github per fare segnalazione ma non è immediato per l’utente “non esperto”. Si svolge una discussione sulla necessità pubblicare i codici sorgente che, se sono open source, vanno resi disponibili (Menegon). Sarebbe bene avere un repository dove il codice che si va a sviluppare sia in chiaro. Inoltre, visto che non è possibile brevettare, è importante evidenziare che questo software è un prodotto di Ritmare. Viene sottolineato che l’assistenza porta via molto tempo, mettere in piedi un nodo per chi non è sistemista è molto impegnativo. Inoltre chi non ha il sistemista si deve appoggiare ad un hosting. Se non si è in grado di dialogare con il sistemista, si va nel proprio CED o altri,almeno temporaneamente lo ospitia SP7, poi ci sarà il piano della maintanance e occorre preparare un piano della sostenibilità per il futuro. Viene stressato il fatto che è molto importante offrire questa soluzione perché altrimenti non avremo i dati, è meglio fare uno sforzo ora ma per vedere dei risultati in seguito. Inoltre i livelli di difficoltà dipendono anche dalla maturità del software, adesso è pacchettizzato, molto più stabile e ci si aspetta meno difficoltà, in più si cercherà di non aggiungere cose complesse e strumenti di base senza voli pindarici. Poi il prodotto meno si tocca più è affidabile. Adesso è difficile dare opinione senza avere esperienza. Parte di incertezza con la quale dobbiamo fare i conti. Meglio forse proporlo prima a persone con un certo skill poi vedere come va… Viene sottolineato che non ci si aspetta che SP7 operi come una società di servizi ma che per ora crei solo prototipo testato su soluzioni più mature. E bisognerà stare attenti a dare in pasto lo SK a persone che non ci daranno problemi.Faremo anche dei disclaimer per tutelarci anche per qualsiasi cosa possasuccedere ai loro server. Faremo il monitoraggio sui log e in modo da non essere responsabili se i nodi vengono spenti; la macchina introdurrà dei test per fare delle verifiche. Si suggerisce anche una lista dei requirements – se vuoi partecipare, ti devi dotare di questo sistema, ecc. Viene proposto di usare il metodo del memorandum of understanding, MoU (esempio delprogetto DORIS_Net) con accettazione di alcune condizioni da soddisfare suirequirements. Viene poi introdotto il discorso relativo alla possibilità di “pingare” eventuali SK già attivi, interessante per futuro prototipo. Quando gli SK verranno accesi il prototipo dovrà cercare di vedere se i nodi sono attivi. F.Pavesi propone di usare SNMP in modo da ottenere altre informazioni, ad es. visualizzazione dati in forma grafica. Forse un po’ invasivo come protocollo. Anche a Tiziano non vengono in mente sistemi meno invasivi. Dal punto di vista tecnico sono tutti equivalenti. S. Menegon afferma che in Cigno viene usato google analytics, non ci traccia i servizi geoserver, va bene perclient, meno per server. Per noi è importante tracciare anche questi ultimi. Vengono elencate le soluzioni da adottare per lo SK esistono 3 livelli:

• google analytics buono per lato client,
• analisi log http per info su come sta erogando il servizio supposto raggiungibile,
• monitoraggio della raggiungibilità del server.

Vengono decise le seguenti suddivisioni dei compiti: S. Menegon si occupa di google analytics per vedere se lo strumento è adeguato. F. Pavesi del secondo livello; le informazioni ottenibili riguardano l’IP client, che query è passata, ecc. Si offre di stabilire unformato comune per i log apache e una modalità di trasmissione per tutti. Chevale anche per le query dei singoli utenti quando fanno le discovery, utileanche per il prototipo successivo.Tiziano si occupa del monitoraggio della raggiungibilità del server e dello SK (ping). A.Oggioni introduce la questione dell’aggiornamento. Ovvero: l’aggiornamento comefarlo? Ci sono due orientamenti chi vuole aggiornare spesso chi mai. SI riesce con il DB esistente? Se inizi a popolare il DB poi bisogna fare aggiornamenti, con quali impatti? con Monica Pepe si è tenuto conto di due possibili livelli.

Il primo come effettuare tecnicamente gli aggiornamenti? Secondo aspetto, una volta stabilito che occorre aggiornarli quali sono le caratteristiche degli aggiornamenti e le esigenze delle persone? Si cercherà di rispondere a queste domande. E’interessante abilitare l’aggiornamento degli SK che ci permette di fare un delay delle azioni di monitoring (prevedendo delle azioni di monitoringnecessarie fin dall’inizio dal prototipo e altre che possono essere aggiunte inseguito), dato che gli SK vengono aggiornati e se pensiamo di voler monitorare delle funzionalità differenti lo possiamo fare in qualsiasi momento perché l’aggiornamento ce lo consente. Vengono suggerite da F. Pavesi dei differenti livelli di priorità di aggiornamento: un livello di base-macchina al livello del sistema operativo che meno si aggiorna meglio è (perfetto accordo con Tiziano) a meno di problemi gravi come bug, ecc. Mentre per gli applicativi abbiamo due situazioni: quelli che mutuiamo (ad es. geoserver,52 North) e quelli dei software che produciamo noi. Frequenze consigliate da F. Pavesi:

• per il livello base macchina la più BASSA possibile;
• per l’applicativo mutuato: una frequenza MEDIA;
• per il software che sviluppiamo noi e delle terze parti, soprattutto nella fase iniziale di sviluppo, una frequenza più ALTA.

F.Pavesi ipotizza un tool da parte dello SK, una sorta di anticamera, dove gli SK sanno dove poter andare a verificare seci sono degli aggiornamenti: lo SK chiede periodicamente (settimana?) se ci sono e quali sono gli aggiornamenti. Noi dobbiamo avere pronto un piano diaggiornamento sullo SK. Il sistema operativo va predeterminato con una frequenza per testare la sicurezza e versioni (LTS). Per gli altri livelli dobbiamo avere la possibilità di verifica prima di fare l’aggiornamento, non è banale bisogna avere la possibilità di fare un’istantanea, uno snapshot della macchina prima dell’aggiornamento, procedimento per affinamento in modo che se il processo fallisce sia possibile tornare indietro. Si sviluppa una discussione sull’opzionalità di alcuni aggiornamenti che non è ritenuta fattibile dato che le periferie non rientrano nella decisione del merito degli aggiornamenti ma sono obbligati a l’obiettivo è rendere disponibili i dati a tutte le comunità e garantire l’interoperabilità ma con la condizione che venga fornito supporto alle periferie. In conclusione si tratta il tema della sicurezza e dell'accesso. Si dovrebbe tutelare il fatto che i dati sono a disposizione della rete ma non dell’esterno. Per quanto riguarda gli aspetti di sicurezza le funzionalità di amministratore dello SK le rileva chi prende in carico lo SK e fa l’istallazione tramite la sottoscrizionedel MoU dovremmo garantirci che loro utilizzeranno il software e che lo farannofunzionare se gli viene dato supporto e si devono occupare della sicurezza. Per la parte accesso differenziato ai dati occorre aggiungere un proxy nostro sullo SK che valuti le richieste. Viene citato ad esempio il caso dei dati osservativi di ENVEUROPE: tutti i dati vengono condivisi dalle comunità partecipanti. I metadati sono accessibili a tutti per la ricerca, solo chi ha un’utenza ad hoc può accedere ai dati.

Pomeriggio Introduzione riguardante i Metadati e il loro utilizzo semantico per infrastruttura Ritmarein senso lato (prototipo un'altra storia) di Cristiano Fugazza, presentazione Viene illustrata la prima struttura RDF con strutturazione gerarchica secondoinclusione sistemistica che ha come nodi finali le persone (SP, WP, AZ, UO,persone). Seconda nuvola di LOD (linked open data) che si vuole costruire è laterminologia che si userà per metadazione, discovery, ecc. categorizzazionemolto ampia delle research areas di 12 elementi che dovranno essere messi inrelazione in una tabella 12 * n con n il numero di widget (collegata a unlivello di pertinenza con l’area), data una area di ricerca e un widget esisteun determinato valore di utilità di quella widget per quella area di ricerca;una volta che l’utente si è autenticato, si avrà una lista di widget ordinatiper pertinenza e inseriti nell’interfaccia a seconda del peso di ognuno. Sidiscute la variabilità del profilo in funzione della ricerca che viene effettuatanel tempo. Si ipotizza l’esistenza di un profilo di breve e lungo termine ma nonvi è accordo completo, si discute se lasciarlo al livello della discovery. Inoltre vi è un thesaurus molto più ampio (es. parametri di marine metadata e my ocean,time per parametri dimensionali) con una caratterizzazione a due livelli: 100parametri al primo livello, 28.000 al secondo livello. Paramentri specifici checi permettono di dire che ad es. un certo sensore raccoglie quella tipologia didato che poi è messo in relazione con l’unità di misura e anche con grandezzadimensionale corrispondente (questo ultimo da fare). Questa è la struttura dimetadazione che serve per suggerire e specificare da parte dell’utente quale èil parametro di un determinato data set o un parametro di input di un datoservizio o la grandezza misurata da un sensore. Si è utilizzato Geonames perevitare all’utente, quando possibile, di dover andare a tracciare una boundingbox dove cercare risorse, l’idea è di utilizzare un gazzetteer. Che forma vogliamo dare ai metadati che andiamo a estrarre dai cataloghi? Propostadi usare DCAT, formato RDF, utilizzato per open data portal USA, UK, EU.Elementi metadata portal EU sono stati messi in relazione con i MD di INSPIRE.Viene sottolineato come vi siano MD che descrivono “cose diverse” meglio forsecatalogare i MD in funzione della “categoria differente” che descrivono epossono avere formato diverso anche a livello di prototipo. Ad esempio MD chedescrive il profilo dell’utente e può servire per soddisfare il requisito diconoscere le ricerche dei partecipanti tramite una discovery dei MD chedescrivono i partecipanti. Sarebbe importante identificare delle categorie diMD che descrivono oggetti omogenei, entità e definire funzionalità, natura delwidget per ogni utente. Altra possibilità: trovare un sistema di indicizzazioneefficace che metta insieme ricerca testuale e semantica e dare una visione deirisultati coerente sul ranking rispetto al profilo dell’utente piuttosto chelavorare sul widget. Discussione in merito. G. Bordogna riporta il discorso suche cosa si intende per metadato in Ritmare? Estensione del termine non solo aidati e servizi ma anche agli utenti, le persone della comunità che accedono alsistema e le funzionalità che descrivono il sistema, quindi si potrebbemostrare in interfaccia quello che interessa ovvero il risultato del matchingtra MD profilo con quello funzionalità. Diverse visioni su questa esigenza. Vero che la soluzione proposta da Gloria è ottimale per l’indicizzazione ma di difficilerealizzazione; ci si può accontentare di riuscire a mettere insieme risultatidi ricerca testuale tradizionale con risultati di ricerca semantica conrisultati coerenti. Condizionante sarà il formato dei MD che metteremo adisposizione poi tutto il resto sarà migliorabile perché dipenderà dallefunzioni di discovery che si realizzeranno in seguito. Si cercherà di non fare inserire all’utente nella widget dei propri dati personali il linkalla lista di persone con interessi simili in maniera dinamica perché èpossibile dare agli utenti una lista di utenti che hanno navigato i MD deglistessi dati che ha esplorato un altro. Si pone l’accento sulla necessità dimetterci nelle condizioni di trattare anche informazioni incomplete come adesempio MD con pochi contenuti.

Giorno 15 Novembre 2013

• 9:30 - 10:00 Divisione in gruppi di lavoro:
  • Starter kit geografico,
  • Starter kit osservazioni.

10:00 - 16:00 parallelamente:

• Gruppo di lavoro Starter kit geografico:
  • testing GeoNode con vector e raster preparati da IREA
• Gruppo di lavoro Starter kit osservazioni:
  • testing con dati osservativi centro marea e testing/realizzazione editor SensorML

minute 15 novembre

• Discussione sullo sviluppo di un tool di editing di metadati (per dati raster e vettoriali)condiviso dai due starter-kit geografico e osservativo : occorre fare un mapping tra campi di MD INSPIRE - RNDT - OpenData Portal (RDF) - GeoNode default. Il mapping INSPIRE/OpenData Portal è già stato fatto da Cristiano, il mapping tra INSPIRE e RNDT è offerdo dal documento RNDT_guida_operativa_dati_v1.2.pdf.
  • Le utenze dell'infrastruttura Ritmare si troveranno in una di queste 4 situazioni:
    • A) dati non pubblicati non metadatati
    • B) dati non pubblicati, metadatati
    • C) dati pubblicati non metadatati
    • D) dati pubblicati, metadatati
  • L'editor di metadati dello starter kit dovrà servire alle utenze A) e C), mentre le necessità delle altre utenze dovranno essere risolte con altre soluzioni, eventualmente esterne allo starter kit. Il tool di editing dovrà dunque prioritariamente aiutare a compilare metadati ex novo. Critiano e Paola si occupano di analizzare gli scenari per i casi B) e D)
  • I nodi periferici saranno abilitati a gestire i metadati lì compilati. Il nodo centrale avrà utilità per reperire e riutilizzare i metadati gestiti dai nodi periferici
  • Lo starter kit dovrà fornire dei cataloghi periferici, dai quali poi estrarre informazioni per l'infrastruttura centrale? L'alternativa è concentrare sin da subito i metadati nell'infrastruttura centrale.
  • Discussione su parallelismi e differenze della matadatazione in campo mapping geografico e in campo osservativo. Mentre per i dati geografici esiste un servizio di catalogo standard CSW, bisogna stabilire il sistema migliore per fare la discovery dei dati osservativi (e anche qui decidere se fare harvesting) e decidere se vale la pena di unificare i due sistemi. Poichè non ci saranno beneficiari di entrambi gli starter kit, non c'è una reale necessità di unificare i due sistemi di discovery, questo farebbe propendere a favore della separazione dei sistemi di discovery (cataloghi) e di metadatazione tra starter kit geografico e osservativo.
  • Separazione dei lavori in due gruppi: uno dedicato allo starter kit geografico (Menegon, Criscuolo, Pepe) e uno al mapping fra profili di metadati (Fugazza, Oggioni, Carrara).
• Test sullo starter kit geografico:
  • import di file vettoriali: il gruppo SHP (dbf + prj + shp + shx) relativo ad una linea di costa viene caricato correttamente da locale e appare la finestra di compilazione del metadato relativo
  • import di file raster: il geotiff di test ritorna error auto-configuring coverage -> dopo l'aggiornamento di geonode l'errore cambia in: could not aquire reader for coverage. Il problema si dimostra relativo alla cattiva definizione della proiezione all'interno del geotiff; purtroppo il geotiff è l'unico formato raster supportato (vedi sotto) ed è difficile comprendere a priori se contiene difetti (come quello relativo alla proiezione).
    • per risolvere il problema di mancato o erroneo sistema di riferimento-proiezione per i tif, si possono mettere a disposizione file prj per ciascun sistema (ma il prj può essere associato solo tramite comando il shell)
  • campi di metadati di default: alcuni campi mancano ed alcuni campi vanno chiariti (es Data, DataQuality, .../ le keywords vanno blindate in base al dizionario controllato/ la categorie vanno modificate in considerazione dei tematismi Ritmare, ad es manca la categoria Sea mentre esiste la categoria Oceans)ma queste discussioni sono rimandate a quando sarà definitiva l'analisi dell'allineamento dei profili
  • compilazione metadati: caricando un layer con il suo metadato in formato XML tramite drag-and-drop Geonode associa automaticamente i metadati contenuti nell'XML file al layer.
  • batch import di gruppi di dati e metadati:
    • si possono trascinare/selezionare più dati sulla finestra di caricamento, purtroppo la richiesta di metadatazione non è più diretta, ma deve avvenire tramite il relativo pulsante che si presenta sulla lista, non c'è un passaggio automatico all'ambiente di editing MD, come nel caso del caricamento di file singolo; per non ripetere da capo l'editing di MD simili. Si può mettere in grado l'utente di creare un template di metadato xml da associare poi a gruppi di layers. Sarebbe da implementare una icona di warning accanto a ciascun layer privo di metadati, per ricordare all'utente di inserirli.
    • possibile per un'intera directory anche senza selezione, solo da linea di comando, può anche favorire la compilazione dei metadati, applicando a tutto il dataset gli stessi metadati (per ora applica alcuni campi comuni a tutto il dataset). Esistono già degli script degli sviluppatori GeoNode che si possono utilizzare per estendere la funzione di compilazione "di gruppo" a tutti i campi di metadati.
  • vestizione: tramite file SLD, è possibile infatti caricare anche file.sld contenente lo stile da applicare al layer insieme allo stesso e poi agire sulle associazioni per più file.
  • sarebbe utile stilare una lista dei formati supportati, dei gruppi di file che devono essere caricati insieme (es il gruppo shp-shx-prj-dbf), fornire soluzioni per conversioni più comuni (es kml-shp, hdf-tiff), delle procedure per favorire tipi alternativi di upload (batch import, da DB con estensione geografica). Sarebbe utile aggiungere nella pagina di upload un breve testo con l'elenco di formati accettati e qualche indicazione di massima.
  • nella tendina per scaricare metadati si può cambiare la dicitura TC211 in ISO 19115

Conclusioni

Sono stati riportati i risultati e i commenti dei primi esperimenti di importazione di vettori e mappe, prima singolarmente e poi sotto forma di gruppi. Le considerazioni e i suggerimenti sono le seguenti:

1. l'interfaccia è molto diretta per il caricamento dei dati, anche in gruppi;
2. per evitare onerose ripetizioni di metadatazione durante l'inserimento di gruppi omogenei di dati, si dovrà abilitare la creazione di template (in gergo GeoNetwork).
3. nell'ingestione di gruppi di dati bisognerà notificare la necessità di metadatazione, più di quanto non sia presente nell'implementazione attuale (warning o alerting), per rendere la creazione del metadato obbligatoria.
4. bisogna trovare soluzioni di supporto ben congegnate perché i formati di ingestione sono molto limitati: SHP & TIFF (fra l'altro non quelli con tfw esterno), quindi:
   1. bisognerà renderlo noto e ben visibile, e comprensibile per i non addetti ai lavori
   2. bisognerà fornire o concepire (a livello starter kit o a livello nodo centrale) degli strumenti di conversione in tali formati (e qui Laura e Monica, con l'aiuto di Fabio dovranno indagare, se specificati nelle interviste, i formati più comuni)
   3. bisognerà rendere consapevoli gli utenti della necessità delle informazioni relative al sistema di riferimento geografico in cui sono inquadrate le loro mappe: es. presenza del file prj; problema più grosso è invece poter verificare la loro correttezza