Il Progetto EULER: un modello per l'integrazione di risorse eterogenee nell'ambito della matematica

Contributo sul tema "L'innovazione tecnologica ed organizzativa per i servizi di biblioteca", presentato in occasione del convegno internazionale di studi "Strumenti e strategie per la costruzione della biblioteca ibrida" (Firenze, 14 febbraio 2001).
 

Abstract

1. Origini, obiettivi ed evoluzione

Gli obiettivi del progetto si possono sintetizzare nei seguenti punti:

• integrazione delle più rilevanti risorse elettroniche nel campo della matematica;
• creazione di un sistema "one stop shopping" oppure seguendo l'evoluzione della terminologia un portale per la matematica;
• adozione di un approccio aperto e scalabile con costi distribuiti e qualità distribuita;
• creazione di un sistema facilmente esportabile ad altri settori disciplinari.

• basi dati bibliografiche;
• OPAC di Biblioteche universitarie;
• riviste elettroniche;
• archivi di pre-print e letteratura grigia;
• risorse di rete controllate e generate automaticamente.

Il progetto ha mantenuto una costante attenzione ai bisogni dell'utenza ed in tutte le sue fasi ha raccolto giudizi e condotto un'attenta ricognizione delle esigenze dei potenziali utenti. Nella fase iniziale è stato messo a punto un questionario dei bisogni informativi con l'intento di disegnare un prototipo realmente corrispondente alle aspettative dei matematici. Il questionario, diviso in due parti, comprendeva le notizie riguardanti le caratteristiche dell’ambiente di lavoro e quelle sulle funzionalità richieste al sistema "one stop shopping" con domande relative alla struttura e all’utilizzo del sistema che il progetto Euler intendeva creare.

Il primo momento di verifica sulla soddisfazione dell'utenza è stata la valutazione della versione alpha, sui giudizi raccolti nel secondo questionario si sono basate le modifiche alla versione Beta, anche quest'ultima oggetto di valutazione dell'utenza, ma stavolta i pareri degli utenti sono interpretati da due specialisti esterni al progetto: l'Università di Amburgo [2] che ha condotto una valutazione sulla "usabilità" del servizio Euler e l'Università di Colonia [3] che ha testato il prototipo sul recupero in termini quantitativi e qualitativi [RIEMAN].

2. I metodi e le tecniche

Tenuto conto che i record dei partner differivano notevolmente gli uni dagli altri come sintassi e semantica dei campi così come variavano i linguaggi di interrogazione e i protocolli di accesso, per seguire questo obbiettivo è stato scelto un approccio basato sull'adattamento delle risorse ("resource adaptation") [JOST], che ha portato alla conversione dei dati originali nel profilo EULER-DC (cfr. Appendice 1), una sorta di "linguaggio di commutazione", realizzando una "normalizzazione dei dati" che ha aumentato la qualità della ricerca e le potenzialità di recupero da parte dell'utenza.

Sulla base di questa scelta lo sviluppo si è articolato secondo tre assi d'integrazione: risorse, accesso e servizi.

2.1 Integrazione delle risorse

Le risorse dei diversi partner possono definirsi eterogenee per:

a) Tipologia
• Risorse primarie/secondarie
• Controllate/non controllate
b) Standard di catalogazione/descrizione usati;
c) Schemi di classificazione (es. MSC, DDC, LCSH) e soggettazione;
d) Uso o non uso delle parole chiave;
e) Lingua.

È stata anche sperimentata con successo l'inclusione di dati resi disponibili da partner esterni al progetto quali MPRESS [MPRESS] e l'archivio e-Print arXiv.org [LANL].

Nel processo di mappatura i partner hanno convertito i propri elementi descrittivi nei 15 elementi della specifica Dublin Core [DC] integrati dei campi aggiuntivi che sono stati ritenuti necessari per descrivere alcune delle risorse presenti che non trovavano corrispondenza in nessuno degli elementi del DC.

Vista la diversificazione dei dati, il processo di integrazione si è realizzato parzialmente nella mappatura nel profilo EULER-DC ed in altri casi, quali la mancata corrispondenza o assenza di schemi di classificazione, sono stati creati una serie di strumenti informativi che nei diversi momenti della ricerca offrono all'utente la risposta immediata su come sono stati ottenuti i suoi risultati. Dalle maschere è possibile conoscere la tipologia di dati del fornitore selezionato, statistiche sui risultati ottenuti.

2.2 Integrazione dell'accesso

Il sistema propone un'interfaccia unica di accesso a tutte le risorse gestite con diverse modalità di consultazione:

• ricerca base (tipo quella dei comuni motori di ricerca di Internet);
• ricerca avanzata (più dettagliata ed ispirata agli OPAC ed alle basi dati bibliografiche);
• browse degli indici associati ai principali canali di ricerca;
• browse dello schema di classificazione MSC.

2.3 Integrazione dei servizi

Terzo momento del lavoro di integrazione portato avanti è stato fornire un servizio comune nel rispetto delle potenzialità di ognuno sotto un comune denominatore: il servizio EULER.

I servizi si possono sintetizzare in quattro gruppi:

• ricerca bibliografica;
• localizzazione nei cataloghi;
• visualizzazione documenti a testo pieno;
• document delivery.

Il sistema Euler, dopo aver fornito la lista dei record risultato di una certa "query" la localizza negli archivi di origine abbandonando l'ambiente integrato per spostarsi in "locale" da dove si accede ai servizi offerti da diversi fornitori: accesso al full text, fornitura documenti e prestito interbibliotecario. Euler non interferisce con l'ambiente "locale" e l'integrazione si mantiene a livello di schede descrittive comuni.

2.4 Caratteristiche tecniche dell'interoperabilità

2.4.1 Architettura del sistema

Il sistema [BERG] è costituito da un insieme di componenti interoperanti organizzati secondo un'architettura client/server che prevede tre livelli funzionali (cfr. Figura 2):

• livello utente - browser WWW standard (es. Netscape Navigator, MS Explorer, Opera);
• livello fornitore del servizio - un server applicativo centralizzato denominato "EULER engine" che opera come gateway tra gli utenti e i fornitori delle informazioni;
• livello fornitori d'informazione - un insieme di database server distribuiti.

La EULER engine è l'unica componente visibile agli utenti finali verso i quali espone le interfacce di ricerca e visualizzazione dei dati, realizzate tramite maschere e pagine HTML generate dinamicamente, con un uso molto limitato di funzioni JavaScript.

Ogni richiesta (interrogazione e browse) formulata da un utente viene "tradotta" dalla EULER engine nella sintassi Z39.50 e inviata simultaneamente a tutti i database server che ospitano le collezioni selezionate. Ottenuta la risposta da ciascun server remoto, questo gateway preleva dai result-set generati un certo numero di record che vengono fusi operando sulla chiave di de-duplicazione, ordinati in base al criterio scelto tra quelli previsti, convertiti in un elenco di riferimenti bibliografici codificati in HTML ed inviati come risposta all'utente.

È responsabilità della EULER engine richiedere ulteriori record ai singoli database server in base al numero di "hits" visualizzabili richiesti dall'utente (per difetto 20) e ai duplicati riconosciuti. La pagina contenente la lista dei risultati mostra anche il numero totale dei record selezionati dall'interrogazione e la loro ripartizione per ciascun database interrogato. L'utente può proseguire chiedendo altri record o può scorrere avanti e indietro tra quelli proposti per visualizzarne il dettaglio (full record).

La prospettazione analitica di un record comprende gli elementi definiti nello schema EULER-DC e realizza l'integrazione con i servizi supportati dai fornitori delle informazioni, infatti contiene i link (URL) per accedere alle risorse originali (es. record in un OPAC, pagina Web, testo pieno di un pre-print, etc.) e per richiedere servizi ai "proprietari" della risorsa (es. link alla maschera di richiesta di document delivery di un catalogo).

Nel prototipo, operativo dal mese di agosto 2000, i componenti tecnologici che implementano l'architettura descritta sono:

• i programmi "ad-hoc" che ogni partner, detentore di dati originali, ha sviluppato per estrarre e/o generare dalle proprie collezioni i dati pertinenti la matematica e per convertirli (cfr. par. 2.1) secondo lo schema di metadata EULER-DC in sintassi XML;
• ISO-tool, il programma di post-elaborazione dei metadata per la generazione della chiave di duplicazione e la conversione dei caratteri diacritici;
• Zebra Indexer per la creazione e l'indicizzazione delle basi di metadata in formato XML e Zebra Server che opera come server Z39.50, software di dominio pubblico della società danese Index Data [ZEBRA];
• Europagate HTTP/Z39.50 gateway [EUROP] e procedure in linguaggio TCL che compongono la EULER engine.

Due aspetti rilevanti per fornire agli utenti una visione integrata e omogenea delle risorse sono: i) il trattamento dei caratteri speciali (diacritici, lettere accentate, simboli matematici) e ii) il riconoscimento dei duplicati esistenti tra i record forniti da uno o più database (duplicati locali e non-locali). Queste funzioni sono state in parte affidate al programma ISO-tool che opera sui record di metadata originali e genera un insieme opportunamente modificato che poi viene caricato ed indicizzato nel database locale (server Z39.50):

• Trattamento dei caratteri speciali. Le codifiche previste per i record originali sono ISO-Latin-1, HTML (Character Entity Set) e LaTeX. Gli elementi di tipo Creator, Contributor, Title, Subject e Description di ogni record vengono trattati in modo da generare per ciascuno un elemento (campo) con la codifica HTML, utilizzato per la visualizzazione da parte della EULER engine, e fino a tre elementi (uno con la codifica normalizzata a 7-bit ASCII, uno in ISO-Latin-1 e uno in 7-bit ASCII con l'uso dello spelling tedesco ae/oe/ue per gli umlauts) usati nei database locali per l'indicizzazione (cfr. Appendice 2), in modo che l'utente possa immettere le parole di ricerca secondo una delle tre precedenti convenzioni.
• Eliminazione dei duplicati. Nel contesto in oggetto l'eterogeneità delle risorse e delle sorgenti d'informazione non consentono l'uso di numeri identificativi standard tipo ISSN e ISBN. Inoltre, la distribuzione delle basi dati non permette l'elaborazione dell'intera collezione per costruire liste di duplicati. Pertanto l'approccio seguito si basa sulla generazione di una "chiave" di de-duplicazione calcolata ed aggiunta a ciascun record. Questa chiave è una sequenza di 5x4 caratteri in cui ciascuna quartina viene derivata dagli altri elementi del record, di norma anno di pubblicazione, autore personale e titolo, secondo opportune regole [JOST]. Grazie a questa chiave, la EULER engine riconosce eventuali record duplicati per i quali propone all'utente un solo esemplare ed i link che consentono di visualizzare in modo analitico ogni singolo record.

Il database locale per EULER viene periodicamente alimentato da un programma che esegue un'interrogazione sulla base dati dell'OPAC e converte ciascuno dei record selezionati secondo lo schema EULER-DC, in formato XML, usando gli elementi e i relativi tag mostrati nella tabella dell'Appendice 1.

Si tratta di una query complessa che è stata predisposta dopo una fase di test e analisi al fine di selezionare i record bibliografici attinenti le scienze matematiche dall'OPAC che contiene i record bibliografici di tutte le biblioteche dell'Ateneo. Infatti, dato che solo il 50% dei record in catalogo ha un codice di classificazione, non è possibile selezionare questi record operando esclusivamente sui codici Dewey.

Pertanto la query utilizza anche il macro-canale di ricerca (i.e. indice) parole-chiave, che combina titoli, soggetti e collane, per estrarre tutti i record che contengono almeno una parola tra quelle presenti in una lista di termini opportunamente selezionati.

Dato che la struttura base del record dell'OPAC è di tipo UNIMARC, la conversione operata è indirettamente una mappatura da UNIMARC a Dublin Core. Successivamente il file generato viene processato dal programma ISO-tool per generare la chiave di de-duplicazione e per il trattamento dei diacritici (generazione degli elementi da indicizzare). In Appendice 3 è riportato un esempio di record convertito per alimentare il database EULER locale.

3. Riflessioni e valutazioni critiche di fine progetto

Il progetto ha concluso la sua attività ottenendo un giudizio estremamente positivo sia per la sua gestione complessiva che per gli aspetti metodologici e tecnici [CONS].

I principali risultati conseguiti sono:

• dimostrazione che l'idea iniziale del sistema "one-stop-shop" era perseguibile;
• piena integrazione di risorse eterogenee attraverso la realizzazione e l'utilizzo di un servizio funzionante basato sulla cooperazione tra istituzioni diverse in ambito europeo;
• definizione di un modello di interoperabilità incentrato su un'architettura distribuita e un insieme di standard internazionali consolidati (HTTP, Z39.50, DC).

Alcune caratteristiche peculiari sono il "cross browsing", il "cross searching" e l'dentificatore di de-duplicazione che permettono di operare in modo uniforme e integrato sulle diverse collezioni di metadata. Attraverso l'interfaccia unificata l'utente può per esempio accedere ad un pre-print, trovare il testo dell'articolo pubblicato e consultarne una recensione.

Come descritto nel par. 2.4 il modello definito si basa su un'architettura distribuita, sul pre-trattamento dei dati originali e sull'adozione di standard comuni a tutti i database dei fornitori d'informazione (schema dei metadata EULER-DC, formato di caricamento e indicizzazione XML, codifiche dei caratteri speciali, profilo EULER per Z39.50).

In particolare, la specifica EULER-DC è un punto di riferimento per la descrizione omogena e l'interoperabilità di risorse eterogenee per tipologia e per i sistemi che le ospitano (OPAC, collezioni bibliografiche, cataloghi di pre-print, pagine web, etc.). L'adozione di standard compatibili con quelli internazionali e l'uso di strumenti software di dominio pubblico hanno facilitato la messa in opera del servizio. Queste scelte rendono possibile l'applicazione del medesimo approccio anche a discipline diverse dalla matematica.

3.2 Problemi aperti e limiti riscontrati

Un altro risultato rilevante del progetto è stato il continuo confronto con le realtà esterne che si stavano sviluppando, attraverso lo studio analitico dei problemi tecnici, funzionali e organizzativi impliciti nella creazione di servizi con le caratteristiche di EULER. L'accurata analisi delle risorse compiuta nella prima metà del progetto e la prolungata fase di sperimentazione della EULER engine hanno infatti permesso di individuare alcuni aspetti critici indipendenti dall'area di applicazione: i limiti del modello distribuito, la semplicità dell'interfaccia di ricerca, maggiore integrazione dei servizi, ampliamento delle risorse disponibili e nuovi tipi di servizi.

• Limiti del modello distribuito e modelli alternativi.

Una delle aspettative più sentite dall'utenza verso un servizio come EULER è la capacità di fornire risposte alle interrogazioni degli utenti con un tempo di risposta basso. L'architettura distribuita su cui si basa il sistema può generare tempi di attesa lunghi quando uno dei database server è fuori servizio o il percorso di rete che lo collega al motore centrale risulta saturo [4]. Del resto il tempo di risposta tende ad aumentare con il crescere dei database server remoti da interrogare simultaneamente. Si tratta di un vincolo strutturale per la scalabiltà del sistema che può essere risolto abbandonando il modello decentralizzato.
• Un primo approccio consiste nel ridurre il numero di server da interrogare creando dei server intermedi, per esempio su base regionale, in cui indicizzare i dati dei fornitori d'informazione di quella regione. Soluzioni analoghe sono previste anche in altri modelli di architetture distribuite [DIENST, DNER] sotto forma di "index server" o "proxy content provider".
• Un approccio completamente diverso prevede la creazione di un unico database centrale che potrebbe essere alimentato tramite il riversamento periodico dei metadata da parte dei fornitori d'informazione o con un protocollo di cattura (harvesting) innescato dal motore centrale [DIENST, OAI]. In quest'ultimo caso la conversione dei dati locali nel formato di metadata formalizzato sarebbe ancora a carico dei fornitori d'informazione, mentre nell'altro potrebbe essere effettuato per tutti centralmente.

• Interfaccia di ricerca.

Quella sviluppata si articola in una maschera di ricerca base, una avanzata e una per il browse. La scelta dei campi e la terminologia usata sono stati largamente discussi e revisionati. Tuttavia la sperimentazione da parte di ricercatori, studenti e bibliotecari e le valutazioni sulla "usability" [RIEMAN] condotte da un team di esperti della Università di Amburgo hanno evidenziato che gli utenti sono ormai abituati all'uso dei motori di ricerca Internet. Questo determina la preferenza per interfacce con poca informazione testuale e pochi campi, che consentano la formulazione di interrogazioni semplici, con la conseguente riduzione dei canali di ricerca previsti e quindi anche un minor numero di indici nei database server. Il disegno di una interfaccia utente più mirata e curata esteticamente sarà uno dei primi obbiettivi del passaggio dalla fase sperimentale alla costituzione di un servizio effettivo.
 
• Integrazione dei servizi.

I partner del progetto hanno deciso di fornire agli utenti solo i riferimenti (link) per accedere ai servizi locali (es. maschera per la richiesta di document delivery e prestito interbibliotecario, accesso al testo pieno di pre-print o riviste). Questa scelta è stata determinata dalla volontà di preservare un'autonomia locale dei fornitori di dati e servizi proprio per le comprensibili difficoltà di uniformare le tipologie di servizi dei fornitori d'informazione e di armonizzare le diverse normative esistenti presso le istituzioni coinvolte. D'altra parte è evidente che per gli utenti sarebbe di estrema utilità disporre di un'interfaccia unica anche per la richiesta dei servizi e per l'accesso alle informazioni primarie. Il raggiungimento di questo obiettivo dipende largamente dalla stipula di accordi tra le istituzioni coinvolte al fine di estendere il livello di cooperazione dalla condivisione/aggregazione dei metadata alla interoperabilità dei servizi per i rispettivi bacini di utenza.
 
• Ampliamento delle risorse e dei servizi.

L'allargamento della cooperazione a partner commerciali (editori, "book store", fornitori di risorse secondarie) renderebbe più completo il servizio. In tal modo il servizio Euler potrebbe svolgere un ruolo di intermediazione tra gli utenti e i "venditori" delle informazioni implementando funzioni di accesso "pay per view" e di "alert" periodico degli utenti interessati a determinate tematiche o pubblicazioni.

Dal punto di vista organizzativo questo scenario prefigura l'evoluzione verso un modello di servizio no-profit, gestito da un consorzio di istituzioni e organizzazioni, con funzioni di "information brokerage" e di negoziazione tra i fornitori commerciali e la comunità dei matematici.

Conclusioni

A tal fine sono determinanti aspetti di tipo tecnico e organizzativo. Rientrano nella prima categoria l'adozione di standard per la descrizione delle risorse (metadata) e per l'interoperabilità dei sistemi. La specifica EULER-DC, che estende parzialmente il set di metadata Dublin Core, può essere valutata come utile punto di partenza anche per altre iniziative simili, per esempio in contesti che includono discipline diverse.

In futuro è ipotizzabile che sistemi di questo tipo adottino il set di elementi base Dublin Core per garantire l'interoperabiltà tra risorse eterogenee, demandando a insiemi specializzati di metadata l'aggiunta di informazioni specifiche per determinate risorse e aree tematiche. Il modello funzionale ormai consolidato prevede la distinzione tra il livello del fornitore di servizi e quello del fornitore di informazioni, affidando al primo compiti di intermediazione nei confronti degli utenti finali e al secondo la messa a disposizione dei metadata e delle risorse (cfr. anche DNER e OAI).

Al contrario l'architettura tecnologica può essere di tipo più o meno distribuito, può utilizzare approcci di tipo "query distribuite" e "cross search" (sperimentato in EULER) o di tipo "harvesting" o anche un misto delle due, attraverso protocolli standard (Z39.50, HTTP, DIENST). La scelta dell'architettura tecnica è in parte influenzata da valutazioni legate alle prestazioni ed alla scalabilità del sistema da realizzare, ma anche da fattori organizzativi legati al livello di autonomia che si vuole garantire ai fornitori d'informazione e alla maggiore o minore complessità delle attività che essi devono svolgere e dei sistemi che devono gestire.

Infine, dal punto di vista organizzativo è fondamentale la definizione di accordi cooperativi tra gli organismi, le istituzioni e i fornitori commerciali coinvolti per definire ruoli, compiti e responsabilità all'interno del nuovo modello funzionale della biblioteca digitale.

Riferimenti

[CONS] "Consensus Review Report".
[http://www.emis.de/MATH/EULER/Annual-Reports/3/consensus-report.html]

[DC] "Dublin Core Metadata Element Set, Version 1.1: Reference Description".
[http://purl.oclc.org/dc/documents/rec-dces-19990702.htm]

[DESIRE] Development of a European Service for Information on Research and Education.
[http://www.desire.org/]

[DIENST] "Dienst Architecture Summary Description".
[http://www.cs.cornell.edu/cdlrg/dienst/architecture/architecture.htm]

[DNER] Distributed National Electronic Resource, Resource Discovery Network.
[http://www.rdn.ac.uk/]

[EULER] EULER Project.
[http://www.emis.de/projects/EULER/]

[EUROPAGATE] Europagate.
[http://europagate.dtv.dk]

[LANL] arXiv.org e-Print archive.
[http://xxx.lanl.gov/]

[GILS] "Application Profile for the Government Information Locator Service (GILS)". (ultimo aggiornamento 24 Novembre 1997).
[http://www.gils.net/prof_v2.html]

[JOST] Jost M., "Resource Adaptation in EULER".
[http://www.emis.de/projects/EULER/Reports/W2.html]

[MPRESS] MPRESS database.
[http://www.mathematik.uni-osnabrueck.de/harvest/brokers/FraGer/]

[OAI] Open Archives Iniziative.
[http://www.openarchives.org/]

[RIEMAN] Rieman J, Franzke M. et Redmiles D., "Usability Evaluation with Cognitive Walkthrough".
[http://www.bui.fh-hamburg.de/pers/ursula.schulz/eulerev/cogwalk1.htm]

[ZEBRA] The Zebra Server.
[http://www.indexdata.dk/zebra/]

[Z39.50] Z39.50 Maintenance Agency.
[http://lcweb.loc.gov/z3950/agency/].
 

Appendice 1. La specifica EULER-DC

Nota

• Tutti gli elementi sono ripetibili all'interno di un record eccetto: Title (TI), De-duplication Identifier (IDE) e Record Source (RS).
• Tutti gli elementi DC mantengono la semantica definita nella specifica Dublin Core [DC]. Gli elementi riportati in corsivo sono stati aggiunti nella specifica EULER-DC e hanno la seguente semantica:
• EULER identifier: riferimento non ambiguo alla risorsa in un dato contesto, serve ad identificarla in modi diversi rispetto a quelli forniti dagli altri campi (es. nome, pagina, numero e volume per gli articoli delle riviste).
• EULER.Fulltext: il testo pieno di pagine web o altre risorse.
• EULER.Event.Location: localizzazione di un evento per il/al quale è stata creata la risorsa descritta nel record.
• EULER.Event.Date: date di un evento per il/al quale è stata creata la risorsa descritta nel record.
• EULER.Event.Name: nome di un evento dove il documento è stato creato.
• EULER.Record.Source: sorgente del record, descrive il fornitore d'informazione che ha fornito il record.
• EULER.Record.Sourceidentifier: URL che punta al record originale presso il il fornitore d'informazione (es. record in un OPAC o in un catalogo di pre-print).
• EULER.Record.Creator: creatore del record che descrive la risorsa.
• EULER.Delivery: riferimento al servizio presso il quale può essere acquisita la risorsa descritta nel record (es. URL della maschera di ordine in linea o di document delivery).
• EULER.Delivery.Description: informazione aggiuntiva necessaria a un utente o una biblioteca per recuperare/ fornire la risorsa descritta nel record.

Appendice 2. Esempio di trattamento dei caratteri speciali

Appendice 3. Record estratto dall'OPAC dell'Università di Firenze e covertito in formato EULER

<REC>
<TY>Text.monograph</TY>
<FOP>Printed material</FOP>
<DI>http://www.unifi.it/universita/biblioteche/polo1/i_bibeco.htm</DI>
<DID>Biblioteca di Scienze Sociali (Economia), Inv: EC001011932 Coll: ECGA 070230/</DID>
<RS>University of Florence:BVE0037030</RS>
<OI>http://opac.unifi.it/opac/full?cat_key=BVE0037030&amp;language=ITALIANO</OI>
<DA>1993</DA>
<CR>Scozzafava, Romano</CR>
<CRI>Scozzafava, Romano</CRI>
<PU>Milano, Masson, 1993.</PU>
<PUI>Milano, Masson, 1993.</PUI>
<LA>it</LA>
<SUD>519.2</SUD>
<TI>La probabilit&agrave; soggettiva e le sue applicazioni</TI>
<TII>La probabilita soggettiva e le sue applicazioni</TII>
<TII>La probabilità soggettiva e le sue applicazioni</TII>
<SU>Probabilit&agrave;</SU>
<SUI>Probabilita</SUI>
<SUI>Probabilità</SUI>
<IDB>8841336765</IDB>
<SD>20000302</SD>
<IDE>1993scozprobsoggappl</IDE>
</REC>

<REC>