Facoltà di Scienze, Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Tecnologie Informatiche
Tesi di Laurea
Doroty: Digital Object RepOsitory with
Types.
Realizzazione della componente di Storage di
un sistema per la gestione delle Digital
Library basato su tipi.
Relatori
Prof. Giuseppe Prencipe Dr. Paolo Manghi
Controrelatore Prof. Giorgio Ghelli
Candidato Alessia Bardi Anno accademico 2008-2009
Indice
1 Introduzione 1
1.1 La nascita delle biblioteche digitali . . . 1
1.2 Modelli dei dati e di documento . . . 3
1.2.1 Modello dei dati per compound object . . . 4
1.2.2 Espressività dei modelli dei dati di DLMS . . . 6
1.3 Obiettivo della tesi . . . 7
2 Stato dell'arte 9 2.1 Fedora . . . 10
2.1.1 Il modello dei dati . . . 10
2.1.2 Architettura . . . 14
2.1.3 Linguaggio di query . . . 15
2.1.4 Osservazioni . . . 17
2.2 DSpace . . . 18
2.2.1 Il modello dei dati . . . 18
2.2.2 Architettura . . . 20 2.2.3 Linguaggio di query . . . 21 2.2.4 Osservazioni . . . 21 2.3 Altri DLMS . . . 22 3 Doroty 25 3.1 Motivazioni . . . 25
3.2 Il modello dei dati . . . 26
3.2.1 Modello di basso livello . . . 26
3.2.2 Modello di alto livello . . . 38
3.3 Architettura . . . 44
3.3.1 TypeManager . . . 48
3.3.2 InstanceManager . . . 54
4 Conclusioni 61
Elenco delle gure
1.1 Struttura di un sistema software . . . 2
1.2 Scala di espressività dei modelli dei dati di DLMS . . . 7
2.1 Struttura di un digital object in Fedora . . . 11
2.2 Entità digitali di Fedora e relazioni per le dissemination . . . . 13
2.3 Architettura di Fedora . . . 14
2.4 modello dei dati di DSpace . . . 19
2.5 Architettura di DSpace . . . 20
3.1 Relazioni fra Object, Set e Type . . . 27
3.2 Istanziare Type, Set e Object . . . 28
3.3 Istanza di un modello di documento per proceedings di una conferenza . . . 36
3.4 Aree dell'architettura di Doroty . . . 45
3.5 Area Logica e Fisica di Doroty . . . 46
3.6 Diagramma delle classi del TypeManager . . . 50
3.7 Tabelle nel database gestite da Hibernate in base al le di mapping LowLevelType.hbm.xml. . . 53
3.8 Diagramma delle classi dell'InstanceManager . . . 55
Elenco delle tabelle
3.1 Grammatica TDL . . . 29
3.2 Grammatica DDL . . . 30
3.3 Grammatica DML . . . 31
3.4 Esempi d'uso degli operatori di cast e import . . . 32
3.5 Implementazione di un modello di documento per l'insieme di proceedings di una conferenza. . . 34
3.6 Creazione di oggetti digitali con il linguaggio DML . . . 34
3.7 Grammatica DQL . . . 37
3.8 Estensioni al linguaggio TDL . . . 39
3.9 Estensioni al linguaggio DML . . . 41
Capitolo 1
Introduzione
1.1 La nascita delle biblioteche digitali
Nel corso degli ultimi anni siamo stati testimoni di un processo di informa-tizzazione che ha coinvolto tutte le attività dei settori terziari portando ad una generale evoluzione dei servizi oerti agli utenti. Le biblioteche non sono rimaste insensibili a tali cambiamenti e si sono evolute sia dal punto di vista dell'organizzazione delle risorse informative, sia da quello dei servizi oerti agli utenti. I maggiori eetti dell'informatizzazione delle biblioteche sono sta-ti il passaggio dagli schedari cartacei ai cataloghi informasta-tici per la gessta-tione delle informazioni sul materiale conservato, la conversione in formato digitale dei contenuti e la necessità di gestire nuove risorse che sempre più spesso sono prodotte in formato digitale, senza una corrispondente copia analogica. A causa di questi cambiamenti, le biblioteche hanno oerto agli utenti nuovi servizi, come la ricerca on-line per mezzo di cataloghi informatici, il prestito interbibliotecario e l'accesso a copie digitali del materiale conservato.
L'informatizzazione dei contenuti e delle funzionalità oerte agli utenti ha portato alla nascita di biblioteche digitali, o Digital Library (DL). Una DL è un'organizzazione costituita da risorse umane, tecnologiche e infrastrutturali che colleziona, organizza, assicura la preservazione e rende disponibili conte-nuti digitali ad una o più comunità di utenti. I sistemi software di supporto ad una DL sono detti Digital Library System (DLS) e forniscono le funziona-lità di base per la gestione dei contenuti, ovvero per la loro memorizzazione, ricerca, accesso ed elaborazione. Le tipologie e la modalità di accesso alle funzionalità variano a seconda delle necessità delle comunità [Candela2007]. La realizzazione di un DLS è un processo che coinvolge sviluppatori ed utenti della DL e che ha come obiettivo la soddisfazione delle esigenze ap-plicative della comunità. Tale obiettivo è spesso in contrasto con i costi che
l'organizzazione è disposta a sostenere per la realizzazione del DLS, la quale avviene secondo uno schema a livelli tipico di ogni sistema software (vedi Figura 1.1).
Figura 1.1: Struttura di un sistema software
Un sistema software è composto dal livello applicativo, costituito dalle applicazioni usate dagli utenti, e un livello di storage (Data Management Sy-stem, DMS) a cui è delegata la gestione e ciente dei dati manipolati dalle applicazioni (vedi 1.1 (a)). In particolare, un'applicazione fornisce agli utenti le funzionalità che essi richiedono presentando i dati secondo il modello dei dati dell'applicazione (i.e. de nizione della struttura delle entità da trattare) stabilito in base alla analisi delle esigenze della comunità. Un DMS forni-sce funzionalità per la memorizzazione persistente, ricerca, elaborazione e accesso ai dati secondo un preciso modello dei dati (per esempio relazionale o ad oggetti). In questo scenario, gli sviluppatori di applicazioni devono in primo luogo esprimere il modello dei dati applicativo per mezzo delle primi-tive del modello dei dati, quindi implementare le applicazioni per gli utenti. Poniamoci ad esempio in un contesto in cui il dominio applicativo sia quello di un'azienda che desidera un'applicazione per la gestione degli stipendi dei suoi impiegati (vedi Figura 1.1 (b)). Per realizzare l'applicazione richiesta gli sviluppatori devono implementare il modello dei dati dell'applicazione in ba-se alle necessità dell'azienda, la quale speci cherà quali informazioni relative
agli impiegati e agli stipendi sono rilevanti. Se il DMS è un sistema di gestio-ne di base di dati relazionale (RDBMS, Relational Database Management System), gli sviluppatori devono progettare e implementare il modello dei dati applicativo come un insieme di tabelle relazionali. A questa operazione seguirà lo sviluppo dell'applicazione, che dovrà proporre una vista dei dati e delle funzionalità in base al modello dei dati applicativo, nascondendo cioè agli utenti le operazioni da eettuare sulle tabelle.
Anche per lo sviluppo di DLS possiamo identi care questi fasi. Come mostrato in Figura 1.1 (c), in questo caso l'applicazione è il DLS, il modello dei dati dell'applicazione è detto modello di documento e il DMS è un Digital Library Management System (DLMS). Un DLMS è un sistema di gestione di dati orientato alle DL, ovvero il suo modello dei dati ha la proprietà di supportare nativamente alcune strutture dati che tipicamente si trattano in una DL, per esempio utenti, metadati, collezioni di oggetti e associazioni fra di essi. Come descritto in dettaglio nella Sezione 1.2, i DLMS si die-renziano in base all'espressività del modello dei dati, ovvero alla varietà di modelli di documento supportati. In questo senso, agli estremi di in una sca-la di espressività dei modelli, possiamo identi care modelli dei dati rigidi e essibili: modelli dei dati rigidi consentono l'espressione solo di modelli di documento dalla struttura prede nita; modelli dei dati essibili permettono invece di esprimere modelli di documento dalla struttura arbitraria.
1.2 Modelli dei dati e di documento
Dalla nascita delle DL ad oggi le esigenze degli utenti sono evolute e, con loro, la natura dei modelli di documento. Possiamo de nire un modello di documento come segue:
Def. (Modello di documento). De nizione formale delle entità (fatti e oggetti del mondo reale) che una DL vuole trattare in termini di struttura (proprietà) e di semantica (signi cato delle proprietà).
Non esistono in letteratura linguaggi per la speci ca di modelli del documen-to. Tipicamente, i progettisti di DL fanno riferimento al linguaggio oerto dal modello dei dati di uno speci co DLMS e ne sfruttano le primitive, dette oggetti digitali, per istanziare le entità della propria DL.
Def. (Modello dei dati di DLMS). De nizione formale dell'insie-me delle primitive, cioè oggetti digitali, supportate da un DLMS per la rappresentazione digitale delle entità di un modello di documento.
L'assenza di un linguaggio di speci ca per modelli di documenti comporta: • la mancanza di strumenti che permettano ai progettisti di rappresentare
il modello di documento di una DL a prescindere da un particolare modello dei dati di DLMS;
• l'impossibilità di comparare diversi DLMS sulla base dell'espressività dei loro modelli di dati, cioè della varietà dei modelli di documento rappresentabili.
Nel seguito, sulla base di un'analisi delle diverse soluzioni di DLMS, forni-remo un semplice linguaggio di speci ca per i modelli del documento, che chiameremo modello dei dati per compound object. Grazie a tale linguaggio, saremo in grado di mostrare le ragioni che ci hanno portato alla realizzazione di Doroty sulla base di un confronto con altre soluzioni per DLMS. In par-ticolare vedremo che Doroty può essere collocato fra i DLMS essibili (vedi Capitolo 3).
1.2.1 Modello dei dati per compound object
I primi DLS (ad esempio gli Information Retrieval System) permettevano agli utenti di memorizzare in maniera persistente documenti multimediali e di recuperarli successivamente attraverso ricerche sui metadati ad essi asso-ciati. In questo contesto, il modello di documento rappresenta il documento multimediale come una coppia di entità payload e metadati. Un payload rappresenta il contenuto di un le, mentre i metadati una descrizione del documento multimediale la cui natura può variare in base al formato del payload o ai requisiti del DLS. Ad esempio: un insieme di keywords nel caso di payload in formato testuale, un istogramma nel caso di payload in formato immagine, o un record, cioè un insieme di etichette e valori, per indicare una lista dettagliata di proprietà del payload.
È tradizionalmente noto nel mondo delle DL che le entità payload e me-tadati individuano due classi di entità ricorrenti nei DLS e sono quindi stru-menti di rappresentazione caratterizzanti dei modelli del documento per le DL.
Def. (Payload). Insieme di dati tipicamente contenuto in un le. Def. (Metadato). Insieme di campi (tipicamente coppie (proprietà, valore)) che descrivono le caratteristiche di un'entità.1
de -Come conseguenza dell'evoluzione dei requisiti delle comunità di utenti del-le DL, deldel-le caratteristiche di condivisione ed aggregazione di contenuti tra diverse DL, potenzialmente in diversi domini autoritativi, e dell'integrazione di strumenti come il Web, attualmente le DL trattano modelli di documento descritti da oggetti digitali dalla struttura più complessa rispetto a quella dei documenti multimediali. La peculiarità di tali modelli di documento, anche detti modelli di compound object, è che descrivono entità caratterizzate da associazioni con altre entità. Ad esempio l'insieme degli articoli che costitui-scono i proceedings di una conferenza: i proceedings, così come gli articoli che li compongono, sono rappresentati da entità payload associate ad entità metadato di formato DC e associate fra loro per mezzo di relazioni. Di fatto, le realtà delle attuali DL sono descritte da modelli di documento che rappre-sentano gra di entità, in cui le entità sono associate tra loro da particolari entità relazione.
Def. (Relazione). Entità che rappresenta un'associazione fra due entità. Tipicamente è dotata di un'etichetta, o nome, che descrive la natura dell'associazione.
Da una rassegna dei modelli dei dati di DLMS, risulta che l'insieme minimale di oggetti digitali ricorrente per la rappresentazione di modelli di documento per compound object descrive una realtà in termini delle entità payload, me-tadato e relazione. Un modello dei dati che mette a disposizione e permette la combinazione di oggetti digitali che rappresentano le tre entità è detto modello dei dati per compound object.
Def. (Modello dei dati per compound object). Modello dei dati che mette a disposizione primitive per la rappresentazione di mo-delli di compound object come combinazione di particolari istan-ze delle tre entità fondamentali delle DL: payload, metadato e relazione2.
Def. (Modello di compound object). Istanza del modello dei dati per compound object, cioè un modello di documento de nito per
nito da DCMI (Dublin Core Metadata Initiative) [DCMI]. Esso de nisce la semantica ed i tipi di quindici campi per la descrizione di un generico documento: title, creator, sub-ject, description, publisher, contributor, date, type, format, identi er, source, language, relation, coverage e rights. Nella rappresentazione XML di DC, ad esem-pio, il valore del tag <dc:author> è l'autore del testo, il valore di <dc:format> è il formato MIME del documento, il valore di <dc:date> è una data o periodo di tempo signi cativo per la risorsa, ad esempio la data di creazione o quella di ultima modi ca.
2È nelle intenzioni future di questa ricerca approfondire la de nizione, qui posta in modo informale, di un linguaggio di speci ca per modelli del documento.
mezzo delle primitive del modello dei dati per compound object.
Ad esempio, il modello del documento relativo ai proceedings di una confe-renza è il modello di compound object che descrive le due entità del mondo reale proceeding e articolo come due istanze di entità payload in associazione tra loro con un'istanza di entità relazione uno-a-molti con etichetta "inPro-ceedings"; in ne, le entità proceeding e articolo sono associate ciascuna ad un'istanza di entità metadati con struttura Dublin Core tramite un'istanza di entità relazione "hasMetadata".
1.2.2 Espressività dei modelli dei dati di DLMS
In base alle de nizioni date nella precedente sezione, un modello dei dati di DLMS può essere misurato, e quindi comprato ad altri, in base alla sua espressività, cioè la capacità dei propri oggetti digitali di rappresentare modelli di compound object. In Figura 1.2 è mostrata un'ipotetica scala di espressività dei modelli (da rigidi a essibili), la quale colloca alcuni dei modelli di dati più noti in letteratura in ordine crescente di essibilità. I cataloghi per documenti multimediali sono DLMS fondamentalmente rigi-di poiché il loro modello dei dati non ore primitive per la gestione delle relazioni tra entità (ad eccezione di quella implicita fra il payload ed il corri-spondente metadato). Esistono modelli dei dati di cataloghi più essibili di altri, per esempio quelli che permettono di decidere il formato dei payload e metadati da rappresentare, ma le assunzioni sulla struttura dei documenti multimediali sono in ogni caso molto restrittive. All'altro estremo della scala troviamo invece DLMS con modelli dei dati molto espressivi, come Fedora [Lagoze2005]. Gli oggetti digitali supportati da Fedora permettono di rap-presentare payload di vari formati MIME (html, ti, mpeg, tar, quicktime ne sono solo alcuni esempi), scegliere in che modalità tali payload devono essere memorizzati (per esempio in locale o come riferimento ad una risorsa esterna al sistema per mezzo di URI) e de nire relazioni arbitrarie fra oggetti in base alle necessità del modello di documento, imponendo però l'uso di metadati Dublin Core per la descrizione degli oggetti.3.
DLMS rigidi Tipicamente i DLMS rigidi sono progettati per essere adot-tati in uno speci co dominio applicativo delle DL, nel quale i requisiti in-formativi e funzionali dei modelli di documento e delle applicazioni sono ben de niti. Per questa ragione il loro modello dei dati impone dei vincoli
Figura 1.2: Scala di espressività dei modelli dei dati di DLMS
strutturali e semantici ben precisi sui compound object rappresentabili. La conseguenza negativa di questo approccio è l'impossibilità di soddisfare le esigenze delle comunità di DL che vorrebbero adottare modelli di documento dierenti.
D'altra parte, grazie alle assunzioni sulla natura dei modelli di documento adottati dalle DL, è possibile distribuire insieme al DLMS un pacchetto di applicazioni pronte per l'uso. I costi di realizzazione di un DLS sono perciò limitati a quelli necessari per la con gurazione di tali applicazioni in base alle eventuali peculiarità del modello di documento.
DLMS essibili I DLMS essibili possono essere usati in qualsiasi dominio applicativo delle DL, poiché le primitive oerte dal modello dei dati sono su cientemente espressive da permettere la rappresentazione di compound object dalla natura arbitraria. D'altra parte, l'assenza di assunzioni sulla struttura e sulla semantica dei modelli di documento adottabili dalle DL, impedisce la distribuzione di applicazioni per gli utenti insieme al DLMS.
Per realizzare un DLS la DL deve a darsi ad un team di sviluppatori per l'implementazione di applicazioni ad hoc per il modello di documento de nito. Questa necessità generalmente comporta un costo di realizzazione e manutenzione del DLS maggiore rispetto a quanto accade nel caso di DLMS rigidi.
1.3 Obiettivo della tesi
Questa tesi presenta il progetto e l'implementazione di un prototipo di DLMS, chiamato Digital Object RepOsitory with Types (Doroty), con modello dei dati essibile basato su tipi. In Doroty un modello di documento è espresso in termini della struttura, cioè dei tipi, dei compound object che popoleranno la DL. L'idea prende ispirazione dai DBMS (Database Management System), nei quali il modello dei dati basato su tipi porta a diversi bene ci sia dal
punto di vista della progettazione, sviluppo e manutenzione di applicazioni, sia da quello della gestione e ciente e sicura dei dati. In particolare Doroty, sfruttando la conoscenza statica dei tipi degli oggetti che dovrà preservare, è in grado di:
• ottimizzare la memorizzazione degli oggetti ed essere più e ciente nella loro ricerca e nell'accesso ai contenuti;
• essere a dabile nel supporto all'integrità dei dati;
• garantire la correttezza delle applicazioni implementate dagli sviluppa-tori di DLS;
• contenere i costi di realizzazione e manutenzione di DLS.
È importante sottolineare che, ad oggi, i nostri studi in letteratura, in parte riportati al Capitolo 2, non hanno portato alla luce un precedente nella rea-lizzazione di un DLMS basato su un modello dei dati tipato. Fedora è l'unico con cui possiamo confrontarci poiché essibile e dotato di un concetto simile a quello dei tipi, non su ciente però a garantire i bene ci sopraelencati.
Il sistema Doroty è presentato al Capitolo 3, nel quale verrà descritto il modello dei dati (sez. 3.2) e l'architettura del sistema (sez. 3.3). In ne, nel Capitolo 4, sono proposti ulteriori sviluppi ed ottimizzazioni del sistema.
Capitolo 2
Stato dell'arte
Nel Capitolo 1 abbiamo individuato due tipologie di modello dei dati che ci permettono di suddividere i DLMS in due categorie: DLMS essibi-li e DLMS rigidi. I principali rappresentanti delle due categorie sono, rispettivamente, Fedora e DSpace.
Fedora adotta un modello dei dati essibile, che permette di esprimere modelli di documento dalla struttura personalizzata, con lo svantaggio però di richiedere più sforzi di con gurazione e di implementazione per istanziare un DLS. Le applicazioni fornite da Fedora sono basate sul modello dei dati del sistema e quindi troppo generiche per essere utilizzate direttamente dagli utenti. Una DL che desidera usare Fedora come DLMS deve quindi a darsi ad un team di sviluppatori per l'implementazione delle applicazioni per gli utenti della comunità. Al contrario, DSpace con il suo modello dei dati rigido, prede nisce la struttura dei modelli di documento esprimibili e, di conseguenza, le applicazioni di base in dotazione con il DLMS sono utilizzabili dagli utenti. La relativa semplicità di installazione è un fattore determinante per la scelta del DLMS da parte delle DL: la diusione di DSpace (circa 500 istanze) è infatti maggiore di quella di Fedora (circa venti istanze)1.
È interessante notare che le organizzazioni cui appartengono i due siste-mi, Fedora Commons e DSpace Foundation, hanno recentemente2 iniziato
una collaborazione per de nire degli standard comuni al ne di garantire l'interoperabilità fra DLS creati a partire dai due sistemi [Morris2008]. In
1In base alle informazioni divulgate dal ROAR (Registry of Open Access Repositories) [ROAR2009] e presenti nei siti internet dei due sistemi.
Istanze registrate di DSpace: 375 nel ROAR, 335 nel wiki di DSpace. Istanze registrate di Fedora: 17 nel ROAR, 12 nel sito di Fedora. I dati sono imprecisi poiché la registrazione dei DLS è facoltativa
2Agosto 2008
particolare è in corso la de nizione di un livello astratto di storage comune per i due sistemi3.
In questo Capitolo si descrivono i sistemi Fedora (sez. 2.1) e DSpace (2.2), in particolare negli aspetti che più ci interessano: il modello dei dati, l'archi-tettura del sistema e il linguaggio di query per mezzo del quale è possibile identi care e selezionare gli oggetti digitali. Nella Sezione 2.3 sono descrit-ti concisamente i sistemi OpenDLib, GreenStone, EPrints, CDS Invenio e Marian DL Generator.
2.1 Fedora
FEDORA (Flexible Extensible Digital Object Repository Architecture) [Lagoze2005] è un'architettura software orientata ai servizi per la gestione di contenuti sviluppata dalla Cornell University e dalla University of Virginia. Fra i più signi cativi DLS realizzati con Fedora citiamo:
• Pergamos [Pyrounakis2006], Università di Atene4; • NSDL5 (National Science Digital Library);
• eSciDoc6 [Razum2006];
• ARROW7 (Australian Research Repository Online to the World) [Groenewegen2008]
2.1.1 Il modello dei dati
Il modello dei dati di Fedora è essibile poiché permette di esprimere modelli di documento di qualsiasi struttura mediante due entità principali: i digital object e le relazioni. Un digital object (vedi Figura 2.1) è un oggetto digi-tale dotato di un identi catore persistente (PID) e costituito da una o più rappresentazioni (o manifestazioni) dirette, ciascuna delle quali è contenuta in un datastream dell'oggetto. Una rappresentazione diretta può essere un payload oppure un riferimento (URI) ad un le remoto. Le relazioni sono
3Maggiori dettagli disponibili sul sito di Fedora: https://fedora-commons.org/-con uence/display/DSPACE/DSpace+-+Fedora+Commons+Collaboration e nelle wi-ki di DSpace: http://wiwi-ki.dspace.org/index.php/Google_Summer_of_Code_2008_- http://wiki.dspace.org/index.php/Google_Summer_of_Code_2008_-Fedora_Integration 4http://pergamos.lib.uoa.gr/dl/index 5http://nsdl.org 6http://www.escidoc.org 7http://arrow.edu.au
usate per creare associazioni orientate fra due digital object e sono dotate di un'etichetta descrittiva che indica la natura dell'associazione. Una rela-zione è de nita come una tripla <Id-soggetto><predicato><Id-oggetto> in cui <Id-soggetto> e <Id-oggetto> sono gli identi catori dei digital ob-ject associati, mentre <predicato> è l'etichetta della relazione che li lega. Il modello dei dati di Fedora prevede alcuni datastream prede niti obbligatori che contengono un le XML ciascuno:
1. Datastream DC per contenere il metadato Dublin Core del digital object;
2. Datastream AUDIT per mantenere le informazioni riguardanti le mo-di che dell'oggetto;
3. Datastream RELS-EXT per memorizzare le relazioni in cui il digital object è il soggetto. In particolare è possibile associare al digital object uno o più oggetti, detti content model, che descrivono la sua struttura e le operazioni che è possibile eseguire, attraverso relazioni etichetta-te con <fedora-model:hasModel>. In tal caso si dice che il digital object è conforme al modello in oggetto. Maggiori dettagli su questa caratteristica del modello dei dati saranno dati nel prossimo paragrafo. In aggiunta ai metadati Dublin Core esistono dei metadati di sistema per ciascun oggetto, ovvero descrizioni gestite dal sistema in maniera trasparente all'utente, come la data di creazione e di ultima modi ca.
Gli oggetti Il modello dei dati di Fedora prevede quattro tipologie di digital object:
FedoraObject Oggetto di base usato tipicamente per aggregare rappresen-tazioni (payload o URI a le remoti). Ogni rappresentazione è contenuta in un datastream dell'oggetto. Oggetti di questo tipo sono associati per mezzo della relazione
<fedora-model:hasModel> all'oggetto speciale di tipo Content-Model di identi catore
fedora-system:FedoraObject-3.0.
ContentModel (modello di contenuto) Descrive la struttura e le operazioni consentite sui digital object ad esso conformi. In particolare, la de nizione della struttura degli oggetti è memorizzata in un ap-posito datastream chiamato
DS_COMPOSITE_MODEL, nel quale il content model dichiara i nomi e i tipi MIME dei datastream che oggetti ad esso confor-mi devono avere. La de nizione delle operazioni avviene invece per mezzo di relazioni con ServiceObject. Oggetti della tipologia ContentModel sono associati per mezzo della relazione
<fedora-model:hasModel> all'oggetto speciale di tipo Content-Model di identi catore
fedora-system:ContentModel-3.0.
ServiceObject Per servizio si intende un componente software che esegue operazioni su richiesta e che espone un'interfaccia che descrive la sintassi di tali operazioni. In Fedora i servizi sono tipicamen-te web service per l'elaborazione di rappresentazioni direttipicamen-te e la produzione dinamica di rappresentazioni virtuali di digital ob-ject. Una rappresentazione virtuale è una rappresentazione crea-ta su richiescrea-ta e non memorizzacrea-ta in un dacrea-tastream dell'oggetto [Fedora2009]. L'associazione dei servizi agli oggetti avviene per mezzo dei ServiceObject, che il modello dei dati di Fedora divide in due tipologie:
ServiceDe nition oggetto che rappresenta l'interfaccia di un ser-vizio. Oggetti di questo tipo sono associati per mezzo della relazione
<fedora-model:hasModel> all'oggetto speciale di ti-po ContentModel di identi catore
Figura 2.2: Entità digitali di Fedora e relazioni per le dissemination ServiceDeployment oggetto che rappresenta l'implementazione di
un servizio, ovvero ne contiene la logica implementan-do le operazioni dichiarate nell'oggetto ServiceDe ni-tion ad esso associato. Oggetti di questo tipo sono associati per mezzo della relazione
<fedora-model:hasModel> all'oggetto speciale di ti-po ContentModel di identi catore
fedora-system:ServiceDeployment-3.0.
Come vediamo in Figura 2.2, l'associazione fra digital object e ServiceObject non è diretta poiché è il ContentModel di un og-getto a dichiarare quali servizi possono essere eseguiti sui digital object ad esso conformi.
Le relazioni La possibilità di creare relazioni dotate di etichette fra i digi-tal object permette la costruzione di gra di oggetti. Fedora fornisce questa funzionalità permettendo di creare un numero arbitrario di relazioni binarie etichettate fra digital object e dette relazioni esterne. Esse sono espresse come triple RDF <soggetto><predicato><oggetto> dove <soggetto> è catore del digital object cui il datastream appartiene, <oggetto> è l'identi- catore di un altro digital object e <predicato> indica il tipo di relazione che intercorre fra essi. L'insieme delle relazioni genera il grafo delle relazioni che Fedora memorizza in una base di dati triple store [Mulgara2009][Kowari2009].
Figura 2.3: Architettura di Fedora
Oltre alle relazioni esterne, Fedora genera in maniera trasparente all'utente altre relazioni, dette interne, che costituiscono un'ulteriore rappresentazione dei metadati di sistema e Dublin Core di ciascun digital object. Per una re-lazione interna la tripla ha come soggetto un identi catore di digital object, come predicato il nome del campo di metadato di riferimento e per oggetto una stringa che contiene il valore del campo speci cato nel predicato. Ad esempio il campo
<dc:author>AuthorName</dc:author>
del record DC di un oggetto con identi catore id1 corrisponde alla tripla <id1><dc:author><AuthorName>.
2.1.2 Architettura
Fedora ha un'architettura client/server basata su servizi. È possibile indivi-duare un core, chiamato Repository Service, che raccoglie i servizi di base e una periferia che comprende i servizi all'esterno del Repository Service.
Il Repository Service è diviso in quattro sottosistemi:
• Sicurezza: si occupa della autenticazione degli utenti e del controllo dell'accesso ai dati e ai servizi;
• Management: si occupa della creazione e manipolazione dei digital ob-ject. In particolare il modulo Registry gestisce un database relazionale in cui sono memorizzati i metadati di sistema e Dublin Core dei digital object;
• Accesso: implementa le operazioni per la ricerca, il discovery di rappre-sentazioni virtuali e l'accesso ai contenuti delle rapprerappre-sentazioni dirette
dei digital object. In particolare il modulo ResourceIndex gestisce il grafo delle relazioni interagendo con una base di dati triple store (sono supportati Mulgara e Kowari). Per dettagli sulla navigazione del grafo si rimanda alla Sezione 2.1.3;
• Storage: si occupa della gestione della memorizzazione dei digital ob-ject. Gli oggetti sono memorizzati come le XML in un formato specia-le, detto FOXML [Davis2008], sul le system del server. Il contenuto di eventuali datastream di un oggetto è memorizzato separatamente dall'oggetto stesso ed un campo dell'XML dell'oggetto indica il path nel le system in cui il payload è stato memorizzato [Fedora2009]. Come mostrato in Figura 2.3, i moduli sono accessibili attraverso interfacce de nite in linguaggio WSDL e che espongono i servizi implementati nel core.
2.1.3 Linguaggio di query
Il grafo delle relazioni mantenuto da Fedora è formato dalle relazioni esterne fra digital object e dalle relazioni interne relative ai metadati Dublin Core e di sistema dei digital object. Fedora permette di eettuare due tipi di ricerche: la ricerca di oggetti su metadati Dublin Core e di sistema, detta ricerca di base, e la ricerca sul grafo delle relazioni nel triple store, detta ricerca RDF. La ricerca di base Una query permette di speci care condizioni in And logico sui valori dei campi dei metadati di sistema e DC e restituisce come risultato la lista degli identi catori dei digital object i cui metadati soddisfano le condizioni. Una condizione ha il formato
<campo><operatore><valore> Gli operatori a disposizione sono:
• =: il valore del campo deve essere uguale a <valore>. Non è possibile usare le wildcard ('*' e '?');
• ~: cerca <valore> all'interno del campo. È possibile speci care wildcard;
• <, >, <=, >=: utilizzabili solo se <campo> e <valore> sono a valori numerici, come interi o date.
La seguente query, per esempio, è formata da due condizioni e trova gli identi catori di tutti i digital object il cui identi catore inizia per demo e
che sono stati creati dopo il 29 Aprile 2008: pid demo* cdate >= 2008-04-29
In particolare, la ricerca di base riguarda i metadati e sfrutta quindi la base di dati relazionale gestita dal sottosistema di Management (vedi Sezione 2.1.2).
La ricerca RDF La ricerca RDF è eettuata sulla base di dati triple store e permette la navigazione del grafo delle relazioni dei digital object. In particolare, è il modulo ResourceIndex del sottosistema di Accesso (vedi Sezione 2.1.2) che si occupa della gestione del grafo delle relazioni. I linguaggi di query disponibili per questo tipo di ricerca sono due: iTQL e SPO.
iTQL La sintassi di base di una query iTQL è della forma: select listaVariabili from db where vincoliSulleVariabili
dove una variabile ha il formato $<stringa>. Tutte le variabili indicate nel-la select devono essere vinconel-late nelnel-la cnel-lausonel-la where. Vediamo un esempio di query sul triple store <#ri>:
select $pid modified from <#ri>
where $pid <fedora-model:hasModel> <fedora-system:FedoraObject-3.0> and $pid <fedora-view:lastModifiedDate> $modified
La query ritorna gli identi catori e la data di ultima modi ca di tutti i digital object che hanno una relazione fedora-model:hasModel con il Con-tentModel di identi catore fedora-system:FedoraObject-3.0, ovvero di tutti i digital object di tipo FedoraObject (vedi Sezione 2.1.1).
Scegliendo opportuni vincoli sulle variabili possiamo ottenere come ri-sultato un sotto-grafo del grafo relazionale. La query seguente mostra il sotto-grafo costituito da tutti i digital object che hanno come ContentModel l'oggetto di identi catore cmodel:ciao:
select $pid $r $cm from <#ri> where $pid $r $cm
and $cm <mulgara:is> <info:fedora/cmodel:ciao> and $r <mulgara:is> <fedora-model:hasModel>
Il predicato <mulgara:is> impone la variabile che lo precede ad avere valore uguale all'elemento che lo segue8.
SPO SPO è un linguaggio RDF semplice che restituisce il risultato come insieme di triple RDF nella forma
<soggetto><predicato><oggetto>
8Ciascuna base di dati triple store de nisce un insieme di predicati utilizzabili all'interno di query, il predicato <mulgara:is> è speci co del triple store Mulgara.
Anche le query hanno la medesima forma: ciascuno dei tre elementi può essere sostituito dal carattere jolly '*' per indicare che il valore dell'elemento può variare. Per esempio una query come la seguente dà come risultato tutte le triple presenti nel triplestore:
* * *
Se si volesse invece avere il sotto-grafo di tutti gli oggetti che hanno come ContentModel l'oggetto di identi catore cmodel:ciao, la query da inoltrare sarebbe:
* <fedora-model:hasModel> <info:fedora/cmodel:ciao>
In maniera analoga possiamo cercare il sotto-grafo degli oggetti che hanno una relazione qualsiasi con l'oggetto di identi catore obj:hello:
* * <info:fedora/obj:hello>
Dierenze tra i linguaggi iTQL e SPO La principale dierenza fra i due linguaggi iTQL e SPO consiste nell'espressività. La sintassi a triple di SPO descritta al paragrafo precedente non permette infatti di esprimere query complesse. Al contrario, iTQL ha un forte potere espressivo consen-tendo di combinare condizioni come si fa solitamente anche con le query SQL e di usare come predicato delle condizioni non solo etichette di relazioni, ma anche predicati de niti dalla base di dati stessa (il triple store Mulgara, ad esempio, mette a disposizione il predicato
texttt<mulgara:before> applicabile a campi che contengono date). Inoltre, le query in SPO restituiscono il risultato sotto forma di triple
<soggetto><predicato><oggetto>, mentre in iTQL il risultato di una que-ry è un insieme di tuple formate dai valori delle variabili elencate nella clau-sola select [Payette2008]. D'altra parte una query in SPO è tipicamente processata più velocemente rispetto l'equivalente in iTQL, per cui nei casi in cui una query può essere espressa in entrambi i linguaggi, SPO è preferibile a iTQL.
2.1.4 Osservazioni
Fedora ore un modello dei dati essibile e non pone nessuna limitazione alla struttura dei modelli di documento. I Content Model sono stati introdotti recentemente nell'architettura di Fedora9 per soddisfare la necessità di
uten-ti e sviluppatori di DLS di manipolare collezioni di oggetuten-ti dalla struttura comune. Tuttavia le informazioni mantenute nei Content Model non sono utilizzate dal sistema per ottimizzare la gestione dei digital object, né per fornire meccanismi per la veri ca di correttezza delle applicazioni.
I ServiceObject rendono facile la personalizzazione delle funzionalità di DLS, permettendo di creare nuovi servizi ed associarli ai digital object come descritto alla Sezione 2.1.1 a pagina 12.
Inoltre la modularità dell'architettura permette di aggiungere o sostituire moduli. Un esempio signi cativo è la possibilità di sostituire il modulo di me-morizzazione prede nito di Fedora basato su le system locale con un modulo di memorizzazione su data grid gestito da SRB (Storage Resource Broker) e iRODS(integrated Rule-Oriented Data System)[DART2009][Zhu2009].
2.2 DSpace
DSpace[Bollini2007] è un progetto nato nel 2000 dalla collaborazione di HP e MIT adesso sviluppato da DSpace Foundation. Numerose università ed enti pubblici utilizzano DLS basati su DSpace per la gestione del materiale utilizzato nelle attività di ricerca, fra i più signi cativi citiamo:
• Earth-prints, Istituto Nazionale di Geo sica e Vulcanologia10, • DSpaceUnipr11, Università di Parma,
• MIT libraries12, Massachusetts Institute of Technology[Smith2003]
2.2.1 Il modello dei dati
Il modello dei dati di DSpace è di tipo rigido, ovvero prede nisce la struttura dei modelli di documento esprimibili. Lo schema in Figura 2.4 mostra la struttura del modello dei dati di DSpace.
Gli oggetti L'entità di base del modello dei dati di DSpace è l'item, un oggetto digitale dotato di un record di metadati Dublin Core e che può appar-tenere ad una o più collection. Un item contiene un insieme di payload orga-nizzato in bundle di bitstream. La Figura 2.4 ci guida nell'analisi dettagliata delle entità che abbiamo introdotto per de nire un item:
Collection collezione di item associata ad una community di utenti. Ogni item deve avere una collezione primaria, tipicamente quella in cui è stato creato, e, opzionalmente, delle collezioni secondarie;
10http://www.earth-prints.org 11http://dspace-unipr.cilea.it 12http://dspace.mit.edu
Figura 2.4: modello dei dati di DSpace
Community comunità di utenti cui appartengono una o più collection. È possibile organizzare una community in sotto-community per ri- ettere l'ordinamento reale di un'organizzazione. Per esempio la community di un'università può essere formata da tante sotto-community quante sono le facoltà. A sua volta la sotto-sotto-community di una facoltà può essere organizzata come insieme delle sotto-community dei suoi dipartimenti;
Bundle contenitore di bitstream. Permette di aggregare più bitstream e di associarli ad uno ed un solo item;
Bitstream contenitore di un payload associato ad un bitstream format che dichiara il tipo MIME del payload memorizzato.
Le relazioni Il modello dei dati di DSpace prevede relazioni prede nite fra le entità (vedi Figura 2.4) ma non ore primitive per la loro creazione personalizzata.
2.2.2 Architettura
L'architettura di DSpace (vedi Figura 2.5) è a tre livelli, ciascuno dei quali modulare.
Figura 2.5: Architettura di DSpace
• Storage: è organizzato in due parti, il gestore delle risorse e quello dei metadati. Il primo si occupa della memorizzazione persistente dei payload contenuti nei bitstream. Il supporto sico di memorizzazione prede nito è il le system, ma in fase di istanziazione del DLS è pos-sibile scegliere un'altra con gurazione, per esempio la memorizzazione su Data Grid con SRB o una con gurazione ibrida le system-SRB. Il gestore dei metadati memorizza invece i metadati DC degli item e i metadati di sistema degli oggetti digitali necessari per il reperimento dei payload, ad esempio il path in cui il payload di un bitstream è stato memorizzato.
inserimento, modi ca ecc) e di gestione delle autorizzazioni degli utenti e delle comunità.
• Applicativo: insieme delle applicazioni utilizzabili dagli utenti. Le ap-plicazioni usano le funzionalità messe a disposizione dal livello di logica per mezzo di API Java. Tali API sono pubbliche ed è perciò possibile espandere il livello applicativo con nuove applicazioni.[DSpace2008]
2.2.3 Linguaggio di query
DSpace ore agli utenti la funzionalità di ricerca full-text sui metadati DC dei digital object e sui contenuti di bitstream grazie ad un indice basato su Lucene13. In particolare il sistema deve essere con gurato a nché il
conte-nuto di bitstream con un particolare formato siano indicizzati. Il linguaggio di query è CQL (Common Query Language), per mezzo del quale è possibile eettuare la ricerca di:
• parole o frasi esatte all'interno dei payload o di speci ci campi di metadati;
• parole simili ad una parola data, detta ricerca fuzzy. In DSpace si può utilizzare in combinazione con la ricerca all'interno di campi, con la sintassi campo:parola . La semantica della query è quella di cercare all'interno del campo indicato i termini simili a parola;
• parole vicine, con la sintassi parola1 parola2 k. La semantica della query è di cercare gli oggetti digitali in cui le due parole indicate sono separate fra loro da al più k parole;
• valori di un campo all'interno di un range. La sintassi è: campo:[parola1 to parola2].
Le condizioni possono essere combinate in una query mediante gli operatori 'OR' ('||'), 'AND'('&&'), 'NOT'('!').
2.2.4 Osservazioni
DSpace è largamente usato come DLMS per la costruzione di DL, soprattutto da parte delle università, per due motivi principali. Innanzitutto perché è un software open-source e la comunità di sviluppatori è molto attiva per garantirne l'a dabilità e migliorarne le prestazioni. Inoltre il modello dei dati
di DSpace supporta concetti che tipicamente una comunità vuole trattare in una DL ed è quindi spesso su ciente a soddisfare le esigenze degli utenti. Quindi, se la rigidità del modello non permette la costruzione di modelli di documento personalizzati, istanziare un DLS pronto per l'uso risulta invece semplice. Visitando infatti le interfacce web dei DLS basati su DSpace (vedi note al paragrafo introduttivo di questa Sezione) si nota una forte somiglianza sia dal punto di vista estetico sia funzionale. Al contrario, se fosse stato scelto un DLMS essibile come Fedora, gli sviluppatori avrebbero dovuto implementare un'applicazione speci ca per il modello di documento.
2.3 Altri DLMS
Nelle sezioni precedenti abbiamo illustrato in dettaglio i sistemi Fedora e DSpace ma, per completare la descrizione dello stato dell'arte, è neces-sario eettuare una carrellata dei DLMS più comunemente usati dalle organizzazioni.
OpenDLib (ISTI-CNR) [Castelli2002] è un sistema modulare distribui-to per il suppordistribui-to alla realizzazione di applicazioni per Digital Library. Il sistema fornisce funzionalità che possono essere con gurate e combinate per soddisfare le diverse esigenze delle comunità delle DL. Il modello dei dati adottato è abbastanza essibile da permettere la rappresentazione di un'am-pia varietà di modelli di documento, ma non è pienamente espressivo. L'ar-chitettura modulare basata su servizi consente una facile espansione dei DLS aggiungendo dinamicamente nuovi servizi. Fra le varie funzionalità interes-santi, si nota la capacità del sistema di importare metadati da le o attraver-so vari protocolli standard. Inoltre, il sistema permette l'accesattraver-so ai metadati importati e memorizzati attraverso interfacce OAI-PMH, ponendosi di fatto come gateway OAI-PMH nei confronti di sorgenti di dati esterne che non sono dotate di tale funzionalità.
GreenStone (NZDL Project) [Witten2000] è un sistema che supporta la realizzazione di DLS nalizzati alla memorizzazione e alla presentazione di collezioni di oggetti digitali. I DLS realizzati con GreenStone sono poco per-sonalizzabili, poiché il sistema è stato progettato per essere semplice da usare anche da utenti poco esperti, a discapito della essibilità. Il sistema permette di memorizzare contenuti digitali nei formati più comuni e di associarli a re-cord di metadati anche personalizzati. Il modello dei dati è comunque rigido poiché la struttura delle collezioni che è possibile creare è pre ssata. Tra le
funzionalità disponibili citiamo la ricerca full-text sul payload ed i metadati degli oggetti digitali e la compatibilità OAI-PMH.
EPrints (JISC) [Millington2007] è un sistema per la gestione di DL orien-tate al lavoro scienti co ed è infatti molto utilizzato per la realizzazione di repository istituzionali. Il modello dei dati permette una forte personalizza-zione di modelli di documento per applicazioni nel dominio dello studio e della ricerca, ma non è adatto alla rappresentazione di entità che appartengono a contesti diversi da quello scienti co. I DLS basati su DSpace sono facilmente istanziabili e personalizzabili mediante l'uso di plugin. L'implementazione dei plugin avviene per mezzo di API in linguaggio Perl ed il sito internet di EPrints14 mette a disposizione plugin pronti per l'uso che
implementa-no operazioni tipicamente desiderate dalle DL, ad esempio l'importazione ed esportazione di metadati. Fra le funzionalità prede nite oerte all'utente troviamo la ricerca full-text dei documenti e l'interoperabilità con altre DL mediante OAI-PMH. È invece in fase di sviluppo una nuova componente del sistema per l'accesso agli oggetti digitali via web service.
CDS Invenio (CERN) [Pepe2005] noto no al 2006 come CDSware (CERN Document Server Software), è un DLMS che consente di realizzare sistemi compatibili con OAI-PMH per la gestione di collezioni di documenti scien-ti ci. In particolare il sistema utilizza il framework CDS InDiCo15 per la
gestione di documenti all'interno di eventi quali meeting e conferenze. L'ar-chitettura di CDS Invenio è modulare ed il sistema permette l'estensione e la personalizzazione di ogni modulo. Il modello dei dati prevede che gli oggetti digitali siano accompagnati da metadati nel formato MARC 2116. È
comun-que possibile implementare modelli di documento che utilizzano un diverso formato di metadati (ad es. Dublin Core, ISO2709, RFC1807) in quanto il sistema mette a disposizione un modulo per la conversione dei record di metadati in formato MARC 21. Fra le funzionalità di rilievo citiamo la ri-cerca di documenti in base a condizioni combinate su metadati, full-text e citazioni.
Marian DL Generator [DLRL] [Fox2002] è un sistema di indicizzazione, ricerca e recupero dell'informazione ottimizzato per le DL sviluppato in Java e C presso il Digital Library Research Laboratory (DLRL) della Virginia Tech University a partire dal 1992. Il progetto di Marian DL Generator è
14http://www.eprints.org
15http://cdsware.cern.ch/indico/index.html 16http://www.loc.gov/marc/
stato abbandonato ancora incompleto dal DLRL, nonostante ciò merita di essere brevemente descritto poiché è uno dei pochi sistemi essibili progettati a noi noto.
Marian DL Generator permette di descrivere modelli di documento per mezzo di le XML, grazie ad un insieme di tag derivati dal linguaggio dichia-rativo 5SL (5 Scenario Language). Tale linguaggio permette di modellare arbitrariamente le entità payload, metadato e relazione. Dopo che lo svilup-patore ha creato i le XML che descrivono i compound object che una DL vuole trattare, Marian DL Generator li analizza e genera in automatico le classi Java con la struttura adattata a rappresentare le entità speci cate nei le XML. Gli oggetti digitali sono quindi rappresentati all'interno del sistema con istanze delle classi generate.
L'obiettivo di Marian era quello di sfruttare la dichiarazione statica della struttura dei compound object al ne di fornire agli sviluppatori di DLS un supporto per la realizzazione di applicazioni. L'uso di le XML per la de nizione delle strutture, però, pone dei limiti alle funzionalità del sistema, ad esempio l'impossibilità di modi care a tempo di esecuzione la struttura di un'entità.
Capitolo 3
Doroty
In questo Capitolo si presenta il sistema Doroty (Digital Object RepOsitory with Types). In particolare, la Sezione 3.1 ne illustra le motivazioni, mentre le Sezioni 3.2 e 3.3 ne descrivono il modello dei dati e l'architettura.
3.1 Motivazioni
Nel Capitolo 1 abbiamo de nito un DLMS come un sistema di gestione di dati orientato alle DL, ovvero un sistema software il cui modello dei dati ore primitive per la gestione di entità che tipicamente si trattano in una DL. DLMS con modello dei dati essibile hanno il vantaggio di permettere la gestione di modelli di documento la cui struttura risponde pienamente ai requisiti di una comunità e lo svantaggio di richiedere alti costi di imple-mentazione e manutenzione delle applicazioni. Doroty si pone l'obiettivo di adottare un modello dei dati essibile e di ridurre i costi indotti da tale scelta introducendo la nozione di tipo come supporto allo sviluppo e alla manuten-zione di DLS. In particolare il modello dei dati su cui si basa Doroty è stato progettato per essere:
1. minimale: è costituito solo dalle primitive necessarie a garantirne la essibilità;
2. basato su tipi: permette di creare un modello di documento de nendo staticamente la struttura dei compound object che lo costituiscono; dove il termine tipo è da considerarsi nell'accezione tradizionale delle basi di dati [Albano1997]:
Def. (Tipo). Descrizione astratta di ciò che accomuna un insieme di entità omogenee (della stessa natura), esistenti o possibili.
In questo contesto, lo sviluppatore che intende implementare un DLS ba-sato su Doroty deve de nire i tipi che descrivono la struttura del model-lo di documento che la DL vuole trattare. Grazie alle informazioni sulla struttura, Doroty è in grado, ad esempio, di ottimizzare la memorizzazione dei payload di uno speci co formato MIME e di supportare lo sviluppatore nell'implementazione di applicazioni corrette [Candela2009a].
3.2 Il modello dei dati
Il modello dei dati di Doroty è composto da due livelli: modello di basso livello (Sezione 3.2.1) e di alto livello (Sezione 3.2.2). Il modello di basso livello comprende un insieme minimale di primitive per la rappresentazione di compound object. Il modello di alto livello comprende primitive che co-stituiscono per i progettatori zucchero sintattico su quello di basso livello, cioè non aumentano l'espressività del modello dei dati, ma sempli cano la realizzazione di modelli di documento, modellando entità che una tipica DL vuole manipolare: come documenti multimediali, aggregazioni, annotazioni.
3.2.1 Modello di basso livello
Le primitive Il modello dei dati prevede tre tipologie di entità:
Type un tipo de nisce la struttura e gli operatori di entità Object. Ogni tipo è dotato di un nome, unico nel sistema, che lo identi ca. I tipi base con cui è possibile modellare la struttura di oggetti sono: Atom tipo per oggetti semplici dotati di un valore, ad
esem-pio numeri, stringhe, le, riferimenti a le (URN); Relation tipo per oggetti che rappresentano relazioni binarie
etichettate fra oggetti appartenenti a due Set;
Structure tipo per oggetti che sono una descrizione di altri og-getti, ovvero metadati;
Object tipo speciale cui tutti gli oggetti esistenti apparten-gono.
Set un Set è istanza di un Type e contenitore di Object univocamente identi cabile nel sistema per mezzo di un nome. In particolare la struttura degli Object contenuti in un Set è quella de nita dal Type da cui il Set è stato istanziato. In questo senso, un Set è il tipo concreto degli oggetti in esso contenuti, mentre un Type è il
tipo astratto degli oggetti contenuti in un Set istanziato da quel Type;
Object un Object è un oggetto digitale dotato di identi catore apparte-nente ad uno o più Set.
Figura 3.1: Relazioni fra Object, Set e Type
Le relazioni fra Object, Set e Type sono illustrate in gura 3.1. I triangoli rappresentano Set, mentre i cerchi gli Object in essi contenuti. La gura mostra che l'esistenza di un Set di tipo RelationType è legata all'esistenza di altri due Set e che un oggetto di tipo astratto RelationType (r) associa due oggetti di quei due Set, raggiungibili a partire da r mediante le sue proprietà fst e snd.
Un Type può essere istanziato in Set dierenti. Tali Set, pur avendo lo stesso Type, costituiscono diversi tipi concreti per gli oggetti. Nella gura 3.2 l'oggetto o:{A} creato dal Set A è di tipo A::T, mentre l'oggetto o:{B} è di tipo B::T.
Type, Set e Object sono creati e manipolati per mezzo di quattro lin-guaggi: TDL (Type De nition Language) per le operazioni sui Type, DDL (Data De nition Language) per le operazioni sui Set, DML (Data Manipu-lation Language) per le operazioni su Object, DQL (Data Query Language)
Figura 3.2: Istanziare Type, Set e Object
per la ricerca di Object nei Set. I prossimi paragra sono dedicati alle de-scrizioni dei quattro linguaggi, di cui speci cheremo la sintassi e la semantica informale.
Il linguaggio di de nizione dei tipi (TDL - Type De nition Langua-ge) Il TDL è il linguaggio che permette di creare nuovi tipi, speci cando la semantica e la struttura che gli oggetti dei tipi creati devono rispettare. Nel-l'attuale implementazione, l'equivalenza semantica di due tipi coincide con l'equivalenza del nome dei due tipi, mentre l'equivalenza strutturale coinci-de con l'equivalenza sintattica. Si noti che l'equivalenza semantica implica quella strutturale, ma non viceversa. La sintassi del TDL è de nita dalla grammatica in Tabella 3.1.
• Type myType = T;
il comando inserisce nell'ambiente una nuova variabile di tipo myType, cioè un nuovo Type di nome myType che de nisce la stessa struttura de nita dal Type T (myType e T si dicono per questo equivalenti strut-turalmente), ma che ha diversa semantica (myType e T non sono perciò equivalenti semanticamente).
• Type atomType = atom(F);
dove F è un formato di le, ad esempio pdf, txt, xml, avi ecc. Il comando crea un nuovo tipo di nome atomType. I Set istanzati a partire da atomType contengono oggetti costituiti da un payload di formato F. • Type structType = struct(D);
dove D ::= [l1:K1,...lk:Kk], ovvero un insieme di proprietà con etichette li e tipo Ki. Il comando crea un tipo di nome structType.
TE ::= Type X = T, TE | T ::= atom(F) | struct(D) | obj | X | rel(A,B,M,TP) | union(A1,...Ak) |
F ::= pdf | xml | avi | other file formats... | int | string | date | boolean | others... M ::= 1:1 | 1:N | N:1 | M:M
TP ::= t:p | p:t | p:p | t:t D ::= [l1:K1,...,lk:Kk] K ::= D
| list(D)
| int | string | others...
Tabella 3.1: Grammatica TDL
I Set istanziati a partire da esso contengono oggetti la cui struttura è quella de nita da D.
• Type relType = rel(A, B, m, tp);
dove A e B sono Set, m e tp la molteplicità e la parzialità della relazione. Crea un nuovo tipo di nome relType, i Set di questo tipo contengono oggetti che rappresentano associazioni fra un oggetto del Set A e uno del Set B.
• Type objType = obj();
dove obj() è il tipo ObjectType, di cui tutti i Type sono specializza-zioni. Set istanziati a partire da objType possono contenere oggetti di qualsiasi tipo astratto.
• Type unionType = union(A1, A2, ..., An);
dove Ai sono Set. Set istanziati da un tipo unione possono contenere oggetti che appartengono ai Set indicati nei parametri al momento del-la de nizione del tipo. Un set di tipo unionType può cioè contenere oggetti che appartengono ai set Ai.
Il linguaggio per la de nizione dei dati (DDL - Data De nition Language) Il DDL è il linguaggio che consente di creare e cancellare i Set,
ovvero i tipi concreti istanziati a partire dai tipi de niti mediante il TDL descritto al paragrafo precedente. La grammatica del linguaggio è mostrata in Tabella 3.2.
C ::= C;C
| Set A = create T(pars) | delete A
Tabella 3.2: Grammatica DDL Sia T un tipo già de nito:
• Set A = create T(pars);
dove A è il nome unico nel sistema che identi ca il Set e pars è una lista di parametri che dipende dal tipo T. Per esempio se T = atom(F), è possibile speci care un parametro che indica se il payload di formato F degli oggetti di A deve essere memorizzato localmente o referenziato per mezzo di una URN. Il comando crea un Set vuoto di nome A e tipo concreto T.
• delete A;
Il comando cancella il Set dal sistema. Allo stato attuale della proget-tazione assumiamo che la cancellazione di un Set comporti la cancella-zione di tutti gli Object in esso contenuti ed i Set di tipo RelationType in cui A era coinvolto. Non si esclude comunque la possibilità futura di consentire l'attuazione di politiche di cancellazione diverse.
Il linguaggio per la manipolazione dei dati (DML - Data Manipula-tion Language) Il DML consente la manipolazione di oggetti all'interno di Set. Le operazioni possibili (vedi la grammatica in Tabella 3.3) sono la creazione, importazione, cast, cancellazione e modi ca di oggetti.
• Object o = new A(pars);
dove A è un Set e pars è una lista di parametri che dipendono dal tipo del Set. Il comando crea un nuovo Object con identi catore unico nel sistema. L'identi catore dell'Object creato viene quindi assegnato alla variabile o. Vediamo, in base al tipo astratto del Set, quali possono essere i parametri per istanziare correttamente un nuovo Object. Sia T il tipo di A, allora:
se T = atom(F) allora pars è una coppia (URN, toUpload) dove URN è il riferimento al le di formato F e toUpload è un valore di
C ::= C;C | TE
| Object x = new A(pars) | A.import(o) | A.cast(o) | A.drop(o) | A.update(o, pars) |{C} | Tabella 3.3: Grammatica DML
tipo bool che indica se il payload del le riferito dalla URN deve essere copiato nel sistema o trattato come sorgente di dati esterna; se T = struct(D) allora pars sono i valori da associare ai campi
speci cati in D;
se T = rel(Set1, Set2, m, tp) allora pars è una coppia di og-getti (fstObj, sndObj) dove fstObj è di tipo concreto Set1 e sndObj è di tipo concreto Set2. In questo caso o è creato se e solo se la sua creazione non viola i vincoli di molteplicità m e di parzialità tp. Nel caso la creazione dell'oggetto avvenga all'inter-no di una transazione, i controlli sui vincoli soall'inter-no rimandati dopo l'ultimo comando della transazione stessa. Una volta che o è sta-to creasta-to, con la sintassi o.fst si recupera l'oggetsta-to fstObj, con o.snd l'oggetto sndObj (vedi la grammatica DQL in Tabella 3.7). se T = union(A1, A2,...,An) allora pars è una coppia (params,
Ai) dove params sono i parametri necessari per la creazione del-l'oggetto e dipendono dal tipo di Ai. Ai è il Set del tipo unione in cui l'oggetto verrà creato.
• A.import(o); e A.cast(o);
dove A è un Set e o:{B}. L'eetto di entrambi i comandi è quello di aggiungere o nel Set A, cioè di modi care il tipo concreto dell'oggetto da o:{B} a o:{B,A}, tuttavia le due operazioni sono applicabili solo se i tipi di A e B rispettano particolari relazioni di equivalenza.
L'operazione di importazione permette il passaggio di oggetti fra Set i cui tipi sono equivalenti semanticamente, mentre l'operazione di cast permette il passaggio di oggetti fra Set i cui tipi sono equivalenti strut-turalmente. Dato che l'equivalenza semantica tra tipi implica quella
1 Type Dog = struct([name:string,race:string]); 2 Type Cat = struct([name:string,race:string]); 3 Type Turtle = struct([name:string,age:int]); 4 Set myDogs = create Dog();
5 Set myCats = create Cat(); 6 Set yourCats = create Cat(); 7 Set myTurtles = create Turtle();
8 Object aDogOfMine = new myDogs([Fido,Beagle]); 9 Object aCatOfMine = new myCats([Romeo,Bengala]); 10 yourCats.import(aCatOfMine);//OK
11 myDogs.import(aCatOfMine);//NO 12 myDogs.cast(aCatOfMine);//OK 13 myTurtles.import(aCatOfMine);//NO 14 myTurtles.cast(aCatOfMine);//NO
Tabella 3.4: Esempi d'uso degli operatori di cast e import
strutturale, l'operazione di importazione non è possibile fra Set i cui tipi sono equivalenti strutturalmente ma non semanticamente. Il rap-porto strutturale e semantico di due Set può essere speci cato in termini di relazioni di congruenza e compatibilità, le cui de nizioni formali sono fornite in [Candela2009b].
Def. (Relazione di congruenza fra Set). Due Set sono in relazione di congruenza se i loro tipi sono equivalenti seman-ticamente, cioè se i loro tipi sono stati creati per modellare la medesima entità.
Def. (Relazione di compatibilità fra Set). Due Set sono in relazione di compatibilità se i loro tipi sono equivalenti strut-turalmente, cioè se i loro tipi sono stati creati per modellare entità con la medesima struttura.
Allo stato attuale di Doroty, possiamo dire che due Set sono equivalenti semanticamente se sono stati creati a partire dallo stesso Type e che, in tal caso, essi sono anche equivalenti strutturalmente.
L'operazione di importazione A.import(o); è possibile se e solo se il Set A è in relazione di congruenza con il Set B. L'operazione di cast A.cast(o); è possibile se e solo se il Set A è in relazione di compatibilità con il Set B.
In Tabella 3.4 è mostrato un esempio di uso degli operatori import e cast. Alle righe 1-3 si creano tre tipi: Dog, Cat e Turtle. I primi due sono in relazione di compatibilità poiché entrambi de niscono una struttura equivalente ( struct([name:string,race:string])) ma se-mantiche distinte (ovviamente i tipi Dog e Cat modellano entità di natu-ra diversa, rispettivamente cani e gatti). Il tipo Turtle de nisce invece una struttura, e quindi una semantica, non equivalente a quella dei Ty-pe Dog e di Cat. I Set myCats::Cat e yourCats::Cat (righe 5-6) sono in relazione di congruenza fra loro, poiché creati a partire dallo stesso tipo, ma non lo sono con i Set myDogs::Dog e myTurtle::Turtle. È perciò consentito importare l'oggetto aCatOfMine del Set myCats::Cat nel Set yourCats::Cat (riga 10) ma non in myDogs::Dog (riga 11) o in myTurtle::Turtle (riga 13). L'operazione di cast è consentita solo fra i Set di tipo Dog e Cat poiché compatibili (righe 12 e 14).
• A.drop(o);
dove A è un Set, o un Object che appartiene ad A. L'eetto del comando è la rimozione dell'oggetto dal Set. Allo stato attuale della progettazio-ne assumiamo che la cancellazioprogettazio-ne di un Object da un Set provochi la rimozione dell'oggetto dal sistema, anche se o appartiene ad altri Set, e che siano cancellate anche gli oggetti relazioni in cui era coinvolto. Non escludiamo la possibilità di consentire in futuro la de nizione di politiche di cancellazione di Object personalizzate.
• {C}; dove C è una sequenza di comandi da eseguire in una transazione. Il termine transazione è da considerarsi nel senso tradizionale delle basi di dati:
Def. (Transazione). Sequenza di azioni di lettura, scrittu-ra ed elaboscrittu-razione dei dati per la quale il DMS assicuscrittu-ra le proprietà di atomicità, consistenza, isolamento e durabilità. Se all'interno della transazione è presente la creazione o cancellazione di Object da Set di tipo RelationType, i controlli sui vincoli di molteplicità e parzialità della relazione sono eseguiti subito dopo l'ultimo comando nella transazione ma subito prima del suo commit.
Esempio Supponiamo di voler implementare un modello di documento per l'insieme di proceedings di una conferenza. In questo contesto, un procee-ding è inteso come una collezione di articoli associata ad un record di me-tadati Dublin Core. Un articolo è un documento in formato PDF che può eventualmente essere associato ad un record di metadati Dublin Core.
1 //TDL: DEFINISCO I TIPI PER PROCEEDINGS, ARTICOLI E METADATI 2 Type ProceedingType = obj();
3 Type ArticleType = atom(PDF);
4 Type DCType = struct([DCField1:type1,...,DCField15:type15]); 5 //DDL: CREO I SET
6 Set Proceedings = create ProceedingType; 7 Set ProceedingsDC = create DCType;
8 Set Article = create ArticleType; 9 Set ArticleDC = create DCType; 10 Set ProceedingsMetadata =
11 create rel(Proceedings,ProceedingsDC,1:1,t:t);
12 Set ArticleMetadata = create rel(Article,ArticleDC,1:1,p:t); 13 Set ProcArticle = create rel(Proceedings,Article,1:n,p:t);
Tabella 3.5: Implementazione di un modello di documento per l'insieme di proceedings di una conferenza.
1 //DML: CREO UN PROCEEDING ED IL SUO RECORD DI METADATI 2 {
3 Object aProc = new Proceedings();
4 Object procDC = new ProceedingsDC(v1,...,v15);
5 Object procDCRel = new ProceedingsMetadata(aProc,procDC); 6 };
7 //DML: CREO UN ARTICOLO, IL SUO RECORD DI METADATI E 8 //LO ASSOCIO AL PROCEEDING
9 {
10 Object anArticle = new Article(URN,payload); 11 Object artDC = new ArticleDC(v1,...,v15);
12 Object artDCRel = new ArticleMetadata(anArticle,artDC); 13 Object procArtRel = new ProcArticle(aProc,anArticle); 14};
Come mostrato in Tabella 3.5, la de nizione del modello di documento avviene in tre fasi:
1. Creazione dei tipi Object, Structure e Atom (righe 2-4) per de nire la struttura delle entità proceeding (ProceedingsType), metadati Dublin Core (DCType) e articoli (ArticleType);
2. Creazione dei Set di tipo Object, Structure e Atom (righe 6-9) a partire dai tipi appena creati (righe 6-9);
3. Creazione dei Set di tipo Relation (righe 10-13) per le relazioni fra proceedings e metadati (ProceedingsMetadata), articoli e metadati (ArticleMetadata) e articoli e proceeding (ProcArticle).
Creati i Set, è possibile popolare la DL creando nuovi oggetti con il linguag-gio DML. Una possibile interazione in DML è mostrata in Tabella 3.6. Nel-la prima transazione (righe 2-6) è creato l'oggetto aProc:{Proceedings}, il corrispondente record di metadati procDC:{ProceedingsDC} e una re-lazione fra di essi (procDCRel:{ProceedingsMetadata}). Quindi con la seconda transazione alle righe 9-14 si crea un oggetto per rappresentare un articolo (anArticle:{Articles}) e lo associamo al record di metadati artDC:{ArticleDC} mediante artDCRel:{ArticleMetadata}. In ne asso-ciamo l'articolo al proceeding con l'oggetto procArtRel:{ProcArticle}. La gura 3.3 descrive gra camente una possibile istanza del modello di documen-to. Gli ovali rappresentano i Set, i cerchi neri al loro interno rappresentano oggetti. Le frecce uscenti da oggetti di tipo RelationType (oggetti appar-tenenti ai Set ArticleMetadata e ProceedingsMetadata e ProcArticle) indicano gli oggetti coinvolti nella relazione.
Il linguaggio di query (DQL - Data Query Language) La grammati-ca del linguaggio è mostrata in Tabella 3.7. Una query Q ritorna un insieme di Object della DL che rispetta i criteri condizionali P e navigazionali L stabiliti da Q.
Il DQL ore tre tipologie di query:
• Target-oriented: Q!L ritorna un insieme di oggetti raggiungibili secondo i criteri condizionali o navigazionali L a partire da un insieme di oggetti iniziale (Q).
• Source-oriented: Q?L ritorna il sottoinsieme dell'insieme di partenza Q formato dagli oggetti che soddisfano i criteri navigazionali e condizionali speci cati da L.
Figura 3.3: Istanza di un modello di documento per proceedings di una conferenza
Q ::= Q!L //query target-oriented | Q?L //query source-oriented
| Q|label //query relation-oriented | label | L ::= L/label | L/* | L//label | L//* | [P]| P ::= (P) | not P | P Bop P | V Con V
| inSet(A) //appartenenza di un Object al Set A
| ofType(T) //conformità di un Object al tipo astratto T | count() Con ::= > | < | = Bop ::= And | Or V ::= Des | At Des ::= [l1:Val,...,lk:Val] Val ::= De | {De,...De} | v At ::= .label At | Tabella 3.7: Grammatica DQL
• Relation-oriented: Q|L ritorna l'insieme degli oggetti relazione nel Set identi cato da L che sono raggiungibili dagli oggetti del Set iniziale Q. I criteri condizionali (vedi la produzione P in Tabella 3.7) sono espressi come predicati logici nei quali possono comparire espressione booleane e operatori speciali per gli oggetti che veri cano l'appartenenza ad un Set (inSet(A)) e la conformità della struttura ad un tipo (ofType(T)).
I criteri navigazionali (vedi la produzione L in Tabella 3.7) sono espressi per mezzo degli operatori speciali /label e //label dove label è l'etichetta di una relazione, o meglio il nome di un Set di tipo relazione. La semantica dei criteri navigazionali è ereditata dalle query XPath [XPath], per illustrarla si introducono le seguenti de nizioni:
R con un oggetto obj2 e viceversa se e solo se R è il nome di un Set di tipo relazione (R::rel(pars)) ed esiste un oggetto r:{R} tale che r.fst = obj1 e r.snd = obj2.
Def. (Raggiungibilità di un oggetto). Un oggetto obj1 è rag-giungibile da un oggetto obj2 e viceversa se e solo se esiste un cammino (o path) di oggetti relazioni che, a partire da obj2, porta ad un oggetto obj3 in relazione con obj1.
• A!/label
ritorna gli oggetti in relazione label con oggetti nel Set A. • A?/label
ritorna gli oggetti di A in relazione label con uno o più oggetti. • A!//label
ritorna gli oggetti in relazione label con oggetti raggiungibili da A. • A?//label
ritorna gli oggetti in A dai quali si possono raggiungere oggetti coinvolti in una relazione label.
La wildcard * può essere usata al posto di label con il signi cato qualsiasi etichetta. Vediamo delle query di esempio facendo riferimento al modello di documento per i proceedings di una conferenza descritto a pagina 33:
• Cerca le relazioni raggiungibili dal Set Article attraverso la relazione ProcArticle:
Article|/ProcArticle
• Cerca fra i proceedings quelli che hanno almeno un articolo pubblicato nel 2007:
Proceedings?/(ProcArticles! /ArticleMetadata[year=2007])
• Cerca gli articoli nei Proceedings pubblicati nel 2007: (Proceedings?/ProceedingsMetadata[year=2007])! /ProcArticles
3.2.2 Modello di alto livello
Estensione al TDL Nella sua attuale versione, il modello di alto livello introduce tre nuovi Type, utili per esprimere alcuni dei concetti tipicamen-te usati nel contipicamen-testo delle DL. Altri potranno essere aggiunti in futuro per
rappresentare altre entità ritenute interessanti come documenti versionabili e utenti.
ObjStruct oggetti di questo tipo astratto sono oggetti digitali associati a record di metadati.
Aggregation oggetti di questo tipo rappresentano aggregazioni di oggetti digitali appartenenti ad un dato Set A;
Annotation oggetti di questo tipo rappresentano annotazioni associate ad un oggetto digitale di un dato Set A , ovvero commenti testuali che riguarda l'oggetto;
La grammatica del TDL è estesa con le clausole in Tabella 3.8. T ::= objStruct(T,D,Pt)
| aggregation(A,Tp) | annotation(A) Pt ::= p:t | t:t Tp ::= p:p | t:p
Tabella 3.8: Estensioni al linguaggio TDL
Estensioni al DDL Vediamo come la creazione di Set a partire dai nuovi Type è implementata in linguaggio a basso livello:
• Set A = create objStruct(T, D, Pt);
dove T è un Type, D è uno StructureType. Il comando crea il Set A i cui oggetti hanno la struttura de nita da T e sono associati ad oggetti con la struttura de nita da D. L'implementazione di tale comando in DDL di basso livello è:
{
Set A = create T;
Set DescOfA = create struct(D);
Set ADescRelSet = create rel(A, DescOfA, 1:1, Pt); };
