università di pisa tesi di laurea magistrale · introduzione 1 1 rdf, sparql e owl 3 ... rdf model...
TRANSCRIPT
Università di Pisa
Tesi di Laurea Magistrale
Un sistema di tipi per SPARQL
Candidato Relatore
Nicola Guido Giorgio Ghelli
Aprile 15, 2011
Indice
Introduzione 1
1 RDF, SPARQL e OWL 3
1.1 Resource Description Framework . . . . . . . . . . . . . . . . 3
1.1.1 RDF Data Model . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 RDF Schema . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Ontology Web Language . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Pro�li OWL2 . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Assunzione OWA . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Sintassi OWL2 . . . . . . . . . . . . . . . . . . . . . . 13
1.2.4 Semantica diretta . . . . . . . . . . . . . . . . . . . . . 17
1.3 SPARQL Protocol and RDF Query Language . . . . . . . . . 18
1.3.1 Convenzioni . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 Introduzione al linguaggio SPARQL . . . . . . . . . . . 19
1.3.3 Graph Pattern . . . . . . . . . . . . . . . . . . . . . . 24
1.3.4 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3.5 Modi�catori di soluzione . . . . . . . . . . . . . . . . . 31
1.3.6 Forme del risultato . . . . . . . . . . . . . . . . . . . . 32
1.3.7 Introduzione alla versione 1.1 . . . . . . . . . . . . . . 33
2 Sintassi e semantica di SPARQL 35
2.1 Sintassi di Sparql . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.1 Sintassi tipi di query . . . . . . . . . . . . . . . . . . . 36
2.1.2 Sintassi dataset . . . . . . . . . . . . . . . . . . . . . . 38
2.1.3 Sintassi variabili, graphTerm e triple pattern . . . . . . 39
2.1.4 Sintassi graph pattern . . . . . . . . . . . . . . . . . . 40
2.1.5 Sintassi value constraint . . . . . . . . . . . . . . . . . 40
i
INDICE ii
2.2 Semantica di SPARQL . . . . . . . . . . . . . . . . . . . . . . 42
2.2.1 Semantica SelectQuery . . . . . . . . . . . . . . . . . . 43
2.2.2 Semantica SelectClause . . . . . . . . . . . . . . . . . . 44
2.2.3 Semantica ConstructQuery . . . . . . . . . . . . . . . . 44
2.2.4 Semantica ConstructClause . . . . . . . . . . . . . . . 45
2.2.5 Semantica ConstructTemplate . . . . . . . . . . . . . . 45
2.2.6 Semantica AskQuery . . . . . . . . . . . . . . . . . . . 47
2.2.7 Semantica DatasetClause . . . . . . . . . . . . . . . . . 47
2.2.8 Semantica Triple . . . . . . . . . . . . . . . . . . . . . 48
2.2.9 Semantica VarOrGterm . . . . . . . . . . . . . . . . . 50
2.2.10 Semantica WhereClause . . . . . . . . . . . . . . . . . 51
2.2.11 Semantica Graph Pattern . . . . . . . . . . . . . . . . 51
2.2.12 Semantica ValueC . . . . . . . . . . . . . . . . . . . . . 52
3 Sistema di tipi 54
3.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2 Requisiti del sistema di tipi . . . . . . . . . . . . . . . . . . . 56
3.3 Il sistema dei tipi: ambiente delle informazioni di tipo . . . . . 63
3.4 Sintassi e semantica dei tipi . . . . . . . . . . . . . . . . . . . 66
3.4.1 Semantica di un tipo nodo TN . . . . . . . . . . . . . . 67
3.4.2 Semantica di un tipo grafo TG . . . . . . . . . . . . . 69
3.4.3 Semantica di un tipo relazione TR . . . . . . . . . . . 70
3.4.4 Semantica di un tipo ambiente dei named graph NG . 76
3.5 Judgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.5.1 Judgment SPARQL . . . . . . . . . . . . . . . . . . . . 77
3.6 Regole di tipi . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.6.1 Funzioni ausiliari . . . . . . . . . . . . . . . . . . . . . 79
3.6.2 Regole SelectQuery . . . . . . . . . . . . . . . . . . . . 79
3.6.3 Regole SelectClause . . . . . . . . . . . . . . . . . . . . 80
3.6.4 Regole ConstructQuery . . . . . . . . . . . . . . . . . . 80
3.6.5 Regole ConstructClause . . . . . . . . . . . . . . . . . 80
3.6.6 Regole ConstructTemplate . . . . . . . . . . . . . . . . 81
3.6.7 Regole AskQuery . . . . . . . . . . . . . . . . . . . . . 83
3.6.8 Regole DatasetClause . . . . . . . . . . . . . . . . . . . 83
INDICE iii
3.6.9 Regole Triple . . . . . . . . . . . . . . . . . . . . . . . 84
3.6.10 Regole VarOrGTerm . . . . . . . . . . . . . . . . . . . 85
3.6.11 Regole WhereClause . . . . . . . . . . . . . . . . . . . 86
3.6.12 Regole Graph Pattern . . . . . . . . . . . . . . . . . . 86
3.6.13 Regole ValueC . . . . . . . . . . . . . . . . . . . . . . . 89
4 Proprietà di soundness 91
4.1 Note preliminari . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.2 Dimostrazione proprietà di soundness . . . . . . . . . . . . . . 99
4.2.1 Dimostrazione soundness SelectQuery . . . . . . . . . . 99
4.2.2 Dimostrazione soundness SelectClause . . . . . . . . . 101
4.2.3 Dimostrazione soundness ConstructQuery . . . . . . . 102
4.2.4 Dimostrazione soundness ConstructClause . . . . . . . 103
4.2.5 Dimostrazione soundness ConstructTemplate . . . . . . 103
4.2.6 Dimostrazione soundness AskQuery . . . . . . . . . . . 107
4.2.7 Dimostrazione soundness DatasetClause . . . . . . . . 108
4.2.8 Dimostrazione soundness Triple . . . . . . . . . . . . . 111
4.2.9 Dimostrazione soundness VarOrGTerm . . . . . . . . . 116
4.2.10 Dimostrazione soundness WhereClause . . . . . . . . . 118
4.2.11 Dimostrazione soundness Graph Pattern . . . . . . . . 118
4.2.12 Dimostrazione soundness valueC . . . . . . . . . . . . . 126
5 Implementazione del type checker 129
5.1 Il linguaggio di programmazione . . . . . . . . . . . . . . . . . 129
5.2 Query SPARQL in JAVA . . . . . . . . . . . . . . . . . . . . . 130
5.2.1 Tipi di Query . . . . . . . . . . . . . . . . . . . . . . . 130
5.2.2 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.2.3 Variabili, graphTerm e triple pattern . . . . . . . . . . 131
5.2.4 Graph Pattern . . . . . . . . . . . . . . . . . . . . . . 132
5.2.5 Value Constraint . . . . . . . . . . . . . . . . . . . . . 133
5.2.6 Parser SPARQL . . . . . . . . . . . . . . . . . . . . . . 133
5.3 Tipi de�niti in JAVA . . . . . . . . . . . . . . . . . . . . . . . 135
5.4 ELO schema in JAVA . . . . . . . . . . . . . . . . . . . . . . . 136
5.4.1 Parser ELO schema . . . . . . . . . . . . . . . . . . . . 139
INDICE iv
5.5 Funzioni ausiliari . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.6 Implementazione regole di tipo . . . . . . . . . . . . . . . . . . 141
6 Conclusioni 143
6.1 Obiettivi a breve/medio termine . . . . . . . . . . . . . . . . . 144
6.2 Obiettivi a lungo termine . . . . . . . . . . . . . . . . . . . . . 145
Bibliogra�a 146
Elenco delle �gure
1.1 Statement RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Esempio di grafo RDF . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Nodo blank per modellare l'indirizzo dell'impiegato 1234 . . . 6
1.4 Esempio RDF Collection . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Esecuzione di una query con named graph . . . . . . . . . . . 30
3.1 Grafo RDF contenente informazioni su giocatori di calcio . . . 56
3.2 Vincoli di disgiunzione e di sottoclasse . . . . . . . . . . . . . 60
5.1 Modellazione tipi di query SPARQL in JAVA . . . . . . . . . 130
5.2 Modellazione GraphTerm in JAVA . . . . . . . . . . . . . . . 131
5.3 Modellazione Graph Pattern in JAVA . . . . . . . . . . . . . . 132
5.4 Modellazione ValueC in JAVA . . . . . . . . . . . . . . . . . . 133
5.5 Grafo RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
v
Elenco delle tabelle
1.1 Tabella Libri - Documenti . . . . . . . . . . . . . . . . . . . . 13
1.2 Operatori SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3 Funzioni accessorie SPARQL . . . . . . . . . . . . . . . . . . . . 26
1.4 Forme sintattiche per i path di proprietà . . . . . . . . . . . . 34
2.1 Sintassi tipi di query . . . . . . . . . . . . . . . . . . . . . . . 36
2.2 Sintassi query select . . . . . . . . . . . . . . . . . . . . . . 37
2.3 Sintassi query construct . . . . . . . . . . . . . . . . . . . . 37
2.4 Sintassi query ask . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5 Sintassi DatasetClause . . . . . . . . . . . . . . . . . . . . . . 38
2.6 Sintassi variabili, graphTerm e triple pattern . . . . . . . . . . 39
2.7 Sintassi graph patterns . . . . . . . . . . . . . . . . . . . . . . 40
2.8 Sintassi value constraints . . . . . . . . . . . . . . . . . . . . . 40
2.9 Sintassi sempli�cata di SPARQL . . . . . . . . . . . . . . . . . . 41
2.10 De�nizione tabellare della funione f . . . . . . . . . . . . . . . 46
2.11 Esempio grafo RDF . . . . . . . . . . . . . . . . . . . . . . . . 49
2.12 Valutazione della prima componente della tripla ?x . . . . . . 49
2.13 Valutazione della seconda componente della tripla dc:creator . 49
2.14 Valutazione della terza componente della tripla ?nome . . . . 49
2.15 Join delle tre relazioni . . . . . . . . . . . . . . . . . . . . . . 50
3.1 Sintassi ELO schema . . . . . . . . . . . . . . . . . . . . . . . 63
3.2 Esempio di ambiente delle costanti tipizzate . . . . . . . . . . 65
3.3 Sintassi dei tipi . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.4 De�nizione dell'operazione di unione tra σ1 ∪ σ2 . . . . . . . . 71
3.5 De�nizione dell'operazione tra σ1 ∩ σ2 . . . . . . . . . . . . . 73
5.1 Grammatica graph pattern . . . . . . . . . . . . . . . . . . . . 132
vi
ELENCO DELLE TABELLE vii
5.2 Grammatica concreta SPARQL . . . . . . . . . . . . . . . . . 134
5.3 Sintassi dei tipi . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.4 Grammatica per gli ELO schema . . . . . . . . . . . . . . . . 139
Elenco delle Query
3.1 AnyGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2 Rdfs:domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3 Rdfs:range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4 Rdfs:range and Rdfs:domain . . . . . . . . . . . . . . . . . . . . 58
3.5 Value constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.6 DisjointClasses and SubClassOf . . . . . . . . . . . . . . . . . . . 61
3.7 DisjointClasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.8 VarOrGTerm error . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.9 Soggetto No Error 1 . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.10 Soggetto No Error 2 . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.11 Predicato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.12 Rdfs:range and Rdfs:domain . . . . . . . . . . . . . . . . . . . . 145
viii
Introduzione
L'idea del web semantico nasce dalla necessità di estendere l'attuale web
in modo da favorire lo scambio di informazioni tra le persone ed applicazio-
ni. A�nchè le informazioni siano comprensibili alle macchine devono essere
a�ancate da informazioni aggiuntive, i cosiddetti �metadati�. Un classico
esempio di metadati può essere lo schema di una tabella, in cui le informazioni
rappresentano i record e i metadati i nomi dei campi.
Un formalismo per esprimere i metadati è il Resource Description Fra-
mework (RDF), uno standard proposto dal W3C. Questo framework mette a
disposizione una notazione per descrivere entità (chiamate risorse) e i legami
che intercorrono fra di esse .
Contestualmente al rilascio di RDF è sorto il problema dell'interroga-
zione delle informazioni espresse in questo formalismo. Sono stati proposti
diversi linguaggi di interrogazione tra cui SPARQL, uno standard W3C. Ta-
le linguaggio permette di esprimere pattern che verranno confrontati con un
insieme di dati RDF. I confronti positivi, match, sono elaborati e restituiti
come soluzione.
Obiettivo della tesi è la de�nizione di un sistema di tipi per SPARQL, con
successiva implementazione di un type checker per il linguaggio. SPARQL è
un linguaggio ancora in fase di sviluppo e la scarsa presenza in letteratura
di studi inerenti la sua analisi statica dei tipi, sono stati motivi guida per lo
sviluppo di questo lavoro.
Strutturazione dei capitoli
I capitoli che compongono questa tesi sono i seguenti:
1
INTRODUZIONE 2
Capitolo 1 - RDF, OWL e SPARQL
Vengono introdotti i linguaggi RDF, OWL e SPARQL, mediante esempi.
Capitolo 2 - Sintassi e semantica di SPARQL
Viene presentata la sintassi di SPARQL e viene proposta una sua seman-
tica formale.
Capitolo 3 - Sistema di tipi
Viene introdotto il sistema dei tipi seguendo il seguente schema:
1. de�nizione dell'ambiente dei tipi
2. de�nizione della sintassi dei tipi
3. de�nizione dei giudizi (judgments)
4. de�nizione delle regole di inferenza
Capitolo 4 - Proprietà di soundness
Viene de�nita la semantica dei giudizi e dimostrata la proprietà di sound-
ness del sistema dei tipi rispetto a tale semantica.
Capitolo 5 - Implementazione del type checker
Vengono sintetizzate le fasi di implementazione del type checker. Vengono
descritti gli algoritmi e le strutture dati adottate.
Capitolo 6 - Conclusioni
Vengono descritti i risultati raggiunti con questa tesi ed elencati i possibili
sviluppi futuri nell'ambito del lavoro svolto
Capitolo 1
RDF, SPARQL e OWL
Il seguente capitolo espone i concetti base necessari alla comprensione del
lavoro svolto attraverso la presentazione dei linguaggi: RDF, OWL e SPARQL.
Di quest'ultimo linguaggio verrà approfondita la versione standard 1.0 pre-
sentando solo le proposte principali della versione 1.1. Del linguaggio OWL
verrà presentato un insieme ristretto dei costrutti dell'update OWL2.
1.1 Resource Description Framework
Resource Description Framework (RDF) è lo strumento base per la codi�ca,
lo scambio e il riutilizzo di metadati strutturati, e consente l'interoperabilità
tra applicazioni che si scambiano sul Web informazioni processabili.
RDF non descrive la semantica delle informazioni, ma fornisce una base
comune per poterla esprimere, permettendo di de�nire la semantica dei tag
XML.
RDF è costituito da due componenti:
� RDF Model and Syntax, che de�nisce il data model RDF e la sua codi�ca
XML;
� RDF Schema, che permette di de�nire speci�ci vocabolari per i metadati.
3
CAPITOLO 1. RDF, SPARQL E OWL 4
1.1.1 RDF Data Model
Il data model RDF, che consente di rappresentare in un modo univoco
informazioni RDF, è molto semplice ed è basato su tre tipi di oggetti: risorse,
proprietà e statement.
Risorse : qualsiasi cosa descritta da un'espressione RDF viene detta risorsa
(resource). Una risorsa può essere una pagina Web, una parte di essa,
un elemento XML all'interno di un documento sorgente. Una risorsa
può anche essere un'intera collezione di pagine web, od un oggetto non
direttamente accessibile via Web, come un libro o un dipinto. Le risorse
sono sempre identi�cate da un Uniform Resource Identi�er (URI).
Proprietà : una caratteristica, un attributo, o una relazione utilizzata per
descrivere una risorsa. Ogni proprietà ha un signi�cato speci�co, de-
�nisce i valori ammissibili, i tipi di risorse che può descrivere, e le sue
relazioni con altre proprietà. Le proprietà associate alle risorse sono
identi�cate da un nome e possono assumere dei valori.
Statements : Una risorsa con una proprietà con un valore de�nito costitui-
sce un RDF statement. Uno statement è quindi una tripla composta da
un soggetto (risorsa RDF), un predicato (proprietà) e un oggetto (risor-
sa RDF). L'oggetto di uno statement, ovvero il valore di una proprietà,
può essere un'espressione (sequenza di carattere o tipo primitivo XML)
oppure essere esso stesso un'altra risorsa.
Figura 1.1: Statement RDF
CAPITOLO 1. RDF, SPARQL E OWL 5
Grafo RDF
Generalmente le relazioni tra risorse, proprietà e valori vengono rappre-
sentate mediante gra� etichettati orientati, in cui le risorse corrispondono
ai nodi del grafo e le proprietà ad archi orientati dal nodo soggetto al nodo
oggetto, come mostrato in �gura 1.2.
Figura 1.2: Esempio di grafo RDF
Un insieme di proprietà che fanno riferimento alla stessa risorsa viene
detto descrizione.
Indichiamo con il termine vocabolario di un grafo l'insieme di tutti i
termini che compaiono come soggetti, proprietà e oggetti nelle sue triple.
I tipi di risorse possono essere:
� Uniform Resource Identi�er o URI references
� Literal, stringhe utilizzate come oggetto
� Blank Node
CAPITOLO 1. RDF, SPARQL E OWL 6
UnURI reference è un URI con un fragment identi�er opzionale alla �ne.
Nella stringa <http://www.example.org/index.html#section2> il fragment
identi�er è separato dall'URI dal carattere speciale �#�.
URIs
<http://www.w3schools.com/rdf><http://www.mp3.it/cd/Pearl Day>
I literal si classi�cano in plain literal, porzioni di testo con tag di lin-
guaggio opzionale e typed literal. Un plain literal senza il tag di linguaggio
è chiamato simple literal ; i typed literal invece sono stringhe abbinate ad un
datatype identi�cato da una URI. Il datatype dà un informazione aggiuntiva
sul tipo del dato contenuto nella stringa.
Plain Typed
�Alice� �27�^^xsd:integer�cat�@en �1999-08-16�^^xsd:date
I blank nodes, generalmente indicati dall'etichetta �_:� seguita da un
nome, sono utilizzabili come soggetto o oggetto. Modellano risorse che non
si è interessati ad identi�care, come per esempio gli attributi multivalore nel
modello relazione. Pensiamo all'esempio classico di un indirizzo civico di una
persona.
Figura 1.3: Nodo blank per modellare l'indirizzo dell'impiegato 1234
CAPITOLO 1. RDF, SPARQL E OWL 7
RDF Containers, RDF Collection
Spesso può essere necessario modellare insiemi di risorse. Pensiamo per
esempio ad un insieme di server ftp che possiedono un software: vorremmo
poter esprimere il fatto che un software è scaricabile da uno di questi ser-
ver e vorremmo poter ordinare i server secondo una certa priorità. Questo
problema non può essere risolto utilizzando semplicemente dei nodi blank in
quanto non ci permettono di esprimere le proprietà di ordine o esclusività
degli elementi dell'insieme.
In RDF modelliamo gli insiemi con delle risorse chiamate Container. Gli
elementi dell'insieme sono risorse o literal e sono chiamati membri. I contai-
ner possono essere di tre tipi:
� rdf:Bag, insieme più generico. Può contenere dei membri duplicati e il
loro ordine non è importante;
� rdf:Seq, insieme in cui i membri seguono un preciso ordine alfabetico,
numerico o temporale. E' possibile avere membri duplicati;
� rdf:Alt, insieme i cui membri sono esclusivi tra loro.
I membri di un insieme possono essere dichiarati in qualsiasi parte del
documento RDF che contiene il grafo. Un'applicazione può correttamente ag-
giungere elementi a uno stesso insieme in momenti di�erenti. Possiamo quindi
vedere il container come un insieme aperto. Da un certo punto di vista que-
sto potrebbe essere un problema, perchè in certi casi si vuole �chiudere� un
insieme e decidere una volta per tutte i soli e unici membri di esso. Per fare
questo l'RDF mette a disposizione un particolare container chiamato Collec-
tion: una lista gestita con le proprietà rdf:first, rdf:rest, rdf:nil che
indicano rispettivamente il primo elemento della lista, l'elemento successivo
e la �ne della lista, vincolando così gli elementi della stessa. RDF Collection
è spesso usato per descrivere gruppi di oggetti: per esempio i diversi autori
di un libro, o gli studenti che frequentano un corso.
In �gura 1.4 è mostrato un insieme di quattro studenti per il corso 6.001
CAPITOLO 1. RDF, SPARQL E OWL 8
Figura 1.4: Esempio RDF Collection
Una sintassi XML per RDF: RDF/XML
Un grafo RDF è comprensibile all'uomo, ma non alle macchine. La seria-
lizzazione è quel processo che permette al dato RDF di essere esportato. Il
documento [2] mostra in che modo ogni elemento RDF viene tradotto in XML.
Di seguito è mostrato il frammento RDF/XML per la Collection in �gura 1.4.
<?xml version=" 1 .0 "?>
<rdf:RDF xmlns : rd f=" ht tp : //www.w3 . org /1999/02/22− rdf−syntax−ns#"xmlns : s=" ht tp : // example . org / s tudents /vocab#">
<rd f :D e s c r i p t i o n rd f : abou t=" ht tp : // example . org / cour s e s /6 .001 ">
<s : s t ud en t s rd f :parseType=" Co l l e c t i on ">
<rd f :D e s c r i p t i o n rd f : abou t=" ht tp : // example . org / s tudents /Amy"/>
<rd f :D e s c r i p t i o n rd f : abou t=" ht tp : // example . org / s tudents /Mohamed"/>
<rd f :D e s c r i p t i o n rd f : abou t=" ht tp : // example . org / s tudents /Johann"/>
</ s : s t ud en t s>
</ rd f :D e s c r i p t i o n>
</rdf:RDF>
CAPITOLO 1. RDF, SPARQL E OWL 9
L'elemento <rdf:RDF> racchiude la de�nizione dello statement RDF ed al
suo interno troviamo la de�nizione di due namespace. I namespace XML sono
usati in quanto essi forniscono un metodo per identi�care senza ambiguità la
semantica e le convenzioni che disciplinano l'utilizzo di proprietà all'interno
di Authority (come ad esempio la Dublin Core) che ne gestisce il vocabolario.
1.1.2 RDF Schema
Le speci�che di RDF includono un insieme di URI riservate (vocabolario
con semantica prede�nita) RDF Schema o RDFS[8]. RDFS non pone dei vincoli
al grafo RDF ma fornisce informazioni aggiuntive sulla semantica di esso. RDF
Schema è un type system per l'RDF ed è alla base di ontologie che risulta-
no essere più espressive come OWL. RDF Schema permette di de�nire classi
e proprietà con dominio e codominio, dove classi e proprietà sono risorse
rdfs:Resource.
Classi
Il concetto di classe è simile a quello di classe nel modello object-oriented.
Una classe è una risorsa che ha tipo rdfs:Class. Lo statement:
ex:MotorVehicle rdf:type rdfs:Class.
indica che ex:MotorVehicle è una classe e che tutte le risorse che avranno
come tipo ex:MotorVehicle saranno istanze delle classe ex:MotorVehicle
a sua volta istanza della classe rdfs:Class.
ex è il pre�sso che sta per http://www.example.org/schemas/vehicles e
identi�ca questa URI nello schema; rdf:type è la proprietà che indica che
una risorsa, soggetto della tripla, è istanza di una classe. É possibile de�nire
una sottoclasse nel seguente modo:
ex:Van rdf:type rdfs:Class.
ex:Van rdfs:subClassOf ex:MotorVehicle.
La classe ex:Van è una sottoclasse di ex:MotorVehicle. Signi�ca che
un'istanza della classe ex:Van è anche un'istanza di ex:MotorVehicle. La
proprietà rdfs:subClassOf è transitiva.
CAPITOLO 1. RDF, SPARQL E OWL 10
Proprietà
Una proprietà è una caratteristica di una classe. Le proprietà sono istanze
della classe rdf:Property. Come le classi anche le proprietà possono avere
sottoproprietà.
ex:driver rdf:type rdf:Property.
ex:oldDriver rdf:type rdf:Property.
ex:oldDriver rdfs:subPropertyOf ex:driver.
È possibile de�nire, con rdfs:domain e rdfs:range, un dominio e un
codominio per una proprietà, come mostrato nell'esempio seguente:
ex:driver rdfs:domain ex:MotorVehicle.
ex:driver rdfs:range ex:Person.
Il range può anche riferirsi direttamente a un tipo XSD (XML Schema De-
�nition). Tenendo presente che speci�care il dominio e il range di una pro-
prietà è facoltativo, va anche detto che qualora venissero speci�cato non vi
sono vincoli sulla complessità della loro de�nizione. Nell'esempio sopraindi-
cato ogni elemento nel dominio della proprietà ex:driver è istanza sia della
classe ex:MotorVehicle che della classe ex:Vehicle.
ex:driver rdfs:domain ex:MotorVehicle.
ex:driver rdfs:domain ex:Vehicle.
Altre descrizioni
É possibile aggiungere un commento ad una risorsa con la proprietà
rdfs:comment oppure riferire un'altra risorsa che potrebbe avere informazioni
riguardanti essa tramite rdfs:seeAlso.
Nel web si hanno a disposizione degli schemi RDF che possono essere
utilizzati per gra� senza dover creare uno schema RDF da sè, come per
esempio:
� il Dublin Core della Dublin Core Metadata Initiative fornisce delle
proprietà per descrivere qualsiasi risorsa web;
� il Friend of a Friend Project (FOAF) fornisce delle proprietà per de-
scrivere persone, relazioni tra persone e attività;
CAPITOLO 1. RDF, SPARQL E OWL 11
1.2 Ontology Web Language
OWL è un linguaggio per de�nire e istanziare ontologie web. Ontologia
è un termine preso in prestito dalla �loso�a e si riferisce alla scienza della
descrizione del tipo di entità del mondo e delle loro correlazioni. Una onto-
logia OWL può includere descrizioni delle classi, proprietà e loro istanze. Una
volta data un'ontologia, la semantica formale di OWL speci�ca come derivare
le conseguenze logiche, ovvero i fatti che non sono presenti esplicitamente
nell'ontologia.
Un'ontologia costituisce una rappresentazione della conoscenza, non un
formato per lo scambio di informazioni. La maggior parte degli standard
Web prodotti, consiste nella combinazione di vari formati per lo scambio di
informazioni e delle speci�che dei protocolli di comunicazione. Questi formati
sono stati dotati di una semantica operazionale, del tipo: �Alla ricezione di un
messaggio di OrdinediAcquisto, trasferisci l'Ammontare in dollari dal
ContodiPartenza al ContodiDestinazione e spedisci il Prodotto.
Ma le speci�che non sono progettate per supportare alcun tipo di ragiona-
mento al di fuori del contesto della transazione. Per esempio non avremmo
in generale un meccanismo che sia in grado di concludere che, poichè il Pro-
dotto è un tipo di Chardonnay, deve anche essere necessariamente un vino
bianco.
Un vantaggio delle ontologie OWL è la disponibilità di strumenti che sono
in grado di ragionare su di esse. Gli strumenti devono fornire un generico
supporto che non deve essere speci�co del particolare dominio considera-
to. Costruire un e�ciente ed utile sistema di ragionamento non è semplice,
mentre la costruzione di un'ontologia risulta un problema trattabile.
Per poter scrivere un'ontologia che possa essere interpretata in maniera
non ambigua e utilizzata da agenti software, avremmo bisogno di una sintassi
e di una semantica formale per il linguaggio OWL. In questo lavoro trattiamo
l'update OWL2. Esso introduce, come vedremo di seguito, una nuova sintassi
più intuitiva per esprimere asserzioni OWL.
CAPITOLO 1. RDF, SPARQL E OWL 12
1.2.1 Pro�li OWL2
OWL2 introduce diversi pro�li che o�rono dei vantaggi in particolari scenari
applicativi. Sono de�niti tre pro�li di�erenti: OWL2 EL, OWL2 QL e OWL2 RL.
Ogni pro�lo è de�nito per restrizione sintattica di OWL2 [12]. Sinteticamente:
OWL2 EL supporta tutti i ragionamenti sulle asserzioni OWL in tempo polino-
miale;
OWL2 QL supporta i ragionamenti su database standard;
OWL2 RL supporta tutti i ragionamenti su triple RDF in tempo polinomiale.
OWL2 è molto simile a OWL. Molti costrutti di OWL2 sono presenti in OWL,
cambiano solo i nomi con cui sono de�niti. Tutte le ontologie OWL valide,
rimangono valide in OWL2. OWL2 aggiunge nuove funzionalità rispetto OWL.
Molti costrutti sono �zucchero sintattico�, vedi la de�nizione della disgiun-
zione tra classi, altri aggiungono espressività al linguaggio, per esempio la
possibilità di de�nire proprietà asimmetriche, ri�essive e disgiuntive.
Prima di introdurre la sintassi di OWL2 presentiamo la nozione di Open
World Assumption ai �ni della comprensione delle sottosezioni seguenti.
1.2.2 Assunzione OWA
OWL e�ettua un' assunzione di mondo aperto (OWA - Open World As-
sumption), cioè assume che la descrizione delle risorse non sia con�nata ad
un unico �le o ad un unico obiettivo. Sebbene la classe C1 sia de�nita
originariamente in un'ontologia O1, questa può essere estesa anche in altre
ontologie. Le nuove asserzioni possono solo aggiungere fatti e conseguenze
e mai cancellarli: non possono ritrattare le informazioni precedenti, possono
però cadere in contraddizione con queste. La possibilità di avere informazioni
contraddittore è un qualcosa che il progettista di ontologie deve tenere bene
in considerazione. Ci si aspetta inoltre che gli strumenti di supporto aiutino
a rilevare questi casi.
Per chiarire il concetto facciamo un esempio. Le basi di dati tradizionali
normalmente sono interpretate usando l'approccio a mondo chiuso (Closed
World Assumption, CWA) in cui si considerano vere le informazioni presenti
CAPITOLO 1. RDF, SPARQL E OWL 13
nella basi di dati e false quelle che non sono presenti. Consideriamo le due
tabelle Libri e Documenti (Tabella 1.1).
Libri
book1book2
Documenti
cd1book3cd2
book1
Tabella 1.1: Tabella Libri - Documenti
Se volessimo la lista dei documenti che sicuramente non sono dei libri
con un assunzione a mondo chiuso la soluzione sarebbe { cd1, book3, cd2},
mentre con un assunzione a mondo aperto la soluzione sarebbe vuota in
quanto sappiamo che cd1, book3 e cd2 sono dei documenti, ma non sappiamo
se sono anche dei libri.
In generale, il mondo aperto è adatto ad applicazioni nelle quali non
si possiede la conoscenza completa del dominio, mentre il mondo chiuso è
adatto ai casi in cui si vuole avere l'esatta conoscenza del dominio.
1.2.3 Sintassi OWL2
OWL2 è un linguaggio utilizzato nel Web Semantico, perciò i nomi in OWL2
sono International Resource Identi�ers IRIs. Essendo le IRIs stringhe lun-
ghe, esistono meccanismi come i namespace che permettono di de�nire una
rappresentazione abbreviata delle IRIs. In OWL2 ci sono tre nozioni di base:
Assiomi asserzioni basilari di un'ontologia OWL2;
Entità elementi utilizzati per riferire oggetti del modello reale;
Espressioni combinazione di entità per esprimere descrizioni complesse.
Una ontologia OWL2 può essere espressa in diversi modi. In questo docu-
mento consideriamo la sintassi funzionale [12] che si adatta ad essere utilizza-
ta per spe�care qualsiasi ontologia e fornisce una base per l'implementazioni
di strumenti OWL2 come APIs e ragionatori.
CAPITOLO 1. RDF, SPARQL E OWL 14
Di seguito vengono presentati i costrutti OWL2 utilizzati in questo lavoro di
tesi. Per ogni costrutto rappresentato viene mostrato un equivalente costrut-
to RDF(S). Essendo OWL2 più espressivo rispetto RDF(s), per quanto concerne
i costrutti che asseriscono �negazioni� non è presente un corrispettivo RDF(S).
Classi, Proprietà e Individui
Gli esempi mostrati di seguito non intendono essere rappresentativi della
potenza espressiva di OWL, ma sono solo una semplice esposizione di alcune
funzionalità utilizzate nel lavoro di tesi.
Introduciamo i costrutti di OWL2 rappresentando le informazioni relative
ad un nucleo familiare. Iniziamo con l'introdurre le persone di cui andremo
a parlare:
ClassAssertion(:Persona :Mary)
Questa asserzione dice che un individuo chiamato Mary è una persona, ovvero
Mary è un'istanza o membro della classe Persona. In genere le classi sono
utilizzate per raggruppare tutte gli individui che hanno qualcosa in comune.
Possiamo utilizzare lo stesso costrutto per indicare che Mary è una Donna.
ClassAssertion(:Donna :Mary)
Le asserzioni ClassAssertion in RDF(S) possono essere espresse con il
costrutto rdf:type.
Le due classi appena introdotte, la classe Persona e la classe Donna, sono
in relazioni di sottoclasse. Nello speci�co la classe Persona è più generi-
ca della classe Donna. In OWL2 questo può essere espresso con l'assioma di
SubClassOf come di seguito:
SubClassOf(:Donna :Persona)
La presenza di questo assioma in un'ontologia consente di e�ettuare ragio-
namenti propri delle istanze della classe Persona sulle istanze della classe
Donna. Una relazione di sottoclasse tra le classi A e B può essere espressa
nel seguente modo: �tutte le istanze di A sono istanze di B�.
CAPITOLO 1. RDF, SPARQL E OWL 15
Supponiamo di avere anche l'assioma:
SubClassOf(:Madre :Donna)
La presenza di questi due assiomi di sottoclasse permette di dedurre che tutte
le madri sono donne, ma anche che tutte le madri sono persone. Tecnicamen-
te, questo signi�ca che la relazione di sottoclasse è transitiva. La relazione è
anche ri�essiva, ovvero ogni classe è sottoclasse di se stessa, intuitivamente
tutte le persone sono persone. Le asserzioni SubClassOf in RDF(S) possono
essere espresse con il costrutto rdfs:subClassOf.
E' possibile che due o più classi in un vocabolario riferiscono lo stes-
so insieme. OWL2 fornisce un meccanismo che permette di asserire che due
classi sono semanticamente equivalenti. Ad esempio i termini Persona e
EssereUmano possono essere interscambiabili, ovvero ogni istanza della clas-
se Persona è anche una instanza di EssereUmano e viceversa. Due classi sono
considerate equivalenti se esse contengono esattamente gli stessi membri.
EquivalentClasses(:Persona :EssereUmano)
Asserire che Persona ed EssereUmano sono equivalenti equivale a dire:
SubClassOf(:Persona :EssereUmano)
SubClassOf(:EssereUmano :Persona)
In alcuni casi l'appartenenza ad una classe esclude l'essere membri di
altre classi. Se si considerano le classi Uomo e Donna, si può escludere il
fatto che un individuo sia istanza di entrambe le classi. Questa relazione di
incompatibilità può essere espressa con l'assioma DisjointClasses
DisjointClasses(:Donna :Uomo)
Nella pratica le asserzioni disgiuntive vengono spesso dimenticate, in quanto
le incompatibilità sembrerebbero evidenti. Ma omettendo i DisjointClas-
ses, deduzioni potenzialmente utili possono essere perse. Dato l'assioma
precedente, un ragionatore OWL2 può asserire la disgiunzione tra le classi
Madre e Uomo. Le asserzioni DisjointClasses in RDF(S) non possono essere
espresse, in quanto questi asserisce solo fatti positivi.
CAPITOLO 1. RDF, SPARQL E OWL 16
Abbiamo appena visto un modo per descrivere i singoli individui e le
relazioni tra classi. Molto spesso in un'ontologia è signi�cativo speci�care in
che relazione stanno i singoli individui tra di loro. Ritornando all'esempio
precedente iniziamo con l'indicare che �La moglie di John è Mary�:
ObjectPropertyAssertion(:hasWife :John :Mary)
L'ordine in cui gli individui vengono scritti è importante. Mentre �la moglie
di John è Mary� è vero, �la moglie di Mary è John� certamente non lo è. Le
asserzioni ObjectPropertyAssertion in RDF(S) sono semplici triple.
In OWL2 è possibile asserire che due individui non sono connessi da una
proprietà, per esempio �Mary non è moglie di Bill�:
NegativeObjectPropertyAssertion(:hasWife :John :Mary)
Questo assioma è l'unico strumento a disposizione per fare asserzioni quando
si conosce la falsità di un fatto. Le asserzioni di questo tipo non possono
essere espresse in RDF(S).
Come per le classi, anche per le proprietà è possibile de�nire una gerar-
chia. OWL2 consente di speci�care queste situazioni con l'assioma SubObject-
PropertyOf. Per esempio asserire �La moglie di John è Mary� equivale ad
asserire �John è sposato con Mary�
SubObjectPropertyOf(:hasWife :hasSpouse)
Le asserzioni SubObjectPropertyOf in RDF(S) possono essere espresse
con rdfs:subPropertyOf.
Frequentemente, le informazioni che due individui sono interconnessi da
una certa proprietà consente di trarre conclusioni riguardanti gli individui
stessi. In particolare, un ragionatore può inferire nuovi predicati veri ri-
guardanti l'appartenenza ad una classe. Per esempio, l'asserzione che B è la
moglie di A ovviamente implica che B è una donna mentre A è un uomo.
Questo può essere espresso nel seguente modo:
ObjectPropertyDomain(:hasWife :Uomo)
ObjectPropertyRange(:hasWife :Donna)
CAPITOLO 1. RDF, SPARQL E OWL 17
Le asserzioni ObjectPropertyDomain e ObjectPropertyRange in
RDF(S) possono essere espresse con rdfs:domain e rdfs:range
In OWL2 è anche possibile asserire che due individui siano o meno la stessa
persona. Ad esempio se si vuole escludere che John e Bill siano lo stesso
individuo, questo può essere espresso nel seguente modo:
DifferentIndividuals(:John :Bill)
Questo tipo di a�ermazioni non possono essere espresse in RDF(S).
E' anche possibile asserire che due nomi di�erenti riferiscono/denotano lo
stesso individuo. Per esempio, possiamo dire che James e Jim sono lo stesso
individuo
SameIndividual(:James :Jim)
Ai �ni del lavoro di tesi si utilizzeranno un sottoinsieme dei costrutti OWL2
presentati. Per la trattazione completa della sintassi formale si rimanda al
documento [11].
1.2.4 Semantica diretta
La semantica formale di OWL2 speci�ca come derivare le sue conseguenze
logiche, ovvero i fatti che non sono presenti in modo esplicito nell'ontologia.
Esistono due modelli alternativi per assegnare semantica alle ontologie di
OWL2:
� un modello teorico, che permette di dare una semantica diretta agli
assiomi [15]
� un modello basato su RDF [14]
Il termine OWL2 DL viene utilizzato per riferire un ontologia OWL2 inter-
pretata utilizzato la semantica diretta.
Il termine OWL2 Full è utilizzato quando viene utilizzata il modello basa-
to su RDF. L'unica di�erenza tra i due modelli è rappresentato dalla semantica
delle annotazioni. In OWL2 DL le annotazioni non hanno un signi�cato for-
male, quindi possono essere tranquillamente ignorate, ciò non accade nelle
ontologie OWL2 Full.
CAPITOLO 1. RDF, SPARQL E OWL 18
1.3 SPARQL Protocol and RDF Query Lan-
guage
Contestualmente al rilascio di RDF è sorto il problema di interrogare i dati
RDF. Tra i diversi linguaggi di interrogazione proprosti, SPARQL è il linguag-
gio de�nito dal W3C. É diventato standard nel gennaio 2008 con una prima
versione minimale. Nel gennaio 2010 sono stati pubblicati i working draft
per la versione 1.1 che aggiungono caratteristiche tipiche di un linguaggio di
interrogazione non presenti nella versione iniziale.
1.3.1 Convenzioni
Terminologia
A di�erenza di RDF che utilizza le URIs (sequenza di caratteri ASCII), il
linguaggio SPARQL utilizza le IRIs (sequenza caratteri UNICODE).
Namespace
SPARQL supporta il meccanismo dei namespace pre�x XML. L'uso dei na-
mespace XML è molto importante in quanto essi forniscono un metodo per
identi�care senza ambiguità la semantica e le convenzioni che disciplina-
no l'utilizzo di proprietà all'interno di vocabolari già esistenti. In SPARQL
i namespace pre�x vengono introdotti dalla parola chiave prefix.
Il formato dati Turtle
In questo studio viene usato il formato dati TURTLE [10] che permette
di mostrare ogni tripla in maniera esplicita. Turtle permette di abbreviare le
IRIs con pre�ssi:
@prefix dc : <http : // purl . org/dc/elements /1.1/> .
@prefix : <http : // example . org/book/> .
: book1 dc : title "SPARQL Tutorial"
CAPITOLO 1. RDF, SPARQL E OWL 19
Descrizioni del risultato
I risultati di una query SPARQL vengono mostrati in forma tabellare
x y z
�Alice� <http://example/a>
Un binding è una coppia (variabile,GraphTerm1). Nel risultato mostrato
in tabella ci sono tre variabili x, y e z (headers delle colonne). Ogni riga della
tabella mostra una soluzione. In Tabella è mostrata una singola soluzione, in
cui x è legata ad �Alice�, y è legata a <http://example/a> e z è unbound,
ovvero non è legata ad alcun termine. Non è richiesto che tutte le variabili
di una soluzione siano legate.
1.3.2 Introduzione al linguaggio SPARQL
Molte query SPARQL contengono un insieme di triple pattern chiamato
Basic Graph Pattern (BGP). I triple patterns sono simili alle triple RDF ma
si di�erenziano per la possibilità di avere in posizione di soggetto, predicato
e oggetto una variabile. Dato un BGP è possibile confrontarlo con un grafo
RDF, chiamato active graph. Il risultato del confronto è una tabella di binding.
Nell'esempio seguente è mostrata una query SPARQL utilizzata per ricer-
care il titolo di un libro su uno speci�co dataset. La query è composta da
due parti: la clausola select che contiene le variabili che dovranno apparire
nel risultato �nale, e la clausola where che fornisce il BGP.
Dataset:
@prefix dc : <http : // purl . org/dc/elements /1.1/> .
@prefix : <http : // example . org/book/> .
: book1 dc : title "SPARQL Tutorial" .
1Il termine indica una risorsa RDF
CAPITOLO 1. RDF, SPARQL E OWL 20
Query:
PREFIX dc : <http : // purl . org/dc/elements /1.1/> .
PREFIX : <http : // example . org/book/> .
SELECT ?title
WHERE { : book1 dc : title ?title }
Risultato:
title
�SPARQL Tutorial�
E' possibile avere zero, una o più soluzione come risultato dell'esecuzione
di una query. Consideriamo il seguente esempio:
Dataset:
@prefix foaf : <http : // xmlns . com/foaf/0.1> .
_ : a foaf : name "Johnny Lee Outlaw" .
_ : a foaf : mbox <mailto : jlow@example . com> .
_ : b foaf : name "Peter Goodguy"
_ : b foaf : mbox <mailto : peter@example . org> .
_ : c foaf : mbox <mailto : carol@example . org> .
Query:
PREFIX foaf : <http : // xmlns . com/foaf/0.1>
SELECT ?name ?mbox
WHERE {?x foaf : name ?name .
?x foaf : mbox ?mbox}
Risultato
name mbox
�Johnny Lee Outlaw� <mailto:[email protected]>�Peter Goodguy� <mailto:[email protected]>
Ogni riga della tabella fornisce una soluzione ovvero un modo con cui le
variabili selezionate possono essere legate con termini RDF in modo tale che
il BGP corrisponda a triple nel dataset.
CAPITOLO 1. RDF, SPARQL E OWL 21
Matching RDF Literals
Il seguente dataset contiene tre RDF literals.
@prefix dt : <http : // example . org/datatype#> .
@prefix ns : <http : // example . org/ns#> .
@prefix : <http : // example . org/ns#> .
@prefix xsd : <http : // www . w3c . org /2001/ XMLSchema#> .
: x ns : p "cat"@en .
: y ns : o "42"^^xsd : integer .
: z ns : p "abc"^^dt : specialDatatype .
�cat�@en è un plain literal con tag di linguaggio en;
�42�^^xsd:integer è un typed literal con tipo
http://www.w3c.org/2001/XMLSchema#integer;
�abc�^^dt:specialDatatype è un typed literal con tipo
http://example.org/datatype#specialDatatype
La seguente query non ha soluzione perchè �cat� è diverso da �cat�@en.
SELECT ?v WHERE {?v ?p "cat"}
Al contrario, la query seguente presenta una soluzione in quanto la varibile
v può essere legata a :x
SELECT ?v WHERE {?v ?p "cat"@en}
Gli integer utilizzati in SPARQL sono dei literal con tipo: xsd:integer.
Per esempio 42 è la forma abbreviata di �42�^^xsd:integer.
SELECT ?v WHERE {?v ?p 42}
Risultato
v
<http://example.org/ns#y>
CAPITOLO 1. RDF, SPARQL E OWL 22
Blank Node nei risultati delle Query
Il risultato di una query può contenere dei blank nodes. I blank nodes
vengono scritti nella seguente forma �_:� seguiti da un nome che identi�ca
il blank node. L'uso di uno stesso nome all'interno dello stesso risultatos
identi�ca lo stesso blank node.
Dataset
@prefix foaf : <http : // xmlns . com/foaf/0.1> .
_ : a foaf : name "Alice" .
_ : b foaf : name "Bob" .
Query
PREFIX foaf : <http : // xmlns . com/foaf/0.1>
SELECT ?x ?nome
WHERE {?x foaf : name ?name}
Risultato
x name
_:c �Alice�_:d �Bob�
I nomi dei blank nodes presenti nella soluzione sono scelti dal sistema e
sono scorrelati da quelli utilizzati nel dataset. Un'altro possibile risultato è
mostrato nella tabella seguente.
x name
_:r �Alice�_:s �Bob�
Le informazioni contenute nelle due tabelle sono identiche. I nomi dei
blank node servono solo ad identi�care uno stesso termine RDF all'interno
della soluzione.
CAPITOLO 1. RDF, SPARQL E OWL 23
Costruire gra� RDF
SPARQL mette a disposizione diverse forme di query. La forma select
ritorna una tabella contenente i binding delle variabili. La forma construct
ritorna un grafo RDF. Il grafo è costruito utilizzando un template che genera
le triple RDF basandosi sul risultato prodotto dal graph pattern matching.
Dataset:
@prefix org : <http : // example . com/ns#> .
_ : a org : employeeName "Alice" .
_ : a org : employeeID 12345 .
_ : b org : employeeName "Bob" .
_ : b org : employeeID 67890 .
Query:
PREFIX foaf : <http : // xmlns . com/foaf/0.1>
PREFIX org : <http : // example . com/ns#>
CONSTRUCT {?x foaf : name ?name}
WHERE {?x org : employeeName ?name}
Risultato:
@prefix foaf : <http : // xmlns . com/foaf/0.1> .
_ : x foaf : name "Alice" .
_ : y foaf : name "Bob" .
che può essere serializzato in RDF/XML come:
<rdf:RDF
xmlns : rd f=" ht tp : //www.w3 . org /1999/02/22− rdf−syntax−ns#"xmln s : f o a f=" ht tp : //xmlns . com/ f o a f /0 .1/ "
>
<rd f :D e s c r i p t i o n>
<foaf :name>Alice</ foaf :name>
</ rd f :D e s c r i p t i o n>
<rd f :D e s c r i p t i o n>
<foaf :name>Bob</ foaf :name>
</ rd f :D e s c r i p t i o n>
</rdf:RDF>
CAPITOLO 1. RDF, SPARQL E OWL 24
1.3.3 Graph Pattern
Il graph pattern è la componente della query con la quale viene selezionato
il sottografo RDF del risultato. È una componente base di una query SPARQL
ed è ottenuta dalla composizione di strumenti diversi. Il graph pattern è
delimitato dalle parentesi gra�e.
Basic Graph Pattern
Il BGP, già introdotto precedentemente, è il componente elementare di un
Graph Pattern. Nell'esempio seguente viene mostrato un unico basic graph
pattern costituito da due triple pattern. Il risultato della query è il prodotto
relazionale tra le due tabelle di binding ottenute dai matching tra i singoli
triple pattern e l'active graph.
PREFIX foaf : <http : // xmlns . com/foaf/0.1/>
SELECT ?name ?mbox
WHERE { ?x foaf : name ?name .
?x foaf : mbox ?mbox }
La stessa soluzione può essere ottenuta dalla seguente query, che raggrup-
pa due basic graph pattern, uno per ogni triple pattern.
PREFIX foaf : <http : // xmlns . com/foaf/0.1/>
SELECT ?name ?mbox
WHERE { { ?x foaf : name ?name }
{ ?x foaf : mbox ?mbox } }
Graph Pattern vuoto
E' possibile speci�care un basic graph pattern vuoto che confrontato con
qualsiasi grafo ritorna la soluzione in cui le variabili sono unbound.
{}
CAPITOLO 1. RDF, SPARQL E OWL 25
Graph Pattern con restrizione
La parola chiave filter restringe il risultato prodotto da un graph pat-
tern matching alle soluzioni che soddisfano l'espressione �ltrante.
Dataset
@prefix dc : <http : // purl . org/dc/elements /1.1/> .
@prefix : <http : // example . org/book/> .
@prefix ns : <http : // example . org/ns#> .
: book1 dc : title "SPARQL Tutorial" .
: book1 ns : price 42 .
: book2 dc : title "The Semantic Web" .
: book2 ns : price 23 .
Query
PREFIX dc : <http : // purl . org/dc/elements /1.1/>
PREFIX ns : <http : // example . org/ns#>
SELECT ?title ?price
WHERE { ?x ns : price ?price .
FILTER (? price < 30 .5 )
?x dc : title ?title . }
Risultato
title price
�The Semantic Web� 23
Se non ci fosse stata la restrizione sul prezzo del libro anche la tupla
(�SPARQL TUTORIAL�,42) sarebbe apparsa nel risultato. E' possibile avere
più restrizioni all'interno della clausola where.
. . .
WHERE { ?x ns : price ?price .
FILTER (? price < 30 .5 )
FILTER (? price > 20)
FILTER ( bound (? price ) )
?x dc : title ?title . }
CAPITOLO 1. RDF, SPARQL E OWL 26
SPARQL permette di applicare ai termini di un grafo RDF e alle variabili
una serie di funzioni e operatori per �ltrare il risultato. Alcuni sono propri
del linguaggio, altri invece vegnono implementati invocando delle funzioni o
usando operatori XPath e XQuery. Nella sezione 11.3 di [6] vi è una tabella
in cui ogni riga è composta da un operatore, i tipi degli argomenti attesi, la
funzione invocata e il tipo del risultato. In tabella 1.2 sono riportate alcune
righe della tabella citata in [6].
Operatore Tipo (A/B) Funzione Risultato
BOUND(A) variabile bound(A) xsd:booleanisIRI(A) isURI(A) termine RDF isIRI(A) xsd:booleanisBLANK(A) termine RDF isBlank(A) xsd:booleanisLITERAL(A) termine RDF isLiteral(A) xsd:booleansameTERM(A,B) termine RDF sameTerm(A,B) xsd:booleanlangMATCHES(A,B) simple literal langMatches(A,B) xsd:booleanREGEX(S,P) simple literal fn:matches(S,P) xsd:boolean
Tabella 1.2: Operatori SPARQL
La funzione bound restituisce true se la variabile passata come argo-
mento ha un valore non vuoto, isIri2 se il termine è un IRI, isLiteral se
è un literal e isBlank se è un blank node. sameTerm restituisce true
se i parametri sono lo stesso termine, langMatches se il tag di linguaggio
A è presente nell'insieme dei tag di linguaggi B.
Operatore Tipo (A) Funzione Risultato
STR(A) literal str(A) simple literalSTR(A) IRI str(A) simple literalLANG(A) literal lang(A) simple literalDATATYPE(A) typed literal datatype(A) IRIDATATYPE(A) simple literal datatype(A) IRI
Tabella 1.3: Funzioni accessorie SPARQL
La Tabella 1.3 elenca alcune funzioni usate da SPARQL. str restituisce la
stringa corrispondente al valore del literal o dell'IRI passato come parametro,
2isURI invoca questa funzione in quanto SPARQL usa gli IRI (una sequenza di caratteri
Unicode) anzichè gli URI (caratteri ASCII).
CAPITOLO 1. RDF, SPARQL E OWL 27
lang restituisce il solo tag di linguaggio di un literal (se non è de�nito rende
una stringa vuota), datatype rende la IRI relativa al tipo del literal se
questo è un typed literal, altrimenti rende xsd:string se è plain literal.
Optional Graph Pattern
Le parti opzionali di un graph pattern possono essere speci�cate sintat-
ticamente con la parola chiave optional applicata ad un graph pattern.
La parola chiave OPTIONAL è associativa da sinistra, quindi i seguenti
pattern sono equivalenti
pattern OPTIONAL { pattern } OPTIoNAL { pattern }
{ pattern OPTIONAL { pattern } } OPTIONAL { pattenr }
Consideriamo il seguente esempio:
Dataset:
@prefix foaf : <http : // xmlns . com/foaf/0.1/> .
_ : a foaf : name "Alice" .
_ : a foaf : homepage <http : // work . example . com/alice/> .
_ : b foaf : name "Bob" .
_ : b foaf : mbox <mailto : bob@work . example> .
Query:
PREFIX foaf : <http : // xmlns . com/foaf/0.1/> .
SELECT ?name ?mbox ?hpage
WHERE { ?x foaf : name ?name .
OPTIONAL {?x foaf : mbox ?mbox}
OPTIONAL {?x foaf : homepage ?hpage} }
Risultato:
name mbox hpage
�Alice� <http://work.example.org/alice/>
�Bob� <mailto:[email protected]>
CAPITOLO 1. RDF, SPARQL E OWL 28
Alternative Graph Pattern
SPARQL fornisce la possibilità di unire i diversi risultati ottenuti da più
graph pattern speci�cati prima e dopo la parola chiave union. Di seguito
è mostrato un esempio. I pre�ssi dc10 e dc11 stanno rispettivamente per
versione 1.0 e 1.1 dello schema Dublin Core. Questa query vuole selezionare
i titoli dei libri memorizzati, indipendentemente dalla versione del Dublin
Core usata.
Dataset:
@prefix dc10 : <http : // purl . org/dc/elements /1.0/>
@prefix dc11 : <http : // purl . org/dc/elements /1.1/>
_ : a dc10 : title "SPARQL Query Language Tutorial " .
_ : a dc10 : creator "Alice" .
_ : b dc11 : title "SPARQL Protocol Tutorial" .
_ : b dc11 : creator "Bob" .
_ : c dc10 : title "SPARQL" .
_ : d dc11 : title "SPARQL ( updated ) " .
Query:
PREFIX dc10 : <http : // purl . org/dc/elements /1.0/>
PREFIX dc11 : <http : // purl . org/dc/elements /1.1/>
SELECT ?title
WHERE { { ?book dc10 : title ?title} UNION { ?book dc11 : title ?title} }
Risultato:
title
�SPARQL Protocol Tutorial��SPARQL��SPARQL (updated)��SPARQL Query Language Tutorial�
Se invece si volesse tener traccia della versione, si potrebbero utilizzare
due variabili diverse al posto della sola ?title come mostrato di seguito
CAPITOLO 1. RDF, SPARQL E OWL 29
Query:
PREFIX dc10 : <http : // purl . org/dc/elements /1.0/>
PREFIX dc11 : <http : // purl . org/dc/elements /1.1/>
SELECT ?x ?y
WHERE { { ?book dc10 : title ?x} UNION { ?book dc11 : title ?y} }
Risultato:
?x ?y
�SPARQL Protocol Tutorial��SPARQL�
�SPARQL (updated)��SPARQL Query Language Tutorial�
1.3.4 Dataset
Un dataset RDF è un insieme di gra� RDF su cui è possibile eseguire una
query. Un dataset contiene sempre un grafo di default senza nome, e altri
gra� identi�cati da un nome (chiamati named graph).
L'esecuzione della query avviene di default sul grafo senza nome. SPARQL
permette però di eseguire la query su uno o più gra� di�erenti. È possibile
speci�care questi gra� al momento della richiesta di esecuzione di una query
oppure direttamente nella query mediante opportune clausole.
Se i gra� vengono indicati sia nella query che nella richiesta, il servizio
prenderà in considerazione solo quelli speci�cati nella richiesta. Nello studio
ci limiteremo comunque a prendere in considerazione solo le indicazioni dei
gra� nella query.
Con la parola chiave from, seguita da un IRI, viene cambiato il grafo
di default. Se vengono speci�cate più clausole from il grafo di default sarà
il risultato dall'RDF merge dei gra� elencati.
Con la parola chiave from named si va ad indicare un named gra-
ph, che si aggiungerà alla lista dei gra� che potranno essere usatilizzati per
l'esecuzione nella query.
CAPITOLO 1. RDF, SPARQL E OWL 30
Graph pattern sui named graph
La parola chiave graph, inserita all'interno della WHERE e seguita da
un IRI (o da una variabile) e da un graph pattern, permette di eseguire il
graph pattern sul grafo indicato da IRI ( o sui gra� indicati dal binding della
variabile). La �gura 1.5 mostra una query con tre named graph e un graph
pattern complesso.
Figura 1.5: Esecuzione di una query con named graph
Di seguito diamo una spiegazione dell'esecuzione della query.
Il primo basic graph pattern viene eseguito sul grafo di default. Il basic
graph pattern che segue la prima occorrenza della parola chiave graph
viene eseguito sul grafo g:g1. Il basic graph pattern che segue la seconda
occorrenza di graph viene eseguito su tutti i named graph, in quanto la
variabile ?g viene legata a tutte le IRIs dei named graph.
CAPITOLO 1. RDF, SPARQL E OWL 31
1.3.5 Modi�catori di soluzione
I modi�catori di soluzione, applicati alla tabella di binding modi�cano il
risultato della query creando un ordine, eliminando i duplicati o riducendo
la cardinalità della soluzione.
Ordinamento
Ordina le righe della tabella in ordine crescente o decrescente secondo
l'operatore �<�. Viene introdotto con la parola chiave order by inserita
dopo la clausola where. Di default l'ordinamento è crescente, se lo si
vuole modi�care basta inserire la parola chiave DESC seguita dal gruppo
di variabili rispetto a cui si vuole ordinare.
PREFIX dc : <http : // purl . org/dc/elements /1.1/>
SELECT ?doc ?autore
WHERE { ?doc dc : creator ?autore . ?doc dc : date ?anno}
ORDERBY ?autore
Proiezione
La proiezione sulla tabella dei binding avviene semplicemente indicando
dopo la parola chiave select la lista delle variabili. Per proiettare l'intera
tabella viene utilizzata la parola chiave *.
Duplicati
Per rimuove i duplicati dalle colonne indicate, si usa distint dopo la pa-
rola chiave select seguita dalla lista di variabili di cui si vogliono eliminare
le soluzioni duplicate.
SPARQL mette a disposizione lo strumento reduced che, in presenza di
valori duplicati, ne mantiene un numero casuale all'interno della soluzione.
Cardinalità
Sceglie una sottotabella della tabella di binding. Con limit indichiamo
il limite superiore di soluzioni e con offset la soluzione da cui partire.
CAPITOLO 1. RDF, SPARQL E OWL 32
1.3.6 Forme del risultato
Una delle carattristiche interessanti di SPARQL è la possibilità di scegliere
il tipo del risultato. Questo è il passo �nale nel �usso di esecuzione della
query, in cui si riceve la tabella di binding delle variabili e la si utilizza in
modi diversi per ottenere risultati diversi. La forma select, quella utilizzata
in tutti gli esempi fatti �n ora, restituisce una proiezione della tabella di
binding.
La forma construct, a partire dalla tabella di binding e da un templa-
te, costruisce e rende un nuovo grafo. Il template non è altro che un insieme
di triple pattern. Partendo dalla tabella di binding, i valori associati alle
variabili vengono mappati sulle triple del template creando così delle nuove
triple RDF che comporranno il grafo della soluzione. Se dovessero compari-
re dei nodi blank sia nelle triple del template che nei valori della tabella,
questi verrebbero sostituiti con dei nuovi nodi blank. Generalmente questo
strumento viene utilizzato quando si vuole cambiare lo schema dei dati. Per
esempio la query construct mostrata nell'esempio precendente selezionava
dati org da un grafo e li trasformava in dati foaf. In questo caso il graph
pattern ha più soluzioni, per cui il grafo risultato è ottenuto dall'unione di
tutti i gra� che descrivono ogni singola risorsa.
La forma describe restituisce le informazioni associate ad una risorsa
sottoforma di grafo RDF. La risorsa viene indicata subito dopo la parola chiave
describe tramite una IRI. La scelta delle informazioni rese come risultato è
fatta dal sistema. È possible richiedere delle informzioni relative a più risorse
come nella query seguente:
PREFIX foaf : <http : // xmlns . com/foaf/0.1/>
DESCRIBE ?x ?y <http : // example . org/alice/>
WHERE { ?x foaf : knows ?y }
La forma ask restituisce il booleano true nel caso in cui la tabella di
binding sia non vuota, false altrimenti.
CAPITOLO 1. RDF, SPARQL E OWL 33
1.3.7 Introduzione alla versione 1.1
La versione 1.0 di SPARQL è ormai standard dal 2008. Nel gennaio 2010
il W3C ha pubblicato un working draft in cui si introducono degli strumenti
aggiuntivi al linguaggio, tipici di un linguaggio di interrogazione.
Espressioni nella proiezione
Nella clausola select è possibile introdurre nuove variabili e inserire
delle espressioni. La parola chiave utilizzata è as.
PREFIX dc : <http : // purl . org/dc/elements /1.1>
PREFIX ns : <http : // example . org/ns/>
SELECT ? title ( ?p AS ? fullprice )
( ? fullprice*(1−discount ) AS customerprice )
WHERE { ?x ns : price ?p ;
dc : title ?title ;
ns : discount ? discount }
Query annidate
Nella clausola where è possibile innestare delle query, per rendere più
potente e �essibile l'espressività delle interrogazioni.
PREFIX ex : <http : // people . example/>
SELECT ?y ? minName
WHERE { ex : alice ex : Knows ?y .
{ SELECT ?y ( MIN (? name ) AS ? minName )
WHERE { ?y ex : name ?name }
GROUPBY ?y} }
Funzioni di aggregazione
Gli aggregati sono espressioni che si applicano ad un gruppo di soluzio-
ni. Come in SQL, la clausola group by speci�ca le variabili da utilizzare
per la creazione dei raggruppamenti. SPARQL 1.1 de�nisce le seguenti fun-
zioni di aggregazione: count, sum, min,max, avg, group_concat e
campione. SPARQL 1.1 introduce anche la clausola having per �ltrare i
risultati dopo l'applicazione delle funzioni di aggregazione.
CAPITOLO 1. RDF, SPARQL E OWL 34
Esistenza del binding
Permette di veri�care se un graph pattern ha una soluzione non vuota
senza aggiungere nuovi binding. Per esempio la seguente query selezionerà
le persone che non hanno un attributo nome.
PREFIX foaf : <http : // xmlns . com/foaf/0.1/>
PREFIX rdf : <http : // www . w3 . org/1999/02/22−rdf−syntax−ns#>SELECT ? persona
WHERE { ? persona rdf : type foaf : person .
NOT EXISTS { ? persona foaf : name ?nome } }
Esiste anche la versione non negata exists.
Path di proprietà
Un path di proprietà descrive un possibile percorso tra nodi del grafo RDF.
L'esecuzione della query determina tutti i match dell'espressione di path e
crea i binding per il soggetto e l'oggetto. Per esempio la seguente query
visualizza il nome di ogni persona che Alice conosce.
PREFIX foaf : <http : // xmlns . com/foaf /0.1/>}
PREFIX ex : <http : // people . example/>
SELECT ?nome
WHERE { ex : Alice foaf : knows/foaf : name ?nome }
È possibile de�nire path complessi usando opportune forme sintattiche
alcune sono elencate nella Tabella 1.4.
Forma sintattica Corrispondenza
^item Path inverso, dall'oggetto al soggetto
item1 / item2 Sequenza di due elementi del path
item1 | item2 Path alternativi
item* Zero o più occorrenze di un elemento
item+ Una o più occorrenze di un elemento
item? Zero o una occorrenza di un elemento
item{n,m} Un path tra n e m occorrenze di un elemento
item{n} Un path con esattamente n occorrenze di un elemento
Tabella 1.4: Forme sintattiche per i path di proprietà
Capitolo 2
Sintassi e semantica di SPARQL
Con il rilascio del framework RDF è sorto il problema dell'interrogazione
delle informazioni espresse in questo formalismo. Sono stati proposti diversi
linguaggi di interrogazione, SPARQL è il linguaggio standard proposto dal W3C.
SPARQL è un linguaggio di interrogazione che si basa sul graph-matching.
Dato un dataset, una query è costituita da un pattern che viene confrontato
con i dati del dataset e i valori ottenuti dai confronti positivi sono elaborati
e restituiti come soluzione. Il dataset può essere costituito da più sorgenti,
ovvero più gra� RDF. Una query SPARQL è costituita da due parti e ha la
seguente forma Head ← Body. Il corpo, o Body, della query è un'espressione
complessa, chiamata graph pattern, che può include triple RDF con variabili,
congiunzioni, disgiunzioni, parti opzionali e vincoli sui valori delle variabili.
La testa, o Head, della query è un'espressione che dà indicazioni sulla forma
del risultato. La valutazione di una query Q su un grafo RDF è e�ettuata in
due passi:
� il corpo della query viene confrontato con il grafo in modo da ottenere
un insieme di binding per le variabili del corpo: la tabella di bindings;
� utilizzando le informazioni presenti nella testa della query, questi bin-
dings vengono elaborati, per esempio applicando i classici operatori
relazionali (proiezione, distinct, etc.), al �ne di produrre il risultato
�nale
35
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 36
Il risultato può avere diverse forme, per esempio può essere un valore boo-
leano, una tabella di valori o un nuovo grafo RDF. Di seguito andiamo a
formalizzare la sintassi e la semantica formale del frammento del linguaggio
SPARQL oggetto dello studio. SPARQL fornisce quattro tipi diversi di query:
select restituisce una proiezione della tabella di binding;
construct restituisce un grafo RDF costruito a partire dal risultato dell'e-
secuzione del corpo della query;
ask restituisce un valore di verità che indica se il pattern nella query ha
matchato o meno con il dataset;
describe restituisce un grafo RDF che descrive le risorse trovate.
La sintassi esposta nei prossimi paragra� riprende quella u�ciale del W3C
[6]. Non essendoci nessuna semantica u�ciale, quella presente nel capitolo si
basa sulla semantica proposta da Pérez, Arenas e Gutierrez [5].
2.1 Sintassi di Sparql
In questo studio ci siamo concentrati su un frammento ridotto del linguag-
gio SPARQL. Non sono stati considerati i modi�catori di soluzione, il prologo
della query e la query describe e sono stati generalizzati i graph pattern,
le triple e i template della query construct.
2.1.1 Sintassi tipi di query
I tipi di query analizzati sono tre: select, construct, ask. Non è
stata considerata la describe in quanto il risultato dell'esecuzione dipende
dal sistema e il suo tipo è noto solo a run time.
Tabella 2.1: Sintassi tipi di query
Query ::= SelectQuery | ConstructQuery | AskQuery
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 37
La forma select restituisce una proiezione delle variabili presenti nella
query con i loro bindings. La sintassi Select * è un'abbreviazione per
proiettare nel risultato tutte le variabili presenti nella query. La grammatica
permette anche di selezionare un sottoinsieme delle variabili legate.
Tabella 2.2: Sintassi query select
SelectQuery ::= SelectClause DatasetClause WhereClauseSelectClause ::= select ((Var)+ | * )
La forma construct restituisce un singolo grafo RDF, istanziazione di
un grafo template. Il risultato è un grafo RDF formato istanziando le variabili
del grafo template coi valori presenti nella tabella di binding. Le nuove triple
combinate con un operatore di unione forniscono il singolo grafo RDF, risultato
dell'esecuzione di query construct. Se qualche istanziazione produce triple
che contengono variabili �unbound� o stringhe in posizione di soggetto o
predicato, allora queste triple non verranno incluse nel grafo RDF. È possibile
creare un grafo RDF che contiene blank nodes. I nomi utilizzati per i blank
nodes hanno uno spazio di scoping associato al grafo creato.
Tabella 2.3: Sintassi query construct
ConstructQuery ::= ConstructClause DatasetClauseWhereClause
ConstructClause ::= construct ConstructTemplateConstructTemplate ::= Triple. Triple*
Molte applicazioni utilizzano la forma ask per testare se una query ha o
meno soluzione. L'unica informazione restituita dall'esecuzione della query
ask è un valore di verità che indica l'esistenza o meno di una soluzione.
Tabella 2.4: Sintassi query ask
AskQuery ::= ask DatasetClause WhereClause
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 38
2.1.2 Sintassi dataset
Le query SPARQL vengono eseguite su un dataset, una collezione di gra�
RDF, che può essere speci�cato:
� direttamente nella query, utilizzando le clausole from e from named;
� dal servizio SPARQL tramite il protocol request.
Senza perdere in generalità, consideriamo solo il primo caso. Il secondo caso
può essere ricondotto al primo, attraverso un preprocessing della query.
Il dataset è costituito dai gra� RDF identi�cati dagli IRIs speci�cati dopo
le clausole from e from named. Il dataset risultante dalle diverse clausole
from e from named è costituito da
� un grafo di default, grafo senza nome;
� un insieme di gra� nominati, coppie <IRI,Graph>.
Ogni clausola from contiene un IRI che riferisce un grafo che verrà usato
nella formazione del grafo di default. Questi gra� non saranno inseriti tra i
named graph. Se una query fornisce più clausole from, il grafo di default è
costituito dall'RDF merge [3] dei gra� riferiti nelle clausole. In questo studio
si è assunto che nella query sia sempre presente almeno una clausola from.
Una query può fornire anche una o più clausole from named. Ogni
clausola contiene un IRI, un riferimento ad un named graph. Se più clausole
from named sono seguite dallo stesso IRI, nel dataset viene inserito un
solo named graph con associato l'IRI. Le clausole from e from named
possono apparire entrambe nella stessa query. La presenza di uno stesso IRI
in due clausole from, o in una from e una from named crea ambiguità
nel dataset, come precisato nelle speci�che di SPARQL [6].
Tabella 2.5: Sintassi DatasetClause
DatasetClause ::= from (DefGraphClause|NamedGraphClause)DatasetClause | ε
DefGraphClause ::= IriRefNamedGraphClause ::= named IriRef
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 39
2.1.3 Sintassi variabili, graphTerm e triple pattern
Prima di proseguire con l'analisi della clausola where, so�ermiamoci
brevemente su alcuni concetti preliminari. De�niamo i seguenti domini Iri-
RefSet, BNodeSet e RDFLiteralSet, che identi�cano rispettivamente
l'insieme delle IRIs, dei Blank Nodes e degli RDFLiteral. L'unione di
questi domini rappresenta l'insieme di tutti i graphTerm oGraphTermSet.
De�niamo formalmente una tripla RDF come una tupla (s,p,o)
(s,p,o) ∈ (IriRef ∪ BNodeSet)×(IriRefSet)×(GraphTermSet)
Assumiamo l'esistenza di un insieme in�nito di variabili VarSet disgiun-
to da GraphTermSet. Un terminale della grammatica studiata è una
variabile, se inizia con uno dei seguenti simboli ? o $. Il nome che segue
questi simboli identi�ca il nome della variabile. L'unione dei domini Var-
Set e GraphTermSet viene indicata con VarOrGtermSet. L'unione
dei domini VarSet e IriRefSet viene indicata con VarOrIriSet.
La produzione della grammatica �Triple� identi�ca un triple pattern. Il
triple pattern è una tripla RDF, con la possibilità di avere in posizione di
soggetto, predicato e oggetto delle variabili. Il triple pattern è formalmente
de�nito come una tupla
(s,p,o)∈(VarOrGtermSet)×(VarOrIri)×(VarOrGtermSet)
La de�nizione del triple pattern permette di avere delle stringhe in posizione
di soggetto, come speci�ca il working group di RDF in [6]. Da notare che per
il momento non esistono gra� RDF con degli RDFLiteral in posizione di
soggetto, quindi un triple pattern con un soggetto di tipo stringa non troverà
riscontro in alcun dataset.
Tabella 2.6: Sintassi variabili, graphTerm e triple pattern
Triple ::= VarOrGterm VarOrIri VarOrGtermVarOrGterm ::= Var | GraphTermVarOrIri ::= Var | IriRefGraphTerm ::= IriRef | BNode | RDFLiteralVar ::= ? Varname | $ Varname
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 40
2.1.4 Sintassi graph pattern
SPARQL si basa sul concetto di graph pattern matching. La possibilità di
combinare semplici graph pattern ci permette di creare graph pattern compli-
cati. Nella sintassi utilizzata il graph pattern più semplice è il triple pattern.
Il linguaggio SPARQL o�re le seguenti parole chiave ., union, optional,
filter e graph che permettono di esprimere graph pattern complessi.
Tabella 2.7: Sintassi graph patterns
WhereClause ::= where GPGP ::= Triple | GP filter ValueC | GP.GP
| GP union GP | GP optional GP| graph VarOrIri GP
2.1.5 Sintassi value constraint
La parola chiave filter restringe la soluzione ritornata dal match del
graph pattern in base ad un'espressione data. Questa espressione prende il
nome di value constraint SPARQL. I �ltri eliminano alcune soluzioni. In un
value constraint vengono utilizzate funzioni (chiamate per nome) e operatori
SPARQL (parole chiavi della grammatica). Le funzioni e gli operatori operano
su graphTerm e sulle variabili. Alcune di queste funzioni e di questi operatori
sono presi direttamente da [7].
Tabella 2.8: Sintassi value constraints
ValueC ::= Var Op VarOrGterm | isIri(Var)| isBlank(Var) | isLiteral(Var)| langMatches(Var,Var) | bound(Var)| sameTerm(Var,Var) | ¬ValueC| ValueC ∨ ValueC | ValueC ∧ ValueC
Op ::= < | > | ≤ | ≥ | 6= | =
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 41
Grammatica SPARQL
In tabella 2.9 è riportata l'intero frammento SPARQL utilizzato nello stu-
dio. Dobbiamo fare una precisazione sulle triple utilizzate sia come com-
ponenti base dei gra� template, sia come componenti base dei graph pattern.
Tabella 2.9: Sintassi sempli�cata di SPARQL
Query ::= SelectQuery | ConstructQuery | AskQuerySelectQuery ::= SelectClause DatasetClause WhereClauseSelectClause ::= select ((Var)+ | * )ConstructQuery ::= ConstructClause DatasetClause
WhereClauseConstructClause ::= construct ConstructTemplateConstructTemplate ::= Triple.Triple*AskQuery ::= ask DatasetClause WhereClauseDatasetClause ::= from(DefGraphClause|NamedGraphClause)
DatasetClause | εDefGraphClause ::= IriRefNamedGraphClause ::= named IriRefWhereClause ::= where GPGP ::= Triple | GP filter ValueC | GP.GP
| GP union GP | GP optional GP| graph VarOrIri GP
Triple ::= VarOrGterm VarOrIri VarOrGtermValueC ::= Var Op VarOrGterm | isIri(Var)
| isBlank(Var) | isLiteral(Var)| langMatches(Var,Var) | bound(Var)| sameTerm(Var,Var) | ¬ValueC| ValueC ∨ ValueC | ValueC ∧ ValueC
Op ::= < | > | ≤ | ≥ | 6= | =VarOrGterm ::= Var | GraphTermVarOrIri ::= Var | IriRefGraphTerm ::= IriRef | BNode | RDFLiteralVar ::= ? Varname | $ Varname
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 42
2.2 Semantica di SPARQL
Il W3C non ha proposto alcuna semantica formale u�ciale per il linguaggio
SPARQL. Sebbene la sintassi del linguaggio sia ben de�nita, l'assenza di una
semantica formale crea delle di�coltà nell'interpretazione di alcune query.
Ogni query SPARQL viene eseguita su uno o più gra� del dataset RDF. Dato
un ambiente iniziale, questo viene modi�cato dalla DatasetClause. De�niamo
l'ambiente come una funzione:
GEnv = IriRefSetf−→ GraphSet
L'ambiente di valutazione del corpo di una query è una coppia nel dominio
(GEnvSet×GraphSet).GEnv è il tipo dell'ambiente che associa ad ogni riferimento IriRef un
grafo.
Graph è il tipo del grafo di default o active graph, ovvero del grafo su
cui verrà eseguito il corpo di una query. Se nel corpo della query è presente
la parola chiave graph, l'active graph cambia.
Dall'esecuzione del corpo della query otteniamo una relazione o tabella
di binding. Ogni relazione è de�nita da un insieme di record,
Rel = ℘(Record)
dove i record sono delle funzioni che associano ad una variabile o ad un
graphTerm un termine del grafo, in presenza di binding, o Null, in caso di
unbound.
Record = VarOrGtermSetf−→ (GraphTermSet ∪ Null)
Dato un record t ed un termine g, de�niamo l'operatore binario che
restitisce il valore del termine g in funzione del record t nel seguente modo:
-[-] : Record → VarOrGtermSet → GraphTermSet
t[g] =
{t(g) se g ∈ dom(t)
g altrimenti
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 43
Se il termine g appartiene al dominio della funzione t, ovvero è un variabile
o un graphTerm in t, allora viene applicata la funzione t all'argomento g ;
altrimenti l'operatore binario restituisce il termine stesso g.
De�niamo di seguito la semantica formale dei diversi costrutti del lin-
guaggio. Nella trattazione adotteremo le seguenti notazioni per i record:
� [] è il record vuoto
� [a1=g1 ,. . . , an=gn] è un record che associa ad ogni ai il corrispondente
gi, dove ai appartiene al dominio VarOrGtermSet e i gi appartiene
al dominio (GraphTermSet ∪ Null)
� [t1]++[t2] denota l'operatozione di estensione del record t1 con il record
t2 con sovrascrittura dei campi di t1 in comune. Per esempio:
[?x=_:a,?y=_:b]++[?x=_:c,?z=_:d]=[?x=_:c,?y=_:b,?z=_:d]
Procediamo di seguito adottando un approccio top-down per presentare
la semantica di SPARQL.
2.2.1 Semantica SelectQuery
La semantica della SelectQuery restituisce una relazione. Il let utilizzato
nella de�nizione è il classico binder che assegna un valore ad una variabile.
J_KSq : SelectQuery → GEnvSet → RelSet
JSelectClause DatasetClause WhereClauseKSq% =
let (%1, δ) = JDatasetClauseKDc% ;
let r = BlankRename(JWhereClauseKWc%1,δ
);
return JSelectClauseKScr .
La SelectQuery è composta da tre clausole. La prima ad essere eseguita
è la DatasetClause che restituisce l'ambiente in cui la query sarà eseguita.
La WhereClause restituisce la relazione r o tabella di bindings, risultato
dell'esecuzione del corpo della query. In�ne la SelectClause e�ettua una
proiezione sulla tabella di bindings.
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 44
Nella semantica viene utilizzata la seguente funzione:
BlankRename = RelSetf−→ RelSet
BlankRename è una funzione bigettiva che data una relazione r′ crea una
nuova relazione r, avente le stesse righe di r′ ma con dei blank nodes �freschi�.
Cioè per ogni blank node b′ in r′ si genera un nuovo blank node b in r che
viene sostituito ad ogni occorrenza di b′ nelle righe di r. Applicata alla
tabella restituita dalla WhereClause, la BlankRename scorrela i blank nodes
che appaiano nel risultato da quelli presenti nel grafo.
2.2.2 Semantica SelectClause
La semantica della SelectClause applicata a una relazione r, restituisce
una nuova relazione.
J_KSc : SelectClause → RelSet → RelSet
Jselect Var1,. . . ,VarnKScr ={[Var1=t[Var1],. . . ,Varn=t[Varn]
]|t ∈ r
}Jselect *KScr = r
Se la parola chiave select è seguita da una lista di variabili, viene fatta
la proiezione delle variabili elencate sulla relazione r. Se invece è seguita dal
terminale * viene ritornata una relazione identica ad r.
2.2.3 Semantica ConstructQuery
La semantica della ConstructQuery applicata ad un ambiente restituisce
un grafo.
J_KCq : ConstructQuery → GEnvSet → GraphSet
JConstructClause DatasetClause WhereClauseKCq% =
let (%1, δ) = JDatasetClauseKDc% ;
let r = BlankRename(JWhereClauseKWc%1,δ
);
return JConstructClauseKCcr .
Il grafo viene costruito a partire dalla tabella di bindings ritornata dal-
l'esecuzione del corpo della query.
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 45
2.2.4 Semantica ConstructClause
La semantica della ConstructClause applicata ad una relazione restituisce
un grafo.
J_KCc : ConstructClause → RelSet → GraphSet
JConstruct ConstructTemplateKCcr = JConstructTemplateKCtr
2.2.5 Semantica ConstructTemplate
La semantica della ConstructTemplate applicata ad una relazione resti-
tuisce un grafo.
J_KCt : Triple → RelSet → GraphSet
JεKCtr = ε
JTriple.Triple*KCtr = JTripleKCtr ∪ JTriple*KCtrJTripleKCtr = Jg1 g2 g3KCtrJg1 g2 g3KCtr =
{⋃t∈ rJg1K
V gtt+[b1=ft
1,..,bn=ftn]
Jg2KV gtt+[b1=ft
1,..,bn=ftn]
Jg3KV gtt+[b1=ft
1,..,bn=ftn]
}Con la ConstructTemplate, si valutano tutte le triple tp del template su
ogni record t della relazione r. Se abbiamo k record in r, la tripla del template
viene valutata k volte e nel caso in cui contenga dei blank nodes b1. . . bn tali
blank nodes devono essere sostituiti nei k record con blank node �freschi�,
ovvero che non appaiano in altre parti del grafo o all'interno dei risultati
delle query, per rispettare la semantica di SPARQL. A questo scopo il record
t viene esteso con la sostutuzione b1=f t1. . . bn=ftn, la quale ridenomina i nodi
blank di tp con i nodi blank f t1. . . ftn diversi per ogni record t. La singola
f ti dato un indice i (dove i indica il numero progressivo di un blank node
nel template) e un record t, genera dei blank nodes diversi per ogni coppia
<indice,record>.
Formalmente le espressioni f t1. . . ftn identi�cano applicazioni di una fun-
zione iniettiva f , con il seguente tipo,
f : (Int×Record) → BNodeSet
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 46
Consideriamo la relazione r e il template mostrati di seguito:
?nome ?knows
�Alice� �Bob��Alice� �Maria��Maria� �Bob�
{ _:a foaf:name ?nome._:b foaf:name ?knows._:c rdf:type foaf:Group._:b foaf:member _:c }
I blank nodes presenti nel template sono tre. Una possibile de�nizione
tabellare della funzione f è mostrata in Tabella 2.10.XXXXXXXXXXXXt
i_:a _:b _:c
�Alice� �Bob� _:d _:e _:f�Alice� �Maria� _:g _:h _:i�Maria� �Bob� _:l _:m _:n
Tabella 2.10: De�nizione tabellare della funione f
Di seguito è mostrata la valutazione delle triple del template sul primo
dei tre record.
J_:a foaf:name ?nomeKCt[“Alice′′“Bob′′]++[ _:a=_:d , _:b=_:e , _:c=_:f ] ∪J_:b foaf:name ?KnowsKCt[“Alice′′“Bob′′]++[ _:a=_:d , _:b=_:e , _:c=_:f ] ∪J_:c rdf:type foaf:GroupKCt[“Alice′′“Bob′′]++[ _:a=_:d , _:b=_:e , _:c=_:f ] ∪J_:b foaf:member _:c KCt[“Alice′′“Bob′′]++[ _:a=_:d , _:b=_:e , _:c=_:f ] ∪ . . . =
= [ _ : d foaf : name “Alice′′.
_ : e foaf : name “Bob′′.
_ : f rdf : type foaf : Group.
_ : e foaf : member _ : f . . . ]
Si noti che:
� ogni diversa valutazione del template produce nodi blank diversi dai
precenti;
� la seconda e la quarta tripla del risultato hanno lo stesso soggetto _:e
proprio come nella seconda e quarta tripla del template _:b
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 47
2.2.6 Semantica AskQuery
La semantica della AskQuery restituisce un valore di verità.
J_KAq : AskQuery → GEnvSet → Bool
JAsk DatasetClause WhereClauseKAq% =
let (%1, δ) = JDatasetClauseKDc% ;
let r = BlankRename(JWhereClauseKWc%1,δ
);
return r 6= [].
L'Ask Query è costituita da due clausole: la DatasetClause e la Where-
Clause. Come nella SelectQuery viene eseguita prima la DatasetClause e poi
la WhereClause. L'AskQuery restituisce un booleano che indica se la tabella
di bindings creata con la WhereClause è o meno vuota.
2.2.7 Semantica DatasetClause
La semantica della DatasetClause restituisce l'ambiente di valutazione del
corpo della query. Quest'ambiente è costituito dalla coppia (ambiente named
graph, active graph), dove il grafo di default è l'active graph di default.
Una DatasetClause vuota restituisce una coppia le cui componenti sono
vuote.
Una DatasetClause non vuota modi�ca l'ambiente di valutazione del-
la query. In presenza di clausola from viene esteso il grafo di default
con l'operatore �∪� che e�ettua l'RDF merge [3]. In presenza di clausole
from named viene esteso l'ambiente con un nuovo �named graph�, utiliz-
zando l'operatore di concatenazione relazionale �++�, visto in precedenza.
J_KDc : DatasetClause → GEnvSet → (GEnvSet×Graph)
JεKDc% =(ε, ε)
JFrom IriRef DatasetClauseKDc% =(π1(JDatasetClauseKDc% ) , π2(JDatasetClauseKDc% ) ∪ %(IriRef)
)JFrom Named IriRef DatasetClauseKDc% =(
π1(JDatasetClauseKDc% ) ++[IriRef:%(IriRef)], π2(JDatasetClauseKDc% ))
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 48
2.2.8 Semantica Triple
La semantica delle triple applicata ad un ambiente di valutazione, ed a
un triple pattern, restituisce una relazione.
J_KTp : TripleSet → (GEnvSet×GraphSet) → Rel
JTripleKTp%,δ = JT1 T2 T3 KTp%,δJT1 T2 T3KTp%,δ= π(T1,T2,T3)(JT1Kt1%,δ 1 JT2Kt2%,δ 1 JT3Kt3%,δ)
J_Kt1 : VarOrGtermSet → (GEnvSet×GraphSet) → Rel
JVarKt1%,δ = {[Var=g1; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}JGTermKt1%,δ = {[1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ ∧ g1=GTerm }
J_Kt2 : VarOrIriSet → (GEnvSet×GraphSet) → Rel
JVarKt2%,δ = {[Var=g2; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}JIriRefKt2%,δ = {[1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ ∧ g2=IriRef }
J_Kt3 : VarOrGtermSet → (GEnvSet×GraphSet) → Rel
JVarKt3%,δ = {[Var=g3; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}JGTermKt3%,δ = {[1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ ∧ g3=GTerm }
La semantica di una tripla (T1,T2,T3) è ottenuta valutando separata-
mente le componenti delle triple. La valutazione della singola componente
restituisce una relazione. Successivamente viene fatta la giunzione tra le tre
tabelle ottenute una per ogni componente e, in�ne, la proiezione sulle varia-
bili della tripla. La notazione [1=g1; 2=g2; 3=g3] indica un record in cui in
posizione 1, 2 e 3 sono presenti i termini g1, g2, g3, termini di una tripla del
grafo.
Valutando la semantica della seguente tripla {?x dc:creator ?nome}
sull'active graph �δ� mostrato in Tabella 2.11 otteniamo:
J ?x dc:creator ?nome KTp%,δ =π(?x dc:creator ?nome)
(J?xKt1%,δ 1 Jdc:creatorKt2%,δ 1 J?nomeKt3%,δ
)
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 49
prefix dc: <http://purl.org/dc/elements/1.1/>_:a dc:creator �Eric Miller�_:a dc:year �2004-02-10�_:b dc:creator �Patrick Hayes�_:b dc:title �RDF Semantics�_:c dc:year �2010-01-26�
Tabella 2.11: Esempio grafo RDF
?x 1 2 3
_:a _:a dc:creator �Eric Miller�_:a _:a dc:year �2004-02-10�_:b _:b dc:creator �Patrick Hayes�_:b _:b dc:title �RDF Semantics�_:c _:c dc:year �2010-01-26�
Tabella 2.12: Valutazione della prima componente della tripla ?x
1 2 3
_:a dc:creator �Eric Miller�_:b dc:creator �Patrick Hayes�
Tabella 2.13: Valutazione della seconda componente della tripla dc:creator
?nome 1 2 3
�Eric Miller� _:a dc:creator �Eric Miller��2004-02-10� _:a dc:year �2004-02-10�
�Patrick Hayes� _:b dc:creator �Patrick Hayes�`RDF Semantics� _:b dc:title �RDF Semantics��2010-01-26� _:c dc:year �2010-01-26�
Tabella 2.14: Valutazione della terza componente della tripla ?nome
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 50
Le tabelle 2.12-2.14 mostrano le relazioni risultato della valutazione se-
parata della tre componenti della tripla ?x dc:creator ?nome
La tabella 2.15 mostra la giunzione delle relazioni precedenti. In�ne, su
tale tabella, viene fatta la proiezione sulle variabili ?x e ?nome.
?x ?nome 1 2 3
_:a �Eric Miller� _:a dc:creator �Eric Miller�_:b �Patrick Hayes� _:b dc:creator �Patrick Hayes�
Tabella 2.15: Join delle tre relazioni
2.2.9 Semantica VarOrGterm
La semantica della VarOrGterm, dato un record, restituisce un termine
del grafo risultato dell'applicazione dell'operatore binario -[-] al record.
J_KV gt : VarOrGtermSet → Record → GraphTermSet
JgKV gtt = t[g]
Consideriamo la tabella
?x ?nome
_:a �Eric Miller�_:b �Patrick Hayes�
La semantica Vgt applicata alla variabile ?nome, restituisce il valore
associato alla variabile sul record. Di seguito valutiamo la variabile ?nome
sul primo record della tabella
J?nomeKV gtt = �Eric Miller�
Da notare che, per de�nizione dell'operatore binario -[-], la semantica della
Vgt applicata ad un termine del grafo restituisce il termine stesso
J24KV gtt = 24
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 51
2.2.10 Semantica WhereClause
La semantica della WhereClause restituisce la tabella di binding ottenuta
dalla valutazione del corpo della query sull'ambiente di valutazione passato.
J_KWc : WhereClause → (GEnvSet×GraphSet) → Rel
JWhere GPKWc%,δ = JGPKGp%,δ
2.2.11 Semantica Graph Pattern
La semantica di GP, dato un ambiente di valutazione, restituisce una
relazione.
J_KGp : Gp → (GEnvSet×Graph) → Rel
J{}KGp%,δ = {[]}
JTripleKGp%,δ = JTripleKTp%,δJGP1.GP2KGp%,δ = JGP1KTp%,δ 1 JGP2KTp%,δJGP1 optional GP2KGp%,δ = JGP1KGp%,δ ×+ JGP2KGp%,δJGP1 union GP2KGp%,δ = JGP1KGp%,δ ∪ JGP2KGp%,δJIriRef Graph GPKGp%,δ = JGPKGp%,%(IriRef)JGraph Var GPKGp% =
{[V ar = i]
dip(i)1 JGP KGp%,%(i) | i ∈ dom(%)
}=⋃i∈dom(%){[V ar = i]} 1 JGP KGp%,%(i)
Data la concatenazione di due graph pattern, viene ritornata la giunzione
delle relazioni risultati dalla valutazione separata dei diversi graph pattern.
La clausola filter in un graph pattern riduce la relazioni ai record per
cui la Value constraint è vera.
Dato un graph pattern con un clausola optional viene ritornata la
giunzione esterna delle relazioni ottenute valutando i singoli graph pattern
R1 1+ R2 =
(R1 1 R2)∪[(R1 \πa1,...,an(R1 1R2))×{[b1=null. . . ,bm=null]}
]
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 52
dove a1,. . . ,an è lo schema della tabella R1 e b1,. . . ,bm sono i campi di R2
che non fanno parte della giunzione.
Dato un graph pattern con clausola graph preceduta da un IriRef, viene
ritornata una relazione ottenuta valutando il graph pattern sull'active graph
identi�cato dall'IriRef. Se a precedere graph è una variabile, il graph pat-
tern viene valutato su tutti i gra� identi�cati dagli IRI che vengono legate
alla variabile. Per fare questo nella semantica viene utilizzata la funzione
dom:
dom : GEnvSetf−→ IriRefSet
che permette di ottenere, dato un ambiente, i nomi dei gra� dell'ambiente.
2.2.12 Semantica ValueC
La semantica Vc applicata ad un ValueC ed un record, restituisce un
booleano che indica se il record soddisfa la condizione ValueC.
J_KV c : ValueC → Record → Bool
Jσ1 OP σ2KV ct = (Jσ1KV tgt OP Jσ2KV tgt )
Jbound(σ)KV ct = (JσKV tgt 6= Null)
JisIri(σ)KV ct = (datatype(JσKV tgt )==IriRef)
JisLiteral(σ)KV ct = (datatype(JσKV tgt )==RDFLiteral)
JisBlank(σ)KV ct = (datatype(JσKV tgt )==BNode)
JlangMatches(σ1,σ2)KV ct = langMatches(Jσ1KV tgt ,Jσ2KV tgt )
JsameTerm(σ1,σ2)KV ct = (Jσ1KV tgt == Jσ2KV tgt )
Gli operandi della condizione vengono valutati con la semantica Vgt. Per
esempio se la condizione fosse (?age OP 24), la valutazione si tradurreb-
be in
J?ageKV gtt OP J24KV gtt
Da notare che la datatype è una funzione che data una variabile o un
termine del grafo restituisce il suo tipo.
CAPITOLO 2. SINTASSI E SEMANTICA DI SPARQL 53
datatype : VarSetf−→ GraphTermSet
La langMatches è una funzione che dati due termini del grado, restituisce
true se essi sono RDFLiteral con i tag di lingua uguali, false altrimenti
langMatches : (GraphTermSet×GraphTermSet) f−→ Bool
L'operatore �==�, utilizzato nella de�nizione semantica della sameTerm,
restituisce true se i due operandi σ1 e σ2 sono lo stesso graphTerm come
de�nito in [9], false altrimenti.
Capitolo 3
Sistema di tipi
Le tecniche di analisi statica approssimano, a tempo di compilazione, il
comportamento di un programma a tempo di esecuzione, con l'obiettivo di
scoprire eventuali errori e dimostrare particolari proprietà.
L'analisi dei tipi è una delle tecniche più importanti. Classi�ca le frasi di
un programma in base al tipo di valori che calcolano e garantisce che ogni
operazione sia applicata a dati corretti.
Un sistema di tipo si speci�ca attraverso i seguenti passi:
1. de�nizione dell'ambiente dei tipi
2. de�nizione della sintassi dei tipi
3. de�nizione dei giudizi (judgments)
4. de�nizione delle regole di inferenza
5. de�nizione della semantica dei giudizi
Nel seguente capitolo verranno presentati i passi 1-4, mentre il capitolo
successivo è dedicato interamente alla de�nizione della semantica dei giudi-
zi e alla dimostrazione della soundness del sistema dei tipi rispetto a tale
semantica.
54
CAPITOLO 3. SISTEMA DI TIPI 55
3.1 Obiettivi
Il sistema dei tipi, che verrà speci�cato di seguito, dovrà avere le seguenti
proprietà:
� �essibilità, in termini di applicabilità dell'analisi. Il sistema deve essere
in grado di operare sia in ambienti di valutazione ricchi di informazioni
di tipo, sia in ambienti con scarse informazioni;
� semplicità, intesa come giusto compromesso tra una analisi dei tipi
eccessivamente dettagliata e una analisi eccessivamente ottimistica. Ad
esempio se il sistema dei tipi avesse informazioni tali da poter calcolare
un tipo eccessivamente complesso, vorremmo che ritornasse invece un
upper bound di tale tipo che fosse più intuitivo.
Gli approcci, che si possono utilizzare per la de�nizione di un sistema dei
tipi, sono due: approccio pessimistico, che considera sbagliate le frasi per le
quali non si riesce a dimostrare l'assenza di errori; appproccio ottimistico, che
considera corrette le frasi per le quali non si riesce a dimostrare la presenza
di errori.
In questo lavoro adottaremo un approccio ibrido per la de�nizione delle
regole di tipo del sistema. Adotteremo un approccio pessimistico per la
de�nizione delle regole di tipo per la testa della query. Nello speci�co, SPARQL
permette di costruire nuovi gra� RDF sulla base del risultato dell'esecuzione
del corpo della query. Il nostro sistema di tipi dovrà generare un errore se non
si riuscisse a stabilire un tipo per i nuovi gra�. Diversamente, adotteremo
un approccio ottimistico per la de�nizione delle regole di tipo per il corpo,
ovvero considereremo corrette tutte le frasi del corpo a meno che non si
dimostri una contraddizione tra loro. Operando in un contesto RDF (nel
corpo viene e�ettuato il graph matching tra il graph pattern SPARQL e i dati
RDF da interrogare) se adottassimo un sistema dei tipi RDFS non saremo in
grado di segnalare mai nessun errore; l'impossibilità di esprimere con RDFS
informazioni negative genera una situazione di compatibilità generale dei tipi,
dove nessuna informazione di tipi è in contraddizione con altre. Vedremo in
seguito come superare questa di�coltà.
CAPITOLO 3. SISTEMA DI TIPI 56
3.2 Requisiti del sistema di tipi
In questa sezione verranno analizzate una serie di query SPARQL. I risul-
tati dell'analisi guideranno la de�nizione del sistema dei tipi proposto per il
linguaggio. L'analisi è stata e�ettuata tenendo presente che il programma-
tore SPARQL può esprimere, mediante un formalismo, una conoscenza preli-
minare sui tipi dei dati che andrà ad interrogare. In questo lavoro di tesi
il formalismo che verrà utilizzato è il linguaggio per ontologie OWL2 e la co-
noscenza verrà modellata attraverso un insieme di assiomi che chiameremo
ExtraLightOWL schema o brevemente ELOSchema.
Tutte le query presenti in questa sezione vengono eseguite sull'active gra-
ph mostrato in �gura 3.1. In �gura sono presenti nodi e archi etichettati
con la stessa Iri. La Iri identi�ca univocamente una risorsa, per esempio sia
il nodo che gli archi etichettati plays_in identi�cano la stessa risorsa. Gli
archi etichettati in grassetto rappresentano predicati riservati RDFS.
Figura 3.1: Grafo RDF contenente informazioni su giocatori di calcio
CAPITOLO 3. SISTEMA DI TIPI 57
L'analisi verrà e�ettuata individuando per ciascuna query quale potrebbe
essere, a nostro parere, il tipo che un sistema di tipi inferirebbe.
La query 3.1 eseguita sull'active graph, restituisce tutte le triple RDF che
compongono il grafo. Il tipo del risultato dell'esecuzione della query è dato
dalle variabili ?s, ?p e ?o con i rispettivi tipi. Non avendo informazioni sulle
variabili, ci aspetteremmo:
� ?s : IriRefSet ∪ BNodeSet
� ?p : IriRefSet
� ?o : IriRefSet ∪ BNodeSet ∪ RDFLiteralSet
SELECT ?s ?p ?o
FROM <http://soccer_play.example/>
WHERE { ?s ?p ?o }
Query 3.1: AnyGraph
La query 3.2 eseguita sull'active graph, restituisce la lista dei giocatori di
calcio del Barcelona. Il tipo del risultato dell'esecuzione della query è dato
dal tipo della variabile ?player. A di�erenza della query precedente, per in-
ferire il tipo della variabile possiamo utilizzare informazioni presenti e deduci-
bili dalle asserzioni OWL2 presenti nello ELOSchema. In quest'esempio speci�co
potremmo dedurre il tipo della variabile ?player a partire da un asserzio-
ne sul dominio del predicato plays_in. Se nello ELOSchema fosse presen-
te un'asserzione ObjectPropertyDomain(plays_in, soccer_player),
potremmo dedurre che la variabile ?player ha tipo soccer_player.
SELECT ?player
FROM <http://soccer_play.example/>
WHERE { ?player plays_in Barcelona }
Query 3.2: Rdfs:domain
CAPITOLO 3. SISTEMA DI TIPI 58
Analogamente, il tipo di ?team della query 3.3 può essere dedotto a partire
da asserzioni sul range del predicato plays_in. Se nello schema fosse pre-
sente una asserzione ObjectPropertyRange(plays_in, soccer_team),
potremmo dedurre che la variabile ?team ha tipo soccer_team.
SELECT ?team
FROM <http://soccer_play.example/>
WHERE { Ronaldinho plays_in ?team }
Query 3.3: Rdfs:range
Combinando le informazioni utilizzate per inferire il tipo del risultato
della query 3.2 e della query 3.3, siamo in grado di avere informazioni sul
tipo delle variabili ?player e ?team presenti nella query 3.4
SELECT ?player,?team
FROM <http://soccer_play.example/>
WHERE {?player plays_in ?team}
Query 3.4: Rdfs:range and Rdfs:domain
La query 3.5 restituisce la lista dei calciatori che giocano in una squadra
di calcio. Il tipo del risultato non è ovvio, in quanto un sistema dei tipi
potrebbe comportarsi in due modi distinti:
1. il sistema potrebbe ricavare informazioni sul valore di ?p, dal value
constraint all'interno della filter e da queste dedurre informazioni di
tipo relativamente a ?player e ?team;
2. il sistema evita di operare tali deduzioni.
Nel primo caso, identi�cando con ?p il predicato plays_in, il tipo del
risultato risulterebbe uguale a quello della query 3.4. Nel secondo caso il
tipo del risultato sarebbe uguale a quello della query 3.1.
CAPITOLO 3. SISTEMA DI TIPI 59
Entrambi i comportamenti sono ragionevoli. A nostro avviso, sono poche
le situazioni in cui dall'analisi statica di una filter riusciremmo a ricavare
informazioni di tipi interessanti. Per questo motivo il nosto sistema dei tipi
in presenza di una filter veri�cherà esclusivamente che l'espressione al suo
interno sia e�ettivamente un value constraint che ritorna un booleano.
SELECT ?player,?team
FROM <http://soccer_play.example/>
WHERE { ?player ?p ?team.
filter (?p = plays_in)
Query 3.5: Value constraint
Fino ad ora abbbiamo visto che uno ELOSchema può contenere informa-
zioni relative ai domini e ai range dei predicati. La scelta del linguaggi OWL2
come formalismo per speci�care informazioni di tipo è dovuta alla possibilità
di speci�care anche vincoli di disgiunzione tra tipi. L'introduzione di que-
sti vincoli permette di rilevare interessanti situazioni in cui parti diverse di
una query sono inconsistenti tra di loro. L'assenza dei vincoli di disgiunzio-
ne renderebbe impossibile l'individuazione di incompatibilità tra tipi, come
accennato in precedenza, ogni tipo risulterebbe potenzialmente compatibile
con qualsiasi altro tipi.
Se avessimo adottato RDFS come formalismo per speci�care uno schema
di informazioni, non avremmo avuto un costrutto per esplicitare vincoli di
disgiunzione.
Il linguaggio OWL2 fornisce il costrutto DisjointClasses per esprimere i
vincoli di disgiunzione in uno ELOSchema. OWL2 permette anche di introdurre
gerarchie di tipo attraverso asserzioni di tipo SubClassOf.
In �gura 3.2 vengono mostrate due gerarchie di tipo e tre vincoli di di-
sgiunzione. I vincoli di disgiunzione si ripercuotono sulle gerarchie di tipo.
Per esempio, a�ermare che il tipo person è disgiunto da country implica che
i tipi sportsman e soccerteam, essendo sottotipi di person, siano disgiunti
da country.
CAPITOLO 3. SISTEMA DI TIPI 60
Figura 3.2: Vincoli di disgiunzione e di sottoclasse
Proseguiamo con l'analisi della query 3.6 che restituisce la lista dei gio-
catori di calcio, che sono anche città. Se nello schema fossero presenti le
seguenti asserzioni il sistema dei tipi genererebbe un errore.
� DisjointClasses(person,country)
� ObjectPropertyDomain(plays_in, soccer_player)
� ObjectPropertyRange(lives_in, country)
� SubClassOf(person, sportsman)
� SubClassOf(sportsman, soccer_player)
Il tipo della variabile ?person è soccer_player nella prima tripla, men-
tre nella seconda tripla è country. Essendo soccer_player un sottoti-
po di person ed essendo person disgiunto dalla classe country avremmo
un'incompatibilità di tipi.
SELECT ?person
FROM <http://soccer_play.example/>
WHERE { ?person plays_in ?team .
Ronaldinho lives_in ?person}
Query 3.6: DisjointClasses and SubClassOf
CAPITOLO 3. SISTEMA DI TIPI 61
Ovviamente, oltre ad avere informazioni da asserzioni ObjectProper-
tyDomain e ObjectPropertyRange, possiamo avere informazioni di ti-
po dal predicato rdf:type. La query 3.7, come nel caso precedente, presenta
una incompatibilità di tipi.
SELECT ?person
FROM <http://soccer_play.example/>
WHERE { ?person rdf:type Person .
Ronaldinho lives_in ?person}
Query 3.7: DisjointClasses
Analizziamo la query 3.8. Se si adottasse lo ELOSchema de�nito per le
due query precendenti, cosi come la variabile ?person anche per la costante
Ronaldinho ci aspetteremmo una incompatibilità di tipo. Questo possibilità,
di tipizzare le costanti come se fossero variabili, può apparire abbastanza
sorprendente, dato che nessun linguaggio di programmazione o interrogazione
si comporterebbe in questo modo, a nostra conoscenza.
Nel nostro sistema, il tipo di una costante può essere speci�cato a priori
o può essere dedotto dal codice. Nel primo caso il sistema rileva eventuali
contraddizioni tra il tipo speci�cato e quello dedotto dal codice. Nel secondo
caso la costante viene tipizzata come se fosse una variabile, per cui verrebbero
comunque rilevate evenutali contraddizioni tra i diversi usi della costante,
come avviene nella query 3.8.
SELECT ?team
FROM <http://soccer_play.example/>
WHERE { Ronaldinho plays_in ?team .
?z lives_in Ronaldinho}
Query 3.8: VarOrGTerm error
La query 3.9 restituisce la lista delle persone che vivono in Barcellonna.
Il tipo della variabile ?person è deducibile dallo ELOSchema come visto pre-
cedentemente. La presenza di un errore sintattico in Barcellonna, secondo
noi, non dovrebbe in�uenzare il tipo della variabile di ritorno.
CAPITOLO 3. SISTEMA DI TIPI 62
SELECT ?person
FROM <http://soccer_play.example/>
WHERE { ?person lives_in Barcellonna }
Query 3.9: Soggetto No Error 1
L'errore sintattico Berson, nella query 3.10, questa volta comporta un
tipo di ritorno diverso. Utilizzando uno ELOSchema in un'assunzione a mondo
aperto, non potremmo dire che Berson non sia una classe, quindi in linea
di principio nella query la variabile ?person avrà tipo Berson. Il risultato
dell'esecuzione della query sul dataset è una relazione ben tipata, ma vuota,
in quanto non esistono triple nel dataset che matchano con il graph pattern.
SELECT ?person
FROM <http://soccer_play.example/>
WHERE { ?person rdf:type Berson}
Query 3.10: Soggetto No Error 2
La query 3.11 restituisce l'insieme delle proprietà che hanno come soggetto
Ronaldinho e come oggetto Barcelona. Secondo una assunzione a mondo
aperto non potremmo dire nulla a riguardo ?p, eccetto che è un Iri. Noi però
supporremo che per ogni grafo sia possibile speci�care la lista dei predicati
che vi possono comparire, {pi}i=1...n. Per ogni predicato pi, presente in questa
lista, andiamo a calcolare l'intersezione tra il tipo del dominio di pi e il tipo
di Ronaldinho e l'intersezione tra il suo range e il tipo di Barcelona. Se
una di queste intersezioni è vuota, il predicato pi viene eliminato dal tipo di
?p. Il risultato �nale è il sottoinsieme di predicati che appaiano nel dataset
tali per cui i domini e i range sono compatibili con i tipi di Ronaldinho e
Barcelona.
SELECT ?p
FROM <http://soccer_play.example/>
WHERE { Ronaldinho ?p Barcelona}
Query 3.11: Predicato
CAPITOLO 3. SISTEMA DI TIPI 63
3.3 Il sistema dei tipi: ambiente delle informa-
zioni di tipo
Iniziamo ad introdurre i diversi elementi del nostro sistema dei tipi, secon-
do lo schema indicato all'inizio del capitolo. Partiamo quindi dall'ambiente
delle informazioni di tipo ( in breve, ambiente dei tipi o ambiente statico).
ExtraLightOWL Schema
Lo ELOSchema è la parte innovativa del sistema di tipi proposto. Esso
rappresenta la conoscenza preliminare del programmatore SPARQL sui dati
che verranno interrogare. Questa conoscenza viene modellata con un insieme
di assiomi OWL2. In tabella 3.1 è mostrata la grammatica SI, acronimo di
Schema di Informazione, per de�nire uno ELOSchema.
SI ::= ε | ClassAssertion(IriRef1, IriRef2)| SubClassOf(IriRef1,IriRef2)| DisjointClasses(IriRef1,IriRef2)| ObjectPropertyDomain(IriRef1,IriRef2)| ObjectPropertyRange(IriRef1,IriRef2)| SI,SI
Tabella 3.1: Sintassi ELO schema
In questo lavoro sono state introdotte due nozioni semantiche per uno
ELOSchema:
1. la semantica immediata di uno ELOSchema corrisponde ad un insieme
di assiomi OWL2;
2. la semantica estesa di uno ELOSchema fornisce un ambiente di valuta-
zione tipizzato.
CAPITOLO 3. SISTEMA DI TIPI 64
La prima nozione semantica,mette in corrispondenza le produzioni della
grammatica SI con i costrutti della sintassi funzionale di OWL2.
J_Ksi : SISet → AxiomSet
JεKsi = ∅J ClassAssertion(IriRef1, IriRef2)Ksi = ClassAssertion(IriRef1, IriRef2)
J SubClassOf(IriRef1,IriRef2)Ksi = SubClassOf(IriRef1,IriRef2)
J DisjointClasses(IriRef1,IriRef2)Ksi = DisjointClasses(IriRef1,IriRef2)
J ObjectPropertyDomain(IriRef1,IriRef2)Ksi =ObjectPropertyDomain(IriRef1,IriRef2)
J ObjectPropertyRange(IriRef1,IriRef2)Ksi =ObjectPropertyRange(IriRef1,IriRef2)
J SI1,SI2Ksi = J SI1Ksi,J SI2Ksi
La seconda nozione semantica introduce il concetto di modello M(SI).
In prima battuta indichiamo con modello M(SI) un insieme di ambienti di
named graph validi secondo l'insieme di assiomi JSIKsi, per cui potremmo
de�nireM(SI) come:
{ % | ∀i ∈ dom(%). %(i) |=OWL JSIKsi}
Un ambiente di named graph, %, fa parte di un modello M(SI), se per
ogni grafo γ presente in % gli assiomi contenuti in ϕ=JSIKsi sono validi. La
presenza di asserzioni DisjointClasses(IriRef1,IriRef2) in ϕ crea però dei
problemi. In particolare, può accadere che una stessa costante appaia in due
gra� diversi di % con due tipi incompatibili. In questi caso, anche se ciascun
dei due gra� soddisfa singolarmente ϕ, %, considerato nel suo complesso, non
lo soddisfa.
Per risolvere questo problema, introduciamo la nozione di ambiente delle
costanti tipizzate. Esso è de�nito come una funzione che preso un IriRef
ritorna una lista di costanti aventi tipo IriRef
TEnv = IriRefSetf−→ IriRefSet
CAPITOLO 3. SISTEMA DI TIPI 65
Un grafo γ soddisfa un ambiente di costanti tipizzate τ se per ogni tripla
(s, p, o) ∈ γ sono veri�cate le seguenti due condizioni:
� se il dominio di p è x, allora s ∈ τ(x);
� se il range di p è y, allora o ∈ τ(y).
Consideriamo l'ambiente delle costanti tipizzate mostrato in tabella 3.2.
Esso speci�ca che se una stessa costante compare in due gra� γ1, γ2 ∈ %, peresempio Luigi, allora Luigi in entrambi i gra� deve avere tipo Persona, per
cui non sono possibili con�itti. Da notare, per tutti gli IriRef prede�niti,
che rappresentano tipi atomini, per esempio xsd:Integer, τ applicato a tali
IriRef restituisce l'insieme dei literal corrispondenti.
τ(Città) { Roma, Berlina, Napoli, ...}τ(Persona) { Luigi, Maria, ...}τ(xsd:Integer) Z
Tabella 3.2: Esempio di ambiente delle costanti tipizzate
Formalizziamo questa nozione interpretando SI come l' �unione dipenden-
te� di tutti gli ambienti di named graph, %, tali che % |=OWL JSIKsi e per i
quali esiste un ambiente delle costanti tipizzate τ tale che % |=OWL τ :
{ % | ∃τ ∈ TEnv . ∀i ∈ dom(%) . %(i) |=OWL τ, JSIKsi}
Per motivi tecnici, in M(SI) riportiamo esplicitamente i valori di τ e
ϕ=JSIKsi, ottenendo �nalmente la seguente de�nizione:
M(SI) = {(τ, ϕ, %) | τ ∈ TEnv, ϕ = JSIKsi, ∀ i ∈ dom(%). %(i) |=OWL τ, ϕ}
Andiamo ora a formalizzare la nozione di soddisfazione γ |= τ, ϕ.
Un grafo γ soddisfa un insieme di assiomi ϕ e una tipizzazione delle costanti
τ se e solo se le informazioni presenti in τ sono compatibili con le asserzioni
OWL2 presenti in ϕ e le costanti presenti in un grafo non violano i vincoli di
tipo speci�cati in τ .
CAPITOLO 3. SISTEMA DI TIPI 66
De�nizione 3.1
γ |=OWL τ, ϕ ⇔ γ |=OWLϕ τ ∨ τ |=OWL ϕ
Questo vuol dire che:
τ |=OWL ϕ ⇔ ∀ SubClassOf(a, b) ∈ ϕ ⇒ τ(a) ∈ τ(b)
∀ DisjointClasses(a, b) ∈ ϕ ⇒ τ(a) ∩ τ(b) = ∅∀ ClassAssertion(a, b) ∈ ϕ ⇒ a ∈ τ(b)
Queste proprietà esprimono il fatto che un IriRefi può avere diversi tipi
a1, . . . , an, purchè questi non siano incompatibili, e in questo caso avremo
IriRefi ∈ τ(a1),. . . ,IriRefi ∈ τ(an)
γ |=OWLϕ τ ⇔ ∀ s, p, o, d. (s, p, o) ∈ γ ∧
ObjectPropertyDomain(p, d) ∈ ϕ⇒ s ∈ τ(d)
∀ s, p, o, r.(s, p, o) ∈ γ ∧ObjectPropertyRange(p, r) ∈ ϕ⇒ o ∈ τ(r)
3.4 Sintassi e semantica dei tipi
La grammatica che de�nisce la sintassi dei tipi è mostrata in tabella 3.3.
Ogni tipo de�nito denota un insieme di elementi tra loro omogenei.
Type TN ::= T_IRI | T_RDFLiteral | T_BNode | {IriRef}| {lit} | nameOf(TG) | TN∪TN | TN∩TN| ofType(IriRef)
Type TG ::= T_IRI | {IriRef} | TG∪TG | ε
Type TR ::= [ ] | [Vgt : σTN] | TR × TR | ε
Type NG ::= NG,IriRef:nameOf(TG) | ε
Tabella 3.3: Sintassi dei tipi
CAPITOLO 3. SISTEMA DI TIPI 67
Nel seguito per ogni non-terminale N usiamo la notazione NSet per indica-
re il linguaggio generato da N. Ad esempio TNSet denota tutte le espressioni
che possono essere generate dalle produzioni di TN:
TNSet = {T_IRI, T_RDFLiteral, . . . , ofType(IriRef),
T_IRI ∪ T_RDFLiteral, ofType(Person), . . . }
Nelle sottosezioni de�niamo la semantica dei diversi tipi de�niti. Per
non appensatire la notazione utilizziamo le seguenti convenzioni: la lettera I
denota il dominio IriRefSet, la lettera B il dominio BNodeSet, la lettera
L denota RDFLiteralSet e T viene utilizzata per denotare l'unione I∪B∪L
3.4.1 Semantica di un tipo nodo TN
Un tipo nodo denota un insieme di graphTerm, insieme di nodi di un
grafo RDF. Dato un tipo nodo ed un ambiente di valutazione, la semantica tn
rende l'insieme dei nodi cui il tipo si riferisce.
J_Ktn : TNSet→(IEnvSet × AxiomSet × GEnvSet)→ GraphTermSet
Il tipo T_IRI identi�ca l'insieme di tutte le IRI references.
JT_IRIKtnτ,ϕ,% = I
Il tipo T_RDFLiteral identi�ca l'insieme di tutti gli RDFLiterals.
J T_RDFLiteral Ktnτ,ϕ,% = L
Il tipo T_BNode identi�ca l'insieme di tutti i blank nodes.
J T_BNode Ktnτ,ϕ,% = B
Il tipo {lit}, a di�erenza del tipo T_RDFLiteral, viene utilizzato per
denotare l'insieme che contiene il singolo literal lit.
J{lit}Ktnτ,ϕ,% = {lit}
CAPITOLO 3. SISTEMA DI TIPI 68
Analogamente a quanto detto sopra, il tipo {IriRef} viene utilizzato per
denotare l'insieme che contiene il singolo riferimento IriRef.
J{IriRef}Ktnτ,ϕ,% = {IriRef}
Il tipo ofType({IriRef}) denota l'insieme delle IriRef1 che hanno come
tipo uno speci�co IriRef. Tale insieme dipende dalla componente τ del-
l'ambiente di valutazione tipizzato. Per esempio JofType({:person})Ktnτ,ϕ,%dipende da τ e denota l'insieme degli IriRefi che τ associa al tipo :person,
mentre JofType(xsd:Integer)Ktnτ,ϕ,% denota l'insieme di tutti gli interi.
JofType({IriRef})Ktnτ,ϕ,% = {IriRefi | IriRefi ∈ τ(IriRef)}
Il tipo nameOf(TG) denota il tipo di un IriRef che riferisce un grafo
nominato, il cui tipo è descritto da TG.
J nameOf(TG) Ktnτ,ϕ,% = {IriRef | %(IriRef) ∈ JTGKtgτ,ϕ,%}
L'unione di un tipo nodo comporta l'unione dei loro insiemi.
JTN1∪TN2Ktnτ,ϕ,% = JTN1Ktnτ,ϕ,% ∪ JTN2Ktnτ,ϕ,%
L'intersezione di un tipo nodo comporta l'intersezione dei loro insiemi.
JTN1∩TN2Ktnτ,ϕ,% = JTN1Ktnτ,ϕ,% ∩ JTN2Ktnτ,ϕ,%
Abbrevieremo di seguito con TN_Any il tipo nodo generico de�nito come
l'unione:
TN_Any = T_IRI ∪ T_BNode ∪ T_RDFLiteral
la cui semantica è la seguente
JTN_AnyKtnτ,ϕ,% = I∪B∪L = T
CAPITOLO 3. SISTEMA DI TIPI 69
3.4.2 Semantica di un tipo grafo TG
Un tipo grafo denota un insieme di gra�. Dato un tipo grafo e un ambiente
di valutazione, la semantica tg denota l'insieme dei gra� cui il tipo si riferisce.
J_Ktg : TGSet→(IEnvSet × AxiomSet × GEnvSet)→ GraphSet
Il tipo ε viene utilizzato per modellare il grafo vuoto.
JεKtgτ,ϕ,% = {ε}
Il tipo T_IRI viene utilizzato per denotare qualsiasi grafo.
JT_IRIKtgτ,ϕ,% = {G | G⊆ (I∪B) × I × T ∧ G|=OWL τ, ϕ}
Il tipo {IriRef} viene utilizzato per denotare i gra� che contengono triple
con IriRef in posizione di predicato
J{IriRef}Ktgτ,ϕ,% = {G | G⊆ (I∪B) × {IriRef} × T ∧ G|=OWL τ, ϕ}
L'unione di due tipi gra�, comporta l'unione dei gra� denotati.
JTG1 ∪ TG2Ktgτ,ϕ,% = JTG1 Ktgτ,ϕ,% ∪ JTG2 Ktgτ,ϕ,%
Forma normale dei tipi grafo Un tipo TG è in forma normale se e solo
se ha la seguente forma:
� T_IRI
� {IriRef1}∪. . .∪{IriRefn}
� ε
Ogni tipo TG può essere normalizzato applicato le seguenti regole:
� T_IRI ∪ TG = T_IRI
� ε ∪ TG = TG
CAPITOLO 3. SISTEMA DI TIPI 70
La forma normale è stata introdotta per sempli�care il sistema dei tipi propo-
sto in questa tesi, in particolare per quanto riguarda le regole di tipo relative
alle triple.
Un tipo grafo con struttura T_IRI denota un grafo generico, mentre un
tipo grafo con struttura {IriRef1}∪. . .∪{IriRefn} denota un grafo in cui
possono apparire, al più, i soli predicati IriRef1,. . . ,IriRefn
3.4.3 Semantica di un tipo relazione TR
Il tipo relazione denota una tabella. Dato un tipo relazione e un ambiente
di valutazione, la semantica tr restituisce una tabella.
J_Ktr : TRSet→(IEnvSet × AxiomSet × GEnvSet)→ RelSet
Il tipo relazione ε denota una tabella vuota.
JεK = {}
Il tipo relazione [ ] denota la tabella che contiene un solo record senza alcun
valore
J[]Ktrτ,ϕ,% = {[]}
Il tipo relazione atomico denota una tabella avente come schema una singola
variabile o un GraphTerm di tipo nodo.
J[Vgt : σTN]Ktrτ,ϕ,% = {[Vgt = X] | X ∈ JσTNKtnτ,ϕ,%}
Il simbolo σ è un indicatore di occorrenza e può assumere due valori σ =? |1.La semantica di un tipo nodo con indicatore di occorrenza JσTNKtnτ,ϕ,% vienede�nita nel seguente modo:
JσTNKtnτ,ϕ,% =
{JTNKtnτ,ϕ,% ∪ {T_Null} se σ =?
JTNKtnτ,ϕ,% altrimenti
Poichè l'indicatore di occorrenza viene utilizzato solo nei tipi relazioni è stata
evitata una modi�ca della grammatica dei tipi TN, per non appesantire la
notazione.
CAPITOLO 3. SISTEMA DI TIPI 71
Il prodotto di due tipi relazioni, comporta il prodotto relazionale tra le due
relazioni denotate.
JTR1×TR2Ktrτ,ϕ,% = JTR1Ktrτ,ϕ,% ××JTR2Ktrτ,ϕ,%
Questa notazione quindi corrisponde alla seguente semantica:
J[Vgt1 : σ1TN1 , . . . , Vgtn : σnTNn]Ktrτ,ϕ,% ={[Vgt1= X1 , . . . , Vgtn = Xn] | Xi ∈ JσiTNiKtnτ,ϕ,% ∧ i = 1...n}
MetaFunzioni union, and, opt
Di seguito diamo la de�nizione delle seguenti metafunzioni che prendono
la sintassi di due tipi relazioni, restituendo rispettivamente la sintassi della
loro unione, giunzione e giunzione esterna.
Dati i seguenti tipi relazioni:
TR1 = [V1 : σ1T1,. . . ,Vi : σiTi,Vi+1 : σi+1Ti+1,. . . ,Vn : σnTn] ;
TR2 = [V1 : σ′1T′1,. . . ,Vi : σ′iT
′i ,Vj : σ′jT
′j ,. . . ,Vm : σ′mT
′m] ;
assumiamo che TR1 e TR2 siano ordinati in modo da presentare nelle prime
i posizioni le stesse variabili o GraphTerm.
Funzione union
De�niamo l'unione sintattica di due relazioni nel seguente modo:
union(TR1 , TR2
)= [V1 : (σ1 ∪ σ′1)(T1 ∪ T ′1), . . . ,Vi : (σi ∪ σ′i)(Ti ∪ T ′i ),Vi+1 :? Ti+1, . . . , Vn :? Tn, Vj :? T ′j , . . . ,Vm :? T ′m]
dove l'operazione (σk ∪ σ′k) è de�nita in tabella 3.4
∪ 1 ?
1 1 ?? ? ?
Tabella 3.4: De�nizione dell'operazione di unione tra σ1 ∪ σ2
CAPITOLO 3. SISTEMA DI TIPI 72
Lemma union
Il seguente lemma ci permette di asserire che prese due relazioni r1 e r2,
la loro unione esterna ha un tipo contenuto nella semantica della funzione
union applicata ai tipi delle due relazioni.
r1 ⊆ JTR1Ktrτ,ϕ,% , r2 ⊆ JTR2Ktrτ,ϕ,% ⇒ r1∪+r2 ⊆ Junion(TR1,TR2)Ktrτ,ϕ,%
L'unione esterna tra due relazioni aventi schema diverso è ottenuta aggiun-
gendo colonne di valori nulli nelle due tabelle al �ne di rendere omogenei gli
schemi e quindi eseguire l'unione relazionale.
Dimostrazione. Assumiamo le premesse del lemma:
r1 ⊆ JTR1Ktrτ,ϕ,% , r2 ⊆ JTR2Ktrτ,ϕ,%
Dimostriamo che:
t ∈ r1 ∪+ r2 ⇒ t ∈ Junion(TR1 , TR2
)Ktrτϕ,%
Assumiamo la premessa t ∈ r1 ∪+ r2 , dimostriamo che:
t ∈ J[V1 : (σ1 ∪ σ′1)(T1 ∪ T ′1), . . . ,Vi : (σi ∪ σ′i)(Ti ∪ T ′i ),Vi+1 :? Ti+1,. . . ,Vn :? Tn,Vj :? T ′j ,. . . ,Vm :? T ′m]Ktrτϕ,%
ovvero vogliamo dimostrare:
1. ∀k = 1 . . . i. t[Vk]∈ J(σk ∪ σ′k)(Tk∪T′k)Ktnτ,ϕ,%
2. ∀k = i+ 1 . . . n. t[Vk]∈ J?TkKtnτ,ϕ,%
3. ∀k = j . . .m. t[Vk]∈ J?TkKtnτ,ϕ,%
Per de�nizione di unione esterna abbiamo due scenari possibili ∀ t∈r1∪+r2:
(a)(t[V1,. . . ,Vi,Vi+1,. . . ,Vn]⊆ JTR1Ktrτ,ϕ,% ∧ t[Vj,. . . ,Vm]=T_Null
)oppure
(b)(t[V1,. . . ,Vi,Vj,. . . ,Vm]⊆ JTR2Ktrτ,ϕ,% ∧ t[Vi+1,. . . ,Vn]=T_Null
)Nel caso in cui vale (a) abbiamo il seguente scenario:
CAPITOLO 3. SISTEMA DI TIPI 73
1. ∀k = 1 . . . i. t[Vk]∈ JσkTkKtnτ,ϕ,%
2. ∀k = i+ 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%
3. ∀k = j . . .m. t[Vk]=T_Null;
Nel caso in cui vale (b) abbiamo il seguente scenario:
1. ∀k = 1 . . . i. t[Vk]∈ Jσ′kT′kKtnτ,ϕ,%
2. ∀k = j . . .m. t[Vk]∈ JσkTkKtnτ,ϕ,%
3. ∀k = i+ 1 . . . n. t[Vk]=T_Null;
Poichè entrambi i due scenari possono essere validi:
1. ∀k = 1 . . . i. t[Vk]∈ JσkTkKtnτ,ϕ,% ∪ Jσ′kT′kKtnτ,ϕ,%per unione dei TN⇔
t[Vk]∈ J(σk ∪ σ′k)(Tk∪T′k)Ktnτ,ϕ,%
2. ∀k = i+ 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%∪ T_Null ⇔ t[Vk]∈ J?TkKtnτ,ϕ,%
3. ∀k = j . . .m. t[Vk]∈ JσkTkKtnτ,ϕ,%∪ T_Null ⇔ t[Vk]∈ J?TkKtnτ,ϕ,%
Operatore and
De�niamo la giunzione sintattica di due relazioni nel seguente modo:
and(TR1 , TR2
)= [V1 : (σ1 ∩ σ′1)(T1 ∩ T ′1), . . . ,Vi : (σi ∩ σ′i)(Ti ∩ T ′i ),Vi+1 : σi+1Ti+1, . . . , Vn : σnTn,Vj : σ′jT
′j , . . . ,Vm : σ′mT
′m]
dove l'operazione (σk ∩ σ′k) è de�nita in tabella 3.5
∩ 1 ?
1 1 1? 1 ?
Tabella 3.5: De�nizione dell'operazione tra σ1 ∩ σ2
CAPITOLO 3. SISTEMA DI TIPI 74
Lemma and
Il seguente lemma ci permette di asserire che prese due relazioni r1 e r2,
la loro giunzione ha un tipo contenuto nella semantica della funzione and
applicata ai tipi delle due relazioni.
r1 ⊆ JTR1Ktrτ,ϕ,% , r2 ⊆ JTR2Ktrτ,ϕ,% ⇒ r1 1 r2 ⊆ Jand(TR1,TR2)Ktrτ,ϕ,%
La giunzione tra due relazioni è de�nita come la classica giunzione relazionale.
Dimostrazione. Assumiamo le premesse del lemma:
r1 ⊆ JTR1Ktrτ,ϕ,%, r2 ⊆ JTR2Ktrτ,ϕ,%
Dimostriamo che:
t ∈ r1 1 r2 ⇒ t ∈ Jand(TR1 , TR2
)Ktrτ,ϕ,%
Assumiamo la premessa t ∈ r1 1 r2, dimostriamo che:
t ∈ J[V1 : (σ1 ∩ σ′1)(T1 ∩ T ′1), . . . ,Vi : (σi ∩ σ′i)(Ti ∩ T ′i ),Vi+1 : σi+1Ti+1, . . . , Vn : σnTn,Vj : σ′jT
′j , . . . ,Vm : σ′mT
′m]Ktrτ,ϕ,%
ovvero vogliamo dimostrare:
1. ∀k = 1 . . . i. t[Vk]∈ J(σk ∩ σ′k)(Tk∩T′k)Ktnτ,ϕ,%
2. ∀k = i+ 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%
3. ∀k = j . . .m. t[Vk]∈ JσkTkKtnτ,ϕ,%
Ma questa è banalmente dimostrabile applicando la de�nizione di giun-
zione relazionale:
1. ∀k = 1 . . . i. t[Vk]∈ JσkTkKtnτ,ϕ,% ∩ Jσ′kT′kKtnτ,ϕ,%per intersezione dei TN⇔
t[Vk]∈ J(σk ∩ σ′k)(Tk∩T′k)Ktnτ,ϕ,%;
2. ∀k = i+ 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%
3. ∀k = j . . .m. t[Vk]∈ JσkTkKtnτ,ϕ,%
CAPITOLO 3. SISTEMA DI TIPI 75
Operatore opt
De�niamo la giunzione esterna sintattica di due relazioni nel seguente modo:
opt(TR1 , TR2
)= [V1 : σ1T1, . . . , Vn : σnTn, Vj :? T ′j , . . . ,Vm : ?T ′m]
Lemma opt
Il seguente lemma ci permette di asserire che prese due relazioni r1 e r2,
la loro giunzione esterna ha un tipo contenuto nella semantica della funzione
opt applicata ai tipi delle due relazioni.
r1 ⊆ JTR1Ktrτ,ϕ,% , r2 ⊆ JTR2Ktrτ,ϕ,% ⇒ r1 1+ r2 ⊆ Jopt(TR1,TR2)Ktrτ,ϕ,%
La giunzione esterna tra due relazioni è de�nita come
r1 1+ r2 = (r1 1 r2)∪[(r1 \ πa1,...,an(r1 1r2))x{[b1=null,. . . ,bm=null]}
]dove [b1. . . bm] sono i campi di r2 non presenti in r1
Dimostrazione. Assumiamo le premesse del lemma:
r1 ⊆ JTR1Ktrτ,ϕ,%, r2 ⊆ JTR2Ktrτ,ϕ,%
Dimostriamo che:
t ∈ r1 1+ r2 ⇒ t ∈ Jopt(X1 , X2
)Ktrτϕ,%
Assumiamo la premessa t ∈ r1 1+ r2, dimostraimo che:
t ∈ J[V1 : σ1T1, . . . , Vn : σnTn, Vj :? T ′j , . . . ,Vm : ?T ′m]Ktrτ,ϕ,%
ovvero vogliamo dimostrare:
1. ∀k = 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%
2. ∀k = j . . .m. t[Vk]∈ J?TkKtnτ,ϕ,%
Per de�nizione di giunzione esterna abbiamo ∀ t∈r1∪+r2:
CAPITOLO 3. SISTEMA DI TIPI 76
(a)(t[V1,. . . ,Vn]⊆ JTR1Ktrτ,ϕ,% ∧ t[Vj,. . . ,Vm]=T_Null
)oppure
(b)(t[V1,. . . ,Vn]⊆ JTR1Ktrτ,ϕ,% ∧ t[Vj,. . . ,Vm]⊆ JTR2Ktrτ,ϕ,%
)Nel caso in cui vale (a) abbiamo il seguente scenario:
1. ∀k = 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%
2. ∀k = j . . .m. t[Vk]=T_Null;
Nel caso in cui vale (b) abbiamo il seguente scenario:
1. ∀k = 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%
2. ∀k = j . . .m. t[Vk]∈ JσkTkKtnτ,ϕ,%
ma questo equivale a dire:
1. ∀k = 1 . . . n. t[Vk]∈ JσkTkKtnτ,ϕ,%;
2. ∀k = j . . .m. t[Vk]∈ JσkTkKtnτ,ϕ,%∪ T_Null ⇔ t[Vk]∈ J?TkKtnτ,ϕ,%
3.4.4 Semantica di un tipo ambiente dei named graph
NG
Il tipo NG={IriRef1:nameOf(TG1),. . . ,IriRefn:nameOf(TGn)} de-
nota un insieme di ambienti GEnv in cui ogni IriRefi è legato ad un grafo
con tipo TGi.
J_Kng : NGSet→ (IEnvSet × AxiomSet × GEnvSet)→GEnvSet
Il tipo ε denota l'insieme di ambienti vuoto.
JεKngτ,ϕ,% = {ε}
Il tipo NG,IriRef:nameOf(TG) denota l'estensione dell'ambiente di gra-
� NG con una nuova associazione IriRef:nameOf(TG). Nella de�nizione
viene utilizzato l'operatore di prodotto relazionale ××.
JNG,IriRef:nameOf(TG)Kngτ,ϕ,%=JNGKngτ,ϕ,%××{[IriRef=γ ]|γ ∈ JTGKtgτ,ϕ,%}
CAPITOLO 3. SISTEMA DI TIPI 77
3.5 Judgment
I Judgment sono delle dichiarazioni formali che hanno la seguente forma:
Γ ` =
in cui Γ è l'ambiente di valutazione tipizzato e = una asserzione.
3.5.1 Judgment SPARQL
Ad ogni categoria sintattica del linguaggio SPARQL assoceremo un diverso
giudizio di tipo, indicato da un apice xx al di sopra del simbolo di implicazione
`xx.
Elenchiamo di seguito i diversi giudizi utilizzati. Tutte le diverse tipologie
di query vengono valutate su un ambiente costituito da uno ELOSchema e da
un ambiente di tipo dei named graph. Il tipo dell'esecuzione di una query è
un tipo TR per le query select, TG per le query construct e Bool per
le query Ask
SI,NG `Sq SelectQuery : TR
SI,NG `Cq ConstructQuery : TG
SI,NG `Aq AskQuery : Bool
La SelectClause opera su una tabella in ingresso con tipo TR e ritorna una
proiezione della tabella con tipo TR′.
TR `Sc SelectClause : TR′
La ConstructClause e la ConstructTemplate operano su una tabella in in-
gresso con tipo TR e ritornano un grafo con tipo TG.
SI,TR `Cc ConstructClause : TG
SI,TR `Ct ConstructTemplate : TG
CAPITOLO 3. SISTEMA DI TIPI 78
La valutazione della DatasetClause ritorna un ambiente di valuzione del cor-
po di una query La DatasetClause modi�ca l'ambiente dei named graph
iniziale di tipo NG e de�nisce il grafo di default di tipo TG.
SI,NG `Dc DatasetClause : NG′,TG
VarOrGTerm valutato su un tipo relazione ritorna il tipo di nodo presente
nella relazione.
TR `V gt VarOrGTerm : TN
La valutazione del corpo di una query su un ambiente ritorna una relazione
con tipo TR.
SI,NG,TG `Tp Triple : TR
SI,NG,TG `Wc WhereClause : TR
SI,NG,TG `Gp GP : TR
Data una relazione con tipo TR, il risultato della valutazione di un value
constraint è un booleano.
TR `V c ValueC : Bool
3.6 Regole di tipi
Le regole di tipo sostengono la validità di un judgment (conclusione) sulla
base di altri judgment chiamati premesse. La forma generale di una regola è
Γ1 ` =1 . . . Γn ` =nΓ ` =
Le premesse stanno al di sopra della linea orizzontale mentre la con-
clusione sta sotto. Se tutte le premesse sono dimostrate, la conclusione è
dimostrata.
CAPITOLO 3. SISTEMA DI TIPI 79
3.6.1 Funzioni ausiliari
Le premesse di una regola possono utilizzare le seguenti funzioni.
Funzione Dom
La funzione dominio prende due argomenti e ritorna un insieme di Iri-
Ref.
Dom : (IriRef × SI) → IriRefSet
La funzione dominio ritorna l'insieme degli IriRefi che fanno parte del do-
minio della proprietà passata come argomento IriRef in accordo a quanto
speci�cato nello ELOSchema.
Dom(IriRef,SI) = {IriRefi | ObjectPropertyDomain(IriRef,IriRefi)∈SI}
Funzione Range
La funzione range prende due argomenti e ritorna un insieme di IriRef.
Range : (IriRef × SI) → IriRefSet
La funzione range ritorna l'insieme degli IriRefi che fanno parte del range
della proprietà passata come parametro IriRef in accordo a quanto speci�-
cato nello ELOSchema SI.
Range(IriRef,SI) = {IriRefi | ObjectPropertyRange(IriRef,IriRefi)∈SI}
3.6.2 Regole SelectQuery
Il tipo associato ad una SelectQuery è dato dal tipo della SelectClause
valutata sul relazione della WhereClause valutata a sua volta sul tipo am-
biente creato dalla DatasetClause.
(TypeSelectQuery)
SI,NG `Dc DatasetClause : NG′, TG
SI,NG′, TG `Wc WhereClause : TR′
TR′ `Sc SelectClause : TR
SI,NG `Sq SelectClause DatasetClause WhereClause : TR
CAPITOLO 3. SISTEMA DI TIPI 80
3.6.3 Regole SelectClause
La TypeSelectClauseAll ritorna il tipo TR dell'ambiente di valuta-
zione. La TypeSelectClause valutata su una relazione TR ritorna il tipo
della proiezione di n variabili sulla relazione.
(TypeSelectClauseAll)
TR `Sc select * : TR
(TypeSelectClause)
TR `V gt?vi : TNi ∀i = 1, . . . , n
TR `Sc select ?v1, . . . , ?vn : [?v1 : TN1 , . . . , ?vn : TNn]
3.6.4 Regole ConstructQuery
Il tipo associato ad una ConstructQuery è dato dal tipo della Construct-
Clause valutata sul relazione della WhereClause valutata a sua volta sul tipo
ambiente creato dalla DatasetClause.
(TypeConstructQuery)
SI,NG `Dc DatasetClause : NG′, TG′
SI,NG′, TG′ `Wc WhereClause : TR
SI, TR `Cc ConstructClause : TG
SI,NG `Cq ConstructClause DatasetClause WhereClause : TG
3.6.5 Regole ConstructClause
Il tipo associato alla ConstructClause è dato dal tipo associato alla Con-
structTemplate.
(TypeConstructClause)
SI, TR `Ct ConstructTemplate : TG
SI, TR `Cc constructConstructTemplate : TG
CAPITOLO 3. SISTEMA DI TIPI 81
3.6.6 Regole ConstructTemplate
Il tipo associato alla ConstructTemplate è un tipo grafo. Di seguito ver-
ranno riportate le regole di tipo de�nite, secondo un approccio pessimistico.
Le regole ritornano un tipo grafo, se la ConstructTemplate genera un grafo
che rispetta lo ELOSchema e la tipizzazione delle costanti. Qualora questo
non avvenisse, il sistema rileva un errore di tipo.
Regola TypeConstructTemplateEmpty
Questa regola si applica ad un template vuoto e ritorna il tipo grafo vuoto.
(TypeConstructTemplateEmpty)
SI, TR `Ct ε : ε
Regola TypeConstructTemplatePredicateConstant
Questa regola si applica ad un template (s IriRef o) e ci permette di
stabilire il tipo del grafo γ, che verrà costruito, se e solo se siamo in grado
di dimostrare che tutti i termini (soggetti e oggetti del predicato IriRef)
rispettano i vincoli di tipi speci�cati nello ELOSchema.
Tra le premesse della regola di inferenza viene utilizzata l'operazione di
intersezione di un insieme di tipi X, ∩I∈xofType(I), così de�nita:
� X=∅ ⇒⋂I∈Xoftype(I) = T_Any
� X=({IriRef} ∪ X′) ⇒ ofType({IriRef}) ∩⋂I′∈X′ofType(I′)
Se nello ELOSchema non sono presenti asserzioni riguardo il dominio e
il range del predicato IriRef, allora gli insieme S e W, de�niti nelle pre-
messe della regola di inferenza sono vuoti. In questo caso le premesse,
SI`OWLTN<:∩TN′, sono soddisfatte banalmente.
Al contrario, in presenza di asserzioni di tipo ObjectPropertyRange
e ObjectPropertyDomain per il predicato IriRef, il soggetto e l'oggetto
devono avere un tipo che rispetti questi vincoli. Nello speci�co adottando
CAPITOLO 3. SISTEMA DI TIPI 82
un approccio pessimistico per la costruzione dei gra�, la regola può essere
applicata se e solo se il tipo del soggetto e il tipo dell'oggetto siano contenuti
rispettivamente nel tipo speci�cato per il dominio e per il range di IriRef.
Questa regola è l'unica, nel nostro sistema, che fa uso del predicato di
inclusione SI `OWL TN <: TN′ . Stabilire se un tipo TN è un sottotipo di
TN′, è un problema tipico della teoria dei tipi. In questo lavoro non viene
approfondito, delegando la sua risoluzione ad un ragionatore OWL.
(TypeConstructTemplatePredicateConstant)
S = Dom(IriRef, SI) W = Range(IriRef, SI)
TR `V gt s : TN1 TR `V gt o : TN2
SI `OWL TN1 <: ∩I∈SofType(I) SI `OWL TN2 <: ∩I∈WofType(I)
SI, TR `Ct s IriRef o : {IriRef}
Regola TypeConstructTemplatePredicateVariable
Questa regola viene applicata ad un template (s ?var p), dove ?var
è una variabile. Se nel tipo relazione TR, la variabile ?var ha un tipo
nodo {IriRef1,. . . ,IriRefn}, allora si applicata la regola TypeConstruct-
TemplatePredicateConstant ai template (s IriRef1 o). . . (s IriRefn o).
(TypeConstructTemplatePredicateVariable)
TR(?var) = TN SI `OWL TN :=: {IriRef1, . . . , IriRefn}∀i = 1...n SI, TR `Ct s IriRefi o : {IriRefi}
SI, TR `Ct s ?var o : {IriRef1} ∪ . . . ∪ {IriRefn}
Da notare l'utilizzato dell'applicazione funzione su un tipo TR. La pre-
messa TR(?var) è vera se e solo se ?var appartiene al dominio di TR. Il
predicato SI `OWL TN :=: {IriRef1, . . . , IriRefn} assicura che il tipo di
?var sia e�ettivamente un tipo unione di IriRef. Anche questa veri�ca viene
delegata al ragionate OWL.
CAPITOLO 3. SISTEMA DI TIPI 83
Regola TypeConstructTemplateUnion
Il tipo dell'unione di due gra� corrisponde all'unione tra il tipo del primo
grafo, costruito con il template Triple, e il tipo del secondo grafo, costruito
con il template Triple*.
(Regola TypeConstructTemplateUnion)
SI, TR `Ct Triple : TG1 SI, TR `Ct Triple∗ : TG2
SI, TR `Cc Triple.T riple∗ : TG1 ∪ TG2
3.6.7 Regole AskQuery
Un AskQuery ritorna un booleano in tutti i casi in cui la DatasetClause
e la WhereClause sono corrette.
(TypeAskQuery)
SI,NG `Dc DatasetClause : NG′, TG
SI,NG′, TG `Wc WhereClause : TR
SI,NG `Aq askDatasetClause WhereClause : Bool
3.6.8 Regole DatasetClause
Il tipo associato ad una DatasetClause è una coppia che identi�ca il tipo
dell'ambiente di esecuzione del corpo della query. Ricordiamo che questo
tipo è costituito dal prodotto cartesiano tra un tipo NG, che identi�ca il tipo
dell'ambiente dei gra� ristretto rispetto l'ambiente iniziale, e un tipo TG, che
identi�ca il tipo del grafo di default. Il tipo ritornato dalla DatasetClause
viene de�nito man mano che si valutano tutte le clausola from, espandendo
il tipo del grafo di default attraverso l'unione di tipi TG, e from named,
restringendo l'insieme dei named graph su cui eseguire il corpo della query.
Nella regola TypeFromEmpty ritorna una coppia (ε, ε), la prima com-
ponente della coppia denota la funzione con dominio vuoto, mentre la seconda
componente denota il tipo TG del grafo vuoto.
CAPITOLO 3. SISTEMA DI TIPI 84
(TypeFromEmpty)
SI,NG `Dc ε : ε, ε
(TypeFrom)
SI,NG `Dc DatasetClause : NG′, TG′
IriRef : NameOf(TG) ∈ NGSI,NG `Dc from IriRef DatasetClause : NG′, TG ∪ TG′
(TypeFromNamed)
SI,NG `Dc DatasetClause : NG′, TG′
IriRef : NameOf(TG) ∈ NGNG `Dc from named IriRef DatasetClause :
(NG′, IriRef : nameOf(TG)), TG′
3.6.9 Regole Triple
Dato un triple pattern e un ambiente di valutazione (SI, NG, TG), una re-
gola �triple� restituisce un tipo relazione TR, che descrive le relazioni prodotte
dal matching del triple pattern con l'ambiente di valutazione. Sono state de-
�nite tre regole di tipo: la prima regola viene applicata in presenza di un tipo
grafo generico T_IRI; in presenza di un tipo grafo {IriRef1}∪ . . .∪{IriRefn},applichiamo la seconda regola a triple patterns con predicati speci�cati e la
terza regola a triple pattern con variabili in posizione di predicato.
Regola TypeTripleAny
Questa regola restituisce il tipo di una relazione in cui il soggetto, predica-
to e oggetto del triple pattern hanno un tipo generico, in quanto dall'ambiente
di valutazione non riusciamo a ricavare alcuna informazione di tipo.
(TypeTripleVarAny)
SI,NG,T_IRI`Tp s p o: [ s:TN_Any , p:T_IRI , o:TN_Any ]
CAPITOLO 3. SISTEMA DI TIPI 85
Regola TypeTriple1
Questa regola restituisce il tipo relazione che associa ad ogni termine del
triple pattern (s IriRef o) un tipo che viene estratto dal predicato IriRef
speci�cato. Tra le premesse della regola di inferenza viene testato se il tipo
del predicato è contenuto nel tipo TG.
(TypeTriple1)
S = Dom({IriRef}, SI)
W = Range({IriRef}, SI)
{IriRef} ∈ {IriRef1} ∪ . . . ∪ {IriRefn}SI,NG, {IriRef1} ∪ . . . ∪ {IriRefn} `Tp s IriRef o :
[s : ∩(y∈S)ofType(y) , IriRef : {IriRef} , o : ∩(y∈W )ofType(y)]
Regola TypeTriple2
Questa regola restituisce il tipo relazione che associa ad ogni termine del
triple pattern (s ?var o) informazioni di tipo estratte dal tipo grafo TG.
(TypeTriple2)
S = {Dom(I, SI) | I ∈ TG}W = {Range(I, SI) | I ∈ TG}
TG = {IriRef1} ∪ . . . ∪ {IriRefn}SI,NG, TG `Tp s ?var o :
[s : ∪S∈S ∩(y∈S) ofType(y) , ?var : TG , o : ∪W∈W ∩(y∈W ) ofType(y)]
3.6.10 Regole VarOrGTerm
Data una variabile e un tipo relazione TR viene ritornato il tipo nodo
associato alla variabile nella relazione. Se la variabile non è de�nita nel tipo
relazione, la regola non viene applicata.
(TypeVarOrGTermVar)
V ar ∈ Dom(TR)
TR `V gt V ar : TR(V ar)
CAPITOLO 3. SISTEMA DI TIPI 86
Dato un GraphTerm e un tipo relazione TR viene ritornato il tipo nodo
associato al GraphTerm nella relazione. Nelle de�nizioni seguenti utilizziamo
l'operatore binario -[-], de�nito nel capitolo precedente. Da notare anche
l'utilizzo del predicato SI `OWL TN1 ∩ TN2 :6=: ∅ tra le premesse della
regola TypeVarOrGTermIri,TypeVarOrGTermBNode. La veridicità
di questo predicato, stabilita da un ragionatore OWL, ci assicura che IriRef o
il nodo blank in TR è ben tipato (non sono presenti incompatibilità di tipo).
(TypeVarOrGTermIri)
SI `OWL {IriRef} ∩ TR[IriRef ] :6=: ∅TR `V gt IriRef : {IriRef} ∩ TR[IriRef ]
(TypeVarOrGTermBNode)
SI `OWL {IriRef} ∩ TR[bn] :6=: ∅TR `V gt bn : T_BNode ∩ TR[bn]
(TypeVarOrGTermLiteral)
TR `V gt lit : {lit}
3.6.11 Regole WhereClause
Il tipo associato ad un WhereClause è dato dal tipo associato al GP
valutato sullo stesso ambiente.
(TypeWhere)
SI,NG, TG `Gp GP : TR
SI,NG, TG `Wc where GP : TR
3.6.12 Regole Graph Pattern
Dato un graph pattern e un ambiente di valutazione viene ritornato un
tipo relazione TR.
CAPITOLO 3. SISTEMA DI TIPI 87
La regola TypeGpEmpty a�erma che il tipo associato ad un graph
pattern vuoto è la relazione vuota.
Le regole TypeGpAND,TypeGpOpt,TypeGpUnion mostrano i tipi
della combinazione di graph pattern. L'and di due graph pattern comporta
la giunzione dei tipi, l'opzionalità di un pattern comporta la giunzione esterna
e l'unione di pattern comporta l'unione dei tipi. La giunzione, la giunzione
esterna e l'unione dei tipi è de�nita a livello sintattico.
La giunzione di due tipi relazione TR e�ettua l'intersezione dei tipi dei
termini che appaiono in entrambe le triple. Se le informazioni di tipo derivanti
dalla valutazione delle triple danno informazioni contraddittorie su di una
variabile o costante, questa intersezione risulta vuota. In questo caso la
regola ritorna un errore, dato che la premessa
SI 0OWLand(TR1,TR2):=:∅
risulterebbe falsa. Questa premessa è stata de�nita in modo da mettere
in evidenza l'approccio ottimistico utilizzato per queste regole: ovvero il
predicato è vero se non riusciamo a dimostrare che l'intersezione è vuota e
quindi non riusciamo a dimostrare l'incompatibilità di tipi.
La regola TypeGpFilter è stata de�nita in modo tale da non modi�care
il tipo di una tabella, dopo che a questa viene applicato un �ltro. Il �ltro
non modi�ca lo schema della tabella, ma ne riduce il numero di record.
La regola TypeGpTriple ritorna il tipo relazione risultato dalla va-
lutazione del triple pattern che costituisce il graph pattern. Il predica-
to SI0OWLand(TR,TR(SI)):=:∅ è stato introdotto per veri�care se il tipo
relazione restituito dalla valutazione di un triple pattern rispetta le infor-
mazioni di tipo presenti nello ELOSchema a livello le costanti. Il tipo re-
lazione, TR(SI), contiene i tipi di tutte le costanti de�niti con asserzioni
ClassAssertion(IriRef1, IriRef2).
TR(SI) = {[IriRefi : {IriRefi}]| ClassAssertion(IriRefi,_) ∈ SI}
L'operazione di giunzione and(TR,TR(SI)) genera un errore se e solo se in
TR è stato de�nito il tipo di una costante incompatibile con quanto speci�-
cato nello ELOSchema.
CAPITOLO 3. SISTEMA DI TIPI 88
(TypeGpEmpty)
SI,NG, TG `Gp {} : []
(TypeGpTriple)
SI,NG, TG `Tp Triple : TR SI 0OWL and(TR, TR(SI)) :=: ∅SI,NG, TG `Gp Triple : TR
(TypeGpUnion)
SI,NG, TG `Gp GP1 : TR1 SI,NG, TG `GP GP2 : TR2
SI,NG, TG `Gp GP1 union GP2 : union(TR1, TR2)
(TypeGpAnd)
SI,NG, TG `Gp GP1 : TR1 SI,NG, TG `GP GP2 : TR2
SI 0OWL and(TR1, TR2) :=: ∅SI,NG, TG `Gp GP1 . GP2 : and(TR1, TR2)
(TypeGpOpt)
SI,NG, TG `Gp GP1 : TR1 SI,NG, TG `GP GP2 : TR2
SI,NG, TG `Gp GP1 opt GP2 : opt(TR1, TR2)
(TypeGpFilter)
SI,NG, TG `Gp GP : TR TR `V c V C : BOOL
SI,NG, TG `Gp GP filter V C : TR
Le regole TypeGpIriGraph e TypeGpVarGraph riguardano l'esecu-
zione di un graph pattern su un grafo diverso da quello di default. Nella
prima regola il graph pattern viene eseguito su un unico grafo di tipo TG1
CAPITOLO 3. SISTEMA DI TIPI 89
speci�cato nell'ambiente di valutazione di GP. La seconda regola permette
di stabilire il tipo del risultato dell'esecuzione di un graph pattern su un in-
sieme �nito di tipi gra�. Nella regola il tipo di questo insieme �nito è dato
dall'unione di tutti i tipi grafo contenuti nel tipo ambiente named graph NG.
(TypeGpIriGraph)
IriRef : nameOf(TG1) ∈ NG SI,NG, TG1 `Gp GP : TR
SI,NG, TG `Gp IriRef graph GP : TR
(TypeGpVarGraph)
SI,NG,∪i∈Dom(NG)NG[i] `Gp GP : TR
SI,NG, TG `Gp V ar graph GP : and([V ar : Dom(NG)], TR)
3.6.13 Regole ValueC
Le regole ValueC veri�cano che gli operandi del confronto abbiano un
tipo corretto e , in questo caso, restituiremo un booleano.
Per i value constraint che utilizzano gli operatori di confronto binari OP,
noi assumiamo una funzione booleana areCompatibleType che stabilisce se i
tipi TN1 e TN2 sono compatibili con OP. Per gli operatori booleani chiediamo
che gli operandi siano booleani. Gli altri operatori non pongono vincoli sugli
operandi.
(TypeVcOp)
TR `V gt?v : TN1 TR `V gt vgt : TN2
areCompatibleType(OP, TN1, TN2)
TR `V c?var OP vgt : Bool
(TypeVcisIri)TR `V gt?var : TN
TR `V c isIri(?var) : Bool
CAPITOLO 3. SISTEMA DI TIPI 90
(TypeVcisLiteral)
TR `V gt?var : TN
TR `V c isLiteral(?var) : Bool
(TypeVcisBlank)
TR `V gt V ar : TN
TR `V c isBlank(?var) : Bool
(TypeVcbound)
TR `V gt?var : TN
TR `V c bound(?var) : Bool
(TypeVclangMatches)
TR `V gt?var1 : TN TR `V gt?var2 : TN
TR `V c langMatches(?var1,?var2) : Bool
(TypeVcsameTerm)
TR `V gt?var1 : TN TR `V gt?var2 : TN
TR `V c sameTerm(?var1,?var2) : Bool
(TypeNotVc)TR `V c V c : Bool
TR `V c ¬V c : Bool
(TypeVcand)
TR `V c V c1 : Bool TR `V c V c2 : Bool
TR `V c V c1 ∧ V c2 : Bool
(TypeVcor)
TR `V c V c1 : Bool TR `V c V c2 : Bool
TR `V c V c1 ∨ V c2 : Bool
Capitolo 4
Proprietà di soundness
L'obiettivo del nostro sistema dei tipi è garantire che l'esecuzione di una
query generi risultati ben tipati. Il sistema si occupa di inferire le frasi di
una query e rilevare eventuali inconsistenze di tipo. Sono considerate corrette
tutte le query che non presentano queste incosistenze.
La correttezza dei tipi inferiti viene espressa mediante un insieme di
proprietà che hanno la seguente struttura.
Schema di proprietà (Upper Bound)
Per ogni tipo ambiente Γ, per ogni ambiente %, per ogni query Q:
Γ ` Q : T ⇒ % ∈ JΓK . JQK% ∈ JT K%
Questo schema di proprietà assume, per i diversi giudizi presentati, le
seguenti forme:
Soundness SelectQuery
SI,NG `Sq SelectQuery : TR ⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%. JSelectQueryK
Sq%′ ⊆ JTRKtrτ,ϕ,%′
Soundness SelectClause
TR `Sc SelectClause : TR′ ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JSelectClauseKScr ⊆ JTR′Ktrτ,ϕ,%
91
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 92
Soundness ConstructQuery
SI,NG `Cq ConstructQuery : TG ⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%. JConstructQueryK
Cq%′ ∈ JTGKtgτ,ϕ,%′
Soundness ConstructClause
SI,TR `Cc ConstructClause : TG ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JConstructClauseKCcr ∈ JTGKtgτ,ϕ,%
Soundness ConstructTemplate
SI,TR `Ct ConstructTemplate : TG ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JConstructTemplateKCtr ∈ JTGKtgτ,ϕ,%
Soundness AskQuery
SI,NG `Aq AskQuery : Bool ⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%. JAskQueryK
Aq%′ ∈ JBoolK
Soundness DatasetClause
SI,NG `Dc DatasetClause : NG′,TG ⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
JDatasetClauseKDc%′ ∈ JNG′Kngτ,ϕ,%′ × JTGKtgτ,ϕ,%′
Soundness Triple
SI,NG,TG `Tp Triple : TR ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,%× JTGKtgτ,ϕ,%. JTripleK
Tp%′,δ ⊆ JTRKtrτ,ϕ,%′
Soundness VarOrGTerm
TR `V gt VarOrGTerm : TN ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.∀t ∈ r. JVarOrGTermKV gtt ∈ JTNKtnτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 93
Soundness WhereClause
SI,NG,TG `Wc WhereClause : TR ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
JWhereClauseKWc%′,δ ⊆ JTRKtrτ,ϕ,%′
Soundness GP
SI,NG,TG `Gp GP : TR ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGPKGp%′,δ ⊆ JTRKtrτ,ϕ,%′
Soundness ValueC
TR `V c ValueC : Bool ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JValueCKV cr ∈ JBoolK
Nella de�nizione delle regole di inferenza abbiamo fatto uso di predicati
della forma �SI`OWL . . .�.Nelle dimostrazioni della proprietà di soundness
assumeremo che il ragionatore OWL garantisca le seguenti proprietà:
Soundness TN1<:TN2
SI `OWL TN1<:TN2 =
∀τ, ϕ, % ∈M(SI). JTN1Ktnτ,ϕ,% ⊆ JTN2Ktnτ,ϕ,%
Soundness TN1:=:TN2
SI `OWL TN1:=:TN2 =
∀τ, ϕ, % ∈M(SI). JTN1Ktnτ,ϕ,% = JTN2Ktnτ,ϕ,%
Soundness TR:=:ε
SI `OWL TR:=:ε =
∀τ, ϕ, % ∈M(SI). JTRKtrτ,ϕ,% = JεKtrτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 94
4.1 Note preliminari
Ai �ni della dimostrazione della proprietà di soundness introduciamo al-
cune osservazioni generali sull'ambiente di valutazione tipizzato. La seman-
tica delle clausola from named, preso un ambiente di valutazione tipizzato
appartenente aM(SI), restringe la de�nizione dell'ambiente prede�nito dei
named graph % ai soli nomi citati nella query. Un primo lemma di interes-
se generale ci dice che tale restrinzione ritorna un ambiente di valutazione
tipizzato che ancora appartiene aM(SI).
Lemma 4.1
∀NG, ∀SI,∀ (τ, ϕ, %) ∈M(SI), ∀ %′ ∈ JNGKngτ,ϕ,%. (τ, ϕ, %′) ∈M(SI)
Dimostrazione. Per costruzione, ogni elemento del dominio di %′ appartiene
anche al dominio di %, ovvero:
∀ i. i ∈ dom(%′) ⇒ i ∈ dom(%)
La tesi segue immediatamente dalla de�nizione di modelloM(SI) di seguito
riportata:
M(SI) = {(τ, ϕ, %) | τ ∈ TEnv, ϕ = JSIKsi, ∀ i ∈ dom(%). %(i) |=OWL τ, ϕ}
Un lemma analogo vale per i tipi relazione, i quali, a seguito di una restrizione
di %, decrescono.
Lemma 4.2
%′ ⊆ % ⇒ ∀ TR . JTRKtrτ,ϕ,%′ ⊆ JTRKtrτ,ϕ,%
Dimostrazione. Vogliamo dimostrare la monotonia dei tipi TR rispetto l'am-
biente di valutazione tipizzato. Dalla semantica dei tipi TR si osserva che
essi sono monotoni rispetto alle componenti TN.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 95
La dimostrazione di monotonia dei tipi TN viene data per induzione strut-
turale. I tipi nodi T_IRI, T_RDFLiteral, T_BNode, {IriRef}, {lit}
e ofType({IriRef}) sono banalmente monotoni in %, dato che non dipen-
do da %. L'unione e la disgiunzione dei tipi TN sono monotone, in quanto
monotone le operazioni di unione e disgiunzione. L'unico caso interessante
riguarda la dimostrazione di monotonia dei tipo nameOf(TG). Vogliamo
dimostrare:
%′ ⊆ %⇒ JnameOf(TG)Ktnτ,ϕ,%′ ⊆ JnameOf(TG)Ktnτ,ϕ,%
ovvero:
IriRef ∈ JnameOf(TG)Ktnτ,ϕ,%′ ⇒ IriRef ∈ JnameOf(TG)Ktnτ,ϕ,%
Assumiamo le premesse, per de�nizione di JnameOf(TG)Ktnτ,ϕ,%′ :
i ∈ dom(%′) ∧ %′(i) ∈ JTGKtgτ,ϕ,%′
Dal lemma 4.1,sappiamo che:
∀ i. i ∈ dom(%′) ⇒ i ∈ dom(%)
Possiamo concludere, visto che la semantica dei tipi TG non dipende dalla
componente %, che:
%(i) ∈ JTGKtgτ,ϕ,%
La semantica del linguaggio utilizza spesso operazioni di ridenominazione
di nodi blank. Dobbiamo dimostrare che queste ridenominazioni non in-
�uenzano la corretteza dei giudizi di tipo. A questo scopo introduciamo una
nozione di equivalenza dei nodi blank rispetto ai tipi. Le ridenominazione
che rispettano questa equivalenza possono essere applicate liberamente.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 96
De�nizione 4.1
Due nodi blank _:a e _:b sono in relazione di equivalenza ∼τ ovvero:
_:a ∼τ_:b ⇒ ∀i . _:a ∈ τ(i) ⇔ _:b ∈ τ(i)
Estendiamo questa relazione di equivalenza ai record di una relazione.
De�nizione 4.2
Due record t e t′ sono in relazione di equivalenza ∼τ se e solo se presentano
le stesse variabili, gli stessi IriRef, gli stessi literal e presentano nodi blank
in relazione di equivalenza ∼τ , ovvero
t ∼τ t′ ⇔ dom(t) = dom(t′)
∀ g ∈ dom(t) . t[g] ∼τ t′[g],
Da questa de�nizione segue immediatamente che
t ∼τ t′ ⇒ ∀g . t[g] ∼τ t′[g]
Estendiamo questa relazione di equivalente alle relazioni.
De�nizione 4.3
Due tabelle r e r′ sono in relazione di equivalenza ∼τ , se e solo se tutti i
record di r sono in relazione ∼τ con i record di r′, e viceversa.
r ∼τ r′ ⇔ ∀ t ∈ r . ∃ t′ ∈ r′ . t ∼τ t′,∀ t′ ∈ r′ . ∃ t ∈ r . t′ ∼τ t
A partire dalle de�nizioni appena presentate, dimostriamo una serie di
lemmi che ci assicurano l'invarianza del nostro sistema rispetto la ridenomi-
nazione dei blank nodes.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 97
Lemma 4.3
_:a ∈ JTNKtnτ,ϕ,% ∧ _:a ∼τ_:b ⇒ _:b ∈ JTNKtnτ,ϕ,%
Dimostrazione. Assumiamo le premesse e dimostriamo la tesi per ogni tipo
TN che può assumere il blank node _:a
(a) _:a ∈ J T_BNodeKtnτ,ϕ,%, la tesi segue banalmente perchè ogni blank nodes
appartiene al dominio B;
(b) _:a ∈ J OfType(IriRef)Ktnτ,ϕ,%, la tesi segue dalla de�nizione 4.1;
L'unione e l'intersezione tra i tipi de�niti in (a) e (b) soddisfano banalmente
la tesi. Un blank nodes in un ambiente di valutazione tipizzato può assumere
esclusivamente questi tipi.
Lemma 4.4
t ∈ JTRKtrτ,ϕ,% ∧ t′ ∼τ t ⇒ t′ ∈ JTRKtrτ,ϕ,%
Dimostrazione. Sia
TR = [V1 : TN1]× . . .× [Vn : TNn]
allora per de�nizione di t∈ JTRKtrτ,ϕ,% abbiamo che
dom(t) = {V1 . . . Vm} ∧ ∀i = 1 . . . n . t(Vi) ∈ JTNiKtnτ,ϕ,%
Dato che t′ ∼τ t, dal lemma 4.3 segue che:
∀i = 1 . . . n . t′(Vi) ∈ JTNiKtnτ,ϕ,%
ovvero t′ ∈ JTRKtrτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 98
Lemma 4.5
JsKV gtt ∈ JTNKtnτ,ϕ,% ∧ t ∼τ t′ ⇒ JsKV gtt′ ∈ JTNKtnτ,ϕ,%
Dimostrazione. Assumiamo le premesse e dimostriamo la tesi per ogni valore
che può assumere s:
JsKV gtτ,ϕ,%′ ∈ JTNKtnτ,ϕ,% ⇔ t[s] ∈ JTNKtnτ,ϕ,%per def. 4.2−−−−−−−→
t′[s] ∈ JTNKtnτ,ϕ,% ⇔ JsKV gtt′ ∈ JTNKtnτ,ϕ,%
Lemma 4.6
r ⊆ JTRKtrτ,ϕ,% ∧ r ∼τ r′ ⇒ r′ ⊆ JTRKtr
Dimostrazione. Vogliamo dimostrare che
t′ ∈ r′ ⇒ t′ ∈ JTRKtrτ,ϕ,%
Dalla de�nizione 4.3 sappiamo che
∀t′ ∈ r′ . ∃t ∈ r . t′ ∼τ t
Dato che
r ⊆ JTRKtrτ,ϕ,% ⇒ t ∈ JTRKtrτ,ϕ,%
Dal lemma 4.4 segue la tesi,
t′ ∈ JTRKtrτ,ϕ,%
.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 99
4.2 Dimostrazione proprietà di soundness
Nelle seguenti sottosezioni verrà dimostrata la soundness del sistema dei
tipi rispetto la semantica dei giudizi. In particolare dimostremo che, per ogni
regola, dalla validità delle premesse segue la validità della conseguenza. La
validità di un qualunque giudizio dimostrato segue da questa proprietà per
induzione.
4.2.1 Dimostrazione soundness SelectQuery
(TypeSelectQuery)
SI,NG `Dc DatasetClause : NG′, TG
SI,NG′, TG `Wc WhereClause : TR′
TR′ `Sc SelectClause : TR
SI,NG `Sq SelectClause DatasetClause WhereClause : TR
Dimostrazione. Si vuole dimostrare che
SI,NG `Sq SelectClause DatasetClause WhereClause:TR ⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
JSelectClause DatasetClause WhereClauseKSq%′ ⊆ JTRKtrτ,ϕ,%′
ovvero, per de�nizione di JSelectClause . . . KSq%′
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.(let (%1, δ) = JDatasetClauseKDc%′ ;let r = BlankRename(JWhereClauseKWc
%1,δ);
return JSelectClauseKScr)⊆ JTRKtrτ,ϕ,%′ .
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse
della regola di inferenza, ovvero
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
JDatasetClauseKDc%′ ∈ JNG′Kngτ,ϕ,%′ × JTGKtgτ,ϕ,%′ (a)
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 100
∀τ, ϕ, %′ ∈M(SI),∀(%′′, δ′′) ∈ JNG′Kngτ,ϕ,%′ × JTGKtgτ,ϕ,%′ .
JWhereClauseKWc%′′,δ′′ ⊆ JTR′Ktrτ,ϕ,%′′ (b)
∀τ, ϕ, %′′ ∈ M(SI),∀r ∈ JTR′Ktrτ,ϕ,%′′ . JSelectClauseKScr ⊆ JTRKtrτ,ϕ,%′′ (c)
Istanziando le variabili di (b), ponendo %′′ = %1 e δ′′ = δ, otteremo quidi
(%1, δ) ∈ JNG′Kngτ,ϕ,%′ × JTGKtgτ,ϕ,%′
r′ = JWhereClauseKWcτ,ϕ,%1
⊆ JTR′Ktrτ,ϕ,%1
La funzione BlankRename, può essere de�nita in modo da restituire una
relazione r, tale che r′ ∼τ r: essendo l'insieme dei blank nodes in�nito, pos-
siamo tranquillamente assumere che in τ sono presenti in�niti blank nodes
in relazione ∼τ con i blank nodes di r′. Dalle lemma 4.6 possiamo dedurre
che:
BlankRenameJWhereClauseKWcτ,ϕ,%1
⊆ JTR′Ktr(τ,ϕ,%1)
Dal lemma 4.1, l'ambiente dei named graph prodotto dalla DatasetClause è
tale che
%1 ⊆ %′
per cui dal lemma 4.2 sappiamo che
JTR′Ktrτ,ϕ,%1 ⊆ JTR′Ktrτ,ϕ,%′
Di conseguenza:
r = BlankRenameJWhereClauseKWcτ,ϕ,%1
⊆ JTR′Ktrτ,ϕ,%1 ⊆ JTR′Ktrτ,ϕ,%′
Istanziando le variabili di (c), ponendo % = %′ otteniamo
r⊆ JTR′Ktrτ.ϕ,%′
JSelectClauseKScr ⊆ JTRKtrτ.ϕ,%′
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 101
4.2.2 Dimostrazione soundness SelectClause
La selectClause prevede due regole di inferenza. La dimostrazione della pro-
prietà di soundness per la la regola TypeSelectClauseAll è immediata.
Di seguito verrà riportata la dimostrazione della soundness per la regola
TypeSelectClause
(TypeSelectClause)
TR `V gt ?vi : TNi ∀i = 1, . . . , n
TR `Sc select ?v1, . . . , ?vn : [?v1 : TN1 , . . . , ?vn : TNn]
Dimostrazione. Si vuole dimostrare che
TR `Sc select ?v1, . . . , ?vn : [?v1 : TN1 , . . . , ?vn : TNn]⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.
Jselect ?v1, . . . , ?vnKScr ⊆ J[?v1 : TN1, . . . , ?vn : TNn]Ktrτ,ϕ,%
ovvero, per de�nizione di Jselect . . . KScr ,
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.{[?v1 = t[?v1], . . . , ?vn = t[?vn]
]| t ∈ r
}⊆{
[?v1 = nodo1, . . . , ?vn = nodon]| nodoi ∈ JTNiKtnτ,ϕ,%}
Bisogna dimostrare che
∀r ⊆ JTRKtrτ,ϕ,% . ∀t ∈ r . ∀i = 1, . . . , n . t[?vi] ∈ JTNiKtnτ,ϕ,%
Per ipotesi sappiamo che la proprietà di soundness vale sulle n-premesse
della regola di inferenza. Dalla premessa i-esima sappiamo che
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. ∀t ∈ r. J?viKV gtt ∈ JTNiKtnτ,ϕ,%
ovvero
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. ∀t ∈ r. t[?vi] ∈ JTNiKtnτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 102
4.2.3 Dimostrazione soundness ConstructQuery
(TypeConstructQuery)
SI,NG `Dc DatasetClause : NG′, TG′
SI,NG′, TG′ `Wc WhereClause : TR
SI, TR `Cc ConstructClause : TG
SI,NG `Cq ConstructClause DatasetClause WhereClause : TG
Dimostrazione. Si vuole dimostrare che
SI,NG `Cq ConstructClause DatasetClause WhereClause:TG ⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
JConstructClause DatasetClause WhereClauseKCq%′ ∈ JTGKtgτ,ϕ,%′
ovvero, per de�nizione di JConstructClause . . . KCq%′ ,
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.(let (%1, δ) = JDatasetClauseKDc%′ ;
let r = BlankRename(JWhereClauseKWc%1,δ
);
return JConstructClauseKCcr)∈ JTGKtgτ,ϕ,%′
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse:
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
JDatasetClauseKDc%′ ∈ JNG′Kngτ,ϕ,%′ × JTG′Ktgτ,ϕ,%′ (a)
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNG′Kngτ,ϕ,% × JTG′Ktgτ,ϕ,%.
JWhereClauseKWc%′,δ ⊆ JTRKtrτ,ϕ,%′ (b)
∀τ, ϕ, % ∈ M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JConstructClauseKCcr ∈ JTGKtgτ,ϕ,% (c)
La proprietà è dimostrata istanziando banalmente queste forme semantiche,
come si è fatto per la SelectClause.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 103
4.2.4 Dimostrazione soundness ConstructClause
(TypeConstructClause)
SI, TR `Ct ConstructTemplate : TG
SI, TR `Cc construct ConstructTemplate : TG
Dimostrazione. Si vuole dimostrare che
SI,TR `Cc construct ConstructTemplate: TG ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.
Jconstruct ConstructTemplateKCcr ∈ JTGKtgτ,ϕ,%
ovvero, per de�nizione di J construct . . . KCcr ,
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JConstructTemplateKCtr ∈ JTGKtgτ,ϕ,%
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse
della regola di inferenza, di conseguenza
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JConstructTemplateKCtr ∈ JTGKtgτ,ϕ,%
ma questo era quello che volevamo dimostrare.
4.2.5 Dimostrazione soundness ConstructTemplate
Di seguito diamo una dimostrazione della proprietà di soundness per le
quattro regole di inferenza prevista dalla ConstructTemplate:
� TypeConstructTemplateEmpty
� TypeConstructTemplatePredicateConstant
� TypeConstructTemplatePredicateVariable
� TypeConstructTemplateUnion
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 104
Regola TypeConstructTemplateEmpty
(TypeConstructTemplateEmpty)
SI, TR `Ct ε : ε
Dimostrazione. Si vuole dimostrare che
SI,TR `Ct ε : ε ⇒ ∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JεKCtr ∈ JεKtgτ,ϕ,%
ovvero, per de�nizione diJεKCtr ,
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. ε ∈ {ε}
La dimostrazione segue immediatamente dalla de�nizione.
Regola TypeConstructTemplatePredicateConstant
(TypeConstructTemplatePredicateConstant)
S = Dom(IriRef, SI) W = Range(IriRef, SI)
TR `V gt s : TN1 TR `V gt o : TN2
SI `OWL TN1 <: ∩y∈SofType(y) SI `OWL TN2 <: ∩y∈WofType(y)
SI, TR `Ct s IriRef o : {IriRef}
Dimostrazione. Si vuole dimostrare che
SI,TR `Ct s IriRef o : {IriRef} ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. Js IriRef oKCtr ∈ J{IriRef}Ktgτ,ϕ,%
ovvero, per de�nizione di Js IriRef oKCtr
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 105
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.{⋃
t′∈rJsKV gtt′ JIriRefKV gtt′ JoKV gtt′
}∈
{γ | γ ⊆ (I∪B) × {IriRef} × T ∧ γ |=OWL τ, ϕ}
Dove t′ è in relazione ∼τ con il record t + [b1 = f t1, . . . , bn = f tn] utilizzato
nella semantica della ConstructTemplate. Il record t+ [b1 = f t1, . . . , bn = f tn]
è il prodotto della ridenominazione dei blank nodes del record t, mediante n
applicazioni della funzione iniettiva f , come speci�cato nel capitolo 2.
Bisogna dimostrare che:
1. le triple del grafo γ, che verrà costruito, abbiano un tipo contenuto nel
dominio (I∪B) × {IriRef} × T;
2. il grafo γ soddisfa il modello τ, ϕ.
La (1) è dimostrabile banalmente, essendo (I∪B) l'upper bound del tipo
di ogni soggetto, {IriRef} il tipo del predicato IriRef e T l'upper bound del
tipo di ogni oggetto.
La (2) è dimostrabile se e solo se ogni tripla che costituisce il grafo rispetti
lo ELOSchema, ovvero
∀ (s IriRef o) ∈ γ, ∀ y ∈ Dom (IriRef, SI) . s ∈ τ(y) ∧∀ y ∈ Range(IriRef, SI) . o ∈ τ(y)
Assumiamo le premesse:
� TR `V gt s : TN1
� TR `V gt o : TN2
� SI `OWLTN1<:∩y∈SofType(y)
� SI `OWLTN2<:∩y∈WofType(y)
possiamo concludere che:
s ∈ JTN1Ktnτ,ϕ,% ⇒ ∀ y ∈ S . s ∈ JofType(y)Ktnτ,ϕ,%o ∈ JTN2Ktnτ,ϕ,% ⇒ ∀ y ∈ W. o ∈ JofType(y)Ktnτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 106
Regola TypeConstructTemplatePredicateVariable
(TypeConstructTemplatePredicateVariable)
TR(?var) = TN SI `OWL TN :=: {IriRef1, . . . , IriRefn}∀i = 1...n SI, TR `Ct s IriRefi o : {IriRefi}
SI, TR `Ct s ?var o : {IriRef1} ∪ . . . ∪ {IriRefn}
Dimostrazione. Si vuole dimostrare che
SI,TR `Ct s ?var o : {IriRef1} ∪ . . . ∪ {IriRefn} ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.
Js ?var oKCtr ∈ J{IriRef1 ∪ . . .∪ IriRefn}Ktgτ,ϕ,%
ovvero, per de�nizione di Js ?var oKCtr
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.{⋃t∈rJsK
V gtt J?varKV gtt JoKV gtt
}∈ J{IriRef1 ∪ . . . ∪ IriRefn}Ktgτ,ϕ,%
Dalle premesse della regola di inferenza sappiamo che la variabile ?var ha
il seguente tipo nodo: {IriRef1, . . . , IriRefn}. Di conseguenza, sappiamo
che il grafo generato con il template (s ?var o) ha una delle seguenti forme
(s IriRef1 o), . . . , (s IriRefn o). Per ogni (s IriRefi o), veri�chiamo che il
grafo generato abbia tipo atomico {IriRefi}, ovvero
SI,TR`Ct s IriRefi o : {IriRefi} ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. Js IriRefi oKCtr ∈ J{IriRefi}Ktgτ,ϕ,%
ma questo è vero, in quanto valida, per ipotesi, la proprietà di soundness
sulla premessa.
Questa proprietà garantisce anche che ogni grafo costruito con il template
{s IriRefi o} soddisfa lo ELOSchema. Ogni tripla generata dalla valutazione
di (s ?var o) appartiene ad un tipo grafo J{IriRefi}Ktgτ,ϕ,%, per un qualche
i ∈ 1 . . . n, quindi per de�nizione di unione dei tipi gra� possiamo concludere
a�ermando che:
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 107
J{IriRefi}Ktgτ,%,ϕ ⊆ J{IriRef1} ∪ . . . ∪ {IriRefn}Ktgτ,ϕ,%
Regola TypeConstructTemplateUnion
(TypeConstructTemplateUnion)
SI, TR `Ct Triple : TG1 SI, TR `Ct Triple∗ : TG2
SI, TR `Cc Triple.T riple∗ : TG1 ∪ TG2
Dimostrazione. Si vuole dimostrare che
SI,TR `Ct Triple.Triple*: TG1 ∪ TG2 ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JTriple.Triple*KCtr ∈ JTG1 ∪ TG2Ktgτ,ϕ,%
ovvero, per de�nizione di J triple.triple* KCtr
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.(JTripleKCtr
⋃JTriple*KCtr
)∈ JTG1 ∪ TG2Ktgτ,ϕ,%
Per ipotesi, la proprietà di soundness è soddisfatta dalle premesse della regola
di inferenza ovvero:
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JTripleKCtr ∈ JTG1Ktgτ,ϕ,%∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JTriple*KCtr ∈ JTG2Ktgτ,ϕ,%
La tesi segue dalla semantica dell'unione dei tipi gra�.
4.2.6 Dimostrazione soundness AskQuery
(TypeAskQuery)
SI,NG `Dc DatasetClause : NG′, TG
SI,NG′, TG `Wc WhereClause : TR
SI,NG `Aq ask DatasetClause WhereClause : Bool
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 108
Dimostrazione. Si vuole dimostrare che
SI,NG `Aqask DatasetClause WhereClause : Bool⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
Jask DatasetClause WhereClauseKAq%′ ∈ JBoolK
ovvero, per de�nizione di Jask . . . KAq%′
∀%, ∀ϕ = JSIKsi,∀%′ ∈ JNGKng%,ϕ.(let (%1, δ) = JDatasetClauseKDc%′ ;
let r = BlankRename(JWhereClauseKWc%1,δ
);
return r 6= [])∈ JBoolK.
La tesi segue immediatamente dalla de�nizione, in quanto (r 6= []) è un'e-
spressione booleana. Per induzione sulle premesse delle regole sappiamo che
la relazione r può essere utilizzata nel test, in quanto ben tipata.
4.2.7 Dimostrazione soundness DatasetClause
La DatasetClause prevede diverse regole di inferenza.
Regola TypeFromEmpty
(TypeFromEmpty)
SI,NG `Dc ε : (ε, ε)
Dimostrazione. Si vuole dimostrare che
SI,NG `Dc ε : (ε,ε)⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%. JεKDc%′ ∈ JεKngτ,ϕ,%′ × JεKtgτ,ϕ,%′
ovvero, per de�nizione di JεKDc%′
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.(ε, ε)∈ {ε} × {ε}
La dimostrazione segue direttamente dalla de�nizione
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 109
Regola TypeFrom
(TypeFrom)
SI,NG `Dc DatasetClause : NG′, TG′
IriRef : nameOf(TG) ∈ NGSI,NG `Dc from IriRef DatasetClause : NG′, TG ∪ TG′
Dimostrazione. Si vuole dimostrare che
SI,NG `Dc from IriRef DatasetClause : NG′,TG∪TG′ ⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
Jfrom IriRef DatasetClauseKDc%′ ∈ JNG′Kngτ,ϕ,%′ × JTG∪TG′Ktgτ,ϕ,%′
ovvero, per de�nizione di Jfrom IriRef DatasetClauseKDc%′
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.(π1(JDatasetClauseKDc%′ ) , π2(JDatasetClauseKDc%′ ) ∪ %′(IriRef)
)∈ JNG′Kngτ,ϕ,%′ × JTG∪TG′Ktgτ,ϕ,%′
Per ipotesi sappiamo che la proprietà di soundness è valida per la premessa
della regola di inferenza:
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.JDatasetClauseKDc%′ ∈ JNG′Kngτ,ϕ,%′ × JTG′Ktgτ,ϕ,%′
Dalla premessa IriRef:nameOf(TG)∈ NG, per de�nizione di JNGKngτ,ϕ,%, sap-piamo che IriRef, nel tipo ambiente named graph, denota un tipo grafo TG,
ovvero:
∀(τ, ϕ, %) ∈M(SI).∀%′ ∈ JNGKngτ,ϕ,%.%′(IriRef)∈ JTGKtgτ,ϕ,%′
La proprietà è dimostrata combinando le due informazioni ed applicando la
semantica dell'unione dei tipi grafo:
π1(JDatasetClauseKDc%′ ∈ JNG′Kngτ,ϕ,%′π2(JDatasetClauseKDc%′ )∪ %′(IriRef)∈ JTG′Ktgτ.ϕ,%′ ∪ JTGKngτ,ϕ,%′
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 110
Regola TypeFromNamed
(TypeFromNamed)
SI,NG `Dc DatasetClause : NG′, TG′
IriRef : nameOf(TG) ∈ NGNG `Dc from named IriRef DatasetClause :
(NG′, IriRef : nameOf(TG)), TG′
Dimostrazione. Si vuole dimostrare che
SI,NG `Dc from named IriRef DatasetClause:
(NG',IriRef:nameOf(TG)),TG'⇒∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.
Jfrom named IriRef DatasetClauseKDc%′ ∈JNG′,IriRef:nameOf(TG)Kngτ,ϕ,%′ × JTG′Ktgτ,ϕ,%′
ovvero, per de�nizione di Jfrom named IriRef DatasetClauseKDc%′
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.(π1(JDatasetClauseKDc%′ )++[IriRef:%′(IriRef)], π2(JDatasetClauseKDc%′ )
)∈(
JNG′Kngτ,ϕ,%′ ××{[IriRef=γ] |γ ∈ JTGKtgτ,ϕ,%′})×JTG'Ktgτ,ϕ,%′
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse
della regola di inferenza, ovvero
∀τ, ϕ, % ∈M(SI),∀%′ ∈ JNGKngτ,ϕ,%.JDatasetClauseKDc%′ ∈ JNG′Kngτ,ϕ,%′ × JTG′Ktgτ,ϕ,%′
Dalla premessa IriRef : nameOf(TG) ∈ NG sappiamo che
∀(τ, ϕ, %) ∈M(SI).∀%′ ∈ JNGKngτ,ϕ,%. %′(IriRef) ∈ JTGKtgτ,ϕ,%′
La proprietà è dimostrata combinando le due informazioni ed in particolare
osservando che:
π1(JDatasetClauseKDc%′ ) ∈ JNG′Kngτ,ϕ,%′
[IriRef : %′(IriRef)] ∈ {[IriRef : γ] | γ ∈ JTGKtgτ,ϕ,%′}
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 111
4.2.8 Dimostrazione soundness Triple
Consideriamo le tre regole di inferenza de�nite per i triple pattern.
Regola TypeTripleAny
(TypeTripleAny)
SI,NG,T_Iri`Tp s p o : [ s:T_Any , p:T_Iri , o:T_Any ]
Dimostrazione. Si vuole dimostrare che
SI,NG,T_Iri `Tp s p o : [ s:T_Any , p:T_Iri , o:T_Any ]⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,% . Js p oKTp%′,δ ∈
J[ s:T_Any, p:T_Iri, o:T_Any ]Ktrτ,ϕ,%′
ovvero, per de�nizione di Js p oKTp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.π(s,p,o)(JsKt1%′,δ 1 JpKt2%′,δ 1 JoKt3%′,δ) ∈
J[ s : T_Any , p : T_Iri , o : T_Any ]Ktrτ,ϕ,%′
Chiamiamo r la seguente tabella:
r = π(s,p,o)(JsKt1%′,δ 1 JpKt2%′,δ 1 JoKt3%′,δ)
r è una tabella con uno schema costituito dalle variabili s, p, o. Per co-
struzione, JpKt2%′,δ associa a p un IriRef presente nell'active graph δ in po-
sizione di predicato, per cui ogni elemento, per cui ogni ennupla t∈r avràt(p)∈IriRefSet.
Dobbiamo dimostrare che il tipo di r sia contenuto nel tipo
[s : T_Any, p : T_Iri, o : T_Any]
Questo è vero perchè T_Any è un upper bound per qualsiasi tipo soggetto,
T_Iri è un upper bound per qualsiasi tipo predicato e T_Any è un upper
bound per qualsiasi tipo oggetto
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 112
Regola TypeTriple1
(TypeTriple1)
S = Dom({IriRef}, SI)
W = Range({IriRef}, SI)
IriRef ∈ {IriRef1} ∪ . . . ∪ {IriRefn}SI,NG, {IriRef1} ∪ . . . ∪ {IriRefn} `Tp s IriRef o :
[s : ∩y∈SofType(y) , IriRef:{IriRef} , o: ∩y∈WofType(y)]
Dimostrazione. Si vuole dimostrare che
SI,NG,{IriRef1}∪. . .∪{IriRefn} `Tp s IriRef o:[s : ∩y∈SofType(y), IriRef : {IriRef}, o : ∩y∈WofType(y)]⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × J{IriRef1}∪. . .∪{IriRefn}Ktgτ,ϕ,%.
Js IriRef oKTp%′,δ ∈J[s: ∩y∈SofType(y) , IriRef:{IriRef} , o : ∩y∈WofType(y)]Ktrτ,ϕ,%′
ovvero, per de�nizione di Js IriRef oKTp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × J{IriRef1}∪. . .∪{IriRefn}Ktgτ,ϕ,%.π(s,IriRef,o)(JsKt1%′,δ 1 JIriRefKt2%′,δ 1 JoKt3%′,δ) ∈
J[s: ∩y∈SofType(y) , IriRef:{IriRef} , o:∩y∈WofType(y)]Ktrτ,ϕ,%′
Chiamiamo r la seguente tabella, data dalla giunzione delle seguenti relazioni:
r = π(s,IriRef,o)(JsKt1%′,δ 1 JIriRefKt2%′,δ 1 JoKt3%′,δ)
Consideriamo le tre relazioni separatamente e notiamo che ogni record di
ogni tabella è il risultato di un matching della tripla con l'active graph δ.
� JsKt1%′,δ = {[s=g1; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}
� JIriRefKt2%′,δ = {[1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ ∧ g2=IriRef }
� JoKt3%′,δ = {[o=g3; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 113
Nello speci�co dobbiamo dimostrare che ∀ t ∈ r, si ha:
(1) t[s] ∈ J∩y∈SofType(y)Ktnτ,ϕ,%′
(2) t[IriRef] ∈ J{IriRef}Ktnτ,ϕ,%′
(3) t[o] ∈ J∩y∈WofType(y)Ktnτ,ϕ,%′
La (2) è immediata.
Di seguito diamo una dimostrazione della (1), la dimostrazione della (3) è
analoga. Sappiamo che ogni riga t della relazione r è in corrispondenza con
una tripla di δ, (g1 g2 g3) , tale che t(s)=g1, t(IriRef)=g2=IriRef, t(o)=g3.
Possiamo dimostrare (1) dimostrando che per ogni tripla g1,g2,g3 che match
(s IriRef o), vale che
g1 ∈ J∩y∈SofType(y)Ktnτ,ϕ,%
Sappiamo che l'active graph δ per de�nizione soddisfa lo ELOSchema e in
particolare soddisfa la tipizzazione delle costanti:
δ |=OWL τ ⇔ ∀ (g1 g2 g3) ∈ δ . ∀ y ∈ Dom (g2, SI)⇒ g1 ∈ τ(y) ∧
∀ (g1 g2 g3) ∈ δ . ∀ y ∈ Range(g2, SI)⇒ g3 ∈ τ(y)
Essendo il predicato speci�cato, possiamo dedurre che
∀y ∈ Dom(IriRef, SI). g1 ∈ τ(y)per definizione di OfType−−−−−−−−−−−−−−−−→
∀y ∈ Dom(IriRef, SI). g1 ∈ JofType(y)Ktnτ,ϕ,%per definizione di S−−−−−−−−−−−−→
∀y ∈ S. g1 ∈ JofType(y)Ktnτ,ϕ,% ⇔ g1 ∈ J∩y∈SofType(y)Ktnτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 114
Regola TypeTriple2
(TypeTriple2)
S = {Dom(I, SI) | I ∈ TG}W = {Range(I, SI) | I ∈ TG}
TG = {IriRef1} ∪ . . . ∪ {IriRefn}SI,NG, TG `Tp s ?var o :
[s : ∪S∈S ∩y∈S ofType(y) , ?var : TG , o : ∪W∈W ∩y∈W ofType(y)]
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `Tp s ?var o :
[s : ∪S∈S ∩y∈S ofType(y), ?var : TG, o : ∪W∈W ∩y∈W ofType(y)]⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. Js ?var oK
Tp%′,δ ∈
J[s : ∪S∈S ∩y∈S ofType(y), p : TG, o : ∪W∈W ∩y∈W ofType(y)]Ktrτ,ϕ,%′
ovvero, per de�nizione di Js ?var oKTp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.π(s,?var,o)(JsKt1%′,δ 1 J?varKt2%′,δ 1 JoKt3%′,δ) ∈
J[s : ∪S∈S∩y∈SofType(y), ?var : TG, o : ∪W∈W∩y∈W ofType(y)]Ktrτ,ϕ,%′
Chiamiamo r la seguente tabella:
r = π(s,?var,o)(JsKt1%′,δ 1 J?varKt2%′,δ 1 JoKt3%′,δ)
Consideriamo le tre relazioni separatamente e notiamo che ogni record di
ogni tabella è il risultato di un matching della tripla con l'active graph δ.
� JsKt1%′,δ = {[s=g1; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}
� J?varKt2%′,δ = {[?var=g2; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}
� JoKt3%′,δ = {[o=g3; 1=g1; 2=g2; 3=g3] | (g1,g2,g3)∈ δ}
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 115
Nello speci�co dobbiamo dimostrare che ∀ t ∈ r, si ha:
(1) t[s] ∈ J∪S∈S ∩y∈S ofType(y)Ktnτ,ϕ,%′
(2) t[?var] ∈ J{IriRef1}∪ . . .∪{IriRefn}Ktnτ,ϕ,%′
(3) t[o] ∈ J∪W∈W ∩y∈W ofType(y)Ktnτ,ϕ,%′
La (2) è banale da dimostrare. Poichè δ ∈ J{IriRef1}∪ . . .∪{IriRefn}Ktgτ,ϕ,%possiamo dedurre che t[?var]={IriRefi} per qualche i=1. . . n.
Manca da dimostrare la (1) e la (3). Di seguito diamo una dimostrazione
della (1), la dimostrazione della (3) è analoga.
Sappiamo che ogni riga t della relazione r è in corrispondenza con una
tripla di δ, g1 g2 g3, tale che t(s)=g1, t(?var)=g2, t(o)=g3.
Possiamo dimostrare (1) dimostrando che per ogni tripla (g1, g2, g3) che
match (s ?var o), vale che
g1 ∈ J∪s∈S ∩y∈S ofType(y)Ktnτ,ϕ,%
Sappiamo che l'active graph δ per de�nizione soddisfa lo ELOSchema e in
particolare soddisfa la tipizzazione delle costanti:
δ |=OWL τ ⇔ ∀ (g1 g2 g3) ∈ δ . ∀ y ∈ Dom (g2, SI)⇒ g1 ∈ τ(y) ∧∀ (g1 g2 g3) ∈ δ . ∀ y ∈ Range(g2, SI)⇒ g3 ∈ τ(y)
Dato che t(?var)∈ J{IriRef1} ∪ . . . ∪ {IriRefn}Ktnτ,ϕ,%′ possiamo dedurre che
g2 ∈ {IriRef1, . . . , IriRefn}, per cui:
∃I ∈ TG.∀y ∈ Dom(I, SI). g1 ∈ τ(y)per definizione di OfType−−−−−−−−−−−−−−−−→
∃I ∈ TG.∀y ∈ Dom(I, SI). g1 ∈ JofType(y)Ktnτ,ϕ,%
Osserviamo che per ogni I∈TG, esiste un elemento S=Dom(I,SI) che appar-
tiene ad S, per cui possiamo riscrivere la formula come segue:
∃S ∈ S.∀y ∈ S. g1 ∈ JofType(y)Ktnτ,ϕ,% ⇔ g1 ∈ J∪S∈S∩y∈SofType(y)Ktnτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 116
4.2.9 Dimostrazione soundness VarOrGTerm
Sono diverse le regole di inferenza per i VarOrGTerm. Per le regole Type-
VarOrGTermBNode e TypeVarOrGTermLiteral non verrà riporta-
ta una dimostrazione, in quanto simile a quella per la regola TypeVarOrG-
TermIri.
Regola TypeVarOrGTermVar
(TypeVarOrGTermVar)
V ar ∈ dom(TR)
TR `V gt V ar : TR(V ar)
Dimostrazione. Si vuole dimostare che
TR `V gt ?var : TR(?var) ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.∀t ∈ r. J?varK
V gtt ∈ JTR(?var)Ktnτ,ϕ,%
ovvero, per de�nizione di J?varKV gtt
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.∀t ∈ r. t[?var]∈ JTR(?var)Ktnτ,ϕ,%
Poichè
r ⊆ JTRKtrτ,ϕ,% ⇒ t ∈ JTRKtrτ,ϕ,%
per de�nizione, essendo ?var∈ dom(TR), abbiamo che:
t[?var] ∈ JTR(?var)Ktnτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 117
Regola TypeVarOrGTermIri
(TypeVarOrGTermIri)
SI `OWL {IriRef} ∩ TR[IriRef ] :6=: ε
TR `V gt IriRef : {IriRef} ∩ TR[IriRef ]
Dimostrazione. Si vuole dimostare che
TR `V gt IriRef : {IriRef} ∩ TR[IriRef] ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.∀t ∈ r.
JIriRefKV gtt ∈ J {IriRef}∩ TR[IriRef] Ktnτ,ϕ,%
ovvero, per de�nizione di JIriRefKV gtt
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.∀t ∈ r.t[IriRef]∈{IriRef}∩J TR[IriRef]Ktnτ,ϕ,%
Bisogna veri�care due condizioni:
1. IriRef ∈ {IriRef}
2. IriRef ∈ JTR[IriRef ]Ktrτ,ϕ,%
La condizione (1) è immediata.
La condizione (2) è veri�cata assumendo la premessa
SI `OWL {IriRef} ∩ TR[IriRef ] :6=: ε
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 118
4.2.10 Dimostrazione soundness WhereClause
(TypeWhere)
SI,NG, TG `Gp GP : TR
SI,NG, TG `Wc where GP : TR
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `Wc where GP:TR ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
Jwhere GPKWc%′,δ ⊆ JTRKtrτ,ϕ,%′
ovvero, per de�nizione di Jwhere GPKWc%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGPKGp%′,δ ⊆ JTRKtrτ,ϕ,%′
La tesi segue immediatamente dall'ipotesi induttiva.
4.2.11 Dimostrazione soundness Graph Pattern
Consideriamo le regole di inferenza per i graph pattern.
Regola TypeGpEmpty
(TypeGpEmpty)
SI,NG, TG `Gp {} : []
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `Gp {}:[] ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. J{}K
Gp%′,δ ⊆ J[]Ktrτ,ϕ,%′
ovvero, per de�nizione di J{}KGp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.{[]}⊆{[]}
La dimostrazione segue immediatamente dalla de�nizione.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 119
RegolaTypeGpTriple
(TypeGpTriple)
SI,NG, TG `Tr Triple : TR SI 0OWL and(TR, TR(SI)) :=: ε
SI,NG, TG `Gp Triple : TR
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `Gp Triple:TR ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,%× JTGKtgτ,ϕ,%. JTripleK
Gp%′,δ ⊆ JTRKtrτ,ϕ,%′
ovvero, per de�nizione di JTripleKGp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,%× JTGKtgτ,ϕ,%. JTripleKTp%′,δ ⊆ JTRKtrτ,ϕ,%′
La dimostrazione segue dall'ipotesi, in quanto il tipo relazione associato al
graph pattern è il tipo relazione risultato dalla valutazione del triple pattern
che costituisce il graph pattern. Per ipotesi infatti sappiamo che:
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,%× JTGKtgτ,ϕ,%. JTripleKTp%′,δ ⊆ JTRKtrτ,ϕ,%′
Come si può notare, ai �ni della dimostrazione della soundness non è neces-
sario assumere la premessa:
SI 0OWL and(TR, TR(SI)) :=: ε
La veridicità di questo predicato assicura che il tipo relazione TR rispetti le
informazioni presenti nello ELOSchema a livello di costanti, come speci�cato
nel capitolo precedente.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 120
Regola TypeGPUnion
(TypeGpUnion)
SI,NG, TG `Gp GP1 : TR1 SI,NG, TG `GP GP2 : TR2
SI,NG, TG `Gp GP1 union GP2 : union(TR1, TR2)
Dimostrazione. Si vuole dimostrare che:
SI,NG,TG `Gp GP1 union GP2:union(TR1,TR2) ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
JGP1 union GP2KGp%′,δ ⊆ Junion(TR1,TR2)Ktrτ,ϕ,%′
ovvero, per de�nizione di JGP1 union GP2KGp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.JGP1KGp%,δ∪+ JGP2KGp%,δ ⊆ Junion(TR1,TR2)Ktrτ,ϕ,%′
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse
della regola di inferenza, ovvero
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGP1KGp%′,δ ⊆ JTR1Ktrτ,ϕ,%′
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGP2KGp%′,δ ⊆ JTR2Ktrτ,ϕ,%′
La dimostrazione segue dalla dimostrazione del lemma union:
r1 ⊆ JTR1Ktrτ,ϕ,%,r2 ⊆ JTR2Ktrτ,ϕ,% ⇒ r1 ∪+ r2 ⊆ Junion(TR1,TR2)Ktrτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 121
Regola TypeGPAnd
(TypeGpAnd)
SI,NG, TG `Gp GP1 : TR1 SI,NG, TG `GP GP2 : TR2
SI 0OWL and(TR1, TR2) :=: ε
SI,NG, TG `Gp GP1 . GP2 : and(TR1, TR2)
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `GpGP1 . GP2:and(TR1,TR2) ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
JGP1 . GP2KGp%′,δ ⊆ Jand(TR1,TR2)Ktrτ,ϕ,%′
ovvero, per de�nizione di JGP1 . GP2KGp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.JGP1KGp%,δ 1 JGP2KGp%,δ ⊆ Jand(TR1,TR2)Ktrτ,ϕ,%′
Per ipotesi induttiva sappiamo che:
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGP1KGp%′,δ ⊆ JTR1Ktrτ,ϕ,%′
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGP2KGp%′,δ ⊆ JTR2Ktrτ,ϕ,%′
La dimostrazione segue dalla dimostrazione del lemma and:
r1 ⊆ JTR1Ktrτ,ϕ,% , r2 ⊆ JTR2Ktrτ,ϕ,% ⇒ r1 1 r2 ⊆ Jand(TR1,TR2)Ktrτ,ϕ,%
La premessa SI 0OWL and(TR1, TR2) :=: ε assicura che i tipi delle due
relazioni siamo compatibili, come speci�cato nel dettaglio nel capitolo prece-
dente.
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 122
TypeGpOpt
(TypeGpOpt)
SI,NG, TG `Gp GP1 : TR1 SI,NG, TG `GP GP2 : TR2
SI,NG, TG `Gp GP1 opt GP2 : opt(TR1, TR2)
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `GpGP1 opt GP2:opt(TR1,TR2) ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
JGP1 opt GP2KGp%′,δ ⊆ Jopt(TR1,TR2)Ktrτ,ϕ,%′
ovvero, per de�nizione di JGP1 opt GP2KGp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.JGP1KGp%,δn JGP2KGp%,δ ⊆ Jopt(TR1,TR2)Ktrτ,ϕ,%′
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse
della regola di inferenza, ovvero
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGP1KGp%′,δ ⊆ JTR1Ktrτ,ϕ,%′
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGP2KGp%′,δ ⊆ JTR2Ktrτ,ϕ,%′
La dimostrazione segue dalla dimostrazione del lemma opt:
r1 ⊆ JTR1Ktrτ,ϕ,% , r2 ⊆ JTR2Ktrτ,ϕ,% ⇒ r1 1+r2 ⊆ Jopt(TR1,TR2)Ktrτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 123
Regola TypeGpFilter
(TypeGpFilter)
SI,NG, TG `Gp GP : TR TR `V c V C : BOOL
SI,NG, TG `Gp GP filter V C : TR
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `Gp GP filter VC:TR ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
JGP filter VCKGp%′,δ ⊆ JTRKtrτ,ϕ,%′
ovvero, per de�nizione di JGP filter VCKGp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.{ t | t∈ JGPKGp%′,δ ∧ JVcKV ct } ⊆ JTRKtrτ,ϕ,%′
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse
della regola di inferenza, ovvero
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%. JGPKGp%′,δ ⊆ JTRKtrτ,ϕ,%′
questo è su�ciente per concludere la dimostrazione, in quanto
{t|t ∈ JGP KGp%′,δ ∧ JV cKV ct } ⊆ JGP KGp%′,δ ⊆ JTRKtrτ,ϕ,%′
Regola TypeGpIriGraph
(TypeGpIriGraph)
IriRef : nameOf(TG1) ∈ NG SI,NG, TG1 `Gp GP : TR
SI,NG, TG `Gp IriRef graph GP : TR
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 124
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `Gp IriRef graph GP:TR ⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
JIriRef graph GPKGp%′,δ ⊆ JTRKtrτ,ϕ,%′
ovvero, per de�nizione di JIriRef graph GPKGp%′,δ
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.JGPKGp%′,%′(IriRef) ⊆ JTRKtrτ,ϕ,%′
Per ipotesi sappiamo che la proprietà di soundness è valida sulle premesse
della regola di inferenza, ovvero
∀τ, ϕ, % ∈M(SI),∀(%′, δ1) ∈ JNGKngτ,ϕ,% × JTG1Ktgτ,ϕ,%. JGPKGp%′,δ1 ⊆ JTRKtrτ,ϕ,%′
La dimostrazione termina prendendo δ1=%′(IriRef) ∈ JTG1Ktgτ,ϕ,%, in quanto
dalle premesse della regola di inferenza sappiamo che IriRef riferisce un grafo
di tipo TG1.
Regola TypeGpVarGraph
(TypeGpVarGraph)
SI,NG,∪i∈dom(NG)NG(i) `Gp GP : TR
SI,NG, TG `Gp V ar graph GP : and([V ar : dom(NG)], TR)
Dimostrazione. Si vuole dimostrare che
SI,NG,TG `Gp Var graph GP: and([Var:dom(NG)],TR)⇒∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × JTGKtgτ,ϕ,%.
JVar graph GPKGp%′,δ ⊆ Jand([Var:dom(NG)],TR)Ktrτ,ϕ,%′
ovvero, per de�nizione di JVar graph GPKGp%′,δ
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 125
∀τ, ϕ, % ∈M(SI),∀(%′, δ) ∈ JNGKngτ,ϕ,% × J∪i∈dom(NG)NG[i]Ktgτ,ϕ,%.{[Var=i]
dip(i)1 JGPKGp%′,%′(i)|i ∈ dom(%′)
}⊆
Jand([Var:dom(NG)],TR)Ktrτ,ϕ,%′
Utilizziamo il lemma and
r1 ⊆ JTR1Ktrτ,ϕ,% , r2 ⊆ JTR2Ktrτ,ϕ,% ⇒ r1 1 r2 ⊆ Jand(TR1,TR2)Ktrτ,ϕ,%
ci basta dimostrare che le seguenti due condizioni, ∀i ∈ dom(%′)
1. {[Var=i]}⊆ J[V ar : dom(NG)]Ktrτ,ϕ,%′
2. JGP KGp%′ ⊆ JTRKngτ,ϕ,%′
La (1) è immediata dato che, per de�nizione di %′ ∈ JNGKngτ,ϕ,% sappiamo che:
dom(%′) = dom(NG) ∧ ∀i ∈ dom(%′). %′(i) ∈ JNG(i)Ktgτ,ϕ,%
poichè
i ∈ dom(%′) ⇔ i ∈ dom(NG) ⇒ i ∈ Jdom(NG)Ktnτ,ϕ,%′
Dimostrare la (2) equivale a dimostrare che:
∀i ∈ dom(%′), %′(i) ∈ J∪i∈dom(NG)NG(i)Ktgτ,ϕ,%
Dato che %′ ∈ JNGKngτ,ϕ,%, abbiamo che
%′(i) ⊆ JNG(i)Ktgτ,ϕ,%
Dalla semantica dell'unione dei tipi grafo possiamo dedurre che
∀ TG, TG′. JTGKtgτ,ϕ,% ⊆ JTG ∪ TG′Ktgτ,ϕ,%
segue che:
JNG(i)Ktgτ,ϕ,% ⊆ J∪i∈dom(NG)NG(i)Ktgτ,ϕ,%
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 126
4.2.12 Dimostrazione soundness valueC
Consideriamo le regole di inferenza per i value constraints.
Regola TypeVcOp
(TypeVcOp)
TR `V gt?var : TN1 TR `V gt vgt : TN2
areCompatibleType(OP, TN1, TN2)
TR `V c?var OP vgt : Bool
Dimostrazione. Si vuole dimostrare che
TR `V c ?var OP vgt : Bool ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. J?var OP vgtKV cr ∈ JBoolK
ovvero, per de�nizione di J?var OP vgtKV cr
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.(J?varKV tgr OP JvgtKV tgr )∈ JBoolK
La tesi segue immediatamente dalla de�nizione, in quanto booleana l'espres-
sione (J?varKV tgr OP JvgtKV tgr ).
La presenza del predicato areCompatibleType(OP,TN1,TN2), tra le pre-
messe della regola di inferenza, ci assicura che l'operatore di confronto possa
essere applicato agli operandi ?var e vgt.
Regola TypeVcIri
(TypeVcIsIri)TR `V gt?var : TN
TR `V c isIri(?var) : Bool
Dimostrazione. Si vuole dimostare che
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 127
TR `V cisIri(?var): Bool ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. JisIri(?var)KV cr ∈ JBoolK
ovvero, per de�nizion di JisIri(?var)KV cr
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.(datatype(J?varKV tgr )== T_IRI)∈ JBoolK
Per ipotesi induttiva sappiamo che
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%. J?varKV gtr ∈ JTNKtnτ,ϕ,%
La tesi segue in quanto datatype(J?varKV tgr == T_IRI) è un'espressione
booleana.
La dimostrazioni della soundness per le regole bound(Var), isLite-
ral(var), isBlank(var), sameTerm(Var1,Var2) non viene riportata in
quanto analoghe.
Regola TypeVclangMatches
(TypeVclangMatches)
TR `V gt?var1 : TN TR `V gt?var2 : TN
TR `V c langMatches(?var1,?var2) : Bool
Dimostrazione. Si vuole dimostrare che
TR `V clangMatches(?var1,?var2): Bool ⇒∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.
JlangMatches(?var1,?var2)KV cr ∈ JBoolK
ovvero, per de�nizione di JlangMatches(?var1,?var2)KV cr
CAPITOLO 4. PROPRIETÀ DI SOUNDNESS 128
∀τ, ϕ, % ∈M(SI),∀r ⊆ JTRKtrτ,ϕ,%.langMatches(J?var1KV tgr ,J?var2KV tgr )∈ JBoolK
La dimostrazione termina in quanto langMatches è una funzione booleana.
Regola TypeVcNeg
(TypeVcNeg)TR `V c V c : Bool
TR `V c ¬V c : Bool
Dimostrazione. La tesi segue immediatamente in quando ¬ VC è un'espres-
sione booleana e la proprietà di soundness è valida su Vc per ipotesi induttiva.
Le dimostrazioni per (Vc1∧Vc2) e (Vc1∨Vc2) sono immediate.
Capitolo 5
Implementazione del type checker
La fase conclusiva del lavoro di tesi è costituita dall'implementazione di
un type checker per SPARQL.
Le sezioni successive illustreranno le scelte implementative fatte e gli al-
goritmi proposti. Verrà fornita una sintetica descrizione dei diversi moduli
che compongono il type checker, mentre per maggiori dettagli implementativi
si rimanda alla documentazione del software.
5.1 Il linguaggio di programmazione
In fase di progettazione sono stati presi in considerazioni diversi linguag-
gi di programmazione. La scelta �nale di utilizzare un linguaggio imperati-
vo, JAVA, rispetto ad uno funzionale, quali per esempio HASKELL o OCAML, è
dovuta principalmente a:
� una conoscenza approfondita del linguaggio;
� la portabilità del software;
� la possibilità di creare un'interfaccia gra�ca agevolmente.
� velocizzare, per motivi didattici, il �passaggio del testimone� ad even-
tuali tesisti o tirocinanti che estenderanno il framework prodotto;
Presentiamo di seguito i moduli (package JAVA) realizzati che compongono
il nostro type checker.
129
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 130
5.2 Query SPARQL in JAVA
Le classi e le interfacce implementate per fornire una rappresentazione sin-
tatticamente di una query SPARQL sono contenute nel package AbstratTree.
Ogni classe del package presenta metodi e variabili di istanza pubbliche
onde evitare funzioni di tipo GET e SET che rendono il codice molto verboso.
5.2.1 Tipi di Query
I diversi tipi di query sono stati modellati con una gerarchia di classi, co-
me mostrato in �gura 5.1. La radice della gerarchia è costituita dalla classe
Query. La classe Query contiene due variabili di istanza utilizzate per model-
lare il dataset e il corpo della query. Le classi SelectQuery, ConstructQuery
e AskQuery estendono la superclasse.
Figura 5.1: Modellazione tipi di query SPARQL in JAVA
Nello speci�co la SelectQuery memorizzata il vettore delle variabili da
proiettare, mentre la ConstructQuery memorizza un blocco di triple, il
template. L'AskQuery non introduce nuove variabili di istanza.
5.2.2 Dataset
Il dataset di una query è stato modellato con la classe DatasetClause.
Questa contiene due variabili di istanza,�from� e �from named�.
La variabile �from� è utilizzata per memorizzare l'insieme dei riferimenti
a gra� sui quali verrà e�ettuato l'RDF merge per costituisce il grafo di de-
fault, la variabile �from named� viene utilizzata per memorizzare i named
graph.
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 131
5.2.3 Variabili, graphTerm e triple pattern
Le variabili che compaiono in una query sono modellati dalla classe Var,
che consente la memorizzazione del nome della variabile.
Per modellare i termini di un grafo è stata realizzata una gerarchia di clas-
si, come mostrato in �gura 5.2. La radice della gerarchia è costituita dalla
classe GraphTerm, che contiene una variabile di istanza utilizzata per memo-
rizzare il termine del grafo. Le classe RDFLiteral, BNode e Iri estendono la
classe GraphTerm.
Figura 5.2: Modellazione GraphTerm in JAVA
Sia la classe Var sia la classe GraphTerm implementano i metodi dell'in-
terfaccia VarOrGterm.
La classe Var implementa un'altra interfaccia, VarOrIri; interfaccia im-
plementata anche dalla classe Iri.
Una volta de�nite queste classi e queste interfacce, per modellare un triple
pattern è state realizzata la classe Triple. Ogni istanza di questa classe
contiene tre variabili per modellare soggetto-predicato-oggetto. Il soggetto e
l'oggetto sono variabili di istanza di tipo VarOrGTerm mentre il predicato ha
tipo VarOrIri.
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 132
5.2.4 Graph Pattern
I graph pattern sono modellati da un insieme di classi Java che imple-
mentano una interfaccia comune GP. In tabella 5.1 è mostrata un frammento
della grammatica concreta utilizzata per costruire graph pattern.
WhereClause ::= where GPGP ::= { TriplesBlock?
((filter ValueC | optional GP | UnionGP| graph VarOrIri GP) . ? TriplesBlock?)* }
TriplesBlock ::= Triple (Triple)*UnionGP ::= GP ( union GP)*
Tabella 5.1: Grammatica graph pattern
In �gura 5.3 è mostato l'insieme delle classi JAVA realizzate per modellare
un graph pattern. Le classi sono in corrispondenza con le produzione della
grammatica proposta.
Figura 5.3: Modellazione Graph Pattern in JAVA
Per esempio un'istanza della classe TriplesBlock, è un oggetto conte-
nente un vettore di Triple.
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 133
5.2.5 Value Constraint
I value constraints sono modellati da un insieme di classi JAVA che imple-
mentano un'interfaccia ValueC, come mostrato in �gura 5.4.
Figura 5.4: Modellazione ValueC in JAVA
Le classi proposte sono in grado di modellare le espressioni logiche, le
funzioni e gli operatori, unari e binari.
5.2.6 Parser SPARQL
La grammatica LL(1), mostrata in tabella 5.2, è diversa dal frammento
sempli�cato studiato nei capitoli precedenti ed è in grado di riconoscere tutte
le query di esempio presenti nel documento u�ciale [6].
Sulla base di questa grammatica, è stato realizzato un parser utilizzando
il generatore di parser JAVACC [16].
Per la generazione del parser ci siamo basati sul codice messo a disposi-
zione dal W3C:
http://www.w3.org/2001/sw/DataAccess/rq23/parsers/sparql.jj
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 134
Tabella 5.2: Grammatica concreta SPARQL
Query ::= SelectQuery | ConstructQuery | AskQuerySelectQuery ::= select ((Var)+ | *) DatasetClause
WhereClauseConstructQuery ::= construct Triples_block DatasetClause
WhereClauseAskQuery ::= ask DatasetClause WhereClauseDatasetClause ::= (from (DGraphClause | NGraphClause) )+DGraphClause ::= IriRefNGraphClause ::= named IriRefWhereClause ::= where GPGP ::= { TriplesBlock?
((filter ValueC | optional GP | UnionGP| graph VarOrIri GP) . ? TriplesBlock?)* }
TriplesBlock ::= Triple (Triple)*UnionGP ::= GP ( union GP)*Triple ::= VarOrGterm VarOrIri VarOrGterm (.)?ValueC ::= ( (Var Op VarOrGterm)
| (isIri | isBlank | isLiteral | bound) (Var)| (langMatches | sameTerm)(Var,Var)| ¬ValueC | ValueC (∨|∧) ValueC) )
Op ::= < | > | ≤ | ≥ | = | 6=VarOrGterm ::= Var | GraphTermVarOrIri ::= Var | IriRefGraphTerm ::= IriRef | BNode | RDFLiteralVar ::= ? Varname | $ Varname
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 135
5.3 Tipi de�niti in JAVA
L'insieme delle classi e delle interfacce utilizzate per avere una rappre-
sentazione dei tipi calcolati dall'analisi statica del linguaggio SPARQL sono
contenute nel package SparqlType. Il contenuto del package permette di
modellare un'espressione regolare della grammatica mostrata in tabella 5.3 e
di seguito riportata:
Type TN ::= T_IRI | T_RDFLiteral | T_BNode | {IriRef}| {lit} | nameOf(TG) | TN∪TN | TN∩TN| ofType(IriRef)
Type TG ::= T_IRI | {IriRef} | TG∪TG | ε
Type TR ::= [ ] | [Vgt : σTN] | TR x TR | ε
Type NG ::= NG,IriRef:nameOf(TG) | ε
Tabella 5.3: Sintassi dei tipi
Le interfacce NG, TN, TG e TR sono in corrispodenza biunivoca con i non-
terminali della grammatica. Le classi presenti nel package sono in corrispo-
denza con le produzioni della grammatica.
Per esempio la classe T_RDFLiteral implementa l'interfaccia TN, non-
terminale della produzione. Le classi T_IRI e {IriRef} implementano le
interfacce TN e TG.
I tipi unione e disgiunzione sono stati implementati estendendo la clas-
se generica java.util.HashSet. Per esempio la classe DisjointTN estente la
classe HashSet<TN> e implementa l'interfaccia TN. In questo modo le clas-
si IntersecTN, UnionTN e UnionTG rappresentano una versione n-aria delle
produzioni binarie TN∩TN, TN∪TN e TG∪TG.La classe Rel contiene l'implementazione del tipo relazione. Questa clas-
se fornisce tre metodi statici che restituiscono un tipo relazione risultato
dell'unione, della giunzione o della giunzione esterna dei due tipi relazione
presi come parametro. Questi metodo implementano le funzioni sintattiche
union, and e opt presentate nel capitolo 4.
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 136
5.4 ELO schema in JAVA
Ai �ni della modellazione di un ExtraLightOWLSchema è stata realizzata
una classe JAVA, la classe SI.java del package ELOSchema, in grado di me-
morizzare le asserzioni OWL2 presenti nello schema e in grado di supportare
ragionamenti, deduzioni logiche, derivanti dalla presenza di tali asserzioni.
Nella classe SI.java sono presenti le seguenti strutture dati:
� ELOclasses, permette di memorizzare la lista delle Iri, identi�catori di
classi OWL2;
� ELOproperty permette di memorizzare per ogni Iri, identi�catore di
proprietà, il dominio e il range della proprietà;
� superClassOf permette di memorizzare per ogni classe OWL2 la lista
delle sue superclassi;
� disjointClasses permette di memorizzare per ogni classe OWL2 la lista
delle classi dalle quali è disgiunta;
� classAssertion permette di memorizzare le informazioni derivanti
dalla presenza di asserzioni ClassAssertion(Iri, Iri).
La classe SI.java prevede un insieme di metodi in grado di estrapolare in-
formazioni di tipo deducibili dai dati memorizzati nelle strutture dati appena
presentate. Presentiamo di seguito gli algoritmi più interessanti implementati
da questi metodi.
Algoritmo per la chiusura transitiva e ri�essiva delle relazioni di
sottoclasse
L'insieme delle classi OWL2 e delle asserzioni SubClassOf presenti nello
ELOSchema costituiscono un grafo G=<V,E> cosi speci�cato
� l'insieme dei nodi V del grafo corrisponde all'insieme delle classi OWL2
presenti nello ELOSchema;
� ogni asserzione SubClassOf(Iri1,Iri2) identi�ca un arco orientato da
Iri1 a Iri2
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 137
Queste informazioni sono memorizzate nella struttura dati superClassOf
della classe SI.java. Ai �ni della tipizzazione, interessa spesso veri�care
l'esistenza di una relazione di inclusione tra due nodi. A tal scopo viene
implementato un algoritmo in grado di e�ettuare la chiusura transitiva e
ri�essiva di questa relazione.
Assumiamo che ogni nodo in N abbia un numero limitato di archi uscen-
ti, ovvero assumiamo che per ogni classe memorizzata nella struttura dati
superClassOf la lista delle sue superclassi sia di dimensioni limitata. Sotto
questa assunzione, abbiamo implementato la chiusura ri�essiva e transitiva
della relazione di inclusione e�ettuando, per ogni nodo presente nel grafo,
una visita in ampiezza del grafo.
La chiusura viene memorizzata in una struttura dati AncestorClosure.
/** Questo metodo calcola la chiusura transitiva e riflessiva
della relazione di sottoclasse */
void createAncestorClosure ( ) {
for each nodo in ELOclasses
createAncestorClosure ( nodo ) ;
}
/** Questo metodo calcola la chiusura transitiva e riflessiva
di un nodo*/
void createAncestorClosure ( nodo ) : {
DaVisitare = [ nodo ] ;
while ( DaVisitare != [ ] ) {
element = DaVisitare . pop ( ) ;
Visitati . add ( element ) ;
AncestorClosure [ nodo ] . add ( element ) ;
for each element1 in superClassOf ( element ) {
i f ( element1 /∈ Visitati )
DaVisitare . push ( element1 ) ;
}
}
}
Al termine del caricamento dello ELOSchema la chiusura viene utilizzata
per veri�care la soddisfacibilità di tutte le classi dello schema, ovveroche non
esiste una classe che ha antenati disgiunta. Lo pseudo-codice dell'algoritmo
utilizzato per e�ettuare questo controllo è riportato di seguito. Ricordia-
mo che le informazioni sui vincoli di disgiunzione sono memorizzate nella
struttura dati DisjointClasses.
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 138
void areDisjoint ( AncestorClosure ( nodo ) ) {
for each element in AncestorClosure ( nodo ) {
i f ( DisjointClasses ( element ) ∩ AncestorClosure ( nodo ) != ∅ )
"ERROR ancestor conflict"
}
Algoritmo per la consistenza del dominio e del range di una pro-
prietà
Come visto nei capitoli precedenti, in un ELOSchema è possibile speci�care
il dominio e il range di una proprietà attraverso asserzioni di tipo Object-
PropertyDomain e ObjectPropertyRange. Ogniqualvolta viene spe-
ci�cato un dominio per una proprietà che già ne ha uno speci�cato, bisogna
veri�care la compatibilità dei due domini. Discorso analogo vale per i range.
/** Questa funzione permette di definire il dominio di property */
void addDomain ( property , dom ) {
i f ( property not in ELOproperty ) {
/**Se property non e ' presente nella struttura dati ELOproperty :
lo inserisco e gli associo il dominio dom*/
ELOproperty . add ( property ) ;
ELOproperty ( property ) . addDomain ( dom ) ;
}
else {
/**Se property e ' presente nella struttura dati ELOproperty :
estendo il suo dominio verificando che l ' operazione non
generi conflitti di tipo*/
oldDomain = ELOproperty ( property ) . getDomain ( ) ;
i f ( areInConflict ( dom , oldDomain )
"ERROR : dom conflict"
else
ELOproperty ( property ) . addDomain ( dom ) ;
}
}
/** Questa funzione verifica se la classe c non e ' compatibile con
le classi presenti nell ' insieme classSet */
boolean areInConflict (c , classSet ) { . . . }
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 139
Algoritmo areInCon�ict
Nello pseudo-codice precedente abbiamo utilizzato la chiamata di funzio-
ne areInConflict. Questa funzione prende due parametri, una classe c e
un insieme di classi classSet, e veri�ca se c è compatibile con tutte le classi
presenti in classSet.
A�nchè c sia compatibile con classSet bisogna veri�care che anche tutti
gli elementi presenti nella chiusura transitiva e ri�essiva di c siano compatibili
con tutti gli ancestor degli elementi in classSet
boolean areInConflict ( Iri c , Set classSet ) {
for each element in AncestorClosure [ c ]
for each element1 in classSet
i f ( DisjointClasses [ element ] ∩ AncestorClosure [ element1 ] != ∅ )
return true ;
return false ;
}
5.4.1 Parser ELO schema
Data la grammatica mostrata in tabella 5.4, il parser è stato realizzato
utilizzando il generatore di parser JAVACC [16].
SI ::= ( ε| ClassAssertion(IriRef1, IriRef2)| SubClassOf(IriRef1,IriRef2)| DisjointClasses(IriRef1,IriRef2)| ObjectPropertyDomain(IriRef1,IriRef2)| ObjectPropertyRange(IriRef1,IriRef2)| SI,SI )+
Tabella 5.4: Grammatica per gli ELO schema
Esempio di uno ELO schema
Di seguito è mostrato uno ELOSchema valido per il grafo in �gura 5.5
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 140
Figura 5.5: Grafo RDF
Class ( person )
Class ( sportsman )
Class ( soccer_player )
Class ( company )
Class ( soccer_team )
Class ( country )
SubClassOf ( sportsman , person )
SubClassOf ( soccer_player , sportsman )
SubClassOf ( soccer_team , company )
DisjointClasses ( company , person )
DisjointClasses ( country , person )
ObjectProperty ( works_in )
ObjectProperty ( plays_in )
ObjectProperty ( lives_in )
ObjectPropertyRange ( works_in , company )
ObjectPropertyDomain ( works_in , person )
ObjectPropertyRange ( plays_in , soccer_team )
ObjectPropertyDomain ( plays_in , soccer_player )
ObjectPropertyRange ( lives_in , country )
ObjectPropertyDomain ( lives_in , person )
ClassAssertion ( Ronaldinho , soccer_player )
ClassAssertion ( Sorace , soccer_player )
ClassAssertion ( Barcelona , soccer_team )
ClassAssertion ( Everton , soccer_team )
ClassAssertion ( Chile , country )
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 141
5.5 Funzioni ausiliari
Le premesse di una regola di inferenza possono far uso di un insieme di
funzioni ausiliari.
Le funzioni Dom e Range sono implementate nella classe SI.java, pre-
sente nel package ELOSchema, e ritornano le informazioni memorizzate nella
struttura dati ELOproperty.
Le premesse delle regola di inferenza dei value constraint possono fare uso
della funzione booleana areCompatibleType. In questa implementazione del
sistema dei tipi, abbiamo de�nito la funzione areCompatibleType costan-
te, ovvero assumiamo che tutte le funzioni di confronto ammettano come
parametro un qualunque valore.
Per motivi di tempo, in questo lavoro abbiamo tralasciato la creazione
di un'interfaccia con un ragionatore OWL fornendo, con gli algoritmi sopra
proposti, un'implementazione delle deduzioni logiche necessarie per stabilire
la veridicità dei seguenti predicati:
� SI `OWL TN1 <: TN2
� SI `OWL TN1 :=: TN2
� SI `OWL TN1 :=: TN2
Questa implementazione risulta completa per quanto riguarda la tipiz-
zazione delle query select, mentre risulta parziale per quanto riguarda la
tipizzazione delle query construct.
5.6 Implementazione regole di tipo
La fase �nale di implementazione ha previsto la trascrizione algoritmica
delle regole di tipo.
Il type checker è stato realizzato attraverso una visita dell'albero di sin-
tassi astratta. Ogni elemento sintattico implementa il metodo ofType() che
preso un ambiente di valutazione ritorna il tipo dell'elemento sintattico.
CAPITOLO 5. IMPLEMENTAZIONE DEL TYPE CHECKER 142
Consideriamo, per esempio la seguente regola di inferenza:
SI,NG `Dc DatasetClause : NG′, TG
SI,NG′, TG `Wc WhereClause : TR′
TR′ `Sc SelectClause : TR
SI,NG `Sq SelectClause DatasetClause WhereClause : TR
il metodo ofType() della classe SelectQuery è il seguente
public TR ofType ( SI si , NG ng ) {
Pair<NG , TG> env = this . dataset . ofType ( si , ng ) ;
Rel r = ( Rel ) this . where . ofType ( si , env . getFirst ( ) , env . getSecond ( ) ) ;
return select . ofType ( r ) ;
}
Tutte le regole sono state realizzate nel seguente modo.
Capitolo 6
Conclusioni
L'oggetto di questo studio è stato SPARQL, linguaggio di interrogazione
per gra� RDF.
La presente tesi è stata così articolata: inizialmente è stato presentato
RDF, il formalismo utilizzato per descrivere dati semistrutturati e il relativo
linguaggio di interrogazione SPARQL nella sua versione standard del 2006.
La versione più recente di SPARQL ha esteso il linguaggio in modo interes-
sante ma questa non è stata oggetto di studio in quanto non ancora standard
proposto dal W3C.
Successivamente è stata presentata la semantica formale e il sistema di
tipi per SPARQL; il sistema di tipi proposto ha come obiettivo principale
quello di de�nire un tipo per le diverse forme del risultato.
Sulla base di questo sistema di tipizzazione, di cui abbiamo dimostrato
la proprietà di soundness, è stato implementato un type checker in grado di
e�ettuare un'analisi dei tipi non banale, derivante dalla possibilità di sfruttare
informazioni, speci�cate a tempo di compilazione dall'utente.
Il sistema dei tipi realizzato combina tecniche di tipizzazione note con
tecniche innovative.
Il nostro sistema si basa su un approccio ottimistico sperimentato nel
sistema di tipi Xquery [7]. Tale approccio permette di combinare informazioni
tipizzate con informazioni non tipizzate.
Sono invece originali le tecniche utilizzate per tipizzare i gra� RDF e per
tipizzare le IRIreference che fanno riferimento a tali gra�.
143
CAPITOLO 6. CONCLUSIONI 144
Originali sono anche le tecniche utilizzate per la descrizione delle gerarchie
di tipi, che combinano relazioni di inclusione con relazioni di disgiunzione,
quest'ultime indispensabili ai �ni del rilevamento di incompatibilità fra tipi.
Dal punto di vista semantico un contributo di questo studio è l'assunzione
dell'esistenza di una funzione di tipizzazione globale, parzialmente nota, che
assegna una semantica ad ogni tipo (la funzione τ).
Un ultimo aspetto originale è la trattazione uniforme delle variabili e delle
costanti nel processo di inferenza dei tipi.
Nelle sezioni che seguiranno verranno mostrati possibili sviluppi futuri
del lavoro svolto.
6.1 Obiettivi a breve/medio termine
Gli obiettivi a breve/medio termine sono molteplici. I più signi�cativi
sono i seguenti:
Implementazione di un'interfaccia gra�ca Il type checker implementa-
to presenta un'interfaccia testuale. Sarebbe interessante sviluppare una
prima interfaccia gra�ca, per il sistema realizzato, che sia in grado di
stampare l'albero di sintassi astratta di una query SPARQL, di forni-
re un editor di testi per ELOSchema e per query SPARQL in grado di
segnale staticamente, utilizzando il sistema realizzato, errori sintattici
ed errori di tipo;
Interfacciamento con un ragionatore OWL Il sistema dei tipi, come visto
in precedenza, fa uso di un insieme di predicati la cui veridicità viene
stabilita da un ragionatore OWL. Per motivi di tempo, in questo lavoro
abbiamo tralasciato la creazione di questa interfaccia fornendo un insie-
me di algoritmi in grado di e�ettuare deduzioni logiche necessarie per
stabilire la veridicità di questi predicati. Tra gli sviluppi futuri sarebbe
interessante analizzare un insieme di ragionatori OWL open source e
creare un'interfaccia verso uno di questi;
CAPITOLO 6. CONCLUSIONI 145
Gestione diversa dei value constraint Le regole di tipo, del nostro siste-
ma, veri�cano esclusivamente se un value constraint è un'espressione
booleana. D'altra parte, però, l'uso di risorse e operatori all'interno
di espressioni booleane permetterebbe di allargare l'analisi statica dei
tipi a quest'ultime, così da rilevare eventuali errori di tipo e inferire in-
formazioni aggiuntive rispetto a quelle derivabili dello ELOSchema. Per
esempio, le espressioni nei value constraint potrebbero essere utilizzate
per ricavare informazioni sul tipo di una variabili presente nel corpo di
una query. Riprendiamo la query analizzata in precedenza:
SELECT ?player,?team
FROM <http://soccer_play.example/>
WHERE { ?player ?p ?team.
filter (?p = plays_in)
Query 6.12: Rdfs:range and Rdfs:domain
in questo caso potremmo inferire che ?p è di tipo plays_in e utilizzare
tale informazione per rilevare eventuali incompatibilità di tipo.
6.2 Obiettivi a lungo termine
L'obiettivo a lungo termine principale è la de�nizione di un sistema di
tipi per SPARQL 1.1. Questo comporterebbe un'estensione dei tipi de�niti
e l'introduzione di nuove regole sui tipi.
È possibile che le regole di tipi da aggiungere al sistema non siano banali
da implementare, in quanto nella versione 1.1 è stata introdotto la possibilità
di annidare le query. In prima analisi, tipare un query annidata equivale a
tipare una funzione che prende come parametro un'altra query; gestire questi
aspetti richiederà un attento studio.
Bibliogra�a
[1] T. Berners-Lee, J. A. Hendler, and O. Lassila, �The semantic web,�
Scienti�c American, vol. 284, pp. 34�43, May 2001.
[2] F. Manola and E. Miller, �RDF primer.� W3C, Recommendation REC-
rdf-primer-20040210, Feb. 2004.
[3] P. Hayes, �RDF semantics.� W3C, Recommendation REC-rdf-mt-
20040210, Feb. 2004.
[4] G. Winskel, The Formal Semantics of Programming Languages. The
MIT Press, 1993.
[5] J. Pérez, M. Arenas, and C. Gutierrez, �Semantics and complexity
of SPARQL,� in International Semantic Web Conference (I. F. Cruz,
S. Decker, D. Allemang, C. Preist, D. Schwabe, P. Mika, M. Uschold,
and L. Aroyo, eds.), vol. 4273 of Lecture Notes in Computer Science,
pp. 30�43, Springer, 2006.
[6] E. Prud'Hommeaux and A. Seaborne, �SPARQL query language for
RDF.� W3C, Recommendation REC-rdf-sparql-query-20080115, Jan.
2008.
[7] A. Malhotra, J. Melton, N. Walsh, and M. Kay, �XQuery 1.0 and XPath
2.0 functions and operators (second edition).� W3C, Proposed Edited
Recommendation PER-xpath-functions-20090421, Apr. 2009.
[8] R. V. Guha and D. Brickley, �RDF vocabulary description langua-
ge 1.0: RDF schema,� W3C recommendation, W3C, Feb. 2004.
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/.
146
BIBLIOGRAFIA 147
[9] G. Klyne and J. J. Carroll, �Resource description framework: Con-
cepts and abstract syntax.� W3C, Recommendation REC-rdf-concepts-
20040210, February 2004.
[10] D. Beckett, �Turtle - terse rdf triple language,� tech. rep., 2007.
[11] P. Hitzler, M. Krötzsch, B. Parsia, P. F. Patel-Schneider, and S. Ru-
dolph, �OWL 2 web ontology language � primer.� World Wide Web
Consortium, Recommendation REC-owl2-primer-20091027, Oct. 2009.
[12] B. Motik, P. F. Patel-Schneider, and B. Parsia, �OWL 2 web ontology
language - structural speci�cation and functional-style syntax.� W3C,
Recommendation REC-owl2-syntax-20091027, Oct. 2009.
[13] P. F. Patel-Schneider and B. Motik, �OWL2 web ontology language-
mapping to RDF graphs.� W3C, Recommendation REC-owl2-mapping-
to-rdf-20091027, Oct. 2009.
[14] M. Schneider, �OWL 2 web ontology language - RDF-based semantics.�
W3C, Recommendation REC-owl2-rdf-based-semantics-20091027, Oct.
2009.
[15] B. Motik, P. F. Patel-Schneider, and B. C. Grau, �OWL 2 web
ontology language � direct semantics.� W3C, Recommendation
REC-owl2-direct-semantics-20091027, Oct. 2009.
[16] Java Compiler CompilerTM (JavaCCTM) - The Java Parser Generator
Home Page. https://javacc.dev.java.net.