Jump to: navigation, search

Meeting Geoportale Milano 18 ottobre 2016

Revision as of 10:32, 18 October 2016 by Mpepe (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
  • 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) 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)

3) Diagramma entity relationship, poi per ciascuna classe, con poi qualche formalismo i vari metodi che possono essere associati alle 4 classi di cui sopra (widget, utente, sessione, categoria). Per questo potrebbe essere utile qualcosa di tipo swagger [[1]]

Finalizzazione interfaccia

  • verifica attività prototipo al seguente indirizzo [[2]]
  • 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