Morfologik

Do niedawna nie było dla polszczyzny korpusu, w którym ręcznie zweryfikowano by podział na zdania (a przynajmniej ja nic o dostępności takiego zasobu nie wiedziałem). Całe szczęście, trwają prace nad Narodowym Korpusem Języka Polskiego – i obejmują one także ręczne oznaczenie tekstu, w tym podział go na zdania. Uzyskałem do testów próbkę obecnie opracowywanego tekstu, aby móc przetestować swoje reguły. Okazało się, że stosujemy nieco inne konwencje – np. ja uznawałem, że liczby porządkowe na początku zdań są osobnym elementem, a nie fragmentem zdania (w OpenOffice.org takie liczby generowane automatycznie nie są w ogóle widoczne dla LanguageTool). Ale po ujednoliceniu takich konwencji przystąpiłem do testów. Wykryłem trochę usterek w regułach SRX, usunąłem je i wyniki są obecnie następujące. W próbce było 42426 znaczników podziału (dalej oznaczone jako Z). Dokładność ( precision ) podziału wyniosła 0,993234 . Kompletność ( recall ) 0,998353 . Poprawność ( accuracy ) 0,991609 . (Wszyst...

This post is related to many languages, so I'm posting in English. Recently, during PALC 2009 , I had a talk on unsupervised generation of rules for LanguageTool. The idea is when you have an error corpus (and you can create one based on Wikipedia revision history , by the way, here's a draft of my paper on creating the error corpus from Wikipedia ), you can use transformation-based learning techniques to create rules that may be used to boostrap rule creation for new languages in LanguageTool. Of course, what I have right now, are only quick hacks and script prototypes, but as you can see in my presentation, I'm planning to make the process a bit easier to use. First of all, the extraction of the error corpus from Wikipedia revision history can be fully ported to Java (I will add filters to remove synonym-for-synonym revisions but some of the most frequent changes are used to adapt the text to some editorial conventions, so they would have to be filtered manually). Curren...

(As this is of interest not only to the Polish-speaking community, this post is in English.) Recently, after some discussions on the lingucomponent list at OpenOffice.org on the method of finding frequent typos, I did some experiments on the revision history logs. Background. The developers of grammar checkers, and autocorrect lists, have hard times with finding relevant corpora. Revision history is an excellent source about native speakers perception of linguistic norms. Frequently revised typos are perceived as errors that need to be corrected, so using these typos on autocorrect lists is justified. The same goes for style, grammar and usage errors. Method . Experiments involved three steps: Clean the history dump (??wiki-latest-pages-meta-history.xml), to get only relevant parts of the dump. Using XML tools isn't recommended (I tried XSLT, forget it). Using a simple awk script, I was able to clean the > 30GB dump in an hour or so, and got a >17 GB file. The script is simp...

Po przygotowaniach przeprowadziłem kilka eksperymentów. I tak okazało się, że poprzedni algorytm był po prostu błędny – generował miliony plików w jednym katalogu. Zamiast tego najpierw „oczyszczam” tekst wiki ze znaczników (na razie nadal są różne brudy), dzieląc go na poszczególne wyrazy i zapisuję do specjalnego pliku pośredniego ze znacznikami startu i końca poszczególnej poprawki. Zajął on około 20 GB. Następnie porównuję kolejne wersje artykułu standardowym poleceniem diff (w trzecim skrypcie). W efekcie powstaje korpus w dosyć standardowym formacie ujednoliconym (jak dla polecenia patch czy CVS). Nadal powstaje, więc nie wiem, jak będzie wielki, ale raczej będzie mniejszy, może kilkaset megabajtów? Z tego korpusu można wydobywać różne rodzaje zmian – na razie ignoruję w eksperymentach komentarze, ale może będzie warto to też uwzględnić. Udaje mi się wyczytać różne rodzaje poprawek literówek czy błędów ortograficznych (sie → się): na razie badam pojedyncze wyrazy, ale może będ...

Jedną z metod tworzenia korektorów gramatycznych i stylistycznych jest wykorzystywanie korpusu błędów, o czym już tutaj pisałem. Najciekawsze są jednak korpusy błędów poprawionych. I tutaj można wykorzystać gigantyczne zasoby Wikipedii. Pełne archiwa zmian w polskich stronach zajmują około 30 GB, przy czym polscy administratorzy wprowadzili pasek dla redaktorów, z którego łatwo wybrać opis czynności redakcyjnej – czyli np. „ort.” czy „lit.”. Pracuję obecnie nad zbudowaniem machiny do przeszukiwania tego archiwum, a ściślej rzecz biorąc – nad wydobyciem wszystkich zmian typu poprawienie literówki itd. Narzędzia do obróbki XML (archiwum meta-history Wikipedii jest w formacie XML) nie nadają się dla tak wielkich plików. Dlatego też używam prostego skryptu w AWK, szybkim i dobrym do tego celu narzędziu. Skrypt generuje pojedyncze pliki dla wszystkich poprawek danej strony. Następnie generuje skrypt bash, który określa, że pliki mają być porównywane standardowym narzędziem diff (ta część ni...