Estensione EDI-RDF

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 prendendoli 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 da una query SPARQL
- Questa query potrebbe essere locale al singolo item (come per l'attuale autoCompletion) o globale (come per l'attuale code), pero' dev'essere personalizzabile
- Ad esempio, al momento le variabili "utili" che dovrebbero accomunare i vari tipi di dato sembrano essere:
  - ?c: l'URI di una risorsa
  - ?l: la rappresentazione human-friendly da inserire nella dropdown list, nelle opzioni di autocompletion ecc. (N.B. questa potrebbe dipendere dalla lingua di default del dato che però non è attualmente utilizzabile come parametro)
  - ?a: la rappresentazione alternativa, nel caso non vi sia una rappresentazione nella lingua di default
  - ?v: il valore che andrà inserito nell'output finale, che può essere differente da quello visualizzato nella dropdown list o tra le opzioni di autocompletamento (questo permette di astrarsi dai vari useCode useURI ecc.)
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
- i parametri potrebbero essere riferiti non all'item ma alla query
  - questo rende possibile, anziché eseguire n query per riempire n campi, eseguire una sola query per recuperare tutti i valori necessari
  - questo però può rendere problematico stabilire nomi di variabili fisse (?c, ?l ...) per esprimere quali valori mettere nelle dropdown lists, nell'output finale ecc.
si potrebbe includere nella validazione tipi di dato quali "mailto:" e "tel:" che hanno una sintassi definita

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
questa query produce il risultato atteso mentre all'interno del template non funziona