2つのデスクトップ検索ツールBeagleとTrackerの比較：パート2
まずはBeagleとTrackerとを使って2つの同じ言葉を検索してみた。はじめに「ethernet」という言葉を検索したところ、結果がまったく異なっていたので驚いた。まぎれもなく単なる一語を検索しただけなのだが、Trackerでは、最も適切だと思われる項目が検索結果のトップに表示された。一方Beagleでは「networking HOWTO」が（「Networking」という名前で）5番目に表示され、またHOWTOの目次文書の方が個々のHOWTO文書そのものよりも高くランク付けされていた。「ethernet」という検索語に対する結果としては、Trackerがトップの結果として表示した「Ethernet HOWTO」の方がずっと適切だろう。
なお、Beagleの検索インターフェースではマッチした結果が最大100件分しか表示されないが、Trackerではマッチした結果の合計数が表示されて、複数ページに分割して表示される検索結果ページを次々に閲覧していくことで、最後の検索結果まですべて確認できるようになっている。
「ethernet」の検索結果はたまたまBeagleでの特別な例に当たったのかもしれないと思ったので、次に「voip」を検索してみた。するとやはりTrackerでは「VOIP HOWTO」のPDFファイルがトップの項目として表示された。一方Beagleでは、siproxdのリリースノートとREADME文書に続いて、「networking HOWTO」、「modem HOWTO」の一部分、「Webcam HOWTO」の中の2つのファイルが表示された。Beagleでは「VOIP HOWTO」は、HTMLファイルもPDFファイルも結果の2ページ目に表示された。
TrackerではAND/OR/NOTなどの論理演算子を使用することはできないが、入力された検索語を使ってランク付けが行なわれている。一方Beagleでは検索語の中でORキーワードを使って選択可能な言葉を指定することができる。また「Linux -troll」のようにマイナス記号を言葉の前に付ければその言葉を含む検索結果を除外することができる。
検索用インターフェース
「tracker-search-tool」を実行すれば、 以下に示すスクリーンショットのようなTrackerのグラフィカルな検索用インターフェースが表示される。このウィンドウには複雑なクエリを読み込んだり保存したりするための方法は表示されないが、検索結果のファイルを右クリックすれば、検索結果のファイルを開いたり、検索結果のファイルが含まれているフォルダを開いたり、検索結果のファイルをごみ箱に移動したり、表示中の検索結果のリストを保存したりすることができる。なお検索結果のリストを保存すると、検索結果の各ファイルのパスが一行に一つずつ書かれたテキストファイルが作成される。その際、保存したい検索結果の件数を指定できれば良いのだが、それはできなくて、GUI上に表示されている10件のみが保存される。GUIを使用して検索すると10件しか指定できないので、検索結果のすべてに対して何らかの操作を行いたい場合（例えばマッチした検索結果すべてを別のマシン上に移動するなど）にはコマンドラインで「tracker-search」コマンドを実行して検索する必要がある。なおBeagleにもbeagle-queryという同様のコマンドライン用のツールがある。
Trackerではウィンドウ左側に並べられている各カテゴリーをクリックすると、検索結果のうち、そのカテゴリーに属する項目だけが表示される。なお各カテゴリーは、そのカテゴリーに該当する検索結果が一件以上存在する場合にのみ表示される。ただし選択したカテゴリーに属している検索結果のみのリストを保存することはできない。Trackerではタグを使いやすくすることが重視されているとのことなので、グラフィカル検索ツールでは、手動でのクエリ文字列の指定以外にもタグを使った検索がある程度サポートされていることを期待していたのだが、サポートされていなかった。例えば一度検索した後に、検索結果のファイルが持つ各タグに基づいた絞り込み機能のようなものがあれば便利かもしれない。カテゴリーはタグよりも一般に多くのファイルに一致するため、タグで指定した方が検索結果を絞り込む作業がより効率的になるだろう。
Trackerの検索インターフェースはシンプルだがクエリを入力して検索する場合には能率的だ。ただし難点として、例えばタグをクリックしてクエリに追加していくことができないので能率的に使いこなすためにはクエリの構文を熟知しておく必要がある。
検索結果を閲覧する際、表示中の検索結果についてのメタデータが表示されているのは便利だ。例えば表示中の10件の結果の中に2つのPDFファイルがある場合、各PDFファイルのページ数も表示されるので、短い概要ではなく本文が含まれている方のファイルを間違えずに開くことができる。このようなメタデータなどに基づいて検索結果を並べ替えることができれば、さらに良いかもしれない。例えば検索結果に対して、ファイルの大きさや変更日時やページ数などに基づいてソートができれば便利だと思う。
検索結果の中にタグが統合されていることはTrackerの大きな長所だ。ただ残念ながら検索結果の各ファイルに対するタグを追加/削除すること以外には、Trackerを使い始めたばかりのユーザが検索の際にタグを活用できる機能はない。確かに、付けておいたタグを右クリックしてコンテキストメニューからSearch for Tag（タグを検索）を選択することは可能だが、この機能ではそのタグが付けられているファイルのみを対象に検索が行なわれるわけではない。つまり例として「foo」というタグをファイルに追加してそのタグを検索してみたところ、結果としては「foo」というタグを持つファイルだけが表示されるのではなく、「foo」という文字列が含まれるソースコードのファイルなども数多く表示された。
以下にbeagle-searchのグラフィカルインターフェースを示した。左側のカテゴリーリストの部分がないため、一見するとTrackerのインターフェースよりもシンプルな印象だ。検索結果に対してフィルタをかけるには、Search（検索）メニューのサブメニューのShow Categories（カテゴリーの表示）を使用すれば、指定したカテゴリーに該当する結果だけを表示することができる。その際Trackerでは一度に一カテゴリーしか選択できないのに対してBeagleでは同時に複数のカテゴリーを選択することができる。Search（検索）メニューからは、ネットワーク上の別のマシンで稼働しているBeagleに対して検索を行うこともできる。またView（表示）メニューでは、変更日時、ファイル名、関連度に基づいて検索結果をソートできるほか、ウィンドウ下部のファイルの詳細情報の枠を非表示にすることもできる。
検索結果を右クリックするとコンテキストメニューが表示されて、デフォルトのアプリケーションかリストから選択したアプリケーションを使って、検索結果のファイルを開くことができる。なおReveal in Folder（フォルダ内で開示）という機能は、単にその検索結果のファイルが含まれるフォルダを開くということの回りくどい表現のようだ。その他にもコンテキストメニューには、検索結果のファイルを誰かにメールで送るという機能や、検索結果のファイルをゴミ箱に移動するという機能がある。
検索結果をソートできるという機能は便利なのだが、ソートの基準となるメタデータのフィールドが、変更日時、ファイル名、関連度に恣意的に限定されてしまっている。また検索ツールにおいてカテゴリーを一度に複数選択可能である点も便利なのだが、そのためのインターフェースはユーザが表示/非表示を選択可能なサイドパネル内にあった方が、例えばNone（なし）、Images（画像）、Media（メディア）というように次々と選択していく必要なく複数のカテゴリーを選ぶことができるので良いと思った。現状では2つのカテゴリーを選択するためにメニューを3回も使用する必要があるため、この方法ではすぐに面倒になって使わなくなってしまうだろう。
クエリ構文とセマンティクス
現在、ユーザがクエリを直接入力するのに向いた簡潔な検索用構文を含む、デスクトップ検索を記述するためのXesam標準を作成/使用する取り組みがコミュニティによって行われている。9月下旬に開催される第一回Desktop Search Hackfestでは、Xesamの開発者とデスクトップ検索開発者とのミーティングが行われる予定なので、うまく行けばXesam標準が広く採用されることになるだろう。Beagleではbeagle-xesamプロジェクトを通してXesamをサポートしている。またTrackerプロジェクトもXesam標準を採用する方向で進んでいる。なおBeagleのネイティブのクエリ構文については優れた文書が用意されている。TrackerはRDFクエリ言語として、より簡潔なSPARQLではなくRDF Query Specificationをサポートしていて、Trackerの配布用tarファイルのrdf-query-examplesサブディレクトリの中にTrackerでRDFクエリ言語を使った簡単な例がいくつか含まれている。なおTrackerのグラフィカル検索ツールが受け付けるクエリ構文についての情報は見つけることができなかった。
まとめ
Beagleのネイティブのクエリ構文には荒削りな部分もいくつかあって、例えば人間にとって読みやすい日付けの書き方から各値を解析しようとするのではなく、人に優しくない形式で入力する必要がある。とは言え「artist:Beatles」のような属性クエリ構文は簡単で覚えやすい。ただし属性クエリ構文は完全一致の検索の場合にのみ有効で、数値のメタデータに対する検索の場合にはあまり役に立たない。
一方TrackerはSPARQL言語ではなくより古いRDFクエリ言語を使用していて、そのことがTrackerの使用を見送る原因になることもあるかもしれない。Trackerの最大の難点は、現在使用しているクエリ構文とセマンティクスについての情報がないことだ。複数の言葉や「*.pdf」のような文字列を入力すること自体に特に問題があるわけではないものの、わざわざRDFクエリ言語を使って書くほど複雑な表現ではないがより詳しいクエリを作成したい場合には、参考になる文書があれば便利だろう。
Beagleでは、ユーザのhomeディレクトリを検索できるだけでなく、イントラネット経由（ファイルサーバ上）の別のBeagleのインスタンスに対して検索を行う機能や、/usr/local/docなどの共有ディレクトリに共通の静的なインデックスを構築して検索できる機能もある。またBeagleのウェブサイトはTrackerのウェブサイトよりも充実していて、特にクエリ構文についての情報が提供されているという優位点がある。しかしながらBeagleとTrackerとを比べればお勧めはTrackerではないかと思う。私が試した単純なクエリに関しては、Trackerの検索結果の方が優れていた――それこそが、これらのプロジェクトのメインの目的だ。Trackerは、Beagleのサイトで行われているように、クエリ構文の略記法を例もいくらか用いてウェブ上で文書化すれば、その最大の弱点を克服できるだろう。
なお私はメタデータ抽出/インデックス作成を行うオープンソースの「ライバル」プロジェクトであるlibferrisに取り組んでいるが、TrackerともBeagleとも関わりはなく、両プロジェクトを公平に考察した。
Ben Martinは10年以上もファイルシステムに携わっている。博士号を取得し、libferris、ファイルシステム、検索ソリューションを中心としたコンサルティングサービスを提供している。
