Estensione EDI-RDF

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
    - Potrebbero esserci dati annidati in blank nodes che non vengono eliminati completamente eliminando le triple riferite all'URI dell'utente
  - 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 da 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.
se necessario, si puo' cmq ipotizzare la creazione di record EdiML da tenere sincronizzati con le strutture RDF nel 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 SPARQL puo' essere tricky

Modifiche necessarie a EDI

consentire a campi di tipo "dependent" di specificare nella query parametri (es. $1$) che:
- non siano necessariamente racchiusi in un item di tipo "autoCompletion"
- non appartengano necessariamente ad un item dello stesso element
consentire a campi di tipo "code" di avere isLanguageNeutral

Bachi rilevati

La lingua di default viene ignorata nel tempplate per FOAF
- deve essere specificata nella richiesta, come fa GeoNode
nella dropdown per selszionare l'area di ricerca, il primo elemento risulta selezionato anche se non lo si seleziona
- se il campo non è obbligatorio, il problema non emerge, però:
- se il campo è multiplo, istanze successive hanno comunque questo problema
la label dei gruppi viene duplicato