Difference between revisions of "Estensione EDI-RDF"

Revision as of 16:47, 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
      • 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 selezionare 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
• non è possibile aggiungere attributi alla root di un element (es. rdf:about al tag foaf:Person che ha come root /rdf:RDF/foaf:Person)

Requisiti da prima stesura template FOAF

• La possibilità di importare dati da social network professionali/research-oriented è emersa nell'ultimo meeting ODIP e consentirebbe anche di velocizzare la creazione di nuovi account da parte di potenziali utenti
  • In esecuzione uno screening dei social network da includere
  • Alcuni espongono API piuttosto che un output in JSON o altro formato. Altri richiederebbero meccanismi di scraping per estrarre i dati piuttosto che la creazione di un account per poter accedere al record di un utente
  • Una volta concluso, si tratterà di decidere quali considerare, come trattare le possibili sovrapposizioni di valori da account multipli, come gestire la creazione di nuovi account su queste reti sociali, ecc.
    • Dato che l'inserimento degli account corrispondenti ai vari social network è necessariamente sequenziale, la regola più immediata è popolare solo i campi che sono rimasti vuoti
    • Occorre decidere come mettere in relazione i dati nel profilo utente di un social network con i campi del record FOAF
    • Si offrirebbe la possibilità di importare anche la rete sociale (da esprimere come foaf:knows) che pero' dovrebbe limitarsi agli utenti Ritmare, forse un po' troppo laborioso da realizzarsi
  • L'ultimo passo e' l'inserimento di questi valori nel form (e gestione delle precedenze rispetto a valori pre-esistenti nel record FOAF associato ad un utente)
    • Si può applicare la stessa regola del punto precedente
• Sarebbe utile separare la modalità di visualizzazione di opzioni precostituite/suggerite nel form HTML (es. dropdown lists vs. campi con autocompletion) dalle query e dalle tipologie di dato che li alimentano
  • serve ad esempio per popolare una dropdown list (al momento limitata a codelist) con gli istituti in Ritmare (che sono invece entità FOAF)
  • rende più facile gestire l'inserimento di valori language neutral/URI al posto delle label nella dropdown list (al momento non possibile con quest'ultime)