研究会報告

3. LIMEDIO におけるZ39.50の適応事例

LIMEDIOは Web版のOPACに特化した検索用のデータベースを 雑誌と図書のカタログデータベースをもとに作成しています。 先ほどの話にもありましたが、MARC21でBib-1で検索するというのにはかなり 無理があるデータベースの構造になっています。 その辺を適宜マッピングしながらやっているのが現状です。

サポートしているサービスはInit,Search,Presentまでで、 Type-1 queryでBib-1なんですが、これについては初回の研究会で 資料を出したものがホームページにもあがっているので、今回は省きます。 その時から内容は多少変わっており、所蔵とか少し加わっているところが ありますが、基本は変わっていないのであちらを参照して下さい。

返戻するレコードシンタックスはMARC21で、文字コードはUTF8固定にしています。 880は一切使っておらず、245や100は、日本語をそのままUTF8にして出しています。 今、LIMEDIOで何校かに入れさせていただいているんですけど、 先ほどユサコさんの発表にもありましたが、札幌医大さんのが 外に向かって見えています（2002.7.18現在、見えない模様）。 その他にも数校いれさせていただいて、評価していただいています。 あとlimedio.comというサイトをLIMEDIOで持っており、 そこにアクセスしていただければ見ることができます。 データ的には、どこかの図書館のデータをデモ用に借りているもので、 著作権的には問題がないこともありませんが、使わせていただいてます。

ここに例があります。245が日本語そのままです。 880を使う使わないで検討しているんでますが、 どう扱うかは議論はしていますが、決まってないということがありまして、 今はしばらくこのままでやっていこうかなと思っています。

もう一つLIMEDIOにはZ39.50とHTTPのGatewayというのを作っています。 まだ商品として形になってはいませんが、 慶應大学さんにもありますが、ブラウザを通して Z39.50の検索が見る ことができるものです。JavaAppletで見かけを格好よくしてあるのが特徴です。 この下に、プロセス構成が書いてあるんですが、スレッドを切って並列で 実行する仕組みです。 HTTPでGatewayサーバにリクエストを投げて、そこでZ39.50のクライアントが起き、 それぞれのZ39.50サーバに向かってリクエストし、そのレスポンスを返すと いう仕組みになってます。

これがAppletで作ったGatewayです。説明させていただきます。 これは今までのLIMEDIOのGUIですとかWeb版のOPACの デザインを無視して全く新しく作りました。 カテゴリというのを用意してありますが、これはサーバ側でセットします。 ここではLCとPubMedとLIMEDIOとNIIの海外向けのUTF8のZ39.50サーバを 置いてあります。 NLMのPubMedはHTTPに移ってしまっているので IndexData社が試験運用的に置いているPubMedを見ています。 どこのZ39.50サーバを見るかというのを選択して、"dental"で検索します。 するとAnimationGIFが動いて検索している状態が分かります。 これでSearchまでできてます。ここで例えばPubMedで結果を見に行くと、 今度はPresentで10件づつとっていきます。 ここがテキストビューとMARCビューで表示を切替ることができます。 PubMedは100と245しかないデータベースで、100もほとんどないですが、 これをデータをもってリンクする機能があり、 この「所蔵検索」や「抄録参照」のボタンががその機能で表示しています。 抄録参照はNLMのPubMedに検索にいくようにしてあります。 PubMedに限らず、 サーバ側でMARCのどのフィールドのどのサブフィールドをキーに検索式を 作る指定ができて、抄録参照は制御番号を持って検索にいく仕組みに なっています。 それから所蔵検索はOPACにつながるようになってます。 札幌医大さんで、この機能を利用しております。 あと、ここに文献複写というのがありますが、 札幌医大さんは文献複写を効率的にやりたいということだったので、 PubMedの情報を背負ってきて論文名や著者名を文献複写依頼まで 持っていき、あらかじめデータのある状態するという仕組みになっています。

日本語で検索します。UTF8でそのまま投げるようになってますので、 VoyagerとかPubMedは当然0件になってしまいます。

これのZ39.50ゲートウエイの仕組みは、 Searchが終わるとZのセッションは一回切れてます。 10件表示するときは、またSearchしてから 10件Present します。 次の10件を表示する時には、さらにSearchして、11件目から20件目をPresent します。

これがMARCで返戻されるデータで、テキストビューの方には所蔵は出していません。 AppletなのでPCの側のパワーだとか、JAVAのプラグインを使ってますので 1.3.0以上であること等、クライアントの環境にディペンドしてます。 もう少しどこへでも動くようにはしたいのですが、現状はこうです。 これがAppletのGatewayのデモでした。

Gatewayをお客さまの所に置かせていただいて、 各サーバとの接続の実験をさせていただいているのですが、 問題が多く苦労が絶えません。

一つ目が、認証のあるサイトをどう扱うかということです。 半分パブリックなGatewayなので、例えばOvidのZのところを見に行った時に 誰がいつ認証するかということがあります。 サーバ側に持たせてしまって誰でも見れるようにするのが多分一番簡単ですが、 そうするとOvidとの契約に問題が発生すると思います。 あとは学内だけしか見えないよという縛りをHTTPDの方でかけられれば、 それで良いような気もしますが、 その辺がどうすればいいのかが分からないところです。 あと、必要に応じてユーザが個別に認証するということもできなくはないかなと 思っていますが、今のApplet版ではZのセッションが一回一回切れてしまうので、 ちょっと無理かなと思ってます。 今は認証をやらないと言い張っているのですが、 どうしても必要との声がかかったらどっちに転ぶか分かりません。

もう一つはレコード構文がMARC21だけに対応していることです。 BLがMARC21に対応しておらず、GRS-1とSUTRS なので、 何とかならないかと言われています。 MARCに依存したコーディングですので今はできないと思っています。 IndexData社にレコード構文に何を対応しているという統計みたいなのがあるの ですが、MARCは70％くらいで、MARCとSUTRS合わせればだいたい100％になるので SUTRSには対応しようかなとも思うのですが、 MARC以外は対応したらいいのか、しなくてもいいのか、ということが 分からない状態になっています。

最後に、文字コード変換というのがあります。 一番苦労したのがLCで、LCは文字コード変換は自分の所ではしない、 ということで、音標記号の前に変なコードが1バイト入ってくると （[入江]：ANSELだと思います）それを私どもの文字コード変換の フィルターにかけるとそれが壊れてしまうので ちょっと苦慮してます。 あとLCは880にまた違うコード（[入江]:EACCです）が 入っているケースがあるみたいで、すべてがUTF8じゃないということが 分かってきました。 返戻されたデータが同じコードで来ることにしているので、 コードの変換の規則が適用できず、うまく表示できないケースが少なからず あります。 そのせいでGatewayのプログラムが止まってみたり、 Appletが止まってみたりいろいろなことが起こっており、苦労させられてます。

ここまでがZ関係の話で、 ここからはLIMEDIOの紹介をちょっとだけさせていただきます。

今やっているのが、ユニコード版LIMEDIOの開発中でデータベースそのものを UTF8化したものです。今までのデータベースはEUCだったんですけれども、 EUCのデータベースでは、ハングルとか中国語の文字とかは検索対象外 でしたが、これらも検索可にして、完全にユニコード化してマルチリン ガルにしますというのを、今開発中です。 商品化は、目録システムの部分とWeb版のOPACから商品化を予定しています。 この中でWeb版のOPACだけ特別に項目をあげたのですが、 NIIの漢字統合インデックスを用いた検索システムを 作ろうとしています。漢字一文字で検索されると、 ちょっと分からない結果がでてしまうことがあるんですけれども、 今は例えば毛沢東で検索すると中国語でもでますし、日本語でも出ますし、 台湾の古い文字でも出ますし、というようなことが今できるようになりつ つあります。 来月LIMEDIOのプライベートセミナーを行ないますが、 そこではそれを出してお見せすることになっています。 UTF8版OPACと同時に、今までどおりSJIS版やJIS版はそのまま残して おくことにしています。 すべてのブラウザがUTF8を表示できるかというと、 多分もうしばらく無理だろうを思っています。 SJIS版は携帯端末版のOPAC用です。 最近はちょっと違ってきていますが、あれはSJISじゃないと表示できないので SJIS版も残ります。 ここに書いてありますが、LIMEDIOのOPACは検索DBを中心に、 Web版のインターフェースがあり、 携帯端末版のインターフェースがあり、 Zのインターフェースがある、仕組みになっています。 実はUTF8化ができれば、 Zも完全に内部がUTF8になりますし、漢字統合インデックスも使えるように なりますので、検索の性能がよくなるのかなと思ってます。 先ほど入江さんのおっしゃってたPositionだとかTruncationですが、 あの辺はLIMEDIO独自にデータベースの中に取り込んでしまっているので、 またマッピングの作業が発生するか、 少し概念を考えなければならないかもしれないです。

ISO/ILLの件です。 担当の開発の連中に聞いたところ、開発は完了してますがテストはまだで、 これからやっていきますと言うことでした。

あとは課題です。 Z39.50サーバの方は880を含めて、 何年か前に作ったフォーマットの見直し作業をしています。 次に Gatewayですが、システムのリンクの機能ですが、 先ほども言いましたけど、認証の宛先をどうすかですとか、 SUTRSとか、BLの扱い等を考えていかなければならないかなと 思っています。

以上です。

[入江]ありがとうございました。いろいろと面白い話がありました。880の話は、やはり悩むところも多いし、いいのかなと思うところも合って、最近中国も韓国のMARCも245に自分のキャラクターを入れているというのが多いし、それがLCのstandardになるという話もあるので、そこはもうちょっと話をしなければいけないでしょう。慶應にしても日本語はやはり245に欲しいというのがあって245に日本語いれていますから、そこはUTF8がもうちょっと話が進めば可能性があるのかなとは思っています。

それからANSELとEACCは泣かされます。ほんとにあれは大変なハンドリングです。RLINは880はEACCですし、245とかにANSELがはいってきますから、化けます。彼らはON THE FLYでUTF8に変換すると言いながら全然やっていないですから、相変わらずEACCとANSELはびっちり入ってきますので、でANSELはたまに変なところにぶつかってソフトを壊しちゃいますので大変だと思います。

お手元にお配りしたもののは一つはターゲットに関する話のガイドラインと、今日これからオンラインでデモをします内容を紙芝居にしてありますので後ほど見ていただければという感じです。

まず一つクライアントORIGIN側なんですがMARUZEN Z39.50 Gateway-CATという非常に古くさいソフトウェアを持っております。これは第一回の時にもちょっと触れさせていただいたのですが、RLGと提携するにあたってクライアントがないとだめよと言われまして一生懸命コンパックさんに協力を仰いで開発したというようなシステムであります。当時は1996年、このシステムが動き始めたのが1997年か8年くらいだったと思うのですが、もう4、5年動いております。現在ユーザーさんは40ユーザーくらいおりまして、RLGの書誌レコードを調達していただくということで、一応このシステムを使っていただいているというような内容になっています。慶應義塾さんもユーザーさんの一つで受発注システムからinvokeしてこのシステムから直接RLGへ接続するというようなこともやったりしております。デモに移ります。

お手元のハンドアウトで見ていただいて分かるように、いわゆるTelnetベースのZのクライアントになってます。当時、もうすでにブラウザは世の中にあったんですけれども、まだNetscapeが出たばっかりくらいの状況で漢字入力するとShiftJISは送ってくるはJISは送ってくるはという非常に劣悪な環境もあったのと、Zがいわゆるstatefulだということで、Webでやるよりもキーボードオペレーションの方がいいんじゃないかということで、同じstatefulなTelnetというような使い方をしております。OSはコンパックコンピュータで、もうすぐHPになりますがαシステムのVMSというOSで動いています。クライアントの方はVMSです。後で説明しますがターゲットの方はTrue64 UNIXの方で動いております。

今日来ていただいた黒澤さんはさんざんご覧いただいている画面だと思いますが、いわゆるTelnetベースのアプリケーションになってます。お客さんに使っていただくということで、なるべく分かりやすいコマンドで動くような形になってます。b RLGとたたくとこれで裏側でINITが動きます。RLGは当然認証が必要ですので裏側でお客さまごとのアカウントのAuthenticationの最初のINITサービスを発行するという形です。このシステム、実は私どものHOSTコンピュータで動いているということもあって、一番頭が痛かったのはFirewall越えというのがありまして、あの頃はまだScreendとかそういう世界でしたので今みたいにNATのルータとかそういうのがないんですよね。どうやってFirewallを越えるかということで、スペシャルですけれどもZ39.50プロキシというのが動いております。プロキシを経由して接続するという状況になっております。これでRLGへZ-associationを張ってしまっています。statefulですからもうこれでRLGのホストコンピュータとの間に通信セッションを開設しているということで、ここから投げるコマンドは全部RLG側に送られるという形になっています。

これ実はRLGだけじゃなくて、さまざまなことができるんですけれども、開発した当時、北米のあちこちの大学でZのターゲットがあがってまして、ただやっぱり今もってまさにプロファイルの議論になっていますが、それぞれ実装が違うということで、クライアントに一生懸命テーブルを作り込みました。それぞれのターゲット毎にテーブルをセットして、検索しやすいように漏れがないようにということで、たとえばデフォルトのAttributeだとか、USEをどういう風にマッピングしているのかというのを全部コチコチコチコチ一生懸命作っていて17件目で疲れましてやめましたけれども、その後、最近慶應さんとかNIIさんをいれてみたり、ちょっとお遊びでCATPさんへ同じコマンドで検索できたら面白いなとか言ってやってたり、そうした残骸がちょっと残っています。それでいわゆるコンフィグレーション、なぜプロファイルを共有化しなければならないかというと、この作業が結構大変だということです。ターゲット毎にUseが違う、それからデフォルトのattributeが違う、送ってくるレコードシンタックスが違うと。確かにプロトコルとしては統一されているんですけれども、それぞれのオリジナリティというか、微妙に違うところがあってそれを解消するためにはどうしてもプロファイルみたいな共通仕様が必要だという話をしたかったんです。

それでは検索してみましょう。このコマンドは、CALISという私どもの図書館システムがあるんですけれども、そのコマンドとほぼイコールというか、ほとんどそのままです。ですからCALISのユーザさんは、まさにローカルシステムと同じコマンドでRLGを検索できるというような感覚を持っていただけるのではないかと思います。真ん中のアスタリスクはブール演算でcatalogとbibliographyで絞り込んで347件ということになっています。RLGのZEPYERはバージョン2ですが、かなり高い機能を実装してまして、まずnamed result setは標準で持っています。ですから検索結果集合をセッションが張られている最中はずっと持っていますので、その検索結果に対する絞り込みというのもできてきています。それを上手に利用するためにGatewaycatの場合は1個で347件ときたらそのあとsと投げると347件に対してResult setの絞り込みをかけていきます。それで使っているお客さんは、まず大きなところからどんどんしぼりこんでいって最終的に自分の欲しいレコードに到達するというようなシチュエーションを想定して、どんどんしぼり込んでいく、Result setに対してしぼり込んでいくというのが標準のオペレーションです。これをちょっと逃げるためにNと打ちますと、これでResult setを新しく切り替えます。これから検索するのは新しいResult setですよ、ただし今までのResult setは破棄してしまった訳ではなくて、当然向こうで保持しておりますのでResult setのリストもクライアント側で持ってたりしてます。あとUse Attribute、s ti=JAVAと打つとすると、ti=でUSEが指定されたことになります。指定したのはUSEだけなんですけれども、クライアントの裏側ではwordのstructureを指定したりとか、completenessを指定したりしております。それでぽんと検索するというわけです。実はこのUse attributeはそのまま標準が使えるようにしてたりもしますのでs 4=JAVAも同じ結果になります。それと、もう一つRLGのターゲットが実装している機能にResouce control facilityというのがあります。これは私はデータベースが大きくなると絶対必要な機能だと思うのですが、ご覧になる方、初めてだと思いますけれども、大きな検索wordを投げた時に、当然検索結果集合をターゲットは作っていくわけです。それに時間がかかる場合に、ターゲットはResource control メッセージを戻してきます。つまり、サーチレスポンスを戻してくるのではなくて、Resource control メッセージを戻してきますので、それに対してクライアントOriginがどう応えるか、行けと言った時には続けます。要はCtrl+Cをたたけない、ブレークキーを送れないかわりにターゲットが、ある一定の間隔で次のリソースへ続けるかどうかとコントロールメッセージとして出てくるので、当然これはNoを返せば検索は中断され、ターゲットはその検索結果を破棄するというような動きになります。CALISの検索エンジンとかですと結構パワーを使ったりするので、この機能がないとgeneric wordを引っかけられたりしたときにかなり苦しいなというのがありまして、とくにRLG検索した時にはヒットレコードがでかいということで、この機能をきちんと実装しておかないとトラブルのもとになるということで、これは当時から使えるようにResouce control を入れてます。

Result setをちょっともう一度見てみます。s RS=1*RS=2　とすると0件になりました。こういった形で過去に検索した結果に対してResult set nameがついてますのでそれに対してブール演算のTYPE-1 queryをなげるという機能です。これもセッションをその都度切ってしまうとなかなかこういう機能は実装しにくい訳ですがstatefulでいうことであれば、かなり高度な検索をかけていくことができるわけです。先ほどちょっとでました、Gatewayの場合はs ti="catalog record"というふうにダブルクォーテーション""でかこってやると、それはフレーズが指定されたということでStructure attributeがフレーズでなげられます。これがcatalogだけだと、どれくらいになるかというと44,000件くらいですね。recordだけだとResource control きちゃいましたが137,572件ですね。これと掛け合わせになっちゃうわけですが、フレーズをきちっと指定すれば簡単に引っ張れるという訳です。次がScan facilityです。ターゲットのインデックスの一覧をこちらに送り返させるという部分です。まず、こちらでサーチじゃなくてインデックスscanをかけますよ、ということで指定したUSE Attributeのcatalogから始まる一覧を持ってこいという形です。例えばこれで29番あたりを選ぶと、画面上はscanの延長線上に見えますが、Z39.50のOriginとしてはSearch facilityを使ってscanから与えられたsuggested attributeというこの29番をヒットさせるためのattributeの推奨されたセットがscanと一緒に送られてきているんですけれども、そのattribute setを持って再度サーチにかかると、18件と同じ件数の結果が得られます。あとは、通常のpresentに入りますけれども、GatewaycatですとzepherがサポートしてますのでElement set nameを有効に使っています。多分、OCLCのレコードもそうだと思うのですが所蔵レコードがごじゃまんと付いてくるようなケースがある訳ですね。MARCレコードのサイズが軽く4K、5K、6Kとかいう感じで6000バイト、8000バイトというような巨大なレコードが沢山くることがありますのでelement set nameでブリーフを指定してやると、せいぜい一覧表示に必要なレコードだけを、まず返してくると。その番号だけを選んで再度presentで今度はフルレコードを取得するためのリクエストを投げるという感じで動きます。

さっきのANSEL、ANSELが出る検索を行きますか。s maruzen 493件です。確かにANSELのキャラクターセットをどうハンドリングするかというのは非常に大きな課題だったんですね。それをちょっと逃げるためにどんなことをやっているかというと、過去に10年20年くらい前にUTLASというUniv.of Torontoのライブラリーシステムというものがありましてそれがやっていた手法なんですけれども、いわゆる置き換えキャラクターというような形でANSELをハンドリングしています。ANSELの場合はコンポーズドキャラクターは先に来るので、山マークの後にoがあります。これを、きちっとUTF8に変換してやらなきゃいけないというような感じです。これはちょっとお遊びでEACCが880にRLGにはいってますので、当時EACCからJISに変換するテーブルを一生懸命RLGが作ってまして、それを未完成の状態でもらいまして、ちょっとぶつけてみまして、ほぅほぅ、やっぱ漢字入ってるんだと見てました。ここはあまり、完全じゃないんですけど、今だとUTF8でやらないといけない感じになると思います。今EACCのテーブルも出てますので、そのテーブルを持ってくれば、もっときちんと完成されたものができるんでしょうけれど、幸いなことにGateway-CATのお客様は日本語は要らないとおっしゃるので、ほとんどお遊びでやっております。

あと、一昨年くらいからZ39.50 Gatewayという、先ほどのHTTP GatewayとかTelnet GatewayではなくてZ39.50同士をGatewayするという機能を持ち始めています。今は、RLGのデータベースを検索してるんですけれども、b/DBDというデータベースセットを指定してやるとこれから送る検索式はすべてDeutsche Bibliothekの方に送られます。Gateway-CATはZ39.50のOriginでRLGのターゲットへメッセージを送って、今度はRLGのターゲットがOriginに変わってDeutsche BibliothekのターゲットへZ39.50のメッセージを送るというわけです。これが分散型の仮想目録といいますか、通常目録を統合する場合はNACSISの場合もそうですけれども、一つの大きなところへどんどんデータを集めていくという考え方なんですけれども、そうするとだんだんきりがなくなってくるという部分で、RLGは2年くらい前から方向性を選択し直して、こういったGateway機能でそれぞれのNational libraryを連携させるということを考え始めています。

同じようにオーストラリアにも行けます。これはオーストラリアのNational LibraryへRLGのターゲット経由でメッセージを送ってくれるという状態になっています。データを見てみますと035にAuNLに入ってますし040の最初の$aにANLとはいてますけれども、これがNational Library of Australiaのターゲットからレスポンスが戻ってきたという形です。こんなことも始まっています。Gateway-CATなんですけど、これができて何なの？というのがあるんですけれども、実はこのデータを簡単にローカルデータベースにエクスポートする機能をもってまして、たとえばこのレコードを欲しいというときにエクスポートの指示をしてやると、これでMARCデータ自体をGatewaycatの方へ一度取り込んでしまっているんですね。そこで簡単な編集ができてsaveコマンドを投げるとGatewayの方へデータをポンと落とし込んでおいて、あとからFTPで、お客様のローカルデータベースの方へ転送していただくという枠組みで動いています。それで大体新刊書の書誌調達でありますとか、遡及変換などのニーズに使っていただいて、かれこれ4、5年になりますけれども、比較的安定して動いているかなぁと、あんまり複雑な検索をされてないのかもしれないんですけれども、だいたい見ているとISBNだけなげてというのがありますが、とりあえず動いているという状況です。

それからターゲットの方なんですけれども、簡単に宣伝させてください。これはうちのMI-PARTNERという社内のシステムがあるんですが、これは私どもの受発注システムがZ39.50のターゲットを持っていまして、これはZepyerほど頭がよくないのでResouce control もしませんし、scanもしませんけど、一応検索ができるということになっています。約200万タイトルくらいの書籍のデータベースを検索できるようにしているという訳です。これはユーザさんというか、実際使っていただいているのは、実は1ヶ所だけでしてbk1さんというECサイトがあるんですけれども、あそこの洋書の調達業務は、私ども出資関係もありましてサポートさせていただいているんですが、それのbk1さんのWebで検索すると、bk1さんのサイトがHTTP Gatewayになりまして、私どものターゲットの方にメッセージを送ってきて、検索結果を返すというような仕組みで一日結構な件数の検索をさばいてます。最初の頃はかなり不安定で、いろいろ問題もあったんですが、最近はそれほど大きな問題もなく安定して動いてくれてると思っています。一応レコードシンタックスはUSMARCをサポートしているんですが、何せ商売用のデータですので、この程度ですね。書名と出版地と出版社と出版年と買っていただくためのローカルデータとうちの受注番号だとか、10,500円でお売りしますというようなことがついています。その後ろに在庫のステータスであるとか取り寄せが可能か不可なのか、などの情報も付けるような形で実装しているという状態です。今後、図書館さんのところでZのクライアントがはいってくると業務システムと連携して選書のデータベースとして使っていただけるかなという、淡い期待は持っているんですが、まだまだそういう話は現状では出てきていないというような形です。一応このターゲットについてのガイドラインの方を、今回資料として付けさせていただきましたので、後ほど見ていただければと思います。ちょっと簡単ですけれども、こんなところです。

CalisとかCARINとか私どもの図書館システムについては機会を改めて、ご紹介できるときがあれば手配したいと思いますので、まずは本屋の丸善のZ39.50を見ていただきました。以上です。