Doplnění domén do systému zodpovídání otázek UIO

MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY ^TIS typ Doplnění domén do systému zodpovídání otázek UIO BAKALÁŘSKÁ PRÁCE Martin Polák Brno,2006

Prohlášení Prohlašuji, že tato bakalářská 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: Mgr. Lukáš Svoboda 11

Shrnutí V každodenním životě potřebujeme získávat různé informace. Jak toho ale docílit? Jednou z možností je vyhledávání informací na internetu. Běžný postup ale mnohdy nepostačuje a oblast odpovědí může být značně rozostřena oproti původní otázce. Způsobem, jak získat přímo korektní odpověď, může být využití systémů pro zodpovídání otázek v přirozeném jazyce. m

Klíčová slova QA systémy, NLP Processing, UIO

Obsah 1 Úvod 1 2 Question Answering systémy 2 2.1 Popis 2 2.2 Čeština vs. další jazyky 2 2.3 Rozdělení QA systémů 3 2.3.1 Closed-domain QA systémy 3 2.3.2 Open-domain QA systémy 3 2.3.2.1 Projekt TREC 3 2.4 Nejznámější běžně používané QA systémy 4 2.4.1 AnswerBus Question Answering System 4 2.4.2 START Natural Language Question Answering System 4 2.4.3 Google 6 2.5 Relevantní práce na FI 6 2.5.1 Znalec encykopedie 6 2.5.2 QASMAN 6 2.5.3 Systém pro komunikaci s uživatelem v přirozeném jazyce se silně omezenou doménou 2.5.4 UIO 7 3 MWE 8 3.1 Zpracování víceslovných výrazů 8 3.2 NástrojMWE 8 4 Postupy pro zpracování dotazů 11 4.1 Obecně užívané principy 11 4.1.1 Systémy založené na porovnávání vzorků s textem 11 4.1.2 Systémy založené na syntaxi 11 4.1.3 Systémy založené na sématice 12 4.2 Metodiky použité při práci rozšiřování funkčnosti UIO 12 4.2.1 Taxonomie 12 4.2.2 Bezkontextová gramatika a doména 14 4.2.2.1 Bezkontextové gramatiky 14 4.2.2.2 Doména 16 4.2.2.3 Testování v průběhu vývoje 19 5 Domény pro dotazování na mapách a převody 20 5.1 Doména Mapy 20 5.1.1 Zadání 20 5.1.2 Řešení problému 20 5.2 Doména Převody 21 5.2.1 Zadání 21 5.2.2 Řešení problému 21 5.3 Statistiky 22 v

5.3.1 Doména Mapy 22 5.3.2 Doména Převody 23 6 Závěr 25 Literatura 26 Rejstřík 27 VI

Kapitola 1 Úvod Dotazovací systémy se těší v současnosti velké oblibě, poskytují totiž mnohým uživatelům velmi snadný způsob, jak se dozvědět odpovědi na svoje dotazy Mezi rozhodně největší výhody, pro které jsou podobné systémy využívány, patří široká škála znalostí a rychlost odpovědi. Zdá se, že nemůže být nic jednoduššího, než napsat dotaz a téměř ihned dostat korektní odpověď. Zároveň je dnes trendem přibližovat manipulaci s masově využívanými nástroji obyčejným lidem. Umožní jim to s minimem znalostí instinktivně tyto nástroje používat. Proto se tvůrci různých systémů snaží najít co možná nejpřátelštější tvář svého produktu a maximálně přiblížit jeho používaní realitě. V oblasti dotazovacích systémů se tyto aspekty také prosazují a jako reakce na ně se objevují systémy pro zodpovídání otázek komunikující v přirozeném jazyce (QA system - Question Answering system). Jak získává člověk od člověka potřebnou informaci? Zeptá se jej. Položí otázku ve svém jazyce. Na podobném principu pracují i QA systémy. Ty se snaží rozpoznat z daného dotazu potřebná data a na jejich základě relevantně odpovědět. Odpověď samotná by měla obsahovat pouze požadovanou informaci, která je otázkou v přirozeném jazyce bezpochyby blíže specifikována, než je tomu u dotazů na vyhledávací systémy typu Google. Na rozdíl od těchto vyhledávacích nástrojů musí QA systém navíc porozumět sémantice dotazu. Odpovědí QA systémů ovšem není seznam dokumentů, který vyhledávač vypíše a uživatel se jimi musí dále probírat. Odpověď těchto systémů by měla být výstižná, co možná nejkratší a také - v přirozeném jazyce. V současné době již takových systému funguje celá řada a v NLP laboratoři Fakulty informatiky Masarykovy univerzity v Brně je podobný system také vyvíjen. Mojí prací bylo rozšířit jeho funkčnost o umožněni dotazování při práci s mapami České republiky. Druhou částí práce pak bylou vytvořit systém pro převody fyzikálních jednotek. Pro lepší orientaci v oblasti QA systémů také uvádím stručný popis několika dnes již používaných systémů a také technologie a nástroje, které jsem při tvorbě těchto rozšiřujících domén použil. 1

Kapitola 2 Question Answering systémy 2.1 Popis QA systémy se od obyčejných dotazovacích systémů liší tím, že na položenou otázku dokáží reagovat odpovědí, která by měla přesně korespondovat s požadovanými daty. Tzn. že vstupem takového systému je otázka v přirozeném jazyce (i když může být i v heslovitém tvaru) a odpovědí je věta, obrázek nebo např. popis, který co nejpřesněji vystihuje reakci na dotaz. V podstatě se jedná o systémy vystavěné nad databází, s jejímiž daty můžeme pracovat pomocí pokynů udělovaných v přirozeném jazyce. Příklady podobných systémů se objevují už koncem šedesátých let, nejznámějším je Lunar, rozhraní pro práci s databází chemických analýz měsíčních hornin. Lunar a podobné systémy té doby pracovaly se specifickými databázemi uloženými v paměti a proto bylo obtížné změnit oblast jejich zaměření. V sedmdesátých letech nastal v této oblasti bouřlivý rozvoj a vznikaly mnohé další systémy jako Ladder využívající vlastnosti sémantických gramatik nebo Ask, který umožnil uživatelům učit systém nová slova a fráze v průběhu sezení. 2.2 Čeština vs. další jazyky Při tvorbě systému zodpovídání otázek v českém jazyce narážíme na spoustu problémů, které při práci s jinými jednoduššími" jazyky nemusíme pocítit. Jako příklad můžeme uvézt angličtinu, která je v počítačovém světě zřejmě nejběžnějším jazykem. Ve srovnání s češtinou její snadnější použití vyplývá hlavně z relativně menší ohebností většiny slov. České slovo může být reprezentováno více tvary nebo naopak může mít jedinný tvar více významů, což pak zvyšuje nároky na jeho zpracování. Při něm musíme v českém jazyce velice často využívat procesy lemmatizace a derivace. Lemmatizace spočívá v převádění různých slovních tvarů na základní tvar. Derivace je pak funkcí opačnou k lemmatizaci. Z uvedeného vyplývá složitá desambiguace, tj. jednoznačnost určení významu slov, např. zdraví" může být podstatné jméno, stejně tak jako přídavné jméno nebo sloveso. Z těchto důvodů neexistuje pro češtinu syntaktický analyzátor. 2

2.3. ROZDĚLENÍ QA SYSTÉMŮ 2.3 Rozdělení QA systémů 2.3.1 Closed-domain QA systémy Tyto systémy pracují pouze na omezené skupině dat, která je specifická pro jednu konkrétní doménu. Při jejich tvorbě je kladen důraz na podrobnost zpracování dané oblasti. Pracují se specializovanými bázemi dat, která jsou velmi často uložena ve formátu XML nebo jiném, umožňujícím co možná nejefektivnější přístup k datům. 2.3.2 Open-domain QA systémy Na rozdíl od Closed-domain QA systémů není oblast jejich působnosti tématicky omezena. Pracují s rozsáhlými korpusy textů nebo s dokumenty na internetu. Protože se většinou jedná o nestrukturovaná data, musí tyto systémy vhodně implementovat algoritmy vyhledání informace (Information Retrieval - IR) a extrakce informace (Information Extraction - IE). Teorie IR se zabývá způsoby manipulace s nestrukturovanými daty, resp. efektivním ukládáním dat, katalogizací, klasifikací a efektivním vyhledáváním. Úkolem IR je tedy rychlé nalezení dokumentů s požadovanou informací. Nezabývá se však jejím dalším zpracováním, na výstup dává nalezený dokument či jeho fragment. Na internetu existuje mnoho aplikací, které vybírají dle zadaného seznamu klíčových slov seznam relevantních dokumentů. Příkladem takové aplikace je textový vyhledávač Google. Pro přesnější zpracování odpovědi se využívají IE algoritmy. Mohou být považovány za určité rozšíření IR algoritmů, protože dále zpracovávají jejich výstupy. Snaží se v textu rozpoznat jednotlivé třídy slov, jejich podtřídy apod. 2.3.2.1 Projekt TREC Text REtrieval Conference se koná každoročně pod záštitou Národního institutu standardů a technologií. První konference byla uspořádána v roce 1992 jako součást programu TIPSTER. Jejím cílem je podporovat výzkum v oblasti vyhledávání informací v rozsáhlých dokumentech. V současnosti má tento projekt pět hlavních cílů: podpořit výzkum v oblasti vyhledávání informací za použití rozsáhlé sady testů zlepšit komunikaci mezi akademickou, průmyslovou a státní sférou a umožnit výměnu postupů za účelem zvýšení výkonnosti urychlit cestu projektů z laboratoří do průmyslového využití prezentacemi těchto prací zvýšit schopnosti využití těchto projektů ve všech sférách vytvořit soubor testů, pokrývajících různé oblasti vyhledávání informací 3

2.4. NEJZNÁMĚJŠÍ BĚŽNĚ POUŽÍVANÉ QA SYSTÉMY Součástí této konference je soutěž systémů zodpovídání otázek vytvořených různými skupinami. Systémy jsou testovány nad sadou testovacích dokumentů. V roce 2004 sada obsahovala přibližně 1033000 dokumentů a měla rozsah asi 3 GB textu. Skládá se převážně z novinových článků a vládních dokumentů. Hodnotí se například přesnost (precision) a odezva (recall). Maximální hodnota obou veličin je 1.0. Přesnost má tuto hodnotu právě tehdy, pokud jsou vybrány pouze relevantní dokumenty a odezva je maximální, když jsou vybrány všechny relevantní dokumenty. Další informace o konferenci TREC jsou k dispozici na slidech [9] a na webu. 1 2.4 Nejznámější běžně používané QA systémy V současné době je již na webu úspěšně spuštěno několik QA systémů (např. asked!, Askjeeves!, IONAUT, LAMP, QuASM, SiteQA Demo, Sydney 2000 Olympics Fact Finder a Wondir), mezi nejznámější však patří AnswerBus Question Answering System a START Natural Language Question Answering System. Jisté prvky komunikace v přirozeném jazyce vykazuje i webový vyhledávač Google. 2.4.1 AnswerBus Question Answering System AnswerBus 2 je příkladem systému typu Open-Domain a je založen na inteligentním získávání odpovědí. Je schopen pracovat ve více světových jazycích, jako jsou kromě angličtiny také němčina, francouzština, italština a některé další. Tvůrcem systému AnswerBus je Zhiping Zheng, který v současnosti pracuje v Oddělení počítačové lingvistiky na Saarland University. AnswerBus při vyhodnocování dotazu využívá pět vyhledávacích nástrojů (Google, Yahoo, WiseNut, AltaVista, Yahoo News), jejichž výsledky dále zpracovává a ve vrácených dokumentech se snaží nalézt odpověď. Tou již není skupina dokumentů, ale pouze věty, nesoucí potenciální odpověď. Tyto věty jsou pak dále setříděny podle relevance a poskytnuty tazateli. Názorné schéma zpracování dotazu systémem AnswerBus je zobrazeno na obrázku 2.1. 2.4.2 START Natural Language Question Answering System START 3 (SynTactic Analysis using Reversible Transformations) byl vyvinut Borisem Katzem, pracovníkem Technického institutu v Massachusetts. Práce na něm započaly v Laboratoři umělé inteligence, nyní je systém rozvíjen společností InfoLab Group, vedenou Borisem Katzem. START byl poprvé spuštěn na webu v prosinci roku 1993. Stěžejní postup, nazývaný "anotace přirozeného jazyka" (natural language annotation) pomáhá STARTu spojit zdroje informací s tazateli. Tato technika používá věty a fráze přiro- 1. http://trec.nist.gov/ 2. http://www.answerbus.com/ 3. http://start.csail.mit.edu/ 4

2.4. NEJZNÁMĚJŠÍ BĚŽNĚ POUŽÍVANÉ QA SYSTÉMY Otázka I Přeložená otázka r 1 r Porovnání Typ otázky slov i ' Vytvoření dotazu pro vyhledávač v Vybrané vyhledávače i Výběr seznamu výsledků z vyhledávačů 1 Extrahované věty ' * Kandidáti na odpověď ' O - ' A nerazené uupuvcui ~"^ Obrázek 2.1: Schéma práce QA systému AnswerBus zeného jazyka jako popisky obsahu, které jsou asociovány s informačními segmenty s různou podrobností. Informační segment je vybrán, pokud jeho popis souhlasí s otázkou na vstupu. Tato metoda umožňuje STARTu uchovávat a zpracovávat různé druhy informací, jako jsou text, diagramy, obrázky, video a audio ukázky, webové stránky a mnohé další. START se snaží s uživatelem komunikovat v přirozeném jazyce. To znamená, že pokud položíme otázku, např. Who is Martin Polák", dokáže START odpovědět celou větou. V tomto případě osobu Martin Polák nezná a reakce je tedy Sorry, no one has told me who Martin Polák is". Podobná, ovšem kladná, reakce nastane, jestliže se tážeme třeba Who is George Bush" Systém odpoví a navíc nás upozorní, že zná těchto osob víc: I know about one more person called "George Bush"". START je na rozdíl od AnswerBusu příkladem Closed-domain QA systému a specializuje se na témata týkající se zeměpisných znalostí, kultury a historie, výzkumu a vědy a umění a zábavy 5

2.5. RELEVANTNÍ PRÁCE NA FI 2.4.3 Google I když nemůžeme považovat vyhledávač Google 4 za klasický případ vyhledávače komunikujícího s uživatelem v přirozeném jazyce, jsou v poslední době patrné snahy jeho tvůrců o to, aby systém porozuměl i těmto dotazům. Navíc je Google nejvyužívanějším webovým vyhledávačem. Je schopen porozumět zcela základním dotazům, jako je např. What is computer" a podobně. Na rozdíl od standardní odpovědi se na prvním místě v seznamu reakcí objeví stránka s definicí slova v angličtině. Je schopen také porozumět dalším dotazům, které jsou ovšem pouze obdobou uvedeného, jako například define computer". Dokáže však pracovat jen s těmito dotazy na definice. Ani toto zpracování není ale implementováno dokonale, neporozumí ani významově stejným nebo podobným dotazům jako např. circumscribe computer". 2.5 Relevantní práce na FI V minulosti již byly na FI MU implementovány různé systémy, zabývající se komunikací nad nějakou bází dat v přirozeném jazyce. Přehled některých z nich je uveden v následujících podkapitolách. 2.5.1 Znalec encykopedie Jedná se o systém, který vznikl v roce 2001 v rámci diplomové práce Zdeňka Svobody a pracuje s daty encyklopedie Diderot 2000. Jádro tvoří dva moduly, z nichž každý využívá různý postup pro zodpovězení dotazu. Modul index XML pracuje s daty ve formátu XML. Využívá znalostní bázi, obsahující nejčastěji kladené dotazy ve formě regulárních výrazů, a pokud je s jeho pomocí nalezena odpověď s dostatečnou přesností, vyhledávání končí. Pokud odpověď není nalezena nebo je její relevance příliš nízká, použije se vyhledávání pomocí dalšího modulu. Index IR pracuje s nestrukturovnými daty. Slouží pro zvýšení funkčnosti a robustnosti celého systému. Je založen na mnoha heuristikách, provádí lexikální a morfologickou analýzu dotazu a na jejich základě se snaží rozpoznat v textu entity, které by mohly poskytnout odpověď. V případě, že není typ odpovědi rozpoznán, jsou extrahovány alespoň nejvíce relevantní dokumenty, kde lze odpověď dohledat. 2.5.2 QASMAN Systém QASMAN zpracovává dotazy nad manuálovými stránkami v Linuxu a byl vytvořen v rámci diplomové práce Pavla Možného. Je implementován v programovacím jazyce Perl a jádro je tvořeno čtyřmi moduly, které se starají o analýzu textu, práci s manuálovými stránkami a nastavení systému. 4. http://www.google.com/ 6

2.5. RELEVANTNÍ PRÁCE NA FI Postup pro analýzu dotazu je podobný jako v případě systému Znalec encyklopedie, tj. dotaz je nejprve zpracováván pomocí souboru vzorů (taxonomie). Pokud není tato procedura úspěšná, přichází na řadu morfologická analýza, následně oprava překlepů a klasifikace otázek. 2.5.3 Systém pro komunikaci s uživatelem v přirozeném jazyce se silně omezenou doménou Systém vznikl jako součást diplomové práce Davida Lásky v roce 2001, pracuje s českým jazykem a orientuje se na zpracování dotazů ohledně předpovědi počasí. Analýze dat předchází jejich parsing, který spočívá v rozdělení textu na věty jednoduché a souvětí, která jsou pak dále členěna na dílčí jednoduché věty. Algoritmus využívá standardních oddělovačů, jako jsou.", ;" a další. Následuje samotná analýza. Zpracování dotazu probíhá ze začátku stejně jako analýza oznamovací věty, k odlišení dochází až po skončení sémantické analýzy. Otázky jsou rozděleny podle základních typů (kdy, kde, jak...), na otázky s předložkou (na kdy, v kolik...) a na otázky vyžadující potvrzení nějakého faktu (Bude pršet? apod.). Po zjištění odpovědi ve znalostní bázi systém reaguje buď celou větou, odpovídajícím výrazem nebo jedním slovem (ano/ne). 2.5.4 UIO Systém je příkladem Closed-domain QAS, v současné době umí odpovídat na dotazy z oblasti IS MU. Doména vznikla v rámci diplomové práce Petra Juráška a poskytuje studentům a pracovníkům MU zjednodušené možnosti vyhledávání v databázi informačního systému. Předmětem mé práce bylo rozšířit funkčnost také o domény Mapy a Převody a principy tvorby těchto extenzí jsou uvedeny dále. V NLP se dále pracuje na obohacení stávajícího systému o dotazování v oblastech kultury, dopravních spojů apod. Technické podrobnosti fungování lze nalézt v [8]. 7

Kapitola 3 MWE 3.1 Zpracování víceslovných výrazů Při vyhodnocování dotazů v přirozeném jazyce je nezbytně nutné využívat nástroj pro zpracování víceslovných výrazů. Jedná se o skupiny slov jdoucích v dotazu po sobě, které mají ale význam jako celek. V doménách pracujících s mapami a převody jednotek to jsou např. Jindřichův Hradec", Dvůr Králové nad Labem" nebo kilogram na metry krychlové". Každý z těchto výrazů musí být vyhodnocen jako celek, protože mají vlastní smysl (jednotka hustoty, jméno města apod.). Aby to tak mohlo být, jsou na ně kladena určitá omezení, vycházející z vlastností daného jazyka. V angličtině, němčině a mnoha dalších podobných jazycích je zpracování těchto výrazů o to jednodušší, že v nich existují omezené možnosti modifikací jednotlivých slov v různých osobách, pádech apod. Oproti tomu čeština je jazyk velmi pestrý, např. pro podstatné jména poskytuje díky sedmi pádům v jednotném a množném čísle až čtrnáct různých tvarů jednoho slova. To klade důraz na striktnější omezení zpracování víceslovných výrazů. Při jejich zápisu se kontroluje shoda jednotlivých slov na pády atd. Například Jindřichově Hradci" je korektně utvořený výraz, oproti tomu Jindřichův Hradci" jako celek žádný smysl nemá. Tato a mnohá další omezení plynoucí z pravidel gramatiky českého jazyka musí být proto uplatňována i při analýze dotazů, kde se podobné výrazy vyskytují. 3.2 Nástroj MWE V NLP laboratoři na Fakultě informatiky MU byl pro zpracování těchto výrazů vyvinut nástroj MWE (MultiWord Expression). Jedná se o knihovnu víceslovných výrazů, kde je pomocí různých vzorů definováno přípustné ohýbání slov, jejich zařazení do kategorií a data, která se k nim v dané kategorii vztahují. Záznamy lze do databáze přidávat ze zdrojových textových souborů, kde jsou uvedeny ve tvaru: výraz<tab>kategorie<tab>váha<tab>data kde <tab> značí znak tabulátor. Konkrétním případem zdroje využitého pro doménu Převody je: nit JAS 1 {:lemma => 'niť,.značka => 'nťj stilbjas 1 {-.lemma => 'stílb',.značka => 'sb'} 8

3.2. NÁSTROJ MWE V mwe souborech však ještě nelze vyhledávat, musíme prvkům výrazů přiřadit gramatický vzor, abychom určili pravidla, podle kterých můžeme s výrazy pracovat. Optimální by byla ruční konverze, kdy bychom mohli tato pravidla definovat přesně, v praxi však probíhá konverze pomocí strojového zpracování, která je ovšem do jisté míry nedeterministická. Při strojové konverzi do formátu srozumitelného pro MWE (soubory formátu morf) probíhá morfologická analýza pomocí nástroje ajka. Během tohoto procesu se ajka snaží přiřadit k jednotlivým slovům všech výrazů vzory, podle kterých pak může být dané slovo ohýbáno. Může narazit na slova, která mají více vzorů nebo je naopak není schopna analyzovat. Podle toho se také liší výstupy konverze: ajka slovo analyzovala Záznamy v databázi jsou pak ve formě: lemmal:indexl,vzorl<space>lemma2:index2,vzor2<tab>hash pro dvouslovný výraz, kde <space> značí mezeru, lemmal a lemma2 jsou lemmata každého slova z výrazu, vzorn je vzorem pro slovo s lemman. Každý vzor ma číselné označení index. Hash obsahuje data z řádku zdrojového souboru, plus klíč.category, označující kategorii a '.weight pro váhu. Oboje se získává ze zdrojového souboru. Může se také stát, že ajka má pro dané slovo definováno více vzorů, potom jsou na výstup poslány všechny možnosti. Uvedenému příkladu pak odpovídá záznam v databázi: nit:212,bez {:lemma=>"niť, -.category=>:jas, :znacka=>"nť, :weight=>"l"} nit:40,chrudim {:lemma=>"nit", -.category=>:]as, :znacka=>"nt", :weight=>"l"} stilb:212,bez {:lemma=>"stilb", -.category=>:]as, :znacka=>"sb", :weight=>"l"} analýza nebyla úspěšná Ajka nedokázala slovům výrazu přiřadit žádný vzor. Potom je slovo zpracováno dalším algoritmem. Ten se snaží určit kořen slova a připojit za něj možné přípony. Záznam je pak ve databázi uveden ve tvaru: slovo:.ispell<tab>hash kde slovo vzniká jako výsledek výpočtu algoritmu, tzn. pro jedno skutečné slovo může algoritmus vypočítat více variant, podle toho, s kolika příponami jej nakonec vyhodnotí. Pro záznam ze zdrojového souboru velekopa NASOBKY-DILY-STARE 1 { -.veličina => 'staré násobky a díly', -.lemma => 'velekopa',.značka => nil, -.koefícient => 36600,.popis => '1 velekopa = 60 kop.', -.vzorec => nil,.zeme => nil,.poznámka => nil, :je_zkratka => false } po kompilaci obdržíme: 9

3.2. NÁSTROJ MWE VELEKOPA:.ispell {:koefícient=>3600, :popis=>"l velekopa = 60kop.", :vzorec=>nil, :zeme=>nil, :lemma=> "velekopa", :velicina=>"star\351 n\341sobky a d\3551y", :category=>:"nasobky-diľy-stare", :poznamka=>nil, :znacka=>nil, :weight=>"ľ'} VELEKOP:.ispell {:koefícient=>3600, :popis=>"l velekopa = 60 kop.", :vzorec=>nil, :zeme=>nil, :lemma=> "velekopa", :velicina=>"star\351 n\341sobky a d\3551y", :category=>:"nasobky-diľy-stare", :poznamka=>nil, :znacka=>nil, :weight=>"ľ'} VELEKOPUS:.ispell {:koefícient=>3600, :popis=>"l velekopa = 60kop.", :vzorec=>nil, :zeme=>nil, :lemma=> "velekopa", :velicina=>"star\351 n\341sobky a d\3551y", :category=>:"nasobky-diľy-stare", :poznamka=>nil, :znacka=>nil, :weight=>"ľ'} VELEKOPO:.ispell {:koefícient=>3600, :popis=>"l velekopa = 60kop.", :vzorec=>nil, :zeme=>nil, :lemma=> "velekopa", :velicina=>"star\351 n\341sobky a d\3551y", :category=>:"nasobky-diľy-stare", :poznamka=>nil, :znacka=>nil, :weight=>"ľ'} Pro zjednodušení umí MWE pracovat také s jednoslovnými výrazy. V současné době již databáze obsahuje takové množství záznamů, že bylo nutné přistoupit na její co nejefektivnější reprezentaci. Proto jsou data uložena ve stromové struktuře trie, což zabezpečuje vysokou rychlost operací s nimi prováděných. Pro testování přítomnosti výrazu v databázi pro MWE existuje jednoduchá utilita v jazyce Ruby testmwe.rb. Po jejím spuštění má uživatel možnost zadat výraz (větu), která je analyzována a výstupem je souhrn informací o prvcích věty, které se vyskytují v databázi. Může to být velmi užitečné při přidávání nových dat do databáze a následném testování úspěšnosti operace, nebo pokud si při analýze dotazu nejsme jisti, jestli je požadovaný výraz uložen v databázi. 10

Kapitola 4 Postupy pro zpracování dotazů 4.1 Obecně užívané principy Existuje více principů, jak může QA systém pracovat. V průběhu skoro 40 let bylo vyvinuto několik postupů zpracování dotazu. 4.1.1 Systémy založené na porovnávání vzorků s textem Tyto systémy (angl. Pattern-matching systems) vznikaly zejména v dřívějších dobách, kdy byl vývoj různých rozhraní pro práci s databázemi v přirozeném jazyce ještě v počátcích. Princip práce spočívá v pokrývání dotazu regulárním výrazem a určení akce v případě shody. Tento jednoduchý přístup má několik výhod, předně regulární výrazy lze používat ve většině programovacích jazyků. Také při zpracování dotazu neprobíhá syntaktická ani sémantická analýza a proto je vyhodnocování poměrně rychlé. Nevýhodou oproti tomu může být u některých jazyků (čeština) mnoho možností, jak poskládat dotaz se stejným významem. Každý možný slovosled musí být potom reprezentován jiným regulárním výrazem. 4.1.2 Systémy založené na syntaxi Systémy tohoto druhu (angl. Syntax-based systems) používají gramatiku, která popisuje možné syntaktické struktury dotazů. Gramatika je tvořena podle slovních druhů, v ní jsou definovány jejich pozice. Konkrétním příkladem je systém Lunar". Úryvkem gramatiky založené na syntaxi můžeme demonstrovat její strukturu, příklad je převzat z [7]: S -> NP VP NP -> Det N Det -> "what" "which" N -> "rock" "specimen" "magnesium" "radiation" "light" VP -> V N V -> "contains" "emits" Neterminál S reprezentuje celou větu a je tvořen částmi vztahujícími se k podstatnému jménu (noun phrase - NP) nebo slovesu (verb phrase - VP). Další neterminály charakterizují část dotazu noun phrase, konkrétně determinant (determiner - Det) a podstatné jméno 11

4.2. METODIKY POUŽITÉ PŘI PRÁCI ROZŠIŘOVÁNÍ FUNKČNOSTI UIO (noun - N), slovesnou část tvoří sloveso (verb - V) a další podstatné jméno. Z gramatiky jednoznačně vyplývá postavení slovních druhů ve větě. Tento fragment je sice velmi jednoduchý, demonstruje však použití a dokáže porozumět dotazům which specimen emits light" nebo which rock contains magnesium". 4.1.3 Systémy založené na sématice Princip sémantických systémů (Semantic grammar systems) spočívá stejně jako syntaktických v použití gramatiky. Narozdíl od nich však prvky gramatiky nereprezentují slovní druhy a jejich spojení, ale neterminály tvoří významové celky. Části dotazu odvoditelné z jednoho neterminálu jsou tedy na stejné významové úrovni. Tato metoda je ovšem striktně závislá na doméně, pro kterou byla gramatika vytvořena. 4.2 Metodiky použité při práci rozšiřování funkčnosti UIO Při rozšiřování stávajícího dotazovacího systému v NLP laboratoři jsem se seznámil s mnoha technologiemi, nezbytnými pro efektivní vývoj nových domén. Nejdůležitějšími jsou dva základní postupy, jak zpracovat dotaz a zajistit tak odpovídající reakci. 4.2.1 Taxonomie Využití taxonomie je jedním z postupů, jak pochopit sémantiku dotazu a relevantně na něj odpovědět. Soubor s taxonomií obsahuje bloky regulárních výrazů, které se snaží pokrývat možné dotazy k dané problematice. Každý blok se potom vztahuje k jednomu tématu. Na konci takového bloku se nachází reakce, která poskytuje odpověď na všechny otázky v daném bloku. Pro zjednodušení práce lze uvézt na začátek taxonomie definiční data pro práci s regulárními výrazy, definici domény a cest k datům pomocí XPath výrazů. definice regulárních výrazů Protože může být regulární výraz velmi obsáhlý nebo často používaný, je možné si jej pro zjednodušení práce pojmenovat a zpřehlednit tak jeho užití v taxonomii. Strukturu takové definice pak lze popsat výrazem: =def.abbre $POJMENOVÁNÍ_RE$ (RE) Konkrétní příklad užití je uveden v následující konstrukci: =def.abbre $VOBORU$ (?:(?:(?:v\ve)(?: oboru\ definice nové domény zamereni)?)\(?:obor\zamereni)) Zde je možné určit doménu pro vytvářenou taxonomii. Obecná struktura definice je tvaru: =def.database=doména, type=typ, source=soubor 12

4.2. METODIKY POUŽITÉ PŘI PRÁCI ROZŠIŘOVÁNÍ FUNKČNOSTI UIO Za typ můžeme dosadit řetězex XML", pokud jsou data ve formátu xml, v tom případě je nutné definovat i cestu k souboru, nebo ponecháme STRING" a SOUBOR je prázdný řetězec "". Užití v praxi: =def.database=is, type=string, source="" =def.database=sylab, type=xml, source="domain/is/sylabutf.xml" definice XPath výrazu Lze popsat funkce pro data nalezená v xml souboru pomocí XPath výrazu za předpokladu, že vstupní větu můžeme reprezentovat regulárním výrazem. Údaj má následující strukturu: =def.finddata(doména,$kategorie$)="xpath výraz" Konkrétně tedy na například: =def.finddata(sylab,$predmet$)="//predmet[@nazev=\"#{$l[:nazev]}\"]" Soubory s taxonomií jsou jednoduše strukturovatelné a proto velmi přehledné. Jako další zpříjemnění práce s taxonomií si můžeme každý blok tématicky pojmenovat a usnadnit tak orientaci. Použití taxonomie je zároveň přirozené a jednoduché. Zpracování dotazů pomocí taxonomie ovšem není vždy na místě. Reprezentujme dotaz výrazem ZAČÁTEK DATA_PRO_ZPRACOVÁNÍ KONEC. ZAČÁTEK a KONEC mohou být pojmenované regulární výrazy, které reprezentují často užívané konstrukce, jako např. kde je", kde se nachází" apod. Nás ovšem nejvíce zajímají data, která musíme získat pro další zpracování a ta jsou obsažena v sekci DATA_PRO_ZPRA- COVÁNÍ. Pro ukázku uvádím příklad, kde je tento problém názorně demonstrován. Mějme dotaz Chci vědět, které nakladatelství vydalo knihu Společenstvo prstenu od J. R. R. Tolkiena v roce 2000" Pro zjištění odpovědi je důležitá jen část věty. Stejnou odpověď očekáváme na dotaz Chci vědět, které nakladatelství vydalo v roce 2000 knihu Společenstvo prstenu od J. R. R. Tolkiena" Změna je pouze v pořadí údajů ve větě, ovšem regulární výrazy musí všechny tyto možnosti brát v potaz. Ve výsledku je často nezbytné reprezentovat všechny sémanticky možné permutace dotazu, což způsobuje značný nárůst dat v taxonomii a tím roste i doba zpracování dotazu. Tento problém řeší užití bezkontextových gramatik. Pro pochopení základních prvků konstrukce taxonomie uvádím jednoduchý příklad na obrázku 4.1. Ten demostruje využití definic a příklad jednoho tématického bloku rozšířených regulárních výrazů. Vyhovující jsou vstupy jako Zjisti, co napsal Martin Polák v oboru matematika", Jaká publikace byla napsána Petrem Novákem v informatice" apod. Reakcí je potom výpis informací nutných pro vypracování odpovědi a to je jméno autora a obor působnosti. 13

4.2. METODIKY POUŽITÉ PŘI PRÁCI ROZŠIŘOVÁNÍ FUNKČNOSTI UIO %%Casto opakujici se dotazy =def.abbre $DOTAZ$ (?:najdi hledej z jisti nacti)?) =def.abbre $KTEROUPUBLIKACI$ (?:(?:(?:jak(?:ou e a) kter(?:ou e a)) ) (?:publikac[ie] prac[ie]) co) =def.abbre $NAPSAL$ (?:(?:napsala? publikovala? byl[ao] publikován[ao] byl[ao] napsán[ao]))? =def.abbre $AUTOR$ (?:autor(?:ka em kou)?) %%AUTOR A OBOR (?:$DOTAZ$ )?(?:$KTEROUPUBLIKACI$ )?(?:$NAPSAL$ )?(?:$AUTOR$ )?(?:$JMENO$ ) (?:$VOBORU$ )?(?:$OBOR$) (?:$DOTAZ$ )?(?:$KTEROUPUBLIKACI$ )?(?:$AUTOR$ )?(?:$JMENO$ )(?:$NAPSAL$ )? (?:$VOBORU$ )?(?:$OBOR$) $STRING:&"autor: #{$JMENO$} obor: #{$OBOR$[:nazev]}"$ Obrázek 4.1: Taxonomie - definice a blok regulárních výrazů 4.2.2 Bezkontextová gramatika a doména Použití gramatiky je dalším způsobem, jak analyzovat dotaz. Věta je syntakticky zkoumána shora dolů. Pokud proběhne analýza úspěšně (najdeme reprezentaci věty pomocí pravidel gramatiky), můžeme tuto větu zpracovat jako dotaz nad danou doménou. Jestli věta není gramatikou zcela analyzována, můžeme pokračovat ve zkoumání dalšími prostředky (rámce). 4.2.2.1 Bezkontextové gramatiky Návrh Před samotnou konstrukcí gramatiky je vhodné si vytvořit její návrh. Jako základ pro další práci bychom si měli sestavit seznam pokud možno všech dotazů, na které by měl systém reagovat. Podle něj se rozhodneme, která data budeme muset mít uložena v databázi a která slouží pro vyjádření sémantiky dotazu. Ty potom reprezentujeme v gramatice pomocí pravidel. Pro přehlednost je výhodnější, pokud každá větev stromu gramatiky sdružuje dotazy s konkrétním významem. Princip Gramatika se skládá z pravidel, podle kterých můžeme danou větu analyzovat. Pravidlo je tvaru: NETERMINÁL -> pravá_strana kde pravá_strana reprezentuje, na co můžeme NETERMINÁL přepsat, tedy jiný NETERMI NÁL nebo nějakou HODNOTU - terminál. Uspořádáním pravidel od kořenového neterminálu tedy obdržíme strom s konečnou výškou, což vyplývá z definice kontextové gramatiky. Věta jazyka generovaného touto gramatikou je potom jedna z větví tohoto stromu. Rozšíření, notace V rámci bezkontextové gramatiky je běžné, že lze jeden neterminál přepsat více způsoby. Pro oddělení jednotlivých možností slouží operátor. Může tak 14

4.2. METODIKY POUŽITE PRI PRACÍ ROZŠIROVANÍ FUNKČNOSTI UIO vzniknout složitější pravidlo ve tvaru NETERMINÁL -> NETERMINÁL1 NETERMINÁL2 podobně můžeme utvořit libovolné pravidlo. Pro aplikaci bezkontextových gramatik v dotazovacích systémech jsou definována určitá rozšíření. Jejich příznaky se uvádí většinou za pravidla gramatiky. :XX se užívá především u kořenového pravidla a signalizuje, že daný neterminál pokrývá celou větu. :X použijeme u pravidel, které chceme později použít při zpracování pomocí rámců. Je také vhodné používat při ladění gramatiky, protože zaručuje, že dané pravidlo bude při úspěšném použití zasláno na debugační výstup. :prior int uděluje pravidlům gramatiky různou prioritu při zpracování. Můžeme použít, pokud je gramatika nejednoznačná. Parametr int vyjadřuje celé číslo, určující prioritu, čím větší int, tím vyšší je priorita. :weight dec poskytuje informaci, s jakou váhou byla věta analyzována. V případě, že je možno dotaz v gramatice analyzovat více relevantními způsoby, můžeme zavézt uspořádání podle vah. Výsledná váha je součinem všech vah u pravidel, která předcházela úplné analýze. :asoc [ left \ right \ no ] definuje asociativitu pravidla. Terminál gramatiky může být zadán v různých tvarech: "data" definuje použití řetězce data striktně v uvedeném tvaru, tzn. bez skloňování, časování apod. 'data' se užívá, pokud chceme zajistit výskyt slova data ve všech jeho tvarech Dále můžeme obě uvedené možnosti zápisu doplnit na regulární výrazy a libovolně kombinovat, např. "na"? 'mapa' bude reprezentovat řetězce jako na mapě", mapách" apod. Pro usnadnění práce s různými permutacemi terminálů a neterminálů v pravidle gramatiky slouží znak *. Jeho uvedením u prvků pravidla na pravé straně říkáme, že tyto prvky mezi sebou mohou libovolně permutovat. Pokud chceme v pravidle označit terminál nebo neterminál, jehož užití je nepovinné, napíšeme za jeho výskyt v pravidle znak?. Následující gramatika je schopna pokrýt dotazy, jako jsou co napsal Martin Polák v informatice" i co napsal v informatice Martin Polák" bez toho, aby jsme museli obě možnosti vypisovat. VETA -> DOTAZ OBOR* AUTOR* DOTAZ -> "co napsal" "kterou publikaci napsal" AUTOR -> "spisovatel"? AUTOR_MWE OBOR -> 15

4.2. METODIKY POUŽITÉ PŘI PRÁCI ROZŠIŘOVÁNÍ FUNKČNOSTI UIO Pro větší přehlednost a upřesnění můžeme v gramatice uvádět komentáře. Označují se uvedením znaku % na začátku komentářového řádku a příklad užití je zřejmý z obrázku 4.2. K pravidlu gramatiky můžeme také doplnit akci, která se provede po jeho úspěšném vyhodnocení. Akce jsou zapsány ve tvaru: {$$ akce $$} Akcí může být nějaká štandartní nebo předdefinovaná funkce jazyka Ruby, nebo jenom vrácení hodnoty. V těchto sekcích se manipuluje s daty, která jsou nutná pro zodpovězení dotazu, probíhá generování a ukládání hodnot do proměnných a volání funkcí. Za povšimnutí stojí postup v případě požadavku získání informací o záznamu z databáze MWE. Informace o objektu z databáze je automaticky uložena na posledním místě pole. Je to hash a specifikací klíče můžeme přistupovat k jednotlivým položkám, například: OBEC -> OBEC_MWE {$$ *args args[-l]['nazev_obec] = args[-l]['obec_mwe'][:lemma] $$} Uvedenou konstrukcí do posledního prvku pole args přidáváme hodnotu s klíčem NA- ZEV_OBEC. Hodnotou je základní slovní tvar části dotazu, který byl vyhodnocen pomocí MWE, v tomto případě se jedná o údaj z databáze názvů obcí. Na obrázku 4.2 uvádím praktickou ukázku, demostrující popsané vlastnosti gramatiky. Jedná se o skupinu pravidel umožňujících pracovat s čísly, provádět s nimi jednoduché operace a to jak s údaji v ryze číselném tvaru, tak i s některými definovanými slovními tvary. Ty jsou pro potřeby výpočtů převáděny na čísla. 4.2.2.2 Doména Soubor s doménou obsahuje kód jazyka Ruby, který rozšiřuje funkce gramatiky a specifikuje některá nastavení. Pro větší přehlednost je doporučeno dělit kód do bloků v pořadí specifikace, rozšíření (rámce) a naprogramované funkce volané gramatikou a rámci jako reakce na dotaz. Specifikace Tato část domény obsahuje její určení pro konkrétní gramatiky a definuje v gramatice použité záznamy z MWE. Nastavení gramatiky pro doménu je uvozeno příkazem register _grammar( 'grammar, grm'). Záznamy z MWE, které chceme použít v gramatice se nastavují pomocí register_category( { 'POJMENOVÁNÍ' => { :type => :mwe, :mweorigname => 'NÁZEV_V_MWE' } }) 16

4.2. METODIKY POUŽITÉ PŘI PRÁCI ROZŠIŘOVÁNÍ FUNKČNOSTI UIO %MATEMATICKY VYRAZ %kořenový neterminál pro tuto skupinu pravidel EXP -> EXP_ :X {$$ i, c i $$} %převod nultého prvku na čislo EXP_I -> EXP {$$ *i i[0].to_i $$} %pravidla pro jednoduché operace s čísly EXP_ -> EXP_ "\+" EXP_ :prior 5 :asoc left {$$ *i i[0] + i[2] $$} EXP_ "\-" EXP_ :prior 5 :asoc left {$$ *i i[0] - i[2] $$} EXP_ "\*" EXP_ :prior 10 :asoc left {$$ *i i[0] * i[2] $$} EXP_ "/" EXP_ :prior 10 :asoc left {$$ *i i[0] / i[2] $$} %pravidlo pro práci se závorkami "\(" EXP_ "\)" {$$ *i i[l] $$} %pravidlo pro normalizaci desetinného tvaru pomocí "." "\d+([.,]\d)?" {$$ *i i[0].gsub(/,/,'.').to_f $$} %konverze čísel ze slovního tvaru na číslice 'půl' {$$ 0.5 $$} 'čtvrť {$$ 1/4 $$} I 'třetina' {$$ 1/3 $$} 'třičtvrtě' {$$ 3/4 $$} Obrázek 4.2: Gramatika - demonstrace užití základních rozšíření Touto konstrukcí zpřístupníme pro gramatiku záznamy v MWE s označením kategorie NÁ- ZEV_V_MWE. V gramatice je pak budeme používat s označením POJMENOVÁNÍ. Toto může být velmi praktické, zejména pokud je název kategorie netriviální, je vhodné si jej pro snadnější čitelnost v gramatice přejmenovat. Rámce Rámce (frames) jsou rozšířením gramatiky, které umožňuje zodpovědět i některé dotazy, které nebyly gramatikou zcela analyzovány. Rámce vybírají z dotazu jen data, která jsou nutná pro zařazení pod danou doménu. Jsou to údaje, které jednoznačně určí, o jakou doménu se jedná a také ty, které jsou nutné pro zodpovězení dotazu. Je tedy třeba vybrat v gramatice neterminály, z nichž jsou tato data odvoditelná. Tyto neterminály označíme příznakem :X a tím je zpřístupníme pro zpracování rámci. V praxi by měl tedy frame pracovat se dvěma typy neterminálů: neterminály určující danou gramatiku - tato specifikace je velmi důležitá, zejména pokud předpokládáme, že systém bude pracovat s více doménami. Může se stát, že některé dotazy, pokud nebudou zpracovány gramatikami, mohou obsahovat data postačující pro vyhodnocení rámci více domén. Je vhodné si v gramatice vytvořit jednoduchý neterminál, který se přepíše pouze na očekávané terminály (např. v doméně nad mapami by rozhodně měl obsahovat výrazy jako "kde je", 'mapa' apod.). neterminály, z nichž odvodíme odpověď - jsou neterminály, jejichž odvozením získáme podstatu dotazu (pro dotazování nad mapami např. město Brno, ulice Botanická). Z této podstaty pak můžeme odvodit odpověď. 17

4.2. METODIKY POUŽITÉ PŘI PRÁCI ROZŠIŘOVÁNÍ FUNKČNOSTI UIO Strukturu a funkce jednotlivých prvků rámce demonstruji na příkladu na obrázku 4.3 a jeho popisu. register_fráme(frame.new( { :frame_name => 'MAPY_OBEC_ULICE', :weight => 1, :attrs => [ Frameltem.new('ASIMAPA', { }, 0), Frameltem.new('ASIOBEC, { }, 0), Frameltem.new('ASIULICE', { 'ASIULICE' => " }, 0.5) ], :lower_frames => [ 'MAPY_ULICE', 'MAPY_MALO_UDAJU' ], :action => { r Mapy.new(r).show_addresses_whih_city(r) }, } ) ) Obrázek 4.3: Příklad rámce z domény pro mapy Prvky těla rámce mají následující význam: :frame_name => 'JMÉNO_RAMCE' určuje název rámce. Pojmenování je pak důležité pro další manipulaci s rámcem, např. v části lower_frames (upper_frames). :weight => dec označuje váhu pro zpracování rámce, dec je desetinné číslo v intervalu <0,1>. :attrs => [ pole Frameltems ] obsahuje pole požadovaných neterminálů z gramatiky pro zpracování rámcem. V rámci jednoho prvku můžeme definovat název neterminálů, jakou hodnotu nabude prvek pole, pokud nebylo možné daný neterminál použít a váhu, kterou se vynásobí celková váha, pokud nemohl být neterminál použit. Z příkladu vyplýva, že dotaz musí obsahovat části odvoditelné z neterminálů ASIMAPA a ASIOBEC, protože pokud by tomu tak nebylo, výsledná váha by klesla na 0 a data by nebyla uznána za korektní pro tento rámec. Oproti tomu neterminál ASIULICE je nepovinný a pokud ho nelze aplikovat, sníží se váha na polovinu a pole bude obsahovat v odpovídajícím prvku prázdný řetězec. :lower_frames => [ pole frame_names ] definuje na podmnožině rámců uspořádání. Rámce uvedené v seznamu mohou pracovat se stejným dotazem jako nadřazený rámec, jejich odpověď je však zpravidla obecnější. Proto mají při zpracování menší prioritu. Opačně můžeme místo klíče :lower_frames použít :upper_frames, tato konstrukce naopak určuje množinu nadřazených rámců danému frame. :action => akce poskytuje reakci na dotaz vyhovující danému rámci, v tomto případě funkci definovanou v dalším těle domény. 18

4.2. METODIKY POUŽITÉ PŘI PRÁCI ROZŠIŘOVÁNÍ FUNKČNOSTI UIO Naprogramované funkce Tato sekce obsahuje funkce nezbytné pro fungování dotazování nad danou doménou. Mohou to být výstupní nebo pouze s daty pracující funkce. Zápisy všech musí odpovídat syntaxi jazyka Ruby. 4.2.2.3 Testování v průběhu vývoje Když se při své práci dostaneme do takové fáze vývoje, kdy bychom chtěli otestovat funkčnost dané gramatiky, jsou k dispozici dva způsoby. Prvním z nich je použití řádkového klienta, který komunikuje s testovacím parserem. Spuštěním aplikace testparser.rb s potřebnými parametry dostáváme na svoje dotazy odpovědi podle toho, jak jsou zpracovány gramatikou. Lze volit také mezi debugačním a stručným" módem. Příkladem užití může být:./testparser.rb -D mapy -D kultura context /tmp/mapy.context -d kde parametr -D určuje domény, které chceme testovat, context je soubor s kontextem a -d značí, že chci testovat v debugačním módu, tedy režimu, kde je podrobně popsána veškerá práce gramatiky na dotazu. Existuje také speciální debugační doména debug, kterou, když spustíme s ostatními požadovanými gramatikami, můžeme ovládat debugační mód přímo v rámci dialogu s testovacím parserem výrazy jako např. zapni debug" nebo vypni debug". Další možností, jak testovat gramatiku, je využití komunikace se serverem, kde máme k dispozici také grafické rozhraní. Po spuštění serveru tedy můžeme zadávat dotazy webové aplikaci za použití prohlížeče. To je velmi výhodné, pokud je odpovědí na dotaz např. webová stránka, jako je tomu v případě dotazování na mapy. Je tedy možné si ihned otestovat správnost utvoření URL apod. Server je spouštěn programem uiiserver.rb s parametry stejnými, jako je tomu u testovacího parseru. 19

Kapitola 5 Domény pro dotazování na mapách a převody 5.1 Doména Mapy 5.1.1 Zadání Úkolem bylo vytvořit systém, který reaguje na dotazy v přirozeném jazyce, týkajících se vyhledávání ulic, obcí a měst na mapách. Odpovědi se měli zobrazovat ve formě mapy, zobrazující relevantní informace požadované dotazem. Systém pracuje se dvěma nejvyužívanějšími aplikacemi v oboru na internetu v Česku na serverech centrum.cz 1 a mapy.cz. 2 Uživatel zasílá požadavky oběma aplikacím vyplněním formuláře. Poskytnutá data potom aplikace umístí na příslušné místo URL, kterému odpovídá mapa s požadovanými údaji. 5.1.2 Řešení problému Pro nejpřesnější možnou funkčnost systému bylo nutné zpracovat rozsáhlou databázi ulic a měst České republiky. Ta byla k dispozici ve formátu CSV (Comma Separated Value). CSV je textový soubor, reprezentující databázovou tabulku. Řádek souboru je jeden záznam tabulky a jednotlivé atributy jsou odděleny jedním konkrétním znakem, například čárka, tabulátor atp. Proto jsou tyto soubory jednoduše zpracovatelné i pomocí regulárních výrazů. Data obsažená v CSV souborech jsem tedy převedl do formy, se kterou mohl pracovat dotazovací systém, tedy do mwe formátu. Před samotnou implementací gramatiky bylo nutné stanovit si množinu otázek. Podle ní jsem pak sestavil odpovídající množinu pravidel. Po jisté době jsem se však s počáteční sadou otázek natolik ztotožnil, že jsem již nebyl schopen sám gramatiku funkčně rozšířit. Z tohoto důvodu je velmi důležité spolupracovat se skupinou lidí, kteří jsou schopni nezávisle poskytovat nové podněty, nové možné dotazy. Na základě těchto poznatků se systém stal robustnější a dokáže reagovat na širokou škálu dotazů. Protože odpovědí na dotaz měla být mapa požadovaného objektu, musel soubor s doménou implementovat pouze jednu důležitou funkci, která dokáže z poskytnutých dat sestavit relevantní URL pro obě používané aplikace. Při zkoumání postupů pro tvorbu adresy na http://mapy.centrum.cz jsem však zjistil nový potřebný algoritmus, určování ID objektu, ten bylo nutné v doméně také použít. Na závěr byly vytvořeny frames, které se snaží roz- 1. http://mapy.centrum.cz/ 2. http://www.mapy.cz/ 20

5.2. DOMÉNA PŘEVODY poznat dotaz na vyhledávání v mapách i přesto, že nebyl rozpoznán gramatikou. Základní postup spočívá ve stanovení určujícího neterminálu a neterminálů, které poskytují pro zpracování potřebná data. Protože existuje předpoklad, že systém bude muset pracovat pro více domén současně, musí určující neterminál striktně definovat věty, které jsou s určitou pravděpodobností dotazem nad mapami. Otázka zpracovaná rámci tedy musí obsahovat výrazy jako mapa", na mapě", kde je" apod. Pro určení odpovědi se potom využívá neterminálů, které se postupně přepíší na údaj o lokalitě. 5.2 Doména Převody 5.2.1 Zadání Základní myšlenkou při implementaci této domény bylo vytvořit systém, který je schopen zpracovat dotazy týkající se vzájemných převodů jednotek fyzikálních veličin. Systém musí umět rozpoznat z věty o jaké jednotky se jedná, číselné údaje vztahující se k jednotkám a zda je možné jednotky mezi sebou vůbec převádět. Odpovědí už není žádná webová stránka, ale přímo výsledek výpočtu ve srozumitelné formě. Při budování systému byla použita data ze stránek věnovaných aplikaci converter a převodům jednotek. 3 V praxi je tento problém na internetu nesčetněkrát zpracován, zpravidla však formou selekčních tabulek. 4 5.2.2 Řešení problému Získání dat pro práci s doménou Převody bylo ve srovnání s mapami o to jednodušší, že rozsah dat není tak obsáhlý a podobnou problematikou se zabývá mnoho webových aplikací. Data jsou dostupná ve formátu HTML, to umožňuje velmi snadný parsing. Pro určitou standardizaci postupu a kvůli přehlednému uchování dat za účelem možného pozdějšího dalšího zpracování jsem data z tabulek v HTML převedl do CSV, odkud potom jednoduše do formátu mwe. Gramatika je ve srovnání s mapami o dost jednodušší, spektrum dotazů není tak široké. Musíme pouze zjistit, mezi jakými jednotkami se má převádět, popř. ještě číselné údaje, veškeré další funkce jsou implementovány v doméně. Doména kromě rámců, jejichž funkčnost snad již není třeba popisovat obsahuje stěžejní metodu, která implementuje vlastní převody. Tato procedura se skládá ze dvou základních kroků. Jsou to: určení vzájemné převoditelnosti jednotek vlastní převod užitím převodních koeficientů Data v mwe souboru totiž obsahují informace o tom, k jaké veličině se daná jednotka vztahuje a jaký je poměr mezi konkrétní jednotkou a jednotkou základní pro danou veličinu. 3. http://www.converter.cz/ 4. http://www.prevod.cz/ 21

5.3. STATISTIKY Musíme proto kontrolovat, zda jsou jednotky vyjádřením stejné nebo aspoň principielně podobné veličiny. Principielně podobné znamená, že subjektivním vyhodnocením můžeme zjistit, že některé veličiny mají sice různá označení, ale jejich podstata je stejná. Např. můžeme vzájemně převádět typografické a délkové jednotky, protože obě označuje ve své podstatě nějakou vzdálenost. Z toho plyne, že při kontrole shody veličin mohou nastat i výjimky, které je nutno zpracovat. Transformace pomocí převodních koeficientů vůči základní jednotce je snadná, vzájemným porovnáním získáme výsledný koeficient. 5.3 Statistiky 5.3.1 Doména Mapy Doména mapy byla testována sadou otázek cca 6 nezávislých potenciálních uživatelů, z nichž každý zadal v průměru 15 otázek. Statistiky vyhodnocení dotazů jsou uvedeny v tabulce na obrázku 5.1. Výsledek Upřesnění Úspěšnost Zcela korektní podle gramatiky 29% podle rámců 5% Úplně špatně nerozpoznáno MWE 3% nerozpoznaný dotaz 10% Více odpovědí, alespoň 1 korektní jedna korektní 20% více korektních 3% Dotaz nepatřící do domény 30% Obrázek 5.1: Statistiky dotazů nad doménou Mapy Relativně nízká úspěšnost systému je dána především velkým množstvím dotazů, které nebyly přímo směrovány do oblasti, kterou se systém zabývá, nebo odpovědi nebyly jednoznačné. První je způsobeno velkým množstvím dotazů (cca 20% z celkového množství), které byly směrovány na konkrétní objekty na mapách. Toto ovšem není součástí zpracování domény a proto systém nemůže znát odpověď. Z četnosti těchto dotazů ovšem vyplývá značná poptávka a proto může být dotazování na objekty na mapách dalším funkčním rozšířením v rámci této domény. Nejednoznačnost odpovědí spočívá v jejich velkém množství, to může mít několik důvodů. Hlavní dva jsou nejednoznačnost vyhledání odpovídajícího víceslovného výrazu reprezentujícího název města nebo obce a duplicity v knihovně MWE. Při zpracování dotazu pomocí rámců probíhá vyhledávání všech možných názvů měst a obcí v dotazu a kvůli rozsáhlé databázi názvů se může stát, že je i nerelevantní slovo vy- 22

5.3. STATISTIKY hodnoceno jako jméno obce nebo ulice. Oproti tomu duplicity v knihovně MWE jsou přejaty z původních databází, jejich odstranění musí probíhat ručně. Jedná se o příklady špatného gramatického zápisu některých lokalit, příkladem je Náměstí svobody vs. náměstí Svobody. Nerozpoznané dotazy jsou takové, které se nepodařilo zpracovat gramatice ani rámcům, nerozpoznáno MWE mohou být sice dotazy, které lze vygenerovat gramatickými pravidly, hodnoty na pozicích MWE však nejsou v databázi. Z uvedeného vyplývá, že vypracovaná gramatika s doménou jsou poměrně přesně zpracovány, problém ovšem většinou nastává, pokud potřebujeme aplikovat rámce. Samostný systém UIO totiž zatím nepracuje správně s prioritami pravidel v gramatice a tím pádem může dojít k násobnému vyhodnocení výrazu, kde většina prvků výstupu není relevantní dotazu. Protože je databáze názvů ulic, měst a obcí velmi rozsáhlá a frame hledá ve větě neterminály pro odvození odpovědi, může dojít ke shodě na nežádoucím místě a proto i k nárůstu množství odpovědí. 5.3.2 Doména Převody Převodní doména byla stejně jako doména o mapách testována na sadě otázek sestavené nezávislými uživateli. Procentuální vyjádření zpracování dotazů je uvedeno v tabulce na obrázku 5.2. Výsledek Upřesnění Úspěšnost Zcela korektní podle gramatiky 52% podle rámců 6% Úplně špatně nerozpoznáno MWE 5% nerozpoznaný dotaz 9% Více odpovědí, alespoň 1 korektní jedna korektní 18% více korektních 4% Dotaz nepatřící do domény 6% Obrázek 5.2: Statistiky dotazů nad doménou Převody Poměrně vysoká úspěšnost zpracování dotazů gramatikou je dána tím, že neexistuje příliš mnoho možností, jak se na převody dotazovat. Gramatika tedy pokrývá většinu možných dotazů. Rámce se snaží odchytit některé další konstrukce dotazu a jsou doplňkovým prvkem pro zpracování otázek na nesmyslné převody. Většina používaných jednotek fyzikálních veličin je obsažena v databázi a proto zůstává poměrně málo dotazů, kde by MWE nerozuměl požadovaným víceslovným výrazům. Stále je ovšem relativně rozsáhlá množina dotazů, kde dochází k více možnostem zpracování mwe údajů, protože jména základních 23