Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web

Università degli Studi di Roma La Sapienza

Facoltà di Ingegneria

Corso di Laurea in
Ingegneria dell'Informazione ind. Informatica

Joseki : un server per interrogare risorse
RDF attraverso un'interfaccia Web

Tesi di Laurea di

Daniele Palma

20 Luglio 2010

Relatore:
Prof. Ugo Vitti

2

Desidero innanzitutto ringraziare il Professor Ugo Vitti per le numerose ore
dedicate alla mia tesi. Infine, ho desiderio di ringraziare con affetto i miei
genitori per il sostegno ed il grande aiuto che mi hanno dato per essermi stato
vicino ogni momento durante questi anni di lavoro.

3

Indice Generale
Indice delle Figure 6

Indice delle Tabelle 9

1 - Introduzione 10

2 - Semantic Web 12
2.1 Che Cos'è?................................................................................................12
2.2 L'Architettura del Semantic Web.............................................................12
2.3 I principi del Semantic Web.....................................................................14
2.4 I Linguaggi del Web Semantico...............................................................14

3 - Resource Description Framework – RDF 17
3.1 Il Modello.................................................................................................18
3.2 La Sintassi................................................................................................20
3.3 La Grammatica Formale..........................................................................23
3.4 RDF Schema............................................................................................26
3.4.1. Classi e Proprietà.......................................................................27
3.4.2. I Vincoli....................................................................................29
4 - Joseki – Il server RDF di JENA 31
4.1 Joseki........................................................................................................31
4.2 Jena...........................................................................................................32
4.2.1. I tools di Jena............................................................................34
4.3 Introduzione a SPARQL..........................................................................35
4.3.1. Il Pattern Matching....................................................................36
4.3.2. Restrizione sui Valori................................................................39
4.3.3. Manipolazione del risultato.......................................................40
4.4 Un esempio di utilizzo.............................................................................40

5 - Procedure di installazione 43
5.1 Installazione di Joseki in locale...............................................................43
4

5.1.1. Configurazione di Joseki..........................................................44
5.2 Installazione di Joseki in remoto..............................................................50
5.3 Installazione di Jena.................................................................................53

6 - Risorse RDF pubbliche 54
6.1 Freebase...................................................................................................54
6.1.1. Esempio di risorsa Freebase.....................................................55
6.2 Dbpedia....................................................................................................57
6.2.1. Esempio di risorsa Dbpedia......................................................58
6.3 MERLOT.................................................................................................60
6.3.1 Esempio di risorsa MERLOT...................................................60

7 - Interrogazione di risorse RDF 62
7.1 Query su un data-set locale......................................................................62
7.2 Query su data-set remoti..........................................................................66

8 - Conclusione e sviluppi futuri 73

Appendice A 74

Appendice B 79

Sitografia 82

5

Indice delle Figure

Capitolo 2:
Fig 2.1 : Architettura del Semantic Web
Fig 2.2 : file XML

Capitolo 3:
Fig 3.1: Grafo corrispondente alla frase dell' ES 3.1
Fig 3.3 : Rappresentazione in RDF del ES 3.3
Fig 3.4 : Rappresentazione prima forma abbreviata
Fig 3.5 : Forma normale dell ES 3.5
Fig 3.6 : Forma abbreviata dell ES 3.5
Fig 3.9 :Equivalenza scrittura tra RDF e RDF schema
Fig 3.10 : RDF schema dell ES 3.8
Fig 3.11 : RDF schema del ES 3.8

Capitolo 4 :
Fig 4.1: Joseki
Fig 4.2: Stack di Joseki
Fig 4.3 : Rappresentazione del modello dell' ES 4.1
Fig 4.4 : Creazione del modello e delle risorse dell ES 4.1
Fig 4.5 : Richiesta degli Statements del modello
Fig 4.6 : Richiesta del s p o di uno stament
Fig 4.7 : Scrittura del contenuto del modello
Fig 4.8 : Lettura di un modello
Fig 4.9 : Rappresentazione di alcune triple
Fig 4.10 : pattern-matching
Fig 4.11 : Semplice query
6

Fig 4.12 : uso del comando OPTIONAL
Fig 4.13 : Uso di UNION
Fig 4.14 : Query con restrizione su un valore
Fig 4.15 : Operatore Distinct
Fig 4.16 : Altri operatori per la manipolazione
Fig 4.17 : Query per un primo utilizzo di Joseki
Fig 4.18 : Frammento del file books.n3

Capitolo 5 :
Fig 5.1 : Uso comando unzip
Fig 5.2 : Uso comando chmod
Fig 5.3 : Settaggio variabile d'ambiente
Fig 5.4 : Avvio di joseki
Fig 5.5 : Dichiarazione dei prefissi della configurazione di Joseki
Fig 5.6 : Sezione del servizio di base
Fig 5.7 : Selezione del data-set
Fig 5.8 : Data-set di un modello da file
Fig 5.9 : Data-set costruito su più grafici
Fig 5.10 : Dichiarazione di più modelli
Fig 5.11 : Accesso ad un modello su Database
Fig 5.12 : Dichiarazione di un processore standard
Fig 5.13 : Dichiarazione di un processore con data-set fisso
Fig 5.14 : Uso comando scp
Fig 5.15 : Uso comando ssh
Fig 5.16 : Url di riferimento del server
Fig 5.17 :Uso del comando nohup
Fig 5.18 : Modifica del file rc.local
Fig 5.19 : Visone del file rc.local
Fig 5.20 : De-compattazione di Jena
Fig 5.21 : Set variabile d'ambiente di Jena
Fig 5.22 : Aggiunta permessi di Jena

7

Capitolo 6 :
Fig 6.1 : Esempio di Argomentazioni Freebase
Fig 6.2 : Raggruppamento dei topic
Fig 6.3 : Visualizzazione delle risorse
Fig 6.4 : Scelta del formato
Fig 6.5 : Server offerto da Dbpedia
Fig 6.6 : Rappresentazione della risorsa Semantic Web
Fig 6.7 : Formati di conversione della pagina
Fig 6.8 : Categorie delle risorse

Capitolo 7 :
Fig 7.1 :Query per l'estrazione delle proprietà del data-set
Fig 7.2 : Risultato della query della Fig 7.1
Fig 7.3 : Risorsa e titolo delle ricerche
Fig 7.4 : Risultato della query in Fig 7.3
Fig 7.5 : Prelevo , titolo , data di sviluppo e sito del progetto
Fig 7.6 : Risultato query della Fig 7.5
Fig 7.7 : Estrazione ID, nome , Livello e data
Fig 7.8 : Risultato query 7.7
Fig 7.9 : Estrazione nome e data di nozze delle principesse europee
Fig 7.10 : Risultato query in Fig 7.9
Fig 7.11 : Query sulla tavola periodica degli elementi
Fig 7.12 : Risultato della query mostrata nella Fig 7.12
Fig 7.13 : nome e simbolo e peso degli elementi con peso > dell'uranio
Fig 7.14 : risultato query mostrata in Fig 7.13
Fig 7.15 : Interrogazione di 2 data-set
Fig 7.16 : Risultato delle query in Fig 7.15
Fig 7.17 : Estrazione proprietà DC
Fig 7.18 : Proprietà DC
Fig 7.19 : Estrazione proprietà VCARD
8

Fig 7.20 : Proprietà standard VCARD

Indice delle Tabelle

Capitolo 3
Tab 3.1 : elementi ES 3.1

Capitolo 4
Tab 4.1 : Risultato della query in Fig 4.11
Tab 4.2 : Risultato query della Fig 4.12
Tab 4.3: Operatori SPARQL
Tab 4.4: Risultato Query

9

Capitolo 1 Introduzione

CAPITOLO 1

Introduzione
Lo scopo di questa tesi, e' manipolare alcune risorse pubbliche con un processore
SPARQL installando un server per l'interrogazione di risorse RDF (Resource
Description Framework).
Abbiamo scelto di lavorare con il server Joseki, che mette a disposizione un'ampia
documentazione, e supporta il linguaggio di interrogazione SPARQL, standardizzato dal
W3C [1], in un ambiente di lavoro web.
Il Web Semantico si occupa di 2 cose: formati comuni per l'integrazione e la
combinazione di dati recuperati da diverse fonti e linguaggi per indicare come i dati
siano correlati ad oggetti del mondo reale. Ciò significa che i dati presenti in un
database, su una macchina possono portare ad un insieme infinito di database che
riguardano tutti lo stesso oggetto.
Tutti gli standard, i linguaggi e il modo di esprimere i concetti, sono racchiusi nella
struttura a gradini del Semantic Web. Questa struttura, insieme a tutti i livelli che ne
fanno parte, sarà' descritta all'interno del capitolo 2.
Il Resource Description Framework [14], molto simile all'XML, è parte integrante della
struttura del Semantic Web e ne costituisce uno dei mattoni fondamentali. L'RDF
descrive e definisce le proprietà di moltissime risorse presenti in rete: nel capitolo 3 se
ne descrive il modello e la sintassi, oltre all'RDF Schema [18], che riesce ad imprimere
ed a restringere il dominio di applicazione di una proprietà.
Nel capitolo 4, viene descritto dettagliatamente il funzionamento di Joseki [4] e di come
permetta, mediante l'uso del linguaggio di interrogazione SPARQL, di estrarre
informazione dalle risorse. Verrà spiegata la sintassi SPARQL ed inoltre si farà uso delle
librerie di Jena, che permettono di manipolare un documento in RDF [22].
Joseki utilizza indirettamente il server Jetty per l'esecuzione e si mette in ascolto sulla
porta 2020 (una volta attivato , andare su http://localhost:2020/sparql ).

10

Capitolo 1 Introduzione

Nel capitolo 5 e' presentata l'installazione del software, comprensiva di tutti i comandi
utilizzati; verrà spiegato come installare il server Joseki localmente al sistema o su una
macchina remota. Inoltre, viene mostrata la configurazione dei servizi che Joseki ci
offre e si passerà poi all'installazione ed alla verifica di alcuni tools offerti da Jena per la
manipolazione di risorse RDF direttamente dal terminale.
Si provvederà nel capitolo 6 ad illustrare alcuni repository pubblici ricercati sul web,
come DBpedia o Freebase, che manipolano grandi quantità di risorse, mettendole a
disposizione del pubblico. Si evidenzia come questi repository sfruttino direttamente
tutti i concetti spiegati nella tesi per la manipolazione delle risorse.
Infine, nel capitolo 7 sono riportate le query effettuate durante la tesi. Tali query sono
state catalogate in due gruppi: quelle eseguite su data-set locali per il server Joseki, e
quelle eseguite su data-set remoti per lo stesso server Joseki. Per accedere al servizio
Joseki via Web, si deve accedere all'indirizzo http://151.100.106.21:2020, oppure per
accedere ad un insieme di risorse correlate a www.retilatina.eu/palma/index.html.

11

Capitolo 2 Semantic Web

CAPITOLO 2

Semantic Web

2.1. Che cos'è ?
Con l'espressione "Semantic Web" si intende un insieme di tecnologie che hanno
l'obiettivo di rendere le informazioni comprensibili ed elaborabili da parte di
programmi: in pratica, lo scopo sta nel permettere a "macchine" (intese come
infrastrutture e applicazioni software) di creare nuova conoscenza traendo delle
conclusioni a partire dalla base di conoscenza iniziale.
Attraverso l'interpretazione del contenuto dei documenti che il Web semantico offre,
saranno possibili ricerche molto più evolute delle attuali, basate sulla presenza nel
documento di parole-chiave ed altre operazioni specialistiche, come la costruzione di
reti di relazioni e connessioni tra documenti, secondo logiche più elaborate del semplice
collegamento ipertestuale.

2.2. L' Architettura del Semantic Web
Per quanto riguarda standard e tecnologie, il Semantic Web deve essere inteso come una
struttura "a gradini": uno "stack" tecnologico, formato da più componenti, in cui ogni
livello è la base per gli standard definiti ai livelli superiori ( Fig 2.1 ).

Fig 2.1 : Architettura del Semantic Web

12


• Alla base di questa architettura c'è lo standard URI (Uniform Resource
Identifiers) [9], che viene usato per la definizione univoca di risorse online :
documenti, file e indirizzi internet. Al contrario, lo standard UNICODE è un
sistema di codifica che associa una combinazione di bit ad ogni simbolo,
carattere o segno, in modo indipendente dal programma, dalla piattaforma o
dalla lingua utilizzata.

• Al livello superiore si trova il metalinguaggio XML (eXtensible Markup
Language) [7], che è di fondamentale importanza, unitamente ai NS
(NameSpace) [8] e a XML Schema. XML è un linguaggio che porta con se
alcune informazioni sulla semantica degli oggetti, mentre i NS, che vengono
definiti tramite degli URI, garantiscono l' interoperabilità tra i dizionari di meta-
dati.

• RDF (Resource Description Framework) [14] e RDF Schema [18]
costituiscono il linguaggio per descrivere le risorse online e i loro tipi, per l
'interoperabilità semantica di dati e informazioni e consentono agli agenti
intelligenti di effettuare inferenze logiche.

• Al livello superiore si trova il Vocabolario delle Ontologie .Le Ontologie sono
sistemi di meta-dati, riferiti a specifici vocabolari, che permettono di descrivere
le relazioni tra le risorse Web, consentendo agli agenti intelligenti di interpretare
e comprendere i dati.

Non di minore importanza, ma ancora in fase di sviluppo, troveremo i livelli di :

• Logica : prevede l'implementazione di un linguaggio che consente di prevedere
dei risultati.

13


• Firma Digitale : è il sistema di autenticazione dei documenti digitali, la firma
digitale attesta che una specifica persona ha scritto quel
determinato documento.

• Fiducia : il Web Semantico può essere osservato come un enorme database in
cui l'utente può accedere, ma è a sua discrezione comprendere quali
siano i dati affidabili da quelli inaffidabili.

2.3. I principi del Semantic Web
Il Semantic Web si basa su sei principi fondamentali che sottendono all'architettura del
Web Semantico e ne descrivono le caratteristiche essenziali :

1. Ogni cosa può essere identificata attraverso una URI .
2. Le risorse e i Link possono avere un “tipo”.
3. L'informazione parziale è tollerata.
4. Non c'è bisogno di una verità assoluta.
5. L'evoluzione è tollerata.
6. Design minimalista

2.4. I Linguaggi del Semantic Web
Il Web, è un enorme contenitore di informazioni, si è sviluppato mediante l'ausilio del
linguaggio HTML, questo si preoccupa soprattutto di curare la formattazione grafica dei
documenti nel web e non fornisce nessun supporto per strutturare e descrivere queste
informazioni dal punto di vista semantico.
Il linguaggio HTML permette di condividere informazioni in modo semplice, l'unico
presupposto è che queste informazioni siano costituite solamente da testo e immagini
con collegamenti ipertestuali.
Attualmente le informazioni sul web sono diventate molto più complesse: video,
database, musica e molto altro. E' necessario quindi, un linguaggio che sia in grado di:
descrivere tipologie di informazioni differenti e specifiche, definire relazioni complesse
di collegamenti fra documenti e trasmettere informazioni in diversi formati.
14


Nasce, a tal proposito, XML: un metalinguaggio che permette di definire e creare
sintatticamente dei linguaggi personalizzati di markup. Si tratta di un linguaggio aperto
e basato su testo, che in termini pratici ci consente di esplicitare la struttura di un
documento dal punto di vista sintattico, attraverso marcatori all'interno del testo.
Un documento XML è organizzato secondo una struttura logica ad albero e non
presenta un insieme predefinito di elementi, ma ci consente di crearne di nuovi in base
alle nostre esigenze.
Esiste un elemento radice che deve essere sempre presente, ogni elemento può avere dei
figli che, a loro volta, possono essere specificati da particolari attributi.
In Fig 2.2 viene mostrato un tipico documento .xml :

<?xml version="1.0" encoding="UTF-8"?>
<utenti>
<utente>
<nome> Daniele </nome>
<cognome> Palma </cognome>
<indirizzo> Sezze </indirizzo>
</utente>
<utente>
<nome> Marco</nome>
<cognome> Rossi </cognome>
<indirizzo> Roma </indirizzo>
</utente>
</utenti>

Fig 2.2 : file XML

Esistono inoltre, diverse tecnologie di supporto all'XML, come le DTD ( Document
Type Definition ), documenti attraverso cui si specificano le caratteristiche strutturali di
un documento XML, grazie all'ausilio di una serie di "regole grammaticali". In
particolare, si definisce: l'insieme degli elementi del documento XML, le relazioni
gerarchiche tra gli elementi, l'ordine di apparizione nel documento XML e quali
elementi e quali attributi sono opzionali o meno.
Una seconda tecnologia di supporto è XML Schema che, come la DTD, serve a
definire la struttura di un documento XML. Il W3C consiglia di adottarlo al posto della

15


DTD stessa, essendo una tecnica più nuova ed avanzata. La sua sigla è XSD, ( XML
Schema Definition ).
In conclusione, per poter essere correttamente interpretato da un browser, un documento
XML deve essere ben formato, deve cioè possedere le seguenti caratteristiche:

• Un prologo, che è la prima istruzione che appare scritta nel documento. Nel
nostro caso: <?xml version="1.0" encoding="UTF-8"?>.

• Un unico elemento radice (ovvero il nodo principale, chiamato root element)
che contiene tutti gli altri nodi del documento. Nell' ES 2.1 : <utenti>.

• All'interno del documento tutti i tag devono essere bilanciati.

Se il documento XML non contiene errori si dice Well Formed (scritto correttamente).
Se il documento è well formed e in più rispetta i requisiti strutturali definiti nel file DTD
o XML Schema associato, viene chiamato Valid (valido).
Un altro linguaggio di maggior importanza, usato per descrivere le risorse sul Web, è
RDF che analizzeremo e presenteremo nel CAP 3.

16

Capitolo 3 RDF-Resource Description Framework

CAPITOLO 3

Resource Description Framework - RDF

La soluzione proposta dal W3C [14] per elaborare i meta-dati, usati nella descrizione
delle risorse presenti nel Web, consiste nell’utilizzo del Resource Description
Framework ( da ora in avanti RDF ).
Fra gli obiettivi che il W3C si è proposto di raggiungere con la definizione di RDF
possiamo considerare: interoperabilità fra applicazioni e sviluppo di
applicazioni automatizzate per il trattamento delle risorse del Web in modo semplice.
RDF potrà essere utilizzato in svariate aree applicative, come ad esempio, la
catalogazione di risorse facenti parte di un sito Web o di una libreria digitale,
descrivendone il contenuto e le relazioni esistenti; rendere più efficienti
le indicizzazioni effettuate dai motori di ricerca; aiutare la condivisione e lo scambio di
informazioni da parte di agenti software intelligenti.
In questo paragrafo, verrà introdotto il modello usato per rappresentare RDF e la
sintassi usata per codificare e trasportare i meta-dati così espressi.
Tale codifica verrà effettuata in modo da massimizzare l’interoperabilità e
l’indipendenza dai server che forniranno i meta-dati e dai client che usufruiranno di tali
servizi. La sintassi presentata farà uso di XML .
Inoltre, bisogna sottolineare come l’obiettivo di RDF sia quello di definire un
meccanismo per descrivere risorse che non fa assunzioni su un particolare dominio
applicativo, né definisce a priori la semantica per uno specifico dominio.
La definizione di tale meccanismo sarà quindi indipendente dal campo di applicazione
e permetterà la descrizione di informazioni relative ad ogni dominio.

17


3.1. Il modello
RDF si basa su un modello per rappresentare proprietà e valori ad esse
associate. Le proprietà possono essere pensate come attributi di risorse e
corrispondono ad una coppia attributo-valore.
Inoltre, mediante le proprietà, si possono rappresentare le relazioni fra le risorse e
quindi il modello di RDF può essere visto come uno schema entità-relazione. Per usare
la terminologia della programmazione object-oriented, le risorse possono essere viste
come oggetti e le proprietà come variabili d’istanza.
Il modello è composto da tre tipologie di oggetti:

Risorse : tutto ciò che viene descritto da RDF è detto risorsa. Una risorsa può
essere una pagina Web o una parte di essa ( identificata da un elemento
HTML o XML) o un intero sito Web. L’identificatore di ogni risorsa è il
proprio URI e pertanto una risorsa può anche essere un oggetto non
direttamente accessibile dal Web.

Proprietà: una proprietà è una caratteristica, un attributo o una relazione utilizzata per
descrivere una risorsa. Ogni proprietà ha un significato specifico, definisce i
valori che può assumere e i tipi di risorse a cui può essere associata.

Asserzioni: una risorsa con una proprietà ed un valore ad essa associato è
un’asserzione. Gli oggetti che prendono parte a questa associazione sono
detti, rispettivamente: il soggetto, il predicato e l’oggetto. L’oggetto può
essere una risorsa o un letterale.

18


ES 3.1 La frase: “Mario Rossi è l’autore della risorsa identificata dall’URL
̃
http://www.myhost.org/ mrossi” è composta dagli elementi elencati nella
tabella seguente.

Soggetto (risorsa) ̃
http://www.myhost.org/ mrossi
Predicato (proprietà) Autore

Oggetto (letterale) “Mario Rossi”
Tabella 3.1 : elementi ES 3.1

Questa frase può anche essere rappresentata mediante un grafo in cui i nodi (gli ovali)
rappresentano le risorse e gli archi rappresentano le proprietà. I nodi che rappresentano
invece dei letterali sono disegnati come rettangoli.

Autore
̃
http://www.myhost.org/ mrossi Mario Rossi


ES 3.2 L’oggetto della frase: “La persona di nome Mario Rossi con email
mrossi@myhost.org è autore della pagina identificata dall’URL
̃
http://www.myhost.org/ mrossi” è questa volta non più un letterale, ma
un’entità` strutturata, rappresentata da un’altra risorsa.

19


̃
http://www.myhost.org/ mrossi

Autore

Nome E-mail

Mario Rossi mrossi@myhost.org


3.2 La Sintassi
In questo paragrafo verranno presentati due tipi di sintassi per codificare un’istanza del
modello di RDF [16] :

La sintassi di serializzazione: permette di esprimere il modello di RDF in maniera
regolare.
La sintassi abbreviata: estende la sintassi precedente, fornendo altri costrutti che
permettono una scrittura più compatta del modello.

Queste sintassi hanno comunque, lo stesso potere espressivo. Ogni proprietà assegnata
ad una risorsa viene elencata dentro un elemento rdf:Description. Questo elemento
permette di identificare la risorsa mediante l’attributo rdf:about, contenente l’URI di
tale risorsa. Se invece la risorsa non ha un URI, questo può essere fornito usando
l’attributo rdf:ID; in questo modo viene creata una risorsa che fa da proxy per quella
originaria.
Le proprietà così specificate, corrispondono ad archi diversi di un grafo relativo al
documento RDF. Ad ogni proprietà deve inoltre essere assegnato
uno schema. Questo può essere fatto aggiungendo ad ogni proprietà il namespace in cui
viene definito l’elemento che rappresenta la proprietà stessa.

20


Si può pensare ad uno schema come ad un dizionario, che definisce i termini che
verranno adottati e vi associa un particolare significato.

ES 3.3 La frase dell’ES 3.1: “Mario Rossi è l’autore della risorsa
̃
definita dall’URI http://www.myhost.org/ mrossi” può essere rappresentata
in RDF/XML come :

<?xml version="1.0"?>
<rdf:RDF
xmlns: rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns: s="http://schema.org/">
<rdf:Description rdf:about="http://www.myhost.com/~mrossi">
<s:Autore>Mario Rossi</s:Autore>
</rdf:Description>
</rdf:RDF>

Fig 3.3 : Rappresentazione in RDF del ES 3.3

Nei casi in cui sia preferibile usare una forma più compatta, si utilizza
la forma abbreviata. Ne esistono tre forme, utilizzabili solo in particolari condizioni:

1.Si può utilizzare, nel caso in cui, non vi siano proprietà ripetute più volte entro
l’elemento rdf:Description e i valori di tali proprietà siano dei letterali. In questo
caso le proprietà possono essere scritte come attributi dell’elemento
rdf:Description.

ES 3.4 Il documento scritto nell’ES 3.3 diventa:

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://schema.org/">
<rdf:Description rdf:about="http://www.myhost.com/~mrossi"
s:Autore="Mario Rossi"/>
</rdf:RDF>

Fig 3.4 : Rappresentazione prima forma abbreviata

21


2.Questa forma è applicabile quando l’oggetto di un’asserzione è un’altra
risorsa, le cui proprietà sono definite nel documento stesso ed i cui valori
sono dei letterali. In questo caso i predicati della risorsa referenziata diventano
attributi del predicato che referenzia la risorsa stessa.

ES 3.5 La frase: “La persona di codice 1375 si chiama Mario Rossi e ha email
̃
mrossi@myhost.org; la risorsa definita dall’URI http://www.myhost.org/ mrossi
è stata creata da costui” può essere scritta come:

<rdf:RDF
<s:Autore rdf:resource="http://www.myhost.com/people/1375"/>
</rdf:Description>
<rdf:Description rdf:about="http://www.myhost.com/people/1375">
<s:Nome>Mario Rossi</s:Nome>
<s:Email>mrossi@myhost.org</s:Email>
</rdf:Description>
</rdf:RDF>

Usando la seconda forma abbreviata, si ottiene:

<rdf:RDF
<s:Autore rdf:resource="http://www.myhost.com/people/1375"
s:Nome="Mario Rossi"
s:Email="mrossi@myhost.com"/>
</rdf:Description>
</rdf:RDF>

3. Questa forma abbreviata si applica quando l’elemento rdf:Description
contiene rdf:type. Questo elemento definisce il tipo della risorsa. In questo caso,
il tipo viene usato direttamente come proprietà della risorsa.

22


ES 3.6 Se si volesse rappresentare il fatto che la risorsa
http://www.myhost.com/people/1375” è un oggetto di tipo “Persona”, la frase
dell’ES 3.5 diventa:

<rdf:RDF
<s:Autore>
<rdf:Description rdf:about="http://www.myhost.com/people/1375">
<rdf:type rdf:resource="http://schema.org/Persona"/>
</rdf:Description>
</s:Autore>
</rdf:Description>
</rdf:RDF>

Usando la terza forma abbreviata si ottiene:

<rdf:RDF
<s:Autore>
<s:Persona rdf:about="http://www.myhost.com/people/1375">
</s:Persona>
</s:Autore>
</rdf:Description>
</rdf:RDF>

3.3 La Grammatica Formale
Di seguito, sono presentate e commentate le produzioni grammaticali
che definiscono il modello RDF [19]. E' da notare, comunque, che la grammatica qui

23


definita è in parte differente da quanto era stato formalizzato nelle prime specifiche dal
W3C .

1. RDF ::= "<rdf:RDF>" description* "</rdf:RDF>" description

2. description ::= "<rdf:Description" idAboutAttr? bagIdAttr?propAttr* "/>"

| "<rdf:Description" idAboutAttr? BagIdAttr? propAttr* ">"
propertyElt"</rdf:Description>"

| typedNode

3. idAboutAttr ::= idAttr | aboutAttr

4. idAttr ::= "rdf:ID=/"" IDsymbol "/""

5. aboutAttr ::= "rdf:about=/"" URI-reference "/""

6. bagIdAttr ::= "rdf:bagID=/"" IDsymbol "/""

7. propAttr ::= typeAttr | propName "=/"" string "/""

8. typeAttr ::= "rdf:type=/"" URI-reference "/""

9. propertyElt ::= "<" propName idAttr? ">" value"</" propName ">"

| "<" propName idAttr? parseLiteral ">"literal "</" propName ">"

| "<" propName idAttr? parseResource ">"propertyElt*
"</"propName ">"

| "<" propName idRefAttr? BagIdAttr? PropAttr* "/>"

24


10. typedNode ::= "<" typeName idAboutAttr? BagIdAttr? propAttr* "/>"
| "<" typeName idAboutAttr? bagIdAttr?propAttr* ">"
propertyElt*"</" typeName ">"
11. propName ::= Qname

12. typeName ::= Qname

13. idRefAttr ::= idAttr | resourceAttr

14. value ::= description | string

15. resourceAttr ::= "rdf:resource=/"" URI-reference "/""

16. Qname ::= NSprefix ":" name

17. URI-reference ::= string, interpreted per [BLFIM98]

18. IDsymbol ::= (any legal XML name symbol)

19. name ::= (any legal XML name symbol)

20. NSprefix ::= (any legal XML namespace prefix)

21. string ::= (any XML text, with "<", ">", and "" escaped)

22. parseLiteral ::= "rdf:parseType=/"Literal/""

23. parseResource ::= "rdf:parseType=/"Resource/"

24. literal ::= (any well-formed XML)

Ogni propertyElt e di un elemento rdf:Description corrisponde ad una tripla (p, r, v), in
cui (vedi produzione 9):

• p è il risultato della concatenazione del namespace a cui appartiene e con il nome
stesso di e;

• r rappresenta :

– una risorsa identificata dal valore dell’attributo rdf:about di rdf:Description (se
presente);

25


– una nuova risorsa, il cui identificatore è dato dal valore dell’attributo rdf:ID, se
presente, oppure una nuova risorsa senza identificatore.

• v rappresenta :

– la risorsa, il cui identificatore è dato dal valore dell’attributo rdf:resource di e (se
presente);

– un letterale, nel caso in cui sia presente l’attributo rdf:parseType con valore
Literal o il contenuto di e sia del testo XML;

– una risorsa, qualora sia presente l’attributo rdf:parseType con valore Resource;

– la risorsa, il cui identificatore è ottenuto dal valore dell’attributo (anche implicito)
rdf:about o rdf:ID dell’elemento rdf:Description contenuto in e.

Quando in un elemento rdf:Description è specificato l’attributo rdf:about, l’asserzione
si riferisce alla risorsa identificata dal valore dell’attributo. Se invece, è presente rdf:ID
o rdf:bagID, la tripla stessa rappresenta una risorsa. L'URI della risorsa è dato dalla
concatenazione dell’URI del documento, all'interno del quale, è definita la tripla con il
valore dell’attributo stesso.

3.4 RDF Schema
Fino ad ora, è stato presentato il modello di RDF come un mezzo per rappresentare
meta-dati e una sintassi RDF/XML come trasporto di tale modello. In questo modo, si è
reso possibile associare delle coppie nome-valore delle risorse o URI. Ma spesso questo
non basta.
Ad esempio, nel caso in cui, si ha una proprietà che fa riferimento ad uno scrittore,
sarebbe semanticamente scorretto associarla ad una macchina o a un’abitazione. Oppure
se si ha una proprietà che rappresenta un compleanno, è importante vincolarne i valori a
delle date (e non numeri generici o caratteri). Il modello di RDF non permette di
effettuare validazione di un valore o restrizione di un dominio di applicazione di una
proprietà.

26


Questo compito è svolto, invece, da RDF Schema [18]. Però, a differenza di XML
Schema o di una DTD, RDF Schema non vincola la struttura del documento, bensì
fornisce informazioni utili all’interpretazione del documento stesso. In seguito, il
namespace di RDF Schema sarà indicato con rdfs; quello di RDF semplicemente con
rdf.

3.4.1 Classi e Proprietà
In questo paragrafo, si indicano le classi principali e le proprietà che fanno
parte del vocabolario definito da RDF Schema. Le classi permettono di definire i tipi
base di ogni risorsa che verrà descritta in RDF; le proprietà sono lo strumento utilizzato
per esprimere le relazioni fra esse.

rdfs:Resource Tutto ciò che viene descritto in RDF è detto risorsa. Ogni risorsa è
istanza della classe rdfs:Resource.

rdfs:Literal Sottoclasse di rdfs:Resource, rappresenta un letterale, una stringa di testo.

rdf:Property Rappresenta le proprietà, così come sono state definite nella sottoclasse
di rdfs:Resource.

rdfs:Class Corrisponde al concetto di tipo e di classe della programmazione object-
oriented. Quando viene definita una nuova classe, la risorsa che la
rappresenta deve avere la proprietà rdf:type impostata a rdfs:Class.

rdf:type Indica che una risorsa è membro di una classe, è ciò istanza di una
specifica classe. Il valore di rdf:type deve essere una risorsa che è istanza
di rdfs:Class (o sua sottoclasse). In pratica permette di specificare il tipo di
una risorsa.

rdfs:subClassOf Specifica la relazione di ereditarietà fra classi. Questa proprietà può
essere assegnata solo a istanze di rdfs:Class. Una classe può essere
sottoclasse di una o più classi (ereditarietà multipla).

27


rdfs:subPropertyOf Istanza di rdf:Property, si utilizza per specificare che una
proprietà è una specializzazione di un’altra. Ogni proprietà può
essere la specializzazione di zero o più proprietà.

rdfs:seeAlso Specifica una risorsa che fornisce ulteriori informazioni sul soggetto
dell’asserzione. Ciò che rappresenta questa risorsa comunque, non può
essere specificato ed è a carico dell’applicazione specificare la sua
interpretazione.

rdfs:isDefinedBy E' sottoproprietà di rdfs:seeAlso e indica una risorsa che definisce il
soggetto di un’asserzione. L’uso più comune di questa proprietà è di
fornire un URI che identifichi lo schema in cui è stato definito il
soggetto.

rdfs:Container Rappresenta la classe base da cui sono derivati i contenitori di RDF.

rdfs:ContainerMembershipPropriety E' la classe da cui derivano i membri rdf: 1,
rdf: 2, etc. dei contenitori.

ES 3.7 In questo esempio le due scritture sono equivalenti : la prima non usa RDF
schema; la seconda invece, lo adotta per la creazione di una classe chiamata
nuovoTipo.

<rdf:Description rdf:about="http://schema.org/nuovoTipo">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />
</rdf:Description>

<rdfs:Class rdf:about="http://schema.org/nuovoTipo"/>

Fig 3.9 :Equivalenza scrittura tra RDF e RDF schema

28


ES 3.8 Definiamo ora la classe Persona, la sua sottoclasse Operaio e la classe
Lavoratore, che è sottoclasse di Operaio. Infine istanziamo la classe
Lavoratore.

<rdf:RDF
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<rdfs:Class rdf:about="http://schema.org/Persona" />
<rdfs:Class rdf:ID="Operaio">
<rdfs:subClassOf rdf:resource="http://schema.org/Persona" />
</rdfs:Class>
<rdfs:Class rdf:ID="Lavoratore">
<rdfs:subClassOf rdf:resource="#Operaio" />
</rdfs:Class>
<rdf:Description rdf:about="http://lavoratori.org/mrossi">
<rdf:type rdf:resource="#Lavoratore"/>
</rdf:Description>
</rdf:RDF>
Fig 3.10 : RDF schema dell ES 3.8

3.4.2 I Vincoli
Le specifiche di RDF Schema definiscono un vocabolario che permette di effettuare
delle asserzioni vincolando le proprietà e le risorse che costituiscono l’associazione.

rdfs:ConstraintResource Sottoclasse di rdfs:Resource, le sue istanze rappresentano
costrutti di RDF Schema utilizzati per esprimere vincoli. Lo
scopo di questa classe è fornire un mezzo ai parser RDF per
riconoscere i costrutti che rappresentano vincoli. Non è però
possibile indicare al parser come utilizzare i vincoli così
identificati.

rdfs:ConstraintProperty Sottoclasse di rdf:Property e rdf:Constraint-Resource, le sue
istanze sono proprietà usate per specificare dei vincoli. Sia
rdfs:domain che rdfs:range sono sue istanze.

29


rdfs:range Usato come predicato di una risorsa r, indica le classi di cui devono essere
membre le risorse a cui verrà applicata r.

rdfs:domain Usato come predicato di una risorsa r, indica le classi valide che saranno
soggetto di un’asserzione che ha come predicato r.

ES 3.8 Riprendendo l’ES 3.7, definiamo delle proprietà,vincolandole ai tipi descritti in
precedenza. Quando re-istanziamo un oggetto di tipo Lavoratore, possiamo
comunque applicarvi i predicati definiti per le superclassi da cui discende.

<rdf:RDF
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
<rdf:Property rdf:about="http://schema.org/Nome">
<rdfs:domain rdf:resource="http://schema.org/Persona"/>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
</rdf:Property>
<rdf:Property rdf:about="http://schema.org/DataNascita">
<rdfs:domain rdf:resource="http://schema.org/Persona"/>
<rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
</rdf:Property>
<rdf:Property rdf:ID="Membro">
<rdfs:domain rdf:resource="#Lavoratore"/>
<rdfs:range rdf:resource="#Meccanico"/>
</rdf:Property>
<rdf:Class rdf:about="http://schema.org/Meccanico"/>
<rdf:Description rdf:about="http://lavoratori.org/meccanici#labour">
<rdf:type rdf:resource="http://schema.org/Meccanico"/>
</rdf:Description>
<rdf:Description rdf:about="http://Lavoratori.org/mrossi">
<rdf:type rdf:resource="#Lavoratore"/>
<s:DataNascita>08 Ottobre, 1968</s:DataNascita>
<epx:Membro
rdf:resource="http://www.iLavoratori.com/meccanici#labour"/>
</rdf:Description>
</rdf:RDF>

Fig 3.11 : RDF schema del ES 3.8
30

Capitolo 4 Joseki-Il server RDF di Jena

CAPITOLO 4

Joseki – Il server RDF di JENA
In questo capitolo, si descriveranno i servizi offerti da Jena, in particolare il server
Joseki, che con l'ausilio del linguaggio SPARQL permette di interrogare le risorse
descritte in RDF. Si procederà poi, ad un semplice utilizzo di Joseki.

4.1.Joseki
Joseki è un HTTP / SOAP engine che permette l'invio di query SPARQL via HTTP [4].
Nella Fig 4.1 viene schematizzato il funzionamento di Joseki.

Fig 4.1: Joseki

Partendo da una risorsa descritta da un file RDF , Joseki riesce ad interrogarla mediante
l'invio di query SPARQL . Nel file di configurazione iniziale di Joseki (.ttl) vengono
descritte tutte le risorse su cui far riferimento.
Tutte le query vengono inviate via HTTP, attraverso un form presente sulla pagina
iniziale del server alla porta 2020. Inoltre, prima della fase di elaborazione della query,
è possibile scegliere in che formato ricevere le informazioni richieste al server. Ad
esempio, possiamo scegliere di riceverle in formato XML, CSV ( Comma-Separated
Values ), TSV ( Tabs-Separated Values ) o semplicemente in TXT.

31


Nella Fig 4.2 viene mostrato lo stack di Joseki e di come, mediante l ausilio di Jena,
attraverso il protocollo HTTP, riesca ad interagire anche con risorse di tipo differente.

Fig 4.2: Stack di Joseki

4.2.Jena
Jena è un framework Java open source (sviluppato dal Semantic Web Research Bristol
Lab della HP) [2] per lo sviluppo di applicazioni orientate al Web Semantico. Esso
fornisce le API per la creazione, interrogazione e gestione in modo programmatico di
RDF.
Inoltre Jena, oltre alla parte di programmazione, ci offre diversi tools per gestire ,
interrogare , modificare , e convertire direttamente una risorsa.
Possiamo ad esempio, convertire le nostre risorse in diversi formati : XML , RDF , N3 ;
e interrogarle mediante il linguaggio SPARQL.

32


ES 4.1 Supponiamo di voler creare una risorsa RDF, rappresentata nella Fig 4.3 :

Risorsa

http://...../Marco_Rossi

Proprietà
VCard:FN

Marco Rossi

Attributo

Fig 4.3 : Rappresentazione del modello dell' ES 4.1

Ogni arco di un modello RDF viene chiamato Statement, e può essere diviso in 3 parti :
il soggetto , il predicato e l'oggetto. Ogni statement può anche essere chiamato tripla.
Si crea un modello (classe Model) mediante il metodo factory
ModelFactory.createDefaultModel() e si aggiungono le varie risorse e le proprietà. In
questo caso, FN , utilizzando il dizionario VCARD (la definizione di VCARD si trova
nel Appendice B ).

// creo un model
Model Esempio_4_1 = ModelFactory.createDefaultModel();

// creo le risorse aggiungendole in cascata
Resource marcoRossi = Esempio_4_1.createResource("http://..../MarcoRossi")
.addProperty(VCARD.FN, " Marco Rossi ");
Fig 4.4 : Creazione del modello e delle risorse dell ES 4.1

VCARD è un dizionario che ci permette di rappresentare tutte le proprietà che
esprimono le generalità di un individuo.
È possibile ottenere la lista degli statement contenuti nel Model mediante l'oggetto di
classe StmtIterator :

// Richiedo al modello la lista degli statement contenuti
StmtIterator iter = Esempio_4_1.listStatements();
Fig 4.5 : Richiesta degli Statements del modello

33


e ottenere puntualmente il soggetto, il predicato e l'oggetto dello statement:

Resource subject = stmt.getSubject(); // richiedo il subject
Property predicate = stmt.getPredicate(); // richiedo il predicate
RDFNode object= stmt.getObject(); // richiedo l'object
Fig 4.6 : Richiesta del s p o di uno stament

Per trascrivere il contenuto del model RDF nei vari formati di serializzazione consentiti
è possibile utilizzare il metodo write() della classe Model, specificando l'output stream
su cui scrivere con il relativo formato (XML, N-TRIPLE o N3):

model.write(fileOutputStream);// Di default XML !
model.write(fileOutputStream, "N-TRIPLE");
model.write(fileOutputStream, "N3");
Fig 4.7 : Scrittura del contenuto del modello

Analogamente, per leggere un documento RDF, si può utilizzare il metodo read() della
classe Model:

InputStream in = new FileInputStream(<< nome del file >>);
model.read(in, "", "N3");
Fig 4.8 : Lettura di un modello

4.2.1 I tools di Jena
Oltre alle librerie in grado di manipolare una risorsa in RDF, Jena ci offre diversi tools
per operare direttamente sulle risorse . Questi tools vengono lanciati su riga di comando
e sono ad azione immediata.

rdfcat : Ci permette di concatenare il contenuto di uno o più documenti RDF. Inoltre,
utilizzando le diverse opzioni disponibili , possiamo convertire la nostra risorsa
RDF in vari formati dall'XML a N3.

rdfcopy : Copia un modello. E' nostra facoltà scegliere inoltre, in quale sintassi ottenere
il risultato della copia ( N3 , XML, RDF , RDF-ABBREV )

34


rdfcompare : Controlla se due modelli sono isomorfi , ovvero se il primo può essere
mappato nell'altro.

sparql : Esegue una query direttamente sul modello. Il risultato verrà stampato sul
terminale.

4.3.Introduzione a SPARQL
SPARQL ( SPARQL Protocol and RDF Query Language) è linguaggio di interrogazione
di una risorsa RDF ed è asceso al rango di W3C Candidate Recommendation [1], come
ultimo tassello per l'edificazione del Web Semantico.
Questo linguaggio adotta la sintassi Turtle [5], un'estensione di N3 ( N-Triples ) [21],
estremamente sintetica e intuitiva al tradizionale RDF/XML.
Possiamo convertire direttamente una risorsa RDF/XML in una estensione N3 grazie
all'ausilio delle API di Jena.

In Fig 4.9 vi è un esempio pratico di alcune triple RDF espresse in turtle, che verranno
utilizzate come riferimento per gli esempi successivi.

@prefix book:<http://esempio.org/book/>
@prefix :<http://esempio.org/esempio/>
:Alpha book:autore "Mario Rossi".
:Beta book:autore "Mario Rossi".
:Gamma book:autore "Gino Bianchi".
:Gamma book:anno 1994.
Fig 4.9 : Rappresentazione di alcune triple

@prefix introduce prefissi e namespace; i due punti senza prefisso (seconda riga)
definiscono il namespace di default.
Le asserzioni sono espresse in concise sequenze soggetto-predicato-oggetto e delimitate
da un punto fermo. Gli URI sono inclusi tra parentesi uncinate e i letterali di tipo stringa
sono contrassegnati da virgolette.

35


4.3.1 Il Pattern Matching
Le query SPARQL si basano sul meccanismo del "pattern matching" [22] e in
particolare su un costrutto, il "triple pattern", che ricalca la configurazione a triple delle
asserzioni RDF, fornendo così, un modello flessibile per la ricerca di corrispondenze.

?titolo book:autore ?autore.
Fig 4.10 : pattern-matching

In luogo del soggetto e dell'oggetto questo "triple pattern" prevede due variabili,
contrassegnate con ?.
Le variabili fungono, in un certo senso, da incognite dell'interrogazione; book:autore
funge invece da costante. Le triple RDF ,che trovano riscontro nel modello, assoceranno
i propri termini alle variabili corrispondenti.

In Fig 4.11 viene mostrata una semplice query per chiarire meglio il funzionamento del
linguaggio

PREFIX book: <http://example.org/book/>
SELECT ?titolo ?autore ?anno
FROM <http://book.com/listaLibri.ttl>
WHERE {
?titolo book:anno ?anno .
}
Fig 4.11 : Semplice query

Analizzando l'esempio soprastante, possiamo vedere che : PREFIX dichiara prefissi e
namespace. SELECT definisce le variabili di ricerca da prendere in considerazione nel
risultato (nell'esempio: titolo, autore e anno). FROM specifica il set di dati su cui dovrà
operare la query (si suppone che le triple siano immagazzinate presso l'indirizzo
“http://book.com/listaLibri.ttl” ). Infine WHERE ,che definisce il criterio di selezione
specificando tra parentesi graffe uno o più "triple patterns" separati da punto fermo.
Applicando la query della Fig 4.11 al set di triple mostrate in Fig 4.9 , si ottiene il
seguente risultato:
36


titolo autore anno
Gamma Gino Bianchi 1994
Tab 4.1 : Risultato della query in Fig 4.11

Il "binding" tra variabili e termini reperiti corrispondenti (in questo caso, un termine per
ciascuna variabile) è reso in forma di tabella, come un rapporto campo-valore: le righe
rappresentano i singoli risultati, le intestazioni di cella rappresentano le variabili definite
nella clausola SELECT e le celle, i termini associati alle variabili.
La query precedente ha catturato esclusivamente le triple dotate di tutti e tre i termini
richiesti (titolo, autore, anno), escludendo le triple che ne possedevano due soltanto
(titolo, autore). È possibile riformulare la query in modo più elastico, prevedendo
l'eventuale assenza di alcuni termini. Possiamo farlo grazie al comando OPTIONAL
come si vede in Fig 4.12.

WHERE {
OPTIONAL {?titolo book:anno ?anno}
}
Fig 4.12 : uso del comando OPTIONAL

Come mostrato, il secondo pattern è dichiarato opzionale, infatti l'informazione è
aggiunta al risultato solo se disponibile, altrimenti le variabili compariranno prive di
valore (unbound). Il risultato della query mostrata in Fig 4.12 sarà :

titolo autore anno
Alpha Mario Rossi
Beta Mario Rossi
Gamma Gino Bianchi 1991
Tab 4.2 : Risultato query della Fig 4.12

37


Le risorse sprovviste della proprietà ?anno sono mostrate ugualmente e le celle dei
valori mancanti sono lasciate vuote.

Un altro modo per avere una certa elasticità nel recuperare le informazioni presenti nelle
risorse, è quello di combinare i diversi operatori logici, che ci vengono messi a
disposizione dal linguaggio SPARQL, come viene fatto nella Fig 4.13. In questa query
si produce lo stesso risultato riportato nella Tab 4.2, ma viene usata la parola chiave
UNION, che ci permette di esprimere un OR logico , che cattura le triple che soddisfano
la prima e la seconda triple patterns.

WHERE {
UNION
{?titolo cd:anno ?anno}
}
Fig 4.13 : Uso di UNION

38


4.3.2 Restrizione sui valori
Grazie ad alcuni operatori applicabili sulle variabili, è possibile restringere il campo
delle nostre ricerche ed effettuare delle query sempre più specifiche.
Di seguito, è descritta la mappatura degli operatori supportati dal linguaggio SPARQL :

A=B
A != B
A<B A e B possono essere di tipo : numerico , stringa
A>B , data e booleano
A <= B
A >= B
A*B
A/B A e B possono essere di tipo numerico
A+B
A-B
Tab 4.3: Operatori SPARQL

Nella Fig 4.14 viene mostrato un esempio di triple patterns con una restrizione sui
valori.

WHERE {
FILTER (?anno > 2000).

}
Fig 4.14 : Query con restrizione su un valore

In questo caso, la restrizione è effettuata mediante l'operatore di confronto >
( maggiore ), il filtro esclude i termini che non soddisfano la condizione definita tra le

39


parentesi tonde. Il risultato, in questo caso, è nullo ( il data-set di riferimento non
prevede valori maggiori di 2000 per la proprietà anno ).

4.3.3 Manipolazione del risultato
Mediante SPARQL, possiamo gestire a nostro piacimento il risultato delle nostre query.
Ad esempio, come in Fig 4.15, con l'operatore DISTINCT è possibile escludere dal
risultato i valori duplicati.

SELECT DISTINCT ?titolo ?autore
4.15 : Operatore Distinct

Altri costrutti supportati da SPARQL per la manipolazione del risultato sono ORDER
BY , LIMIT e OFFSET.
Nella Fig 4.16 viene mostrato l'uso degli altri operatori per la manipolazione del
risultato delle nostre query.

ORDER BY DESC(?autore)
LIMIT 10
OFFSET 10
Fig 4.16 : Altri operatori per la manipolazione

Facendo riferimento all'esempio, l'espressione ORDER BY imposta l'ordine dei risultati
della query . I risultati sono presentati in ordine decrescente (DESC) in base alla
variabile ?autore. LIMIT pone restrizioni al numero dei risultati, limitandoli, ai soli
primi 10. OFFSET permette di "saltare" un certo numero di risultati, escludendo, i primi
10.

4.4. Esempio di utilizzo
Appena Joseki viene lanciato di default, permette di eseguire query via browser
sull'elenco dei dati contenuto nel file d'esempio books.n3 (un elenco dei libri).
Lanciando il browser e collegandosi all'URL http://localhost:2020/ si visualizza una
pagina Web con una Text Box, nella quale è possibile digitare la query SPARQL che si
40


vuole eseguire. Ad esempio, inserendo nella Text Box la seguente query SPARQL, si
richiedono tutti i libri che hanno un titolo, e il relativo risultato è presentato in una
pagina HTML. In Fig 4.17 viene mostrata la query di prova che ci appresteremo ad
eseguire :

PREFIX books:<http://example.org/book/>
PREFIX dc:<http://purl.org/dc/elements/1.1/>
SELECT ?book ?title
WHERE { ?book dc:title ?title }
Fig 4.17 : Query per un primo utilizzo di Joseki

Joseki provvederà ad interrogare il file books.n3, che si presenterà come in Fig 4.18, e il
risultato della query viene visualizzato tramite una pagina web. Infatti, il client effettua
una GET passando come parametro la query inserita nella Text Box e la relativa
risposta HTTP di Joseki, che contiene il risultato della query opportunamente formattato
in HTML.

@prefix dc:<http://purl.org/dc/elements/1.1/> .
@prefix vcard:<http://www.w3.org/2001/vcard-rdf/3.0#> .
@prefix ns:<http://example.org/ns#> .
@prefix :<http://example.org/book/> .

:book1
dc:title "Harry Potter and the Philosopher's Stone" ;
dc:creator "J.K. Rowling" ;.
:book2
dc:title "Harry Potter and the Chamber of Secrets" ;
dc:creator _:a .
#(…..segue la dichiarazione dei libri....)
_:a
vcard:FN "J.K. Rowling" ;
vcard:N
[ vcard:Family "Rowling" ;
vcard:Given "Joanna"
]

Fig 4.18 : Frammento del file books.n3

41


Il risultato della query mostrata in Fig 4.17 sarà:

books title
<http://example.org/book/book7> "Harry Potter and the Deathly Hallows"
<http://example.org/book/book2> "Harry Potter and the Chamber of Secrets"
<http://example.org/book/book4> "Harry Potter and the Goblet of Fire"
<http://example.org/book/book6> "Harry Potter and the Half-Blood Prince"
<http://example.org/book/book1> "Harry Potter and the Philosopher's Stone"
<http://example.org/book/book3> "Harry Potter and the Prisoner Of Azkaban"
<http://example.org/book/book5> "Harry Potter and the Order of the Phoenix"

Tab 4.4: Risultato Query

42

Capitolo 5 Procedure di installazione del Software

CAPITOLO 5

Procedure di installazione del software

In questo capitolo descriviamo le procedure di installazione del software utilizzato, sia
su una macchina locale e sia su una macchina remota, in questo caso un server
dell'università raggiungibile all'indirizzo 151.100.106.21 sulla porta 2020.

5.1. Installazione di Joseki in locale
Innanzi tutto bisogna connettersi al sito http://www.joseki.org/, oltre a tutta la
documentazione necessaria per il funzionamento, sotto la voce download troveremo
diverse release del server, scarichiamo la più recente, nel nostro caso Joseki-3.4.1 .
Apriamo il terminale e procediamo con la de-compattazione del pacchetto, utilizzando il
comando :

unzip Joseki-3.4.1.zip
Fig 5.1 : Uso comando unzip

Sempre attraverso il terminale, dobbiamo dare i permessi di esecuzione, lettura e
scrittura a tutti i file presenti nella cartella /bin della nostra distribuzione con il
comando:

chmod u+x bin/*
Fig 5.2 : Uso comando chmod

L'asterisco include tutti i file presenti nella cartella bin.
Infine bisogna settare la variabile d'ambiente , JOSEKIROOT dove è stata installata la
distribuzione del server , per fare ciò si usa il comando :

export JOSEKIROOT= < path dell instalazione di Joseki >
Fig 5.3 : Settaggio variabile d'ambiente

43


Adesso il nostro server è pronto per l'esecuzione, basta lanciare il file rdfserver presente
nella cartella /bin .
Di default se si lancia Joseki senza specificare un file di configurazione, il server
prenderà come riferimento il file joseki-config.ttl .
Il file di configurazione viene utilizzato per specificare a quale risorsa di dati si vuole
far riferimento, perché è possibile interfacciare Joseki anche con database e risorse di
tipo differenti.

sh bin/rdfserver < file di configurazione >
Fig 5.4 : Avvio di joseki

Una volta lanciato il server, Joseki si attiverà utilizzando il protocollo HTTP sulla porta
2020, aprendo un qualsiasi browser, andare su http://localhost:2020, per interrogare le
nostre risorse .

5.1.1 Configurazione di Joseki
Il server Joseki viene configurato attraverso dei servizi, e ogni servizio viene
implementato grazie ad un processore, che esegue le query in modo fisso su data-set
predefiniti, o altrimenti riesce ad assemblare il data-set in modo dinamico a seconda
della query. Quando si pubblicano dati già esistenti, è più opportuno utilizzare un
processore che non consente un data-set da specificare nella query.
Il file di configurazione di Joseki non è altro che un grafo RDF, e questo di default
prende il nome di joseki-config.ttl ed è scritto solitamente in N3 invece di RDF|XML .
Grazie a questa configurazione il server può leggere un ampia gamma di serializzazione
RDF.
Innanzitutto, bisogna dichiarare alcuni prefissi, questi sono la base delle informazioni
del nostro file (come in Fig 5.5), dato che il file di configurazione è in RDF, l'ordine
delle sezioni non incide sul server, ma aiuta l'utente a leggere il file .
Quindi, all'interno di un file è possibile inserire più sezioni che riguardando risorse e
servizi differenti.

44


@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix module: <http://joseki.org/2003/06/module#> .
@prefix joseki: <http://joseki.org/2005/06/configuration#> .
@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
## Nota:aggiungendo rdfs:label ai nodi , Joseki
## stamperà ogni messaggio di log.
## --------------------------------------------------------------
## Approposito di questa configurazione
<> rdfs:comment "Esempio di una configurazione di Joseki" .
## --------------------------------------------------------------
## Approposito di questo server
[] rdf:type joseki:Server ;
.
Fig 5.5 : Dichiarazione dei prefissi della configurazione di Joseki

Una volta dichiarati i prefissi si passa alla descrizione dei servizi, il servizio base offerto
da Joseki è l'interpretazione del linguaggio SPARQL.
In Fig 5.6 si vede come aggiungere il servizio di base :

# Servizio 1 - Nuova sezione -
# Uso generale di un processore SPARQL , nessun data-set,
# bisogna specificare il data-set o nella query o nei parametri del
# protocollo di richiesta .
[]
rdf:type joseki:Service ;
rdfs:label "nome servizio" ;
joseki:serviceRef "sparql" ;
joseki:processor joseki:ProcessorSPARQL ;
.
Fig 5.6 : Sezione del servizio di base

Se si ha la necessità di interrogare un data-set fisso, Joseki ci permette di farlo
aggiungendo l'opportuno servizio (come si vede in Fig 5.7)

45


# Servizio 2 – processore SPARQL solo
#.per un determinato data-set
rdfs:label "SPARQL on the books model" ;
joseki:serviceRef "books" ;
# parti del data-set
joseki:dataset _:books ;
# Parti del servizio.
# Questo processore non consente né il protocollo,
# nemmeno la query per specificare i data-set.
joseki:processor joseki:ProcessorSPARQL_FixedDS ;
.

Fig 5.7 : Selezione del data-set

Passeremo ora alla sezione riguardante la dichiarazione del data-set . Un data-set può
essere definito mediante un Jena Assembler Description, ovvero un assemblatore per la
creazione di modelli. Ogni data-set di dati RDF è una raccolta di più grafici che possono
avere un nome o meno, a sua volta ogni grafico, può essere visto come un modello di
Jena, questi vengono definiti attraverso uno Jena Assembler vocabulary.
Si faranno alcuni esempi sulle sezioni del file di configurazione di Joseki che settano i
data-set, i tipi di modelli e il processore.
Questo primo data-set, mostrato in Fig 5.8, ha un solo grafico di default. Il contenuto
del data-set viene caricato da un file ( se ne possono caricare più di uno ), ma il nome
del file non conferisce il nome al modello.

46


# Dataset con un modello da file
_:books rdf:type ja:RDFDataset ;
rdfs:label "Books" ;
ja:defaultGraph
[ a ja:MemoryModel ;
rdfs:label "books.n3" ;
ja:content [ ja:externalContent <file:Data/books.n3> ]
];
.

Fig 5.8 : Data-set di un modello da file
Un esempio più complesso è mostrato in Fig 5.9, dove vengono presi due grafici da
fonti differenti, e le fonti conferiranno anche il nome al modello.

_:dataset1 rdf:type ja:RDFDataset ;
ja:defaultGraph _:model0 ;
rdfs:label "Dataset _:dataset1" ;
a:namedGraph
[ ja:graphName <http://example.org/name1> ;
ja:graph _:model1 ] ;
ja:namedGraph
[ ja:graphName <http://example.org/name2> ;
ja:graph _:model2 ] ;
.

Fig 5.9 : Data-set costruito su più grafici

Vedremo ora come definire la sezione riguardante la dichiarazione dei modelli questo
avviene attraverso lo Jena Assembler vocabulary ,in Fig 5.10 si suppone di avere
diversi modelli su cui far riferimento.

47


## Grafico individuale ( Jena chiama questi modelli )
## (la sintassi dei file dei dati è data da un file di estensioni in RDF/XML)
_:model0 rdf:type ja:MemoryModel ;
rdfs:label "Model fonde i 2 file RDF )" ;
ja:content [
ja:externalContent <file:D1.ttl> ;
] ;.
rdfs:label "Model (contenuto D1.ttl )" ;
ja:content [
] ;.
rdfs:label "Model (contenuto D2.ttl )" ;
ja:content [
ja:externalContent <file:D2.ttl> ;].

Fig 5.10 : Dichiarazione di più modelli

Se si ha la necessità, di interrogare un modello memorizzato su un qualsiasi database, si
procederà come si vede in Fig 5.11

_:db rdf:type ja:RDBModel ;
ja:connection
[
ja:dbType "MySQL" ;
ja:dbURL "jdbc:mysql://localhost/data" ;
ja:dbUser "user" ;
ja:dbPassword "password" ;
ja:dbClass "com.mysql.jdbc.Driver" ;
];
ja:modelName "books"
.
Fig 5.11 : Accesso ad un modello su Database

48


Infine, vedremo la sezione riguardante il processore, ogni descrizione del processore
può avere parametri che vengono passati ad ogni istanza di classe al momento della
creazione.
In Fig 5.12 viene mostrata la dichiarazione di un processore standard SPARQL, che
accetta query attraverso i parametri FROM | FROM NAME, e i dati vengono caricati di
volta in volta . Mentre in Fig 5.13 viene dichiarato un processore con con data-set fisso
che non accetta query attraverso i parametri FROM | FROM NAME

joseki:ProcessorSPARQL
rdf:type joseki:Processor ;
rdfs:label "Processore Generale SPARQL" ;
module:implementation joseki:ImplSPARQL ;
# Parametri : accetta query con FROM/FROM NAMED
joseki:allowExplicitDataset "true"^^xsd:boolean ;
joseki:allowWebLoading "true"^^xsd:boolean ;
## Non cè una politica di chiusura
## (i dati vengono caricati di volta in volta).
joseki:lockingPolicy joseki:lockingPolicyNone ;
.
Fig 5.12 : Dichiarazione di un processore standard

joseki:ProcessorSPARQL_FixedDS
rdfs:label "Processore SPARQL con data-set fisso" ;
# This processor does not accept queries with FROM/FROM NAMED
joseki:allowExplicitDataset "false"^^xsd:boolean ;
joseki:allowWebLoading "false"^^xsd:boolean ;
# Fixed background dataset : multiple read requests are OK
joseki:lockingPolicy joseki:lockingPolicyMRSW ;
.
Fig 5.13 : Dichiarazione di un processore con data-set fisso

49


5.2 Installazione di Joseki in remoto
Per una simulazione, che si avvicini sempre più alla realtà, abbiamo installato il server
Joseki su una macchina remota, un server dell'università. Le procedure di installazione, i
comandi da utilizzare per l'avvio di Joseki sono gli stessi del paragrafo 5.1, l'unica
differenza sta nella connessione al server remoto .
Per connetterci al server remoto apriamo la shell e digitiamo il comando :

Scp <sorgente file> -r palma@151.100.106.21 :~
Fig 5.14 : Uso comando scp

scp, sta per secure-copy, ed è uno dei programmi utilizzati per scambiare file tra gli host
di una rete, in questo caso la mia macchina ed il server.
In <sorgente file> viene inserito il path dove si trova Joseki, e -r specifica che dovrà
essere copiato tutto il contenuto della cartella selezionata. Subito dopo viene selezionato
l user, il server di riferimento e dove mandare i file, :~ ,indica la directory di base.
Naturalmente, per effettuare questa operazione il programma richiede un autenticazione
al server.
Una volta terminata l'operazione di copia, possiamo connetterci al server remoto tramite
il comando :

ssh -l palma 151.100.106.21
Fig 5.15 : Uso comando ssh

ssh è un programma per loggarsi su una macchina remota ed eseguire comandi
direttamente su questa, con -l si specifica il nome dell'utente che si connette, e poi viene
inserito l'indirizzo fisico della macchina.
Possiamo riprendere ora tutti i comandi del paragrafo 5.1 e digitarli direttamente sul
server .
Per vedere il funzionamento di Joseki, si deve aprire un qualsiasi browser e inserire
come URL :

50


URL: 151.100.106.21 : 2020
Fig 5.16 : Url di riferimento del server

I comandi descritti, non ci garantiscono il continuo funzionamento di Joseki, infatti una
volta chiusa la sessione o il terminale, il processo relativo a Joseki viene troncato dal
server e di conseguenza Joseki cesserà di funzionare.
Per far si, che ciò non avvenga, si possono utilizzare due tecniche distinte, la prima si
riferisce ad un avvio manuale del servizio utilizzabile in fase di sviluppo/test
dell'applicazione, la seconda utilizzabile per l'avvio del servizio in automatico, una volta
che l'applicazione è terminata e pronta per essere utilizzata.
Per avviare manualmente Joseki si effettua un accesso tramite il protocollo ssh al server
ove risiede l'applicazione e tramite il comando in Fig 5.17, si manda in esecuzione il
servizio.
nohup sh /bin/rdfserver &
Fig 5.17 :Uso del comando nohup

Prima di lanciare il comando descritto in Fig 5.17 bisogna spostarsi all'interno della
cartella root di Joseki attraverso il comando cd.
Il comando in Fig 5.17 in realtà è composto da tre istruzioni distinte:

• nohup: che ha la funzione di staccare il processo dal genitore, in quanto
lavorando in ssh se non si effettua un detach del processo figlio, alla
chiusura della connessione ssh, che può avvenire intenzionalmente o
accidentalmente, il processo verrebbe terminato dato che viene
terminato il processo padre, cioè la bash creata dalla connessione ssh;

• sh ./bin/rdfserver: lancio dello script utilizzato per l'avvio di joseki;

• &: esegue il comando per l'avvio del processo in background, cioè consente di
rilasciare l'utilizzo della shell una volta avviato il processo senza aspettare la
terminazione di quest'ultimo e quindi permettere di chiudere la sessione ssh
o di svolgere altre attività.
51


Con la seconda tecnica, Joseki viene eseguito in automatico dal server e il suo
funzionamento viene garantito in qualsiasi circostanza. Questa, consiste nel modificare
il file rc.local ( mostrato in Fig 5.19 ) posizionato all'interno della directory /etc/rc.d/ in
slackware 12.1, il quale è uno script che viene eseguito automaticamente dal sistema
una volta terminata la procedura di startup, essendo uno script di sistema, per effettuare
la modifica di rc.local bisogna avere le credenziali di root.
La modifica di rc.local consiste nell'inserire alla fine dello script i comandi utilizzati per
l'avvio del server come si vede in Fig 5.18

cd /home/palma/Joseki-3.4.1
sh /home/palma/Joseki-3.4.1/bin/rdfserver &
Fig 5.18 : Modifica del file rc.local

La prima riga serve per definire l'ambiente in cui si deve eseguire lo script di avvio di
Joseki, mentre la seconda serve per avviare Joseki in modalità background come
descritto precedentemente.

#!/bin/sh

# /etc/rc.d/rc.local: Local system initialization script.
# Put any local startup commands in here. Also, if you have
# anything that needs to be run at shutdown time you can
# make an /etc/rc.d/rc.local_shutdown script and put those
# commands in there.

cd /home/palma/Joseki-3.4.1

sh /home/palma/Joseki-3.4.1/bin/rdfserver &
exit 0
Fig 5.19 : Visone del file rc.local

52


5.3 Installazione di Jena
Anche se Jena è stato sviluppato come un insieme di librerie java, è possibile far uso di
alcune utility a riga di comando descritte nel cap. 4.2.1.
Per prima cosa, bisogna scaricare l'ultima versione di Jena (nel nostro caso è la 2.6.2 ), e
poi decomprimere l'archivio,verrà creata una sotto-directory chiamata Jena-2.6.2 nella
directory di home. Per fare ciò si usa il comando :

unzip Jena-2.6.2.zip
Fig 5.20 : De-compattazione di Jena

Sempre dalla shell , si deve impostare la directory di root di Jena attraverso il comando :

export JENAROOT = ~ / Jena-2.6.2
Fig 5.21 : Set variabile d'ambiente di Jena

Infine, bisogna aggiungere i permessi di esecuzione a tutti i file presenti nella cartella :

chmod u+x $JENAROOT/bin/*
Fig 5.22 : Aggiunta permessi di Jena

E' possibile verificare il funzionamento di Jena, utilizzando l'opzione --help a una delle
utility presenti nella directory /bin,

53

Capitolo 6 Risorse RDF pubbliche

CAPITOLO 6

Risorse RDF pubbliche
In questo capitolo, vengono mostrate le maggiori basi di dati presenti nel web, come
Freebase , Dbpedia [11] , e il MERLOT [12] ( Multimedia Educational Resource for
Learning and Online Teaching ), che rendono pubblicamente disponibili le loro risorse,
utilizzando sempre un approccio al Web Semantico .

6.1 FreeBase
Freebase è una grande base di dati collaborativa, si tratta, di una raccolta online di dati
strutturati non solo in RDF, che vengono raggruppati da fonti differenti, tra cui offre il
suo contributo "wiki". Freebase mira a creare una grande e unica risorsa globale che
permette alle persone e alle macchine di accedere a informazioni, contenuti, e altro, in
modo più efficiente utilizzando l'approccio del Web Semantico. E' stato sviluppato dalla
società americana di software MetaWeb ed è entrato in esecuzione nel marzo del 2007.
Questo sistema contiene informazioni su circa 12 milioni di argomenti o Enti, ogni
nuovo argomento che viene inserito, ha un ID univoco, modo da poter gestire topic con
lo stesso nome, ma con significato diverso.
Ad ogni argomento può essere associato a uno o più tipi come ad esempio, persone,
luoghi, film ecc ecc, e ogni tipo può avere delle proprietà aggiuntive come la data di
nascita per una persona o le coordinate per un luogo. Questi tipi, le relative proprietà e i
relativi concetti vengono chiamati Schema.
Chiunque può contribuire all'inserimento di un nuovo concetto e sulla definizione di
nuove proprietà e schemi.
FreeBase provvede anche a mettere a disposizione delle API per la creazione, modifica
o miglioramento degli schemi, e queste ci permettono anche di interrogare le risorse
contenute direttamente da un interfaccia web.

54


6.1.1 Esempio di risorsa Freebase
Come è stato accennato è possibile esplorare tutte le risorse che Freebase ci offre, ed è
possibile navigare all'interno dei topic.
Sotto la voce explore Freebase, troveremo tutti gli argomenti messi a disposizione dal
sistema come si vede in Fig 6.1. Ad esempio, scegliendo l'argomento Science &
Tecnology, si aprira una lista di tutte le sotto-argomentazioni presenti.

Fig 6.1 : Esempio di Argomentazioni Freebase

Scegliendo la tipologia internet, che contiene a sua volta 40152 topic, troveremo una
breve descrizione di internet e tutti i topic vengono catalogati all'interno del tipo stesso

55


Fig 6.2 : Raggruppamento dei topic

Se scegliamo il topic website, il primo in Fig 6.3, questo contiene a sua volta 4627
topic, si nota che questi verranno visualizzati come un risultato di una query e che è
consentito fare delle operazioni direttamente via web su queste risorse, filtrando il
nome, il contenuto e la categoria degli oggetti o aggiungendo e rimuovendo proprietà
delle informazioni.


Possiamo inoltre vedere il risultato della ricerca, in formato RDF e non solo, andando
sul link in basso alla pagina come in Fig 6.4 .
56


Fig 6.4 : Scelta del formato

6.2 DBpedia
Le basi della conoscenza svolgono un ruolo sempre più importante nel migliorare
l'intelligenza del web e nel sostenere l'integrità delle informazioni. Oggi, la fonte
centrale di conoscenza sul Web e data da Wikipedia, e viene mantenuta grazie a migliaia
di contributori.
Il progetto DBpedia, sfrutta proprio questo centro di informazioni per l'estrazione di dati
strutturati e li rende disponibili sul web, utilizzando sempre un approccio al Web
Semantico. DBpedia descrive attualmente più di 3,4 milioni di cose, di cui 1,5 milioni
sono classificati in un ontologia pubblica scaricabile da sito, tra cui 312.000 persone,
413.000 posti, 94.000 album musicali, 49.000 film, 15.000 video giochi, 140.000
organizzazioni, 146.000 specie e 4.600 malattie .
Tutti i data-set di Dbpedia, sono caratterizzati da delle etichette caratteristiche , tra cui
3,2 milioni di cose classificate in 92 lingue diverse; 841.000 collegamenti a immagini e
5.081.000 link a pagine web esterne; 9.393.000 link esterni in altri data-set RDF,
565.000 categorie di Wikipedia, e 75.000 le categorie YAGO. La base di conoscenza di
tutta DBpedia consiste di oltre 1 miliardo di triple RDF, di cui 257 milioni sono stati
ricavati dalla edizione inglese di Wikipedia e 766 milioni sono stati estratti dalle
edizioni in altre lingue.

57


6.2.1 Esempio di risorsa Dbpedia
Tutte le risorse di Dbpedia vengono presentate come dati strutturati e queste possono
essere interrogate attraverso l'ausilio del linguaggio SPARQL o visualizzate attraverso il
metodo del Linked Data. Dbpedia, ci offre una piattaforma per l'interrogazione delle
risorse, ma questo non toglie che possiamo utilizzare una qualsiasi server per
l'interrogazione di dati strutturati come ad esempio Joseki.
Tutti i data-set pubblici di Dbpedia sono stati caricati in http://DBpedia.org/sparql,
mentre sotto l'indirizzo http://dbpedia.org/snorql/ è stato caricato un server generico
SPARQL per l'interrogazione delle risorse come si vede in Fig 6.5.

Fig 6.5 : Server offerto da Dbpedia

Inoltre, è possibile visualizzare il risultato delle query nel formato più opportuno
scegliendo in che modo ricevere il risultato, tutti i namespace per l'interrogazione
vengono importati automaticamente.
Un altro modo per esplorare le risorse in modo automatico, è quello di utilizzare
direttamente il nostro browser, questo approccio viene chiamato Linked Data.
Tutte le risorse sono collegate tra loro, e così un utente partendo da un iniziale fonte di
dati, si può spostare attraverso un web potenzialmente infinito di sorgenti, collegati da

58


link in RDF. Questo sistema viene utilizzato specialmente da sistemi automatici. Se ad
esempio vogliamo visualizzare le fonti di dati che esprimono il concetto “Semantic
Web”, queste vengono descritte dalla pagina http://dbpedia.org/page/Semantic_Web

Fig 6.6 : Rappresentazione della risorsa Semantic Web

Sotto le voci Property, verranno inserite rispettivamente tutte le proprietà che la risorsa
“Semantic Web” possiede, una sorta di namespace per la risorsa. Mentre in Value tutti i
valori contenuti dalla proprietà, questi valori possono essere degli attributi
( genericamente in formato testuale ) o dei riferimenti ad altre risorse, questi riferimenti,
se aperti, vengono strutturati nel modo precedentemente descritto.
Inoltre, è possibile, convertire e visualizzare la pagina della risorsa in diversi formati

Fig 6.7 : Formati di conversione della pagina

59


6.3 Merlot
Il MERLOT( Multimedia Educational Resource for Learning and Online Teaching ) è
una comunità gratuita aperta di risorse online, destinata principalmente al corpo
docente, le persone e gli studenti provenienti da tutto il mondo, per condividere tra loro
materiale di apprendimento.
L'obiettivo principale del MERLOT, è quello di migliorare l'efficacia dell'insegnamento
e dell'apprendimento, aumentandone la quantità e la qualità del peer reviewed online di
materiali didattici .
Il repository del MERLOT non è composto solamente da materiali di apprendimento,
ma anche da assegnazioni, commenti, collezioni personali e pagine Web Content
Builder, tutte progettate, per migliorare l'esperienza di insegnamento di un materiale
didattico.
Tutti le risorse sono suddivise in 14 differenti tipologie di apprendimento e una vasta
gamma di materiale è composta anche da commenti e assegnazioni. Le assegnazioni
sono progetti, documentazioni o attività che possono essere parte del corso per una
classe, queste sono legate ad un modulo di apprendimento che può riguardare solamente
l'oggetto di apprendimento o può coinvolgere altre attività.
I commenti invece sono le osservazioni individuali delle persone che hanno utilizzato
un materiale, è possibile anche valutarlo attraverso un livello di apprezzamento.

6.3.1 Esempio di risorsa MERLOT
Tutte le risorse vengo suddivise in 14 categorie, come si vede in Fig 6.8, selezionando
ad esempio la categoria Learning Object Repository, sulla destra della pagina saranno
visualizzate tutte le risorse riguardanti questa argomentazione.

60


Fig 6.8 : Categorie delle risorse

Ogni risorsa, viene catalogata attraverso un nome che la identifica, un tipo ( tutti i tipi
sono mostrati in Fig 6.8) e la data di inserimento. Se ci sono state modifiche, viene
riportata la data della modifica. Inoltre vengono visualizzati i commenti, i peer review le
personal Collection e gli esercizi riguardanti la risorsa, come mostrato in Fig 6.9 .


61

Capitolo 7 Query su risorse RDF

CAPITOLO 7

Interrogazione di risorse RDF

In questo capitolo vengono riportate tutte le query che sono state eseguite utilizzando il
server Joseki. Sono state raggruppate in 2 categorie: le query effettuate su un data-set
locale al sistema , utilizzando il server Joseki in locale, e le query fatte su data-set
presenti sul web utilizzando il server Joseki installato su una macchina remota (server
dell'università all'indirizzo 151.100.106.21 sulla porta 2020).

7.1 Query su un data-set locale
Tutte le query effettuate in questo paragrafo fanno riferimento ad un determinato data-
set, memorizzato localmente al sistema.
Il data-set viene messo a disposizione dal sito www.data.gov, dove è possibile trovare
migliaia di data-set in RDF, contenenti milioni di triple. Per i nostri esempi abbiamo
usato il dataset-1218.rdf, che fa riferimento alle ricerche tecnologiche effettuate negli
Stati Uniti.
La query mostrata in Fig 7.1 estrae tutte le proprietà che contiene il data-set; queste ci
permettono di interrogare il data-set in modo approfondito;

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xml: <http://www.w3.org/XML/1998/namespace>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#Property>
SELECT ?proprietà
FROM <file:///home/daniele/Scaricati/dataset-1218.rdf>
WHERE
{ ?proprietà rdfs:label ?x }
Fig 7.1 :Query per l'estrazione delle proprietà del data-set

62


Il risultato della query viene mostrato in Fig 7.2 in formato txt :

Fig 7.2 : Risultato della query della Fig 7.1

Se ad esempio, come nella query mostrata in Fig 7.3, preleviamo la risorsa ed il titolo
di ogni progetto ,otteniamo il risultato in formato XML, ripreso in parte in Fig 7.4 .

SELECT ?risorsa ?titolo
WHERE
{ ?risorsa
<http://www.data.gov/semantic/data/alpha/1218/dataset-1218.rdf#project_title>
?titolo . }
Fig 7.3 : Risorsa e titolo delle ricerche

63


Fig 7.4 : Risultato della query in Fig 7.3

Prendiamo ora in considerazione i progetti che devono essere sviluppati. In particolare
ci interessano il titolo , la data di sviluppo e il sito web del progetto. Per estrarre queste
informazioni dal data-set possiamo utilizzare la query riportata in Fig 7.5.

SELECT DISTINCT ?titolo ?dataSviluppo ?sitoWeb
WHERE
{
?x < http://www.data.gov/semantic/data/alpha/1218/dataset-
1218.rdf#project_title > ?titolo .
?x <http://www.data.gov/semantic/data/alpha/1218/dataset-
1218.rdf#start_date> ?dataSviluppo .
1218.rdf#site_website> ?sitoWeb .
}
Fig 7.5 : Prelevo titolo , data di sviluppo e sito del progetto

Parte del risultato nel formato XML della query mostrata in Fig 7.5 viene riportato in
Fig 7.6.

64


Fig 7.6 : Risultato query della Fig 7.5

In Fig 7.7 invece viene mostrata una query che estrae dal data-set: l'ID del progetto, il
nome dello stesso , il grado di difficoltà del progetto, e infine la data di inizio del
progetto. Il risultato viene filtrato sulla data di inizio del progetto e ordinato in ordine
ascendente per livello di difficoltà.

SELECT DISTINCT
?ID_Progetto ?Nome_Progetto ?Livello_di_Ricerca ?Data_Inizio
WHERE
{
1218.rdf#project_id> ?ID_Progetto .
1218.rdf#project_title> ?Nome_Progetto .
1218.rdf#research_type> ?Livello_di_Ricerca .
1218.rdf#start_date> ?Data_Inizio .
FILTER (?Data_Inizio >= "12/12/93")
}
ORDER BY ASC (?Livello_di_Ricerca)
Fig 7.7 : Estrazione ID, nome , Livello e data
65


Il risultato della query in Fig 7.7 viene riportato in Fig 7.8 :

Fig 7.8 : Risultato query 7.7

7.2 Query su data-set remoti
In questo paragrafo vengono riportate tutte le query che sono state eseguite su data-set
pubblici presenti sul web . Si è preferito eseguire le query su una macchina remota ,
sulla quale è stato installato il server joseki (cfr 5.2 ).
Cominciamo ad eseguire la query mostrata in Fig 7.9, dove vengono prelevate dal data-
set specificato, il nome e la data di nozze delle principesse europee , il risultato infine
viene filtrato prendendo in considerazione solamente quelle sposate prima del 1974.

66


PREFIX ged: <http://www.daml.org/2001/01/gedcom/gedcom#>
SELECT ?nome_Principessa ?data_nozze
FROM <http://www.daml.org/2001/01/gedcom/royal92.daml>
WHERE
{
?royal ged:title "Princess".
?royal ged:name ?nome_Principessa.
?royal ged:spouseIn ?family.
?family ged:marriage ?marriage.
?marriage ged:date ?data_nozze.
FILTER (?data_nozze < "1 GEN 1974").
}
Fig 7.9 : Estrazione nome e data di nozze delle principesse europee

Il risultato della query viene mostrato in Fig 7.10 :

Fig 7.10 : Risultato query in Fig 7.9

Passiamo ora, ad interrogare un nuovo data-set pubblico, che descrive la tavola
periodica degli elementi. Nella Fig 7.11 viene mostrata un query che preleva il nome , il
peso atomico , il numero ed il simbolo di tutti i gas nobili presenti sulla tavola
periodica. Il risultato, viene poi ordinato per numero dell'elemento e infine mostrato in
Fig 7.12.

67


PREFIX table: <http://www.daml.org/2003/01/periodictable/PeriodicTable#>
SELECT ?nome_elemento ?simbolo ?peso_atomico ?numero
FROM <http://www.daml.org/2003/01/periodictable/PeriodicTable.owl>
WHERE
{ ?element table:group ?group.
?group table:name "Noble gas".
?element table:name ?nome_elemento.
?element table:symbol ?simbolo.
?element table:atomicWeight ?peso_atomico.
?element table:atomicNumber ?numero.
}
ORDER BY ASC (?numero)
Fig 7.11 : Query sulla tavola periodica degli elementi

Fig 7.12 : Risultato della query mostrata nella Fig 7.12

Sempre sullo stesso data-set, eseguiamo una query che mostra il nome, il simbolo e il
peso di tutti gli elementi che hanno peso maggiore dell'uranio (Fig 7.13).

68


PREFIX table: <http://www.daml.org/2003/01/periodictable/PeriodicTable#>
SELECT ?nome_elemento ?simbolo ?peso
FROM <http://www.daml.org/2003/01/periodictable/PeriodicTable.owl>
WHERE
{
?uranium table:name "uranium".
?uranium table:atomicWeight ?peso_uranio.
?element table:name ?nome_elemento.
?element table:symbol ?simbolo.
?element table:atomicWeight ?peso.
FILTER (?peso > ?peso_uranio).
}
ORDER BY ASC (?peso)
Fig 7.13 : nome e simbolo e peso degli elementi con peso > dell'uranio

Il risultato (parziale) della query è riportato in Fig 7.14 :

Fig 7.14 : risultato query mostrata in Fig 7.13

Nella query mostrata in Fig 7.15, vengono interrogati 2 data-set; da uno prenderemo le
informazioni riguardanti la persona, in particolare il nome e l'e-mail, dall'altro estraiamo
tutte le pubblicazioni che ha effettuato nella 2003 Dublin Core conference.

69


PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?nome ?e_mail ?titolo
FROM <http://www.siderean.com/dc2003/dc2003_presentations.rdf>
FROM <http://www.siderean.com/dc2003/dc2003_agents.rdf>
WHERE
{ ?person foaf:publication ?doc.
?doc dc:title ?titolo.
?person foaf:mbox ?e_mail.
?person foaf:name ?nome.
}
Fig 7.15 : Interrogazione di 2 data-set

Ogni persona ha contribuito a una pubblicazione, immagazzinata dalla variabile ?doc ,
di conseguenza ogni ?doc avrà un ?titolo; ogni persona ha una ?e_mail e un ?nome.
Così facendo si mette in relazione il data-set contenente tutte le pubblicazioni con
quello che contiene tutti gli agenti della dc (Dublin Core Metadata Initiative).
Il risultato della query e' mostrato in Fig 7.16 :

Fig 7.16 : Risultato delle query in Fig 7.15

70


Nelle query svolte fino ad ora, sono state usate in diverse occasioni, alcuni standard,
come VCARD, DC ( Dublin Core ) [10] e FOAF ( Friend of a Friend ). Questi standard,
vengono ripresi e commentati nell'Appendice B dell'elaborato.
E' possibile interrogare questi standard, attraverso delle query, per prelevarne tutte le
proprietà di cui sono composti.
In Fig 7.17,viene mostrata la query per estrarre tutte le proprietà che compongono lo
standard DC :

SELECT ?proprietà
FROM <http://dublincore.org/2008/01/14/dcelements.rdf>
WHERE
{ ?x rdfs:label ?proprietà }
Fig 7.17 : Estrazione proprietà DC

In Fig 7.18, vengono riportate dunque tutte le proprietà che fanno parte dello standard
DC , utilizzato per descrivere in RDF un documento sul Web :

Fig 7.18 : Proprietà DC

71


Provvederemo ora, in Fig 7.19, all'estrazione di tutte le proprietà dello standard
VCARD, utilizzato per descrivere in RDF, tutte le caratteristiche e le generalità di una
persona :

SELECT ?proprietà
FROM <http://www.w3.org/2006/vcard/ns>
WHERE
{ ?x rdfs:label ?proprietà }
Fig 7.19 : Estrazione proprietà VCARD

Parte del risultato della query, mostrata in Fig 7.19, sarà riprodotta in Fig 7.20 :

Fig 7.20 : Proprietà standard VCARD

72

Capitolo 8 Conclusione e sviluppi futuri

CAPITOLO 8

Conclusione e sviluppi futuri
Nei capitoli precedenti, è stato presentato un server web, Joseki, che ci permette di
effettuare le interrogazioni, mediante l'ausilio di SPARQL, su risorse sviluppate in RDF
e non solo.
Come abbiamo visto, nella parte di installazione in remoto, si è riscontrato il problema
riguardante il troncamento prematuro del servizio, una volta che si chiudeva la sessione
o il terminale. Questo problema è stato risolto, in un primo momento attraverso l'uso del
comando nohup e poi modificando il file dei servizi in esecuzione rc.local, di modo che
il server Joseki parta come servizio di base sul server remoto.
E' stato trattato inoltre, il Resource Description Framework ( RDF ): modello e sintassi
utilizzati, oltre a RDF schema.
Sul server sono state effettuate alcune query nel linguaggio di interrogazione per meta-
dati SPARQL.
Sono stati descritti alcuni repository online, che rendono le loro risorse pubbliche e che
sfruttano i concetti del Web Semantico, oltre al vocabolario DC che permette di
identificare le proprieta' dei documenti per estrarre le informazioni desiderate. Tali
repository non esauriscono le risorse disponibili sul web: e' infatti plausibile pensare di
creare ulteriori repository, o recuperare ulteriori risorse secondo le necessita' di ricerca e
di documentazione specialistiche. Tuttavia il sistema messo in piedi durante la tesi
(SPARQL+Joseki) consente l'interrogazione anche di queste nuove risorse, qualora
dovessero essere rese pubbliche e/o accessibili.

73

Appendice A conf-joseki.ttl

Appendice A : conf-joseki.ttl

In questo appendice, viene mostrato il file di configurazione che è stato utilizzato per
l'avvio di joseki, tale file è presente all'interno della distribuzione di joseki installata.
Tutti i # indicano una parte di commento.

# This file is written in N3 / Turtle

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix module: <http://joseki.org/2003/06/module#>.
@prefix joseki: <http://joseki.org/2005/06/configuration#>.
@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#>.
## --------------------------------------------------------------
## This file is written in N3 / Turtle
## It is an RDF graph - order of RDF triples does not matter
## to the machine but it does help people who need to edit this file.

## Note: web.xml must be in-step with this file.
## for each service,

## Note: adding rdfs:label to blank nodes will cause Joseki
## to print that in log messages.
## --------------------------------------------------------------
## About this configuration
<> rdfs:label "Joseki Configuration File" .
## --------------------------------------------------------------
## About this server
<#server> rdf:type joseki:Server ;
# Example of some initialization code.
joseki:initialization
[ module:implementation

74


[ module:className <java:org.joseki.util.ServiceInitSimple> ;
rdfs:label "Example initializer" ; ]
];
.
## --------------------------------------------------------------
## Services
## Services are the points that request are sent to.
## serviceRef that will be used to match requests to services,
## not some resource URI for the description.
## Note that the service reference and the routing of incoming
## requests by URI as defined by web.xml have to align.

# Service 1
# General purpose SPARQL processor, no dataset, expects the
# request to specify the dataset (either by parameters in the
# protocol request or in the query itself).

<#service1>
rdfs:label "service point" ;
joseki:serviceRef "sparql" ; # web.xml must route this name to Joseki
joseki:processor joseki:ProcessorSPARQL ;
.

# Service 2 - SPARQL processor only handling a given dataset
<#service2>
rdf:type oseki:Service ;
rdfs:label "SPARQL on the books model" ;
joseki:serviceRef "books" ; # web.xml must route this name to Joseki
# dataset part
joseki:dataset <#books> ;

75


# Service part.
# This processor will not allow either the protocol,
# nor the query, to specify the dataset.

joseki:processor joseki:ProcessorSPARQL_FixedDS ;
.

## ---- SPARQL/Update
## A pair of services - one for SPARQL queries, one for SPARQL/Update
## Previous web.xml must also be updated to include a defintion for the
## servlet "SPARQL/Update service processor" and update requests must
## be routed to this servlet.
## <#serviceUpdate>
## rdf:type joseki:Service ;
## rdfs:label "SPARQL/Update" ;
## joseki:serviceRef "update/service" ;
## # dataset part
## joseki:dataset <#mem>;
## # Service part.
## # This processor will not allow either the protocol,
## # nor the query, to specify the dataset.
## joseki:processor joseki:ProcessorSPARQLUpdate
## .
## <#serviceRead>
## rdf:type joseki:Service ;
## rdfs:label "SPARQL" ;
## joseki:serviceRef "sparql/read" ;
## # dataset part
## joseki:dataset <#mem> ; ## Same dataset
## # Service part.
## # This processor will not allow either the protocol,

76


## # nor the query, to specify the dataset.
## joseki:processor joseki:ProcessorSPARQL_FixedDS ;
## .
## --------------------------------------------------------------
## Datasets
<#books> rdf:type ja:RDFDataset ;
rdfs:label "Books" ;
ja:defaultGraph
[ rdfs:label "books.n3" ;
a ja:MemoryModel ;
ja:content [ja:externalContent <file:Data/books.n3> ] ;
];
.
<#mem> rdf:type ja:RDFDataset ;
rdfs:label "MEM" ;
ja:defaultGraph [ a ja:MemoryModel ] ;
.
## --------------------------------------------------------------

## Processors

joseki:ProcessorSPARQL
rdfs:label "General SPARQL processor" ;

# Parameters - this processor processes FROM/FROM NAMED
joseki:allowExplicitDataset "true"^^xsd:boolean ;
joseki:allowWebLoading "true"^^xsd:boolean ;
## And has no locking policy (it loads data each time).
## The default is mutex (one request at a time)

77


joseki:lockingPolicy joseki:lockingPolicyNone ;
.

joseki:ProcessorSPARQL_FixedDS
rdfs:label "SPARQL processor for fixed datasets" ;

# This processor does not accept queries with FROM/FROM NAMED

joseki:allowExplicitDataset "false"^^xsd:boolean ;
joseki:allowWebLoading "false"^^xsd:boolean ;
.

joseki:ProcessorSPARQLUpdate
rdfs:label "SPARQL Update processor" ;
module:implementation joseki:ImplSPARQLUpdate ;
.

joseki:ImplSPARQL
rdf:type joseki:ServiceImpl ;
module:className
<java:org.joseki.processors.SPARQL> .

joseki:ImplSPARQLUpdate
rdf:type joseki:ServiceImpl ;
module:className
<java:org.joseki.processors.SPARQLUpdate> .
# Local Variables:
# tab-width: 4
# indent-tabs-mode: nil
78

Appendice B VCARD & FOAF

Appendice B : VCARD e FOAF

Nel capitolo 7, vengono eseguite delle query su risorse pubbliche e sono state utilizzate
alcune proprietà, queste, vengono messe a disposizione da alcuni standard come
VCARD e FOAF ( Friends of a Friends ), di seguito verranno mostrate le maggiori
proprietà che compongono questi due standard.

VCARD, definisce uno standard per descrivere un individuo, le proprietà più importanti
presenti all'interno di questo standard sono :

● FN : Full Name, definisce il nome completo dell'individuo

● N : Name, solo il nome della persona.

● NICKNAME : soprannome della persona.

● PHOTO: viene memorizzata un url che fa riferimento alla foto dell'individuo.

● BDAY : definisce il giorno del compleanno della persona.

● ADR : è l indirizzo dell'individuo.

● LABEL : un etichetta che può essere assegnata all'individuo.

● TEL : viene memorizzato il numero di telefono

● EMAIL : l'email della persona.

● GEO : è composto da 2 numeri, rispettivamente la longitudine e latitudine in cui
si trova la persona.

● TITLE : si riferisce al titolo di studio della persona

● ROLE : il ruolo che la persona ha nella società o in particolare nel lavoro

● ORG : organizzazione dove l'individuo lavora

● CATEGORIES : è la categoria del lavoro intrapreso dalla persona

● NOTE : le possibili note che descrivono la persona

● URL : un indirizzo web di riferimento

79


FOAF è un'ontologia comprensibile dal computer atta a descrivere persone, con le loro
attività e le relazioni con altre persone e oggetti. Chiunque può usare FOAF per
descriversi. FOAF permette a gruppi di persone di descrivere quel fenomeno noto come
social network senza la necessità di un database centralizzato.
Tutte le proprietà di FOAF vengono raggruppate in 5 categorie, la categoria di base
(Fig B1), la categoria per le informazioni personali ( Fig B2 ), la categoria sugli account
online ( Fig B3 ), la categoria dei progetti e gruppi ( Fig B4 ) e infine la categoria dei
progetti e delle immagini (Fig B5)

Fig B.1 Fig B.2

Fig B.3 Fig B.5
80


Fig B.4

81

Sitografia

Sitografia :

[1] SPARQL Query Language for RDF,
in : http://www.w3.org/TR/rdf-sparql-query/

[2] Jena – A Semantic Web Framework for Java,
in :http://jena.sourceforge.net/

[3] Documentazione di Jena,,
in :http://jena.sourceforge.net/documentation.html

[4] Joseki - a SPARQL Server for Jena,
in :http://www.joseki.org/

[5] Turtle - Terse RDF Triple Language,
in :http://www.w3.org/TeamSubmission/turtle/

[6] Tim Berners-Lee , Notation 3,
in : http://www.w3.org/DesignIssues/Notation3

[7] Extensible Markup Language (XML),
in : http://www.w3.org/XML/

[8] Namespaces in XML 1.0,
in : http://www.w3.org/TR/REC-xml-names/

[9] URIs, URLs, and URNs: Clarifications and Recommendations,
in : http://www.w3.org/TR/uri-clarification/

[10] Dublin Core Metadata Element Set,
in : http://dublincore.org/documents/dces/

82

Sitografia

[11] Dbpedia,
in : http://wiki.dbpedia.org/About

[12] MERLOT,
in : http://www.merlot.org/merlot/index.htm

[13] vCard ,
in : http://en.wikipedia.org/wiki/VCard

[14] Resource Description Framework (RDF),
in : http://www.w3.org/RDF/

[15] W3C , Semantic Web Activity,
in : http://www.w3.org/2001/sw/

[16] W3C , RDF/XML Syntax Specification,
in : http://www.w3.org/TR/rdf-syntax-grammar/

[17] Semantic Web History,
in : http://www.w3.org/1999/11/11-WWWProposal/

[18] W3C, RDF Vocabulary Description Language 1.0: RDF Schema,
in : http://www.w3.org/TR/rdf-schema/

[19] Resource Description Framework (RDF): Concepts and Abstract Syntax
in : http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/

[20] RDF Semantics ,
in : http://www.w3.org/TR/2004/REC-rdf-mt-20040210/

[21] Tim Berners-Lee, Primer: Getting into RDF & Semantic Web using N3
in : http://www.w3.org/2000/10/swap/Primer.html

83

Sitografia

[22] SPARQL Protocol for RDF ,
in : http://www.w3.org/TR/rdf-sparql-protocol/

84

Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web (20)

Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web