Z39.50開発事例
1. 新日鉄ソリューションズ (LVZ)
[橋本]新日鉄ソリューションズの橋本と申します。前回事情で出席できませんでしたので、今回初めて出席させていただきます。よろしくお願いします。今回の研究会の中で、うちが開発しました、LVZのZ39.50について紹介させていただく時間をいただきましたので、簡単な資料と説明で申し訳ありませんが、紹介させていただきます。
プロジェクターに出せる資料ができなかったんで、皆さんにお配りした2枚の紙、あると思いますが、そちらの方で、うちのZ39.50サーバーの簡単な概要について、説明させていただきます。
簡単な資料ですみませんが、Z39.50サーバーのどういう機能をサポートしているかという、箇条書き程度のものですが、LVZ Z39.50サーバーの方は、LVZの検索サーバーの方を介して、データベースの調査を行い、クライアントのほうのその要求を出して、返戻を返しております。よって、Z39.50のプロトコルの処理を行うモジュールと、それを受け取って、実際LVZのデータベースに対して検索サーバーと連携する処理を行うモジュールの2つに大きく分かれております。
実装してますサービスが、基本的なものですが、初期化・検索・ソート・返戻・終了のサービスを実装しております。初期化の中で対応しておりますプロトコルバージョンですが、ヴァージョン２と3のほうに対応しております。オプションとして、検索・ソート・返戻に対応しております
サーバーを立ち上げますときに、エミュレーション機能あり、なしのどちらかで起動できるように対応しております。エミュレーション機能ありで起動しているときは、認証処理を行います。文字コードのほうは、ISO-2022-jpとUTF-8、の2種類の文字コードに対応しております。
検索サービスのほうが、検索の対象とするファイルデータベースですが、図書の書誌と所蔵を扱うBOOK、雑誌書誌所蔵を扱うserial、の2種類のデータベースを指定して検索を行います。問い合わせ方として、タイプ1、タイプ101をサポートしております。検索式の論理式としてサポートしているものは、ANDORとANDNOTの2種類です。ソート機能ですが、こちらはLVZの検索サーバーのほうの機能のほうと関連することがありまして、次のような制限事項としてあげてますが、次のようなものがあります。現在指定できるソート項目というのは、1項目のみ、大文字と小文字の区別をしないでソートを行います。複数の検索対象ファイル、図書と雑誌と別のソート対象項目を指定する機能は、現在はサポートしておりません。
スコアに基づく検索結果集合に対するソートは今のところサポートしておりません。
返戻サービスですが、対応しておりますレコートコードに関しましては、CAT-Pフォーマット形式と、MARC21と、JP-MARCの3種類です。要素集合名として、簡略レコード型と、詳細レコード型と2種類を指定できます。
最後に、BIB-1のサポートの詳細の表を載せておりますが、ユースアトリビュートに関しましては、NII様のZ39.50サーバーの公開されてます仕様のほうに合わせる形を取らせて頂いております。実際正式には公開していないのですが、うちのほうで検索用サーバーを設置しておりますので、その画面だけを簡単ですが紹介いたします。
検索条件を入力する画面です。最初にそれぞれ登録されておりますZのサーバーがございますので、その中からどのサーバーに対して検索を行うか、を選択します。選択したZ39.50サーバーに対して、検索条件を入力します。検索ボタンを押すと、選択した各サーバーに対して、Z39.50のプロトコルにしたがって、検索要求を出していきます。検索結果のほうが各サーバーの件数として表示されます。ソートのサービスを実装しておりますサーバーに対しては、ソート項目も選択できるようになります。それぞれのサーバー名をクリックしますと、そのサーバーの検索結果の一覧を表示する画面になります。
この画面を見ただけでは、Z39.50のプロトコルが使われているとか、どういうMARCで返ってきているのかというのが分からないとは思うのですが、受け取ったデータを解析して、表示しております。一つのデータの詳細表示に戻って、MARC表示を行います。。実際にサーバーの方から返ってきているデータのMARCフォーマット形式を解析しています。
ページの方は正式には公開できていませんが、近いうちに皆さんがインターネット上でこういう画面で検索できるように公開したいと思っております。先日、慶應大学さんのZ39.50のページの方にうちのサーバーへの検索のルートをつけていただきまして、実際に検索できることも確認できております。
今後の対応としてたしましては、LVZのほうはCAT-P形式で目録データを持っているので、それをMARC21の方にどういう風に変換するかということがありますので、こちらの方はNII様の変換仕様の方に従う形になると思いますが、そちらの方も進めていきたいと思っております。
以上、簡単な説明で、上手な説明ではありませんでしたが、弊社のLVZのZ39.50の実例報告ということで、報告させていただきます。
2. 慶應義塾大学の実装方式
[入江]それでは質問もまた、あとで。慶應の方にいきます。慶應の方のデモはですね、Z39.50のウェブゲートウェイの機能分担と機能概要というところをですね、見ていただければ。
慶應の方のゲートウェイ、ゲートウェイ側でいくつかポートを分けておりますので、これがUTFの対応のものです。前回も見せているんですが、今回いろいろ考えたことがありまして、実装のやり方を説明させていただきます。
機能分担と機能概要ということで書いていますが、Z39.50のターゲットは交換フォーマットをきちっと出すための機能ということで、機能限定をしております。その代わり、文字コードのいくつかのパターンを用意しようかと思っています。JISも出していますけど、ポートをわけて、慶應のターゲットから出す文字コードだけ分けています。KOSMOSIIと言っているのは、ローカルの慶應のシステムです。KOSMOSIIからZ39.50ターゲットにデータを貰ってですね、そこから出していくフォーマットは一応MARC21ベースに準拠したフォーマットを出します。それ以外にゲートウェイを作っておりまして、このゲートウェイはユーザーインターフェースとターゲットのバリエーションがいっぱいあるので、それを吸収するということで考えているものです。LVZもついています。
日本語資料をいっぱい持っているMelvylから返って来るデータは、元々はここはINNOPACなんですけれども、EACCです。EACCのデータをコンバートしてUTFにしています。MARCフォーマットを見ると、長音が出ていないんですが、通常にMARC21で出てきたものは、どこであろうが普通に出ます。ここに日本語表示の場合と英語表示の場合と選べるようになってまして、通常の基本タグから持ってくるものと、880から展開するものの切り分けをしています。これは、ローマ字形です。ユーザーインターフェースの設定はここでやっています。
通常にデータを交換するという意味でのフォーマットを決めてしまって、あとはクライアント側である程度のコントロールをしてしまうと、同じに見えるという説明です。Z39.50ターゲットは、何をするかといえば、データフォーマットを決めた形に出していくものであって、あとはユーザーインターフェースを作らなければならないというところだと思います。そこをある程度コントロールして、のせましたと。これを、今回LVZが作られたということだったので、当たり前でMelvylは漢字できないんですが。皆さんUTFのコードを持っているので、あとはBIB1のマッピングがあるので、いろいろやらなければならないのですが、LVZはあたり前にでます。LVZは新日鉄さんから情報をいただいて、設定するのに5分かからなかったのですが、慶應側のネットワークが閉じていたので、そこを直してもらって、やったらすぐにできました。ある程度NIIさんが出している標準とかありますので、それに則ってもらえれば、ほとんど問題なく出るかと思っています。データ交換という意味では、それなりにできるかなと。今後のターゲットは、CD-ROMサーバーがZに上がってますから、それをくっつけるテストをしています。一応SilverPlatterにしろ、Ovidにしろ、テキストのマッピングは出してますので、それにそってやればできます。ただ、SilverPlatterとかCD-ROMとかいうのはだいたい著作権の問題があって、ここにはリンクしてないですけれども、CD-ROMについては、全部問題なくZで検索できるようになっています。あとはそこからどこにいくかということだと思うのですけれども。全部実験はしてみました。今回は、ターゲットとクライアントの機能分担をきちっとして、ターゲットは通常のMARC21で出す形にして、ある程度のユーザーインターフェースをゲートウェイでやっていくことです。日本語資料を普通にどこでもいこうという形で作っています。細かい資料については、コンパックさんが作った資料がありまして、基本的なところはコンパックさんが作ってくれているんで、出しています。libsysのページから、いつでも入れますので、いろいろやってみてください。あとはこれをどう業務で使うかというのがありまして、今書店さんの発注システムからｚで検索がきて、重複チェックをするという実験をしています。ただまだ安定していなくて、業務に乗っけると、いろいろありまして、まだテスト中ですけれども。いくつかの実験をしながらやっています。とういうところで、僕のほうのデモは終わります。
3. 富士通 (iLiswave)
[松永] 富士通の松永と申します、よろしくお願いいたします。本日は5分ほどお時間をいただきまして、弊社大学図書館システム「iLiswave」の標準化の状況ということで、簡単にご説明させていただきます。Z39.50サーバは、NACSISフォーマットからMARC21の変換機能を現在開発しております。「NII様からご提示された変換仕様をベースに書誌変換機能開発済み」と資料に書いてございますが、先ほどNII様より仕様変更の説明がございまして、非常に大変な修正量があるなあと思いました。所蔵変換機能に関しましては、仕様が決定したということで良かったなあと思っております。資料の図は元の変換仕様で展開している例になります。
http-Z39.50ゲートウェイ(クライアント)は、統合情報検索環境という商品の１機能として提供いたします。資料の画面は一例となります。画面展開は次の通りです。
- データベースリストから検索対象を選択して検索を実行します。
- 各データベースの検索結果件数が表示されます。
- 検索結果件数をクリックすると検索結果一覧が表示されます。
- 検索結果一覧から1件を選択してクリックすると詳細表示されます。
これは開発が完了しておりまして、現在京都大学様で評価中という状態になっています。
「ISO ILLプロトコル」に関して今まで研究会では話題にならなかったのですけど、これも標準化の一つかなと思いまして、開発状況だけご説明させていただきます。NACSIS-ILLでは1月末からOCLCとの接続テストを実施されていると思います。弊社のiLiswaveにおいても対応を進めているところでございます。項目追加のほうは画面上にマッピングが終わりまして、OCLCへの複写依頼まではテスト済みになっております。現在、テストサーバーのほうが受付機能のテストができない状況になっております。先日NII様のほうにお伺いましたら、2月初旬あたりにテストが可能になるということなので、それにあわせて受付機能のテストを開始いたします。
課題が3点あります。Z39.50ターゲットは、NII様の仕様変更にともなう書誌変換機能の修正が必要だということです。後ほどいろいろ質問させていただきます。Z39.50ゲートウェイは、利用者サービス（デリバリ）までつなげなければならないということで、複写依頼などをどういった形で提供していくかということです。「ISO ILLプロトコル」は、宛名・担当について国内でやる場合と、OCLC宛ての英文でやる場合と、文法形式が異なることです。弊社CATPクライアントだけの課題かも知れませんが、宛名・担当を分解した形で表示・入力するため難しいのです。4月の本稼動に向けて頑張りたいと思っております。
富士通からの説明は以上でございます。
[入江]早稲田さんのデモが始まる前に、ILLとか、そういう利用に結びつく、クロスサーチができたあとに、どういう風に利用に結びつくかという問題だと思いますので、これからやっていかなければならないと思います。
多言語対応(文字コードとMarc21)
1. 早稲田大学 (Unicode版 INNOPAC)
[荘司]早稲田の荘司と申します。よろしくお願いいたします。INNOPACというシステムなんですが、INNOPAC自体がUNICODE版を持っているのでそれについて簡単に説明いたします。配布資料がございませんので、スクリーンをご覧ください。
こちらがINNOPACの本体で、こちらがデーターベースだとします。インデックスのデータベースと、ここは普通のローデータといいますか、入ったままのデータを蓄える２つのファイルを持っています。外から入力されますとテーブルがありまして、例えば早稲田にやってる例ですが、シフトJISのコードが入ってくると、それをアスキーコード、先ほど説明がありました7bitのアスキーに変換して、それを格納しています。もうひとつは、いわゆる正規化です。ノーマナイズを行ってインデックスのほうにも格納しています。これは文字が何であれ、すべて英小文字で格納する方法がとられています。ここで、我々のほうからINNOVATIVE社に注文したのは、メールに関しては、数年前だったので、インターネット上は7ビットしかいかんだろ、ということで、2022-JPで出すように、またレーザープリンタに出す必要性がありましたので、ESC/Pで出すように、といったお願いをしました。INNOPACの場合、この例では、テーブルがシフトJISと書いてあります。ですが、例えば、これはシンガポールの国立大学なんですが、GBを選んだり、EACCを選んだり、また、日本語の場合はシフトJISを選びなさいとあります。要するに、先ほどのテーブルを複数個購入すれば、ユーザが文字のテーブルを選択することが可能になります。元の内部データはアスキー1種類なんですが。次の例は、香港の中文大学なんですけれども、昔、我々はDOBISというシステムを使っていたんですけど、この大学もDOBISからINNOPACへ移行した中国語が入っているサイトです。ここではBIG5というコードで動いています。
ここに2つ機械の機というプレートを出しました。シフトJISでは2バイトなんですが、16進で8B40という機械の機というコードは、EACCコードでは、214552というコードになります。3バイトのコードです。INNOPACの中ではこの文字は8バイトになります。先ず最初にアスキーキャラクターの"{"、次にEACCの16進表記、最後にアスキーキャラクター"}"の8バイトです。つまり、一つの漢字コードに対して、シフトJISコードでは2バイト、EACCで3バイトですけれども、INNOPACでは8バイトという冗長なコード体系を持っています。一方、アスキーで設計されたINNOPACの内部機構を変えなくてもいい、という利点もあります。
先ほどのテーブルの絵がありましたけれども、このシフトJISコード、これとこの変換テーブルを、実際はUTF-8のテーブルなんですけれども、UNICODEの変換テーブルに変えるだけで、UNICODE版のINNOPACになります。ここで、ちょっと何故この文字を2つ出したかといいますと、内部的にEACCコードのこの頭、この1バイトが違うだけで、あとは同じコードを持っていますが、この二つは串刺しで検索されます。どうも内部的にマスクをかけている感じで検索をしているようです。推測の域を出ていないんですけれども。
右画面（シフトJIS）のほうで、著者名で陳さんを引きました。左側（UTF-8）のほうの、こちらでも同じ陳さんを検索します。一番最後のエントリーに飛びますと、陳さんという簡体字が出ています。シフトJISコード（右画面）のほうでも同じレコードに飛ぶと、データベースは同じですので、同じレコードにあたります。この文字はJISコードに無いので、コードページに無い文字は、カタログで使わない"{"、"}"を使った内部コードで表示されてしまいます。先ほど芝野先生のお話にあったのと同じ現象が起きています。右がわのシフトJISの普通に公開しているほうで見れば、なんとなく読める。こちらで見ますと、いわゆる簡体字で（中国語で）ちゃんと出てきています。UNICODE版のひとつの特徴なんですけれども、例えばこの中国語だけではなくて、ISBNで89で始まるのが、韓国ですが、それで検索すると、ここにあるようにハングル文字と漢字、あとダイアクリティカルマークのついたOの上に波打ったというかそういうデータが出てきます。実は、MARCを見ると、OCLCから購入したデータでして、OCLCから購入したデータにダイアクリティカルマークが入ったものがそのまま入っているので、そのまま出てくる。OCLCに入っていたそのままを使って、880をデータを取り込んでおりますので、OPACを見ますと、そのまま漢字かなハングル交じりというのが見える、という風になっています。
今やったような音標記号があるものですと、例えば、このようにいろいろな記号がついているものがあります。このデータも直接OCLCから取っているデータですので、いちいちこのような記号を入力したわけではないんですが、きちんと表示できるようになっています。同じ物をこちらの普通のシフトJISバージョンで見ると、出ません。こういった形で表示されるようになっています。同じINNOPACですが、カイロのAmerican Universityですが、ここも実は昔DOBISというものを使っていました。ここのインターフェースも同じです。arabicで引きまして、言語をアラビア語にして、ここもUNICODEにしますと、右から始まって、こう言う風にきちんと入っています。また、このアラビア文字でサーチにいくと検索されます。
ダイアクリティカルにつきましては、第一部のお話にありましたように、INNOPACではどういう風にしているかといいますと、このアキュートの文字、ノンスペースの記号があって、eがあるという、このMARC21のフォーマットも使っていいよということになっています。それをINNOPACでは、"{"、"}"を使って、E2というのを10進表記すると226になり、それとeという風に{226}eという6バイトで表しています。これは非アスキー文字に対してINNOVATIVE社がやってきたもので、漢字はここを伸ばして8バイトにしたという手法を使ったのではないかと思います。
文字は大体見えるけれども、入れるのはどうするんだという話があります。業務用画面に入ると、先ずターミナルタイプを選びなさいというのがあります。アメリカ的ないろんなターミナルが並んでいる、タイ語のターミナルとかもあるんですけれども、ここでUTF-8のターミナルを選ぶ。メニュースクリーンは残念ながらアスキーコードでしか返ってきません。新しいレコードを入れるときはFEPの問題があります。実際に早稲田でどうやっているかといいますと、中国語を入れてるチームは中国語のChinesewriterとかそのようなFEPを使っています。ここでは無いので、とりあえずIMEの文字一覧から選ぶことにします。例えば、245フィールドに何か文字を入れたい。これはUNICODEのCJK漢字ですね、これを選んで、リターンをすれば入ってきます。これで、中国語を入力することができます。もちろん、例えばハングルの場合でも、ハングルを選ぶとハングル文字も入っていきます。このようにしたり、OCLCなり、同じINNOPACを使っている館からデータ交換をやったりということで、入力しています。
[入江]時間があれば、と思っていたんですが、慶應も同じようなことをやっていまして、SQLサーバーで簡単に作ったデータベースで、慶應の買っている中国語の6割がOCLCにあったので、OCLCから中国語のデータはほぼ買っている状態です。問題なく入っちゃうんで、韓国語と中国語はそこから持ってきているんです。あとオリジナルだけ作ればね、書誌データは国際交換しなくちゃいけない時代になっていると、そのときどういうフォーマットを使えば交換できるのかと、日本のデータも外から持っていってもらえるには、どう作るのかと、やっぱりお互い交換しないとダメだね、というレベルで、OCLCばっかりあんなに儲かっちゃ困るけど（笑）っていうのもあるから。
ここでＺの話は早稲田さんで最後にさせていただきまして、ここから新しい話になるんですが、先に説明をしていただいてからZの質問に行きたいと思います。
米沢さんのほうから今NIIがやっています、メタデータDBについての説明をお願いいたします。
[米沢]NIIの米沢と申します。