appunti su SCORMlnx.itisgalileiroma.it/joomla/images/stories/pdf/appunti scorm.pdf · La terza...

appunti su SCORM

e sulla formazione a distanza

Italo Losero

versione 2, 9 maggio 2006

- 1

Indice degli appunti

In questo testo.....................................................................................................................................................3Il processo di standardizzazione: chi crea gli standard per l'e-learning e quali sono le realtà coinvolte............................................4

In questo capitolo.............................................................................................................................................4Il processo di formazione degli standard..................................................................................................................5Gli enti coinvolti..............................................................................................................................................6Infine, chi norma?...........................................................................................................................................13conclusioni...................................................................................................................................................13

L'applicazione del reference model SCORM..................................................................................................................14In questo capitolo...........................................................................................................................................14introduzione..................................................................................................................................................15Componenti di un sistema FAD............................................................................................................................15I metadati: descrittori degli oggetti......................................................................................................................22Il packaging..................................................................................................................................................22Il colloquio con la piattaforma............................................................................................................................23Corrispondenza del reference model SCORM ai componenti della FAD.............................................................................26conclusione...................................................................................................................................................29

Learning objects?................................................................................................................................................30in questo capitolo...........................................................................................................................................30La strutturazione in Learning Objects...................................................................................................................30In base all'esperienza.......................................................................................................................................32

I metadati.........................................................................................................................................................34in questo capitolo...........................................................................................................................................34Sistemi di catalogazione dei materiali didattici........................................................................................................34Introduzione ai metadati secondo SCORM...............................................................................................................36Analisi dei metadata........................................................................................................................................38Compilazione dei metadati: il dettaglio.................................................................................................................39Esempio di compilazione...................................................................................................................................55Obbligatorietà dei campi...................................................................................................................................64XML binding..................................................................................................................................................67Tools per l’implementazione dei metadati..............................................................................................................69

La realizzazione di learning objects strutturati secondo le specifiche SCORM e i modelli d’apprendimento: un’esperienza concreta.......74In questo capitolo...........................................................................................................................................741. Introduzione .............................................................................................................................................742. Impostazioni iniziali ....................................................................................................................................753. Formazione esperti di contenuto.....................................................................................................................804. Fornitura dei contenuti in formato digitale.........................................................................................................845. Realizzazione............................................................................................................................................846. Controllo e testing......................................................................................................................................867. Conclusione..............................................................................................................................................86

AICC: come funziona ............................................................................................................................................90in questo capitolo...........................................................................................................................................90terminologia.................................................................................................................................................91struttura di un corso........................................................................................................................................91rapporti tra CMI e WBT.....................................................................................................................................93cosa comunicare: il data model...........................................................................................................................96sequencing: esempi e binding.............................................................................................................................99

da SCORM a AICC andata e ritorno...........................................................................................................................104in questo capitolo..........................................................................................................................................104lifecicle del materiale didattico nella piattaforma...................................................................................................105L'importazione / esportazione dei corsi................................................................................................................107il runtime...................................................................................................................................................110

Repositories di learning objects..............................................................................................................................1131 - Premessa................................................................................................................................................1132 - I materiali di partenza................................................................................................................................1133 - La condivisione dei materiali prodotti..............................................................................................................1144 - Strategie di organizzazione delle repository: un approccio bottom-up .......................................................................115

- 2

In questo testo...

... si trova la raccolta degli appunti sugli standard della formazione a distanza.

E' una raccolta, e come tale non ha pretese di completezza.

La prima parte riguarda in generale il processo di standardizzazione, descrivendo quali enti hanno influenza nelle decisioni come sono strutturati le attuali specifiche, in particolare per quanto riguarda SCORM.

A SCORM è dedicata la seconda parte: partendo dalla struttura di un sistema di formazione a distanza se ne isolano i componenti per evidenziare a ciascuno di essi quale parte del reference model si applica.

La terza parte è relativa ai learning objects, cercando di definirne l'entità ed il comportamento in un LMS.

Si passa, nella quarta parte, a descrivere i metadati; sono riportate le specifiche LOM tradotte in italiano e tre esempi di compilazione completa per un learning object.

La quinta parte riporta nei dettagli una esperienza di creazione di corsi strutturati secondo learning object e stili di apprendimento.

La sesta e settima parte riguardano AICC: come funzionano i materiali creati secondo queste specifiche e quali accorgimenti devono essere attuati per convertire i materiali didattici da una standard all'altro.

Infine è inserita una parte relativa a repository di learning objects, riguardo a come organizzare le risorse e come collegarle tra loro.

Buona lettura!

In questo testo... - 3

Il processo di standardizzazione: chi crea gli standard per l'e-learning e quali sono le realtà coinvolte.

In questo capitolo...

Scopo di questo capitolo è il fornire una informazione generale sulle modalità di creazione in genere degli standard ed in particolare di quelli per i sistemi di formazione a distanza.

Per questo si affronta dapprima la modalità con la quale un (qualsiasi) standard viene generato, quindi si analizzano gli enti che hanno qualche ruolo nel processo di standardizzazione a, infine vengono esposti alcuni concetti generali che riguardano l'applicazione di SCORM ai sistemi FAD.

In generale le norme ISO (International Organization for standardization, www.iso.org) indicando il livello più alto della standardizzazione internazionale in qualsiasi campo. Esistono norme per i filetti delle viti, per la larghezza delle prese della corrente, per la larghezza dei binari dei treni; ma ad oggi non esiste una norma ISO per la formazione a distanza; esistono invece alcuni riferimenti suggeriti che hanno una più o meno vasta applicazione.

Prima di analizzare nel dettaglio quali siano è bene ricordare la modalità con cui queste norme vengono emanate.

Alla fine di questo capitolo si avrà una visione del panorama normativo che circonda il modello SCORM.

Per avere informazioni sulle modalità di standardizzazione della formazione a distanza si può provare a… seguire un apposito corso di formazione a distanza: si può trovare su readygo un corso frequentabile liberamente.1

Qui vengono date informazioni su AICC, SCORM e IMS; il significato di queste sigle viene spiegato più avanti.

1 http://www.readygo.com/aicc/

Il processo di standardizzazione: chi crea gli standard per l'e-learning e quali sono le realtà coinvolte. - 4

Il processo di formazione degli standard

Gli standard vengono creati per essere utilizzati: si parte dalla necessità di una standardizzazione per arrivare alla norma di riferimento.

Si possono distinguere quattro passi nella costruzione degli standard:

1. I primi passi vengono mossi in funzione dei bisogni degli utenti e degli studi condotti dai settori di ricerca e sviluppo di riferimento: ognuno crea i propri ‘standard’ proprietari, semplici norme che consentono di unificare le procedure all’interno di un ambito ristretto.

2. La necessità di condividere con altre realtà le stesse procedure (per consentire l’interoperabilità dei prodotti) fa sì che si creino consorzi o gruppi di aziende, su base privata o pubblica, che elaborino alcune ‘norme comuni’ che normalmente riguardano parti specifiche del sistema da normare;tra le iniziative prese a questo livello possiamo ricordare ARIADNE, IMS e AICC.

3. Ad un livello superiore, le indicazioni delle entità precedenti, specifiche per alcuni aspetti del processo, vengono armonizzate e raccolte in una cornice unica. E’ il caso di Advanced Distance Learning, iniziativa promossa dal ministero della difesa statunitense, che ha raccolto in un context framework le norme presenti per dare un aspetto normativo globale sul processo di formazione a distanza, raccogliendo gli standard proposti nell’iniziativa SCORM (sharable content object reusable module), che risulta oggi la più seguita iniziativa globale di normazione sulla formazione a distanza.

4. A questo punto le norme vengono proposte agli enti ufficiali (IEEE,CEN) fino a diventare norme accolte da ISO


Il processo descritto è stato semplificato; in realtà i rapporti tra le entità non è nettamente separato da un punto all’altro, esistono collaborazioni a molti livelli.

Oggi non esiste una norma ISO di riferimento per la FAD, quindi l’iter normativo non ha ancora seguito tutto il suo corso; tuttavia, l’ampia adozione delle specifiche individuate da SCORM pone queste indicazioni come standard de facto (o industry standard) per la maggior parte dei sistemi di formazione a distanza.

Occorre ricordare che solo le norme indicate da enti certificatori ufficiali (ISO, CEN, DIN) sono standard de jure; il processo che porta a questi standard è spesso lungo a causa degli indispensabili passaggi a cui è soggetta la norma.

Gli enti coinvolti

Nella figura viene rappresentato l'insieme degli enti che in qualche modo hanno concorso alla definizione degli standard sulla formazione a distanza.

Diamo prima uno sguardo d'insieme; tutto lo schema tende, attraverso la freccia diagonale, verso ISO, standard non ancora raggiunto.


SpecConsortia

SpecConsortia

SpecConsortia

SpecConsortia

SpecConsortia

User,Testbed,

Frameworks

SpecConsortia

SpecConsortiaStandardBodies

UserNeedsR&D

Volendo cercare un punto d'inizio lo si può individuare nel Dublin Core, primo metodo di definizione dei materiali editoriali di qualsiasi tipo. Pochi anni dopo l'introduzione del world wide web (1994) sembra enorme il numero di pagine presenti, circa 500000; viene promosso un sistema di metadati (=dati di dati, descrittori) per cercare di dare una catagorizzazione semantica alle pagine web; tenendosi a Dublin, nell'Ohio, le specifiche definite verranno chiamate Dublin Core1 (DCMI, Dublin Core Metadata Initiative).

Il sistema prevede di indicizzare risorse ovunque localizzate nella rete, identificando come risorsa 'qualsiasi cosa che ha una identità', senza alcun tipo di restrizione. Non prevede l'applicazione alle sole risorse web, ma può indicizzare qualsiasi tipo di oggetto.

Sopra alla freccia sono posti quegli enti che hanno un forte carattere nordamericano, mentre sotto la freccia sono posti quelli con forte caratterizzazione europea.

Entrambi hanno contribuito alla realizzazione del reference model secondo le specifiche caratteristiche.

In particolare tutto ciò che è a base nordamericana è caratterizzato da un approccio fortemente pragmatico, funzionale, orientato al massimo dell'efficienza; ciò che è di origine europea è più orientato alla definizione precisa e formale, alla rigorosa definizione dell'oggetto, al significato semantico esatto.

L'unione degli sforzi dell'una e dell'altra parte ha portato ad un modello complesso che coniuga i punti di forza di entrambe le tipologie di attori.


Segue una descrizione2 degli enti che si occupano di standardizzazione dei materiali didattici

Si inizia con gli enti più grandi, di cui possono essere membri solo le nazioni per giungere a quelle che agiscono a scala meno ampia, di cui tipicamente fanno parte produttori di piattaforme e materiali didattici.

ISO (International Organization for Standardization)

La ricerca di standard da parte dell’ISO è finalizzata a promuovere il commercio e lo scambio di beni prodotti; membri dell’ISO sono le nazioni attraverso i loro comitati normatori.

Lavorano alle norme i technical commitee, ad ognuno dei quali possono o meno partecipare le diverse nazioni. Non è obbligatorio aderire alle norme ISO; tuttavia le nazioni possono legiferare in modo da far rendere obbligatorie queste norme.

Il 10 novembre del 1999 è stato creato un joint committee ISO/IEC che nel sottocomitato 36 si occupa delle norme per i learning standards3. Fanno parte di questo sottocomitato Australia (SAI), Canada (SCC), Cecoslovacchia (CSNI), Corea (KATS) , Norvegia (NSF), Svizzera (SNV), Ucraina (DSSU); il segretariato è affidato agli USA.

IEEE e CEN suggeriscono le proposte all’ISO.

All'indirizzo web jtc1sc36.org si trovano documenti e lavori del sottocomitato.

All'ISO possono partecipare nazioni, non aziende o singole persone.

2 Per approfondimenti, vedi http://www.ou.nl/open/psl/Bookmarks/LearnTechStandards.html

3 http://jtc1sc36.org/


CEN4 (Comité Européen de Normalisation)

CEN è a base europea ed è partner regionale di ISO, a cui è legata dal protocollo di Vienna.

La sezione che si occupa di standard didattici è sotto CEN/ISSS (Information Society Standardization System).

Fanno parte del CEN i comitati formatori delle singole nazioni; il CEN emana European Standard (EN) e documenti di armonizzazione; i primi sono norme per gli stati membri della comunità europea, i secondi raccomandazioni.

CEN/ISSS è costituito da technical commitees e da workshops; uno di questi ultimi è dedicato alle learning technologies (CEN/ISS WS/LT, nato il 25 marzo 1999); altri workshop interessanti sono quello su IT profiles and curricola e knowledge management

4 http://www.cenorm.be


IEEE5 (Institute of Electrical and Electronics Engineers)

Questo ente, a base americana, è costituito da Technical Societies/Councils e da Standards Committees & Working Groups; tra questi ultimi, si occupa di elearning il Learning Technology Standards

Committee (LTSC)6.

Per quanto riguarda quanto si dirà nel seguito, ha grande importanza il lavoro fatto dall’IEEE sui Learning Object Metadata (LOM), che è alla base dei sistemi di descrizione dei materiali didattici; la versione 1.3 di Scorm incorpora un modello di dialogo (runtime) con la piattaforma scritto da IEEE.

5 http//www.ieee.org

6 http://ltsc.ieee.org


ADL7 (Advanced Distributed learning)

ADLnet è di particolare importanza per lo studio sugli Standard: una delle attività è la cura e la emanazione del refernce model SCORM.

E’ un progetto del ministero della difesa degli Stati Uniti e dell’ufficio scientifico della Casa Bianca; lo scopo primario è promuovere l’uso delle tecnologie didattiche in modo che le industrie possano creare prodotti interscambiabili e commercializzabili; collabora con IMS e AICC, è promotore del modello di riferimento SCORM che proponte un insieme di standard prodotti da terze parti e tra loro correlati. Nonostante sia indubbiamente la proposta più diffusa sul mercato, non tutti8 sono d’accordo sulla validità del modello.

7 http://www.adlnet.org

8 Edward Welsch (assistant editor of Online Learning Magazine) SCORM: Clarity or Calamity? http://www.onlinelearningmag.com/onlinelearning/magazine/article_display.jsp?vnu_content_id=1526769


IMS9 (Instructional Management Systems Global Learning Consortium)

A base americana, è un experts group chenasce da Educause, associazione no profit di scuole e università ‘promoting the intelligent use of information technology ‘;

E' costituita dalle grandi case di sviluppo software, quali Microsoft, Autodesk, Cisco, Sun, etc.

Collabora con: ADL, IEEE, DC, AICC, ARIADNE, CEN, W3C

Ha tra i propri obiettivi rendere interoperabili le tecnologie per la formazione e supportare l’adozione delle specifiche IMS in prodotti e servizi.

ARIADNE10 (Alliance for Remote Instructional Authoring and Distribution Networks for Europe)

E’ un progetto finanziato dall’unione europea che è stato attivo negli anni 1996-2000; Insieme IMS ha prodotto le specifiche LOM presentate e approvate da IEEE

AICC (Aviation Industry CBT Committee)

E’ un gruppo internazionale di industrie aeronautiche che fin dal 1993 ha prodotto standard sulla modalità con cui realizzare i courseware; oggi (SCORM 1.2) dà un importante contributo nel modello SCORM soprattutto per quanto riguarda il run-time, cioè lo scambio di dati tra materiale didattico e piattaforma nel momento in cui avviene la fruizione.

E' da segnalare come la prima delle istituzioni che ha tentato di 'regolare' il funzionamento dell'e-learning.

9 http://www.imsproject.org

10 http://www.ariadne-eu.org/


Infine, chi norma?

ADLnet raccoglie e organiza il modello di riferimento SCORM, che a sua volta scompone il processo di formazione in diverse parti, ognuna delle quali viene fatta oggetto di specifiche normative prelevate da enti o consorzi quali IMS, IEEE, AICC che sono i veri emanatori delle norme di riferimento.

Quando SCORM recepisce le norme le contestualizza indicandone limiti e caratteristiche di applicazione.

Per esempio: IEEE è l'organo che ufficialmente emana il Learning Object Metadata (LOM v 1.0) che è il riferimento per quanto riguarda i metadati.

Nelle specifiche IEEE il modello può essere applicato per qualsiasi tipo di oggetto e nessuno dei campi da compilare è obbligatorio. Nel recepimento che ne fa ADLnet per SCORM l'applicazione è relativa ad oggetti obbligatoriamente digitali, e a seconda del tipo vengono indicati i campi ritenuti obbligatori.

conclusioni

Molti sono gli enti che si occupano di standardizzazione nel campo dell'e-learning.

ADLnet ha creato un modello di riferimento chiamato SCORM estrapolando da diversi enti le specifiche che vanno a comporre il panorama degli oggetti che concorrono a formare il sistema di e-learning.

Leggendo i book di SCORM si trovano i riferimenti a specifiche emanate da enti diversi da ADLnet ed integrate in un modello unico.


L'applicazione del reference model SCORM

In questo capitolo

Questo capitolo serve a capire come leggere i documenti del reference model Scorm.

ADLnet attraverso SCORM definisce un modello di riferimento che individua le norme da utilizzare per i diversi aspetti del processo della formazione in rete; è quindi necessario padroneggiare quali siano questi aspetti per poterli affrontare separatamente e ad essi applicare le norme di riferimento.

Si deve agire in due direzioni parallele: mentre nella prima si scompone l'anatomia di un sistema di formazione a distanza per evidenziarne i singoli componenti, nell'altra si individuano, all'interno del reference model, quali siano le parti applicabili su ognuno di essi.

La prima parte presuppone una precisa conoscenza dei sistemi FAD; non la si ottiene con la perfetta conoscenza di una piattaforma, ma con l'analisi del funzionamento di più sistemi, evidenziandone le parti comuni e le singolarità.

Si deve arrivare a scomporre le piattaforme nei componenti singoli in modo da poterli osservare separatamente e ad essi applicare la parte del reference model che, se esiste, ne definisce il comportamento.

Da questa prima parte devono essere estratti i concetti di materiale didattico, LMS, interazioni tra materiali e LMS, metadati, packaging, struttura del corso.

Nella seconda parte si deve conoscere l'impianto generale con il quale sono scritte le norme e riuscire ad isolarne le parti che interessano applicandole agli oggetti che costituiscono le piattaforme.

Una volta chiarite le parti soggette al modello di riferimento e la modalità della loro realizzazione secondo gli standard può iniziarsi il processo di creazione o modifica di materiali didattici o piattaforme LMS. Il lavoro risulta molto più complesso per chi crea piattaforme piuttosto che per chi crea materiali didattici.

Va comunque ricordata che l'applicazione di SCORM di per se non porta a vantaggi immediati; se ne deve recepire la filosofia di fondo per poter utilizzare al meglio le potenzialità di un'archiettura così vasta e complessa.

L'applicazione del reference model SCORM - 14

introduzione

SCORM non è uno standard: è un reference model. Questo significa che non emana specifiche normative, ma individua per ogni aspetto tecnico della formazione a distanza quali norme, erogate da diversi enti, devono essere prese in considerazione.

Ciò consente alcune prime considerazioni: non si va ad incidere sulla qualità didattica della formazione a distanza, ma sulla modalità tecnica della sua erogazione.

In questo capitolo ci si occupa dello stabilire a quali sezioni del reference model devono conformarsi i componenti un sistema di formazione a distanza.

Per questo la spiegazione deve procedere con i seguenti passi:

• Definire ed isolare i diversi componenti di un sistema di fad

• Abbinare ad ogni parte il riferimento SCORM relativo

• Evidenziare la regola (e l’ente che la emana) nell’ambito del reference model di SCORM

E' una sezione fondamentale per capire la struttura di SCORM

Il semplice definire ‘standard’ una sistema FAD non è parametro sufficiente per conoscerne il comportamento e l’applicabilità a diversi materiali/ contesti formativi; sapere che un sistema è definito standard secondo

SCORM1.2 - LMS–RTE2 - SCO–RTE1 - MD-XML1+Extensions - ADLCP-PIF1

potrebbe avere poco senso se non vengono indagati e capiti i significati delle sigle.

Componenti di un sistema FAD


Questa è una parte fondamentale per conoscere il funzionamento degli standard, alla fine della quale si potrà capire il significato delle sigle di conformità dei sistemi formativi e si saprà attingere alle relative norme di riferimento.

Abbiamo visto che aderire a SCORM vuol dire aderire ad un reference model, ovvero ad un insieme di norme che globalmente definiscono l’intero processo formativo in rete.

Per poter capire dove applicare le norme, è necessario fare una analisi del funzionamento del sistema tecnologico; solo in questo modo è possibile evidenziare i punti sui quali è presente definire una normativa.

Un sistema di formazione a distanza può essere visto come composto da quattro ‘colonne’ fondamentali:

1. i materiali didattici o courseware

2. la piattaforma tecnologica di erogazione dei corsi

3. le risorse umane che a vario livello contribuiscono al funzionamento del sistema

4. il sistema organizzativo che permette agli utenti la fruizione dei corsi.

Gli standard qui in discussione riguardano i primi due punti, cioè si riferiscono alla parte tecnologico/implementativi del processo; i punti 3 e 4, che sono sicuramente i punti chiave per l'ottimale funzionamento del processo formativo, sono al di fuori di queste note perché non interessate dagli standard.

I materiali didattici

I materiali didattici o courseware sono costituiti da quei documenti (testi, audio, video) che, presenti in diverso formato, contengono le informazioni che si vogliono veicolare agli utenti.

Spesso definiti come courseware, sono il 'libro' intorno al quale ruota la formazione a distanza. In essi sono presenti le nozioni da apprendere.

Possono presentarsi in varia forma, ma in ogni caso sono all'interno di un 'contenitore' HTML, ovvero assumono le sembianze di una pagina web o di più pagine tra loro collegate.

Perché i materiali siano SCORM devono, tra le altre cose, obbligatoriamente effettuare 'chiamate' verso la piattaforma (vedi più avanti).

All'interno di queste pagine web sono presenti i testi, le immagini, i video che costituiscono la materia della formazione; 'annegati' dentro le pagine ci sono i comandi che consentono l'interazione scorm con la piattaforma.


Nel caso di materiali animati sviluppati con Macromedia Flash, all'interno del contenitore HTML è presente un file SWF (quello generato da Flash) che contiene il materiale didattico e le eventuali chiamate verso la piattaforma.

Utilizzando lo stesso procedimento qualsiasi materiale didattico può diventare un materiale SCORM: semplicemente fornendogli l'involucro HTML che fa le chiamate necessarie; anche se, in questo modo, non vengono sfruttate le potenzialità del reference model.

Esempio: sono presenti materiali non scorm in forma di file di Word o Excel, già preparati, e li si vuole fare diventare oggetti SCORM. Astraendo da qualsiasi concetto di granularità dei contenuti, l'intero file può essere inserito come oggetto da scaricare mettendo il link su una pagina web; questa pagina web possederà l'involucro SCORM che renderà il materiale adattabile alle piattaforme.

E' un meccanismo barbaro per creare materiali didattici; non sfrutta alcuno dei vantaggi di SCORM, se non la possibilità di caricare velocemente i materiali su una piattaforma; può essere usato solo in casi di estrema necessità.

I materiali creati da zero o portati a SCORM possiedono capacità di colloquio con la piattaforma che consentono personalizzazioni, schemi di apprendimento variegati, salti condizionali, salvataggio di dati tra una sessione e l'altra di formazione, comunicazione con il contesto della piattaforma, e tante altre possibilità che arricchiscono il potenziale didattico, la riusabilità dell'oggetto e l'economicità dello sviluppo. processo formativo, sono al di fuori di queste note perchè non interessate dagli standard.

la piattaforma di formazione

La piattaforma di formazione è la base intorno alla quale ruotano tutti i processi formativi; costituita da un sito web, è il collante che collega l'utente con i materiali didattici, con i tutor o altre persone (esperti, gestori, etc) coinvolti nel processo formativo, con i dati prelevati dalle precedenti fruizioni o ricavati dalle azioni degli altri attori.


Questo collante agisce come strumento di comunicazione, smistando le informazioni originate verso i loro destinatari. Per definire le modalità do comunicazione che ha una piattaforma possiamo distinguerle a seconda dell'origine e del destinatario delle informazioni da comunicare.

Esistono sottosistemi finalizzati alla comunicazione tra persone: in questo caso sia l'emittente che il ricevente del processo comunicativo è costituito da un attore umano del processo formativo. L'informazione è generata durante la fruizione del corso e ne caratterizza il funzionamento.

Possiamo citare: posta, forum, chat, aule virtuali, video e audio conferenze, etc.

In altri sottosistemi l'informazione può essere generata in modo non direttamente correlato con l'azione di una persona ma con l'azionamento di un meccanismo: per esempio una bacheca intesa nel senso di raccolta di files utili, un sistema di monitoraggio che consenta al tutor di vedere i progressi degli utenti, una linkografia che porti i corsisti verso siti di approfondimento.

I materiali didattici vanno intesi in questa seconda accezione: sono oggetti statici (dal punto di vista del meccanismo di generazione delle informazioni!!!!) che portano informazioni didattiche verso gli utenti.

Ed è proprio su questo tipo di materiali che si possono applicare i dettami del reference model SCORM; per questo una piattaforma LMS può avere alcuni sottosistemi per nulla interessati dal reference model che entra in gioco solo quando si parla di materiali didattici precedentemente preparati; aderire a SCORM, per un LMS, significa avere una parte del proprio sistema in grado di importare materiali secondo le specifiche; non si applica cioè all'intera piattaforma.


le interazioni tra materiali didattici e piattaforma

Di seguito si parlerà di materiali didattici sotto forma digitale e di piattaforme che usano internet (ed in particolare il web) come forma di comunicazione.

Distinguiamo due diversi aspetti dei materiali didattici: il primo riguardante il contenuto ed un secondo riguardante il processo di fruizione.

Per quanto riguarda il primo punto, il contenuto, ad oggi gli standard non riguardano il contenuto dei materiali didattici: riguardano unicamente la modalità con cui i contenuti vengono creati ed il rapporto che hanno con l'LMS.

E’ cioè possibile costruire un corso perfettamente standard con contenuti pessimi dal punto di vista didattico, in quanto la qualità didattica dei contenuti non viene messa in discussione dagli standard.

Cio’ che viene regolato riguarda la strutturazione del materiale didattico, ovvero la modalità di costruzione, ed i meccanismi di colloquio con la piattaforma.

Per quanto riguarda il secondo punto, il processo di fruizione, deve essere presente

• una modalità di veicolazione del corso all’utente, che sia in grado di visualizzarne i contenuti

• un modalità di comunicazione tra la piattaforma e il contenuto che consenta l'interazione


tra i due, per esempio per il tracciamento delle operazioni svolte dall’utente.

L’insieme delle operazioni viene svolto all’interno di un ambiente di funzionamento (run-time environment) oggetto di standardizzazione.

Dal momento in cui l’utente entra in un sistema di formazione e comincia a fruire di un corso, devono avvenire operazioni di tracking delle azioni svolte; alcune sono classiche e da tutti utilizzate (es.: quanto tempo è passato dall’inizio alla fine della fruizione), altre possono essere impostate dall’autore del materiale che inserisce nello stesso modalità di comunicazione e tracciamento verso la piattaforma, che deve fornire metodi standard per effettuarle.

In questa prima, semplificata, fase di suddivisione abbiamo distinto l’oggetto di standardizzazione in tre semplici elementi:

1. la strutturazione del materiale didattico

2. la visualizzazione del materiale didattico

3. il colloquio tra piattaforma e materiale didattico

Con un piccolo, ulteriore approfondimento si può ampliare il ragionamento ed avere un panorama globale dell’azione di standardizzazione.

la struttura: il modello di aggregazione dei contenuti

Per quanto riguarda la strutturazione del materiale didattico, ogni corso deve essere diviso in sezioni più piccole; può essere usato l’esempio di suddividere un libro in capitoli.

Ogni oggetto elementare dal punto di vista didattico, o learning object, deve essere per quanto possibile autonomo dal resto del corso e reggersi in piedi da solo; ciò fa sì che lo stesso oggetto possa essere riutilizzato in contesti diversi. Il reference model SCORM chiama questi oggetti SCO


(Sharable Content Object), altri enti dànno definizioni leggermente diverse (RLO reusable learning object, RIO reusable information object, etc), ma il concetto è sempre quello della scomposizione in mattoncini elementari ricomponibili l’intero corso.

Sta in questo concetto la grandezza (per alcuni) o il difetto (per altri) del modello scorm.

Chi lo difende, fa leva sulla elevata riusabilità, condivisione, flessibilità di un sistema ad oggetti componibili; chi ne è detrattore, trova il limite nella definizione vaga di singolo oggetto, nella difficoltà nell’accostare oggetti diversi, nella trasparenza didattica richiesta vede un oggettivo limite alle capacità didattiche.

A valle della divisione di un corso in SCO vi è ancora la possibilità di suddividere i componenti in SCA (capitoli -> paragrafi) come unità, non autonome, comunque riutilizzabili in contesti diversi; a valle di questi vi sono singoli items (testi, disegni, fotografie) comunque indicizzabili e riutilizzabili.

A partire dalla versione 1.3 viene saltato il passaggio degli SCA per passare direttamente agli assets, unità elementari.

I livelli di definizione degli oggetti diventano così tre, diversi funzionalmente:

1. il livello più alto è il corso, o content aggregation, che è costituito dall'aggregazione di più SCO.

2. il livello inferiore è lo SCO, assimilabile al learning object, costituito da una unità di apprendimento autonoma, che può essere associata ad altri SCO per costituire il corso. E' in grado (e deve) colloquiare con l'LMS, possiede le chiamate necessarie (vedi dopo, runtime) per inizializzare e terminare il processo di fruizione.

3. il livello elementare è costituito dall'asset, costituito da una immagine, un grafico, un testo o qualsiasi oggetto che non colloquia con la piattaforma ma può essere riutilizzato in più SCO; per esempio un grafico con il diagramma di Mollier per gli stati fisici dell'acqua può essere utilizzato come asset sia in un corso di termodinamica che in un corso di meccanica dei fluidi.

Un corso è costituito da un filo (content aggregation) che lega, aggrega tutti i contenuti utilizzati e li presenta come una unità all’utente.

La modalità tecnica di raccoglimento di tutti i dati (files) che costituiscono un corso ha importanza fondamentale in termini si riutilizzabilità: è per questo che anche questa modalità è oggetto di standardizzazione, sia per quanto riguarda come unire in unico contenitore i files sia per quanto riguarda la modalità di recupero e aggregazione dei contenuti all’interno del contenitore.

Questa aggregazione è costituita da un indice che tiene traccia di tutti i componenti del corso; a partire da una radice individua tutti gli SCO che fanno parte del corso, e per ogni SCO individua i singoli assets.


I metadati: descrittori degli oggetti.

I metadati sono dati di dati: descrivono con strutture predefinite gli oggetti didattici. Il cartellino sul quale, un tempo, in ogni biblioteca venivano annotati i dati dei libri all'interno di uno schedario è un esempio semplice di scheda con metadati.

Abbiamo visto che i tre livelli di riferimento sono i corsi, gli SCO, gli assets. Perchè sia possibile un riutilizzo degli stessi è indispensabile che ognuno sia descritto; ci deve essere cioè una spiegazione del corso che ne indichi lo scopo, le caratteristiche, la durata, i destimnatari etc; così deve essere per gli SCO, in modo che sia possibile analizzare tutti quelli presenti in un corso e magari estrarne qualcuno per riutilizzarlo in altri corsi. Altrettanto dicasi a livello di assets: più si descrivono questi oggetti e più semplice sarà il loro riuso.

A questo punto potrebbe farsi una osservazione: non sarebbe più semplice vedere direttamente i corsi, gli sco, gli asset per decidere come sono fatti e se sono riutilizzabili, piuttosto che descriverli attraverso i metadati? La risposta sta nella semplicità d'uso: mentre la visione diretta richiede tempo, visualizzatori appositi a seconda del tipo di materiale, analisi complesse, l'analisi dei metadati è più facilmente effettuabile a livello informatico, l'omogeneizzazione dei dati consente un confronto più semplice, sono direttamente presenti analisi e giudizi sui contenuti altrementi più difficilmente estraibili.

I metadati sono quindi dati che spiegano gli oggetti didattici e sono riscontrabili sia a livello di corso che di SCO che di asset.

Il packaging

Il riutilizzo dei materiali didattici comporta che sia ben definita la modalità con la quale i file viaggiano da una piattaforma all'altra.

Per questo deve essere predisamente individuata la modalità con la quale 'impacchettare' i materiali didattici cosi' che possano facilmente transitare tra sistemi; da una piattaforma LMS all'altra oppure da un sistema di authoring verso una piattaforma.


Il colloquio con la piattaforma

Quanto detto finora riguarda il materiale didattico nella sua versione statica, ovvero non ancora fruita dall'utente. Perchè un utente possa fruire di questo materiale occorrono ancora due passaggi:

• il materiale deve essere fruibile, cioè visualizzabile dall'utente presso la propria postazione di lavoro;

• il materiale deve essere attivo, cioè interagire con l'LMS. Questo a diversi scopi: per esempio il tracking, che consente di sapere a che punto è arrivata la fruizione cosi' da proporre all'utente la giusta pagina, o per registrare i risultati di un test, o ancora per proporre all'allievo il giusto SCO. Perchè esista questa interattività deve esistere un meccanismo di colloquio tra materiale e piattaforma.

L'interazione è di due tipi: dapprima l'utente all'interno di un corso può avere alcuni gradi di libertà nel decidere quale parte del materiale didattico fruire e quindi, una volta effettuata la decisione, ci deve essere una interazione che indichi durante la fruizione ciò che avviene.

La visualizzazione

Sembra un aspetto scontato ma non lo è: il materiale deve essere visualizzato dall'utente, in modo che possa fruire delle nozioni presenti. SCORM si riferisce solo a materiali digitali; si tratta quindi della visualizzazione di files.

Il particolare meccanismo di funzionamento inoltre richiede che la visualizzazione della parte principale del materiale avvenga all'interno di un browser o client http. Il materiale deve quindi essere realizzato come pagine HTML, similmente a quanto si fa per costruire siti web.

Ciò non significa che il materiale deve solo essere costituito da pagine web: esse devono essere la traccia ma, similmente a quanto avviene nei siti, possono essere forniti materiali disponibili attraverso download di diverso tipo (presentazioni powerpoint, video, animazioni flash, disegni autocad etc.)

Perchè possa funzionare il meccanismo di scambio dati il materiale deve essere visualizzato in un child della finestra della piattaforma, cioè in una sotto-finestra dipendente da quella principale. Ciò significa che deve essere visualizzato in un frame o in una finestra di pop-up.

Per chi sviluppa materiali didattica è un importante punto da tenere in conto durante il progetto dell'architettura grafica .

L'interazione con l'LMS: i gradi di libertà, navigazione e sequenziamento

Come abbiamo già visto un corso può essere costituito da diversi SCO.

la modalità con la quale l'utente accede ai diversi SCO può essere diversa: potrebbe avere un indice con tutti quelli presenti nel corso e decidere quale fruire in base alle proprie personali convinzioni, oppure essere obbligato a seguire il primo e, solo al termine di quello, passare al secondo e così via. Oppure potrebbero esserci test vincolanti che non permettono di passare alla


lezione successiva se non si è superato il test. O, ancora, deve essere possibile in fase di ripasso poter accedere a tutti gli SCO e in fase di studio poter accedere solo in modo sequenziale.

Gli esempi presentati spiegano cosa sia il sequenziamento; il progettista del materiale didattico è in grado di prevedere il tipo di sequenziamento e far si che l'LMS, qualsiasi LMS, si comporti esattamente come l'autore ha previsto.

All'interno di un singolo SCO, inoltre, l'utente può passare da una pagina all'altra in modo libero o imponendo un tipo di scorrimento tra le pagine prefissato, a scadenze temporali o logiche. Anche in questo caso, il progettista del materiale può imporre un tipo di navigazione all'interno dello SCO; sarà l'LMS a fornire i meccanismi di navigazione tra le pagine.

L'interazione con l'LMS: prima della fruizione

Fin quando il materiale è all'interno di una banca dati e non viene fruito da alcun utente non c'è alcuna interazione con l'LMS, se non quella di riportare al massimo il titolo dell'oggetto didattico.

Da quanto un utente comincia a richiederne la fruizione comincia un rapporto di scambio dati tra materiale e piattaforma , che può essere scarno oppure molto intenso.

Chiariamo prima il meccanismo:

1. L'utente apre il sito in cui è presente l'LMS; può procedere a visitare molte parti che non richiedono che venga effettuato un login. In questa fase, tipicamente, non può fruire di corsi se non a quelli aperti all'utente ospite, che qui non vengono presi in considerazione

2. L'utente effettua un login. Da questo momento è riconosciuto come uno degli iscritti all'LMS, che presenta un elenco di corsi fruibili. Il materiale non è ancora stato interessato, non effettua alcuna comunicazione.

3. L'utente sceglie di fruire un corso tra quelli che ha a disposizione. A questo punto comincia l'interazione del materiale didattico con la piattaforma, che al minimo consiste in una


chiamata che indica lla piattaforma che il materiale x sta per essere fruito dall'utente y e da una chiamata che indica che l'utente y ha terminato la fruizione del materiale x; tra queste due chiamate 'estreme' possono essere inserite (dagli autori dei materiali didattici) molte altre chiamate.

Durante questi colloqui che avvengono tra materiale e piattaforma devono essere stabiliti due modalità, come in qualsiasi processo di comunicazione: COME comunicarsi i dati e QUALI dati possono essere comunicati.

Un esempio: se il progettista dei materiali didattici ritiene di voler inserire, in alto a destra, il nome dell'utente che sta fruendo il materiale non può naturalmente scriverlo nel momento in cui viene creato il materiale didattico.

Tuttavia il creatore del materiale può precedere una chiamata alla piattaforma richiedendo il nome dell'utente e quindi andarlo a scrivere in alto a destra. Ogni volta che un utente utilizzerà quel materiale la piattaforma fornirà il nome dell'utente che in quel momento sta fruendo il materiale.

L'interazione con l'LMS: durante la fruizione

Fin quando il materiale è all'interno di una banca dati e non viene fruito da alcun utente non c'è alcuna interazione con l'LMS, se non quella di riportare al massimo il titolo dell'oggetto didattico.

Da quanto un utente comincia a richiederne la fruizione comincia un rapporto di scambio dati tra materiale e piattaforma , che può essere scarno oppure molto intenso.

Chiariamo prima il meccanismo:

1. L'utente apre il sito in cui è presente l'LMS; può procedere a visitare molte parti che non richiedono che venga effettuato un login. In questa fase, tipicamente, non può fruire di


corsi se non a quelli aperti all'utente ospite, che qui non vengono presi in considerazione

2. L'utente effettua un login. Da questo momento è riconosciuto come uno degli iscritti all'LMS, che presenta un elenco di corsi fruibili. Il materiale non è ancora stato interessato, non effettua alcuna comunicazione.

3. L'utente sceglie di fruire un corso tra quelli che ha a disposizione. A questo punto comincia l'interazione del materiale didattico con la piattaforma, che al minimo consiste in una chiamata che indica lla piattaforma che il materiale x sta per essere fruito dall'utente y e da una chiamata che indica che l'utente y ha terminato la fruizione del materiale x; tra queste due chiamate 'estreme' possono essere inserite (dagli autori dei materiali didattici) molte altre chiamate.

Durante questi colloqui che avvengono tra materiale e piattaforma devono essere stabiliti due modalità, come in qualsiasi processo di comunicazione: COME comunicarsi i dati e QUALI dati possono essere comunicati.

Un esempio: se il progettista dei materiali didattici ritiene di voler inserire, in alto a destra, il nome dell'utente che sta fruendo il materiale non può naturalmente scriverlo nel momento in cui viene creato il materiale didattico.

Tuttavia il creatore del materiale può precedere una chiamata alla piattaforma richiedendo il nome dell'utente e quindi andarlo a scrivere in alto a destra. Ogni volta che un utente utilizzerà quel materiale la piattaforma fornirà il nome dell'utente che in quel momento sta fruendo il materiale.

Corrispondenza del reference model SCORM ai componenti della FAD

A questo punto sono stati isolati i componenti del sistema di formazione a distanza e può essere affrontato il bookshelf (scaffale) SCORM.

In questo ipotetico scaffale esistono diversi libri di colore diverso, ognuno abbinabile ad una delle parti prima definite

1 Overview è una panoramica di sistema valida a livello generale

2 Il content aggregation model descrive nel dettaglio come strutturare sia logicamente che fisicamente i contenuti del amteriale didattico; è la parte più 'anziana' e 'solida' del reference model, i numerosi feedback degli anni passati la hanno irrobustita. Per i contenuti, in particolare


2.1 Metadata affronta la modalità con la quale scrivere i descrittori; si basa su un modello di IEEE, il Learning Object Metadata, ed indica nel dettaglio la modalità di scrittura dei metadati compreso il binding, cioè il modo di scrivere in un unico file i metadati.

2.2 Content Structure indca la modalità con cui strutturare i dati in corsi / sco /assets, prevedendo tutte le possibilità di insiemi e sottoinsiemi di corsi/oggetti. Le specifiche derivano da AICC

2.3 Content Packaging indica le modalità con cui 'impacchettare' fisicamente l'insieme di files che costituiscono il corso in modo che siano scambiabili tra LMS, e tra LMS e sistemi di authoring

2.4 Sequencing Information descrive quelle parti di sequenziamento che sono impostabili a livello di corso prima che ne avvenga la fruizione.

3 Sequencing and navigation è la parte più 'nuova' del reference model e risente della relativa 'giovinezza' e della limitata applicazione e feedback d'uso; è sicuramente la lettura meno facile, finisce con pagine di pseudo-code che indicano nei dettagli la modalità di implementazione degli LMS SCORM.

4 Run Time Environment è la parte dedicata alle interazioni nel momento della fruizione tra materiale e piattaforma. In SCORM 1.3 (quello qui riportato) le specifiche vengono prese da IEEE, mentre in SCORM 1.2 erano prelevate da AICC; ciò porta a differenze non da poco, che non rendono interoperabili materiali/piattaforme costruite secondo i due standard.

4.1 la parte API indica la modalità con la quale possono essere eseguite le chiamate, definendo nel dettaglio il modello di funzionamento che fa uso di Javascript:

4.2 la parte Data Model descrive le singole chiamate, possibili risposte e comportamento dll'LMS

In totale si tratta di più di un migliaio di pagine di documentazione; quasi tutte indispensabili per capire il modello di funzionamento di SCORM. All'infuori delle spiegazioni tecniche delle singole chiamate e dello pseudo-code di implementazione di sequencing & navigation, tutto il resto merita una attenta lettura da parte di chi è interessato a sviluppare materiali o piattaforme SCORM, o semplicemente per chi vuole capire nel dettaglio il funzionamento di questo magnifico accrocchio.

Non è una lettura facile; soprattutto le parti nuove (S&N) non sono scritte in modo scorrevole, risentono della recente implementazione. Al di là di qualche parola effettivamente disarmante (nel


simple sequencing si dice che non si chiama 'semplice' perchè è facile, tutt'altro..., si veda la lavagna originale sotto riportata) si respire comunque un'aria di logicità e di pragmaticità nello scrivere questo reference model.

Come si presenta un corso SCORM

In questi appunti non si può entrare nel dettaglio tecnico dell'implementazione dei corsi; spero di riuscire ad aggiungere alcune parti espressamente dedicate al modo con cui scrivere, tecnicamente, i corsi SCORM.

Tuttavia si può dare uno sguardo d'insieme:

Un package, cioè un file zippato con estensione PIF, avrà nella root un file di nome imsmanifest.xml (manifest file) e, raccolti o meno in cartelle, tutti i materiali che costituiscono il corso(physical files).

All'interno del manifest file saranno presenti diverse sezioni: metadata per le descrizioni, organizations per definire come è strutturato il corso, resurces per descrivere i file utilizzati; eventualmente sub-manifests per suddividere i corsi in sotto-corsi.


conclusione

L'iniziativa americana ADLnet ha prodotto SCORM, che è un'insieme di regole che definiscono le modalità di funzionamento e interazione dei componenti di un sistema di formazione a distanza; in particolare vengono definiti i modelli con i quali costruire i materiali didattici e le piattaforme di formazione a distanza, con lo scopo di ottenere la massima indipendenza e interoperabilità tra gli uni e gli altri.

Il materiale didattico SCORM, ovvero il corso, è costituito da learning objects aggregati a diverso livello; tanto il corso quanto i l.o. possono essere descritti attraverso metadati, che sono descrittori come titolo, autore, versione, etc. All'interno del materiale didattico è possibile descrivere sia le regole con le quali deve essere erogato (quale l.o. prima, quale dopo) che i dati scambiati con la piattaforma (LMS) di erogazione.

Dal punto di vista del supporto, il materiale didattico si presenta come un unico file compresso che ha all'interno

• un descrittore del corso in formato XML dal nome imsmanifest.xml in posizione di root che contiene informazione sulle risorse presenti, sulla loro organizzazione, e la descrizione di corso e risorse

• l'insieme dei files che costituiscono il corso

La piattaforma di erogazione (LMS) SCORM è in grado di importare ed erogare materiali SCORM, garantendone il funzionamento che è stato impostato dall'autore del materiale didattico. Attraverso meccanismi di comunicazione standard dialoga con il materiale didattico e immagazzina i dati di fruizione degli utenti.


Learning objects?

in questo capitolo

Questo capitolo è finalizzato a capire cosè un learning object.

Già a partire dal titolo il punto interrogativo segna l'aleatorietà della definizione; non è facile trovare persone che siano d'accordo su cosa sia un LO.

In questa parte viene unicamente considerata l'accezione del LO per quanto riguarda SCORM, cioè come oggetto tecnico, non come oggetto contenutistico..

la maggior parte delle controversie nasce proprio dal confondere i due piani, mescolando la definizione tecnica con quella didattica o contenutistica.

Il fiorire di diverse definizioni (moduli, unità didattiche o di apprendimento, lezioni, etc) non ha fatto che aumentare la confusione.

La strutturazione in Learning Objects

Il concetto sul quale si basano tutti gli standard, tanto per le piattaforme quanto per i contenuti, è quello dei learning objects, traducibile in italiano in molti modi diversi, ognuno errato per qualche motivo; unità didattica potrebbe essere un buon termine se non portasse ad equivocare con molti altri progetti che lo utilizzano.

Un LO è una unità autonoma sulla quale si basa il percorso di apprendimento; organizzando opportunamente diversi LO si ottiene un corso.

Nella figura l’implementazione di Autodesk: in questo caso l’implementazione parte da Raw Content, semplici contenuti di base senza autonomia didattica (SCORM li chiama Assets; possono o meno avere descrittori metadata) che possono essere riuniti in RIO, a loro volta riunibili in RLO, l’analogo dei Learning Object: questi hanno autonomia didattica ed un set obbligatorio di metadata di descrizione.

A livello superiore ci sono due sovrainsiemi: c’è la lezione ed il corso.

Learning objects? - 30

E’ bene chiarire che, non essendoci uno standard unico, non esiste una definizione univoca di learning object; soprattutto non esiste una chiara norma su come deve essere fatto un LO, mentre sono chiare le indicazioni su:

1. come descrivere il metadata del LO

2. come distribuire metadata e LO in files

3. l’interazione tra LO e LMS

La divisione del contenuto didattico di un corso in ‘oggetti’ riutilizzabili è alla base di molti sistemi di standardizzazione dei materiali didattici per la formazione in rete.

Tuttavia, non per tutti i sistemi l’oggetto risultante dalla scomposizione del corso è definito allo stesso modo.

Anche un libro, strutturato in capitoli e paragrafi, potrebbe essere un esempio di divisione di un corso (libro) in learning object (capitoli) a loro volta costituiti da assets (paragrafi).

Termini come LO, RLO, SCO a volte vengono utilizzati in modo intercambiabile; approfondendo il significato che viene attribuito ai termini si possono evidenziare le differenze. Da queste differenze nascono pregi e difetti delle diverse ‘concezioni’ dell’oggetto elementare.


In particolare nei confronti dell’oggetto SCO, definito da ADL nel framework SCORM, le caratteristiche, e le critiche che ne derivano, sono relative a:

• Definizione poco chiara della grandezza dello SCO, definita in termini di obbiettivi didattici

• Indipendenza dagli altri oggetti e dal corso stesso; se da una parte ne migliora la riutilizzabilità, dall’altra implica la costruzione di oggetti ‘blindati’ che non comunicano con l’esterno; “esclude quindi ogni persona, cosa, o idea esistita da quando è nato l’universo che può essere referenziata dal percorso formativo”11;

• Neutralità pedagogica: per alcuni è un progio, consentendone un facile riuso, per altri è un aspetto negativo (o un mito!), non permettendo un particolare approccio pedagogico.

Di seguito alcune definizioni dell’”oggetto elementare”:

IEEE: Any entity, digital or non-digital, which can be used, re-used or referenced during technology-supported learning (IEEE Learning Technology Standards Committee)

Merrill: knowledge object, componet of instruction

ARIADNE: pedagogical document

NSF: ‘escot’ educational software component

MERLOT: on line learning materials

Apple: Learning Interchange ‘resources’

SCORM: One activity of the process of creating and delivering learning experiences involves the creation, discovery and gathering together, or aggregation, of simple assets into more complex learning resources and then organizing the resources into a predefined sequence of delivery12

In base all'esperienza...

Per quella che è l'esperienza personale di chi scrive, il learning object è costituito da una unità di apprendimento su un argomento il più possibile definito, con pochi collegamenti con altri oggetti di contenuto simile, della durata media da parte dell'utente di circa mezz'ora.

Questa non è una definizione ma un buon punto di partenza. Chi fa da coordinatore per lo sviluppo di materiali può utilizzarlo per impostare la base della discussione con gli attori di processo, in particolare

• con gli esperti di contenuto che dovranno fornire la materia prima per i materiali didattici, in modo che strutturino argomenti/conoscenze che cadano in una griglia così predefinita;

• con i curatori della piattaforma LMS di riferimento, per far sì che gli oggetti creati siano il

11 Whiley, D. A. (2000), “connecting learning objects to instructional design theory: a definition, a metaphor, a taxonomy”; http://www.reusability.org/read/chapters/wiley.doc

12 SCORM 1.2 Content Aggregation Model


più possibile riutilizzabili già dal primo impiego;

• con i responsabili di una eventuale repository nella quale organizzare i contenuti;

• con i responsabili dell'assistenza all'apprendimento o del tutoring.

La fase di definizione del 'mattoncino di base' è di importanza fondamnetale per la riuscita del sistema di formazione, va curata nei minimi particolari.

Una volta chiarito che il LO deve avere una propria unitarietà per quanto riguarda l’argomento di apprendimento, si deve mediare tra due estremi:

1. costruire LO molto piccoli: ciò consente l’estrema flessibilità e riusabilità dei LO, ma richiede lo sforzo di descrizione dei metadata (fino a d 80 campi nel modello IEEE) che richiede tempo e risorse

2. costruire LO molto grandi; consente di minimizzare la scrittura dei metadata, di accorpare tutti i materiali in una unica struttura; lo svantaggio risiede nella poca riutilizzabilità degli oggetti così creati.

Alcune considerazioni estratte da passate esperienze possono essere d’aiuto:

• un LO ha una durata approssimativa tra i 10 minuti e la mezz’ora (NETg: 30 minuti13)

• CISCO: ‘Reusable Learning Object:focus on a single job task, are similar to a short lesson, and should contain no more than 7 plus or minus 2 reusable information objects’

• Con il concetto di ‘seduta’: meaningful division of learning that is accomplished by a student in a continuous effort—that is one sitting" (Jordan, Mann, & Regalado, 2000).

• Paragonando le lezioni tradizionali: to be similar in scope and nature to the content of a typical "lesson" so as to create instruction, not merely information (Downes, 2000).

• Focalizzando sugli obbiettivi: Develop the instructional content of a learning object so that it is able to satisfy a single learning objective (Longmire, 2000).

• Focalizzando sui contenuti: Develop content objects that are independent of other content, which can be recombined for various outcomes. Each learning object must be able to stand alone so that confusion is not caused by references to previous topics not visibly seen (Centre for Learning Technologies, 2000; Eaton, 1996; Quinn, 2000).

• Altre considerazioni si possono trovare sul sito Learning Circuits14

13 http://www.netg.com/14 Un buon articolo può essere Warren longmire, A Primer on Learning Objects,

http://www.learningcircuits.org/mar2000/primer.html


I metadati

in questo capitolo

In questo capitolo viene spiegato cosa sono i metadati e come vengono implementati nel reference model.

I metadati sono descrittori delle risorse utilizzate come materiali didattici; dopo una breve introduzione, verranno analizzati i metadati suggeriti e quindi verranno portati tre esempi di compilazione; successivamente viene presentato il binding15 (la scrittura in file)dei dati.

E’ bene ricordare che esistono tools particolari per la compilazione e il binding dei metadati, anche se tutto può essere eseguito usando un semplice editor di testo. Questi tools semplificano la redazione e la scrittura in file.

Una volta descritte le risorse didattiche in questo modo, apposite content repositories possono occuparsi del loro immagazzinamento, archiviazione, ricerca e catalogazione.

Sistemi di catalogazione dei materiali didattici

Analisi dei sistemi esistenti

CAREO

A base canadese, il Campus Alberta Repository of Educational Objects è un esempio molto simile al progetto proposto. Infatti lo standard con il qale vengono immagazzinati i materiali didattici è derivato a IEEE LOM, adattandolo alle proprie esigenze e definendo il loro protocollo: CanCore Metadata Protocol. In questo caso viene utilizzato un tool opensource, ALHOA, per classificare gli oggetti didattici. Il sito è liberamente visitabile, ci si può iscrivere per vedere ed inserire oggetti didattici.

ETB

L’European Treasury Browser è a base europea ed è stato costruito per docenti che vogliano utilizzarne la capacità di immagazzinare e distribuire oggetti didattici. Anche in questo caso può essere preso come esempio, ma negativo: l’aver utilizzato un proprio sistema di catalogazione degli oggetti didattici, distante da quelle che sono le indicazioni internazionali, ha portato alla non-interoperabilità verso sistemi diversi, e quindi ad un precoce invecchiamento e inutilizzo del

15 Rappresentazione in XML dei metadati

I metadati - 34

sistema.

Merlot

Una segnalazione a parte va fatta per lo statunitense Multimedia Educational Resource for Learning and Ondine Teaching per l’utilizzo massiccio che ne è stato fatto. Contiene migliaia di oggetti didattici, è un sistema aperto a tutti sia in consultazione che in immissione. Un meccanismo di voto associato con il numero di richieste consente di stilare una ‘classifica’ degli oggetti didattici, indicandone i migliori.

E’ basato su IEEE LOM, consente l’indicizzazione e la ricerca delle risorse. E’ utile provare a fare una ricerca per un particolare argomento di insegnamento per notare quanti materiali siano già pronti e disponibili (naturalmente in lingua inglese).

EDNA

A base australiana, è libero per docenti che lì operano.

Si bassa su Dublin Core (progenitore di IEEE LOM, quindi in parte compatibile), e in questo caso indicizza solo risorse web, cioè materiali didattici disponibili ondine. Non si occupa dell’immagazzinamento di file, ma solo della catalogazione delle risorse altrove disponibili

Canada SchoolNet

E’ un progetto molto simile al precedente, più esteso nel database, dedicato a docenti canadesi.

ARIADNE Knowledge Pool System

Questo progetto, europeo, assume rilevanza particolare grazie alla sua natura distribuita. Il sistema consente di creare più repositories di materiali didattici tra loro collegate, unendo come risorse uniche quelle derivanti da sistemi diversi. Sicuramente un sistema aperto a qualsiasi sviluppo futuro. Basato su IEEE LOM, fornisce un tool gratuito per la catalogazione ed

immissione delle risorse.

SeSDL

Il progetto Scottish electronic Staff Development Library conserva alcune particolarità che lo rendono unico, in particolare nel rapporto con lo standard SCORM per le risorse didattiche. In questo caso è possibile caricare risorse didattiche non strutturate ed averne in risposta un corso strutturato secondo SCORM 1.2 in unico file compresso.

The Learning Matrix

Come ultimo esempio la Learning Matrix è il risultato statunitense degli sforzi del governo Clinton-Gore (1992-2000) per promuovere lo sviluppo delle risorse didattiche negli USA, attraverso la National Science Foundation. Basato su IEEE LOM è dedicato soprattutto a risorse di tipo scientifico-matematico

Buone Pratiche

Dall’analisi effettuata si possono dedurre alcune direzioni del progetto:

• basarsi su standard internazionali

I metadati - 35

• in particolare dublin core e IEEE LOM sono quelli più accreditati

• l’integrazione con SCORM consentirebbe,oltre alla catalogazione, anche la creazione di risorse didattiche immediatamente erogabili su piattaforme di formazione a distanza standard; tuttavia la maggiore complessità realizzativi suggerisce di demandare in secondo tempo questa parte.

• La libertà a tutti di inserire/consultare oggetti didattici potrebbe allargare il campo di attività e di uso della risorsa; potrebbe dapprima essere suggerito un uso interno per poi aprire il sistema

• L’uso di un meccanismo di voto, o di premio, a seconda della qualità dei materiali didattici inseriti/usati potrebbe essere utile per evidenziare e promuovere i lavori migliori

• La catalogazione di risorse web non direttamente prodotte/immagazzinate nel sistema per fornire risorse didattiche potrebbe essere utile per condividere le conoscenze a livello di ente

• Una apertura del sistema può essere promossa prevedendo una apertura verso altre repository (ARIADNE, o altre repository di altri enti/sistemi)

Introduzione ai metadati secondo SCORM

Lo scopo della standardizzazione dei metadati è quello di fornire una nomenclatura e classificazione comune per gli oggetti didattici, in modo da consentire la catalogazione e la ricerca in sistemi coerenti.

Storicamente, ADL si è riferita a quegli enti che hanno sviluppato sistemi di metadati per oggetti didattici; in questo caso IEEE, IMS e ARIADNE; questi gruppi hanno prodotto loro specifiche in un’ottica collaborativa, ottenendo risultati simili; SCORM 1.2 si riferisce direttamente al modello IMS, il quale a sua volta si basa su IEEE; per il binding, ancora ci si riferisce a IMS.

Da SCROM 1.3 il modello è diventato quello di IEEE, il Learning Object Metadata versione 1.0 (LOM 1.0)

In questa sezione vengono riportate le indicazione su come applicare il modello dei metadati previsto da IEEE LTSC LOM16 ai tre livelli previsti da SCORM, cioè assets, SCOs e Content Aggregation (=oggetti semplici, learning objects, corsi); una volta definiti i metadati, li si scrive in un file secondo le specifiche di binding previste da IMS Learning Resource Meta-data XML Binding Specification.

A livello di Content Aggregation lo scopo dei metadati è rendere accessibile la struttura del corso

16 http://ltsc.ieee.org/wg12/

I metadati - 36

così che sia possibile, a content repositories, accedere ai contenuti e fornire descrizioni del corso intero inteso come unità.

A livello di SCOs, i metadati possono servire a descrivere il contenuto del singolo oggetto e a renderlo disponibile per essere aggregato in diverse modalità; ne consente la ricerca ed il riuso.

A livello di Assets i metadati ne consentono la ricerca ed il riuso soprattutto infase di creazione di contenuti.

La modalità con cui viene suggerito questo processo è tale da facilitare e promuovere in ogni caso il riuso e la condivisione.

Dove vengono scritti i metadati?

I metadati trovano posto all'interno del file Imsmanifest.xml, il 'file indice' di tutti i contenuti SCORM.

E' bene chiarire che i metadati si possono trovare in più parti: almeno a livello di definizione di corso, LO e asset; ma anche in molte altre 'zone' del manifest file. in figura l'esplosione, a partire dal disco con i materiali, fino a raggiungere alcuni dei metadati.

Nella seconda figura vengono evidenziate, a titolo di esempio, alcune zone nelle quali sono presenti i metadati:

I metadati - 37

Analisi dei metadata

Il modello LOM prevede nove categorie principali nelle quali organizzare i metadati; ogni categoria, a sua volta, può essere divisa in sottocategorie.

In ogni caso è la parte terminale, la foglia dell'albero che va compilata.

Il modello prevede nove categorie di dati:

1. General informazioni generali per descrivere la risorsa come unità.

2. Lifecycle sulla storia e stato della risorsa, con informazioni su chi l’ha creata e corretta..

3. Meta-metadata raccoglie informazioni su come sono stati creati i metadati stessi

4. Technical per le caratteristiche tecniche della risorsa

5. Educational per le caratteristiche didattiche e pedagogiche.

6. Rights per la proprietà intellettuale e condizioni d’uso della risorsa.

7. Relation si riferisce alle relazioni tra la risorsa presa in considerazione e le altre a cui è in qualche modo collegata

I metadati - 38

4. Resources

1 Manifest

3. Organizations

2 Metadata

Imsmanifest29/05/2003 - v9

4.1 Resource

4.1.1 identifier

4.1.2 type

4.1.3 href

4.1.4 SCORM type

4.1.5 metadata

4.1.5.1 Schema

4.1.5.2 Schema version

4.1.5.3 Adlcp:location

4.1.5.4 {metadata}

4.1.6 file

4.1.6.1 Href

4.1.6.2 Metadata

4.1.6.2.1 Schema

4.1.6.2.2 Schema version

4.1.6.2.3 Adlcp:location

4.1.6.2.4 {metadata}

Enter Sub-topic

4.1.7 dependency 4.1.7.1 Identifier ref

1.1 Identifier

1.2 version

3.1 Default

3.2 Organization

3.2.1 identifier

3.2.2 Structure

3.2.3 title

3.2.4 item

3.2.4.1 identifier

3.2.4.2.identifier ref

3.2.4.3 is visible

3.2.4.4 parameters

3.2.4.5 title

3.2.4.6 item

3.2.4.7 metadata

3.2.4.7.1 Schema

3.2.4.7.2 Schema version

3.2.4.7.3 Adlcp:location

3.2.4.7.4 {metadata}

3.2.4.8 Prerequisites 3.2.4.8.1 type

3.2.4.9 Max time allowed

3.2.4.10 Time Limit Action

3.2.4.11 Data from LMS

3.2.4.12 Mastery Score

3.2.5 metadata

3.2.5.1 Schema

3.2.5.2 Schema version

3.2.5.3 Adlcp:location

3.2.5.4 {metadata}

2.1 Schema

2.2 Schema version

2.3 Adlcp:location

2.4 {metadata}

8. Annotation per le informazioni sull’uso didattico della risorsa e su chi le ha compilate.

9. Classification definisce in quale modo a risorsa è catalogabile secondo un sistema di classificazione

Lo Scorm Meta Data Information Model rappresenta in una tabella i criteri per la compilazione dei dati; la tabella è composta dalle colone:

1. numero

2. nome del metadato

3. spiegazione

4. molteplicità (quante istanze sono possibili)

5. tipo di dato (langstring, Data, Vocabulary)

Nella molteplicità a volte viene riportato il valore smallest permitted maximum, che significa che le applicazioni utilizzanti il metadato devono poter processare almeno quel numero di istanze. Una applicazione può imporre un massimo accettabile di istanze, ma tale massimo non può essere inferiore a quanto riportato.

Compilazione dei metadati: il dettaglio

Segue la tabella SCORM relativa ai meta-data; ne presento la traduzione semplificata della colonna centrale, ove possibile comunque riferirsi all’originale.

ATTENZIONE: quest tabella è relativa a scorm 1.2 in un momento in cui non sono ancora stati recepiti i cambiamenti in IEEE da 6.1 DRAFT a LOM 1.0; va utilizzata solo a scopo didattico per illustrare le voci utilizzate, nell’esempio di compilazione seguente vene utilizzato LOM 1.0. Va altresì ricordato che le differenze tra LOM Draft 6.1 e LOM 1.0 sono minime, riguardano principalmente la catalogazione.

I metadati - 39

Nel realizzare nuove compilazioni di metadata, è conveniente riferirsi a LOM 1.0.

The SCORM Meta-data Information Model

Nr Name Spiegazione Multiplicity

Data Type

1 General Viene descritta la risorsa didattica nella sua intierezza

1 and only 1

Container

2 Identifier Una etichetta univoca che identifica la risorsa

Essendo del tipo ‘reserved’ non deve essere usata; può essere utilizzata per scopi interni al sistema di authoring/catalogazione, è trasparente per quanto riguarda l’LMS

RESERVED

String

3 Title Il nome della risorsa; può essere creato ‘a caso’ oppure essere quello dato dal sistema di authoring/catalogazione.

1 and only 1

LangString Type (smallest permitted maximum: 1000 characters)

I metadati - 40

4 Catalog Entry Voce del catalogo scelto; importante per definire i criteri di ricerca della risorsa all’interno di un insieme.

Può essere funzionalmente sostituito dall’1.1

0 or More (smallest permitted maximum: 10)

Container

5 Catalog Nome del catalogo o sistema di catalogazione di riferimento.

0 or 1 String (smallest permitted maximum: 1000 characters)

6 Entry Valore della voce del catalogo. 0 or 1 LangStringType (smallest permitted maximum: 1000 characters)

7 Language La lingua primariamente utilizzata dalla risorsa per comunicare con l’utente, “none” (nessuna) è un valore accettabile

Gli standard per descrivere la lingua sono ISO 63923 & ISO 316624.


String (smallest permitted maximum: 100 characters)

8 Description Descrizione testuale della risorsa della quale si stanno compilando i metadati


LangStringType (smallest permitted maximum: 2000 characters)

9 Keyword Keywords per la descrizione della risorsa.

Questo elemento può essere usato in modo funzionale verso altri metadati.



10 Coverage ‘zona’, copertura, temporale, geografica o culturale applicabile alla risorsa.



I metadati - 41

11 Structure Organizzazione sottostante alla risorsa.

IEEE LOM Vocabulary:

4. Collection

5. Mixed

6. Linear

7. Hierarchical

8. Networked

9. Branched

10. Parceled

11. Atomic

0 or 1 VocabularyType (Restricted)

12 Aggregation Level

Granularità della risorsa.


1 – il più piccolo livello di aggregazione (assets).

2 – collezione di atomi, per esempio doc. html che contiene più immagini.

3 – libello di aggregazione superiore, esempio insieme di pagine html .

4 – il livello più elevato, per esempio un corso.


13 Life Cycle Storia, evoluzione e stato corrente del documento

0 or 1 Container element

14 Version versione 0 or 1 LangStringType (smallest permitted maximum: 50 characters)

I metadati - 42

15 Status Corrente stato della risorsa


• Draft

• Final

• Revised

• Unavailable


16 Contribute Chi ha contribuito alla risorsa durante la sua evoluzione

Nota: differente da 3.3:MetaMetaData.Contribute.


Container

17 Role Tipo di contributo

Nota: It is recommended that exactly one instance of Author exists.


• Author

• Publisher

• Unknown

• Initiator

• Terminator

• Validator

• Editor

• Graphical Designer

• Technical Implementer

• Content Provider

• Technical Validator

• Educational Validator

• Script Writer

• Instructional Designer

0 or 1 VocabularyType (Best Practice)

I metadati - 43

18 Entity Identità e informazioni sulla persona o gli enti che hanno contribuito alla risorsa, ordinato per importanza decrescente

se 2.3.1 Author, l’entità deve essere una persona.

Se 2.3.1 è Publisher, l’entità deve essere un ente

se 2.3.1 non è Author or Publisher, then this element shall be a contributor.

Questo elemento deve essere descritto come Vcard vCard25 element.



19 Date Data del contributo.

ISO 860126 standard per le date.

0 or 1 DateType

20 Meta-Metadata Informazioni sui metadati (non sulla risorsa descritta).

1 and only 1

Container

21 Identifier Identificatore dei metadati RESERVED

String

22 Catalog Entry Descrive questa istanza di metadati in funzione di un sistema di catalogazione; può rimpiazzare il 3.1


Container

23 Catalog Nome del catalogo 0 or 1 String (smallest permitted maximum: 1000 characters)

24 Entry Valore all’inerno del catalogo 0 or 1 LangStringType (smallest permitted maximum: 1000 characters)

25 Contribute Contributi alla realizzazione di questi metadati

Diverso da 2.3:Lifecycle.Contribute.


Container

I metadati - 44

26 Role Tipo di contributo

Note: It is recommended that exactly one instance of Creator exists.


• Creator

• Validator

0 or 1 VocabularyType (Best Practice)

27 Entity Informazione su persone o enti che hanno contribuito ai metadati

vCard25 element.



28 Date Data del contributo

ISO 860126 standard.

0 or 1 DateType

29 Metadata Scheme

Nome e versione delle specifiche utilizzate per definire i metadati; se ce n’è più di uno, i metadati sono conformi a tutte le specifiche.



30 Language Linguaggio con cui sono scritti i metadati, potenzialmente diverso da quello della risorsa verso l’utente. ‘None’ è un valore accettabile


31 Technical Risorse tecniche 1 and only 1

Container

32 Format Tipo ‘tecnico’ di dati.

Può essere usato per identificare il tipo di software utilizzato per creare la risorsa.

Deve essere descritto come MIME type o ‘non-digital’.



33 Size La grandezza del file in byte; possono essere usate solo cifre; è da prendere in considerazione la versione reale se ne esiste una compressa.


I metadati - 45

34 Location URL o URI della posizione fisica (se molte, primaria) della risorsa; è possibile una indicazione relativa alla posizione dei metadati o una assoluta

.



35 Type Tipo distringa utilizzata per descrivere location

• TEXT

• URI

0 or 1 String (Restricted values)

36 Requirement Requisiti tecnici per l’uso della risorsa; se più di uno, sono tutti richiesti (AND).


Container

37 Type Tecnologia richiesta.


• Operating System

• Browser

0 or 1 Vocabulary Type (Best Practice)

I metadati - 46

38 Name Nome della tecnologia richiesta


If 4.4.1:Technical.Requirements.Type = 'Operating System'

• PC-DOS

• MS-Windows

• MacOS

• Unix

• Multi-OS

• Other

• None

If 4.4.1:Technical.Requirements.Type = 'Browser'

• Any

• Netscape Communicator

• Microsoft Internet Explorer

• Opera

If 4.4.1:Technical.Requirements.Type = something other then Open Vocabulary


39 Minimum Version

La più piccola versione richiesta. 0 or 1 String (smallest permitted maximum: 30 characters)

40 Maximum Version

La più alta versione possibile. 0 or 1 String (smallest permitted maximum: 30 characters)

41 Installation Remarks

Note di installazione. 0 or 1 LangString Type (smallest permitted maximum: 1000 characters)

42 Other Platform Requirements

Info sulle informazioni hardware e software.

0 or 1 LangString Type (smallest permitted maximum: 1000 characters)

I metadati - 47

43 Duration Tempo necessario per il ‘play’ della risorsa alla velocità prevista, soprattutto per filmati suoni o animazioni.

DateType ISO 860126 standard

0 or 1 Date Type

44 Educational Caratteristiche didattiche e pedagogiche della risorsa; l’informazione è essenziale per chi vuole ’a quality learning experience’.

L’informazione è rivolta a docenti, managers, allievi.

0 or 1 Container

45 Interactivity Type

Il flusso di interazione tra la risorsa e l’utente.


• Active

• Expositive

• Mixed

• Undefined

Nel tipo espositivo, il fluso primario è dalla risorsa all’utente; video, materiale grafico, ipertesti, learning-by-reading.

Nel tipo attivo, l’informazione fluisce dall’utente alla risorsa: simulazioni, questionari, esercizi, learning-by-doing.

Nota: navigare su ipertesti non è cosiderata attività; gli ipertesti ricadono nella categoria ‘espositiva’

0 or 1 Vocabulary Type (Restricted)

I metadati - 48

46 Learning Resource Type

Tipo di risorsa, in ordine di importanza decrescente.


• Exercise

• Simulation

• Questionnaire

• Diagram

• Figure

• Graph

• Index

• Slide

• Table

• Narrative Text

• Exam

• Experiment

• Problem Statement

• Self Assesment


Vocabulary Type (Best Practice)

47 Interactivity Level

Grado di interattività tra utente e risorsa.


• very low

• low

• medium

• high

• very high


I metadati - 49

48 Semantic Density

Misura soggettiva dell’utilità della risorsa comparata alla sua grandezza o durata.


• very low

• low

• medium

• high

• very high


49 Intended End User Role

Utente; per grado decrescente di importanza


• Teacher

• Author

• Learner

• Manager


Vocabulary Type (Restricted)

I metadati - 50

50 Context L’ambiente di utilizzazione della risorsa


• Primary Education

• Secondary Education

• Higher Education

• University First Cycle

• University Second Cycle

• University Postgrade

• Technical School First Cycle

• Technical School Second Cycle

• Professional Formation

• Continuous Formation

• Vocational Training


Vocabulary Type (Best Practice)

51 Typical Age Range

Tipico range di utilizzazione (utenti).

Quando possibile, indicare l’età minima o massima;



52 Difficulty Indica quanto è difficile l’uso della risorsa per il tipico range di età.


• very easy

• easy

• medium

• difficult

• very difficult


I metadati - 51

53 Typical Learning Time

Tempo approssimativo per lutilizzo della risorsa.

DateType ISO 860126 standard con commento

0 or 1 Date Type

54 Description Commenti su come la risorsa deve essere usata.

Es.: manuale del tutor, indicazioni per il docente.


55 Language Linguaggio utilizzato dall’utente tipico della risorsa. “None” is an acceptable value.

ISO 63923 & ISO 316624 standards.



56 Rights Proprietà intellettuale e condizioni d’uso della risorsa.

1 and only 1

Container

57 Cost Indica se l’uso della risorsa comporta un pagamento.


• yes

• no

1 and only 1


58 Copyright And Other Restrictions

Indica se c’è un copyright sull’uso .


• yes

• no

1 and only 1


59 Description Commenti sui termini d’uso della risorsa.


60 Relation Relazioni tra la risorsa descritta ed altre, se ne esistono.

Sono possibili più istanze di questa categoria.


Container

I metadati - 52

61 Kind Natura della relazione con la risorsa descritta in 7.2.

IEEE LOM Vocabulary (from Dublin Core28):

• IsPartOf

• HasPart

• IsVersionOf

• HasVersion

• IsFormatOf

• HasFormat

• References

• IsReferencedBy

• IsBasedOn

• IsBasisFor

• Requires

• IsRequiredBy


62 Resource Risorsa di riferimento per la relazione.

0 or 1 Container

63 Identifier Identificatore di catalogo. RESERVED

String

64 Description Descrizione della risorsa-target. 0 or 1 LangString Type (smallest permitted maximum: 1000 characters)

65 Catalog Entry Voce del catalogo 0 or More (smallest permitted maximum: 10)

Container

66 Catalog Nome del catalogo 0 or 1 String (smallest permitted maximum: 1000 characters)

67 Entry Voce nel catalogo 0 or 1 LangString Type (smallest permitted maximum: 1000 characters)

I metadati - 53

68 Annotation Note sull’uso didattico della risorsa, su chi le ha descritte e quando.


Container

69 Person Chi scrive la nota.

vCard25


70 Date Data di creazione della nota. 0 or 1 Date Type

71 Description Annotazione nel dettaglio 0 or 1 LangString Type (smallest permitted maximum: 1000 characters)

72 Classification Questa categoria descrive se la risorsa è iscritta a qualche particolare sistema di classificazione

To define multiple classifications, there may be multiple instances of this category.


Container

73 Purpose Lo scopo della classificazione.


• Discipline

• Idea

• Prerequisite

• Educational Objective

• Accessibility Restrictions

• Educational Level

• Skill Level

• Security Level


74 Taxon Path Voce tassonomica di definizione; i seguenti saranno rifiniture di questa.

Dipende dagli schemi di classificazione utilizzati.


Container

I metadati - 54

75 Source Nome del sistema di classificazione.

Può essere utilizzato qualsiasi schema di classificazione ‘ufficale’, oppure uno schema di classificazione definito dall’utente.


76 Taxon Individua un particolare termine all’interno del sistema di classificazione to designate a particular taxon.

Può essere indicata una gerarchia:

Physics/ Acoustics/ Instruments/ Stethoscope;

Medicine/ Diagnostics/ Instruments/ Stethoscope


Container

77 Id Identificatore del livello tassonomico (es.id345)


78 Entry Etichetta della voce tassonomica. (es., Social Sciences)


79 Description Descrizione dello scopo della classificazione (9.1)


80 Keyword Keywords per il sistema di classificazione



Esempio di compilazione

Una volta definiti i metadati in termini generali, per capirne il funzionamento è bene applicarli a

I metadati - 55

qualche oggetto conosciuto.

Nella successiva tabella, questa volta basata su LOM 1.0, vengono riportati i metadati per tre oggetti didattici:

• una presentazione di slide che spiegano il modello LOM; sia la presentazione che i metadati sono compilati da Erik Duval17 della Katholieke Universiteit Leuven.

• Si è detto che un oggetto didattico può aver diverse forme; pensando a quale sia stato per me un oggetto didattico importante, ho utilizzato una foto dei miei figli e tentato di

descriverlo come risorsa didattica

• Una presentazione con video e slides sugli standard didattici18.

• Una colonna libera, che permette la compilazione dei campi come esercizio.

Nr Nome

valore

molteplicità tipo

emanuele e gabriele video

esercizio

1 General -

1.1

Identifier

-

max 10

1.1.1

Catalog

"ARIADNE" 1

characterstring losero maestra

1.1.2

Entry "CS_LKP_v_3.0_nr_999" 1

characterstring lr123 udxxx

1.1.1

Catalog

"URL" 1

characterstring url url

17 http://www.cs.kuleuven.ac.be/~erikd/18 http://www.linkomm.net/0804t/

I metadati - 56

1.1.2

Entry "http://www.cs.kuleuven.ac.be/~erikd/CHRONOS/2002/06/25/slides.ppt" 1

characterstring

http://www.losero.net/reps/lr123 http://www.maestra.net/ud/xxx

1.2

Title ("en","LOM Tutorial")

1

langstring

("it","gabriele & emanuele")

("it","introduzione agli standard per l'e-learning")

1.3

Language

"en-GB"

max 10

characterstring it it

1.4

Description

("en","These slides give a general overview of the LOM standard.")

max 10

langstring

("it","la risorsa didattica principale")

("it","breve introduzione agli standard sull'e-learning con video e slides")

1.5

Keyword

("en","metadata")

max 10

langstring

("it","emanuele")

("it","scorm")

1.5

Keyword

("en","learning objects")

langstring

("it","gabriele")

1.5

Keyword

("fr","metadonnees")

langstring ("it","figli")

1.6

Coverage ("en","21st

century")

langstring

("it","contemporaneo")

("it","contemporaneo")

1.7

Structure

("en","linear") 1

vocabulary collection atomic

1.8

Aggregation Level

("LOMv1.0","2")

vocabulary

("LOMv1.0","2")

("LOMv1.0","1")

2 Life Cycle -

2.1

Version("en","1.0")

langstring

("it","preadolescenza") ("it","2.2")

2.2

Status ("LOMv1.0","final")

vocabulary

("LOMv1.0","revised") ("LOMv1.0","draft")

2. Contrib -

I metadati - 57

3 ute

2.3.1

Role("LOMv1.0","author")

vocabulary

("LOMv1.0","author") ("LOMv1.0","author")

2.3.2

EntityvCard: Erik Duval vcard

vCard: Laura Martinotti vCard:Italo Losero

2.3.3

Date"2002-06-24" date

"1991-01-17" "2003-04-08"

2.3.1

Role ("LOMv1.0","subject matter expert")

vocabulary

("LOMv1.0","author") ("LOMv1.0","technical validator")

2.3.2

Entity vCard: Stefaan Ternier vcard

vCard: Laura Martinotti vCard:Nicodemo Ricco

2.3.3

Date"2002-06-24" date

"1992-08-25" "2003-04-08"

2.3.1

Role ("LOMv1.0","graphical designer")

vocabulary

("LOMv1.0","author") ("LOMv1.0","publisher")

2.3.2

EntityvCard: Eddy Forte vcard

vCard:Italo Losero vCard:Antonino Gentile

2.3.3

Date"2002-06-15" date "1991" "2003-04-12"

3 Meta-Metadata -

3.1

Identifier -

3.1.1

Catalog

"ARIADNE"

characterstring

"losero fotorepository" "maestra"

3.1.2

Entry "CS_LKP_v_3.0_nr_999"

characterstring

"fotoalbum/fuerte/" "video_ud123"

3.1.1

Catalog

"URL"

characterstring "URL" "URL"

3.1.

Entry "http://www.cs.kuleuv

characterstrin

http://www.losero.n

http://repository.maestra.net

I metadati - 58

2 en.ac.be/~erikd/CHRONOS/2002/06/25/slides.xml" g

et/fotoschema

3.2

Contribute -

3.2.1

Role("LOMv1.0","creator")

vocabulary

("LOMv1.0","creator") ("LOMv1.0","creator")

3.2.2

EntityvCard: Erik Duval vcard

vCard:Italo Losero vCard:Italo Losero

3.2.3

Date"2002-06-24"

dateTime

"2003-04-09" "2003-04-09"

3.3

Metadata Schema "LOMv1.0"

characterstring "LOMv1.0" "LOMv1.0"

3.4

Language

"en"

characterstring "it" "it"

4 Technical -

4.1

Format "application/x-powerpoint"

vocabulary non digital "application/x-powerpoint"

4.2

Size"2150000"

4.3

Location

"http://www.cs.kuleuven.ac.be/~erikd/CHRONOS/2002/06/25/slides.ppt"

characterstring

"la cassa - Torino"

"http://www.cs.kuleuven.ac.be/~erikd/CHRONOS/2002/06/25/slides.ppt"

4.4

Requirement - "pazienza" "Iexplorer"

4.4.1

OrComposite

-

4.4.1.1

Type("LOMv1.0","operating system")

vocabulary ("LOMv1.0","operating system")

I metadati - 59

4.4.1.2

Name

("LOMv1.0","multi-os") ("LOMv1.0","multi-os")

4.4.1.3

Minimum Version

- characterstring

"4.2"

4.4.1.4

Maximum Version

- characterstring

"6.0"

4.5

Installation Remarks

("en","Open with Microsoft Powerpoint or a compatible viewer.")

langstring

("it","prevedere adeguati spazi aerati")

("it","preferibilmente da vedere con linee con buona velocità.")

4.6

Other Platform Requirements -

langstring

("it","real video e scheda audio")

4.7

Duration

-

characterstring PT180S

5 Educational -

5.1

Interactivity Type

("LOMv1.0","expositive")

vocabulary

("LOMv1.0","active") ("LOMv1.0","expositive")

5.2

Learning Resource Type

("LOMv1.0","slide")

vocabulary ("LOMv1.0"

,"self assesment") ("LOMv1.0","lecture")

5.3

Interactivity Level

("LOMv1.0","low")

vocabulary

("LOMv1.0","very high") ("LOMv1.0","low")

5.4

Semantic Density

("LOMv1.0","low")

vocabulary

("LOMv1.0","very high") ("LOMv1.0","high")

5.5

Intended End User Role

("LOMv1.0","learner")

vocabulary



I metadati - 60

5.6

Context

("LOMv1.0","other")

vocabulary

("LOMv1.0","other") ("LOMv1.0","traning")

5.7

Typical Age Range ("18-")

langstring ("18-") ("it","docenti con esperienza")

5.8

Difficulty ("LOMv1.0"

,"easy") vocabulary

("LOMv1.0","very difficult") ("LOMv1.0","easy")

5.9

Typical Learning Time "PT3H00M"

characterstring "PT100Y" "PT3H00M"

5.10

Description

("en","Best used as supportive material for an interactive workshop.")

("it","passare il maggior tempo possibile insieme")

("it","da seguire con le slide e gli appunti a fianco")

5.11

Language

"en"

characterstring "it" it

6 Rights -

6.1

Cost ("LOMv1.0","no")

vocabulary

("LOMv1.0","yes") ("LOMv1.0","no")

6.2

Copyright and Other Restrictions

("LOMv1.0","no")

vocabulary

("LOMv1.0","no") ("LOMv1.0","yes")

6.3

Description

("LOMv1.0","If this material is re-used then a notification to [email protected] would be appreciated. If this material is redistributed, then providing the

langstring

("it","se riutilizzato notificare a [email protected], se distribuito non aggiungere altri costi")

I metadati - 61

material at no cost with no copyright or other restrictions is strongly encouraged.")

7 Relation -

7.1

Kind ("LOMv1.0","is based on")

vocabulary … ("LOMv1.0","is referenced by")

7.2

Resource -

7.2.1

Identifier

-

7.2.1.1

Catalog"IEEE p1484.12.1"

characterstring url

7.2.1.2

Entry

"D6.4"

characterstring

"http://www.losero.net/materiali/standardoc.html") (?)

7.2.2

Description

("en","The last draft version of the LOM standard.")

langstring

("it","documento sulla standardizzazione dei materiali didattici")

8 Annotation -

8.1

Entity- vcard

vCard:Italo Losero vCard:Italo Losero

8.2

Date-

dateTime

"2003-15-04" "2003-15-04"

8.3

Description

- langstring

("it","usare con cautela vista l'elevata permalosità")

("it","da usare solo a posteriori, dopo la presenza")

9 Classification -

I metadati - 62

9.1

Purpose

("LOMv1.0","discipline")

vocabulary

("LOMv1.0","skill level") ("LOMv1.0","competency")

9.2

Taxon Path -

9.2.1

Source

("en","ARIADNE")

langstring

("it","repertorio didattico ABC")

("it","sistema di classificazione maestra")

9.2.2

Taxon

-

9.2.2.1

Id

"2"

characterstring "121" "12"

9.2.2.2

Entry ("en","Exact Sciences and Engineering")

langstring

("it","cure parentali") ("it","standard materiali fad")

9.2.2.1

Id

"3"

characterstring

9.2.2.2

Entry("en","Computer Science")

langstring

9.2.2.1

Id

"6"

characterstring

9.2.2.2

Entry

("en","metadata")

langstring

9.3

Description

("en","These slides give a general overview of the LOM standard.")

langstring

("it","nella definizione delle abilità per l'uso riguarda i genitori")

("it","E' una lezione visibile come video")

9.4

Keyword

("en","metadata")

langstring ("it","figli") ("it","standard materiali fad")

9. Keywor ("en","learn langstri ("it","cen")

I metadati - 63

4 d ing object") ng

9.4

Keyword

langstring ("it","ieee")

9.4

Keyword

langstring ("it","scorm")

9 Classification -

9.1

Purpose

("LOMv1.0","educational level")

9.2

Taxon Path -

9.2.1

Source("en","ARIADNE")

9.2.2

Taxon

-

9.2.2.1

Id

"2"

9.2.2.2

Entry

("en","Post-graduate")

9.3

Description

("en","These slides are so complex that they should only be used by real smart people.")

Obbligatorietà dei campi

A seconda del livello di compilazione SCORM definisce quali campi sono obbligatori (Mandatory), opzionali (Optional), o dove non devono essere usati (Reserved).

I metadati - 64

Name Content Aggregation

SCO Asset

1.0 general M M M

1.1 identifier R R R

1.2 title M M M

1.3 catalogentry M M O

1.3.1 catalog M M O

1.3.2 entry M M O

1.4 language O O O

1.5 description M M M

1.6 keyword M M O

1.7 coverage O O O

1.8 structure O O O

1.9 aggregationlevel O O O

2.0 lifecycle M M O

2.1 version M M O

2.2 status M M O

2.3 contribute O O O

2.3.1 role O O O

2.3.2 centity O O O

2.3.3 date O O O

3.0 metametadata M M M

3.1 identifier R R R

3.2 catalogentry O O O

3.2.1 catalog O O O

3.2.2 entry O O O

3.3 contribute O O O

3.3.1 role O O O

3.3.2 centity O O O

3.3.3 date O O O

3.4 metadatascheme M M M

3.5 language O O O

4.0 technical M M M

4.1 format M M M

I metadati - 65

4.2 size O O O

4.3 location M M M

4.4 requirement O O O

4.4.1 type O O O

4.4.2 name O O O

4.4.3 minimumversion O O O

4.4.4 maximumversion O O O

4.5 installationremarks O O O

4.6 otherplatformrequirements

O O O

4.7 duration O O O

5.0 educational O O O

5.1 interactivitytype O O O

5.2 learningresourcetype O O O

5.3 interactivitylevel O O O

5.4 semanticdensity O O O

5.5 intendedenduserrole O O O

5.6 context O O O

5.7 typicalagerange O O O

5.8 difficulty O O O

5.9 typicallearningtime O O O

5.10 description O O O

5.11 language O O O

6.0 rights M M M

6.1 cost M M M

6.2 copyrightsandotherrestrictions

M M M


7.0 relation O O O

7.1 kind O O O

7.2 resource O O O

7.2.1 identifier R R R

7.2.2 description O O O

7.2.3 catalogentry O O O

I metadati - 66

7.2.3.1 catalog O O O

7.2.3.2 entry O O O

8.0 annotation O O O

8.1 person O O O

8.2 date O O O


9.0 classification M M O

9.1 purpose M M O

9.2 taxonpath O O O

9.2.1 source O O O

9.2.2 taxon O O O

9.2.2.1 id O O O

9.2.2.2 entry O O O

9.3 description M M O

9.4 keyword M M O

XML binding

Nel documento ‘Conformance Requirements’ di SCORM 1.219, vengono riportati, a livello minimo di conformità sui metadata (MD-XML1) i seguenti requisiti:

• Is a well formed XML Document, and

• Is valid against the IMS Learning Resource Metadata Version 1.2.1 XML Schema Definition (XSD), and

• Contains elements that conform to their corresponding specified data types, and

• Contains all mandatory document elements for the corresponding meta-data application profile (Content Aggregation, SCO or Asset) as described in Section 2.2 of the Content Aggregation Model, and

• Elements defined as having restricted vocabularies adhere to all defined vocabularies as defined in Section 2.2 of the Content Aggregation Model1.

Come si vede, solo le ultime due condizioni si riferiscono a quanto finora riportato; le prime tre

19 ADLnet, Sharable Content Object Reference Model -Version 1.2 - Conformance Requirements

I metadati - 67

hanno una connotazione tecnica.

Vengono dati per conosciuti nella seguente spiegazione i concetti di base relativi all’XML; dove si vogli approfondire l’argomento si riporta a http://www.w3.org/XML/ o alle tante risorse sul web che trattano dell’argomento.

Il primo punto riguarda la corretta sintassi del file XML.

Il secondo punto è quello che valida la correttezza dei dati che vengono inseriti, che devono aderire a quanto specificato dallo schema di riferimento:

Il terzo punto riporta agli specifici data types che devono essere utilizzati; negli esempi di compilazione, se correttamente eseguiti, se ne è debitamente tenuto conto.

Nel seguito non viene spiegata nel dettaglio l’implementazione dell’intero file XML, in quanto è condizione piuttosto rara quella di creare ‘a mano’, con un editor di testo o con un editor xml l’intero file.

Normalmente vengono usati tools che consentono di passare direttamente dalla compilazione dei campi, come fatto negli esempi precedenti, alla scrittura del file XML, secondo le regole sopra citate.

Per questo, segue la spiegazione su come viene implementato un solo campo.

Esempio: l’implementazione del campo <title>

Nel documento precedentemente citato, al punto 2.1.3.1 ‘Asset Meta-data Conformance Requirements’ per il campo 1.1.1 <title> viene riportato:

1 L’elemento <title> deve aderire ai punti seguenti:

• <title> deve apparire una ed una sola volta.

• <title> deve essere rappresentato dal tipo LangStringType.

• <title> deve avere un minimo numero di caratteri gestibile di 1000 – non è un requisito, è un ‘warning’.

Non ci sono problemi per il primo punto, l’indicazione è chiara: non può avere molteplicità.

Per quanto riguarda il secondo, si deve definire nel dettaglio il tipo LangString.

Nel paragrafo ‘2.2.3.2.1.LangString Element’ di ‘The SCORM Content Aggregation Model’ viene definita l’implementazione del tipo langstring, che:

• definisce una frase in un linguaggio umano

I metadati - 68

• è sempre unica all’interno del suo parent xml

• ha l’attributo di nome lang rappresentante il linguaggio umano di scrittura

viene riportato l’esempio pratico di implementazione di una keyword, di tipo langString, nel campo classification:

1 <classification>2 <keyword>3 <langstring xml:lang=”en”>simulation</langstring>4 </keyword>

5 </classification>

Nel nostro caso, se il titolo della risorsa è ‘la storia dei boschi del piemonte’, potrà essere rappresentato con

1 <langstring xml:lang=”it”> la storia dei boschi del piemonte</langstring>

Applicando lo stesso processo a tutti i dati necessari si giunge alla compilazione del file xml (binding) contenente tutti i dati.

Tools per l’implementazione dei metadati.

Abbiamo visto che spesso è meglio rivolgersi a specifici software che consentono il binding automatico, creando direttamente il file XML a partire dalla compilazione dei metadati. Quello che segue è un elenco di software presenti in rete per raggiungere lo scopo.

• Macromedia20 propone una soluzione per la produzione di interi corsi utilizzando i software di produzione di siti (Dreamweaver, Flash). Durante la produzione del corso, viene automaticamente creato il file (o i files) IMSmanifest.xml necessari.

• Microsoft21 propone un pacchetto per la creazione di corsi: anche in queso caso è implementato un pacchetto per la produzione di file xml necessari

• ALOHA: E’ uno strumento per la creazione dei metadati e la comunicazione tra repositories http://aloha.netera.ca/

20 http://www.macromedia.com/resources/elearning/21 http://www.microsoft.com/elearn/

I metadati - 69

• DC-dot: Costruito per iil dublin core, consente comunque anche la mappatura come IMS. http://www.ukoln.ac.uk/metadata/dcdot/

• IMSE/VIMSE: Scritto in java, per scrivere in XML imetadati IMS http://imsevimse.sourceforge.net.

• LOM Editor: Sviluppato nel contesto del progetto Multibook (Personal Multimedia book) specificatamente per LOM. http://www.multibook.de/lom/

• MetaBrowser (Australia): E’ un sistema di catalogazione aperto a molti tipi di metadati http://metabrowser.spirit.net.au/

• Reggie Metadata Editor: "Permette la specifica creaione di metadati in modo semplice http://www.metadata.net/dstc/

• Splash: Editor di metadati dedicato ai sistemi peer to peer http://www.edusplash.net

• Sun Developer's Toolkit: Toolkit per la creazione di metadati IMS compatibili.. http://www.imsproject.org/tools/sun.html

Oltre a questi strumenti ‘dedicati’ a LOM o IMS, è possibile utilizzare un ‘qualsiasi’ editor XML; è importante che l’editor sia in grado di utilizzare gli schemi XSD proposti da IMS in modo da valicare il codice creato e da consentire una creazione guidata dei tag.

Nelle immagini che seguono vengono riportate alcune schermate di XMLspy utilizzato come xml editor.

I metadati - 70

In questa schermata si vede l’editor in cui è caricato lo schema proposto da IMS; si vede aperto l’elemento lom, in cui è presente il child di nome general, in cui è aperto keywords, nella finestra in alto a destra si vede che il dato accettato è di tipo langstring: ci troviamo nella posizione in cui si possono inserire le keyword di descrizione della risorsa in generale.

Esplodendo la voce keyword prima riportata in azzurro si ottiene la schermata:

che in questo caso contiene la keyword ‘mouse’ espressa in tre lingue.

Il codice XML creato sarà:

<keyword><langstring

xml:lang="en">mouse</langstring><langstring

xml:lang="es">raton</langstring><langstring

xml:lang="fr">souris</langstring></keyword>

visibile nell’applicazione in questo modo:

I metadati - 71

Procedendo così possono compilarsi tutti i dati; la validazione del codice rispetto allo schema caricato e la compilazione dei campi obbligatori consentiranno di dichiarare valido il codice secondo l’impostazione IMS.

Repositories basate su metadati

LearnAlberta Portal: http://www.learnalberta.ca/

BELLE/CAREO: http://careo.netera.ca

COLIS: http://www.edna.edu.au/go/browse/0

European Knowledge Pool System: http://rubens.cs.kuleuven.ac.be:8989/lkptm5/intro.jsp (example node)

Heal: http://www.healcentral.org/index.htm

iLumina: http://turing.csc.uncwil.edu/ilumina/homePage.xml

Lydia: http://www.lydialearn.com/

MERLOT: http://www.merlot.org

SeSDL: http://www.sesdl.scotcit.ac.uk

SMETE: http://www.smete.org/

I metadati - 72

Universal Brokerage Platform: http://www.educanext.org/UNIVERSAL

I metadati - 73

La realizzazione di learning objects strutturati secondo le specifiche SCORM e i modelli d’apprendimento: un’esperienza concreta

In questo capitolo

Qui viene presentata una esperienza concreta che riguarda la realizzazione di 12 corsi strutturati secondo SCORM 1.2, in cui chi scrive ha coordinato i lavori.

Hanno contribuito alla stesura del testo e all'esperienza in oggetto Sara Spata, Elena Carniel, Piergiorgio Borgogn, Viviana Addari.

1. Introduzione

Esiste un paradosso nel giudizio che si dà sulla formazione in rete.

Da una parte la si giudica come moda del momento: così com’è successo per l’e-commerce nei passati anni, la FAD (come viene comunemente chiamata) sta vivendo un momento di notorietà. In molti contesti viene citata come soluzione ottimale, punta tecnologica, soluzione ai problemi dell’apprendimento; la pluralità di contesti a cui si applicano queste definizioni è la più ampia, andando dalle scuole dell’obbligo a quelle professionalizzanti, all’università, ai master specialistici.

Nonostante la molteplicità degli ambiti di applicazione la FAD viene citata sempre allo stesso modo, senza differenziarne le modalità applicative, realizzative e tecnologiche. Formazione a distanza risulta la parola magica che aggiunge potenzialità ad un progetto, innovazione ad un percorso formativo, dà un futuro luminoso a progetti stantii; a tale hybris formativa si contrappone spesso il mancato o parziale successo delle iniziative di formazione, il ridimensionamento dei risultati e delle aspettative, ponendo la FAD nell’ambito delle operazioni realizzabili in futuro, una volta che ne venga comprovata la funzionalità e chiariti i metodi di funzionamento. (Cornoldi C., Metacognizione e Apprendimento)

Dall’altra parte ci sono esperienze realizzate che dimostrano il successo di alcune iniziative; soprattutto in quei paesi dove le distanze non sono solo di tempo ma anche e soprattutto di luogo (Canada, Australia, Stati Uniti) sono cresciuti sistemi formativi che utilizzano largamente la FAD con successo, dove per successo si intende l’effettivo apprendimento da parte dei discenti. Tali iniziative sono il risultato di prove, esperimenti, tentativi di applicazione delle nuove tecnologie alla didattica dove l’elemento tecnologico viene utilizzato come trasportatore dell’informazione, riportando l’informatica al suo ruolo primo (informazione automatica). Il successo di queste iniziative è basato sui fallimenti precedenti: per evitare gli errori già commessi i sistemi si sono

La realizzazione di learning objects strutturati secondo le specifiche SCORM e i modelli d’apprendimento: un’esperienza concreta - 74

evoluti raggiungendo un grado di maturità che ne ha consentito l’uso proficuo.

Il paradosso tra i due modi di intendere la FAD è risolvibile alla luce delle esperienze passate: rinunciando a ricalcare i passi dove altri paesi e sistemi formativi hanno fallito, e traendo insegnamento dalle altrui esperienze, possono realizzarsi soluzioni a base locale che coniughino l’esperienza altrui con i contenuti e metodi sviluppati localmente, evitando sprechi di risorse ed investimenti dal basso ritorno. (Becciu M., Colasanti A.R., I.a demotivazione scolastica come, sintomo di un sè scoraggiato)

Così la ‘moda’ della FAD diventa una effettiva opportunità di sviluppo dei sistemi formativi, permettendo la crescita di quelle istituzioni che già si occupano di formazione integrando le conoscenze acquisite con le nuove modalità formative.

Il presente contributo ha come scopo principale la presentazione di un progetto realizzato dall’ente CNOS-FAP Piemonte, proprietario della Piattaforma Maestra, volto alla realizzazione dei materiali didattici standard SCORM di 10 corsi da erogare in modalità “blended”. Principali attori del percorso realizzato sono stati 10 formatori senior responsabili della redazione dei contenuti, neofiti per quanto concerne la formazione a distanza, e il gruppo tecnico di gestione della Piattaforma Maestra composto da un responsabile di progetto, un programmatore per lo sviluppo delle funzionalità SCORM, un grafico per l’elaborazione dell’interfaccia del learning object, un sviluppatore di pagine HTML, un esperto in processi formativi per l’opera di revisione e adeguamento dei contenuti.

2. Impostazioni iniziali

Per quanto riguarda gli standard, le difficoltà sono dovute alla vastità della materia: tanto tecnologicamente quanto metodologicamente si aprono scenari nei quali è difficile orientarsi; guru delle diverse università e vendors delle più disparate ditte si contendono la verità su come impostare e fare funzionare un sistema didattico, al punto che è difficile trovare un punto di riferimento che sia base per un giudizio chiaro.

Ha senso, a questo punto, parlare di standard perché sono il risultato dell’esperienza maturata da chi già da anni sperimenta queste tecniche e metodologie. Se la formazione a distanza fosse un processo didattico nel quale le conoscenze pregresse dell’istituzione formativa, unite con le nuove tecnologie, fossero necessarie e sufficienti per aver successo, probabilmente non sarebbe nato alcuno standard; ogni soggetto erogatore di formazione avrebbe creato e custodito gelosamente il proprio, come oggi ci si comporta con i modelli didattici ed educativi.

La realtà ha dimostrato il contrario. Soprattutto dal punto di vista economico, la realizzazione di materiali didattici e piattaforme di FAD secondo sistemi chiusi e proprietari ha portato ad investimenti eccessivi, non giustificabili con l’apprendimento ottenuto. Dal punto di vista metodologico, i sistemi proprietari obbligano ad un basso livello di riutilizzabilità di quanto creato.

Risulta quindi, almeno in prima battuta, relativamente facile decisione l’aderire ad uno standard internazionale piuttosto che sviluppare un proprio modello; vedremo tuttavia che questa operazione non è di semplice realizzazione, richiede investimenti soprattutto in termini di formazione.

L’adesione agli standard comporta indubbi vantaggi dal punto di vista della interoperabilità, consente di ‘dare un futuro certo’ a quanto viene creato/sviluppato; esiste un vantaggio non immediatamente percepibile sul quale vorremmo soffermarci, che riguarda il cambiamento indotto


nell’istituzione formativa.

Non è facile capire e padroneggiare le conoscenze sulla standardizzazione nella FAD: devono essere fatti parecchi distinguo, ci vuole una certa conoscenza, anche tecnica, dei sistemi di formazione; le norme risultano ad una prima analisi complesse, vaste, dalla non chiara applicazione.

Dobbiamo tuttavia ricordare che tali norme sono risultate da quel passaggio prima citato da sistemi FAD non ben funzionanti verso sistemi dal risultato più certo; il lavoro fatto nel definire, separare, catalogare il processo di formazione a distanza per poi applicare ai singoli passaggi le norme è di per sé una conoscenza profonda del sistema; questo significa che nello studiare gli standard ed il loro ambito di occupazione si ottiene una conoscenza di sistema utile anche quando non venga applicata in primis la fad nell’istituzione formativa.

Ciò può essere utile ben oltre il mondo della fad; allo sguardo attento non possono sfuggire le analogie tra le modalità di progetto / presentazione dei percorsi didattici in diverse regioni e sistemi formativi d’Italia con le modalità di ‘assemblaggio’ dei corsi secondo standard: è facile previsione che gli uni evolvano verso gli altri, dando una specie di ‘vantaggio competitivo’ a chi conosce regole ed impostazioni degli standard.

Conoscere l’evoluzione del processo di standardizzazione, gli ambiti e le modalità di applicazione costituisce una base utile per conoscere quanto è stato fatto finora, per evitare gli errori altrui, seguirne i consigli migliori ed evitare di farsi ingannare dai paradossi sulla formazione in rete.

Procedura di implementazione standard scorm

Come precedentemente affermato, la forte spinta verso l’e-learning di oggi e la comunicazione diffusa che Internet consente hanno promosso la ricerca di soluzioni comuni tra produttori di materiali per riuscire ad indirizzare in modo maggiormente produttivo ed utile le risorse impiegate nella produzione di sistemi di formazione tecnologicamente avanzati con particolare attenzione a:

• accessibilità in quanto il ‘linguaggio comune’ attraverso il medium internet consente l’indipendenza della posizione geografica dell’utente, della piattaforma di erogazione e dei materiali; consente agli autori di contenuto e di piattaforme di creare i propri materiali in una ‘zona franca’, ovvero su server internet raggiungibili da ovunque.

• interoperabilità, consentendo l’uso di materiali sviluppati per una piattaforma da parte di un’altra piattaforma in ambiti diversi, e viceversa l’uso della stessa piattaforma per distribuire materiali creati per altri progetti.

• durabilità, consentendo il riutilizzo di contenuti senza sottoporli ad una riscrittura ma semplicemente ad una revisione; la granularità dei learning object rende possibile la modifica solo di alcune parti.

Nella definizione degli standard si parte dal dublin core, modello di riferimento adottato per gli standard nei cataloghi bibliografici; in questo standard viene introdotto il concetto di Metadata, ovvero dati di dati.

Questi metadata costituiscono un descrittore della risorsa ma non ne costituiscono il contenuto.

L’attività di standardizzazione della formazione on-line si suddivide in:

• standardizzazione dei contenuti (content aggregation model)

• struttura del contenuto (Content Model)


• definizione dei metadata

• modello di implementazione dei metadata

• modalità di erogazione (Run-time environment)

• definizione delle modalità di colloquio tra materiali didattici e la piattaforma di erogazione (LMS API)

• definizione del modello di dati che devono essere comunicati tra piattaforma e contenuti (LMS data model)

SCORM (Sharable Content Object Reference Model) fornisce una cornice applicativa (context framework) che inquadra tutti le tappe sopraccitate facendo riferimento ai lavori svolti dagli enti che sviluppano i singoli sottopunti.

Per quanto riguarda i contenuti, i passi da compiere sono: in prima istanza definire la granularità dei learning object, ovvero a quale livello spezzare i contenuti per creare i LO, in seguito associare ad ognuno il set di metadata necessari a descriverlo ed in ultima istanza definire come questi elementi “atomici” vengono aggregati.

Nella definizione dei metadata dei LO si devono seguire due processi: il primo consiste nel definire il set di dati da utilizzare ed il secondo nell’implementare tecnicamente i descrittori.

Il dizionario dei dati utilizzato da SCORM è dedotto dalle specifiche definite da IMS. In questo dizionario sono descritti i campi da inserire, e per alcuni di questi viene definito un set di valori tra i quali scegliere.

Una volta definiti i valori da assegnare ai diversi campi, si deve racchiudere struttura e valori all’interno di un file unico; di questo si occupa il modello di implementazione dei metadata (‘Meta-data XML Binding Best Practice’) di IMS, che indica come strutturare in un file XML tutto l’albero dei metadata consentendo il sistema di aggregazione.

Come precedentemente affermato, lo scopo dello SCORM Run-time Enviroment è quello di fornire un metodo standard per consentire il riutilizzo dei materiali sviluppati su diverse piattaforme e favorire quindi l’interoperabilità e la durabilità dei materiali.


Perché questo avvenga deve esistere un modo comune per “lanciare” una risorsa (Launch Mechanism), una modalità unica di comunicazione tra il contenuto e la piattaforma (API) ed un set standard di informazioni che possono essere scambiate tra la piattaforma ed il materiale (Data model).

Il Launch mechanism definisce le procedure e le responsabilità per stabilire una comunicazione tra il materiale e la piattaforma. La comunicazione è standardizzata attraverso l’uso di API (Application Protocol Interface) comuni.

Le API sono il meccanismo di comunicazione per informare l’LMS dello stato in cui si trova la fruizione del materiale (es. la fruizione è stata completata) ed sono utilizzate per leggere o settare dati dal/sul Data Base della piattaforma di fruizione.

Il materiale deve utilizzare solo dati di questo set se si vuole mantenere la possibilità di riutilizzare lo stesso materiale su piattaforme diverse.

Lo stile dei contenuti

Se per quanto riguarda i requisiti tecnici di un materiale didattico esistono delle specifiche dettate nelle norme SCORM, per quanto concerne i modelli da seguire per comporre un materiale didattico efficace, non esistono linee guida ben delineate, per lo meno non sviluppate a tal punto da poter diventare punti di riferimento o standard. Pertanto, al momento di scegliere alcuni modelli efficaci di redazione di contenuti didattici, ai fini del progetto dei 10 corsi, la ricerca è stata faticosa e complicata proprio data la mancanza di riferimenti precisi.

Nonostante ciò, a livello europeo (rappresentato dai membri del CEN ISSS Learning Technologies Workshop) sono stati dichiarati alcuni requisiti ritenuti fondamentali al fine di strutturare materiali


didattici fruibili a distanza, anche in autoformazione, attenti alle necessità ed alle caratteristiche degli allievi. (Honey P., Mumford A., The manual of learning styles,)

Partendo da due delle maggiori criticità concernenti lo sviluppo dei materiali didattici, ovvero la perdita di sintesi provocata dalla bassa densità informativa del mezzo tecnologico e i brevi momenti di attenzione da parte degli allievi causati dal rapido affaticamento della percezione, le principali raccomandazioni da tenere presenti durante la realizzazione di un supporto didattico sono:

• Strutturare i contenuti partendo da una sintesi e affrontando in seguito i dettagli

• Fornire informazioni significative e non ridondanti

• Facilitare la ri-partenza dell’apprendimento provvedendo ad informazioni contestuali

• Stimolare costantemente l’allievo per cercare di prevenirne la stanchezza

Oltre a queste semplici quanto fondamentali raccomandazioni, nel panorama attuale esistono alcuni interessanti studi dedicati agli stili d’apprendimento ed al rispetto delle preferenze cognitive dell’individuo coinvolto nel processo di apprendimento. Si tratta, in pratica, di studi rivolti alla definizione dell’approccio complessivo di un individuo all’apprendimento e della modalità preferenziale di percezione e reazione ai compiti dell’apprendimento. (D.A.Kolb, Experimental Learning, Prentice-Hall 1984)

In paricolare, partendo dal ciclo di apprendimento elaborato dallo psicologo cognitivista David A. Kolb, sono stati definiti quattro stili corrispondenti alle quattro fasi percorse da un individuo durante un processo di apprendimento.

Applicati a percorsi formativi a distanza, gli studi sopraccitati e le conseguenti applicazioni sono rivolti principalmente alla realizzazione di contenuti il più possibile aderenti agli stili d’apprendimento dell’allievo, al fine di rendere il processo di apprendimento dell’individuo più efficace in termini di miglior utilizzo del tempo dedicato allo studio del materiale didattico.

Ciascun individuo, infatti, è generalmente più abile nel compiere una fase del ciclo rispetto alle altre, in quanto resta influenzato dalle proprie preferenze cognitive. (Scilligo P., Questionario sugli stili di apprendimento).

Chiaramente non esiste uno stile migliore dell’altro né tanto meno esistono individui che sanno riconoscere il proprio modello in uno degli stili individuati. Generalmente, infatti, ciascun individuo possiede uno “stile dominante” rispetto agli altri presenti e pronti ad essere applicati in modo


Esperienza

Osservazione

Concettualizzazione

Sperimentazione attiva

Fig 4:Il ciclo

efficace a seconda del compito, del contenuto e del contesto. (Mariani L., Lingua e Nuova Didattica)

Nella formazione a distanza, ancor più che nella formazione in presenza, l’attenzione agli stili cognitivi dell’allievo riveste un ruolo fondamentale ai fini di un favorevole successo formativo. Proprio la distanza fisico-temporale tra docente e discente obbliga l’organizzatore di un percorso formativo a riflettere anticipatamente sullo stile da imprimere ai contenuti da trasmettere che assumono la veste di lezioni o unità didattiche strutturate. (Mariani L., Strategie per Imparare)

L’unità didattica, quindi, ha un ruolo importante, va progettata e realizzata con cura particolare poiché non può essere rielaborata o rimodellata in tempo reale sulla base delle caratteristiche degli allievi emergenti in itinere, come, viceversa, può avvenire in un processo di apprendimento gestito in presenza.

3. Formazione esperti di contenuto

Delineate le impostazioni generali da seguire durante il processo di realizzazione dei materiali didattici, si è provveduto alla formazione degli autori dei contenuti dei 10 corsi. In particolare, sono stati affrontati temi quali: la formazione a distanza, la definizione e suddivisione dei contenuti del corso in learning objects, la definizione e la compilazione dei metadata e lo stile dei contenuti. (Fabris A., Gabellano S., Modelli manageriali emergenti).

La scrittura dei metadata è stata una operazione eseguita in parte dagli esperti di contenuto ed in parte dal gruppo tecnico di gestione. Si è proceduto dapprima alla formazione degli esperti di contenuto ai concetti e alla motivazione della scrittura dei metadata, quindi si sono definiti quali dati fare compilare procedendo ad una scrematura che ha dapprima definito quali metadata fossero ritenuti necessari. Infine i metadata sono stati divisi in generali, tecnici e specifici, lasciando la compilazione di questi ultimi agli esperti di contenuti e la compilazione dei restanti a cura del gruppo tecnico di gestione.

Per facilitare l’implementazione dei dati, la scrittura è avvenuta tramite un apposito tool sviluppato per l’occasione, nonostante non manchino in rete specifici programmi per la generazione dei metadata.


Per quanto concerne lo stile dei contenuti, con i 10 creatori di contenuto coinvolti nel progetto non è stato possibile predisporre la preparazione di ciascun Learning Object secondo i 4 stili d’apprendimento in modo da garantire un’offerta pienamente completa e rispondente ai modelli cognitivi dell’allievo. Si è però deciso di mantenere come obiettivo principale, la creazione di Learning Object secondo uno stile d’apprendimento dichiarato.

Al fine di non imporre in modo casuale uno stile a ciascun docente coinvolto è stato somministrato un test finalizzato alla rilevazione del personale stile d’insegnamento. In tal modo ciascun esperto di contenuto avrebbe creato il materiale nel modo più aderente a quanto di norma messo in atto durante le lezioni in presenza, pur rispettando determinati canoni necessari all’elaborazione di materiali didattici per la FaD quindi strutturati e parzialmente autoconsistenti, dettati dai modelli degli stili d’apprendimento.

Pertanto, durante il percorso formativo, supportati dalla prova strutturata, i docenti creatori del contenuto hanno individuato il proprio stile d’insegnamento che di norma corrisponde allo stile di apprendimento messo in atto durante il personale percorso di crescita formativa.

Individuato lo stile d’apprendimento da proporre durante l’esposizione dei materiali, la fase successiva del percorso formativo attivato con gli autori dei contenuti coinvolti ha previsto la precisazione delle componenti contenutistiche di ciascun Learning Object in base alle linee guida generali ed al rispetto dello stile di apprendimento prescelto.

Oltre allo stile d’apprendimento, un’ulteriore riferimento fornito agli esperti di contenuto sono state le linee guida generali scaturite da studi rivolti all’elaborazione di materiali didattici multimediali.


Fig 5: La compilazione del manifest di Lo

Generalmente, infatti, quando si pensa a realizzare un materiale didattico da fruire tramite l’ausilio di una tecnologia informatica, gli errori più comuni sono il ricercare la sensorialità dell’esperienza dell’apprendimento oppure al contrario semplicemente il trasporre contenuti istruttivi sul web. Da un lato, quindi, si rischia di utilizzare in modo poco equilibrato la multimedialità favorendo la distrazione dell’allievo mentre dall’altro si rischia di utilizzare poca interazione agendo in modo inefficace.

Partendo dalla suddivisione in Learning Object riportiamo brevemente le linee guida fornite agli esperti di contenuto.

Innanzitutto i momenti di sintesi: come affermato in precedenza, a causa dei limiti del mezzo tecnologico, sono necessari frequenti momenti di sintesi che aiutino non solo lo studio e la fruizione ma la ri-partenza dell’apprendimento. Di conseguenza, lo schema di redazione del Learning Object prevede la presenza di un momento di sintesi iniziale e di un momento di sintesi finale denominati rispettivamente Introduzione e Conclusione.

All’interno dell’introduzione all’allievo vengono presentati gli obiettivi, la descrizione del problema che verrà affrontato e risolto durante il Learning Object, le istruzioni fondamentali e necessarie alla fruizione corretta del materiale. Tutto al fine di chiarire le aspettative, centrare il focus dell’intervento per motivare le attività dell’allievo, facilitare il processo di autovalutazione.

Il momento di sintesi finale ha come scopo principale la ripresa sintetica dei maggiori concetti forniti e del percorso affrontato durante la fruizione del materiale, e la motivazione alla prosecuzione del percorso formativo.


Fig. 6: Corso online nella piattaforma Maestra

Dopo aver presentato la sintesi e l’ambito dell’intervento, i dettagli contenenti i concetti da presentare in modo sequenziale all’allievo vengono suddivisi in piccoli paragrafi (“chunks of content”) che rappresentano i concetti principali il cui apprendimento è ritenuto indispensabile al fine di giungere positivamente alla soluzione del problema presentato. Tali paragrafi compongono il core del Learning Object e pertanto vanno sviluppati in modo coerente ai diversi stili cognitivi degli allievi. Pertanto, in questa fase, ricopre particolare importanza l’equilibrio tra porzione grafica e testuale, tra parti visivo-verbali e visivo-non verbali, tra parti uditive e cinestetiche al fine di facilitare la fruizione e la memorizzazione dei concetti importanti da parte di allievi sensibili non solo alla qualità del contenuto trasmesso ma anche alla modalità di presentazione dello stesso.

L’interazione con l’allievo si realizza principalmente nei momenti dedicati alla valutazione dell’apprendimento. Elaborati sottoforma di esercitazioni e tests, le prime hanno lo scopo principale di costruire un alto livello di padronanza degli obiettivi definiti attraverso la riproduzione attiva e l’applicazione dei concetti studiati nelle tappe d’apprendimento e sono poste in itinere a livello dei paragrafi. I tests, invece, sono volti alla misurazione del grado di padronanza degli obiettivi: accessibili alla fine dell’LO sono costituiti da batterie di domande appartenenti a diverse tipologie (risposta aperta -con correzione da parte del tutor-, risposta chiusa, abbinamento, ordinamento cronologico o sequenziale -con feedback e correzione automatica-).

Un “buon” materiale didattico possiede, oltre a momenti di applicazione e di riflessione volti ad attivare l’allievo con pratiche di problem solving e a fornire opportunità di sedimentazione, opportunità di estensione definite nei momenti di recupero e di approfondimento. Tali momenti sono inseriti a corredo dei contenuti base del Learning Object come materiali di supporto, glossari, bibliografie, sitografie e materiali strutturati per approfondire determinati tematiche presentate lungo il percorso.


Fig 7: La suddivisione dei contenuti

Apprese le linee guida sopra definite, gli autori dei 10 corsi hanno provveduto alla stesura dei contenuti con particolare riferimento alla struttura interna dei learning objects ed alla modalità di presentazione finale. È necessario, infatti, rammentare che il “delivering system” del materiale ha influenzato notevolmente la stesura dei contenuti: tutto quanto scritto, infatti, faceva i conti con i limiti del formato di distribuzione. Limiti che si sono tradotti in alcune raccomandazioni da seguire durante la fase di redazione contenutistica: innanzitutto i titoli per quanto concerne numero di caratteri e significatività, stile del contenuto il più possibile sintetico e stimolante, descrizione chiara ed esaustiva delle parti non verbali inserite (schemi, tabelle, immagini, grafici, etc…), voce guida di accompagnamento del percorso suggerito dall’autore.

4. Fornitura dei contenuti in formato digitale

Dopo aver fornito le indicazioni principali da seguire durante la fase di redazione dei contenuti, il processo di realizzazione dei materiali ha preso avvio secondo le norme concordate con i docenti.

Gli esperti di contenuto hanno provveduto all’invio dei learning objects in formato digitale in modo parziale e sequenziale. Ciascun learning object inviato, infatti, è stato visionato dal gruppo tecnico di gestione il quale ha provveduto a sua volta all’invio di feedback e suggerimenti o proposte di modifica da validare contenutisticamente: in tal modo, il processo di verifica in itinere dei contenuti dei L.O. è stato costante ed ha reso più agevole il conseguente processo di perfezionamento del prodotto finale.

5. Realizzazione

Il progetto in esame ha riguardato la creazione di una serie di corsi FAD secondo le specifiche standard SCORM.

Date le premesse, quindi, si è passati alla progettazione grafica tenendo conto della necessità di fruire dei materiali principalmente tramite Internet con la mediazione di un LMS e della necessità di “interscambiabilità” degli stessi.

La fruibilità può essere intesa sia dal punto di vista dell’uso on line del materiale a video quanto della stampabilità dei contenuti pur definendo la fruizione via web preferenziale.

I materiali sono stati progettati in modo da poter essere visualizzati in tempi ragionevoli anche da chi non disponesse di una connessione a larga banda e soprattutto sono stati realizzati utilizzando tecnologie il più possibile cross browsing.

Per lo sviluppo sono stati utilizzati i seguenti linguaggi:

• HTML

• Cascading Style Sheet


• Javascript per la navigazione tra le pagine, le esercitazioni e l’interazione con le API SCORM della piattaforma, così come richiesto dalla specifiche standard.

Sono stati impostati due separati fogli di stile, uno per la presentazione a video e l’altro per la stampa della lezione, che hanno tenuto conto delle caratteristiche peculiari dei due media, quali risoluzione, colori, definizione, lunghezza della pagina.

Tenuto conto del fatto che la maggior parte dei monitor degli utenti utilizza una risoluzione grafica 800X600 si è deciso di strutturare la pagina in modo che fosse visibile in modo ottimale da tale risoluzione.

Al fine di facilitare l’orientamento dell’allievo in fase di fruizione si è deciso di suddividere la pagina in aree ben definite secondo la loro differenziazione logica. Si sono quindi impostati quattro frames che individuano le aree principali:

• intestazione

• indice

• contenuto

• navigazione

L’area di contenuto è stata differenziata dal punto di vista grafico dalle altre tre (graficamente uniformi) per facilitare maggiormente l’attenzione da parte dell’allievo e all’interno della stessa sono state inserite immagini di accompagnamento finalizzate all’interruzione della continuità testuale e di supporto alla memorizzazione.

Alla barra di navigazione, interscambiabile tra i vari learning objects sono state demandate tutte le operazioni di interazione con la piattaforma di fruizione.

Per quanto concerne gli standards, essendo le opportunità offerte dallo standard SCORM molto ampie, si è deciso di implementare non tutte le specifiche ma solo il core.


Fig. 8: Learning Object

Sono quindi state implementate le funzionalità SCORM a livello SCO-RTE1+Mandatory che prevede, oltre alle funzioni fondamentali di ricerca delle API messe a disposizione dall’LMS e LMSInitialize() e LMSFinish(), anche le chiamate alle funzioni di LMSGetValue() e LMSSetValue() che permettono di leggere e settare i valori:

• cmi.core.entry (R)

• cmi.core.lesson_status (R/W)

• cmi.core.lesson_location (R/W)

• cmi.core.session_time (W)

• cmi.suspend_data (R/W)

• cmi.launch_data (R)

• cmi.core.exit (W)

Le specifiche SCORM non riguardano solo la parte cosiddetta di RunTime (interazione con la piattaforma) ma anche la parte riguardante i descrittori della risorsa: i metadata. A tal fine è stato sviluppato un tool ad hoc per la creazione del file xml dei metadata che accompagnano la risorsa, sia essa un singolo LO od un corso intero.

Per quanto riguarda il file dei metadata si è ritenuto importante, visto il contesto, implementare, oltre ai campi obbligatori, tutti quei descrittori facenti parte della categoria educational. I files di metadata seguono quindi le specifiche MD-XML1+Optional.

6. Controllo e testing

In seguito alla realizzazione delle versioni di prova dei learning objects di ciascun corso, l’attività successiva ha previsto il testing della versione beta di ogni corso realizzato. Tale attività è stata effettuata da parte del docente autore del contenuto per quanto concerne la revisione stilistica e la congruenza di quanto realizzato nei confronti di quanto dichiarato dal modello definito e la gradevolezza dell’impatto visivo finale.

Contemporaneamente alla fase di testing redazionale, si è dato avvio alla fase di testing delle funzionalità del materiale tramite l’esecuzione di tests di funzionamento, tests dei media inseriti, tests di stress.

Al termine della redazione dei materiali di ogni singolo learning object, infine, ciascun autore si è occupato della compilazione dei metadata di ciascun learning object secondo le linee guida presentate e descritte durante il percorso formativo iniziale.

7. Conclusione


Nel presente contributo, ci siamo posti come obiettivo principale la sintesi del processo di realizzazione di materiali didattici per la FaD analizzando nel dettaglio le tappe percorse durante il progetto portato a termine. Ovviamente, non sono mancate le difficoltà dettate principalmente dall’adesione alle specifiche dettate dallo standard SCORM e dall’adozione di modelli di contenuto attenti ai processi d’apprendimento degli allievi.

Difficoltà quindi per entrambi gli attori coinvolti: aderire ad uno standard tecnologico ha comportato infatti uno sforzo notevole da parte del gruppo tecnico di gestione sia per quanto concerne lo sviluppo dei learning object che per quanto concerne l’aggiornamento delle impostazioni del learning management system.

Gli autori dei contenuti, dal canto loro, hanno riscontrato particolari difficoltà relativamente all’adeguamento del proprio stile di insegnamento alla redazione contenuto da trasmettere secondo un modello prestabilito per la formazione a distanza, ambito a loro sconosciuto.

In generale, però, crediamo che nonostante le difficoltà sopraelencate, i vantaggi ottenuti dalla realizzazione di materiali siano tali da ritenere tale progetto funzionale agli obiettivi preposti anche se la fase di erogazione vera e propria sarà destinata alla conferma o alla smentita di quanto affermato.

8. Bibliografia


Fig 9: Processo di produzione del

Formazione autori

Standard

Stile dei

Fornitura contenuti

Validazione

Realizzazione

Grafic Tecni

Versione

Testing di

Pubblica

Becciu M., Colasanti A.R., I.a demotivazione scolastica come, sintomo di un sè scoraggiato. Rassegna CNOS, n° 2, 1994.

Cornoldi C., Metacognizione e Apprendimento, Il Mulino, 1995.

Fabris A., Gabellano S., Modelli manageriali emergenti, Isedi, 1993.

Honey P., Mumford A., The manual of learning styles, 1984.

Kolb D. A., Experiential Learning, Prentice-Hall 1984.

Mariani L., Lingua e Nuova Didattica, Anno XXV, Numero speciale, 1996.

Mariani L., Strategie per Imparare, Zanichelli, 1996.


Fig1: La piattaforma Maestra

Scilligo P., Questionario sugli stili di apprendimento in: Polarità, Agosto 1997.

Link utiliADL - The Adavanced Distributed Learning http://www.adlnet.org/

AICC - Aviation Industry CBT Consortium http://www.aicc.org/

The ARIADNE Foundation http://www.ariadne-eu.org

CEN ISSS Learning Technologies Workshop http://www.cenorm.be/isss/Workshop/lt/

Dublin Core Metadata Iniziative http://www.dublincore.org

IEEE Learning Technology Standards Committee (LTSC) http://ltsc.ieee.org/

IMS [The Instructional Management System] Global Learning Consortium, Inc. http://www.imsproject.com/

LMML - Learning Material Markup Language http://daisy.fmi.uni-

PROMETEUS http://prometeus.org/1indexa.html

Italo Losero


AICC: come funziona

in questo capitolo

Una introduzione al modello AICC per la costruzione di materiali didatticie piattaforme FAD

AICC significa Aviation Industry CBT (Computer-Based Training) Committee (AICC) ed è una

associazione internazionale di professionisti della formazione. AICC pubblica guide per l'industria dell'aviazione per lo sviluppo, pubblicazione, e valutazione di CBT (computer based training) e le tecnologie correlate. HA gli obbiettivi:

assistere i produttori di tecnologie areonautiche nell'implementazione di sistemi di formazione assistiti da computer.

promuovere l'interoperabilità dei sistemi.

fornire un forum aperto per la discussione di queste guide.

AICC è stata una delle prime compagnie a rilasciare specifiche per la formazione mediata da computer, sino dai primi anni 80; è fortemente orientata al pragmatismo del funzionamento tecnicamente corretto dei materiali didattici e della loro interazione con la piataforma di lancio.

I corsi realizzati con lo standard AICC sono fortemente legati all’ambiente Microsoft Windows, che in qualche caso è necessario per il corretto funzionamento dei files.

Le specifiche, essendo state sviluppate anche in un’epoca pre-web, consentono il funzionamento dei corsi anche al di fuori della comunicazione client-server web, che è solo una delle possibilità di funzionamento, mentre è previsto il funzionamento in locale su una singola macchina, installando sulla stessa sia la piattaforma di formazione che il corso stesso.

AICC: come funziona - 90

terminologia

Per quanto riguarda le terminologie, AICC indica con CMI (computer managed instruction) la piattaforma o LMS, mentre con CBT indica i corsi, che possono essere interamente o parzialmente costituiti da files (in Scorm si tratta solo di digital content); AU indica le Assignable Units, che vengono ad avere un ruolo come learning objects , come gli SCO di SCORM.

Di seguito verrà analizzata la struttura delle specifiche analizzando dapprima la forma sotto la quale si presenta un corso AICC, evidenziandone le caratteristiche di comunicazione materiale-piattaforma per quanto riguarda i dati di corso e l’ambiente di runtime, specificandone infine le modalità di sequencing delle unità didattiche.

struttura di un corso

Un corso AICC è costituito dai files e materiali fisici che rappresentano i materiali didattici accompagnati da un (e uno solo) set di files che li descrivano e ne curano il comportamento in piattaforma.

Questo set di file descrive la struttura del corso e viene chiamato Course Interchange File set.

Una piattaforma che segue le specifiche AICC deve essere in grado di interpretare questo set di files per importare corsi e di generarlo per esportarli.

I file sono sette, quattro indispensabili e tre opzionali; devono avere tutti lo stesso nome, avere una estensione prefissata a seconda del tipo, essere nella stessa directory, contenere gli indispensabili elementi descritti nelle specifiche.

Sono files di testo scritti secondo due diverse modalità: alcuni come tabelle CSV altri come files INI; di entrambi sono riportate le specifiche per il binding, cioè viene spiegato nel dettaglio come vanno scritti.


Course Interchange File set

Course Description (CRS) {filename}.CRS Obbligatorio

Assignable Unit (AU) {filename}.AU Obbligatorio

Descriptor (DES) {filename}.DES Obbligatorio

Course Structure (CST) {filename}.CST Obbligatorio

Objectives Relationships (ORE)

{filename}.ORE Opzionale

Prerequisites (PRE) {filename}.PRE Opzionale

Completion Requirements(CMP)

{filename}.CMP Opzionale

Il significato dei files nel set

Course Interchange File set

Course Description (CRS) {filename}.CRS Obbligatorio

E’ il file principale che descrive i corso nella sua intierezza e non a singoli elementi del corso stesso

Assignable Unit (AU) {filename}.AU Obbligatorio

E’ il file che contiene i riferimenti alle singole unità didattiche e relativi dettagli, anche didattici (score, Time limit. etc); quando si tratta di convertire il corso in un altro f0rmato o di


utilizzarne solo i materiali didattici è il file che più interessa per localizzare i materiali.CSV.

Descriptor (DES) {filename}.DES Obbligatorio

Tiene traccia di ogni singolo elemento del corso, mantenedo la corrispondenza tra identificativi generati dalla piattaforma e identificativi dei materiali, sotto forma di tabella CSV

Course Structure (CST) {filename}.CST Obbligatorio

Contiene un raggruppamento in blocchi delle AU; suggerisce un’ordine di presentazione ricavato dall’ordine in cui sono presentate le AU

Objectives Relationships (ORE) {filename}.ORE Opzionale

Definisce la relazione tra obbiettivi e AU.

Prerequisites (PRE) {filename}.PRE Opzionale

Definisce i prerequisiti necessari all’accesso di una AU o blocco diAU

Completion Requirements(CMP) {filename}.CMP

Opzionale

Definisce i requisiti per cui può essere considerata completata una AU o completato un blocco di AU

rapporti tra CMI e WBT

struttura e comunicazioni

I files di cui abbiamo parlato precedentemente servono ad importare/esportare corsi da una piattaforma all’altra; descrivono la struttura del corso nella sua intierezza.

Tuttavia questa informazione che un corso fa verso la piattaforma mettendolo al corrente della propria struttura non è l’unica forma di dialogo tra i due attori; al momento della esecuzione del corso da parte di un utente avviene un dialogo diretto e sincrono che serve a comunicare i dati di fruizione (risultato di un test, lezione seguita, etc).

Vanno quindi distinti due transiti di informazioni: uno sulla struttura del corso e uno sulle comunicazioni tra piattaforma e materiale.


Il primo avviene in maniera asincrona rispetto alla fruizione, viene messo in atto nel momento di importazione/esportazione dei corsi; i dati comunicati vengono immagazzinati all’interno della piattaforma, in modalità proprietarie e non specificate da AICC.

Il secondo avviene in maniera sincrona con la fruizione, viene messo in atto dalle azioni che l’utente compie fruendo del materiale didattico. viene chiamata comunicazione di runtime.

elementi costitutivi della comunicazione

Come ogni modello comunicativo, entrambi sono costituiti da due specifiche: cosa comunicare e come comunicarlo. Una comunicazione telefonica, ad esempio, contiene il come comunicarlo (filo, microfono, meucci etc) e cosa viene comunicato (le parole che vengono espresse).

Le specifiche AICC informano come la piattaforma e il materiale didattico devono comportarsi (DOCUMENT NO. CMI001 CMI Guidelines for Interoperability).

Per quanto riguarda il cosa comunicare:

• vengono descritti i parametri con cui definire la struttura di un corso

• vengono definiti i parametri con cui definire la comunicazione di un corso verso la piattaforma mentre avviene la fruizione


binding, come comunicare

La modalità per comunicare la struttura di un corso è quella già vista, il course interchange file set, con i quattro file obbligatori ed i tre opzionali.

Per quanto riguarda come comunicare il runtime, vengono distinte diverse situazioni operative:

• nel caso che si operi in sistemi stand alone, non connessi in rete, viene descritto un sistema che utilizza files per scambiare dati: AICC file binding

• nel caso che si operi in un ambiente in rete via HTTP

• se si utilizza il meccanismo di comunicazione direttamente attraverso il protocollo HTTP viene descritto il sistema AICC HACP binding

• se si utilizza il meccanismo di comunicazione indiretto su HTTP ma tramite ECMA script (javascript) viene descritto il sistema AICC API binding


cosa comunicare: il data model

AICC definisce nel dettaglio che cosa deve essere comunicato all'interno dei metodi di trasporto sopra descritti.

Vengono definiti un course structure data model e un communication data model, il primo relativo alla struttura del corso, utile soprattutto per l'importazione/esportazione e settaggio dei parametri, ed il secondo relativo ai parametri che possono essere comunicati a livello di runtime.

Sia l'uno che l'altro contengono alcuni elementi di compilazione obbligatoria ed altri di compilazione facoltativa.

structure data model

Contiene 39 elementi, in gran parte obbligatori; alcuni con prevista molteplicità, ovvero possono essere inseriti molte volte, in particolare course.elements.

Servono a descrivere il corso nella sua intierezza, definendone i dati generali, il numero di AU e blocchi esistenti, una matrice di dati sui singoli elementi (AU) che costituiscono il corso.

Possono essere suddivisi in due blocchi:

• il primo contiene tutti i valori descrittivi del corso

• il secondo descrive, per ogni elemento del corso, i valori descrittivi dell'elemento.

Ad esempio, appartengono alla prima parte elementi quali il titolo del corso, l'autore, gli obbietti del corso, la sua descrizione; appartengono alla seconda parte, per ogni elemento del corso, gli stessi elementi sopra descritti ma relativi ad una AU anziché all'intero corso, insieme ad altri elementi quali il punteggio massimo ottenibile in un test, gli obbiettivi raggiungibili con il completamento del singolo elemento, etc.

I valori presenti sono utilizzati nel processo di import/export, vengono immagazzinati all'interno del CMI in una modalità non specificata da AICC.

Alcuni di essi possono essere utilizzati nelle comunicazioni di runtime.

communication data model

Il communication data model definisce 85 campi tra obbligatori (15) e facoltativi.

Assume una particolare importanza perchè nelle specifiche SCORM 1.2 viene adottato proprio questo data model, veicolato con ECMAscript, per il runtime.


I valori riguardano:

• nella prima parte, core, sono tutti obbligatori e sono relativi allo stato della particolare unità che si sta fruendo; i restanti dati sono quasi tutti facoltativi

• commenti inviati dall'utente al CMI e viceversa;

• la valutazione sul raggiungimento degli obbiettivi;

• i dati sulla fruizione della lezione da parte dello studente

• le preferenze che lo studente può settare

• le interazioni dello studente con l'LMS

• i percorsi frequentati

• dati demografici sullo studente

Il sequencing in AICC

Si raggiunge una modalità di sequenziamento impostata a livello di corso definendo elementi di corso e modalità per l'avvio e il completamento di questi elementi.

Questi elementi sono parti dell'intero corso per le quali può essere previsto un requisito di ingresso e una definizione delle modalità di completamento.

sequencing: elementi

All'interno della struttura è possibile inserire informazioni sul sequenziamento degli elementi nel corso.

Un corso può essere strutturato definendo diversi elementi, ognuno dei quali ha uno specifico identificativo di sistema:

1. AU (Assignable Unit)

2. Blocchi

3. Obbiettivi

Le Au possono essere raggruppate in blocchi; i blocchi a loro volta possono essere contenuti da


altri blocchi, organizzando il corso in sezioni.

gli obbiettivi possono essere assegnati a singole AU o a blocchi.

sequencing: prerequisiti e completamento

Per gli elementi prima citati possono essere previsti prerequisiti e requisiti di completamento, secondo lo schema:

prerequisiti -> AU -> completamento

prerequisiti -> Blocchi -> completamento

obbiettivi -> completamento


Tutti gli elementi con i loro prerequisiti e dati di completamento possono essere raccolti in espressioni logiche semplici o complesse che definiscono nel dettaglio le modalità di fruizione degli elementi del corso in base al comportamento dell'utente. Il binding in file è descritto nel dettaglio.

I requisiti per il completamento dipendono dallo stato degli elementi del corso, cioè blocchi, obiettivi e AU.

Questo stato è identificato da uno dei valori: passed, failed, completed, incomplete, browsed,not attempted.

sequencing: esempi e binding


Con gli elementi finora raccolti è possibile costruire espressioni semplici o complesse che consentono di definire nel dettaglio il sequencing delle AU.

Questo è un esempio fornito da AICC:

lo schema generale:

la traduzione in file (binding):

Questi file saranno presenti nel course interchange file set:



sequencing: modalità di funzionamento

Per il funzionamento del sequencing devono avvenire più operazioni:

• la piattaforma deve importare le informazioni di sequencing dal course interchange file set

• il materiale didattico deve comunicare lo stato in cui è attraverso le procedure di runtime

• la piattaforma deve combinare le informazioni ricevute sul sequencing con quelle che ottiene dal runtime per definire il comportamento da tenere nei confronti dell'utente



da SCORM a AICC andata e ritorno

in questo capitolo

come convertire in modo (quasi) indolore i materiali didattici per la formazione a distanza

SCORM e AICC

Per la lettura di queste note si devono avere presenti le basi del funzionamento di SCORM e AICC come specifiche per la definizione dei materiali didattici e del loro rapporto con le piattaforme.

AICC è storicamente nata prima del reference model SCORM; dedicata allo sviluppo di specifiche per i materiali didattici all'interno dell'industria aeronautica, ha cominciato i lavori nell'era pre-internet, per cui alcune parti riguardano il funzionamento di sistemi stand-alone senza connessioni in rete. Le specifiche, scaricabili dal sito aicc.org, sono erogate direttamente dall'associazione.

SCORM è una raccolta di specifiche, o meglio reference model, che non sono erogate dai promotori del progetto, ma una raccolta di specifiche create da altri attori, tra cui anche AICC; ecco perchè in qualche caso i concetti si intersecano. SCORM è un progetto erogato da ADLNET, a sua volta erogazione del dipartimento della difesa USA e dell'ufficio per le tecnologie della casa bianca.

Nel definire il reference model vengono analizzate e promosse le specifiche di altri attori pubblici o privati, quali sono AICC, IMS, IEEE.

Il metodo di lavoro

Sia i materiali SCORM che quelli AICC si riferiscono alla formazione erogata attraverso piattaforme tecnologiche; le modalità di costruzione dei materiali didattici riguardano più 'momenti' vissuti all'interno delle piattaforme di erogazione: è quindi necessario sezionare in parti la vita del materiale nella piattaforma per isolare le singole situazioni nelle quali vengono applicate le specifiche. In questo modo, comparando la modalità di funzionamento di AICC e SCORM, si possono ricavare i dati necessari per traghettare il materiale didattico da una modalità all'altra.

da SCORM a AICC andata e ritorno - 104

lifecicle del materiale didattico nella piattaforma

schema generale

Esistono due casi totalmente distinti di interazione del materiale didattico con la piattaforma: uno asincrono e l'altro sincrono rispetto alla fruizione.

Il primo, asincrono, riguarda l'importazione ed esportazione dei corsi. Un materiale didattico deve essere costruito in modo che, fornito sotto forma di pachetto software isolato, possa essere importato all'interno della piattaforma e possedere i requisiti di funzionamento che l'autore ha impostato. Lo stesso vale per l'esportazione: un corso immesso in una piattaforma può essere esportato conservando tutte le caratteristiche che ha avuto al momento dell'authoring.

Il secondo, sincrono, riguarda l'interazione del materiale didattico con l'utente al momento della fruizione. Dal momento in cui qualcuno esegue il login sulla piattaforma, viene riconosciuto, e richiede il lancio di un materiale didattico, avvengono una serie di interazioni tra materiale e piattaforma che vengono chiamate di runtime.

La 'traduzione' di un materiale da una tipologia all'altra deve conservare le funzionalità in entrambi i momenti; sarebbe inutile importare un corso che non può funzionare, né avere un corso che teoricamente può 'parlare' con la piattaforma ma che su essa non può essere installato.


La struttura dei corsi AICC e SCORM

Un corso AICC si presenta come un insieme di materiali didattici descritti come struttura e funzionamento all'interno di una struttura di 7 files, 4 obbligatori (legati alla struttura) e tre facoltativi (legati al sequencing):

L'insieme dei 7 files si chiama Course Interchange File set. Per i significati dei singoli files, si riporta ad opportuni approfondimenti.

Un corso SCORM si presenta come unico file con estensione PIF (package interchange format) che è un file zippato che ha obbligatoriamente a livello di radice un file di nome imsmanifest.xml che contiene tutte le descrizioni del corso e, solitamente in opportune directory, tutti i files che costituiscono le lezioni del corso.


All'interno del file imsmanifest.xml sono presenti diverse sezioni codificate in xml, relativi alla descrizione (metadata), alla struttura (organization – sub-manifest), ai file utilizzati (resources)

L'importazione / esportazione dei corsi

Due aspetti devono essere considerati: lo spostamento 'fisico' dei materiali e la loro strutturazione e descrizione

spostamento delle risorse

Innanzitutto va ricordato che mentre SCORM si riferisce solo a materiali digitali, AICC prevede di poter utilizzare anche risorse non digitali; nel prosieguo si tratterà solo di materiali digitali.

Inoltre AICC ha un forte accento sull'ambiente operativo Microsoft Windows; alcune funzioni sono direttamente riferite a chiamate interne Windows (es.: createProcess()), o fanno riferimento a valori che vanno direttamente scritti nel registro di Windows.

Va ancora considerato che AICC prevede anche il funzionamento standalone, con materiali didattici direttamente eseguiti sul pc utente, che non possono essere utilizzati in un'archiettura di rete HTTP; in quel caso, per portarli a SCORM, vanno previste riscritture totali dei materiali didattici.

Esistono 'luoghi' nei quali sono descritte tutte le risorse utili, cioè tutti i file necessari per il


funzionamento del corso; individuati questi 'luoghi' si potrà estrarre l'elenco e la posizione dei file necessari in modo da poterli singolarmente individuare e sistemare nella piattaforma di erogazione nella posizione più opportuna.

• per AICC sono descritti all'interno del Course Interchange File set nel file con estensione DES, che tiene traccia di ogni singolo elemento del corso, mantenendo la corrispondenza tra identificativi generati dalla piattaforma e identificativi dei materiali, sotto forma di tabella CSV

• per SCORM sono all'interno dell'imsmanifest.xml nella sezione resources, sotto forma di XML.

Lo spostamento dei file quindi si risolve nell'andare a cercare nel giusto punto l'elenco dei file necessari e nel portarli a destinazione; nel caso di 'traduzione' da uno standard all'altro si tratta semplicemente di scrivere in modo diverso l'elenco dei files.

interpretazione della struttura e del sequencing

Il discorso è più complesso per quanto riguarda la struttura dei materiali; va 'capita' la strutturazione data ai materiali nel primo formato per poterla tradurre nel formato di destinazione.

Ciò ha importanza fondamentale, perchè, oltre a inibire o meno il funzionamento, ha diretta influenza sulle procedure di runtime, che a loro volta si basano sulla struttura del corso.

SCORM, nel modello più semplificato, precede una struttura a tre livelli: il corso è costituito da learning objects chiamati SCO che a loro volta possono essere costituiti da Assets; gli assets sono oggetti semplici che non hanno capacità di comunicazione con la piattaforma, gli SCO sono i più piccoli oggetti in grado di comunicare con la piattaforma ed essere 'autonomi' nel funzionamento, mentre il corso è una aggregazione di SCO. Esiste una certa differenza nella definizione di 'corso' tra SCORM1.2 e SCORM1.3 (o 2004). Le specifiche più recenti indicano un corso come aggregazione di contenuti (content aggregation) costituito da una organizzazione (content organization) a sua volta costituita da learning activities che a loro volta possono contenerne altre; a livello di foglia dell'albero delle attività (activity tree) ogni learning activity corrisponde ad uno SCO. A tali learning activities sono direttamente colllegati i meccanismi di sequencing and navigation.

In SCORM 1.2 la struttura è direttamente espressa come content aggregation e definito come mappa delle risorse disponibili; attraverso i prerequisiti di fruizioni possono definirsi modalità di sequencing.

Va qui fatta una nota: in realtà le modalità di sequencing non sono quasi mai state eseguite in questo modo, perchè la norma non è chiara e perchè l'evoluzione (1.3) ha seguito altre strade. Di conseguenza si è assistito ad un uso vendor-based dei requisiti per ottenere meccanismi di sequencing o, più semplicemente, si sono utilizzati modi di fruizioni lineari tra le unità didattiche messe a disposizione. E' diventato uso comune non prevedere meccanismi di sequencing in SCORM 1.2

In SCORM 1.3 il sequencing rappresenta la 'novità' della versione e prevede meccanismi derivati da IMS sequencing che sono di una certa complessità. Le specifiche prevedono 70 pagine di pseudo-code per definire il modo con il quale le piattaforme dovrebbero interpretare i meccanismi di sequencing forniti dai materiali didattici. E' un'operazione complessa da seguire, ad oggi poche piattaforme supportano questa modalità di funzionamento.

In AICC la struttura è definita per unità didattiche (AU), blocchi di unità e obbiettivi; i meccanismi di sequencing sono più consolidati, basati sullo stato di prerequisiti e requisiti di completamento delle unità didattiche, dei blocchi e degli obbiettivi.


Migrare la struttura

Per quanto riguarda la struttura del corso i meccanismi di traduzione tra i due standard non rappresentano particolari difficoltà. Il 'mattone' di base in entrambi i casi è un oggetto autonomo (AICC->AU, SCORM->SCO), il raggruppamento in blocchi è facoltativo in entrambi i casi, la sovra-struttura corso esiste allo stesso livello per entrambi; a parte le differenze nel binding, cioè nel tradurre i concetti in file (di testo, CSV per AICC - XML per SCORM) i concetti sono similari.

Ciò che è ben sviluppato, fin dalle prime versioni , in SCORM sono i metadati, che non trovano analogo corrispondente in AICC. I metadati cono la ricchezza informativa che circonda ogni singolo corso o SCO; pur essendo prevista in AICC una sezione relativa alle informazioni per ogni oggetto, non esiste una modalità così ricca come IEEE LOM (learning object metadata, la specifica su come scrivere i metadati). Inoltre AICC non prevede specificatamente il livello assets, mentre in SCORM il livello esiste e può utilizzare metadati LOM.

Questo significa che nel passare da SCORM a AICC si perde la ricchezza del dato, mentre nella direzione opposta diventa obbligatorio marcare i nuovi oggetti con i metadati; quantunque IEEE LOM di per sè non preveda l'obbligatorietà di nessun dato e consenta l'utilizzo di risorse digitali, quando ADLnet ne ha scelto la specifica per l'introduzione in SCORM ne ha ristretto l'ambito di applicazione ai soli oggetti digitali e ha definito per ogni livello, corso - SCO - asset, quali metadati devono essere obbligatoriamente presenti.

Migrare il sequencing

Non sempre, all'interno dei corsi presenti in commercio, sono previsti meccanismi di sequencing. I casi che si verficano sono di tre tipi:

• non c'è alcun meccanismo di sequencing

• sono presenti semplici meccanismi di sequencing che prevedono due modalità di fruizione: la libera fruizione di tutte le unità didattiche o la fruizione vincolata ad un accesso sequenziale alle unità didattiche; il passaggio dalla unità x alla unità (x+1) è definito dall'aver frequentato/visto quella precedente o dall'aver superato il test precedente

• ci sono meccanismi più avanzati di sequencing, che prevedono modalità complesse di navigazione tra le unità didattiche dipendenti dall'interazione dell'utente con la piattaforma

• Nel primo caso, chiaramente, siamo nella soluzione più semplice per quanto riguarda la migrazione; le unità didattiche vengono proposte a libera scelta e disposte in modo sequenziale. E' il caso di default per SCORM 1.2.

• Il secondo e terzo caso sono più complessi, perchè interessano anche le chiamate di runtime; oltre a ricostruire l'esatta struttura e l'esatto sequencing, si deve far sì che le chiamate di runtime interagiscano con la struttura nel modo definito nel sequencing.

• In particolare nel secondo caso, la migrazione tra SCORM e AICC diventa abbastanza semplice se si tratta di SCORM 1.2; altrementi si cade nel terzo caso. Si tratta, a livello di AICC, di leggere come i file opzionali descrivono il sequencing che, in questo caso, è semplice; in SCORM si andrà a posizionare gli SCO in modo sequenziale/lineare e a livello di prerequisiti di fruizione li si lascerà vuoti (fruizione a libera scelta) o ogni SCO avrà come prerequisito l'aver frequentato quello precedente o aver ricevuto dal runtime un certo voto dal precedente (l'implementazione del dato è molto vendor-oriented, in quando ADLnet non fornisce dettagli su questo tipo di sequencing perchè li specifica in 1.3)

• Nel terzo caso prevediamo che i materiali SCORM saranno erogati da un LMS SCORM 1.3


per il sequencing, che quindi implementa tutto il pseudo code (i casi sono ad oggi pochi!). Le informazioni di sequencing per AICC si ottengono ancora dai file opzionali, mentre per SCORM 1.3 vanno scritte/lette le specifiche di sequencing, che in parte sono contenute all'interno della descrizione della struttura (content organization) ed in parte sono a livello generale nel CAM (content aggregation) come specifica a sè (IMSsequencing). La traduzione passa attraverso uno stato intermedio in cui, su carta, vengono definiti i modelli di sequenziamento letti dal corso da tradurre; in un secondo momento vengono scritti nella modalità del file di destinazione

E... navigation?

In SCORM 1.3 il book che si occupa di sequenziamento si chiama sequencing and navigation. Oltre alle specifiche di sequenziamento riporta anche quelle di navigazione: questo significa che una piattaforma LMS SCORM 1.3 fornisce al corso le modalità di navigazione, cioè i menu attraverso i quali l'utente può navigare nel corso, sfogliare le pagine, afrontare nuove unità/test, etc.

Mentre 'normalmente' il corso prevede un proprio menù di navigazione, in queto caso il corso contiene materiali didattici non singolarmente fruibili se non con l'ausilio di una piattaforma di supporto che ne fornisca i meccanismi di navigazione.

Non c'è nulla di simile in AICC.

Tuttavia, nella conversione AICC -> SCORM 1.3 e nel caso del secondo punto del paragrafo precedente, potrebbe bastare fornire quale modalità di navigazione utilizzare (sequenziale/libera) per utilizzare navigation e risolvere il problema del sequencing.

Nell’immagine viene utilizzato l’ambiente di runtime fornito come esempio da ADLnet per testare un materiale didattico;

a sinistra la navigazione è imposta come sequenziale, la piattaforma offre il pulsante ‘continua’ per fornite lo SCO all’utente ;

a destra la navigazione è impostata come libera, quindi vengono fatti vedere i contenuti del corso tra i quali si può scegliere, mentre la piattaforma offre i pulsanti per sospendere o abbandonare la lezione.

il runtime


Con il termine runtime si identificano quelle azioni che vengono poste in essere al momento della fruizione del corso e che riguardano l’interazione tra materiale didattico e piattaforma in conseguenza delle azioni dell’utente.

Trattandosi di comunicazione vanno identificati un mezzo trasmissivo (come comunicare) e una intesa su cosa comunicare, anche chiamata il data model.

cosa prevede AICC

AICC prevede 3 modelli adottabili sul come comunicare e un data model.

I tre modelli sono:

• per piattaforme stand alone, basate su file locali: protocollo basato su file (runtime file binding)

• per piattaforme su web:

• comunicazione via protocollo HTTP (HACP binding)

• comunicazione attraverso API ECMAscript (API binding)

Sul cosa comunicare è previsto un data model, che prevede:

• nella prima parte, core, sono tutti obbligatori e sono relativi allo stato della particolare unità che si sta fruendo; i restanti dati sono quasi tutti facoltativi

• commenti inviati dall'utente al CMI e viceversa;

• la valutazione sul raggiungimento degli obbiettivi;

• i dati sulla fruizione della lezione da parte dello studente

• le preferenze che lo studente può settare

• le interazioni dello studente con l'LMS

• i percorsi frequentati

• dati demografici sullo studente

cosa prevede SCORM

Nella storia del modello SCORM si sono susseguite tre fasi nei confronti del runtime:

• in un primo momento, nelle prime versioni del modello, il focus era sull'organizzazione dei contenuti e sulla descrizione con i metadati

• in un secondo momento (SCORM 1.2) è stato introdotto il runtime; in particolare è stato adottato il modello proposto da AICC, integrandone il come e il cosa comunicare.

• l’ultima versione di SCORM, 1.3 o 2004, adotta un’altro modello di runtime, conservando però le modalità di comunicazione (ECMAscript) del runtime precedente; pur mantenendo il come è cambiato il cosa comunicare, cioè il data model.


AICC-> SCORM

Si deve definire verso quale versione di SCORM si vogliono convertire i materiali AICC.

Se la versione è SCORM 1.2 le operazioni di conversione possono anche essere poche o nulle, a seconda del binding di partenza.

Se si parte da corsi che utilizzano il file binding l’operazione è complessa: si devono ‘smontare’ i corsi, individuare le singole chiamate che vengono fatte, trasformarle in chiamate alle API magari sviluppando un wrapper in ECMAscript per facilitarsi il compito di traduzione.

Se si parte da corsi che utilizzano l’HACP binding si può con opportuna ingegneria e qualche malizia da webmaster cercare un percorso più veloce trasformando le chiamate su HTTP in chiamate ad un wrapper che a sua volta le trasformi in chiamate API.

Se si parte da corsi che utilizzano l’API binding si è nel caso più fortunato, in quanto la modalità di funzionameno è la stessa di SCORM. Potrebbe non essere necessario alcun cambiamento, ma si deve comunque fare una verifica perchè potrebbero esserci chiamate con risposte in funzione della struttura del corso, diversamente definita da AICC e SCORM, che quindi potenzialmente potrebbero dover essere modificate.

Se la versione è SCORM 1.3 sono valide tutte le considerazioni precedenti per il come comunicare, ma devono essere riscritte tutte le chiamate perchè cambia il data model, passando da quello di AICC a quello di IEEE. Lo SCORM Run-Time Environment Data Model è basato su P1484.11.1 Draft Standard for Learning Technology - Data Model for Content Object Communication standard prodotto da IEEE LTSC Computer Managed Instruction (CMI).

La differenza non è abissale, ma le stesse chiamate indispensabili per comunicare l’inizio e la fine della fruizione sono chiamate con termini diversi, quindi vanno riscritte.

Andando nel dettaglio ci sono chiamate presenti nell’uno e non nell’altro modello, quindi non è sufficiente sviluppare un ‘traduttore’ di chiamate.


Repositories di learning objects

1 - Premessa

Chiunque si occupa di didattica si occupa di informazione, condividendo e diffondendo informazioni tra docente e discente. Le nuove tecnologie dell'informatica, come informazione automatica, non possono che interagire con le modalita' con cui la didattica si esprime. Per questo la diffusione delle tecnologie dell'informazione ha fatto si' che molti docenti ed editori organizzassero contenuti didattici in forma informatica; a volte per una semplice memorizzazione del dato, a volte per una organizzazione piu' complessa che ne facilitasse la fruizione. Le istituzioni e le imprese che hanno prodotto materiali didattici si trovano ora nella necessita' di organizzare e rendere disponibili in modo sistematico i materiali creati. Il paradigma dei learning objects con la relativa granularita' che prospetta fa si' che si possa avere un approccio sistematico per la catalogazione di questi (piccoli) oggetti didattici, la loro aggregazione e distribuzione.La delocalizzazione delle risorse consentita dalla diffusione della rete costringe ad ipotizzare architetture distribuitte piuttosto che ad applicazioni stand-alone. Le tecnologie relative alla raccolta dei dati non sono cambiate concettualmente molto rispetto a qualche lustro or sono; co' che e' fortemente cambiato sono le modalita' di veicolazione e di trasmissione dei contenuti. Per questo, accanto a sistemi di catalogazione ormai consolidati e ampiamente adottati (es. ISBN, Dublin Core) si devono porre sistemi di scambio di informazioni e pubblicazione di materiali che rispondono a tecnologie e metodi relativamente giovani (SOAP, XML). Il progetto di 'depositi' di oggetti didattici diventa cosi' esercizio di unione sinergica di sistemi di organizzazione di dati e di trasporto di informazioni.

In questo documento viene delineato un possibile percorso che, partendo da materiali disomogenei digitali e non digitali creati da autori diversi localizzati in sedi fisiche diverse, porti alla creazione di una repository o deposito di materiali didattici accessibili secondo diverse forme di utilizzo.

2 - I materiali di partenza

Parte della ' ricchezza' di un ente o impresa che si occupi di formazione risiede nei materiali utilizzati come supporto alla didattica. A volte la creazione e' demandata alla buona volonta' dell'insegnante, altre volte sono presenti strutture di creazione dei materiali didattici che

Repositories di learning objects - 113

producono oggetti ad un piu' approfondito livello di definizione tecnica, metodologica e di autonomia didattica. La diversita' delle situazioni di partenza provoca la conseguente disparita' degli oggetti prodotti; volendo ricordare solo alcune delle disparita' macroscopiche:

• per quanto riguarda i supporti o materiali digitali o materiali non digitali

• per quanto riguarda la finalita', o materiali creati per il supporto alla didattica, che necessitano della guida del docente o materiali per l'autoistruzione

• per quanto riguarda la tecnologia o materiali che devono essere fruiti con un apposito 'player' o materiali fruibili attraverso il web

Tutti questi materiali devono essere indicizzati in maniera univoca; vanno perciò cercati metodi che omogeneizzino il modo con cui vengono descritti così da utilizzare l'uniformità descrittiva per poter costruire sistemi di catalogazione e ricerca efficienti.

3 - La condivisione dei materiali prodotti

Condividere i materiali prodotti equivale ad una capitalizzazione degli investimenti in tempo e risorse necessari per creare i singoli materiali. Soprattutto in ambienti scolastici si assiste alla proliferazione di materiali su argomenti simili costruiti da docenti diversi che vanno a sovrapporsi moltiplicando gli sforzi e impoverendo i risultati. Gli stessi tempi, organizzati sullo stesso materiale da parte di più persone in modo collaborativo, genererebbero un risultato più completo ed efficace a parità di risorse investite.

La condivisione delle risorse consente inoltre di non iniziare da zero; quando un docente/editor vuole creare un nuovo materiale parte da uno già realizzato (se presente) adattandolo e/o migliorandolo massimizzando così le risorse dedicate.

Non sono poche le resistenze che vengono poste a questo approccio; permangono forti rapporti di dipendenza tra un autore ed i propri materiali, giudicati sempre migliori di quelli prodotti da altri sullo stesso argomento. Inoltre una certa 'gelosia' nel condividere quanto creato (sia a livello di persone che di istituzioni) e' spesso freno ai sistemi di condivisione dei materiali. Mentre i vertici dell'organizzazione possono vedere da subito i frutti della condivisione dei materiali in un'unica banca dati, gli autori dei materiali ne vedono i vantaggi solo a posteriori, quando possono adattare ai propri scopi i materiali altrui o partire da essi per costruirne nuovi.

C'e' inoltre un passaggio obbligatorio che a volte e' cosi' stretto da impedire il passaggio alla organizzazione in unica banca dati: la standardizzazione. Nel catalogare ogni materiale in modo che sia classificabile e' necessario passare attraverso un utilizzo condiviso della metodologia di catalogazione che deve essere unica e condivisa, pena l'insuccesso dell'operazione. Cio' comporta la accettazione e condivisione di vocabolari comuni e di metodi condivisi.


Nel creare le modalita' di standardizzazione si possono inventare sistemi ex-novo che si adattino all'organizzazione in cui vengono calati; e' sempre meglio analizzare prima cio' che esiste a livello internazionale, quindi cercare di adattare una delle metodologie diffuse; se non si incontra quella 'ottimale' si puo' adattare una esistente con i meccanismi di espansione quasi sempre presenti e, solo in ultima analisi, verificata l'impossibilita' di utilizzare uno dei punti precedenti, creare una propria metodologia di catalogazione.

Uno degli indicatori di qualita' dei materiali creati piu' diffuso nelle maggiori repository e' il peer review che consiste nel raccogliere giudizi di qualita' da parte degli utenti (selezionati o meno) sui materiali didattici. Piu' si allarga il numero di utenti interessati e piu' diventa un criterio accettabile anche se 'punitivo' verso alcuni materiali. Si puo' fare un facile parallelo con il peer review del sito di aste e-bay, dove il giudizio degli utenti dato su un venditore (editor) e' la cartina di tornasole per comprare (fruire) l'oggetto (materiale).

In ogni caso il processo di organizzazione e condivisione dei materiali richiede una forte motivazione da parte degli attori coinvolti e un forte coaching da parte degli organizzatori, puo' difficilmente essere applicato in maniera forzosa e mostra i migliori risultati sul lungo termine, mentre i difetti collegati alla mancata introduzione sono immediatamente visibili.

4 - Strategie di organizzazione delle repository: un approccio bottom-up

Una volta stabilita la volonta' di organizzare le risorse in una (o piu') repository di materiali si procede a definire i criteri di classificazione dei materiali.

Gli standard organizzativi vanno definiti a vari livelli:

• a livello di catalogazione del singolo materiale didattico

• a livello di servizi forniti da un singolo deposito di materiali didattici

• a livello di metadeposito di materiali didattici

Classificazione dei singoli materiali didattici

La pratica di classificazione dei materiali didattici passa attraverso il concetto di metadati (dati di


dati) cioe' descrittori del materiale didattico che ne definiscono alcuni aspetti; sono paragonabili alla classica 'scheda' cartacea una volta presente nelle biblioteche utilizzata per descrivere un volume; lo schedario definiva l'insieme dei volumi presenti.

La scheda non e' il volume, e' una entita' separata che ne descrive il contenuto ed alcune caratteristiche salienti (editore, data, etc). Allo stesso modo i metadati sono entita' separate dal materiale didattico, utilizzati per descriverlo. Nello scegliere quali dati registrare entrano in campo gli standard.

Come prima accennato si puo' scegliere di non aderire ad alcuno standard, utilizzarne uno presente o adattarne uno tramite modifiche. La scelta di non adottare alcuno standard va fatta con estrema cautela in quanto potrebbe vanificare tutto il progetto una volta che si deve 'aprire' verso altre realta'.

L'adozione di uno standard così com'e' e' la soluzione che garantisce la massima apertura del sistema e da' garanzie di stabilita'. L'adattamento diventa indispensabile quando e' necessario inserire descrittori non previsti direttamente dallo standard.

Nella descrizione dei materiali didattici quelli piu' utilizzati sono il Dublin Core e IEEE LOM. Va qui appena ricordato che la classificazione attraverso metadati fornisce un approccio tecnologico che permette una efficiente catalogazione. Cio' non implica una catalogazione di qualita'. L'affidamento della redazione dei metadati a persone qualificate e' elemento di importanza fondamentale per la buona organizzazione dei metadati.

Dublin Core

Pochi anni dopo l'introduzione del world wide web (1994) sembra enorme il numero di pagine presenti, circa 500000; viene promosso un sistema di metadati per cercare di dare una catagorizzazione semantica alle pagine web; tenendosi a Dublin, nell'Ohio, le specifiche definite verranno chiamate Dublin Core1 (DCMI, Dublin Core Metadata Initiative). Il sistema prevede di indicizzare risorse ovunque localizzate nella rete, identificando come risorsa 'qualsiasi cosa che ha una identita'', senza alcun tipo di restrizione. Non prevede l'applicazione alle sole risorse web, ma puo' indicizzare qualsiasi tipo di oggetto. I campi previsti sono2:

1. Title: Il titolo o il nome della risorsa attribuito ad essa dall'autore o dall'editore.

2. Creator La persona o l'organizzazione primariamente responsabile per la creazione del contenuto intellettuale della risorsa.

3. Subject L'oggetto trattato nella risorsa. Tipicamente questo campo e' utilizzato anche per contenere le parole chiave (keyword). L'uso di vocabolari controllati e schemi di classificazione e' incoraggiato.

4. Description Una descrizione testuale della risorsa, ad esempio l'abstract nel caso di un articolo.

5. Publisher L'ente responsabile per rendere la risorsa disponibile nella sua forma attuale.


6. Contributor La persona o l'organizzazione, non specificata nell'elemento Creator, che ha realizzato una parte significativa nel contenuto intellettivo della risorsa.

7. Date Data di creazione o della pubblicazione della risorsa. Per il formato da utilizzare si veda ISO 8601 ( http://www.w3.org/TR/NOTE-datetime)

8. Type La categoria della risorsa, ad esempio: "Home Page", "Racconto", "Report Tecnico", etc... Per problemi di interoperabilita' dovrebbe essere espresso sempre in inglese e scelto da una lista limitata di possibilita'.

9. Format Il formato dei dati contenenti la risorsa ed opzionalmente le sue dimensioni. Anche questo campo dovrebbe essere scelto da una lista limitata standard.

10.Identifier Un identificatore univoco della risorsa. Ad esempio la sua URI (Uniform Resource Identifier) oppure l'International Standard Book Number (ISBN).

11.Source Eventuali informazioni su un'altra risorsa dalla quale la presente e' stata derivata.

12.Language La lingua utilizzata, espressa come definito nel RFC1766.

13.1Relation Contiene l'identificatore di un'altra risorsa correlata. Questo elemento %uFFFD ancora in sviluppo.

14.Coverage Le caratteristiche spaziali e temporali del contenuto descritto nella risorsa. Ad esempio per un libro di storia sull'Europa nel medioevo.

15.Rights Un indentificatore di una risorsa che definisce la licenza d'uso della risorsa in questione.

'Ad esempio:

< META NAME="DC.Creator" CONTENT="..............." >

indica lautore del documento

< META NAME="DC.Contributor" CONTENT="..............." >

indica eventuali soggetti che hanno contribuito alla realizzazione del documento

Il Dublin Core non indica alcun campo come obbligatorio, sara' la specifica implementazione a definire quali campi devono essere obbligatoriamente compilati. La tipica implementazione del Dublin Core e' all'interno delle pagine HTML, dove in una zona non visibile all'utente sono immagazzinati i dati secondo Dc. Tuttavia i maggiori motori di ricerca tendono a non utilizzare questi dati per indicizzare le pagine, in quanto spesso utilizzati da creatori di contenuti 'poco scrupolosi' che pur di far salire l'importanza delle pagine scrivono qualsiasi cosa. L'importanza di questo standard e' stata definitivamente siglata dal fatto che sotto la guida del National Information Standards Organization (NISO) lo standard di metadata Dublin Core e' stato recentemente recepito come norma ISO 15836:20034. IEEE LOM (SCORM) Tools Si parla di binding dei metadati quando si passa dal concetto teorico di metadato con un valore assegnato alla sua scrittura permanente, tipicamente su un file. Il tipico binding del Dublin Core e' come file HTML all'interno (nel codice) di ogni pagina web, dove all'interno dei tag esistono coppie nome-valore che descrivono gli elementi del Dublin Core. Ma nulla vieta di scrivere i valori all'interno di un qualsiasi database; i dati molto spesso vengono scritti in file XML che sono per loro natura adatti a ricevere questi tipi di informazioni, a livello di servizi forniti da un singolo deposito di materiali didattici


Una volta creato il 'deposito' di materiali didattici su di esso vanno montati i servizi necessari al suo utilizzo.

Da una parte saranno presenti i servizi che riguardano l'immissione e la catalogazione dei materiali, dall'altra parte i servizi di consultazione della repository.

Servizio di immissione dati

Non si tratta del semplice caricamento di materiali didattici, ma dell'inserimento ragionato di oggetti didattici finalizzato al successivo recupero e utilizzo. Vanno implementati meccanismi che vedono solo come ultimo passo il caricamento fisico dei files (quando presenti), mentre devono essere definite con precisione le politiche di catalogazione ed accettazione dei materiali. La marcatura con metadati del materiale caricato e' la procedura principale per la catalogazione. A seconda dello schema utilizzato vanno distinti i campi di obbligatoria compilazione rispetto a quelli facoltativi; alcuni possono essere definiti come indispensabili per una prima immissione del materiale, altri possono essere considerati di indispensabile compilazione solo dopo il caricamento del materiale nella repository, subordinandone la pubblicazione al completamento della procedura. Il sistema di marcatura dei metadati deve essere per quanto possibile sequenziale, suggerendo all'utente un percorso preferenziale di compilazione, facilitante utilizzando vocabolari di voci dove questo e' possibile (o obbligatorio), autocorrettivo impedendo di inserire voci in aperto contrasto tra loro. Il processo assume particolare importanza in quanto e' attraverso ai metadati che i materiali verranno cercati/trovati; la corretta compilazione e' prerequisito essenziale al funzionamento del sistema.

Per questo possono prevedersi linee-guida per la compilazione, sistemi di help interattivo, corsi di formazione ad-hoc per il personale addetto all'immissione dei dati.

Quando il materiale catalogato e' di tipo digitale puo' avvenire il caricamento del materiale nella repository, o tramite upload da pagina web o con meccanismo piu' complesso (ftp, trasferimento manuale, etc.); in questo caso la repository diventa anche il luogo fisico nel quale sono depositati i materiali. Altre volte si preferisce lasciare i materiali in altro luogo, peraltro raggiungibile in rete, pur inserendo i metadati nella repository; molti dei cataloghi di materiali didattici presenti in rete fanno riferimento a materiali , siti o parte di siti che sono raggiungibili via web. Un particolare servizio di immissione dati riguarda il peer review, ovvero la possibilita' di esprimere giudizi sui materiali terzi da parte di persone diverse dall'autore che siano disponibili per gli utenti della repository


Servizio di consultazione

In questo servizio risiede la maggiore evidenza dell'utilita' delle repository. Si deve dare l'opportunita' agli utenti di trovare e utilizzare il materiale depositato. La ricerca avverra' secondo diverse tipologie:

• una ricerca semplice consente la ricerca di un materiale semplicemente digitando una o piu' keyword. Pur essendo la ricerca piu' semplice per quanto riguarda l'utente, e' la piu' complessa dal punto di vista tecnico. Si tratta di definire in quali metadati viene eseguita la ricerca, con quali modalita' confrontare le keyword con i dati, quale peso dare ai diversi metadati.

• La ricerca complessa potrebbe consentire la ricerca differenziata in tutti i campi dei metadati disponibili, o in un sottoinsieme che si ritiene significativo. I risultati della ricerca possono essere direttamente fruiti se si tratta di risorse digitali (visualizzati o scaricati), oppure immagazzinati in una zona dedicata all'utente per un successivo riutilizzo. Piu' materiali didattici, opportunamente collocati in sequenza, possono costruire una unita' formativa; alcune repository consentono di legare in un corso i materiali ed in alcuni casi ne consentono il download come corso SCORM per l'utilizzo in una piattaforma compatibile con lo standard.

metadeposito di materiali didattici

Nel modello visto finora, ad un unico deposito nel quale vengono depositati i metadati possono corrispondere piu' luoghi nei quali le risorse sono fisicamente presenti, siano esse digitali o non digitali. In uno scenario piu' complesso, piu' repository possono scambiarsi i metadati per aumentare di volume l'archivio e consentire agli utenti la ricerca su un numero piu' grande di dati a disposizione.

L'aggiornamento e il mantenimento di queste larghe basi di dati condivisi e' stato applicato in diverse applicazioni telematiche tra quelle che piu' hanno stravolto il panorama della rete e che ne hanno consentito l'espansione e la potenza d'uso; tra queste si possono citare in ordine cronologico di applicazione i motori di ricerca, la diffusione dei software di download peer-to-peer, il formato di scambio news RSS.

• I motori di ricerca fanno riferimento a 'oggetti' telematici (i siti) che sono fisicamente presenti in una location unica. Il motore di ricerca ne analizza i metadati, mantiene un database aggiornato che mette in relazione i metadati con la posizione dei siti e mette a disposizione degli utenti la ricerca tra i dati. Non contiene i siti stessi (a parte la copia di alcune pagine che a volte e' trattenuta) ma solo i metadati che li descrivono.

• I software peer-to-peer, da napster in poi, funzionano in modo molto simile. Questa volta i 'materiali' sono presenti sui pc degli utenti stessi, che funzionano sia da server; i metadati sui contenuti vengono trasferiti aun database sul quale viene costruita l'interfaccia di riceerca dei brani (o del software). Anche in questo caso non e' la repository che contiene i materiali, ma svolge una funzione di ricerca per conto degli utenti; una volta ottenuto il


risultato lo si puo' prelevare dal computer sul quale risiede.

• Il formato RSS (Really Simple Syndication) e' un altro esempio del paradigma citato. E' finalizzato alla ricerca/presentazione di notizie, cioe' di pagine web comunque complesse relative a notizie. Anche in questo caso la pagina web risiede unicamente su un server, ma i metadati vengono distribuiti verso un database centrale che ne consente la ricerca e indicizzazione; una volta trovata la notizia ricercata questa viene 'scaricata' direttamente dal server nel quale risiede. Rispetto ai casi precedenti questa volta abbiamo una codifica della modalit%uFFFD con la quale i metadati vengono trasferiti, alla quale fa riferimento il protocollo RSS.

Nel creare un sistema di repository tra loro collegate riveste particolare importanza la modalita' con la quale le repository scambiano i dati tra loro. Nel caso dei motori di ricerca esistono particolari agenti software (spider, crawler, etc.) che con una certa frequenza visitano i siti, estraggono informazioni (metadati) e compilano il database centrale. Nel caso dei software peer-to-peer e' il programma utilizzato che scandaglia i metadati dell'utente (essenzialmente i nomi dei files da condividere) e li sposta verso un database centrale. Nel caso di RSS esistono agenti software che scandagliano i siti che offrono questo servizio ad intervalli regolari e portano i risultati al database centrale.

Nel caso delle repository di materiali didattici si deve pensare ad un meccanismo di scambio dati che consenta ad una repository di avere i dati di altre repository alle quali e' collegata; questo meccanismo puo' funzionare a tempo o per notifica.

Con i meccanismi a tempo, similmente ai motori di ricerca, esiste un software che funziona ad intervalli regolare ed interroga le repository con cui si e' collegati.

Con i meccanismi di notifica la repository sulla quale sono avvenuti cambiamenti e/o modifiche notifica le altre repository con cui e' collegata dell'avvenuto cambiamento, invitando rispettivi agenti a scandagliarli, o trasmettendoli insieme al messaggio di notifica. Questo meccanismo di raccolta dei dati viene chiamato data harvesting, per quanto riguarda le modalita' con le quali queste 'interrogazioni' avvengono esistono alcuni standard definiti; si rimanda alle specifiche IMS sulle repository e a OAI-MPH per gli approfondimenti.

http://dublincore.org/about/history/ Da http://giosue.home.cern.ch/giosue/tesi/tesi/node48.html http://archivi.beniculturali.it/Biblioteca/DCbiblioteca.html http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37629&ICS1=35&ICS2=240&ICS3=30 SESDL


Date post:	25-May-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

appunti su SCORMlnx.itisgalileiroma.it/joomla/images/stories/pdf/appunti scorm.pdf · La terza...

Documents