データ利活用のためのジャパンサーチモデル

利活用しやすいデータを考える

• 見つかるデータ
  • 分かりやすい項目：領域を問わず適用でき、特別な知識なしに理解できる項目（キー）
  • 一貫した名前：同じものは同じ名前（値）。典拠による識別、もしくは典拠へのリンク
  • 無理のない記述：利用者のメンタルモデルに反しないシンプルな構造、膨張しない名前空間
• 活かせるデータ
  • 訴求効果がある：表示用画像、地図、年表などで視覚化しやすい項目
  • 探索と集約ができる：横断検索、キーワードや分類、正規化値など集約の手掛かり
  • 付加価値を生む：データの分析、組み合せや予想外の発見、第三者による情報追加
• 辿れるデータ
  • アクセス：より深い情報や現物につながる。その権利もわかる
  • ソースと来歴：データのもとになった情報や作成者、更新時
  • リンクするデータ：URIを辿れる、外部情報とつながる、誰もが同様に言及できる

ジャパンサーチ利活用スキーマ

• 共通記述情報とソース情報の分離
  • 見つけやすく活かしやすいデータを目指した共通記述
  • 辿れる＝コンテンツへのアクセス、ソースと来歴情報
• 扱いやすさと詳細さを両立させる複レイヤ構造
  • 相反する要件を両立させ無理のない記述とするために2つのレイヤを導入
  • Schema.org語彙によるシンプル記述のレイヤⅠ
  • 独自定義語彙を加えた構造化記述のレイヤⅡ
• 見つかるデータ、つながる値
  • 「いつ」「どこ」「だれ」「なに」を中心に値を正規化
  • 正規化値をNDLA、Wikidata、DBpedia(J)などのLODハブにリンク

共通記述情報とソース情報の分離

• 共通記述＋アクセス・ソース情報の構造
  • 分野を問わない、見つかる・活かせる項目による共通記述を設定
  • コンテンツの記述情報とは別に、アクセスのための情報を集約
  • ソースを共通記述から分離し、来歴の明示とともに元データ取得も可能に
    • 共通記述は無理に100%の変換を目指さず、共通化しないものはソースに任せる（導入句付きschema:descriptionでも）
  • 
  • Europeanaモデル（EDM）とも対応する共通記述とアクセス・ソース情報の分離
    • 共通記述及びソース情報のsourceDataがore:Proxy、アクセス情報がore:Aggregationに相当
    • 各ore:Proxyはそれぞれの視点でのメタデータを記述

共通記述と対になるProxyとしては、ソース情報よりそこからリンクしている元データでの記述というべきなので、「のsourceData」を追記し、図（クリックで表示する第2図）でのProxyの位置を変更

共通記述のレイヤⅠ：シンプル記述

• Schema.orgによる扱いやすい記述
  • 
  • 単純明快、基本的なパターンで検索できる

  • SELECT * WHERE { ?s schema:spatial place:三重 }

  • Schema.orgは世界的に広く利用され、特別な説明なしに通じる
  • RDFに親しみのないウェブ開発者も利用しやすい
    • SPARQLの知識が不要なREST API的EasySPARQLも提供（構造化記述と合わせたクエリをサーバー側で生成し、JSONで結果を返す）

共通記述のレイヤⅡ：構造化記述

• シンプル記述と対になる構造化ノード
  • 
  • 構造化記述プロパティ＋関係タイプ（作者、役者、制作地、出土地）
    • 元データの項目名（出土地）の詳細は関係タイプで記述＝データごとに新たなプロパティを定義する必要がなく、多様な領域記述に柔軟に対応できる
  • 変換元データの保存（住所→都道府県のような正規化で失われる情報）や処理に関する注記
  • さらに緯度経度、時代などの付加価値情報を追加できる
    • 伊勢国相可村発掘「脚付長頚坩」の場合：緯度経度とその判定に用いた辞書を注記

構造化記述：注釈あるいはプロパティグラフ

• シンプル記述の関係への説明的注釈
  • 
  • 構造化ノードはシンプル記述の説明もしくは注釈と考えることができる
  • プロパティグラフの関係プロパティと捉えてもよい
    • プロパティグラフはノード（円）、関係（矢印）がそれぞれプロパティ（キー：値の組；RDFでいうプロパティとは異なる）を持つことができる
    • 関係はタイプを持ち（つまりrelationType）、それがRDFでの矢印ラベル（＝述語）に相当する
  • RDF文のメタデータ記述拡張案RDF*（Turtle*）を使えば

  • <<jpsd:cobas-91058 schema:spatial place:三重>>
        jps:relationType   role:発見.出土 ;
        schema:description "出土地: 伊勢国相可村" .

見つかるデータ、つながる値

• データ値の正規化
  • 伊勢国相可村発掘 → place:三重
  • 「永仁元年十月三日」→ time:1293
  • "葛飾卍老人"、"北斉載斗改葛飾為一"、"画狂人北斎" → chname:葛飾北斎
• LODハブとのリンク

  • chname:葛飾北斎 owl:sameAs
        <http://id.ndl.go.jp/auth/entity/00270331> ,
        <http://ja.dbpedia.org/resource/葛飾北斎> ,
        <http://dbpedia.org/resource/Hokusai> ,
        <http://www.wikidata.org/entity/Q5586> ,
        <http://viaf.org/viaf/69033717> ,
        <http://collection.britishmuseum.org/id/person-institution/1820> ,
        ...

  • 同じLODハブにリンクしている（海外の）エンドポイントを統合クエリで横断検索できる
  • 漢字の入力が難しい利用者もWikidataのIDなどで検索できる

グラフを用いた検索

• プロパティパスによる階層検索
  • データソースによって異なるアイテム型（クラス）を、サブクラスとして関連付け
    • クラスは提供データの分類などに基づくため、同じものを指すのに「絵画」「版画」などばらつきがある
    • 版画--subClassOf-->絵画と定義しておき、両者を含めた検索
  • SPARQLのプロパティパスでサブクラスを含めて一括検索

  • ?type rdfs:subClassOf* type:絵画

• 同一関係の連鎖
  • ジャパンサーチ正規化名を中心に複数のLODハブURIをリンク
  • sameAsリンクでndla:00270331もwikidata:Q5586も一括して検索できる
    • 正規化名を値（目的語）とすれば1ステップで。NDLA、WikidataなどLODハブのURIを値とする場合は、正規化名を介して他のLODも調べるために2ステップ必要

  • ?s schema:creator/owl:sameAs? chname:葛飾北斎
    ?s schema:creator/owl:sameAs/owl:sameAs? <http://www.wikidata.org/entity/Q5586>

    • 後者はschema:creator/owl:sameAs*でも検索できる

ジャパンサーチのデータを利活用RDFで利用する

• データ分析
  • 正規化年や場所を頻度、分布分析の軸に
  • 分類やキーワードの出現数を調べるなど
  • 緯度経度や正規化年を利用した分析結果の視覚化
• 統合クエリ
  • 正規化名とLODハブURIとのリンクを利用した海外MLAとのつながり
  • SPARQLエンドポイントがなくてもAPIラッパである程度対応可能
  • 各エンドポイントごとにモデルが異なるため、それを理解したクエリ記述が必要
• 外部データと付加価値
  • 外部データとの組合せ（例：絵入源氏物語を青空文庫の与謝野源氏と並べる）
  • 注釈としての利用者タグやデータのキュレーション（例：相撲絵のタグ付け）
    • Web Annotationを用いて第三者のメモやコメントを結びつける
    • 専門家がデータを選んだりコメントを加えて提供すれば（ジャパンサーチ ギャラリーのデータ版）、分野に詳しくないユーザ向けの利活用出発点にも
  • 同一作品を利用者が同定＝アイテムレベルの正規化とLODリンク（未実現。識別子のハブへ）

利活用スキーマを共有フォーマットとして利用する

• オープンデータを利活用スキーマRDFに変換
  • 日本関係外国語図書の書誌情報（TSVから）
  • メトロポリタン美術館（CSVから）とクリーブランド美術館（API経由JSONから）
  • CSV/TSVからの簡易変換ツールを提供
  • ジャパンサーチRDFと共通のモデルで、統合検索も容易
• 汎用共通フォーマットとしての利活用スキーマ
  • 構造化プロパティ＋関係タイプで分野を問わない共通記述
    • 例：クリーブランド美術館RDFで被引用文献を表現したい → jps:relatedLinkの関係タイプをrole:関連.被引用として、新規プロパティを定義することなく記述
  • 基本がSchema.orgなので、その範囲で無理なく拡張できる
    • 例：メトロポリタン美術館の源氏物語展の出展作品を記述したい → schema:workFeaturedが（利活用スキーマでは明示的に採用していないが）使える
  • 最小限ながら共有可能な正規化辞書
    • ジャパンサーチ名鑑を使う、あるいはhttps://jpsearch.go.jp/entity/chname/名前空間の正規化名をクエリで調べるなど
    • 正規化辞書自身の公開は課題（各領域の典拠との照合など精度の向上が必要）

参照先

• 参照したリソース
  1. Europeana Data Model documentation
     <https://pro.europeana.eu/resources/standardization-tools/edm-documentation>
  2. EasySPARQL, SPARQLエンドポイント解説§4
     <https://jpsearch.go.jp/api/sparql-explain/#sec4>
  3. 構造化記述プロパティ, 利活用スキーマ概説§1.2
     <https://jpsearch.go.jp/api/introduction/#sec1-2>
  4. Graph database concepts, The Neo4j documentation
     <https://neo4j.com/docs/getting-started/current/graphdb-concepts/>
  5. Foundations of an Alternative Approach to Reification in RDF, by Olaf Hartig and Bryan Thompson, 2014-06-13, rev.2019-03-19
     <https://arxiv.org/abs/1406.3399>
  6. SPARQL 1.1 Federated Query, 2013-03-21, W3C Recommendation
     <https://www.w3.org/TR/sparql11-federated-query/>
  7. Property Paths, SPARQL 1.1 Query Language §9, 2013-03-21, W3C Recommendation
     <https://www.w3.org/TR/sparql11-query/#propertypaths>
  8. ジャパンサーチ非公式サポート, データ分析、統合クエリ、オープンデータの変換、ユーザタグなどの具体例
     <https://www.kanzaki.com/works/ld/jpsearch/>
  9. EasySPARQLで取得したデータを地図表示する, SPARQLエンドポイント解説§4.3
     <https://jpsearch.go.jp/api/sparql-explain/#sec4-3>
  10. Web Annotation Data Model, 2017-02-23, W3C Recommendation
      <https://www.w3.org/TR/annotation-model/>
  11. 連携するデータ：Linked Data Hub, 2016-10-11, メタデータのオープン化等検討WG第2回
      <https://www.kanzaki.com/works/2016/pub/1011dam.html>