Difference between revisions of "Estensione EDI-RDF"
m |
m |
||
Line 33: | Line 33: | ||
'''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" | ||
+ | ** non appartengano necessariamente ad un item dello stesso element | ||
* consentire a campi di tipo "code" di avere isLanguageNeutral | * consentire a campi di tipo "code" di avere isLanguageNeutral | ||
'''Bachi rilevati''' | '''Bachi rilevati''' | ||
− | * La lingua di default viene ignorata nel tempplate per FOAF, | + | * 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 | * 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 non è obbligatorio, il problema non emerge, però: | ||
** se il campo è multiplo, istanze successive hanno comunque questo problema | ** se il campo è multiplo, istanze successive hanno comunque questo problema | ||
* la label dei gruppi viene duplicato | * la label dei gruppi viene duplicato |
Revision as of 12:31, 13 October 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"
- 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