Difference between revisions of "Estensione EDI-RDF"

Revision as of 12:45, 8 August 2014

Scopo: estendere EDI in modo da consentire la creazione e aggiornamento form-based di dati RDF.

Utilizzo: gestire utenti/istituti in RITMARE, toponimi, descrizioni di produttori e utilizzatori di sensori in prospettiva ODIP2, gestione dell'accesso alle risorse fornite dagli SK basata su rete sociale.

Caso d'uso: come primo caso d'uso si può prendere FOAF e fare in modo che EDI consenta la creazione e l'aggiornamento dell'anagrafica di RITMARE per quanto riguarda ricercatori e istituti. Lo scopo è quello di creare una interfaccia da presentare all'utente sul portale centralizzato.

Due scenari alternativi:

Creazione e modifica dei dati attraverso RDF/XML:
- PRO si richiede la sola produzione di XML da parte di EDI
- CON spreco di risorse in quanto prevede cancellazioni inutili
- caso d'uso:
  - L'utente seleziona (gli viene presentato o crea da zero) il record FOAF corrispondente ad una entità (ricercatore o istituto)
  - Il template specifico genera il form corrispondente, eventualmente popolato con le proprietà già presenti
  - L'utente inserisce o modifica le proprietà
  - Al momento del POST, tutti i dati associati all'uri dell'entità vengono eliminati
  - L'RDF/XML corrispondente alle proprietà inserite nel form viene generato e inserito nel triple store
Creazione e modifica dei dati attraverso SPARQL
- PRO l'aggiornamento potrebbe divenire transazionale
- CON EDI dovrebbe generare una query SPARQL sa sottoporre all'endpoint
- caso d'uso:
  - L'utente seleziona (gli viene presentato o crea da zero) il record FOAF corrispondente ad una entità (ricercatore o istituto)
  - Il template specifico genera il form corrispondente, eventualmente popolato con le proprietà già presenti
  - L'utente inserisce o modifica le proprietà
  - Al momento del POST, viene generata la query SPARQL che aggiorna le proprietà inserite attraverso il form

Considerazioni: In ambo gli screnari, ci sono un po' di cose che cambiano rispetto all'utilizzo attuale di EDI:

(ai fini del testing) conviene puntare EDI al Virtuoso di staging (1.0.0.20) in modo da lasciare inalterato il comportamento degli SK.
non ha ragione di esistere un EdiML per ognuno dei record FOAF da gestire perché le strutture dati di riferimento sono quelle del triple store.
di conseguenza, il popolamento del form HTML per l'editing di una entità esistente deve eseguire una o più query SPARQL per recuperare i valori esistenti
l'aggiornamento deve tenere conto di modificha e cancellazione di proprietà esistenti nonché l'inserimento di nuove, eseguirlo in una sola QUERY puo' essere tricky

@@ Line 28: / Line 28: @@
 * (ai fini del testing) conviene puntare EDI al Virtuoso di staging (1.0.0.20) in modo da lasciare inalterato il comportamento degli SK.
 * non ha ragione di esistere un EdiML per ognuno dei record FOAF da gestire perché le strutture dati di riferimento sono quelle del triple store.
-* di conseguenza, il popolamento del form HTML per l'editing di una entità esistente deve eseguire una o più query sparql per recuperare
+* di conseguenza, il popolamento del form HTML per l'editing di una entità esistente deve eseguire una o più query SPARQL per recuperare i valori esistenti
+* l'aggiornamento deve tenere conto di modificha e cancellazione di proprietà esistenti nonché l'inserimento di nuove, eseguirlo in una sola QUERY puo' essere tricky