Difference between revisions of "Estensione EDI-RDF"
m |
m |
||
Line 37: | Line 37: | ||
'''Bachi rilevati''' | '''Bachi rilevati''' | ||
− | * La lingua di default viene ignorata se | + | * La lingua di default viene ignorata nel tempplate per FOAF, in cosa differisce dagli altri? |
+ | * nella dropdown per selszionare l'area di ricerca, il primo elemento risulta selezionato anche se non lo si seleziona |
Revision as of 16:36, 19 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
Bachi rilevati
- La lingua di default viene ignorata nel tempplate per FOAF, in cosa differisce dagli altri?
- nella dropdown per selszionare l'area di ricerca, il primo elemento risulta selezionato anche se non lo si seleziona