Skip to topic | Skip to bottom
Home

Tesi
Tesi.TestoDellaTesir1.4 - 14 Sep 2004 - 20:23 - ManuelBartolitopic end

Start of topic | Skip to actions
-- ManuelBartoli - 24 May 2004

CAPITOLO 1

INTRODUZIONE

Il World Wide Web contiene un’enorme quantità di documenti e d’informazioni ed il loro numero cresce rapidamente. Non ci allontaneremmo troppo dalla realtà affermando che è possibile trovare in rete praticamente tutte le informazioni di cui si è alla ricerca. Questo fa di Internet la maggiore risorsa informativa a cui si può attingere. Nonostante le enormi potenzialità offerte, però, il modello su cui si basa presenta alcune carenze e, sotto alcuni aspetti, rappresenta addirittura un passo indietro rispetto ai primi approcci fatti in questo campo, tanto che potrebbe risultare insufficiente ad un utente non occasionale. Chi accede alla rete, infatti, ha spesso la necessità di effettuare ricerche molto più raffinate di quelle che sono attualmente possibili attraverso i motori di ricerca. Potrebbe essere interessato non solo al dato in se stesso, ma ad un dato con determinate caratteristiche semantiche, le quali sarebbero visibili solo una volta giunti in possesso del dato stesso. Sempre più frequentemente, inoltre, si ha la necessità di trattare i dati in maniera automatizzata, di acquisirli attraverso applicazioni, di poterli riutilizzare in contesti diversi da quelli per cui l’autore li ha creati. Un’altra lacuna che affligge il World Wide Web così come è oggi è strettamente legata ai browser web, che non permettono di editare il contenuto dei documenti, rendendo di fatto il Web semplicemente un mezzo per pubblicare informazioni ad un pubblico vasto, quando invece era stato ideato come un potente mezzo per l’apprendimento a livello personale, uno strumento per facilitare il lavoro collaborativo, un sistema per condividere il proprio sapere al fine di sviluppare una “intelligenza collettiva”. In questo panorama si colloca il progetto Annotea[1] del W3C[2]. Annotea si pone come obiettivo quello di estendere i protocolli già esistenti e attualmente utilizzati dal World Wide Web per poter mettere a disposizione dell’utente della rete un’architettura client/server tale per cui egli sia in grado di produrre annotazioni su pagine web, possibilità in questo momento preclusa a chi utilizza strumenti “classici” o non abbia i diritti di modifica sul documento stesso. Scopo di questa tesi sarà, dopo aver introdotto brevemente il concetto di web semantico e collaborativo, quello di presentare il progetto Annotea evidenziandone il ruolo di primaria importanza all’interno di questo contesto. I capitoli successivi sono organizzati nel modo seguente: Nel capitolo 2 verrà descritto il contesto tecnico, sociale e politico in cui è nato e si sta sviluppando Annotea ed il suo evolversi negli anni. Nel capitolo 3 verranno illustrate le parti di cui si compone la sua architettura e i software che le implementano, scendendo in dettaglio sulla demo da me sviluppata. Nel capitolo 4 verranno sviscerati i dettagli implementativi e tecnici relativi ai componenti di Annotea e alla realizzazione della demo. Verranno analizzate inoltre le scelte effettuate. Nel capitolo 5, infine, metteremo brevemente a confronto Annotea con altri progetti che si muovono nello stesso contesto analizzandone le differenze ed i punti in comune. Verranno inoltre tratte le conclusioni relative al lavoro svolto e verranno presentati gli sviluppi futuri del progetto Annotea.

CAPITOLO 2

ANNOTAZIONI E COLLABORAZIONI

Per comprendere con esattezza i motivi che hanno portato alla nascita del progetto Annotea, bisognerà per prima cosa tracciare un profilo del contesto storico, tecnico e sociale in cui tale progetto si muove. Questa chiarificazione sarà utile per determinare che cosa si intende quando si parla di collaborazioni e annotazioni su pagine web, e del perché si è sentita la necessità di creare degli strumenti per la loro implementazione

2.1 Il World Wide Web

Il World Wide Web (che da questo momento indicheremo, per comodità, soltanto con la sigla WWW) come lo conosciamo oggi è essenzialmente un sistema multimediale, ipertestuale e globalmente distribuito. E’ multimediale perché i documenti che lo compongono, nella loro totalità, sono di natura mediatica eterogenea. Oltre al semplice testo ci troviamo di fronte ad immagini, documenti grafici, filmati e suoni, spesso usati contemporaneamente all’interno dello stesso documento il quale, per questo motivo, viene detto “documento multimediale”. E’ ipertestuale perché permette una consultazione non lineare dei documenti. Possiamo, infatti, oltre che scegliere l’ordine di lettura delle diverse pagine che ci interessano, anche seguire un “link” per noi significativo ma che spezza la sequenzialità del testo che stiamo leggendo. Il concetto di ipertesto deriva dal concetto geometrico di iperspazio, termine a sua volta ottenuto contraendo il termine di “spazio iperbolico”. La struttura interna di un testo è unidimensionale, l’ipertesto invece ha una struttura multidimensionale in quanto composto da più di un testo. Ogni combinazione possibile dell’ordine di lettura crea un nuovo testo. E’ globalmente distribuito perché i documenti a cui si ha accesso non risiedono né su di un solo file, né su di un solo file system, né su di una rete locale composta da qualche macchina, ma sono immagazzinati su milioni di macchine localizzate sulla quasi totalità della superficie terrestre, a grandissima distanza le une dalle altre ma raggiungibili e richiamabili pressoché istantaneamente avendo a disposizione gli strumenti hardware e software necessari. Il motivo iniziale per cui fu inventato questo “sistema multimediale, ipertestuale e globalmente distribuito” è stato la necessità di un miglior scambio di informazioni tra i ricercatori del CERN dove, nel 1990, si trovava a lavorare Tim Berners-Lee, universalmente riconosciuto come l’inventore del WWW[3], il quale si fece carico dello sviluppo di questo sistema. Dopo appena 14 anni questo mezzo nato per esigenze pratiche all’interno di un centro di ricerca, è la più grande risorsa di informazioni in nostro possesso. Questa enorme quantità di documenti e informazioni ha portato evidenti vantaggi alla comunità dato che questi dati sono di facile e veloce reperibilità e ad un costo contenuto. Accanto a questi aspetti positivi però ne troviamo anche alcuni negativi dovuti alle scelte implementative che sono stati compiute per realizzare il WWW, due di questi aspetti li andremo di seguito ad esaminare nello specifico.

2.2 Il web semantico

Il primo, e forse più evidente, difetto è la mancanza di organizzazione, di una struttura ben definita che permetta di catalogare e suddividere i documenti ed i dati in essi contenuti secondo delle aree di interesse precise e caratterizzate. Inoltre sta diventando una priorità per molti avere a disposizione delle macchine che comprendano in maniera automatica i dati provenienti dalla rete. Il web potrebbe fare un grande passo in avanti se diventasse un luogo dove i dati possono essere condivisi ed elaborati da strumenti automatizzati e permettere così alle persone di trarne beneficio. Attualmente una pagina web fornisce come unici dati quelli che possono essere usati dalle macchine allo scopo di visualizzazione o comunque di riproduzione. E’ chiaro che questi non sono sufficienti se quello che cerchiamo è l’automazione, l’integrazione e il riuso dei dati attraverso varie applicazioni. Il web semantico, pur essendo ancora soltanto un’idea, si pone proprio l’obiettivo di andare a colmare questa lacuna. Il suo successo dipende in maniera cruciale dalla facile creazione, interazione e uso dei dati semantici. “Il web semantico è un’estensione del web attuale, in cui alle informazione vengono dati un senso, un significato ben definito, migliorando in questo modo la cooperazione tra i computer e le persone”[4]. Una delle sfide del web semantico è la creazione di metadata con la collaborazione di utenti web, cioè combinando il contenuto semantico creato da un grande numero di persone. Un metadata è un dato che fornisce informazioni su altri dati. Le due tecnologie fondamentale per lo sviluppo del web semantico sono senza dubbio XML (eXtensible Markup Language)[5] e RDF (Resource Description Framework) [6]. XML è un metalinguaggio, è cioè un linguaggio che permette agli utenti di creare il proprio linguaggio, attraverso la definizione dei propri tag e di aggiungere delle strutture arbitrarie ai propri documenti. Tali strutture per essere comprese e riutilizzate da altri utenti, siano essi persone o computer, dovranno essere dichiarate su di un documento apposito chiamato DTD che può essere sia contenuto nel documento principale che fornito a parte. Un metalinguaggio da solo però non sarebbe sufficiente per lo scopo che ci siamo prefissi, XML infatti non dice nulla circa il significato delle strutture che definisce. Per questo motivo il significato è espresso dal linguaggio RDF che attraverso una serie di triple esprime un soggetto, un verbo ed un oggetto di una frase elementare. Queste triple sono scritte utilizzando tag XML.

2.3 Il web collaborativo

L’altro aspetto che andremo ad analizzare è la totale scomparsa del concetto di collaborazione nell’ambito della creazione di documenti web. Quando dal nostro browser richiamiamo una pagina, l’unica azione che possiamo compiere su di essa è visualizzarla. Al massimo possiamo compilare un form con dei dati da inviare al server. Qualsiasi altra operazione sul documento ci è praticamente preclusa. L’unico modo che abbiamo per manipolare i documenti è quello di avere accesso sul server dove essi risiedono e, inoltre, vantare diritti di modifica sui file che ci interessano. Come abbiamo già detto il WWW non era stato pensato assolutamente in questi termini. Anzi l’idea iniziale era diametralmente opposta. Il web è nato come uno strumento di condivisione di informazioni e di creazione collaborativa delle stesse. D’altronde, però, questa situazione sembra decisamente difficile da aggirare. Se infatti da un lato un ristretto gruppo di collaboratori non avrebbe nessun problema a permettere ad ognuno dei suoi componenti in libero accesso in modifica ai dati e ai documenti da loro prodotti, dall’altra sembra altrettanto logico che lo stesso gruppo sia molto reticente a concedere lo stesso privilegio a chiunque disponga di un browser. Un altro scenario in cui ci si andrebbe ad imbattere sarebbe quello del diritto d’autore. Se una pagina web contenesse la “Divina Commedia” di Dante, piuttosto che la trascrizione del “Discorso alla Nazione” di un capo di stato, potremmo ancora attribuire, e sarebbe legittimo farlo, il contenuto di tali pagine agli autori originali dopo un’arbitraria modifica effettuata da un ignoto navigatore? E se ciò fosse possibile, quanti autori darebbero il permesso di pubblicare le proprie opere sulla rete? Queste domande, chiaramente, non sono di facile ed immediata risposta, nonostante questo però la possibilità di creare contenuti in maniera collaborativa è un’esigenza sentita fortemente dalla comunità di internet.

2.4 Il progetto Annotea

Alla luce di queste considerazioni nel 1995 il W3C da vita al progetto Annotea. Il W3C (World Wide Web Committee) è l’organizzazione fondata nel 1994 e presieduta proprio da Tim Berners-Lee il cui fine è sviluppare protocolli comuni per migliorare l’interoperabilità tra i sistemi in rete e per guidare l’evoluzione del WWW. Il progetto Annotea, che attualmente fa parte sia del gruppo di progetti LEAD (Live Early Adoption and Demostration)che di quelli SWAD (Semantic Web Advanced Development), inizialmente basava il suo sviluppo su due gruppi di lavoro nati per “identificare estensioni alle tecnologie web” che “facilitassero la collaborazione asincrona su vasta area”, il primo si occupava delle collaborazioni ed il secondo delle annotazioni. Il motivo per la creazione di due gruppi anziché uno è da ricercarsi nella differenza concettuale che al tempo distingueva i due argomenti. Con il termine collaborazione si intendeva la creazione “collaborativa e asincrona” di un documento da parte di chiunque abbia accesso alla rete. Con annotazioni s’intendevano delle note, degli appunti, che un utente associava ad un documento, piuttosto che ad una sua parte, ma non poteva metterle a disposizione degli altri, salvandole localmente sulla propria macchina o postazione di lavoro, come fosse la nota a margine di un libro. Ben presto, comunque, i nuovi scenari che l’evolversi del progetto hanno messo in evidenza hanno sempre maggiormente avvicinato i due rami di sviluppo fino a far confluire i due gruppi in uno solo. Le annotazioni si sono raffinate, passando da brevi parti di testo a documenti complessi a loro volta, sono state aggiunte alcune caratteristiche, come la possibilità di replicare ad un’annotazione già esistente. Soprattutto, però, si è sentita la necessità di poter condividere le annotazioni create e di avere accesso a quelle create da altri facendo sostanzialmente coincidere le problematiche di questo gruppo con quello delle collaborazioni. Nonostante la fusione dei due gruppi, comunque, ci si è trovati a dover affrontare problemi etici e pratici che hanno fatto perdere al progetto alcuni dei suoi iniziali propositi a favore di alcune inevitabili soluzioni di compromesso, creando uno strumento ancora acerbo ma comunque dalle grandi potenzialità. L'idea di collaborazione iniziale, come detto, prevedeva che qualsiasi utente avesse accesso a tutti i documenti della rete con possibilità di modifica. Questa idea porta con sé almeno tre problemi, in questo momento, insormontabili. Prima di tutto la necessità forzata del consenso alla modifica sia degli autori dei documenti che degli amministratori dei sistemi sui quali tali documenti risiedono, situazione difficilmente verificabile. Inoltre, se la collaborazione divenisse uno strumento largamente utilizzato, bisognerebbe affrontare il problema di dove immagazzinare le modifiche o gli eventuali nuovi documenti prodotti. L'ultimo problema sarebbe la consistenza del lavoro prodotto: basterebbe, infatti, che un utente qualsiasi modificasse o cancellasse una risorsa che compone un documento per influire in maniera pesante sul lavoro degli altri. Allo stato attuale del progetto alcuni di questi problemi sono stati risolti cambiando le specifiche iniziali. Per far convivere l'integrità di un documento e la probabile mancanza dei diritti necessari con la possibilità di annotarlo, si è deciso che i commenti non debbano andare a modificare direttamente la pagina. Per annotare un documento, infatti, bisogna innanzi tutto richiamarlo e visualizzarlo sul browser, poi scegliere la parte che si vuole annotare, sia essa una parte di testo oppure un immagine, scrivere l'annotazione e poi salvare questa su di un server preposto a tale scopo. In questo modo, indicando l'indirizzo di tale server nella lista dei propri “annotation server”, sarà possibile risalire in un secondo momento alle note che si sono create o che in ogni modo si vogliono visualizzare. Il documento, quindi, non è fisicamente modificato e rimane sul server dove risiedeva in precedenza, ma ogni volta che è richiamato dal nostro browser, l'annotation server lo accoppia con le note relative. Per rendere possibile tutto questo sull'annotation server risiede un database che contiene i tracciati dei record che permettono di ricostruire l'annotazione: l'url del documento, il punto in cui l'annotazione dovrà apparire in formato XPointer[7] e il testo dell'annotazione vera e propria. A questo punto il browser visualizza il documento e, nei punti dove sono state inserite le note visualizza un richiamo che indica la presenza di un commento, solo cliccandoci sopra il commento diventerà visibile e/o modificabile secondo i permessi che si hanno sull'annotation server. Questa soluzione ha preso corpo solamente alla fine del 1998, quando XML e le tecnologie ad esso legate come RDF, XLink e XPointer, hanno assunto una maturità tale da poter essere prese in considerazione per un sistema così concepito. La possibilità di definire dei permessi sulle annotazioni create permette un raffinamento dell'uso che se ne può fare, si ha infatti la possibilità di renderle visibili o meno piuttosto che avere o meno il permesso di modificarle, creando in questo modo annotazioni personali, gruppi di lavoro e quanto altro, proprio come accade in un qualsiasi sistema che preveda la presenza di più utenti, risolvendo in tal modo il problema della consistenza del lavoro svolto. Queste scelte, l'uso degli standard XML e la separazione fisica del documento dalle annotazioni, hanno portato alla relativa stabilità attuale del progetto, anche se a scapito dell’abbandono di alcune scelte iniziali. L'unico problema rimasto irrisolto rimane dove immagazzinare le note un domani che saranno prodotte in quantità. Le proposte sono molteplici: da un unico server centralizzato fino ad arrivare ad una rete di server preposti. Nessuna, però, sembra ancora in grado di soddisfare in maniera adeguata le attese. Quello che si chiede a questa architettura, oltre alla possibilità di accogliere una grande quantità di dati, è di poter essere raggiunta da tutti. Necessità insomma della capacità di sopperire ad un’enorme quantità di richieste e di traffico. E’ ovvio che qualsiasi privato può crearsi la propria rete Annotea, ma quello che si vuole è una struttura pubblica e liberamente usabile. A questo punto il problema risulta essere meramente economico.

CAPITOLO 3

ANNOTEA

Entreremo ora in maniera più approfondita all’interno del progetto Annotea, andando a conoscere la sua architettura e i software che la implementano. Vedremo come sia possibile realizzare le specifiche del progetto senza rimanere necessariamente legati a determinati software. Nello spirito della sua fondazione, infatti, il w3c descrive gli standard a cui ci deve attenere ma non vincola in alcun modo sulla maniera in cui questi standard vengono implementati. A tal proposito mette a disposizione le proprie versioni di tali software ma allo stesso tempo ne indica le alternative e incoraggia l’implementazione di soluzioni proprie.

3.1 L’architettura

Come abbiamo già detto l’idea da cui si sviluppa Annotea è l’esigenza di creare delle estensioni alle tecnologie web esistenti. E’ facile quindi comprendere perché si sia deciso di implementare soltanto le caratteristiche inerenti l’aspetto delle annotazioni e collaborazioni, appoggiandosi in tutto e per tutto sulle strutture e sui protocolli già utilizzati nel WWW. Per questo motivo si deve pensare ad Annotea come ad una sovrastruttura del web così come lo conosciamo, volta ad aumentare le nostre capacità di controllo e produzione dei contenuti, senza intaccare la struttura sulla quale ci veniamo a poggiare. L’architettura client/server tipica della navigazione in internet è mantenuta totalmente. Per quanto riguarda il lato client è ovvio che la scelta del software dovrà ricadere su di un browser capace di implementare le specifiche di Annotea. Questi browser, ovviamente, permettono a chi non è interessato all’aspetto collaborativo, di navigare in maniera “classica” e senza mutare l’approccio maturato dall’uso quotidiano, anche se il loro forte è ovviamente la creazione e manipolazione delle annotazioni. Dal lato server, come detto, vengono introdotti gli Annotea server. Questi immagazzineranno, sotto forma di RDF, le annotazioni inerenti le pagine web. Il protocollo di comunicazione con i server Annotea è http, lo stesso utilizzato tra il browser e gli web server. Come si può vedere dalla figura 1 le annotazioni possono essere salvate anche in locale ma in questo modo non saranno condivise. Sarà poi compito del browser, quando verrà richiesta una pagina annotata, ricostruirla dopo averne raccolto gli elementi che la compongono, il documento originale proveniente dal web server e le annotazioni in arrivo dai server Annotea o da locale. La sola accortezza richiesta all’utente è quella di indicare, e quindi di conoscere precedentemente, l’indirizzo dei server da cui leggere le eventuali annotazioni o sui quali salvare le proprie. Quindi l’iter per la creazione di un annotazione sarà il seguente (figura 1). Per prima cosa si richiama, attraverso il browser, la pagina a cui si è interessati. Una volta che la pagina verrà visualizzata, si sceglierà il punto in cui si desidera che l’annotazione venga inserita. Si scrive l’annotazione, si invia l’annotazione ad uno o più annotation post server da noi scelti. Gli annotation post server sono i server a cui decidiamo di inviare l’annotazione appena creata. La presenza di due liste distinte per inviare e ricevere le annotazioni, permette di mantenere le annotazioni prodotta da noi separate da quelle che vogliamo solo visualizzare (Questa possibilità è prevista solamente da Amaya). L’annotazione può essere salvata anche localmente dove il browser si occuperà di immagazzinarla su di un file di testo, ma in questo modo non potrà essere condivisa. Una volta che l’annotazione è stata creata, chiunque usando un browser adatto, richiami la pagina da noi annotata e abbia nella sua lista di server Annotea quello che in cui noi abbiamo salvato l’annotazione, vedrà all’interno della pagina richiesta un’icona che lo avvertirà che in quel punto è stata creata una nota. Se deciderà di visualizzarla, verrà aperta una finestra di pop up in cui apparirà l’annotazione stessa e gli strumenti per modificarla o scrivere una replica, naturalmente se l’utente è in possesso dei permessi per poterlo fare.

Figura 1. L’architettura di Annotea.

3.2 I server

E’ il w3c stesso che, attraverso il suo sito web, incoraggia gli utenti ad implementare la propria versione di server Annotea. Attualmente però ne esistono solamente due versioni funzionanti e, per così dire, “riconosciuti ufficialmente”. Uno è messo a disposizione dal w3c, mentre l’altro è un’applicazione per Zope[8].

3.2.1 w3c public annotation server

Il w3c mette a disposizione un server Annotea perfettamente funzionante all’url http://annotest.w3.org/annotations. Dopo una breve procedura di registrazione, sarà possibile usare questo come annotation post server. L’unico lato negativo di questa procedura è che il w3c non garantisce la persistenza nel tempo dei dati salvati su questo server. Per ovvi motivi di spazio, infatti, periodicamente il database viene svuotato per garantire lo spazio necessario alle nuove annotazioni a scapito di quelle più vecchie. Per questo motivo è ovvio che questa soluzione va intesa solamente per scopi dimostrativi o per svolgere dei test e non come una piattaforma di lavoro o produzione. Questo server, inoltre, è il metro dello sviluppo del progetto stesso, infatti è su questa piattaforma che vengono implementate e testate in anteprima tutte le nuove caratteristiche che vengono introdotte. Sul sito del w3c è anche presente un tutorial su come implementare personalmente un server con le stesse caratteristiche di questo. Il database su cui verranno salvate le annotazioni è mySQL, come web server per interfacciarsi con l’esterno è stato scelto Apache, mentre le richieste per la gestione delle annotazioni sono affidate ad una serie di script Perl.

3.2.2 ZAnnot

L’altro server che andremo a conoscere, e che come vedremo sarà quello usato nella nostra demo, è ZAnnot[9]. Negli ultimi anni, all’interno del WWW, hanno assunto sempre maggiore importanza gli application server. Un application server, sostanzialmente, affianca alla capacità di inviare pagine web ai client che ne fanno richiesta, quella di eseguire vere e proprie applicazioni. Una pagina web normalmente non è un applicazione, è un file di testo opportunamente formattato che il client si incarica di renderizzare graficamente una volta ricevuto. Un application server è in grado di inserire all’interno di una pagina web un’applicazione la cui interfaccia grafica apparirà all’interno del browser, ma che svolgerà le sue operazioni sul server dove risiede. Ovviamente nel panorama di Internet si affacciano numerosi application server i quali rispondono a tutti i gradi di bisogno dell’utente. Esistono soluzioni commerciali o open source, server per applicazioni Java piuttosto che per Python o C++. L’application server di cui ci occuperemo è Zope. Zope è un progetto open source ed è sviluppato in Python[10], un linguaggio di scripting open source ed object oriented talmente potente da essere usato in progetti industriali o legati a grandi produzioni, come si può leggere nei credits del sito. Zope permette la pubblicazioni di applicazioni scritte sia in Python che in C++ e sono in lavorazione porting per altri linguaggi, ha un web server interno chiamato Medusa, e fornisce internamente anche un RDBMS ad oggetti. La sua natura modulare, oltretutto, permette di utilizzare soluzioni personali in quanto non vincola l’uso di queste ulteriori caratteristiche. Della suite fornita, infatti, è soltanto l’application server ad essere indispensabile, in quanto si può interfacciare sia a web server che a RDBS diversi da quelli forniti, sempre che si abbia bisogno di questi servizi. ZAnnot è un applicazione per Zope, scritta in Python e che implementa le specifiche di un annotation server.

3.3 I client

Anche per quello che riguarda i client il w3c promuove la creazione di nuove soluzioni. Attualmente si conoscono tre browser utilizzabili che implementano le specifiche Annotea e ci permettono la creazione e la gestione delle annotazioni. I tre software in questione sono Snufkin[11], Annozilla[12] e Amaya[13].

3.3.1 Snufkin

Snufkin non è propriamente un’applicazione, ma piuttosto uno studio sulle possibilità di Microsoft Internet Explorer (IE). Il browser di casa Microsoft ha un object model estremamente flessibile, e combinando questo aspetto con la possibilità di automatizzarlo attraverso degli script, si possono facilmente aggiungere caratteristiche a questo prodotto. Per fare ciò è necessario installare ScriptX?, un controllo ActiveX? creato dalla Meadroid[14],ed essere in possesso di una versione di IE uguale o superiore alla 5 che gira su una piattaforma Win32. Dopo l’installazione di ScriptX?, basterà scaricare e lanciare l’eseguibile di Snufkin (l’ultima versione disponibile è la 0.25). Ci troveremo davanti ad una sessione di IE uguale in tutto e per tutto a quella a cui siamo abituati, ma avremo a disposizione delle caratteristiche che prima ci erano precluse. Basterà infatti scrivere nella location bar i comandi nella sintassi di Snufkin per poter, tra le altre cose, validare la pagina che stiamo visualizzando (snufkin:validate), visualizzare l’header (snufkin:head) o visualizzare il contenuto della sezione noframe della pagina (snufkin:normes). La caratteristica che ci interessa maggiorente è naturalmente la possibilità di gestire le annotazioni. Il comando snufkin:annotations permetterà di visualizzare le annotazioni relative alla pagina che abbiamo aperto. Sunfkin:annotate apre una finestra di pop up che ci permetterà di creare la nostra annotazione che poi sarà inserita nel punto da noi prescelto. Per rendere possibile l’utilizzo dell’interfaccia relativa alle annotazioni, sarà necessario editare manualmente lo script di Snufkin, inserendo opportunamente l’indirizzo del server delle annotazioni, i nostri username e password relativi a quel server e il flag che indicherà se caricare automaticamente o meno le annotazioni relative alla pagina che stiamo visualizzando. Il progetto soffre degli inevitabili limiti di un progetto mantenuto da una sola persona e che si deve necessariamente poggiare su parti software di cui non ha controllo (IE e ScriptX?), le release sono estremamente rare e lo stesso autore dichiara la non maturità del codice. Nonostante tutto, però, Snufkin offre delle caratteristiche molto interessanti ed ha indubbiamente degli enormi margini di miglioramento per il futuro.

3.3.2 Annozilla

Anche per quanto riguarda Annozilla non si può parlare di una vera e propria applicazione. Annozilla è infatti un plugin per Mozilla. Rispetto a Snufkin può vantare di una maggiore cura grafica e la perfetta integrazione nel browser di riferimento. Dopo aver installato il pacchetto presente nel sito del progetto, giunto alla versione stabile 0.3.5, basterà dare il comando crome://annozilla/content/addpanel.xul nella barra degli indirizzi per vedere aggiunta la cartella relativa ad Annotea nella sidebar di Mozilla. All’interno di questa cartella abbiamo tutti gli strumenti necessari per la gestione e la creazioni delle annotazioni. Anche in questo caso è possibile indicare un solo server sia per ricevere le annotazioni che per salvarle e non è prevista una doppia lista. E’ stata recentemente rilasciata la versione 0.5beta di Annozilla, gli autori la definiscono come sperimentale, ma sembra funzionare con l’ultima relase di Mozilla 1.6 e fornisce il supporto per la sola lettura delle annotazioni anche se installata su Firefox 0.8, la technoloy preview di Mozilla.

3.3.3 Amaya

Come per i server, anche per i client il w3c mette a disposizione un suo strumento. Amaya è un editor/browser/validatore opensource, arrivato ormai alla relase 8.5, che si pone come punto di riferimento principale per i produttori che vorranno entrare in questo settore. Pensato originariamente come validatore di pagine web, Amaya è giunto ben resto a ricopre anche il ruolo d’editor e di browser. Date queste caratteristiche, sembrerebbe di trovarsi dinnanzi ad una killer application del panorama web. La realtà invece ci descrive una situazione ben diversa. Amaya è poco conosciuto perché, essendo prodotto da un ente e non da una software house, non gode neanche lontanamente della cassa di risonanza di altre applicazioni. Inoltre si presenta in una veste grafica spoglia e poco accattivante ben lontana dai browser che conosciamo e che, pur essendo un aspetto irrilevante ai fini pratici, in questo campo incide negativamente al momento della scelta. Oltretutto la veste grafica scelta si integra male sia con i temi dell’ambiente Windows sia con quelli dell’ambiente *NIX. Dal punto di vista tecnico ci troviamo invece di fronte ad un prodotto di tutto rispetto. Amaya è un ottimo validatore di pagine web, essendo questo la caratteristica principale per cui è nato e che non è stata mai abbandonata dai suoi sviluppatori. Come editor di pagine web, Amaya è un prodotto sicuramente sottovalutato, in quanto ci fornisce, anche se in un ambiente decisamente spartano, tutte le caratteristiche per la produzione di codice html: editor testuale, preview wysiwyg direttamente modificabile e tutte quegli strumenti solitamente presenti in questo tipo di strumenti. Amaya è molto rigido per quanto riguarda la sintassi e, praticamente, forza la creazione di codice aderente agli standard e ben formattato. E’ inoltre importante ricordare che Amaya supporta praticamente tutti gli standard web, anche quelli di ultima generazione come SVG (Scalable Vector Graphic, che permette di creare grafica attraverso una sintassi XML), MathML (Mathematical Markup Language, che permette di creare formule matematiche complesse attraverso sintassi XML), oltre naturalmente a quelli già affermati come HTML, XHTML, CSS e HTTP. Di Amaya esiste anche una versione OpenGL? che implementa le trasformazioni, le trasparenze e le animazioni SMIL degli elementi SVG. L’unico frangente in cui Amaya mostra un po’ i suoi limiti è quello della navigazione standard. Se intendiamo usarlo solamente come browser andremo incontro ad alcuni aspetti negativi. L’esperienza quotidiana potrebbe infatti essere frustrata dalla già citata povertà grafica e la non eccelsa velocità, se paragonata con quella dei browser più diffusi. Ma il punto di forza di questo prodotto è, ovviamente, la gestione delle annotazioni sui documenti web. Amaya mette a disposizione tutte le caratteristiche sino ad ora sviluppate in questo campo: creazione, reply e edit d’annotazioni locali e remote load d’annotazioni locali e remote (tramite il semplice inserimento degli indirizzi dei server remoti cui ci si vuole appoggiare), la possibilità di filtrare le annotazioni da visualizzare attraverso l'autore, il server di provenienza e il tipo, la possibilità di una gestione multiserver per quanto riguarda i server di load e la separazione delle liste tra i server di load e quelli di post. Dei tre client presi in esame, Amaya ,implementando il maggior numero di caratteristiche, è quello che permette il maggior controllo sulla gestione delle annotazioni, rivelandosi lo strumento migliore sotto questo punto di vista. Annozilla è quello che integra meglio gli strumenti per la gestione delle annotazioni all’interno del suo layout ma è ancora abbastanza lontano dal livello qualitativo di Amaya. Snufkin è il più acerbo dei tre, non avendo né le caratteristiche di Amaya né l’eleganza grafica di Annozilla, dimostrandosi per quello che è: uno studio sulle possibilità di implementazione di nuove caratteristiche per IE, ma dagli enormi margini di miglioramento.

3.4 La demo

In questa parte descriveremo i passi compiuti per installare una demo funzionante di Annotea. Vedremo i problemi incontrati e le soluzioni adottate per risolverli, analizzeremo le scelte effettuate e i settagli adottati sia sul server che sul client per raggiungere il risultato desiderato.

3.4.1 L’installazione del server

Il w3c rende disponibili le linee guida per la realizzazione di un proprio Annotea server che riproduca le caratteristiche del w3c public annotation server. L'architettura proposta dal w3c si basa su l'utilizzo di diverse tecnologie che vanno poi ad interagire nel funzionamento del server Annotea. Come server web è usato Apache, con l'unica aggiunta di alcuni richiami a script Perl che devono essere aggiunti all'interno del file di configurazione del server (httpd.conf). E' importante mettere in evidenza che in questo caso Apache non è usato per mettere a disposizione pagine web ma annotazioni. Le annotazioni e l'elenco degli utenti abilitati all'uso del server Annotea, coi relativi permessi, risiedono su di un database mySQL. Gli script Perl vanno aggiunti per permettere ad Apache di interfacciarsi con il motore del database e sono scaricabili dal sito del w3c in due formati: uno compresso con un freeze di sviluppo “meno recente” e l'altro, preferibile, direttamente dal CVS del progetto. La differenza tra le due scelte è macroscopica. Il formato compresso si compone di quattro archivi la cui grandezza è di poche centinaia di Byte e risalgono al 2000. Prelevarli dal CVS invece, garantisce che, oltre ad avere un prodotto più attuale, si sta utilizzando una versione più completa e strutturata, dato che la dimensione si aggira intorno ai dieci megabyte. Gli utenti di Apache che sono autorizzati all'uso degli Annotea Perl script sono gestiti direttamente da un database minimale, in formato testuale, gestito direttamente da Apache. L'utilizzo di numerosi prodotti, anche se ottimi e riconosciuti da tempo come standard “de facto” nei rispettivi campi (Apache come web server, mySQL come database, il Perl come linguaggio di scripting), porta, almeno dal mio punto di vista, ad una perdita d’immediatezza nell'installazione e manutenzione del prodotto completo che dovrebbero andare a formare, ovvero un server Annotea. Infatti, dopo aver installato le singole parti e aver eseguito alla lettera i settagli proposti dal documento del w3c, il prodotto non funziona ancora e rimane difficile capire a chi sia imputabile il malfunzionamento del tutto o fare un tracing del percorso dell'annotazione che si sta cercando di gestire. Ancor di più poiché le note messe a disposizione dal w3c sono approssimative in alcuni punti chiave e confidano nella conoscenza da parte dell'utente di ognuno degli strumenti che si sta usando. Oltretutto, nonostante si siano presi in considerazione tutti i client conosciuti, nessuno si prodiga in dettagli quando occorre un errore, né a video né nei suoi log. Questa mia impressione è avvalorata dal fatto che, ufficialmente, nessun server pubblicamente raggiungibile sia realizzato seguendo queste indicazioni tranne quello pubblico del w3c. Personalmente, ad oggi, non ne ho trovati altri, usando canali di ricerca classici (Google). Come detto in precedenza, l'unica altra implementazione funzionante di un Annotea server conosciuta è ZAnnot. ZAnnot è un'applicazione per Zope, l'application server scritto in Python, che implementa tutte le funzioni di Annotea, avendo come ulteriore vantaggio una notevole facilità d’installazione e manutenzione.

L'unico inconveniente incontrato, poi risolto attraverso uno scambio di e-mail con un utente che aveva avuto il mio stesso problema e rintracciato attraverso la mailing-list del w3c, si è riscontrato installando ZAnnot su di un server Zope installato dai binari e non compilato da sorgenti. Alla luce della mia esperienza posso affermare che l'installazione di Zannot si compone di tre semplici passaggi che permettono di avere, veramente in pochissimo tempo, un server Annotea funzionante. Per prima cosa bisogna installare Python da sorgenti (è consigliata esplicitamente la versione 2.1.x), avendo cura di compilarlo con l'opzione “--with-thread” che creerà così le librerie necessarie alla successiva compilazione di Zope.

configure -–with-threads && make && make install

Va a questo punto installato Zope. Dopo aver recuperato i sorgenti ed averli scompattati, basta lanciare lo script Python che si occuperà di tutte le fasi necessarie.

python w_pcgi.py

Dopo essersi procurati ZAnnot, basta scompattarlo nella directory dove risiedono le applicazioni che Zope può rendere pubbliche attraverso il suo web server interno. Basta quindi lanciare Zope, autenticarsi come suo amministratore, aggiungere un'istanza di ZAnnot tra le applicazioni messe a disposizione dal server e configurare i permessi sulle annotazioni che gli utenti del server Annotea potranno gestire. Personalmente ho configurato l’applicazione privilegiando la funzionalità e la velocità di realizzazione piuttosto che l’aspetto più strettamente amministrativo come la gestione meticolosa degli account. Dopo aver fatto ripartire Zope, passo necessario affinché quest’ultimo si accorga della nuova applicazione, mi loggo come manager. A questo punto aggiungo agli oggetti di Zope un annotation server object che chiamerò “zanno”. Il nome scelto è importante perché andrà a fare parte dell’indirizzo del servizio. A questo punto non mi rimane che configurare i permessi come da figure 2a e 2b, rendere cioè il server raggiungibile ed usabile da tutti e le annotazioni leggibili da chiunque. L'Annotea server a questo punto è funzionante e si può aggiungere il suo indirizzo, http://:8080/zanno, nella lista degli annotation server del proprio client. I vantaggi di usare Zannot/Zope sono molteplici. Zope è oramai un prodotto maturo e stabile, testato da un'ampia comunità di utenti e sviluppatori (il vantaggio tipico del mondo opensource). Un RDBM, un server web, la gestione degli utenti e dei permessi sono già compresi e gestiti dalla suite, ma la struttura modulare di Zope permette di usare al posto di uno qualsiasi di questi componenti un prodotto differente a seconda delle proprie necessità o preferenze. Zannot stesso può esistere in più di un'istanza per poter così far convivere sulla stessa macchina, ad esempio, un server di produzione e uno di test o sviluppo piuttosto che diversi server che raccolgono annotazioni relative ad argomenti diversi.

Figura 2a. Configurazione dei permessi di ZAnnot.

Figura 2b. Configurazione dei permessi di ZAnnot.

3.4.2 La configurazione del client

Dopo aver preso attentamente in esame tutti i client disponibili, ho scelto di usare Amaya, il prodotto del w3c. La scelta è caduta su questo software principalmente per due motivi. Il primo è la sua completezza, come già detto Amaya ha implementato per primo ed in numero maggiore tutte le caratteristiche introdotte di volta in volta all’interno del progetto Annotea, ed anche se sotto alcuni aspetti esce sconfitto dal confronto con altri prodotti, nel specifico campo della gestione delle annotazioni è ad oggi il prodotto di riferimento. Il secondo motivo è conseguenza diretta di ciò che abbiamo appena detto, dovendo fare una dimostrazione inerente la creazione e la gestione delle annotazioni, mi sembra ovvio farla con il prodotto che permette di compiere il maggior numero di operazioni possibili su di esse. Usando Amaya abbiamo la certezza che saremo in grado di gestire tutte le caratteristiche del progetto Annotea, dato che è lo stesso prodotto usato per svilupparle e testarle. Dal sito di Amaya è possibile scaricare la versione più recente per il nostro sistema operativo. Sono presenti i porting per Windows (sono supportate tutte le versioni dalla 95 in poi), Linux (sia sorgenti che binari) e, dall’ultima versione, la 8.5, è stato aggiunto anche quello per Mac OS X. L’installazione dei binari è semplice ed immediata. Per quanto riguarda Linux, basta scompattare l’archivio scaricato e si avrà pronto l’albero dell’installazione. Basterà a questo punto lanciare l’eseguibile per avere Amaya perfettamente funzionante. In ambiente Windows, la versione scaricata è un file di setup che, dopo le domande di rito: in che directory scompattare l’albero dell’applicazione, che nome inserire nell’elenco delle applicazioni, installerà autonomamente il programma. Per quanto riguarda questa specifica dimostrazione, useremo la release 8.5 specifica per Windows XP. Una volta installato il programma e lanciato l’eseguibile ci troviamo di fronte alla pagina di presentazione di Amaya (figura 3).

Figura 3. La pagina di presentazione di Amaya

Come vediamo l’interfaccia grafica dà l’impressione di una concezione obsoleta che mal si amalgama con l’impostazione generale e lo stile grafico utilizzato dal sistema operativo Windows XP. Ad onore del vero è giusto sottolineare che, avendo utilizzato Amaya anche su sistemi operativi Linux con KDE e Gnome, si ha la stessa impressione di inadeguatezza grafica anche su altri sistemi operativi e non solo con quello di casa Microsoft. D’altrocanto notiamo molto presto come sotto questa antiquata concezione grafica operi uno dei software maggiormente all’avanguardia nel campo degli standard web. La stessa pagina di presentazione, se visualizzata con altri browser, non viene renderizzata correttamente in quanto contiene standard non supportati da prodotti maggiormente utilizzati (figura 4).

Figura 4. La pagina di presentazione di Amaya su IE.

Come vediamo né l’immagine, né la formula matematica, né i poligoni sono visualizzati correttamente in quanto espressi in formati non supportati da Microsoft Internet Explorer, rispettivamente XLink, MathML e SVG. Nessuno degli altri browser presi in considerazione, Mozilla 1.6, Firefox 0.8 e Opera, supporta queste caratteristiche e di conseguenza gestisce anche in maniera differente il modo di presentare a video i dati che non comprende. Gli altri prodotti optano per mostrare come un enorme blocco di testo le parti scritte comprese tra tag che non riescono ad identificare. Superato l’iniziale smarrimento dovuto all’interfaccia grafica iniziamo ad entrare in maniera più approfondita nelle caratteristiche di questo prodotto. Iniziamo notando nella toolbar in alto, la presenza delle icone relative sia alla navigazione, sia all’editing di pagine web. E’ possibile passare da una modalità all’altra semplicemente premendo un bottone. Senza scendere troppo in particolari che ci porterebbero troppo lontano dall’argomento principale della nostra demo, voglio far notare come all’interno di un’unica interfaccia grafica, seppur lontana dallo stile a cui siamo abituati, convivono i due aspetti principali, oltre alla possibilità di annotare documenti, di questo prodotto: browser ed editor wysiwyg. Passiamo ora all’analisi di come sia possibile creare e estire annotazioni tramite l’utilizzo dei software appena descritti.

3.4.3 Come creare e gestire annotazioni

Per primo cosa bisognerà inserire le impostazioni necessarie per il caricamento delle annotazioni che ci interessano e il salvataggio di quelle da noi create. Andiamo nel menù a tendina Annotations e scegliamo la voce Configure, si aprirà una finestra in pop up come quella di figura 5. Il primo box, Annotation e bookmark user, indica il nome con il quale vogliamo essere riconosciuti dagli annotation server. Questo indicativo sarà il nome con il quale saveremo le nostre annotazioni. In Annotation post server andrà indicato l’indirizzo del server Annotea sul quale vogliamo che le nostre annotazioni vengano salvate. Nel nostro caso sarà http://zope.mbartoli.web.cs.unibo.it:80/zanno. In annotation server vanno inseriti gli indirizzi da cui vogliamo caricare le annotazioni riguardanti i documenti di cui ci stiamo interessando. Noi inseriremo,oltre a “localhost”, l’indirizzo del nostro annotation server. I checkbox sottostanti gestiscono il comportamento di Amaya per quanto riguarda il caricamento delle annotazioni. Nell’ordine viene abilitato il caricamento delle annotazioni salvate in locale, il caricamento delle annotazioni remote e la disibilitazione del caricamento automatico di tutte le annotazioni relative al documento caricato nel browser. Andiamo nella barra degli indirizzi e dirigiamo il nosro browser verso il sito del w3c, digitiamo quindi www.w3.org. Appena la pagina verrà visualizzata ci posizioneremo con il mouse nei pressi del link relativo al progetto Annotea e facciamo click. E’ importante non fare click sul link, altrimenti verremo rediretti verso la pagina di destinazione. A questo punto riapriamo il menù a tendina “Annotations” e scegliamo la voce “Annotate selection” a questo punto si aprirà una finestra di pop up come quella in figura 6 dove andremo a scrivere il testo della nostra annotazione di prova “Questa è una prova di Annotea”

Figura 5. Il pannello di configurazione delle annotazioni.

Figura 6. La finestra delle annotazioni.

Ora basta scegliere dal menù “Annotations” l’opzione “Post to server” e la nostra prova verrà inviata all’indirizzo dichiarato precedentemente nel box “Annotation post server”. Se ricarichiamo la pagina che abbiamo annotato o dal solito menù a tendina scegliamo la voce “Load” apparirà una matita arancione nel punto che avevamo scelto di associare la nostra annotazione (Figura 7). Facendo doppio click sulla matita si riaprirà la finestra di figura 6 nella quale possimo editare la nostra annotazione o decidere di creare una risposta scegliendo la voce “Reply to annotaions” dal menù “Annotaions” della finestra di pop up. Verrà aperta una nuova finestra in cui potremo scrivere la nostra risposta che, una volta salvata, farà apparire l’annotazione iniziale come in figura 8. E’ abbastanza facile immaginare come sia possibile creare complesse discussioni e sottodiscussioni utilizzando gli strumenti messi a disposizione da Annotea e Amaya. Ogni annotazione può diventare, se seguita da un adeguato numero di utenti disposti a partecipare attivamente, un forum di discussione vero e proprio. In quest’ottica si inserisce la considerazione fatta in precedenza sulla difficoltà di gestire un sistema basato sull’architettura di Annotea una volta che le annotazioni e gli utenti siano cresciuti abbastanza. Il problema non sarebbe solamente l’immagazzinamento delle informazioni, ma anche, e forse soprattutto, la capacità di reperirle se non si conosce l’URI del server dove risiedono.

Figura 7. Il richiamo all’annotazione appena creata.

L’ipotesi della produzione di un grande numero di annotazioni porta con sé anche un altro problema oltre a quelli del loro salvataggio e della loro reperibilità. Posto come assunto che si riesca a superare in maniera efficace questi problemi e che il progetto Annotea incontri il successo sperato, non è difficile immaginare uno scenario in cui un utente veda il documento visualizzato dal browser letteralmente invaso dalle icone del gran numero di annotazioni presenti su quella pagina. Amaya ci mette a disposizione la capacità di filtrare le Annotazioni che vogliamo vedere visualizzate attraverso la possibilità di creare localmente dei filtri in base all’autore, il tipo e il server di provenienza delle annotazioni che verranno visualizzate (Figura 9). Per raggiungere questo scopo è necessario, dal solito menù a tendina, scegliere la voce “Local filter” per fare apparire la finestra di pop up che permetterà di gestire questi filtri.

Figura 8. La risposta all’annotazione è stata salvata.

Figura 9. La gestione dei filtri locali

Dato che la creazione di un filtro per quanto riguarda l’autore o il server dell’annotazione dovrebbe risultare abbastanza intuitiva, spenderemo qualche parola in più per quanto riguarda il filtro del tipo. In Amaya sono previsti diversi tipi di annotazioni, sette per la precisione: Avviso, Cambiamento, Commento, Esempio, Spiegazione, Domanda e Vedi anche. In pratica, pur scegliendo dei tipi differenti, l’annotazione che si viene a creare è sempre uguale a meno del campo “Annotation type” dello schem RDF che si andrà a salvare sul server e delle diverse icone che appariranno sul documento una volta caricate le annotazioni. La catalogazione in diverse categorie delle annotazioni, permette di avere una struttura ancor più organizzata e flessibile. Questo, unitamente alla possibilità di creare dei filtri permette una maggiore velocità ed efficienza alle nostre ricerche nel caso in cui ci dovessimo muovere all’interno di documenti pesantemente annotati in cui la natura dei commenti sia molto eterogenea.

3.5 Conclusioni

In questo capitolo abbiamo visto i passi da compiere per installare velocemente ZAnnot, un server Annotea scritto per Zope, da poter utilizzare per il salvataggio delle nostre annotazioni. Subito dopo abbiamo visto come configurare efficacemente Amaya, il client messo a disposizione dal w3c per implementare le caratteristiche di Annotea. Nell’ultima parte abbiamo visto come creare e gestire le nostre annotazioni e come sia possibile salvarle e richiamarle dal server che abbiamo scelto di utilizzare e come interagire con le annotazioni già esistenti una volta che sono state caricate. Possiamo dire di avere affrontato tutti gli aspetti relativi alle annotazioni messi a disposizione di Amaya che, è bene ricordarlo, è un software che offre molto di più della possibilità di creare e gestire annotazioni ma che ha in questo aspetto la sua particolarità più marcata ed evidente. Abbiamo visto come sia relativamente facile arricchire di contenuti un documento altrimenti per noi intoccabile come può essere una pagina web che risiede su di un server dove non abbiamo accesso, oppure come sia possibile cooperare con altri utenti per la creazione di dati e documenti condivisi. Annotea mette a nostra disposizione degli strumenti di grande fascino per chi è interessato a quegli aspetti del web che, pur essendo stati tra i principali ispiratori di internet come è oggi, sono andati persi nel tempo a favore di una più immediata usabilità e a causa del loro scontrarsi con dei problemi pratici ancora oggi di difficile soluzione. Annotea è purtroppo ancora acerbo sotto alcuni aspetti ma ciò è principalmente dovuto al fatto che si basa su tecnologie ancora non del tutto stabili e ancora lontane dal diventare standard (XPointer difficilmente lo diventerà), che anzi trovano in Annotea uno dei principali campi di applicazione e di prova della loro validità.

CAPITOLO 4

APPROFONDIMENTO TECNICO

Nei capitoli precedenti abbiamo visto che cosa è Annotea sotto alcuni aspetti. Abbiamo elencato e spiegato brevemente i contesti tecnici e sociali che hanno fatto nascere il progetto Annotea e le evoluzioni che il progetto ha vissuto nel tempo. Abbiamo visto quali erano gli obiettivi iniziali e le difficoltà che si sono dovute affrontare per raggiungerli. Come detto, alcune volte, queste difficoltà si sono rivelate di impossibile risoluzione, tanto da portare alla redefinizione degli obiettivi del progetto. Abbiamo visto l’architettura di Annotea, come funziona un annotation server e come usare un client. Abbiamo infine creato e manipolato delle annotazioni usando una nostra installazione. In questo capitolo, invece, scenderemo maggiormente nel dettaglio per quanto riguarda l’aspetto più strettamente tecnico. Cercheremo di approfondire alcuni concetti in precedenza soltanto nominati e che meriterebbero comunque una trattazione molto più ampia.

4.1 XML

La nascita e l’affermarsi dell’eXtensible Markup Language (XML) e delle tecnlogie ad esso legato è da considerarsi il momento cruciale per le sorti di Annotea. XML va veramente inteso come la pietra angolare su cui si regge l’intero progetto. Infatti, se non si consideria l’architettura e le applicazioni che la compongono come possono essere il database delle annotazioni e il server web che gestisce le richieste o il protocollo usato per la trasmissione dei dati tra queste, la solo altra tecnologia utilizzata è XML, o delle tecnologie derivate da esso. XML è un linguaggio nato per descrivere altri linguaggi o, più propriamente, un metalinguaggio. Questo concetto che ad una prima analisi può sembrare estremamente astratto e poco chiaro nasconde, in realtà, una tecnologia che sta letteralmente rivoluzionando il panorama del Wolrd Wide Web. Questo linguaggio deriva per linea diretta dall’HTML e dal più vecchio SGML, ed è quindi un linguaggio di markup che si esprime attraverso tag proprio come i suoi predecessori. La differenza tra i suoi predecessori e XML è però profonda in quanto, pur mantenendo alcuni principi comuni ai linguaggi più vecchi, quest’ultimo ha di diverso sia gli obiettivi che si prefigge che alcuni concetti di partenza. Possiamo dire che la necessità di creare un nuovo linguaggio che sopperisse ai problemi dei due predecessori ha portato alla creazione di XML che ne eredità solamente le caratteristiche migliori. Nonostante HTML si sia evoluto in un linguaggio estremamente ricco e funzionale per la creazione di documenti strutturati, esso definisce solamente quei documenti che poi andranno pubblicati sulla rete. Questo particolare tipo di documento è appropriato per molte applicazioni, ma un considerevole insieme di altre applicazioni avrebbero enormi benefici da un modo più flessibile di strutturare i documenti. Inoltre un grande gruppo di tecnologie web sentivano il bisogno di un linguaggio che definisse una struttura di dati generalizzata ed è evidente che un linguaggio come HTML non fosse usabile per queste tecnologie. SGML, che è il linguaggio da cui è derivato anche HTML, è un meccanismo per specificare delle regole strutturali per la presentazione di dati. Il problema di questa tecnologia è la sua complessità e il fatto di contenere delle caratteristiche che rendono l’implementazione di software per la sua trattazione estremamente difficile. Eliminando queste caratteristiche, senza sacrificare nessuna delle funzionalità di SGML per la specifica di strutture di dati, è stato creato un linguaggio più facile da usare ma che contiente tutto il potere strutturale del linguaggio di partenza. Si può quindi affermare che XML è un sottoinsieme di SGML, da cui eredita gli obiettivi e la struttura, che è stato sfrondato di quelle caratteristiche che lo rendevano pesante e difficile da implementare. Si è così giunti alla creazione di un linguaggio molto più leggero ma estremamente potente, inoltre, dato che redefinire delle strutture dati già esistenti attraverso il DTD di XML è un compito relativamente semplice, la transizione tra sistemi già esistenti e XML può in molti casi avvenire in maniera relativamente semplice. Oggi si può affermare che XML sia uno dei centri nevralgici del web attuale, tanto che dopo aver raggiunto la stabilità necessaria per essere usato negli ambienti di produzione, ha anche raggiunto una diffusione tale che molte tecnologie lo utilizzano come base di partenza per il loro sviluppo e numerose altre sono rivisitate e corrette attraverso XML. La misura di quanto appena detto è data dal fatto che l’intero HTML sia stato redefinito attraverso le specifiche e le idee di XML, giungendo ad XHTML che è l’ultima incarnazione di HTML e sicuramente la più performante in termini di efficienza e portabilità (cross platform) dato che l’uso di XML ha permesso un approccio modulare e una facile estensibilità. Non solo HTML, ovviamente, ha tratto notevoli benefici dall’utilizzo di XML. Numerose sono le tecnologie che sono state sviluppate usando come base di partenza proprio l’eXtensible Markup Language. Una di queste è il Resource Description Framework di cui andremo adesso a parlare.

4.2 RDF

Abbiamo già detto in precedenza che in web è stato in origine costruito per essere usato dall’uomo e, sebbene ogni cosa in esso sia leggibile dalle macchine, questi dati tuttavia non sono comprensibili da queste ultime. E’ veramente difficile automatizzare qualunque cosa sul web e, a causa della quantità di informazioni contenute, non è possibile gestirlo manualmente. La soluzione proposta è quella di usare metadati per descrivere i dati contenuti sul web. I metadati sono “dati sui dati” (per esempio un catalogo di biblioteca è un metadato poiché descrive pubblicazioni) o, nell’accezione usata nella specifica di RDF,”dati che descrivono risorse web”. La distinzione tra dati e metadati non è di tipo assoluto: è una distinzione creata in origine da una specifica applicazione, e molte volte la stessa risorsa potrà essere interpretata simultaneamente nei due modi. Resource Description Framework (RDF) è una base per il trattamento dei metadati; esso fornisce interoperabilità tra applicazioni che scambiano sul Web informazioni comprensibili dalle macchine. RDF pone l'accento sui mezzi che consentono l'elaborazione automatica di risorse Web. RDF può essere utilizzato in diverse aree di applicazione; per esempio: nella ricerca di risorse al fine di migliorare le capacitàdei motori di ricerca, nella catalogazione per descrivere il contenuto e le relazioni del contenuto disponibili in un particolare sito Web, in una pagina o in una biblioteca digitale, usato da agenti software intelligenti per facilitare la condivisione e lo scambio di conoscenza, nella valutazione di contenuto, nel descrivere collezione di pagine che rappresentano un unico "documento" logico, per descrivere i diritti di proprietà intellettuali di pagine web, e per esprimere le preferenze sulla riservatezza da parte di un utente così come le politiche di riservatezza di un sito Web. RDF associato alla firma digitale rappresenterà la chiave di volta per la costruzione di un " Web affidabile " per il commercio elettronico, per la collaborazione e per altre applicazioni. Scopo essenziale di RDF è quello di realizzare un meccanismo per la descrizione di risorse che non sia basato su un particolare dominio di applicazione, né che definisca (a priori) la semantica di qualche dominio di applicazione. La definizione di questo meccanismo, pertanto, dovrebbe essere neutrale rispetto ai domini, tuttavia il meccanismo dovrebbe essere adattabile alla descrizione di informazioni di qualsiasi dominio. Tra le cose più importanti per facilitare la definizione di metadati, RDF disporrà di un sistema di classi, analogo a quelli utilizzato dai sistemi di programmazione e modellazione orientata agli oggetti. Una collezione di classi (tipicamente creata per uno scopo o per un dominio specifico) viene detta schema. Le classi sono organizzate in una gerarchia, e offrono meccanismi di estensibilità attraverso un raffinamento in sottoclassi. In questo modo, per creare uno schema leggermente differente da uno esistente, non sarà necessario "reinventare la ruota", ma si potranno realizzare solo modifiche incrementali rispetto allo schema di base. Attraverso la condivisione degli schemi, RDF favorirà il riutilizzo delle definizioni di metadati. Grazie alla estensibilità incrementale di RDF, se gli agenti che elaborano i metadati incontrano schemi non noti saranno comunque in grado di risalire all'indietro fino agli schemi a loro familiari ed eseguire azioni significative su metadati diversi da quelli per cui erano stati progettati. Inoltre la condivisibilità e l'estensibilità di RDF consentono ai creatori dei metadati di usare ereditarietà multiple per "mischiare" le definizioni, di fornire viste multiple per i loro dati, servendosi del lavoro già fatto da altri. Inoltre, è possibile creare istanze di dati RDF sulla base di schemi multipli utilizzando fonti multiple (es., "mischiando" tipi differenti di metadati). Gli schemi possono, a loro volta, essere scritti in RDF; un documento abbinato a questa specifica, [RDF Schema] descrive un insieme di proprietà e classi per descrivere gli schemi RDF. Quale risultato dell'attività di molte comunità che si sono trovate a concordare sui principi di base della rappresentazione e della trasmissione dei metadati, RDF è il frutto dell'influenza di diverse fonti. Le influenze principali provengono dalla stessa comunità della standardizzazione del Web nella forma di metadati HTML e PICS, dalla comunità dei bibliotecari, dalla comunità dei documenti strutturati nella forma di SGML e soprattutto XML, e anche dalla comunità della rappresentazione della conoscenza (KR). Ci sono anche altre aree tecnologiche che hanno contribuito alla definizione di RDF: linguaggi di modellazione e programmazione orientata agli oggetti, e le basi di dati. Anche se RDF proviene dalla comunità della rappresentazione della conoscenza, i lettori familiari con questo specifico campo devono essere avvertiti che RDF non specifica un meccanismo per ragionare. RDF può essere definito un semplice sistema. Un meccanismo per ragionare potrebbe essere costruito al di sopra di questo sistema. Ritengo inoltre che sia importante notare che non sia necessario utilizzare la sintessi XML per descrivere un sistema RDF, ma una qualsiasi altra sintassi capace di esprimero lo stesso modello.

4.2.1 Modello RDF di base

Alla base di RDF vi è un modello per rappresentare proprietà definite e valori di proprietà. Il modello RDF si basa su principi ben definiti provenienti da varie comunità operanti nel campo della rappresentazione dei dati. Le proprietà RDF possono essere pensate come attributi di risorse e in questo senso corrispondono alle tradizionali coppie attributo-valore. Le proprietà RDF rappresentano anche relazioni fra risorse e quindi un modello RDF può perciò somigliare ad un diagramma entità-relazione. (Più esattamente, gli schemi RDF - che sono essi stessi istanze del modello dei dati RDF - sono diagrammi entità-relazione). Nella terminologia delle architetture orientate agli oggetti, le risorse corrispondono ad oggetti e le proprietà corrispondono a variabili di istanza. Il modello dei dati RDF è un modo, neutrale rispetto alla sintassi impiegata, di rappresentare espressioni RDF. La rappresentazione del modello dei dati è usata per valutare l'equivalenza dei significati. Due espressioni RDF sono equivalenti se, e solo se, le loro rappresentazioni del modello dei dati sono uguali. Questa definizione di equivalenza permette variazioni sintattiche nell'espressione, senza alterarne il significato. Il modello di base dei dati è costituito da tre tipi di oggetto: Risorse Tutte le cose descritte con espressioni RDF vengono dette risorse . Una risorsa può essere un'intera pagina Web; ad esempio il documento "http://www.w3.org/Overview.html". Una risorsa può anche essere una parte di una pagina Web; ad esempio uno specifico elemento HTML o XML all'interno di un documento. Una risorsa può anche essere un'intera collezione di pagine; per esempio un intero sito Web. Una risorsa può anche essere un oggetto non direttamente accessibile via Web; ad esempio un libro stampato. Le risorse sono sempre definite da URI con eventuali anchor id. Qualsiasi cosa può avere associato un URI; l'estensibilità degli URI permette l'introduzione di identificatori per qualsiasi entità immaginabile. Proprietà Una proprietà consiste in un aspetto specifico, una caratteristica, un attributo, o una relazione usata per descrivere una risorsa. Ogni proprietà ha un significato specifico, definisce i valori ammessi, i tipi di risorse a cui può riferirsi, e la sua relazione con altre proprietà. Questo documento non tratta del modo in cui le proprietà vengono espresse; per tali informazioni, vedi la specifica RDF Schema. Asserzioni Una determinata risorsa, insieme ad una proprietà definita e al valore relativo alla proprietà stessa, costituiscono una asserzione RDF. Queste tre parti della asserzione sono dette, rispettivamente, il soggetto, il predicato, e l'oggetto. L'oggetto di una asserzione (ovvero il valore della proprietà ) può essere a sua volta un'altra risorsa, oppure può essere un letterale: ovvero una risorsa (definita da un URI) o una semplice stringa di caratteri o altro tipo di dato primitivo definito da XML. In termini RDF un letterale può comprendere nel suo contenuto anche markup XML, ma esso non è elaborato da un processore RDF. Esistono alcune restrizioni sintattiche su come può essere espresso il markup nei letterali;

4.2.2 Esempi

Le risorse sono identificate da un identificatore di risorsa. Un identificatore di risorsa è un URI più un anchor id opzionale. Ai fini di quanto trattato in questa sezione, le proprietà saranno indicate con semplici nomi. Consideriamo come semplice esempio la frase : “Ora Lassila è il creatore della risorsa http://www.w3.org/Home/lassila”. Questa frase si compone delle seguenti parti: Soggetto (Risorsa) http://www.w3.org/Home/Lassila Predicato(Proprietà ) Creatore Oggetto (letterale) "Ora Lassila"

Noi rappresenteremo graficamente un'asserzione RDF servendoci di grafi orientati etichettati (detti anche "diagrammi a nodi e archi"). In questi diagrammi i nodi (di forma ovale) rappresentano le risorse e gli archi rappresentano le proprietà definite . I nodi che rappresentano stringhe (letterali) avranno forma rettangolare. La frase riportata sopra potrebbe pertanto essere rappresentata con il seguente diagramma:

La direzione della freccia è significativa. L’arco parte sempre dal soggetto e punta all’oggetto dell’asserzione. Il semplice diagramma riportato sopra può anche essere letto “http://www.w3.org/Home/lassila” ha come creatore “Ora Lassila”, o più in generale “HA”. Consideriamo ora il caso in cui si voglia dire qualcosa di più circa le caratteristiche del creatore di questa risorsa. In prosa tale proposizione potrebbe essere: L’individuo il cui nome è Ora Lassila, e-mail , è il creatore di http://www.w3.org/Home/lassila. Lo scopo di questa frase è quello di rendere il valore della proprietà "Creatore" un'entità strutturata. In RDF tale entità è rappresentata come un'altra risorsa. La proposizione riportata sopra non dà un nome a questa risorsa; essa è anonima, quindi nel diagramma sottostante noi la rappresenteremo come un ovale vuoto:

Corrisspondentemente a quanto indicato nella nota precedente, questo diagramma potrebbe essere letto “http://www.w3.org/Home/lassila ha come creatore qualcuno e questo qualcuno ha come nome Ora Lassila e come e-mail lassila@w3.org” Il modello dei dati RDF offre una struttura concettuale, astratta, per la definizione e l'uso di metadati. Per creare e scambiare questi metadati sarà necessaria anche una sintassi concreta. Questa specifica RDF usa la codifica XML come sintassi di interscambio. RDF richiede inoltre l'utilizzo di Namespace XML per associare ciascuna proprietà allo schema in cui è definita la proprietà. Le descrizioni sintattiche presenti in questo documento usano la notazione Extended Backus-Naur Form (così come definita nella specifica XML nella Sezione 6, intitolata "Notation") per descrivere gli elementi sintattici di base di RDF. La EBNF viene qui condensata, per facilitarne la lettura; in particolare, si usa “rdf” in corsivo per indicare una variabile di prefisso di namespace piuttosto che la più esatta notazione BNF " '<' Nsprefix ':...' ". è implicito dall'adozione delle regole XML il requisito che i nomi di proprietà e di tipo usati nei tag di chiusura coincidano esattamente a quelli usati nei tag di apertura. Tutte le flessibilità sintattiche di XML sono inoltre comprese implicitamente; es. trattamento degli spazi bianchi, uso degli apici singoli (') o doppi ("), character escaping, case sensitivity, e identificazione del linguaggio naturale o formale. Questa specifica definisce due sintassi per la codifica di una istanza di un modello di dati RDF. La sintassi di serializzazione esprime in modo regolare tutte le caratteristiche del modello dei dati. La sintassi abbreviata include dei costrutti aggiuntivi che servono a rappresentare in forma più compatta un sottoinsieme del modello dei dati. Gli interpreti RDF devono essere in grado di trattare sia la sintassi di serializzazione completa che quella abbreviata. Quindi gli autori di metadati sono liberi di adoperare le due sintassi insieme.

4.2.3 Sintassi di serializzazione di base

Raramente una singola asserzione RDF compare isolata; più comunemente diverse proprietà di una risorsa saranno date insieme. La sintassi XML di RDF è stata progettata per compiere questo facilmente raggruppando le molteplici asserzioni riguardanti la stessa risorsa all'interno di un elemento Description. L'elemento Description indica, tramite l'attributo about, la risorsa alla quale si applicano tutte le asserzioni . Se la risorsa non esiste ancora (ovvero, non ha ancora un identificatore), allora l'elemento Description può fornire l'identificatore della risorsa usando un attributo ID. La sintassi di serializzazione RDF di base ha la seguente forma:

[1] RDF ::= [''] description* [''] [2] description ::= '' propertyElt* '' [3] idAboutAttr ::= idAttr | aboutAttr [4] aboutAttr ::= 'about="' URI-reference '"' [5] idAttr ::= 'ID="' IDsymbol '"' [6] propertyElt ::= '<' propName '>' value ''| '<' propName resourceAttr '/>' [7] propName ::= Qname [8] value ::= description | string [9] resourceAttr ::= 'resource="' URI-reference '"' [10] Qname ::= [ NSprefix ':' ] name [11] URI-reference ::= string, interpreted per [URI] [12] IDsymbol ::= (any legal XML name symbol) [13] name ::= (any legal XML name symbol) [14] NSprefix ::= (any legal XML namespace prefix) [15] string ::= (any XML text, with "<", ">", and "&" escaped)

L'elemento RDF è un semplice involucro che delimita i confini in un documento XML entro cui il contenuto è esplicitamente da intendere mappabile in una istanza di modello di dati RDF. L'elemento RDF è opzionale se il contenuto può essere riconosciuto come RDF dal contesto dell'applicazione. L'elemento Description contiene gli elementi rimanenti che sono all'origine della creazione delle asserzioni nell'istanza del modello. L'elemento Description può essere pensato (ai fini della sintassi di base RDF) semplicemente come un posto dove inserire l'identificazione della risorsa che viene descritta. Tipicamente vi sarà più di una asserzione relativa ad una risorsa; Description fornisce un modo per indicare il nome della risorsa solo una volta pure in presenza di diverse asserzioni . Quando, con l'elemento Description, viene specificato l'attributo about, le asserzioni contenute in Description si riferiscono alla risorsa il cui identificatore è indicato da about. Il valore dell'attributo about è interpretato come un riferimento-URI. Il corrispondente identificatore della risorsa si ottiene risolvendo il riferimento-URI nella sua forma assoluta, secondo quanto specificato da [URI]. Se nel riferimento-URI è incluso un identificatore di frammento, allora l'identificatore di risorsa si riferisce solamente a quella sottocomponente della risorsa che contiene che è identificata dal corrispondente id del frammento interno alla risorsa principale, altrimenti l'identificatore si riferisce all'intera risorsa indicata dall'URI. Un elemento Description senza attributo about rappresenta una nuova risorsa. Tale risorsa potrebbe essere un surrogato, o proxy, per qualche altra risorsa fisica che non abbia un URI riconoscibile. Il valore dell'attributo ID dell'elemento Description, se presente, rappresenta l' anchor ID di questa risorsa "in-line" . Se un'altro Description o un valore di proprietà deve essere riferito alla risorsa "in-line", questo userà il valore dell'ID di quella risorsa contenuto nel suo attributo about. L'attributo ID indica la creazione di una nuova risorsa e l'attributo about si riferisce ad una risorsa esistente; quindi, in Description è possibile specificare o ID o about, ma non entrambi contemporaneamente nello stesso elemento. I valori per ogni attributo ID non devono apparire in più di un attributo ID all'interno del singolo documento. Un elemento Description può contenere più di un elemento propertyElt con lo stesso nome di proprietà. Ciascuno di questi propertyElt aggiunge un arco al grafo. L'interpretazione di questo grafo è definita da chi progetta lo schema. All'interno di un propertyElt, l'attributo resource specifica che un'altra risorsa è il valore di questa proprietà; ovvero l'oggetto della asserzione, piuttosto che un letterale è un'altra risorsa identificata da un URI. L'identificatore di risorsa dell'oggetto è ottenuto risolvendo il riferimento-URI dell'attributo resource in modo analogo a quanto indicato sopra per l'attributo about. Le stringhe devono essere XML well-formed; i soliti meccanismi XML per l'escaping e per il contenuto fra apici possono essere usati se le stringhe contengono sequenze di caratteri (es. "<" e "&") che violano le regole di well-formed o che in qualche modo possano essere confuse con il markup. Per la sintassi aggiuntiva per specificare un valore di una proprietà con contenuto XML well-formed contenente markup, in modo che questo markup non sia interpretato da RDF. I nomi di proprietà devono essere associati con uno schema. Ciò può ottenersi qualificando i nomi degli elementi con un prefisso di namespace per connettere in modo non ambiguo la definizione della proprietà con il corrispondente schema RDF o dichiarando un namespace di default, così come specificato in [NAMESPACES]. La frase scelta come esempio:

Ora Lassila è il creatore della risorsa http://www.w3.org/Home/lassila

è rappresentata in RDF/XML come:

Ora Lassila

Qui il prefisso 's' di namespace si riferisce a uno specifico prefisso di namespace scelto dall'autore di questa espressione RDF e definito in una dichiarazione di namespace XML del tipo:

xmlns:s="http://description.org/schema/"

Questa dichiarazione di namespace sarebbe tipicamente inclusa come attributo XML nell'elemento rdf:RDF ma può anche essere inclusa all'interno di un particolare elemento Description, o anche in una singola espressione propertyElt. L' URI del nome del namespace nella dichiarazione di namespace costituisce un identificatore unico globale per il particolare schema che l'autore di questi metadati sta usando per definire il proprio uso della proprietà Creator. Anche altri schemi possono definire una proprietà di nome Creator e le due proprietà saranno distinte attraverso i loro identificatori di schema. Nota anche che uno schema normalmente definisce diverse proprietà ; una singola dichiarazione di namespace sarà sufficiente a rendere disponibile l'uso di un ampio vocabolario di proprietà. Il documento XML completo contenente le descrizioni di cui sopra sarebbe:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> Ora Lassila

Usando per il namespace RDF la sintassi di default come definita in [NAMESPACES], questo documento potrebbe essere scritto anche così:

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> Ora Lassila

Inoltre, le dichiarazioni di namespace possono essere associate con un singolo elemento Descriptio o anche con un singolo elemento propertyElt, come nell'esempio seguente:

Ora Lassila

Dal momento che le dichiarazioni di namespace possono essere annidate, l'esempio precedente potrebbe essere ulteriormente condensato nel seguente modo:

Ora Lassila

Tuttavia, espressioni fortemente condensate come questa sono scoraggiate quando la codifica RDF/XML è scritta a mano o per mezzo di un editor di testo. Sebbene priva di ambiguità, questa modalità aumenta le possibilità di errore rispetto all'uso coerente di prefissi espliciti. Nota che un frammento RDF/XML che si intende inserire in altri documenti dovrebbe dichiarare tutti i namespaces adoperati, in modo da essere completamente autoesplicativo. Ai fini di una migliore leggibilità, negli esempi introduttivi riportati nel seguito di questa sezione saranno omesse le dichiarazioni di namespace per far risaltare lo specifico punto illustrato. Alla luce di quanto spiegato fino a questo punto credo che sia utile mostrare come appare una annotazione salvata localmente da Amaya in formato RDF:

<r:RDF xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:a="http://www.w3.org/2000/10/annotation-ns#" xmlns:t="http://www.w3.org/2001/03/thread#" xmlns:http="http://www.w3.org/1999/xx/http#" xmlns:d="http://purl.org/dc/elements/1.0/"> http://www.google.it/#xpointer(string-range(/html[1]/body[1]/center[1]/p[2]/font[1],"",52,6)) Annotation of Google manuel 2004-05-25T17:33:46+01:00 2004-05-25T17:34:12+01:00

Si può facilemente notare che il documento annotato è la pagina “http://www.google.it”, che il titolo dell’annotazione è “Annotation of Google” e che l’autore sia “manuel”. E’ bene notare che, per ricostruire la posizione dell’annotazione sulla pagina di riferimento, Amaya utilizzi la sintassi XPointer:

http://www.google.it/#xpointer (string-range (/html[1]/body[1]/center[1]/p[2]/font[1],"",52,6))

Questa convenzione, che non crea problemi quando l’annotazione viene salvata localmente dato che l’applicazione che la crea e che la legge è sempre la stessa, è invece fonte di problemi quando si inviano annotazioni su annotation server remoti. XPointer, infatti, non è stato ancora riconosciuto come standard dal W3C e molto probabilmente non lo diverrà mai, per cui il salvataggio di questo dato potrebbe portare a interpretazioni non omogenee se l’annotazione venisse consultata da client diversi. A tal proposito Annotea ha scelto di sopperire al problema in maniera forse brutale ma sicuramente efficace. Le annotazioni remote non sono infatti referenziabili a singole parole o caratteri. Se con il mio client creo un’annotazione che fa riferimento ad una parola all’interno di un paragrafo e poi la salvo, quando la andrò a ricaricare dal server, l’icona dell’annotazione non apparirà accanto alla parola che ho precedentemente annotato ma invece farà riferimento, inevitabilmente, all’inizio del paragrafo che contiene la parola precedentemente annotata.

CAPITOLO 5

CONFRONTO CON GLI ALTRI TOOL

Dopo aver introdotto i concetti inerenti il web semantico e collaborativo, abbiamo concentrato la nostra attenzione sul progetto Annotea e il modo in cui realizza tali concetti. Abbiamo poi visto come sia possibile realizzare un proprio server Annotea e successivamente utilizzare Amaya per produrre e gestire le nostre annotazioni. In questo capitolo faremo una breve panoramica su alcuni tool che si pongono, come Annotea, l’obiettivo di implementare i principi originari di un web semantico e collaborativo.

5.1 Le ontologie

Le ontologie sono considerate i componenti di base di cui sono composte le informazioni, sono informazioni basilari che non possono essere ulteriormente scomposte in informazioni più semplici. Il combinarsi delle ontologie va a creare l’informazione che noi percepiamo. Inoltre le ontologie sono una parte riutilizzabile di conoscenza su un dominio specifico. Il concetto di ontologia ricopre una parte importante in alcuni dei tool che vedremo di seguito per cui ne forniremo due delle più note definizioni.

5.1.1 Definizione di ontologia secondo Gruber

La definizione più citata di ontologia fu data da Tom Gruber nel 1993. Un'ontologia è una esplicita specificazione di una concettualizzazione. La definizione di Gruber costruisce l'idea che la formalizzazione del dominio di conoscenza inizia con la concettualizzazione del dominio [Genesereth e Nilsson 1987], cioè è l'identificazione degli oggetti che si è ipotizzato esistano nel mondo e delle relazioni tra loro. Secondo Gruber un'ontologia è una quintupla composta di classi, istanze, funzioni, relazioni, assiomi. Le classi corrispondono alle entità del dominio, le istanze sono gli oggetti che stanno nel dominio, le funzioni e le relazioni collegano le entità al dominio, ed in fine gli assiomi che limitano il senso e l'uso delle classi, istanze, funzioni e relazioni.

5.1.2 Definizione di ontologia secondo Guarino

Un'ontologia secondo Guarino, è invece: un set di assiomi logici progettati per considerare il senso di un vocabolario. Da questa definizione nasce la relazione tra una concettualizzazione e l’ontologia che la specifica e la formalizza. La definizione di Gruber è così stata estesa prendendo non solo la concettualizzazione ma anche il linguaggio usato per descriverla ed un insieme di assiomi associati con essa. In questo senso un'ontologia è un linguaggio dipendente mentre una concettualizzazione è un linguaggio indipendente.

5.2 Gli altri tool

Passiamo ad analizzare alcuni tool che possono essere paragonati al progetto Annotea per quanto riguarda la loro capacità di creare e gestire annotazioni

5.2.1 OntoMat?-Annotizer

Ontomat-Annotizer è un front-end grafico disponibile sia per Windows che per Linux, che permette la creazione e la gestione di annotazioni basandosi sul framework CREAM (CREAtion of Metada) creato dall’università di Karlsruhe. Questo framework è molto simile a quello proposto da Annotea in quanto si basa, per il salvataggio delle annotazioni, su database relazionali interrogabili attraverso il linguaggio SQL. E’ inoltre possibile salvare localmente le proprie annotazioni. Il formato usato per il salvataggio, sia esso locale o remoto, è quello definito dalla sintassi RDF precedentemente descritta. Negli sviluppi previsti da questo applicativo c’è anche la possibilità di collegare tra di loro diverse annotazioni, creando un’interconnessione dinamica che permetterà traslazioni anche tra diversi server. Di questo progetto fa anche parte S-CREAM (Semiautomatic CREAtion of Metadata) che mira alla creazione semiautomatica di annotazioni di pagine web. Per ottenere questo risultato sono stati creati due tool supplementari: Amilcare e Anne. Per estrarre automaticamente le informazioni occorre prima eseguire una fase di ‘addestramento’ del tool che esegue l’estrazione (Amilcare). L’utente deve fornire un set di documenti, simili tra loro, e annotarli in modo opportuno prima di poter iniziare la fase di “learning”. L’output di questa fase è una serie di regole di inferenza che verranno poi usate dal tool per estrarre la conoscenza dai documenti sui quali verrà invocato (Anne). Le informazioni estratte possono essere successivamente rifinite. E’ importante sottolineare che questo strumento permette solamente la creazione di annotazioni appartenenti a categorie di ontologie precedentemente definite. Le classi di ontologie a cui fare riferimento si possono sia scaricare dalla rete che creare autonomamente.

5.2.2 Smore

SMORE (Semantic Markup, Ontology and RDF Editor) è uno strumento che permette all’utente di arricchire i propri documenti con aggiunte di parti RDF usando ontologie Web in relazione a specifici termini ed elementi dell’utente stesso. Lo scopo di questo software è quello di fornire all’utente un ambiente flessibile nel quale può creare la sua pagina web senza troppi ostacoli (è presente nel pacchetto anche un editor HTML), permettergli di arricchire i propri documenti con minime conoscenze dei termini e della sintassi RDF. Comunque, l’utente deve essere in grado di classificare semanticamente i dati in suo possesso per creare annotazioni. Fornisce un riferimento a ontologie già esistenti, per permettere di usare più precisi riferimenti sulla propria pagina web. L’utente può anche creare la sua ontologia da appunti e prendere in prestito termini da ontologie già esistenti. Questo tool è sviluppato all’interno del progetto MINDSWAP e consente di annotare anche immagini (o parti di esse) con PhotoSMORE?. Un altro obiettivo di questo progetto è quello di ridurre la differenza tra la creazione dei contenuti (creazione di pagine web – authoring) e la fase di annotazione. Il processo di annotazione è più o meno simile agli altri: si seleziona una parte del testo e si creano delle triple (tipo RDF). Gli elementi delle triple possono essere associati agli elementi di ontologie anche in un momento successivo alla creazione della tripla stessa. C’è un componente – MailSMORE? – che consente di arricchire le mail scritte rispettando certe strutture, di triple collegate ad ontologie relative alla posta elettronica. Questo framework consente di modificare, navigare, cercare ontologie, aiutando in questo modo la ricerca dell’ontologia più adatta da associare all’annotazione che si sta effettuando. E’ inoltre possibile cercare dinamicamente l’ontologia che più si addice al contesto specifico. C’è un sistema che inferisce alcuni tipi di triple e le propone all’utente che può eventualmente cancellarle. Scraper è un modulo che consente di analizzare il contenuto di pagine web alla ricerca di strutture predefinite quali tabelle, campi, liste e creare automaticamente triple RDF. C’è un sistema per la gestione delle ontologie – Parka-DB – che si affida ad un DBMS e gestisce le triple RDF per fare inferenza.

5.2.3 MnM?

MnM? (Ontology Driver Semi-Automatic and Automatic Support for Semantic Markup) è uno strumento per l’annotazione che è in grado di supportare l’annotazione sia automatica che semi-automatica di pagine web con contenuto semantico. MnM? integra un web browser con un editor per l’ontologie e fornisce APIs da collegare ai server per le ontologie e per l’integrazione di informazioni tramite strumenti per l’estrazione delle informazioni. Tra le sue caratteristiche c’è la possibilità di annotare rispetto ad ontologie ben precise, di navigare le varie ontologie rispetto a cui annotare i documenti, annotare automaticamente dei documenti dopo una fase di “learning”, il controllo di validità dei risultati rispetto alle ontologie usate. Gli autori del progetto dicono che il loro sistema è simile ad OntoMat?. Il tool richiede diversi pacchetti software per funzionare (per adesso funziona solo su Windows 2000). Questo tool fa uso di Annie e Amilcare, per trovare i token dei documenti (parole, frasi, etc.) e per indurre le regole di estrazione. In futuro prevedono di utilizzare l’annotazione così creata per migliorare le ricerche facendo anche uso di agenti.

5.2.4 Wiki Wiki Web

Definire Wiki wiki web un tool sarebbe un errore, in quanto non esiste nessuna applicazione con questo nome che implementa un sistema di annotazione. E’, piuttosto, un’idea dalla quale si sono sviluppate diverse implementazioni del concetto di base. La parola wiki è di origine hawaiana e significa veloce. L’obiettivo è quello di fornire all’utente di un sito web, un’interfaccia che gli dia la possibilità di creare e modificare liberamente le pagine che compongono il sito. Date queste caratteristiche il progetto Wiki wiki web si inserisce meglio nel settore del web collaborativo anziché in quello semantico, ma sta avendo un riscontro talmente positivo che merita certamente di essere perlomeno segnalato. Il primo sito che ha implementato questo meccanismo è stato c2.com/cgi/wiki?WikiWikiWeb. Questo sito permette ai suoi utenti di creare nuove pagine e di modificare quelle già esistenti. Ovviamente esistono dei limiti entro i quali muoversi tesi più che altro a prevenire comportamenti deliberatamente distruttivi nei riguardi dei contenuti. Alcune pagine, ad esempio quelle contenenti indici e link di partenza oppure le home delle diverse sezioni, non sono modificabili ne cancellabili. Gli utenti hanno a disposizione una sand box dove compiere esperimenti ed acquisire manualità con il sistema. Si ha infatti a disposizione un sottoinsieme di tag HTML che possono essere usati nei documenti, arricchito da una serie di convenzioni aggiuntive che riguardano principalmente convenzioni di formattazioni del testo, o regole di inserimento di link o immagini. Una volta inserito o modificato il testo che interessa attraverso l’interfaccia di composizione messa a disposizione dallo stesso sito, si possono verificare i risultati ottenuti. E’ chiaro che sopra questo framework siano implementabili sistemi di utenza, permessi e pubblicazione facilmente immaginabili. L’unico strumento necessario per usufruire di Wiki wiki web è, pertanto, il nostro comune browser, senza necessità di reperire componenti aggiuntivi non presenti nella distribuzione standard o tantomento software appositi. Sull’onda di questo primo esperimento ne sono seguiti altri tra i quali spicca sicuramente la Wikipedia. Questo sito si pone come obiettivo quello di fornire alla comunità di internet una enciclopedia completamente gratuita e creata dagli stessi utenti attraverso i loro inserimenti e modifiche. Il successo è stato immediato, tanto che, non solo sono presenti migliaia di voci distribuite nei diversi campi di interesse, ma sono già presenti numerose traduzioni che a loro volta implementano e mettono a disposizione un sistema wiki completamente indipendente da quello originario. Anche questa tesi che state leggendo è pubblicata su un sistema wiki messo a disposizione dall’università. Esistono diversi soluzioni per implementare autonomamente un sistema Wiki wiki web sui propri siti web, dallo scrivere un proprio software ad hoc ed implementare il framework su cui andrà a lavorare, a quella certamente più immediata di reperire un pacchetto in rete già pronto tra i numerosi già presenti e facilmente rintracciabili.

CAPITOLO 6

CONCLUSIONI

In questa tesi abbiamo inizialmente descritto il contesto tecnico, sociale e politico in cui è nato e si sta sviluppando il progetto Annotea del W3C ed il suo evolversi negli anni. Annotea è un progetto nato per aumentare le capacità del web semantico e collaborativo cercando di realizzare alcuni aspetti che erano nelle intenzioni di partenza di chi ha creato internet . Il W3C ha cercato di concepire un’architettura che permettesse di creare e gestire informazioni e documenti condivisi da una comunità di utenti più o meno grande. Il progetto col tempo sì e venuto a scontrare con problemi di tipo pratico, alcune volte insormontabili, derivanti della natura intrinseca degli elementi su cui si andava ad operare. La proprietà intellettuale di un documento, il diritto di accedere o meno a infrastrutture hardware predisposte ad ospitare informazioni, la necessità di proteggere il proprio o l’altrui lavoro da interventi esterni e non autorizzati sono solo una parte di questi problemi. Come abbiamo visto alcuni hanno addirittura portato a ridefinire le specifiche del progetto mentre altri come la limitata capacità fisica dei sistemi preposti al salvataggio di annotazioni sono ancora argomento di discussione. Successivamente sono state illustrate le parti di cui si compone l’architettura di Annotea e i software sia sul lato server che su quello client che le implementano, scendendo in dettaglio sulla demo da me sviluppata. Il W3C si è fatto carico della produzione dei software necessari all’implementazione del progetto Annotea, ma come qualsiasi altro standard in lavorazione presso questo ente, incoraggia la produzione e l’utilizzo di altri strumenti che lo implementano. Abbiamo così visto alcune proposte per la creazione delle architetture necessarie alla realizzazione di un server Annotea e i client che supportano questo progetto. Ho elencato le difficoltà incontrate e le scelte effettuate per la realizzazione di una mia demo di Annotea e ho cercato di spiegare come sia possibile creare e gestire un’annotazione con gli strumenti da me usati. Sono stati in seguito sviscerati i dettagli implementativi e tecnici relativi ai componenti di Annotea e alla realizzazione della demo, analizzando le scelte che mi hanno portato all’utilizzo di un sistema ibrido composto dal client prodotto dal W3C e del server prodotto dalla comunità opensource di Zope e funzionante sotto questo application server. Di seguito abbiamo messo brevemente a confronto Annotea con altri progetti che si muovono nello stesso contesto analizzandone in parte le differenze ed i punti in comune. In questa parte abbiamo visto come Annotea si differenzi dagli altri progetti ad essa paragonabili per alcune scelte radicali. La decisione di dare la possibilità di creare annotazioni senza fare riferimento ad un insieme predefinito di ontologie, è sicuramente la più importante. Se inizialmente può sembrare un aspetto negativo in quanto da la possibilità di creare informazioni teoricamente inutilizzabili o prive di significato per un agente automatizzato, che ricordiamo è uno degli obiettivi del progetto, dopo una breve riflessione è semplice capire come in realtà questa scelta sia vincente sotto il profilo della flessibilità e della potenza del progetto. L’utente o la comunità che necessità di informazioni o annotazioni ben formattate per il loro utilizzo deve semplicemente definire un specifica e creare dei dati coerenti con tale specifica. Tutti gli altri sono liberi di usare Annotea a loro piacimento, magari come un iper-forum. L’architettura di Annotea da la possibilità all’utente di utilizzarla per implementare un sistema di ontologie ma gli altri progetti non possono simulare il comportamento generale di Annotea e questo mi sembra decisamente un punto a favore. Possiamo quindi dire che il progetto Annotea ricopre indubbiamente un ruolo principale nel campo dello sviluppo del web semantico e collaborativo. La sua storia quasi decennale viaggia e si evolve di pari passo con l’evolversi delle tecnologie e degli standard su cui si basa, gli stessi che sono attualmente adottati dalle applicazioni leader del settore web. Le scelte effettuate durante il suo sviluppo, che ricordiamo è tuttora in atto, anche se in alcuni casi sono state quasi obbligatorie, si sono dimostrate non solo afficaci ma in alcuni casi sicuramente vincenti per aspetti come la flessibilità e la potenza del prodotto finale. Quello che arriva in mano all’utente finale è un prodotto facile da installare ma anche da utilizzare, che permette di creare e gestire annotazioni e informazioni per i più diversi utilizzi, dall’acquisizione automazzata di dati, alla creazione di appunti su documenti di studio, alla creazione di un sistema per la creazione collaborativa di pagine web. Non bisogna poi dimenticare che Annotea e i software che lo implementano sono attualmente in via di sviluppo. Uno dei punti di forza di questo progetto è l’alto numero di standard supportato dal client prodotto dal W3C che sono stati aggiunti al progetto man mano che si affermavano sulla rete. E’ quindi lecito aspettarsi che l’affermarsi di altri standard porterà al loro ingresso nella già lunga lista di quelli supportati. Inoltre la sua natura di prodotto basato su standard le cui specifiche sono di libero accesso porterà alla creazioni, peraltro già iniziata, di prodotti sempre più numerosi tra cui scegliere a seconda delle proprie esigenze e possibilità.


to top


You are here: Tesi > ArgomentiDiTesi > ProgettoAnnotea > TestoDellaTesi

to top

Copyright © 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback