Ingredienti per un prototipo

Abstract

Appunti per un piano un po’ più esecutivo, individuando casi d’uso e soggetti che garantiscano sia una certa fattibilità (disponibilità di dati e funzionalità) in tempi ragionevoli, che una buona rappresentatività (vedi viste elencate sotto).

Razionale

Secondo quanto emerso dalle interviste e dalle successive analisi e sintesi, emergono alcuni “ingredienti” da privilegiare per il prototipo, ovvero:

rete osservativa (metadatazione sensori – SensorML – e distribuzione osservazioni, anche in Real Time – SOS) (importante in particolare per SP5)
strumenti di collaborazione trasversale fra gruppi (importante in particolare per SP3 ma trasversale al progetto)
inquadramento dell’area geografica (trasversale a tutto il progetto)

Obiettivo: selezionare e descrivere casi d'uso e prospettare scenari d’interazione fra soggetti appartenenti a RITMARE basandoci su persone reali (in grado quindi di fornire o richiedere dati/funzionalità). Questi casi e persone devono essere rappresentativi sotto diversi profili, o viste. Tali viste sono state individuate come:

flussi di lavoro
tipo di comunità (Aree di ricerca)
tipo di dati (osservativo, raster, vector)
campagne di misura in situ
tipo di processi (Quality Check per sp5 (Cardin), analisi di dati biologici (Bastianini, Foglini) analisi di serie temporali (Fontolan), Analisi di mappe (Piatanesi))
rappresentatività dei sottoprogetti e degli enti coinvolti

Soggetti e loro classificazione

Si è proceduto ad una individuazione di soggetti candidati, ovvero persone di riferimento, e ad una loro classificazione, quali consumatori/produttori, in riferimento ai macrorequisiti

boe ed intercalibrazione (Cardin, OGS; Manzella, ENEA; Bastianini, CNR)
habitat costieri, carote di sedimento, biologia (Foglini, CNR)
metadati di crociera, batimetrie, transetti nave (Campiani, Bortoluzzi, CNR)
aspetti collaborativi (Bresciani, CNR; Del Negro, OGS; Fontolan, CONISMA)
tsunami (Piatanesi, INGV)
DSS difesa costiera (Scarcella, CNR)
ground true validation per remote sensing, serie storiche (Bastianini, CNR)

(manca SZN)

Per queste persone, considerando i Macrorequisiti (WP1_AZ1) come ordinati dal Panel, si possono desumere due matrici: consumatori e produttori (come nelle figure seguenti).

Ipotetico flusso di lavoro

macrorequisiti secondo il panel
selezione persone secondo il punto 1)
selezione persone secondo le viste
ipotesi di flussi di interscambio tra le persone coinvolte
individuazione dei flussi di interscambio fattibili
rappresentazione di casi d'uso
utilizzo delle analisi delle soluzioni interne al progetto per l'approvvigionamento di dati e funzionalità nei flussi di interscambio fattibili
progettazione del prototipo alla luce delle soluzioni interne esistenti e dei casi d'uso
implementazione del middleware, del controller e dei widget di interfaccia per rispondere ai casi d'uso delle persone coinvolte

Ipotesi flussi di interscambio

Secondo quanto riportato sopra e relativamente al punto 4), sono stati ipotizzati, seguendo l'ottica dei macrorequisiti, diversi piani di interscambio, numerati appunto secondo i macrorequisiti. Nei diagrammi seguenti sono riportate le istantanee di questi piani di interscambio possibile fra gli attori individuati (come selezionati al punto precedente) in forma diagrammatica.

Condivisione dati di base

Informazioni sull'area geografica

Strumenti di collaborazione trasversale fra gruppi

Gestione dati Real-Time

Opzioni di visualizzazione avanzate

Casi d'uso di interscambio

intercalibrazione di boe o elementi della rete osservativa (su base della descrizione nominale)
utente che misura transetti e che utilizza lo use case precedente per validare od indirizzare la propria misura
utente (e.g. Bresciani) misura in situ parametri che servono a caliibrare/validare stime degli stessi da immagini telerilevate
utente (e.g. Bresciani) usa parametri di base misurati dalla rete osservativa per decidere dove/quando misurare
utente (e.g. Bortoluzzi) usa prodotti da telerilevamento a bassa risoluzione per la scelta delle rotte da seguire in crociera (e quindi dei transetti da operare)
utenti che usano come input a modelli: dati di base da rete osservativa intercalibrati (UC1), dati di verità a terra (UC3) e mappe da telerilevamento (UC7)
produzione di mappe de telerilevamento utilizzando dati di base da rete osservativa intercalibrati (UC1), dati di verità a terra (UC3)
visualizzazione/accesso ai dati di base per un confronto analitico, per cui occorre aggregare (e..g. diverse frequenze), trasformare (e.g. unità di misura) e più genericamente armonizzare
visualizzazione 2D+, 3D o nD dei dati di base (anche previa spazializzazione)
modelli per la produzione di mappe di sintesi e/o indicatori utilizzando come input datasets forniti da Data Services (es OGC-WFS, OCG-WMS).

Workflow e avanzamento Prototipo

Questo il dettaglio di come EDI di debba integrare nei workflow dei due SK, con indicato cosa resta da realizzare/rivedere (tentative). Legenda:

X : aspetto da realizzare/rivedere entro la presentazione del prototipo (il c.d. proto-prototipo).
(X) : aspetto da realizzare/rivedere entro la release del prototipo.
((X)) : aspetto da realizzare/rivedere entro la realizzazione dell'infrastruttura centrale.

Dettagli sul workflow:

(X) Mappatura autenticazione utente in locale su strutture FOAF in remoto per attualizzare i campi che possono essere autocompilati/suggeriti in base all'utente che si e' autenticato (es. i vari contact point): essendo dipendente dal singolo deployment degli SK, è possibile che si possa rimandarne l'implementazione alla release degli stessi, utilizzando in fase di presentazione un utente di default per illustrare il funzionamento.
l'utente decide di inserire un dato in GSK o un sensore in OSK; ad un certo punto del workflow, viene richiesto l'editing dei metadati. Due entry point separati:
- GSK:
  - al termine dell'upload, GSK estrae alcuni metadati (es. CRS, BB) o assegna altri di default (es. lingua, keyword)
  - l'utente accede alla scheda contenete i metadati
  - GSK accede in remoto a EDI per ottenere la parte dell'interfaccia (l'editor) da integrare con l'interfaccia residente, gli passa come parametri della richiesta i metadati ricavati dal dato e quelli assegnati di default
- OSK:
  - SeosorML si riferisce alla descrizione di un sensore a prescindere dalle relative osservazioni; verificare con Alessandro come strutturare questo passaggio.
EDI genera l'HTML da integrare nell'interfaccia residente, da realizzare:
- X inserimento campi multipli
- X tipi complessi (es. bb, date range)
- X integrazione con bootstrap
l'utente lo compila
X al momento del post, avviene validazione di tipo e di mutua dipendenza tra campi (in locale, nel browser)
avviene il post
il server edi compone l'xml secondo il template (es. rndt), da realizzare:
- X tutti i campi con isFixed="true"
- (X) stabilire lo schema di URN per i campi hasValue="auto"
- X gestione campi multipli
X il server valida l'XML secondo lo schema corrispondente (RNDT, SensorML)
l'XML torna indietro al browser (non allo starter kit di riferimento), da realizzare:
- X GSK: vedere con Stefano il passaggio dell'xml a geonode come step worflow inserimento risorsa
- X OSK: vedere con Alessandro il meccanismo di describesensor o quant'altro

RNDT

Osservazione preliminare: pensavo di mostrare nel proto-proto solo i campi obbligatori (tranne la "Keyword a testo libero" ed "Estensione temporale", o conviene togliere anch'essi?) per sottolineare il numero ridotto di elementi richietsi e le funzionalita' di autocompilazione.

per il prototipo potremmo dire che aggiungeremo:

campi facoltativi
campi multipli (cosi' nn passa come qualcosa che ci e' sfuggito...)

S - possibile ridurre carattere testi di help e cambiare colore
S - possibile avere (il 27/28) il GSK come macchina virtuale in locale (presso IREA)?
F+S - tutti le label di elemento e item risultano linkati ("manina" nel browser) ma non eseguono azioni

   - possibilita' help in mouseover

F - prima riga del doc e' un "Identificatore file:" senza campi (e' "auto")
F - contenuto attributi ed elementi in versione language-neutral (lang="zxx")

   sussume F - Categoria tematica: valore language neutral della label

F - Data dei metadati: datepicker non picka vC - Formato di presentazione: mettere "tabella digitale" come valore di default vF+C - Tema di INSPIRE: conviene cambiare SPARQL per mettere la codelist ordinata secondo l'italiano? vC - Tema di INSPIRE: possiamo inserire un valore di default che si adatti alla maggioranza dei content provider? F - Parametro osservativo: metre si scorrono i suggerimenti, nel campo compare l'uri (sempre uguale data la lunghezza del campo) anzicheì' la label

   - forse non possibile

F - togliere secondo text field e passare parametro URI F+C - Scala equivalente e Distanza sono in stretta alternanza, capire come renderli graficamente (magari indicando "Risoluzione spaziale") e nel codice

   - aggiungere semplice "oppure"

vC - Limitazione d'uso: mettere "Nessuna condizione applicabile" come valore di default vC - Altri vincoli: mettere "L’accesso ai dati è pubblico" come valore di default

   !!! lo era gia', forse nn visualizzato perche' c'era un <hasValue> vuoto 
   (F) - validazione incrociata tra Vincoli di accesso, Vincoli di fruibilita' e Altri vincoli

F - verificare che default value sia visualizzato anche nelle textbox F+S - Localizzazione geografica: passaggio metadati ricavati da GeoNode come parametri richiesta

   NOME PAR    | SIGNIFICATO 
   (- uid       | id del dataset)
   (- tit       | titolo del dataset)
   (- type      | ???)
   (- i vari URL per il download multiformato)
   (- data)
   - BBOX
       - chiedere a S il formato
       (F) - validazione incrociata valori bb
   (- SRS)

vC - Spostare in Estensione il sist rif coord vC - Commentare estensione temporale in Estensione dei dati per l'incontro 27-28 F - Estensione temporale: al momento non genera alcun elemento (data type = dateRange), conviene usare "Data inizio" e "Data fine"? F+C+S - Inserimento nel template e passaggio nella query string per URL del dato vC - guardare distributor vC - Verificare accoppiamento endpoints-formato e versione

   a livello ISO, e' possibile specificare formato e versione dello stesso per ognuno degli elementi "Risorsa online"