Difference between revisions of "Estensione EDI-RDF"
m (→Requisiti da prima stesura template FOAF) |
m (→Requisiti da prima stesura template FOAF) |
||
Line 79: | Line 79: | ||
* 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 è 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 | ** 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 | + | * 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 |
Latest revision as of 12:12, 15 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 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