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