Namazu-devel-ja(旧)


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NMZ.iのデータ長について



寺西です。

"Komai @home" wrote:
> 
> 2.1系は、もしかしたら大幅にNamazuが生まれかわるかもしれない、という
> 期待もこめて、似て非なるフォーマットでない方がいいという考えにも賛同して
> アイディアとして、以下のようなことを投稿しておきます。

いろいろアイディアを出し合って、議論できるのが ML の良いところです
から、バンバン出してください。

> (すみませんアイディアだおれかも。。)

そう思わずにいろいろアイディアを出していただけると、いろんな人の
刺激になったり、別のアイディアを生んだりできるので良いと思いますよ。

> [観点]
> スコアの計算方法をユーザーが新規に考えたのを取り込みやすくして
> より面白いものがでたら対応しやすくする。
...
> 2)スコア値と文書IDが現在同じファイル(NMZ.i)に書かれているが、
> スコア値を別ファイルにする。
> 3)mknmz側も、すっきりと、スコアの計算方法をユーザーが適当に
> 新規に考えたのを取り込みやすくする。

2,3 に関しては、そのままではスコアの計算方法をユーザーが新規に
考えたのを取り込みやすくなるのかどうかが不明です。
mknmz でユーザが定義したスコアの計算方法でインデックスを作成
するだけならファイルが分かれてなくても良いわけですから。

ここでファイルを分けたことで、どのようなメリットが出てくるのかが
分かればいいですね。この辺りはいろいろ考えておられるのではないか
と思いますので、そこをお話いただければと思います。

たとえば、複数種類のスコアを計算して、検索時にスコアを切替えできる
ようにしたいとか。

また、インデックスファイルのフォーマットは別にしても、スコアの
計算方法をユーザーが定義するようにするのは難しいわけですが、
それはともかく、どういったスコア計算を考えられているのでしょうか?

# スコア計算部分をプラグイン化するとかだといいのかな。

> イメージ
> NMZ.i
> 単語xを含む文書の総数:文書ID、文書ID 、、(差分)
> 
> NMZ.score
> 単語xを含む文書の総数:スコア、スコア、、、(差分無し)

NMZ.score のオフセットファイル NMZ.score.i が必要になりますので、
インデックスは多少大きくなります。
それだけのメリットがあるかどうかが鍵ですね。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E