View source for 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 [http://sp7.irea.cnr.it/jboss/MDService/rest/getEditor?template=FOAF&version=2.00 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 [http://sp7.irea.cnr.it/svn/SP7/Shared/portale/ screening] dei social network da includere
** Alcuni espongono API piuttosto che un output in JSON o altro formato. Altri richiederebbero meccanismi di [http://scrapy.org/ 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 [http://10.0.0.10:8890/sparql?default-graph-uri=&query=++++++++++++++PREFIX++vcard%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2006%2Fvcard%2Fns%23%3E%0D%0A++++++++++++++PREFIX++addr%3A++%3Chttp%3A%2F%2Fwymiwyg.org%2Fontologies%2Ffoaf%2Fpostaddress%23%3E%0D%0A++++++++++++++SELECT+%3Fl%0D%0A++++++++++++++FROM+%3Chttp%3A%2F%2Fritmare.it%2Frdfdata%2Fproject%3E%0D%0A++++++++++++++WHERE+{{%0D%0A++++++++++++++++%3Chttp%3A%2F%2Fsp7.irea.cnr.it%2Frdfdata%2Fproject%2FCristianoFugazzaIREA%3E+addr%3AthoroughfareName+%3Fl+.%0D%0A++++++++++++++}+UNION+{%0D%0A++++++++++++++++%3Chttp%3A%2F%2Fsp7.irea.cnr.it%2Frdfdata%2Fproject%2FCristianoFugazzaIREA%3E+addr%3Aaddress+%3Fb1+.%0D%0A++++++++++++++++%3Fb1+addr%3AdeliveryPoint+%3Fb2+.%0D%0A++++++++++++++++%3Fb2+addr%3Alocation+%3Fb3+.%0D%0A++++++++++++++++%3Fb3+addr%3AthoroughfareName+%3Fl+.%0D%0A++++++++++++++}+UNION+{%0D%0A++++++++++++++++%3Chttp%3A%2F%2Fsp7.irea.cnr.it%2Frdfdata%2Fproject%2FCristianoFugazzaIREA%3E+vcard%3Aorg+%3Fi+.%0D%0A++++++++++++++++%3Fi++addr%3Aaddress+%3Fi1+.%0D%0A++++++++++++++++%3Fi1+addr%3AdeliveryPoint+%3Fi2+.%0D%0A++++++++++++++++%3Fi2+addr%3Alocation+%3Fi3+.%0D%0A++++++++++++++++%3Fi3+addr%3AthoroughfareName+%3Fl+.%0D%0A++++++++++++++}}%0D%0A++++++++++++++LIMIT+1&should-sponge=&format=text%2Fhtml&timeout=0&debug=on query] produce il risultato atteso mentre all'interno del template non funziona