日経新聞(5/10)でも取り上げられたようなのでご存知の方も多いでしょうが，
大学共同利用機関法人 人間文化研究機構では，
研究資源共有化事業が進められています．
その柱は，1)データベースの拡充，高次化と 2)研究資源を共有するための情報環境の創出です．
1)に関しては，各研究機関が持つデータベース(以下，DB)の質的・量的拡充とGISデータの作成等が行われています．また，2)に関しては，「研究資源共有化システム」と総称する情報システムの開発が行われています．
今回は，2008年4月から公開になった
「研究資源共有化システム」について書いてみたいと思います．
なお，このあたりの事情は，2008年3月14日に行われた研究資源共有化シンポジウム
「研究資源共有化 - その展開と可能性 - 」に講演予稿集がアップされていますので，そちらも併せてご参考下さい．
1. 研究資源共有化システムの概要事業紹介ページによれば，このシステムは以下の3システムから成ります(2006年度から開発開始，2008年4月から運用開始)．
- 統合検索システム
- DBシステム．各研究機関が公開しているDBの横断・統合検索を実現する．
- nihuONEシステム
- DBシステム．研究者自身による容易なDB作成，研究支援機能を持つ．2008年5月16日現在，非公開．近日公開予定らしい．
- GT-Map/GT-Timeシステム
- アプリケーション．時間情報や空間情報（地理情報）に基づいた分析を可能にする．2008年5月16日現在，非公開．近日公開予定らしい．
2，3はまだ一般公開されていません．また，ryojin3的に最もホットなトピックは統合検索システムだと考えているので，そこについてまとめます．
2. 統合検索システムの概要統合検索システムは，人間文化機構を構成する5研究機関が提供する108のDBに対して，一括で横断検索，個々のDBが持つ時間・空間情報を用いた統合表示ができるシステムです．
以下は対象となる5研究機関です(トップページではなく，個々のDB紹介ページにリンクしています)．
また，各機関のサイトから
統合検索システムへのリンクが貼られています．
統合検索システムのシステム構成は以下のようになっています．
図は以下から抜粋しました．
各機関の情報システムのフロントにFront End System(以下，FES)とGate Way System(以下，GWS)が配置され，FESで各DBのメタデータの違いが吸収され，FESとGWSの連携により，ユーザはWebから横断検索が可能となります．
FESは，各機関の各DBの項目を共通のメタデータ項目にマッピングし，マッピング情報をメタデータデータベース(以下，MDB)で保持するシステムです．図を見ると，サーバサイドのMDB検索システムやOAI-PMHのリポジトリ機能も備えているようです．
また，GWSとは，異なるプロトコルや媒体を使う他のネットワークシステムに接続するためのソフトウェア(いわゆるゲートウェイ)のことを指し，ここでは，Webブラウザからの検索要求をFESに渡すクライアントサイドのMDB検索システムになります．プロトコルには図書館管理システムでよく使われている
Z39.50と
SOAPを用いてXMLで要求を送る
SRW(Search/Retrieve Web Service)が採用されています．
他にも，検索システムの運用管理に特化したシステム，共通ユーザインターフェースの採用等，面白い試みがなされていますが，ryojin3が一番気になるのは，やはり，どうやって108ものDBの項目を「共通のメタデータ項目」にマッピングしているのか，という部分になります．
3. 統合検索システムにおける共通メタデータ山本泰則: "データベース横断検索のための共通メタデータ - 統合検索システムにおける定義と2つの課題 - ", 人間文化研究機構研究資源共有化シンポジウム「研究資源共有化 - その展開と可能性」講演予稿集, pp.16-21, 2008.(PDF)によれば，このシステムで採用している共通メタデータには，以下の3種類があります．
- Dublin Core
- 基本15エレメントを用いている．精密化(qualifier)はしていない(方言が多いから??)
- 5W1H
- 時空間情報
これらのメタデータに以下の規則を適用したようです．
NIHUメタデータマッピング規則(以下は論文の抜粋で，全規則は現在未公開のようです)
- Dublin Core(以下，DC)
- 原DBでの表示対象情報はすべて表示．つまりDCのいずれかに割り当てる．
- Resourceの内容が対象とする時間範囲はDCのCoverage(Temporal)とする．
- Resourceに起きた事象に関する時間情報はDCのDataとする．
- Resourceの内容が対象とする地理的情報はDCのCoverage(Spatial)とする．
- Resourceが製作あるいは使用された地理的情報はDCのCoverage(Spatial)とする．
- 5W1H
- マッピング対象はWho，What，When，Whereとする．
- 文で記述された情報や備考，上記4つにマッピングできない情報はOtherにマッピングする．
- 時空間情報
- 原DBでの記述表現は適切と判断される数値範囲に変換する．
- その他
- DCでは別途検索用，結果表示用のメタデータを設ける．
- 原DBの各項目を上記それぞれのメタデータ及びAnyに独立でマッピングする．
- 5W1Hは検索のみで使用し，結果表示はDCを用いる．
4. マッピングの課題NIHUメタデータマッピング規則を策定するにあたり，様々な課題があったようです．
- モノ情報に関する問題
- 原DBが管理するモノはDCの場合，Resource(資源)かContents(内容)か．
- DCの場合，(楽器や土器等)モノによってType，Subject，Description等複数の項目に割り当ての可能性がある．
- 時間情報に関する問題
- DCのResourceに生じた時間情報(製作時期，使用年代等)はDCのDateが適用．
- DCのCoverageには資源の内容が表している時間的な範囲がある．
- 空間情報に関する問題
- DCのCoverage(Spatial)が有力だが，資源そのものの空間的情報(製作地，使用地等)は記述項目がない．
- DBによって表記が様々．「縄文時代中期」とか「ジャワ島東南部海岸地域」等．
- Creator情報に関する問題
- 例えば何らかの演奏の場合，DCのCreatorは演者か，記録者か．
- モノと時間に関する問題
- ex)手紙：当初は内容が重要だが，時代を経ると素材や折り目等，素材も重要になる．
- 一般的な問題
- DCにマッピングすることで，個々の要素の定義や意味があいまいになる場合がある．
- DCのAnyを用いることで一部回避しているが，原DBの全項目のマッピングが本当に必要かどうか検討を要する．
- 時空間情報では一部矩形範囲に正規化したが，それが妥当かどうか検証を要する．
- DCのDumb-Down規則に反する部分が出てきた．
ryojin3の考察さて，一連の概要を読んでの考察です．
今回は人間文化研究機構の研究資源共有化事業の1つである研究資源共有化システム，それも統合検索システムのみをフォーカスして書きました．
このシステムは，100を超える人文系DBを共通メタデータと1つのインターフェースで連動させたという点で，高い利便性が実現できたと言うことができると思います．
もちろん，これまでにも博物館情報を連携する同様の試みはいくつかあります．
例えば，
前回書いた国立美術館の情報連携や文化遺産オンラインもそうですし，自然科学系の分野では，
地球規模生物多様性情報機構(GBIF：Global Biodiversity Information Facility)の試みがあります．GBIFでは，
Darwin Coreという標本・観察データを記述できるXML形式の標準と
専用プロトコルを用い，動物・植物・微生物・菌類・タンパク質データや生態系データにいたるまで，様々な機関で蓄積された種々のデータを世界規模で相互利用しようとしています．
自然科学系は対象が違いすぎるので，また別の機会に掘り下げるとして，人文科学系の博物館情報の連携という観点でこのシステムを見てみると，やはりそこではメタデータマッピングにおける意味的なずれが生じていることが問題となっています．
山本氏は論文の最後で，このシステムを用いても全DBをあたかも1つのDBのように利用できることにはならない，と締めくくっています．氏は個々のDBができた経緯から共通メタデータの限界に触れ，キチンとした横断検索を実現する手段として，統合検索システムで全DBをスキャンし，関心があるDBについては個々のDBを精密に検索する，そのような二段構えの仕組みが必要だとしています．
ryojin3もこの意見には賛成です．ただ，どうせなら全DBをスキャンした段階である程度ユーザが欲する(と思われる)ジャンル(スキーマ)を提示できる仕組みがあると，なおいいなと考えています．
