準備:メタデータのポータルを記述するために

メタデータポータルの役割

  • 複数ソースのメタデータを集め一貫した形で提供
    • 図-arc-detail: (聖天町之法界坊 市川団蔵)
    • さまざまなソースの異なる記述を統合された形に集約する
    • ソースの違いを越えた検索ができ、かつ元のソースを確認できる
  • 利用者タスクから見た役割
    • 発見:さまざまな収集元のデータを一貫した形で検索できる
    • 識別:対象を確認する情報が、収集元でどう記述されていたかも含め正確に揃う
    • 選択:利用者の目的に照らして絞り込むための情報が得られる
    • 取得:元のデータ(ソース)にたどり着けるリンク。ライセンス、アクセス制限などが把握できる

メタデータポータルの記述とグラフ

  • ポータルが集約するデータは多様
    • 同じ分野であっても組織ごとに記述方法が異なる
    • 複数分野に跨がる場合はさらに多様化する
    • 形式(モデル)だけでなく値の記述もさまざま
  • 表形式モデル
    • CSVなどシンプルな形でも表現でき扱いやすい
    • 事前に項目定義(スキーマ)を決めるのが基本
    • 想定外の項目にあとから対応するのが難しい
      • リレーショナル構造で複雑な情報はある程度記述できる
    • 図2:
  • グラフ形式モデル
    • 節(ノード、円)と節の関係を矢印で表現
    • 節から新たな矢印を出して関係を伸ばしていける
    • 想定外の関係(項目)にも柔軟に対応できる。複雑な関係もOK
    • 図3:

RDFグラフの記述とURIによる識別

  • RDFトリプルとURI
    • 項目-値ペアに主語を加えたRDFトリプルで最小単位の情報を記述
    • 主語、述語(項目名)、目的語(項目値)にグローバルな識別子URIを用いる → ウェブ全体で通じる
      • 漢字などを直接用いることができる識別子はIRI(URIの上位互換)だが、ここではIRIと同じ意味でURIを用いる
    • 図4:
    • 関係(述語で示されるもの)をRDFのプロパティと呼ぶ
  • RDFリテラルとRDFグラフ
    • 数字やラベルそのものなど別途名前を与える必要がないものはリテラル(=そのまま)値とする
    • RDFトリプルの集合をRDFグラフと呼ぶ
    • 同じURIを持つノードは(誰が記述したものでも)連結できる
    • 図5:
    • 共通の識別子=URIを広く共有すれば、グラフが繋がり、付加価値が増す
    • 標準化されたクエリSPARQLを用いて同じ方法でどのRDFグラフでも検索できる

ジャパンサーチの2つのデータ

  • ジャパンサーチ(JPS)連携フォーマットと利活用スキーマ
    • 連携フォーマット:提供機関のメタデータをほぼそのまま受け入れ
      • 共通化可能な十数項目は共通項目ラベルにマッピング
      • JSONに変換してジャパンサーチの通常利用検索機能を提供
    • 利活用スキーマ :連携フォーマットのJSONを元にRDF化
      • 共通項目ラベル定義に加えデータセットごとの変換定義でマッピング
      • 共通辞書、データセット用補助辞書を用意し、値を可能な範囲で正規化
    • 図6:

発見・識別・選択のデータ設計

発見タスクのための情報

  • 多様な項目と利用者の発見タスク
    • ポータルはさまざまな要素(項目)から成る情報を収集する
    • 利用者はできるだけシンプルに発見タスクを実現したい
    • 情報記述と利用者の(領域についての)メンタルモデルが異なると混乱する
      • 出版物について、利用者は出版者などを直接のプロパティと想定しているのに、情報記述では「出版イベント」に出版者、出版日、出版地がまとめられている、など
  • 名前とラベル
    • 作品のタイトルや人物の名前などは検索、結果表示ともに基本となる要素
    • できるだけシンプルに、対象の種別を問わず同じプロパティ(項目)で
  • 「だれ」「いつ」「どこ」「なに」
    • 5W1Hはほぼ誰にでも通じる一種のメンタルモデル
    • 多様な対象の記述項目もこのカテゴリで集約できるものが多い
    • JPS連携フォーマットの共通項目ラベルも「人物/団体」「時間/時代」「場所」など(利活用スキーマは後述)
    • 図8: (連携フォーマット=通常検索の詳細画面)

値の正規化とURI

  • 発見タスクと値の揺れ
    • (ARC浮世絵ポータルの記述)
    • 機関ごとに項目名も値も異なる。発見タスクを容易にするためには一貫性が重要
  • 値の共通URI化とプロパティ
    • ARCは浮世絵分野のポータルとして独自の正規化
    • ジャパンサーチはより広い分野のポータルとして(ARC提供の値も改めて)正規化&共通識別子=URI付与
    • 人物、団体などを中心に約3.25万の名前辞書を作成し、統合典拠とする
      • 連携フォーマットのデータをRDF化する際に、データセットごとの規則を設定してマッピング
      • 豊国〈1〉、初代豊国、一陽斎など別号や改名も歌川豊国に統一
    • 使いやすいシンプルなプロパティとしてschema:creatorを採用
      • 出版者はschema:publisherなど、シンプルな記述にはschema.orgの語彙を利用

識別子を共有するハブ

  • さまざまな識別子
  • 識別子のハブとなるWikidata
    • Wikipediaの多言語リンクとして2012年に発足
    • Wikipediaとは異なり、Qで始まるID型の識別子。歌川豊国ならQ950316
    • 8000強の外部識別子が登録されており、Wikidataを介して相互にリンクすることが可能
      • 各外部識別子はそれぞれPで始まる固有のプロパティで関連付けられる
    • 直接WikidataのURIを用いなくても、リンクを辿ってつながることで間接的な識別子共有に
    • 図12:

識別・選択タスクのための情報

  • 正規化前の元データの記述
    • 検索結果を識別し、選択するためには細かな違いが重要になることがある
    • 正規化名だけでなく、資料に記されていた名前は何であったか
  • 関連する複数項目
    • 並列の別項目で記述される情報がしばしば関連している(作者名なら落款、読み、英語表記など)
    • 画、絵師、摺、筆などの役割が「豊国画」のように名前と同じ項目にまとめられることもある
  • RDFの空白ノードと構造化
    • RDFにはURIで識別・参照する通常ノードのほかにURIを持たない(グラフ内でのみ識別する)空白ノードがある
    • 空白ノードを節点としてひとまとまりの情報を構造化できる
    • 図14:

ジャパンサーチ利活用スキーマの詳細記述モデル

  • ジャパンサーチの構造化記述
    • 「いつ」「どこ」「だれ」について、空白ノードを用いた構造化記述を導入
    • 正規化値URIをjps:valueで、加えてjps:relationTypeでその役割を示すURI
      • 同じ役割を持つ「いつ」「どこ」と対応付けられる。例えばrole:公開.出版で出版者、出版日、出版地(出版イベント)が対応
      • 役割のURIは責任表示などの役割文字も加味して階層化。「制作」「公開」など大きなくくりで集約可能
    • さらに元データや関連情報の値もschema:descriptionで構造化空白ノードに保持する
      • 関連情報の項目名は導入句として保持する
  • 寄与者(だれ)とその役割のモデル
    • アイテム主語とこれらを構造化した空白ノードはjps:agentialで関連付け
    • 英語表記、読みなどは作者についての情報なので、空白ノードではなく正規化名ノードに記述
    • さらに正規化URI名はWikidataなど識別子ハブに関連付け、広いつながりと間接的な識別子共有を可能にする
    • 図-jps-agential-chname:

使いやすさ:発見タスクとのバランス

  • 利用者は発見のための情報を...
    • シンプルに考える。対象アイテムの直接のプロパティ値であるというメンタルモデル
    • 構造化記述の場合、モデルを知らないと発見タスク(人物名/URIでの検索)がうまくできないかもしれない
  • ジャパンサーチの二層モデル
    • 使いやすさのために、schema:creatorを用いて正規化値URIをその目的語とする(単純プロパティ)
    • 単純プロパティと構造化記述を併記し、いずれからも正規化値URIにつながるようにする
    • 図16:

さらに発見のための情報:「いつ」「どこ」「なに」

  • 時間、場所の正規化
    • 時間、場所も寄与者と同じ二層モデルで記述
    • 時間は年単位、場所は都道府県単位に正規化(=URIを付与)し、関連するLODなどとリンク
    • さらに場所の構造化ノードからは劇場の正規化名URI(できなければncname:)をrdfs:seeAlsoで関連付け
  • 主題やキーワード
    • アイテムの内容から調べる手がかりとなるものをschema:aboutに抽出。これもURI
    • 役者絵での描かれた役者など、人物自体が主題であるときは単純プロパティをcreatorやcontributorではなくaboutとしている

追加のマッピング

  • グループ化と上位/全体・部分関係
    • コレクショングループなど複数のアイテムをグループ化する識別子
    • 検索URIをschema:isPartOfの値として記述。たとえば10以上のアイテムを含むコレクショングループを検索できる
      • 検索パラーメータのURLは共有しやすいURIではないかも知れないが、識別子として機能する
  • 主として識別・選択に資する情報
    • さまざまな領域の項目名をすべて適切なプロパティにマッピングすることは難しい
    • 発見より識別・選択タスクを重視してschema:descriptionにまとめ、元の項目名を導入句とする
    • これらは値もさまざまなので、正規化/URI化はせずリテラル値
      • ラベルと合わせてテキスト検索(発見タスク)の対象にも。ただしRDFの場合テキスト検索はあまり効率的ではない
      • 判種などはキーワード化(URI化)を考えても良いかもしれない

取得タスクのデータ設計

保有者メタデータと共通化メタデータ

  • ポータルのアイテム記述を構成するリソース
    • 文化財実体(CHO):浮世絵の現物などの実体リソース
    • D(デジタル化)オブジェクト:CHOの画像、動画やそれを閲覧するウェブページなど
    • 保有者メタデータ:CHOの保有・管理者(ポータルの収集元)が作成したメタデータ
    • 共通化メタデータ:ポータルが保有者メタデータを収集して標準化したメタデータ
  • ヨーロピアナのデータモデル(ORE/EDM)
    • ORE:集約したリソースを表すAggregation、また特定のコンテクストにおける集約を表すProxyなどの概念を導入
    • EDM:OREをベースに、対象となる文化財実体をProvidedCHOとし、保有者(収集元)とヨーロピアナ(ポータル)のメタデータをそれぞれのProxyに記述して区別するモデル
    • 図23:

ジャパンサーチのソース、アクセス情報

  • アイテムの記述情報とソース、アクセス情報
    • 記述情報:ジャパンサーチで正規化などを加えたメタデータを記述=ヨーロピアナのProxyに近い
    • アクセス情報:収集元のDオブジェクトへのリンクなどをまとめる=収集元のAggregationに近い
      • 取得タスクのための情報は主にここに集められる
    • ソース情報:記述情報を生成する元となった情報源(つなぎ役など)へのリンク
      • 収集元のメタデータは連携フォーマットのJSON#5で保持し、jps:sourceDataプロパティでリンクする
      • 元データの各項目は、使いやすさのために記述情報の構造化ノードに配分
    • 図24:

取得タスクのための情報 (1) 提供者

  • 所蔵館、所有者についての情報
    • provider:Dリソースへのアクセス提供者
      • 通常は文化財実体を所蔵・公開する機関
      • 正規化辞書に登録してURI化。Wikidataなどにリンクするとともに、所在地、緯度経度などの情報も持つ
    • contentId:所蔵館でのID、請求記号など(グローバルな識別子ではないのでリテラル値)
    • contentHolder:文化財実体の所有者(寄託などの場合providerと異なることがある)

取得タスクのための情報 (2) リンク

取得タスクのための情報 (3) ライセンス

  • ライセンスと権利情報
    • 利活用のためにはライセンス/権利情報がとても重要
    • license:画像などの利用ライセンスURI(Creative Commonsなど)=アプリケーションが判断できる
    • contentRights:文(リテラル)で示される権利情報
    • usageInfo:利用規約などの文章を表示するウェブページURL
  • ライセンスの定義と関連付け
    • ジャパンサーチはCreative CommonsもしくはRights Statementsによるライセンス表記を推奨
    • 推奨ライセンスが示されず提供者固有の利用規約などがある場合:
      • ライセンスをothersとして利用規約ページをusageInfoに記述。もしくは
      • 利用規約ページURLをライセンスURIとみなして定義を作成し、推奨ライセンスと関連付け
      • 標準ライセンスでなくてもアプリケーションの判断が可能
    • ライセンス定義から商用利用可、教育利用のみなどのカテゴリ検索クエリを組み立てることができる

実体の切り分けと識別:芝居の場合

役者絵の役者と役柄

  • 配役の2つの要素
    • 配役の情報には、芝居での役柄とそれを演じる役者の2つの要素=実体がある
    • 「聖天町之法界坊〈4〉市川 団蔵」は前半が役柄、後半が役者
  • ジャパンサーチでの構造化記述
    • 図33:
    • 構造化ノードの主たる値(jps:value)は役者
    • 役柄は正規化=URI付与を試み(できなければncname:)、schema:characterNameとする
    • 場所の構造化ノードが劇場(森田座)とその所在地(江戸=東京)の2つの要素を持つのと同様

芝居番付に含まれる実体

  • 番付ポータルのアイテム
  • 芝居公演
    • 番付で案内する一つの興行=イベント
    • メタデータは公演の日時、場所、興行主、出演者など
  • 演目(上演作品)
    • 興行で上演される(複数の)作品
      • JPS利活用スキーマでは公演をイベントの、上演をパフォーマンスの下位クラスと位置づけて区別している
    • メタデータはそれぞれの作者、出版日、初演年など

芝居番付の実体を記述するモデル

  • 番付、公演、作品
    • 番付 の内容(schema:about)は公演イベント
      • 公演の識別子は用意されていないので、年、都市および(JPSでの)タイトル+月日+劇場名のハッシュで公演URI を生成する
      • 同じ公演の番付が複数あるとき、公演でまとめることができる
    • 公演で上演する作品(schema:workPerformed)→ URIを付与
      • これも番付に記載されているので、その内容(about)としても関連付ける
    • さらにそれぞれの外題(上演作品)の記載は、番付=刷り物の一部を構成する(schema:hasPart)
      • 場幕名のような補足情報はhasPartの目的語ノードを構造化してschema:descriptionで記述
      • 作品(の一幕)を上演したPerformanceとしてモデル化することもできる
    • 図37:

役者絵と上演

  • ARC浮世絵ポータルの上演情報
    • 役者絵のデータには描かれた舞台の上演(公演)情報も記述されている
    • 浮世絵の主題というわけではないので、番付ポータルRDFとは違い公演を独立実体化してはいない
      • 時間、場所ともに浮世絵アイテムのプロパティとして記述
      • jps:relationTypeをrole:内容.上演とする。出版年月の場合はrole:公開.出版
      • 興行名=公演のタイトルも直接の画題ではないので参考としてschema:description
    • 外題は役者が演じている内容なので、番付ポータルと同じ辞書を用いて正規化・URI付与し、schema:aboutの値に
  • ARC番付ポータルとの接点
    • 上演情報を利用して役者絵が描かれた芝居の番付を「発見」できないか?
    • 共通する要素は上演年月日、場所(劇場)、外題
      • 役者については、番付ポータルにも「役者/Staff」があるが、あまり積極的に収録されていない??
    • 番付ポータルの(JPSでの)タイトルは複数外題の連結であるのに対し、浮世絵ポータルの興行名は単一演目
    • 前者の公演URIと同じものを生成できない → クエリを工夫する →
      • 同じ公演URIが生成できればグラフが直接つながるので話は簡単

役者絵に対応する番付を見つける

  • 共通要素を用いてSPARQLクエリを組み立てる
    • 番付ポータル&浮世絵ポータルのアイテムをそれぞれ?s1、?s2と設定
    • 両者の上演年(?when)、劇場(?theater)、外題(?work)を同じ変数として一致するものを探す
      • 劇場名はユニーク(同名劇場が別の都市にはない)と仮定
      • 厳密は上演年だけでなく月日まで比較すべきだが、同一年に同一外題を異なる月に上演しないと仮定
      • マッチ数を絞るために上演年(?when)を一つの時代(time:寛政)に限定する
    • SELECT ?s1 ?label1 ?s2 ?label2 ?theater ?when ?work ?image WHERE {
 ?s1 rdfs:label ?label1 ; schema:temporal ?when ;
 jps:spatial/rdfs:seeAlso ?theater ;
 schema:about ?work ; # schema:image ?img ;
 jps:sourceInfo/schema:provider chname:ARC番付ポータル .
 ?s2 rdfs:label ?label2 ; schema:temporal ?when ;
 jps:spatial/rdfs:seeAlso ?theater ;
 schema:about ?work ; schema:image ?image ;
 jps:sourceInfo/schema:provider chname:ARC浮世絵ポータル .
 ?when schema:isPartOf time:寛政 } ORDER BY ?s1 ?label2
  • 番付と役者絵の対応の発見

URIの共有とデータ利活用

ジャパンサーチからCultural Japanへ

同じ浮世絵作品のアイテムを発見する

  • 浮世絵の作品典拠URI
    • たとえば北斎の富嶽三十六景の赤富士(凱風快晴)はCJだけでも30点以上
    • 「凱風快晴」で検索してもかなりのアイテムが発見できるが、日本語でないタイトルや表記の揺れなどがある
    • 同じ作品を集約するためにはまず作品の典拠URIが必要。しかし赤富士(=凱風快晴)の典拠URIとは?
    • 識別子のハブWikidata#9はどうか? 浮世絵を網羅はしていないが富嶽三十六景は全て登録されている!
  • Wikidataを利用した浮世絵アイテムの集約
    • 「凱風快晴」の各アイテムをWikidataの「凱風快晴」(Q3565037)にschema:exampleOfWorkで関連付け
    • さらにそれを同「富嶽三十六景」(Q227494)とschema:isPartOfで結ぶ
    • 図40:
    • CJに収録されている「凱風快晴」各アイテムを一括で発見できる
  • 課題
    • CJ収録アイテムの中から富嶽三十六景の版画を探してそれぞれ適切なWikidataに関連付けるのは手間のかかる作業
      • 辞書を用意してある程度効率化はできるが、完全ではなく漏れもあり得る(AI活用?)
      • 新データセットの追加などに対応してマッピングを自動追加するシステムがない
    • あらゆる作品がWikidataに登録されているわけではない
      • たとえば広重の東海道五十三次シリーズの集約用にはCJ独自の作品URIを作成している
      • 浮世絵ポータルによる典拠URIの提供?

浮世絵と場所情報

  • 所蔵館の位置
  • 作品内容の位置
    • Wikidataの富嶽三十六景各アイテムの多くはプロパティP7108(展望場所)を持ち、そこから緯度経度が得られる
      • 得られない作品については適宜通説などを調べて緯度経度を推定
    • CJのRDFストアに登録した作品(Wikidata URI)に、schema:contentLocationとして位置情報を記述
    • SPARQLクエリで情報取得 → 地図インターフェイスを用いて富嶽三十六景の収録アイテムを紹介
    • 図-fugaku-map:
    • 同様に作品を集約し緯度経度で地図表示する広重の東海道五十三次

スキーマの拡張:展覧会情報の記述

  • 展覧会と出品リストのモデル
    • メトロポリタン美術館、クリーブランド美術館などは過去の展覧会ページも充実
    • 日本関連展覧会の出品リストをCJ収録のRDFで利用できないか
    • JPS利活用スキーマにtype:展覧会あり。このインスタンスを展覧会アイテムとし、開催期間、会場は記述できる
    • 出品リストの各作品に対応するCJアイテムURIをschema:workFeaturedで展覧会アイテムに関連付け → サムネイルなどを表示できる
  • グループ化と順序の表現
    • 多くの展覧会は章立て(出品作品のグループ化)があり、出品リストの番号もある
    • 章をフラグメント識別子で表現して展覧会アイテムからschema:hasPartで関連付け。さらにそこからschema:itemListElementを用いてアイテムと順序を構造化
      • 図では一部略しているが展覧会アイテムとCJアイテムはさらにschema:workFeaturedで結ばれる
    • 図42:
    • このモデルのRDFから作成したカルチュラルジャパン展覧会アーカイブや、章立てを部屋に配分したセルフミュージアムのような応用

サービスを越えた連携

  • 複数のRDFストアを一括検索
    • SPARQLの統合クエリを用いると、SERVICE句で外部のエンドポイントを照会できる 
    • SELECT ?s ?label ?labele ?image WHERE {
 BIND("川瀬巴水" as ?who)
 {SERVICE <https://query.wikidata.org/sparql> {
 #Wikidataへのクエリ
 ?s <http://www.wikidata.org/prop/direct/P170>/<http://www.wikidata.org/prop/direct/P6698> ?who ;
 rdfs:label ?labele FILTER (lang(?labele)="en")
 OPTIONAL{ ?s rdfs:label ?label FILTER(lang(?label)="ja")}
 OPTIONAL{ ?s <http://www.wikidata.org/prop/direct/P18> ?image }}
 } UNION {
 #ジャパンサーチ自身へのクエリ
 ?s schema:creator/rdfs:label ?who ;
 rdfs:label ?label ; schema:image ?image ;
 jps:sourceInfo/schema:provider chname:ARC浮世絵ポータル
 OPTIONAL{ ?s schema:name ?labele FILTER(lang(?labele)="en")}
 }
}
      • SERVICEを用いたWkikidataへのクエリとジャパンサーチ自身へのクエリをUNIONで組み合わせる
      • WikidataのP170、P18、P6689はそれぞれ作者、画像、ジャパンサーチ名称識別子のプロパティ
    • RDFグラフと(間接)共有識別子を用いることで、ポータルの収集対象ではないDBともある程度の連携が可能
    • やや複雑で制約もあるが、マッピング設計などなしにフットワーク軽く使える

まとめ

  • グラフモデルによる柔軟なメタデータ記述
    • ポータルが扱う多様なデータを柔軟に記述できる
    • 複雑な構造を記述でき、想定外の項目(関係)にも対応できる
    • URIによる識別を組み込んだRDFグラフは広く共有可能。標準クエリ言語SPARQLも使える
  • 利用者タスクを念頭に置いたデータ設計
    • 発見タスクのためにはシンプルで正規化された記述が有効
    • 識別・選択タスクのためには元データも含めた詳細な情報がほしい
    • 取得タスクはアクセスのための情報を集約すると扱いやすい
    • ジャパンサーチ利活用スキーマは二層モデル+ソース/アクセス情報分離でこれらに対応
  • 実体の識別と利活用
    • ポータルのメタデータにはさまざまなレベルの実体が含まれる場合がある
    • 実体を適切に切り分け、識別子を与えると新たなつながりや発見が生まれる
    • そのURI(特に作品など)を共有すればメリットが大きい。識別子のハブとしてのWikidata
    • さまざまなデータベースを整備しているARCから共有可能な識別子が提供されることに期待!

参照先