Recommended
More Related Content
Similar to 平成22年度 NIIポータル研修 機関リポジトリのメタデータ概論
Similar to 平成22年度 NIIポータル研修 機関リポジトリのメタデータ概論 (20)
More from Yuji Nonaka
More from Yuji Nonaka (19)
平成22年度 NIIポータル研修 機関リポジトリのメタデータ概論
- 1. 機関リポジトリの メタデータ概論 平成22年度学術ポータル担当者研修 平成22年7月29日 ＜会場：名古屋大学＞ 北海道大学附属図書館学術システム課 野中雄司 js@lib.hokudai.ac.jp
- 2. 今日のお話 • １．基本概念 – 1-1 メタデータ設計の意味 • 何を考えてメタデータ（入力項目）設計すればよいか – 1-2 OAI-PMH • ２．メータデータ設計 – 2-1 内部メタデータ設計 – 2-2 外部へのデータ提供設計
- 5. 要するに • 学内構成員に対するサービスである。 • 機関内産出の研究成果を世界中からアクセ スされやすいようにする – 可視性（ビジビリティ）のアップ ＝（イコール）
- 7. 1-2 OAI-PMH
- 8. OAI-PMHとは？ • 複数リポジトリのデータを収集し，それに基づ いたサービスを提供するために開発された データ提供・収集用のプロトコル • Open Archives Initiative によって開発 – 仕様書（http://www.openarchives.org/OAI/openarchivesprotocol.html） – 翻訳（http://www.nii.ac.jp/irp/archive/translation/oai-pmh2.0/） • HTTP通信を使用するため，アプリケーション に依存しない
- 9. リポジトリから見たOAI-PMH • 主にリポジトリ用の外部へのデータ提供を実 現するためのもの • リポジトリを設置するということ ＝（イコール） • 一つのサービスに提供するとその提供先が 別のサービスにデータ提供し，広がっていくこ とも。 「OAI-PMHで外部にデータ提供することで ある。」といっても過言ではない。
- 12. つまり • 機関リポジトリに搭載されている文献データを 他のサービスが（勝手に）持って行って（刈り 取って）くれて，サービスしてくれる。 • 自分たちからデータを送付する必要がない。 • 変更，削除記録も考慮してくれる。 例えば JAIRO 「ハーベスティング」といいます
- 14. コマンドとパラメタ Verb 説明 指定可能パラメタ Identify どんなリポジトリですか？ ListMetadataFormats どんな形式でデータを出力できますか？ i ListSets どんな集合がありますか？ r GetRecord データを1つください m, i ListIdentifiers IDリストをください m, s, f, u, r ListRecords データを全部ください m, s, f, u, r パラメタ 説明 metadataPrefix このデータ形式で set この集合のデータを from この日時のデータから until この日時のデータまで identifier このIDのデータを resumptionToken 次項のデータを 本表はOAI-PMHの仕様書に加え以下を参考に作成 http://www12.ocn.ne.jp/~zuki/drf/repository.html
- 17. ２．メタデータ設計
- 19. 機関リポジトリのメタデータ おおきく２つの用途に分けられます • システム内部で使用するメタ データ（内部メタデータ） • 外部に提供するメタデータ – OAI-PMH（等）で外部に提供するメタデータ
- 23. 世界標準は顧慮せず、なおかつ、顧慮する？ • 内部メタデータ設計は自由に！ – 内部で文献を管理するための情報やリポジトリシ ステム上で見せたい項目を保持！ – ハーベスティングしてほしいサービスに対応でき る情報を保持！ • 外部へのデータ提供は標準準拠で！ – OAI-PMH（等）で外部へデータ提供するためのメ タデータは標準準拠で！ – サービスプロバイダによっていろいろな形式（メタ データフォーマット）の出力が求められる。 • junii2，OAI_DC，MTD-MS…
- 24. 2-1．内部メタデータ設計
- 26. 内部メタデータ（設計考慮点） 1. どのようなメタデータフォーマットでデー タを外部に提供するのかをあらかじめ 想定し， 2. リポジトリ内部で保持する内部メタデー タを資料種別ごとに明確に決定するこ とが重要 3. 必要な情報を不足なく定義すること 以下を参考にした http://drf.lib.hokudai.ac.jp/drf/index.php?plugin=attach&refer=DRF-Ookayama&openfile=020909_05_handout.pdf
- 27. 資料種別ごとに必要項目を考えてみる 内部メタデータ項目は様々なタイ プの資料の最小公倍数で 雑 紀 会 学 教 誌 要 議 位 材 タイトル ● ● ● ● ● 著者 ● ● ● ● ● 抄録 ● ● ● 著者キーワード ● ● 学位授与機関・学位の種類 ● 掲載誌情報 ● ● 発表学会・開催地・開催年 ● 授業年度・講義科目名 ● junii2形式に対応し たいので分割して保 持しなくちゃ
- 31. 内部メタデータの記述 • 記述方法（書誌部分）についても，やっぱり統 一的規範は存在しない。 • 「学術コンテンツ登録システム 」 の「II. データ 記述マニュアル」を参考にしている機関も。 – http://www.nii.ac.jp/nels/man/index.html 「タイトルにルビが入っている場合はどうやって入力すれば？」 などなど記述方法についての疑問
- 32. 2-2. 外部へのデータ提供設計
- 33. 外部へのデータ提供用メタデータ （標準準拠で！） • データ提供のためのメターデータにはフォー マットごとに記述仕様がある。（サービスプロバイダ は，複数リポジトリからデータを集めてそれを元にサービス するため） メタデータフォーマット 使用サービス等 OAI_DC（シンプルダブリンコア） OAI-PMHで必須。OAIster等 で使用 junii2 JAIRO、CiNiiで使用 ETD-MS 学位論文用。NDLTDで使用
- 34. 各メタデータスキーマと参考ページ • OAI_DC - http://www.openarchives.org/OAI/2.0/oai_dc.xsd - http://dublincore.org/documents/dces/ • junii2 - http://irdb.nii.ac.jp/oai/junii2.xsd - http://www.nii.ac.jp/irp/archive/system/junii2.html - http://www.nii.ac.jp/irp/archive/system/junii2_guide.html （junii2ガイドライン） • ETD-MS - http://www.ndltd.org/standards/metadata/etdms/1.0/etdms.xsd/view - http://www.ndltd.org/standards/metadata/etd-ms-v1.00-rev2.html 各フォーマットの記述方法はメタデータスキーマで表現されていま す。
- 38. まとめ
- 40. 内部メタデータ設計とクロスウォーク 設定はとっても大変そう？ • まずはいろいろリポジトリに入力，登録してみ て，OAI-PMHの各フォーマットでどのように出 力されるか確認してみる。 – http://XXX.ac.jp/verb?XXXXX&metadataPrefix=oai_dc&... – http://XXX.ac.jp/verb?XXXXX&metadataPrefix=junii2&... • 必要があれば調整すればよい 参考になるサイト等 IRDBハーベスタ機能実装仕様(junii2) http://www.nii.ac.jp/irp/archive/system/irdb_harvest.html DRIVERガイドライン(oai_dc) http://drf.lib.hokudai.ac.jp/drf/index.php?tech DRF-ML上での議論(oai_dc) DRF-ML（http://drf.lib.hokudai.ac.jp/drfml/）で[oai_dc]や[クロスウォーク]で検索
Editor's Notes
- 本日のメニューです。 まずメタデータを設計する前に考えておくべき基本概念をお話していきたいと思います。また，機関リポジトリを運営するにあたって避けては通れないOAI-PMHについてもお話しし，その後で実際のメターデータ設計についてお話していきたいと思います。
- まずはメタデータ設計するにあたって，何を考えていただきたいかを話していきたいと思います。
- 改めて機関リポジトリというものを再確認してみます。これはよく機関リポジトリの定義に利用されるリンチの定義ですが， 「大学がその構成員に提供する、大学とその構成員が創造したデジタル資料の管理や発信を行うために，大学がそのコミュニティの構成員に提供する一連のサービス」 が機関リポジトリであるとされています。
- 要するに，機関リポジトリとは，外部の研究者や一般の人に対する情報提供サービスではなく，内部の構成員に対するサービスになります。 つまり，リポジトリを設置するということは，機関内産出の研究成果を広く世界中からアクセスされやすいようにする，サービスのことです。 これはよくビジビリティのアップなどと言われますが，主に２通りの方法があります。
- まず，Googleなどの検索エンジンにクロールされてインデクシングされるようにすること。 そしてもう一つが，文献のデータを所定の様式で用意すると，そのデータを持って行ってくれて，自らのサービスにそのデータを登録し，サービス展開してくれるものがあるので，それらにデータ提供できるようにリポジトリを構築すること。 この２つが主要な方法になります。 一つ目はリポジトリの世界に限らずの話ですので、今日は、リポジトリ特有といえる後者の話をしていきたいと思います。
- さきほど，文献のデータを所定の様式で用意すると，そのデータを持って行ってくれて，サービス展開してくれるものがあるといいましたが，それを実現するために開発されたOAI-PMHというプロトコルがあります。 ではOAI-PMHとは何かといいますと， 複数リポジトリのデータを収集し，それに基づいたサービスを提供するために開発されたデータ提供・収集用のプロトコルです。 Open Archives Initiative によって開発されています。 HTTP通信を使用するため，アプリケーションに依存しないでデータのやりとりを行うことができます。
- もう少し具体的にリポジトリ側から言いますと OAI-PMHとは，「主にリポジトリ用の外部へのデータ提供を実現するためのもの」です。 先程，機関リポジトリとは「研究成果を世界中からアクセスされやすいように構築する」，サービスであるといいましたが，これを実現させるものであり，リポジトリを設置するということ＝（イコール）「「OAI-PMHで外部にデータ提供することである。」 といっても過言ではない。 と言えます。 また，一つのサービスに提供するとその提供先が別のサービスにデータ提供し，広がっていくこともあります。
- こんなイメージになります。 データを収集してサービスするものは，OAI-PMHを利用して各リポジトリからデータを収集し，そのデータを使用してそれぞれのサービスを展開しています。また，これらのサービスからまた別のサービスにデータが渡っていくこともあり，自分の機関リポジトリのデータを検索できるサイトなどがどんどん広がっていきます。
- OAI-PMHプロトコルの概要です。 まず，OAI-PMHはHTTPでやりとりします。データがほしい側，取得する側を「サービスプロバイダ」といいます。またデータを提供する側（機関リポジトリ側ですね）は，データプロバイダといいます。 まずサービスプロバイダは，このようなURLでリポジトリにどんなデータがほしいか要求し，リポジトリは，XMLで要求に合致したデータを返す仕組になります。ちなみにURL中のこの赤字部分を「ベースURL」といいます。またURL中のverb引数で要求する命令を表します。 また，OAI-PMHで取得できるのは，あくまで文献のデータであり，コンテンツ本体はやりとりしません。
- つまり，機関リポジトリ側がOAI-PMHに対応することによって，サービスプロバイダが自動的にデータを取得してくれていって，勝手にサービスしてくれます。 機関リポジトリ側では正しく設定しておけば，以後の作業は必要ありません。 また，データを更新したり，削除したりした場合でも，OAI-PMHで引き渡すデータの中にそれとわかる仕組みがあり，サービスプロバイダがサービスプロバイダで保持しているデータを更新したり，削除したり，適切に扱ってくれます。 例えばみなさん御存知かと思いますが，NIIが運用している学術機関リポジトリポータル，通称JAIROがありますが，これは日本中の機関リポジトリからOAI-PMHによりデータを取得し，日本中の機関リポジトリに搭載された文献を一度に検索できるサービスを展開しています。
- 以上が概要ですが、ここでモデル比較してみたいと思います。 まずみなさんなじみのあるNACSIS-CATですが、これはまず各機関で分担してCATに登録し、それをダウンロードして自機関のOPACなどで使うという仕組みです。 それに対して、OAI-PMHでは、各機関が自分のリポジトリに登録しておくと、サービスプロバイダがリポジトリ上のデータを勝手に取得していって、データベースを構築、サービスします。
- それでは一つ要求例を示したいと思います。見やすいように改行していますが，実際は１行のＵＲＬです。この例では metadataprefixパラメタで，どのような形式のデータがほしいかを示し， from,untilパラメタで，指定期間に更新されたデータのみほしいことを示し， setパラメタで，リポジトリ中のどの集合がほしいかを示し， verb引数のListRecordsで，これらの条件に合致したレコードを全てください，ということを表しています。＜結果を見せる。別途XMLファイルで用意＞
- では，実際の運用例をJAIROの例で説明したいと思います。 まず，リポジトリ側は文献のデータを入力，登録します。 そのデータはJAIROがOAI-PMHを使用して，ハーベスティングし，JAIRO内にデータを登録します。これにより，JAIROでこのデータが検索されるようになります。 また，JAIROはCiNiiにこのデータを提供していますので，CiNiiからもリポジトリに登録した文献が検索されるようになります。 まずはOAI-PMHはこのように使われているということをイメージしておいていただければと思います。
- ここで一区切りです。ここからメタデータについてお話してきたいと思います。 ここまで，メタデータ設計をする際にまず前提として考慮してほしいこと，そして外部へのデータ提供のためにOAI-PMHというプロトコルがあるというお話をしました。 では，実際にそのためにはどのようにすればよいかということをここからお話していきたいと思います。
- メタデータ，メタデータといいますが，メタデータとはなんでしょうか？よくデータのデータとか，データを要約したデータとか言われますが，リポジトリにおけるメタデータとは 「デジタルコンテンツの多面的な特性を記述するもの」ということができると思います。そして機関リポジトリのメタデータにはこのような情報が記述されることになります。 例えば，当然目録に相当する書誌情報や，保存されているコンテンツを再生するための情報，つまりコンテンツのファイルタイプなどですね。PDFなのかwordなのかといった情報や，このコンテンツの利用についての情報，また内部情報として資料を受け入れた日や，更新情報などが記述されます。 このような情報が機関リポジトリのメタデータとして表現されることになります。
- 機関リポジトリのメタデータはまた，用途として大きく２つに分けることができます。 １つはシステム内部で使用するメタデータ，そして外部に提供するメタデータです。この外部に提供するメタデータが先程までご説明したOAI-PMHにより出力されるメタデータということになります。
- 簡単に内部メタデータ，外部への提供メタデータについて説明します。 まず内部メタデータとは，文字通り機関リポジトリに登録する，登録されているメタデータです。みなさんが自分で入力したデータやシステムが自動的に付与した登録日などが内部メタデータとしてリポジトリシステム内のデータベースに保存されます。
- 次に外部へ提供するメタデータですが，これは実体として機関リポジトリ内に存在しているわけではなく，内部メタデータを外部に提供する用に変換して出力されるメタデータのことをいいます。OAI-PMHではXMLで出力され，またOAI-PMHでは要求がくる度に，内部メタデータを変換して出力します。
- ではここからこの用途別の２つのメタデータを実際に設計するためのお話をしていきたいと思います。 まず，機関リポジトリにおけるこれら２つのメタデータを設計するにあたってはこのことを念頭においていただければと思います。 「世界標準は顧慮せず，なおかつ，顧慮する」 なんのこっちゃというところですが，
- こういうことがいいたかったのです。 「内部メタデータ設計は自由に！」つまり内部メタデータは世界標準は顧慮せず， 「外部へのデータ提供は標準準拠で！」つまり外部へ提供するメタデータは顧慮せよ，と。 こちらはなぜ標準準拠する必要があるかと言うと，OAI-PMHのサービスプロバイダによって，いろいろな決められた形式（メタデータフォーマットと言いますが）での出力が要求されるからです。 例えばJAIROはjunii2というフォーマットでの出力，OAIsterではoai_dcというフォーマットでの出力が求められます。 どうしてこのように考えてほしいかは，ここから具体的に説明していきます。
- まず内部メタデータの設計からお話します。
- 先程，「内部メタデータは自由に！」といいましたが，逆に言うと，世界標準がないということです。 機関リポジトリは扱うコンテンツが多様なこともあり，メタデータ項目，記述方法について，NACSIS-CATのコーディングマニュアルのような統一的規範は存在しません。 つまりどのような入力項目を持つか，どのように記述していくかは，自分で入力項目を設計したり，記述方法を決めていかなくてはなりません。そうはいっても標準がないんじゃどうやって設計していけばいいのかわからないじゃん，ということでどう設計していけばよいか。
- まずは，以下の点を念頭において，設計していっていただければと思います。 まず，機関リポジトリの使命は，ただリポジトリにデータを登録するだけではなく，どう外部にデータ提供していくかが重要であるため， １．どのようなメタデータフォーマットでデータを外部に提供するのかをあらかじめ想定し， ２．リポジトリ内部で保持するメタデータを資料種別ごとに明確に決定することが重要 ３．以上を踏まえ，必要な情報を不足なく定義すること となります。 これだけでは少しピンとこないかもしれませんが，まずは以上のことを念頭において後の話を聞いていただければと思います。
- まずは，資料種別ごとにどのような入力項目が必要かを考えていきます。 雑誌や紀要であれば，タイトルや著者の他にも掲載誌情報が必要だろうと， また，学位論文であれば，学位授与機関や学位の種類も記載したいなと・・・ またあわせて外部へのデータ提供も考えます。このケースではJAIROへデータ提供したいのですが，JAIROで求められるJunii2形式は分割した掲載誌情報を求めているので，ジャーナルタイトル，巻，号，ページは分割して保持しなくちゃ…。 こういったように，まず自分の機関で登録したい文献の種類ごとに必要な入力項目，保持したい項目を考えていきます。またあわせて外部へどのようなメタデータフォーマットでデータを提供するのかも考えていきます。 手前味噌で申し訳ありませんが，以下HUSCAPでの例でもう少しイメージを見ていただければと思います。
- 例えば学位論文の場合は，学位の種類を記述したかったので，デフォルトの内部メタデータの項目に加えこのような項目を増やしています。
- また例えば雑誌論文の場合は，掲載誌情報を詳細に記述したかったのと，JAIROにデータ提供したかったので，このような項目を追加しています。
- またHUSCAPでは内部メタデータとして登録作業管理情報もメタデータとして保持したりしています。このように必要な項目を自由に設計していっていただければと思います。
- また，項目だけではなく，メタデータの記述方法についても統一的規範は存在しません。つまり，「タイトルにルビが入っている場合はどうやって入力するの？」といった部分です。 NIIの「学術コンテンツ登録システム」がありますが，このデータ記述マニュアルなどを参考にされてる大学さんなどもあるようですので，そちらなどを参考にしてもよいかと思います。
- ではここから外部提供用メタデータについてお話します。
- 外部へデータ提供する場合には標準準拠のメタデータを出力する必要があります。これは，サービスプロバイダは複数リポジトリからデータを集めてそれを元にサービスするため，例えばどれがタイトルで，どれが著者なのかといったように，自らでサービスするために必要な項目，記述方法で保持する必要があるからです。そのため，様々なメタデータフォーマットが存在します。 つまり，リポジトリ側は，サービスプロバイダが要求する形式（つまり標準準拠で）でデータ提供しなければならない，ということです。 このメタデータフォーマットですが，例えばoai_dcというメタデータフォーマットがあり，これはOAI-PMHでは必須とされています。また，OAIsterなど主だった海外サービスプロバイダへは基本的にこの形式でデータ提供することになります。また，今日何度も登場したJAIROに対してはJunii2というメタデータフォーマットでの出力が求められる，といったことになります。
- 参考までに各スキーマが記述されているＵＲＬと，またその解説ページをこのスライドに記述しましたので，帰ってからご参考いただければと思います。 なお，Junii2については資料１としてお渡しした表形式になっているものもあります。こちらがわかりやすいと思いますので後で見て，あぁこういうものなのだなと確認していただければと思います。
- 具体的にはこのような方法をとります。 それぞれのフォーマットで出力するためにフォーマットごとに「内部メタデータ」から「外部に提供するメタデータ」への変換プログラムを作成することになります。また，この変換のプロセスをクロスウォークと言います。
- では，HUSCAPでの内部メタデータ項目とクロスウォーク設定を資料２として添付してみましたので，ちょっとご覧ください。 例えばHUSCAPでは文献の所在を表すURLを内部メタデータ項目として「identifier.uri」という項目名で保持していますが，oai_dcで出力するときには「identifier」という項目名で，junii2で出力するときには「URI」という項目名で出力しています。 また，雑誌論文の場合の掲載誌情報ですが，内部メタデータ項目としては，分割して保持していますが，oai_dcではこれらを結合して「identifier」として出力，junii2ではunii2の項目名に変換して，そのまま出力させています。 ＜以下これらをHUSCAPの画面，OAI_DCの画面，Junii2の画面で見せる。上記の説明項目でこれがこうなったと実際に示す。＞ このようになります。
- つまり内部メタデータでは，oai_dcやjunii2，etd_msなど，自分が出力したい外部メタデータフォーマットを十分に出力しうる項目を保持する必要があります。それをそれぞれのメタデータフォーマットで必要な項目のみ，それにあった名前，形式で出力することになります。
- 再びイメージです。 まず機関リポジトリに保存されるメタデータは自由に！かつ不足なく記述できるように設計しましょう。また，外部へのデータ提供は，それぞれのスキーマに沿ったデータをきちんと出力するように設計しましょう。
- ここまで説明してきましたが，なんだか難しそうと思っていらっしゃる方もいるかと思いますが，そんなに難しく考えないでほしいなと思います。 まずは自分でOAI-PMHのコマンドをたたいてその出力がどうなっているのかを確認してみてください。データを眺めていれば，あぁここに入力した値はこうやって出力されるんだな，とかいうことがわかると思います。なので，それを確認しながら設計，調整できますので，なにも怖いものはないと思います！
- また，業者にリポジトリシステムの導入をお願いする場合は，このOAI-PMHの知識もあるかどうかも確認したほうがよいと思います。 また，導入時には，内部メタデータ項目のカスタマイズだけではなく，最低限OAI_DC，Junii2のクロスウォーク設定まで盛り込むことが重要と思います。
- さて最後ですが，すべての準備が整って，サービスプロバイダにデータ提供したいところですが，これは次の「機関リポジトリの公開」講義で詳しいお話がありますのでそちらを楽しみにしていただければと思います。
- 終わり