universita` degli studi di trento - Marco Ronchetti

UNIVERSITA’ DEGLI STUDI DI TRENTO
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea
INFORMATICA
Elaborato Finale
UN REPOSITORY DISTRIBUITO PER LEARNING OBJECT
Relatore/1st Reader:
Laureando/Graduant:
Ronchetti Marco
Groff Matteo
Anno accademico 2010 - 2011
INTRODUZIONE.............................................................................................................3
Cos'è un Learning Object..................................................................................................4
Learning Object Metadata (LOM)................................................................................4
Implementazione di LOM........................................................................................5
JaxB..........................................................................................................................5
VCARD....................................................................................................................6
Esempio di file vCard..........................................................................................6
Caratteristiche di un buon repository.................................................................................7
Repositori già esistenti:.....................................................................................................7
Merlot:...........................................................................................................................7
Le Mill..........................................................................................................................8
Connexion.....................................................................................................................9
Ariadne..........................................................................................................................9
Generazione dei Metadati per Learning Object...............................................................10
Tipo Oggetto: .............................................................................................................11
Materia: ......................................................................................................................11
Argomento:.................................................................................................................11
Target:.........................................................................................................................12
Keywords:...................................................................................................................12
Organizzazione del Repository........................................................................................12
Architettura.................................................................................................................12
Core.............................................................................................................................14
Tecnologie Utilizzate..................................................................................................15
EJB .......................................................................................................................15
Web Services..........................................................................................................16
Database XML.......................................................................................................17
Utilizzo del Database XML nel Core:....................................................................19
Database Relazionale.............................................................................................19
Generatore di Metadati....................................................................................................20
Estrattore:....................................................................................................................21
Generatori...................................................................................................................21
Funzionamento del Repository........................................................................................22
Gestione degli Utenti..................................................................................................22
Gestione dei Meta-dati................................................................................................23
Generazione............................................................................................................23
Generazione Automatica:..................................................................................23
Completamento.............................................................................................23
Titolo:............................................................................................................23
Targhet, Tipo di Lezione Materia ed Argomenti...........................................23
Keywords......................................................................................................24
Tipo di applicazione......................................................................................24
Inserimento.................................................................................................................24
Licenza:...........................................................................................................................24
Licenza pubblica:........................................................................................................25
Licenza Privata:..........................................................................................................26
Ricerca:............................................................................................................................27
Ricerca Semplice:.......................................................................................................27
Approfondimento distanza di Levenshtein............................................................27
Ricerca Avanzata.........................................................................................................28
Search Options.......................................................................................................28
Funzionamento Software Distribuito...............................................................................28
Livelli di astrazione:...................................................................................................29
Possibile altra implementazione: Centralizzazione....................................................29
Interfaccia Web................................................................................................................30
Framework:.................................................................................................................30
JSF:.........................................................................................................................30
Framework per Ajax...............................................................................................32
IceFaces.............................................................................................................32
Registrazione:.........................................................................................................33
Login......................................................................................................................34
Pannello Utente......................................................................................................34
Aggiunta di un nuovo Learning Object:.................................................................34
I tuoi dati................................................................................................................36
Ricerca....................................................................................................................37
Risultati di una ricerca / I tuoi Learning Object.....................................................37
Dettagli di un Learning Object...............................................................................38
Integrazione Facebook................................................................................................38
Like Button:...........................................................................................................38
Comments:.............................................................................................................39
Rilevanza sociale...............................................................................................39
Distribuzione:....................................................................................................39
Launcher..........................................................................................................................39
Embedded Glassfish:..................................................................................................39
Avvio di SamgI e del Repository................................................................................40
Conclusioni......................................................................................................................41
Bibliografia......................................................................................................................41
Indice Analitico................................................................................................................42
INTRODUZIONE
Questa tesi nasce nell'ambito di un grande progetto che la Provincia Autonoma di Trento
sta sviluppando con lo scopo di innovare la didattica nelle scuole attraverso
l'introduzione di nuove tecnologie a supporto dei docenti e degli studenti.
Una parte di questo progetto, supportato dall'Università degli Studi di Trento riguarda la
diffusione di numerose Lavagne Interattive Multimediali (LIM) nella varie scuole
Trentine: SLIM4DIDA (Supporto all'introduzione di Lavagne Interattive Multimediali
per (4) la Didattica) è stato il progetto pilota, il quale sta continuando tuttora con il
progetto Wii4Dida.
Una LIM è un dispositivo elettronico ideato e realizzato per sostituire la tradizionale
lavagna didattica, sulla quale è possibile disegnare attraverso dei pennarelli virtuali o
con il metodo touch screen. Tipicamente questa lavagna è collegata ad un Pc
permettendo di unire il classico paradigma didattico incentrato sulla lavagna, con
l'integrazione di contenuti multimediali dinamici, quali software sviluppati ad Hoc per
facilitare e migliorare l'insegnamento.
Le possbilità offerte da una LIM rispetto ad una lavagna tradizionale sono enormi infatti
introdurre una lavagna interattiva in aula equivale ad "aprire" la classe al digitale;
significa, in qualche misura, invertire il senso di marcia della tecnologia. Non sono più
infatti gli allievi ad essere "portati" in sala per la classica "ora di informatica", ma è il
multimediale ad entrare in classe e a rendersi immagine, video, web, risorse interattive.
Mantenendo il classico paradigma centrato sulla lavagna e utilizzando metodi
tradizionali d’insegnamento come la lezione frontale, il docente potenzia la possibilità
d’utilizzare software didattico in modo condiviso, la propria attività; facilita la
spiegazione dei processi, la descrizione di situazioni e ambienti, l’analisi di testi.
Tutto ciò consentendo una visualizzazione diretta e condivisa dell’oggetto su cui è
convogliata tutta l’attenzione degli allievi, avendo anche la possibilità di salvare i
percorsi didattici proposti, per successivi utilizzi o per la distribuzione agli studenti
(inclusi quelli assenti).
Oltre che per la didattica frontale, la lavagna interattiva può essere impiegata in aula
per lezioni di tipo interattivo/dimostrativo: per condurre dunque attività collaborative
e laboratoriali, per svolgere le interrogazioni, per la navigazione e ricerca su web, per
presentare in modo innovativo studi ed elaborati realizzati dagli studenti.
Molti insegnanti hanno parlato di elevati indici di gradimento e di coinvolgimento
degli allievi.
E fra i "perché" hanno in particolare indicato la "proprietà" della LIM di allinearsi al
linguaggio, delle immagini, dei filmati, della fruizione interattiva, cui le nuove
generazioni e i loro stili d’apprendimento sono ormai abituate
Proprio tutti i possibili contenuti ( detti Learning Object ) sono stati il punto di partenza
di questa tesi in quanto la realizzazione di lezioni passa attraverso una fase di creazione
e sviluppo delle stesse. Ma anche di ricerca e di riutilizzo di quanto già creato, dato che
uno dei punti di maggiore forza degli strumenti elettronici per supportare la didattica è
proprio la possibilità di riutilizzare materiale, facilitando e velocizzando la preparazione
delle lezioni.
L'obiettivo di questo progetto è quindi realizzare un sistema che permetta lo scambio e
la ricerca di contenuti didattici, in particolar modo per lavagne interattive. Attraverso la
realizzazione di un repository che sia disponibile e accessibile ai docenti che desiderino
utilizzare contenuti per Lavagne Multimediali. Questo Repository è stato pensato per
essere installato su un server di una scuola, ma che abbia la possibilità di scambiare dati
con i repository installati sulle altre scuole, realizzando cosi un sistema distribuito per lo
scambio dei LO.
Questa tesi si suddivide in più parti principali: nella prima parte inquadreremo a fondo
l’ambiente in cui questa si sviluppa, analizzando gli obiettivi di questo progetto e
confrontandolo con quanto è stato già stato creato nel resto del mondo per risolvere il
medesimo problema.
La seconda parte parla dei metadati, cioè di come classificare e indicizzare i vari
Learning Objects, i metodi da me utilizzati comprendenti vantaggi e svantaggi del mio
approccio.
Nella terza parte iniziamo a parlare della realizzazione di questo progetto, descrivendo
le scelte architetturali prese, le tecnologie utilizzate e le basi del funzionamento di
questo progetto approfondendone tutti i punti fondamentali discutendone le scelte prese.
La quarta parte riguarda l'interfaccia utente, l'utilizzo e l'installazione del repository.
Comprende degli approfondimenti su alcune tematiche della programmazione di
applicazioni Web 2.0 e sulle tecnologie adottate per lo sviluppo dell’interfaccia utente.
Cos'è un Learning Object
Iniziamo a definire che cosa è un Learning Object. Un LO è definito come ogni risorsa
digitale utile a supportare l'apprendimento, cioè una mattonella di base per e-learning e
può essere qualsiasi cosa, come un file pdf, un documento, un’immagine, un file video o
audio, la cosa importante è che il contenuto abbia lo scopo di insegnare qualche cosa.
Le caratteristiche principali di un Learning Object sono:
Modulari: cioè posso essere aggregati e usati assieme ad altro LO.
Riusabili: significa che una risorsa può essere utilizzata infinite volte, anche in
ambienti e situazioni di apprendimento diverse.
Reperibili: cioè ricercabili e classificabili attraverso una fase di generazioni di
metadati.
Che cosa sono i metadati?
I metadati sono delle informazioni associate a un LO, ma che non si riferiscono
direttamente al contenuto ma hanno lo scopo di classificarlo e di raggrupparlo in
categorie assieme ad altri LO, Ad esempio contengono informazioni riguardo al titolo,
ma anche alla materia di cui si occupano, sul livello di difficoltà e di conoscenze
richieste per comprenderne il contenuto e cosi via.
Esistono degli standard internazionali per il formato dei metadati, quali ad esempio
Dublin Core o lo stand ieee LOM (Learning Object Metadata). Nel repository tutti i LO
inseriti saranno classificati e indicizzati attraverso un documento LOM.
Learning Object Metadata (LOM)
Per approfondire LOM è lo standard approvato dall'IEEE nel giugno 2002 e fissa il
minimo insieme di proprietà necessario per la gestione, l'allocazione e la valutazione dei
Learning Object.
LOM è nato con lo scopo di dare coerenza e di fornire uno standard internazionale in
modo che tutti i gestori di meta-dati abbiano un riferimento, potendo cosi condividere
informazioni fra loro.
Le radici di questo standard affondano in ARIADNE (Alliance of Remote
Instructional Authoring and Distribution Networks for Europe) associazione la
quale si occupa di indicizzare Learning Object già dalla meta degli anni 90 e punto di
riferimento internazionale per la generazione, gestione e soprattutto lo scambio di metadati fra i vari LO.
LOM composto di nove aree descrittive, contenenti gruppi di attributi strutturati ad
albero:
• Generale: racchiude le informazioni comuni sul Learning Object;
• Ciclo di vita: racchiude le informazioni sulla vita del LO (versione, data di creazione,
ecc.);
• Meta-metadati: fornisce informazioni sullo schema di meta-dati adottato;
• Tecnico: contiene informazioni sui requisiti e le caratteristiche tecniche del LO;
• Didattico: racchiude informazioni sulle proprietà didattiche del LO;
• Diritti: fornisce informazioni sui diritti intellettuali e simili del LO;
• Relazioni: contiene indicazioni sul legame tra l'oggetto e altre risorse;
• Annotazioni: contiene commenti sull'uso didattico del LO;
• Classificazioni: fornisce informazioni sulla materia e l'argomento affrontati
In totale questi nove gruppi racchiudono settanta elementi descrittivi.
Queste informazioni se correttamente compilate permettono di classificare in modo
completo una risorsa, e ne permettono cosi delle efficacie ricerche dello stesso.
Implementazione di LOM
I meta-dati sono rappresentati attraverso un nodo xml ben definito nelle specifiche ieee.
Un semplice esempio di un possibile meta-dato è il seguente:
<lom xmlns="http://ltsc.ieee.org/xsd/LOMv1p0">
<general>
<title>
<string xml:lang="sp">Julio Cesar</string>
<string xml:lang="it">Giulio Cesare</string>
</title>
<language>la</language>
</general>
<technical>
<location type="URI">
http://RepositoryDiLezioni/RepositoryGUI/UploadedLO/matteo/cesare.html
</location>
</technical>
</lom>
Ovviamente questo è un meta-dato molto incompleto dato che sono specificati
solamente 3 dei 70 elementi descrittivi possibili ma è un buon esempio per capire com'è
strutturato.
Per elaborare queste informazioni nell'ambiente Java ho trovato delle api LOM4J scritte
per fornire una semplice interfaccia per il formato LOM. Queste api sono usate anche
negli altri repository come Ariadne e si basano su JAXB unito a un supporto per la
gestione delle VCARD.
JaxB
JAXB è un parser XML che utilizza un approccio completamente differente rispetto a
SAX o Dom. Infatti, le API jaxb creano dei veri e propri oggetti Java a partire dalla
definizione del file XML, definizione che viene di solito fatta usando DTD o XML
Schema. Da queste definizioni sono create dinamicamente delle classi Java che poi
conterranno i dati riportati nel file XML.
Come potete vedere dall'immagine qui riportata il funzionamento è abbastanza
semplice: sono creati degli oggetti dalla definizione del file XML. Quest’approccio è
utilissimo perché rende invisibile al programmatore la presenza del file xml.
Si lavora semplicemente con degli oggetti java senza doversi preoccupare di
problematiche di parsing o di navigazioni fra nodi.
VCARD
è un formato di file per i biglietti da visita elettronici. I vCard possono essere allegati a
messaggi email, ma possono essere scambiati anche in altri modi, generalmente su
internet o tra due o più dispositivi mobili. Possono contenere informazioni come nome,
cognome, indirizzo, numeri di telefono, email, url, compleanno, immagini e perfino clip
audio. Queste vCard sono utilizzate nel documento LOM per identificare l'autore
dell'oggetto.
Esempio di file vCard
BEGIN:VCARD
VERSION:2.1
N:Matteo
NICKNAME:Matteogrf
TEL;HOME;VOICE:123456789
TEL;CELL;VOICE:123456789
TEL;HOME;FAX:123456789
ADR;HOME:;;Strada del Redebus 24 00100=0D=0AItalia
EMAIL;PREF;INTERNET:[email protected]
REV:20080817T172534Z
END:VCARD
Caratteristiche di un buon repository
Un repository per aver successo ed essere ben funzionante deve soddisfare
generalmente una serie di requisiti fondamentali, i quali oltre definire di direttive di
funzionamento devono comprendere argomenti quali la semplicità di utilizzo e
l'efficienza operativa. Poiché un sito web oltre ad essere funzionale, deve anche essere
semplice e veloce, è cosa nota che una grande complessità di utilizzo allontana molti
utenti, quindi:
•
Deve essere semplice e rapido, alcuni repository richiedono moltissime
informazioni per la creazione dei metadati, annoiando l'utente facendogli
compilare moltissimi campi e form, questo è un problema che scoraggia
l'inserimento di nuovi contenuti e perfino l'utilizzo.
•
La ricerca deve essere semplice e intuitiva, permettendo di trovare ciò che si
cerca con pochi click e poche azioni, infatti, una cattiva ricerca rende inutile un
repository
•
Deve essere disponibile un meccanismo di protezione dei contenuti,
permettendo all'utente di scegliere con chi condividere il proprio lavoro.
•
L'installazione deve essere semplice, ed eseguibile da un qualunque utente che
non possiede specifiche conoscenze informatiche, in tal modo questo repository
può essere installato su molti server permettendone una gran diffusione.
•
La gestione degli utenti deve essere sviluppata nel modo più semplice possibile,
chiedendo all'utente solamente le minime informazioni necessarie. E dimostrato
che più informazioni sono richieste, meno utenti decideranno di registrarsi e di
contribuire.
Il mio obiettivo è quindi realizzare un pacchetto software completo che sia funzionale e
utile per soddisfare nel miglior modo possibile questi requisiti.
Ora vorrei porre l'attenzione su cosa esiste già e su com’è stato realizzato.
Repositori già esistenti:
Esistono già molti repository per lo scambio dei LO, i quali fra loro presentano rilevanti
differenze che ne influenzano l'usabilità e l'utilità. Per esempio alcuni sono aperti e altri
invece sono chiusi a gruppi di utenti ben definiti, come membri di un’associazione o
università. Alcuni possono essere pensati per argomenti o materie ben definiti, altri son
più generali, in ogni modo la struttura base resta sempre la stessa.
Ho analizzato i repository di maggiore fama:
Merlot:
Merlot è un repository nato nel 1997 in California, è complemento aperto a tutti gli
utenti e al momento indicizza oltre 25.000 LO.
Analizzandone la struttura d’inserimento e ricerca è ipotizzabile che si basi su un
formato LOM per la descrizione dei contenuti.
Utilizzandolo si nota che durante la fase di registrazione cerca di avere la maggior
quantità possibile d’informazioni sull'ambito educativo dell'utente, richiedendo di
compilare numerosi form con menu a tendina, con la possibilità si scegliere elementi già
definiti. Le principali informazioni richieste sono l'ambito d’insegnamento, la materia e
il livello d’insegnamento.
In seguito, le informazioni raccolte saranno utilizzate per velocizzare la generazione dei
Metadati inserendo opportuni valori di default dei vari menu.
Quest’approccio è lo stesso che avevo pensato per il mio repository, rendendo pero
l'inserimento delle informazioni aggiuntive opzionale in modo da non rallentare e
scoraggiare la registrazione.
Il sistema d’inserimento delle risorse è simile alla registrazione, cioè una volta deciso di
inserire un LO si dovranno compilare numerosi form con menu a scelta rapida, per
descrivere nel modo più completo possibile la risorsa che si sta inserendo.
Il sistema utilizza una classificazione Materia – Argomenti, i quali selezionabili ma non
modificabili.
Fa anche una distinzione sui vari scopi del LO, quali lezioni, esercizi, esame, prova,
corso on-line.
Simulazione ecc...
Gli step per la descrizione sono i seguenti:
Titolo e URL
Descrizione
Categoria
Autore
Informazioni Opzionali (Copyright e informazioni Tecniche)
Interessante la possibilità di creare delle Collection, cioè un raggruppamento di LO che
servono per raggruppare in modo completo una lezione composta di più Learning
Objects. Esprimendo il concetto di Modularità di un LO.
La ricerca è molto strutturata, e comprende la possibilità di specificare tutti i possibili
dettagli di un filtro.
A mio parere è un ottimo repository, dal quale potrei prendere molti spunti, il difetto dal
mio punto di vista è l'utilizzo può diventare lento e noioso data la presenza di numerosi
campi nelle form.
Le Mill
Si tratta di uno dei più famosi repository di metadati e utilizza un approccio
completamente diverso da merlot: chiede sempre il minimo possibile, favorendo la
rapidità e la semplicità a discapito della completezza e della precisione nella
classificazione.
La registrazione è molto semplice e non richiede nessuna informazione aggiuntiva
rispetto ai dati base di un utente.
Provando a inserire un nuovo LO notiamo che il repository non permette un upload
locale della risorsa, ma accetta solamente un collegamento a essa.
Le informazioni necessarie per la creazione dei metadati comprendono Titolo, Autore
Descrizione e Parole chiave, poi sono presenti menu a scelta rapida per Lingua materia
Argomento target e licenza.
È interessante la possibilità offerta da questo sito di creare lezioni con dei tool da loro
proposti.
Offre anche un sopporto multilingua e per la creazione di collection di lezioni.
A differenza di Merlot offre una gran semplicità e velocita di utilizzo che viene pero
pagata nel momento della ricerca poiché son presenti meno informazioni che descrivono
l'oggetto e quindi è più difficile trovare ciò che si cerca.
Connexion
Questo repository è completamente diverso rispetto ai precedenti, è molto più
sviluppato, poiché oltre alle funzionalità di Repository realizza un sistema sociale,
curando la figura dell'autore e delle relazioni fra essi, con possibilità di recensione e
controllo dei contenuti.
Si occupa anche della creazione di contenuti, fornendo tool per la creazione e per
l'esportazione nel formato standard proprietario del sito.
Legate all'account utente ci sono funzionalità per il supporto e la gestione dei contenuti,
una cartella personale per i propri lavori e numerosi strumenti di personalizzazione a
essa associati.
Le risorse sono suddivise in moduli che possono essere composti di singoli Learning
Objects o raggruppamenti. Esistono anche le Colleciton di moduli, che rappresentano un
percorso formativo più completo.
Registrandoci si nota una procedura identica a Le Mill.
La creazione dei metadati è gestita nello stesso modo degli altri repository analizzati.
In conclusione possiamo considerare questo tipo di repository anche come un social
network che collega i docenti fra loro.
Ariadne
Ariadne è un’associazione europea aperta al mondo, per la condivisione e il riutilizzo di
Learning Object. Il cui cuore è una rete distribuita di repository i quali scambiano
informazioni fra loro.
E membro di globe, un sistema mondiale per lo scambio di Learning Object, di cui
fanno parte tutti i maggiori repository internazionali di metadati. Questo fa si che
indicizzi un numero immenso di risorse (quasi un milione) molto diverse fra loro,
provenienti da repository molto diversi. Questo porta a repository a lavorare a un livello
di astrazione altissimo il che crea solamente un caos generale che rende impossibile
trovare qualsiasi cosa si voglia cercare. Anche a causa alle poche possibilità di scelta.
Per l'indicizzazione si basa sul Generatore SamgI (sarà spiegato più avanti nel
dettaglio) il quale lavora ad un livello di astrazione alto, non permettendo cosi
ricerche riguardanti materie, argomenti e dettagli specifici molto importanti in un
Learning Object.
Come si può notare tutti questi repository presentano sia dei pregi sia dei difetti, non ho
trovato ancora un repository per cosi dire perfetto da poter prendere come esempio, ma
mi forniscono grandi spunti per l'implementazione del mio progetto, che ovviamente
non intende, essere migliore dei repository già citati, ma ho fatto del mio meglio per
renderlo il più funzionale e usabile possibile.
Ho portato questi 4 repository come esempio perché rappresentano tutti i possibili
approcci seguibili, difatti molti degli altri repository esistenti sono realizzati sono molti
simili a quelli presentati.
Analizzandone vantaggi e svantaggi possiamo affermare che esiste una regola che dice
che più informazioni si richiedono più la ricerca e la classificazione sarà precisa, ma più
noioso e difficile sarà il repository da utilizzare.
Per la creazione del mio repository cercherò quindi di trovare un giusto bilanciamento,
cercando di prendere il meglio da ogni repository analizzato.
Generazione dei Metadati per Learning Object
In questo capitolo parleremo di come il repository genererà i metadati associati a ogni
Learning Object, e discuteremo dei valori più importanti da considerare per una buona
classificazione.
Questo è necessario perché ogni Learning Object necessità d’informazioni (meta-dati)
in modo da poterlo classificare e inserire nell’ambiente cui esso appartiene. Ad esempio
data una presentazione multimediale è necessario conoscere chi l’ha creata, di che
argomento tratta, chi è il target di questa presentazione ecc... tutte queste informazione
sono i meta-dati associati all'oggetto.
La procedura per la loro generazione ha i seguenti requisiti per essere efficiente ed
efficace:
•
Deve generare meta-dati corretti e il più possibile completi e consoni per una
corretta ricerca.
•
Non deve causare all'utente uno spreco di tempo. Com’è noto a nessun utente
piace perdere tempo a inserire manualmente i meta-dati In quanti si tratta di una
procedura noiosa.
Per far questo ho scelto di utilizzare il tool SamgI di Ariadne, un generatore automatico
di meta-dati il quale dato un file in input cerca di estrarre la maggior quantità
d’informazioni possibili.
Presentano pero i seguenti problemi:
1. Non tutti i formati sono supportati
2. Presenta qualche errore di estrazione
3. Mancanza di alcune informazioni
Questa mi porta ad adottare un approccio misto, che riesca a fondere la generazione
automatica con un supporto manuale, in modo da richiedere poco tempo all'utente e di
porre rimedio ai limiti della generazione automatica. L'idea base di questo approccio è
di creare una generazione assistita di meta-dati
In pratica cercherò di affidare all'utente solo una funzione di controllo della correttezza
dei meta-dati generati, e nel caso di errori o d’impossibilità di generare
automaticamente alcune informazioni di primaria importanza cercherò di mettere
l'utente nelle condizioni di inserire questi dati nel modo più semplice veloce ad
automatico possibile, supportandolo con suggerimenti, menu a scelta rapida e cosi via.
Esistono dei formati standard per la creazione di questi meta-dati, io ho scelto di seguire
il formato LOM (Learning Object Metadata) giacché è il meglio supportato da SamgI e
a mio parere il più completo e specifico per le necessità del mio progetto.
Tipo Oggetto:
Questa informazione descrive di che tipo di oggetto si tratta. Ad esempio:
Presentazione, Pdf, Immagine, Ecc... questo metadato può essere estratto in modo
automatico in base all'estensione del file. Nel caso di estensioni sconosciute o di file
applicativi verrà chiesto all'utente di inserire manualmente questo campo. Per rendere
questo più efficiente l'applicazione sarà capace di imparare nuove estensioni quando un
oggetto sconosciuto sarà descritto.
Ci sono situazioni, come ad esempio documenti html generati da una servlet che sono
disponibili sul web senza estensione. Queste situazioni sono gestite analizzando l'url e
riconoscendo le servlet.
Materia:
Estrarre la materia in modo automatico non è semplice, e il generatore automatico non
mi aiuta molto, pero per cercare di individuarla si può procedere nelle seguenti
direzioni:
A)
In base alle informazioni sull'autore: per esempio se abbiamo altri oggetti con lo
stesso autore, i quali riguardano tutti lezioni di storia, è consono ipotizzare che si tratti
anche questa di una lezione di storia.
B)
In base alle informazioni su chi inserisce tale oggetto: per esempio se chi
inserisce quest’oggetto, è un professore di matematica si può ipotizzare che si tratti di
una lezione di matematica, oppure se l'utente in precedenza ha inserito lezioni di storia,
potrebbe trattarsi di una lezione di storia.
C)
Cercando nel titolo, parole chiavi e descrizione: in queste parti del testo in alcuni
casi è possibile trovare informazioni che riguardano le materie.
Ovviamente se questo porta a un risultato errato, è compito dell'utente correggerlo
cambiando la materia o aggiungendone una nuova.
Argomento:
si tratta di un punto specifico della materia, il quale potrebbe essere anche condiviso fra
più materie, ad esempio un personaggio storico presente sia in letteratura sia in storia
dell'arte.
Per ricavare questa informazione è necessario un approccio simile a quello per la
materia.
Target:
A chi è rivolta la lezione: studenti di scuola elementare, medie, superiore ecc...
Per completare questo metadato è possibile inserire un menu a scelta rapida con le varie
opportunità, inizializzato col valore suggerito, ricavato in base alle informazioni che si
hanno sull'autore dell'oggetto. I target potrebbero essere: Tutti, Asilo, Elementare,
Medio, Superiore, Università.
Keywords:
Parole chiave della lezione, sono estratte direttamente dal generatore, si potrebbe
chiedere all'utente un loro controllo di correttezza.
Per i dati di minor importanza lascerò solamente una generazione automatica,
poiché far perdere all'utente troppo tempo è più dannoso di qualche informazione
incompleta, giacché porterebbe l'utente a non inserire il Learning Object.
Organizzazione del Repository
Architettura
In questo capitolo parleremo di com’è stato costruito il repository, analizzando le varie
parti che lo compongono e approfondendo le tecnologie con le quali è stato
implementato.
Per prima cosa è necessario spiegare che il repository è stato realizzato come
un’applicazione stand-alone, cioè viene eseguito come un normale programma, questo
per dare una grande semplicità e facilità d’installazione.
Cosi facendo hanno la massima flessibilità: potrà essere cosi installato su un server di
una scuola, su un computer locale di un docente o anche su un server in internet.
E comunque possibile, per chi volesse, eseguire il respository in un normale web
container.
Analizzando l'applicazione possiamo affermare che è composta di 5 parti principali:
Core:
Si occupa di gestire tutte le richieste e le operazioni, interagendo con le altre parti.
Metadata Generator: E il motore SamgI per la generazione automatica dei metadati
XML Database: Database nel quale sono memorizzati i metadati, in formato XML
secondo lo standard LOM.
SQL Database: Database nel quale sono memorizzate in modo relazionale le
informazioni sugli utenti e su quanto gestito dal respository.
Interfaccia Web: interfaccia realizzata attraverso un sito web per interagire col
repository.
Il core e SamgI sono delle web application e devono essere eseguite in un Web
Container, per questo ho scelto di utilizzare Embedded Glassfish, non richiedendo
all'utente finale l'installazione e la conoscenza di un Web Server.
Lo schema che rappresenta come queste parti interagiscono fra loro e come il tutto è
strutturato è il seguente:
Approfondiamo le parti fondamentali:
Core
Nel core si concentra la logica di funzionamento del repository stesso, e fornisce tutti i
vari servizi e operazioni che sono necessarie nel repository.
Le operazioni fondamentali sono:
•
Gestione degli Utenti
•
Gestione dei Metadati
•
Ricerca
•
Suggerimenti per il completamento dei metadati
•
Scambio di dati con gli altri repository.
Tutto è realizzato in java, e in modo specifico tramite l'utilizzo degli EJB, e ad alto
livello ogni parte fondamentali è in generale organizzata su uno schema a 3 livelli in
modo da ottenere un buon livello di astrazione fra logica di funzionamento e
implementazione:
Al livello superiore c'è per ogni servizio fondamentale un Bean che fornisce l'interfaccia
di funzionamento, la quale ha lo scopo di essere utilizzata direttamente dall'applicazione
web.
Questi Bean per la maggior parte delle operazioni si appoggiano su altri EJB che
forniscono le interfacce per l'accesso e la modifica dei dati, i quali a loro volta
utilizzano degli Entity Bean per l'accesso diretto ai dati, oppure a classi che nello stesso
modo ne forniscono un’interfaccia, come il gestore del database XML e di SamgI.
In pratica l'applicazione è stata realizzata seguendo e utilizzando il semplice pattern
chiamato Facade che letteralmente significa "facciata" e indica un oggetto che permette,
attraverso un'interfaccia più semplice, l'accesso a sottosistemi che espongono interfacce
complesse e molto diverse tra loro, nonché a blocchi di codice complessi.
Prima di addentrarci nel particolare di ogni servizio approfondiamo le tecnologie scelte
e utilizzate nella creazione del repository:
Tecnologie Utilizzate
EJB
Gli Enterprise Java Bean (EJB) sono i componenti che implementano, lato server, la
logica di business all'interno dell'architettura Java EE. Nel mio caso realizzano il core
del repository, cioè il nucleo, ho scelto questa tecnologia perché fornisce
automaticamente molte caratteristiche utili a una veloce e solida implementazione, tra
cui la persistenza, il supporto alle transazioni, la gestione della concorrenza e della
sicurezza l'integrazione con altre tecnologie, come i Web Services. Lo standard attuale è
EJB 3.
Inoltre è una tecnologia ideale per il mio progetto poiché le specifiche EJB intendono
fornire una metodologia standard per implementare la logica di funzionamento delle
applicazioni di tipo enterprise, cioè che forniscono servizi via internet. Per realizzare
applicazioni di questo tipo è necessario affrontare una serie di problematiche tecniche
che possono rivelarsi molto complesse e laboriose da risolvere. Alle quali gli EJB
intendono fornire una soluzione a questi problemi in modo da semplificare lo sviluppo
di questo tipo di applicazioni.
Le specifiche EJB descrivono in dettaglio come realizzare un’applicazione server che
fornisca le seguenti funzionalità:
Persistenza
•
•
Elaborazione delle transazioni
•
Controllo della concorrenzialità
•
Servizio di directory per elencare e nominare gli EJB (JNDI)
•
Sicurezza
•
Installazione di componenti software in un application server
•
Invocazione di procedure remote tramite l'utilizzo di CORBA
•
Fornire servizi Web
Non tutte queste funzionalità sono utilizzate nel mio core, ad esempio l'unita che si
occupa della persistenza è utilizzata per il salvataggio dei dati riguardanti gli utenti, ma
anche per le materie e gli argomenti, cosi come per tutti gli altri dati che hanno bisogno
di essere salvati: ad esempio i possibili livelli di difficoltà di una lezione o i tipi di
applicazione che SamgI può gestire e analizzare. Non ho bisogno di JMS o di CORBA,
pure le transazioni e la concorrenzialità non sono molto importanti in questo progetto,
poiché non si tratta di operazioni critiche nelle quali un errore di questo genere può
causare seri problemi.
Invece utilizzo i Servizi Web per realizzare un software distribuito, e anche JNDI per
richiamare gli EJB dall'interfaccia Web.
Esistono tre tipi di EJB:
EJB di Entità (Entity EJB): il loro scopo è di inglobare gli oggetti sul lato server
•
che memorizzano i dati. Gli Entity Bean forniscono la caratteristica della persistenza.
Sono usati nel core per rappresentare gli utenti, le materie, gli argomenti e salvare i loro
dati in modo persistente su un DB.
•
EJB di sessione (Session EJB): gestiscono l'elaborazione delle informazioni sul
server. Generalmente sono un’interfaccia tra i client e i servizi offerti dagli
elementi disponibili sul server. Ne esistono di due tipi:
Con stato (stateful). I Bean di sessione con stato sono oggetti distribuiti che
•
possiedono uno stato. Lo stato non è persistente, però l'accesso al Bean è limitato a un
unico client. Questo tipo di Bean non è utilizzato pero nel mio progetto, poiché ho
preferito utilizzare solamente Bean stateless e gestirmi autonomamente le sessioni e lo
stato delle operazioni attraverso normali classi java, perché non richiedevo le
caratteristiche di un EJB, dato che sia la sessione sia le operazioni possibili sono
semplici e senza particolari problemi di concorrenza e di sicurezza.
•
Senza stato (stateless). I Bean di sessione senza stato sono oggetti distribuiti
senza uno stato associato, questa caratteristica permette un accesso
concorrente alle funzionalità offerte dal Bean. Non è garantito che il
contenuto delle variabili d’istanza si conservi tra diverse chiamate ai metodi
del Bean. Questo tipo di Bean è utilizzato per implementare tutte le
principali funzionalità offerte dal core, dalla gestione degli utenti alla ricerca.
•
EJB guidati da messaggi (Message driven EJB): sono gli unici Bean con
funzionamento asincrono. Tramite il Java Message Service (JMS), s’iscrivono a
un argomento (topic) o a una coda (queue) e si attivano alla ricezione di un
messaggio inviato all'argomento o alla coda cui sono iscritti. Non richiedono
un’istanziazione da parte dei client. Questi Bean non sono presenti nel
repository.
Per realizzare un software che sia distribuito, ho utilizzato dei Web Service Basati su
session Bean stateless che permettono alle varie istanze del repository di comunicare fra
loro attraverso internet.
Web Services
Un Web Service è un sistema software progettato per supportare l'interoperabilità fra
diversi elaboratori di una medesima rete. Caratteristica fondamentale di un Web Service
è di offrire un'interfaccia software (descritta in un formato automaticamente elaborabile
quale, ad esempio, il WSDL) utilizzabile da altri sistemi, nel mio caso un’altra istanza
del repository può interagire con il Web Service stesso attivando le operazioni descritte
nell'interfaccia tramite appositi "messaggi" inclusi in una "busta": tali messaggi sono,
trasportati sul protocollo HTTP, quindi viaggiano sulla porta 80, solitamente aperta in
tutti i router e le reti. Questo è stato uno dei motivi che mi hanno fatto preferire i Web
Service a sistemi operativo quali CORBA, i quali non lavorano attraverso la porta 80.
Tutti i messaggi fra i WS sono formattati nel formato XML. Quando mi si è presentata
la necessità di scambiare messaggi complessi fra i Web Service ho creato un Xschema
che definisse il formato corretto del messaggio scambiato e ne permettesse un miglior
parsing.
L'elenco dei vantaggi di un utilizzo dei Web Service è il seguente:
•
Sono indipendenti dalla piattaforma sulla quale sono eseguiti.
•
I protocolli sono open e in formato testuale, cosa che li rende di più facile
compressione e utilizzo.
•
Funzione mediante HTTP, non richiedendo modifiche alle regole del firewall.
•
Possono essere facilmente utilizzati in combinazione l'uno con l'altro per creare
servizi complessi.
Gli svantaggi sono principalmente legati a prestazioni generiche peggiori rispetto a RMI
e CORBA.
Database XML
Tutti i meta-dati, descritti nel formato LOM, sono contenuti in un file di tipo xml,
quindi il modo migliore e più semplice per effettuare operazioni su di essi, quali
modifiche, ricerche, inserimenti e cancellazioni è di gestirli attraverso un database
XML.
Io ho scelto di Utilizzare BaseX,
BaseX è un database gratuito, molto leggero e con ottime performance, il quale
implementa uno Xpath e Xquery processor molto avanzato, comprendendo tutte le
nuove specifiche W3C per l'update e specialmente per la ricerca full text all'interno dei
contenuti, parte fondamentale nella mia applicazione.
Schematizzando le caratteristiche di BaseX sono:
•
é un database XML completo di ottime prestazioni.
•
Offre un efficiente e completo supporto per Xpath Xquery.
•
Ha un’architettura client server con transazioni, logging e controllo della
sicurezza.
•
Offra numerosi API: REST/JAX-RX, XQJ, XML:DB.
•
E possibile integrarlo in un progetto attraverso la versione embedded.
Nel repository il database XML è stato integrato con la creazione di un piccolo software
che si occupa della sua installazione, avvio e gestione, la quale è richiamato al momento
dell'avvio del repository stesso. Il metodo di comunicazione fra il core e il Database si
basa attraverso le API JAX-RX, che in pratica sono un insieme di chiamate HTTP. Ogni
operazione richiesta al database dipende dal tipo di richiesta HTTP effettuata:
Per spiegare meglio questo funzionamento supponiamo che il Database sia attivo ed in
ascolto all'indirizzo http://localhost:8984/jax-rx/repositoryDB/: ogni richiesta inviata a
questo indirizzo web locale sarà una operazione effettuata sul database.
Metodo GET:
A richieste di tipo GET sono associate delle query Xpath oppure Xquery la quali devono
essere inserite come parametro di nome “query”.
Ad esempio la query: http://localhost:8984/jax-rx/repositoryDB?query=//LOM/*.
Ritornerà tutti i nodi di nome LOM presenti all'interno del database repositoryDB.
Questo metodo per eseguire le query però è disordinato e scomodo specialmente se si
utilizza Xquery, mentre è molto semplice se si utilizza Xpath. Fortunatamente anche il
metodo post permette di inviare query al database.
Metodo POST:
Attraverso il metodo POST è possibile eseguire 2 tipi di operazioni distinte sul
database: inviare query o comandi.
Per inserire una query si dovrà inserire nel corpo del messaggio un testo XML nella
seguente forma:
Ritorna 5 titoli dei LO presenti nel database.
<query xmlns="http://jax-rx.sourceforge.net">
<text>for $l in //LOM return $l/title</text>
<parameter name="count" value="5"/>
<parameter name="output" value="indent=no"/>
</query>
Questo modo per scrivere risulta, a mio parare più ordinato e comprensibile. Nello
stesso modo è possibile inviare comandi al database. Esempio:
<command xmlns="http://jax-rx.sourceforge.net">
<text>show users</text>
<parameter name="wrap" value="no"/>
</command>
Questo comando mostra tutti gli utenti del database.
Metodo PUT:
Tramite questo metodo si può creare un nuovo database o aggiungere elementi a esso.
Ad esempio per creare un nuovo database di nome Test basterà inviare una richiesta di
tipo PUT all'url http://localhost:8984/jax-rx/Test.
Se invece si volesse aggiungere un documento XML al database, è necessario inviare
una richiesta alla stessa URL, con il documento XML contenuto nel body della
richiesta.
Nello stesso modo, attraverso il metodo DELETE si compie l'operazione inversa.
L'update dei dati si effettua attraverso il metodo POST e un’operazione Xquery Update.
Utilizzo del Database XML nel Core:
Per effettuare tutte queste operazioni ho scritto un Enterprise Bean di tipo singleton che
si occupa di gestire la comunicazione e tutte le operazioni da e per il database, fornendo
una semplice interfaccia per le operazioni descritte in precedenza, in modo tale da poter
effettuare insert, delete, e query senza conoscere nulla del database.
Database Relazionale
Per mantenere le informazioni riguardanti gli utenti, e le altre informazioni che devo
essere memorizzate dall'applicazione ho scelto di utilizzare un database relazionale.
Dopo aver preso in considerazioni i più comuni database quali MySQL, Postgree ecc.,
la mia scelta è ricaduta su Apache Derby, detto anche Java DB, per il fatto di essere
molto leggero e già integrato in java. In questo il server ospitante il repository non deve
preoccuparsi di installare e configurare il database. Lo svantaggio è che Derby non ha le
performances degli altri database ma dato che la mole di dati che deve gestire non è di
grandezza critica questo non è un problema. Inoltre il tipo di database è completamente
separato dall'implementazione del core attraverso una persistence unit. Modificando la
Persistence Unit è possibile cambiare a piacimento il database senza dover modificare
minimamente il codice sorgente del core.
Questo è lo schema delle tabelle presenti nel database.
NextMetadataID: questa semplicissima tabella possiede solo una riga contenente l'id
da assegnare al prossimo LO che verrà inserito, in quanto il database XML non ha un
sistema di gestione automatico degli id, ed è necessario garantire che ogni LOM inserito
nel database sia univoco.
Type: contiene tutti i possibili tipi MIME utilizzabili nel repository. Questa lista è
dinamica e potrebbe espandersi nel caso SamgI riconosca nuovi tipi di applicazioni non
ancora inseriti o utilizzati nel repository. È inizializzata con dei valori standard durante
la prima esecuzione del repository. Es: Pdf, doc, html e altri vari Mime Type.
Target: questa tabella, inizializzata alla prima esecuzione del repository, contiene tutti i
possibili target di una lezione. Ad esempio Elementare, Medie, Superiori ecc...
User: Contiene le informazioni riguardanti un utente registrato, con dei puntatori alla
materia preferita e al target preferito per le sue lezioni.
Subject e Topic: Sono tutte le materie che posso essere scelte nel repository con una
relazione N a N con i possibili argomenti di una materia.
Generatore di Metadati
Il generatore di metadati (AMG) è un software open source nato nel 2005 pensato per
indicizzare la notevole massa di oggetti educativi di cui Ariadne poteva disporre;
analizzandone il contenuto e creando dei metadati.
E stato realizzato da sotto la guida di Erik Duval professore e ricercatore presso
l'università cattolica di Lovanio (Belgio) nonché presidente di Ariadne e membro del
consiglio IEEE LTSC (Il gruppo che si occupa dei Learning Object Metadata).
Si può certamente considerare come una delle più importanti e influenti persone
dell'ambito dei Learning Object.
SamgI è completamente realizzato in Java ed è composto di una serie di piccoli
generatori interni che si occupano dei vari ambiti da analizzare. Si basa su Apache
Lucene per l'estrazione e la ricerca dell’informazione dai vari testi.
Estrattore:
Come prima cosa il generatore cerca di estrarre il testo dai vari documenti, quali doc,
pdf ecc... per questo sono stati realizzati degli estrattori i quali analizzando un generico
file ne estraggono il testo e le proprietà.
Generatori
Successivamente entrano in azioni i vari generatori di metadati tra i quali possiamo
citare un Generatore d’informazioni riguardanti il Mime, uno riguardante le Keyword,
Titolo, Descrizione e anche informazioni base come durata dimensione.
Nonostante funzioni in un modo discreto, presenta dei limiti, che non permettono una
descrizione accurata del metadato.
Non tutti i file sono supportati: da alcuni tipi di file è oggettivamente molto difficile
estrarre numerose informazioni, quali immagini, archivi e file eseguibili.
Se pensiamo a questi tipi di file, risulta impossibile estrarre informazioni significanti in
modo automatico, anche perché potrebbe essere presenti nel codice o magari non esserci
per niente.
Impossibilità di Estrarre Alcune informazioni: di vitale importanza per una buona
classificazione sono la materia e l'argomento, purtroppo queste informazioni molte volte
non sono nemmeno contenute nel file, inoltre in AMG non esiste un sistema che
definisca cosa è una materia e cosa è un argomento, per questo, queste informazioni,
come altre non posso essere generate automaticamente.
Errori di Estrazione: può anche succedere che a volte AMG estragga delle
informazioni che non sono realmente corrette, poiché credo si basi su metodi
probabilistici per definire alcune informazioni.
Complessivamente analizzando i vantaggi e i difetti di questo generatore posso
affermare che fornisce una buona descrizione globale dell'oggetto, la quale pero è
insufficiente quando si scende più nel dettaglio, il quale deve essere inserito
manualmente da un utente che conosce a fondo la risorsa.
Nel progetto il repository è eseguito come un’applicazione web che fornisce delle
servlet per l'analisi di Learning Object. Il core quindi esegue una connessione http
locale per comunicare col generatore. Questo è dovuto al fatto che la distribuzione più
stabile e meglio funzionante che ho trovato di SamgI era quella fornita tramite un file
war dai creatori stessi.
Il generatore è avviato subito prima del caricamento del repository sullo stesso server
web.
Funzionamento del Repository
Gestione degli Utenti
L'utente ha un ruolo centrale nel repository, e questo schema mostra ciò che un utente
può fare:
L'interfaccia per la gestione degli utenti è fornita dal Session Bean UserManager, il
quale mette a disposizione tutte le possibili operazioni quali login, log out,
registrazione, modifica dati ecc...
Le politiche adottate per la gestione e la sicurezza degli utenti sono le seguenti:
•
La registrazione richiede solamente nome utente, password e indirizzo email,
tutte le altre informazioni potranno essere inserite in seguito, cosi facendo si
permette una registrazione veloce e senza problemi.
•
Il nome utente è un dato univoco e permanente, una volta registrati non sarà più
possibile cambiare il proprio nome utente.
•
Le password è salvata in maniera criptato nel database, in tal modo nessuno può
conoscere la password di un altro utente nemmeno se ha accesso al database.
•
Al momento del login è creata una sessione per ogni utente la quale è gestita
internamente in modo molto leggero tramite una tabella degli utenti loggati.
•
Ogni volta che un utente esegue un’operazione, deve fornire l'id che le e stato
assegnato durante il login, questo id viene controllato e se non è corretto
l'operazione non è consentita.
I dati degli utenti sono salvati nel database e gestiti dal rispettivo Entity Bean User in
quale si occupa automaticamente della gestione della persistenza e della tabella.
Gestione dei Meta-dati
Questa parte riguarda principalmente la generazione di meta-dati, il salvataggio nel
database e la loro cancellazione.
Generazione
Quest’operazione è fondamentale nel repository e viene suddivisa in 3 distinte fasi le
quali hanno bisogno dell’interazione dell'utente:
Generazione Automatica:
In questa prima fase viene analizzato dal Generatore SamgI il Learning Object che
dovrà essere inserito nel repository, ottenendo cosi una prima “grezza” versione. La
quale è salvata in sessione in attesa di essere raffinata nella seconda fase.
Completamento
In questa seconda fase vengono arricchiti i meta-dati generati automaticamente,
attraverso un inserimento e modifica dei campi ritenuti più importanti quali: Titolo,
Parole Chiave, Materia e Argomenti, Tipo di File, Target, Licenza e tipo di lezione.
Per aiutare l'utente nella scelta e nel complemento sono forniti automaticamente dei
suggerimenti attraverso un apposito sistema implementato nel Suggest Bean il quale
fornisce, per ognuno dei principali campi da analizzare alcuni suggerimenti e aiuti:
Titolo:
Ho pensato che i possibili titoli che il Learning Object può avere si possono estrarre in 2
modi: Il primo e solitamente più corretto è il titolo che viene estratto dal generatore
analizzando il LO, ma non sempre è possibile, per questo, viene anche inserito come
suggerimento il nome del file, opportunamente formattato e ripulito dell'estensione.
Esempio: un file di nome La_dinastia_Carpentigia_di_Francia.pdf diverrà: La dinastia Carpentigia di
Francia
In molti casi quanto viene suggerito tramite questi 2 modi è corretto, negli altri casi sarà
compito dell'utente scrivere un titolo consono.
Targhet, Tipo di Lezione Materia ed Argomenti
Questi dati possono essere accomunati perché presentano circa le stesse problematiche e
caratteristiche e sono informazioni che non possono essere individuate in nessun modo
dal generatore automatico. Per questo i suggerimenti si compongono nel seguente
modo:
Dapprima viene suggerito il valore di default per l'utente, successivamente sono inseriti
gli altri valori, in base alla loro frequenza di utilizzo da parte dell'utente e in generale
negli altri meta-dati inseriti.
Per il tipo di lezione inoltre viene analizzata l'estensione e associata all'evento più
probabile, ad esempio se si tratta di un file di testo è probabile che la lezione sia una
lettura, se è un foglio elettronico potrebbe trattarsi di un’esercitazione, se è una
presentazione potrebbe essere una lezione per l'autoapprendimento o di un’esposizione
in classe e cosi via.
Keywords
Le keyword vengono estratte automaticamente dal generatore, per questo all'utente è
solamente chiesto di controllare quanto già estratto, dando la possibilità di inserirle o
cancellarle in modo di avere un controllo di qualità delle stesse.
Tipo di applicazione
Questa informazione è estratta dall'estensione del file, in ogni modo è stato necessario
valutare la possibilità che siano inseriti elementi con estensione sconosciuta al
repository,
per
questo
dapprima
viene
suggerito
il
tipo
(MIME)
rilevato
dall'applicazione, ma vengono anche resi disponibili altri formati per la scelta
dell'utente.
Casi particolari: esiste un caso particolare ed è dato da risorse che sono generate
dinamicamente da servlet web. Questa situazione è stata gestita identificando le servlet
e analizzando quanto sa esse generato.
Questi metodi per i suggerimenti possono sembrare molto grezzi ma questo è dovuto
principalmente al fatto che un LO può essere qualsiasi cosa, da un video a una
presentazione o a widget per sankore, questo porta a lavorare a un altissimo livello di
astrazione rispetto alla risorsa non avendo idea di che cosa si tratti.
Ovviamente se si trattasse di un repository per soli file Pdf, si potrebbe pensare di
analizzare il file e fornire suggerimenti molto più esatti e complessi.
Inserimento
L'inserimento consiste nell'aggiunta dei meta-dati nel database XML, associando a
ognuno di essi un id e un riferimento all'utente in modo da garantirne l'unicità.
In questa fase viene anche gestita l'URL alla risorsa con una distinzione fra risorse locali
e remote.
L'indirizzo alla risorsa locale varia se cambia l'indirizzo IP del repository. Ma una
risorsa deve essere sempre disponibile e utilizzabile, per questo ad ogni indirizzo locale
verrà associato un pattern il quale indica che ogni volta che viene richiesta quella risorsa
l'URL deve essere trasformato in un indirizzo che punta alla macchina locale. Per
risorse remote invece non può eseguita nessuna operazione e viene utilizzato l'URL
inserito durante la fase di generazione.
Licenza:
Ai Learning Object presenti nel repository posso essere assegnate 2 tipi di licenza
diversi:
Licenza pubblica:
Con questa licenza di tipo creative commons una risorsa diventa pubblica e aperta a tutti
e tutti gli utenti che vogliono utilizzarla devono seguire le seguenti direttive imposte
dalla licenza:
Si è liberi di:
•
Riprodurre
•
Distribuire
•
Comunicare al pubblico
•
Esporre in pubblico
•
Rappresentare
•
Eseguire e recitare quest'opera
•
Modificare quest'opera
Alle seguenti Condizioni:
•
Devi attribuire la paternità dell'opera nei modi indicati dall'autore o da chi
ti ha dato l'opera in licenza e in modo tale da non suggerire che essi avallino
te o il modo in cui tu usi l'opera.
•
Non puoi usare quest'opera per fini commerciali.
•
Se alteri o trasformi quest'opera, o se la usi per crearne un'altra, puoi
distribuire l'opera risultante solo con una licenza identica o equivalente a
questa.
Prendendo atto che:
•
E' possibile rinunciare a qualunque delle condizioni sopra descritte se ottieni
l'autorizzazione dal detentore dei diritti.
•
Nel caso in cui l'opera o qualunque delle sue componenti siano nel pubblico
dominio secondo la legge vigente, tale condizione non è in alcun modo
modificata dalla licenza.
La licenza non ha effetto sui seguenti diritti:
•
Le eccezioni, libere utilizzazioni e le altre utilizzazioni consentite dalla legge sul
diritto d'autore;
•
I diritti morali dell'autore
•
diritti che altre persone possono avere sia sull'opera stessa che su come l'opera
viene utilizzata, come il diritto all'immagine o alla tutela dei dati personali.
Licenza Privata:
Con questa licenza il Learning Object resta confinato all'interno del repository e
solamente gli utenti registrati a esso potranno accedervi e utilizzarla e si è liberi di:
•
Riprodurre
•
Comunicare al pubblico
•
Esporre in pubblico
•
Rappresentare
•
Eseguire e recitare quest'opera
•
Modificare quest'opera
Alle seguenti Condizioni:
•
L'opera, può essere utilizzata, esposta, eseguita solamente all'interno del
contesto nel quale il repository si riferisce, ad esempio se si tratta di un
repository di Learning Object per l'Università di Trento l'opera potrà essere
utilizzata solamente all'interno ditale università, e non ci potrà essere nessun
utilizzo al di fuori di tale contesto.
•
Devi attribuire la paternità dell'opera nei modi indicati dall'autore o da chi
ti ha dato l'opera in licenza e in modo tale da non suggerire che essi avallino
te o il modo in cui tu usi l'opera.
•
Non puoi usare quest'opera per fini commerciali.
•
Se alteri o trasformi quest'opera, o se la usi per crearne un'altra, puoi
distribuire l'opera risultante solo con una licenza identica o equivalente a
questa.
Prendendo atto che:
•
E' possibile rinunciare a qualunque delle condizioni sopra descritte se ottieni
l'autorizzazione dal detentore dei diritti.
•
Nel caso in cui l'opera o qualunque delle sue componenti siano nel pubblico
dominio secondo la legge vigente, tale condizione non è in alcun modo
modificata dalla licenza.
La licenza non ha effetto sui seguenti diritti:
•
Le eccezioni, libere utilizzazioni e le altre utilizzazioni consentite dalla legge sul
diritto d'autore;
•
I diritti morali dell'autore
•
diritti che altre persone possono avere sia sull'opera stessa che su come l'opera
viene utilizzata, come il diritto all'immagine o alla tutela dei dati personali.
Ricerca:
Sono stati implementati 2 tipi di ricerca: Semplice e Avanzata.
Ricerca Semplice:
Consiste nel ricercare i LO secondo una parola o un insieme di parole, e si basa su una
ricerca di tipo full text scegliendo quelli che contengono la parola ricercata. Per
aumentare la possibilità di successo la ricerca è di tipo fuzzy, questo significa che viene
fatta anche una ricerca approssimata della parola ricercata, in modo da essere flessibile a
errori di scrittura da parte dell'utente, o a parole che potrebbero essere scritte al plurale
invece che al singolare ecc.
Questa ricerca approssimata è basata sulla distanza di Levenshtein, dove il massimo
numero di errori permessi in una stringa è calcolato dividendo la lunghezza della stringa
per 4, preservando pero un minimo di 1.
L'ordinamento di questi risultati tiene conto di quante volte la parola ricercata compare
all'interno del meta-dato.
Approfondimento distanza di Levenshtein
La distanza di Levenshtein, o distanza di edit, è una misura per la differenza fra due
stringhe. Introdotta dallo scienziato russo Vladimir Levenshtein nel 1965, serve a
determinare quanto due stringhe siano simili.
La distanza tra due stringhe A e B è il numero minimo di modifiche elementari che
consentono di trasformare la A nella B. Per modifica elementare s’intende
La cancellazione di un carattere,
•
•
La sostituzione di un carattere con un altro
•
L'inserimento di un carattere.
Per esempio, per trasformare "bar" in "biro" occorrono due modifiche:
1.
"bar" -> "bir" (sostituzione di 'a' con 'i')
2. "bir" -> "biro" (inserimento di 'o')
Ricerca Avanzata
Questo tipo di ricerca è più complesso, e permette, oltre ad inserire una parola di ricerca
full text di scegliere direttamente molte caratteristiche del LO, quali target, materia e
argomenti, tipo di applicazione e tipo di lezione.
Nell'esecuzione di questa ricerca vengono analizzati i campi specifici di ogni LOM e
sono confrontati con quanto scelto dall'utente.
Search Options
Queste informazioni sono fondamentali per la ricerca avanzata e servono per fornire
all'utente le possibili scelte sulle quali potrà effettuare una ricerca avanzata.
Ad esempio se nel repository sono presenti 3 lezioni pdf e 1 widget per Lavagne
Interattive nella scelta del tipo di applicazione ci sarà:
Esempio di Search Options riguardanti il
tipo di file.
Questi valori tengono conto anche di quanto è presente negli altri repository attraverso
un protocollo distribuito con il quale vengono scambiate queste informazioni.
Il risultato viene poi filtrato in base alle licenze, così un utente registrato vedrà le
opzioni riguardanti tutti i learning Object, mentre un utente non registrato vedrà solo
quelle riguardanti i learning object con licenza pubblica.
Cosi facendo ogni utente vede informazioni corrette e si riduce cosi la possibilità di
effettuare ricerche con risultato nullo.
La gestione e generazione di queste informazioni è gestita dall'enterprise Bean
SearchOptions il quale si occupa di creare queste informazioni analizzando il proprio
database e cercando quelle dei repository a esso collegati.
Generare queste informazioni è un’operazione complessa che richiede del tempo, per
questo è stato implementato un sistema di caching che le memorizza e le aggiorna
quando necessario, es: cancellazione o inserimento di un nuovo LO, e a tempo per
quanto riguarda le informazioni contenute negli altri repository.
Funzionamento Software Distribuito
Per far sì che i repository possano comunicare fra loro, in modo da favore lo scambio di
Learning Object fra le varie istanze e permettere una miglior disponibilità e diffusione
delle risorse è stato pensato di realizzare il repository in maniera distribuita.
I repository sono stati cosi organizzati in maniera gerarchica realizzando un albero dove
ogni elemento può avere un solo padre e un numero illimitato di figli. Non esiste un
repository server, ma sono tutte istanze identiche, le quali si occupano sia da fare da
padre ai propri figli, che da figlio al proprio padre, cosi facendo non sono necessarie
implementazioni differenti in base alla posizione gerarchica.
Esempio di Albero dei
Repository
All'avvio ogni repository tenta una connessione al padre. Se questa connessione dovesse
fallire, sarà riprovata a intervalli di 10 minuti, inoltre ogni repository è sempre in
ascolto delle richieste di connessione di un figlio.
Livelli di astrazione:
Ogni istanza comunica solamente con il proprio padre e i figli, tutti gli altri sono
nascosti poiché la comunicazione con quei repository è gestita in modo trasparente dal
padre o dal figlio. In tal modo un repository non deve conoscere tutta la topologia della
rete distribuita, ma comunica solamente con i suoi “vicini” i quali a loro volta si faranno
carico di comunicare con i loro “vicini” e cosi via.
Per esempio nell'esecuzione di una query distribuita il repository invia la richiesta al
padre i ai figli i quali faranno lo stesso estendendo cosi la query a tutta la rete di
repository, facendo sempre attenzione a non creare cicli i quali porterebbero a uno stallo
del sistema.
I risultati di una ricerca sono combinati con quelli degli altri repository creando il
risultato finale.
Questo tipo d’implementazione è semplice ma porterebbe ad avere scarse performances
in caso di una rete con molti nodi, e a mancanza di dati nel caso una delle istanze
dovesse andare off line.
Quindi nel caso la rete dovesse espandersi, sarebbe meglio modificare questa
implementazione con una centralizzata che sarà discussa nel prossimo paragrafo.
Possibile altra implementazione: Centralizzazione
Un'idea per sopperire ai limiti dell'implementazione completamente distribuita è quella
di centralizzare tutti i Learning Objects pubblici nella radice, in questo modo nei
repository figli restano solamente i LO privati che non devono uscire da esso, mentre
quelli pubblici sono copiati dal padre, in quale ne acquisisce i compiti di gestione. Cosi
facendo si avrebbe un grande repository centrale il quale gestisce tutte le risorse
pubbliche.
Le query verrebbero cosi effettuate su un solo repository, e non su un numero pari alla
grandezza della rete riducendo di molto i tempi. Inoltre in caso di caduta di un nodo le
risorse resterebbero comunque disponibili.
Interfaccia Web
Si tratta di un sito web realizzato per permettere l'utilizzo del repository con le
tecnologie JSF 2.0 e Ajax.
L'interfaccia permette di registrarsi, gestire il proprio account, inserire e ricercare i
Learning Object, ed è pensata per essere il più semplice e intuitiva possibile, rendondo
tutte le operazioni semplici veloci e naturali.
Iniziamo con un approfondimento riguardante le tecnologie e le scelte architetturali
utilizzate:
Framework:
Lo scopo di un framework è di risparmiare allo sviluppatore la riscrittura di
codice già steso in precedenza per compiti simili. In questo modo ho semplificato la
realizzazione del sito web riducendone il tempo di sviluppo.
Il principale framework utilizzato è JSF2
JSF:
Jsf è una tecnologia java basata sul pattern architetturale Model-View-Controller
(MVC). Il suo scopo è di semplificare lo sviluppo dell'interfaccia utente di una
applicazione Web.
Jsf prevede un ampio insieme di classi e relative API che permettono di:
•
Definire i componenti dell’interfaccia utente (UI), gestire il mantenimento del
relativo stato e il verificarsi dei relativi eventi.
•
Semplificare il sistema di gestione della navigazione tra le pagine della web
application;
•
Realizzare dei componenti personalizzati (Custom Component), che estendano e
potenzino le funzionalità delle classi base del framework;
•
Supportare l’internazionalizzazione e l’accessibilità dell'applicazione.
L'architettura di un'applicazione è stratificata su 3 livelli gerarchicamente
crescenti.
Alla base della gerarchia ci sono le servlet, mentre salendo troviamo il livello delle JSP
e all'apice la tecnologia JSF. L'utilizzo di JSF facilita lo sviluppatore nel suo lavoro
poiché consente di:
•
Gestire eventi, basandosi su Java Beans;
•
Utilizzare l’EL (Expression Language) per la realizzazione del valuebinding e il
method-binding, mediante il quale è possibile legare le proprietà dei componenti
dell’UI, rappresentati con tag nelle pagine, direttamente con la business logic.
•
Analizzare il ciclo di vita di una richiesta, ben definito attraverso una serie di
fasi, e recuperare in ogni istante le variabili d’interesse per la logica
dell'applicazione;
•
Utilizzare i backing beans (managed beans) costituenti la business logic, con la
possibilità di istanziarli in un qualsiasi momento on demand.
In JSF 2 è pero possibile sostituire il livello di JSP con un livello più avanzato, che e
facelets, permettendo cosi di realizzare pagine più ordinate ed efficienti:
Quest’opportunità di abbandonare JSP all'inizio mi è sembrata strana, in quando per
abitudine da sempre sia dai corsi universitari sia da quelli alle superiori mi hanno
sempre insegnato Java + JSP per realizzare un’applicazione web dinamica.
Ma Jsp ha sempre avuto dei limiti, che appaiono sempre più chiari nella realizzazione di
applicazioni Web 2.0 quali in primo luogo l’impossibilita di realizzare Template, ed
anche altri problemi riguardanti il ciclo di vita di una pagina: Java Server Facies a
differenza di JSP che processa gli elementi di una pagina nell’ordine in cui questi
appaiono, organizza i componenti in una complessa struttura ad albero.
Per questo è stato creato Facelets che risolve e migliora i seguenti aspetti riguardo a
JSP:
• indipendenza dal web container
• compatibilità con qualsiasi versione JSF
• tempi di compilazione più veloci
• supporto per il templating
• supporto di Expression Language
Le pagine di Facelets sono in formato Xhtml quindi sono well formed e non possono
contenere codice come jsp ma solamente tag. Questa cosa le rende molto piu ordinate e
comprensibili, inoltre migliora la distinzione fra visualizzazione e logica, riducendo cosi
anche gli errori di programmazione.
Framework per Ajax
Questa è stata la parte più e difficile nella scelta dei framework, poiché esistono
moltissimi framework tutti con diversi pregi e difetti. Io conoscevo già una libreria, con
la quale avevo già grande familiarità e confidenza: RichFaces.
Ho iniziato quindi a realizzare l'applicazione con richfaces, ma poi nei test ho notato che
era troppo dipendente dall'ambiente di esecuzione.
Quindi ho iniziato a testare altri framework per java e dopo numerose prove, ho scelto
di utilizzare IceFaces, perché è il piu semplice da configurare e offre una maggiore
portabilità fra i diversi container.
IceFaces
IceFaces è un framework open source che viene utilizzato dai programmatori Java EE
per creare Rich Internet Application (RIA) usando il linguaggio Java.
IceFaces sfrutta l'intero ecosistema di tool e ambienti di esecuzione basati su standard
JavaEE. Permette di sviluppare applicazioni RIA con numerose caratteristiche
sviluppate in Java senza bisogno di applet o plug-in proprietari da integrare nel
Browser. Le applicazioni IceFaces sono applicazioni JSF così che non ci sia bisogno
dell'utilizzo di Java script, inoltre il meccanismo che sta alla base (Ajax) è
completamente trasparente allo sviluppatore.
Il cuore di IceFaces è formato da tre elementi:
1.
Il Framework IceFaces
Questo è un'estensione del framework standard JSF con la fondamentale differenza con
cui è trattata la fase di rendering. Diversamente da JSF il rendering avviene nel DOM
lato server e solo cambiamenti parziali sono lasciati al browser e in seguito assemblati
con un bridge Ajax molto leggero. Il risultato è un render fluido, effettuato solo su certi
elementi della pagina. Ajax utilizza le Api inizializzate dal server e integra il
meccanismo similmente al cycle di JSF.
2. Il Bridge Ajax
Presenta elementi lato server e lato client che coordinano la comunicazione (basata su
Ajax) fra il browser del client e l'applicazione lato server. Il Bridge quindi si occupa di
apportare i cambiamenti alla presentazione dalla fase di rendering al browser del client e
del riassemblamento di questi cambiamenti nel DOM del browser per applicare i
cambiamenti. Inoltre ha il compito di rilevare le interazioni dell'utente con la
presentazione e di portare le azioni dell'utente indietro all'applicazione per essere
processate dal JSF lifecycle. Un meccanismo chiamato partial submit è integrato nei
componenti di IceFaces e facilita la generazione di eventi attraverso il bridge. La prima
volta che la pagina viene caricata viene creato il bridge Ajax e coordina gli
aggiornamenti della presentazione e la trasmissione degli eventi dell'utente per tutto il
lifetime dell'applicazione.
3. La Suite di componenti di IceFaces
La suite di componenti fornisce tutti i componenti per la costruzione dell'interfaccia
grafica dell'applicazione. Include sia i componenti standard di Jsf e una vasta gamma di
componenti che consente allo sviluppatore di costruire applicazioni sofisticate e
dall'interfaccia intuitiva. Oltre al meccanismo succitato dell'interazione diretta con il
DOM i componenti possono utilizzare un set di effetti come il drag and drop tutto ciò
con la semplice modifica di attributi così che non si debba mai ricorrere a Java script.
Purtroppo non tutto IceFaces è libero, tutti i componenti base sono liberi e accessibili,
invece alcuni componenti avanzati sono disponibili solo a pagamento, comunque con un
po’ di pratica nei componente base è possibile ricrearsi numerosi componenti avanzati.
Un altro punto di forza di IceFaces è la perfetta integrazione in NetBeans attraverso
un’estensione. In questo modo molte fasi d’installazione e configurazione sono
automatizzate rendendone semplice l'utilizzo e l'installazione.
Per riassumere questo è lo schema a livelli dell'applicazione web:
Presentation Tier
Request Controller
State Management
Funzionamento delle parti principali dell'applicazione web:
Registrazione:
La form di registrazione richiede nome utente, password ed email.
Questi dati sono controllati e in caso siano corretti, si viene registrati al repository e
automaticamente loggati.
In caso di errori essi saranno segnalati affianco del campo errato: Il nome utente deve
essere univoco ad avere almeno 4 caratteri, la password ha una lunghezza minima di 5 e
l'indirizzo email deve essere in un formato valido.
Dopo aver completato la registrazione, è consigliabile completare i propri dati per
ottenere un inserimento di risorse più agile e veloce.
Form per la registrazione al Repository
Login
Nel caso l'utente non sia loggato, nel box Pannello utente apparirà la form di login, la
quale permette anche di accedere alla registrazione.
Il login necessità di username e password e permette, attraverso l'opzione remember me
di essere loggati in automatico nei futuri accessi, questo avviene attraverso un popup
sicuro che viene salvato nel browser lato client con lo scopo di identificare l'utente. E
inoltra disponibile una procedura per il recupero della password, nel caso sia stata
dimenticata dall'utente, o inserita in modo errato in fase di registrazione.
Form per il login
Pannello Utente
Quando un utente è loggato, la form per il login è sostituita con una lista delle
operazioni che è possibile effettuare:
•
Aggiungere un nuovo Learning Object
•
Modificare i Propri dati
•
Modificare i propri Learning Object
•
Eseguire il Log out
Pannello Utente
Aggiunta di un nuovo Learning Object:
Quest’operazione è suddivisa in 3 diversi fasi:
La prima, riguardante l'upload della risorsa presenta la seguente schermata che ne
permette il caricamento da url oppure dal pc dell'utente:
Aggiunta di un nuovo Learning Object: Upload di una risorsa
L'inserimento da url è immediato, una volta cliccato su analizza verrà controllata la
correttezza del percorso inserito, in caso affermativo il learning object verrà analizzato
dal generatore SamgI e si potrà passare alla fase 2.
Nel caso che invece si esegue l'upload di un Lo dal pc locale, si aprirà un popup con lo
scopo di gestire quest’operazione. Una volta terminata, analogamente all'inserimento da
url la risorsa sarà analizzata e si potrà cosi procedere alla fase 2.
Upload di un Lo
La seconda parte riguarda il completamento dei metadati: dopo aver eseguito l'analisi
del Lo sono suggerite le varie opzioni e si richiede un controllo da parte dell'utente.
Aggiunta di un nuovo Learning Object: Inserimento dei Metadati
Come si può notare dall'immagine precedente è richiesto all'utente di controllare le
informazioni di maggiore importanza per la classificazione della risorsa, le altre
informazioni raccolte dal generatore, di minor importanza non vengono mostrate
all'utente, ma sono comunque salvate nel database per avere una più completa
descrizione del Lo.
Confermando questi dati si passa alla parte 3, nella quale viene semplicemente richiesto
di confermare l'inserimento e di scegliere la licenza da applicare al Learning Object
appena inserito:
Aggiunta di un nuovo Learning Object: Scelta della licenza
I tuoi dati
Questa pagina permette di modificare indirizzo email e password, inoltre offre la
possibilità di assegnare la materia e il livello d’insegnamento di default per le risorse
che saranno inserite dall'utente.
Non è invece consentito modificare il nome utente, perché trattasi di un dato univoco
nel repository, il quale è necessario per l'identificazione dell'utente.
Pagina per la modifica dei propri dati personali
Ricerca
Come già spiegato in precedenza, esistono 2
tipi di ricerca: Semplice e Avanzata la form per la ricerca è banale, e basta inserire la
parola e frase cercata, mentre per la ricerca avanzato è necessario scegliere i valori dei
campi desiderati come mostrato nella seguente immagine.
From per la ricerca
Risultati di una ricerca / I tuoi Learning Object
In questa pagina sono mostrati i risultati di una qualsiasi ricerca, mostrando i risultati e
le più importanti informazioni a essi associate, quali titolo, materie e argomenti, ecc...
Da qui è possibile scaricarli direttamente, oppure cliccando sul titolo si accede a una
pagina di approfondimento, contente maggiori informazioni, discussioni e pareri di altri
utenti riguardanti tale risorsa.
Risultati di una Ricerca
Nel caso della pagina che mostra i tuoi Learning Objects, per ogni risorsa vi è la
possibilità di cancellarla o modificarla attraverso degli appositi bottoni.
Dettagli di un Learning Object
Questa è la pagina principale e più dettagliata per la consultazione di un LO, vi sono
mostrate tutte le principali informazioni, i vari commenti e le recensioni date dagli
utenti come feedback. In questo modo oltre ad avere informazioni riguardanti la risorsa,
possiamo farci un’idea della sua qualità e dell'apprezzamento degli altri utenti che ne
hanno usufruito.
È inoltre data la possibilità di contattare direttamente l'autore per porre domande o
mandargli qualche segnalazione attraverso un popup disponibile solamente ai membri
della comunità. Per la sicurezza dell'autore non sarà mostrata la sua mail, ma l'invio
verrà gestito dal repository, in tal modo non viene reso pubblico l'indirizzo, evitando
cosi che spammer o malintenzionati possano disporre direttamente di quell'email. Cosi
facendo viene inoltra salvaguardata la privacy dell'autore.
D
ettagli riguardanti il Learning Object
Form per l'invio di una mail
all'autore
Integrazione Facebook
Per dare un feedback alle risorse e favorire la discussione, il confronto e il commento
delle stesse ho scelto di utilizzare alcuni plug-in sociali offerti da Facebook, in
particolare il famoso Like e la possibilità di aggiungere commenti.
In questo modo è data agli utenti la possibilità di segnalare le risorse migliori o quelle
scadenti, realizzando cosi un sistema di controllo della qualità.
L'integrazione di questi componenti è stata relativamente semplice: Facebook mette a
disposizione delle api per gli sviluppatori con un set di componenti standard tramite
FBML, una libreria di tag contenenti tutti i plug-in base per la costruzione di un sito
web sociale collegato a Facebook.
Purtroppo questi componenti sono pensati per ambianti di sviluppo quali Php e simili e
non risultano funzionanti su Jsf, per questo ho dovuto spendere del tempo nel creare un
sistema che permettesse di inserire questi componenti nella mia applicazione web.
Il sistema si basa principalmente sull'utilizzo di un frame che richiama una pagina
esterna, con delle routines Java script riesco a creare il codice FBML per associare un
learning object alle proprie risorse Facebook.
I componenti che sono stati utilizzati sono:
Like Button:
Questo pulsante permette di condividere il Lo con i tuoi amici in Facebook, quando
l'utente clicca su questo pulsante, sarà creato un post all'interno delle news dei tuoi
amici in Facebook contenente un link al Learning Object.
Inoltre verrà tenuto conto di quante persone hanno condiviso questa risorsa con i propri
amici, più questo numero sarà elevato più alta sarà la qualità della risorsa.
Sarebbe interessante sviluppare un sistema di ordinamento dei Lo in base alla loro
popolarità, in modo da fornire come prima scelta le risorse che sono più popolari e
meglio giudicate dagli altri utenti.
Esempio di Like button
associato a un Learning Object.
Comments:
Si tratta di un plug-in sociale che permette di inserire i commenti in una qualunque
pagina del sito, permettendo anche un controllo della discussione da parte di un
moderatore.
Rilevanza sociale
Il componente mostra per primi i commenti di più alta rilevanza per l'utente,
ordinandoli per mostrare prima i commenti dei propri amici, di amici di amici, i più
votati. I commenti segnalati come spam saranno nascosti.
Distribuzione:
I commenti saranno facilmente condivisi con i tuoi amici in quando è possibile,
attraverso l'opzione “Pubblica su Facebook” inviare la discussione sulle news dei Propri
amici all'interno di Facebook i quali potranno, senza accedere al repository contribuire
alla discussione.
Barra
dei Commenti associata a un Learning Object.
Launcher
Si tratta del programma con il compito di avviare il Repository.
Per far questo esegue l'avvio di Embedded Glassfish e carica su di essa il generatore di
meta-dati, il core e l'interfaccia web. Inoltre avvia anche il database XML.
Embedded Glassfish:
Si tratta della versione embedded del famoso Web Server Glassfish 3.1, il quale è
completo di tutte le funzionalità della versione normale (Jax-Rx, EJB container, JSP
container, Java DB integrato, ecc.) e può essere utilizzato e controllato tramite le
Embedded API.
Il funzionamento di embedded Glassfish è analogo al funzionamento di Glassfish
normale, e si basa sullo stesso dominio di esecuzione.
Il dominio di esecuzione è un albero di cartelle e di file di configurazione nel quale può
essere eseguita.
Anche se Embedded Glassfish può crearsi un dominio virtuale, è buona norma
assegnarne a essa uno già configurato, giacché permette di personalizzarne il
funzionamento nel dettaglio e di mantenere i dati fra diversi deploy della stessa
applicazione web.
Per questo, la prima cosa che è fatta dal Launcher è creare manualmente un dominio nel
caso che esso non esista ancora (es: Primo avvio dell'applicazione).
Questa creazione è relativamente semplice ed è suddivisibile in 3 passi:
•
Creazione dell'albero delle directory di esecuzione (domain/domain1 ecc...)
•
Configurazione del dominio, tramite la copia dei file di configurazione del
dominio da me scritti: es domain.xml nel quale viene principalmente specificata
la porta di esecuzione e il connection pool per la connessione al database.
•
Copia delle librerie necessarie al funzionamento delle applicazioni web che
saranno successivamente caricate nella cartella lib.
Dato che il database è integrato in Glassfish, una cancellazione manuale del dominio di
esecuzione di Glassfish porterebbe a una perdita di tutti i dati contenuti nel database
relazionale.
In seguito è avviata un’istanza di Glassfish sul dominio da me creato, la quale leggendo
il file config.xml si configurerà nel modo opportuno.
Avvio di SamgI e del Repository
Dopo aver eseguito un corretto avvio di Glassfish, viene caricato il generatore di
metadati, presente nel file amg.war.
Anche quest’operazione è banale: attraverso le api fornite da Glassfish, è necessario
solamente il path per il war ed esso sarà automaticamente caricato. Dato che le librerie
necessarie e le configurazioni sono già state settate in fase di avvio, non sono necessarie
ulteriori operazioni.
Lo stesso vale per il deploy del core e dell'interfaccia web i quali sono contenuti nel file
RepositoryDiLezioni.aer.
Una volta avviato il tutto il repository sarà attivo e sarà possibile accedervi attraverso
delle pagine web.
Conclusioni
Concludendo si può affermare che questo repository, inserito nel più grande ambito di
Wii4dida, è come un piccolo mattoncino che fa evolvere il progetto.
Anche se siamo ancora agli inizi, e i grandi cambiamenti si fanno lentamente a passo a
passo, penso di aver realizzato un’applicazione che potrà essere utile per la diffusione
delle Lim, e che pone la base per lo scambio e la classificazione dei Learning Object.
L'applicazione presentata in questa tesi è stata implementata sempre pensando
all'utilizzo da parte di un utente finale senza particolari conoscenze informatiche,
ponendo l'attenzione alla semplicità dell'utilizzo e alla portabilità del codice, che deve
poter essere eseguito su molti server indipendentemente dalle caratteristiche tecniche
della macchina e dalle conoscenze informatiche dell'utilizzatore.
Bibliografia
•
Wikipedia
-
http://it.wikipedia.org
•
Ariadne
-
http://www.ariadne-eu.org/
•
Referenze per i Metadati
http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf
•
Implementazione Java per Lom -
•
Creazione dell'applicazione Web - http://platform.netbeans.org/tutorials
•
Librearia Ajax Ice Faces
•
XML Db e Xquery Tutorials -
•
Embedded Glassfish Tutorials - http://download.oracle.com/docs/cd/E1979801/821-1754/gihyz/index.html
-
http://sourceforge.net/projects/lom-j/
http://www.icefaces.org/
http://basex.org/
Indice Analitico
Indice analitico
Aggiunta di un nuovo Learning Object:..........................................................................49
Architettura......................................................................................................................19
Argomenti........................................................................................................................34
Argomento.......................................................................................................................18
Ariadne............................................................................................................................14
Avvio ...............................................................................................................................59
Bibliografia......................................................................................................................60
Centralizzazione..............................................................................................................42
Comments........................................................................................................................57
Conclusioni......................................................................................................................59
Connexion........................................................................................................................14
Core.......................................................................................................................19 e seg.
Database Relazionale.......................................................................................................27
Database XML.................................................................................................................24
Dom...................................................................................................................................9
EJB .................................................................................................................................21
EJB di Entità....................................................................................................................22
EJB di sessione................................................................................................................23
EJB guidati da messaggi..................................................................................................23
Embedded Glassfish........................................................................................................58
Errori di Estrazione..........................................................................................................31
Estrattore..........................................................................................................................30
Facebook..........................................................................................................................56
Facelets............................................................................................................................45
Framework.......................................................................................................................43
Framework per Ajax........................................................................................................45
Generatore di Metadati....................................................................................................29
Generatori........................................................................................................................30
generazione assistita di meta-dati ...................................................................................16
Generazione Automatica..................................................................................................33
Generazione dei Metadati................................................................................................16
Gestione degli Utenti.......................................................................................................31
Gestione dei Meta-dati.....................................................................................................33
IceFaces...........................................................................................................................45
Implementazione di LOM.................................................................................................9
Inserimento......................................................................................................................35
Interfaccia Web................................................................................................................43
JaxB...................................................................................................................................9
JSF...................................................................................................................................43
Keywords...................................................................................................................18, 34
Launcher..........................................................................................................................57
Le Mill.............................................................................................................................13
Learning Object.................................................................................................................7
Licenza.............................................................................................................................35
Licenza Privata................................................................................................................37
Licenza pubblica..............................................................................................................36
Like Button......................................................................................................................56
Login................................................................................................................................48
LOM..................................................................................................................................7
Materia.............................................................................................................................34
Materia: ...........................................................................................................................17
Merlot..............................................................................................................................12
Metodo GET:...................................................................................................................25
Metodo POST..................................................................................................................26
Metodo PUT....................................................................................................................26
Pannello Utente................................................................................................................49
Registrazione...................................................................................................................47
Ricerca.......................................................................................................................38, 53
Ricerca Avanzata.............................................................................................................39
Ricerca Semplice.............................................................................................................38
Risultati di una ricerca.....................................................................................................53
SAX...................................................................................................................................9
Search Options.................................................................................................................39
SLIM4DIDA......................................................................................................................5
Software Distribuito........................................................................................................41
Target...............................................................................................................................18
Targhet.............................................................................................................................34
Tipo di applicazione........................................................................................................34
Tipo di Lezione................................................................................................................34
Tipo Oggetto: ..................................................................................................................17
Titolo................................................................................................................................34
tuoi dati............................................................................................................................52
VCARD...........................................................................................................................10
Web Services...................................................................................................................24
distanza di Levenshtein..................................................................................................38