Meccanismi di rappresentazione ed estrazione delle metainformazioni. Andrea Giovanni Nuzzolese

Transcript

1 Meccanismi di rappresentazione ed estrazione delle metainformazioni Andrea Giovanni Nuzzolese 29 giugno 2006

2 Indice Introduzione 2 1 Analisi del crawler non semantico Concetti di base Architettura di un crawler non semantico Studio del crawler semantico Introduzione al crawler semantico Dal crawler non semantico a quello semantico Architettura generale del crawler semantico Il parsing semantico Connessione al database Gestione del database e memorizzazione delle metainformazioni Conclusioni 16 Bibliografia 17 1

3 Introduzione L obiettivo del tirocinio è stato quello di studiare e sviluppare un meccanismo di rappresentazione ed estrazione delle matainformazioni per la realizzazione di un crawler per un motore di ricerca semantico all interno del dominio unibo. Per studiare e sviluppare un tale meccanismo efficiente si è fatto ricorso a teorie di Information Retrieval [RBY99], che è una materia che tratta problemi di rappresentazione, memorizzazione, organizzazione ed accesso ad informazioni. Si è cercato quindi di utilizzare, nell ambito del progetto, alcuni concetti che sono alla base degli obiettivi dell Information Retrieval, come cercare di ottenere una memorizzazione efficiente delle metainformazioni per cercare di facilitare un successivo acceso tramite query da parte di un utente. La necessità di dover accennare ad alcune teorie dell Information Retrieval deriva non solo da quanto appena detto ma, anche dalla definizione stessa di Information Retrieval, che formalmente è una quadrupla [Vel04] [D,Q,F,R(q k, d j )] dove : D è un insieme di viste logiche, o rappresentazioni dei documenti nella collezione Q è un insieme di viste logiche, o rappresentazioni dei bisogni informativi dell utente, dette query F è uno schema per modellare le rappresentazioni dei documenti, le query, e le interrelazioni fra query e documenti R(q i, d j ) è una funzione di rilevanza, o ranking R : Q D R che definisce un ordine fra i documenti, in relazione alla query q i Quello che interessa della definizione appena data, ai fini del nostro progetto, è lo schema F, infatti esso può essere descritto da un ontologia, che è alla base del crawler semantico di cui si sono voluti studiare e sviluppare alcuni aspetti all interno di questo tirocinio. È importante fornire anche una definizione formale di ontologia, in quanto su di essa vengono costruiti i documenti RDF/OWL che sono relativi alle risorse del dominio unibo di cui si vogliono fornire una rappresentazione semantica e che sono l oggetto della nostra fase di crawling. Un ontologia può essere definita quindi, come una tripla [DLM04] (C, R, A) dove 2

4 C è un insieme di concetti (detti anche classi) R è un insieme di relazioni concettuali tali che ogni relazione in R è definita su C C A è un insieme di assiomi La definizione appena data è importante perché aiuta a capire come vengono organizzate le metainformazioni in un documento semantico e fornisce una prima idea su come un crawler semantico dovrebbe comportarsi per recuperarle. Infatti, se si focalizza l attenzione sugli insiemi C ed R, si nota che essi individuano un grafo G = (V, E) tale che: V C E = {(c 1, c 2 ) C C : S R : (c 1, c 2 ) S} Quello che interessa è tale grafo G composto da un insieme di vertici V che rappresentano i concetti e da un insieme di archi E che rappresentano le relazioni tra tali concetti. Per poter estrarre le metainformazioni occorre quindi visitare un grafo che altro non è che un documento semantico scritto in RDF [McB04] o OWL [DLM04]. Quanto detto circa l utilizzo delle teorie di Information Retrieval, della rappresentazione e dell analisi di un documento semantico, ha portato all individuazione, durante il tirocinio, di due toolkit java orientati al web semantico che per funzionalità e potenzialità possono ritenersi equivalenti, ammettendo comunque delle opportune differenze. Questi due toolkit sono Sesame e Jena. In un primo momento si è orientato lo sviluppo del crawler verso l utilizzo di Sesame, in quanto permette una forte astrazione dal sistema utilizzato per la memorizzazione delle metainformazioni e fornisce ad esso un supporto molto robusto attraverso due moduli fuzionali distinti e complementari chiamati rispettivamente Repository API e Graph API [ope]. Il primo fornisce un accesso di alto livello al repository (supporto per la memorizzazione) utilizzato, ad esempio, per l interrogazione, la memorizzazione, l estrazione di file RDF ecc... Il secondo fornisce un supporto più raffinato alla manipolazione RDF come ad esempio, l aggiunta e la creazione di modelli RDF direttamente dal codice. L alto potere di astrazione di sesame è però limitato dal fatto che esso non è in grado di supportare documenti scritti in OWL ma esclusivamente quelli scritti in RDF. Si é deciso, quindi, di utilizzare, in un secondo momento, Jena che è in grado di gestire documenti semantici scritti sia in OWL che in RDF e che attraverso delle API molto robuste permette le stesse funzionalità di Sesame anche se con una minore astraibilità rispetto al repository utilizzato per la memorizzazione. Infine per lo sviluppo del codice del crawler semantico si è utilizzata come guida il codice preesistente del crawler non semantico che verrà descritto ampiamente in seguito. 3

5 Capitolo 1 Analisi del crawler non semantico Per studiare la progettazione di un crawler semantico si è partiti, come è naturale che fosse, dallo studio di un crawler tradizionale, o meglio non semantico. Tale crawler è quello attualmente funzionante nel motore di ricerca del dominio dell Università di Bologna e prima di passare alla sua analisi è necessario fornire una definizione che possa rendere un idea approssimata, ma per il momento esaustiva su cosa sia un crawler e su quali siano le sue funzionalità. Un crawler (conosciuto anche come spider) è un programma che passa in rassegna il World Wide Web (o anche determinati domini) in un modo metodico e automatizzato. Tecnicamente è un tipo di bot, ossia un programma o script che automatizza delle operazioni tipicamente eseguite da utenti umani. Un crawler non mantiene soltanto una copia di tutte le pagine visitate per poi successivamente analizzarle, ma le indicizza per rendere la ricerca più veloce e precisa, sebbene la fase di indicizzazione sia, almeno formalmente, distinta da quella di crawling pura. In generale, un crawler prende in input una lista di URL [BL05] da visitare. Durante l analisi di un URL (parsing), identifica tutti gli hyperlink presenti in questa pagina e li aggiunge alla lista di URL da visitare, inoltre salva il contenuto del documento in formato plaintext, privato cioè di tutti i tag html, e lo memorizza. Su questi file in plaintext ottenuti dalla fase di crawling pura viene costruito l indice (o gli indici) del motore di ricerca. [Wik] 1.1 Concetti di base Un crawler è una componente di un motore di ricerca dalla progettazione tutt altro che semplice. Il compito primario è quello di ritrovare tutti i documenti presenti (con dovute eccezzioni) in uno o più domini o addirittura in tutto il Web. Si deve quindi sviluppare un algoritmo che permetta una visita esaustiva delle risorse pre- 4

6 senti in rete. Bisogna di conseguenza conoscere com è fatta e come è possibile rappresentare una rete. Una rete è rappresentabile con un grafo diretto. Dalla teoria dei grafi sappiamo che un grafo è un insieme di coppie di vertici ed archi, ossia dove : G = (V, E) V è l insieme dei vertici E V V è l insieme di archi che connettono i vertici Indipendentemente dalla rappresentazione del grafo attraverso liste di adiacenza o matrice di adiacenza, quello che interessa è l algoritmo per la visita di tale grafo. Gli algoritmi più diffusi sono due, quello che visita il grafo in ampiezza (Breadth-First Search o BFS) e quello che visita il grafo in profondità (Depth-First Search o DFS) [THC01]. Il tempo di esecuzione dei due algoritmi è O(V+E) per BFS e Θ(V + E) per DFS, quindi praticamente equivalente. Di conseguenza viene fornita una breve descrizione solo della visita in ampiezza. Dato un grafo G = (V, E) con uno specifico vertice s chiamato sorgente, la visita in ampiezza esplora sistematicamente gli archi di G per scoprire ogni vertice che sia raggiungibile da s. L algoritmo scopre prima tutti i vertici che hanno distanza k da s prima di scoprire un qualunque vertice a distanza k+1. Ogni vertice ha un colore associato : bianco : vertice non ancora visitato grigio : vertice visitato ma non espanso (vertice appena scoperto) nero : vertice espanso, ossia di cui si conoscono tutti i vertici connessi ad esso Nella figura 1.1 viene mostrato graficamente il funzionamento dell algoritmo. 1.2 Architettura di un crawler non semantico Dopo aver introdotto i concetti base che sono dietro la costruzione di un crawler è possibile passare ora ad analizzare nel dettaglio l architettura di un crawler e nello specifico, del crawler non semantico di unibo. 5

7 Figura 1.1: Visita in profondità di un grafo Il linguaggio utilizzato per la progettazione del crawler è Java, un linguaggio orientato agli oggetti. Quindi quando si parlerà di classi si farà riferimento ad un modello di un insieme di oggetti che sono capsule che contengono sia dati che operazioni per manipolare tali dati. [MG06] Il cuore del crawler di unibo è costituito da circa 6 classi, le quali implementano tutte le specifiche che fin qui sono state citate. In pratica le risorse della rete vengono gestite come una coda di URL da visitare. Ovviamente tale coda non è nota completamente a priori in quanto il grafo della rete viene visitato seguendo l algoritmo BFS. Da questa coda, uno alla volta vengono presi i documenti e parsati, vengono cioè estratti tutti i collegamenti ipertestuali ad altre pagine del dominio e, come detto precedentemente, vengono eliminati tutti i tag html in modo da rendere i documenti in formato plaintext. I documenti così ottenuti vengono inseriti in una coda, in cui sono pronti per essere indicizzati. Questo è il funzionamento generale. Nella figura 1.2 viene mostrato il diagramma UML [Com05] delle classi del crawler [Ros] di cui in seguito si effettuerà una più approfondita analisi. L inizializzazione delle strutture dati utilizzate dal crawler e dei vari thread crawl (thread che si occupano del crawling) è di responsabilità della classe BlackWindow che contiene il metodo main. L inizializzazione delle strutture dati è fatta a partire da dei file di configurazione gestiti attraverso una determinata classe chiamata Configuration la cui analisi non 6

8 Figura 1.2: Diagramma UML del crawler non semantico del dominio unibo è di fondamentale importanza per i nostri interessi. Prima di partire con il vero e proprio crawling vengono settati i due tipi di filtro (prefilter e postfilter) responsabili della differenziazione tra risorse visitate e quelle ancora da visitare. In questo contesto vengono inoltre inizializzate le strutture dati per la coda degli URL da visitare (classe LinksQueue) e per i documenti già parsati (classe ResourcesList). Importante è anche l inizializzazione di una classe che determina l estrazione dei collegamenti ipertestuali durante la fase di parsing di un documento, ossia la classe HtmlInfoExtractor, che sarà molto importante, come verrà in seguito mostrato, per la progettazione del crawler semantico. Si è detto che la classe BlackWindow è responsabile della gestione dei thread di crawling, 7

9 che sono implementati nella classe Crawler da un metodo chiamato crawl. Tale metodo si può dire che effettua alcune delle operazione più importanti. Infatti : estrae le URL dalla coda dei link (LinksQueue) verifica prima di scaricare il documento se tale risorsa è già stata visitata utilizzando i prefiltri inizializzati nella classe BlackWindow scarica il documento dalla URL verifica con i postfiltri se il documento ha subito delle modifiche dall ultimo crawling passa il documento agli estrattori che ricercano collegamenti ipertestuali ad altre risorse del dominio unibo da inserire nella LinksQueue e rendono il documento in formato plaintext inserisce il documento nella coda dei documenti parsati (ResourseList) La ricerca, durante il parsing, di collegamenti ipertestuali è resa possibile da un determinato metodo della classe Crawler chiamato extractlinks che ricerca nel contenuto del documento tutti i tag html di tipo < a >, < area > e < frame > La classe LinksQueue è responsabile di gestire la coda delle URL ancora da visitare appartenenti alla classe Link. Sono quindi forniti una serie di metodi propri per la gestione di una coda quali add() che inserisce una URL o get() che restituisce una URL e la elimina dalla coda. È importante dire che ogni volta che viene aggiunta una URL, ovvero un nuovo Link si controlla all interno della coda se esso è già presente, infatti è molto probalile che all interno di documenti diversi siano presenti dei collegamenti ipertestuali alla stessa risorsa e con questo controllo si evita di far lievitare la coda con delle ripetizioni inutili. Avere una risorsa che presenta più link verso di essa non è un informazione inutile, in quanto in fase di ranking sarà importante assegnare un peso ad ognuna di essa e ciò può essere facilitato sapendo quanti collegamenti a se stessa essa presenta. La classe ResourcesList serve, invece, a gestire una lista di oggetti Resource, che sono i documenti gia visitati in fase di crawling e che quindi verrano successivamente indicizzati. 8

10 Capitolo 2 Studio del crawler semantico Si è visto precedentemente come è possibile visitare il grafo della rete per recuperare risorse in modo da poterle indicizzare. Quello che si vorrebbe descrivere ora è un crawler che oltre a svolgere le funzionalità fin qui descritte possa analizzare, memorizzare e successivamente indicizzare il grafo dei documenti semantici della rete. Senza entrare in dettagli poco utili, è possibile dare una definizione informale, ma significativa, di web semantico : Definizione 1 Il Web Semantico è un estensione del Web corrente in cui le informazioni hanno un ben preciso significato e in cui computer e utenti lavorano in cooperazione [TBL01] Il Web Semanticon può essere visto come una struttura comune per lo scambio di dati e non di documenti come avveniva nel web tradizionale ed inoltre come linguaggio per memorizzare le relazioni esistenti tra i dati e gli oggetti del mondo reale. Per memorizzare tali relazioni si utilizzano dei modelli RDF [McB04] o OWL [DLM04] basati su statement. Ogni statement dice qualcosa su una risorsa. Uno statement può essere visto come una tripla composta da tre parti : Il soggetto che è la risorsa da cui l arco parte Il predicato che è la proprietà che da il nome all arco L oggetto che è la risorsa o il literal puntato dall arco In figura 2.1 viene mostrato un esempio di grafo RDF in gli i soggetti vengono indicati dai nodi ellittici, i predicati dalle etichette poste sugli archi e gli oggetti dai nodi rettangolari. Un possibile modello RDF che descriva il grafo in figura n. 2.1 è : 9

11 Figura 2.1: Esempio di grafo RDF <rdf:description rdf:about=" <ex:editor> <rdf:description> <ex:homepage> <rdf:description rdf:about=" </rdf:description> </ex:homepage> </rdf:description> </ex:editor> </rdf:description> <rdf:description rdf:about=" <ex:editor> <rdf:description> <ex:fullname>dave Beckett</ex:fullName> </rdf:description> </ex:editor> </rdf:description> <rdf:description rdf:about=" <dc:title>rdf/xml Syntax Specification (Revised)</dc:title> </rdf:description> 2.1 Introduzione al crawler semantico Per quanto detto e per quanto mostrato è possibile affermare che un modello semantico scritto in RDF rappresenta un grafo diretto. Sviluppare un crawler semantico significa proprio effettuare una visita di tale grafo per poterne ottenere un suo albero di copertura che renda possibile la memorizzazione e l indicizzazione dei documenti. 10

12 È importante notare che i nodi del grafo di cui ci si propone di effettuare una visita, sono individuati dagli statement all interno di un modello RDF, quindi è possibile recuperarli parsando semplicemente il modello. Questa soluzione è buona, ma incompleta, in quanto non tiene conto che all interno di uno statement si possa fare riferimento ad un modello semantico esterno a quello che stiamo analizzando. Per i fini che ci proponiamo e per rendere un idea più semplice, si può pensare quanto appena detto come caso analogo a quello di un documento html che presenta dei collegamenti ipertestuali a documenti esterni. È possibile sfruttare questa analogia per riprendere quanto detto per il crawler non semantico e adattarlo per sviluppare una sua versione semantica, tenendo ovviamente conto che i dati che si tratteranno saranno modelli semantici e non documenti html. 2.2 Dal crawler non semantico a quello semantico Più che ad una riscrittura di un crawler semantico completamente nuovo, si è pensato, nell ambito del tirocinio, ad una migrazione di codice dal crawler non semantico in modo da poter riutilizzare funzionalità che comunque sarebbero state utilizzate. Per prima cosa si è modificato il crawler originario di unibo in modo che potesse riconoscere, all interno di un documento html, la presenza di un riferimento ad un modello semantico. Questo è stato reso possibile applicando delle modifiche alla classe Crawler che, come detto in precedenza, è responsabile (gestisce) il parsing. Infatti durante l analisi di un documento html vengono riconosciuti come collegamenti ipertestuali tutti i tag < a >, < area > e < frame >. A questi possiamo aggiungere il tag < link >, in quanto proprio attraverso tale tag si indica all interno di un documento html la presenza di un riferimento ad un modello semantico. Ovviamente è possibile che il tag link non contenga necessariamente un riferimento ad un modello semantico, ma ad esempio ad un foglio di stile. Per evitare l inconveniente di fare il parsing di documenti non idonei, bisogna analizzare l estensione del modello o documento a cui si fa riferimento. Tale analisi viene effettuata nella classe HtmlInfoExtractor le cui istanze recuperano i collegamenti ipertestuali e li restituiscono all istanza della classe Crawler. Dopo ever accertato che il riferimento che si è incontrato è proprio un modello semantico, vengono sfruttate, come verra enunciato in seguito, le funzionalità di Jena per continuare nel crawling semantico. Esiste la possibilità che un documento html non presenti il tag < link >, ma abbia comunque un modello semantico di riferimento. In questo caso quest ultimo modello sarà recuperato ed indicizzato ugualmente sfruttando la linea completamente semantica di crawling. 11

13 2.3 Architettura generale del crawler semantico Il compito che il nostro crawler semantico deve avere è quello di generare, come al solito, un albero di copertura, però questa volta verrà generato non solo attraverso l analisi di documenti html, ma anche di modelli semantici, costituiti come detto da statement. Si è detto non solo in quanto la parte non semantica continuerà comunque ad essere eseguita. Quello che occorre prima di tutto, è capire come sviluppare l algoritmo di visita in ampiezza di un grafo sulle componenti semantiche della rete. Parlando di crawling non semantico, si è detto di come l algoritmo BFS [THC01] venga realizzato ricercando i collegamenti ipertestuali all interno dei documenti html e gestendoli in opportune strutture dati. In maniera analoga possiamo, per l analogia detta precedentemente tra i link html e riferimenti a modelli semantici esterni, utilizzare questi ultimi per sviluppare il nostro algoritmo di visita. Per sviluppare l algoritmo di visita occorrono delle classi che permettano il parsing di modelli semantici, occorre anche poter memorizzare tali modelli per poter successivamente generare un indice. In figura 2.2 è mostrato il diagramma UML delle classi della parte semantica del crawler sviluppato nell ambito del tirocinio. Il crawler è formato da quattro parti : il cuore che è costituito dalla classe JenaBD, coordinatrice di tutte le attività il nucleo formato dalla classe SemanticParser e dalla classe ReferencesQueue che effettuano il parsing dei modelli e la gestione della coda dei riferimenti ai modelli semantici esterni. la classe JenaDBConf che serve ad inizializzare il database per la memorizzazione dei modelli semantici la classe JenaDBManage che serve ad effettuare tutte le operazioni di memorizzazione, cancellazione e di query nel database Di seguito queste quattro componenti verranno analizzate in maniera più dettagliata. 2.4 Il parsing semantico Il nucleo costituito dalla classe SemanticParser e dalla classe ReferencesQueue si occupa, come detto, del parsing dei modelli e della gestione della coda dei riferimenti ai modelli se- 12

14 Figura 2.2: Diagramma UML delle classi del crawler semantico mantici esterni. Viene considerato come un unica parte in quanto le due classi sono, sebbene distinte, strettamente correlate. Il parsing vero e proprio è ovviamente effettuato dalla classe SemanticParser, che preso un modello semantico, ne effettua la lettura ricercando tutti gli statement in esso contenuti. Per ogni statement, inoltre, analizza singolarmente le sue componenti, ossia il soggetto, il predicato e l oggetto, per ricercare dei riferimenti a modelli semantici esterni, ossia uno statement con una proprietà della classe rdfs:seealso. Se viene trovato un riferimento esterno, esso viene aggiunto il corrispondente URL alla coda dei modelli semantici da visitare gestita dalla classe ReferencesQueue. Tale classe è analoga alla classe LinksQueue del crawler non semantico, quindi le sue funzionalità sono del tutto simmetriche, in quanto vengono forniti dei metodi per la gestione di una coda. In questo caso la coda è per semplicità costituita da elemnti stringa, e non si è deciso di generare un nuovo tipo, come nel caso non semantico degli elementi Link. Questa decisione è stata dettata anche dal fatto che ogni componente di uno statement appartiene ad una classe differente fornita dalle API di Jena e che ognuna di essa era facilmente generalizzabile attraverso l uso del tipo String. Si è accennato, nel paragrafo 2.2 su come non fosse necessaria la presenza del tag < link > 13

15 in un documento html per indicare la presenza di una relativa documentazione semantica. Infatti attraverso la visita del grafo semantico tale risorsa, a meno che essa sia un nodo isolato, oppure faccia parte di una componente connessa staccata da quella in analisi, verrà sicuramente recuperata. 2.5 Connessione al database Dopo essere stati parsati dal crawling non semantico i documenti venivano memorizzati su file system. Tale soluzione è applicabile anche nel nostro caso, ma, nell ambito del tirocinio, si è scelto di utilizzare un database relazionale per la memorizzazione degli statement dei modelli semantici. Formalmente gestire un database relazionale appare più complicato rispetto al file system, ma tale complessità viene ripagata da un efficienza migliore in termini di prestazioni, sia immediate che in luogo di creazione dell indice. A conferma di quanto detto, viene utilizzata una classe apposita, la JenaDBConf, solo per la connessione al data base e l inizializzazione delle strutture dati successivamente utilizzate. L utilizzo di un apposita classe sarebbe stato evitato se si fosse scelto uno storage basato su file system, infatti Jena permette la sua configurazione attraverso la chiamata di un unico metodo, mentre per quanto riguarda il database relazionale bisogna effettuare tre passi sequenziali [sou] : caricare il dirver JDBC che permette alla classe di comunicare con un istanza del database. creare una connessione con il databese, che crea un oggetto java utilizzato per la comunicazione con il database. creare o aprire un modello su una connessione che permette la connessione finale con il database e crea un modello vuoto o apre un modello precedentemente creato. Il seguente è un esempio di codice per la configurazione di una connessione con un database PostgreSQL : // Si carica il Driver String classname = "org.postgresql.driver" class Class.forName (classname); // path del driver // il driver viene caricato String DB_URL = "jdbc:postgresql://localhost/test"; String DB_USER = "test"; String DB_PASSWD = ""; // URL del server del database // user id del database // password del database 14

16 String DB = "PostgreSQL"; // tipo del database // Si crea la connessiona al database IDBConnection conn = new DBConnection ( URL, DB_USER, DB_PASSWD, DB); // Si crea un modello nel database ModelMaker maker = ModelFactory.createModelRDBMaker(conn); ModelRDBm = maker.createmodel (); 2.6 Gestione del database e memorizzazione delle metainformazioni L obbiettivo finale del nostro crawler è quella di poter memorizzare tutte le relazioni che si incontrano, cioè gli statement di un modello semantico. Questi statement, come si è visto, possono essere recuperarati durante la fase di parsing di un modello semantico. Il compito della classe JenaDBManage è quello di generare un un unico modello, dai numerosi che vengono recuperati durante la fase di crawling. In pratica ogni volta che il parser incontra uno statement semanticamente corretto lo invia alla classe JenaDBManage che lo inserisce in questa sorta di modello temporaneo. Si utilizza il termine temporaneo in quanto questo modello non è certamente quello che verrà successivamente memorizzato nel database, in quanto potrebbero esserci statement ripetuti oppure già presenti in memoria. Quando il crawler ha terminato la visita del grafo semantico, non ci sono più statement da aggiungere, di conseguenza viene iniziato un controllo off-line che consiste nell interrogare, per ogni tripla soggetto, predicato, oggetto, il database per evitare nella memorizzazione finale ripetizioni inutili. Tale controllo poteva essere inserito on-line, cioè in piena fase di analisi del grafo semantico, ma si è preferito mantenere i costi relativi all interrogazione del database separati da quelli di crawling puri. Se un interrogazione restituisce un esito positivo vuol dire che lo statement è già presente nel database (ovviamente la prima volta che verrà effettuato il crawling il database sarà vuoto senza possibilià di avere statement già presenti), mentre se l interrogazione restituisce esito negativo si procede nella memorizzazione dello statement nel modello finale che è poi quello mantenuto nel database. 15

17 Conclusioni Il lavoro effettuato durante il tirocinio attraverso lo studio personale o di gruppo, che ha coinvolto me ed altri tirocinanti anche in una breve esperienza di extreme programming, sarà continuato ed ovviamente approfondito in ambito di tesi. Le maggiori difficoltà sono ovviamente state quelle puramente decisionali, ossia quelle che hanno portato alla progettazione dell architettura generale del crawler semantico. Esse sono state dovute, come espresso in precedenza, al fatto che prima si era scelta una linea di sviluppo che utilizzava come toolkit semantico Sesame ed in seguito si è preferito Jena. Tale decisione ha portato ad una serie di modifiche sostanziali del progetto in quanto, i due strumenti sono in sostanza dal punto di vista funzionale equivalenti, ma presentano essenziali differenze dal punto di vista strutturale. Inoltre il tirocinio è servito ad approfondire le conoscenze del linguaggio Java e della piattaforma Eclipse utilizzata per la stesura del codice. 16

18 Bibliografia [BL05] T. Berners-Lee. Uniform resource identifier (uri): Generic syntax [Com05] A. Comai. Introduzione a uml [DLM04] F. van Harmelen D. L. McGuinness. Owl web ontology language overview [McB04] B. McBride. Rdf primer [MG06] S. Martini M. Gabrielli. Linguaggi di programmazione : principi e paradigmi. McGraw-Hill, [ope] openrdf.org. Sesame user guide. [RBY99] B. Ribeiro Neto R. Baeza Yates. Modern Information Retrieval. Addison Wesley, [Ros] D. Rossi. Codice del motore di ricerca del portale web di unibo. [sou] sourceforge.org. Jena how to. [TBL01] O. Lassila T. Berners-Lee, J. Hendler. The semantic web [THC01] R. L. Rivest T. H. Cormen, C. E. Leiserson. Introduction to Algorithms. McGraw- Hill, [Vel04] P. Velardi. L information retrieval. estrinfo/progetto2005/managiga.pdf, [Wik] Wikipedia. Web crawler. 17