Wykorzystanie komputerowych narzędzi przetwarzania języka w normalizacji diachronicznej tekstów polskich

(1)

Wykorzystanie komputerowych

narzędzi przetwarzania języka

w normalizacji diachronicznej

tekstów polskich

(2)

(3)

UNIWERSYTET IM. ADAMA MICKIEWICZA W POZNANIU

SERIA

Krzysztof Jassem

Wykorzystanie komputerowych narzędzi przetwarzania języka w normalizacji diachronicznej tekstów polskich

POZNAŃ 2018

(4)

Recenzent:

Publikacja sfinansowana przez

Rektora Uniwersytetu im. Adama Mickiewicza w Poznaniu oraz Wydział Prawa i Administracji UAM

This edition © Uniwersytet im. Adama Mickiewicza w Poznaniu, Wydawnictwo Naukowe UAM, Poznań 2018

Projekt okładki:

Redakcja:

Redakcja techniczna:

Łamanie komputerowe: Marcin Tyma

ISBN 978-83-232- ISSN

WYDAWNICTWO NAUKOWE UNIWERSYTETU IM. ADAMA MICKIEWICZA W POZNANIU 61-701 POZNAŃ, UL. FREDRY 10

www.press.amu.edu.pl

Sekretariat: tel. 61 829 46 46, faks 61 829 46 47, e-mail: wydnauk@amu.edu.pl Dział Promocji i Sprzedaży: tel. 61 829 46 40, e-mail: press@amu.edu.pl Wydanie I. Ark. wyd. 00,00. Ark. druk. 00,00

DRUK I OPRAWA: VOLUMINA.PL DANIEL KRZANOWSKI, SZCZECIN, UL. KS. WITOLDA 7-9

(5)

Spis treści

Spis treści Wstęp

1. Komputerowe przetwarzanie tekstów języka polskiego

1.1. Przegląd komputerowych narzędzi przetwarzania języka polskiego 1.1.1. Podział na zdania

1.1.2. Tokenizacja

1.1.3. Analiza morfologiczna

1.1.4. Ujednoznacznianie morfosyntaktyczne 1.1.5. Parsing płytki

1.1.6. Rozpoznawanie jednostek nazewniczych 1.1.7. Parsing głęboki

1.1.8. Normalizacja tekstu

1.2. Przegląd polskich systemów integrujących narzędzia przetwarzania języka 1.2.1. Language Tool

1.2.2. Multiservice 1.2.3. CLARIN

2. PSI-Toolkit – zintegrowany, kompatybilny i rozszerzalny zestaw narzędzi przetwarzania języka naturalnego

2.1. Przeznaczenie systemu PSI-Toolkit 2.2. Struktura danych (krata)

2.2.1. Anotacja krawędzi 2.2.2. Tagi krawędzi

2.2.3. Rozkłady na krawędzie składowe 2.2.4. Wagi krawędzi

2.2.5. Motywacja zdefiniowania kraty jako struktury danych 2.2.6. Tekstowa postać PSI-kraty

Podsumowanie podrozdziału 2.2 2.3. Potoki przetwarzania

Podsumowanie podrozdziału 2.3.

2.4. Procesory 2.4.1. Readery

2.4.2. Anotatory zestawu PSI-Toolkit 2.4.3. Writery

Podsumowanie podrozdziału 2.4

(6)

2.5. Odseparowanie danych językowych od procesu przetwarzania 2.6. Rozszerzalność zestawu PSI-Toolkit

2.7. Przenośność

3. Normalizacja diachroniczna tekstów języka polskiego 3.1. Motywacja badań

3.2. Przegląd komputerowych systemów normalizacji tekstu 3.2.1. Metody normalizacji tekstu

3.2.2. Prace związane z normalizacją diachroniczną Podsumowanie podrozdziału 3.2

3.3. iayko – program do normalizacji diachronicznej z wykorzystaniem trans- duktorów skończenie stanowych

3.3.1. Początkowe źródło reguł normalizacji 3.3.2. Transduktory skończenie-stanowe

3.3.3 Przykłady reguł normalizacji diachronicznej w systemie iayko 3.3.4. Lista wyjątków

3.3.5. Wybrane aspekty implementacji 3.3.6. Ewaluacja rozwiązania

Podsumowanie podrozdziału 3.3

3.4. Diachronic normalizer – narzędzie do normalizacji diachronicznej jako ele- ment zestawu PSI-Toolkit

3.4.1. Normalizacja diachroniczna w procesie przetwarzania tekstu 3.4.2. Przykłady użycia procesora iayko

3.4.3. Opóźnione ujednoznacznianie wyników normalizacji diachronicznej 3.4.4. Tworzenie spersonalizowanego normalizatora

4. Reguły normalizacji diachronicznej

4.1. „Odkrywka” – korpusowe źródło datowania reguł 4.2. Metodyka datowania reguł

4.3. Reguły inspirowane opracowaniem Felińskiego (1816) Reguła „i -> j” po „y”, przed spółgłoską

Reguła „i -> j” na początku wyrazu przed samogłoską Reguła „i -> j” pomiędzy samogłoskami

Reguła „i->j” po samogłosce przed spółgłoską Reguła „y -> j” przed samogłoską

Reguła usunięcia litery „y”

Reguła „y -> j” po samogłosce Reguła „dź-> ć” w bezokolicznikach Reguła „dz-> c” w bezokolicznikach Reguła „z -> s” w przedrostkach Reguła „á -> a”

Reguła „iej -> ij” w formach rozkazujących Reguła „s -> z” w przyimkach.

(7)

4.4. Reguły inspirowane Rozprawami Deputacji (Rozprawy, 1830)

Reguła “szy -> łszy” w formach imiesłowów przysłówkowych uprzednich Reguła „źrzódło”

Reguła: polonizacja nazw własnych

Reguła “gie -> ge” w wyrazach obcego pochodzenia Reguła “ó -> o” w wybranych wyrazach

Rule: “x-> ks”

Reguła modernizująca przymiotniki rodzaju męskiego w narzędniku 4.5. Reguły inspirowane Uchwałami Akademii Umiejętności (1891)

Reguła “zk -> sk” w przymiotnikach

Reguła “z -> s” w końcówkach rzeczowników “ęstwo”

Reguła “z -> s” w przedrostku Reguła „é -> e”

4.6. Reguły inspirowane Zasadami Akademii Umiejętności (Zasady, 1917) Reguła z -> ś w przedrostkach czasowników

4.7. Reguły inspirowane Uchwałami Komitetu Ortograficznego (Jodłowski, Taszycki, 1936)

Reguła yjum -> ium w zakończeniach rzeczowników Reguła yjum -> jum w zakończeniach rzeczowników Reguła yja -> ia w zakończeniach rzeczowników Reguła yja -> ja w zakończeniach rzeczowników Reguła yj -> ii w zakończeniach rzeczowników Reguła yj -> ji w zakończeniach rzeczowników Reguła y -> i po spółgłosce, a przed samogłoską 4.8. Reguły podziału wyrazów

Reguła “nie” + czasownik

Reguły podziału specyficznych wyrazów

Reguły podziału spójników złożonych typu “przyczem”

Reguła odseparowania partykuły “by” od wyrazów nieodmiennych Reguła rozdzielenia partykuły “nie” od predykatywów (np. ‘nie wolno’) 4.9. Reguły inspirowane analizą korpusu diachronicznego

Reguła ll -> l Reguła ff -> f Reguła pp -> p Reguła: mm -> m Reguła rr -> r Reguła ss -> s Reguła nn -> n Reguła kk -> k

Reguła spolszczenia wyrazów pochodzenia niemieckiego Rule: “x-> gz”

Reguła zmodernizowania formy gerundium

Reguła zmodernizowania końcówek fleksyjnych rzeczowników

Reguła “a -> y” dla rzeczowników obcego pochodzenia w mianowniku liczby mnogiej

(8)

Reguła zmodernizowania przedrostków “vice” I “contr”

Reguła zmian fonetycznych

Reguła pozostałych zmian w obrębie wyrazu Reguła zmiękczania: n-> ń, s -> ś

Reguła zmodernizowania końcówek bezokoliczników

Reguła zmodernizowania form czasowników w formie orzecznika w pierwszej osobie liczby mnogiej

Reguła zmodernizowania imiesłowu przymiotnikowego biernego 4.10. Kolejność przetwarzania reguł

Podsumowanie rozdziału 4.

5. Podsumowanie pracy 6. Bibliografia

7. Spis rysunków

(9)

Wstęp

Celem niniejszej pracy jest przedstawienie, na przykładzie normalizacji diachronicznej historycznych tekstów polskich, zastosowania komputerowych na- rzędzi przetwarzania języka do badania zjawisk lingwistycznych.

Normalizacja diachroniczna to automatyczny proces konwersji tekstu historycznego do jego współczesnego odpowiednika. W proponowanym tutaj roz- wiązaniu proces ten dokonywany jest w oparciu o reguły stworzone przez spe- cjalistę. Punktem wyjścia do utworzenia takiego zestawu reguł było opracowanie (Malinowski, 2012), które stanowi kompendium zmian w nowożytnej ortografii polskiej. Dzięki zastosowaniu metod komputerowych tę początkową listę reguł w znacznym stopniu poszerzono, uzyskując w ten sposób nieskodyfikowane wcze- śniej informacje o zmianach w pisowni języka polskiego.

Narzędzie¹ do normalizacji diachronicznej, prezentowane w niniejszej pracy, sprowadzono do postaci tzw. procesora zestawu narzędzi przetwarzania języka na- turalnego o nazwie PSI-Toolkit. (Procesorem zestawu PSI-Toolkit nazywamy każde narzędzie zawarte w tym zestawie.) Uzyskano w ten sposób możliwość komputerowego przetwarzania tekstów historycznych. Na przykład, w celu dokonania analizy składniowej tekstu historycznego, analizowany tekst poddaje się kolejno działaniom następujących procesów: wczytanie tekstu z danego formatu, tokenizacja tekstu historycznego, normalizacja diachroniczna, analiza leksykalna wersji uwspółcześnionej, analiza składniowa wersji zmodernizowanej.

Układ pracy jest następujący: Rozdział 1. stanowi przegląd najważniejszych narzędzi przetwarzania języka polskiego. W podrozdziale 1.1. wyszczególniono poszczególne typy narzędzi, przedstawiając dla każdego z nich istniejące rozwią- zania – ze szczególnym uwzględnieniem tych, które zostały stworzone przy współ- udziale autora niniejszej pracy. W podrozdziale 1.2. omówiono polskie systemy integrujące jedno-zadaniowe narzędzia, tworzące wielozadaniowe platformy przetwarzania języka.

1 Narzędziem nazywa się w tej pracy program komputerowy dedykowany do wykonywania jednego, precyzyjnie zdefiniowanego zadania

(10)

Rozdział 2 poświęcony jest w całości systemowi integrującemu PSI-Toolkit, który powstał w ramach projektu badawczego² prowadzonego przez autora niniejszej książki.

Rozdział 3. poświęcony jest zagadnieniu normalizacji diachronicznej. Podroz- dział 3.1. podaje motywację badań z tej dziedziny. Podrozdział 3.2. poświęcony jest omówieniu dotychczasowych działań mających na celu normalizację diachro- niczną tekstów polskich. Podrozdział 3.3. opisuje rozwiązanie autorskie – infor- matyczny system iayko, którego główną składową jest narzędzie do normalizacji diachronicznej³. Podrozdział 3.4 łączy zagadnienia omówione w rozdziałach 2.

oraz 3., przedstawiając zalety integracji wytworzonego narzędzia iayko z zestawem PSI-Toolkit.

Rozdział 4. zawiera autorską listę reguł normalizacji diachronicznej zapisaną w (modyfikowanym na potrzeby niniejszego zadania) formalizmie Thrax, służą- cym do definiowania transduktorów skończenie stanowych, która stanowi pod- stawę działania programu opisanego w rozdziale 3. Lista uzupełniona jest komen- tarzami, przykładami użycia oraz wykresami obrazującymi zmiany zachodzące w języku na osi czasu, odpowiadające regułom.

W podsumowaniu podkreśla się korzyści płynące ze stosowania narzędzi automatycznego przetwarzania języka naturalnego w badaniu zjawisk językowych, które zobrazowane zostały w pracy na przykładzie analizy zmian pisowni języka polskiego. Podaje się przykłady zastosowania opracowanego systemu normalizacji diachronicznej. Wskazuje się potencjalne kierunki dalszych badań, które mogą za- owocować poszerzeniem zestawem reguł normalizacji diachronicznej, a co za tym idzie – podwyższeniem jakości działania programu opartego na tych regułach.

2 Projekt badawczo-rozwojowy Ministerstwa Nauki i Szkolnictwa Wyższego N N516 480540,

„Narzędzia do automatycznego przetwarzania języka polskiego udostępnione publicznie”

3 W skład zespołu projektowego wchodzili: Krzysztof Jassem – reguły normalizacji diachronicznej, Filip Graliński – procedury ewaluacji i testowania, Tomasz Obrębski – metody skończenie- -stanowe

(11)

1 Komputerowe przetwarzanie tekstów języka polskiego

Komputerowe przetwarzanie tekstu zapisanego w języku naturalnym to proces, którego celem jest poprawne zinterpretowanie tekstu przez komputer. Przyj- muje się, że komputer poprawnie zinterpretował zadany tekst, jeśli wykonał akcję zgodną z oczekiwaniami użytkownika. W zależności od przeznaczenia systemu komputerowego oczekiwaną akcją może być pzykładowo odpowiedź na pytanie zawarte w tekście, wykonanie podanego polecenia, analiza wydźwięku tekstu¹ czy przetłumaczenie tekstu na inny język naturalny.

Metody przetwarzania tekstu mogą być zależne lub niezależne od języka. Na przykład większość współczesnych algorytmów tłumaczenia automatycznego² może być z powodzeniem zastosowana dla wielu różnych par językowych. Aby skonstruować system dla nowej pary językowej, wystarczy bowiem dostarczyć do systemu odpowiednio duży korpus odpowiadających sobie tekstów w tychże języ- kach. Wciąż jednak większość metod służących do zrozumienia tekstu zależnych jest od języka, w którym tekst został napisany. Niniejszy rozdział poświęcony jest omówieniu stanu prac w dziedzinie przetwarzania języka polskiego. Podrozdział 1.1. przedstawia ogólnodostępne narzędzia programistyczne wykonujące poszcze- gólne zadania przetwarzania języka polskiego. W podrozdziale 1.2. omówione są zestawy agregujące takie narzędzia.

1 Analiza wydźwięku to automatyczny proces identyfikacji nastawienia autora wypowiedzi do jej tematyki (przykładem może być klasyfikacja wypowiedzi na dany temat jako pozytywnej lub negatywnej).

2 Mowa tutaj o paradygmatach tłumaczenia metodami statystycznymi lub z wykorzystaniem sieci neuronowych

(12)

1.1. Przegląd komputerowych narzędzi przetwarzania języka polskiego

W tradycyjnym podejściu przetwarzanie języka naturalnego podzielone jest na etapy, następujące jeden po drugim³. Proces ma często charakter potokowy – dane wyjściowe z jednego etapu stają się danymi wejściowymi kolejnego. Najwygod- niej⁴ jest przyjąć, że w pierwszej kolejności⁵ tekst podlega podziałowi na mniej- sze części, zwane segmentami. W pewnym uproszczeniu zakłada się, że granice segmentów mogą przebiegać między dokumentami wchodzącymi w skład tekstu, paragrafami, zdaniami lub wyrazami. W niniejszym podrozdziale omówiony zostanie podział na te dwie ostatnie składowe.

1.1.1. Podział na zdania

Formalizm SRX

Najbardziej rozpowszechniona metoda dzielenia tekstów na zdania polega na stosowaniu reguł podziału zapisanych w formalizmie SRX (Segmentation Rules eXchange). Jest to standard wypracowany na początku XXI wieku przez założone w Szwajcarii stowarzyszenie LISA (Localization Industry Standards Association), którego celem było ułatwienie procesu lokalizacji, czyli tłuma- czenia oprogramowania komputerowego. Formalizm SRX pozwala na zapisa- nie reguł podziału tekstu, zapisanego w jednym lub w wielu językach. Reguły zebrane są w grupy dotyczące poszczególnych języków. Każda reguła określa konteksty: lewostronny i prawostronny (opisane za pomocą wyrażeń regularnych⁶) dla potencjalnego miejsca podziału. Program dzielący tekst na zdania analizuje reguły w kolejności ich zapisu w pliku, przy czym każda z nich oznacza potencjalne miejsca podziału w całym analizowanym tekście.

Wydruk 1-1 obrazuje fragment pliku reguł zapisanych w formacie SRX.

3 Współczesne technologie coraz częściej odchodzą od tego podejścia. Na przykład w systemach tłumaczenia automatycznego z wykorzystaniem sieci neuronowych wewnętrzne etapy przetwarzania ukryte są w niejawnych warstwach sieci neuronowej.

4 W komputerowym przetwarzaniu języka często stosuje się określenie „wygodny” (ang. conve- nient). Ma ono na celu podkreślenie, że dane założenie / rozwiązanie może nie być zgodne z teoriami lingwistycznymi, ale umożliwia opracowanie efektywnie działającego oprogramowania.

5 Pomija się tutaj etap tzw. czyszczenia tekstu polegającego m.in. na usunięciu różnego typu znaczników (np. znaczników HTML), usuwaniu wielokrotnych spacji, czy sprowadzaniu znaków tekstu do jednolitego formatu (np. Unicode).

6 Wyrażenia regularne to wzorce definiujące klasy napisów. Przystępny kurs na ten temat znajduje się na stronie internetowej http://wazniak.mimuw.edu.pl/index.php?title=%C5%9Arodowisko_

programisty/Wyra%C5%BCenia_regularne

(13)

Wydruk 1‑1. Przykład zapisu reguł w formacie SRX

</rule>

</rule>

</rule>

Na Wydruku 1-1 przedstawione są trzy reguły podziału. Pierwsza z nich, po- przedzona komentarzem Inicjały, zawarta pomiędzy pierwszymi dwoma znacz- nikami typu rule, jest przeznaczoną dla programu segmentującego informacją o tym, że potencjalnymi miejscami podziału są takie lokalizacje, dla których:

po lewej stronie (element beforebreak) występuje początek wyrazu (\b), po któ- rym następuje duża litera (p{Lu}) i znak kropki (\.), a po prawej stronie (element afterbreak) występuje biały znak (\s). Reguła specyfikuje, że w każdym takim miej- scu dokumentu program nie powinien wstawiać znaku podziału (break=”no”).

Reguła poprzedzona komentarzem Koniec zdania informuje, że należy wstawiać znak podziału w każdą lokalizację pomiędzy znakiem kropki, znaku zapytania lub wykrzyknika a białym znakiem⁷, po którym występuje duża litera. Reguła ta nie jest jednak stosowana w tych lokalizacjach, które przez regułę poprzedzającą zo- stały oznaczone jako „brak podziału”. Ostatnia reguła dotyczy podziału tekstu przed znakiem nowego wiersza.

Przykładowe działanie programu dzielącego zdania w oparciu o powyższe re- guły obrazuje Wydruk 1-2.

7 Biały znak to znak nieposiadający graficznej reprezentacji (np. tabulacja, spacja, znak nowego wiersza), służący najczęściej jako separator tokenów w tekście

(14)

Wydruk 1‑2. Działanie programu w oparciu o reguły zapisane w formacie SRX

Tekst wejściowy:

J. Kowalski przyleciał na lotnisko Chopina w Warszawie. Natychmiast udał się na postój taksówek.

Tekst wejściowy z oznaczonymi potencjalnymi miejscami podziału:

J. <break=no> Kowalski przyleciał na lotnisko Chopina w Warszawie. <break=yes> Natychmiast udał <break = yes>

się na postój taksówek.

Tekst wyjściowy podzielony na zdania zgodnie z oznaczonymi miejscami podziału:

J. Kowalski przyleciał na lotnisko Chopina w Warszawie.

Natychmiast udał się na postój taksówek.

Podział na zdania w systemie LanguageTool

LanguageTool to projekt, rozwijany przez społeczność jego użytkowników, któ- rego podstawowym celem jest korekta błędów językowych w tekstach zapisanych w różnych językach. Zasoby tego projektu dotyczące języka polskiego omówione są bardziej szczegółowo w sekcji 1.2.1.

Pierwszym etapem przetwarzania tekstu w systemie LanguageTool jest podział na zdania zgodnie z regułami zapisanymi w formalizmie SRX. Reguły dotyczą- ce wszystkich języków zapisane są w jednym pliku. Pierwsze z nich dotyczą po- działów niezależnych od języka – występujących po znakach interpunkcyjnych i wszelkiego typu nawiasach zamykających. Pozostałe reguły pogrupowane są we- dług języków, których dotyczą. Na Wydruku 1-3. podano dwie przykładowe regu- ły uwzględniające polskie skróty:

Wydruk 1‑3. Reguły podziału na zdania w systemie LanguageTool

<beforebreak>\barch\.\s</beforebreak>

</rule>

</rule>

(Napis \b oznacza w notacji wyrażeń regularnych początek wyrazu, napis \.

oznacza znak kropki, a napis \s reprezentuje dowolny biały znak.) Pierwsza regu- ła stanowi, że po skrócie arch. nie należy wstawiać znaku podziału, a druga – że znaku podziału nie należy wstawiać po skrócie art. zaczynającym się z małej bądź wielkiej litery.

Interesujący przykład podziału opisują reguły podane na Wydruku 1-4.

(15)

Wydruk 1‑4. Zastosowanie pozytywnej i negatywnej reguły podziału w systemie LanguageTool

</rule>

</rule>

Pierwsza reguła dotyczy adresów internetowych zakończonych domeną pl. Je- śli po takim napisie następuje spacja (\s) i ciąg liter rozpoczęty dużą literą (\p{Lu}\

p{Ll}), to po spacji ma zostać wstawiony znak podziału. Druga reguła natomiast dotyczy dwuliterowych skrótów zaczynających się na literę p (pl. – plac, pw. – pod wezwaniem i pn. – pod nazwą). Po skrótach tych nie należy wstawiać znaku po- działu. W przypadku gdy napis pl. dołączony jest bez spacji do niepustego napisu (zapis [^s] w pierwszej regule), pierwsza reguła ma priorytet.

Zbiór reguł systemu LanguageTool jest systematycznie poszerzany przez użytkowników systemu, którzy analizują błędy jego działania. Dzięki temu moż- liwe jest wychwycenie subtelności językowych takiego typu, jak wskazano na Wydruku 1-4.

Podział na zdania w systemie PSI‑Toolkit

PSI – Toolkit jest zestawem narzędzi przetwarzania języka, który zostanie omówiony szczegółowo w rozdziale 2. Jednym z narzędzi zestawu jest segmen- tator, dzielący tekst na zdania zgodnie z regułami zapisanymi w standardzie SRX. Pod względem funkcjonalnym⁸ rozwiązania LanguageTool i PSI-Toolkit są bardzo zbliżone. Celem projektu PSI-Toolkit jest umożliwienie łatwego odczytu i modyfikacji reguł. Dlatego reguły są rozdzielone w osobnych plikach dla każde- go języka, a zestaw reguł dla każdego z nich składa się zaledwie z kilku elemen- tów (w przypadku LanguageTool liczba reguł jest bliska tysiącu). Każda reguła obejmuje klasę napisów o podobnym „zachowaniu interpunkcyjnym”. Obrazuje to Wydruk 1-5.

8 Aspekt funkcjonalny aplikacji komputerowej to własność mówiąca o tym, jakie potrzeby użyt- kownika jest w stanie ona spełnić. Pojęciu temu przeciwstawia się aspekt niefunkcjonalny: w jaki sposób potrzeby te są realizowane. Na przykład korektory pisowni są równoważne pod względem funkcjonalnym, jeśli poprawiają te same klasy błędów. Mogą się różnić w aspekcie niefunkcjonal- nym, jeśli jeden z nich działa szybciej lub wymaga mniejszego wysiłku użytkownika.

(16)

Wydruk 1‑5. Reguły podziału na zdania w systemie PSI‑Toolkit

</rule>

</rule>

<!—inne skróty, po których nie należy robić podziału zdania -->

</rule>

</rule>

<!-- skróty, które mogą kończyć zdanie - nie wpływają na podział, więc nie ma dla nich opracowanej żadnej akcji:

\s([aA]bs|[aA]ang|[bB]db|[bB]ł|[bB]m|[bB]r|[bB]d|[bB]elg|[bB]lp|[bB]ot|[cC]d|…) -->

<!-- skróty zawierające kropki - nie wpływają na podział, więc nie ma dla nich opracowanej żadnej akcji:

\s(A\.D|a\.m|a\.s\.c|a\.t|a\.u\.c|[aA]\.C|b\.d|b\.m|b\.r|b\.u|c\.o|e\|…) -->

W rzeczywistości każda klasa skrótów zawiera znacznie więcej elementów.

Różnicę w zapisie obu zestawów reguł stanowi wykorzystanie znaku alternatywy (|) w zestawie reguł PSI-Toolkit.

Podsumowanie sekcji 1.1.1

Współczesne narzędzia podziału tekstów polskich na zdania stosują metody oparte na regułach opracowanych manualnie. Szczególnie popularnym standar- dem zapisu reguł jest formalizm SRX, w którym można zapisać reguły pozytywne („wstaw miejsce podziału”) lub negatywne („nie wstawiaj znaku podziału”). W zapisie SRX istotna jest kolejność zapisu reguł.

1.1.2. Tokenizacja Pojęcie tokenizacji

Tokenizacja to podział tekstu na fragmenty, zwane tokenami, zwykle oddzielo- ne od siebie białymi znakami oraz określenie ich typu jako jednego z:

(17)

– znak interpunkcyjny

– znacznik (jeśli znaczników nie usunięto na etapie tzw. czyszczenia tekstu) – jednostka nieleksykalna

– potencjalna jednostka leksykalna.

Znacznikami mogą być napisy formatujące tekst. Przykładami jednostek nieleksykalnych mogą być adresy e-mailowe, adresy internetowe, numery telefonów itp. Potencjalne jednostki leksykalne to napisy, które są potencjalnymi wyrazami języka.

Pożądany rezultat procesu tokenizacji obrazuje Przykład 1-1.

Przykład 1-1. Oczekiwany wynik tokenizacji

Załóżmy, że tekst wejściowy do pewnego systemu tokenizacji ma postać na- stępującą:

Najwyższe tempo rozwoju gospodraczego w r. 2016 nastąpiło na [[Węgrzech]], a nie w [[Polsce]] (źródło: www.wp.pl).

Pożądany wynik tokenizacji obrazuje Tabela 1-1.:

Tabela 1‑1. Wynik tokenizacji przykładowego zdania polskiego

Token Typ tokenu

Najwyższe Potencjalna jednostka leksykalna

tempo Potencjalna jednostka leksykalna

rozwoju Potencjalna jednostka leksykalna

gospodarczego Potencjalna jednostka leksykalna

w Potencjalna jednostka leksykalna

r. Potencjalna jednostka leksykalna

2016 Jednostka nieleksykalna

nastąpiło Potencjalna jednostka leksykalna

na Potencjalna jednostka leksykalna

[[ Znacznik

Węgrzech Potencjalna jednostka leksykalna

]] Znacznik

, Znak interpunkcyjny

a Potencjalna jednostka leksykalna

nie Potencjalna jednostka leksykalna

w Potencjalna jednostka leksykalna

[[ Znacznik

Polsce Potencjalna jednostka leksykalna

]] Znacznik

(18)

( Znak interpunkcyjny

źródło Potencjalna jednostka leksykalna

: Znak interpunkcyjny

www.wp.pl Jednostka nieleksykalna

) Znak interpunkcyjny

. Znak interpunkcyjny

Na Przykładzie 1-1- można zaobserwować niejednoznaczności, które program tokenizacji powinien rozstrzygnąć:

1) Czy napis r. należy traktować jako jeden token, czy jako dwa rozdzielne?

2) Czy napis r. należy traktować jako potencjalną jednostkę leksykalną, czy jako jednostkę nieleksykalną?

3) Czy błędny zapis wyrazu („gospodraczego”) należy traktować jako poten- cjalną jednostkę leksykalną?

4) Czy napis [[ należy traktować jako pojedynczy znacznik, czy jako dwa zna- ki interpunkcyjne [?

W kolejnych częściach omówione zostaną takie i inne problemy występujące w procesie tokenizacji.

Interpretacja znaku kropki

Kropka standardowo traktowana jest jako znak interpunkcyjny i oddzielana jest od poprzedzającego ją tokenu. Kropka stanowić może jednak również część skrótu, jak w przykładowym zdaniu: Poniższy artykuł jest autorstwa prof. dr. hab.

Jana Kowalskiego⁹. Oczekuje się wtedy, że tokenizator połączy kropkę z poprzedza- jącym ją skrótem i zinterpretuje taką zbitkę jako potencjalną jednostkę leksykalną.

Skrót może również kończyć zdanie, a wyzwanie stojące wtedy przed tokenizato- rem obrazuje Przykład 1-2.

Przykład 1-2. Tokenizacja skrótu kończącego zdanie

Załóżmy, że tekst wejściowy do programu tokenizacji ma postać:

Tokenami mogą być wyrazy, skrótowce, itp.

Oczekiwane wyjście z systemu ma postać przedstawioną w Tabeli 1-2.

9 W niektórych zastosowaniach oczekuje się, aby skróty zostały rozwinięte do pełnych form (np. Poniższy artykuł jest autorstwa profesora doktora habilitowanego Jana Kowalskiego). Pojawia się wtedy problem poprawnego wygenerowania form fleksyjnych skracanych wyrazów. Problem ten omawiany jest w sekcji 1.1.6.

(19)

Tabela 1‑2.Oczekiwany wynik tokenizacji zdania zakończonego skrótem

Token Typ tokenu

Tokenami Potencjalna jednostka leksykalna

mogą Potencjalna jednostka leksykalna

być Potencjalna jednostka leksykalna

wyrazy Potencjalna jednostka leksykalna

skrótowce Potencjalna jednostka leksykalna

itp. Potencjalna jednostka leksykalna

. Znak interpunkcyjny

Wyzwaniem dla tokenizatora jest konieczność „podwojenia” kropki na wyj- ściu programu – z jednej strony jest ona traktowana jako część tokenu itp., a z dru- giej – pełni rolę samodzielnego znaku interpunkcyjnego.

Rozwiązanie problemu skrótów najczęściej polega na tym, że tokenizator we- ryfikuje istnienie skrótu w specjalnie przygotowanej liście wyróżniającej skróty, które mogą kończyć zdanie (co jednak w pełni nie rozwiązuje problemu, np. samo istnienie listy skrtótów nie rozstrzygnie pożądanej interpretacji napisu ul.: skrót od ulica czy wyraz ul na końcu zdania).

Kropka może pełnić funkcję separatora wewnątrz tokenu, np. w adresach e-mailowych (jassem@amu.edu.pl). Zidentyfikowanie tej funkcji kropki jest w przetwarzaniu stosunkowo łatwe (wystarczy sprawdzić, czy po kropce znajduje się biały znak) – jednak takie „mechaniczne” podejście uniemożliwia zgodną z intencjami autora segmentację tekstów zapisanych z błędem (np. w parze zdań:

Tokenami mogą być wyrazy.Tokeny oddzielane są białymi znakami.). Jednym ze sposobów na uzyskanie oczekiwanych wyników tokenizacji dla jednostek zawiera- jących kropkę jest stosowanie wyrażeń regularnych, które definiują poszczególne rodzaje jednostek nieleksykalnych.

Interpretacja spacji

Spacja najczęściej stanowi granicę pomiędzy tokenami. Istnieje od tej reguły kilka wyjątków. Jednym z nich są napisy numeryczne, np. numery telefonów, numery identyfikacyjne (NIP, PESEL). Oczekuje się, że w takiej sytuacji tokenizator połączy ciągi numeryczne oddzielone spacjami w jeden token. Zadanie to można zrealizować stosunkowo łatwo za pomocą wyrażeń regularnych.

Nie jest oczywiste, jak tokenizator powinien traktować frazy wyrazowe, które pisane są z użyciem spacji, gdy pożądane jest, aby ich składowe w dalszym prze- twarzaniu były traktowane łącznie (np. dla zbitek wyrazów co prawda, na pewno).

(20)

Różne programy realizujące tokenizację traktują takie zbitki wyrazowe w różny sposób.

Można by oczekiwać, że wysokiej jakości tokenizator połączy w jeden element wielowyrazowe określenia jednego bytu, np. Rzeka św. Wawrzyńca, 17 lipca 2017, czy prof. dr hab. Jan Kowalski. Najczęściej jednak tokenizatory „nie zajmują” się tym zadaniem, pozostawiając je procesowi rozpoznawania jednostek nazewniczych (patrz: sekcja 1.1.6).

Interpretacja pauzy i półpauzy

Z punktu widzenia komputerowego przetwarzania języka półpauza może peł- nić następujące funkcje:

1) spajanie napisów, z których każdy osobno nie stanowi jednostki leksykal- nej, np. hokus-pokus

2) spajanie napisów, z których każdy osobno stanowi jednostkę leksykalną, ale znaczenie całego bytu nie jest kompozycją znaczeń poszczególnych składo- wych, np. czary-mary

3) spajanie jednostek leksykalnych w całość o znaczeniu będącym kompozy- cją znaczeń składowych, np. polsko-japoński

4) spajanie przedrostków z jednostkami leksykalnymi, np. arcy-atrakcja.

O ile w pierwszych dwóch przypadkach, niezależnie od przeznaczenia systemu informatycznego, oczekuje się, że tokenizator zwróci¹⁰ jeden token, o tyle w pozostałych przypadkach pożądane działanie nie jest oczywiste i jest mocno związane z procesem analizy morfologicznej (patrz: sekcja 1.1.3).

Jako że zakłada się, że tokenizacja jest procesem bezsłownikowym¹¹, rozdzie- lenie przypadków 1) i 2) od 3) i 4) nie jest trywialne. Efekt ten można uzyskać poprzez stosowanie wyrażeń regularnych dla pewnych spojeń typu 3) oraz poprzez wyposażenie systemu informatycznego w wyczerpującą listę przedrostków (dla spojeń typu 4)).

Trudność napotykaną w procesie tokenizacji stanowią znaki pauzy. W tekstach elektronicznych pauza często oznaczana jest tym samym symbolem, co półpauza.

Co więcej, autorzy tekstów niekonsekwentnie stawiają spacje przed i po znaku pauzy, co powoduje, że wynik automatycznego przetwarzania może być niezgodny z intencją autora tekstu.

10 Predykat „zwrócić” jest kalką językową angielskiego predykatu „to return”, który w odniesie- niu do programu komputerowego oznacza „podać w wyniku”

11 Założenie to stosuje się ze względu na szybkość działania

(21)

Apostrof

Apostrof stanowi ciekawe wyzwanie dla tokenizatorów języka angielskiego.

Poszczególne tokenizatory traktują te same wyrażenia w bardzo różny sposób, co obrazuje Przykład 1-3.

Przykład 1-3. Tokenizacja wyrażeń z apostrofami w języku angielskim

Poniższe zdanie poddano działaniu różnych tokenizatorów języka angielskiego:

Mr. O’Connor doesn’t think that the boys’ stories about the cowboy’s hat are amusing

Wyniki zwracane przez różne tokenizatory obrazuje Tabela 1-3.

Tabela 1‑3. Różne wyniki zwracane przez tokenizatory języka angielskiego Treebank^a) WordPunct^b) PunktWord^c) Whitespace^d) Pattern^e)

Mr. Mr Mr. Mr. Mr.

O’Connor . O O’Connor O’Connor

does O ‘Connor doesn’t does

n’t ‘ doesn think n’t’

think Connor ‘t that think

that doesn think the that

the ‘ that boys’ the

boys t the stories boys’

‘ think boys about stories

stories that ‘ the about

about the stories cowboy’s the

the boys hat cowboy

cowboy ‘ about are ‘s

‘s stories the amusing hat

hats about cowboy are

are the cowboy ‘s amusing

amusing ‘ hat

s are

hat amusing

are amusing

a) Treebank Tokenizer; http://www.nltk.org/_modules/nltk/tokenize/treebank.html b) http://www.nltk.org/_modules/nltk/tokenize.html

c) http://www.nltk.org/_modules/nltk/tokenize/punkt.html d) http://www.nltk.org/_modules/nltk/tokenize.html e) http://www.clips.ua.ac.be/pages/pattern-en#parser

(22)

W języku polskim apostrofu używamy:

1) dla oddzielenia końcówki fleksyjnej niektórych nazwisk i imion obcego pochodzenia, gdy nazwisko kończy się samogłoską (np. Morse’a, Johny’ego) 2) dla oddzielenia przyrostka derywacyjnego wyrazu obcego pochodzenia

(np. bridge’owy)

3) w wyrazach pochodzenia obcego zawierających apostrof (a’la casa, McDo- nald’s, rockn’roll)

4) w celu opuszczenia pierwszych dwóch cyfr daty rocznej (np. ’17)

Tokenizatory niekonsekwentnie przetwarzają apostrofy. Na przykład tokeni- zator zestawu PSI-Toolkit w pierwszych trzech przypadkach nie rozdziela poszcze- gólnych członów wyrazu (zwracając jeden token, np. Morse’a), a w czwartym – od- dziela apostrof od liczby (zwracając dwa tokeny: ‘ i 17).

Tokenizator Toki

Istotną cechą narzędzi przetwarzania języka naturalnego jest odseparowanie procesu przetwarzania od zasobów językowych. Daje to możliwość – w przypadku rozpoznania nieprzenalizowanego wcześniej zjawiska językowego – uzupełnienia samych zasobów, bez ingerencji w algorytm przetwarzania. W przypadku tokenizacji, w skład zasobów językowych wchodzą leksykony (np. leksykon skrótów) oraz reguły klasyfikacji tokenów. Program toki (Radziszewski, Śniatowski, 2011a)¹², tokenizator tekstów języka polskiego opracowany na Politechnice Wrocławskiej, w sposób wzorcowy realizuje postulat separacji przetwarzania od zasobów.

Proces tokenizacji odbywa się w kilku przebiegach¹³ (zwanych przez autorów warstwami przetwarzania (ang. layers)), wykonywanych w określonej kolejności.

Pierwszy przebieg to podział tekstu na segmenty: wiersze (separatorami są znaki nowego wiersza) lub zdania (podział na zdania dokonywany jest zgodnie z regułami podanymi w pliku o nazwie segment.srx). W wyniku tego przebiegu każdy fragment będący albo całym zdaniem, albo zakończony znakiem końca wiersza zostaje oznaczony jako jeden token, klasyfikowany jako typ t.

Przykład 1‑4. Tokenizacja tekstu za pomocą narzędzia ‘toki’

Załóżmy, że tekst wejściowy poddany działaniu narzędzia toki jest następujący:

Kupiłam (nowe) buty! Zapłaciłam 100$.

Wynik pierwszego przebiegu (poddział na segmenty) obrazuje Tabela 1-4.

12 Szczegółowe informacje na temat tego narzędzia można uzyskać na stronie: http://www.nlp.

pwr.wroc.pl/redmine/projects/toki/wiki

13 Jako jeden przebieg rozumiemy tutaj zestaw transformacji wykonywanych przez program na całym tekście: od jego pierwszego do ostatniego znaku

(23)

Tabela 1‑4. Dane wyjściowe pierwszego przebiegu tokenizacji w programie ‘toki’

Typ tokenu Rozpoznany token

T Kupiłam (nowe) buty!

T Zapłaciłam

T 100$.

Kolejne przebiegi wykonywane są zgodnie z kolejnością podaną w pliku config.

ini, w sekcji [layers], której zawartość obrazuje Wydruk 1-6:

Wydruk 1‑6. Fragment pliku konfiguracyjnego programu ‘toki’ – warstwy przetwarzania

[layers]

layer=exc_0 layer=suff_safe layer=a_lexicon layer=a_classify layer=suff_dot layer=tu_classify layer=exc_1 layer=n_classify layer=exc_2 layer=th_classify layer=hyphen layer=ts_classify

W celu wykonania pierwszego przebiegu (layer=exc_0) program odszukuje sekcję w pliku config.ini o nazwie zgodnej z nazwą warstwy – w pierwszym prze- biegu jest to sekcja o nawie exc_0. Sekcja ta ma postać przedstawioną na Wydruku 1-7 (numery wierszy wstawiono na potrzeby niniejszego opracowania).

Wydruk 1‑7. Fragment pliku konfiguracyjnego programu ‚toki’ ‑ opis warstwy przetwarzania

(1) [layer:exc_0]

(2) class=split

(3) separators=[[\p{S} \p{P}]-[\u002d \u2010 ‘ : ; \. , @ \$ \+ ~ \= / \? \& % # ~ _]] (4) separa- tor_token_type=p

Wiersz (1) zawiera nazwę warstwy. Wiersz (2) to instrukcja, jak wyodrębniać tokeny (w tym wypadku należy dzielić tekst według separatorów, o czym decyduje przynależność warstwy do klasy split). Wiersz (3) to deklaracja wszystkich separa- torów (znaków podziału) w tym przebiegu: \p{S} w notacji wyrażeń regularnych oznacza klasę symboli specjalnych (np. znaków walut), \p{P} oznacza klasę zna- ków interpunkcyjnych; po znaku minusa podane są w nawiasach kwadratowych te znaki, które należy w tym przebiegu zignorować (znaki pauzy, półpauzy, apo-

(24)

strofu, dwukropka itd.). Wiersz (4) to instrukcja przypisania typu p do tokenów pełniących funkcję separatora.

Danymi wejściowymi w każdym kolejnym przebiegu są dane wyjściowe z przebiegu poprzedniego – w przypadku warstwy exc_0 są one tożsame z danymi wyjściowymi procesu segmentacji (Tabela 1-4).

Dane wyjściowe warstwy exc_0 obrazuje Tabela 1-5.

Tabela 1‑5. Dane wyjściowe drugiego przebiegu tokenizacji w programie ‚toki’

T Kupiłam (nowe) buty!

T Zapłaciłam

T 100

P $

T .

W kolejnym przebiegu (suff_safe) wyodrębniane są nawiasy oraz wybrane zna- ki interpunkcyjne (z wyłączeniem m.in. kropki) i oznaczane typem p. Dane wyj- ściowe po tym przebiegu mają postać przedstawioną w Tabeli 1-6.

Tabela 1‑6. Dane wyjściowe trzeciego przebiegu tokenizacji w programie ‚toki’.

T Kupiłam

P (

T nowe

P )

T buty

P !

T Zapłaciłam

T 100.

P $

T .

Kolejny przebieg (a_lexicon) odpowiada za wyodrębnienie wszystkich skró- tów, które podane są explicite w pliku o nazwie abbrev.txt. Etap oznaczony jako a_classify odpowiada za odseparowanie napisów, które składają się z samych spół- głosek zakończonych kropką – traktowane są one heurystycznie jako skróty. Skró- tom przydziela się typ tokenu a. Dopiero w kolejnym etapie (suff_dot) dokonuje się wyodrębnienia kropki jako znaku interpunkcyjnego kończącego zdanie. Kolejne

(25)

warstwy wykorzystują wyrażenia regularne do wyodrębniania tokenów i rozpo- znają kolejno:

– adresy mailowe i internetowe (tu_classify)

– pozostałe symbole specjalne i znaki interpunkcyjne (exc_2) – liczby i napisy numeryczne, np. adresy IP (n_classify) – formy fleksyjne skrótowców, np. PZPN-u (th_classify) – pauzyi i półpauzy (hyphen)

– pozostałe ciągi nietypowych znaków niesklasyfikowane w poprzednich przebiegach (ts_classify).

Podsumowując, należy stwierdzić, że program toki jest narzędziem szeroko konfigurowalnym. Bez ingerencji w kod programu można:

– zmodyfikować reguły podziału na segmenty – wystarczy nanieść zmiany w pliku segment.srx

– zmienić porządek przetwarzania – wystarczy zmienić kolejność warstw w sekcji [layers] w pliku config.ini

– poprawić reguły rozpoznawania poszczególnych typów tokenów – wystarczy dokonać zmian w poszczególnych sekcjach odpowiadającym warstwom (przebiegom przetwarzania)

– uzupełniać wybrany plik tekstowy leksykonu (np. abbrev.txt).

Dokładna inspekcja kodów narzędzia udostępnionego w repozytorium git¹⁴ projektu wykazuje pewne niedoskonałości. Po pierwsze, plik abbrev.txt na dzień 15 sierpnia 2017 zawiera tylko jeden element (skrót prof.). Po drugie, w repozyto- rium znajduje się kilka plików z wyrażeniami aglunatywnymi (typu abyśmy), do których nie ma odwołań w pliku config.ini. Sprawia to wrażenie, jakby projekt nie został ukończony.

Tokenizator PSI‑Toolkit

Punktem wyjścia do opracowania tokenizatora zestawu PSI-Toolkit był system tłumaczenia automatycznego Translatica (Jassem, 2009), w którym opracowano reguły tokenizacji dla czterech języków: polskiego, angielskiego, niemieckiego i rosyjskiego. W zestawie PSI-Toolkit zdefiniowano reguły tokenizacji dla języków:

14 git to najbardziej popularny obecnie system kontroli wersji oprogramowania – czyli środowi- sko, które umożliwia autorom projektu informatycznego dodawanie nowych fragmentów kodów do wspólnego repozytorium, przy czym zapamiętywany jest stan projektu przed i po każdej jego modyfikacji. Mechanizm ten zapewnia, że ewentualne szkody spowodowane wprowadzeniem zmiany są odwracalne. Każdy użytkownik z dostępem do systemu typu git ma możliwość sklonowania (zdupli- kowania) całego repozytorium danego projektu na swoim komputerze. Projekt toki przechowywany jest w repozytorium http://nlp.pwr.wroc.pl/toki.git, do którego dostęp jest całkowicie otwarty. Autor niniejszej pracy mógł więc sklonować repozytorium i przeanalizować jego zawartość.

(26)

niemieckiego, angielskiego, hiszpańskiego, fińskiego, francuskiego, włoskiego, polskiego, rosyjskiego, szwedzkiego i tureckiego.

Tokenizator opiera się na zestawach reguł umieszczonych w plikach .rgx. Pliki te zawierają makra i reguły tokenizacji. Plik common.rgx zawiera reguły niezależ- ne od języka. Pliki de.rgx, en.rgx, es.rgx, fi.rgx, fr.rgx, it.rgx, pl.rgx, ru.rgx, se.rgxx, se.rgx zawierają reguły specyficzne dla poszczególnych języków.

Makro zawarte w dowolnym pliku .rgx definiuje wzorzec tekstu i ma postać:

@def name regex

gdzie: @def oznacza początek definicji makra, name jest nazwą makra, a regex jest wyrażeniem regularnym

Reguła tokenizacji ma postać:

@rule name/token_type := extended_regex

gdzie: napis @rule oznacza początek reguły, name jest nazwą reguły, token_type oznacza typ tokenu zwracany przez regułę, a extended_regex to wzorzec tekstu zdefiniowany za pomocą makr i wyrażeń regularnych.

Na Wydruku 1-8 przedstawiony jest fragment pliku common.rgx¹⁵ (wiersze zo- stały ponumerowane dla potrzeb niniejszej pracy).

Wydruk 1‑8. Fragment pliku reguł tokenizacji systemu PSI‑Toolkit

(1) @def litera [a-zA-Z]

(2) @def litCyfSpMysl [a-zA-Z0-9_-]

(3) @def litSpMysl [a-zA-Z_-]

(4) @rule blank/B := [\ \n\r\t\f\p{Z}]+

(5) @rule punct/I := [!\?]+|[\.,;:\p{P}]

(6) @rule addr/X := (?:litera+:\/\/)? litSpMysl+ (?:\.(?:litCyfSpMysl)+)+ (?:\?[^\ ])?

W wierszu (1) zdefiniowano makro o nazwie litera, które reprezentuje dowol- ną litera z alfabetu łacińskiego.

W wierszu (2) zdefiniowano makro o nazwie litCyfSpMysl, które reprezentuje dowolną literę z alfabetu łacińskiego, dowolną cyfrę, znak podkreślenia lub znak półpauzy.

W wierszu (3) zdefiniowano makro o nazwie litSpMysl, które reprezentuje do- wolną literę z alfabetu łacińskiego, znak podkreślenia lub znak półpauzy.

W wierszu (4) zdefiniowano regułę o nazwie blank, która rozpoznaje niepusty napis dowolnej długości składający się ze znaków spacji, tabulacji lub niewidocz- nych znaków. W wyniku rozpoznania takiego napisu tokenizator ma zwrócić war- tość B jako typ rozpoznanego tokenu.

15 Plik ten znajduje się pod adresem: https://github.com/filipg/psi-toolkit/blob/master/tools/

tokenizers/tp/data/common.rgx

(27)

W wierszu (5) zdefiniowano regułę o nazwie punct, która rozpoznaje niepusty ciąg dowolnej długości składający się ze znaków wykrzyknika lub zapytania albo dowolny inny znak interpunkcyjny. W wyniku rozpoznania takiego ciągu tokeni- zator ma zwrócić wartość I jako typ rozpoznanego tokenu.

W wierszu (6) zdefiniowano regułę o nazwie addr, która korzysta ze zdefi- niowanych wcześniej makr litSpMysl oraz litCyfSpMysl w celu określenia wzorca, który odpowiada adresom internetowym. W wyniku rozpoznania takiego ciągu tokenizator ma zwrócić wartość X jako typ rozpoznanego tokenu.

Przykład 1-5. Działanie tokenizatora zestawu PSI-Toolkit Działaniu tokenizatora zestawu PSI-Toolkit poddano zdanie:

Adres zestawu narzędzi to psi-toolkit.wmi.amu.edu.pl.

Tokenizator zwraca informacje podane w Tabeli 1-7.

Tabela 1‑7.Przykładowy wynik działania tokenizatora PSI‑Toolkit

id. tokenu początek długość język Tekst typ tokenu

1 0 5 pl Adres T

2 5 1 pl _ B

3 6 7 pl zestawu T

4 13 1 pl _ B

5 14 9 pl narzędzi T

6 23 1 pl _ B

7 24 2 pl to T

8 26 1 pl _ B

9 27 26 pl p s i - t o ol k it .

wmi.amu.edu.

pl

X

10 53 1 pl . I

Dla każdego języka zdefiniowano ponadto plik abbrev.rgx, który zawiera listę skrótów danego języka. Przykład 1-6 obrazuje wpływ listy skrótów na wynik tokenizacji.

Przykład 1-6. Przetwarzanie skrótów w tokenizacji

Działaniu tokenizatorów zestawu PSI-Toolkit – polskiemu i angielskiemu – poddano następujące zdanie:

Przemawiać będzie prof. dr hab. Jan Kowalski.

Wyniki zwrócone przez oba tokenizatory przedstawione są w Tabeli 1-8. (skrót hab. znajduje się na liście skrótów polskich, ale nie – angielskich.)

(28)

Tabela 1‑8. Wpływ listy skrótów na działanie tokenizatora PSI‑Toolkit

id. tokenu tokenizator polski tokenizator angielski

1 Przemawiać Przemawiać

2 będzie będzie

3 prof. prof.

4 dr dr

5 hab. hab.

6 Jan .

7 Kowalski Jan

8 . Kowalski

9 .

Dla języka polskiego lista skrótów tokenizatora PSI-Toolkit zawiera 570 pozy- cji¹⁶. Tokenizator zestawu PSI-Toolkit rozróżnia więcej typów tokenów niż tokeni- zator toki – dla języka polskiego jest ich 23. Tabela 1-9 podaje przykładowe typy tokenów rozpoznawane przez tokenizator PSI-Toolkit:

Tabela 1‑9. Przykładowe typy tokenów zwracane przez tokenizator PSI‑Toolkit

Typ tokenu Opis

Blank sekwencja białych znaków

Text tekst bez białych znaków

Punct sekwencja znaków interpunkcyjnych Tag znaczniki (np. para znaków ‘<>’)

Int liczba całkowita

Iso Znak ISO

Path oznaczenie ścieżki dostępu do pliku

Podsumowanie sekcji 1.1.2

Tokenizacja tekstu nie jest zadaniem o jednoznacznie określonym rezultacie – wyniki zwracane przez różne tokenizatory dla tych samych danych wejściowych mogą się różnić w zależności od przeznaczenia tokenizatora. W niniejszej pracy opisano dwa narzędzia tokenizacji języka polskiego. Program toki ma architek- turę warstwową – przetwarza teksty w kilku przebiegach, które można wygodnie konfigurować, edytując sekcję [layers] w pliku config.ini. Tokenizator PSI-Toolkit wyróżnia więcej typów tokenów i dysponuje listami skrótów dla tokenizowanych języków. Konfigurowanie tokenizatora PSI-Toolkit możliwe jest poprzez zmianę kolejności zapisu reguł w pliku .rgx.

16 Lista ta znajduje się pod adresem:

https://github.com/filipg/psi-toolkit/blob/master/tools/tokenizers/tp/data/pl/abbrev.rgx

(29)

1.1.3. Analiza morfologiczna Cel analizy morfologicznej

W większości systemów przetwarzania tekstów, po tokenizacji następuje etap analizy morfologicznej. W etapie tym analizowane są tylko tokeny typu tekstowego (w tokenizatorze toki jest to typ t, w tokenizatorze PSI-Toolkit jest to typ text). Ce- lem jest pozyskanie dalszych informacji o jednostkach, które najprawdopodobniej są kluczowe dla rozpoznania znaczenia tekstu. Wyróżnia się dwie główne metody analizy morfologicznej: stemowanie i lematyzacja. Pierwsza z nich, której imple- mentacje działają zdecydowanie szybciej, znajduje zastosowanie przede wszyst- kim w przetwarzaniu danych dużego rozmiaru, np. w wyszukiwaniu informacji oraz grupowaniu dokumentów. Lematyzacja stosowana jest wszędzie tam, gdzie oczekuje się dokładniejszych informacji o jednostkach tekstu kosztem wydajności przetwarzania.

Przykład 1-7 wyjaśnia różnicę między pojęciami stemowania i lematyzacji.

Przykład 1-7. Porównanie oczekiwanych wyników stemowania i lematyzacji Tabela 1-10 obrazuje oczekiwane wyniki stemowania i lematyzacji dla różnych wyrazów wywodzących się z tego samego rdzenia semantycznego.

Tabela 1‑10. Porównanie oczekiwanych wyników stemowania i lematyzacji – na przykładzie Forma

fleksyjna Oczekiwany wynik

stemowania Oczekiwany wynik lematyzacji

budowałem bud budować +

czasownik +

czas przeszły, l. poj., 1. osoba, aspekt niedokonany

budowy bud budowa +

rzeczownik + dopełniacz, l. poj.

zbudowałem bud zbudować +

czasownik +

czas przeszły, l. poj., 1. osoba, aspekt dokonany

budowlany bud budowlany +

przymiotnik +

mianownik, l. poj., rodzaj męski Proces stemowania

Stemowanie (ang. stemming) to proces mający na celu wyekstrahowanie rdze- nia wyrazu, czyli morfemu leksykalnego wyrazu, zawierającego jego podstawowe znaczenie¹⁷. Przykład 1-7 wskazuje, że programy dokonujące stemowania (stem-

17 Definicja rdzenia podana jest za słownikiem języka polskiego PWN (sjp.pwn.pl)

(30)

mery) powinny dokonywać odcinania analizowanego wyrazu zarówno prze- drostków, jak i przyrostków (potencjalnie również wrostków). W praktyce jednak stemmery odcinają tylko końcowe litery wyrazów – co więcej, czynią to w sposób dalece niedoskonały.

Przykład 1-8. Przykład działania stemmera Snowball

Wydruk 1-9 obrazuje zastosowanie stemmera Snowball¹⁸ dla zdania w języku angielskim¹⁹:

Wydruk 1‑9. Wynik zwrócony przez stemmer Snowball

Tekst wejściowy:

Stemming is an inefficient computational process that computes stems very efficiently.

Tekst wyjściowy:

stem is an ineffici comput proces that comput stem veri effici.

Można zaobserwować, że dla dwóch par wyrazów o tym samym rdzeniu (stem- ming – stems, computational – computes) otrzymano (zgodnie z oczekiwaniami) ten sam rdzeń. Jednakże wyrazy inefficient oraz efficiently, wbrew oczekiwaniom, sprowadzone zostały do rdzeni różniących się przedrostkiem. Zaskakujące jest również sprowadzenie formy wyrazowej very do rdzenia veri.

Przykład 1-8 obrazuje, że w przetwarzaniu komputerowym nie oczekuje się, że wynik stemowania będzie identyczny z rdzeniem w rozumieniu lingwistycznym.

Stemmery dla języka polskiego

Dla języka polskiego stworzono kilka rozwiązań tego typu, a ich omówienie można znaleźć w pracy (Weiss, 2005). Przedstawione zostaną tutaj dwa narzędzia, różniące się znacząco metodą działania.

Lametyzator

Stemmer o nazwie Lametyzator (Weiss, 2003) został opracowany na bazie słownika i-spell²⁰. Słownik ten (obecnie zastąpiony przez słownik aspell²¹) składa się z kilku plików form podstawowych oraz z pliku instrukcji tworzenia z nich form fleksyjnych. Przykładowa instrukcja ma postać przedstawioną na Wydruku 1-10.

18 Strona projektu: http://snowball.tartarus.org/projects.html

19 Eksperymentu dokonano za pomocą stemmera dostępnego na stronie: http://text-proces- sing.com/demo/stem/

20 http://ispell-pl.sourceforge.net/

21 http://aspell.net/

(31)

Wydruk 1‑10.Przykładowa instrukcja tworzenia form fleksyjnych w słowniku ‚i‑spell’

> -Ć,ŁEM

Instrukcja ta informuje, że w formie podstawowej należy zastąpić ostatnią li- terę ć sekwencją liter łem. W ten sposób z lematów: usunąć, cisnąć można uzyskać formy wyrazowe usunąłem, cisnąłem.

Lametyzator, w oparciu o tego typu informacje, buduje automat skończony (pojęcie automatu skończonego zostanie wyjaśnione w podrozdziale 3.3), który akceptuje wszystkie formy fleksyjne zawarte w słowniku ispell.

Stempel

Inne podejście do stemowania proponowane jest w projekcie Stempel²². W roz- wiązaniu tym nie korzysta się ze słownika. W celu uzyskania rdzenia z formy flek- syjnej stosuje się zastąpienia liter zdefiniowane w tzw. regułach transformacji. Re- guły te pozyskiwane są automatycznie ze zbioru par: <forma fleksyjna – forma podstawowa> – im większy zbiór, tym większe pokrycie²³ wyekstrahowanego zestawu reguł. Przewagą takiego podejścia w stosunku do metody opartej na słowni- ku jest możliwość pozyskania informacji zwrotnej dla wyrazów, które nie występu- ją w leksykonie. Z drugiej strony, stemowanie wyrazów występujących w słowniku obarczone jest większą liczbą błędów.

Stempelator

W pracy (Weiss, 2005) autor porównuje skuteczność obu stemmerów z innymi rozwiązaniami²⁴ oraz opracowanym przez autora systemem hybrydowym, o na- zwie Stempelator. Stempelator zwraca wyniki takie jak Lametyzator dla wyrazów ze słownika ispell, oraz wyniki takie jak Stempel dla wyrazów spoza słownika. System hybrydowy uzyskuje wyższą jakość niż każdy z systemów z osobna (w przedziale między 70% a 85% - w zależności od badanego korpusu tekstów), a jego wydajność (liczona w liczbie wyrazów przetworzonych w ciągu sekundy) jest akceptowalnie niższa od każdego z systemów składowych (o ok. 30% - 50%).

22 http://getopt.org/stempel/#distrib

23 Pojęcie „pokrycie” jest tłumaczeniem angielskiego wyrazu „recall”, który w dziedzinie przetwarzania komputerowego oznacza procentową część danych, którą dana metoda przetwarza poprawnie. Termin „pokrycie zestawu reguł” jest skrótem myślowym – oznacza pokrycie (recall) uzyskane przez program, który przetwarza dane zgodnie z tym zestawem reguł.

24 Mowa tu o dwóch systemach stemowania opracowanych w ramach projektów magisterskich oraz o systemie lematyzacji Morfeusz

(32)

Proces lematyzacji

Przez kategorię syntaktyczną będziemy w niniejszej pracy rozumieć grupę wy- razów posiadających podobne cechy składniowe. Przykładowo, w języku polskim wyróżnić można kategorię rzeczownika, oznaczaną tutaj napisem subst, kategorię przymiotnika, oznaczaną napisem adj, kategorię czasownika określonego ozna- czaną napisem fin, kategorię bezokolicznika, oznaczoną napisem inf oraz kilkana- ście innych, mniej licznych kategorii.

Przez kategorię morfosyntaktyczną będziemy rozumieć grupę wyrazów nale- żących do tej samej klasy syntaktycznej o tych samych wartościach cech morfo- logicznych. Przykładowo, napisem fin:sg:ter:imperf oznaczana będzie kategoria morfosyntaktyczna, do której należą czasowniki określone w liczbie pojedynczej (sg), w trzeciej osobie (ter), w aspekcie niedokonanym (imperf), a napisem sub- st:pl:gen:m2 – kategoria morfosyntaktyczna rzeczowników w liczbie mnogiej (pl), w dopełniaczu (gen), w rodzaju męskim nieżywotnym (m2).

Lematyzacja to proces, który dla danej formy wyrazowej znajduje jej formę podstawową (lemat), a ponadto podaje informację, do jakiej kategorii morfosyntaktycznej należy forma wyrazowa²⁵. W przypadku wieloznaczności, od lematyzatora, czyli programu dokonującego lematyzacji, oczekuje się podania wszystkich możliwych kategorii morfosyntaktycznych, do których może należeć dana forma.

Obrazuje to Przykład 1-9.

Przykład 1-9. Wyniki zwracane przez lematyzator Morfeusz dla niejednoznacznej formy wyrazowej

Tabela 1-11 podaje wyniki uzyskane przez lematyzator Morfeusz²⁶ dla formy wyrazowej soli.

Tabela 1‑11. Wyniki zwracane przez lematyzator Morfeusz dla wyrazu ‘soli’

forma podstawowa kategoria

morfosyntaktyczna typ nazwy kwalifikacja semant.

solić fin:sg:ter:imperf

sol:s1⁶ subst:pl:gen:m2 nazwa pospolita monet.

Sola subst:pl:gen:f nazwa pospolita zool.

Sola subst:sg:dat:f nazwa pospolita zool.

Sola subst:sg:gen:f nazwa pospolita zool.

Sola subst:sg:loc:f nazwa pospolita zool.

25 Alternatywne podejście przyjmuje, że wynikiem lematyzacji jest wyłącznie zestaw lematów (bez kategorii morfosyntaktycznej).

26 Warto nadmienić, że w roku 2013 powstała wersja programu o nazwie Morfeusz 2 w postaci biblioteki dynamicznej, która umożliwia włączanie wyników lematyzatora do aplikacji autorskich (KIeraś, Woliński, 2017).