Generování dialogových rozhraní

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY P <?A %, \J/ & Generování dialogových rozhraní DISERTAČNÍ PRÁCE Luděk Bártek Brno, 2005

Prohlášení Prohlašuji, že tato disertační práce práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: doc. RNDr. Ivan Kopeček, CSc. 11

Poděkování V úvodu této práce bych rád poděkoval svým kolegům z Laboratoře řeči a dialogu Fakulty Informatiky Masarykovy univerzity za cenné náměty a rady při tvorbě práce a vlastního textu. Jmenovitě bych rád poděkoval docentu Kopečkoví, magistrům Čeňkovi, Batůškovi, Gaurovi a dalším spolupracovníkům. Dále bych chtěl poděkovat všem, kteří mi umožnili publikovat dosažené výsledky na konferencích. Nemalou pomoc mi také poskytli lidé, kteří mi pomohli s korekturami textu. m

Obsah 1 Úvod 5 1.1 Současný stav oblastí souvisejících s transkódováním. 6 1.1.1 Jazyky pro popis dialogových rozhraní 6 1.1.2 Dialogová rozhraní 7 1.1.3 Techniky realizace transkódování uživatelských rozhraní 7 1.2 Cíle práce 9 1.3 Poznámky k obsahu práce 9 2 Dialogová rozhraní 11 2.1 Základní pojmy 11 2.2 Dialogová komunikace a její cíl 12 2.3 Dialogový systém 13 3 VoiceXML 15 3.1 Struktura VoiceXML dokumentu 15 3.2 Gramatiky používané ve VoiceXML 17 3.2.1 XML formát SRGS gramatiky 17 3.2.2 Augmented BNF formát SRGS gramatiky... 18 4 Převod grafických rozhraní na dialogová 21 4.1 Kategorizace vstupních komponent 22 4.2 Stromová reprezentace grafického rozhraní 23 4.3 Mentální model GUI 25 4.4 Hodnotící kritérium stromu komponent GUI 26 4.4.1 Požadavky na hodnotící funkci 26 4.4.2 Návrh hodnotícího kritéria 27 5 Generování dialogů s iniciativou systému 30 5.1 Optimalizace stromu vstupních komponent 31 5.2 Získávání popisů vstupních polí 32 5.3 Transformace vstupních komponent 34 5.3.1 Libovolný text 34 5.3.2 Vstup jedné hodnoty z dané množiny 34 1

OBSAH 5.3.3 Vstup více hodnot 42 6 Generování dialogů se smíšenou iniciativou 45 6.1 Nápověda pro uživatele 45 6.1.1 Identifikace požadovaných údajů 46 6.1.2 Generování nápovědy 47 6.2 Analýza uživatelské odpovědi 48 6.2.1 Kritérium podobnosti informačních systémů a jejich GUI 50 6.2.2 Rozšiřování množiny pravidel 52 6.2.3 Návrh struktury databáze pravidel 53 6.2.4 Generování pravidel z uživatelských odpovědí 53 6.2.5 Ekvivalence pravidel 54 6.2.6 Přidávání pravidel do databáze 56 6.2.7 Generování gramatiky z pravidel 57 6.3 Návrh vhodné dialogové strategie 58 6.3.1 Opravný dialog 60 6.4 Generování dialogu 60 6.4.1 Ohodnocení výsledného dialogu 61 6.4.2 Návrh ohodnocení výsledného dialogu 62 6.5 Optimalizace dialogových strategií 65 6.5.1 Zvyšování spolehlivosti dialogu 65 6.5.2 Optimalizace délky dialogu 66 6.5.3 Zvyšování přirozenosti dialogu 67 7 Závěr 69 7.1 Shrnutí 69 7.2 Budoucí práce 69 A Struktura a princip činnosti systému DIG 71 B Doplnění systému o další jazyk pro popis grafického rozhraní 74 B.l Vytvoření analyzátoru popisu GUI 74 B.2 Generování stromu komponent 75 B.3 Přidání analyzátoru do systému DIG 75 C Statistika získávání popisů z GUI 77 D Struktura databáze pravidel 79 E Přidávání pravidel do databáze 81 E.l Komunikační protokol 81 E.l.l Formát požadavku pro přidání pravidla do databáze 82

OBSAH E.1.2 Formát požadavku pro získání pravidla z databáze 83 E.1.3 Formát požadavku pro odstranění pravidla z databáze 83 F Návrh aplikace pro zadávání pravidel 85 3

Seznam obrázků 2.1 Schéma dialogového systému 13 5.1 Ukázka stromu s ohodnocením 37 5.2 E-minimální strom odpovídající stromu na obr. 5.1... 37 5.3 E-minimální strom odpovídající stromu na obr. 5.1... 38 5.4 Ukázka Li množiny 39 5.5 Ukázka L r množiny 40 6.1 Jednoduchý formulář 47 A.l Schéma komunikace DIG s okolím 72 A.2 Schéma systému DIG 72 4

Kapitola 1 Úvod V posledních letech dochází ke značnému rozmachu komunikačních a informačních technologií, který je způsoben mimo jiné rychlým rozšiřováním dostupnosti Internetu. Toto rozšiřování s sebou nese jako důsledek zvyšující se množství různých informačních systémů dosažitelných pro běžné uživatele. Zároveň se také začíná klást důraz na vyšší dostupnost těchto informačních zdrojů, které se dosahuje např. přístupem pomocí telefonu, zpřístupněním služeb lidem s různými druhy postižení, pro které je komunikace s počítačem pomocí klasických grafických rozhraní komplikovaná a často téměř nemožná, apod. V těchto případech mohou přispět ke zvýšení přístupnosti aplikací dialogová rozhraní. Jedním ze způsobů, jak dodatečně implementovat dialogové rozhraní do stávající aplikace, je generovat ho z existujícího GUI. Tato oblast, v literatuře označovaná jako transkódování (viz [1]), se začala ve větší míře rozvíjet poté, co byly publikovány standardní formáty pro popis obou typů rozhraní. Pro popis GUI lze použít například (X)HTML (viz [2]) nebo XUL (viz [3]), pro dialogová rozhraní VoiceXML (viz [4]). Důvody uvedené v předcházejících dvou odstavcích, zvýšení přístupnosti aplikací pomocí dialogu a rychlá možnost doplnění dialogového rozhraní použitím transkódování, nás vedly k myšlence navrhnout nové postupy pro transkódování uživatelských rozhraní do dialogové podoby (viz kapitoly 1.2 a 1.3). 5

1. ÚVOD 1.1 Současný stav oblastí souvisejících s transkódováním 1.1.1 Jazyky pro popis dialogových rozhraní Pro popis dialogových rozhraní se z počátku používala různá proprietární řešení a vývojové nástroje jako např. CSLU Toolkit (viz [5]), Danish Dialogue Project: Dialogue Description Language (viz [6]), atd. Jedním z prvních standardů pro popis řečových rozhraní byl jazyk SALT. Tento jazyk je využit například v prohlížeči SpeechMania firmy Philips (viz [7]). Jazyk SALT (viz [8]) je založen na jazyce XML (viz [45]) a rozšiřuje existující značkovací jazyky jako HTML, XHTML (viz [9]) a XML o značky umožňující přidání řečového vstupu a výstupu, ovládání pomocí myši, klávesnice a dotykového displeje. Dalším, v současnosti rozšířeným jazykem pro popis dialogů je VoiceXML. VoiceXML je součástí širší skupiny standardů souhrnně označované W3C Voice Browser Activity (viz [10]). Mezi tyto standardy dále patří Speech Recognition Grammar Specification (SRGS, viz [11]), Speech Synthesis Markup Language (SSML, viz [12]), Pronunciation Lexicon (viz [13]), Semantic Interpretation for Speech Recognition (SISR, [14]) a Call Control XML (CCXML, viz [15]). Jazyky VoiceXML a SRGS jsou stručně popsány v kapitole 3. Standard SSML definuje značkovací jazyk sloužící k popisu řečového výstupu pomocí kombinace zvukových záznamů, syntetizované řeči a hudby. Návrháři dialogového systému umožňuje nastavit různé charakteristiky těchto výstupů (např. jméno, pohlaví a věk u syntetizované řeči). Standard Pronunciation Lexicon slouží k popisu fonetických informací, které lze využít při syntéze a rozpoznávání řeči. Je navržen tak, aby umožnil vývojářům poskytnout dodatečné informace o výslovnosti slov jako jsou zkratky, místní názvy, atd. Standard SISR slouží k získávání sémantiky rozpoznané promluvy. Standard CCXML je určen k ovládání hlasových a telefonních prostředků z VoiceXML. K použití jazyků skupiny Voice Browser Activity v praxi je zapotřebí VoiceXML interpretr. V současné době jsou dostupné například interpretry OptimTalk (viz [17]), Open VXI (viz [18]), VoiceXML for DirectTalk (viz [19]), VoiceGenie VoiceXML Interpreter (viz [20]), Be- 6

1. ÚVOD Vocal Café (viz [21]), atd. Odkazy na některé další VoiceXML interpretry lze získat na adrese viz [10]. Mezi příklady použití jazyků definovaných v rámci Voice Browser Activity patří např. Distributed spoken dialogue system over the mobile network (DSD) (viz [16]). 1.1.2 Dialogová rozhraní Dialogová rozhraní mohou být statická nebo dynamická. Mezi statická rozhraní lze zařadit například informační linky telefonních operátorů, telefonní rozhraní pro správu bankovních účtů, atd. Další oblastí, ve které se využívají statická dialogová rozhraní, jsou navigační systémy automobilů (ATX [22], VICO [23], atd). Dynamická dialogová rozhraní lze využít stejným způsobem jako dynamická GUI, zejména v případech, že dialogové rozhraní má zprostředkovat výsledek dotazu na informační systém. Při jejich generování mohou být použity podobné principy(viz [24]) a podobné prostředky jako v případě grafických rozhraní (CGI viz [39], JSP viz [40], ASP viz [41], PHP viz [42], atd.). Jako příklad dynamicky generovaných dialogových rozhraní lze uvést prototyp na kontextu založené architektury inteligentního domácího prostředí (viz [25]), dialogový server firmy Unisys (viz [26]), který poskytuje nástroj pro tvorbu těchto rozhraní, návrh dialogového rozhraní pro práci s korpusem dialogů (viz [27]), atd. Dalším způsobem generování VoiceXML dokumentů je použití XSL Transformace (viz [43]). Tento způsob je zejména vhodný, pokud jsou jako zdroj pro generovaný dialog použita strukturovaná data, buď uložená v databázi nebo ve formě XML souborů (viz [28]). 1.1.3 Techniky realizace transkódování uživatelských rozhraní Další technikou, kterou lze použít pro generování dialogových rozhraní, je transkódování. Při transkódování dochází k převodu jednoho typu popisu uživatelského rozhraní na jiný. Často se využívají transformace GUI do podob vhodných pro různé druhy zařízení (PDA, mobilní telefony, atd). Dalším častým případem je převod grafického rozhraní do dialogové podoby. Pro popis GUI mohou být 7

1. ÚVOD použity jazyky typu HTML, UIML (viz [36]), XUL, pro popis dialogového rozhraní se většinou používá jazyk VoiceXML. V současné době existuje řada řešení a přístupů k problematice transkódování. Část z nich používá IBM WebSphere Trascoding Publisher (dále jen WTP, viz [29], [30]). Příkladem řešení využívajících WTP je HTML-to-VoiceXML transcoder vytvořený v IBM (viz [31]), který převádí obecné HTML stránky do dialogové podoby. HTML stránky jsou rozděleny na dvě části. První obsahuje vlastní text stránek a druhá odkazy, které se na stránce vyskytují. První část je uživateli přečtena a poté je mu umožněno vybrat si, kterým odkazem chce pokračovat. Jednou z nevýhod řešení je, že z důvodů absence kontextu u seznamu odkazů, používá k popisu cíle odkazu text uzavřený v příslušném elementu a. Obsah elementu a nemusí vždy sám o sobě podat dostatek informací o cíli odkazu. Další nevýhodou je, že rozlišení na text a odkazy musí provádět uživatel manuálně, přidáním značek rozlišujících obě části kódu. Mimo tento přímočarý přístup se při transkódování často používá doplnění transkódovaných stránek o meta-informace popisující sémantiku jednotlivých částí textu (viz [32]). V těchto případech jsou k doplnění informací, které jsou v HTML kódu zmíněny pouze implicitně, použity anotace. Je zde navržen přístup, který umožňuje jejich automatické generování a následnou transformaci stránek doplněných o anotace do dialogové podoby. Pro přidání sémantických informací do popisu GUI lze použít jak proprietární řešení (viz [32]), tak standardní jazyky (viz [33]). Další řešení používají vlastní prostředky pro převod GUI do dialogové podoby. Jedním z nich je řešení navržené v diplomové práci [34], které používá k transkódování denotační sémantiky a logické programování (viz [35]). Transkódování lze také realizovat pomocí XSL transformace (viz [43]). Toto řešení má však svá omezení daná právě použitím jazyka XSLT. Jedním z těchto omezení je, že ho nelze použít na rozhraní popsaná pomocí jazyků, které nejsou odvozeny z XML. Z toho důvodu by mohl vzniknout problém při transkódování uživatelského rozhraní popsaného pomocí HTML. Další nevýhodou je obtížné získání popisů jednotlivých vstupních polí. Tyto nevýhody ale pomíjejí, pokud je vstupním formátem jiný jazyk umožňující popis GUI, jako 8

1. ÚVOD UIML, XUL. U těchto typů dokumentů je přesně definován popis vstupního pole a je součástí příslušného elementu. Kromě přístupů, kdy jsou z HTML kódu přímo generovány dialogy, je možné se setkat i s přístupem, kdy je navrženo dialogové rozhraní, které je generováno z dat získaných jako výsledek uživatelského dotazu (viz např. [37]). S využitím tohoto přístupu se lze setkat také u dotazovacích systémů (viz [38]). 1.2 Cíle práce Všechny práce zmíněné v předchozí kapitole se věnují hlavně převodům obecných stránek do dialogové podoby. Tato práce se zaměřuje na specifickou část problematiky transkódování; na stránky, které slouží jako grafická uživatelská rozhraní (GUI) k různým aplikacím. Jejím cílem je navrhnout postupy, které umožní převod GUI do dialogové podoby, navržení ohodnocení dialogů a optimalizaci výsledných dialogů s přihlédnutím k navrženému ohodnocení. Při hodnocení dialogu a jeho optimalizacích budou brány na zřetel i preference uživatele. Další odlišností oproti většině uvedených prací je možnost využití dialogu se smíšenou iniciativou při komunikaci s uživatelem. 1.3 Poznámky k obsahu práce Práci lze tématicky rozdělit do několika částí, které řeší jednotlivé problémy při generování dialogových rozhraní: Základní pojmy z oblasti dialogových systémů, existující technologie a současná situace v oblasti dialogových systémů - těmto tématům jsou věnovány kapitoly 2, 2.2, 3. Principy transformace GUI do dialogové podoby - tímto problémem se zabývá kapitola 4. Jsou v ní rozebrány kategorizace vstupních komponent GUI (kapitola 4.1), stromová reprezentace GUI (kapitola 4.2) a ohodnocení stromu komponent. Navržené ohodnocení koresponduje s ohodnocením dialogu. 9

1. ÚVOD Generování dialogu s iniciativou systému - část věnovaná problematice generováni dialogů s iniciativou systému (kapitola 5) řeší otázku optimalizace stromu vstupních komponent. Optimalizace stromu komponent má za cíl optimalizaci délky výsledného dialogu (kapitola 5.1). Dále jsou v této části navrženy metody pro získávání popisů jednotlivých vstupních polí (kapitola 5.2) a transformaci jednotlivých typů vstupních komponent GUI (kapitola 5.3). Posledním problémem, který je řešen v kapitole 5.3.2, je optimalizace dialogové strategie pro komponenty umožňující výběr jedné hodnoty z dané množiny. Generování dialogu se smíšenou iniciativou - kapitola 6. Kapitola rozebírá jednotlivé problémy, které se vyskytují při generování dialogu se smíšenou iniciativou (nápověda pro uživatele - kapitola 6.1, analýza uživatelské odpovědi - kapitola 6.2, vhodná dialogová strategie generovaného dialogu - kapitola 6.3 a optimalizace dialogu - kapitola 6.5). 10

Kapitola 2 Dialogová rozhraní Existuje řada důvodů pro vývoj a používání dialogových rozhraní: Komunikace pomocí dialogu je pro většinu uživatelů podstatně přirozenější, než komunikace prostřednictvím GUI a může vést k odbourání zábran, které někteří uživatelé mají při práci s počítačem. Dialogové systémy umožňují nové způsoby přístupu k aplikacím (například pomocí telefonu, náhlavní soupravy,...) - uživatel může komunikovat s počítačem aniž by potřeboval použít ruce, které zůstávají volné pro další činnost. Dialogová rozhraní usnadňují přístup k aplikacím pro zdravotně postižené uživatele, pro které je práce s počítačem prostřednictvím GUI obtížná (zrakově/motoricky postižení). Pomocí dobře vytvořeného dialogového rozhraní lze komunikovat s aplikací rychlostí srovnatelnou s rychlostí komunikace prostřednictvím GUI. 2.1 Základní pojmy Základními pojmy, které se v práci vyskytují, jsou dialog, promluva, obrat, a dialogová strategie. Dialogem budeme rozumět vzájemnou komunikaci dvou účastníků, v našem případě se bude jednat o komunikaci člověk - počítač. Promluva je souvislé sdělení, které učiní jeden účastník dialogu směrem k druhému. Pod pojmem obrat rozumíme promluvu a reakci druhého účastníka. Dialogová strategie určuje pro každou promluvu dialogu následníka. 11

2.2 Dialogová komunikace a její cíl 2. DIALOGOVÁ ROZHRANÍ Funkci přiřazující každému dialogu reálné číslo budeme nazývat hodnotící funkce a značit E(L). Uspořádanou čtveřici M = (Si,S 2, Ei,E 2 ),kde Si, i G {1,2} označuje dialogovou strategii a E i} i G {1,2} hodnotící funkci dialogu i-tého účastníka dialogu, nazveme dialogovou komunikací. Dialog u nazveme z hlediska i-té ho účastníka: příznivější než dialog v, právě když Ei(u) > Ei(v) méně příznivý než dialog v, právě když Ei(u) < Ei(v) ekvivalentní dialogu v, právě když Ei(u) = Ei(v). Hodnotící funkce by měla zohledňovat následující faktory: spokojenost účastníka s výsledkem dialogu délku dialogu přirozenost dialogu (do jaké míry je dialog člověk - počítač podobný dialogu člověk - člověk). Dialogovou komunikaci C = (Si,S 2,Ei,E 2 ) nazveme: kooperativní, právě když E\ = E 2. To znamená, že oba účastníci dialogu mají shodný cíl a snaží se spolupracovat. nekooperativní, právě když E x ^ E 2. V tomto případě se cíle obou účastníků dialogu odlišují. s nulovým součtem, právě když E\ = E 2.V tomto případě jsou cíle účastníků protichůdné. Z pohledu řízení průběhu dialogu lze dialogy rozdělit do následujících tří kategorií: 1. Dialog s iniciativou systému - dialog, jehož průběh je řízen dialogovým systémem. 2. Dialog s iniciativou uživatele - dialog, jehož průběh je řízen uživatelem a systém v převážné míře pouze odpovídá na uživatelské dotazy. 12

2. DIALOGOVÁ ROZHRANÍ 3. Dialog se smíšenou iniciativou - dialog, při kterém dochází ke střídání řídící role uživatele a dialogového systému. 2.3 Dialogový systém Dialogové rozhraní je pro uživatele viditelnou částí dialogového systému, jak je zobrazen na obrázku 2.1. Pod dialogovým rozhraním v tomto obrázku chápeme části, které se přímo podílejí na interakci s uživatelem: rozpoznávání řeči s podporou lingvistických znalostí (v našem případě gramatik pro rozpoznávání promluv) syntetizér řeči. Uživatelst '-ý profil t Ľ )oménov é znalosti \ 1 i 1 \ 1 \ 1 1 ' Rozpoznávání reci -^ Sémantický analyzátor -^ i, i, i i Dialogový manažer Lingvistické znalosti _ Kontext _ dialogu \ 1 Generátor sdělení \ 1 Syntetizér řeči Obrázek 2.1: Schéma dialogového systému 13

2. DIALOGOVÁ ROZHRANÍ Komponenty obsažené ve schématu mají následující úkoly: Rozpoznávání řeči - rozpoznání uživatelské promluvy. Databáze lingvistických znalostí se využívá ke zvýšení úspěšnosti systému pro rozpoznávání řeči a obsahuje např. informace o četnosti výskytů jednotlivých sekvencí slov a další jazykové charakteristiky. Může být využita v okamžiku, kdy je výsledek rozpoznávání nejednoznačný. Sémantický analyzátor - zjištění významu uživatelské promluvy. K tomu účelu modul používá kontext dialogu, doménové znalosti a informace z uživatelského profilu. Dialogový manažer - řízení celého systému. Na základě známých faktů (kontext systému, uživatelský profil, doménové znalosti) rozhoduje o dalším kroku dialogu ze strany systému. Generátor sdělení - generování sdělení podle požadavků dialogového manažeru. Vygenerovaná sdělení jsou předávána řečovému syntetizéru. 14

Kapitola 3 VoiceXML Jedním z prvních návrhů značkovacího jazyka pro popis dialogových strategií byl jazyk VoiceML. Jednalo se o značkovací jazyk odvozený z XML, který sloužil k zápisu dialogových strategií. Dříve než byl tento jazyk přijat a začal se více používat, byl nahrazen jazykem VoiceXML. První specifikace jazyka VoiceXML byla uveřejněna konsorciem firem AT&T, IBM, Lucent Technologies a Motorola v roce 1999 (viz [44]). Od roku 2002 probíhá vývoj VoiceXML s podporou konsorcia W3, které jej zařadilo mezi své standardy a v dnešní době je dostupná specifikace VoiceXML verze 2.1. 3.1 Struktura VoiceXML dokumentu Každý VoiceXML dokument je XML dokumentem (viz [45]), a proto musí začínat standardní XML hlavičkou. Kořenovým elementem VoiceXML dokumentu je element vxml. VoiceXML popisuje, podobně jako VoiceML, dialogovou strategii, která má být použita pro množinu dialogů. Každý VoiceXML dokument se skládá z formulářů (element form) anebo dialogů řešících určitý podcíl daného problému (subdialogů, element subdialog). Cílem dialogu je vyplnění jednotlivých vstupních slotů, tj. požadovaných vstupních hodnot, uživatelem. Tyto vstupní sloty jsou ve VoiceXML popsány pomocí vstupních polí (element field). V současné době ještě stále neexistují dostatečně spolehlivé systémy pro rozpoznávání plynulé řeči. Ve VoiceXML je nespolehlivost částečně eliminována pomocí gramatik specifikujících množinu možných vstupních promluv, které mají být rozpoznány, zanalyzovány a získány z nich potřebné údaje. Množina gramatik, které mohou být 15

3. VOICEXML v dokumentu použity, závisí pouze na použitém VoiceXML interpretru. Podle VoiceXML standardu by každý VoiceXML interpretr měl podporovat následující formáty gramatik: Augmented BNF (viz [11]) XML (viz [11]). Tyto gramatiky jsou definovány spolu s VoiceXML a dalšími jazyky pro práci s dialogem a řečí ve skupině standardů souhrnně nazývané W3C Speech Interface Framework (viz [10]). <?xml version="l.0"?> <vxml xmlns="http://www.w3.org/2001/vxml" version="2.0"> <form> <field name="pozdrav"> <prompt>aho j </prompt> <grammar type="application/x-jsgf"> Ahoj{cesky} Ciao{italsky} Hi{anglicky} </grammar> <noinput> Mohl byste me prosim pozdravit? </noinput> <nomatch> Rozumím angličtine, češtine a italštině </nomatch> </field> <block> <prompt> Uživatel pozdravil <value expr="pozdrav"/> </prompt> </block> </form> </vxml> Příklad 1.: Ukázka VoiceXML dokumentu 16

3. VOICEXML Gramatiky jsou použity ve vstupních polích, kde slouží k omezení množiny rozpoznávaných promluv. Umožňují také přidat k jednotlivým pravidlům sémantickou reprezentaci dané promluvy. Gramatiky jsou do vstupních polí vkládány pomocí elementu grammar. Další často používaný element VoiceXML je element prompt. Element prompt slouží k popisu hlasového výstupu pro uživatele. Ukázkový VoiceXML dokument (viz Příklad 1.) realizuje velmi jednoduchý dialog. Systém nejprve uživatele pozdraví. Uživatel odpoví jednou z možností uvedenou v gramatice (Ahoj, Ciao, Hi). Reakce systému je: Uživatel pozdravil česky \ italsky \ anglicky.", v závislosti na uživatelově odpovědi. Element noinput ohraničuje kód specifikující akce, které se mají provést, pokud v rámci stanoveného časového limitu nebyl detekován žádný vstup. Element nomatch ohraničuje kód, který se má provést v případě, že vstup nebyl rozpoznán (neodpovídal zadané gramatice). Formát použité gramatiky je Java Speech Grammar Format (viz [46]). Text ve složených závorkách představuje sémantickou interpretaci dané promluvy. Tento formát byl standardním formátem gramatik ve VoiceXML verze 1.0. 3.2 Gramatiky používané ve VoiceXML Všechny interpretry jazyka VoiceXML by měly podporovat ABNF a XML formáty gramatiky definované ve standardu Speech Recognition Grammar Specification (viz [11]). V obou případech se jedná o bezkontextové gramatiky obohacené o sémantickou reprezentaci dané promluvy. Protože ABNF i XML formáty jsou dva zápisy jednoho typu gramatiky, je zřejmé, že vyjadřovací schopnosti obou formátů jsou shodné. Proto v následující kapitole bude rozebrána XML varianta gramatiky a následně budou zmíněny odlišnosti ABNF formátu. 3.2.1 XML formát SRGS gramatiky Tento formát gramatiky je postaven na zápisu pravidel v XML formátu. Každý soubor s XML gramatikou musí obsahovat standardní XML hlavičku. 17

3. VOICEXML Kořenovým elementem každé XML SRGS gramatiky je element grammar. Tento element může obsahovat definice jmenného prostoru, XML Schématu (viz [45]) a musí obsahovat specifikaci kořenového neter minálního symbolu dané gramatiky. Dále může tento kořenový element obsahovat atribut mode, který udává, pro jaký vstup je daná gramatika určena. Možné hodnoty jsou voice (vstup ze systému pro rozpoznávání řeči) anebo dtmf (vstup z klávesnice telefonního přístroje pomocí tónové modulace). U kořenového elementu se může také vyskytnout atribut base, který určuje společné URI, k němuž se mají vztahovat relativní odkazy v dané gramatice. Dále je v kořenovém elementu přípustný libovolný atribut definovaný ve standardu XML (viz [45]). Úplný výčet atributů lze najít v [11] a [45]. Popis dalších, nepříliš podstatných elementů, které se mohou vyskytovat za hlavičkou gramatiky, je vynechán. Jejich podrobný výčet se nachází v [11]. Jednotlivá pravidla jsou uzavřena do elementů rule. Tento element musí obsahovat atribut id s unikátní hodnotou pro každé pravidlo dané gramatiky. Pravidlo může být také specifikováno odkazem na jiné pravidlo, které se může vyskytovat buď v daném dokumentu nebo v externím souboru. Odkaz na pravidlo se zadá pomocí elementu ruleref, který musí obsahovat atribut uri. Tento atribut určuje URI (viz [2]), kde se nachází definice daného pravidla. Pokud obsahuje dané pravidlo gramatiky varianty, je seznam variant uzavřen do elementu one-of. Jednotlivé varianty jsou ohraničeny elementem item. Vkládání sémantických informací do SRGS gramatik se děje pomocí atributu tag. Přesné použití tohoto atributu je specifikováno v [14]. Příklad 2. ukazuje, jak by vypadal XML formát SRGS gramatiky v příkladu dialogu z kapitoly věnované VoiceXML. 3.2.2 Augmented BNF formát SRGS gramatiky Oproti XML formátu SRGS gramatiky není ABNF formát (viz [11]) založen na XML. Formát hlavičky ABNF gramatiky je jiný, i když položky zůstávají stejné jako v případě XML formátu. Jejich zápis je ve tvaru dvojice atribut hodnota;", za níž následuje středník. Názvy 18

3. VOICEXML <grammar root="pozdrav"> <rule id="pozdrav"> <one-of> <item tag="česky">ahoj</item> <item tag="italsky">ciao</item> <item tag="anglicky">hi</item> </one-of> </rule> </grammar> Příklad 2.: Ukázka XML formátu SRGS gramatiky atributů jsou stejné jako u XML formátu. Zápis pravidel je v ABNF formátu oproti XML formátu poněkud jednodušší. Formát zápisu je následující: $jméno-pravidla = pravidlo Znakem $ jsou označeny neterminální symboly, terminálni symboly mohou začínat libovolným znakem. Pokud však obsahují některý speciální symbol, musí být uzavřeny do uvozovek. Protože se jedná o jazyk pro zápis bezkontextových gramatik, musí být na levé straně pravidla neterminální symbol a na pravé straně posloupnost terminálních a neterminálních symbolů. <grammar> public $pozdrav=ahoj:"česky" Ciao:"italsky" Hi:"anglicky" </grammar> Příklad 3.: Ukázka ABNF formátu SRGS gramatiky pro Příklad 1. 19

3. VOICEXML Pokud se některý symbol opakuje, je počet opakování uzavřen do symbolů '<' a '>'. Sémantika tohoto zápisu je následující: < n > opakování právě n-krát < m n > opakování m až n-krát < m > opakování alespoň m-krát. Sémantická reprezentace se od pravidla odděluje pomocí symbolu ':'. 20

Kapitola 4 Převod grafických rozhraní na dialogová Z hlediska použití můžeme grafická rozhraní rozdělit na: 1. informativní 2. interaktivní. Cílem informativního rozhraní je sdělení potřebné informace uživateli. Naproti tomu cílem interaktivního rozhraní je umožnit uživateli aktivní komunikaci s aplikací, která toto rozhraní používá. Práce bude věnována právě interaktivním rozhraním a jejich převodu do dialogové podoby. Při převodu grafického rozhraní na dialogové je důležité vygenerovat takové dialogové rozhraní, aby byl zajištěn korektní vstup požadovaných hodnot od uživatele. K tomu, aby uživatel mohl korektně zadat požadované vstupy musí znát: 1. Účel, ke kterému dané rozhraní slouží. 2. Požadované hodnoty. Převod grafického rozhraní na dialogové lze realizovat jako transformaci vstupních polí grafického rozhraní, která slouží pro zadání hodnot uživatelem, do dialogové podoby. Popis požadované hodnoty se většinou nachází v blízkosti odpovídajícího vstupního pole. S automatickým převodem GUI do dialogové podoby úzce souvisí následující problémy: Získání popisů vstupních polí, na jejichž hodnoty se má systém uživatele dotázat. 21

4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ Analýza odpovědi uživatele a získání všech relevantních dat, která uživatel systému ve své odpovědi sdělil. Návrh robustních univerzálních dialogových strategií, které se budou snažit o maximální uživatelskou přívětivost. «... Pro konverzi grafických rozhraní na dialog je zapotřebí provést analýzu možných vstupních komponent GUI a jejich kategorizaci. Poté je možné transformovat vstupní dokument na strom objektů podobným způsobem, jaký je použit při analýze značkovacích jazyků založených na XML (viz [47]). Ze stromového modelu je následně vytvořena simulace mentálního modelu GUI (viz [48]). Získaný mentální model lze poté převést do podoby dialogu, jak bude ukázáno dále. 4.1 Kategorizace vstupních komponent Pro potřeby dialogových rozhraní není důležitá vizuální podoba dané komponenty, ale popisovaná množina vstupů. Z tohoto hlediska je možné veškeré vstupní komponenty GUI rozdělit do následujících kategorií: 1. Vstup libovolného textu - např. textové pole, vstup hesla, atd. Tato kategorie bude realizována dotazem na příslušnou hodnotu vstupního pole s tím, že vstupní hodnota nebude gramatikou omezena (viz kapitola 5.3.1). Proto bude v současnosti vstup těchto hodnot realizován pomocí klávesnice (resp. DTMF). 2. Vstup jediné hodnoty z dané množiny - např. radiobutton, menu, atd. Oproti předcházející kategorii zde bude gramatikou omezena množina vstupních hodnot (viz kapitola 5.3.2). 3. Vstup více hodnot z dané množiny - např. checkbox, vícepoložkové menu, atd., které je možno realizovat buď pomocí subdialogů anebo gramatiky (viz kapitola 5.3.3). 22

4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ I další komponenty GUI lze zařadit do některé z těchto kategorií. Jako příklad je možné uvést potvrzení nebo zrušení zadaných hodnot, které lze realizovat jako vstup jediné hodnoty z dané množiny. Příslušná množina bude obsahovat popisy těchto komponent. Tlačítka mohou být chápána jako vstup jedné z hodnot ano/ne s tím, že dotaz bude např.: Přejete si stisknout tlačítko XI". Teoreticky bylo by možné ponechat buď pouze kategorii vstup libovolného textu nebo kategorie vstup jedné hodnoty z a vstup více hodnot. Pokud by byla ponechána pouze kategorie vstup libovolného textu, výsledkem by byla nižší efektivita vygenerovaného dialogu (nutnost zpracování vstupu na úrovni VoiceXML kódu místo zpracování vstupu rozpoznávačem řeči) a nemožnost hlasové komunikace. Kategorii vstup libovolného textu není vhodné odstranit z následujících důvodů: 1. Extrémní nárůst velikosti gramatik pro vstupy, které původně patřily do této kategorie. Uvedený nárůst by mohl nastat například tehdy, pokud by uživatel zadával atribut, který by mohl nabývat značného množství hodnot (např. název knihy, jméno autora,...). 2. Nemožnost vytvoření gramatiky pro rozpoznávání promluv v případě, že systém neumožňuje získat všechny možné hodnoty některého atributu. 3. Nemusí být zřejmé, zda má být místo vstupu libovolného textu použit vstup jedné hodnoty resp. vstup množiny hodnot. Mohou nastat situace, kdy lze použít obě kategorie komponent. Která kategorie se má použít, vyplyne až v průběhu dialogu. 4.2 Stromová reprezentace grafického rozhraní Při stromové reprezentaci GUI vycházíme z jeho DOM reprezentace, která je modifikována tak, aby bylo dosaženo co nejoptimálnějšího stromu z pohledu dialogové strategie. Již na této úrovni lze definovat kritérium, které odpovídá hodnotící funkci dialogové strategie. Konstrukce hodnotícího kritéria je popsána v kapitole 4.4. Navržené kritérium optimality je použito pro optimalizaci stromu komponent 23