昨日のエントリの，俺にとっては続きです．
情報知識学会というところで今月末に1件，共著の発表をします．今年は香川大学での実施です．ただし，しゃべるのは私自身ではなく，指導している学生です．卒論の成果にプラスアルファして予稿を仕上げ，発表してもらうのは，2年連続となります．
査読無しの予稿とはいえ，最初の節に何を書けばいいか，難渋しました．あ，先月末のことです．初稿は，学生の卒論の第1章でしたが，インパクトに欠けるように思えたので，自分の認識を追加することにしました．こうすること自体は，共著なので問題ありませんし，今回のも過去のも，学生が筆頭筆者で私が段落または節を書き加えたのがどこかというのは，読めば容易に思い出せます．
具体的に何を書いたかですが，そのまま引用するのは未公開情報ということで良くありませんので，前々から持っていた「思い」を綴る形で，書いてみます．
「全文検索」と言えば，“ぐぐる”でおなじみ，Googleですかね．Yahoo!もgooも健在ですし，最近ではBingや百度(Baidu)なんてのも出てきました．
それらは，インターネット上のあまねくコンテンツに対する情報検索サービスです．そして，ボットあるいはクローラと呼ばれるものが情報収集をして，構造化されています．我々としては，この雑記もそうですが，Web上で公開していれば，そのうち検索されるようになります．SEO（検索エンジン最適化）なんて言葉もあります．
そういったのと別に，会社や団体といった組織が，独自に全文検索サービスを提供していることもあります．サーバやコンテンツの維持，またときにはコンテンツや検索方法などの追加は，その組織がコストを払ってやっています．
そのようにする理由を考えてみますと，そのコンテンツは必ずしも公（おおやけ）にできない，というのがまず挙げられます．社内情報や，個人のローカルファイル，また「元ネタ」をプライベートに電子化したため，著作権の問題が解決されていないもの，なんてのもあるかもしれません．それでも，そんな情報（ファイル）が多数あるとき，プライベートな全文検索サービスを作っておけば，知っているキーワードから瞬時にファイルが取得できるってわけです．
また別の理由も思い浮かびます．自前で検索サービスを作り，組織の内外へ提供していると，アクセスログなどの分析を通じて，「具体的にどんなキーワードで検索されているのか」「どんな検索のニーズがあるのか」を知ることも，可能となります．それによって，そのコンテンツの価値や強みを知ることにつながります．逆に言うと，そういう努力をしない検索サービスは，「うちはこんなコンテンツがありますから，どんどん（検索して）アクセスしてね」と出すだけで発展性のない，殿様商売のようなもので，先行き不安なものです．
ちなみに私の研究室ではこれまで，聖教（しょうぎょう）と呼ばれる数百年前の史料の書誌情報を対象として，まずは単純に全文検索できるものを作りました．で，結果の中に，人物名だとか地名だとかが見えるのですが，そういった情報がどこにあるかを知るために，作った全文検索を使って発見しました．別のところから持ってきた人物名リストを，片っ端から，この全文検索サービスにかけるのです．Webのフォームじゃなくて，いわばダイレクトな接続で，毎秒1万アクセス以上というスピードで，やりました．そうして，この名前は全然出てこないから捨てる，この名前は結構出てくるなあなんてことで，選別をしました．最終的に，人物名・地名・寺院名・年代については，検索結果で内部リンクを張り，って何かというと，クリックしたら，そのキーワードで検索できるってことで，いちいちフォームに打ち込まなくっていいんですね，人が使う検索にも役立つようにしたわけです．
「プライベートな全文検索」については，1台のノートPCにサーバとクライアントを詰め込み，持ち運べて，瞬時に漏れなく検索できるシステムを作りました，ってのは1年前のおんなじところの学会発表です．念のため書いておきますと，Googleデスクトップは「漏れなく」がダメです．grepコマンドだと「瞬時に」が難しいのです．
さてここで，開発者さんを想定します．この人が今，手っ取り早く独自の全文検索サービスを作るには，何をすればいいんでしょうか? 外の計算機からのアクセスも，できるようにします．
手っ取り早いというと，Webサーバと全文検索エンジンをインストールして，Webアプリケーションにすること，でしょうか．もちろんインストールだけではダメで，コンテンツすなわち文書群を登録することが，前処理として欠かせません．この前処理のことを「インデックス化」とも言います．あと，「全文検索エンジン」は，計算機の中で全文検索をする中核を担うソフトウェアのことで，「全文検索サービス」は，人間相手に，まあ実際のところは計算機間のやりとりで，全文検索をできるようにしたシステムで，全文検索エンジンを内部に持つ，というふうにとらえてください．
そうしたとき，全文検索エンジンは，「全文検索でない検索」，言ってみれば古くから行われているデータベース検索サービスにおける，データベース管理システム(DBMS)に相当します．DBMSでの検索は，数値や，文字列に関しては完全一致検索であれば非常に有効なのですが，「この言葉が含まれている文書」を知る，部分一致検索は，効率的ではありません．ここに，全文検索エンジンの強みがあります．
もう一つ，違いがあります．DBMSの場合，その検索性能は，もちろん採用するDBMSにも依存しますが，むしろ，データベースの「設計」によるところが大きいのです．「スキーマ設計」とも呼ばれます．全文検索エンジンは，スキーマ設計をすることなく，ファイルをぼんぼん放り込めば，すぐに検索できるようになるわけですが，言い換えると，採用する全文検索エンジンが，検索性能に大きく影響することを意味します．
さて，さきほどの開発者さんです．データベースの設計構築は得意なのですが，急きょ，全文検索サービスを構築し，提供することになりました．そういう人が，たまたま目にした全文検索エンジンに惚れ込み，作ったアプリケーションは，全文検索エンジンの機能を生かし切れていなかったり，メモリを食いつぶしたりしている，なんてことになるかもしれません．
全文検索サービスの実現にあたり，開発者さんの観点で，ほしいものを並べてみましょう．検索時間が短いこと，漏れのない検索ができること，前処理の時間が短いこと，インデックスサイズが小さいこと，特別な検索ができること，あたりでしょうか*1．そのすべてを満たす，言ってみれば開発者さんのニーズに合った全文検索エンジンというのは，それぞれの全文検索エンジンのWebサイトを見たり，ソフトウェアをダウンロードしてREADMEファイルを読んだりしたくらいでは，必ずしも知ることができないんじゃないかと思ったわけです．
そんな問題意識のもと，何をしたのかというと…それは学生の発表にご期待ください．
