The Web of Data. Ormai è facile imbattersi in questa espressione. Ma qual è il suo significato?
Siamo tutti d’accordo sul definire il web come un insieme di dati. Più precisamente, il Web of Data è un database distribuito : mentre per il www il livello di granularità sta nel recupero dei file, per il Web of Data questo livello di granularità è insito nel recupero delle informazioni. Inoltre l’informazione non necessariamente deve essere contenuta in un file, la sua esistenza si basa solo su una URI e il suo significato si basa sulle relazioni con altre URIs. Il Web delle URIs è il Web of Data.

Qui si sottolinea dunque una basilare differenza. Lo standard per rappresentare le relazioni tra le URIs e tra queste e stringhe di vario tipo, come già descritto in un precedente post, è il modello RDF.

Le informazioni sono raccolte in Database (DB in seguito), i quali vanno interrogati e qui si pone allora il problema di unificare le rappresentazioni di Dati, di Knowledge (di cui gli Schemi sono un subset), di Quieries e di Modelli ( i concetti). L’approccio tradizionale è quello del database relazionale SQL (per chiarire).

Con l’RDF tale approccio è stato superato con l’introduzione di un linguaggio più evoluto di interrogazione: lo SPARQL, acronimo che sta per SPARQL Protocol and RDF Query Language e che è uno standard W3C.

Il salto da SQL a SPARQL è avvenuto perché si è passati ad un diverso approccio di rappresentazione ( e quindi ad un diverso linguaggio di interrogazione) dei DB.

Vediamo un esempio in dettaglio.

1) Titti è una persona

2) Wolf è un cane

3) Titti e Wolf sono grandi amici

Nella rappresentazione tradizionale di un Database Relazionale, le informazioni si tradurrebbero come segue:

Un più efficace modello di rappresentazione è quello che si serve dei Grafi, mutuato dal concetto di grafo in Matematica, ed è chiamato appunto  Graph Database:

Se volessimo espendere il modello potremmo inserire il concetto/la relazione che, sia un essere umano, sia un cane sono mammiferi e quindi, una volta definita la classe Mammifero,  E.Umano e Cane diventeranno  delle sottoclassi in un Db relazionale.  Il Graph Database diventerebbe   :

Potremmo espendere ulteriormente se aggiungessimo una relazione per indicare che Titti guida la sua automobile: in tal caso dovremmo sviluppare il Graph DB rispetto ad un ulteriore rappresentazione relazionale in cui avremo inserito una tabella Auto_Table.

La rappresentazione via grafi è molto più snella ed inoltre più immediata. Dal punto di vista del linguaggio, si è passato dal SQL allo SPARQL per interrogare RDF. E’ stato davvero necessario? E quali sono i vantaggi? La sintassi inuitiva è necessaria per le query semantiche!
Passiamo dunque dai modelli ai linguaggi . SQL vs SPARQL. SQL permette di definire queries sugli attributi degli oggetti di un DB, mentre SPARQL ne consente queries di relazioni! E’ stato infatti strutturato a partire da triple (RDFModel)e riprende alcuni elementi della sintassi di SQL.
Analizziamo il Tracking degli ordini di alcuni prodotti.

Come si vede dalla figura successiva, un modello relazionale, piatto e tabulare (tante colonne, altrettanti attributi), è meno intuitivo e snello di un RDF (Graph) che peraltro, mette in evidenza intuitivamente le relazioni tra gli oggetti del Database:

E mentre SQL limita le relazioni ai valori degli attributi:

…
FROM Orders AS o
JOIN Products AS p ON o.product=p.id

SPARQL ha i link proprio nel data model che sta interrogando

…
WHERE { ?o <Orders.products> ?p }

Inoltre la query SPARQL si basa sul meccanismo del “pattern matching” e in particolare su un costrutto, il “triple pattern”, che ricalca la configurazione a triple delle asserzioni RDF fornendo un modello flessibile per la ricerca di corrispondenze.

In luogo del soggetto e dell’oggetto questo “triple pattern” prevede due variabili, contrassegnate con ?.

Le variabili sono da considerarsi come  incognite dell’interrogazione, orders.products funge invece da costante: le triple RDF che trovano riscontro nel modello associeranno i propri valori alle variabili corrispondenti.

E mi preme sottolineare qui la differenza tra la parola chiave Union in SPARQL e la stessa in SQL:

in SPARQL
WHERE { { ?x <TableA.field> ?y }
UNION
{ ?x <TableB.field> ?y } }
in SQL
JOIN ( SELECT TableA.field AS foo FROM … WHERE …
UNION
SELECT TableB.field [AS foo] FROM … WHERE … ) AS U0 ON U0.foo=…

UNION, che esprime un OR logico dichiara che la query non si limita  alle triple che soddisfano entrambi i triple patterns, ma cattura sia quelle che soddisfano il primo, sia quelle che soddisfano il secondo..

Per maggiori dettagli rimando a http://www.w3.org/2006/Talks/0518-SPASQL/

Siamo una Generazione C, forse sarebbe il caso di fare un salto quantico verso la generazione R 3.0 .

Dal Web 2.0 al Web 3.0 : Linked Data – Connect Distributed Data across the Web !