図 1: Z39.50 の全体像
今日使われている大多数の商用オンラインデータベース検索サービスでは、 大型計算機(mainframe)に検索システムを搭載し、 端末の制御を大型機から行なっている[1]。
これらのオンラインデータベースを検索するには、 システム毎のコマンドやデータベース構造を覚えなければならないということが 大きな問題としてあげられる[2]。 しかし、1つのデータベース機関が多数のデータベースの提供する DIALOGのようなサービスが登場し、 多様なシステム、多様な検索方法という問題は解決され、 大きな問題とはなっていなかった。
現在、WWWの普及により多くのOPACがWWW上で提供されるようになってきた。 WWW上で提供されているOPACは、従来のOPAC よりユーザインタフェースに優れ、使いやすい[3]。 yahooやinfoseekに代表されるサーチエンジン など WWW 上で提供されている情報検索システムも現れた。 WWWはHTTPという検索を目的としていないプロトコルを使っているために、 大型計算機時代からの履歴を利用した検索を行なえない。 このように、ネットワーク上にOPACやWWW上のサーチエンジンなど様々な 情報検索システムが存在し、アクセスできるようになった。 しかし、これらの検索システムに対して検索を行なうためには、 検索システム独自の検索クライアントからアクセスしなければならず、 検索システムごとに違ったインタフェースやシステムに 習熟しなければ検索できない。 ユーザーが検索システム固有の検索クライアントからしかアクセスできない 理由は大きく2つあげられる。
これに対し、 Z39.50 は検索クライアント検索サーバ間のやり取りを 標準化しているので、 Z39.50 を用いた検索クライアントを使うことにより、 ユーザは固有のインタフェースやシステムの違いを意識 せずに Z39.50 を用いた検索サーバにアクセスし、検索できる。 また、 Z39.50 はセッションを維持したままの検索を約束しているので、 履歴を利用した検索もできる。 Z39.50 を用いた検索システムは、アメリカ議会図書館の Z39.50 管理機構に 登録されているだけでも100を越えており、増加の一途をたどっている。
そこで、このような背景をふまえて、本研究ではクライアントサーバ間のやりとりを標準化し、一元的にアクセスできる 「情報検索プロトコル Z39.50 」を用いた検索クライアントの開発を 行なう。図1は Z39.50 検索システムのイメージを表している。 左にクライアント、右にサーバがあり、その間のやりとりを Z39.50 で行なう。 クライアントは、特定のサーバだけでなく、 Z39.50 を用いたサーバであれば どのサーバでもアクセスでき、 また、サーバも特定のクライアントからだけではなく、 Z39.50 を用いたクライアントであればどのクライアントからでもアクセスできる。