Stato Avanzamento Lavori SAL Finale (1 Ottobre 2011 - 1

Spett.le
FI.LA.S. S.p.A.
Via della Conciliazione, 22
00193 Roma
Progetti di RSI delle PMI - POR FESR Lazio 2007/2013
Asse I – Attività I.1
RICHIESTA EROGAZIONE AGEVOLAZIONI
□
I SAL
x SALDO
1
Dati anagrafici della richiedente:
Denominazione:
Digital Video S.p.A.
Forma giuridica:
Società per Azioni
Indirizzo: via Sante Bargellini 4, 00137 ROMA
Codice fiscale e/o Partita IVA:
C.F. 05163320582 P.I. 01365181005
N. Telefono
+39 06 4325 2306
Nominativo Referente
Claudio MATTEI
2
N. Fax +39 06 4356 8516
Richiesta
Erogazione del contributo di Euro
Atto di
29 settembre 2010
Codice CUP
F87I0000380007
Titolo del progetto:
3
prot. n.
VOCS – Voice On Content Storyteller
Dettaglio costi sostenuti
252
Voci di Spesa
Ricerca
Industriale
(€)
Sviluppo
Sperimentale
(€)
Reti di
cooperazione
(€)
a. Personale (ricercatori, tecnici e altro
personale ausiliario) nella misura in
cui è impiegato nel progetto
39,405.92
169,753.46
0,00
b. Acquisizione di nuove
strumentazioni ed attrezzature
utilizzate per il progetto
1,020.76
992.78
0,00
c. Ricerca contrattuale, competenze
tecniche, brevetti servizi di consulenza
e servizi equivalenti utilizzati ai fini
dell'attività di ricerca.
23,030.00
120,485.00
0,00
d. Materiali di consumo funzionali ai
progetti di ricerca
1,356.98
0.00
0,00
e. Spese generali
6,857.43
30,765.51
0,00
Totale spese
71,681.08
321,996.75
0,00
4
Relazione sull'attività di ricerca svolta
WP1:Specifiche funzionali e realizzative del progetto
MESI 1-12
Il WP1 e' stato completato entro la la scadenza assegnata (1 Ottobre 2011) La descrizione estesa del WP1,
come da specifiche di progetto, e' la seguente:
WP1 Analisi: Specifiche funzionali e realizzative del progetto.
In questo Work Package vengono definite in modo dettagliato le specifiche della piattaforma: ambiti di
utilizzo, organizzazione contenuti e archivio, meccanismi di interazione vocali e non, modalità di creazione
dello storytelling, caratteristiche dell’Avatar, interfaccia prototipo finale.
E prevista una parziale sovrapposizione con alcuni WP realizzativi, per permettere una fase di test
preliminare delle specifiche realizzate.
WP1.1 Introduzione e descrizione svolgimento lavori.
La prima fase del progetto e' consistita nella raccolta e studio dello stato dell'arte negli ambiti di ricerca
riguardanti lo storytelling, i meccanismi di dialogo vocale, le tecniche di speech recognition e la sintesi
vocale.
Una volta acquisite le conoscenze necessarie, si sono messe a punto le caratteristiche funzionali del
software, per poi passare allo sviluppo delle specifiche realizzative di questo, sia per quanto riguarda la
creazione della storia, l'organizzazione dei contenuti multimediali, che per quanto riguarda la messa a punto
del sistema di I/O vocale.
Durante la messa a punto delle specifiche funzionali, si e' inoltre realizzato un Use Case, cioe' la simulazione
della costruzione di una storia interattiva reale. Nell'Use Case si e' simulato il workflow di un autore nella
costruzione della storia, le modalita' di creazione e interazione con gli avatar, la messa a punto dei
meccanismi vocali di interazione.
I prossimi paragrafi descriveranno e documenteranno le varie attività appena descritte.
WP 1.2 Stato dell'arte nel Dialogo Vocale per applicazioni mobili e multimediali
Mediavoice, in collaborazione con Infocom, la Fondazione Ugo Bordoni e Cultorale, hanno realizzato uno
studio sullo stato dell'arte dei meccanismi di interazione vocale per applicazioni mobili e multimediali.
WP 1.2.1 Il dialogo vocale
La voce è il più semplice, comune ed efficiente mezzo di comunicazione utilizzato dagli essere umani per
interagire tra loro. Per questo motivo sarebbe confortevole e naturale poter interagire con i dispositivi
attraverso il parlato, piuttosto che tramite le attuali periferiche di input (principalmente mouse e tastiera). Tale
motivazione ha portato i ricercatori a concentrare gli sforzi sullo sviluppo di sistemi in grado di effettuare il
riconoscimento automatico del parlato (ASR – Automatic Speech Recognition), così da permettere ai
dispositivi di identificare parole a partire dai suoni e trasformarle in testo o in comandi. Sistemi di questo tipo
trovano applicazione in molti ambiti, come dettatura, controllo, assistenza telefonica, traduzione
automatica…
Come sarà chiaro in seguito, la costruzione di un sistema di riconoscimento del parlato diventa sempre più
complessa, a causa del sempre più avanzato grado di perfezione che si vuol raggiungere, che punta a
coprire il più elevato numero di parlatori e il più vasto numero di applicazioni. Infatti, l’obiettivo è costruire un
sistema ASR in grado di risultare indipendente dall’utente che lo utilizza, di possedere un vocabolario infinito
e di funzionare indipendentemente dalle modalità di dettatura che l’utente utilizza. Così, dal riconoscimento
di poche parole, piccole frasi, si è giunti alla possibilità di avere a che fare con sistemi ASR in grado di
adattarsi al parlatore e riconoscere un elevato numero di parole, enunciati, testi, in varie lingue. La direzione
futura dello sviluppo punta a ottenere un sistema real-time, con accuratezza del 100%, capace di
riconoscere ogni parola intellegibile, pronunciata da chiunque, anche in presenza di rumore e in qualsiasi
lingua e accento.
WP 1.2.2 Classificazione dei sistemi di riconoscimento del parlato
I sistemi di riconoscimento del parlato si possono suddividere in varie categorie, sulla base del tipo di
pronuncia che sono in grado di riconoscere, del modello “aculinguistico” cui fanno riferimento, del
vocabolario di termini che possono essere riconosciuti.
In base al tipo di pronuncia riconoscibile, è possibile classificare i sistemi ASR nelle seguenti categorie:
•
Sistemi per parole isolate
I riconoscitori di parole isolate sono in grado di accettare in ingresso un suono continuo che presenti
silenzio all’inizio e al termine della finestra di campionamento, ovvero dell’intervallo sul quale viene
effettuata l’acquisizione audio. Tali sistemi trovano applicazione in tutti quei casi in cui all’utente è
richiesto un comando o una risposta; l’implementazione di questi sistemi è evidentemente la più
semplice, anche perché il comando dell’utente è appositamente pronunciato in maniera chiara e
precisa (es. “Stampa” , “Esci”).
•
Sistemi per parole connesse
I riconoscitori di parole connesse sono un’evoluzione dei sistemi per parole isolate, permettendo di
riconoscere brevi enunciati connessi con una minima pausa. Questi sistemi sono utili per tutte quelle
operazioni di comando/controllo che richiedono, ad esempio, di operare una certa azione su un
determinato elemento (es. “Apri Calcolatrice” , “Riproduci Musica”).
•
Sistemi per parlato continuo
I riconoscitori di parlato continuo permetto all’utente di parlare in modo quasi-naturale, mentre il
dispositivo discrimina il contenuto del parlato. L’implementazione di questi sistemi è più complicata,
in quanto il parlato viene emesso in modo sufficientemente complesso dal punto di vista
dell’articolazione, della fusione delle parole, della pronuncia, della quantità di termini pronunciabili.
•
Sistemi per parlato spontaneo
I riconoscitori di parlato spontaneo permettono all’utente di parlare in modo naturale, essendo in
grado di controllare e gestire tutta la varietà di caratteristiche del parlato umano, come errori di
pronuncia, esitazioni, sovrapposizioni. L’implementazione di questi sistemi è notevolmente
complicata in quanto richiedono potenze di elaborazione elevate e modelli di funzionamento di tipo
articolato.
I sistemi ASR necessitano della creazione di un modello del parlato, dovuto al fatto che ogni parlatore è
unico nel suo sistema vocale organico e nella sua personalità vocale. Infatti, per ogni parlatore, si deve
considerare una serie di caratteristiche psico-fisiche che rendono il modello molto complesso (struttura fisica
del cavo orale, velocità e stile del parlato, sesso, età, ambiente socioculturale…). Sulla base della tipologia
di modello vocale utilizzato, i sistemi ASR si possono suddividere in:
•
Sistemi dipendenti dal parlatore
I riconoscitori dipendenti sono implementati per uno specifico parlatore. Questi sono perciò molto
accurati per quel parlatore e generalmente inefficienti per altri; sono solitamente poco elaborati dal
punto di vista della complessità del modello, ma sono limitati dal punto di vista della flessibilità
nell’utilizzo. Nei sistemi commerciali, in fase di installazione, il sistema chiede all’utente di leggere un
testo noto con voce e velocità naturali. Il sistema si adatta così alle caratteristiche del parlatore,
offrendogli risultati sempre migliori in termini di precisione.
•
Sistemi indipendenti dal parlatore
I riconoscitori indipendenti sono sistemi progettati per una molteplicità di parlatori o, nel più delle
volte, per essere completamente scorrelati dal parlatore. Per questo motivo sono in grado di
riconoscere input provenienti da un vasto gruppo di persone; a questo scopo, l’accuratezza dei
sistemi indipendenti è in parte limitata, a favore di un più flessibile campo di applicazione. La loro
capacità di riconoscere più parlatori, però, ne aumenta la complessità dal punto di vista del modello
elaborativo.
Infine, sulla base dell’entità del vocabolario di termini riconosciuti, i sistemi ASR si possono suddividere in:
•
Sistemi a vocabolario ridotto - decine di parole
•
Sistemi a vocabolario medio - centinaia di parole
•
Sistemi a vocabolario grande - migliaia di parole
•
Sistemi a vocabolario molto grande - decine di migliaia di parole
•
Sistemi fuori vocabolario - in grado di mappare parole sconosciute in parole del vocabolario
WP 1.2.3 Principi generali di funzionamento
Il compito principale di un sistema ASR è quello di acquisire una forma d’onda sonora come ingresso e
produrre come output una stringa o un insieme di parole. Lo schema di principio di un sistema di
riconoscimento del parlato si può presentare come segue.
Un generico sistema ASR si compone di tre fasi: nella fase di pre-elaborazione vengono estratte le
caratteristiche relative alla traccia vocale acquisita, relativamente alla velocità, all’intonazione, alle pause
(questa fase può anche attuarsi una sola volta, nel periodo di addestramento del sistema); nella successiva
fase di decodifica vengono applicati i modelli acustici e linguistici che si hanno a disposizione, sulla base
delle caratteristiche ottenute nella fase precedente, allo scopo di effettuare una ricerca all’interno del
vocabolario in merito alle informazioni decodificate; infine, nella fase di post-elaborazione vengono
identificati i migliori match tra input vocale e stringa testuale allo scopo di costruire l’output finale. È chiaro
come tutte le fasi siano fondamentali per la qualità complessiva del sistema.
In ogni caso, il funzionamento di un generico sistema ASR si basa sulla comparazione dell’audio in ingresso,
opportunamente elaborato, con un database pre-registrato (speaker independent) oppure creato in fase di
addestramento del sistema (speaker dependent), allo scopo di ricercare la parola pronunciata dal parlatore
all’interno del database stesso. Questa operazione può essere effettuata sulla parola intera o sui singoli
fonemi. Alcune problematiche, però, rendono questo procedimento incredibilmente complesso: ogni volta
che una persona pronuncia la stessa parola, lo fa in modo differente, non producendo mai lo stesso suono
per uno stesso fonema; mentre l’orecchio umano è dotato del cosiddetto “ascolto intenzionale” che gli
permette quasi di isolare il suono che si vuole ascoltare dal sottofondo, per i sistemi ASR ogni rumore di
fondo è un elemento fortemente disturbante che inficia sul risultato del processo; il suono di ogni fonema,
inoltre, cambia a seconda del fonema che lo precede e che lo segue.
Tecniche di estrazione delle caratteristiche vocali
L’estrazione delle caratteristiche vocali è una delle fasi più importanti del processo di riconoscimento del
parlato, in quanto è essenziale per separare correttamente le parole e fornirle come input ai processi
successivi. Ogni voce ha caratteristiche differenti e individuali che si rispecchiano nella pronuncia. Queste
caratteristiche possono essere estratte attraverso varie tecniche, che comunque devono rispettare alcuni
criteri; esse infatti, devono permettere di misurare facilmente le caratteristiche estratte, devono possedere
caratteristiche stabili nel tempo (stesse tracce vocali devono presentare sempre stesse caratteristiche),
devono essere il più possibile indipendenti dall’ambiente di acquisizione (mostrare solo piccole fluttuazioni
tra un ambiente e l’altro per una stessa traccia).
Una delle più potenti tecniche di analisi è il metodo della codifica a predizione lineare (LPC – Linear
Predictive Coding), che è diventato uno dei metodi principali per la stima dei parametri di base della voce,
in quanto fornisce anche un prototipo computazionale della voce di rilevante funzionalità. Per questo motivo,
questa tecnica viene usata in genere in molte attività di elaborazione dei segnali audio e vocali, allo scopo di
rappresentare l’inviluppo spettrale del segnale vocale. Il modello vocale su cui si basa la tecnica LPC
strutturato in maniera tale da considerare la voce come un segnale potuto, caratterizzato da una precisa
intensità e frequenza, sul quale vengono inseriti (a causa del movimento della bocca e della lingua) una
serie di disturbi di tipo definito (sibili, pop). Un campione vocale, inoltre, si può sempre approssimare come
una combinazione lineare di vecchi campioni. È così possibile determinare una serie di parametri e
coefficienti caratteristici dell’apparato vocale e di alcuni campioni di riferimento, utili a determinare, o meglio
prevedere, campioni futuri. Ovviamente, maggiore è il numero di campioni acquisiti, maggiore è
l’accuratezza della previsione. I coefficienti così determinati vengono trasformati e normalizzati in un set più
robusto di parametri che prendono il nome di coefficienti cepstrali.
Un’altra tecnica ampiamente utilizzata è quella MFCC (Mel Frequency Cepstral Coefficients), che si basa
su un modello di tipo logaritmico che, rispetto a quello lineare usato in altre tecniche di rappresentazione del
segnale vocale, è capace di approssimare molto meglio il sistema vocale umano. Diversamente da quanto
accade nella LPC, il segnale vocale, dopo essere stato catturato e finestrato, subisce una trasformazione di
frequenza (in genere una DFT) e viene sottoposto a un banco di filtri triangolari equispaziati centrati su
particolari frequenze (mel frequency). Le ampiezze dello spettro determinato vanno a costituire il vettore
MFCC. Alcune varianti di questa tecnica prevedono modifiche delle spaziature delle frequenze,
dell’ampiezza dei filtri e delle tecniche di trasformazione/antitrasformazione in frequenza (ad esempio
coseno discreto). I valori MFCC non sono molto resistenti dal punto di vista del rumore; sono stati ideati,
perciò, alcuni stratagemmi per ridurre l’influenza del rumore, come ad esempio la normalizzazione dei valori
in potenza per eliminare i contributi a bassa energia (essenzialmente rumore).
WP 1.2.4 Evoluzione negli approcci di riconoscimento del parlato
Nel corso degli anni, vari sono stati gli approcci mediante i quali i ricercatori hanno affrontato il problema del
riconoscimento vocale. In una prima fase, hanno avuto una forte influenza le tecniche di programmazione
sviluppate per risolvere il problema del pattern-recognition. Infatti, dal punto di vista computazionale, il
problema del riconoscimento vocale consiste nell’analizzare un frammento, riconoscerlo e classificarlo
secondo categorie che rappresentino significati per gli esseri umani. Più precisamente, alla base di tutti gli
approcci si trova l’idea che esistono finite e distinte unità fonetiche (fonemi) in qualsiasi linguaggio parlato e
che queste sono caratterizzate da un set di proprietà acustiche misurabili. In realtà, queste proprietà sono
fortemente variabili. Successivamente, con l’avvento dei sistemi basati su reti neurali artificiali, anche i
sistemi di riconoscimento del parlato sono stati strutturati su questa modalità di elaborazione. In periodi più
recenti, lo studio dei modelli di calcolo stocastico ha portato alla creazione di nuovi approcci. In ogni caso, la
maggior parte delle applicazioni di tipo commerciale si basa ancora largamente su reti neurali, o su tecniche
ibride.
Un primordiale metodo di costruzione di un sistema ASR è quello ad approccio basato su template. In
questo tipo di tecniche si cerca una corrispondenza precisa tra una traccia vocale e un set di parole preregistrate, al fine di trovare il miglior match. Seppure molto accurato, perché spesso dotato di ottimi modelli
di riferimento per le parole, questo metodo è limitato dalla quantità di pre-registrazioni disponibili e dal fatto
che le parole pronunciate in fase di ingresso non devono subire variazioni dal punto di vista dell’intonazione
e della pronuncia. Infatti, la fase di preparazione dei campioni pre-registrati è dispendiosa e costruire un
vocabolario grande è impraticabile (spesso ci si limita a centinaia di parole). Inoltre è fortemente dipendente
dal parlatore e non permette il riconoscimento del parlato continuo.
Per ottimizzare i modelli ad approccio basato su template, si sono messi a punto degli algoritmi di
adattamento in grado di facilitare la misura di similarità tra tracce vocali. Questi algoritmi, noti come dynamic
time warping permettono di modificare le tracce vocali in termini di velocità e tempo, anche in modi non
lineari, per confrontare le une con le altre. In questo modo si cerca di trovare un allineamento tra le
sequenze isolate, anche se in alcune evoluzioni di queste tecniche, gli algoritmi sono in grado di lavorare
anche su piccoli enunciati.
Con l’avvento delle reti neurali si è divenuti in grado di risolvere problemi di riconoscimento del parlato più
complessi. Attraverso questi approcci, i sistemi ASR sono diventati più indipendenti dal punto di vista del
parlatore e più resistenti ai disturbi. Anche se esistono diverse metodologie che sfruttano le reti neurali,
quella più utilizzata consiste nel riconoscimento dei fonemi. Contrariamente a quanto accade in altre
tipologie di approcci, le reti neurali non si avvalgono di grosse assunzioni di tipo statistico riguardo le
proprietà vocali, ma sfruttano modelli probabilistici per intraprendere decisioni riguardo l’assegnazione di
determinati tratti vocali a specifiche parole sulla base delle informazioni iniziali fornite come training della
rete. Infatti, dopo una fase di addestramento relativa a un discreto numero di possibili fonemi di ingresso, la
rete neurale è pronta per discriminare i fonemi all’interno di tracce vocali di ingresso sufficientemente
complesse.
Per migliorare un sistema ASR si può adottare un approccio di tipo statistico, allo scopo di stimare modelli
acustici e linguistici a priori, piuttosto che misurarli o determinarli in ingresso, incidendo così sulla velocità e
sull’efficienza dell’intero sistema di riconoscimento del parlato. Ovviamente, molto dipende dalla bontà del
modello probabilistico utilizzato per le assunzioni acustiche e linguistiche, che può essere affetto da non
accuratezza, inficiando così su tutte le performance del sistema.
Uno dei modelli più popolari allo stato dell’arte è l’Hidden Markov Model (HMM). La popolarità di questo
approccio è dovuta alla sua capacità di addestramento automatico e alla sua flessibilità e semplicità
computazionale. L’applicazione di questo modello è permessa dal fatto che la sequenza dei fonemi di un
segnale vocale segue il principio di Markov, per cui la probabilità di un evento futuro è legata esclusivamente
all’evento presente e non agli eventi passati; il segnale vocale, infatti, si può considerare come un processo
stazionario a tratti o per brevi periodi. Il modello di Markov prevede la generazione di una sequenza
vettoriale n-dimensionale di valori reali, con n molto piccolo (in genere 15-30) Questo prevede la
generazione di una matrice di fonemi, correlati tra loro sulla base della probabilità che un fonema segua un
altro. Questa matrice viene usata per l’addestramento della rete neurale che, una volta riconosciuto un
fonema (o una parola), conosce quali fonemi (o parole) devono essere ricercate nell’analisi della successiva
traccia. In questo modo si possono inoltre creare automaticamente modelli di parole o frasi sulla base dei
modelli probabilistici associati ai fonemi.
L’architettura di un sistema automatico di dialogo si compone di un modulo di riconoscimento vocale, un
modulo di comprensione del linguaggio, uno per la generazione del linguaggio, un modulo per la
generazione della voce e infine un modulo per la gestione del dialogo (Figura 1).
Figura 1: Architettura funzionale generica di un sistema automatico di dialogo
Attuali approcci del riconoscimento del parlato
La funzione del modulo di riconoscimento vocale é quella di convertire il segnale vocale, proveniente da un
microfono o dalla linea telefonica, e opportunamente digitalizzato, in una stringa di testo corrispondente alla
sequenza di parole pronunciate e estratte da un vocabolario definito in precedenza. Il vocabolario e la
grammatica devono essere definiti a priori, quindi il riconoscitore non può riconoscere parole estranee al
vocabolario. Allo stato dell’arte dei riconoscitori commerciali si possono riconoscere vocabolari di decine di
migliaia di parole usando grammatiche per regole o usando grammatiche statistiche. Nei sistemi
commerciali, ad ogni turno di dialogo c’é una grammatica (in genere a regole, ma sempre più
frequentemente negli ultimi anni, statistica) definita in modo da coprire tutte le possibili risposte al prompt
definito per quel turno. Nei sistemi di ricerca, invece, il vocabolario e la relativa grammatica (tipicamente
statistica e a grande copertura) sono gli stessi per tutti i turni di interazione, quindi non viene cambiata al
cambiare dello stato del dialogo. In alcuni sistemi la grammatica viene adattata utilizzando un corpus
raccolto durante la messa in opera (tipicamente centinaia o migliaia di frasi registrate e trascritte durante la
fase operativa del sistema).
La comprensione del linguaggio
La funzione del modulo di comprensione del linguaggio é quella di convertire la rappresentazione testuale
della frase di ingresso (generata dal riconoscimento vocale) in una rappresentazione semantica. Ci sono
svariati modi per rappresentare la semantica, ma il più comune, utilizzato nei sistemi di dialogo, è quello
basato su key-value pairs. Per esempio, la seguente richiesta:
“Voli da Milano a Roma nel pomeriggio di Domenica 28 Novembre”
può essere rappresentata semanticamente con i seguenti key-value pairs (slots):
RICHIESTA: VOLO; ORIGINE: MI; DESTINAZIONE: ROMA; ORARIO: 12:00-18:00; DATA: 28-11
Per classificazione semantica si intende il processo di assegnazione, ad una frase di input, di una categoria
(o classe) appartenente a un dizionario di categorie semantiche ben preciso.
Il numero delle categorie semantiche é in genere determinato dalla applicazione. Ma si possono usare
classificatori che prescindono dall’applicazione e assegnano una categoria da una lista più ampia delle
effettive categorie semantiche utilizzate.
Per la classificazione semantica é necessario un corpus che contenga un numero sufficiente di esempi
testuali di frasi (dette “trascrizioni”), ciascuno associato a un identificatore di tipo semantico (detto
“annotazione”) (Figura 2). Il corpus viene utilizzato da un algoritmo di training che produce i parametri di un
classificatore in grado di assegnare automaticamente un tag.
Offline download/upload
capabilities
Selects utterances from
sets or single grammars
Sortable, configurable
utterance lists
Multiple/Unique utterance
views
Drag’n drop file-folder
interface
Play utterance
Update
transcription/annotation
Manage lists of semantic
categories
12
Figura 2: Esempio di sistema di trascrizione e annotazione.
La fase di acquisizione del corpus è particolarmente delicata se si vuole poter addestrare adeguatamente il
classificatore. Questa acquisizione può essere effettuata in modi diversi:
1. Utilizzando la tecnica del Mago di Oz [1] e [2], che è stata molto usata nei primi sistemi
commerciali. Oggi è un po’ caduta in disuso, sia per il costo di addestramento dell’operatore
(Wizard), sia per la migliore qualità ottenuta da una annotazione offline e la possibilità di rivedere
l’annotazione in fasi successive. Il Mago di Oz è una simulazione che permette di avere dati
sull'interazione tra il parlante e la macchina senza avere a disposizione un sistema di dialogo. La
simulazione consiste nel far interagire un utente con una macchina “finta”, impersonata dallo
sperimentatore (chiamato wizard), senza che il primo ne sia a conoscenza. Le precondizioni per
ottenere dei dati utili sono tre: i. deve essere possibile simulare il sistema (ad es. se il sistema
gestisce un database, il database deve essere disponibile); ii. deve essere definito come si
comporterà il sistema; iii. la simulazione deve essere convincente. La tecnica WoZ prevede l’utilizzo
di operatori addestrati i quali, in tempo reale, comprendono la richiesta dell’utente e instradano la
chiamata alla terminazione telefonica corretta, nel caso di “call routing”, oppure interagiscono con un
sistema computerizzato che permette loro di associare la frase ad una “tag” semantica appropriata.
Mentre l’utente ha la percezione di interagire con un sistema automatico (il prompt é sintetico, o
registrato), l’operatore (wizard), esegue in tempo reale la funzione di annotazione, e può interagire
con il sistema automatico simulando, lui stesso, il sistema di “comprensione del linguaggio”. I dati
così raccolti vengono poi utilizzati per l’addestramento.
2. Annotazione offline. Le frasi di training possono venire acquisite in modi diversi, a seconda
che si disponga di un sistema online o meno (per esempio un vecchio sistema IVR, o un sistema
esistente con riconoscimento vocale ma per il quale si voglia progettare una variante che prevede la
comprensione del linguaggio).
a. Nel caso non si disponga di un sistema di dialogo in linea, occorre reclutare i
soggetti con particolare attenzione alla loro estraneità allo sviluppo del sistema in questione.
I soggetti devono appartenere, al meglio possibile, alla distribuzione statistica degli utenti del
sistema in progetto. I soggetti devono essere istruiti alla esecuzione di un compito simile a
quello in progetto, con particolare attenzione a non creare delle “cue” linguistiche che
possano suggerire ai soggetti certe parole o forme verbali, e quindi costituire un “bias” del
corpus (per esempio si possono proporre scenari in modo visuale o schematico, senza
istruire i soggetti “parola per parola” su quello che devono dire). Il problema di questo tipo di
collezione di corpus deriva dal fatto che i soggetti istruiti ad eseguire un compito “virtuale” si
comportano in modo diverso da utenti reali con una vera e propria motivazione ad usare il
sistema.
b. Nel caso si disponga di un sistema in linea da utilizzare come meccanismo
di collezione del corpus, si può inserire nel sistema un prompt per la raccolta della frase
richiesta. Per esempio, si assuma di avere un sistema IVR (per favore selezioni 1 per
informazioni sul suo credito attuale, 2 per acquistare più crediti, 3 per ...), e si voglia usare
questo sistema per acquisire un corpus da utilizzare per un centralino a linguaggio naturale.
Si può inserire all’inizio della transazione, prima del primo prompt, un prompt che richiede
una frase in linguaggio naturale, per esempio “Per favore mi dica il motivo della sua
chiamata”. Poiché il sistema di comprensione non esiste ancora (deve essere ancora creato
basandoci sul corpus), il sistema di acquisizione non reagisce alla frase del chiamante, ma
la registra semplicemente, per poi passare il controllo al sistema IVR (Grazie. Per favore
selezioni 1 per informazioni sul suo credito attuale, 2 per acquistare più crediti, 3 per ...) o
turno seguente. Il progetto del prompt di acquisizione é molto importante, e deve essere
effettuato con cautela.
Lo scopo della acquisizione, trascrizione, e annotazione di un corpus di frasi é sia quello di creare un
modello del linguaggio (grammatica) statistico, sia quello di creare un classificatore semantico in grado di
produrre una o più tag semantiche su ciascuna frase di input. Per un buon sistema di classificazione
semantica con un numero di valori semantici inferiore ai 100, si richiedono dalle 5.000 alle 10.000 frasi
campione. Ovviamente con corpora di maggiori dimensioni si possono ottenere prestazioni più elevate.
La prima fase del processo richiede la trascrizione di ciascuna frase del corpus. Questa viene effettuata da
trascrittori che devono essere addestrati, almeno marginalmente, sul contenuto generale delle frasi del
corpus. In particolare deve essere fornita loro una lista delle parole meno comuni che potrebbero essere
trascritte erroneamente, e dei termini specifici del contesto utilizzato. Questa lista deve essere aggiornata
periodicamente da un “manager di trascrizione”, il quale provvede al controllo di qualità delle trascrizione
mediante campionamento e controllo. La lista deve includere anche parole che possono essere trascritte in
modi diversi, per esempio email e e-mail, e fornire indicazioni sulla trascrizione accettata. Inoltre, é
necessario creare uno standard di trascrizione che preveda simboli per parti della frase incomprensibili,
parole interrotte o ripetute, e rumore.
Al contrario della trascrizione, l’annotazione richiede personale specializzato che abbia una comprensione,
seppur minima, del contesto e della applicazione. Nella prima fase del progetto di annotazione é necessario
creare una “guida di annotazione” che includa una lista completa delle tag semantiche e una spiegazione del
significato di ciascuna (per esempio alcuni esempi di frasi). La guida di annotazione deve essere riveduta
periodicamente insieme agli annotatori.
La generazione del linguaggio
La maggior parte dei sistemi di dialogo non usa un modulo di generazione del linguaggio sofisticato. Infatti,
la quasi totalità dei sistemi commerciali usa prompt registrati quando l’informazione del prompt non é
variabile. In caso di informazione variabile (per esempio quando il prompt include una data, un numero, una
località, o il nome dell’utente), si usano sistemi di generazione molto semplici, basati su templates, o ibridi
che utilizzano template e macchine a stati finiti. La generazione del linguaggio per sistemi di dialogo é un
area di ricerca che é stata trascurata da anni, ed esiste molto poco in letteratura. Recentemente sono stati
sviluppati dei metodi statistici di generazione del linguaggio.
La generazione della voce
La maggioranza dei sistemi di dialogo commerciali usa prompt registrati da un attore. La registrazione dei
prompt viene gestita dal progettista VUI che segue l’attore in modo da dare al prompt l’intonazione richiesta
dal sistema. Nel caso il prompt sia costituito da porzioni con informazione variabile, e l’informazione sia
riducibile ad un numero di elementi limitati (per esempio una data o un numero), il prompt viene diviso nelle
corrispondenti porzioni (incluso gli elementi variabili) che vengono registrati separatamente. In fase operativa
il prompt viene assemblato in tempo reale. Per la costruzione di prompt con informazione variabile si usa la
tecnica del “concatenative prompt recording” (CPR), nella quale le varie porzioni del prompt vengono
registrate in versioni multiple con tipi diversi di intonazione. L’esempio tipico é quello dei numeri. Ogni digit
viene registrato in tre versioni, con intonazione ascendente (se in inizio frase), piatta (se centrale) o
discendente (se a fine frase). In fase di assemblaggio vengono scelte le porzioni con l’intonazione corretta in
funzione della posizione di ogni singolo digit nella frase. Nel caso in cui l’informazione variabile nel prompt
non é limitata (per esempio il nome di un prodotto da una estesa lista di prodotti, o il nome dell’utente da un
database di utenti), si deve ricorrere all’utilizzo di un sistema di TTS (text-to-speech). In alcuni sistemi di alta
qualità i prompt vengono assemblati con porzioni registrate e porzioni sintetizzate da un TTS creato sulla
stessa voce dell’attore.
La gestione del dialogo
La funzione del modulo di gestione del dialogo é quella, ad ogni turno, di ricevere i segnali di ingresso (le tag
semantiche dalla comprensione della voce, e eventuali informazioni provenienti dai sistemi esterni) e
generare comandi per l’esecuzione della prossima attività del dialogo (per esempio la generazione di un
prompt, o l’esecuzione di comandi sui sistemi esterni). Per fare questo il modulo di gestione deve mantenere
il contesto, sotto forma di variabili che vengono accumulate durante il corso del dialogo. I sistemi di gestione
del dialogo si possono categorizzare in tre classi fondamentali:
1. Sistemi di controllo a macchina a stati finiti ricorsiva (call-flow). Questi sono la stragrande
maggioranza dei sistemi commerciali, dove il dialogo é gestito da un “call flow”, rappresentato come
una macchina a stati finiti, tipicamente gerarchica. Ogni nodo rappresenta sia una attività (per
esempio la generazione di un prompt o la richiesta di informazioni a un database), oppure il ricorso a
un sotto-dialogo, rappresentato a sua volta da un’altra macchina a stati finiti. Nei sistemi moderni, un
nodo corrisponde ad un modulo di dialogo che gestisce tutte le funzioni discorsive relative alla
richiesta di un elemento informativo, come per esempio il re-prompting e la conferma.
2. Sistemi basati su inferenza. Questi sono tipicamente sistemi di ricerca dove il compito del dialogo
viene specificato in modo dichiarativo, e una macchina inferenziale seleziona le azioni opportune in
modo da completare il task.
3. Sistemi stocastici basati sul machine learning. Questi sistemi sono basati su strategia di machine
learning, tipicamente reinforcement learning. Il task viene descritto tramite un sistema di rewards, e
algoritmi di reinforcemente learning imparano a selezionare le azioni in modo da massimizzare il
reward globale. Poiché il training richiede migliaia di interazioni, non é possibile utilizzare utenti reali,
ma si usa un “utente simulato”.
Nel campo commerciale e in ricerca si distinguono due tipi di dialogo caratterizzati dai termini “dialogo
diretto” e il “dialogo a iniziativa mista”. Nel dialogo di tipo diretto i prompt di sistema istruiscono il parlante a
rispondere in modo ben preciso, per esempio suggerendo risposte, sia in modo diretto che indiretto, o
facendo domande alle quali la risposta é chiaramente “si” o “no”. Questi sono esempi di prompt diretti:
Per favore selezioni una delle opzioni seguenti: informazioni sul conto, aprire un nuovo conto o
pagamenti arretrati.
Ha ricevuto la visita del nostro tecnico? Per favore risponda si o no.
Nel caso di dialogo a iniziativa mista si lascia la libertà all’utente di esprimersi a suo piacimento (per esempio
Per favore descriva brevemente il problema), ed anche di fornire informazioni che non sono state
espressamente richieste dal prompt (Da quale città vuole partire? Vorrei partire da Genova al mattino).
Nello stato dell’arte nei sistemi di dialogo, specialmente quelli commerciali, la strategia prevalente é quindi
quella di utilizzare open prompts quando sia necessario, e continuare il dialogo con richieste precise per la
finalizzazione della transazione. Lo sviluppo di grammatiche statistiche permette, in ogni caso, di poter
riconoscere espressioni estranee a quelle richieste esplicitamente dal prompt diretto, e quindi di conferire al
dialogo una certa elasticità che lo avvicina alla iniziativa mista.
WP 1.2.5 Progetto e sviluppo di un sistema di dialogo
Moduli di dialogo
I moduli di dialogo, o dialog modules, o semplicemente DM, sono i componenti fondamentali di sistemi di
dialogo di arbitraria complessità. Per definizione, un DM è una funzione predisposta alla acquisizione di uno
o più elementi di informazione in un turno di dialogo. Visto come una black-box, un DM, una volta invocato
dal sistema di dialog management, esegue un certo numero di operazioni e ritorna il controllo al dialog
manager in uno di due stati finali: informazione acquisita o fail. I DM esistenti in commercio (per esempio
Nuance, o SpeechCycle RPA) sono progettati per l’acquisizione di informazioni specifiche, quali:
-
SI’ o NO
-
DIGITS
-
NUMERI NATURALI
-
CODICE FISCALE
-
DATE
-
QUANTITA’ DI VALUTA
-
NOMI E INDIRIZZI
-
NUMERI DI CARTA DI CREDITO
-
DATE PER LA VALIDITA’ DELLE CARTE DI CREDITO
Una volta integrato in una applicazione, un DM specifico può essere configurato per l’applicazione. Per
esempio un DM_Carta di credito può essere configurato per un tipo di carta specifica (per esempio Visa,
Mastercard, o American Express), o un DM_Quantità di valuta può essere configurato per un ammontare
minimo o massimo (per esempio dell’ordine delle decine, centinaia, o migliaia di Euro, a seconda
dell’applicazione). Esistono anche DM_custom che possono essere configurati a piacimento per
l’acquisizione di un qualunque tipo di informazione relativa a una particolare clientela [3], [4], [5].
Internamente un DM è un mini-dialogo, con una logica che prevede l’esecuzione delle seguenti funzioni
(dette anche funzioni di “discourse”).
- Emissione del prompt iniziale
-
Attivazione del riconoscitore con grammatica iniziale
-
Gestione del time-out
-
Gestione di livelli diversi di confidenza del riconoscimento
o
Alta confidenza, DM esce con risultato
o
Media confidenza, DM inizia dialogo di conferma
o
Bassa confidenza, DM richiede l’informazione (reprompting)
-
Gestione del dialogo di conferma
-
Gestione del recognition rejection.
-
Gestione del dialogo di reprompting
-
Gestione della “lista delle esclusioni” dal vocabolario. Questa é utile quando una risposta é stata
esplicitamente negata in un dialogo di conferma (per esempio Ha detto Aosta, è giusto? No.) e
quindi questa risposta deve essere esclusa dalla grammatica nei turni seguenti per evitare di
incorrere in un loop (Lo dica di nuovo, per favore. Ancona. Ha detto Aosta, giusto? No. OK. Lo ridica
per favore. A N C O N A. Ha detto Aosta …)
-
Configurazione di grammatiche in parallelo. Può essere utile avere grammatiche globali (per
esempio richiesta di operatore, richiesta di aiuto) in parallelo a qualunque grammatica di “contenuto”
del DM.
-
Logging specifico di tutti gli eventi.
Attualmente i DM sono elementi relativamente complessi che possono essere configurati dal punto di vista
funzionale nel modo seguente:
- Numero massimo di reprompt
-
Conferma sempre, in caso di bassa confidenza, o mai
-
Valori delle soglie di confidenza
-
Valore della soglia di rigetto
-
Grammatiche di contenuto e globali.
Per la messa in opera, un DM richiede un certo numero di prompt:
- Prompt iniziale
-
Uno o più prompt di conferma, fino al numero massimo di conferme previsto.
-
Uno o più reprompt, fino al numero massimo di reprompt previsto
-
Prompt di fail.
Strategie alternative di gestione degli errori
La strategia di gestione degli errori tipica, descritta nella sezione precedente, é quella della correzione a due
passi (two-step confirmation), così chiamata perché la correzione di un errore richiede non meno di due
turni:
S: Dica il nome della città, prego
U: Ancona
S: Ha detto Aosta, è giusto? Per favore dica sì o no (STEP 1)
U: No
S: Dica di nuovo il nome della città, per favore (STEP 2)
U: Ancona
S: Sì. Ancona.
Un metodo alternativo é quello della correzione a un passo, come nel seguente esempio:
S: Dica il nome della città, prego
U: Ancona
S: Ha detto Aosta, è giusto? (STEP 1)
U: No, Ancona
S: Sì. Ancona.
Non esistono studi pubblicati sull’efficacia di questo tipo di correzione, ma uno dei problema é quello
dell’accuratezza. La correzione a due passi ha una accuratezza alta per due motivi: il vocabolario SI/NO
(Yes/No) ha una accuratezza quasi del 100%, mentre nel secondo passo si può usare una lista a
esclusione—come spiegato in precedenza—ed escludere la parola negata (Aosta nell’esempio), evitando di
incorrere nello stesso errore una seconda volta. Mentre questa seconda opzione é possibile anche nella
correzione a due passi, l’accuratezza di riconoscimento di frasi di negazione seguite dalla correzione (no, è
Ancona) é senz’altro inferiore rispetto a quella del vocabolario SI/NO. Quindi, anche se la durata del dialogo
di correzione a un passo può essere inferiore, la sua accuratezza é più bassa della strategia a due passi. Il
secondo problema é quello dell’indurre gli utenti ad eseguire una correzione ad un passo, quindi progettare
un prompt che induca la maggior parte dei parlanti a usare una espressione di correzione del tipo no, è
Ancona.
Alcuni lavori [6] propongono uno studio su strategie alternative di recovery da situazioni di noncomprensione, ovvero di rigetto d parte del modulo di riconoscimento e comprensione. Vengono identificate
dieci possibili strategie di recovery: “AREP: Richiesta di ripetere la frase”, “ARPH: Richiesta di riformulare la
frase”, “RP: Riprompt”, “DRP: Riprompt più dettagliato”, “NTFY: Notifica di non comprensione”, “YLD:
Silenzio”, “MOVE: Continuare i dialogo passando a una seconda domanda”, “YCS: Suggerimento su cosa
dire”, “TYCS: Suggerimento su cosa dire in modo più dettagliato”, “HELP: Lungo messaggio di aiuto”.
I risultati sperimentali suggeriscono che la strategia migliore é “MOVE”, cioè dove il sistema reagisce alla
mancata comprensione continuando con un’altra domanda, diversa dalla precedente, invece di insistere in
un re-prompting. La seconda migliore strategia é “HELP”, dove il sistema propone una descrizione dello
stato attuale del dialogo e alcuni esempi di quello che l’utente può dire.
Voice User Interface
Per Voice User Interface (VUI), si intende la completa specifica del comportamento di un sistema in tutte le
possibili situazioni. Il progetto della VUI viene tradizionalmente completato, prima del vero e proprio sviluppo,
da un VUI designer. Comprende i seguenti elementi:
- Specifica testuale completa di tutti i prompt, inclusi i prompt iniziali, i re-prompt, i prompt di conferma,
eccetera.
-
Specifica di massima di tutte le grammatiche (esempi di frasi accettate, e lista completa dei semantic
tag) per ogni turno del dialogo.
-
Topologia del dialogo in termini di transizioni condizionali fra un nodo rappresentante un turno e il
successivo.
Funds Transfer
Entry
Skip the following "Get"
blocks if not needed...
Get Originating
Account
Available Account are:
Checking, Savings, and
Reserve Credit
Get Destination
Account
Available Account are:
Checking, Savings, and
Reserve Credit
Get Transfer
Amount
Once
Corrected
natural
language
shortcut
Originating Account
Is amount >
originating
balance?
Destination Account
Transfer Amount
No
Yes
Play Bad Amount
Message
Once
Corrected
Get Transfer Date
Transfer Date
Play Verify Transfer
Message
Get Incorrect Part
No
Transfer Verified?
Yes
Play Transfer Message
(and balances if Date is
'today')
Main Menu
Figura 3: Esempio di visione di insieme del diagramma di flusso (parziale) di un sistema di dialogo
durante il progetto VUI. Il call-flow riportato in questo esempio si riferisce ad una applicazione
bancaria di SpeechWorks.
Ancora oggi molte aziende effettuano il progetto VUI compilando un documento che include una visione
completa della topologia del dialogo, mediante una serie di moduli standard inizialmente adottati da
SpeechWorks verso la fine degli anni ‘90, e poi estesi a quasi tutta l’industria. In questo tipo di specifica il
progettista compila, in una prima fase, una visione di insieme del diagramma totale di flusso, come per
esempio quella di Figura 3. In funzione della complessità del progetto, l’intera visione di insieme del sistema
di dialogo può richiedere molti diagrammi di flusso. La seconda parte é la completa specifica di ciascun
modulo di dialogo (corrispondente a un nodo del diagramma di flusso), mediante una tabella, come quella
riportata in Tabella 1.
4000_GetTransferDate
DialogModule™
Date
(Previously ALTdmCustomContext)
Entering from
Er rore. L'ori gine riferimento non è stata tr ovata., Errore. L'origine riferimento non è stata trovata.
Prompts
Type
Name
Wording
Initial
funds_transfer_date_initial
"When would you like to transfer these funds ? If yoùd like to transfer
t he funds immediately, please s ay today."
Timeout 1
funds_transfer_date_first_timeout
"I'm sorry, I didn't hear you. Please say the month and day you want
your funds trasferred... for example, January 25th or next
wednesday."
Timeout 2
funds_transfer_date_second_timeout
"I didn't hear you that time either. Please say today, tomorrow, or a
f uture date like Oct ober 31st."
Retry 1
funds_transfer_date_initial_reprompt
"Please say when you would like to t ransfer these funds."
Retry 2
funds_transfer_date_reprompt
"Please say when you would like to t ransfer funds one more time. If
yoùd lik e to transfer funds immediately, say 'today'. If you would like
t o transfer funds in the future, please say the month and day.. . for
example, January 25th or next wednesday."
Help
help
help
funds_transfer_date_help
"On which date to want this transfer to bec ome effective. You can
say a date like 'Oct ober thirty first,' 'next thursday,' or 'two weeks
f rom yesterday.'"
Option
Vocabulary
Date
<date _string>
DTMF
N/A
Action
Confirm.
Go t o: “Er rore. L'origine ri ferimento non è
stata trovata."
N ever
Confirmation Prompts
Option
Name
Date
Default confirmation, as handled by t he Date
DialogModule™
Wording
Result
“I think you said <…>, is that correct?”
Commands
See default settings, as specified in “Erro re. L'origine riferimento non è stata trovata.” on page Error! Bookmark not def ined..
Module Settings
Allow Barge-in
Tabella 1: Esempio di specifica completa di un modulo del call-flow parziale di Figura 3.
Nello sviluppo tradizionale, la specifica, una volta completata, viene passata ai programmatori, i quali la
implementano utilizzando uno dei seguenti metodi:
- VoiceXML statico
-
VoiceXML dinamico. Sistema di sviluppo Web, per esempio Java Server Pages (JSP).
-
VoiceXML dinamico. Sistema di sviluppo grafico.
In genere, oggi, si tende ad evitare lo sviluppo di sistemi basati su pagine statiche di VoiceXML, sia per la
complessità (ad esempio un sistema di dialogo moderno può includere migliaia di pagine) associata alla
difficoltà di gestione (in un sistema di pagine VoiceXML statiche, non é possibile avere una visione ad alto
livello del call-flow). Quindi, nei sistemi moderni, si usano pagine di VoiceXML generate dinamicamente da
un programma che contiene una descrizione grafica del call-flow.
Esistono, in commercio, diversi programmi grafici che consentono di creare una descrizione completa del
call-flow (inclusi i prompts, le grammatiche, e le connessioni ai back-end esterni). Per esempio, il sistema
RPA (Rich Phone Application) sviluppato e commercializzato da SpeechCycle, é basato sulla architettura
mostrata in Figura 4.
Figura 4: Architettura di dialogo del sistema RPA (SpeechCycle).
RPA Compose é un sistema grafico di progetto e sviluppo di un sistema di dialogo. Consiste in un plug-in
per MS Visual Studio, e quindi utilizza tutte le feature di Visual Studio (Figura 5).
Figura 5: Esempio di sistema di sviluppo utilizzato all'interno di MS Visual Studio
Una volta terminata la specifica completa di un call-flow mediante RPA Compose, il sistema compila una
meta-rappresentazione che viene poi interpretata dal sistema di run-time RPA Transact, il quale genera,
automaticamente e in real-time, pagine dinamiche di VoiceXML ad ogni turno di interazione.
WP 1.2.6 Sistemi di dialogo Open Source
Il pacchetto open-source più completo per lo sviluppo di sistemi di dialogo allo stato dell’arte é senz’altro
Olympus [7], sviluppato alla Carnegie Mellon University (CMU) per il progetto Let’s Go Lab [8] e utilizzato
anche da alcuni partecipanti al progetto Spoken Dialog Challenge [9].
Olympus é basato sulle tecnologie sviluppane alla CMU. In particolare:
- La gestione del dialogo é fatta da RavenClaw [10] basato su un sistema ad agenda [11]. Il sistema
ad agenda é stato sviluppato diversi anni fa da Rudniky alla CMU e si basa su una descrizione
“goal-oriented” del task. L’agenda viene mantenuta automaticamente e crea l’istanziazione delle
azioni (per esempio “prompt”) che ottimizzano la risoluzione del goal più promettente.
-
La gestione dell’interazione a basso livello, come nel calso dei “dialog modules” descritti in
precedenza, viene eseguita dal sistema Apollo [12].
-
Il riconoscimento della voce viene effettuato dal sistema di riconoscimento open source della CMU (
Sphynx).
-
La comprensione del linguaggio dal sistema Phoenix [13].
-
La generazione del linguaggio basata sul sistema Rosetta [14]
-
La sintesi della voce basata sul sistema Kalliope.
-
L’architettura su MIT Galaxy [15].
IN particolare, l’architettura Galaxy, sviluppata da MIT negli anni 1990, e prodotta e resa open source da
MITRE in occasione del progetto DARPA Communicator, é basata su una HUB centrale che comunica
con un numero arbitrario di servers plug-in. La HUB può essere programmata in modo da simulare una
qualunque connettività (anche condizionale) fra i server (Figura 6).
Figura 6: Diagramma della architettura Galaxy.
WP 1.2.7 Valutazione del dialogo
Misure oggettive delle prestazioni del dialogo
Al di la delle misure delle prestazioni di riconoscimento per ogni singolo turno, si possono sviluppare misure
delle prestazioni globali oggettive, come il livello di automazione, il task completion rate o il transaction
completion time, e il tempo medio di transazione (AHT o Average Handling Time). Nonostante alcune misure
potrebbero richiedere una annotazione manuale, per esempio per stabilire il successo o meno del dialogo, si
preferisce utilizzare metodi automatici (anche a scapito di una certa precisione nella misura), in quanto una
qualunque valutazione manuale richiede tempo e lavoro, e quindi limita sia la possibilità di valutare grandi
quantità di dialoghi in tempo reale, sia la possibilità di introdurre sistemi automatici di “machine learning” per
l’ottimizzazione del sistema.
Correntemente si usano, sia nei sistemi commerciali che in quelli di ricerca, diversi metodi per assegnare
misure oggettive sulle prestazioni di dialogo. Il metodo più efficace é quello di individuare dei nodi del callflow il cui raggiungimento (insieme ad altre condizioni), garantisce l’avvenuto successo della transazione.
Per esempio, in un sistema di banking, se l’utente supera la fase di deposito o trasferimento, il dialogo può
essere considerato completato con successo. In un sistema di risoluzione di problemi, se l’utente supera la
fase di “recovery” e non richiama successivamente per lo stesso problema, il dialogo può essere considerato
completato con successo.
Analisi dell’esperienza dell’utente
Mentre le misure di accuratezza del riconoscimento della voce, e le misure di prestazione e successo del
dialogo sono oggettive (una volta definiti i criteri) e possono essere automatizzate in modo semplice, la
misura di soddisfazione dell’utente (customer satisfaction), richiede delle valutazioni soggettive. Il metodo
più usato é quello del questionario o survey. Alcuni degli utenti, selezionati in modo casuale, vengono
richiamati non molto tempo dopo aver eseguito una transazione (non oltre 24 ore dopo), e vengono poste
loro delle domande orientate ad una valutazione soggettiva della qualità della interazione. I problemi con
questo metodo sono i seguenti:
- il costo della esecuzione del questionario non é indifferente. Oggi si usano spesso questionari
automatizzati tramite sistemi di dialogo che chiamano direttamente l’utente a un orario stabilito
(sistemi outbound)
-
una percentuale molto bassa (spesso inferiore al 20%) di utenti richiamati per il questionario
accettano di completarlo.
-
Le risposte prodotte dagli utenti sono spesso poco utili per stabilire le cause del malfunzionamento di
un sistema.
Un nuovo sistema di valutazione dell’esperienza di utente, detto Caller Experience Index (CEI), é basato
sulla valutazione soggettiva di un corpus di registrazioni di dialoghi completi (tipicamente qualche centinaio)
fatta da un gruppo di “valutatori”, i quali assegnano un punteggio a ciascun dialogo su una scala da 1 a 5. Il
punteggio corrisponde alla valutazione sulla qualità dell’esperienza di utente. Utilizzando un numero
sufficiente di “valutatori”, si riesce a mantenere una consistenza della valutazione che permette l’uso del
punteggio medio come un parametro “oggettivo”. La tecnica di CEI é basata su concetti simili alla tecnica di
MOS (Mean Opinion Score), utilizzata per la valutazione dei sistemi di trattamento della voce (compressione,
sintesi) [16].
WP 1.2.8 Nuove frontiere del dialogo vocale
Dialogo multimodale
Nella realtà il dialogo vocale è sempre accompagnato da altre modalità di comunicazione. Noi parliamo e
nello stesso tempo comunichiamo con i gesti, con le espressioni facciali, indichiamo oggetti presenti nella
realtà circostante, e così via. Purtroppo però la commercializzazione di sistemi multimodali che
comprendano anche il dialogo vocale è ancora molto limitata. Questa situazione potrà cambiare
positivamente con la sempre più ampia diffusione degli smartphone o dei tablets, che favoriranno l’uso di
interfacce multimodali che includano la voce [17].
Il progetto “Companion”, nato da un consorzio Europeo di 14 partners [18], mira alla realizzazione di un
“compagno virtuale” utilizzando lo stato dell’arte delle tecnologie di dialogo sia vocale che multimodale. La
differenza fondamentale fra un sistema di dialogo tradizionale e il dialogo sviluppato in Companions é che
non c’é un unico compito, ma i compiti sono multipli, e nella conversazione si può passare da un compito a
un altro. Questo obiettivo richiede uno studio accurato delle situazioni di dialogo e delle conseguenti
strategie, incluse “empathy” e “positivity”, che non sono tipicamente considerante nello sviluppo di dialoghi
“task oriented” di tipo commerciale. A questo proposito é interessante uno studio effettuato tramite Wizard of
Oz da Nick Webb et al. [19], la cui conclusione richiama alla necessità di una maggiore comprensione del
contesto.
L’architettura di uno dei sistema più sofisticati [20] si basa sul motore di dictation Nuance, seguito da un
classificatore di sentimento (sentiment analysis) [21], con l’obiettivo di assegnare un valore allo stato
emozionale dell’utente su una scala di 5 valori. In parallelo, un motore di comprensione di linguaggio
naturale genera una analisi sintattica e semantica della frase. Il risultato é una valutazione dell’evento in
contesto con valori emozionali dell’utente. Il modulo di gestione del dialogo (Dialog Manager) decide se a)
fare una domanda riguardo all’evento b) esprimere una opinione, o c) generare delle frasi per esprimere
empatia con l’utente. Quando, dopo un certo numero di turni, il sistema ha raggiunto una comprensione
sufficiente dell’evento in contesto, genera un prompt complesso che esprime conforto, opinioni, e
suggerimenti, anche dettati dal contesto. Questo prompt é generato da un modulo specifico chiamato
Affective Strategy Module [22].
Questo tipo di tecnologia “affettiva” può essere particolarmente utile per il progetto VOCS, per la
progettazione dell’Avatar in grado di ascoltare e di parlare con una voce ‘emozionale’, di poter pronunciare in
maniera particolarmente chiara i messaggi di più difficile fruizione. Il ruolo principale dell’Avatar, nel progetto,
è infatti quello di rendere più facile il dialogo fra il sistema e l’utente, sia perché il sistema è in grado di
simulare virtualmente una persona umana che parla, sia perché le informazioni fornite dai movimenti della
bocca sono complementari a quelle acustiche percepite dalle orecchie.
Dialogo vocale integrato in dispositivi mobili
Fino a pochi anni fa, il riconoscimento del parlato all’interno dei telefoni cellulari era limitato alla possibilità di
pronunciare il nome di dieci o al massimo venti persone e poterle così raggiungere telefonicamente, dopo
una sessione di training. Naturalmente il successo della chiamata non era scontato, dipendendo sia da
quanto la pronuncia del nome fosse simile a quella prodotta durante il training, sia da quanto l’ambiente in
cui il sistema veniva usato fosse simile all’ambiente dove il sistema era stato addestrato, subendo quindi un
vero e proprio crollo in ambienti rumorosi.
Oggi, i più diffusi sistemi integrati comprendono applicazioni vocali in sistemi mobili e applicazioni da fruire in
auto, applicazioni vocali per decoder, set-top-box, eBook reader, autobus e treni, apparati medicali, screen
reader ed altri ausili per i disabili, computer industriali e militari, robot, bancomat, applicazioni di domotica,
elettrodomestici, ed innumerevoli altri dispositivi di elettronica di consumo.
Per quanto riguarda i sistemi mobili, l’esempio più noto è quello di Siri, l’assistente vocale introdotto
recentemente da Apple con il nuovo iPhone 4S. Siri non vanta nessuna particolare innovazione tecnologica,
basandosi infatti sullo stato dell’arte della tecnologia vocale, così come la conosciamo dalla fine degli anni
’70. La novità di Siri è quella di affacciarsi sul mercato al momento giusto, perfettamente integrata in uno
degli strumenti più desiderati e popolari tra i consumatori, grazie anche alle applicazioni di ricerca vocale
come quelle di Google e di Microsoft (Bing), e all’assistente vocale per Android, Vlingo, che hanno reso
verosimile l’idea di parlare con il proprio SmarPhone.
Le interfacce vocali integrate in sistemi mobili o in automobile pongono nuovi e interessanti problemi di
usabilità [23]. Infatti l’interazione vocale con servizi di telefonia mobile si differenzia da quella con telefono
fisso o con i computer desktop. Progettare e costruire interfacce vocali usabili integrate in sistemi mobili
richiede di ripensare completamente l’interazione, dal punto di vista degli utenti e dell’ambiente in cui
l’interazione avviene. Per quanto riguarda gli utenti va considerato che si tratta di utenti in movimento, con
mani e occhi occupati. Per quanto riguarda l’ambiente di interazione, non si tratta di un ambiente definito a
priori, ma bisogna prevedere che l’utente spostandosi si muova da un ambiente di un certo tipo a un altro
con caratteristiche completamente diverse.
WP 1.2.9 Conclusioni
Nell’articolo, abbiamo presentato lo stato dell’arte del dialogo automatico [24]. E’ ovvio che siamo ancora
lontani dal dialogo tra esseri umani. In questo caso, infatti, il dialogo avviene in modo libero, non vincolato.
La principale differenza rispetto all’interazione uomo-macchina è che quella tra esseri umani è un’interazione
aperta, dinamica, con più parlanti, ognuno con i propri scopi e che condividono conoscenze sull’ambiente in
cui avviene il dialogo, sulle relazioni tra i partecipanti al dialogo, e così via.
La comunità scientifica ha sempre cercato di raggiungere la naturalezza nell’interazione con l'utente
permettendo una sempre maggiore libertà di espressione [25].
Uno dei motivi di questo è che la tecnologia odierna non è ancora in grado di imitare la comunicazione
umana con gli stessi livelli di precisione, robustezza, e efficacia. Infatti, se da una parte il riconoscimento e la
comprensione del parlato commettono errori, dall’altra le interfacce utente sono ben lontane dall'efficacia
degli esseri umani. Perché tutta questa tecnologia funzioni, è necessario imporre severe limitazioni agli
obiettivi delle applicazioni, cosa che richiede una grande quantità di lavoro manuale per i progettisti. Queste
limitazioni sono spesso non percepite dagli utenti e questo può creare un problema. Più il sistema esibisce
un comportamento antropomorfo, infatti, più l'utente tende a sentirsi libero di esprimersi, e a pretendere una
naturalezza che non è invece supportata dall'applicazione, creando così un divario tra l'utente e la macchina
che porta ad inevitabili problemi di comunicazione.
E’ molto importante quindi per i sistemi di dialogo commerciali avere una Voice User Interface (VUI) ben
definita, seguendo il principio chiamato “completezza della VUI”. L'interfaccia VUI è completa quando il suo
comportamento è completamente specificato rispetto a tutte le possibili situazioni che possono verificarsi
durante l'interazione, comprese le frasi degli utenti e le risposte del sistema. Attualmente, al fine di garantire
la completezza della VUI, è consigliabile arrivare alla specifica della completezza dell'interfaccia già nella
fase iniziale di progettazione. L'unico paradigma di gestione del dialogo in grado di produrre interfacce VUI
complete in modo semplice e riproducibile è quello funzionale rappresentato dal flusso di chiamata. Altri
meccanismi più sofisticati, come quelli basati su inferenze o modelli statistici, richiedono complessità molto
maggiore e maggiori costi per garantire la completezza VUI.
Presto tutti o quasi tutti utilizzeranno uno smartphone come principale strumento di comunicazione. La
capacità di comprimere la voce sul dispositivo, inviarlo a un server remoto tramite un veloce collegamento
dati 3G, e contemporaneamente visualizzare le informazioni, trasformerà il paradigma del dialogo vocale in
una comunicazione wireless multimodale. Solo con l'aggiunta della componente visiva ad un sistema di
riconoscimento vocale si potrà ridurre o rimuovere la maggior parte degli errori presenti nei sistemi di
dialogo, che sono una delle cause principali della scarsa adozione dei sistemi vocali.
L’applicazione prevista dal progetto VOCS, che dovrà funzionare in ambienti aperti, con più utenti interessati
a dialogare col sistema, richiede lo studio di nuove soluzioni ai problemi di dialogo finora affrontati.
L’applicazione dovrà essere in grado di coordinare con gli altri partecipanti al dialogo la presentazione e il
riconoscimento dei segnali comunicativi, di rilevare, identificare, individuare e caratterizzare i partecipanti al
dialogo.
Al fine di progettare un’interfaccia come quella del progetto, è necessario estendere le tecniche di
elaborazione del linguaggio naturale, solitamente utilizzati per sequenze lineari di discorso, con tecniche che
prevedano l'integrazione e la comprensione del linguaggio multimodale, distribuiti su più modalità di input.
Bibliografia
[1] Aiello, D., Cerrato, L., Delogu, C., Di Carlo, A., “The acquisition of a speech corpus for limited domain translation”, Proceedings of
"EUROSPEECH '99", Budapest, September 1999, vol. 5, 2223-2226
[2] Aiello D., C. Delogu, R. De Mori, A. Di Carlo, M. Nisi, S. Tummeacciu, “Automatic Generation of Visual Scenarios for Spoken
Corpora Acquisition”, 5th International Conference on Spoken Language Processing ICSLP 98, Sydney, November 30 December 4, 1998, paper 0499
[3] Barnard, E., Halberstadt, A., Kotelly, C., Phillips, M., “A Consistent Approach To Designing Spoken-dialogue Systems,” Proc. of
ASRU99 – IEEE Workshop, Keystone, Colorado, Dec. 1999.
[4] Nuance Dialog Modules: http://www.nuance.com/for-business/by-solution/customer-service-solutions/solutions-services/inboundsolutions/self-service-automation/dialog-modules/index.htm
[5] SpeechCycle Partner Portal: http://partners.speechcycle.com/
[6] Bohus, D., and Rudnicky, A., “Sorry, I Didn't Catch That! - An Investigation of Non-understanding Errors and Recovery Strategies”,
in Proceedings of SIGdial-2005, Lisbon, Portugal.
[7] http://wiki.speech.cs.cmu.edu/olympus/index.php/Olympus
[8] Eskenazi, M., Black, A., Raux, A. and Langner, B. “Let's Go Lab: a platform for evaluation of spoken dialog systems with real world
users”, Interspeech 2008, Brisbane, Australia
[9] Black, A., Burger, S., Langner, B., Parent, G., and Eskenazi, M. “Spoken Dialog Challenge 2010” Spoken Language Technologies
2010, Berkeley, CA
[10] Bohus, Dan & Alexander I. Rudnicky (2009), "The RavenClaw dialog management framework: Architecture and systems",
Computer Speech & Language.
[11] Rudnicky & Wei Xu, "An agenda-based dialog management architecture for spoken language systems", IEEE ASRU Workshop
(1999).
[12] Raux, Antoine & Maxine Eskenazi, "A Multi-Layer Architecture for Semi-Synchronous Event-Driven Dialogue Management", IEEE
Automatic Speech Recognition and Understanding Workshop, 2007.
[13] Ward, Wayne & Sunil Issar, "Recent improvements in the CMU spoken language understanding system", ARPA Human
Language Technology Workshop, 1994.
[14] Ward, Wayne & Sunil Issar, "Recent improvements in the CMU spoken language understanding system", ARPA Human
Language Technology Workshop, 1994.
[15]http://communicator.sourceforge.net/sites/MITRE/distributions/GalaxyCommunicator/docs/manual/index.html
[16] Evanini, K., Hunter, P., Liscombe, J., Suendermann, D., Dayanidhi, K., Pieraccini, R., “Caller Experience: a Method for Evaluating
Dialog Systems and its Automatic Prediction”, in Proc. of 2008 IEEE Workshop on Spoken Language Technology (SLT 08),
December 15-18, 2008, Goa, India.
[17] R. Pieraccini, D. Suendermann, K. Dayanidhi, J. Liscombe, “Are We There Yet? Research in Commercial Spoken Dialogue
Systems”, Text, Speech and Dialogue -- 12th Int'l Conference TSD 2009.
[18] Companions Project: http://www.companions-project.org/
[19] Bradley, J., Benyon, D., Mival, O. and Webb, N., “Wizard of Oz Experiments and Companion Dialogues”. Proc. Human Computer
Interaction 2010 (HCI'10), 6-10 September 2010, Dundee, UK.
[20] Cavazza, M., Santos de la Cámara, R., Turunen, M., Relano Gil, J., Hakulinen, J., Crook, N., and Field, D. (2010), “How was your
day? An Affective Companion ECA Prototype”, Proc. 11th Annual Meeting of the Special Interest Group on Discourse and
Dialogue (SIGDial), 24-25 September, 2010, University of Tokyo, Tokyo, Japan, pp. 277-280
[21] Moilanen, K. and Pulman. S. (2009). “Multi-entity Sentiment Scoring”. Proc. Recent Advances in Natural Language Processing
(RANLP 2009). September 14-16, Borovets, Bulgaria. pp. 258—263
[22] Cavazza, M., Smith, C., Charlton, D., Crook, N., Boye, J., Pulman, S., Moilanen, K., Pizzi, D., Santos de la Camara, R., Turunen,
M., “Persuasive Dialogue based on a Narrative Theory: an ECA Implementation”, Proc. of the 5th Int. Conf. on Persuasive
Technology 2010.
[23] Botond Pakucs, “Butler: A Universal Speech Interface for Mobile Environments”, Internal Report Centre for Speech Technology
(CTT), KTH, 2005.
[24] Pieraccini R. “The Voice in the Machine: Building Computers That Understand Speech”, MIT Press, 2012
[25] Pieraccini, R. Huerta, J., “Where do we go from here? Research and Commercial Spoken Dialog Systems”, Proc. of 6th SIGdial
Workshop on Discourse and Dialog, Lisbon, Portugal, 2-3 September, 2005. pp. 1-10
WP 1.3 Stato dell'arte nello Storytelling
Digital, in collaborazione con Infocom , hanno realizzato uno studio sullo stato dell'arte dello storytelling nelle
applicazioni software. Riportiamo un estratto dello studio in questione.
WP 1.3.1 Introduzione
In termini narrativi lo Storytelling è una metodologia che, usando i principi della retorica e della narratologia,
crea racconti influenzanti in cui vari pubblici possono riconoscersi. Lo storytelling è oggi massicciamente
usato dal mondo dell'impresa, dal mondo politico e da quello economico, per promuovere e posizionare
meglio valori, idee, iniziative, prodotti, consumi. Le applicazioni di questa disciplina sono molte, dall’ambito
della letteratura a quello della politica, da quello aziendale a quello scolastico. Il successo di questa
disciplina è determinato dal fatto che il racconto è una forma di comunicazione naturale e intuitiva, capace di
coinvolgere le persone.
Il termine “Digital Storytelling” si deve a Joe Lambert e Dana Atchley che negli anni '90 realizzarono un
sistema interattivo multimediale all’interno di una performance teatrale dove su di un largo schermo sullo
sfondo mostrava immagini e filmati di storie di vita. Il gruppo di artisti, educatori e professionisti della
comunicazione che via via si costituì attorno a loro è riuscito negli anni ad allargare i campi di intervento del
digital storytelling a molti contesti che spaziano dalla scuola alle aziende, dall’arte all’impegno politico. Il
centro da allora ha aiutato molte persone ad utilizzare gli strumenti digitali per raccontare le loro storie di
vita, dimostrando che le stesse tecnologie che hanno creato distanza e frammentazione potevano essere
usate in modo nuovo per ri-connettere, creare nuovi legami, sentirsi partecipi di una comunità. La narrazione
digitale diventa insomma un collante culturale. La diffusione dei computer e di Internet ha permesso uno
sviluppo dello storytelling, il ricorso a blog, forum e social network infatti dà la possibilità di condividere le
proprie esperienze. Attraverso questi mezzi è in grado di emergere un tipo di conoscenza dal basso, che
può essere interessante. Una tendenza sviluppatasi con la rete è quella della condivisione delle proprie
esperienze, e lo strumento informatico permette anche la pubblicazione di materiale multimediale. Internet
permette inoltre di pubblicare testi e racconti in appositi siti, gratuita e priva della figura dell’editore. In molti
casi l’industria editoriale ha funzionato da filtro, escludendo dalla pubblicazione molte opere, secondo canoni
e criteri diversi. Sia per ragioni economiche, sia per questioni inerenti alla qualità dell’opera.
Tra le applicazioni più importanti dello storytelling c’è la pedagogia. Il ricorso a storie può essere infatti di
facile comprensione per l’apprendimento del bambino. Nei libri scolatici delle scuole elementari infatti, per
rendere semplice un concetto si ricorre ad una storia o a dei personaggi. Una tecnica simile è utilizzata
anche nei corsi di lingue, molti sono organizzati con dei personaggi, che tramite un dialogo o un testo
mostrano un aspetto della lingua. La metodologia dello storytelling consiste nell'uso di procedure narrative al
fine di promuovere meglio valori, idee ed è incentrato sulle dinamiche di influenzamento sociale.
La narrazione ha un potenziale pedagogico e didattico, dalla quale possiamo trarne peculiarità educative e
formative intendendole sia come strumento di comunicazione delle esperienze, sia come strumento riflessivo
per la costruzione di significati interpretativi della realtà. Dare rilievo alla narrazione, ai racconti dei soggetti
che vengono coinvolti nei processi educativi e formativi, rappresenta la svolta epistemologica sia per leggere
fenomeni e processi (narrazione come strumento di ricerca), sia per produrre azioni e cambiamenti
intenzionali (narrazione come strategia didattica). La narrazione è uno strumento per penetrare in profondità
nelle cause e nelle ragioni di eventi, i particolari che vengono raccontati costruiscono una storia, diventano
reali e determinano la storia stessa. Questa metodologia è una risorsa sia per l'educazione, sia per la
formazione, promuove uno sviluppo generativo tra l'esperienza, l'osservazione della stessa e le intuizioni che
ne derivano. Lo storytelling è fondamentale in diversi contesti educativi e formativi con la prospettiva di lifelong learning, sia in termini cognitivi che educativi. L'elemento autobiografico nello storytelling è
fondamentale perché la realtà diventa una presupposizione, un indizio, una narrazione appunto che
corrisponde ad un'interpretazione soggettiva.
Fin dall'infanzia lo storytelling contribuisce in maniera notevole all'alfabetizzazione, in quanto è proprio la
contestualizzazione di tale processo entro il quadro della narrazione che facilita la costruzione di senso
intorno all'apprendimento complesso della scrittura e della lettura. Bisogna acquisire delle regole per
comporre un testo. Il “raccontare” in forma narrativa strutturata permette di creare le basi
dell'alfabetizzazione, ovvero una prima costruzione di significati condivisi tra adulto e bambino. È importante
usare tale metodologia sin dalla prima scolarizzazione utilizzando i tipi di testualità adeguati al grado di
alfabetizzazione dei bimbi. Da alcuni anni la metodologia dello storytelling ha trovato spazio anche nel
campo della formazione degli adulti e dell'apprendimento a livello di istruzione superiore. Mc Druy e Alterio ci
forniscono appunto interessanti argomentazioni in merito all'uso riflessivo sull'esperienza al fine di migliorare
i processi di apprendimento. Utilizzando il metodo di raccontare storie, diventa possibile situare
l'apprendimento nei contesti significativi e promuovere processi dialogici di interazione riflessiva attraverso lo
sviluppo di contesti collaborativi.
Lo storytelling è una metodologia che usa la narrazione come mezzo creato dalla mente per inquadrare gli
eventi della realtà e spiegarli secondo una logica di senso. L’atto del narrare, nello storytelling, si ritrova
nell’esperienza umana e si può rappresentare in varie forme (individuali o collettive) che connettono
pensiero e cultura. Soprattutto le emozioni dell’uomo – attraverso la narrazione – trovano il mezzo più
efficace di espressione. Il pensiero narrativo possiede una molteplicità di significati, ma questi necessitano di
essere tradotti, affinché si possano costruire una o più forma di comunicazione che siano rielaborate dai
soggetti secondo i termini della narrazione. Il discorso narrativo permette di rendere comprensibile,
comunicabile e ricordabile il vissuto. Quindi, il pensiero narrativo organizza l’esperienza soggettiva e
interpersonale; mentre il discorso narrativo rende possibile la riflessione. Si tratta di un “processo interattivo”
dal momento che il discorso narrativo rende possibili interpretazioni molteplici per tutti i soggetti che entrano
in contatto con una certa storia. Attraverso il “racconto di storie” noi cerchiamo di “mettere ordine” e di dare
un senso attivo alle nostre caotiche esperienze quotidiane. Il nostro “vissuto umano” prende forma, diviene
comunicabile, comprensibile e può essere ricordato. Con il raccontare si compie una sorta di “collegamento”,
dalla duplice funzione:
Diretto all’interiorità: narrazione in funzione riflessiva;
Rivolto al contesto in cui si è immersi
Lo storytelling si sviluppa a partire dall’assunzione di due principi fondamentali: l’organizzazione delle
esperienze umane avviene grazie ai racconti e la narrazione è un processo che dota le persone di una
sensibilità culturale che li mette in grado di attivare processi riflessivi e formativi, soprattutto nei gruppi. Il
modo attraverso cui questi racconti vengono condivisi è il “discorso narrativo”, traduzione del “pensiero
narrativo” di cui tutte le persone sono dotate. Il discorso narrativo, per essere efficace, deve possedere
alcune caratteristiche specifiche: sequenzialità narrativa (l’ordine dato in un racconto può non riflettere lo
svolgersi cronologico dei fatti reali, né la contingenza delle relazioni causa-effetto); particolarità (evidenziare
dettagli che nella realtà potrebbero apparire poco o non significativi); intenzionalità; verosimiglianza
(percezione che l’ascoltatore deve avere riguardo alla storia); componibilità (intreccio tra le varie parti del
della narrazione e il suo insieme); referenzialità (si riferisce a quanto la storia possa essere plausibile);
appartenenza a un genere (devono essere ben identificabili sia la fabula che l’intreccio).
Il discorso narrativo può esplicitarsi in varie modalità: orale, scritta, mediata. Il metodo più efficace sembra
essere quello orale tuttavia anche gli altri due metodi si stanno rivelando fruttiferi. Il testo scritto si
caratterizza soprattutto per due elementi: temporalità degli eventi e causalità della concatenazione dei fatti.
Aspetto fondamentale della narrazione dei racconti è l’interpretazione: l’utilità del raccontare storie ed
ascoltarle sta nel momento in cui viene superato lo scenario dell’azione (quadro narrativo entro cui si dipana
la storia) per integrarlo con lo scenario della conoscenza (insieme degli stati interni e dei punti di vista dei
personaggi). Il nocciolo dello storytelling infatti sta nella correlazione che si instaura nella rappresentazione
narrativa della realtà tra i processi di interpretazione, quelli di proiezione e quelli di riflessione. Da qui si
sviluppa la metodologia dello storytelling, di cui l’idea di base nel suo utilizzo è lo sviluppo
dell’apprendimento riflessivo (reflective learning). Essa è definita per fasi nella sua realizzazione:
scelta della finalità e del target, (ossia definizione di quello che si vuole comunicare e a chi);
definizione dei tempi, della disponibilità delle persone coinvolte ed eventuale possibilità di lavoro di
gruppo;
realizzazione (passa prima attraverso la scelta del genere e la stesura della sceneggiatura);
feedback di valutazione da parte dell’audience.
WP 1.3.2 IL DIGITAL STORYTELLING
I Digital Storytelling sono brevi storie di carattere personale o accademico che i digital storytellers
trasformano in video della durata di pochi minuti, aggiungendo la propria voce a immagini, titoli, effetti e
transizioni che scorrono sullo schermo, a volte accompagnati da suoni o musica. La potenzialità di
questo strumento sta nella possibilità che esso offre di coniugare due mondi fra loro molto diversi: da un lato
storie, fiabe, racconti, narrazioni autobiografiche, dall’altro i nuovi media, gli strumenti tecnologici
innovativi, computer, macchine fotografiche, telecamere e software come programmi di editing, di
elaborazione delle immagini o dei suoni e così via. Con lo sviluppo dei media digitali si è assistito ad un
processo di ri-mediatizzazione delle pratiche narrative tradizionali, le quali hanno acquisito una nuova
forza e forma: combinando la logica ipertestuale con la strategia multimediale gli eventi sono trasformati in
parole, immagini, suoni, video. L’impiego dei media nel racconto di storie amplifica le potenzialità
espressive e comunicative della narrazione e fanno riemergere la caratteristica tradizionale delle storie di
collante culturale in grado di creare aggregazione sociale. Il potere aggregante e coinvolgente delle
narrazioni digitali è relazionato alle possibilità offerte dalla rete e dai software sociali che permettono la
creazione di legami tra le persone impegnate in una rete di connessioni globale in cui partecipare
attivamente per la produzione e circolazione di contenuti. Strumenti come web logs, youtube, flicker, social
network, etc., permettono la condivisione da parte degli utenti di storie personali, di interpretazioni
personali della realtà, ma anche di commentare e ampliare tali storie attraverso personali narrazioni.
In questo modo la narrazione attraverso le tecnologie ricrea e rinsalda i legami sociali della
comunità coinvolta e partecipe in una nuova dimensione narrativa per la costruzione di significati e
interpretazioni condivise.
Le narrazioni digitali, come evidenziano Rodriguez Illera e Londono Monroy, hanno avuto una rapida
diffusione che ha riempito ogni spazio della comunicazione, immergendoci in un universo narrativo
che mescola differenti stili e canali comunicativi. Il presupposto di partenza per la produzione di un
digital storytelling è che tutti hanno una storia da raccontare, le tecnologie potenziano il significato della
storia da trasmettere, amplificando la voce del narratore. Da una ricognizione della letteratura di
riferimento emerge che esistono due modelli di digital storytelling: un modello classico, sviluppato dal
Center for Digital Storytelling di Berkley, che prevede la narrazione di storie autobiografiche in formati
digitali attraverso un audio narrazione in prima persona e che presentano una struttura lineare e
chiusa, simile a quella della narrativa tradizionale. L’altro modello, invece, è caratterizzato da una
maggiore interattività, sono narrazioni, cioè, che offrono la possibilità di modificare la storia e cocostruirla divenendo co-autori, in quanto la struttura non è predefinita dall’inizio ed utilizzano, infine,
più elementi mediali (immagini, testi, audio, video, musica) senza l’impiego di un audio narrazione. Le
narrazioni digitali che appartengono al secondo modello rappresentano i digital storytelling di nuova
generazione che utilizzano gli strumenti e sfruttano le potenzialità offerte dalla Web 2.0.
Le “story tales” possono essere definite come “blended telling stories with digital tecnology”. E’ il carattere
blended che ne fa uno strumento didatticamente valido, perché unisce l’abilità della narrazione alle
potenzialità tecnologiche. Leslie Rule definisce il digital storytelling come l'espressione moderna dell'antico
mestiere di cantastorie. Una Digital tale è una breve narrazione (max 5 min) di un evento che integra diversi
linguaggi: alcuni tipici della narrazione altri della sceneggiatura. L'alunno impostando la narrazione e la
sceneggiatura sviluppa alcune abilità: capacità di scrittura e di espressione orale, abilità tecnologiche e
sensibilità artistica. Possono essere utilizzate immagini, fotografie, disegni (o altro materiale scannerizzabile)
video, musica, la voce o effetti sonori. Gli elementi essenziali non sono che una semplificazione, un punto da
dove cominciare perché ci sono infinite variazioni per costruire una narrazione digitale. Affinché uno
storytelling possa dirsi efficace è necessario che la narrazione abbia una struttura interna familiare a chi la
vedrà, in cui si possa identificare e in cui eventi e personaggi assumano un ruolo chiaro; è poi essenziale la
presenza di fattori che la rendano personale e possano suscitare delle emozioni. Joe Lambert a tal proposito
individua sette elementi che aiutano in un approccio personale allo storytelling: punto di vista personale, una
struttura della narrazione che sorprenda domande e fornendo risposte non banali, inserimento di contenuti
emotivi e coinvolgenti, un’efficace economia della narrazione (si può dire molto con poco), un ritmo adeguato
alle modalità narrative. La storia non deve necessariamente avere un lieto fine, invece elemento importante
e che accresce l’attenzione nell’utente è la percezione di autenticità.
Jason Ohler, molto incentrato sull’uso educativo delle digital story tales, pone l’accento sulla narrazione più
che sulle nuove tecnologie: “una buona narrazione farà una buona digital story tell e non il contrario”.
Sostanzialmente Jason Ohler utilizza due approcci. Il primo, “computer based” consiste nel basare la
creazione di una storia principalmente attraverso il computer (immagine, musica, usando programmi come
iMovie o Moviemaker). Nell'altro approccio, chiamato “sfondo verde” la storia viene narrata in modo
tradizionale filmando il protagonista con uno sfondo neutro per poi integrarlo con i multimedia. Questa
seconda soluzione facilita la didattica perché l’alunno fa un’ulteriore riflessione sull’uso delle nuove
tecnologie. Alcune tecniche, affini alle Digital storytelling hanno in comune alcuni elementi. I video annotation
prevedono l’interattività nel filmato o nelle immagini, cioè è possibile modificare il contenuto digitale creato
dall’autore. I photolanguage: sono raccolti in dossier fotografici utilizzati a scopi didattici o di orientamento,
ma non prevedono la voce narrante o le riprese. Il Digital storytelling è un metodo a sé stante che utilizza
alcune tecniche già note come la narrazione e la sceneggiatura unendole con creatività e autenticità.
Le comunità di Digital tellers “sono le memorie della comunità, non la storia, non un archivio, non un liste di
autorità ma una memoria vivente, la coscienza dell’identità collettiva intrecciata in centinaio di storie. Per
parlare delle comunità è necessario parlare dei centri di formazione, essi stessi comunità di Digital
Storytellers. Uno dei centri più accreditati a livello mondiale è il Center for Digital Storytelling negli Stati Uniti
già citato sopra. Diretto da Joe Lambert con la collaborazione di Nina Mullen, ha organizzato decine di
workshop, lavorando con molte comunità di adolescenti e di adulti intorno a un tema e una comunità. Un
attività interessante del Centro sono i casi di studio dove vengono raccolte Digital storytells locale e orali su
svariati temi come l'organizzazione sindacale, la prevenzione della violenza, l'handicap, i servizi sociali e
salute ecc. E’ prevista una sezione dedicata all’educazione e all’uso delle Digital storytells nella didattica
come ad esempio nell'insegnamento della lingua oppure l'educazione artistica. Un esempio è la comunità
nata intorno alla Digital storytelling Iniziative del Public broadcasting for Northerm California (KQED). Più di
500 studenti delle scuole superiori partecipano al progetto “Coming California” sull’immigrazione in
California. Quest’anno, il progetto include anche storie sul mito di sentirsi o essere della California. Il centro
prevede altresì un workshop per gli insegnanti e un follow up nella scuola. Sostanzialmente, le Digital
Storytells hanno la funzione di aggregare comunità. Un buon esempio è la comunità di volontari che si
“raccontano” attraverso le digital story tellers.
L’Associazione Community Service Volunteers (CVS) che le rappresenta, è una delle più importanti
associazioni di volontari in UK. Un altro punto di riferimento negli stati Uniti, è la Digital Storytelling
Association che ha eredito del lavoro del fondatore, artista e cantastorie dei Digital storytelling Dana Winslow
Atchley Negli anni ’80, ha condotto molti workshop, realizzando delle story tales anche per grande
compagnie delle Usa come Coca Cola che si racconta attraverso digital story tale. Anche in Europa si sono
sviluppate delle correnti. In Inghilterra Daniel Meadows circa 15 anni fa, ha creato Capture Wales and Telling
Lives, il primo nucleo della BBC dedicato alle Digital story tales. Basandosi sulla propria esperienza di
fotografo/documentalista ha anche un sito personale PhotoBus An adventure in documentary Photography.
Non è un caso che le narrazioni digitali siano nate negli Stati uniti dove costruire il proprio percorso di
apprendimento è la norma, dove il docente è visto come uno allenatore che affianca l’alunno (Sclavi, 2003).
Le materie disciplinari che potrebbero sviluppare il metodo sono molte. Il valore aggiunto delle narrazioni
digitali sono molto chiare nel sito della Carnegie Mellon University. Mostra un frammento di una lezione di
chimica in 3 versioni, la prima tradizionale, la seconda con l'immagine e la terza integrate in una narrazione
digitale. Usare le nuove tecnologie in modo creativo permetterebbe all’alunno e al docente di costruire il
materiale didattico insieme.
Le narrazioni digitali possono essere intese come documentazione visuale, memoria visiva di un unico
soggetto, l'alunno, di una classe, di un momento didattico ma possono rappresentare anche le memoria e le
conoscenze di un'intera scuola. Nell’ottica dell’autonomia scolastica potrebbero anche assolvere ad una
funzione di promozione dell’istituto dove non vengano solo presentati curricoli e POF ma anche,
qualcos’altro, quello che il knowledge management definisce la conoscenza informale. Anche alcuni progetti
europei come il progetto PENCIL, nell'ambito scientifico, di cui INDIRE è partner, cercano di cogliere la
conoscenza informale per trasformarla in risorse digitali. Ad esempio, le narrazioni digitali degli alunni
potrebbero dare uno spaccato significativo della vita scolastica informale, dello stato emozionale
dell’ambiente scuola. Le narrazioni digitali possono potenzialmente costruire comunità tra scuole, nazionali e
internazionali a seconda degli interessi specifici. L’esperienza condotta all’INDIRE insieme ad alcune IRRE
nell’ambito del progetto Primule va in questo senso, anche se non si tratta di Digital storytelling ma di una
documentazione molto più ampia che permette attraverso 3 aree (vivi/trasferisci/rifletti l’esperienza) la
rappresentazione di un’esperienza didattica. Ecco che la scuola attraverso i Digital storytelling potrà
raccontarsi e ritrovare tutti gli elementi della trama narrativa: il tempo/i personaggi/gli alunni/il contesto/il
nesso causale.
Un altro lavoro, che dà un taglio utile per documentare l’attività della scuola è quello di Helen C. Barrett, che
utilizza le Digital tales per comporre il portfolio. Se visionate il seguente esempio, l’insegnante intervista
Vittoria, una bambina di circa 6 anni, che frequenta la prima elementare. Il portfolio elettronico/digital story
tales si propone di evidenziare le sue abilità di base (lettura scrittura e calcolo) attraverso semplici domande
come: Mi piace ...perché…ho imparato. Interessante è la meta-riflessione di Tori, ormai in prima elementare,
che ripercorre, sempre insieme all’insegnante, il suo percorso alla scuola materna.
Per la produzione del digital storytelling bisogna possedere e/o acquisire determinate competenze e
conoscenze che riguardano le modalità tradizionali di scrittura e narrazione, capacità creative,
competenze tecnologiche e di produzione mediale e capacità di sviluppo di progetti. I digital
storytelling possono essere un momento di apprendimento e di alfabetizzazione tecnologica, di
sviluppo di capacità di sintesi, di ricerca e organizzative più stimolanti e creative delle metodologie
tradizionali. La metodologia dello storytelling è ampiamente impiegata nei contesti formativi ed
educativi come strategia di alfabetizzazione alla lettura e alla scrittura in quanto oltre al semplice
dominio dei segni grafici della scrittura, l’uso delle narrazioni digitali favorisce l’acquisizione delle
regole per la costruzione del testo e quindi anche la gestione dei processi delle attività cognitive.
A tale riguardo, il presente progetto si inserisce nel contesto italiano caratterizzato da un forte processo di
digitalizzazione dei contesti educativi, scolastici e formativi. Tale processo è mosso dalla necessità di
creare delle infrastrutture adeguate, attraverso l’implementazione nel sistema scolastico italiano della
strumentazione tecnologica e della connessione in rete, che permettano di rispondere alle esigenze
intese in termini di sviluppo di competenze emergenti dalla società dell’informazione. La
Recommendation of the European Parliament and of the Council del 18 dicembre del 2006, stabilisce che
il compito dell’educazione e della formazione è di offrire ai giovani la possibilità di sviluppare e
acquisire le competenze chiave al fine di consentire un maggiore adattamento ai cambi sociali e
renderli cittadini attivi (2006/962/EC). Tra le otto competenze individuate dalla Raccomandazione Europea,
la “competenza digitale” fa riferimento allo sviluppo di abilità tecniche, del pensiero critico, della creatività
nella produzione di contenuti, di capacità espressive attraverso nuovi linguaggi e uso degli strumenti
in modo innovativo. Il Ministero della Pubblica Istruzione italiana ha per questo motivo avviato differenti
programmi per lo sviluppo delle tecnologie didattiche al fine di promuovere e favorire l’educazione
degli studenti alla multimedialità, l’introduzione di questa nella didattica per migliorare i processi di
apprendimento-insegnamento.
In linea con il programma di introduzione delle ICT nelle scuole e lo sviluppo di competenze digitali
è il Piano di intervento “Scuola Digitale” promosso dal MIUR e dall’Agenzia per lo Sviluppo
dell’Autonomia Scolastica. L’obiettivo è di sviluppare e potenziare l’innovazione didattica attraverso l’uso
delle tecnologie informatiche. Il progetto di ricerca si svolgerà presso alcune classi delle scuole medie
inferiori della Regione Puglia che partecipano al progetto Cl@ssi 2.0, progetto facente parte del Piano
di Intervento “Scuola Digitale”. I digital storytelling, utilizzati come metodologia didattica per attività
extra-scolastiche, offriranno una opportunità di media literacy più stimolante e coinvolgente rispetto ad
altre metodologie didattiche, ma soprattutto immergono gli studenti in un ambiente tecnologico a loro
noto che facilita l’acquisizione di competenze e abilità tecnologiche e l’uso critico dei media. In tal senso la
metodologia del digital storytelling, attraverso la manipolazione di più codici e formati della narrazione orale,
scritta, visuale, permette l’apprendimento e lo sviluppo di competenze non solo alfabetiche ma anche
compositive/espressive, tecnologiche e critiche.
La fase di ideazione e progettazione della storia in quanto narrazione composta anche da elementi
filmici, prevede una iniziale rappresentazione visuale attraverso gli strumenti del visual portrait e dello
storyboard. Il visual portrait o storymap è uno strumento che permette di descrivere la storia nella
sua struttura, cioè gli intrecci, gli eventi, gli elementi dinamici che la caratterizzano al fine di creare
una sorta di mappa emozionale della narrazione . La costruzione dello storyboard consente di pianificare
la storia da un punto di vista più tecnico, ovvero di stabilire il contenuto della sceneggiatura e gli
elementi e i codici comunicativi che si utilizzeranno, attraverso il disegno delle scene e degli eventi.
Entrambi gli strumenti facilitano la visualizzazione dei componenti della narrazione, loro progressione,
sulla base dei quali è possibile selezionare e raccogliere le immagini, la musica, l’audio, etc., più utili per
lo sviluppo della propria storia. A seguito di questa fase preparatoria si ha la realizzazione della narrazione
digitale attraverso il montaggio dei differenti formati scelti e selezionati da ogni utente.
WP 1.3.3 RIFERIMENTI BIBLIOGRAFICI
• Andreocci B., Potenzialità didattiche dei filmati digitali interattivi in ambienti di formazione in rete in
Formare Newsletter, n. 47 ottobre/novembre 2006
• Benton, P. The power of the digital storytelling in the classroom, Spiral Notebook, april 2006
http://www.edutopia.org/community/spiralnotebook/?p=33
• Banaszewski, T. Digital storytelling finds its place in the classroom, MultiMedia Schools,
January/febbruary 2002
• Joe
Lambert:
Digital
Storytelling:
http://www.storycenter.org/book.html
Capturing
Lives,
Creating
Community
• Corrado Petrucco, Marina De Rossi: Narrare con il digital storytelling a scuola e nelle organizzazioni,
Roma, Carocci editore, 2009
• Biondi, G., La documentazione come sistema di rappresentazione delle conoscenze, in Goldtrain, 2005
http://www.bdp.it/lucabas/lookmyweb_2_file///Biondi_rappresentazioni_conoscenze.pdf
• Lambert J., Digital storytelling cookkbook and travelling companion(version 4.0), may 2003
• Kajder, S., Digital Images in the language arts classroom, Learning & leading with technology, v. 31, n.
8, 2004
• New, J., How To: Use Digital Storytelling in Your Classroom, EdutopiaMagazine, dic 2005
• Ohler, J., Traditional Stories go green, Storytelling magazine, 2007
• Ohler, J., Digital stories in the classroom, 2007
• Pearson Hathorn P., Using Digital storytelling as a literacy toll for the Inner City Middle school Youth,
The charter schools ressource journal, v. 1, n. 1, winter 2005
• Pennac, D., Come un romanzo, Feltrinelli, 2006
• Powel B. T., Native/American Digital/storytelling situating the Cherokee oral tradition within American
literary history
in Literature Compass 4/1 (2007), pp. 1-23, http://www.blackwellsynergy.com/doi/pdf/10.1111/j.1741-4113.2006.00376.x?cookieSet=1
• Raieli, R., Il visual retrieval, AIDAinformazioni, n. 19, 2001
• Sclavi, M., Arte di ascoltare e mondi possibili, Mondadori, Milano, 2003
• Standley M., Digital Storytelling: using new technology and the power of stories to help our students
learn- and teach, cable in the classroom, june 2003
• Standley M., Digital stroytelling with iMovie/Powerpoint. Vision Technology in Education, 2004
• Federico Batini, Simone Giusti (a cura di) Le storie siamo noi. Gestire le scelte e costruire la propria vita
con le narrazioni, Napoli, Liguori editore, 2009
• Federico Batini, Andrea Fontana, Storytelling Kit. 101 esercizi di narrazione d'impresa, Milano, Etas,
2010
• Claudio Cortese, L'organizzazione si racconta, Milano, Guerini, 2000
• Duccio Demetrio, Raccontarsi. L'autobiografia come cura di sé, Milano, Raffaello Cortina editore, 1995
• Andrea Fontana, Manuale di Storytelling. Raccontare con efficacia prodotti, marchi e identità d'impresa,
Milano, Etas, 2009
• Andrea Fontana, Story-selling, Milano, Etas, 2010
• Andrea Fontana, Gianluca Sgreva, Il Ponte narrativo. Le scienze della narrazione per le leadership
politiche contemporanee Milano, Lupetti, 2011
• Corrado Petrucco, Marina De Rossi: Narrare con il digital storytelling a scuola e nelle organizzazioni,
Roma, Carocci editore, 2009
• Christian Salmon, "Storytelling. La Fabbrica delle Storie".
• Karin B.Evans and Dennis Metzger,Storytelling, 2000, ASTD.
• Gabiele Qualizza, Lo storytelling nella comunicazione d'impresa, Rivista di scienze della comunicazione
- A.I (2009) n.2 (luglio-dicembre)
• Barbara Quacquarelli, Francesco Paoletti, Qual è il contributo dello storytelling all’interno della vita delle
organizzazioni e delle loro attività?, Sviluppo & Organizzazione, n.220, Marzo/Aprile 2007
• Andrea Fontana, Storytelling management: Narratologia, organizzazioni e economie del simbolico,
Sviluppo & Organizzazione, n.220, Marzo/Aprile 2007
• Francesco Varanini, L'organizzazione come rete di storie e lo storytelling come furto, Sviluppo &
Organizzazione, n.220, Marzo/Aprile 2007
• Enrico Viceconte, Contar Storie, Persone e Conoscenze n.54, 2010
WP 1.4 Specifiche Funzionali del sistema Vocs.
In questa sezione vengono descritti i concetti e le funzionalità del sistema per la creazione e la fruizione di
storie interattive per il progetto Vocs.
Le specifiche funzionali, per quanto riguarda la parte di costruzione di storie con contenuti multimediali, e'
stata sviluppata da Digital Video con la collaborazione del dipartimento Infocom e del Conservatorio di Roma
Santa Cecilia
Nel corso del capitolo verranno inserite alcune immagini di esempio, allo scopo di dare un’idea di come
apparirà visivamente l’interfaccia del sistema. Tali immagini ovviamente non vogliono rappresentare l’
interfaccia definitiva del software, ma solo dare un’indicazione di massima, per rendere i concetti esposti più
chiari.
Il capitolo è suddiviso in paragrafi. In ognuno di essi viene illustrata una delle diverse entità che
compongono la storia interattiva (Story, Scene, Plot, etc.) , e viene brevemente descritto il componente
software (l’Editor) che la crea e la manipola.
Per la terminologia di tali entità si è scelta la lingua inglese. Riteniamo che i termini in inglese siano più
espressivi e concisi dei corrispondenti italiani: useremo ad esempio i termini ‘Cast’ e ‘Plot’ invece di
‘Interpreti’ e ‘Trama’.
1.1WP 1.4.1 La Story e lo Story Editor
La Story e’ l’oggetto che rappresenta l’intera storia interattiva. E’ l’unico oggetto che può essere salvato e
caricato da file, e a tal fine verrà creato un formato file proprietario. (un file che contiene la storia potrebbe
chiamarsi ad esempio : visita_museo.vox). Il file di storia potrebbe essere strutturato in modo da far
riferimento ad altri file che contengono i vari componenti, come ad esempio le scene, i behaviour editor, i
plot. Dal punto di vista dell’utente tutto ciò sarà reso trasparente, dando accesso al solo file principale. È
ovviamente possibile riprodurre (playback) la storia, che potrà avvenire a tutto schermo o su una finestra in
due differenti modalità: a schermo intero o in finestra.
La Story è definita da un insieme di Scene, dia uno Story Cast, e da un Entry Point.
Una Scene é un’unità narrativa della storia: l’autore può strutturare la storia dividendola in scene Scene
seguendo diversi criteri. Tipicamente, il criterio più naturale è una organizzazione delle scene Scene
secondo ‘location’: se la storia si sviluppa in diverse ambientazioni, ognuna di esse può essere
rappresentata da una diversa Scene.
L’autore può manipolare la storia tramite lo Story Editor, che mostra la struttura delle Scene secondo una
rappresentazione a grafo. In figura un esempio di tale rappresentazione:
Ogni ‘nodo’ del grafo (i rettangoli in figura) rappresenta una Scene, e ogni ‘arco’ (le linee che congiungono i
diversi nodi) tra due nodi indica che esiste una transizione tra due sceneScene: cioè che durante il playback
della storia, è possibile passare da una scena all’altra.
Ogni nodo mostrerà un’una immagine rappresentativa della scena in questione.
Nello Story Editor è possibile creare, cancellare, duplicare e organizzare sullo schermo i diversi nodi. Gli
archi invece vengono creati automaticamente dal sistema in base ai Plot associati alle sceneScene, come
vedremo in seguito. E’ possibile definire anche l’EntryPoint della Story, che è rappresenta la scena che viene
eseguita all’inizio del playback della storia, nonché ovviamente il nome della scena.
Lo Story Cast é l’insieme dei contenuti (Content) di cui é composta la storia.
Tali Content possono essere suddivisi in diverse categorie: immagini statiche, filmati, personaggi animati
(contenuti che sono in grado di effettuare delle azioni), clip audio, clip video, e cosi via.
Nel software esisterà un componente grafico, chiamato Story Browser, che è essenzialmente un browser ad
icone suddiviso nelle varie categorie suddette, e che permette di accedere velocemente alle proprietà dei
vari oggetti, di selezionare un oggetto per inserirlo in all’interno di una uno Stage Scene o nel caso di
caratteri animati, ad accedere all’’Editor per definire il ‘behaviour’ dei caratteri animati (vedi prossimi
paragrafi). Tramite lo Story Browser e’ possibile anche selezionare velocemente a fini di editing i diversi
componenti all’interno dei rispettivi editor.
E’ possibile popolare lo Story Cast importando i vari contenuti dal file browser del sistema operativo. Nota
che l’autore non é tenuto a popolare esplicitamente questo lo Story Cast: come vedremo successivamente,
esiste anche lo Scene Cast, e tutto ciò che viene aggiunto a quest’ultimo apparirà automaticamente anche
nello Story Cast.
1.2WP 1.4.2 La Scene
Come già accennato, una Scene è un elemento narrativo della storia.
Ad ogni Scene è associato uno Scene Cast, uno Stage, e uno o piú un Plot.La principale
funzione di una Scene è quella di raggruppare logicamente Scene Cast, Plot e Stage.
Lo Scene Cast è del tutto analogo allo Story cast Cast (anche come interfaccia grafica), ma contiene solo i
contenuti relativi alla scena a cui è associato. Aggiungendo un elemento allo Scene Cast, questo, se non già
presente, viene anche aggiunto allo Story Cast.
Lo Stage è la struttura della scena dal punto di vista visivo: rappresenta cioè il modo in cui i vari contenuti
visivi sono composti e posizionati sulla scena durante il playback.
I Plot sono l’insieme di istruzioni (come si direbbe in linguaggio informatico, gli ‘script’) che permettono lo
svolgimento della storia interattiva.
Vediamo ora in dettaglio i concetti di Stage e Plot, e i loro relativi editor.
WP 1.4.3 Lo Stage e lo Stage Editor.
Lo Stage è quindi ciò che appare durante il playback della storia, e lo Stage Editor è il componente che
permette di creare e manipolare tali Stage, scegliendo quali contenuti utilizzare del Cast, componendo
l’inquadratura, e definendo alcune grandezze, come la camera.
In figura un esempio di come potrebbe apparire uno Stage Editor.
In questo editor è possibile selezionare dal cast Cast gli elementi da includere nello Stage, come i fondali, i
personaggi, gli elementi scenici, e di effettuare la loro composizione geometrica, tramite movimenti,
scalature, rotazioni, etc.
Per l’aggiunta degli elementi visuali sullo stage è possibile caricarli tramite classica interfaccia di file browser
o più semplicemente tramite drag&drop dal sistema operativo.
Una volta caricati i contenuti, è possibile assegnare loro un nome.
E’ altresì possibile caricare piú volte lo stesso contenuto, assegnando ad esse un nome diverso. In questo
modo, due diversi contents visivamente identici possono essere utilizzati come due entità completamente
distinte all’interno della scena.
È inoltre possibile definire l’ordine di sovrapposizione dei vari livelli, nonché oggetti speciali come
inquadrature e aree sensibili. A tal fine e’ possibile creare un oggetto speciale nello stage, chiamato HotBox.
Un HotBox e’ un area rettangolare, a cui si associa un nome, che puo’ essere posizionata sullo schermo. Le
HotBox hanno fondamentalmente 3 diversi usi:
1) HotBox come Special area dello stage: Se si vuole eseguire qualche azione quando un personaggio
raggiunge un certo punto dello stage, oppure se l’utente clicca con il mouse in un punto dello stage,
l’HotBox permette di definire tali punti sensibili, e di riferirsi ad essi tramite il nome dell’HotBox;
2) HotBox come inquadratura per i movimenti di camera: se si vogliono effettuare zoom su alcune parti
dello stage, o effettuare carrellate, etc., l’HotBox permette di definire tali inquadrature e riferirsi ad
esse tramite il loro nome;
3) HotBox come frame per il playback di un videoclip: se si vuole visualizzare un clip in una porzione
dello stage, tramite una HotBox si può definire dove eseguire tale playback.
Una volta definita una HotBox e assegnata ad essa un nome, è possibile definire le azione descritte
all’interno del plot riferendosi ad esso tramite il suo nome.
La composizione che si effettua nello Stage Editor e’ il punto di partenza per il playback della scenaScene.
Durante tale playback, in base al Plot in esecuzione (vedi paragrafo successivo), la composizione messa a
punto nello sStage Editor sarà modificata dalle azioni specificate e dall’interazione con l’utente. Ovviamente i
vari contents dello Scene l cCast della scena non dovranno essere tutti presenti “on stage” all’inizio, ma
potranno entrare o uscire a seconda dello svolgersi degli eventi della storia. Inoltre, è possibile definire un
content come ‘invisibile’ sullo stage, per farlo apparire al momento opportuno tramite un comando nel plot.
Ovviamente un content può anche essere reso invisibile durante lo svolgimento della scena.
Nello Stage Editor è anche possibile effettuare un Preview: cioè effettuare un playback della sola scena
stessa, per dare modo all’autore della storia di verificare in corso di sviluppo il suo funzionamento.
Per effettuare il playback dell’intera storia, l’entry point nel software e’ sempre attraverso lo stage editor; da
qui, tramite una opportuna interfaccia di tipo “player console”, è possibile lanciare l’intera storia , anche in
modalità full screen.
WP 1.4.4 I Plot e il Plot Editor.
Come abbiamo accennato, ad ogni scena è associato un Plot.
Il pPlot è l’insieme di istruzioni, strutturate in modo anche complesso, che permette di animare in modo
interattivo la scena stessa. Dal punto di vista logico eè funzionale, esso si può definire la ‘programmazione'
della storia, analogamente a quello che accade, per esempio in Macromedia Flash, tramite l’utilizzo di
linguaggi di script come ActionScript.
Nel sistema Vocs verranno utilizzati paradigmi e modalità di ‘programmazione ‘visuale’, evitando qualsiasi
tipo di scrittura esplicita di codice di programmazione. In pratica, le varie azioni saranno assemblate
utilizzando il concetto di blocco funzionale (Block):
un Block è un elemento di interfaccia grafica che esegue un compito elementare (ad esempio: sposta il
personaggio ‘Bambino’ alla posizione (x, y), suona la clip audio ‘tromba’, togli il personaggio ‘Coniglio’ dallo
stage, etc.).
Tali Block vengono quindi composti tra loro, in modo graficamente intuitivo, per creare delle sequenze di
istruzioni.
Nella figura, un esempio di interfaccia grafica
SCRATCH)
con l’utilizzo di Block (tratto dal software open source
In questo approccio, i Block vengono ‘incastrati’ tra loro per formare delle sequenze complesse di istruzioni.
Il paradigma di interfaccia grafico ad “incastro” permette di realizzare una sintassi complessa e consistente
dello scripting del plot; tale modalità permette di collegare tra loro le istruzioni solo se ciò e’ permesso dalla
sintassi, mediante l’utilizzo del concetto intuitivo dei blocchi ad incastri e senza prevedere un training
dell’autore per le regole di scrittura delle action
Ogni Plot della scena può essere composto da un certo numero di questi insiemi di blocchi funzionali.
Chiamiamo il singolo insieme Action.
I Block possono essere divisi in categorie, in base alla loro tipologia di comportamento. Ecco a mo’ di
esempioSeguono alcuni esempi di Block divisi in categorie.
Event Block:
sono blocchi che possono essere posti solo all’inizio di una Action. Essi fanno si che la Action venga
eseguita quando accade un certo evento. Esempi di eventi possono essere: la scena inizia, l’utente ha
cliccato con il mouse sopra il personaggio ‘Coniglio’, l’utente ha chiesto con un comando vocale di sentire il
suono della tromba, sono stati uccisi 100 marziani, etc.
Movement Block:
sono blocchi che muovono i contenuti sullo stage. Esempi: sposta “Bambino” nella posizione (x, y), Muovi
“Coniglio” di x pixels verso sinistra, Mostra sullo stage Stage personaggio ‘Cappellaio” in posizione x,y, etc.
Sound Block:
permettono di manipolare il suono. Esempi: suona la clip “Tromba” dal secondo x al secondo Y, interrompi
tutti suoni, parla dicendo “ciao sono il coniglio”, etc.
Video Block:
permettono di visualizzare dei videoclip sulla scena. Esempi: esegui la clip “vita di corte”, nell’HotBox
“schermo”, interrompi tutti i video, etc.
Control Block:
permettono di strutturare le Action. Esempi: ripeti <blocks> per 10 volte, se <condizione> allora esegui
<blocks>, vai a scena “Nel Bosco delle fate”. (Quest’ultimo esempio di Control Block, crea automaticamente
un collegamento nello Story Editor tra le la scena attuale e la scena chiamata “Nel Bosco delle fate”.)
Altri due concetti fondamentali per lo sviluppo dei Plot sono gli Attribute e gli State.
Gli Attribute sono delle entità che memorizzano dei valori.
Ad esempio in un videogioco a del generela Space Invaders, esisteráesisterà l’attributo ‘marziani uccisi’, che
memorizza un numero intero.
Esisteranno dei Block per manipolare gli attributi. Ad esempio: assegna il valore 100 a ‘marziani uccisi’,
incrementa di 1 il valore di ‘marziani uccisi’, se ‘marziani uccisi’ e’ uguale a 100, allora visualizza “Hai vinto!”.
Nell’interfaccia grafica del Plot Editor, sarà possibile visualizzare tutti gli attributi del plot attuale, e crearne di
nuovi.
Un attributo può esistere anche a livello globale, e cioè comune e accessibile da tutte le scene della
StoriaStory.
Gli State memorizzano lo stato attuale di una scena. Durante il playback di una scena esisterà sempre un
Current State.
Ad esempio, se in una scena in una cucina il personaggio ‘bambino’ deve rubare la marmellata su
comando vocale dell’utente, il comportamento del ‘bambino’ al comando vocale ‘prendi la marmellata!’
vogliamo che cambi a seconda se la porta della cucina e’ aperta o chiusa. Nel secondo caso il bambino
prima chiude la porta e poi prende il vasetto. In una situazione del genere, nella scena esisteranno due stati
chiamati ‘porta aperta’, e ‘porta chiusa’. La Action che risponde all’evento “prendi la marmellata” sarà quindi
diversa a seconda dello stato attuale della scena.
Ovviamente, in modo analogo agli Attribute, esisteranno dei Block speciali per manipolare lo State della
ScenaScene. Esempio: cambia State in ‘porta chiusa’, se State e’ uguale a ‘porta aperta’ allora esegui action
‘chiudi porta’, etc.
Lo State può essere visto come un caso speciale di attributo.
L’interfaccia grafica del Plot editor permette di creare e manipolare le action che costituiscono il plot.
Esisterà un “Block Catalog” che visualizza tutti i tipi di blocks disponibili. Per l’aggiunta dei blocks ad una
action sarà sufficiente effettuare un drag&drop dal Catalog al plot Editor, agganciandoli alle action
opportune. Sarà possibile, sempre tramite drag&drop, muovere o copiare blocchi e gruppi di blocchi da
un’azione ad un'altra, oltre ovviamente a cancellare blocchi esistenti.
WP 1.4.5 I Behaviour ed il Behaviour Editor.
I Behaviour sono degli insiemi di istruzioni associate ad un singolo Content presente nel Cast (tipicamente,
tale Content potrebbe essere l’insieme di immagini che compongono l’animazione di un personaggio della
storia) per rendere tale contenuto animabile in maniera interattiva. In pratica, un Behaviour associato ad un
personaggio rende il personaggio una sorta di ‘automa’ in grado di eseguire dei comandi che provengono
dai plot delle scene. Ad esempio si potrebbe creare un Behaviour del personaggio ‘bambino’ in modo tale
che questo sia in grado di eseguire una serie di comandi, come: afferra il vasetto di marmellata, aspetta
impaziente, dí ‘io sono un monello!’, etc.
Il concetto di Behaviour è simile a quello di Plot delle Scene. La differenza principale é che il Behaviour è
associato ad un Content, mentre il Plot è relativo ad una Scene. Anche il Behaviour Editor è simile al Plot
Editor; differisce da quest’ultimo nel tipo di Block utilizzabili, che sono in parte diversi nei due casi. Ad
esempio, Nella creazione di un Behaviour potrà esserci un Movement Block del tipo “esegui i frames dal 12
al 35” in riferimento alle immagini animate del Content associato al Behaviour in questione, oppure un Event
Block “esegui comando ‘afferra la marmellata ’).
Anche per i Behaviour esiste il concetto di Attribute e State. Ad esempio, nell’eseguire il comando “afferra la
marmellata”, l’animazione da eseguire dipende dallo stato del personaggio: se e’ seduto su una sedia, se
non e’ presente in scena, etc. Nel caso lo stato del personaggio sia ‘Seduto’, bisogna eseguire una Action
che fa alzare il bambino dalla sedia, e cosi via.
WP 1.4.6 Struttura dell’interfaccia grafica di Vocs
La struttura dell’interfaccia grafica del software dovrà permettere di organizzare i vari componenti in modo
chiaro e permettendo l’accesso ai vari editor presenti in modo veloce e funzionale.
Inoltre, i componenti (i contents, le scene, i plot…) sono condivisi da diversi editor, quindi dovrà esserci un
meccanismo centralizzato che permetta di selezionare gli oggetti su cui si vuole lavorare indipendentemente
dall’editor in cui ci si trova al momento.
I componenti principali di Vocs sono 5:
-
Lo Story Browser
-
Lo Scene Editor
-
Il Character Editor
-
Lo Stage Editor
-
Il Plot Editor
Il suddetto meccanismo di selezione e navigazione centralizzato di cui sopra verrà realizzato mediante lo
Story browser, tramite il quale sarà possibile selezionare i vari componenti. A tal fine, nell’interfaccia
globale lo Story Browser sarà sempre presente e visibile sullo schermo.
Gli altri 4 editor invece, saranno organizzati in una modalità a tabbed windows, per permettere lo switch
veloce tra l’uno e l’altro.
Nell’immagine seguente, viene mostrato tale organizzazione dei componenti del software, in una
versione preliminare di studio dell'interfaccia. Sulla destra, e’ presente lo story browser, strutturato ad
albero; il primo livello dell’albero rappresenta le varie scene, e il secondo i contenuti di ogni scena. Le
icone associate ai contenuti illustrano il tipo di contenuto (carattere animato, elemento di scena, suono,
video, HotBox). Per le scene, i le icone mostrano una immagine thumbnail del contenuto dello stage. I
quattro editor sono selezionabili tramite i tab in alto. Ogni editor avrà una sua toolbar con un set di icone
per la manipolazione dei contenuti.
WP 1.4.7 Il Vocs Player.
Il software Vocs verr’ realizzato in due versioni. La prima, quella appena descritta, e’ una versione completa
di tutte le funzionalità per l’authoring delle storie. La seconda è una versioenslaled-down che permette il solo
playback delle storie realizzate. Questa versione, denominata ‘Vocs Player’, permetterá esclusivamente il
caricamento di una storia e la sua esecuzione, sia in modalitá windowed che full screen. Nella figura,
l’aspetto della GUI per il player Vocs.
WP 1.4.8 Struttura della Story
Riportiamo nei 2 diagrammi seguenti la struttura della Story cosi come é stata descritta nel documento:
STORY
attributes
State
SCENE
Attributes
SCENE
SCENE
STAGE
ACTION
PLOT
ACTION
CAST
ACTION
CAST
CONTENT
CONTENT
CONTENT
BEHAVIOUR
ACTION
ACTION
ACTION
WP1.5 specifiche funzionali dell'Integrazione dei moduli vocali con l' ambiente di sviluppo della
“Story” del software
L’ambiente di sviluppo VOCS prevede che ad ogni azione eseguita dal player dello storyteller venga inviato
un feedback a Speaky che interagisce con l’utente in maniera appropriata con eventuali prompt vocali.
Il Player dello Storyteller reagisce ad usa serie di eventi definiti, in fase di progettazione, dall’autore della
“Story”. Ad ogni evento corrisponde un insieme di azioni che il player eseguirà a seguito dell’evento
specifico. L’autore della “Story” potrà, opzionalmente, associare ad ogni evento oppure ad ogni azione, un
insieme di comandi vocali che scateneranno i medesimi eventi o le medesime azioni, ma nella modalità di
interazione vocale .
Le azioni associate ai comandi vocali, o alle diverse interazioni tra utente e “Story” (tramite il player), sono le
medesime. In aggiunta un comando vocale potrà sollevare anche più azioni contemporaneamente.
WP1.5.1 Interfaccia per Input e Output Vocale
L’ambiente di sviluppo della “Story” verrà corredato con una interfaccia per l’inserimento degli elementi
Vocali. Tali elementi sono di due tipi differenti, input vocali (“Speaky Speech Input”) e output vocali (“Speaky
Speech Output”);
Speaky Speech Input (SSI)
Più frasi per ogni evento/azione (Control Block):
Gli input vocali sono insiemi di frasi alle quali è assegnato un significato specifico corrispondente ad un
evento oppure ad una azione predefinita all’interno dei blocchi evento o blocchi di controllo/azioni dello script
(plot) della “Story”. Ogni evento o azione avrà quindi una o più frasi (comandi vocali) che lo scatenano.
Comandi vocali duplicati: (Ambiguità)
Ogni frase potrà essere duplicata per altri eventi o azioni relativi a differenti script all’interno della “Story” (ad
es. in scene diverse tra loro). Per risolvere l’ambiguità il player vocale invierà di volta in volta a Speaky lo
stato in cui si trova (es. in quale scena o gruppo di scene, o stato specifico all’interno della scena, ecc.).
Questa informazione permetterà a Speaky di inviare il codice corretto, dell’evento o dell’azione, al player
rispetto al contesto in cui si trova. Questa attività di disambiguazione la definiamo come “Sistema automatico
di disambiguazione”.
In alternativa questo compito potrà essere demandato al player che scatena l’evento o esegue l’azione
corrispondente in base al contesto in cui si trova.
Il sistema di sviluppo controlla i comandi vocali inseriti durante la definizione della “Story” ed evidenzia
all’autore le eventuali anomalie e duplicati. L’autore potrà quindi stabilire se risolvere i duplicati con frasi
differenti oppure lasciare al “sistema automatico di disambiguazione” tale compito.
Speaky Speech Output (SSO)
Feedback o Prompt vocali: Casualità, Prosodia ed Emozione.
L’autore della “Story” ha la possibilità di definire, per ogni azione effettuata dal player, durante l’interazione
con l’utente, una serie di feedback vocali o frasi che verranno erogate da Speaky. In particolare ogni
feedback vocale verrà associato ad un codice specifico. Ad ogni codice corrispondono una o più frasi che
Speaky erogherà in maniera casuale per dare l’impressione della variabilità con cui risponde alle medesime
azioni all’interno della “Story”.
I feedback vocali possono essere corredati da effetti prosodici (tag di prosodia) o espressivi (tag emozionali)
in maniera da rendere emozionante ed accattivante la comunicazione con l’utente della “Story”.
L’interfaccia di sviluppo utilizzata dall’autore della “Story” prevede la costruzione dei prompt vocali in
maniera semplice ed intuitiva e permette l’inserimento dei tag, di prosodia ed emozionali, in modalità grafica.
WP1.5.2 Le componenti per l’ambiente di sviluppo
L’ambiente di sviluppo della “Story” utilizzerà una serie di componenti grafiche per l’inserimento degli
elementi vocali sopra definiti ovvero gli “Speaky Speech Input” e “Speaky Speech Output”. Tali componenti
verranno implementati utilizzando l’ambiente di sviluppo Microsoft Visual Studio .Net 2010. Esse saranno
componenti contenenti le API (Application Programming Interface) per l’integrazione delle stesse
nell’ambiente di sviluppo della “Story” e si declinano in interfacce grafiche per l’inserimento degli elementi
vocali durante la costruzione della “Story”. L’autore utilizzerà tali interfacce grafiche per definire gli elementi
vocali.
L’ambiente di sviluppo delle “Story” è sviluppato con l’ambiente Microsoft Visual Studio 2010 .Net ed il
linguaggio specifico è VC++ Nativo (non .NET). Il linguaggio di programmazione per le componenti vocali è
invece C#.NET. Considerando gli ambienti e i linguaggi di programmazione utilizzati verrà sviluppata una
interfaccia per la comunicazione tra i vari ambienti di sviluppo.
Il Flusso di Dialogo
Il flusso di dialogo che deriva dalla implementazione della “Story” è costruito in base alla struttura della
“Story” stessa così come definita nel capitolo precedente.. Qui di seguito vediamo come si mappa la
struttura del dialogo vocale con la struttura della “Story” sulla base delle componenti che la costituiscono.
Il Dialogo Vocale può essere inoltre personalizzato in alcuni suoi elementi dall’autore della “Story”. Tali
personalizzazioni sono di seguito descritte.
Es. Definire comportamenti alternativi per i comandi universali, accorpare gli stati di dialogo (import di stati),
definire gli stati di transizione (es. stati di conferma comando vocale), ecc.
WP 1.6 Uno studio preliminare su un software per lo storytelling: Use case.
Questo documento fornisce un esempio di utilizzo del software Vocs per la realizzazione di una storia
interattiva voice-driven. Lo scopo di questo esercizio e’ quello di verificare che le specifiche funzionali del
software siano adeguate ad un utilizzo pratico per la creazione di una storia interattiva. E' servito inoltre per
effettuare varie iterazioni sulle specifiche stesse. La grande utilità di una simulazione di attività di sviluppo di
una storia e' soprattutto la possibilità di evidenziare mancanze, inefficienze o limiti di un modello funzionale.
Useremo la terminologia inglese del software Vocs riguardo le varie grandezze coinvolte; diremo Story
invece che storia, Scene invece che scena e cosi via.
Verrà prima fatta la descrizione di un frammento di Story da realizzare, nell’ambito dell’edutainment
musicale.
Successivamente, verranno descritti in dettaglio i vari step necessari per la sua realizzazione. Il workflow
utilizzato in questo esempio parte dalla produzione dei contenuti, per poi realizzare la Story e le varie
Scene. Ovviamente, possono essere utilizzati altri modelli di workflow.
WP1.6.1 Descrizione storia (frammento) da realizzare
La storia interattiva riguarda la visita di un museo di strumenti musicali, effettuata con una guida virtuale
realizzata tramite un avatar. Tale avatar guida l’utente attraverso la storia degli strumenti, la loro
realizzazione e il loro utilizzo.
In questo frammento illustreremo una semplice situazione in cui l’avatar e’ in una stanza del museo, con vari
strumenti musicali esposti. L’utente può interagire con la guida chiedendo informazioni, visualizzando un
particolare strumento, e giocando con esso, simulando il suo utilizzo.
La Story inizia con una Scene, in una stanza del museo. In questa stanza sono visibili, in alcune teche, degli
strumenti musicali d’epoca: una chitarra, un violino, una spinetta, e cosi via.
All’inizio della storia, l’avatar entra camminando e si ferma al centro, dicendo alcune frasi di benvenuto
(”Buongiorno! Io sono la tua guida nel museo! Fammi tutte le domande che vuoi”)
A questo punto l’avatar resta in attesa, movendosi leggermente e facendo alcune espressioni di quando in
quando.
L’utente potrà fare domande in linguaggio naturale su vari argomenti.
Esempi:
“mi parli di come e’ nato il museo?”
“quanti strumenti contiene?”
“ cos’e’ quello strumento a destra?”
“ mi racconti com’e’ fatto?”
Il sistema ricorda l’ultimo argomento trattato, cosicché riesce ad interpretare correttamente domande che si
riferiscono al contesto (esempio: “mi racconti come e’ fatto?” si riferisce allo strumento di cui si sta parlando)
In questo esempio tratteremo solo due tipi di input vocale:
domande sulla storia del museo, e descrizione e interazione con uno strumento, la chitarra.
Se l’utente chiede di parlare della storia del museo, l’avatar dice “ho realizzato un piccolo video per questo,
ecco qua!” e parte un videoclip non interattivo con un mini documentario sul museo.
Se l’utente chiede di poter vedere/toccare/suonare la chitarra, l’avatar si avvicina alla teca con la chitarra, e
la tira fuori . A questo punto parte una nuova Scene. Questa Scene e’ un close-up sulla chitarra, che riempie
tutto lo schermo. L’utente può toccare con il mouse le singole corde e sentirne il suono.
Può anche fare domande sulla chitarra, e la voce fuori campo, descrive i vari componenti dello strumento.
WP1.6.2 Realizzazione Contenuti
Per la realizzazione della storia servono, al minimo:
- un immagine di background per la Scene del museo: contiene le varie teche con gli strumenti
musicali, e altri decori. Per gli strumenti musicali per cui e’ prevista interazione con l’avatar (nel
nostro esempio, la chitarra), tali strumenti non vengono disegnati direttamente nel background ma
realizzati a parte e sovrimposti nel montaggio dello Stage. Se e’ previsto che l’avatar apra una teca,
afferri al chitarra, anche la vetrina della teca deve essere realizzata a parte, in quanto elemento
animato.
Un’immagine di bg per la scena con la chitarra: consiste in una chitarra in primo piano, senza le
corde. Le corde vibrano al tocco, quindi vengono realizzate separatamente come contenuti animati.
- Un livello completo di animazione dell’avatar: questo livello deve contenere segmenti animati delle
varie azioni: camminata (basta verso destra o verso sinistra, poi si può fare l’immagine speculare
attraverso il software), alcune animazioni “idle” di attesa, alcune animazioni con l’avatar parlante,
l’avatar che apre la teca e prende la chitarra.
- un livello animato che mostra la corda di chitarra, da ferma a vibrante.
- Un videoclip con il mini-documentario sul museo
- Una serie di clip audio con i suoni delle corde di chitarra che vibrano
- Una serie di clip audio con il parlato dell’avatar nelle varie situazioni
WP1.6.3 Workflow di realizzazione della storia
Come già detto, l’ordine in cui vengono realizzati i vari componenti della storia può variare a seconda
dell’organizzazione del lavoro dell’utente.
Creazione Storia e Scene.
Viene creata nel software una nuova Story.
Nello Scene Editor, vengono create due Scene: la Scene MuseumRoom e la Scene Guitar. Le due Scene
appariranno nello Scene Editor come due icone vuote. Non ci sono ancora collegamenti tra le due scene,
verranno aggiunti automaticamente in fase di creazione dei Plot.
Creazione Cast
Evidenziando ognuna delle due scene create, e’ possibile visualizzare, in un’area dell’interfaccia, il cast che
contiene le icone dei contenuti attualmente utilizzati per la Scene, che ovviamente inizialmente è vuoto. Per
importare i contenuti, e’ sufficiente fare drag&drop da una finestra di windows explorer in quest’area. Quindi
per ogni scena, vengono importati i contenuti video e audio relativi.
Stage Editing.
Ora vengono montate le scene dal punto di vista visuale nello Stage Editor.
Nello Scene Editor si seleziona la Scene MuseumRoom; nella finestra dello Stage Editor appare lo stage
della scena, vuoto; si vede solo il rettangolo della camera. Tramite drag&drop dalla finestra del cast, si
aggiungono i vari contributi visuali: il background, gli eventuali arredi, gli strumenti musicali, e l’avatar.
Ognuno di questi contenuti può essere scalato, spostato, ruotato interattivamente. E’ possibile anche
cambiare l’ordine di sovrapposizione sullo schermo. La composizione fatta nello Stage rappresenta ciò che
si vede quando la scena inizia; quindi l’avatar, che entra in scena camminando, viene posizionato fuori dalla
camera. Vengono creati anche alcuni HotSpot. Un HotSpot e’ un punto sulla scena a cui viene assegnato
un nome. Questi punti possono poi esser riferiti tramite il nome quando si eseguiranno le azioni sulla scena.
Possiamo creare due Hotspot, al centro della stanza e presso la teca con la chitarra, e chiamarli
CenterOfRoom e NearGuitar.
Analoghe operazioni per la scena della chitarra, Guitar; si seleziona tale Scene nello Scene Editor, si popola
lo Stage con i contenuti (la chitarra, le corde), posizionandoli interattivamente. In questa scena, su richiesta
dell’utente, viene fornita una descrizione delle varie parti che compongono lo strumento. Il testo parlato puo’
essere accompagnato dall’apparizione di didascalie e frecce che indicano che parte si sta descrivendo
(manico, paletta, ponte…) . A tal fine se sono stati prodotti dei contenuti a riguardo, si posizionano
correttamente sulla scena. Poiché le frecce e didascalie appariranno durante la spiegazione, all’inizio della
scena questi contenuti vengono settati come “invisible”. Verranno resi visibili al momento opportuno tramite
il Plot della scena.
Creazione Behaviours
Per questo frammento di Story, l’unico contenuto dotato di Behaviour e’ l’avatar.
Dal cast della scena, selezionare l’avatar e aprire il Behaviour Editor.
Nel Behaviour Editor si mettono a punto le varie azioni che l’avatar deve compiere. A tal fine si realizzano
dei nodi collegati tra loro: ogni nodo, o stato, quando viene eseguito nella scena, esegue la sequenza
animata a cui e’ associato. Ogni stato puó avere un nome; durante il playback, nel plot della Scene (vedi
dopo) si puo’ dare un comando che porta il character nello stato con quel nome, passando dal nodo corrente
a quello richiesto seguendo la via piú breve tra i collegamenti (link) tra nodi ed eseguendo sullo stage le
animazioni associate a questi. I link tra nodi possono essere di 3 tipi; command, automatic, random.
I link command vengono attraversati quando viene dato un comando . i link automatic vengono eseguiti
sempre, a meno che ci sia un link command e sia in corso l’esecuzione di un comando per andare su un
certo stato;
i link random sono come gli automatic ma vengono eseguiti con un certo fattore di probabilità.
Nel nostro caso, l’avatar deve eseguire pochi comandi: Walk, Speak , TakeGuitar, oltre a prevedere uno
stato Idle, in cui non fa niente, e’ in attesa ma ovviamente si muove e fa delle piccole animazioni. Uno stato
chiamato “Idle” e’ obbligatorio in un behaviour. Se non c’e’ viene dato un errore quando si inizia il playback.
Cominciamo con la messa a punto di tale stato Idle.
Supponiamo che, nell’animazione dell’avatar ci siano alcune sequenze che rappresentano il character
fermo, che fa alcuni piccoli movimenti, ad esempio:
frame 1-10 ondeggia leggermente;
frame 11-20 si gratta la testa;
frame 21-30 sbadiglia.
Creiamo tre stati, associando ad ognuno i range di frame specificati. Diamogli il nome Idle, Idle1 e Idle2, per
esempio.
Settiamo Idle come nodo di start; il nodo cioè che viene eseguito all’inizio della scena.
Dobbiamo simulare un comportamento “vivo” del personaggio; per cui in modo casuale, ogni tanto esegue
qualche movimento. Per far questo usiamo i link random. Colleghiamo Idle con Idle1 e con Idle2 con un link
con probabilità 20%. Eseguiti Idle1 e Idle2, si deve tornare all’ Idle principale, quindi si fa un link automatico
fino a Idle.
Ecco la situazione (link verdi automatici, gialli random, rossi command)
start
State: IDLE1
20%
Frames 11-20
20%
State: IDLE2
State: IDLE
Frames 1-10
Frames 21-30
Quando viene iniziata la storia, viene eseguita l’animazione Idle; al termine, viene “lanciato il dado” e si
decide se andare su Idle1, su Idle2, o se ripetere l’animazione Idle. (Se non viene seguito nessun link, il
software esegue nuovamente lo stato corrente)
A questo punto dobbiamo realizzare la camminata e la parte in cui prende il violino. Per la camminata si crea
uno stato apposito, chiamiamolo Walking, con il rispettivo range di frame. Analogamente per l’animazione in
cui l’avatar afferra la chitarra, chiamiamolo TakeGuitar
Alla fine della camminata, l’avatar puo’ andare in Idle, a meno che gli si chieda di prendere la chitarra. Quindi
si collega il nodo Walking ad Idle con un link automatico, e al nodo TakeGuitar con un link command. Una
volta presa la chitarra, si ritorna su Idle. Però non si può usare il ciclo Idle precedente, perché l’avatar ora ha
una chitarra in mano! bisogna creare una nuovo ciclo IdleWithGuitar (corredato di tutte le transizioni random,
come figura precedente) in cui l’avatar impugna una chitarra. Ecco la situazione (si omettono Idle1 e Idle2
per chiarezza.)
State: WALKING
Frames 31-40
State: IDLE
Frames 1-10
State: TAKE-GUITAR
Frames 41-50
State: IDLEWITH-GUITAR
Frames 51-60
Chiaramente e’ possibile anche implementare l’azione in cui l’avatar rimette a posto la chitarra.
A tal fine bisogna prevedere uno stato WalkingWithGuitar con la chitarra in mano, mentre per l’animazione
LeaveGuitar si puo’ usare la precedente animata al contrario; basta specificare nel nodo relativo, come
frame da animare, 50-41 invece che 41-50. la costruzione della porzione di behaviour e’ analoga alla
precedente.
Se il livello di animazione dell’avatar e’ realizzato tramite un formato movie (tipo .avi, .mov…) e il frammento
di cui fare il playback e’ dotato di suoni, verranno suonati anche questi (ad esempio il rumore dei passi
mentre cammina). Altrimenti, se il livello e’ fatto da frame su file separati (png, tif…) e’ possibile associare ad
ogni stato un file audio da suonare.
Per quanto riguarda le sequenze in cui l’avatar parla, e’ possibile specificare, tra gli attributi del character, il
set di frame di animazione con il personaggio con le varie posizioni di bocca; le quali verranno visualizzate
, per ora in modo random, durante il parlato. Quando in un plot si esegue il comando speak “sentence”,(vedi
dopo) il sistema prima porta il character in stato idle e poi se son state settate, esegue le animazioni scelte
per il parlato per tutta la durata della frase.
Creazione Plot
Possiamo ora creare i Plot della Story.
Il Plot e’ diviso in Action; ogni Action e’ formato da un insieme di Block funzionali che eseguono un task. Il
colore dei block negli esempi seguenti evidenzia il tipo di block : verde per Event Block, azzurro per Normal
Block, rosso per control block.
Ogni Action comincia con un blocco di tipo evento: a seconda dell’evento che si e’ verificato (un comando
vocale, un click del mouse, etc.) si eseguono determinate azioni.
La nostra Story comincia nella Scene MuseumRoom con l’avatar che entra camminando e si posiziona al
centro, in attesa di input.
La scene MuseumRoom e’ gia stata settata come start della Story, quindi quando si fa il playback viene
visualizzato lo stage relativo, e viene lanciato l’evento “On scene Start”, eseguente l’eventBlock relativo.
Apriamo il Plot editor della scena e creiamo l’action per posizionare l’avatar:
ON SCENE START
MOVE avatar TO
CenterOfRoomUSING
walking
La prima action e’ completa. Il blocco “move…to…using” ha il seguente funzionamento: sposta il character
“avatar” sull’hotspot “center_of_stage” (creato precedentemente nello stageEditor) passando per lo stato
del behaviour “Walking”.
Le tre grandezze specificate, avatar, centerOfRoom e Walking possono essere scelte da un menu a tendina;
il primo viene selezionato tra tutti gli asset presenti nel cast della scene, il secondo tra tutti gli Hotspot creati
nello stage, il terzo tra tutti gli stati del behaviour associato ad avatar. Il terzo parametro e’ opzionale. Se non
c’e’ si mantiene il character nello stato Idle spostandolo nel punto indicato. Se il terzo parametro c’e’, lo
spostamento comincia solo quando l’avatar e’ nello stato Walking, resta in tale stato finché arriva a
destinazione, e quando arrivato viene riportato in Idle.
A questo punto il character e’ al centro, in attesa. Ogni tanto compie dei piccoli movimenti, come settato nel
behaviour.
Adesso facciamo le action per i comandi vocali.
Esisteranno degli eventi appositi che vengono eseguiti quando un comando vocale viene interpretato. Dovrá
esser realizzato un editor apposito per i comandi vocali. (da discutere con mediavoice) In questo editor
verranno definiti una serie di comandi che possono essere usati nelle actions. Il sistema interpreta il parlato,
cerca un match tra i comandi definiti nell’editor e se lo trova lancia l’evento relativo.
Nel nostro esempio definiamo i seguenti comandi vocali:
-show museum movie
-describe guitar
-talk about museum
-cannot understand request
-go back main scene
per ognuno degli eventi associati ad un commando vocale, creiamo una action nel plot.
Per l’evento ‘show museum movie’ l’avatar potrebbe dire qualcosa del tipo “vuoi sapere un po’ di piú della
storia de museo? Bene! Ti faccio vedere un piccolo film” e parte il movie.
Ecco l’action:
ON VOCAL COMMAND: show
museum movie
Avatar
museum.mp3
SPEAKS
SET movie_seen TO 1
PLAY MOVIE history.avi
In questo esempio, le frasi che l’avatar pronuncia sono tutte registrate su file mp3. Viene creata la variabile
movie_seen e posta a 1. Questo segnala che il film e’ gia’ stato visto dall’utente. Questa variabile fa si che
se l’utente chiede di nuovo di vedere il film, l’avatar può dire qualcosa del tipo “ah vuoi rivederlo di nuovo? Ti
e’ proprio piaciuto, bene!”
Per implementare questo meccanismo , possiamo modificare l’action precedente introducendo un blocco di
controllo, l’If..THEN…ELSE. AI blocchi di controllo vanno associati un certo numero di blocchi, che
dipendono dal tipo di controllo. Nel caso dell’ IF..THEN..ELSE, vanno associati due blocchi.
L’action diventa:
THEN
ELSE
ON VOCAL COMMAND show
museum movie
Avatar SPEAKS museum.mp3
Avatar SPEAKS museum2.mp3
IF movie_seen UNDEFINED
SET movie_seen TO 1
PLAY history.avi
il significato del blocco di controllo e’ evidente. Notare che la variabile viene definita “on-the fly”. La prima
volta che si esegue l’action, il sistema non conosce movie_seen. In questo caso, movie_seen e’
UNDEFINED e viene eseguito il THEN. Il comando SET, nel porre la variabile pari a 1, la sta definendo. In
questo esempio e’ irrilevante il valore di movie_seen, conta solo il fatto che sia stata definita.
Questo meccanismo, per creare nuove situazioni quando si fanno le stesse richieste, per generare varietà,
può essere ripetuto per tutte le action legate ai comandi vocali, tramite l’uso delle variabili. Ometteremo
questa gestione delle ripetizioni nelle prossime action.
Vediamo ora il vocal command ‘describe guitar’. Questo comando viene invocato quando l’utente chiede
dettagli sulla chitarra. L’avatar in questo caso, va verso la teca della chitarra, l’afferra, comincia a descrivere
la chitarra, e poi passa il controllo alla nuova Scene, Guitar Scene.
L’action relativa e’ la seguente:
ON VOCAL COMMAND describe
guitar
MOVE avatar TO nearGuitar
USING walking
HIDE guitar.png
avatar EXECUTE take-guitar
Avatar
SPEAKS
description.mp3
guitar
PLAY
SCENE
GuitarScene
from BEGINNING
All’inizio, si fa camminare l’avatar fino all’Hotspot chiamato nearGuitar;
poi si toglie l’immagine della chitarra dalla scena, perché nel momento che l’avatar comincia a prenderla,
essa e’ inclusa nell’animazione dell’avatar; poi dice quel che deve e infine si passa alla scena GuitarScene.
Notare che la presenza del Block PLAY SCENE crea automaticamente un arco di link, nello Story Editor, tra
le due Scene presenti.
Per quanto riguarda l’evento ‘cannot understand request’, questo viene invocato tutte le volte che non viene
capito il comando vocale. L’avatar potrebbe dire cose tipo “che hai detto/ non capisco!” “ripeti per favore?”
etc.
Si possono realizzare una serie di frasi diverse, per rendere la cosa meno ripetitiva, ed ogni volta sceglierne
una random tra queste.
Per far questo, si può usare il control block “CHOOSE RANDOM BLOCK” che accetta un numero qualsiasi
di blocchi e sceglie uno di questi casualmente.
Ecco l’action:
ON VOCAL COMMAND cannot
understand
CHOOSE RANDOM BLOCK
Avatar
SPEAKS
sorry1.mp3
Avatar
SPEAKS
sorry2.mp3
guitar
Avatar
SPEAKS
sorry3.mp3
Avatar
SPEAKS
sorry4.mp3
guitar
guitar
guitar
Realizziamo ora il plot della scena GuitarScene.
Questa scena comincia con una descrizione della chitarra, evidenziando le varie parti con frecce e
didascalie sullo schermo. Finita la descrizione, l’utente può cliccare sulle varie corde, vederle
vibrare e sentirne il suono.
Ecco l’action eseguita all’inizio della scena:
ON SCENE START
PLAY
guitar description
intro.mp3
SHOW arrow1.png
PLAY guitar description1
HIDE
SHOW
arrow1.png
arrow2.png
PLAY guitar description2
HIDE
SHOW
arrow2.png
arrow3.png
PLAY guitar description3
HIDE arrow3.png
PLAY guitar description end
La descrizione vocale della chitarra e’ divisa in parti. Per ogni parte viene visualizzato sulle schermo la
didascalia e freccia relativa alla parte che si sta per descrivere, e si nasconde la didascalia precedente.
In qualsiasi momento, l’utente può cliccare su una corda, vederla vibrare e sentirne il suono. Supponiamo
che l’animazione della corda e’ contenuta in un file movie dotato di suono.
Per ogni corda, viene realizzata una semplice action come la seguente:
ON MOUSECLICK ON string1
PLAY string1.mov
L’event block ON MOUSECLICK viene invocato quando l’utente clicca sul content specificato nel blocco.
Infine, per tornare alla scena precedente, viene fatta la action che implementa il vocal command go back
main scene:
ON VOCAL COMMAND go back
main scene
PLAY SCENE MuseumScene
FROM CURRENTSTATE
In questo caso il block PLAY SCENE, invece di fare il playback dall’inizio (con l’avatar che entra in scena
camminando) ritorna alla scena nello stato in cui la si e’ lasciata.
Anche in questo caso, l’uso del block PLAY SCENE crea automaticamente un arco di congiunzione tra le
due scene nello Story Editor.
Con questo, il frammento di storia è concluso.
WP2 Sviluppo: Produzione, reperimento e trattamento contenuti.
MESI 9-15
La descrizione estesa del WP2, come da specifiche di progetto, è la seguente:
WP2 (MESI 9-15, DV+MV+IC+SC) Sviluppo: Produzione, reperimento e trattamento contenuti.
In collaborazione con le associazioni indicate, verranno raccolti e prodotti i contenuti multimediali richiesti per
l’ambito artistico/culturale prescelto. Tali contenuti verranno filtrati, transcodificati e su di essi verrà costruita
la Voice User Interface (VUI) utilizzando dei tool realizzati appositamente, avvalendosi delle tecnologie
sviluppate da Digital Video e Mediavoice.
Questo Work Package è stato realizzato da parte dell'Accademia di Santa Cecilia, con la collaborazione di
Digital Video.
WP 2.1 Produzione, reperimento e trattamento contenuti
Per la realizzazione della story è stato individuato come ambito didattico-educativo il Museo di Strumenti
Musicali dell’Accademia (MUSA). Infatti gli strumenti musicali posseggono in sé qualità intrinsecamente
“multimediali”: sono esteticamente interessanti (immagini), hanno un suono particolare (audio), vengono
suonati con certi movimenti (video). Inoltre gli strumenti posseduti dall’Accademia fanno parte di una rete di
beni culturali più ampia rappresentata da diversi Archivi digitali. Ad esempio è possibile ascoltare il suono di
alcuni strumenti esposti nel museo, dalle registrazioni storiche conservate nell’archivio sonoro. Infine
l’Accademia ha da sempre posto particolare attenzione agli aspetti di divulgazione ed educazione dei
ragazzi attraverso diverse iniziative, incuse attività specifiche realizzate presso il MUSA e relative alle nuove
tecnologie.
La tecnologia VOCS, quindi, è da subito apparsa particolarmente indicata per la creazione di un’applicazione
divertente e allo stesso educativa per valorizzare e far conoscere il patrimonio del MUSA ai ragazzi, senza
dimenticare come l’aspetto “tecnologico” e interattivo risulti di particolare attrattiva per i ragazzi, oggi abituati
a interagire in maniera disinvolta con computer e video games (come emerso anche in altri progetti di
ricerca).
La storia interattiva segue lo svolgersi di una visita al MUSA, effettuata con una guida virtuale (l’avatar).
Tale avatar – una giovane studentessa universitaria – guida i ragazzi attraverso quattro aspetti salienti legati
al museo, ma anche più in generale alla tradizione musicale dell’Accademia: la storia del museo e il
patrimonio ad essa collegato, uno strumento classico, uno strumento etnomusicologico, l’orchestra.
Ecco come appare nella storia finale uno screenshot della scena iniziale della storia:
La progettazione è stata realizzata in funzione del workflow di realizzazione del lavoro, ma anche
considerando gli obiettivi del progetto e in particolare l’aspetto interattivo e d’interazione vocale. Dopo aver
scritto la trama della storia e i contenuti fondamentali è stata poi elaborata una griglia sinottica con la
descrizione dettagliata delle singole scene, i contenuti necessari e le caratteristiche richieste all’avatar.
Do seguito riportiamo una griglia sinottica della story con i contenuti necessari e le esigenze legate all'avatar
Scena
Contenuti per la scena
Dettagli avatar
Scena 0a. Accoglienza
- Foto della galleria con teche
strumenti
- Musica di sottofondo
- Avatar che entra camminando
- Avatar che parla
- Avatar che indica (tocca) icone
selezionate
- Foto della galleria con
cambiamento di luce
- Icone
- Etichette testuali per selezione
elementi
- Musica di sottofondo
- Avatar che entra camminando
- Avatar che parla
- Avatar che indica (tocca) icone
selezionate
- Foto del concerto storico per
sfondo
- Foto/icona regina Margherita
- Musica di sottofondo
Idem
All’inizio della storia, l’avatar entra
camminando e si ferma al centro,
dicendo alcune frasi di benvenuto e
dando inizio alla visita
Scena 0b. Menu principale
L’avatar invita l’utente a scegliere
con comando vocale quale aspetto
del museo vuole approfondire ad es:
“Per scoprire la storia, chiedi ‘Storia’”
L’avatar comunica all’utente che
potrà tornare a questa scena in ogni
momento dicendo “menu”
L’utente sceglierà una delle quattro
scene indicate dalle quattro icone.
Scena 1. “STORIA”
L’avatar fa una piccola intro del tipo
“Tutto è cominciato dal concerto che
vedete nella foto alle mie spalle….
[accenna alla regina Margherita]”
Quando accenna alla Regina
Margherita appare un suo ritratto che
viene zooomato.
Scena 2. “ORCHESTRA”
L’avatar entra sullo sfondo spiega
cosa accade in questa scena:
“Nella sala Santa Cecilia, proprio qui
sopra al museo, suona la nostra
famosa orchestra… Qui potrai
conoscere alcuni degli strumenti che
la compongono”
- Immagine con schema
dell’orchestra con etichette tipo
“archi”, “legni”, “ottoni”, “percussioni”
- L’avatar si rimpicciolisce e invita a
giocare con gli strumenti
dell’orchestra
Gioco strumenti orchestra:
- Si sente il suono di uno strumento:
l’utente deve dire il nome dello/degli
strumento/i che suonano
- Foto dell’orchestra
- Video dell’orchestra
- Schema orchestra
- Immagini e suoni dei singoli
strumenti per il gioco
- Musica di sottofondo (da
registrazione orchestra)
Idem
- Avatar rimpicciolito
Scena 3. “VIOLINO”
L’avatar accoglie l’utente e dice
qualche parola introduttiva sul violino
Stradivari detto “Toscano”.
Mentre parla dello strumento parte
dello sfondo è occupato dal violino
su un piedistallo
A questo punto, sempre su invito
dell’avatar l’utente può scegliere se
vedere un video dello Stradivari
dicendo “video”
- Grafica sfondo stile
palcoscenico
- Foto violino stradivari ritagliata
- Grafica piedistallo
- Video storico con Carmirelli
che suona il violino
- Musica di sottofondo (violino –
Paganini)
- Idem
Scena 4. “LAUNEDDAS”
Sfondo foto b/n archivi etno
Sardegna
- L’avatar introduce la musica
“popolare” e introduce gli strumenti
di quest’ultima (presenti al museo).
In particolare l’antico strumento
sardo chiamato launeddas.
- L’avatar fa ascoltare un brano per
launeddas (zoom sul suonatore)
- L’avatar fornisce ulteriori
informazioni sulla launeddas.
- Foto sfondo con suonatori
launeddas bianco e nero
- Elementi grafici per sfondo
(albero, lampione) colorati con
trasparenze
- Audio launeddas da archivio
sonoro etnomusicologia
- idem
Una volta definita la struttura della story è iniziata la fase di creazione del database di contenuti tramite la
raccolta, filtraggio e transcodifica dei contenuti. Alcuni di questi, come è intuibile dalla tabella, sono stati
ricercati e reperiti direttamente dagli Archivi dell’Accademia. Altri (quali ad esempio icone ed elementi grafici)
sono stati creati appositamente. Chiaramente i contenuti estratti dagli archivi sono stati modificati e
predisposti in modo da essere adatti alla story. Inoltre durante la creazione della story è sorta la necessità di
aggiungere o modificare alcuni dei contenuti inizialmente individuati per adattarli al meglio al lavoro.
Ecco un esempio di altra scena della storia, relativa al violino Stradivari “Toscano”. L’immagine del violino
proviene dall’archivio fotografico dell’Accademia
WP3 Sviluppo: Design e realizzazione avatar
MESI 9-21
La descrizione estesa del WP3, come da specifiche di progetto, e' la seguente:
WP3 (MESI 9-21, DV+MV+OI+FUB+CUL) Sviluppo: Design e realizzazione avatar
Verrà ideato e realizzato l‘Avatar (o gli Avatar), sia nella sua forma visuale che nei suoi meccanismi di
interazione vocali. A tal fine verranno prodotti dei contenuti per l’aspetto visuale del personaggio, e tutte le
animazioni previste per le sue funzioni all’interno delle storie. Verranno inoltre integrati i motori di sintesi e
riconoscimento vocale, per produrre un automa sofisticato che fungerà da guida e controllore nella creazione
di segmenti di storytelling della piattaforma. Sarà possibile eseguire prove di integrazione con il motore di
render del WP4, il cui sviluppo avverrà di pari passo con quello dell’avatar.
WP3.1 Design e realizzazione avatar
Questo Work Package è stato realizzato da parte dell'Accademia di Santa Cecilia, con la collaborazione di
Digital Video.
Il punto di partenza per la realizzazione dell'Avatar é stata l'identificazione della storia da realizzare, il suo
ambito e i suoi meccanismi interattivi.
La storia prescelta riguarda la visita di un museo degli strumenti musicali. Ci si e' immaginati quindi la
situazione tipo di una scolaresca che effettua tale visita guidati da un professore di musica, che funge da
Avatar per la storia interattiva.
La prima ipotesi presa in considerazione per la realizzazione dell’avatar è stata quella di un professore sui
35-40 anni, dall'aspetto non troppo serioso .
Dei primi studi sul personaggio hanno portato ad alcune ipotesi, rappresentate nella seguente figura:
E' stato realizzato il turnaround completo, come da figura:
Successivamente, in parte a causa di problemi tecnici e di licenze software, e’ stata presa un’altra direzione.
Infatti, il motore di Sintesi vocale realizzato da MediaVoice, tra le voci disponibili di una certa qualità e
verosimiglianza, ha a disposizione soltanto voci di tipo femminile.
Si e’ quindi preferito tornare sui nostri passi e realizzare un avatar di sesso femminile, quindi una giovane
professoressa.
Riportiamo il turnaround completo del personaggio:
WP4 Sviluppo: Realizzazione motore di render dello storytelling
MESI 9-21
A seguito della completa messa a punto delle specifiche funzionali, si e' passati allo sviluppo del software
vero e proprio. Di seguito, la descrizione del workpackage come da specifiche di progetto:
WP4 (MESI 8-22, DV+IC+OI+FUB) Sviluppo: Realizzazione motore di render dello storytelling
Verrà realizzato il motore di render, quella parte cioè del software che crea in tempo reale la storia vera e
propria. Il motore di render, interpretando i comandi provenienti dall’avatar, assemblerà i contenuti
audiovisivi disponibili, eventualmente aggiungendo movimenti di camera, effetti speciali ed effetti sonori, per
creare il segmento di storytelling voluto. Inizialmente, è previsto un simulatore di Avatar, cioè un componente
che emette comandi verosimili, simulando il comportamento interattivo dell’avatar.
Questo workpackage in realta' non comprende solo la realizzazione del motore di render, ma anche la
realizzazione delle librerie di base, degli elementi per la costruzione e l'editing dello storytelling nonche' dei
widget base dell'interfaccia grafica.
Illustreremo le varie componenti realizzate.
WP4.1 L'ambiente di Sviluppo e le librerie base.
Per lo sviluppo del software si e' scelta la piattaforma Visual Studio 2008 nel linguaggio C++, Come librerie
di base per la realizzazione degli elementi di interfaccia grafica, si e' scelto il pacchetto open source di
libreria Qt (versione 4.6) della Nokia.
Durante lo sviluppo del software, si e' fatto un upgrade dell'ambiente di sviluppo passando a Visual Studio
2010 e alle librerie Nokia Qt 4.8.
Per quanto riguarda la parte di render realtime onscreen, si sono utilizza le librerie standard openGl.
Per la gestione dei suoni e delle musiche (caricamento, salvataggio playback) si e' scelta la libreria Ambiera
irrKLang, mentre per la parte di gestione Videoclip (caricamento e playback embedded di movies) si e'
utilizzata la libreria Phonon di Qt.
Il sistema Vocs supporta i formati di file immagine e movie piu' diffusi, come tif, png, bmp, gif, jpg, etc. cosi'
come i formati movie quicktime mov e avi. Per la parte audio, analogamente, sono supportati i formati
standard come mp3, aiff, wav, flac.
Per la lettura e scrittura di tali formati ci si e' avvalsi sia di librerie proprietarie sviluppate da Digital Video, che
da librerie non commerciali come Quicktime (per il formato avi) e la libreria Tiff (per il formato tif)
WP4.2 I formati file di Vocs
Come gia' accennato, per quanto riguarda i contenuti multimediali Vocs non ha introdotto formati proprietari,
ma utilizza i piu' diffusi formati di immagini, movie e suoni.
Per quanto riguarda invece la memorizzazione delle storie, si sono creati alcuni formati file, tutti basati sullo
standard XML.
Una storia interattiva di Vocs viene memorizzata all'interno di un folder, creato dal sistema, il cui nome
coincide col nome della storia.
Tale folder contiene i file che costituiscono la storia stessa, in particolare:
- il file VST (Vocs Story) memorizza quali sono le scene costituenti la storia, e come sono organizzate tali
scene nella storia.
- il file VSC memorizza tutte le informazioni per la singola scena: gli elementi multimediali, la geometria sullo
stage, i behaviour degli avatar, le action delle scena.
Quindi ogni storia e' essenzialmente composta1 file VST e vari file VSC, uno per ogni scena nella storia.
WP4.3 Il motore di Render e lo Stage Editor
Per la realizzazione del motore di render si sono utilizzate le primitive di disegno openGl.
Ogni scena e' composta da una serie di StageItem.
Gli StageItem: sono elementi multimediali da visualizzare sullo stage. Ogni StageItem contiene informazioni
(espresse tramite matrici affini di trasformazione) sulla sua geoetria all'interno dello stage.
GLi stageItems possono essere Character, Props, HotAreas, o MultimediaItems:
Characters: sono i contenuti multimediali animati e dotati un behaviour (gli Avatar). I Character hanno
associato uno stato attuale, che evolve durante il playback della storia, e che indica che porzione
dell'animazione visualizzare;
Props: sono immagini statici visualizzate sullo stage, come backgrounds e oggetti di scena. Non sono
elementi animati;
HotAreas: sono elementi che definiscono zone speciali dello schermo. Servono epr mettere a punto azioni
interattive, per definre area di playback di movie, etc. e non sono visualizzati durante il playback;
MultimediaItem: sono i movie e le soundtrack utilizzate nella scena;
Il disegno del singolo frame completo sullo schermo consiste nello scorrere i vari stageItem e applicare un
metodo appropriato di render, basato su openGl .
Il render completo della scena sullo stage Editor avviene in modalità diverse, che dipende si sta in modalità
editing o playback.
Render in editing mode:
In questa modalita' viene fatto sempre il render dello stato iniziale della scena, i character non evolvono. Il
ridisegno viene invocato in base agli input dell'utente, tipicamente click del mouse, o modifiche dei widget
dell'interfaccia. In questa modalita' e' possibile caricare o cancellare stageItems, modificare la loro
geometria sullo schermo, etc.
In editing mode, vengono anche disegnati dei gadget per l'editing degli oggetti sullo schermo, come cornici,
frecce, etc.
In figura, l'interfaccia dello stage con una scena in edit mode:
Render in playback mode:
Questa modalità effettua l'esecuzione della storia interattiva.
Appena viene eseguita, si legge all'interno del plot la scena iniziale, si carica nello stage, e si esegue la
action iniziale di essa.
Il render viene regolato da un timer, che ad intervalli regolari (tipicamente 1/25 di secondo) fa evolvere il
sistema in base alle action della scena e agli input vocali e non dell'utente.
Di seguito riportiamo un diagramma del workflow di render della scena:
Ecco una breve descrizione dei nodi del diagramma di flusso:
- Start: L'inizio della scena viene tipicamente invocato tramite un comando sull'interfaccia.
- Load Scene; vengono caricati tutti gli StageItem della scena, resettati tutti gli stati della scena corrente allo
stato iniziale;
- Loop: questo funge come una sorta di main Loop temporizzato del playback; la velocità settata
corrisponde con il framerate del playback su schermo.
- Check Input: si verifica se son arrivate delle richieste dall'utente. queste richieste possono essere
tipicamente dei comandi vocali, ma anche comandi da interfaccia grafica (click del mouse sulla scena,
pause/stop della storia, etc.)
- Check Actions: all'interno del plot si verifica se una certa Action e' stata completata e si passa alla
successiva, settando le opportune variabili di stato;
- Changed Scene: seconda degli input e dell'evoluzione del plot si controlla se e' necessario cambiare
scena (o terminare la storia). In tal caso, viene caricata la nuova scena (o se e' finita la storia, si torna in edit
mode)
.
Evolve Status: Viene settato il nuovo stato di tutti gli stageItem;
Draw Scene: viene disegnata la scena sullo stage, esattamente come avviene in edit mode: con la
differenza che gli StageItem hanno uno stato non iniziale;
Play Multimedia: se richiesto, vengono lanciati i playback delle soundtrack e dei video.
WP4.4 Il plot, e il plot editor.
Il plot e' l'elemento della storia in cui vengono specificate le azioni da compiere (actions) in seguito a
comandi dell'utente o cambiamenti di stato. Ogni Action e' composta di blocchi che eseguono un'operazione
elementare (come muovere un personaggio, suonare una soundtrack, etc) che vengono assemblati insieme
in modo intuito tramite una interfaccia grafica che utilizza l'approccio del Visual Programming.
In figura, un esempio di plot all'interno del software Vocs composto di alcune azioni:
Ogni action comincia con un blocco speciale(in rosso) che identifica un evento (comando vocale, inizio
scena.etc) ed e' seguito da una serie di blocchi (colore blu) che seguono una serie di azioni. Altri blocchi
speciali sono quelli che non prevedono ulteriori azioni (in giallo), come ad esempio fine storia, cambio scena,
etc.
E' possibile assemblare e manipolare i vari blocchi tramite drag&drop. Nella colonna di sinistra sono presenti
tutti i blocks usabili nella scena.
L'implementazione dei blocchi in c++ e' stata fatta in modo molto strutturata e modulare, in modo tale che
l'aggiunta di un nuovo blocco, e quindi di una nuova funzionalità, sia estremamente facile e veloce.
Riportiamo di seguito il diagramma delle classi e delle ereditarietà per la classe base VBlock:
Diamo una breve descrizione delle classi basi e dei blocchi funzionali piu' importanti:
VBlock: la classe base da cui ogni blocco deriva;
VExecuteBlock: esegue un comando.
VConditionBlock: fa un check su qualche grandezza della scene attuale e ritorna true o false.
VUnaryBlock: un blocco che puo' avere un solo blocco come successiva azione
VZeraryBlock: un blocco conclusivo: nessun alra azione puo' essere eseguita in questa scena dopo di esso.
VIfBlock; un blocco che accetta come argomento un VConditionBlock e 2 VExecuteBlock, e implementanta
il comando if..then..else.
VMoveCameraBlock: esegue un movimento di camera di tipo pan e zoom.
VPlayVideoBlock: un dato videoclip viene mostrato sullo stage.
VPerformCharacterBlock: va eseguire una data animazione ad un avatar specificato
VStartBlock: un blocco di inizio action, tipicamente un evento esterno
VVocalCommandBlock: uno startBlock invocato quando un o o piu' comandi vocali asegnati son stati dati;
VStartSceneBlock: StartBlock invocato all'inizio di una scena
WP4.5 la Story e lo Story editor.
Le varie scene della storia, e le loro connessioni all'interno della storia, possono venire visualizzate, sotto
foram di grafo orientato, ed editate all'interno dello story editor. In figura un esempio di una storia composto
di 4 scene:
Ogni arco indica che durante il playback della storia, e' possibile passare da una scena a quella ad essa
collegata. Lo story editor viene popolato in modo semi automatico: sia le icone che rappresentano le scene
che gli archi di connessione infatti vengono calcolati automaticamente da Vocs.
WP5 Sviluppo: Realizzazione motore vocale dello storytelling
MESI 8-22
. Di seguito, la descrizione del workpackage come da specifiche di progetto:
WP5 (MESI 8-22, MV+CUL) Sviluppo: Realizzazione motore vocale dello storytelling
Verrà realizzato l’engine vocale dello storytelling, vale a dire il modulo della piattaforma che rappresenta la
parte vocale dell’Avatar e che è in grado di gestire i due motori di basso livello di sintesi, Text to speech
(TTS) e riconoscimento vocale, Automatic Speech Recognition (ASR), insieme al sottomodulo VUI che
gestisce la interfaccia vocale disegnata e interagisce con la parte grafica dell’Avatar.
WP 5.1 L'interfaccia utente
L'interfaccia utente di Speakable è estremamente semplice. Tramite avvisi sull’ambiente grafico di Windows
informa l’utente tramite dei messaggi non invasivi dello stato operativo del programma.
L’avvio del sistema presenta la schermata in figura:
Premendo start si avvia il monitoraggio della cartella designata, pre-impostata all’interno del registro sistema
di windows nella chiave:
HKEY_CURRENT_USER -> Software -> VocsProject -> VocsConfig -> VvcFolder
Il software risponde tramite un “ballon Tip” sulla barra di windows ai vari eventi programmati:
1. Attivazione del servizio.
2. Disattivazione del servizio.
3. Rilevazione modifiche e elaborazione dei file.
4. Chiusura dell’applicazione
WP5.2 Funzionamento
Il servizio si incarica di monitorizzare, quando attivato, in modo costante la cartella definita nella chiave:
HKEY_CURRENT_USER -> Software -> VocsProject -> VocsConfig -> VvcFolder
in cerca di file del tipo nome_file_da_monitorare.vvc
<story name="visita_del_museo_della_musica">
<global_events>
<event id='0'>
<vocal_command sentence="stop"/>
<vocal_command sentence="ferma"/>
</event>
<event id='1'>
<vocal_command sentence="alza volume"/>
</event>
<event id='2'>
<vocal_command sentence="abbassa volume"/>
</event>
</global_events>
<scene_events scene_name="inizio_visita">
<event id='3'>
<vocal_command sentence="vai a sinistra"/>
<vocal_command sentence="sinistra"/>
<vocal_command sentence="cammina verso sinistra"/>
<vocal_command sentence="torno indietro"/>
</event>
<event id='4'>
<vocal_command sentence="vai a destra"/>
</event>
</scene_events>
<scene_events scene_name="nella_stanza_dei_liuti">
<event id='3'>
<vocal_command sentence="spiega"/>
<vocal_command sentence="raccontami"/>
<vocal_command sentence="cosa sono questi?"/>
<vocal_command sentence="basta non mi interessa"/>
</event>
<event id='4'>
<vocal_command sentence="vai nella prossima stanza"/>
</event>
</scene_events>
</story>
Esempio di file museo della musica.vvc
Quando viene rilevato un nuovo file o viene effettuata una modifica a un file esistente, quest’ultimo viene
immediatamente processato.
Vengono creati nella cartella definita nella chiave:
HKEY_LOCAL_MACHINE -> Software -> Wow6432Node -> Mediavoice -> SpeakyMCE
le grammatiche ed i voice template della visita secondo la regola di un Voice Template per visita e una
grammatica per scena.
<root version="2.0">
<ASR>
<Grammar id="inizio_visita"
dictionary="2@@visita_del_museo_della_musica@@main@@static@@
visita_del_museo_della_musica_inizio_visita@@main@@static">
<Role>
<Phrase>
<static>CMD</static>
</Phrase>
<Parsed>
<statoid>inizio_visita</statoid>
<textid>void_text</textid>
<textcmdid>command</textcmdid>
</Parsed>
</Role>
</Grammar>
<Grammar id="nella_stanza_dei_liuti"
dictionary="2@@visita_del_museo_della_musica@@main@@static@@
visita_del_museo_della_musica_nella_stanza_dei_liuti@@main@@static
">
<Role>
<Phrase>
<static>CMD</static>
</Phrase>
<Parsed>
<statoid>nella_stanza_dei_liuti</statoid>
<textid>void_text</textid>
<textcmdid>command</textcmdid>
</Parsed>
</Role>
</Grammar>
</ASR>
</root>
Esempio di Voice Template creato dal sistema: visita_del_museo_della_musica.xml
Esempio di Voice Template creato dal sistema: visita_del_museo_della_musica.xml
language it-it;
mode voice;
root $main;
tag-format <loq-semantics\1.0>;
public $main =
(
( $voice_command {:cmd}) {<@semantica strcat("CMD?#?" $cmd)>}
);
$voice_command =
(
"vai a sinistra":"3" |
"sinistra":"3" |
"cammina verso sinistra":"3" |
"torno indietro":"3" |
"vai a destra":"4"
) {return($value)};
visita_del_museo_della_musica_inizio_visita.gram
WP6 Test e Tuning prototipo piattaforma
MESI
24
20-
. Di seguito, la descrizione del workpackage come da specifiche di progetto:
WP6 (MESI 20-24, DV+MV+IC+OI+FUB+CUL+SC) Test e Tuning prototipo piattaforma
Nell’ultima fase del progetto verrà effettuato sia un nuovo test modulare, sia un test complessivo con relativo
tuning. Questa fase è necessaria ai fini di irrobustire la piattaforma e di calibrare i suoi parametri operativi
affinché corrisponda al meglio alle specifiche utente disegnate inizialmente.
Per il test e tuning del prototipo, si e’ realizzata una storia completa, sufficientemente complessa da
permettere un test esaustivo delle varie funzionalità. Lo sviluppo della storia, data la sua complessità, e’
iniziata già dal mese 12, con una collaborazione molto stretta tra gli sviluppatori software e gli autori che ha
permesso la modifica delle feature sviluppate, nonché dell’interfaccia grafica, in base alle indicazioni
continue degli autori durante l’implementazione della storia.
La storia presenta infatti diverse feature, come playback di videoclip inseriti all’interno delle scene,
movimenti dio camera complessi, giochi interattivi, e cosi via.
Riportiamo di seguito la descrizione della storia realizzata.
WP6.1 Set-up del sistema, training e aggiornamenti
Come passo iniziale per l’uso di VOCS, il sistema è stato installato su alcune macchine dell’Accademia
insieme allo staff di Digital Video. Contestualmente è stato anche installato il sistema di riconoscimento
vocale Speaky insieme allo staff di MediaVoice.
Allo stesso tempo è stata studiata la documentazione (manuale utente e casi d’uso) e sono state effettuate
delle sessioni di training. Durante tutto il progetto il software si è evoluto e nuove versioni con nuove
funzionalità sono state consegnate. C’è quindi stato un continuo feedback incrociato con il team di sviluppo
(ad esempio con feature-request o bug-report) che ha seguito da un lato l’evoluzione del software, dall’altro
quella della story stessa.
Per la condivisione delle varie versioni della storia è stato utilizzato sia un server FTP, sia (successivamente)
1
un servizio di storage online pensato per lo sviluppo, che offre GIT come sistema per il versioning.
WP6.2 Realizzazione della story
Una volta reperiti e preparati i contenuti essi sono stati importati in VOCS attraverso semplice drag-and-drop.
Per semplificare e rendere più efficiente il lavoro, una copia di tutti i contenuti necessari è stata fatta
localmente sulla macchina utilizzata per l’editing. Una volta importati i contenuti in VOCS, essi vengono
visualizzati in una struttura ad albero (il browser delle scene )
Ecco riportata la struttura ad albero della story, come appare nel software:
Ogni scena è stata organizzata visualmente nello Stage Editor nel quale vengono disposti e organizzati i vari
contenuti visuali quali sfondi, oggetti, character con operazioni di spostamento e posizionamento,
ridimensionamento ecc.
Riportiamo le schermate dell’interfaccia del software per quanto riguarda due delle scene della story, la
scena iniziale e la scena “Launeddas”, che evidenziano la disposizione dei vari elementi grafici
1
Si veda http://it.wikipedia.org/wiki/Git_%28software%29
Ecco invece la scena “Launeddas” durante il playback:
I contenuti audio e video sono stati aggiunti nel Plot Editor: essi, infatti, hanno natura temporale (devono
iniziare a in un certo momento, durare per un certo intervallo di tempo e poi finire).
Elemento centrale della story è l’avatar, chiamato all’interno del software “Character”. Dal punto di vista
tecnico il Character è una sequenza di frame forniti come immagini singole o all’interno di un video,
eventualmente con una trasparenza. Una volta importato un insieme di frame, l’avatar viene “modellato”
all’interno del Character Editor, nel quale è possibile stabilirne il comportamento in unità dette “Nodi”. Ogni
nodo è costituito da una serie di frame contigui, possiede una alcune proprietà e può essere collegato
logicamente ad altri nodi. Come delineato nella griglia sinottica (v. Errore. L'origine riferimento non è stata
trovata.) l’avatar deve entrare camminando in ogni scena: questo elemento, infatti, produce un senso di
maggiore immersione nella storia, dando all’utente l’idea di essere realmente nell’ambiente del museo. A
questo scopo è stato creato il nodo “walk1” con un attributo Move diverso da zero: ciò indica a VOCS che
quando il Character è in questo nodo esso deve spostarsi. Il comportamento esatto e l’andamento dello
spostamento (in questo caso un “camminata”) verranno poi definiti successivamente nel Plot Editor.
Ecco come appare tale nodo “walk1” nell’interfaccia del software:
Il parlato, ovvero l’animazione labiale, è gestito indipendentemente dall’animazione dell’avatar stesso. Ciò
vuol dire che in ogni momento in cui l’avatar deve parlare, deve anche muovere la bocca coerentemente. Il
labiale viene quindi specificato in un attributo specifico “Mouth” il quale punta a un video contenente
l’animazione. Sono quindi stati creati i nodi necessari per il parlato. Anche in questo caso la gestione vera e
propria delle sequenze di parlato all’interno di ogni scena avviene successivamente nel Plot Editor.
Qui di seguito tree esempi di nodi dell’avatar realizzati per il parlato. E’ presente il fil mouth.mov, che
contiene le bocche con le varie posizioni.
Una volta importati i contenuti e organizzata la scena con la disposizione visiva degli elementi necessari
(grafica, hotspot, avatar), si è passati alla realizzazione della “trama” vera e propria della story all’interno del
Plot Editor. Ovviamente la story sviluppa con VOCS è interattiva e quindi la trama è aperta e deve contenere
elementi logici in grado di reagire a diverse condizioni esterne quali l’input dell’utente, il passare del tempo,
ecc.
Partendo dalla Griglia sinottica per la storia si è proceduto alla elaborazione delle scene. Senza entrare nel
dettaglio di ogni singola scena, riportiamo qui alcuni elementi salienti relativi al lavoro nel plot editor.
Chiaramente il design di alcune scene è stato più complesso rispetto ad altre. Ad esempio la scena
introduttiva è relativamente statica (l’avatar entra su una musica di sottofondo, dice qualcosa e poi passa
alla scena successiva); ben più articolata è la scena che funge da menù principale della visita: qui l’avatar
deve spiegare agli utenti le varie entrate del menù, inoltre essi devono poter scegliere (attraverso un
comando vocale) una qualunque delle scene presentate. Questa scena contiene quindi un blocco
principale con le azioni del personaggio e i contenuti relativi (musica di sottofondo, parlato ecc.), ma
parallelamente anche una serie di blocchi che reagiscono ai comandi degli utenti. E’ stato aggiunto anche un
blocco “On Bad Vocal Command”, importante per dare un feedback all’utente nel caso abbia dato un
comando non previsto o che il sistema non sia in grado di comprendere: in questo caso l’avatar dice di non
aver capito e riepiloga brevemente le possibili scelte presenti nel menu.
Nella figura seguente, sopra: blocchi “On vocal command” per la scena menù, che permettono all’utente di
lasciare la scena e far partire quella scelta. Sotto: frammento di blocco “On Bad Vocal Command” per
reagire a un comando vocale non riconosciuto
Ed ecco uno screenshot della scena menu, con l’avatar che indica le diverse opzioni disponibili.
Una delle scene più complesse da realizzare è indubbiamente stata quella relativa all’orchestra. In questa
viene proposto all’utente un gioco nel quale deve indovinare, ascoltandoli, alcuni strumenti dell’orchestra.
Per la realizzazione del gioco sono state sfruttate appieno le caratteristiche avanzate del Plot editor, in
particolare gli operatori logici.
Quando l’utente dà il via con un comando vocale, una variabile todo viene settata a 1: essa corrisponde allo
strumento corrente.
Ecco il blocco iniziale per la partnza del gioco. Si noti come la variabile “todo” venga inizializzata a 1
A questo punto viene chiamata una Action che suona condizionalmente il file audio relativo. L’utente può
provare in ogni momento a dire il nome dello strumento, a questo punto verrà attivato un Vocal Command e
un blocco logico che controlla che il comando vocale sia effettivamente corrispondente allo strumento
attuale. Si veda come esempio come la Errore. L'origine riferimento non è stata trovata.. L’Action
“ascolta” controlla qual è lo strumento corrente ed esegue il file audio associato, nel caso particolare in cui
siano stati indovinati tutti gli strumenti verrà eseguito un file finale. Esaminiamo il blocco relativo al comando
vocale per indovinare il violino. Se l’utente dice “violino”, il blocco condizionale controlla che il violino sia
effettivamente lo strumento corrente: nel caso questo sia vero, l’avatar comunicherà all’utente il successo e
la variabile todo verrà settata allo strumento successivo. In caso contrario, l’avatar comunica l’insuccesso.
Alla fine del blocco viene semplicemente richiamata l’action, a prescindere dall’esito.
Questo semplice gioco risulta particolarmente interessante sia dal punto di vista educativo sia
dell’interfaccia: infatti la possibilità di interagire con comandi vocali, come se si stesse parlando con una
persona, permette all’utente di concentrarsi solo sul gioco (ad esempio sull’ascolto dello strumento da
indovinare), senza essere disturbato da possibili mediazioni dell’interfaccia (dover fare click su qualcosa
ecc.): dal punto di vista educativo questo permette di avere un feedback immediato e di interagire col
sistema in maniera naturale e con i propri ritmi.
Nella figura seguente, a sinistra: spezzone dell’Action relativa alla riproduzione degli strumenti da indovinare.
A destra: blocco comando vocale relativo al violino
WP6.3 Conclusioni
Abbiamo descritto le attività svolte nell’ambito del progetto VOCS. Il lavoro è stato organizzato in diverse fasi
riassumibili in: progettazione della storia, reperimento e creazione dei contenuti, realizzazione della storia.
La prima fase ha visto un lavoro di analisi del settore culturale e musicale con particolare attenzione agli
aspetti didattico-educativi legati alle attività svolte dall’Accademia e conseguente progettazione della storia,
relativa alle attività del Museo di Strumenti Musicali. Nella fase successiva si è proceduto alla creazione del
database di contenuti sia estraendoli e adattandoli dagli archivi multimediali dell’Accademia, sia creandoli ad
uopo. Infine l’ultima fase ha visto la creazione vera e propria della storia tramite il software VOCS, con un
processo iterativo di scambio con i partner coinvolti nel progetto e di adattamento in itere dei contenuti ove
necessario. Attraverso la tecnologia VOCS è stato quindi possibile creare con successo un’applicazione
multimediale con interazione vocale per il Museo di Strumenti Musicali mirata ai ragazzi: essa permette di
presentare in maniera intuitiva e interessante alcuni aspetti salienti della storia e del patrimonio culturale
dell’Accademia attraverso un coinvolgimento attivo dell’utente e riducendo le barriere tradizionalmente
create dai metodi d’interazione tradizionale con le tecnologie (ad esempio tastiere, mouse ecc.): riducendo
tali barriere il sistema è in grado di incrementare le capacità didattico-educativa e divulgative del Museo, e quindi – potenzialmente di attirare un maggiore e più variegato numero di visitatori.
Appendice: Rete di cooperazione tra imprese e organismi di ricerca.
Secondo quanto previsto dal progetto, le attività di implementazione della rete di cooperazione tra imprese e
organismi di ricerca sono state avviate come attività di un vero e proprio Laboratorio, da sperimentare come
luogo fisico e virtuale di collegamento tra le esigenze di innovazione delle PMI del territorio e le potenzialità
innovative dell’attività di ricerca.
Si è, quindi, proceduto in primo luogo ad attivare un gruppo di lavoro composto da rappresentanti di
imprese, organismi di ricerca, associazioni, partecipanti alla rete insieme alle due imprese proponenti,
Mediavoice SrL e Digital Video SpA, e al Dipartimento di Ingegneria dell’Informazione, Elettronica e
Telecomunicazioni – DIET – dell’Università di Roma La Sapienza (già Dipartimento Infocom e ora
denominato DIET a seguito della fusione con il Dipartimento di Elettronica), che svolge anche specifica
attività di ricerca per la realizzazione del progetto, con la finalità di realizzare l’organizzazione di incontri,
workshop, eventi con le strutture partecipanti, per scambi di idee, di esperienze, confronti tra le buone
pratiche e i casi aziendali di successo.
Hanno partecipato, in particolare, a tale primo nucleo costituito del gruppo di lavoro, rappresentanti del
Dipartimento di Ingegneria Elettronica dell’Università degli Studi Tor Vergata di Roma, dell’Associazione
Università Ricerca Innovazione Società – AURIS onlus –, delle aziende operanti nel settore dell’ICT e della
multimedialità CoMetis S.r.l., Ingegneria 2000, Videoprogetti SrL.
Il gruppo di lavoro ha operato fin dalla sua costituzione come un punto di riferimento collegiale di scambio e
di confronto, realizzato in modo anche informale, con scambi frequenti di idee e di informazioni, nella logica
di far crescere la conoscenza individuale e collettiva e di sperimentare nuove forme organizzate di
collaborazione. Si è posto, però, fin da subito l’obiettivo di ampliare ed estendere la partecipazione ad altri
soggetti imprenditoriali e di ricerca che operano nel campo dell’ICT e della multimedialità, e in particolare a
quelli fortemente proiettati verso l’innovazione, ponendo anche attenzione a compagini di ricercatori
impegnati nella costruzione di spin off universitari e, quindi, geneticamente orientati al collegamento tra
ricerca e sviluppo di processi di innovazione e trasferimento tecnologico. Si sono realizzati numerosi incontri,
contatti via web, riunioni ad hoc, nelle quali è stato esaminato lo stato di avanzamento tecnico scientifico del
progetto VOCS-NET, in particolare, sotto il profilo dei risultati delle attività di ricerca, ma, più in generale, è
stato avviato uno scambio di informazioni e conoscenze sullo stato dell’arte e le prospettive di evoluzione
della ricerca tecnologica nel campo dell’ICT e, sul piano più specificamente imprenditoriale, sulle prospettive
produttive e di mercato delle attività innovative sviluppate e in corso di realizzazione da parte delle imprese
coinvolte.
Si è, successivamente, proceduto a progettare le linee di azione del piano operativo per la realizzazione
della rete di cooperazione, secondo le quali sono state sviluppate le attività, riassunte schematicamente
come di seguito:
-
realizzazione sistematica nel Laboratorio per la costruzione della rete di cooperazione di scambi,
confronti di idee, esperienze, tra i soggetti del mondo della ricerca e i soggetti del mondo
dell’impresa, finalizzati anche ad identificare progressivamente contenuti e azioni per i quali
organizzare forme di collaborazione stabile;
-
ricognizione delle realtà di ricerca e imprenditoriali del settore dell’ICT e della multimedialità
contattabili e coinvolgibili nei momenti di confronto e scambio di idee e problematiche del
Laboratorio per la costruzione della rete di cooperazione, anche al fine di identificare i soggetti da
includere nella rete di cooperazione o con i quali, comunque, costruire forme di comunicazione e
connessione con caratteri di continuità;
-
azioni di sensibilizzazione del mondo della ricerca, con particolare attenzione alla creazione di
contatti con giovani laureati e laureandi con competenze tecnologiche nel settore dell’ICT e della
multimedialità e orientati all’impegno in attività innovative;
-
iniziative di contatto e scambio con spin off universitari costituiti o in corso di costituzione operanti
nel settore dell’ICT e della multimedialità;
-
azioni di contatto con altre reti di cooperazione tra organismi di ricerca e imprese nell’obiettivo di
costruire utili sinergie, sia per lo sviluppo di processi di innovazione, che per incrementare le
potenzialità di mercato;
-
analisi e approfondimento della nuova forma del “Contratto di Rete” come possibile linea di
evoluzione generabile nell’ambito della costituenda rete di cooperazione tra organismi di ricerca e
imprese.
A seguito di tali attività si è giunti alla definizione dell’Agreement di Rete che prevede
l’attivazione tra tutti i partecipanti di una collaborazione tecnico-scientifica per lo sviluppo di
attività di ricerca industriale e di sviluppo sperimentale nel campo delle tecnologie ICT e
multimediali e delle loro diverse applicazioni in ambito civile. Prevede, inoltre, la disponibilità di
tutti i partecipanti a promuovere, anche su proposta di una delle parti, conferenze illustrative
concernenti le attività svolte; tirocini formativi e/o professionali, partecipazione a bandi e
avvisi pubblici e privati, sia nazionali, che internazionali, riguardanti il campo di collaborazione
tecnico-scientifica individuato. Nello spirito di estensione della rete di collaborazione, prevede,
infine, di accettare la partecipazione alla rete di collaborazione, di due spin off universitari del
Dipartimento DIET, in corso di costituzione, che saranno denominati il primo MediaMove e il
secondo ICTinnova, e che saranno entrambi costituiti in forma di SrL, nonché di accettare la
partecipazione alla rete di collaborazione di altre aziende e altri enti di ricerca che ne facessero
richiesta e con i quali sarà ritenuto possibile attivare positive sinergie tecnologiche e/o
commerciali.
Momento particolarmente significativo nella creazione della Rete di cooperazione è stata la
realizzazione dell’evento, svolto in data Venerdì 22 giugno 2012. L’evento, dal titolo
“UNIVERSITA’, RICERCA, IMPRESA IN RETE PER L’INNOVAZIONE E LO SVILUPPO”, si è svolto
presso l’Auletta del Chiostro della Facoltà di Ingegneria Università la Sapienza a San Pietro in
Vincoli. L’evento è stato realizzato come un incontro aperto, con la partecipazione di
rappresentanti del mondo dell’università e della ricerca, del mondo dell’impresa e di enti e
istituzioni locali.
I temi trattati hanno riguardato le problematiche relative alle difficoltà economiche dell’Italia e
all’urgenza di far ripartire un trend di crescita stabile, necessariamente alimentato dallo
sviluppo diffuso di processi di innovazione che si innestino nel tessuto produttivo italiano,
costituito in massima parte da PMI. E’ stato sottolineato come occorra attivare iniziative e
interventi che, anche a partire dai territori, vedano come protagonisti gli attori centrali della
filiera dell’innovazione, il mondo dell’università e della ricerca, il mondo dell’impresa, con il
coinvolgimento degli enti preposti al sostegno della ricerca e dell’innovazione, con particolare
attenzione alle PMI, in modo da accrescerne la competitività e favorirne
l’internazionalizzazione. E’ stata evidenziata l’importanza di creare nella regione Lazio
opportunità e facilitazioni per l’attivazione di rapporti e reti di collaborazione tra mondo
dell’università e della ricerca e PMI e tra PMI con vocazioni tecnologiche sinergiche, e di
sostenere e incentivare la costituzione e la vitalità di spin off tecnologici e accademici.
Nel corso dell’evento è stato presentato e firmato l’Agreement di Rete di Cooperazione tra PMI
e Organismi di Ricerca, creata nell’ambito del progetto “Voice On Content Storyteller - VOCSNET”.
All’evento hanno partecipato, tra gli altri, il Direttore del Dipartimento DIET e delegato
Università la Sapienza per i rapporti con le PMI, il Direttore Generale Sviluppo Lazio SpA, la
FILAS SpA, il Vice Presidente del Parlamento Europeo, insieme a tutte le realtà che, con le due
imprese promotrici Mediavoice SrL e Digital Video SpA, hanno sottoscritto l’Agreement di
Rete, il Dipartimento DIET, l’Associazione AURIS onlus, Mantrics S.r.l., Digital Video S.p.A.,
I4E2 SrL, Quadra TV SCARL, Cosmic Blue Team S.p.A, Ingegneria 2000 SrL, nonché numerosi
rappresentanti di imprese del Lazio, di associazioni, di Dipartimenti universitari, di spin off
universitari.
Allegato: Agreement di creazione di una rete di collaborazione, promossa da Digital Video S.p.A e
da Mediavoice SrL, nell’ambito del progetto “Voice On Content Storyteller - VOCS-NET -.
Conclusioni
Prototipi
Alla conclusione del progetto, e’ disponibile un prototipo perfettamente funzionante e completo di tutte le
funzionalità previste. Con tale prototipo è stata realizzata una storia completa che verra’ presentata in un
evento che si svolgerà nei prossimi mesi presso la sede di Santa Cecilia.
Risultati ottenuti
Tutti i task relativi al progetto sono stati completati nei tempi previsti.
Attualmente, per il progetto Vocs, non sono in corso registrazione di brevetti.
5
Coordinate bancarie
Banca:
Banca Intesa S. Paolo S.P.A. - Filiale di Roma 28
Indirizzo:
Via Tiburtina 582, 00159 Roma
C/C n.
100000004400
IBAN:
IT88 O 03069 03218 100000004400
Intestazione del c/c:
ABI
03069
CAB
03218
CIN
O
DIGITAL VIDEO SPA
Data
Timbro e firma
(del legale rappresentante)
Allegati:
-
Rendicontazione amministrativa dei costi sostenuti, secondo la modulistica e la guida predisposte da Filas
S.p.A., corredata da :
allegato 1 : Dichiarazione in autocertificazione liberatoria del fornitore e beni nuovi di fabbrica;
allegato 2 : Dichiarazione in autocertificazione attestante i requisiti dell’impresa;
allegato 3 : Dichiarazione in autocertificazione attestante i requisiti del progetto;
allegato 4 : Dichiarazione in autocertificazione attestante la data di fine progetto (solo per richiesta a saldo);
allegato 5 : Dichiarazione in autocertificazione prototipo (solo per richiesta a saldo);
allegato 6 : Dichiarazione in autocertificazione attestante le spese generali sostenute;
allegato 7 : fac simile time sheet
Informativa ai sensi dell’art. 13 DLGS. 196/2003 (codice della privacy)
In conformità al decreto legislativo 30 giugno 2003 n. 196 (Codice in materia di protezione dei dati personali)
e successive modifiche, FI.LA.S. S.p.A., con sede in Roma, Via della Conciliazione, 22, in qualità di titolare
del trattamento, è tenuta a fornire ai soggetti interessati, ai sensi dell’art. 13, le seguenti informazioni
riguardanti l’utilizzo dei relativi dati personali.
INFORMAZIONI CIRCA IL TRATTAMENTO DEI DATI RACCOLTI
1) Modalità di raccolta dei dati personali
I Suoi dati personali saranno raccolti presso tutte le sedi di Filas S.p.A., con o senza l’ausilio di modalità
telematiche, e trattati, con modalità anche automatizzate, anche ai fini della loro inclusione in una banca di
dati, ed in ogni caso con strumenti idonei a garantirne la sicurezza e la riservatezza.
2) Finalità del trattamento dei dati personali
I dati saranno trattati da Filas S.p.A. e da società del gruppo Filas per le seguenti finalità:
a) per l’adempimento ad obblighi di legge, regolamenti e normative comunitarie cui è sottoposta la FI.LA.S.
S.p.A., o i servizi da Voi richiesti (fatturazione, documentazione necessaria per l’attivazione dei finanziamenti
pubblici, valutazione e finanziabilità del progetto, revisione contabile, ecc.);
b) per dare esecuzione a contratti nei quali siete parte, o ad obblighi scaturenti dagli stessi, o per acquisire
informazioni precontrattuali attivate su Vostra richiesta (garanzie, fidejussioni, merito di credito, ecc.);
c) per altre finalità gestionali ed organizzative interne (programmazione delle attività, ecc.);
3) Modalità di trattamento dei dati personali
In relazione alle indicate finalità, il trattamento dei dati personali avviene mediante strumenti manuali ed
informatici, telematici o comunque automatizzati con logiche strettamente correlate alle finalità stesse e,
comunque, in modo da garantire la sicurezza e la riservatezza dei dati stessi.
4) Conferimento dei dati personali
Il conferimento dei dati personali è obbligatorio per le finalità relative agli adempimenti di cui al precedente
punto 2.
L’eventuale rifiuto di conferire e/o autorizzare il trattamento dei dati per le suddette finalità comporterà
l’impossibilità della instaurazione, prosecuzione del rapporto e/o valutazione del progetto.
La successiva eventuale opposizione o revoca al trattamento dei dati personali per le suddette finalità
comporterà l’impossibilità della prosecuzione del rapporto e/o valutazione del progetto.
5) Categorie di soggetti ai quali i dati possono essere comunicati con il consenso dell’interessato
I Suoi dati personali non saranno diffusi e/o comunicati a terzi, salvo che ai seguenti soggetti ai fini esclusivi
dello svolgimento del Servizio:
• Enti, od Amministrazioni Pubbliche, anche Comunitari, il cui intervento è previsto da leggi, regolamenti e
normative comunitarie o dalle convenzioni o accordi in base ai quali opera la nostra Società;
• liberi professionisti anche in forma associata o società che operano per nostro conto valutazioni di
progetto, incluso il possesso di requisiti per l’attivazione di fondi pubblici;
• società di consulenza amministrativa, organizzativa e gestionale (società di revisione, società di
consulenza informatica, ecc.);
• professionisti e società di recupero crediti.
• società che svolgono servizi bancari, finanziari ed assicurativi;
• società controllate, collegate o comunque appartenenti allo stesso gruppo, ai fini dello svolgimento del
Servizio.
Tutti i soggetti appartenenti alle categorie ai quali i dati possono essere comunicati utilizzeranno i dati in
qualità di “Titolari” ai sensi della legge, in piena autonomia.
L’ambito di diffusione territoriale dei Suoi dati sarà limitato al territorio dell’Unione Europea.
6) Titolare e responsabile del Trattamento dei dati in base all’art. 4 lett. f) e lett f) del D.lgs. 196/2003
Titolare del trattamento è FI.LA.S. – Finanziaria Laziale di Sviluppo – S.p.A., con sede in Roma, Via della
Conciliazione, 22 – 00193 Roma, cap. soc. 35.857.000,00 Euro, iscritta presso il Registro delle Imprese di
Roma al n. 398087.
Il responsabile al quale Lei può rivolgersi per l’esercizio dei diritti di cui al successivo punto 7 è il
Responsabile dell’Area Gestione Agevolazioni, domiciliato per la carica presso la sede di Filas di Via della
Conciliazione, 22 – 00193 Roma, tel.: 06.328851, fax: 06.36006808, e-mail: [email protected].
Un elenco aggiornato dei responsabili del trattamento è disponibile su Sua richiesta presso la sede legale di
Filas.
7) Diritto di accesso ai dati personali ed altri diritti in base all’art. 7 D.lgs. 196/2003
1. L'interessato ha diritto di ottenere la conferma dell'esistenza o meno di dati personali che lo riguardano,
anche se non ancora registrati, e la loro comunicazione in forma intelligibile.
2. L'interessato ha diritto di ottenere l'indicazione:
a) dell'origine dei dati personali;
b) delle finalità e modalità del trattamento;
c) della logica applicata in caso di trattamento effettuato con l'ausilio di strumenti elettronici;
d) degli estremi identificativi del titolare, dei responsabili e del rappresentante designato ai sensi del
precedente punto 6;
e) dei soggetti o delle categorie di soggetti ai quali i dati personali possono essere comunicati o che possono
venirne a conoscenza in qualità di rappresentante designato nel territorio dello Stato, di responsabili o
incaricati.
3. L 'interessato ha diritto di ottenere:
a) l'aggiornamento, la rettificazione ovvero, quando vi ha interesse, l'integrazione dei dati;
b) la cancellazione, la trasformazione in forma anonima o il blocco dei dati trattati in violazione di legge,
compresi quelli di cui non è necessaria la conservazione in relazione agli scopi per i quali i dati sono stati
raccolti o successivamente trattati;
c) l'attestazione che le operazioni di cui alle lettere a) e b) sono state portate a conoscenza, anche per
quanto riguarda il loro contenuto, di coloro ai quali i dati sono stati comunicati o diffusi, eccettuato il caso
in cui tale adempimento si rivela impossibile o comporta un impiego di mezzi manifestamente
sproporzionato rispetto al diritto tutelato.
4. L 'interessato ha diritto di opporsi, in tutto o in parte:
a) per motivi legittimi al trattamento dei dati personali che lo riguardano, ancorchè pertinenti allo scopo della
raccolta;
b) al trattamento di dati personali che lo riguardano a fini di invio di materiale pubblicitario o di vendita diretta
o per il compimento di ricerche di mercato o di comunicazione commerciale.
Lei potrà esercitare in qualsiasi momento e gratuitamente i diritti previsti dall'art. 7 del Dlgs. 196/2003
rivolgendosi al Titolare del trattamento.
DICHIARAZIONE DI CONSENSO
Spettabile FILAS S.p.A.,
Io sottoscritta/o ________________________, con la presente, ad ogni effetto di legge e di regolamento, ed
in particolare ai sensi del Decreto Legislativo 30 giugno 2003, n. 196, preso atto dell’informativa fornita
dichiaro di prestare il mio libero, consapevole, informato, specifico ed incondizionato consenso al
trattamento dei miei/nostri dati, ivi compresa la comunicazione ai soggetti di cui al punto 5
dell’informativa, ai fini esclusivi dello svolgimento del Servizio e per le finalità di cui al punto n. 2
dell’informativa
Data
Timbro e firma del Legale Rappresentante