Listato 2.4: Esempio di uso di “variabili di percorso” in Lorel.
s e l e c t d i s t i n c t path−o f (P)
from Map . a i r p o r t {A} . ( ( . % ) ∗ )@P. nextTo {B} where A = ”PSA” and B = ” LeaningTower ”
Variabili di percorso
Un’interessante feature messa a disposizione dal linguaggio (vedi Listato 2.4)3, riguarda le “variabili di percorso”; capita spesso in problemi spaziali, ma non solo, di chiedersi se esiste e nel caso restituire, un percorso tra due nodi.
La difficolt`a nel mettere a disposizione questo tipo di variabili, si ha durante la fase di collezione dei risultati a causa della chiusura di Kleene: nel caso si scelgano due nodi tra cui esiste un percorso che li collega contenente almeno un ciclo, l’insieme dei risultati risulterebbe infinito. La scelta fatta in Lorel `e stata quella di restituire solo percorsi in cui un oggetto, facente parte di una porzione di espressione regolare terminante con “+” o “*”, pu`o essere attraversato al massimo una sola volta. Nonostante la condizione di aciclicit`a sia restrittiva, `e stato mostrato che per la maggior parte dei casi d’uso, la politica adottata risulta sufficiente.
Costruzione dei risultati
Il risultato di un’interrogazione Lorel risulta essere un nuovo grafo OEM. In questo modo `e possibile utilizzare tale risultato per successive interrogazioni o integrazioni con altre basi di dati.
Durante la fase di creazione della risposta `e possibile che questa contenga riferimenti a nuovi oggetti (ad esempio l’elemento principale “answer”) creati sul momento, oppure ad oggetti esistenti.
Un analisi dettagliata sulla politica di creazione di nuovi oggetti e la scelta delle etichette nella creazione dei risultati si trova in [2].
2.2
SPARQL
Sparql (SPARQL Protocol and RDF Query Language) `e il linguaggio di interrogazione progettato dal W3C per il modello Resource Description Fra- mework descritto nella sezione 1.4.6.
3Nell’esempio citato: una variabile tra “{}” cattura il nodo a cui l’etichetta precedente
Il suo primo rilascio risale al mese di Gennaio 2008 [53], mentre una nuova versione `e in progetto e le sue caratteristiche possono essere trovate in [52].
Il motivo principale di questo nuovo progetto risiede nel fatto che, con la prima versione, molte feature presenti in ormai tutti i linguaggi di interroga- zione devono essere emulate attraverso script esterni sulla base dei risultati ottenuti. Semplici esempi sono: l’aggregazione, le negazioni, la possibilit`a di creare interrogazioni annidate, eccetera. Per ovvi motivi, la prima versione del linguaggio risulter`a compatibile con la nuova.
Nel seguito di questa tesi, quando verranno descritte caratteristiche esclu- sive della nuova versione sar`a esplicitato. Nel mostrare esempi di interroga- zioni, i listati saranno formati da tre sezioni:
Data in cui viene esplicitato, se necessario, il dataset a cui le interrogazioni si riferiscono e gli eventuali dati sono mostrati in sintassi Turtle (meno verbosa dell’equivalente RDF/XML);
Query in cui vengono mostrate le interrogazioni. Questa `e a sua volta com- posta da una prima parte in cui si definiscono i prefissi utilizzati nella scrittura della query vera e propria;
Result in cui vengono esplicitati i risultati dell’interrogazione.
2.2.1
Aspetti principali del linguaggio
Anche questo linguaggio propone una sintassi che ricorda quella di SQL con le clausole di selezione e proiezione. Dagli esempi mostrati si nota, in generale, la mancanza della clausola from: la sorgente dei dati viene infatti esplicitata al momento della connessione con l’entit`a che risolve la query [51]. E’ co- munque possibile definire con le clausole from e from name all’interno delle singole interrogazioni, particolari dataset diversi o aggiuntivi rispetto a quello preimpostato.
La sintassi della clausola where in Sparql, mette in evidenza il meccanismo utilizzato nella risoluzione delle interrogazioni: il graph pattern matching. La composizione del pattern per la selezione dei dati, avviene tramite compo- sizione di pattern di grafi pi`u semplici; quello pi`u semplice `e una tripla con delle costanti e delle variabili: applicata al dataset, restituisce tutti i possibili assegnamenti validi per tutte le sue variabili. Un insieme di pattern di triple, costituisce un graph pattern elementare. Ogni matching del pattern sui dati deve comportare un assegnamento di tutte le variabili presenti.
Nel listato 2.5 viene presentato un esempio di dataset RDF e interrogazio- ne RDF. Nella sezione dati si notano tre oggetti astratti :a, :b, :c espressi mediante il formalismo dei “blank nodes”: per i primi due oggetti vengono
2.2. SPARQL 35
Listato 2.5: Esempio di interrogazione semplice in RDF.
Data :
@ p r e f i x f o a f : <h t t p : / / xmlns . com/ f o a f /0.1/ > . : a f o a f : name ” Johnny Lee Outlaw ” .
: a f o a f : mbox <m a i l t o : jlow@example . com> . : b f o a f : name ” P e t e r Goodguy” .
: b f o a f : mbox <m a i l t o : peter@example . org> . : c f o a f : mbox <m a i l t o : c a r o l @ e x a m p l e . org> . Query :
PREFIX f o a f : <h t t p : / / xmlns . com/ f o a f /0.1/ > SELECT ?name ?mbox
WHERE
{ ? x f o a f : name ?name . ? x f o a f : mbox ?mbox } R e s u l t :
name mbox
” Johnny Lee Outlaw ” <m a i l t o : jlow@example . com> ” P e t e r Goodguy” <m a i l t o : peter@example . org>
definiti i valori delle propriet`a “name” e “mbox”, per il terzo solo il secon- do valore. Il pattern di ricerca `e un unico graph pattern (circoscritto dalle parentesi graffe), composto da due triple pattern: con la prima si richiede che un oggetto x abbia un nome (il cui valore sar`a associato alla variabile ?name), e con la seconda, che lo stesso x abbia anche una casella postale (associato a ?mbox ). L’interrogazione restituir`a tutti i risultati per le coppie “nome” e “casella postale”. La soluzione in cui a x viene associato il valore :c non compare tra i risultati in quanto, non essendogli stata definita la propriet`a “name”, non `e stato possibile effettuare il binding della variabile ?name.
Altri esempi di pattern pi`u complessi, saranno mostrati nel capitolo 3. Nonostante che anche Sparql sia un linguaggio nato per un modello per dati semistrutturati, per quanto concerne il confronto tra entit`a del grafo, si comporta in modo pi`u restrittivo rispetto a Lorel. Nel caso di uguaglianza ad esempio (operatore “=” o “!=”), se i valori possono essere confrontati (tipi di dato conosciuti ed eventualmente dopo un cast implicito) il risultato sar`a un valore booleano; al contrario, se i dati appartengono ad un tipo di dato sconosciuto, il risultato potr`a essere “vero” se sono la stessa costante o altrimenti un errore a tempo di esecuzione4. Una completa specifica riguardo alle possibilit`a di confronto, `e data in [53].
Tolleranza alla irregolarit`a della struttura e completezza dei dati Anche Sparql adotta delle soluzioni per quanto riguarda i problemi nella scrittura di interrogazioni in relazione all’irregolarit`a della struttura dei dati e incompletezza degli stessi.
La navigazione dei dati In relazione a quanto detto per il linguaggio Lorel, Sparql offre al programmatore solo i percorsi semplici simulandoli con graph pattern. Come esempio si riprende la ricerca di ristoranti vista per Lorel:
R.address.zipcode Z diventa5 in Sparql:
{?R foaf:address ?add . ?add foaf:zipcode ?Z}
4Per rilassare questo vincolo, Sparql mette a disposizione un operatore “sameterm”
che, in caso di costanti diverse di tipo sconosciuto, ritorna un valore booleano negativo anzich´e un errore.
2.2. SPARQL 37 Nella nuova versione di Sparql in fase di progetto, qualcosa nella stes- sa direzione dei percorsi complessi di Lorel `e stata pensata. Tale feature, al momento della stesura di questa tesi, rimane ancora qualcosa di bassa priorit`a [57].
Tolleranza alla non completezza Per il trattamento di questo aspetto, Sparql fin dalla sua prima versione, mette a disposizione due particolari graph patter utilizzabili nella fase di matching: “optional” e “alternative” graph pattern.
Il primo permette all’utente di definire graph pattern “opzionali” con variabili che, se trovano un corrispettivo assegnamento nel dataset, contri- buiscono alla soluzione, altrimenti, vengono lasciate senza valore non costrin- gendo il sistema a scartare l’intera soluzione.
Il secondo pattern permette invece di definire dei graph pattern alterna- tivi: se almeno uno tra i possibili trova un binding per tutte le sue variabili, allora l’intero “alternative graph pattern” ha un match nel dataset e si proce- de a calcolare il resto della soluzione. Nel caso in cui pi`u alternative abbiano un match nei dati in esame, tutte le soluzioni vengono calcolate.
Esempi specifici del loro uso sono nel capitolo 3. Costruzione dei risultati
In Sparql esistono quattro forme di interrogazione che calcolano altrettanti differenti tipi di risposte:
SELECT il risultato `e una serie di associazioni tra le variabili presenti nella clausola select e i corrispettivi valori assegnati per ciascun matching (tipo di query mostrato nel listato 2.5); il risultato pu`o eventualemente essere serializzato in XML.
CONSTRUCT oltre alla clausola where, viene definito un template per la costruzione di un nuovo dataset RDF a partire dai risultati degli assegnamenti delle variabili.
ASK si chiede di calcolare se un certo pattern ha almeno un match nel dataset.
DESCRIBE il risultato `e una descrizione di una certa risorsa.
Un esempio di interrogazione “construct” `e mostrato nel listato 2.6. La clausola construct definisce il template che avr`a ogni match del pattern di ricerca: una tripla composta dalla URI che identifica “Alice”, dalla pro- priet`a vcard:FN e dal valore assunto dalla variabile ?name ogni volta. Tutti
Listato 2.6: Esempio di interrogazione “construct” in Sparql. Data : p r e f i x f o a f : <h t t p : / / xmlns . com/ f o a f /0.1/ > . : a f o a f : name ” A l i c e ” . : a f o a f : mbox <m a i l t o : a l i c e @ e x a m p l e . org> . Query : PREFIX f o a f : <h t t p : / / xmlns . com/ f o a f /0.1/ > PREFIX v c a r d : <h t t p : / /www. w3 . o r g /2001/ vcard−r d f /3.0#> CONSTRUCT
{ <h t t p : / / example . o r g / p e r s o n#A l i c e > v c a r d :FN ?name } WHERE { ? x f o a f : name ?name } R e s u l t : @ p r e f i x v c a r d : <h t t p : / /www. w3 . o r g /2001/ vcard−r d f /3.0#> . <h t t p : / / example . o r g / p e r s o n#A l i c e > v c a r d : FN ” A l i c e ” .
2.3. G-LOG 39