人間文化研究機構研究資源共有化シンポジウム「研究資源共有化 ―その展開と可能性―」

講演予稿集

2008 年 3 月 14 日

人間文化研究機構

研究資源共有化シンポジウム開催にあたって

人間文化研究機構では、その保有する研究データベースを統合的に検索する研究資源共有化システムの開発を共有化推進事業として 2005 年より進め、本年 4 月から一般に公開することになりました。このシステムでは、本機構を構成する５研究機関－国立歴史民俗博
物館、国文学研究資料館、国際日本文化研究センター、総合地球環境学研究所、国立民族学博物館が提供する 100 を越えるデータベースを横断検索する基本機能に加え、個々のデータベースが有する時間・空間の情報を用いて統合的に検索し、表示する機能を実現しています。そして、研究成果を容易に公開できる研究支援機能を有するシステムを開発してきました。
この事業を進めるにあたり、人文科学の多種で多数のデータベースを横断検索する方法、そのユーザインタフェース、多様な時間・空間情報の扱いとその知識ベースの構築など、幾つかの課題を解決してきました。この開発の成果を公表するとともに、より広く高度な研究資源共有化を展開するための討議の場としてシンポジウムを開催いたします。
2008 年 3 月 14 日
人間文化研究機構
研究資源共有化推進タスクフォース
プログラム委員会

人間文化研究機構研究資源共有化シンポジウム

研究資源共有化 ―その展開と可能性―

日時：2008 年 3 月 14 日（金） 10:00～17:00
場所：情報・システム研究機構会議室
プログラム
総合司会

合庭 惇（国際日本文化研究センター）

10:00～10:15
開催挨拶
石井米雄（人間文化研究機構 機構長）
10:15～12:00
研究資源共有化システム − 探すから知的再生産ツールへ −及川昭文（総合研究大学院大学／
人間文化研究機構 客員教授） ------------- 1
研究資源共有化システムにおける統合検索システム
安永尚志（人間文化研究機構客員教授） ---------------- 9
データベース横断検索のための共通メタデータ― 統合検索システムにおける定義と 2 つの課題 ―山本泰則（国立民族学博物館） ----------------------------- 13
12:00～13:00＜休憩＞
13:00～14:45
文化資源研究情報統合検索のためのユーザインタフェース
安達文夫（国立歴史民俗博物館）-------------------------- 19
空間情報に基づく情報解析ツール
原正一郎（京都大学 地域研究統合情報センター／
人間文化研究機構 客員教授）-------------- 27
時間情報に基づく情報解析ツール
関野 樹（総合地球環境学研究所）----------------------- 35
14:45～15:00＜休憩＞
15:00～16:55
パネル・ディスカッション「時間空間テーマで探る・解く・語る人間文化」
司会
柴山 守（京都大学 東南アジア研究所／
人間文化研究機構 客員教授）
久保正敏（国立民族学博物館）文化情報資源の時空間概念モデル -------------------------------- 41
花島誠人（地域開発研究所）
五島敏芳（国文学研究資料館）
高橋一樹（国立歴史民俗博物館）
相田 満（国文学研究資料館）
16:55～17:00
閉会挨拶
朝岡康二（人間文化研究機構 理事）
基調

研究資源共有化システム－探すから知的再生産ツールへ－

及川 昭文

藤沢 桜子

洪 政国

山元 啓史

総合研究大学院大学
人間文化研究機構

人間文化研究機構

日本 IBM

オーストラリア国立大学

一般的に人文系のデータベースは標準化が困難で，研究者それぞれの研究内容や成果と深く関連している。さまざまな研究資料がデータベースとして共有化されることは，その分野の研究の発展には重要な要素であるが，まずはそれぞれの研究者のニーズに応えたデータベースが作られることが必要となってくる。エンジニアの支援なしに人文系の研究者がデータベースを作成，インターネットで公開できるようにするためには，研究支援ツールとしての DBMS を構想する必要がある。簡単な手順でデータベースの定義，作成そしてインターネットでの公開ができる nihuONE と呼ばれるデータベース・システムの開発を試みた。このシステムが目標としているのは，エンドユーザが研究のさまざまな場
面で活用できる研究支援ツールとしての機能の充実である。

Academic Resource Sharing System as the Tool for Academic Activities
Akifumi Oikawa

Sakurako FujisawaJung-Kook Hong

Hilofumi Yamamoto

The Graduate Univ. for
Advanced Studies
National Institutes for
the Humanities

National Institutes for
the Humanities

IBM Japan, Ltd.

The Australian
National University

It is difficult to standardize databases in the humanities because the styles and formats of humanity database
deeply depend on the contents and results of each study. First, it is necessary to produce a database which satisfies
the demands of researchers. Secondly it is essential to share a database with other researchers for the progress ofstudies. It is necessary to develop a new concept of DBMS which enables researchers of the humanities to easily
manage their own data without the assistances of computer technicians. We have been developed a new DBMS
called "nihuONE" which is designed as not only a traditional database system but also a research tool. Our systemallows users to create their database and transfer it to the internet server. The goal of our system is to enhance thefunctions which will be available in various aspects of research scenes.

とにつながっていくことになる。
今回，研究資源共有化システムのサブシステム
として開発されたデータベース・システム（以下，nihuONE）は，データベースを活用するための機能を拡充し，これらの機能を使いこなすことによって，データベースを利用した知的再生産の実現を図ろうとするものである。[1]1．はじめに
研究資源共有化推進事業では，人間文化研究機
構（以下，機構）を構成している 5 つの研究機関に蓄積されているさまざまな学術情報を，いつでも，どこからでも利用できる情報環境を構築する
ことから始まったが，この「利用できる」ということには，いくつかのレベルが考えられる。
まず，必要とする学術情報の所在を探しだすということがある。簡単に所在を探せるようにするには，これらがデータベースとして整備され，検索システムが準備されていなければならない。また，複数のデータベースを横断して，必要とする情報を検索できることも重要な要件となる。
つぎに，探し出した学術情報を分析したり，自分の研究に適したように編集したり，新たなデータを追加したりといった利用が考えられる。学術情報を「探す」だけでなく，研究に「活用する」ということで，それは学術情報の再生産というこ

2．nihuONE の概要
nihuONE は 2006 年度に初期開発を終了し，2007
年の 4 月に試行運用を開始した。データベースの新規作成や移植を行いながら，機能・性能についての評価を行った。その結果に基づき機能追加，性能向上のための第 2 次開発を実施した。この開発は 2007 年 10 月末に完了し，現在第 2 次開発に含めることができなかったいくつかの機能追加のための第 3 次開発を行っている。これは 2008 年 3月までに終了し，4 月から正式な運用を開始する-1-

徴としては，・XML 形式のテキストであればそのまま登録できる（RDBMS のように DTD やスキーマ宣言をする必要がない）。
・索引を作成する必要がない（データベースの更新に時間がかからない）。
・複数検索一括処理で多重アクセスを同時処理できる（検索時間が短くてすむ）。
などを挙げることができる。nihuONE の開発においては，これらの特徴を最大限生かすことを心がけた。

予定となっている。
2.1 知的再生産ツールとしての要件
nihuONE が人文系の研究者にとっての知的再生
産ツールとして機能するためには，すくなくとも
次の二つの要件が満たされている必要がある。
ひとつは「SE やプログラマなどの情報技術者の支援なしで，データベースの作成から Web での公開までできる」ことである。[2]多くの研究者は研究に必要な資料やデータをカードにしたり，図表にしたり，あるいはファイル
フォルダーにまとめたりして整理している。デー
タベース化とはこれらの資料やデータをコンピュータ上の仮想空間に移し替える作業，すなわち，
コンピュータが処理できる，管理できる形態への変換作業である。この変換作業を研究者が日常的に行っている資料やデータの整理作業の延長として行えれば，データベース作成は困難なものでなくなってくる。nihuONE では，データベースについての基礎的な知識さえあれば，この作業を容易に行えるようにさまざまな工夫を凝らしている。
もう一つは「単なる検索ツールとしてではなく，データベースを活用できる研究支援ツールとして機能する」ことである。本来データベースは蓄積されたデータを分析したり，人事システム，給与システムあるいは大学における学務システムなどのようなある特定の業務を効率よく運用することを目的として開発，発展してきたものである。しかし，情報化時代の到来とともに大量の情報の中から必要なものを探し出す，いわゆる検索機能が重要視されるようになった。その結果，検索やそれに関連した機能や性能は格段に充実してきているが，データベースに格納されているデータを分析したり，活用するための機能は不十分なままにあるのが現状である。nihuONE は，検索機能のみ
でなくデータベースの分析やそれらを活用するための機能の充実を図った。

システム管理・運用モジュール
DB 活用
モジュール

・利用者管理 ・DB 登録 ・利用統計

XML 型
データベース
エンジン

DB 管理
モジュール

・統計処理
・ダウンロード

Shunsaku

・DB 定義
・項目定義
・表示定義

………

………

検索モジュール

図1

nihuONE の構成

それぞれのモジュールの主な機能は以下のようになる。
システム管理・運用モジュール
・利用者の管理（登録・削除・編集など）
・データベースの登録・削除
・利用統計
・システムのバックアップとリカバリ
データベース管理モジュール
・データベースの管理
・項目定義
・表示（一覧，詳細）定義
検索モジュール
・検索（横断検索，詳細検索，絞込検索，数値検索，
KWIC 検索など）活用モジュール
・統計処理
・ダウンロード

各モジュールは，それぞれの改変やバージョン
アップが他のモジュールに影響しないように，可能な限り独立性を保持するようにした。

2.2 nihuONE のソフトウェア構成
図 1 のように nihuONE は XML 型データベース
・エンジンである Shunsaku を核としているが，開発においては，製品版のまま利用することにした。
これは Shunsaku をカスタマイズすることによって生じるシステム管理・運用の煩雑さや経費増などを避けるのが大きな理由であった。Shunsaku の特3．マイ・データベースの実現
一般的に人文系のデータベースは標準化が困難
で，研究者それぞれの研究内容や成果と深く関連-2-

のデータをもとに MyDB を作成する。
③既存のデータベースを加工，再編集したり，あるいは新しい資料を追加したりして MyDB を作成する。
いずれのケースでも，単純かつ容易な作業でMyDB を作成できることが，システムとしての機能要件になる。たとえば①の場合，Excel などは使えなくても，ワープロなどで決められた書式でデータをテキストとして入力すれば，それがそのままデータベースにアップロードできること。②の場合では Excel ファイルを CSV 形式のファイルに変更するだけでデータベースにアップロードできること。③の場合であれば，既存のデータベー
スから必要な項目を CSV，タブ区切りなど多彩な形式で簡単にダウンロードできることなどである。

している。したがって，対象となる資料が同じであっても，作成されるデータベースは研究者ごとに異なったものとなる性質を本質的に持っている。
研究資源の共有化はその分野の研究の発展には重要な要素であるが，個々の研究者の知的生産を支援するためには，まずそれぞれの研究者のニーズに応えたデータベース（以下，マイ・データベースと呼び，MyDB と称する）が作られることが肝要となってくる。[3]多くの場合，データベースは周到な準備を経て，組織的，計画的に作成されるものであるが，研究者個人が分析の対象として，あるいは研究の成果をまとめるために MyDB を作成する場合には，まずは作ってみて，不具合があれば項目の定義を変更したり，再編集したり，試行錯誤を繰り返しながら作られていくことになる。これらの作業を人
文系の研究者が容易に行うことができるためには，
以下のような要件が満たされている必要がある。

3.2 容易な定義変更
MyDB は研究と密着したデータベースであり，研究の進展に伴って，項目追加や項目の属性や内容の変更が必要となることが少なくない。また，研究の結果をデータベースに反映し，そのデータベースを再び分析に活用するということもある。
つまり，研究の進展にともなってデータベースの構成や項目定義の変更を容易に行えることが不可欠になってくる。
たとえば，検索結果一覧で表示する項目は，データベースを作成したあとでも，図 3 のように「項3.1 作るのが簡単
MyDB の作成過程としては，以下の 3 つのケースが想定される。
① 1 次資料を集めることから始める。あるいは 1
次資料は収集済みであるが，電子化はまだで，まったくゼロから MyDB を作成する。
② 1 次資料の電子化はできており，Excel などのソフトを利用してそれなりに活用している。こ①1次資料の収集，あるいは②excelなどで作成されているデータをもとにMyDBを作成する。

イノシシデータベース

電子化から始めて，MyDB作成に取りかかる。

貝釧データベース
土師器データベース
前方後円墳データベース

貝塚データベース
貝塚文献データベース
遺構データベース

nihuONEに 新 し い DBを 定
義 し ， PC上 で編 集し たデータをアップロードする。

遺物データベース③既存のデータベースから研究に必要なレ
コードを検索し，必要な項目を選んでダウンロードする。研究目的に対応して新しいレコードや項目の追加，データの編集や加
工を行う。

図2

マイ・データベースのイメージ-3-

目定義」をやり直すことによって簡単に変更できる。

ならない。むしろ，システム管理者に依頼しなくても，自分の判断でそれぞれのデータベースを管理・運用できることは大きな利点ということがで
きる。
表1
区

分

admin

DB 管理者

図3

nihuONE の利用者区分
権限・役割など

システム管理者で，.一人だけ登録できる。
その役割は利用者の管理，データベースの登
録・削除，利用統計の閲覧，システムのバッ
クアップ・リカバリなどである。
データベースの管理・運用を行う者で，各データベースに必ず一人だけ設定する。

認証を必要とするデータベースの閲覧やデー
登録利用者 タのアップロード・ダウンロードの権限を付与された利用者である。

一覧表示の定義画面

一般利用者

3.3 システム運用と DB 運用の分離
一般的に DBMS の運用においては，システムの管理とデータベースの管理は同じ管理者が兼ねることが多い。このため DBMS に収録されるデータベースが多くなればなるほど，管理者の運用に関わる負荷は大きくなる。結果として，それぞれのデータベースのアップデートや保守に支障をきた
すことが少なくない。nihuONE ではこのような状況を回避するために，システム運用とデータベース運用を完全に分離している。
nihuONE の利用者は表 1 のように 4 種類に区分される。nihuONE での基本的なデータベース作成
プロセスは，①データベースの登録 → ②データ
ベースの定義 → ③項目の定義 → ④表示（一覧，詳細）形式の定義 → ⑤データのアップロードとなる。このプロセスにおいて，admin が関与するのは，①のデータベースの登録のみである。
この登録処理では，「データベース識別記号」と「データベース管理者」の設定を行い，それ以後の作業はすべてデータベース管理者の仕事となり，システム管理者はデータベースの管理・運用の作業から解放されることになる。このことは多数のデータベースを公開，運用している部署にとっては，システム運用にのみ専念すればよく，非常に大きなメリットとなる。
一方データベース管理者は，自分が作成し，その内容を熟知しているデータベースのみを管理するわけであるから，たとえ複数のデータベースを管理するとしても，運用の作業は大きな負担とは

一般公開されているデータベースのみを閲覧できる利用者である。

3.4 項目定義と品質管理
データベース管理者がデータベースを作成するにあたって，最も重要な仕事は項目定義である。
項目定義では表 2 で示す属性を各項目ごとに設定することになる。
この項目定義は画面上で行うが，事前に Excelなどで作成しておき一括してアップロードすることもできる。また定義が終了した時点で CSV ファ
イルとしてダウンロードする機能もある。
項目定義は，既に入力されているデータの内容との整合性が保証されれば，データベース作成後に変更することもできる。たとえば，検索項目となっていない項目をあらたに検索対象としたり，区切り文字を追加したり，最小値や最大値の値の変更などである。また，項目そのものを新しく追加したり，削除することも可能である。
データベースの利用価値を左右するものの一つ
はデータの品質である。nihuONE においては，デー タ の 品 質 を 高 め る た め の 品 質 管 理 （ Quality
Control，以下 QC）機能を充実させた。QC は項目
定義でパラメータを入力しておくことで，データのアップロード時に実行される。表 2 は項目定義で設定しなければならない属性の一覧であるが，そのうち属性の欄が塗りつぶされているものはQC 項目である。
データ型チェック：その項目が表 2 の「データ型」のどれにあたるかは必ず指定しなければなら

-4-

表2
属

性

内

項目定義

－属性一覧－

容

タグ番号

項目を識別する3桁の数字

名

項目名称

称

注 2：「デリミッタ項目」とは，一つの項目に複数のキーワードなどがあらかじめ指定された区切り文字（デリミッタ）
で区切って入力されている項目のことである。たとえば，
区切り文字「；」で区切られたテキスト「情報処理；データベース；XML」などが入力されている項目。
注 3：デリミッタ項目の場合，区切り文字で区切られた文字列単位でソーティングして格納しなおすかどうかを指定する。
例えば，「アサリ，シジミ，マシジミ，ハマグリ」と入力されていた場合，これを「アサリ，シジミ，ハマグリ，マシ
ジミ」とソートする。

表示名称

一覧表示などの際に表示する項目名称

ID

ID項目かどうかの指定（Yes/No）注1

データ型

データの種別を表すコード
1＝テキスト（全角のみ）
2＝テキスト（半角のみ）
3＝テキスト（全角，半角）11＝数値（カンマ，小数点を含まない）
12＝数値（カンマを含む）
13＝数値（小数点を含む）
14＝数値（カンマ，小数点を含む）
20＝ファイル

最小値

データ型が数値の場合の最小値を指定（不明の場合は空白）

最大値

コードが数値の場合の最大値を指定（不明の場合は空白）テキスト長

コードがテキストの場合の最大バイト長を指定（不明の場合は空白）

必須項目

必須項目の指定（Yes/No）

検索対象

検索対象の指定（Yes/No）

KWIC検索KWIC検索対象の指定（Yes/No）

区切り文字

デリミッタ項目 注2の場合，使用する区切り
文字。

ソート

デリミッタ項目の場合，区切られた文字列
単位でのソーティングの指定注3

html

htmlテキストかどうかの指定（Yes/No）

頻度統計

検索結果の集合に対して頻度統計の対象とするかどうかの指定（Yes/No）

基本統計

検索結果の集合に対して基本統計の対象とするかどうかの指定 （Yes/No）

Table変換

Tableを利用したテキスト変換の指定

リンク対象

他のデータベースへのリンク指定ない。それぞれの項目データがこの指定に適合しているかどうかを調べる。
ペアチェック：文献目録データベースなどで「著者名」「著者名よみ」のように必ず同時に存在しなければならない項目があった場合，いずれかが欠落していないかを調べる。
Table 変換：入力されたデータが，DB 管理者によってあらかじめ登録されているテーブルに含まれているかどうかを調べる。テーブルには変換する値（数値でもテキストでも可）も設定されており，エラーがなければその値を指定された項目のデータとして展開する。
デリミッタ項目の 2 重チェック： たとえば「シジミ，アサリ，ハマグリ，カキ，アサリ」と入力されたデータを，「アサリ，アサリ，カキ，シジミ，
ハマグリ」とソーティングし，同じ文字列がある
場合は自動的に削除する。
辞書チェック，辞書変換：あらかじめ nihuONEにデータベースとして登録されている辞書と照合し，入力されたデータがその辞書に含まれているかどうかを調べる。また，エラーがなければ，その辞書の任意の項目値を新しい項目データとして展開する機能もある。
3.5 SDF 形式
レコード・データを一括してアップロードする
ファイルの形式としては，CSV，タブ区切りなどが一般的であるが，nihuONE ではこれらの形式の他に独自の形式として SDF（Standard Data Format）と名付けた形式を取り扱えるようにした。
SDF とは図 4 のように「タグ番号」「｜（区切り文字として使用）」とデータから構成されたテキ
ストファイルである。したがって，ワープロなどで作成したり，編集することが可能となる。このSDF 形式を設定した主な理由は，CSV，タブ区切りの形式ではテキスト中に「改行」の制御文字を含めることができないからである。

ペアチェック 著者名と著者名読みのように必ず同時に存在する項目の指定
辞書チェック 辞書を参照してその辞書の中に存在するかどうかをチェックする
公開・非公開 公開・非公開の指定
ダウンロード ダウンロードの可否の指定
注 1：複数の項目を ID 項目として指定できる。その場合すべての項目値を連結したものが ID として認識される。

-5-

たとえば，最近文献目録データベースなどに「目次」という項目を設定し（図 4 参照），そこに目次の見出しを「／」などの文字で区切って入力する例が多く見られる。しかし，見出しが多数ある場
合は非常に読みにくくなる。この「／」を「改行」にすれば，図 5 のように見やすくなる。
また，一つの項目のデータが長い場合（たとえば，貝塚データベースの出土している貝類の名称を入力する項目で，非常に多くの貝が出土している場合，テキスト長が 3000 バイトを超えるレコー
ドがある），Excel の一つのセルで画面がいっぱいになり，編集がやりにくいということも理由の一つである。

3.5 リンク機能
データベース中に「参考文献」といった項目がある場合，通常「書名，著者名，発行年月日」等の書誌情報が入力されている。nihuONE では，このような階層的な関係を持つデータを「リンク機能」を用いて表現できるようにした。具体的には
次のような手順で実現する。
1）項目定義の際に，あらかじめリンクするデータ
ベースの識別記号を設定する。この項目を「リンク項目」と呼ぶ。設定できるデータベースは
nihuONE に登録されていればどのデータベースでも可能である。すなわち同一データベース
中の他のレコードにリンクすることもできる。
2）リンク項目にリンク対象となるデータベースのレコード ID を入力しておく。
3）詳細表画面で，リンク項目に表示されている ID
をクリックすれば，当該レコードが別画面で表示される。
具体的に示すと，図 6 は貝塚データベースの検索結果の詳細表示であるが，「関連文献」がリンク項目となっており，ここにある「貝塚文献データベース」のレコード ID（たとえば 020011）をクリックすると当該文献が表示される。

010|10001
020|鉅野県発見『父母恩重経』の『省略経』の新資料〈鉅７〉について040|新井 慧誉
070|豊山教学大会紀要
090|第 30 号
100|13 東京
110|豊山教学振興会
120|2002/11/1
130|p17-28
150|石碑の概要／石碑建立のいきさつ／〈鉅 7〉のテキスト／経文の検討／結語
160|630
170|690210|0388-2500
;

図4

図5

3.6 ファイル型項目の活用
項目属性のデータ型に「ファイル」がある（表 2参照）。この項目に入力されるのはファイル名で，ファイル本体は事前に nihuONE のサーバ上に転送しておく。詳細表示画面でこのファイル名をクリックすると，ブラウザがファイルの拡張子に応じた処理を実行する。
図 7 は幕末明治地勢地図の詳細表示で項目「索引地図」に入力されている pdf ファイル名をクリ

SDF 形式の例

テキスト中に改行を挿入した例

図 6 リンク項目の例（貝塚データベースと貝塚文献データベース）-6-

ックすると図 8 のような地図が表示される。利用者はこの地図をダウンロードして自由に利用することができる。［4］図7

さまざまに活用することがデータベース構築の本
来の目的である。nihuONE では，データベースそのものを分析する機能や活用を容易にするためのダウンロード機能の充実を図った。

幕末明治地勢地図の詳細表示

図9

図8

国立民族学博物館にある画像の表示例

4.1 統計処理機能
検索して得られたレコード集合に対して統計処理を実行する機能で，「基本統計」と「頻度集計」の 2 つがある。
基本統計：データ型が「数値」の項目に対して「最小値，最大値，平均値，標準偏差値」を計算する機能である。
頻度集計：項目にデータとして入力された文字
列単位でその頻度を集計する機能で，デリミッタ
項目の場合にとくに有効である。2 つの項目までのクロス集計も可能で，さまざまな分析の基礎資料として活用できる。
基本統計や頻度集計の結果は CSV 形式でダウンロードできる。図 10 は貝塚データベースの出土遺物である「哺乳類」の集計結果をダウンロードし，
Excel で若干の編集を行い表示した例である。

pdf による地図

これらのファイルが nihuONE 以外のサーバに格納されている場合は，別の方法で同じような処理を実現できる。項目の属性を“html”と指定することによって，その項目に入力された文字列はhtml テキストとして解釈される。たとえば，<a href='http://www.minpaku.ac.jp/… /mcd5/083.jpg'> の よ うに入力しておけば，nihuONE 以外のサーバに格納されている画像が表示される。図 9 はその例であり，ここに表示されている画像は国立民族学博物館のサーバに格納されているものである。［4］4.2 ダウンロード機能の充実
nihuONE では以下のようにさまざまな場面でダウンロード機能を利用できるようになっている。
ただし，一般の利用者が利用できるのは⑤～⑦の場合のみである。
①利用者管理⑤検索結果一覧②データベース定義⑥ KWIC リスト
③項目定義
⑦統計処理
④詳細表示

4．検索ツールから活用ツールへ
文献目録などの類のデータベースはいわば参照
情報を提供するためのデータベースであるが，現在 nihuONE で公開されている貝塚データベースな
どは，データベースそのものが分析対象となるものである。もちろん貝塚データベースを参照目的で利用することもあるが，検索結果を対象として-7-

5．おわりに図 10

nihuONE は「データベースを作る，検索する，活用する」を目標に掲げて開発を進めてきた。すなわち，単に情報を探すだけでなく，データベースとして蓄積されている情報を，さまざまに活用できるツールを提供することによって，知的生産支援を実現しようとするものである。
開発にあたって重視したことは，SE などの技術者の支援なしでも研究者自身の手でこれらのツー
ルを容易に使いこなせるようにすることであったが，試行結果から目標はほぼ達成できたのではな
いかと判断している。今後の課題としては，これらのツールをより充実させていくことであり，まずは時空間システムをはじめとするアプリケーション・ソフトとのスムーズな連携ツールを実現していくことを計画している。

頻度集計結果を excel で表示検索された各レコードのデータをダウンロード
する機能はほとんどの DBMS に標準的に装備されているが，検索結果一覧や KWIC リストなどのデータをダウンロードするには，複雑な操作や利用者側でマクロを組むなどの作業が必要であり，人文系の研究者にそれを望むのは，多くの場合困難である。
nihuONE においては，たとえば，KWIC リスト
を取り込みたい場合は，KWIC 検索を実行し，その結果を CSV ファイルとしてダウンロードする。
図 11 はダウンロードしたファイルを Excel で表示した例であるが，これらのデータをワープロに取り込んで編集することも容易に行える。
基本統計や頻度集計の結果も，同じように CSV
ファイルとしてダウンロードできるようになっており，Excel などの表計算ソフトを使って，より高度な統計的分析などを行うことも可能になる。
得られたデータをどのように活用するかは利用者側の課題であるが，ダウンロードできる場面を数多く設定することで，データベースの活用の機会が拡がることは間違いないであろう。

謝辞
nihuONE の運用テストのために身装関連データ
ベースの移植を行ったが，国立民族学博物館の関係者，とくに中川隆氏，また，大阪樟蔭女子大学の高橋晴子教授からは多大な協力を頂きました。
ここに記して感謝いたします。

［1］及川昭文，藤沢桜子，洪政国，山元啓史「研究支援機能を強化したデータベース・システムの開発」じんもんこん 2007 論文集，pp.229-236，2007［2］及川昭文，山元啓史「Web 公開のためのデータベース・エンジニアリング」情報処理学会研究報告
CH-49，pp.49-56，2001［3］及川昭文，山元啓史「研究者のためのマイ・デー
タベース・システムの開発」第 13 回公開シンポ
ジウム「人文科学とデータベース」論文集，pp.25-34，2007［4］鎌田聖子，及川昭文「幕末明治地勢地図境界デー
タの作成」じんもんこん 2007 論文集，pp.205-212，
2007［5］中川隆，高橋晴子，及川昭文「民博コスチューム
データベース(MCD)の過去・現在・未来」じんもんこん 2007 論文集，pp.229-236，2007

図 11

KWIC リストを Excel 上で表示

-8-

研究資源共有化システムにおける統合検索システム
安永尚志
大学共同利用機関法人人間文化研究機構

１．はじめに2008 年 4 月より，人間文化研究機構の研究資
源共有化システムが一般公開される．人文研究
資源共有化事業（以下，共有化事業）として，2005 年度より 3 ヶ年に渡って，システム開発とその環境整備が進められてきた．
このシステムでは，機構を構成する 5 研究機
関（国立歴史民俗博物館，国文学研究資料館，
国際日本文化研究センター，総合地球環境学研究所，国立民族学博物館）が提供する 100 を越えるデータベースを一括して横断検索することができる．また，個々のデータベースが持つ時
間・空間の情報を用いて，統合的に検索し表示する機能を実現している．
このシステム環境を，研究資源共有化システ
ムにおける「統合検索システム」と言う．統合
検索システムの開発に当っては，人文科学の多種で多数のデータベースを横断検索する方法，
そのユーザインタフェース，多様な時間・空間
情報の扱いとその知識ベースの構築など，幾つかの課題を解決してきた．
ここでは，統合検索システムの考え方や構成などについて述べる．なお，技術要素などの詳細については本シンポジウムの中で報告する．

すなわち横断検索を行う．個々のデータベースの操作法の違いや所在を意識しない．
⑤ 検索及び結果の高度処理を行う（時空間情報解析システムなど）．
⑥ 可能な限り，国際標準技術を用いる．
⑦ 先行研究成果などを活用する[1][2]．
⑧ 当面，5 機関を対象とするが，将来他機関などへの接続を考慮する．
これらに従って，統合検索システムは[1][2]に基づいて，次の 3 要素を柱として構築した．
① XML による標準的なデータ記述．
② メタデータ（Dublin Core を主とする）によるデータベースの違いの吸収．
③ 国際標準検索プロトコルによる検索手順の一元化（Z39.50 及び SRW:Search/Retrieve
Web service）．
なお，共有化事業では，機関の既存データベ
ースの高次化計画（画像情報やデータの追加，見直しなど）が同時に進められた．
óòópé“WebäÓñ{ÉVÉXÉeÉÄ
ÅiGWS ÅCFES ÅjÅc

5 ã@ä÷Å@GWS

Internet
Web ÉTÅ[Éoã@î\ã@ç\

ã@ç\Å@
MGR

åüçÐÉVÉXÉeÉÄ
Å[WebÉQÅ[ÉgÉEÉFÉCã@î\Åiâ^ópä«óùÉVÉXÉeÉÄÅj

ä«óùâ^ópÉVÉXÉeÉÄ

ÉÅÉ^ÉfÅ[É^åüçÐÉVÉXÉeÉÄ
ÉTÅ[Éoã@î\InternetåüçÐÉVÉXÉeÉÄÉNÉâÉCÉAÉìÉgã@î\ÉÅÉ^ÉfÅ[É^ä«óùã@î\ÉnÅ[ÉxÉXÉeÉBÉìÉOã@î\

2．システム構成
ÉnÅ[ÉxÉXÉeÉBÉìÉO

2.1 前提と要件(ÉQÅ[ÉgÉEÉFÉCÉVÉXÉeÉÄ
)ã@ç\äOFES

5 ã@ä÷

Internet

5 ã@ä÷Å@FESåüçÐÉVÉXÉeÉÄ
ÉTÅ[Éoã@î\(ÉtÉçÉìÉgÉGÉìÉhÉVÉXÉeÉÄ
)ÉÅÉ^ÉfÅ[É^ÉfÅ[É^ÉxÅ[ÉX
ã@î\

メタデータ
DB

ÉÅÉ^ÉfÅ[É^ïœä ã@î\
機構外
既存DB

機構外
既存DB

機構外
既存DB

機構外
既存DB

システムを設計するにあたり，以下の前提とäOïî å§ãÜã@ä÷ÎcÎc
要件の下に方針を定めた．
Åc① 5 機関の公開中の原データベースを共有
図１ システム構成概要図（当初計画）
化対象とする（2008.4 時点で 108 種類）．
② 原データベースには手を入れない．すな
2.2 システム構成
わち，再構築などをしない．
③ 利用者は人文科学研究者を中心とするが，システム構成の概要を図 1 に示す．当初計画
一般公開を行う．
で全体的な構想である．各機関には，専用の情④ 全データベースに対して，一元的な検索報システムに前置して，個々に FES：Front End
1ÉÅÉ^ÉfÅ[É^ïœä

既存DB

既存DB

既存DB

System 並びに GWS：Gate Way System を置く構成としている．FES により，メタデータによる
原データベースの違いを吸収し，FES と GWSの連携により，標準の一括した横断検索を実現する．利用者は Web アクセスにより，GWS を介して情報検索を実施する．
なお，現在のシステムでは，外部研究機関への接続は実装していない．ハーベスティングによるメタデータ集約を考慮している．

機関GWS

機関FES

（クライアント機能）（サーバ機能）利用者
Webサーバ機能
システム
HTTP
検索システム-Webゲートウェイ
機能システムXML
GTA

検索システムクライアント機能
システム

変換データベース

メタデータDB
・・
・

メタデータDB

機能を一体化した実装を行っている．
統合検索システムは，インフォコム株式会社
による製品 InfoLib-GlobalFinder を用いて開発している．
(2) MGRMGR は，機構に置く基本システムの 1 形態
であり，統合検索システム全体の運用管理に特化した機能を持つ．機関データベースの登録，削除，更新などの状況を把握し，利用統計，障害対策，資源管理，バックアップなどの運用管理を行う．さらに，共有化に共通する情報資源（例えば，地図，地名辞書データなどのコンテ
ンツ，高次処理用機能ソフトウェアなど）のサーバとして位置づけ，利用者からのダウンロードに対応する．
リポジトリ機能を実装している．OAI-PMH：
The Open Archives Initiative Protocol for Metadata
Harvesting による．現在，外部機関との接続は行っていないが，機関 FES からの運用管理情報の収穫などで用いている．
一方，基本システムに対する運用管理は，別途専用システムにより，これらの機器監視，システム状況監視，保守などを行う．
(3) メタデータ［詳細は別稿］
メタデータは，Dublin Core をベースとして，
人間文化研究機構マッピング規則[3]を策定し，全データベースの MDB を作成した．全項目，
5W1H（人・物・時・所），書誌（名称・作者・
主題），詳細（5W1H＋書誌），及び拡張 DCMES：
Dublin Core Metadata Element Set の5 カテゴリによる検索と表示を行う．また，GTA（時空間情報解析システム）用に，時空間メタデータを定義している．
マッピング規則に基づき，5 機関の 100 余のデータベースについて，上記カテゴリに対応す
る MDB を構築し，運営している．
(4) 利用者インタフェース［詳細は別稿］
利用者インタフェースは，一般利用を考慮し，実証実験，モニタ試験などを経ながら，使い易さを優先し，実装した．上記 5 カテゴリによる検索方法により，より高度な専門向き検索に対応している．
検索結果についても，一覧表示と詳細表示，

変換DB
・・
・

メタデータ
構築機能
システム

変換DB

変換DB
Z39.50

メタデータDB

SRW

収集・提供

収集

メタデータ・データベース機能
システム

原データベース

原DB
検索システムサーバ機能システム
Z39.50 / SRW

MGR（運用管理システム）

リポジトリ機能OAI-PMH

・・・原DB

図 2 基本システム構成概要図（現在）(1) 基本システム
各機関の情報システムに前置された FES は，
原データベースに対して 5 種のメタデータマッ
ピングを行い，MDB（メタデータ・データベース）を構築し保持する．情報検索プロトコル
Z39.50 及び SRW：Search/Retrieve Web Service により，GWS と接続し，MDB に対する情報検索を実施する．GWS をクライアントとし，FESをサーバとするインターネット通信による．
一方，利用者は Web アクセスにより，GWSに持つ Web サーバに対して，横断検索要求を行い，共有化検索結果を得る．Web サーバは標準
検索システムクライアントと，ゲートウェイを行い，検索を実施する．
Z39.50（v.2）と SRW（v.1.1）は，データベー
ス毎に明示的に指定するが，極力 SRW に統一している．
各機関の FES と GWS を合わせて，基本シス
テムと呼ぶ．図 2 に，基本システム構成の概要を示す．機関においては，FES 及び GWS の両

2

初期画面
ホームページから

検索画面
データベース選択
検索方法の指定
検索語入力

人間文化研究機構
国立歴史民俗博物館
国文学研究資料館
国立民族学博物館
国際日本文化研究センター
総合地球環境学研究所＜注＞*
CIF：Chrono-oriented Interface Function
時間指向インタフェース機能
GIF：Geo-oriented Interface Function
空間指向インタフェース機能

検索結果画面

詳細画面

DB件数表示
一覧表示

詳細表示

原データベース
画面
原データベース表示

時空間画面

時空間
詳細画面

CIF*
GIF*

図 3 検索画面の流れ
図４ 検索画面の１例

結果のソート，キーワードのハイライト表示，
原データベースへのリンクなど，多くの機能を提供している．
図 3 に画面遷移の概要を示す．また，図 4，5に画面例を示す．
原データベースへのリンクは，通常は URL
参照により行う．一方，FES のメタデータ変換などで URL 作成ができない場合，あるいはデータ全件出力などで参照 URL を複雑化させる
場合などでは，中継機能として，リゾルバ機能をGWS に置き，リンク用URL を作成参照する．
管理者用インタフェースを設けている．基本
システム環境の運用管理，及び MGR による統合検索システムのトータルな運用管理を行う．
(5) GTA［詳細は別稿］
横断検索だけではなく，検索と結果の高次処
理の 1 つとして，GTA インタフェースを，Web
プラグインとして実装した．検索画面に GTA
検索機能を埋込み，選択利用ができる．時間表
示機能（CIF：Chrono-oriented Interface Function），
空 間 表 示 機 能 （ GIF ： Geo-oriented Interface
Function）を持つ．タイムスライダによる時間
範囲の指定や，地図を使用した位置範囲の指定を行ってデータベースを検索することができる．
また，検索結果を年表上や地図上に表示することもできる．
3．システム開発
システム開発の経緯を以下にまとめる．
(1) 2005 年度は，先行実績[1][2]を踏まえ，トー3

図５ 検索結果の一覧画面の１例

タルな技術基準を評価するための実証実験を行った．資料招請と意見招請を行い，要求仕様を確定し，基本設計を行った．
(2) 2006 年度は，基本システムの開発と実装を行い，評価のための試験運用及び実証試験を行った．入札により，インフォコム社の Infolib を主とするシステムをベースに，統合検索システ
ムの骨格を完成した．5 機関のメンバからなる
タスクフォースや，実務者から成る WG を組織
し，システム開発を進捗し，また運用の実際と管理体制の確立をはかった．
(3) 2007 年度は，研究資源共有化システムの機能拡充として政府調達を行った．主たる追加機
能は，5W1H 並びに時空間メタデータの追加，
GTA の Web プラグインの実装などである．
5 機関の利用者モニタによる評価を行った．

4．試験，評価各機関 2 名以上の研究者及び大学院生（計 13名）による実利用による評価試験を，2007 年 10月に実施した．それぞれ専門の立場から 2 週間ほどの利用を行い，意見などの集約を行った．
結果は満足できるものとの評価であった．い
くつかの課題も指摘され，システム機能拡充の一環として組入れた．以下に概要をまとめる．
(1) データベース利用
OPAC などはよく使うが，専門領域のデータ
ベースは何があるかも分からない状況であり，機関を越えた利用はほとんどない．
(2) 資源共有化
資源共有化については知っているが，実態は知らない．ただし，期待度は高い．
(3) 横断検索
検索カテゴリが 5 つあり，その違いが分からないので，専門的な検索に結びつかない．
一方，思いがけずに他機関の関連データベー
スから情報が得られ，新たな知見が得られたとする評価もいくつかあった．
(4) 使い勝手
使い勝手の評価は良好であった．検索カテゴ
リ毎の同一キーワードで，検索結果が異なるとの評価があった．メタデータのマッピングの差異が原因であるが，統合指向ケースと個別指向ケースがあり，現時点では断定は困難である．
(5) 操作性
操作性，画面遷移，結果表示などは充分とされた．語彙ではなく，同一概念で検索し結果を得たい，
あるいは外字を含む検索の希望がある．
原データベースへのリンクは重視した要件であるが，やはり利用者の指向は高かった．
(6) 研究・教育
今後，とくに教育における利用として，機関をまたぐ情報資源の共有は必然である．
GTA による新しい利用法に期待度が高い．
(7) その他（意見など）・各機関で個々に造られた DB は，それ自体が思想であり研究成果だが，個別 DB から離れた
横断検索に意味があるか．
・個々の機関の専門性を活かした個性的で新規性のあるデータベース構築を充実させるべき．

・史料編纂所や東京文化財研究所など機構外にも拡張すべきである．
・表示されるメタデータの内容がデータベース
によってかなり異なる．
5．終わりにモニタ評価による様々な指摘は，可能な限り機能拡充として実装した．ただし，積残しの課
題もあり，次期計画などに委ねる．
今後の展望としては，機関のデータベースの充実が不可欠である．既存データベースの高次化はもとより，未公開のものの整備，さらに種類を増やすことも必要である．ただし，かなりな予算措置を伴う．
また，他研究機関などとの接続を進めなければならない．人間文化研究機構は人文科学の一部をカバーするに過ぎないので，関連する国内の研究機関，さらに海外の研究機関などとの連携が不可欠である．これも，次年度以降の大きな課題である．
アクセスは，機構並びに各機関ホームページ
経由としている．
人間文化研究機構：http://www.nihu.jp/
本事業は，石井米雄機構長，朝岡康二理事の指導の基に進められた．また，人間文化研究機
構の資源共有化検討委員会，タスクフォースメ
ンバの方々を始め，関係される多くの方々の献
身的な努力により，実現が図られてきた．深く感謝するものである．また，インフォコム株式会社，デスクロージャ・イノベーション社など
多くの企業の協力によるところも大きい．合わ
せて深謝する．
参考文献[1] 国文学研究資料館：共同研究「文化情報資源の共有化システムに関する研究」報告書，平成 16,17,18 年度[2] 安永尚志他：基盤研究(S)「国際コラボレー
ションによる日本文学研究資料情報の組織化と発信」研究成果報告書，2006.3[3] 人間文化研究機構：NIHU メタデータマッ
ピング規則（Dublin Core 編，5W1H 編，時空間
編），2006.12

4

人間文化研究機構研究資源共有化シンポジウム 2008-03-14

データベース横断検索のための共通メタデータ― 統合検索システムにおける定義と 2 つの課題 ―山本 泰則
国立民族学博物館
概要 「統合検索システム」とは、人間文化研究機構に属する５機関のデータベースを横断的に検索するシステムである。それぞれのデータベースの構造のちがいを超えて横断検索するために、各データベースの項目を共通メタデータに変換（マッピング）し、共通メタデータを検索するという方法をとった。共通メタデータには、Dublin Core、5W1H (Who, What, When, Wher, Why, How)および時空間情報を採用した。また本稿では、採用した共通メタデータそのものがもつ課題、統合検索システムでおこなった変
換規則の課題について議論している。

ある。この方法により Google のようなフリーキー
ワードによる検索以上の検索精度をめざす。
本プロジェクトに関わる多くのメンバーが、すでに総合研究大学院大学の共同研究（2003 年
４月～2005 年３月）、国文学研究資料館の共同研究（2004 年４月～2007 年 3 月）で実験的なシステムを構築してきた経験をもつが（[2, 3]）、本
プロジェクトは、それをさらに発展させた実用システムの開発を目的とする。
本稿では、統合検索システムで用いた共通メ
タデータに焦点を当て、その定義と構成を述べる。また、利用上の課題についても議論をおこなう。

1. はじめに
人間文化研究機構は、所属する５つの研究機関（国立歴史民俗博物館、国文学研究資料
館、総合地球環境学総合研究所、国際日本文化研究センター、国立民族学博物館）の間で研究資源を共有化するプロジェクトを、2005 年度
より進めてきた。その中心として開発をおこなってきたのが「統合検索システム」である。これは、５機関のもつ多数のデータベースを一元的に検索・利用することをめざしている。
５機関のもつデータベースは、図書や論文の目録をはじめ、古文書や絵画資料、博物館の「もの」資料、映像・音響資料、歴史史料の所在
情報、遺跡の発掘情報など、対象はさまざまである。また、データ形式も全文データ、音声データ、静止画・動画データなど多岐にわたる。このように対象もデータ構造（スキーマ）も異なる
データベースを一元的に検索することは容易ではない。すでにあるデータベースは、５機関で合計１００を超えており、データベースを一から作り直すことは実質上不可能である。
そこで、われわれがとった方法は、それぞれのデータベースの情報項目を共通の項目（メタデータ）に変換し、それを検索するというもので

2. 統合検索システムのアプローチ
2.1 共通メタデータ
データベース横断検索のための共通メタデータとして、プロジェクトでは次の３種類を採用した。
1. Dublin Core
インターネット上のさまざまな情報資源を発見するために、それら資源のどれもが共通にもってい る 基 本 特 性 を 15 の 要 素 に ま と め た も の がDublin Core Metadata Element Set（以下、DC）である（[1]）。

1

人間文化研究機構研究資源共有化シンポジウム 2008-03-14

2. 5W1H
何かものごとを述べるときには、5W1H、つまり 、 い つ （ When ） 、 ど こ で （ Where ） 、 だ れ が（Who）、なにを（What）、なぜ（Why）、どのように（How）したかを含めることが不可欠であるといわれる。データベースついても、多くがこれらの情報をもっていると考え、DC とは別の種類のメ
タデータとして、5W1H を採用することにした。
3. 時空間情報
データベースには、日付や年代・時代などの時間情報、および、住所や地域、国、緯度経度などの地理的、空間的情報をもつものが少なくない。これらを３つ目のメタデータとして採用した。時空間情報は、単に情報検索の手段を提供するだけでなく、他の条件で検索した結果を地図上や年表のような時間軸上に表示すること
により、情報間の新たな関連性を発見する可能性も期待している。

た、手紙のように本来は紙に書かれた内容が重要な資料でも時代を経るにつれ、紙の素材や折り目など、もの資料としての側面も重要が増す。
また、原データベースの項目を DC のどの要
素に割りあてればよいか判断に迷う場面もしばしば生じ た。たとえ ば、楽器の種類はふつうType に属すると考えられるが、データベースによっては Subject に割りあてた方が適切な場合がある。土器の形など、資料の形状情報も Type、
Subject、Discription など、いくつかの割りあての可能性がある。また、Source は、「その資源が作りだされる元になった資源」を意味するが、それは Relation の一種と解釈することもできる。
DC は、何を記述対象とするかに非常に敏感な
メタデータである。たとえば、音楽演奏を撮影した
ビデオテープを考えると、音楽演奏そのものを記述するなら Creator は演奏者、録画したビデオテープを記述するなら、Creator はビデオ撮影者に2.2 マッピングの課題
５機関の持つデータベースをこれら３種類

なろう。このことが DC メタデータの検索情報のメタデータに変換する過程で、さまざまな問

発見を困難にしている面があると思われる。

題点が生じた（[4～8]）。

時空間情報
各機関が持つデータベースの時空間的情報には、「縄文時代中期」、「ジャワ島東南部海岸地域」など、ことばで表現されているものが少な
くない。また表現方法もさまざまで統一されていない。これらの情報を時空間検索で扱えるようにするには、なんらかの正規形に変換する必要があった。

Dublin Core
DC の 基 本 要 素 の 定 義 で は 、 「 資 源 」（Resource）とその「内容」（Contents）をはっきり区別している。たとえば、要素 Date には資源に生じたなんらかの時間情報（製作時期や、使用
年代など）、要素 Coverage には資源の内容が表している時間的な範囲を記述する。一方、地理的、空間的な情報については、内容を記述する Coverage (Spatial)はあるが、資源そのものの空間的情報（製作地や使用地など）を記述す
る要素がない。Internet 上の情報資源なら、URＩ（おそらく要素 Idetifier に含まれる）があれば十分であるが、実資料の場合はそうはいかない。
５機関のデータベースの対象は、多くがもの資料を含む実資料である。もの資料は資源と内容を区別することは困難であり、内容を記述す
る DC の要素にどんな情報を割りあてたらよいかを判断することは必ずしも容易ではない。ま

2.3 NIHU メタデータマッピング規則
以上のような点を考慮して、統合検索システ
ムで用いるマッピング規則を決定した（[9]）。以
下、要点を述べる。
Dublin Core
1. 原データベースで記述している対象を DC
でいう「資源」とする。
2. 原データベースで表示対象になっている情報は、原則としてすべてを表示対象とする。
つまり、DC のどれかの情報にマッピングする。

2

人間文化研究機構研究資源共有化シンポジウム 2008-03-14

表1. 統合検索システムの共通メタデータのXML構造（抜粋）
出

No 現

下位
要素

XMLタグ名記述内容

1 1 nihu_dc
2 1

SortTemporal

時間ソート用3 *What

5W1H検索用

4 *Who

5W1H検索用

5 *When

5W1H検索用

6 *

Where

5W1H検索用

7 *Others

8 1

Any

9 *
10 *

全項目検索用sval

全項目データTitle

Dublin Core

11 *CreatorDublin Core

12 *Subject

Dublin Core

13 *Description

Dublin Core

14 *Publisher

Dublin Core

15 *Contributor

Dublin Core

16 *

Date

Dublin Core

17 *

Type

Dublin Core

18 *FormatDublin Core19 *Identifier

Dublin Core

20 *SourceDublin Core

21 *Language

Dublin Core

22 *Relation

Dublin Core

23 *Coverage24 ?

Dublin Core

dsCoverage

Dublin Core検索用CoveragedsContainer

25 +
26 *

spatial

空間情報

27 *

temporal

時間情報

28 ?

時空間検索用CoveragetsCoverage

29 +tsContainer

30 *tsDate

時空間情報検索用フィールド時間情報

tsDescDate

31 +元データに記述された時間情報

tsDescription

32 +tsNormDate

33 +正規化された時間情報

34 1

tsFrom

開始時刻（日本時間）。W3C DTF

35 1

tsTo

終了時刻（日本時間）。W3C DTF

tsDescPlace

元データに記述された位置情報

tsPlace

36 *
37 +

空間情報
tsDescription

38 +tsNormPlace

39 +正規化された空間情報（座標）tscoodinate

40 +
41 1

tsNWpoint○

矩形北西点の緯度経度。WGS84測地系の10進表記

42 1

tsSEpoint○

矩形南東点の緯度経度。WGS84測地系の10進表記

43 *RightsDublin Core3

人間文化研究機構研究資源共有化シンポジウム 2008-03-14

3. 資源の内容が対象としている時間範囲はCoverage (Temporal)へ、資源に起きた事象に関する時間情報は Date へマッピングする。
4. 資源の内容が対象とする地理的情報、および資源が製作あるいは使用された地理的情報を Coverage (Spacial) へマッピングする。
5W1H
1. 5W1H のうち、Who, What, When, Where
をマッピングの対象とする1。
2. 文で記述された情報や備考にあたる情報、上記の４要素にマッピングできない項
目は、Others へマッピングする。
時空間情報
1. 時間情報は、正規化した時間の区間で表現する。
2. 空間情報は、緯度経度の矩形範囲で表し、矩形の北西端と南東端の組を与える。
3. 元データベースで記述的に表現されている時空間情報は、適切と判断される数
値範囲に変換する。
4. 専用のメタデータを設け、そこに元の記述な表現を残す。
その他
1. DC では、それぞれの要素について検索
用メタデータと検索結果表示用メタデー
タを別に設ける。原データベースの項目
を、検索用および表示用、さらに Any に対して、それぞれ独立にマッピングする。
2. 5W1H は検索にのみ用い、検索結果は
DC にマッピングした形で表現する。
以上を反映して、統合検索システムで用いるメ
タデータを表１のような構成にした。

いくつか課題が残されている。

コアメタデータ Dublin Core
NIHU メタデータマッピング規則では、元のデータベースの情報（特に表示用）を DC のいず
れかの要素（適切なものが無い場合はDescription になる可能性が高い）にマッピング
することを要請している。しかし、すべての情報をマッピングすることにより、個々の要素の定
義・意味をあいまいにしてしまうことにならないのか。DC は「コア」メタデータであり、多くの資源がもつ情報の共通要素、いわば最大公約数の情報をメタデータとして選択しているはずである。
統合検索システムでは、Any というメタデー
タを DC と独立して導入したため、結果の表示ではなく検索に関していえば、実質的には、DCにすべての情報をマッピングする必要はなくなっている。DC に原データベースのすべての項
目をマッピングしなければならないか、表示しなければならないかについては、再検討を要する。
時空間メタデータ

前節のような方針にもとづいて共通メタデー

実際、時空間メタデータで直接扱えるような数値化された情報を持つデータベースは少なく、文字による記述を緯度経度の矩形範囲や時間範囲に正規化する必要があった。機械的な正規化で期待した検索結果が得られるかどうかは、
今後検証を要する。
さらに、複雑な形状の地域を表すために、凹凸のある多角形で表した領域も検索対象にする機能が必要である。
また、メタデータの内部的な設計の問題である が 、 時 空 間 情 報 の メ タ デ ー タ を 、 DC
Coverage の下位要素として位置づけたことは、DC の dumb-down rule に反することになり、必要性を含め再考を要する。

タを決定し、統合検索システムに組み込んだが、標準メタデータのローカル化

3. 共通メタデータ定義上の課題

今回は、Internet の電子的な情報資源の発見のために作成された Dublin Core Metadata

1

Why、How へはマッピングできたとしても適切な検索語を選べないと考え、対象外とした。
4

人間文化研究機構研究資源共有化シンポジウム 2008-03-14

Element Set を実資料をも記述するために、「元来の意味を大きく逸脱しない範囲で」メタデータの定義を拡張した。しかし、そのことによって人間文化研究機構外部の機関が作る DC メタデータの定義との間の互換性を損ねてしまったことは否めない。標準は標準を守ってこそ、互換性が保証される。
Dublin Core の基本 15 要素で記述できない
情報要素があるのなら、要素の定義を拡張するのではなく、むしろ必要な新たな要素を導入すべきではなかったのか。たとえば、前節のマッピング規則では、場所・地域に関する情報はすべて Coverage(Spatial)に割りあてたが、資源と内容、Date と Coverage (Temporal)を区別する DCの流儀にしたがうのなら、内容ではなく資源に起こった空間的な情報（製作地、収集地など）を記述する Place (あるいは Location) のようなタグを独自に導入してもよかったのではなかろうか。つまり、NIHU DC を定義するのではなく、
NIHU アプリケーションプロファイルを定義すべきであったと考える。それは、人文科学で用いる実資料のための共通メタデータを提案することにもなるだろう。

ベースが見つかったら、個別のデータベースをその特性に合わせて精密に検索する。このような二段構えの検索が有効ではないかと思われる。そして、そのために、共通メタデータは単な
るフリーキーワード検索よりは精度のよい検索手段を統合検索システムが提供することを期待されている。
ともあれ、統合検索システムの実現・公によって、われわれは共通メタデータを用いたデータ
ベース横断検索の有効性を、実データにもとづ
き検証できる大規模なテストベッドを手に入れたことにもなる。今後、継続的な利用と評価、それにもとづく改良を経てこそ、統合検索システム
はより実用的なシステムになっていくと考える。

謝辞
本稿の内容は、研究資源共有化プロジェクトのタスクフォースのメンバーをはじめ、それ以前の総合研究大学院大学共同研究および国文学研究資料館共同研究にかかわった多くの関係諸氏との議論、いただいた貴重なご意見や示唆にもとづいている。ここに深く感謝の意を表する。

4. まとめ参考文献 URL

本稿では、統合検索システムでデータベースの構造の違いを吸収するために設計し、用いた共通メタデータについて述べ、利用上の課題について議論をおこなった。
ところで、このシステムによって、全データベ
ースがあたかも一つのデータベースであるかのように利用できるのだろうか。筆者はそうは考えない。それぞれのデータベースは作られた経緯があり、似たような資料を対象にしていても、どんな目的を持ってどんな視点で作成されたかに
よって情報の採録のしかたも構造も異なりうる。
共通メタデータによる検索には限界がある。
統合検索は、むしろ、各データベースを検索するためのインデックスと考えるべきではないか。
つまり、統合検索システムによって、全データベースを広くスキャンし、関心がありそうなデータ[1] Dublin Core Metadata Initiative,(http://dublincore.org/)[2] 原正一郎：「Z39.50 とメタデータによる研究機関
連携」，情報処理，vol.43, no.9, pp.968-974,
2002[3] 山本・原・柴山・安達・合庭・安永：「Dublin Core
メタデータと Z39.50 プロトコルにもとづく人文科
学系データベースの統合検索に関する実証実
験」，人文科学とコンピュータシンポジウム論文
集，情報処理学会シンポジウムシリーズ
2004(17), pp.199-205, 情報処理学会，2004[4] 原・相田・入口・江戸・五島・山田：「データベース
共有におけるデータマッピングの事例的研究」，
情報処理学会研究報告，2005(67), pp.31-38，
2005[5] 安達・鈴木・小島・高橋：「資源共有化のための5

人間文化研究機構研究資源共有化シンポジウム 2008-03-14

歴史資料データベースの Dublin Core へのマッ
ピングの検討」，情報処理学会研究報告，
2005(67), pp.39-46，2005[6] 山本・中川：「データベース横断検索のための民族学標本資料情報の Dublin Core による記述」
情報処理学会研究報告，2005(67), pp.47-54，
2005[7] 安達・鈴木：「歴史研究データベースの Dublin
Core へのマッピングとその課題」，情報処理学会
研究報告，2006(112), 2006-CH-0728,pp.47-54,
2006[8] 山本泰則：「機構資源共有化分散システム
Dublin Core へのマッピングの原則 ― 検討課
題 ―」，国文学研究資料館第 3 回共同研究会「文化情報資源の共有化システムに関する研究」，
2006（口頭発表）[9] 「NIHU メタデータマッピング規則 ver.2.00」，人間文化研究機構, 2007（未公開）6文化資源研究情報統合検索のためのユーザインタフェース
安達文夫
国立歴史民俗博物館
1. はじめに
人文科学に関する様々な研究資源の情報が記述されたデータベースを、その所在や個々の操作方
法を意識することなく統合的に検索できる研究資
源共有化システムの開発を進めてきた。対象とするデータベースは 100 を超える上、研究分野は歴史学、国文学、文化人類学など多様である。そして、データベースが扱う対象も、所蔵するあるいは各地に所在する資料や図書・文献の目録情報、
フルテキストや画像で表した資料の内容、資料調
査やフィールドワークなどで集積した研究対象の様々な事項など幅が広い。
このようなデータベースをまとめて検索し、結果を表示するユーザインタフェースは、当然ながら特定の事象を対象としている個別のデータベースの検索インタフェースとは、設計する上で異なった考慮が必要である。複数のデータベースを横断的に検索するシステムは図書を対象として実現されている。図書の内容は多様であっても、図書を記述する情報は同質である。これに対し、文化資源の研究情報は、決して同質とは言えない。さらに、文化資源研究情報では、時間や場所に関する情報が重要である。多くのデータベースに時間
情報、空間情報が付与されているが、記述形式は様々である。このような同質ではない情報を対象として、時空間情報をも含めた検索を実現することは、単なる横断検索の域を超えた統合的な検索を実現することであり、そのユーザインタフェースの構成法は大きな課題となる。
加えて、本稿の中で具体的に示してゆくが、文化資源研究情報の中には区分が難しい情報や、情報の値が本質的に確定し得ないものがある。この確定的でない情報を、ユーザインタフェース上どのように扱うかが重要な課題となる。また、人文科学の研究において使われてきた探すためのインタフェースは、インターネットの検索サイトが提供するインタフェースとは異なっている。利用者にとって使い慣れたインタフェースを統合検索にどう反映するかも課題の一つである。
本稿では、Dublin Core メタデータを基本的な共通メタデータとする方針の下で、全体としては同質ではなく不確定な情報を有する多種多様な文化資源の研究情報のデータベースを時空間情報を含めて統合的に検索するためのユーザインタフェースの構成法について記す。
2. 検索機能の全体構成
2.1 検索フロー
人文科学の多くの DB では、検索語の入力、検索結果の一覧表示、そこから一つを選んでの詳細表示が基本的なフローとなっている。研究資源共有化システムでは、対象となるDB が100 を超え、ヒット件数が膨大になることが想定される。これが個別の DB の検索との第一の違いであるが、横断検索のフローでよく見られる DB 毎のヒット件数の一覧を表示することを取り入れ、検索結果の全体を見通せるようにできる。統合検索ではさらに、原 DB の存在と、時空間表示との連係を考慮して検索フローを構成する必要がある。以下の検討を基にした統合検索のフローを図 1 に示す。
(1) 原 DB の画面表示と詳細表示
個々の DB には、その記述対象や分野に応じて必要とされる情報が適切に区分され配置された検索結果を表示する画面が用意されている。この画面を表示することによって、原 DB が記述する情報の伝達が完了する。このことから、原 DB の検索結果画面を表示することを基本とする必要がある。
このとき、統合検索の中の詳細表示の位置付けを明らかにする必要がある。すなわち、詳細表示

検索語入力ヒット件数表示

一覧表示

詳細表示

時間表示

空間表示

原DB画面表示

図 1 統合検索のフロー
は原 DB 画面が表示されるのであれば不要とも言える。しかし、様々に記述された DB の情報を共通の枠組みを通して見ることも求められることか
ら、詳細表示に統一的なビューを提示する役割を持たせる。
検索結果の一覧表示、詳細表示のいずれからも、
原 DB の画面を表示する。以下で述べる時空間解
析機能の表示画面から、
原 DB の画面表示を行う。
(2) 時空間解析機能とのフロー
統合検索では、検索結果の時間情報と空間情報をそれぞれ表示する時間表示(CIF)と空間表示(GIF)の機能を有する。これらの時空間解析機能を提供するフローとして幾つかの案が考えられる。
その中で、一覧表示、時間表示、空間表示の三者間で相互に遷移して結果の表示を変えることを同等に操作でき、余計な遷移を伴わず利用者にとって簡潔な図１に示したフローとする。また、これにより検索結果を一覧表示で確認して時間表示や空間表示ができる。
2.2 検索条件指定(1) 検索条件の設定種別
統合検索では、全ての DB の全てのデータ項目
を対象に検索することが基本である。このためには、インターネットの検索サイトが提供するような一つの入力フィールドを設けた入力画面を用意すればよい。これにより、検索文字列をスペースで区切って並べるなどして、絞り込んだ検索を実行できる。
しかしながら、例えば“鎌倉”が時代名か、地名
か、あるいは人の名前かを区別した検索を実現す

るには、意味を区分した検索語入力のフィールドを用意する必要がある。これを、多様な DB を対象とし、様々な利用を想定する統合検索において実現するには、概念的には、図 2 に示すように、検索項目の意味を幾つかの分解能でまとめた検索
手段を用意し、利用者が必要とする意味の分解能で検索する機能を必要とする。
また、統合検索はどのような DB があるか意識せずに検索できる点に特徴がある。しかし、入力
する検索語によっては、関心のない分野あるいは対象のレコードもヒットする。検索する対象が明
確な利用のためには、特定の DB を選択して検索できる機能が求められる。このとき、DB を何らかの種類に分けてグループ化し、そのグループあるいはその中の DB を指定して検索できる機能が有効である。分類の観点を変えることにより、幾つかの DB のグループを構成することも考えられる。また、複数のデータベースグループの組み合

全項目

5項目程度

15項目程度原DB項目

図 2 検索項目の分解能

わせによって検索条件を設定することも考えられる。
このように、多様な DB を対象として効果的な統合検索を実現するには、検索語の組み合わせ、検索項目の意味の分解能、データベースグループの指定の３通りの検索条件設定の手段を設ける必要がある。そして、この３通りの手段を組み合わせて検索条件を設定できることが必要となる。この組合せによる条件設定は、絞り込み検索を行う
際にも有効である。
(2) 検索項目種別の構成
上述のように、検索語入力の項目は、段階的に細かくなるように設置する。一方、共通メタデー
タとして、DC メタデータを基本とし、5W1H メ
タデータを用意する。当然ながら、全ての項目を対象にする全項目検索が最も粗い。5W1H メタデータに基づく検索がその次となる。これを人・物・時・所検索と名付けている。
DC メタデータは後述するように、不慣れな人にはエレメントの意味が分かりづらいとともに、文化資源の研究情報を対象とする場合には、ほとんどマッピングされないエレメントがある。そこ
で、文献情報の基本的な検索を対象として、DC
メタデータから要素となるエレメントを選び、名称・作者・主題検索として用意する。これと人・物・時・所検索を併せたものを詳細検索とする。
最も細かい検索項目として、DC メタデータを熟知した利用者向けに Dublin Core 検索を設ける。
以上をまとめると、以下の５つの検索項目としての種別を用意する。
(a) 全項目検索(b) 人・物・時・所検索(c) 名称・作者・主題検索(d) 詳細検索(e) Dublin Core 検索(b)と(c)で検索項目の細かさは同等である。これ以外は細かくなる順に記している。
検索項目種別間の遷移をどのように構成するかは、ユーザインタフェースを分かりやすくする上で重要である。システム的には検索語が入力された後に検索項目種別が変わる場合、項目の粗い方
から細かい方へは入力された検索条件を保持したまま遷移することは可能であるが、その逆はできない場合が生ずる。利用者にとっては、条件によ

らず同じように操作できることが望ましい。検索
条件を引き継ぐことができない場合はその旨警告
し、判断を利用者に委ねて、検索項目種別間の遷移を一律に行えるようにする。
3. 検索インタフェースの構成
3.1 検索項目と詳細表示項目(1) 詳細表示の方法
図 1 に示した検索フローの中で、検索語入力がDublin Core 検索によるときは、DC メタデータ
により詳細表示することは自然である。人・物・時・所検索の際に 5W1H メタデータで詳細表示することも不自然ではない。しかし、全項目検索の結果をメタデータのエレメントを区分せずに表示したのでは、利用者にとって不都合である。DC
メタデータに基づく方が適切と考えられる。詳細
表示の役割は、共通のビューで検索結果を提示することであるから、検索項目種別によらず表示を同一にすることが適切である。
(2) 検索と表示の項目
DC メタデータは、文献目録 DB のデータ項目
をマッピングすることに親和性がある。しかし、モノ資料を記述する DB では、DC の定義そのもではマッピング先が不定となるデータ項目が存在する。この不定な部分を DC の定義に準じてできるだけ合理的に解釈できるよう NIHU メタデー
タマッピング規則を定めている。しかし、マッピングする際の規則として明確であっても、これを基に検索する利用者にとって、どのフィールドに入力するか、どの項目に表示されるか不確定で紛
らわしい面は残る。
そこで、一般の利用者向けに、
DC メタデータの幾つかのエレメントについて簡略化し、検索と表示上の分かりやすいユーザイン
タフェースを構成する。
(a) Date と Coverage_Temp.
Date は資源に起きた事象に関する時間情報であり、Coverage_Temp.は資源の内容として対象となっている時間情報である。
その意味は明確で、データ項目をマッピングする上で解釈に迷うことはない。古文書の日付は Coverage_Temp.であり、作成年代は Date である。原本であれば日付と作
成年代、すなわち Coverage_Temp.と Date は一致し、写しであれば、両者は異なる。しかしなが

ら、時間情報のこれらの意味を区別なく記述している DB も多い。例えば、複製品について製作年
代として原本のそれが記述されていることは普通にある。また、全文 DB において、資源を原資料と捉えるか、電子化された資料と捉えるかによって、Date の内容が変わる。資源をどちらで捉える
かはマッピングする側で決まることであり、利用者にとっては少なくとも検索するまでは分からない。むしろ知らずに検索できる方が望ましい。そこで、Date と Coverage_Temp.を表示上の区分は行わない。
(b) Subject と Type研究文献に関する DB では、そのテーマ、主題を記述するデータ項目がある。一方、様々な資料に関する DB では、資源の種類―例えば、江戸時代に収集された楽器では龍笛，琵琶、七絃琴等―を記述するデータ項目がある。いずれも、研究資源を検索する上で重要な情報である。Subject は資源の内容に関する主題、キーワードである。
Type も本来は資源の内容に関してテキスト、
画像
等、あるいは小説、誌、随筆という性質、種類を表すものである。NIHU メタデータマッピング規則では、拡張解釈して資源そのものの性質や種類のデータ項目をマッピングできるようにしている。
しかし、一般の利用者にとって、キーワードと資源の種類の区別がされるとは限らない。また、錦絵の DB に見られる主題分類の美人画、役者絵、名所絵等は、マッピングする側でも Subject かType か迷いが生ずる。
このようにどちらか明確に定まらない性質のデータ項目が多いことから、検索と表示上は両者の区分を行わない。
(c) Source と Relation
Source は資源が作り出される元になった資源であり、Relation は資源に関連する他の資源であって、定義としては明確である。しかし、文化資源研究情報の中には、原稿の草稿は Source であるが、複異版や製品の現品は Source ではなく、Relation であるといった紛らわしい関係が少なからず現れる。また、何を資源と捉えるかによって、Source と Relation のマッピング先が変わり得る。そこで、表示上は両者を区分しない。
(3) 項目名とメタデータエレメント
以上の検討を基にした詳細表示の項目について
ラベル名と該当する DC メタデータのエレメント

表1

検索結果表示のラベル名とDCエレメント

表示ラベル
名称
主題・種別
作成者・著者
公開者・出版者
協力者
記述・説明
時期・日付
地域・場所
形式・形状
資料番号
関係資料
言語
権利関係
表2

DC element
Title
Subject / TypeCreatorPublisher
Contributor
Description
Date / Coverage_Temporal
Coverage_Spacial
FormatIdentifier
Source / Relation
Language
Rights

検索語入力のラベル名と共通メタデータ

検索語入力ラベル
共通メタデータ
人・物・時・所検索
人・組織
Who
物・事
What
時期・日付
When
地域・場所
Where
名称・作者・主題検索
名称
Title
作成者・著者 Creator
公開者・出版者 Publisher
主題・種別
Subject / Typeを表 1 に示す。また、人・物・時・所および名称・作者・主題検索のラベル名と該当するメタデータの項目を表 2 に示す。先に記したように、詳細検索は人・物・時・所検索と基本書誌検索の合成である。Dublin Core 検索は、これに慣れている利用者向けであるので、DC メタデータそのもので詳細表示を行う。
3,2 時空間情報による検索(1) 時空間情報の正規化
統合検索の対象となる DB で時間や場所の情報
は文字列で記述されている。したがって、前節で記した時と所の検索は、文字列検索となる。これは、例えば時間に関して、時代や元号の名称や、世紀や西暦年を指定しての検索ができる。
しかし、
16 世紀を検索するために 16 を入力しても、1816

（年）がヒットするという文字列検索に共通する問題がある。そして、時間情報は多様な形式で記述されているため、利用者か意図する対象を全て検索することは保障されない。これは、個々のDB においては、統一した時間情報の形式であっても、これらをまとめて検索する統合検索において生ずる問題である[1]。このような問題は、空間情報においても同様に生ずる。
一方、幾つかの DB では、時間情報に関して開始と終了を指定する検索を提供している。文字列で表記された時間情報を数値情報に変換することにより、上記の問題を解決できる。時間情報は和暦による表記も多い。統合検索は広く世界に関わる研究資源を対象とするため、太陽暦で正規化する。和暦の正規化は、暦日テーブル[2]を利用できる。時間情報は、時代や世紀のように幅を持つことから、開始と終了を正規化する。
時間情報の中には、“江戸時代中期”のように曖
昧な表記が少なくない。これは期間の始まりと終わりを確定的に記述できないために使われる。検索の手がかりに限定して何らかの値を与えて正規化する。また、“江戸時代”でも、その始まりは研究分野によって異なる。このような、開始あるいは終了に幾つかの解釈が存在する時期区分については、DB 毎にそれぞれに正規化時間を与える。
同じ時代で DB によって区間が違っても、検索の手掛かりとするには支障はない。
空間情報は、その領域を矩形で表し、西北と東南の緯度・経度で正規化する。代表点で表すときは、西北と東南が同じ値となる。文字表記された
旧地名を正規化するには吉田東吾の大日本地名辞書を電子化した地名辞書[3]を利用できる。
(2) 検索の一致条件と条件指定区間で表した時間情報を開始と終了を指定して検索する際の条件一致の候補を図 3 に示す。検索
条件の開始と終了の区間に、検索対象の区間が完
全に入っている(a)だけを一致とする方法と、検索条件の区間に部分的にでも重なる対象を一致とする方法がある。人文科学の研究者からは、関連するものは全て対象として表示する要求があることから、後者を一致の条件とする。空間情報の検索の一致条件も、時間情報と同様に、部分的な重なりがあれば一致とする。
時空間情報を指定する検索は、2.2 節で述べた 5

Y1

Y2

(a)
(b)
(c)
(d)

図 3 時間情報の検索の一致条件
種類の検索項目種別の全てにおいて、文字列による検索と併用できるようにする。具体的には、画面上のボタンを押すことにより、時空間情報による条件設定画面が表示される。その一例を図 4 に示す。時間は帯、空間は地図上で範囲を指定でき
る他、共に数字を入力しての指定も可能である。
3.3 一覧表示
一覧表示は、検索条件に一致した多くのレコー
ドの中から、目視で必要なものを探し出す重要な機能を提供する。統合検索では様々な DB を対象とすることを考慮し、一覧性がよい表示の構成と、探しやすくするためのソートの機能について、ユーザインタフェースの面から検討を加える。
3.3.1 一覧表示の構成
100 を越える DB を対象とした統合検索では、検索条件によっては相当数のレコードが表示される。このとき、一つのレコードに含まれる複数の項目を縦列的に表示するよりも、同じ項目を比較できるよう並べて表示する形式が適切と考えられる。これにより、人文科学の研究者が使用してきた印刷物による目録や個別の DB と同じ使い勝手
で利用できる。具体的には、項目を横に、レコー
ドを縦に並べる表形式とする。
一方、表示項目は一覧表示と詳細教示とで同じであることが分かりやすい。一覧表示を表形式で詳細表示と同じ項目で行うと、画面上に全ての項目を表示できない。この問題は個別 DB の一覧表
示でも同様であるが、個々の DB の特性を基に利用を想定して表示の優先順を決めることができる。
これに対し、多数の DB をまとめて検索した結果を表示する統合検索では、優先順は決まらない。
そこで、表示項目を指定できるインタフェースを

図 4 検索条件入力画面の例（詳細検索）
設ける。
デフォルトとなる一覧表示項目は、多くの利用者にとって共通で分かりやすいことが求められる。
“名称”を表示するとともに、幾つかの DB で同じ名称が現れることから、“識別子”を表示する。どの DB でヒットしたものかが分かるよう、原 DBと公開機関の名称を表示する。
個別の DB の検索表示では、一つの項目に一つの事項が記述される。統合検索では共通メタデー
タの一つの項目に原 DB の複数のデータ項目がマ
ッピングされるため、一覧表示の一項目に複数の事項が表示されることになる。これは、一覧性を阻害する要因となりかねない。この解決は今後の課題となる。
3.3.2 ソート機能(1) 表示項目によるソート
多くの DB で提供されているように、表示項目毎にソートする機能を実現することは有用である。
しかし、個別の DB と違って、一つの表示項目に複数の原 DB のデータ項目が対応するため、どれを対象にソートするかが課題となる。項目を分解し各々をソートすることも考えられるが、他の項目によるソートや絞り込み検索との連係を考えると処理は単純ではない。そこで、共通メタデータの項目毎にソート対象を決め、これを基にソートを行う。これによっても、表 1 の作成者・著者、
主題・種別、地域・場所など多くの表示項目でソートが有効に機能すると考えられる。しかし、記述・説明では、様々な意味のデータ綱目が多数マ
ッピングされるため、ソートの効果は低くなる。
ソートの対象が一つの項目に複数あることに対す
る本質的な対応は今後の課題である。
(2) 正規化時間情報によるソート
共有化の対象とする DB の中には、時間情報によるソートを提供するものがある。正規化時間情報を利用すれば、元々時間順に並べ替えることができなかった時代表記等によるレコードも含めた

3.4 データベースグループ
検索対象が明確な利用のため、DB のグループを構成し、これを選択しての検索を提供する。グ
ループの種別を複数設けることもできる。このグループをヒット件数の表示に使用するとともに、継続する絞り込み検索の条件設定にも使用する。
このため、あるグループ種別において、グループ
を全ての DB がいずれか一つだけに属するよう構成する必要がある。この条件を満たすグループの(a) 和暦表記(b) 和暦以外の表記
構成を検討する。
容易に構成できるのは、原 DB を公開する機関
図5 時間情報の表記と並べ替え
別のグループである。次に考えられるのは、研究ソートが可能となる。このとき、一覧表示の表示
分野別のグループである。しかし、多様で分野間形式は他の項目によるソートと同一とする。このに密接な連続性がある人文科学の領域で研究分野
条件下で、表記が多様で、不確定な意味表現を持
別のグループを的確に構成することは、たやすい
つ時間情報を、どのように並べることがユーザイことではない。仮に構成できたとしても、DB をンタフェース上適切かを検討する。
1 対 1 に対応付けることは難しく、利用者に理解
時間情報には、西暦と和暦のように相互に変換されるとは期待できない。
可能なものの他、年、年月、年月日と精度が異な
そこで、DB が記述する対象の性質に着目し、る情報が混在する。これらの並べ替えの順につい利用者にとっても区分が分かりやすいグループをて、和暦を例として、図 5(a)に示す。これは、精構成することを考える。文化資源の研究資源に関度が同じものは時間順に、異なるものは精度が一する DB は、表 3 に示すように、あるまとまりをつ高いもの後に並べる方法であり、個別の DB で持つ資料群を記述するものと、研究の対象とする
取り入れられている方法である。正規化時間情報
事項を、様々な資料やフィールドワークにより記に対しては、終了の早い順に並べ、これが同じと述するものに大別できる。前者は、その資料群にきは開始の遅い順に並べることで実施できる。
属する資料の目録的な基本情報を収録するものと、
この表示の中に西暦表記のデータが混在しても資料の内容を何らかの形式で収録するものに分け
不自然ではない。しかし、図 5(b)の江戸時代中期られる。
や近世といった時代名が混在するのは不自然であ
基本情報を記述するものは、DB の公開機関でる。世紀の表記の混在も多少不自然である。そこ所蔵する資源を対象とするか、広く所在する資源
で、西暦および元号だけを含む和暦表記とそれ以を対象とするかで区分できる。これは利用者にと外の時間表記を分けて表示するソート方法とする。 って研究資源を DB 公開機関で利用できるかを知このように表示することにより、同じ時代表記でる重要な分類となる。さらに、所蔵する資源を図
正規化時間の開始・終了が DB により異なっても書とそれ以外に分けことが、検索対象を指定する
表示が不自然とはならない。
上で利用者に有用である。広く所在する研究資源
安永 9 年10月18日
安永 9 年10月21日
安永 9 年10月
安永 9 年12月 7日
安永 9 年12月
安永 9年
安永10年 1月
安永
天明 1年 5月
天明 1年閏 5月12日

1780年
18世紀
江戸時代
江戸時代中期
近世

表3
区分

記述対象とデータベースグループ

所蔵
図書以外
所蔵資料目録目録
研 研究
図書
所蔵図書・雑誌目録
究 資料群
本文・フルテキスト
テキスト
資
内容
画像、音響等 画像・映像・音響源
研究対象の事項
事項・ファクト

各所に所在
事項・ファクト
研究文献目録についても、図書・雑誌、報告書等の文献とそれ以外を分けることは理解しやすい。
資源の内容について記述した DB でも、所蔵の関係で区分できるが、検索の際に内容を知ることができることから、利用者にとって関心とならな
いと考えられる。内容の記述形式で区分する方が利用しやすい。
表 3 のように構成したグループの中で、文献以外の各所に所在する研究資料の目録を収録する
DB と研究対象の事項を収録する DB は、内容から区分が難しいものがあることからまとめて一つのグループとしている。所蔵資料目録の中に、その画像や記載のフルテキストを付与したものがあると同時に、全文・フルテキストや画像・映像・
音響にも目録的な情報は付与される。これはどちらが主であるかによって分類する。
利用者は、グループを選択し、あるいは、その中の DB を選択して検索できる。この選択を、統合検索を行う度に指定することなく利用者毎に指定されたグループを登録し再利用できる
MyGroip の機能を実現している。
データベースグループは、システム上の都合か
ら、全ての DB がいずれか一つのグループに属することを条件とした。ある分類に対して多対多の関係となるグループであっても DB の選択ができる手段の実現は今後の課題となる。グループ種別
間の演算により検索対象を指定することも今後の課題である。
4. むすび
人文科学の分野の多様な DB を統合的に検索する研究資源共有化システムでのユーザインタフェース構成法について述べた。原 DB の画面表示、
時空間解析機能を含めた検索フロー、ならびに検索結果一覧表示において、統合検索に特徴的な構成を図った。そして、解決すべき重要な課題は、
まとめて検索することが、同質でない DB を検索することになり、検索条件の入力や表示をいかに
分かりやすく構成するかにあった。また、データの記述形式が個々の DB で統一されていても、全体としては不均質となる。時間と空間の情報に関しては正規化データに変換し、これに基づき検索する手段を設けた。時間情報は、幅を有するとともに、人文科学分野の性格として確定的に記述し得ない性質を持つ点が、ユーザインタフェース上の一つの課題となった。空間情報についても同様であるが、広がりの実際的記述が課題として残っている。DB のグループを指定しての検索は、統合検索において有用であり、分かりやすいグループを構成した。しかし、広がりと繋がりを持つ研
究分野別のグループ化には課題が残っている。
多様な文化資源研究情報を収録したデータベー
スを統合的に検索する上の幾つかの課題を解決し、ユーザインタフェースに反映してきた。一般公開
されてから、利用者の評価を受けることになる。
様々な意見を今後の課題として行きたい。
参考文献[1] 安達文夫, 原正一郎,柴山 守, “時間情報を持
つ人文科学DB の統合検索のためのユーザイン
タフェースの検討課題,” 情報処理学会研究報
告, vol.2007, No.49. 2007-CH-74, pp.65-72(2007).
[2] 相田 満, “暦象オントロジの構築 ―日本旧暦時代の文献分析支援のために―,” 情報処理学会研究報告, vol.2007, No.95. 2007-CH-76,
pp.25-32 (2007).
[3] 桶谷猪久夫, “人文分野における日本地名辞書の構築と地名属性の特徴分析,” 情報処理学会
シ ン ポ ジ ウ ム 論 文 集 , vol.2007, No.15.
pp.79-86 (2007).

空間情報に基づく情報解析ツール
原 正一郎
京都大学地域研究統合情報センター
人文科学は歴史・文学・宗教・政治・経済学・民族学・民俗学・農業・環境などの学問分野を包摂する学際的研究分野の１つである。しかし人文科学研究者は個別の専門性に立脚した研究を展開しており、専門領域を超えた学際的研究の実現は容易ではない。資源共有化システムは、人文科学に関する多様なデータや情報を統合して新しい研究知の創出を支援する情報処理システムである。本論文では資源共有化システムについてメタデータの視点から解説し、そこから派生・発*1
展しつつある時空間情報処理ツールの開発状況とその応用について述べる。

１．資源共有化システムとは人 文 科 学 で 利 用 さ れ て い る 研 究 資 源 （ Research
Resources：以下では「資源」）には、モノ・テキス
ト・画像・動画・音声・数値など様々なメディアがあり、これらの情報はデータベースとして組織化され、インターネット上に公開されている。これらは個別データベースシステムであるため、①データベースごとにデータ構造*2 が異なる
②データベースごとに検索法が異なる③類似の資源でありながら別々のデータベースに収容されていることがあり、データベースの所在を把握していないと検索が困難である④資源と関連した研究成果などを調べることが困難であるなどの問題が指摘されていた。
資源共有化システム（Resource Sharing System）は、
このような問題の解決を目指して開始された[1]。資源共有化システムでは、異なるデータベースをシー
ムレス（seamless）に接合することを目指している。
つまり利用者からは、データ項目・項目名・検索手順・データベースの所在などが一つに見える、言い換えるとネットワーク上に分散する複数のデータベースが単一データベースであるかのように見えるデータベースを構築することである。この資源共有化
システムが目指すシナリオは、例えば国文学研究資料館の史料所在目録データベースから「伊能家」を検索すると、館蔵資料目録データベースや画像デー
タベースなども同時に検索して、伊能忠敬の「日本経緯度実測」の所在情報や画像情報なども入手できるような情報処理システムを実現することである。
最初に考えた資源共有化システムの実現方法は、全てのデータベースのデータ構造と検索手順を同じものに作り替える、いわゆる「データベースの統一」
であった。しかし国文学（図書館的）と史学（アーカイブズ情報的）を比べただけでも、両者が利用する資史料などの資源は重複しているものの、それぞれの整理体系は異なっており、データベースの統一は困難であった。また既存のデータベースに手を加えることには、図書館やアーカイブズからの反発もあった。
そこでデータベースの統一を諦め、仮想的な中間データベースを介した共有化を目指すことにした。
これが資源共有化システムの原型である（Fig.1）。
仮想的な中間データベースを介した資源の共有化を実現するため、資源共有化システムでは個別データ
ベースと並列にメタデータベースを設置する。メタ
データ（metadata）とは、データについてのデータという意味であるが、ここでは汎用的に利用することを意図して定義された標準的なデータ構造と定義する。具体的にはダブリンコアメタデータ（Dublin
Core Metadata、以下「DC メタデータ」）[2]を採用しFig.1 初期資源共有化システムのデータスキーマ*1 本稿は参考文献[7]をベースに加筆・修正したものである。
*2 例えばＡとＢという２つのデータベースに人名を登録する場合を考える。データ項目が、データベースＡでは「Name」、Ｂでは「名前」である場合、同一の検索命令で二つのデータベースを同時に検索するは困難である。さらにデータベースＡでは姓と名が別々のデー
タ項目となっているのに対して、データベースＢでは姓と名が一つのデータ項目にまとめられている場合、同時検索はより複雑となる。
なお本稿ではデータ・情報・知識を厳密には区別していない。大まかには、研究対象から収集されてあまり加工されていない比較的「生」の数値や記述などをデータ、データに統計処理や類別化などの知的作業を加えた結果を情報、データや情報の間の構造・関連ある
いは利用法を知識としている。

-1-

た。次に各データベースのデータ構造を CD メタデータの構造に合わせて変換（mapping）してメタデー
タベースに登録する。これにより、全てのデータベースが DC メタデータという同一のデータ構造を持つことになる。
ところで DC メタデータ規約はデータ項目を定義しているだけであり、データベースの実装法には言及していない。つまり DC メタデータベースといっても、あるデータベースは関係データベースシステ
ム、別のデータベースでは文字列検索エンジンにより実現されるかもしれない。このままではデータベ
ースごとに検索方法が異なってしまい、データベー
スをシームレスに接合することはできない。その解決方法として、資源共有化システムでは、Z39.50[3]あるいは SRW（Search/Retrieve Web Service）[4]と呼ばれる標準検索規約を導入してる。
まとめると、初期の資源共有化システムとは、メ
タデータとして DC メタデータ、標準検索手順として Z39.50 あるいは SRW を利用したデータベースシ
ステムであり、① DC メタデータにより各データベースにおけるデータ構造の違いを吸収する② Z39.50 あるいは SRW により各データベースにおける検索法の違いを統一する
ことにより、データ構造や検索手順の異なる複数のデータベースを、データ構造と検索手順が同一のデータベース群であるかのように利用者に見せている。

２．時空間情報の重要性[5]情報を整理する観点の一つとして古くから 5W1Hがある。5W は対象に関する Who（誰が）、What（何を）、When（いつ）、Where（どこで）、Why（どのような目的で）の情報であり、1H は How（どのようにして）の情報である。我々が報告書などを作成する場合、殆ど無意識のうちに、報告内容を 5W1H の観点に分解している。
データベースの設計においても 5W1H は重要な観点であるが、観点の重みには差があるように思われる。例えば書誌目録の場合、題名（What）と作者（Who）の情報が多用されている印象を受ける。時間（When）と場所（Where）に関する情報も重要であるが、多くの書誌目録では資料の内容とは関係の薄い情報が記述されているので（When は出版年、Where は出
版地）、これらを一般利用者が検索に使う機会は少ないであろう。主題は 5W1H の全てを含みうる。しかし日本の場合、主題の整備が遅れているうえに、主題の中身が区別されていないことが多い*3。したがって、例えば「近衛」について検索しようとしても、それが人名なのか、地名なのか、あるいは職名であるのか区別できない。このように、現状の書誌目録における When と Where はあまり重宝しない。初期の資源共有化システムは、基本的には書誌目録デー
タベースを対象としていたので、この問題を抱えている。しかし内容に関する When と Where 情報が整備されれば、情報検索のための重要な手がかりとなることは疑いがない。
ところで非文字資料、例えば考古的遺物あるいは地震などの自然現象に著者はいないので、これらがWho に関する情報を持つことは希である（遺物の発見者などはあり得る）。また What に関する情報についても、識別性の高い記述を与えることが困難な場
合も多い（単に「壺」など）。これに対して When（「いつ」対象物が作られたのか、使われていたのかなど）と Where（「どこで」対象物が作られたのか、発見されたのか、あるいは「どこに」存在していたのかな
ど）は、殆どの非文字資料に共通の情報である。実際 When と Where が唯一の検索手段あるいは比較の指針となる場合も多い。
このように When と Where は殆どの事象・事物に共通な情報である（以降では When と Where を併せて「時空間情報」（spatiotemporal information）と呼ぶ）。
したがって、多様な資源を統合する資源共有化シス
テムの検索において、時空間情報は Who および Whatとともに不可欠な観点となる。そのため人間文化研
究機構の新しい資源共有化システム（「統合検索システム」と呼んでいる）では、DC メタデータを拡張している。時空間情報処理においては、ある事象・事物に関する時間と場所のデータは対になっている必要がある。DC メタデータの Date 要素には空間情報を記述することはできないので、Coverage 要素を拡張して、時間と場所の対を記述することになった。
ところで場所の表現法には地名、住所、ZIP コード、
緯度・経度など、時間の表現法にも和暦、西暦年、ユリウス通日など実に多様である。データベースの検索結果を表示する際には、元データベースの多様な表現法を踏襲する必要がある。一方、時空間情報処理（検索）を効率的に行う上で、位置については
国際標準座標系による緯度・経度、時間についてもISO86015[6]などの国際標準に従って記述されていることが望ましい。この結果、Coverage 要素内には表示用と検索理用の 2 種類の時空間表現を記述することとなった。そのため Coverage 要素内の時空間情報
記述は少々複雑になっている。
ところで資料分析の過程で、事象の発生場所や事*3 例えば LC MARC（米国議会図書館の機械可読目録：MAchine Readable Cataloging）の場合、tag 150 $y に時間に関するトピックを記述することができる。また tag 651 には地理名称を記述することができる-2-

国史、タイ史など）が分布する。GIS に相当して複数の年表をコンピュータ上に表示したり、重ね合わせたりする情報処理システムは、あまり例がない（例
え ば MIT に よ る SMILE プ ロ ジ ェ ク ト のTimeLine[8]）。
これらに加えて時空間情報解析を支援するツールとして、デジタル歴史地名辞書と暦日テーブルがある。デジタル歴史地名辞書は、歴史地名の属性、現在地名との対応、緯度・経度などを登録した地名辞書である。暦日テーブルは、グレゴリオ暦と和暦など、異なる暦日間の相互参照表である。
以下では主題軸と空間軸が形成する地図平面に対応する GIS ツールとして開発を進めてきた GT-Map
について述べる。

Fig.2 時空間情報モデル（久保、関野）[7]
物の所在を半透明の用紙にプロットして地図を作成
したり、このような地図を何枚も重ね合わせて分布を比較したりすることは、地域研究などではよく見かける作業である。同様に事象を時間順序に並べ替えて年表を作成したり、因果関係を見いだすために複数の年表を並べるようなことも、歴史研究では基礎的な作業であろう。これらは時空間情報を基盤としている。以上の考察から、人文科学のあらゆる場
面において時空間情報は重要な役割を果たすと考えられる。

４．空間情報解析ツール（GT-Map）

３．時空間情報モデル
時空間情報処理モデルを Fig.2 に示す。ここでは
資 料 の 内 容 に 関す る情 報を主 題軸 （ Theme/Subject
Axis）、空間軸（Spatial Axis）、時間軸（Temporal Axis）の 3 次元に分解して表現している。空間情報を緯度と経度で表せば全体として 4 次元となる。
主題軸は、その名の通り、事象・事物の主題や内容などを語彙情報に従って配列するものである。これは従来の目録的な情報に相当する。
空間軸は事象・事物を位置情報に従って配列するものである。これは従来の地図的な情報に相当する。
標準的な位置情報の記述法は緯度と経度の対であるが、住所や郵便番号などでも構わない（地名辞書などを利用して緯度・経度の対に変換できる）。主題軸と空間軸が形成する平面には、様々な主題図（ベース地図、道路地図、土地利用図、汚染分布図、患者
発 生 地 図 な ど ） が 分 布 す る 。 GIS（ Geographical
Information Systems/Science）とは、これらの地図をコンピュータ上に表示したり、重ね合わせたり、様々な演算処理を行う情報処理システムである。
時間軸は事象・事物を時間情報に従って配列するものである。これは従来の年表的な情報に相当する。
標準的な時間情報の記述はグレゴリオ暦であるが、和暦などでも構わない（暦日テーブルなどを利用してグレゴリオ暦に変換できる）。主題軸と時間軸が形成する平面には、様々な年表（日本史、朝鮮史、中-3-GT-Map（Geo-Temporal Map）は主題軸と空間軸が形成する地図情報を処理する GIS ツールの一種である。ただし時間情報も処理できるという特徴を持っている。基本的にはクライアント側のツールであるが、サーバ側ツールとしても提供可能である（統合
検索システムの「空間表示機能」はその一例である。
ただし検索機能に制限されている）。
GT-Map は University of Sydney の ArchaeologicalComputing Laboratory と University ofCalifornia
Berkeley の ECAI （Electronic Cultural Atlas Initiative）
プロジェクト[9]が開発した TimeMap[10]を基礎としている。TimeMap は GIS ビュアの一種であり、様々な地図や航空写真などを重ね合わせて表示させることができる。この重ね合わされる個々の地図や写真などをレイヤ（layer）と呼ぶ。さらに、レイヤ上の指定した対象物あるいは矩形で指定した空間範囲にある対象物に関する情報を、データベースから検索して表示することもできる。この地図上の対象物をフィーチャ（feature あるいは地物：道路、病院、神社、河川、行政界など実世界に存在するものを抽象化した概念。レイヤ上では点、線、多角形などの図形として表現される）と呼ぶ。TimeMap の特徴は、指定した空間範囲のデータだけではなく、指定した時間範囲に関連した事象・事物も、データベースか
ら検索して表示できる（そのため TimeMap と呼ばれている）。さらにフィーチャデータの中に URL が記載されていれば、それが示す Web コンテンツを表示
あるいはプログラムとして実行することもできる。
しかし TimeMap には、漢字コード（特に日本語）をうまく処理できない、DC メタデータの項目を指定した検索ができない、GIS 用メタデータファイルの作成が面倒、解析機能を持たないなどの問題点があった。そこで TimeMap Open Source Consortium との間で TimeMap ソースコードの利用に関する覚書を交
わし GT-Map の開発を開始した。当初は TimeMap のソースコードをかなり利用していたが、最新版のソースコードは完
全にオリジナルなものととなっている。
GT-Map は以下の 5 つの部分から構成されている（Fig.3）。
① メ イ ン メ ニ ュ ー バ ー （ Main
Menu Bar）：プロジェクトの保存と呼出、アプリケーショ
ンの環境設定などの機能を提供する。
②アイコンメニューバー（Icon
Bar）：フィーチャの拡大・縮小・移動（パン）、フィーチ
ャや空間領域指定などの機能を提供する。
③ ス ペ ー ス ビ ュ ア （ Space
Viewer）： レ イ ヤ 情 報 を 表 示する。
④プロジェクトビュア（Project
Viewer）： 処 理 の 対 象 と な る
レイヤのリストである。表示や検索の対象とす
るレイヤの選択、フィーチャの表示属性の編集機能などを提供する。
⑤タイムスライダ（Time Slider）：スペースビューに表示するフィーチャの時間範囲内を指定する。
GT-Map は GIS ツールであるため、以下の基本的な GIS 機能を実現している。
①ベース地図の上に複数のレイヤ（主題図、分布図、衛星写真、航空写真など空間データの単位）を重ね合わせて可視化する機能。
②空間領域における図形のズームイン・ズームア
ウト機能。
③フィーチャの主題属性を対象とした検索などのデータ処理機能。
④フィーチャの空間属性を対象とした検索などのデータ処理機能。
さらに GT-Map の特徴として、以下の機能をあげることができる。
⑤フィーチャに関する情報（写真、HTML 文書、
プログラムなど）への Web リンクを介したアクセス機能。
⑥プロジェクト（project）：GT-Map では複数の関Fig.3 GT-Map の概要
連するレイヤをプロジェクトという単位にまとめることができ、レイヤのアクティブ化・非ア
クティブ化あるいは削除などの操作をプロジェ
クト単位で容易に実行できる。
⑦フィーチャの時間属性を対象とした検索などのデータ処理機能。
⑧時間情報に従ってフィーチャを時系列的に表示
するアニメーション機能。
⑨ JAVA で作成されている GIS ツールであるため
プラットフォームへの依存性が低い。
なお GT-Map で処理可能なデータのファイル形式
は、ESRI ShapeFile、CSV（Comma Separated Values）
ファイル、XML ファイルである。さらに画像データ
として JPEG、JPEG2000、GIF、TIFF、PNG が利用可能である。
上記以外の機能として、以下に示す GIS 機能の研究・開発を進めている（ただし現時点の GT-Map には実装されていない）。
⑩" レイヤ間の比較・論理演算⑪" クリアリングハウス（Clearing House）*4 との連携：レイヤデータ、プロジェクトデータおよび時空間処理ツールに関するメタデータをクリ
アリングハウスから検索し、インポートする機*4 本来のクリアリングハウス（clearinghouse）は、資料やデータを収集・保存して利用できるようにする機関のことである。GIS 分野のリアリングハウスは、インターネット上に分散している地理情報を交換する仕組みである。複数のデータベースで蓄積されている地理情報に関するメタデータを管理し、メタデータ検索を介して空間データの所在情報や空間データへのアクセス機能などを提供する。クリア
リングハウスによっては、ダウンロードだけではなく、独自に作成した空間データを公開する機能も提供している。HGIS 研究グループのクリアリングハウスは空間データのみならず、空間解析ツールの登録・公開も可能となっている。

-4-

Fig.4 GT-Map による空間データの表示例
詳細なデータを表示する（図中⑤）。

能。反対にクリアリングハウスへレイヤデータなどをエクスポートする機能⑫" JAVA Plug-in 機能：TimeMap は基本的にビュアであり、DEM（Digital Elevation Model）を利用した傾斜計算などができない。そこで様々なデータ処理機能を GT-Map の外部アプリケーシ
ョンとして作成し、これらを適宜 GT-Map から呼び出して使えるようにする。このプラグイン（plug-in）方式を採用することにより、GT-Map
を単なるビュアではなく、解析ツールとしても利用できるようにする。
⑬" アノテーション（annotation）機能：レイヤ上の任意の地点あるいは矩形領域を指定して情報（XML 文書および画像など）を追加したり、それらを地図上で表示したりする機能。これはフィールドワークにおける利用を想定した機能である。これにより、フィールドワーク中に収集した写真などの資源をメモなどとともにデータベースに蓄積できるようにする。

５．歴史データの GT-Map への適用例
空間情報解析ツールを人文科学研究資源へ適用した事例として、「歴史地震データベースの構築」を紹介する[11]。
5.1 歴史地震資料のデジタル化
我が国の歴史地震記事は、田山実編『大日本地震史料』[12]や武者金吉編『増訂大日本地震史料』[13]などに網羅されている。これらの歴史地震史料集には正史のみならず伝聞・噂あるいは後世に書き加えられたテキストなど多種多様な記事が収集されている。そのため信頼性の低い記事も混在しており、誤った結論を導く原因ともなっている。
「古代・中世の全地震史料の校訂・電子化と国際標準震度データベース構築に関する研究」は、歴史
地震史料集が抱える上記の問題解決を目指した研究
プロジェクトである（以下、歴史地震研究）[14]。
歴史地震研究では、史料の信頼性・異本関係・校訂などの本文批判（text critic）を通じて、信頼性の高い地震記事の選別・修正を行い、精度の高い地震史
料データベースの構築を目指している。歴史地震研
究では史料のデジタル化から着手した。ここでの特色は XML を全面的に導入している点にある。デジタル化は終了し、作成された電子テキストを利用し

GT-Map の表示例を Fig.4 示す。これは近畿付近における歴史地震の分布例（5 章参照）を示している。
ここでは地図上の矩形（図中①）とタイムスライダの時間（図中②）で指定された時空間範囲にある地震データとその属性情報一覧を表形式（図中③）で提示している。この表から特定の地震データを選択すると（図中④）、該当する地震データの位置を地図上の色の反転で示すとともに、WEB リンクを介して-5-

Fig.5 歴史地震史料の電子化テキスト例
た本文批判の作業が進行中である。XML マークアップを施した電子テキストの例を Fig.5 に示す。

ところで GIS ツールではレイヤ制御などの情報を設定する必要がある。GT-Map ではレイヤ用（tmm）とプロジェクト用（tms）の 2 種類の制御ファイルが必要である。両者とも XML 形式のパラメータ設定
ファイルであるが、かなり煩雑である。Fig.4 に示した GT-Map 表示例における Earthquake Sample Data レ
イヤの tmm ファイルを Fig.6 に示す（説明は省略する）。これを手作業で作成するのは簡単ではないため、
メ タ デー タ専 用 の オ ー サ リ ン グツー ル（ authoring
tool ）の構築を予定している。
歴史地震研究は継続中であり、ここで示したデー
タも作成途上であるが、この地震発生分布地図に震度分布や災害地図などを重ね合わせれば、基本的な震度データベースを構築できると考えている。本格的な解析作業はこれからである。

5.2 時空間情報の抽出と利用
電子テキストを眺めてみると、各地震記事には必ず時間情報（Fig.5 の<J.Date>など）が付与されており、主な内容は地震に関連した事象（建物の倒壊など）と場所に関する記述である。そこで地震に伴う事象の発生時刻と位置の同定を試みた。サンプルとして 9 つの地震を選択した。
実験では、まず地震記事から建物・市街・遺跡などの地名を抽出した。次に抽出した地名に対応する
現在地名を可能な限り推定した。最後に現在地名から緯度と経度を求めた。市街のように広がりを持つ地名の場合、役場など、その区域を代表するフィー
チャの緯度・経度（地点）を採用した。和暦は年月日までをグレゴリオ暦に換算した。これらの作業は歴史専攻の大学院生に依頼した。
作成された時空間データの一部を Table.1 に示す。
こ こ で NDATE は 地 震 に 伴 う 事 象 の 発 生 時 刻 、ONAME は事象が発生した場所、PNAME はその現在地名、DLAT はその緯度、DLON は経度である。
このデータを GT-Map で利用するには ESRI Shapefile
形式あるいは CSV ファイル形式に変換しなければな
らない。ESRI Shapefile 形式への変換には特別なツールが必要であるが、CSV ファイルへの変換に特別なツールは不要である。

５．あとがき
資源共有化システムは、人文科学に関する多様なデータや情報を統合して新しい研究知の創出を支援する情報処理システムである。本稿では、資源共有化システムについてメタデータの視点から解説し、そこから派生・発展しつつある時空間情報処理ツールの開発状況とその応用について述べた。

資源共有化システムを研究者の視点から見た場合、資源の所在を容易に検索できるようになったことは評価できるものの、研究支援あるいは知識発見のツールにはなり得ていないと思われる。資源共有化シ

Table.1 地震記事の時空間データ例-6-知識利用の初歩的な取り組みと考えられる。
時空間情報処理は人文科学分野における新しい研
究パラダイムであり、Google Earth などの既存ツールに拘泥されるよりも、自由な発想で研究開発を進め た 方 が 良 い と 考 え て い る 。 実 際 GT-Map や
GT-Time[7]などは我々自身が開発しているツールであるため、研究の進展に応じた機能の変更・拡張を臨機応変に行うことができる。例えば GT-Map とGT-Time を相互に連携させるツールが検討されている。これは、特定の事象・事物を空間的な視点から
俯瞰・分析する際には GT-Map を利用し、同じ事象を時間的な視点から俯瞰・分析したければ GT-Timeに切り替えることのできる本格的な時空間解析ツールである。時間と空間を同時に処理できるようになるため、Google Earth などより優れた解析ツーになると言える。これは進展が著しい研究領域における支援ツールとして重要な要件であると考える。

謝辞
本稿に関連した時空間解析ツールおよびデータの開発には、HGIS 研究グループ[15]による貢献があった。HGIS 研究グループのメンバー、特に柴山守（京都大学教授）、桶谷猪久夫（大阪国際大学教授）、久保正敏（国立民族学博物館教授）、貴志俊彦（神奈川大学教授）、関野樹（総合地球環境学研究所準教授）、相田満（国文学研究資料館助教）、石川正敏（東京農工大学助教）の各氏に感謝いたします。

Fig.6 tmm 設定ファイル例(一部)
ステムは資源の蓄積・所在に関する情報システムであり、それらの内容を対象とはしているとは言い難
いからである。そのため、資源共有化システムに蓄積された多様なデータ・情報を検索し、それらを分
析・統合・解析して新しい知識生成を試みる、具体的には可視化・語彙分析・画像解析・統計処理・時
空間解析・シミュレーションあるいはデータ間の関連付け・分類・情報縮約・因果関係の抽出・将来予測・評価などを行うことは困難である。
資源共有化システムを研究支援あるいは知識発見
ツールとするためには、資源の内容に関する情報をより豊富にする必要がある。Fig.2 のモデルに従うと、資源の内容を、事象・事物（概念，モノ，事件，人物，事件など）の主題という語彙による関連づけだけではなく、時間的・空間的にも関連付けることが必要である。これにより、語彙のみの場合に比べてより高度な情報処理を実現できる。このような事象
・事物間の関連づけを仮に「知識」とするならば、用語辞典・地名辞書・暦日データなどのオントロジ
ー辞書を構築して、資源を相互に関連付ける試みは、
-7-

参考文献
[1] 原正一郎,安永尚志: 国文学電子資料館システム,
国文学研究資料館紀要, No.26, pp.25-52, 2000.
[2] Dublin Core Metadata Initiative: Dublin Core
Metadata Element Set Version 1.1 Reference
Description, http://dublincore.org/documents/dces/,
2004.
[3] ANSI/NISO: ANSI/NISO Z39.50-1995 Information
Retrieval (Z39.50) Application Service Definition andProtocol Specification, 1995.
[4] The Library of Congress: SRU(Search/Retrieve via
URL),http://www.loc.gov/standards/sru/,2004.
[5] 原正一郎,柴山守:地域情報学の構築と時空間情報解析ツール、人文科学とコンピュータシンポジウ
ム論文集 2007、Vol. 2007,No.15,pp.71-78,2007.
[6] ISO: ISO 8601 Data elements and interchange
formats - Information interchange - Representation ofdates and times, 2004
[7] Tatsuki SEKINO: Temporal Based Information
System (T2Map), PNC2007 Abstract,
http://pnclink.org/ pnc2007/pdf/20_0940_
AreaInformaticI.pdf[8] MIT: "SMILE Project TimeLine,"http://simile.mit.edu/timeline/[9] ECAI (Electronic Cultural Atlas Initiative):
http://ecai.org[10] Ian Johnson: TimeMap Time-based Interactive
Mapping, The Archaeological Computing
Laboratory, University of Sydney,
http://www.timemap.net/index.html[11] 原正一郎:地震史料の XML データ作成,
月刊地球, 総特集地震史料の校訂とデータベー
ス化－日本の古代・中世を中心に－,海洋出版
vol.27, No.11, pp.853-860.
[12] 田山実:大日本地震史料, 震災予防調査会報告,No.46, 1904.
[13] 武者金吉編: 増訂大日本地震史料, 文部省震災予防評議会, 第１巻, 1941, 第２巻, 1943, 第３巻,
1943.
[14] 石橋克彦: 古代・中世の全地震史料の校訂・電子化と国際標準震度データベース構築に関する研究,科学研究費補助金基盤研究(A)(1),
http://historical.seismology.jp/erice/[15] HGIS 研究会：
http://www.cseas.kyoto-u.ac.jp/projects/other/
shibayama1-projects_ja.html-8-時間情報に基づく解析ツール
関野樹（総合地球環境学研究所）

年表やグラフは情報を時系列に沿って表示する手段として長年用いられてきた。もし、これら年表やグラフに含まれる情報を同じ時間軸上に並べることが出来れば、異なるタイプの情報間の関連性を時間情報に基づいて解析してゆくことが可能になるはずである。GT-Time (Geo-Temporal Time)は、このような時間情報に基づく解析を実現する解析ツールである。本発表では、この GT-Time の概要について報告する。

１．まえがき1
人間文化研究機構の研究資源共有化推進事業
では、所属する五つの機関が持つデータベースを網羅的に検索する仕組みを構築し、研究教育に必要な情報を効率よく発見・利用してゆくとともに、それらが特定のデータベースだけでは気付かな
かったような新たな知識の発見につながることを目指している。既存の多くの検索システムでは、
キーワードを入力することでそのキーワードを含む情報を検索している。本事業のように異なる種類の情報を結びつけて検索する場合、キーワー
ドは情報同士の接点として有効であるものの、入力された語の綴りや送り仮名など僅かな違いに
より検索結果が大きく異なることなどの問題も指摘されている。近年、このような異なる種類の情報同士を結びつけるための新たな接点として、
時空間の情報が注目されており、様々な解析手段が提供されている。
地理情報システム（GIS）は、空間情報に基づいて様々な情報を連携させ、それらの関連性から新たな知見を発見しようとするものである。地図
上に様々な情報を表示してゆくだけはなく、地図の重ね合わせや位置情報に基づいた様々な解析が可能である。その有用性は、近年様々な分野でこれらが普及していることからも明らかであり、空間情報が情報同士を結びつけるための接点として重要であることを裏付けている。
これと同様に、時間情報も情報同士を結びつけるための接点として重要である。時間情報を伴う資料としては、国文学研究資料館が所蔵するような日記や史料などの時系列に沿って記述された文書資料がまず挙げられるであろう。さらに、国際日本文化研究センターの和歌や俳諧のデータ
ベースであれば、それらの作成年代が時間情報として伴っている。また、国立歴史民俗博物館や国立民族学博物館が所蔵する考古資料や民族資料

本稿は、2007 年 12 月発行の文献[1]に対し、最近 2 ヶ月
間に GT-Map に追加された機能に関する情報を書き加えるなどの修正を行ったものである。

などモノとして存在する資料についてはその制
作年代や利用期間が、写真や映像資料については撮影日時といった時間情報が伴っている。さらに、総合地球環境学研究所で扱っているような気象などの環境モニタリングデータ、地層の解析から推定される地震、洪水、津波の災害の記録などにも時系列に沿った情報が存在している。このように時間情報を伴う多種多様な情報があり、また、扱う時間範囲についても 1 日を単位とした短期間のものから世紀にまたがる長期のものまで様々なレベルの時間情報を伴った情報が存在する。これらの情報同士を突き合わせることによって、単一の情報からは知りえない新たな知見が明らかになってゆく可能性がある。
しかしながら、時間情報に着目し、ある期間に生じたイベント間の相関関係や周期性に関する分析を行うことが出来るツールは未だ存在していない。多種多様な情報を自由に組み合わせて試
行錯誤を繰り返しながら新たな知見の発見につなげてゆくためには、GIS のように各種の情報を総合的に取り扱うことの出来るツール、いわば「時間情報版の GIS」のようなツールが必要なのである。本事業では、GIS のような総合的な解析
環境で時間情報に基づいた解析を行うことを実現するため、新たな解析ツール（GT-Time）の実
験的な開発を行った。今回は、この GT-Time の概要について報告するとともに、このようなツールの応用可能性や時間情報を用いた研究の方向性について議論を進める。

２．GT-Time の特徴
GT-Time は、2005 年度より研究開発が行われていた T2Map の構想を基にして、2006 年度より本事業で開発が進められ、データの表示機能、
表示範囲の選択（タイムスライダ）、マスクを使ったデータの解析機能などが実装された（図１）。
以下に本ツールの特徴を示す。
時間情報への特化：GT-Time は、その機能を時間情報の解析に特化させていることが従来の類似のツールと決定的に異なる点である。時間情レイヤ(数値データ)レイヤ(文字列データ)レイヤ(時間軸目盛り)

レイヤ一覧(レイヤの表示/非表示切り替えと表示順の操作)

タイムスライダ(時間軸と表示範囲の操作)

図１:GT-Time の概観
タイムスライダにより表示範囲を選択する。図では 1800～1870 年が選択・表示されている。

報に基づいて情報を表示・解析するためのツール
は GIS の分野でも開発されており、TimeMap[2]をベースに本事業で構築された GT-Map など、幾つかの GIS ツールが空間情報と時間情報を組
み合わせて表示・解析する機能を有している。しかしながら、これらの GIS ツールでは扱う情報
が空間情報を伴っていることを前提としており、空間情報を持たない情報を扱うことが難しい。例
えば、「世界大恐慌」はその期間を特定できるものの、その場所を特定することが難しい。また、「歴代天皇の在位期間」など、時間情報を扱う上での基本的な情報も空間情報を持っておらず、GIS で扱うことが出来ない。この点で、GT-Timeはその機能を時間情報の解析に特化させること
により、空間情報を持たないこれらの情報を適切な形式で表示し、情報間の関連性を時間情報に基づいて解析することを可能にしている。
解析ツールとしての機能：GT-Time は、情報を表示するための単なるビュワーではなく、解析ツールとしての機能に重点を置いている。従来もいくつかの年表作成ツールが研究ベース[3,4,5]や事業ベース[6]で開発されている。しかしながら、これらは情報を表示するためのビュワーとしての機能が主であり、研究に資するような十分な
解析機能は持たない。この点で、GT-Time では
様々な検索機能や情報間の関連性を時間情報に基づいて解析するための機能が充実している。また、GT-Time では、数値データを折れ線グラフ
やプロットグラフなどの形で扱うことが可能であり、これらを年表形式で表示された文字列のデータと組み合わせて表示することが出来る（図１）。これにより、人文科学分野だけでなく、社
会科学、自然科学の多様な情報を用いながら、新
たな知見の発見に資することを可能にしている。
暦法の違いを吸収：時間情報の取り扱いには、
和暦、西暦といった暦法の違いの問題が存在する。
これは、空間情報を GIS で扱う際の座標系の問

図２:複数の時間軸目盛りを表示させた例
明治の改暦前後について、旧暦のままの目盛り（旧暦）、改暦された目盛り（和暦）、西暦の目盛りをそれぞれ示した。また、日付と異なる目盛りの例として、
二十四節季による目盛りを示す。

題とよく似ている。GT-Time では、基準となる
時間軸を汎用性の高いユリウス通日にすること
で、異なる暦法で表現された時間情報を同じ時間軸上に表示することを実現している。ユリウス通日は、紀元前 4713 年 1 月 1 日正午からの通算日数であり、改暦などに伴う不連続がない（西暦も、1582 年 10 月にユリウス暦から現行のグレゴリ
オ暦に改暦された際に 10 日間の不連続がある）。
この特徴を活かし、ユリウス通日は天体の運行を計算することなどにもしばしば用いられている。
GT-Time では、このユリウス通日に複数の暦の日時を対応させることで、異なる暦法による時間の情報であってもその時間的な関係の解析を可能にしている。また、暦が存在しないような地質
年代の情報も、ユリウス通日を負の値として過去に拡張することにより取り扱うことが出来るよ
うにしている。
西暦以外の暦に基づく情報を扱う場合は、それぞれの暦が示されている方がそれらの情報を理解しやすい。例えば、イスラム教に基づく行事についてはイスラム暦に基づいた時間軸が無ければ理解できないし、農業に関する行事であれば、雨季・乾季などの期間が示されていると理解しやすい。そのため、GT-Time では、レイヤとレイヤの間に任意の時間軸目盛りを表示する機能がある（図 2）。この目盛りは、ユーザが作成した情報に基づいて作成されるため、暦以外の不定期に起きる情報を時間軸の目盛りとして用いることも出来る。
イベント間の期間を計測：GT-Map には任意の時点間の期間を計測する機能がある。これは GIS

において任意の地点間の距離を測定する機能に相当する。計測され期間は、年、月、週、日、時間の単位で表示することが出来る。なお、年は365.25 日、月は 30.4375 日（365.25 / 12）として計算している。

３．GT-Time による時間情報解析
上述のように、GT-Time は時間情報に特化した解析ツールである。ここでは、この GT-Timeが提供する時間情報に基づいた解析について、解析事例に沿ってその考え方を紹介する（図３）。
GT-Time では、データが表示される単位をレイヤと呼んでいる（図１）。レイヤは横方向に時間軸を設定しており、左から右へ時間が進む。レイヤには、大別するとデータレイヤ、マスクレイヤおよび目盛りレイヤがあり、それぞれ役割が異なっている。
データレイヤ： 年表のように文字情報を表示するための文字列レイヤと数値情報を折れ線グラ
フ、プロットグラフ、棒グラフとして表現する数
値レイヤがある。文字列レイヤでは、横方向のバーとして各イベントが生じた期間を表現する。期間を示すバーをクリックすることにより、イベン
トの詳細を見ることが出来る。文字列レイヤや数値レイヤは与えられたデータに基づいて作成される。基となるデータは、GT-Time 用のスキーマに基づいた XML ファイルもしくは CSV ファ
イルからインポートされる。
マスクレイヤ： 解析を行うための特殊なレイヤ。
各イベントは時間範囲のみを持ち、イベントとしての内容は無い。検索結果や特定のデータに基づいて作成される。マスクレイヤ間では論理積・論
理和・否定の論理演算が可能であり、これらを利用して解析内容に合わせたマスクレイヤの加工を行う。このマスクが示す期間に基づいて他の文字列レイヤや数値レイヤから必要とする期間の情報を抽出する。
目盛りレイヤ：時間軸目盛りを表示するための特殊なレイヤ。西暦以外の暦による目盛りや潮汐な
どの自然現象、景気、政権交代などの不定期に起こる現象を時間軸の目盛りとして用いることが出来る。
以下、図３の例に基づいて GT-Time を使った解析の考え方について説明する。
（１）マスクの生成
マスクは、数値データや文字列データの検索結果から作成する方法と、任意のデータから直接生成する方法がある。図３では、検索による作成方
法を示している。数値データの場合は、「特定の値以上」等の検索条件を満たす期間の集合としてマスクが作成される。一方、文字列の場合は、特定のキーワードを含むイベント期間の集合としてマスクが作成される。図３の例では、数値デー
タの場合が「経済指標がマイナス」という条件で、文字列データの場合が「『不景気』を含む記事」という条件でそれぞれ新たなマスクレイヤが生成されている。
また、構想段階の機能であるが、単純に検索された期間の集合だけでなく、検索条件に合致した時点を基準にしてマスクを過去・未来に伸張させることにより、「地震発生から 1 週間以内」、「政
権交代の前後 3 日」などの期間を持つマスクを作ることが出来る。
任意のデータからマスクを作成する場合は、マスクする期間を記述した XML ファイル等を読み込んで作成する。潮汐や月の満ち欠け、四季などの繰り返し生じる現象、天皇や将軍の在位期間な
どの基礎的なデータはこの方法で作成するほうが容易であろう。
（２）マスクの加工解析内容に合わせて、マスクレイヤ間の論理演（解析内容）
経済指標がマイナスで、新聞も不景気に関する記事を掲載しているときに、議会ではどのような議論がされていたのか？

１．マスクの生成

２．マスクの加工（１）数値データの検索結果からマスクを生成
経済指標の経時変化（マスク３）（マスク１）

マスク１と２の論理積指標がマイナスの期間

３．マスクによる情報の抜き出し
議事録（２）文字列データの検索結果からマスクを生成
新聞記事（マスク２）「不景気」を含む記事（解析結果）

マスク３を使って抜き出し

図３：GT-Time による時間情報に基づく解析の事例
１．マスクの生成、２．マスクの加工、３．マスクによる情報の抜き出しを繰り返しながら、情報間の関連性を時間情報に基づいて解析してゆく。

図４:マスクを使った検索を行う画面（左）マスク同士の論理演算、（右）マスクを使ったレコードの抽出。

算を行い、必要なマスクを生成する（図４）。図３の例では、「経済指標がマイナス」かつ「新聞が不景気に関する記事を掲載している」という 2
つの条件を同時に満たす期間を求めようとしている。この場合、それぞれの検索結果から生成されたマスクレイヤ（マスク１、２）の論理積を取ることで、必要とする期間を示すマスクレイヤ（マスク３）を生成することが出来る。このほかに、マスクレイヤ間の論理演算として論理和、否定が可能である。特定の条件に当てはまる期間を除外したい場合などに否定は有効である。
（３）マスクによる情報の抜き出し作成したマスクレイヤを使って、データレイヤ
から情報を抜き出す（図４）。つまり、マスクで示された期間に含まれるイベントを別のデータレイヤから抽出し、新たなデータレイヤを生成する。図３の例では、条件に当てはまる期間の議事録の情報を抜き出している。無論、抜き出した情報によるデータレイヤを使って新たにマスクレイヤを生成するなどの解析が可能である。
このような操作を繰り返すことにより、複数のデータレイヤに示された情報を時間情報に基づいて解析し、その関連性を解析してゆくことが可能になる。

４．今後の展開（１）辞書との連携
GT-Time を利用するためにはツール本体だけでなく、利用に必要な基本的なデータを整備しておく必要もある。例えば、諸外国の暦を扱うためには、暦間の変換テーブルが必要である。これは、先述のユリウス通日にそれぞれの暦を対応させたものを用意しておけばよい。また、天皇や将軍などの在位期間のデータ、平安・鎌倉・室町といった時代区分に関するデータ、歴史上の代表的な事件を集めた歴史年表データなど、時間情報を扱う上での基本データも必要になる。これは、GISを利用するのに行政界や地形などの基本的なデータが必要になることに相当する。また、Time

Period Directory[7]などの時間名に関する情報
源や時間情報で整理されたディレクトリサービ
ス[8]と連携することで、その利用の幅が広がってゆくことが期待される。
（２）インターフェース機能として
GT-Time は年表やグラフを表示するためのビュワーとしても十分な機能を持っている。このため、GT-Time から検索や解析などの複雑な機能を廃し、これを時間情報の表示を行うためだけのインターフェースとして利用することも想定される。時間情報を持つデータベースに対し問い合
わせを行い、結果を年表形式で GT-Time 上に表示するのである。これは、GT-Time が研究目的だけでなく、アーカイブの構築といった事業的な用途にも適用できることを示している。これについては、本事業の統合検索システムの時空間イン
ターフェースとして実現している。
（３）新たな機能の追加
GT-Time にはプラグインとして機能を追加することが出来る。これにより、新たな表示機能や検索・解析機能などを追加してゆくことを可能にしている。
表示機能では、現在は同じ色で表示される年表やグラフをテーマ毎に色分けして表示する機能
や、表示するイベントに優先順位をつける機能などが有用であろう。また、時差に対応することにより、地域間の情報の比較が容易に行えるようになる。
検索・解析機能では、移動平均などの統計解析機能の実装、アノテーションの付加や情報間の関連を視覚的に表示するなどの機能も考えられる。
さらに、周期的・非周期的に繰り返し起こる現象を解析するための機能が渇望される。これにより、田植えの時期や政権交代後の支持率の変化を比較するといった類の解析が可能になる。
地理情報との連携も、今後追加されるべき機能として重要である。特に、GT-Time とのデータの互換性やインターフェースの共通化などにより、利用者が時間・空間の情報を駆使して様々な

事象間の関係を探索することが可能になると思われる。

５．あとがきGT-Time は、多種多様な情報を組み合わせて様々な解析を行い、それに基づいて新たな時系列のデータ（年表）を作成するという、新たな発想を取り入れて構築された解析ツールである。この点で、旧来の年表作成ツールとも GIS とも異な
る全く新しいタイプのツールであるといえる。本事業で構築された GT-Time は必ずしも実用段階には達していない機能もあるが、ここで培われた技術や考え方を将来の研究開発に生かすことで、歴史学や考古学のように時間情報を直接扱う分
野だけでなく、思想、経済、政治、そして、様々な情報を総合的に扱う必要がある地域研究や民族学研究など、人文社会科学の諸分野において大きな貢献を果たすものと思われる。

参考文献[1] 関野 樹・久保 正敏 (2007) T2Map－時間情報に特化した解析ツール. じんもんこん2007, 情報処理学会シンポジウムシリーズ 2007(15),71-78.
[2] TimeMap Open Source Consortium. http://www.timemap.net/[3] SIMILE TimeLine. http://simile.mit.edu/timeline/[4] Longviewer. http://www.longnow.org/about/lon
gview.php[5] The Historical Event Markup and Linking pro
ject. http://www.heml.org/samples/blocks/heml/sa
mple-timeline[6] @Nifty TimeLine. http://timeline.nifty.com[7] Vivien Petras, Ray R. Larson & Michael Buckl:Time period directories: A metadata infrastructure
for placing events in temporal and geographic
context. 6th ACM/IEEE-CS Joint Conference on
Digital Libraries; June 11 - 15, 2006. Chapel Hill,
NC, USA.
[8] History by Time Period in the Yahoo! Direct
ory: http://dir.yahoo.com/Arts/Humanities/History/By_Time_Period/

文化資源の時空間統合アーカイブズ：研究資源の共有を目指して
国立民族学博物館・文化資源研究センター

久保正敏

１．文化資源アーカイブズ：文化のダイナミズム解明を目指して
人間文化の多用な豊かさを研究するには、様々な方法がある。国立民族学博物館の文化資源研究センターでは、文化に関わる資源を幅広く捉え、可視なモノ資料や可視化が容易
な文字・数値・図像・画像・映像などの資料、そこから生み出される二次、三次資料、さらには、知識・技術などの身体化された情報、組織や観念などの制度化された情報もカバーすることを狙っている。これらは、総体として文化事象の記録であり、その蓄積は人間文化の理解に役立つ。もっとも、文化事象は、環境・政治・経済・社会・文化がからみあった複雑な系であり、その理解は、様々な視点や立場の研究者たちによる仮説設定や発見、
それらに基づく総合的な議論の積み重ねの中から生まれてくるものであろう。そこに、研究資源を共有する意義がある。
しかしながら、従来、社会学・政治学・地理学などマクロな解析と文化人類学のようなミクロな解析は、必ずしも相補的に行われてきた訳ではない。文化事象は、ミクロ－マク
ロ様々なレベルの事象が相互に関係し合うダイナミズムの中でこそ理解できる。ダイナミ
ズムのベースとなるのが時空間情報であり、すべての文化資源は時空間情報を伴う事象として扱われるのが望ましい。
自然科学分野でも、気象など環境モニタリング・データ、地層の解析から推定される地震、
洪水、津波の災害記録、など、様々な時空間情報を伴った事象が存在する。これら数値を記録文書など非数値情報と突き合わせれば、生態学的分析や地域史と気候変動史との相関関係など、大きな枠組みの中で数値の意味を明らかにできよう。
このように、人文科学的な文化資源情報と自然科学的な数値情報の両者を、時空間情報をベースとする事象として捉えてアーカイブズ化し、その解析ツールを整備すれば、事象間の関係性を発見し、地域や領域の動的な関係を総合的に理解できるだろう。
例えば、筆者のフィールドであるオーストラリア・アボリジニの社会・文化を見ても、19 世紀後半から対アボリジニ保護隔離政策が適用され始めた要因の一つには、雨量減少により水場が減少した結果、白人入植者とアボリジニの接触と衝突の機会が増えたことがある。
また同時期の英国での人道主義や、当時脚光を浴びていた生物進化論が、保護隔離政策の一環として 20 世紀に入ってからの混血児引き離し政策につながった。このような、個々の事象が相互に関係し合うダイナミズムは、個別のコミュニティ調査だけでは捉え難く、それを取り巻く諸要素の系を通時的・共時的に分析して総合し、要素間の因果関係など、自明ではない種々の相関関係を発見しない限り、理解することが難しい。
また筆者は、総合地球環境学研究所（地球研）で進められてきたプロジェクト研究「アジア・熱帯モンスーン地域における地域生態史の統合的研究：1945－2005（代表：秋道智彌）」に参加し、生態史という観点から研究資源の活用を模索してきた。生態史とは、人と環境との相関関係の系を歴史的・総合的に捉える立場であり、やはりここでも、複雑な系のダイナミズム解明がポイントとなる。このプロジェクトでは、特に環境史に関わる歴史文書の一例として、中国で公刊された「雲南県志」の一部を和訳し、文書アーカイブズ化を試みている。これは生態史プロジェクトのメンバーである兼重努（滋賀医科大学）、長谷千代子（地球研プロジェクト研究員）の努力によって進められてきたものである。
いずれのプロジェクトにおいても、文化事象間の相互関係を理解するうえで、時空間情報を導入したアーカイブズ形成の必要性が明らかになってきたのである。

1２．文化資源アーカイブズに求められるもの(1) 文化資源アーカイブズへの時空間軸とテーマ軸の導入
文化資源アーカイブズに、時空間情報に加えて、環境破壊、農業、自然災害、など、その事象を説明あるいは関係する複数のテーマ・キーワードを付加すれば、テーマに基づく検索や解析も容易になるだろう。
この考えに基づけば、文化資源アーカイブズに集積された事象やそれらの相関関係は、図1 のように、時間軸、空間軸、テーマ軸から成る３次元空間上で表現でき、時間軸・テーマ
軸に沿ってそれらを射影すれば、年表のような表現が得られ、空間軸・テーマ軸に沿って射影すれば地理情報システム（GIS）のような表現が得られることになる。両表現を駆使すれば、事象間の相関関係の発見や理解が容易になる可能性がある。

図 1. 空間・時間・テーマの 3 軸の 3 次元空間における事象と事象間の相関関係(2) ミクロ－マクロ往還の仕組み：ズームイン・アウト機能の実現
様々な視点から総合的に情報を把握・分析できる文化資源アーカイブズには、それに不案
内な他分野の研究者にとってもアクセスしやすい仕組みが必要で、例えば、マクロな検索用
語や時間・空間範囲からアーカイブズにアクセスし、その性格を学習しつつデータを発掘していければ、他のデータとの突き合わせにより新たな発見につながる。そのためには、時間軸、空間軸、テーマ軸の各々について、ミクロ－マクロの様々なレベルを往還しつつ検索や表示のできることが望ましい。
具体的には、図 2 に示すように、空間軸において、地図のズームイン、アウトに連動した様々なレベルの地名での表示や検索、時間軸でも、その伸張に連動した様々なレベルでの時間表現、暦法の相違を吸収できる表示や検索の仕組みである。そのためには、地名辞書や暦の変換辞書、また、テーマ軸については意味のシソーラスやオントロジーの整備が必要となる。意味のオントロジー整備は難しい作業だが、ある研究者が作成したオントロジーを他分野の研究者も共有・追加できる仕組みを導入し、相補的にオントロジーを構築していく方法も考えられる。

2

図 2. 時空間を統合した文化資源アーカイブズにおけるミクロ－マクロ往還(3) フォーラム型のアーカイブズ整備
オントロジーの構築だけでなく、様々な解析の結果も、共有のアーカイブズへ還元される仕組みが望ましい。すなわち、従来のような特定分野毎に縦割り的に行われてきた知識の共有ではなく、収集データや解析の結果得られた仮説などを共通の土台にアップロードし、これに基づいて参加する研究者たちによるさらなる知見や知識の蓄積のできる、いわば「共創」のフォーラムであり、これにより、異分野間での協業や発見が促進されよう。さらには、こうして蓄積されていくアーカイブズを、対象となる現地の人々と共有することも視野に入れるべきであろう。これは、文化資源を現地に還元し現地の文化復元や復興に寄与する意義があるほか、現地との共同作業によって情報の精度が向上するメリットなどもある。
(4) 事象間の相関関係の記述
事象間に隠れた相関関係の発見が文化資源アーカイブズ形成の目的の一つならば、研究者たちが仮説として立てた相関関係を記述する仕組みを、アーカイブズの枠組みに導入できないか。例えば、シソーラスの中で関係語（RT）として掲げられる、行為と道具、行為と結果、行為と受動者、起源、因果関係、事物・行為と対抗者、などの相関関係を属性として持つリンクを、事象（群）の間に設定し保存する仕組みである。他の研究者がこれを参照でき
れば、仮説の検証や、それを土台とした深化など、フォーラムとしてのアーカイブズの可能性が広がる。同様なアイデアは、例えば慶応義塾大学で開発された「歴象データモデル」でも実現されて歴史研究や教育へ応用されており、文化のダイナミズム解明にも有効であろう。
(5) 「サイクロニクル」のアイデア
乾期や雨期を持つモンスーン地域などの事象には季節性を反映したものが多く、周期性の観点からの解析が必要となる場面が多い。これは、一方向で形成された年表を「折り畳み」、
周期的なカレンダーの集合として捉えることに相当する。筆者はこの考え方を、周期性を持った年表という意味で「サイクロニクル（Cychronicle = Cyclic Chronicle）」と名付けている。周期の契機となる事象をアーカイブズから抽出し、これに基づき年表を折り畳んで、「漁
撈暦」「農事暦」などを各周期毎に積み上げて比較することで、ある地域での長期の変化、あるいは地域間の差異、突発的事件の影響などを解析・発見することができるかも知れない。
3

これを展開すれば、ある条件でアーカイブズを検索する中から、事象群の中に隠された周期性を発見できる可能性もある。こうした操作の可能な解析ツールが望まれる。

図 3. サイクロニクルのアイデア
３．実現へ向けての取組み
時空間情報に着目した検索・表示システムに関しては、人間文化研究機構の研究資源共有化システム事業の中で、データベース横断検索ツールの一部としての時空間表示プラグインという形で開発が進行中である。また、筆者も参加する、京都大学東南アジア研究所・京都大学地域研究統合情報センターを核とする研究グループ（柴山守、原正一郎、関野樹ほか）
は、総合的なシステム開発に向けての検討と試行を進め、図 1 の空間展開面、時間展開面
それぞれに基づく、二種類の情報解析ツールの中で実現を図りつつある。
我々の研究グループでは、表示と解析の両場面で二種類の情報解析ツールが常に往還できるようなツール群の開発を狙っている。また、暦年変換表、地名辞書、など、時間・空間のミクロ－マクロ往還を支援するオントロジー整備も進めている。これについては、相田満（国文学研究資料館）や桶谷猪久夫（大阪国際大学）などが構築を進めている。
これらを組み込み様々な解析が可能な、文化資源アーカイブズのメタデータの構造についても検討を進めている。我々は、事象は全て開始時刻・終了時刻を持ったものとして扱う。
しかし、歴史文書などでは、複数の事象が一件のデータとして記述されている例が多く、これを個々の事象に分割していくのか、または、開始時刻・終了時刻についてもそれぞれに属性を付与して別の取扱が可能な形式に整形するのか、などの問題が残されている。同様に、書誌的な情報やモノ資料情報を見ても、出版年月、再版年月、製作年月と使用年月、製作地と使用地、など、意味の異なる複数の時空間値が附属しており、それらを表現できるデータ構造の検討も必要である。
以上の様々な課題を解決しつつ、この構想をできるだけ実現できるようなモデル構造を提示し、比較的容易に扱えるツール群を整備して行ければ、このアーカイブズは、人文社会系、自然科学系を含む多分野の研究者にとって、研究・分析のための共有資源、及び、研究成果の提示のための共有資源となり、それらを土台として、文理の枠組みを超えた様々な知見が得られ、さらには現地との共同のための資源となることが期待できるだろう。

4