RICHIESTA EROGAZIONE AGEVOLAZIONI - mediavoice.it Vocs SAL finale.pdf · riconoscimento automatico...

Spett.le

FI.LA.S. S.p.A.

Via della Conciliazione, 22

00193 Roma

Progetti di RSI delle PMI - POR FESR Lazio 2007/201 3

Asse I – Attività I.1

RICHIESTA EROGAZIONE AGEVOLAZIONI

□ I SAL

x SALDO

Dati anagrafici della richiedente:

Denominazione: Digital Video S.p.A.

Forma giuridica: Società per Azioni

Indirizzo: via Sante Bargellini 4, 00137 ROMA

Codice fiscale e/o Partita IVA: C.F. 05163320582 P.I. 01365181005

N. Telefono +39 06 4325 2306 N. Fax +39 06 4356 8516

Nominativo Referente Claudio MATTEI

Richiesta

Erogazione del contributo di Euro

Atto di 29 settembre 2010 prot. n. 252

Codice CUP F87I0000380007

Titolo del progetto: VOCS – Voice On Content Storyteller

Dettaglio costi sostenuti 3

1

2

Voci di Spesa Ricerca Industriale

(€)

Sviluppo Sperimentale

(€)

Reti di cooperazione

(€)

a. Personale (ricercatori, tecnici e altro personale ausiliario) nella misura in cui è impiegato nel progetto

39,405.92 169,753.46 0,00

b. Acquisizione di nuove strumentazioni ed attrezzature utilizzate per il progetto

1,020.76 992.78 0,00

c. Ricerca contrattuale, competenze tecniche, brevetti servizi di consulenza e servizi equivalenti utilizzati ai fini dell'attività di ricerca.

23,030.00 120,485.00 0,00

d. Materiali di consumo funzionali ai progetti di ricerca

1,356.98 0.00 0,00

e. Spese generali 6,857.43 30,765.51 0,00

Totale spese 71,681.08 321,996.75 0,00

Relazione sull'attività di ricerca svolta

WP1:Specifiche funzionali e realizzative del proget to MESI 1-12 Il WP1 e' stato completato entro la la scadenza assegnata (1 Ottobre 2011) La descrizione estesa del WP1, come da specifiche di progetto, e' la seguente: WP1 Analisi: Specifiche funzionali e realizzative del progetto. In questo Work Package vengono definite in modo dettagliato le specifiche della piattaforma: ambiti di utilizzo, organizzazione contenuti e archivio, meccanismi di interazione vocali e non, modalità di creazione dello storytelling, caratteristiche dell’Avatar, interfaccia prototipo finale. E prevista una parziale sovrapposizione con alcuni WP realizzativi, per permettere una fase di test preliminare delle specifiche realizzate.

WP1.1 Introduzione e descrizione svolgimento lavori .

La prima fase del progetto e' consistita nella raccolta e studio dello stato dell'arte negli ambiti di ricerca riguardanti lo storytelling, i meccanismi di dialogo vocale, le tecniche di speech recognition e la sintesi vocale. Una volta acquisite le conoscenze necessarie, si sono messe a punto le caratteristiche funzionali del software, per poi passare allo sviluppo delle specifiche realizzative di questo, sia per quanto riguarda la creazione della storia, l'organizzazione dei contenuti multimediali, che per quanto riguarda la messa a punto del sistema di I/O vocale. Durante la messa a punto delle specifiche funzionali, si e' inoltre realizzato un Use Case, cioe' la simulazione della costruzione di una storia interattiva reale. Nell'Use Case si e' simulato il workflow di un autore nella costruzione della storia, le modalita' di creazione e interazione con gli avatar, la messa a punto dei meccanismi vocali di interazione. I prossimi paragrafi descriveranno e documenteranno le varie attività appena descritte.

WP 1.2 Stato dell'arte nel Dialogo Vocale per appli cazioni mobili e multimediali Mediavoice, in collaborazione con Infocom, la Fondazione Ugo Bordoni e Cultorale, hanno realizzato uno studio sullo stato dell'arte dei meccanismi di interazione vocale per applicazioni mobili e multimediali.

WP 1.2.1 Il dialogo vocale

La voce è il più semplice, comune ed efficiente mezzo di comunicazione utilizzato dagli essere umani per interagire tra loro. Per questo motivo sarebbe confortevole e naturale poter interagire con i dispositivi attraverso il parlato, piuttosto che tramite le attuali periferiche di input (principalmente mouse e tastiera). Tale motivazione ha portato i ricercatori a concentrare gli sforzi sullo sviluppo di sistemi in grado di effettuare il riconoscimento automatico del parlato (ASR – Automatic Speech Recognition), così da permettere ai dispositivi di identificare parole a partire dai suoni e trasformarle in testo o in comandi. Sistemi di questo tipo

4

trovano applicazione in molti ambiti, come dettatura, controllo, assistenza telefonica, traduzione automatica…

Come sarà chiaro in seguito, la costruzione di un sistema di riconoscimento del parlato diventa sempre più complessa, a causa del sempre più avanzato grado di perfezione che si vuol raggiungere, che punta a coprire il più elevato numero di parlatori e il più vasto numero di applicazioni. Infatti, l’obiettivo è costruire un sistema ASR in grado di risultare indipendente dall’utente che lo utilizza, di possedere un vocabolario infinito e di funzionare indipendentemente dalle modalità di dettatura che l’utente utilizza. Così, dal riconoscimento di poche parole, piccole frasi, si è giunti alla possibilità di avere a che fare con sistemi ASR in grado di adattarsi al parlatore e riconoscere un elevato numero di parole, enunciati, testi, in varie lingue. La direzione futura dello sviluppo punta a ottenere un sistema real-time, con accuratezza del 100%, capace di riconoscere ogni parola intellegibile, pronunciata da chiunque, anche in presenza di rumore e in qualsiasi lingua e accento.

WP 1.2.2 Classificazione dei sistemi di riconoscime nto del parlato

I sistemi di riconoscimento del parlato si possono suddividere in varie categorie, sulla base del tipo di pronuncia che sono in grado di riconoscere, del modello “aculinguistico” cui fanno riferimento, del vocabolario di termini che possono essere riconosciuti.

In base al tipo di pronuncia riconoscibile, è possibile classificare i sistemi ASR nelle seguenti categorie:

• Sistemi per parole isolate

I riconoscitori di parole isolate sono in grado di accettare in ingresso un suono continuo che presenti silenzio all’inizio e al termine della finestra di campionamento, ovvero dell’intervallo sul quale viene effettuata l’acquisizione audio. Tali sistemi trovano applicazione in tutti quei casi in cui all’utente è richiesto un comando o una risposta; l’implementazione di questi sistemi è evidentemente la più semplice, anche perché il comando dell’utente è appositamente pronunciato in maniera chiara e precisa (es. “Stampa” , “Esci”).

• Sistemi per parole connesse

I riconoscitori di parole connesse sono un’evoluzione dei sistemi per parole isolate, permettendo di riconoscere brevi enunciati connessi con una minima pausa. Questi sistemi sono utili per tutte quelle operazioni di comando/controllo che richiedono, ad esempio, di operare una certa azione su un determinato elemento (es. “Apri Calcolatrice” , “Riproduci Musica”).

• Sistemi per parlato continuo

I riconoscitori di parlato continuo permetto all’utente di parlare in modo quasi-naturale, mentre il dispositivo discrimina il contenuto del parlato. L’implementazione di questi sistemi è più complicata, in quanto il parlato viene emesso in modo sufficientemente complesso dal punto di vista dell’articolazione, della fusione delle parole, della pronuncia, della quantità di termini pronunciabili.

• Sistemi per parlato spontaneo

I riconoscitori di parlato spontaneo permettono all’utente di parlare in modo naturale, essendo in grado di controllare e gestire tutta la varietà di caratteristiche del parlato umano, come errori di pronuncia, esitazioni, sovrapposizioni. L’implementazione di questi sistemi è notevolmente complicata in quanto richiedono potenze di elaborazione elevate e modelli di funzionamento di tipo articolato.

I sistemi ASR necessitano della creazione di un modello del parlato, dovuto al fatto che ogni parlatore è unico nel suo sistema vocale organico e nella sua personalità vocale. Infatti, per ogni parlatore, si deve considerare una serie di caratteristiche psico-fisiche che rendono il modello molto complesso (struttura fisica del cavo orale, velocità e stile del parlato, sesso, età, ambiente socioculturale…). Sulla base della tipologia di modello vocale utilizzato, i sistemi ASR si possono suddividere in:

• Sistemi dipendenti dal parlatore

I riconoscitori dipendenti sono implementati per uno specifico parlatore. Questi sono perciò molto accurati per quel parlatore e generalmente inefficienti per altri; sono solitamente poco elaborati dal punto di vista della complessità del modello, ma sono limitati dal punto di vista della flessibilità nell’utilizzo. Nei sistemi commerciali, in fase di installazione, il sistema chiede all’utente di leggere un

testo noto con voce e velocità naturali. Il sistema si adatta così alle caratteristiche del parlatore, offrendogli risultati sempre migliori in termini di precisione.

• Sistemi indipendenti dal parlatore

I riconoscitori indipendenti sono sistemi progettati per una molteplicità di parlatori o, nel più delle volte, per essere completamente scorrelati dal parlatore. Per questo motivo sono in grado di riconoscere input provenienti da un vasto gruppo di persone; a questo scopo, l’accuratezza dei sistemi indipendenti è in parte limitata, a favore di un più flessibile campo di applicazione. La loro capacità di riconoscere più parlatori, però, ne aumenta la complessità dal punto di vista del modello elaborativo.

Infine, sulla base dell’entità del vocabolario di termini riconosciuti, i sistemi ASR si possono suddividere in:

• Sistemi a vocabolario ridotto - decine di parole

• Sistemi a vocabolario medio - centinaia di parole

• Sistemi a vocabolario grande - migliaia di parole

• Sistemi a vocabolario molto grande - decine di migliaia di parole

• Sistemi fuori vocabolario - in grado di mappare parole sconosciute in parole del vocabolario

WP 1.2.3 Principi generali di funzionamento

Il compito principale di un sistema ASR è quello di acquisire una forma d’onda sonora come ingresso e produrre come output una stringa o un insieme di parole. Lo schema di principio di un sistema di riconoscimento del parlato si può presentare come segue.

Un generico sistema ASR si compone di tre fasi: nella fase di pre-elaborazione vengono estratte le caratteristiche relative alla traccia vocale acquisita, relativamente alla velocità, all’intonazione, alle pause (questa fase può anche attuarsi una sola volta, nel periodo di addestramento del sistema); nella successiva fase di decodifica vengono applicati i modelli acustici e linguistici che si hanno a disposizione, sulla base delle caratteristiche ottenute nella fase precedente, allo scopo di effettuare una ricerca all’interno del vocabolario in merito alle informazioni decodificate; infine, nella fase di post-elaborazione vengono identificati i migliori match tra input vocale e stringa testuale allo scopo di costruire l’output finale. È chiaro come tutte le fasi siano fondamentali per la qualità complessiva del sistema.

In ogni caso, il funzionamento di un generico sistema ASR si basa sulla comparazione dell’audio in ingresso, opportunamente elaborato, con un database pre-registrato (speaker independent) oppure creato in fase di addestramento del sistema (speaker dependent), allo scopo di ricercare la parola pronunciata dal parlatore all’interno del database stesso. Questa operazione può essere effettuata sulla parola intera o sui singoli fonemi. Alcune problematiche, però, rendono questo procedimento incredibilmente complesso: ogni volta che una persona pronuncia la stessa parola, lo fa in modo differente, non producendo mai lo stesso suono per uno stesso fonema; mentre l’orecchio umano è dotato del cosiddetto “ascolto intenzionale” che gli permette quasi di isolare il suono che si vuole ascoltare dal sottofondo, per i sistemi ASR ogni rumore di fondo è un elemento fortemente disturbante che inficia sul risultato del processo; il suono di ogni fonema, inoltre, cambia a seconda del fonema che lo precede e che lo segue.

Tecniche di estrazione delle caratteristiche vocali L’estrazione delle caratteristiche vocali è una delle fasi più importanti del processo di riconoscimento del parlato, in quanto è essenziale per separare correttamente le parole e fornirle come input ai processi successivi. Ogni voce ha caratteristiche differenti e individuali che si rispecchiano nella pronuncia. Queste caratteristiche possono essere estratte attraverso varie tecniche, che comunque devono rispettare alcuni criteri; esse infatti, devono permettere di misurare facilmente le caratteristiche estratte, devono possedere caratteristiche stabili nel tempo (stesse tracce vocali devono presentare sempre stesse caratteristiche), devono essere il più possibile indipendenti dall’ambiente di acquisizione (mostrare solo piccole fluttuazioni tra un ambiente e l’altro per una stessa traccia).

Una delle più potenti tecniche di analisi è il metodo della codifica a predizione lineare (LPC – Linear Predictive Coding ), che è diventato uno dei metodi principali per la stima dei parametri di base della voce, in quanto fornisce anche un prototipo computazionale della voce di rilevante funzionalità. Per questo motivo, questa tecnica viene usata in genere in molte attività di elaborazione dei segnali audio e vocali, allo scopo di rappresentare l’inviluppo spettrale del segnale vocale. Il modello vocale su cui si basa la tecnica LPC strutturato in maniera tale da considerare la voce come un segnale potuto, caratterizzato da una precisa intensità e frequenza, sul quale vengono inseriti (a causa del movimento della bocca e della lingua) una serie di disturbi di tipo definito (sibili, pop). Un campione vocale, inoltre, si può sempre approssimare come una combinazione lineare di vecchi campioni. È così possibile determinare una serie di parametri e coefficienti caratteristici dell’apparato vocale e di alcuni campioni di riferimento, utili a determinare, o meglio prevedere, campioni futuri. Ovviamente, maggiore è il numero di campioni acquisiti, maggiore è l’accuratezza della previsione. I coefficienti così determinati vengono trasformati e normalizzati in un set più robusto di parametri che prendono il nome di coefficienti cepstrali.

Un’altra tecnica ampiamente utilizzata è quella MFCC (Mel Frequency Cepstral Coefficients ), che si basa su un modello di tipo logaritmico che, rispetto a quello lineare usato in altre tecniche di rappresentazione del segnale vocale, è capace di approssimare molto meglio il sistema vocale umano. Diversamente da quanto accade nella LPC, il segnale vocale, dopo essere stato catturato e finestrato, subisce una trasformazione di frequenza (in genere una DFT) e viene sottoposto a un banco di filtri triangolari equispaziati centrati su particolari frequenze (mel frequency). Le ampiezze dello spettro determinato vanno a costituire il vettore MFCC. Alcune varianti di questa tecnica prevedono modifiche delle spaziature delle frequenze, dell’ampiezza dei filtri e delle tecniche di trasformazione/antitrasformazione in frequenza (ad esempio coseno discreto). I valori MFCC non sono molto resistenti dal punto di vista del rumore; sono stati ideati, perciò, alcuni stratagemmi per ridurre l’influenza del rumore, come ad esempio la normalizzazione dei valori in potenza per eliminare i contributi a bassa energia (essenzialmente rumore).

WP 1.2.4 Evoluzione negli approcci di riconoscimento del par lato 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 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 si stema automatico di dialogo

Attuali approcci del riconoscimento del parlato

La funzione del modulo di riconoscimento vocale é quella di convertire il segnale vocale, proveniente da un microfono o dalla linea telefonica, e opportunamente digitalizzato, in una stringa di testo corrispondente alla sequenza di parole pronunciate e estratte da un vocabolario definito in precedenza. Il vocabolario e la grammatica devono essere definiti a priori, quindi il riconoscitore non può riconoscere parole estranee al vocabolario. Allo stato dell’arte dei riconoscitori commerciali si possono riconoscere vocabolari di decine di migliaia di parole usando grammatiche per regole o usando grammatiche statistiche. Nei sistemi commerciali, ad ogni turno di dialogo c’é una grammatica (in genere a regole, ma sempre più frequentemente negli ultimi anni, statistica) definita in modo da coprire tutte le possibili risposte al prompt definito per quel turno. Nei sistemi di ricerca, invece, il vocabolario e la relativa grammatica (tipicamente statistica e a grande copertura) sono gli stessi per tutti i turni di interazione, quindi non viene cambiata al cambiare dello stato del dialogo. In alcuni sistemi la grammatica viene adattata utilizzando un corpus raccolto durante la messa in opera (tipicamente centinaia o migliaia di frasi registrate e trascritte durante la fase operativa del sistema).

La comprensione del linguaggio

La funzione del modulo di comprensione del linguaggio é quella di convertire la rappresentazione testuale della frase di ingresso (generata dal riconoscimento vocale) in una rappresentazione semantica. Ci sono svariati modi per rappresentare la semantica, ma il più comune, utilizzato nei sistemi di dialogo, è quello basato su key-value pairs. Per esempio, la seguente richiesta:

“Voli da Milano a Roma nel pomeriggio di Domenica 28 Novembre”

può essere rappresentata semanticamente con i seguenti key-value pairs (slots):

RICHIESTA: VOLO; ORIGINE: MI; DESTINAZIONE: ROMA; ORARIO: 12:00-18:00; DATA: 28-11

Per classificazione semantica si intende il processo di assegnazione, ad una frase di input, di una categoria (o classe) appartenente a un dizionario di categorie semantiche ben preciso.

Il numero delle categorie semantiche é in genere determinato dalla applicazione. Ma si possono usare classificatori che prescindono dall’applicazione e assegnano una categoria da una lista più ampia delle effettive categorie semantiche utilizzate.

Per la classificazione semantica é necessario un corpus che contenga un numero sufficiente di esempi testuali di frasi (dette “trascrizioni”), ciascuno associato a un identificatore di tipo semantico (detto “annotazione”) (Figura 2). Il corpus viene utilizzato da un algoritmo di training che produce i parametri di un classificatore in grado di assegnare automaticamente un tag.

12

Drag’n drop file-folder interface

Sortable, configurable utterance lists

Multiple/Unique utterance views

Play utterance

Update transcription/annotation

Manage lists of semantic categories

Selects utterances from sets or single grammars

Offline download/upload capabilities

Figura 2: Esempio di sistema di trascrizione e anno tazione.

La fase di acquisizione del corpus è particolarmente delicata se si vuole poter addestrare adeguatamente il classificatore. Questa acquisizione può essere effettuata in modi diversi:

1. Utilizzando la tecnica del Mago di Oz [1] e [2], che è stata molto usata nei primi sistemi commerciali. Oggi è un po’ caduta in disuso, sia per il costo di addestramento dell’operatore (Wizard), sia per la migliore qualità ottenuta da una annotazione offline e la possibilità di rivedere l’annotazione in fasi successive. Il Mago di Oz è una simulazione che permette di avere dati sull'interazione tra il parlante e la macchina senza avere a disposizione un sistema di dialogo. La simulazione consiste nel far interagire un utente con una macchina “finta”, impersonata dallo sperimentatore (chiamato wizard), senza che il primo ne sia a conoscenza. Le precondizioni per ottenere dei dati utili sono tre: i. deve essere possibile simulare il sistema (ad es. se il sistema gestisce un database, il database deve essere disponibile); ii. deve essere definito come si comporterà il sistema; iii. la simulazione deve essere convincente. La tecnica WoZ prevede l’utilizzo di operatori addestrati i quali, in tempo reale, comprendono la richiesta dell’utente e instradano la chiamata alla terminazione telefonica corretta, nel caso di “call routing”, oppure interagiscono con un sistema computerizzato che permette loro di associare la frase ad una “tag” semantica appropriata. Mentre l’utente ha la percezione di interagire con un sistema automatico (il prompt é sintetico, o registrato), l’operatore (wizard), esegue in tempo reale la funzione di annotazione, e può interagire con il sistema automatico simulando, lui stesso, il sistema di “comprensione del linguaggio”. I dati così raccolti vengono poi utilizzati per l’addestramento.

2. Annotazione offline. Le frasi di training possono venire acquisite in modi diversi, a seconda che si disponga di un sistema online o meno (per esempio un vecchio sistema IVR, o un sistema esistente con riconoscimento vocale ma per il quale si voglia progettare una variante che prevede la comprensione del linguaggio).

a. Nel caso non si disponga di un sistema di dialogo in linea, occorre reclutare i soggetti con particolare attenzione alla loro estraneità allo sviluppo del sistema in questione. I soggetti devono appartenere, al meglio possibile, alla distribuzione statistica degli utenti del sistema in progetto. I soggetti devono essere istruiti alla esecuzione di un compito simile a quello in progetto, con particolare attenzione a non creare delle “cue” linguistiche che possano suggerire ai soggetti certe parole o forme verbali, e quindi costituire un “bias” del corpus (per esempio si possono proporre scenari in modo visuale o schematico, senza istruire i soggetti “parola per parola” su quello che devono dire). Il problema di questo tipo di collezione di corpus deriva dal fatto che i soggetti istruiti ad eseguire un compito “virtuale” si comportano in modo diverso da utenti reali con una vera e propria motivazione ad usare il sistema.

b. Nel caso si disponga di un sistema in linea da utilizzare come meccanismo di collezione del corpus, si può inserire nel sistema un prompt per la raccolta della frase richiesta. Per esempio, si assuma di avere un sistema IVR (per favore selezioni 1 per informazioni sul suo credito attuale, 2 per acquistare più crediti, 3 per ...), e si voglia usare questo sistema per acquisire un corpus da utilizzare per un centralino a linguaggio naturale. Si può inserire all’inizio della transazione, prima del primo prompt, un prompt che richiede una frase in linguaggio naturale, per esempio “Per favore mi dica il motivo della sua chiamata”. Poiché il sistema di comprensione non esiste ancora (deve essere ancora creato basandoci sul corpus), il sistema di acquisizione non reagisce alla frase del chiamante, ma la registra semplicemente, per poi passare il controllo al sistema IVR (Grazie. Per favore selezioni 1 per informazioni sul suo credito attuale, 2 per acquistare più crediti, 3 per ...) o turno seguente. Il progetto del prompt di acquisizione é molto importante, e deve essere effettuato con cautela.

Lo scopo della acquisizione, trascrizione, e annotazione di un corpus di frasi é sia quello di creare un modello del linguaggio (grammatica) statistico, sia quello di creare un classificatore semantico in grado di produrre una o più tag semantiche su ciascuna frase di input. Per un buon sistema di classificazione semantica con un numero di valori semantici inferiore ai 100, si richiedono dalle 5.000 alle 10.000 frasi campione. Ovviamente con corpora di maggiori dimensioni si possono ottenere prestazioni più elevate.

La prima fase del processo richiede la trascrizione di ciascuna frase del corpus. Questa viene effettuata da trascrittori che devono essere addestrati, almeno marginalmente, sul contenuto generale delle frasi del corpus. In particolare deve essere fornita loro una lista delle parole meno comuni che potrebbero essere trascritte erroneamente, e dei termini specifici del contesto utilizzato. Questa lista deve essere aggiornata periodicamente da un “manager di trascrizione”, il quale provvede al controllo di qualità delle trascrizione mediante campionamento e controllo. La lista deve includere anche parole che possono essere trascritte in modi diversi, per esempio email e e-mail, e fornire indicazioni sulla trascrizione accettata. Inoltre, é necessario creare uno standard di trascrizione che preveda simboli per parti della frase incomprensibili, parole interrotte o ripetute, e rumore.

Al contrario della trascrizione, l’annotazione richiede personale specializzato che abbia una comprensione, seppur minima, del contesto e della applicazione. Nella prima fase del progetto di annotazione é necessario creare una “guida di annotazione” che includa una lista completa delle tag semantiche e una spiegazione del significato di ciascuna (per esempio alcuni esempi di frasi). La guida di annotazione deve essere riveduta periodicamente insieme agli annotatori.

La generazione del linguaggio

La maggior parte dei sistemi di dialogo non usa un modulo di generazione del linguaggio sofisticato. Infatti, la quasi totalità dei sistemi commerciali usa prompt registrati quando l’informazione del prompt non é variabile. In caso di informazione variabile (per esempio quando il prompt include una data, un numero, una località, o il nome dell’utente), si usano sistemi di generazione molto semplici, basati su templates, o ibridi

che utilizzano template e macchine a stati finiti. La generazione del linguaggio per sistemi di dialogo é un area di ricerca che é stata trascurata da anni, ed esiste molto poco in letteratura. Recentemente sono stati sviluppati dei metodi statistici di generazione del linguaggio. La generazione della voce

La maggioranza dei sistemi di dialogo commerciali usa prompt registrati da un attore. La registrazione dei prompt viene gestita dal progettista VUI che segue l’attore in modo da dare al prompt l’intonazione richiesta dal sistema. Nel caso il prompt sia costituito da porzioni con informazione variabile, e l’informazione sia riducibile ad un numero di elementi limitati (per esempio una data o un numero), il prompt viene diviso nelle corrispondenti porzioni (incluso gli elementi variabili) che vengono registrati separatamente. In fase operativa il prompt viene assemblato in tempo reale. Per la costruzione di prompt con informazione variabile si usa la tecnica del “concatenative prompt recording” (CPR), nella quale le varie porzioni del prompt vengono registrate in versioni multiple con tipi diversi di intonazione. L’esempio tipico é quello dei numeri. Ogni digit viene registrato in tre versioni, con intonazione ascendente (se in inizio frase), piatta (se centrale) o discendente (se a fine frase). In fase di assemblaggio vengono scelte le porzioni con l’intonazione corretta in funzione della posizione di ogni singolo digit nella frase. Nel caso in cui l’informazione variabile nel prompt non é limitata (per esempio il nome di un prodotto da una estesa lista di prodotti, o il nome dell’utente da un database di utenti), si deve ricorrere all’utilizzo di un sistema di TTS (text-to-speech). In alcuni sistemi di alta qualità i prompt vengono assemblati con porzioni registrate e porzioni sintetizzate da un TTS creato sulla stessa voce dell’attore.

La gestione del dialogo

La funzione del modulo di gestione del dialogo é quella, ad ogni turno, di ricevere i segnali di ingresso (le tag semantiche dalla comprensione della voce, e eventuali informazioni provenienti dai sistemi esterni) e generare comandi per l’esecuzione della prossima attività del dialogo (per esempio la generazione di un prompt, o l’esecuzione di comandi sui sistemi esterni). Per fare questo il modulo di gestione deve mantenere il contesto, sotto forma di variabili che vengono accumulate durante il corso del dialogo. I sistemi di gestione del dialogo si possono categorizzare in tre classi fondamentali:

1. Sistemi di controllo a macchina a stati finiti ricorsiva (call-flow). Questi sono la stragrande maggioranza dei sistemi commerciali, dove il dialogo é gestito da un “call flow”, rappresentato come una macchina a stati finiti, tipicamente gerarchica. Ogni nodo rappresenta sia una attività (per esempio la generazione di un prompt o la richiesta di informazioni a un database), oppure il ricorso a un sotto-dialogo, rappresentato a sua volta da un’altra macchina a stati finiti. Nei sistemi moderni, un nodo corrisponde ad un modulo di dialogo che gestisce tutte le funzioni discorsive relative alla richiesta di un elemento informativo, come per esempio il re-prompting e la conferma.

2. Sistemi basati su inferenza. Questi sono tipicamente sistemi di ricerca dove il compito del dialogo viene specificato in modo dichiarativo, e una macchina inferenziale seleziona le azioni opportune in modo da completare il task.

3. Sistemi stocastici basati sul machine learning. Questi sistemi sono basati su strategia di machine learning, tipicamente reinforcement learning. Il task viene descritto tramite un sistema di rewards, e algoritmi di reinforcemente learning imparano a selezionare le azioni in modo da massimizzare il reward globale. Poiché il training richiede migliaia di interazioni, non é possibile utilizzare utenti reali, ma si usa un “utente simulato”.

Nel campo commerciale e in ricerca si distinguono due tipi di dialogo caratterizzati dai termini “dialogo diretto” e il “dialogo a iniziativa mista”. Nel dialogo di tipo diretto i prompt di sistema istruiscono il parlante a rispondere in modo ben preciso, per esempio suggerendo risposte, sia in modo diretto che indiretto, o facendo domande alle quali la risposta é chiaramente “si” o “no”. Questi sono esempi di prompt diretti:

Per favore selezioni una delle opzioni seguenti: informazioni sul conto, aprire un nuovo conto o pagamenti arretrati.

Ha ricevuto la visita del nostro tecnico? Per favore risponda si o no.

Nel caso di dialogo a iniziativa mista si lascia la libertà all’utente di esprimersi a suo piacimento (per esempio Per favore descriva brevemente il problema), ed anche di fornire informazioni che non sono state espressamente richieste dal prompt (Da quale città vuole partire? Vorrei partire da Genova al mattino).

Nello stato dell’arte nei sistemi di dialogo, specialmente quelli commerciali, la strategia prevalente é quindi quella di utilizzare open prompts quando sia necessario, e continuare il dialogo con richieste precise per la finalizzazione della transazione. Lo sviluppo di grammatiche statistiche permette, in ogni caso, di poter riconoscere espressioni estranee a quelle richieste esplicitamente dal prompt diretto, e quindi di conferire al dialogo una certa elasticità che lo avvicina alla iniziativa mista.

WP 1.2.5 Progetto e sviluppo di un sistema di dial ogo

Moduli di dialogo

I moduli di dialogo, o dialog modules, o semplicemente DM, sono i componenti fondamentali di sistemi di dialogo di arbitraria complessità. Per definizione, un DM è una funzione predisposta alla acquisizione di uno o più elementi di informazione in un turno di dialogo. Visto come una black-box, un DM, una volta invocato dal sistema di dialog management, esegue un certo numero di operazioni e ritorna il controllo al dialog manager in uno di due stati finali: informazione acquisita o fail. I DM esistenti in commercio (per esempio Nuance, o SpeechCycle RPA) sono progettati per l’acquisizione di informazioni specifiche, quali:

- SI’ o NO

- DIGITS

- NUMERI NATURALI

- CODICE FISCALE

- DATE

- QUANTITA’ DI VALUTA

- NOMI E INDIRIZZI

- NUMERI DI CARTA DI CREDITO

- DATE PER LA VALIDITA’ DELLE CARTE DI CREDITO

Una volta integrato in una applicazione, un DM specifico può essere configurato per l’applicazione. Per esempio un DM_Carta di credito può essere configurato per un tipo di carta specifica (per esempio Visa, Mastercard, o American Express), o un DM_Quantità di valuta può essere configurato per un ammontare minimo o massimo (per esempio dell’ordine delle decine, centinaia, o migliaia di Euro, a seconda dell’applicazione). Esistono anche DM_custom che possono essere configurati a piacimento per l’acquisizione di un qualunque tipo di informazione relativa a una particolare clientela [3], [4], [5].

Internamente un DM è un mini-dialogo, con una logica che prevede l’esecuzione delle seguenti funzioni (dette anche funzioni di “discourse”).

- Emissione del prompt iniziale

- Attivazione del riconoscitore con grammatica iniziale

- Gestione del time-out

- Gestione di livelli diversi di confidenza del riconoscimento

o Alta confidenza, DM esce con risultato

o Media confidenza, DM inizia dialogo di conferma

o Bassa confidenza, DM richiede l’informazione (reprompting)

- Gestione del dialogo di conferma

- Gestione del recognition rejection.

- Gestione del dialogo di reprompting

- Gestione della “lista delle esclusioni” dal vocabolario. Questa é utile quando una risposta é stata esplicitamente negata in un dialogo di conferma (per esempio Ha detto Aosta, è giusto? No.) e quindi questa risposta deve essere esclusa dalla grammatica nei turni seguenti per evitare di incorrere in un loop (Lo dica di nuovo, per favore. Ancona. Ha detto Aosta, giusto? No. OK. Lo ridica per favore. A N C O N A. Ha detto Aosta …)

- Configurazione di grammatiche in parallelo. Può essere utile avere grammatiche globali (per esempio richiesta di operatore, richiesta di aiuto) in parallelo a qualunque grammatica di “contenuto” del DM.

- Logging specifico di tutti gli eventi.

Attualmente i DM sono elementi relativamente complessi che possono essere configurati dal punto di vista funzionale nel modo seguente:

- Numero massimo di reprompt

- Conferma sempre, in caso di bassa confidenza, o mai

- Valori delle soglie di confidenza

- Valore della soglia di rigetto

- Grammatiche di contenuto e globali.

Per la messa in opera, un DM richiede un certo numero di prompt:

- Prompt iniziale

- Uno o più prompt di conferma, fino al numero massimo di conferme previsto.

- Uno o più reprompt, fino al numero massimo di reprompt previsto

- Prompt di fail.

Strategie alternative di gestione degli errori

La strategia di gestione degli errori tipica, descritta nella sezione precedente, é quella della correzione a due passi (two-step confirmation), così chiamata perché la correzione di un errore richiede non meno di due turni:

S: Dica il nome della città, prego

U: Ancona

S: Ha detto Aosta, è giusto? Per favore dica sì o no (STEP 1)

U: No

S: Dica di nuovo il nome della città, per favore (STEP 2)

U: Ancona

S: Sì. Ancona.

Un metodo alternativo é quello della correzione a un passo, come nel seguente esempio:

S: Dica il nome della città, prego

U: Ancona

S: Ha detto Aosta, è giusto? (STEP 1)

U: No, Ancona

S: Sì. Ancona.

Non esistono studi pubblicati sull’efficacia di questo tipo di correzione, ma uno dei problema é quello dell’accuratezza. La correzione a due passi ha una accuratezza alta per due motivi: il vocabolario SI/NO (Yes/No) ha una accuratezza quasi del 100%, mentre nel secondo passo si può usare una lista a esclusione—come spiegato in precedenza—ed escludere la parola negata (Aosta nell’esempio), evitando di incorrere nello stesso errore una seconda volta. Mentre questa seconda opzione é possibile anche nella correzione a due passi, l’accuratezza di riconoscimento di frasi di negazione seguite dalla correzione (no, è Ancona) é senz’altro inferiore rispetto a quella del vocabolario SI/NO. Quindi, anche se la durata del dialogo di correzione a un passo può essere inferiore, la sua accuratezza é più bassa della strategia a due passi. Il secondo problema é quello dell’indurre gli utenti ad eseguire una correzione ad un passo, quindi progettare un prompt che induca la maggior parte dei parlanti a usare una espressione di correzione del tipo no, è Ancona.

Alcuni lavori [6] propongono uno studio su strategie alternative di recovery da situazioni di 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.

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

Skip the following "Get"blocks if not needed...

Available Account are:Checking , Savings , andReserve Credit

Available Account are:Checking , Savings , andReserve Credit

Is amount >originatingbalance?

Play Bad AmountMessage

Yes

No

Transfer Verified?

Play Transfer Message(and balances if Date is

'today')

Yes

Get OriginatingAccount

Get DestinationAccount

Get Transfer Date

Main Menu

Play Verify TransferMessage

No

Originating Account

Destination Account

Transfer Amount

Transfer Date

naturallanguageshortcut

Get Incorrect Part

Funds TransferEntry

OnceCorrected

Get TransferAmount

OnceCorrected

Figura 3: Esempio di visione di insieme del diagram ma di flusso (parziale) di un sistema di dialogo durante il progetto VUI. Il call-flow riportato in questo esempio si riferisce ad una applicazione bancaria di SpeechWorks.

Ancora oggi molte aziende effettuano il progetto VUI compilando un documento che include una visione completa della topologia del dialogo, mediante una serie di moduli standard inizialmente adottati da SpeechWorks verso la fine degli anni ‘90, e poi estesi a quasi tutta l’industria. In questo tipo di specifica il progettista compila, in una prima fase, una visione di insieme del diagramma totale di flusso, come per esempio quella di Figura 3. In funzione della complessità del progetto, l’intera visione di insieme del sistema di dialogo può richiedere molti diagrammi di flusso. La seconda parte é la completa specifica di ciascun modulo di dialogo (corrispondente a un nodo del diagramma di flusso), mediante una tabella, come quella riportata in Tabella 1.

4000_GetTransferDate

DialogModule™ Date (Previously ALTdmCustomContext)

Entering from Errore. L'origine ri ferimento non è stata trovata. , Errore. L'origine ri ferimento non è stata trovata.

Prompts Type Name Wording

Initial funds_transfer_date_init ial "When would you like to transfer these funds? If yoùd like to transfer the funds immediately, please say 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_init ial_reprompt "Please say when you would like to t ransfer these funds."

Retry 2 funds_transfer_date_reprompt "Please say when you would like to t ransfer funds one more time. If yoùd like 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 become effective. You can say a date like 'October thirty first, ' 'next thursday,' or 'two weeks f rom yesterday. '"

Option Vocabulary DTMF Action Confirm. Date <date_string> N/A Go to: “Errore. L'origine ri ferimento non è

stata trovata. " Never

Confirmation Prompts Option Name Wording Result

Date Default confirmation, as handled by the Date DialogModule™

“I think you said <…>, is that correct?”

Commands See default settings, as specified in “Errore. L'origine riferimento non è stata trovata. ” on page Error! Bookmark not def ined. .

Module Settings Allow Barge-in

Tabella 1: Esempio di specifica completa di un modu lo del call-flow parziale di Figura 3.

Nello sviluppo tradizionale, la specifica, una volta completata, viene passata ai programmatori, i quali la implementano utilizzando uno dei seguenti metodi:

- VoiceXML statico

- VoiceXML dinamico. Sistema di sviluppo Web, per esempio Java Server Pages (JSP).

- VoiceXML dinamico. Sistema di sviluppo grafico.

In genere, oggi, si tende ad evitare lo sviluppo di sistemi basati su pagine statiche di VoiceXML, sia per la complessità (ad esempio un sistema di dialogo moderno può includere migliaia di pagine) associata alla difficoltà di gestione (in un sistema di pagine VoiceXML statiche, non é possibile avere una visione ad alto livello del call-flow). Quindi, nei sistemi moderni, si usano pagine di VoiceXML generate dinamicamente da un programma che contiene una descrizione grafica del call-flow.

Esistono, in commercio, diversi programmi grafici che consentono di creare una descrizione completa del call-flow (inclusi i prompts, le grammatiche, e le connessioni ai back-end esterni). Per esempio, il sistema RPA (Rich Phone Application) sviluppato e commercializzato da SpeechCycle, é basato sulla architettura mostrata in Figura 4.

Figura 4: Architettura di dialogo del sistema RPA ( SpeechCycle).

RPA Compose é un sistema grafico di progetto e sviluppo di un sistema di dialogo. Consiste in un plug-in per MS Visual Studio, e quindi utilizza tutte le feature di Visual Studio (Figura 5).

Figura 5: Esempio di sistema di sviluppo utilizzato all'interno di MS Visual Studio

Una volta terminata la specifica completa di un call-flow mediante RPA Compose, il sistema compila una meta-rappresentazione che viene poi interpretata dal sistema di run-time RPA Transact, il quale genera, automaticamente e in real-time, pagine dinamiche di VoiceXML ad ogni turno di interazione.

WP 1.2.6 Sistemi di dialogo Open Source Il pacchetto open-source più completo per lo sviluppo di sistemi di dialogo allo stato dell’arte é senz’altro Olympus [7], sviluppato alla Carnegie Mellon University (CMU) per il progetto Let’s Go Lab [8] e utilizzato anche da alcuni partecipanti al progetto Spoken Dialog Challenge [9].

Olympus é basato sulle tecnologie sviluppane alla CMU. In particolare:

- La gestione del dialogo é fatta da RavenClaw [10] basato su un sistema ad agenda [11]. Il sistema ad agenda é stato sviluppato diversi anni fa da Rudniky alla CMU e si basa su una descrizione “goal-oriented” del task. L’agenda viene mantenuta automaticamente e crea l’istanziazione delle azioni (per esempio “prompt”) che ottimizzano la risoluzione del goal più promettente.

- La gestione dell’interazione a basso livello, come nel calso dei “dialog modules” descritti in precedenza, viene eseguita dal sistema Apollo [12].

- Il riconoscimento della voce viene effettuato dal sistema di riconoscimento open source della CMU ( Sphynx).

- La comprensione del linguaggio dal sistema Phoenix [13].

- La generazione del linguaggio basata sul sistema Rosetta [14]

- La sintesi della voce basata sul sistema Kalliope.

- L’architettura su MIT Galaxy [15].

IN particolare, l’architettura Galaxy, sviluppata da MIT negli anni 1990, e prodotta e resa open source da MITRE in occasione del progetto DARPA Communicator, é basata su una HUB centrale che comunica con un numero arbitrario di servers plug-in. La HUB può essere programmata in modo da simulare una qualunque connettività (anche condizionale) fra i server (Figura 6).

Figura 6: Diagramma della architettura Galaxy.

WP 1.2.7 Valutazione del dialogo Misure oggettive delle prestazioni del dialogo

Al di la delle misure delle prestazioni di riconoscimento per ogni singolo turno, si possono sviluppare misure delle prestazioni globali oggettive, come il livello di automazione, il task completion rate o il transaction completion time, e il tempo medio di transazione (AHT o Average Handling Time). Nonostante alcune misure potrebbero richiedere una annotazione manuale, per esempio per stabilire il successo o meno del dialogo, si preferisce utilizzare metodi automatici (anche a scapito di una certa precisione nella misura), in quanto una qualunque valutazione manuale richiede tempo e lavoro, e quindi limita sia la possibilità di valutare grandi quantità di dialoghi in tempo reale, sia la possibilità di introdurre sistemi automatici di “machine learning” per l’ottimizzazione del sistema.

Correntemente si usano, sia nei sistemi commerciali che in quelli di ricerca, diversi metodi per assegnare misure oggettive sulle prestazioni di dialogo. Il metodo più efficace é quello di individuare dei nodi del 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.2.8 Nuove frontiere del dialogo vocale Dialogo multimodale

Nella realtà il dialogo vocale è sempre accompagnato da altre modalità di comunicazione. Noi parliamo e nello stesso tempo comunichiamo con i gesti, con le espressioni facciali, indichiamo oggetti presenti nella realtà circostante, e così via. Purtroppo però la commercializzazione di sistemi multimodali che comprendano anche il dialogo vocale è ancora molto limitata. Questa situazione potrà cambiare positivamente con la sempre più ampia diffusione degli smartphone o dei tablets, che favoriranno l’uso di interfacce multimodali che includano la voce [17].

Il progetto “Companion”, nato da un consorzio Europeo di 14 partners [18], mira alla realizzazione di un “compagno virtuale” utilizzando lo stato dell’arte delle tecnologie di dialogo sia vocale che multimodale. La differenza fondamentale fra un sistema di dialogo tradizionale e il dialogo sviluppato in Companions é che non c’é un unico compito, ma i compiti sono multipli, e nella conversazione si può passare da un compito a un altro. Questo obiettivo richiede uno studio accurato delle situazioni di dialogo e delle conseguenti strategie, incluse “empathy” e “positivity”, che non sono tipicamente considerante nello sviluppo di dialoghi “task oriented” di tipo commerciale. A questo proposito é interessante uno studio effettuato tramite Wizard of Oz da Nick Webb et al. [19], la cui conclusione richiama alla necessità di una maggiore comprensione del contesto.

L’architettura di uno dei sistema più sofisticati [20] si basa sul motore di dictation Nuance, seguito da un classificatore di sentimento (sentiment analysis) [21], con l’obiettivo di assegnare un valore allo stato emozionale dell’utente su una scala di 5 valori. In parallelo, un motore di comprensione di linguaggio naturale genera una analisi sintattica e semantica della frase. Il risultato é una valutazione dell’evento in contesto con valori emozionali dell’utente. Il modulo di gestione del dialogo (Dialog Manager) decide se a) fare una domanda riguardo all’evento b) esprimere una opinione, o c) generare delle frasi per esprimere empatia con l’utente. Quando, dopo un certo numero di turni, il sistema ha raggiunto una comprensione sufficiente dell’evento in contesto, genera un prompt complesso che esprime conforto, opinioni, e

suggerimenti, anche dettati dal contesto. Questo prompt é generato da un modulo specifico chiamato Affective Strategy Module [22].

Questo tipo di tecnologia “affettiva” può essere particolarmente utile per il progetto VOCS, per la progettazione dell’Avatar in grado di ascoltare e di parlare con una voce ‘emozionale’, di poter pronunciare in maniera particolarmente chiara i messaggi di più difficile fruizione. Il ruolo principale dell’Avatar, nel progetto, è infatti quello di rendere più facile il dialogo fra il sistema e l’utente, sia perché il sistema è in grado di simulare virtualmente una persona umana che parla, sia perché le informazioni fornite dai movimenti della bocca sono complementari a quelle acustiche percepite dalle orecchie.

Dialogo vocale integrato in dispositivi mobili

Fino a pochi anni fa, il riconoscimento del parlato all’interno dei telefoni cellulari era limitato alla possibilità di pronunciare il nome di dieci o al massimo venti persone e poterle così raggiungere telefonicamente, dopo una sessione di training. Naturalmente il successo della chiamata non era scontato, dipendendo sia da quanto la pronuncia del nome fosse simile a quella prodotta durante il training, sia da quanto l’ambiente in cui il sistema veniva usato fosse simile all’ambiente dove il sistema era stato addestrato, subendo quindi un vero e proprio crollo in ambienti rumorosi. Oggi, i più diffusi sistemi integrati comprendono applicazioni vocali in sistemi mobili e applicazioni da fruire in auto, applicazioni vocali per decoder, set-top-box, eBook reader, autobus e treni, apparati medicali, screen reader ed altri ausili per i disabili, computer industriali e militari, robot, bancomat, applicazioni di domotica, elettrodomestici, ed innumerevoli altri dispositivi di elettronica di consumo. Per quanto riguarda i sistemi mobili, l’esempio più noto è quello di Siri, l’assistente vocale introdotto recentemente da Apple con il nuovo iPhone 4S. Siri non vanta nessuna particolare innovazione tecnologica, basandosi infatti sullo stato dell’arte della tecnologia vocale, così come la conosciamo dalla fine degli anni ’70. La novità di Siri è quella di affacciarsi sul mercato al momento giusto, perfettamente integrata in uno degli strumenti più desiderati e popolari tra i consumatori, grazie anche alle applicazioni di ricerca vocale come quelle di Google e di Microsoft (Bing), e all’assistente vocale per Android, Vlingo, che hanno reso verosimile l’idea di parlare con il proprio SmarPhone. Le interfacce vocali integrate in sistemi mobili o in automobile pongono nuovi e interessanti problemi di usabilità [23]. Infatti l’interazione vocale con servizi di telefonia mobile si differenzia da quella con telefono fisso o con i computer desktop. Progettare e costruire interfacce vocali usabili integrate in sistemi mobili richiede di ripensare completamente l’interazione, dal punto di vista degli utenti e dell’ambiente in cui l’interazione avviene. Per quanto riguarda gli utenti va considerato che si tratta di utenti in movimento, con mani e occhi occupati. Per quanto riguarda l’ambiente di interazione, non si tratta di un ambiente definito a priori, ma bisogna prevedere che l’utente spostandosi si muova da un ambiente di un certo tipo a un altro con caratteristiche completamente diverse.

WP 1.2.9 Conclusioni

Nell’articolo, abbiamo presentato lo stato dell’arte del dialogo automatico [24]. E’ ovvio che siamo ancora lontani dal dialogo tra esseri umani. In questo caso, infatti, il dialogo avviene in modo libero, non vincolato. La principale differenza rispetto all’interazione uomo-macchina è che quella tra esseri umani è un’interazione aperta, dinamica, con più parlanti, ognuno con i propri scopi e che condividono conoscenze sull’ambiente in cui avviene il dialogo, sulle relazioni tra i partecipanti al dialogo, e così via.

La comunità scientifica ha sempre cercato di raggiungere la naturalezza nell’interazione con l'utente permettendo una sempre maggiore libertà di espressione [25].

Uno dei motivi di questo è che la tecnologia odierna non è ancora in grado di imitare la comunicazione umana con gli stessi livelli di precisione, robustezza, e efficacia. Infatti, se da una parte il riconoscimento e la comprensione del parlato commettono errori, dall’altra le interfacce utente sono ben lontane dall'efficacia degli esseri umani. Perché tutta questa tecnologia funzioni, è necessario imporre severe limitazioni agli obiettivi delle applicazioni, cosa che richiede una grande quantità di lavoro manuale per i progettisti. Queste limitazioni sono spesso non percepite dagli utenti e questo può creare un problema. Più il sistema esibisce un comportamento antropomorfo, infatti, più l'utente tende a sentirsi libero di esprimersi, e a pretendere una naturalezza che non è invece supportata dall'applicazione, creando così un divario tra l'utente e la macchina che porta ad inevitabili problemi di comunicazione.

E’ molto importante quindi per i sistemi di dialogo commerciali avere una Voice User Interface (VUI) ben

definita, seguendo il principio chiamato “completezza della VUI”. L'interfaccia VUI è completa quando il suo comportamento è completamente specificato rispetto a tutte le possibili situazioni che possono verificarsi durante l'interazione, comprese le frasi degli utenti e le risposte del sistema. Attualmente, al fine di garantire la completezza della VUI, è consigliabile arrivare alla specifica della completezza dell'interfaccia già nella fase iniziale di progettazione. L'unico paradigma di gestione del dialogo in grado di produrre interfacce VUI complete in modo semplice e riproducibile è quello funzionale rappresentato dal flusso di chiamata. Altri meccanismi più sofisticati, come quelli basati su inferenze o modelli statistici, richiedono complessità molto maggiore e maggiori costi per garantire la completezza VUI.

Presto tutti o quasi tutti utilizzeranno uno smartphone come principale strumento di comunicazione. La capacità di comprimere la voce sul dispositivo, inviarlo a un server remoto tramite un veloce collegamento dati 3G, e contemporaneamente visualizzare le informazioni, trasformerà il paradigma del dialogo vocale in una comunicazione wireless multimodale. Solo con l'aggiunta della componente visiva ad un sistema di riconoscimento vocale si potrà ridurre o rimuovere la maggior parte degli errori presenti nei sistemi di dialogo, che sono una delle cause principali della scarsa adozione dei sistemi vocali. L’applicazione prevista dal progetto VOCS, che dovrà funzionare in ambienti aperti, con più utenti interessati a dialogare col sistema, richiede lo studio di nuove soluzioni ai problemi di dialogo finora affrontati. L’applicazione dovrà essere in grado di coordinare con gli altri partecipanti al dialogo la presentazione e il riconoscimento dei segnali comunicativi, di rilevare, identificare, individuare e caratterizzare i partecipanti al dialogo. Al fine di progettare un’interfaccia come quella del progetto, è necessario estendere le tecniche di elaborazione del linguaggio naturale, solitamente utilizzati per sequenze lineari di discorso, con tecniche che prevedano l'integrazione e la comprensione del linguaggio multimodale, distribuiti su più modalità di input. Bibliografia

[1] Aiello, D., Cerrato, L., Delogu, C., Di Carlo, A., “The acquisition of a speech corpus for limited domain translation”, Proceedings of "EUROSPEECH '99", Budapest, September 1999, vol. 5, 2223-2226

[2] Aiello D., C. Delogu, R. De Mori, A. Di Carlo, M. Nisi, S. Tummeacciu, “Automatic Generation of Visual Scenarios for Spoken Corpora Acquisition”, 5th International Conference on Spoken Language Processing ICSLP 98, Sydney, November 30 - December 4, 1998, paper 0499

[3] Barnard, E., Halberstadt, A., Kotelly, C., Phillips, M., “A Consistent Approach To Designing Spoken-dialogue Systems,” Proc. of ASRU99 – IEEE Workshop, Keystone, Colorado, Dec. 1999.

[4] Nuance Dialog Modules: http://www.nuance.com/for-business/by-solution/customer-service-solutions/solutions-services/inbound-solutions/self-service-automation/dialog-modules/index.htm

[5] SpeechCycle Partner Portal: http://partners.speechcycle.com/

[6] Bohus, D., and Rudnicky, A., “Sorry, I Didn't Catch That! - An Investigation of Non-understanding Errors and Recovery Strategies”, in Proceedings of SIGdial-2005, Lisbon, Portugal.

[7] http://wiki.speech.cs.cmu.edu/olympus/index.php/Olympus

[8] Eskenazi, M., Black, A., Raux, A. and Langner, B. “Let's Go Lab: a platform for evaluation of spoken dialog systems with real world users”, Interspeech 2008, Brisbane, Australia

[9] Black, A., Burger, S., Langner, B., Parent, G., and Eskenazi, M. “Spoken Dialog Challenge 2010” Spoken Language Technologies 2010, Berkeley, CA

[10] Bohus, Dan & Alexander I. Rudnicky (2009), "The RavenClaw dialog management framework: Architecture and systems", Computer Speech & Language.

[11] Rudnicky & Wei Xu, "An agenda-based dialog management architecture for spoken language systems", IEEE ASRU Workshop (1999).

[12] Raux, Antoine & Maxine Eskenazi, "A Multi-Layer Architecture for Semi-Synchronous Event-Driven Dialogue Management", IEEE Automatic Speech Recognition and Understanding Workshop, 2007.

[13] Ward, Wayne & Sunil Issar, "Recent improvements in the CMU spoken language understanding system", ARPA Human Language Technology Workshop, 1994.

[14] Ward, Wayne & Sunil Issar, "Recent improvements in the CMU spoken language understanding system", ARPA Human Language Technology Workshop, 1994.

[15]http://communicator.sourceforge.net/sites/MITRE/distributions/GalaxyCommunicator/docs/manual/index.html

[16] Evanini, K., Hunter, P., Liscombe, J., Suendermann, D., Dayanidhi, K., Pieraccini, R., “Caller Experience: a Method for Evaluating Dialog Systems and its Automatic Prediction”, in Proc. of 2008 IEEE Workshop on Spoken Language Technology (SLT 08), December 15-18, 2008, Goa, India.

[17] R. Pieraccini, D. Suendermann, K. Dayanidhi, J. Liscombe, “Are We There Yet? Research in Commercial Spoken Dialogue Systems”, Text, Speech and Dialogue -- 12th Int'l Conference TSD 2009.

[18] Companions Project: http://www.companions-project.org/

[19] Bradley, J., Benyon, D., Mival, O. and Webb, N., “Wizard of Oz Experiments and Companion Dialogues”. Proc. Human Computer Interaction 2010 (HCI'10), 6-10 September 2010, Dundee, UK.

[20] Cavazza, M., Santos de la Cámara, R., Turunen, M., Relano Gil, J., Hakulinen, J., Crook, N., and Field, D. (2010), “How was your day? An Affective Companion ECA Prototype”, Proc. 11th Annual Meeting of the Special Interest Group on Discourse and Dialogue (SIGDial), 24-25 September, 2010, University of Tokyo, Tokyo, Japan, pp. 277-280

[21] Moilanen, K. and Pulman. S. (2009). “Multi-entity Sentiment Scoring”. Proc. Recent Advances in Natural Language Processing (RANLP 2009). September 14-16, Borovets, Bulgaria. pp. 258—263

[22] Cavazza, M., Smith, C., Charlton, D., Crook, N., Boye, J., Pulman, S., Moilanen, K., Pizzi, D., Santos de la Camara, R., Turunen, M., “Persuasive Dialogue based on a Narrative Theory: an ECA Implementation”, Proc. of the 5th Int. Conf. on Persuasive Technology 2010.

[23] Botond Pakucs, “Butler: A Universal Speech Interface for Mobile Environments”, Internal Report Centre for Speech Technology (CTT), KTH, 2005.

[24] Pieraccini R. “The Voice in the Machine: Building Computers That Understand Speech”, MIT Press, 2012

[25] Pieraccini, R. Huerta, J., “Where do we go from here? Research and Commercial Spoken Dialog Systems”, Proc. of 6th SIGdial Workshop on Discourse and Dialog, Lisbon, Portugal, 2-3 September, 2005. pp. 1-10

WP 1.3 Stato dell'arte nello Storytelling Digital, in collaborazione con Infocom , hanno realizzato uno studio sullo stato dell'arte dello storytelling nelle applicazioni software. Riportiamo un estratto dello studio in questione.

WP 1.3.1 Introduzione

In termini narrativi lo Storytelling è una metodologia che, usando i principi della retorica e della narratologia, crea racconti influenzanti in cui vari pubblici possono riconoscersi. Lo storytelling è oggi massicciamente usato dal mondo dell'impresa, dal mondo politico e da quello economico, per promuovere e posizionare meglio valori, idee, iniziative, prodotti, consumi. Le applicazioni di questa disciplina sono molte, dall’ambito della letteratura a quello della politica, da quello aziendale a quello scolastico. Il successo di questa disciplina è determinato dal fatto che il racconto è una forma di comunicazione naturale e intuitiva, capace di coinvolgere le persone.

Il termine “Digital Storytelling” si deve a Joe Lambert e Dana Atchley che negli anni '90 realizzarono un sistema interattivo multimediale all’interno di una performance teatrale dove su di un largo schermo sullo sfondo mostrava immagini e filmati di storie di vita. Il gruppo di artisti, educatori e professionisti della comunicazione che via via si costituì attorno a loro è riuscito negli anni ad allargare i campi di intervento del digital storytelling a molti contesti che spaziano dalla scuola alle aziende, dall’arte all’impegno politico. Il centro da allora ha aiutato molte persone ad utilizzare gli strumenti digitali per raccontare le loro storie di vita, dimostrando che le stesse tecnologie che hanno creato distanza e frammentazione potevano essere usate in modo nuovo per ri-connettere, creare nuovi legami, sentirsi partecipi di una comunità. La narrazione digitale diventa insomma un collante culturale. La diffusione dei computer e di Internet ha permesso uno sviluppo dello storytelling, il ricorso a blog, forum e social network infatti dà la possibilità di condividere le proprie esperienze. Attraverso questi mezzi è in grado di emergere un tipo di conoscenza dal basso, che può essere interessante. Una tendenza sviluppatasi con la rete è quella della condivisione delle proprie esperienze, e lo strumento informatico permette anche la pubblicazione di materiale multimediale. Internet permette inoltre di pubblicare testi e racconti in appositi siti, gratuita e priva della figura dell’editore. In molti casi l’industria editoriale ha funzionato da filtro, escludendo dalla pubblicazione molte opere, secondo canoni e criteri diversi. Sia per ragioni economiche, sia per questioni inerenti alla qualità dell’opera.

Tra le applicazioni più importanti dello storytelling c’è la pedagogia. Il ricorso a storie può essere infatti di facile comprensione per l’apprendimento del bambino. Nei libri scolatici delle scuole elementari infatti, per rendere semplice un concetto si ricorre ad una storia o a dei personaggi. Una tecnica simile è utilizzata

anche nei corsi di lingue, molti sono organizzati con dei personaggi, che tramite un dialogo o un testo mostrano un aspetto della lingua. La metodologia dello storytelling consiste nell'uso di procedure narrative al fine di promuovere meglio valori, idee ed è incentrato sulle dinamiche di influenzamento sociale. La narrazione ha un potenziale pedagogico e didattico, dalla quale possiamo trarne peculiarità educative e formative intendendole sia come strumento di comunicazione delle esperienze, sia come strumento riflessivo per la costruzione di significati interpretativi della realtà. Dare rilievo alla narrazione, ai racconti dei soggetti che vengono coinvolti nei processi educativi e formativi, rappresenta la svolta epistemologica sia per leggere fenomeni e processi (narrazione come strumento di ricerca), sia per produrre azioni e cambiamenti intenzionali (narrazione come strategia didattica). La narrazione è uno strumento per penetrare in profondità nelle cause e nelle ragioni di eventi, i particolari che vengono raccontati costruiscono una storia, diventano reali e determinano la storia stessa. Questa metodologia è una risorsa sia per l'educazione, sia per la formazione, promuove uno sviluppo generativo tra l'esperienza, l'osservazione della stessa e le intuizioni che ne derivano. Lo storytelling è fondamentale in diversi contesti educativi e formativi con la prospettiva di 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.

Fin dall'infanzia lo storytelling contribuisce in maniera notevole all'alfabetizzazione, in quanto è proprio la contestualizzazione di tale processo entro il quadro della narrazione che facilita la costruzione di senso intorno all'apprendimento complesso della scrittura e della lettura. Bisogna acquisire delle regole per comporre un testo. Il “raccontare” in forma narrativa strutturata permette di creare le basi dell'alfabetizzazione, ovvero una prima costruzione di significati condivisi tra adulto e bambino. È importante usare tale metodologia sin dalla prima scolarizzazione utilizzando i tipi di testualità adeguati al grado di alfabetizzazione dei bimbi. Da alcuni anni la metodologia dello storytelling ha trovato spazio anche nel campo della formazione degli adulti e dell'apprendimento a livello di istruzione superiore. Mc Druy e Alterio ci forniscono appunto interessanti argomentazioni in merito all'uso riflessivo sull'esperienza al fine di migliorare i processi di apprendimento. Utilizzando il metodo di raccontare storie, diventa possibile situare l'apprendimento nei contesti significativi e promuovere processi dialogici di interazione riflessiva attraverso lo sviluppo di contesti collaborativi.

Lo storytelling è una metodologia che usa la narrazione come mezzo creato dalla mente per inquadrare gli eventi della realtà e spiegarli secondo una logica di senso. L’atto del narrare, nello storytelling, si ritrova nell’esperienza umana e si può rappresentare in varie forme (individuali o collettive) che connettono pensiero e cultura. Soprattutto le emozioni dell’uomo – attraverso la narrazione – trovano il mezzo più efficace di espressione. Il pensiero narrativo possiede una molteplicità di significati, ma questi necessitano di essere tradotti, affinché si possano costruire una o più forma di comunicazione che siano rielaborate dai soggetti secondo i termini della narrazione. Il discorso narrativo permette di rendere comprensibile, comunicabile e ricordabile il vissuto. Quindi, il pensiero narrativo organizza l’esperienza soggettiva e interpersonale; mentre il discorso narrativo rende possibile la riflessione. Si tratta di un “processo interattivo” dal momento che il discorso narrativo rende possibili interpretazioni molteplici per tutti i soggetti che entrano in contatto con una certa storia. Attraverso il “racconto di storie” noi cerchiamo di “mettere ordine” e di dare un senso attivo alle nostre caotiche esperienze quotidiane. Il nostro “vissuto umano” prende forma, diviene comunicabile, comprensibile e può essere ricordato. Con il raccontare si compie una sorta di “collegamento”, dalla duplice funzione:

� Diretto all’interiorità: narrazione in funzione riflessiva;

� Rivolto al contesto in cui si è immersi

Lo storytelling si sviluppa a partire dall’assunzione di due principi fondamentali: l’organizzazione delle esperienze umane avviene grazie ai racconti e la narrazione è un processo che dota le persone di una sensibilità culturale che li mette in grado di attivare processi riflessivi e formativi, soprattutto nei gruppi. Il modo attraverso cui questi racconti vengono condivisi è il “discorso narrativo”, traduzione del “pensiero narrativo” di cui tutte le persone sono dotate. Il discorso narrativo, per essere efficace, deve possedere alcune caratteristiche specifiche: sequenzialità narrativa (l’ordine dato in un racconto può non riflettere lo svolgersi cronologico dei fatti reali, né la contingenza delle relazioni causa-effetto); particolarità (evidenziare dettagli che nella realtà potrebbero apparire poco o non significativi); intenzionalità; verosimiglianza (percezione che l’ascoltatore deve avere riguardo alla storia); componibilità (intreccio tra le varie parti del della narrazione e il suo insieme); referenzialità (si riferisce a quanto la storia possa essere plausibile); appartenenza a un genere (devono essere ben identificabili sia la fabula che l’intreccio).

Il discorso narrativo può esplicitarsi in varie modalità: orale, scritta, mediata. Il metodo più efficace sembra essere quello orale tuttavia anche gli altri due metodi si stanno rivelando fruttiferi. Il testo scritto si

caratterizza soprattutto per due elementi: temporalità degli eventi e causalità della concatenazione dei fatti. Aspetto fondamentale della narrazione dei racconti è l’interpretazione: l’utilità del raccontare storie ed ascoltarle sta nel momento in cui viene superato lo scenario dell’azione (quadro narrativo entro cui si dipana la storia) per integrarlo con lo scenario della conoscenza (insieme degli stati interni e dei punti di vista dei personaggi). Il nocciolo dello storytelling infatti sta nella correlazione che si instaura nella rappresentazione narrativa della realtà tra i processi di interpretazione, quelli di proiezione e quelli di riflessione. Da qui si sviluppa la metodologia dello storytelling, di cui l’idea di base nel suo utilizzo è lo sviluppo dell’apprendimento riflessivo (reflective learning). Essa è definita per fasi nella sua realizzazione:

� scelta della finalità e del target, (ossia definizione di quello che si vuole comunicare e a chi);

� definizione dei tempi, della disponibilità delle persone coinvolte ed eventuale possibilità di lavoro di gruppo;

� realizzazione (passa prima attraverso la scelta del genere e la stesura della sceneggiatura);

� feedback di valutazione da parte dell’audience.

WP 1.3.2 IL DIGITAL STORYTELLING

I Digital Storytelling sono brevi storie di carattere personale o accademico che i digital storytellers trasformano in video della durata di pochi minuti, aggiungendo la propria voce a immagini, titoli, effetti e transizioni che scorrono sullo schermo, a volte accompagnati da suoni o musica. La potenzialità di questo strumento sta nella possibilità che esso offre di coniugare due mondi fra loro molto diversi: da un lato storie, fiabe, racconti, narrazioni autobiografiche, dall’altro i nuovi media, gli strumenti tecnologici innovativi, computer, macchine fotografiche, telecamere e software come programmi di editing, di elaborazione delle immagini o dei suoni e così via. Con lo sviluppo dei media digitali si è assistito ad un processo di ri-mediatizzazione delle pratiche narrative tradizionali, le quali hanno acquisito una nuova forza e forma: combinando la logica ipertestuale con la strategia multimediale gli eventi sono trasformati in parole, immagini, suoni, video. L’impiego dei media nel racconto di storie amplifica le potenzialità espressive e comunicative della narrazione e fanno riemergere la caratteristica tradizionale delle storie di collante culturale in grado di creare aggregazione sociale. Il potere aggregante e coinvolgente delle narrazioni digitali è relazionato alle possibilità offerte dalla rete e dai software sociali che permettono la creazione di legami tra le persone impegnate in una rete di connessioni globale in cui partecipare attivamente per la produzione e circolazione di contenuti. Strumenti come web logs, youtube, flicker, social network, etc., permettono la condivisione da parte degli utenti di storie personali, di interpretazioni personali della realtà, ma anche di commentare e ampliare tali storie attraverso personali narrazioni. In questo modo la narrazione attraverso le tecnologie ricrea e rinsalda i legami sociali della comunità coinvolta e partecipe in una nuova dimensione narrativa per la costruzione di significati e interpretazioni condivise.

Le narrazioni digitali, come evidenziano Rodriguez Illera e Londono Monroy, hanno avuto una rapida diffusione che ha riempito ogni spazio della comunicazione, immergendoci in un universo narrativo che mescola differenti stili e canali comunicativi. Il presupposto di partenza per la produzione di un digital storytelling è che tutti hanno una storia da raccontare, le tecnologie potenziano il significato della storia da trasmettere, amplificando la voce del narratore. Da una ricognizione della letteratura di riferimento emerge che esistono due modelli di digital storytelling: un modello classico, sviluppato dal Center for Digital Storytelling di Berkley, che prevede la narrazione di storie autobiografiche in formati digitali attraverso un audio narrazione in prima persona e che presentano una struttura lineare e chiusa, simile a quella della narrativa tradizionale. L’altro modello, invece, è caratterizzato da una maggiore interattività, sono narrazioni, cioè, che offrono la possibilità di modificare la storia e co-costruirla divenendo co-autori, in quanto la struttura non è predefinita dall’inizio ed utilizzano, infine, più elementi mediali (immagini, testi, audio, video, musica) senza l’impiego di un audio narrazione. Le narrazioni digitali che appartengono al secondo modello rappresentano i digital storytelling di nuova generazione che utilizzano gli strumenti e sfruttano le potenzialità offerte dalla Web 2.0.

Le “story tales” possono essere definite come “blended telling stories with digital tecnology”. E’ il carattere blended che ne fa uno strumento didatticamente valido, perché unisce l’abilità della narrazione alle potenzialità tecnologiche. Leslie Rule definisce il digital storytelling come l'espressione moderna dell'antico mestiere di cantastorie. Una Digital tale è una breve narrazione (max 5 min) di un evento che integra diversi linguaggi: alcuni tipici della narrazione altri della sceneggiatura. L'alunno impostando la narrazione e la

sceneggiatura sviluppa alcune abilità: capacità di scrittura e di espressione orale, abilità tecnologiche e sensibilità artistica. Possono essere utilizzate immagini, fotografie, disegni (o altro materiale scannerizzabile) video, musica, la voce o effetti sonori. Gli elementi essenziali non sono che una semplificazione, un punto da dove cominciare perché ci sono infinite variazioni per costruire una narrazione digitale. Affinché uno storytelling possa dirsi efficace è necessario che la narrazione abbia una struttura interna familiare a chi la vedrà, in cui si possa identificare e in cui eventi e personaggi assumano un ruolo chiaro; è poi essenziale la presenza di fattori che la rendano personale e possano suscitare delle emozioni. Joe Lambert a tal proposito individua sette elementi che aiutano in un approccio personale allo storytelling: punto di vista personale, una struttura della narrazione che sorprenda domande e fornendo risposte non banali, inserimento di contenuti emotivi e coinvolgenti, un’efficace economia della narrazione (si può dire molto con poco), un ritmo adeguato alle modalità narrative. La storia non deve necessariamente avere un lieto fine, invece elemento importante e che accresce l’attenzione nell’utente è la percezione di autenticità.

Jason Ohler, molto incentrato sull’uso educativo delle digital story tales, pone l’accento sulla narrazione più che sulle nuove tecnologie: “una buona narrazione farà una buona digital story tell e non il contrario”. Sostanzialmente Jason Ohler utilizza due approcci. Il primo, “computer based” consiste nel basare la creazione di una storia principalmente attraverso il computer (immagine, musica, usando programmi come iMovie o Moviemaker). Nell'altro approccio, chiamato “sfondo verde” la storia viene narrata in modo tradizionale filmando il protagonista con uno sfondo neutro per poi integrarlo con i multimedia. Questa seconda soluzione facilita la didattica perché l’alunno fa un’ulteriore riflessione sull’uso delle nuove tecnologie. Alcune tecniche, affini alle Digital storytelling hanno in comune alcuni elementi. I video annotation prevedono l’interattività nel filmato o nelle immagini, cioè è possibile modificare il contenuto digitale creato dall’autore. I photolanguage: sono raccolti in dossier fotografici utilizzati a scopi didattici o di orientamento, ma non prevedono la voce narrante o le riprese. Il Digital storytelling è un metodo a sé stante che utilizza alcune tecniche già note come la narrazione e la sceneggiatura unendole con creatività e autenticità.

Le comunità di Digital tellers “sono le memorie della comunità, non la storia, non un archivio, non un liste di autorità ma una memoria vivente, la coscienza dell’identità collettiva intrecciata in centinaio di storie. Per parlare delle comunità è necessario parlare dei centri di formazione, essi stessi comunità di Digital Storytellers. Uno dei centri più accreditati a livello mondiale è il Center for Digital Storytelling negli Stati Uniti già citato sopra. Diretto da Joe Lambert con la collaborazione di Nina Mullen, ha organizzato decine di workshop, lavorando con molte comunità di adolescenti e di adulti intorno a un tema e una comunità. Un attività interessante del Centro sono i casi di studio dove vengono raccolte Digital storytells locale e orali su svariati temi come l'organizzazione sindacale, la prevenzione della violenza, l'handicap, i servizi sociali e salute ecc. E’ prevista una sezione dedicata all’educazione e all’uso delle Digital storytells nella didattica come ad esempio nell'insegnamento della lingua oppure l'educazione artistica. Un esempio è la comunità nata intorno alla Digital storytelling Iniziative del Public broadcasting for Northerm California (KQED). Più di 500 studenti delle scuole superiori partecipano al progetto “Coming California” sull’immigrazione in California. Quest’anno, il progetto include anche storie sul mito di sentirsi o essere della California. Il centro prevede altresì un workshop per gli insegnanti e un follow up nella scuola. Sostanzialmente, le Digital Storytells hanno la funzione di aggregare comunità. Un buon esempio è la comunità di volontari che si “raccontano” attraverso le digital story tellers.

L’Associazione Community Service Volunteers (CVS) che le rappresenta, è una delle più importanti associazioni di volontari in UK. Un altro punto di riferimento negli stati Uniti, è la Digital Storytelling Association che ha eredito del lavoro del fondatore, artista e cantastorie dei Digital storytelling Dana Winslow Atchley Negli anni ’80, ha condotto molti workshop, realizzando delle story tales anche per grande compagnie delle Usa come Coca Cola che si racconta attraverso digital story tale. Anche in Europa si sono sviluppate delle correnti. In Inghilterra Daniel Meadows circa 15 anni fa, ha creato Capture Wales and Telling Lives, il primo nucleo della BBC dedicato alle Digital story tales. Basandosi sulla propria esperienza di fotografo/documentalista ha anche un sito personale PhotoBus An adventure in documentary Photography.

Non è un caso che le narrazioni digitali siano nate negli Stati uniti dove costruire il proprio percorso di apprendimento è la norma, dove il docente è visto come uno allenatore che affianca l’alunno (Sclavi, 2003). Le materie disciplinari che potrebbero sviluppare il metodo sono molte. Il valore aggiunto delle narrazioni digitali sono molto chiare nel sito della Carnegie Mellon University. Mostra un frammento di una lezione di chimica in 3 versioni, la prima tradizionale, la seconda con l'immagine e la terza integrate in una narrazione digitale. Usare le nuove tecnologie in modo creativo permetterebbe all’alunno e al docente di costruire il materiale didattico insieme.

Le narrazioni digitali possono essere intese come documentazione visuale, memoria visiva di un unico soggetto, l'alunno, di una classe, di un momento didattico ma possono rappresentare anche le memoria e le conoscenze di un'intera scuola. Nell’ottica dell’autonomia scolastica potrebbero anche assolvere ad una funzione di promozione dell’istituto dove non vengano solo presentati curricoli e POF ma anche, qualcos’altro, quello che il knowledge management definisce la conoscenza informale. Anche alcuni progetti

europei come il progetto PENCIL, nell'ambito scientifico, di cui INDIRE è partner, cercano di cogliere la conoscenza informale per trasformarla in risorse digitali. Ad esempio, le narrazioni digitali degli alunni potrebbero dare uno spaccato significativo della vita scolastica informale, dello stato emozionale dell’ambiente scuola. Le narrazioni digitali possono potenzialmente costruire comunità tra scuole, nazionali e internazionali a seconda degli interessi specifici. L’esperienza condotta all’INDIRE insieme ad alcune IRRE nell’ambito del progetto Primule va in questo senso, anche se non si tratta di Digital storytelling ma di una documentazione molto più ampia che permette attraverso 3 aree (vivi/trasferisci/rifletti l’esperienza) la rappresentazione di un’esperienza didattica. Ecco che la scuola attraverso i Digital storytelling potrà raccontarsi e ritrovare tutti gli elementi della trama narrativa: il tempo/i personaggi/gli alunni/il contesto/il nesso causale.

Un altro lavoro, che dà un taglio utile per documentare l’attività della scuola è quello di Helen C. Barrett, che utilizza le Digital tales per comporre il portfolio. Se visionate il seguente esempio, l’insegnante intervista Vittoria, una bambina di circa 6 anni, che frequenta la prima elementare. Il portfolio elettronico/digital story tales si propone di evidenziare le sue abilità di base (lettura scrittura e calcolo) attraverso semplici domande come: Mi piace ...perché…ho imparato. Interessante è la meta-riflessione di Tori, ormai in prima elementare, che ripercorre, sempre insieme all’insegnante, il suo percorso alla scuola materna.

Per la produzione del digital storytelling bisogna possedere e/o acquisire determinate competenze e conoscenze che riguardano le modalità tradizionali di scrittura e narrazione, capacità creative, competenze tecnologiche e di produzione mediale e capacità di sviluppo di progetti. I digital storytelling possono essere un momento di apprendimento e di alfabetizzazione tecnologica, di sviluppo di capacità di sintesi, di ricerca e organizzative più stimolanti e creative delle metodologie tradizionali. La metodologia dello storytelling è ampiamente impiegata nei contesti formativi ed educativi come strategia di alfabetizzazione alla lettura e alla scrittura in quanto oltre al semplice dominio dei segni grafici della scrittura, l’uso delle narrazioni digitali favorisce l’acquisizione delle regole per la costruzione del testo e quindi anche la gestione dei processi delle attività cognitive.

A tale riguardo, il presente progetto si inserisce nel contesto italiano caratterizzato da un forte processo di digitalizzazione dei contesti educativi, scolastici e formativi. Tale processo è mosso dalla necessità di creare delle infrastrutture adeguate, attraverso l’implementazione nel sistema scolastico italiano della strumentazione tecnologica e della connessione in rete, che permettano di rispondere alle esigenze intese in termini di sviluppo di competenze emergenti dalla società dell’informazione. La Recommendation of the European Parliament and of the Council del 18 dicembre del 2006, stabilisce che il compito dell’educazione e della formazione è di offrire ai giovani la possibilità di sviluppare e acquisire le competenze chiave al fine di consentire un maggiore adattamento ai cambi sociali e renderli cittadini attivi (2006/962/EC). Tra le otto competenze individuate dalla Raccomandazione Europea, la “competenza digitale” fa riferimento allo sviluppo di abilità tecniche, del pensiero critico, della creatività nella produzione di contenuti, di capacità espressive attraverso nuovi linguaggi e uso degli strumenti in modo innovativo. Il Ministero della Pubblica Istruzione italiana ha per questo motivo avviato differenti programmi per lo sviluppo delle tecnologie didattiche al fine di promuovere e favorire l’educazione degli studenti alla multimedialità, l’introduzione di questa nella didattica per migliorare i processi di apprendimento-insegnamento.

In linea con il programma di introduzione delle ICT nelle scuole e lo sviluppo di competenze digitali è il Piano di intervento “Scuola Digitale” promosso dal MIUR e dall’Agenzia per lo Sviluppo dell’Autonomia Scolastica. L’obiettivo è di sviluppare e potenziare l’innovazione didattica attraverso l’uso delle tecnologie informatiche. Il progetto di ricerca si svolgerà presso alcune classi delle scuole medie inferiori della Regione Puglia che partecipano al progetto Cl@ssi 2.0, progetto facente parte del Piano di Intervento “Scuola Digitale”. I digital storytelling, utilizzati come metodologia didattica per attività extra-scolastiche, offriranno una opportunità di media literacy più stimolante e coinvolgente rispetto ad altre metodologie didattiche, ma soprattutto immergono gli studenti in un ambiente tecnologico a loro noto che facilita l’acquisizione di competenze e abilità tecnologiche e l’uso critico dei media. In tal senso la metodologia del digital storytelling, attraverso la manipolazione di più codici e formati della narrazione orale, scritta, visuale, permette l’apprendimento e lo sviluppo di competenze non solo alfabetiche ma anche compositive/espressive, tecnologiche e critiche.

La fase di ideazione e progettazione della storia in quanto narrazione composta anche da elementi filmici, prevede una iniziale rappresentazione visuale attraverso gli strumenti del visual portrait e dello storyboard. Il visual portrait o storymap è uno strumento che permette di descrivere la storia nella sua struttura, cioè gli intrecci, gli eventi, gli elementi dinamici che la caratterizzano al fine di creare una sorta di mappa emozionale della narrazione . La costruzione dello storyboard consente di pianificare la storia da un punto di vista più tecnico, ovvero di stabilire il contenuto della sceneggiatura e gli elementi e i codici comunicativi che si utilizzeranno, attraverso il disegno delle scene e degli eventi. Entrambi gli strumenti facilitano la visualizzazione dei componenti della narrazione, loro progressione,

sulla base dei quali è possibile selezionare e raccogliere le immagini, la musica, l’audio, etc., più utili per lo sviluppo della propria storia. A seguito di questa fase preparatoria si ha la realizzazione della narrazione digitale attraverso il montaggio dei differenti formati scelti e selezionati da ogni utente.

WP 1.3.3 RIFERIMENTI BIBLIOGRAFICI

• Andreocci B., Potenzialità didattiche dei filmati digitali interattivi in ambienti di formazione in rete in Formare Newsletter, n. 47 ottobre/novembre 2006

• Benton, P. The power of the digital storytelling in the classroom, Spiral Notebook, april 2006 http://www.edutopia.org/community/spiralnotebook/?p=33

• Banaszewski, T. Digital storytelling finds its place in the classroom, MultiMedia Schools, January/febbruary 2002

• Joe Lambert: Digital Storytelling: Capturing Lives, Creating Community http://www.storycenter.org/book.html

• Corrado Petrucco, Marina De Rossi: Narrare con il digital storytelling a scuola e nelle organizzazioni, Roma, Carocci editore, 2009

• Biondi, G., La documentazione come sistema di rappresentazione delle conoscenze, in Goldtrain, 2005 http://www.bdp.it/lucabas/lookmyweb_2_file///Biondi_rappresentazioni_conoscenze.pdf

• Lambert J., Digital storytelling cookkbook and travelling companion(version 4.0), may 2003

• Kajder, S., Digital Images in the language arts classroom, Learning & leading with technology, v. 31, n. 8, 2004

• New, J., How To: Use Digital Storytelling in Your Classroom, EdutopiaMagazine, dic 2005

• Ohler, J., Traditional Stories go green, Storytelling magazine, 2007

• Ohler, J., Digital stories in the classroom, 2007

• Pearson Hathorn P., Using Digital storytelling as a literacy toll for the Inner City Middle school Youth, The charter schools ressource journal, v. 1, n. 1, winter 2005

• Pennac, D., Come un romanzo, Feltrinelli, 2006

• Powel B. T., Native/American Digital/storytelling situating the Cherokee oral tradition within American literary history in Literature Compass 4/1 (2007), pp. 1-23, http://www.blackwell-synergy.com/doi/pdf/10.1111/j.1741-4113.2006.00376.x?cookieSet=1

• Raieli, R., Il visual retrieval, AIDAinformazioni, n. 19, 2001

• Sclavi, M., Arte di ascoltare e mondi possibili, Mondadori, Milano, 2003

• Standley M., Digital Storytelling: using new technology and the power of stories to help our students learn- and teach, cable in the classroom, june 2003

• Standley M., Digital stroytelling with iMovie/Powerpoint. Vision Technology in Education, 2004

• Federico Batini, Simone Giusti (a cura di) Le storie siamo noi. Gestire le scelte e costruire la propria vita con le narrazioni, Napoli, Liguori editore, 2009

• Federico Batini, Andrea Fontana, Storytelling Kit. 101 esercizi di narrazione d'impresa, Milano, Etas, 2010

• Claudio Cortese, L'organizzazione si racconta, Milano, Guerini, 2000 • Duccio Demetrio, Raccontarsi. L'autobiografia come cura di sé, Milano, Raffaello Cortina editore, 1995

• Andrea Fontana, Manuale di Storytelling. Raccontare con efficacia prodotti, marchi e identità d'impresa, Milano, Etas, 2009

• Andrea Fontana, Story-selling, Milano, Etas, 2010 • Andrea Fontana, Gianluca Sgreva, Il Ponte narrativo. Le scienze della narrazione per le leadership

politiche contemporanee Milano, Lupetti, 2011 • Corrado Petrucco, Marina De Rossi: Narrare con il digital storytelling a scuola e nelle organizzazioni,

Roma, Carocci editore, 2009 • Christian Salmon, "Storytelling. La Fabbrica delle Storie". • Karin B.Evans and Dennis Metzger,Storytelling, 2000, ASTD. • Gabiele Qualizza, Lo storytelling nella comunicazione d'impresa, Rivista di scienze della comunicazione

- A.I (2009) n.2 (luglio-dicembre) • Barbara Quacquarelli, Francesco Paoletti, Qual è il contributo dello storytelling all’interno della vita delle

organizzazioni e delle loro attività?, Sviluppo & Organizzazione, n.220, Marzo/Aprile 2007 • Andrea Fontana, Storytelling management: Narratologia, organizzazioni e economie del simbolico,

Sviluppo & Organizzazione, n.220, Marzo/Aprile 2007 • Francesco Varanini, L'organizzazione come rete di storie e lo storytelling come furto, Sviluppo &

Organizzazione, n.220, Marzo/Aprile 2007

• Enrico Viceconte, Contar Storie, Persone e Conoscenze n.54, 2010

WP 1.4 Specifiche Funzionali del sistema Vocs.

In questa sezione vengono descritti i concetti e le funzionalità del sistema per la creazione e la fruizione di storie interattive per il progetto Vocs.

Le specifiche funzionali, per quanto riguarda la parte di costruzione di storie con contenuti multimediali, e' stata sviluppata da Digital Video con la collaborazione del dipartimento Infocom e del Conservatorio di Roma Santa Cecilia

Nel corso del capitolo verranno inserite alcune immagini di esempio, allo scopo di dare un’idea di come apparirà visivamente l’interfaccia del sistema. Tali immagini ovviamente non vogliono rappresentare l’ interfaccia definitiva del software, ma solo dare un’indicazione di massima, per rendere i concetti esposti più chiari.

Il capitolo è suddiviso in paragrafi. In ognuno di essi viene illustrata una delle diverse entità che compongono la storia interattiva (Story, Scene, Plot, etc.) , e viene brevemente descritto il componente software (l’Editor) che la crea e la manipola.

Per la terminologia di tali entità si è scelta la lingua inglese. Riteniamo che i termini in inglese siano più espressivi e concisi dei corrispondenti italiani: useremo ad esempio i termini ‘Cast’ e ‘Plot’ invece di ‘Interpreti’ e ‘Trama’.

1.1WP 1.4.1 La Story e lo Story Editor

La Story e’ l’oggetto che rappresenta l’intera storia interattiva. E’ l’unico oggetto che può essere salvato e caricato da file, e a tal fine verrà creato un formato file proprietario. (un file che contiene la storia potrebbe chiamarsi ad esempio : visita_museo.vox). Il file di storia potrebbe essere strutturato in modo da far riferimento ad altri file che contengono i vari componenti, come ad esempio le scene, i behaviour editor, i plot. Dal punto di vista dell’utente tutto ciò sarà reso trasparente, dando accesso al solo file principale. È ovviamente possibile riprodurre (playback) la storia, che potrà avvenire a tutto schermo o su una finestra in due differenti modalità: a schermo intero o in finestra.

La Story è definita da un insieme di Scene, dia uno Story Cast, e da un Entry Point.

Una Scene é un’unità narrativa della storia: l’autore può strutturare la storia dividendola in scene Scene seguendo diversi criteri. Tipicamente, il criterio più naturale è una organizzazione delle scene Scene secondo ‘location’: se la storia si sviluppa in diverse ambientazioni, ognuna di esse può essere rappresentata da una diversa Scene.

L’autore può manipolare la storia tramite lo Story Editor, che mostra la struttura delle Scene secondo una rappresentazione a grafo. In figura un esempio di tale rappresentazione:

Ogni ‘nodo’ del grafo (i rettangoli in figura) rappresenta una Scene, e ogni ‘arco’ (le linee che congiungono i diversi nodi) tra due nodi indica che esiste una transizione tra due sceneScene: cioè che durante il playback della storia, è possibile passare da una scena all’altra.

Ogni nodo mostrerà un’una immagine rappresentativa della scena in questione.

Nello Story Editor è possibile creare, cancellare, duplicare e organizzare sullo schermo i diversi nodi. Gli archi invece vengono creati automaticamente dal sistema in base ai Plot associati alle sceneScene, come vedremo in seguito. E’ possibile definire anche l’EntryPoint della Story, che è rappresenta la scena che viene eseguita all’inizio del playback della storia, nonché ovviamente il nome della scena.

Lo Story Cast é l’insieme dei contenuti (Content) di cui é composta la storia.

Tali Content possono essere suddivisi in diverse categorie: immagini statiche, filmati, personaggi animati (contenuti che sono in grado di effettuare delle azioni), clip audio, clip video, e cosi via.

Nel software esisterà un componente grafico, chiamato Story Browser, che è essenzialmente un browser ad icone suddiviso nelle varie categorie suddette, e che permette di accedere velocemente alle proprietà dei vari oggetti, di selezionare un oggetto per inserirlo in all’interno di una uno Stage Scene o nel caso di caratteri animati, ad accedere all’’Editor per definire il ‘behaviour’ dei caratteri animati (vedi prossimi

paragrafi). Tramite lo Story Browser e’ possibile anche selezionare velocemente a fini di editing i diversi componenti all’interno dei rispettivi editor.

E’ possibile popolare lo Story Cast importando i vari contenuti dal file browser del sistema operativo. Nota che l’autore non é tenuto a popolare esplicitamente questo lo Story Cast: come vedremo successivamente, esiste anche lo Scene Cast, e tutto ciò che viene aggiunto a quest’ultimo apparirà automaticamente anche nello Story Cast.

1.2WP 1.4.2 La Scene

Come già accennato, una Scene è un elemento narrativo della storia.

Ad ogni Scene è associato uno Scene Cast, uno Stage, e uno o piú un Plot.La principale funzione di una Scene è quella di raggruppare logicamente Scene Cast, Plot e Stage.

Lo Scene Cast è del tutto analogo allo Story cast Cast (anche come interfaccia grafica), ma contiene solo i contenuti relativi alla scena a cui è associato. Aggiungendo un elemento allo Scene Cast, questo, se non già presente, viene anche aggiunto allo Story Cast.

Lo Stage è la struttura della scena dal punto di vista visivo: rappresenta cioè il modo in cui i vari contenuti visivi sono composti e posizionati sulla scena durante il playback.

I Plot sono l’insieme di istruzioni (come si direbbe in linguaggio informatico, gli ‘script’) che permettono lo svolgimento della storia interattiva.

Vediamo ora in dettaglio i concetti di Stage e Plot, e i loro relativi editor.

WP 1.4.3 Lo Stage e lo Stage Editor.

Lo Stage è quindi ciò che appare durante il playback della storia, e lo Stage Editor è il componente che permette di creare e manipolare tali Stage, scegliendo quali contenuti utilizzare del Cast, componendo l’inquadratura, e definendo alcune grandezze, come la camera.

In figura un esempio di come potrebbe apparire uno Stage Editor.

In questo editor è possibile selezionare dal cast Cast gli elementi da includere nello Stage, come i fondali, i personaggi, gli elementi scenici, e di effettuare la loro composizione geometrica, tramite movimenti, scalature, rotazioni, etc.

Per l’aggiunta degli elementi visuali sullo stage è possibile caricarli tramite classica interfaccia di file browser o più semplicemente tramite drag&drop dal sistema operativo.

Una volta caricati i contenuti, è possibile assegnare loro un nome.

E’ altresì possibile caricare piú volte lo stesso contenuto, assegnando ad esse un nome diverso. In questo modo, due diversi contents visivamente identici possono essere utilizzati come due entità completamente distinte all’interno della scena.

È inoltre possibile definire l’ordine di sovrapposizione dei vari livelli, nonché oggetti speciali come inquadrature e aree sensibili. A tal fine e’ possibile creare un oggetto speciale nello stage, chiamato HotBox.

Un HotBox e’ un area rettangolare, a cui si associa un nome, che puo’ essere posizionata sullo schermo. Le HotBox hanno fondamentalmente 3 diversi usi:

1) HotBox come Special area dello stage: Se si vuole eseguire qualche azione quando un personaggio raggiunge un certo punto dello stage, oppure se l’utente clicca con il mouse in un punto dello stage, l’HotBox permette di definire tali punti sensibili, e di riferirsi ad essi tramite il nome dell’HotBox;

2) HotBox come inquadratura per i movimenti di camera: se si vogliono effettuare zoom su alcune parti dello stage, o effettuare carrellate, etc., l’HotBox permette di definire tali inquadrature e riferirsi ad esse tramite il loro nome;

3) HotBox come frame per il playback di un videoclip: se si vuole visualizzare un clip in una porzione dello stage, tramite una HotBox si può definire dove eseguire tale playback.

Una volta definita una HotBox e assegnata ad essa un nome, è possibile definire le azione descritte all’interno del plot riferendosi ad esso tramite il suo nome.

La composizione che si effettua nello Stage Editor e’ il punto di partenza per il playback della scenaScene. Durante tale playback, in base al Plot in esecuzione (vedi paragrafo successivo), la composizione messa a punto nello sStage Editor sarà modificata dalle azioni specificate e dall’interazione con l’utente. Ovviamente i vari contents dello Scene l cCast della scena non dovranno essere tutti presenti “on stage” all’inizio, ma potranno entrare o uscire a seconda dello svolgersi degli eventi della storia. Inoltre, è possibile definire un content come ‘invisibile’ sullo stage, per farlo apparire al momento opportuno tramite un comando nel plot. Ovviamente un content può anche essere reso invisibile durante lo svolgimento della scena.

Nello Stage Editor è anche possibile effettuare un Preview: cioè effettuare un playback della sola scena stessa, per dare modo all’autore della storia di verificare in corso di sviluppo il suo funzionamento.

Per effettuare il playback dell’intera storia, l’entry point nel software e’ sempre attraverso lo stage editor; da qui, tramite una opportuna interfaccia di tipo “player console”, è possibile lanciare l’intera storia , anche in modalità full screen.

WP 1.4.4 I Plot e il Plot Editor.

Come abbiamo accennato, ad ogni scena è associato un Plot.

Il pPlot è l’insieme di istruzioni, strutturate in modo anche complesso, che permette di animare in modo interattivo la scena stessa. Dal punto di vista logico eè funzionale, esso si può definire la ‘programmazione' della storia, analogamente a quello che accade, per esempio in Macromedia Flash, tramite l’utilizzo di linguaggi di script come ActionScript.

Nel sistema Vocs verranno utilizzati paradigmi e modalità di ‘programmazione ‘visuale’, evitando qualsiasi tipo di scrittura esplicita di codice di programmazione. In pratica, le varie azioni saranno assemblate utilizzando il concetto di blocco funzionale (Block):

un Block è un elemento di interfaccia grafica che esegue un compito elementare (ad esempio: sposta il personaggio ‘Bambino’ alla posizione (x, y), suona la clip audio ‘tromba’, togli il personaggio ‘Coniglio’ dallo stage, etc.).

Tali Block vengono quindi composti tra loro, in modo graficamente intuitivo, per creare delle sequenze di istruzioni.

Nella figura, un esempio di interfaccia grafica 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 chiesto con un comando vocale di sentire il suono della tromba, sono stati uccisi 100 marziani, etc.

Movement Block:

sono blocchi che muovono i contenuti sullo stage. Esempi: sposta “Bambino” nella posizione (x, y), Muovi “Coniglio” di x pixels verso sinistra, Mostra sullo stage Stage personaggio ‘Cappellaio” in posizione x,y, etc.

Sound Block:

permettono di manipolare il suono. Esempi: suona la clip “Tromba” dal secondo x al secondo Y, interrompi tutti suoni, parla dicendo “ciao sono il coniglio”, etc.

Video Block:

permettono di visualizzare dei videoclip sulla scena. Esempi: esegui la clip “vita di corte”, nell’HotBox “schermo”, interrompi tutti i video, etc.

Control Block:

permettono di strutturare le Action. Esempi: ripeti <blocks> per 10 volte, se <condizione> allora esegui <blocks>, vai a scena “Nel Bosco delle fate”. (Quest’ultimo esempio di Control Block, crea automaticamente un collegamento nello Story Editor tra le la scena attuale e la scena chiamata “Nel Bosco delle fate”.)

Altri due concetti fondamentali per lo sviluppo dei Plot sono gli Attribute e gli State.

Gli Attribute sono delle entità che memorizzano dei valori.

Ad esempio in un videogioco a del generela Space Invaders, esisteráesisterà l’attributo ‘marziani uccisi’, che memorizza un numero intero.

Esisteranno dei Block per manipolare gli attributi. Ad esempio: assegna il valore 100 a ‘marziani uccisi’, incrementa di 1 il valore di ‘marziani uccisi’, se ‘marziani uccisi’ e’ uguale a 100, allora visualizza “Hai vinto!”.

Nell’interfaccia grafica del Plot Editor, sarà possibile visualizzare tutti gli attributi del plot attuale, e crearne di nuovi.

Un attributo può esistere anche a livello globale, e cioè comune e accessibile da tutte le scene della StoriaStory.

Gli State memorizzano lo stato attuale di una scena. Durante il playback di una scena esisterà sempre un Current State.

Ad esempio, se in una scena in una cucina il personaggio ‘bambino’ deve rubare la marmellata su comando vocale dell’utente, il comportamento del ‘bambino’ al comando vocale ‘prendi la marmellata!’ vogliamo che cambi a seconda se la porta della cucina e’ aperta o chiusa. Nel secondo caso il bambino prima chiude la porta e poi prende il vasetto. In una situazione del genere, nella scena esisteranno due stati chiamati ‘porta aperta’, e ‘porta chiusa’. La Action che risponde all’evento “prendi la marmellata” sarà quindi diversa a seconda dello stato attuale della scena.

Ovviamente, in modo analogo agli Attribute, esisteranno dei Block speciali per manipolare lo State della ScenaScene. Esempio: cambia State in ‘porta chiusa’, se State e’ uguale a ‘porta aperta’ allora esegui action ‘chiudi porta’, etc.

Lo State può essere visto come un caso speciale di attributo.

L’interfaccia grafica del Plot editor permette di creare e manipolare le action che costituiscono il plot. Esisterà un “Block Catalog” che visualizza tutti i tipi di blocks disponibili. Per l’aggiunta dei blocks ad una action sarà sufficiente effettuare un drag&drop dal Catalog al plot Editor, agganciandoli alle action opportune. Sarà possibile, sempre tramite drag&drop, muovere o copiare blocchi e gruppi di blocchi da un’azione ad un'altra, oltre ovviamente a cancellare blocchi esistenti.

WP 1.4.5 I Behaviour ed il Behaviour Editor.

I Behaviour sono degli insiemi di istruzioni associate ad un singolo Content presente nel Cast (tipicamente, tale Content potrebbe essere l’insieme di immagini che compongono l’animazione di un personaggio della storia) per rendere tale contenuto animabile in maniera interattiva. In pratica, un Behaviour associato ad un personaggio rende il personaggio una sorta di ‘automa’ in grado di eseguire dei comandi che provengono dai plot delle scene. Ad esempio si potrebbe creare un Behaviour del personaggio ‘bambino’ in modo tale che questo sia in grado di eseguire una serie di comandi, come: afferra il vasetto di marmellata, aspetta impaziente, dí ‘io sono un monello!’, etc.

Il concetto di Behaviour è simile a quello di Plot delle Scene. La differenza principale é che il Behaviour è associato ad un Content, mentre il Plot è relativo ad una Scene. Anche il Behaviour Editor è simile al Plot Editor; differisce da quest’ultimo nel tipo di Block utilizzabili, che sono in parte diversi nei due casi. Ad esempio, Nella creazione di un Behaviour potrà esserci un Movement Block del tipo “esegui i frames dal 12 al 35” in riferimento alle immagini animate del Content associato al Behaviour in questione, oppure un Event Block “esegui comando ‘afferra la marmellata ’).

Anche per i Behaviour esiste il concetto di Attribute e State. Ad esempio, nell’eseguire il comando “afferra la marmellata”, l’animazione da eseguire dipende dallo stato del personaggio: se e’ seduto su una sedia, se non e’ presente in scena, etc. Nel caso lo stato del personaggio sia ‘Seduto’, bisogna eseguire una Action che fa alzare il bambino dalla sedia, e cosi via.

WP 1.4.6 Struttura dell’interfaccia grafica di Vocs

La struttura dell’interfaccia grafica del software dovrà permettere di organizzare i vari componenti in modo chiaro e permettendo l’accesso ai vari editor presenti in modo veloce e funzionale.

Inoltre, i componenti (i contents, le scene, i plot…) sono condivisi da diversi editor, quindi dovrà esserci un meccanismo centralizzato che permetta di selezionare gli oggetti su cui si vuole lavorare indipendentemente dall’editor in cui ci si trova al momento.

I componenti principali di Vocs sono 5:

- Lo Story Browser

- Lo Scene Editor

- Il Character Editor

- Lo Stage Editor

- Il Plot Editor

Il suddetto meccanismo di selezione e navigazione centralizzato di cui sopra verrà realizzato mediante lo Story browser, tramite il quale sarà possibile selezionare i vari componenti. A tal fine, nell’interfaccia globale lo Story Browser sarà sempre presente e visibile sullo schermo.

Gli altri 4 editor invece, saranno organizzati in una modalità a tabbed windows, per permettere lo switch veloce tra l’uno e l’altro.

Nell’immagine seguente, viene mostrato tale organizzazione dei componenti del software, in una versione preliminare di studio dell'interfaccia. Sulla destra, e’ presente lo story browser, strutturato ad albero; il primo livello dell’albero rappresenta le varie scene, e il secondo i contenuti di ogni scena. Le icone associate ai contenuti illustrano il tipo di contenuto (carattere animato, elemento di scena, suono, video, HotBox). Per le scene, i le icone mostrano una immagine thumbnail del contenuto dello stage. I quattro editor sono selezionabili tramite i tab in alto. Ogni editor avrà una sua toolbar con un set di icone per la manipolazione dei contenuti.

WP 1.4.7 Il Vocs Player.

Il software Vocs verr’ realizzato in due versioni. La prima, quella appena descritta, e’ una versione completa di tutte le funzionalità per l’authoring delle storie. La seconda è una versioenslaled-down che permette il solo playback delle storie realizzate. Questa versione, denominata ‘Vocs Player’, permetterá esclusivamente il caricamento di una storia e la sua esecuzione, sia in modalitá windowed che full screen. Nella figura, l’aspetto della GUI per il player Vocs.

WP 1.4.8 Struttura della Story

Riportiamo nei 2 diagrammi seguenti la struttura della Story cosi come é stata descritta nel documento:

STORY

SCENE SCENE SCENE

State

Attributes

attributes

WP1.5 specifiche funzionali dell'Integrazione dei moduli vocali con l' ambiente di sviluppo della “Story” del software

L’ambiente di sviluppo VOCS prevede che ad ogni azione eseguita dal player dello storyteller venga inviato un feedback a Speaky che interagisce con l’utente in maniera appropriata con eventuali prompt vocali.

Il Player dello Storyteller reagisce ad usa serie di eventi definiti, in fase di progettazione, dall’autore della “Story”. Ad ogni evento corrisponde un insieme di azioni che il player eseguirà a seguito dell’evento specifico. L’autore della “Story” potrà, opzionalmente, associare ad ogni evento oppure ad ogni azione, un insieme di comandi vocali che scateneranno i medesimi eventi o le medesime azioni, ma nella modalità di interazione vocale .

Le azioni associate ai comandi vocali, o alle diverse interazioni tra utente e “Story” (tramite il player), sono le medesime. In aggiunta un comando vocale potrà sollevare anche più azioni contemporaneamente.

WP1.5.1 Interfaccia per Input e Output Vocale

STAGE

ACTION

PLOT

ACTION ACTION

CAST

ACTION ACTION ACTION

CONTENT CONTENT CONTENT

CAST

BEHAVIOUR

L’ambiente di sviluppo della “Story” verrà corredato con una interfaccia per l’inserimento degli elementi Vocali. Tali elementi sono di due tipi differenti, input vocali (“Speaky Speech Input”) e output vocali (“Speaky Speech Output”);

Speaky Speech Input (SSI) Più frasi per ogni evento/azione (Control Block): Gli input vocali sono insiemi di frasi alle quali è assegnato un significato specifico corrispondente ad un evento oppure ad una azione predefinita all’interno dei blocchi evento o blocchi di controllo/azioni dello script (plot) della “Story”. Ogni evento o azione avrà quindi una o più frasi (comandi vocali) che lo scatenano.

Comandi vocali duplicati: (Ambiguità) Ogni frase potrà essere duplicata per altri eventi o azioni relativi a differenti script all’interno della “Story” (ad es. in scene diverse tra loro). Per risolvere l’ambiguità il player vocale invierà di volta in volta a Speaky lo stato in cui si trova (es. in quale scena o gruppo di scene, o stato specifico all’interno della scena, ecc.). Questa informazione permetterà a Speaky di inviare il codice corretto, dell’evento o dell’azione, al player rispetto al contesto in cui si trova. Questa attività di disambiguazione la definiamo come “Sistema automatico di disambiguazione”.

In alternativa questo compito potrà essere demandato al player che scatena l’evento o esegue l’azione corrispondente in base al contesto in cui si trova.

Il sistema di sviluppo controlla i comandi vocali inseriti durante la definizione della “Story” ed evidenzia all’autore le eventuali anomalie e duplicati. L’autore potrà quindi stabilire se risolvere i duplicati con frasi differenti oppure lasciare al “sistema automatico di disambiguazione” tale compito.

Speaky Speech Output (SSO) Feedback o Prompt vocali: Casualità, Prosodia ed Em ozione. L’autore della “Story” ha la possibilità di definire, per ogni azione effettuata dal player, durante l’interazione con l’utente, una serie di feedback vocali o frasi che verranno erogate da Speaky. In particolare ogni feedback vocale verrà associato ad un codice specifico. Ad ogni codice corrispondono una o più frasi che Speaky erogherà in maniera casuale per dare l’impressione della variabilità con cui risponde alle medesime azioni all’interno della “Story”.

I feedback vocali possono essere corredati da effetti prosodici (tag di prosodia) o espressivi (tag emozionali) in maniera da rendere emozionante ed accattivante la comunicazione con l’utente della “Story”.

L’interfaccia di sviluppo utilizzata dall’autore della “Story” prevede la costruzione dei prompt vocali in maniera semplice ed intuitiva e permette l’inserimento dei tag, di prosodia ed emozionali, in modalità grafica.

WP1.5.2 Le componenti per l’ambiente di sviluppo L’ambiente di sviluppo della “Story” utilizzerà una serie di componenti grafiche per l’inserimento degli elementi vocali sopra definiti ovvero gli “Speaky Speech Input” e “Speaky Speech Output”. Tali componenti verranno implementati utilizzando l’ambiente di sviluppo Microsoft Visual Studio .Net 2010. Esse saranno componenti contenenti le API (Application Programming Interface) per l’integrazione delle stesse nell’ambiente di sviluppo della “Story” e si declinano in interfacce grafiche per l’inserimento degli elementi vocali durante la costruzione della “Story”. L’autore utilizzerà tali interfacce grafiche per definire gli elementi vocali.

L’ambiente di sviluppo delle “Story” è sviluppato con l’ambiente Microsoft Visual Studio 2010 .Net ed il linguaggio specifico è VC++ Nativo (non .NET). Il linguaggio di programmazione per le componenti vocali è invece C#.NET. Considerando gli ambienti e i linguaggi di programmazione utilizzati verrà sviluppata una interfaccia per la comunicazione tra i vari ambienti di sviluppo.

Il Flusso di Dialogo

Il flusso di dialogo che deriva dalla implementazione della “Story” è costruito in base alla struttura della “Story” stessa così come definita nel capitolo precedente.. Qui di seguito vediamo come si mappa la struttura del dialogo vocale con la struttura della “Story” sulla base delle componenti che la costituiscono.

Il Dialogo Vocale può essere inoltre personalizzato in alcuni suoi elementi dall’autore della “Story”. Tali personalizzazioni sono di seguito descritte.

Es. Definire comportamenti alternativi per i comandi universali, accorpare gli stati di dialogo (import di stati), definire gli stati di transizione (es. stati di conferma comando vocale), ecc.

WP 1.6 Uno studio preliminare su un software per lo storytelling: Use case.

Questo documento fornisce un esempio di utilizzo del software Vocs per la realizzazione di una storia interattiva voice-driven. Lo scopo di questo esercizio e’ quello di verificare che le specifiche funzionali del software siano adeguate ad un utilizzo pratico per la creazione di una storia interattiva. E' servito inoltre per effettuare varie iterazioni sulle specifiche stesse. La grande utilità di una simulazione di attività di sviluppo di una storia e' soprattutto la possibilità di evidenziare mancanze, inefficienze o limiti di un modello funzionale.

Useremo la terminologia inglese del software Vocs riguardo le varie grandezze coinvolte; diremo Story invece che storia, Scene invece che scena e cosi via.

Verrà prima fatta la descrizione di un frammento di Story da realizzare, nell’ambito dell’edutainment musicale.

Successivamente, verranno descritti in dettaglio i vari step necessari per la sua realizzazione. Il workflow utilizzato in questo esempio parte dalla produzione dei contenuti, per poi realizzare la Story e le varie Scene. Ovviamente, possono essere utilizzati altri modelli di workflow.

WP1.6.1 Descrizione storia (frammento) da realizzar e

La storia interattiva riguarda la visita di un museo di strumenti musicali, effettuata con una guida virtuale realizzata tramite un avatar. Tale avatar guida l’utente attraverso la storia degli strumenti, la loro realizzazione e il loro utilizzo.

In questo frammento illustreremo una semplice situazione in cui l’avatar e’ in una stanza del museo, con vari strumenti musicali esposti. L’utente può interagire con la guida chiedendo informazioni, visualizzando un particolare strumento, e giocando con esso, simulando il suo utilizzo.

La Story inizia con una Scene, in una stanza del museo. In questa stanza sono visibili, in alcune teche, degli strumenti musicali d’epoca: una chitarra, un violino, una spinetta, e cosi via.

All’inizio della storia, l’avatar entra camminando e si ferma al centro, dicendo alcune frasi di benvenuto (”Buongiorno! Io sono la tua guida nel museo! Fammi tutte le domande che vuoi”)

A questo punto l’avatar resta in attesa, movendosi leggermente e facendo alcune espressioni di quando in quando.

L’utente potrà fare domande in linguaggio naturale su vari argomenti.

Esempi:

“mi parli di come e’ nato il museo?”

“quanti strumenti contiene?”

“ cos’e’ quello strumento a destra?”

“ mi racconti com’e’ fatto?”

Il sistema ricorda l’ultimo argomento trattato, cosicché riesce ad interpretare correttamente domande che si riferiscono al contesto (esempio: “mi racconti come e’ fatto?” si riferisce allo strumento di cui si sta parlando)

In questo esempio tratteremo solo due tipi di input vocale:

domande sulla storia del museo, e descrizione e interazione con uno strumento, la chitarra.

Se l’utente chiede di parlare della storia del museo, l’avatar dice “ho realizzato un piccolo video per questo, ecco qua!” e parte un videoclip non interattivo con un mini documentario sul museo.

Se l’utente chiede di poter vedere/toccare/suonare la chitarra, l’avatar si avvicina alla teca con la chitarra, e la tira fuori . A questo punto parte una nuova Scene. Questa Scene e’ un close-up sulla chitarra, che riempie tutto lo schermo. L’utente può toccare con il mouse le singole corde e sentirne il suono.

Può anche fare domande sulla chitarra, e la voce fuori campo, descrive i vari componenti dello strumento.

WP1.6.2 Realizzazione Contenuti Per la realizzazione della storia servono, al minimo:

- un immagine di background per la Scene del museo: contiene le varie teche con gli strumenti musicali, e altri decori. Per gli strumenti musicali per cui e’ prevista interazione con l’avatar (nel nostro esempio, la chitarra), tali strumenti non vengono disegnati direttamente nel background ma realizzati a parte e sovrimposti nel montaggio dello Stage. Se e’ previsto che l’avatar apra una teca, afferri al chitarra, anche la vetrina della teca deve essere realizzata a parte, in quanto elemento animato.

- Un’immagine di bg per la scena con la chitarra: consiste in una chitarra in primo piano, senza le corde. Le corde vibrano al tocco, quindi vengono realizzate separatamente come contenuti animati.

- Un livello completo di animazione dell’avatar: questo livello deve contenere segmenti animati delle varie azioni: camminata (basta verso destra o verso sinistra, poi si può fare l’immagine speculare attraverso il software), alcune animazioni “idle” di attesa, alcune animazioni con l’avatar parlante, l’avatar che apre la teca e prende la chitarra.

- un livello animato che mostra la corda di chitarra, da ferma a vibrante.

- Un videoclip con il mini-documentario sul museo

- Una serie di clip audio con i suoni delle corde di chitarra che vibrano

- Una serie di clip audio con il parlato dell’avatar nelle varie situazioni

WP1.6.3 Workflow di realizzazione della storia Come già detto, l’ordine in cui vengono realizzati i vari componenti della storia può variare a seconda dell’organizzazione del lavoro dell’utente.

Creazione Storia e Scene. Viene creata nel software una nuova Story.

Nello Scene Editor, vengono create due Scene: la Scene MuseumRoom e la Scene Guitar. Le due Scene appariranno nello Scene Editor come due icone vuote. Non ci sono ancora collegamenti tra le due scene, verranno aggiunti automaticamente in fase di creazione dei Plot.

Creazione Cast

Evidenziando ognuna delle due scene create, e’ possibile visualizzare, in un’area dell’interfaccia, il cast che contiene le icone dei contenuti attualmente utilizzati per la Scene, che ovviamente inizialmente è vuoto. Per importare i contenuti, e’ sufficiente fare drag&drop da una finestra di windows explorer in quest’area. Quindi per ogni scena, vengono importati i contenuti video e audio relativi.

Stage Editing.

Ora vengono montate le scene dal punto di vista visuale nello Stage Editor.

Nello Scene Editor si seleziona la Scene MuseumRoom; nella finestra dello Stage Editor appare lo stage della scena, vuoto; si vede solo il rettangolo della camera. Tramite drag&drop dalla finestra del cast, si aggiungono i vari contributi visuali: il background, gli eventuali arredi, gli strumenti musicali, e l’avatar.

Ognuno di questi contenuti può essere scalato, spostato, ruotato interattivamente. E’ possibile anche cambiare l’ordine di sovrapposizione sullo schermo. La composizione fatta nello Stage rappresenta ciò che si vede quando la scena inizia; quindi l’avatar, che entra in scena camminando, viene posizionato fuori dalla camera. Vengono creati anche alcuni HotSpot. Un HotSpot e’ un punto sulla scena a cui viene assegnato un nome. Questi punti possono poi esser riferiti tramite il nome quando si eseguiranno le azioni sulla scena. Possiamo creare due Hotspot, al centro della stanza e presso la teca con la chitarra, e chiamarli CenterOfRoom e NearGuitar.

Analoghe operazioni per la scena della chitarra, Guitar; si seleziona tale Scene nello Scene Editor, si popola lo Stage con i contenuti (la chitarra, le corde), posizionandoli interattivamente. In questa scena, su richiesta dell’utente, viene fornita una descrizione delle varie parti che compongono lo strumento. Il testo parlato puo’ essere accompagnato dall’apparizione di didascalie e frecce che indicano che parte si sta descrivendo (manico, paletta, ponte…) . A tal fine se sono stati prodotti dei contenuti a riguardo, si posizionano correttamente sulla scena. Poiché le frecce e didascalie appariranno durante la spiegazione, all’inizio della scena questi contenuti vengono settati come “invisible”. Verranno resi visibili al momento opportuno tramite il Plot della scena.

Creazione Behaviours

Per questo frammento di Story, l’unico contenuto dotato di Behaviour e’ l’avatar.

Dal cast della scena, selezionare l’avatar e aprire il Behaviour Editor.

Nel Behaviour Editor si mettono a punto le varie azioni che l’avatar deve compiere. A tal fine si realizzano dei nodi collegati tra loro: ogni nodo, o stato, quando viene eseguito nella scena, esegue la sequenza animata a cui e’ associato. Ogni stato puó avere un nome; durante il playback, nel plot della Scene (vedi dopo) si puo’ dare un comando che porta il character nello stato con quel nome, passando dal nodo corrente a quello richiesto seguendo la via piú breve tra i collegamenti (link) tra nodi ed eseguendo sullo stage le animazioni associate a questi. I link tra nodi possono essere di 3 tipi; command, automatic, random.

I link command vengono attraversati quando viene dato un comando . i link automatic vengono eseguiti sempre, a meno che ci sia un link command e sia in corso l’esecuzione di un comando per andare su un certo stato;

i link random sono come gli automatic ma vengono eseguiti con un certo fattore di probabilità.

Nel nostro caso, l’avatar deve eseguire pochi comandi: Walk, Speak , TakeGuitar, oltre a prevedere uno stato Idle, in cui non fa niente, e’ in attesa ma ovviamente si muove e fa delle piccole animazioni. Uno stato chiamato “Idle” e’ obbligatorio in un behaviour. Se non c’e’ viene dato un errore quando si inizia il playback.

Cominciamo con la messa a punto di tale stato Idle.

Supponiamo che, nell’animazione dell’avatar ci siano alcune sequenze che rappresentano il character fermo, che fa alcuni piccoli movimenti, ad esempio:

frame 1-10 ondeggia leggermente;

frame 11-20 si gratta la testa;

frame 21-30 sbadiglia.

Creiamo tre stati, associando ad ognuno i range di frame specificati. Diamogli il nome Idle, Idle1 e Idle2, per esempio.

Settiamo Idle come nodo di start; il nodo cioè che viene eseguito all’inizio della scena.

Dobbiamo simulare un comportamento “vivo” del personaggio; per cui in modo casuale, ogni tanto esegue qualche movimento. Per far questo usiamo i link random. Colleghiamo Idle con Idle1 e con Idle2 con un link con probabilità 20%. Eseguiti Idle1 e Idle2, si deve tornare all’ Idle principale, quindi si fa un link automatico fino a Idle.

Ecco la situazione (link verdi automatici, gialli random, rossi command)

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

Chiaramente e’ possibile anche implementare l’azione in cui l’avatar rimette a posto la chitarra.

A tal fine bisogna prevedere uno stato WalkingWithGuitar con la chitarra in mano, mentre per l’animazione LeaveGuitar si puo’ usare la precedente animata al contrario; basta specificare nel nodo relativo, come frame da animare, 50-41 invece che 41-50. la costruzione della porzione di behaviour e’ analoga alla precedente.

Se il livello di animazione dell’avatar e’ realizzato tramite un formato movie (tipo .avi, .mov…) e il frammento di cui fare il playback e’ dotato di suoni, verranno suonati anche questi (ad esempio il rumore dei passi

State: IDLE

Frames 1-10

State: IDLE2

Frames 21-30

State: IDLE1

Frames 11-20

20%

20% start

State: IDLE

Frames 1-10

State: WALKING

Frames 31-40

State: TAKE-GUITAR

Frames 41-50 State: IDLE-WITH-GUITAR

Frames 51-60

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:

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

ON SCENE START

MOVE avatar TO CenterOfRoomUSING walking

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

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:

il significato del blocco di controllo e’ evidente. Notare che la variabile viene definita “on-the fly”. La prima volta che si esegue l’action, il sistema non conosce movie_seen. In questo caso, movie_seen e’ UNDEFINED e viene eseguito il THEN. Il comando SET, nel porre la variabile pari a 1, la sta definendo. In questo esempio e’ irrilevante il valore di movie_seen, conta solo il fatto che sia stata definita.

Questo meccanismo, per creare nuove situazioni quando si fanno le stesse richieste, per generare varietà, può essere ripetuto per tutte le action legate ai comandi vocali, tramite l’uso delle variabili. Ometteremo questa gestione delle ripetizioni nelle prossime action.

Vediamo ora il vocal command ‘describe guitar’. Questo comando viene invocato quando l’utente chiede dettagli sulla chitarra. L’avatar in questo caso, va verso la teca della chitarra, l’afferra, comincia a descrivere la chitarra, e poi passa il controllo alla nuova Scene, Guitar Scene.

L’action relativa e’ la seguente:

ON VOCAL COMMAND: show museum movie

Avatar SPEAKS museum.mp3

PLAY MOVIE history.avi

SET movie_seen TO 1

ON VOCAL COMMAND show museum movie

IF movie_seen UNDEFINED

PLAY history.avi

SET movie_seen TO 1

Avatar SPEAKS museum2.mp3

Avatar SPEAKS museum.mp3

THEN ELSE

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:

Realizziamo ora il plot della scena GuitarScene.

Questa scena comincia con una descrizione della chi tarra, 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.

ON VOCAL COMMAND describe guitar

MOVE avatar TO nearGuitar USING walking

HIDE guitar.png

avatar EXECUTE take-guitar

Avatar SPEAKS guitar

description.mp3

PLAY SCENE GuitarScene

from BEGINNING

ON VOCAL COMMAND cannot understand


sorry1.mp3

CHOOSE RANDOM BLOCK


sorry2.mp3


sorry3.mp3 Avatar SPEAKS guitar

sorry4.mp3

Ecco l’action eseguita all’inizio della scena:

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:

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 SCENE START

PLAY guitar description

intro.mp3 SHOW arrow1.png

PLAY guitar description1

HIDE arrow1.png

SHOW arrow2.png


HIDE arrow2.png

SHOW arrow3.png

ON MOUSECLICK ON string1

PLAY string1.mov

ON VOCAL COMMAND go back main scene

PLAY SCENE MuseumScene

FROM CURRENTSTATE


HIDE arrow3.png

PLAY guitar description end

In questo caso il block PLAY SCENE, invece di fare il playback dall’inizio (con l’avatar che entra in scena camminando) ritorna alla scena nello stato in cui la si e’ lasciata.

Anche in questo caso, l’uso del block PLAY SCENE crea automaticamente un arco di congiunzione tra le due scene nello Story Editor.

Con questo, il frammento di storia è concluso.

WP2 Sviluppo: Produzione, reperimento e trattamento con tenuti. MESI 9-15 La descrizione estesa del WP2, come da specifiche di progetto, è la seguente:

WP2 (MESI 9-15, DV+MV+IC+SC) Sviluppo: Produzione, reperimento e trattamento contenuti. In collaborazione con le associazioni indicate, verranno raccolti e prodotti i contenuti multimediali richiesti per l’ambito artistico/culturale prescelto. Tali contenuti verranno filtrati, transcodificati e su di essi verrà costruita la Voice User Interface (VUI) utilizzando dei tool realizzati appositamente, avvalendosi delle tecnologie sviluppate da Digital Video e Mediavoice. Questo Work Package è stato realizzato da parte dell'Accademia di Santa Cecilia, con la collaborazione di Digital Video.

WP 2.1 Produzione, reperimento e trattamento conten uti

Per la realizzazione della story è stato individuato come ambito didattico-educativo il Museo di Strumenti Musicali dell’Accademia (MUSA). Infatti gli strumenti musicali posseggono in sé qualità intrinsecamente “multimediali”: sono esteticamente interessanti (immagini), hanno un suono particolare (audio), vengono suonati con certi movimenti (video). Inoltre gli strumenti posseduti dall’Accademia fanno parte di una rete di beni culturali più ampia rappresentata da diversi Archivi digitali. Ad esempio è possibile ascoltare il suono di alcuni strumenti esposti nel museo, dalle registrazioni storiche conservate nell’archivio sonoro. Infine l’Accademia ha da sempre posto particolare attenzione agli aspetti di divulgazione ed educazione dei ragazzi attraverso diverse iniziative, incuse attività specifiche realizzate presso il MUSA e relative alle nuove tecnologie.

La tecnologia VOCS, quindi, è da subito apparsa particolarmente indicata per la creazione di un’applicazione divertente e allo stesso educativa per valorizzare e far conoscere il patrimonio del MUSA ai ragazzi, senza dimenticare come l’aspetto “tecnologico” e interattivo risulti di particolare attrattiva per i ragazzi, oggi abituati a interagire in maniera disinvolta con computer e video games (come emerso anche in altri progetti di ricerca).

La storia interattiva segue lo svolgersi di una visita al MUSA, effettuata con una guida virtuale (l’avatar). Tale avatar – una giovane studentessa universitaria – guida i ragazzi attraverso quattro aspetti salienti legati al museo, ma anche più in generale alla tradizione musicale dell’Accademia: la storia del museo e il patrimonio ad essa collegato, uno strumento classico, uno strumento etnomusicologico, l’orchestra.

Ecco come appare nella storia finale uno screenshot della scena iniziale della storia:

La progettazione è stata realizzata in funzione del workflow di realizzazione del lavoro, ma anche considerando gli obiettivi del progetto e in particolare l’aspetto interattivo e d’interazione vocale. Dopo aver scritto la trama della storia e i contenuti fondamentali è stata poi elaborata una griglia sinottica con la descrizione dettagliata delle singole scene, i contenuti necessari e le caratteristiche richieste all’avatar.

Do seguito riportiamo una griglia sinottica della story con i contenuti necessari e le esigenze legate all'avatar

Scena Contenuti per la scena Dettagli avatar

Scena 0a. Accoglienza

All’inizio della storia, l’avatar entra camminando e si ferma al centro, dicendo alcune frasi di benvenuto e dando inizio alla visita

- Foto della galleria con teche strumenti

- Musica di sottofondo

- Avatar che entra camminando

- Avatar che parla

- Avatar che indica (tocca) icone selezionate

Scena 0b. Menu principale

L’avatar invita l’utente a scegliere con comando vocale quale aspetto

del museo vuole approfondire ad es:

“Per scoprire la storia, chiedi ‘Storia’”

L’avatar comunica all’utente che potrà tornare a questa scena in ogni momento dicendo “menu”

L’utente sceglierà una delle quattro scene indicate dalle quattro icone.

- Foto della galleria con cambiamento di luce

- Icone

- Etichette testuali per selezione elementi


- Avatar che entra camminando

- Avatar che parla

- Avatar che indica (tocca) icone selezionate

Scena 1. “STORIA” L’avatar fa una piccola intro del tipo “Tutto è cominciato dal concerto che vedete nella foto alle mie spalle…. [accenna alla regina Margherita]”

Quando accenna alla Regina

- Foto del concerto storico per sfondo

- Foto/icona regina Margherita


Idem

Margherita appare un suo ritratto che viene zooomato.

Scena 2. “ORCHESTRA”

L’avatar entra sullo sfondo spiega cosa accade in questa scena:

“Nella sala Santa Cecilia, proprio qui sopra al museo, suona la nostra famosa orchestra… Qui potrai conoscere alcuni degli strumenti che la compongono”

- Immagine con schema dell’orchestra con etichette tipo “archi”, “legni”, “ottoni”, “percussioni”

- L’avatar si rimpicciolisce e invita a giocare con gli strumenti dell’orchestra

Gioco strumenti orchestra: - Si sente il suono di uno strumento: l’utente deve dire il nome dello/degli strumento/i che suonano

- Foto dell’orchestra

- Video dell’orchestra

- Schema orchestra

- Immagini e suoni dei singoli strumenti per il gioco

- Musica di sottofondo (da registrazione orchestra)

Idem

- Avatar rimpicciolito

Scena 3. “VIOLINO” L’avatar accoglie l’utente e dice qualche parola introduttiva sul violino Stradivari detto “Toscano”.

Mentre parla dello strumento parte dello sfondo è occupato dal violino su un piedistallo

A questo punto, sempre su invito dell’avatar l’utente può scegliere se vedere un video dello Stradivari dicendo “video”

- Grafica sfondo stile palcoscenico

- Foto violino stradivari ritagliata

- Grafica piedistallo

- Video storico con Carmirelli che suona il violino

- Musica di sottofondo (violino – Paganini)

- Idem

Scena 4. “LAUNEDDAS”

Sfondo foto b/n archivi etno Sardegna

- L’avatar introduce la musica “popolare” e introduce gli strumenti di quest’ultima (presenti al museo). In particolare l’antico strumento sardo chiamato launeddas.

- L’avatar fa ascoltare un brano per launeddas (zoom sul suonatore)

- L’avatar fornisce ulteriori informazioni sulla launeddas.

- Foto sfondo con suonatori launeddas bianco e nero

- Elementi grafici per sfondo (albero, lampione) colorati con trasparenze

- Audio launeddas da archivio sonoro etnomusicologia

- idem

Una volta definita la struttura della story è iniziata la fase di creazione del database di contenuti tramite la raccolta, filtraggio e transcodifica dei contenuti. Alcuni di questi, come è intuibile dalla tabella, sono stati ricercati e reperiti direttamente dagli Archivi dell’Accademia. Altri (quali ad esempio icone ed elementi grafici) sono stati creati appositamente. Chiaramente i contenuti estratti dagli archivi sono stati modificati e predisposti in modo da essere adatti alla story. Inoltre durante la creazione della story è sorta la necessità di aggiungere o modificare alcuni dei contenuti inizialmente individuati per adattarli al meglio al lavoro.

Ecco un esempio di altra scena della storia, relativa al violino Stradivari “Toscano”. L’immagine del violino proviene dall’archivio fotografico dell’Accademia

WP3 Sviluppo: Design e realizzazione avatar MESI 9-21 La descrizione estesa del WP3, come da specifiche di progetto, e' la seguente:

WP3 (MESI 9-21, DV+MV+OI+FUB+CUL) Sviluppo: Design e realizzazione avatar Verrà ideato e realizzato l‘Avatar (o gli Avatar), sia nella sua forma visuale che nei suoi meccanismi di interazione vocali. A tal fine verranno prodotti dei contenuti per l’aspetto visuale del personaggio, e tutte le animazioni previste per le sue funzioni all’interno delle storie. Verranno inoltre integrati i motori di sintesi e riconoscimento vocale, per produrre un automa sofisticato che fungerà da guida e controllore nella creazione di segmenti di storytelling della piattaforma. Sarà possibile eseguire prove di integrazione con il motore di render del WP4, il cui sviluppo avverrà di pari passo con quello dell’avatar.

WP3.1 Design e realizzazione avatar Questo Work Package è stato realizzato da parte dell'Accademia di Santa Cecilia, con la collaborazione di Digital Video. Il punto di partenza per la realizzazione dell'Avatar é stata l'identificazione della storia da realizzare, il suo ambito e i suoi meccanismi interattivi. La storia prescelta riguarda la visita di un museo degli strumenti musicali. Ci si e' immaginati quindi la situazione tipo di una scolaresca che effettua tale visita guidati da un professore di musica, che funge da Avatar per la storia interattiva. La prima ipotesi presa in considerazione per la realizzazione dell’avatar è stata quella di un professore sui 35-40 anni, dall'aspetto non troppo serioso . Dei primi studi sul personaggio hanno portato ad alcune ipotesi, rappresentate nella seguente figura:

E' stato realizzato il turnaround completo, come da figura:

Successivamente, in parte a causa di problemi tecnici e di licenze software, e’ stata presa un’altra direzione. Infatti, il motore di Sintesi vocale realizzato da MediaVoice, tra le voci disponibili di una certa qualità e verosimiglianza, ha a disposizione soltanto voci di tipo femminile.

Si e’ quindi preferito tornare sui nostri passi e realizzare un avatar di sesso femminile, quindi una giovane professoressa. Riportiamo il turnaround completo del personaggio:

WP4 Sviluppo: Realizzazione motore di render dello storytelling MESI 9-21 A seguito della completa messa a punto delle specifiche funzionali, si e' passati allo sviluppo del software vero e proprio. Di seguito, la descrizione del workpackage come da specifiche di progetto: WP4 (MESI 8-22, DV+IC+OI+FUB) Sviluppo: Realizzazione motore di render dello storytelling Verrà realizzato il motore di render, quella parte cioè del software che crea in tempo reale la storia vera e propria. Il motore di render, interpretando i comandi provenienti dall’avatar, assemblerà i contenuti audiovisivi disponibili, eventualmente aggiungendo movimenti di camera, effetti speciali ed effetti sonori, per creare il segmento di storytelling voluto. Inizialmente, è previsto un simulatore di Avatar, cioè un componente che emette comandi verosimili, simulando il comportamento interattivo dell’avatar. Questo workpackage in realta' non comprende solo la realizzazione del motore di render, ma anche la realizzazione delle librerie di base, degli elementi per la costruzione e l'editing dello storytelling nonche' dei widget base dell'interfaccia grafica. Illustreremo le varie componenti realizzate.

WP4.1 L'ambiente di Sviluppo e le librerie base. Per lo sviluppo del software si e' scelta la piattaforma Visual Studio 2008 nel linguaggio C++, Come librerie di base per la realizzazione degli elementi di interfaccia grafica, si e' scelto il pacchetto open source di libreria Qt (versione 4.6) della Nokia.

Durante lo sviluppo del software, si e' fatto un upgrade dell'ambiente di sviluppo passando a Visual Studio 2010 e alle librerie Nokia Qt 4.8. Per quanto riguarda la parte di render realtime onscreen, si sono utilizza le librerie standard openGl . Per la gestione dei suoni e delle musiche (caricamento, salvataggio playback) si e' scelta la libreria Ambiera irrKLang, mentre per la parte di gestione Videoclip (caricamento e playback embedded di movies) si e' utilizzata la libreria Phonon di Qt. Il sistema Vocs supporta i formati di file immagine e movie piu' diffusi, come tif, png, bmp, gif, jpg, etc. cosi' come i formati movie quicktime mov e avi. Per la parte audio, analogamente, sono supportati i formati standard come mp3, aiff, wav, flac. Per la lettura e scrittura di tali formati ci si e' avvalsi sia di librerie proprietarie sviluppate da Digital Video, che da librerie non commerciali come Quicktime (per il formato avi) e la libreria Tiff (per il formato tif)

WP4.2 I formati file di Vocs Come gia' accennato, per quanto riguarda i contenuti multimediali Vocs non ha introdotto formati proprietari, ma utilizza i piu' diffusi formati di immagini, movie e suoni. Per quanto riguarda invece la memorizzazione delle storie, si sono creati alcuni formati file, tutti basati sullo standard XML. Una storia interattiva di Vocs viene memorizzata all'interno di un folder, creato dal sistema, il cui nome coincide col nome della storia. Tale folder contiene i file che costituiscono la storia stessa, in particolare: - il file VST (Vocs Story) memorizza quali sono le scene costituenti la storia, e come sono organizzate tali scene nella storia. - il file VSC memorizza tutte le informazioni per la singola scena: gli elementi multimediali, la geometria sullo stage, i behaviour degli avatar, le action delle scena. Quindi ogni storia e' essenzialmente composta1 file VST e vari file VSC, uno per ogni scena nella storia.

WP4.3 Il motore di Render e lo Stage Editor

Per la realizzazione del motore di render si sono utilizzate le primitive di disegno openGl. Ogni scena e' composta da una serie di StageItem . Gli StageItem: sono elementi multimediali da visualizzare sullo stage. Ogni StageItem contiene informazioni (espresse tramite matrici affini di trasformazione) sulla sua geoetria all'interno dello stage. GLi stageItems possono essere Character, Props, HotAreas, o MultimediaItems: Characters : sono i contenuti multimediali animati e dotati un behaviour (gli Avatar). I Character hanno associato uno stato attuale, che evolve durante il playback della storia, e che indica che porzione dell'animazione visualizzare; Props : sono immagini statici visualizzate sullo stage, come backgrounds e oggetti di scena. Non sono elementi animati; HotAreas : sono elementi che definiscono zone speciali dello schermo. Servono epr mettere a punto azioni interattive, per definre area di playback di movie, etc. e non sono visualizzati durante il playback; MultimediaItem : sono i movie e le soundtrack utilizzate nella scena; Il disegno del singolo frame completo sullo schermo consiste nello scorrere i vari stageItem e applicare un metodo appropriato di render, basato su openGl . Il render completo della scena sullo stage Editor avviene in modalità diverse, che dipende si sta in modalità editing o playback. Render in editing mode : In questa modalita' viene fatto sempre il render dello stato iniziale della scena, i character non evolvono. Il ridisegno viene invocato in base agli input dell'utente, tipicamente click del mouse, o modifiche dei widget dell'interfaccia. In questa modalita' e' possibile caricare o cancellare stageItems, modificare la loro geometria sullo schermo, etc. In editing mode, vengono anche disegnati dei gadget per l'editing degli oggetti sullo schermo, come cornici, frecce, etc. In figura, l'interfaccia dello stage con una scena in edit mode:

Render in playback mode : Questa modalità effettua l'esecuzione della storia interattiva. Appena viene eseguita, si legge all'interno del plot la scena iniziale, si carica nello stage, e si esegue la action iniziale di essa. Il render viene regolato da un timer, che ad intervalli regolari (tipicamente 1/25 di secondo) fa evolvere il sistema in base alle action della scena e agli input vocali e non dell'utente. Di seguito riportiamo un diagramma del workflow di render della scena:

Ecco una breve descrizione dei nodi del diagramma di flusso: - Start : L'inizio della scena viene tipicamente invocato tramite un comando sull'interfaccia. - Load Scene ; vengono caricati tutti gli StageItem della scena, resettati tutti gli stati della scena corrente allo stato iniziale; - Loop : questo funge come una sorta di main Loop temporizzato del playback; la velocità settata corrisponde con il framerate del playback su schermo. - Check Input : si verifica se son arrivate delle richieste dall'utente. queste richieste possono essere tipicamente dei comandi vocali, ma anche comandi da interfaccia grafica (click del mouse sulla scena, pause/stop della storia, etc.) - Check Actions : all'interno del plot si verifica se una certa Action e' stata completata e si passa alla successiva, settando le opportune variabili di stato; - Changed Scene : seconda degli input e dell'evoluzione del plot si controlla se e' necessario cambiare scena (o terminare la storia). In tal caso, viene caricata la nuova scena (o se e' finita la storia, si torna in edit mode) .

Evolve Status : Viene settato il nuovo stato di tutti gli stageItem; Draw Scene : viene disegnata la scena sullo stage, esattamente come avviene in edit mode: con la differenza che gli StageItem hanno uno stato non iniziale; Play Multimedia: se richiesto, vengono lanciati i playback delle soundtrack e dei video.

WP4.4 Il plot, e il plot editor. Il plot e' l'elemento della storia in cui vengono specificate le azioni da compiere (actions) in seguito a comandi dell'utente o cambiamenti di stato. Ogni Action e' composta di blocchi che eseguono un'operazione elementare (come muovere un personaggio, suonare una soundtrack, etc) che vengono assemblati insieme in modo intuito tramite una interfaccia grafica che utilizza l'approccio del Visual Programming . In figura, un esempio di plot all'interno del software Vocs composto di alcune azioni:

Ogni action comincia con un blocco speciale(in rosso) che identifica un evento (comando vocale, inizio scena.etc) ed e' seguito da una serie di blocchi (colore blu) che seguono una serie di azioni. Altri blocchi speciali sono quelli che non prevedono ulteriori azioni (in giallo), come ad esempio fine storia, cambio scena, etc. E' possibile assemblare e manipolare i vari blocchi tramite drag&drop. Nella colonna di sinistra sono presenti tutti i blocks usabili nella scena.

L'implementazione dei blocchi in c++ e' stata fatta in modo molto strutturata e modulare, in modo tale che l'aggiunta di un nuovo blocco, e quindi di una nuova funzionalità, sia estremamente facile e veloce. Riportiamo di seguito il diagramma delle classi e delle ereditarietà per la classe base VBlock:

Diamo una breve descrizione delle classi basi e dei blocchi funzionali piu' importanti: VBlock : la classe base da cui ogni blocco deriva;

VExecuteBlock : esegue un comando. VConditionBlock : fa un check su qualche grandezza della scene attuale e ritorna true o false. VUnaryBlock : un blocco che puo' avere un solo blocco come successiva azione VZeraryBlock : un blocco conclusivo: nessun alra azione puo' essere eseguita in questa scena dopo di esso. VIfBlock ; un blocco che accetta come argomento un VConditionBlock e 2 VExecuteBlock, e implementanta il comando if..then..else. VMoveCameraBlock : esegue un movimento di camera di tipo pan e zoom. VPlayVideoBlock : un dato videoclip viene mostrato sullo stage. VPerformCharacterBlock : va eseguire una data animazione ad un avatar specificato VStartBlock : un blocco di inizio action, tipicamente un evento esterno VVocalCommandBlock : uno startBlock invocato quando un o o piu' comandi vocali asegnati son stati dati; VStartSceneBlock : StartBlock invocato all'inizio di una scena

WP4.5 la Story e lo Story editor. Le varie scene della storia, e le loro connessioni all'interno della storia, possono venire visualizzate, sotto foram di grafo orientato, ed editate all'interno dello story editor. In figura un esempio di una storia composto di 4 scene:

Ogni arco indica che durante il playback della storia, e' possibile passare da una scena a quella ad essa collegata. Lo story editor viene popolato in modo semi automatico: sia le icone che rappresentano le scene che gli archi di connessione infatti vengono calcolati automaticamente da Vocs.

WP5 Sviluppo: Realizzazione motore vocale dello st orytelling MESI 8-22 . Di seguito, la descrizione del workpackage come da specifiche di progetto: WP5 (MESI 8-22, MV+CUL) Sviluppo: Realizzazione motore vocale dello storytelling Verrà realizzato l’engine vocale dello storytelling, vale a dire il modulo della piattaforma che rappresenta la parte vocale dell’Avatar e che è in grado di gestire i due motori di basso livello di sintesi, Text to speech (TTS) e riconoscimento vocale, Automatic Speech Recognition (ASR), insieme al sottomodulo VUI che

gestisce la interfaccia vocale disegnata e interagisce con la parte grafica dell’Avatar.

WP 5.1 L'interfaccia utente

L'interfaccia utente di Speakable è estremamente semplice. Tramite avvisi sull’ambiente grafico di Windows informa l’utente tramite dei messaggi non invasivi dello stato operativo del programma. L’avvio del sistema presenta la schermata in figura: Premendo start si avvia il monitoraggio della cartella designata, pre-impostata all’interno del registro sistema di windows nella chiave: HKEY_CURRENT_USER -> Software -> VocsProject -> VocsConfig -> VvcFolder Il software risponde tramite un “ballon Tip” sulla barra di windows ai vari eventi programmati:

1. Attivazione del servizio. 2. Disattivazione del servizio. 3. Rilevazione modifiche e elaborazione dei file. 4. Chiusura dell’applicazione

WP5.2 Funzionamento

Il servizio si incarica di monitorizzare, quando attivato, in modo costante la cartella definita nella chiave: HKEY_CURRENT_USER -> Software -> VocsProject -> VocsConfig -> VvcFolder in cerca di file del tipo nome_file_da_monitorare.vvc

Esempio di file museo della musica.vvc Quando viene rilevato un nuovo file o viene effettuata una modifica a un file esistente, quest’ultimo viene immediatamente processato. Vengono creati nella cartella definita nella chiave:

<story name="visita_del_museo_della_musica"> <global_events> <event id='0'> <vocal_command sentence="stop"/> <vocal_command sentence="ferma"/> </event> <event id='1'> <vocal_command sentence="alza volume"/> </event> <event id='2'> <vocal_command sentence="abbassa volume"/> </event> </global_events> <scene_events scene_name="inizio_visita"> <event id='3'> <vocal_command sentence="vai a sinistra"/> <vocal_command sentence="sinistra"/> <vocal_command sentence="cammina verso sinistra"/> <vocal_command sentence="torno indietro"/> </event> <event id='4'> <vocal_command sentence="vai a destra"/> </event> </scene_events> <scene_events scene_name="nella_stanza_dei_liuti"> <event id='3'> <vocal_command sentence="spiega"/> <vocal_command sentence="raccontami"/> <vocal_command sentence="cosa sono questi?"/> <vocal_command sentence="basta non mi interessa"/> </event> <event id='4'> <vocal_command sentence="vai nella prossima stanza"/> </event> </scene_events> </story>

HKEY_LOCAL_MACHINE -> Software -> Wow6432Node -> Mediavoice -> SpeakyMCE le grammatiche ed i voice template della visita secondo la regola di un Voice Template per visita e una grammatica per scena.

Esempio di Voice Template creato dal sistema: visita_del_museo_della_musica.xml

<root version="2.0"> <ASR> <Grammar id="inizio_visita" dictionary="2@@visita_del_museo_della_musica@@main@@static@@visita_del_museo_della_musica_inizio_visita@@main@@static"> <Role> <Phrase> <static>CMD</static> </Phrase> <Parsed> <statoid>inizio_visita</statoid> <textid>void_text</textid> <textcmdid>command</textcmdid> </Parsed> </Role> </Grammar> <Grammar id="nella_stanza_dei_liuti" dictionary="2@@visita_del_museo_della_musica@@main@@static@@visita_del_museo_della_musica_nella_stanza_dei_liuti@@main@@static"> <Role> <Phrase> <static>CMD</static> </Phrase> <Parsed> <statoid>nella_stanza_dei_liuti</statoid> <textid>void_text</textid> <textcmdid>command</textcmdid> </Parsed> </Role> </Grammar> </ASR> </root>

Esempio di Voice Template creato dal sistema: visita_del_museo_della_musica.xml

visita_del_museo_della_musica_inizio_visita.gram

WP6 Test e Tuning prototipo piattaforma MESI 20-24

. Di seguito, la descrizione del workpackage come da specifiche di progetto: WP6 (MESI 20-24, DV+MV+IC+OI+FUB+CUL+SC) Test e Tuning prototipo piattaforma Nell’ultima fase del progetto verrà effettuato sia un nuovo test modulare, sia un test complessivo con relativo tuning. Questa fase è necessaria ai fini di irrobustire la piattaforma e di calibrare i suoi parametri operativi

affinché corrisponda al meglio alle specifiche utente disegnate inizialmente.

language it-it; mode voice; root $main; tag-format <loq-semantics\1.0>; public $main = ( ( $voice_command {:cmd}) {<@semantica strcat("CMD?#?" $cmd)>} ); $voice_command = ( "vai a sinistra":"3" | "sinistra":"3" | "cammina verso sinistra":"3" | "torno indietro":"3" | "vai a destra":"4" ) {return($value)};

Per il test e tuning del prototipo, si e’ realizzata una storia completa, sufficientemente complessa da permettere un test esaustivo delle varie funzionalità. Lo sviluppo della storia, data la sua complessità, e’ iniziata già dal mese 12, con una collaborazione molto stretta tra gli sviluppatori software e gli autori che ha permesso la modifica delle feature sviluppate, nonché dell’interfaccia grafica, in base alle indicazioni continue degli autori durante l’implementazione della storia. La storia presenta infatti diverse feature, come playback di videoclip inseriti all’interno delle scene, movimenti dio camera complessi, giochi interattivi, e cosi via. Riportiamo di seguito la descrizione della storia realizzata.

WP6.1 Set-up del sistema, training e aggiornamenti

Come passo iniziale per l’uso di VOCS, il sistema è stato installato su alcune macchine dell’Accademia insieme allo staff di Digital Video. Contestualmente è stato anche installato il sistema di riconoscimento vocale Speaky insieme allo staff di MediaVoice.

Allo stesso tempo è stata studiata la documentazione (manuale utente e casi d’uso) e sono state effettuate delle sessioni di training. Durante tutto il progetto il software si è evoluto e nuove versioni con nuove funzionalità sono state consegnate. C’è quindi stato un continuo feedback incrociato con il team di sviluppo (ad esempio con feature-request o bug-report) che ha seguito da un lato l’evoluzione del software, dall’altro quella della story stessa.

Per la condivisione delle varie versioni della storia è stato utilizzato sia un server FTP, sia (successivamente) un servizio di storage online pensato per lo sviluppo, che offre GIT1 come sistema per il versioning.

WP6.2 Realizzazione della story

Una volta reperiti e preparati i contenuti essi sono stati importati in VOCS attraverso semplice drag-and-drop. Per semplificare e rendere più efficiente il lavoro, una copia di tutti i contenuti necessari è stata fatta localmente sulla macchina utilizzata per l’editing. Una volta importati i contenuti in VOCS, essi vengono visualizzati in una struttura ad albero (il browser delle scene )

Ecco riportata la struttura ad albero della story, come appare nel software:

Ogni scena è stata organizzata visualmente nello Stage Editor nel quale vengono disposti e organizzati i vari contenuti visuali quali sfondi, oggetti, character con operazioni di spostamento e posizionamento, ridimensionamento ecc.

Riportiamo le schermate dell’interfaccia del software per quanto riguarda due delle scene della story, la scena iniziale e la scena “Launeddas”, che evidenziano la disposizione dei vari elementi grafici

1 Si veda http://it.wikipedia.org/wiki/Git_%28software%29

Ecco invece la scena “Launeddas” durante il playback:

I contenuti audio e video sono stati aggiunti nel Plot Editor: essi, infatti, hanno natura temporale (devono iniziare a in un certo momento, durare per un certo intervallo di tempo e poi finire).

Elemento centrale della story è l’avatar, chiamato all’interno del software “Character”. Dal punto di vista tecnico il Character è una sequenza di frame forniti come immagini singole o all’interno di un video, eventualmente con una trasparenza. Una volta importato un insieme di frame, l’avatar viene “modellato” all’interno del Character Editor, nel quale è possibile stabilirne il comportamento in unità dette “Nodi”. Ogni nodo è costituito da una serie di frame contigui, possiede una alcune proprietà e può essere collegato logicamente ad altri nodi. Come delineato nella griglia sinottica (v. Errore. L'origine riferimento non è stata trovata. ) l’avatar deve entrare camminando in ogni scena: questo elemento, infatti, produce un senso di maggiore immersione nella storia, dando all’utente l’idea di essere realmente nell’ambiente del museo. A questo scopo è stato creato il nodo “walk1” con un attributo Move diverso da zero: ciò indica a VOCS che quando il Character è in questo nodo esso deve spostarsi. Il comportamento esatto e l’andamento dello spostamento (in questo caso un “camminata”) verranno poi definiti successivamente nel Plot Editor.

Ecco come appare tale nodo “walk1” nell’interfaccia del software:

Il parlato, ovvero l’animazione labiale, è gestito indipendentemente dall’animazione dell’avatar stesso. Ciò vuol dire che in ogni momento in cui l’avatar deve parlare, deve anche muovere la bocca coerentemente. Il labiale viene quindi specificato in un attributo specifico “Mouth” il quale punta a un video contenente l’animazione. Sono quindi stati creati i nodi necessari per il parlato. Anche in questo caso la gestione vera e propria delle sequenze di parlato all’interno di ogni scena avviene successivamente nel Plot Editor.

Qui di seguito tree esempi di nodi dell’avatar realizzati per il parlato. E’ presente il fil mouth.mov, che contiene le bocche con le varie posizioni.

Una volta importati i contenuti e organizzata la scena con la disposizione visiva degli elementi necessari (grafica, hotspot, avatar), si è passati alla realizzazione della “trama” vera e propria della story all’interno del Plot Editor. Ovviamente la story sviluppa con VOCS è interattiva e quindi la trama è aperta e deve contenere elementi logici in grado di reagire a diverse condizioni esterne quali l’input dell’utente, il passare del tempo, ecc.

Partendo dalla Griglia sinottica per la storia si è proceduto alla elaborazione delle scene. Senza entrare nel dettaglio di ogni singola scena, riportiamo qui alcuni elementi salienti relativi al lavoro nel plot editor.

Chiaramente il design di alcune scene è stato più complesso rispetto ad altre. Ad esempio la scena introduttiva è relativamente statica (l’avatar entra su una musica di sottofondo, dice qualcosa e poi passa alla scena successiva); ben più articolata è la scena che funge da menù principale della visita: qui l’avatar deve spiegare agli utenti le varie entrate del menù, inoltre essi devono poter scegliere (attraverso un comando vocale) una qualunque delle scene presentate. Questa scena contiene quindi un blocco principale con le azioni del personaggio e i contenuti relativi (musica di sottofondo, parlato ecc.), ma parallelamente anche una serie di blocchi che reagiscono ai comandi degli utenti. E’ stato aggiunto anche un blocco “On Bad Vocal Command”, importante per dare un feedback all’utente nel caso abbia dato un comando non previsto o che il sistema non sia in grado di comprendere: in questo caso l’avatar dice di non aver capito e riepiloga brevemente le possibili scelte presenti nel menu.

Nella figura seguente, sopra: blocchi “On vocal command” per la scena menù, che permettono all’utente di lasciare la scena e far partire quella scelta. Sotto: frammento di blocco “On Bad Vocal Command” per reagire a un comando vocale non riconosciuto

Ed ecco uno screenshot della scena menu, con l’avatar che indica le diverse opzioni disponibili.

Una delle scene più complesse da realizzare è indubbiamente stata quella relativa all’orchestra. In questa viene proposto all’utente un gioco nel quale deve indovinare, ascoltandoli, alcuni strumenti dell’orchestra. Per la realizzazione del gioco sono state sfruttate appieno le caratteristiche avanzate del Plot editor, in particolare gli operatori logici.

Quando l’utente dà il via con un comando vocale, una variabile todo viene settata a 1: essa corrisponde allo strumento corrente.

Ecco il blocco iniziale per la partnza del gioco. Si noti come la variabile “todo” venga inizializzata a 1

A questo punto viene chiamata una Action che suona condizionalmente il file audio relativo. L’utente può provare in ogni momento a dire il nome dello strumento, a questo punto verrà attivato un Vocal Command e un blocco logico che controlla che il comando vocale sia effettivamente corrispondente allo strumento attuale. Si veda come esempio come la Errore. L'origine riferimento non è stata trovata. . L’Action “ascolta” controlla qual è lo strumento corrente ed esegue il file audio associato, nel caso particolare in cui siano stati indovinati tutti gli strumenti verrà eseguito un file finale. Esaminiamo il blocco relativo al comando vocale per indovinare il violino. Se l’utente dice “violino”, il blocco condizionale controlla che il violino sia effettivamente lo strumento corrente: nel caso questo sia vero, l’avatar comunicherà all’utente il successo e la variabile todo verrà settata allo strumento successivo. In caso contrario, l’avatar comunica l’insuccesso. Alla fine del blocco viene semplicemente richiamata l’action, a prescindere dall’esito.

Questo semplice gioco risulta particolarmente interessante sia dal punto di vista educativo sia dell’interfaccia: infatti la possibilità di interagire con comandi vocali, come se si stesse parlando con una persona, permette all’utente di concentrarsi solo sul gioco (ad esempio sull’ascolto dello strumento da indovinare), senza essere disturbato da possibili mediazioni dell’interfaccia (dover fare click su qualcosa ecc.): dal punto di vista educativo questo permette di avere un feedback immediato e di interagire col sistema in maniera naturale e con i propri ritmi.

Nella figura seguente, a sinistra: spezzone dell’Action relativa alla riproduzione degli strumenti da indovinare. A destra: blocco comando vocale relativo al violino

WP6.3 Conclusioni

Abbiamo descritto le attività svolte nell’ambito del progetto VOCS. Il lavoro è stato organizzato in diverse fasi riassumibili in: progettazione della storia, reperimento e creazione dei contenuti, realizzazione della storia. La prima fase ha visto un lavoro di analisi del settore culturale e musicale con particolare attenzione agli aspetti didattico-educativi legati alle attività svolte dall’Accademia e conseguente progettazione della storia, relativa alle attività del Museo di Strumenti Musicali. Nella fase successiva si è proceduto alla creazione del database di contenuti sia estraendoli e adattandoli dagli archivi multimediali dell’Accademia, sia creandoli ad uopo. Infine l’ultima fase ha visto la creazione vera e propria della storia tramite il software VOCS, con un processo iterativo di scambio con i partner coinvolti nel progetto e di adattamento in itere dei contenuti ove necessario. Attraverso la tecnologia VOCS è stato quindi possibile creare con successo un’applicazione multimediale con interazione vocale per il Museo di Strumenti Musicali mirata ai ragazzi: essa permette di presentare in maniera intuitiva e interessante alcuni aspetti salienti della storia e del patrimonio culturale dell’Accademia attraverso un coinvolgimento attivo dell’utente e riducendo le barriere tradizionalmente create dai metodi d’interazione tradizionale con le tecnologie (ad esempio tastiere, mouse ecc.): riducendo

tali barriere il sistema è in grado di incrementare le capacità didattico-educativa e divulgative del Museo, e - quindi – potenzialmente di attirare un maggiore e più variegato numero di visitatori.

Appendice: Rete di cooperazione tra imprese e orga nismi di ricerca.

Secondo quanto previsto dal progetto, le attività di implementazione della rete di cooperazione tra imprese e organismi di ricerca sono state avviate come attività di un vero e proprio Laboratorio, da sperimentare come luogo fisico e virtuale di collegamento tra le esigenze di innovazione delle PMI del territorio e le potenzialità innovative dell’attività di ricerca.

Si è, quindi, proceduto in primo luogo ad attivare un gruppo di lavoro composto da rappresentanti di imprese, organismi di ricerca, associazioni, partecipanti alla rete insieme alle due imprese proponenti, Mediavoice SrL e Digital Video SpA, e al Dipartimento di Ingegneria dell’Informazione, Elettronica e Telecomunicazioni – DIET – dell’Università di Roma La Sapienza (già Dipartimento Infocom e ora denominato DIET a seguito della fusione con il Dipartimento di Elettronica), che svolge anche specifica attività di ricerca per la realizzazione del progetto, con la finalità di realizzare l’organizzazione di incontri, workshop, eventi con le strutture partecipanti, per scambi di idee, di esperienze, confronti tra le buone pratiche e i casi aziendali di successo.

Hanno partecipato, in particolare, a tale primo nucleo costituito del gruppo di lavoro, rappresentanti del Dipartimento di Ingegneria Elettronica dell’Università degli Studi Tor Vergata di Roma, dell’Associazione Università Ricerca Innovazione Società – AURIS onlus –, delle aziende operanti nel settore dell’ICT e della multimedialità CoMetis S.r.l., Ingegneria 2000, Videoprogetti SrL.

Il gruppo di lavoro ha operato fin dalla sua costituzione come un punto di riferimento collegiale di scambio e di confronto, realizzato in modo anche informale, con scambi frequenti di idee e di informazioni, nella logica di far crescere la conoscenza individuale e collettiva e di sperimentare nuove forme organizzate di collaborazione. Si è posto, però, fin da subito l’obiettivo di ampliare ed estendere la partecipazione ad altri soggetti imprenditoriali e di ricerca che operano nel campo dell’ICT e della multimedialità, e in particolare a quelli fortemente proiettati verso l’innovazione, ponendo anche attenzione a compagini di ricercatori impegnati nella costruzione di spin off universitari e, quindi, geneticamente orientati al collegamento tra ricerca e sviluppo di processi di innovazione e trasferimento tecnologico. Si sono realizzati numerosi incontri, contatti via web, riunioni ad hoc, nelle quali è stato esaminato lo stato di avanzamento tecnico scientifico del progetto VOCS-NET, in particolare, sotto il profilo dei risultati delle attività di ricerca, ma, più in generale, è stato avviato uno scambio di informazioni e conoscenze sullo stato dell’arte e le prospettive di evoluzione della ricerca tecnologica nel campo dell’ICT e, sul piano più specificamente imprenditoriale, sulle prospettive produttive e di mercato delle attività innovative sviluppate e in corso di realizzazione da parte delle imprese coinvolte.

Si è, successivamente, proceduto a progettare le linee di azione del piano operativo per la realizzazione della rete di cooperazione, secondo le quali sono state sviluppate le attività, riassunte schematicamente come di seguito:

- realizzazione sistematica nel Laboratorio per la costruzione della rete di cooperazione di scambi, confronti di idee, esperienze, tra i soggetti del mondo della ricerca e i soggetti del mondo dell’impresa, finalizzati anche ad identificare progressivamente contenuti e azioni per i quali organizzare forme di collaborazione stabile;

- ricognizione delle realtà di ricerca e imprenditoriali del settore dell’ICT e della multimedialità contattabili e coinvolgibili nei momenti di confronto e scambio di idee e problematiche del Laboratorio per la costruzione della rete di cooperazione, anche al fine di identificare i soggetti da includere nella rete di cooperazione o con i quali, comunque, costruire forme di comunicazione e connessione con caratteri di continuità;

- azioni di sensibilizzazione del mondo della ricerca, con particolare attenzione alla creazione di contatti con giovani laureati e laureandi con competenze tecnologiche nel settore dell’ICT e della multimedialità e orientati all’impegno in attività innovative;

- iniziative di contatto e scambio con spin off universitari costituiti o in corso di costituzione operanti nel settore dell’ICT e della multimedialità;

- azioni di contatto con altre reti di cooperazione tra organismi di ricerca e imprese nell’obiettivo di costruire utili sinergie, sia per lo sviluppo di processi di innovazione, che per incrementare le potenzialità di mercato;

- analisi e approfondimento della nuova forma del “Contratto di Rete” come possibile linea di evoluzione generabile nell’ambito della costituenda rete di cooperazione tra organismi di ricerca e imprese.

A seguito di tali attività si è giunti alla definizione dell’Agreement di Rete che prevede l’attivazione tra tutti i partecipanti di una collaborazione tecnico-scientifica per lo sviluppo di attività di ricerca industriale e di sviluppo sperimentale nel campo delle tecnologie ICT e multimediali e delle loro diverse applicazioni in ambito civile. Prevede, inoltre, la disponibilità di tutti i partecipanti a promuovere, anche su proposta di una delle parti, conferenze illustrative concernenti le attività svolte; tirocini formativi e/o professionali, partecipazione a bandi e avvisi pubblici e privati, sia nazionali, che internazionali, riguardanti il campo di collaborazione tecnico-scientifica individuato. Nello spirito di estensione della rete di collaborazione, prevede, infine, di accettare la partecipazione alla rete di collaborazione, di due spin off universitari del Dipartimento DIET, in corso di costituzione, che saranno denominati il primo MediaMove e il secondo ICTinnova, e che saranno entrambi costituiti in forma di SrL, nonché di accettare la partecipazione alla rete di collaborazione di altre aziende e altri enti di ricerca che ne facessero richiesta e con i quali sarà ritenuto possibile attivare positive sinergie tecnologiche e/o commerciali.

Momento particolarmente significativo nella creazione della Rete di cooperazione è stata la realizzazione dell’evento, svolto in data Venerdì 22 giugno 2012. L’evento, dal titolo “UNIVERSITA’, RICERCA, IMPRESA IN RETE PER L’INNOVAZIONE E LO SVILUPPO”, si è svolto presso l’Auletta del Chiostro della Facoltà di Ingegneria Università la Sapienza a San Pietro in Vincoli. L’evento è stato realizzato come un incontro aperto, con la partecipazione di rappresentanti del mondo dell’università e della ricerca, del mondo dell’impresa e di enti e istituzioni locali.

I temi trattati hanno riguardato le problematiche relative alle difficoltà economiche dell’Italia e all’urgenza di far ripartire un trend di crescita stabile, necessariamente alimentato dallo sviluppo diffuso di processi di innovazione che si innestino nel tessuto produttivo italiano, costituito in massima parte da PMI. E’ stato sottolineato come occorra attivare iniziative e interventi che, anche a partire dai territori, vedano come protagonisti gli attori centrali della filiera dell’innovazione, il mondo dell’università e della ricerca, il mondo dell’impresa, con il coinvolgimento degli enti preposti al sostegno della ricerca e dell’innovazione, con particolare attenzione alle PMI, in modo da accrescerne la competitività e favorirne l’internazionalizzazione. E’ stata evidenziata l’importanza di creare nella regione Lazio opportunità e facilitazioni per l’attivazione di rapporti e reti di collaborazione tra mondo dell’università e della ricerca e PMI e tra PMI con vocazioni tecnologiche sinergiche, e di sostenere e incentivare la costituzione e la vitalità di spin off tecnologici e accademici.

Nel corso dell’evento è stato presentato e firmato l’Agreement di Rete di Cooperazione tra PMI e Organismi di Ricerca, creata nell’ambito del progetto “Voice On Content Storyteller - VOCS-NET”.

All’evento hanno partecipato, tra gli altri, il Direttore del Dipartimento DIET e delegato Università la Sapienza per i rapporti con le PMI, il Direttore Generale Sviluppo Lazio SpA, la FILAS SpA, il Vice Presidente del Parlamento Europeo, insieme a tutte le realtà che, con le due imprese promotrici Mediavoice SrL e Digital Video SpA, hanno sottoscritto l’Agreement di Rete, il Dipartimento DIET, l’Associazione AURIS onlus, Mantrics S.r.l., Digital Video S.p.A., I4E2 SrL, Quadra TV SCARL, Cosmic Blue Team S.p.A, Ingegneria 2000 SrL, nonché numerosi rappresentanti di imprese del Lazio, di associazioni, di Dipartimenti universitari, di spin off universitari.

Allegato: Agreement di creazione di una rete di collaborazione, promossa da Digital Video S.p.A e da Mediavoice SrL, nell’ambito del progetto “Voice On Content Storyteller - VOCS-NET -.

Conclusioni

Prototipi

Alla conclusione del progetto, e’ disponibile un prototipo perfettamente funzionante e completo di tutte le funzionalità previste. Con tale prototipo è stata realizzata una storia completa che verra’ presentata in un evento che si svolgerà nei prossimi mesi presso la sede di Santa Cecilia.

Risultati ottenuti Tutti i task relativi al progetto sono stati completati nei tempi previsti.

Attualmente, per il progetto Vocs, non sono in corso registrazione di brevetti.

Coordinate bancarie

Banca: Banca Intesa S. Paolo S.P.A. - Filiale di Roma 28

Indirizzo: Via Tiburtina 582, 00159 Roma

C/C n. 100000004400 ABI 03069 CAB 03218 CIN O

IBAN: IT88 O 03069 03218 100000004400

Intestazione del c/c: DIGITAL VIDEO SPA

Data

Timbro e firma

(del legale rappresentante)

Allegati: Rendicontazione amministrativa dei costi sostenuti, secondo la modulistica e la guida predisposte da Filas S.p.A., corredata da :

- allegato 1 : Dichiarazione in autocertificazione liberatoria del fornitore e beni nuovi di fabbrica;

- allegato 2 : Dichiarazione in autocertificazione attestante i requisiti dell’impresa;

- allegato 3 : Dichiarazione in autocertificazione attestante i requisiti del progetto;

- allegato 4 : Dichiarazione in autocertificazione attestante la data di fine progetto (solo per richiesta a saldo);

- allegato 5 : Dichiarazione in autocertificazione prototipo (solo per richiesta a saldo);

- allegato 6 : Dichiarazione in autocertificazione attestante le spese generali sostenute;

- allegato 7 : fac simile time sheet

5

� Informativa ai sensi dell’art. 13 DLGS. 196/2003 (c odice della privacy)

In conformità al decreto legislativo 30 giugno 2003 n. 196 (Codice in materia di protezione dei dati personali)

e successive modifiche, FI.LA.S. S.p.A., con sede in Roma, Via della Conciliazione, 22, in qualità di titolare

del trattamento, è tenuta a fornire ai soggetti interessati, ai sensi dell’art. 13, le seguenti informazioni

riguardanti l’utilizzo dei relativi dati personali.

INFORMAZIONI CIRCA IL TRATTAMENTO DEI DATI RACCOLTI

1) Modalità di raccolta dei dati personali

I Suoi dati personali saranno raccolti presso tutte le sedi di Filas S.p.A., con o senza l’ausilio di modalità

telematiche, e trattati, con modalità anche automatizzate, anche ai fini della loro inclusione in una banca di

dati, ed in ogni caso con strumenti idonei a garantirne la sicurezza e la riservatezza.

2) Finalità del trattamento dei dati personali

I dati saranno trattati da Filas S.p.A. e da società del gruppo Filas per le seguenti finalità:

a) per l’adempimento ad obblighi di legge, regolamenti e normative comunitarie cui è sottoposta la FI.LA.S.

S.p.A., o i servizi da Voi richiesti (fatturazione, documentazione necessaria per l’attivazione dei finanziamenti

pubblici, valutazione e finanziabilità del progetto, revisione contabile, ecc.);

b) per dare esecuzione a contratti nei quali siete parte, o ad obblighi scaturenti dagli stessi, o per acquisire

informazioni precontrattuali attivate su Vostra richiesta (garanzie, fidejussioni, merito di credito, ecc.);

c) per altre finalità gestionali ed organizzative interne (programmazione delle attività, ecc.);

3) Modalità di trattamento dei dati personali

In relazione alle indicate finalità, il trattamento dei dati personali avviene mediante strumenti manuali ed

informatici, telematici o comunque automatizzati con logiche strettamente correlate alle finalità stesse e,

comunque, in modo da garantire la sicurezza e la riservatezza dei dati stessi.

4) Conferimento dei dati personali

Il conferimento dei dati personali è obbligatorio per le finalità relative agli adempimenti di cui al precedente

punto 2.

L’eventuale rifiuto di conferire e/o autorizzare il trattamento dei dati per le suddette finalità comporterà

l’impossibilità della instaurazione, prosecuzione del rapporto e/o valutazione del progetto.

La successiva eventuale opposizione o revoca al trattamento dei dati personali per le suddette finalità

comporterà l’impossibilità della prosecuzione del rapporto e/o valutazione del progetto.

5) Categorie di soggetti ai quali i dati possono es sere comunicati con il consenso dell’interessato

I Suoi dati personali non saranno diffusi e/o comunicati a terzi, salvo che ai seguenti soggetti ai fini esclusivi

dello svolgimento del Servizio:

• Enti, od Amministrazioni Pubbliche, anche Comunitari, il cui intervento è previsto da leggi, regolamenti e

normative comunitarie o dalle convenzioni o accordi in base ai quali opera la nostra Società;

• liberi professionisti anche in forma associata o società che operano per nostro conto valutazioni di

progetto, incluso il possesso di requisiti per l’attivazione di fondi pubblici;

• società di consulenza amministrativa, organizzativa e gestionale (società di revisione, società di

consulenza informatica, ecc.);

• professionisti e società di recupero crediti.

• società che svolgono servizi bancari, finanziari ed assicurativi;

• società controllate, collegate o comunque appartenenti allo stesso gruppo, ai fini dello svolgimento del

Servizio.

Tutti i soggetti appartenenti alle categorie ai quali i dati possono essere comunicati utilizzeranno i dati in

qualità di “Titolari” ai sensi della legge, in piena autonomia.

L’ambito di diffusione territoriale dei Suoi dati sarà limitato al territorio dell’Unione Europea.

6) Titolare e responsabile del Trattamento dei dati in base all’art. 4 lett. f) e lett f) del D.lgs. 1 96/2003

Titolare del trattamento è FI.LA.S. – Finanziaria Laziale di Sviluppo – S.p.A., con sede in Roma, Via della Conciliazione, 22 – 00193 Roma, cap. soc. 35.857.000,00 Euro, iscritta presso il Registro delle Imprese di Roma al n. 398087.

Il responsabile al quale Lei può rivolgersi per l’esercizio dei diritti di cui al successivo punto 7 è il Responsabile dell’Area Gestione Agevolazioni, domiciliato per la carica presso la sede di Filas di Via della Conciliazione, 22 – 00193 Roma, tel.: 06.328851, fax: 06.36006808, e-mail: [email protected].

Un elenco aggiornato dei responsabili del trattamento è disponibile su Sua richiesta presso la sede legale di Filas.

7) Diritto di accesso ai dati personali ed altri di ritti in base all’art. 7 D.lgs. 196/2003 1. L'interessato ha diritto di ottenere la conferma dell'esistenza o meno di dati personali che lo riguardano, anche se non ancora registrati, e la loro comunicazione in forma intelligibile.

2. L'interessato ha diritto di ottenere l'indicazione:

a) dell'origine dei dati personali;

b) delle finalità e modalità del trattamento;

c) della logica applicata in caso di trattamento effettuato con l'ausilio di strumenti elettronici;

d) degli estremi identificativi del titolare, dei responsabili e del rappresentante designato ai sensi del precedente punto 6;

e) dei soggetti o delle categorie di soggetti ai quali i dati personali possono essere comunicati o che possono venirne a conoscenza in qualità di rappresentante designato nel territorio dello Stato, di responsabili o incaricati.

3. L 'interessato ha diritto di ottenere:

a) l'aggiornamento, la rettificazione ovvero, quando vi ha interesse, l'integrazione dei dati;

b) la cancellazione, la trasformazione in forma anonima o il blocco dei dati trattati in violazione di legge, compresi quelli di cui non è necessaria la conservazione in relazione agli scopi per i quali i dati sono stati raccolti o successivamente trattati;

c) l'attestazione che le operazioni di cui alle lettere a) e b) sono state portate a conoscenza, anche per quanto riguarda il loro contenuto, di coloro ai quali i dati sono stati comunicati o diffusi, eccettuato il caso in cui tale adempimento si rivela impossibile o comporta un impiego di mezzi manifestamente sproporzionato rispetto al diritto tutelato.

4. L 'interessato ha diritto di opporsi, in tutto o in parte:

a) per motivi legittimi al trattamento dei dati personali che lo riguardano, ancorchè pertinenti allo scopo della raccolta;

b) al trattamento di dati personali che lo riguardano a fini di invio di materiale pubblicitario o di vendita diretta o per il compimento di ricerche di mercato o di comunicazione commerciale.

Lei potrà esercitare in qualsiasi momento e gratuit amente i diritti previsti dall'art. 7 del Dlgs. 196 /2003

rivolgendosi al Titolare del trattamento.

DICHIARAZIONE DI CONSENSO Spettabile FILAS S.p.A.,

Io sottoscritta/o ________________________, con la presente, ad ogni effetto di legge e di regolamento, ed in particolare ai sensi del Decreto Legislativo 30 giugno 2003, n. 196, preso atto dell’informativa fornita dichiaro di prestare il mio libero, consapevole, informato, specifico ed incondizionato consenso al trattamento dei miei/nostri dati, ivi compresa la comunicazione ai soggetti di cui al punto 5 dell’informativa, ai fini esclusivi dello svolgimento del Servizio e per le finalità di cui al punto n. 2 dell’informativa

Data

Timbro e firma del Legale Rappresentante

RICHIESTA EROGAZIONE AGEVOLAZIONI - mediavoice.it Vocs SAL finale.pdf · riconoscimento automatico...

Documents

Transcript of RICHIESTA EROGAZIONE AGEVOLAZIONI - mediavoice.it Vocs SAL finale.pdf · riconoscimento automatico...