Re: SimMetrics: string benz

On Aug 21 04:03, Ahmet A. Akin wrote:
> SleepyCat ya da db4o gibi sistemlerin klasik RDBMS'in yerini
> alamamalarinin temel nedeni ise sanirim ki gecmisten gelen
> bagimliliklar, arac eksiklikleri, ortak sorgu mekanizmasinin olmamasi
> ya da sorgularin yeterince guclu olmamasi gibi sayilabilir. bu konuya
> hic girmesem daha iyi, icinden cikamam :)

Bence de öyle yapalım. Çünkü bu yolla veritabanlarının yıllardır çalışıp
sırf bu standartları (ACID[1] olsun, MVCC[2] mimarisi olsun)
gerçekleştirmek için hele hele yıllardır uğraştığını düşünecek
olursak... Yani durum o kadar farklı ki şöyle özetleyeyim: MySQL
bildiğim kadarı ile bir kaç depolama mekanizması sunuyor ve ön tanımlı
olarak gelen MyISAM SleepyCat'in DB'sini kullanıyor. Sizin anlayacağınız
deve-tırnak ilişkisi.

[1] http://en.wikipedia.org/wiki/ACID
[2] http://en.wikipedia.org/wiki/MVCC

> bu konuda fazla kavga gurultu etmeden asil probleme doneyim,
> Turkce bir stemmer yapmak zor degil, ancak burada sizin bilginize
> danisayim, sizin bu kok bulucu mekanizmadan tam olarak beklediginiz
> nedir? "kitaba" kelimesinde "kitap" kokunun varliginin sezilmesi ve
> aramanin bunu getirmesi mi mesela?

Kesinlikle tam olarak bu.

> Bizdeki kok bulucuyu mehmet yazmisti, onun da bu konudaki gorusunu
> duymayi isterim.

[Keşke onun e-posta'sını da birileri bu iletilerin CC alanına eklese.]

> Evet ama google gibi davranip bu isi arama motru ile yapmayi tercih
> ederdim. Elimi herhangi bir veri tabanina baglamadan.

Burada kimse arama motorunun veritabanında yer almasından memnun değil
zaten. Sırf bu yüzden var olan tekerleği yüz bin takla atarak bir
veritabanı için keşfetmeye çalışıyorsunuz. Ama elbette bunun getirisi
götürüsünden epey fazla ki insanlar bu yüzbin taklayı öyle ya da böyle
atıyor.

> ... hatali giris durumunda ...

Bence bu 3 kelime Türkçe hata metriklerinin ne kadar çok kullanım
alanına sahip olabileceğini özetliyor.

> bir ek, bildigim kadari ile kok bulucu indexlerin olusturulmasi
> sirasinda kullaniliyor. Postgre icerisindeki bu kok bulucu moduler bir
> yapiya mi sahip? yani bir sekilde bir java kutuphanesini cagirmak ya
> da kullanmak mumkun oluyor mu ?

Açıkcası tsearch2 snowball[3] stemmer kütüphanesini kullanıyor. Benim
aklımda da böyle bir projeye kalkışmadan önce keşke Zemberek'i snowball
kütüphanesi ile geliştirebilsek fikri vardı. Bu konu hakkında ne
düşünüyorsunuz? Biliyorum Zemberek JAR dosyasının içinde
TurkishStemmer() metodunu export etmek sizin için muhtemelen şuan en
kolay yol olacaktır. Ama oyunu kitabına göre oynamak adına snowball
kütüphanesinin kullanılması hakkında ne düşünüyorsunuz?

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

Sorunuza yanıt verecek olursam, tsearch2 lexeme'lerine ve bu lexeme'leri
de stem'lerine ayırdıktan sonra bunu özel bir veri tipi şekilde tutuyor,
tsvector adında. tsvector alanlarında stem'ler dökümanın hangi
noktalarında ne sıklıkla yer aldıkları meta bilgileri ile saklanıyorlar.
Şöyle basit bir örnek vereyim:

SELECT CAST('Our first string used today' AS tsvector);
tsvector
---------------------------------------
'Our' 'used' 'first' 'today' 'string'
(1 row)

SELECT to_tsvector('default',
'Our first string used today first string');
to_tsvector
--------------------------------------------
'use':4 'first':2,6 'today':5 'string':3,7
(1 row)

Stem'lerin konumlarının saklanması, sıralamanın önemli olduğu
aramalarda; ne sıklıkla kullanıldıkları ise bulunan gelimenin tümce
içinde geçme frekansının belirlenmesinde kullanılıyor.

Sorun şu ki, tsearch2 snowball kütüphanelerini kullandığından, ayrıca
bir stemmer prosedürünün, onun tarafından kullanılabilir hale
getirilmesi ikinci bir masraf çıkarabilir. (Şu an bunun boyutunu
bilmiyorum.) Ama sonuç itibari ile bu da olur. Sadece merak ettiğim eğer
yapabiliyorsak, Snowball kütüphanelerini kullanabilir miyiz?

İyi çalışmalar.