Difference between revisions of "Estensione EDI-RDF"
Line 34: | Line 34: | ||
'''Modifiche necessarie a EDI''' | '''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". | * consentire a campi di tipo "dependent" di specificare nella query parametri (es. $1$) che non siano necessariamente racchiusi in un item di tipo "autoCompletion". | ||
+ | * consentire a campi di tipo "code" di avere isLanguageNeutral |
Revision as of 18:09, 15 September 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.
- 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".
- consentire a campi di tipo "code" di avere isLanguageNeutral