DOC. CU : Definizione dell architettura della piattaforma - Documento di specifica e design per la piattaforma

Transcript

1 Progetto VICE DOC. CU : Definizione dell architettura della piattaforma - Documento di specifica e design per la piattaforma Data: Lunedì 5 Aprile 2004 Definizione dell architettura della piattaforma 1

2 INDICE 1 Summary Il Framework Struttura e ruoli Metodi di accesso Architettura del framework Scenari di utilizzo Il repository classico MILOS Metadata modeler Interface logic Adaptable Repository Service Logic (ARSL) Metadata database Large Object database Descrizione Accesso navigazionale al repository Hyperbase Le associazioni semantiche Il livello di accesso Hyperbase nel localizzatore Il wizard pedagogico Informazioni pedagogiche (produttore) Informazioni pedagogiche di supporto alla scelta e individuazione di materiale Osservazioni sugli aiuti per costruire un percorso in base ad un approccio educativo Osservazioni su altri tipi di aiuto Il modulo ontologico Le ontologie ed il semantic web Una struttura per il semantic web I linguaggi del semantic web Strumenti per il semantic web Le ontologie per l e-learning I servizi basati sulle ontologie Implementazione Profilazione utente e adattività Architettura Profilazione utenti Aspetti matematici...75 Definizione dell architettura della piattaforma 2

3 7.4 Aspetti cognitivi Aspetti tecnologici Stato del contributo Valutazione e validazione dell usabilità Learner-Centred Design vs User-Centred Design Progettazione Learner- Centred Usabilità del software LC Interazione con i sistemi di e-learning: uno studio pilota Studio di linee guida per la valutazione di usabilità di piattaforme di e-learning...89 Bibliografia...91 Definizione dell architettura della piattaforma 3

4 1 Summary Il progetto VICE (Virtual Continuing Education) mira allo sviluppo di strumenti e metodi per la costruzione di learning object (LO) efficaci e riusabili, e di un repository che supporti la progettazione e la costruzione di moduli didattici, riutilizzando i learning objects disponibili. Gli obbiettivi del progetto si possono pertanto riassumere così: Costruzione di una piattaforma innovativa per la realizzazione di un repository, orientato a massimizzare la ricusabilità di Learning Objects. Sviluppare una metodologia che consenta di realizzare LO s efficaci e di elevata ricusabilità. Sviluppare metodi innovativi per accedere al repository. Sviluppare metodi per la misurazione della usabilità e validità dei LO s I ruoli più importanti identificati per l ambiente VICE sono quelli di amministratore di sistema, gestore della didattica (per creare l impianto logico e dei metadati), organizzatore della didattica (che crea specifici moduli didattici utilizzando LOs), autore (che crea i singoli LOs). Il repository che si intende sviluppare ha, alla base, una moderna architettura classica, basata sulla memorizzazione dei contenuti separata dai metadati; i contenuti possono anche essere large objects multimediali. I metadati hanno una struttura compatibile con i principali standard (SCROM in particolare). Il repository contiene descrittori dei metadati, e può anche contenere descrittori di LO s tradizionali (lezioni, esercitazioni, test in aula,..) o comunque senza un contenuto memorizzabile. L accesso classico al repository avviene mediante search (per ora basate sui metadati ed in seguito estese a considerare il contenuto). Un altro meccanismo di accesso al repository si basa su di una ipertestualizzazione del suo contenuto: un impianto di navigazione consente di fare un browsing dei contenuti del repository, navigando, per esempio, da una tecnologia, ai prodotti SW che la realizzano o agli esempi della sua applicazione. Un terzo meccanismo di accesso, più sperimentale ed innovativo, si basa su di un wizard pedagogico, vale a dire su di un agente intelligente capace di individuare (a fronte dei requisiti di contenuto e degli obbiettivi didattici da raggiungere) i LOs più adatti e di costruire con essi un percorso didattico valido. Il wizard pedagogico presuppone la disponibilità di una ontologia didattica capace di rappresentare gli elementi più significativi di un approccio didattico, e di un meccanismo di profilazione utente, vale a dire di un meccanismo per individuare le caratteristiche salienti degli utenti del repository. L ultimo tema affrontato è la individuazione di uan metodologia sistematica per la valutazione della usabilità sia del repository, che dei LO s in esso contenuti. Definizione dell architettura della piattaforma 4

5 2 Il Framework Obiettivo del seguente capitolo è descrivere, in modo dettagliato, il framework su cui si basa il repository. Se ne descrivono in particolare le strutture e le modalità d accesso, i metodi di accesso ai dati e le metodologie utilizzate. Da ultimo si descriveranno alcuni possibili scenari di utilizzo. 2.1 Struttura e ruoli Nel seguente paragrafo si descrive la struttura logica del framework (dati e sottosistemi), si identificheranno i differenti ruoli che un utente può ricoprire e saranno descritti alcuni macroscenari di utilizzo Dati L unità atomica di informazione che può essere acceduta utilizzando il repository sono i Learning Object (LO). Ogni LO è costituito da due parti fondamentali; i dati veri e propri, che possono essere informazioni di qualsiasi genere e in qualsiasi formato (raw-data), e le meta-informazioni sui dati stessi (metadata) che li caratterizzano; il repository è utilizzato per memorizzare entrambi i tipi di informazione. L utilizzo dei metadata garantisce il riuso dei LO in diversi contesti. Esistono tuttavia particolari LO a cui non è associato alcun raw-data (si consideri per esempio il caso di un seminario o di un libro di testo) e il cui unico tipo di informazione che c è nel repository sono i metadata. Associato al concetto di LO vi sono anche i concetti di versione e variante di un LO. In particolare, solo l autore di un LO può crearne una nuova versione mentre le varianti di un LO possono essere create da tutti gli autori. In entrambi i casi è come se si creasse un nuovo LO anche se nei metadata viene tenuta traccia del LO da cui derivano. Ogni LO potrà inoltre appartenere a più tipologie (es. teorema, algoritmo, esempio grafica 3D) che lo caratterizzano a livello didattico: lo stesso LO può essere usato con scopi didattici od in ambiti differenti. Più LO possono essere, a loro volta, organizzati in Percorsi Didattici che ne definiscono una sequenza di fruizione in un processo di apprendimento. Analogamente ai LO anche ai Percorsi Didattici sono associati i metadata. Un insieme di Percorsi Didattici definiscono infine un Modulo didattico ovvero una sequenza ordinata di Percorsi Didattici. Tutta l architettura del Framework è pensata in funzione sia dei dati sia della struttura logica e fisica in cui sono contenuti: il repository Sottosistemi Il framework è costituito da alcuni sottosistemi che, interagendo tra loro, contribuiscono a creare l ambiente complessivo su cui poi sarà basato il funzionamento del repository. Queste parti possono essere considerate dei sottosistemi a tutti gli effetti e, definendo le opportune interfacce, possono essere implementate anche con linguaggi differenti trovando quindi la tecnologia che meglio si adatta alla realizzazione di ognuna di esse. Dal punto di vista logico si possono identificare sei sottosistemi: area pubblica: accessibile liberamente da un qualsiasi utente esterno che abbia accesso ai canali di comunicazione previsti. Dall area pubblica è possibile sia accedere ai LO e ai Percorsi Didattici contenuti nel repository sia effettuare alcune semplici operazioni. In particolare è possibile sfogliare e navigare i LO e i Percorsi Didattici, esportarli nella propria area privata. Non è invece consentito modificare i contenuti in alcun modo. Definizione dell architettura della piattaforma 5

6 area privata: area riservata ai soli utenti registrati, mette a disposizione alcuni servizi (metadata modeler, metadata editor) riservati a particolari categorie di utenza che necessitano di autorizzazione. Anche da questa zona è ovviamente possibile accedere al repository e ai dati in esso contenuti. localizzatore: dal punto di vista logico il localizzatore altro non è che un repository locale in tutto e per tutto simile al repository pubblico. Il localizzatore, di cui esiste un istanza per ogni utente registrato, permettere agli utenti di avere in locale i LO e i Percorsi didattici su cui sta lavorando. Essi possono essere già presenti nel repository pubblico e copiati in locale per eventuali modifiche oppure possono essere creati ex-novo ed esportati nel repository pubblico, rendendoli disponibili a tutti. metadata modeler: accessibile solo dal gestore della didattica (descritto in seguito nel documento) permette di definire sia le classi di meta-informazioni (classi di metadata) che potranno essere associate ai LO e ai Percorsi Didattici, sia i vari tipi di associazioni utilizzate per collegare due LO. metadata editor: accessibile agli autori (descritti in seguito nel documento) permette l istanziazione dei metadata e la loro associazione ad un raw-data o ad un Percorso Didattico. Il metadata editor permette inoltre sia la definizione della sequenza di fruizione dei LO in un Percorso Didattico sia la creazione e modifica di un Modulo Didattico. interfaccia di coordinamento: accanto ai sottosistemi precedentemente descritti si trova il sistema di coordinamento che costituisce il nucleo fondamentale del framework. Questo ne rappresenta il fulcro vero e proprio su cui si basano tutti gli altri sottosistemi che contribuiscono ad offrire le funzionalità e i servizi per il collegamento al repository. Così configurato il framework è in grado di fornire le funzionalità cui è preposto, e di cui si parlerà più in dettaglio in seguito, mantenendo comunque un alto livello di modularità. Si rende in questo modo anche più semplice l eventuale sviluppo futuro di ulteriori moduli che possono essere definiti, indipendentemente dalla tecnologia utilizzata, semplicemente analizzando accuratamente le interfacce messe a disposizione Ruoli Si descrivono ora in dettaglio i ruoli degli attori che hanno accesso al repository. In particolare sono previsti tre ruoli. Ognuno di questi è caratterizzato da un differente tipo di accesso al repository. Non tutti i ruoli d utenza possono accedere in scrittura ai dati contenuti del repository pubblico. In particolare, esiste il ruolo di amministratore di sistema che ha accesso a servizi particolari come gestione della correttezza dei dati e il management degli utenti del sistema (creazione utenti, cancellazione,utilizzo dei files di log, etc... ). Diversificando i servizi messi a disposizione per i vari ruoli di utenze si può schematizzare l accesso all applicazione nel seguente modo (Figura 1): amministratore di sistema: ha accesso al repository con funzioni di controllo e amministrazione. Ha la possibilità di gestire gli utenti e il loro profilo, può controllare la correttezza dei dati nel repository. Ha accesso inoltre alle informazioni relative ai profili utente. Gestisce l abilitazione degli organizzatori della didattica. Definizione dell architettura della piattaforma 6

7 gestore della didattica: definisce e gestisce le classi di metadata e di associazione. organizzatore della didattica: accede al repository per creare i moduli didattici utilizzando i percorsi didattici e i LO creati dai vari autori. Può inoltre creare nuove associazioni tra LO. autore: crea e gestisce i LO e i Percorsi Didattici nel repository. Può inserire nuovi raw-data nel repository (facendone l upload dal proprio PC), può verificare la consistenza con le informazioni già presenti nel repository, può importare i LO dal repository centrale al proprio localizzatore o li può esportare all esterno del repoitory. Durante il processo di importazione dei LO dal repository centralizzato verso quello locale, l autore può decidere di importarne solo i descrittori oppure anche i raw data annessi. Può anche decidere di importare un singolo LO o tutti i LO collegati. Il localizzatore conterrà quindi una replica parziale del repository pubblico oltre alle informazioni private (non ancora rese pubbliche) di ogni utente Macro-scenari di utilizzo Figura 1 I ruoli degli utenti Nel seguente paragrafo sono descritte le funzionalità che il sistema offre ai vari utenti. Come già evidenziato gli utenti principali del sistema sono l autore e l organizzatore e il gestore della didattica. L autore può accedere sia al localizzatore che al repository pubblico; in particolare accedendo al localizzatore egli può (Figura 2): creare e/o modificare i LO creare e/o modificare i percorsi didattici creare le associazioni semantiche tra LO esportare nel repository pubblico i LO creati o modificati sottoporre i percorsi didattici creati all organizzatore della didattica ne deciderà l esportazione nel repository pubblico. Definizione dell architettura della piattaforma 7

8 Figura 2 - L autore nel localizzatore Accedendo invece al repository pubblico l autore può (Figura 3Figura 2): ricercare i LO o percorsi (utilizzando la ricerca classica, navigazionale o semantica) importare nel proprio localizzatore (utilizzando le cartelle di lavoro) i LO o i percorsi didattici trovati per elaborarli in un secondo momento. Figura 3 - L autore nel repository pubblico L organizzatore della didattica può (Figura 4): esportare nel repository pubblico i percorsi didattici che gli vengono sottoposti dai vari autori creare/modificare i Moduli Didattici Definizione dell architettura della piattaforma 8

9 Figura 4 - L'organizzatore della didattica nel localizzatore Il gestore della didattica può (Figura 5): definire nuovi tipi di metadata definire nuovi tipi di associazioni semantiche esportare nel repository pubblico i tipi di metadata e di associazioni semantiche Figura 5 Il gestore della didattica nel localizzatore 2.2 Metodi di accesso Accanto al concetto di ruolo di utenza, che consente di definire le modalità per accedere all applicazione, si definiscono anche tre differenti modalità di accesso alle informazioni contenute nel repository. Questo avviene indipendentemente da come si è acceduto al framework. In particolare le differenti tipologie di accesso ai dati non dipendono dal ruolo che si ricopre ma quanto dalle finalità della ricerca che si vuole effettuare. Ogni ruolo di utenza che abbia a propria disposizione il servizio di ricerca all interno del repository può, di volta in volta, decidere quale tipologia di accesso sia la più indicata per ottimizzare il proprio lavoro. Nello specifico le differenti modalità di accesso ai dati si possono schematizzare come segue: Definizione dell architettura della piattaforma 9

10 Accesso ipertestuale/navigazionale: i LO e i percorsi didattici sono organizzati in collezioni. Per esempio è possibile organizzarli in base alla tipologia o all argomento trattato. Una volta acceduto ad un LO è inoltre possibile navigare verso altri LO utilizzando le associazioni semantiche. Accesso di tipo semantico o pedagogico: l accesso alle informazioni (LO e Percorsi) avviene tramite una ricerca che tiene conto di varie informazioni quali, per esempio, la profilazione dell organizzatore, chi fa la ricerca, la profilazione dei destinatari (target) e dei LO. Ad esempio: io (autore x) voglio organizzare un corso di informatica grafica (argomento y) per studenti di disegno industriale (target z). Grazie agli agenti che saranno implementati il risultato proposto è un corso tarato in base alle caratteristiche di chi vuol fare il corso e anche in base al profilo del target. Le basi informatiche e le finalità del corso cambiano in base al tipo di studente. Accesso per contenuto con ricerche effettuate utilizzando le informazioni relative ai LO. Questo tipo di accesso comprende l accesso classico sugli attributi, come per le basi di dati tradizionali: ad esempio (autore x, data y, lingua it). Il risultato sarà uno o più LO di quell autore di quella data in italiano. Inoltre questo tipo di accesso permette di fare ricerche anche senza specificare esattamente i campi della struttura interessati (ricerca tipica per dati semi-strutturati): ad esempio, si vuole esaminare i LO in cui si parla, anche come argomento secondario, di semantic web. In questo caso la ricerca di tipo testuale su semantic web può venire effettuata non solo su campi come Titolo e Descrizione associati al LO, ma, se presenti, anche su campi contenuto del LO, come un trascritto dello speaker, nel caso di audio/video, il contenuto testuale di slide di presentazioni, etc.. I tre tipi di ricerca, dal punto di vista logico, restituiscono come risultato un insieme di LO o Percorsi Didattici. La loro differenziazione non si ha a livello di risultato ma riguarda il metodo di ricerca effettuato sul repository. In ultima analisi, quindi, i tre metodi di ricerca attuano un differente tipo di approccio ai metadata che identificano i LO e producono un risultato che può essere diverso a seconda di quanto queste meta-informazioni siano state analizzate e processate. 2.3 Architettura del framework In questa parte del documento si analizza la struttura fisica del framework. Vengono definite le tecnologie che si utilizzano e si analizzano nel dettaglio i componenti fondamentali di cui è già stata discussa la funzione logica Architettura fisica Nell ambito del progetto, è stato disegnato un framework architetturale con caratteristiche specifiche per supportare adeguatamente gli scenari di utilizzo e i tipi di accesso ai LO, precedentemente descritti. Il framework si basa sui servizi forniti da MILOS (MultImedia Learning Object Server), un sistema di Repository per la memorizzazione e il recupero dei LO, appositamente disegnato in questo progetto. MILOS è basato su un potente database/repository multimediale, in grado di garantire funzionalità di persistenza, ricerca e recupero di LO descritti secondo lo standard XML del W3C. L uso dello standard XML come formato di memorizzazione dei metadati dei LO presenta diversi vantaggi, come l integrazione di più formati di metadati, la possibilità di utilizzare potenti linguaggi di interrogazione come XPATH e XQUERY, la possibilità di mettere in relazione diverse Definizione dell architettura della piattaforma 10

11 componenti di metadati, tramite lo standard XLINK, la possibilità di definire schemi su metadati tramite XML Schema, etc. Nel framework complessivo dell architettura, MILOS realizza il repository pubblico, che fornisce i propri servizi alle atre componenti distribuite del framework come web-services. Il repository MILOS, al suo interno è strutturato a tre livelli:. Al livello inferiore, si trovano i due moduli che gestiscono i due database, logicamente e fisicamente differenti, dei metadati dei LO e dei raw-data che compongono i LO. I metadata sono contenuti in un repository per la gestione di oggetti XML (XMLSE) [1]. I raw data sono contenuti invece in un repository che supporta semplici funzioni di accesso diretto, inserzione, eliminazione e update. Le query, effettuate dal livello superiore di MILOS (business logic) sul repository dei metadati di LO, in linguaggi XML, verranno eseguite utilizzando XMLSE come engine di ricerca. I LO vengono restituiti alla business logic dal repository che contiene i raw data utilizzando il formato SCORM (Sharing Content Object Reference Model). Nel livello intermedio di MILOS troviamo la sua business logic. A questo livello avviene la gestione degli accessi ai repository. Lo strato operativo prende il nome di ARSL (Adaptable Repository Service Logic). L interrogazione alla logica di business si effettua utilizzando opportuni XML-schema, mentre il flusso di LO verso il livello superiore avviene sempre tramite il formato SCORM. Il livello d interfaccia di MILOS è realizzato utilizzando dei web-services che sono pubblicati verso l applicazione e che mettono a disposizione dell utente di MILOS una API (Application Program Interface) per l accesso al repository. I vari servizi necessari per interagire con il repository sono realizzati dalle API e a queste si può accedere richiamando il web-service che le invoca. Un altro ruolo di MILOS nel framework complessivo è di fornire servizi di middleware (realizzati su di un web-server e un application server) per gestire l interazione tra il repository pubblico/centralizzato e i repository locali, con opportune opzioni di sincronizzazione. La gestione dei dati utilizzando il formato SCORM rende anche necessaria la presenza, in un livello intermedio, dello SCORM Run Time Environnement che gestisce l interazione tra i pacchetti SCORM e il client. Per le ricerche di dati correlati che forniscono percorsi ipertestuali di navigazione del repository si utilizza XLINK. In questo modo i metadati risultano legati tra loro in relazione al contenuto del LO ed è possibile creare in maniera naturale percorsi semantici all interno del repository e realizzare una navigazione e una ricerca per contenuti affini. La fruizione dell applicazione avviene tramite interfaccia web. Su questa si possono trovare i servizi per l accesso al repository centralizzato e i servizi per l accesso alle parti localizzate di repository dove il ruolo d utenza lo consenta. Su un server web sono anche pubblicati i contenuti per la fruizione. Definizione dell architettura della piattaforma 11

12 Figura 6 - MILOS Considerando i diversi ruoli previsti all interno dell applicazione è possibile dettagliare ulteriormente la definizione dell architettura del sistema. Nell analisi si è scelto di non tenere conto, per il momento, dei diversi tipi d accesso all interfaccia dell applicazione web: internet, intranet, UMTS, palmare. Si parte dalla considerazione che ogni utente, qualunque sia il suo ruolo, una volta effettuato con successo il login all applicazione, a livello di web-server, si trovi ad interagire con il sistema attraverso l interfaccia dell applicazione web personalizzata. L architettura generale del sistema è basata su un modello a tre livelli in cui si può riconoscere un livello di presentazione definito dall interfaccia web dell applicazione, un livello di logica di business, in cui sono gestite le operazioni tipiche del middleware, e un livello di storage in cui sono immagazzinati e gestiti i dati veri e propri. Di quest ultimo livello è parte integrante anche MILOS che nell ottica dell applicazione è un tutt uno con le basi di dati che gestisce. Il localizzatore è parte integrante dell applicazione e svolge funzioni tipiche del secondo e del terzo livello oltre ad utilizzare una versione locale di MILOS per l accesso alle informazioni locali. Il DBMS per la gestione degli utenti opera a fianco del repository centralizzato. Può essere pensato come un normalissimo db (Access, Mysql, Postgres, etc...) che interagisce con la logica di business e consente di arrivare all home page personalizzata da cui, poi, ogni utente ha a disposizione i servizi caratteristici del suo ruolo. Il metadata editor e il metadata modeler sono applicazioni esterne che interagiscono con la logica di business per definizione dei metadata e per l associazione con i metadata. Definizione dell architettura della piattaforma 12

13 E poi la logica di business si occupa della produzione del pacchetto SCORM per immagazzinare i dati nel DB e dell opportuno XML-schema per interagire con le API messe a disposizione da MILOS Localizzatore e metadata modeler. Figura 7 - Architettura generale Obiettivo del seguente paragrafo è analizzare più nel dettaglio alcuni gli strumenti già introdotti che cosituiscono parte integrante del framework. -localizzatore Questa è la zona riservata in cui gli autori potranno esercitare le funzioni di "Authoring". Per authoring intendiamo tutte quelle operazioni che riguardano la definizione, creazione e modifica di LO, Percorsi Didattici, Moduli Didattici, classi di metadata e di associazioni (descritti in seguito). In particolare esiste un localizzatore per ogni utente (autore, organizzatore della didattica, gestore della didattica). In particolare il localizzatore è una versione locale del repository che contiene tutte le informazioni necessarie per l utente in modo che possa svolgere le proprie attività senza accedere al repository pubblico. Al fine di trasferire un ingente mole di informazioni per la sincronizzazione (raw-data), il download dei LO, dal repository pubblico al localizzatore, deve essere richiesto in modo esplicito dall utente e deve essere limitato ai soli LO effettivamente necessari per lavorare. Ciò garantisce sempre la sincronizzazione con il repository che contiene i raw-data. La sincronizzazione avviene connettendosi al repository pubblico ed è realizzata tramite un interscambio tra ARSL locale e ARSL centralizzato. La sincronizzazione dei metadata avviene ogni volta che è lo stato dei metadati del LO raggiunge un livello logico di consistenza tale che è opportuno un salvataggio sul repository pubblico, mentre la sincronizzazione dei raw-data avviene ogni volta che l utente lo ritiene necessario Questo può avvenire per scaricare in locale raw-data su Definizione dell architettura della piattaforma 13

14 cui lavorare o per aggiungere al repository pubblico raw-data modificati o raw-data prodotti ex novo in locale. In questo modo è possibile garantire all utente la possibilità di lavorare off-line senza la continua necessità di avere una connessione permanente con i dati centralizzati. A fronte di questi pro bisogna anche rimarcare l unico importante contro che nasce da una gestione di questo tipo: la sincronizzazione di raw-data di grosse dimensioni potrebbe imporre vincoli sulla banda necessaria per l interscambio di dati. Figura 8 Localizzatore La gestione delle versioni avviene seguendo il sistema di miglioramenti progressivi. Ogni LO può essere cambiato modificando alcune parti o aggiungendo informazioni che lo rendono più completo. Questo privilegio è però riservato solamente all autore del LO il quale può scegliere se modificare il LO esistente nel repository pubblico (raw-data e/o metadata) o estenderlo creando una nuova versione o variante. Le relazioni che sono istanziate nel riutilizzo del LO rappresentano un enorme vantaggio al momento della ricerca nel repository. Questi percorsi consentono, partendo da un LO, di risalire a quelli che gli sono collegati come significato e che sono stati sviluppati a partire da esso. In questo modo rimane traccia delle modifiche effettuate da altri autori e si può creare, in maniera naturale, una history di un LO basata sulla frequenza di utilizzo. A livello di metadata questi collegamenti sono realizzati tramite gli XLINK. Quando uno sviluppatore decide di modificare un LO per aggiungere o per modificare contenuti, può anche scegliere di non pubblicare una nuova versione come integrazione del lavoro già svolto ma di istanziare il tutto come un LO diverso, indipendente da quello di partenza. E il caso, in particolare, di LO i cui contenuti possono essere condivisi tra più argomenti con scopi didattici differenti. Ad esempio se un LO contiene informazioni sull utilizzo degli algoritmi di ricerca potrebbe avere impieghi differenti a seconda che serva per la preparazione di un corso di informatica di base o per la preparazione di un corso di ricerca operativa: per completezza semantica non sarebbe corretto aggiungere le informazioni proprie della ricerca operativa al LO dichiarandone una nuova versione ma piuttosto creare ad hoc un nuovo LO con un utilizzo più specifico degli stessi argomenti. Definizione dell architettura della piattaforma 14

15 -metadata modeler Il metadata modeler permette al gestore della didattica di creare nuovi tipi di metadata o di associazione che sono poi opportunamente passati all interfaccia di MILOS. In questo modo il middleware stesso si preoccupa di creare le API necessarie per la ricerca e per l inserimento dei metadata e dei LO nel repository. Lo standard per i metadata è il 3 [3]. Pur utilizzando uno schema molto simile definiamo l insieme dei metadati, a livello logico, in maniera dettagliata. È previsto un nucleo di metadata indispensabili e fondamentali di cui un LO non può fare a meno e, a corredo, una galassia di metadata facoltativi che, se istanziati, contribuiscono a tipizzare fortemente il LO in questione. Figura 9 - Schema Metadata I metadata facenti parte del core sono obbligatori, l autore decide poi se vuole o meno arricchire il LO istanziando anche i metadata satellite o se preferisce lasciare che questo abbia un carattere più generale. Il metadata modeler si preoccupa di definire quale sia lo schema dei metadata mentre il metadata editor si pone come strumento a servizio dell autore per editare i metadata già definiti in fase di modellazione. In generale i metadata del core contengono informazioni sulla tipologia di LO e sull autore di quest ultimo. In relazione alla tipizzazione, al versioning e alla creazione di varianti del LO vengono riempiti automaticamente i metadata del core che contengono le relative informazioni, compresi anche gli eventuali percorsi XLINK che puntano ai LO legati al corrente, per mezzo delle relazioni predefinite. La galassia di metadata satellite resta a disposizione dell autore se questi dovesse manifestare l intenzione di tipizzare fortemente il LO rendendolo meno generale. Per definire i metadata attraverso il modeler bisogna interagire con MILOS fornendo un XMLschema che viene interpretato dal middleware e che crea le API e i web-services necessari per l interazione. Lo standard 3 offre già di per sè una forte categorizzazione dei metadata in base alle loro funzionalità e ai loro scopi. In particolare i metadata risultano suddivisi in alcune categorie principali. Definizione dell architettura della piattaforma 15

16 general. Informazioni generali riguardanti il LO nella sua visione più generale. In questa categoria troviamo ad esempio un identificatore univoco del LO, un titolo, una tipologia di catalogo con il rispettivo inquadramento, il linguaggio in cui è scritto, alcune parole chiave, una breve descrizione, l area semantica a cui fa riferimento, indicazioni sulla sua sottostruttura e sul suo livello di aggregazione in riferimento a strutture più semplici e non da ultimo le informazioni sull autore. lyfecycle. Informazioni generali sulla storia del LO, sul suo stato corrente e sulle eventuali entità che hanno interagito con esso portando ad alcune modifiche. Nel dettaglio troviamo ad esempio il numero di versione, lo stato di completamento e i contributi allo sviluppo. meta-metadata. Informazioni che descrivono il record del metadata stesso. Troviamo informazioni su chi ha creato o modificato i metadata, su quali metadata sono stati istanziati, sul linguaggio in cui metadata stessi sono scritti e un identificatore che identifica univocamente il record di metadata. technical. Informazioni che descrivono i requisiti e le caratteristiche tecniche del LO. Contengono dati che riguardano il formato del LO, la sua dimensione, la sua localizzazione (URI), i prerequisiti tecnici per la fruizione, le note per una corretta visualizzazione e la durata temporale della fruizione prevista in fase di creazione. educational. Questa categoria descrive il LO in termini pedagogici/didattici relativi all apprendimento. Troviamo ad esempio informazioni relative al tipo di interattività richiesta al fruitore, al tipo di risorsa di apprendimento (lezione, esercitazione, esperimento, etc.), alla densità semantica, all uso tipico previsto per l utente finale, al contesto, alla fascia di età di targeting, alla difficoltà, al tempo medio di apprendimento e al linguaggio di esposizione. rights. Vengono descritti i diritti di utilizzo e di proprietà relativi al LO. Esistono, per esempio, metadata che descrivono il costo di utilizzo del LO, le restrizioni imposte sui contenuti dal creatore e i commenti dell autore sulle condizioni di utilizzo (License). relation. In questa categoria vengono descritte le eventuali relazioni di che un LO ha con altri LO. Il 3, utilizzando 52lin Core, offre già alcuni tipi di relazioni predefinite come ad esempio is part of oppure is instance of. In particolare nei metadata possiamo indicare il tipo di relazione, la risorsa a cui fa riferimento e una descrizione del legame. annotation. Contiene annotazioni sulla creazione del LO e eventuali commenti al LO e allo sviluppo delle funzionalità per cui è preposto. classification. Questa categoria descrive un possibile inquadramento del LO in sistemi di classificazione predefiniti. Contiene ad esempio informazioni sulle finalità di sviluppo del LO e su un eventuale classificazione tassonomica di questo. Definizione dell architettura della piattaforma 16

17 L insieme dei metadata forniti dal 3 è molto diversificata e particolareggiata. Basando il modello di metadata su quello già fornito dalla IEEE possiamo creare un modello che ricalchi fedelmente quello riportato sopra definendo in maniera precisa quali metadata devono, per loro natura, far parte del core e quali appartengono invece alla galassia rimanente. Un percorso di questo tipo ci porterà a definire, in un passo successivo, l XML-schema che definisce il modello dei metadata e che, interpretato da MILOS, renderà possibile la creazione dei web-services per l accesso al repository centralizzato. Per loro stessa natura i metadata del core rendono il LO il più generale possibile. In questa categoria troveremo quindi solo quelle informazioni che permettono di identificare univocamente un LO senza entrare nel dettaglio riguardo il suo utilizzo o le sue finalità. In particolare potremmo enumerare i metadata del core nella maniera seguente: identificatore univoco dati dell autore data creazione tipo di supporto linguaggio dei testi tipo di risorsa di apprendimento tipo di relazioni e riferimento fisico Gli altri metadata dello standard 3 sono comunque utili per aumentare il livello di dettaglio della descrizione del LO, fanno quindi parte della galassia dei metadata satellite e la loro istanziazione è a discrezione dell autore. Esiste inoltre un insieme di metadata che sviluppano funzionalità utili per l implementazione di differenti tipologie di accesso all applicazione, ad esempio la ricerca con l utilizzo di agenti. Queste vengono definite in un documento XML-schema a parte e passate all interfaccia di MILOS che creerà API e web-services su misura per la gestione. 2.4 Scenari di utilizzo Obiettivo del seguente paragrafo è sia descrivere le funzioni principali dell applicazione sia evidenziare l interazione tra i diversi moduli del sistema che concorrono alle stesse. Definizione dell architettura della piattaforma 17

18 L autore: Creazione di un nuovo LO. Figura 10 - Creazione di un nuovo LO Lo scenario modella la possibilità per l autore di creare un nuovo LO e di renderlo disponibile nel repository pubblico (Figura 10). Sequenza di operazioni: 1. L autore esegue l upload del materiale didattico (raw-data) dal proprio PC al repository locale (localizzatore). 2. L autore avvia il metadata editor. 3. L autore seleziona i raw-data a cui associare i metedata. L operazione è opzionale e non viene eseguita nel caso il nuovo LO non preveda raw-data associati. 4. I raw-data vengono caricati nel metadata editor. In particolare vengono caricati sono i riferimenti ai raw-data. 5. L autore edita i metadata e li associa ai raw-data creando, di fatto, il nuovo LO 6. Il nuovo LO è salvato nel repository locale 7. L autore decide di esportare il nuovo LO nel repository pubblico. L operazione è opzionale in quanto non è detto che l autore voglia rendere disponibile il nuovo LO agli altri utenti. Definizione dell architettura della piattaforma 18

19 L autore: Modifica di un LO. Figura 11 - Modifica di un LO Lo scenario modella la possibilità per l autore di modificare un LO, creando una nuova versione o facendone semplicemente l update (Figura 11). Se l autore non è il proprietario del LO l operazione porterà alla creazione di un nuovo LO che sarà una variante del LO originario. Sequenza operazioni: 1. L autore avvia il metadata editor. 2. L utente seleziona dal repository locale il LO da modificare. 3. Il LO viene caricato nel metadata editor. 4. L autore modifica i raw-data associati al LO. L operazione consisterà nel fare l upload nel repository locale di nuovi raw-data e nell associazione degli stessi al LO. 5. L autore modifica i metadata associati al LO (ne associa di nuovi, modifica o elimina quelli esistenti). 6. L autore salva il nuovo LO decidendo se è una nuova versione, un update o una variante. 7. L autore decide di esportare il nuovo LO nel repository pubblico. L operazione è opzionale in quanto non è detto che l autore voglia rendere disponibile il nuovo LO agli altri utenti. Definizione dell architettura della piattaforma 19

20 L autore: Creazione di un nuovo percorso didattico Figura 12 - Creazione nuovo percorso Lo scenario modella la possibilità per l autore di creare un nuovo percorso didattico (Figura 12). Un percorso didattico è composto sia da LO sia da altri percorsi didattici organizzati in una struttura che ne definisce la sequenza di fruizione. Sequenza operazioni: 1. L autore avvia il metadata editor. 2. L utente seleziona dal repository locale i LO e i percorsi didattici da utilizzare per la creazione del nuovo percorso. 3. I riferimenti ai LO e ai percorsi didattici selezionati vengono caricati nel metadata editor. 4. L autore definisce la struttura del nuovo percorso didattico. 5. L autore edita i metadata e li associa al nuovo percorso didattico. L operazione presuppone la selezione dei tipi di metadata da utilizzare per caratterizzare il percorso 6. L autore salva il nuovo percorso didattico nel repository locale 7. L autore sottopone il nuovo percorso didattico all organizzatore della didattica che deciderà se renderlo pubblico o meno. L operazione è opzionale in quanto l autore potrebbe non voler rendere pubblico il proprio percorso didattico. Definizione dell architettura della piattaforma 20

21 L autore: Modifica di un percorso didattico Figura 13 - Modifica di un percorso didattico Lo scenario modella la possibilità per l autore di modificare un proprio percorso didattico. La modifica comprende la modifica sia della struttura che dei metadata associati allo stesso (Figura 13) Sequenza operazioni: 1. L autore avvia il Metadata Editor 2. L autore seleziona dal repository locale il percorso da modificare. 3. Il riferimento al percorso viene caricato nel Metadata Editor 4. L autore modifica la struttura del percorso. Ciò equivale a: a. Riorganizzare la sequenza di fruizione dei LO e dei sotto-percorsi b. Inserire/Eliminare un LO c. Inserire/Eliminare un percorso didattico 5. L autore modifica i metadata associati al percorso (ne associa di nuovi, modifica o elimina quelli esistenti). 6. L autore salva il percorso didattico nel repository locale. 7. L autore sottopone il nuovo percorso didattico all organizzatore della didattica Definizione dell architettura della piattaforma 21

22 L autore: Creazione di un associazioni tra LO Figura 14 - Creazione di un associazione tra LO Lo scenario modella la possibilità per l autore di creare un associazione tra due LO. L associazione è creata da un autore nel suo localizzatore e può essere esportata nel repository pubblico. (Figura 14). Sequenza operazioni: 1. L autore selezione il LO source dell associazione 2. L autore seleziona il tipo di associazione da istanziare 3. L autore seleziona il LO target dell associazione. La nuova associazione è salvata nel repository locale 4. L autore decide di esportare l associazione nel repository pubblico insieme ai LO source e target Definizione dell architettura della piattaforma 22

23 L Organizzatore della didattica: Esportazione di un percorso didattico Figura 15 - Esportazione di un percorso didattico Lo scenario modella la possibilità per l organizzatore della didattica di rendere pubblici i percorsi didattici da lui creati o che gli sono stati sottoposti per l approvazione dai vari autori (Figura 15). Sequenza operazioni: 1. L organizzatore della didattica sfoglia i percorsi presenti nel suo repository locale. 2. L organizzatore della didattica seleziona i percorsi da rendere pubblici e li esporta nel repository. L Organizzatore della didattica: Creazione di un modulo didattico Figura 16 Creazione di un modulo didattico Lo scenario modella la possibilità per l organizzatore della didattica di creare un nuovo modulo didattico (Figura 15). Sequenza operazioni: 1. L organizzatore della didattica seleziona i percorsi didattici da inserire nel modulo didattico 2. L organizzatore della didattica inserisce le informazioni di base associate al modulo didattico 3. L organizzatore della didattica salva il modulo didattico nel proprio repository locale. 4. L organizzatore della didattica rende pubblico il modulo didattico. Definizione dell architettura della piattaforma 23

24 Il Gestore della Didattica: Definizione di un nuovo tipo di metadata Figura 17 - Definizione di un nuovo tipo di metadata Lo scenario modella la possibilità per il gestore della didattica di definire nuovi tipi di metadata che saranno poi utilizzati dagli autori per caratterizzare i LO e i percorsi didattici (Figura 17). Sequenza operazioni: 1. Il gestore avvia il metadata modeler 2. Il gestore definisce il nuovo tipo di metadata che viene salvato nel repository locale. 3. Il gestore rende pubblico il nuovo tipo di metadata. Definizione dell architettura della piattaforma 24

25 Il Gestore della didattica: Definizione di un nuovo tipo di associazione tra LO Figura 18 - Definizione di un nuovo tipo di associazione tra LO Lo scenario modella la possibilità per il gestore della didattica di definire nuovi tipi di associazioni tra LO che saranno poi utilizzati dagli autori per creare le associazioni tra i vari LO (Figura 18). Sequenza operazioni: 1. Il gestore avvia il metadata modeler 2. Il gestore definisce il nuovo tipo di associazione che viene salvato nel repository locale. Il gestore specifica il nome della nuova associazione e il dominio cui appartiene (matematica, informatica, etc.). 3. Il gestore rende pubblico il nuovo tipo di associazione. Definizione dell architettura della piattaforma 25

26 3 Il repository classico Per il Repository di LO, da sviluppare nell ambito del progetto, si sono individuate i seguenti requisiti essenziali: Flessibilità di strutturazione e rappresentazione di oggetti e metadati Scalabilità e distribuzione dell architettura Modello operativo adeguato alle funzionalità richieste dalle altre componenti del progetto La flessibilità è richiesta a due livelli: a livello degli oggetti di base che compongono i LO e a livello dei metadati dei LO. Gli oggetti di base, ad esempio. file PDF, video MPEG2, presentazioni PowerPoint, immagini JPEG, oggetti con sequenze temporali, tipo SMIL o MPEG4, etc. hanno ognuno un suo formato e strutturazione interna, e fanno riferimento ad ambienti/tool specifici di sviluppo e display. I metadati descrivono il contenuto degli oggetti basici, o raw-data, (ad esempio, MPEG7 per gli oggetti multimediali) e la loro valenza e composizione nell ambito di un LO (metatdati SCORM). E chiaro che deve essere possibile rappresentare situazioni in cui un LO (descritto a livello di metadati) contiene diversi oggetti basici, e, viceversa, un oggetto basico è contenuto in diversi LO. La flessibilità richiesta per rappresentare e gestire metadati di LO si ottiene adottando XML come standard di specifica di metadati (come nel caso di MPEG7 e SCORM, descritti nel seguito). I requisiti di scalabilità e distribuzione sono essenziali in relazione all ambiente operativo per questo genere di applicazioni. Infatti, non si può realisticamente immaginare un unico Repository centralizzato per i LO,. Piuttosto, è realistica una situazione in cui diverse organizzazioni rendono disponibili, con opportuni controlli, i loro LO, ed in particolare i loro metadati su cui poter effettuare ricerche sul contenuto. Questo approccio permette un riuso dei LO posseduti, generando valore aggiunto. Nel nostro caso, pensiamo di ottenere questi scopi adottando una tecnologia basata su Web Services. Il modello operativo richiesto per un Repository di LO ha requisiti specifici che risultano diversi da quelli di un DBMS classico. Abbiamo identificato i seguenti requisiti specifici: Deve essere possibile inserire metadati di LO nuovi e diversi senza l intervento preventivo di un amministratore, come nel caso dei DBMS; Deve essere molto efficiente nell accesso, in lettura, ai metadati rappresentati in XML, usando linguaggi standard quali XPath [13] e XQuery [14]. Le interfacce XML ai database relazionali sono particolarmente inefficienti per oggetti complessi XML, in quanto richiedono un grande numero di operazioni di Join. Non è necessario che il Repository di LO supporti un meccanismo transazionale potente ma rigido come quello dei DBMS, piuttosto un meccanismo più semplice (tipo check-out e check-in) per controllare che sta lavorando sui metadati di un LO. Deve essere molto efficiente anche per le operazioni di inserimento di nuovi LO (ad esempio, operazioni di bulk import, nel caso una organizzazione acquisti grandi librerie di LO per iniziare nuovi fronti di attività) Deve essere possibile definire più versioni dei metadati di un LO. In questa sezione presentiamo l architettura e le funzionalità di MILOS (MultImedia Learning Object Server) il sistema di Repository per il supporto alla memorizzazione e recupero dei LO che si basa sui requisiti di progetto precedentemente esposti. Nel primo anno di attività del progetto si è Definizione dell architettura della piattaforma 26

27 completato il disegno del sistema MILOS è si è iniziata la sua implementazione, specialmente per alcuni moduli critici di cui si necessità valutare quanto prima le funzionalità. MILOS è basato su un potente database/repository multimediale, in grado di garantire funzionalità di persistenza, ricerca e recupero di LO in XML (descritti usano lo schema del W3C). L uso dello standard XML come formato di memorizzazione dei documenti ha fra i tanti vantaggi anche quello di permettere l integrazione di formati preesistenti quali SCORM [15] e MPEG-7 [16] utili per il progetto. In particolare il formato SCORM sarà utilizzato per descrivere LO, mentre MPEG-7, per arricchire le componenti multimediali dei LO stessi. Infatti alcune parti dei LO possono essere oggetti di base vale a dire, immagini, file PDF, video, presentazioni Power Point, oggetti interattivi in MPEG-4, etc. 3.1 MILOS L infrastruttura di MILOS è basata su un architettura a tre livelli (Figura 19) composta da cinque componenti logici: metadata Modeler, Interface Logic, Adaptable Repository Service Logic, Storage Layer (composto dal Large Object Database, e dal metadata Database). La Figura mostra anche la relazione fra gli strumenti di creazione dei LO (metadata editors) e il Repository. Il metadata Modeler è uno strumento per la creazione di modelli di metadati per la creazione dei LO. La Interface Logic è formata da un certo numero di componenti in grado fornire varie interfacce di accesso ai LO agli utenti esterni attraverso la rete, utilizzando un semplice browser. Il Repository Service Logic gestisce l accesso ai dati memorizzati nel Repository dei LO (metadata DB) e dei dati di base (Large Object DB). Di seguito diamo una descrizione più dettagliata di questi componenti. Si noti che tutti i componenti di MILOS comunicano attraverso il protocollo SOAP. Figura 19 L architettura di MILOS 3.2 Metadata modeler È uno strumento utilizzato per definire nuovi modelli di metadati o arricchire modelli già esistenti Come esempio si supponga di voler creare uno schema di LO con nuove funzionalità ed ontologie, il risultato dei questa fase di progettazione sarà un insieme di uno o più schemi XML, che saranno in seguito utilizzati come parametro di ingresso per l Adaptable Repository Service Logic. Quest ultimo è in grado di adattare la sua interfaccia di accesso sulla base del nuovo schema di metadati. Definizione dell architettura della piattaforma 27

28 3.3 Interface logic La interface Logic comprende tutti i moduli relativi alle attività esportate all esterno dal sistema. Tipicamente l accesso sarà fornito attraverso un browser web. In particolare, i metadata Editor Tools permettono agli utenti di editare o modificare manualmente i metadati associati ai LO. In teoria esiste un metadata editor per ogni schema di metadati. In pratica, un editor di metadati può essere programmato in modo da funzionare con più schemi di metadati definiti da un metamodello di metadati. Alcuni dei tipi di metadati possono essere generati automaticamente; è il caso ad esempio dei metadati multimediali, come il trascritto o le scene di un filmato. In questo caso un editor può essere utile per apportare delle correzioni. I Retrieval tools sono usati per cercare i LO. Varie funzionalità sono fornite da questa interfaccia: gli utenti possono ad esempio cercare del testo libero sul trascritto o sulle descrizioni associate ai LO, ricercare specifici campi di metadati, oppure eseguire ricerche per similarità sui contenuti multimediali, etc. Un esempio di metadata editor, sviluppato durante il progetto ECHO, un progetto europeo per la gestione di documenti storici Audio/Video, è mostrato in Figura 20. Un importante caratteristica di questo editor è che il suo codice non è cablato su di un particolare insieme di attributi dei metadati. Infatti, l editor di ECHO utilizza l XML schema del modello dei metadati di ECHO come un file configurazione. Il vantaggio di tale scelta risiede nella possibilità di aggiungere o rimuovere dei campi secondo le esigenze degli utilizzatori del sistema ECHO. Questo è ottenuto dando all editor la possibilità di riconoscere automaticamente un sottoinsieme di tipi predefiniti dagli schemi XML, come, stringhe, booleani, date, etc. Figura 20 L editor del progetto ECHO 3.4 Adaptable Repository Service Logic (ARSL) Questo componente gestisce l accesso alle basi di dati sottostanti: il LO database (che fornisce la persistenza dei LO) e il Large Object database (dove sono memorizzati tutti i dati di base dei LO). Definizione dell architettura della piattaforma 28