Web Semantic

I ndice
Introduzione ................................................................
......................................................................................
...................................................... 6
Capitolo 1 ................................................................
..........................................................................................
.......................................................... 8
................................................................
............................................
Il Web semantico ................................
................................
............ 8
1.1 Introduzione ............................................................................... 8
1.2 Principi del Web Semantico ....................................................... 8
1.3 Obiettivi del Web Semantico
Semantico ................................................... 11
1.4 I Servizi Web ............................................................................ 12
1.5 La rappresentazione della conoscenza ................................... 13
1.6 I nomi delle risorse: URI .......................................................... 15
1.7 Gli strati del Web semantico .................................................... 16
1.7.1 L’XML ................................................................................. 17
1.7.3 L’RDF e l’RDFS ................................................................. 20
1.7.4 Lo strato delle ontologie .................................................... 21
1.7.5 Lo strato logico .................................................................. 22
1.7.6 Proof .................................................................................. 22
1.8 Le ontologie ............................................................................. 22
Capitolo 2 ................................................................
........................................................................................
........................................................ 25
................................................................
...........................................
KAON ToolSuite ................................
................................
........... 25
2.1 Introduzione ............................................................................. 25
2.2 La Piattaforma KAON .............................................................. 25
2.3 Sistemi richiesti ........................................................................ 26
1
2.4 Installazione ............................................................................. 27
2.5 Componenti del ToolSuite di KAON ........................................ 27
2.6 Architettura di KAON ............................................................... 30
2.7 KAON API ................................................................................ 31
2.8 OIOI-Model .................................................................................. 32
2.9 Linguaggio ontologico di KAON............................................... 34
2.10 Root concept .......................................................................... 35
2.11 MetaMeta-modeling
modeling ....................................................................... 36
2.12 Query ..................................................................................... 36
2.12.1 Sintassi ........................................................................... 37
2.12.2 Espressioni concetto
concetto ....................................................... 37
2.12.3 Espressioni proprietà ....................................................... 42
2.13 Query sullo Schema .............................................................. 44
2.14 OIOI-modeler: KAON Workbench ............................................. 44
2.14.1 Il menù File ...................................................................... 46
2.14.2 Il menù Edit ...................................................................... 49
2.14.3 Il menù View .................................................................... 49
2.14.4 Il menù Procedures ......................................................... 49
2.15 Creare ontologie .................................................................... 50
2.16 KAON Portal .......................................................................... 51
Capitolo 3 ................................................................
........................................................................................
........................................................ 52
........................................................
KAON: I Componenti Remoti ................................
........................ 52
3.1 Introduzione ............................................................................. 52
3.2 RDF Server .............................................................................. 52
3.3 Engineering Server .................................................................. 57
3.4 L’Accesso ai database ............................................................. 58
2
3.5 Scenari dell’Engineering Server .............................................. 59
3.6 Direct Engineering Server........................................................
60
Server
Capitolo 4 ................................................................
........................................................................................
........................................................ 66
................................................................
....................................
Risultati Sperimentali ................................
................................
.... 66
4.1 Introduzione ............................................................................. 66
4.2 Il Concetto di Inferenza ............................................................ 67
4.3 L’ontologia dei laureati. ............................................................ 69
4.3.1 Aggiungere un nuovo concetto .......................................... 74
4.3.2 Aggiungere una nuova proprietà ....................................... 75
4.3.3 Aggiungere una nuova istanza .......................................... 76
4.3.4 Istanziare proprietà ............................................................ 77
4.4 Piccolo motore inferenziale: .................................................... 81
4.5 L’ inferenza
inferenza tra due database e il sillogismo aristotelico: ........ 83
Capitolo 5 ................................................................
........................................................................................
........................................................ 88
KAON Server ................................................................
................................................................
...............................................
............... 88
5.1 Introduzione ............................................................................. 88
5.2 Architettura del KAON Server.................................................. 90
5.2.1 I connettori ......................................................................... 91
5.2.2 Nucleo per la gestione ....................................................... 92
5.2.3 La sicurezza ....................................................................... 92
5.2.4 I componenti funzionali ...................................................... 93
5.3 Installazione ............................................................................. 93
Appendice A: ................................................................
...................................................................................
................................................... 95
...............................................
Breve guida a MS Sql Server 2000 ................................
............... 95
Introduzione ................................................................................... 95
3
I database ...................................................................................... 95
Guida a MS Sql Server 2000 ......................................................... 98
Installazione ................................................................................... 99
L'Enterprise Manager................................................................... 100
I database di test.......................................................................... 101
Creazione di un database ............................................................ 102
APPENDICE B: ................................................................
.............................................................................
............................................. 105
................................................................
...............................................
Codici JAVA ................................
................................
............... 105
Script dell’inferenza sull’ontologia dei laureati.
laureati............................. 105
Script sull’inferenza tra i due database:.......................................
110
database:
Considerazioni Finali ................................................................
.....................................................................
..................................... 116
Bibliografia ................................................................
....................................................................................
.................................................... 119
Risorse................................
Risorse................................................................
..........................................................................................
.......................................................... 121
Ringraziamenti ................................................................
..............................................................................
.............................................. 124
4
“A Pierina e Vito
5
Introduzione
La nascita di Internet ha segnato profondamente la comunità, intesa come insieme
di persone e tecnologie. Su Internet si appoggia di fatto l’infrastruttura del World
Wide Web ideato da Berners Lee e costituisce attualmente il mezzo più veloce per
il recupero di informazioni. Estrarre un’informazione dal web costituisce, però,
secondo le analisi dello stesso ideatore, una delle problematiche principali. In
effetti, sul web vengono pubblicati documenti di ogni tipo, è chiaro quindi che la
ricerca di un elemento può dar luogo alla restituizione di risultati che non hanno
nulla a che vedere con l’informazione ricercata. Questo trova giustificazione nel
fatto che le ricerche vengono fatte per parola chiave e molto spesso le stesse
parole vengono utilizzate per catalogare entità che non hanno niente a che vedere
tra loro, dal punto di vista semantico. Per risolvere tale problema Lee sognò di
fornire i sistemi elaborativi di capacità semantica nella selezione di contenuti dal
web, e da questa idea nasce oggi il Web Semantico.
Il nostro lavoro di tirocinio, svoltosi presso i laboratori del CRIAI di Portici, è basato
sullo studio della piattaforma open-source KAON (The KArlsruhe ONtology and
Semantic Web tool suite), per la crazione, gestione e interrogazione di ontologie;
in particolare analizzeremo molto da vicino alcuni componenti di KAON sviluppati
per facilitare la memorizzazione e quindi il riuso di ontologie anche da parte di più
utenti situati su macchine diverse, quali l’E
Engineering Server e l’RDF
RDF Server
Server .
6
Il tool KAON è stato prodotto dalla collaborazione di:
FZI Research Center for Information Technologies
University of Karlsruhe, Germany
Research Group Knowledge Management (WIM)
http://www.fzi.de/wim
Institute AIFB
University of Karlsruhe, Germany
Knowledge Management Group (WBS)
http://www.aifb.uni-karlsruhe.de/WBS
In particolare in quest’elaborato forniremo una panoramica generale sul Web
Semantico. Faremo riferimento ai linguaggi che si propongono per costituire i vari
strati del Web Semantico. Vedremo cos’è un’ontologia, e perché il suo ruolo è
tanto importante in questo contesto. Esamineremo delle ontologie, pensata
mettendone in evidenza tutta una serie di features. In particolare creeremo
un’ontologia su un database, e su di essa effettueremo un’inferenza ad hoc.
Successivamente
mostreremo
come
inferire
conoscenza
mediante
l’interoperabilità di differenti ontologie dislocate in punti diversi. I risultati
sperimentali saranno presentati nell’ultima parte di quest’elaborato dove degli
opportuni commenti evidenzieranno le parti più interessanti del codice Java scritto
per realizzare l’inferenza prima citata.
7
Capitolo 1
Il Web semantico
1.1 Introduzione
In questo capitolo introdurremo il concetto di Web Semantico e specificheremo
come l’informazione deve essere strutturata; faremo una breve panoramica sui
linguaggi sviluppati per realizzare la semantica dell’informazione. Inoltre
descriveremo il concetto di ontologia dal punto di vista informatico nel contesto del
Web Semantico.
1.2 Principi del Web Semantico
In un articolo molto noto, pubblicato nel maggio del 2001 sulla prestigiosa rivista
Scientific American, Tim Berners-Lee , James Hendler e Ora Lassila scrivono:
“Il SemanticWeb è un’estensione dell’attuale Web, nella quale all’informazione
viene dato un significato ben definito, permettendo così ai computer e alle persone
meglio
cooperazione”..[1]
di lavorare megl
io in cooperazione”
8
Nello stesso mese Tim Berners-Lee ad una conferenza del W3C ad Hong Kong,
afferma che:
”Nel prossimo futuro saranno possibili collegamenti telematici di qualunque genere
un’inedita
e un’
inedita forma del contenuto Web – il Web Semantico – darà impulso a una
vera e propria rivoluzione. “
Il Semantic Web è quindi una nuova entità vista come estensione dell’attuale Web
che ne aumenti l’efficienza. Sostanzialmente l’obiettivo del Web Semantico è
quello di aumentare l’usabilità del Web, permettendo agli utenti di effettuare
ricerche per ottenere dei risultati più inerenti.
Sta diventando dunque sempre più evidente la necessità di strutturare l’enorme
massa d’informazioni presenti in Internet in modo tale da permettere all’utente di
reperire ciò che realmente sta cercando e non ciò che gli assomiglia, ossia non
interessa recepire quelli che definiamo dei “falsi positivi” (documenti che non
forniscono nessun dato utile alla nostra ricerca). I motori di ricerca come Google,
non sono in grado di restituire l’informazione esatta, se si cerca infatti una cosa del
tipo “Madonna“ il risultato sarà del tipo:
Mappa di Madonna
Madonna del Sasso
ViaMichelin - Map24
9
Madonna.com
Madonna
- [ Traduci questa pagina ]
www.madonna
madonna.com/madonna
madonna/indexHtml.html
- 3k - 12 apr 2005 - Copia cache madonna
madonna
Pagine simili
APT - Madonna di Campiglio Pinzolo Val Rendena
Sito Ufficiale dell'Azienda di Promozione Turistica di Madonna di Campiglio,
Pinzolo e Val Rendena. Potete trovare tutte le informazioni per le Vostre ...
www.campiglio.net/ - 16k - 12 apr 2005 - Copia cache - Pagine simili
MADONNA MADONNA MADONNA - [ Traduci questa pagina ]
List of sites about Madonna.
Madonna
www.cbvcp.com/c2/madonna
madonna.html
- 27k - Copia cache - Pagine simili
madonna
Madonna University - [ Traduci questa pagina ]
Official web site--information for prospective students, alumni, parents, and
benefactors, including academic programs, online courses, faculty, ...
www.munet.edu/ - 14k - 12 apr 2005 - Copia cache - Pagine simili
Madonna Inn - San Luis Obispo, California - [ Traduci questa pagina ]
A landmark resort hotel on California's Central Coast for over forty-five years.
Imaginitive interior design and architecture make this inn a unique ...
www.madonna
madonnainn.com/
- 7k - 12 apr 2005 - Copia cache - Pagine simili
madonna
10
Ossia una serie di link che non risultano essere utili ai fini della nostra ricerca. Con
l’introduzione del Web Semantico sarà possibile associare una semantica1 ai dati
presenti nella rete esplicitandone il loro significato in modo da renderli utilizzabili
dalle applicazioni.
1.3 Obiettivi del Web Semantico
Gli obiettivi principali del Web Semantico sono: [2]
1. Facilitare l’automatizzazione dell’interazione tra agenti software ed
informazioni.
2. Accrescere il livello di fiducia dell’utente nella bontà delle risposte
ottenute dal Web Semantico.
3. Aumentare l’accessibilità dell’informazione.
4. Facilitare l’integrazione d’informazioni già presenti sul Web.
5. Aumentare l’efficienza dei motori di ricerca.
6. Realizzare dei sistemi di catalogazione dei contenuti e delle
relazioni tra pagine.
1 La semantica è un ramo della linguistica e, più in generale, della teoria dei linguaggi che studia il
significato dei simboli e dei loro raggruppamenti; nel caso delle lingue, studia il significato delle
parole, delle frasi, dei singoli enunciati. In logica matematica con semantica si intende quella
disciplina che, fissando l'insieme delle regole che presiedono all'interpretazione di un linguaggio
formale, studia le relazioni fra le formule del linguaggio e le entità extralinguistiche nei cui termini
vengono interpretate.
11
7. Creare degli insiemi di pagine che, pur appartenendo a domini
diversi, correlino le varie informazioni da un punto di vista
semantico.
8. Gestire i diritti d’autore e la proprietà intellettuale delle opere
d’ingegno.
1.4 I Servizi
ervizi Web
Una problematica strettamente legata con il Web Semantico è quella dei Servizi
Web. Il Web sta evolvendo da semplice deposito di testi, immagini e contenuti
multimediali a contenitore di servizi via via più complessi. In futuro ci sarà un
passaggio dal semplice accesso ad un’informazione, alla richiesta di un servizio
che realizza una transazione ossia uno scambio d’informazioni tra l’agente
dell’utente e l’agente del fornitore del servizio; tutto ciò in modo trasparente per
l’utente.
Attualmente le informazioni sul Web sono principalmente contenute all’interno di
pagine HTML. L’HTML è un linguaggio che permette di descrivere come
visualizzare delle informazioni, solitamente delle stringhe di testo o immagini.
Quindi una pagina HTML è semplicemente testo, collegamenti ipertestuali e
immagini. Per fornire dei servizi che non prevedono l’interazione diretta da parte
dell’utente con la pagina stessa possiamo pensare di scrivere dei programmi che,
12
partendo da conoscenze preacquisite riguardanti la pagina, estraggano da essa
l’informazione voluta. Ciò ci porta alla facile deduzione che la quantità di risultati
sbagliati, che non soddisfano la nostra richiesta, sia molto alta. Ciò è legato al fatto
che HTML descrive solo le informazioni per la visualizzazione dell’informazione la
quale sarà poi fruita da un essere umano, il quale è dotato di una sua intelligenza
che gli permetterà di capire cosa è attinente alla ricerca e cosa non lo è. È chiaro
dunque, che ciò di cui necessitiamo è un agente intelligente in grado di riprodurre il
comportamento dell’essere umano. Un modo per aiutare un agente siffatto è
quello di introdurre un linguaggio che consente di definire la semantica di un testo.
Si può pensare di riscrivere un documento marcandolo con delle stringhe che ne
facilitino la comprensione. In questo modo la comprensione del testo da parte di
un agente deriverà dalla capacità che esso ha di capire il significato dei marcatori.
1.5 La rappresentazione della conoscenza
I vari problemi connessi con il Web semantico sono in prima battuta problemi di
rappresentazione della conoscenza (KR Knowledge Representation). Se in un
database locale il significato di ogni singolo campo è ben noto a tutti, quello che si
sta prefigurando per il Web semantico è una situazione nella quale ognuno possa
definire i propri campi con un proprio significato. L’idea del Web semantico è di
realizzare un modello base comune per tutti, che permetta la strutturazione
13
dell’informazione e al tempo stesso l’esplicitazione della semantica. Una delle
linee guida nello sviluppo di nuovi linguaggi è sempre stata l’idea che il
miglioramento di un linguaggio di KR dovesse andare nella direzione del
miglioramento della sua capacità espressiva. Questa visione del mondo, in cui una
KB (Knowledge Base) rappresenta l’intero insieme di credenze che un’entità
ragionante ha su di un determinato dominio, porta alla necessità di linguaggi che
abbiano la capacità di fornire strumenti per esprimere profondi legami relazionali
tra oggetti e che forniscano allo stesso tempo mezzi per realizzare dell’inferenza
sulla KB stessa.
Tuttavia si sta formando l’idea che questa teoria debba essere cambiata per
quanto riguarda Internet ed il World Wide Web. Da un certo punto di vista il WWW
è di per sé una KB: una massa enorme di informazioni che possono essere
raccolte da un agente e sulle quali si possono effettuare delle interrogazioni. Se
consideriamo però che ogni pagina presente in rete contiene un’informazione ci
rendiamo facilmente conto che la mole di dati raccolta in questa KB metterebbe in
crisi qualsiasi sistema di KR.
Questo è dovuto al fatto che molti dei linguaggi attuali di KR hanno aumentato la
loro capacità espressiva generando in parallelo un aumento della complessità
computazionale. È infatti noto che gli attuali motori inferenziali che stanno alla
14
base di molti linguaggi di KR hanno complessità NP-hard2. Un altro grosso
problema è quello che difficilmente è pensabile un agente che sia in grado di
raccogliere tutte le informazioni presenti sul Web. Altro aspetto critico è la forte
dinamicità del Web. Certe pagine sono statiche nel tempo, altre cambiano ma
senza modificare il loro contenuto semantico, altre nascono, mentre altre vengono
rimosse.
Agenti
Intelligenti
Documenti
Ontologie
Knowledge
Markup
Database
Web
Semantic
Applicazioni
Figura 1:
1: Struttura concettuale del nuovo Web
1.6 I nomi delle risorse:
risorse: URI
Per poter descrivere le conoscenze che abbiamo sul mondo dobbiamo poter dare
un nome univoco agli oggetti in esso contenuti, siano essi materiali o immateriali.
2 Problemi NPNP-hard sono tali che un algoritmo per risolvere uno di questi problemi può essere
convertito in un algoritmo per risolvere un qualunque problema NP. In pratica, questi problemi sono
almeno complicati quanto un qualunque problema NP, anche se potrebbero esserlo di più.
15
Dobbiamo per prima cosa capire come si possano nominare oggetti e relazioni in
modo non ambiguo. All’interno del Web Semantico viene utilizzato il concetto di
URI (Universal Resource Identifier) per ogni oggetto di cui si voglia parlare. Il
controllo delle URI, a differenza dell’URL (Universal Resource Identifier), delle
particolari URI che oltre a identificare la risorsa sul Web la localizzano, è
decentralizzato e ciò comporta alcuni problemi. Infatti si potrebbe avere uno stesso
nome per due oggetti diversi, o anche URI diverse che si riferiscono alla stessa
risorsa, ciò non accade perché il nome di una risorsa sarà dato da una URI seguita
dal simbolo # seguito a sua volta dal nome vero e proprio. Ogni nome diverso di
questo tipo identificherà una risorsa diversa. Questo meccanismo permetterà di
domiciliare nomi diversi alla stessa URL, ossia nella stessa pagina.
Quello che è importante capire è che la URI non è un indirizzo che consente ad un
browser di trovare un file sul Web, ma è il nome di una risorsa. La URI può o meno
fornire informazioni aggiuntive sull’oggetto che identifica.
1.7 Gli strati del Web semantico
Ora continuiamo la nostra panoramica sul Web Semantico definendo una struttura
di tipo gerarchica in cui sono presenti i linguaggi preposti per realizzare le funzioni
che deve ricoprire il Web Semantico. E’ costituito come già detto attraverso vari
16
strati sovrapposti di linguaggi dove ogni nuovo strato usa o estende quelli
precedenti. L’insieme di questi livelli è raffigurato in Figura 2:
Figura 2.
2. Strati dell’architettura del Web Semantico
1.7.1 L’XML
XML è utilizzato per creare una struttura “digitale” dei documenti, cioè i documenti
sono rappresentati in maniera tale da poter essere interpretati da un computer,
affinché le informazioni immesse possano essere elaborate, memorizzate e
ricercate. Prima di tutto, si deve definire una struttura logica del documento (che è
comune a tutti i documenti di quel tipo) e individuare i suoi componenti: ognuno di
questi è un elemento XML ed è legato agli altri da vincoli di dipendenza; tutti gli
elementi che compongono un documento assumono una struttura ad albero:
l’elemento principale è la radice, gli altri sono i suoi sottoelementi, sono a loro volta
rami o foglie a seconda che abbiano o no dei discendenti.
Ogni elemento può avere degli attributi che ne descrivono le proprietà. Si noti che
la strutturazione di un documento in questi termini non è immediata: alcuni aspetti
17
possono essere rappresentati sia come elementi sia come attributi e da alcuni tipi
di documento non è possibile ricavare una struttura perfettamente ad albero.
La struttura fisica di un documento XML è formata di entità: un’entità è un costrutto
che rappresenta una parte del testo, ha una dimensione variabile (da un carattere
a tutto il documento) ed ha un nome, per permettere i riferimenti ad essa. Come gli
elementi indicano i componenti della struttura logica del documento, le entità
specificano la posizione di insiemi di byte: si deve fare in modo che questi due
aspetti siano correlati tra loro. L’insieme di comandi che stabiliscono questo
legame è il “markup”, ossia l’insieme dei “tag”: questi comandi sono distinti dal
testo mediante dei delimitatori e in pratica ciò che è racchiuso fra i simboli di
minore (“<”) e maggiore (“>”) costituisce il markup, che è la parte che è interpretata
dagli elaboratori. La forma è analoga (ma maggiormente rigida da un punto di vista
formale) a quella dei tag HTML, ma, se in questo caso danno solo indicazioni per
la formattazione delle informazioni, in un documento XML le informazioni
riguardano il tipo di dato compreso tra il tag di apertura e quello di chiusura.[3]
Come già detto, i documenti di un certo tipo hanno la stessa struttura; a questo
proposito la tecnologia XML consente di creare la dichiarazione di tipo di
documento o DTD (Document Type Definition), che rappresenta la definizione
formale di ogni tipo (analogamente allo schema, che, nell’ambito delle basi di dati,
stabilisce i vincoli per la strutturazione dei dati).
18
Una DTD specifica le caratteristiche di un certo tipo di documento, cioè gli
elementi, gli attributi e le entità: un documento che si conforma ad una DTD si dice
valido; se non è valido, potrebbe essere ben formato (cioè contenente un markup
comprensibile ma non conforme ad una DTD). Un documento XML deve
dichiarare a quale DTD si conforma, per verificarne la validità, ma tale
dichiarazione non è obbligatoria e il documento in questo caso non è considerato
né valido, né non valido.
I nomi delle proprietà possono anche essere associati a dei namespace, in modo
che la loro semantica non sia ambigua. Questi servono per identificare dei domini
applicativi in cui è garantita l’uniformità sintattica. XML, da solo, non è in grado di
realizzare una delle caratteristiche fondamentali del Web: i collegamenti
ipertestuali. Per questo motivo, è affiancato da uno standard, XLink, che permette
di inserire elementi in un documento in modo da creare e descrivere collegamenti
tra risorse: i link che si possono ottenere non sono solo di tipo unidirezionale e uno
a uno come nel caso di HTML, ma possono essere bidirezionali, uno a molti, molti
a molti. Come detto all’inizio, in un documento XML non devono comparire
informazioni o elementi che riguardino il modo in cui i dati vengono visualizzati.
Accanto ad XML esiste, quindi, una seconda specifica, XSL (eXtensible Style
Language), che permette di creare fogli di stile per specificare come il contenuto di
19
un documento XML debba essere visualizzato sul supporto scelto (browser,
stampante, e così via). Con questo strumento si realizzano gli scopi primari di
XML:
mantenere
separati
gli
elementi
di
contenuto
dagli
elementi
di
formattazione.[4]
1.7.3 L’RDF e l’RDFS
L’RDF e l’RDF-Schema (RDFS) vengono usati per esplicitare le relazioni tra
documenti e tra metadati3 permettendo di compiere asserzioni che contribuiscono
ad incrementare delle vere e proprie basi di conoscenza. Con l’RDF è possibile
formalizzare la conoscenza attraverso espressioni del tipo “soggetto-predicato-
oggetto” (detti statement), i cui termini e restrizioni operative sono definite in
apposite strutture chiamate RDF-Schema. Potremmo ad esempio asserire che
“Dante Alighieri è l’autore della Divina Commedia” e nello schema RDF relativo vi
saranno asserzioni che specificano cosa significa “essere un autore” e che ne
limitano l’applicazione ad un campo semantico ristretto che è quello delle “opere
letterarie”. In sostanza, mentre l’XML aiuta a dichiarare una struttura di
conoscenza, l’RDF aggiunge ad essa l’aspetto relazionale.
L’RDFS ha un sistema a classi, paragonabile a quello della programmazione ad
3
metadati sono letteralmente dati che descrivono dati, ossia esprimono parte di quello che c’è da
sapere su un certo insieme di dati e ciò che da tale conoscenza è possibile inferire mediante regole
di ragionamento.
20
oggetti: una collezione di classi è detta schema e le classi formano una gerarchia.
Il modello dei dati è rappresentato con un grafo, che schematizza gli statement: i
nodi del grafo sono le risorse descritte da RDF (pagine Web, insieme di pagine,
oggetti non direttamente accessibili via Web), gli archi sono etichettati con il nome
della proprietà relativa alla risorsa e sono direzionati dal nodo che rappresenta la
risorsa verso quello che ne indica il valore. Con l’RDF, ogni risorsa è identificata in
modo univoco sul Web, attraverso la sua URI (Uniform Resource Identifier) o URL
(Uniform Resource Locator).[5] Nonostante tutto, RDFS non dà la possibilità di
inferire conoscenze nuove a partire da quelle già esistenti, dunque, in quest’ottica,
si presenta la necessità di fornire un altro componente alla pila di livelli del Web
Semantico. Questo nuovo strato è quello delle Ontologie.
1.7.4 Lo strato delle ontologie
Gli strumenti linguistici messi a disposizione dallo strato degli Schemi sono
sufficienti per la creazione di collezioni di proprietà e classi organizzate in modo
gerarchico tra loro. Vedremo come questi vocabolari saranno le ontologie di
riferimento per il Web Semantico.
21
1.7.5 Lo strato logico
Lo strato logico consiste di regole che permettono di realizzare inferenza. Affinché
ciò sia possibile, c’è bisogno di implementare agenti software che siano in grado di
compiere deduzioni.
1.7.6 Proof
Un livello “proof” (prova) è stato concepito per permettere la spiegazione di
risposte generate da agenti automatici. Chiaramente, si potrebbe voler scegliere i
risultati dedotti dal particolare agente; questo richiederà la traduzione del suo
meccanismo interno di reasoning in un linguaggio di rappresentazione delle prove.
Alla base del Web Semantico ci sono le ontologie come è mostrato nella figura 2,
quindi è importante accennare cosa intendiamo noi per ontologia, il suo utilizzo nel
Web, inoltre vedremo successivamente che Kaon ha un suo modo proprio di
realizzare e interrogare le ontologie.
1.8 Le ontologie
Il termine “ontologia” è preso in prestito dalla filosofia. L’etimologia di questa parola
proviene dal greco: “on” sta per ente e “logos” per discorso. Infatti, nel gergo
22
filosofico l’“ontologia” rappresenta il discorso che concerne ciò che è, ovvero lo
studio dell’essere in quanto tale.
Ovviamente, nel nostro ambito un’ontologia assume un significato un po’ diverso:
“Un’ontologia è una specificazione formale ed esplicita di una concettualizzazione
condivisa” [Gruber].
Nel contesto delle scienze dell’informazione, un’ontologia è un documento che
indica in modo formale il significato e i legami fra termini ossia individua gli aspetti
che sono ritenuti rilevanti nel contesto e quelli che possono essere ignorati.
L’introduzione delle ontologie nel Web consente la strutturazione delle informazioni
e permette di superare alcuni aspetti critici del Web tradizionale. In primo luogo, le
varie sorgenti “producono” informazioni in diversi formati e la creazione di indici
per localizzare queste sorgenti è piuttosto complessa, poiché è molto difficile
ottenere indicazioni da sorgenti audio o video: un’ontologia può facilitare questa
operazione, descrivendo in modo formale i contenuti di ogni sorgente e aiutando
un utente nella ricerca di quelle sorgenti che generano un particolare tipo di
informazione.
Inoltre definendo mediante un’ontologia il contesto in cui è presentato un certo
documento, i termini utilizzati sono proprio di quell’ambito e quindi il loro significato
non è ambiguo.
L’ontologia
si introduce
proprio
per
ridurre
le
confusioni concettuali o
terminologiche in modo da avere un’interpretazione condivisa, in altre parole un
23
vocabolario comune, con un significato per i vari termini su cui tutti sono
d’accordo.
La gestione di quantità di dati enormi, quali quelle a cui intende rivolgersi il web
semantico, necessita di strumenti software di elevatissima affidabilità e
robustezza. Per lo sviluppo del Web Semantico l’uso dei database risulta di vitale
importanza per assicurare la persistenza dei dati e per consentire una consolidata
applicazione
di
politiche
di
sicurezza,
di
backup
e
di
recovery.[6]
24
Capitolo 2
KAON ToolSuite
2.1 Introduzione
Nel capitolo seguente presenteremo la piattaforma conosciuta come KAON,
descriveremo i componenti della suite di KAON, definiremo l’architettura di KAON
e descriveremo brevemente ogni singolo componente del ToolSuite tra cui OIMODELER, KAON API, KAON PORTAL.
2.2 La Piattaforma KAON
KAON (The KArlsruhe ONtology and Semantic Web tool suite) è una piattaforma
open source per la gestione di ontologie principalmente finalizzata
finalizzata ad applicazioni
commerciali. Essa include un insieme di componenti che permettono di creare e
25
gestire facilmente ontologie e fornisce un framework per la creazione di
applicazioni basate sulle ontologie. KAON applica le tecnologie del Web
Semantico agli scenari dell’e-commerce e del B2B (Business to Business). Proprio
per questo, robustezza e scalabilità sono due aspetti fondamentali di questa suite,
in quanto sono fattori di qualità chiave per ogni applicazione commerciale.
KAON è stato sviluppato da FZI e AIFB, presso l’università di Karlsruhe, in
Germania. L’infrastruttura Kaon è stata sviluppata e rilasciata con metodologia
Open Source. Il linguaggio con cui è stato sviluppato Kaon è Java e i files binari ed
i
sorgenti
sono
scaricabili
gratuitamente
da
Internet
(http://sourceforge.net/projects/kaon).
La licenza è GNU Library o Lesser General Public License(LGPL) e non viene
chiesta alcuna citazione (es. powered by).
I linguaggi naturali supportati sono l’inglese ed il tedesco.
2.3 Sistemi richiesti
KAON lavora con la JDK 1.4.1_01 della Sun (disponibile gratuitamente su
http://java.sun.com/products/archive/j2se/1.4.1_0.
• JBoss 3.2.1 (disponibile gratuitamente su http://www.jboss.org/)
26
2.4 Installazione
Per installare KAON bisogna prelevare il file zip dal sito http:/sourceforge.net/ e
scompattarlo all’interno di una directory. Bisogna poi settare la variabile di
ambiente KAON_ROOT con il nome della cartella in cui è stato decompresso
KAON.
2.5 Componenti del ToolSuite di KAON
Una illustrazione del KAON ToolSuite e dei suoi componenti è rappresentata nella
figura seguente:[7]
Figura
Figura 3: Tool di KAON
27
Il componente KAON è costituito di KAON Frontend e KAON Core il quale, a sua
volta, include una serie di moduli per la creazione e gestione delle ontologie.
Il Frontend è rappresentato da due applicazioni sviluppate per essere
immediatamente utilizzate dagli utenti e sono:
KAON Workbench,
Workbench, che fornisce un ambiente grafico per la manipolazione
delle ontologie; esso include l’OI
OIOpen
OI-Modeler che è un editor grafico e l’Open
Registry che fornisce i meccanismi per la registrazione e la ricerca delle
ontologie in un contesto distribuito.
KAON Portal,
Portal, che è sostanzialmente un portale Web basato sulle
ontologie.
Il CORE di KAON supporta l’accesso programmatico alle ontologie includendo sia
le API sia le Implementation per una gestione locale e remota dei contenitori di
ontologie:
le KAON API e le RDF API forniscono un’interfaccia astratta per
accedere
ai
diversi
tipi
di
ontologie
indipendentemente
dal
meccanismo di immagazzinamento.
esistono inoltre tre diverse implementazioni delle KAON API e delle
RDF API: le implementazioni sono l’Engineering
Engineering Server
Server, che è un
server di ontologie basato su di un database; l’RDF
RDF Server,
Server che può
essere usato per immagazzinare e accedere ai moduli RDF; le
28
APIonRDF che sono un’implementazione realizzata per operare con
file RDF locali o remoti.
I KAON EXSTENSIONS sono un insieme di componenti aggiuntivi non inclusi
nella distribuzione standard di KAON ossia non inclusi nella versione 1.2.7.
DLP (Description Logic Programs) supporta un efficiente reasoning di
ontologie.
KAON Server può essere considerato come un Application Server per
il Semantic Web, che fornisce un’infrastruttura generica per facilitare
l’ingegneria plug’n’play delle applicazioni basate sulle ontologie.
KAONtoEdit è un plug-in per OntoEdit4 che permette di lavorare
direttamente su implementazioni delle KAON API per caricare,
modificare e immagazzinare i modelli ontologici.
TextTo
TextToOnto è un tool basato su KAON che supporta il processo della creazione
delle ontologie fornendo una collezione di strumenti indipendenti per il
mantenimento e l’apprendimento dell’ontologie.
4
OntoEdit è un tool commerciale grafico basato su Java, per lo sviluppo ed il mantenimento di
ontologie, realizzato dalla ontoprise GmbH a partire dall’architettura progettata da Siegfried
Handschuh dell’Università di Karlsrhue. Il tool si basa su un potente modello interno di ontologia.
Questo paradigma supporta linguaggi di rappresentazione schematizzandoli il più possibile per
concetti, relazioni e assiomi.
29
2.6 Archi
Architettura
rchitettura di KAON
Figura 4: l’architettura di KAON
La figura precedente illustra le interazioni tra le API di KAON e i moduli sottostanti
mettendo in risalto il ruolo centrale delle API.
Ogni Client, per esempio l’editor ontologico di KAON ossia l’OI-MODELER, accede
tramite le KAON API alle ontologie indipendentemente dal meccanismo di
immagazzinamento.
APIonRDF rappresenta un’implementazione delle KAON API per accedere ai dati
RDF attraverso le RDF API. Per RDF API esistono due diverse implementazioni,
30
da un lato un’implementazione su memoria principale ed include un RDF parser e
un serializer; dall’altro, un’implementazione data dall’RDF Server che supporta le
RDF API in remoto e permette l’immagazzinamento persistente dei moduli RDF in
database relazionali.
A destra della figura ci sono le API proxy, un’altra implementazione delle KAON
API che consentono al client di interagire con i vari tipi di Engineering Server
(Direct, Local, Remote) anche questi ultimi basati su database relazionali.
2.7 KAON API
Per consentire un accesso programmatico alle ontologie, KAON mette a
disposizione tutta una serie di interfaccie java che costituiscono le KAON API.
Queste realizzano il supporto necessario affinché KAON possa creare, modificare,
memorizzare e interrogare le ontologie.
Dal punto di vista implementativo il modulo KAON API viene distribuito col file
kaonapi.jar ed è ben organizzato in diversi package.[8] I package più interessanti
sono:
oimodel:
oimodel contenente interfacce che rappresentano varie ontologie ed entità;
change:
change contenente le classi necessarie per l’aggiornamento di ontologie e relative
istanze;
util:
util contenente le classi relative a diverse funzioni di utilità;
31
vocabulary:
vocabulary contenente le classi che definiscono i nomi di alcuni ben noti concetti e
proprietà.
La presenza di package e classi da includere si rivela molto utile nella fase
implementativa in quanto consente di ridurre i tempi di sviluppo.
2.8 OIOI-Model
Una caratteristica interessante del framework KAON è quella di identificare l’unità
di informazione col cosiddetto OIOI-model (Ontology-Instance model). Un OI-model
può contenere definizioni ontologiche (concept e property) , e anche istanze
(instance). Questo modello è rappresentato attraverso un OIModel interface, che
gli permette di interagire con l’esterno. In particolare, i metodi relativi alla sezione
ontologia del modello OI sono racchiusi nell’interfaccia Ontology,
Ontology, mentre quelli
relativi
alla
sezione
istanze
dell’ontologia
sono
racchiusi
nell’interfaccia
InstancePool.
InstancePool
Ad ogni modo, queste due interfacce non vengono mai istanziate da sole, ma
sempre insieme a formare un modello OI.
La Figura 9 rappresenta graficamente la struttura dell’interfaccia del modello OI.
32
Figura 5: Interfaccia del modello OI
Nell’OI-model:
• un concetto è rappresentato attraverso l’interfaccia Concept che fornisce
metodi per recuperare informazioni del tipo superconcept o subconcept di un
dato concetto;
• una proprietà è rappresentata attraverso l’interfaccia Property che fornisce
metodi per recuperare informazioni come l’insieme dei concetti domain e
range;
• un’istanza è rappresentata attraverso l’interfaccia Instance che fornisce
metodi per recuperare informazioni quale, ad esempio, l’insieme dei
superconcept del concetto relativo a quella specifica istanza.
33
Inoltre un OI-model può includere altri OI-model: in questo modo un’ontologia può
riusare le entità (concetti, proprietà e istanze) definite nel modello incluso. Tale
tecnica è definita modularizzazione ed è uno dei punti forti di KAON.
2.9 Linguaggio ontologico di KAON
Il linguaggio ontologico di KAON è basato su RDFS, ma contiene alcune
estensioni proprietarie. Tra queste c’è la possibilità di definire una property come:
• simmetrica – se A “è amico di” B e la proprietà “è amico di” è simmetrica,
allora KAON deduce anche che B “è amico di” A.
• transitiva – se A “è amico di” B e B “è amico di” C, e la proprietà “è amico di”
è transitiva, allora KAON può concludere che A “è amico di” C.
• inversa – se A “è genitore di” B, e la proprietà “è figlio di” è l’inversa di “è
genitore
genitore di”,
di” allora KAON stabilisce che B “è figlio di” A.
Altre caratteristiche sono:
• Meta-modeling: concept e property possono essere trattati come istanze di
meta-concepts.
• Lexical entry: introducono informazioni lessicali sulle entità dell’ontologia e
sono caricate nell’ontologia stessa con una particolare struttura.
34
2.10 Root concept
Ogni OI-model include per default il root OI-model (che definisce solo il concetto
radice). Questo significa che tutte le classi di un’ontologia, per KAON, devono
essere organizzate in maniera gerarchica, dove il nodo “radice” è appunto il
concetto root. Secondo gli ideatori di questa piattaforma, includere un concetto
radice, dal quale tutti gli altri discendono, risulta più elegante e pratico nello
strutturare i modelli.[9]
In Figura 6 riportiamo un esempio di ontologia che rispecchia la struttura a radice
tipica di KAON.
Figura 6. Esempio di un’ontologia KAON
35
2.11 MetaMeta-modeling
KAON supporta il concetto del meta-modeling, il che significa che è possibile
trattare concetti e proprietà come istanze dei meta-concepts. Ossia un concetto e
un’istanza con la stessa URI possono esistere simultaneamente nello stesso OImodel. In questo caso l’istanza è chiamata spanning instance del concetto. In
particolare ogni volta che un concetto o una proprietà è aggiunta all’OI-model
automaticamente la sua spanning instance viene aggiunta anch’essa al modello.
2.12 Query
Strutturare i dati, modellando un dominio di conoscenza tramite le ontologie, deve,
poi, permettere ad un utente di recuperare informazioni.
KAON offre, ovviamente, la possibilità di interrogare le ontologie mediante un
semplice linguaggio di query. Chiaramente, questo linguaggio tiene conto
dell’ossatura delle ontologie: gli schemi RDF (RDFS) e gli statement (RDF). Una
caratteristica fondamentale è la possibilità di interrogare sia lo schema che le
istanze, oltre a poter fare interrogazioni anche tramite lexical entry.
36
2.12.1 Sintassi
Per realizzare le selezioni alle quali siamo interessati, KAON utilizza espressioni
concetto ed espressioni proprietà, che possono essere combinate per creare
espressioni più complesse.
2.12.2 Espressioni concetto
Un’espressione concetto può essere pensata come un concetto definito
intenzionalmente. Dalla valutazione di un’espressione concetto viene restituito un
insieme di istanze, che possono essere considerate come rappresentanti del
concetto citato. L’espressione più semplice è la cosiddetta espressione concetto
primitiva, che invoca semplicemente un concetto esistente. Nel linguaggio delle
query i concetti sono identificati dalle rispettive URI, che devono essere scritte
all’interno di parentesi quadre ([]). Per esempio, la seguente è un’espressione
concetto primitiva:
[http://wim.fzi.de/vision#Person]
questa restituisce il gruppo di istanze che sono instance del concept #Person
nell’ontologia http://wim.fzi.de/vision (questa è la URI logica dell’OI-model).
Comunque, scrivere l’intera URI può essere fastidioso in fase di scrittura. Se il
37
prefisso della URI del concetto coincide con la URI logica dell’OI-model, allora la
URI può essere omessa e la precedente query diventa:
[#Person]
Se il prefisso della URI non è lo stesso di quello dell’OI-model, allora la scrittura
della URI per esteso può essere evitata dichiarando un namespace:
WITH prefix AS ‘http://me.com/ontology/name#’
([prefix:Person])
Quest’esempio mostra anche che le query possono essere formattate su più linee,
favorendo cosi’la leggibilità.
E’ possibile riferirsi anche al concetto radice dell’OI-model; qualora volessimo farci
restituire tutte le istanze presenti nell’ontologia:
ROOT
Espressioni concetto più complesse possono essere costruite a partire da quelle
più semplici.
Per esempio, selezionare tutte le cose che vivono in una città può essere fatto
tramite:
SOME(<#lives_in>,[#City])
SOME prende due parametri: un’espressione proprietà e un’espressione concetto,
e restituisce l’insieme di tutte le istanze per le quali la proprietà assume valore nel
concetto. Nel nostro caso la query restituirà le istanze che hanno almeno
un’istanza di #lives_in che punta ad un elemento del concetto #City.
#City Avere
38
un’istanza di una property (property instance) significa che c’è un’instance per la
quale è stata definita la property. Le parentesi angolari (<>) delimitano la property
dal resto della query. Le espressioni proprietà primitive (espressioni che invocano
esattamente proprietà presenti nell’OI-model) vengono accedute tramite le loro
URI, allo stesso modo dei concetti. Ritornando all’esempio precedente, l’insieme
restituito è, appunto, quello di tutte le istanze per cui è definita la property
#lives_in;
#lives_in dunque, se ci sono, ad esempio, persone e animali che vivono in città,
tutte queste instance di #Person e #Animal verranno ritornate in un unico gruppo.
Per ottenere solo le instance di #Person che #lives_in #City dovremmo scrivere:
[#Person] AND SOME(<#lives_in>,[#City])
L’espressione AND prende due espressioni concetto e crea un nuovo concetto con
solo quegli elementi che appartenono ad entrambe le espressioni concetto.
Assumiamo, adesso, che vogliamo selezionare solo le cose che vivono a Berlino:
SOME(<#lives_in>,{!#Berlin!})
L’espressione concetto { } denota un concetto con esattamente quelle istanze che
sono esplicitamente elencate tra le parentesi graffe. In altre parole, {!#Berlin!} è un
concetto che contiene solo Berlino come singola istanza. I due punti esclamativi (!
!) sono usati per dire che l’identificatore al loro interno è un’istanza. Questa
interrogazione, dunque, restituirà tutte quelle istanze che hanno la property
#lives_in con il valore #Berlin.
#Berlin Altri modi per formulare la stessa query sono:
SOME(<#lives-in>={ !#Berlin! })
39
oppure
SOME(<#lives-in>=!#Berlin!)
Una sintassi simile a questa può essere usata se volessimo tutti gli oggetti con una
property avente un particolare valore, per esempio, con la property #name uguale
a “John Smith”:
SOME(<#name>='John Smith')
Tutte le costanti devono essere delimitate da apici singoli (‘‘, non è possibile
introdurre costanti contenenti gli apici) . La costante John Smith è equivalente al
concetto contenente solo un elemento. Tale concetto è un concetto dati (poiché
contiene dati, piuttosto che istanze). Non è concesso creare concetti che abbiano
dati, come pure istanze.
Un altro tipo di query che potremmo pensare di realizzare riguarda tutti gli elementi
per cui è definita una property avente valore in uno, ed un solo, elemento. Per
esempio, alcune persone possono lavorare in diverse città allo stesso tempo, e
quindi, vivere anche in più #City.
#City La query SOME(<#lives-in>=!#Berlin!) invoca
tutte le cose che vivono a Berlino, ma non mette restrizioni alla possibilità di una
“doppia residenza” . Se qualcuno vive anche a Roma, sarà comunque prelevato.
Per aiutarci, in questa particolare circostanza, dobbiamo far uso dell’espressione
ALL. Questa prende anch’essa come parametri una property e un concept e,
ritorna tutte le cose per le quali è definita quella proprietà, i cui valori devono
essere tutti e solo nell’espressione concetto. In altre parole, l’espressione:
40
ALL(<#lives-in>=!#Berlin!)
ci restituirà tutte le entità che vivono in Berlino, e solo in Berlino (dal momento che
questa espressione concetto contiene solo un elemento, #Berlin).
#Berlin
Comunque, il comportamento della ALL è particolare; infatti,verrano restituiti anche
tutti quegli elementi per i quali la property non è definita minimamente. Dunque,
affinché possiamo ottenere tutte le cose che #lives_in Berlino, e solo li’, dobbiamo
combinare due espressioni:
SOME(<#lives-in>=!#Berlin!) AND ALL(<#lives-in>=!#Berlin!)
La prima seleziona gli elementi per i quali siamo certi che vivano a Berlino, la
seconda prende entità viventi solo in questa città, e non anche altrove.
A parte l’intersezione di concetti è anche possibile rappresentare l’unione o il
complemento di insiemi di istanze. Se fossimo interessati a tutte le persone e tutti i
gatti dell’ontologia, potremmo risolvere con:
[#Person] OR [#Cat]
Se invece, volessimo tutte le istanze, a meno di quelle del concept #Person:
#Person
NOT [#Person]
L’ordine di precedenza da considerare per espressioni più complesse è il
seguente: NOT, AND, OR.
Data una property, possiamo anche chiedere:
• tutte le istanze per cui è stata definita la proprietà, come accade, ad esempio
con:
41
FROM(<#lives-in>)
L’effetto di questa query è lo stesso di SOME(<#lives-in>,ROOT)
• tutte le istanze alle quali punta:
TO(<#lives-in>)
L’effetto di quest’altra è lo stesso di SOME(INVERSE(<#lives-in>),ROOT).
INVERSE è un operatore che viene utilizzato per le property e restituisce invertiti i
campi domain e range della property.
2.12.3 Espressioni proprietà
Il risultato della valutazione di un’espressione proprietà è un insieme di tuple
(coppie), dove ogni tupla contiene due istanze o un istanza e un valore (Literal).
Per esempio, la query:
<#lives-in>
restituisce le coppie che collegano gli elementi dell’ontologia con i luoghi in cui
vivono.
Una più interessante espressione proprietà è:
INVERSE(<#lives-in>)
Questa ritorna l’insieme di tuple che contengono come primo elemento i luoghi, e
come secondo i soggetti che li abitano.
Assumiamo che una persona vive (#lives_in
#lives_in)
#lives_in una città, che è in (#is_in)
(#is_in una
nazione. Allora l’espressione proprietà:
42
<#lives-in>.<#is-in>
associa le persone con i Paesi in cui vivono. Per esempio, per selezionare tutte le
persone che vivono in Germania si può fare nel seguente modo:
[#Person] AND SOME(<#lives-in>.<#is-in>=!#Germany!)
E’ inoltre possibile ottenere un sottoinsieme di una proprietà. Data la property
#lives_in,
#lives_in sappiamo che essa collega le persone ai luoghi in cui vivono. Possiamo
volere un sottinsieme di questa proprietà, che connette le persone alle città
interessate, attraverso la seguente espressione:
<#lives-in> IN:2 [#InterestingCity]
IN:x prende come parametri un ‘espressione proprietà ed un’espressione concetto;
essa ritorna un sottoinsieme della proprietà per il quale l’oggetto alla posizione x (1
o 2) è istanza del concept specificato.
E’ anche possibile creare una nuova proprietà. Per esempio, possiamo inventare
una proprietà che lega tutte le persone interessate alle città interessate, usando:
CROSS([#InterestingPerson],[#InterestingCity])
CROSS prende due espressioni concetto e forma una property contenente tutte le
combinazioni dove la prima istanza viene dal primo concetto e la seconda dal
secondo concetto.
43
2.13 Query sullo Schema
In KAON, come detto non è possibile solo interrogare le instanze ma possiamo
anche interrogare lo schema. Interrogare lo schema significa in realtà interrogare i
concetti e per fare ciò si fa uso del meta-modelling: in particolare usiamo le
spanning-instance sulle quali è possibile effettuare delle query5.
Da quanto detto quindi interrogare lo schema significa interrogare delle “instanze”
che rappresentano il concetto da cui si vuole trarre le opportune informazioni.
2.14 OIOI-modeler: KAON Workbench
L’OI-modeler è un tool per la creazione e la gestione di ontologie. Un aspetto
importante di questo componente è la scalabilità per produrre ontologie grandi,
5
In effetti, non è possibile interrogare direttamente i concetti.
44
così come pure l’introduzione di alcune regole di utilità relative alla gestione di
ontologie. Gli algoritmi di layout del grafo sono basati su una open-source library,
la TouchGraph1.
Per far partire questa applicazione basta eseguire il file batch kaongui.bat che si
trova nella directory <kaon-root>/bin (dove per <kaon-root> intendiamo la directory
in cui è stato decompresso il file .zip contenente i file binary della suite KAON) .
La Figura 7 ci mostra l’interfaccia utente dell’OI-modeler con le sue numerose
finestre.[10]
Figura 7: KAON Workbench
Workbench
Ci sono 4 menù che sono messi a disposizione dell’utente e sono:
1.
Il menù File
45
2.
Il menù Edit
3.
Il menù View
4.
Il menù Procedures
2.14.1 Il menù File
Load Workspace
Carica un workspace contenente lo stato di
tutte le finestre dell’ultima sessione salvata.
Save Workspace
Salva un KAON Workspace.
Open OI-Model
Apre un’ontologia esistente. Se scegliamo
questa funzione, apparirà un’altra finestra nella
quale specificare quale OI-Model aprire e
Figura 8: Il menù File
come raggiungerlo.
46
Figura 9
Possiamo qui definire dove reperire l’ontologia da caricare: se vogliamo operare su
un’ontologia presente in locale, sul nostro disco rigido, scegliamo RDF Models e
allora dobbiamo specificare la URI fisica. Se, invece, l’ontologia dovesse essere
caricata da un server, selezioneremmo Engineering Server,
Server e specificheremmo il
nome del server, il porto e la URI logica. Se lavorarassimo direttamente con il
database, sceglieremmo Direct Engineering Server.
Server
47
Figura 10:
10: Apertura di un’ontologia sita su Direct Engineering Server
Create a new OIOI-Model
E’ la funzione per creare un OI-Model vuoto.
Copy to new OIOI-Model
Con questa opzione possiamo clonare un OI-Model ed, eventualmente salvarlo in
un database remoto.
Duplicate OIOI-Model
Apre una nuova finestra e duplica l’OI-Model in un nuovo OI-Model dello stesso
tipo memorizzandolo in locale.
Save
Save OIOI-Model
Salva l’OI-Model corrente.
48
Import
Apre una nuova finestra dove è possibile selezionare i file rdf e rdfs da importare.
Export
Permette di esportare l’OI-Model corrente memorizzandolo in altri file .rdf o .kaon.
2.14.2 Il menù Edit
Con questo menù si possono editare ontologie; per esempio, aggiungere e
eliminare concept, property o instance, inserire dei nodi nel clipboard, o aprire e
includere OI-Model nel workspace. Inoltre con le funzioni Undo e Redo è
concesso, rispettivamente, annullare e rifare l’ultimo passo di lavoro.
2.14.3 Il menù View
Questo menù rende disponibili una serie di funzionalità utili ai fini di una
visualizzazione ottimale delle ontologie.
2.14.4 Il menù Procedures
Permette di modificare l’interfaccia grafica in modo che l’utente possa usare
l’interfaccia con le funzioni per lui più interessanti.
49
2.15 Creare ontologie
Per lavorare con l’OI-Model possiamo creare una nuova ontologia o aprirne una
già esistente. Per crearne una ex novo selezioniamo la voce “Create New OIModel” del menù File. Per continuare a lavorare su un’ontologia esistente,
selezioniamo “Open OI-Model”, sempre dallo stesso menù.
Per introdurre un nuovo concetto, ci sono tre modi:
Usando la voce “New concept ”del menù Edit
Aprendo il menù contestuale (col tasto destro del mouse nella
finestra del grafo) e scegliendo “New concept”.
Cliccando nella finestra dell’inspector col tasto destro del
mouse.
In tutti e tre i casi apparirà la stessa finestra, in cui sarà anche possibile inserire
una label per il nuovo concetto.
In maniera analoga, si procede per creare una nuova property.
L’OI-Modeler distingue due generi di proprietà: Properties from a concept,
concept
proprietà che puntano ad altri concetti, costituendo attributi per il concetto
selezionato, e Properties to
to a concept,
concept che sono relazioni da altri concetti al
concetto selezionato. Questi due tipi di property, relativamente ai nodi che
collegano, vengono visualizzati con archi orientati di colori diversi.
In figura 11 rappresentiamo un esempio: la property owns
owns ha come soggetto una
person,
person e come oggetto un cat.
cat
50
Figura 11
Per person, owns è una “Properties from a concept” (la freccia tra questi è rosa),
mentre, per cat,
cat owns è una “Properties to a concept” (la freccia qui è verde).
Per specificare domain e range di una property possiamo selezionare la proprietà,
e cliccare col tasto destro del mouse sul concetto a cui siamo interessati: così
facendo, appare un menù contestuale, dove possiamo scegliere “Add To Property
Domain” o “Add To Property Range”.
2.16 KAON Portal
Portal
KAON Portal è una dimostrazione di come le API di KAON possano essere usate
per costruire portali Web basati sulle ontologie. Esso si rivela uno strumento utile
ai fini della navigazione di un’ontologia, e soprattutto, sostiene il proposito di
KAON di lavorare con ontologie multilingue.
51
Capitolo 3
KAON:
AON: I Componenti Remoti
3.1 Introduzione
In questo capitolo tratteremo gli altri componenti del KAON ToolSuite e in
particolare esamineremo due componenti essenziali per la memorizzazione e
gestione delle ontologie in remoto. Non avrebbe senso creare delle ontologie e
accedere a tali ontologie solo sulla macchina su cui sono state create anzi lo
scopo principale è quello di “donare” le ontologie al mondo, ossia permettere a
qualunque client di accedere su una macchina dove è situata l’ontologia cercata o
più in generale accedere ad un qualunque file RDF. Descriveremo i due
componenti RDF Server e Engineering Server, seguiremo la fase di istallazione
mostrando l’utilizzo che si fa di tali componenti.
3.2 RDF
RDF Server
L’RDF Server permette la memorizzazione persistente dei file RDF in database
relazionali. Il Server è realizzato con JBOSS, per questo per far funzionare l’RDF
52
Server bisogna prima di tutto istallare l’applicazione JBOSS dopodiché bisogna
settare la variabile d’ambiente JBOSS_HOME facendola puntare alla root della
distribuzione
di
JBOSS,
ad
esempio
nel
nostro
caso:
JBOSS_HOME
=C:\jboss\jboss-3.0.4
Prima di eseguire l’istallazione di RDF Server bisogna far partire JBOSS ossia
eseguire il file run.bat
run.bat situato nella cartella di JBOSS: C:\jboss\jboss-3.0.4\bin
C:
Eseguiamo successivamente il file deploy.bat nella cartella di KAON:
C:\kaon_bin\rdfserver
rdfserver\deploy.bat.
rdfserver
Così si esegue finalmente l’installazione dell’RDF Server. Eseguita anche
quest’ultima operazione il componente è pronto per essere usato ossia è possibile
caricare eventualmente dei file RDF o per meglio dire delle ontologie nel
particolare database utilizzato.
Nel nostro caso abbiamo scelto per realizzare il nostro database di utilizzare
MySql essendo questo DBMS di tipo freeware (vedi Appendice A).
Per ottenere ciò che ci siamo prefissati dobbiamo modificare alcuni file di JBOSS
in modo che JBOSS possa usare come DBMS di riferimento proprio MySql.
Tale configurazione di JBOSS si ottiene facilmente eseguendo i passi descritti nel
seguito, ma in generale la soluzione mostrata si adatta a qualsiasi DBMS anche se
i componenti di KAON sono stati testati utilizzando il DBMS MS Sql
Sql Server 2000,
2000
che è a pagamento.
Configurazione di JBOSS:
53
1. Creare un database: tale operazione viene eseguita semplicemente
utilizzando l’interfaccia utente di MySql, tipo “MySql-Front”.
2. Ottenere il JDBC driver per il database desiderato, nel nostro caso MySql,
che è un file .jar; tale file è chiamato connettore mysqlmysql-connector.jar
connector.jar,
.jar e non
è fornito da KAON ma è stato prelevato dal sito di MySql.
3. Copia tutti di file del JDBC driver nella cartella di JBOSS: C:\jboss\jboss
C:
3.0.4\server\default\lib, nel nostro caso il file da copiare è uno solo.
4. Nella cartella C:\jboss\jboss
3.0.4\server\default\deploy andiamo ad aprire il
C:
file mysqlmysql-service.xml6 con un editor di testo e modifichiamo il file nel
seguente modo: a) trovo il tag “JndiName” e assegno MySqlDS indicando in
questo modo che la sorgente dei dati per JDBC è il database MySql; b)
vado a cambiare la stringa di connessione JDBC facendola puntare al
database prescelto.
Di seguito riportiamo la parte del file mysqlmysql-service.xml modificata:
<attribute name="JndiName">MySqlDS</attribute>
<attribute name="ManagedConnectionFactoryProperties">
name="ManagedConnectionFactoryProperties">
<properties>
<config<config-propertyname="ConnectionURL" type="java.lang.String">
jdbc:mysql://localhost:3306/myOntologyDatabase
</config</config-property>
6
In questo caso il file è quello per configurare JBOSS per utilizzare MySql, se il DBMS è diverso il
file template sarà relativo all’DBMS utilizzato.
54
<config<config-propertyname="DriverClass" type="java.lang.String">
com.mysql.jdbc.Driver</configcom.mysql.jdbc.Driver</config-property>
property>
<config<config-property name="UserName" type="java.lang.String">
root</configroot</config-property>
<config<config-property name="Password" type="java.lang.String">
</config</config-property>
</properties>
</attribute>
In realtà i creatori di KAON presentano le procedure elencate utilizzando solo MS
Sql Server 2000 e come vederemo nei prossimi paragrafi per altri componenti non
possiamo utilizzare un qualsiasi DBMS.
Abbiamo dunque un componente per caricare e memorizzare in modo persistente
le ontologie; cerchiamo ora di caricare le ontologie in questo modulo RDF Server.
Ci sono due modi diversi per caricare le ontologie: entrambi i file che effettuano la
fase di caricamento sono contenuti nella cartella C:\kaon_bin\rdfserver\ e sono:
loader.bat in cui non viene fatta alcuna verifica sullo stato del database;
dbloader.bat in cui viene effettuata una verifica sul database: se pieno viene prima
svuotato e successivamente viene riempito con le informazioni relative alla nuova
ontologia. Nel presente lavoro ho testato entrambe le soluzioni; poiché anche la
55
sintassi è uguale presento di seguito il comando da lanciare via console per
utilizzare correttamente il file dbloader:
dbloader[<rdf
bloader[<rdf[<rdf-url>[<alias>[<defaulturl>[<alias>[<default-namespace>[<jdbcnamespace>[<jdbc-connectionconnection-string>[<driverstring>[<driverclass>]]]
Dove:
rdf-url è l’indirizzo fisico dell’ontologia.
alias e default-namespace sono i riferimenti logici che sceglie l’utente e il secondo
può anche essere omesso.
jdbc-connection-string (mysql://localhost:3306/myOntologyDatabase) è la stessa
stringa inserita nel file di configurazione.
driver-class, nel caso di MySql, è com.mysql.jdbc.Driver.
Quindi nel nostro caso la stringa del dbloader sarà:
uri:default-dbloader file:C:/kaon_bin/examples/data/jaguar.kaon onto uri:default
“jdbc:mysql://localhost:3306/myOntologyDatabase;UserName=root;
password= “ com.mysql.jdbc.Driver.
L’utilità di tale componente, almeno per questa versione di KAON, è limitata al solo
immagazzinamento di file RDF: di fatto tutti i tool grafici che servono per costruire
ontologie, come ad esempio KAON Workbench, si servono del solo componente
Engineering Server che, oltre a permettere l’immagazzinamento persistente delle
ontologie, consente di modificarle a seconda delle necessità del client.
56
3.3 Engineering Server
Quando costruiamo grandi ontologie l’uso di un Database Management System
risulta essere inevitabile. Per gestire le interazioni con il database system, KAON
include un modulo chiamato appunto Engineering Server le cui caratteristiche
principali sono:
Transazioni.
Meccanismo di scambio di notifiche.
Caricarmento degli elementi delle ontologie.
Modularizzazione all’interno dello stesso database.
In breve, possiamo definire l’Engineering Server come un meccanismo di
immagazzinamento per le ontologie di KAON, basato sui database relazionali e
adatto per la creazione
creazione e la gestione delle ontologie.
Inoltre è importante ricordare che tale componente, creato dallo stesso
sviluppatore di KAON, Boris Motik, è stato testato con un’ontologia consistente di
100.000 concetti, 66.000 proprietà e 1.000.000 di instanze.
57
3.4 L’Accesso ai database
L’Engineering Server è un server per le ontologie ed è ottimizzato per la
progettazione di queste ultime. Questa ottimizzazione in particolare è riflessa nello
schema del database usato dal server. Poiché l’ingegneria delle ontologie
coinvolge la creazione e la cancellazione di concetti, che dovrebbero avere
capacità multi-utente e transazionale, l’Engineering Server prevede un database
con un numero fissato di tabelle. Lo schema impiegato dall’Engineering Server è
presentato nella figura sottostante:
Figura 12
12
Come si può notare, lo schema è formato da un numero fisso di tabelle; esso offre
un accesso scalabile, simultaneo e transazionale alle informazioni dell’ontologie.
L’Engineering Server si distingue dagli altri componenti anche per la particolarità
dello schema del database, infatti gli altri componenti memorizzano le istanze di
uno singolo concetto in tabelle separate.
58
3.5 Scenari dell’Engineering Server
Ci sono diversi modi di usare l’Engineering Server (Direct, Local, Remote), in
generale però i client accedono all’Engineering Server attraverso un’appropriata
implementazione delle KAON API, come mostra la figura 4 del capitolo 2, e cioè
tramite le API proxy, le quali forniscono informazioni al client circa l’ontologia che
si intende utilizzare e si occupano di rilevare le inconsistenze tra i dati nella cache
locale e quelli presenti nel database.
Direct Engineering Server consiste in un’architettura a due livelli (database e
Engineering Server). Questo significa che l’Engineering Server accede al database
direttamente, anche se quest’ultimo può essere situato su una macchina
differente. Il Direct Engineering Server è utilizzato in molte applicazioni, soprattutto
in quelle in cui non è necessaria la notifica distribuita degli eventi di
aggiornamento, pertanto rappresenta a tutti gli effetti la variante più semplice per
l’uso dell’Engineering Server, e non richiede, infatti, neanche l’utilizzo di JBOSS.
Per il Remote/Local Engineering Server è richiesto anche l’utilizzo di JBOSS e
quindi questa soluzione si presenta come un’architettura a tre livelli. Il vantaggio
principale è che permette la notifica degli aggiornamenti verso i client, che, quindi,
possono essere informati in tempo reale di eventuali modifiche apportate
59
all’ontologia. Dunque questo tipo di Engineering Server può servire da base per
una collaborazione tra più client.
Per i nostri scopi il vantaggio fornito dal Direct Engineering Server, ossia la
semplicità di connessione, è rilevante: per questo motivo nella nostra trattazione ci
soffermeremo sull’utilizzo del Direct Engineering Server.
3.6 Direct Engineering Server
Installazione:
La prima fase dell’istallazione del Direct Engineering Server prevede la creazione
del database sul server e il caricamento del relativo schema.
Di seguito presenteremo le fasi che portano all’istallazione del componente:
1. Installare il DBMS che nel nostro caso è MS Sql
Sql Server 2000 (vedi
Appendice A).
60
2. Creare un nuovo database con il proprio tool di gestione del database
che nel nostro caso è l’Enterprise Manager (vedi Appendice A).
3. Usare SQL Query Analyzer per eseguire lo script schema.sql situato:
C:\kaon_bin\engineeringserver\schema\. Questo script creerà lo schema
sul nostro database.
Nella figura che segue presentiamo come MS Sql Server 2000 esegue lo script
che crea lo schema tramite SQL Query Analyzer.
Figura 13: SQL Query Analyzer
Dopo aver eseguito i passi appena descritti l’Engineering Server è pronto per
essere usato nella sua versione direct. Ora utilizzando l’OI-Modeler possiamo
creare un’ontologia, che, come visto nel capitolo 2, KAON definisce OI-Model, e
salvarla direttamente su un database remoto.
61
Infatti utilizzando il menù file del KAON Workbench e in particolare le funzioni
Create a new OIOI-Model (se voglio creare un nuovo OI-Model), Open (se voglio
aprire un OI-model già esistente) potrò operare su OI-Model siti anche su
macchine diverse. In una schermata come quella mostrata in figura 10 (Capitolo 2)
si presenta l’apertura di un OI-Model dove le informazioni come Database e
Logical OI-model URI possono variare a seconda di dove è situato l’OI-model che
si vuole considerare.
Le altre informazioni, come il porto e il Driver, sono strettamente legate al tipo di
DBMS che si intende utilizzare. Se scegliamo la funzione per creare l’OI-Model sul
database e intendiamo usare il Direct Engineering Server, assegneremo all’OIModel un riferimento logico, il nome del database su cui deve essere creato, e
imposteremo gli altri parametri come nella figura che segue:
62
Figura 14
14
Una volta creato, il nuovo OI-MODEL sarà caratterizzato da una certa URI del tipo:
direct://user_name@
direct://user_name@host:port/Driver/DatabaseName?L
host:port/Driver/DatabaseName?Logical
ogicalURI dove:
direct indica che si è scelto la modalità Direct Engineering Server
user_name è quella predefinita.
host solitamente rappresenta l’indirizzo IP della macchina su cui è situato il
database..
port indica la porta usata, che nel caso di MS SQL SERVER 2000 è la 1433
DatabaseName è il nome scelto dall’utente per il database su cui si memorizza
l’OI-Model.
63
Logical
ogical URI è un riferimento logico che viene dato all’OI-Model, infatti su uno
stesso database potremmo avere diversi OI-Model, l’importante è che la Logical
URI sia unica.
Se si seleziona nel menù file del Workbeanch la voce Copy to new OIOI-Model,
Model,
come sottolineato nel capitolo 2, viene creato un nuovo OI-Model identico a quello
precedente nel nostro database con una differenza sostanziale: su una copia non
possono essere effettuate eventuali modifiche all’OI-Model. Facciamo un esempio:
supponiamo di avere in memoria centrale un certo OI-Model; se creiamo una copia
di questo OI-Model nel nostro database, e successivamente apriamo, sempre
attraverso il KAON Workbeanch, la copia presente nel database, su di essa non
potremo effettuare nessuna operazione: non potremo di fatto né aggiungere né
rimuovere alcun elemento ma ci è permesso solo di navigare l’OI-Model per
reperire eventuali informazioni utili.
Questa soluzione scelta da KAON può sembrare in un primo momento una scelta
inopportuna, ma in realtà non lo è, poiché si può pensare di voler fornire al
“mondo” gli OI-Model garantendo che la loro struttura non subisca alterazioni. Si
immagini, come esempio, di fornire l’ontologia dei propri dati che nessuno dovrà
cancellare o modificare. Tale tecnica cerca quindi di preservare un determinato OIModel inalterato.
Nei prossimi capitoli affronteremo un esempio d’inferenza dove l’OI-Model è
situato su una macchina diversa da quella del client grafico e apparirà più evidente
64
la semplicità con cui Direct Engineering Server permette di memorizzare,
modificare e caricare OI-Model siti su macchine remote.
65
Capitolo 4
Risultati Sperimentali
4.1 Introduzione
Nei precedenti capitoli abbiamo descritto KAON e i suoi componenti in particolare
ci siamo soffermati sul fatto che ora le ontologie, che in KAON vengono definite
OI-Model, non sono necessariamente presenti sulla memoria di massa in locale
ma possono essere situate su host diversi. La domanda che ci si pone è la
seguente: possiamo dedurre delle informazioni da un OI-Model già esistente?
Ossia: possiamo fare delle inferenze? La risposta dovrebbe essere negativa
poiché la versione di KAON da noi studiata, la 1.2.7, non permette di fare delle
inferenze, almeno in modo automatico poiché non fornisce nessun motore
inferenziale. Nella figura 4 del capitolo 2 abbiamo preso in considerazione
l’architettura di KAON: come si può notare la parte centrale di tale architettura è
occupata dalle KAON API e, grazie a quest’ultime, possiamo effettuare delle
deduzioni su OI-Model già esistenti modificandone se è necessario la struttura,
aggiungendo eventuali concetti, istanze o proprietà.
66
In questo capitolo ci occuperemo di esaminare alcune API di KAON di particolare
interesse, inoltre forniremo due esempi d’inferenza: nel primo caso aggiungeremo
una nuova proprietà allo schema dopo aver rilevato le opportune informazioni
utilizzando le opportune query. Nel secondo caso forniremo un esempio in cui gli
OI-Model sono due e situati su due database diversi: il caso che prenderemo in
considerazione è un’esempio di ricerca fatta sul Web Semantico in cui l’inferenza
sarà realizzata a partire dalle informazioni residenti sui due database.
4.2 Il Concetto di Inferenza
“Inferire” delle informazioni a partire da alcune già note esplicitamente, significa
fare delle deduzioni. Infatti, lo strato logico del Web Semantico intende far
realizzare ragionamenti ad un calcolatore, in modo da simulare un’Intelligenza
Artificiale. I meccanismi, tramite i quali si cerca di perseguire questo obiettivo
trovano riscontro in modalità di ragionamento già esistenti. Basti pensare al modo
di procedere del sillogismo aristotelico,
aristotelico oppure ai risultati che è possibile
raggiungere attraverso una funzione composta,
composta così come intesa in matematica.
Aristotele presentò per la prima volta il seguente modo di fare elaborazioni:
“Se l’uomo7 è un animale, e un animale mangia la carne, allora l’uomo mangia la
carne” .
7
Aristotele identificava con Uomo sia l’universo femminile che l’universo maschile.
67
Questa tecnica non è molto dissimile da quello che produce una funzione
composta:
Se f:A -> B , e g:B -> C , allora fog:A -> C
Tutto ciò costituisce il presupposto per capire meglio cosa si vorrebbe realizzare
tramite un’inferenza. Generalmente per ottenere un’inferenza è necessario
utilizzare dei motori inferenziali (inference engine), che sono dei componenti
software i quali svolgono il reasoning
reasoning,
inferenziali Una regola
ning elaborando le regole inferenziali.
inferenziale è, in effetti, una stringa di testo, che così come una query, viene
passata come parametro a particolari metodi che la sappiano interpretare.
Possiamo facilmente immaginare la potenza di questa tecnica, e soprattutto la
rilevanza che essa viene ad avere in un contesto in cui si vuole arricchire di
semantica l’informazione. Infatti, se ci riconducessimo al caso di un’ontologia con
un consistente numero di concetti, proprietà e istanze, e definissimo diverse regole
di inferenza, otterremmo risultati sensazionali e forse inattesi in termini di nuove
informazioni disponibili.
Non avendo KAON a disposizione un motore inferenziale, presentiamo di seguito
alcuni esempi di ontologie e relativi, semplici, motori inferenziali sviluppati ad hoc.
68
4.3 L’ontologia dei laure
laureati.
Questa ontologia è il frutto delle nostre considerazioni sulle caratteristiche di
KAON. Essa è un esempio di piccole dimensioni, il che è chiaramente voluto, in
quanto i modelli di grosse dimensioni sono più difficili da gestire. Tra l’altro, il
problema della scalabilità è un punto cruciale per chi si occupa di manipolare
questi grafi; pensiamo, in particolare, a coloro i quali si trovano a dover lavorare
con ontologie caricate sul Web, che rappresentano la struttura di un intero dominio
di conoscenza, presumibilmente molto vasto. A noi basta che il modello inventato
si presti bene alle analisi che intendiamo effettuare.
Il punto di partenza, nella creazione di questa nuova ontologia, è l’inclusione degli
OI-model del root ฀invers delle lexical entries. Utilizzando il KAON Workbench, ci
accorgiamo che questi due OI-model vengono aggiunti per default, sempre,
quando facciamo nascere un nuovo OI-model. Questo è, ovviamente, un aspetto
originale, che distingue KAON da un qualunque altro tool.
Nel nostro caso l’ontologia deve essere creata sul database quindi bisogna
utilizzare l’Engineering Server, ma per il lavoro da noi svolto basta utilizzare il
Direct Engineering Server come descritto nel capitolo 3.
69
Ora partendo dal concetto Root andiamo a costruire tramite il KAON Workbench il
nostro OI-Model; riferendoci al capitolo 2 inseriamo i concetti Persona, Citta8,
Università.
niversità
Figura 15
Allo stesso modo aggiungiamo delle proprietà che sono:
situatain:
situatain
riferita alle università che devono essere situate in una certa città;
laureatoa:
laureatoa
riferita alle persone che sono laureate in una certa università;
8
L’accento che l’italiano predispone per parole come “città” e “università” in KAON “non “ è
supportato nel senso che quando assegnerà una URI al concetto inserito caratterizzerà tale URI
con una serie di simboli il cui utilizzo è poco pratico da usare per le operazioni che dovremo fare
con lo script java.
70
residentein:
residentein riferita alle persone residenti in una determinata città.
Aggiungiamo anche le istanze al nostro OI-Model e in particolare aggiungiamo
istanze del concetto Persona, al concetto Universita e al concetto Citta. In questo
modo abbiamo evidenziato ancora di più il fatto che, come nella programmazione
ad oggetti, qui i concetti sono le classi e le instanze sono oggetti di quella classe, e
dunque di quest’ultima specificano tutte le proprietà.
Figura 16
La figura precedente mostra le instanze del concetto Persona e del concetto Citta
e del concetto Universita.
71
Finalmente il nostro OI-Model è completo; a questo punto possiamo effettuare
un’inferenza: per far questo abbiamo le KAON API che ci permettono di accedere
da uno script java all’OI-Model modificandone, se si desidera, lo schema e
permettono l’uso di Query per ricavare le informazioni cercate.
Chiaramente, per produrre script java, abbiamo bisogno di un ambiente di
sviluppo, che oltre ad editare ci permetta anche di compilare ed eseguire i
programmi. Affinché si possano utilizzare tutte le interfacce, le classi e i relativi
metodi, occorre allegare al progetto java le librerie in cui risultano definiti questi
strumenti. Avendo lavorato con JCreator, abbiamo incluso tutti i file .jar,
.jar presenti in
<kaon-root>/lib; tra le librerie richieste abbiamo dovuto inserire anche i connettori
al database MS SQL SERVER 2000 presi dalla cartella <jboss-root>/deploy. Ciò è
stato fatto andando nel menù Project,
Project selezionando Project Setting,
Setting e copiando i
file .jar nella finestra Required Libraries.
Libraries
Il primo passo per inferire un’informazione è interrogare un OI-model e per far ciò
dobbiamo, innanzitutto, caricarlo in memoria, secondo una particolare struttura.
Per accedere all’OI-Model è richiesto l’utilizzo dell’interfaccia KAONConnection e
la conoscenza della URI fisica. Dunque, l’apertura viene realizzata tramite
chiamata al seguente metodo:
KAONConnection.openOIModelPhysical(String physicalURI)
Noi scriveremo:
OIModel oimodel = KAONConnection.openOIModelPhysical(String
72
physicalURI);
Bisogna però nel nostro caso aprire un OI-Model che risiede su un database
remoto, e per far ciò si deve prima impostare dei parametri di connessione che,
per il Direct Engineering Server, sono i seguenti:
KAON_CONNECTION
“edu.unika.aifb.kaon.engineeringserver.client.
.DirectKAONConnection”
SERVER_URI
“direct://u
“direct://user@host_
ser@host_name:port/Driver/
name:port/Driver/dbN
:port/Driver/dbName”
dbName”
JDBC_DRIVER
Il nome della classe del JDBC driver:
“com.microsoft.jdbc.sqlserver.SQLServerDriver”
com.microsoft.jdbc.sqlserver.SQLServerDriver”
La URI fisica in questo caso sarà del tipo:
direct://user@host_name:port/type/dbName?logical_model_URI
Adesso, dopo che l’OI-Model è finalmente aperto, per eseguire una query ci
serviamo del metodo OIModel.executeQuery(). Questo è uno dei tanti metodi che
è possibile richiamare sull’interfaccia OIModel. Esso prende come parametro una
73
stringa (String) e restituisce una java Collection. Dunque, sembra essere quello
che fa al caso nostro, dal momento che una query è appunto una riga di testo. Il
tipo di oggetti nella Collection varia a seconda del tipo di query. Se la query è
un’espressione concetto, allora la collezione contiene oggetti di tipo Instance, che
è una delle interface messe a disposizione da KAON. Se, invece, la query è
un’espressione proprietà, allora la collezione contiene oggetti di tipo Object[], dove
gli elementi della tupla restituita possono essere sia di tipo Instance sia di tipo
String.
Fino ad ora non abbiamo ancora menzionato come possiamo introdurre concept,
property ed instance in una ontologia già esistente e salvata in un file rdf, tramite le
API di KAON. Questa possibilità, offerta da KAON, verrà adoperata anche per
realizzare i nostri esempi d’inferenza.
4.3.1 Aggiungere un nuovo concetto
Per creare un nuovo concetto richiamiamo il metodo getConcept sull’OI-model:
Concept newconcept=oimodel.getConcept(m_sLogicalURI +"#newconcept");
Poiché il metodo OIModel.getConcept restituisce sempre un concetto (anche se
non c’è un concetto nel modello con la URI specificata), esso può essere usato sia
per creare nuovi concetti, che per accedere a quelli già esistenti. L’unico
parametro che dobbiamo passargli è la URI del concetto che viene creato o
invocato.
74
Chiaramente, nell’introdurre cambiamenti siamo sempre obbligati a rispettare delle
regole. Infatti, il concetto che inseriamo deve inserirsi nella struttura gerarchica a
radice dell’OI-model. Possiamo di fatto o appendere il nuovo concetto al concetto
root o potremmo anche far nascere un concept come sub-concept di uno
preesistente. Se volessimo questo per il concetto newconcept:
newconcept
Concept newconcept2 =
oimodel.getConcept( m_sLogicalURI +"#newconcept2" );
changes.add( new AddEntity( newconcept2 ) );
changes.add( new AddSubConcept( newconcept, newconcept2 ) );
oimodel.applyChanges( changes );
changes.clear();
oimodel.save();
E’importante non omettere oimodel.save(); altrimenti i cambiamenti non verranno
effettivamente apportati nell’OI-model.
E’importante sapere che ogni nuovo concetto che deve essere aggiunto all’OImodel (tramite AddEntity) deve però diventare subconcept di un altro
(AddSubConcept) .
4.3.2 Aggiungere una nuova proprietà
Analogamente ai concetti (OIModel.getConcept), una nuova proprietà può essere
creata attraverso OIModel.getProperty. Il seguente codice crea una nuova
75
proprietà, newproperty,
newproperty che ha come dominio newconcept e come range un altro
concetto che discende direttamente da root che noi chiamiamo concept1:
Property newproperty =
oimodel.getProperty( m_sLogicalURI +"#newproperty" );
changes.add( new AddEntity(newproperty) );
changes.add( new AddPropertyDomain(newproperty, newconcept ) );
changes.add( new AddPropertyRange(newproperty, concept1 ) );
oimodel.applyChanges( changes );
changes.clear();
oimodel.save();
Dunque i passi richiesti per introdurre una nuova proprietà sono:
•
creare una proprietà (oimodel.getProperty)
•
inserire la proprietà nell’OI-model (AddEntity)
•
definire il dominio della proprietà (AddPropertyDomain)
•
definire il range della proprietà (AddPropertyRange)
Per una sub-property possiamo servirci di AddSubProperty (superProperty,
subProperty )
4.3.3 Aggiungere una nuova istanza
Il codice seguente realizza la creazione della instance newinsta
newinstance
instance del concept
newconcept:
newconcept
Instance newinstance =
76
oimodel.getInstance( m_sLogicalURI +"#newinstance " );
changes.add( new AddInstanceOf(newconcept
newconcept,
newconcept newinstance ) );
oimodel.applyChanges( changes );
changes.clear();
oimodel.save();
4.3.4 Istanziare proprietà
proprietà
L’istanziazione di proprietà è simile a quella di concetti. Il prossimo frammento di
codice istanzia la property newproperty (newconcept
newconcept,
newconcept, concept1)
concept1 creando la
relazione newproperty tra l’istanza del nuovo concetto (x) e l’istanza del concetto
già esistente(y).
PropertyInstance x_ newproperty _y =
oimodel.getPropertyInstance(newproperty, x, y );
changes.add(
new AddPropertyInstance( x_ newproperty _y) );
oimodel.applyChanges( changes );
changes.clear();
oimodel.save();
Comunque c’è da sottolineare che oimodel.getPropertyInstance, così come
getInstance, getProperty e getConcept, non prende come parametri proprio quelli
riportati tra parentesi; vuole che si specifichi l’intera URI. Dopo aver descritto in
generale come attraverso le KAON API è possibile modificare l’OI-Model e
77
ricordando come vengono effettuate le query, descriviamo l’esempio di inferenza
che abbiamo sviluppato.
Dal nostro OI-Model sappiamo che tra le persone considerate alcune sono
laureate ma non tutte sono laureate alla stessa facoltà; la facoltà non è sempre la
stessa e a seconda di quale facoltà consideriamo la città in cui si sarà laureato lo
studente è diversa.
Descriviamo di seguito la formula inferenziale e i passi che abbiamo seguito per
ottenere il risultato cercato:
perso
“Se una pers
ona si è laureata alla facoltà Federico II essendo la Federico II situata
a Napoli, allora tale persona si è laureta a Napoli”.
Dunque per realizzare la seguente formula inferenziale bisogna:
Verificare quali tra le istanze del concetto persona sono effettivamente
laureate.
Controllare se la proprietà che voglio inserire, laureatonella,
laureatonella esiste già,
poiché sarà proprio questa proprietà a rappresentare l’inferenza: infatti la
formula richiede che, a valle di certe condizioni che siano verificate, si crei
da script java una proprietà tra i concetti Persona e Citta.
Effettuare una ricerca sulle università per sapere dove sono situate: a valle
di tale verifica inserisco tra le istanze una nuova istanza di proprietà.
78
Se ora apriamo il nostro OI-Model9 con la procedura consueta descritta nella figura
10 del capitolo 2, otteniamo un’immagine come questa:
Figura: 17
9
L’OI-Model deve essere attraverso il KAON Workbench nuovamente caricato poiché l’inserimento
di un elemento nell’OI-Model comporta una modifica anche alle tabelle del database.
79
Come si può facilmente notare lo script java(vedi figura 18) creato funziona
correttamente: di fatto si presenta nell’OI-Model una nuova proprietà che è proprio
la proprietà che volevamo inserire la quale presenta come dominio il concetto
Persona e come range il concetto Citta.
Figura 18
80
4.4 Piccolo motore inferenziale:
Come si è mostrato nel capitolo 1, quando in un attuale motore di ricerca si digita
una frase del tipo Madonna, molti dei risultati ottenuti non sono pertinenti con le
informazioni che volevamo ottenere.
Consideriamo ora il caso in cui un utente voglia conoscere delle informazioni sulla
dieta di persona. In tal caso con gli attuali motori di ricerca digitare una frase del
tipo “cosa mangia Luigi?” porterebbe a dei risultati che si discostano molto da
quello che si vuole ottenere.
Di fatto questo modo di effettuare la ricerca è improprio, nel senso che non
rappresenta un uso corretto dell’ utilizzo degli attuali motori di ricerca.
Ora mostreremo che con KAON il problema potrebbe essere risolto creando un
piccolo programma in java e utilizzando due modelli creati ad hoc per sapere cosa
mangia una persona in particolare sapere cosa mangia Luigi.
Questo esempio è da considerarsi per vari motivi:
Ricalca il sillogismo aristotelico: sul primo database creeremo un OI-Model
che rappresenti il sillogismo aristotelico, cioè introdurremo il concetto Uomo,
come sottoconcetto del concetto animale, affermeremo che l’animale si
nutre di carne e da queste informazioni dedurremo che l’uomo si nutre di
carne;
è un esempio di inferenza fatta a cavallo tra due OI-Model presenti su due
database diversi.
81
Ora rappresenteremo attraverso due figure la creazione degli OI-Model come si
ottengono utilizzando il KAON Workbench:
Descrizione
dell’OIdell’OI-Model
sul
primo
database:
In giallo sono mostrati il concetto Animale e
sottoconcetto Uomo (basta glissare col
tasto destro del mause sul concetto Animale
Figura: 19
e selezionare la voce New Concept). In rosa
è indicata la spanning-instance del concetto
Uomo.
Descrizione
dell’OIdell’OI-Model
sul
secondo
database:
In giallo è mostrato il concetto Carne con le
istanze Arrosto, Pollo, Salsiccia ancora
Figura: 20
La realizzazione del codice java ci permetterà di effettuare l’inferenza sul primo
database
realizzando
il
classico
sillogismo
aristotelico;
successivamente
82
scriveremo del codice java che ci permetterà di inferire che Luigi, un’istanza della
classe Uomo del primo OI-Model, mangia Arrosto, salsicce, etc... che sono istanze
del concetto Carne sito sul secondo OI-Model.
Di seguito descriveremo i passi compiuti per realizzare le operazioni sopra
descritte, evidenziando alcuni aspetti del codice che sono di particolare rilievo.
4.5 L’ inferenza
inferenza tra due database e il sillogismo
aristotelico:
Per realizzare il sillogismo aristotelico abbiamo compiuto i seguenti passi:
eseguiamo la connessione al primo database dove la URI fisica per la
connessione è la seguente:
direct://[email protected]:1433/MSSQL/MARCELLO?aristotele
Sa
Username di default
10.0.0.27
Indirizzo IP della macchina in cui è
sito il database
1433
Porta usata per default da MS Sql
Server 2000
MSSQL
Driver del DBMS utilizzato
MARCELLO
Nome del database utilizzato
83
Aristotele
URI logica dell’ OI-Model situato in
quel database
effettuiamo una query sul concetto Animale facendoci restituire la
spanning-instance del concetto Uomo10 dove il concetto Uomo è definito
come sottoconcetto del concetto Animale infatti, come già illustrato nel
capitolo 2, KAON permette di interrogare lo schema utilizzando il
paradigma del Meta-modelling;
effettuiamo una query sulla proprietà “mangia” che ha come dominio il
concetto Animale e come range il concetto Carne. Se il dominio sarà
proprio il concetto Animale allora deduciamo che l’Uomo mangia la
Carne.
10
Dove con il concetto Uomo intendiamo l’ umanità indistintamente dai sessi.
84
Figura: 21
Ora sappiamo che le istanze del concetto Uomo, essendo Uomo un
Animale, si nutrono di Carne e che Carne a sua volta è un concetto
definito anche in un secondo OI-Model dove presenta delle istanze.
Dunque dai passi che seguono potremo dedurre che un’istanza di Uomo
come Luigi mangia istanze di Carne del tipo Arrosto, Salsiccie etc...
effettuiamo la connessione ad un altro database che ha nome final e una
URI logica del tipo carne. La stringa di connessione questa volta sarà:
85
direct://[email protected]:1433/MSSQL/final
direct://[email protected]:1433/MSSQL/final?
carne. Possiamo subito far notare
final?carne.
che potevamo considerare anche due OI-Model residenti sullo stesso
database; l’importante è che i due OI-Model abbiano una URI logica
diversa;
effettuiamo una query sul concetto Uomo appartenente al primo OI-Model,
facendoci restituire tutte le sue istanze;
l’utente inserisce da tastiera l’istanza del concetto Uomo di cui desidera
conoscere la dieta;
per l’istanza scelta si prelevano le istanze del concetto Carne presente nel
secondo OI-Model.
Nella figura che segue si mostra uno script del programma java durante
l’esecuzione:
Figura: 22
86
Quindi quando un utente ora inserirà nel motore di ricerca la stringa “Cosa mangia
Luigi?” avrà immediatamente il risultato richiesto.
In appendice viene fornito il codice java per entrambi i tipi di inferenza con gli
opportuni commenti.
87
Capitolo 5
KAON Server
5.1 Introduzione
KAON Server può essere considerato come un’applicazione server per il Web
Semantico di cui la progettazione e lo sviluppo sono basati su applicazioni server
pre-esistenti. Il progetto del KAON Server è frutto della collaborazione di molti
programmatori anche esterni al gruppo di KAON: questi hanno fornito un notevole
contributo a Boris Motik e Daniel Oberle che sono gli ideatori del progetto. In
particolare KAON Server nasce per facilitare il riuso di moduli già esistenti tra cui
un immagazzinatore di ontologie e un editor per ontologie. KAON Server, come
presentato nella figura 3 del capitolo 2, è parte dell’estensione di KAON e lavora
grazie a JDK 1.4.1_03 disponibile al seguente link: http://java.sun.com/j2se/. Il
codice sorgente e i binari della Kaon Exstension sono invece reperibili al sito
http://sourceforge.net/projects/kaon-ext.
Nel presente capitolo ci soffermeremo a descrivere l’architettura di KAON Server,
la fase di installazione e l’utilità che se ne può trarre.
88
Prima di definire KAON Server cerchiamo di capire quali sono i requisiti di una
applicazione server per il Web Semantico.
Ci sono essenzialmente cinque gruppi di requisiti:
un server dovrebbe rispondere alle classiche funzioni statiche del Web;
devono essere garantite le funzioni dinamiche del Server quali come:
modifica dei dati;
immagazzinamento dei dati;
transizioni;
evoluzione e versatilità;
monitoraggio;
i client possono desiderare di collegarsi a distanza con il server con
protocolli differenziati e devono essere propriamente autorizzati;
il sistema deve essere pensato per facilitare un’estensione e una
riconfigurazione della struttura;
deve includere i requisiti che sono associati alla descrizione semantica dei
moduli software.
Ulteriori requisiti comuni per ogni applicazione server, e in particolare per il Web
Semantico, sono: a)la connettività; b)un modulo software che deve essere
raggiunto facilmente dai client per realizzare la particolare richiesta; c)la sicurezza
delle informazioni. KAON Server è stato creato proprio per rispondere a questi e
89
altri requisiti che sono indispensabili per il Web Semantico: esso raggrupperà molti
dei moduli software necessari al Web Semantico come mostrato nella figura
seguente.[11]
Applicazioni
Portal
OilEd
Ontology Editor
FaCT
Modulo
Software
XML Schema
Validator
Sesame
Rule-based
system
Racer
KAON RDF Store
Figura: 22
5.2 Architettura del KAON Server
90
Connettori
Nucleo per la gestione
Sicurezza
Componenti Funzionali
Figura: 23
5.2.1 I connettori
connettori
Un connettore gestisce la comunicazione della rete con il sistema attraverso uno
specifico protocollo di rete. Oltre all’opzione per collegare i connettori in modo
locale, ulteriori connettori sono sviluppati per offrire il collegamento a distanza, ad
esempio l’RMI (JAVA’s Remote Method Invocation).
91
5.2.2 Nucleo per la gestione
Il microkernel descritto è provvisto di un kernel di gestione che si occupa della
scoperta, dalla ripartizione e del caricamento dei componenti, che possono
finalmente eseguire una richiesta. Il Registro organizza gerarchicamente in
categorie le descrizioni dei componenti. Come il nome suggerisce, il gestore di
dipendenza permette invece di esprimere e controllare i rapporti fra i componenti.
5.2.3 La sicurezza
E’ realizzata da una serie di interconnettori ovvero sono delle entità software le
quali monitorano le richieste che vengono fatte ai componenti funzionali
(aggiornamento dati e operazioni di query), affinchè solo ai client correttamente
autenticati e autorizzati sia permesso accedere ai componenti funzionali. Ogni
componente può essere registrato presso parecchi intercettori che operano nella
parte anteriore garantendo in modo ancora più evidente la sicurezza.
L’insieme delle generiche funzionalità, quali sicurezza, annotazione e controllo di
concorrenza è realizzato proprio grazie a tali interconnettori; inoltre questi
componenti garantiscono anche la transazione e la modularizzazione.
92
5.2.4 I componenti funzionali
funzionali
A questa categoria appartengono l’immagazzinatore di file RDF, il contenitore di
ontologie, ecc…
Attraverso il registro il kernel può dinamicamente rispondere alle richieste dei client
offrendo il relativo componente funzionale che espleta quel particolare servizio.
Tra i componenti funzionali ritroviamo l’Engineering Server, l’RDF Server che
abbiamo descritto nel capitolo 3.
5.3 Installazione
Per eseguire il KAON Server bisogna andare lanciare il file startserver.bat
presente (nel nostro caso) nella cartella:
C:/kaon_ext/kaonserver/release/bin/.
Prima di far partire il KAON Server bisogna caricarne i componenti:per fare ciò
basta di fatto copiare i file siti nella cartella di KAON denominata 3rdparty nella
cartella kaonserver definita deploy.
Una volta caricati i componenti è possibile, utilizzando un qualunque browser per
internet
e
indicando
nella
barra
degli
strumenti
la
seguente
URL
http://localhost:8082, ottenere l’interfaccia del KAON Server.
93
Figura: 24
Come si può notare è possibile utilizzare il KAON server corredato di quasi tutti i
suoi componenti.
Persistono tuttavia alcuni problemi nel caricamento di altri componenti poiché
questi non funzionano correttamente: come lo stesso Boris Motik afferma, il lavoro
di sviluppo si sta attualmente concentrando su KAON 2 versione che, tra l’altro,
fornirà una soluzione a questi problemi.[12]
94
Appendice A:
A:
Breve guida a MS Sql Server 2000
Introduzione
Nel seguente capitolo descriveremo brevemente cosa sono i database,
introdurremo i DBMS e i database relazionali.
Successivamente forniremo una piccola guida ad un DBMS quale MS Sql Server
2000 sul quale si poggiano i componenti della suite di KAON.
I database
Una base di dati (database o DB) è una collezione organizzata di dati utilizzati per
rappresentare le informazioni di interesse ed è gestita da un DBMS.
Un DBMS (DataBase Management System) è un sistema software in grado di
gestire collezioni di dati che siano grandi, condivise e persistenti, assicurando la
loro affidabilità e privatezza. Dove per grandi si vuole intendere di dimensioni
95
(molto) maggiori della memoria centrale dei sistemi di calcolo generalmente
utilizzati; persistenti significa che la collezione di dati ha un periodo di vita
indipendente dalle singole esecuzioni dei programmi che le utilizzano; infine
condivise nel senso che vengono utilizzate da applicazioni diverse.
Le caratteristiche di affidabilità e privatezza si definiscono invece come:
•
Affidabilità
Affidabilità - resistenza a malfunzionamenti HW o SW.
•
Privatezza - con una disciplina di controllo degli accessi.
Un DBMS in particolare è un sistema di "facilities" che consentono di effettuare tre
operazioni fondamentali sui dati, cioè:
•
la ricerca
•
l'aggiornamento
l'aggiornamento
•
la cancellazione
E’ logico però porsi la seguente domanda: perché bisogna utilizzare un DBMS? Le
ragioni possono essere molteplici:
96
controllare in modo centralizzato i dati;
ridurre la ridondanza dei dati;
evitare che siano presenti dati inconsistenti;
permettere la condivisione dei dati tra gli utenti;
consentire la definizione di standard per la rappresentazione dei
dati e per le modalità di accesso ai dati;
definire delle restrizioni sull'accesso ai dati per garantirne la
sicurezza;
mantenere l'integrità dei dati per mezzo di procedure di
validazione.
Esitono diversi tipi di database, ma attualmente sono quasi tutti di tipo relazionale,
basati cioè sul modello relazionale proposto da E. F. Codd nel 1970 per favorire
l’indipendenza dei dati.
Database commerciali basati su questo modello sono incominciati a comparire
all'inizio degli anni 80: tali database relazionali sono basati sul concetto di
relazione, la quale è sostanzialmente un insieme di record omogenei, cioè definiti
sugli stessi campi.
Ad ogni dominio all’interno della relazione viene associato un nome, chiamato
attributo, che ne descrive il ruolo (nelle tabelle diventerà poi il nome della colonna
97
ovvero del campo).
Una tabella rappresenta una relazione se: a) i valori di ogni colonna sono fra loro
omogenei; b) le righe sono diverse fra loro e le intestazioni delle colonne sono
diverse tra loro.
Ogni riga di una tabella viene chiamata record e una chiave è un attributo (o un
insieme di attributi) che identificano i record di una relazione.[13]
Esempi di DBMS commerciali sono: MS Access, MS Sql
Sql Server 2000,
2000 Oracle,
DB2, etc. Esistono anche DBMS open-source come: Postgres Sql,
MySql e
Firebird.
Guida a MS Sql Server 2000
Di seguito forniamo una piccola guida illustrata su come usare MS Sql Server
2000; la trattazione non è completa ma è mirata al solo utilizzo di MS Sql Server
2000 per le elaborazioni eseguite coi componenti di Kaon.
SQL Server è un DBMS di casa Microsoft, nato come prodotto leader del suo
settore. Sia come interfaccia sia come utilizzo è simile al già noto MS Access, ma
il suo funzionamento e le potenzialità offerte sono ben superiori a quelle di
quest’ultimo.
98
Installazione
La differenza tra SQL Server (ed altri come Oracle, MySQL, ecc...) con Access
consiste soprattutto nel fatto che mentre Access è un’applicazione che lavora
quasi esclusivamente lato client, SQL Server crea delle strutture di dati residenti
direttamente su un server e vi fornisce accesso.
Se lavorate su una rete locale allora potete installare il server su una macchina
che farà da server di database ed installare i client sui vari computer della rete che
si connetteranno direttamente al database unico sul server.
Nulla vieta che potete installare il server di SQL Server anche sul vostro computer
locale e utilizzare lo stesso come client, scelta peraltro obbligata nel caso in cui
non disponiate di una rete. I CD che vengono forniti al momento dell’acquisto sono
autopartenti e l'installazione del server e del client sono completamente guidate.
Importante è ricordare che:
•
durante l'installazione del server dovete configurare il nome del
computer su cui è installato il server di SQL Server, perchè vi servirà
in fase di connessione ad altre interfacce come ASP, ASP.NET,
Visual Basic, ecc...
99
•
quando vi sarà chiesta la password e l'utente che ha accesso al
database dovrete specificare sa che sta per SQL System
Administrator.
L'Enterprise Manager
Una volta installato SQL Server possiamo raggiungere il programma dal menù
Start/Programmi/MicrosoftSql
Start/Programmi/MicrosoftSqlServer
qlServer;
Server;
apriamo
l'Enterprise
Enterprise
Manager,
Manager
ovvero
l'interfaccia che consente di gestire tutti i processi di Sql Server, sia sistemistici sia
di sviluppo.
Di seguito un'anteprima dell'interfaccia di SQL Server:
Figura 25:
25: Interfaccia di SQL Server
come si nota, nel riquadro di sinistra ci sono diverse voci contrassegnate da una
cartellina gialla, che è possibile espandere per la gestione di vari processi. Quelli
che ci interessano più da vicino sono quelli legati allo sviluppo, quindi ci limiteremo
alla voce Database.
Database
100
Aprendo detta voce, ci ritroveremo nel riquadro di destra una serie di database:
alcuni di questi sono di configurazione ed altri di test.
Figura 26:
26: Mostra il contenuto della cartella database
I database di test
Come già detto nel paragrafo precedente, Sql Server ha per default sia una serie
di database predefiniti che servono per la configurazione di alcune caratteristiche
interne, sia una serie di database di prova che servono solo ad effettuare dei test
in fase di apprendimento.
101
I database di test di SQL Server sono Northwind e pubs,
pubs utilizzati anche in
moltissimi esempi della maggior parte dei libri che trattano i database.
Su questi database si possono effettuare tutte le prove ed i test che si desidera
fare, ma si consiglia di non cancellarli per evitare problemi a SQL Server che li ha
in memoria per default.
Per i nostri test utilizzeremo un database che creeremo ad hoc, in modo da non
generare malfunzionamenti in SQL Server e anche per mostrare come si crea un
nuovo database.
Creazione di un database
database
Per creare un nuovo database attraverso l'interfaccia grafica di SQL Server è
sufficiente cliccare col tasto destro del mouse sulla voce Database contrassegnata
da una cartellina gialla e selezionare la voce Nuovo database...
A questo punto si aprirà la seguente maschera:
102
Figura 27:
27: Creazione db di prova
che chiede il nome del database da creare: per esempio, inseriamo db_prova.
db_prova A
questo punto avremo il nostro nuovo database contrassegnato, come gli altri, da
un cilindro giallo, simbolo classico per designare un database; aprendolo potremo
vedere tutto quello che c'è a disposizione per la gestione del nostro database,
come mostrato in figura:
Figura 28:
28: Interfaccia per la gestione del database
Come già specificato in precedenza la trattazione non riguarda strettamente
l’utilizzo di MS SQL SERVER ma in appendice sono reperibili i link affinché il
103
lettore possa trovare eventuali informazioni aggiuntive che ritiene necessarie per
scopi diversi a quelli a cui tale trattazione si riferisce.
Un DBMS molto diffuso è My SQL, tale DBMS a differenza di MS SQL SERVER
non è a pagamento e può essere tranquillamente prelevato dal seguente sito:
http://dev.mysql.com
Dalle statistiche prelevate dalla rete si dimostra che tale DBMS è il più usato nel
mondo, sia perché risulta essere efficiente, sia perché può essere liberamente
utilizzato per scopi non commerciali ed è facilmente reperibile. Nell’ambito delle
prove eseguite con KAON, è stato necessario usare il database MS SQL SERVER
e non invece uno gratuito come My SQL, perché quest’ultimo non è supportato da
tutti i componenti di KAON come chiaramente dimostrato nel capitolo 4.
104
APPENDICE B:
Codici JAVA
Il codice qui presentato è stato scritto utilizzando JCreator.
Script
Script dell’inferenza sull’ontologia dei laureati.
laureati.
package myprojects.kaon;
import edu.unika.aifb.kaon.api.oimodel.*;
import java.lang.Object;
import java.util.*;
import edu.unika.aifb.kaon.api.*;
import edu.unika.aifb.kaon.api.change.*;
import edu.unika.aifb.kaon.engineeringserver.client.DirectKAONConnection;
import java.sql.Driver;
import java.sql.DriverManager;
import java.lang.Class;
import java.lang.Exception;
class onto{
static KAONConnection kaonConnection;
105
public onto(){} //Costruttore
public
static
void
main(String
args[])
throws
KAONException,
ClassNotFoundException{
// Connessione al Direct Engeneering Server
Map parameters=new HashMap();
//Parametri di Connessioneper usare Direct Engeneering Server
parameters.put(KAONManager.KAON_CONNECTION,
"edu.unika.aifb.kaon.engineeringserver.client.DirectKAONConnection");
parameters.put("SERVER_URI","direct://[email protected]:1433/MSSQL/MAR
CELLO");
parameters.put("JDBC_DRIVER","com.microsoft.jdbc.sqlserver.SQLServer
Driver");
try {
kaonConnection=KAONManager.getKAONConnection(parameters);
} catch(KAONException exc) {
System.out.println("\t\t\tIL
SERVER
NON
E’
ATTIVO
AL
MOMENTO");
System.out.println("\t\t\t\t\tRIPROVARE PIU’TARDI");
System.out.println("\t\t\t\t\t\tL'ESECUZIONE TERMINA QUI");
System.exit(-1);
}
OIModel oimodel=kaonConnection.openOIModelPhysical
("direct://[email protected]:1433/MSSQL/MARCELLO?enzo");
System.out.println("Connesso!!!");
// Inizio Programma che simula un PICCOLO MOTORE INFERENZIALE
SULL’ONTOLOGIA DEI LAUREATI//
106
//Realizzo la query sui laureati
System.out.println("\tPICCOLO MOTORE INFERENZIALE");
System.out.print("Eseguiamo la seguente query: ");
String query="<#laureatoa>";
System.out.println(query);
Collection result=oimodel.executeQuery(query);
//Conto il numero di elementi che ho dalla query
Iterator iterator=result.iterator();
System.out.print("Gli elementi che soddisfano la query sono ");
System.out.println(result.size());
//prelevo le istanze a coppie
while (iterator.hasNext()) {
Object[] tuple=(Object[])iterator.next();
Instance person=(Instance)tuple[0];//persona
Instance univers=(Instance)tuple[1];//università
System.out.println("Scandisco la tupla: " + person.getURI() + " -- " +
univers.getURI() + "...");
//Controlla se la proprietà esiste già...
System.out.println("Controllo se la proprieta’'" + "laureatonellacitta" +
"‘esiste gia'... ");
Set B=oimodel.getProperties();
Iterator iter=B.iterator();
boolean trovato=false;
while(iter.hasNext() && !trovato){
Property p=(Property)iter.next();
//System.out.println("\tProprieta':"+p.getURI());
if(p.getURI().equals("laureatonellacitta")) {
trovato=true;
107
}
}
// Crea la proprietà se NON esiste già
if(!trovato){
System.out.print("La proprietà NON esiste: la creo...");
List changes = newLinkedList();
//direct//[email protected]:1433/MSSQL/MARCELLO?
Property graduated_in = oimodel.getProperty("laureatonellacitta");
changes.add( new AddEntity(graduated_in) );
changes.add( new AddPropertyDomain(graduated_in,
oimodel.getConcept( "enzo#Persona" ) ) );
changes.add( new AddPropertyRange( graduated_in,
oimodel.getConcept( "enzo#Citt%C3%A0" ) ) );
oimodel.applyChanges( changes );
changes.clear();
oimodel.save();
System.out.println(" creata!!!");
} else {
System.out.println("La proprietà esiste già!!!");
}
//Faccio una query sulle università x sapere in quale città sono situate
System.out.println("Faccio una query sulle università x sapere in
quale citta’e’situata la '" + univers.getURI() + "'");
query=("<#situatain> IN:1 !" + univers.getURI() + "!");
System.out.println(query);
Collection univresult=oimodel.executeQuery(query);
108
System.out.print("Gli elementi che soddisfano la query sulle
università sono ");
System.out.println(univresult.size());
Iterator iteratorUniv=univresult.iterator();
if (iteratorUniv.hasNext()){
Object[] coppia=(Object[])iteratorUniv.next();
Instance city=(Instance)coppia[1];//città
System.out.println("La '" + univers.getURI() + "‘e’situata a '" + city.getURI()
+ "'!");
System.out.println("Inserisco l'istanza della proprietà 'laureatonellacitta’tra '"+
person.getURI() + "‘e '" + city.getURI() + "'." );
//ad esempio: "Teddy laureato nella città di Napoli"
PropertyInstance laureatoa =oimodel.getPropertyInstance(
oimodel.getProperty("laureatonellacitta") , person, city);
List changes = new LinkedList();
changes.add(new AddPropertyInstance(laureatoa) );
try{
oimodel.applyChanges( changes );
changes.clear();
oimodel.save();
}catch(KAONException exc){
System.out.println("Statement della proprietà già esistente!");
}
}
} // end of while
} // end of main
} // end of class
109
Script sull’inferenza tra i due database:
package myprojects.kaon;
import edu.unika.aifb.kaon.api.oimodel.*;
import java.lang.Object;
import java.io.*;
import java.util.*;
import edu.unika.aifb.kaon.api.*;
import edu.unika.aifb.kaon.api.change.*;
import edu.unika.aifb.kaon.engineeringserver.client.DirectKAONConnection;
import java.sql.Driver;
import java.sql.DriverManager;
import java.lang.Class;
import java.lang.Exception;
class onto{
static KAONConnection kaonConnection;
public onto(){} //Costruttore
static String query;
public
static
void
main(String
args[])
throws
KAONException,
ClassNotFoundException{
System.out.print("\t\t\tPICCOLO MOTORE INFERENZIALE\n\t\t\t\t
110
Sillogismo Aristotelico\n\n Connessione al server in
corso... ");
Map parameters=new HashMap();
//Parametri di Connessione per usare Direct Engeneering Server
parameters.put(KAONManager.KAON_CONNECTION,
"edu.unika.aifb.kaon.engineeringserver.client.DirectKAONConnection
");
parameters.put("SERVER_URI","direct://[email protected]:1433/MSSQL/
MARCELLO");
parameters.put("JDBC_DRIVER","com.microsoft.jdbc.sqlserver.SQL
ServerDriver");
try {
kaonConnection=KAONManager.getKAONConnection(parameters);
} catch(KAONException exc) {
System.out.println("\n\t\t\tIL SERVER NON E’ATTIVO AL
MOMENTO");
System.out.println("\t\t\t\t\tRIPROVARE PIU’TARDI");
System.out.println("\t\t\t\t\t\tL'ESECUZIONE TERMINA
QUI");
System.exit(-1);
}
OIModel oimodel=kaonConnection.openOIModelPhysical
("direct://[email protected]:1433/MSSQL/MARCELLO?sillogismo");
System.out.println("connesso !");
System.out.print("Eseguiamo la seguente query: ");
111
String query="[#Animale]";
System.out.println(query);
Collection result=oimodel.executeQuery(query);
//Conto il numero di elementi che ho dalla query
Iterator iterator=result.iterator();
//prelevo le istanze a coppie ossia prelevo il concetto Uomo dal concetto
animale Animale, ricordiamo che in realtà usiamo le spannig-instance
List changes = new LinkedList();
Instance domain1=null;
while (iterator.hasNext()) {
Instance domain=(Instance)iterator.next();
if(domain.getURI().equals("sillogismo#Uomo")){
//Eseguo la seconda query ossia realizzo il vero sillogismo aristotelico
System.out.print("Eseguiamo la seconda query: ");
String query1="<#mangia>";
System.out.println(query1);
Collection result1=oimodel.executeQuery(query1);
Iterator iterator1=result1.iterator();
//Prelevo le istanze a coppie ossia prelevo il concetto Animale e concetto
Carne.
while (iterator1.hasNext()) {
Object[] tuple1=(Object[])iterator1.next();
domain1=(Instance)tuple1[0];
Instance range1=(Instance)tuple1[1];//carne
if(domain1.getURI().equals("sillogismo#Animale")){
System.out.println("Scandisco la tupla: " + domain1.getURI() +
" mangia "+ range1.getURI() + "...");
112
System.out.println("\tQuindi l'uomo mangia la carne");
}
}//end while sui concetti animale e carne
}
}
System.out.print("\nConnessione al secondo server in corso... ");
Map parameters2=new HashMap();
//Parametri di Connessione per usare Direct Engeneering Server
parameters2.put(KAONManager.KAON_CONNECTION,
"edu.unika.aifb.kaon.engineeringserver.client.DirectKAONConnection
");
parameters2.put("SERVER_URI","direct://[email protected]:1433/MSSQL
/final");
parameters2.put("JDBC_DRIVER","com.microsoft.jdbc.sqlserver.SQL
ServerDriver");
kaonConnection=KAONManager.getKAONConnection(parameters2);
OIModel oimodel2=kaonConnection.openOIModelPhysical
("direct://[email protected]:1433/MSSQL/final?carne");
System.out.println("connesso !");
String query2="[#Uomo]";
Collection result2=oimodel.executeQuery(query2);
Iterator iterator2=result2.iterator();
System.out.print("Per quale istanza vuoi effettuare la ricerca? ");
113
String scelta= new String("sillogismo#");
try {
String temp= new String();
InputStreamReader isr=new InputStreamReader(System.in);
BufferedReader br=new BufferedReader (isr);
temp = br.readLine();
scelta = scelta + temp;
} catch(Exception ex) {
ex.printStackTrace();
}
while (iterator2.hasNext()) {
Instance parte2=(Instance)iterator2.next();
if(parte2.getURI().equals(scelta)) {
String chi = parte2.getURI();
int pos = chi.indexOf("#");
System.out.print( "\n" + chi.substring(pos+1) + " mangia ");
String query3="[#Carne]";
Collection result3=oimodel2.executeQuery(query3);
Iterator iterator3=result3.iterator();
while (iterator3.hasNext()) {
Instance parte3=(Instance)iterator3.next();
String cosa =parte3.getURI();
pos = cosa.indexOf("#");
System.out.print(cosa.substring(pos+1));
if (iterator3.hasNext())
System.out.print(", ");
else
System.out.println(".");
114
}
} // end of if
} // end of while
}//end of main
}//end of class
115
Considerazioni Finali
Il Web Semantico costituisce uno dei temi centrali della ricerca nel campo
dell’informatica. La ragione per cui tanti studiosi sono interessati a come sta
evolvendo il Web sta nel fatto che selezionare informazioni da questo enorme
contenitore è una pratica che ormai ricorre quotidianamente nella vita di ognuno di
noi: basti pensare che una pagina di un qualsiasi motore di ricerca è caricata in un
secondo da milioni di utenti sparsi in tutto il mondo.
Dobbiamo, però, tener presente che questi lavori di adeguamento dei contenuti
alle nostre esigenze sono ancora in una fase sperimentale, anche se negli ultimi
anni la “comunità” coopera affinché i lavori siano realizzati al più presto.
KAON rispecchia pienamente la volontà della comunità: in effetti già il fatto che è
una piattaforma open-source lascia intuire che si vuole dare spazio all’ingegno ed
alla fantasia di chiunque si occupi di sviluppare software.
116
Uno dei problemi di KAON è di fatto rappresentato dalla scarsa documentazione
necessaria, soprattutto ad utenti non molto esperti, per utilizzare in tempi minimi
tutte le potenzialità che la piattaforma possiede.
Le prove effettuate sono state ricche di difficoltà , in particolare, nella fase di
istallazione di componenti quali l’RDF Server e l‘Engineering Server. Al fine di
completare quelle parti del lavoro scarsamente documentate si è dovuto ricorrere
spesso a contattare via e-mail il team degli sviluppatori, trovando, peraltro, sempre
grande disponibilità. l’RDF Server e l‘Engineering Server si sono rivelati tuttavia
estremamente interessanti in quanto si poggiano su database relazionali, e infatti,
grazie al loro utilizzo, è possibile memorizzare una o più ontologie su macchine
diverse effettuando eventualmente delle inferenze. Diversa è stata la fase di
realizzazione del codice java per realizzare i due esempi di inferenza dove i
problemi incontrati sono stati relativamente di semplice soluzione, anche se,
vogliamo ancora una volta sottolineare che altri tool possiedono già un motore
inferenziale a differenza di KAON, dove questo è ancora in fase di sviluppo.
La versione estesa di KAON non presenta significative soluzioni: lo stesso KAON
Server non è completamente funzionante. Molti componenti attualmente non
possono essere caricati e l’interesse dei progettisti di KAON è ormai rivolto a
KAON 2, che dalle ultime notizie reperibili su siti come sourceforge.net, o lo stesso
sito di KAON, sarà a pagamento.
117
In conclusione, a partire dai risultati ottenuti, alcune prospettive di sviluppo del
lavoro qui presentato potrebbero essere:
• lo studio della piattaforma KAON 2;
• migliorare l’attuale versione di KAON fornendola di un motore inferenziale;
• la realizzazione di una nuova piattaforma che sia strutturata, almeno
nell’architettura, come KAON conservando di quest’ultima soprattutto il
concetto di modularizzazione, che resta per KAON uno dei suoi vantaggi più
evidenti.
118
Bibliografia
[1] Tim Berners-Lee, James Hendler, Ora Lassila, “The Semantic Web”, Scientific
American, Maggio 2001.
[2] Paolo Bouquet, Roberta Ferrario, “Il Semantic Web” , Laboratorio di Ontologia
Applicata, CNR, Trento.
[3] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, Extensible Markup
Language (XML) 1.0, Second Edition, W3C Recommendation 6 Ottobre 2000
[4] Corrado Petrucco, “Le prospettive didattiche del Semantic Web” , Dipartimento
di Scienze dell’ educazione, Università di Padova.
[5] O.Lassila, R.R.Swick , Resource Description Framework (RDF) – Model
and Syntax, W3C Recommendation 22 Febbraio 1999
[6] W.N.Borst, Construction of Engineering Ontologies, 1997
[7] Thomas Gabel, York Sure, Johanna Voelker, ”KAON –An Overview”, Aprile
2004
[8] FZI & AIFB, “Developer s Guide for KAON 1.2.7” , Gennaio 2004
[9] Thomas Gabel, York Sure, Johanna Voelker, “KAON - OntologyManagement
Infrastructure” , SEKT/2004/D3.1.1.a/v1.0 ,26 Marzo 2004
[10] FZI, “OI-Modeler User’s Guide” , 2004
[11] Raphael Volz, Daniel Oberle, Steffan Staab, Boris Motik, “KAON Server –A
Semantic Web Managment System“ Agosto 2003
119
[12] Boris Motik, Daniel Oberle, Steffan Staab, Rudi Studer, Raphael Volz, “KAON
Server Architecture“ Agosto 2003
[13] Anna Maria Cotugno, Michele D’Urzo, Luigi Lamberti,
Restituita Prota,
“Informatica –Sistemi Automazione, Novembre 1999
120
Risorse
Web Semantico
www.w3.org/2001/sw
www.w3.org/DesignIssues/Semantic.html
www.semanticweb.org
www.disobey.com/detergent/2002/sw123
www.xml.com/pub/a/2000/11/01/semanticweb
www.netcrucible.com/semantic.html
http://www.blueberrypie.it/
XML
www.xml.com
www.w3.org/XML/
www.xml.org
121
RDF
www.opsla.snu.ac.kr/research/ seminar/2004/RDF
www.w3.org/RDF
KAON
http://kaon.semanticweb.com
http://sourceforge.net
http:// www.ibm.com/us
RDF SERVER
http://kaon.semanticweb.com
Engineering Server
http://kaon.semanticweb.com
KAON Server
122
http://kaon .semanticweb.com
Appendice A
http://www.hereasnet.it
123
Ringraziamenti
Ringrazio la mia famiglia,
famiglia la mia ragazza e miei amici per la forza che mi hanno
conferito nei momenti difficili che hanno accompagnato la mia vita universitaria.
Ringrazio Marcello Esposito per la sua disponibilità nel mostrarmi il modo giusto di
lavorare e soprattutto, lo ringrazio per avermi supportato e invogliato a superare i
miei limiti.
Ringrazio l’ ing. Francesco Saverio Gragnani per la disponibilità e per avermi
aiutatato a risolvere i problemi incontrati nel mio lavoro.
Ringrazio tutto il personale CRIAI per l’appoggio fornitomi per realizzare il mio
lavoro e soprattutto per avermi fatto sentire parte di una famiglia: il CRIAI.
124
125