1 準備：利用者タスクとRDFグラフ

2 例題：著作リストをつくる

• ステップ1：山崎正和の著作を探し出す
  • 例えばNDLオンラインで著者（＝山崎正和）検索
  • 
• ステップ2：検索結果からリストに収録する著作を絞り込む
  • タイトルや掲載誌を見て明らかに別の山崎正和氏によるものを選び分ける
  • 細胞学や臨床心理学の山崎氏は該当する？
  • 
• ステップ3：得られた結果をもとに著作リストの雛形を作る
  • 結果のデータを何らかの手段で取得し、加工する
  • エクスポート機能やAPIがあれば取得手段となる

3 試みたタスクと求められる機能

• タスク1a：網羅的に（未知の著作を含め）探す
  • 山崎正和の全著作を探す：集中機能
  • 同姓同名によるノイズ、別名や表記の揺れによる漏れをなくしたい
• タスク1b：特定の（既知の）ものを探す
  • 山崎正和と司馬遼太郎の対談「日本人と京都」の初出誌と収録書を探す
  • 中央公論1996年の「再録 司馬遼太郎名対談選」（雑誌記事）しかヒットしない
  • 大宅壮一文庫により初出＝「新潮45+」1985年4月号、別情報源により収録書＝遠藤周作 編『話し上手聞き上手』
    • NDLでは「新潮45+」の個別号書誌は提供されていない模様
    • 同じ司馬遼太郎との対談「近代化の推進者明治天皇」の収録書『明治国家のこと』はNDLサーチに部分タイトルが含まれるためヒットする。しかし目次が収録されていないため山崎／司馬対談が含まれることが分からなかった
  • 一つの目録で見つからなくても外部情報源に導いてくれる機能
• タスク2a：見つかったものを確かめる
  • 「組織極性による～」「臨床心理学と文明史上の革命」は探しているものか（著作リストに加えるべき記事か）
  • 前者は山形大学の山崎正和教授。後者は雑誌巻号などは分かるが、著者は氏名のみで判定できない
    • 全国日本学士会のサイトで調べると掲載号の目次があり、「劇作家　山崎正和の提言：『臨床心理学と文明史上の革命』」と記されていることから著作リスト収録対象であることが分かる
  • 的確な標目（ID）付与。難しければ、やはり必要に応じて外部情報源に導いてくれる機能
• タスク2b＋タスク3：目的に合わせて絞り込み、データを取得する
  • 識別の結果、著作リストの対象外とわかったものを除外する
  • 明確に識別できなかったものはとりあえず残してデータを取得し、あとで絞り込む
    • あるいは先にデータを取得して絞り込みは別ツールで行なう
  • データそのものを別のツールで利用する

4 利用者タスクの整理

• FRBRの4タスク分析（＋1）
  • 発見：別名や表記の揺れも含め（再現率）つつ、ノイズの少ない（精度）検索 → アクセスポイント
  • 識別：対象が何ものかを確かめる → 詳細な記述と関連情報リンク
  • 選択：利用者目的と照合し絞り込む → 多くの場合、識別とセット
  • 取得：記述対象の入手先、ライセンス、アクセス制限など（今回の例ではデータそのもの）
• • 探索：つながりを見出す＝IFLA LRMで加わった＋1
• 拡張するメタデータ利用タスク
  • 目録自身をデータとして利用する。著作リストの下準備のほか、集約、分析、データ視覚化など
  • 外部データとの統合と再利用。目録の外でも（文脈なしでも）使える情報
  • 利用者としてのコンピュータプログラム
  • 外部からのアクセス促進。リンクされるLODとして

5 メタデータの共有と文脈

• 文脈を前提とする記述
  • OPACなどの目録詳細は一般に項目：値ペアで表現される
  • 対象は詳細ページの表すもの（暗黙の前提）
  • 
• 文脈に依存しない記述
  • メタデータを異なるDBで共有・再利用するには対象の明示が必要
  • 対象を主語として項目：値ペアに加えることで文脈に依存せずに表現
  • 

6 RDFグラフによる記述

• RDFトリプルとURI
  • 項目：値ペアに主語を加えたRDFトリプルで最小単位の情報を記述
  • 主語、述語（項目名）、目的語（項目値）にURIを用いる → ウェブ全体で通じる
    • 漢字などを直接用いることができる識別子はIRI（URIの上位互換）だが、ここではIRIと同じ意味でURIを用いる
  • 
• RDFリテラルとRDFグラフ
  • 数字やラベルそのものなど別途名前を与える必要がないものはリテラル値（＝そのまま）とする
  • RDFトリプルの集合をRDFグラフと呼ぶ
  • 同じURIを持つノードは（誰が記述したものでも）連結できる
  • 
  • 共通のURIを広く共有すれば、グラフが繋がり、付加価値が増す

7 Linked Dataと2種類のURI

• リンクするデータ
  • ティム・バーナーズ＝リーが2006年にLinked Dataの4原則についてのメモを公開
  • URIを識別だけでなくリンクにも用いる＝リンクを辿ってRDFが取得できる
    • LODはこの考えを公開データに結びつけるもので、2007年のW3CプロジェクトLinking Open Dataが発端
    • つまり「リンクする」オープンデータ。その後、一般にはLinked Open Data
  • 外部データセットとのリンクは重要だが、同じデータセット内のリンクもLinked Data
• 情報リソースと非情報リソース
  • URIを辿って直接情報が得られるものは情報リソース＝典拠など
  • 人物などネットワーク経由で取得できないものは非情報リソース
  • 異なるもの（例えば典拠と人物）に同じURIを与えることはできない（＝URIの衝突）
• Web NDLAの典拠と人物
  • 典拠URI：http://id.ndl.go.jp/auth/ndlna/00094706
    • 典拠作成日、出典など人物とは別の属性を持つ
  • 人物URI：http://id.ndl.go.jp/auth/entity/00094706
    • 生没年など人物としての属性を持つ
  • 著者の記述には人物URIを用いる
  • 

8 アクセスポイントとLOD

9 典拠とアクセスポイント

• 典拠レコードの要素
  • 統一された名前（統一標目）と識別子ID
  • 別名、表記の揺れからのアクセス（異形アクセスポイント）
  • ほかの実体との区別＝識別のための情報（生没年、分野など）
  • 関連する実体とのリンク
  • 来歴、根拠、情報源
  • （図書館情報学事典2023「典拠コントロール」より。以下で「典拠要素」として参照）
• アクセスポイントの形とURI
  • 標目型：山崎, 正和, 1934-2020 → 分かりやすいが改名、没年追加などで変化
  • ID型：00094706 → 確実だがラベルなしには使えず、複数典拠が混在すると機能しない
  • URI型：http://id.ndl.go.jp/auth/ndlna/00094706 → どこでも確実。典拠レコードRDFの主語にできる
• URIによる典拠の記述
  • （概ね）共通の方法でラベルと関連付け（典拠要素1.）
  • 
    • 以下では長いURIを必要に応じてrdfs:labelのような形で短縮表記
  • 他の要素もRDFトリプルで記述し、典拠レコード全体をRDFグラフとする

10 組織・領域を越えるアクセスポイント

• 複合データ（ポータル）での発見の課題
  • 異なる典拠形を持つ（あるいは典拠形を持たない）データの集合
    • そもそも典拠の構築はコストがかかり、どんな組織でも自前で整備できるものではない
  • 元のデータセット単位では統制された名前（標目）でも、ポータルに集めると他と微妙に異なる
  • 単純な姓名だけの場合、機械的な識別・マッピングはかなり工夫を要する
  • IDはそのままでは統合環境で使えない（対応辞書があれば翻訳できる）
• ポータルの横断型アクセスポイント：ジャパンサーチ正規化名
  • 人物、団体などを中心に約3.25万の名前辞書を作成し、統合典拠とする
    • URIはWikipedia的な名前型URI。可能ならWeb NDLAやWikidataにリンクする（典拠要素4.）
    • 連携先のデータをRDF化する際に、データセットごとの規則を設定してマッピング
    • マッピングの当否を確認するために、別名や識別の情報（典拠要素2.および3.）が重要
    • すべての名前を辞書化できるわけではない（後述）
  • URI型のアクセスポイントはそのまま用いる
    • 全国書誌の各アイテムの著者はNDLAのURIが付与されているので、基本的にはマッピングせずそのまま収録
    • 統合典拠にNDLAとのリンク（owl:sameAs）がある（要素4.）ので、どちらからでも検索できる

  • SELECT ?s ?label ?who WHERE {
        ?s rdfs:label ?label ;
            schema:creator ?who .
        ?who owl:sameAs? chname:山崎正和    #著者がNDLAでもchnameでも検索できる
    }

    ▶

11 関連リンクと識別子のハブ

• 複数の典拠（URI）
  • 分野ごとに、組織ごとにいろいろな典拠
    • アメリカ議会図書館：n79135559
    • 韓国国立中央図書館：KAC200402504
    • Google知識グラフID：/g/1q5bfcg1b
    • 神学索引：363405151
  • 関連リンク先（典拠要素4.）としてどの典拠を使うか
    • 複数にリンクしてもよいが、どこかに集中できる方が互いにリンクしやすい
    • 自前で典拠を持たず外部典拠をアクセスポイントとして使うことも考えられる
    • 図書館関係ならVIAFがあるが…
• 識別子のハブとなるWikidata
  • Wikipediaの多言語リンクとして2012年に発足
  • Wikipediaとは異なり、Qで始まるID型の識別子。山崎正和ならQ11468118
  • 上記の例すべてを含む8000強の外部識別子が登録されており、Wikidataを介して相互にリンクすることが可能
    • 各外部識別子はそれぞれPで始まる固有のプロパティで関連付けられる
  • 

12 正規化辞書にない名前

• 値のURI化と典拠
  • すべての値を典拠としてURI化できるのが理想
  • データセットで用いる典拠にすべての値がマッピングできるとは限らない
  • たとえば生命科学の山崎正和氏（秋田大学）はNDLAの典拠IDがないため、NDLサーチのRDFでは空白ノード
  • 
• ジャパンサーチの正規化辞書と非統制名
  • 正規化辞書に登録する名前はchname:名前空間のURIを付与
  • 辞書にマッピング（正規化）できない名前も、ncname:名前空間を用いてURI化する
    • ncはnon-controlledで、同姓同名が同じncname:にマッピングされる可能性もある
    • URIを用いた集約など、アクセスポイントとしてのメリットがある
  • 
  • キーワードなども、表記の揺れや同音異義語を厳密に考えずそのままURI化してアクセスポイントに

13 アクセスポイントとしてのNDC

• NDCの版とURI
  • 
  • NDCの932は、版によって上位分類名が微妙に異なるが基本的に同じ意味
  • 分類記号932を表すURIはNDC-LD8/9版、NDL版など現在のところ複数ある
  • NDLサーチのRDFでは型付リテラル（"932"^^dcndl:NDC8）
  • 「エレファント・マン」のNDCは国立国会図書館では8版の932、公立図書館では9版／10版の932が多い
• アクセスポイントとして版次なしURIを直接記述
  • Webcat PlusのRDFモデルでは、試験的にNDC-LDの版次なしURIに一本化
  • もちろん版によって項目名が異なる分類もあるので、版も確認できる必要がある → schema:descriptionに導入句「分類: 」に続けて版付分類記号を格納
    • 「このアメリカ」の914.6は9版以降では「評論．エッセイ．随筆--近代：明治以後」であるのに対し、8版では「評論．小品．随筆--近代」、さらに6/7版では「日記，紀行，随筆，小品．評論--江戸時代」
• • 考え方としては、後述の構造化を用いて、基本値は版次なしURIとしつつ版情報も併記する方法もある
• 版次なしURIのNDC-LDの定義
  • 版次なしURIは9版、8版のNDC-LDの分類定義でdct:isVersionOfとして記述されているのみ
    • これだけでは、上位下位関係を利用した集約などができない
  • NDC-LD9版のrdfs:label、skos:broaderを継承、9版にはdct:hasVersionでリンク
  • さらにWebcat plusで用いられる分類で、NDC-LD9版では定義されていない分類を追加
    • 補助区分表による分類（NDC-LDでは部分的に生成）を、実際に使われているものに絞って追加生成（版次なしのみ）
    • 第10版での新設、第6/7版からの廃止など第9版にない分類を追加

14 詳細な記述と構造化

15 多重化された値

• 行為者とその役割などが多重化された責任表示
  • 複数の情報を単一項目に押し込むため値が多重化される
  • 
  • 記述方法が分野によって異なる → 名前と役割の区切りが非専門家では分からない場合も
    • 和田英作編、西山元文の「作」「文」は役割文字なのか名前の一部なのか
  • さらに複数値が1フィールドに記述されることもあるが区切り文字が不統一
    • 同じデータセットで , が複数値区切りと姓名区切りの両方に用いられたり
    • "Hearn, Lafcadio, 1850-1904 小泉, セツ"というデータは機械的に分割できるのか
• 分割と項目名
  • NDLサーチのRDFではdct:creatorの値としてURI、dc:creatorの値として役割を含む責任表示
  • 
  • 役割は人間が読んではじめて分かる。dct:の値とdc:の値の対応が分からない
    • 役割ごとに項目（プロパティ）を設定すれば整理できるが

    • creator	バーナード・ポメランス
      translator	山崎正和

    • 多分野メタデータでは際限なくプロパティが増える
    • 同一プロパティで検索できない

16 RDFによる構造化データ

• セットとなる表現
  • 
  • 表記と読み、筆名と本名、住所分かち書きなど、ひとまとまりとして扱うべき情報
  • それぞれのプロパティで直接記述すると、別名や住所が複数ある場合など対応関係が破綻する
• RDFの空白ノードと構造化
  • 通常ノードはURIで識別・参照する
  • 空白ノード：グラフ内で識別できればOKでグローバルに参照する必要のないノード
  • ある（匿名の）ノードがグラフ内に存在することだけ示す
  • 空白ノードを節点としてひとまとまりの情報を構造化できる
  • 

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

• ジャパンサーチの構造化記述
  • ジャパンサーチ利活用スキーマ：200近いデータセットを統一的に記述するためのRDF語彙
  • 「いつ」「どこ」「だれ」について、空白ノードを用いた構造化記述を導入
  • 正規化値をjps:valueで、加えてjps:relationTypeでその役割を示す
  • さらに元データの値もschema:descriptionで構造化ノードに保持する
• 寄与者（だれ）とその役割のモデル
  • アイテム主語とこれらを構造化した空白ノードをjps:agentialで関連付け
    • 元項目名を細かなプロパティに分けず、役割として表現。さらに元データ値の導入句としても保存
    • 役割の値は責任表示などの役割文字も加味して構造化。「制作」「公開」など大きなくくりで集約可能
    • 同じ役割を持つ「いつ」「どこ」と対応付けられる。例えば「公開.出版」で出版者、出版日、出版地（出版イベント）が対応
    • 元データは別名や表記揺れを標目に正規化したときなど確認のために必要
  • 詳細な関連情報がまとまっている＝識別タスクに重要
  • 

18 使いやいアクセス：発見タスクとのバランス

• 利用者はアクセスポイントを…
  • シンプルに考える。対象アイテムの直接のプロパティ値であるというメンタルモデル
    • 構造化記述の場合、モデルを知らないと発見タスク（人物名／URIでの検索）がうまくできないかもしれない
  • まず試してみる。dct:creatorなど広く使われるプロパティの確率が高いだろう…
• ジャパンサーチの二層モデル
  • 使いやすさのために、schema:creatorを用いて正規化値をその目的語とする（単純プロパティ）
  • 単純プロパティと構造化記述を併記し、いずれからも正規化値につながるようにする
  • 
• • Web NDLAで標目形（優先ラベル）をrdfs:labelとしても記述するのも同様の考え
  • 

19 （参考）Wikidataの記述モデル

• 直接プロパティと構造化プロパティの二層モデル
  • 山崎正和の受賞（P166）の記述＝賞名（文化勲章）に加え、受賞年2006と記述の来歴Wikipediaを付記
  • 
• • 基本プロパティ（p:P166）は受けた賞、時間、来歴の構造化ノードにリンク
  • 直接プロパティ（wdt:P166）で受けた賞（文化勲章）のリソースにショートカット
  • 

20 リンクと構造化によるメタデータの拡張

21 ジャパンサーチの構造化ノードとLOD

• 時間情報の記述
  • jps:temporal、schema:temporalを用いて二層モデル
  • 時間正規化は年単位で、常に範囲を持つ（単年は開始、終了が同じ）→LRMのTime-spanと同様
  • 時代、世紀を年範囲で定義し、時代は構造化ノードにjps:eraで追記
  • 各時間実体からWikidataなどのほかHuTimeとリンク
• 場所情報の記述
  • jps:spatial、schema:spatialを用いて二層モデル
  • 場所正規化は都道府県（海外は国）単位
  • 緯度経度を付与し、geohashへのリンクを用いて階層構造を提供
  • 場所（place:）とそこにある寄与者（組織、自治体など）を区別。LODには寄与者から
    • LRMでのPlaceがThe place as an extent of space is distinct from any governing bodiesとしているのと同様
• ほかの記述への拡張
  • 全体・部分関係において、上位実体の「どの部分」なのかを表現
  • アイテムの実体レベルと作品の関係
  • 一般的な関係（relatedLink）と構造化ノードのrelationTypeによる汎用的関係記述
  • 共通する名前はURI化して繋ぐ

22 全体・部分関係の記述

• シリーズ
  • 全集、文庫など（seriesTitleで表現されているもの）
  • 元の値がシリーズ名のみであってもURI化し、schema:isPartOfを用いて関連付ける
    • 多くの場合、シリーズや文庫の名前は一貫性がある（ように見える。表記が不統一な場合もあるが柔軟に対応する）
    • Webcat PlusはNDLの全国書誌とCiNiiのデータを統合しており、CiNii由来の上位シリーズIDを持つ
  • 
• コレクション
  • しばしば収蔵品はいくつかのコレクションとしてまとめられている
  • 同じくURI化してschema:isPartOfで関連付け
    • コレクションの扉や紹介ページURIにフラグメント識別子を加えれば実用的
  • コレクションにはschema:Collection型を付与（rdf:type）し、シリーズや単なるグループ化と区別
  • 例えば慶應オブジェクトハブにおけるコレクションとアイテムの資料グループ

23 全体・部分関係の記述：構造化と二層モデルの導入

• 掲載誌情報の記述
  • 
  • ①どの雑誌の②何巻何号の③何ページに掲載されているか
  • 雑誌巻号②を一つの出版物とし、雑誌①とpartOfで関連付ける
  • 記事を独立したアイテムとして②とpartOfで関連付け。さらに構造化してselectorで掲載ページ
• • 

24 アイテムと作品：上演の記述モデル

• 演劇作品とその上演
  • 早稲田演博演劇上演記録データベースは複数の上演アイテムが同一の作品を取り上げている
    • 上演は日時・場所を持つイベント（公演）だが、作品の表現形と考えても良いかもしれない
  • 上演と作品はschema:workPerformedで関連付ける
  • 
• 芝居作品、上演、番付
  • ARC番付ポータルはさらに番付（公演の宣伝刷り物）が複数の公演に結びつく
  • 番付と上演はschema:aboutで関連付け。さらに番付と作品もショートカットで結んでいる

25 （構想中）著作リストの作品と出版物

• 作品の掲載誌（初出）と書籍化
  • 著作リストは「作品」ごとに掲載誌（初出）、書籍化などの出版物を記述する
  • ここではFRBRの4階層ではなくBibframe型の3階層を用い、作品（Work）と出版物（Instance）をschema:workExampleで関係づける
  • 
  • さらに出版物の見本などの個別アイテム（Item）が蔵書にある場合は、これもschema:workExampleで関連付ける
    • アーカイブのDBとしては、蔵書リストにおいてアイテム→出版物のschema:exampleOfWorkとする方が扱いやすいかもしれない

26 Linked Dataでできることは

27 つながりを活かす

• データセット間の連携
  • データセット連携によるタスク補完
    • ひとつの目録で提供できる情報には限界が → 調べきれなかった情報を別のデータセットで調べる
  • リンクされるLODとして外部からの利用促進
• リンクするデータによる探索
  • セレンディピティ → 試してみるとそうお目にかかれるものではないが、LODクラウドを考えれば可能性はある
    • IFLA LRMも3.3 User Tasks Definitionsの説明で重要としている
  • むしろ同じポータル内でのリンクによるつながりで興味深い発見が
  • 

28 （構想中）注釈モデルによる引用からのリンク

• 引用を注釈モデルで記述する
  • 山崎正和『このアメリカ』第九章に、小泉八雲『心』（平井呈一訳）からの引用がある

  • …早いはなしが、日本の國では、ごく普通につかっている日用品などでも、まず長持ちをさせようという考えで作られているものは、めったにない。たとえば、旅の泊りに着くたびに、切れては履きかえるあのわらじというもの。…

  • Web Annotationモデルを応用して、注釈対象を書籍ページ、内容を引用文ノードとして表現
  • 引用を介して作品から作品（著者から著者）への探索ができる
  • 

29 識別子ハブを介した相互検索（統合クエリ）

• 利用する：自目録の識別子（典拠）で他のデータベースを検索
  • ジャパンサーチの典拠（chname）を用いて韓国国立中央図書館を検索する

  • SELECT ?s ?label ?kac WHERE {
        {SELECT ?kac {
            SERVICE <https://query.wikidata.org/sparql> {
                ?wd <http://www.wikidata.org/prop/direct/P6698> "山崎正和" ;
                    <http://www.wikidata.org/prop/direct-normalized/P5034> ?kac }
        }}
        {SERVICE <https://lod.nl.go.kr/sparql> {
            ?s rdfs:label ?label ;
                <http://purl.org/dc/terms/creator> ?kac
    }}}

    ▶
• 利用してもらう：目録の典拠の知識がなくても知っている識別子で検索
  • 韓国国立中央図書館のIDを用いてジャパンサーチを検索する

  • SELECT ?s ?label ?chname WHERE {
        ?s rdfs:label ?label ;
           schema:creator/owl:sameAs? ?chname .
        ?chname rdfs:isDefinedBy chname: ; owl:sameAs ?wd .
        {SELECT ?wd {
            SERVICE <https://query.wikidata.org/sparql> {
                ?wd <http://www.wikidata.org/prop/direct/P5034> "KAC200402504" }
    }}}

    ▶

30 充実そして活性化

• 典拠の出典や関連を示す
  • 典拠に収録する元となった文書などにリンクできれば、根拠を確かめることができる（典拠要素5.）
  • 関連情報や背景をLODリンクで提供でき、典拠の理解・解像度が高まる（典拠要素3.および4.）
    • 要素3.の識別に必要な情報は典拠が持つ方が使いやすいが、それ以上の追加情報はリンクとして利用者に提供
    • IFRA LRMのNomenの属性にReference sourceが加えられていることにも対応する
  • 
• さまざまな規模の典拠の連携
  • 各組織の名前マスターテーブル → 外部典拠とのリンクで典拠として整備
  • 地域、領域固有の名前を確実に典拠LOD化 → 得意分野を補完し合う典拠連携
    • デジタルアーカイブとして個別品目を公開するだけでなく典拠もセットに
    • 個別アイテムに「○○は江戸時代の～」とある詳細説明を典拠LODに。ぜひとも！
• 利用者としてのコンピュータ
  • AIキュレーターによる展覧会企画では、不正確なメタデータに起因するおかしな選択やキャプションも
  • 典拠とLODリンクを用いた明確なメタデータ
  • たとえば人間の理解力に頼る責任表示ではなく適切な構造化とリンクする典拠

31 まとめと課題

• 発見と集中を向上させるアクセスポイント
  • 典拠形アクセスポイントへのURI導入とLOD化
  • 識別子のハブを介した典拠の共有・再利用と多分野典拠の連携
  • 典拠情報の解像度と理解の向上
• 識別・選択のための正確な記述
  • 構造化ノードを利用した複雑さ（多重化値）の適切な分解と統合
  • 構造化による精密記述と単純プロパティによる使いやすさを両立させる二層モデル
• メタデータの拡張と繋がり
  • 全体・部分関係、作品とアイテムの関係などによる情報の多段階結合
  • 繋がったリンクをたどることによる探索と再発見。さらにリンクされるデータ
  • データとしてのメタデータ利活用。コンピュータもAIも利用者！
• 課題
  • 多様なメタデータの正規化／構造化作業の手間 → AIを利用できるか？
  • 作品の典拠の整備と関連付け
  • より多くの典拠／メタデータがLODとして繋がるように