ディスカバリーサービスのさらなる「日本化」を目指して

佛教大学図書館 専門員
飯野勝則（iino@bukkyo-u.ac.jp）
図書館総合展日外アソシエーツ社フォーラム
2013年10月30日於横浜
1

はじめに2

佛教大学と図書館のあらまし• 1912年開学• 浄⼟宗による設⽴• 京都市および南丹市にキャンパス• 仏教学部をはじめ、保健医療技術学部など7学部体制• 通学課程学生数： 約7000人• 通信課程学生数： 約14000人• 図書館蔵書数： 約97万冊• 図書館年間開館⽇数： 316⽇
• 2011年4月より、⽇本で初めてディスカバリーサービス「Summon」の正式運用を開始
3

ディスカバリサービス

4ディスカバリーサービスとは？
①次世代OPAC (NGC: Next Generation Catalog)• Aqua Browser• eXtensible Catalog②ウェブスケールディスカバリ（WSD: Web Scale Discovery）• Summon• EBSCO Discovery Service• WorldCat Local• Primo Central③ウェブ検索エンジン• Google• Yahoo！

さまざまな⾒解が存在するが、最近の図書館業界としては「②」に分類される４つのシステム（通称：BIG4）の意味で用いられることが多い
5

ウェブスケールディスカバリ（WSD）
機能• 図書館OPACなど⾃館のコンテンツから、商用のデータベースに⾄るまでを統合的に検索できる• 視覚的に⼯夫されたユーザインターフェース上で検索結果を統合的に表⽰できる
特徴（四つの要件）• クラウドサービスとしての提供• 図書館や各種の商用データベース等から収集されたメタデータを統合した、ウェブスケールな検索用の「セントラルインデックス」を所有• 電⼦リソースに対し、定期的に⾃動でデータ更新（ハーベスト）を⾏うための仕組みを持ち、利用者に最新の検索データを提供• 単⼀の検索窓で検索を⾏えるほか、検索結果全てを「関連度」順に表⽰

横断検索（Federated Search）と次世代OPAC（NGC）で実現されていた「機能」を引き継ぎ、新たな特徴（四つの要件）を付与して形成されている
6

ウェブスケールディスカバリの仕組み
大学内
イントラネット

IP認証

検索 ”Hawaii”

ウェブスケール
ディスカバリベンダー

事前のデータ収集（ハーベスト）

結果

データベースA

データベースB

データベースC

大学外インターネット

検索 ”Hawaii”

結果

ウェブスケール
ディスカバリサーバ

データベースD“Hawaii”を検索すると、“Hawaii”というキーワードをあらかじめ収集したデータを用いて作成した「セントラルインデックス」に対し検索を⾏い、その結果を表⽰する
7

横断検索（Federated Search）
Multi Search / 360 Search※2007年5月〜2009年3月※ 2009年4月〜2011年3月

・キーワードを各データベースに投げて、その返答結果をひとつの画面上で統合して表⽰するシステム
・増え続けるデータベース（とくに英語）を利用者に効率的に使わせたいという必要性から生まれた8

横断検索（Federated Search）の仕組み
IP認証
大学内
イントラネット

Federated Search
ベンダー

検索 ”Hawaii”

データベースA

結果
IP認証
検索 ”Hawaii”

データベースB

結果

IP認証

検索 ”Hawaii”

ログイン認証検索 ”Hawaii”

結果合成

データベースC結果
横断検索サーバ

認証不要（オープン）
検索 ”Hawaii”

データベースD

結果“Hawaii”を検索すると、“Hawaii”というキーワードを複数のデータベースに投げ、検索させ、帰ってきた結果を一つの画面で表⽰
9

次世代OPAC（Next Generation Catalog）
Aqua Browser Library
Edinburgh University Library

http://aquabrowser.lib.ed.ac.uk/

・視覚的に優れたデザインを採用しているほか、ファセット分析などの技法により、利用者により多くの情報を直感的、効率的に提供するシステム
・図書や雑誌に限らず、図書館で提供できる幅広いコンテンツを、直感的に利用者に提供したいという必要性から生まれた10

横断検索と次世代OPACの弱点
横断検索

次世代OPAC（Federated Search）（Next Generation Catalog）• 検索結果が各データベースの反応順で表⽰される• OPAC以外の外部のデータベース• 検索能⼒が各データベースの検索システムの能⼒に依存する

断検索を利用する必要があるを統合的に検索する場合には横• 横断検索の弱点は次世代OPACの• 検索のためのデータベース接続が不安定である

弱点でもある• 検索に対する反応が遅い
これらの弱点を克服する「特徴（四つの要件）」をもったシステムとして、ウェブスケールディスカ
バリは開発された
11

次世代OPAC（NGC）とウェブスケールディスカバリ（WSD）の関係性①次世代OPAC（ＮＧＣ）②ウェブスケール
ディスカバリ（WSD）

・実際には、ウェブスケールディスカバリ（WSD）も次世代OPACの一形態
・ウェブスケールディスカバリは、「次世代」の中の「次世代」であり「ウェブスケールな次世代OPAC（NGC）」
12

ウェブスケール（Web-Scale）とスケーラビリティ（ Scalability ）13

ウェブスケールとは？
• 図書館本来の「スケール」である、インスティチューションスケール（Institution-Scale）の対義語

Institution-Scale

Web-Scale“Libraries at Webscale”. OCLC.
http://www.oclc.org/reports/webscale/default.htm
14WSDのスケーラビリティ
Web-Scale
GlobalInstitution-Scale
Local

Group-Scale
Consortial
Regional

WSDはウェブスケールのみならず、多層的なスケール概念を包摂するシステムであり、その思想は「検索モード」や扱う「コンテンツ」等に反映されている
15

スケーラビリティと検索モード

Web-ScaleGroup-Scale
Institution-Scale
From WorldCat Local

検索対象となるデータの範囲を「スケーラビリティ」に応じて設定できる

16

スケーラビリティとコンテンツ
GlobalWeb-Scale
Regional /Consortial
Group-Scale
Local
Institution-Scale• 商用データベースなど• 契約があれば世界中で利用可• 地域コンソーシアムが作成したデータベースなど• グループとしての利用が中⼼• グループ内だけの限定コンテンツも• 図書館や大学が作成したデータベースなど• その図書館や大学での利用が中⼼• 学内限定というのも

17

BIG4

18

高ディスカバリ対応の難易度

低WorldCat Local（WCL）•2007年リリース。WSDの先駆け的存在

•OCLC

19
Portland State Library. http://library.pdx.edu/Summon•

2009年リリース•Serials Solutions社

20

佛教大学図書館「お気軽検索」. http://bukkyo.summon.serialssolutions.com

EBSCO Discovery Service（EDS）•2010年リリース•EBSCO社

⽴命館大学図書館. http://www.ritsumei.ac.jp/library/21

Primo Central•

2010年リリース•Ex Libris社

22
Loughborough University Library Catalogue Plus. http://lcp.lboro.ac.uk/

ここから⾒えるもの
英語コンテンツ・
データベースの増加

横断検索システム

ウェブス
ケールディ
スカバリ
コンテンツタイプの増加
OPACインターフェースの不満

次世代
OPAC

検索結果、表⽰速度への不満

・英語を基盤とする「豊富な電⼦コンテンツ」が先に存在し、その利用を効率的に⾏
うためのソリューションの進化の中で開発
・「必要は発明の⺟」を地で⾏く、海外で開発された「英語コンテンツありき」のサービス
23

日本化へのステップ24

日本化の前提
現実の認識• BIG4をはじめ、ディスカバリサービスは海外製品しかなく、継続的な日本化への取り組みは避けられない• 日本語もベンダーにとっては世界中のユーザーが使う言語のひとつでしかない
背景の認識• ディスカバリサービスの生まれた背景は明らかに日本と異なる• これまでの図書館システムとは異なる特徴（四つの要件）を持っている
⽂化的な摩擦や⽢受の必要性を認識• 海外製品であるがゆえに、日本的感覚からみると、違和感のある対応や仕組みも日本化する範囲を認識• システムとコンテンツの両面から、十分に日本語の学術情報を扱えるようにする• 日本的な細やかさが求められる部分をどう扱うかを考える
25

システムとコンテンツの日本化「開始」ステップ（Summonの場合）• 検索画面などの日本語化• もっとも初期に開始

コンテンツの導入• 「ローカル」なOPACデータのロード• 「グローバル」な商用データベースのユーザインターフェース

ロードには時間が必要• 日本語に特化した検索技術の適用• 利用者の言語に応じた検索結果の表⽰
検索機能（システム）の（デザイン）の日本語化

強化

実際の作業は、並⾏して継続している26

日本語に特化した検索技術（例）形態素解析

たとえば「京都」の検索結果に「東京都」が入ってこないようにする。新語などが出てきた場合には難しいことも（ex.リニアの「東京都駅」）
27

ユーザインターフェースによる利用者の言語認識

中国語と日本語のように、漢字を共通に使う言語の場合でも、利用者の望む結果を返す
28

コンテンツの日本化29収集されるべきコンテンツ
論⽂

雑誌タイトル

雑誌記事

図書タイトル

図書目次

リファレンス

新聞記事

公⽂書

写真

音声

音楽

映像

30

収集されるべきコンテンツ
論⽂

雑誌タイトル

雑誌記事

図書タイトル

図書目次

リファレンス

新聞記事

公⽂書

写真

音声

音楽

映像

31

コンテンツの収集アクション（１）ライセンスを中⼼に考えると自館コンテンツ• OPAC• 機関リポジトリ• デジタルアーカイブ

オープン
データベース

商用データベース• NDL雑誌記事索引• ジャパンナレッジ• JAIRO• CiNii• Medical Finder• 医中誌Web• magazine plus
• book plus
• 新聞その他

現在のフェーズは「商用データベース」へのアクションが中⼼32

コンテンツの収集アクション（２）スケーラビリティから考えると

GlobalWeb-Scale
Regional /Consortial
Group-Scale
Local
Institution-Scale• 商用データベースなど

高• 契約があれば世界中で利用可• 地域コンソーシアムが作成したデータベースなど• グループとしての利用が中⼼• グループ内だけの限定コンテンツも• 図書館や大学が作成したデータベースなど

ディスカバリ対応の難易度

低• その図書館や大学での利用が中⼼• 学内限定というのも現在のフェーズは「Global / Web-Scale」へのアクションが中⼼33

コンテンツベンダーから⾒た課題•

海外ベンダーへの信頼欠如•

メタデータの⾏⽅に不安•

海外ベンダーの相手は面倒

⼼理面•

ポリシーの問題•

そもそも契約上無理

ライセン
ス面

技術面

⾦銭面

•

技術的に難しい•

収益を確保する⽅法が⾒えない•

どんな技術が必要か分からない•

データ提供の対応に費用がかかる

コンテンツベンダーに対し、解決できる課題の場合、図書館がその共存共栄できるメリットを提⽰し、迷いをとる手助けをする必要がある？
34

Summonと日本語コンテンツに⾒る
Win-Win関係

35

Federated SearchとSummon
検索件数の経年変化
200,000
180,000

Before173,516After

160,000
140,000※ ↓2013年4-7月

115,930

120,000

105,712

100,000
80,00060,00040,00020,00013,0830Federated Search （2010）

Summon（2011）

Summon（2012）

Summon（2013）

統合検索（横断検索）の利用はSummon導入前の2010年度に⽐べ、2011年度で8.9倍、2012年度で13.3倍に増加
36

Summonの検索回数と日本語コンテンツ投入時期（佛大の場合）
JAIRO(2013年4月)

NDL雑誌記事索引（再）・医中誌・ジャパンナレッジ(2013年6月)

CiNii(2012年9月)

J-STAGE(2012年10月)

35,00030,00025,000Federated Search （2010）

20,000

Summon（2011）
15,000

Summon（2012）
Summon（2013）

10,0005,000
0
4月

5月

6月

7月

8月

9月

10月

11月

12月

1月

2月

3月

NDL雑誌記事索引(2011年4月)

とくにCiNiiとJAIROの投入後、検索回数の伸びが⾒られるのでは？
37

CiNiiのダウンロード件数
4,500

Summon対応開始(2012年9月)
4,000
3,500
3,000
2010年度

2,500

2011年度
2,000

2012年度
2013年度

1,500
1,000
500
0
4月

5月

6月

7月

8月

9月

10月

11月

12月

1月

2月

3月

SummonのCiNii対応が開始されたのち、CiNiiのダウンロード件数も増加
傾向
38

OPAC検索件数の経年変化
800,000
700,000

Before709,622After
613,511598,398
600,000
500,000
400,000※ ↓2013年4-7月
300,000

265,244

200,000
100,0000
2010年度

2011年度

2012年度

2013年度Summonの導入一年目は、OPACの検索結果が増加したが、⼆年目になり減少を⽰す。本年度もその傾向は継続の模様
39

Summonにおける詳細画面設定

詳細画面をSummon側に持たせることで、OPACへの遷移が減少
40

OPACとの利用⽐較
2013年

28%

72%

※ 2013年4-7月

2012年

22%

78%
FS/Summon
OPAC

2011年

14%

86%

↑After↓Before
2010年 2%

0%

98%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

OPACと統合検索（横断検索）の検索件数の合計に対するそれぞれの割合は、Summon導入後、統合検索の占める率が高くなりつつある
41

一⽅的Win-Win関係（？）
「棚からぼたもち」

42

日経BP記事検索サービス（キジケン）

2013年9月時点では、Summonにメタデータを提供していない日本語データベースのひとつ
43

日経BPキジケンにおけるダウンロード件数の経年変化
16,000After

Before15,202

14,00012,00010,000

9,201

8,000
6,276
6,000
4,000
2,00002010年度

2011年度

2012年度Summon導入前の2010年度に⽐べ、2011年度は1.5倍、2012年度は2.4倍の伸び。2012年度は定額契約の上限件数（12000件）超え44

雑誌記事索引

⽇経BP社の雑誌コンテンツを数多く採録
http://www.ndl.go.jp/jp/data/sakuin/sakuin_index.html
45

雑誌記事索引のデータから日経BPキジケンへのアクセス

46

雑誌記事索引のデータから冊⼦体の雑誌書誌へのアクセス

47

ここからわかること•

Summonは一度受容されると利用者の資料探索⾏動に与える影響は大きい•

日本語コンテンツの質と量がSummonの評価に直結する•

Summonにデータを提供した1次資料データベースの利用は増加する•

雑誌記事や論⽂タイトルなど価値のあるメタデータを提供できるデータ
ベースはSummonにそのコンテンツを提供することで、他のデータベースに多大な貢献をもたらし、手放すことが難しくなる•

例えばmagazine plusは、こういったデータベースのひとつになりうるかも・・

図書館ステークホルダにとって重要な共存共栄をもたらす「正のスパイラル」が出現
48

理想的な「正のスパイラル」
価値のあるデータベース

メタデータのディスカバリ

データベース契約の続⾏への提供

メタデータを提供したデー

ディスカバリの利用者増加

タベースの価値を再認識

データベース本体や他のデータベースの利用を導く

日本語コンテンツの場合、この流れは一層強固なものに・・・（本当です）
49

データベースの価値を再認識するあるアクシデントを通じて50

日経BPキジケンのダウンロード数
NDL雑誌記事索引旧データ削除(2013年4月)
2,500

NDL雑誌記事索引再度のSummon対応 (2013年6月)
2,000

1,500

2010年度
2011年度
2012年度

1,000

2013年度
500

0
4月

5月

6月

7月

8月

9月

10月

11月

12月

1月

2月

3月

NDL雑誌記事索引のSummon対応(2011年4月)

NDL雑誌記事索引のデータ削除により、本年度は利用者数が急激に低下。新データ投入後も回復していない
51

雑誌記事索引からのハーベストデータの変化Before

After

新データでは、ISSNデータが入っておらず、正確なリンクを形成できない状態に（泣）
52雑誌記事から冊⼦体雑誌書誌へのアクセス件数
1400

1200

1000800

2010年度NDL雑誌記事索引
旧データ削除 600(2013年4月)

2011年度
2012年度
2013年度400

200

佛大におけるJAIROのSummon対応(2013年4月)

CiNiiのSummon対応(2012年9月)

0
4月

5月

6月

7月

8月

9月

10月

11月

12月

1月

2月

3月

CiNii、JAIROのSummon対応と雑誌記事索引由来データのISSN欠損から、冊⼦体雑誌の利用は著しく減少。2010年並みで推移
53

APIの仕様変更に原因

ISSNという分かりやすい形でのメタデータはないが、実際にはURIとして保持しているので、なんとかなりそう
54

ISSNの復活

2013年9月13日（⾦）よりISSNが復活。推移を注意深く監視中55

日経BPキジケンのダウンロード数（速報）
2,500

2,000

1,500
2010年度2011年度
2012年度

1,000

2013年度

500

0
4月

5月

6月

7月

8月

9月

10月

11月

12月

1月

2月

3月

9/13のISSNの復活をうけ、月刊1041件のダウンロードを記録し、本年度はじめて1000件台に乗せる。明るい⾒通しが得られたことで、ISSNデータを含む雑誌記事索引を再評価？
56

ここからわかること•

雑誌記事索引は商用データベースとは異なるが、商用データベースであっても、再評価の過程に変化はないと思われる•

例えば雑誌記事索引に類似するmagazine plusであれば、同じような評価となることも期待できるし、これ以上の波及効果を生み出せる可能性がある•

商用データベースの契約者のSummon上でのみ、そのメタデータの利用を許諾するようにすれば、商用データベースの契約は維持されるだろう•

日本語コンテンツが入っていても、ユーザビリティを確保できないと、Summonは十分な効⼒を発揮できないという現実がある

57

ちなみにmagazine plusですが2014年4月からディスカバリサービスでのメタデータ利用が可能に！

58

日本語対応から日本化へAPIによるSummonのユーザビリティ向上の試み

59

日本語対応における現実と課題•

ハーベスト（収集）を受け入れていない商用データベースが存在•

NDL-OPACやOPACのメタデータの内容は、従来からの目録規則に準拠した部分にとどまり、「豊かなメタデータ」とは言いにくい•

日本語によるディスカバリサービスでの図書検索は、OPACにおける図書検索と遜⾊ないものでありたい。すなわち、OPACで可能なことはディスカバリサービスでも可能であってほしい•

ユーザインターフェースに日本的な細やかさをもとめたい
ディスカバリサービスの枠を超え、APIを用いての外部情報資源の利用を⾏うことで課題解決に道が開ける
60

API(Application Programming Interface)•

あるソフトウェアが外部のソフトウェアに対して提供するインターフェース（接続規格）•

データの外部からの呼び出しや、交換といった用途で用いられる

61

例えばAPI（BOOK API）を使うと論⽂雑誌タイトル

雑誌記事

図書タイトル

図書目次

リファレンス

新聞記事

公⽂書

写真

音声

音楽

映像

メタデータが収集できていない日本語の「図書目次」といったデータを既存の書誌のデータを用いて表⽰できる。間接的な「書誌エンリッチメント」が可能

62

BOOKデータASPサービス（BOOK API）

63

概要
• 日外アソシエーツ社の「BOOKデータベース」の内容、目次・要旨、著者紹介情報（2001年〜現在）、表紙書影（2000年〜現在）をAPIによって提供するサービス• ISBNを検索キーとして該当のメタデータを「BOOKデータベース」からXML形式で呼び出すことができる。また表紙書影についてはJPEG画像を呼び出すことができる。
• 表⽰される内容はすべて著作権が処理されたものであり、ライセンス的な⼼配がない

64

BOOK APIでの呼び出しデータ

XMLではタイトル、ISBN、あらすじ、目次データ、著者情報、IPアドレスなどを取得できる
65

OPACにおけるBOOK APIの実装

本学の場合には、あらすじ、目次データ、著者情報のみを表⽰していたが、利用者からの評判がよかったこともあり、Summon導入後は「日本化」のトピックのひとつとして、連携を本格的に検討。実証実験を開始
66

SummonにおけるBOOK API実証実験

67

OPACとSummonの仕様⽐較
OPAC• オンプレミス（学内設置等）での運用が一般的で、サーバ自体も所有・管理が可能なため、自由度が高い• ベンダーを通して、一定の画面カスタマイズなども可能

Summon（ディスカバリサービス）• クラウドサービスであり、サーバ等を自由に触れる環境ではない• ユーザインタフェースの共通化により、画面カスタマイズの自由度が低い• セキュリティなどの面で考慮すべき要件が多いということで、Summonのほうが適用は難しい部分も・・
68

BOOK API実装の概念図（OPAC）
大学内イントラネット

日外アソシエーツ

ISBN
あらすじ等
OPACサーバ（図書館設置）BOOK サーバ

大学外インターネット

69

BOOK API実装の概念図（Summon）
大学内イントラネット

日外アソシエーツ

図書館設置サーバISBN

BOOKサーバ

あらすじ等

検索

結 果合成

ISBN

あらすじ等

大学外インターネット
Serials Solutions

検索
結果合成

Summonサーバ70

検証結果としてはとりあえず、図書に関する目録規則準拠のメタデータについて、それを補う情報を表⽰できることを確認
71

ただし課題も・・・

72

技術的な課題
ブラウザ• 検証段階だがInternet Explorerは、独自のセキュリティポリシーをもっており、「目次」「あらすじ」の表⽰が難しい• FirefoxやChromeの頻繁なアップデートに対する一定の懸念
Summon• クラウドサービスを背景に、ベンダー側でのユーザインターフェー
ス画面のアップデートなどが頻繁なことに懸念• アップデートにより仕様や「設計思想」が変更された場合には、スクリプトを書き直して、設定をし直す必要が出てくる可能性

73

Internet Explorerと他ブラウザの⽐較
IE

Firefox
Chrome

ただいま回避策などを模索中・・・
74Summon の仕様変更
SummonSummon2.0

ただいまSummon2.0向けに急ピッチで開発中・・・
75

正式運用に向けて• Internet Explorerへの完全対応• 今後切り替わるSummon2.0への対応スクリプトの開発• SummonのベンダーであるSerials Solutions社には運用のための技術的要望などを申し入れ済み• Serials Solutions社からは前向きな返答

ディスカバリサービス「日本化」のステップとして、Summonについてはある程度の⾒通しがついた状況

76

その他の注意点•組み込みを認めるか否かはディスカバリサービスのベンダー側の考え⽅によるので、ベンダー側との事前の協議を⾏っておくこと（ちなみにSummonおよびEBSCO Discovery Serviceで対応できることは確認済とのこと）•

ディスカバリサービスベンダーとの技術的協議を⾏い、クライアントとしての要望を伝えること•

ディスカバリサービスベンダーを介して各種設定を⾏い、持続的な保守体制を利用すること

とにかく持続可能なシステムとして利用できるようにすることが大切77

近未来への展望
さらなる「日本化」に向けて

78

収集されるべきコンテンツ
論⽂

雑誌タイトル

雑誌記事

図書タイトル

図書目次

リファレンス

新聞記事

公⽂書

写真

音声

音楽

映像

日本語においても、英語コンテンツと同様のメタデータの「厚み」がほしい
79

厚みの要素のひとつ「時間」

時間（過去）

過去のデータに対しても「遡及」していくことは将来的には必要だろう
80図書目次（あらすじ）に絞ると論⽂

現状雑誌タイトル

雑誌記事

図書タイトル• あらすじ、目次データのハーベストデータはほとんどな
い

図書目次

新聞記事
リファレンス公⽂書• BOOK APIによる外部情報の取得でエンリッチメントを試みている状態• BOOK APIで取得できる図書のあらすじや目次情報は、写真1986年以降に限られるという時間的な制約
音声
音楽
映像
時間的な厚みの必要性• 図書館の書庫などに埋もれる1986年以前の図書にも、⼈⽂科学系を中⼼に十分利用できる学術情報は存在必要性は高いのでは？

• NDL-OPACや自館OPACの書誌による基本の「メタデータ」
については、過去への遡及は十分に⾏われている状態

81

日本語の図書目次メタデータの存在状況（≠ディスカバリ対応）
1986年〜現在

1969年〜1985年

1968年以前• BOOKデータベース•★BOOKデータベースの拡張プロジェクトとし電⼦としては存在が明らかではないて、日外アソシエーツ社で入⼒事業が開始され•ることに！
冊⼦目録• 国会図書館デジタル化資料

一定の課題が解決されれば、ディスカバリサービスの一層の「日本化」は進むはず82

課題と要望API（ASPサービス）• 遡及データにはISBNなどがなく、現状の仕様では連携できない可能性が高い• APIとしての利用の需要を考えると、代替となるキー（ex. NCID, 全国書誌番号など？）への対応を考える必要もある
ハーベスト対応• 国⽴国会図書館デジタル化資料とともに、ディスカバリサービスによるハーベストに対応できることが望ましい• ディスカバリサービス内での書誌マージ（OPAC書誌などとの統合）などを、ディスカバリベンダーと協調して⾏ってほしい

課題解決により、多くの価値ある日本語メタデータを「意識せずに」提供できる状
況を作ることが可能。Win-Win関係は拡大するのでは？
83

本当の「日本化」に向けて前提から考える• ディスカバリサービスは「豊富な英語コンテンツありき」のシステムであった• 日本的な思想を反映させるためには「豊富な日本語コンテンツ」があることが前提であり、それが日本化を後押しする目標を再認識する• 日本化は日本語対応のみを意味するものではない。日本的なきめ細やかなユーザビリティの向上等を広く含んでの日本化である
誰が何をすべきかを考える• 図書館とそのステークホルダには、Win-Win関係構築のためにも、継続的に収録メタデー
タの分野と時代の厚みを増していく努⼒が必要である

ディスカバリサービスの「日本化」の向こうには、ディスカバリサービスを通しての日本語学術情報の「グローバル化」が⾒える。国としての姿勢も今後問われるかも？？
84

ご清聴ありがとうございました85