ジャパンサーチ利活用スキーマの設計と応用
- ジャパンサーチ メタデータの構築
- 分析と概念モデル:FY2017
- マッピング開発からベータ版公開:FY2018
- 連携フォーマットと利活用スキーマ
- 利活用スキーマへの変換の流れ
- 利活用スキーマのインターフェイス
- 利活用スキーマの設計
- 利用者タスクによるメタデータ分析
- 共通記述情報とソース情報の分離
- 共通記述情報の基本項目
- 名称とラベル
- 複レイヤ構造と語彙の選定
- レイヤⅠ:シンプル記述
- レイヤⅡ:構造化記述
- 構造化記述:注釈あるいはプロパティグラフ
- 正規化値とLOD
- 汎用共通項目
- アクセス情報とメディアオブジェクト
- 利活用スキーマRDFの探索と応用
- いつ:時間正規化と範囲検索
- どこ:位置情報の利用
- なに:グラフによる探索
- さらにグラフ探索
- だれ:正規化と統合クエリ
- ジャパンサーチ内の新しい関係を見出す
- 注釈によるユーザ発信情報
- データとしての利活用スキーマRDF
- スキーマ(モデル)自身の活用
- 課題と展望
- ベータ版公開から5ヶ月
- 正規化の課題
- クラス定義のあり方
- 活用できるポータルへ
- 参照先
ジャパンサーチ メタデータの構築
分析と概念モデル:FY2017
- 多様なソースを集約するメタデータ語彙とは
- 博物館、公文書館、人文学、標本、放送番組など20近くのデータを分析
- DC-NDLを拡張する?→図書館リソースと同じ精度で他領域まで拡張するのは困難
- 各分野の既存語彙を集める?→対応範囲が広すぎ複雑。つまみ食いで中途半端になりそう
- まず語彙を特定しない概念モデルから
- サンプルデータを分析し、記述に必要な要素を整理
- 記述語彙を特定せず、まず要素を表現するためのモデルを考える
- 提供しやすい×利用しやすい
- 提供者に負担をかけない=事前マッピングなどを求めない
- 元データや現物へのアクセスを導く=提供者、利用者双方にメリット
マッピング開発からベータ版公開:FY2018
- 語彙を含めたスキーマの策定
- 複数語彙を候補に、概念モデルを記述できるかどうか検討
- できれば語彙は少数に(膨大な名前空間宣言は不便)
- Schema.org+独自語彙の組合せ
- マッピングツール開発+辞書整備
- 概念モデル段階(前年度)で仮語彙によるテストマッピングを反復
- サンプルデータを実際に変換してみることで、概念モデルの不足を修正
- 語彙&モデル策定後、実データ(大きいデータセットは数百万件レベル)変換に対応できるマッピングツール
- 正規化のための辞書整備が大仕事
- ベータ版公開
- 2019年2月27日ベータ版公開
- RDFストア(SPARQLエンドポイント)も同時提供。約7億トリプルのRDF
連携フォーマットと利活用スキーマ
- 2つのメタデータフォーマット
- 各機関が持っているメタデータ項目をそのままの形で用いる「連携フォーマット」
- 多種多様なメタデータを一貫した形で利活用するための「利活用スキーマ」
- 連携フォーマット
- 提供機関のデータをほぼそのままの形で受け入れ
- 名称/タイトル、英語名、URLなどの共通化可能な十数項目は、共通項目ラベルにマッピングする(ラベル解析定義)
- JSONに変換してelasticsearchに格納され、ジャパンサーチの通常利用検索機能を提供
- 利活用スキーマ
- 連携フォーマットのJSONデータとラベル解析定義を元に個別マッピングを定義し、RDFを生成
- 利活用スキーマのモデルに変換するとともに、値を可能な範囲で正規化する
利活用スキーマへの変換の流れ
- 利活用スキーマRDF生成のワークフロー
- 連携フォーマットの共通項目に対応する共通変換定義と、データセットごとの個別変換定義を組合せ、マッピング定義を準備
- マッピングツールは辞書を用いて値を正規化する正規化モジュールを呼び出しながら、各アイテムをRDFに変換
利活用スキーマのインターフェイス
- Linked Data
- ジャパンサーチの通常利用URIの
item
をdata
に置き換えると利活用スキーマRDFを取得できる - 内容折衝(Acceptヘッダ)により、ブラウザからの利用には下記のSnorql画面に転送、アプリケーションには指定のフォーマットでRDF
- ジャパンサーチの通常利用URIの
- SPARQLエンドポイント
- https://jpsearch.go.jp/rdf/sparql/
- RDFを格納するVirtuosoに直接リクエストするエンドポイント
- EasySPARQLとSnorql
- https://jpsearch.go.jp/rdf/sparql/easy/
- ブラウザでアクセスすると、検索結果やRDFグラフを読みやすく表示するSnorql画面
- 簡単なREST風パラメータで、RDFを意識せずに利用するEasySPARQL
- 例:https://jpsearch.go.jp/rdf/sparql/easy/?who=葛飾北斎
- アプリケーションにはJSONなどでクエリ結果フォーマットに従ったデータを返す
利活用スキーマの設計
利用者タスクによるメタデータ分析
- 利用者の4タスクの観点でサンプルデータの項目を分析
- Find:発見=タイトル、キーワードなどによる検索(標目、アクセスポイント)
- Identify:識別=示されている対象が何なのか、求めている(既知の)コンテンツかどうか判断できる情報
- Select:選択=(検索結果などの)選択肢のうち、対象が求めている(未知の)コンテンツかどうかを判断できる情報。識別より広い意味での記述
- Obtain:取得=示されている(選択した)対象を取得する手段(の情報)の提供
- タスク分析に基づく概念モデルの基本構造
- いつ、どこで、だれが、何を(→特に発見タスク)を基本にシンプルな項目設定
- 単純プロパティと構造的プロパティの併置(識別、選択タスク)
- 提供=アクセス情報の整理と集約(取得タスク)
- アプリケーションによる活用も踏まえた情報形態(Linked Data)
共通記述情報とソース情報の分離
- 共通記述+アクセス・ソース情報の構造
- 分野を問わない、発見~選択タスクに重要な共通記述を設定
- 取得タスクのための、アクセス情報を集約
- ソースを共通記述から分離し、来歴の明示とともに元データ取得も可能に
- 共通記述は無理に100%の変換を目指さず、共通化しないものはソースに任せる(導入句付き
schema:description
でも)
- 共通記述は無理に100%の変換を目指さず、共通化しないものはソースに任せる(導入句付き
- Europeanaモデル(EDM)とも対応する共通記述とアクセス・ソース情報の分離
- 共通記述及びソースデータ(sourceData)が
ore:Proxy
、アクセス情報がore:Aggregation
に相当 - 各
ore:Proxy
はそれぞれの視点でのメタデータを記述
- 共通記述及びソースデータ(sourceData)が
共通記述情報の基本項目
- 概念モデル設計における共通記述の基本項目とタスク
基本項目 内容 発見 識別 選択 タイプ アイテムの基本区分(図書、絵画、標本など) ○ - ○ 名称 タイトル、別名、英語名、読みなどの名前 ◎ ◎ ○ エージェント 関連する人/組織(作者、発行者、記述対象など) ◎ ◎ ○ 場所関係 場所に関する情報(制作地、発掘地、内容の舞台など) ○ ○ ◎ 時間関係 時間に関する情報(制作年、対象時期など) ○ ◎ ◎ 主題など 統制された主題・分類/自由キーワード ○ △ ○ 識別子,言語 ISBNなどの識別子、アイテムの記述言語 △ ◎ ◎ 画像 アイテムの特徴を確認するためのサムネイル画像 - ◎ ◎ 上位アイテム 現在のアイテムがその一部である上位アイテム(資料階層) ○ ○ ○ (汎用記述) 個別項目に収録できない情報 △ ○ ◎ - さらに提供情報(取得タスク)とソース情報にリンクする
名称とラベル
- 複数の名称の扱い
- 名称には別名、読み、英文名など複数があり得る
- それぞれの項目名を分けると、識別には有利だが発見には不便になる
- 同じ項目(プロパティ)を用い、言語タグで区別する
- 主タイトルと別名は、次のラベルとの一致で区別する
- シリーズタイトルなどは、名称ではなく上位アイテムとして実体化する
- アイテムの代表名称としてのラベル
- 複数の名称を同じプロパティにした場合、検索結果セットが増えてしまう
- SPARQLで
{?s :名称 ?name.}
と検索すると、同じアイテム(?s
)に名称の数だけ結果セットができる - 1アイテムにつき1つの結果セットにするには、検索の工夫が必要
{?s :名称 ?name . FILTER(lang(?name) = "ja")}
- SPARQLで
- 言語タグの有無が検索に影響するため、事前知識がないと混乱する
- 言語タグを持つ
"脚付長頚坩"@ja
は、{?s :名称 "脚付長頚坩".}
では検索できない
- 言語タグを持つ
- 名称のプロパティ(
schema:name
)とは別に、rdfs:label
で代表名称(ラベル)を言語タグ無しで記述する - 同じ言語タグを持つ名称のうち、代表ラベルと一致するもの以外は別名と考える
- ただし別名にも読みがある場合、現在のモデルでは区別できない
- 別名読みがあるデータセットは少ない(現在のところゼロ)→実用のため、名称の構造化は採用せず(100%の変換を目指さない原則)
- 複数の名称を同じプロパティにした場合、検索結果セットが増えてしまう
複レイヤ構造と語彙の選定
- タスクとモデルの構造
- 発見タスクには、シンプルで分かりやすい構造と語彙が必要
- ここでの「発見」は、特にジャパンサーチ内での検索の容易性
- モデル、語彙に加え、項目値の一貫性(正規化)も重要
- 識別、選択タスクには、確認や判断のための詳細な情報が必要
- 元データにある細かな違い(たとえば「歌川国芳作」と「伝歌川国芳画」)もきちんと提示
- 項目をまとめつつ、元データの項目名の違い(発掘地、開催地)も保持する
- 逆に元データでは自明な項目名に文脈を付与(標本の場合の「都道府県」→取得.採集地)
- 発見タスクには、シンプルで分かりやすい構造と語彙が必要
- 分かりやすさと詳細さを両立させる2つのレイヤ
- 発見タスクと識別、選択タスクの両方で重要な役割を担う、だれ(エージェント)、いつ(時間)、どこ(場所)について、複レイヤ構造を導入
- Schema.org語彙によるシンプル記述のレイヤⅠ
- 独自定義語彙を加えた構造化記述のレイヤⅡ
レイヤⅠ:シンプル記述
- Schema.orgによる分かりやすい記述
- 基本的なパターンで検索でき、モデルに関する特別な予備知識を求めない
SELECT * WHERE {
?s
schema:spatial place:三重
}- Schema.orgは世界的に広く利用され、特別な説明なしに通じる
- RDFに親しみのないウェブ開発者も利用しやすい
- 値も正規化し、異なる表記も一貫して検索できるようにする
レイヤⅡ:構造化記述
- シンプル記述と対になる構造化ノード
- 構造化記述プロパティ+関係タイプ(作者、訳者、制作地、出土地)
- 元データの項目名(出土地)の詳細は関係タイプで記述=元項目名の保持&文脈付与
- 関係タイプは制作、公開、発見、取得、記録、出演、内容、支援、関連の大区分
- さらに
role:発見.出土
という形で小区分を設け、大区分と関連付ける。小区分は変換時に動的生成も
- 変換元データの保存(住所→都道府県のような正規化で失われる情報)や処理に関する注記
- 元データはソース情報でも辿れるが、利用時のスムーズな確認は重要
- さらに緯度経度、時代などの付加価値情報を追加できる
- 伊勢国相可村発掘「脚付長頚坩」の場合:緯度経度とその判定に用いた辞書を注記
jps:value
プロパティでシンプル記述と同じ正規化値に関連付ける
- 構造化記述プロパティ+関係タイプ(作者、訳者、制作地、出土地)
構造化記述:注釈あるいはプロパティグラフ
- シンプル記述の関係への説明的注釈
- 構造化ノードはシンプル記述の説明もしくは注釈と考えることができる
- プロパティグラフの関係プロパティと捉えてもよい
- プロパティグラフはノード(円)、関係(矢印)がそれぞれプロパティ(キー:値の組;RDFでいうプロパティとは異なる)を持つことができる
- 関係はタイプを持ち(つまり
relationType
)、それがRDFでの矢印ラベル(=述語)に相当する
- RDF文のメタデータ記述拡張案RDF*(Turtle*)で記述してみると
<<jpsd:cobas-91058 schema:spatial place:三重>> jps:relationType role:発見.出土 ; schema:description "出土地: 伊勢国相可村" .
正規化値とLOD
- データ値の正規化
- 伊勢国相可村発掘 →
place:三重
、「元徳三年銘」→time:1331
- "葛飾卍老人"、"北斉載斗改葛飾為一"、"画狂人北斎" →
chname:葛飾北斎
- 正規化名を
chname:
、辞書マッチのない名前はそのままncname:
名前空間でURI化して区別(エージェントの場合) - 一次資料作成者では難しい大胆な正規化を敢えて実施
- 「伝○○作」など、作者とするには疑問の余地がある場合も正規化 → 元データも保持することで確認可能に
- 課題は多い(後述)が、当初予想した以上に正規化の効果は大きい
- 伊勢国相可村発掘 →
- LODハブとのリンク
汎用共通項目
- 基本項目以外は汎用記述
- 収集するデータセットのすべての項目を適切にマッピングするのは無理
- 共通記述において、基本項目(#10参照)以外は汎用記述にまとめる
- 識別、選択タスクに役立つ記述。発見タスクは、項目指定ではなく、値の検索を想定
- リテラル値の汎用記述
schema:description
を用い、値の先頭に導入句として項目名を加える<dignl-1287486>
schema:description
"注記 :
電子展示会名:国立国会図書館開館60周年記念貴重書展…".
- URIの汎用記述
jps:relatedLink
を用いて構造化し、relationType
に元項目の意味(関係)、schema:url
にURIを記述<dignl-1287486>
jps:relatedLink
[ jps:relationType role:関連.被参照
; #元項目はisReferencedBy schema:url <http://www.ndl.go.jp/exhibit60/...#no37> ]; schema:relatedLink <http://www.ndl.go.jp/exhibit60/...#no37> .
アクセス情報とメディアオブジェクト
- 取得タスクのための情報を集約
- 資料を所蔵している機関(
schema:provider
) → 英文名称、緯度経度などを含む情報 - 提供機関の資料紹介/カタログURL(
schema:url
)- IIIFマニフェストを含む、資料(のデジタル化オブジェクト)についての情報URL
- 資料のデジタル画像、音声動画など(
schema:associatedMedia
)- 直接利用できる高解像度画像、動画、3Dオブジェクト、などを想定(現在のところ該当なし)
- サムネイル画像は共通情報(資料自身のプロパティ)として
schema:image
- 請求記号、展示番号など、資料閲覧のためのID
- 中間アグリゲータ(つなぎ役)が紹介ページを提供している場合、ソース情報も
schema:url
などを持つ
- 資料を所蔵している機関(
- メディアオブジェクトのライセンス情報とメタデータ
- オブジェクトを主語としたトリプルで型、フォーマット、ライセンスなどを記述
- ライセンスは、提供者の基本ライセンスとしての提供が大半で、記述方法は要検討
- 現状では、利用者はライセンスを条件にしたアイテム/オブジェクト検索はできない
利活用スキーマRDFの探索と応用
いつ:時間正規化と範囲検索
- 時間表記の正規化と実体化
- 時間記述はすべて年を単位に正規化
- 範囲を持つ時間実体(Interval)として表現。単年でも
start
、end
プロパティを持つ - 時代、世紀も同じ形で時間範囲実体として扱える。さらに曖昧年(○年代、189xなど)も
- 時間実体を利用して、異なる記述のアイテムを検索。例:鎌倉時代の絵画
- 「鎌倉時代」という時代表記の値だけでなく、その時代範囲の西暦、和暦記述も検索できる。
SELECT ?s ?start ?end WHERE { {time:鎌倉時代
jps:start
?st ;jps:end
?et} ?s a type:絵画 ;schema:temporal
[jps:start
?start;jps:end
?end ] . FILTER (?start >= ?st && ?end <= ?et) }- さらに年表上への表示も
どこ:位置情報の利用
- 都道府県単位の正規化
- 場所記述は粒度がさまざま(国単位~街区住所)。旧国名や市町村合併=現在使わない地名
- 都道府県を単位に正規化(海外は国単位)。
- たとえば検索結果を都道府県別に集計し地図を色分けするなど
- 緯度経度とGeohash
なに:グラフによる探索
- タイプと階層検索
- タイプは元データの「種別」などから生成 → データセットによって異なる
- クラスを階層化:「版画」「水彩」は「絵画」の一種
- クラス階層を利用して例えば神奈川県の絵画&サブクラスを検索(プロパティパス)
?type
rdfs:subClassOf*
type:絵画
さらにグラフ探索
- 主題とキーワード
- 分類記号、件名標目、自由キーワードをURI化し、いずれも
schema:about
- それぞれ値の名前空間URIは異なる
- 分類記号はNDCの階層とNDLSHの関係を利用して
rdfs:seeAlso
による関連付けとラベルを内部的に設定- クエリを簡単にするため、
broader
、related
を区別せず、全てseeAlso
でリンク
- クエリを簡単にするため、
- 関連付けを使って例えば伝説に関係するものを検索
?s
schema:about
?subj . ?subjrdfs:seeAlso*
/rdfs:label "伝説"
- 分類記号、件名標目、自由キーワードをURI化し、いずれも
- 関係タイプの階層
- 役割の小区分は
skos:broader
で大区分と関連付けている - 汎用的な
spatial
、temporal
、agential
記述から、一定の役割を絞り込み検索できる ?s
jps:spatial
[ jps:value place:岡山 ; jps:relationType/skos:broader?
role:制作 ]- 現在のところ、Virtuosoの特徴により役割URIよりそのラベルを使う方が効率的
- 役割の小区分は
だれ:正規化と統合クエリ
- 正規化値とグラフ探索
- 作者などは、元データの典拠を用いて記述している場合がある(全国書誌でのNDLAなど)
- これらの典拠は正規化名URIと
sameAs
で関連付け→プロパティパスで一括検索できる ?s
schema:creator
/owl:sameAs?
chname:夏目漱石
- LODハブとMLA統合検索
- SPARQLエンドポイントを提供するMLAの多くが、それぞれの作者典拠をLODにリンク
- 共通のLODリンクを利用した統合検索が可能
- 作品記述のRDFモデルは各機関それぞれ異なるので、クエリは個別設計が必要
- 次の例はWikidataへの統合クエリ
?wid
owl:sameAs
chname:歌川国芳 ; rdfs:isDefinedBy <http://www.wikidata.org/>. SERVICE<https://query.wikidata.org/sparql>
{ ?uriwdt:P170
?wid ; rdfs:label ?label . FILTER (lang(?label)="en") OPTIONAL{?uriwdt:P18
?image} }
ジャパンサーチ内の新しい関係を見出す
- 作者関連グラフの推論
- アイテムにはしばしば複数寄与者 → これらの寄与者の間には何らかのつながりがある
SELECT ?someone (count(?s) as ?count) WHERE { ?s
jps:agential
[jps:relationType/skos:broader? role:制作; jps:value/owl:sameAs?chname:歌川広重
], [jps:relationType/skos:broader? role:制作; jps:value?someone
] FILTER(?someone != chname:歌川広重) } GROUP BY ?someone- つながりのある寄与者を集めることで、作者関連グラフが得られる
CONSRUCT
句で関係を表すRDFグラフ生成もできるがここではつながりの数も考慮
注釈によるユーザ発信情報
- マイノートとWeb Annotation
- ジャパンサーチのマイノートは、利用者によるアイテムへの注釈と考えることができる
- この関係は、Web Annotationを用いて表現できる
- Web Annotationで記述した注釈を用いて、ジャパンサーチとの統合クエリができる
- 自身のエンドポイントがなくても、ファイルに保存したWeb Annotationで統合クエリは可能
- ARQのようなコマンドラインツールで、ファイルを対象にクエリを実行できる
- URIハブとしてのジャパンサーチ
- 同じアイテムURIを
target
として記述された注釈は集約が可能 - さまざまな注釈を集める第三者サービス=ユーザ発信情報との連携の可能性
- ただし同じ「作品」が複数アイテムに対応する場合があり、URIハブとして機能するにはそれらの集約が必要
- 同じアイテムURIを
データとしての利活用スキーマRDF
- メタデータはデータでもある
- 利活用スキーマRDFは、基本的にはアイテムを記述するメタデータ
- さらにメタデータ自体をデータとして分析対象にすることもできる
- 地図色分けやチャートはその一種でもあるが、視覚化表現からアイテム検索クエリにリンクしており、検索結果表現のインターフェイスの一種でもある
- タイトルなどのテキスト分析
- キーワードをタイトルに含むアイテムを年別集計しグラフ化(例:猛烈,根性,感性,努力)
- タイトル抽出 → KH Coderで分析するなど
- 右図は「引札」を含むタイトルの多次元尺度法プロット
スキーマ(モデル)自身の活用
- オープンデータを利活用スキーマRDFに変換
- 日本関係外国語図書の書誌情報(TSVから)
- メトロポリタン美術館(CSVから)とクリーブランド美術館(API経由JSONから)
- CSV/TSVからの簡易変換ツールを提供
- ジャパンサーチRDFと共通モデルなので、利用者の追加学習コスト不要。統合検索も容易
- 汎用フォーマットとしての利活用スキーマ
- 構造化プロパティ+関係タイプで分野を問わない共通記述
- 例:クリーブランド美術館データの被引用文献 →
jps:relatedLink
の関係タイプをrole:関連.被引用
として汎用記述
- 例:クリーブランド美術館データの被引用文献 →
- Schema.orgの範囲で無理なく拡張できる
- シンプル記述にSchema.orgを用いているので、追加しても理解しやすい
- 例:メトロポリタン美術館源氏物語展の出展作品 →
schema:workFeatured
で記述
- 発見タスク(いつ、どこ、だれ、なに)以外は、拡張が使いやすさを損なう恐れは小さい
- 構造化プロパティ+関係タイプで分野を問わない共通記述
課題と展望
ベータ版公開から5ヶ月
- 比較的狙いに近く機能しているところ
- モデルの表現力、柔軟性、検索能力は、実データに対して概ね想定通り
- 新規追加データセットも、今のところマッピング対応できている
- 正規化は想定した以上に力を発揮する。統合クエリは外部からも注目されている
- SPARQLエンドポイントの応答は実用レベル(じつは重要なポイント)
- モデルの表現力、柔軟性、検索能力は、実データに対して概ね想定通り
- 課題そして/あるいは次の一歩
- 正規化の範囲と精度。予想外のパターンに遭遇し誤変換してしまっているものもある
- 外部データベースとの連携。例えば自治体コードを介したe-Statとの関連
- 同じ「作品」の同定。異なるデータセットで同じ「作品」を扱っているケースは少なくない → さらにWikidataなどとの関連付けも
- ユーザとデータの接点
- たとえば場所情報(ご当地アイテム)、時間情報(生まれ年、記念年)
- ユーザ発信情報(注釈)をうまく組み込む方法
正規化の課題
- 現在の正規化ツール
- サンプルデータ~ベータ版マッピング実装の過程で、さまざまな正規化規則を追加
- 特に時間情報は、ツールにより力技で正規化時間に変換
- 記述の例外が次々に出現し、いたちごっこ(変換ミスもあり)→機械学習などの利用も必要
- 固有名と辞書
- さらに人名、組織名を中心に、固有名と判定した部分を辞書マッチさせて名寄せ
- 同姓同名はアイテムの分野(タイプ)で判定
- 辞書は手作りで、人名なら約5600件
- 高頻度の人名中心に辞書を作成しているので、カバー率は比較的高いが、限界あり
- 今後現代の作品の収録が増えると名前マッチでは無理
- 提供者と協力して典拠整備が必要
- さらに人名、組織名を中心に、固有名と判定した部分を辞書マッチさせて名寄せ
- 元データの生かし方と精度
- 時間、場所ともに、現在の正規化では、より詳細な粒度の情報を持つ元データを生かせない
- 年表や地図による視覚化、あるいはご当地アイテム検索も、現状では大まかなレベル
- 緯度経度を用いる地図マッピングと対照的
- 一方、詳細度を高めた正規化には、一層精緻なマッピングツールが必要
- 元データの粒度はデータセットにより異なるため、現状の正規化以上は無理な場合もある。正規化データの階層化などの工夫が必要
クラス定義のあり方
- 元データの値からのマッピング
- 現在のタイプは、元データの「分類」などの項目に基づきマッピング
- 項目値のばらつきは、データセットごとに対応定義を用意し、一定程度同じクラスになるよう調整
- 一部のデータセットはタイプ固定(たとえば「放送番組」)、また適切な項目がなく、タイトルなどから推定する場合もある
- クラス体系の整備
- 複数データセットが混在するとき、基本区分としてのタイプ(クラス)付与は重要
- NDLと協議して約70の基本クラスを定め、階層化
- データセットのマッピング定義時に、必要があればサブクラスを基本クラスに追加
- 例えば「工芸」のサブクラスとして「竹工芸」を追加定義
- クラス体系=オントロジー構築は、大きなエネルギーを必要とする作業だが、現在は十分な検討の余力がない
- GettyのAATなどとの関連付けも望まれるが…
活用できるポータルへ
- より充実したデータを
- ベータ版公開時で約1700万アイテム(約7億トリプル)をRDF化しているが、データセットは16のみ
- サイエンスミュージアムネット、国立公文書館、全国書誌の3データセットで8割以上を占める
- データ提供のタイミングにより、RDF化が間に合わなかったデータセットあり
- 2019年7月時点でジャパンサーチ自身の連携データセットは既に40以上 → 順次RDF化
- データが増えるほどポータルとしての集積効果が高まる
- 特に各地の地元文化財や資料が集まれば、とても興味深いネットワークができる
- ベータ版公開時で約1700万アイテム(約7億トリプル)をRDF化しているが、データセットは16のみ
- 世界とのつながり
- 海外にある日本関連リソースもジャパンサーチを介して
- ジャパンサーチ内では欧州所在日本古書総合目録
- メトロポリタン、クリーブランド美術館RDFのような形で、ジャパンサーチと連動する海外リソース情報
- 世界で利用される日本関連リソースのポータルとして
- Wikidataがジャパンサーチ正規化名を表すプロパティJapan Search name IDを用意し、人名を中心に登録
- オックスフォード大ボドリアン図書館の招聘ウィキメディアンであるポールター氏のブログ記事でWikidataからのクエリ紹介
- 英語ラベル、読み(ローマ字)の一層の充実
- 海外にある日本関連リソースもジャパンサーチを介して
参照先
- 参照したリソース
- ジャパンサーチ利活用フォーマット概念モデルと語彙検討報告書, 2018-06-01, 国立国会図書館
<http://www.ndl.go.jp/jp/dlib/standards/jpsformat.html> - 第二次中間取りまとめ, 2019-04, デジタルアーカイブジャパン実務者検討委員会
<https://www.kantei.go.jp/jp/singi/titeki2/digitalarchive_suisiniinkai/jitumusya/2018/torimatome2.pdf#page=38> - ジャパンサーチのシステム・アーキテクチャ, by 川島隆徳, 2019-04-29, アカデミック・リソース・ガイド 743号
<http://www.arg.ne.jp/node/9738> - EasySPARQLのREST風パラメータ, SPARQLエンドポイント解説§4
<https://jpsearch.go.jp/api/sparql-explain/#sec4> - SPARQL 1.1 Query Results JSON Format, 2013-03-21, W3C Recommendation
<https://www.w3.org/TR/sparql11-results-json/> - Europeana Data Model documentation
<https://pro.europeana.eu/resources/standardization-tools/edm-documentation> - 構造化記述プロパティ, 利活用スキーマ概説§1.2
<https://jpsearch.go.jp/api/introduction/#sec1-2> - Graph database concepts, The Neo4j documentation
<https://neo4j.com/docs/getting-started/current/graphdb-concepts/> - 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> - SPARQL 1.1 Federated Query, 2013-03-21, W3C Recommendation
<https://www.w3.org/TR/sparql11-federated-query/> - 歴史地名データ, 人間文化研究機構
<https://www.nihu.jp/ja/publication/source_map> - Web Annotation Data Model, 2017-02-23, W3C Recommendation
<https://www.w3.org/TR/annotation-model/> - 相撲絵の場合:ジャパンサーチとWeb Annotation, (非公式サポート)
<https://www.kanzaki.com/works/ld/jpsearch/annot-sumo> - ARQ - A SPARQL Processor for Jena
<https://jena.apache.org/documentation/query/> - KH Coder: 計量テキスト分析・テキストマイニングのためのフリーソフトウェア
<https://khcoder.net/> - e-Stat 地域から探す
<https://www.e-stat.go.jp/regional-statistics/> - Art & Architecture Thesaurus, Getty Research Institute
<https://www.getty.edu/research/tools/vocabularies/aat/> - Japan Search name ID, Wikidata property
<https://www.wikidata.org/wiki/Property:P6698> - Welcome Japan Search to the web of Linked Open Data, by Martin Poulter, 2019-05-30
<http://blogs.bodleian.ox.ac.uk/digital/2019/05/30/welcome-japan-search-to-the-web-of-linked-open-data/>
- ジャパンサーチ利活用フォーマット概念モデルと語彙検討報告書, 2018-06-01, 国立国会図書館