ジャパンサーチ利活用スキーマの共有可能実体：マッピングとデータ連携

データ連携とジャパンサーチ利活用スキーマ
連携の共通点：いつ、どこ、だれ、なに
二層記述モデル
実体の切り出しと集約
共有可能実体化マッピング事例：「なに」を中心に
アイテム型の共通化
埋め込まれた実体：掲載誌
構成要素と全体
記述内容と共有可能実体
作品とアイテム
錦絵から句碑へ：共有可能実体を介したデータ連携
共有可能実体とマッピングの課題：「だれ」を中心に
共有可能実体のURI (1)：識別子の設定
共有可能実体のURI (2)：現状と課題
マッピングの課題 (1)：項目名（プロパティ）
マッピング上の課題 (2)：項目値
まとめ
参照先

データ連携とジャパンサーチ利活用スキーマ

連携の共通点：いつ、どこ、だれ、なに

多様なデータをつなぐ切り口：プロパティの4W
- 2021年2月末までに多分野にわたる100データセットを利活用スキーマでRDF化
- 項目名はみな異なるが、ほとんどのデータセットが「いつ」「どこ」「だれ」に相当する項目を持つ
- さらに「なに」は、アイテム自身（型）、アイテムの内容（主題）、つながるもの（関連）が何か
- 欲張らず、4Wを中心に焦点を絞って連携の切り口に
連携の接点：値の共有
- 同じ切り口（項目／プロパティ）にそろえても値の記述が異なる
- 別名：1806年は文化三年、嘉慶11年とも。歌川貞秀は五雲亭、玉蘭斎などとも表記される
- 揺れと粒度：同じ名前でも表記の揺れが多数。時間、場所は粒度も多様。さらにさまざまな補助情報や記号なども
- 記述の違いにはそれぞれ意味はあるが、実体として同じものを共有できない
正規化値による集約とリンク
- 値を正規化し、別名でも実体として同じなら同じ名前（識別子）を用いる
- 同じ名前による集約ができる
- 名前を実体化することで、付加情報を関連付ける
- 厳密さよりも多様なデータセットの共通項として（時間は年単位、場所は都道府県単位）

二層記述モデル

共通化と個別データ
- 各データセットの値記述には、それぞれ理由がある
- 単純な正規化・共通化では、重要な細部が失われる
構造化ノードと単純プロパティ
- 正規化した値と元の値を両方保持する構造化ノード
- 項目名も確認可能にする（元データの導入句として）
- 正規化値を簡単に扱えるショートカットも用意した二層記述モデル
二層記述モデルのグラフ
- 構造化プロパティは独自語彙（jps:）、ショートカットはschema.orgに統一

実体の切り出しと集約

正規化値を共有可能な実体にする
- 名前を共通化（正規化）するだけでなく、URIで識別される実体（Linked Data）として扱う
- 読み、説明、画像などの情報を集約して付加できる
- Wikidata、NDLA、VIAFなどの外部LODとリンクして繋がりを広げる
責任表示型記述から実体と役割を切り分ける
- 多くの記述で、1つのフィールド値に名前と役割がまとめられている（目録規則でいう責任表示）
- 同じフィールドに複数名が役割とともに列挙されることもある
- ```
"Creator": "[作者]杉田玄白撰、杉田伯元書"
"Creator": "[作者]東條信耕［著］；阿部喜任，高田信頌，傍島正心校"
```
- 名前と役割の切り分けが困難な記述もある
- ```
"編著者": "緑亭川柳作" vs "絵師": "田口米作"
```
  - 「作」は役割？名前の一部？
同じ名前の区別
- アイテムの型による限定：「絵画」ならば吉田博はchname:吉田博_(絵画)
- データセットごとの補助マッピング：古筆切所収情報での「明雲」はchname:大僧正明雲
- 別フィールド値で区別：二十一代集の「関白前左大臣」は[書名]が「続古今和歌集」なら一条実経…

共有可能実体化マッピング事例：「なに」を中心に

アイテム型の共通化

複合データセットでの型の重要性
- 対象が未知であるとき、複合データセットの横断検索では型（クラス）が手がかりになることが多い
- 条件を“ラベルに「横浜港」を含む”とした検索 →あるていど内容の想像はつくが整理しにくい
- ラベルと合わせて型も結果に示す検索 → 型があることで選択タスクが容易になる
- ラベル条件に加え絵画とそのサブクラスに限定した検索 → あらかじめ目的が明確ならより確実
データから型へのマッピング
- 型や種別を示すフィールドが提供されないデータセットも多い
- 歴博館蔵資料目録の場合：Relationの名前パターンから型にマッピング
- 正規表現付与する型
  
  ^.*(銭貨|古銭)$ 硬貨
  
  ^.+(絵[巻図]?|[^絵]画|版木|之図)$ 絵画等
  
  ^.*(文書|字[版本]|典籍類?|禁裏本)$ 古書・古文書
  
  ... ...
- 歴博館蔵品を型別に集約して閲覧できる

正規表現	付与する型
^.*(銭貨\|古銭)$	硬貨
^.+(絵[巻図]?\|[^絵]画\|版木\|之図)$	絵画等
^.*(文書\|字[版本]\|典籍類?\|禁裏本)$	古書・古文書
...	...

埋め込まれた実体：掲載誌

論文等と掲載誌の関係
- 多くのデータで掲載誌、巻号、ページが単一フィールドにまとめられている
- ```
"Source": "[掲載誌情報]ここまで進んだ!ここまで分かった!国立国語研究所の日本語研究 : 国立国語研究所第9回NINJALフォーラム, pp.6-13, 2016-08-10"
```
- 掲載誌や連続フォーラムの実体が埋もれてしまい、何とつながるかを記述できない
関係の記述
- Source情報から掲載誌を切り分け、実体化（さらに全国書誌などJPSデータとマッチング）
- 掲載号、ページなどは、agentialの場合と同じく構造化ノードに保持する
- isPartOfを用いて同じフォーラムの報告書掲載記事を集約できる
- 蔵書印データベースや古筆切所収情報では出典／典拠をrelatedLinkとして記述
- 明治期出版広告データベースでは掲載媒体、広告対象およびそのシリーズをabout、relatedLink、isPartOfの組合せで

構成要素と全体

行から巻、作品へ
- 絵入源氏物語、歴史物語は古書の1行が1つのアイテム（type:構成要素）
- ページ単位、巻本単位、作品単位でそれぞれ全体部分関係（isPartOf）を記述
- 「何の一部か」で集約ができる
構成要素の利用
- 絵入源氏物語で「紅葉」が出現する箇所を巻行単位で検索できる
- 構成要素テキストを順につなげば本文を組み立てられる
- 「絵入」の位置を示す情報などを加え、EPUBリーダーで表示

記述内容と共有可能実体

名所図会と名所実体
- 平安京都名所図会の「下賀茂神社」は『都名所図会巻之六後玄武再刻』の一部（構成要素）
- 記述内容（何を）をchname:下鴨神社として共有可能実体化することで、他の文化財アイテムの所蔵を記述できる
- 下鴨神社の各種催事を季語検索（歳時記）と関連付けることもできる
- 各名所実体には緯度経度情報を付与し、地図上でのプロットも可能
季語検索と季語実体
- 季語検索の各アイテムは「俳諧歳時記」の構成要素（と思われる）。記述内容が季語
- 俳諧歳時記をもとにkeyword/歳時記:名前空間に季語実体を作成。外部リソースともリンク
- keyword:名前空間のキーワードと関連付けることで、俳句以外のアイテムも歳時記にリンク
  - 一般キーワードと季語の名前空間を分けるのは、例えば江戸時代の馬川渡を指す「水馬」とアメンボを指す「水馬(水澄)」を区別する必要があるため

作品とアイテム

映画作品とフィルム
- NFAJ所蔵映画フィルム検索システムはその名の通り上映用フィルムのデータベース
- メタデータにはフィルムの属性（時間、フィート長、カラー）に加え映画作品の属性（監督、出演者、配給など）も
- フィルムと作品を別実体にすることで、同じ作品の（何の）フィルムを集約
- さらに同じ原作に基づく別作品の集約も。例：伊豆の踊子
芝居作品、上演、番付
- ARC番付ポータルの番付は同一公演のものを複数館が所有、さらに公演では複数の作品を上演
- それぞれを個別実体として切り分けてリンク。作品ごと、公演ごとの集約ができる

錦絵から句碑へ：共有可能実体を介したデータ連携

季語実体を介して異なる分野のデータがつながる

共有可能実体とマッピングの課題：「だれ」を中心に

共有可能実体のURI (1)：識別子の設定

名前型URIの採用
- 利用する際に分かりやすく便利（数値などのID型では毎回ラベル参照が必要）
- マッピングの検証に（同ID型では誤マッピングを見つけるのが難しい）
- 非統制名前空間：辞書マッチしない名前のncname:。またkeyword:も原則としてデータ値をそのままURI化
- これらとの関係からも、正規化名（chname:、place:）に名前型URIを採用
外部典拠とジャパンサーチ正規化名
- たとえば全国書誌の名前は原則としてNDLAを利用
- 正規化名が対応NDLAを辞書に持っている場合は、マッピング時にchnameに変換
- chnameと対応NDLAはowl:sameAsで関連付け → あとで辞書追加した場合でもプロパティパスで検索できる
- ```
?s schema:creator/owl:sameAs? chname:篠田瑳助  #ndla:001165689 も検索できる
```
同一実体の機械的識別：ハッシュを用いたURI
- 番付ポータルにおいて、同じ「公演」を同じURIで識別したいが、IDはない
- 外題統合（＝演目）、年月、地域・劇場が一致すれば同一公演と仮定
- これらのハッシュを用いたURI（ただしハッシュだけだと分かりにくいので、西暦年と地域を平文で前置する）。例：event-1816名古屋-1a90af71ce3c458d

共有可能実体のURI (2)：現状と課題

正規化名へのマッピング状況

だれ（agential）で用いられる名前の出現数と正規化率
区分	全出現数	名前数 (除重複)	平均回数
全体	22,693,903	2,559,583	8.87
chname (含SA)	6,447,307	28,583	225.56
chname + NDLA	15,895,029	1,742,136	9.12
正規化率 (+NDLAの場合)	28.41% (70.04%)	1.12% (68.06%)	-

名前数(除重複)はDISTINCTを用いて重複を除いた名前の出現数
平均回数＝使用名数÷全出現数で、同じ名前が平均何回使われているかを示す
chname(含SA)＝全国書誌のNDLAのうちchnameにowl:sameAsで関連付けたものを含む
+NDLAは全国書誌のagentialがすべてNDLAという前提での「正規化名」合計

辞書定義時の同姓同名と別名
- 同姓同名を区別するため必要に応じて限定子を用いる（#4参照）が、バランスが難しい
- 別名を別人格（実体）と捉えるべきか、集約すべきか
- 集約したほうが一般に利用しやすい。しかし「松竹合名会社」を現在の「松竹」に集約するのは？
マッピング漏れと誤マッピング
- 正規化は、名前切り出しアルゴリズム×辞書マッチによる。すなわち：
- 名前切り出しに失敗、空白・記号の除去が不完全などの理由でマッピング漏れが生じ得る
- 同姓同名の誤マッピングは、テキストマッチ基本の処理では完全には回避できない

マッピングの課題 (1)：項目名（プロパティ）

提供される項目の欠落
- 元のデータベースには存在する（はずの）項目が、提供時に省略される場合がある
- 特に型（クラス）判定の基礎となる種別、区分などが略される場合が多い
- ほか正規化値、画像などの省略：それぞれ事情があるとは思うが、不完全マッピングや検索結果で埋もれたりして、せっかくのデータが生きないので、間引くことなく提供して頂けると嬉しい
項目名マッピングは十分か
- 4W以外の大半は、項目名を導入句としたschema:descriptionにマッピング（詳しくは基本記述プロパティ説明参照）
- ```
schema:description "品質形状: 紙本着色", "員数: 1幅"
```
- 主として検索（発見タスク）より表示（選択タスク）が中心と考えたため。集約はFILTERで可能
- ```
?s schema:description ?desc
FILTER strstarts(?desc, "品質形状:")
```
- schema.orgで提案されている materialExtentなどは追加してもよいのかも…

マッピング上の課題 (2)：項目値

複数値を持つ項目の記述パターン
- 配列型：項目値を配列にする（表形式データでは難しい）
- 区切り文字型：1つの項目値を区切り文字で分けて複数値列挙
- 独立複数項目型：外題1～10、場幕名1～10、音曲1～10…
配列型項目の対応
- 複数の項目が配列型である時、関連する配列要素は同じ位置であることが原則
- ```
"人物": ["篠田瑳助", "竹柴濤治", ...],
"よみ": ["しのだ さすけ", "たけしば とうじ", ...]
```
  - これが対応しないデータは、マッピング困難！

区切り文字の憂鬱

1つの区切り文字が（同じデータセット内で）違う機能に用いられることがある

"creator": "篠田瑳助・竹柴涛治・竹柴浅吉・竹柴喜三次..."
"creator": "監督・天の巻・マキノ正博、地の巻・池田富保、"

1つのフィールドに複数の役割

"Creator":"/Murakami N, Hatanaka S/日本植物学会/The Botanical Society of Japan"
//どうやら"著者和名/著者英名/発行者和名/発行者英名"という構造らしい

まとめ

共有可能な実体
- データ値から固有名を切り出して正規化＆実体化
- 表記の揺れや別名を含めた集約ができる
- 異なるデータセットのアイテム間につながりができる
- 関連情報とリンクすることで応用範囲が広がる
プロパティとモデル
- 4Wを中心に独自語彙とSchema.orgで記述
- 同じクエリが異なるデータセットでも使える＝横断検索
- 使いやすさと元データ保持を両立させる二層記述モデル（#3参照）
- 用途に応じた柔軟なクエリの組み立て
課題と展望
- 適切なデータ連携のためには、プロパティ共有だけでなく値の共有も必要
- 正規化辞書の単独整備には限界 → データ提供者の（あるいは外部の）典拠との連携が重要
- さらに一貫した値記述のためのコンセンサス（少なくともデータセット内で）が欲しい

参照先

参照したリソース
1. ジャパンサーチ利活用スキーマ概説
  <https://jpsearch.go.jp/static/developer/introduction/>
2. ジャパンサーチ利活用スキーマの設計と応用, 2020, デジタルアーカイブ学会誌, 4巻4号, p.342-347
  <https://doi.org/10.24506/jsda.4.4_342>
3. リンクするデータ、未来へのリンク, 2011-03-07
  <https://www.kanzaki.com/works/2011/pub/0307wi2.html>
4. 責任表示 - 図書館情報学用語辞典第5版での解説
  <https://kotobank.jp/word/責任表示-1703111>
5. 絵入源氏物語を電書リーダーで読む
  <https://www.kanzaki.com/works/ld/jpsearch/genji-reader>
6. 京都の名水を名所図会のデータでプロット
  <https://www.kanzaki.com/works/ld/jpsearch/jpgeomap#qt=keyword&qd=名所.水>
7. 映画のメタデータとリンクするデータ, 2016-04-27
  <https://www.kanzaki.com/works/2016/pub/0226momat.html>
8. ジャパンサーチ利活用スキーマ概説 - 基本記述プロパティ
  <https://jpsearch.go.jp/static/developer/property_simple/>
9. MaterialExtent & CollectionSize - Issue #1759 - schemaorg
  <https://github.com/schemaorg/schemaorg/issues/1759>