Difference between revisions of "Estensione EDI-RDF"

Revision as of 10:26, 14 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

Requisiti da prima stesura template FOAF

• L'opportunità 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 fornendo valori di default per le proprietà FOAF presi dai profili associati all'utente
  • 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, se e 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 è valorizzare 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, dipendentemente dalla rappresentazione del primo
    • 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 alla selezione di una label dalla dropdown list (al momento non possibile con quest'ultime)
  • i widget corrispondenti ai vari tipi di dato (code, autoCompletion, string, ...) devono originare dallo stesso insieme di valori estratti dalla query SPARQL corrispondente
• Anche i valori di default nel tag defaultValue devono poter essere generiche query SPARQL
  • Il valore di default deve poter produrre la selezione di un elemento di una dropdown list (al momento credo che defaultValue si applichi solo al tipo "string" o al massimo "text")
• eliminare il tipo "dependent"
  • dev'essere possibile specificare parametri (es. $1$) in una query SPARQL qualsiasi, sia essa contenuta in hasValue o defaultValue, in un elemento di tipo code, autoCompletion, string, ecc.
  • il parametro non deve necessariamente appartenere ad un item dello stesso elemento

Bachi rilevati

• La lingua di default viene ignorata nel template per FOAF
  • soluzione: 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 duplicata
• non è possibile aggiungere attributi alla root di un element (es. rdf:about al tag foaf:Person che ha come root /rdf:RDF/foaf:Person)
  • non si può aggirare il problema accorciando la root se uno dei campi contenuti è multiplo