politecnico di torinoelite.polito.it/files/thesis/fulltext/barroero.pdf · l'esempio più...

POLITECNICO DI TORINO

IV Facoltà di Ingegneria

Corso di Laurea in Ingegneria dell’Organizzazione d’Impresa

La classificazione a faccette fra Knowledge Management e Information Architecture:

metodologie e strumenti

Relatore Professor Fulvio Corno Tutore Aziendale Candidata Ingegnere Alberto Ciaramella Giulia Barroero

Ottobre 2007

- 3 -

INDICE

Introduzione ...........................................................................................................- 5 -

Capitolo 1 - La knowledge organization..............................................................- 7 -

1.1 Introduzione...............................................................................................................- 7 -

1.2 I sistemi di organizzazione.........................................................................................- 7 - 1.2.1 Indicizzazione semantica................................................................................................. - 7 - 1.2.2 Tesauri............................................................................................................................. - 8 - 1.2.3 Tassonomie...................................................................................................................... - 8 - 1.2.4 Ontologie......................................................................................................................... - 9 - 1.2.5 Conclusioni...................................................................................................................... - 9 -

1.3 Gli schemi di classificazione ...................................................................................- 10 -

1.4 Classificazione a faccette.........................................................................................- 10 - 1.4.1 Introduzione .................................................................................................................. - 10 - 1.4.2 I vantaggi degli schemi a faccette per il Web................................................................ - 11 - 1.4.3 I vantaggi per l'utente .................................................................................................... - 14 - 1.4.4 Il caso wine.com............................................................................................................ - 15 -

Capitolo 2 - Analisi di faceted browser..............................................................- 17 -

2.1 I browser visionati ...................................................................................................- 17 -

2.2 The Flamenco Search Interface Project ..................................................................- 18 - 2.2.1 Introduzione .................................................................................................................. - 18 - 2.2.2 Demo (Nobel Prize Winners) ........................................................................................ - 18 - 2.2.3 Prerequisiti richiesti....................................................................................................... - 19 - 2.2.4 Architettura SW............................................................................................................. - 20 - 2.2.5 Dati in ingresso.............................................................................................................. - 21 -

2.3 MIT Longwell...........................................................................................................- 23 - 2.3.1 Introduzione .................................................................................................................. - 23 - 2.3.2 Demo (MIT Libraries)................................................................................................... - 23 - 2.3.3 Prerequisiti richiesti....................................................................................................... - 25 - 2.3.4 Architettura SW............................................................................................................. - 25 -

2.4 AquaBrowser Library ..............................................................................................- 25 - 2.4.1 Introduzione .................................................................................................................. - 25 - 2.4.2 Demo (Queens Library)................................................................................................. - 26 - 2.4.3 Architettura SW............................................................................................................. - 28 -

2.5 mSpace.....................................................................................................................- 29 - 2.5.1 Introduzione .................................................................................................................. - 29 - 2.5.2 Demo............................................................................................................................. - 29 - 2.5.3 Tecnologia..................................................................................................................... - 32 - 2.5.4 Architettura SW............................................................................................................. - 32 -

2.6 Aduna Autofocus......................................................................................................- 33 - 2.6.1 Introduzione .................................................................................................................. - 33 - 2.6.2 Demo............................................................................................................................. - 34 - 2.6.3 Prerequisiti richiesti....................................................................................................... - 35 - 2.6.4 Tecnologia..................................................................................................................... - 35 -

2.7 SWED.......................................................................................................................- 40 - 2.7.1 Introduzione .................................................................................................................. - 40 -

- 4 -

2.7.2 Demo (MokaByteSWP) ................................................................................................ - 41 - 2.7.3 Tecnologia..................................................................................................................... - 42 - 2.7.4 Prerequisiti richiesti....................................................................................................... - 42 - 2.7.5 Architettura SW............................................................................................................. - 42 -

2.8 Tabella riassuntiva ..................................................................................................- 44 -

Capitolo 3 - Il progetto Intellifacet.....................................................................- 47 -

3.1 Introduzione.............................................................................................................- 47 -

3.2 Tipologie di informazione........................................................................................- 47 -

3.3 Fasi di realizzazione ................................................................................................- 48 - 3.3.1 Utilizzo di H-DOSE ...................................................................................................... - 48 - 3.3.2 Lato server..................................................................................................................... - 49 - 3.3.3 Ontologia....................................................................................................................... - 49 - 3.3.4 Indicizzazione................................................................................................................ - 50 - 3.3.5 Interfaccia di navigazione ............................................................................................. - 51 - 3.3.6 Ricerca testuale ............................................................................................................. - 52 -

3.4 Architettura SW .......................................................................................................- 52 -

3.5 Possibili miglioramenti............................................................................................- 54 -

3.6 Backoffice ................................................................................................................- 54 -

Conclusioni ...........................................................................................................- 57 -

Ringraziamenti.....................................................Errore. Il segnalibro non è definito.

Bibliografia e siti consultati ................................................................................- 59 -

- 5 -

Introduzione

Ognuno di noi cerca in modo diverso, in base alle proprie esigenze e all'obiettivo che guida la sua ricerca; si ha, perciò, l’esigenza di sistemi capaci di adattarsi a tale diversità di esigenze e profili di pubblico. E’ necessario garantire un accesso all'informazione secondo strade diverse con il concetto di multidimensionalità. I sistemi di ricerca “full-text” si limitano a cercare l'occorrenza di una parola (o di una stringa) all'interno di un insieme di documenti rischiando di estrarre risorse che non riguardano ciò che stiamo cercando, ma presentano la stringa cercata o di non considerare documenti pertinenti che contengono sinonimi delle parole cercate. I sistemi a faccette, invece, sono particolarmente indicati in quanto risultano comodi non solo per la classificazione, che incarna perfettamente questa logica multidimensionale, ma anche per la possibilità che offrono di associare fra loro concetti diversi. Questa monografia è strutturata in tre capitoli principali. Nel primo capitolo si effettua una breve introduzione sui fondamenti della knowledge organization, descrivendone i sistemi di organizzazione e gli schemi di classificazione. Inoltre viene descritto cosa si intende per “classificazione a faccette” e i vantaggi che questa ha portato nell’organizzazione dei contenuti e nell’esperienza degli utenti nel Web. Il secondo capitolo presenta una descrizione di alcuni casi dell’impiego di sistemi di navigazione a faccette nel web che ho esaminato e confrontato secondo criteri comuni. Il terzo capitolo descrive la struttura di Intellifacet, la demo del faceted browser, realizzato dall’Intellisemantic srl durante il mio periodo di tirocinio formativo.

- 7 -

Capitolo 1 - La knowledge organization

1.1 Introduzione

La rivoluzione informatica ha creato l’illusione che si potesse improvvisamente risolvere il problema dell’organizzazione e della gestione dell’informazione per favorirne la reperibilità. Oggi si è capito che la tecnologia è sicuramente un supporto per la gestione della conoscenza ma ciò non elimina il problema dell’organizzazione dei suoi contenuti. L’organizzazione delle conoscenze, che si fonda su principi in gran parte indipendenti dal supporto fisico su cui sono memorizzate, è indispensabile per poterle utilizzare, trovando le informazioni che occorrono allo scopo del momento tra quelle disponibili. Inoltre, è anche una fase fondamentale per la ricerca di conoscenze nuove: i ricercatori che sviluppano, inconsapevolmente, conoscenze già possedute da altri, stanno perdendo tempo e non contribuiscono all’avanzamento del sapere.

1.2 I sistemi di organizzazione

Uno degli aspetti che interessano l'architettura dell'informazione è l'organizzazione ottimale dei contenuti nei documenti, in particolare nei siti web. A questo scopo vengono utilizzate, più o meno consapevolmente, varie forme di sistemi per l'organizzazione della conoscenza (knowledge organization system, KOS), come parole-chiave, tesauri, stringhe di soggetto, tassonomie, ontologie, schemi di classificazione.

1.2.1 Indicizzazione semantica In tutti i casi l’informazione viene reperita per mezzo di indici che descrivono: • le entità (caso db) • i documenti (caso information retrieval) • le pagine Web (caso ricerca in rete)

- 8 -

Gli indici sono metadati cioè dati sui dati, rappresentazioni sintetiche che contengono riferimenti ai documenti interi, che vengono creati sia manualmente che automaticamente e sono indispensabili per far trovare i documenti e quindi farli leggere. Per migliorare la navigazione e il recupero dei dati da parte dell’utente, gli autori di pagine web hanno, quindi, la possibilità di aggiungere parole o frasi che ne descrivono il contenuto attraverso i cosiddetti metadati.

1.2.2 Tesauri

Nella sua forma più semplice un vocabolario controllato è un sottoinsieme di un linguaggio che rappresenta un sapere specialistico, per esempio un elenco dei termini specifici di una disciplina (arte, medicina, economia, ecc. ). Un vocabolario controllato di questo tipo può essere deciso da uno o più esperti, o costruito automaticamente scartando dai testi del settore le parole cosiddette “non-stop” (articoli, preposizioni, pronomi, ecc.) Un primo arricchimento del vocabolario controllato è costituito dalla introduzione dei sinonimi, o meglio di termini considerati equivalenti secondo certi criteri, nella stessa lingua o in lingue diverse, comprendendo anche errori ortografici comuni. Poiché nessuno dei termini equivalenti è considerato preferito, si parla di anelli di sinonimi. Un thesaurus è un “vocabolario di un linguaggio d’indicizzazione controllato” (standard ISO 1986) in cui vengono esplicitate relazioni semantiche fra termini. Precisamente: • relazioni di equivalenza fra i termini; • relazioni gerarchiche fra i termini preferiti; • relazioni associative fra i termini. Lo scopo di un tesauro è quello di formalizzare la terminologia per evitare la ridondanza del linguaggio naturale, che è quanto può accadere con le parole-chiave, così da aumentare il richiamo (recall) dei documenti rilevanti tra i risultati.

1.2.3 Tassonomie Un vocabolario controllato diventa uno schema di classificazione, tassonomia, quando i termini vengono organizzati in una gerarchia. Le tassonomie non sono molto diverse dai tesauri, tranne per la rappresentazione ad albero e il minor rigore con cui vengono specificate le relazioni. Uno schema di classificazione svolge un triplice ruolo: • per l’architetto dell’informazione, come strumento di organizzazione e

etichettatura dei documenti • per l’utente, come ausilio alla navigazione (se, come in Yahoo!, è resa visibile

come parte integrante dell’interfaccia) • per l’utente, nella ricerca, quando gli vengono mostrate le categorie in cui è stato

trovato il termine dell’interrogazione familiarizzandolo con lo schema di classificazione del sistema.

- 9 -

1.2.4 Ontologie

Anche le ontologie hanno una struttura concettuale simile a quella dei tesauri ma le relazioni tra i termini è nella forma gatto IS-A felino. Oltre alle relazioni generiche, partitive e associative, possono essere utilizzate molte altre relazioni, in base alle definizioni della singola ontologia. In questo modo, più che un albero gerarchico, si forma una vera e propria rete complessa di relazioni tra i concetti che può essere visualizzata, anche graficamente, in modi efficaci. Quello che rende le ontologie particolarmente utili è il fatto che in esse le relazioni sono generalmente registrate in modo formale e trattabile in automatico, utilizzando un apposito linguaggio di rappresentazione della conoscenza. Un “agente intelligente” software potrà così elaborarle secondo personali regole, quindi essere in grado di inserire nuove relazioni. La possibilità di mettere online diverse ontologie porta all’idea di farle dialogare fra loro, affinché venga moltiplicata la conoscenza complessiva trattabile in automatico, realizzando l’auspicato web semantico. A tale scopo occorre scegliere dei linguaggi di rappresentazione standard condivisi dai diversi sistemi, come DAML o il più recente OWL (Web Ontology Language) sviluppato dal World Wide Web Consortium (W3C).

1.2.5 Conclusioni Oggi i nuovi modelli di KOS sono orientati verso un potenziamento delle operazioni di information retrieval e verso un’automazione spinta nella fase di indicizzazione. Per raggiungere il primo obiettivo si sta cercando di velocizzare i motori di ricerca, che dovrebbero catturare le queries richieste dagli utenti all’interno di un database ben strutturato, mostrando i risultati della ricerca attraverso l’utilizzo di semplici interfacce in grado di servire meglio l’utente, pilotandolo “intelligentemente” a seconda dei suoi interessi e delle sue necessità. La sfida più grande nel campo dell’information retrieval è l’identificazione concettuale all’interno di uno specifico dominio di interesse. Infatti, un sistema di information retrieval semanticamente guidato ha la capacità di riconoscere, ovvero “capire”, attraverso chiarificazioni e precisazioni imposte all’utente, i possibili e vari significati di una determinata parola nella stringa di ricerca. Soltanto quando l’utente abbia disambiguato completamente il termine, il sistema potrà essere in grado di eseguire la ricerca senza troppo “rumore” nel risultato. Un sistema intelligente potrebbe non soltanto catturare l’informazione pertinente alla richiesta dell’utente, ma anche aiutarlo nell’esplorare e chiarire cosa sta cercando fornendogli informazione utile e correlata. In questo scenario un KOS ha due funzioni: • assistere l’utente; • supportare l’indicizzazione automatica attraverso l’analisi sintattico-semantica

del testo. Queste due funzioni richiedono un KOS con una ricca struttura semantica. Per realizzare questi e altri obiettivi, i nuovi KOS devono sposare la struttura concettuale

- 10 -

delle ontologie, ovvero, gerarchie ben strutturate di concetti connesse attraverso un network di relazioni dettagliate su base concettuale – con la ricchezza terminologica dei migliori tesauri. I nuovi KOS devono contenere concetti specifici linkabili attraverso un network di relazioni ben definite e un ricco set di termini che identifichino questi concetti. In un’ontologia si verificherà l’assegnazione di un unico identificatore ad ogni concetto; in questo modo ogni concetto e relazione saranno esplicitamente definite come un’unica entità e l’ontologia diventerà una formalizzazione semantica.

1.3 Gli schemi di classificazione

Gli schemi di classificazione sono forse i più classici tra i KOS. Sono stati sviluppati soprattutto a partire dalla fine dell'Ottocento, per far fronte alla crescita della quantità di documenti da ordinare e gestire nelle biblioteche e nelle bibliografie. La maggior parte degli schemi di classificazione sono sostanzialmente enumerativi, ossia si basano sull'elencazione delle classi nelle quali è possibile ripartire i documenti da classificare. Poiché le possibilità di combinare fra loro i concetti sono limitate, quasi tutti i concetti da utilizzare devono essere già previsti dallo schema, che perciò è necessariamente costituito da tavole voluminose. L'universo della conoscenza viene suddiviso in un certo numero di classi principali, ognuna di queste in sottoclassi, e così via, sviluppando in questo modo un albero gerarchico, di profondità teoricamente illimitata. L'esempio più famoso è la Classificazione decimale Dewey (CDD), introdotta dal bibliotecario newyorkese Melvil Dewey a partire dal 1876, e da allora progressivamente espansa, aggiornata e adottata in biblioteche di tutto il mondo.

1.4 Classificazione a faccette

1.4.1 Introduzione

Un'evoluzione della classificazione enumerativa è stata introdotta dall'indiano S.R. Ranganathan a partire dagli anni Trenta, e successivamente diffusa dai membri del Classification Research Group. Nella concezione di Ranganathan uno schema di classificazione deve essere utilizzato in biblioteca in modo integrato: non soltanto cioè per realizzare un catalogo da consultare, ma anche per disporre i volumi negli scaffali secondo un ordine adeguato, che permetta agli utenti di localizzare direttamente quelli che trattano gli argomenti di loro interesse. Perciò, egli dedicò molto del suo lavoro a identificare dei principi fondanti per la classificazione, e introdusse soluzioni profondamente innovative all'eterno problema di rappresentare le innumerevoli sfumature dell'opera dell'intelletto umano. In alternativa agli schemi di classificazione già esistenti da diversi decenni, Ranganathan studiò un sistema meno rigido e più articolato, che definì classificazione a faccette. Una faccetta (in inglese "facet") è un particolare aspetto sotto il quale un argomento viene trattato; secondo Ranganathan, le faccette di qualsiasi classe si possono

- 11 -

ricondurre a cinque categorie fondamentali: personalità (l'oggetto centrale di un discorso), materia (i componenti e le proprietà dell'oggetto), energia (le caratteristiche dinamiche dei processi che lo interessano), spazio (i suoi elementi geografici o in genere spaziali), e tempo (le sue fasi cronologiche). Con una classificazione a faccette, il contenuto di un documento può essere descritto analiticamente nei suoi diversi aspetti; questi sono poi espressi tutti insieme, secondo una sequenza determinata da regole di funzionalità: perciò Ranganathan definisce questo tipo di classificazione analitico-sintetico. La classificazione a faccette è nota anche come Colon Classification, per la caratteristica frequenza con cui ricorre nella sua notazione il simbolo di due punti (in inglese "colon"). La classificazione a faccette non si preoccupa di collocare un oggetto in una gerarchia, ma di descriverlo in termini di sue proprietà o caratteristiche mutuamente esclusive. Non una singola grande tassonomia, ma tante piccole tassonomie che rispecchiano altrettanti diversi punti di vista. Nella classificazione a faccette, il contenuto dei documenti è analizzato in una serie di aspetti fra loro complementari, le cosiddette faccette, e quindi espresso per combinazione dei codici corrispondenti a ciascuna faccetta. Poiché le tavole di uno schema a faccette devono elencare solo i possibili valori (fuochi) di ogni faccetta, lasciando le loro possibili combinazioni al classificatore, esse risultano molto più compatte di quelle di uno schema enumerativo. Pur godendo della stima degli esperti di tutto il mondo, in quanto metodo più avanzato ed efficace di quello enumerativo, l'analisi a faccette non è stata ancora applicata in modo massiccio a biblioteche e bibliografie. Infatti, gli schemi enumerativi godono di maggiore notorietà e di strutture organizzative più potenti che forniscono una ricca documentazione anche in lingue diverse dall'inglese, e questo basta a convincere molti enti ad utilizzarle in luogo dei più avanzati schemi a faccette. Tuttavia, i principi individuati e definiti esplicitamente da Ranganathan a proposito della formazione delle classi, delle faccette, del loro ordine di citazione, della notazione adottata per esprimerli hanno una grandissima importanza teorica. Essi infatti, ripresi da autorevoli studiosi - fra i quali i membri del Classification Research Group - hanno fornito le basi per lo sviluppo di avanzati sistemi di indicizzazione: thesauri, classificazioni a faccette speciali e generali,…

1.4.2 I vantaggi degli schemi a faccette per il Web Un nuovo interesse per la potenza della logica a faccette si riscontra negli ultimi anni proprio nell’ architettura dell'informazione. Numerosi siti infatti adottano, più o meno esplicitamente, un'indicizzazione "a faccette", in cui, cioè, il contenuto di ciascuna pagina è accessibile alternativamente attraverso l'uno o l'altro degli aspetti che contribuiscono a formarlo. Questa tecnica è ritenuta vantaggiosa anche ai fini dell'usabilità, in quanto offre agli utenti diversi percorsi per arrivare alle stesse risorse a seconda dei loro rispettivi punti di partenza, invece di costringerli ad adattarsi a un modello concettuale gerarchico che inevitabilmente esprime solo uno di tali possibili percorsi.

- 12 -

Nella progettazione e nella gestione di un sito web, così come di un qualsiasi sistema informativo digitale complesso (per esempio, un'intranet aziendale o un sistema di knowledge management), i principi della classificazione vengono impiegati in continuazione. Ci si trova, infatti, spesso nella situazione di dover organizzare una gran mole di contenuti con lo scopo principale di consentirne un facile recupero e, nella maggioranza dei casi, la soluzione più efficace risulta essere quella di ricorrere al buon vecchio metodo della classificazione. L'uso più evidente sul Web dei principi della classificazione si può riscontrare negli indici sistematici, cioè in quei siti che fungono da cataloghi organizzati delle risorse presenti on-line (Yahoo!, Virgilio, Open Directory,…). Ma classificare non è un compito semplice: un'attività di classificazione non supportata da strategie, metodologie e competenze adeguate rischia di produrre organizzazioni degli item illogiche e incoerenti, quindi poco scalabili e, soprattutto, difficilmente usabili dagli utenti. L’incoerenza, quando è accompagnata da un design non adeguato, risulta la causa delle difficoltà di utilizzo del sistema da parte degli utenti che non riescono a costruirsi un modello mentale dell’organizzazione del sito, fase determinante per una navigazione proficua. Il potere di uno schema organizzativo puro deriva dalla sua capacità di suggerire un semplice modello mentale che l'utente può facilmente comprendere. Gli utenti riconoscono facilmente un'organizzazione specifica per audience o per argomento e schemi organizzativi puri abbastanza piccoli possono essere applicati a grandi quantità di contenuto senza sacrificarne l'integrità o sminuirne l'usabilità. Tuttavia, quando si inizia a miscelare elementi di molteplici schemi, ne consegue spesso confusione e le soluzioni sono raramente scalabili. Poiché le parti sono mischiate tra loro, non possiamo formarci un modello mentale (Rosenfeld e Morville-2002). Un sistema coerente è anche maggiormente prevedibile: all'utente potrebbe bastare la lettura di solo alcune classi per dedurre tutte le altre, rendendo così più semplice e più rapida l'attività di comprensione e di apprendimento. A volte, per esempio se l'utente trova subito l'informazione che cercava (magari ancor prima che la pagina si sia completamente caricata), può capitare che veri e propri modelli mentali non vengano prodotti. Quando modelli mentali sono invece necessari, la rapidità della loro creazione e la prevedibilità del sistema sono aspetti molto importanti. Date tali premesse, l'utilizzo anche sul Web delle classificazioni bibliografiche potrebbe sembrare una soluzione ragionevole in quanto esse mostrano un livello di coerenza maggiore rispetto agli schemi home-grown. Ovviamente, nel proporre per il Web le classificazioni bibliografiche i bibliotecari sono comunque consapevoli del fatto che accorgimenti e modifiche all'impianto tradizionale debbano essere necessariamente apportati, non fosse altro che per la sostanziale diversità tra la fisicità del libro e la virtualità del Web. Ma le classificazioni bibliografiche classiche, in quanto enumerative e condivise, soffrono soprattutto di un problema: sono di fatto conservative perché strutturalmente chiuse, istituzionalizzate e centralizzate. Infatti non consentono in fase di indicizzazione, quando diviene necessario, l'inserimento da parte del classificatore di una nuova categoria; solo il compilatore può modificare la classificazione.

- 13 -

Ben diverso è il caso delle classificazioni a faccette, le quali consentono un'effettiva apertura grazie a innovazioni sostanziali nel procedimento stesso di classificazione. Tali sistemi, dichiaratamente alternativi agli schemi gerarchico-enumerativi tradizionali, sono infatti frutto di un ripensamento radicale delle tecniche di classificazione: abbandonano l'idea di un'enumerazione a priori di tutte le classi a favore di una metodologia che consente di crearle "on the fly" partendo da alcuni elementi preventivamente decisi (le faccette e i fuochi). Durante la fase di indicizzazione, l’indicizzatore ha il compito di descrivere l’oggetto rispetto alle faccette previste, assegnando per ogni faccetta i fuochi più adatti. Sarà l’unione dei fuochi selezionati per ogni faccetta che genererà automaticamente la classe per l’oggetto in questione. Un sistema on-line basato su una classificazione a faccette, in quanto effettivamente aperto, è quindi una soluzione interessante per andare incontro alla necessità, così urgente sul Web, di poter fare affidamento su schemi di classificazione flessibili e velocemente adattabili. Non si deve però cadere nell'errore di considerare tale apertura assoluta. È infatti chiaro che il numero di categorie potenziali previste ha un limite che, sebbene molto elevato, rappresenta in ogni caso un vincolo nelle capacità rappresentative del sistema. Ma gli schemi a faccette rimediano a questo problema attraverso un alto livello di scalabilità, assai maggiore rispetto alle classificazioni gerarchico-enumerative classiche. Queste ultime sono infatti difficilmente scalabili: l'aggiunta di una nuova categoria rende spesso necessaria la modifica delle classi dello stesso livello (per assicurarne la mutua esclusività) e/o di una grossa parte della struttura ad albero dello schema. La colpa di tale difetto delle classificazioni gerarchico-enumerative è da imputare anche alla loro struttura gerarchica. In uno schema ad albero tradizionale ci sono infatti forti relazioni per ogni ramo: le classi inferiori dipendono da quelle superiori. Negli schemi a faccette è invece sempre possibile aggiungere una nuova faccetta descrittiva di un nuovo aspetto dell'oggetto e non si avranno ripercussioni di alcun tipo sulle altre faccette. In una classificazione analitico-sintetica ogni faccetta è infatti autonoma dalle altre: determina una proprietà ("sfaccettatura") dell'oggetto da classificare indipendentemente dalle proprietà descritte dalle altre faccette. Se il sistema può accogliere nuove faccette senza doversi "aggiustare" globalmente, ed è quindi intrinsecamente scalabile, si ripropone tuttavia anche in questo caso a questione della riclassificazione. L'aggiunta di una faccetta rende infatti necessaria la riclassificazione di tutte le entità secondo la nuova faccetta e, quando migliaia sono gli oggetti già classificati, il lavoro non è certo di poco conto. È però evidente come l'aggiunta di una faccetta abbia vantaggi di gran lunga superiori rispetto all'inserimento o alla modifica di una o più categorie in uno schema gerarchico. Una faccetta in più determina infatti un aumento esponenziale del numero delle combinazioni potenziali e, quindi, un livello di specificazione maggiore del carattere descrittivo delle classi. Cosa comporta, invece, l'introduzione di un nuovo focus in una faccetta? I problemi si avranno se l'aggiunta di un nuovo focus rende non mutuamente esclusive le classi: essendo queste parte di una precisa tassonomia costruita sulla base del principio di divisione della faccetta, si ripropongono infatti gli stessi

- 14 -

problemi di inserimento e di riclassificazione tipici delle classificazioni gerarchico-enumerative: la riclassificazione del materiale non riguarderà tutti gli item, ma è tuttavia probabile per una parte di questi. È consigliabile allora prestare sempre molta attenzione e tempo alla preliminare analisi a faccette: tale fase è, infatti, di strategica importanza nello sviluppo di un sistema di classificazione analitico-sintetico e, se compiuta con cura, evita poi problemi di riclassificazione.

1.4.3 I vantaggi per l'utente

Sono stati dimostrati i vantaggi che l'adozione sul Web di uno schema a faccette può comportare per il lavoro dei designer e degli architetti dell'informazione di un sito, consentendo loro di fare affidamento su un sistema aperto, facilmente scalabile e flessibile in fase di indicizzazione. Per esaminare i vantaggi degli schemi a faccette sul Web in una prospettiva di esperienza-utente, invece, è necessario ritornare alla "questione dell'incoerenza", e chiederci perché i siti web facciano così ampio uso di classificazioni altamente ibride e incoerenti nonostante le difficoltà che queste possono comportare per l'utente. Il motivo principale di tale utilizzo può essere fatto risalire alla necessità di inserire nel top-level della gerarchia (e quindi in homepage) il numero più alto possibile di "categorie popolari", attuando così una strategia di "popularity-based classification". Lo scopo è quello di consentire all'utente un accesso più veloce a tali "categorie popolari", intendendo con questa espressione gli argomenti, i servizi, le azioni, i prodotti, e in generale tutti gli item classificati, che sono considerati più rilevanti per le tipologie di utente a cui il sito si rivolge. Uno schema di classificazione rigorosamente coerente può comportare il rischio che alcune categorie ritenute popolari, o addirittura tutte, siano collocate in nodi inferiori e diversi dello schema, causando così sia un aumento delle difficoltà nel loro ritrovamento da parte dell'utente, sia la necessità di un numero di click maggiore rispetto all'ipotesi in cui tali categorie fossero direttamente disponibili in homepage. Se l'obiettivo è realizzare una "popularity-based classification", spesso risulta allora essere necessario rinunciare alla coerenza dello schema (mutua esclusività delle categorie e adozione di un unico principio di divisione per nodo). In una struttura gerarchico-enumerativa, la progettazione di una "popularity-based classification" può infatti implicare che le categorie del top-level: • siano fra loro sovrapponibili; • siano generate con principi di divisione differenti. Di fatto, attraverso una "popularity-based classification", i siti web cercano di soddisfare già in homepage molti dei bisogni informativi e delle esigenze dei loro potenziali utenti. Sanno benissimo, nonostante a dir la verità non ci sia un totale accordo su questo tema, che al navigatore del Web non piace fare molti click per arrivare a ciò che cerca. Sanno anche che uno schema di classificazione è sempre soggettivo e arbitrario: orientarsi nelle tassonomie compilate da altri non è spesso semplice. Riassumendo, le classificazioni gerarchico-enumerative pienamente coerenti determinano un doppio vincolo: • possono spingere in basso le categorie popolari;

- 15 -

• non permettono ad uno stesso livello (e in particolare in homepage) strategie di navigazione e di ricerca differenti, cioè secondo diversi principi di divisione/raggruppamento.

L'usabilità e l'utilità in un sistema di questo tipo risultano compromesse, soprattutto se la strategia è quella di una classificazione che soddisfi il prima possibile, magari già in homepage, le esigenze più popolari. Sembrano esserci allora motivi sufficienti per sposare la causa dell'incoerenza, come d'altronde fanno molti degli indici sistematici e dei portali della rete. Le classificazioni a faccette, in quanto multidimensionali (diversi criteri di divisione possono essere applicati contemporaneamente), permettono di aumentare notevolmente il numero di esigenze di ricerca e di interrogazione soddisfatte, senza rinunciare alla coerenza. Gli utenti possono iniziare la ricerca dalla faccetta che più interessa loro: ognuno potrà trovare tutti gli item che rispondono a quella che considera essere la caratteristica più importante, senza l'obbligo di un unico percorso che parta da una faccetta specifica e senza dover controllare diverse sottocategorie. Il sistema garantisce infatti una pluralità di accessi, cioè una molteplicità di modalità di navigazione e di ricerca secondo principi di divisione differenti e, quindi, secondo bisogni informativi diversi. Si realizza così un ottimo sistema di accessi multipli. Ogni faccetta corrisponde a un tipo di esigenza degli utenti: eliminando un principio di divisione che potrebbe essere utile, non si permette più agli utenti di navigare lo schema secondo la corrispondente modalità di ricerca/esigenza. Un'interfaccia analitico-sintetica può inoltre risolvere la questione delle categorie popolari: sotto l'etichetta della faccetta corrispondente non saranno elencati tutti i fuochi, soprattutto se troppi, ma solo quelli che si prevede verranno cliccati più frequentemente dagli utenti, magari ordinandoli proprio per popolarità e non sulla base di un criterio alfabetico. Se l'utente preferirà vederli tutti, potrà farlo in un secondo tempo. Inoltre, se i criteri di divisione vengono pure chiaramente mostrati la classificazione diventa anche autoesplicativa e trasparente, risolvendo il problema, tipico di uno schema gerarchico-enumerativo classico, di non avere "una struttura esplicita tale da appalesare o da adombrare la teoria che esso incarna" (Serrai, 1977). La familiarizzazione con lo schema diventa, quindi, non più necessaria. Riassumendo, si realizza quindi un sistema che prevede: • accessi multipli sulla base di diversi bisogni informativi; • la soddisfazione, senza troppi click, delle esigenze più popolari; • una classificazione coerente, intuitiva e autoesplicativa. Aggiungendo a questa lista anche le proprietà, già evidenziate, di apertura, scalabilità, flessibilità e possibilità, senza controindicazioni, di cross-classification in fase di indicizzazione, è ora possibile cogliere tutte le potenzialità che l'applicazione al Web della teoria delle faccette comporta.

1.4.4 Il caso wine.com Anche il sito wine.com offre un esempio di felice applicazione della classificazione mediante faccette. Fin dalla homepage, sono presentate all’utente diverse opzioni di accesso (browsing) al catalogo dei vini.

- 16 -

Figura 1.1 –Schermata iniziale del “wine shop” PRICE, REGION e TYPE rappresentano le faccette primarie di questo catalogo, a sua volta ripartite in topics (o faccette di secondo livello). Anche in questo caso, è possibile utilizzare le faccette in combinazione (mediante la ricerca avanzata), così da ottenere un set di risultati che soddisfano più criteri.

Figura 1.2 – Esempio di ricerca avanzata dei vini

- 17 -

Capitolo 2 - Analisi di faceted browser

2.1 I browser visionati

La maggior parte del tirocinio svolto presso l'Intellisemantic srl è stata dedicata alla ricerca e analisi delle prestazioni di browser a faccette. I facet browsers visionati sono i seguenti:

Progetto Creatori Sito del progetto

Flamenco Università di Berkeley http://flamenco.berkeley.edu/

Longwell SIMILE (MIT Libraries e MIT CSAIL)

http://simile.mit.edu/wiki/Longwell

AquaBrowser Medialab http://www.medialab.nl/

mSpace Università di Southampton, School of Electronics and Computer Science

http://www.mspace.fm/

Autofocus Aduna http://www.aduna-

software.com/products/autofocus/

Swed Università di Bristol http://www.swed.org.uk/

Ho deciso di esaminare più approfonditamente, in questa monografia, questo gruppo di soluzioni perché penso compongano un quadro generale sufficientemente vario e descrittivo delle diverse applicazioni della classificazione a faccette presenti nel web. Quindi sono andata a specificare meglio i programmi nella tabella, tentando di farne un confronto in base ai parametri sotto riportati: � Funzionalità: descrizione delle caratteristiche generali del progetto. � Architettura del software: descrizione dei moduli che compongono il progetto e

permettono la realizzazione di tutte le sue funzionalità.

- 18 -

� Prerequisiti richiesti: risorse che l’utente necessita per poter far funzionare il software sul proprio sistema.

� Esempi di utilizzo con relativi link: descrizione di alcune demo e siti che utilizzano i software.

� Interfaccia utente: giudizio di come le funzionalità del browser vengono visualizzate all’utente.

� Output search testuale: in che modo vengono visualizzate le risorse che sono il risultato della search “tradizionale.

� Dati in ingresso: descrizione dei formati dei dati che premettono alle risorse di essere catalogate

� Open source si/no?

2.2 The Flamenco Search Interface Project

2.2.1 Introduzione Flamenco (FLexible information Access using MEtadata in Novel Combinations) è un progetto curato dall'Università di Berkeley, scritto in Python, che consiste in un motore di ricerca e directory organizzati con il criterio delle faccette, disponibile open source con licenza BSD. E’ uno strumento concepito per guidare gli utenti attraverso la vastità delle informazioni d'architettura presenti sul web. L'interfaccia muove i suoi esploratori attraverso categorie di scelta e parole chiave in un'organizzazione strutturale fondata sul metadato. Consente quindi un'amplificazione delle tradizionali pratiche di catalogazione bibliografica in ambiente elettronico.

2.2.2 Demo (Nobel Prize Winners)

Accedendo alla demo, si nota subito la presenza di una doppia via: • la ricerca diretta; • una directory di link.

Figura 2.1 – Interfaccia della demo di Flamenco utilizzato per catalogare i vincitori dei premi nobel

- 19 -

Come si può osservare nell’immagine la directory di link si presenta graficamente simile a quella di Yahoo o Google dando l’impressione che ogni riquadro colorato sia l’insieme di oggetti diversi. In realtà la logica della directory è molto diversa: ciascun ramo rappresenta un percorso di accesso alternativo alla stessa collezione di items ma parallelo agli altri; ogni riquadro è quindi una faccetta della medesima collezione, rappresentato visivamente con un colore diverso dagli altri. E’ necessario notare che le faccette rappresentano non tanto un contenitore dei dati a nostra disposizione ma un loro descrittore semantico (proprietà o aspetto dei dati stessi). E’ possibile effettuare, sfogliando la directory, una selezione progressiva definita “filtraggio” . Una volta operata una prima selezione è sempre possibile raffinare ulteriormente la ricerca all'interno del sottoinsieme estratto utilizzando le altre faccette che vengono sempre ripresentate assieme ai risultati. Inoltre, per ogni insieme di risultati vengono specificate le sue coordinate semantiche rispetto a tutte le faccette del sistema: oltre a mostrare l’insieme dei risultati, Flamenco rende visibile la collocazione di tali risultati rispetto alle varie faccette. Il motore di ricerca associato alla directory lavora in modo simile: quando si opera una ricerca diretta, esso non esegue una semplice ricerca full-text, ma si appoggia al sistema di classificazione a faccette per estrarre i risultati. L’utente, impiegando in modo combinato e complementare searching e browsing, può: • scegliere se cercare un’informazione mediante ricerca diretta o sfogliando una

directory; • raffinare o espandere i risultati della propria ricerca; • esplorare risorse correlate in maniera semantica a quelle trovate; • scegliere punti di vista alternativi in ogni momento.

2.2.3 Prerequisiti richiesti Per utilizzare il server di Flamenco, serve un computer su cui è installato Linux o Mac OS X con: • Web server che supporta CGI scripts (es: Apache è preinstallato in Mac OS X e

nella maggior parte dei sistemi Linux); • Python 2.3 o superiore.

Flamenco usa anche il modulo di MySQLdb per Python; se non è già installato Flamenco lo installa automaticamente usando una copia di MySQLdb che è inclusa nella distribuzione di Flamenco. Serve, quindi, un account MySQL per avere il permesso di creare nuovi database o avere l’accesso al database in cui flamenco raccoglie le collection dell’utente.

- 20 -

Lucene è usata opzionalmente per garantire una ricerca full-text ottimizzata (la ricerca full-text è già disponibile via MySQL senza l’uso di Lucene). Se si desidera integrare Lucene bisogna avere: • Java (JRE) 1.2 or superiore. • Accesso al proprio MySQL server sulla porta TCP 3306.

2.2.4 Architettura SW Il diagramma seguente illustra l’architettura SW di Flamenco (i blocchi colorati sono parte di Flamenco). Tutti i blocchi (eccetto Java, MySQL, Lucene e WebKit) sono scritti in Python.

Figura 2.2 – Architettura di Flamenco I metadati relativi agli oggetti della collection sono salvati in un database SQL. Flamenco usa MySQL, sebbene qualunque database SQL sarebbe sufficiente. MySQLdb è l’interfaccia Python per MySQL. Flamenco usa anche il motore di ricerca Lucene, scritto in Java, per le sue caratteristiche della “full-text search”. Se java o Lucene non sono disponibili la ricerca testuale è implementata usando MySQL. Il modulo metadb, “core” dell’implementazione a faccette dei metadati di Flamenco, fornisce un livello di astrazione sopra il database SQL e le funzionalità di ricerca testuale. Il modulo html fornisce le funzionalità per generare HTML. Il modulo components usa le informazioni salvate nel database per costruire l’interfaccia utente di Flamenco. Queste parti sono combinate insieme e trasformate in pagine Web dal modulo Flamenco. Floogle e FrankenMatrix sono altre variazioni dell’interfaccia utente.

- 21 -

Il CSS per l’interfaccia utente è generato dinamicamente dal modulo FlamencoStyle che è composto da css, generatore automatico di fogli di stile, and Style, per inviare CSS anzichè HTML. WebKit, parte di Webware, permette la corretta visualizzazione delle pagine generate e dei fogli di stile.

2.2.5 Dati in ingresso Per caricare una collection in Flamenco devono essere forniti i metadati relativi alla collection in “tab-delimited” files (TSV files, estensione ".tsv") che possono essere facilmente manipolati usando OpenOffice o Microsoft Excel. Una collection di Flamenco è un set di oggetti tutti dello stesso tipo (es: tutti gli oggetti sono libri, tutti gli oggetti sono canzoni,…) mentre i metadati relativi a un oggetto consistono nei suoi valori delle faccette e degli attributi. Il primo passo nella preparazione di una collection è decidere quali informazioni diventeranno faccette e quali attributi: i valori delle faccette sono usati per organizzare gli oggetti in categorie mentre i valori degli attributi sono solo visualizzati con un oggetto individuale.

Figura 2.3 – Esempio di faccette e attributi di una collection Nell’esempio, relativo alla demo sui premi nobel, “prize” è una faccetta che indica il tipo di premio nobel vinto mentre “name” è un attributo che indica il nome del vincitore. Infatti, ha senso raggruppare i vincitori in categorie per il tipo di premio e non per i loro nomi. I valori delle faccette sono associati a un numero ID mentre i valori degli attributi sono stringhe.

- 22 -

I file TSV che bisogna fornire sono: � attrs.tsv

Tabella in cui ogni linea rappresenta un attributo. Il campo attribute identifier deve essere un nome corto e univoco che contiene solo lettere e “_” (no spazi o punteggiatura) mentre displayable name è ciò che viene visualizzato dall’utente.

� facets.tsv

Tabella in cui ogni linea rappresenta una faccetta. Il campo facet identifier deve essere un nome corto e univoco (anche rispetto agli attributi) che contiene solo lettere e “_” , displayable name è ciò che viene visualizzato dall’utente e long description fornisce una descrizione dettagliata della faccetta.

� items.tsv

Tabella che fornisce ID e attributi per tutti gli oggetti. Ogni oggetto ha un suo ID univoco che può essere una stringa o un numero. Il campo item identifier è seguito dai valori degli attributi per l’oggetto nell’ordine in cui gli attributi sono inseriti in attrs.tsv.

� facet_terms.tsv

Tabella che, per ogni faccetta ( facet è il “facet identifier” di facets.tsv), fornisce l’albero dei termini delle categorie nella faccetta. E’ l’unico file che, in ogni riga, può avere un diverso numero di campi. Ogni linea rappresenta una categoria e fornisce l’intera catena di categorie “padre”. Il campo term identifier deve essere un numero univoco all’interno della faccetta.

� facet_map.tsv

- 23 -

Tabella che, per ogni faccetta, collega gli oggetti ai termini della categoria. � sortkeys.tsv

Tabella opzionale che indica quali faccette o attributi sono utilizzate per ordinare i risultati. Il campo description è il testo del link da usare per ordinare i risultati.

� text.tsv

Tabella opzionale che supporta la ricerca testuale per Flamenco.

2.3 MIT Longwell

2.3.1 Introduzione Longwell è un web browser RDF a faccette, scritto come un’applicazione web java, che visualizza il contenuto del thesaurus nascondendo il modello RDF sottostante. E' disponibile open source con licenza BSD-style. E’ un progetto creato e gestito da SIMILE, joint project di MIT Libraries e MIT CSAIL.

2.3.2 Demo (MIT Libraries)

Figura 2.4 – Pagina iniziale della demo di Longwell

- 24 -

Una faccetta è un particolare metadato che è considerato importante per l’insieme di documenti che sto navigando. Quando una collection è selezionata, Longwell inizia a processare l’insieme dei documenti ed estrae una lista di faccette, i loro valori e il numero di volte che ciascun valore della faccetta è presente nel dataset (colonna a destra della schermata) Cliccando sul titolo della faccetta è possibile visualizzarne i valori.

Figura 2.5 – Esempio della ricerca a faccette della demo di Longwell Aggiungere restrizioni nel pannello di destra ha l’effetto di “zoom in” nel dataset, cioè, di rimuovere dall’elenco tutto ciò che non ci interessa. Quando non è più possibile un’ulteriore restrizione per faccette il pannello di destra risulta vuoto. Allo stesso modo l’utente può effettuare “zoom out” rimuovendo delle restrizioni inserite precedentemente (nella parte alta a sinistra della schermata). Il risultato della restrizione è una selezione degli oggetti presenti nel dataset. Longwell può anche essere configurato per visualizzare particolari proprietà degli oggetti in diversi modi, e, con i fogli di stile CSS, è possibile ottenere una bella presentazione dei dati senza dover modificare il codice sorgente di Longwell. Longwell ha anche l’abilità di usare una restrizione “free-text” che riduce il dataset a tutti gli oggetti che contengono la stringa cercata nei valori delle loro proprietà. Questa restrizione è attivata inserendo il testo nel box sopra la lista delle faccette.

- 25 -

2.3.3 Prerequisiti richiesti I requisiti necessari per utilizzare Longwell su dati RDF: • Java Virtual Machine (JVM) versione 1.4 o superiore • Apache Maven 2.0

2.3.4 Architettura SW

Il lato Client di Longwell ha 3 componenti: Query Engine, History, User Interface.

Query Engine Questo componente tiene traccia della corrente “faceted query” che consiste in due collections di facette: • “root facets”: selezione delle cose tramite cui l’utente può rifinire la ricerca. • “current facets”: risultato della navigazione a faccette, cambiano ogni volta che

l’utente interagisce con le faccette nella UI.

History Component

E’ responsabile di tener traccia delle azioni dell’utente e di rispondere all’uso dei pulsanti di “backward” e “forward” del browser.

User Interface Component UI è formata da 3 parti: • “control panel”: in alto a sinistra e contiene il pulsante “Add View”. • “browse panel”: a destra, contiene i controlli per la navigazione del dataset

(facets e text search). • “view panel”: oggetti visualizzati dall’utente. Queste 3 parti si comportano in maniera diversa a seconda della presenza o meno di restrizioni.

2.4 AquaBrowser Library

2.4.1 Introduzione AquaBrowser è un potente motore di ricerca e visualizzatore di dati che consente il recupero di informazioni, sviluppato in maniera specifica per le biblioteche, e supportato da sistemi di associazione tra termini, varianti di scrittura, tesauri e varianti linguistiche del termine o dei termini ricercati. Offre inoltre la possibilità di gestione amministrativa e produzione di statistiche finalizzate sia al miglioramento del servizio, sia ad una più puntuale configurazione del sistema stesso.

- 26 -

E’ una soluzione a pagamento realizzata dalla società olandese Medialab.

2.4.2 Demo (Queens Library)

L'interfaccia presenta tre differenti funzioni di recupero e presentazione delle informazioni: search, discover, refine.

Figura 2.6 – Interfaccia della demo di AquaBrowser per la Queens Library

Search

Figura 2.7 – Funzione di search nell’interfaccia di AquaBrowser

ABL consente agli utenti di cercare informazioni sul proprio catalogo e presenta i risultati di tale ricerca in una lista, personalizzabile, ordinata per rilevanza rispetto alla query stessa.

- 27 -

Altri criteri di ordinamento (per titolo, per data, per autore etc.) sono disponibili per una differente presentazione dei medesimi risultati, in relazione alle specifiche esigenze di ricerca dell'utente.

Figura 2.8 – Selezione del criterio di ordinamento dei risultati Dalla schermata di presentazione dei risultati è possibile, attraverso una semplice funzione di navigazione, accedere direttamente al catalogo informatizzato della biblioteca (OPAC) per fruire dei servizi (informazioni sulle copie, prestito, prenotazione, document delivery etc.) a cui l'utente è abilitato.

Discover Funzione di navigazione delle informazioni attraverso una “nuvola” o “galassia di termini” relazionati, in vario modo, al termine ricercato.

Figura 2.9 – Funzione di discover nell’interfaccia di AquaBrowser

- 28 -

Ponendo al centro della “galassia” il termine ricercato, il sistema recupera e presenta, come “suggerimenti” di esplorazione del catalogo, una serie di termini relazionati al termine ricercato per associazioni (i termini più utilizzati nei record in associazione a quello ricercato), per traduzioni (le traduzioni linguistiche del termine ricercato), per sinonimi, per varianti di scrittura, per gerarchie tesaurali. La galassia o nuvola di termini associati a quello ricercato si rigenera ad ogni nuova ricerca e ad ogni nuova esplorazione del catalogo.

Refine Consente all'utente di filtrare la propria ricerca al fine di recuperare cio che è di suo interesse. Questa funzione permette, partendo dal risultato di una query, di recuperare una serie di filtri da utilizzare ai fini di un ulteriore restringimento delle proprie ricerche cioè di effettuare una navigazione a faccette.

Figura 2.10 – Funzione di refine nell’interfaccia di AquaBrowser Ogni biblioteca, in relazione alle abitudini ed attitudini della propria utenza, decide quali categorie di dati mettere a disposizione nella sezione di Refine come filtri delle successive ricerche.


Figura 2.11 – Architettura SW di AquaBrowser

- 29 -

• Data Connectors: link tra Aquabrowser e le sue sorgenti di dati; trasformano i

dati in input nel formato di Medialab. Medialab ha sviluppato “data adapters” per informazioni non strutturate (Microsoft Word e Excel, HTML e siti web) ma anche per informazioni strutturate come quelle fornite da MSSQL, XML, …

• Knowledge Builder: fornisce un’analisi dei dati in input usando la frequenza delle parole e l’analisi delle co-occorrenze per creare una rete semantica che può supportare i processi di search e refine.

• Igor : motore di ricerca di AquaBrowser. • Context Builder: insieme di componenti che crea l’ambiente di navigazione per

gli utenti. Arricchisce le queries, fornisce suggerimenti, aiuti e altri tipi di feedback. Inoltre, compila i risultati della ricerca e le associazioni dal motore di ricerca. Questo componente inoltre fornisce l’opzione di refine sul set di risultati.

• User Interface: unisce tutto insieme. Presenta i risultati e offre l’ambiente per formulare le queries.

2.5 mSpace

2.5.1 Introduzione

mSpace è un servizio di interfaccia che include un modello di interazione e un software framework per aiutare le persone ad accedere ed esplorare le informazioni sviluppato dalla School of Electronics and Computer Science (università di Southampton) scritto in javascript e PHP. mSpace software framework può essere scaricato gratuitamente dal sito di sourceforge. Presenta molte categorie associate alle informazioni e permette di manipolarle e decidere quante presentarne e come. In questo modo le persone possono organizzare le informazioni rispetto ai loro interessi e contemporaneamente avere a disposizione percorsi complementari per accedere alle stesse risorse.

2.5.2 Demo Cosa succederebbe se voglio trovare qualcosa da un dominio di cui ho un interesse generale senza averne una conoscenza specifica? mSpace utilizza come esempio della sua demo una raccolta di brani di musica classica e si chiede: come fare a trovare un brano di musica classica che può piacere, utilizzando Google, se non si conosce la differenza tra Beethoven e Chopin o non si sa cosa sia una sonata? Se digito classical music su Google troverò una lista di pagine informative sulla musica classica: descrizioni sui termini e sui brani, raccomandazioni su cosa ascoltare, biografie dei compositori,…Tantissima informazione dispersa in una marea di click!

- 30 -

Figura 2.12 – Schermata di Google iTunes Music Store potrebbe aiutare: la sua “browse area” permette di usare il software iTunes per navigare la musica disponibile nel suo store.

Figura 2.13 – Schermata di iTunes Ma anche in questo caso devi già sapere ciò che vuoi e quale artista vuoi ascoltare. Non si può organizzare il browser in altre categorie, per es: strumenti (piano, violino, violoncello,..) o genere (sinfonia, sonata, concerto,..) o periodo (romantico, contemporaneo, …), ecc.... Non si ha nemmeno la possibilità di avere informazioni sul significato dei termini presenti nel browser. Ciò che mSpace fa è combinare la semplicità di iTunes con le informazioni che ottengo dalla Google search. mSpace software framework consente di organizzare qualunque tipo di dati in un browser simile, graficamente, ad iTunes, associarci delle informazioni ed esplorarli nel modo che l’utente preferisce. Avendo una lista di brani di musica classica, siti che contengono informazioni sulla musica classica (nella rete) e un set di categorie, si può applicare il framework mSpace a queste risorse per associarle l’une alle altre. L’interfaccia mSpace permette poi di esplorare e manipolare le informazioni.

- 31 -

Figura 2.14 – Schermata di mSpace

La figura 2.14 mostra “ mSpace Classical Music Broswer”: ci sono tre categorie(Era, Composer and Piece) disposte in modo simile ad iTunes e una finestra “Information” in cui è visualizzata la descrizione dell’elemento che clicco in una categoria.

Figura 2.15 – Funzione “preview cues” di mSpace Il testo è utile ma alcune volte non è sufficiente, specialmente quando ciò che sto cercando riguarda la musica o i video. Con mSpace passando con il mouse sopra un titolo in una categoria visualizzo una selezione definita “preview cues”. Per esempio, se non conosco il suono della musica Romantica posso cliccare sulla “preview cues” di “Romantic” e ascoltare un esempio del tipo di musica che trovo lì dentro.

- 32 -

Figura 2.16 – Scelta delle categorie di mSpace Inoltre in mSpace l’utente ha la possibilità di organizzare l’informazione come desidera scegliendo quali categorie usare, per organizzare l’informazione, aggiungendole o sottraendole dall’elenco in alto nella pagina. mSpace può essere applicato potenzialmente a qualunque area informativa (film, Internet Movie Database (IMDB),… )

2.5.3 Tecnologia

Il Semantic Web

Le macchine che processano pagine Web non sanno nulla del loro contenuto. I motori di ricerca cercano documenti che contengano le parole ricercate e producono una lista di risultati. Con il Web Semantico vengono aggiunti dati alle pagine che aiutano le macchine a creare connessioni tra le pagine e anche a compiere ragionamenti sulle pagine stesse. Ma, oltre che ritornare più e migliori risultati, il Web semantico può essere utilizzato per creare associazioni e questa è la caratteristica alla base di mSpace.


- 33 -

Figura 2.17 – Architettura di mSpace • MK: Ogni datastore all’interno del modello mSpace è gestito da un Server

mSpace Knowledge (MK) associato. Questo livello di astrazione permette l’accesso a ogni “Semantic storage” scelto, presentandolo con un protocollo fissato.

• MQ: mSpace Query Servers sono potenti che gestiscono il complicato e intenso processo richiesto per fare query attraverso MKs multipli. Questa distribuzione permette ai clients meno “potenti” (MAs) di avere l’accesso alle informazioni semantiche richieste in maniera efficiente. Le queries sono costruite qui e vengono mandate su un protocollo fissato ai MKs per ottenere i risultati.

• MA mSpace Mobile è un esempio di un’applicazione mSpace (MA). Possono esistere molte applicazioni mSpace e possono riferirsi a svariate sorgenti di conoscenza. Con l’astrazione a tre livelli sopra, un poco potente dispositivo mobile può facilmente avere accesso alle informazioni tramite qualsiasi MQ che può produrre ed eseguire queries complicate e ritornare risultati semplici.

2.6 Aduna Autofocus

2.6.1 Introduzione AutoFocus è un software di Desktop Search sviluppato dalla società olandese Aduna, disponibile open source e senza registrazione richiesta con licenza OSL e Aduna Commercial License (ACL). Il software è stato creato per permettere il reperimento di documenti testuali (anche in diversi formati) all'interno di file system ma anche di siti web, intranet, IMAP email server e in Microsoft Outlook. Il sistema software è stato pensato per fondere assieme tre meccanismi che possano aiutare nel migliore dei modi l'utente nella propria ricerca: fulltext search, metadati e cluster map. Il primo permette di ricercare tramite query i documenti che contengono i termini richiesti dall'utente, i secondi sono sfruttati per agevolare ulteriori scremature nella ricerca usando le faccette e l'ultimo permette di visualizzare e analizzare i risultati ottenuti in un modo visuale più diretto.

- 34 -

Il maggior vantaggio rispetto a tools simili è quindi che AutoFocus presenta i risultati della search usando le faccette e Cluster Maps. AutoFocus ha l’abilità di monitorare tutte le sorgenti in cui ci si aspetta di avere informazioni preziose e fornisce i mezzi per la ricerca mirata di quelle informazioni. Dall'analisi effettuata si evince come il sistema utilizzato sia piuttosto innovativo sotto certi aspetti e di certo diverso dai più comuni strumenti di Desktop Search. Lo strumento sembra più indirizzato ad essere una guida nelle ricerche dell'utente, comunque lascia molto spazio per operare a chi lo utilizza, senza contare il fatto che l'interfaccia utente è realizzata piuttosto bene. Per certi aspetti questo potrebbe essere interessante, e di sicuro risultare accattivante per un utente medio per via della visualizzazione grafica dei risultati, che aiuta e stimola ad interagire con lo strumento.

2.6.2 Demo

Figura 2.17 – Schermata di Autofocus � Desktop client per una search basata su metadati e un’esplorazione delle sorgenti

dei dati personali.

- 35 -

� Ricerca più efficiente grazie ai termini suggeriti (suggested search terms) � Risultati della search visualizzati in Cluster Maps per mostrare la

sovrapposizione tra le queries. � Sorgenti: File systems, IMAP e-mail servers, HTTP servers � Tipi di file supportati: è una lista lunga e in continua crescita, ad esempio: MS

Office, Open Office, txt, html, pdf, xml � Versione: 4.0 beta 3 (Maggio 2007) � Piattaforme: Windows, Linux, Mac OS e tutte le altre piattaforme Java 5-enabled � Può connettersi a AutoFocus Server(s) per l’amministrazione centrale.

2.6.3 Prerequisiti richiesti Sistema operativo

• Windows 98 (Second Edition) • Windows ME • Windows NT 4.0 SP6 e successivi • Windows 2000 SP3 e successivi • Windows XP SP1 e successivi • Solaris 8 e successivi • Red Hat Linux 8 e successivi • SuSe Linux 8 e successivi • Mandrake Linux 9 e successivi • MacOS X

n.b.: AutoFocus può girare su qualunque piattaforma con una Java virtual machine usando il Java installer, anche se non è garantito il suo corretto funzionamento.

Hardware richiesto

• CPU: il minimo è Pentium II a 400 MHz, raccomandata Pentium III a 1 GHz o superiore.

• RAM: minimo 128 MB, raccomandata 256 MB. • Spazio su disco: 100 MB + 2 MB ogni 1000 items.

2.6.4 Tecnologia

AutoFocus è basato sulle seguenti tecnologie: • Aperture : per l’estrazione e la richiesta di contenuti full text e di metadati di file

systems, caselle mail e siti web.

- 36 -

• Sesame: per uno storage scalabile e veloce dei metadati. • Cluster Map Library: per la visualizzazione delle Cluster Maps. AutoFocus è un sistema di reperimento dell'informazione basato sul modello booleano, ma la struttura generale con cui unisce le funzionalità di metadati e fulltext search è abbastanza complessa. Per l'archiviazione dei metadati, il software sfrutta le potenzialità di Sesame, mentre per l'indicizzazione del fulltext si appoggia alla libreria Lucene. Per fondere le due componenti all'interno del sistema è stato creato un Sail tra i due (LuceneSail.java), e sfruttato il framework Aperture (anch'esso sviluppato da Aduna). Questo in sostanza ha la funzione di estrarre metadati e fulltext (Data Objects) dalle collezioni prescelte (Data Sources) attraverso un apposito Crawler, operando in modo diverso dopo aver distinto attraverso il MIMEType il tipo di documento ed utilizzando appositi Extractors. A questo punto avviene la connessione al Sail prima citato e vengono memorizzati i DataObject raccolti. In particolare alcuni tipi di dati verranno indicizzati con Lucene (per esempio fulltext), altri saranno inseriti come metadati negli archivi di Sesame (per esempio la data di ultima modifica del documento), mentre altri ancora saranno sia raccolti in Sesame sia indicizzati con Lucene (per esempio titolo e autore). I dati archiviati in Sesame sono direttamente raggiungibili tramite query in linguaggio SERQL, mentre i dati indicizzati da Lucene sono reperibili attraverso l'uso di una o più proprietà virtuali del grafo RDF che connette la risorsa alla query di Lucene, contenuta come literal nella query RDF. A questo punto la query di Lucene viene valutata sull'indice creato e viene ritornata la lista degli URI dei documenti ricercati, utilizzata eventualmente per effettuare un join con altre sottoquery di Lucene.

Figura 2.18 – Struttura di Aduna Aperture

- 37 -

Indicizzazione

Gli sviluppatori di AutoFocus hanno ritenuto utile non dare troppo peso alle consuete fasi che solitamente precedono l'indicizzazione del testo di una collezione di documenti (analisi lessicale, stopwords, stemming, etc), e quindi hanno creato un Analyzer (CountingAnalyzer.java) che si appoggia alla classe StandardAnalyzer di Lucene, ma senza sfruttarne totalmente le potenzialità. Viene infatti eseguita solamente un'analisi lessicale, con conseguente pulitura del testo. Un'unica operazione aggiuntiva che viene svolta (anche se in verità poco legata all'indicizzazione del fulltext, perchè le informazioni estratte vengono inserite nei metadati) è quella di memorizzare per ogni documento una lista di parole significative, ma questo viene fatto con un algoritmo piuttosto “crudo”. Dato il documento senza stopwords (vengono eliminate le stopwords delle varie lingue supponendo che la loro interferenza sia minima) vengono prese semplicemente le prime dieci parole ritenute significative (SignificantTermsExtractor.java). Si nota quindi come gli sviluppatori abbiano cercato di puntare per questo strumento alla rapidità nello svolgimento delle operazioni a discapito di altre qualità. Probabilmente si è inteso sopperire a tali mancanze con le potenzialità di altri parti del sistema, come l'uso delle Cluster Map. Per quanto riguarda invece l'indicizzazione vera e propria del testo vengono utilizzate le classi della libreria Lucene. In particolare vengono riprese le classi IndexWriter, Document, e Field, le quali permettono la creazione dell'indice (IndexWriter) e l'aggiunta dei vari elementi all'interno di esso (Document e Field). Gli elementi contenuti nell'indice sono detti appunto Documents, i quali contengono a loro volta vari campi (Field appunto) che altro non sono che coppie del tipo nome/valore. La creazione dell'indice viene effettuata attraverso un metodo detto Inverted Indexing (questo perché può elencare per ogni termine i documenti che lo contengono), che consiste nella creazione per ogni documento di singoli indici (segments) i quali vengono di volta in volta caricati direttamente in memoria principale, per ottimizzare i tempi di operazione. Per ogni segment viene tenuto un riferimento in uno stack. Durante la sua evoluzione l'indice può svilupparsi quindi aggiungendo singoli segment, oppure facendo un merge di indici già esistenti in un indice di taglia maggiore. La creazione di un singolo indice avviene per lo più in quattro fasi): creazione di uno stream di Token (eventualmente ripuliti da Stop word e/o a cui viene applicato un algoritmo di Stemming), inversione del documento tramite uso di una HashTable, ordinamento della tabella di hash tramite quickSort, scrittura delle hashtable su disco ed eventuale merge con altri segment.

- 38 -

Figura 2.19 – Creazione indice di Lucene Tale procedura risulta piuttosto efficace, in quanto comprende operazioni la cui complessità temporale è ragionevolmente contenuta. All'interno di ogni indice, tra le varie informazioni viene mantenuto anche un dizionario dei termini usati nei field dei vari documenti, e possibilmente anche il numero di documenti contenenti quel termine.

Interrogazione

Tutte le query sono elaborate attraverso lo stesso Analyzer usato anche nell'indicizzazione. Questa strategia fa si che, data una query qualsiasi, venga ritornato il maggior numero di documenti potenzialmente rilevanti (tutti quelli dove è contenuto almeno un termine dell'interrogazione), il che è sostanzialmente in accordo con la linea di pensiero con cui è stato sviluppato il sistema. Come già accennato infatti, AutoFocus mira non tanto a ritornare immediatamente i soli documenti rilevanti, ma in generale a mettere a disposizione dell'utente uno strumento che permetta di orientare la sua ricerca in più passi. Per questo è stata sviluppata una libreria grafica (basata sulla libreria Java Swing) che permette di visualizzare i risultati della ricerca effettuata e capire quali documenti possano essere rilevanti o meno. La libreria prende il nome di Cluster Map Library , e permette la visualizzazione dei risultati di un'interrogazione tramite una sorta di diagramma di Venn, dove tutti i documenti reperiti da una stessa query sono raggruppati in uno stesso insieme (Cluster). Nel caso fossero effettuate più interrogazioni, saranno visualizzati (se presenti) i documenti che determinano l'intersezione tra esse. In questo modo l'utente, per mezzo di più interrogazioni, può orientare la propria ricerca verso gli insiemi formati dall'intersezione dei cluster, oppure può rendersi conto di aver indirizzato male la propria ricerca (nel caso le query fatte non diano intersezioni). Oltre alle query l'utente potrà sfruttare anche

- 39 -

alcune funzioni operanti sui metadati raccolti, che permettono di restringere ulteriormente il raggio d'azione della ricerca. Oltre alla visualizzazione con la Cluster Map, viene inoltre data una visualizzazione testuale in elenco dei documenti reperiti con informazioni supplementari (es. titolo, parte del testo etc.).

Cluster Map

Nella Cluster Map sottostante si può vedere una collection di dati: i documents sono le sfere gialle e le emails quelle blu. Se questo cluster contenesse pagine web, sarebbero delle sfere verdi. Gli oggetti nel cluster contengono tutti il termine cercato biology.

Figura 2.20 – Esempio di cluster di biology

Dopo aver aggiunto un altro termine per la ricerca, taxonomy, la map mostra tre clusters. Il cluster nel mezzo raccoglie tutti gli oggetti che contengono entrambi i termini. Bisogna notare che la map contiene anche i due clusters di oggetti che contengono un solo termine. La dimensione dei clusters fornisce un feedback visuale del numero degli oggetti contenuti nel cluster.

Figura 2.21 – Esempio di clusters di biology e taxonomy Quando il numero degli oggetti supera 250, il cluster non mostra più i singoli oggetti ma un disco con all’interno il numero degli oggetto che contiene. Quando si clicca su un cluster, AutoFocus mostra gli oggetti contenuti in una lista.

- 40 -

Aggiungendo un terzo termine (visualization) i risultati sono raccolti in una map ancora più interessante. Il cluster nel mezzo è connesso a tutti e tre i termini cercati, ma la map mostra anche tutte le altre combinazioni di risposta. Aggiungendo altri termini nella search si avranno maps sempre più complesse; AutoFocus fornisce schemi di colori differenti che aiutano a capire la mappa.

Figura 2.22 – Esempio di cluster complesso

2.7 SWED

2.7.1 Introduzione SWED (Semantic Web Environment Directory) è un progetto dimostrativo di sistema web sostenibile e scalabile per la costruzione e gestione di portali informativi che utilizza due concetti fondamentali: il Web semantico e una classificazione a faccette. L’infrastruttura del portale semantico è stata sviluppata da Hewlett Packard Labs a Bristol e da ILRT (Institute for Learning and Research Technology) presso l’università di Bristol. Lo scopo è quello di creare una directory di organizzazioni che si occupano di ambiente all'interno del Regno Unito. Essenzialmente SWED fornisce una vista globale sui dati, forniti dalle singole organizzazioni effettuando un' "operazione di raccolta"; tra i diversi siti presenti sul Web. I vari membri delle organizzazioni quindi, possiedono, controllano e pubblicano le loro informazioni. Queste informazioni sono raccolte, confrontate e pubblicate sul portale. In questo modo, con una così grande ricchezza di informazioni ben indicizzate è molto più semplice, rispetto alle tradizionali directory, cercare e trovare informazioni rilevanti al nostro scopo. Oltre al prototipo di portale, il progetto comprende anche del software scaricabile gratuitamente che permette di creare il proprio portale personalizzato.

- 41 -

2.7.2 Demo (MokaByteSWP)

Figura 2.23 – Schermata di MokaByte SWP MokaByteSWP è il nuovo portale semantico della rivista “MokaByte”, ossia un "catalogatore di contenuti" che consente di eseguire una classificazione semantica dei dati immessi secondo regole e ontologie specificate in RDF e SKOS. Tramite un meccanismo di popolamento, il sistema aggrega varie informazioni specificate secondo il formalismo RDF su varie tipologie di documenti articoli del magazine, schede corso, commenti dei lettori, altri documenti generici) in modo da offrire una catalogazione con significato dei vari contenuti. � NON è un motore di ricerca sintattico, dove si inserisce una parola e il motore

fornisce tutte le possibili occorrenze nei vari documenti indicizzati. � È uno strumento di catalogazione � È uno strumento che effettua ricerche con approccio diverso. MokaByteSWP rappresenta quindi un sistema di navigazione dei contenuti che espone un approccio differente, guidato da concetti (faceted), non dalle parole. Il nodo centrale del portale semantico è la possibilità di inserire informazioni in RDF secondo classificazioni che rispecchiano determinate logiche le cui regole di base sono definite in apposite ontologie. MokaByteSWP è una dimostrazione di come sia possibile utilizzare sistemi semantici per catalogare contenuti - i più disparati - in modo da consentirne un uso efficace ed economicamente vantaggioso. Il portale in questo momento viene rilasciato in versione beta: anche se il motore è funzionante da un punto di vista operativo, al momento le ontologie di classificazione sono state inserite in una prima versione. L'utente può sfruttare la casella di testo per immettere una parola da cercare, utilizzando il sistema come un semplice motore di ricerca; oppure può ricercare qualche argomento all'interno di precisi gruppi di classificazione.

- 42 -

2.7.3 Tecnologia SWED funge da raccoglitore di risorse fisicamente collocate altrove: ciascuna organizzazione gestisce e pubblica i propri contenuti in modo autonomo nei propri siti ma, attraverso il Web semantico (file RDF e ontologie), i vari aggiornamenti vengono intercettati da SWED e riclassificati automaticamente in una logica unitaria. Il Web semantico fornisce il sostrato tecnico utile allo sviluppo di una classificazione a faccette che, a sua volta, permette una modalità di esplorazione delle risorse che fonde browsing e searching. Come si può notare nell’interfaccia di MokaByteSWP, in alto a sinistra si trova il motore di ricerca mentre il resto della pagina è occupato da rettangoli che fungono da “cancelli di ingresso” per il browsing (ricordando i quadrati colorati di Flamenco). Ogni riquadro è una faccetta che rappresenta un aspetto delle risorse nella directory, permettendo di accedervi secondo logiche di navigazione alternative. Per ogni faccetta del sistema vengono anticipati all’utente parte dei contenuti interni, contribuendo a rendere più esplicito il contenuto della faccetta stessa, insieme ad un numero tra parentesi che indica la somma di documenti archiviati sotto un particolare contenuto. Mediante il [+] posto a sinistra del nome della faccetta, si ha la possibilità di espanderne il box affinché sia possibile visualizzarne l’intero contenuto. In questo modo, l’esigenza di mostrare il contenuto di ciascuna faccetta non rischia di generare il problema opposto di sovraffollamento informativo che provocherebbe disorientamento nel navigatore.

2.7.4 Prerequisiti richiesti Il portale è implementato come una Java web application che richiede un Java servlet container environment che supporti una Java Servlet API 2.2. Il prototipo gira su tomcat 4.* and 5.* e funziona probabilmente anche su altri containers come Jetty. La documentazione è stata sviluppata con l’ipotesi che l’utente stia lavorando su tomcat versione 5.0.25.


- 43 -

Figura 2.24 e 2.25 – Architettura di SWED Il componente principale è il “portal viewer” che lavora come un’applicazione web in un Java servlet container e fornisce un’interfaccia web interface su un set di dati web semantici contenuti nel portale. L’implementazione corrente non è un generico web browser semantico e non dà accesso dinamico ai dati web semantici conservati fuori dal portale. Il secondo componente è un “aggregator” che periodicamente scannerizza una lista di sorgenti note (siti) e esegue l’upload di ogni dato RDF modificato nel database del portale cosicché possano essere visualizzati dall’utente. Mentre il diagramma a blocchi mostra un unico database, in realtà il portale estrae i dati da molteplici files caricati in memoria, oppure da un database opzionale. Tipicamente i templates del display sono file semplici (o locali o recuperabili via http URLs) e sono caricati e amministrati da un “template engine”. Le ontologie sono tipicamente file RDF locali (RDFS or OWL) e sono caricati in memoria. I dati sono solitamente tenuti in un database ma possono essere caricati in memoria da files statici nel caso di portali semplici Tutte le pagine dei display dei più importanti portali sono generate da templates. I creatori di SWED volevano fosse facile cambiarli per fornire un nuovo “look” e un nuovo supporto di navigazione senza dover scrivere codice java. Una particolare richiesta di design era la possibilità di scrivere templates per visualizzare dati RDF che potessero riusare i templates già inseriti. Per esempio, produrre templates per visualizzare il campo di indirizzo descritto usando diverse ontologie e poi, in un template visualizzare un organizzazione, semplicemente chiedendo di mostrarne l’indirizzo, lasciando decidere al sistema il suo tipo e il template relativo da usare.

- 44 -

Per fornire queste caratteristiche si è scelto di usare il motore template di “Jakarata Velocity” che offre un semplice e compatto linguaggio di scripting adatto al compito di generare le pagine del portale. Inoltre, il portale supporta la ricerca testuale attraverso l’inserimento di un’istanza del motore di Lucene.

2.8 Tabella riassuntiva

OPEN

SOURCE FUNZIONALITA'

PREREQUISITI RICHIESTI

open source licenza BSD

motore di ricerca e directory organizzati con il criterio delle

faccette

Pc su cui è installato Linux o Mac OS X con web server che supporta CGI scripts e Python

(2.3 o superiore)

open source licenza BSD

web browser RDF a faccette scritto come un’applicazione

web java

Java Virtual Machine (1.4 o superiore) e Apache Maven

2.0

A pagamento

motore di ricerca e visualizzatore di dati

sviluppato in maniera specifica per le biblioteche

_

open source

servizio di interfaccia che include un modello di

interazione e un software framework per accedere ed esplorare le informazioni

Pc su cui è installato Linux o Mac OS X

open source con

licenza OSL e ACL

software di Desktop Search qualsiasi tipo di piattaforma con una Java virtual machine

open

source

progetto dimostrativo di sistema web sostenibile e

scalabile per la costruzione e gestione di portali informativi

richiede un Java servlet container environment che

supporti Java Servlet API 2.2. Il prototipo gira su tomcat 4.*

e 5.*.

- 45 -

INTERFACCIA UTENTE OUTPUT search testuale DATI IN

INGRESSO

la directory di link si presenta graficamente simile a quella di

Yahoo o Google dando l’impressione che ogni riquadro colorato sia l’insieme di oggetti

diversi e non una faccetta

quando si opera una ricerca diretta si appoggia al sistema di

classificazione a faccette per estrarre i risultati

collection + metadati in “tab-delimited” files

(TSV files, estensione ".tsv")

L'interfaccia, priva di colori, risulta dispersiva e rende difficoltoso capire come

interpretare e navigare i dati.

restrizione “free-text” che riduce il dataset a tutti gli oggetti che contengono la

stringa cercata nei valori delle loro proprietà.

dati RDF

presenta tre differenti funzioni di recupero e presentazione delle informazioni: search (ricerca testuale), discover (galassia di termini relazionati al termine ricercato), refine (ricerca a

faccette).

consente agli utenti di cercare informazioni sul proprio

catalogo e presenta i risultati in una lista, personalizzabile,

ordinata per rilevanza rispetto alla query.

“data adapters” per trasformare informazioni,

strutturate e non, in formato Medialab

consente di organizzare qualunque tipo di dati in un

browser simile, graficamente, ad iTunes, associarci delle

informazioni ed esplorarli nel modo che l’utente preferisce.

Elenco delle risorse che contengono la parola cercata

può essere applicato

potenzialmente a qualunque area

informativa

presenta i risultati della search usando le faccette e Cluster

Maps (per mostrare la sovrapposizione tra le queries). La ricerca è più efficiente grazie

ai termini suggeriti.

visualizzazione con la Cluster Map + visualizzazione testuale in elenco dei documenti reperiti con informazioni supplementari

lunga e in continua crescita (MS Office, Open Office, txt, html,

pdf, xml)

motore di ricerca + rettangoli che fungono da “cancelli di ingresso”

per il browsing (ricordando i quadrati colorati di Flamenco)

quando si opera una ricerca testuale si appoggia al sistema di classificazione a faccette per

estrarre i risultati oltre a visualizzarne l'elenco

data source + ontologie + templates

Progetto link delle demo analizzate

Flamenco Nobel prize winners - http://orange.sims.berkeley.edu/cgi-bin/flamenco.cgi/nobel/Flamenco

Longwell MIT Libraries - http://simile.mit.edu/longwell/demo/libraries/

AquaBrowser Queens Library - http://aqua.queenslibrary.org/

mSpace mSpace beta (classical music explorer) - http://beta.mspace.fm/

Autofocus Aduna Spectacle - http://www.aduna-software.com/aduna-spectacle

Swed Mokabyte semantic portal - http://www.mokabyte-swp.it/SemanticPortal/

- 46 -

- 47 -

Capitolo 3 - Il progetto Intellifacet Dimostratore di un portale semantico

3.1 Introduzione

Capitale intellettuale e risorse web determinano ogni giorno una costante crescita dei dati aziendali e ciò, spesso, invece di trasformarsi in un’opportunità di sviluppo, finisce paradossalmente per diventare un ostacolo alle attività dell’azienda Oltre l’80% delle informazioni su cui le aziende basano il proprio business è generalmente in forma testuale, quindi la gestione di tutti questi dati (atti di convegni, bilanci, report, ricerche, comunicati stampa,...), archiviati in posti e formati diversi (doc, ppt, pdf, html, xls, txt,…) è molto complessa. Il prototipo Intellifacet è stato realizzato per dimostrare la possibilità e l'efficacia di acquisire informazioni da fonti strutturate e non strutturate e presentarli all'utente in forma semplice e facilmente consultabile. I risultati vengono infatti raggruppati per categorie e visualizzati con il sistema “a faccette”, che permette di raffinare la ricerca secondo la direzione voluta, avendo, al contempo, una visione d'insieme delle informazioni disponibili. Il lavoro è stato svolto su due fronti : • l'estrazione automatica di dati e metadati da documenti per dare struttura

all'informazione non strutturata • la pubblicazione sul web con interfaccia a faccette In questo modo si sono dimostrate le funzionalità della ricerca semantica sia in fase di classificazione automatica, sia in fase di navigazione tra i risultati.

3.2 Tipologie di informazione

Esistono almeno 3 tipi di dati presenti tipicamente in una intranet per cui la semantica può essere esplicitata: dati non strutturati, dati strutturati o semi-strutturati, dati semantici.

- 48 -

• dati strutturati: riguardano informazioni ripetitive e presentate in un formato

strutturato. Sono file, tabelle, database, data warehouse, etc. Questo tipo di dati è facilmente memorizzabile ed accessibile da programmi software comuni.

• dati non strutturati: documenti, immagini, grafici, filmati, audio, … In questo caso la semantica deve essere esplicitata, questi dati devono essere trasformati in dati strutturati(database, xml) oppure semantici, nel caso di rdf.

• dati semantici Poiché di dati già semantici ce ne sono ancora pochi nelle aziende abbiamo pensato di concentrarci sui metodi per trasformare i dati non strutturati o strutturati in rdf.

3.3 Fasi di realizzazione

3.3.1 Utilizzo di H-DOSE H-DOSE (Holistic Distributed Open Semantic Elaboration platform) è il motore di ricerca, document indexer and retriever semantico, sviluppato dal gruppo di ricerca e-lite del Politecnico di Torino. Come tutti gli indexer/retriever H-DOSE prevede due fasi: una fase di indicizzazione, in cui ad ogni documento viene associata una rappresentazione compressa, e una fase di ricerca, in cui si individuano i documenti le cui rappresentazioni compresse sono più vicini alla rappresentazione compressa della richiesta effettuata dall’utente. La rappresentazione compressa dipende dai concetti del testo e si esprime sotto forma di un insieme di annotazioni automatiche, che associano i concetti individuati nel documento con quelli effettivamente rilevanti per l’applicazione, rappresentati in modo formale tramite ontologie.

Figura 3.1 – Fase di indicizzazione di H-dose Tra gli elementi qualificanti di H-DOSE si sottolinea che le annotazioni semantiche dei documenti sono state condensate in un tipo di rappresentazione molto efficiente, sia dal punto di vista dei requisiti elaborativi che dal punto di vista dei requisiti di memoria, denominata spettro concettuale. La rappresentazione grafica dello spettro concettuale di un documento riporta sulle ascisse i concetti rilevanti per

- 49 -

l’applicazione, ordinati in modo opportuno, e sulle ordinate la rilevanza dei concetti nel documento stesso. H-DOSE, essendo un I/R semantico, permette, tra le varie funzionalità, l’individuazione di un maggior numero di documenti pertinenti alla richiesta effettuata, l’ordinamento più appropriato dei documenti individuati in base alla richiesta, l’annotazione automatica di documenti, il supporto all’accesso differenziato di documenti per classi di interesse, ottenuto differenziando le ontologie utilizzate dalle differenti categorie di utilizzatori. Oltretutto H-DOSE garantisce: • Efficienza computazionale, dovuta alla particolare rappresentazione delle

annotazioni sotto forma compressa di spettri concettuali. • Facilità di integrazione con qualunque tipo di applicazione di terze parti

(portale, CMS,CRM etc.), conseguenza dell’assenza di vincoli hardware o software: le funzionalità offerte, infatti, sono accessibili tramite web services.

• Indipendenza dall’ambiente di sviluppo delle conoscenze: l’utilizzo di formati standard per la codifica delle ontologie (OWL) consente una piena libertà nella scelta.

Ovviamente bisogna integrare H-DOSE in un’applicazione sviluppando un progetto che aggiunga i seguenti elementi: • la selezione e/o lo sviluppo, l’adattamento, la validazione e il mantenimento delle

ontologie. • la progettazione e lo sviluppo di un’interfaccia utente efficace. • lo sviluppo dell’interfaccia con l’applicazione e con il sistema operativo

dell’utente. Al fine di ottenere una navigazione semantica a faccette per esplicitare le associazioni semantiche e permettere all'utente di navigare semanticamente i risultati della query Intellifacet utilizza un'estensione di H-DOSE a livello di indexing che associa un dato documento ad un concetto dell'ontologia di riferimento. In questo modo sul client verrà visualizzata una faccetta con i concetti dell'ontologia e il numero di documenti che li popolano.

3.3.2 Lato server Si è deciso di utilizzare JAVA come linguaggio di programmazione, tomcat come application/web server e postgres come database (supportato da H-DOSE).

3.3.3 Ontologia Per sfruttare le potenzialità delle soluzioni semantiche bisogna sviluppare ontologie adeguate per l’applicazione. Per Intellifacet si è deciso di utilizzare una semplice ontologia relativa alla semantica in owl creata integrando una tassonomia sui semantic topics usata dai progetti europei “Knowledge web” e “Reverse”.

- 50 -

La tassonomia è disponibile come estensione OWL dell'ontologia SWRC sulle pubblicazioni disponibile all'indirizzo http://ontoware.org/projects/swrc/. Abbiamo utilizzato le istanze, relative ai documenti semantici, dell’ontologia generale sulle pubblicazioni come classi della tassonomia relativa al progetto Intellifacet.

La tassonomia utilizzata è: 1)Basic Web Information Technologies 1.1)Architecture of Web Information Systems 1.2)Web Data Extraction / Information Extraction 1.3)Personalization Techniques 1.4)Rdf (Resource Description Framework / RDFSchema) 1.5)Security 1.6)Web Data Integration 1.7)Web Services 1.8)XML 2)Ontologies 2.1)Ontology Engineering 2.2)Ontology Languages (Ontology Representation / Ontology Languages / OWL) 2.3)Ontology Reasoners 3)Semantic Web Applications 3.1)Bioinformatics 3.2)E-Business 3.3)E-Government 3.4)E-Health 3.5)E-Learning 3.6)Engineering 3.7)Knowledge Management 3.8)Law 3.9)Multimedia 4)Semantic Web Special Topics 4.1)Agents and Semantic Web 4.2)Benchmarking and Scalability 4.3)Design and Testbed Case Studies 4.4)Natural Language Processing / Human Language Technologies 4.5)Peer-to-Peer and Semantic Web 4.6)Semantic Grid 4.7)Semantic Web Services 4.8)Social Impact of the Semantic Web 4.9)Social Networks and Semantic Web Per la tassonomia è stato necessario, poi, creare un file di synset che specificasse i termini, in italiano e in inglese, da associare ad ogni concetto. La class java “lang” è stata usata per distinguere le lingue sui documenti formato plain text, usando l’analisi sulle preposizioni, in modo da distinguere automaticamente tra documenti italiani e inglesi.

3.3.4 Indicizzazione Intellifacet indicizza circa 200 documenti, in formato doc e pdf, relativi alla semantica raccolti all'interno di Intellisemantic nei suoi anni di ricerca.

- 51 -

E' stato necessario individuare dei tools che permettessero di estrarre, in automatico, il testo da file pdf e word e convertirlo nel formato txt con cui lavora H-DOSE. A questo proposito si sono individuate queste tecnologie: • Estrazione testo da pdf: questo compito può essere agevolmente svolto con

un'utility contenuta in Xpdf: pdftotext converte file dal formato PDF (Portable Document Format / Adobe Acrobat) in testo puro. Il comando pdfinfo consente di conoscere le informazioni disponibili su di un file pdf.

• Estrazione testo da documenti word: Jakarta POI - Java API To Access Microsoft Format Files (funziona anche per i ppt, excel etc).

3.3.5 Interfaccia di navigazione L'interfaccia di navigazione lato client è stata realizzata sfruttando l’architettura a faccette. Gli elementi delle faccette devono interagire con le informazioni estratte da H-DOSE, Xpdf e Jakarta POI. L'interfaccia a faccette permette di esplicitare anche verso l'utente finale le associazioni semantiche che vengono create sul server, per facilitare la navigazione e anche per restringere “semanticamente” i risultati di una query . Nell'ambito del progetto Simile è stato sviluppato Exhibit , un framework per gestire totalmente lato client le informazioni strutturate su più dimensioni, scrivendo solo pagine HTML e, opzionalmente, pagine CSS e codice Javascript. SIMILE Exhibit ha notevoli vantaggi: • tutte le informazioni sono gestite lato client senza la necessità di database o

server; • i dati e la loro presentazione sono divisi; • i medesimi dati posso essere visualizzati contestualmente con visuali

significative, tipo mappe o timeline; • facilita la creazione di mashup di dati Ai fini della demo (e fino circa 500 documenti che è il limite attuale per la scalabilità gestendo l'informazione lato client) il framework Exhibit è assolutamente sufficiente, senza dover sviluppare interamente un'interfaccia ajax all’interno dell’azienda. E' open-source con licenza bsd (si possono fare tutte le elaborazioni purchè si citino i credits). Exhibit lavora gestendo le faccette interamente lato client, quindi da questo punto di vista è molto veloce. I dati gli vengono passati dal server sotto forma di file JSON. Il nostro lavoro è quello di fornire al client un file JSON composto da: 1)l'associazione tra concetti dell'ontologia e documenti collegati (la semantica che è perfettamente in grado di fornire H-DOSE); 2)tutte le faccette che è opportuno inserire nella demo.

- 52 -

3.3.6 Ricerca testuale La ricerca testuale in Intellifacet è fornita da Lucene, la famosa libreria che permette di avere in Java un motore di ricerca per diverse tipologie di file. E' un progetto opensource della Apache Software Foundation che fornisce una libreria estremamente flessibile che ci permette di inserire nelle applicazioni le funzionalità di motore di ricerca. Una base di dati testuale Lucene viene chiamata indice ed è normalmente contenuto in una cartella del filesystem, ma esistono altre possibilità, quali la creazione di un indice in RAM, utilizzato soprattutto per aumentare le prestazioni. All'interno dell'indice vengono inseriti documenti (istanze), a loro volta divisi in campi o colonne (fields). I campi testuali veri e propri (come il titolo ed il corpo di un documento) verranno indicizzati , mentre altri campi, ad esempio l'identificatore del documento all'interno di un database, saranno solo salvati, per essere utilizzati come riferimento. In pratica non sarà possibile eseguire ricerche in questi campi, ma solo accedere al loro valore, nei documenti ritornati da una query eseguita su un altro campo. L'inserimento di un documento all'interno dell'indice comporta una scansione del testo per individuare le parole presenti; tale procedimento prende il nome di analisi ed ovviamente è dipendente dalla lingua del testo. Una volta che il documento, o meglio, i suoi campi sono stati indicizzati questi sono disponibili per l'esecuzione di ricerche. E' possibile eseguire ricerche sull'indice in due modalità distinte: utilizzando direttamente le API di ricerca oppure utilizzando una sorta di linguaggio di interrogazione.

3.4 Architettura SW

Figura 3.2 – Architettura SW di Intellifacet

- 53 -

• L’utente sceglie le directories da analizzare; per questa demo abbiamo utilizzato

documenti relativi alla semantica. • I files vengono trasformati in formato txt e indicizzati, e viene estratto un primo

set di metadati. In questa fase si estraggono: title, author, publication date, language and extension.

• Vengono estratti i topics relativi all’ontologia che si è deciso di caricare insieme ai documenti.

• Viene generata automaticamente l’interfaccia web, mettendo insieme tutte le informazioni e i metadati grazie al tool SIMILE Exhibit.

• L’utente può navigare la pagina web usando sia la ricerca a faccette che la ricerca testuale fornita Apache Lucene.

Figura 3.3 – Interfaccia di Intellifacet

- 54 -

Figura 3.4 – Tipi di sort dei risultati di Intellifacet

3.5 Possibili miglioramenti

• L’acquisizione di informazioni strutturate deve essere più agevole e l’analisi di

dati strutturati deve essere possibile per un maggior numero di formati: database, xml, excel, RSS, ecc...

• E’ necessario creare un'interfaccia di back-end per gestire la raccolta e la

selezione delle fonti delle informazioni da analizzare. • E’ necessario creare un'interfaccia di back-end per la gestione delle informazioni

da pubblicare/annotare. In particolare deve rendere possibile la selezione delle faccette, delle voci al loro interno e delle informazioni visualizzate per ogni item trovato, e la possibilità di annotare oppure modificare le informazioni raccolte sui documenti indicizzati.

• E’ necessario creare un'interfaccia di lato utente a faccette perchè Exhibit

funziona bene solo fino a 500 documenti.

3.6 Backoffice

Successivamente alla presentazione del dimostratore Intellifacet, si è iniziato a lavorare al suo backoffice. Le funzionalità necessarie sono: 1)Fase di indexing (crawling e topics extraction):

• Inserire la directory da analizzare • Gestire le sottodirectories • Implementare nel codice la gestione della lingua in automatico • Gestire le ontologie e i relativi file di synset.

- 55 -

Figura 3.5 – Scelta della directory da indicizzare con le relativa ontologia

Figura 3.6 – Lista dei documenti indicizzati 2)Lucene indexing

- 56 -

• L'indexing con Lucene deve poter essere effettuato ogni volta che si indicizzano nuovi documenti

3)Json editing • L'utente deve poter editare alcuni campi del json, in particolare: Titolo,

Autore e Data.

Figura 3.7 – Interfaccia per la modifica dei metadati di un documento

- 57 -

Conclusioni In questa monografia ho voluto mostrare come, per poter trasformare l’informazione in conoscenza, è necessario un accesso flessibile e multi-dimensionale all’informazione stessa. Il contesto aziendale ma anche, più semplicemente, siti, intranet e data-repository di qualsiasi genere, presentano una grande quantità di dati caratterizzati da continui e rapidi mutamenti. E’ necessario, quindi, prevedere sistemi di classificazione e di accesso all’informazione aperti, flessibili e adattativi in modo da soddisfare una pluralità di approcci ai dati differenti. In un simile scenario ha acquistato un grande valore la “classificazione a faccette” che contrappone un sistemi di classi (faccette) orizzontale ed aperto (ciascuna faccetta è descrittiva di una proprietà) alla verticalità e rigidità dei sistemi di catalogazione tradizionali che presentano un’eccessiva ramificazione in profondità delle gerarchie. Applicare tale procedimento di classificazione per organizzare i contenuti di un sito web può produrre vantaggi sia da un punto di vista “interno” di indicizzazione e manutenzione del sito stesso (il sistema è aperto, facilmente scalabile, flessibile e adeguato nei casi in cui sia utile indicizzare uno stesso item sotto più classi), sia rispetto all’esperienza dell’utente del sito (possibilità di accessi multipli a seconda dei diversi bisogni, schema coerente, intuitivo, autoesplicativo e soluzione immediata delle esigenze più popolari). Ovviamente, per parlare di classificazione adatta all’organizzazione della conoscenza, è necessario che il sistema preveda una forma di indicizzazione semantica (ossia relativa al contenuto o al soggetto) di ciò che si intende classificare. La classificazione a faccette, nella sua formulazione originaria di Ranganathan, non si limita semplicemente a teorizzare un accesso pluridimensionale agli oggetti di una collezione ma, a questo, associa poi altri aspetti, meno conosciuti ma ugualmente importanti, come l’ordine di citazione delle faccette e un sistema di notazione utile a garantire tale ordine. Negli ambienti legati al web è oggi in atto la tendenza a definire come “faceted” o “a faccette” un qualsiasi sistema adotti una logica simile a quella della classificazione a faccette, pur non condividendo in pieno tutte le caratteristiche della teoria originaria. La maggioranza delle applicazioni presenti nel web, comprese quelle analizzate nel capitolo 2, utilizza, infatti, la classificazione a faccette in una forma spuria, cioè rifacendosi esclusivamente alla sua logica pluridimensionale di accesso all’informazione. Minor interesse sembra invece dedicato agli schemi generali di Ranganathan in base ai quali scegliere le faccette principali del sistema e il loro ordine, quindi al sistema di notazione e all’ordine di citazione. Se sia conveniente o meno introdurre un nuovo tipo di organizzazione dei contenuti web tramite la logica delle faccette è un interrogativo a cui non si è ancora data una valida risposta e la discussione e la sperimentazione sono ancora in corso. Come dimostrato nel capitolo 2, si stanno sviluppando molti sistemi funzionanti, facilmente integrabili ed innovativi, che utilizzano la classificazione a faccette e che cominciano ad essere in grado di interagire con l’utente in modo proficuo e intuitivo.

- 58 -

Bisogna considerare che, ancora oggi, una gran parte dei siti web impiega la struttura gerarchica per organizzare i propri contenuti e che, quindi, il sistema tende a essere sempre riconoscibile producendo una certa familiarità negli utenti. Da un lato c’è il riconoscimento dei limiti strutturali delle classificazioni gerarchico-enumerative e della loro scarsa vicinanza ai modelli cognitivi propri della mente umana e, dall’altro, la consapevolezza dell’importanza delle convenzioni e degli standard e del fatto che le gerarchie rappresentano ancora un modo familiare e funzionale per organizzare l’informazione.

- 59 -

Bibliografia e siti consultati � Classificazione a faccette:

� “Organizzare la conoscenza : dalle biblioteche all'architettura dell'informazione per il Web” Claudio Gnoli, Vittorio Marino, Luca Rosati - Hops-Tecniche nuove : Milano : 2006

� “Le faccette in architettura dell'informazione” Luca Rosati = Le

dimensioni dell'informazione : giornata di studio AIB Piemonte-ISKO Italia, 2005.

http://www.iskoi.org/doc/dimensioni3.htm � “Classificazione a faccette”, Claudio Gnoli - AIB : Roma : 2004 � “The Use of Faceted Analytico-Synthetic Theory as Revealed in the

Practice of Website Construction and Design” Kathryn La Barre : 2006 � “Classificazioni per il Web. I vantaggi dell'adozione di schemi a

faccette”, Vittorio Marino : 2004 � Flamenco:

� http://flamenco.berkeley.edu/ , sito web di Flamenco

� “Flamenco Image Browser:Using Metadata to Improve Image Search During Architectural Design” Ame Elliott

� “Semi-Automated Creation of Facet Hierarchies” Marti Hearst

� MIT Longwell:

� http://simile.mit.edu/wiki/Longwell , sito web di Longwell � AquaBrowser Library:

� http://www.medialab.nl/ , sito web di AquaBrowser � “AquaBrowser Library, The White Paper”, Jasper Kaizer e Anthony

Hodge � mSpace:

� http://www.mspace.fm/ , sito web di mSpace � Aduna Autofocus:

� http://www.aduna-software.com/products/autofocus/ , sito web di Autofocus

- 60 -

� http://www.openrdf.org/ , sito web di Sesame

� http://lucene.apache.org/, sito web di Lucene

� http://aperture.sourceforge.net/, sito web di Aperture

� “Performance Analysis and Optimization on Lucene”, David ChiChuan

Su, Stanford University

� “Ontology-based Information Visualization: Towards Semantic Web Applications”, Christiaan Fluit, Marta Sabou and Frank van Harmelen

� SWED:

� http://www.mokabyte-swp.it/SemanticPortal , sito web di MokaByteSWP � http://www.swed.org.uk/ , sito web di SWED

� Intellifacet:

� http://intellisemantic.myvnc.com:8080/IntelliFacet/index.jsp , Semantic Enterprise search

� http://www.intellisemantic.com/ , sito web di Intellisemantic srl

� “Le applicazioni semantiche e il motore di ricerca H-DOSE” , Alberto

Ciaramella

� “H-DOSE: an Holistic Distributed Open Semantic Elaboration Platform” , Dario Bonino, Alessio Bosca, Fulvio Corno, Laura Farinetti, Federico Pescarmona

� http://dose.sourceforge.net/ , sito web di H-DOSE

� “Exhibit: Lightweight Structured Data Publishing” , David F. Huynh,

David R. Karger, Robert C. Miller

� http://simile.mit.edu/exhibit/ , sito web di Exhibit

� “Performance Analysis and Optimization on Lucene””””. David Chi-Chuan Su

� http://lucene.apache.org/java/docs/, sito web della documentazione di Lucene