Ai miei genitori, a Fabio e alla piccola Helena

Ai miei genitori, a Fabio e alla piccola Helena

INTRODUZI ODUZIONE ONE Negli ultimi anni il World Wide Web ha avuto uno sviluppo enorme, soprattutto dovuto all'introduzione di nuove tecnologie in grado di conferire a qualsiasi utente, anche quello meno esperto, la capacità di pubblicare i propri contenuti su Internet in maniera facile e veloce. Tuttavia, la grande semplicità nel contribuire ai contenuti della rete con materiale proprio si traduce in un problema di gestione veloce ed efficace dell enorme mole di documenti che ne consegue. Per questo motivo risulta evidente come sia necessario ideare un sistema in grado di arricchire il materiale disponibile su Internet di informazioni riguardanti i contenuti pubblicati, in modo da rendere più efficiente la classificazione e l organizzazione automatica dei contenuti sulla rete e, soprattutto, le ricerche attraverso i motori di ricerca. Tale compito viene svolto principalmente grazie all uso e l interpretazione dei metadati, il cui scopo è descrivere le caratteristiche principali dei documenti presenti nella rete, in modo da rendere più veloci ed efficienti le operazioni su di essi. Ad oggi, sono state ideate soluzioni molto sofisticate per la metadatazione dei documenti scambiati attraverso sistemi di gestione documentale centralizzati. Le informazioni relative ai documenti del sistema sono contenute all interno di database creati ad hoc e ciascun set di metadati è collegato al documento cui si riferisce attraverso una tabella di references. In tali contesi la separazione tra contenuti e relativi metadati non rappresenta un grosso problema, poiché qualsiasi operazione possibile sui documenti comporta sempre e comunque il preventivo accesso al sistema i

ii INTRODUZIONE centrale: ogni ricerca, ad esempio, viene effettuata a partire dalle metainformazioni contenute all interno del database centrale e, una volta ottenuti i risultati, si viene automaticamente indirizzati verso i documenti desiderati. Inoltre l aggiornamento di tali metadati è piuttosto semplice, poiché esiste comunque un unica directory accessibile da tutti gli utenti del sistema, all interno della quale vengono gestiti i file condivisi. Il vero problema nasce nel momento in cui la struttura del sistema non è più centralizzata, bensì distribuita. Un esempio molto efficace di questa problematica si presenta, ad esempio, nei sistemi di gestione documentale basati sullo scambio di email. L efficacia della posta elettronica risiede nel fatto che si tratta di un sistema di trasmissione di informazioni molto veloce, immediato e di facile apprendimento, anche da parte di utenti poco esperti: per questo motivo lo scambio di email risulta, ad oggi, lo strumento di diffusione di documenti più utilizzato. È importante notare come l efficienza della posta elettronica come mezzo di comunicazione e di scambio di file derivi soprattutto dal fatto che, al momento dell invio di un email, si stabilisca un canale di comunicazione pressoché diretto tra mittente e destinatario: non esiste, infatti, un sistema centrale di smistamento di tutta la posta scambiata attraverso la rete, ma semplicemente degli algoritmi di routing che calcolano dinamicamente il percorso migliore verso l indirizzo di destinazione. Da questa considerazione si può facilmente dedurre quanto l estrema flessibilità ottenuta grazie alla dinamicità degli algoritmi di inoltro dei messaggi porti invece alla creazione di una rete di scambio con una struttura a grafo molto complessa e, soprattutto, decentralizzata. Per questo motivo risulta molto difficile riuscire ad integrare qualsiasi sistema di gestione documentale tradizionale con un mezzo di comunicazione tanto distribuito quanto la posta elettronica.

INTRODUZIONE iii In un contesto come quello dell UN OCHA 1, ad esempio, i funzionari delle Nazioni Unite svolgono il proprio lavoro in aree geografiche spesso disastrate da catastrofi naturali o in piena crisi umanitaria; in tali situazioni di emergenza, gli strumenti a disposizione degli operatori per la comunicazione con la sede centrale o con le unità dislocate in altre zone critiche sono limitatissimi: in genere si tratta di un computer portatile con la possibilità di connettersi ad Internet raramente e per periodi di tempo spesso molto brevi. In una situazione così disagiata diventa difficile mantenere un database centrale d'appoggio per tutti i documenti del sistema a cui far riferimento per le operazioni di retrieve: risulta più facile ed immediato lo scambio diretto di documenti tra i singoli utenti. La complessità del panorama finora descritto ha portato alla nascita di Metadata for OCHA [VIT06]. Questo progetto si propone di creare un architettura in grado di gestire uno scambio sicuro dei file all interno del sistema OCHA, garantendo che non vi sia alcuna perdita di informazioni riguardanti il loro versionamento o l autorità dei cambiamenti introdotti. A questo scopo è stato definito uno schema di metadati specifici relativi ai documenti creati e scambiati all interno del sistema e la creazione di strumenti per la gestione degli stessi. Il progetto Ontology Mail Manager nasce dalla necessità di creare un sistema in grado di mantenere sempre aggiornati (e soprattutto accessibili) i metadati relativi ai documenti scambiati via email all'interno del sistema OCHA ed ha, quindi, il compito di occuparsi dell integrazione della posta elettronica all interno del più complesso progetto Metadata for OCHA. Per prima cosa è necessario creare un ontologia in grado di descrivere in maniera appropriata i messaggi di posta elettronica e tutte le informazioni che è possibile evincere da essi. 1 United Nations Office for the Coordination of Humanitarian Affairs - Ufficio delle Nazioni Unite per gli Affari Umanitari; sito ufficiale: http://ochaonline.un.org/

iv INTRODUZIONE Bisogna inoltre ideare uno strumento in grado di generare automaticamente i metadati relativi ad ogni singola email scambiata all'interno del sistema. Il problema di rendere sempre e comunque accessibili i metadati riguardanti i documenti a disposizione dell utente può essere facilmente risolto tenendo presente uno dei principi fondamentali del progetto Metadata for OCHA : la coesistenza dei contenuti veri e propri con le specifiche metainformazioni che li descrivono; in questo modo, infatti, non è più necessario accedere ad un database centrale per poter recuperare le informazioni relative ad un certo documento di cui l utente è già in possesso: tale soluzione, tra l altro, potrebbe essere difficilmente gestibile per i funzionari OCHA, i quali potrebbero incontrare grossi problemi nel connettersi al sistema centrale dalle postazioni in cui sono dislocati. Nonostante ciò è comunque importante riuscire a mantenere una sorta di server centrale che raccolga tutta la posta scambiata e che sia in grado di compiere alcune operazioni sulle email a partire dai metadati che esse contengono. Ovviamente, è fondamentale che la raccolta di tutti i documenti del sistema venga gestita in maniera automatica, senza rallentare o complicare il lavoro dell utente; tale problema risulta di facile soluzione se al server centrale viene associato un indirizzo email, il quale può essere automaticamente inserito nella lista dei destinatari del messaggio: in questo modo viene conservata una copia di tutta la posta scambiata all interno del sistema in un unico server centrale, così da rendere semplici e veloci le operazioni di ricerca e di retrieve delle informazioni.

Indice INTRODUZIONE... I 1 IL PROBLEMA DELLA METADATAZIONE DELLE COLLEZIONI DI DOCUMENTI...1 1.1 LE ONTOLOGIE...4 1.1.1 RDF...5 1.1.2 RDFS...5 1.1.3 OWL...6 1.2 I MODELLI PER LA METADATAZIONE DI COLLEZIONI DI DOCUMENTI...6 1.2.1 Un modello teorico: An analytical model of collections and their catalogues...7 1.2.2 RSLP CD: Research Support Libraries Programme Collection Description...11 1.2.3 DCC AP: Dublin Core Collections Application Profile...13 1.2.4 NISO Z39.91-200x: NISO Collection Description Specification...14 1.2.5 Limiti dei modelli descritti...15 2 ONTOLOGY MAIL MANAGER...19 2.1 META MAIL: LA METADATAZIONE DELLA POSTA ELETTRONICA...21 2.1.1 Definizione delle classi e delle proprietà dell ontologia...23 2.1.2 Creazione e gestione dei metadati da parte dell Ontology Mail Manager.....27 2.2 METADATA CREATOR...27 2.3 MAIL AGENT...28 3 ARCHITETTURA DELL ONTOLOGY MAIL MANAGER...30 3.1 ARCHITETTURA REST PER UN SISTEMA DISTRIBUITO...33 3.1.1 Il protocollo di comunicazione: Mail Protocol...35 v

vi Indice 3.1.2 Funzionalità del Mail Protocol...38 3.1.2.1 Ricerca di messaggi scambiati all interno del sistema...38 3.1.2.2 Retrieve di un messaggio...41 3.1.2.3 Retrieve immediato...45 3.1.2.4 Aggiornamento dell'ontologia...47 3.1.2.5 Iscrizione alla mailing list...50 3.1.2.6 Annullamento iscrizione alla mailing list...51 3.1.2.7 Recupero manuale dell'ontologia...53 3.1.2.8 Help...54 3.2 IMPLEMENTAZIONE DEL METADATA CREATOR...59 3.2.1 Raccolta delle metainformazioni riguardanti il messaggio di posta...60 3.2.2 Creazione e gestione dei metadati del messaggio...61 3.3 IMPLEMENTAZIONE DEL MAIL AGENT...61 3.3.1 Accesso immediato ai metadati tramite protocollo IMAP...62 3.3.2 Interazione con il Folder Monitor...63 3.4 INTEGRAZIONE DEL SISTEMA CON I PRINCIPALI CLIENT DI POSTA ELETTRONICA...64 3.4.1 Mozilla Thunderbird...64 3.4.2 Outlook Express...67 CONCLUSIONI...71 BIBLIOGRAFIA...75 INDICE DELLE FIGURE...79 INDICE DELLE TABELLE...81 A PROTOCOLLO DI COMUNICAZIONE DELL ONTOLOGY MAIL MANAGER...83 A.1 MAIL PROTOCOL XML SCHEMA...83 B ONTOLOGIE...87 B.1 META MAIL...87 B.2 OCHA...100 RINGRAZIAMENTI...143

Capitolo 1 1 Il problema della metadatazione delle collezioni di documenti Com è possibile notare dal seguente grafico, dal 2000 in poi si è verificato un picco di incremento del numero di siti web pubblicati su Internet. Figura 1 Evoluzione di Internet dalla sua nascita 2 La causa di tale crescita può essere facilmente trovata nella repentina diffusione, avvenuta nel periodo indicato, di nuove tecnologie come i blog, i forum e simili; la caratteristica fondamentale di questi strumenti risiede 2 Fonte: http://www.inetassociation.com/timeline.html 1

2 Il problema della metadatazione delle collezioni di documenti nella loro facilità di utilizzo e di apprendimento, grazie la quale risulta possibile per tutti gli utenti, anche quelli meno esperti, pubblicare su Internet i propri contenuti in maniera semplice e veloce. Analogamente si può notare come lo stesso incremento si sia verificato per ciò che riguarda la posta elettronica, ormai diventata il più diffuso mezzo di comunicazione e di invio di documenti tra gli utenti della rete: solamente negli Stati Uniti, ad esempio, il volume della posta elettronica circolata su Internet è quasi triplicata dal 2000 ad oggi. Figura 2 Diffusione della posta elettronica dal 2000 3 La gestione di un tale quantitativo di dati viene ulteriormente complicata dall ambiguità caratteristica dei linguaggi umani, la quale risulta difficilmente interpretabile da parte dei sistemi informatici; questa considerazione può essere chiarita dal seguente esempio: inserendo il termine Aria all interno del motore di ricerca di Wikipedia si viene indirizzati ad una cosiddetta pagina di disambiguazione, la quale elenca tutti i possibili concetti che è possibile associare alla parola specificata; il risultato ottenuto è il seguente [WIK08a]: - L'aria è il miscuglio di gas che compone l'atmosfera - Aria è un comune spagnolo 3 Fonte: http://www.imediaconnection.com/content/5630.asp

Il problema della metadatazione delle collezioni di documenti 3 - L'aria è una forma musicale - Aria è un album di Alan Sorrenti - Aria è un album degli Asia - Aria è un album di Gianna Nannini - Aria è un film collettivo del 1987 diretto, tra gli altri, da Robert Altman, Jean-Luc Godard, Derek Jarman e Ken Russell - ARIA è un manga di Kozue Amano - Aria (subgenus), genus Sorbus L esempio appena illustrato dimostra come sia necessario creare un meccanismo per poter specificare in maniera precisa e non ambigua le metainformazioni riguardanti il contenuto dei documenti presenti sulla rete: in questo modo, è possibile effettuare ricerche sui metadati, ottenendo così risultati più precisi. Ad oggi, infatti, la maggior parte dei motori di ricerca utilizza criteri sintattici di analisi dei documenti (basati, cioè, sulla semplice corrispondenza di termini omografi), restituendo spesso risultati inconsistenti con la ricerca che l utente intendeva compiere realmente; l utilizzo dei metadati, invece, aumenta la raffinatezza delle operazioni di ricerca, poiché è possibile condurre analisi semantiche dei documenti sulla rete, rendendo così possibile per i motori di ricerca selezionare i risultati in base al concetto espresso, anche se descritto utilizzando termini che non coincidono con quelli specificati dall utente. Inoltre le metainformazioni possono essere utilizzate per definire criteri di aggregazione da utilizzare per organizzare i documenti digitali in collezioni. L appartenenza di un documento ad una certa collezione, infatti, lo arricchisce di ulteriori significati circa il contesto all interno del quale si colloca: ciò rende molto più efficiente l indicizzazione dei documenti da parte dei motori di ricerca, rendendo molto più veloci ed efficaci la ricerca ed il reperimento dei risultati ottenuti. L esigenza di organizzare i contenuti in collezioni (ciascuna delle quali descritta da opportuni metadati) deriva dalla necessità di velocizzare e rendere più efficiente la gestione di grosse quantità di dati; ciò è reso possibile dal fatto che la metadatazione di collezioni crei una descrizione ad

4 Il problema della metadatazione delle collezioni di documenti alto livello di tutto il set di dati, fornendo così informazioni generali circa la sua struttura, i singoli elementi che lo compongono, i criteri di aggregazione tra di essi e le relazioni esistenti tra un documento e l altro. Il vantaggio più evidente che deriva da questo tipo di organizzazione dei contenuti è la maggiore efficienza nella ricerca di informazioni all interno di sistemi che si trovano a dover gestire un elevato numero di documenti: a scapito di un leggero incremento del costo da sostenere durante la fase di inserimento del documento all interno del sistema, la qualità della ricerca aumenta notevolmente e si traduce in una drastica diminuzione del tempo necessario a ricavare le informazioni cercate. Dal ragionamento appena esposto, emerge chiaramente la necessità di creare dei modelli formali in grado di descrivere la realtà riguardante l organizzazione in collezioni di un elevato numero di documenti: tali schemi prendono il nome di ontologia. 1.1 Le ontologie In filosofia, il termine ontologia assume letteralmente il significato di studio dell essere e si tratta di quella branca della metafisica il cui scopo è fornire una spiegazione di che cosa sia l essere in quanto tale e quali siano le categorie fondamentali attraverso cui esso si manifesta. Tale termine è stato ereditato dall informatica ed indica il tentativo di creare uno schema in grado di descrivere una porzione di realtà, all interno di un dominio ben definito, specificando le entità (classi) che la compongono e le relazioni che esistono tra di esse; queste ultime possono essere di vario tipo e specificano che tipo di legame mette in relazione tra loro diverse entità appartenenti allo stesso dominio di definizione, creando così una serie di regole sintattiche che è possibile utilizzare per esprimere affermazioni sulla realtà così modellata. Le ontologie vengono specificate sulla base di tre specifiche tecnologie: RDF, RDFS e OWL.

Il problema della metadatazione delle collezioni di documenti 5 1.1.1 RDF Il Resource Description Framework (RDF) [W3C04a] è un modello astratto il cui scopo è fornire un meccanismo generale per rappresentare ed esprimere affermazioni circa le risorse presenti sul Web. Il modello è molto semplice e si basa sul concetto di RDF triple; questo oggetto consiste in una terna composta dai seguenti valori: un soggetto, il quale è un riferimento RDF ad un URI oppure un nodo vuoto, un predicato, il quale è un riferimento RDF ad un URI e un oggetto, il quale è un riferimento RDF ad un URI, un letterale oppure un nodo vuoto. È possibile, quindi, descrivere in maniera completa ogni risorsa presente sul web attraverso la specificazione di terne del tipo soggetto-predicatooggetto, secondo lo schema appena illustrato. È comunque importante sottolineare che RDF fornisce esclusivamente un modello astratto per la descrizione delle risorse e non dà alcuna indicazione sul linguaggio da utilizzare per la rappresentazione dei concetti espressi secondo questo schema. 1.1.2 RDFS L RDF Schema (RDFS) [W3C04b] è un estensione semantica di RDF, sulla cui base si definisce un linguaggio per la specificazione di un vocabolario RDF. Lo Schema descrive le classi che rappresentano le risorse da metadatare e le proprietà che creano delle relazioni tra le classi soggetto ed il relativo oggetto ; tale distinzione viene formalizzata all interno del linguaggio introducendo i concetti di dominio e range (o codominio) delle proprietà. È possibile inoltre creare delle relazioni gerarchiche tra le entità specificando il concetto di subclassof, il quale permette alle classi che derivano da una classe principale di ereditarne tutte le proprietà, secondo un approccio Object Oriented simile a Java; un discorso analogo può essere

6 Il problema della metadatazione delle collezioni di documenti fatto per ciò che riguarda la capacità delle proprietà di poter derivare da altre proprietà. In conclusione RDF Schema definisce un linguaggio molto semplice basato sul modello RDF, tramite il quale è possibile descrivere tutte le risorse presenti sul Web. 1.1.3 OWL OWL (Web Ontology Language) [W3C04c] è un linguaggio per la serializzazione di modelli ontologici per la descrizione di documenti ed applicazioni presenti sul Web. Questo linguaggio si basa su RDF ed RDFS, estendendo il vocabolario di quest ultimo: OWL, infatti, introduce alcuni importanti concetti, come quelli di disgiunzione e di uguaglianza tra classi, di cardinalità, di tipizzazione delle proprietà del modello, ecc.: in questo modo è possibile esprimere affermazioni molto più complesse di quanto non sia possibile con RDF Schema. OWL, quindi, rappresenta un linguaggio più complesso, e quindi anche più completo per la creazione di ontologie Web-based. 1.2 I modelli per la metadatazione di collezioni di documenti In generale, per modello si intende una rappresentazione di un oggetto o di un fenomeno, in grado di riprodurre caratteristiche o comportamenti ritenuti fondamentali per l ambito all interno del quale viene creato [WIK08b]; analogamente, un modello ontologico descrive le entità che appartengono ad un certo dominio e le relazioni che esistono tra esse. Un modello ontologico è formato da un certo numero di classi, ciascuna della quali rappresenta un entità appartenente alla realtà di riferimento; a partire da queste, similmente a quanto succede in un modello ad oggetti, possono essere istanziati degli individui, i quali rappresentano un singolo oggetto definito a partire dall entità descritta dalla classe cui appartengono. Ogni oggetto del modello, infine, può essere ulteriormente specificato dalla

Il problema della metadatazione delle collezioni di documenti 7 presenza di eventuali attributi e può essere associato ad un altro per mezzo di proprietà. Per poter formalizzare ontologie in grado di descrivere in maniera esaustiva la porzione di realtà cui si riferiscono, quindi, è necessario che esse si sviluppino a partire da modelli ben strutturati, capaci di rappresentare tutte e solo le entità più importanti concernenti la realtà da descrivere. Nei prossimi paragrafi sarà condotta un analisi riguardante i più diffusi modelli per la metadatazione delle collezioni di documenti. Innanzitutto sarà presentato un modello teorico, il cui scopo è dare una visione generale di quali siano le caratteristiche principali di cui tener conto per specificare le metainformazioni riguardanti qualsiasi tipo di collezione (sia fisica che digitale); in seguito si analizzeranno i più importanti progetti sviluppati sulla base del modello teorico presentato, alcuni dei quali coinvolgono le più importanti organizzazioni che si occupano di standard, tra cui, ad esempio, Dublin Core Metadata Initiative (DCMI) e NISO (National Information Standars Organization). Nel capitolo 2, infine, ci si occuperà della creazione di un modello specifico per la metadatazione della posta elettronica. Sulla base dello schema così ottenuto, sarà sviluppata un ontologia per la descrizione delle metainformazioni relative alle collezioni di email, con lo scopo di colmare le lacune presentate dai modelli che verranno descritti a breve. 1.2.1 Un modello teorico: An analytical model of collections and their catalogues Esistono molti modelli per descrivere collezioni (sia fisiche che digitali), la maggior parte delle quali si basa sullo schema descritto da Michael Heaney nel 2000 all interno del suo studio An analytical model of collections and their catalogues [HEA00]. Il concetto fondamentale su cui si basa questo modello teorico è quello di information landscape : la realtà è vista come un paesaggio che è possibile descrivere attraverso una mappa a curve di livello, tenendo conto solo dei dislivelli che la caratterizzano e

8 Il problema della metadatazione delle collezioni di documenti tralasciando invece tutti i dettagli relativi i singoli elementi che contiene e che causano le disomogeneità che la sua superficie presenta 4. Lo stesso concetto è applicabile alle collezioni di oggetti digitali e fisici, ambito all interno del quale il concetto di Information Landscape prende il nome di Collection Level Description : la collezione può essere descritta secondo vari gradi di accuratezza, partendo da un livello più generale, per poi passare ad un livello di dettaglio via via più specifico. Heaney distingue tra quattro differenti tipi di descrizione delle collezioni ( Collection- Description ): 1. Unitary: viene descritta la collezione nella sua totalità, senza fornire alcuna informazione circa i singoli elementi che la compongono, a meno che questi non contengano importanti informazioni contestuali circa la collezione stessa; 2. Hierarchic: vengono descritte le informazioni circa la collezione intesa nella sua totalità, ma anche quelle riguardanti gli elementi che la compongono, il loro contenuto ed il contesto cui appartengono, tenendo conto delle relazioni gerarchiche che sussistono tra i vari elementi; 3. Analytic: crea una lista dei singoli elementi che compongono la collezione, fornendo anche una descrizione del loro contenuto; 4. Indexing: vengono descritte le informazioni che è possibile raccogliere circa i singoli elementi che compongono la collezione. Ogni collezione può essere rappresentata secondo uno dei profili appena elencati; questa modularità permette la creazione di diversi tipi di descrizione, ciascuno dei quali in grado di gestire informazioni a vari livelli di completezza e, quindi, di complessità. 4 The information landscape can be seen as a contour map in which there are mountains, hillocks, valleys, plains and plateaux. A large general collection of information say a research library can be seen as a plateau, raised above the surrounding plain. A specialized collection of particular importance is like a sharp peak. Upon a plateau there might be undulations representing strengths and weaknesses.

Il problema della metadatazione delle collezioni di documenti 9 La figura seguente rappresenta il grado di dettaglio associato a ciascun tipo di Collection-Description : Figura 3 AMCC: Relazione tra Collezioni e Descrizione delle Collezioni Heaney propone un proprio schema, col quale cerca di dare una visione di tipo Unitary delle collezioni. L entità principale del modello è la classe Collection, la quale rappresenta, per l appunto, un aggregato di oggetti aventi certe caratteristiche comuni. Attraverso la proprietà Is-Gathered-Into è possibile ricavare quali siano i singoli oggetti ( Item ) che compongono la collezione. Di ogni oggetto rappresentato è possibile ricavare il contenuto (tramite la relazione Is-Embodied-In con la classe Content ) e le parti in cui esso è articolato (grazie alle proprietà Has-Part e Is-Embodied-In, che mettono in relazione la classe Item con le classi I-Component e CN-Component, rispettivamente). È possibile inoltre descrivere il produttore (rappresentato dalla classe Producer e collegato all oggetto per mezzo della proprietà Produces ). Un altra classe molto importante è Collector, la quale rappresenta un Agent il cui scopo è l aggregazione di oggetti di tipo Collection per mezzo della proprietà Collects, creando così vere e proprie collezioni di collezioni.

10 Il problema della metadatazione delle collezioni di documenti Tale modello è rappresentato dal seguente schema: Figura 4 AMCC: schema della classe Collection L altra entità fondamentale del modello di Heaney è rappresentata dalle Collection-Description. Il modello che le descrive è molto simile a quello che rappresenta le Collection ; l unica eccezione è data dalle proprietà aggregatrici, le quali permettono alle Collection-Description di essere formate da un solo oggetto. Il resto del modello rimane inalterato: in modo analogo a quanto accade per le Collection, infatti, è possibile indicare creatore ( Producer ) e contenuto ( Content ) della Description, le parti ( CN-Component ) in cui essa è articolata, ecc.

Il problema della metadatazione delle collezioni di documenti 11 Tale modello può essere rappresentato graficamente nel modo seguente: Figura 5 AMCC: schema della classe Collection-Description È importante notare, infine, che le Collection-Description possono essere specificate secondo diversi tipi di dettaglio, così come indicato ad inizio paragrafo: il tipo di descrizione indica il punto da cui la Collection- Description accede allo schema della Collection, determinando così quali saranno le proprietà e gli attributi della collezione visibili per la specificazione della sua descrizione. Numerosi schemi di metadati sono stati sviluppati a partire dal modello teorico di Heaney: in seguito ne vengono illustrati solo alcuni. 1.2.2 RSLP CD: Research Support Libraries Programme Collection Description L RSLP CD [POW00] è uno schema di descrizione delle collezioni ideato da Andy Powell sulla base del modello teorico proposto da Heaney ed il cui scopo fondamentale è creare un set strutturato di metadati per la descrizione delle collezioni. Lo schema sviluppato si basa sulla necessità delle biblioteche di integrare le descrizioni dei singoli elementi con una descrizione a livello generale

12 Il problema della metadatazione delle collezioni di documenti dell intera collezione, utilizzando formati strutturati, aperti, standard e machine-readable. L RSLP CD Schema implementa una versione semplificata del modello di Heaney ed è quindi sviluppato utilizzando l architettura RDF. L entità principale del modello è, analogamente a quanto accade per lo schema di Heaney, la classe Collection. La relazione collects, la quale unisce Collector e Collection, specifica come esistano degli oggetti aggregatori che possano includere una o più collezioni, diventando così essi stessi delle vere e proprie collezioni. Di ogni collezione, infine, è possibile descrivere le informazioni riguardanti la sua Location (ovvero il luogo, fisico o virtuale, in cui si trova la collezione), l Owner (l Agent che detiene la proprietà legale della collezione) e l Administrator (colui o colei che detiene i diritti di amministrazione della Location all interno della quale è contenuta la collezione). Le relazioni appena descritte sono illustrate dal seguente schema: Figura 6 RSLP CD Schema Lo schema ideato da Powell supporta la creazione di Unitary Finding- Aids, ovvero di una descrizione a livello generale dell intera collezione. È infine importante notare come le proprietà specificate siano state ereditate da schemi di metadati già esistenti come, ad esempio, il Dublin

Il problema della metadatazione delle collezioni di documenti 13 Core Metadata Element Set [DCM08] ed alcuni attributi dello schema vcard [W3C01]. Per una trattazione più specifica dell RSLP CD Schema si fa riferimento al sito ufficiale del progetto [POW00]. 1.2.3 DCC AP: Dublin Core Collections Application Profile Il Dublin Core Application Profile [DCC07] è il tentativo del DC Collection Description Task Group di formalizzare l RSLP CD Schema utilizzando i termini del core. Il compito principale di tale progetto è definire un subset di elementi Dublin Core tramite i quali creare uno schema in grado di descrivere esaustivamente le collezioni ed i relativi cataloghi (un insieme, cioè, di metadati riguardanti una specifica collezione). Tale progetto è tuttora in corso e, ad oggi, ha sviluppato una serie di bozze di schemi per la descrizione delle collezioni digitali e fisiche. Per, sono previste due classi principali: Collection e Catalogue, le quali indicano, rispettivamente, una collezione (di qualsiasi tipo e dimensione) e la sua descrizione. Per ciascuna di esse, analogamente a quanto accade nel modello di Powell, può essere specificata una Location ad indicare il luogo (fisico o virtuale) in cui si trova la risorsa. In maniera leggermente differente all RSLP CD Schema, invece, sono gestite la proprietà e la creazione della collezione: in questi casi la classe Collection è collegata all entità generica Agent tramite le relazioni owns, nel primo caso, e collects, nel secondo. È importante notare come venga introdotto il concetto di Item, il quale rappresenta i singoli elementi che compongono la collezione: tale classe è collegata all entità Collection tramite la relazione is-gathered-into. Inoltre viene inserita nel modello l entità Service, la quale fornisce una descrizione del servizio che è necessario utilizzare per poter accedere alla collezione.

14 Il problema della metadatazione delle collezioni di documenti Lo schema seguente illustra graficamente la struttura del modello appena descritto: Figura 7 DCC AP Schema 1.2.4 NISO Z39.91-200x: NISO Collection Description Specification Lo schema di descrizione delle collezioni della NISO [NIS05] è anch esso un Dublin Core Application Profile, il quale è stato sviluppato a partire dallo schema descritto nel paragrafo precedente. L entità fondamentale del modello è descritta dalla classe Collection, la quale può essere descritta solo in termini di altre collezioni o, in alternativa, di Subject Completeness Indicator : ciascuno di questi oggetti è composto da un soggetto, il quale deve essere un termine riconducibile ad uno schema, e da un livello di completezza che dia una misura della profondità, all interno della collezione, del soggetto specificato.

Il problema della metadatazione delle collezioni di documenti 15 Anche in questo schema, quindi, viene fornita una visione della collezione di tipo Unitary, caratterizzata da una descrizione molto generale che specifica le proprietà della collezione intesa come un unica entità, mentre tutti i dettagli relativi i singoli elementi che la compongono sono totalmente trascurati. 1.2.5 Limiti dei modelli descritti I modelli finora descritti risultano molto efficaci per quanto concerne la metadatazione dei documenti digitali al fine di organizzare gli stessi in collezioni. È da notare comunque che ciascuno di essi tratta le collezioni in maniera molto generale; nessuno dei modelli appena descritti, infatti, sarebbe in grado di descrivere in maniera completa i messaggi di posta elettronica: non è previsto, ad esempio, alcun meccanismo per descrivere in maniera appropriata gli attori coinvolti nella comunicazione email, né il ruolo che essi ricoprono durante lo scambio di messaggi. Per dimostrare tale affermazione, è possibile tentare di applicare i modelli descritti finora al dominio dello scambio della posta elettronica. Innanzitutto si può provare ad applicare l RSLP CD Schema, considerando l insieme di tutti messaggi scambiati all interno di un sistema come la Collection da descrivere. Figura 8 RSLP CD Schema per la descrizione della posta elettronica

16 Il problema della metadatazione delle collezioni di documenti Dallo schema ricavato è possibile notare come la posta elettronica possa essere descritta solo a livello molto generale e che esprimere alcuni concetti specifici delle email risulta impossibile poiché mancano le classi necessarie a rappresentarli. Se proviamo ad inserire nel modello gli agenti coinvolti nello scambio, ad esempio, è possibile tener conto solamente del Destinatario o del Mittente, ma mai di entrambi contemporaneamente: solamente uno di questi agenti può essere rappresentato dall RSLP CD Schema per mezzo della classe Collector, e ciò dipende dalla scelta del criterio secondo il quale si intende organizzare la collezione (se per mittente o per destinatario). Nell eventualità in cui il Collector sia il destinatario, inoltre, non esiste un meccanismo che ne specifichi il tipo (To, Cc o Bcc). È importante comunque notare come non sia minimamente possibile fare dei riferimenti specifici relativi ai singoli oggetti che compongono la collezione: l RSLP CD Schema, infatti, si propone di fornire una descrizione di tipo Unitary delle collezioni. Il limite intrinseco al modello appena presentato, quindi, non rende possibile affermare, ad esempio, se l email contiene degli allegati, quale siano l oggetto ed il contenuto, quale sia la priorità associata, ecc.: in questo modo, non è possibile specificare quei criteri di aggregazione attraverso i quali poter efficientemente organizzare tali documenti in collezioni digitali. È possibile, quindi, tentare di descrivere la posta elettronica tramite il Collection Application Profile del Dublin Core Metadata Initiative. In questo modello, infatti, viene introdotto il concetto di Item tramite il quale dovrebbe essere possibile dare una descrizione dettagliata delle proprietà riguardanti le singole email che compongono la collezione.

Il problema della metadatazione delle collezioni di documenti 17 Il seguente schema rappresenta il tentativo di rappresentare la posta elettronica attraverso il DCC AP: Figura 9 DCC AP Schema per la descrizione della posta elettronica Si può notare come, applicando questo modello, sia possibile creare un indice dei messaggi scambiati all interno del sistema. Tuttavia non è possibile tener conto di altre caratteristiche molto importanti ai fini di eventuali ricerche all interno della collezione quali il contenuto delle email, l oggetto, la priorità associata, ecc. Per questo motivo anche il DCC AP risulta essere uno schema poco efficace per la descrizione della posta elettronica. Il modello proposto dalla NISO, infine, similmente a quanto accade per l RSLD CD Schema, risulta inappropriato per la descrizione della posta

18 Il problema della metadatazione delle collezioni di documenti elettronica, poiché ha lo scopo di descrivere le collezioni in termini di altre collezioni: utilizzando tale modello, quindi, tutte le informazioni relative alle singole email andrebbero perdute. Per questo motivo è necessario creare una specifica ontologia il cui scopo è la descrizione di tutti gli aspetti riguardano lo scambio di posta elettronica.

Capitolo 2 2 Ontology Mail Manager Metadata for OCHA [VIT06] è un progetto che si propone di creare un architettura per lo scambio sicuro dei file dell Ufficio delle Nazioni Unite per gli Affari Umanitari; tale progetto si basa principalmente sulla specificazione e l aggiornamento dei metadati che descrivono i documenti condivisi all interno del sistema. A questo scopo, il progetto Metadata for OCHA prevede la specificazione di un ontologia in grado di descrivere le metainformazioni riguardanti i file scambiati, ma anche quelle circa i funzionari delle Nazioni Unite che agiscono su di essi, specificandone i dati personali, il ruolo che ricoprono all interno dell organizzazione, l ufficio cui appartengono, eccetera. Inoltre Metadata for OCHA prevede l introduzione di alcuni strumenti per la gestione dei file del sistema basata essenzialmente sull interpretazione dei metadati che li descrivono. Ontology Mail Manager implementa quella parte del progetto Metadata for OCHA che si occupa della gestione e della metadatazione della posta elettronica, creando un ontologia in grado di descrivere in maniera adeguata tutte le proprietà caratteristiche delle email; a tal scopo, inoltre, il progetto implementa quegli strumenti necessari alla creazione dei metadati relativi ai messaggi scambiati ed alla loro gestione sulla base dell interpretazione delle metainformazioni che li descrivono. 19

20 Ontology Mail Manager A questo scopo sono stati sviluppati due moduli per la gestione della posta elettronica: il Metadata Creator ed il Mail Agent. Il primo si occupa della creazione dei metadati riguardanti i messaggi di posta in uscita sulla base di un ontologia condivisa da tutti gli utenti del sistema; ha inoltre il compito di inserire tali metadati all interno dell email, in modo da renderli facilmente accessibili a chi riceverà il messaggio; il Metadata Creator, infine, gestisce tutta la posta in uscita dell utente, inviandone una copia ad un determinato indirizzo email associato al Mail Agent (l altro modulo implementato dall Ontology Mail Manager). Il compito principale del Mail Agent, invece, è fornire agli utenti alcuni servizi che permettano loro di compiere le operazioni di retrieve e di aggiornamento dell ontologia; gli utenti possono inoltre compiere ricerche tra i messaggi scambiati all interno del sistema ed hanno la possibilità di ricevere via email una copia dei risultati ottenuti. Il Mail Agent, infine, si integra con un altro modulo del progetto Metadata for OCHA : il Folder Monitor. Questa applicazione si occupa di rilevare qualsiasi cambiamento effettuato dagli utenti all interno della cartella condivisa e, quando ciò accade, di validare i metadati contenuti all interno dei documenti appena salvati; poiché il Mail Agent ha il compito di memorizzare automaticamente all interno della cartella condivisa tutti i file ricevuti in allegato ai messaggi di posta in arrivo, ogni volta che ciò accade il Folder Monitor rileverà tale cambiamento, compiendo le proprie operazioni di validazione. In caso di errore, il Mail Agent deve fornire al Folder Monitor un servizio che permetta all applicazione di inviare tutte le comunicazioni del caso all utente che ha tentato la creazione o l aggiornamento del file che ha generato la situazione d errore.

Ontology Mail Manager 21 2.1 Meta Mail: la metadatazione della posta elettronica A partire dai modelli di metadatazione finora presentati, è possibile notare come non sia previsto uno specifico schema in grado di rappresentare in maniera esaustiva tutte le caratteristiche tipiche dei messaggi di posta elettronica. Per questo motivo è stato necessario creare uno schema ontologico in grado di descrivere in maniera appropriata tutti gli aspetti che riguardano lo scambio di email. A tal scopo si è fatto riferimento al modello teorico di Heaney, cercando di fornire una descrizione di tipo Analytic delle collezioni di documenti inviati tramite posta elettronica; per questo motivo il focus è stato concentrato maggiormente sugli Item del modello: a partire dai metadati specificati per la loro descrizione sarà in seguito possibile estrarre i criteri di aggregazione per la creazione dinamica di collezioni di tali oggetti. L entità principale dell ontologia è definita dalla classe Email e rappresenta un messaggio di posta elettronica. La classe Agente deriva direttamente dalla classe Person dell ontologia OCHA e rappresenta gli attori coinvolti nello scambio di email. Esistono due tipi di Agente, a seconda del ruolo ricoperto nella transazione: il Mittente è colui o colei che invia il messaggio; il Destinatari, invece, è la persona che lo riceve. Ogni Agente è identificato in modo univoco dal proprio indirizzo email ed, eventualmente, da un nickname visualizzato dal client di posta elettronica come mittente/destinatario dell email scambiata; ciascuno dei destinatari dell'email, inoltre, può essere di tre tipi: il destinatario principale (To), il destinatario in copia carbone (Cc) o il destinatario in copia carbone nascosto (Bcc). Di ogni email scambiata si tiene traccia della data e dell ora di creazione e di invio; ogni messaggio di posta elettronica, inoltre, può contenere o meno del testo nel proprio body e ad esso può essere associato un oggetto che sintetizzi le informazioni che vengono trasmesse con l invio.

22 Ontology Mail Manager Ad ogni messaggio viene inoltre assegnata una priorità, che può essere alta, normale o bassa (il valore di default è normale ); ciascuna email, poi, può essere inoltrata o essere oggetto di risposta da parte del destinatario. Il messaggio di posta elettronica, infine, può eventualmente contenere uno o più allegati, ciascuno dei quali identificato attraverso il proprio nome di file; ogni attachment, inoltre, è rappresentato per mezzo della classe Allegato, la quale deriva direttamente dalla superclasse File dell ontologia OCHA. La figura a seguire fornisce una rappresentazione grafica dello schema ontologico appena descritto. Legenda: Class Subclass ObjectProperty DatatypeProperty

Ontology Mail Manager 23 Figura 10 Schematizzazione dell'ontologia Meta Mail 2.1.1 Definizione delle classi e delle proprietà dell ontologia Seguendo lo schema appena illustrato è stata sviluppata l ontologia Meta Mail, la quale si propone di fornire una descrizione completa dei messaggi di posta elettronica scambiati all interno del sistema Ontology Mail Manager. In seguito vengono illustrate tutte le classi e le proprietà che compongono l ontologia Meta Mail. Tabella 1 META MAIL: Classi dell'ontologia URI Label Definition Super-class URI Label Definition Super-class URI Label Definition Super-class URI Label Definition URI Label Definition Super-class Agente http://tuori.web.cs.unibo.it/ontologia/metamail.owl#agente Agente Rappresenta una persona o un ente coinvolto nello scambio di posta elettronica. http://www.owl-ontologies.com/ocha.owl#person Allegato http://tuori.web.cs.unibo.it/ontologia/metamail.owl#allegato Allegato Rappresenta un file inviato come allegato all email. http://www.owl-ontologies.com/ocha.owl#file Destinatario http://tuori.web.cs.unibo.it/ontologia/metamail.owl#destinatario Destinatario Rappresenta la persona o l ente che riceve l email. Agente Email http://tuori.web.cs.unibo.it/ontologia/metamail.owl#email Email Rappresenta il messaggio di posta elettronica scambiato. Mittente http://tuori.web.cs.unibo.it/ontologia/metamail.owl#mittente Mittente Rappresenta la persona o l ente che invia l email. Agente

24 Ontology Mail Manager Tabella 2 META MAIL: Proprietà di tipo ObjectProperty dell ontologia allegatoa URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#allegatoa Label allegatoa Definition Proprietà che mette in relazione un File con l Email a cui è allegato. Comment La proprietà ha cardinalità (1, 1). Domain Allegato Range Email Inverse of haallegato forward URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#forward Label forward Definition Proprietà che mette in relazione un Email con un altra Email che ne rappresenta un inoltro a terzi. Comment La proprietà ha cardinalità (1, 1). Domain Email Range Email haallegato URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#haallegato Label haallegato Definition Proprietà che mette in relazione un Email con il File che ha in allegato. Comment La proprietà ha cardinalità (0, N). Domain Email Range Allegato Inverse of allegatoa inviataa URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#inviataa Label inviataa Definition Proprietà che mette in relazione un Email con uno dei suoi Destinatari. Comment La proprietà ha cardinalità (1, N). Domain Email Range Destinatario

Ontology Mail Manager 25 inviatada URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#inviatada Label inviatada Definition Proprietà che mette in relazione un Email con il Mittente che l ha inviata. Comment La proprietà ha cardinalità (1, 1). Domain Email Range Mittente reply URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#reply Label reply Definition Proprietà che mette in relazione un Email con un altra Email che ne rappresenta la risposta al solo mittente originale. Comment La proprietà ha cardinalità (1, 1). Domain Email Range Email replyall URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#replyall Label replyall Definition Proprietà che mette in relazione un Email con un altra Email che ne rappresenta una risposta multipla (ovvero inviata da uno dei destinatari dell email originale ed indirizzata al mittente originario ed agli altri destinatari). Comment La proprietà ha cardinalità (1, 1). Domain Email Range Email Tabella 3 META MAIL: Proprietà di tipo DatatypeProperty dell ontologia creatail URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#creatail Label creatail Definition Proprietà che specifica la data di creazione di un Email. Comment La proprietà ha cardinalità (1, 1). Domain Email Range http://www.w3.org/2001/xmlschema#string hacontenuto URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#hacontenuto Label hacontenuto Definition Proprietà che specifica l eventuale testo contenuto nel body di un Email. Comment La proprietà ha cardinalità (0, 1).

26 Ontology Mail Manager Domain Email Range http://www.w3.org/2001/xmlschema#string haoggetto URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#haoggetto Label haoggetto Definition Proprietà che specifica l eventuale oggetto di un Email Comment La proprietà ha cardinalità (0, 1). Domain Email Range http://www.w3.org/2001/xmlschema#string hapriorita URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#hapriorita Label hapriorita Definition Proprietà che specifica la priorità assegnata ad un Email. Comment La proprietà ha cardinalità (1, 1). Domain Email Range http://www.w3.org/2001/xmlschema#string; one of: - alta - normale - bassa inviatail URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#inviatail Label inviatail Definition Proprietà che specifica la data di invio di un Email. Comment La proprietà ha cardinalità (1, 1) Domain Email Range http://www.w3.org/2001/xmlschema#string parlalingua URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#parlalingua Label parlalingua Definition Proprietà che specifica una lingua (specificata secondo ISO 639-3) parlata da un Agente. Comment La proprietà ha cardinalità (0, N). Domain Agente Range http://www.w3.org/2001/xmlschema#string; in particolare verrà utilizzata una sequenza di tre caratteri per identificare la lingua, secondo lo standard ISO 639-3. tipodestinatario URI http://tuori.web.cs.unibo.it/ontologia/metamail.owl#tipodestinat ario Label tipodestinatario

Ontology Mail Manager 27 Definition Proprietà che specifica di che tipo è un Destinatario dell Email (To, Cc, Bcc). Comment La proprietà ha cardinalità (1, 1) Domain Destinatario Range http://www.w3.org/2001/xmlschema#string; one of: - To - Cc - Bcc 2.1.2 Creazione e gestione dei metadati da parte dell Ontology Mail Manager Il meccanismo di specificazione dei metadati è implementato nella posta elettronica attraverso l uso degli headers, descritti nell RFC 2822 ( Internet Message Format ) [NWG01a]: si tratta di messaggi testuali che forniscono le metainformazioni riguardanti l email all interno della quale sono contenuti. È importante notare come lo standard impolementi la creazione di nuovi headers da parte dell utente, i cosiddetti Optional Fields. Il vincolo che è necessario rispettare perché questi possano essere specificati all interno delle email è che non abbiano lo stesso nome di altri headers noti (quelli, cioè, già previsti dall RFC 2822); per convenzione, il nome di questi campi inizia con la sequenza X-. Ogni volta che il client di posta elettronica invia un nuovo messaggio, il Metadata Creator genera i metadati che descrivono l email processata; questi saranno espressi in linguaggio OWL ed inseriti all interno del messaggio utilizzando un apposito header chiamato X-Ontology-Mail- Manager, secondo le specifiche dello standard Internet Message Format. 2.2 Metadata Creator Il Metadata Creator è un modulo installato sulla macchina di ciascun utente del sistema il cui compito è metadatare tutta la posta in uscita secondo lo schema dell ontologia Meta Mail, reperendo automaticamente tutte le informazioni necessarie e svolgendo le proprie funzioni senza che sia necessario il continuo intervento da parte dell utente.

28 Ontology Mail Manager Questo modulo si occupa inoltre dell invio al server centrale di una copia di ciascun messaggio di posta scambiato all interno del sistema: a tale scopo l indirizzo email del Mail Agent viene aggiunto in Bcc alla lista dei destinatari originali dell email. Il Metadata Creator si frappone tra il client di posta elettronica ed il server SMTP vero e proprio intercettando tutta la posta in uscita ed eseguendo le operazioni di metadatazione della stessa. Una volta ricevuto il messaggio inviato dal client, il processo di metadatazione dell email si svolge secondo due fasi: la raccolta delle metainformazioni relative allo scambio ed il loro successivo invio. Per prima cosa il Metadata Creator reperisce le informazioni necessarie alla specificazione dei metadati leggendo il contenuto degli headers del messaggio; in seguito il modulo recupera ulteriori informazioni riguardanti il mittente da un file di configurazione in cui l utente avrà immesso i propri dati personali al momento dell installazione. Infine l aplicazione inserisce i metadati creati, specificati in linguaggio OWL, all interno di un apposito header dell email ed inoltra il messaggio di posta elettronica al server SMTP, il quale provvederà all invio vero e proprio. 2.3 Mail Agent Il Mail Agent è un modulo installato sul server centrale che, agendo come un utente di un server IMAP, salva automaticamente tutta la posta in entrata; l applicazione fornisce inoltre i servizi necessari per la gestione dei messaggi ricevuti e dell ontologia Meta Mail. Le operazioni possibili all interno del sistema sono essenzialmente la possibilità di effettuare delle ricerche di messaggi sulla base dei metadati in essi contenuti ed il retrieve delle email trovate. Per quanto concerne la gestione dei metadati, il Mail Agent offre un sistema di aggiornamento dell ontologia da parte degli utenti: tale operazione richiede l invio lato client di un messaggio di posta elettronica contenenente la richiesta, opportunamente specificata secondo la sintassi del