Difference between revisions of "Ingredienti per un prototipo"
(54 intermediate revisions by 4 users not shown) | |||
Line 16: | Line 16: | ||
# rappresentatività dei sottoprogetti e degli enti coinvolti | # 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) | # boe ed intercalibrazione (Cardin, OGS; Manzella, ENEA; Bastianini, CNR) | ||
# habitat costieri, carote di sedimento, biologia (Foglini, CNR) | # habitat costieri, carote di sedimento, biologia (Foglini, CNR) | ||
− | # metadati di crociera, batimetrie, transetti nave (Bortoluzzi, CNR) | + | # metadati di crociera, batimetrie, transetti nave (Campiani, Bortoluzzi, CNR) |
# aspetti collaborativi (Bresciani, CNR; Del Negro, OGS; Fontolan, CONISMA) | # aspetti collaborativi (Bresciani, CNR; Del Negro, OGS; Fontolan, CONISMA) | ||
# tsunami (Piatanesi, INGV) | # tsunami (Piatanesi, INGV) | ||
Line 28: | Line 30: | ||
Per queste persone, considerando i Macrorequisiti (WP1_AZ1) come ordinati dal Panel, si possono desumere due matrici: consumatori e produttori (come nelle figure seguenti). | Per queste persone, considerando i Macrorequisiti (WP1_AZ1) come ordinati dal Panel, si possono desumere due matrici: consumatori e produttori (come nelle figure seguenti). | ||
− | [[File:Consumatori.png|600px|frameless|center]] | + | [[File:Consumatori.png|600px|frameless|center|Tabella Consumatori]] |
− | [[File:Produttori.png|600px|frameless|center]] | + | [[File:Produttori.png|600px|frameless|center|Tabella Produttori]] |
== Ipotetico flusso di lavoro == | == Ipotetico flusso di lavoro == | ||
Line 45: | Line 47: | ||
== Ipotesi flussi di interscambio == | == 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. | 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 [[ | + | Nei diagrammi seguenti sono riportate le istantanee di questi piani di interscambio possibile fra gli attori individuati (come selezionati al punto [[Ingredienti_per_un_prototipo#Soggetti_e_loro_classificazione|precedente]]) in forma diagrammatica. |
+ | |||
+ | [[File:inter_R0.png|thumb|frameless|center|Piano macrorequisito R0|Condivisione dati di base]] | ||
+ | [[File:inter_R1.png|thumb|frameless|center|Piano macrorequisito R1|Informazioni sull'area geografica]] | ||
+ | [[File:inter_R2.png|thumb|frameless|center|Piano macrorequisito R2|Strumenti di collaborazione trasversale fra gruppi]] | ||
+ | [[File:inter_R3.png|thumb|frameless|center|Piano macrorequisito R3|Gestione dati Real-Time]] | ||
+ | [[File:inter_R6.png|thumb|frameless|center|Piano macrorequisito R6|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" |
Latest revision as of 17:01, 21 January 2014
Contents
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.
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.
- GSK:
- 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"