研究会報告

LCへの提案について

まず、この行動についての意義と目的なんですけれども、グローバル標準を視野にいれて日本の標準について議論して推奨プロファイルを作ってきました。この作成した日本の標準というのを実際にグローバルに活用していただかないと意味がございません。そのために、実質的に世界標準を作成維持しているLC、議会図書館に発信しようということです。それから、その目的というのは存在を認知してもらうということがまず一つ、それから実際に具体的なフィードバックを受けて実際に使えるものかを確認すること、そして必要な改訂や残された問題解決の材料としたいと思います。最後には、使えるものとして世界及び国内へも広げていかなければなりませんので、その一助としたいと思っています。

具体的な方法なんですが、これから作業に取りかかって、2003年の2月くらいに具体的に提案をするということを目的にしたいと思います。誰がというと、このライブラリーシステム研究会からです。何をということですが、一つはこのライブラリーシステム研究会の目的と活動について、背景的な情報を提示しなければいけないと思います。具体的には2つあります。Z39.50の推奨プロファイルそのもの、そしてもう一つは目録標準に関する問題点というのが継続的に検討してきています。これについては、まだ最終的に結論を得ていないものもありますが、それもやはり、この時点で提示したいと思います。それぞれの問題についてフィードバックを要請するということです。このWHATの部分について具体的に確認いたします。まずライブラリーシステム研究会の活動と目的ですけれども、図書館システムのグローバル化に対応するために、システムライブラリアン、図書館システムベンダー、書誌ユーティリティや研究機関の有志によって研究会が組織されています。最初のプロダクトとして、日本におけるZ39.50のプロファイルについて論議して推奨プロファイルを作りました。先ほど申し上げましたように、関連する目録標準については継続検討中のものもあります。まず、推奨プロファイルについてですが、前回の研究会、及び前々回でも入江の方からお配りして説明いたしましたけれども、一つのものが出来ています。特徴としてはグローバルに利用できるインターフェースであることと、もう一つは国内でも普及可能であるという特徴があると思います。具体的には、グローバルという意味では文字コードはUTF8を使う、それからレコードフォーマットはMARC21のタイプ1に準拠する、分かち書きインデックスを持つことを前提としている、同様にローマ字インデックスを持つことを前提としている、というものです。国内では、国内インターフェースはMARC21の拡張によって対応が可能である、そしてNIIの提供するターゲットと調整可能である、ということで既にプロファイルができあがっていますので、それをそのままLCのZ39.50の部署へ提案するということでよろしいかと思います。

次に継続検討中のものについてですけれども、これはどちらかというと目録標準の問題になってきています。たとえば件名、これについては日本の図書館のプラクティスでは、もしかしたら言い方が悪いかもしれませんが、これまで軽視されてきています。一方、欧米のプラクティスでは適当なSubject Headingのついていないデータというものの評価は低いです。という認識までは我々はつかんでいるところだと思います。これに対してLCのSubject Headingを付けた方がいいのではないかという議論は見えてますけれども、全員のコンセンサスを得られたというところまでは至ってないかと思います。次にヨミのデータです。これは一般的にヨミのないデータがあります。例えば300、Physical Descriptionのところですが、これについてヨミを付けるかどうかといった細かいところまでは、まだ議論してないと思います。また非ローマ字のタグの持ち方があります。これは70年代にアメリカで始まった880というタグに非ローマ字だけを集めて記述するという手法を維持するかどうかということについて、まだ具体的に議論してないかと思います。これについては、この後に国内交換フォーマットということで丸善の佐藤さんからお話があるかと思います。ということで継続検討事項の中で目録標準の問題についてはZ39.50とは別の次元で国内外で議論が必要であるかと思います。ただ、何も方向性がないままに提示しても仕方がありませんので、ここで、ある程度議論して一定の方向性、たとえばLCSHを付けたらどうだろうか、というような方向性を示した上で、LCのMARCの窓口に投げてあげるのがいいのではないかと思います。それから、もう一つ継続検討事項として日本語の問題が大きいということを我々は確認しています。具体的には、ローマ字の標準がない、あるいは分かち書きの標準がないということです。ただ、これは図書館に限らず、国内唯一の標準がないということですので、一応の指針を示す必要があるかと思いますが、別の次元で、国内の議論を先行させる必要があるかと思いますので、ここで急にLCに提案ができるという段階ではないかと思います。そしてフィードバックの要請です。推奨プロファイルについてはグローバルな利用が可能かということの確認、目録標準の問題についてはグローバルな観点からプリフェランスがないかということのフィードバックを要請したいと思います。先ほど申し上げたように、日本語に特化した問題、ローマ字分かちについては国内の論議を優先させたいと思います。そして、どこにどのようにということですが、Z39.50についてはMaintenance AgencyがLCの中にございます。そしてそこで推奨プロファイルをリストにしています。そこに我々の作ったものをリストにしてください、ということを依頼すればよろしいかと思います。もう一つMARCのことですがMARCのフォーラム、メーリングリストがあります。こちらの方に目録標準についての問題点について一定の方向性を示した上で広くコメントを求めてはいかがでしょうか、ということが私の提案です。実は、このやり方というのはいくつかオプションがあります。まずZ39.50についてのオプションなんですが、プロファイルとしてリストしてもらうだけではなくて、さらにZIG、Z39.50 Implementors Group の推奨をもらうですとか、IRPと呼ばれる Internationally Registered Profile というところの承認をもらうという、一段階二段階上の段階もございます。今回はリストをするというところまでを一つの目標にしたいと思います。その他にRegister of Implementors ということで、実装している団体とか組織をリスト化するということを、LCのMaintenance Agencyでやっています。こちらの方では具体的に国内の実装した団体ができたところであげるですとか、これから作業しなければならないこともあるかと思いますので、今後の問題だと思っています。それからMARC21のことですが、LCの方に窓口が三通り用意されています。一つは先ほど申し上げましたメーリングリストに、まず投げてみるということが一つです。その他に、アドバイザリ委員会というのがあります。これはALAアメリカの図書館協会のMARBIと呼ばれる委員会ですとか、National Libraries、アメリカのナショナルライブラリーも入っています。カナダ、オーストラリアの国立図書館も入ってます。それから大規模なOCLCとかRLINといった書誌ユーティリティも入っています。こちらの方の委員会に提言をするという可能性もあります。もう一つがMARCの標準のオフィスへ直接提言をするということもあります。しかしながら、先ほど申し上げたように、我々でもまだ結論が得られていないということでもありますので、まずはMARCのフォーラムに投げてみてはどうかというのが私の提案です。

そして最後に、期待される結果と今後の展開です。LCを中心に研究会の活動とプロダクトが認知されるということが先決だと思ってます。実にLCというのは日本のことを知っているようで知りません。例えばMARCのメーリングリストで二年ほど前に日本のMARCの標準とは何なのかという質問に対して、JAPAN-MARCがあって、確かUS-MARCとのマッピングしたはずだという答えだったんですね。その時に問うてる人はNACSISのフォーマットがJAPAN-MARCのフォーマットなのかというような言い方だったんですけれども、それについて詳しく答えたのは私で、その他に日本人のポストは一件もございませんでした。

そしてフィードバックを受けて、Z39.50の標準の整備を進めると同時に国内での広報、実装を進めるということ、そして目録標準については継続検討事項については指針をまとめて国内及びグローバルコミュニティにもう一度提案をするということです。先ほどから申し上げているようにローマ字と分かちについては日本語の問題として別途検討する必要があると思っています。以上が私の提案と確認でございます。

[入江]付け足しではないのですが、慶應がRLGのメンバーになったことに伴いRLIN経由でZ39.50のテストをしないかという話がきています。ご報告したいと思います。NIIさん、Z39.50を立ち上げてどうですか。

国内交換のために求められることということで、何か手はあるの？ということで、とりあえずMARC21のマルチスクリプトモデルというのがあります。LCのサイトにすると、たった1ページのところにあがっている内容なんですが、ここにMARC21で多言語をどう扱うかというモデルの提案がされています。提案というか一つの考え方だと思うのですが、大きくはこの考え方には2つありまして、いわゆるモデルAと言われる考え方とモデルBと言う考え方があります。モデルAについては、この一年間当研究会が今まで議論してきました880というAlternate Graphic Representationというフィールドを使ったラテンへの字訳・音訳による記述と漢字の記述を併記しようというやり方です。この後例が出てきます。この後の例の1、2のところではラテンへの字訳・音訳をレギュラーフィールド、880以外のフィールドに記述するというもの、3つ目の例としてあがっているのが非ラテン系言語による通常記述ということでレギュラーフィールドに直接ヘブライなどを書いてしまおうというモデルがあがっています。それからモデルBの方は非常にシンプルな多言語記述という形で、リンクフィールドを持たないでレギュラーフィールドにどんどん母国語を書いてしまおうというような例です。モデルAの中に出てきます880と、それに伴うコントロールサブフィールド$6についてちょっと簡単にLCのページにあったものを列記してみました。$6というサブフィールドは他のサブフィールドとちょっと違って、フィールドをコントロールするためのサブフィールドということになっています。特に、ここはリンケージ、レギュラーフィールドと880の間のリンクを表示するフィールドというふうに定義されていまして、最初にLinking tagということでリンクする通常タグがはいっていまして、次にOccurrence Numberということで1レコード中の各リンク関係を識別するための二桁の番号、数字がはいっています。これはシーケンスでなくてもユニークであればいいみたいですが00はレギュラーフィールドがなく、リンクしないというオプションがあるようです。その後ろはScript Identification Codeということで、880に実際に書かれている記述の識別コードということで、例えば(3と入っていればそれはアラビックだよと$1と入っていれば、それはChinese,Japanese,Koreanだよ、と(2と入っていればヘブライだよというようなことが定義されています。最後のフィールドオリエンテーションコードは記述の向きということでアラビア語のように右から左へ各言語をrをつけて表しています。それを踏まえてLCにあがっているモデルAのデータです。LCのページが分かりにくくて、どこかにいい例がないかなと探したら、たまたまアメリカの図書館システムを作っている会社ですけれどもLibrary Corporationというところが非常にきれいなMARC21のマニュアルをWebにあげていらっしゃって、ちょっとだけ借用しました。これが最初のラテンへの字訳・音訳によるフィールド記述、これが一般的なよく見かける記述の仕方です。今回ライブラリーシステム研究会でプロファイルの中に推奨したMARC21のスタイルというのは、まさにこの形でレギュラーフィールドにローマ字を書いて、880のところに日本語の漢字仮名混じりを埋め込んでいくというやり方です。例2はあまり変わりはないのですが、右から左へ読むものの例です。例3の方はレギュラーフィールドにアラビア語を書いてしまうというような書き方で、ただし880に字訳したラテンをそのまま書いていくというスタイルです。もう一つモデルBのシンプルというのになりますと、レギュラーフィールドの中にラテン系と非ラテン系が混じって入ってしまうというような書き方があるというのがLCが言うところのマルチスクリプトのモデルの例です。なるべく、これをくずしたくないなという方向で国内向けの考え方で整理したんですけれども、日本語の記述を想定すると、モデルBはシンプルな多言語記述だけれどもリンクをもっていないから、カタカナヨミやローマ字ヨミをどういうふうに記述したらいいんだろうかと、場合によってはサブフィールドを拡張するか、もしくは二桁しかないインディケータを拡張するしかないということで、これはちょっとやりにくいなぁというのがモデルBということで最初に消去しました。実はモデルBがいいんじゃないかと最初は入江さんとも話していたのですが、よくよく考えると、これはやばいぞということになり、モデルAの1と2の方を検討しました。まずモデルAの例1なんですがラテンへの字訳・音訳によるレギュラーフィールドなんですが、いわゆる北米におけるCJKレコードの標準的な記述の仕方ではあるんですが、ご存知のようにカタカナヨミが並列して記述しにくいと、記述しにくいというかほとんど記述できないと、ローマ字と漢字仮名混じりは何とかなるという形です。もしこれでカタカナヨミを入れるとするとサブフィールド$6のScript Identification Codeに日本語のカタカナヨミとか日本語のローマ字とか日本語の分かちとかを付けてもらうと書けるかなぁという感じはしました。もう一つ、こちらの方が大きかったのですが、レギュラーフィールドへのラテン以外の記述が制限されるということで、300がもとのデータが日本語で書いたものしかないと、「1冊」とかですね。改めてローマ字を入れるかカタカナのヨミを振ってやらないと、データが作れないというような厳しさがでてくると思います。これは既存のデータをうまく流用するというところでは難しい問題になるなぁということです。続いてマルチスクリプトのモデルの例3の実装かけてみたものです。日本語でレギュラーフィールドを書いてしまおうというもので、実はこういった形を実装しているところでは国内では私の知ってる限りでは２つ、慶應大学さんと早稲田さんです。日本語を直接レギュラーフィールドに書いて、あとはフィールド880とコントロールサブフィールド$6でカタカナヨミとローマ字の対応がこんな感じでとれるかなぁというふうに思いました。カタカナのところは$1を書いて、ローマ字は(Bという形であれば、そのフィールドがローマ字なのかカタカナなのかというのは一応機械は分かるだろうというふうに思ったわけです。実際にいくつか乗せてみるとまあまあ入れるかなぁと思いますが、250、版を書くところのヨミといったところはローマ字にすると落ちてしまうのですが、日本語をダイレクトに書ければ当然書けるだろうという書き方です。300あたりはページ数であれば半角変換をかけてやればいいのですが、一冊とか一巻とか全何巻なんてのが入ってきてしまうので、なかなか一様には変換出来ないところだと思います。こんな形で考えてみました。発表までの間、何度か見直してみたのですが、いくつか問題はあります。例えばOccurrence Numberは二桁なんですが99までいってしまったらどうしようとか、それからどうもLCの仕様を見るとリンク関係は一対一の対応じゃないとまずいのかなぁと、これは実は一対二の対応になってしまいますので、ここだけ見ると掟破りなのかなぁと考えられます。この他に早稲田さんがやってる$8を使うという方法も実は検討対象にはなるかなぁと考えております。今見ていただいているのは私どもの商品データなので生の商売用のデータですが、こういった形で乗せていくことができそうだなぁ、とできれば問題点も含めて今後のいろんな議論のきっかけになればいいなぁと考えております。

[入江]ありがとうございました。何かご意見があれば。

[酒井]慶應大学の酒井でございます。880の問題については実はLCでも一度ディスカッションペーパーというところで、一度880をなくそうじゃないかという議論があったんです。それが98年だと思います。ただその後の結論というのが佐藤さんも私もつかんでいません。途中ではメーリングリストでその方がいいじゃないか、もっとパワフルにシステムを展開できるという人が約一名いたところまではつかんでいるのですが、多分その結論が出なくて、このモデルA,Bそしていろんな例が出てきて、とりあえずいろんな形ができるよというところまでで終わっているんだと思います。ですから、これから私たちがしなくてはいけないのは、日本ではこういうふうに考えられる、私たちはこうしたいと提案していかないと、その他の方々に任せているだけでは国内交換フォーマットに関してもそうですけれども、我々としてはこう考えているということを出していかないと、外国にいらっしゃる方たちが我々の作った書誌を使えない状況というのは、ずっと続いてしまうと思います。そういった意味でも我々の提案は重要だと思います。

[入江]お手元にピンクの紙がいっているかと思いますが、森本さんのTRCデータをRLINに搭載したデータをどう思うのかといった講演会が12月にあります。それはアメリカにいらっしゃる日本語のカタロガーの方がどういうふうに日本語の目録を利用されているか、そこでの問題点等が説明していただけるということです。参考にしながら考えていきたいと思っています。