[入江]それでは石田さんの方のご講演をお願いしたいと思います。Z39.50の課題ということでよろしくお願い致します。
（正面スクリーン：講義資料)
[石田] 初めまして。ただいまご紹介にあずかりました、インテック・ウェブ・アンド・ゲノムの石田と申します。もともとZ39.50というプロトコルを追うきっかけはインターネットの検索を業務の一環でやっていた時がございまして、その流れで一つはISOになろうとしているプロトコルがあり、この図書館で作られたプロトコルを汎用的な用途に使えないものかという観点から取り組み、調査から入っていったという経緯があります。
技術的に追った時期がございまして、その時の私なりの問題意識等を含め てお話させていただければなと思っております。お時間１５分ということ で資料はちょっと多いのですが、基本的に要点だけ部分的にかいつまんで お話させていただきたいと思ております。
まず、一般的にZ39.50とは何かという話や、どのように使用するのかとい ったことを技術的な観点から説明が必要だろうと思っております。ただ、今回お集まりいただいた方々はだいたいこの辺りは把握されてると思っておりますので、市場動向をお話ししたいと思います。
市場動向なんですけれども、図書館システムとしましては統合的なシステ ムというものが従来からございます。現状の海外の主要な図書館システム がどのような位置付けにあるかという点ですが、みなさんご存知のようにほぼ全て欧米の図書館システムにおいてZ39.50をもつということになっております。使い方としましては専用クライアントを使うというのはどちらかというと業務系で使われる場合が多いようで、一般の利用者を想定した場合ですとWEBのGatewayを通されることが大半であるというのも、皆さんよくご存知の通りかと思います。
非常に統合的に図書館システムという位置づけでなくても、小規模な情報の検索という観点からZ39.50を図書館システムに適用するという割とコンパクトなパッケージのシステムというのも海外のシステムには多く見られます。現状では多くのシステムがプロトコル上Z39.50の1992年版の仕様を採用しています。これはINNOPACも確かVersion2、これは非常に海外ではメジャーなシステムですけれどもVersion2の規格を採用しています。現在このVersion2が非常に重要視されているのは、アメリカや欧米の世界では比較的早くから取り組みがされていたという事情がございます。具体的な製品の範疇ですと、まずスタンドアロンの製品、それからツールキットレベルの製品、システムインテグレーションやコンサルタントを行うようなメーカさんが海外ですといろいろあります。CrossnetさんとかIndexdataさんとかツールキットを作られているところがありますし、Blueangel Technologiesなどは主にスタンドアロンな製品を販売されています。ここにあげたのは非常に小さな会社でしてInnovative Interfaceさんとか、その他OCLCさんももちろんですし、RLGさんもそうですが、非常に大きな書誌目録のユーティリティの企業が図書館パッケージを作成されて販売されているというのが非常に多く見られます。
国内の製品市場がどんなものかということを私が知っている範囲内で書きました。企業の名前等は私の調査不足で全部実際を反映してないかもしれないのですが、すみません。私が今把握したレベルですと、まずNIIさんが今現在プロトタイプレベルから盛んに公開されてまさに実務運用にめがけて走っているシステムがございます。ゆくゆくは非常に多くの大学系の図書館とつながりますので、市場的には一つのスタンダードを作りうるところだと考えております。これは目録の形式を含めて考えております。また、ここ3,4年くらいの間に早稲田大学さんとか慶應大学さんとか、東京工業大学さんとかで相次いでZ39.50を導入されたシステムが立ち上がってきております。こういうようなシステムが、非常に草の根的と言うとちょっと失礼なのかもしれませんが、立ち上がってきてその上で新たに相互接続に関する問題意識が浮かび上がるというのは問題解決する一つの典型的なパターンだと思いますので、こういう中から今回のようなミーティングが生まれたというのは非常に意義のあることだと思っております。
最近の例ですと、IBMさんと紀伊國屋さん、あと新日鉄ソリューションズ大分さんのLibVisionというのが一つ開発されております。これはおそらくそのNIIさんの今のシステムとの整合性をまず考えて作られたシステムだと教えて頂いたことがあります。 実際に今からいくつかのメーカさんで実装や連携を検証しながら開発作業がすすめられると思うのですが、Z39.50というプロトコルは規格書見られてお分かりの通りなのですが一般に難解と言われています。OSIのLayerで言うアプリケーション層に相当するのですが、実際には5,6のLayerからOSIを抽象化された用語で記述されておりますので、一般の技術者が理解するのもなかなか敷居が高いというところがあります。エンジニアは確かに理解する必要がある程度はあるのですが、その上でおおよそに至っては国内の図書館で日本語を扱う相互連携をどういうふうに確立していくかということも、プロトコルのさらに上の層で重要な課題となっております。これには、非常に地道な実証作業と経験に基づいた仕様への反映が必要になります。これは、アメリカでは92年から94年にかけてテストベットという環境が作られて、その成果がISOの規格の一部に含まれておりますので、こういう地道な作業も日本においても必要になるんだなぁと改めて実感しております。
ちょっと今回Zというテーマでみなさんお集まりにいただいて議論される場が作られた訳ですが、もちろんこれもZ単独のシステムということではなく、ゆくゆくはILL図書館間の相互貸借のシステムと結んで使っていく形が、非常に近い将来のあってほしい形態だと思います。ともに情報検索、ILLに関してはISOのプロトコルとして規格化されておりまして、ILLに関してもにJISになるという話はきいてたので、もうなったんでしょうか。いずれにしろ主要な２つの図書館情報学の記述プロトコルがJISになったということで、これらが国際標準に基づく図書館システムが普及する一つのきっかけになるだろうと思っております。Z39.50とILLを連携するやり方として、現在プロファイル
が用意されております。基本的にZのプロトコルを用いて検索、そしてデータMARCレコードを返戻してどこに何があるかという所蔵情報を確認するところまでがZのプロトコルが担当します。その後注文・貸出・返却、この一連のILLの作業がその後に続きます。これらが連携して、一連の検索と貸借をつないだネットワーク経由の連携処理が実現することを想定した規格です。当然このようなシステムである以上、異なるベンダーさんで作られたシステムで相互接続ができないと事実上運用できないということですので、こういうところにも懸案の相互接続の検証パスということが重要な役割を持つということになります。
ILLプロトコルに関しては、今回のテーマからはちょっとずれるかと思うのですが、現在はISOのプロトコルで定義されています。ILLプロトコルは全サービスがメール型の非確認型サービスと言われるもので構成されております。これがZのプロトコルと非常に異なる点でして、Zのプロトコルとは基本的にクライアントからサーバーに要求を投げて、サーバがそれにどのように対応したかということを結果として受け取らないと、次のSTATEへは移れない、移らないというのが基本的なサービスの仕様になっております。ところが、ILLはこのようなことにはなっていませんで、1ILLのサービスサイトから、別の2のILLのサービスサイトに要求が投げられた段階で1ILLサイトは状態を遷移させるという仕様です。なぜこのような仕様になったかというのは、非常に歴史的な経緯がありまして、実は電子メールを使ってILLサービスを行うという過去の流れから、このような非確認型サービスをとっております。ILLプロトコルは現在蓄積交換型のメールで行うのが一つの主流なのですが、これは今後Zのような確認型サービスに移行する可能性が出てきています。これは現在検討されているテーマです。
あと、ともにOSIのプロトコルで難解なところがあります。Z39.50でILLというと一般的にどのような流れになるかというのは先ほどご説明した感じかと思います。基本的にはZを使って蔵書を検索し、注文する一歩手前までいきます。その後ISOのILLに連携するという形です。Z39.50とILLの連携にはProfile 1というのがありまして、このProfile 1で蔵書注文の拡張サービスが定義されています。Profile 2ではILL-Requestというものを使いまして実際には注文を行うProfileのパラメータの使用を定義します。大きくこの２つで検索と貸借というのがつながるということになります。時間もありませんので、国内利用に向けて必要な環境ならび合意として私が考えていることを、ちょっと好き勝手なことになり、申し訳有りませんが述べさせて頂ければと思います。
まず、言語面ですが、現状の検索式や診断レコードは国際化する必要があると思っております。具体的には日本語を扱うときに、８bitのバイナリーデータは扱えるかどうか、また文字集合に関して、どういった文字集合かという符号化方式です。この符号化方式に関しては、ISOの規格としてはUTF-8を使うUnicode系のやつと、エスケープシーケンスを使う7bit-JISのISO2022の２つがISOとしては正式に認められておりますので、私個人的にはシステム間インターフェースで流れる文字コードの符号化方式に関してはこの２つのうちどちらかを使って頂きたいと思っております。たとえば、シフトJISやEUCというのは確かに現実でインターネットを含めて使われているのですが、これはユーザーインターフェースに近いアプリケーション依りに限ってこのようないろいろな文字コードが使われるのは構わないのではないかと思うのですが、基幹的なシステムのインターフェースとしては基本的にISOで認められ、Zでも認知されているこういう符号化方式のどちらかを選択できるような環境を用意するというのがまず検討されるべきことかと考えております。
また日本語の特有の問題としまして、これまでのご発表にありましたように分かち書きとか、ローマ字・かな・漢字等のいろいろな表現方式というのがMARCにございますので、やはりこれはご専門の方々の意見をいろいろと反映させて合意に至れば素晴らしいと思います。この辺りは専門家の方々の意見がいろいろあると思いますので、是非日本語の場合の検索式のあり方というのを検討していただければよいのではないかと考えております。 検索式におけるアクセスポイントやレコード構文これもいろいろと細かい違いがあるというご発表がありましたが、この辺りも検討するに非常に有意義な課題だと思っております。
基本的に欧米の人達はアジア圏のことを別に考えておりませんので、やはりアジア圏の日本がアジア圏の一つとしてマルチバイトの言語圏でZを扱うときどうすればよいかというのを提案していくというのは欧米の人達にとっても知らなかったことが明確になっていく非常によい機会なのではないかと思います。
次にMARCにつきまして、私なりの感じていることを若干申しますと、海外でMARCというとISO2709に準拠したものを指すということです。これに準拠してない場合は、別の書誌目録のフォーマットという認識でいます。日本語の表現可能なMARCとしまして、もちろん国立国会図書館さんで作られておりますJapan/MARC、それから日本語のもう一つの候補としましてはUSMARC現在MARC21となっております。この２つがございます。NIIさんの方で今回取り組まれているMARCの一つにMARC21というのがあるというのを聞いて、非常に素晴らしいと感じました。MARC21の良いところはUTF-8で記述できるというところです。UTF-8を好き嫌いというのは何かとあると思うのですが、一つは統一的にアジア圏の国々の言葉もMARCに載せることができるという点で現実的な選択肢として有望なのではないかと思っております。
また書誌目録の観点からいきますと、現在NACSIS/CATの書誌目録というのが大学系図書館ではスタンダードになっておりますので、こういうものもZで扱うときには新しく登録するという作業を行えば十分にZで扱っていくことができます。この他にMARCベンダーさん固有のMARCがございます。これは多分NIIさんでも同じように作業されているかと思うのですが、新規にレコード構文を登録する場合はどうすればよいかということですが、これはZ39.50のメンテナンスエイジェンシーに必要な手続きを申請して、登録してもらうという作業をふめばよいと思っております。レコード構文を識別させなければいけないとか、属性集合やその拡張を定義して登録すること、要素集合を何にするかということが基本的なことになると思います。所蔵レコードを含む場合、ILLとの連携がもしあれば非常にいいのではないかと思っております。
こうしたことが技術的な仕様を決めることよりも、もしかすると非常に大きなウェイトを占めるかもしれないのですが、一端仕様としてこういったものでどうでしょうという皆さんのいろいろな意見を集めて仕様を作っていく過程で、合意を作っていく作業が一番重要で労が多いのですけれども、その結果得られる果実というのは長期に渡って享受できるものではないかと思っております。ここで非常に時間をかけて合意を形成することに力を割くということが、このようなみなさんお集まりいただくような機会に期待されている作業ではないかと思っております。
次に、実運用システムの課題として、これも私なりのコメントなんですが、ベンダー間で相互連携性を検証していく必要があると思っております。具体的には、現在NIIさんの取り組みがございますので、NIIさんで公開されますレコード数や将来の相互連携数の規模を考えますと、システムの構築が一つの非常に有望な実証事例になると考えております。ネイティブなNacsis/CATのレコードフォーマットがネットワーク上流通するというのが一つのキーになるのではないかと思います。今後相互連携のための仕様を作成されるということですので、そういう過程に期待したいと思っております。
日本語対応のシステムに関してはユーザーにフレンドリーな日本語クライアント、具体的にはWebのGATEWAYが主になるかと思いますが、こういうところに凝られるとだんだん使われる方が無意識なうちにこういうシステムを使っているという形で普及が進むのではないかと思っております。Z39.50の開発動機を今一度思い起こしたいのですが、基本的にはネットワークで共同目録作成作業を支援するという、各図書館もしくは書誌ユーティリティの方々のネットワーク経由での共同目録作成作業を支援するところから、このプロトコルを開発しようという動機が始まっておりますので、そう意味からいきますと今回のNIIさんの事例はまさにマッチする、非常に私としては分かりやすい事例だと思いますし、もちろん検索という観点からもこのコンセプトの成果がうけられるものと考えております。
最後に簡単にZ39.50の将来、動向なんですが述べたいと思います。今現在Z39.50はV4のDraftが作られてレビューが行われております。この過程でOSI準拠という文言が外されます。OSIという文言がついたのはISOの規格に載せるための政治的理由があったためで、現在そのISOの規格になっておりますので徐々にこういう縛りをなくしていく方向で規格改訂も進んでおります。もう一つはZNG-Z39.50 Next Generationという全く違う情報検索のあり方を検討する動きがあります。これは現在Webでメインストリームと呼ばれる、あるいはメインストリームになると予想される規格プロトコルです。こういったものを使って簡易に情報検索をやりたいというコンセプトからこういう動きが始まっております。有効な技術といたしましてはXML、URI、SOAP、UDDIとかHTTPです。Statelessでいいのではないかというのが一つのコンセプトです。基本的に古典的というか、traditionalというか、図書館系の情報検索は状態管理を行って、セッションを積み上げながら情報検索の処理を行うというのが多分traditionalなシステムだったのではないかと私は考えている訳ですが、Webが普及したおかげでちょっと考え方が変わりつつあります。使いやすいインターフェースを、しかも作りやすくといった観点から技術的な見直しを図りたいというのがNext Generationの動きでして一つはそのStatelessでやりたい。それからASN.11やBERのOSIの難解な符号化方式や抽象化された用語はできるだけ使わないようにしたい、ただしExplain機能と呼ばれるZのサーバ自身がどういうデータベースをもち、アクセスポイントを持ち、どういうレコード構文に対応しているかという自分自身が語れる機能を是非とも普及させたいというのがNext Generationの一つのテーマです。これは現在のZのサーバでは非常に実装が少ないと言われているExplain機能なのですが、これを是非普及させたいというのが大きな目玉になっています。その他、抽象構文やスキーマは従来どおり使用を続けます。一応LCの人に言わせればメンテナンスエイジェンシーには公式には参加していません。がみなさんボランティアで参加しています。
将来としてもう一つなのですが、WEBと親和性の高い、かつ実装が簡単なプロトコルが欲しいというのが技術的な動機です。Statelessでいいじゃないか、ただ必要ならばセッション管理もつけましょう。ただし明確な規格は含めないということで作業は進められております。各目録規則を適切に扱うという前提は崩したくないですし、目録の規則と流通の方式、一般にMARCとZのプロトコルのような規格というのを、独立して相互に発展させて組み合わせていくような形は守っていきたいというのが彼らの考えです。
ただZが今後なくなるのかというと私はそうとは考えておりません。Zのプロトコルは長年の図書館界における情報検索の集大成の一つだと思っております。非常に検索式やレコード構文において高度なフレームワークを持ち、特筆すべき拡張性を持っておりますと私は感じております。ネットワーク図書館というコンセプトでは、今後とも洗練されたフレームワークであり続けるだろうと思っておりますし期待しております。
時間オーバーしてしまいましたが、かいつまんで思っていることを発表させて頂きました。どうもありがとうございます。
[入江]ありがとうございました。
[入江]大変わかりやすい解説でポイントを解説していただいたので、聞きたい質問があると思うのですが、質問があられる方挙手して頂いて。
Ｑ：[酒井]プロファイルの中でバスプロファイルというのが図書館向けにあるかと思うのですが、それを取り上げられてないんですけれども、それは一般的ではないんでしょうか。
Ａ：[石田]いえ、あの一般的というかいくつかあるんです。例えば、バスプロファイルは確かイギリスの図書館で作られているプロファイルの一つですし、ドイツで作られたものもありますし、ニュージーランドやオーストラリアで作られたものも、最近テキサスで作られた各ライブラリーグループの中のプロファイルがあります。そういうのは、どちらかというとコミュニティレベルでプロファイルを規定して、それを使っているという前提で相互接続をするという流れですので、ちょっと個々には取り上げなかったのですが、プロファイルベースの相互接続性の検証というのは欧米では大きな流れです。個々のライブラリーグループの中で行われています。
プロファイルの話が出たんですけれども、インターナショナルとして位置づけられるプロファイルというものを検討する動きがあります。レジストリという機関を作りまして、そこに登録して、どのプロファイルを使うか、実際にはZを使う上でどういうスキーマを使うかという識別子を交換しながら、お互いにどのプロファイルを使うかということを知った上でその後のZのやりとりを行っていくわけですが、そういのも例えば今回のこの日本におけるやり方として、こういうプロファイルを日本版のプロファイルを作るというのも有望なやり方だと思います。
[酒井]ありがとうございました。
[入江]他に質問のありましたら。
Ｑ：[米沢]将来の話で非常に興味深く、私全然知らないことを聞いて面白いなと思ったのですが、我々NIIでCATPというものを作ってまして、それも何となく近いなぁと思って心強く思っているのですけれども、レコード形式としてダブリンコアというのが最近話題になっていますけれども、そういったものをいれるという動きはないんでしょうか。
Ａ：[石田]ダブリンコアに関しては２年前になると思うのですが、ダブリンコアて１５，６個くらいのレコードセットがベースにあるんですけれども、非常にベーシックな要素で、一つはそういう要素が既にZで中で使われるプロファイルに含まれているということから、別にしてダブリンコア専用の応用プロファイルを作る必要があるかどうかという議論がありました。現在はアメリカの行政情報を扱うプロファイルの中に拡張して埋め込んで使うという認識がその時の議論の結論だったと思います。ダブリンコアのような非常に汎用的な基本的な要素っていうのは、実際には、じゃあダブリンコアて言い出すと実はそれに相当するものは既に入っているということがいろんな分野であると思うんです。Zの場合は行政情報のプロファイルというのが94年くらいにできあがってまして、その中でダブリンコアの要素を含めさせた、含めているという再認識みたいな感じかなぁと思っております。
Ｑ：[佐藤]今、米沢先生の方からもあったNext Generationに関してXMLと言う話がありましたけれども、MARCというのは非常にトラディショナルなレコードシンタックスというか、逆に言うと素人目にはとてもとてもという様な部分もあるわけです。基本的にMARCを例えばXMLとharmonizeしようとか、そういったMarc uplanguageとharmonizeさせようという動きも北米にはありまして、むしろそういったレコードシンタックス自体の柔軟性というか、DTDを交換すれば基本的にはデータのやりとりができるというような動きというのはどうなんでしょうか。つまりMARCとしてもあるけれども、一つは書誌レコードをXMLのような非常に可搬性の高い外形式といいますか、そこに埋め込んでやりとりするという動きはあるんでしょうか。
Ａ：[石田]私も厳密にZNGの話を、多分昨年末くらいから向こうの内輪のメンバー内で議論が立ち上がって検討し始めて、このような簡単なペーパーをホームページに出しているんですが、今、佐藤さんが言われたような、XMLでMARCを埋め込んでいく作業というのは非常に傍目にみても大変な作業だなと思います。そういう動きに関しては、MARCの表現形式をXMLベースで完全に別に表現してしまうという、内容的・意味的には同じでも表現的には全く別物で流通させるというのが、まずあります。埋め込んだ形で従来のMARCを流通させることについてはちょっと私も把握してないんですが、XMLを使う一つの利点というのはWEBとの親和性というのがもちろんあるんですが、レコード構文としてXMLベースで統一的に扱うように無理矢理にでもすることによることによるメリットがいくつかあるんだと思うんです。それと検索式の表現にXMLを使う、APDUに相当するものですか、Z39.50の従来のプロトコルでいうapplication protocol data unitに相当するものをXMLで表現して、流通するオブジェクトにSOAPを使っておこなうと、SOAPっていうのはRPCをモデルにしたものなんですが、それにのせてXMLのリクエストを書いてレスポンスを受けるという表現をWEBに親和性のある情報検索のメカニズムを作ろうとしています。ちょっと話が横にそれて申し訳ないんですが、MARCに関しては全く違う表現で書いちゃおうというのがあると思います。私もその流れを知ってるくらいしかなくて、ほんとに詳しい話はまだ存知あげていないところにあります。
[入江]ありがとうございました。次世代の話になるといろんな意見がみなさんあられると思うんで、ただ去年ダブリンコアの話でいくと早稲田さんと慶應がちょうどここでOCLCがいらしてダブリンコア、コークオンパレードというセッションを一回やっています。そういう話は今後の中でも出てくると思いますし、今後の話についてはいろいろ論議をしていければと思いますが、基本的にこの会議の課題としてあるこれからすぐ作るZの標準化という意味では、先ほど石田さんがおっしゃった労多い作業なり、つめていく作業と、図書館側の専門家と言われる作業も多いと思いますので、そこはきちっとやりながら、逆にそこのところをきちっと合意しなければいとなかなか次に行けない世界かもしれないところもあると思っていますので作業を進めていきたいと思っております。MARCフォーマットの話がでましたので慶應の酒井さんMARCフォーマットについて何かありますか。
[酒井] 申し遅れました。慶應義塾大学の酒井由紀子と申します。よろしくお願い致します。私、慶應義塾大学で動いているKOSMOSⅡにシステム移行する時に書誌データのところのワーキンググループの主査をいたしておりました。その時に、私の中ではUSMARCでいこうという確信がありまして、それを入江ですとか丸善の佐藤さんにご説明したところ合意を得られまして、日本語の書誌も含めてUSMARCフォーマットでいきましょうということで実現しています。それは国際的に書誌を流通させたいという思いがカタロガーとしてありましたので、それを実現したかったということがあります。真の意味での国際標準を採用したいという理由がありました。例えばUNIMARCはスタンダードのスタンダードでexchangeするためのスタンダードでしかありませんし、また日本人の日本人による日本のための書誌フォーマットがいくつかあるかと思うのですが、それはやはり私の中では選択肢にはいらなかったということです。実際に作業的に行ったのは、実は慶應大学は早稲田さんに先を越されていましてWINEのデータが既にOCLCにコンバートされている、今既に50万近くになりましたでしょうか、２回のPhaseにわけてコンバートされていると思いますけれども、その書誌を欧米の方達が使っているという実績がおありです。当時、私たちが検討を始めたときに既にそのコンバート第１Phaseが終わっておりまして、また他にRLINの方にもTRCのデータがコンバートされつつあった状況で、その辺りで私が一番注目していたのは実際にUSMARCを使っているアメリカのEast Asian Libraryの方々の反応というのを参考にして慶應義塾のフォーマットあるいは入力基準といったものを形成していきました。その時に一つ問題になったのがMarcフォーマットというのはAACR2という目録規則と切っても切り離せないものがありまして、それを日本語の書誌にも適用するかという問題が現場のカタロガーの間でありました。結論からいうと、ある程度妥協はしたのですがAACR2でいこうということで落ち着いています。そこで実際に問題になったのは、例えばNOTE。私はNOTEを英語で書けないの、というふうに現場に提案したのですが、それは勘弁してくださいというお話でしたので、もちろん皆さんご想像のように1からオリジナルでカタログを現場が取っているわけでは今の時代ございませんので、例えばJapanMarcフォーマットでRLINの方からTRCMARCの内容が流れてくるという時代ですので、それをいちいち英語に全て直すという作業はできませんのでそこのところは妥協したということです。他に欧米の方で、カタロガーとして日本の書誌をUSMARCフォーマットであっても使うときにやはり障害になるのがContents disintegrationの違いとおっしゃってましたけれども、NOTEのところもそうですけれども先ほどでました分かち書きの問題ですとか、あるいは大文字Capitalizationの問題は避けて通れない、あるいは日本の書誌にはLC Classificationがないじゃないか、LCのSubject Headingがないじゃないかということで実際のカタロガーの方が使うときには、かなりModifyあるいは追加するという作業が必要だということがわかりました。ここのところはやはり問題だと思います。Z39.50を実現するにあたっては私はやはりUSMARCフォーマットを元にした方がいいのではないかと考えていますけれども、それは先ほどからメーカの方がおっしゃているようにシンタックスの統一ということだけでなく、カタロガーの間でのsemanticsの統一見解shareするという意味でも一番いい選択なのではないかなと思っています。
関連して一つ提案なのですけれども、Z39.50というと、それをあげれば予算も通るのではないかと思われている方もいらっしゃるのではないかと思うのですけれども、一つ図書館として考えていかなければならないのは何のためにZ39.50を実装するのかということを、ここのメンバーにお願いしたいのは、システム担当の方は現場にお話いただきたい、あるいはメーカの方は何のために使えるんだということを是非顧客の方々にご説明いただきたいと思います。それはもちろんILLの業務であったり、先ほど私が一つ例にあげたカタロガーが使えるということがあるでしょうし、あるいは拡張OPACということもあるでしょうけれども、現場で何のために使えるのかということを是非強調して目的が何なのかということをはっきりしてからシステムの構築という作業にうつって頂ければと思います。長くなりましたけれど申し訳ありません。以上です。
[入江] ありがとうございました。石田さんもお話になったし、酒井さんもお話になったと思うのですが、記述の問題そのもの、このまえRLINでDBDをもってきたときに、DBDのNOTEはドイツ語だと、OCLCのNOTEは英語だと、どっちの書誌が欲しいのっていうと、できればOCLCが欲しいってなるんだけど、でも話をするとRLINはドイツ語のデータを引く人が何でドイツ語のNOTEじゃダメなんだと言うという話があって、その辺のところがいくつかあると思います。早稲田がINNOPACでもともとWINEがカタカナだったという選択で自動変換でローマ字にしたときのいろんな問題をよくおっしゃいますけど、ローマ字と言っているのがグローバルなindexだとRLINはよくそう言っちゃうんですけど、ローマ字が統一されなかったら日本語引けないとか言われちゃうんで、その辺についてはこれから図書館側の問題としては考えていかなければならないと思っています。他にご質問あるでしょうか。
[入江] 慶應の加藤が参っておりますので、簡単に挨拶をお願いします。
[上田] 同志社大学の上田です。はるばる京都からまいりました。いろいろメーカさん知ったお顔の方がいらっしゃいます。ビジネスチャンスのターゲットになるのではないかと思いますけれども、うちは次期システムの導入について検討を始めたばかりで、こちら側のコンセプトをしっかりしたものを作りながら、メーカさんのお考えも見極めていきたいというふうなことを考えまして、入江さんのお誘いで参加させていただきました。今後ともよろしくお願いいたします。
[入江] ありがとうございました。菊池さんお願いします。
[菊池] 明治大学の図書館菊池です。よろしくお願い致します。
[入江] 菊池さんは僕が平和にいたときよく資料をもらいに行ってた人なんでこうなっちゃうと何か面白いなと思っちゃいます。またよろしくお願いいたします。佐藤さんおねがいします。
[佐藤哲] 上智大学の佐藤と申します。この中で私が一番図書館のことよくわからないのだと思います。4年ほど前にとんでもないところから図書館に来まして、加藤さんとか入江さんにいろいろ教えて頂いてここまで来たと言うところも若干ありまして今回声をかけていただいて参加するわけですけれども。若干こういうと申し訳ないんですけれども、少なくとも私の大学の図書館の情報の中身からいたしますと私自身は絶望的かなと思っておりますので、ここで標準化してもらったものを製品として利用させて頂こうかなと思っているのが本音のところでして、図書館システム今見直しもやっていますけれども、Zとは何かというのも館内ではZのZが何だか分からないといったところが本音です。この後誰を参加させたらいいのかも分からない状態でして、今話きかれて、酒井さんからZをいれるんだったらよく考えてくださいという話もありましたが、確かにその通りで上には通りがいいんです。Z化するんだと、これが国際標準だと、NIIさんがいれるんだというと通るというと恐ろしい状況が確かにありますので、一つここで皆さんに頑張っていただいてその成果をいただきたいと思っておりますのでよろしくお願いいたします。
[入江]ありがとうございました。中崎様お願いします。
[中崎] 立命館大学の中崎でございます。
今、立命館ではZ39.50に関しては開発中ということでして、本来であれば2000年4月からということであったのですが、諸々の事情で遅れております。是非この研究会で得た知識を存分に使って開発の方に取り組んでいきたいと思っております。今後ともよろしくお願い致します。今日はどうもありがとうございました。
[入江]安本さんお願いします。
[安本] 関西学院大学の安本です。よろしくお願いいたします。お話伺っておりまして、この中で一番遅れている学校じゃないかと確信を持ちました。今からこの研究会で取り組んでいこうという内容については関西学院大学では全く未着手未検討の状態です。今から勉強させていただきますのでよろしくお願いいたします。
[加藤] 締めということかもしれませんが、途中中座しまして申し訳ありませんでした。先ほどOCLCの話が出ましたけれども、この元々は私たちがOCLCに行ったときにOCLCのコークの事業展開を日本でどこか発表できるところはないかということで、そのAssignmentを持って私帰国いたしまして、早稲田大学にお話をしたら早稲田がぜひ乗りたいということで、早慶でまさにこの場所なんですけれどもそんな話をしました。その時に今後やはり今流行りで言っていますコンソーシアム、一つの大学ではできないのでいろいろ探ろうといった結果が今日ここに結実したという感じがしています。先ほど酒井さんもおっしゃったように、まさにユーザーなしでは物が考えられない話ですから、事業計画・事業目標をしっかり収めて、その中で開発していっていただきたいし、まさに日本側の情報発信基地としての一つの役割があると思っております。まだ国からも援助がある訳じゃありませんし、あるいはNPOかもしれませんし、これからこの研究会がどういう形になるかわかりませんが少なくとも日本側で共通の認識の中でグローバルに適用出来る日本のtypicalなものを作っていくというようなことは考えていきたいと思っております。近いうちに、まだ今模索中なのですけれども、アメリカの大きな機関と共同開発をしていくと、共同研究をしていくというようなところまでこの研究会をもっていけたらいいかなと思っております。ただそれは確約できないんですけれども思っております。それから入江にも言っていることなんですが、こういう図書館界で研究会ってよくおこなわれるんですけれども、立ち上がりはわりかし簡単に立ち上がるんです。気が付いてみるとあれ、どうしたっけっていうのが結構あるんです。そういう形にだけはしたくないと思っていますので今後メールを中心に議論をやりとりするかと思いますが、一定の期間どこまでやったら一回終了ということを認識しながら、そこでうまくアウトプットが出れば次の段階というような進み方で行って頂きたいと思っております。大学、企業、メーカ、国と大きな連合体が少なくとも今日はスタートした訳ですので是非みなさんご協力お願いしたいと思います。よろしくお願い致します。
[入江] ありがとうございました。各大学の方で、参加者で挨拶いただいてないところがございますので、同志社上田さんの方から一言ずつ。
私3年間図書館を離れていまして、この4月にまた図書館に戻ってきました。3年間大学のネットワークやっていたんですけれども、図書館戻ってきまして、システムまわりのことを聞きますと、3年間の変化というのはとても大きかったなというふうに感じてます。浦島太郎になったような気持ちでして、今回このような会議にお誘いいただいて、4年くらい前にZ39.50に関わりを持ったことがあるんですけれども、もう一度勉強させ直していただきたいと思ってますのでよろしくお願いいたします。