Meeting Geoportale Milano 18 ottobre 2016

Meeting Geoportale

Presenti

• Gloria Bordogna
• Paola Carrara
• Laura Criscuolo (via Skype)
• Luca Frigerio
• Cristiano Fugazza
• Stefano Menegon
• Diego Migliavacca
• Monica Pepe

Agenda

1. Introduzione
2. Frontend (10 -13)
   1. Attività progettazione (data model), definizione di API e basic widget
   2. Finalizzazione interfaccia
3. Backend (14 - 17)
   1. Inquadramento
   2. Harvesting

Frontend

Progettazione

Definizione delle caratteristiche/attributi dei widget e delle strutture dati atte a riceverle, per la rappresentazione dell'interfaccia e degli utenti, e API

1. strutture dati
2. modalità di archiviazione e di interrogazione delle suddette strutture dati
3. modalità per la definizione delle API
4. definizione widget selezionati per prototipo (interazione con IUAV)

output atteso: accordo sugli strumenti di modellazione, modalità di interazione del gruppo e definizione della roadmap

1) strutture dati

Discussione sul fatto che le strutture dati debbano essere relative solo al frontend o anche al backend. Differenziazione fra widget:

• interni
• esterni

Proposta: Core per entrambi e quello dei widget interni può essere specifico alle funzionalità di backend Maggiore difficoltà nel logging delle operazioni utente nei widget esterni Proposta di log con invocazioni relative al widget Separazione fra strutture dati du backend e frontend e mappatura successiva fra le due, parte di allineamento interna o estensione del backend (harvesting di CKAN è già in questa direzione). Livello alto di relazioni fra entità: utente, sessione widget e categoria. Poi, verranno rappresentate, a livello più basso, i metodi (quindi le API) del widget generico (posizionamento, interazioni nel workspace) sessione (variabili di stato), utente (profilo) e categoria (quello che chiamavamo profilo). (figura Cristiano)

2) modalità di archiviazione e di interrogazione delle suddette strutture dati

Per l'implementazione finora attuata in RITMARE Sp7: RDF e SparQL

3) modalità per la definizione delle API

Diagramma entity relationship (in Astah) per la rappresentazione di ciascuna classe per le 4 classi di cui sopra (widget, utente, sessione, categoria), con poi qualche formalismo per i vari metodi che possono essere associati alle classi. Per questo potrebbe essere utile qualcosa di tipo swagger [[1]]. Per intanto Gloria e Laura fanno la parte più ad alto livello sulle classi e sul core e poi si decide se swagger o altro strumento per la parte dei metodi. (Specificare il concetto di stato in una sessione da cui dipende il livello di complessità, log della sessione diverso dal log del widget. Il log è una proprietà del widget che viene ereditata dalla sessione). Classi standard con interoperabilità come pacchetti base e poi loro estensioni.

4) definizione basic widget

Si discute e si arriva alla definizione della selezione di widget da implementarsi nel prototipo

• Widget discovery
• Widget mappa
• Widget my-data
• Widget news/push/summary
• Widget metadati
• Widget plot/chart

scadenze: 2 settimane per definizione classi standard con diagrammi entity relationship

Finalizzazione interfaccia

• verifica attività prototipo al seguente indirizzo [[2]]
  • lo spostamento dei widget tramite trascinamento ne comporta ancora in alcuni casi il collocamento al di fuori degli spazi della griglia;
  • la griglia di sfondo ancora non corrisponde agli effettivi spazi widget;
  • discussione sulle barre di menù contestuale e propria del singolo widget;
  • le icone widget nella barra verticale ancora non seguono l'ordine di presentazione delle istanze di widget negli spazi del portale;
  • discussione sull'esistenza e sulla funzione dei workspace: l'esistenza di più workspace può essere bypassata dalle funzioni di salvataggio delle sessioni di lavoro (Gloria). L'esistenza dei widget consente tuttavia la gestione simultanea di un maggior numero di istanze widget (Cristiano, Monica). La barra verticale può essere eliminata per questioni di semplicità di impatto-utente, ma anche di semplicità della struttura dati (Gloria e Stefano).
  • discussione sull'attivazione dei widget "dormienti": c'è l'esigenza di averli tutti attivi per via delle numerose interazioni tra widget (Stefano). Col primo click si potrebbero rendere attivi, col doppio click potrebbero "conquistare" lo spazio principale (Gloria e Stefano), oppure per "svegliare" il wiget si potrebbe cliccare su apposito tasto al centro della velatura (Laura). Per far ricomparire la velatura sul widget, rendendolo di nuovo dormiente, è sufficiente cliccare su una nuova finestra (Stefano).
  • discussione su semplificazione delle attività utente sul portale: i modi per interagire con i widget devono essere pochi e sempre uguali (Gloria)
• individuazione attività rimanenti e future

scadenze: fine del 2016

Backend

Inquadramento

• inquadramento generale sulla discovery

requisiti per il backend della discovery

1. ricerca per specifici target elements
2. flessibilità su faceted search
3. deve supportare i parametri di ricerca geospaziali

Proposta di Gloria: mappatura fra requisiti di discovery e classic search e semantic search

Canditati: SolR (Lucene), Elastic Search

Ricerca distribuita su nodi specializzati per particolari schemi o indicizzazioni diverse, nel nostro caso possiamo usare un indicizzatore diverso per ogni schema di MD Haystack [[3]] gestisce diverse ricerche multi indice su differenti backend o su diversi nodi

Arricchimento Semantico e Harvesting nel backend

• popolamento del backend con opportuno formato di MD (da EDIML) verifica funzioni di discovery opportune
• traduzione da EDIML a RDF
• cenni su semantic lift

output atteso: definizione del quadro sinottico di attività di discovery/catalogo, definizione della roadmap