All’interno di questo capitolo abbiamo visto la struttura del sistema mediatore MOMIS, le sue funzionalit`a ed il procedimento che viene effettuato per produrre lo schema globale (risultato terminale del processo di integrazione delle fonti) a partire da quelli locali. Concentriamoci ora sull’utilizzo che tale sistema pu`o avere nell’ambito del progetto ECD (enhanced contents delivery) di cui fa parte la presente tesi.
Ricordiamo che lo scopo di tale progetto `e quello di sviluppare tecnologie e stru-menti in grado di offrire, agli utenti finali, contenuti arricchiti. Ci`o pu`o essere fatto attraverso l’identificazione di materiale digitale presente su fonti diverse ed etero-genee, attraverso la sua trasformazione, organizzazione ed aggiunta di metadati ed informazioni utili a qualificarlo e a far giungere agli utenti materiale pi`u rilevante ai loro fini.
Risulta, quindi, molto importante l’impiego, unitamente a tecnologie per la ges-tione di archivi di documenti digitali(eg.biblioteche digitali XML), di un modulo me-diatore come MOMIS, in particolare se utilizzato per raccogliere schemi di sorgenti eterogenee e permetterne l’annotazione, l’arricchimento semantico. Fondamentale risulta, quindi, l’interazione con il database lessicale WordNet, descritto nel capitolo
6, che fornisce le conoscenze necessarie alla fase di annotazione per associare ad ogni termine (e quindi ad ogni elemento degli schemi) un concetto. WordNet `e in grado anche di individuare relazioni fra i concetti selezionati, fatto importantissimo per il problema che ci accingiamo a risolvere: identificare quali schemi XML (quindi quali documenti XML apparteneti ad un archivio) sono in grado di fornire informazioni utili ad una richiesta dell’utente, e riformulare tale richiesta per questi schemi.
Cerchiamo ora di capire quali parti del mediatore MOMIS ci interessano, e saran-no quindi utilizzate in seguito. Lo scopo di MOMIS `e quello di creare una vista globale integrata (GVV) di un insieme di schemi rappresentanti sorgenti di dati etero-genee. Un metodo possibile per risolvere il nostro problema `e quello di far porre, al-l’utente, le richieste, o query, direttamente sullo schema globale, per poi riformularle (per mezzo di apposite tabelle di mapping inglobate nelle classi globali ODLI3) diret-tamente in query per gli schemi locali. Questo metodo, bench`e fornisca i risultati vo-luti, costringerebbe l’utente a studiare preventivamente la composizione dello schema globale, che pu`o non trovare, nella terminologia, riscontro diretto con gli schemi lo-cali. Non `e questo il nostro intento. L’utente, infatti, deve essere libero di esprimere la richiesta con i termini che ritiene possano fornire le informazioni desiderate, un po’ come avviene nei motori di ricerca utilizzabili sul Web (eg. Google, Altavista, ecc...), senza bisogno di una lettura preventiva dello schema globale. Deve essere compito del sistema, successivamente, reperire similarit`a semantiche fra i termini ed i path espressi dalla query con quelli situati negli schemi, in modo da poterla riscrivere sugli schemi identificati come interessanti. A tale scopo, quindi, bastano i seguenti moduli appartenenti al sistema MOMIS:
• Il modulo SAM di acquisizione degli schemi dalle sorgenti. Tale modulo
impie-ga i wrapper (uno differente per ogni tipo di fonte da utilizzare) per tradurre gli schemi originali in ODLI3. Questa rappresenta una fase indispensabile per tutte le altre.
• Il modulo SLIM, in grado di interagire col database lessicale WordNet e
perme-ttere la annotazione (assegnazione dei significati) agli schemi tradotti in ODLI3. Questo modulo software `e, inoltre, in grado, a partire dagli schemi annotati, di produrre un thesaurus di relazioni semantiche fra gli elementi contenuti in essi. Sar`a proprio questo thesaurus (insieme agli schemi arricchiti semanticamente) il punto di partenza per una corretta riscrittura delle richieste degli utenti finali.
Oltre ai due moduli citati nell’elenco precedente, sarebbe possibile impiegare, per il nostro scopo, anche il modulo SIM. Tale modulo si occupa sia di reperire relazioni intra-schema dovute alla struttura degli stessi (ereditariet`a, foreign-key, ecc...) che, basandosi sul software ODB-Tools, di inferire nuove relazioni a partire da quelle trovate da SLIM o aggiunte dal progettista. Per quanto riguarda le relazioni intra-schema, esse non interessano molto al nostro fine: ci`o che importa sono invece le relazioni inter-schema che legano fra loro termini appartenenti a schemi differenti. Potrebbero essere utili, invece, le relazioni inferite tramite l’utilizzo delle logiche de-scrittive. Nello sviluppo del software della presente tesi sono stati impiegati solamente i moduli SAM e SLIM. L’impiego del modulo SIM, comunque, non varierebbe il fun-zionamento del procedimento per la riscrittura di una richiesta basandosi sugli schemi annotati, si impiegherebbe solamente il thesaurus prodotto da SIM invece che quello prodotto dal modulo SLIM.
Vediamo ora, brevemente, le modifiche che `e necessario apportare ai moduli di MOMIS, impiegati nell’ambito della presente tesi, al fine di risolvere il problema della riscrittura delle query poste da un utente su un archivio di documenti XML.
1. Assumendo che sia impiegato il linguaggio Xml-Schema (descritto approfondi-tamente all’interno del capitolo 3) per descrivere la struttura dei documenti che possono comparire all’interno di un archivio XML, `e necessario procettare ed implementare un wrapper che traduca da Xml-Schema ad ODLI3. Tale wrapper non `e ancora stato implementato e, all’interno del capitolo 5, si esprimono le specifiche richieste per una corretta traduzione da Xml-Schema ad ODLI3. 2. Il modulo SLIM, per evitare possibili perdite di conoscenza, deve poter usufruire
di una versione estensibile di WordNet, in cui possano essere aggiunti nuovi termini, significati e relazioni fra di essi. Per mezzo della tesi di laurea di Veronica Guidetti[24] WordNet `e stato reso facilmente estensibile, riportando la conoscenza da esso espressa in un database relazionale chiamato MOMISWN. Nell’ambito della presente tesi `e stata prodotta una nuova versione di SLIM in grado di reperire le informazioni necessarie da questo database.
Il linguaggio Xml-Schema
3.1 Introduzione
Lo scopo di un Xml-Schema[11, 13, 12] `e quello di definire una classe di documenti Xml, permettendone la validazione. I documenti Xml che corrispondono alla de-scrizione fornita da un Xml-Schema vengono chiamati ’documenti istanza’ di quel particolare schema.
L’utilizzo di questo strumento permette di definire in modo molto preciso la strut-tura che deve avere un documento Xml, supportando, a differenza delle DTD (Docu-ment Type Definition), l’utilizzo di un grande numero di tipi di dato primitivi, quali Stringhe, Interi, Date, Reali L’invenzione di tale linguaggio `e stata resa necessaria anche dal fatto che le DTD sono fornite con una sintassi a se stante, differente da quella dell’Xml vero e proprio, mentre gli schemi si basano su descrizioni fornire in Xml, permettendo di lavorare su di essi con strumenti gi`a creati per tale standard e risultando molto pi`u comodi per i programmatori.
Una ulteriore novit`a rispetto alle DTD `e data dalla possibilit`a di definire nuovi tipi di dato, sia complessi (contenenti dei sottoelementi) che semplici (non contenenti al-cun sottoelemento), partendo da elementi gia definiti in questo o in altri schemi. L’ul-tima caratteristica citata aggiunge ad Xml-Schema un approccio che si pu`o definire Object-Oriented assomigliando moltissimo, appunto, al concetto di ereditariet`a pre-sente in numerosi linguaggi di programmazione. Questo fatto, insieme alla puntuale tipizzazione dei dati, rende Xml-Schema un linguaggio pi`u facilmente utilizzabile, rispetto alle DTD, congiuntamente a linguaggi di programmazione veri e propri.