Un sistema per l'integrazione di varianti di una stessa ontologia

Alma Mater Studiorum - Università di Bologna
FACOLTÀ DI SCIENZE MATEMATICHE FISICHE NATURALI
Corso di laurea in Informatica
Un Sistema per l’integrazione
di varianti
di una medesima Ontologia
Tesi di laurea in Tecnologie Web
Relatore Presentata
Chiar.mo prof. Fabio Vitali da Marco Righi
Correlatore
Dott. Antonio Angelo Feliziani
Sessione III
Anno Accademico 2005/2006
1

Dedicato a mia madre Silvana e alla mia ragazza Michela
2

INDICE
1 Introduzione 5
2 Integrazione tra ontologie 11
2.1 Ontologie e applicazioni in campo informatico 11
2.1.1 L’origine del concetto di ontologia 11
2.1.2 Le ontologie in campo informatico 13
2.1.3 Tipizzazione delle ontologie informatiche 14
2.2 L’importanza dell’Integrazione tra ontologie 14
2.2.1 Le ontologie nell’information flow 15
2.2.2 l’importanza dell’integrazione 17
2.3 Metodologie di Integrazione 18
2.3.1 Alcune definizioni 18
2.3.2 Il processo di integrazione 19
2.3.3 Problemi nel processo di integrazione 20
2.3.4 La relazione tra le versioni 23
2.3.5 Il problema del versionamento 26
2.3.6 Un framework per il versionamento 28
2.4 Conclusioni 28
3 Metadata Integrator 31
3.1 Metadata for Document Exchange 31
3.1.1 Il progetto Metadata for Document Exchange 31
3.1.2 L’architettura 32
3.1.3 Metadata tools 33
3.2 Integreted Metadata Editor 34
3.2.1 Integrazione con Word 35
3.2.2 L’interfaccia principale 35
3.2.3 L’interfaccia secondaria 37
3.2.4 Selezione degli elementi ontologici 38
3.2.5 Modifica degli elementi ontologici 39
3.2.6 C# 40
3.2.7 RDF 42
3

3.3 Metadata Integrator 43
3.3.1 Architettura degli aggiornamenti 43
3.3.2 Principali funzionalità 44
3.3.3 Accessibilità alla nuova funzionalità 45
3.3.4 L’interfaccia principale 46
3.3.5 Il trattamento dei conflitti 48
3.4 Conclusioni 49
4 Architettura di Metadata Integrator 51
4.1 Requisiti d’installazione 51
4.2 Accenni sull’architettura Windows 52
4.3 Introduzione all’architettura di IME 52
4.3.1 Organizzazione del codice 53
4.3.2 Lo schema ontologico 53
4.3.3 Le classi ontologiche 54
4.3.4 DsoFile.dll 55
4.3.5 Drive.dll 56
4.4 Metadata Integrator 56
4.4.1 Fasi dell’implementazione 56
4.4.2 Organizzazione del codice 57
4.4.3 La classe MergeableItem 59
4.4.4 La classe MergeableElement 62
4.4.5 La classe MergeableClass 63
4.4.6 Il processo di integrazione 64
4.4.7 Installazione di IME 67
5 Conclusioni 69
6 Bibliografia 71
4

1 INTRODUZIONE
Scopo di questa dissertazione è illustrare al lettore i vantaggi che derivano
dall’adozione di software basati su ontologie nell’ambito dell’information flow e
la necessità che hanno tali software di un meccanismo di integrazione ontologica.
In questo contesto andremo anche a mostrare un esempio concreto di software
per l’integrazione ontologica che ho avuto modo di sviluppare, ovvero il
Metadata Integrator.
Il concetto di ontologia nasce nella Grecia antica come lo studio dell’essere in
quanto tale, e subito diviene un mezzo per classificare tutto ciò che esiste in
categorie.
In informatica si suole chiamare ontologia lo schema concettuale di un dato
dominio[GRU93]. Normalmente si tratta di un vocabolario che descrive un certo
dominio, e di un insieme di assunzioni esplicite che vincolano l’interpretazione
dei termini del vocabolario. Gli ambiti in cui le ontologie si sono rivelate utili
sono molteplici, e vanno dall’ingegneria del software all’ingegneria della
conoscenza. Un importante ambito di ricerca, che noi tratteremo con particolare
riguardo, è l’information flow all’interno degli elementi di un’organizzazione
estesa.
Sappiamo bene come al giorno d’oggi gran parte dei dipendenti di un’azienda
basa il proprio lavoro sull’uso del computer, e come le aziende investano sempre
maggiori risorse nell’archiviazione di documenti elettronici. Tuttavia gli
strumenti esistenti oggi per l’archiviazione, la ricerca e la condivisione di tali
documenti risultano ancora molto inadeguati, e sono alla causa di alcuni problemi
come il fraintendimento o la perdita di documenti.
Per fare un esempio basta pensare ad i motori di ricerca per il web, mediamente il
50% delle risorse estratte da questi strumenti sono irrilevanti, per di più solo il
20% delle risorse rilevanti è individuato correttamente. Alla base di questi
malfunzionamenti sta il fatto che i software non sono in gradi capire il contenuto
dei documenti, essi basano la ricerca su di una semplice corrispondenza sintattica
tra le parole della query dell’utente e le parole nel documento.
5

È facile intuire come tale meccanismo sia approssimativo ad esempio vi sono
molte parole per esprimere lo stesso concetto e molti modi diversi di descrivere
lo stesso fenomeno.
Uno strumento che può venirci in aiuto per superare i problemi dei software
attuali sono i metadati o metainformazioni. I metadati sono un insieme di
informazioni strutturate che descrivono alcune caratteristiche o relazioni del
documento per aiutarci ad interpretarne il contenuto. I metadati sono strettamente
legati al concetto di ontologia, infatti per essere efficaci le informazioni che sono
aggiunte al documento devono essere estratte da un vocabolario che non dia adito
a fraintendimenti, appunto un’ontologia.
I metadati già esistevano molto prima dell’avvento dei computer, basti pensare
alle schede sui libri di una biblioteca per la catalogazione, ma stanno assumendo
un importanza cruciale proprio grazie alle nuove tecnologie.
Un aspetto fondamentale dei metadati è che essi per funzionare al meglio devono
essere inseriti dall’autore del documento al momento della creazione dello stesso.
Infatti pensiamo se l’autore andasse ad inserirli in un momento successivo,
rischierebbe di dimenticare parte del contenuto o il senso generale dello scritto,
dando origine cosi a metainformazioni incomplete o peggio errate. Se fosse una
terza persona ad aggiungere i metadati invece si avrebbe un doppio svantaggio
infatti egli dovrebbe prima leggere attentamente il documento, investendo cosi
molto del suo tempo, e rischiando in ogni caso di fraintendere parte o tutto il
contenuto del documento, originando di nuovo metainformazioni errate o
incomplete.
In questo scenario appare vantaggioso fornire a ogni strumento per la creazione
di documenti un meccanismo per aggiungere le metainformazioni e un’ontologia
da cui trarle.
Le diverse ontologie sparse nel sistema devono tuttavia essere allineate ed in
mutuo accordo tra loro, altrimenti rischieremmo di tornare al punto di partenza.
6

Queste sono alcune tra ragioni che introducono l’esigenza di un meccanismo
efficiente per allineare le ontologie e portarle in mutuo accordo sul significato dei
termini che descrivo, in una parola per integrarle.
Il problema dell’integrazione ontologica è uno degli ambiti di ricerca più attivi
nel campo delle ontologie informatiche. Infatti non è affatto un problema di facile
soluzione, e vi sono numerosi aspetti di cui è necessario tenere conto.
Le ontologie non sono oggetti statici ma hanno la tendenza ad evolvere nel tempo
a seguito di molteplici fattori. Alcuni di questi fattori possono essere identificati
con cambiamenti del dominio descritto a cui l’ontologia deve necessariamente
adeguarsi. Altre cause possono essere la necessità di descrivere un fenomeno da
un punto di vista differente, oppure un nuovo accordo sul significato di un
termine ecc...
Metadata Integrator (MI) è un progetto che ho avuto la possibilità di sviluppare,
esso è in grado di integrare diverse varianti di una medesima ontologia. MI si
inserisce all’interno di un progetto più ampio chiamato Metadata For Document
Exchange.
Metadata For Document Exchange (MFDE) è un progetto elaborato per favorire
l’interscambio di documenti tra i diversi membri di una grande azienda. Il
progetto inoltre è in grado agevolare notevolmente tutti i processi che riguardano
l’archiviazione, la ricerca, l’integrazione, il riuso dei documenti, senza per questo
stravolgere le metodologie di lavoro a cui gli utenti sono abituati.
Il meccanismo si basa sull’adozione di un’ontologia comune, e di un certo
numero di metainformazioni strutturate che sono aggiunte ad ogni documento,
per fare sì che esso sia in grado dai autodescriversi.
Il progetto è composto di tre elementi principali, i metadati e l’ontologia cui sono
riferiti, l’architettura di sistema che deve essere messa in atto per permettere al
sistema di funzionare, e gli strumenti necessari per manipolare i metadati in
modo efficiente.
7

Tra gli strumenti necessari alla messa in opera di MFDE ve ne è uno in
particolare di nostro interesse, l’Integrated Metadata Editor (IME). Questo ci
interessa perché è proprio al suo interno che è stato inserito Metadata Integrator.
IME è un plug-in di Microsoft Word che permette l’inserimento e la modifica dei
metadati associati al documento. I plug-in sono applicativi in grado di integrarsi
ad un programma principale ed in grado di estenderne le funzionalità.
IME si attiva in modo automatico ogni volta che l’utente procede al salvataggio
del documento e lo guida nell’inserimento dei metadati necessari all’information
flow così come previsto dal progetto MFDE.
Per ricercare le metainformazioni più adatte al documento l’utente è messo in
grado di navigare attraverso gli elementi esistenti all’interno della propria
ontologia. Quando all’interno dell’ontologia non vi sono ancora i termini più
corretti l’utente è anche libero di inserirne di nuovi o di modificare quelli presenti
per aggiornarli o adattarli. Naturalmente l’utente ha anche la possibilità di
eliminare gli elementi obsoleti così da rendere più facile la ricerca.
Quello che mancava ad IME fino a questo momento era invece un meccanismo in
grado di confrontare le modifiche avvenute su due istanze indipendenti
dell’ontologia per integrarle.
Questo meccanismo è appunto Metadata Integrator. Come abbiamo detto, MI è in
grado di integrare l’ontologia locale con un'altra che si trova tra le risorse locali,
di rete, o sul web.
Il risultato di tale integrazione è una nuova ontologia che compone gli elementi
delle due in maniera opportuna. Ciò significa che il programma è in grado di
individuare gli elementi nuovi, quelli eliminati, e quelli modificati e riportare
tutte queste modifiche nell’ontologia risultante.
8

Il programma è in grado di svolgere l’integrazione in maniera semi-automatica.
Questo è possibile grazie al fatto che l’ontologia è stata modificata per contenere
alcune meta-informazioni aggiuntive sugli elementi dell’ontologia stessa.
Nel corso dell’integrazione MI è anche in grado di gestire in maniera autonoma
eventuali situazioni di conflitto che possono venirsi a creare tra le diverse varianti
ontologiche. In particolare con il termine conflitto intendiamo situazioni nelle
quali uno stesso elemento subisce, in ontologie diverse, operazioni che sono tra
loro incompatibili, per esempio cancellazione inserimento. La logica utilizzata
per risolvere queste situazioni è semplice: il programma presume che
l’operazione avvenuta in tempi più recenti sia quella corretta. Di conseguenza
tutte le altre operazioni che sarebbero incompatibili vengono ignorate.
Per implementare questo meccanismo di risoluzione automatica dei conflitti tra i
nuovi metadati aggiunti all’ontologia vi è anche un’etichetta temporale associata
ad ognuna delle operazioni che avvengono sugli elementi dell’ontologia stessa.
Alla fine del processo di integrazione l’utente viene informato per mezzo di un
report riepilogativo e a questo punto l’ontologia locale viene sostituita con il
risultato dell’integrazione.
9

2 INTEGRAZIONE TRA ONTOLOGIE
In questo capitolo parleremo in generale del concetto di ontologia, dalla nascita
del termine fino alle più moderne applicazioni in campo scientifico con
particolare attenzione al settore informatico. In seguito proporremo alcuni scenari
per mostrare al lettore l’importanza e l’attualità delle ontologie nel campo
dell’information flow all’interno di aziende di una certa dimensione, e con essi
mostreremo anche l’importanza di disporre di un meccanismo di integrazione tra
le ontologie quando si lavora con esse.
In fine nell’ultima parte del capitolo tratteremo il problema dell’integrazione di
ontologie da un punto di vista prettamente tecnico. Mostreremo i problemi da
considerare al momento in cui si intraprende un processo di integrazione nel
tentativo di fornire al lettore un insieme di strumenti necessari per afrontare
questo tipo di problemi.
2.1 Ontologie e applicazioni in campo informatico
In questa sezione intendiamo dare al lettore alcune nozioni generali sul concetto
d’ontologia. Partiremo analizzando origini del concetto d’ontologia legate
all’ambito filosofico e risalente all’epoca dei filosofi presocratici. Analizzeremo
poi gli sviluppi pratici seguiti a tali studi concentrandoci in maniera particolare
sugli ambiti d’utilizzo d’ontologie in campo informatico.
Termineremo fornendo alcuni modelli di ontologie applicabili in campo
informatico e analizzando come esse si adattino ai diversi utilizzi.
2.1.1 L’origine dell’ontologia
Il termine ontologia [WIK06] deriva dal greco, "eon" e "logos", e significa
letteralmente "discorso sull'ente". L'ontologia è lo studio dell'essere, ovvero
di ciò che è, esiste, è pensabile.
11

Padre e fondatore dell'ontologia, è Parmenide, 505-504 AC, appartenente ai
presocratici. Parmenide fu il primo a porsi la questione dell'essere nella sua
totalità, dunque a porsi il problema, ancora alla sua genesi, dell'ambiguità tra
i piani logico, ontologico e linguistico. Platone, Aristotele e a seguire tutta la
filosofia greca, elaborò progressivamente questo ed altri temi.
In particolare Aristotele descrisse l'ontologia (pur senza usare questo termine)
come "la scienza dell'essere in quanto essere". L’espressione 'in quanto' vuol
dire 'riguardo all'aspetto di'. Secondo questa teoria, quindi, l'ontologia è la
scienza dell'essere riguardo all'aspetto dell'essere, o lo studio degli esseri
nella misura in cui questi esistono.
Nelle “Categorie” Aristotele mostra come tutto ciò che esiste possa essere
classificato in categorie, In figura 1 ne abbiamo una rappresentazione.
Figura 1 Categorie di Aristotele.
Dopo di lui in molti riproposero il problema, che in verità è trattato in modo
più o meno indiretto in ogni filosofia.
Il termine ontologia "fu coniato soltanto agli inizi del XVII secolo da Rudolf
Göckel per il suo “Lessico filosofico” e, autonomamente, da Jacob Lorhard
per la sua Ogdoas Scolastica[WIK06].
Nonostante la sua tradizione sia eminentemente teoretica, l'ontologia si sta
dimostrando in tempi recenti particolarmente feconda nei suoi risvolti pratici:
12

alcune questioni ontologiche hanno avuto impatto sulla fisica delle particelle
e diffuse sono le applicazioni di ontologie in campo informatico.
2.1.2 Le ontologie in campo informatico
In termini molto generali, in informatica si suole chiamare ontologia lo
schema concettuale di un dato dominio. Tale schema può assumere forme
molto diverse, a partire da una semplice tassonomia (classificazione
gerarchica di concetti) fino ad arrivare ad una vera e propria teoria logica.
Normalmente si tratta di una gerarchia di concetti correlati attraverso
relazioni semantiche, ma le ontologie più elaborate forniscono anche regole
(come assiomi o teoremi) che aiutano a specificare com’è strutturato il
dominio. Siamo quindi di fronte ad opere ingegneristiche costituite da un
vocabolario, che descrive un dato dominio, ed un insieme di assunzioni
esplicite, che vincolano l’interpretazione dei termini del vocabolario.
Barry Smith e Christopher Welty [SMI01] individuano tre grandi aree
d’applicazione delle ontologie nei sistemi informatici: l’ingegneria della
conoscenza, che concerne la progettazione di basi di conoscenza e i sistemi su
di esse basati; la modellazione concettuale, che riguarda le fasi iniziali della
progettazione di basi di dati; e l’ingegneria del software, soprattutto
relativamente ai cosiddetti ‘ linguaggi orientati agli oggetti ’.
In ognuno di questi settori, si è seguito fino a poco tempo fa, un approccio
alla progettazione che privilegiava soltanto esigenze interne al sistema da
realizzare.
Con l’avvento della rete, il problema dell’interazione e della comunicazione
tra sistemi diversi (anche distribuiti) è divenuto fondamentale
13

2.1.3 Tipizzazione delle ontologie Informatiche
È possibile tracciare alcune distinzioni tra diversi tipi di ontologie a seconda
dello scopo per il quale sono sviluppate. Un esempio può essere la distinzione
tra ontologie di applicazione, che offrono servizi terminologici, ontologie di
dominio, costruite ad hoc per uno specifico dominio, e ontologie di
riferimento, che offrono invece un alto grado d’espressività. Le ontologie di
riferimento vengono spesso utilizzate per creare consenso sui termini, o tra
ontologie d’alto livello, costituite da categorie molto generali.
Una distinzione di rilievo e che vale la pena sottolineare, poiché individua
entità di carattere abbastanza dissimile, è quella tra ontologie ``light weight'' e
ontologie fondazionali. Le ontologie ``light weigth'' sono artefatti sviluppati
specificamente per l'applicazione a domini definiti e ristretti o per compiti
molto specifici; sono strutture tassonomiche che contengono termini primitivi
e compositi con le loro definizioni, connessi da relazioni semplici e sono
normalmente utilizzate in comunità stabilizzate, in cui il significato inteso dei
termini è più o meno conosciuto e condiviso da tutti i membri. D'altro canto,
le ontologie fondazionali sono schemi più generali, non strettamente connessi
a domini particolari ma piuttosto adattabili in maniera generale e quindi più
adatti alla comunicazione dell'informazione attraverso domini e comunità
diversi.
2.2 L’importanza dell’integrazione delle ontologie
In questa parte introdurremo il ruolo che le ontologie ricoprono all’interno del
processo di information flow in organizzazioni di una certa dimensione e
valuteremo i vantaggi che seguono all’adozione di tecniche di storage delle
informazioni basate su esse. Concluderemo la nostra analisi valutando in uno
scenario come quello introdotto il ruolo indispensabile di task in grado di
allineare e coordinare tra loro le ontologie esistenti.
14

2.2.1 Le ontologie nell’information flow
Un importante ambito di ricerca, che sta prendendo piede negli ultimi anni,
riguarda l’information flow all’interno degli elementi di un’organizzazione
estesa. Sappiamo come ormai la maggior parte dei dipendenti di
un’organizzazione basi quasi completamente il proprio lavoro sul computer e
come le compagnie investano sempre di più per l’immagazzinamento
efficiente dei documenti elettronici. Gli strumenti più diffusi tra gli utenti
sono senza dubbio e-mail, web browser e search engine; l’inadeguatezza di
questi strumenti a supportare i processi di storage delle organizzazioni è alla
base di problemi quali la perdita, il fraintendimento, il salvataggio in posti
non adeguati dei documenti prodotti.
Ad esempio i search engine, nonostante siano cresciuti notevolmente sia per
diffusione che per sofisticatezza negli ultimi anni, restano molto lontani dalla
perfezione. Basti pensare ai search engine per il web, nei quali circa il 50%
dei risultati ottenuti risultano irrilevanti, e soltanto il 20% delle informazioni
rilevanti è catturato. Alla base della perdita delle informazioni sta il fatto che
uno stesso concetto può essere descritto in molti modi diversi. Gli engine
basano la propria ricerca su un confronto sintattico tra la parola nella query
dell’utente e la parola nel documento; ne consegue che se l’autore usa una
parola diversa per esprimere lo stesso concetto la ricerca sarà destinata a
fallire.
Una possibile soluzione a questo disagio potrebbe essere quella di aggiungere
ai documenti alcune parole ricavate da un vocabolario non ambiguo per
descrivere alcuni aspetti del documento. La ricerca di tali parole potrebbe
dare dei risultati praticamente perfetti. Le parole aggiunte sono dette dati
riguardanti i dati o metadati.
15

I metadati sono un insieme di informazioni strutturate che descrivono fatti o
relazioni relative al documento per aiutare a dare un significato al contenuto
dello stesso.
Metadati e ontologie sono concetti strettamente legati, infatti per essere
efficaci i metadati devono essere ricavati da un vocabolario non ambiguo che
fornisca un’interpretazione del termine; tale vocabolario è appunto
un’ontologia.
Già prima dell’avvento dei computer i metadati sono stati impiegati nella
catalogazione di ampie collezioni di libri o documenti:
• Nelle biblioteche: per agevolare il meccanismo di catalogazione dei libri.
• In database di pubblicazioni: per aiutare la ricerca bibliografica.
• Nella pubblicazione di libri: si usa organizzare nel retro del libro un
indice delle informazioni.
I dati che non sono accompagnati da metadati sono spesso difficili da trovare
e da accedere, problematici da interpretare e integrare, perdendo in questo
modo il loro valore.
Tra i vantaggi dell’uso dei metadati troviamo:
• Facilità di ricerca: gli engine possono usare i termini dell’ontologia per
ottenere i risultati rilevanti.
• Supporto per il workflow: dalle metainformazioni un utente può sapere
quanto è vecchio un documento, chi è l’autore, ecc…
• Supporto interdipartimentale: se tutti i dipartimenti utilizzano la stessa
ontologia e le stesse regole per l’impiego dei metadati la consistenza delle
informazioni è automatica.
16

• Memoria dell’organizzazione a lungo termine: i documenti non perdono
di valore nel tempo.
2.2.2 L’importanza dell’integrazione
È importante sottolineare che i metadati per essere efficaci devono essere
inseriti dall’autore del documento al momento della creazione o della
modifica dello stesso e non in un momento successivo o da altre persone o
assistenti. Infatti se l’autore inserisse i metadati in un momento successivo
alla creazione del documento il pericolo di dimenticare una parte o tutto il
contenuto sarebbe concreto. Di conseguenza anche i metadati risulterebbero
incompleti i errati.
Ancora più grande è il rischio di avere metadati errati se l’autore dei metadati
è diverso dall’autore del documento. Un autore diverso infatti dovrebbe
leggere con attenzione il documento, perdendo cosi il proprio tempo e
rischiando in ogni caso di interpretare in maniera scorretta alcuni elementi
dello stesso.
In uno scenario come quello descritto al punto precedente risulta evidente
come può essere utile che ogni utente possegga una versione locale
dell’ontologia comune, per permettergli di lavorare anche quando si trova off-
line o fuori della sede di lavoro.
Le ontologie spesso sono soggette a variazioni per vari motivi quali ad
esempio il cambiamento del dominio descritto o la modellazione di un
fenomeno da un diverso punto di vista ecc…
È fondamentale che le varie istanze esistenti nel sistema siano sempre
allineate, ovvero non siano in contraddizione tra loro e siano coerenti
nell’attribuzione del significato ai termini, altrimenti molti dei vantaggi dei
metadati sopra descritti svanirebbero.
17

Il processo tramite il quale le diverse varianti di un’ontologia possono essere
coordinate è un problema molto attuale nel campo della ricerca sulle
ontologie ed è detto integrazione ontologica.
2.3 Metodologie di Integrazione
Con questo capitolo intendiamo fornire al lettore alcuni strumenti per
affrontare il problema dell’integrazione di ontologie da diversi punti di vista.
In primo luogo introdurremo il processo di integrazione che permette di
creare una nuova ontologia da due esistenti; di seguito mostreremo
brevemente i principali problemi da affrontare in un processo di questo tipo.
Analizzeremo quindi la relazione di versione, relazione che intercorre tra le
versioni di una stessa ontologia. Anche per questa introdurremo brevemente i
punti critici, fornendo quindi alcuni strumenti atti a creare una sorta di
framework per esprimere in modo corretto la relazione.
2.3.1 Alcune definizioni
Prima di procedere è bene dare alcune definizioni dei termini che andremo ad
utilizzare nel corso dei seguenti capitoli, poiché esistono in letteratura
svariate sfumature di significato attribuite ad essi [KLE01a].
• Mappatura ontologica: processo in grado di mettere in relazione concetti
o relazioni simili provenienti da fonti diverse.
• Unione o integrazione di ontologie: il processo atto a creare una nuova
ontologia a partire da due o più ontologie esistenti con degli elementi
sovrapposti.
• Allineamento: Il processo in grado di portare due ontologie in mutuo
accordo.
18

• Traduzione: cambiare la rappresentazione formale di un’ontologia
preservandone i concetti semantici.
• Versione: l’ontologia risultante dopo avere applicato una o più variazioni
ad un’ontologia.
• Versionamento: Un metodo in grado di esprimere le relazioni esistenti tra
un’ontologia e tutte le versioni esistenti di essa.
2.3.2 Il processo di integrazione
Il problema dell’Integrazione delle ontologie è a tutt’oggi uno dei maggiori
ambiti di ricerca in campo ontologico e presenta diverse questioni aperte.
Quando qualcuno si appresta a riutilizzare due o più ontologie esse devono
essere in qualche modo combinate insieme; questo può essere fatto tramite il
processo d’integrazione [PIN99].
Possiamo pensare il processo d’integrazione composto dei seguenti passaggi
[MC00]:
• rilevare le zone delle ontologie sovrapposte (mappatura);
• mettere in relazione i concetti che sono semanticamente vicini
(allineamento ed integrazione);
• controllare la correttezza e la non ridondanza del risultato.
19

Figura 2 Interazione d’Ontologie.
L’allineamento delle ontologie spesso rende indispensabile apportare alcune
modifiche almeno ad una delle due. Tali modifiche generano una nuova
versione dell’ontologia stessa, introducendo il problema del versioning.
In fine va tenuto in considerazione che, se le ontologie sono espresse in
linguaggi diversi si rende necessaria una traduzione, ovvero la modifica della
rappresentazione formale dell’ontologia preservando la semantica della
stessa.
2.3.3 Problemi nel processo di integrazione
La chiave dei problemi che nascono nell’utilizzo di ontologie indipendenti sta
nelle differenze che possono esistere tra esse [KLE01a]. Per questo ora
esploreremo in che cosa due ontologie possono differire.
Una prima distinzione da fare è tra differenze a livello linguistico che
riguardano i meccanismi tramite i quali vengono definiti classi, relazioni, ecc,
e differenze a livello ontologico che riguardano invece il modo in cui il
dominio è modellato [VIS97].
Le differenze a livello linguistico occorrono ogni qual volta si vuole
combinare ontologie scritte in linguaggi ontologici differenti. In esse
possiamo distinguere quattro tipi di differenze [CHA00] che possono
verificarsi:
20

• Sintassi: ovviamente linguaggi diversi usano una diversa sintassi. Ad
esempio per esprimere la stessa classe in RDF, un linguaggio nato per la
descrizione della conoscenza nel web, che vedremo meglio nel capitolo 3, si
utilizza l’espressione <rdfs:Class ID=”miaClasse”/> mentre in
LOOM, un linguaggio introdotto nello studio delle intelligenze artificiali,
(defconcept miaClasse). Questo tipo di differenze è tipicamente il
tipo più semplice da affrontare.
• Notazione logica: si presenta quando i due linguaggi utilizzano una
notazione logica diversa per esprimere gli stessi concetti, ad esempio alcuni
linguaggi permettono di esprimere in maniera esplicita la disgiunzione tra
classi (es. disjoint A B ) mentre altri esprimono tale concetto attraverso la
negazione del concetto di sottoclasse (es. A sub-class-of (NOT B)). Le
ontologie che rientrano in questo caso non presentano alcuna differenza a
livello di concetti ontologici ma solo di come essi sono espressi logicamente.
• Semantica delle primitive: va tenuto in considerazione il fatto che uno
stesso termine può presentarsi tra le parole chiave di diversi linguaggi, ma
esso può possedere una semantica diversa in base al linguaggio. Ex. ci sono
diverse interpretazioni di della funzione di eguaglianza tra classi.
• Espressività del linguaggio: in fine va sempre considerato che linguaggi
diversi possono essere in possesso di capacità espressive diverse. Ex. alcuni
linguaggi posseggono il concetto di Lista e Insieme, altri ne sono sprovvisti.
21

Differenze a livello ontologico si presentano invece quando si procede
all’integrazione di due o più ontologie anche solo parzialmente sovrapposte,
indipendentemente dal linguaggio in cui esse sono espresse.
Una prima categoria di differenze ontologiche sono quelle inerenti alla
concettualizzazione del dominio.
• Scope: Due classi sembrano rappresentare lo stesso concetto, ma non
posseggono la medesima specifica [VIS97]. Un esempio può essere la classe
Impiegato, amministrazioni diverse possono utilizzare tale concetto con
piccole ma significative distinzioni.
• Modello e granularità: Questa differenza occorre quando parti del
dominio sovrapposte sono modellate con un livello di dettaglio diverso
[CHA00]. Ad esempio un’ontologia può fornire il concetto di auto ma non di
camion, un'altra presentare il concetto di camion in maniera superficiale, una
terza può entrare in dettaglio.
Procedendo con l’analisi delle differenze a livello ontologico incontriamo
un’altra classe che possiamo definire differenze di interpretazione: questa
riguarda lo stile di modellazione del dominio.
• Paradigma: diversi paradigmi possono essere usati per esprimere
concetti come tempo, azioni, casualità ecc.
• Descrizione dei concetti: vi sono alcune scelte che possono essere fatte
all’atto di modellare un concetto. Ex una differenza tra due concetti può
essere espressa introducendo un attributo qualificante o definendo una nuova
classe.
22

In fine un’ultima classe può essere descritta come differenze a livello
terminologico.
• Sinonimi: lo stesso concetto può essere presentato con nomi diversi, ad
esempio un’ontologia lo può presentare con il nome di macchina mentre
un'altra sotto il nome di automobile.
• Omonimi: lo stesso termine esprime concetti diversi in diversi domini, ad
esempio il termine ontologia ha un significato diverso in informatica piuttosto
che in filosofia.
• Encoding: Un valore può essere fornito con encode diversi, ad esempio
una distanza può essere fornita in km, in m ecc.
Figura 3 [MK01a] schema riassuntivo delle differenze tra ontologie
2.3.4 La relazione tra le versioni
Il concetto di versionamento parte dal presupposto che esistono
contemporaneamente più versioni di una stessa ontologia. Di solito tali
versioni sono originate apportando variazioni ad una variante esistente
23

dell’ontologia originale. L’insieme delle varianti genera una struttura ad
albero detto albero di derivazione.
Figura 4 Esempio di Albero di Derivazione
Ci sono due importanti aspetti da considerare quando si parla di relazione tra
versioni, il primo è la differenza tra una relazione di versione e le relazioni
concettuali all’interno di un’ontologia.
Di solito un’ontologia è un insieme di definizioni di classi (o concetti), delle
loro proprietà e di assiomi su esse. Una variazione in un’ontologia genera una
nuova versione di essa e di conseguenza una relazione tra i concetti e le
relazioni della versione originale e gli stessi elementi della versione
modificata.
Tale relazione tuttavia è profondamente diversa dalle relazioni che legano tra
loro gli elementi dell’ontologia originale.
Figura 5 Esempio di relazione di versione [KLE02b]
La relazione di versione non è una vera e propria relazione concettuale, essa
infatti non aggiunge alcun tipo di informazione sul conto della classe quale
24

concetto appartenente al dominio, bensì fornisce metainformazioni su essa
quale elemento ontologico.
Una relazione di versione dovrebbe possedere le seguenti caratteristiche:
• Trasformazioni: [BAN87] una specifica di cosa è cambiato nella
versione corrente dal punto di vista della definizione ontologica.
• Relazioni concettuali: le relazioni esistenti tra i costrutti delle due
diverse versioni, ex relazioni di equivalenza o altre relazioni logiche.
• Metainformazioni: quali per esempio l’autore della versione, la data,
ecc…
• Scope: una descrizione del contesto all’interno del quale gli
aggiornamenti sono considerati validi. Ex può essere un contesto temporale
come una data di transizione.
Un secondo aspetto da tenere in considerazione è in quale maniera viene
concretamente espresso l’insieme dei cambiamenti avvenuti sulla versione
corrente. Possiamo distinguere due diversi aspetti che riguardano l’insieme
dei cambiamenti: il primo è la granularità dell’informazione che può andare
dal singolo attributo della classe al file intero. Il secondo riguarda invece il
metodo con il quale tali informazioni vengono espresse. Vi sono due metodi
pensabili:
• Esplicito: i cambiamenti vengono espressi in maniera esplicita in forma di
un insieme di operazione (ex Add A Delete B ecc…)
• Implicito: i cambiamenti vengono espressi tramite il confronto della
nuova versione con la precedente.
25

Naturalmente non vi è equivalenza tra i metodi, infatti essi non sono in grado
di fornire le stesse informazioni.
2.3.5 Il problema del versionamento
Dal punto di vista ontologico possiamo affermare che il processo di
versionamento fornisce un meccanismo agli utilizzatori delle varianti
ontologiche per eliminare le ambiguità nell’interpretazione dei concetti
presenti nell’ontologia[KLE01b]; in altre parole esplicita la compatibilità tra
le versioni. La compatibilità tra due varianti è legata alle modifiche avvenute,
di conseguenza l’impatto semantico delle modifiche dovrebbe essere
esaminato.
Per analizzare i cambiamenti che possono avvenire su un ontologia è
fondamentale che ne esaminiamo la natura. Possiamo definire un’ontologia
come la specifica di una concettualizzazione condivisa su un dominio
[GRU93]. Va da se che le modifiche possono riguardare:
• Dominio: Se varia il dominio deve indiscutibilmente variare anche
l’ontologia che lo descrive. Un esempio può essere la creazione di un nuovo
reparto aziendale, o l’assunzione di un nuovo impiegato.
• Concettualizzazione condivisa: La concettualizzazione di un dominio
non è un concetto statico che viene creato in fase iniziale e dimenticato, ma
un elemento dinamico che varia nel tempo in relazione ai concetti descritti e
al consenso comune sul loro significato. Inoltre una concettualizzazione può
variare in base alla prospettiva che si applica al dominio. Processi diversi
possono avere punti di vista differenti sul dominio e di conseguenza una
diversa concettualizzazione. Ex si pensi ad un’ontologia che descriva le
26

connessioni stradali di Venezia dal punto di vista di un pedone; se la
prospettiva viene spostata a quella di una gondola alcuni oggetti come un
ponte variano la propria concettualizzazione passando da elemento necessario
per attraversare un canale a ostacolo.
• Specifica: Anche la specifica può variare; in questo caso otteniamo una
specie di traduzione dell’ontologia. I concetti e il dominio rimangono
invariati, ciò che varia è il meccanismo tramite il quale le informazioni sono
formalmente immagazzinate.
Il versionamento è fondamentale perché talvolta i cambiamenti ad
un’ontologia possono essere causa di incompatibilità.
Vi sono diversi oggetti che possono avere una dipendenza da un’ontologia.
Per ognuno di questi si genera un diverso tipo di incompatibilità:
• Documenti conformi all’ontologia: nel semantic web ad esempio un
documento può essere creato utilizzando i termini di un ontologia. Se questa è
modificata il documento potrebbe trovarsi a contenere un’ interpretazione
diversa di un termine o un termine che non esiste.
• Altre ontologie: infatti vi possono essere altre ontologie create a partire
da essa o che vi fanno riferimento e ogni cambiamento può portare
conseguenze in esse.
• Software: vi possono essere applicativi che utilizzano l’ontologia. Le
applicazioni infatti spesso usano un modello interno per rappresentare
l’ontologia; variazioni nel documento originale possono portare ad
un’incompatibilità tra i due modelli.
27

2.3.6 Un framework per il versionamento
La principale domanda cui dovrebbe rispondere un framework ontologico per
il versionamento è “come usare le ontologie esistenti in nuove
situazioni”[KLE01a]. Esso dovrebbe quindi tener conto da un lato della
relazione tra le versioni ontologiche, dall’altro della relazione con le
dipendenze dell’ontologia, fornendo agli utilizzatori delle varie versioni un
meccanismo per garantire la compatibilità. Per questo possiamo imporgli i
seguenti requisiti in ordine crescente di complessità:
• Identificazione: un meccanismo che permetta di riconoscere in
maniera certa le definizioni contenute all’interno dell’ontologia.
• Insieme dei cambiamenti: un meccanismo in grado di fornire
l’insieme dei cambiamenti avvenuti tra due diverse versioni in
maniera esplicita.
• Trasparenza: l’operazione di conversione dovrebbe essere, ove
possibile, automatizzata.
2.4 Conclusioni
In questo capitolo abbiamo visto come il concetto di ontologia stia
progressivamente trovando sempre maggiori applicazioni in campo
informatico.
In molte di queste applicazioni le esigenze di avere sistemi distribuiti e
concorrenti di aggiornamento, modifica o rimpiazzamento delle ontologie
esistenti hanno introdotto la necessità di possedere un meccanismo che sia in
grado di riconoscere e gestire tutti questi cambiamenti.
28

Queste premesse hanno fatto nascere il problema del riuso delle ontologie,
uno dei principali problemi all’interno della ricerca che riguarda le ontologie.
Poiché il problema del riuso non è affatto un problema banale o di facile
soluzione, esso è stato scomposto in due distinti problemi secondo la
definizione di [KLE01a]. Ognuno dei componenti infine è stato analizzato in
dettaglio per quello che riguarda i meccanismi di funzionamento e le
criticità.
Tutti gli strumenti forniti nel corso di queste pagine hanno l’ obiettivo di
preparare il lettore ad affrontare il prossimo capitolo in cui verrà presentato
un caso concreto di riuso di ontologie in un applicazione ontology oriented,
l’Integrated Metadata Editor (IME).
29

3 METADATA INTEGRATOR
Nel corso di questo capitolo andremo ad analizzare l’implementazione di un
meccanismo di integrazione tra istanze di ontologie che ho avuto modo di
sviluppare.
Dal momento che tale meccanismo che ho chiamato Metadata Integrator è stato
inserito all’interno di un progetto esistente ovvero Metadata for Document
Exchange partiremo la nostra analisi con una presentazione del progetto in
generale.
In particolare il processo è stato inserito all’interno di un elemento del progetto
chiamato Integrated Metadata Editor; la nostra analisi proseguirà quindi con una
carrellata sulle principali funzionalità fornite da questo software nel corso della
quale verranno anche brevemente trattati i linguaggi di programmazione con i
quali è stato sviluppato.
In fine ci concentreremo sul progetto in se, su quali servizi in particolare sia in
grado di fornire e sul suo funzionamento generale.
3.1 Metadata for Document Exchange
3.1.1 Il progetto Metadata for Document Exchange
Metadata for document Exchange è un progetto elaborato per favorire
l’interscambio efficiente di informazioni tra i diversi membri di una grande
organizzazione.
MFDE si propone di migliorare il modo in cui gli utenti sono in grado di
modificare, scambiarsi e salvare i documenti prodotti all’interno
dell’organizzazione, senza per questo stravolgere le metodologie di lavoro. Il
sistema si basa sulla sistematica adozione di un certo numero e di un certo
tipo di metadati con il quale ogni documento è in grado di fornire
informazioni su se stesso.
Il progetto è composto di tre elementi principali, i metadati e l’ontologia cui
sono riferiti, l’architettura di sistema che deve essere messa in atto per
31

permettere al sistema di funzionare, e gli strumenti necessari per manipolare i
metadati in modo efficiente.
3.1.2 L’architettura
È importante comprendere pienamente l’architettura aziendale per la quale è
stato progettato MFDE al fine di comprendere appieno quali siano poi gli
strumenti necessari per la manipolazione dei metadati. Il contesto preso in
esame è quello di una organizzazione di grandi dimensioni, in particolare
l’OCHA (Office for the Coordination of Humanitarian Affaire presso l’UN),
e sono state seguite alcune linee guida:
• La manipolazione dei metadati va fatta client-side
• Devono esistere più copie dello stesso documento salvate in posizioni
diverse all’interno del sistema.
• Il lavoro degli utenti deve essere influenzato il meno possibile dal
sistema.
• La documentazione esistente deve essere solo marginalmente
interessata dalla nuova implementazione.
Central
repository
(NYC/GE) Local
repository
Field officer
Semi-automatic
selection
Automatic
update Shared directory
e-mail attachment
e-mail message
FTP
diskette, etc.
checkpoint
checkpoint
Other uses
of documents
Other sources
of documents
Other sources
of documents
Figura 6 l'architettura proposta
32

Possiamo vedere in figura l’architettura risultante, vi è un unico central
repository che contiene una copia di tutti i documenti che esistono negli altri
luoghi e vari repository locali che contengono un sottoinsieme di questi
documenti.
In fine vi sono gli utenti che devono essere messi in grado di integrare i
metadati all’interno dei documenti che creano e di poter modificare a
piacimenti tanto i documenti quanto le relative metainformazioni.
Generalmente considereremo documenti file appartenenti al pacchetto office
(word – excell – powerpoint ), pdf, ma anche immagini quali gif o jpg ecc…
3.1.3 Metadata tools
I metadata tools sono divisi in tre grandi categorie e in accordo con
l’architettura che abbiamo appena visto troviamo:
• User tool: sono installati su ogni singola macchina, usati normalmente
dagli utenti nel corso delle loro quotidiane mansioni.
• Local tool: installati sul server locale questi strumenti forniscono
funzionalità di verifica, validazione e comunicazione agli altri servizi
e strumenti.
• Central tool: installati solamente sul repository centrale questi
strumenti forniscono funzionalità di verifica validazione e
comunicazione con i repository locali.
Gli user tool hanno come principale obiettivo quello di permettere all’utente
di inserire e modificare i metadati corretti, secondo l'ontologia proposta,
all’interno del documento; questo, come detto, nella maniera più intuitiva
33

possibile. I tool che ricadono in questa categoria sono tutti editor per
metadati:
• Internal metadata editing application: questo strumento si andrà ad
integrare con l’editor del documento e consentirà di associare le
metainformazioni ad ogni salvataggio dello stesso. I formati che
prevedono l’associazione di metadati sono quelli appartenenti al
pacchetto office ed i pdf.
• External metadata editing application: questo è invece l’editor
associato a tutti i tipi di file che non prevedono la possibilità di
associare metadati (immagini, ecc…); in questo caso è l’utente a
dover ricordare di attivare la funzionalità.
• Mail validator: applicativo associato al client mail dell’utente che ha il
compito di controllare se il messaggio o eventuali allegati hanno un
formato valido di metainformazioni.
3.2 Integrated Metadata Editor
Integrated Metadata Editor(IME) è un applicativo che si propone all’interno del
progetto Metadata for Document Exchange come internal editor per i documenti
di microsoft Word.
Tale progetto, sviluppato in C sharp, di cui darò alcune nozioni inseguito, è
proposto come plug-in per il programma Microsoft Word. I plug-in sono
applicativi in grado di interagire con un programma principale , nel nostro caso
microsoft Word, ed in grado di estenderne le funzionalità.
34

3.2.1 Integrazione con Word
Come detto IME estende le funzionalità di Word e gli fornisce da un lato
l’abilità di associare elementi della nostra ontologia al documento,
arricchendolo in questo modo di metainformazioni, dall’altro permette
all’utente di aggiornare l’insieme di elementi dell’ontologia.
Dopo l’installazione del programma compare tra le barre degli strumenti un
nuovo elemento denominato Integrated Metadata Editor che permette di
abilitare o disabilitare il plug-in (come mostrato in figura 7).
Figura 7 integrazione all'interno di Microsoft Word
Quando il plug-in è abilitato, ogni volta che un documento di word viene
salvato appare l’interfaccia principale del IME prima che l’operazione sia
eseguita.
3.2.2 Interfaccia principale
L’interfaccia principale abbiamo detto viene mostrata ogni volta che l’utente
decide di salvare un file di word, essa permette di compilare tutte le
metainformazioni obbligatorie al funzionamento dell’architettura.
Nel corso del normale utilizzo questa maschera è generalmente la sola con
cui l’utente si trova ad interagire.
35

Figura 8 Interfaccia principale di IME
Alcuni campi vengono riempiti in maniera automatica con le informazioni
relative al documento che stiamo modificando, ad esempio nome del file o
document location.
Per gli altri campi l’applicativo accede al file delle preferenze in cui sono
salvati i valori di default e in maniera automatica propone tali valori per
riempire i campi. Oltre i valori di defaul sono salvati un certo numero di
ultimi valori inseriti.
Queste funzionalità sono eccedibili tramite il tasto destro sul relativo campo.
Figura 9 Funzionalità aggiuntive dell’interfaccia principale di IME
Per stabilire se il documento sia stato modificato e quindi stabilire se
aumentare o meno il numero di versione del documento il programma
effettua il checksum del documento e lo confronta con le informazioni
precedentemente salvate.
36

Dopo aver eseguito queste operazioni l’applicazione procede alla lettura
dell’ontologia per essere in grado ove richiesto di suggerire tutti i possibili
valori in essa contenuti per i vari campi previsti.
3.2.3 Interfaccia secondaria
L’interfaccia secondaria permette all’utente di inserire una serie di
informazioni che non sono strettamente necessarie al funzionamento
dell’architettura ma possono essere utili agli utenti per meglio definire alcuni
dei loro documenti.
L’interfaccia è divisa in due sezioni: optional info e details. La prima
contiene appunto informazioni opzionali per i documenti standard che
tuttavia è bene definire per alcuni tipi di documenti come ad esempio le
pubblicazioni tecniche. La seconda parte invece contiene informazioni sulle
relazioni del documento corrente con altri documenti esistenti.
Figura 10 interfaccia secondaria di IME
37

3.2.4 Selezione degli elementi ontologici
Le restanti funzionalità dell’applicazione sono essenzialmente dedicate alla
ricerca inserimento eliminazione e modifica degli elementi ontologici
appartenenti all’ontologia. Ogni utente possiede una copia locale
dell’ontologia e ha anche la facoltà di modellarne gli elementi in qualsiasi
momento per rispondere in maniera immediata ed efficiente a esigenze
derivanti da una variazione del dominio o dalla necessità di descrivere un
elemento imprevisto fino a quel momento.
Per ogni classe ontologica principale è prevista una maschera tale da facilitare
l’individuazione e la selezione di uno o più elementi ontologici (in base allo
specifico campo associato ai metadati).
Figura 11 Interfaccia selezione ontologica
Possiamo notare in figura come l’insieme degli elementi ontologici venga
tradotto per migliorare la navigazione in una struttura gerarchica ad albero.
Questo se da un lato migliora notevolmente la navigazione nella struttura
impone il vincolo che non vi siano cicli all’interno dell’insieme degli
elementi, altrimenti la struttura non risulterebbe più assimilabile ad un albero.
38

3.2.5 Modifica degli elementi ontologici
Tramite la maschera vista al punto precedente è anche possibile accedere
all’insieme di operazioni di modifica degli elementi ontologici.
Queste funzionalità sono situate nel menu contestuale che appare premendo il
tasto destro sull’elemento o sul controllo.
Figura 12 Menu contestuale tasto destro
Come possiamo notare in figura i menu contestuali sono differenti a seconda
di quale punto del controllo viene cliccato: cliccando su un elemento potrò
accedere all’insieme delle operazioni di modifica di quel elemento; cliccando
su un punto generico potrò accedere alle operazioni di inserimento di un
elemento al top-level.
L’insieme delle operazioni messe a disposizione sono:
• Inserimento di un elemento: Una nuova istanza della classe ontologica
è inserita all’interno della gerarchia. Esso può essere aggiunto al top
level oppure come figlio di un elemento già esistente. Quando si
sceglie di inserire un nuovo elemento viene visualizzata una nuova
maschera (figura 13) da compilare con le informazioni riferite al
nuovo elemento.
• Cancellazione di un elemento: Un elemento nella gerarchia viene
rimosso, e con esso tutti i propri discendenti. Per questo è bene porre
una certa attenzione prima di eseguire un operazione di cancellazione,
eventuali operazioni di variazione della gerarchia vanno infatti
compiute preventivamente per evitare perdita di informazioni.
39

• Modifica di un elemento: permette di modificare ognuno degli
attributi di cui è composto l’elemento. Viene mostrata una nuova
interfaccia (figura 13) che a sua volta permette di aggiungere
eliminare modificare tutti i campi di cui è composto l’elemento. Oltre
a ciò è anche possibile modificare la posizione dell’elemento
all’interno della gerarchia, portandolo ad esempio al top-level o
rendendolo figlio di un altro nodo.
Figura 13 Maschera di modifica / Inserimento
Da notare che non tutte le maschere di visualizzazione posseggono
funzionalità di modifica dell’insieme degli elementi ontologici. Le maschere
che ne sono sprovviste evidentemente fanno riferimento ad elementi che si
considerano non modificabili direttamente dall’utente (es. le lingue non sono
modificabili dall’utente).
3.2.6 C#
Il core del progetto Integrated Metadata Editor è stato sviluppato interamente
in C#.
C# (o C Sharp) è un linguaggio di programmazione orientato agli oggetti
sviluppato da Microsoft all’interno del progetto .NET ed in seguito divenuto
40

standard ed approvato da ECMA (European Computer Manufacturers
Association) ed ISO (International Organization for Standardization).
C# possiede una sintassi procedurale [WIK07b], ovvero organizzata a
blocchi, orientata agli oggetti e basata su quella di C++, ma che include
aspetti di molti altri programmi (come Delphi e Java) con una particolare
enfasi alla semplificazione.
Nella specifica ECMA a C# sono posti i seguenti obiettivi di design:
• Il linguaggio e la sua implementazione devono fornire un supporto
ideale per l’ingegneria del software come una forte tipizzazione un
controllo sugli array e sulle variabili non inizializzate non che un
garbage collector automatico.
• Il linguaggio deve essere inteso per lo sviluppo di componenti
software che possano essere inseriti in sistemi distribuiti.
• La portabilità del codice sorgente è importante.
• Il supporto per l’internazionalizzazione è importante.
• Il linguaggio deve essere in grado di creare applicazioni utilizzabili
sia in sistemi hosted che embedded
• Le prestazioni delle applicazioni sono importanti. Particolare
attenzione è posta all’ottimizzazione delle risorse del sistema, anche
se non è pensabile naturalmente di competere con applicativi C o
assembly.
41

3.2.7 RDF
RDF è il linguaggio che abbiamo scelto per esprimere e memorizzare la
nostra ontologia su file.
Il Resource Description Framework (RDF) è sostanzialmente un modello
formale di dati dotato di sintassi di interscambio, un sistema di schemi di tipo
ed un linguaggio d’interrogazione. Esso è stato specificatamente creato,
secondo una raccomandazione (10 Febbraio 2004) del W3C, l’organo nato
per favorire lo sviluppo degli standard nel web, per la descrizione dei
metadati relativi alle risorse.
Il modello di dati RDF è formato da risorse, proprietà e valori. Qualunque
cosa descritta da RDF è detta risorsa; ogni risorsa è identificata da un URI
(Uniform Resource Identifier). L’ URI è quindi un identificatore univoco di
risorse e può essere un URL (Uniform Resource Locator) o un URN
(Uniform Resource Name).
Le proprietà sono delle relazioni che legano tra loro risorse e valori oppure
risorse con altre risorse, e possono anch’esse essere identificate da un URI.
Un valore, invece, o è una risorsa o è un tipo di dato primitivo.
L’unità base per rappresentare un’informazione in RDF è lo statement. Uno
statement è una tripla del tipo: “Soggetto – Predicato – Oggetto” dove il
soggetto è una risorsa, il predicato è una proprietà e l’oggetto è un valore.
Un modello RDF altro non è che un insieme di statement, questo può essere
immaginato come un grafo orientato in cui i nodi sono risorse o valori,
mentre gli archi sono dati dalle proprietà.
Un grafo RDF può essere rappresentato fisicamente tramite una
rappresentazione, esistono vari tipi di serializzazione:
42

• N-TRIPLE: si serializza il grafo come un insieme di triple soggetto -
predicato – oggetto
• N3: si serializza il grafo descrivendo, una per volta, una risorsa e tutte
le sue proprietà
• XML: l’RDF è serializzato in un file XML.
Per serializzazione si intende la possibilità di salvare dati in un formato tale
da permettere in seguito di recuperarli; in particolare la serializzazione xml
salva i dati in un file di testo tramite la sintassi XML. L'XML, acronimo di
eXtensible Markup Language è un metalinguaggio di markup creato dal
W3C.
3.3 Metadata Integrator
Come accennato nel corso di questo documento Metadata Integrator è un
processo per l’integrazione di varianti di istanze di una stessa ontologia che ho
avuto la possibilità di sviluppare e di cui ora voglio illustrare le principali
funzionalità.
Come ho gia accennato il processo è stato inserito all’interno del progetto
Metadata for Document Exchange ed in particolare all’interno di un suo
componente ovvero l’IME.
3.3.1 Architettura degli aggiornamenti
L’architettura degli aggiornamenti non è stata vincolata alla struttura del
progetto ma è stata lasciata piuttosto flessibile. Come possiamo vedere in
figura 14 infatti un utente può aggiornare la propria ontologia integrandola sia
con quella del central repository o del local server, ma anche con quella di un
altro utente del sistema.
43

Figura 14 Architettura degli aggiornamenti
Al momento dell’esecuzione il programma richiede all’utente di indicare
l’ubicazione dell’ontologia con la quale verrà eseguito il confronto. Per
agevolare il più possibile gli utenti tale ontologia si può trovare sulla
macchina locale, su una delle macchine appartenenti alla rete interna, oppure
ad un indirizzo web.
3.3.2 Principali funzionalità
Metadata Integrator si occupa di integrare ed allineare l’ontologia utilizzata
dall’utente che lo invoca con un'altra ontologia che viene indicata al processo
dall’utente.
Il processo di integrazione è composto da una serie di sotto processi più
semplici:
• Inserimento: Tutti gli elementi che sono stati inseriti nell’ontologia di
confronto e non compaiono nell’ontologia corrente vengono inseriti.
L’inserimento avviene in maniera da rispettare la struttura dei dati,
oltre l’oggetto vengono inseriti anche tutti i suoi riferimenti da e per
gli altri oggetti dell’insieme.
44

• Eliminazione:Tutti gli oggetti che sono stati eliminati nell’ontologia
di confronto e invece qui compaiono vengono eliminati, naturalmente
con essi viene anche aggiornata la struttura dei dati.
• Confronto: per tutti gli elementi che compaiono in entrambe le
ontologie si procede al confronto tra le diverse versioni. Nel corso di
questo confronto vengono controllati tutti i campi dell’oggetto e per
ogni uno di essi si procede all’aggiornamento del valore se più recente
o all’aggiunta di nuovi valori all’interno dell’insieme dei valori del
campo se si tratta di campo a valore multiplo. Vengono inoltre
aggiornati, ove possibile, i collegamenti verso gli altri oggetti
dell’insieme.
• Controllo di validità: alla fine di questi processi si esegue un controllo
di validità che accerta che la nuova struttura dati creata sia una
struttura valida.
Importante sottolineare che il processo non aggiorna entrambe le ontologie
ma solamente quella dell’utente che l’ha invocata.
Questo per semplicità poiché non sempre si posseggono i permessi per poter
scrivere sul disco di origine dell’ontologia di confronto, specialmente se essa
si trova in rete o sul web.
3.3.3 Accessibilità alla nuova funzionalità
La nuova funzionalità come abbiamo più volte detto è stata integrata
all’interno del progetto IME.
45

Figura 15 Accesso alla nuova funzionalità
Come vediamo in figura è stato inserito un nuovo bottone denominato
Ontology Integrator, nella parte inferiore dell’interfaccia principale di IME,
tramite questo è possibile accedere alla funzione Integrazione.
3.3.4 L’interfaccia principale
L’Interfaccia principale del nuovo processo è quella che permette di avere
accesso alla nuova funzionalità di integrazione.
Come possiamo vedere in figura essa è estremamente semplice ed intuitiva,
composta di pochi essenziali elementi.
L’unico input richiesto all’utente è la locazione dell’ontologia con la quale
effettuale l’integrazione, che, come abbiamo detto, può essere una risorsa
locale, di rete o web. Nei primi due casi si può usufruire dell’apposito tasto
sfoglia posto alla destra del campo di testo, mentre nel terzo è necessario
inserire manualmente l’intero indirizzo nel campo.
Il resto del processo è completamente automatico e l’utente può monitorare
l’andamento attraverso le due barre dell’interfaccia. Come avremo modo di
vedere nel prossimo capitolo l’ontologia è composta da un certo numero di
classi ontologiche, ognuna delle quali a propria volta composta da un certo
numero di istanze.
46

Figura 16 La schermata principale
Come vediamo in figura 16 le varie classi ontologiche compaiono nella lista
nella parte centrale dell’interfaccia. La barra mostra lo stato di elaborazione
della classe corrente. Una volta che l’elaborazione della classe è terminata a
lato della relativa voce dell’elenco compare una “v” e si riparte con
l’elaborazione della prossima classe.
Dopo aver terminato il processo di integrazione all’utente viene fornito un
breve documento riepilogativo delle operazioni eseguite, che per ogni classe
ontologica riporta tutti gli elementi nuovi che sono stati inseriti e tutti gli
elementi eliminati.
Figura 17 Riepilogo Integrazione
47

3.3.5 Il trattamento dei conflitti
Nel corso delle operazioni di modifica che ogni utente svolge sulla propria
ontologia in maniera indipendente, è lecito aspettarsi che possano venirsi a
creare situazioni di indecisione nel trattamento degli aggiornamenti.
Ad esempio a seguito di comunicazioni che alcuni utenti ricevono e altri no o
di fraintendimento di tali comunicazioni si possono creare situazioni in cui su
uno stesso elemento vengono eseguite operazioni incompatibili quali ad
esempio inserimento e cancellazione.
Dal momento che il processo è totalmente automatico è bene spiegare quale
tecnica è utilizza per la risoluzione di tali conflitti.
Per fare questo ci serviremo di un esempio esplicativo.
Paolo ed Elena ricevono una comunicazione che il collega dell’ufficio
vendite Mario è stato licenziato, quindi entrambi procedono ad eliminare
l’elemento ontologico associato a Mario. Il giorno seguente Paolo è in
permesso quando Elena riceve la comunicazione che si è verificato un
malinteso e Mario è stato reintegrato, quindi procede al reinserimento di
Mario in ontologia; quando Paolo rientra dal permesso chiede ad Elena di
poter aggiornale la sua ontologia con quella della collega.
A questo punto il sistema di trattamento dei conflitti decide di inserire
nuovamente Mario anche nell’ontologia di Paolo.
Il criterio generale seguito dal sistema in questo caso e di conseguenza in
ogni caso di conflitto, è quello che probabilmente l’operazione svolta in
tempi più recenti è quella corretta.
48

3.4 Conclusioni
Abbiamo visto in questo capitolo un processo per l’integrazione tra varianti
ontologiche inserito all’interno di un contesto più generale di un progetto per
l’applicazione di metadati ai documenti.
Tale strumento è un esempio pratico dell’utilità dei processi di integrazione
tra ontologie che abbiamo trattato nei paragrafi precedenti.
49

4 ARCHITETTURA DI METADATA INTEGRATOR
Questo capitolo è rivolto a quella parte dei lettori che desiderano approfondire il
funzionamento di Metadata Integrator al fine modificarlo o di aggiungervi nuove
funzionalità.
Varranno analizzati in dettaglio molti aspetti del software, dalla sua installazione
ad una visione generale delle classi fondamentali che lo compongono.
Durante il capitolo verranno anche introdotti in maniera molto sommaria alcuni
argomenti che riguardano l’architettura di windows ed i paradigmi di
programmazione ad oggetti per fornire al lettore i necessari strumenti a
comprendere appieno i contenuti.
4.1 Requisiti d’installazione
Come detto più volte il progetto Metadata Integrator è stato inserito all’interno
del progetto Integrate Metadata Editor, di conseguenza i requisiti e la procedura
di installazione che andremo qui ad analizzare sono quelli di IME.
I sistemi operativi supportati sono: Windows 2000, Windows Server 2003
Service Pack 1 for Itanium-based Systems, Windows Server 2003 x64 editions,
Windows Vista Business, Windows Vista Enterprise, Windows Vista Home
Basic, Windows Vista Home Premium, Windows Vista Starter, Windows Vista
Ultimate, Windows XP, Windows XP Professional x64 Edition.
In oltre abbiamo detto in precedenza il programma funge da plug-in per
Microsoft Word, di conseguenza la presenza del programma principale è
indispensabile. Le versioni di Word compatibili con il nostro componente sono
Microsoft Word 2003 / 2007.
In fine l’applicativo richiede la presenza del Microsoft .NET Framework Version
1.1 Redistributable Package. Questo altro non è che un pacchetto di strumenti
necessari al corretto funzionamento delle applicazioni sviluppate con
51

tecnologia .NET di Microsoft ed è scaricabile in forma gratuita dall’apposito sito
di Microsoft.
4.2 Accenni sull’architettura Windows
Sin dalla loro nascita i sistemi della famiglia Windows presentavano una struttura
modulare, il sistema è operativo formato da una collezione di librerie ad aggancio
dinamico (DLL). Queste DLL costituiscono la cosiddetta API (Application
Program Interface) ovvero l’interfaccia fra le applicazioni e il sistema operativo.
Una dynamic link library è una libreria software, ovvero un insieme di funzioni
di uso comune, che non viene collegata in maniera statica ad un eseguibile in fase
di compilazione, ma viene caricata dinamicamente in fase di esecuzione.
I vantaggi di questo tipo di approccio sono che permette la separazione del codice
di programmi in parti concettualmente distinte, che verranno caricate solo se
effettivamente necessarie. Inoltre, una singola libreria può essere caricata in
memoria una sola volta e utilizzata da più programmi, il che permette di
risparmiare le risorse del sistema.
Il principale svantaggio è legato al fatto che una nuova versione di una DLL, se
mal progettata, potrebbe avere un comportamento diverso, interferendo in alcuni
casi addirittura con il funzionamento di alcuni programmi che usavano la
versione precedente.
4.3 Introduzione all’architettura di IME
Come abbiamo detto nel corso di questo documento il progetto Metadata
Integrator è stato inserito all’interno del progetto IME, per cui è bene prima di
approfondire l’architettura, dare un breve introduzione dell’architettura di IME
cosi da poter comprendere meglio il contesto all’interno del quale si è lavorato.
52

4.3.1 Organizzazione del codice
Normalmente un progetto in C sharp contiene almeno due tipi di file, i file cs
che possono essere form di qualche tipo, classi, interfacce ecc, oppure i file
resx utilizzati per creare e definire le risorse dell'applicazione
All’interno di un progetto C# una risorsa è costituita da dati non eseguibili
che vengono distribuiti con l'applicazione stessa. Una risorsa può essere
visualizzata in un'applicazione sotto forma di messaggi di errore o come parte
dell'interfaccia utente.
All’interno del progetto IME in fine vi sono anche file rdf, essi contengono la
materializzazione su disco della nostra ontologia in serializzazione XML.
Le classi che compongono il progetto IME si possono dividere in tre
categorie:
• Grafiche: classi che forniscono da interfaccia verso l’utente.
• Ontologiche: classi che forniscono una rappresentazione
dell’ontologia all’interno dell’appicazione.
• Input Output: classi che forniscono un framework per acquisire e
salvare i dati nei documenti siano essi documenti del pacchetto office
oppure file rdf.
4.3.2 Lo schema ontologico
L’ontologia funge da perno attorno al quale l’intero progetto ruota, essa è
composta da due classi principali (file e document) e quattro classi secondarie
(term location organization e person).
53

Le due classi principali sono materializzate direttamente all’interno del
documento di Word, mentre le classi secondarie sono materializzate
all’interno di altrettanti file RDF.
Si può affermare che le classi secondarie forniscano in un certo qual modo la
base dati per le metainformazioni che sono allegate al documento di Word.
Figura 18 Schema dell'ontologia del progetto
Per manipolare la nostra ontologia usiamo due strumenti diversi a seconda di
dove siano le informazioni; per aggiungere metainformazioni al documento di
Word si usa DsoFile.dll, mentre per accedere alle ontologie materializzate
tramite RDF viene utilizzato Drive.dll. Entrambi i meccanismi di accesso
verranno analizzati più in dettaglio nel corso di questo capitolo.
4.3.3 Le classi ontologiche
Queste classi sono a loro volta divise in due categorie, un primo gruppo
riproduce in maniera più o meno fedele la struttura dei singoli elementi
ontologici secondari. Un secondo gruppo invece riproduce la struttura
54

dell’ontologia, funge da contenitore per le classi del primo tipo e permette le
interazioni tra esse.
Ogni istanza di una classe ontologica possiede un identificatore univoco
all’interno dell’ontologia, attraverso il quale può essere referenziata da tutti
gli altri elementi della stessa ontologia.
L’identificatore contiene informazioni sull’utente e la macchina che hanno
creato l’istanza, per cui non è possibile che due istanze create da utenti
diversi posseggano lo stesso identificatore, anche se rappresentano lo stesso
fenomeno.
4.3.4 DsoFile.dll
I documenti “OLE di archiviazione strutturata” di Microsoft posseggono la
capacità di memorizzare alcune metainformazioni in insiemi di proprietà
permanenti situate all’interno della struttura del documento.
File OLE sono ad esempio documenti di Word, cartelle di lavoro di Excel,
presentazioni PowerPoint ecc…
La libreria Dsofile.dll ,fornita in forma gratuita da Microsoft, è in grado di
accedere sia in lettura che in scrittura alle proprietà di qualsiasi file "OLE di
archiviazione strutturata".
All’interno della libreria Dsofile.dll vi è un unico oggetto che è possibile
istanziare, ovvero DSOFile.OleDocumentProperties.
L'oggetto DSOFile.OleDocumentProperties consente di accedere alle
proprietà di documenti OLE di un file che si carica utilizzando il metodo
Open. Tutte le proprietà vengono lette e salvate in cache al momento
dell'apertura. Le proprietà vengono riscritte nel file solo quando si invoca il
metodo Save. In fine il metodo Close rilascia le risorse allocate e libera i
blocchi sul documento.
55

4.3.5 Drive.dll
Drive è una libreria sviluppata in C# per il pacchetto .NET e fornita dai suoi
sviluppatori con la formula open source. Drive è un parser per documenti
RDF pienamente compatibile con la specifica di RDF fornita dal W3C.
Abbiamo avuto modo di vedere nel capitolo precedente come un grafo RDF
possa essere poi materializzato su file seguendo una delle serializzazioni
esistenti. Va aggiunto che uno stesso grafo può essere espresso in modi molto
diversi, anche se si utilizza la stessa serializzazione.
La libreria drive agevola il lavoro del programmatore acquisendo il
documento RDF e costruendo la struttura a grafo tipica del linguaggio, in
maniera indipendente dalla tecnica di rappresentazione scelta dall’autore del
documento.
La libreria Drive mette a disposizione tre classi principali:
• IRdfParserFactory: permette di istanziare un nuovo parser tramite il
metodo GetRdfParser.
• IRdfParser: permette di caricare un file rdf tramite il metodo
ParseRdf.
• IRdfGraph: permette di navigare all’interno del grafo.
4.4 Metadata Integrator
4.4.1 Fasi dell’implementazione
L’implementazione del progetto si è svolta in due fasi fondamentali. In una
prima fase sono state analizzate le caratteristiche dell’architettura esistente e
comparate con le esigenze associate alle nuove funzionalità che si desidera
56

implementare. Frutto di tale analisi è stato un insieme di modiche
architetturali necessarie agli oggetti che si desiderino sottoporre alla funzione
di integrazione.
In una seconda fase sono stati introdotti tutti i nuovi elementi necessari al
funzionamento del sistema ed è stato quindi implementata la funzione di
integrazione.
4.4.2 Organizzazione del codice
L’organizzazione del codice è stata basata su di due paradigmi tipici della
programmazione ad oggetti, le classi astratte e l’ereditarietà tra classi.
La programmazione orientata agli oggetti è un paradigma di
programmazione, che prevede di raggruppare in un'unica entità (la classe) sia
le strutture dati che le procedure che operano su di esse, creando per l'appunto
un "oggetto" software dotato di proprietà (dati) e metodi (procedure) che
operano sui dati dell'oggetto stesso.
L' ereditarietà consente di definire una classe come sottoclasse o classe
derivata a partire da una classe preesistente detta superclasse o classe base. La
sottoclasse "eredita" implicitamente tutte le caratteristiche (proprietà e
metodi) della classe base.
Concettualmente, l'ereditarietà indica una relazione di generalizzazione: essa
corrisponde infatti all'idea che la superclasse rappresenti un concetto generale
e la sottoclasse rappresenti una variante specifica di tale concetto generale.
Una classe A dichiarata sottoclasse di un'altra classe B:
• eredita (possiede implicitamente) tutte le variabili di istanza e tutti i
metodi di B;
• può avere variabili o metodi aggiuntivi;
57

• può ridefinire i metodi ereditati da B attraverso l'overriding, in modo tale
che essi eseguano la stessa operazione concettuale in un modo specializzato.
C# cosi come altri linguaggi di programmazione ad oggetti permette ad una
classe o ad un oggetto di modificare il modo in cui è implementata una
propria funzionalità ereditata da un'altra classe (di solito un metodo). Questa
caratteristica è chiamata "ridefinizione" (in inglese, "override").
Una classe astratta è una classe che non può essere istanziata direttamente.
Da una siffatta classe sarà possibile soltanto ereditarne proprietà e metodi
nelle classi figlie. In C#, per definire una classe astratta si utilizza la parola
riservata abstract. Ad esempio:
public abstract class FiguraGeometrica {...}
Sempre grazie alla parola riservata abstract, è possibile definire anche dei
metodi astratti all'interno delle classi astratte. Tali metodi, dovranno essere
necessariamente ridefiniti nelle classi figlie. Un possibile esempio di un
metodo astratto nella classe astratta FiguraGeometrica potrebbe essere il
seguente:
public abstract void disegna();
Ogni sottoclasse di una classe astratta deve ridefinire tutti i metodi astratti
della sua superclasse (o essere anch'essa dichiarata astratta). Se è una classe
astratta ed implementarne un'altra essa non ha tale obbligo, ma chi dovesse
implementare la classe astratta figlia dovrà implementare i metodi astratti di
entrambe.
Una classe astratta può anche contenere proprietà e metodi concreti, in tal
caso essi vengono ereditati direttamente dalle classi figlie.
58

4.4.3 La classe MergeableItem
La classe MergeableItem è una classe astratta che è stata aggiunta al progetto
per fungere da interfaccia alle classi ontologiche che rispecchiano in maniera
diretta uno delle classi secondarie dell’ontologia.
Questa classe definisce in particolare alcuni metodi astratti che sono
fondamentali per la funzione di integrazione, soprattutto per poter mettere a
confronto due diverse classi ontologiche e sapere se sono uguali o in cosa
differiscono.
Il confronto tra la classe corrente ed un'altra classe ontologica viene fatto per
mezzo del metodo equals.
Public bool Equals(object obj){…};
Il metodo equals è un metodo implementato nella classe object di C# della
quale tutte le classi sono necessariamente figlie, esso consente di determinare
se l'oggetto Object specificato è uguale all'oggetto Object corrente. Tale
metodo può tuttavia essere ridefinito nelle classi figlie, ed è proprio questo il
nostro caso, per poterne personalizzare il comportamento.
Il metodo equals non si limita a controllare se gli oggetti sono dello stesso
tipo, ma controlla che i valori associati alle proprietà dei due oggetti
corrispondano.
Si pone tuttavia il problema di scegliere in modo efficace le proprietà
pertinenti a identificare l’oggetto in quanto rappresentazione della stessa
entità concreta, che noi chiameremo proprietà identificanti.
Abbiamo visto nel corso del secondo capitolo come le ontologie siano entità
che variano nel corso del tempo, per cui abbiamo bisogno di un metodo che
sia il più possibile flessibile per specificare le proprietà identificanti.
59

Sono venuti in nostro aiuto ancora una volta i metadati, infatti abbiamo
inserito all’interno dell’ontologia un nuovo elemento in grado di fornirci
metainformazioni sugli elementi strutturali delle classi ontologiche.
In particolare per ogni classe sappiamo quali siano le proprietà identificanti.
Tali informazioni sono accessibili tramite il metodo statico :
public static ArrayList getMergeableItemIdentifierFields (MergeableClassesType)
che si trova all’interno della classe MergeableClass di cui parleremo in
seguito.
Alla luce di queste premesse possiamo capire il funzionamento del metodo
equals implementato nelle cassi figlie di MergeableItem. Il metodo ricava
dall’ontologia le metainformazioni sulla classe che esso rappresenta, quindi
confronta tra loro i campi significativi per valutare se l’oggetto specificato
possa essere accomunato all’oggetto corrente.
Abbiamo detto nel corso del capitolo precedente che ogni istanza ontologica è
in possesso di un identificatore univoco, usato dalle altre istanze all’interno
dell’ontologia per referenziarla.
Abbiamo anche fatto notare come tale identificatore sia diverso in base
all’utente che crea l’istanza. Si deduce che anche se due istanze
rappresentano lo stesso oggetto esse possano avere identificatori distinti in
diverse ontologie. Vista l’architettura del progetto vi possono essere vi
possono essere nel sistema innumerevoli documenti che identificano
l’oggetto con uno o l’altro identificatore indipendentemente.
Può essere quindi vantaggioso che il prodotto dell’integrazione sia in grado di
associare entrambi gli identificatori all’oggetto. A questo scopo è stato
aggiunto alla classe MergeableItem un campo di tipo collezione
alternativeIdentifiers. All’interno di alternativeIdentifiers vengono salvati di
60

volta in volta gli identificatori delle ontologie con le quali l’oggetto corrente è
stato integrato, naturalmente solo se i due non coincidono.
Questo metodo riproduce a propria volta un processo di integrazione a livello
del singolo oggetto. Esso analizza ogni singola proprietà dell’oggetto corrente
mettendola in confronto con la relativa proprietà l’oggetto specificato alla
ricerca di valori che non coincidano.
Public void Integrate(MergeleItem Item){…};
Quando viene rinvenuto un valore non coincidente modifica l’oggetto
corrente assegnando al campo in conflitto il valore più recente.
Quindi ritorno da tale metodo l’oggetto sul quale è stato invocato è stato
aggiornato, ogni campo riporta il valore più recente e le relative
metainformazioni associate.
4.4.4 La classe MergeableElement
Per applicare la politica di gestione automatica dei conflitti vista nel capitolo
precedente abbiamo necessità di avere informazioni aggiuntive su alcuni
degli elementi che compongono la nostra ontologia.
In particolare necessitiamo metainformazioni riguardanti l’ultima operazione
avvenuta sull’oggetto in questione e la data della stessa.
La classe MergeableElement fornisce un interfaccia per tutti gli oggetti che
necessitano delle nuove metainformazioni.
Oggetti che rientrano in questa categoria sono sia le istanze delle diverse
classi ontologiche, sia le proprietà delle stesse classi.
In particolare:
61

public void setOperation(operation newOperation)
public operation getOperation()
sono i metodi che permettono rispettivamente di marcare un oggetto come
modificato, e di ottenere informazioni su quale tipo di operazione sia
avvenuta.
Nel caso non sia avvenuta alcuna operazione il metodo ritornerà un valore
predefinito (Ex. Nothing).
Le uniche operazioni possibili sugli oggetti sono inserimento e cancellazione,
nel caso l’oggetto sia soggetto ad un operazione di aggiornamento, essa è resa
tramite un operazione di cancellazione del vecchio valore seguita da un
operazione di inserimento del valore aggiornato.
Anche la struttura ontologica è stata modificata leggermente per essere in
grado immagazzinare le nuove informazioni sugli oggetti.
4.4.5 La classe MergeableClass
Questa classe astratta fornisce un interfaccia comune alle classi che fungono
da collezioni di elementi ontologici.
Tra i metodi implementati troviamo meccanismi per la manipolazione degli
elementi (ex. aggiungi elimina elemento) e soprattutto metodi di confronto tra
elementi.
Il metodo getEquivalentElement consente di stabilire se la classe contiene
l’elemento specificato. In caso affermativo restituisce l’elemento
corrispondente altrimenti torna un valore nullo, che significa che non
contiene nessun oggetto concettualmente uguale all’oggetto specificato.
Per ottenere il risultato per ognuno degli elementi di cui è contenitore invoca
il metodo equals con l’oggetto specificato. Il primo degli oggetti che da un
esito positivo viene restituito.
62

public MergeableItem getEquivalentElement (MergeableItem){…}
Figura 19 Relazioni di ereditarietà legate alle classi Mergeable
4.4.6 Il processo di integrazione
Dopo aver creato le interfacce viste nella sezione precedente ed adattato gli
oggetti esistenti nel progetto affinché siano in grado di implementarle, siamo
in fine pronti per implementare il nostro processo di integrazione.
Il processo si compone di quattro fasi fondamentali:
• Acquisizione delle informazioni: vengono raccolte informazioni
inerenti le classi di entrambe le ontologie, e vengono istanziate le
classi ontologiche.
• Confronto degli elementi: i singoli elementi vengono confrontati tra
loro e vengono individuate le zone di sovrapposizione tra le due
ontologie.
• Aggiornamento dell’ontologia corrente: vengono inseriti ,eliminati o
modificati gli elementi dell’ontologia corrente ove necessario.
63

• Controllo di validità: viene verificato che il risultato dell’integrazione
sia ancora un ontologia valida.
Come abbiamo detto più volte nel corso di questo documento le ontologie
hanno la tendenza a subire variazioni nel tempo a seguito di svariati fattori.
Per assecondare tale esigenza abbiamo strutturato il meccanismo che
stabilisce quali classi debbano partecipare all’integrazione in maniera
dinamica.
Le nuove informazioni sono state inserite direttamente all’interno
dell’ontologia in un apposita sezione.
Le informazioni su quali classi ontologiche siano interessate dall’integrazione
sono accessibili all’interno dell’applicativo tramite il metodo statico:
public static ArrayList getMergeableClassList()
che si trova all’interno della classe MergeableClass.
Dopo aver acquisito tali informazioni il processo procede acquisendo gli
elementi interessati da entrambe le ontologie. La posizione dell’ontologia
locale è nota al processo, l’altra ontologia, che noi chiameremo onologia di
confronto, viene invece indicata dall’utente come abbiamo visto nel capitolo
precedente.
Una volta acquisiti i dati per ogni classe ontologica vengono istanziate una
collezione di MergeableItem, che rappresenta gli elementi dell’ontologia di
confronto, e una MergeableClass, che rappresenta gli elementi dell’ontologia
corrente, e si procede alla fase di confronto.
Il prossimo passo dell’integrazione sta nell’individuazione delle zone di
sovrapposizione delle due ontologie ovvero degli elementi presenti in
entrambe.
64

Ogni oggetto può trovarsi:
• Nell’ontologia locale ma non in quella di confronto.
• Nell’ontologia di confronto ma non in quella locale.
• In entrambe le ontologie.
Il primo caso non è di nostro interesse, in quanto come abbiamo detto nel
corso del capitolo precedente soltanto l’ontologia locale risulta modificata al
termine del processo, e rispetto a questo caso l’ontologia locale già risulta
completa.
Il secondo caso prevede invece che l’oggetto sia aggiunto all’ontologia locale
che altrimenti risulterebbe incompleta.
In fine l’ultimo caso risulta leggermente più complesso. Infatti dopo aver
verificato che l’oggetto esiste in entrambe le ontologie è necessario in primo
luogo verificare se ha subito modifiche in uno o in entrambe le ontologie.
Se l’oggetto è stato soggetto ad un operazione in una soltanto delle ontologie,
la versione modificata diventa quella ufficiale.
Se invec l’oggetto ha subito modifiche in entrambe le ontologie, è necessario
stabilire quale versione sia più attendibile.
Come abbiamo visto nel corso del capitolo 3 questo viene fatto in base alla
data in cui la modifica è avvenuta, infatti associata ad ogni operazione si
trova come abbiamo visto un etichetta temporale che indica con esattezza il
giorno in cui l’operazione è avvenuta. Confrontando le date è semplice
ottenere quale versione sia più recente e di conseguenza più attendibile.
Dopo aver terminato questo controllo è necessario ripetere lo stesso tipo di
confronto anche per ogni proprietà dell’oggetto. Come abbiamo visto questo
65

secondo controllo viene delegato all’oggetto stesso invocando il metodo
Integrate.
Il controllo di validità viene eseguito a livello del singolo elemento.
immediatamente dopo l’inserimento o la modifica dell’oggetto stesso.
Abbiamo visto come la rappresentazione dell’ontologia interna all’IME sia
associabile ad un albero, mentre la struttura ontologia di RDF sia associabile
ad un grafo diretto. Per permetterci di convertire un grafo in un albero
tuttavia è necessaria una condizione: non ci devono essere cicli all’interno del
grafo.
Il controllo di validità ha esattamente questo scopo, verifica che l’eventuale
inserimento dell’oggetto non dia origine a conflitti simili, non generi nessun
ciclo all’interno della struttura ontologica.
4.5 Installazione di IME
L’installazione di IME è semplice ed immediata gran parte delle applicazioni in
ambiente Windows del resto.
In primo luogo è necessario procurarsi “Microsoft .NET Framework Version 1.1
Redistributable Package” se questo non è gia installato sulla macchina. Il
pacchetto può essere reperito in forma gratuita nella sezione download del sito di
Microsoft.
Una volta installato l’aggiornamento sarà sufficiente lanciare il pacchetto di
installazione di IME e seguire la procedura guidata.
Ad installazione avvenuta possiamo notare che aprendo un documento di Word si
presenta un nuovo elemento tra le barre degli strumenti del programma chiamato
“Integrated Metadata Editor Toolbar”. Questo elemento consente di abilitare /
disabilitare il nuovo plug-in.
Dopo l’installazione IME di default risulta abilitato quindi all’utente che desideri
utilizzarlo non restano altre operazioni da svolgere.
66

5 CONCLUSIONI
Da questa dissertazione emerge l’utilità e l’attualità delle ontologie in molti
ambiti, soprattutto in quello dell’information flow all’interno di organizzazione
di una certa dimensione. È anche emerso tuttavia come ad oggi gli strumenti più
diffusi tra gli utenti non siano ancora in grado di supportare queste nuove
metodologie di lavoro basate sulle ontologie e sui metadati.
In questo contesto abbiamo visto come Metadata For Document Exchange ed in
particolare Integrated Metadata Editor siano strumenti preziosi per l’utente, in
grado di integrarsi con gli strumenti di uso comune, e che con un disagio minimo
sono in grado di offrirgli tutti i vantaggi, che abbiamo visto essere molti,
derivanti dall’inserimento dei metadati all’interno dei documenti prodotti.
Proseguendo con lo sviluppo del documento abbiamo visto l’assoluta necessità,
quando si comincia a lavorare con le ontologie, di un processo in grado di
allineare le svariate varianti ontologiche esistenti in un modello come quello da
noi proposto. Proprio in questo ambito abbiamo inserito Metadata Integrator, un
processo capace di integrare diverse varianti ontologiche in maniera semi
automatica. Il nostro programma tuttavia è ancora lungi dall’essere perfetto, e di
questo tratteremo in questa sezione, a beneficio di coloro che desiderino
implementare un processo simile al nostro o che desiderino aumentarne le
funzionalità.
Sicuramente un primo punto che può essere migliorato è la gestione dei conflitti
che si possono creare tra le diverse ontologie. È importante che l’integrazione
ontologica sia per quanto possibile automatica, poiché non si possono fare
assunzioni sul grado di preparazione di un utente. Tuttavia abbiamo visto vi sono
situazioni in cui il processo si trova in difficoltà a stabilire quale versione sia la
più attendibile.
Il linguaggio RDF non mette a disposizione alcun meccanismo per il
versionamento o l’integrazione delle ontologie, per cui un programmatore che si
68

appresti ad affrontare questo problema deve prevedere di salvare in qualche
modo metainformazioni sull’ontologia stessa.
Il nostro processo prevede di registrare la quantità minima di informazioni per
essere in grado di prendere decisioni autonome sulle situazioni di conflitto. Dal
momento che le informazioni a disposizione sono minime, il meccanismo di
decisione in caso di conflitto è tutto sommato piuttosto ingenuo. Avendo a
disposizione un numero maggiore di metainformazioni sulle ontologie e le
operazioni avvenute si potrebbero prevedere meccanismo molto più raffinati.
Un altro punto che sarebbe interessante sviluppare meglio sarebbe l’interfaccia di
Metadata Integrator, con particolare riferimento al report riepilogativo delle
modifiche apportate all’ontologia. Al momento, ricordiamo, riporta solamente gli
elementi aggiunti ed eliminati dalle diverse classi. Potrebbe essere interessante
per un utente più esperto un report più dettagliato, che riporti anche gli elementi
modificati ed i campi di tali elementi che sono stati interessati.
Potrebbe anche essere interessante permettere agli utenti una volta terminata
l’integrazione di verificare i cambiamenti avvenuti e di annullare quelle che loro
ritengono non corrette.
Questo sviluppo potrebbe essere un diverso meccanismo per ridurre al minimo
gli errori dovuti all’integrazione di ontologie, anche se richiederebbe l’intervento
di un utente con un certo bagaglio di conoscenze di base.
Vorrei concludere dicendo che la possibilità di partecipare a questo progetto è
stata per me un esperienza particolarmente gratificante. In particolare sono felice
di aver concluso il mio piano di studi con esso perché mi ha dato la possibilità di
mettere in pratica buona parte delle conoscenze che ho acquisito nel corso di
questi tre anni di studio.
Ad esempio i corsi di programmazione e paradigmi di programmazione sono stati
fondamentali per comprendere l’architettura di un progetto complesso come
Integrated Metadata Editor, per giunta sviluppato in un linguaggio C# mai visto
fino a questo momento. Il corso di ingegneria del software è stato indispensabile
69

per impostare le struttura del mio progetto ed integrarla con quello gia esistente,
il corso di sistemi operativi e di reti di calcolatori sono stati preziosi per
comprendere il comportamento del mio sistema operativo.
In fine il corso di tecnologie web mi ha permesso di comprendere appieno le
grandissime potenzialità e le prospettive di applicazioni fondate su ontologie e
metadati. Tali applicazioni sono probabilmente il prossimo livello di sviluppo in
molti più ambiti di quanti si possa ad oggi immaginare.
70

6 BIBLIOGRAFIA
[BAN87] Jay Banerjee and Won Kim and Hyoung-Joo Kim and Henry F. Korth.
“Semantics and Implementation of Schema Evolution in Object-Oriented
Databases” ACM SIGMOD Record archive Volume 16 , Issue 3 (December
1987) Pages: 311 - 322 Year of Publication: 1987 ISSN:0163-5808
http://portal.acm.org/ft_gateway.cfm?
id=38748&type=pdf&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618
[CHA00] H. Chalupsky. “OntoMorph: a translation system for symbolic
knowledge”. In A.G. Cohn, F. Giunchiglia, and B. Selman, editors, Principles of
Knowledge Representation and Reasoning: Proceedings of the Seventh
International Conference (KR2000), Breckenridge, Colorado, USA, April 2000,
San Francisco, CA, 2000. Morgan Kaufmann.
http://www.isi.edu/~hans/publications/KR2000.pdf
[GRU93] Gruber, T. R. (1993). “A Translation Approach to Portable
Ontology Specifications”. Knowledge Acquisition, 5(2), 199-220, Academic
Press Ltd. London, UK
ftp://ftp.ksl.stanford.edu/pub/KSL_Reports/KSL-92-71.ps.gz
[HEF04] Heflin, J. and Hendler, J. “Dynamic Ontologies on the Web”. In:
Proceedings of the Seventeenth National Conference on Artificial Intelligence
(AAAI-2000). AAAI/MIT Press, Menlo Park, CA, 2000. pp. 443-449.
[KLE01a] Michel Klein. “Combining and relating ontologies: an analysis of
problems and solutions”. In: Workshop on Ontologies and Information Sharing,
IJCAI'01, Asuncion Gomez-Perez, Michael Gruninger, Heiner Stuckenschmidt
and Michael Uschold (eds.), Seattle, USA, August 4-5, 2001.
http://www.cs.vu.nl/~mcaklein/papers/IJCAI01-ws.pdf
71

[KLE01b] Michel Klein and Dieter Fensel. “Ontology versioning for the
Semantic Web”. In: Proceedings of the First International Semantic Web
Working Symposium (SWWS), page 75-91, Stanford University, California,
USA, July 30 - August 1, 2001.
http://www.cs.vu.nl/~mcaklein/papers/SWWS01.pdf
[KLE02a] Michel Klein, Dieter Fensel, Atanas Kiryakov and Damyan
Ognyanov. “Ontology Versioning and Change Detection on the Web”. In:
13th International Conference on Knowledge Engineering and Knowledge
Management (EKAW02), LNCS no. 2473, page 197-212, Siguenza, Spain,
October 1-4, 2002.
http://www.cs.vu.nl/~mcaklein/papers/EKAW02.pdf
[KLE02b] Michel Klein, Atanas Kiryakov, Damyan Ognyanov and Dieter
Fensel. “Finding and Characterizing Changes in Ontologies.” In: Proceedings
of the 21st International Conference on Conceptual Modeling (ER2002) , LNCS
no. 2503, page 79-89, Tampere, Finland, October 7-11, 2002.
http://www.cs.vu.nl/~mcaklein/papers/ER2002.pdf
[MAS03] MASOLO Claudio, OLTRAMARI Alessandro, GANGEMI Aldo,
GUARINO Nicola, VICU Laure “La prospettiva dell'ontologia applicata”
Rivista di estetica ISSN 0035-6212 2003, vol. 43, no22, pp. 170-183
http://www.loa-cnr.it/Papers/rivest.pdf
[MC00] Deborah L. McGuinness, Richard Fikes, James Rice, and Steve Wilder.
“An Environment for Merging and Testing Large Ontologies”. In the
Proceedings of the Seventh International Conference on Principles of Knowledge
Representation and Reasoning (KR2000), Breckenridge, Colorado, USA. April
12-15, 2000.
http://dit.unitn.it/~accord/RelatedWork/Matching/McGuinnessKR.pdf
72

[PIN99]H. Sofia Pinto, Asuncion Gomez-Perez, and Joao P. Martins
“Some issues on ontology integration”. In Proceedings of The Workshopon
Ontologies and Problem Solving Methods During IJCAI-99, Stockholm, Sweden,
August 1999.
http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-18/7-pinto.pdf
[SMI01] Barry Smith, Christopher Welty. “FOIS introduction: Ontology
towards a new synthesis” Formal Ontology in Information Systems Proceedings
of the international conference on Formal Ontology in Information Systems -
Ogunquit, Maine, USA Pages: 3 - 9
Year of Publication: 2001 ISBN:1-58113-377-4
http://www.cs.vassar.edu/faculty/welty/papers/fois-intro.pdf
[VIS97] Pepjijn R. S. Visser and Dean M. Jones and T. J. M. Bench-Capon and
M. J. R. Shave. “An Analysis of Ontological Mismatches: Heterogeneity
versus Interoperability” Working notes of the AAAI 1997 Spring Symposium
on Ontological Engineering, Stanford University, California , USA, pp.164-172.
http://www.csc.liv.ac.uk/~kraft/publications/stanf-97.ps.gz
[WIK06] WikiPedia “Ontologia” 09/02/2006
http://it.wikipedia.org/wiki/Ontologia
[WIK07a] WikiPedia “Ontologia (informatica)” 07/02/2007
http://it.wikipedia.org/wiki/Ontologia_%28informatica%29
[WIK07b] WikiPedia “C Sharp” 17/02/2007
http://en.wikipedia.org/wiki/C_Sharp
73

Un sistema per l'integrazione di varianti di una stessa ontologia

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to Un sistema per l'integrazione di varianti di una stessa ontologia

Similar to Un sistema per l'integrazione di varianti di una stessa ontologia (20)

Un sistema per l'integrazione di varianti di una stessa ontologia