# Japan Search RDF Schema - its design and application

抄録：ジャパンサーチ利活用スキーマは、多様な領域のデータを集約・提供する統合ポータルのための RDF モデルおよび語彙で ある。設計にあたっては、海外の統合ポータル事例も参照しつつ、利用者タスクの観点で扱いやすく、また連携元にもメリットが あることを目指した。その基本として、構造化ノードと単純プロパティを併記する二層記述、ソースとアクセス情報のグループ化 などを採用している。基本部分設計の検討ポイントを説明するとともに、時間・場所情報の表現および正規化の細部について、 SPARQL の機能を踏まえた工夫を紹介する。

Abstract: Japan Search RDF Schema is a data model and vocabulary for large scale portals that aggregate data from heterogeneous domains. It is designed to be effective in terms of user tasks as well as be beneficial to data providers, considering the previous practices in other countries. As the basis of the design, it introduces dual layered model where both structured nodes and simple properties contribute to the description. Also, it distinguishes information about data sources and item access from the metadata of item itself. This paper discusses the points of consideration for the basic design. Then it explains the details of the spatiotemporal information representation and data normalization, with the SPARQL functionalities in mind.

キーワード : ジャパンサーチ、RDF、SPARQL、Schema.org、正規化、マッピング

Keywords: Japan Search, RDF, SPARQL, Schema.org, Data normalization, Schema alignment
## 1. はじめに

ジャパンサーチは正式公開された 2020 年 8 月末の時点で 108 のデータベースと連携し、約 2100 万アイテムのメタデータを収集・公開している。そのうち利活用スキーマの RDF に変換されているのは 40 データベース、約 1800 万アイテムの約 8.9 億トリプルである。 RDF 化されているものに限ってみても、その内容は美術館 ・博物館、図書館、文書館から放送番組、科学写真、古典芸能上演史、歳時記と広範囲にわたる。多様な領域のデータを、連携元に過度な負担をかけずに集約しつつ、利用者にとっては使いやすく価値あるものとして提供するため、ジャパンサーチは連携フォーマットと利活用スキーマという 2 の形でデー 夕を扱う。本稿では後者の設計について、その骨格を検討するプロセスと、利用しやすさを目指したモデルの工夫を紹介する。

## 2. 課題と先行事例

## 2.1 統合ポータルの要件

統合ポータルには、

・多様な領域のデータを収集し、一貫した形で利用できるように提供する
・利用者を連携元に導き、またそのコンテンツの活用を促進するという役割がある。

データの集約・統合の基本手順は、（A）連携元で共通形式ヘマッピング後に集約、(B) 集約後に統合側で変換、(C)マッピングは行なわず集約したままの形をベースにする、に大きく分けて考えることができる。

統合側の立場で見ると、(A)はマッピング負担は小さいが、元項目名（場合によっては構造）情報が欠落したデータを扱うことになる。将来の拡張まで見込んだ共通形式の定義も容易ではない。（B）はデータセットごとにマッピングを考えるため、負荷が高くスケー ラビリティにも課題があるが、より精緻な統合結果を追求できるだう。（C)は元データの項目名、值ともに保持されるが、検索エンジンの全文検索と同様で、項目を絞った詳細な検索は難しい。これらの選択、あるいは組み合わせは、統合ポータル設計の前提条件を与える。

また利用者を提携元に導くためには、データの来歴を明確にし、コンテンツへのアクセスを支援しなければならない。自前のデータだけを扱う場合とは少々異なる視点が必要となる。

## 2.2 先行事例としての Europeana と DPLA

欧州の統合ポータルである Europeana は、データ交換規約 ${ }^{[1]}$ に基づき連携元が $\mathrm{EDM}^{[2]}$ に準拠したデー夕を用意することになっており、手順としては (A) 型である。EDM は、Dublin Coreの語彙に加え、データの提供者やデジタルオブジェクトに関する独自プロパティを定義する。またリソースの集合を記述する ORE ${ }^{[3]}$ の Aggregation を用いて、画像やウェブページなどの記述をアイテム自体のメタデータから分離している。

さらに EDM では、ORE の Proxyを利用し、アイテムに対する複数視点のメタデータを切り分けて記述できる。EuropeanaのRDFは、連携元データを 1 つの Proxyに、統合側がデータ正規化などで整備したメ夕データをもう1つの Proxyに割り当て、両者を合わせて提供する形になっている。

米国の統合ポータル DPLA は、サービスハブ (中間アグリゲータ）とコンテンツハブ（大規模機関）からメタデータを収集する。サービスハブは参加機関のメタデータを束ね、DPLAの求める標準形式にマッピングする役割を担う ${ }^{[4]}$ 。やはり (A) 型の手順だが、標準形式は Dublin Core、MODS、MARC XML などから選択できる。DPLA はこれらをさらに EDM 準拠のメ夕データに変換して提供しており、この点では(B)の要素も含む。

Europeana とは異なり、DPLAのRDF は Proxyを用いず、変換結果を直接アイテムのメタデータとして記述する[5]。ハブからのデータは JSON-LD の originalRecord フィールドに XML リテラルなどの形で記述されるが、 RDF グラフには含まれない。

## 2.3 ジャパンサーチの変換の流れ

ジャパンサーチは、連携元にデータのマッピングを求めず、データに共通ラベル情報（元項目名と汎用ラベルの関連付け）を加えたものを「連携フォーマット」 とし、Elasticsearchによる検索等の機能を提供する ${ }^{[6]}$ 。 （C）の手順に近いが、共通ラベル情報を連携元に付与してもらう点では (A)の要素、さらにそれを一定の形に整理する (B)の要素も部分的に持つ。

さらに連携フォーマットの JSON データを元に「利活用スキーマ」のRDFデータを生成し、SPARQL エンドポイントを通じて提供している。連携フォーマットから利活用スキーマへは、データセットごとのマッピング定義および值正規化の辞書を用意し、ツールで変換する。連携フォーマットは元データに手を加えていないので、手順としては(B)の統合側変換になる。 EDM の Proxy P Aggregation のような提携元との関

図1連携元データからジャパンサーチ利活用スキーマへの変換手順

係については、アイテムに関する標準化メタデータ記述（記述情報）と、来歴の情報（ソース情報）、取得のための情報（アクセス情報）を分けてグループ化する形を導入した。Europeana のモデルと同一ではないものの、デジタル化オブジェクトの集合体という意味でアクセス情報は Aggregation に、ポータル側で整理するメタデータという意味で記述情報は統合側 Proxy に対応させることができる。

ソース情報は、連携元からのデータに関する来歴情報に加え、連携フォーマットの JSON データへのリンクを持たせる形とした。この点は DPLAの originalRecord に近いとも言える。

## 3. 利活用スキーマの設計

## 3.1 スキーマ設計の準備

ジャパンサーチ利活用スキーマの検討は、知的財産推進計画 2017 で「メタデータを集約・共有化し、活用者による様々な形での利活用に資する」[7] とされたことを受けて始まった。スキーマの設計にあたっては、 まず連携元のデータから利用者向け記述に必要な要素を抽出し、仮想語彙による概念モデルを作ることにした。データを吟味する前に特定の使用語彙を決めると、 あとで矛盾や不足が生じたり、選んだ語彙にスキーマを合わせる方向に陥りがちで、モデル設計も制約を受けてしまうからである。

抽出した記述要素は、FRBR 最終報告で提示されている利用者の 4 タスク (発見、識別、選択、取得) ${ }^{[8]}$ を念頭に置いて共通項目に整理していく。前述のアクセス情報は、このうちの取得タスクに関するものと考えることができる。

利活用スキーマの案は 2017 年度に 3 回開催された有識者検討会に提示して討議し、そのフィードバックを反映しつつ改良していった[9]。

## 3.2 基本記述要素の抽出と役割モデル

記述要素の抽出・整理は、連携候補機関の 10 種類

のデータセットから項目名を列挙し、それをグループ化するところから出発した。役割が同等であるものは、元データの項目名が違っても同じ共通項目にまとめる。また共通化しにくく汎用性も高くないものは「記述」とし、ここにその他全般を収める形にした。最初の検討会では 25 の要素を共通項目として挙げ、後に 14 まで絞り达んでいる。

共通項目の数を絞るのは、主に発見タスクを容易にするためだが、逆に項目名による識別の情報を減らしてしまうことになる。そこでグループ化前の元項目名を、関係における役割として構造化する「役割モデル」 を導入することにした。

図2 元のデータを項目名（役割）と値に構造化する役割モデル

このモデルでは、元データ項目の違いは役割で分かるから、踏み达んだグループ化ができる。たとえば 「撮影地」も「出版地」も同じ “場所” プロパティにまとめ、元項目に関わらず「北海道に関するもの」を調べるといった使い方が可能だ。そこでこうした検索 （発見）が有用な関係として、「だれ」「どこ」「いつ」 を寄与者関係、場所関係、時間関係の大きな共通項目にまとめることになった。

さらに統合ポータルの場合はソースごとに項目値のばらつきが大きいので、的確な発見タスクのために、値は正規化 URI とした (正規化については後述)。一方「記述」にまとめた項目は、発見タクスよりも識別・選択タスクでの役割が中心になると考えられる。 これらはそのままリテラル値とし、値の先頭に導入句として元項目のラベルを加えることにした。

## 3.3 Schema.org と二層記述

概念モデルがほぼ固まったところで、具体的な語彙の選定に入る。利用時の煩雑さを避けるため、基本記述は最小限の語彙でカバーできることを重視し、既存語彙の再利用にはこだわらなかった。その結果、用語が豊富で記述も柔軟な Schema.orgを基本に、役割モデルなどは独自語彙を定義して用いることになった。

役割モデルは、「だれ」「どこ」「いつ」のプロパティを独自に定めるとともに、全て Schema.org のプロパティで並行記述する「二層記述」モデルに拡張した ${ }^{[10]}$ これにより、記述情報の值はすべて Schema.org の単純
プロパティ (SP) で検索が可能となり、分かりやすさ、使いやすさが増す。さらに構造化ノード側の記述 （SD）には元デー夕記述を schema:description で加え、正規化値と元データを原則としてセットで記述することにした。

図3単純プロパティと構造化記述を組み合わせた二層記述モデル

元データは当初、全体を一括してソース情報に保持する（Europeana のP Proxyに近い）形を想定していた。 しかしそれでは正規化値と元データとの対応関係が分かりにくく、識別・選択のための詳細表示も実装しにくい。元データを項目ごとにSD９ schema:description に移し、ソース情報には連携フォーマットの JSON へのリンクを記述することで、来歴情報としてのソース情報の位置づけも整理された。

二層記述モデルは、一つのプロパティに多重化されていた発見と識別・選択タスクを単純プロパティSP と構造化記述 SD に分けて整理したものだが、SDを SP に対する注釈（詳細記述）と捉えることもできる。 これはプロパティグラフ (グラフの弧も属性を持つ) をRDFで表現する方法の一種として、RDF*[11] などに通じるものと考えてもよいだろう。

さらに構造化ノードは、元データの保持にとどまらず、たとえば役者絵に描かれた人物の役柄を併記するなど、詳細情報記述のための拡張ポイントとして機能する。設計したモデルでは記述しきれない情報に出会っても、構造化ノードへのプロパティ追加によって、全体の構造に影響を与えることなく対応が可能であった。

## 4. スキーマの細部と SPARQL での利用 4.1 クラス階層と役割階層

ジャパンサーチ利活用スキーマでは、アイテム型 （クラス）を必須とした。型情報は記述内容を理解する（識別・選択）基本となる。また統合ポータルのように多様なソースのデータを扱う場合、「絵画」などの型による検索（発見）のためにも重要である。

アイテム型も連携元データの值に基づくため、同じ作品であっても、データセットによって「版画」絵画」 とばらつきが出てしまう。これらを「絵画」に正規化

するのも一案だが、利活用スキーマでは「版画」を「絵画」のサブクラスとし、それぞれの元デー夕記述を生かす方法をとった。

サブクラス関係は、SPARQL エンドポイントがRDFS 推論機能を備えていればそれを介して、そうでなくてもプロパティパス[12]を用いて発見タスクに生かすことができる。次のクエリは、歌川広重の作品で絵画もしくはそのサブクラスが型として付与されているものを検索する。

## SELECT ?s ?label WHERE\{

?s a/rdfs:subClassOf* type:絵画 ;

schema:creator chname:歌川広重；

rdfs:label ?label

\}

プロパティパスは、RDF グラフで節一弧一節一弧...節とつながる節（ノード）間のサブグラフを、その弧（プロパティ）を/で連結した「パス」で示すものである。このとき、パスを構成する弧は反復演算子 （?なら 0 もしくは 1 回、*なら 0 回以上、十なら 1 回以上、など）によって出現数を指定できる。

二層記述における jps:relationType の値も、役割を「制

の値は「制作.画」のような形で階層記述する方法を採用した。階層関係は skos:broaderを用いて定義する。 クラス階層と同様、プロパティパスを用いた検索ができる（役割は項目名保持が当初の目的であったが、「広重画」のような記述の役割部分も切り出すようにし、元項目名は schema:description の導入句に移した)。

## 4.2 時間関係の記述

時間関係の值は西暦年を単位に正規化し、単年だけでなく年範囲も含め時間リソースとしてURIを付与した。時間リソースは開始年と終了年を示すプロパティを付与する（データ型xxd:gYear のリテラルだが、一部の SPARQL エンジンで紀元前の値が正しく処理されないため、整数值によるプロパティも加えた)。一貫性のために、単年であっても開始年と終了年が同じである時間範囲として扱う。

世紀はその年範囲の時間リソースによって表現し、 その別名として世紀名を付与する (20世紀は time: 1901-2000で、そのラベルの一つに“20 世紀”を持つ)。時代も同様に開始年と終了年を持つ時間リソースとして定義するが、時代名を用いたURIを付与し、同等の年範囲 URI と skos:closeMatch で関連付けた。次のクエリは、この構造を利用して室町時代の範囲に含まれるアイテムを検索する。

## SELECT DISTINCT ?cho WHERE \{

?cho schema:temporal [

jps:start ?start;

jps:end ?end ].

FILTER(?start $>=$ ?st \& \& ?end $<=$ ?ed)

time:室町時代 jps:start ?st; jps:end ?ed .

\}

多くのスキーマで時間関係の記述にはリテラル値が用いられており、利用者もそれを期待する可能性がある。そのため、relationType が制作、公開.出版であるときは、それぞれ schema:dateCreated、schema:datePublished を年（月日）のリテラル值で併記した。

元データに年記述と時代名が併記されている場合は、年記述を正規化値に用い、時代名は構造化ノードに jps:era プロパティで記述する。

なお「江戸時代初期」のように細分される時代も、現在は「江戸時代」に集約している。初期、前期などは範囲があいまいで使用法も記述者によって違っており、年範囲にマッピングした正規化が難しいためである。

## 4.3 場所関係と存在物

場所関係の値は都道府県（海外の場合は国）を単位として正規化する。元データがより詳しい記述の場合、市郡レベルの地名が確実に判定できるデー夕は、構造化ノードに jps:region で「神奈川.横浜市」のように都道府県名とセットにしたURIを追記し、その値を都道府県 URI と schema:isPartOf で関連付けた。

歴史的地名や市町村合併によって地名が変化しているときは、対応辞書を用いて現在の都道府県名で正規化し、元データを schema:description に格納する。また 「撮影地：武道館」など、場所とその地にある存在物が区別されない值は、所在地によって正規化し、必要に応じて存在物を構造化ノードから rdfs:seeAlso で関連付けている。

地名の他に緯度経度（位置情報）が与えられる場合は、緯度経度から算出される Geohash ${ }^{[13]}$ の URI を位置情報の値とし、構造化ノードから schema:geo で結びつけた。これによって同じ場所でのイベント（撮影、採集など）の集中機能が得られる。またGeohash の「上位桁が同じであればその上位 Geohash が示す範囲内に含まれる」性質を利用して、一定範囲の位置情報をもつデータを簡単に検索できる（利活用スキーマでは、 jps:within プロパティを定義してこの包含関係を記述している)。緯度経度の個別プロパテイは、この Geohash URI を主語にして記述する。

正規化値の都道府県や市郡は、県庁所在地などの代

図4撮影場所とその緯度経度/Geohashを記述するグラフ

表点がその緯度経度（代表位置）として扱われることが多く、利活用スキーマではこれを schema:geo で記述している。個別地点の位置情報を持たないアイテムであっても、場所関係正規化値の代表位置情報を利用して地図上に表示させることが可能だ。代表位置と個別位置を区別するため、場所の空間的関係を表す語彙から取られた schema:geoCoveredByを用い、その值の Geohash の桁数に粒度を反映させる（3 标なら都道府県、4桁なら市郡レべルなど）ようにした。

「どこ」という切り口では、所蔵館をその対象と考えることもできる。しかし所蔵館はアイテム自身の本来的属性ではないため、記述情報とは別のアクセス情報に含め、そこに schema:itemLocation で所在地の正規化 URI を併記した。所蔵館の緯度経度などは、その schema:location をたどって取得できる。

## 4.4 正規化、LOD、国際化

利活用スキーマ RDFへの変換では、辞書に人物、文化施設、場所などの 3 万弱の正規化名を登録して URI 化を行なっている。正規化識別子は、数値による IDではなく、DBpediaなどと同様の自然言語を用いた。幅広い利活用のためには、URI だけで発見、識別などのタスクを実行できることが肝要と考えるからである (数値 ID の場合は rdfs:label などから表示名の別途取得が必要)。また辞書マッチできなかった値もURI として扱えるよう、正規化名の名前空間（chname:）とは別に非統制名の名前空間 (ncname: を用意して元データをそのまま URI 化しており、こちらとの整合性を取るという目的もあった。

同姓同名は “村上隆_(絵画)”のようなアイテム型連動の、あるいは “山本平左衛門(版元)”のような型と直接連動しない接尾辞を加えた URI で区別する。収録データベースの中には、たとえば全国書誌のように標目に典拠（Web NDLA）URIを用いているもの
がある。こうしたデー夕は正規化の必要はなく、その URIをそのまま寄与者関係などの値とするのが合理的た。ただ同一対象の定義済み正規化名がある場合に競合して発見タスクを損なわないよう、Web NDLAの URI と正規化名を owl:sameAsで関連付け、プロパティパスを用いてどちらの URIでも検索可能とした（頻出するものは変換時に対応表を用いてジャパンサーチ正規化名にマッピングしている)。

同様にして、正規化名はDBpedia、Wikidata、VIAF の URI とも owl:sameAsで結びつけた。これらの LOD ハブを介して、ジャパンサーチ正規化名は他の多くの典拠 URIともつながる。さらに、この値を用いて外部 SPARQL エンドポイントと統合クエリを行なう [14] など、ジャパンサーチの利活用範囲を広げるものとして期待される。

また正規化名を英語でも検索、表示できるよう、英語名（もしくはローマ字表記）を言語タグ enを持つリテラルとし、schema:nameの値とした。日本語名は同様に言語タグ jaで schema:name に記述するとともに、言語タグなしの値を rdfs:label で加える。schema:name は主として発見タスク、rdfs:label は識別タスクを担う位置づけである（英語の場合は schema:name が識別タスクに用いられることもある)。さらに人名などはカナ読みを言語タグ ja-Kanaで加えた。正規化名だけでなく、アイテム自身にも同じ形で日英の値を記述している。

## 5. おわりに

ジャパンサーチ利活用スキーマは、利用者タスクの観点で扱いやすく、また連携元にもメリットがあることを目指して、二層記述、ソースとアクセス情報のグループ化、正規化と LOD リンクなどを組み合わせた。細部の設計では、SPARQLの機能を生かせるように工夫した。

応用例の一つとして、2020 年 8 月に公開された Cultural Japan ${ }^{[15]}$ を挙げておこう。これは海外主要美術館や Europeana、DPLA などのポータル、さらに IIIF マニフェストから集めたデータを利活用スキーマの RDF に変換し、統合的な検索機能を提供するものである。 ジャパンサーチの SPARQL エンドポイントから取得したデータも一部加わっており、多彩なソースに柔軟に対応できる利活用スキーマの利点が生かされている。

課題としては、最初に記した基本手順(B)におけるスケーラビリティが挙げられる。現在は個々のマッピング定義、補助辞書作成に相当のエネルギーを費やしているが、連携対象が増えていくとこれには限界があるだろう。推奨標準形式を提示するという考え方もあ

るものの、実際には中間段階で単純化されすぎた項目からの情報復元に苦労もしている。さらに最も時間を要するのは正規化辞書の作成なので、典拠の利用と共有をすすめる方が先決というべきかもしれない。

## 註・参考文献

[1] Europeana Data Exchange Agreement https://pro.europeana.eu/page/the-data-exchange-agreement (accessed 2020-07-30)

[2] Europeana Data Model https://pro.europeana.eu/page/edm-documentation (accesed 2020-07-30)

[3] Open Archives Initiative. Object Reuse and Exchange. 2008. http://www.openarchives.org/ore/ (accessed 2020-07-30)

[4] DPLA. Becoming a Service Hub https://pro.dp.la/prospective-hubs/becoming-a-service-hub (accessed 2020-07-30)

[5] DPLA. Metadata Application Profile https://pro.dp.la/hubs/metadata-application-profile (accessed 2020-07-30)

[6] 川島隆徳. ジャパンサーチのシステム・アーキテクチャ. 2019, アカデミック・リソース・ガイド743号.

http://www.arg.ne.jp/node/9738 (参照 2020-07-30)

[7] 知的財産戦略本部. 知的財産推進計画2017, p.79.

https://www.kantei.go.jp/jp/singi/titeki2/kettei/chizaikeikaku 20170516.pdf (参照 2020-07-30)

[8] International Federation of Library Associations and Institutions.
Functional Requirements for Bibliographic Records, §2.2 Scope. 1997 (ammended 2009).

https://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf (accessed 2020-07-30)

[9] 国立国会図書館. 平成29年度「ジャパンサーチ（仮称）」利活用フォーマット検討成果物。

https://www.ndl.go.jp/jp/dlib/standards/pdf/jps_metadeliverables. pdf (参照日 2020-07-30)

[10] Daichi Machiya, Tomoko Okuda, Masahide Kanzaki. Japan Search RDF Schema: A Dual-Layered Approach to Describe Items from Heterogeneous Data Sources. 2019.

https://dcpapers.dublincore.org/pubs/article/view/4227 (accessed 2020-07-30)

[11] Olaf Hartig, Bryan Thompson. Foundations of an Alternative Approach to Reification in RDF. 2014 (rev.2019).

https://arxiv.org/abs/1406.3399

(accessed 2020-07-30)

[12] Steve Harris, Andy Seaborne (eds.). SPARQL 1.1 Query Language, §9 Property Paths. 2013. https://www.w3.org/TR/sparql11-query/ (accessed 2020-07-30)

[13] Geohash https://en.wikipedia.org/wiki/Geohash Geohashについては、発案者のGustavo Niemeyer自身が2008 年に開設したWikipediaのページを参照するようhttp:// geohash.org/でも示されている (参照 2020-07-30)

[14] 神崎正英. RDFとSPARQLによる多様なデータの活用. 情報の科学と技術. 2020, vol. 70, no. 8, pp.399-405.

[15] Cultural Japan

https://cultural.jp/ (accessed 2020-08-01)