České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Diplomová práce
Zpracování textu v přirozeném jazyce
Adam Slavický
Vedoucí práce: Ing. Martin Molhanec, CSc.
Studijní program: Elektrotechnika a informatika, navazující magisterský Obor: Výpočetní technika 13. května 2010
2
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Praze dne 14.5.2010.
______________________________________________
3
4
Abstract It is an object of the present master thesis to propose a method for modelling natural language with the purpose of machine translation. A further object of the thesis is to design and implement an application allowing embodiment of this modelling method and translation of text in natural language based on the said method. The translation is based on applying user-defined formal rules of context-free attribute grammar for any natural language and the use of a language-independent symbolic representation of meaning (interlingua). The interlingua is implemented as an ontology. The method of modelling natural language has its theoretical foundation in the theory of valency.
Abstrakt Předmětem této diplomové práce je navrhnout způsob modelování přirozeného jazyka za účelem strojového překladu. Dalším předmětem této práce je navrhnout a implementovat aplikaci umožňující realizaci tohoto způsobu modelování a překladu textu v přirozeném jazyce na základě tohoto způsobu. Překlad je založen na aplikaci uživatelsky zadaných formálních pravidel bezkontextové atributové gramatiky pro jakýkoli přirozený jazyk a využití jazykově nezávislé symbolické reprezentace významu (interlingua). Interlingua je realizována jako ontologie. Způsob modelování přirozeného jazyka je teoreticky založen na valenční teorii.
5
6
Obsah ABSTRACT ........................................................................................................................................... 5 ABSTRAKT ........................................................................................................................................... 5 OBSAH ................................................................................................................................................... 7 1.
TEORETICKÁ ČÁST ................................................................................................................ 15
1.1
Počítačová podpora pro překlad ................................................................................................................. 15
1.2
Typy strojového překladu .............................................................................................................................. 15
1.3
Dosavadní stav techniky ................................................................................................................................. 16
1.4 Vybrané jazykové jevy ..................................................................................................................................... 16 1.4.1 Homonymie a polysémie............................................................................................................................................... 16 1.4.2 Shoda ..................................................................................................................................................................................... 17 1.4.3 Obligatornost a fakultativnost .................................................................................................................................... 18 1.4.4 Morfologické jevy ............................................................................................................................................................. 18 1.5 Funkční generativní popis (FGP) ................................................................................................................. 19 1.5.1 Formální popisy jazyka.................................................................................................................................................. 19 1.5.2 Roviny popisu .................................................................................................................................................................... 20 1.5.3 Vztah forma-funkce ......................................................................................................................................................... 20 1.5.4 Morf a morfém ................................................................................................................................................................... 20 1.5.5 Lexém, lexikální forma, lexikální jednotka, lemma ........................................................................................... 20 1.6
Valenční teorie ................................................................................................................................................... 21
1.7
Větné vzorce ........................................................................................................................................................ 21
2.
ÚVODNÍ STUDIE ...................................................................................................................... 23
2.1 Požadavky na systém ....................................................................................................................................... 23 2.1.1 Požadavky na systém z hlediska rozsahu.............................................................................................................. 23 2.1.2 Požadavky na systém z uživatelského hlediska.................................................................................................. 23 2.1.3 Požadavky na systém z lingvistického hlediska ................................................................................................. 23 2.1.4 Návrh řešení uživatelských požadavků.................................................................................................................. 24 2.1.5 Návrh řešení lingvistických požadavků ................................................................................................................. 24 2.1.5.1 Formalismus pro lexikální reprezentaci ..................................................................................................... 24 2.1.5.2 Formalismus pro sémantickou reprezentaci ............................................................................................ 24 2.1.5.3 Formalismus gramatických kategorií ........................................................................................................... 24 2.1.5.4 Reprezentace vět a ontologií ............................................................................................................................ 25 2.1.5.5 Morfologická reprezentace ............................................................................................................................... 25 2.1.5.6 Aplikace pravidel CFG a AG ............................................................................................................................... 25 2.1.5.7 Řešení víceznačnosti ............................................................................................................................................ 25 2.2
3. 3.1
Odborný článek .................................................................................................................................................. 26
ANALÝZA ................................................................................................................................... 28 Architektura systému ...................................................................................................................................... 28
7
3.1.1 3.1.2 3.2
Webový server................................................................................................................................................................... 29 Databáze ............................................................................................................................................................................... 29 Deployment diagram ....................................................................................................................................... 29
3.3 Entity pro jazykově nezávislý popis ........................................................................................................... 30 3.3.1 Séma (Sema) ....................................................................................................................................................................... 30 3.3.1.1 Odvození (Derive) ................................................................................................................................................. 30 3.3.1.2 Test ISA ...................................................................................................................................................................... 30 3.3.1.3 Odvození a odpojení ............................................................................................................................................. 30 3.3.1.4 Smazání ...................................................................................................................................................................... 30 3.3.2 Sémantická valence (SemanticValency)................................................................................................................. 31 3.3.2.1 Smazání ...................................................................................................................................................................... 31 3.4 Entity pro jazykově závislý popis ................................................................................................................ 31 3.4.1 Jazyk (Language) .............................................................................................................................................................. 31 3.4.1.1 Nastavení aktuálního jazyka............................................................................................................................. 31 3.4.1.2 Smazání jazyka ....................................................................................................................................................... 31 3.4.2 Typ morfu (MorphType) ............................................................................................................................................... 31 3.4.2.1 Odstranění typu morfu........................................................................................................................................ 31 3.4.3 Morf (Morph) ..................................................................................................................................................................... 32 3.4.3.1 Odstranění morfu .................................................................................................................................................. 32 3.4.4 Atribut (Attribute) ........................................................................................................................................................... 32 3.4.4.1 Smazání atributu.................................................................................................................................................... 32 3.4.5 Hodnota atributu (AttributeValue) .......................................................................................................................... 32 3.4.5.1 Smazání hodnoty atributu ................................................................................................................................. 32 3.4.6 Přiřazení hodnot atributů (MorphAssignment, MorphTypeAssignment) .............................................. 32 3.4.7 Lexikální vzor (LexicalPattern).................................................................................................................................. 33 3.4.7.1 Editace vzoru ........................................................................................................................................................... 33 3.4.7.2 Smazání vzoru ......................................................................................................................................................... 33 3.4.8 Lexém (Lexeme) ............................................................................................................................................................... 33 3.4.8.1 Nalezení lexému podle hodnot morfů (LEXMATCH) ............................................................................. 33 3.4.8.2 Smazání lexému ..................................................................................................................................................... 34 3.4.9 Lexikální jednotka (LexicalUnit) ............................................................................................................................... 34 3.4.9.1 Strom lexikálních jednotek ............................................................................................................................... 34 3.4.9.2 Test ISA ...................................................................................................................................................................... 34 3.4.9.3 Smazání lexikální jednotky ............................................................................................................................... 34 3.4.10 Lexikální valence (LexicalValency) .......................................................................................................................... 34 3.4.10.1 Smazání lexikální valence............................................................................................................................. 35 3.5 Entity pro specifikaci gramatiky ................................................................................................................. 35 3.5.1 Neterminál (Nonterminal) ........................................................................................................................................... 35 3.5.1.1 Smazání neterminálu ........................................................................................................................................... 35 3.5.2 Pravidlo CFG (Rule) ......................................................................................................................................................... 35 3.5.3 Symbol (Symbol) .............................................................................................................................................................. 35 3.5.4 Symbol neterminálu (NontermSymbol)................................................................................................................. 36 3.5.5 Symbol morfu (MorphSymbol) .................................................................................................................................. 36 3.5.6 Symbol separátoru (SeparatorSymbol) ................................................................................................................. 36 3.5.7 Pravidlo AG (Agrule) ....................................................................................................................................................... 36 3.5.8 Příkaz AG (AgruleCommand)...................................................................................................................................... 37 3.5.8.1 Editace příkazů AG ................................................................................................................................................ 37 3.5.9 Příkaz deklarace dočasné proměnné (AgcDeclare) .......................................................................................... 37 3.5.9.1 Dočasná proměnná (AgVariable) ................................................................................................................... 38 3.5.10 Příkaz přiřazení proměnné (AgcAssign)................................................................................................................ 38 3.5.11 Příkaz přiřazení hodnoty atributu (AgcAsgaval) ............................................................................................... 39 3.5.12 Příkaz porovnání hodnoty atributu (AgcCmpaval)........................................................................................... 39 3.5.13 Příkaz porovnání s lexémem (AgcCmplex) ........................................................................................................... 39 3.5.14 Příkaz lexikálního vyhledání (AgcLexmatch) ...................................................................................................... 40 3.5.15 Příkaz testu shody (AgcGovern) ................................................................................................................................ 40
8
3.5.16 Příkaz testu ISA lexikální jednotky (AgcIsa) ........................................................................................................ 41 3.6 Model entit pro popis gramatiky ................................................................................................................. 41 3.6.1 Class diagram ..................................................................................................................................................................... 41 3.6.2 Popis vazeb ......................................................................................................................................................................... 41 3.7 Entity pro popis překladu .............................................................................................................................. 41 3.7.1 Pravidlo překladu (TransRule) .................................................................................................................................. 41 3.7.2 Příkaz TR (TransCommand) ....................................................................................................................................... 42 3.7.2.1 Editace příkazů TR ................................................................................................................................................ 42 3.7.3 Příkaz deklarace dočasné proměnné (TrcDeclare)........................................................................................... 42 3.7.3.1 Dočasná proměnná (TransVariable)............................................................................................................. 43 3.7.4 Příkaz přiřazení proměnné (TrcAssign) ................................................................................................................ 43 3.7.5 Příkaz porovnání hodnoty atributu (TrcCmpaval) ........................................................................................... 43 3.7.6 Příkaz testu ISA lexikální jednotky (TrcIsaLexunit) ......................................................................................... 44 3.7.7 Příkaz testu ISA sématu (TrcIsaSema) ................................................................................................................... 44 3.7.8 Příkaz překladu (TrcTranslate) ................................................................................................................................. 44 3.7.9 Abstraktní datový model .............................................................................................................................................. 45 3.8 Specifikace parseru .......................................................................................................................................... 47 3.8.1 Parsing .................................................................................................................................................................................. 47 3.8.2 Překlad .................................................................................................................................................................................. 47 3.8.3 Zpětný překlad .................................................................................................................................................................. 47 3.8.4 Rekonstrukce ..................................................................................................................................................................... 48 3.9 Specifikace funkcionality systému .............................................................................................................. 48 3.9.1 Jazykově nezávislý popis .............................................................................................................................................. 49 3.9.2 Jazyk ....................................................................................................................................................................................... 49 3.9.3 Morfologie ........................................................................................................................................................................... 49 3.9.4 Lexikon.................................................................................................................................................................................. 49 3.9.5 Popis gramatiky ................................................................................................................................................................ 49 3.9.6 Popis překladu ................................................................................................................................................................... 50 3.10
4.
Specifikace funkcionality překladu ............................................................................................................ 50
IMPLEMENTACE ..................................................................................................................... 51
4.1 Architektura systému jako serverové aplikace ..................................................................................... 51 4.1.1 Programovací jazyk PHP 5 ........................................................................................................................................... 51 4.1.2 Relační databáze MySQL ............................................................................................................................................... 51 4.1.3 E-R diagram ........................................................................................................................................................................ 52 4.2 Vysvětlení vazeb E-R diagramu .................................................................................................................... 53 4.2.1 Popis vazeb ......................................................................................................................................................................... 53 4.3 Databázová realizace ....................................................................................................................................... 53 4.3.1 Příkaz atributové gramatiky (agcmd) ..................................................................................................................... 53 4.3.2 Pravidlo AG (agrule) ....................................................................................................................................................... 54 4.3.3 Dočasná proměnná pravidla AG (agvar)................................................................................................................ 55 4.3.4 Atribut (attr)....................................................................................................................................................................... 55 4.3.5 Hodnota atributu (aval) ................................................................................................................................................ 55 4.3.6 Odvození sématu (derive) ............................................................................................................................................ 55 4.3.7 Jazyk (lang) ......................................................................................................................................................................... 55 4.3.8 Lexém (lexeme)................................................................................................................................................................. 55 4.3.9 Lexikální vzor (lexpat) ................................................................................................................................................... 55 4.3.10 Lexikální jednotka (lexunit) ........................................................................................................................................ 56 4.3.11 Lexikální valence (lexval) ............................................................................................................................................. 56 4.3.12 Morf (morph) ..................................................................................................................................................................... 56
9
4.3.13 4.3.14 4.3.15 4.3.16 4.3.17 4.3.18 4.3.19 4.3.20 4.3.21 4.3.22 4.3.23 4.3.24
Přiřazení hodnoty morfu (morphasg) .................................................................................................................... 56 Typ morfu (morphtype) ................................................................................................................................................ 56 Přiřazení hodnoty typu morfu (mtasg) .................................................................................................................. 56 Neterminál (nonterm) ................................................................................................................................................... 57 Pravidlo CFG (rule) .......................................................................................................................................................... 57 Séma (sema) ....................................................................................................................................................................... 57 Sémantická valence (semaval) ................................................................................................................................... 57 Session (sess) ..................................................................................................................................................................... 57 Symbol pravé strany (symbol) ................................................................................................................................... 57 Příkaz překladového pravidla (transcmd) ............................................................................................................ 58 Relace překladu (translate) ......................................................................................................................................... 58 Překladová proměnná (transvar) ............................................................................................................................. 59
4.4 Entity pro parsing.............................................................................................................................................. 59 4.4.1 Lexer ...................................................................................................................................................................................... 59 4.4.2 Parser..................................................................................................................................................................................... 59 4.4.3 Symbol pravidla (Symbol) ............................................................................................................................................ 60 4.4.4 Morph .................................................................................................................................................................................... 61 4.4.5 Nonterm ............................................................................................................................................................................... 61 4.4.6 Separator.............................................................................................................................................................................. 61 4.4.7 Objekt gramatiky (Grammar) ..................................................................................................................................... 61 4.4.8 Item......................................................................................................................................................................................... 61 4.4.9 Item morfu (MorphItem) .............................................................................................................................................. 62 4.4.10 Item separátoru (SeparatorItem) ............................................................................................................................. 62 4.4.11 Item neterminálu (NontermItem) ............................................................................................................................ 63 4.4.12 Instance lexému (Lexeme) ........................................................................................................................................... 63 4.4.13 Lexikální vektor (LexVector) ...................................................................................................................................... 64 4.5 Model entit pro parsing................................................................................................................................... 65 4.5.1 Class diagram ..................................................................................................................................................................... 65 4.5.2 Vysvětlení vazeb ............................................................................................................................................................... 65 4.6 Algoritmus parsingu......................................................................................................................................... 66 4.6.1 Metoda NontermItem::receive ..................................................................................................................................... 70 4.6.2 Aplikace pravidel AG....................................................................................................................................................... 70 4.7 Entity pro rekonstrukci .................................................................................................................................. 71 4.7.1 Reverzní item (RevItem)............................................................................................................................................... 71 4.7.2 Reverzní item morfu (MorphRev) ............................................................................................................................ 71 4.7.3 Reverzní item neterminálu (NontermRev)........................................................................................................... 72 4.7.4 Nulový reverzní item (NullRev)................................................................................................................................. 72 4.7.5 Kontejner reverzních itemů (RevContainer) ....................................................................................................... 72 4.8 Algoritmus rekonstrukce ............................................................................................................................... 72 4.8.1 Metoda NontermRev::reconstruct ............................................................................................................................ 73 4.8.2 Metoda MorphRev::reconstruct................................................................................................................................. 74 4.8.3 Reverzní aplikace příkazu LEXMATCH ................................................................................................................... 74 4.9 Algoritmus překladu ........................................................................................................................................ 75 4.9.1 Kontejner pro překlad (TransContainer) .............................................................................................................. 75 4.9.2 Popis algoritmu ................................................................................................................................................................. 75 4.10
Algoritmus zpětného překladu .................................................................................................................... 76
4.11 Funkcionalita uživatelského rozhraní ...................................................................................................... 77 4.11.1 Oddělení prezentace od datového modelu ........................................................................................................... 77 4.11.2 Ošetření vstupů ................................................................................................................................................................. 78 4.12
Příklad naplnění ................................................................................................................................................ 78
10
4.12.1 Morfologie ........................................................................................................................................................................... 78 4.12.1.1 Introflexe ............................................................................................................................................................. 78 4.12.1.2 Reduplikace ........................................................................................................................................................ 79 4.12.2 Gramatika ............................................................................................................................................................................ 79
5.
ANALÝZA RIZIK ....................................................................................................................... 82
5.1 Seznam rizik ........................................................................................................................................................ 82 5.1.1 Rizika spojená s rozsahem produktu ...................................................................................................................... 82 5.1.2 Rizika obchodního dopadu .......................................................................................................................................... 82 5.1.3 Procesní rizika ................................................................................................................................................................... 82 5.1.4 Technické otázky .............................................................................................................................................................. 83 5.1.5 Rizika spojená s vývojovým týmem ......................................................................................................................... 83 5.2
Vyhodnocení rizik ............................................................................................................................................. 83
5.3
Návrhy na zmírnění rizik................................................................................................................................ 84
6.
TESTOVÁNÍ............................................................................................................................... 85
6.1
Black-box testing ............................................................................................................................................... 85
6.2 Návrh testů........................................................................................................................................................... 85 6.2.1 Test 1: test jazykového popisu ................................................................................................................................... 85 6.2.2 Test 2: test ověřování vstupů z GUI ......................................................................................................................... 85 6.3 Provedení testů .................................................................................................................................................. 85 6.3.1 Test 1: test jazykového popisu ................................................................................................................................... 85 6.3.2 Test 2: kontrola správnosti vstupů .......................................................................................................................... 87 6.3.2.1 Test integritního omezení při smazání ........................................................................................................ 87 6.3.2.2 Test správného zadání pravidla AG............................................................................................................... 88 6.4
7.
Vyhodnocení testů ............................................................................................................................................ 89
ZÁVĚR ........................................................................................................................................ 90
7.1
Dosažené cíle....................................................................................................................................................... 90
7.2
Výhled .................................................................................................................................................................... 90
8.
LITERATURA............................................................................................................................ 91
9.
SEZNAM ZKRATEK ................................................................................................................. 92
10.
INSTALACE A KONFIGURACE ......................................................................................... 93
10.1.1 Instalace podpůrného softwaru................................................................................................................................. 93 10.1.2 Instalace aplikace ............................................................................................................................................................. 93
11.
UŽIVATELSKÁ PŘÍRUČKA................................................................................................ 94
11.1
Přihlášení do systému ..................................................................................................................................... 94
11.2
Orientace v systému ......................................................................................................................................... 94
11
11.3 Uživatelské informace ..................................................................................................................................... 94 11.3.1 Překlad .................................................................................................................................................................................. 95 11.4
Jazyky ..................................................................................................................................................................... 96
11.5 Morfologie ............................................................................................................................................................ 97 11.5.1 Typy morfů .......................................................................................................................................................................... 97 11.5.2 Morfy ...................................................................................................................................................................................... 98 11.6 Atributy a hodnoty ............................................................................................................................................ 99 11.6.1 Atributy................................................................................................................................................................................. 99 11.6.2 Hodnoty atributů .............................................................................................................................................................. 99 11.7 Gramatika ...........................................................................................................................................................100 11.7.1 Přehled pravidel ............................................................................................................................................................ 100 11.7.2 Editace symbolu ............................................................................................................................................................. 100 11.7.3 Detail pravidla ................................................................................................................................................................ 101 11.7.4 Detail příkazu .................................................................................................................................................................. 101 11.8 Lexikon ................................................................................................................................................................102 11.8.1 Lexikální vzory ............................................................................................................................................................... 102 11.8.2 Lexémy ............................................................................................................................................................................... 103 11.8.3 Lexikální jednotky......................................................................................................................................................... 103 11.8.4 Editace příkazu překladu ........................................................................................................................................... 105 11.8.5 Lexikální valence ........................................................................................................................................................... 105 11.9 Sémantika...........................................................................................................................................................105 11.9.1 Sémata ................................................................................................................................................................................ 105 11.9.2 Sémantické valence ...................................................................................................................................................... 106
OBSAH PŘILOŽENÉHO CD .........................................................................................................107
12
13
14
1. Teoretická část Tato kapitola se nejprve zabývá motivací pro strojový překlad zejména odborných textů. Rozčleňuje metody strojového překladu do tříd, uvádí dosavadní stav techniky s výhodami a nevýhodami hlavních v současnosti existujících aplikací a formuluje požadavky na systém pro strojový překlad. Mezi ně patří jak funkční požadavky, tak i požadavky na řešení určitých lingvistických problémů, se kterými se setkáváme v oblasti strojového překladu a zpracování přirozeného jazyka jako takového. Diplomová práce si bere jako teoretický základ funkční generativní popis jazyka (FGP) a valenční teorii větných vzorců. Kapitola tedy dále pokračuje stručnými popisy těchto modelů jazyka a terminologie, která se k těmto formalismům váže.
1.1 Počítačová podpora pro překlad Překládání textů mezi různými jazyky je v dnešním globalizovaném světě nezbytností. Texty, které se nejvíce překládají, jsou zejména odborného charakteru (vědecké, průmyslové, právní apod.), zatímco na krásnou literaturu, která je pro překlad nejobtížnější, spadá jen 0,3 % [1]. Například Generální ředitelství pro překlady Evropské komise (Directorate-General for Translation of the European Commission) zaměstnává 1600 překladatelů a jen v roce 2004 vyprodukovalo 1 270 586 stránek formátu A4 překladů [2]. Překlad odborných textů je tedy velmi vyhledávanou a lukrativní disciplínou. Pro svou větší schematičnost jsou odborné texty vhodné pro zpracování nástroji CAT (Computer-Assisted Translation, překlad podporovaný počítačem). Například podle výzkumu mezi jazykovými profesionály [3] v roce 2006 až 82 % uživatelů používá nástroje s překladovou pamětí (translation memory, TM) což jsou nástroje umožňující správu segmentů textu ve zdrojovém jazyce a cílovém jazyce (jazycích). Ještě lákavější se jeví možnost strojového překladu (machine translation, MT), která by překlad odborných textů vyřešila úplně.
1.2 Typy strojového překladu Způsoby MT lze hrubě rozdělit na metody překladu pomocí pravidel (rule-based) a statistické metody. Statistické metody obvykle využívají velkých bilinguálních korpusů a metodu „hrubé síly“. Laicky řečeno, čím rozsáhlejší jsou korpusy, tím větší je pravděpodobnost korektnosti výsledného překladu. Přes svou relativní úspěšnost statistické metody textu v žádném smyslu „nerozumějí“. Překlad pomocí pravidel naopak simuluje gramatiku jazyků, je lingvisticky čistší a uživatelsky průhlednější, ačkoli administrátorská práce s ním je výrazně pracnější. Překlad (ať už statistický nebo pomocí pravidel) může být realizován buďto mezi jazykovými páry nebo nebo prostřednictvím jazykově nezávislé sémantické reprezentace (interlingua). Překlad mezi jazykovými páry sice obchází nutnost symbolické reprezentace, jejíž konstrukce je z různých důvodů problematická, avšak je náročnější na údržbu: pro překlad mezi libovolnými n jazyky je zapotřebí n(n-1) jednosměrných překladačů; naproti tomu při využití symbolické reprezentace je zapotřebí pouze 2n jednosměrných překladačů. 15
1.3 Dosavadní stav techniky V současnosti neexistují uspokojivé nástroje pro plně automatický strojový překlad textu, na který nejsou kladeny žádné další nároky. Pro zúžené tematické okruhy však jsou např. u statistických metod k dispozici rozsáhlé korpusy, což způsobuje relativně vysokou efektivnost aplikací využívajících statistických metod ve strojovém překladu odborných textů. Mezi nejznámější bezplatné online MT nástroje patří Google Translate a systém Systran, který dále tvoří základ nástrojů Microsoft Bing Translator a Yahoo! Babel Fish. Všechny tyto systémy pracují na statistické bázi a překlady se realizují mezi jazykovými páry. U Google Translate se v případě nedostatečných dat pro realizaci překladu v rámci jazykového páru používá převod přes mezijazyk, kterým často bývá angličtina. Tento typ překladu připomínající překlad pomocí interlingui se označuje jako překlad s transferem. Uvedené statistické systémy spojuje to, že ačkoliv jsou vhodné pro základní orientaci uživatele, který nerozumí zdrojovému textu, dělají často zcela základní chyby v gramatice daného jazyka, a to ze své samotné definice – nepřistupují k textu systematicky. Text v přirozeném jazyce je inherentně víceznačný a častým úkolem překladatele je rozhodovat se mezi různými možnostmi výsledného překladu. Uvedené nástroje však nabízejí pouze jednu možnost výstupního překladu. Toto je opět vhodné pro uživatele, který nerozumí zdrojovému textu, zatímco překladatel (u něhož předpokládáme znalost jak zdrojového, tak cílového jazyka) by měl obdržet veškeré vhodné překlady a z nich si poté vybrat. To, že statistický systém nerozumí textu, má ještě jednu implikaci: nedovede odlišit korektní text od nekorektního. Vstupní text, který nedává žádný smysl, tedy přesto „přeloží“. Až na výjimky jsou tyto systémy uzavřeny, tj. vyvíjí je firma či výzkumný institut. Uživatel tedy nemá možnost do nich zasáhnout a pozměnit chování systému, pokud není s překladem spokojen.
1.4 Vybrané jazykové jevy Překlad přirozeného jazyka je nesmírně rozsáhlá problematika. Vybíráme tedy některé hlavní problémy, které očekáváme, že požadovaný systém bude řešit.
1.4.1 Homonymie a polysémie Problém homonymie (víceznačnosti) je jedním z centrálních problémů překladu a počítačového zpracování jazyka jako takového [4]. Vyřešení mnohoznačnosti (ambiguity) se označuje jako desambiguace. Není-li desambiguaci z nejrůznějších důvodů možné provést, je třeba uživatele alespoň upozornit o přítomnosti homonymie, aby na tento fakt mohl adekvátně reagovat – to je právě významný problém, který výše uvedené aplikace neřeší.
16
Případ, kdy homonymii není prostředky strojového (ani žádného jiného) překladu možné vyřešit, je např. následující příklad strukturní homonymie [5], ve kterém australský autor zdrojového textu píše: [...] an epidemic in a Japanese prisoner of war camp [...] V tomto případě se může jednat jak o japonský tábor pro válečné zajatce (v Japonsku) nebo tábor pro japonské válečné zajatce (např. v USA). Co měl autor na mysli, lze zjistit pouze z okolního textu, a pokud se informace v textu nenachází, je třeba informaci zjistit mimo text (od autora, z jiných informačních zdrojů apod.). Homonymie může nastávat na různých úrovních. Např. u flektivních jazyků se může vyskytovat morfologická homonymie u koncovek slov. Koncovka –y ve slově ženy může znamenat genitiv singuláru nebo nominativ, akuzativ i vokativ plurálu. Lexikální homonymie se týká jevu, ve kterých stejně znějící slova mají různé významy (např. slovo travička). Syntaktická homonymie označuje jev, ve kterém má celý úsek textu (někdy i celá věta) několik různých čtení. Klasický příklad v angličtině [6]: Time flies like an arrow. Tato věta má několik čtení, v nichž predikátem může být kterékoli ze slov time, flies a like. Podobný příklad v češtině: Ženu holí stroj. I v této větě může být predikát kterýkoli ze slov ženu, holí a stroj. V případě, že predikátem je ženu, nabývá navíc slovo holí dvou různých významů, které jsou sice povrchově reprezentovány stejnými mluvnickými kategoriemi (instrumentál singuláru slova hůl), ale v obou použitích se týkají různých významů instrumentálu v češtině – použití nástroje (pravý instrumentál) nebo pohyb skrze (perlativ). Významy těchto dvou konstrukcí budou zřejmější v angl. překladu: I’m chasing a machine with a stick (instrumentál) oproti I’m chasing a machine through a stick (perlativ). Dále je např. slovo žena polysémní. Polysémie označuje jev, ve kterém jednomu slovu (lexikální jednotce) odpovídá více významů. Tak např. slovu žena odpovídají významy „žena“ (pohlaví) a „žena“ (manželka). Některá slova nabývají různých významů v různých kontextech. Sloveso přijít může znamenat „dopravovat se někam chůzí“ (Přišel z Vinohrad.), „být doručen“ (Přišly nové zprávy.), „nastat“ (Přišla ekonomická krize.), „pozbýt“ (Přišel o spoustu peněz) apod.
1.4.2 Shoda Shoda (agreement, concord) je vzájemný vztah mezi různými částmi věty nebo dokonce diskursu, při kterém se tyto různé části musí shodovat v určitých kategoriích, aby mohly plnit svou syntaktickou funkci. V jazycích s volným slovosledem bývá shoda častější, protože umožňuje označit, jakou funkci mají jednotlivá slova. V češtině je shoda poměrně bohatá, v angličtině poměrně řídká a v některých jazycích (např. indonéština) neexistuje vůbec.
17
Příklad: V české větě Divocí psi roztrhali ovečku se vyskytuje několik typů shody. Atribut divocí rozvíjí subjekt psi a shoduje se v něm v pádě, čísle, rodě a navíc v životnosti. Subjekt psi se shoduje s predikátem roztrhali v čísle a u českého minulého participia navíc v rodě. Na shodu se lze dívat tak, že řídicí člen „řídí“ řízený člen. V uvedeném příkladě subjekt psi řídí číslo a rod predikátu roztrhali (nikoli naopak při zachování významu). V tomto kontextu se situace anglicky označuje jako government (řízení).
1.4.3 Obligatornost a fakultativnost Věta v přirozeném jazyce sestává z množství vzájemně závislých větných členů, z nichž přítomnost některých je nutná, naopak přítomnost jiných je volitelná. Uvažujme větu [DANEŠ81]: Maminka navštívila přítelkyni. V této větě slovo přítelkyni považujeme za povinný (obligatorní) člen, protože výpověď *Maminka navštívila. považujeme za gramaticky nekorektní. Jak dále uvádí [7], toto neplatí v případě eliptické výpovědi, protože lze uvažovat korektní souslednost vět: Myslil jsem, že když je maminka nemocna, teta ji navštíví. Nemýlil jsem se. Navštívila. Naproti tomu ve větě Maminka navštívila přítelkyni včera je člen včera nepovinný (fakultativní). Vypuštění takového členu z věty nijak neovlivní její gramatickou správnost.
1.4.4 Morfologické jevy V lingvistice se slova běžně dělí na nejmenší jednotky, které nesou nějaký význam: morfémy. Např. české slovo nehořlavý lze rozdělit na posloupnost morfémů ne-hoř-l-av-ý. Morfém může být volný, pokud se může objevovat samostatně, nebo vázaný, pokud se může objevovat jen v kombinaci s jinými morfémy. Příkladem volného morfému je v češtině les, příkladem vázaného morfému je přípona –e, která se může vyskytovat jen jako přípona, nikoli však samostatně. Derivační morfém může být připojen ke slovu a vytvořit jiné slovo. Např. morfém ne- vytváří ze slova šťastný nové slovo nešťastný. Gramatický morfém naopak vyjadřuje gramatickou informaci o roli slova ve větě a nemění význam. Např. morfém –y modifikuje slovo les tak, že z něj vytváří plurál lesy. Alomorf je varianta morfému. Např. anglická přípona pro plurál –s má jako alomorf –es. Jazyky lze z hlediska morfologie dělit mezi jazyky analytické, aglutinační, flektivní, introflektivní a polysyntetické. Poznamenejme, že toto dělení není ostré a jazyky často z nějaké části spadají do všech těchto kategorií. U některých jazyků dochází v rámci slov k výrazným změnám. Flektivní jazyky (jako např. čeština) mají afixy, jimiž vyjadřují množství gramatických kategorií. Např. v českém slově pán nese koncovka –u informaci o osobě, čísle, rodě, čase a částečně vidu. Všimněme si, že u tohoto slovesa je vid určen zároveň přítomností předpony s-. U aglutinačních jazyků nese každý afix zvláštní gramatickou kategorii. Např. v esperantu ve slově nefinsonanta (nedoznělý) znamenají afixy ne: ne, fin: do, son: kořen slovesa soni (znít), ant: přítomné činné participium, a: koncovka pro adjektivum. Jazyky, 18
ve kterých se vyskytuje polysynteze, mohou v rámci jednoho slova vyjádřit celé sdělení. Např. v turečtině slovo Afyonkarahisarlılaştıramadıklarımızdanmısınız znamená Nejste jedním z těch lidí, u nichž jsme se neúspěšně snažili, aby se podobali obyvatelům Afyonkarahisaru? [8]. Introflektivní jazyky, jako je např. arabština, mají morfémy (typicky kořen slova), které se uvnitř mění. Například v arabštině konsonantní rámec k-t-b může být obsazován samohláskami, které vytvářejí jak derivační, tak gramatické změny: kitab: kniha, kutub: knihy, katib: spisovatel, katab: napsal apod. K introflexi dochází i v indoevropských jazycích, např. v angl. goose/geese, něm. Zahn/Zähne (umlaut) nebo při vokalické gradaci, např. v angl. sing/sang/sung (ablaut). V češtině se za introflektivní změny dají považovat změny např. hroch/hroši nebo dvůr/dvoře (zde jsou vidět dokonce dvě introflexe najednou). V rámci morfologie jednoho slova dochází mezi jednotlivými morfémy rovněž k syntaktickým vztahům a výše zmíněné shodě. Je tedy na místě mluvit o syntaxi v rámci morfologického popisu – morfosyntaxi. Zatímco v evropských jazycích jsou slova v textu intuitivně sekvencemi písmen, analytické jazyky, jako např. vietnamština, používají slabičný zápis, ve kterém jedno slovo může sestávat z více sekvencí (sinh vật học: biologie; cà phê: káva). Vietnamský mluvčí však tato slova neanalyzuje na části (v příkladu slova „biologie“ by to byla slova „život“, „věc“ a „věda“), v synchronním popisu tedy skutečně platí, že se jedná o jedno slovo složené z několika „podslov“, než o několik slov. I syntaktická informace se u analytických jazyků vyjadřuje spíše zvláštními slovy než změnami vázaných morfémů v rámci jednoho slova, jak je tomu u jazyků flektivních nebo aglutinačních.
1.5 Funkční generativní popis (FGP) 1.5.1 Formální popisy jazyka Formálních popisů jazyka je celá řada. Mezi ně patří např.: •
•
•
Analýza bezprostředních složek (immediate constituent analysis, IC analysis), ve které se věta rekurzivně rozkládá na složky, které v ní leží přímo vedle sebe. Teorie předpokládá, že to, co leží ve větě vedle sebe, je spolu také těsně spojeno, což vede při neprojektivitě – jevu, ve kterém naopak logicky svázané komponenty věty leží daleko od sebe a hrany logického stromu se tak kříží – k nepřekonatelným obtížím. Generativní gramatika (generative grammar, GG): vychází z analýzy bezprostředních složek a postuluje, že gramaticky správné věty lze generovat generativními či přepisovacími pravidly formální gramatiky a že struktura jazyka nějakým způsobem reprezentuje strukturu myšlenek v mysli mluvčího. Z generativní gramatiky byla odvozena teorie překladačů programovacích jazyků. Závislostní gramatika (dependency grammar): popisuje větu výpovědi jako strukturu, která je určena vztahy mezi řídícím slovem a jinými slovy, které jsou na řídícím slově závislé.
19
1.5.2 Roviny popisu Funkční generativní popis (FGP) je stratifikační formalismus jazyka, který je výsledkem práce Pražské lingvistické školy a je popsán např. v [9]. Podle tohoto formalismu vycházejícím ze závislostní gramatiky se větná výpověď zkoumá systémem vzájemně provázaných rovin popisu. Množina uváděných rovin je v různých aplikacích různá. Například Pražský závislostní korpus (Prague Dependency Treebank), což je korpus českých textů obsahující ve své verzi PDT 2.0 celkem 2 miliony slovních jednotek na své morfologické úrovni [10], využívá poznatků z FGD a předpokládá čtyři roviny: • • • •
slovní rovina reprezentující surový text, morfologická rovina reprezentující jednotlivá slova, analytická rovina reprezentující povrchovou syntax, tektogramatická rovina reprezentující hloubkovou syntax.
Termínem povrchová syntax se označuje syntax, která nenese žádné informace o významu věty (nebo jen minimální), zatímco hloubková syntax už u závislostí eviduje funkce, které jednotlivé větné členy hrají, a další informace.
1.5.3 Vztah forma-funkce Jednotlivé roviny popisu mezi sebou mají vztah takový, že nižší rovina je formou vyšší roviny, zatímco vyšší rovina je funkcí roviny nižší. Forma je tedy konkrétní reprezentací, funkce je její abstraktní realizací.
1.5.4 Morf a morfém V souladu se vztahem forma-funkce existuje vztah mezi morfem a morfémem takový, že morf je textová sekvence, zatímco morfém je množina gramatických/sémantických informací asociovaných s touto sekvencí.
1.5.5 Lexém, lexikální forma, lexikální jednotka, lemma Lexém je abstraktní jednotka, která v sobě spojuje formální a významovou složku. Na jedné straně představuje množinu všech možných manifestací nějakého slova v textu (lexikální formy), tedy množiny morfémů, které jsou schopny tento lexém realizovat. Na druhé straně je spojen s množinou lexikálních jednotek, (lexical unit, LU), což jsou všechny významy, které v daném jazyce může tento lexém představovat. Každý lexém má lemma, tedy základní, kanonický tvar, který se často používá jako slovníkové heslo. V souladu s přístupem forma-funkce tedy je lexikální jednotka funkcí lexému. Příklad: Lexém přijít má podle valenčního slovníku VALLEX [11] 21 lexikálních jednotek (z nichž některé byly vypsány v příkladu výše). Tento lexém reprezentuje množinu lexikálních forem (přišel, přijde, přišla apod.) a jeho lemma je přijít.
20
1.6 Valenční teorie Valence v chemii je schopnost částice na sebe vázat jiné částice na přesně daná místa. Valenční teorie tuto symboliku přenáší do lingvistiky a postuluje, že lexikální jednotky disponují valencemi (valency) kterými mohou vázat jiné lexikální jednotky. Ve FGP tento popis odpovídá tektogramatické rovině. Jinou metaforou by mohl být pohled na lexikální jednotku jako funkci, která přijímá jiné lexikální jednotky jako své argumenty. Místo, na které se může na lexikální jednotku navázat jiná lexikální jednotka, se nazývá valenční pozice. Navázanou jednotku označujeme jako participant. Valenční pozice je obligatorní, pokud je na ní pro gramatickou korektnost věty nutná přítomnost participantu, jinak je fakultativní.1 Struktura obligatorních valenčních pozic v okolí lexikální jednotky se označuje jako valenční rámec (valency frame). Ve valenčním slovníku, jako je např. VALLEX, se uvádějí mj. názvy valencí a pády (eventuelně ve spojitosti s předložkami), ve kterých se objevují. Fakultativní participanty ležící mimo valenční rámec se ve valenční teorii obvykle označují jako volná doplnění (free modifications), obligatorní participanty nazýváme aktanty (actants). Příklad: Slovo dát v jednom ze svých významů předpokládá 3 valenční pozice: • • •
ACT: agens = kdo dává ADDR: adresát = komu je dáváno PAT: patiens = co je dáváno
V souladu s naší terminologií tuto situaci popisujeme tak, že lexém dát má lexikální jednotku dát1, která má rámec dát1 ACT1 ADDR3 PAT4, což vyjadřuje, že agens je v 1. pádě, adresát je ve 3. pádě a patiens je ve 4. pádě. Řetězec dát1 je pouhé označení lexikální jednotky, kterých k lexému dát patří několik.
1.7 Větné vzorce Daneš ve své studii valence českých sloves [DANEŠ] posunuje valenční teorii ještě výše a ke gramatickým větným vzorcům (GVV), které popisují konkrétní chování sloves ve svém valenčním okolí a odpovídají tak valenčním rámcům, přidává ještě sémantické větné vzorce (SVV) na nové, sémantické abstraktní úrovni. V souladu s přístupem forma-funkce je tedy sémantický větný vzorec formou lexikální jednotky. Valenčnímu rámci na této sémantické úrovni odpovídá intenční pole, které předpokládá obsazení rámci sémantickými participanty. Mezi sémantické role participantů (což jsou sémantické valence) patří např. L (locatum, umístění), A (agens, činitel), P (posesor, vlastník), K (kvalifikace, nesení vlastnosti), T (transformace) apod. Významy jednotlivých sloves lze prostřednictvím těchto valencí dekomponovat na jednodušší participanty. Tak např. větu spravit lze dekomponovat do sémantické 1
Míra obligatornosti není striktní, a proto se v literatuře hovoří ještě o valenčních pozicích potenciálních, typických apod.
21
formule x A NOT(y K z) T (y K z), což znamená, že x je činitelem (agentem), že situace, v níž y nenese vlastnost z (funkční pořádek), se transformuje do situace, v níž y tuto vlastnost nese. Slovesa lze pak na sémantické rovině rozčleňovat do kategorií podle struktury jejich sémantických formulí. Popis rovněž implikuje množinu sémantických rysů, jimiž je např. zmíněná vlastnost „funkční pořádek“. Jiné rysy jsou např. „člověk“, „zvíře“, „přírodní síla“ apod. Tyto rysy jsou sémanticky významné jednak proto, že společně se sémantickými rolemi tvoří základní kameny konstrukce složitějších významů, ale také proto, že přímo určují hloubkovou syntax. Příklad 1: Lexikální jednotka sníst ACT1 PAT4 odvozená od lexému sníst přijímá jako agens takové participanty, které na sémantické rovině mají sémantický rys „člověk“. Věta Jana snědla dort zní korektně, věta Pes snědl dort už méně. Lexikální jednotka sežrat ACT1 PAT4 přijímá na pozici agens takové participanty, které naopak sémantický rys „člověk“ nemají, a tedy větu The dog ate the cake přeložíme jako Pes sežral dort. Příklad 2: Daneš uvádí větu Okno se zavřelo větrem, kde na pozici větrem může být pouze participant, který má lexikální rys „přírodní síla“. Analogická věta *Okno se zavřelo Pavlem je tedy vnímána jako nekorektní.
22
2. Úvodní studie V úvodní studii budou shrnuty požadavky na systém vyplývající z předchozího popisu dosavadního stavu techniky (tedy uživatelské požadavky)a požadavky plynoucí z povahy jazykové skutečnosti, kterou si klademe za úkol počítačově modelovat (tedy lingvistické požadavky). Rovněž jsou popsány požadavky na systém z hlediska rozsahu, které s ohledem na neobyčejnou šíři zpracovávaného tématu omezují rozsah systému, a tedy i očekávání a požadavky s ním spojené. Dále bude podána konkrétní specifikace aplikace, která tyto požadavky splňuje, ve formě odborného článku.
2.1 Požadavky na systém 2.1.1 Požadavky na systém z hlediska rozsahu Systém je zamýšlen jako experimentální. Nejedná se tedy o řešení, tím méně komerční, pro využití běžnými uživateli pro překladatelské úkoly, nýbrž o systém pro správu jazykově nezávislé symbolické reprezentace a správu jazykově závislé lexikální reprezentace nějakého přirozeného jazyka. Funkcionalita překladu slouží k ověření zadané jazykově závislé, resp. jazykově nezávislé definice. Součástí systému nejsou a priori žádné definice, které by bylo možno prakticky použít. Systém tedy nepředpokládá žádnou konkrétní lingvistickou teorii. Pouze umožňuje uživatelům takové definice zadat.
2.1.2 Požadavky na systém z uživatelského hlediska Z popisu dosavadního stavu techniky v oblasti strojového překladu, který je uveden v předešlé kapitole, plyne, že je žádoucí poskytnout systém, který splňuje následující funkční požadavky: a. b. c. d.
nějakým způsobem „rozumí textu“ umožní uživateli zasáhnout do způsobu překladu v případě více výsledků překladu poskytne všechny uživateli k vybrání v případě nekorektního textu oznámí chybu.
2.1.3 Požadavky na systém z lingvistického hlediska Podle uvedeného popisu problémů nastávajících při zpracování jazyka po systému požadujeme, aby řešil následující lingvistické jevy: a. b. c. d.
homonymie různých typů (morfologická, lexikální, strukturní), shoda, obligatornost a fakultativnost participantů, různé morfologické jevy: 23
a. introflexe, b. nejasná hranice slov od polysynteze až po rozdělení slov do oddělených morfů u některých analytických jazyků c. nesení mnoha gramatických kategorií jedním morfem u flektivních jazyků, d. morfosyntax u flektivních jazyků
2.1.4 Návrh řešení uživatelských požadavků Z množiny uživatelských požadavků plyne, že systém by měl implementovat strojový překlad založený na pravidlech (rule-based MT) aby umožnil uživateli zasáhnout do způsobu překladu, a rovněž by měl využívat symbolickou reprezentaci (interlingua), aby „rozuměl textu“ po sémantické stránce a rovněž eliminoval nutnost konstrukce zvláštního překladače pro každý jazykový pár. Protože je zadávání pravidel poměrně pracná záležitost a zároveň má být systém otevřený pro zpracování všech jazyků, jeví se jako vhodné zpracovat systém jako webovou serverovou aplikaci přístupnou komukoli, kdo je připojen k Internetu. V dnešní době masového rozšíření fenoménu sociálních sítí a online spolupráci na tvoření obsahu (např. u Wikipedie) takto systém přirozeně využije množství internetových přispěvatelů-lingvistů, kteří do něj budou dodávat obsah.
2.1.5 Návrh řešení lingvistických požadavků Vhodné řešení pro vyhovění uvedeným požadavkům je systém, který: • • • •
převede vstupní text ve zdrojovém jazyce pomocí pravidel uživatelsky zadané bezkontextové gramatiky do jazykově závislé reprezentace (parsing), přeloží jazykově závislou reprezentaci do interlingui (překlad), přeloží symbolickou reprezentaci z interlingui do jazykově závislé reprezentace v cílovém jazyce (zpětný překlad), převede jazykově závislou reprezentaci v cílovém jazyce do textu v cílovém jazyce (rekonstrukce).
2.1.5.1
Formalismus pro lexikální reprezentaci
Jako vhodný formalismus pro jazykově závislou reprezentaci volíme valenční popis inspirovaný FGP, v němž lexikální reprezentace konkrétní věty je strom, jehož uzly odpovídají lexikálním jednotkám a jehož hrany odpovídají valencím.
2.1.5.2
Formalismus pro sémantickou reprezentaci
Jako vhodný formalismus pro jazykově nezávislou reprezentaci (sémantickou reprezentaci) volíme valenční popis inspirovaný sémantickým větným vzorcem podle Daneše. Sémantická reprezentace konkrétní věty je opět strom, jehož uzly odpovídají sémantickým participantům (sématům) a hrany odpovídají sémantickým valencím (v Danešově terminologii sémantickým rolím).
2.1.5.3
Formalismus gramatických kategorií
Systém umožní definici gramatických kategorií (např. pád, číslo, rod...) a jejich hodnot pro daný jazyk a jejich přiřazení v libovolně velkém počtu morfémům. Tím se řeší morfologický jev nesení více gramatických kategorií jedním morfem.
24
2.1.5.4
Reprezentace vět a ontologií
Komponenty reprezentace (lexikální jednotky, sémata, valence) konkrétní věty jsou instancemi entit definovaných administrátorem. Samotná ontologie sémantických jednotek má formu orientovaného acyklického grafu (directed acyclic graph, DAG), což je vhodné pro provádění testů na sémantické rysy, jak je uvedeno v odstavci popisujícím větné vzorce. Po ontologii lexikálních nevyžadujeme takovou expresivitu, stačí tedy strukturovat ji jako strom.
2.1.5.5
Morfologická reprezentace
Systém považuje jazyk na nejnižší úrovni reprezentace za posloupnost sekvencí znaků (morfů) a separátorů (bílých znaků a/nebo speciálních znaků), ne nutně ve střídavém pořadí. Tím se řeší problém s nejasnou hranicí slov. Dále se tím umožňuje to, že pravidla CFG nečiní rozdíl mezi syntaxí a morfosyntaxí.
2.1.5.6
Aplikace pravidel CFG a AG
Lexikální reprezentace se při parsingu vygeneruje uživatelsky zadanými pravidly atributové gramatiky (AG) asociovanými s pravidly bezkontextové gramatiky (CFG). Sémantická reprezentace se z lexikální reprezentace vygeneruje opět zadanými pravidly operujícími nad lexikálními jednotkami a sématy v obou těchto reprezentacích. Všechna uvedená pravidla jsou reverzibilní, aby nebylo zapotřebí psát zvláštní pravidla pro parsing a rekonstrukci, resp. pro překlad a zpětný překlad. Více o problematice parsování viz [12]. Mezi pravidla AG patří zejména: • • • •
konstrukce lexémů z morfémů (čímž se řeší funkční přechod mezi morfologickou a analytickou rovinou) test shody gramatických kategorií (čímž se řeší lingvistický požadavek na ovládání gramatické shody) přiřazení gramatických kategorií budovaným objektům lexikální reprezentace nastavení obligatornosti u těchto přiřazení (čímž se řeší požadavek na ovládání obligatornosti participantů)
2.1.5.7
Řešení víceznačnosti
Parser neklade na pravidla CFG žádné jiné nároky, než aby byla prosta levé rekurze. Pro cyklení poskytuje parser regulární výrazy. Parser je LL(1) paralelní parser, který v případě nalezení více pravidel expandujících jeden neterminál expanduje všechna pravidla. V případě vygenerování více reprezentací je systém akumuluje a zpracovává všechny. Pokud naopak text nevyhoví žádným pravidlům, oznámí se chyba. Jedna lexikální jednotka může mít více překladů na více sémat. Tím se řeší možnost lexikální homonymie. Stejně jako v ostatních případech homonymie se i tento případ zpracovává vytvořením více překladů. Tato navrhovaná řešení v úplnosti vyčerpávají požadavky na systém, které budou dále shrnuty již bez uvedení jejich motivace ve formě odborného článku.
25
2.2 Odborný článek Úkolem je navrhnout víceuživatelskou webovou serverovou aplikaci, která umožňuje uživateli vstup do systému chráněný heslem, dále po vstupu do systému: • • • •
Editaci uživatelů (pro administrátora systému) Editaci ontologie sémantické struktury reprezentující význam Pro každý jazyk, editaci jazykově závislých dat Otestování správnosti zadání překladem textu ze zdrojového jazyka do cílového
Editací se obecně míní standardní operace zápisu, změny vlastností nebo smazání nějaké entity. Smazání nesmí být provedeno, pokud je na mazané entitě závislá nějaká jiná entita. V takovém případě se uživateli poskytne varování. Změna názvu entity nemá vliv na její strukturní chování (výjimkou je morf). Editace ontologie sémantické struktury (jazykově nezávislého popisu) sestává z editace sémat a sémantických valencí. Sémata jsou organizována jako orientovaný acyklický graf (DAG), kde uzly jsou sémata a hrany jsou orientované operace odvození sématu. Editace jazykově závislého popisu sestává pro každý jazyk z: • • • • • •
Editace jazyka Editace morfologické úrovně Editace gramatických kategorií a jejich hodnot Editace lexikální úrovně Editace pravidel bezkontextové gramatiky (CFG) a pravidel atributové gramatiky (AG), které umožňují konstrukci lexikální reprezentace (LR) z textu a zpětnou rekonstrukci textu z LR Editace pravidel překladu, která umožní překlad LR na sémantickou reprezentaci (SR) a zpětný překlad SR na LR
Editace jazyka spočívá v zavedení nového jazyka do systému a jeho následné editace. Uživatel může definovat jazykově závislá data pouze tehdy, pokud je jazyk zaveden do systému. Každý jazyk definuje svůj základní neterminál. Editace morfologické úrovně umožní definovat morfy sdružené do typů morfů. Každý morf má svůj základní alomorf, který slouží k reprezentaci morfu pro lexikální vyhledávání. Editace gramatických kategorií umožní editovat atributy a jejich hodnoty. Dále umožní morfům a třídám morfů přiřazovat skupiny hodnot určitých atributů. Editace lexikální úrovně umožní editovat lexikální vzory, které sdružují lexémy. Lexikální vzor sestává z uspořádané posloupnosti typů morfu. Lexém má lemma, což je posloupnost morfů. Aby lexém mohl patřit do lexikálního vzoru, musí jeho lemma odpovídat posloupnosti typů morfu tohoto vzoru. Dále se umožňuje editace lexikálních jednotek a množiny lexikálních valencí. Lexikální jednotky jsou organizovány do množiny orientovaných stromů, v níž každá lexikální jednotka (kromě kořenové) zná svou rodičovskou jednotku. Každá lexikální jednotka má svůj přiřazený lexém. Každý lexém může mít přiřazeno více lexikálních jednotek. 26
Editace pravidel CFG předpokládá editaci neterminálů. Každý neterminál může mít množství pravidel CFG2. Pravidlo má množství symbolů: symbolů neterminálu, symbolů morfu nebo symbolů separátoru. Symboly mají multiplicitu známou z regulárních výrazů (0..1, 1..1, 0..N, 1..N). Každé pravidlo CFG má množství pravidel AG. Pokud jediné pravidlo AG nebylo korektně provedeno, uvedené pravidlo CFG selže. Pravidla AG umožňují adresovat všechny proměnné (výstupní a množinu vstupních) přítomné v pravidle a dále: • • • • • • •
deklarovat dočasné proměnné před konstrukcí LR provést test na gramatickou shodu zkonstruovat lexikální jednotku na základě nalezených morfů porovnat hodnotu atributu s konstantou nastavit hodnotu atributu přiřadit proměnnou po konstrukci LR provést test na lexikální jednotku
LR má stromovou strukturu, kde uzly jsou instance lexikálních jednotek a hrany jsou instance lexikálních valencí. V pravidlech AG se umožňuje „tečková adresace“ (adresace postupem po hranách adresovaného stromu). Editace pravidel překladu umožní definovat relaci překladu mezi sématem a lexikální jednotkou a dále ji asociovat s množinou pravidel překladu (TR). Pokud jediné pravidlo TR nebylo korektně provedeno, uvedený překlad selže. Pravidla TR umožňují adresovat obě proměnné (séma i lexikální jednotku) přítomné v relaci překladu a dále: • • •
deklarovat dočasné proměnné přiřadit proměnnou provést rekurzivně překlad celého podstromu adresovaného
SR má stromovou strukturu, kde uzly jsou instance sémantických jednotek a hrany jsou instance sémantických valencí. V pravidlech TR se rovněž umožňuje tečková adresace. Pravidla AG a TR jsou reverzibilní, což znamená, že je možné je zpětně aplikovat pro zpětný překlad z SR do LR, resp. z LR do textové formy. U pravidel AG i TR se dá nastavit obligatornost. Ověření překladem textu spočívá v zadání zdrojového textu a výběru zdrojového a cílového jazyka. Text je zpracován pravidly CFG a AG do LR, dále je LR přeložena pravidly TR do SR, dále je SR zpětně přeložena do LR cílového jazyka obrácenou aplikací TR, konečně je z LR cílového jazyka rekonstruován cílový text obrácenou aplikací CFG a AG. Pokud je vygenerováno více reprezentací, vrátí se všechny. Pokud není vygenerována žádná, vrátí se chybová hláška.
2
Je-li to u pravidel zřejmé z kontextu, upřesnění „CFG“, „AG“ nebo „TR“ se vynechává.
27
3. Analýza Tato kapitola slouží k analýze a specifikaci systému na základě zadání z odborného článku uvedeného v předcházející teoretické části. Výstup této kapitoly se použije ke konkrétní realizaci v následující kapitole Implementace. Nejprve je popsána architektura systému a jeho rozvržení do funkčních komponent. Dále jsou popsány datové struktury, které jsou nutné pro realizaci systému na všech jeho úrovních. Dále jsou popsány požadavky na algoritmy a požadavky na uživatelské rozhraní. Popis je proveden bez ohledu na jejich konkrétní realizaci programovými prostředky. Konkrétní realizace architektury systému, datových struktur, algoritmů a uživatelského rozhraní je popsána v následující kapitole Implementace. Popisují se datové struktury využívané pro: • • • •
jazykově nezávislý popis jazykově závislý popis popis gramatiky popis překladu
Je-li to zapotřebí pro pochopení významu atributů entit, je v rámci jejich popisu rovněž popsána funkcionalita, která je s nimi sdružena. Popis datových struktur je následován požadavky na algoritmy. Požadavky na algoritmy se míní jejich očekávané vstupy, výstupy a informace, které se použijí při běhu algoritmu. Konkrétní provedení algoritmů je popsáno v následující kapitole Implementace. Popisují se požadavky na algoritmy pro: • • • •
parsing překlad zpětný překlad rekonstrukci textu
Popis požadavků na uživatelské rozhraní je složen z obecného popisu očekávané funkcionality. Konkrétní provedení uvedené funkcionality je popsáno v následující kapitole Implementace. Uživatelské rozhraní musí uživateli poskytnout možnost: • • • • •
správy jazykově nezávislého popisu správy jazykově závislého popisu správy popisu gramatiky správy popisu překladu spuštění algoritmu překladu zadaného textu podle zadaných dat
3.1 Architektura systému V této sekci se popisuje navrhovaná architektura systému. Konkrétní produkty určené k její implementaci se uvádějí v implementační fázi.
28
3.1.1 Webový server Systém je navržen jako webová aplikace běžící na webovém serveru na Internetu. Webový server je přístupný přes protokol HTTP. Systém je naprogramován v některém ze skriptovacích3 interpretovaných serverových jazyků, jehož interpret běží jako modul webového serveru. Uživatel s připojením k Internetu se systémem komunikuje přes Internet prostřednictvím webového prohlížeče, na který je kladena podmínka podpory cookies.
3.1.2 Databáze Data systému jsou uložena v relační databázi, která běží na tomtéž nebo jiném serveru. Interpret serverového jazyka musí být schopen komunikace s touto relační databází.
3.2 Deployment diagram Situace je zřejmá z následujícího deployment diagramu. Klient využívá webový prohlížeč pro komunikaci s webovým serverem přes protokol HTTP. Webový server běží na fyzickém aplikačním serveru. Jako modul webového serveru běží interpret skriptovacího jazyka. Aplikace napsaná ve skriptovacím jazyce tento interpret využívá ke své funkci. Webový server je dále schopen komunikace s databází běžící na nějakém databázovém serveru přes nějaký databázový protokol, který závisí na konkrétním typu databáze.
3
„Skriptovací“ znamená, že běh programu v typickém příkladu použití trvá krátkou dobu, neinteraktivní a předpokládá se, že program na standardní výstup odevzdává nějaký obsah.
29
je
3.3 Entity pro jazykově nezávislý popis Tato podkapitola popisuje datové struktury použité pro reprezentaci jazykově nezávislého popisu, jak je definován v odborném článku. V závorkách jsou uvedeny názvy tříd tak, jak se vyskytují v přiloženém class diagramu.
3.3.1 Séma (Sema) Systém eviduje množství sémat. Séma má: • • • •
PK4 název (text) popis (text) ISA signaturu
3.3.1.1
Odvození (Derive)
Sémata jsou organizována v orientovaném acyklickém grafu (DAG). Každé séma může v DAG mít M předchůdců a N následníků. Vztah „předchůdce-následník“ je realizován relací odvození (derivation), která dekomponuje vztah M:N. Relace odvození tedy má: • •
FK sématu předchůdce FK sématu následníka
Ve zdejší terminologii je předchůdce/následník bezprostřední relace, kdežto předek/potomek je tranzitivní uzávěr této relace.
3.3.1.2
Test ISA
Séma A musí umět zjistit, zda jiné séma B je jeho předchůdce, tedy zda existuje posloupnost odvození B od A. Tento test označujeme jako test ISA (angl. is a), v objektové terminologii tedy test, zda B je potomkem A. ISA signatura je seznam všech předků sématu. Při testu ISA tedy stačí zjistit, zda určitý předek je uveden v ISA signatuře testovaného sématu.
3.3.1.3
Odvození a odpojení
Odvození sématu B od sématu A znamená, že všichni potomci B se stanou rovněž potomky všech předků A. Není umožněno odvození sématu B od takového sématu A, které je buď následníkem A (pak by došlo k vytvoření cyklu) nebo je předkem A (pak by bylo odvození zbytečné). Při odvození sématu B od A se tedy ISA signatura B nastaví na průnik ISA signatury sémat A a B. Naopak odpojení sématu B od sématu A znamená, že všichni potomci B přestanou být potomky předků A. Potom se od ISA signatur všech potomků B odečte ISA signatura A (rekurzivně). Protože žádné séma B nemůže zdědit A dvěma cestami (z důvodů popsaných v předešlém odstavci), je taková akce bezpečná.
3.3.1.4
Smazání
Odstranění sématu ze systému není možné za těchto okolností:
4
Symbolem PK se ve zdejším použití má na mysli primární klíč, symbolem FK cizí klíč.
30
• •
od sématu je odvozeno jiné séma séma je navázáno na nějaký překlad nebo je na ně v některém překladu prováděn test ISA
3.3.2 Sémantická valence (SemanticValency) Systém eviduje množství sémantických valencí. Sémantická valence má: • •
PK název (text)
3.3.2.1
Smazání
Odstranění sémantické valence není možné tehdy, pokud je tato valence referencována v nějakém pravidle TR.
3.4 Entity pro jazykově závislý popis Tato podkapitola popisuje datové struktury použité pro reprezentaci jazykově závislého popisu, jak je definován v odborném článku.
3.4.1 Jazyk (Language) Systém eviduje množství jazyků. Jazyk má: • • • •
PK název (text) ISO-1 kód (text) FK počátečního neterminálu
3.4.1.1
Nastavení aktuálního jazyka
Jazyk je možno nastavit jako aktuální. Všechny operace editace jazykově závislého popisu se pak týkají tohoto jazyka.
3.4.1.2
Smazání jazyka
Jazyk není možno smazat, pokud existuje nějaká entita, která se ho týká, a sice kterákoli z následně definovaných entit.
3.4.2 Typ morfu (MorphType) Systém pro každý jazyk eviduje množství typů morfů. Každý typ morfu obsahuje: • • •
PK FK jazyka název (text)
3.4.2.1
Odstranění typu morfu
Typ morfu nelze odstranit, pokud má nějaké morfy nebo pokud figuruje v nějakém lexikálním vzoru. Při odstranění typu morfu jsou zároveň odstraněna i všechna přiřazení hodnot atributů k typu morfu.
31
3.4.3 Morf (Morph) Typ morfu má dále množství morfů. Morf má: • • •
FK typu morfu hodnotu FK základního alomorfu (jiný morf)
Prvotně je jako základní alomorf nastaven morf sám. Základní alomorf morfu je možno změnit, ale pouze tehdy, pokud tento morf nefiguruje v lemmatu nějakého lexému.
3.4.3.1
Odstranění morfu
Morf není možno smazat, pokud: • •
je základním alomorfem jiného morfu figuruje v lemmatu nějakého lexému
Při odstranění morfu jsou zároveň odstraněna i všechna přiřazení hodnot atributů k morfu.
3.4.4 Atribut (Attribute) Systém pro každý jazyk eviduje množství atributů. Atribut má: • • •
PK FK jazyka název (text)
3.4.4.1
Smazání atributu
Atribut nelze smazat, pokud má nějaké hodnoty.
3.4.5 Hodnota atributu (AttributeValue) Atribut má dále množství hodnot. Hodnota atributu má: • •
FK hodnoty název (text)
3.4.5.1
Smazání hodnoty atributu
Hodnotu atributu nelze smazat, pokud: • •
figuruje v přiřazení nějakému morfu nebo typu morfu figuruje v testu porovnání (CMPAVAL) nějakého pravidla AG
3.4.6 Přiřazení hodnot atributů (MorphAssignment, MorphTypeAssignment) Ke každému typu morfu nebo morfu lze přiřadit množství dávek přiřazení hodnot atributů. Jde o to, že když je morf rozpoznán, tato přiřazení s ním asociují hodnoty atributů. Trojice atribut-hodnota-typ morfému, resp. atribut-hodnota-morf, se nazývá dávka přiřazení. Z důvodu morfologické homonymie může být k jednomu typu morfu, resp. morfu přiřazeno více dávek. 32
Jak pro typ morfu, tak pro morf se umožňuje: • • • •
vytvořit nové přiřazení (tím se zároveň vytvoří nová dávka) přidat do dávky nové přiřazení vymazat přiřazení z dávky (vymazáním posledního přiřazení se zároveň zruší celá dávka) vymazat celou dávku
Přiřazení je tedy kvartérní relace obsahující tyto členy: • • • •
FK morfu (resp. typu morfu) FK atributu FK hodnoty FK dávky
3.4.7 Lexikální vzor (LexicalPattern) Systém pro každý jazyk eviduje množství lexikálních vzorů. Lexikální vzor má: • • • •
PK FK jazyka název vzor (uspořádanou množinu typů morfu)
3.4.7.1
Editace vzoru
Vzor je možné editovat přidáním nového typu morfu, vyřazením typu morfu nebo změnou pořadí typů morfu. Vzor není možné editovat tehdy, patří-li do vzoru nějaké lexémy.
3.4.7.2
Smazání vzoru
Vzor není možno smazat, pokud do něj patří nějaké lexémy nebo pokud figuruje v AG pravidlu lexikálního vyhledání (LEXMATCH).
3.4.8 Lexém (Lexeme) Systém pro každý lexikální vzor eviduje množství lexémů. Lexém má: • •
FK lexikálního vzoru lemma (uspořádanou množinu morfémů)
Dále může být k lexému přiřazeno N lexikálních jednotek. Systém umožňuje novou lexikální jednotku připojit nebo starou odpojit. Dále systém umožňuje editovat lemma výběrem morfu pro každou pozici. Jako morfy v lemmatu se vybírají ty, které jsou základními alomorfy, tj. ty, které jsou základními alomorfy samy sobě. Vybíraný morf musí odpovídat typu morfému, který je uveden ve vzoru lexikálního vzoru, do kterého lemma patří, na příslušné pozici.
3.4.8.1
Nalezení lexému podle hodnot morfů (LEXMATCH)
Tento algoritmus se nazývá LEXMATCH (lexeme match) a je jedním z pravidel AG. Funkce LEXMATCH má jako argumenty:
33
• •
lexikální vzor uspořádanou množinu PK morfů
Pro danou množinu morfů nalezne pro každý z nich základní alomorf. Jejich uspořádání by tedy teoreticky mělo tvořit lemma hledaného lexému, pokud je v systému zanesen. Vyhledá se tedy takový lexém, který patří do uvedeného lexikálního vzoru a má stejné lemma. Pokud takový lexém není nalezen, funkce končí chybou. Pokud nalezen je, vrátí se lexém i s množinou lexikálních jednotek (existují-li), které jsou k lexému připojeny. Některé pozice v uspořádané množině nemusí být součástí vyhledávání a jsou tedy prázdné. Na takové pozice se při vyhledávání lemmatu nebere zřetel.
3.4.8.2
Smazání lexému
Lexém není možno smazat, pokud jsou k němu připojeny nějaké lexikální jednotky.
3.4.9 Lexikální jednotka (LexicalUnit) Systém eviduje množství lexikálních jednotek (lexical unit, LU). LU obsahuje: • • • • • • •
PK FK jazyka FK lexému název (text) popis (text) FK předchůdce (lexikální jednotka) ISA signatura
3.4.9.1
Strom lexikálních jednotek
Lexikální jednotky jsou organizovány ve stromové struktuře, proto má každá lexikální jednotka předchůdce (pokud není kořenová). Lexikální jednotku je možno do stromu připojit, ze stromu odpojit nebo ji přímo smazat.
3.4.9.2
Test ISA
Analogicky se sématem má i lexikální jednotka svou ISA signaturu a je na ní možno provést test ISA lexikální jednotky. Způsob provedení testu zde neuvádíme pro jeho analogičnost testu ISA sématu.
3.4.9.3
Smazání lexikální jednotky
Lexikální jednotku není možné smazat za těchto podmínek: • •
je předchůdcem jiných jednotek ve stromě je spojena relací překladu s nějakým sématem
3.4.10
Lexikální valence (LexicalValency)
Systém eviduje množství lexikálních valencí. Lexikální valence má: • •
PK název 34
3.4.10.1
Smazání lexikální valence
Lexikální valenci nelze smazat, je-li referencována v nějakém pravidle TR.
3.5 Entity pro specifikaci gramatiky Parsing je proces, kterým se vstupní text zpracovává pomocí pravidel CFG a AG a převádí se přitom do LR. Aby se tak mohlo stát, musí být specifikována pro daný jazyk gramatika a jazyk musí mít správně nastaven počáteční neterminál na jeden z neterminálů jazyka. V této sekci jsou popsány datové struktury sloužící k popisu gramatiky. V závorkách jsou uvedeny názvy tříd, jak se vyskytují v class diagramu.
3.5.1 Neterminál (Nonterminal) Systém eviduje množství neterminálů. Neterminál má: • • •
PK FK jazyka Název (text)
3.5.1.1
Smazání neterminálu
Neterminál nelze smazat za těchto podmínek: • • •
je-li referencován prostřednictvím některého symbolu v některém pravidle, je-li počátečním neterminálem jazyka, jsou-li k němu připojena nějaká pravidla CFG.
3.5.2 Pravidlo CFG (Rule) Pro každý neterminál může existovat množství pravidel CFG, která ho rozvíjejí. Neterminál bez pravidel je nekorektní konstrukce, která nemůže být referencována žádným pravidlem. Pravidlo CFG má: • • •
PK FK neterminálu, který rozvíjí FK jazyka
Pravidlo CFG dále ve své expanzi pravé strany obsahuje množství symbolů a má k sobě přiřazeno množství pravidel AG.
3.5.3 Symbol (Symbol) Symbol, přesněji symbol pravé strany pravidla CFG je abstraktní třída, která má následující podtřídy: • • •
symbol neterminálu, symbol morfu, symbol separátoru. 35
Každý z těchto symbolů obsahuje: • • • •
PK FK pravidla název (text) multiplicitu opakování – výběr jedné z hodnot: • 0..1 • 1 • 0..N • 1..N
Symboly lze do pravidla přidávat, z pravidla je ubírat nebo měnit jejich pořadí.
3.5.4 Symbol neterminálu (NontermSymbol) Symbol neterminálu reprezentuje výskyt neterminálu v pravidle CFG. Je podtřída symbolu a obsahuje navíc: •
FK neterminálu, který rozvíjí
Multiplicita může nabývat kterékoli z hodnot.
3.5.5 Symbol morfu (MorphSymbol) Symbol morfu reprezentuje výskyt terminálu v pravidle CFG, který rozpoznává sekvenci písmen. Je podtřída symbolu a obsahuje navíc: •
FK třídy morfu, do které patří rozpoznaný text
Multiplicita může nabývat hodnot 0..N nebo 1..N. Je tomu tak proto, že při zpracování textu v přirozeném jazyce nemá smysl zabývat se oddělenými písmeny, a proto symbol morfu při parsingu akumuluje celé množství znaků. Případ výskytu jednopísmenného morfu (multiplicita 1) je speciálním případem 1..N, podobně případ výskytu prázdného (nulového) morfu (multiplicita 0..1) je speciálním případem 0..N.
3.5.6 Symbol separátoru (SeparatorSymbol) Symbol separátoru reprezentuje výskyt terminálu v pravidle CFG, který rozpoznává oddělovač. Za oddělovač se považuje neprázdná sekvence bílých znaků nebo jeden interpunkční znak, který z obou stran může mít sekvence bílých znaků. Symbol separátoru je podtřída symbolu a jeho multiplicita může nabývat kterékoli hodnoty.
3.5.7 Pravidlo AG (Agrule) Každé pravidlo CFG může obsahovat množství pravidel AG. Každé pravidlo AG tedy obsahuje: • •
FK pravidla CFG FK jazyka
Dále každé pravidlo AG obsahuje množinu příkazů AG. Pravidlo AG je v rámci parsingu splněno právě tehdy, jsou-li splněny všechny jeho příkazy. 36
3.5.8 Příkaz AG (AgruleCommand) V rámci jednoho pravidla AG jsou příkazy AG rozčleněny do čtyř sekcí podle pořadí jejich aplikace: • • • •
sekce deklarace sekce pretestu sekce produkce sekce posttestu.
Příkaz AG je abstraktní třída, z ních jsou odvozeny následující podtřídy: • • • • • • • •
příkaz deklarace dočasné proměnné (DECLARE) příkaz přiřazení proměnné (ASSIGN) příkaz přiřazení hodnoty atributu (ASGAVAL) příkaz porovnání hodnoty atributu (CMPAVAL) příkaz porovnání s lexémem (CMPLEX) příkaz lexikálního vyhledání (LEXMATCH) příkaz testu shody (GOVERN) příkaz testu ISA lexikální jednotky (ISA)
Každý příkaz AG má dále: • • •
FK pravidla AG, k němuž patří označení sekce (deklarace, pretest, produkce, posttest) pořadí v rámci sekce (přirozené číslo)
Jak bude uvedeno podrobněji v popisu algoritmu parsingu, příkazy AG pravidla AG adresují proměnné, které jsou k dispozici v rámci pravidla CFG, ke kterému patří pravidlo AG. Pro tento výklad je třeba uvést, že těmito proměnnými jsou: • • •
3.5.8.1
vstupní proměnné odpovídající symbolům pravé strany pravidla CFG, výstupní proměnná odpovídající levé straně pravidla CFG, dočasné proměnné deklarované příkazem DECLARE.
Editace příkazů AG
Příkazy AG je možno do pravidla AG libovolně přidávat, odebírat nebo měnit jejich pořadí. Jedinou výjimkou je odebrání příkazu deklarace dočasné proměnné (DECLARE), které není povoleno v případě, že některé jiné příkazy AG adresují tuto dočasnou proměnnou.
3.5.9 Příkaz deklarace dočasné proměnné (AgcDeclare) Příkaz DECLARE zavádí do adresačního prostoru pravidla AG dočasnou proměnnou pravidla AG. Je možné jej aplikovat pouze v sekci deklarace. Má tyto vlastnosti: • • •
název dočasné proměnné (text) typ dočasné proměnné (FK lexikální jednotky; nepovinné) FK vytvořené dočasné proměnné
37
3.5.9.1
Dočasná proměnná (AgVariable)
Zavedením příkazu DECLARE se vytvoří dočasná proměnná pravidla AG, která má tyto vlastnosti: • • • •
PK FK pravidla AG název (text) z příkazu DECLARE typ (FK lexikální jednotky; nepovinné) z příkazu DECLARE
Je-li příkaz DECLARE vymazán, je vymazána i příslušná dočasná proměnná. Příkaz DECLARE, jak již bylo řečeno, nelze vymazat, pokud se tato dočasná proměnná adresuje v některém z ostatních příkazů AG.
3.5.10
Příkaz přiřazení proměnné (AgcAssign)
Příkaz ASSIGN slouží k přiřazení celé proměnné na adresované místo. Adresovaným místem může být buď výstupní proměnná nebo dočasná proměnná. Proměnnou, do které se přiřazuje, označujeme jako levostrannou, proměnnou, která je přiřazována, označujeme jako pravostrannou. Příkaz ASSIGN lze aplikovat pouze v sekci produkce. Příkaz ASSIGN je podtřídou abstraktní třídy příkazu AG a má tyto vlastnosti: • • • • • • • •
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná FK levostranné dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) typ pravostranné proměnné – jedna z hodnot: • vstupní proměnná • dočasná proměnná FK pravostranné vstupní proměnné, je-li typem pravostranné proměnné vstupní proměnná FK pravostranné dočasné proměnné, je-li typem pravostranné proměnné dočasná proměnná pravostranná cesta (posloupnost lexikálních valencí v tečkové adresaci pravé strany; nepovinné) obligatornost přiřazení (ano/ne)
FK dočasné proměnné označuje PK dočasné proměnné deklarované příkazem DECLARE. FK vstupní proměnné označuje PK symbolu pravé strany pravidla CFG. Pokud dojde k tečkové adresaci prvku, který ve struktuře neexistuje, žádné přiřazení se neprovede. Je-li přiřazení obligatorní, pravidlo selže. Není-li obligatorní, není provedena žádná akce.
38
3.5.11
Příkaz přiřazení hodnoty atributu (AgcAsgaval)
Příkaz ASGAVAL (ASsiGn Attribute VALue) slouží k přiřazení konkrétní hodnoty atributu nějaké proměnné. Lze jej aplikovat pouze v sekci produkce. Je podtřídou abstraktní třídy příkazu AG a má tyto vlastnosti: • • • •
3.5.12
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná FK levostranné dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) FK hodnoty atributu (přiřazovaná hodnota)
Příkaz porovnání hodnoty atributu (AgcCmpaval)
Příkaz CMPAVAL (CoMPare Attribute VALue) slouží k testu na shodnost hodnoty atributu nějaké proměnné s porovnávanou hodnotou. Lze jej aplikovat v sekci pretest nebo posttest. Je podtřídou abstraktní třídy příkazu AG a má tyto vlastnosti: •
• • • • •
3.5.13
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná • vstupní proměnná FK dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná FK vstupní proměnné, je-li typem levostranné proměnné vstupní proměnná levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) typ testu: • shodnost • neshodnost FK hodnoty atributu (porovnávaná hodnota)
Příkaz porovnání s lexémem (AgcCmplex)
Příkaz CMPLEX (CoMPare with LEXeme) slouží k ověření, zda testovaná proměnná je nebo není konkrétním lexémem. Lze jej aplikovat pouze v sekci posttest. Je podtřídou abstraktní třídy příkazu AG a má tyto vlastnosti: • • • • •
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná FK levostranné dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) FK porovnávaného lexému typ testu: 39
• •
3.5.14
shodnost neshodnost
Příkaz lexikálního vyhledání (AgcLexmatch)
Příkaz LEXMATCH (lexeme match) slouží k nalezení lexému a přiřazených lexikálních jednotek. Bližší popis algoritmu LEXMATCH (nalezení lexému podle hodnot morfů) je podán v analytické části u popisu lexému. Výsledky vyhledání jsou přiřazeny levostranné proměnné. Lze jej aplikovat pouze v sekci pretest. Je podtřídou abstraktní třídy příkazu AG a má tyto vlastnosti: • • • • •
3.5.15
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná FK levostranné dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) FK lexikálního vzoru (první argument algoritmu LEXMATCH) uspořádaná množina symbolů morfu (uspořádaná množina získaných hodnot morfů je druhý argument algoritmu LEXMATCH)
Příkaz testu shody (AgcGovern)
Příkaz GOVERN (GOVERNment) slouží k ověření shody hodnot atributů levé a pravé strany, pokud adresované argumenty mají těmto atributům vůbec přiřazené hodnoty. Lze jej aplikovat pouze v sekci pretest. Je podtřídou abstraktní třídy příkazu AG a má tyto vlastnosti: •
• • • • • • • • •
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná • vstupní proměnná FK dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná FK vstupní proměnné, je-li typem levostranné proměnné vstupní proměnná levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) FK atributu levé strany typ pravostranné proměnné – jedna z hodnot: • vstupní proměnná • dočasná proměnná FK pravostranné vstupní proměnné, je-li typem pravostranné proměnné vstupní proměnná FK pravostranné dočasné proměnné, je-li typem pravostranné proměnné dočasná proměnná pravostranná cesta (posloupnost lexikálních valencí v tečkové adresaci pravé strany; nepovinné) FK atributu pravé strany
40
3.5.16
Příkaz testu ISA lexikální jednotky (AgcIsa)
Příkaz ISA slouží k ověření identity testované proměnné vůči lexikální jednotce. K dispozici je pozitivní test ISA (testovaná proměnná je potomkem LU), negativní test ISA (testovaná proměnná není potomkem LU), pozitivní shoda (testovaná proměnná je LU) a negativní shoda (testovaná proměnná není LU). Příkaz lze aplikovat pouze v sekci posttest. Je podtřídou abstraktní třídy příkazu AG a má tyto vlastnosti: • • • • •
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná FK levostranné dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) FK lexikální jednotky, proti níž se test provádí typ testu – jedna z hodnot: pozitivní test ISA negativní test ISA pozitivní shoda s LU negativní shoda s LU
3.6 Model entit pro popis gramatiky 3.6.1 Class diagram 3.6.2 Popis vazeb
3.7 Entity pro popis překladu Překlad je proces, který LR v nějakém jazyce převádí do SR. Aby bylo možné překlad provést, musí být v systému zavedeny příslušné LU a sémata. Dále musí být tyto LU a sémata propojeny prostřednictvím vhodných pravidel překladu, které jsou asociovány s příkazy překladu (TR). V této sekci jsou popsány zmíněné datové struktury pro popis překladu mezi LR a SR. V závorkách jsou uvedeny názvy tříd, jak se objevují v class diagramu.
3.7.1 Pravidlo překladu (TransRule) Pravidlo překladu (translation rule, TR) je dekompozice M:N vztahu mezi LU a sématem. TR tedy obsahuje: • •
FK lexikální jednotky FK sématu
Aby mohl být překlad podle tohoto pravidla úspěšně proveden, musí s ním být asociováno množství příkazů TR. Pravidlo překladu je v rámci překladu splněno právě tehdy, jsou-li splněny všechny jeho příkazy.
41
3.7.2 Příkaz TR (TransCommand) Analogicky s AG jsou i v rámci jednoho pravidla překladu příkazy TR rozčleněny do čtyř sekcí podle pořadí jejich aplikace: • • • •
sekce deklarace sekce pretestu sekce produkce sekce posttestu.
Příkaz TR je abstraktní třída, z ních jsou odvozeny následující podtřídy: • • • • • •
příkaz deklarace dočasné proměnné (DECLARE) příkaz přiřazení proměnné (ASSIGN) příkaz porovnání hodnoty atributu (CMPAVAL) příkaz testu ISA lexikální jednotky (ISALEXUNIT) příkaz testu ISA sématu (ISASEMA) příkaz překladu (TRANSLATE)
Každý příkaz TR má dále: • • •
FK pravidla překladu, k němuž patří označení sekce (deklarace, pretest, produkce, posttest) pořadí v rámci sekce (přirozené číslo)
Jak bude uvedeno podrobněji v popisu algoritmu překladu, příkazy TR překladového pravidla adresují proměnné, které jsou k dispozici v rámci překladového pravidla. Pro tento výklad je třeba uvést, že těmito proměnnými jsou: • • •
3.7.2.1
vstupní proměnná odpovídající lexikální jednotce, výstupní proměnná odpovídající sématu, dočasné proměnné deklarované příkazem DECLARE.
Editace příkazů TR
Příkazy TR je možno do překladového pravidla libovolně přidávat, odebírat nebo měnit jejich pořadí. Jedinou výjimkou je odebrání příkazu deklarace dočasné proměnné (DECLARE), které není povoleno v případě, že některé jiné příkazy TR adresují tuto dočasnou proměnnou.
3.7.3 Příkaz deklarace dočasné proměnné (TrcDeclare) Příkaz DECLARE zavádí do adresačního prostoru překladového pravidla dočasnou proměnnou překladu. Tato proměnná musí být povinně typována na některé séma. Je možné jej aplikovat pouze v sekci deklarace. Má tyto vlastnosti: • • •
název dočasné proměnné (text) typ dočasné proměnné (FK sématu; povinné) FK vytvořené dočasné proměnné
42
3.7.3.1
Dočasná proměnná (TransVariable)
Zavedením příkazu DECLARE se vytvoří dočasná proměnná překladu, která má tyto vlastnosti: • • • •
PK FK pravidla překladu název (text) z příkazu DECLARE typ (FK sématu) z příkazu DECLARE
Je-li příkaz DECLARE vymazán, je vymazána i příslušná dočasná proměnná. Příkaz DECLARE, jak již bylo řečeno, nelze vymazat, pokud se tato dočasná proměnná adresuje v některém z ostatních příkazů TR.
3.7.4 Příkaz přiřazení proměnné (TrcAssign) Příkaz ASSIGN slouží k přiřazení celé sémantické proměnné na adresované místo. Adresovaným místem může být buď výstupní proměnná nebo dočasná proměnná. Přiřazovanou proměnnou může být pouze dočasná proměnná. Proměnnou, do které se přiřazuje, označujeme jako levostrannou, proměnnou, která je přiřazována, označujeme jako pravostrannou. Příkaz ASSIGN lze aplikovat pouze v sekci produkce. Příkaz ASSIGN je podtřídou abstraktní třídy příkazu TR a má tyto vlastnosti: • • • • • •
typ levostranné proměnné – jedna z hodnot: • výstupní proměnná • dočasná proměnná FK levostranné dočasné proměnné, je-li typem levostranné proměnné dočasná proměnná levostranná cesta (posloupnost sémantických valencí v tečkové adresaci levé strany; nepovinné) FK pravostranné dočasné proměnné pravostranná cesta (posloupnost sémantických valencí v tečkové adresaci pravé strany; nepovinné) obligatornost přiřazení (ano/ne)
FK dočasné proměnné označuje PK dočasné proměnné překladu deklarované příkazem DECLARE.
3.7.5 Příkaz porovnání hodnoty atributu (TrcCmpaval) Příkaz CMPAVAL (CoMPare Attribute VALue) slouží k testu na shodnost hodnoty atributu vstupní proměnné (lexikální jednotky) s porovnávanou hodnotou. Lze jej aplikovat pouze v sekci pretest. Je podtřídou abstraktní třídy příkazu TR a má tyto vlastnosti: • •
levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) typ testu: • shodnost • neshodnost 43
•
FK hodnoty atributu (porovnávaná hodnota)
3.7.6 Příkaz testu ISA lexikální jednotky (TrcIsaLexunit) Příkaz ISALEXUNIT slouží k ověření identity testované vstupní proměnné vůči lexikální jednotce. K dispozici je pozitivní test ISA (testovaná proměnná je potomkem LU), negativní test ISA (testovaná proměnná není potomkem LU), pozitivní shoda (testovaná proměnná je LU) a negativní shoda (testovaná proměnná není LU). Příkaz ISALEXUNIT lze aplikovat pouze v sekci pretest. Je podtřídou abstraktní třídy příkazu TR a má tyto vlastnosti: • • •
levostranná cesta (posloupnost lexikálních valencí v tečkové adresaci levé strany; nepovinné) FK lexikální jednotky, proti níž se test provádí typ testu – jedna z hodnot: pozitivní test ISA negativní test ISA pozitivní shoda s LU negativní shoda s LU
3.7.7 Příkaz testu ISA sématu (TrcIsaSema) Příkaz ISASEMA je analogický příkazu ISALEXUNIT a slouží k ověření identity testované vstupní proměnné vůči sématu. K dispozici je pozitivní test ISA (testovaná proměnná je potomkem sématu), negativní test ISA (testovaná proměnná není potomkem sématu), pozitivní shoda (testovaná proměnná je přímo sématem) a negativní shoda (testovaná proměnná není přímo sématem). Příkaz ISALEXUNIT lze aplikovat pouze v sekci posttest. Je podtřídou abstraktní třídy příkazu TR a má tyto vlastnosti: • • •
levostranná cesta (posloupnost sémantických valencí v tečkové adresaci levé strany; nepovinné) FK sématu, proti němu se test provádí typ testu – jedna z hodnot: pozitivní test ISA negativní test ISA pozitivní shoda s LU negativní shoda s LU
3.7.8 Příkaz překladu (TrcTranslate) Příkaz TRANSLATE slouží k překladu pravostranné lexikální jednotky na levostrannou sémantickou jednotku. Lze jej aplikovat pouze v sekci produkce. Je podtřídou abstraktní třídy příkazu TR a má tyto vlastnosti: •
levostranná cesta (posloupnost sémantických valencí v tečkové adresaci levé strany; nepovinné) 44
• •
pravostranná cesta (posloupnost lexikálních valencí v tečkové adresaci pravé strany; nepovinné) obligatornost (ano/ne)
Pokud není specifikována ani pravostranná, ani levostranná cesta, jedná se o přímý překlad lexikální jednotky, k němuž se využívá informace o mapování LU na séma z pravidla překladu, k němuž tento příkaz TRANSLATE patří. Je-li specifikována pravostranná či levostranná cesta, lexikální jednotka adresovaná pravostrannou cestou se přeloží rekurzivní aplikací algoritmu překladu. Pokud dojde k tečkové adresaci prvku, který ve struktuře neexistuje, žádné přiřazení se neprovede. Je-li přiřazení obligatorní, pravidlo selže. Není-li obligatorní, není provedena žádná akce.
3.7.9 Abstraktní datový model Poskytujeme abstraktní datový model uvedených skutečností (abstraktní v tom smyslu, že není spojený s žádným konkrétním DBMS). Poznamenejme, že entity příkazů TR a příkazů AG nebylo možné do modelu z důvodu prostoru zahrnout. Dále nebyla poskytnuta propojení mezi jazykem a entitami, které se ho týkají, poněvadž by bylo obtížné, ne-li nemožné, mít vzniklou strukturu planární a tedy srozumitelnou.
45
46
3.8 Specifikace parseru V této části specifikujeme požadavky, které jsou kladeny na parser a které je nutno implementovat. Konkrétní implementace algoritmu parsingu včetně pomocných entit, které jsou k tomu zapotřebí, je předmětem kapitoly Implementace. Parser je obecný název pro objekt, který realizuje čtyři následující algoritmy (z nichž pouze první je v pravém slova smyslu parsing): • • • •
parsing zdrojového textu a převedení na LR ve zdrojovém jazyce překlad LR na SR zpětný překlad SR na LR v cílovém jazyce rekonstrukce textu z LR v cílovém jazyce
3.8.1 Parsing Vstupem parsingu je: • • •
zdrojový text zdrojový jazyk startovní neterminál zdrojového jazyka
Výstupem parseru je: •
množina LR ve zdrojovém jazyce, která reprezentuje text
Algoritmus, který se použije, je parsing pomocí zadané bezkontextové gramatiky s aplikací připojených pravidel AG, která zkonstruují množinu LR. Pořadí fází aplikace příkazů AG pro každé pravidlo AG je: deklarace, pretest, produkce, posttest.
3.8.2 Překlad Vstupem překladu je: •
množina LR ve zdrojovém jazyce
Výstupem překladu je: •
množina SR
Algoritmus, který se použije, je překlad pomocí zadaných překladových pravidel s aplikací připojených pravidel TR, která zkonstruují množinu SR. Pořadí fází aplikace příkazů TR pro každé překladové pravidlo je: deklarace, pretest, produkce, posttest.
3.8.3 Zpětný překlad Vstupem zpětného překladu je: •
množina SR 47
• •
cílový jazyk startovní neterminál cílového jazyka
Výstupem zpětného překladu je: •
množina LR v cílovém jazyce
Algoritmus, který se použije, je zpětný překlad pomocí zadaných překladových pravidel s reverzní (opačnou) aplikací připojených pravidel TR, která zkonstruují množinu LR. Pořadí fází aplikace příkazů AG pro každé pravidlo je: deklarace, posttest, produkce, pretest.
3.8.4 Rekonstrukce Vstupem rekonstrukce je: •
množina LR v cílovém jazyce
Výstupem rekonstrukce je: •
množina cílových textů
Algoritmus, který se použije, je reverzní parsing (rekonstrukce) pomocí zadané bezkontextové gramatiky s aplikací reverzně (opačně) použitých připojených pravidel AG, která zkonstruují množinu cílových textů. Pořadí fází aplikace příkazů AG pro každé pravidlo AG je: deklarace, posttest, produkce, pretest.
3.9 Specifikace funkcionality systému V této části specifikujeme požadavky na uživatelské rozhraní, které musí uživateli umožňovat určité akce týkající se správy dat v systému. Konkrétní implementace těchto akcí je popsána v sekci Implementace. Data, která je třeba spravovat, se týkají: • • • •
jazykově nezávislého popisu (sémata, odvození a sémantické valence) jazykově závislého popisu (jazyk, typy morfu, morfy, atributy, hodnoty, přiřazení typům morfů, přiřazení morfům, lexikální vzory, lexémy, lexikální jednotky, lexikální valence) popisu gramatiky (neterminály, pravidla, symboly, pravidla AG, příkazy AG) popisu překladu (relace překladu, příkazy TR)
Editací entity se opět rozumí operace: • • •
vytvoření nové entity změny lokálních vlastností entity (např. název, popis apod.) smazání entity
Na smazání entity, případně další operace s entitami se kladou integritní omezení, která jsou definována výše u každého typu entity. 48
3.9.1 Jazykově nezávislý popis Správa sémantické (významové) roviny umožňuje uživateli: • • • •
editovat sémata připojit séma pod jiné séma odpojit séma od jiného sématu editovat sémantické valence
3.9.2 Jazyk Správa jazyků umožňuje uživateli editovat jazyky.
3.9.3 Morfologie Správa morfologické roviny umožňuje uživateli editovat: • • • • • •
typy morfu morfy pro daný typ morfu atributy hodnoty atributu pro daný atribut přiřazení hodnot atributu typům morfu přiřazení hodnot atributu morfům
3.9.4 Lexikon Správa lexikální roviny umožňuje uživateli: • • • • • • • • • •
editovat lexikální vzory přidávat do lexikálních vzorů typy morfu měnit pořadí typů morfu v rámci lexikálního vzoru odebírat typy morfu z lexikálních vzorů editovat lexémy nastavovat lemma z morfů editovat lexikální jednotky přiřazovat lexikální jednotky pod jiné lexikální jednotky editovat přiřazení lexému lexikální jednotce editovat lexikální valence
3.9.5 Popis gramatiky Správa gramatiky jazyka umožňuje uživateli: • • • • •
editovat neterminály přidávat a odebírat pravidla CFG u neterminálů editovat symboly pravých stran pravidel CFG měnit pořadí symbolů pravých stran pravidel CFG u pravidel CFG editovat pravidla AG
49
3.9.6 Popis překladu Správa překladu je součást lexikální roviny a umožňuje uživateli: • • •
asociovat lexikální jednotky se sématy odpojovat lexikální jednotky od sémat u překladového pravidla (tj. asociace LU se sématem) editovat pravidla TR
3.10 Specifikace funkcionality překladu Uživateli umožňuje funkcionalita překladu zadat vstupní text, vstupní a cílový jazyk a spustit překlad pomocí parseru, jehož očekávaná funkce je definována výše. Volitelně umožňuje funkcionalita překladu zobrazit výpisy z jednotlivých mezistavů po každé z těchto fází: parsing, překlad, zpětný překlad, rekonstrukce.
50
4. Implementace Implementační část sestává z konkrétního popisu architektury systému a realizace datových struktur, algoritmů a funkcionality uživatelského rozhraní, jak jsou specifikovány v předešlé části analytické.
4.1 Architektura systému jako serverové aplikace Systém je navržen jako webová aplikace běžící na webovém serveru na Internetu. Webový server je přístupný zvenčí přes protokol HTTP. Příkladem webového serveru je Apache, ale může být použit jakýkoli jiný server, který je schopen běhu interpretu PHP 5. Operační systém, na kterém server běží, je libovolný, server na něm ovšem musí být schopen běhu. Příkladem operačního systému, na kterém může běžet server Apache, je Linux. Rozumí se, že uvedená volba webového serveru a operačního systému je uvedena ve smyslu příkladu provedení a nemá být chápána jako omezení pro implementovanou aplikaci, protože tato může běžet stejně dobře i pod jinými vhodnými kombinacemi webového serveru a operačního systému.
4.1.1 Programovací jazyk PHP 5 Systém je naprogramován v serverovém jazyce PHP 5, jehož interpret běží jako modul webového serveru. Mezi důvody pro výběr právě tohoto jazyka patří: • • • • • • •
jedná se o dobře známý, zdokumentovaný programovací jazyk se širokou podporou interpret jazyka PHP 5 je k dispozici zdarma jazyk nabízí dobrou podporu pro objektově orientované programování autor tohoto systému je s programováním v tomto jazyce dobře obeznámen, čímž se snižují rizika projektu interpret disponuje garbage collectorem, který automaticky odstraňuje objekty, na které nevedou žádné reference bez problémů se připojuje k relačním databázím včetně MySQL, jsou-li nainstalovány příslušné zásuvné moduly je-li nainstalován zásuvný modul mbstring, může PHP 5 pracovat s řetězci ve víceznakových jazykových sadách (např. UTF-8), což je zásadní pro práci s řetězci v národních abecedách
4.1.2 Relační databáze MySQL Data systému jsou uložena v relační databázi MySQL 5, která běží na stejném stroji jako webový server, anebo jiném stroji. Musí být zajištěno, že interpret PHP 5 běžící na webovém serveru může komunikovat s relační databází prostřednictvím komunikačního modulu, který je zásuvným modulem interpretu. Tato komunikace nesmí být blokována např. firewallem. 51
4.1.3 E-R diagram
52
4.2 Vysvětlení vazeb E-R diagramu Následuje vysvětlení relací znázorněných v E-R diagramu. Z důvodu přehlednosti nejsou zakresleny vazby: • •
na jazyk (lang), protože jazykově závislé jsou téměř všechny entity v diagramu vedoucí od příkazů AG (agcmd) a příkazů TR (transcmd) – velmi by to znepřehlednilo diagram
4.2.1 Popis vazeb 1. Do třídy morfu (morphtype) patří morfy (morph). 2. Přiřazení typu morfu (mtasg) dekomponuje M:N relaci mezi typem morfu (morphtype) a hodnotou atributu (aval). 3. Přiřazení morfu (morphasg) dekomponuje M:N relaci mezi morfem (morph) a hodnotou atributu (aval). 4. Atribut (attr) má hodnoty (aval). 5. Do lexikálního vzoru (lexpat) patří lexémy (lexeme). 6. Lexém (lexeme) definuje množství lexikálních jednotek (lexunit). 7. Od sématu (sema) lze operací odvození (derive) odvodit další séma. 8. Lexikální jednotku (lexunit) lze operací překladu (translate) přeložit na séma (sema). 9. K překladu (translate) se používají příkazy pravidel překladu (transcmd). 10. K překladu (translate) se může využívat dočasná proměnná překladu (transvar). 11. Dočasná proměnná překladu (transvar) je typována na séma (sema). 12. Neterminální symbol (nonterm) je rozvíjen pravidly CFG (rule). 13. Pravidlo (rule) je složeno ze symbolů (symbol). 14. K pravidlu (rule) patří pravidla AG (agrule). 15. Pro zpracování pravidla AG (agrule) se používají příkazy AG (agcmd). 16. Při zpracování pravidla AG (agrule) se může používat dočasná proměnná (agvar). 17. Dočasná proměnná (agvar) může být typována na lexikální jednotku (lexunit).
4.3 Databázová realizace V této sekci uvádíme popis konkrétních realizací entit databázových tabulek MySQL, jak jsou uvedeny v předchozím E-R diagramu. U každého databázového sloupce dodáváme popis jeho sémantiky. V následujícím popisu se používají tyto zkratky: • • •
PK: primární klíč FK: cizí klíč AI: auto-increment
4.3.1 Příkaz atributové gramatiky (agcmd) název id id_agrule phase
typ int PK AI int int
sémantika primární klíč pravidlo AG; FK agrule.id fáze ve které příkaz nastává (deklarace, pretest, produkce, posttest)
53
ord cmd
int int
leftArg
int
leftArgType
int
leftPath
varchar
rightArg
int
rightArgType
int
rightPath
int
cmpType
int
oblig id_aval
tinyint int
id_lexeme
int
lexmatch
varchar
id_lexpat
int
id_isa
int
varid
int
varname
varchar
varlexunit
int
pořadí v rámci pravidla AG typ příkazu: 1=DECLARE, 2=GOVERN, 3=CMPAVAL, 4=CMPLEX, 5=LEXMATCH, 6=ISA, 7=ASSIGN, 8=ASGAVAL levá strana: ID symbolu vstupní proměnné (symbol.id) nebo ID dočasné proměnné (agvar.id) typ levé strany: 1=vstupní proměnná, 2=dočasná proměnná, 3=výstupní proměnná adresace levé strany: čárkami oddělená posloupnost lexikálních valencí (lexval.id) pravá strana: ID symbolu vstupní proměnné (symbol.id) nebo ID dočasné proměnné (agvar.id) typ pravé strany: 1=vstupní proměnná, 2=dočasná proměnná, 3=výstupní proměnná adresace pravé strany: čárkami oddělená posloupnost lexikálních valencí (lexval.id) typ porovnání: 1=rovnost, 2=nerovnost, 3=pozitivní ISA, 4=negativní ISA 0=fakultativní, 1=obligatorní ID hodnoty pro porovnání CMPAVAL nebo přiřazení ASGAVAL; FK aval.id ID lexému pro porovnání CMPLEX; FK lexeme.id argument příkazu LEXMATCH: čárkami oddělená posloupnost ID symbolů (symbol.id) nebo pomlček, nemá-li být daná pozice začleněna do vyhledávání lexikální vzor, proti kterému porovnávat v příkazu LEXMATCH; FK lexpat.id hodnota lexikální jednotky (lexunit.id), proti které porovnávat v příkazu ISA ID dočasné proměnné deklarované příkazem DECLARE; FK agvar.id název proměnné deklarované příkazem DECLARE typ proměnné deklarované příkazem DECLARE; FK lexunit.id
4.3.2 Pravidlo AG (agrule) název id id_rule id_lang
typ int PK AI int int
sémantika primární klíč pravidlo CFG; FK rule.id jazyk; FK lang.id
54
4.3.3 Dočasná proměnná pravidla AG (agvar) název id id_agrule name id_lexunit
typ int PK AI int varchar int
sémantika primární klíč pravidlo AG; FK agrule.id název typ dočasné proměnné; FK lexunit.id
typ int PK AI int varchar
sémantika primární klíč jazyk; FK lang.id název
4.3.4 Atribut (attr) název id id_lang name
4.3.5 Hodnota atributu (aval) název id id_attr value
typ int PK AI int varchar
sémantika primární klíč atribut; FK attr.id hodnota
4.3.6 Odvození sématu (derive) název id id_from id_to
typ int PK AI int int
sémantika primární klíč séma předchůdce; FK sema.id séma následníka; FK sema.id
typ int PK AI varchar int varchar
sémantika primární klíč ISO-1 kód startovní neterminál, FK nonterm.id název v národním jazyce
4.3.7 Jazyk (lang) název id code startNt name
4.3.8 Lexém (lexeme) název id id_lexpat lemma
typ int PK AI int varchar
lemmaReadable
varchar
sémantika primární klíč lexikální vzor; FK lexpat.id čárkami oddělená posloupnost ID základních alomorfů (morph.id) lidsky čitelné lemma (řetězcová reprezentace)
4.3.9 Lexikální vzor (lexpat) název id id_lang
typ int PK AI int
sémantika primární klíč jazyk; FK lang.id
55
pattern
varchar
name dsc
varchar text
4.3.10
Lexikální jednotka (lexunit)
název id id_lang id_super
typ int PK AI int int
name isa id_lexeme dsc
varchar varchar int text
4.3.11 název id id_lang name
4.3.12 název id value id_base
4.3.13
čárkami oddělená posloupnost typů morfu (morphtype.id) název textový popis
sémantika primární klíč jazyk; lang.id ID nadřazené lexikální jednotky; lexunit.id název ISA signatura asociovaný lexém; FK lexeme.id textový popis
Lexikální valence (lexval) typ int PK AI int varchar
sémantika primární klíč jazyk; FK lang.id název
Morf (morph) typ int PK AI varchar int
sémantika primární klíč textová hodnota morfu ID základního alomorfu, morph.id
Přiřazení hodnoty morfu (morphasg)
název id id_morph id_attr id_aval id_batch
typ int PK AI int int int int
4.3.14
Typ morfu (morphtype)
název id id_lang name
typ int PK AI int varchar
4.3.15 název id id_morphtype
sémantika primární klíč morf; FK morph.id atribut; FK attr.id hodnota; FK aval.id číslo dávky
sémantika primární klíč jazyk, FK lang.id název
Přiřazení hodnoty typu morfu (mtasg) typ int PK AI int
sémantika primární klíč typ morfu; FK morphtype.id
56
id_attr id_aval id_batch
4.3.16 název id id_lang name
4.3.17 název id id_nonterm id_lang valid
4.3.18 název id name isa dsc
4.3.19 název id name
4.3.20 název id id_usr timeLast state
4.3.21
int int int
atribut; FK attr.id hodnota; FK aval.id číslo dávky
Neterminál (nonterm) typ int PK AI int varchar
sémantika primární klíč jazyk; FK lang.id název
Pravidlo CFG (rule) typ int PK AI int int tinyit
sémantika primární klíč rozvíjený neterminál; FK nonterm.id jazyk; lang.id 0=platné pravidlo; 1=neplatné pravidlo
Séma (sema) typ int PK AI varchar text text
sémantika primární klíč název ISA signatura textový popis
Sémantická valence (semaval) typ int PK AI varchar
sémantika primární klíč název
Session (sess) typ varchar int timestamp int
sémantika hash udržující session uživatel; FK user.id poslední aktivita v systému 1=přihlášen, 2=odhlášen, vypršela
3=session
Symbol pravé strany (symbol)
název id id_rule ord type
typ int PK AI int int int
id_ref
int
sémantika primární klíč pravidlo CFG; FK rule.id pořadí symbolu v pravidle typ symbolu: 1=neterminál, 2=morf, 3=separátor podle typu symbolu: ID neterminálu (nonterm.id), ID typu morfu
57
name mul
4.3.22
Příkaz překladového pravidla (transcmd)
název id id_trans phase
typ int PK AI int int
ord cmd
int int
leftArg
int
leftArgType
int
leftPath
varchar
rightArg
int
rightArgType
int
rightPath
int
cmpType
int
oblig id_aval
tinyint int
id_isalexunit id_isasema
int int
varname varsema
varchar int
4.3.23 název id id_lang id_sema id_lexunit
(morphtype.id) uživatelský název multiplicita: 1=ONE, 2=OPT, 3=ASTER, 4=PLUS
varchar int
sémantika primární klíč relace překladu; FK translate.id fáze ve které příkaz nastává (deklarace, pretest, produkce, posttest) pořadí v rámci pravidla AG typ příkazu: 1=DECLARE, 2=CMPAVAL, 3=ISALEXUNIT, 4=ASSIGN, 5=TRANSLATE, 6=ISASEMA ID dočasné proměnné (transvar.id), je-li typ levé strany 3 typ levé strany: 2=dočasná proměnná, 3=výstupní proměnná adresace levé strany: čárkami oddělená posloupnost sémantických valencí (semaval.id) pravá strana: ID symbolu vstupní proměnné (symbol.id) nebo ID dočasné proměnné (transvar.id) podle typu pravé strany typ pravé strany: 1=vstupní proměnná, 2=dočasná proměnná adresace pravé strany: čárkami oddělená posloupnost lexikálních valencí (lexval.id) typ porovnání: 1=rovnost, 2=nerovnost, 3=pozitivní ISA, 4=negativní ISA 0=fakultativní, 1=obligatorní ID hodnoty pro porovnání CMPAVAL; FK aval.id porovnávaná hodnota LU; FK lexunit.id porovnávaná hodnota sématu: FK sema.id název deklarované proměnné typ deklarované proměnné; FK sema.id
Relace překladu (translate) typ int PK AI int int int
sémantika primární klíč jazyk lexikální jednotky; FK lang.id cílové séma; FK sema.id překládaná LU; FK lexunit.id
58
4.3.24
Překladová proměnná (transvar)
název id id_trans name id_sema
typ int PK AI int varchar int
sémantika primární klíč relace překladu; FK.trans.id název sémantický typ proměnné; FK sema.id
4.4 Entity pro parsing V této sekci jsou popsány entity, které pro svou funkci vyžaduje algoritmus parsingu. Připomeňme, že parsing je proces, kterým se vstupní text zpracovává pomocí pravidel CFG a AG a převádí se přitom do LR. Nejprve budou popsány objekty, které přímo provádějí parsing (lexer, parser a gramatika). Dále budou popsány třídy, které se využívají: • •
pro parsing bezkontextové gramatiky pro souběžnou konstrukci LR
4.4.1 Lexer Lexer (lexikální analyzátor) je objekt, který prochází vstupní text. Při periodickém volání jeho metody lex se lexer posune o jednu pozici dále v textu. Lexer poskytuje informaci, jaký text se nachází na dané pozici. Tato informace se skládá z dvojice token-hodnota. Token může reprezentovat buď znak nebo separátor. V případě, že je token znak, pak hodnota odpovídá hodnotě znaku (tedy písmenu). V případě, že je token separátor, pak hodnota odpovídá typu separátoru. Rozlišujeme tyto typy separátorů: • • •
bílý znak interpunkční znak konec vstupního textu
Lexer tedy udržuje následující atributy: • • • •
vstupní text aktuální pozice ve vstupním textu aktuální token aktuální hodnota
Lexer zejména poskytuje tyto metody: • • •
lex – posune lexer o jednu pozici dále v textu getToken – vrátí aktuální token getValue – vrátí aktuální hodnotu
4.4.2 Parser Parser je objekt, který nejen realizuje vlastní parsing, ale spouští i překlad, zpětný překlad a rekonstrukci. Pro tento účel obsahuje: 59
• • • • • • • •
vstupní text, objekt lexeru, objekt gramatiky aktuálně zpracovávaného jazyka, leaves – množinu aktuálně parsovaných itemů, tedy „listů“ paralelního parsingu množinu výsledků parsingu (instancí lexému) množinu výsledků překladu (instancí sémat) množinu výsledků zpětného překladu (instancí lexému) množinu výsledků rekonstrukce (reverzních itemů)
Parser zejména obsahuje tyto metody: • • • • • • •
init – inicializuje parser nastavením vstupního textu, vstupního a výstupního jazyka a počátečních neterminálů těchto jazyků parse – převede vstupní text ve zdrojovém jazyce do jeho LR a uloží výsledky do množiny výsledků parsingu translate – převede všechny LR uložené v množině výsledků parsingu do jejich SR a uloží výsledky do množiny výsledků překladu reverseTranslate – převede všechny SR uložené v množině výsledků překladu do jejich LR v cílovém jazyce a uloží výsledky do množiny výsledků zpětného překladu reconstruct – převede všechny LR z množiny výsledků zpětného překladu do odpovídajících reverzích itemů a uloží výsledky do množiny výsledků rekonstrukce. shift – provede fázi SHIFT nad množinou aktuálně parsovaných itemů reduce – provede fázi REDUCE nad množinou aktuálně parsovaných itemů
Metody parseru jsou inherentně spojeny s popisem algoritmů, nejsou tedy popisovány zde.
4.4.3 Symbol pravidla (Symbol) Symbol je abstraktní třída reprezentující entitu symbolu pravé strany pravidla CFG. Zatímco je pořadí symbolů vyjádřeno sloupcem ord (pořadí, order), u objektů třídy Symbol patřících pod jedno pravidlo CFG je praktické uchovávat relaci předchůdcenásledník pomocí reference na další objekt třídy Symbol v pravidle. Symbol tedy má atribut next, který je referencí na další symbol. Pokud je nulový, jedná se o poslední symbol. Abstraktní třída Symbol definuje abstraktní metodu createItem, která vrací příslušný objekt třídy odvozené od Item (viz dále) patřící k tomuto symbolu. Jedná se tedy o implementaci návrhového vzoru Factory. Parametrem metody createItem je item neterminálu (NontermItem), který je rodičem (parent) vytvářeného itemu. Dále, rovněž podle návrhového vzoru Factory, definuje třída Symbol abstraktní metodu createRevItem, která podobným způsobem generuje reverzní item. Jejím parametrem je model reverzního itemu. Od abstraktní třídy Symbol jsou odvozeny třídy Morph, Nonterm a Separator. 60
4.4.4 Morph Třída Morph implementuje abstraktní třídu Symbol a je reprezentací symbolu morfu v pravidle. Má vlastnosti popsané v analytické části (navrhovaná třída MorphSymbol) a navíc implementuje: • •
pomocnou metodu createItem, která vrací objekt třídy MorphItem, pomocnou metodu createRevItem, která vrací objekt třídy MorphRev.
4.4.5 Nonterm Třída Nonterm implementuje abstraktní třídu Symbol a je reprezentací symbolu neterminálu v pravidle. Má vlastnosti popsané v analytické části (navrhovaná třída Nonterm) a navíc implementuje: • •
pomocnou metodu createItem, která vrací objekt třídy NontermItem, pomocnou metodu createRevItem, která vrací objekt třídy NontermRev.
4.4.6 Separator Třída Separator implementuje abstraktní třídu Symbol a je reprezentací symbolu separátoru v pravidle. Má vlastnosti popsané v analytické části (navrhovaná třída Separator) a navíc implementuje: • •
pomocnou metodu createItem, která vrací objekt třídy SeparatorItem, pomocnou metodu createRevItem, která vrací objekt třídy SeparatorRev.
4.4.7 Objekt gramatiky (Grammar) Objekt gramatiky v sobě sdružuje informace vztahující se ke gramatice zpracovávaného jazyka. Zejména obsahuje tyto atributy: • • • •
jazyk, který modeluje množinu neterminálů jazyka množinu pravidel jazyka množinu morfů jazyka
Poskytuje tyto metody: • • •
getMorphByValue – zjistí, zda pro daný typ morfu existuje morf s danou hodnotou, a vrátí jeho PK getRuleById – pro daný PK pravidla vrátí pravidlo getRulesByNonterminal – pro daný neterminál vrátí množinu pravidel, která ho rozvíjejí
4.4.8 Item Používaný algoritmus paralelního LL(1) parsingu pro svou činnost využívá objektů zvaných itemy, které reprezentují aktuálně zpracovávaný úsek textu. Itemy jsou instancemi symbolů pravé strany pravidla CFG. Item je abstraktní třída, od které jsou odvozeny třídy: 61
• • •
item morfu item separátoru item neterminálu
Item obsahuje zejména tyto atributy: • • • • • •
lexemes – množina LR tohoto itemu (instancí lexému) symbol – symbol, který item modeluje count – počet opakování itemu canReduce – zda je možné item redukovat prev – reference na předchozí item v rozvoji pravidla; pokud je item první, pak je reference prázdná parent – neterminál (objekt NontermItem), v jehož expanzi se item nachází; je to neterminál, kterému po dokončení parsování pravidla je třeba předat získané LR
Item definuje tyto abstraktní metody: • •
shift – reakce na zprávu SHIFT od parseru reduce – reakce na zprávu REDUCE od parseru
Metody shift a reduce jsou inherentně spojeny s algoritmem parsingu, jsou tedy popsány u konkrétních tříd v rámci popisu algoritmu parsingu
4.4.9 Item morfu (MorphItem) Item morfu je instancí jednoho symbolu morfu (MorphSymbol). Funguje jako akumulátor načítaných písmen a jeho úkolem je rozpoznat podle těchto písmen morf odpovídající typu morfu definovanému symbolem morfu. Má navíc tyto atributy: • •
hodnota akumulovaného řetězce písmen FK rozpoznaného morfu
Item morfu má navíc metody: • •
4.4.10
lookup – nalezení FK morfu na základě akumulované hodnoty (využívá k tomu metodu gramatiky getMorphByValue) spawn – vytvoření hluboké kopie
Item separátoru (SeparatorItem)
Item separátoru je instancí jednoho symbolu separátoru (SeparatorSymbol). Funguje jako rozpoznávač separátoru v toku textu. Má navíc: •
hodnotu rozpoznaného typu separátoru
Item separátoru má navíc metodu: •
spawn – vytvoření hluboké kopie
62
4.4.11
Item neterminálu (NontermItem)
Item neterminálu je instancí jednoho symbolu neterminálu (NonterminalSymbol). Funguje jako zástupce jednoho konkrétního rozvoje pravidla CFG pro tento neterminál při parsingu. Udržuje navíc: • •
solutions – množinu itemů, které řeší rozvoj pravidla CFG pro každé z opakování neterminálu lexicalSolutions – množinu všech LR výsledků parsování, tedy lexikálních řešení, pro každé z opakování neterminálu
Dále obsahuje tyto metody: • •
4.4.12
expand – spustí paralelní parsing všech pravidel, která jej expandují receive – přijme LR všech itemů realizujících tento item neterminálu po jeho rozpoznání pro dané opakování neterminálu, zpracuje je pravidly AG a výsledek uloží do množiny lexikálních řešení lexicalSolutions
Instance lexému (Lexeme)
Instance lexému je objekt, který reprezentuje jakoukoli LR, která během parsingu vznikne. Slouží k přenášení informací mezi různými úrovněmi parsovacího stromu. Tento objekt nemusí být v pravém slova smyslu instancí lexému podle toho, jak byl lexém definován výše. Protože se jedná o dynamický objekt, který se mění v průběhu algoritmu parsingu a překladu, může v různých fázích svého životního cyklu reprezentovat morf, lexém i lexikální jednotku. Má tyto vlastnosti: • • • • •
morphID – FK rozpoznaného morfu (pokud reprezentuje morf) lexID – FK rozpoznaného lexému (pokud reprezentuje lexém) luID – FK rozpoznané lexikální jednotky (pokud reprezentuje lexikální jednotku) actants – množina aktantů5, tedy jiných instancí lexému připojených přes nějakou valenci. Tato množina je realizována jako pole, ve kterém indexy jsou PK lexikálních valencí a hodnoty jsou přímo objekty lexémů data – množina hodnot atributů
Všimněme si, že množina aktantů asociovaných přes nějakou valenci s instancí lexému realizuje konkrétní valenční pole a vytváří stromovou strukturu LR. Instance lexému má dále zejména tyto metody: • •
assignAttributeValue – přiřadí do množiny data danou hodnotu atributu assignActant – přiřadí do množiny actants nový aktant
5
Toto pojmenování není v přísném slova smyslu zcela přesné – aktant podle valenční teorie označuje obligatorní participant. Správnější pojmenování by bylo tedy „participant“. Zda je daná pozice obligatorní nebo není, se určuje teprve v rámci pravidel AG. Hovoří-li se zde tedy v tomto kontextu o aktantech, jedná se vlastně o reprezentaci valenčních participantů.
63
• • •
4.4.13
getMorphID, getLexID, getLuID – „gettery“ pro FK rozpoznaného morfu, lexému nebo LU spawn – vytvoří hlubokou kopii translate – vytvoří množinu SR pro tuto instanci lexému
Lexikální vektor (LexVector)
Lexikální vektor je objekt, který v sobě integruje LR (tedy instance lexému) vstupních proměnných, výstupní proměnné a dočasných proměnných (deklarovaných příkazem AG DECLARE) při zpracování příkazy pravidla AG. Tvoří tedy adresní prostor pro pravidlo AG. Lexikální vektor obsahuje tyto atributy: • • •
input – uspořádaná množina LR vstupních proměnných temp – uspořádaná množina LR dočasných proměnných output – LR výstupní proměnné
Dále obsahuje tyto metody: • • •
spawn – vytvoří hlubokou kopii declareVariable – deklaruje novou proměnnou volitelně s nějakým typem (lexikální jednotky) a vloží ji do množiny temp setLexeme – nastaví konkrétní LR v jedné z množin input, temp, output na zadanou LR
64
4.5 Model entit pro parsing 4.5.1 Class diagram
4.5.2 Vysvětlení vazeb Uvedený třídní diagram je pouze zjednodušeným zobrazením situace během parsingu. Přesto však osvětlí složité vztahy mezi třídami. • •
Parser má k dispozici jeden lexer (Lexer) a jeden objekt gramatiky (Grammar) Gramatika (Grammar) modeluje nějaký jazyk. Má množinu neterminálů (tabulka Nonterm). 65
• • • • • •
Neterminál (tabulka Nonterm) rozvíjí množství pravidel (Rule). Pravidlo CFG (Rule) má na své pravé straně množství symbolů (Symbol). Symbol může být realizován třídami Separator, Nonterm a Morph. Každá z těchto tříd může podle návrhového vzoru Factory vygenerovat realizace abstraktní třídy Item: SeparatorItem, NontermItem a MorphItem. Ke každému pravidlu CFG (Rule) je přiřazeno množství pravidel AG (Agrule). Pravidlo AG je realizováno konkrétními pravidly AgcDeclare, AgcLexmatch, AgcAssign, AgcGovern, AgcCmpaval, AgcAsgaval a AgcIsa.
4.6 Algoritmus parsingu Parsing je paralelní LL(1) parsing bezkontextové atributové gramatiky. Gramatika může být jakákoli, která splňuje požadavek neexistence levé rekurze. Symboly pravé strany jsou opatřeny multiplicitami známými z regulárních výrazů. Multiplicity symbolů pro účel tohoto popisu nazvěme takto: • • • •
0..1: OPT (volitelný, optional) 1: ONE (jeden) 0..N: ASTER (symbol * z regulárních výrazů, asterisk) 1..N: PLUS (symbol + z regulárních výrazů)
Algoritmus pro parsing funguje takto: 1. Inicializovat lexer zdrojovým textem, nastavit jej před první pozici (takže při dalším volání lex bude na první pozici ve zdrojovém textu). 2. Inicializovat parser objektem gramatiky pro zdrojový jazyk a dále: a. Vyprázdnit pole leaves určené pro akumulaci aktivních itemů. b. Pro startovní neterminál vygenerovat objekt NontermItem (multiplicita 1, canReduce=false) a vložit jej do leaves. 3. Opakovat: a. Posunout lexer o jednu pozici voláním lex. b. Všem itemům v poli leaves odeslat zprávu SHIFT (zavolat jejich metody shift). i. Pokud zprávu SHIFT dostane NontermItem, pak: 1. Má-li multiplicitu ONE, pak nastavit canReduce=true (redukovat při příštím opakování itemu) a expandovat své pravidlo metodou expand: a. Metoda expand pro všechna pravidla expandující tento neterminál vytvoří příslušný item z jejich prvních symbolů (metodou createItem, návrhový vzor Factory) a všem jim rekurzivně vyšle zprávu SHIFT. b. Je-li pravidel expandujících tento neterminál více než jedno, je třeba pro každé další vytvořit kopii přijímacího neterminálu (metodou spawn) a nastavit jako parent výše vytvořeného itemu právě tuto kopii. Důvodem je to, že každý běh expandovaného pravidla vrátí principielně jinou LR po přijetí
66
principielně jiného množství znaků, načež je třeba předat LR a řízení správnému neterminálnímu itemu. 2. Má-li multiplicitu OPT, pak je třeba paralelně simulovat pokračování ve zpracování i nepřijetí žádného textu: a. Vytvořit (metodou spawn) kopii tohoto neterminálu, která simuluje nepřijetí žádného textu. Nastavit jí canReduce=true a okamžitě ji zredukovat vysláním zprávy REDUCE (tj. zavoláním metody reduce). Metoda reduce se volá s parametrem addToLeaves=false (viz dále), což vyvolá okamžitý SHIFT itemu následujícího po této kopii namísto jeho vložení do pole leaves. b. Pro tento neterminál se zachovat jako v bodě 1. 3. Má-li multiplicitu PLUS, pak je třeba paralelně simulovat pokračování dalším opakováním tohoto neterminálu i ukončení po zpracování tohoto opakování: a. Vytvořit (metodou spawn) kopii tohoto neterminálu, které se nastaví canReduce=false a expanduje se výše popsaným způsobem. Tato kopie simuluje pokračování dalším opakováním. b. Pro tento neterminál se zachovat jako v bodě 1. 4. Má-li multiplicitu ASTER, pak záleží, kolikrát se tento neterminál již opakoval: a. Pokud se dosud neopakoval (count=0), pak je třeba simulovat normální pokračování s jedním opakováním, opakované pokračování i okamžitou redukci. Pro poslední dvě eventuality se metodou spawn vytvoří kopie. i. Normální pokračování: viz bod 1. ii. Opakované pokračování: viz bod 3a. iii. Okamžitá redukce: viz bod 2a. b. Pokud se již opakoval (count>0), pak se pokračuje stejně, jako kdyby multiplicita byla PLUS, tedy bodem 3. ii. Pokud zprávu SHIFT dostane MorphItem, pak: 1. Je-li aktuálním tokenem znak, pak: a. Objekt MorphItem se chová stejně jako NontermItem, pouze místo expanze nastane toto: i. Akumulátor načteného řetězce přidá na konec aktuální hodnotu z lexeru. ii. Instance MorphItem se přidá do pole leaves, aby v následující fázi přijala zprávu reduce. iii. Není třeba řešit eventuality ONE a OPT, protože symbol morfu má vždy multiplicitu ASTER nebo PLUS. b. Není-li aktuálním tokenem znak, ačkoli MorphItem znak očekává, pak je pravděpodobné, že došlo k chybě srovnání (compare error) se znakem separátoru. 67
i. Pokud má MorphItem prázdnou naakumulovanou hodnotu a multiplicita je ASTER, pak je to v pořádku a může okamžitě skončit rozpoznáním nulového morfu – zavolá se okamžitě reduce s parametrem addToLeaves=false. ii. V opačném případě skutečně došlo k chybě srovnání a neprovede se žádná akce, tj. MorphItem se nevloží do leaves, nezůstane na něj žádná reference a v nejbližší době se zničí garbage collectorem. iii. Pokud zprávu SHIFT dostane SeparatorItem, pak: 1. Je-li aktuálním tokenem znak, mohlo dojít k chybě srovnání. Je-li SeparatorItem s multiplicitou OPT, okamžitě se redukuje s parametrem addToLeaves=false. V opačném případě se jedná o chybu srovnání, neprovede se žádná akce 2. Je-li aktuálním tokenem separátor, pak: a. Je-li SeparatorItem s multiplicitou OPT, pak je třeba simulovat paralelně nepřijetí i přijetí separátoru analogickým způsobem, jak je popsáno výše. b. Je-li SeparatorItem s multiplicitou ONE, pak se nastaví canReduce=true a vloží do leaves analogickým způsobem, jak je popsáno výše. c. Všem itemům v poli leaves odeslat zprávu REDUCE (zavolat jejich metody reduce), přičemž parametr addToLeaves=true. i. Pokud zprávu dostane NontermItem, pak se zavolá jeho metoda reduce, která funguje takto: 1. Je-li počet lexikálních řešení (lexicalSolutions) je nulový, pak to znamená, že pravidla AG nevyprodukovala žádnou LR. V takovém případě se tato větev paralelního parsingu ukončí tím, že se nevloží do leaves, nezůstane na ni žádná reference a garbage collector ji v nejbližší době zlikviduje. V případě, že však došlo k přeskočení tohoto itemu neterminálu (jeho count=0 a jeho multiplicita je OPT nebo ASTER), pak je vše v pořádku a item neterminálu si do lexicalSolutions vloží umělý prázdný lexém. 2. Pokud je nastaveno canReduce=false, pak NontermItem pokračuje svým dalším opakováním: a. Inkrementuje count. b. Pokud je reduce volána standardně s addToLeaves=true (což je případ fáze REDUCE), pak se tento NontermItem přidá do leaves. c. Pokud je reduce volána nestandardně s addToLeaves=false, pak se jedná o vynucenou redukci, přičemž má NontermItem pokračovat svým dalším opakováním, tudíž se zavolá jeho metoda shift. 3. Pokud je nastaveno canReduce=true, pak je expanze neterminálu u konce. 68
a. Pokud po tomto neterminálu následuje nějaký symbol (reference next není nulová), pak se pokračuje tímto symbolem. i. Ze symbolu se vytvoří item (volání metody createItem). ii. Pokud je standardně addToLeaves=true, pak se jednoduše item vloží do leaves. iii. V opačném případě se zavolá shift tohoto itemu. b. Pokud již po tomto neterminálu nenásleduje žádný symbol, pak je tento neterminál poslední a je třeba rodičovskému itemu předat výsledky parsingu jeho expanze. i. Existuje-li rodičovský item, pak se zavolá jeho metoda receive (viz další podsekce). ii. Neexistuje-li rodičovský item, pak parsing doběhl do konce. Vygenerované LR z pole lexicalSolutions se předají přímo parseru a algoritmus končí úspěchem. iii. Je-li ii. Pokud tuto zprávu dostane MorphItem, pak: 1. Není-li aktuální token lexeru znakem, pak: a. Pokud tento MorphItem naakumuloval nějakou hodnotu, došlo právě k chybě srovnání. MorphItem se pak nevloží do leaves a tato větev paralelního parsingu končí. b. Pokud MorphItem nenaakumuloval žádnou hodnotu, pak je vše v pořádku a pokračuje se dále ke zpracování nulového morfu. 2. Pokud je canReduce=false, bude se v příštím cyklu parseru pokračovat načítáním hodnoty. MorphItem se vloží do leaves. 3. V opačném případě se MorphItem zredukuje. a. Metodou lookup se v databázi vyhledá FK morfu. b. Pokud metoda nic nenajde, neprovede se žádná akce a logická větev se zapomene. c. Pokud metoda najde FK morfu, pak: i. Provede kartézský součin mezi přiřazeními hodnot atributů morfu a přiřazeními hodnot atributů typu morfu, vytvoří z nich instance lexémů (Lexeme), přidělí jim nalezený morphID a vloží je všechny do pole lexemes objektu MorphItem. ii. Existuje-li v rozvoji pravidla následník, známým způsobem se z něj vytvoří item a ten se pak vloží do leaves (pokud addToLeaves=true) nebo se zavolá jeho metoda shift (v opačném případě).
69
iii. Neexistuje-li následník, pak se zavolá metoda receive nadřazeného neterminálu (parent) a jeho metoda reduce. iii. Pokud tuto zprávu dostane SeparatorItem, zachová se stejně, jen s tímto rozdílem: případě úspěchu se nevolá se žádná metoda lookup, ale vygeneruje se lexém, do něhož se vloží typ separátoru sepType získaný z hodnoty lexeru. d. Pokud pole leaves obsahuje nějaké itemy, cyklí se algoritmus znovu od bodu 3, v opačném případě se ukončí neúspěchem, protože paralelní parsing nenalezl žádné řešení.
4.6.1 Metoda NontermItem::receive Metoda receive slouží itemu neterminálu k přijetí LR svého rozvoje. Volá ji vždy poslední item rozvoje. Algoritmus zpracování příslušných LR je tedy následující: 1. Zpětným průchodem po referencích prev se získají všechny itemy zpracování expanze neterminálu a protože jsou v obráceném pořadí, uloží se do pole a obrátí se standardní funkcí PHP array_reverse. 2. Ze všech itemů se získají pole jejich LR uložená v jejich poli lexemes. 3. Každý item může mít množství LR, takže je potřeba vygenerovat všechny kombinace. Provede se tudíž kartézský součin mezi všemi poli lexemes všech získaných itemů. 4. Z optimalizačních důvodů se již během konstrukce kartézského součinu na každou vygenerovanou kombinaci aplikují pravidla AG, která zpravidla většinu kombinací nepřijmou. 5. Kombinace, které projdou pravidly AG, se akumulují v poli lexemes itemu neterminálu pro jeho dané opakování (count).
4.6.2 Aplikace pravidel AG Každá kombinace lexémů (objekt třídy Lexeme) vygenerovaná z kartézského součinu v metodě NontermItem::receive se podrobí pravidlům AG. Pro každé z pravidel AG asociované s pravidlem rozvoje itemu neterminálu se vytvoří instance lexikálního vektoru (objekt třídy LexVector), jehož vstupní proměnné (input) se naplní lexémy kombinace. Následně prochází lexikální vektor čtyřmi fázemi zpracování příkazy AG, jak jsou popsány v analytické části. Kromě algoritmu LEXMATCH (vysvětlen v popisu entity lexém) a testu ISA (vysvětlen v popisu entity lexikální jednotka) se neprovádějí žádné zvláštní algoritmy, které by bylo třeba vysvětlovat. Tečkovou notací se rozumí adresace stromu tvořeného aktanty, kde jednotlivé prvky notace označují indexy pole actants daného lexému. Aby byla kombinace lexémů přijata, musí všechny příkazy daného pravidla AG proběhnout korektně. Následuje výpis možných příkazů v sekcích, ve kterých se mohou vyskytovat: 1. Deklarace: v této fázi se volají všechny příkazy DECLARE, které naplní pole temp lexikálního vektoru deklarovanými proměnnými. 70
2. Pretest: a. Příkaz CMPAVAL otestuje, zda adresovaný lexém má určitý atribut. Není-li tomu tak, příkaz selže. b. Příkaz LEXMATCH provede algoritmus lexikálního vyhledání (viz popis entity lexém). Není-li nalezen žádný lexém, příkaz selže. V opačném případě se pro všechny lexikální jednotky asociované s lexémem vytvoří kopie zpracovávaného lexikálního vektoru (metodou spawn) a výsledek lexikálního vyhledávání (tedy lexID a luID) se přiřadí levostranným proměnným příkazu. c. Příkaz GOVERN otestuje shodu hodnot atributů levostranné a pravostranné proměnné. V případě, že některá z proměnných atribut vůbec nemá, otestování se neprovede a příkaz skončí úspěšně –shoda v gramatických kategoriích totiž platí pouze mezi větnými členy, které tyto kategorie skutečně nesou. 3. Produkce a. Příkaz ASSIGN přiřadí pravostrannou proměnnou levostranné. Pokud dojde k chybě adresace tečkovou notací (pravostranná nebo levostranná proměnná/valenční pozice neexistuje), pak příkaz selže jen tehdy, je-li obligatorní. b. Příkaz ASGAVAL přiřadí levostranné proměnné hodnotu. 4. Posttest: a. Příkaz CMPLEX otestuje, zda levostranná proměnná je nebo není rovna porovnávanému lexému. b. Příkaz ISA otestuje, zda levostranná proměnná je/není rovna/potomkem porovnávané lexikální jednotky.
4.7 Entity pro rekonstrukci Algoritmus rekonstrukce textu z LR vyžaduje entity, které jsou popsány v této sekci.
4.7.1 Reverzní item (RevItem) Reverzní item reprezentuje nějaký lexém a snaží se najít jeho rozvinutí do textu pomocí reverzní aplikace pravidel AG. Reprezentovaný lexém se nazývá model. Dále má reverzní item multiplicitu, která je odvozena od multiplicity symbolu modelu. Reverzní item je abstraktní třída, která definuje tyto abstraktní metody: • • • •
reconstruct – metoda algoritmu rekonstrukce, která vrací pole reverzních itemů reprezentujících řešení rekonstrukce; pokud nelze reverzní item nijak rekonstruovat, vrací se prázdné pole spawn – vytvoření hluboké kopie printOut – vrací rekonstruovaný řetězec isRealized – vrací logickou hodnotu, zda je reverzní item realizován, tedy zda generuje nějaký text
4.7.2 Reverzní item morfu (MorphRev) Reverzní item morfu reprezentuje jeden rekonstruovaný morf. Má následující atributy: •
baseID – PK základního alomorfu pro rekonstruovaný morf 71
• •
mt – PK typu morfu získaný ze symbolu morfu value – textová hodnota morfu
Metoda isRealized vždy vrací true, protože realizovaný je i nulový morf. Metoda printOut je triviální - vrací textovou hodnotu rekonstruovaného morfu. Metoda reconstruct bude vysvětlena v rámci popisu algoritmu rekonstrukce.
4.7.3 Reverzní item neterminálu (NontermRev) Reverzní item neterminálu reprezentuje rekonstruovaný rozvoj neterminálu. Má následující atributy: • •
nt – PK neterminálu, který tento reverzní item reprezentuje revs – pole obsahující reverzní itemy rozvoje pravidla neterminálu
Metoda isRealized vrací false tehdy, když nebylo prostřednictvím reverzně aplikovaných pravidel AG nalézt žádný lexém reprezentující lexikální jednotku, který by mohl být modelem tomuto reverzním itemu. Metoda printOut vrací konkatenaci řetězců získaných rekurzivním voláním printOut všech podřízených reverzních itemů v poli revs.
4.7.4 Nulový reverzní item (NullRev) Nulový reverzní item nahrazuje nerealizovaný reverzní item neterminálu. Jeho metoda isRealized je vždy true. Metoda printOut vrací prázdný řetězec, metoda reconstruct vrací pole s tímto samotným itemem.
4.7.5 Kontejner reverzních itemů (RevContainer) Kontejner reverzních itemů je podtřída lexikálního vektoru (LexVector), který obohacuje o pole revs. Reprezentuje adresační prostor pro reverzně aplikovaná pravidla AG. Pole revs obsahuje reverzní itemy, jejichž modelem jsou lexémy sdružené v poli vstupních proměnných input lexikálního vektoru. Smyslem kontejneru reverzních itemů je tedy poskytnout prostor, ve kterém reverzní pravidla AG nejprve rekonstruují vstupní lexémy v poli input na základě známého výstupního lexému output, dále na základě těchto vstupních proměnných rekonstruovat reverzní itemy.
4.8 Algoritmus rekonstrukce Algoritmus rekonstrukce vyžaduje: • • •
startovní neterminální symbol LR v cílovém jazyce určenou k rekonstrukci, tj. lexém s obsazenými aktanty PK cílového jazyka
Je-li toto dáno, probíhá algoritmus následovně: 1. Vytvořit reverzní neterminální item (objekt třídy NontermRev) na základě startovního neterminálního symbolu. Jeho atribut nt se nastaví na hodnotu 72
tohoto symbolu, multiplicita se nastaví na ONE, model se nastaví na zdrojový lexém k rekonstrukci. 2. Pro tento reverzní neterminální item se zavolá metoda reconstruct, která vrací množinu reverzních itemů realizujících tento item. Tyto reverzní itemy jsou řešeními algoritmu rekonstrukce.
4.8.1 Metoda NontermRev::reconstruct Metoda reconstruct reverzního neterminálního itemu funguje takto: 1. Získají se všechna pravidla AG pro pravidla CFG rozvíjející neterminál nt. 2. Pro každé z těchto pravidel AG: a. Na základě pravidla CFG asociovaného s pravidlem AG se vytvoří kontejner reverzních itemů (objekt třídy RevContainer). i. Výstupní proměnná output (zde ovšem zdrojová) se nastaví na kopii modelu model. ii. Pole input se naplní prázdnými lexémy, kterých je tolik, kolik je symbolů v pravidle CFG. iii. Pole revs se naplní reverzními itemy podle symbolů pravidla CFG pomocí jejich funkce createRevItem (návrhový vzor Factory), přičemž jejich modelem je lexém v poli input na odpovídající pozici. b. Na kontejner se reverzně aplikují tzv. konstrukční příkazy AG. Rekonstrukci je totiž zapotřebí provést dvoufázově: nejprve se zkonstruuje struktura a teprve poté se opětnou aplikací testovacích pravidel ověří její validita. Aplikace konstrukčních pravidel probíhá v pořadí deklarace-posttest-produkce-pretest, a to takto: i. Deklarační fáze proběhne stejně jako při aplikaci příkazů AG při parsingu. ii. Ve fázi posttest se aplikují příkazy ISA. iii. Ve fázi produkce se aplikují příkazy ASGAVAL a ASSIGN, avšak u příkazu ASSIGN nikoli takové příkazy, které se týkají přiřazování atributů, protože ty v tuto chvíli ještě nejsou k dispozici. iv. Ve fázi pretestu se vynechávají příkazy GOVERN a CMPAVAL a aplikuje se pouze reverzně příkaz LEXMATCH, jak je popsáno ve zvláštním odstavci. Reverzní příkaz LEXMATCH přiřadí reverzním itemům morfu hodnoty baseID, tedy PK bázových morfů. c. Po aplikaci konstrukčních příkazů AG se může u nepovinných neterminálů stát, že nebudou nijak realizovány, tj. že jim konstrukčními příkazy ASSIGN nebude přiřazena žádná lexikální jednotka. Takové reverzní itemy neterminálů (u kterých metoda isRealized vrací false) se nahradí umělou instancí třídy NullRev, tedy nerealizací. d. Následně se u všech reverzních itemů v poli revs zavolá rekurzivně metoda reconstruct. Metoda pro každý reverzní item může vrací pole výsledných reverzních itemů realizujících tento reverzní item. e. Na všechna tato pole se aplikuje kartézský součin podobně, jako je tomu v metodě NontermItem::receive. Pro každou kombinaci vzešlou z tohoto kartézského součinu se provedou tyto operace: i. Vytvoří se kopie kontejneru, ze kterého kombinace vznikla. 73
ii. Na tento kontejner se aplikují verifikační pravidla AG v tomto pořadí sekcí: produkce-pretest. Pravidla se provádějí v normální podobě, tedy nikoli reverzně. 1. V sekci produkce se provedou pravidla ASGAVAL a ASSIGN. 2. V sekci pretestu se provedou pravidla CMPAVAL a GOVERN. iii. Pro všechny kontejnery, které projdou všemi pravidly: 1. Vybere se jejich pole revs a jejich lexém output. 2. Vytvoří se nový reverzní item neterminálu obsahující toto pole revs a model odpovídající output. 3. Tento item se předá na výstup.
4.8.2 Metoda MorphRev::reconstruct Reverzní rekonstrukce morfu se volá až tehdy, když je provedena konstrukční fáze a pravděpodobně proběhl reverzní příkaz LEXMATCH, který morfu mohl přiřadit PK bázového morfu baseID. MorphRev načte všechny morfy, které mají baseID jako základní alomorf. Je-li multiplicita MorphRev 0..N, pak jsou povoleny i nulové morfy, v opačném případě nikoliv. Pokud není vyplněno baseID, načtou se všechny morfy z typu morfu specifikovaného proměnnou mt. Dále se pro všechny tyto morfy provede kartézský součin přiřazení hodnot atributů morfům a typům morfu, a to stejně, jako se to provádí v metodě MorphItem::lookup. Pro každou z těchto kombinací se metodou spawn vytvoří kopie tohoto reverzního itemu morfu, jeho modelu se přiřadí zjištěný PK morphID a hodnoty atributů této kombinace. Na výstupu metody je pak pole všech výsledných reverzních itemů morfu vzniklých z této kombinace.
4.8.3 Reverzní aplikace příkazu LEXMATCH Reverzní příkaz LEXMATCH operuje nad kontejnerem reverzních itemů. Zatímco běžný příkaz LEXMATCH na základě známých PK morfů nejprve nalezne jejich bázové morfy, sestaví z nich očekávané lemma lexému a pokusí se takový lexém najít mezi lexémy určitého lexikálního vzoru, reverzní příkaz LEXMATCH funguje opačně: Na základě známé lexikální jednotky lexému levostranné proměnné získá PK lexému a tedy jeho lemma. Lemma podle definice obsahuje množinu bázových morfémů. Podle uspořádané množiny symbolů morfu obsažené v pravidle LEXMATCH zjistí, kterým reverzním itemům morfu bázové morfémy přiřadit, a provede to. Reverzní příkaz LEXMATCH však selže tehdy, když lexikální vzor lexému levostranné proměnné nesouhlasí s lexikálním vzorem, který je argumentem příkazu LEXMATCH. Jsou-li některé pozice v množině symbolů morfu pro LEXMATCH vynechány, žádný bázový morfém se nepřiřazuje.
74
4.9 Algoritmus překladu Algoritmus překladu využívá ke svému chodu třídu kontejneru pro překlad (TransContainer), jež je popsána v následujícím pododstavci.
4.9.1 Kontejner pro překlad (TransContainer) Kontejner pro překlad je třída, která je analogická třídě LexVector ve zpracování příkazů AG. Stejně jako ona i třída TransContainer poskytuje adresační prostor pro překladová pravidla. Třída TransContainer obsahuje atributy: • • •
input – vstupní lexém reprezentující LR output – výstupní séma reprezentující SR temp – množinu deklarovaných proměnných překladu (TransVariable)
Podobně jako LexVector má i TransContainer metodu declareVariable pro deklaraci nové sémantické dočasné proměnné a metodu spawn pro hlubokou kopii.
4.9.2 Popis algoritmu Algoritmus pro překlad má na vstupu lexém reprezentující LR a na výstupu séma reprezentující SR. Pravidla TR mají zabezpečit překlad stromové struktury LR do odpovídající struktury SR. Překlad se realizuje voláním metody Lexeme::translate, která provádí následující operace: 1. Získá všechna pravidla překladu TR pro daný lexém. Připomeňme, že pravidlo TR (TransRule) obsahuje FK lexikální jednotky (luID) a FK sématu (semaID). 2. Pro každé z pravidel TR: a. Vytvoří novou instanci TransContainer. b. Jako input nastaví svou kopii. c. Aplikuje na TransContainer všechny příkazy TR. i. Ve fázi deklarace se provedou všechny příkazy DECLARE. ii. Ve fázi pretest se provedou nad lexémem tyto příkazy: 1. Příkaz CMPAVAL, který zjistí, zda výsledek tečkové adresace lexému má atribut odpovídající/neodpovídající testované hodnotě atributu. 2. Příkaz ISALEXUNIT, který zjistí, zda výsledek tečkové adresace lexému je/není konkrétní lexikální jednotkou nebo je/není potomkem této konkrétní lexikální jednotky, a to již popsaným algoritmem. iii. Ve fázi produkce se provedou tyto příkazy: 1. Příkaz ASSIGN, který přiřadí hodnotu mezi dvěma deklarovanými sémantickými proměnnými nebo ze sémantické proměnné do výstupní proměnné. Dojde-li k selhání adresace a příkaz ASSIGN je obligatorní, příkaz selže. 2. Příkaz TRANSLATE, který v případě, že chybí adresace obou stran, využije přímého překladu luID na semaID známého z pravidla TR. V případě, že je levá či pravá strana 75
adresována, je výsledkem překladu výsledek rekurzivně volané metody translate adresovaného lexému. Pokud dojde k selhání adresace a příkaz TRANSLATE je obligatorní, příkaz selže. iv. Ve fázi posttestu se provedou tyto příkazy: 1. Příkaz ISASEMA, který zjistí, zda výsledek tečkové adresace sématu je/není konkrétním sématem nebo je/není potomkem tohoto konkrétního sématu, a to již popsaným algoritmem. d. Řešením jsou všechny kontejnery, které projdou všemi příkazy TR. e. Na výstup se odevzdávají sémata, která vzešla z překladu.
4.10 Algoritmus zpětného překladu Zpětný překlad má na vstupu FK cílového jazyka a séma (objekt třídy Sema) reprezentující SR určené ke zpětnému překladu do LR cílového jazyka. Pro zpětný překlad není potřeba žádná zvláštní další entita, protože uvedený algoritmus překladu je dobře reverzibilní. Algoritmus využívá opět třídy kontejneru pro překlad (TransContainer) a realizuje se voláním metody Sema::reverseTranslate, která provádí následující operace: 1. Získá všechna pravidla překladu TR pro dané séma a daný cílový jazyk. Připomeňme, že pravidlo TR (TransRule) obsahuje FK lexikální jednotky (luID) a FK sématu (semaID). 2. Pro každé z pravidel TR: a. Vytvoří novou instanci TransContainer. b. Jako output nastaví svou kopii. c. Aplikuje na TransContainer zpětně všechny příkazy TR. Fáze při zpětném překladu jsou s výjimkou fáze deklarace v opačném pořadí i. Ve fázi deklarace se provedou všechny příkazy DECLARE stejným způsobem jako v normálním algoritmu překladu. ii. Ve fázi posttestu se provedou tyto příkazy: 1. Příkaz ISASEMA, který zjistí, zda výsledek tečkové adresace sématu je/není konkrétním sématem nebo je/není potomkem tohoto konkrétního sématu, a to již popsaným algoritmem. iii. Ve fázi produkce se provedou tyto příkazy: 1. Reverzně příkaz ASSIGN, který přiřadí hodnotu mezi dvěma deklarovanými sémantickými proměnnými nebo z výstupní proměnné do deklarované sémantické proměnné. Dojde-li k selhání adresace a příkaz ASSIGN je obligatorní, příkaz selže. 2. Reverzně příkaz TRANSLATE, který v případě, že chybí adresace obou stran, využije přímého překladu semaID na luID známého z pravidla TR. V případě, že je pravá nebo levá strana adresována, je výsledkem překladu výsledek rekurzivně volané metody reverseTranslate adresovaného sématu. Pokud dojde k selhání adresace a příkaz TRANSLATE je obligatorní, příkaz selže. 76
iv. Ve fázi pretest se provedou nad lexémem tyto příkazy: 1. Příkaz ISALEXUNIT, který zjistí, zda výsledek tečkové adresace lexému je/není konkrétní lexikální jednotkou nebo je/není potomkem této konkrétní lexikální jednotky, a to již popsaným algoritmem. d. Řešením jsou všechny kontejnery, které projdou všemi příkazy TR. e. Na výstup se odevzdávají lexémy, která vzešly z reverzního překladu.
4.11 Funkcionalita uživatelského rozhraní Uživatelské rozhraní koncipujeme jako grafické uživatelské rozhraní (GUI) typické pro informační systémy běžící na internetu. Způsob ovládání takových aplikací je obecně znám a není třeba jej obšírně popisovat. Ve zdrojovém kódu každé sekci GUI odpovídá zvláštní třída zakončená postfixem Gui (např. GrammarGui pro zpracování funkcionality týkající se gramatiky, LexGui pro funkcionalitu lexikonu apod.). HTML stránky s formuláři jsou generované statickými metodami označenými prefixem page, akce zpracovávající formulářová data odeslaná metodou HTTP POST (např. odeslání formuláře s detailem nějaké entity) nebo akce generované speciálním tvarem URL odesílaná metodou GET (například klepnutí na hyperlinku sloužící k prohození pořadí dvou entit) jsou zpracovávané metodami označenými prefixem action. Samotná konkrétní implementace GUI, a tedy způsob ovládání systému, je zřejmé z uživatelské příručky. Pomocí této příručky a v ní obsažených snímků obrazovky je možné ověřit, že všechny požadavky na funkcionalitu uživatelského rozhraní se řeší prostřednictvím implementovaného GUI.
4.11.1
Oddělení prezentace od datového modelu
GUI je striktně odděleno od databázových dotazů prostřednictvím vrstvy datové abstrakce (data abstraction layer). Tato vrstva je implementována třídami zakončenými 77
prefixem DL. Nikde v GUI se tedy nevyskytuje databázový dotaz, naopak se tyto požadavky delegují na třídy ~DL, které tyto požadavky vykonávají a navracejí do GUI již vhodně zformátovaná data. Z toho plyne, že při eventuelní výměně DBMS není třeba přeprogramovávat celé GUI, ale pouze vyměnit vrstvu datové abstrakce. Vrstva datové abstrakce dále komunikuje s modulem pro zpracování dotazů. Ten na nižší úrovni abstrahuje od nutnosti zpracovávat konkrétní programovou realizaci databázového dotazu (PHP funkce mysql_*), spravuje připojení k databázi, řeší chyby dotazů nebo chyby připojení k databázi apod.
4.11.2
Ošetření vstupů
Pro informační systém na architektuře klient-server je pro bezpečnost velmi důležité ošetření vstupů. V tomto konkrétním případě je třeba zajistit, aby nebylo možné provést žádnou akci, která by nevyhovovala integritním omezením. Pokud uživatel takovou akci provede, musí o tom být upozorněn. Znamená to tedy, že každé integritní omezení uvedené v analytické části musí být implementováno obslužnou metodou action, což také je. V sekci Testování je o ošetření vstupů podáno více informací.
4.12 Příklad naplnění Přestože předmětem práce není konkrétní naplnění systému daty, pokládám za vhodné ukázat způsob naplnění systému.
4.12.1
Morfologie
Morfy, jak je chápe systém, neodpovídají nutně morfům v klasickém lingvistickém popisu. Počítačové zpracování podle zde uvedeného modelu například implikuje, že cokoli, co se nějakým způsobem na nějaké pozici mění, je samostatným morfem.
4.12.1.1
Introflexe
Introflektivní jevy v češtině například vyžadují nestandardní morfologii. Příkladem budiž slovo bože (vokativ singuláru slova bůh). Ve standardním popisu by rozdělení na morfy bylo bož-e. Introflexe na o i na ž nás však nutí rozdělit lexém hned na čtyři morfémy a definovat například zvláštní lexikální vzor NounBůh pro slova jako bůh (dalšími lexémy tohoto vzory by byla slova stůl nebo dvůr) sestávající z těchto tříd morfů: NounBůhRoot, IfxUo, IfxH, NounPánEnd Typ morfu NounBůhRoot obsahuje morfy jako b, st, dv, které jsou samy sobě základními alomorfy. Typ morfu IfxUo obsahuje ů, o, kde ů je základní alomorf pro všechny ostatní morfy. Typ morfu IfxH obsahuje h, z, ž, kde základní alomorf je h. Typ morfu NounPánEnd obsahuje nulový morf (základní alomorf) a morfy a, e, u, em, y apod. Lexémy jsou pak b-ů-h-NULL, dv-ů-r-NULL apod.
78
4.12.1.2
Reduplikace
Anglická pravidelná slovesa lze rozdělit např. do těchto lexikálních vzorů: • • • •
VerbE obsahující slovesa končící na –e, jako create, engage apod. Obsahuje typ morfu VerbERoot (morfy creat, engag) a VerbEEnd (morfy e, es, ed, ing). VerbSimple obsahující slovesa končící na souhlásku, kde nedochází k reduplikaci, jako torment, stall, thwart apod. Obsahuje typ morfu VerbSimpleRoot (torment, stall, thwart) a VerbConsEnd (nulový morf a morfy s, ed, ing). VerbSs obsahující slova končící na dvě sykavky jako hiss, buzz apod. Obsahuje typ morfu VerbSsRoot (hiss, buzz) a VerbSsEnd (nulový morf, es, ed, ing). Problém tvoří slova jako skip, dub, ban, která při konjugaci reduplikují poslední konsonantu. Pro každou z těchto konsonant je třeba definovat nové typy morfu a nové lexikální vzory, např. pro lexikální vzor VerbRedupP by to byly typy morfu VerbRedupPRoot (skip), VerbRedupPP (nulový morf, p), VerbConsEnd.
4.12.2
Gramatika
Rudimentární gramatika češtiny, která přijímá např. větu Bůh stvořil zemi., je uvedena zde:
Oranžově jsou uvedeny symboly neterminálů, modře morfů, červeně separátorů. Barvou jsou vypsány typy morfů, resp. typy neterminálů. Šedě jsou označeny uživatelské popisy symbolů, které se používají při adresaci uvnitř pravidla. • Základní neterminál je Sent, který přijímá větu v pořadí subjekt-predikát-objekt. • První slovo (Arg) může být rozvito adjektivem (Adjective). • Adjektivum (Adjective) je zde modelováno jako tvrdý vzor (např. dob-r-ý, zele-ný) připravený na introflexi na druhém morfu (dob-r-ý/dob-ř-í apod.). • NounPlFilter přijímá podstatné jméno Noun a provádí na něm analýzu plurálu (viz dále v popisu pravidel AG pro toto pravidlo CFG). • U podstatných jmen uvádíme pravidlo pro rozpoznání lexémů v lexikálním vzoru NounBůh (viz výše) a NounZemě. • Lexikální vzor NounZemě je podobný vzoru růže, jen s tím rozdílem, že v některých tvarech má koncovka morf ě.
79
• •
Sloveso vzoru prosí (VerbProsí) sestává z nepovinné derivační VerbPre (nulový morfém, s, vy, u apod.), kořene RootProsí a koncovky EndProsí. Aby bylo možno ke slovesu připojit předponu ne (morf Neg), je pravidlo Verb, které expanduje na Neg a VerbBase, kde teprve přepisuje na VerbProsí.
předpony nepovinné vytvořeno VerbBase
Následují vybrané výpisy pravidel AG: Pro první pravidlo může být sada pravidel AG například:
Zde vidíme zpracování prvního pravidla. Předpokládá se, že existují atributy gender (jmenný rod), case (pád nabývající např. hodnot case1 nebo case4) a number (číslo). • • • • • •
Pravidlo 35 udává shodu (příkaz GOVERN) přísudku s podmětem v rodě, pravidlo 38 v čísle. V případě, že přísudek není příčestí minulé, nenese příznak rodu. V takovém případě příkaz GOVERN není vůbec aplikován, protože není splněna podmínka, že levostranný i pravostranný argument vykazuje atribut. Pravidla 37 a 43 vyžadují, aby podmět byl v 1. pádě, resp. předmět ve 4. pádě (příkaz CMPAVAL). Obligatorní příkazy ASSIGN v produkční části vytvářejí LR věty se slovesem valenčního rámce ACT1 PAT4. U pravidel 48 a 49 je vidět tzv. „tečková notace“. Zeleně jsou označeny sémantické valence. Příkazy jsou obligatorní proto, že pokud při syntéze není nalezen participant na valenční pozici Act nebo Pat, příkaz se neprovede a celé pravidlo selže. Pozn.: RESULT označuje výstupní proměnnou.
80
Předpokládejme existenci valence Mod, která integruje všechna volná doplnění (jako je i přívlastek shodný, AttribAgr). Vidíme, že v pravidle 114 je přiřazováno volitelné adjektivum. Pravidlo musí být fakultativní (optional), aby bylo zajištěno, že v případě neexistence adjektiva, popř. neexistence valenční cesty .Mod.AttribAgr pravidlo neselže.
Toto pravidlo AG zabezpečuje v volání příkazu LEXMATCH (č. 27). Rozpoznávají se morfémy Root, IfxUo, IfxH. Lexém se vyhledává ve vzoru NounBůh. V případě, že je lexém nalezen, jsou mu přiřazeny hodnoty pádu a čísla získané z koncovky a hodnota jmenného rodu získaná z kořene.
81
5. Analýza rizik Systém je vystaven množství rizik, která zde uvádíme společně s návrhem pro jejich zmírnění:
5.1 Seznam rizik 5.1.1 Rizika spojená s rozsahem produktu • • • • •
Projekt je středně velký, plánován cca mezi 10-20 tisíci řádek. Využívá databázi o 20-30 tabulkách, skládá se z řádově desítek tříd OOP. Stupeň důvěry v odhad velikosti a množství práce je relativně malý. Projekt je experimentální a není vyloučeno, že se objeví faktory, které práci prodraží. Systém není souměřitelný s předchozími produkty, protože neexistují žádné, které by mu byly podobné. Počet uživatelů produktu je malý, řádově do 10 osob, které se jím v první fázi budou zabývat. Není třeba klást nároky na GUI a použitelnost, protože projekt v této fázi není určen pro distribuci koncovým uživatelům. Množství znovupoužitého softwaru je minimální. Algoritmy a datové struktury jsou veskrze originální, projekt nenavazuje na žádný jiný projekt.
5.1.2 Rizika obchodního dopadu •
• • • •
Vzhledem k tomu, že se jedná o experimentální systém a není určený ke komerčnímu využití, nemá produkt vliv na zisk subjektů, které ho vyvíjejí. Jediný vliv produktu na zisk vývojářů je ten, že jim vývojem experimentálního systému vzniká ušlý zisk v hlavním zaměstnání. Zákazníci nekladou žádné finanční postihy za pozdní dodání či defektní produkt. Systém z principu nemůže být penalizován z důvodu svého experimentálního charakteru. Produkt nemusí spolupracovat s žádnými dalšími systémy. Neexistují žádné normy, které by upravovaly kvalitu produktu a kterým by produkt musel vyhovovat. Množství zákazníků produktu je v této fázi vývoje malé.
5.1.3 Procesní rizika • •
•
Projekt je vyvíjen jednou osobou – realizátorem – která při vývoji nespadá pod žádný subjekt. Evaluace procesů společnosti nemá tedy smysl. Realizátor jako fyzická osoba ovšem rozumí procesu softwarového vývoje a je zvyklý tento proces dodržovat ze své obvyklé práce. Má za sebou 6 let aktivní práce jako programátor-analytik v soukromé softwarové společnosti a 1 rok jako projektový manažer. Při své práci používá analytické nástroje. Specifikace produktu jsou během vývoje pravidelně přezkoumávána a kontrolována na jejich správnost, poněvadž korektnost vyvíjeného produktu je vzhledem k jeho smyslu (experimentální lingvistický systém a diplomová práce) esenciální.
82
5.1.4 Technické otázky • • • • • • •
Celý kód je napsán v PHP 5, což je objektově orientovaný programovací jazyk vyšší úrovně, pro nějž existují profesionální vývojářské nástroje. Pro dokumentaci kódu je používána standardní konvence phpDoc. Pro návrh testovacích dat, konfigurací změn, prototypování apod. se však nepoužívají žádné zvláštní nástroje. Software je psán na velmi dobře známé jazykové platformě. Komunikuje standardním způsobem s databází. Grafické uživatelské rozhraní je minimalistické a nekladou se na ně žádné vizuální požadavky. Projekt ovšem z principu vyžaduje používání ne zcela běžných algoritmů a modeluje ne zcela běžné skutečnosti. Systém modeluje zpracování přirozeného jazyka, což je neobvykle rozsáhlá a obtížná vědní disciplína. V této oblasti má vývojář určité znalosti dané zájmem o předmět studia, avšak nemá žádné např. akademické kvalifikace a existuje riziko, že systém nebude kvalitně jazyk modelovat.
5.1.5 Rizika spojená s vývojovým týmem • • • • •
Vývojový tým je malý – sestává právě z jedné osoby. Tato osoba má vynikající kvalifikaci a zkušenosti v návrhu informačních systémů v daném programovacím jazyce a při použití daného DBMS. Vývojový tým bohužel není vyčleněn na celou délku trvání projektu, protože projekt není financován, a tak na něm musí vývojář pracovat ve svém volném čase paralelně s hlavním zaměstnáním. Pracovník nemá žádné finanční ohodnocení, což však není na újmu motivace, poněvadž žádné finanční ohodnocení ani neočekává. Případný úbytek pracovníků by byl pro kontinuitu projektu zcela kritický.
5.2 Vyhodnocení rizik •
• • •
•
Rozsah produktu přináší střední míru rizika. Přestože projekt není neúnosně velký, je i tak relativně rizikový z důvodu své novosti. Jedná se o návrhovou práci experimentálního charakteru s minimálním množstvím znovupoužitelného softwaru. Na druhou stranu nejsou kladeny žádné požadavky na přístupnost a použitelnost, což v mnohém tato rizika vyvažuje. Riziko obchodního dopadu je minimální. Případné selhání projektu nebude mít žádné obchodní následky. Procesní rizika jsou malá. Vývojář je dobře obeznámen se softwarovými metodikami a má praxi v oboru. Co se týče technických otázek, z hlediska použitých technologií jsou rizika minimální (používají se dobře známé a prakticky prozkoušené technologie), což však neplatí o modelované skutečnosti, kde existuje poměrně vysoké riziko selhání. Celkové riziko je střední. Rizika spojená s vývojovým týmem jsou střední. Přestože je realizační tým na dobré profesionální úrovni, nemůže věnovat projektu veškerý pracovní čas. Dále v projektu chybí lidské rezervy pro případ výpadku lidského faktoru. 83
5.3 Návrhy na zmírnění rizik • • •
Rizika již nelze zmírnit v technologických otázkách, protože ty jsou na dobré úrovni – používají se vhodné a dobře známé technologie. Naopak lze rizika zmírnit lepší kontrolou projektu v oblasti lingvistické, tedy pravidelnější konzultaci se skutečnými odborníky v oboru. Dále by bylo možné zmírnit rizika spojená s vývojovým týmem zvýšením finančního ohodnocení vývojáře, takže by nemusel věnovat tolik času jiným, finančně zajímavějším projektům, je však otázka, kde na takovou eventualitu v současné situaci vzít zdroj financování.
84
6. Testování 6.1 Black-box testing Systém bude otestován metodou black-box testing, ve které se nepředpokládá žádná znalost vnitřní struktury testované entity. Do systému se vkládají správné a nesprávné vstupy a očekává se adekvátní výstup.
6.2 Návrh testů S ohledem na charakter systému proveme následující testy:
6.2.1 Test 1: test jazykového popisu 1. Předpokládejme vhodně zadaný jazykový popis, který využívá všech rysů systému. a. Těmito rysy jsou vložené jazykové informace (typy morfů a morfy s přiřazenými hodnotami atributů; lexémy odpovídající lexikálním vzorům s přiřazenými lexikálními jednotkami), gramatické informace (gramatická pravidla rozpoznávající určité věty a celé spektrum definovaných příkazů pravidel AG), jazykově nezávislé informace (definice ontologie sémat) a překladové informace (využívající celého spektra definovaných příkazů TR). 2. Funkčnost systému bude pozitivně ověřena, pokud systém správně přeloží větu odpovídající danému popisu. 3. Funkčnost systému bude negativně ověřena, pokud systém naopak nesprávný vstup (nevyhovující pravidlům) odmítne a vydá chybovou hlášku.
6.2.2 Test 2: test ověřování vstupů z GUI 1. Vzhledem k tomu, že se jedná o aplikaci poskytující GUI, je třeba toto GUI otestovat. 2. Funkčnost GUI bude pozitivně ověřena, pokud veškerá funkcionalita uvedená v analytické části povede k očekávaným výsledkům. 3. Funkčnost GUI bude negativně ověřena, pokud nekorektní vstupy z GUI nebudou systémem akceptovány a systém uživateli ohlásí adekvátní chybové hlášky.
6.3 Provedení testů 6.3.1 Test 1: test jazykového popisu V testovacím příkladu necháme přeložit větu Bůh stvořil zemi. z češtiny do angličtiny a zobrazit výsledky jednotlivých fází překladu:
85
Vidíme, že program vygeneroval v souladu se specifikací více překladů. Je tomu tak proto, že gramatika angličtiny byla zadána nejednoznačně: nepodporuje mluvnické číslo (aktant Number). Provedeme nyní negativní test: tentýž text necháme přeložit z angličtiny do češtiny. Překladač by měl oznámit chybu, neboť „Bůh stvořil zemi.“ není korektní anglická věta.
86
Vidíme, že v tomto případě systém korektně oznámil uživateli chybu.
6.3.2 Test 2: kontrola správnosti vstupů Zatímco pozitivní kontrola správnosti vstupů je realizována ověřením, že se ve všech bodech program chová podle uživatelské příručky, ověříme nyní negativní kontrolou, že program ověřuje a reportuje nesprávné vstupy.
6.3.2.1
Test integritního omezení při smazání
Integritní omezení diktují, že není možné smazat neterminál, na který jsou navázána některá pravidla.
Pokud uživatel varovné hlášení ignoruje, systém přesto vstup zkontroluje a zahlásí chybu.
87
6.3.2.2
Test správného zadání pravidla AG
Další test správného zadání vstupů bude proveden na pravidle AG. Při definici levostranné adresace „tečkovou adresací“ je nutné, aby všechny valence existovaly.
Při takovém zadání systém zahlásí chybu:
88
6.4 Vyhodnocení testů Byly provedeny testy black-box testingem na správné zpracování správných vstupů systémem a naopak zahlášení chyby při zadání vstupů nekorektních. Tyto testy byly provedeny jak na centrální funkcionalitě překladu s využitím všech rysů, které systém pro zpracování jazyka nabízí, tak na funkcionalitě grafického uživatelského rozhraní, při které došlo k ověřování kontroly korektnosti uživatelských vstupů. Testy byla prokázána správná funkčnost programu: • •
při zadání správných vstupů byly vstupy akceptovány a systém provedl očekávané operace při zadání nesprávných vstupů byly vstupy odmítnuty a systém zahlásil uživateli chybové hlášení
Vzhledem k rozsáhlosti systému a četnosti integritních omezení v této práci neuvádíme výsledky testů všech integritních omezení, která systém obsahuje a která jsou definována v analytické části. Výsledky testů jsou obdobné a není je zde třeba poskytovat všechny.
89
7. Závěr 7.1 Dosažené cíle Tato práce si klade za cíl navrhnout způsob modelování přirozeného jazyka za účelem strojového překladu, jež by bylo založeno na uživatelsky definovaných pravidlech a umožňovalo k překladu využívat univerzální vnitřní formy běžně označované jako interlingua. Dále je cílem této práce poskytnout aplikaci pro provádění tohoto způsobu, která by umožňovala uživatelům definovat jazykově závislou reprezentaci nějakého přirozeného jazyka i jazykově nezávislý univerzální sémantický popis. Způsob modelování přirozeného jazyka má adresovat některé vybrané problémy, s nimiž se setkáváme při zpracování přirozeného jazyka, jako je víceznačnost na různých úrovních popisu jazyka, gramatické vztahy mezi větnými členy (shoda), morfologické změny slov apod. Tohoto cíle se dosahuje prostřednictvím navržené a implementované webové aplikace, která umožňuje uživatelům editovat jazykově závislou i jazykově nezávislou reprezentaci. Teoretický přístup ke zpracování jazyka, který se používá při specifikaci obou úrovní reprezentace, je inspirován funkčním generativním popisem (FGP) a valenční teorií. Program aplikuje na vstupní text pravidla bezkontextové atributové gramatiky tak, aby se text převedl do lexikální reprezentace (LR) ve formě stromu. Tuto reprezentaci pak převede do ekvivalentní jazykově nezávislé sémantické reprezentace (SR). Zpětnou aplikací těchto pravidel ji převede opět do LR v cílovém jazyce a rekonstruuje z ní cílový text. V případě víceznačností přivede program na výstup všechna řešení, v případě nenalezení žádných řešení se ohlásí chyba.
7.2 Výhled Tato práce představuje dobrý základ k dalšímu pokračování. Směrů, kam pokračovat, existuje mnoho. Uživatel by například mohl do procesu překladu zasahovat již během některé z jeho fází a usměrňovat je, čímž se omezí množství generovaných řešení při výskytu víceznačností. Stromová struktura, a tedy dobrá adresovatelnost reprezentací LR a SR umožňuje snadno zavést do jazykového popisu koreference, které by uživatel mohl sám editovat. Vzhledem k tomu, že jsou již navrženy způsoby transformace stromových reprezentací do jiných, dala by se jazykově nezávislá reprezentace obohatit o pravidla převodu struktur v rámci jí samé. Tím by se systém naučil odvozovat složitější významy z jednodušších nebo je zpětně analyzovat, což by pro překlad byla velmi užitečná vlastnost. Dále by se systém dal rozšířit o možnost importu dat z jiných systémů. Vzhledem k povaze systému by se dalo uvažovat o importu definic z valenčních slovníků.
90
8. Literatura [1]
NIEL, F.: Traduction automatique. Science et vie micro, 1986.
[2]
Translation in the Commission: where do we stand eight months after enlargement? [online]. 13.1.2005 [cit. 13.5.2010]. Dostupné z:
.
[3]
LAGOUDAKI, E.: Translation Memory systems: Enlightening users' perspective. In: Translation Memories Survey 2006. [online] 2006. [cit. 13.5.2010] Dostupné z:
[4]
STROSSA, P.: Vybrané kapitoly z počítačového zpracování jazyka. Opava: Slezská univerzita v Opavě, Filozoficko-přírodovědecká fakulta, Ústav informatiky, 1999.
[5]
PIRON, C.: Le défi des langues (The Language Challenge). Paris: L'Harmattan, 1994.
[6]
ALTMANN, G.: Výstup na babylonskou věž. Praha: Triáda, 2005.
[7]
DANEŠ, F. – HLAVSA, Z. et al.: Větné vzorce v češtině. Praha: Academia, 1981.
[8]
YALE, P. – CAMPBELL, V. – PLUNKETT, R. Turecko – z řady průvodců Lonely Planet. Praha: Svojtka, 2007.
[9]
SGALL, P. Generativní popis jazyka a česká deklinace. Praha: Academia, 1967.
[10]
The Prague Dependency Treebank 2.0 [online] 2006. [cit. 13.5.2010]. Dostupné z:
[11]
LOPATKOVÁ, M. Vallex. The Valency Lexicon of Czech Verbs with Complex Syntactic-Semantic Annotation. [online] 2006. [cit. 13.5.2010]. Dostupné z:
[12]
MELICHAR, B. – ČEŠKA, M. – JEŽEK, K. – RICHTA, K. Konstrukce překladačů, I. část. Praha: Vydavatelství ČVUT, 1999.
91
9. Seznam zkratek AG
Atributová gramatika
CFG
Bezkontextová gramatika (context-free grammar)
DAG Orientovaný acyklický graf (directed acyclic graph) DBMS Systém řízení bází dat (database management system) FGP
Funkční generativní popis
FK
Cizí klíč (foreign key)
GG
Generativní gramatika
GUI
Grafické uživatelské rozhraní (graphical user interface)
IC
Bezprostřední složky (immediate constituents)
ISA
Relace mezi objektem a jeho předkem (=is a)
HTTP HyperText Transfer Protocol, protokol běžně používaný pro přenos webového obsahu po Internetu PDT Pražský závislostní korpus (Prague Dependency Treebank) PHP Interpretovaný programovací jazyk PHP vhodný pro psaní serverových webových aplikací PK
Primární klíč (primary key)
LR
Lexikální reprezentace
LU
Lexikální jednotka (lexical unit)
MT
Strojový překlad (machine translation)
SR
Sémantická reprezentace
TR
Pravidlo překladu (translation rule)
VALLEX
Valenční slovník VALLEX (VALency LEXicon)
92
10. Instalace a konfigurace 10.1.1
Instalace podpůrného softwaru
Program ke své činnosti potřebuje: • • •
nainstalovaný webový server, nainstalovanou podporu programovacího jazyka PHP 5, nainstalovaný DBMS MySQL 5.
Všechny tyto činnosti jsou detailně popsány na: VEČEŘA, Z. Instalace nejnovější verze Apache 2.0, PHP 5.2.x a MySQL 5.0 krok za krokem. [online] 14.1.2007 [citace 13.5.2010]. Dostupné z:
10.1.2
Instalace aplikace
1. Zkopírujte zdrojové kódy aplikace do adresáře pro skripty. 2. Upravte Config/Config.php pro připojení k vašemu databázovému stroji. 3. Spusťte SQL dávku install.sql na databázovém stroji pro vytvoření databáze.
93
11. Uživatelská příručka V této sekci budou pomocí snímků obrazovky vysvětleny všechny aspekty GUI.
11.1 Přihlášení do systému
Přihlášení do systému se provádí pomocí jména a hesla, které vám poskytne administrátor, a stiskem tlačítka vstoupit.
11.2 Orientace v systému
Horní lišta obsahuje obvykle dva řádky. Horní řádek označuje sekci, dolní řádek je kontextový a mění se podle sekce. Klepnutím na odkaz se přemístíte na příslušnou stránku.
V levém rohu uvidíte uživatelské menu, prostřednictvím něhož se můžete odhlásit ze systému nebo přejít na editaci uživatelských informací.
11.3 Uživatelské informace
94
Na této stránce si můžete změnit heslo, což je při prvotním přihlášení nového uživatele dokonce nutné.
11.3.1
Překlad
Na této stránce můžete otestovat zadání dat do systému přeložením nějaké věty. Vyberete vstupní a výstupní jazyk, zaškrtnete dodatečné volby a stisknete Přeložit. Je-li překlad úspěšný, uvidíte překlad, eventuelně parsovací stromy.
95
11.4 Jazyky
Na stránce jazyků můžete vybrat aktivní jazyk, ve kterém chcete pracovat. Stisknutím křížku můžete jazyk smazat, pokud v něm nejsou žádné definice. Ikonou „Přidat jazyk“ můžete přidat jazyk. Informace o jazyku můžete změnit klepnutím na název jazyka.
96
11.5 Morfologie 11.5.1
Typy morfů
Sekce „Morfologie“ umožňuje přidávat a mazat typy morfů. Klepnutím na název typu morfu přejdete do editace typu morfu, kde můžete změnit název typu morfu, přidat skupinu přiřazení atributů, vymazat skupinu přiřazení, vymazat jedno přiřazení ze skupiny přiřazení, přidat přiřazení do skupiny a nastavovat hodnoty v přiřazení. Zde i jinde v systému se data zobrazují v tříditelné tabulce. Klepnutím na záhlaví tabulky ji setřídíte podle daného kritéria. Bledě modrý proužek je stránkovač – použijte jej, pokud se výsledky nevejdou na jednu stránku.
97
11.5.2
Morfy
Na stránce morfů vidíte přehled morfů v tříditelné tabulce. Ve sloupci Hodnota se zobrazují hodnoty morfů, případně null pro nulový morf. V dalším sloupci jsou základní alomorfy morfů. Je-li morf sám sobě základním alomorfem, je označen hvězdičkou. Dále následují výpis přiřazených atributů. Morfy lze přidávat a mazat. Klepnutím na hodnotu morfu přejdete do detailu morfu.
Na stránce detailu morfu lze změnit hodnotu morfu, nastavit základní alomorf, přidat/odebrat skupinu přiřazení, přidat/odebrat přiřazení ve skupině a nastavit hodnoty přiřazení.
98
11.6 Atributy a hodnoty 11.6.1
Atributy
Na stránce s atributy je k dispozici tabulka atributů s vypsanými hodnotami. Je možno atribut přidat nebo prázdný atribut vymazat. Klepnutím na název atributu přejdete na detail atributu, klepnutím na detail hodnoty přejdete na detail hodnoty.
V detailu atributu je možné atribut přejmenovat.
11.6.2
Hodnoty atributů
Na stránce s hodnotami atributů lze hodnotu vymazat nebo přidat novou. Klepnutím na název hodnoty přejdete do editace hodnoty, kde ji lze přejmenovat analogicky se stránkou detailu atributu.
99
11.7 Gramatika 11.7.1
Přehled pravidel
Na této stránce je vidět přehled pravidel. Klepnutím na „Přidat neterminál“ lze přidat nový neterminál. Ikona smazání ve sloupci „Název“ maže neterminál, ikona přidání přidává neterminálu nové pravidlo. Klepnutím na název neterminálu jej lze přejmenovat. Ve sloupci pravidla ikona lupy vede na detail pravidla s editací atributové gramatiky. Ikona smazání maže pravidlo. Ikona přidání přidává nový symbol na konec pravidla, přičemž se otevře okno editace symbolu. Ikona popelnice vymaže symbol z pravidla. Ikona lupy v posledním sloupci opět vede na atributovou gramatiku. Číslo vedle ní udává, kolik pravidel AG pravidlo má. Oranžové symboly jsou neterminální, modré symboly jsou symboly morfů, červené jsou separátory. Šedivý text je název symbolu.
11.7.2
Editace symbolu
V editaci symbolu lze symbol pojmenovat. Je třeba vybrat typ symbolu (symbol separátoru, morfu nebo neterminálu) a multiplicitu. U symbolu morfu se vybírá typ morfu, u symbolu neterminálu se vybírá neterminál. Ikonami „vlevo“ a „vpravo“ lze měnit pořadí editovaného symbolu v rámci pravidla.
100
11.7.3
Detail pravidla
V detailu pravidla je vidět atributovou gramatiku. Jednotlivá pravidla AG jsou barevně odlišena. V rámci jednoho pravidla jsou rovněž barevně odlišeny sekce. Klepnutím na „Přidat pravidlo AG“ se přidá nové pravidlo AG. Ve sloupci Pravidlo ikona smazání maže pravidlo, ikona přidání přidává nový příkaz do pravidla, ikona smazání ve sloupci „Příkaz“ maže příkaz, ikona lupy otevírá detail příkazu. Příkazy AG mají barevně zvýrazněnou syntaxi. Nemusíte se učit žádný jazyk, všechno je možné navolit z menu. Tmavomodře se označují atributy. RESULT symbolizuje výstupní proměnnou. Zeleně je označena cesta přes lexikální valence v tečkové notaci. Poznámky OBLIGATORY/OPTIONAL označují, zda je příkaz obligatorní (nesmí v něm dojít k chybě) nebo fakultativní.
11.7.4
Detail příkazu
V detailu příkazu si můžete navolit libovolný příkaz. Valenční cesta se zadává názvy lexikálních valencí (musíte je znát) oddělených tečkou. V horní liště si vybíráte fázi, do
101
které bude příkaz patřit; podle toho se vám budou kontextově měnit možné příkazy. Např. pro fázi pretest vypadá detail příkazu takto:
Všimněte si způsobu zápisu příkazu LEXMATCH. Je vidět, že na poslední proměnnou se nebere zřetel – pro vypuštění testu můžete tedy použít pomlčku.
11.8 Lexikon 11.8.1
Lexikální vzory
Na stránce s lexikálními vzory vidíte přehled lexikálních vzorů. Lexikální vzor je možné přidat nebo smazat. Klepnutím na název přejdete do detailu vzoru.¨
102
V detailu lexikálního vzoru můžete přepsat název a popis. Ikona popelnice ze vzoru odstraní typ morfu. Stiskem tlačítka uložit se vzor změní na nastavené hodnoty. Je-li vybrána hodnota „přidat na konec“, pak se přidá na konec.
11.8.2
Lexémy
Na stránce lexémy je přehled lexémů. Lexémy lze přidávat a mazat. Ve sloupci Lemma je vidět čitelné lemma i lemma rozdělené na morfy pomlčkami. Varovně je označeno lemma, které není nastaveno. Napravo je seznam lexikálních jednotek (LU) připojených k danému lexému včetně jejich bezprostředně nadřazené jednotky. Klepnutím na název lemmatu se dostaneme na editaci lexému.
Pro pozice dané lexikálním vzorem lze vybrat pro lemma morfy. Dále lze odpojit nebo připojit další lexikální jednotku. Ikonou lupy lze přejít na konkrétní lexikální jednotku.
11.8.3
Lexikální jednotky
Seznam základních lexikálních jednotek obsahuje takové, které nemají žádného rodiče. Ikona smazání smaže jednotku, ikona přidání přidá pod jednotku podjednotku. 103
Klepnutím na název jednotky nebo na lupu u výpisu počtu překladů se přejde do editace jednotky, jinak se přejde do stromové struktury na úrovni dané jednotky.
Zobrazení na jiné úrovni je analogické, pouze přibývá navigační tlačítko přechodu na vyšší úroveň.
V detailu jednotky lze přepsat název a popis. Je-li z padacího menu vybráno séma, přidá se pro ně nový překlad. Pod tabulkou je seznam překladů k sématu, které je uvedeno ve sloupci Séma. Ikona smazání ve sloupci Překlad maže celý překlad, ikona přidání přidává nový příkaz. Ikona smazání ve sloupci Příkaz maže příkaz, ikona lupy přechází na editaci překladového příkazu.
104
11.8.4
Editace příkazu překladu
Editace příkazu překladu je analogická způsobu editace příkazu AG a platí pro ni stejný způsob použití.
11.8.5
Lexikální valence
Stránka s lexikálními valencemi sestává z pouhého číselníku analogickému jiným podobným stránkám. Opět je k dispozici možnost přidání, smazání a editace.
11.9 Sémantika 11.9.1
Sémata
105
Editace sémantické roviny na základní rovině připomíná rovinu lexikální. Opět lze sémata přidávat a mazat. Odkazy ale vedou na totéž místo, tedy editaci detailu sématu.
V detailu sématu vidíme jak bezprostřední předchůdce a následníky, tak i všechny předky a potomky. Klepnutím lze přejít na dané séma. Ikonou popelnice se séma od daného sématu odpojí. Lze přepsat název a popis. Je-li z padacího menu vybráno séma, potvrzením formuláře se toto séma pod ně připojí.
11.9.2
Sémantické valence
Stejně jako v případě lexikálních valencí, tak i zde sémantické valence jsou prostý číselník. Ten lze upravovat přidáváním, mazáním a editací názvů.
106
Obsah přiloženého CD /Config – konfigurační skript /Data – databázová abstrakční vrstva /Gui – třídy pro GUI /images – obrázky používané aplikací /Lang – třídy pro popis jazykově závislé úrovně /Meaning – třídy pro popis jazykově nezávislé úrovně /Text – třídy pro generování jazykově závislé úrovně z textu /Util – pomocné funkce /*.php – základní skripty pro běh programu /install.sql – MySQL dávka pro vytvoření databáze /DP.pdf – tato diplomová práce
107
