（メモ）「九州大学附属図書館のディスカバリ・サービスとメタデータ管理」

情報組織化研究グループ月例研究会報告（2012.10）
九州大学附属図書館のディスカバリ・サービスとメタデータ管理
香川朋子氏（九州大学附属図書館）
http://josoken.digick.jp/meeting/2012/201210.html
2012年10月20日（土）

　上記の極私的メモです。
　詳細は上のURLの記録・ハンドアウトを参照。

・九大のディスカバリ・サービスの基本的な設計としては、以下の2本柱のハイブリッド。
　- Cute.Search＝外のコンテンツを見つけに行く＝リンクリゾルバ・e-resource
　- Cute.Catalog＝九大自身のコンテンツへ導く・発信する＝OPAC・リポジトリ・デジタル化学内資料
・採用しているシステムとしては、
　- Cute.Search＝Summon
　- Cute.Catalog＝XC
・Cute.Searchは内外のコンテンツを一括して対象にしてるから、Cute.Catalogも含む。ウェブ的なスケールのインデックス。
・Cute.Catalogの検索結果表示ランキングの判定には、「Solr」というシステム？を使っている。
・OPACのレコードがエンリッチだなあ、って思う。

・XCっていうのは、アンドリューメロン財団が出資して、ロチェスター大学さんが主に開発している。九大さんもスポンサーのひとつなんだけど協力的な感じ。
・「ユーザインタフェース」と「図書館システム（ILS）」の間に「XC」のソフトがはさまっている感じ。
　- 資料のメタデータは、「図書館システム」→「OAI」→「MST」→「Drupal」→「ユーザインタフェース」、って流れる。（メタデータの流れは一方向）
　- 貸出・利用リアルタイム情報は、「図書館システム」←→「NCIP」←→「Drupal」←→「ユーザインタフェース」って流れる。（貸出・利用リアルタイム情報は双方向）
・XCってそういう間に立ってくれる人なんだね。

・それぞれの機能をもう少し詳しく。
・「OAI」。OAIは、まだOAI-PMH形式になってないメタデータ（これはいろんなところから来るんだけど、常連は図書館システムから）を受けとって、OAI-PMH形式にしてあげて、それをMSTに渡す。
・このOAIさんがいるから、たぶん、種々雑多なところから種々雑多なメタデータを拾い集めてきてもだいじょうぶなんだと思う。
・「MST」。MSTは、OAIがわざわざ変換してくれたOAI-PMH形式のデータだけじゃなくて、もともとOAI-PMH形式で出してくれてる人（常連はリポジトリ）からのデータも直で受けとる。
・「MST」さんは、受けとったOAI-PMH形式のメタデータを”正規化”する。（たぶんこの”正規化”は目録の世界で言う”正規化”とは別のもの）　あと、うけとったメタデータが、著作レベルだったり表現形レベルであったり体現形レベルであったり、書誌レベルがばらばらであったりするんだろうけど、それを分析して整理して、各レベルの書誌として分割したメタデータを整形してあげる。（こんなこと機械でできるんだ、もう人間いらんね！）

・そんな「OAI」「MST」を通って流れていく、メタデータの流れをもう少し詳しく。
・１。いろんな種類のデータベース（図書館システムの所蔵図書の書誌データベースとか、CiNiiとか、九大のリポジトリとか、デジタル化コレクションなど）があって、さまざまなフォーマット（NACSISのCATPとか、MARCとか、DC（DubrinCoreとか））でのメタデータがある。
・２。さまざまなフォーマットのメタデータを、一部はOAI経由で、一部（DCのもの）は直に、MSTに流す。
・３。MSTの中では、「MARCXML」か「DC」かに大きくわかれる。
・４。そのうちMARCXMLのほうのメタデータには、外部のデータベースからリッチなデータをリッチにアドオンしてリッチなメタデータに仕立て上げる。（後述）
・５。MARCXMLもDCもどっちもを、XC形式のメタデータにしちゃう。
・６。XC形式のメタデータをDrupal（→Cute.Catalog）やSummon（→Cute.Search）に流す。

・書誌レコードをリッチにさせる件。
・BOOKデータベースやLCの目次・内容概説。
・Web-NDLSH・九大独自分類などの主題情報。特に主題情報のリッチ化は重要、ファセットブラウジングにいるから。
・ISSN-L。同タイトルでメディアが異なるもの同士のISSNをリンクづけてくれるデータセットみたいなのがISSNさんのwebサイトからダウンロードできるのでそれを使う。

・XCスキーマ、というのがある。
・XCスキーマは、DublinCore＋RDA＋XC独自要素。
・九大はさらに加えて、＋PRISM（論文関係の要素）＋DC-NDL（CJKに特有のヨミ要素）＋九大ローカル要素
・Cute.Catalogのスキーママッピング表というのがあって、縦軸が各要素項目、横軸が各データベース（NALISとかInfolibによる諸々データベースとか）。要素数は174くらいあるんだけど、現在使用中なのは115くらい。
・この辺は正直あんまよくわかんない。まあ、レコードの表なんだろうな、という感じ。

・データの定期更新は、差分のみでやるので、1日1回、5-10分くらい。（註：NDLSearchは毎回全件更新。）
・この件は、学内でWGをくんで取り組んでいる。
・九大ではこの件の事例成果をもって、NIIのERDB検討に参加している。

・課題。FRBR表現。Linked Open Data対応。
・課題。異なるメディア・資料種別の同一ものをまとめるのに、統一書名典拠をローカル典拠ファイルとして活用しようとしている。（うーん・・・）
・あと、九大関係者を集めた九大著者典拠ファイルを構築しようとしている。（これはイイね！）
・課題。全体をすっきりさせる。個別のインタフェース、データベースがまだすごいたくさん公開されている状態なので、これをがしっとまとめちゃう。ユーザ向けのインタフェースはDrupalのウェブサイトにしちゃって、その中にすべてのサービスを組み込むことにする。メタデータ管理も、ひとつの業務システムとして統合する。
・課題。重複したレコードへの対応。九大はいま、複数のデータベースから流れてきた重複レコードのうち、どの1つを選ぶかについて、元データベースに優先順位をつけて選ぶことにしている。いっぽう、SerialsSolutionsさんがSummonでやってる重複処理は、複数のデータベースからきたレコードには、それぞれ”得意な項目”があるはずで、その”得意な項目”をいいとこ取りして結果的に高品質になったレコードをひとつ作っちゃう、というやり方。


　江上個人の感想としては、こういった話、特に”結果”や”成果”の部分だけじゃなくて、”経緯””みちのり”の部分がもっとオープンに発表されていって、共有されていったらいいな、って思う。こういう成功しました、現状はこうです、だけじゃなくて、こういうことを試しました、やったらこんな感じでした、それにこんだけ費やしました、これこれこういうふうにみんなで動きました、ていうような、”画”が見える情報共有だと、別の人による次の”実働”がすごくやりやすくなるし、逆に、あ、うちは別ルートで行くべきやな、っていう判断もしやすくなるし。
　あと、これはこれですごいけど、京大さんの富士通製新OPACもあれはあれで充分すごいと思った。京大さんのほうはあれを踏まえて富士通さんが製品にしはるから、結果として、あれがたくさんのところでわあって使われていく、ていうことだから、そのことの意味って結構に大きいんじゃないかな、っていうあれです。