Università degli Studi di Brescia
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Elettronica
Dipartimento di Elettronica per l’Automazione
Tesi di Laurea
Metodi e strumenti per
l’interrogazione di ontologie di
dominio
Relatore:
Ch.ma Prof.ssa Valeria De Antonellis
Correlatori:
Dott. Michele Melchiori
Dott.ssa Sabrina De Capitani di Vimercati
Laureando:
Pietro Martinelli
matricola 35043
Anno Accademico 2001-2002
Questo lavoro rappresenta, naturalmente, la conclusione di un cammino
iniziato cinque anni fa, tra incertezze, dubbi e, forse, un po’ di paura. D’altra
parte, esso conclude anche un periodo della mia vita, legato a doppio filo
al mio ruolo di studente, e mi “costringe”, in qualche modo, a “diventare
grande”. . . Esso può dunque essere una buona occasione per ringraziare le
persone che, in un modo o nell’altro, mi hanno accompagnato in tutti questi
anni, che mi sono state vicine, con la loro presenza, il loro affetto, il loro
pensiero. . . o che, per qualunque motivo, sono state e sono importanti per
me, e per la mia vita. . .
Grazie dunque, prima di tutto, ai miei genitori, che in tutto questo tempo
hanno sempre costituito un punto di riferimento ed un aiuto insostituibili,
nei momenti di “scelta” come nella vita di ogni giorno, e che mi hanno reso
possibile arrivare fin qui. E grazie a Maddalena, mia amica prima che mia
sorella, che mi sopporta quotidianamente, pur sostenendo che “non c’è niente
di più inutile di un ingegnere”. . .
Grazie poi a tutti i miei amici, ed in particolare (in rigoroso ordine alfabetico) ai più cari: ad Antonella, amica. . . e non solo, a Beppe, per il nostro
essere in sintonia su tutto, tranne che sul calcio, e a Nicola, splendido e
paziente compagno di scuola da tredici anni a questa parte...
Vorrei poi ringraziare tutta la mia famiglia, in primis i miei cugini, per la
loro simpatia, e poi i miei zii, zie e nonni, quelli che ci sono e quelli che non
ci sono più, per essere stati sempre, per me, un esempio ed un riferimento
assai importante.
A proposito di questo lavoro, vorrei ringraziare la prof.ssa De Antonellis,
per la gentilezza e la competenza con la quale mi ha seguito fin dall’inizio,
il Dr. Melchiori, per la precisione e la puntualità delle sue correzioni e dei
suoi consigli, e tutti i ragazzi che hanno lavorato in laboratorio “sulla sedia
accanto alla mia”, rendendo divertenti e meno faticosi questi mesi di intensa
attività: grazie dunque a Devis, Antonio, Paolo, Denise e, ovviamente !, alla
mitica coppia Nicola & Nicola, compagni insostituibili di mille elaborati.
Grazie poi a Mike & Scalo, per aver sofferto, pianto e gioito con me
durante e dopo le partite dell’Inter, aiutandomi ad accantonare, per un po’,
la tensione di queste ultime settimane. E grazie a tutte le ragazze ed i ragazzi
che hanno diviso con me, negli ultimi cinque anni, lezioni ed esami, paure e
preoccupazioni.
Infine, un grazie a Francesco Guccini e Fabrizio De Andrè, per aver scritto
una canzone per ogni possibile stato d’animo, e per avermi aiutato cosı̀ ad
imparare “la mia distanza dalle stelle”; a Leonardo da Vinci, per aver inventato la bicicletta, compagna splendida ed insostituibile di tanti chilometri e
di tante emozioni; ad Ernesto Guevara, per la sua vita e non solo; a René Descartes, per aver inventato la geometria analitica, passione insolita ma non
i
per questo meno bella; a Dante Alighieri ed Isaac Asimov, grandissimi ed
irraggiungibili maestri di che cosa significhi sognare.
Grazie anche a tutti gli altri, alle innumerevoli persone che avrei voluto
ricordare ma non ho citato per il semplice motivo che tutta questa sfilza di
nomi mi sembra già abbastanza noiosa e melensa. In ogni caso, loro lo sanno.
Pietro.
ii
E respirava difficile, come un ciclista in salita,
un respiro che era ritmo sporco e pena.
Alessandro Baricco,“City”
Mi piace sentirmi parlare. È una delle cose
che mi diverte di più. Spesso sostengo lunghe
conversazioni con me stesso e sono cosı̀ intelligente che a volte non capisco nemmeno una
parola di quello che dico.
Oscar Wilde,“Il razzo illustre”
iii
Indice
1 Introduzione
1
2 Ontologie e ingegneria dell’informazione
2.1 Definizione di ontologia . . . . . . . . . . . . . . . .
2.2 Prospettive di utilizzo di ontologie . . . . . . . . . .
2.3 Cenni sulla costruzione di ontologie . . . . . . . . .
2.4 Linguaggi logici per la rappresentazione di ontologie
2.5 Il linguaggio concettuale X-Formalism . . . . . . . .
2.6 Il linguaggio ODLI 3 . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
. 3
. 5
. 8
. 11
. 15
. 21
3 Utilizzo di ontologie
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Modalità di utilizzo di ontologie: descrizione dettagliata .
3.3 L’architettura di ontologia a tre livelli in ARTEMIS . . .
3.4 Modalità di utilizzo di ontologie e linguaggi di ARTEMIS
.
.
.
.
.
.
.
.
.
.
.
.
29
29
30
34
36
4 Sviluppo di primitive per l’utilizzo di
4.1 Navigazione strutturale dell’ontologia
4.2 Ricerca di istanze di concetti . . . . .
4.3 Criteri di ricerca . . . . . . . . . . .
4.4 Primitive e categorie di utenti . . . .
4.5 Conclusioni . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
43
45
48
49
.
.
.
.
51
52
54
57
64
ontologie
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Modello di ricerca per ontologie
5.1 Introduzione: un motore di ricerca basato su ontologie
5.2 OQL per ontologie . . . . . . . . . . . . . . . . . . . .
5.3 Interfacce per comporre Query OQL . . . . . . . . . .
5.4 Gestione di una Query OQL: costruzione della risposta
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Progetto e implementazione di interrogazioni in ARTEMIS 72
6.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
iv
6.2
6.3
6.4
6.5
6.6
Analisi e descrizione dei concetti rilevanti .
Progetto delle classi . . . . . . . . . . . . .
Traduzione di Query:rappresentazione delle
Traduzione di Query: algoritmi . . . . . .
Realizzazione dell’interfaccia utente . . . .
. . . .
. . . .
scelte
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
72
79
90
92
98
7 Esempi di interrogazione su ontologie in ARTEMIS
109
7.1 L’ontologia di esempio . . . . . . . . . . . . . . . . . . . . . . 109
7.2 Alcune interrogazioni di esempio . . . . . . . . . . . . . . . . . 112
8 Conclusioni e sviluppi futuri
119
A Sintassi completa di ODLI 3
121
B Sintassi completa di OQL - Object Query Language
136
C La tecnologia CORBA
139
D Architettura dell’interfaccia grafica
143
E Codice completo degli esempi
148
E.1 Codice completo dell’ontologia utilizzata negli esempi . . . . . 148
E.2 Codice completo dello schema integrato utilizzato negli esempi 161
E.3 Codice completo delle interrogazioni di esempio . . . . . . . . 181
Bibliografia
189
v
Capitolo 1
Introduzione
La diffusione delle tecnologie Web rende accessibile ad un numero sempre
crescente di utenti un insieme di informazioni sempre più grande, potenzialmente illimitato, distribuito su sorgenti indipendenti ed eterogenee. Infatti,
in questi ultimi anni, numerose organizzazioni hanno iniziato a sperimentare
il Web a scopo di cooperazione e di ampliamento delle attività commerciali,
migliorando il volume e l’efficienza nello scambio di informazioni. Di conseguenza, i sistemi informativi aziendali sono stati (parzialmente) migrati
verso il Web ed è sorta quindi l’esigenza di disporre di metodi e strumenti
per accedere efficacemente ai dati informativi differenti ora resi disponibili
su Web da sorgenti informative autonome ed eterogenee.
In questo scenario, nasce la necessità di descrivere ed accedere le informazioni mediante un modello integrato, che dia una rappresentazione globale,
integrata e condivisa delle informazioni relative ad un particolare dominio,
astraendo dalle sorgenti cui le informazioni effettivamente appartengono.
In particolare, nell’ambito del progetto Artemis, sviluppato in una collaborazione tra il Dipartimento di Elettronica per l’Automazione dell’Università degli Studi di Brescia ed il Dipartimento di Scienze dell’Informazione
dell’Università di Milano, questi requisiti vengono soddisfatti definendo un
modello di ontologia a tre livelli, costruita a partire da sorgenti XML in
un dato dominio, che fornisce uno spazio di ricerca strutturato e permette l’interrogazione di sorgenti multiple senza che l’utente debba conoscere
preventivamente la loro locazione, il loro vocabolario ed i loro contenuti.
L’obiettivo di questa tesi è mettere a punto metodi e sviluppare strumenti
allo scopo di interrogare tale modello integrato, ovvero di rendere possibile
sfruttare l’ontologia a tre livelli per ottenere informazioni, sia sul modello
stesso, sia sul contenuto delle sorgenti che esso descrive.
Il nostro lavoro si rivolge in particolare nella direzione di realizzare strumenti di interrogazione indipendenti dal dominio modellato ed indipendenti
1
dalle sorgenti integrate. Tali strumenti devono rendere possibile un accesso
semplice, immediato e naturale alle informazioni che il modello contiene, indipendentemente dalle conoscenze pregresse dell’utente relative al processo
di modellazione ed al dominio modellato.
Per fare questo, è stato necessario fare uso di un insieme di linguaggi atti a
modellare concettualmente domini informativi, a darne una rappresentazione
ricca ed esauriente, e ad esprimere interrogazioni tanto sull’ontologia quanto
sulle sorgenti integrate. In tal senso, si fa uso del linguaggio X-Formalism per
modellare concettualmente l’ontologia, mentre la sua rappresentazione logica
è data mediante il linguaggio ODLI 3 , derivato dall’ambito della modellazione
di basi di dati ad oggetti. Infine, le interrogazioni sui modelli ontologici e
quelle sulle sorgenti locali sono espresse utilizzando il linguaggio OQL (Object
Query Language), anch’esso nato nell’ambito delle basi di dati ad oggetti.
Di seguito è illustrata l’organizzazione della tesi.
Nel Capitolo 2 si introduce il concetto di ontologia, illustrandone il possibile utilizzo in vari ambiti dell’Ingegneria dell’Informazione. Il Capitolo 3
prende quindi in esame le modalità di interazione con modelli di questo genere, valutando le peculiarità dovute alle diverse categorie di utenti e contestualizzando il tutto nell’ambito dei linguaggi utilizzati nel progetto Artemis.
Nel Capitolo 4 si passa poi allo sviluppo di una serie di primitive che rendono
possibile utilizzare in modo semplice un’ontologia nell’ottica delle modalità
di interazione individuate ed approfondite nel capitolo precedente. Il Capitolo 5 sviluppa quindi un modello di ricerca di informazioni in ontologie
basato sull’utilizzo del linguaggio d’interrogazione OQL; contestualizza poi
il concetto di query al caso specifico dei modelli ontologici; chiarisce di quali
informazioni è necessario disporre per passare da interrogazioni sul modello
ad interrogazioni sulle sorgenti di partenza, e propone infine un formalismo
concettuale per la rappresentazione di tali informazioni. Il Capitolo 6 descrive il progetto e l’implementazione di due moduli software che realizzano
le funzioni analizzate nel corso dei capitoli precedenti. I moduli forniscono
all’utente un’interfaccia che rende possibile navigare i concetti dell’ontologia e interrogare in modo naturale e flessibile l’ontologia stessa, curando la
riformulazione delle interrogazioni poste, in termini di interrogazioni da sottomettere alle singole sorgenti integrate. Un esempio di utilizzo di tali moduli
viene infine illustrato nel Capitolo 7.
2
Capitolo 2
Ontologie e ingegneria
dell’informazione
2.1
Definizione di ontologia
In letteratura si trovano spesso definizioni lievemente diverse di ontologia. In
genere, tali differenze sono motivate dal diverso punto di vista degli autori,
i quali tendono a spiegare questo concetto alla luce di ciò che nei loro lavori
interessa proporre ed enunciare. Volendo tenere conto di diverse definizioni,
una ontologia
1. è un vocabolario
2. è un modello di un particolare dominio della realtà
3. è una specificazione esplicita e formale di una concettualizzazione condivisa e comune
In particolare un’ontologia definisce in modo esplicito e formale un insieme di termini relativi ad un particolare dominio, dà un insieme di relazioni
tra questi termini, ed un insieme di regole semantiche che precisano i ruoli
ed i comportamenti dei concetti definiti nel dominio di interesse. Un’ontologia fornisce una base comune che può essere comunicata e che permette di
scambiare informazioni espresse in forme diverse [11].
Per quanto riguarda alcune possibili interpretazione del concetto di ontologia, specialmente alla luce delle esigenze che ne determinano l’importanza
(come discusso nella sezione seguente), si veda [20]. Per un esempio di utilizzo
di una definizione formale di ontologia come insieme di concetti e relazioni,
si veda (ad esempio) [19]. Infine, per una definizione di ontologia come
vocabolario con particolari caratteristiche si veda [16].
3
2.1.1
Motivazioni di fondo
Dato che, come si è detto, la definizione di ontologia dipende essenzialmente
dal punto di vista che si adotta, ed è dunque legata a ciò che con un’ontologia
ci si propone di fare, vediamo da quali esigenze pratiche è nato il concetto di
ontologia, in modo da capirne meglio il significato.
Sono molti i contesti nei quali esiste una grande varietà di informazioni
difficili da scambiare e da integrare a causa del differente linguaggio nel quale
sono espresse. Naturalmente una situazione di questo genere risulta spiacevole, per esempio perchè il fatto di non potersi scambiare della conoscenza fa sı̀
che tale conoscenza debba essere ricostruita ex-novo quando necessaria, e in
certi casi può non esserci affatto la possibilità di ricostruire una conoscenza.
Il concetto di ontologia nasce dalla necessità e dalla volontà di trovare
un modo per porre rimedio a situazioni nelle quali è impossibile, o quantomeno difficile, condividere e scambiare informazioni a seguito di differenze
tra i linguaggi parlati dai diversi agenti che operano in un ben determinato
dominio di conoscenza. Esso dunque rappresenta essenzialmente un mezzo
che permette di integrare informazioni provenienti da fonti eterogenee, e basa
la sua funzione su una conoscenza della semantica del dominio di interesse,
ovvero dei concetti e delle relazioni tra concetti che in tale contesto risultano
rilevanti, nonchè della terminologia ad essi relativa. Ora vedremo come la
necessità di utilizzare concetti come le ontologie possa nascere da differenti
tipologie di eterogeneità tra i linguaggi dei diversi agenti che si trovano a
voler condividere conoscenza.
Si è detto che il problema consiste essenzialmente nella differenza tra i
linguaggi parlati dai diversi agenti. In realtà, per differenza di linguaggio si
può intendere una incompatibilità di diversi tipi. Infatti, può darsi il caso di
agenti che parlino due lingue diverse: è il caso di un soggetto umano italiano
ed uno tedesco, che si trovino a non conoscere nessuna lingua comune, o di
due agenti automatici che utilizzino formati di ingresso ed uscita incompatibili. In questo caso è abbastanza evidente come la differenza di linguaggio sia
un problema. Tuttavia, per linguaggio si può intendere anche la terminologia
utilizzata da due agenti: si pensi al caso di due persone che parlano la stessa
lingua ma indichino gli stessi concetti con termini diversi, oppure utilizzino
gli stessi termini con sfumature semantiche diverse. Chiaramente, se nel caso
di due agenti umani che dialogano può aver luogo una forma di semantizzazione progressiva, ovvero un processo mediante il quale, nel corso del dialogo,
i due interlocutori si rendono conto delle differenze terminologiche e risolvono
il problema, nel caso di agenti automatici una situazione di incomprensione
di questo tipo, oltre ad essere potenzialmente molto più pericolosa di quella
indicata in precedenza, non si presta certo ad una soluzione spontanea ed
4
automatica da parte dei due interlocutori. Ancora, si può pensare a forme di
informazioni relative ad uno stesso dominio, espresse mediante analoga terminologia ma mediante formalismi diversi: si pensi per esempio all’utilizzo
di diversi formati per i documenti prodotti durante le diverse fasi del ciclo
di vita di un software (linguaggio naturale ed alberi di decomposizione per
l’analisi dei requisiti, diagrammi UML per la fase di progettazione, schemi
di collaudo basati su linguaggio naturale per la fase di test, . . . ), quando
chiaramente sarebbe comodo poter avere una vista complessiva sull’insieme
di tutte le varie fasi e dei vari documenti. Anche in questo caso, se questa
difficoltà può essere superata, con un certo costo, mediante l’intervento di esseri umani, è chiaramente difficile immaginare la possibilità di automatizzare
tale attività di integrazione.
Abbiamo presentato alcuni casi pratici nei quali risulta necessario porsi il
problema di trovare una base comune che permetta lo scambio di informazioni
e di conoscenza tra soggetti diversi che operano sullo stesso dominio ma, per
qualche motivo, non si capiscono. Come detto in precedenza, il concetto
di ontologia come noi lo intendiamo nasce da esigenze di questo genere, e
risulta pertanto definibile come una concettualizzazione formale e condivisa
del dominio di interesse. Nel seguito, dopo aver presentato in generale il
ciclo di vita della conoscenza, mostreremo come alcuni dei processi che lo
compongono possano essere realizzati con grande efficacia mediante l’utilizzo
di modelli ontologici.
Esempi dell’utilità delle ontologie per risolvere problemi come quelli qui
ricordati si trovano nella maggioranza degli articoli che di ontologie trattano.
In particolare, [20] costituisce in questo senso un’introduzione molto generale
ed articolata. [11] propone invece alcuni esempi di utilizzo di ontologie come
base per un’architettura orientata al commercio elettronico (tra aziende e
tra privati ed aziende). [16] discute dell’utilità di modelli di tipo ontologico
nell’ottica dell’integrazione di sorgenti web.
2.2
Prospettive di utilizzo di ontologie
Presentiamo ora alcuni esempi di particolari contesti di utilizzo di ontologie.
Essi, oltre a chiarire con maggiore precisione che cosa si intenda per ontologia,
daranno anche un’idea dell’utilità di tale concetto in situazioni pratiche.
2.2.1
Ontologie come strumento di comunicazione
Come ampiamente ricordato in precedenza, l’utilizzo di ontologie riduce la
confusione concettuale e terminologica, rendendo disponibile una base di la5
voro unitaria ed esplicita all’interno di un dato dominio. In questo modo, esso
rende possibile la comprensione e la comunicazione tra persone con differenti
esigenze e punti di vista, dovuti ai rispettivi contesti. Ecco alcuni aspetti
di uso di ontologie che facilitano la comunicazione tra persone all’interno di
una organizzazione.
• Modello normativo: all’interno di un sistema software di grandi dimensioni, è sensato immaginare che parecchie persone siano nella necessità di avere una comprensione condivisa del sistema e delle sue
finalità. Come già visto, l’utilizzo di ontologie permette, attraverso
la realizzazione di un modello normativo del sistema, di creare una
definizione semantica del sistema stesso, e dunque di rendere disponibile un modello estendibile che può essere successivamente raffinato, il
quale permette trasformazioni semantiche tra differenti contesti (“viste” dei diversi soggetti). In questo modo, un modello incentrato su
regole di trasformazione (assimilabili alle regole di mapping ricordate
in precedenza) rende possibile la suddetta comprensione condivisa del
sistema, senza forzare le persone coinvolte a cambiare il loro punto di
vista sul sistema stesso, ma ponendosi semplicemente come mediatore
tra le “viste” che i diversi soggetti hanno.
• Rete semantica: è poi possibile utilizzare le ontologie per creare una
rete di relazioni semantiche, che tenga traccia dei collegamenti tra le
diverse entità di un dominio, e per rendere possibile una semplice navigazione di tale rete. E’ chiaro che una rete di questo genere è comunque
implicita in un dato dominio o sistema, tuttavia differenti soggetti possono avere di tale rete di relazioni implicita una percezione diversa, a
seconda dei loro punti di vista ed interessi (od esigenze) particolari e
delle loro diverse assunzioni. Tutto ciò è dovuto essenzialmente alla
mancanza di un accordo condiviso a proposito delle relazioni chiave
all’interno del sistema. Tutto questo è particolarmente importante per
quanto riguarda sistemi che utilizzino diverse ontologie provenienti da
differenti domini: le ontologie servono a questo punto per esplicitare tutte le assunzioni alla base dei modelli e delle reti di relazioni, in
modo da identificare le connessione logiche tra gli elementi di modelli
diversi. Ancora una volta, il ruolo dell’ontologia è quello di mediatore,
questa volta essenzialmente tra diversi insiemi di assunzioni a proposito
di modelli e relazioni tra entità.
• Consistenza e mancanza di ambiguità: uno dei ruoli più importanti che le ontologie giocano nella comunicazione è quello di costituire
una definizione priva di ambiguità per i termini utilizzati in un dominio
6
o in un sistema software. Inoltre, il carattere di formalità di tale definizione rende possibile interventi di verifica e mantenimento automatici
della consistenza dell’insieme stesso di definizioni.
2.2.2
Ontologie ed interoperabilità (persone, tools) Ontologie come INTERLINGUA
Alcune applicazioni delle ontologie sono rivolte a permettere l’interoperabilità tra differenti utenti con la necessità di scambiare dati o di utilizzare
differenti sistemi software. Un tema assai importante in questo senso è quello di realizzare un substrato, un ambiente integrato, che permetta di far
cooperare differenti sistemi software, i quali in partenza utilizzano formati e
terminologie non direttamente compatibili. E’ chiaro che pensare ad una cooperazione tra n sistemi che “non si capiscono” senza utilizzare alcuno strato
intermedio rende necessario sviluppare interfacce di comunicazione tra ogni
coppia di sistemi, ovvero in totale n (n - 1) / 2 traduttori specifici. Come
è noto dalla conoscenza dei criteri base della progettazione di compilatori,
l’utilizzo di un “linguaggio intermedio” tra i vari linguaggi possibili riduce il
numero di traduttori necessari a 2n (n nel caso di interfacce di conversione
bidirezionali). Tale linguaggio intermedio, naturalmente, costituisce l’ambiente integrato entro il quale far collaborare i diversi sistemi o soggetti, ed è
realizzabile mediante l’utilizzo di una ontologia per la traduzione dei diversi
formati (di nuovo, mediante regole di mapping). Ancora una volta, l’ontologia si candida ad essere un efficace mediatore tra soggetti che non siano in
grado di “capirsi” direttamente. L’aspetto interessante è che un tale approccio all’integrazione di sistemi diversi con la necessità di cooperare non rende
necessario apportare alcuna modifica ai sistemi stessi, ma solo realizzare il
substrato comune e le varie interfacce di traduzione verso i formati specifici
dei diversi sistemi. In pratica, si tratta di realizzare un’ontologia del dominio
di interesse e di scrivere le regole di traduzione (di mapping) per ogni sistema
interessato all’integrazione.
2.2.3
Ontologie e Ingegneria del Software
Una comprensione concordata e condivisa del problema da risolvere può assistere con profitto nella specificazione di un sistema software. Ad esempio,
il Businnes System Development Method (BSDM) della IBM utilizza un’ontologia dell’organizzazione come base per progetto e sviluppo nell’ambito
dell’Information Technology. Naturalmente, il ruolo dell’ontologia nella specifica varia con il grado di formalità e di automatizzazione che si utilizza
7
nella metodologia di progetto. In un approccio informale, le ontologie facilitano la comprensione dei processi e l’identificazione dei requisiti del sistema,
nonchè la comprensione delle relazioni tra le componenti del sistema. Ciò
è particolarmente importante nel caso di sistemi sviluppati da team distinti
che operano su domini diversi. Ancora una volta, il ruolo dell’ontologia come
mediatore si dimostra assai utile. In un approccio più formale, un’ontologia permette di fornire una specifica dichiarativa del sistema che si intende
realizzare. Anche in questo caso, la possibilità di operare verifiche automatiche su una specifica formale risulta assai importante (si pensi per esempio
alle metodologie di specifica formale dei requisiti utilizzate nell’Ingegneria
del Software). In questo modo, è possibile fornire garanzie di robustezza e
di completezza delle specifiche, con chiare, positive conseguenze sulla qualità
del prodotto finale. D’altro canto, è sensato pensare che ad una specifica
formale dei requisiti di un sistema software si possa far corrispondere, entro
certi limiti, uno svolgimento automatico, o pseudo-automatico, dei successivi
passi dello sviluppo del software.
2.3
2.3.1
Cenni sulla costruzione di ontologie
Le metodologie
L’aspetto principale da tenere in considerazione quando si costruisce un’ontologia è la sua caratteristica di concettualizzazione condivisa tra più soggetti.
Di conseguenza, le diverse tipologie di approccio alla progettazione ed alla
realizzazione di un modello ontologico si differenziano, tra l’altro, in base al
grado di partecipazione di tali diversi soggetti allo sforzo di concettualizzazione del dominio di interesse. In particolare, considerando anche il punto di
vista adottato dagli sviluppatori rispetto alle particolari istanze del dominio
che si vuole andare a rappresentare, si possono distinguere cinque approcci
principali (più eventuali soluzioni ibride) alla progettazione di ontologie:
• Approccio “ispirato” un solo sviluppatore parte da una premessa
circa il perchè sia richiesta un’ontologia e, basandosi esclusivamente
sulla propria immaginazione e creatività, e sul proprio punto di vista a
proposito del dominio d’interesse, progetta e sviluppa l’ontologia.
• Approccio induttivo: l’ontologia è sviluppata osservando, esaminando ed analizzando casi specifici (istanze) nel dominio d’interesse.
• Approccio deduttivo: al contrario, un approccio deduttivo è concepito adottando alcuni principi generali ed applicandoli adattativamente
8
fino a costruire una ontologia orientata ad un dominio specifico. In pratica, prevede la specializzazione ad un particolare dominio di un insieme
di nozioni di validità generale.
• Approccio sintetico: uno sviluppatore identifica un insieme di ontologie, scelte in modo che nessuna costituisca un sottoinsieme di un’altra.
L’insieme delle caratteristiche di queste ontologie di base, insieme ad
altri concetti selezionati che si riferiscono al dominio che dev’essere descritto, viene sintetizzato in modo da costruire una ontologia unificata.
Un’operazione di questo tipo coinvolge fasi di integrazione sistematica
dei concetti, di eliminazione delle incompatibilità e di riconciliazione
delle diverse terminologie.
• Approccio collaborativo: in questo caso, lo sviluppo dell’ontologia è il risultato dello sforzo congiunto di tutti, o comunque di molti,
i possibili utilizzatori dell’ontologia stessa, allo scopo di rispecchiare
esperienze e punti di vista di persone diverse che cooperano in modo
da ottenere una rappresentazione il più possibile generale e flessibile del
dominio d’interesse. In particolare, un’attività di questo tipo può proficuamente essere incentrata attorno alla figura di un progettista o di
un gruppo di progettisti che realizzano un prototipo iniziale dell’ontologia (ad esempio, basandosi su uno degli approcci visti in precedenza);
compito di tale o tali progettisti è poi quello di proporre ad ogni soggetto che collabora allo sviluppo il prototipo iniziale, e di recepire quindi
le indicazioni di tutti i collaboratori a proposito delle aggiunte o delle
variazioni necessarie per perfezionare il prototipo. Questi due passi,
distribuzione del prototipo corrente e raccolta di opinioni (variazioni
ed aggiunte), vengono auspicabilmente svolti in modo iterativo, onde
pervenire all’ontologia tramite una serie di raffinamenti incrementali.
In pratica, l’idea è quella di un gruppo di esperti di ontologie che guidi
un gruppo di esperti del dominio nei passi necessari ad ottenere un
modello completo e soddisfacente.
2.3.2
Commenti e confronti critici
In generale, è evidente come la scelta di uno di questi approcci non dipenda
da criteri generali di validità, bensı̀ principalmente da considerazioni relative alle particolari caratteristiche e necessità del caso pratico in questione.
Ad esempio, è abbastanza chiaro che un approccio come quello cosiddetto
ispirato risulta assolutamente sensato ed efficace qualora il punto di vista
dello sviluppatore sia molto simile, o meglio ancora uguale, a quello degli
9
utilizzatori dell’ontologia. In caso contrario, un approccio di questo genere può costringere i soggetti diversi dallo sviluppatore ad adattarsi al suo
punto di vista, il che rischia di fare perdere quei vantaggi di mediazione tra
“viste” diverse che abbiamo indicato, ripetutamente, come l’essenza dell’utilizzo di ontologie. In questo senso è quindi facile pensare che un approccio
più vantaggioso possa essere quello cosiddetto collaborativo, che permette
una miglior copertura dei punti di vista di possibili diverse tipologie di utenza. Un modello ontologico costruito in questo modo, dunque, si propone
potenzialmente come il migliore dal punto di vista della generalità, essendo
originato da uno sforzo di comunicazione e di precisazione di diverse aspetti
del dominio di interesse ad opera di persone diverse. Tuttavia, l’approccio
collaborativo comporta anche alcuni aspetti svantaggiosi, correlati in particolare al numero di persone coinvolte nel progetto, certo maggiore di quanto
non sia negli altri casi. Un incremento eccessivo di tale numero di persone
comporta tempi sensibilmente allungati per quanto riguarda ogni iterazione
delle fasi di presentazione del prototipo e di raccolta del feedback. D’altra
parte, può condurre in certi casi ad una fase di stallo, nel momento in cui le
esigenze ed i punti di vista di diversi collaboratori dei progettisti “centrali”
si trovino ad essere in qualche modo incompatibili. In sostanza, dunque, una
scelta come quella di approccio collaborativo alla realizzazione di ontologie
rende di vitale importanza l’abilità dell’esperto nel coordinare i diversi soggetti che collaborano alla realizzazione dell’ontologia, e nel mediare tra le
diverse spinte derivanti dal contrapporsi di punti di vista diversi a proposito
del modello da realizzare.
Per quanto riguarda le altre tipologie di approccio, è necessario sottolineare come nessuna di esse sembri poter condurre a modelli la cui generalità
sia paragonabile a quella di ontologie costruite mediante approccio collaborativo. Il caso di approccio induttivo, ad esempio, ha il chiaro pregio di
conformarsi bene a casi reali di utilizzo dell’ontologia. Tuttavia, questo pregio costituisce in qualche misura anche il limite principale di una scelta di
progetto come questa: infatti, la validità del risultato ottenuto dipende essenzialmente dalla generalità e dalla completezza (rispetto alla totalità dei
casi possibili o almeno probabili) dei casi pratici considerati come punto di
partenza dello sviluppo. D’altra parte, approcci come quello deduttivo o
come quello sintetico hanno il grosso limite di essere scollegati sia da casi
particolari (istanze del dominio di riferimento), sia dal rapporto con esperti
del dominio da modellare. In pratica, la bontà e la completezza del risultato
finale dipendono in misura estremamente elevata dall’abilità dell’esperto di
ontologie che si occupa della modellazione, dalle caratteristiche e dalla validità dei principi generali o delle ontologie preesistenti che si utilizzano come
punto di partenza, e dunque anche dal tipo di dominio su cui si opera (più o
10
meno astratto, più o meno in evoluzione). In pratica, approcci come questi
risultano probabilmente interessanti ed azzeccati in casi molto particolari,
ma non sembrano dimostrare caratteristiche di validità generale.
Una panoramica dei diversi approcci che è possibile adottare per sviluppare un’ontologia è presentata in [15], con particolare attenzione per quanto
riguarda l’approccio collaborativo, a proposito del quale è dato anche un
esempio di modus operandi da parte dell’esperto di ontologie.
2.4
2.4.1
Linguaggi logici per la rappresentazione
di ontologie
Concetti di base
Una distinzione estremamente importante che è necessario tenere in considerazione parlando di linguaggi di rappresentazione di ontologie, è quella tra
livello di rappresentazione concettuale e logica. Il livello concettuale, in particolare, si riferisce (si pensi ai diagrammi Entity - Relationship nel caso di
basi di dati) ai concetti presenti nella realtà che si vuole rappresentare, ed
alle relazioni che tra questi concetti intercorrono. Si tratta dunque di una
rappresentazione legata non tanto ad una esigenza implementativa, quanto
invece ad una esigenza descrittiva. Il livello logico, al contrario, rappresenta
in qualche modo una implementazione di quanto espresso a livello concettuale, il cui scopo è quello di fornire una rappresentazione di una determinata
realtà che sia utilizzabile e gestibile automaticamente, o risulti comunque
formalizzata in modo più preciso e meno di alto livello di quella concettuale.
Quanto detto nelle sezioni precedenti è stato volto essenzialmente a dare
un’idea dei concetti con cui ci si trova a trattare nell’ambito dei modelli ontologici. La presente sezione si propone invece di illustrare come sia possibile
dare una rappresentazione di una ontologia da un punto di vista logico, ovvero una rappresentazione scritta in un linguaggio ben definito, utilizzabile
come punto di partenza concreto dell’utilizzo del modello.
2.4.2
Tipologie di linguaggi ed esempi
È necessario prima di tutto distinguere tra due principali filoni di linguaggi. Infatti, se esistono linguaggi pensati genericamente per rappresentare
ontologie, la tipologia di applicazione dei modelli ontologici basata su web,
genericamente indicata sotto l’etichetta di Semantic - Web, ha portato allo
sviluppo di linguaggi specifici per la rappresentazione di ontologie su web.
11
In particolare, tali linguaggi condividono in genere la caratteristica di appoggiarsi per quanto riguarda la sintassi su linguaggi preesistenti e general
purpose, dei quali costituiscono una sorta di estensione ottenuta mediante
costrutti e vincoli specifici. È il caso ad esempio di linguaggi come OIL, la cui
sintassi è basata su quella di RDF (definizioni di tipo per documenti XML), o
SHOE, la cui sintassi è basata su SGML ed XML, o come RDF stesso il quale, in quanto linguaggio utilizzato per definire tipi, si presta abbastanza bene
a rappresentare nozioni di natura semantica come concetti, strutturazione
di concetti e relazioni (link) fra concetti (cosı̀ come DTD, altro formalismo
per la definizione di tipi basato su XML). Ancora, possiamo ricordare XOL,
linguaggio di definizione di ontologie basato su XML, che differisce da un
linguaggio dedicato come Ontolingua essenzialmente per il fatto che utilizza
una sintassi di tipo XML invece che una sintassi propria (ad esempio, con
notazione funzionale, tipo Lisp). A titolo esemplificativo di questa categoria,
per dare un’idea del tipo di formalismo coinvolto, proponiamo un esempio in
XOL:
<class>
<name>person</name>
</class>
<slot>
<name>age</name>
<domain>person</domain>
<value-type>integer</value-type>
<numeric-max>150</numeric-max>
</slot>
<individual>
<name>Fred</name>
<type>person</type>
<slot-values>
<name>age</name>
<value>35</value>
</slot-values>
</individual>
A proposito invece dei linguaggi pensati appositamente per la rappresentazione di ontologie, sembra interessante illustrare le principali tipologie che
è possibile individuare, dal punto di vista della filosofia di fondo del linguaggio e del tipo di concetti che esso utilizza. È tuttavia indispensabile notare
12
come, accanto ad un utilizzo diretto dei linguaggi per rappresentare ontologie, sia assai importante anche il filone di progetti e strumenti applicativi
incentrati attorno al tema dell’utilizzo di ontologie, il cui scopo in genere è
quello di automatizzare la gestione di un certo numero di sorgenti di informazioni presenti su web (è il caso ad esempio del progetto Ontobroker, che
utilizza come formato di rappresentazione la Frame - logic, linguaggio basato
su frame del quale si darà esempio dopo), oppure quello di permettere la costruzione e l’utilizzo di ontologie senza necessariamente dover interagire con
un linguaggio logico formale, ma basandosi esclusivamente su un interfaccia
di tipo grafico (è il caso, ad esempio, del sistema Protege 2000, che si basa
per la rappresentazione interna su RDF e SHOE).
Una rassegna completa e dettagliata delle tipologie di linguaggi di rappresentazione di ontologie, e di esempi, è presente in [5].
Si prenderanno ora in considerazione linguaggi basati su frame e linguaggi basati su un’architettura ad oggetti, tipologie fondamentali dei linguaggi
dedicati alla rappresentazione di ontologie, dando esempio di casi particolari
dell’uno e dell’altro tipo, nonchà di eventuali progetti che utilizzano l’uno
piuttosto che l’altro tipo di formalismo.
Linguaggi basati su Frame
Si tratta di linguaggi che prevedono primitive per la gestione di definizione,
estensione ed istanziazione di classi, definizione di attributi, specifica di valori, definizione di predicati e regole. In genere, predicati e regole, cosı̀ come, in
un secondo momento, le interrogazioni, vengono rappresentati mediante una
sintassi derivata dalla logica del primo ordine, per la quale esistono importanti e ben noti risultati teorici a proposito delle possibilità e delle tecniche
di computazione e di ottimizzazione del calcolo automatico. In particolare,
le regole prevedono l’utilizzo dei consueti connettivi logici (AND, OR, NOT,
implicazione), e di variabili quantificate universalmente od esistenzialmente.
È il caso, ad esempio, di Ontolingua, o del linguaggio Frame - logic utilizzato per rappresentare ontologie all’interno del progetto Ontobroker, del quale
mostriamo ora un esempio di rappresentazione di un’ontologia:
Object[].
Person :: Object.
Employee :: Person.
Researcher :: Employee.
Student :: Person.
Publication :: Object.
Organization :: Object.
13
Person
[
firstName =>> STRING;
lastName =>> STRING;
eMail =>> STRING;
publication =>> Publication;
].
Employee
[
affiliation =>> Organization;
].
Researcher
[
cooperatesWith =>> Researcher;
worksFor =>> Organization;
]
Publication
[
author =>> Person;
title =>> STRING;
year =>> NUMBER;
abstract =>> STRING;
]
FORALL Person1, Person2
Person1:Researcger[cooperatesWith ->> Person2] <Person2:Researcher[cooperatesWith ->> Person1].
FORALL Person1, Publi
Person1:Person[publication ->> Publi] <->
Publi:Publication[author ->> Person1].
Esempio di interrogazione (ricerca di informazioni):
FORALL Obj, LN, EM <Obj: Researcher[firstName ->> "Pietro";
lastName ->> LN;
14
email ->> EM],
che richiede cognome ed e - mail di tutti i ricercatori di nome Pietro.
Linguaggi orientati agli oggetti
Sono linguaggi la cui funzione è quella di rappresentare un insieme di entità (concetti ed istanze in corrispondenza di classi ed oggetti) mediante
un’architettura analoga a quella dei comuni linguaggi di programmazione ad
oggetti (come Java o C++). In questo senso, uno sforzo normativo è dato
dall’esistenza di standard internazionali che fungono da riferimento per la
descrizione di sistemi ad oggetti, standard che possono essere estesi allo scopo di risolvere il problema specifico della rappresentazione di ontologie. E’
il caso ad esempio del linguaggio logico ODLI3, sviluppato come estensione
dello standard ODMG-93 per la rappresentazione di architetture ad oggetti.
Nella sezione 2.6 forniamo, a titolo di esempio completo di linguaggio per la
rappresentazione di ontologie, una panoramica completa delle potenzialità e
dei costrutti principali di tale linguaggio.
2.5
Il linguaggio concettuale X-Formalism
Il linguaggio X-formalism è stato definito nell’ambito del progetto Artemisper la rappresentazione concettuale di schemi di dati XML. Il linguaggio
X-formalism prevede tre tipi principali di entità, definiti X-type, X-class
ed EXF Frame (EXF sta per eXtended X-Formalism), quest’ultimo definito
semplicemente come insieme di X-types ed X-classes. Di tali concetti viene
data una definizione formale, in termini di parti che li costituiscono: per
esempio, un X-type è definito come una quadrupla, che comprende un nome
(eventualmente con un tipo padre), un modello del contenuto (una sorta di
struttura di quanto segue), una lista di proprietà (ognuna con nome, tipo ed
eventuale tipo padre, cardinalità, lista di attributi), un insieme di attributi.
Ogni attributo è visto a sua volta come una tripla, formata da un nome, un
tipo ed una cardinalità. Definizione dello stesso genere viene quindi data per
una X-class.
È importante sottolineare come definizioni di questo genere permettano
di rappresentare con estrema facilità i DTD e gli XML-Schema, la cui struttura ricalca quella formalizzata nelle definizioni di X-type ed X-class. Come
appare evidente, questo genere di rappresentazione, estremamente comodo
se si tratta di rappresentare, magari automaticamente, la struttura di DTD
ed XML-Schema, e dunque poi di ricavare conoscenza da documenti XML
che a tali modelli del contenuto si rifanno, risulta abbastanza ostica per una
15
lettura immediata da parte di una persona. Si è pensato dunque di dare una
rappresentazione grafica di ogni concetto utilizzato in X-formalism (classi,
attributi, proprietà, link tra classi. . . ), onde semplificare il più possibile l’approccio umano a questo tipo di rappresentazione concettuale di ontologie. Di
seguito, diamo una breve spiegazione testuale dei concetti che intervengono
nella definizione di una X-class, e le primitive di traduzione in un linguaggio
grafico (figura 2.1). Quindi, riportiamo un esempio di XML-schema (figura
2.2.(a)) ed uno di DTD per documenti XML (figura 2.2.(b)), la concettualizzazione del secondo mediante X-formalism (figura 2.3) e la rappresentazione
grafica di tale concettualizzazione (figura 2.4). Una X-classe rappresenta
un insieme di elementi con una struttura comune. Per struttura si intende
un insieme di proprietà e/o di nomi di X-classi referenziate. Una proprietà
(property) di una X-classe descrive una caratteristica di un elemento rappresentato dalla X-classe; essa è costituita, come già ricordato, da un nome,
un tipo, una cardinalità ed una lista di attributi. Una X-classe referenziata
(referenced X-class) per una X-classe c è una X-classe c’ che appare nella
struttura di c; un concetto di questo tipo serve per esprimere una relazione
tra la X-classe c e la X-classe c’. Un link, caratterizzato da nome e tipo, serve per descrivere relazioni tra diversi documenti. Un attributo (attribute),
caratterizzato da nome e tipo, descrive una caratteristica addizionale di una
proprietà, di un link, di una X-classe. Tali concetti vengono rappresentati
graficamente mediante le primitive riportate in figura 2.1
Concept
Graphical representation
X-class
=⇒
property
link
attribute
referenced class
or
union structure
and
sequence structure
Figura 2.1: Primitive per la rappresentazione grafica di X-formalism
(Si noti che per union structure si intende l’alternativa tra due (o più)
16
strutture, mentre per sequence structure si intende la concatenazione di due
(o più) strutture. In particolare, se s1 ,s2 ,. . . ,sn sono strutture, dal punto di
vista formale (s1 ,s2 ,. . . ,sn ) è una sequence structure, mentre (s1 |s2 ) è una
union structure).
Per una definizione formale completa di X-formalism, si vedano [4] e [7].
Accanto a quanto è stato detto a proposito di DTD ed X-formalism,
ricordiamo che un’estensione di tale linguaggio (X-formalism esteso) è
stata successivamente introdotta allo scopo di modellare in modo semplice ed
efficace una diversa tipologia di rappresentazione della struttura generale di
documenti XML, chiamata XML Schema. L’idea di fondo rimane ovviamente
sempre quella di fornire un modello formale della struttura di documento in
questione, allo scopo di integrare poi facilmente le informazioni contenute
nei documenti che istanziano lo schema in questione. Le estensioni principali
rispetto ad X-formalism riguardano una gestione più dettagliata e fine dei
meccanismi di tipizzazione, per esempio la possibilità di definire liste, gruppi
di elementi, meccanismi di indicizzazione mediante chiavi e chiavi esterne,
derivazione di nuovi tipi da tipi esistenti, ed altre caratteristiche ancora.
Per una presentazione più completa e dettagliata a proposito di X-formalism
esteso, si veda [12].
È importante infine notare come un meccanismo di traduzione del modello formale in un modello grafico sia stato elaborato anche per X-formalism
esteso: com’è facile immaginare, le primitive grafiche (figura 2.5) sono strettamente collegate a quelle già mostrate in precedenza, dalle quali d’altra
parte derivano. Di seguito, diamo un elenco di tali primitive, ed un esempio
di modello grafico di un XML Schema.
17
<?xml version=‘‘1.0’’ ?>
<!DOCTYPE products SYSTEM ‘‘product.dtd’’>
<products>
<computer brand=‘‘toshiba’’>
<PC>
<name>Satellite Pro 4200</name>
<spec>Pentium III 450 MHz</spec>
<price> $ 3.000</price>
</PC>
<PC>
<name>Portege 7200CT</name>
<spec>Pentium III 600 MHz</spec>
<price> $ 4.000</price>
</PC>
</computer>
<software>
<item>
<name>GNU Emacs 20.5.1</name>
<note>Linux</note>
<tohome xlink:href=‘‘http://www.gnu.org’’>
GNU’s home page
</tohome>
</item>
</software>
</products>
(a)
<!DOCTYPE products [
<!ELEMENT products (computer+,software)>
<!ELEMENT computer (PC)+>
<!ELEMENT software (item)+>
<!ELEMENT PC (name,spec,price)>
<!ELEMENT item (name,note,price?,tohome?)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT spec (#PCDATA)>
<!ELEMENT price (#PCDATA)>
<!ELEMENT tohome (#PCDATA)>
<!ELEMENT note (#PCDATA)>
<!ATTLIST tohome
xmlns:xlink CDATA #FIXED http://www.w3.org/1999/xlink
xlink:href CDATA #REQUIRED>
<!ATTLIST computer
brand CDATA #REQUIRED>
]>
(b)
Figura 2.2: Esempio di DTD
18
hproducts, (computer+, software),{},{},{computer,software},{}i
Figura 2.3: Esempio di rappresentazione mediante X-formalism
PRODUCTS
(1,n)
brand
COMPUTER
SOFTWARE
(1,n)
(1,n)
ITEM
PC
name
spec
price name
note
(0,1)
price
(0,1)
tohome
href
Figura 2.4: Esempio di X-formalism rappresentato graficamente
Figura 2.5: Primitive per la rappresentazione grafica di X-formalism esteso
19
Figura 2.6: Esempio di X-formalism esteso rappresentato graficamente
20
2.6
Il linguaggio ODLI 3
ODLI 3 è il linguaggio di rappresentazione interna utilizzato da Artemis. Il
linguaggio è conforme allo standard ODMG-93 (Object Database Standard),
che per alcuni aspetti estende.
Concetti fondamentali di ODMG-93 sono i consueti concetti di classe,
oggetto, attributo e metodo, tipici della programmazione ad oggetti e, più in
generale, di una qualunque architettura basata su di una struttura ad oggetti.
Essenziali ovviamente sono anche i concetti di ereditarietà e specializzazione.
class Persona
{
String nome;
Date dataDiNascita;
// Metodi
Persona(); // Costruttore: nasce una nuova persona
int età(); // Restituisce un tipo atomico
};
class Atleta: Persona // Una sottoclasse di Persona
{
String disciplina;
String categoria;
// Metodi
int ultimoRisultato();
};
class Podio // Una classe con valori complessi
{
String nomeGara;
Persona primoClassificato;
Persona secondoClassificato;
Persona terzoClassificato;
};
Si noti come il meccanismo delle classi con valori complessi corrisponda
abbastanza esattamente a quello che in X-formalism era il significato delle
referenced XClass.
Lo standard che stiamo prendendo in esame permette di stabilire delle
21
relazioni tra oggetti. Esse hanno il ruolo dei puntatori nei linguaggi di programmazione, arricchito tuttavia da alcuni aspetti essenziali, come la persistenza e la possibilità di realizzare verifiche di integrità, le cui condizioni
possono essere espresse nello schema e gestite automaticamente. Ciò viene
fatto dichiarando che una relazione è simmetrica.
class Animale
{
String razza;
String nome;
Ref <Proprietario> appartieneA inverse possiede;
}
class Proprietario:
Persona
{
Ref <Animale> possiede inverse appartieneA;
}
nell’ipotesi che ogni proprietario possieda un solo animale, e viceversa.
Volendo invece rappresentare una relazione uno a molti, o molti a molti,
è necessario introdurre prima i costrutti che permettono di modellare collezioni di oggetti (ordinate - List - o non ordinate - Set -).
Set < Ref < Atleta > > Squadra;
Set < Ref < Animale > > Animali;
List < Ref < Persona> > Persone;
In questo modo, è possibile rappresentare relazioni multiple come segue:
class Persona
{
String nome;
Date dataDiNascita;
Set < Ref < Persona > > genitori inverse figli;
Set < Ref < Persona > > figli inverse genitori;
Set < Ref < Animale > > possiede inverse appartieneA;
// Metodi
Persona();
int età(); // Restituisce un tipo atomico
void sposa (Ref <Persona> consorte);
}
22
Accanto all’ODL (Object Definition Language) sommariamente presentato,
lo standard ODMG-93 introduce un linguaggio di query, OQL (Object Query
Language), il quale risulta essere in sostanza un soprainsieme della sezione
di query di SQL’92.
Tale linguaggio permette di sottomettere ad un sistema, genericamente
organizzato secondo un’architettura client - server, interrogazioni relative agli
oggetti in esso contenuti, secondo una sintassi estremamente simile a quella
di SQL. In particolare, una della caratteristiche di OQL è quella di mantenere la compatibilità con le query SQL. Accanto a questa, senza dubbio
importantissima è la caratteristica di indipendenza fisica e logica dalle strutture dati sottostanti, caratteristica peraltro essenziale, in genere, per tutti i
linguaggi logici. Chiaramente, un sistema di questo genere si presta molto
bene a far sı̀ che le interrogazioni possano essere ottimizzate da un apposito
modulo del server OQL, e semplifica dunque notevolmente tanto la scrittura
di applicazioni dedicate quanto l’eventuale utilizzo di OQL in interrogazioni
cosiddette embedded (per esempio, all’interno di applicazioni C++).
Di seguito presentiamo alcuni esempi di interrogazioni OQL, il cui significato appare estremamente chiaro a chi abbia una minima conoscenza
di SQL. Notiamo che l’accesso agli elementi interni ad oggetti complessi è reso possibile mediante l’utilizzo della tradizionale notazione puntata
(nomeOggetto.nomeAttributo o nomeOggetto.nomeRelazione) o, equivalentemente, mediante la notazione ->.
select p.nome
from Animali a, a.appartieneA f
select f.nome
from Persone p,p.figli f
il cui risultato chiaramente non è un valore atomico bensı̀ un insieme, più
precisamente del tipo Bag < String >, ovvero un insieme che può contenere
elementi ripetuti.Per avere ciò che logicamente può interessare in un caso
del genere, ovvero l’insieme (nel senso proprio del termine) dei figli di una
persona, si avrà
select distinct f.nome
from Persone p,p.figli
Complicando un po’ gli esempi,
select a.nome, a.razza
from Persone p, p.possiede a
23
where p.nome = Giovanni Rossi and
count (p.figli) >= 2
select p.nome
from Persone p,
select distinct p.possiede) as a
where p.nome = a.nome
Una grande differenza rispetto ad SQL consiste nel fatto di poter creare
qualunque genere di valore complesso come risultato finale di una interrogazione, cosı̀ come risultato intermedio all’interno di una query.
select struct (
io: p.nome
miaEtà:p.età
mieiGenitori: (select struct (
nome: f.nome,
età: f.età
)
from p.genitori f)
)
from Persone p
Come si vede, quest’ultima interrogazione crea come risultato una struttura
che corrisponde ad un sottoinsieme dei valori complessi di Persona. In particolare, il tipo dei valori restituiti dalla precedente query è
struct TipoRisultante
{
String io;
int miaEt’a;
Bag < struct
{
String nome;
int et’a;
}
> mieiGenitori;
}
Ancora, nelle interrogazioni OQL è possibile invocare metodi sugli oggetti.
Inoltre, l’architettura object oriented permette di sfruttare il cosiddetto po24
limorfismo, e dunque di avere una scelta dinamica della classe sulla quale invocare un determinato metodo (ovvero, un metodo invocato formalmente su
una certa classe potrebbe in realtà essere invocato su un oggetto appartenente
ad una sottoclasse di tale classe: la scelta avviene dinamicamente).
class Persona
{
// Attributi
//...
// Metodi
//...
virtual Set < String > attività;// Un metodo ridefinibile
}
class Atleta
{
// Attributi
//...
// Metodi
//...
virtual Set < String > attività;
// Il metodo è stato ridefinito
}
class Impiegato
{
// Attributi
//...
// Metodi
//...
virtual Set < String > attivit’a;
// Il metodo è stato ridefinito
}
select p.attività
from Persone p
Chiaramente, l’invocazione di metodo p.attività può far riferimento indifferentemente ad un oggetto di tipo Persona, ad uno di tipo Atleta o ad
uno di tipo Impiegato.
Ancora, come in SQL, esiste la possibilità di creare viste intermedie
(define nomeVista as select .........) sulle quali operare successiva25
mente nuove interrogazioni. Chiaramente, è possibile anche effettuare la
stessa ricerca complessiva annidando due differenti query.
OQL prevede poi la possibilità di comporre operatori con l’unico vincolo
di rispettare le corrispondenze tra i tipi.
Infine, come SQL, OQL include operatori su insiemi (union,intersect,except),
quantificatori (for all, exists), operatori aggregati (min, max, count,
sum, avg), caratteristiche di raggruppamento (group by) e di ordinamento
(order by) all’interno delle interrogazioni.
Diamo ora di seguito qualche accenno a proposito delle principali estensioni
introdotte da ODLI 3 rispetto ad ODMG-93.
• Optional constructor: denotato mediante (?), è introdotto per classi che hanno un attributo opzionale (cioè la cui presenza in un’istanza
non è necessaria). Anche in questo caso, l’esigenza di fondo è quella di
catturare le caratteristiche di dati semistrutturati. Si veda ad esempio
la seguente dichiarazione:
{
attribute String city;
attribute String street;
attribute String zipcode;
}
union
{
string;
},
che rappresenta il fatto che un indirizzo può essere semplicemente una
stringa di caratteri, oppure essere scomposto in tre parti distinte.
• Terminological relationships: esprimono relazioni tra la terminologia delle diverse sorgenti di informazioni integrate. Esse sono definite
tra classi ed attributi, e sono specificate considerando i nomi di attributi e classi, denotati come termini. In particolare, ODLI 3 permette
di specificare i tre seguenti tipi di relazione terminologica:
– SYN (synonym-of), definita tra due distinti termini t ed u che
sono sconsiderati sinonimi in ogni sorgente considerata.
– BT (Broader Terms, o hypernymy), definite tra due termini t ed
u tali che t ha un significato più ampio e generale di u.
26
– RT (Related Term), o associazione positiva, utilizzata per termini che sono utilizzati genericamente nello stesso contesto nelle
sorgenti considerate.
Si considerino ad esempio due sorgenti di informazioni ED ed FD. Relazioni terminologiche sono ad esempio
<ED.FastFood RT ED.Owner>
<FD.Restaurant BT FD.Bistrot>
Cosa assai importante, esiste la possibilità di derivare automaticamente
nuove relazioni terminologiche implicite in un insieme di relazioni date.
• Rules (regole): ODLI 3 introduce due generi di regola: regole if then,
per esprimere in maniera dichiarativa vincoli di integrità interni alle
sorgenti e tra sorgenti distinte; regole di mapping, per esprimere le
relazioni tra la schema description dello schema d’integrazione e la
schema description delle sorgenti originali. Esempio: regola if then
rule Rule1 forall X in FoodPlace:
X.category = ’High’) then X.price > 100;
Esempio: regole di mapping
attribute integer price
mapping rule (S.car.ItalianPrice union
S.car.USPrice
on Rule2)
rule Rule2
{
case of S.car.country:
Italy: S.car.ItalianPrice;
US: S.car.USPrice;
}
O ancora, considerando l’esempio di due sorgenti di informazioni ED
ed FD,
interface FoodPlace
{
attribute name
mapping rule
ED.FastFood.name,
FD.Restaurant.name,
27
FD.Brasserie.name;
attribute category
mapping rule ED.FastFood.category,
FD.Restaurant.category,
FD.Bistro.type;
attribute zone
mapping rule ED.FastFood = ’Pacific Coast’,
FD.Restaurant = ’Atlantic Coast’,
FD.Bistro = ’Atlantic Coast’,
FD.Brasserie =’Atlantic Coast’;
}
regole la cui utilità è evidente nel momento in cui si debbano “convertire” interrogazioni sottoposte allo schema globale in interrogazioni
da sottoporre ai singoli schemi relativi alle sorgenti di partenza.
28
Capitolo 3
Utilizzo di ontologie
3.1
Introduzione
Accostandosi al problema dell’utilizzo di una ontologia, si possono individuare alcune principali categorie di utilizzo, che permettono di inquadrare
in modo preciso le varie problematiche che vengono a porsi, a proposito
per esempio dei formalismi necessari per interfacciare l’ontologia verso i suoi
utenti.
Si tratta per esempio di distinguere i diversi livelli di astrazione ai
quali vogliamo rendere possibile l’accesso alle informazioni contenute in una
ontologia. Cosı́ si puó immaginare la necessitá di effettuare ricerche di informazioni a partire da un concetto, oppure a partire da un particolare termine
o, ancora, da un insieme di concetti compresi nell’ontologia.
A proposito invece del tipo di informazione che si desidera ricavare,
si puó pensare di voler accedere alle informazioni strutturali dell’ontologia,
per esempio alle relazioni tra due concetti dati, e d’altra parte é logico immaginare un utilizzo volto al reperimento di riferimenti a particolari istanze
di questo o quel concetto, o insieme o categoria di concetti, istanze presenti
in una o piú delle sorgenti di informazioni che l’ontologia integra.
D’altro canto, sembra importante tenere in considerazione anche il ruolo e la tipologia dell’utente dell’ontologia: infatti un differente grado di
esperienza a proposito del concetto stesso di ontologia, e dei formalismi e
delle strutture che esso comporta, porta a diverse possibilitá di utilizzo della
nostra concettualizzazione di un dominio. Mentre un esperto di ontologie
può muoversi con una certa facilitá, per esempio, tra i concetti di relazione,
categoria, concetto, sorgente di conoscenza, solo per citarne alcuni, e probabilmente ha anche una certa esperienza di formalismi di rappresentazione di
tutti questi concetti, un utente esperto del dominio ma assolutamente digiu-
29
no del concetto stesso di ontologia necessita di poter far uso di questo potente
modello senza doverne essere cosciente.
Infine, altra distinzione è quella tra utenti di tipo umano ed utenti “automatici”, ovvero moduli software che desiderano fare uso delle potenzialitá
offerte dal modello ontologico.
3.2
Modalità di utilizzo di ontologie: descrizione dettagliata
Vediamo ora, più dettagliatamente, le diverse tipologie di utilizzo di ontologie
sopra indicate. Come apparirà chiaro, le classificazioni di seguito approfondite non sono tutte mutuamente esclusive ma, al contrario, si possono articolare
in gruppi tra loro ortogonali, a seconda della peculiarità presa in considerazione (per esempio, il tipo di utente è ortogonale al tipo di approccio alla
ricerca di informazioni). Per comodità, nella seguente descrizione le tipologie
di utilizzo relative alle diverse caratteristiche distintive considerate saranno
raggruppate tra di loro.
3.2.1
Differenti livelli di astrazione
Come si è accennato prima, una distinzione tra le tipologie di utilizzo di una
ontologia è relativa al livello di astrazione dal quale si desidera partire per
ricercare ed ottenere informazioni.
Ricerca in base a categorie di concetti
Una prima possibilità, in questo senso, è quella di voler ottenere informazioni
partendo da una categoria di concetti molto generale, che comprenda un
insieme più o meno vasto di concetti dell’ontologia. Si tratta in qualche
modo di considerare una particolare vista dell’ontologia, ovvero di valutarne il
contenuto informativo partendo da un livello di astrazione superiore a quello
degli stessi concetti che l’ontologia considera e lega tra di loro.
Si pensi ad esempio ad una ontologia che rappresenti la tassonomia del
mondo animale (una tassonomia è, ovviamente, un caso particolare di ontologia). Una ricerca del tipo di quella qui descritta può essere ad esempio
quella di chi voglia ricercare informazioni sugli animali domestici : infatti,
tale categoria non esiste come elemento della tassonomia scientifica, e tuttavia individua un insieme di concetti (specie animali nel caso in questione)
organico e definito, ovvero quella che si è chiamata una vista sull’ontologia.
30
Ricerca in base a concetti
Una seconda possibilità, naturalmente, consiste nel voler ricercare informazioni a proposito di un particolare concetto contenuto nell’ontologia: è questo
forse il genere di utilizzo più semplice da immaginare, che permette un accesso alle informazioni dell’ontologia ad un livello di astrazione che è lo stesso
al quale sono identificati e correlati i concetti al suo interno.
Sempre facendo riferimento alla tassonomia del mondo animale, una ricerca di questo genere è per esempio quella effettuata focalizzando la propria
attenzione sul concetto di gatto europeo: si tratta infatti di due concetti della
nostra ontologia, in base ai quali si desidera ricercare informazioni.
Ricerca keyword-driven
Si può poi pensare ad un accesso keyword-driven all’ontologia, ovvero ad una
ricerca di informazioni che parta da un insieme di termini, non necessariamente corrispondenti a concetti o relazioni dell’ontologia. In questo caso, si
utilizzano le relazioni semantiche tra i concetti dell’ontologia, e la conoscenza di relazioni tra termini (per esempio, di sinonimia) per fare il matching
tra le keyword dell’interrogazione e la terminologia dell’ontologia, onde poter
fornire le informazioni desiderate.
Ancora a proposito dell’ontologia di cui negli esempi precedenti, è di
questo genere una ricerca effettuata in base al termine micio: si tratta infatti
di un termine che non si riferisce direttamente ad un concetto dell’ontologia,
ma che per sinonimia è chiaramente legato ad un concetto, quello di gatto,
che all’ontologia appartiene.
3.2.2
Differenza nella tipologia di informazioni ricercata
Un altro criterio di classificazione delle tipologie di utilizzo di un’ontologia si
basa, come indicato in precedenza, sul tipo di informazione che dall’ontologia
si desidera ottenere.
Ricerca di particolari istanze di concetti dell’ontologia
Una modalità di utilizzo abituale di una qualunque metodologia di ricerca di informazioni è quella che comporta la ricerca di particolari istanze di
informazioni, ovvero nel caso ontologico di istanze dei concetti presenti nell’ontologia: ciò significa che, a partire da una categoria di concetti, da un
concetto o da un insieme di keyword, si desidera ricercare un insieme di riferimenti a particolari oggetti collegati a questi concetti (categorie, keyword).
31
Ad esempio, è il caso di voler trovare un elenco di riferimenti a pagine web
collegate al concetto di Animale domestico, oppure ai termini gatto, cane,
canarino.
Ricerca di informazioni strutturali sull’ontologia
Più legata al modello ontologico utilizzato per fornire informazioni ad un
utente, invece, è la modalità di navigazione dell’ontologia orientata al reperimento di informazioni strutturali sull’ontologia stessa: si tratta di valutare
non le caratteristiche estensionali dell’insieme di fonti di dati che l’ontologia integra, bensı̀ le caratteristiche intensionali del modello utilizzato per
integrarle.
Da una parte, dunque, l’esigenza può essere quella di partire da un concetto per conoscerne le proprietà o le eventuali relazioni con altri specifici
oggetti.
Dall’altra, può darsi il caso di voler avere informazioni a proposito della
tassonomia dei concetti rappresentati dall’ontologia, ovvero di voler conoscere
tutti i concetti sussunti da un dato concetto, o che lo sussumono, o ad esso
legati mediante altri tipi di relazione.
In ogni caso, si tratta di una tipologia di acceso ben diversa da quella
precedente, in quanto fornisce informazioni qualitative sui legami (eventuali)
tra concetti e sulle caratteristiche strutturali e tassonomiche di un concetto
(o tipologia di concetti, ovviamente, o concetti collegabili a parole chiave. . . ),
e non informazioni estensionali sulle particolari istanze di un concetto.
3.2.3
Differente grado di esperienza dell’utente
Naturalmente, differenti gradi di esperienza dell’utente, sia relativamente al
dominio cui l’ontologia si riferisce, sia relativamente alle ontologie stesse,
comportano differenti modalità di utilizzo di questo strumento di integrazione di sorgenti di conoscenza. Un utente esperto del concetto di ontologia e di
quanto esso comporta in termini di formalizzazione e modellazione di domini
possiede buone capacità di interagire col modello anche mediante linguaggi
ed interfacce di basso livello, al contrario di un utente digiuno delle problematiche relative alla realizzazione ed all’utilizzo di ontologie. Un utente esperto
(dello strumento, non necessariamente del dominio), ovviamente, è più facilmente in grado di classificare le diverse modalità di utilizzo del modello
ricordate in questa sezione. In questo modo, è evidente come ad un utente
esperto forse del dominio, ma inesperto a proposito delle ontologie, sia necessario offrire possibilità di utilizzo dei servizi offerti dall’ontologia (in ultima
analisi, interfacce) in grado di supplire a questa sua inesperienza: dunque è
32
sensato pensare ad interfacce di tipo grafico, che semplifichino al massimo,
per esempio, l’individuazione delle tipologie di utilizzo desiderato, possibilmente evitando all’utente di dover diventare anche solo in parte esperto delle
problematiche del modello utilizzato per fornirgli informazioni.
3.2.4
Differente tipologia di utente: utente umano ed
utente automatico
Infine, è chiaro che una forte discriminante nell’individuazione di modalità
di utilizzo di modelli di tipo ontologico quella che distingue utenti di tipo
umano e di tipo automatico.
Infatti, è possibile voler sfruttare automaticamente le potenzialità offerte
da una modellazione di un dato dominio come quella di cui si discute. Si
pensi per esempio all’utilizzo di un’ontologia allo scopo di integrare diversi
tool software che si occupano di problematiche affini ma con terminologie e
formati anche solo leggermente diversi.
Evidentemente, la realizzazione di un mediatore tra questi strumenti, basato su una rappresentazione ontologica della semantica del dominio, costituisce una interessante possibilità di integrare detti strumenti senza doverli
modificare. Chiaramente, un mediatore di questo genere deve poter utilizzare le opportunità di mediazione fornite dall’ontologia in modo automatico,
senza richiedere l’intervento di un utente umano. Per quanto riguarda l’utilizzo di ontologie in quest’ottica, si veda [18]. Dunque, è necessario valutare
anche la possibilità di fornire differenti primitive di accesso ad una ontologia,
o meglio primitive di livelli diversi, a seconda che l’utente sia umano o meno.
Per un modulo software è necessario infatti avere a disposizione un’interfaccia formale e ben definita, magari anche di basso livello; si può pensare poi
alla costruzione di un’interfaccia grafica, per utenti umani, che permetta di
tradurre azioni sugli oggetti grafici ed azioni di navigazione all’interno di tale
interfaccia in chiamate alla primitive di basso livello utilizzabili direttamente
da uno strumento automatizzato. In [21] viene presentato un approccio di
questo genere, nel quale un’interfaccia grafica permette di costruire in modo
semplice e trasparente per l’utente query espresse in un linguaggio formale di
basso livello: in particolare, il linguaggio in questione è mutuato dall’Intelligenza Artificiale, e si basa su una variante sintattica della logica del primo
ordine. D’altra parte, la scelta di utilizzare linguaggi di query di questo
genere è comune anche ad altri casi presenti in letteratura.
Riportiamo ora un paio di esempi tratti da [18], che illustrano più chiaramente le due diverse modalità di interazione con un’ontologia appena illustrate.
33
Per quanto riguarda un’interazione estremamente formale, l’articolo indicato utilizza come già detto una sintassi basata sulla FOL (First Order
Logic), ed in particolare presenta un linguaggio, chiamato F.logic, che viene
utilizzato tanto per esprimere conoscenza (per esempio, vincoli di integrità
sull’ontologia) quanto per esprimere interrogazioni all’ontologia stessa. Un
esempio di interrogazione è il seguente:
FORALL Public <- EXISTS ResearcherID
researcherID:Researcher[lastName ->>Martinelli;publication ->> Public].
o, ancora,
FORALL resID1, ResID2 <ResID1:Researcher[cooperateWith ->> ResID2]
and ResID2:Researcher.
In entrambi i casi, ovviamente, la sintassi presentata rappresenta il fatto
che il concetto Researcher possiede gli attributi lastName e publication,
e la relazione cooperateWith.
Appare chiaro che utilizzare un’interfaccia di questo genere risulta fondamentale quando gli utenti siano moduli automatizzati, in genere moduli
software.
Per contro, come si è già detto in precedenza, il problema di un utente
umano è quello di essere facilitato da un’interfaccia di tipo grafico piuttosto
che dal dover utilizzare un linguaggio formale (a proposito del quale tra
l’altro nasce anche una questione di esperienza, di cui si d̀etto in 3.2.3). A
questo proposito, l’articolo [18] presenta quanto messo a punto in portali che
forniscono all’utente un’interfaccia grafica basata sulla geometria iperbolica,
che permette di navigare tra i concetti dell’ontologia, e su un insieme di
check-box e menu a tendina, che permettono di visualizzare le proprietà e le
relazioni di un concetto, di interagirvi e dunque di comporre con facilità le
query. Le query vengono costruite selezionando in apposite finestre grafiche
gli attributi ed i valori per essi desiderati, in relazione ad uno o più concetti.
3.3
L’architettura di ontologia a tre livelli in
ARTEMIS
In questa sezione presentiamo l’architettura di ontologia a tre livelli in Artemis; nelle sezioni successive presenteremo invece i linguaggi concettuali e
34
logici utilizzati per descrivere tale architettura e per rappresentare l’ontologia.
ARTEMIS considera un’architettura di ontologia a tre livelli [5], basata
per quanto riguarda le fonti di informazioni su standard di strutturazione
semantica di documenti legati a DTD ed XML-Schema, le descrizioni di tipi
di dato più comunemente usate per documenti XML.
L’architettura a tre livelli comprende un livello cosiddetto Semantic
mapping layer, ovvero un livello di mapping semantico, che si occupa di
organizzare le diverse sorgenti di conoscenza, o meglio le X-classi che ne rappresentano il contenuto, in cluster di X-classi, ovvero in insiemi di X-classi
affini (benchè in generale di provenienza diversa). A questo punto, i cluster
sono mappati in X-classi globali, che rappresentano in pratica una sorta
di riconciliazione ed unificazione di concetti affini, rappresentati dalle diverse X-classi del cluster, in un solo concetto di livello più alto: questo livello
dell’architettura si dice Interorganizational knowledge layer o Mediation layer. Infine, l’architettura di ARTEMIS prevede un terzo livello, più
astratto, al fine di organizzare la conoscenza sottostante in diverse viste particolari, dipendenti per esempio dal particolare punto di vista che una certa
utenza ha rispetto al dominio che l’ontologia modella. Questo livello, che
permette in pratica ad ogni utente di identificare l’ontologia con l’insieme di
concetti di suo interesse, è detto Subject category layer. L’architettura
di ARTEMIS prevede poi la presenza di link (relazioni) tra i diversi concetti. In particolare, essi possono essere classificati secondo due criteri tra loro
ortogonali:
• link di tipo synonymy (i due concetti sono da considerare equivalenti)
35
• link di tipo hypernymy (relazione di tipo is-a)
• link di tipo hyponymy (relazione inversa della precedente)
• link di tipo positive association (ogni altro tipo di relazione)
- link tra concetti dello stesso livello (es, tra due X-classi globali). Tali
link realizzano in pratica, livello per livello, la struttura tassonomica
dell’insieme di concetti del dominio che l’ontologia modella.
- link tra concetti di diverso livello (es, tra una subject category ed una
X-classe globale). Tali link rappresentano invece i passi di astrazione
tra concetti appartenenti ai diversi livelli dell’ontologia, e permettono
di mantenere un collegamento, navigabile, tra tali livelli.
3.4
Modalità di utilizzo di ontologie e linguaggi di ARTEMIS
Analizziamo ora le suddescritte modalità di utilizzo di una ontologia alla luce
di quanto enunciato a proposito del progetto ARTEMIS. In particolare, è utile considerare che il linguaggio logico ODLI 3 viene utilizzato come linguaggio
di rappresentazione interno ad ARTEMIS di quanto viene espresso a livello
concettuale mediante X-formalism: di conseguenza, le considerazioni che nel
seguito saranno fatte a proposito del ruolo dei costrutti di X-formalism in relazione all’utilizzo di ontologie possono considerate valide anche a proposito
dei costrutti di ODLI 3 .
Pertanto, concentreremo la nostra attenzione sui legami tra il linguaggio
concettuale X-Formalism e le diverse modalità di utilizzo di ontologie, sottintendendo che legami analoghi possono essere individuati tra tali modalità
ed il linguaggio logico di rappresentazione ODLI 3 , tranne nel caso in cui alcuni aspetti di quest’ultimo risultino particolarmente interessanti e rilevanti
rispetto a quanto già detto per X-formalism.
3.4.1
Differenti livelli di astrazione
Ricerca in base a categorie di concetti
Si tratta di utilizzare il livello di astrazione indicato come Categorization
layer: il suo scopo infatti è proprio quello di mostrare all’esterno delle particolari viste sull’ontologia, dalle quali è poi possibile ottenere le informazioni
desiderate navigando i link, sia di tipo intra-layer sia di tipo inter-layer.
36
Ricerca in base a concetti
Chiaramente, il meccanismo di navigazione dei vari tipi di link tra concetti
funziona anche in questo caso; l’unica differenza rispetto al caso precedente
è data dal punto di partenza di questa navigazione: non più una subject
category, bensı̀ una X-classe globale.
Ricerca di informazioni keyword - driven
In questo caso, come si è detto, il problema essenziale consiste nel riportare i
termini utilizzati per definire la ricerca nella terminologia utilizzata dall’ontologia: ancora una volta i link, in particolare quelli di sinonimia, permettono
di realizzare quanto richiesto per fornire le informazioni richieste dall’utente.
Ovviamente, anche i link di tipo hypernymy ed hyponymy contribuiscono
alla traslazione della terminologia della query in quella dell’ontologia.
3.4.2
Differenza nella tipologia di informazioni ricercata
Ricerca di particolari istanze di concetti dell’ontologia
Come detto, la costruzione dei tre livelli dell’architettura di Artemis si basa
su una sorta di livello zero, costituito dalle informazioni esportate, mediante formalismi XML, da sorgenti eterogenee e distribuite. Chiaramente, al
momento della costruzione delle X-classi, si mantiene un collegamento tra
queste nuove entità e le sorgenti di informazioni di partenza; ancora, a livello
della costruzione delle X-classi globali, si mantiene un collegamento con i cluster di X-classi la cui unificazione ha portato alla definizione della X-classe
globale; questo modo, discendendo la tassonomia del modello ontologico fino
al livello delle X-classi, è possibile recuperare e fornire come risposta alla
richiesta sottomessa all’ontologia i riferimenti alle sorgenti di base, istanze
dei concetti che l’ontologia modella.
Ricerca di informazioni strutturali sull’ontologia
Le informazioni richieste vengono reperite navigando i link presenti all’interno
dell’ontologia: link tra concetti del medesimo livello permettono di reperire
informazioni relative alla tassonomia dell’insieme dei concetti che l’ontologia
modella, mentre link tra concetti appartenenti a modelli diversi permettono
di ricostruire le informazioni strutturali relative a concetti di un certo livello
partendo da concetti di livelli diversi, ed ancora di fornire notizie sui legami
37
tra concetti modellati a livelli di astrazione differenti (informazioni sui passi
di astrazione all’interno della modellazione).
3.4.3
Differente grado di esperienza dell’utente
Come detto prima, differenti caratteristiche dell’utente dell’ontologia in termini tanto di conoscenza del dominio quanto di esperienza nel campo dei modelli ontologici rendono sensato pensare alla possibilità di creare viste sull’ontologia: esse, come detto, rendono possibile personalizzare ciò che l’ontologia
mostra ad un determinato utente (o categoria di utenti).
Appare evidente come la caratteristica architetturale di Artemis che più
si presta a venire in contro a questa esigenza sia la possibilità di definire delle
subject categories: il Categorization layer, come detto, è essenzialmente
un meccanismo di creazione di viste sui concetti dell’ontologia, allo scopo di
permettere all’utente di identificare l’ontologia con l’insieme di concetti di
suo interesse. Questo è esattamente ciò di cui si ha bisogno nell’ottica di
affrontare al meglio utilizzi della medesima ontologia da parte di tipologie
diverse di utente. Accanto a questo, considerando specificamente le differenze tra due utenti in fatto di esperienza di modelli ontologici, si vede come un
utente esperto di questi strumenti possa senza problemi far uso di linguaggi di
basso livello, per esempio di un linguaggio di interrogazione con una sintassi
ricalcata sulla logica del primo ordine (FOL) ed un lessico ed una semantica
legati alla rappresentazione formale di X-Formalism. Un utente poco esperto
o addirittura digiuno in fatto di modelli ontologici, al contrario, necessita
di un’interfaccia rispetto a tali strumenti di tipo meno tecnico e più intuitivo: in questo senso, la possibilità di dare una rappresentazione grafica della
concettualizzazione effettuata mediante X-Formalism sembra poter essere un
buon punto di partenza. Infine, il linguaggio logico ODLI 3 , il quale come
detto deriva dallo standard ODMG-93 e risulta dunque collegato anche ad
un linguaggio di interrogazione SQL-like, OQL, si può porre in questo senso
come una sorta di via di mezzo tra l’estremo tecnicismo di un interfaccia
mediante costrutti di tipo FOL ed una interfaccia puramente grafica: OQL
dunque è il mezzo adatto per semplificare l’interazione con una ontologia,
pur mantenendola su un piano formale, preciso e molto espressivo, per un
utente che non sia esperto di ontologie ma per esempio abbia una discreta
conoscenza di linguaggi logici come SQL.
38
3.4.4
Differente tipologia di utente: utente umano ed
utente automatico
Come detto in precedenza, dal punto di vista di questa distinzione tra tipologie di utilizzo dell’ontologia si tratta essenzialmente di poter fornire primitive
di accesso al modello ontologico di diverso livello di astrazione. Da un lato,
come abbiamo visto, X-Formalism costituisce di per sè un linguaggio estremamente formale, che permette dunque di pensare facilmente ad interazioni
tra l’ontologia ed utenti automatizzati. La possibilità tuttavia di dare una
semplice ed efficace rappresentazione grafica dei concetti di X-Formalism non
esclude dall’utilizzo di tale formalizzazione un utente umano: infatti, come
detto nella sezione 3.2.4, l’idea principale sulla quale insistere per far coesistere i due tipi di utenza è quella di sviluppare un’interfaccia grafica che
permetta una costruzione semplice e trasparente di interazioni a livello più
basso. È chiaro come una corrispondenza forte tra X-formalism e sua rappresentazione vada, seppur ancora a livello concettuale, in questa direzione.
Infine, anche in questo caso è possibile, a proposito di ODLI 3 , fare un discorso simile a quello fatto nella sezione 3.4.3: anche in questo caso infatti
OQL rappresenta una possibilità di interfacciamento tra utente ed ontologia
che risulta d’altra parte molto più amichevole per un utente umano. D’altra
parte, è importante notare che strumenti automatizzati che utilizzino il linguaggio SQL per interrogare database relazionali potrebbero essere utilizzati
agevolmente, previo “aggiornamento” relativo all’utilizzo di sistemi ad oggetti, per usufruire delle possibilità offerte da una rappresentazione di ontologie
mediante ODLI 3 .
39
Capitolo 4
Sviluppo di primitive per
l’utilizzo di ontologie
Nel proporre le seguenti primitive di interazione per un’ontologia, si è tenuto
conto principalmente dell’analisi effettuata a proposito delle diverse modalità
mediante le quali è possibile interagire con l’ontologia stessa. In particolare,
alcune primitive sono incentrate sulla navigazione strutturale dell’ontologia, altre invece sul reperimento di riferimenti ad istanze dei concetti che
l’ontologia modella.
D’altra parte, è necessario pensare a primitive che permettano di differenziare il punto di partenza della ricerca, vale a dire che diano la possiblità
di effettuare ricerche per concetto, per categoria o per parole chiave.
Infine, come l’analisi effettuata in precedenza ha evidenziato, pare importante offrire diverse possiblità di interazione, in termini essenzialmente di
possibili viste sull’ontologie, a categorie di utenti differenti.
Di quest’ultimo aspetto si discuterà nella sezione 4.4, dopo la presentazione
delle primitive individuate.
4.1
Navigazione strutturale dell’ontologia
Un caratteristica peculiare di un modello ontologico della realtà consiste nella possibilità di ricavarne informazioni sulla struttura del modello stesso.
In particolare, tre sono le possibili tipologie di informazioni strutturali che
pare sensato richiedere all’ontologie, e per le quali si sono pensate alcune
fondamentali primitive di interazione.
40
4.1.1
Percorrere la gerarchia dei concetti
Requisito fondamentale per poter assumere informazioni strutturali da un
modello ontologico è quello di poter percorrere la gerarchia dei concetti rappresentati, ovvero di poter passare da ciascun concetto all’insieme dei concetti che lo specializzano (concetti figli), e che lo sussumono (concetti padri).
Pertanto, si è pensato a due primitive che rendano disponibile tale servizio
agli utenti di un’ontologia.
• generalization-of
Partendo da un concetto, fornisce l’insieme dei concetti che lo sussumono.
Semi-formalmente, di questa primitiva si può dare la seguente rappresentazione:
{ Concept } generalization-of ( Concept )
(4.1)
• specialization-of
Partendo da un concetto, fornisce l’insieme dei concetti che lo specializzano.
Semi-formalmente, abbiamo la seguente primitiva:
{ Concept } specialization-of ( Concept )
(4.2)
Non si è pensato alle due primitive presentate solo a seguito delle considerazioni relative alle diverse modalità di utilizzo di ontologie, ed in particolare
alla modalità legata alla ricerca di informazioni strutturali sul dominio che
l’ontologia modella. Un’altra forte motivazione è quella legata alla necessità di reperire informazioni relative alle istanze dei concetti modellati nell’ontologia. Anche per tale esigenza, risulta indispensabile disporre di uno
strumento che permetta di navigare all’interno della gerarchia dei concetti,
allo scopo ad esempio di cercare riferimenti ad istanze di concetti che specializzano o generalizzano il concetto di partenza. Si pensi per esempio al
caso tassonomico, che di quello ontologico risulta sottoinsieme. Sia data ad
esempio la necessità di reperire riferimenti ad istanze del concetto Felino,
contenuto nell’ontologia. Può darsi il caso che non esistano istanze dirette
di tale concetto, ma che esistano istanze del concetto Gatto o del concetto
Leone, istanze che chiaramente corrispondono ai requisiti della ricerca ed è
necessario poter reperire.
Per un’analisi più dettagliata e formale dell’utilizzo di primitive di questo genere allo scopo di ridefinire l’insieme dei concetti dei quali reperire le
istanze, si veda [19].
41
Volendo dare una rappresentazione più formale delle primitive illustrate in
questa sezione, utilizziamo una notazione funzionale. Sia dunque C l’insieme
dei concetti dell’ontologia. Le due primitive enunciate sono rappresentate
dalle funzioni
generalization-of:
C → 2C
(4.3)
specialization-of:
C → 2C ,
(4.4)
essendo 2C l’insieme potenza di C, ovvero l’insieme di tutti e soli i suoi
possibili sottoinsiemi.
4.1.2
Identificare relazioni tra concetti
Altrettanto importante risulta poter accedere alle informazioni, che l’ontologia racchiude, a proposito delle relazioni esistenti tra concetti diversi. Cosı̀
si è pensato ad una primitiva che, partendo da due concetti, fornisca il tipo
di relazione tra essi esistente (eventualmente un valore nullo, nel caso non
esistano relazioni esplicite, rappresentate cioè all’interno dell’ontologia, tra i
due concetti).
Come fatto in precedenza, diamo una rappresentazione semi-formale di tale
primitiva:
’NULL’ ∪ rel-Type get-relation-between (Concept, Concept) (4.5)
Formalmente, secondo la notazione vista prima,
• get-relation-between:
C × C → RT ∪ φ,
essendo RT l’insieme dei possibili tipi di relazione.
4.1.3
Analisi di un concetto: proprietà, relazioni
Un altro possibile utilizzo del modello ontologico è relativo alla ricerca di
informazioni sui singoli concetti, ovvero sugli attributi da cui tali concetti
sono costituiti. In pratica, si tratta di una modalità di interazione volta alla
ricerca di una sorta di definizione di un concetto attraverso la descrizione
degli attributi che lo costituiscono.
D’altra parte, ottenere informazioni sul nome e sul tipo degli attributi
di un concetto può servire anche come base di partenza per la realizzazione di una strategia di ricerca di particolari istanze di un concetto, le quali
soddisfino determinati criteri. Chiaramente, pensando all’ontologica come al
risultato di un’integrazione di sorgenti di provenienza eterogenea, non si può
42
in generale suppore di conoscere nomi e tipi degli attributi di ogni concetto, per quanto magari a livello concettuale tali attributi siano chiaramente
conosciuti. Dunque anche in quest’ottica risulta importante disporre di una
primitiva d’interazione con il modello ontologico che permetta di ottenere
informazioni sulla struttura interna di ogni concetto, ovvero una primitiva
che, partendo da un concetto, fornisca un insieme di attributi, ciascuno con
il loro tipo.
Semi-formalmente, abbiamo
{ < attr-Name, attr-Type > } attributes-of ( Concept )
(4.6)
È possibile fare un discorso in tutto analogo al precedente a proposito delle
relazioni di un concetto: si può dunque pensare ad una primitiva che, partendo da un concetto, fornisca un insieme di concetti con i quali il concetto
di partenza è in una qualche relazione:
{ < Concept, rel-Type > } relations-of ( Concept )
(4.7)
Secondo la notazione funzionale formale adottata in precedenza, tali primitive si possono denotare come segue:
• attributes-of:
• relations-of:
C → 2N ×AT
C → 2C×RT ,
essendo A l’insieme dei possibili nomi di attributo ed AT l’insieme dei possibili tipi di attributo.
4.2
Ricerca di istanze di concetti
Accanto a quanto visto in precedenza, è naturale pensare a primitive che
permettano il reperimento di particolari istanze di concetti, in corrispondenza
di determinati requisiti, per esempio sui valori di uno o più attributi.
Nel caso più generale, ciò che si desidera è avere la possibilità di ottenere
riferimenti ad istanze di concetti partendo da un insieme di concetti e da una
condizione che coinvolga i valori di attributi di tali concetti. Per esempio, si
possono desiderare le istanze del concetto Gatto europeo per le quali l’attributo colore valga la costante ‘GRIGIO’, e l’attributo lunghezza valga più
di ‘40 cm’.
In generale, ci si riferisce ad una primitiva del tipo
43
{ Instance } search-instances-of ( { Concept }, condition )
(4.8)
dove condition è una espressione booleana ottenuta legando gli attributi
Attri,j dei concetti Conci (a cui si accede con notazione puntata, del tipo
Conci .Attri,j ) mediante i consueti operatori AND, OR, NOT, e mediante parentesi tonde ( e ).
In particolare, si può pensare ad una primitiva specifica per il caso in cui
si desideri ricercare istanze di un solo concetto: è questo infatti, probabilmente, il caso più frequente, e pare dunque sensato prevedere una primitiva
ad esso dedicata. Una tale primitiva è del tipo seguente:
{ Instance } search-instances-of ( Concept, condition )
(4.9)
Un esempio di istanziazione di tale primitiva potrebbe essere
search-instances-of( Gatto europeo, Gatto europeo.colore =
‘GRIGIO’ AND Gatto europeo.lunghezza > ‘40 cm’ )
(4.10)
Uno strumento di interfaccia verso un’ontologia di questo genere, tuttavia,
può essere facilmente visto, invece che come una vera e propria primitiva, come una sorta di primitiva derivata da primitive di base più semplici.
Adottando per esempio primitive di base come
{ Instance } get-instances-of ( Concept )
(4.11)
value get-value-of (Concept, attribute),
(4.12)
e
il cui significato è chiaro alla luce del formalismo sin qui utilizzato, risulta abbastanza semplice realizzare il servizio fornito dalla primitiva indicata sopra.
Quindi non costituirebbe una mancanza, dal punto di vista delle possibilità
offerte dall’ontologia ai suoi utenti, pensare solo alle due primitive cosiddette
di base e realizzare ad un livello superiore la primitiva search-instances-of
() presentata in precedenza. Non esiste a priori una scelta ideale, in proposito. La questione di fondo, come spesso accade in ambito informatico,
consiste nel decidere che genere di soluzione architetturale adottare: se da
44
una parte sarebbe possibile adottare una scelta minimalista e lasciare addirittura all’utente il compito di costruire strumenti di interazione più complessi
a partire da un numero limitato di semplici primitive di base, è anche vero che una scelta diversa, che metta a disposizione primitive più complesse,
permette di offrire all’utente un utilizzo più semplice ed immediato delle funzionalità dell’ontologia, nonchè di rendere accessibili tali funzionalità anche
ad utenti meno esperti dell’ambito ontologico. In questo caso, la nostra scelta
cade su primitive come la (4.8) e la (4.9). Se la seconda rappresenta infatti
il caso particolare della prima di maggior utilizzo, la prima risulta abbastanza espressiva da rappresentare una gamma molto vasta di interrogazioni
dell’ontologia, pur senza giungere all’estremo di costituire una mera ridefinizione sintattica di OQL. Per quanto riguarda i costrutti di OQL ai quali
non risulta possibile accedere mediante una primitiva come la (4.8) (si pensi
alla clausola group by o al costrutto exists), una scelta sensata è quella di
fornire la possibilità ad un utente con esigenze ed esperienza particolari di
sottomettere all’ontologia direttamente una query OQL: a questo scopo, si
immagina di fornire una primitiva speciale, del tipo
{ Instance } evaluate-OQL-query ( OQL query )
(4.13)
Per concludere questa sezione, diamo ora una definizione più formale delle
primitive introdotte, utilizzando la notazione funzionale già vita nelle sezioni
precedenti.
search-instances-of: 2C × CON → 2I
(4.14)
search-instances-of:
C × CON → 2I
(4.15)
Q → 2I ,
(4.16)
evaluate-OQL-query:
dove per CON si intende l’insieme delle condizioni booleane costruite come
detto, per I l’insieme delle istanze di concetti dell’ontologia e per Q l’insieme
di tutte le possibili query OQL.
4.3
Criteri di ricerca
Infine, è necessario pensare a primitive che permettano di ottenere informazioni per mezzo del modello ontologico partendo non solo da specifici concetti,
ma anche da categorie di concetti o ancor più semplicemente da parole
chiave.
45
4.3.1
Ricerca a partire da concetti
Tutte le primitive proposte in precedenza prevedevano che l’utilizzo dell’ontologia partisse da uno (o più) concetti in base ai quali l’utente intendeva
fare una ricerca. Non resta dunque altro da dire a proposito di questa modalità di ricerca, che è stata utilizzata in precedenza come modalità nella
quale presentare le primitive in quanto rappresenta la tipologia di interazione più profondamente legata al fatto di utilizzare un modello ontologico del
dominio sul quale si sta lavorando. Nel seguito, parleremo invece di come
è possibile intendere le altre due modalità di ricerca individuate alla luce
di quanto già illustrato. Chiaramente, sarebbe stato possibile iniziare il discorso presentando primitive operanti in una delle altre modalità, per poi
approfondire il discorso relativo a quella basata su concetti. Tuttavia, come
detto, è sembrato meglio contestualizzare le primitive di interazione descritte
nelle sezioni precedenti nell’ottica della modalità di interazione che pis̀i lega
all’architettura sottostante.
4.3.2
Ricerca a partire da categorie
Per categoria di concetti si intende in generale un insieme di concetti relativi ad uno stesso ambito o contesto, ovvero in pratica una vista sull’insieme
dei concetti che l’ontologia comprende.
In particolare, l’architettura di Artemis prevede un livello di astrazione, detto Subject category Layer, che corrisponde all’esigenza di rappresentare
particolari viste sull’ontologia. In pratica dunque si tratta di ripensare alle
primitive descritte nelle sezioni precedenti alla luce del fatto che i componenti di un’ontologia possono essere tanto Concetti quanto Categorie. Per
esempio, la primitiva 4.1 può essere intesa, semplicemente, come
{ Component } generalization-of ( Component ),
(4.17)
dove Component può, come detto, essere un Concept od una Category.
Secondo la notazione funzionale usata in precedenza,
generalization-of:
0
C 0 → 2C ,
(4.18)
con C 0 = C ∪ CA, e CA insieme delle possibili categorie.
4.3.3
Ricerca a partire da keyword
Diverso è il discorso relativo alla ricerca di informazioni keyword - driven: in questo caso infatti si tratta di partire da un insieme di termini che
46
non corrispondono necessariamente a concetti (con categorie) dell’ontologia,
e di tradurli in termini dell’ontologia mediante le relazioni terminologiche.
A questo punto, si tratta essenzialmente di sfruttare tali relazioni (che, lo
ricordiamo, contribuiscono a dare origine ai Cluster di X-classi cui corrisponderanno poi le X-classi globali) allo scopo di riportarsi in una delle
condizioni di partenza note, ovvero di stabilire a quale concetto, o insieme
di concetti (o di categorie) la ricerca specificata mediante parole chiave si
riferisce.
A questo punto, pare sensato fornire una semplice primitiva che, partendo
da un termine, determini a quale concetto (o categoria) dell’ontologia tale
termine sia più prossimo.
{ Component } component-from ( Term )
(4.19)
In realtà, anche in questo caso vale il discorso fatto nella sezione 4.2 sulla
necessità di effettuare una scelta a proposito della complessità delle primitivi
che si desidera fornire. Infatti, sarebbe possibile pensare a versioni di tutte
le primitive proposte in precedenza che, partendo da un insieme di termini,
si occupi di tradurli in concetti (o categorie) e quindi di effettuare le relative
ricerche. Per esempio, la 4.1 in quest’ottica potrebbe diventare
{ Component } generalization-of-component-from ( { Term } ),
(4.20)
la quale a questo punto potrebbe essere articolata al suo interno come segue:
{
...
Traduzione dell’insieme di termini in un insieme di Componenti
...
Utilizzo di generalization-of (Component) per ogni componente determinato in precedenza
...
}
Appare evidente che un meccanismo di questo tipo rischia di diventare
insostenibilmente complicato nel momento in cui si vogliano contestualizzare
a questa tipologia di utilizzo dell’ontologia primitive più complesse di quella
proposta, come per esempio le (4.11) e (4.12). Sembra dunque sensato pensare semplicemente ad una primitiva come la (4.19), peraltro indispensabile
onde permettere un utilizzo completo ed efficace della (4.13).
Formalmente, l’ultima primitiva presentata diventa
component-from:
essendo T l’insieme dei possibili termini.
47
0
T → 2C ,
(4.21)
4.4
4.4.1
Primitive e categorie di utenti
Personalizzazione delle viste sull’ontologia
Come rilevato in fase di analisi delle modalità di interazione tra utenti ed
ontologia, lo strumento principe presente nell’architettura di Artemisdal
punto di vista della differenziazione degli utenti in diverse categorie è quello
del Subject category layer, dal momento che permette di prendere in
considerazione particolari viste dell’ontologia: in questo modo, è possibile
pensare ad una vista come al modo in cui una determinata categoria di
utenti vede l’insieme dei concetti dell’ontologia, ovvero come il sottoinsieme
dei concetti di suo interesse.
Alla luce di questo fatto, pensare a primitive di interazione che permettano di differenziare l’interazione a seconda della categoria di utenti (ad esempio, utenti molto esperti del dominio ed utenti novizi del dominio) risulta
corrispondere a quanto detto nella sezione 4.3.2 a proposito delle primitive
pensate per rendere possibili la ricerca a partire da Categorie.
Tale discorso tuttavia può essere ampliato prendendo in considerazione il
ruolo degli utenti dell’ontologia nella definizione delle categorie relative ad
una determinata categoria di utenti.
Da una parte, senza dubbio, si pensa a categorie che emergano dal processo di integrazione delle sorgenti collegate all’ontologia, categorie nella cui
definizione può essere chiamato ad intervenire, eventualmente, l’esperto di
dominio che della costruzione dell’ontologia si occupa.
D’altra parte, è abbastanza sensato pensare alla possibilità, per un singolo
utente, di personalizzare il suo modo di interfacciarsi con l’ontologia, nel senso
di definire una o più viste sui concetti del modello ontologico legati alle sue
esigenze ed alla sua esperienza del dominio.
Tuttavia, ritengo che una possibilità di questo tipo costituisca un servizio
riferibile ad un livello superiore a quello delle primitive con le quali l’ontologia
si interfaccia verso i suoi utenti. Ad esempio, si può pensare ad una possibilità
di personalizzazione mediante la creazione di un profilo utente locale, ovvero
che non modifichi la struttura dell’ontologia con l’aggiunta di nuove categorie,
ma debba invece essere utilizzato da un livello intermedio al fine di utilizzare
le primitive dell’ontologia.
In termini di primitive pertanto credo si possa far riferimento semplicemente a quanto riportato nella sezione 4.3.2, tenendo presente il possibile
sviluppo futuro qui discusso.
48
4.4.2
Utente umano ed utente automatico
Le primitive discusse in precedenza si prestano bene ad un utilizzo da parte
di utenti automatici, e senza dubbio meno bene a quello da parte di utenti
umani, fatto salvo il caso di utenti assai esperti del modello ontologico e delle
sue problematiche. Personalmente, sono dell’idea che l’insieme di primitive
proposte possa e forse debba costituire da base per la creazione di un interfaccia rivolta ad utenti umani, che permetta di sfruttarne le potenzialità
senza dover essere esperti del modello ontologico.
In questo senso, d’altra parte, si sono indirizzate anche alcune esperienze
presenti in letteratura, ad esempio quelle illustrate in [9] e [18].
4.5
Conclusioni
Riportiamo di seguito l’insieme delle primitive proposte, sulla scorta delle
discussioni presentate a proposito di alcune scelte di complessità e di livello
di astrazione.
1. generalization-of:
C 0 → 2C
0
2. specialization-of:
C 0 → 2C
0
3. get-relation-between:
C 0 → 2N ×AT
4. attributes-of:
5. relations-of:
C × C 0 → RT ∪ φ
0
C 0 → 2C ×RT
0
6. search-instances-of:
2C × CON → 2I
7. search-instances-of:
C 0 × CON → 2I
8. evaluate-OQL-query:
9. component-from:
Q → 2I
0
T → 2C ,
essendo C 0 = C ∪ CA l’insieme dei possibili concetti e categorie, RT l’insieme
dei possibili tipi di relazione, AT l’insieme dei possibili tipi di attributo, CON
l’insieme delle condizioni booleane su attributi di elementi di C 0 , I l’insieme
delle istanze di elementi di C 0 , Q l’insieme delle possibili query OQL e T
l’insieme dei possibili termini.
49
Interfaccia grafica
(tipo Geometria
ellittica)
Interfaccia per singolo
componente (browsing
e ricerca in base a
valori dei campi)
Interfaccia per
costruire "viste"
(categorie) LOCALI
Interfaccia per la
costruzione di query
OQL
Primitive di
"AGGIORNAMENTO"
"Filtraggio" mediante un PROFILO
LOCALE (categorie locali di concetti)
Gestore dell'ontologia
Amministratore di categoria
"Filtraggio" mediante un PROFILO
GLOBALE (categoria di utenti)
generalization-of
search-instances-of
specialization-of
get-relation-between
attributes-of
get-instances
relations-of
get-value 50
evaluate-OQL-query component-from
Capitolo 5
Modello di ricerca per ontologie
La prima sezione del capitolo propone una semplice architettura generale di
motore di ricerca basato su ontologie, ponendo l’accento sull’identificazione di un modulo dedicato alla ricerca Query - driven, oggetto della nostra
trattazione.
Quindi si contestualizza l’idea di ricerca Query - driven, ed in particolare
l’utilizzo di un linguaggio come OQL, al caso di un motore basato su ontologie. Si indicano quindi i limiti imposti dal modello ontologico sottostante,
e si discute delle caratteristiche di OQL che trovano o meno corrispondenza
nell’architettura di una ontologia. Di seguito, si dà in forma BNF una sintassi
generica di query OQL relativa all’ambito di utilizzo di nostro interesse.
Per completezza, in ogni caso, in appendice si dà una descrizione completa
della sintassi OQL, sempre in forma BNF.
Il passo successivo è quello di discutere una possibile interfaccia (grafica)
per la composizione di Query OQL, partendo dai punti di vista in proposito
presenti in letteratura.
Infine, si illustra il problema della gestione della Query OQL composta
mediante l’interfaccia, ovvero della costruzione di una risposta mediante l’utilizzo delle mapping rules dell’ontologia e la sottomissione di interrogazioni
“locali” alle singole sorgenti integrate dall’ontologia stessa. Per far questo, si
descrive la sintassi generale di una regola di mapping in ODLI 3 , e si propone un formalismo per rappresentare regole di mapping a livello concettuale,
evidenziandone la completezza dal punto di vista delle esigenze di traduzione
delle Query.
51
5.1
Introduzione: un motore di ricerca basato su ontologie
In fase di analisi delle diverse modalità di utilizzo di ontologie, ci si è soffermati su una distinzione basata sul genere di informazioni che si vogliono
reperire, intensionali (strutturali) od estensionali (relative ad istanze), e sul
punto di partenza utilizzato per le ricerche estensionali. Pare dunque sensato
ipotizzare che un motore di ricerca basato sull’utilizzo di ontologie preveda
al suo interno moduli diversi dedicati a svolgere i tre tipi di ricerca che da
quella classificazione emergono.
Vediamo nel dettaglio il funzionamento di tali moduli.
5.1.1
Moduli di navigazione
È il modulo che si occupa di rendere possibile all’utente la navigazione all’interno della struttura dell’ontologia. In particolare, esso deve prevedere
un’interfaccia grafica che permetta di rappresentare in modo semplice ma
completo le diverse entità delle quali l’ontologia è costituita, concetti e relazioni essenzialmente. Inoltre, deve dare la possibilità di spostare il proprio
punto di osservazione da un concetto ad un altro, seguendo le relazioni che
collegano i concetti oppure scegliendo da una lista generale di concetti disponibili. La parte di interfaccia dedicata al singolo concetto deve permettere
di visualizzare l’insieme degli attributi del concetto e delle relazioni che lo
legano ad altri concetti.
5.1.2
Modulo di ricerca Keyword - driven
È il modulo più vicino all’idea tradizionale di motore di ricerca: esso deve
permettere l’inserimento di un insieme di termini (parole) in base ai quali si
desidera effettuare la ricerca di istanze all’interno dell’ontologia. In realtà,
è sensato prevedere la possibilità di effettuare ricerche intensionali (concetti,
attributi) a partire da termini, fornendo cosı̀ l’opportunità di navigare attravero l’ontologia senza in partenza doverne conoscere nulla, se non il dominio
di riferimento.
5.1.3
Modulo di ricerca Query - driven
È il modulo che permette di effettuare le ricerche più complesse ed articolate
sull’insieme delle sorgenti di informazioni che l’ontologia integra.
In generale, esso deve offrire la possibilità di costruire una Query OQL
che descriva, mediante un insieme di condizioni, le caratteristiche desiderate
52
Interfaccia di navigazione
(es: geometria iperbolica)
MODULO di
navigazione
Interfaccia di composizione
di Query
Modulo di ricerca
Query - based
Interfaccia di inserimento
Keyword
MODULO di
ricerca
Keyword - based
Motore di ricerca
basato su
ONTOLOGIE
VISUALIZZAZIONE RISULTATI RICERCHE
Figura 5.1: Architettura di un motore di interrogazione basato su ontologie
53
nell’insieme di istanze restituire dalla ricerca. In particolare, è necessario
che tale possibilità sia offerta in forma grafica, da una parte sfruttando le
funzionalità del modulo di navigazione che permette di conoscere i nomi dei
concetti, delle relazioni, degli attributi, e dall’altra fornendo un’interfaccia di
composizione della query che non richieda di conoscere la sintassi di OQL, ma
solo di organizzare l’insieme di condizioni desiderate in base alle informazioni
rese disponibili dal modulo di navigazione. Un esempio di interfacce di questo
tipo è stato proposto all’interno del progetto Ontobroker (vedi [9], [8]) ed in
altri progetti (vedi [18]), ovviamente in modo diverso.
5.2
OQL per ontologie
Dal punto di vista della realizzazione di una interfaccia per la composizione
di interrogazioni OQL da sottomettere ad una ontologia, è importante effettuare un’analisi preliminare delle varie opportunità che è necessario tenere
in considerazione: se infatti OQL è pensato, in generale, per esprimere interrogazioni anche molto complesse su basi di dati ad oggetti, non è tuttavia
detto che tutte le possibilità che offre risultino interessanti e realizzabili nel
contesto di un sistema di utilizzo di ontologie.
Pertanto, mentre nell’appendice B presentiamo la sintassi completa di una
query OQL generica, in questa sezione concentriamo la nostra attenzione sugli aspetti di OQL che è possibile contemplare e che interessano nell’ambito
ontologico.
5.2.1
Presupposti, possibilità e limiti
Come già notato in fase di analisi delle modalità di impiego di una ontologia, al di là di utilizzi legati alla ricerca di informazioni di tipo strutturale,
l’interazione più tipica di un utente con una ontologia è quella volta a reperire istanze di concetti. In particolare, l’idea di fondo è quella di poter
fissare alcune condizioni alle quali devono sottostare le istanze desiderate per
essere considerate “valide”: in questo modo, all’utente è possibile scegliere
le caratteristiche delle istanze di suo interesse, scartando tutte le altre. Lo
scopo finale, chiaramente, è ottenere un elenco (un insieme) di riferimenti ad
istanze che soddisfano le condizioni imposte.
Chiaramente, tali istanze possono trovarsi in diverse sorgenti tra quelle
che l’ontologia integra: il ruolo essenziale del modello ontologico è dunque
ancora una volta quello di un mediatore che rende trasparente all’utente l’effettiva collocazione delle informazioni di suo interesse. In pratica, l’ontologia
si occupa di sottomettere ad ogni sorgente di partenza un’interrogazione, che
54
contestualizza quella proposta dall’utente nella terminologia specifica della
singola sorgente, senza che l’utente se ne debba preoccupare.
È chiaro pertanto che l’utente che effettua l’interrogazione, pur essendo
eventualmente a conoscenza dell’architettura sottostante il sistema di interrogazione, lavora nell’ottica di chi utilizza un motore di ricerca, o il catalogo di
una biblioteca, o l’indice di un libro. La differenza essenziale sta nel fatto che
l’ontologia permette di fondere, come detto in modo trasparente, sorgenti e
dunque sistemi di indicizzazione delle informazioni differenti ed indipendenti.
L’esigenza principale dunque, come ampiamente discusso a proposito
dell’Utilizzo di ontologie, è quella di scegliere uno o più concetti (o categorie di concetti) dell’ontologia, e di poter fissare particolari relazioni e vincoli
sui valori dei loro attributi e/o delle relazioni tra di essi intercorrenti.
5.2.2
Query OQL ed ontologie
L’insieme di interrogazioni OQL di nostro interesse è costituito dalle possibili istanze del costrutto select che coinvolgono condizioni su attributi di
concetti e relazioni tra concetti.
Pertanto, utilizzando una notazione di tipo BNF, possiamo rappresentare
la sintassi delle interrogazioni di nostro interesse nel modo seguente:
query ::= select attributes_list
from component_name {, component_name}
[ where condition ]
attributes_list ::= attribute {, attribute}
attribute ::= component_name.attribute_name
component_name ::= concept_name
component_name ::= category_name
condition
condition
condition
condition
condition
condition
::=
::=
::=
::=
::=
::=
condition and condition
condition or condition
not condition
( condition )
boolean_constant
term operator term
term ::= attribute
55
term ::= constant_value
constant_value ::= numeric_constant
constant_value ::= boolean_constant
constant_value ::= string_constant
operator
operator
operator
operator
operator
operator
::=
::=
::=
::=
::=
::=
=
!=
>
<
>=
<=
Chiaramente, dal punto di vista della grammatica cosı̀ descritta, concept name,
category name, attribute name, numeric constant, boolean constant,
string constant, =, !=, <, >, <=, >= sono da considerarsi come terminali.
A questo punto, riprendiamo la primitiva che abbiamo introdotto in precedenza in modo da rendere possibile la ricerca di istanze di concetti:
search-instances-of:
0
2C × CON → 2I
(5.1)
o, in notazione meno formale e più vicina all’idea di metodo da invocare
su un’ontologia,
{ Instance } search-instances-of ( { Concept }, condition )
(5.2)
È immediato notare come le possibilità di ricerca offerte da una primitiva di questo genere ricalchino quasi esattamente quelle discusse sopra a
proposito della contestualizzazione di OQL all’ambito ontologico.
Più precisamente, l’unica differenza è relativa alla possibilità o meno di
proiettare i risultati della ricerca su uno o più attributi del concetto (categoria) in questione piuttosto che considerare le istanze nel loro insieme.
D’altra parte, nell’ottica dell’utilizzo di una ontologia come supporto per ricerche web, è lecito pensare che l’esigenza prevalente sia quella di ricondursi
ad istanze dei concetti, ovvero a riferimenti a pagine web collegate ai concetti
in questione.
Cosı̀ non è riduttivo pensare, dal punto di vista della 5.1, che l’effettiva
sintassi di OQL corrispondente non sia esattamente quella proposta, ma sia
invece del tipo
56
query ::= select *
from component_name {, component_name}
[ where condition ]
La versione più completa, a questo punto, ha senso nell’ottica di un utilizzo più generale di quello orientato alla funzione di motore di ricerca. In
questo senso, si può pensare di modificare la primitiva 5.1, oppure di aggiungere all’insieme di primitive proposte una nuova voce che contempli la
possibilità di considerare solo particolari proiezioni delle istanze reperite.
5.3
5.3.1
Interfacce per comporre Query OQL
Casi pratici (in letteratura)
Prima di tutto, è importante ricordare che un’interfaccia grafica che permetta
la composizione di Query OQL non può prescindere da un’interfaccia grafica
che renda possibile la navigazione attraverso i concetti dell’ontologia: infatti,
ricordiamo che per comporre una Query è necessario essere a conoscenza dei
nomi di concetti e categorie, nochè dei nomi degli attributi e delle relazioni
sui quali si vogliono imporre condizioni. È chiaro che un utente, soprattutto
se occasionale, che intenda utilizzare le funzionalità di un motore di interrogazione basato su ontologie non deve essere costretto a conoscere e ricordare
tali informazioni, delle quali ha tuttavia inequivocabilmente bisogno. Per
questo motivo, in letteratura, quando si propone un’interfaccia grafica per
la composizione di interrogazioni, in genere si sviluppa il discorso nell’ottica,
più ampia, di un insieme di interfacce che permettano anche l’accesso alle
informazioni strutturali (intensionali) contenute nell’ontologia.
In particolare, si possono individuare due tipologie fondamentali di interfaccia che renda possibile l’accesso alla struttura di una ontologia.
Intuitivamente, un primo semplice caso è quello in cui i concetti dell’ontologia sono rappresentati, mediante il loro nome, in un albero che rende
evidenti le relazioni di sussunzione tra concetti padre e concetti figli. è il
caso ad esempio di strumenti di costruzione di ontologie come OntoEdit.
Naturalmente, nulla vieta di utilizzare un approccio di questo genere, oltre
che per la modifica e per la realizzazione di ontologie, anche per la semplice visualizzazione del loro contenuto intensionale. Un approccio di questo
genere prevede che, selezionando opportunamente il nome di un concetto,
sia possibile visualizzare l’insieme degli attributi che lo compongono e delle
relazioni che intrattiene (escluse naturalmente quelle di generalizzazione e
specializzazione, esplicite nel diagramma ad albero).
57
D’altra parte, la letteratura in materia propone (si vedano ad esempio le
esperienze illustrate in [9] e [18]) anche l’utilizzo di interfacce grafiche studiate
specificamente per il caso ontologico, ovvero per il caso di un insieme di concetti in mutua relazione. In particolare, la differenza rispetto alla possibilità
descritta in precedenza si riferisce alla visualizzazione della struttura costituita da concetti, mentre non tocca la visualizzazione della “composizione
interna” dei singoli concetti. Si tratta ad esempio di utilizzare un approccio
basato sulla geometria iperbolica (vedi figura 5.2), che permette modificare il
punto di vista, incentrando attenzione e rappresentazione grafica sul concetto selezionato e sui concetti ad esso più strettamente collegati, dando invece
minor risalto a quelli meno affini.
Figura 5.2: Esempio di interfaccia basata su geometria iperbolica
Accanto a queste interfacce di visualizzazione, che come detto risultano
indispensabili anche nell’ottica di formulazione di una Query, proponiamo
ora due esempi, tratti dai casi reali [18] e [9] ricordati in precedenza, relativi
all’interfaccia di composizione vera e propria di un’interrogazione.
L’articolo [18], ad esempio, propone un’interfaccia di navigazione iperbolica come quella descritta in precedenza, alla quale associa, in corrispondenza
della selezione di un nodo (corrispondente ad un concetto), un frame che,
58
oltre ad illustrare le caratteristiche costitutive (attributi, relazioni) del concetto in questione, permette, mediante un insieme di campi, menu a tendina
e check-box, di impostare condizioni di ricerca sui valori di attributi e relazioni (vedi figura 5.3). Il limite di una scelta di questo genere, evidentemente,
è il fatto di ridurre la complessità delle Query cosı̀ realizzabili al caso di
condizioni che coinvolgono valori di un solo concetto.
Figura 5.3: Esempio di frame tratto da [18]
In [9], al contrario, si presenta una soluzione leggermente diversa e più
flessibile, in termini di interrogazioni che è possibile realizzare tramite essa. Infatti in questo caso, accanto alla “solita” interfaccia di navigazione
basata sulla geometria iperbolica, si prevede un modulo per comporre l’interrogazione che non risulta collegato ad un singolo concetto, ma permette di
istanziare più concetti, di fissare condizioni sui valori dei rispettivi attributi,
e di realizzare vincoli di riferimento tra istanze dell’uno ed istanze dell’altro
concetto, mediante variabili associate ai diversi concetti (vedi figura 5.4). In
pratica, il senso di un’interfaccia di questo genere è quello di schematizzare
59
graficamente la scrittura di una interrogazione pensata in termini di clausole
della logica a frame su cui si basa, come linguaggio di rappresentazione ed
interrogazione, il progetto Ontobroker. Tuttavia, la corrispondenza delle variabili associate ai concetti con la possibilità, offerta da OQL, di effettuare
una sorta di join tra concetti diversi, e di esprimere condizioni sugli attributi
di tali concetti, mostra come una soluzione del tipo di quella proposta in [9]
possa essere ritenuta interessante e completa anche dal punto di vista che
interessa a noi, quello della costruzione di Query OQL.
Figura 5.4: Esempio di frame tratto da [9]
In poche parola, utilizzando un parallelo con le interrogazioni in OQL
che per mezzo di esse è possibile costruire, la differenza tra le due proposte
illustrate, e riferite come detto a casi di reale utilizzo di ontologie come base
per la ricerca di informazioni, è quella che c’è tra una Query completa (nel
secondo caso) ed una nella quale la clausola from del costrutto select sia
vincolata a contenere uno ed un solo nome di concetto.
5.3.2
Interfacce per comporre Query e progetto Artemis
Dal punto di vista delle nostre esigenze, ovvero di pensare ad una interfaccia
di composizione di Query OQL da utilizzare nell’ambito del sistema Artemis, è importante ricordare (tabella 5.1) la struttura del frame riferito ad un
singolo concetto.
60
Proprietà
Name
Type
Properties
Kind-of
Subconcept
Association
Weblinks
Descrizione
Nome del concetto c
Concetto locale(X-Class), concetto globale(global X-Class),
Subject Category
Lista delle proprietà del concetto. Obbligatorio per X-Classi ed
X-Classi globali
Nomi dei concetti che sussumono c. Obbligatorio per tutte
le categorie soggetto tranne che per la radice della gerarchia.
Opzionale per X-Classi ed X-Classi globali.
Nomi dei concetti che specializzano c. Obbligatorio per
tutte le categorie soggetto eccetto le foglie. Opzionale per
X-Classi ed X-Classi globali.
Nome dei concetti dell’ontologia legati a c da una
relazione di tipo SYN o RT.
Link web alle sorgenti di dati associate a c. Obbligatorio
per le X-Classi globali. Per categorie soggetto, derivato da quelli
delle X-Classi globali collegate.
Tabella 5.1: Struttura del frame di un concetto in Artemis
Chiaramente, la realizzazione di un’interfaccia che agisca all’interno del
sistema Artemis non può non tenere in considerazione tale rappresentazione
a frame dei concetti dell’ontologia: infatti, tale rappresentazione concettuale
permette da una parte di mettere in evidenza le caratteristiche di un concetto
che l’interfaccia deve poter rappresentare, e dall’altra di sottolineare quali
di queste caratteristiche possono essere utilizzate allo scopo di aggiornare
l’interfaccia in base alle azioni dell’utente (navigazione seguendo i riferimenti
a concetti correlati, ad esempio) o di costruire la risposta all’interrogazione
composta.
Alla luce di quanto detto in precedenza, sia in generale al proposito della
composizione di Query OQL, sia in particolare per quanto riguarda i due casi
reali citati, vediamo ora di discutere gli aspetti concettuali rappresentati dalla
tabella 5.1 nell’ottica della costruzione di un’interfaccia che operi all’interno
del sistema Artemis.
Interfacce e frame concettuale di tabella 5.1
Prima di tutto, si nota che tutte le caratteristiche necessarie alla realizzazione di un’interfaccia per navigare attraverso i concetti dell’ontologia sono
comprese nel frame concettuale presentato, che descrive - indipendentemente
61
dal linguaggio logico nel quale l’ontologia viene effettivamente rappresentata - la struttura e le proprietà di concetti locali, concetti globali e categirie
soggetto.
Infatti, notiamo che tale frame prevede, per ogni concetto (categoria), informazioni relative a
• concetti genitori, per risalire nella gerarchia;
• concetti figli, per scendere nella gerarchia;
• concetti collegati mediante altre relazioni, onde esplicitare situazioni di affinità tra concetti in termini di contesto di riferimento, nonchè
relazioni terminologiche di sinonimia;
• proprietà (attributi) del concetto stesso, onde definirlo precisamente
mediante la descrizione delle sue parti.
Mediante queste caratteristiche, tenendo in considerazione anche le informazioni relative al nome ed alla tipologia dell’unità concettuale (concetto
locale, concetto globale, categoria), è chiaramente rappresentare ogni concetto nella totalità dei suoi aspetti, nonchè spostarsi da un concetto ad un
altro ad esso relazionato. In tal senso, l’idea più semplice di una interfaccia
si costruisce attorno alle caratteristiche rappresentate dal frame concettuale
di tabella 5.1. Si immagina dunque di rappresentare graficamente l’insieme
dei concetti dell’ontologia, collegandoli mediante le informazioni sulle relazioni di sussunzione, di specializzazione e generiche. Quindi, selezionando
un particolare concetto, le informazioni sugli attributi ed un riepilogo delle
relazioni con altri concetti possono essere rapidamente resi disponibili.
Interfaccia per la composizione di Query
A questo punto, possiamo immaginare un’interfaccia che sfrutti queste informazioni per comporre interrogazioni OQL. In particolare, l’idea prospettata
da [18] appare interessante, anche se limitata a interrogazioni sul singolo
concetto, in quanto direttamente realizzabile modificando in modo semplice
ed immediato l’interfaccia di rappresentazione già descritta. D’altra parte, è
vero anche che una ricerca incentrata su di un solo concetto, se non esaurisce
la totalità delle tipologie di interrogazioni immaginabili, costituisce in ogni
caso il caso più frequente ed intuitivo di utilizzo di una ontologia a scopo
di ricerca. Sembra pertanto una buona idea quella di semplificare al massimo tale tipo di interazione tra utente e sistema, integrandone la possibilità
all’interno dell’interfaccia di descrizione del singolo concetto.
62
Per quanto riguarda, infine, la composizione di interrogazioni più complesse, che convolgano più di un concetto, l’interfaccia relativa deve in qualche
modo riferirsi ad una concezione come quella presentata in [9]. Tuttavia, il
limite principale di tale proposta è senza dubbio quello di presentare all’utente un’interfaccia scollegata dalla rappresentazione della struttura dei concetti
dell’ontologia, e degli attributi ditali concetti. Al contrario, sembra sensato
supporre che una composizione tipica di interrogazioni ad una ontologia si
sviluppi a seguito di una navigazione tra concetti e di una presa di visione delle caratteristiche costitutive delle singole unità concettuali. Per questo, l’idea
che intendiamo proporre è quella di integrare il modulo di composizione di
Query OQL complesse all’interno di un’interfaccia più vasta, che permetta di
tenere sotto controllo tanto l’insieme dei concetti e delle reciproche relazioni,
quanto gli attributi dei concetti di volta in volta selezionati. Ad esempio, si
può pensare ad un’interfaccia fondamentalmente basata su una rappresentazione (ad albero, mediante geometria iperbolica, . . . ) dell’ontologia nel suo
complesso, affiancata da una sezione di descrizione del concetto selezionato
e da una per la composizione di Query complesse, quest’ultima del tipo di
quella presentata in figura 5.4. In questo modo, l’utente ha la possibilità di
tenere sotto controllo tutte le informazioni che gli servono, ed eventualmente
di procurarsi le informazioni relative ai nomi di concetti, attributi e relazioni
durante la costruzione della sua interrogazione.
Una soluzione di questo tipo, tuttavia, mantiene un problema evidente
della proposta di [9], quello della realizzazione di join tra concetti diversi mediante variabili impostate dall’utente (Variable1 e Variable2 nell’esempio
mostrato in figura 5.4), aspetto senza dubbio macchinoso per l’utente poco
esperto di ontologie e soprattutto di linguaggi di interrogazione.
In realtà, l’unica possibilità in tal senso potrebbe essere quella di un’interfaccia un po’ più complessa di quelle viste in [18] e [9], costituita da tre
parti fondamentali:
• Sezione di visualizzazione della struttura dei concetti
• Sezione di visualizzazione degli attributi del concetto selezionato
• Sezione in cui selezionare, visualizzare e modificare le caratteristiche
dell’interrogazione
Il significato delle prime due parti è evidente alla luce di quanto detto
fino ad ora.
Questa terza sezione, invece, può essere vista come l’evoluzione del
modulo riportato in figura 5.4: in particolare, essa deve comprendere un elenco di concetti, anche ripetuti, associati automaticamente a
63
variabili diverse (il cui nome, per esempio, può essere costituito da
una variazione di quello del concetto corrispondente e da un numero
progressivo). Tale elenco deve poter essere aggiornato (aggiunta e rimozione di concetti associati a variabili) intervenendo sull’interfaccia
di rappresentazione della gerarchia dei concetti. Accanto a tale elenco, in corrispondenza delle diverse variabili, si deve poter visualizzare
una descrizione del corrispondente concetto (attributi, relazioni); deve essere quindi possibile, all’interno di tale visualizzazione, impostare
condizioni sui valori che i singoli attributi devono assumere. Tali valori
possono essere delle costanti, oppure riferirsi a condizioni di join con
altre variabili (condizioni su relazioni) o con attributi di altre variabili (condizioni su attributi). A tale scopo, l’impostazione dei valori su
attributi e variabili può essere effettuata mediante un campo di testo
(valori costanti) o mediante un menu a tendina (condizioni di join).
Tale menu deve proporre esclusivamente le variabili-istanza, o gli attributi di tali variabili, il cui tipo è compatibile con quello dell’attributo,
o della relazione, sul quale si sta imponendo una condizione.
5.4
5.4.1
Gestione di una Query OQL: costruzione
della risposta
Considerazioni generali
Il primo problema che ci si trova a dover affrontare nell’ambito della costruzione della risposta ad una query sottomessa ad una ontologia, è quello della
differente terminologia utilizzata dall’ontologia stessa rispetto a quella delle
diverse sorgenti che essa integra. Infatti, è evidente che per fornire una risposta all’interrogazione in questione è necessario effettuare una ricerca presso le
diverse sorgenti di informazioni, e che tuttavia tale ricerca non può in generale essere svolta utilizzando la stessa terminologia della query di partenza.
In generale, infatti, i nomi di concetti ed attributi dello schema globale dell’ontologia non corrispondono a quelli degli schemi locali, essendo frutto di
un’integrazione di termini provenienti dalle diverse sorgenti.
Ricordando le opportunità offerte da ODLI 3 per la rappresentazione di
ontologie, è chiaro identificare nelle mapping rules l’aspetto che permette di
ovviare a questo problema. È per mezzo di esse, infatti, che vengono mantenuti riferimenti tra i concetti ontologici relativi ai diversi livelli dell’ontologia, ed in particolare è per mezzo di esse che si può pensare di “tradurre”
la terminologia globale in quelle locali.
In realtà, tale traduzione non costituisce un passo banale all’interno della
64
costruzione della risposta all’interrogazione, ma risulta al contrario influenzata da considerazioni relative tanto alle caratteristiche delle sorgenti di informazione in questione e dell’integrazione effettuata, quanto alla necessità
di pensare a meccanismi e tecniche di ottimizzazione delle interrogazioni da
sottomettere alle singole sorgenti.
Ad esempio, può darsi il caso di una classe globale che derivi da classi
locali che presentano attributi diversi: in particolare, se un attributo globale
coinvolto nella query non corrisponde ad alcun attributo di una delle particolari classi locali relative, si ha il primo caso critico per quanto riguarda la
traduzione dell’interrogazione stessa. Si parla in questo caso di attributo
non verificabile, e ci si trova di fronte ad una scelta: sottomettere la query
alla sorgente cui appartiene la classe con l’attributo non verificabile, ignorando le condizioni su tale attributo, col rischio di restituire informazioni errate,
oppure non farlo, col rischio di tralasciare informazioni corrette. L’altro evidente problema è quello dell’utilità o meno di alcune sorgenti locali rispetto
alla ricerca: se infatti le regole di mapping fissano che un particolare attributo locale può assumere un solo valore, e tale valore rende identicamente falsa
la condizione della query, è chiaro come sia sensato evitare di coinvolgere
la sorgente cui tale attributo si riferisce nel meccanismo di costruzione della
risposta alla query. In tal caso, si tratta essenzialmente di una questione di
ottimizzazione.
In ogni caso, le regole di mapping espresse mediante ODLI 3 rendono
possibile tenere in considerazione tali casi, senza dubbio critici, a proposito
della traduzione delle interrogazioni. Qualora non si verifichi nessuno dei due
casi precedentemente ricordati, è necessario utilizzare le informazioni fornite
dalle mapping rules per procedere ad una corretta contestualizzazione delle
interrogazioni globali nell’ottica delle differenti terminologie locali.
Diamo ora di seguito una definizione generale della sintassi delle mapping
rules prevista da ODLI , per poi discutere più dettagliatamente della casistica
dei problemi di traduzione.
5.4.2
Mapping rules in ODLI 3
attr_dcl
::= [readonly] attribute domain_type attribute_name [*]
[fixed_array_size] [mapping_rule_dcl]
mapping_rule_dcl::= mapping_rule rule_list
rule_ list
::= rule
| rule, rule_list
rule
::= local_attr_name
| identifier
65
| and_expression
| union_expression
and_expression ::= (local_attr_name and and_list)
and_list
::= local_attr_name
| local_attr_name and and_list
union_expression::= (local_attr_name union union_list on identifier)
union_list
::= local_attr_name
| local_attr_name union union_list
local_attr_name ::= source_name.class_name.attribute_name
Presentiamo ora un esempio di utilizzo di questo costrutto all’interno
della definizione di una classe ODLI 3 :
interface FoodPlace
{
attribute name
mapping rule
ED.FastFood.name,
FD.Restaurant.name,
FD.Brasserie.name;
attribute category
mapping rule
ED.FastFood.category,
ED.Restaurant.category,
FD.Bistro.type;
attribute zone
mapping rule
ED.FastFood = "Pacific Coast",
FD.Restaurant = "Atlantic Coast",
FD.Bistro = "Atlantic Coast",
FD.Brasserie = "Atlantic Coast";
}
Chiaramente, si tratta di una rappresentazione mediante un particolare
linguaggio logico di un insieme di connessioni tra le entità dell’ontologia del
quale è ovviamente possibile immaginare una rappresentazione concettuale, la quale cioè sia indipendente dal particolare linguaggio utilizzato per
rappresentare l’ontologia a livello logico.
Nella sezione seguente verraà proposto un semplice formalismo concettuale in grado di rappresentare informazioni di questo genere astraendole dalla specificità del linguaggio logico mediante il quale l’ontologia viene
effettivamente rappresentata.
66
5.4.3
Sviluppo di un formalismo concettuale per mapping rules
Essenzialmente, si tratta di rappresentare, in pratica, quello che graficamente
può essere visto come il contenuto di una tabella la 5.2.
FoodPlace
ED.FastFood
FD.Restaurant
FD.Bistro
FD.Brasserie
name
name
name
null
name
category
category
category
type
null
zone
‘Pacific Coast’
‘Atlantic Coast’
‘Atlantic Coast’
‘Atlantic Coast’
Tabella 5.2: Esempio di tabella di mapping
Rifacendoci all’esperienza ed all’esempio di X-Formalism esteso, che definisce le entità dell’ontologia in termini di n-uple, possiamo pensare ad una
concettualizzazione delle regole di mapping come quella che segue:
Una regola di mapping (mapping rule) è una coppia della forma:
global-class-name
class-mapping-rule
: GCN
: {attribute-mapping-rule}
attribute-mapping-rule
local-class-name,
local-attribute-name>}
= {<global-attribute-name,
dove local-attribute-name può a sua volta essere
• Un singolo attributo locale (mapping diretto di un attributo globale su
di un attributo locale)
• Un valore costante (mapping di un attributo locale su di un valore
costante per la classe locale local-class-name)
• Una concatenazione di attributi locali del tipo (local-attr 1 ,local-attr2 ,
...,local-attrN ) (mapping in and)
• Un’alternativa di attributi locali del tipo (local-attr 1 |local-attr2 |
...|local-attrN ) (mapping in union)
• Un valore nullo (null), in corrispondenza di classi locali local-class-name
mappate sulla classe globale GCN che non possiedono attributi su cui si
mappi l’attributo globale global-attribute-name
67
Naturalmente, ogni terna <global-attribute-name, local-class-name,
local-attribute-name> è individuata univocamente dalla coppia dei primi
due elementi (ovvero, per ogni attributo locale il mapping su di una classe
locale è unico). D’altra parte, data una classe globale GCN, per ogni attributo
globale global-attribute-name in essa compreso e per ogni classe locale local-class-name dalla quale GCN deriva, esiste una terna attributemapping-rule individuata dalla coppia <global-attribute-name, localclass-name>
Discutiamo ora il significato delle diverse caratteristiche concettuali di
una regola di mapping, allo scopo di verificarne la completezza e l’esaustività
dal punto di vista della “traduzione” di Query sull’ontologia in Query locali
alle sorgenti di dati. Per far questo, consideriamo le diverse tipologie di
attributo globale che è possibile avere, dal punto di vista della mappatura su
attributi di classi locali:
• Attributi globali mappati direttamente su attributi locali
Si tratta di attributi globali in corrispondenza biunivoca con un particolare attributo di una classe locale. In questo caso, la traduzione della
Query globale in Query locale per la sorgente in questione è molto semplice, e prevede la semplice sostituzione del nome di attributo globale
con il nome dell’attributo locale ed ovviamente quella del nome della
classe locale con quello della classe locale.
Ad esempio, è il caso dell’attributo globale name mappato direttamente
sull’attributo locale ED.FastFood.name.
In questo caso, una Query come
select name
from FoodPlace
diventa
select name
from FastFood
• Attributi globali mappati mediante corrispondenza in and
In questo caso, gli attributi globali in questione sono ottenuti dal concatenamento degli attributi locali in and fra loro. La traduzione del
nome degli attributi, dunque, consiste nella sostituzione del nome dell’attributo globale con i nomi di tutti gli attributi locali su cui si mappa,
68
contestualmente alla clausola della Query nella quale l’attributo globale
compare.
Pertanto, dato il caso di mapping
interface Person
{
attribute name
mapping rule
S1.Persona.nome,
(S2.Mensch.Vorname and S2.Mensch.Familienname);
}
una Query come
select name
from Person
viene tradotta, per la sorgente S2, come segue:
select Vorname, Familienname
from Mensch
Ancora, una Query in cui l’attributo mappato in and compaia nella clusola where dell’interrogazione, viene mappata tenendo conto del diverso
ruolo dell’attributo in questione. Pertanto
select *
from Person
where name = ’Pietro Martinelli’
diventa per la sorgente S2
select *
from Mensch
where Vorname = ’Pietro’ and Familienname = ’Martinelli’
69
• Attributi globali mappati mediante corrispondenza in union
Si tratta di attributi globali il cui mapping sugli attributi locali di una
determinata classe dipende dal valore di un terzo parametro, indicato
in genere come tag attribute. In tal senso, è necessario sia definita una
regola che definisca come effettuare il mapping. Vediamo ad esempio il
caso seguente:
interface Car
{
attribute country
mapping rule
S.Auto.paese,
attribute price
mapping rule
(S.Auto.prezzo_italiano union S-Auto.prezzo_inglese on Regola1);
}
rule Regola1
{
case of S.car.paese:
’Italia’
: S.car.prezzo_italiano;
’Inghilterra’ : S.car.prezzo_inglese;
}
Immaginando di avere la Query globale
select price
from Car
la traduzione genera due interrogazioni distinte, e più precisamente
select prezzo_italiano
from Auto
where paese = ’Italia’
e
70
select prezzo_inglese
from Auto
where paese = ’Inghilterra’
• Attributi globali mappati su valori costanti
Questo è, infine, il caso in cui un attributo globale sia mappato su una
costante di una classe locale (si veda, per esempio, il caso dell’attributo zone della classe globale FoodPlace presentato in precedenza).
Informazioni di questo tipo coinvolgono, più che l’aspetto della pura
traduzione dell’interrogazione, quello dell’ottimizzazione della Query,
già indicato in precedenza.
Cosı̀ ad esempio una Query come
select *
from FoodPlace
where zone = ’Pacific Coast’
non darà origine ad alcuna interrogazione alla sorgente FD, mentre sarà
tradotta nella Queri banale
select *
from FastFood
per quanto riguarda la sorgente ED, con evidenti vantaggi intermini di
risparmio di tempo di ricerca su entrambe le sorgenti (nel secondo caso,
in quanto permette di non dover verificare una condizione che si sa per
ipotesi essere sempre verificata per le istanze della classe FastFood).
Abbiamo dunque illustrato, mediante alcuni semplici esempi basati sulla rappresentazione delle mapping rules in ODLI 3 , le diverse possibilità che
possono aversi quando si deve convertire una interrogazione globale in interrogazioni a sorgenti locali. Tali esempi esauriscono evidentemente tutte le
eventualità che è necessario tenere in considerazione affrontando il problema.
Pertanto, un formalismo come quello presentato a pagina 67 rappresenta a livello concettuale, in modo esauriente, tutti i diversi casi di mapping
di nostro interesse.
71
Capitolo 6
Progetto e implementazione di
interrogazioni in ARTEMIS
6.1
Introduzione
Come detto nella sezione 5.4, ogni query è espressa dall’utente in termini di
concetti dell’ontologia. Il problema che qui ci si pone è quello di riformulare
la query originale come un set di query da sottoporre alle sorgenti associate
all’ontologia. In particolare, la riformulazione di interrogazioni poste sui concetti dell’ontologia, in interrogazioni valutabili dalle singole sorgenti locali,
richiede un processo di traduzione che coinvolge meccanismi di mapping tra
i diversi livelli in cui l’ontologia è organizzata .
L’insieme delle risposte ottenute dalle interrogazioni poste sulle singole
sorgenti andrà combinato e riconciliato per fornire un risultato omogeneo
quale risposta alla query originale.
Tuttavia, in questo lavoro limitiamo il nostro interesse al solo processo di
riformulazione della query.
Illustriamo dunque nel dettaglio i concetti che è necessario considerare
in questo problema, per poi chiarire gli aspetti algoritmici.
6.2
6.2.1
Analisi e descrizione dei concetti rilevanti
Inquadramento nell’architettura di Artemis
Diamo ora una breve presentazione dell’architettura di Artemis, in modo
da illustrare a grandi linee il contesto entro il quale i nostri moduli software
andranno ad operare. In particolare, descriviamo le funzionalità realizzate
72
dai diversi moduli esistenti, allo scopo di definire e precisare i requisiti ai
quali dovranno rispondere quelli che andremo a progettare e realizzare.
Il sistema Artemis, allo stato attuale, si occupa dell’intera processo di
integrazione che, partendo da sorgenti eterogenee e distribuite d’informazioni
relative ad uno stesso dominio, giunge sino alla costruzione di un’ontologia
che modelli tale dominio.
Tale processo si realizza mediante una successione di diverse fasi, logicamente concatenate, che descriviamo brevemente di seguito:
1. Prefase di Wrapping, che permette di passare da una descrizione estensionale delle sorgenti da integrare realizzata mediante XML-Schema o
RDF ad una rappresentazione delle sorgenti in termini di X-Class (vedi
2.5) e quindi di schemi ODLI 3 (vedi 2.6).
2. Fase di valutazione di affinità: Artemisvaluta l’affinità tra tutte le
possibili coppie di classi, mediante un’analisi dell’affinità di nome e
dell’affinità strutturale, e una successiva determinazione di un’affinità
globale, ottenuta come media pesata delle precedenti.
3. Fase di Clustering: in base ai risultati della valutazione di affinità ed
alla scelta di una soglia di affinità, le classi locali vengono raggruppate
in cluster. Ogni cluster rappresenta un insiemi di due o più classi affini.
4. Fase di Unificazione: da ogni cluster viene ottenuta una sola classe
globale, che rappresenta il risultato dell’integrazioni delle classi locali
associate al cluster in questione. Si ottiene in questo modo la cosiddetta
vista integrata, ovvero un insieme di classi globali e di corrispondenze
tra classi globali e classi locali.
5. Fase di wrapping ODLI 3 - X-Formalism: la descrizione delle classi globali ottenute dalla fase precedente viene tradotta nel linguaggio concettuale X-Formalism.
6. Fase di generazione dell’ontologia di dominio: partendo dalle X-Class
globali fornite dalla fase precedente, un apposito modulo ricava un’ontologia di dominio, costruendo un insieme di concetti, e di relazioni tra
concetti, sia partendo da eventuali relazioni esplicite sia inferendone di
nuove in base alla struttura dei concetti.
A questo punto, la necessità che ci si trova ad affrontare è quella di rendere
possibile l’utilizzo dell’ontologia ottenuta allo scopo di ottenere informazioni.
Da una parte, dunque, è necessario disporre di un sistema di composizione
di interrogazioni sull’ontologia; dall’altra, si rende indispensabile realizzare
73
un meccanismo che, sfruttando le informazioni prodotte durante le fasi di
integrazione e di generazione dell’ontologia, permetta di ricondurre l’interrogazione sull’ontologia ad un insieme di interrogazioni sulle sorgenti locali
di partenza. A queste esigenze rispondono i moduli software progettati e
realizzati nell’ambito di questa tesi, di cui daremo conto nelle sezioni che seguono, e che presentiamo nella figura 6.1 inseriti nell’architettura complessiva
di Artemis.
Figura 6.1: Architettura di Artemis: in verde i moduli realizzati nell’ambito
di questa tesi
6.2.2
Concetti associati ad un’interrogazione
Query Una generica Query che consideriamo, ed in particolare una Query sull’ontologia, comprende le possibili forme di interrogazioni OQL che si
manifestano nel processo di traduzione. In particolare, un Query può essere
caratterizzata come una coppia <variabili, condizione>, dove variabili
74
è l’insieme delle variabili coinvolte nell’interrogazione e condizione è la
condizione espressa dalla clausola where dell’interrogazione OQL.
Local Query Una Local Query è la specializzazione di una generica Query
contestualizzata ad una sorgente locale. Pertanto, oltre alla struttura di una
Query, essa comprende, in particolare, informazioni di corrispondenza tra la
query posta sull’ontologia e la query locale vera e propria. Le informazioni
di corrispondenza determinano come i termini della query locale (i nomi di
interfacce ed i nomi di attributo, o le costanti) sono associati ai termini della
query originale (ad esempio, quale associazione attributo globale - attributo
locale sono verificate nel contesto della particolare query locale considerata).
Variable In una qualsiasi query SQL è possibile associare variabili alle relazioni coinvolte nella clausola from della query, per poi utilizzare tali variabili
nelle altre clausole della query stessa. Analogamente, in una query OQL
posta sull’ontologia, è consentito l’uso di variabili associate a concetti.
Una Variable modella una variabile in una query ed è caratterizzata da
una coppia <nome variabile, tipo variabile>. Nel caso di una interrogazione su ontologia il tipo variabile è il nome del concetto del quale la
variabile nome variabile è istanza.
Condition Una Condition corrisponde alla condizione booleana che è
possibile esprimere nella clausola where di un’interrogazione OQL.
6.2.3
Tipologie di mapping tra livelli diversi: utilizzo
e rappresentazione
Prima di tutto va ricordato che, nell’architettura di ontologia considerata
(vedi figura 6.2), esistono diverse tipologie di mapping, ovvero
M1 Mapping tra concetti dell’ontologia ed X-Class globali
M2 Mapping tra X-Class globali e schema integrato
M3 Mapping tra schema integrato e schemi locali
M4 Mapping complessivo tra concetti dell’ontologia e schemi locali
In particolare, è chiaro come ai fini della traduzione di query il mapping di
maggiore interesse sia l’ultimo, che altro non è che la composizione di quelli
precedenti, che fornisce la corrispondenza tra gli elementi del livello più alto
quelli del livello più basso dell’ontologia.
75
Vediamo ora, in breve, le altre tipologie di mapping, illustrando dal punto
di vista concettuale come entità di un certo livello si mappino in entità di
livello più basso.
Mapping tra concetti dell’ontologia ed X-Classi globali Sussistono tre diversi casi nel mapping di concetti dell’ontologia su X-Class globali
(si veda [3]):
• Corrispondenza uno a uno tra concetto ed X-Class (fig. 6.2, caso
M1.A)
• Corrispondenza uno a molti tra concetto ed X-Class (fig. 6.2, caso
M1.C): è il caso di X-Class diverse che rappresentano uno stesso concet-
(Concetti)
(M1.A)
(M1.B)
(M1.C)
(M1)
(X-Class globali)
(M2.A)
(M2)
(M2.B)
(Interfacce globali)
(M3)
(Interfacce locali)
(Sorgente 1)
(Sorgente 2)
(Sorgente 3)
Figura 6.2: Tipologie di mapping tra livelli dell’ontologia
76
to. Ad esempio, due X-Class come IndirizzoCasa ed IndirizzoNegozio,
rappresentando entrambe un indirizzo, possono dar vita ad un unico
concetto Indirizzo.
• Corrispondenza molti a uno tra concetto ed X-Class (fig. 6.2, caso
M1.B): è il caso di X-Class il cui tipo complesso contenga costrutti di
choice. Ogni possibilità di scelta nell’espressione choice dà origine ad
un concetto diverso.
Nel primo dei tre casi, la traduzione di un’interrogazione sull’ontologia in una
corrispondente interrogazione su X-Class è banale, e comporta semplicemente
la sostituzione del nome del concetto con quello della X-Class da cui tale
concetto deriva. Le proprietà del concetto corrispondono a quelle della XClass, e non è pertanto necessario alcun intervento di traduzione dei loro
nomi.
Nel secondo caso, il nome del concetto è associato ai nomi di n X-Class
diverse. Un’interrogazione posta sul concetto sarà tradotta nell’unione (costrutto union di OQL) di n interrogazioni sulle diverse X-Class da cui il concetto deriva (ad esempio, select * from Indirizzo verrà riformulata come
select * from Indirizzocasa union select * from IndirizzoNegozio).
Infine, il terzo caso viene trattato in modo simile al primo, dal momento che ad ogni concetto corrisponde una ed una sola X-Class globale, e la
sostituzione risulta pertanto univoca.
Mapping tra X-Class e schema integrato Normalmente, una XClass globale è associata ad una ed una sola interface dello schema integrato. In questo caso, il nome della X-Class e dell’interface coincidono, i
nomi delle rispettive proprietà anche, ed i tipi delle proprietà della X-Class
sono derivati da quelli delle proprietà dell’interface dal Wrapper “ODL I 3
to X-Formalism” mediante gli algoritmi descritti in [12].
Un’eccezione a questa regola si verifica qualora una interface dello schema integrato sia definita, per quanto riguarda la sua struttura, da un’alternativa tra diversi (ad esempio N + 1) corpi mediante il costrutto union di
ODLI 3 . In questo caso, all’interface in questione corrispondono N + 2
X-Class, una rappresentativa di ogni corpo dell’alternativa ed una per rappresentare l’alternativa stessa (come illustrato in [12]). In questo caso, la
denominazione delle X-Class segue una regola precisa: l’interface
interface nomeInterfaccia
(...)
{...}
union nomeUnion1
77
{...}
union nomeUnion2
{...}
...
union nomeUnionN
{...}
dà origine ad una classe con nome nomeInterfaccia e tipo nomeInterfacciaType, N X-Class ognuna con nome nomeInterfaccia@nomeUnionI e tipo nomeInterfaccia@nomeUnionI Type, dove I è l’indice del corpo I-esimo,
e ad una interfaccia con nome nomeInterfacciaOR e tipo {nomeInterfacciaORType,[nomeInterfaccia, nome Interfaccia@nomeUnion1, ...,
nomeInterfaccia@nomeUnionN]}.
Anche in questo caso le proprietà delle X-Class sono omonime a quelle
dell’interface, mentre i tipi sono derivati secondo gli algoritmi descritti in
[12].
Operativamente, nella riformulazione di query, la corrispondenza tra XClass e schema integrato è ottenuta facendo riferimento alle regole di denominazione descritte, che permettono di associare l’X-Class alla propria
interface.
Mapping tra schema integrato e schema locale Questa tipologia
di mapping, infine, è già ampiamente discussa in ??.
Risulta evidente come, da un punto di vista concettuale, non vi sia differenza, in termini di rappresentazione, tra questo genere di mapping e quello
di nostro interesse, indicato al punto M4. In entrambi i casi, infatti, si tratta
di mappare attributi di classi globali (siano esse concetti o interface globali
dello schema integrato) su attributi di interface locali.
In particolare, come già mostrato, si può pensare di rappresentare le
regole che descrivono mapping come quelli ai punti M3 e M4 mediante una
tabella come la 5.2. Per ogni classe di alto livello è dunque data una tabella,
sulle cui colonne troviamo gli attributi della classe in questione e sulle cui
righe troviamo la coppia <sorgente, interfaccia locale>. Ogni cella
della tabella, contiene la descrizione del mapping di un attributo della classe
per i dati sorgente ed interface locale. Una regola di mapping, come si è
proposto in 5.4.3, è una coppia
global class name
class mapping rule
: GCN
: {attribute mapping rule}
78
dove
attribute mapping rule
local class name,
local attribute name>}
= {<global attribute name,
Con riferimento alla rappresentazione tabellare appena descritta, il global
class name individua la tabella, il global attribute name individua la colonna, il local class name individua la riga (essendo costituito da due parti, sorgente e nome interfaccia locale), il corrispondente local attribute name infine è associato alla cella della tabella, e può assumere le forme
descritte in 5.4.3.
6.3
6.3.1
Progetto delle classi
Classi che modellano un’interrogazione
Nella sezione 6.2.2 sono stati presentati i concetti principali associati ad una
interrogazione. In particolare, sono stati introdotti i concetti di Query, Local
Query, Variable e Condition. Modellare i primi tre mediante semplici strutture dati risulta immediato. Dal punto di vista della rappresentazione di una
Condition tramite strutture dati, tale concetto non corrisponde ad un’unica struttura dati, ma viene più naturalmente illustrato definendo diverse
tipologie di condizione. Di conseguenza, dal punto di vista implementativo,
sembra opportuno modellare una Condition, più che con una classe, con
una interfaccia, che caratterizzi il comportamento di una classe che intenda
rappresentare un particolare tipo di Condition. Si tenga inoltre presente
che, usualmente, è possibile rappresentare un’espressione di qualunque genere (espressione algebrica, espressione booleana, statement di un linguaggio di
programmazione,. . . ) mediante un albero binario (o binarizzabile). Definiamo prima di tutto le tipologie di nodi dell’albero necessario per rappresentare
una qualunque Condition.
79
<<Interface>>
<<Interface>>
Copyable
Condition
+getCopy(): Copyable
+stampa(out: DataOutputStream): void
left
SimpleCondition
-variabili: SearchableVector
-condizione: Condition
ComplexCondition
-operator: String
-booleanOperator: int
-leftOperand: Operand
-left: Condition
-rightOperand: Operand
rightOperand
-right: Condition
<<Interface>>
+getConceptOfVariabe(var: String): String
Translatable
leftOperand
1..*
<<Interface>>
Operand
Variable
+traduciPer(sorgente: Source, mapTab: ConceptToLocalMappingTable): Translatable
Constant
-valore: String
BooleanConstant
+toString(): String
-nome: String
80
Figura 6.3: Classi che modellano la Query
Query
right
-tipo: String
Literal
Source
LocalQuery
-tradotto: boolean
-interrogazioni: Vector
-tabella: TraductionChoiceTable
+getTraductionChoiceTable(): TraductionChoiceTable
1..*
-variabile: String
-attributo: String
-nome: String
-variabile: String
+translating: int
+addTraductionChoiceItem(): TraductionChoiceItem
+creaTraduzione(mapTab: ConceptToLocalMappingTable): void
+LocalQuery(query: Query): LocalQuery
+getTranslatingQuery(): LocalQuery
-attributi: Vector
+addLocalQuery(query: LocalQuery): void
<<Interface>>
SearchableVector
NewComparable
-current: int
+compareTo(toCompare: Object, mode: int): int
-currentMode: int
+getConceptOfVariable(var: String): String
1..*
TraductionChoiceTable
LiteralConcatenation
-daCercare: NewComparable
+search(toSearch: NewComparable, mode: int): NewComparable
+getNext(): NewComparable
+searchVector(toSearch: NewComparable, mode: int): SearchableVector
ComplexCondition Una ComplexCondition concettualizza la parte
ricorsiva della grammatica che, come visto in ??, descrive in generale una
clausola where di una interrogazione. In particolare, essa corrisponde ad
un operatore booleano (AND, OR o NOT) applicato ad uno (nel caso OR)
oppure a due operandi, che sono a loro volta Condition. Dunque una
ComplexCondition è modellabile come una terna <booleanOperator, left,
right>, dove booleanOperator è il tipo di operatore che il nodo rappresenta, e left e right sono le due sotto-condizioni collegate dall’operatore in
questione (chiaramente, nel caso NOT una delle due perde significato).
SimpleCondition Una SimpleCondition, al contrario, concettualizza
la parte non ricorsiva della definizione di una condizione: essa rappresenta infatti una foglia dell’albero che modella la condizione, cioè un’espressione booleana semplice, tipo var1.x > 2 o var2.y != var3.x. Pertanto,
una SimpleCondition può essere modellata come una terna <operatore,
leftOperand, rightOperand>, dove operatore è l’operatore della condizione atomica e leftOperand e rightOperand sono gli operandi (vedi 6.3.1)
che tale operatore confronta.
BooleanConstant Una Boolean Constant modella il caso banale di
condizione booleana, quello costituito semplicemente da una costante booleana. Essa dunque può essere rappresentata, semplicemente, come un valore.
Operand
Un Operand modella un qualunque operando di una condizione atomica di
una interrogazione. Anche in questo caso, più che rappresentare una struttura comune a tutti i tipi di operando, un Operand descrive una caratteristica
(l’essere un operando) comune a concetti diversi, e può pertanto essere in
modo più naturale modellata come interfaccia più che come classe. Classi
che implementano tale interfaccia modellano le diverse possibilità cui ci si
trova di fronte analizzando un operando di una condizione atomica.
Constant Una Constant rappresenta la tipologia degli operandi costanti (costanti numeriche, alfanumeriche o booleane). Si può dunque modellare, semplicemente, come una stringa di caratteri contenente il valore della costante. Il caso particolare Boolean Constant, come discusso in 6.3.1,
rappresenta anche un caso banale di Condition.
81
Identifier Un Identifier rappresenta un attributo di una variabile che funge da operando. Può pertanto essere modellato da una coppia
<variabile, attributo>. Inoltre, nell’ottica di nostro interesse, quella cioè
della traduzione di Query in LocalQuery, è utile associare ad un Identifier
un flag booleano che indichi se tale Identifier, all’interno di una certa
SimpleCondition della Local Query, sia già stato tradotto o meno.
IdentifierConcatenation Una IdentifierConcatenation rappresenta un tipo particolare di operatore, quello risultante da un’espressione costituita dalla concatenazione di attributi di una certa variabile, ed è dunque rappresentabile mediante una coppia <variabile, attributi>, dove
variabile è il nome della variabile in questione ed attributi l’insieme degli attributi concatenati. In particolare, l’utilità di modellare tale tipologia
di operando emerge in fase di traduzione della query in query locali, come
si vedrà analizzando il modo di elaborare le diverse tipologie di regole di
mapping.
6.3.2
Classi che definiscono l’ontologia
Ontology
Una Ontology è il concetto che rappresenta l’ontologia nel suo insieme, ed
è dunque, essenzialmente, un insieme di concetti e di relazioni tra concetti.
In particolare, essa viene modellata come un insieme di concetti, nella cui
definizione sono riportate le informazioni sulle relazioni con altri concetti.
Oltre a questo, è necessario modellare i tipi di attributo utilizzati per
definire le componenti dei concetti. Vediamo, di seguito, le classi utilizzate
per modellare i diversi aspetti dell’ontologia.
GenericTypeDefinition
Questa classe rappresenta gli elementi comuni ad una generica definizione
di tipo, sia essa un tipo di attributo o un concetto.
In particolare, una GenericTypeDefinition è costituita da un nome, da
un vettore equivalenteA di nomi di GenericTypeDefinition equivalenti e
da un vettore disgiuntoDa di GenericTypeDefinition disgiunte da quella
in questione.
82
GenericTypeDefinition
-equivalenteA: Vector
-disgiuntoDa: Vector
GeneralElement
StructType
AttributeType
-attributi: SearchableVector
-sinonimi: SearchableVector
83
Figura 6.4: Classi che modellano le entità dell’ontologia
-nome: String
ComplexType
-tipoBase: Attribute
Concept
-genitori: SearchableVector
-figli: SearchableVector
Attribute
-attributi: SearchableVector
1..*
-toXClass: Vector
-tipo: AttributeType
-cardinalita: String
-specifica: String
ListType
RangeType
-lowerBound: int
-upperBound: int
1..*
-lowerBoundInf: Boolean
-upperBoundInf: Boolean
Ontology
-concetti: SearchableVector
-tipi: SearchableVector
EnumType
-item: Vector
GeneralElement
La classe GeneralElement estende la GenericTypeDefinition e concettualizza l’aspetto comune a concetti ed attributi. In particolare, tale aspetto
è costituito dall’insieme sinonimi dei sinonimi del GeneralElement in questione e dai metodi dedicati al trattamento (aggiunta di un elemento, lettura
dell’insieme di sinonimi) di tale insieme di sinonimi.
Concept
La classe Concept estende la GenericElement e modella un concetto dell’ontologia. Sue caratteristiche peculiari, oltre a quelle già discusse per la classe
GeneralElement, sono:
• genitori, insieme dei concetti che sussumono il concetto in questione
• figli, insieme di concetti che specializzano il concetto in questione
• attributi, insieme degli attributi del concetto in questione
• to X Class, insieme di riferimenti alla X-Classi dalle quali il concetto
in questione deriva
Attribute
Un Attribute concettualizza un attributo di un concetto dell’ontologia. In
particolare, oltre a quanto ereditato da GeneralElement, gli elementi che
costituiscono un Attribute sono:
• tipo, che rappresenta il tipo dell’attributo in questione
• cardinalità, che rappresenta la cardinalità dell’attributo in questione
• specifica, che rappresenta la specifica dell’attributo in questione, è
un aspetto della definizione di tipo di attributo in X-Formalism
AttributeType
Un AttributeType rappresenta un generico tipo di attributo. Questa classe
estende la classe GenericTypeDefinition. Non presenta nuovi attributi nè
nuovi metodi, dal momento che il fatto stesso di essere un AttributeTye
caratterizza in modo esauriente il sottoinsieme di GenericTypeDefinition
di nostro interesse.
84
ComplexType
Questa classe estende la classe AttributeType e rappresenta i tipi di attributo non primitivi, ovvero costruiti a partire da un tipo base. Il riferimento al tipo base sul quale viene costruito il tipo complesso in questione è
rappresentato dall’attributo tipoBase.
ListType
La classe ListType estende la classe ComplexType allo scopo di rappresentare un tipo complesso ottenuto mediante il costrutto list di ODLI 3 . Non
presenta nuovi attributi, dal momento che il fatto di essere un ListType ne
esaurisce completamente la descrizione.
EnumType
Un EnumType è un ComplexType che rappresenta tipi costruiti mediante il
costrutto ODLI 3 enum. Esso comprende dunque un vettore item che modella
l’insieme degli elementi dell’enumerazione utilizzati per definire il nuovo tipo.
SpecificComplexType
Uno SpecificComplexType è un ComplexType costruito fissando, a partire
da un dato tipo base, un particolare valore costante. Tale valore può rappresentare un tipo CONSTANT (un attributo di questo tipo ha il valore fissato),
un tipo FIXED (un attributo di questo tipo può essere definito come facoltativo, ma se esiste ha il valore fissato) o un tipo DEFAULT (un attributo di
questo tipo, a meno di esplicite indicazioni, ha il valore fissato).
RangeType
Un RangeType è un tipo complesso che rappresenta tipi costruiti definendo un
range ODLI 3 . Tale classe è costituita dunque dalla quadrupla <lowerBound,
upperBound, lowerBoundInf, upperBoundInf>, dove i primi due attributi
sono gli estremi del range e gli ultimi due sono valori booleani che servono
per modellare estremi di range infiniti.
StructType
Uno StructType è un AttributeType che rappresenta tipi definiti mediante
il costrutto struct di ODLI 3 . Pertanto, tale classe comprende un vettore
attributi di attributi della struct.
85
6.3.3
Classi che modellano il mapping tra livelli diversi
MappingTarget
-tipo: int
-target: Vector
+Mapping(type: int): MappingTarget
+addTarget(target: String): void
Mapping
-classeAltoLivello: String
-attributoAltoLivello: String
-sorgente: String
-interfacciaLocale: String
-mappingTarget: MappingTarget
+MappingRule(hlClass: String, hlAttr: String, source: String, localInt: String): Mapping
1..*
1..*
GlobalToLocalMappingTable
+GlobalToLocalMappingTable(nomeFileSchema: String): void
ConceptToLocalMappingTable
+insertMapping(rule: Mapping, concetto: Concept): void
<<utilizza>>
<<Interface>>
Translatable
+traduciPer(sorgente: Source, mapTab: ConceptToLocalMappingTable): Translatable
Figura 6.5: Classi che modellano il mapping tra livelli diversi
Presentiamo ora come si è deciso di rappresentare il mapping tra classi
86
di alto livello ed interfacce locali.
MappingTarget
Un Mapping Target è la concettualizzazione di una cella di una tabella come
la 5.2, ovvero rappresenta la proprietà local attribute name della rappresentazione concettuale sopra ricordata. In particolare, un Mapping Target è
una coppia <tipo, target>, dove tipo rappresenta il tipo di mapping (come discusso in 5.4.3, un attributo globale si può mappare su una costante, su
un singolo attributo locale, su un’alternativa(OR) di attributi locali, su una
concatenazione (AND) di attributi locali, oppure può non avere mapping su
una determinata interfaccia locale associata alla classe di alto livello in analisi), mentre target costituisce il vettore di entità locali sulle quale si effettua
il mapping (e dunque può contenere una costante, un attributo locale, o più
attributi locali).
Mapping
Un Mapping descrive:
• l’insieme degli elementi necessari per individuare una cella di una tabella come la 5.2
• il suo contenuto;
Può pertanto essere vista come una quintupla <classeAltoLivello, attributoAltoLivello, sorgente, interfacciaLocale, mappingTarget>, dove le prime quattro proprietà sono le caratteristiche che individuano una cella
e la quinta è un Mapping Target, come descritto nel paragrafo precedente.
È evidente che la classe Mapping modella un qualsiasi tipo di mapping
fra due livelli diversi. Nel seguito si vedrà ad esempio come tale classe può
essere utilizzata tanto per rappresentare il mapping tra schema integrato e
schemi locali, quanto per rappresentare il mapping tra concetti dell’ontologia
e schemi locali.
GlobalToLocalMappingTable
Una GlobalToLocalMappingTable descrive il mapping tra schema integrato
e schemi locali(mapping M3 in 6.2.3). È un insieme di Mapping, ovvero un
vettore i cui elementi sono oggetti Mapping. In particolare, questa tabella
viene costruita analizzando il file ODLI 3 che descrive lo schema integrato ed
i suoi riferimenti agli schemi locali.
87
ConceptToLocalMappingTable
Una ConceptToLocalMappingTable descrive il mapping tra concetti dell’ontologia e schemi locali delle sorgenti(mapping M4 in 6.2.3). È una tabella le
cui righe sono Mapping. In particolare, questa tabella si costruisce partendo
dall’insieme dei concetti dell’ontologia e dalla GlobalToLocalMappingTable.
Il meccanismo di costruzione di tale tabella si basa sulla possibilità di comporre le informazioni di mapping tra concetti ed X-Class con quelle relative
alle corrispondenze tra X-Class ed interface globali e con quelle contenute
nella tabella GlobalToLocalMappingTable.
6.3.4
Altre classi
Abbiamo indicato i concetti che permettono, una volta tradotti in classi, di
modellare le entità del dominio di nostro interesse. Diamo ora un accenno
delle classi necessarie per compiti di servizio, ovvero la cui definizione non
è collegata ad esigenze rappresentative di una qualche entità del dominio,
bensı̀ alla necessità di svolgere particolari compiti.
QueryTraductionManager
Questa classe funge da “contenitore” per le classi che modellano l’ontologia,
l’interrogazione da tradurre e le regole di mapping tra concetti e sorgenti
locali. In questo modo, essa rappresenta l’unica classe con la quale un utente
esterno abbia la necessità di interagire per utilizzare il modulo di traduzione
di interrogazioni.
In particolare, la sua struttura ed i suoi legami con le altre classi sono
quelli indicati in figura 6.6.
Classi Scanner e Parser
Per quanto riguarda l’acquisizione delle informazioni contenute nei file OQL
od ODLI 3 , è opportuno utilizzare analizzatori lessicali e sintattici specifici
per ogni tipologia di file di input. In particolare, per la definizione del lessico
e dei relativi analizzatori è comodo fare uso del generatore di analizzatori
lessicali JFlex, mentre per quanto riguarda la definizione delle grammatiche
e la realizzazione degli analizzatori sintattici si utilizza il generatore BYacc-J.
JFlex, partendo da una descrizione mediante espressioni regolari di un lessico, e da una corrispondenza tra riconoscimento di tali espressioni ed azioni
da intraprendere, genera una classe Java che svolge funzione di analizzatore
lessicale per il lessico in questione.
88
BYacc-J, partendo da una definizione di una grammatica in forma BNF, e
da una corrispondenza tra produzioni riconosciute ed azioni da intraprendere,
genera una classe Java che svolge funzione di analizzatore sintattico per la
grammatica in questione.
QueryTraductionManager
-nomeFileOntologia: String
-nomeFileSchema: String
Ontology
-nomeFileQuery: String
-concetti: SearchableVector
-ontologia: Ontology
-tipi: SearchableVector
-query: Query
-sorgenti: SearchableVector
-mapTab: ConceptToLocalMappingTable
+setNomeFileSchemaIntegrato(nome: String): void
+setNomeFileOntologia(nome: String): void
+setNomeFileQuery(nome: String): void
<<utilizza>>
+leggiSorgenti(): void
+creaTraduzioni(): void
+stampaQuery(): void
<<utilizza>>
GlobalToLocalMappingTable
Query
-variabili: SearchableVector
+GlobalToLocalMappingTable(nomeFileSchema: String): void
-condizione: Condition
+getConceptOfVariabe(var: String): String
ConceptToLocalMappingTable
+insertMapping(rule: Mapping, concetto: Concept): void
Source
-nome: String
-interrogazioni: Vector
+translating: int
+creaTraduzione(mapTab: ConceptToLocalMappingTable): void
+getTranslatingQuery(): LocalQuery
+addLocalQuery(query: LocalQuery): void
Figura 6.6: La classe Query Traduction Manager
89
In particolare, si è deciso di realizzare tre coppie di analizzatori lessicale
e sintattico, per leggere i tre diversi file in input:
• OntologyScanner ed OntologyParser, per l’acquisizione della descrizione dell’ontologia.
• IntegratedSchemaCompleteScanner ed IntegratedSchemaCompleteParser, per l’acquisizione della descrizione dello schema integrato.
• OQLScanner ed OQLParser, per l’acquisizione dell’interrogazione
OQL da tradurre.
6.4
Traduzione di Query:rappresentazione delle scelte
Precisiamo prima di tutto che parlando di traduzione di Query indichiamo
il processo che, partendo da una Query sull’ontologia, e sfruttando le informazioni contenute in una ConceptToLocalMappingTable, genera per ogni
sorgente integrata dall’ontologia una Local Query e la traduce nella terminologia della sorgente in questione. In particolare, tale meccanismo di
traduzione può:
1. non dare origine ad alcuna traduzione, nel caso in cui un qualche concetto associato ad una variabile della Query non si mappi su alcuna
interfaccia locale di quella sorgente, oppure nel caso in cui per un particolare attributo di una variabile della Query non esista mapping su
alcuna interfaccia locale a quella sorgente, tra quelle su cui si potrebbe
mappare il concetto cui la variabile si riferisce;
2. dare origine ad una traduzione “semplice”, nel caso in cui ogni concetto
ed ogni attributo presenti nella Query si mappino esattamente su una
sola interfaccia locale e su un solo attributo locale, rispettivamente, per
ogni sorgente considerata;
3. dare origine ad una traduzione costituita dalla concatenazione (mediante costrutto union di OQL) di più LocalQuery, esaustiva di tutte
le possibili combinazioni di corrispondenze tra concetti ed interfacce
locali (qualora un singolo concetto si possa mappare su più interfacce
locali alla medesima sorgente) e tra attributi di concetti ed attributi di
interfacce locali (qualora un singolo attributo di un concetto si mappi
90
su un’alternativa - union nella mapping rule - di attributi di una certa
interfaccia locale).
È evidente che, se il caso 1 è banale, e se il caso 2 si esaurisce nella ricerca
di una corrispondenza tra concetti ed interfacce locali, il caso 3 è quello più
difficile da trattare nel processo di traduzione. Per supportare questo caso
particolare, come indicato in precedenza (vedi 6.2.2), una Local Query è una
Query dotata di una tabella di corrispondenze, ovvero di scelte di traduzione
operate in fase di riformulazione della query, tra entità dell’ontologia (concetti e relativi attributi) ed entità locali nelle quali quelle dell’ontologia sono
state tradotte. Vediamo dunque come sono rappresentate le corrispondenze
utilizzate per la traduzione (tenere traccia di queste informazioni, da una
parte è necessario ai fini della traduzione, e dall’altra potrebbe essere utile
per riformulare i risultati ottenuti dalle query poste sulle singole sorgenti in
termini della query di partenza.
TraductionChoiceItem
-concetto: String
TraductionChoiceTable
-attributoGlobale: String
-interfacciaLocale: String
-mappatoSu: Vector
-tipoMapping: int
1..*
mappatoSu è un vettore
con n > 1 elementi nel
caso di mapping in AND
Figura 6.7: Classi che rappresentano le scelte di traduzione
6.4.1
TraductionChoiceItem
Un TraductionChoiceItem è la descrizione di una corrispondenza tra un
attributo di un concetto dell’ontologia ed attributi di interface locali. Esso è dunque una quintupla <concetto, attributo globale, interfaccia
91
locale, mappato su, tipo mapping>, dove mappato su è un vettore di attributi locali (caso di mapping con concatenazione (AND) di attributi locali),
un attributo locale o una costante, tipoMapping definisce il tipo di mapping
relativo a questa scelta (AND, singolo attributo, costante).
6.4.2
TraductionChoiceTable
Una TraductionChoiceTable è una tabella di Traduction Choice Item, e
rappresenta l’insieme delle scelte effettuate nei passi successivi di riformulazione della Query sull’ontologia in una particolare Local Query, quella cui
la tabella è associata. Chiaramente, una Traduction Choice Table viene
costruita ed aggiornata incrementalmente man mano che l’interrogazione viene tradotta, in particolare quando vengono tradotti gli eventuali attributi di
concetti della query di partenza (vedi 6.5.2).
6.5
Traduzione di Query: algoritmi
Come già discusso in 5.4, il problema della traduzione di interrogazioni OQL
comporta l’utilizzo delle regole di mapping tra i diversi livelli dell’ontologia.
In particolare, come visto, tali regole si differenziano in alcune tipologie diverse, presentate in 6.2.3. Abbiamo detto che le regole che mappano concetti
dell’ontologia (e loro attributi) sulle interfacce locali delle sorgenti possono
essere ottenute componendo i tre livelli di mapping dettagliatamente descritti
in ??, ed abbiamo illustrato il significato di tali tipologie di mapping.
Vediamo ora, alla luce dei concetti illustrati in precedenza, ed in particolare del discorso sulle scelte di traduzione presentato in 6.4, che cosa significa
tradurre una Query in una LocalQuery e come avviene tale traduzione.
Sia data una particolare sorgente locale, per la quale è necessario ottenere
una traduzione di una Query formulata sull’ontologia. Il primo passo della
traduzione consiste nell’istanziare una Local Query sulla base della Query
in questione. In pratica, tale Local Query, associata alla sorgente, risulta
essere inizialmente una copia della Query sull’ontologia, la cui tabella delle
scelte di traduzione si presenta, da principio, vuota.
Si tratta, quindi, di tradurre questa copia che abbiamo associato alla sorgente di nostro interesse. In particolare, tradurre un’interrogazione significa
tradurne l’elenco di variabili e tradurne la condizione. Si noti come in generale una query OQL non debba necessariamente associare variabili ai concetti
della clausola from; tuttavia, dal momento che ci occupiamo di query OQL
composte mediante un’interfaccia di composizione e non direttamente, si assume per semplicità che tale interfaccia componga query OQL nelle quali
92
ad ogni concetto viene automaticamente associata una variabile. In questo
senso, dunque, ha senso parlare di traduzione di variabili e di attributi di
variabili, come si farà in seguito.
6.5.1
Traduzione di variabili
Tradurre le variabili della query significa sostituire i nomi di concetto associati alle variabili con nomi di interfacce locali. In generale, tale sostituzione
Concetto --> Interfaccia locale non è, per una data sorgente, univoco.
La traduzione di una variabile dell’interrogazione, dunque, genera in linea di
principio diversi possibili risultati, corrispondenti alla combinazione di tutte
le possibili alternative di sostituzione per il singolo concetto. In realtà, non è
detto che tutte queste alternative siano valide per quanto riguarda la traduzione dell’interrogazione. Infatti, è importante tenere in considerazione che
un dato concetto C, pur mappandosi su una certa interfaccia locale IL, può
non avere su di essa un mapping per ogni suo attributo. Si veda il seguente
esempio, nel quale le regole di mapping tra concetti ed interfacce locali sono
espresse mediante la notazione utilizzata da ODLI 3 :
interface Cat
{
attribute string name
mapping rule
S.Gatto.nome,
S.Cat.name;
attribute string color
mapping rule
S.Cat.color;
}
In questo caso, è evidente che in generale il concetto Cat si mappa sia sull’interfaccia locale S.Gatto sia su quella S.Cat. È tuttavia altrettanto chiaro
come una traduzione di Cat in S.Gatto risulti priva di valore per interrogazioni la cui condizione coinvolga l’attributo name di una variabile riferita al
concetto Cat, non essendoci alcun mapping di tale attributo sull’interfaccia
in questione.
Questo semplice esempio sottolinea come, benchè concettualmente sia
possibile immaginare la traduzione delle variabili e la traduzione della condizione di una Query come due passi separati, dal punto di vista operativo
è sensato evidenziare il legame che lega i due aspetti: l’esempio stesso della rappresentazione di regole di mapping in ODLI 3 rende evidente come il
93
mapping su una particolare interfaccia locale (e su suoi attributi) dipenda
non solo dal concetto, bensı̀ anche dai suoi attributi.
Sembra pertanto logico svolgere prima la traduzione della condizione della
query, e dal risultato delle scelte di traduzione operate in tale fase desumere
la traduzione dei concetti in interfacce locali.
Allo scopo di rappresentare la caratteristica di traducibilità comune ai
concetti utilizzati per rappresentare un’interrogazione, si è deciso di introdurre un’interfaccia, denominata Translatable. Tale interfaccia vincola
le classi che la implementano a prevedere un metodo traduciPer(Source,
ConceptToLocalMappingTable), che rappresenta il cuore del processo di traduzione. In particolare, i concetti che devono essere traducibili (Translatable) sono Condition ed Operand: tali interfacce, pertanto, sono definite
come estensioni di Translatable. Vediamo ora come le classi che modellano le diverse tipologie di Condition e di Operand si comportano dal punto
di vista della traducibilità, ovvero come si traduce ogni singolo concetto di
nostro interesse.
6.5.2
Traduzione di condizioni
La traduzione di una condizione avviene analizzando ricorsivamente la struttura ad albero dell’espressione che rappresenta la condizione. Vediamo dunque come avviene la traduzione dei singoli nodi di tale albero, a seconda del
loro tipo.
Complex Condition Una condizione complessa si traduce riscrivendo
le due sotto-condizioni corrispondenti ai due rami di sinistra e di destra
che si dipartono dal nodo Complex Condition dell’albero che rappresenta la
condizione della query. In particolare, in caso di condizione complessa di tipo
NOT, la traduzione si effettua traducendo il solo sottoalbero corrispondente
alla condizione negata dall’operatore booleano unario.
Simple Condition Una condizione semplice si traduce riscrivendo i
due operandi dell’operatore che la Simple Condition rappresenta.
Constant, BooleanConstant Ogni costante, e pertanto anche ogni
costante booleana, rimane invariata dopo il processo di traduzione.
Identifier Un identificatore, ovvero una coppia <variabile, attributo>, si traduce considerando il mapping della terna <concetto, attri-
94
buto, sorgente> (dove concetto è il nome del concetto associato alla variabile variabile) su interfacce ed attributi locali.
È chiaro per quanto detto in precedenza che tale mapping non è necessariamente univoco, e può dunque portare a dover considerare diverse alternative, ovvero a generare più traduzioni diverse, ugualmente valide, della query
di partenza. Tali traduzioni, come detto, verranno composte in un’unica query da sottomettere alla sorgente locale mediante l’operatore union di OQL
(in alternativa, si può pensare di sottomettere separatamente alla sorgente
le diverse Local Query risultanti, e di effettuare quindi l’unione dei risultati
cosı̀ ottenuti).
Esemplifichiamo l’uso della tabella delle scelte che, come detto, viene
associata ad ogni Local Query. Riferendoci all’esempio indicato sopra, ipotizziamo di dover tradurre due diversi Identifier riferiti all’attributo name
di variabili che istanziano il concetto Cat. Ad una prima occorrenza di tale situazione, chiaramente, si sdoppia la Local Query in due Local Query
alternative, entrambe associate alla stessa sorgente. Nella prima di tali alternative si userà il mapping di Cat.name su S.Cat.name, nella seconda quello
su S.Gatto.nome. Proseguendo poi nella traduzione della prima delle due
alternative, si incontrerà nuovamente un attributo name di una variabile di
tipo Cat. In questo caso, chiaramente, è necessario rimanere coerenti ed effettuare la stessa scelta che ha portato a definire quella particolare possibilità
di traduzione (e dunque considerare solo il mapping su S.Cat.name).
Ancora, può darsi il caso in cui si sia incontrato un Identifier riconducibile alla coppia Cat.color, e che si sia pertanto utilizzato il mapping
su S.Cat.color. A questo punto, incontrando un Identifier riferito a
Cat.nome, pur non avendo ancora effettuato mapping di questo tipo, si dovrà necessariamente scegliere il solo mapping su S.Cat.nome, escludendo
quello su S.Gatto.nome, valido in generale ma incompatibile con le scelte
già effettuate.
In pratica, dunque, il ruolo della Mapping Choice Table è quello di mantenere nel caso della traduzione di una query una traccia delle scelte effettuate
sino alla traduzione dell’Identifier in questione.
Vediamo ora, nel dettaglio, come si deve operare per tradurre per una
certa sorgente sorgente un Identifier <variabile, attributo> di una
Local Query query.
1. Si individua il concetto concetto corrispondente alla variabile variabile dell’identifier.
2. Si cerca nella TraductionChoiceTable associata a query la coppia <concetto,
attributo>.
95
2.1. Se esiste una riga della tabella con tale terna, si utilizza il mapping che essa rappresenta per tradurre l’attributo dell’Identifier in
questione.
2.2. Se non esiste una riga di questo genere, si cerca nella tabella una riga
contenente <concetto>
2.2.1. Se non esiste una riga di questo genere, si cerca nella ConceptToLocalMappingTable un insieme di righe con la terna concetto,
attributo, sorgente.
2.2.1.1. Se tale insieme è vuoto, significa che non è possibile tradurre la coppia <concetto, attributo> per
sorgente: in questo caso, si eliminano tutte le possibili LocalQuery associate a sorgente.
2.2.1.2. Se tale insieme contiene un solo elemento, siamo di
fronte a tre possibilità:
• Tale elemento rappresenta un MappingTarget su
una costante: si sostituisce l’Identifier con la costante in questione e si aggiorna la TraductionChoiceTable
con il mapping seguito (quintupla <concetto, attributo globale, interfaccia locale, costante, tipo
= COSTANTE>). La traduzione dell’Identifier è
conclusa.
• Tale elemento rappresenta un singolo attributo di
una interfaccia locale: si sostituisce l’attributo attributo
con il nome dell’attributo locale trovato, e si aggiorna la TraductionChoiceTabel con il mapping seguito (quintupla <concetto, attributo globale,
inter- faccia locale, attributo locale, tipo
= ATTRI- BUTO>). La traduzione dell’Identifier è
conclusa.
• Tale elemento rappresenta un MappingTarget su
una concatenazione di attributi di un’interfaccia locale: si sostituisce l’Identifier con una IdentifierConcatenation e si aggiorna la MappingChoiceTable con il
mapping seguito (quintupla <concetto, attributo,
interfaccia locale, elenco attributi locali,
tipo = CONCATENAZIONE>). La traduzione dell’Identifier è conclusa.
• Tale elemento rappresenta un’alternativa di N attributi di un’interfaccia locale: in questo caso, si
96
hanno N diverse possiblità di traduzione. Si creano dunque N copie (N - 1 oltre a quella corrente)
della LocalQuery in traduzione, e si differenziano
le varie copie con le N possibilità di traduzione di
attributo offerte dall’alternativa tra gli attributi.
Chiaramente, si inserisce nelle rispettive tabelle di
scelta la quintupla <concetto, attributo, sorgente, interfaccia locale, attributo locale scelto, tipo = ATTRIBUTO>, dove attributo locale scelto è l’attributo, tra quelli in
alternativa, scelto per la copia in questione. La
traduzione dell’Identifier è conclusa.
2.2.1.3. Se tale insieme contiene N > 1 elementi, significa che
la coppia <concetto, attributo> si mappa su N interfacce locali a sorgente. In questo caso, si procede generando N (N - 1 più quella attuale) copie della LocalQuery attuale, e si differenziano le copie aggiornando le rispettive tabella di scelta con la terna
<concetto, attributo, interfaccia locale scelta>.
2.2.2. Se esiste una riga di questo genere, si utilizza il nome di interfaccia locale in essa contenuto per cercare nella ConceptToLocalMapping Table una riga con la quadrupla <concetto, attributo, sorgente, interfaccia locale>.
• Se non esiste una riga del genere, significa che le scelte di
traduzione sin qui effettuate non possono portare a traduzioni complete della query di partenza. Pertanto, si elimina
la LocalQuery corrente.
• Se esiste una riga del genere, ci si trova di fronte alle
alternative già chiarite in 2.2.1.2.
97
6.6
Realizzazione dell’interfaccia utente
Trattiamo ora il problema della realizzazione di un’interfaccia grafica che
permetta di navigare l’ontologia e di comporre interrogazioni OQL su di
essa, sulla scorta di quanto ià discusso nella sezione 5.3. In tale sezione
si sono presentati due diversi approcci, presenti in letteratura, al problema
di nostro interesse. Sulla base di tali casi reali, si è presentata una prima
strutturazione di un sistema grafico che permetta un accesso semplice e chiaro
alla struttura dell’ontologia, nonchè di ottenere dall’ontologia informazioni
di tipo intensionale ed estensionale.
Vediamo ora un approccio più organico e completo al problema della
realizzazione di un’interfaccia per utilizzare modelli ontologici.
6.6.1
Obiettivi: analisi dei requisiti
Prima di tutto, riprendiamo brevemente le esigenze alla base del nostro lavoro
di progetto e realizzazione dell’interfaccia.
• Disporre di un’interfaccia di tipo grafico, del genere di quelle presenti in
progetti reali in letteratura, capace di visualizzare la struttura dell’ontologia, ovvero l’insieme dei concetti che la compongono, delle relazioni
tra di essi (almeno quelle principali), e la struttura di ogni concetto.
Seguire un requisito di questo genere, chiaramente, va nella direzione
di realizzare un’interfaccia che si proponga come strumento di semplice
uso anche ad utenti non esperti, dando una rappresentazione di tipo
grafico o semi-grafico del modello in uso.
• Realizzare un’interfaccia adatta al’utilizzo di utenti non necessariamente esperti nell’utilizzo di linguaggi di Query SQL-like. In questo senso,
l’idea di un’interfaccia di composizione di query basata su elementi grafici (menu a tendina, pulsanti,. . . ) ed azioni tramite mouse (clic del
mouse, drag and drop,. . . ) si propone di fornire un di supporto intuitivo
all’utente inesperto.
• Facilitare l’apprendimento dell’uso tramite indicazioni che l’interfaccia
fornisce nell’ottica di facilitare l’apprendimento e l’utilizzo dell’interfaccia stessa.
• Prevedere un buon supporto all’utente dal punto di vista del feedback che l’interfaccia fornisce in presenza di azioni scorrette e dunque
non permesse, allo scopo di chiarire all’utente gli errori commessi e di
evitarne la ripetizione.
98
• Supportare l’utente nella composizione di interrogazioni corrette, ovvero guidare la composizione delle query in modo da evitare, ad esempio,
condizioni che coinvolgano il confronto tra entità di tipo incompatibile.
Gli ultimi tre requisiti, in particolare, vanno nella direzione di soddisfare i
principali criteri di usabilità di Nielsen [17], ben noti nell’ambito della Human
Computer Interaction.
Più precisamente, si è posta particolare attenzione a presentare all’utente un’interfaccia che gli permetta di evitare errori inutili, guidandolo in
una composizione completa e corretta delle interrogazioni, impedendogli di
compiere azioni scorrette dal punto di vista della realizzazione di tali interrogazioni, e segnalando in modo adeguato e chiaro tanto le indicazioni sul da
farsi, quanto le segnalazioni di eventuali errori.
D’altro canto, si è cercato di fornire l’interfaccia proposta di un Help
completo ed esauriente, onde aiutare l’utente in caso di dubbio.
Infine, si è pensato a due diversi livelli di utilizzo dell’interfaccia, rendendo immediatamente disponibili le più comuni opzioni di composizione di
un’interrogazione, e dando la possibilità di attivare in un secondo momento
quelle più avanzate.
6.6.2
L’interfaccia proposta: descrizione e commento
Come già accennato nella sezione 5.3, la nostra idea è quella di proporre un’interfaccia articolata in tre diverse parti, la prima per visualizzare i concetti dell’ontologia e le loro relazioni, la seconda per descrivere la struttura dei singoli
concetti, la terza per la composizione vera e propria dell’interrogazione.
È abbastanza evidente che ciascuna di queste diverse parti può, in linea
di massima, essere realizzata in più modi diversi. Qui si propone pertanto una possibile scelta realizzativa per le tre diverse sezioni dell’interfaccia;
tuttavia, le scelte architetturali adottate in fase di realizzazione permettono,
come spiegato più avanti, di sostituire in modo semplice, a livello di implementazione, uno dei tre moduli con un altro che svolga la stessa funzione in
modo diverso.
Presentazione dell’ontologia Per la presentazione della struttura dell’ontologia si è realizzata un’interfaccia di tipo tabellare (vedi figura 6.8),
che permette di elencare i concetti che costituiscono l’ontologia, nonchè informazioni sulle relazioni di sussunzione e di specializzazione che tra tali
concetti intercorrono. Come ricordato in 5.3, in letteratura sono dati esempi
di presentazione della struttura di un’ontologia in forma grafica, basati sulla geometria iperbolica. Tuttavia, in questa sede non è sembrato opportuno
99
complicare l’aspetto realizzativo dell’interfaccia grafica, e si è pertanto deciso
di optare, piuttosto che per una presentazione grafica, per una presentazione
tabellare della struttura dell’ontologia.
In ogni caso, come già accennato, si è fatto in modo di lasciare un’ampia
possibilità di modifica dell’interfaccia proposta, realizzando un’architettura
modulare predisposta per la sostituzione di singole parti, ad esempio del
modulo che si occupa di rappresentare l’ontologia. Tale architettura sarà
illustrata nell’appendice D.
Figura 6.8: Navigazione dell’ontologia
Presentazione dei concetti Per descrivere completamente un concetto,
è necessario presentarne la struttura, ovvero l’insieme degli attributi. È questa la strada seguita da [18], come indicato in figura 5.3. Un’altra possibile
scelta è quella di [9], riportata in figura 5.4, che consiste nel dare indicazioni
sulla struttura di ogni concetto solo nel momento in cui è necessario utilizzare gli attributi del concetto in questione per comporre un’interrogazione.
Anche nel primo caso, tuttavia, la presentazione della struttura di un concetto era finalizzata all’introduzione di valori di confronto da richiedere in fase
d’interrogazione.
Nel nostro lavoro si è presa la decisione di rappresentare la struttura di
un concetto in modo autonomo rispetto alla composizione di interrogazioni,
basandosi sull’idea che un utente possa avere la necessità di farsi un’idea dei
concetti su cui può effettuare una query prima di essere in grado di formulare
la stessa. Si è pertanto deciso di scindere due aspetti logicamente distinti, che
nei casi presentati in 5.3 risultavano invece confusi. D’altra parte, come si
100
è ampiamente discusso a proposito delle modalità di utilizzo di un’ontologia
(vedi 3.2 e, in particolare, 3.2.2), non è detto che l’utilizzo di un’ontologia
sia volto esclusivamente alla ricerca di informazioni estensionali, ma può
darsi invece l’eventualità che l’utente ricerchi informazioni sulla struttura
dell’ontologia e dei concetti che la compongono. Anche in questo senso,
dunque, è sembrato opportuno proporre una descrizione di ogni concetto
evinta dal contesto di composizione di interrogazioni.
In particolare, come già nel caso della presentazione dell’ontologia, si è
optato per una rappresentazione tabellare (figura 6.9) degli attributi di un
concetto, arricchita rispetto a quelle di [9] e [18] dell’informazione relativa ai
tipi degli attributi. Tale informazione, oltretutto, arricchisce la descrizione
dei legami tra diversi concetti, dal momento che un concetto può essere il
tipo di un attributo di un altro concetto, e dunque essere collegato a tale
concetto.
La selezione del concetto di cui visualizzare la struttura avviene mediante
clic sulla riga del concetto d’interesse nella tabella dell’ontologia.
Figura 6.9: Struttura di un concetto
Composizione di interrogazioni Anche per quanto riguarda la composizione di interrogazioni, si è pensato di arricchire quanto già proposto nei
casi reali citati. In particolare, in [9] si proponeva un interfaccia nella quale
l’utente doveva scegliere un concetto ed associare a tale concetto un nome
di variabile, quindi sceglierne un attributo ed indicarne un valore, il quale
poteva essere una costante inserita dall’utente o una delle variabili istanziate.
101
Figura 6.10: Composizione di interrogazioni
102
Nel nostro lavoro, si è pensato di assegnare automaticamente alle variabili,
istanziate mediante la scelta di concetti, nomi univoci. Questa scelta da una
parte non costringe necessariamente l’utente a conoscere la distinzione tra
concetti e variabili; dall’altra, per come i nomi sono scelti, rende esplicito il
legame della variabile con il concetto istanziato, chiarendo cosı̀ all’utente il
significato della variabile senza costringerlo a ricordarlo.
Una panoramica d’insieme della sezione d’interfaccia che permette la composizione di interrogazioni è data in figura 6.10. Vediamo ora in dettaglio
come si articola tale sezione.
Figura 6.11: Tabella delle variabili
Scelta e rappresentazione delle variabili Mentre nei casi presenti
in letteratura la scelta della variabili era implicita [18] oppure legata all’indicazione del valore da assegnare ad attributi delle variabili [9], nella nostra
103
interfaccia abbiamo deciso di separare le due questioni, la scelta di una variabile associata ad un concetto e l’imposizione di condizioni sulle variabili o
sui loro attributi.
In particolare, si è destinata una parte dell’interfaccia all’elencazione, in
forma di tabella (vedi figura 6.11), delle variabili istanziate e dei rispettivi
concetti di riferimento. Tale tabella può essere arricchita di nuove variabili
scegliendo un concetto nella tabella che rappresenta l’ontologia. Tale scelta
può essere effettuata mediante doppio clic sul concetto d’interesse, o mediante
Drag and Drop dalla tabella dei concetti a quella delle variabili. Naturalmente, è possibile rimuovere una variabile dalla relativa tabella selezionandola ed
utilizzando quindi l’apposito bottone.
Figura 6.12: Rappresentazione della condizione della query
Scelta e rappresentazione della condizione della query Per coerenza con quanto fatto a proposito della rappresentazione dell’ontologia, della
struttura dei concetti e dell’elenco delle variabili, anche la condizione dell’interrogazione che si sta componendo viene rappresentata mediante una
tabella.
In particolare, una riga di tale tabella può essere
1. un confronto tra due operandi
2. un operatore booleano (AND, OR, NOT) applicato sotto-condizioni.
Tre menù a tendina danno la possibilità di scegliere operandi ed operatori per comporre le condizioni atomiche, mentre un insieme di bottoni permette di inserire gli operatori booleani o di inserire una condizione atomica
accettando le selezioni effettuate sui tre menu.
In particolare, si noti come una composizione di interrogazioni atomiche
di questo genere, che comprenda cioè la possibilità di scegliere l’operatore
104
mediante il quale confrontare i due operandi, costituisca una notevole estensione rispetto ai casi reali ricordati in precedenza, nei quali l’unico operatore
utilizzabile era quello di uguaglianza, sottinteso nella scelta di un valore da
imporre per un attributo.
L’insieme degli operatori proposto è fisso (vedi figura 6.13), ma nulla vieta
di pensare ad una modifica di tale insieme.
Figura 6.13: Menu di scelta dell’operatore
La scelta degli operandi, al contrario, è legata al contesto in cui si opera,
ed in particolare alle variabili istanziate disponibili nella tabella. In particolare, il primo operando può essere scelto in un elenco (vedi figura 6.14.(a))
che comprende tutte le variabili istanziate e tutti i loro attributi. Il secondo
operando, invece, può essere impostato dall’utente (valori costanti), oppure
scelto in un elenco ridotto rispetto al precedente, costituito da tutti gli elementi del precedente il cui tipo è compatibile 1 con quello del primo operando
scelto (figura 6.14.(b)).
Accanto a questo insieme base di funzionalità, che permette evidentemente di specificare condizioni costituite esclusivamente da condizioni atomiche
legate mediante AND, OR e NOT, senza la possibilità di comporre sottocondizioni di profondità qualunque, di è deciso di proporre un insieme di
funzionalità avanzate, attivabili mediante un bottone apposito. Queste ulteriori funzionalità hanno lo scopo di permettere all’utente di correggere la
condizione composta (bottoni di cancellazione di una riga e di reset dell’intera condizione), e soprattutto di costruire espressioni complesse senza che
1
Due tipi sono considerati compatibili se coincidono, oppure se uno dei due deriva
dall’altro. Ad esempio, se il primo operatore è di tipo Tipo, per la scelta del secondo
potrebbero essere disponibili elementi di tipo Tipo, o di tipo TipoParticolare: Tipo
o, ancora, di tipo SET < Tipo >
105
(a) Menù di scelta del primo operando
(b) Menù di scelta del secondo operando
Figura 6.14: Menu per la scelta degli operandi
siano posti limiti alla profondità delle sotto-espressioni. In questo senso, si
dispone di bottoni per l’inserimento e la rimozione di parentesi all’inizio ed
alla fine di ogni riga.
In figura 6.15 proponiamo un’immagine della barra dei bottoni standard,
mentre quella completa delle funzionalità avanzate è presentata in figura 6.16
(si noti in particolare il tasto “Avanzate”, che cambia aspetto a seconda della
modalità scelta e permette di passare dall’una all’altra).
Figura 6.15: Bottoni per modificare la condizione: versione base
I messaggi di errore Un discorso a parte merita il sistema di indicazioni e messaggi di errore messo a punto allo scopo di segnalare all’utente
il problema che si è presentato e dare indicazioni per evitarne il ripetersi.
Come già ricordato in precedenza, si è posta una particolare cura nella scelta
di messaggi il più possibile chiari, completi e costruttivi per l’utente, che non
si limitino dunque a segnalare la presenza di un problema, ma si curino anche
di dare un’indicazione su come risolverlo.
106
Figura 6.16: Bottoni per modificare la condizione: versione avanzata
Diamo di seguito un elenco dei messaggi di errore utilizzati nell’interfaccia
proposta, descrivendo la situazione nella quale vengono utilizzati.
1. Azione impossibile: tabella delle variabili vuota o non selezionata
Questo messaggio compare quando l’utente preme il bottone di eliminazione di una variabile dalla tabella delle variabili senza aver selezionato
alcuna riga di tale tabella, o in presenza di tabella vuota.
2. Errore: scegliere il primo operando prima di aggiungere una
condizione !
Questo messaggio compare quando l’utente preme il bottone per aggiungere una condizione atomica senza aver selezionato il primo operando di tale condizione
3. Errore: scegliere il secondo operando prima di aggiungere una
condizione !
Questo messaggio compare quando l’utente preme il bottone per aggiungere una condizione atomica senza aver selezionato il secondo operando di tale condizione
4. Errore: scegliere un operatore prima di aggiungere una condizione !
Questo messaggio compare quando l’utente preme il bottone per aggiungere una condizione atomica senza aver selezionato l’operatore di
tale condizione
5. Errore: selezionare una riga della tabella delle condizioni prima di compiere un’azione !
Questo messaggio compare quando l’utente preme uno dei bottoni che
modificano la condizione senza aver selezionato alcuna riga della tabella
della condizione
107
6. Azione impossibile: tabella della condizione vuota !
Questo messaggio compare quando l’utente tenta di resettare la tabella
della condizione e tale tabella è vuota
7. Errore di sintassi nella condizione della Query
Questo messaggio compare quando l’utente conclude la composizione dell’interrogazione dopo aver realizzato una query sintatticamente
scorretta
108
Capitolo 7
Esempi di interrogazione su
ontologie in ARTEMIS
Mostriamo ora qualche esempio del funzionamento del software prodotto, ed
in particolare del modulo che si occupa di tradurre l’interrogazione sull’ontologia in un insieme di interrogazioni sulle sorgenti locali integrate.
Per fare questo, presentiamo dapprima l’ontologia sulla quale verranno effettuate le interrogazioni, indicando le corrispondenze tra concetti dell’ontologia ed X-Class globali, e riportiamo quindi le regole di mapping tra schema
integrato e schemi locali.
Di seguito, proponiamo alcune interrogazioni sull’ontologia in questione,
mostrando le traduzioni per le diverse sorgenti.
7.1
L’ontologia di esempio
L’ontologia utilizzata per i nostri esempi è quella proposta in [3] come esempio
di funzionamento di un software che genera i concetti dell’ontologia a partire
dalle X-Class globali.
Allo scopo di fornire esempi relativi a tutti i possibili casi di traduzione
supportati dal nostro software, tuttavia, si è deciso di mantenere l’ontologia
presentata in [3], ma non l’origine di tale ontologia; a questo scopo, invece di
prendere in considerazione le sorgenti locali dalle quali il lavoro citato ricavava
l’ontologia, si fornisce una descrizione ODLI 3 del mapping tra schema integrato e schemi locali, in modo da arricchire la casistica delle corrispondenze
rispetto a quelle presenti in [3].
L’ontologia di cui faremo uso modella un dominio di carattere musicale, e prevede concetti che descrivono attività professionali legate al mondo
della musica (compositori, cantanti, . . . ), manifestazioni e gruppi musicali,
109
strumenti e “materiale musicale” (libri, spartiti, . . . ). In particolare, tale
ontologia si basa su cinque sorgenti locali di partenza, ognuna delle quali
si riferisce al dominio indicato. Schematizziamo per semplicità l’insieme di
corrispondenze tra i diversi passi d’integrazione nella figura 7.1, che istanzia
il modello generale proposto nella sezione 6.2.3 a proposito delle tipologie di
mapping.
interface artist
{
attribute string name;
attribute string artName ?;
(Concetti)
... ... ...
}
... ... ...
artist: artist
name: artist
...
(X-Class globali)
property {artName, string, (0,1)}
interface artist {
... ... ...
attribute string artName ? mapping rule
EMI.Artista.nomeDArte,
... ... ...
(VDP.Artista.soprannome union VDP.Artista.nomignolo
on rule1)
(Interfacce globali)
}
interface Artista {
attribute string nomeDArte;
...
}
interface Artista {
attribute string soprannome;
attribute string nomignolo;
... ... ...
}
(Sorgente
VDP)
... ... ...
(Sorgente
EMI)
(Sorgente
SONY)
(Sorgente
ISLAND)
(Interfacce locali)
(Sorgente
DG)
Figura 7.1: Esempio di mapping di un concetto sui diversi livelli dell’ontologia
La rappresentazione ODLI 3 completa dell’ontologia, generato dal modulo
software presentato in [3], viene riportato nell’appendice E. Di seguito mo-
110
striamo invece un estratto di tale rappresentazione, in modo da introdurre i
nostri esempi.
Descrizione del concetto Biography
interface Biography
{
attribute string author;
attribute date publishingDate;
attribute artist artist;
};
Descrizione del concetto artist
interface artist
{
attribute string name;
attribute string artName ?;
attribute date birthDate;
attribute set<AlbumType>Album;
};
Descrizione del concetto Composer, che estende il concetto artist
interface Composer:artist
{
attribute activity_Composer activity;
};
Descrizione del concetto Song
interface Song
{
attribute string title;
attribute decimal length;
attribute string kind ?;
attribute integer soldCopies ?;
attribute artist artist ?;
};
111
Lo schema integrato
Il codice ODLI 3 dello schema integrato descrive le corrispondenze tra gli
attributi delle interfacce globali (omonime, come detto in 6.2.3, alle X-Class
globali) e gli attributi delle interfacce locali. Tale corrispondenza è espressa mediante l’utilizzo delle regole di mapping, caratteristica introdotta in
ODLI 3 a questo preciso scopo.
Il codice ODLI 3 completo dello schema integrato utilizzato per gli esempi
è riportato nell’appendice E. Di seguito ne presentiamo un breve estratto,
per illustrare il meccanismo di definizione delle regole di mapping all’interno
della definizione delle classi globali. In particolare, mostriamo una parte
della definizione dell’interfaccia globale artist e delle corrispondenze dei suoi
attributi con quelli delle interfacce locali. Si noti ad esempio come l’attributo
globale name si mappi in certi casi su una concatenazione di attributi locali, e
come all’attributo globale artName corrisponda in un caso ad un’alternativa
tra attributi di una interfaccia locale.
interface artist
{
attribute string name
mapping rule
EMI.Artista.nome,
(SONY.Artist.firstname and SONY.Artist.middlename and
SONY.Artist.lastname),
ISLAND.Artist.name,
(DG.Kuenstler.Vorname and DG.Kuenstler.Familienname),
(VDP.Artista.nome and VDP.Artista.cognome);
attribute string artName ?
mapping rule
EMI.Artista.nomeDArte,
SONY.Artist.artName,
(VDP.Artista.soprannome union VDP.Artista.nomignolo
on rule1);
};
7.2
Alcune interrogazioni di esempio
Proponiamo, di seguito, alcune interrogazioni sull’ontologia, indicando poi
come il software le traduce, utilizzando le informazioni illustrate prima, in
interrogazioni per le sorgenti locali. In questa sede si è deciso di presentare
esclusivamente una parte della traduzione ottenuta, allo scopo di sottolineare
112
la particolarità che ciascun esempio mira a mettere in luce. Per l’output
completo del modulo di traduzione si rimanda all’appendice E.
L’interrogazione
select *
from Biography Biography_1,
artist artist_1,
Composer Composer_1,
Song Song_1,
Song Song_2
where
(Biography_1.author = ’Pietro martinelli’ and
Biography_1.artist = ’Ludwig van Beethoven’)
or
(artist_1.artName != ’Bono’ and
Composer_1.birthDate = artist_1.birthDate)
and
(Song_1.title != Song_2.title and
Song_1.length > Song_2.length and
Song_1.artist = Song_2.artist)
non genera per la sorgente ISLAND alcun risultato, mentre fornisce la
seguente traduzione per la sorgente VDP:
SELECT *
FROM Biografia Biography_1,
Artista artist_1,
Compositore Composer_1,
Brano Song_1,
Brano Song_2
WHERE ((((Biography_1.nomeAutore = ’Pietro Martinelli’)
AND
(Biography_1.artista = ’Ludwig van Beethoven’))
OR
((artist_1.soprannome != ’Bono’)
AND
(Composer_1.giornoNascita||Composer_1.meseNascita||
Composer_1.annoNascita = artist_1.giornoNascita||
artist_1.meseNascita||artist_1.annoNascita)))
AND
113
(((Song_1.titolo != Song_2.titolo)
AND
(Song_1.durata > Song_2.durata))
AND
(Song_1.autore = Song_2.autore)))
union
SELECT *
FROM Biografia Biography_1,
Artista artist_1,
Compositore Composer_1,
Brano Song_1,
Brano Song_2
WHERE ((((Biography_1.nomeAutore = ’Pietro Martinelli’)
AND
(Biography_1.artista = ’Ludwig van Beethoven’))
OR
((artist_1.nomignolo != ’Bono’)
AND
(Composer_1.giornoNascita||Composer_1.meseNascita||
Composer_1.annoNascita = artist_1.giornoNascita||
artist_1.meseNascita||artist_1.annoNascita)))
AND
(((Song_1.titolo != Song_2.titolo)
AND
(Song_1.durata > Song_2.durata))
AND
(Song_1.autore = Song_2.autore)))
Il primo fatto si spiega notando che la sorgente ISLAND (cosı̀ come la DG)
non prevede nelle sue interfacce locali alcun attributo corrispondente all’attributo artName del concetto artist (e dei concetti figli). In casi come questo,
si è deciso di non effettuare alcuna traduzione per la sorgente in questione. Altra scelta poteva essere quella di tradurre la condizione omettendo la
condizione sull’attributo intraducibile, tuttavia si è preferito garantire traduzioni che portino ad interrogazioni con risultati corretti piuttosto di lasciare
aperta la possibilità di ottenere risultati potenzialmente ma non necessariamente corretti. Per quanto riguarda invece la traduzione riportata sopra, è
interessante notare come essa sia costituita dall’unione (costrutto union di
OQL) di due sotto-interrogazioni. Questo è dovuto al fatto che l’attributo
artName del concetto artist non si mappa univocamente su un attributo di
un’interfaccia locale alla sorgente VDP, bensı̀ sull’alternativa tra due attributi
114
locali (soprannome e nomignolo) di una stessa interfaccia (Artista). Ricordiamo che questa doppia possibilità era esplicita nelle regole di mapping
espresse nello schema integrato.
Altrettanto interessante è l’esempio seguente: l’interrogazione
select *
from Biography Biography_1,
MusicalGoodsStore MusicalGoodsStore_1,
MusicalReview MusicalReview_1
where (Biography_1.author = ’Pietro Martinelli’ and
Biography_1.artist = ’Gioacchino Rossini’)
or (MusicalGoodsStore_1.IVA = ’1234567890’ and
not (MusicalGoodsStore_1.storeName = Biography_1.author))
and MusicalReview_1.location = ’via Branze n 38’
.Come accadeva per l’interrogazione precedente, coinvolge un attributo
(l’attributo IVA del concetto MusicalGoodsStore) che non si mappa su tutte
le sorgenti, bensı̀ solo su due di esse (EMI e VDP). Come prima, il processo di
traduzione non genera interrogazioni locali per le sorgenti per le quali non
esiste un mapping di tutti gli attributi coinvolti.
L’altro aspetto interessante di questa interrogazione consiste nel fatto
che uno stesso concetto, MusicalReview, si mappa su due diverse interfacce
locali alla stessa sorgente (SpettacoloMusicale e RassegnaMusicale per
la sorgente EMI, Spettacolo e Rassegna per la sorgente VDP). Anche in
questo caso, pertanto, il traduttore genera per la sorgente interessata una
interrogazione costituita dall’unione di due sotto-interrogazioni, ognuna delle
quali corrisponde ad una delle due possibilità di traduzione del concetto
MusicalReview. In particolare, la traduzione ottenuta per la sorgente EMI è
SELECT *
FROM Biografia Biography_1,
NegozioDiMusica MusicalGoodsStore_1,
SpettacoloMusicale MusicalReview_1
WHERE ((((Biography_1.autore = ’Pietro Martinelli’)
AND
(Biography_1.artista = ’Gioacchino Rossini’))
OR
((MusicalGoodsStore_1.pIva = ’1234567890’)
AND
NOT ((MusicalGoodsStore_1.nome = Biography_1.autore))))
AND
115
(MusicalReview_1.luogo = ’via Branze n 38’))
union
SELECT *
FROM Biografia Biography_1,
NegozioDiMusica MusicalGoodsStore_1,
RassegnaMusicale MusicalReview_1
WHERE ((((Biography_1.autore = ’Pietro Martinelli’)
AND
(Biography_1.artista = ’Gioacchino Rossini’))
OR
((MusicalGoodsStore_1.pIva = ’1234567890’)
AND
NOT ((MusicalGoodsStore_1.nome = Biography_1.autore))))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
Infine, presentiamo un caso di interrogazione che, per una data sorgente,
origina una traduzione composta dall’unione di quattro sotto-interrogazioni.
In pratica, quest’ultima interrogazione riunisce le casistiche discusse separatamente alle pagine 114 e 115: per quanto riguarda la sorgente VDP, infatti,
esistono due possibili mapping per il concetto MusicalReview, e due possibili
mapping per l’attributo artName del concetto artist. La traduzione ottenuta dunque coinvolge tante sotto-interrogazioni quante sono le combinazioni
possibili di tali scelte.
Presentiamo ora l’interrogazione
select *
from Biography Biography_1,
MusicalGoodsStore MusicalGoodsStore_1,
MusicalReview MusicalReview_1,
artist artist_1
where ((Biography_1.author = Biography_1.artist)
or not (MusicalGoodsStore_1.storeName = Biography_1.author))
and MusicalReview_1.location = ’via Branze n 38’
and (artist_1.birthDate = ’19/03/1978’ or
not artist_1.name = artist_1.artName)
e la traduzione per la sorgente VDP ottenuta applicando il nostro software
SELECT *
116
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Spettacolo MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.giornoNascita||artist_1.meseNascita||
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.soprannome))))
union
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Rassegna MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.giornoNascita||artist_1.meseNascita||
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.soprannome))))
union
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Spettacolo MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
117
AND
((artist_1.giornoNascita||artist_1.meseNascita||
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.nomignolo))))
union
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Rassegna MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.giornoNascita||artist_1.meseNascita||
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.nomignolo))))
118
Capitolo 8
Conclusioni e sviluppi futuri
La presente tesi ha portato allo sviluppo di un modello di interrogazione di
ontologie, ed alla realizzazione di strumenti per la navigazione della struttura dei concetti e per la scrittura di query su modelli ontologici. In questo
lavoro ci si è inoltre occupati di risolvere il problema della riformulazione
di interrogazioni poste sull’ontologia in interrogazioni sulle sorgenti locali.
All’analisi dei linguaggi logici usati per descrivere il mapping tra i due diversi livelli, dunque, sono seguiti lo sviluppo di un formalismo concettuale per
la rappresentazione delle regole di mapping, il progetto di un algoritmo di
traduzione e l’implementazione di tale algoritmo in un modulo software per
l’interrogazione di ontologie nell’ambito dell’ambiente di strumenti Artemis.
In tal modo si fornisce ad un utente un’interfaccia grafica amichevole che
rende possibile osservare le caratteristiche intensionali di un dominio informativo, nonchè realizzare interrogazioni sull’ontologia allo scopo di ottenerne
informazioni estensionali, ottenendo come risultato un insieme di interrogazioni da sottomettere alle diverse sorgenti d’informazioni che l’ontologia integra. In particolare, si è visto che tale risultato viene raggiunto in due passi:
prima di tutto, il modulo grafico di interrogazione permette di comporre una
query sull’ontologia, imponendo condizioni su concetti ed attributi, senza che
l’utente debba necessariamente conoscere la sintassi di OQL. In un secondo
momento, il modulo di traduzione, basandosi sulle relazioni di mapping tra i
diversi livelli dell’ontologia, fa sı̀ che tale query sia riscritta mediante la terminologia delle diverse sorgenti, nascondendo all’utente la natura eterogenea
e distribuita di tali sorgenti e la complessità delle corrispondenze tra sorgenti
e modello integrato.
Un possibile sviluppo del presente lavoro consiste nella gestione dell’effettiva sottomissione delle query tradotte alle sorgenti locali, e soprattutto dei
risultati che ogni singola sorgente restituisce: si tratta dunque di utilizzare
le tabelle di traduzione rese disponibili dal nostro modulo, per ricondurre le
119
informazioni ottenute dalla terminologia delle sorgenti alla terminologia del
modello ontologico.
Un’altra questione da affrontare, in un lavoro successivo, può essere quella
dell’ottimizzazione del processo di traduzione delle interrogazioni; ad esempio
si potrebbe pensare di modificare l’algoritmo di traduzione allo scopo di
valutare se particolari sotto-condizioni della query, ad esempio quelle che
coinvolgono attributi che si mappano su costanti, possano essere a priori
scartate o, al contrario, vincolino in partenza il risultato dell’interrogazione
sulla relativa sorgente. D’altra parte, è possibile ipotizzare di modificare la
politica di gestione delle situazioni di mapping impossibile su una particolare
sorgente, o su una particolare interfaccia locale. Il nostro algoritmo, in casi
come questo, decide che la traduzione corrente è priva di senso, e la elimina; si
può tuttavia pensare ad una diversa politica di gestione di queste situazioni,
che ad esempio generi riscritture dell’interrogazione di partenza prive delle
condizioni sugli attributi intraducibili, e fornisca la possibilità di valutare
in un secondo momento, eventualmente in modo interattivo, la correttezza
di risultati ottenuti sottomettendo alle sorgenti d’informazioni una query
semplificata.
Infine, un altro possibile sviluppo futuro di questo lavoro può consistere
nella realizzazione di un’interfaccia di navigazione dell’ontologia diversa da
quella proposta da noi, e che ad esempio adotti, come suggerito in 5.3, un approccio basato sulla geometria iperbolica. Come dettagliatamente illustrato
nell’Appendice D, l’architettura che si è sviluppata per il modulo grafico è
rivolta a rendere fattibili modifiche di questo genere in modo il più possibile
indolore.
120
Appendice A
Sintassi completa di ODLI 3
OdlSpecification
::= Definition PUNTO
| Definition PUNTOEVIRGOLA
| Definition PUNTOEVIRGOLA OdlSpecification
Definition
::= TypeDcl
| ConstDcl
| ExceptDcl
| Interface
| RuleDcl
| ExtRuleDcl
| ThesaurusRelation
| Module
| error
TypeDcl
::= TYPEDEF TypeDeclarator
| ConstrTypeSpec
TypeDeclarator
::= TypeSpec Declarators
Declarators
::= Declarator
| Declarators VIRGOLA Declarator
121
Declarator
::= IDENTIFIER
| IDENTIFIER ArraySizeList
ArraySizeList
::= FixedArraySize
| ArraySizeList FixedArraySize
TypeSpec
::= SimpleTypeSpec
| ConstrTypeSpec
SimpleTypeSpec
::= BaseTypeSpec
| TemplateTypeSpec
| IDENTIFIER
BaseTypeSpec
::= FloatingPtType
| IntegerType
| CharType
| BooleanType
| OctetType
| RangeType
| AnyType
FloatingPtType
::= FLOAT
| DOUBLE
IntegerType
::= LongIntType
| SHORT
| UNSIGNED LONG
| UNSIGNED SHORT
LongIntType
::= INTEGER
| INT
| LONG
122
CharType
::= CHAR
BooleanType
::= BOOLEAN
OctetType
::= OCTET
RangeType
::= RANGE APERTAGRAFFA RangeSpecifier CHIUSAGRAFFA
RangeSpecifier
::= SignedIntegerLiteral VIRGOLA SignedIntegerLiteral
| SignedIntegerLiteral VIRGOLA PIU INFINITE
| MENO INFINITE VIRGOLA SignedIntegerLiteral
AnyType
::= ANY
TemplateTypeSpec
::= ArrayType
| StringType
| CollectionType
ArrayType
::= ARRAY ANGOLOSINISTRO SimpleTypeSpec VIRGOLA INTEGER_LITERAL
ANGOLODESTRO
| ARRAY ANGOLOSINISTRO SimpleTypeSpec ANGOLODESTRO SEQUENCE
ANGOLOSINISTRO SimpleTypeSpec VIRGOLA
INTEGER_LITERAL ANGOLODESTRO
StringType
::= STRING ANGOLOSINISTRO INTEGER_LITERAL ANGOLODESTRO
| STRING
CollectionType
::= AttrCollectionSpecifier ANGOLOSINISTRO SimpleTypeSpec
ANGOLODESTRO
AttrCollectionSpecifier
123
::= SET
| LIST
| BAG
ConstrTypeSpec
::= StructType
| UnionType
| EnumType
StructType
::= STRUCT IDENTIFIER APERTAGRAFFA MemberList CHIUSAGRAFFA
MemberList
::= Member
| MemberList Member
Member
::= TypeSpec Declarators PUNTOEVIRGOLA
UnionType
::= UNION IDENTIFIER SWITCH APERTATONDA SwitchTypeSpec CHIUSATONDA
APERTAGRAFFA SwitchBody CHIUSAGRAFFA
SwitchTypeSpec
::= IntegerType
| CharType
| BooleanType
| EnumType
| ScopedName
| RangeType
SwitchBody
::= Case
| Case SwitchBody
Case
::= CaseLabelList ElementSpec PUNTOEVIRGOLA
CaseLabelList
::= CaseLabel
| CaseLabel CaseLabelList
124
CaseLabel
::= CASE ConstExp DUEPUNTI
| DEFAULT DUEPUNTI
ElementSpec
::= TypeSpec Declarator
EnumType
::= ENUM IDENTIFIER APERTAGRAFFA EnumeratorList CHIUSAGRAFFA
EnumeratorList
::= Enumerator
| EnumeratorList VIRGOLA Enumerator
Enumerator
::= IDENTIFIER
ConstExp
::= OrExpr
OrExpr
::= XOrExpr
| OrExpr OR XOrExpr
XOrExpr
::= AndExpr
| XOrExpr PAGODA AndExpr
AndExpr
::= ShiftExpr
| AndExpr ECOMMERCIALE ShiftExpr
ShiftExpr
::= AddExpr
| ShiftExpr MAGGIOREMAGGIORE AddExpr
| ShiftExpr MINOREMINORE AddExpr
AddExpr
::= MultExpr
| AddExpr PIU MultExpr
125
| AddExpr MENO MultExpr
MultExpr
::= UnaryExpr
| MultExpr PER UnaryExpr
| MultExpr SLASH UnaryExpr
| MultExpr BACKSLASH PERCENTUALE UnaryExpr
UnaryExpr
::= Signes PrimaryExpr
| PrimaryExpr
PrimaryExpr
::= IDENTIFIER
| INTEGER_LITERAL
| FLOATING_PT_LITERAL
| APERTATONDA OrExpr CHIUSATONDA
| APERTATONDA error CHIUSATONDA
ConstDcl
::= CONST StringType IDENTIFIER UGUALE STRING_LITERAL
| CONST CharType IDENTIFIER UGUALE CHARACTER_LITERAL
| CONST IntegerType IDENTIFIER UGUALE ConstExp
| CONST FloatingPtType IDENTIFIER UGUALE ConstExp
SignedIntegerLiteral
::= INTEGER_LITERAL
| Signes INTEGER_LITERAL
SignedFloatingPtLiteral
::= Signes FLOATING_PT_LITERAL
| FLOATING_PT_LITERAL
Signes
::= MENO
| PIU
ExceptDcl
::= EXCEPTION IDENTIFIER APERTAGRAFFA OptMemberList CHIUSAGRAFFA
OptMemberList
126
::=
| MemberList
ScopedName
::= IDENTIFIER
| DUEPUNTI DUEPUNTI IDENTIFIER
| ScopedName DUEPUNTI DUEPUNTI IDENTIFIER
Interface
::= InterfaceDcl
IntView
::= INTERFACE
| VIEW
InterfaceDcl
::= IntView IDENTIFIER DUEPUNTI InheritanceSpec
OptTypePropertyList OptPersistenceDcl SingleInterfaceBody
| IntView IDENTIFIER DUEPUNTI InheritanceSpec OptTypePropertyList
OptPersistenceDcl
SingleInterfaceBody InterfaceBodyUnionList
| IntView IDENTIFIER OptTypePropertyList OptPersistenceDcl
SingleInterfaceBody
| IntView IDENTIFIER OptTypePropertyList OptPersistenceDcl
SingleInterfaceBody InterfaceBodyUnionList
InheritanceSpec
::= IDENTIFIER
| InheritanceSpec VIRGOLA IDENTIFIER
OptTypePropertyList
::=
| APERTATONDA OptSourceSpec OptExtentSpec OptKeySpec OptCandKeySpec
OptForKeySpec CHIUSATONDA
OptSourceSpec
::=
| SOURCE SourceType IDENTIFIER
SourceType
::= RELATIONAL
127
|
|
|
|
NFRELATIONAL
OBJECT
FILE
SEMISTRUCTURED
OptExtentSpec
::=
| EXTENT ListExtent
ListExtent
::= IDENTIFIER
| ListExtent VIRGOLA IDENTIFIER
OptKeySpec
::=
| KEY Key
OptCandKeySpec
::=
| CandKeySpecList
CandKeySpecList
::= CandKeySpec
| CandKeySpecList CandKeySpec
CandKeySpec
::= CANDIDATE_KEY IDENTIFIER Key
OptForKeySpec
::=
| ForKeySpecList
ForKeySpecList
::= ForKeySpec
| ForKeySpecList ForKeySpec
ForKeySpec
::= FOREIGN_KEY APERTATONDA ForeignKeyList CHIUSATONDA
REFERENCES IDENTIFIER OptRefKeyList
OptRefKeyList
128
::=
| APERTATONDA ForeignKeyList CHIUSATONDA
ForeignKeyList
::= IDENTIFIER
| ForeignKeyList VIRGOLA IDENTIFIER
Key
::= APERTATONDA PropertyList CHIUSATONDA
PropertyList
::= PropertyName
| PropertyList VIRGOLA PropertyName
PropertyName
::= IDENTIFIER
OptPersistenceDcl
::=
| PERSISTENT
| TRANSIENT
InterfaceBodyUnionList
::= InterfaceBodyUnion
| InterfaceBodyUnionList InterfaceBodyUnion
InterfaceBodyUnion
::= UNION IDENTIFIER SingleInterfaceBody
SingleInterfaceBody
::= APERTAGRAFFA InterfaceBody CHIUSAGRAFFA
InterfaceBody
::= Export PUNTOEVIRGOLA
| Export PUNTOEVIRGOLA InterfaceBody
Export
::= TypeDcl
| ConstDcl
| ExceptDcl
| AttrDcl
129
| RelDcl
| OpDcl
AttrDcl
::= OptReadonly ATTRIBUTE DomainType AttributeName
OptFixedArraySize OptMappingRuleDcl
OptReadonly
::=
| READONLY
AttributeName
::= IDENTIFIER
| IDENTIFIER PUNTODIDOMANDA
DomainType
::= EnumType
| StructType
| SimpleTypeSpec
OptFixedArraySize
::=
| FixedArraySize
FixedArraySize
::= APERTAQUADRA INTEGER_LITERAL CHIUSAQUADRA
OptMappingRuleDcl
::=
| MappingRuleDcl
MappingRuleDcl
::= MAPPING RULE MapRuleList
MapRuleList
::= MapRule
| MapRuleList VIRGOLA MapRule
MapRule
::= LocalAttributeName
| DefaultValue
130
| MapAndExpression
| MapUnionExpression
LocalAttributeName
::= IDENTIFIER PUNTO IDENTIFIER PUNTO IDENTIFIER
LocalClassName
::= IDENTIFIER VIRGOLA IDENTIFIER
DefaultValue
::= IDENTIFIER PUNTO IDENTIFIER UGUALE STRING_LITERAL
MapAndExpression
::= APERTATONDA MapAndList AND LocalAttributeName CHIUSATONDA
MapAndList
::= LocalAttributeName
| MapAndList AND LocalAttributeName
MapUnionExpression
::= APERTATONDA MapUnionList UNION LocalAttributeName
ON IDENTIFIER CHIUSATONDA
MapUnionList
::= LocalAttributeName
| MapUnionList UNION LocalAttributeName
RelDcl
::= RELATIONSHIP TargetOfPath IDENTIFIER INVERSE
InverseTraversalPath OptOrderBy
TargetOfPath
::= IDENTIFIER
| RelCollectionType MINOREMINORE IDENTIFIER MAGGIOREMAGGIORE
RelCollectionType
::= SET
| LIST
InverseTraversalPath
::= IDENTIFIER DUEPUNTI DUEPUNTI IDENTIFIER
131
OptOrderBy
::=
| APERTAGRAFFA ORDER_BY ScopedNameList CHIUSAGRAFFA
ScopedNameList
::= ScopedName
| ScopedNameList VIRGOLA ScopedName
OpDcl
::= OptOneway OperTypeSpec IDENTIFIER ParameterDcls
OptRaisesExpr OptContextExpr
OptOneway
::=
| ONEWAY
OperTypeSpec
::= SimpleTypeSpec
| VOID
ParameterDcls
::= APERTATONDA ParamDclList CHIUSATONDA
| APERTATONDA CHIUSATONDA
ParamDclList
::= ParamDcl
| ParamDclList VIRGOLA ParamDcl
ParamDcl
::= ParamAttribute SimpleTypeSpec Declarator
ParamAttribute
::=
| IN
| OUT
| INOUT
OptRaisesExpr
::=
| RAISES APERTATONDA ScopedNameList CHIUSATONDA
132
OptContextExpr
::=
| CONTEXT APERTATONDA StringLiteralList CHIUSATONDA
StringLiteralList
::= STRING_LITERAL
| StringLiteralList VIRGOLA STRING_LITERAL
ExtRuleDcl
::= EXTRULE IDENTIFIER ExtRuleSpec
ExtRuleSpec
::= ForAll IDENTIFIER IN ExtRuleType
ExtRuleType
::= ExtRuleIsa
| ExtRuleBottom
ExtRuleBottom
::= APERTATONDA LocalClassName AND LocalClassName
CHIUSATONDA THEN IDENTIFIER IN BOTTOM
ExtRuleIsa
::= LocalClassName THEN IDENTIFIER IN LocalClassName
RuleDcl
::= RULE IDENTIFIER RuleSpec
RuleSpec
::= ForAll IDENTIFIER IN IDENTIFIER DUEPUNTI
RuleBodyList THEN RuleBodyList
| APERTAGRAFFA CASE OF IDENTIFIER DUEPUNTI CaseList
CHIUSAGRAFFA
ForAll
::= FOR ALL
| FORALL
RuleBodyList
::= APERTATONDA RuleBodyList CHIUSATONDA
133
| RuleBody
| RuleBodyList AND RuleBody
RuleBody
::= DottedName RuleConstOp OptRuleCast LiteralValue DottedName
RuleConstOp OptRuleCast DottedName
| DottedName IN DottedName
| ForAll IDENTIFIER IN DottedName DUEPUNTI RuleBodyList
| EXISTS IDENTIFIER IN DottedName DUEPUNTI RuleBodyList
| DottedName UGUALE SimpleTypeSpec IDENTIFIER APERTATONDA
DottedLiteralList CHIUSATONDA
DottedLiteralList
::= DottedLiteral
| DottedLiteralList VIRGOLA DottedLiteral
DottedLiteral
::= OptSimpleTypeSpec DottedName
| OptSimpleTypeSpec LiteralValue
OptSimpleTypeSpec
::=
| SimpleTypeSpec
RuleConstOp
::= UGUALE
| MAGGIORE UGUALE
| MINORE UGUALE
| MINORE
| MAGGIORE
LiteralValue
::= SignedFloatingPtLiteral
| SignedIntegerLiteral
| CHARACTER_LITERAL
| STRING_LITERAL
DottedName
::= IDENTIFIER
| DottedName PUNTO IDENTIFIER
134
OptRuleCast
::=
| APERTAGRAFFA SimpleTypeSpec CHIUSAGRAFFA
CaseList
::= CaseSpec
| CaseList CaseSpec
CaseSpec
::= LiteralValue DUEPUNTI DottedName
ThesaurusRelation
::= LocalAttributeName ThesRelType LocalAttributeName
| LocalClassName ThesRelType LocalClassName
| LocalClassName ThesRelType LocalAttributeName
| LocalAttributeName ThesRelType LocalClassName
ThesRelType
::= SYN
| BT
| NT
| RT
Module
::= MODULE IDENTIFIER APERTAGRAFFA OdlSpecification CHIUSAGRAFFA
135
Appendice B
Sintassi completa di OQL Object Query Language
query_program ::= {define_query;} query
define_query ::= define identifier as query
query
query
query
query
query
query
query
query
query
query
query
query
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
::=
nil
true
false
integer_literal
float_literal
character_literal
string_literal
entry_name
query_name
bind_argument
from_variable_name
(query)
query
query
query
query
query
query
query
query
::=
::=
::=
::=
::=
::=
::=
::=
query + query
query - query
query * query
query / query
- query
query mod query
abs (query)
query verb+||+ query
query ::= query comparison_operator query
136
query ::= query like string_literal
comparison_operator ::= =
comparison_operator ::= !=
comparison_operator ::= >
comparison_operator ::= <
comparison_operator ::= >=
comparison_operator ::= <=
query ::= not query
query ::= query and query
query ::= query or query
query
query
query
query
query
query
query
query
query
::=
::=
::=
::=
::=
::=
::=
::=
::=
query ::=
query ::=
query ::=
query ::=
dot ::= .
query ::=
query ::=
query ::=
query ::=
query ::=
query ::=
type_name ( [query ] )
type_name (identifier:query {, identifier: query})
struct (identifier: query {, identifier: query})
set ( [query {, query} ])
bag ( [query {,query} ])
list ( [query {,query} ])
(query, query {, query})
[ list ](query .. query)
array ( [query {,query} ])
query dot attribute_name
query dot relationship_name
query dot operation_name
query dot operation_name( query {,query} )
| ->
* query
query [query]
query [query:query]
first (query)
last (query)
function_name( [ query {,query} ] )
query ::= for all identifier in query: query
query ::= exists identifier in query: query
query ::= exists(query)
query ::= unique(query)
query ::= query in query
query ::= query comparison_operator quantifier query
quantifier ::= some
137
quantifier ::= any
quantifier ::= all
query ::= count (query)
query ::= count (*)
query ::= sum (query)
query ::= min (query)
query ::= max (query)
query ::= avg (query)
query ::= select [ distinct ] projection_attributes
from variable_declaration {, variable_declaration}
[where query ]
[group by partition_attributes ]
[having query ]
[order by sort_criterion {, sort_criterion} ]
projection_attributes ::= projection {, projection}
projection_attributes ::= *
projection ::= query
projection ::= identifier: query
projection ::= query as identifier
variable_declaration ::= query [ [ as ] identifier ]
partition_attributes ::= projection {, projection}
sort_criterion ::= query [ordering ]
ordering ::= asc
ordering ::= desc
query ::= query intersect query
query ::= query union query
query ::= query except query
query
query
query
query
query
::=
::=
::=
::=
::=
listtoset (query)
element (query)
distinct(e)
flatten (query)
(class_name) query
138
Appendice C
La tecnologia CORBA
CORBA è l’acronimo di Common Object request Broker Architecture. Esso rappresenta un insieme di specifiche e di regole di comportamento
un’architettura appunto, messo a punto dall’OMG [2] allo scopo di rendere
possibile lo sviluppo di sistemi in ambiente eterogeneo e distribuito.
In particolare, CORBA descrive e rende possibile la comunicazione tra
oggetti distribuiti su piattaforme distanti e in generale diverse, indipendentemente dai linguaggi di programmazione utilizzati per realizzare i singoli
oggetti. Ad esempio, un’architettura di questo genere permette a programmi
scritti in Java di comunicare con programmi scritti in linguaggi come Fortran, Cobol o C++, permettendo il riutilizzo di software scritto in linguaggi
di programmazione ora poco utilizzati.
La figura C.1 rappresenta uno schema generale dell’architettura CORBA.
L’elemento centrale di tale architettura è l’ORB (Object Request Broker),
servizio che svolge il ruolo di mediatore tra i diversi oggetti remoti. Esso è
dunque l’entità logica che realizza la comunicazione remota, nascondendone i dettagli implementativi, con il risultato di rendere tale comunicazione
analoga a chiamate locali. In particolare, in presenza di una richiesta di comunicazione da parte di un oggetto chiamante verso un altro oggetto, l’ORB
svolge i seguenti compiti:
1. Trovare, in rete, l’oggetto chiamato
2. Inviargli la richiesta dell’oggetto chiamante
3. Attendere il risultato della chiamata e farlo pervenire all’oggetto chiamante
Come abbiamo detto, CORBA è un’architettura, e non un sistema. Pertanto, ORB è un elemento logico, che può essere definito mediante un linguaggio di programmazione qualunque. Per questo motivo, l’OMG definisce
139
Figura C.1: CORBA e l’ORB
l’ORB mediante un’interfaccia astratta (ORB interface) senza addentrarsi
nei dettagli implementativi.
L’ORB, abbiamo visto, si occupa dell’individuazione dell’oggetto remoto
chiamato in rete, e della comunicazione tra chiamante e chiamato, senza che
di questo si debba preoccupare l’oggetto cliente (chiamante).
Questa separazione di ruoli è possibile grazie al fatto che le interfacce di
tutti gli oggetti che comunicano tramite l’ORB sono descritte per mezzo di
un formalismo comune, detto IDL (Interface Definition Language). In
particolare, il compilatore IDL per un dato linguaggio di programmazione si
preoccupa di tradurre una descrizione IDL dell’interfaccia di un certo oggetto
CORBA in una definizione di tale interfaccia nel linguaggio di programmazione per il quale il compilatore è stato costruito, che naturalmente corrisponde
a quello in cui l’oggetto CORBA verrà effettivamente implementato. La filosofia di fondo dell’architettura CORBA consiste nella netta separazione tra
interfaccia di un oggetto CORBA ed effettiva implementazione sottostante: la definizione IDL dell’interfaccia di un oggetto permette pertanto di
specificare esclusivamente gli aspetti relativi all’interfaccia dell’oggetto, vale
a dire segnature dei metodi ed eventuali eccezioni rilanciate, collocazione in
package, costanti e strutture dati utilizzate dai metodi.
Descriviamo ora come avviene, in pratica, l’invocazione dei servivi CORBA.
Nella figura C.3, il servant rappresenta l’implementazione dell’oggetto
remoto, ovvero la specifica mediante un linguaggio di programmazione dei
metodi definiti dall’interfaccia ODL dell’oggetto remoto. Il client, invece,
140
Figura C.2: CORBA: comunicazione tra client e server
Figura C.3: CORBA: invocazione remota di metodi
141
rappresenta l’oggetto che invoca i metodi del servant, senza doversi preoccupare dei dettagli della comunicazione con l’oggetto remoto. Sottolineiamo
come esista una differenza (C.3) tra servant e Server: il primo rappresenta
un’istanza di un oggetto CORBA, mentre il secondo è il processo che istanzia
il servant e lo mette a disposizione del client.
Con riferimento all’immagine C.2, vediamo ora di chiarire come avviene
la comunicazione tra client e servant, ed in particolare come vengono
risolti i problemi relativi al passaggio di parametri dal primo al secondo, e
dei risultati in senso inverso.
Ogni oggetto client deve essere dotato di uno stub, ed ogni oggetto
server di uno skeleton. Stub e skeleton fungono da intermediari, rispettivamente, tra client ed ORB e tra server ed ORB. Di fatto, il client invia
la richiesta di comunicazione al proprio stub, che effettua la traduzione dal
linguaggio di programmazione client-side ad un generico formato CORBA,
ed effettua quindi la richiesta remota. Sul lato server, invece, avvengono
le operazioni inverse, ovvero lo skeleton riceve la richiesta remota, effettua
la traduzione da formato generico CORBA al linguaggio di programmazione
server-side.
Il client richiama i metodi di un oggetto remoto servant mediante
un object reference fornito dal server. Lo stub identifica tramite l’ORB
la macchina remota sulla quale è presente il server che gestisce l’oggetto
remoto di cui si desiderano invocare i metodi. Si stabilisce la connessione
con tale macchina e si spedisce la richiesta completa di eventuali parametri
per la chiamata del metodo remoto. Lo skeleton invoca il metodo sul servant
e restituisce, sempre tramite l’ORB, i risultati al client.
Il procedimento di “impacchettamento” dei dati da trasmettere in un
formato CORBA generico, che astrae dai formati specifici dei linguaggi di
programmazione mediante i quali sono implementati gli oggetti CORBA,
prende il nome di marshaling, mentre il recupero di tali dati prende il nome
di unmarshaling.
Per completare la panoramica sull’architettura mostrata in figura C.1,
la Dynamic Invocation Interface (DII) è un’interfaccia che permette al
client di inviare dinamicamente una richiesta alloggetto remoto senza conoscerne linterfaccia e senza avere un legame con lo stub; la Dynamic Skeleton Interface (DSI) è l’analogo dal lato server; infine, l’Object Adapter assiste l’ORB nel far pervenire la richiesta in un formato valido e nelle
operazioni di attivazione/disattivazione degli oggetti.
142
Appendice D
Architettura dell’interfaccia
grafica
Questa appendice non intende descrivere in maniera dettagliata i dettagli
implementativi del modulo che realizza l’interfaccia grafica di navigazione
dell’ontologia e di composizione di interrogazioni, bensı̀ illustrare le scelte
architetturali adottate allo scopo di rendere possibile modificare parti di tale
interfaccia in modo semplice e modulare.
Concettualmente, l’interfaccia grafica di nostro interesse è costituita da
tre parti diverse:
• un modulo che permette di visualizzare l’ontologia (vale a dire l’insieme
dei concetti dell’ontologia e le relazioni che intercorrono tra di essi)
• un modulo che permette di visualizzare la struttura di un concetto, vale
a dire l’insieme dei suoi attributi e dei loro tipi
• un modulo che permette di comporre un’interrogazione sui concetti
dell’ontologia
Allo scopo di organizzare e coordinare i tre moduli individuati, si è deciso
di pensare ad un’architettura che permetta di modificare una delle tre parti
indipendentemente dalle altre, allo scopo di scegliere separatamente il tipo
di implementazione da realizzare per ciascun modulo, senza che questa scelta
vincoli in qualche modo le scelte realizzative degli altri moduli.
143
FrameInterrogazione
-ontologyManager: OntologyLayoutManager
-conceptManager: ConceptLayoutManager
-queryManager: QueryCompositionManager
+FrameInterrogazione(queryManager: QueryCompositionManager, conceptManager: ConceptLayoutManager, ontologyManager: OntologyLayoutManager): void
OntologyLayoutManager
QueryCompositionManager
-observerList: Vector
-observerList: Vector
+addObserver(observer: OntologyLayoutManagerObserver): void
+notifyAllObserver(mode: int): void
+addObserver(observer: QueryCompositionManagerObserver): void
+getSelectedConcept(): Concept
+notifyAllObserver(): void
+setOntology(onto: Ontology): void
+getComposedQuery(): String
144
ConceptLayoutManager
-observerList: Vector
1..*
+addObserver(observer: ConceptLayoutManagerObserver): void
+notifyAllObserver(): void
<<Interface>>
+getSelectedAttribute(): Attribute
QueryCompositionManagerObserver
1..*
1..*
<<Interface>>
OntologyLayoutManagerObserver
+newSelectedConcept(source: OntologyLayoutManager, mode: int): void
<<Interface>>
ConceptLayoutManagerObserver
+newSelectedAttribute(source: ConceptLayoutManager): void
Figura D.1: Architettura dell’interfaccia grafica - Diagramma delle classi
Cosı̀ l’interfaccia nel suo complesso è implementata in una classe contenitore, denominata FrameInterrogazione, costruita sulla base dei tre moduli
necessari allo svolgimento delle tre diverse funzioni. In particolare, tali moduli vengono rappresentati da tre classi astratte, denominate OntologyLayoutManager, ConceptLayoutManager e QueryCompositionManager. Le effettive
implementazioni dei tre moduli, come quelle proposte nell’interfaccia realizzata, sono pertanto ottenute estendendo le tre classi astratte citate, mentre
la classe contenitore FrameInterrogazione può risultare indipendente dall’effettiva scelta effettuata in fase di realizzazione dei singoli moduli. Si tenga
presente, per inciso, che il gestore della presentazione di ontologie e concetti
è pensato per essere un pannello con contenuto scrollabile, mentre il gestore
della composizione di interrogazioni è semplicemente un pannello.
Volendo garantire la massima intercambiabilità tra i moduli che realizzano
l’interfaccia si è dovuto affrontare il problema di fornire un meccanismo di comunicazione tra tali moduli, dal momento che la presentazione degli attributi
di un concetto varia a seconda del concetto selezionato sulla rappresentazione dell’ontologia, e che la composizione dell’interrogazione (ed in particolare
la scelta delle variabili della query) non può in generale prescindere dalle
selezioni effettuate sui due moduli di rappresentazione.
Seguendo il design pattern noto come Observer, si è pertanto realizzato un
meccanismo di notifica degli eventi di selezione su OntologyLayoutManager
e ConceptLayoutManager ad osservatori registrati per tali Manager. Per
completezza, e per supportare anche eventuali necessità di reazione alle operazioni effettuate dall’utente sulla sezione di composizione di interrogazioni, si è esteso tale meccanismo di registrazione e notifica anche al caso del
QueryCompositionManager.
Allo scopo di realizzare tale architettura di comunicazione tra moduli, si
sono realizzate tre interfacce, indicate come OntologyLayoutManagerObserver,
ConceptLayoutManagerObserver e QueryCompositionManagerObserver. In
particolare, ogni ConceptLayoutManager deve implementare l’interfaccia OntologyLayoutManagerObserver, mentre ogni QueryCompositionManager deve implementare le interfacce OntologyLayoutManagerObserver e ConceptLayoutManagerObserver. Tali dettagli sono chiariti dalla figura D.1.
Per maggiore chiarezza, vediamo nel dettaglio il funzionamento di tale
meccanismo su un semplice esempio.
Il Design pattern Observer
Classe di cui osservare il comportamento: supporta un meccanismo di
registrazione degli osservatori.
class ToObserve
145
{
private Vector observerList;
/*
...
*/
/**
Metodo di registrazione degli osservatori
*/
public addObserver(Observer observer)
{
observerList.addElement(observer);
}
/**
Metodo di notifica agli osservatori degli eventi
dell’oggetto osservato
Tale metodo viene invocato, ad esempi, dal codice
che rileva e gestisce gli eventi del mouse o della
tastiera sull’oggetto osservato
*/
public notifyAll()
{
for all observer in observerList
observer.changeDetected(this);
}
/**
Metodo mediante il quale gli osservatori possono
accedere allo stato dell’oggetto osservato
*/
public getState()
{
/*
...
*/
}
}
146
Classe Observer: riceve la notifica dei cambiamenti di stato dell’oggetto
osservato, accede al nuovo stato di tale oggetto e lo elabora
class Observer
{
/**
Metodo invocato dall’oggetto osservato per notificare il
cambiamento di stato
*/
public changeDetected(ToObserve source)
{
/*
Accede al nuovo stato della sorgente della notifica
*/
newState = source.getState();
/*
Fa qualcosa con il nuovo stato
*/
startElaborationOf(newState);
}
}
147
Appendice E
Codice completo degli esempi
E.1
Codice completo dell’ontologia utilizzata
negli esempi
// Ontologia in ODLI3
interface Biography
{
attribute string author;
attribute date publishingDate;
attribute artist artist;
};
interface artist
{
attribute string name;
attribute string artName*;
attribute date birthDate;
attribute set<AlbumType>Album;
};
interface Singer:SongSingerWriter
{
attribute activity_Singer activity;
};
interface Composer:SongSingerWriter
148
{
attribute activity_Composer activity;
};
interface SongSingerWriter:artist
{
attribute activity_SongSingerWriter activity;
};
interface AlbumType
{
attribute string title;
attribute integer year;
attribute string kind;
attribute integer soldCopies;
attribute set<Song> Song;
attribute artist artist*;
};
interface Song
{
attribute string title;
attribute decimal length;
attribute string kind*;
attribute integer soldCopies*;
attribute artist artist*;
};
interface MusicalClassification
{
attribute string week;
attribute set<string> sponsor;
attribute set<AlbumType>Album;
attribute set<Song> Song;
};
interface TopTenAlbum:AlbumType
{
attribute position_TopTenAlbum position;
attribute integer lastPosition*;
attribute artist artist;
149
};
interface TopTenSong:Song
{
attribute string kind;
attribute integer soldCopies;
attribute position_TopTenSong position;
attribute integer lastPosition*;
attribute artist artist;
};
interface MusicalReview
{
attribute date day;
attribute string location;
attribute MusicalGroup MusicalGroup;
};
interface MusicalGroup
{
attribute string name;
attribute string director;
attribute set<string> components;
attribute set<Song> Song;
};
interface Band:MusicalGroup
{
attribute groupType_Band groupType;
};
interface Chorus:MusicalGroup
{
attribute groupType_Chorus groupType;
};
interface Orchestra:MusicalGroup
{
attribute groupType_Orchestra groupType;
};
150
interface MusicalInstrumentCatalog
{
attribute date publishingDate;
attribute string shopName;
attribute set<InstrumentCategory> InstrumentCategory*;
attribute set<MusicalInstrument> MusicalInstrument*;
};
interface InstrumentCategory
{
attribute CategoryType_InstrumentCategory CategoryType;
attribute set<MusicalInstrument> MusicalInstrument;
};
interface MusicalInstrument
{
attribute integer catalogCode*;
attribute string instrumentType;
attribute decimal price;
attribute string seller;
attribute string payment;
};
interface WindInstrument:MusicalInstrument
{
attribute integer catalogCode;
attribute instrumentType_WindInstrument instrumentType;
};
interface PercussionInstrument:MusicalInstrument
{
attribute integer catalogCode;
attribute instrumentType_PercussionInstrument instrumentType;
};
interface StringedInstrument:MusicalInstrument
{
attribute integer catalogCode;
attribute instrumentType_StringedInstrument instrumentType;
};
151
interface MusicalGoodsStore
{
attribute string storeName;
attribute string IVA;
attribute InstrumentCatalog InstrumentCatalog;
attribute SheetCatalog SheetCatalog;
attribute BookCatalog BookCatalog;
};
interface SheetCatalog
{
attribute date publishingDate;
attribute set<MusicalSheet> MusicalSheet;
};
interface BookCatalog
{
attribute date publishingDate;
attribute set<MusicalBook> MusicalBook;
};
interface MusicalSheet
{
attribute decimal price;
attribute string payment;
attribute string seller;
attribute string metrics;
attribute artist artist;
};
interface MusicalBook
{
attribute decimal price;
attribute string payment;
attribute string seller;
attribute string title;
attribute set<string> author;
attribute date publishingDate;
};
typedef enum{sings_song} activity_Singer;
152
typedef enum{writes_song} activity_Composer;
typedef enum{sings_song,writes_song} activity_SongSingerWriter;
typedef range{1,10} position_TopTenAlbum;
typedef range{1,10} position_TopTenSong;
typedef enum{instrumental} groupType_Band;
typedef enum{choral} groupType_Chorus;
typedef enum{mixed} groupType_Orchestra;
typedef enum{wind,percussion,stringed}
CategoryType_InstrumentCategory;
typedef enum{strumpet,saxophone,horn,clarinet,flute,organ,oboe}
instrumentType_WindInstrument;
typedef enum{piano,xylophone,drum,cymbals}
instrumentType_PercussionInstrument;
typedef enum{guitar,violin,viola,violoncello,harp,lyre,mandolin}
instrumentType_StringedInstrument;
// Regole di sussunzione per i tipi
// R_ISA_1
for all X in
// R_ISA_2
for all X in
// R_ISA_3
for all X in
// R_ISA_4
for all X in
// R_ISA_5
for all X in
// R_ISA_6
activity_Singer then X in activity_SongSingerWriter
activity_Singer then X in string
activity_Composer then X in activity_SongSingerWriter
activity_Composer then X in string
activity_SongSingerWriter then X in string
153
for all X in
// R_ISA_7
for all X in
// R_ISA_8
for all X in
// R_ISA_9
for all X in
// R_ISA_10
for all X in
// R_ISA_11
for all X in
// R_ISA_12
for all X in
// R_ISA_13
for all X in
// R_ISA_14
for all X in
// R_ISA_15
for all X in
// R_ISA_16
for all X in
position_TopTenAlbum then X in position_TopTenSong
position_TopTenAlbum then X in integer
position_TopTenSong then X in position_TopTenAlbum
position_TopTenSong then X in integer
groupType_Band then X in string
groupType_Chorus then X in string
groupType_Orchestra then X in string
CategoryType_InstrumentCategory then X in string
instrumentType_WindInstrument then X in string
instrumentType_PercussionInstrument then X in string
instrumentType_StringedInstrument then X in string
// Regole di equivalenza
// R_EQUI_1
for all X in position_TopTenAlbum then X in position_TopTenSong
and for all Y in position_TopTenSong then Y in
position_TopTenAlbum
// Regole di disgiunzione
// R_DIS_1
for all X in Singer then X not in Composer and
for all Y in Composer then Y not in Singer
// R_DIS_2
for all X in Band then X not in Chorus and
for all Y in Chorus then Y not in Band
// R_DIS_3
for all X in Band then X not in Orchestra and
154
for all Y in Orchestra then Y not in Band
// R_DIS_4
for all X in Chorus then X not in Orchestra and
for all Y in Orchestra then Y not in Chorus
// R_DIS_5
for all X in WindInstrument then X not in PercussionInstrument and
for all Y in PercussionInstrument then Y not in WindInstrument
// R_DIS_6
for all X in WindInstrument then X not in StringedInstrument and
for all Y in StringedInstrument then Y not in WindInstrument
// R_DIS_7
for all X in PercussionInstrument then X not in StringedInstrument
and for all Y in StringedInstrument then Y not in
PercussionInstrument
// R_DIS_8
for all X in activity_Singer then X not in activity_Composer and
for all Y in activity_Composer then Y not in activity_Singer
// R_DIS_9
for all X in activity_Singer then X not in groupType_Band and
for all Y in groupType_Band then Y not in activity_Singer
// R_DIS_10
for all X in activity_Singer then X not in groupType_Chorus and
for all Y in groupType_Chorus then Y not in activity_Singer
// R_DIS_11
for all X in activity_Singer then X not in groupType_Orchestra
and for all Y in groupType_Orchestra then Y not in
activity_Singer
// R_DIS_12
for all X in activity_Singer then X not in
CategoryType_InstrumentCategory and for all Y in
CategoryType_InstrumentCategory then Y not in activity_Singer
// R_DIS_13
for all X in activity_Singer then X not in
instrumentType_WindInstrument and for all Y in
instrumentType_WindInstrument then Y not in activity_Singer
// R_DIS_14
for all X in activity_Singer then X not in
instrumentType_PercussionInstrument and for all Y in
instrumentType_PercussionInstrument then Y not in
activity_Singer
// R_DIS_15
155
for all X in activity_Singer then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
activity_Singer
// R_DIS_16
for all X in activity_Composer then X not in groupType_Band and
for all Y in groupType_Band then Y not in activity_Composer
// R_DIS_17
for all X in activity_Composer then X not in groupType_Chorus
and for all Y in groupType_Chorus then Y not in
activity_Composer
// R_DIS_18
for all X in activity_Composer then X not in groupType_Orchestra
and for all Y in groupType_Orchestra then Y not in
activity_Composer
// R_DIS_19
for all X in activity_Composer then X not in
CategoryType_InstrumentCategory and for all Y in
CategoryType_InstrumentCategory then Y not in activity_Composer
// R_DIS_20
for all X in activity_Composer then X not in
instrumentType_WindInstrument and for all Y in
instrumentType_WindInstrument then Y not in activity_Composer
// R_DIS_21
for all X in activity_Composer then X not in
instrumentType_PercussionInstrument and for all Y in
instrumentType_PercussionInstrument then Y not in
activity_Composer
// R_DIS_22
for all X in activity_Composer then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
activity_Composer
// R_DIS_23
for all X in activity_SongSingerWriter then X not in
groupType_Band and for all Y in groupType_Band then Y not in
activity_SongSingerWriter
// R_DIS_24
for all X in activity_SongSingerWriter then X not in
groupType_Chorus and for all Y in groupType_Chorus then
Y not in activity_SongSingerWriter
156
// R_DIS_25
for all X in activity_SongSingerWriter then X not in
groupType_Orchestra and for all Y in groupType_Orchestra then
Y not in activity_SongSingerWriter
// R_DIS_26
for all X in activity_SongSingerWriter then X not in
CategoryType_InstrumentCategory and for all Y in
CategoryType_InstrumentCategory then Y not in
activity_SongSingerWriter
// R_DIS_27
for all X in activity_SongSingerWriter then X not in
instrumentType_WindInstrument and for all Y in
instrumentType_WindInstrument then Y not in
activity_SongSingerWriter
// R_DIS_28
for all X in activity_SongSingerWriter then X not in
instrumentType_PercussionInstrument and for all Y in
instrumentType_PercussionInstrument then Y not in
activity_SongSingerWriter
// R_DIS_29
for all X in activity_SongSingerWriter then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
activity_SongSingerWriter
// R_DIS_30
for all X in groupType_Band then X not in groupType_Chorus and
for all Y in groupType_Chorus then Y not in groupType_Band
// R_DIS_31
for all X in groupType_Band then X not in groupType_Orchestra and
for all Y in groupType_Orchestra then Y not in groupType_Band
// R_DIS_32
for all X in groupType_Band then X not in
CategoryType_InstrumentCategory and for all Y in
CategoryType_InstrumentCategory then Y not in groupType_Band
// R_DIS_33
for all X in groupType_Band then X not in
instrumentType_WindInstrument and for all Y in
instrumentType_WindInstrument then Y not in groupType_Band
// R_DIS_34
for all X in groupType_Band then X not in
instrumentType_PercussionInstrument and for all Y in
157
instrumentType_PercussionInstrument then Y not in
groupType_Band
// R_DIS_35
for all X in groupType_Band then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
groupType_Band
// R_DIS_36
for all X in groupType_Chorus then X not in
groupType_Orchestra and for all Y in groupType_Orchestra then
Y not in groupType_Chorus
// R_DIS_37
for all X in groupType_Chorus then X not in
CategoryType_InstrumentCategory and for all Y in
CategoryType_InstrumentCategory then Y not in
groupType_Chorus
// R_DIS_38
for all X in groupType_Chorus then X not in
instrumentType_WindInstrument and for all Y in
instrumentType_WindInstrument then Y not in
groupType_Chorus
// R_DIS_39
for all X in groupType_Chorus then X not in
instrumentType_PercussionInstrument and for all Y in
instrumentType_PercussionInstrument then Y not in
groupType_Chorus
// R_DIS_40
for all X in groupType_Chorus then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
groupType_Chorus
// R_DIS_41
for all X in groupType_Orchestra then X not in
CategoryType_InstrumentCategory and for all Y in
CategoryType_InstrumentCategory then Y not in
groupType_Orchestra
// R_DIS_42
for all X in groupType_Orchestra then X not in
instrumentType_WindInstrument and for all Y in
instrumentType_WindInstrument then Y not in
groupType_Orchestra
158
// R_DIS_43
for all X in groupType_Orchestra then X not in
instrumentType_PercussionInstrument and for all Y in
instrumentType_PercussionInstrument then Y not in
groupType_Orchestra
// R_DIS_44
for all X in groupType_Orchestra then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
groupType_Orchestra
// R_DIS_45
for all X in CategoryType_InstrumentCategory then X not in
instrumentType_WindInstrument and for all Y in
instrumentType_WindInstrument then Y not in
CategoryType_InstrumentCategory
// R_DIS_46
for all X in CategoryType_InstrumentCategory then X not in
instrumentType_PercussionInstrument and for all Y in
instrumentType_PercussionInstrument then Y not in
CategoryType_InstrumentCategory
// R_DIS_47
for all X in CategoryType_InstrumentCategory then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
CategoryType_InstrumentCategory
// R_DIS_48
for all X in instrumentType_WindInstrument then X not in
instrumentType_PercussionInstrument and for all Y in
instrumentType_PercussionInstrument then Y not in
instrumentType_WindInstrument
// R_DIS_49
for all X in instrumentType_WindInstrument then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
instrumentType_WindInstrument
// R_DIS_50
for all X in instrumentType_PercussionInstrument then X not in
instrumentType_StringedInstrument and for all Y in
instrumentType_StringedInstrument then Y not in
instrumentType_PercussionInstrument
159
// Sinonimie
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
Mapping tra i concetti ontologici e le Xclass globali di origine
Biography: Biography
artist: artist
Singer: Singer
Composer: Composer
SongSingerWriter: SongSingerWriter
AlbumType: Album
Song: Song
MusicalClassification: MusicalClassification
TopTenAlbum: TopTenAlbum
TopTenSong: TopTenSong
MusicalReview: MusicalReview
MusicalGroup: MusicalGroup
Band: Band
Chorus: Chorus
Orchestra: Orchestra
MusicalInstrumentCatalog: MusicalInstrumentCatalog
InstrumentCategory: InstrumentCategory
MusicalInstrument: MusicalInstrument
WindInstrument: WindInstrument
PercussionInstrument: PercussionInstrument
StringedInstrument: StringedInstrument
MusicalGoodsStore: MusicalGoodsStore
SheetCatalog: SheetCatalog
BookCatalog: BookCatalog
MusicalSheet: MusicalSheet
MusicalBook: MusicalBook
Le ultime righe di tale codice definiscono le corrispondenze tra concetti ed X-Class globali. L’ultima riga, ad esempio, indica che il concetto
MusicalBook deriva dalla X-Class globale MusicalBook.
160
E.2
Codice completo dello schema integrato
utilizzato negli esempi
// Schema integrato ODLI3
/*
Sogenti utilizzate:
EMI,
SONY,
ISLAND,
Deutsche Grammophone (DG),
La Voce del Padrone (VDP)
*/
interface Biography
{
attribute string author
mapping rule
EMI.Biografia.autore,
SONY.Biography.author,
ISLAND.Bio.author,
DG.Biographie.Autor,
VDP.Biografia.nomeAutore;
attribute date publishingDate
mapping rule
EMI.Biografia.data,
SONY.Biography.publishingDate,
ISLAND.Bio.date,
DG.Biographie.Date,
VDP.Biografia.dataDiPubblicazione;
attribute artist artist
mapping rule
EMI.Biografia.artista,
SONY.Biography.artist,
ISLAND.Bio.artist,
DG.Biographie.Kuenstler,
VDP.Biografia.artista;
};
interface artist
{
attribute string name
161
mapping rule
EMI.Artista.nome,
(SONY.Artist.firstname and SONY.Artist.middlename and
SONY.Artist.lastname),
ISLAND.Artist.name,
(DG.Kuenstler.Vorname and DG.Kuenstler.Familienname),
(VDP.Artista.nome and VDP.Artista.cognome);
attribute string artName ?
mapping rule
EMI.Artista.nomeDArte,
SONY.Artist.artName,
(VDP.Artista.soprannome union VDP.Artista.nomignolo on rule1);
attribute date birthDate
mapping rule
EMI.Artista.dataNascita,
SONY.Artist.birthDate,
ISLAND.Artist.birthDate,
DG.Kuenstler.Geburtstag,
(VDP.Artista.giornoNascita and VDP.Artista.meseNascita and
VDP.Artista.annoNascita);
attribute album_set Album
mapping rule
EMI.Artista.opere,
SONY.Artist.albums,
ISLAND.Artist.Album,
DG.Kuenstler.Werke,
VDP.Artista.album;
};
interface Singer
{
attribute string name
mapping rule
EMI.Cantante.nome,
(SONY.Singer.firstname and SONY.Singer.middlename and
SONY.Singer.lastname),
ISLAND.Singer.name,
(DG.Singer.Vorname and DG.Singer.Familienname),
(VDP.Cantante.nome and VDP.Cantante.cognome);
attribute string artName
mapping rule
EMI.Cantante.nomeDArte,
162
SONY.Singer.artName,
VDP.Cantante.soprannome;
attribute date birthDate
mapping rule
EMI.Cantante.dataNascita,
SONY.Singer.birthDate,
ISLAND.Singer.birthDate,
DG.Singer.Geburtstag,
(VDP.Cantante.giornoNascita and VDP.Cantante.meseNascita and
VDP.Cantante.annoNascita);
attribute album_set Album
mapping rule
EMI.Cantante.titoliAlbum,
SONY.Singer.albums,
ISLAND.Singer.Album,
DG.Singer.Werke,
VDP.Cantante.raccolte;
attribute activity_Singer activity
mapping rule
SONY.Singer.activity,
ISLAND.Singer.activity;
};
interface Composer
{
attribute string name
mapping rule
EMI.Compositore.nome,
(SONY.Composer.firstname and SONY.Composer.lastname),
ISLAND.SongWriter.name,
(DG.Komponist.Vorname and DG.Komponist.Familienname),
(VDP.Compositore.nome and VDP.Compositore.cognome);
attribute string artName
mapping rule
SONY.Composer.artName,
VDP.Compositore.soprannome;
attribute date birthDate
mapping rule
EMI.Compositore.dataDiNascita,
SONY.Composer.birthDate,
ISLAND.Composer.birthDate,
DG.Komponist.Geburtstag,
163
(VDP.Compositore.giornoNascita and VDP.Compositore.meseNascita and
VDP.Compositore.annoNascita);
attribute album_set Album
mapping rule
EMI.Compositore.opere,
SONY.Composer.albums,
ISLAND.Composer.Album,
DG.Komponist.Werke,
VDP.Compositore.album;
attribute activity_Composer activity
mapping rule
EMI.Compositore.occupazione,
SONY.Composer.activity,
DG.Komponist.Taetigkeit,
VDP.Compositore.attivita;
};
interface SongSingerWriter
{
attribute string name
mapping rule
EMI.Cantautore.nome,
(SONY.SongSingerWriter.firstname and
SONY.SongSingerWriter.middlename and
SONY.SongSingerWriter.lastname),
ISLAND.SingerWriter.name,
(DG.SongSingerVerfasser.Vorname and
DG.SongSingerVerfasser.Familienname),
(VDP.Cantautore.nome and VDP.Cantautore.cognome);
attribute string artName
mapping rule
EMI.Cantautore.nomeDArte,
SONY.SongSingerWriter.artName,
VDP.Cantautore.soprannome;
attribute date birthDate
mapping rule
EMI.Cantautore.dataNascita,
SONY.SongSingerWriter.birthDate,
ISLAND.SingerWriter.birthDate,
DG.SongSingerVerfasser.Geburtstag,
(VDP.Cantautore.giornoNascita and VDP.Cantautore.meseNascita and
VDP.Cantautore.annoNascita);
164
attribute album_set Album
mapping rule
EMI.Cantautore.opere,
SONY.SongSingerWriter.albums,
ISLAND.SingerWriter.Album,
DG.SongSingerVerfasser.Werke,
VDP.Cantautore.album;
attribute activity_SongSingerWriter activity
mapping rule
EMI.Cantautore.attivita,
SONY.SongSingerWriter.activity,
DG.SongSingerVerfasser.Taetigkeit,
VDP.Cantautore.attivita;
};
interface Album
{
attribute string title
mapping rule
EMI.Album.titolo,
SONY.Album.title,
ISLAND.Album.title,
DG.Album.Titel,
VDP.Album.titolo;
attribute integer year
mapping rule
EMI.Album.pubblicatoNel,
SONY.Album.year,
ISLAND.Album.publicationYear,
DG.Album.Jahr,
VDP.Album.anno;
attribute string kind
mapping rule
EMI.Album.genere,
SONY.Album.kind,
DG.Album.Art;
attribute integer soldCopies
mapping rule
EMI.Album.copieVendute,
SONY.Album.soldCopies,
DG.Album.VerfaufteKopie;
attribute Song_set Song
165
mapping rule
EMI.Album.canzoni,
SONY.Album.Songs,
ISLAND.Album.SongSet,
DG.Album.Lieder,
VDP.Album.brani;
attribute artist artist ?
mapping rule
EMI.Album.autore,
SONY.Album.artist,
ISLAND.Album.artist,
DG.Album.Autor,
VDP.Album.autore;
};
interface Song
{
attribute string title
mapping rule
EMI.Canzone.titolo,
SONY.Song.title,
ISLAND.Song.title,
DG.Lied.Titel,
VDP.Brano.titolo;
attribute decimal length
mapping rule
EMI.Canzone.lunghezza,
SONY.Song.length,
ISLAND.Song.length,
DG.Lied.Laenge,
VDP.Brano.durata;
attribute string kind ?
mapping rule
EMI.Canzone.genere,
SONY.Song.kind,
DG.Lied.Art;
attribute integer soldCopies
mapping rule
EMI.Canzone.copieVendute,
SONY.Song.soldCopies,
DG.Lied.VerfaufteKopie;
attribute artist artist ?
166
mapping rule
EMI.Canzone.autore,
SONY.Song.artist,
ISLAND.Song.artist,
DG.Lied.Autor,
VDP.Brano.autore;
};
interface MusicalClassification
{
attribute string week
mapping rule
EMI.Classifica.settimanaNumero,
SONY.Classification.week,
ISLAND.MusicalClassification.week,
DG.Rangliste.Woche,
VDP.Classifica.settimana;
attribute string_set sponsor
mapping rule
EMI.Classifica.sponsor,
SONY.Classification.sponsorizedBy,
VDP.Classifica.nomiSponsor;
attribute Album_set Album
mapping rule
EMI.Classifica.album,
SONY.Classification.albums,
ISLAND.MusicalClassification.albumSet,
DG.Ranglist.Alben,
VDP.Classifica.albums;
attribute Song_set Song
mapping rule
EMI.Classifica.canzoni,
SONY.Classification.songs,
ISLAND.MusicalClassification.songSet,
DG.Ranglist.Lieder,
VDP.Classifica.brani;
};
interface TopTenAlbum
{
attribute string title
mapping rule
EMI.TopTenAlbum.titolo,
167
SONY.TopTenAlbum.title,
ISLAND.TopTenAlbum.title,
DG.TopTenAlbum.Titel,
VDP.TopTenAlbum.titolo;
attribute integer year
mapping rule
EMI.TopTenAlbum.pubblicatoNel,
SONY.TopTenAlbum.year,
ISLAND.TopTenAlbum.publicationYear,
DG.TopTenAlbum.Jahr,
VDP.TopTenAlbum.anno;
attribute string kind
mapping rule
EMI.TopTenAlbum.genere,
SONY.TopTenAlbum.kind,
DG.TopTenAlbum.Art;
attribute integer soldCopies
mapping rule
EMI.TopTenAlbum.copieVendute,
SONY.TopTenAlbum.soldCopies,
DG.TopTenAlbum.VerfaufteKopie;
attribute Song_set Song
mapping rule
EMI.TopTenAlbum.canzoni,
SONY.TopTenAlbum.Songs,
ISLAND.TopTenAlbum.SongSet,
DG.TopTenAlbum.Lieder,
VDP.TopTenAlbum.brani;
attribute artist artist
mapping rule
EMI.TopTenAlbum.autore,
SONY.TopTenAlbum.artist,
ISLAND.TopTenAlbum.artist,
DG.TopTenAlbum.Autor,
VDP.TopTenAlbum.autore;
attribute position_TopTenAlbum position
mapping rule
EMI.TopTenAlbum.posizione,
SONY.TopTenAlbum.position,
ISLAND.TopTenAlbum.pos,
DG.TopTenAlbum.Lage,
168
VDP.TopTenAlbum.posiz;
attribute integer lastPosition ?
mapping rule
SONY.TopTenAlbum.lastPosition,
ISLAND.TopTenAlbum.lastPos;
};
interface TopTenSong
{
attribute string title
mapping rule
EMI.CanzoneTopTen.titolo,
SONY.TopTenSong.title,
ISLAND.TopTenSong.title,
DG.TopTenLied.Titel,
VDP.BranoTopTen.titolo;
attribute decimal length
mapping rule
EMI.CanzoneTopTen.lunghezza,
SONY.TopTenSong.length,
ISLAND.TopTenSong.length,
DG.TopTenLied.Laenge,
VDP.BranoTopTen.durata;
attribute string kind
mapping rule
EMI.CanzoneTopTen.genere,
SONY.TopTenSong.kind,
DG.TopTenLied.Art;
attribute integer soldCopies
mapping rule
EMI.CanzoneTopTen.copieVendute,
SONY.TopTenSong.soldCopies,
DG.TopTenLied.VerfaufteKopie;
attribute artist artist
mapping rule
EMI.CanzoneTopTen.autore,
SONY.TopTenSong.artist,
ISLAND.TopTenSong.artist,
DG.TopTenLied.Autor,
VDP.BranoTopTen.autore;
attribute position_TopTenSong position
mapping rule
169
EMI.CanzoneTopTen.posizione,
SONY.TopTenSong.position,
ISLAND.TopTenSong.pos,
DG.TopTenLied.Lage,
VDP.BranoTopTen.posiz;
attribute integer lastPosition ?
mapping rule
SONY.TopTenSong.lastPosition,
ISLAND.TopTenSong.lastpos;
};
interface MusicalReview
{
attribute date day
mapping rule
EMI.SpettacoloMusicale.data,
EMI.RassegnaMusicale.data,
SONY.MusicalReview.day,
ISLAND.Review.date,
DG.Schauspiel.Date,
VDP.Spettacolo.giorno,
VDP.Rassegna.giorno;
attribute string location
mapping rule
EMI.SpettacoloMusicale.luogo,
EMI.RassegnaMusicale.luogo,
SONY.MusicalReview.location,
ISLAND.Review.locateIn,
DG.Schauspiel.Platz,
VDP.Spettacolo.luogo,
VDP.Rassegna.luogo;
attribute MusicalGroup MusicalGroup
mapping rule
EMI.SpettacoloMusicale.gruppo,
EMI.RassegnaMusicale.gruppo,
SONY.MusicalReview.MusicalGroup,
ISLAND.Review = ’U2’,
DG.Schauspiel.Gruppe,
VDP.Spettacolo.gruppo,
VDP.Rassegna.gruppoProtagonista;
};
170
interface MusicalGroup
{
attribute string name
mapping rule
EMI.GruppoMusicale.nome,
SONY.MusicalGroup.name,
DG.Gruppe.Name,
VDP.Gruppo.nome;
attribute string director
mapping rule
EMI.GruppoMusicale.direttore,
SONY.MusicalGroup.director;
attribute string_set components
mapping rule
EMI.GruppoMusicale.componenti,
SONY.MusicalGroup.components,
DG.Gruppe.Mitglieder,
VDP.Gruppo.costituitoDa;
attribute Song_set Song
mapping rule
EMI.GruppoMusicale.pezzi,
SONY.MusicalGroup.Song,
DG.Gruppe.Lieder,
VDP.Gruppo.brani;
};
interface Band
{
attribute string name
mapping rule
EMI.BandaMusicale.nome,
SONY.Band.name,
DG.Kapelle.Name,
VDP.Banda.nome;
attribute string director
mapping rule
EMI.BandaMusicale.direttore,
SONY.Band.director;
attribute string_set components
mapping rule
EMI.BandaMusicale.componenti,
SONY.Band.components,
171
DG.Kapelle.Mitglieder,
VDP.Banda.costituitoDa;
attribute Song_set Song
mapping rule
EMI.BandaMusicale.pezzi,
SONY.Band.Song,
DG.Kapelle.Lieder,
VDP.Banda.brani;
attribute groupType_Band groupType
mapping rule
SONY.Band.groupType;
};
interface Chorus
{
attribute string name
mapping rule
EMI.CoroMusicale.nome,
SONY.Chorus.name,
DG.Chor.Name,
VDP.Coro.nome;
attribute string director
mapping rule
EMI.CoroMusicale.direttore,
SONY.Chorus.director;
attribute string_set components
mapping rule
EMI.CoroMusicale.componenti,
SONY.Chorus.components,
DG.Chor.Mitglieder,
VDP.Coro.costituitoDa;
attribute Song_set Song
mapping rule
EMI.CoroMusicale.pezzi,
SONY.Chorus.Song,
DG.Chor.Lieder,
VDP.Coro.brani;
attribute groupType_Chorus groupType
mapping rule
SONY.Chorus.groupType;
};
interface Orchestra
172
{
attribute string name
mapping rule
EMI.Orchestra.nome,
SONY.Orchestra.name,
DG.Orchester.Name,
VDP.Orchestra.nome;
attribute string director
mapping rule
EMI.Orchestra.direttore,
SONY.Orchestra.director,
DG.Orchester.Direktor,
VDP.Orchestra.dirett;
attribute string_set components
mapping rule
EMI.Orchestra.componenti,
SONY.Orchestra.components,
DG.Orchester.Mitglieder,
VDP.Orchestra.costituitoDa;
attribute Song_set Song
mapping rule
EMI.Orchestra.pezzi,
SONY.Orchestra.Song,
DG.Orchester.Lieder,
VDP.Orchestra.brani;
attribute groupType_Chorus groupType
mapping rule
SONY.Orchestra.groupType;
};
interface MusicalInstrumentCatalog
{
attribute date publishingDate
mapping rule
EMI.CatalogoStrumenti.data,
SONY.MusicalInstrumentCatalog.publishingDate,
ISLAND.InstrumentCatalog.date,
DG.Instrumentkatalog.Date,
VDP.CatalogoStrumenti.data;
attribute string shopName
mapping rule
EMI.CatalogoStrumenti.negozio,
173
SONY.MusicalInstrumentCatalog.shopName,
DG.Instrumentkatalog.Geschaeft,
VDP.CatalogoStrumenti.nomeNegozio;
attribute InstrumentCategory_set InstrumentCategory ?
mapping rule
SONY.MusicalInstrumentCatalog.InstrumentCategory,
ISLAND.InstrumentCatalog.categories;
attribute MusicalInstrument_set MusicalInstrument ?
mapping rule
EMI.CatalogoStrumenti.elencoStrumenti,
SONY.MusicalInstrumentCatalog.MusicalInstrument,
ISLAND.InstrumentCatalog.instruments,
DG.Instrumentkatalog.Instrumente,
VDP.CatalogoStrumenti.strumentiVenduti;
};
interface InstrumentCategory
{
attribute CategoryType_InstrumentCategory CategoryType
mapping rule
EMI.CategoriaStrumenti.tipo,
SONY.InstrumentCategory.CategoryType,
ISLAND.Category.type,
DG.Kategorie.Art,
VDP.Categoria.tipo;
attribute MusicalInstrument_set MusicalInstrument
mapping rule
EMI.CategoriaStrumenti.elencoStrumenti,
SONY.InstrumentCategory.MusicalInstrument,
ISLAND.Category.instruments,
DG.Kategorie.Instrumente,
VDP.Categoria.strumenti;
};
interface MusicalInstrument
{
attribute integer catalogCode ?
mapping rule
SONY.MusicalInstrument.catalogCode,
VDP.Strumento.codiceCatalogo;
attribute string instrumentType
mapping rule
EMI.StrumentoMusicale.tipo,
174
SONY.MusicalInstrument.instrumentType,
ISLAND.Instrument.type,
DG.Instrument.Art,
VDP.Strumento.tipo;
attribute decimal price
mapping rule
EMI.StrumentoMusicale.prezzo,
SONY.MusicalInstrument.price,
ISLAND.Instrument.price,
DG.Instrument.Preis,
VDP.Strumento.prezzo;
attribute string seller
mapping rule
EMI.StrumentoMusicale.venditore,
SONY.MusicalInstrument.seller,
DG.Instrument.Verkaeufer,
VDP.Strumento.venditore;
attribute string payment
mapping rule
EMI.StrumentoMusicale.pagamento,
SONY.MusicalInstrument.payment;
};
interface WindInstrument
{
attribute integer catalogCode
mapping rule
SONY.WindInstrument.catalogCode,
VDP.StrumentoAFiato.codiceCatalogo;
attribute instrumentType_WindInstrument instrumentType
mapping rule
EMI.StrumentoAFiato.tipo,
SONY.WindInstrument.instrumentType,
ISLAND.WindInstrument.type,
DG.Ateminstrument.Art,
VDP.StrumentoAFiato.tipo;
attribute decimal price
mapping rule
EMI.StrumentoAFiato.prezzo,
SONY.WindInstrument.price,
ISLAND.WindInstrument.price,
DG.Atemmusikinstrument.Preis,
175
VDP.StrumentoAFiato.prezzo;
attribute string seller
mapping rule
EMI.StrumentoAFiato.venditore,
SONY.WindInstrument.seller,
DG.Ateminstrument.Verkaeufer,
VDP.StrumentoAFiato.venditore;
attribute string payment
mapping rule
EMI.StrumentoAFiato.pagamento,
SONY.WindInstrument.payment;
};
interface PercussionInstrument
{
attribute integer catalogCode
mapping rule
SONY.PercussionInstrument.catalogCode,
VDP.StrumentoAPercussione.codiceCatalogo;
attribute instrumentType_PercussionInstrument instrumentType
mapping rule
EMI.StrumentoAPercussione.tipo,
SONY.MusicalInstrument.instrumentType,
ISLAND.PercussionInstrument.type,
DG.Schlaginstrument.Art,
VDP.StrumentoAPercussione.tipo;
attribute decimal price
mapping rule
EMI.StrumentoAPercussione.prezzo,
SONY.MusicalInstrument.price,
ISLAND.PercussionInstrument.price,
DG.Schlaginstrument.Preis,
VDP.StrumentoAPercussione.prezzo;
attribute string seller
mapping rule
EMI.StrumentoAPercussione.venditore,
SONY.PercussionInstrument.seller,
DG.Schlaginstrument.Verkaeufer,
VDP.StrumentoAPercussione.venditore;
attribute string payment
mapping rule
EMI.StrumentoAPercussione.pagamento,
176
SONY.PercussionInstrument.payment;
};
interface StringedInstrument
{
attribute integer catalogCode
mapping rule
SONY.StringedInstrument.catalogCode,
VDP.StrumentoACorde.codiceCatalogo;
attribute instrumentType_StringedInstrument instrumentType
mapping rule
EMI.StrumentoACorde.tipo,
SONY.StringedInstrument.instrumentType,
ISLAND.StringedInstrument.type,
VDP.StrumentoACorde.tipo;
attribute decimal price
mapping rule
EMI.StrumentoACorde.prezzo,
SONY.StringedInstrument.price,
ISLAND.StringedInstrument.price,
VDP.StrumentoACorde.prezzo;
attribute string seller
mapping rule
EMI.StrumentoACorde.venditore,
SONY.StringedInstrument.seller,
VDP.StrumentoACorde.venditore;
attribute string payment
mapping rule
EMI.StrumentoACorde.pagamento,
SONY.StringedInstrument.payment;
};
interface MusicalGoodsStore
{
attribute string storeName
mapping rule
EMI.NegozioDiMusica.nome,
SONY.MusicalGoodsStore.storeName,
ISLAND.MusicalStore.name,
DG.Musikgeschaeft.Name,
VDP.Negozio.nome;
attribute string IVA
mapping rule
177
EMI.NegozioDiMusica.pIva,
VDP.Negozio.IVA;
attribute InstrumentCatalog InstrumentCatalog
mapping rule
EMI.NegozioDiMusica.catalogoStrumenti,
SONY.MusicalGoodsStore.InstrumentCatalog,
ISLAND.MusicalStore.instrCatalog,
DG.Musikgeschaeft.Instrumente,
VDP.Negozio.strumenti;
attribute SheetCatalog SheetCatalog
mapping rule
EMI.NegozioDiMusica.catalogoSpartiti,
SONY.MusicalGoodsStore.SheetCatalog,
ISLAND.MusicalStore.sheetCatalog,
DG.Musikgeschaeft.Musikkatalog,
VDP.Negozio.spartiti;
attribute BookCatalog BookCatalog
mapping rule
EMI.NegozioDiMusica.catalogoLibri,
SONY.MusicalGoodsStore.BookCatalog,
ISLAND.MusicalStore.bookList,
DG.Musikgeschaeft.Buecherkatalog,
VDP.Negozio.elencoLibri;
};
interface SheetCatalog
{
attribute date publishingDate
mapping rule
EMI.CatalogoSpartiti.dataPubblicazione,
SONY.SheetCatalog.publishingDate,
ISLAND.SheetCatalog.date,
DG.Musikkatalog.Date,
VDP.ElencoSpartiti.dataPub;
attribute MusicalSheet_set MusicalSheet
mapping rule
EMI.CatalogoSpartiti.spartiti,
SONY.SheetCatalog.MusicalSheet,
ISLAND.SheetCatalog.sheets,
DG.Musikkatalog.Musiken,
VDP.ElencoSpartiti.lista;
};
178
interface BookCatalog
{
attribute date publishingDate
mapping rule
EMI.CatalogoLibri.dataPubblicazione,
SONY.BookCatalog.publishingDate,
ISLAND.BookCatalog.date,
DG.Buecherkatalog.Date,
VDP.ElencoLibri.data;
attribute MusicalBook_set MusicalBook
mapping rule
EMI.CatalogoLibri.libri,
SONY.BookCatalog.MusicalBook,
ISLAND.BookCatalog.books,
DG.Buecherkatalog.Buecher,
VDP.ElencoLibri.lista;
};
interface MusicalSheet
{
attribute decimal price
mapping rule
EMI.Spartito.prezzo,
SONY.MusicalSheet.price,
ISLAND.Sheet.price,
DG.Musik.Preis,
VDP.Musica.prezzo;
attribute string payment
mapping rule
EMI.Spartito.tipoDiPagamento,
SONY.MusicalSheet.payment,
ISLAND.Sheet.payMode,
DG.Musik.Bezahlung,
VDP.Musica.pagamento;
attribute string seller
mapping rule
EMI.Spartito.negoziante,
SONY.MusicalSheet.seller,
ISLAND.Sheet = ’ISLAND Store’,
DG.Musik.Verkaeufer,
VDP.Musica.vendutaDa;
attribute string metrics
179
mapping rule
EMI.Spartito.tempo,
SONY.MusicalSheet.metrics,
ISLAND.Sheet.metrics,
VDP.Musica.tempo;
attribute artist artist
mapping rule
EMI.Spartito.artista,
SONY.MusicalSheet.artist,
ISLAND.Sheet.artist,
DG.Musik.Autor,
VDP.Musica.compostaDa;
};
interface MusicalBook
{
attribute decimal price
mapping rule
EMI.Libro.prezzo,
SONY.MusicalBook.price,
ISLAND.Book.price,
DG.Musikbuch.Preis,
VDP.LibroDiMusica.costo;
attribute string payment
mapping rule
EMI.Libro.tipoDiPagamento,
SONY.MusicalBook.payment,
ISLAND.Book.payMode,
DG.Musikbuch.Bezahlung,
VDP.LibroDiMusica.pagamento;
attribute string seller
mapping rule
EMI.Libro.negoziante,
SONY.MusicalBook.seller,
ISLAND.Book = ’ISLAND Store’,
DG.Musikbuch.Verkaeufer,
VDP.LibroDiMusica.vendutoDa;
attribute string title
mapping rule
EMI.Libro.titolo,
SONY.MusicalBook.title,
ISLAND.Book.titled,
180
DG.Musikbuch.Titel,
VDP.LibroDiMusica.titolo;
attribute string_set author
mapping rule
EMI.Libro.scrittoDa,
SONY.MusicalBook.author,
ISLAND.Book.author,
DG.Musikbuch.Autor,
VDP.LibroDiMusica.autore;
attribute date publishingDate
mapping rule
EMI.Libro.data,
SONY.MusicalBook.publishingDate,
ISLAND.Book.date,
DG.Musikbuch.Date,
VDP.LibroDiMusica.stampatoInData;
};
E.3
Codice completo delle interrogazioni di
esempio
Esempio 1
Interrogazione sull’ontologia
select *
from Biography Biography_1,
artist artist_1,
Composer Composer_1,
Song Song_1,
Song Song_2
where
(Biography_1.author = ’Pietro martinelli’ and
Biography_1.artist = ’Ludwig van Beethoven’)
or
(artist_1.artName != ’Bono’ and
Composer_1.birthDate = artist_1.birthDate)
and
(Song_1.title != Song_2.title and
181
Song_1.length > Song_2.length and
Song_1.artist = Song_2.artist)
Risultato della traduzione
// ##@@ TRADUZIONE per la SORGENTE EMI:
// ##@@ UNION di 1 query:
SELECT *
FROM Biografia Biography_1,
Artista artist_1,
Compositore Composer_1,
Canzone Song_1,
Canzone Song_2
WHERE ((((Biography_1.autore = ’Pietro martinelli’)
AND
(Biography_1.artista = ’Ludwig van Beethoven’))
OR
((artist_1.nomeDArte != ’Bono’)
AND
(Composer_1.dataDiNascita = artist_1.dataNascita)))
AND
(((Song_1.titolo != Song_2.titolo)
AND
(Song_1.lunghezza > Song_2.lunghezza))
AND
(Song_1.autore = Song_2.autore)))
// ##@@ TRADUZIONE per la SORGENTE SONY:
// ##@@ UNION di 1 query:
SELECT *
FROM Biography Biography_1,
Artist artist_1,
Composer Composer_1,
Song Song_1,
Song Song_2
WHERE ((((Biography_1.author = ’Pietro martinelli’)
AND
(Biography_1.artist = ’Ludwig van Beethoven’))
OR
((artist_1.artName != ’Bono’)
AND
(Composer_1.birthDate = artist_1.birthDate)))
182
AND
(((Song_1.title != Song_2.title)
AND
(Song_1.length > Song_2.length))
AND
(Song_1.artist = Song_2.artist)))
// ##@@ Nessuna traduzione possibile per la sorgente ISLAND
// ##@@ Nessuna traduzione possibile per la sorgente DG
// ##@@ TRADUZIONE per la SORGENTE VDP:
// ##@@ UNION di 2 query:
SELECT *
FROM Biografia Biography_1,
Artista artist_1,
Compositore Composer_1,
Brano Song_1,
Brano Song_2
WHERE ((((Biography_1.nomeAutore = ’Pietro martinelli’)
AND
(Biography_1.artista = ’Ludwig van Beethoven’))
OR
((artist_1.soprannome != ’Bono’)
AND
(Composer_1.giornoNascita||Composer_1.meseNascita||
Composer_1.annoNascita = artist_1.giornoNascita||
artist_1.meseNascita||artist_1.annoNascita)))
AND
(((Song_1.titolo != Song_2.titolo)
AND
(Song_1.durata > Song_2.durata))
AND
(Song_1.autore = Song_2.autore)))
union
SELECT *
FROM Biografia Biography_1,
Artista artist_1,
Compositore Composer_1,
Brano Song_1,
Brano Song_2
WHERE ((((Biography_1.nomeAutore = ’Pietro martinelli’)
AND
(Biography_1.artista = ’Ludwig van Beethoven’))
183
OR
((artist_1.nomignolo != ’Bono’)
AND
(Composer_1.giornoNascita||Composer_1.meseNascita||
Composer_1.annoNascita = artist_1.giornoNascita||
artist_1.meseNascita||artist_1.annoNascita)))
AND
(((Song_1.titolo != Song_2.titolo)
AND
(Song_1.durata > Song_2.durata))
AND
(Song_1.autore = Song_2.autore)))
Esempio 2
Interrogazione sull’ontologia
select *
from Biography Biography_1,
MusicalGoodsStore MusicalGoodsStore_1,
MusicalReview MusicalReview_1
where (Biography_1.author = ’Pietro Martinelli’ and
Biography_1.artist = ’Gioacchino Rossini’)
or (MusicalGoodsStore_1.IVA = ’1234567890’ and
not (MusicalGoodsStore_1.storeName = Biography_1.author))
and MusicalReview_1.location = ’via Branze n 38’
Risultato della traduzione
// ##@@ TRADUZIONE per la SORGENTE EMI:
// ##@@ UNION di 2 query:
SELECT *
FROM Biografia Biography_1,
NegozioDiMusica MusicalGoodsStore_1,
SpettacoloMusicale MusicalReview_1
WHERE ((((Biography_1.autore = ’Pietro Martinelli’)
AND
(Biography_1.artista = ’Gioacchino Rossini’))
OR
((MusicalGoodsStore_1.pIva = ’1234567890’)
AND
184
NOT ((MusicalGoodsStore_1.nome = Biography_1.autore))))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
union
SELECT *
FROM Biografia Biography_1,
NegozioDiMusica MusicalGoodsStore_1,
RassegnaMusicale MusicalReview_1
WHERE ((((Biography_1.autore = ’Pietro Martinelli’)
AND
(Biography_1.artista = ’Gioacchino Rossini’))
OR
((MusicalGoodsStore_1.pIva = ’1234567890’)
AND
NOT ((MusicalGoodsStore_1.nome = Biography_1.autore))))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
// ##@@ Nessuna traduzione possibile per la sorgente SONY
// ##@@ Nessuna traduzione possibile per la sorgente ISLAND
// ##@@ Nessuna traduzione possibile per la sorgente DG
// ##@@ TRADUZIONE per la SORGENTE VDP:
// ##@@ UNION di 2 query:
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Spettacolo MusicalReview_1
WHERE ((((Biography_1.nomeAutore = ’Pietro Martinelli’)
AND
(Biography_1.artista = ’Gioacchino Rossini’))
OR
((MusicalGoodsStore_1.IVA = ’1234567890’)
AND
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore))))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
union
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Rassegna MusicalReview_1
WHERE ((((Biography_1.nomeAutore = ’Pietro Martinelli’)
185
AND
(Biography_1.artista = ’Gioacchino Rossini’))
OR
((MusicalGoodsStore_1.IVA = ’1234567890’)
AND
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore))))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
Esempio 3
Interrogazione sull’ontologia
select *
from Biography Biography_1,
MusicalGoodsStore MusicalGoodsStore_1,
MusicalReview MusicalReview_1,
artist artist_1
where ((Biography_1.author = Biography_1.artist)
or not (MusicalGoodsStore_1.storeName = Biography_1.author))
and MusicalReview_1.location = ’via Branze n 38’
and (artist_1.birthDate = ’19/03/1978’ or
not artist_1.name = artist_1.artName)
Risultato della traduzione
// ##@@ TRADUZIONE per la SORGENTE EMI:
// ##@@ UNION di 2 query:
SELECT *
FROM Biografia Biography_1,
NegozioDiMusica MusicalGoodsStore_1,
SpettacoloMusicale MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.autore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.autore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.dataNascita = ’19/03/1978’)
186
OR
NOT ((artist_1.nome = artist_1.nomeDArte))))
union
SELECT *
FROM Biografia Biography_1,
NegozioDiMusica MusicalGoodsStore_1,
RassegnaMusicale MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.autore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.autore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.dataNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome = artist_1.nomeDArte))))
// ##@@ TRADUZIONE per la SORGENTE SONY:
// ##@@ UNION di 1 query:
SELECT *
FROM Biography Biography_1,
MusicalGoodsStore MusicalGoodsStore_1,
MusicalReview MusicalReview_1,
Artist artist_1
WHERE ((((Biography_1.author = Biography_1.artist)
OR
NOT ((MusicalGoodsStore_1.storeName = Biography_1.author)))
AND
(MusicalReview_1.location = ’via Branze n 38’))
AND
((artist_1.birthDate = ’19/03/1978’)
OR
NOT ((artist_1.firstname||artist_1.middlename||
artist_1.lastname = artist_1.artName))))
// ##@@ Nessuna traduzione possibile per la sorgente ISLAND
// ##@@ Nessuna traduzione possibile per la sorgente DG
// ##@@ TRADUZIONE per la SORGENTE VDP:
// ##@@ UNION di 4 query:
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
187
Spettacolo MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.giornoNascita||artist_1.meseNascita||
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.soprannome))))
union
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Rassegna MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.giornoNascita||artist_1.meseNascita||
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.soprannome))))
union
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Spettacolo MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.giornoNascita||artist_1.meseNascita||
188
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.nomignolo))))
union
SELECT *
FROM Biografia Biography_1,
Negozio MusicalGoodsStore_1,
Rassegna MusicalReview_1,
Artista artist_1
WHERE ((((Biography_1.nomeAutore = Biography_1.artista)
OR
NOT ((MusicalGoodsStore_1.nome = Biography_1.nomeAutore)))
AND
(MusicalReview_1.luogo = ’via Branze n 38’))
AND
((artist_1.giornoNascita||artist_1.meseNascita||
artist_1.annoNascita = ’19/03/1978’)
OR
NOT ((artist_1.nome||artist_1.cognome = artist_1.nomignolo))))
189
Bibliografia
[1] Javasoft home page. http://www.javasoft.com.
[2] Omg home page. http://www.omg.org.
[3] Devis Bianchini. Strumenti e metodi per la costruzione di ontologie di
dominio. Master’s thesis, Università degli studi di Brescia, 2002.
[4] S. Castano, V. De Antonellis, S. De Capitani di Vimercati, and M. Melchiori. An XML-based framework for information integration over
the web. In Proc. of Int. Workshop on Information Integration and
Web-based Applications & Services, Yogyakarta, Indonesia, settembre
2000.
[5] S. Castano, V. De Antonellis, S. De Capitani di Vimercati, and M. Melchiori. Designing a three-layer ontology in a web-based interconnection scenario. In First International Workshop on Electronic Business
Hubs: XML, Metadata, Ontologies, and Business Knowledge on the Web
(WEBH2001), Munich, Germany, September 2001.
[6] S. Castano, V. De Antonellis, S. De Capitani di Vimercati, and
M. Melchiori. An XML-based integration scheme for web data sources.
Ingénierie des Systèmes d’Information, 6(1):99–122, 2001.
[7] S. Castano, V. De Antonellis, S. De Capitani di Vimercati, and M. Melchiori. Semi-automated extraction of ontological knowledge from xml
data sources. In Second International Workshop on Electronic Business
Hubs: XML, Metadata, Ontologies, and Business Knowledge on the Web
(WEBH2002), Aix En Provence, France, Settembre 2002.
[8] Stefan Decker, Michael Erdmann, Dieter Fensel, and Rudi Studer. Ontobroker in a nutshell. Research and Advanced Technologies for Digital
Libraries, 1998.
190
[9] Stefan Decker, Michael Erdmann, Dieter Fensel, and Rudi Studer. Ontobroker: Ontology based access to distributed and semi-structured
information. DS-8: Semantic Issues in Multimedia Systems, 1999.
[10] John O. Everett, Daniel G. Bobrow, Reinhard Stolle, Richard Crouch,
Valeria de Paiva, Cleo Condoravi, Martin van den berg, and Livia Polany. Making ontologies work for resolving redundancies across documents.
Communications of the ACM, 45(2), 2002.
[11] Dieter Fensel. Ontologies: Silver bullet for knowledge management and
electronic commerce, 2001.
[12] Simone Foladori. Metodi e strumenti di unificazione di sorgenti xml.
Master’s thesis, Universitá degli studi di Brescia, marzo 2002.
[13] Michael Gruningen and Jintae Lee. Ontology application and design.
Communications of the ACM, 45(2), 2002.
[14] Nicola Guarino and Christopher Welty. Evaluating ontological decisions
with ontoclean. Communications of the ACM, 45(2), 2002.
[15] Clyde W. Holsapple and K.D. Joshi. A collaborative approach to
ontology design. Communications of the ACM, 45(2), 2002.
[16] Henry Kim. Predicting how ontologies for the semantic web will evolve.
Communications of the ACM, 45(2), 2002.
[17] J. Nielsen. Usability engineering. Morgan Kaufmann, San Francisco,
1994.
[18] Steffen Staab and Alexander Mädche. Knowledge portals - ontologies at
work. AI Magazine, 21(2), 2001.
[19] Yannis Tzitzikas, Nicolas Spyratos, and Panos Constantopoulos.
Mediator over ontology-based information sources. 2001.
[20] Mike uschold and Michael Gruningen. Ontologies: Principles, methods
and application. Knowledge Engineering Review, 11(2), giugno 1996.
[21] Mike Uschold and Michael Gruninger. Ontologies: Principles, methods
and application. Knowledge Engineering Review, 1996.
191

Scarica

la mia - Amicofragile

proposto automaticamente

ppsx

Le query in access

Lezione 2

La pietra vivente The living stone

Lezione 1

PresentazioneTesina

valutazione sistema NetWatcher - DBGroup

PPT - Dipartimento di Informatica