Uwagi o tworzeniu korpusów

Krzysztof Szafran
Instytut Informatyki UW
Uwagi o tworzeniu korpusów
(wersja z 4 lipca 2012 )
1. Wprowadzenie
Tekst niniejszy stanowi zbiór uwag i notatek, których celem jest ułatwienie początkującemu
użytkownikowi poliqarpa i rozmaitych narzędzi z nim związanych przygotowywanie korpusów.
Tekst w żadnym wypadku nie stanowi samodzielnej dokumentacji wymienionych w nim
programów i narzędzi i w wielu miejscach odsyła do tej dokumentacji.
Ostatnia część tekstu zawiera również pewne uwagi dotyczące instalacji poliqarpa oraz marasca.
2. Budujemy korpus — na przykładzie Słownika polszczyzny XVI wieku
2.1. Przygotowanie pdf-u
Poszczególne tomy Słownika przygotowywane są zwykle w postaci plików pdf ale często rozmaite fragmenty tomu zawarte są w oddzielnych plikach.
Wszystkie fragmenty dokumentu zawarte w oddzielnych plikach pdf muszą zostać połączone w jeden plik z zachowaniem właściwej kolejności stron. Można do tego użyć programu o
nazwie pdftk1 . Przykładowe wywołanie pokazane jest niżej.
pdftk SpXVI_35t_kpbc.pdf SpXVI_35t_wkl1_kpbc.pdf SpXVI_35t_wkl2_kpbc.pdf
cat output SpXVI_35t.pdf
Trzy pierwsze argumenty programu są nazwami plików zawierających kolejno tekst 35. tomu
słownika oraz tekst dwóch wklejek dołączonych do każdego tomu. Kolejny argument (’cat’)
oznacza polecenie połączenia tych plików. Ostatni jest nazwą pliku wynikowego, do którego ma
zostać zapisany cały dokument.
2.2. Konwersja do formatu DjVu
Kolejnym etapem jest przygotowanie kopii dokumentu w formacie DjVu. Punktem wyjścia jest
plik w formacie pdf.
Do konwersji dokumentu z formatu pdf do formatu DjVu można użyć programu o nazwie
pdf2djvu2 .
pdf2djvu -d 600
--filter-text=unligature -i index.djvu SpXVI_35t.pdf
Uwagi:
1. Użycie parametru -i powoduje powstanie tak zwanego rozdzielonego dokumentu DjVu (por.
man pdf2djvu). Plik indeksowy tego dokumentu powinien nazywać się index.djvu.
1
2
Por. np.: http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
Por. np.: http://jwilk.net/software/pdf2djvu
1
2. pdf2djvu domyślnie robi normalizację NFKC tekstu (patrz man pdf2djvu oraz http://
unicode.org/reports/tr15/), która w szczególności zamienia długie s na zwykłe s. Aby
tego uniknąć, należy użyć opcji: –filter-text=unligature.
— Źródła programu unligature są dostępne pod adresem: https://bitbucket.org/
jwilk/unligature. Jego instalacja polega na wywołaniu programu make. Zawarty w
dystrybucji plik makefile odwołuje się do pliku: /usr/share/unicode/UnicodeData.
txt. Należy zadbać o to, aby plik był dostępny i aby umieszczona w pliku makefile
informacja o jego lokalizacji była zgodna ze stanem faktycznym.
— W wielu dystrybucjach Linuksa (Debian, Ubuntu) plik UnicodeData.txt znajduje się
w pakiecie o nazwie unicode-data.
— W trakcie instalacji programu unligature następuje odwołanie do programu lex. W
niektórych popularnych wersjach Linuksa (np. Ubuntu) dostępny on jest w pakiecie flex.
2.3. Przygotowanie hOCR z plików DjVu
Jednym ze sposobów uzyskania plików w formacie hOCR jest wykorzystanie plików DjVu3 .
W tym celu używamy programu djvu2hocr z pakietu ocrodjvu4 :
djvu2hocr
--word-segmentation=uax29 SpXVI_35t.djvu > SpXVI_35t_hocr.xml
Uwagi:
1. W starszych wersjach programu djvu2hocr występował błąd, który powodował obrócenie
„do góry nogami” pliku hocr. W konsekwencji, jeśli zaznaczenia wskazujące znalezione
formy miały działać prawidłowo, konieczne było użycie opcji –flip przy wzbogacaniu korpusu. Fakt ten może stwarzać pewne niedogodności w przypadku dodawania do istniejącego
korpusu nowych dokumentów albo w przypadku tworzenia korpusu z istniejących wcześniej
i tworzonych aktualnie plików hocr. Niestety program do wzbogacania korpusu nie daje możliwości zastosowania opcji –flip w sposób selektywny, tylko dla wybranych dokumentów.
2. Pominięcie opcji "–word-segmentation=uax29" oznacza użycie domyślnego sposobu segmentacji (por. man djvu2hocr), co może powodować ’przyklejanie’ do form tekstowych
różnych znaków, np. cudzysłowów.
2.4. Nadawanie struktury dokumentom
W przypadku dokumentów wielostronicowych możliwe jest umowne dzielenie dokumentu na
części, w skład których wchodzą określone strony. W trakcie przeszukiwania korpusu możliwe
jest ograniczenie poszukiwań do wybranych części.
Dokonanie takiego podziału możliwe jest za pomocą programu annotate-hocr5 . Wymaga
on opisania struktury przetwarzanych dokumentów w pliku tekstowym, w odpowiednim formacie.
Przykładowo, struktura tomu 35 Słownika polszczyzny xvi wieku może być opisana następująco:
1
front,1,4
list,5,9
vacat,10,10
3
4
5
Inna możliwość opisana jest w dalszej części niniejszego tekstu.
Por. np.: https://bitbucket.org/ jwilk/ocrodjvu/overview
Por. np.: https://bitbucket.org/jwilk/marasca-wbl/src/f3e00b9275a6/misc/annotate-hocr
2
body,11,481
vacat,482,482
inset,483,494
Liczba w pierwszym wierszu specyfikuje, który z kolei dokument tekstowy opisują dalsze
wiersze. Każdy kolejny wiersz opisuje jedną sekcję dokumentu: front (tytularia itp.), intro (wstępy zawarte w I tomie), list (listy haseł na początku poszczególnych tomów), body (hasła), errata
(erraty i uzupełnienia), back (końcowe strony tomu), inset (wkładki z wykazem źródeł i skrótów).
Opis każdej z sekcji składa się z co najmniej trzech części zakończonych przecinakami albo
znakiem końca wiersza. Pierwsza część to napis definiujący nazwę sekcji, dwie dalsze to para
liczb całkowitych określająca zakres stron tworzących sekcję. Pozostałe części opisu stanowią
komentarz. W pliku z opisem dopuszczalne są również całe wiersze komentarza — muszą rozpoczynać się znakiem ’#’.
W powyższym przykładzie dokument dzielony jest na rozłączne części obejmujące sąsiednie strony. W ogólności możliwe jest nadanie dokumentowi struktury drzewiastej. Ilustruje to
poniższy przykład.
1
front, 1,140, (4)
intro, 5,140
list, 141,146
body, 147,452, (449) = 306
errata, 450,452
back, 453,454, spis treści
inset, 455,457
back, 458,459
Tutaj segment o nazwie intro zawarty jest (jest podsegmentem) w segmencie front. Podobnie errata jest fragmentem body.
Nie istnieje ustalony zestaw nazw segmentów, które mogą pojawić się w opisie. Jedynymi
ograniczeniem są struktura, która musi być drzewem, oraz konieczność umieszczenia w opisie
ojca przed synem.
Użycie programu annotate-hocr pokazane jest niżej.
./annotate-hocr -h
usage: annotate-hocr [-h] [--dry-run] [--in-place]
<hocr-file> [<hocr-file> ...]
Uwaga: Wbrew temu, co widać wyżej, jeden z parametrów kontrolujących wyjście, czyli
–dry-run albo –in-place, jest obowiązkowy.
Poniżej widać przykład nadania struktury jednemu dokumentowi.
./annotate-hocr --in-place
+ volume 1
SpXVI_35t_hocr.xml < struktura35.txt
Możliwe jest również nadanie struktury wielu dokumentom w jednym przebiegu programu.
./annotate-hocr --in-place
*/*.xml < struktura.txt
W takim przypadku plik struktura.txt musi zawierać ciąg opisów struktury kolejnych
dokumentów.
Przykładowy fragment takiego pliku dla Słowinka polszczyzny XVI wieku pokazany jest niżej.
3
1
front, 1,140, (4)
intro, 5,140
list, 141,146
body, 147,452, (449) = 306
errata, 450,452
back, 453,454, spis treści
inset, 455,457
back, 458,459
2
front, 1,6
list, 7,13
body, 15,540, (535) = 526
errata, 536,540
back, 541,542,v
errata, 543,547
3
front, 1,4
list, 5,11
body, 13,741, = 729
back, 742,742
Opisuje on trzy kolejne tomy słownika. Oczywiście należy zadbać o to, aby kolejność opisu
poszczególnych dokumentów była zgodna z kolejnością przetwarzania plików przez program
oraz o to, aby faktyczna liczba stron w dokumencie była zgodna z numerami stron w opisie.
2.5. Konwersja do formatu xces
Konwersji na format xces należy poddać każdy z dokumentów tworzących korpus. W przypadku dzieł wielotomowych, takich jak słowniki, naturalnym podziałem na dokumenty jest podział
na tomy.
Do konwersji używamy programu hocr2xces6 (należy upewnić się, że używamy aktualnej wersji — w starszych wersjach występował błąd polegający na sklejaniu słów na granicach
wierszy). Program ten wykonuje konwersję dokumentu zapisanego w formacie hocr czytanego ze standardowego wejścia, do IPI PAN-owskiego wariantu formatu xces. Wynik konwersji
wypisywany jest na standardowe wyjście.
Przykładowe wywołanie dla jednego dokumentu pokazane jest niżej.
hocr2xces < SpXVI_35t_hocr.xml > SpXVI_35_xces.xml
Uwaga: Program nie zakłada żadnych ustalonych postaci rozszerzeń nazw plików. W sensie
technicznym wszystkie one są XML-em. Wskazane jest takie ustalanie tych nazw, aby określały
jednoznacznie zawartość pliku. Ułatwia to uniknięcie ewentualnych pomyłek. Użycie skrótów
hocr i xces jako rozszerzeń jest możliwe, ale powoduje, że pliki te nie zawsze są automatycznie
poprawnie rozpoznawane jako xml przez system operacyjny i niektóre aplikacje.
6
Por. np. https://bitbucket.org/jwilk/marasca-wbl/.
4
2.6. Budujemy korpus — bpng
Do budowy korpusu używamy programu bpng7 . Zgodnie z informacją podaną w manualu, poza
samymi dokumentami w odpowiedniej wersji formatu xces, konieczne jest przygotowanie dla
każdego dokumentu pliku nagłówkowego oraz jednego wspólnego pliku konfiguracyjnego dla
tworzonego korpusu.
2.6.1. Plik konfiguracyjny dla korpusu
Plik konfiguracyjny powinien mieć nazwę ’nazwa_korpusu’.bp.conf, gdzie ’nazwa_korpusu’ jest wybraną przez nas nazwą. Plik ten specyfikuje nazwy plików z dokumentami i
odpowiadających im plików nagłówkowych oraz, przez odwołanie się do zawartości tych plików nagłówkowych, specyfikuje metadane korpusu. Również metadane, podobnie jak elementy
struktury, mogą być wykorzystywane w zapytaniach służących do przeszukiwania korpusu.
Przykładowy plik konfiguracyjny dla 35. tomu Słownika polszczyzny XVI wieku o nazwie
(na przykład) spxvi35.bp.conf może wyglądać jak niżej.
[locale]
locale = pl_PL
[filenames]
header = header.xml
morphosyntax = morph.xml
[meta]
name = volume
path = /meta/volume
[meta]
name = year
path = /meta/year
[meta]
name = range
path = /meta/range
[meta]
name = origin
path = /meta/origin
Jak widać plik ten składa się z sekcji, których nazwy ujęte są w nawiasy kwadratowe8 .
W sekcji [filenames] podane są nazwy plików z dokumentami (tutaj morph.xml) oraz
ich nagłówkami (tu header.xml). W przypadku korpusu składającego się z wielu dokumentów,
każdy z nich powinien być zawarty w plikach o takich samych nazwach natomiast do przetwarzania programem bpng powinny one zostać umieszczone w odpowiedniej strukturze katalogowej
— każdy dokument (czyli opisujące go dwa pliki) w oddzielnym podkatalogu.
Kolejne cztery sekcje o nazwie [meta] definiują metadane przewidziane dla wszystkich
dokumentów w danym korpusie. Każda z tych sekcji definiuje jeden rodzaj informacji ujętej w
metadanych.
7
8
Por. np. http://poliqarp.sourceforge.net/man/bpng.html
Bardziej szczegółowy opis budowy tego pliku znajduje się na stronie manuala programu bpng.
5
Pierwszy wiersz sekcji, rozpoczynający się od napisu ’name’ definiuje rodzaj metadanej.
Tak więc w tym przypadku metadane składają się z pozycji: volume, year, range, origin.
Oczywiście liczba pozycji w metadanych, a co za tym idzie liczba odpowiadających im sekcji
może być dowolna, podobnie jak nazwy nadane tym pozycjom 9 .
Kolejny wiersz rozpoczynający się od słowa ’path’ pokazuje, gdzie w pliku nagłówkowym
można znaleźć wartość opisywanej metadanej.
W tych sekcjach dopuszczalne są jeszcze pewne dodatkowe wiersze, ułatwiające kontrolę
postaci danych (por. strona manuala programu bpng).
2.6.2. Pliki nagłówkowe
Pliki nagłówkowe nie maja ściśle określonego formatu ale pod względem formalnym powinny
stanowić poprawnie zbudowany plik XML-owy10 . Sposób wykorzystania ich zawartości opisany
jest w pliku konfiguracyjnym — jak już powiedzieliśmy wyżej, wyrażenia ’path’ definiują
dostęp do wartości dla poszczególnych elementów metadanych.
Przykładowa zawartość pliku header.xml dla 35. tomu słownika, odpowiadająca pokazanemu wyżej plikowi konfiguracyjnemu widoczna jest niżej.
<meta>
<volume>35</volume>
<year>2011</year>
<range>from Q to ROWNY</range>
<origin>pdf</origin>
</meta>
2.6.3. Tworzenie korpusu — program bpng
Samo wywołanie programu bpng może mieć postać pokazaną niżej.
bpng ’nazwa_korpusu’ <katalog_z _danymi>
Parametr <katalog_z_danymi> powinien wskazywać odpowiednią strukturę katalogów zawierającą podkatalogi — oddzielny dla każdego dokumentu — z plikami opisującymi dokument
i jego nagłówek. Poniżej przykładowe wywołania z konkretnymi parametrami.
bpng spxviw ../spxviw-xces/t*
bpng spxvi35 spxvi35.data/
Niektóre inne postaci wywołania (np. katalog bieżący zamiast <katalog_z_danymi>) mogą
powodować problemy.
2.6.4. Szacunkowa liczba tokenów w korpusie
Oszacowanie liczby tokenów w korpusie można uzyskać dzieląc wielkość pliku:
<nazwa>.poliqarp.corpus.image
przez 12.
9
Przeglądarka marasca traktuje metadane w specyficzny sposób. Ich postać, dla pewnych korpusów znanych
przeglądarce, jest ściśle określona i kontrolowana. Dla korpusów, których nazw przeglądarka nie zna, ich postać
jest dowolna.
10
Oznacza to w szczególności, że niektóre znaki, np. & nie mogą być używane w metadanych w sposób
dowolny.
6
2.6.5. Indeksy — bpindexer
Dodatkowym elementem korpusu mogą być indeksy, które nie są obowiązkowe i nie są bezpośrednio widoczne dla użytkownika z poziomu klienta używanego do przeglądania korpusu,
ale wyrażnie przyspieszają wykonywanie zapytań. Do ich tworzenia służy program o nazwie
bpindexer, który domyślnie tworzy trzy indeksy (por. man bpindexer). Dla korpusu Słownik
polszczyzny XVI wieku pożyteczny jest tylko indeks form ortograficznych.
Można go stworzyć używając opcji -i o.
bpindexer -i o <nazwa_korpusu>
2.7. Wzbogacanie korpusu
Wzbogacenie korpusu jest operacją, która pozwoli przeglądarce marasca na pokazanie wyniku
zapytania w postaci zaznaczenia znalezionego tokenu na obrazie strony pokazanej w formacie
DjVu. Aby korpus wzbogacić, należy użyć programu augment-djvu-corpus11 .
./augment-djvu-corpus -h
usage: augment-djvu-corpus [option...] <base-name> <hocr-file...>
Augment Poliqarp binary corpus with information about segment coordinates.
positional arguments:
base
corpus basename
files
hOCR files
optional arguments:
-h, --help show this help message and exit
--flip
flip hOCR vertically (to work around buggy djvu2hocr)
--append
append data to the existing corpus
Przykładowe wywołania pokazane są niżej.
augment-djvu-corpus spxvi35 SpXVI_35t.xml
augment-djvu-corpus --flip spxviw ../spxviw-hocr/t*/text.hocr
Uwagi:
1. Do wzbogacenia należy użyć plików hocr (nie xces!)
2. Jeśli w gotowym korpusie zaznaczenie, zamiast we właściwym miejscu, będzie pojawiać się
symetrycznie względem środka strony, oznacza to, że należało użyć opcji –flip (por. wyżej,
opis przygotowywania plików hocr).
3. W przypadku wielu dokumentów w korpusie należy zadbać o właściwą kolejność przetwarzania, zgodną z kolejnością wstawiania dokumentów do korpusu.
Następnie należy zmodyfikować zawartość pliku <basename>djvu.filenames tak, aby pokazywał faktyczne dokumenty djvu. Plik ten powinien zawierać adresy URL rozpoczynające się
od http: (niestety nie może to być adres typu file://).
Uwaga:
Jednym z możliwych rozwiązań w przypadku konieczności zorganizowania dostępu do djvu,
jeśli komputer nie ma zewnętrznego adresu internetowego natomiast ma poprawnie zainstalowaną marascę, którą widać np. pod adresem ’http://poliqarp/, jest umieszczenie w katalogu ’ma11
Por. np.: https://bitbucket.org/jwilk/marasca-wbl.
7
rasca/marasca/media/extra’ linku symbolicznego do katalogu z plikiem djvu. Wtedy w pliku
filenames należy umieścić informację:
http://poliqarp/extra/kpbc-spxvi35/index.djvu
(tutaj sam plik nazywa się ’index.djvu’).
2.8. Opisy
Do tworzenia opisów widocznych na stronie wyszukiwarki używany jest mechanizm stosowany
w django12 .
W katalogu /marasca/marasca/templates/ znajdują się pliki zawierające wzorce (templates) opisujące wspólne fragmenty strony, natomiast w podkatalogu /marasca/marasca/
ptemplates/coprpora/ umieszczone są wzorce dotyczące poszczególnych korpusów.
W dystrybucji marasca w tym miejscu znajdują się opisy pewnej liczby korpusów znanych
przeglądarce, co może ułatwić przygotowanie opisu nowego korpusu.
Na przykład plik zawierający pierwszą część opisu (będzie ona widoczna w oknie przeglądarki przed polem przewidzianym do wpisywania zapytań do korpusu) opisu słownika Lindego
(plik o nazwie slownik-lindego.html, gdzie fragment ’slownik-lindego’ odpowiada identyfikatorowi korpusu występującemu w plikach konfiguracyjnych marasca, może wyglądać jak
niżej.
{% load i18n %}
{% blocktrans %}<p>
<a href=’http://poliqarp.wbl.klf.uw.edu.pl/extra/linde/index.djvu’>A
preliminary electronic version</a> of the second edition of Linde’s dictionary
</p>
{% endblocktrans %}
{% blocktrans %}<p>
Scans were made with Fujitsu fi-6130 scanner and Kofax VRS software by Joanna
A. Bilińska. OCR was prepared with FineReader 10 (selected language Polish,
default values of other recognition parameters) and saved as PDF/A files with
MRC lossy compression. The scans has been converted to DjVu format by Jakub
Wilk, he also converted the OCR results to the suitable corpus format.
</p>
{% endblocktrans %}
{% blocktrans %}<p>
The corpus consists of ca. 7 million segments. This version of the
corpus is available since August 6, 2010.
</p>
{% endblocktrans %}
Druga część opisu (widoczna w oknie przeglądarki poniżej pola przewidzianego do wpisywania zapytań) zawarta w pliku o nazwie slownik-lindego_sufiks.html może mieć następującą postać.
{% load i18n %}
{% blocktrans %}<p>
12
Por. np. https://docs.djangoproject.com/en/dev/ref/templates/
8
It is recommended to switch on graphical concordances option in
<a href=’/settings/’>Settings</a>.
{% endblocktrans %}
{% blocktrans %}<p>
Search can be limited to a specific volume with the <code>within</code> clause,
e.g. <code>within vol6</code> or <code>within vol6part2</code>. The clause can
be also used to limit the search to the following sections:
<code>body</code> (entries and their corrections),
<code>errata</code> (just the corrections),
<code>intro</code> (introductory texts),
<code>info</code> (other informations),
<code>varia</code> (dedications, subscriber lists),
<code>front</code> (frontmatter),
<code>back</code> (backmatter).
</p>
{% endblocktrans %}
{% blocktrans %}<p>
Please send questions and comments to
<a href=’mailto:[email protected]’>[email protected]</a>.
</p>
{% endblocktrans %}
Po przygotowaniu nowego albo zmianie opisu istniejącego korpusu należy uruchomić skrypt
update-i18n, który zwykle znajduje się w katalogu marasca/marasca/.
Zaktualizuje on, między innymi, plik locale/pl/LC_MESSAGES/django.po, który powinien zawierać polskie tłumaczenia komunikatów (czyli fragmentów opisu ujętych w znaczniki
{% blocktrans %}, {% endlocktrans %} w plikach pokazanych wyżej).
W przypadku dodawania nowego opisu, w pliku znajdować się będą komunikaty, którym
nie przypisano polskich odpowiedników natomiast w przypadku modyfikacji opisu istniejącego
polskie wersje nie będą odpowiadać treści wersji angielskiej.
W obu przypadkach plik należy poddać edycji. Można do tego użyć dedykowanego edytora poedit (por. http://www.poedit.net/), ale możliwe jest też użycie dowolnego edytora
tekstowego.
Następnie należy wykonać polecenie:
./manage compilemessages
Aby wyniki były widoczne na stronie wyszukiwarki należy przeładować serwer WWW.
Uwagi:
1. Z formalnego punktu widzenia do tworzenia opisów należy używać standardu XHTML.
2. Warto zauważyć, że jako cudzysłowy, w które ujęte są wartości atrybutów użyte zostały znaki
apostrofu.
3. Przy przygotowywaniu opisów oraz ich tłumaczeń należy zwrócić szczególną uwagę na to,
aby w tekście wszystkie cudzysłowy były prawidłowo pozamykane oraz aby znacznikom <a
href= ... > zawsze odpowiadały znaczniki zamykające </a>.
9
3. Korpusy font sensitive — na przykładzie Słownika Lindego
Korpusy tego typu pokazują informację o fontach, którymi złożone są w dokumencie formy, stanowiące wynik zapytania. Tego typu informacja może być użyteczna w przypadku dokumentów
historycznych, które często w całości albo we fragmentach były składane czcionką gotycką.
3.1. Skrypt font_sensitive.py M.Zająca
Podstawowym narzędziem wykorzystywanym do tworzenia tego typu korpusów jest program
font_sensitive.py przygotowany przez Marcina Zająca 13 .
Zgodnie z informacją zawartą w README program przekształca pliki hOCR w korpus,
który może być oglądany programem poliqarp. Traktuje on informację o fontach jako kategorię
gramatyczną co pozwala użytkownikowi na wykorzystanie jej przy przeszukiwaniu korpusu.
Sposób wywołania widać niżej.
./font_sensitive.py corpus_name list_of_filenames_to_convert
Mankamentem programu jest brak parametryzacji pliku konfiguracyjnego korpusu oraz plików nagłówkowych poszczególnych dokumentów — ich treść wpisana jest na stałe w teść programu. Stwarza to pewne niedogodności zwłaszcza przy tworzeniu korpusów składających się
z wielu dokumentów, dla których zawartość plików nagłówkowych powinna być zróżnicowana.
W trakcie działania programu najpierw pliki hOCR zawierające dane przekształcane są do
formatu xces, dołączane są pliki nagłówkowe, tworzony jest plik konfiguracyjny korpusu a dopiero potem tworzony jest korpus. Drobna ingerencja w treść programu polegająca na usunięciu
wywołania programu bpng pozwala na dwuetapowe przygotowanie korpusu.
W pierwszym kroku, przy użyciu lekko zmodyfikowanego programu, z plików hOCR tworzone są dane w postaci plików xces i plików nagłówkowych. W kroku drugim, po dokonaniu
odpowiednich korekt w nagłówkach i pliku konfiguracyjnym, wywoływany jest program bpng i
tworzony korpus.
3.2. Przygotowanie plików hOCR z plików pdf
Danymi dla programu M. Zająca są pliki w formacie hOCR. Jednym ze sposobów przygotowania
takich plików jest użycie programu pdfa@hocr14 .
Przykładowe wywołanie (dla jednego z tomów drugiego wydania słownika Lindego) może
wyglądać jak niżej.
pdfa2hocr.py -v -i -p -u pl_PL -r 5107x6605 6iiFR11.pdf
Linde2-6ii.html
Bardzo istotnym parametrem wywołania tego programu jest parametr -r, w opisie użycia
oznaczony jako resolution.
-r RESOLUTION, --resolution=RESOLUTION
resolution of page in pixels
Należy pamiętać, że jest to parametr wejściowy określający wielkość strony dokumentu w
pixelach. Użycie nieprawidłowej wartości może powodować, że zaznaczenia wyszukanych w
korpusie form nie będą trafiać we właściwe miejsca w odpowiednich plikach djvu. Informację
13
Skrypt dostępny jest w repozytorium: https://bitbucket.org/jwilk/marasca-wbl.
Program ten, którego autorem jest T. Olejniczak dostępny jest w
https://bitbucket.org/tomek87/pdfautils.
14
10
repozytorium
o wielkości strony dokumentu w pliku djvu udostępnia np. przeglądarka DjView (menu kontekstowe, pozycja information).
Niestety parametr -r jest aktualny dla wszystkich stron w przetwarzanym dokumencie a dla
niektórych druków strony mogą mieć dość znacznie zróżnicowane wymiary. Taka sytuacja ma
miejsce np. dla pierwszego wydania słownika Lindego udostępnianego przez KPBC. W takim
przypadku konieczne jest przyjęcie najbardziej typowej albo uśrednionej wielkości strony.
3.3. Nadawanie struktury
Jak zostało powiedziane wcześniej, do nadawania struktury dokumentom hOCR używamy skryptu annotate-hocr. Skrypt ten wymaga aby plik miał odpowiednią strukturę formalną. W praktyce sprowadza się to do odpowiedniej postaci nagłówka takiego pliku. Powinien on rozpoczynać
się znacznikiem:
<html xmlns="http://www.w3.org/1999/xhtml">
Znacznik ten mówi, że plik zapisany jest w formacie xhtml. Natomiast pliki generowane
przez pdfa2hocr z formalnego punktu widzenia zapisane są w formacie html (mają nagłówki
rozpoczynające się od <html>.
W związku z tym konieczne jest wprowadzenie odpowiednich zmian w plikach hocr. Można
do tego wykorzystać polecenie:
sed -i -e ’s,<html>,<html xmlns="http://www.w3.org/1999/xhtml">,’ <plik-hocr>
Uwaga: Przy nadawaniu struktury wielu dokumentom umieszczonym w jednym katalogu
należy zwrócić baczną uwagę na kolejność w jakiej skrypt pobiera pliki do przetwarzania —
musi ona być zgodna z kolejnością opisów.
3.4. font_sensitive — przygotowanie danych dla bpng
Jak wspomniano już wcześniej skrypt font_sensitive ma wpisaną na stałe postać pliku konfiguracyjnego korpusu oraz treść plików nagłówkowych przetwarzanych dokumentów. Dla uproszczenia następnego kroku, czyli ręcznego edytowania tych plików, warto zmodyfikować treść
skryptu tak, aby edycja pliku konfiguracyjnego nie była konieczna a edycja nagłówków wymagała jak najmniejszych zmian15 .
Przykładowe wywołanie skryptu przystosowanego do tworzenia korpusu słownika Lindego
pokazane jest niżej.
/font_sensitive_forLinde.py LindeAll hocry-anotowane/*.xml
Wynikiem takiego wywołania będzie stworzenie w katalogu LindeAll podkatalogu o nazwie LindeAll.data zawierającego plik konfiguracyjny dla korpusu oraz podkatalogi, z których każdy zawiera plik z danymi w formacie xces i nagłówek dla niego.
3.5. Edycja danych i stworzenie korpusu
Kolejnym krokiem jest poddanie edycji plików nagłówkowych oraz wykonanie korpusu i jego
wzbogacenie. Kroki te wyglądają analogicznie, jak opisane w poprzedniej części tekstu.
15
Przy okazji zmodyfikowano nieco strukturę katalogów, w której skrypt umieszcza dokumenty wynikowe.
11
3.6. Uzyskany wynik
Niestety uzyskany w ten sposób korpus nie zawiera informacji o nadanej dokumentom strukturze. Bliższa analiza treści skryptu font_sensitive pokazuje, że ignoruje on znaczniki wprowadzone w trakcie nadawania struktury, co oznacza, że przynajmniej na razie, nie jest możliwe
wykonywanie korpusów zawierających informację o fontach i jednocześnie informację o strukturze dokumentu.
4. Instalacja podstawowych programów
4.1. Poliqarp
4.2. Instalacja z pakietów
Najprostszym sposobem instalacji poliqarpa jest wykorzystanie pakietów przygotowanych dla
systemu operacyjnego Linux w wersji Debian i pokrewnych, w formacie deb16 .
Poszczególne pakiety zawierają (numery mogą się zmieniać, w zależności od wersji):
— poliqarp-base_1.3.11_i386.deb:
1. bp — tworzy korpus binarny (format XCES),
2. bpindexer — buduje indeksy dla korpusu binarnego,
3. bpng — tworzy korpus binarny (formaty IPIPAN XCES, NKJP TEI)
4. bpupgrade — konwertuje korpusy binarne,
5. poliqarpc — klient uruchamiany z wiersza poleceń,
6. poliqarpd — serwer polqarpa.
Każdy z tych programów ma własny opis w manualu(1). Istnieje też strona manuala opisująca
składnię zapytań — poliqarp-query-syntax(7).
Ponadto podczas instalacji pakietu, w katalogu /usr/share/doc/poliqarp-base umieszczane są ważne pliki przykładowe, miedzy innymi konfiguracyjne, oraz plik README.gz
zawierający zwięzły opis instalacji poliqarpa ze źródeł oraz opis użytkowy podstawowych
programów.
— poliqarp-gui_1.2.11_i386.deb zawiera:
1. poliqarp — interfejs graficzny do poliqarpa.
Ma on również (skromną) stronę w manualu.
4.2.1. Konfiguracja
Po zainstalowaniu pakietów żadne pliki konfiguracyjne nie są tworzone automatycznie. Również
serwer poliqarpd nie startuje automatycznie — wymaga ręcznego uruchomienia, np tak:
poliqarp -d -c /home/kszafran/.poliqarp/poliqarpd.conf
gdzie plik poliqarpd.conf jest plikiem konfiguracyjnym dla serwera.
Uwaga: Przykładowy plik konfiguracyjny dostarczany z pakietem zawiera opcję max-match-size,
której nazwę należy ewentualnie zmienić na max-match-length.
4.2.2. Test poprawności działania
Do przetestowania poprawności instalacji oraz do oswojenia się z poliqarpem można wykorzystać materiały dostępne na stronie Korpus JP: http://korpus.pl/index.php?page=download
16
Por. http://jwilk.net/software/poliqarp
12
Niestety dostępne tam wersje binarne korpusów zostały przygotowane w tak zwanej wersji
1 i wymagaj konwersji za pomocą programu bpupgrade.
4.3. Instalacja ze źródeł
Osoby zainteresowane albo zmuszone do wykonania instalacji poliqarpa ze źródeł znajdą opis
postępowania we wspomnianym wyżej pliku README
4.4. marasca
Źródła programu marasca należy pobrać z odpowiedniego repozytorium. Najwygodniej można
to zrealizować przez stworzenie jego kopii:
hg clone https://bitbucket.org/jwilk/marasca-wbl
Przy pobieraniu plików z repozytorium marasca należy upewnić się, że właściwie ustawiony jest parametr branch — powinien on mieć wartość ’wbl’. Czy jest tak w istocie, można
sprawdzić w pliku ’branch’ w katalogu ’.hg’ klonu repozytorium.
Kopia repozytorium zawiera kilka katalogów. Przeglądarka marasca znajduje się w katalogu
o nazwie marasca.
4.4.1. Instalacja
Instalacja sprowadza się do:
1. Wykonania skryptu setup znajdującego się w katalogu marsca.
2. Wyedytowania powstałego w wyniku wykonania poprzedniego kroku pliku $hostname.py
znajdującego się w podkatalogu settings na wzór znajdującego się tam pliku wbl.py.
Po wykonaniu powyższych czynności należy upewnić się, że w pliku (/marasca/settings/
__init__.py) właściwie ustawiony jest dostęp do plików z opisami korpusów, np. tak, jak niżej
(ścieżki powinny być ścieżkami bezwzględnymi do odpowiedniego katalogu/katalogów):
LOCALE_PATHS = (
’/home/www/project/common_files/locale’,
’/var/local/translations/locale’
)
oraz, że uprawnienia do plików .mo są poprawne17 .
Poza katalogiem marasca z repozytorium do poprawnego działania aplikacji niezbędny jest
katalog locks, zwykle umieszczony na tym samym poziomie, co marasca. Jego dokładna lokalizacja określona jest w pliku konfiguracyjnym $hostname.py (na końcu pliku).
Uwaga: Problemy przy uruchamianiu przeglądarki mogą być spowodowane brakiem albo
niewłaściwymi prawami dostępu do plików logów albo katalogu locks.
5. Konfiguracja korpusów
W zależności od tego, jakiego klienta chcemy używać do oglądania korpusów, konieczne jest
umieszczenie odpowiednich informacji we właściwych plikach konfiguracyjnych.
17
W razie potrzeby należy wykonać najpierw polecenie ./manage compilemessages.
13
5.1. Plik konfiguracyjny serwera poliqarp
Niestety nie jest możliwe takie skonfigurowanie serwera poliqarpd aby można było oglądać
korpusy korzystając zarówno z klienta graficznego, jak też z marasca. W takiej sytuacji konieczne jest wykorzystanie dwóch kopii serwera, z których każda używa innego numeru portu
do komunikacji z klientem.
5.2. Klient graficzny
Klient graficzny uruchamiany poleceniem poliqarp korzysta z pliku konfiguracyjnego o nazwie
.poliqarp.cfg. W tym pliku możliwe jest ustawienie numeru portu, przez który będzie się on
komunikował z serwerem poliqarpd.
Analogicznie w pliku konfiguracyjnym serwera poliqarpa należy ustawić identyczny numer
portu.
5.3. marasca
W pliku konfiguracyjnym serwera poliqarpd (poliqarpd.conf), który ma współpracować z
marasca konieczne jest dodanie odpowiedniej informacji o lokalizacji korpusu. Może ona mieć
postać widoczną niżej.
corpus = slownik-lindego: /srv/poliqarp/corpora/LindeSE
Uwaga:
1. Wpisanie takiej informacji do pliku konfiguracyjnego serwera komunikującego się z klientem graficznym spowoduje zakłócenie jego pracy.
2. Po dodaniu opisu korpusu do pliku konfiguracyjnego należy ponownie uruchomić serwer
poliqarpa.
Następnie w pliku $hostname.py, o którym była mowa wyżej, w tablicy zwracanej przez
funkcję _get_corpora() dodajemy opis nowego korpusu:
DjVuCorpus(path=’/srv/poliqarp/corpora/LindeSE’
id=’slownik-lindego’,
title=_(u’Linde SE’),
abbreviation=’LindeSE’,
has_interps=True
)
Uwaga:
1. Nazwa ’DjVuCorpus’ nie może zostać zmieniona.
2. Należy się upewnić, że w opisach korpusów w pliku $hostname.py znajduje się wiersz
abbreviation = ... .
6. Konfiguracja Apache’a
Na to aby aplikacja marasca została w pełni zintegrowana z serwerem Apache należy wykonać
następujące operacje.
1. Zainstalować pakiet (libapache2-mod-wsgi) dostarczajacy wsgi (w katalogu /etc/apache/
mods-enabled/ pojawiają się linki wsgi.conf i wsgi.load do /mods-available/, gdzie są
opisy dostępnych modułów).
14
2. Umieścić w katalogu /apache2/sites-available/ odpowiednio zmodyfikowany plik
polqarp.
<VirtualHost *:80>
ServerName poliqarp.kanji.klf.uw.edu.pl
Alias /robots.txt /dev/null
Alias /favicon.ico /dev/null
Alias /css/ /home/kszafran/NEW/marasca/marasca/media/css/
Alias /js/ /home/kszafran/NEW/marasca/marasca/media/js/
Alias /extra/ /home/kszafran/NEW/marasca/marasca/media/extra/
AliasMatch ^/google(.*) /home/kszafran/NEW/marasca/marasca/media/google/$1
WSGIDaemonProcess marasca
WSGIProcessGroup marasca
WSGIScriptAlias / /home/kszafran/NEW/marasca/django.wsgi
CustomLog ${APACHE_LOG_DIR}/poliqarp-access.log vhost_combined
</VirtualHost>
Uwaga: W pewnych sytuacjach konieczne moż być dokonanie dodatkowego wpisu w pliku
/etc/hosts.
3. Umieścić w podkatalogu /sites-enabled/ link do pliku poliqarp
4. Umieścić w katalogu marasca (dokładna lokalizacja podana jest w pliku poliqarp) odpowiednio zmodyfikowany pliku django.wsgi, np. taki:
import os
import sys
os.environ[’DJANGO_SETTINGS_MODULE’] = ’settings’
sys.path.append(’/home/kszafran/NEW/marasca/marasca/’)
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
5. Zrestartować serwer Apache.
15