Prohlášení Prohlašuji, že tato disertační práce práce je mým původním autor ským dílem, které jsem vypracoval samostatně. Všechny zdroje, pra meny 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. Ne malou pomoc mi také poskytli lidé, kteří mi pomohli s korekturami textu.
m
Obsah 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í 1.1.2 Dialogová rozhraní 1.1.3 Techniky realizace transkódování uživatelských rozhraní 1.2 Cíle práce 1.3 Poznámky k obsahu práce 2 Dialogová rozhraní 2.1 Základní pojmy 2.2 Dialogová komunikace a její cíl 2.3 Dialogový systém 3 VoiceXML 3.1 Struktura VoiceXML dokumentu 3.2 Gramatiky používané ve VoiceXML 3.2.1 XML formát SRGS gramatiky 3.2.2 Augmented BNF formát SRGS gramatiky . . . . 4 Převod grafických rozhraní na dialogová 4.1 Kategorizace vstupních komponent 4.2 Stromová reprezentace grafického rozhraní 4.3 Mentální model GUI 4.4 Hodnotící kritérium stromu komponent GUI 4.4.1 Požadavky na hodnotící funkci 4.4.2 Návrh hodnotícího kritéria 5 Generování dialogů s iniciativou systému 5.1 Optimalizace stromu vstupních komponent 5.2 Získávání popisů vstupních polí 5.3 Transformace vstupních komponent 5.3.1 Libovolný text 5.3.2 Vstup jedné hodnoty z dané množiny 1
5.3.3 Vstup více hodnot Generování dialogů se smíšenou iniciativou 6.1 Nápověda pro uživatele 6.1.1 Identifikace požadovaných údajů 6.1.2 Generování nápovědy 6.2 Analýza uživatelské odpovědi 6.2.1 Kritérium podobnosti informačních systémů a jejich GUI 6.2.2 Rozšiřování množiny pravidel 6.2.3 Návrh struktury databáze pravidel 6.2.4 Generování pravidel z uživatelských odpovědí 6.2.5 Ekvivalence pravidel 6.2.6 Přidávání pravidel do databáze 6.2.7 Generování gramatiky z pravidel 6.3 Návrh vhodné dialogové strategie 6.3.1 Opravný dialog 6.4 Generování dialogu 6.4.1 Ohodnocení výsledného dialogu 6.4.2 Návrh ohodnocení výsledného dialogu 6.5 Optimalizace dialogových strategií 6.5.1 Zvyšování spolehlivosti dialogu 6.5.2 Optimalizace délky dialogu 6.5.3 Zvyšování přirozenosti dialogu Závěr 7.1 Shrnutí 7.2 Budoucí práce Struktura a princip činnosti systému DIG Doplnění systému o další jazyk pro popis grafického roz hraní B.l Vytvoření analyzátoru popisu GUI B.2 Generování stromu komponent B.3 Přidání analyzátoru do systému DIG Statistika získávání popisů z GUI Struktura databáze pravidel Přidávání pravidel do databáze E.l Komunikační protokol E.l.l Formát požadavku pro přidání pravidla do da tabáze
Formát požadavku pro získání pravidla z da tabáze E.1.3 Formát požadavku pro odstranění pravidla z da tabáze F Návrh aplikace pro zadávání pravidel
83 83 85
3
Seznam obrázků 2.1
Schéma dialogového systému
13
5.1 5.2 5.3 5.4 5.5
Ukázka stromu s ohodnocením E-minimální strom odpovídající stromu na obr. 5.1 . . . E-minimální strom odpovídající stromu na obr. 5.1 . . . Ukázka Li množiny Ukázka Lr množiny
37 37 38 39 40
6.1
Jednoduchý formulář
47
A.l Schéma komunikace DIG s okolím A.2 Schéma systému DIG
4
72 72
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í kla sický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 apli kací dialogová rozhraní. Jedním ze způsobů, jak dodatečně implementovat dialogové roz hraní 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í for má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í dia logové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 stan dardy dále patří Speech Recognition Grammar Specification (SRGS, viz [11]), Speech Synthesis Markup Language (SSML, viz [12]), Pro nunciation Lexicon (viz [13]), Semantic Interpretation for Speech Re cognition (SISR, [14]) a Call Control XML (CCXML, viz [15]). Jazyky VoiceXML a SRGS jsou stručně popsány v kapitole 3. Stan dard 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 syn tetizované ř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 pro středků z VoiceXML. K použití jazyků skupiny Voice Browser Activity v praxi je zapo tř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]), Be6
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 sta tická rozhraní lze zařadit například informační linky telefonních ope rátorů, telefonní rozhraní pro správu bankovních účtů, atd. Další ob lastí, 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 ge nerová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 do mácího prostředí (viz [25]), dialogový server firmy Unisys (viz [26]), který poskytuje nástroj pro tvorbu těchto rozhraní, návrh dialogo vé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 roz hraní, je transkódování. Při transkódování dochází k převodu jed noho 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 gra fické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 dialo gové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 Pu blisher (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 vy brat 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 im plicitně, použity anotace. Je zde navržen přístup, který umožňuje jejich automatické generování a následnou transformaci stránek do plně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 dia logové 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ís ká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 di alogy, 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živatel ské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ře vodům obecných stránek do dialogové podoby. Tato práce se za měřuje na specifickou část problematiky transkódování; na stránky, které slouží jako grafická uživatelská rozhraní (GUI) k různým apli kací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í tech nologie 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 pro blémem se zabývá kapitola 4. Jsou v ní rozebrány kategorizace vstupních komponent GUI (kapitola 4.1), stromová reprezen tace 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á pro blematice generováni dialogů s iniciativou systému (kapitola 5) řeší otázku optimalizace stromu vstupních komponent. Opti malizace 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í (kapi tola 5.2) a transformaci jednotlivých typů vstupních komponent GUI (kapitola 5.3). Posledním problémem, který je řešen v kapi tole 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. Kapi tola rozebírá jednotlivé problémy, které se vyskytují při gene rování dialogu se smíšenou iniciativou (nápověda pro uživa tele - 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 apli kací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 zdra votně postižené uživatele, pro které je práce s počítačem pro střednictvím GUI obtížná (zrakově/motoricky postižení). • Pomocí dobře vytvořeného dialogového rozhraní lze komuni kovat 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 účast ní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. DIALOGOVÁ ROZHRANÍ
2.2 Dialogová komunikace a její cíl 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,S2, Ei,E2),kde Si, i G {1,2} ozna čuje dialogovou strategii a Ei}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,S2,Ei,E2)
nazveme:
• kooperativní, právě když E\ = E2. To znamená, že oba účast níci dialogu mají shodný cíl a snaží se spolupracovat. • nekooperativní, právě když Ex ^ E2. V tomto případě se cíle obou účastníků dialogu odlišují. • s nulovým součtem, právě když E\ = —E2.V tomto případě jsou cíle účastníků protichůdné. Z pohledu řízení průběhu dialogu lze dialogy rozdělit do násle dují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ži vatelské 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 sys té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
Ľ)oménov é
znalosti
t
\1
Rozpoznávání reci i,
i
-^
1
\
1
Sémantický analyzátor i,
\1 1' -^
Dialogový manažer ii
\1
Lingvistické znalosti
_
Kontext _ dialogu
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. Data bá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 čet nosti výskytů jednotlivých sekvencí slov a další jazykové cha rakteristiky. 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é promlu vy. 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ů dia logové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 doku ment 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ža dovaný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é sys té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. V O I C E X M L
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]). Příklad 1.: Ukázka VoiceXML dokumentu
16
3. V O I C E X M L
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 jednot livým pravidlům sémantickou reprezentaci dané promluvy. Grama tiky jsou do vstupních polí vkládány pomocí elementu grammar. Další často používaný element VoiceXML je element prompt. Ele ment 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 od poví jednou z možností uvedenou v gramatice (Ahoj, Ciao, Hi). Re akce 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 ohra nič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 interpre taci dané promluvy. Tento formát byl standardním formátem grama tik 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 Recogni tion 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 jed noho typu gramatiky, je zřejmé, že vyjadřovací schopnosti obou for má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 for mátu. 3.2.1 XML formát SRGS gramatiky Tento formát gramatiky je postaven na zápisu pravidel v XML for mátu. Každý soubor s XML gramatikou musí obsahovat standardní XML hlavičku. 17
3. V O I C E X M L
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řeno vé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 vy skytovat 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 va riant 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 po mocí 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. V O I C E X M L
Ahoj C i a o < / i t e m > Hi 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 sym boly 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ů. public $pozdrav=Ahoj:"česky"| Ciao:"italsky"| Hi:"anglicky"
Příklad 3.: Ukázka ABNF formátu SRGS gramatiky pro Příklad 1.
19
3. V O I C E X M L
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í sym bolu ':'.
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ži vateli. Naproti tomu cílem interaktivního rozhraní je umožnit uživa teli 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é vyge nerovat 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 trans formaci vstupních polí grafického rozhraní, která slouží pro zadání hodnot uživatelem, do dialogové podoby. Popis požadované hod noty 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 sou visí 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ů po dobný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ý men tá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 hle diska je možné veškeré vstupní komponenty GUI rozdělit do násle dujících kategorií: 1. Vstup libovolného textu - např. textové pole, vstup hesla, atd. Tato kategorie bude realizována dotazem na příslušnou hod notu vstupního pole s tím, že vstupní hodnota nebude gra matikou omezena (viz kapitola 5.3.1). Proto bude v součas nosti 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 hod not, 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 libovol ného textu, výsledkem by byla nižší efektivita vygenerovaného di alogu (nutnost zpracování vstupu na úrovni VoiceXML kódu místo zpracování vstupu rozpoznávačem řeči) a nemožnost hlasové ko munikace. 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é hod noty 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. Mo hou 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 defino vat 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
4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ
a je součástí hodnotící funkce dialogové strategie, která je popsána v kapitole 6.4.2. Vlastní reprezentace grafického rozhraní je založena na ohodno ceném stromu, jehož kořenem je daný dokument. Na druhé úrovni jsou jednotlivé vstupní formuláře a na dalších úrovních vstupní kom ponenty. Každé komponentě je přiřazena váha, která udává, do jaké míry daná vstupní komponenta a její hodnota omezují prohledávaný stavový prostor. Tímto přístupem je optimalizován dialog vzhledem k počtu zadaných údajů, což vede ke zkrácení výsledného dialogu a tím i vyššímu ohodnocení výsledného dialogu (viz 6.4.2). Jednotlivé úrovně výsledného stromu jsou dány právě DOM re prezentací daného grafického rozhraní. Některé textové uzly, které nesouvisí se zadáváním vstupních údajů, jsou buď odstraněny nebo přesunuty na vhodnější umístění ve stromě. Která z těchto dvou ope rací se provede, závisí na tom, o jaký uzel se jedná. Těmito uzly jsou například odkazy na jiné stránky, které budou spojeny do zvláštního uzlu. Dotaz na případný přechod na jinou stránku bude realizován vždy až ke konci dialogu. Proto bude tento uzel, při procházení do hloubky, umístěn ke konci odpovídajícího stromu (uzly na konci nej pravější cesty tímto stromem). Texty, které slouží jako popisy vstupních komponent, budou při dány jako atributy uzlů, které reprezentují dané vstupní komponenty. Texty, jejichž cílem je popis účelu daného dokumentu, budou při dány jako jeden z prvních uzlů a budou z nich pouze odstraněny meta-informace, které slouží k popisu grafického designu rozhraní. Tyto meta-informace budou odstraňovány obecně, neboťjsou pro účely dialogového rozhraní zbytečné. Zde budou jedinou výjimkou tabulky, které obsahují vstupní komponenty a budou použity k zís kání relevantních popisů daných vstupních komponent. V tomto pří padě tabulky slouží pro přehledné umístění jednotlivých vstupů a jejich popisů na stránce. Detailní postup při získávání alternativních popisuje popsán v ka pitole 5.2.
24
4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ
4.3 Mentální model GUI Transformaci GUI do dialogové podoby lze popsat pomocí kroků: 1. Vytvoření mentálního modelu GUI (viz [48]) z DOM reprezen tace, jak si jej pravděpodobně vytvoří uživatel. 2. Vygenerování dialogového rozhraní z vytvořeného mentálního modelu. Lze předpokládat, že mentální modely grafického a dialogového uživatelského rozhraní jedné aplikace se budou lišit způsobem ukon čení zadávání vstupních hodnot. Zbývající část mentálního modelu, tj. jaké hodnoty je nutno zadat k získání požadovaných údajů, zů stává stejná. Z těchto důvodů obsahuje mentální model, který si vytvoří uživa tel při práci s GUI, následující informace, které budou reprezentovány pomocí formulí predikátové logiky: 1. popisy jednotlivých vstupních polí 2. přípustné hodnoty vstupních polí 3. akce, která se má provést v okamžiku zadání vstupních hodnot. Dále je nutné u každé vstupní komponenty uchovat informace o jejím typu. Tento atribut bude nabývat jedné z hodnot text, single, multi (viz kapitola 5.3). Vstup I bude reprezentován uspořádanou trojicí I=(Popis kompo nenty, Typ komponenty, Přípustné hodnoty). Uživatelské rozhraní UI je definováno jako sjednocení jeho vstup ních komponent. Prakticky je mentální model uživatelského rozhraní realizován přidáním atributu jednotlivým vstupním polím uvnitř DOM stromu. Atributy obsahují hodnotu trojice I. Transkódování lze popsat pomocí diskrétní funkce s parametry UI a použitá dialogová strategie. Postupy pro zjištění hodnoty této funkce jsou popsány v kapitolách 5.3, pokud je zvolena dialogová strategie s iniciativou systému a v kapitole 6 v případě dialogové strategie se smíšenou iniciativou. 25
4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ
4.4 Hodnotící kritérium stromu komponent GUI Zde navržené kritérium slouží k přeuspořádání stromu vstupních komponent tak, aby bylo dosaženo co nejlepšího ohodnocení výsled ného dialogu. Použité ohodnocení je popsáno v kapitole 6.4.2. 4.4.1 Požadavky na hodnotící funkci Navržená hodnotící funkce by měla splňovat tyto základní poža davky: 1. Měla by popisovat, do jaké míry daná kategorie vstupních kom ponent redukuje velikost prostoru dalšího možného pokračo vání dialogu. 2. Měla by být snadno transformovatelná na hodnotící funkci dia logu, jak byla definována v kapitole 2.2 a je popsána v kapitole 6.4.2. Z předchozích dvou bodů vyplývá, že výsledná funkce by měla zohledňovat: • Velikost množiny možných uživatelských odpovědí může mít vliv na výslednou délku dialogu. Přímo ovlivňuje velikost gra matik a tím spolehlivost rozpoznávání promluv a nutnost pou žití opravných dialogů. • Spokojenost účastníka s výsledkem dialogu je ovlivněna zejmé na tím, zda se podařilo dosáhnout požadovaného cíle, a jak dlouhý dialog k tomu byl zapotřebí. Spokojenost uživatele s vý sledkem dialogu lze ovlivnit pouze nepřímo tím, že budeme po stupovat od vstupů, které zajišťují vyšší spolehlivost systémů pro rozpoznávání řeči, ke vstupům, u nichž lze předpokládat nižší spolehlivost. Délku dialogu lze většinou pouze odhad nout. V případě dialogové strategie se smíšenou iniciativou ji lze také ovlivnit kvalitou množiny pravidel pro rozpoznávání promluvy. • Přirozenost vlastního dialogu - tento faktor lze zohlednit až ve fázi generování výsledného dialogu (viz kapitola 5). 26
4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ
Rozdílné preference uživatelů lze řešit například přidáním uži vatelských profilů spojených s identifikací uživatele pomocí hlasu. Profily by popisovaly např. o jak zkušeného uživatele se jedná, jaká je jeho preferovaná dialogová strategie, atd. Po mocí uživatelských profilů by bylo možné zvýšit uživatelskou přívětivost a tím i hodnocení daného dialogu. Tento přístup zůstává jako námět na další studium a výzkum. 4.4.2 Návrh hodnotícího kritéria Při návrhu hodnotícího kritéria budeme vycházet z požadavků, které byly popsány v kapitole 4.4.1. Prvním požadavkem je redukce prostoru možných uživatelských odpovědí. Tento požadavek lze zohlednit pomocí vhodného ohod nocení jednotlivých vstupních komponent v závislosti na velikosti množiny přípustných odpovědí. Proto nejlepší hodnocení bude mít vstup libovolného textu a nejhorší vstup jedné hodnoty z dané mno žiny. Dalším požadavkem, zmíněným v předcházející kapitole, byla snadná transformace na hodnotící funkci. Splnění tohoto bodu je snadné, protože redukce počtu možných uživatelských odpovědí ovlivňuje délku dialogu a nutnost použití opravných dialogů v případě vstupu nekorektních hodnot. Délka dialogu také ovlivňuje spokojenost s vlastním dialogem. Předpokládejme, že všechny prvky vstupního formuláře jsou uspořádány do matice podle svého grafického umístění ve formuláři. Pokud na daném místě ve formuláři není ani vstupní komponenta ani text, bude příslušné pole matice obsahovat prázdnou hodnotu (null). Tuto matici označíme jako Inp, jednotlivé prvky matice budou označeny Inpij. Proměnná EText obsahuje počet ohodnocených textových vstupů, proměnná TText obsahuje celkový počet textových vstupů. Podobně proměnné TMulti a EMulti obsahují celkový počet komponent pro vstup více hodnot resp. počet zpracovaných komponent pro vstup více hodnot. Funkce card vrací mohutnost dané množiny, Dom obsa huje množinu možných hodnot dané vstupní komponenty.
27
4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ
Dále označme jednotlivé třídy vstupních komponent: • Single - vstup jedné hodnoty z dané množiny. • S Single - vstup jedné hodnoty z dané množiny textových ře tězců. Je zjevné, že platí SSingle C Single, a tudíž se jedná pouze o rozšíření kategorizace popsané v kapitole 4.1. Toto roz šíření bylo provedeno z důvodu jednoduššího zápisu hodnotící funkce. • Multi - vstup více hodnot z dané množiny. • Text - vstup textu. Z předchozího obsahu kapitoly vyplývá hodnotící funkce: ' EText + 0,5
Inpij E SSingle A (1) (Inpi-ij E TextM Inpij-i E Text) Inpij E Text (2)
EText E(Inpij) TText -EMulti
i card(Dom(Inpi
j))
TText + T Multi + C Single
Inpij E Multi
(3)
Inpij E Single
(4)
Vztah (1) říká, že pokud je bezprostředním předchůdcem kompo nenty a z kategorie Text komponenta b patřící do kategorie Single, je vhodné zachovat původní pořadí komponent. Komponenta b bude totiž s největší pravděpodobností sloužit jako popis komponenty a. Vztah (2) udává, že komponenty kategorie Text jsou ve většině případů nejdůležitější vstupní komponentou z celého GUI. Ostatní komponenty většinou pouze upřesňují její význam. Proto budou mít, až na výjimku ošetřenou vztahem (1), nejlepší ohodnocení. Vztahy (3) a (4) hodnotí opět vstupní komponenty podle toho, jak omezují prohledávaný stavový prostor. Komponenty kategorie Single jej rozdělují na poloviny, zatímco komponenty v kategorii Multi jej dělí na n dílů. Na základě ohodnocení jednotlivých komponent pomocí funkce E dojde k přeorganizování stromu vstupních komponent tak, aby 28
4. PŘEVOD GRAFICKÝCH ROZHRANÍ NA DIALOGOVÁ
umístění jednotlivých komponent ve formulářích odpovídalo jejich ohodnocení. Tento strom bude poté přetransformován na dialog za použití postupu popsaného v kapitole 5.3.
29
Kapitola 5
Generování dialogů s iniciativou systému Při generovaní dialogů s iniciativou systému dochází k řadě pro blémů, které je třeba vyřešit: 1. Uspořádat uzly DOM reprezentace popisu grafického rozhraní tak, aby výsledný strom odpovídal ohodnocení jednotlivých uzlů. Pro ohodnocení jednotlivých uzlů je použito kritérium, popsané v kapitole 4.4. Reorganizaci stromu je věnována kapi tola 5.1. 2. Nalézt ve zdrojovém dokumentu ke každému vstupu vhodný popis, který uživateli dostatečně ozřejmí, jaká hodnota je po něm požadována (viz kapitola 5.2). Z nalezených popisů vy tvořit mentální model GUI (viz kapitola 4.3). 3. Nalézt rozumnou transformaci jednotlivých vstupních kompo nent do dialogové podoby, aby se co nejvíce minimalizovalo množství informací předávaných uživateli, které jsou nutné k zadání potřebných dat (viz kapitola 5.3). 4. Navrhnout datovou strukturu, která bude umožňovat uchová vání přehledu o zadaných vstupních polích. 5. Optimalizovat generované dialogy pro komponenty umožňu jící vstup jedné hodnoty z dané množiny (viz kapitola 5.3.2). Reorganizace uzlů stromu a transformace jednotlivých vstupních komponent jsou specifické problémy pro generování dialogů s inici ativou systému. Druhý problém, nalezení popisů vstupních polí, se v mírně pozměněné podobě vyskytuje i při generování dialogů se smíšenou iniciativou. 30
5. G E N E R O V Á N Í D I A L O G Ů S I N I C I A T I V O U S Y S T É M U
Vlastní transformace GUI na dialogový systém je realizována v následujících krocích: 1. Analýza GUI a transformace na strom vstupních komponent. 2. Nalezení popisů pro vstupní komponenty a vytvoření mentál ního modelu. 3. Optimalizace získaného stromu. 4. Transformace stromu do dialogové podoby a optimalizace subdialogů pro některé kategorie komponent. Po pretransformovaní GUI na dialogové rozhraní je takto získaný VoiceXML dokument dále zpracován způsobem popsaným v pří loze A.
5.1 Optimalizace stromu vstupních komponent Kritériem pro optimalizaci stromu komponent je ohodnocení kom ponent (viz kapitola 4.4.2). Při optimalizaci není možné přesouvat jednotlivé komponenty mezi vstupními formuláři, kterých může být v GUI více. Proto lze optimalizaci stromu vstupních komponent řešit napří klad: 1. Kontrolou a případnou reorganizací stromu pomocí výměn jed notlivých uzlů. 2. Vytvořením nového stromu, který odpovídá ohodnocení kom ponent. Vzhledem k tomu, že při použití postupu naznačeného v bodě 1. by mohly být ztraceny informace o původním dokumentu, bude použit postup naznačený v bodu 2. Při použití postupu z bodu 1. by se mohly některé komponenty například dostat do úplně jiného formuláře, než byly původně umístěny. Při reorganizaci stromu lze použít pouze kroky, které nenaruší logickou strukturu dokumentu. Bez ztráty informace o logické struk tuře dokumentu je možné provádět záměnu jednotlivých potomků 31
5. G E N E R O V Á N Í D I A L O G Ů S I N I C I A T I V O U S Y S T É M U
daného uzlu, kteří jsou na stejné úrovni v závislosti na jejich ohod nocení. Reorganizaci stromu lze realizovat algoritmem: 1. u =kořen 2. Uspořádej potomky uzlu u zleva doprava podle jejich ohodno cení. 3. Realizuj uvedený postup rekurzivně postupně pro všechny po tomky uzlu u.
5.2 Získávání popisů vstupních polí Pro získávání popisů vstupních polí je důležitá vizuální stránka gra fického rozhraní a rozmístění informací. Popis vstupní komponenty se nachází na obrazovce vždy v blízkosti příslušné komponenty. Ne vždy tímto popisem musí být jenom text. Může jim být například hodnota další komponenty, která ji předchází nebo následuje, nebo popis v grafické podobě. V případě grafického popisu by automa tický převod mohl být nemožný, pokud by nebyl doplněn textovým popisem anebo by selhaly metody rozpoznání písma (OCR, viz např. [49]). Tento případ zde nebude diskutován, ale lze ho převést na úroveň textových popisů přidáním modulu realizujícího OCR před algoritmus diskutovaný dále v kapitole. Postup, jakým lze přidat modul pro předzpracování vstupního formuláře, je popsán v příloze B. Získání popisů pro jednotlivé vstupní komponenty lze realizovat následujícími způsoby: 1. Sémantickou analýzou popisu GUI. 2. Heuristickým algoritmem vycházejícím ze zvyklostí používa ných při vytváření GUI. U grafických rozhraní je důležitým faktorem ovlivňujícím jeho vnímání uživatelem rozmístění jednotlivých prvků v rámci formu láře. Jejich umístění může ovlivnit pořadí, v jakém uživatel tyto prvky zpracovává. Z tohoto důvodu se nejeví jako vhodné použití metod sémantické analýzy určených pro analýzu textu. 32
5. G E N E R O V Á N Í D I A L O G Ů S I N I C I A T I V O U S Y S T É M U
Princip navrženého a použitého heuristického algoritmu je násle dující: 1. Pokud je popis součástí vstupní komponenty, např. atribut alt u elementu input, anebo je jednoznačně komponentě přiřazen, např. pomocí elementu label (v případě, že je GUI popsáno po mocí HTML), použijeme tento popis. 2. Pokud jsou jednotlivé vstupní komponenty umístěny do ta bulky, pokusíme se najít text, respektive textovou komponentu, v buňce předcházející danou buňku v daném řádku. Pokud se zde text respektive textová komponenta nenachází, hledáme v předchozím řádku v daném sloupci. Pokud je zde nalezen text, použijeme ho jako popis. 3. Pokud kroky 1. a 2. nevedly k výsledku, pokus se najít název vstupního pole ve větách, které předcházejí vstupní kompo nentu. V případě, že se podaří větu nalézt, použijeme ji jako popis. 4. Pokud byly předchozí kroky algoritmu neúspěšné a mezi před cházející a zpracovávanou vstupní komponentou je text, re spektive textová komponenta, použijeme jako popis tento text, případně hodnotu dané textové komponenty. 5. Pokud všechny předcházející kroky selhaly, použijeme jako po pis název komponenty. Je zřejmé, že tento algoritmus vede ve většině případů k poža dovanému cíli, tj. získání popisu vstupní komponenty. Algoritmus selže pouze v případě, že jméno komponenty rozumně nekorespon duje s jejím účelem. Během pokusů na různých GUI, realizovaných pomocí HTML, se tímto algoritmem podařilo dosáhnout úspěšnosti mezi 71 a 100 pro centy. Výsledky a popis daného experimentu jsou podrobně uvedeny v příloze C.
33
5. G E N E R O V Á N Í D I A L O G Ů S I N I C I A T I V O U S Y S T É M U
5.3 Transformace vstupních komponent V této kapitole jsou rozebrány možné způsoby transformace jed notlivých kategorií vstupních komponent uvedených v kapitole 4.1. Výsledky transformace prezentují fragmenty VoiceXML kódu, který bude využívat XML formát SRGS gramatik. 5.3.1 Libovolný text Mezi vstupní komponenty typu libovolný text patří například tex tový vstup, textové pole anebo vstup hesla. Jejich hodnotou může být libovolný řetězec, který lze gramatikou omezit pouze za před pokladu, že známe všechny možné hodnoty daného vstupního pole. To je však většinou prakticky těžko realizovatelné. Jediné vstupní komponenty, které lze tímto způsobem omezit, jsou komponenty sloužící k zadávání hodnot klíčů pro prohledávání databází. Tyto vstupy by bylo možné omezit pouze na množinu přípustných klíčů, ale výsledná gramatika by byla ve většině případů velmi rozsáhlá a její zpracování by mohlo být časově náročné. Z tohoto důvodu je vhodné, aby se množina možných vstupů neomezovala. Ukázkový dokument zobrazující popsanou transformaci je uve den v příkladu 4. Proměnná application.lastresult$.utterance obsahuje poslední roz poznaný vstup, který je nutno dále zpracovat, a z kterého musí být získány hodnoty hledaných klíčů. Gramatika, která je povinnou sou částí elementu/ieZíí, by měla být co nejobecnější. V uvedeném příkladu je použito pravidlo pro neterminální symbol Garbage, který znamená, že se má část vstupu odpovídající tomuto neterminálnímu symbolu ignorovat. Vzhledem k tomu, že současné systémy pro rozpoznávání řeči potřebují mít specifikovaný vstup pomocí gramatiky, nelze uve dené pravidlo použít pro hlasový vstup. Může však být použito pro vstup pomocí klávesnice. 5.3.2 Vstup jedné hodnoty z dané množiny Do kategorie vstup jedné hodnoty z dané množiny patří například komponenty typu radiobutton, menu, jednoduchý výběr (listbox, resp. select). 34
5. G E N E R O V Á N Í D I A L O G Ů S I N I C I A T I V O U S Y S T É M U
