WP1:Specifiche funzionali e realizzative del progetto MESI 1-12

Transcript

1 RELAZIONE TECNICA INTERMEDIA 1 SAL PERIODO DAL 1 OTTOBRE 2010 AL 1 OTTOBRE 2011 ATI: Digital Video SpA (Capofila) MediaVoice srl TITOLO DEL PROGETTO: VOCS Voice On Content Storyteller COSTO ,08; CONTRIBUTO ,00 IMPRESA /ERP Sede operativa 1) Digital Video S.p.A Via Sante Bargellini Roma 2) MediaVoice S.r.l. via Laurentina Roma 1) STATO DI ATTUAZIONE DELL INTERVENTO 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.

2 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.x 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.x.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.x.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 ).

3 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.

4 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.x.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

5 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.x.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 pre-registrate, 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

6 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

7 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: 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 Drag n drop file-folder interface Selects utterances from sets or single grammars Multiple/Unique utterance views Play utterance Sortable, configurable utterance lists 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:

8 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

9 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 alle 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 e , 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

10 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).

11 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.x.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

12 - 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:

13 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 non-comprensione, 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.

14 - 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 natural language shortcut Get Transfer Amount Once Corrected Originating Account Destination Account Is amount > originating balance? Yes Play Bad Amount Message Transfer Amount No 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.

15 4000_GetTransferDate DialogModule Entering from Errore. L'origine riferimento non è stata trovata., Errore. L'origine riferimento non è stata trovata. Prompts Type Name Wording Date (Previously ALTdmCustomContext) Initial funds_transfer_date_initial "When would you like to transfer these funds? If yoùd like to transfer the 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 future date like October 31st." Retry 1 funds_transfer_date_initial_reprompt "Please say when you would like to transfer these funds." Retry 2 funds_transfer_date_reprompt "Please say when you would like to transfer funds one more time. If yoùd lik e to transfer funds immediately, say 'today'. If you would like to 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 'October thirty first,' 'next thursday,' or 'two weeks from yesterday.'" Option Vocabulary DTMF Action Confirm. Date <date_string> N/A Go to: Errore. L'origine riferimento non è stata trovata." Confirmation Prompts Option Name Wording Result Date Commands Default confirmation, as handled by the Date DialogModule I think you said < >, is that correct? See default settings, as specified in Errore. L'origine riferimento non è stata trovata. on page Error! Bookmark not defined.. Module Settings Allow Barge-in Never 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.

16 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 runtime RPA Transact, il quale genera, automaticamente e in real-time, pagine dinamiche di VoiceXML ad ogni turno di interazione. WP 1.x.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:

17 - 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.x.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

18 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 call-flow 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.x.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 è

19 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.

20 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.x.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 uomomacchina è 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 è

21 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, [2] Aiello D., C. Delogu, R. De Mori, A. Di Carlo, M. Nisi, S. Tummeacciu, Automatic Generation of Visual Scenarios for Spoken Corpora Acquisition, 5 th 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 [4] Nuance Dialog Modules: [5] SpeechCycle Partner Portal: [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] [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, [13] Ward, Wayne & Sunil Issar, "Recent improvements in the CMU spoken language understanding system", ARPA Human Language Technology Workshop, [14] Ward, Wayne & Sunil Issar, "Recent improvements in the CMU spoken language understanding system", ARPA Human Language Technology Workshop, [15]

22 [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 [18] Companions Project: [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), September, 2010, University of Tokyo, Tokyo, Japan, pp [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 [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 [23] Botond Pakucs, Butler: A Universal Speech Interface for Mobile Environments, Internal Report Centre for Speech Technology (CTT), KTH, [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, pp WP 1.x 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.x.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

23 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 riconnettere, 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 life-long 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.

24 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

25 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.x.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

26 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

27 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

28 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

29 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

30 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à extrascolastiche, 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

31 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.x.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 Banaszewski, T. Digital storytelling finds its place in the classroom, MultiMedia Schools, January/febbruary 2002 Joe Lambert: Digital Storytelling: 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, 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

32 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, 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.

33 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.x 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.x.1 La Story e lo Story Editor

34 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:

35 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.x.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.

36 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.x.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.

37 È 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.x.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.

38 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 con l utilizzo di Block (tratto dal software open source SCRATCH) 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

39 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

40 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.x.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.x.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.

41 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.

42 WP 1.x.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.x.8 Struttura della Story Riportiamo nei 2 diagrammi seguenti la struttura della Story cosi come é stata descritta nel documento:

43 STORY SCENE SCENE SCENE STAGE PLOT CAST ACTION ACTION ACTION CAST CONTENT CONTENT CONTENT BEHAVIOUR ACTION ACTION ACTION

44 WP1.x 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.x.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.

45 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.x.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 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.

46 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.x Uno studio preliminare su un software per lo storytelling interattivo: 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.x.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 )

47 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.x.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.

48 - 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.x.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

49 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 si gratta la testa; frame 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.

50 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: IDLE Frames % State: IDLE1 Frames % State: IDLE2 Frames 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 State: IDLE Frames 1-10 State: TAKE-GUITAR Frames State: IDLE- WITH-GUITAR Frames 51-60

51 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, invece che 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

52 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

53 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 ON VOCAL COMMAND show museum movie ELSE IF movie_seen UNDEFINED Avatar SPEAKS museum.mp3 Avatar SPEAKS museum2.mp3 SET movie_seen TO 1 PLAY history.avi il significato del blocco di controllo e evidente. Notare che la variabile viene definita onthe 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

54 HIDE guitar.png avatar EXECUTE take-guitar Avatar SPEAKS guitar description.mp3 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 guitar sorry1.mp3 Avatar SPEAKS guitar sorry2.mp3 Avatar SPEAKS guitar sorry3.mp3 Avatar SPEAKS guitar sorry4.mp3

55 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 description1.mp3 HIDE arrow1.png guitar SHOW arrow2.png PLAY description2.mp3 HIDE arrow2.png guitar SHOW arrow3.png PLAY description3.mp3 guitar HIDE arrow3.png PLAY guitar description end.mp3 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:

56 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. WP3 Sviluppo: Design e realizzazione avatar MESI 9-21 Il WP3 e' in corso di realizzazione, in una fase iniziale. 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.

57 Questo Work Package e' in corso di realizzazione 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 struemnti 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. Si e' voluto quindi realizzare un personaggio animato, rappresentante un professore sui anni, dall'aspetto non troppo serioso. Dei primi studi sul personaggio hanno portato ad alcune ipotesi, rappresentate nella seguente figura: Infine la scelta dell'avatar da usare e' stata rpesa, ed e' stato realizzato il turnaround completo, come da figura:

58 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. 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 diseganta e interagisce con la parte grafica dell Avatar.