FINDSPOTはプロパティ検索機能という名称で、本文以外の要素についても検索するしくみを持っています。今回は、文書の本文テキスト以外の文書プロパティ情報を扱うために用意している文書フィルタのしくみについて説明します。

文書プロパティとカスタマイズ性

一般的に、文書本文を対象に検索を行うのが全文検索エンジンと見られがちです。ところが、文書には本文以外にさまざまな情報を持っており、このような付加的な情報の検索を全文検索と同時に行うことも、検索エンジンの重要な機能です。

このような付加的な情報は文書プロパティと呼ばれています。たとえばMicrosoft Wordは、文書のプロパティを保持する機能があり、次のような情報が記録できます。

タイトル

サブタイトル

作成者

管理者

会社名

分類

キーワード

コメント

作成日時

修正日時

この他にファイルシステム上のパス名、タイムスタンプ、アクセス権なども重要な情報であり、これらも文書プロパティと考えられます。

インターネットで公開されているHTMLの場合には次のような情報が文書プロパティとして考えられます。

URI

日付

タイトル

キーワード

メタ情報

もう少し具体的な文書についても考えてみましょう。社内標準のテンプレートを使って作成したMicrosoft Excelの見積もり書の場合には次のような情報が文書プロパティとして考えられます。

見積もり書番号

見積もり日付

お客様名

お客様ID

見積もり概要

見積もり合計金額

担当者名

以上のように、文書プロパティは文書フォーマットやテンプレート、使い方等によっていろいろと定義できることがわかります。つまり、文書プロパティは、実際にどのような情報がその文書を管理するために使われているか、どのような括りで文書を分類したいか、どのような角度から文書を検索したいかなど、使い手の要望に応じて、さまざまな要素から決定されると考えて良いでしょう。

検索エンジンが特定の文書プロパティに固定された作りになっていると、検索エンジンを利用する際に簡単にカスタマイズや機能面での限界が生じてしまいます。たとえば機密性を示すたった1つのフラグであっても、検索エンジンがこのフラグを元に絞り込みを行えるかどうかで、随分と使い勝手が違ってきます。実際に、このような固定的な作りになっている検索エンジンがかなりの数を占めています。

FINDSPOTはカスタマイズ性に設計の重点を置いているため、検索エンジンの利用シーンに応じて、どのような文書プロパティを利用するかについて利用者側で柔軟に定義したりカスタマイズできるようにしています。

文書フィルタ

では、どのようにしてFINDSPOTで柔軟に文書プロパティを扱えるようにしているかの解説に移りましょう。そのためには、FINDSPOTの文書フィルタという構造について説明する必要があります。

FINDSPOTのエンジン本体は、findspotdというプログラム（UNIX版ではデーモン、Windows版ではサービス）です。findspotdはインデックスを作成したり、検索する機能を持っています。インデックスを作成する場合には、インデックスをリクエストするクライアントプログラムとの協調作業となり、findspotdとインデックスクライアントとはTCP/IPのソケットで通信します。

インデックスクライアントは、全文検索対象のファイル名拡張子に対応する文書フィルタと呼ぶプログラムを呼び出し、各アプリケーション固有の文書情報をFINDSPOTの独自形式のXMLファイルに変換した後、このXMLファイルをfindspotdに送信します。findspotdは受け取ったXMLの情報を元にインデックスや書誌情報を記録します。

リポジトリ形式XMLと呼んでいるFINDSPOTの独自形式のXMLファイルは、文書の本文情報、書誌情報を入れるカプセルのような役割を果たします。このリポジトリ形式XMLファイルは自由度が高く、本文や書誌情報以外に、前述のような利用シーンに応じた文書プロパティを記述できるようにしています。独自の文書プロパティを追加したいならば、文書フィルタに少し手を加えて拡張するだけで良いのです。

文書プロパティのスキーマ情報

FINDSPOTで利用できる文書プロパティの型には次のような種類があります。

文書プロパティの型名はXML Schemaの記法を用いて指定します。また、データの保存形式については次の4種類を指定できます。

それぞれの文書プロパティにはユニークな名前が付けられます。これらのスキーマ情報をインデックスの定義ファイル（XML形式）に記述することで、独自の文書プロパティが定義できます。

FINDSPOTでは文書の書誌情報はSQLデータベースに保存しますが、保存形式の2, 3が指定された文書プロパティは、書誌情報と一緒にSQLのデータベースに情報を保存します。保存形式の1, 3が指定された文書プロパティ情報は、全文検索インデックスが作られます。このようにしてスキーマ情報が指定された文書プロパティは、次回解説する予定のプロパティ検索式を使って通常の全文検索と併用することで、より高い検索機能が実現できます。

文書フィルタによる検索エンジンのカスタマイズ性

文書フィルタ機能を、文書フォーマットごとの独立したプログラムとしたことで、カスタマイズ性や新たな文書形式をサポートするといった拡張性はぐっとアップしました。

たとえば、独自の実験データのデータファイル形式を、検索エンジンでサポートすることを考えてみましょう。実験データにはデータ以外に次のような情報が記録されており、これらを全文検索したいとします。

種類（4桁の数値）

実験の概要

実験日付時刻

実験担当者名

コメント

FINDSPOTならば、独自の実験データのデータファイル形式を読み込み、リポジトリ形式XMLファイルを生成するフィルタプログラムを作成し、実験日付、実験の概要、種類、コメントに関するスキーマ定義を行うだけで、独自の実験データのデータファイル形式を検索できるようになるのです。

文書フィルタの外部配置

文書フィルタを検索エンジンの内部ではなくできるだけ外部に配置するという設計は、カスタマイズ性を向上させる以外にもうひとつ、全文検索エンジンの安定性の向上という重要なねらいがあります。

文書ファイルから全文検索対象となるテキストデータを抽出するのは、さまざまな検索エンジンがそれぞれ実装している機能です。ところが、何十万ファイルという文書を扱うと、中には必ずといって良いほど壊れた文書ファイルや拡張子が間違って付けられたファイルなどが存在します。このようなファイルからテキストデータを抽出しようとして、検索エンジンのプログラムがUAE（Unrecoverable Application Error）を発生したり、ハングアップしていつまでもインデックスの作成が終わらないことがとても多いのです。この点は、FINDSPOTの開発を始める前にさまざまな検索エンジンを利用して感じた不満のひとつでした。

文書フィルタを検索エンジンの内部に持つ作りになっていると、テキストデータの抽出時のUAEやハングアップの影響をエンジンが直接受けてしまいます。FINDSPOTではこのような影響を最小限に留めるために、文書フィルタを検索エンジンから離れた外部プロセスとして実現する工夫をしています。文書フィルタが外部プロセスになっていれば、文書フィルタでたとえUAEが発生しても、エラーとして扱い、インデックスの作成を継続することができます。