Jump to: navigation, search

Meeting Geoportale Milano 18 ottobre 2016

Revision as of 11:34, 18 October 2016 by Ritmare (Talk | contribs)

Meeting Geoportale

Presenti

  • Gloria Bordogna
  • Laura Criscuolo (via Skype)
  • 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

Introduzione

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. Differenza da 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 e widget e poi a livello più basso le API del widget generico (posizionamento, interazioni nel workspace.) sessione (variabili di stato), utente 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 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).

4) definizione basic widget

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;
  • individuazione attività rimanenti e future

output atteso: definizione della roadmap (inclusa implementazione basic widget)

Backend

Inquadramento

  • inquadramento generale sulla discovery

Harvesting

  • popolamento di CKAN 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

Retrieved from "http://sp7.irea.cnr.it/wiki/index.php?title=Meeting_Geoportale_Milano_18_ottobre_2016&oldid=3330"