Difference between revisions of "Estensione EDI-RDF"
m |
m |
||
Line 16: | Line 16: | ||
*** L'RDF/XML corrispondente alle proprietà inserite nel form viene generato e inserito nel triple store | *** L'RDF/XML corrispondente alle proprietà inserite nel form viene generato e inserito nel triple store | ||
* Creazione e modifica dei dati attraverso SPARQL | * Creazione e modifica dei dati attraverso SPARQL | ||
− | ** PRO l'aggiornamento | + | ** 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 |
Revision as of 12:02, 7 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