namazu-ml(ring)

[Rei FURUKAWA <furukawa@xxxxxxxxxxxx>]

古川です。

From: Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>
Date: Tue, 04 May 1999 22:11:51 +0900
satoru-t> 現在、考えている案は次の通りです。足りない点があれば提案して

satoru-t>   * 文書読み込み部の抽象化 (APIを定義し、拡張性を高める)
satoru-t>     - 新しい文書形式への対応を容易にする
satoru-t>       e.g. Word文書, PDF, http://, ftp://, news://

ちょっと前に話題になった、pdf2txt ですが、完成度がかなり上がり、試した
かぎりでは、実用的に、ほとんど問題ない出力が得られるようになっています。
みなさまお試しを。

    ftp://paprika.noc.intec.co.jp/pub/person/ishida/freeware/pdf2txt/


satoru-t>   * NMZ.f のフォーマットを変更し、 NMZ.field.* と統合する
satoru-t>     - 現在のフォーマットは柔軟性ゼロな上にサイズ効率が悪い

ローカルファイルについては、要約を、検索側でつくる「こともできる」よう
になっているといいな、と思います。小さいファイルがたくさんあるような状
況では、NMZ.f が、ファイルを二重に持っているのに近いサイズになってしま
うためです。
    速度を重視したい人 -> NMZ.f 内に要約
    サイズを重視したい人 -> 検索時に要約作成
てな感じで。もちろん、mknmz で行なっているような、複雑な処理は要らない
と思います。


satoru-t>     - 中間・後方一致、正規表現、フィールド指定での検索を抑制 

個人的に、いちばん実装して欲しいのは、「部分一致と、わかち書きの両立」
なんですが、

satoru-t> 先日、とある方と suffix array の考え方を応用できないものかと
satoru-t> 話し合いました。うまくいけば、わかち書きに依存しない形の全文
satoru-t> 検索システムが作れるかもしれません。当分、先の話ですが。

これがうまくいけば、関係なくなりそうです。


From: Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>
Date: Wed, 05 May 1999 10:47:11 +0900

satoru-t> masao@xxxxxxxxxx (Masao Takaku) wrote:
satoru-t> >  * 日付をキーにしたless than, greater thanの指定検索。
satoru-t> >	( 1999年1月以降の記事 OR 1998年1月以前の記事 AND "TERM" )
satoru-t> >	といった検索をしたい。
satoru-t> 
satoru-t> この場合、どのような形式で日付を指定するかが問題になると思う
satoru-t> んだけど、ISO 8601に従えば間違いないですね。 1999-05-05 のよ
satoru-t> うに。

実は、pnamazu では、もう実装していて、現在デバッグ & cache 対応中なの
です。仕様が決まったら、それに合わせようかと思うので、教えてください。

ちなみに、こちらでは、YYYY.MM.DD というのを考えていました。というのは、
「日付指定には、ぜひ '+' '-' による相対指定をしたい」と思っていて、そう
すると、日付の区切りに '-' を使うと混乱するからです。

今のところ、pnamazu では、
    +[1999.1.1,1999.1.15]   1999年1月1日〜1999年1月15日
    +[1999.4,]              1999年4月以降
    +[,1999.4]              1999年4月以前
    +[.2.1]                 直近の2月1日 (年は省略可)
    +[-5,+.6]               今日の5年前から6ヶ月間
といった指定ができるようになる予定です。
    
namazu.cgi の機能としては、「日付の相対指定」を希望しておきます。


それと、
* ON_MEMORY_MAX, FILE_SIZE_LIMIT の自動設定
ができると、よいです。

% limit
cputime         unlimited
filesize        unlimited
datasize        22528 kbytes
stacksize       8192 kbytes
coredumpsize    unlimited
memoryuse       30720 kbytes
descriptors     64 
memorylocked    10240 kbytes
maxproc         64 

などといった状況から、適切な値を推定してもらえると、ありがたいのですが…

-- 
Rei FURUKAWA 
furukawa@xxxxxxxxxxxx