WCRFT

Wklejam fragment mejla od niego:

Dane które brały udział w ewaluacji (a przynajmniej ich część) umieściłem na stronie http://furtka.ogrodek.waw.pl/~kuba/no-maca-guesser/. W katalogu 'folds' są oryginalne foldy, w 'reana' foldy poddane ponownej analizie zgodnie z Twoimi wskazówkami. Katalog 'reana-guessed' zawiera dane 'reana' z dodatkowymi interpretacjami dla słów nieznanych (dla każdego po 10 najbardziej prawdopodobnych tagów), które zostały otrzymane przy pomocy zgadywacza statystycznego. Na koniec, 'reana-tagged' to wynik ujednoznaczniania danych z 'reana-guessed'. Wyżej podane liczby są wynikiem porównania kolejnych foldów ('folds/testXX.plain') z wynikami tagowania ('reana-tagged/testXX.plain'). W danych brakuje wyników tagowania dla folda 08, miałem z nim drobne problemy i testy przeprowadziłem na osobnej maszynie, do której nie mam teraz dostępu. Pod koniec tygodnia uzupełnię dane.

Te dane są już uzupełnione, fold 08 też powinien być.

Do testów, jak rozumiem, potrzebne będą dane z reana-tagged/testXX.plain. To są już gotowe wyniki tagera do porównania z tym samym, co my porównujemy, tj. folds/test##.xml. Dane są w fomacie plain (-i plain). Prawdopodobnie trzeba będzie najpierw to przekonwertować na format xces, bo skrypt porównujący tagery (patrz drugi ticket) zakłada, że wszystko jest w tym samym formacie. Można to przekonwertować corpus-getem, ew. maca analyse -t nkjp -c nop (nop, czyli nie używamy konwertera tagsetu — ale konwersji formatu możemy dokonać, -i plain -o xces). Może pojawić się problem, że ten format nie zachowuje akapitów. Musisz sprawdzić, czy to jest problem (chyba i tak korpus wzorcowy czytany jest token po tokenie a nie zdanie po zdaniu/akapit po akapicie). Gdyby jednak to był problem, to może zajść potrzeba przekonwertowania danych testowych (folds/testXX.xml) na format ten sam, ale bez zachowania podziału na akapity (corpus-get bez przełącznika -C tak właśnie robi).

W oryginalnych danych z NKJP był problem, że pojawiał się jeden token ze spacją w środku (orth=m. in.). Gdyby w danych Kuby też takie coś było (dowiesz się, jeśli wywali się corpus-get albo cokolwiek innego, co czyta ten plain), to możesz to ręcznie poprawić, to było jedno wystąpienie w całym korpusie. Ale raczej ten problem tu już jest wyeliminowany.