~fumi/ChangeLog

http://pictseek.com/

類似画像検索サイト

http://www.marsflag.com/

検索結果のサイトをサムネイル付きで表示．

http://qooqle.jp/

Google Suggest で入力補完を行いつつ、Yahoo! での検索を行います。
検索結果は、はてなブックマークの登録数に応じてタグクラウドっぽく表示されます。
同時に商品カテゴリを Yahoo! の検索結果から自動的に判別して Amazon 検索も行います。

http://qooqle.jp

YahooAPI とはてな API を利用した検索

- http://solvalou.net/mt/archives/2006/01/qooqle.php

http://zen.seesaa.net/article/11956486.html

http://hotwired.goo.ne.jp/news/culture/story/20060120202.html

http://wiki.lumrix.net/ja/

Wikipedia のインクリメンタルサーチ

http://labs.systemone.at/retrievr/

via: i d e a * i d e a - 落書き検索（retrievr）

http://www.doko.jp/

リクルートによる全国のお店・サービス検索エンジン．

- リクルートの地域検索はGoogleを超えるか？::したらば元社長日記

自分がブックマークした URL だけを対象に検索したり，
特定の tag でブックマークされた URL だけを対象に検索できると
便利そうなんだけど．

http://del.icio.us/ を買収した Yahoo がやってくれないかなぁ．
もちろん google でもいいけど．

[2005-12-19-1] でメモした，
なぜネットではディレクトリが敗れ、サーチとタグが勝利するのか について，
404 Blog Not Found:名称未設定.entry と
サーチとタグは勝利するか を読んでスッキリした．

問題というか，スッキリしなかった理由は次の 2 点．
- mojix さんのいうファイルはデータとしてのファイル
  - 小飼さんのいう「ファイルが持つ役割を表す」名前をもつファイルが
    関係しそうなのは「無名ファイルシステム」と「個人の PC 環境」くらい．
- 「ディレクトリ」という言葉
  - Yahoo のカテゴリ階層としてのディレクトリ
  - ファイルシステムにおけるディレクトリ

http://www.jmuk.org/d/?path=2005/12/18#d18t02

[2005-12-19-1] でメモした，
なぜネットではディレクトリが敗れ、サーチとタグが勝利するのかと，
[2005-12-19-2] の分類→キーワード→分類関連．

http://nais.to/~yto/clog/2005-12-18-2.html

[2005-12-19-1] の関連．

まずタグの標準化について。
ソーシャルブックマークなどで共通に使うタグは標準の表記や用語が決まっ
ていた方が便利です。例えば、「ソーシャルネット」「ソーシャルネット
サービス」「ソーシャルネットワーキング」「SNS」、あなたはタグとし
てどれを使っていますか？ これが各自バラバラなら（一人で使うには良
いですが）、ソーシャルブックマークとしての面白さは激減です。

情報収集という観点からは用語のばらつきは利便性を損なうのはたしか．
タグの構造化の一環として， alias で用語のゆれを吸収するという手も．

http://mojix.org/2005/12/18/102729

思ったことを適当に
- ディレクトリの分類の利用時のコストは，分類者と利用者が考える
  階層構造が一致しないために発生するもの．
- サーチとタグは目的の単語で充分だが，
  ディレクトリでは目的の単語から上位カテゴリを考える必要がある
- 階層構造が把握できていれば有用
- ディレクトリ -> サーチ -> タグ の流れは
  他者 -> 機械 -> 利用者自身 という流れ
- タグのメリット
  > 2） 対象内に出現しない単語（サーチでは拾いようがない）を対象に結びつけられる
  これ重要

http://kotonoha.main.jp/2005/12/09gooleseo.html

http://slashdot.jp/article.pl?sid=05/11/01/0219228

namazu と同じオプションを持つ rast-search を書けば，
namazu.el がそのまま使えて便利なんじゃないかと思ってみたり．
（もちろん，出力も namazu 風にして）

昨日[2005-10-23-5]のつづき．

namazu では以下のような出力から namazu-max-page を得ている．

現在のリスト: 21 - 40
ペイジ: [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16]

rast-search ではこのような出力を得られないので，rast-max-page を得られず，
rast-next-page などが機能しない．
rast-search では

search result of "hoge"
1 hits

と件数がでるのでこれから rast-max-page を計算するようにしてみた．

rast-next-page とかは効くようになったけど，
検索結果に番号をふっていないし，何ページ目かの表示もないのでいまいち．

rast.el を書いてみた [2005-10-23-5] ので，ついでに
namazu-howm-grep をもとに rast-howm-grep を書いてみた
（howm の隠し機能で rast を使えるけど，検索だけ出来ればいいので）．

rast-search には namazu の "-all" のようにファイル名を返すオプションが
ないので，rast-command は howm の ext/howm-rast-search.rb を使う．

[ Read More... ]

namazu.el を書き換えて，とりあえず検索はできるようにしてみた．

やったことは．
- s/namazu/rast/
- rast-command を rast-search に
- rast-cs-read, rast-cs-write を 'utf-8 に
- namazu の option を rast の対応するものに変更
- rast-output-url-pattern の変更
くらい．

howm のメモを howm-rast-register で登録したものでしか試していないので，
他のパターンも試してみること．
elisp もよくわかっていないので，これ以上手を入れるのは難しそう．

たいして書き換えていないので，

(setq namazu-command "rast-search")

などとして namazu.el をそのまま使えないかと思ったけど，

(setq arg-list (append
                arg-list
                (list "-n" (int-to-string rast-search-num)
                      "-w" (int-to-string (* page-num rast-search-num))
                      key)))

とオプションが埋め込まれている部分があるので無理そう．

- Rast: 全文検索システム