Re: SimMetrics: string benz

On Aug 21 11:55, Ahmet A. Akin wrote:
> Bu konuda yani kok bulucunun teknik yapisikonusunda bir kac sey
> soylemek istiyorum. onceden kok bulma isleminin basitce
> gerceklestirilebilecegini sanmistim, ama aslinda konu biraz daha
> karmasik. Zemberek icerisinde uc farkli kok bulma mekanizmasi yer
> aliyor. standartkok bulucu, ascii toleransli kok bulucu ve hata
> toleransli kok bulucu. Bu mekanizmalari kullanmak icin zemberek
> icerisindeki morfolojik cozumleyici vs'ye normalde gerek yok diye
> dusunuyordum, oturup hizla TuyrkishStemmer yazmaya kalkisinca kazin
> ayaginin oyle olmadigini anladim.

Daha öncede belirttiğim gibi ilgili JAR dosyasından TurkishStemmer
sınıfı kullanılabildiği sürece bu işi yapabileceğimi düşünüyorum. Ama
hazır kazın ayağı da böyle değilken, iş için epey bir ek masraf çıkıyor
gibi görünüyorsa Snowball[1] kütüphanesinin kullanımı hakkında fikrinizi
alabilir miyim? Yani şu an Zemberek'e bu özelliği eklemek ile, bu işi
Snowball'a port edip kalanını orada tamamlamak arasında ne derece fark
olur?

[1] http://www.snowball.tartarus.org/

> Nedeni ise su: su andaki kok bulucu kelimenin tam yapisini goz onune
> almadan sadece baslangicina bakarak olasi tum kok adaylarini buluyor.
> Ornegin "kayalar" kelimesi icin kok bulucu size "kay(mak), kaya ve
> ozel isim Kaya" koklerini aday olarak getirecektir. Oysa buradaki
> gercek kok sadece "kaya" dir. bunun ortaya cikmasi icin ise tum
> kelimenin cozulmesi gerekir. bu islem, yani olasi cozumler zemberek
> icerisinde zatenyapilan bir sey oldugundan bunu yapmak kolay ama kok
> performansi saniyede yuz bin seviyesinden 20-30 binlere hatta daha
> asagilara inecektir.
> Buradaki baska bir sorun ise sozluk icerisinde yer almayan ozel
> adlarin cozumlenemez olarak isaretlenmesi "Bill'in" kelimesinin koku
> bulunamayacaktir. Bu durumda cok onemli olan ozel isim arama islemi
> Turkce kok bulucu icin yeterince iyi calismayacaktir. buradaki
> yapilabilecekbir sey turkce kok bulucunun cozum bulmadigi durumlarda
> ingilizce kok bulucunun devreye girmesi olabilir. Baska bir alternatif
> bu tip ozel durumlara ozel mudahale etmek olabilir, bu ne yazik ki
> calisma gerektirecek bir is. (onemli bir konu aslinda, baska konularda
> da bu islem gerekebilir). Eger elimizde geri dogru cozumleme
> algoritmasi olsa sanirim bu konuda daha iyi bir basarim ortaya
> cikabilirdi ama isin astari yuzunden pahaliya gelir derim.
> Sonucta postgre icerisinden herhangi bir jar dosyasina erisim kolay
> ise zemberek kutuphanesinin kullanimi da kolay olacaktir. burada
> dikkat edilmesi gereken tek nokta zemberek kutuphanesinin sadece bir
> kere isletilmesi. cunku kutuphanin ilklendirilmesi cok pahali bir
> islem olup 600ms-1sn civarinda bir gecikmeye neden olacaktir. JVM ilk
> acilis suresi de cabasi.Bir kere ilklendirildikten sonra elbette
> oldukca iyi bir perforemnas verecegini soyleyebilirim. eger sadece ilk
> bulunan kokun yeterli oldugu bir durum olur ise (bazi durumlarda iki
> ya da daha fazla dogru kok cozumu olabilir elmasI -> elma-si, elmas-i
> gibi ) saniyede 30-40 bin kelime icin kok bulunabilecegini
> soyleyebilirim.
> Bu konuda sizin ihtiyaclariniza gore kutuphanede gerekli
> degisiklikleri yapabilirim, ya da sirf stemmericin ozel bir erisim
> sinifi saglayabilirim saniyorum. Tabi bu arada bir an once zemberek 2
> icerisindeki degisiklikleri de tamamlamak istiyoruz..

Bu konuyu biraz dağıtabilir ama, çok ufak bir açıklama benim için
yeterli olur: Zemberek2'yi de java ile yazıyorsunuz değil mi? Java'yı en
baştan beri tercih etmenizdeki sebep nedir?

İyi çalışmalar.