• Nie Znaleziono Wyników

Ocena informacji tekstowej metodą Conceptual Dependency

W dokumencie Index of /rozprawy2/10469 (Stron 69-83)

De-pendency

Należy zauważyć, że o ile wyszukiwanie informacji w tekście poprzez obecność słów kluczowych może prowadzić do wysokiej skuteczności (popularne indeksery i wyszukiwarki internetowe potrafią zwracać miliony adresów zawierające poszuki-wane słowa), o tyle jakość wyników biorąc pod uwagę całą przestrzeń zwróconych dokumentów będzie niska. Strony (szczególnie te znajdujące się w tzw. długim ogonie listy rezultatów) będą zawierały teksty, które w żaden sposób nie wiążą się z tematyką poszukiwania, najczęściej przypadkowo zawierając słowa kluczo-we, wyrwane z kontekstu, lub też użyte w zupełnie innym znaczeniu (problem wieloznaczności). Prowadzi to do sytuacji, w której obecne systemy wyszukiwania

65

informacji, dysponując nadmiarem informacji o niskiej jakości, nie radzą sobie z jej filtrowaniem, obarczając tym zadaniem użytkownika końcowego wyszukiwarki internetowej.

Należało wobec tego zaproponować rozwiązanie, które w sposób znacząco lep-szy w stosunku do technologii słów kluczowych potrafiłoby reprezentować infor-macje i jej wzorce w tekście. Rozwiązanie takie powinno w sposób precyzyjny definiować zakres informacji interesujący dla odbiorcy oraz powinno zapewnić selekcję tylko tych dokumentów, które spełniają wymogi jakościowe ponad ilo-ściowymi. Problematyka ta jest jednak o tyle złożona, że cytując za [37] „brak formalnego modelu informacji semantycznej zmusza do posługiwania się modelem intuicyjnym”.

Rozważając model reprezentacji informacji należy mieć na uwadze cel jego tworzenia przez co powołując się na przytoczonego autora należy przywołać de-finicję ekstrakcji informacji.

Definicja 4.2. Ekstrakcja informacji jest to proces identyfikacji (rozpoznania) w

konkretnym tekście pochodzącego z zewnątrz (spoza analizowanego tekstu) sche-matu informacyjnego oraz ocena stopnia dopasowania schesche-matu i tekstu.

Lubaszewski w [37] przedstawia klasyczny schemat informacji przygotowywa-ny ręcznie, który bazując koncepcyjnie na teorii Conceptual Dependency Shanka [60] stanowi wybrany podzbiór tej teorii. Schemat ten bazuje na budowie formu-larza stanowiącego stereotyp zdarzenia, w którym wyszczególnione zostają role jakie pojawić mogą się w opisywanym tekście, np.:

• Zdarzenie • Sprawca • Cel • Obiekt • Miejsce • Narzędzie • Czas

Schemat ten następnie wypełniany jest regułami dopasowania. Najprostszym przykładem reguł dopasowania jest obecność w zdaniu formy wyrazu będące-go na liście wyrazów danebędące-go slotu (roli). Budowa skryptu uwzględnia trzy części: syntetyczną, analityczną oraz część okoliczności.

Pierwsza część skryptu – syntetyczna – służy do syntetycznego opisu stereo-typu zdarzenia, a więc takiego który precyzyjnie wypełnia wszystkie role zdefi-niowane w zdaniu. Stwierdzenia w tej postaci mają najczęściej formę zdań oznaj-miających stwierdzających dany fakt lub stan świata.

Druga i trzecia część skryptu – analityczna i okoliczności – służą do opisu ana-litycznego, czyli takiego w którym zdarzenie opisywane jest jako logiczna (często wariantywna) sekwencja zdań. Jest to metoda, która umożliwia użyć kontekstu w analizie semantycznej zdań, który powoduje zmianę w sposobie oceny seman-tycznej poszczególnych zmian.

Przykładowo typowe zdanie syntetyczne mówiące o czynności picia herbaty można zapisać w następujący sposób:

Jan wypił herbatę.

jednakże opis ten może być także skonstruowany w sposób analityczny:

Leniwie rozglądnął się po pokoju. Wzrokiem odnalazł szafkę, z której wyciągnął kubek. Woda już wrzała. Zaparzył herbatę wąchając unoszącą się woń. Powoli de-lektował każdy łyk.

Jak widać druga sekwencja zdań wyraźnie wskazuje na czynność picia herbaty, jednakże żadne ze zdań nie zawiera wprost wyrazów „pić” i „herbata”. Dodat-kowo całe zdarzenie może odbywać się podczas konkretnych okoliczności, które także mogą być zawarte w skrypcie:

Leniwie rozglądnął się po pokoju. Wzrokiem odnalazł szafkę, z której wyciągnął kubek. Woda już wrzała. Zaparzył herbatę wąchając unoszącą się woń. Powoli delektował każdy łyk. Zachodzące słońce Peru wdzierało się przez wpółotwarte okiennice.

Do reprezentacji danych w skrypcie ostatecznie zdecydowano się skorzystać z języka yaml2, który jest uniwersalnym formatem serializowania struktur da-nych. Wsparcie dla języka yaml w postaci biblioteki dostępne jest dla większości popularnych języków programowania. Yaml bazuje na prostej reprezentacji tek-stowej. W odróżnieniu od języka XML zapewnia stosunkowo dużą czytelność kodu przez człowieka oraz niski narzut formatowania. Istotną zaletą języka yaml jest także fakt, że deserializacja produkuje reprezentacje danych w natywnych strukturach danych użytego języka programowania. Pozwala to w dużym stopniu na niezależność od języka implementacyjnego oraz znacznie uprasza sam proces implementacji.

Przykładowy skrypt zapisany w języku yaml ma następującą postać: analytic:

sentences:

67 - obligatory: true slots: - name: slot_name1 obligatory: true weight: 50 min: 1 tokens: [] threshold: 50 threshold: 50 circumstances: sentences: [] threshold: 10 weight: 50 name: test synthetic: threshold: 50 sentences: - obligatory: true slots: - name: obiekt obligatory: true weight: 35 min: 1 tokens:

- {type: Word, value: 285668672} - name: obiekt1

obligatory: true weight: 15

min: 1 tokens:

- {type: Word, value: 285944176} threshold: 50

Części skryptu

Skrypt na poziomie najwyższym reprezentowany jest jako mapa (tablica z haszowaniem). analytic: <część skryptu> synthetic: <część skryptu> circumstances:

<część skryptu>

Klucze tablicy odpowiadają trzem częściom skryptu: • synthetic – część syntetyczna skryptu,

• analytic – część analityczna skryptu, • circumstances – część okoliczności skryptu.

Kolejność części skryptu w pliku yaml może ulec zmianie i nie ma ona znaczenia praktycznego.

Każda z części zawiera kolejną mapę z kluczami: • sentences – lista zdań części skryptu,

• weight – waga części skryptu,

• threshold – wartość liczbowa progu wagi zdań części skryptu, używana aby stwierdzić czy część skryptu została dopasowana ze względu na dostateczną ilość dopasowanych zdań.

Przykładowo: circumstances: sentences: [ <zdanie>, ] threshold: <liczba> weight: <liczba> Zdania skryptu

Każda część składa się z listy zdań (sentences). Element sentences zawiera listę zdań. Każde ze zdań w skrypcie reprezentuje wzorzec (schemat) informacyjny zdania, które może być wyszukane w tekście. Część syntetyczna powinna zawierać tylko jedno zdanie (z założenia). Należy odróżnić zdania skryptu script sentences od zdań tekstu, gdzie te pierwsze są wzorcem informacji, a te drugi tekstem w języku naturalnym. Pojedyncze zdanie skryptu ma następujący format:

sentences:

- obligatory: <true | false> treshold: <liczba>

weight: <liczba> slots: [ <slot>, ] - <zdanie>

69

• obligatory – obligatoryjność zdania oznacza czy dopasowanie zdania jest bezwzględnie wymagane, aby dopasowanie części skryptu powiodło się; ob-ligatoryjność jest drugim poza użyciem wag i progów niezależnym warun-kiem dopasowania informacji w skrypcie; może przyjmować wartości true lub false,

• threshold – wartość liczbowa progu wagi używana w celu weryfikacji czy dopasowane elementy zdania zawierają odpowiednią wartość informacyjną aby nastąpiło dopasowanie,

• weight – waga zdania, która zostanie przekazana do części skryptu jeśli całe zdanie zostanie dopasowane (waga może być także ujemna, co może być wykorzystywane w postaci zdań dyskryminujących pewne schematy informacyjne przed dopasowaniem),

• slots – lista slotów zdania.

Sloty

Kolejną jednostką dopasowania na niższym poziomie abstrakcji jest slot. Jest to pojedyncza rola w tekście. Slot reprezentowany jest poprzez następującą struk-turę danych: slots: - name: <tekst> obligatory: <liczba> weight: <liczba> min: <liczba> tokens: [ <token>, ] - <slot>

Slot złożony jest z następujących elementów:

• name – nazwa slotu, nazwa nie uczestniczy w procesie dopasowania, ma tylko charakter informacyjny podczas analizy rezultatów dopasowania, • obligatory – obligatoryjność slotu, która określa czy slot musi zostać

do-pasowany, aby dopasowanie całego zdania mogło zaistnieć (niezależnie od wag),

• weight – waga slotu, która zostanie przekazana do zdania jeśli cały slot zostanie dopasowany (waga może być także ujemna, co może być wykorzy-stywane w postaci slotów dyskryminujących pewne schematy informacyjne przed dopasowaniem),

• min – wartość liczbowa określająca ilościowo liczbę dowolnych różnych to-kenów slotu, które muszą zostać dopasowane, aby slot został dopasowany, • tokens – lista tokenów slotu.

Tokeny

Token jest to elementarna jednostka wyszukiwania, której można użyć przy budowie skryptów. Ze względu na to, że w mechanizmie skryptów koncepcyjnie przewidziano, iż dopasowanie elementów semantycznych w zdaniu dalekie jest od dopasowywania pojedynczych napisów, form czy wyrazów, do reprezentacji tych elementów potrzebna była dodatkowa warstwa abstrakcji, która jest repre-zentowana poprzez token. Pojedynczy wyraz jest więc jedną z wielu możliwych specjalizacji abstrakcyjnego tokenu. Do reprezentacji tokenu wybrano następują-cy schemat:

tokens:

- type: <text - typ tokenu> case: <true | false> value: <dowolna wartość> - <token>

Pojedynczy token zawsze związany jest z typem, który wskazuje na konkretną specjalizację i określonym tutaj polem type. W związku z tym interpretacja pola value jest wariantywna i zależy od typu użytego tokenu. Pole case informuje czy wielkość liter w porównywaniu tokenu do tekstu oryginalnego ma znaczenie.

Token należy traktować jako wzorzec, który w zdaniu może posiadać kon-kretną reprezentację. Może być ona pojedyncza, mnoga lub nawet nieskończenie wariantywna. Jednym z rodzaju tokenów może być więc pojedyncza forma wyra-zu swyra-zukana dosłownie. W zależności od przyjętego podejścia i wartości pola case, formę może reprezentować pojedynczy ciąg znaków, bądź też kilka różnych cią-gów znaków dopuszczając możliwość pominięcia polskich znaków diakrytycznych czy uwzględniając różną wielkość liter. Jeszcze więcej możliwości reprezentacji tokenu w zdaniu występuje w przypadku gdy token traktowany jest jako wyraz języka polskiego. Wyraz taki zawiera szereg form fleksyjnych, które reprezentują go w zdaniu. Każda z tych form może się więc także odnosić do tokenu będące-go wyrazem. Ostatnią grupą są wyrazy potencjalne takie jak np. liczby. Wyrazy takie charakteryzuje fakt, iż nie da się ich zesłownikować, natomiast najczęściej bardzo łatwo można przedstawić regułę ich generowania. Tak więc wyrazem pasu-jącym do takiego tokenu może być dowolny wyraz z nieskończonego przeliczalnego zbioru napisów generowanego przez określoną regułę.

71

• token typu wyraz CLP (Word) – jest to token, który reprezentuje poje-dynczy wyraz z biblioteki CLP. Identyfikowany jest on jako numer ID z biblioteki CLP, który stanowi wartość pola value. Ze względu na charakter biblioteki CLP dopasowanie tego tokenu jest zawsze case-insensitive (nie-wrażliwe na wielkość liter) oraz następuje niezależnie od użytej formy słowa w tekście. Przykładowy format tokenu wyrazu w yaml to:

{type: Word, value: <numer CLP ID>, case: false}

Wartością jest pojedynczy numer ID CLP. W przypadku chęci użycia wie-lu wariantów fleksyjnych jednego wyrazu dostępnych w CLP pod różnymi numerami ID należy użyć wielu różnych tokenów typu Word;

• token typu wyraz spoza CLP (UnknownWord) – jest to token, który repre-zentuje pojedynczą formę wyrazu spoza CLP. Pole value tokenu powinno zawierać postać tekstową formy. Przykładowy format tego tokenu yaml to: {type: UnknownWord, value: <forma wyrazu>, case: false}

Token ten powinien zostać dopasowany do dowolnego napisu stanowiącego jeden wyraz w zdaniu (a więc zawierającego lewą i prawą granicę wyrazu), co gwarantuje, że wyraz taki nie dopasuje się jako fragment innego dłuższego wyrazu w tekście. Za pomocą tego tokenu można także wyrazić pojedynczą formę wyrazu z CLP. Aby zdefiniować wszystkie możliwe formy wyrazu spoza CLP należy więc użyć zbioru tokenów typu UnknownWord.

• token typu cytat (Cite) – jest to token, który definiuje dokładny ciąg napi-sów do znalezienia. Cytat ten nie jest interpretowany w żaden sposób przez CLP. Szukany jest dosłowny ciąg znaków (z dokładnością do białych zna-ków). Należy zdefiniować parametr o nazwie ’case’, który dla wartości True oznacza uwzględnianie wielkości znaków oraz odwrotnie dla wartości False. Format takiego tokenu to:

{type: Cite, case: true, value: <text>}

Otwarty format tokenu sprawia, że potencjalne rozszerzanie specyfikacji jest możliwe. Przykładowe planowane do wprowadzenia nowe rodzaje tokenów mogą być zdefiniowane następująco:

• numery (Numbers) – token dopasowujący się do wyrażenia będącego nu-merem. Pole value może zawierać definicję zakresu numeru (np. 100..200; 1,2,3)

• dołączenie dowolnego słownika językowego – na zasadzie analogicznej do tokenu typu Word utworzyć można token dla wyrazu z dowolnego innego słownika (np. słownik wielosegmetowy, słownik semantyczy, słownik slan-gowy, słownik specjalistyczny, itp. . . ).

Należy jednak zwrócić uwagę na fakt, że sama reprezentacja danych w skryp-cie nie jest związana z logiką przetwarzania tokenu przez narzędzie ewaluujące skrypt. Narzędzie to powinno dostarczyć implementacji algorytmów dopasowania opisanych w tym rozdziale tokenów, zdań, części skryptów do tekstu. Oznacza to, że dla każdego rodzaju tokenu, musi istnieć implementacja w ekstraktorze skryptu potrafiąca rozpoznać daną jednostkę w tekście wejściowym.

Rozdział 5

Semantyczne strategie doboru

linków

Wykorzystując aparat semantyczny opisany w rozdziale 4 należy utworzyć nowe strategie semantyczne, które będą wykorzystywały informacje o ewaluacji semantycznej dokumentów. Zaproponowano trzy nowe metody, które zostały opi-sane w rozdziale 5.3. Do działania metod z wykorzystaniem ekstraktora skryptów koniecznie jest zdefiniowanie struktury skryptu, co zostało opisane w szczegółach w rozdziale 5.2. Wyniki eksperymentów zaprezentowano w rozdziale 5.6.

5.1 Architektura i implementacja ekstraktora skryptów

Ekstraktor skryptów jest narzędziem utworzonym na potrzeby ewaluacji skryp-tu w formacie opisanym w rozdziale 4.4. Narzędzie to zostało nazwane Pyxtractor, co stanowi skrót od Python Extractor i odnosi się także do wybranego języka im-plementacyjnego. Narzędzie to umożliwia ocenę stopnia dopasowania tekstu do wybranego skryptu.

Ocena dopasowania reprezentowana jest poprzez parę dwu wartości: spełnie-nie obligatoryjności oraz wynik punktowy (waga). Wypełniony skrypt posiada zestaw elementów podlegających ocenie powiązanych z wagami oraz wartości progowe. Wagi w dalszym etapie służą do wyliczania finalnego wyniku punk-towego natomiast wartości progowe określają czy nastąpiło dopasowanie wzorca ze względu na minimalną wymaganą ilość informacji. Dodatkowo każdy element dopasowania posiada także obligatoryjność, która jest cechą stwierdzająca czy pojawienie się danego elementu w tekście jest bezwzględnie wymagane, aby do-pasowanie doszło do skutku (niezależnie od wartości wag). W związku z tym finalny wynik działania skryptu interpretowany jest jako pomyślne dopasowanie wtedy, gdy wszystkie wymagane (obligatoryjne) elementy w skrypcie pojawiły

się oraz gdy ich jakość (ilość informacji) mierzona w postaci wagi przekraczała minimalny próg określony w skrypcie. Powyższy opis ideowy ekstraktora przed-stawiono w postaci sformalizowanej w definicjach 5.1, 5.2, 5.3 oraz 5.4.

Definicja 5.1. Niech funkcja δ(T, S)→ (O, W ) oznacza dowolną funkcję ocenia-jącą tekst T z użyciem wzorca S. Dopasowaniem skryptu S do tekstu T nazywamy wartość funkcji δ(T, S) będącą dwójką (O, W ), gdzie O jest wartością logiczną ( True lub False) oznaczającą warunek obligatoryjności, a wartość W jest wagą dopasowania będącą dowolną liczbą całkowitą i oznaczającą mierzalną ilość dopa-sowanej informacji.

Definicja 5.2. Wartość ρ(S) ∈ C nazywamy wartością progową skryptu będącą dowolną liczbą całkowitą.

Definicja 5.3. Niech δ(T, S) → (O, W ). Pozytywnym dopasowaniem skryptu S do tekstu T nazywamy takie dopasowanie (O, W ), które spełnia warunek logiczny O ∧ (W ρ(S)). Wartość W w przypadku pozytywnego dopasowania skryptu oznacza miarę ilościową informacji dopasowanych w skrypcie S i jest ona miarą względna dla S (tzn. nie można jej porównywać dla różnych skryptów S).

Definicja 5.4. Niech δ(T, S)→ (O, W ). Negatywnym dopasowaniem skryptu S do tekstu T nazywamy takie dopasowanie (O, W ), które spełnia warunek logiczny ¬O ∨ (W < ρ(S)). Wartość W w przypadku gdy wyrażenie O nie jest prawdzi-we nie niesie żadnego znaczenia. W przypadku, gdy wyrażenie O jest prawdziprawdzi-we, wartość W reprezentuje względną dla S miarę ilościową informacji (jednak nie-dostatecznej, tzn. poniżej wartości progowej).

Tekst reprezentowany jest przez dowolny nieotagowany ciąg znaków czyli w postaci czystej bez annotacji. Implementacja ekstraktora skryptów ładuje skrypt także w postaci tekstowej sformatowanej z użyciem notacji yaml.

Architektura Pyxtractora została przedstawiona na rysunku 5.1 z użyciem widoku klas notacji UML.

5.1.1 Klasa Pyxtractor

Jest to klasa, która odpowiada za wykonanie dopasowania skryptu do zadane-go tekstu. Inicjalizuje się ją podając ścieżkę do pliku ze skryptem yaml, która jest używana do zainstancjonowania obiektu klasy Script. Następnie należy przekazać za pomocą metody feed() porcję tekstu do oceny. Wykonując metodę evaluate() następuje dopasowanie skryptu. Dopasowanie to dla wszystkich części skryptu uruchamia metodę evaluate scriptsentence() która przeprowadza ocenę dopaso-wania pojedynczego zdania skryptu do tekstu. Używa ona dla każdego slotu z tokenami metody pomocniczej evaluate tokens() wykonywanej dla każdego zda-nia tekstu. Metoda evaluate tokens() wykorzystuje metodę find() obiektów typu

75                                                                              

Rysunek 5.1: Widok klas UML ekstraktora skryptów.

Token, aby stwierdzić czy konkretny token może być znaleziony w tekście. Zlicza liczbę tokenów znalezionych w tekście i zwraca ją jako wynik działania. Liczba ta jest porównywana z parametrem min slotu skryptu – dzięki czemu można stwierdzić czy minimalna liczba tokenów potrzebna do dopasowania slotu została znaleziona.

Po skończonej ewaluacji metoda decision() zwraca wartość True bądź False w zależności czy zgodnie z zadanymi warunkami w skrypcie tekst jest lub nie jest dopasowany.

Klasa Pyxtractor umożliwia sekwencyjną pracę w postaci wielokrotnego uży-wania metody feed() i pozostałych w celu oceny innych tekstów.

5.1.2 Klasa Script

Jest to warstwa abstrakcji zbudowana nad formatem skryptu w pliku yaml. Instancjonowanie klasy wymaga podania nazwy pliku, z którego należy wczytać strukturę danych. Klasa przechowuje skrypt rezerwując atrybut obyaml do prze-chowywania go w postaci natywnych struktur danych języka Python. Dodatkowo wprowadza ujednolicenie serializacji tej struktury zapewniając tym samym

moż-liwość modyfikowania programowego skryptu i zapisu go z powrotem do formatu yaml, co jest wykorzystywane w edytorze skryptów. Służą do tego dwie metody save() oraz save as().

5.1.3 Klasa Text

Klasa Text służy do przechowywania tekstu w postaci zoptymalizowanej dla przetwarzania przez klasę Pyxtractor. Klasa Text inicjalizowana jest na wejściu tekstem czystym. Podczas inicjalizacji następuje segmentacja zdań tekstu z uży-ciem metody split sentences(). Każde ze zdań jest także tagowane za pomocą numerów ID biblioteki CLP. Aby późniejsza identyfikacja ciągu znaków, który reprezentował wyraz znaleziony w bibliotece CLP, była możliwa stosuje się roz-szerzony format zapisu informacji o znalezionym wyrazie:

( [ CLP ID, ... ] , forma, position start, position end )

Format ten wprowadza czwórkę: lista numerów ID biblioteki CLP, które zo-stały dopasowane dla danej formy, forma wyrazu znaleziona w tekście, lewa i prawa granica napisu w tekście reprezentująca daną formę wyrażoną w postaci offsetu w znakach od początku tekstu zdania.

Taka reprezentacja danych pozwala na produkowanie przez Pyxtractor w pro-cesie dopasowania skryptu złożonej struktury danych, umożliwiającej identyfika-cje wszystkich rzeczywistych fragmentów napisów uczestniczących w dopasowa-niu. Na podstawie danych zawartych w takiej strukturze możliwe jest utworzenie narzędzia służącego do testowania skryptów oraz dogłębnej analizy wyników (a nie tylko powierzchownej w postaci wyniku liczbowego).

Informacje o zdaniach i wyrazach CLP przechowywane są w ramach jednej struktury w atrybucie sentences klasy Text. Jej format stanowi lista dwójek za-wierających tekst zdania oraz listę wyrazów w formacie opisanym powyżej: [ ( zdanie 1 w postaci tekstowej, [ wyraz 1, wyraz 2, ...

... , wyraz n] ), ... ] 5.1.4 Klasa Token

Klasa Token jest to klasa podstawowa dla klas innych klas specjalizujących rodzaj tokenu i dziedziczących po niej. Definiuje ona funkcjonalność przechowa-nia struktury danych tokenu z formatu yaml oraz dokonaprzechowa-nia konwersji w locie wartości value na wartość python unicode, jeśli jest taka potrzeba. Dodatkowo udostępnia metodę serializacji do struktury danych pythona umożliwiającą zapi-sanie przez klasę Script z powrotem skryptu do pliku yaml.

77

5.1.5 Klasy TokenWord, TokenCite, TokenUnknownWord

Klasy te specjalizują rodzaj tokenu dziedzicząc podstawowy interfejs po kla-sie Token. Implementują one metodę find(sentence), która zwraca wartość True jeśli token można odnaleźć w zdaniu reprezetowanym przez argument sentence. Argument sentence jest strukturą danych pythona zawierającą informację o zda-niu tekstowym. Format struktury sentence jest zdefiniowany w opisie klasy Text. Tokeny posiadają następujące reguły dopasowania:

• TokenWord – reprezentuje pojedynczy wyraz języka polskiego wyrażony poprzez identyfikator ID biblioteki CLP; dopasowuje się do dowolnej formy fleksyjnej tego wyrazu w tekście,

• TokenCite – reprezentuje dowolny spójny fragment ciągu znaków; dopaso-wuje się do identycznego ciągu znaków z uwzględnieniem możliwości wyłą-czenia sprawdzania wielkości liter,

• TokenUnknownWord – reprezentuje dowolną formę wyrazu języka

W dokumencie Index of /rozprawy2/10469 (Stron 69-83)

Powiązane dokumenty