考える：RDFデータ設計での留意点

RDFのコア(1)：トリプルとグラフ

RDFはトリプルを集めたグラフ
- 自然文とおなじくRDF文も主語、述語、目的語（トリプル）で構成される
- RDFは主語と目的語のノードを述語で結ぶ有向ラベル付きグラフで表現される
さまざまな形の情報を共通の単純構造に
- 表もトリプルの組み合わせ（＝グラフ）で表現可能
- より複雑なネットワーク構造もグラフで表現できる
- 複雑な構造を単純なトリプルに分解し、また逆に元の構造を復元できる

RDFのコア(2)：URIと共通＝標準化

URIによる名前付け
- 主語、述語、目的語をURIで名前付けし、識別のスコープをグローバルに
- 組織や領域を超えた連携を可能にする
素材としての標準化
- プロパティと値をURIとして正規化＝同じものを常に同じ名前で扱う
- グラフを利用した構造正規化で情報を適切に整理する（後述）
- 単純なトリプルに分解することで素材としてアプリケーション処理が容易に
- 素材を標準手段（SPARQL、URI）で利用できることが重要

ジャパンサーチのRDF

RDF化の前の段階
- 連携元のデータ：表形式なら一定の構造正規化はされているが、値正規化はまちまち
- 連携フォーマット：基本プロパティ（関係名）の共通マッピング
連携フォーマットから利活用スキーマへ
- 構造の組み替え：標準モデルに翻訳する。基本的なマッピング
- 埋もれている構造の抽出：値の中に含まれる構造値を切り出す。規則化しにくく処理が複雑（後述）
- 値正規化：典拠と辞書を作りマッピングする。厄介だがやるべきことはストレート
- 型の付与：多様なデータセットの統一利用には必須。基準になる項目がないと大変

値と関係の設計(1)：単純値と構造化

共通の単純プロパティ
- 同じことを表現する述語は多数。著者、作者、creator…
- 領域ごとに異なるプロパティを共通化。Dublin CoreやSchema.orgの利用。連携フォーマットでもこれを実現
- 一方、単純化するだけでは情報が失われる
正規化と構造化記述
- 情報を構造化し、正規化した値と元の値をセットで記述する
- プロパティの違いも値の役割として構造化する
  - プロパティグラフの関係プロパティとして考えてもよい

値と関係の設計(2)：利用のバランス

メンタルモデルはフラット構造？
- 情報がどのような構造で記述されるかは、スキーマを知らないと分からない
- 作者はアイテムの直接プロパティ値か、構造化された記述の値か
- フラットな記述の想定（メンタルモデル）に対しデータ構造が異なるとうまく利用できない
ジャパンサーチの二層モデル
- 単純プロパティと構造化ノードを対で持つ
- タスクによる使い分け：発見タスクなら単純プロパティ、識別／選択タスクなら構造化ノードなど

検証の方法

安心して使えるデータの提供
- 型（rdf:type）、ラベル（rdfs:label）やアクセス情報のURLはかならずある
- 画像（schema:image）があれば必ずライセンス情報がある
- 期待する利用者／アプリケーションが混乱しないように
制約を形式的に表現して検証可能にする
- ShEx（Shape Expressions）：ノードの持つプロパティ制約をシェイプとして表現
  - ジャパンサーチの制約記述やWikidataのスキーマプロジェクトでも用いられている
  - Node.js上のShExツールshex.js（オンライン版）、Apache JenaのShExなどで検証できる
- ほかに制約自体もRDFで記述するSHACLなどがある
SPARQLによる検証
- SPARQLのFILTERやHAVINGを用いてグラフの制約を検証できる
- ShExやSHACLの実装の多くは内部的にSPARQLを生成して検証
- 表形式などの独自の制約ルールからSPARQLを生成して検証することも可能
- ```
#rdfs:labelが必須＝漏れているものがないかチェック（名前空間宣言略）
ASK FROM <target_graph> WHERE {
    ?s jps:sourceInfo ?source
    FILTER not exists {?s rdfs:label ?label}
}
```

悩む：RDFデータづくりの課題と対応

情報の多重化と飛び地

複数値の多重化：値の中に含まれる構造

一つのフィールドに複数値を持たせ、さらにそれぞれの値が名前と役割など複数の情報を持つ
アイテムによって区切り記号が異なったり、同じ記号が異なる意味で使われたり

[北畠親房著] ; 岩佐正校注 . 時枝誠記, 木藤才藏校注
渡辺一夫責任編集,More, Thomas, Sir, Saint,Erasmus, Desiderius,渡辺, 一夫,二宮, 敬,沢田, 昭夫,
大林組プロジェクトチーム,山崎/正和,小松/左京,加藤/秀俊,編集部,編集部,
ジンメル/著谷川徹三/訳

飯田清三氏談/岩井商店社長 岩井勝次郎氏談/阪急電鉄専務 上田寧氏談

飛び地：同じ情報が複数箇所に分かれる
- dc:creatorとdct:creatorでリテラル責任表示とURIが使い分けられている
- ```
<https://ndlsearch.ndl.go.jp/books/R100000136-I1970023484904708496#material>
    dc:creator "Yamazaki Masakazu ; translated by Barbara Sugihara" ;
    dct:creator 
        [ foaf:name "山崎, 正和" ], 
        [ foaf:name "Sugihara, Barbara" ]
```
- 利用者が対応関係を見つけるための仕組みが必要になる
- 構造化ノードなどを用いて関連情報をまとめるなど

埋め込まれた構造

目次に含まれる記事とタイトル、著者

目次: 
思ひつくまゝ（長谷川伸）
新しき批評の登場を望む（千葉亀雄）...

それぞれの記事を独立実体としてタイトル、著者を記述し、雑誌本体とhasPartで関連付ける

:Showa_magazine-100015103 a type:雑誌
    schema:hasPart 
        [ rdfs:label "思ひつくまゝ" ;
          schema:creator chname:長谷川伸 ], 
        [ rdfs:label "新しき批評の登場を望む" ;
          schema:creator chname:千葉亀雄 ]

章節構造の分離と階層化
- 古事類苑データベースの「歳時部十一　1　年始祝三　年玉　774ページ」の構造をグラフで記述

直接目的語と間接ノード

場所とそこにある寄与者実体
- 東京文化会館は東京・上野という場所にあるAgent型実体＝公演の主体ともなる
- 連携フォーマットでは「場所」と「上演主体」の値がいずれも東京文化会館
場所型寄与実体を間接ノードからのリンクで表現する
- 場所は本来「東京都台東区～」など → 構造化し東京文化会館をrdfs:seeAlsoで関連付ける

SPARQLの日本語検索

全文検索エンジンとの組み合わせ
- SPARQLはFILTER containsで日本語検索もできるが、異体字正規化は単独ではできない
- Fuseki、GraphDBなどはLuceneを外部エンジンとして異体字正規化も含めた検索が可能
- いずれもRDF登録時にrdfs:labelなどプロパティを指定し、特定の構文で呼び出す。次の例はFuseki
- ```
PREFIX text: <http://jena.apache.org/text#>
SELECT ?s ?score ?label WHERE {
    (?s ?score) text:query (rdfs:label "万国与地図") .
    ?s rdfs:label ?label .
}
```
- 異体字検索の一方、ノイズもある。また同じLucene利用でもFuseki、GraphDBでは異なる結果
  - 上例で"万国輿地図説"が検索できる一方、"万国往来"もヒットするなどノイズがあり、また日本語のトークン化の違いによりエンドポイントごとにヒット数も異なる
  - GraphDBはUnicode NFKCの範囲であるのに対しFusekiはより広い範囲を正規化するので、例えば後者では"小学生"で"小學生"もヒットするが前者ではヒットしない、など
  - 異体字正規化を含めた検索範囲の広さとトークンによるノイズはトレードオフとなる傾向がある
アプリケーション層＋プロパティ使い分け
- 検索アプリケーションがSPARQLを呼び出す形ならRDFの事前正規化を利用することもできる
- 例えばrdfs:labelとschema:nameを使い分け、後者に異体字正規化済み文字列をもたせるなど
  - アプリケーションからの検索時に、同じ正規化テーブルを使って文字列を変換
  - schema:nameの値をFILTER containsすれば異体字も含めてヒットする
  - 山崎正和アーカイブでは「世阿弥」で「世阿彌」も含めた検索をSPARQLベースで提供している
- この場合、rdfs:labelは識別／選択タスク、schema:nameは発見タスクを担うと考えることもできる

AIの時代に

メタデータはAIに任せればよい？
- AIで構造正規化も値正規化も（いずれは）できるかも → しかし任せ切りは危うく利用時に人間の確認が必要
- どの段階で人間が確認するか。データをRDF生成時に正規化すれば利用する際の負担は減る
- 現時点では原嘉寿子作「青の洞門」の公演が東京文化会館舞台芸術創造フェスティバル2002の一環として桂直久の演出により東京文化会館で行なわれた。のような文からのグラフ構築は難しい
  - 概ね妥当なモデルを生成するが、東京文化会館をOrganizationかつPlaceとして扱ってしまう

知識グラフとAI/LLM

自然文テキストや非構造化データの構造化、メタデータ構築は人手の介在が必要で高コスト
ここをAI/LLMが自動生成したり補助したりする利用法が盛んに研究されている

対象＼LLM利用法	LLM主導的（生成的）	LLM支援的（補完的）
オントロジー構築	内容から概念を抽出しクラスとプロパティを生成（トップダウン的創発）	既存KG／語彙を参照し、クラス・関係構造を整理・マッピング（ボトムアップ整合）
知識（インスタンス）抽出	スキーマを前提とせず、情報をトリプル構造に変換（schema-free抽出）	既存スキーマ（や補助的ルール）を参照し、抽出トリプルを正規化・補正（schema-based補正）

最近（2025年）の研究事例には、たとえばLLM主導型のオントロジー自動構築やトリプル抽出性能の評価、応用的なLLM支援型として社内知識の活用を支援する知識グラフ自動生成などがある

使う：応用素材としてのRDF

ウェブアプリケーションでの利用

RDFの利点はどのデータも標準手法で利用できること
- クエリ結果はJSONやCSVなどで得られるので、さまざまなウェブアプリケーションで利用可能
- ```
SELECT ?prfc (count(?cho) as ?count) WHERE{
    ?cho a type:建築 ;
        schema:spatial ?prfc .
} GROUP BY ?prfc
```
- 結果はグラフなどの視覚化も容易。緯度経度や時間情報があれば地図や年表での表示なども可能
- 一般的APIでもこれらは可能だが、RDFなら標準クエリ言語SPARQLでどこからでも取得できる

グラフ階層の探索

プロパティパスを用いた階層の一括取得
- 件名の上位語、下位語、関連語を一括して調べることができる
- ```
?sh rdfs:label "量子力学"; skos:broader* ?s
```
- 上位語の連鎖だけ（?sの値のみ）でなくSPOの表として取り出す＝前述の通りアプリケーションで容易に利用可
- ```
SELECT ?s ?p ?o WHERE {
    ?sh rdfs:label "量子力学"; skos:broader* ?s
    BIND(skos:broader as ?p) ?s ?p ?o
}
```

NDLSHの件名階層グラフ

CONSTRUCTでSPOの表を階層構造のグラフとして再構築する

CONSTRUCT {
    ?s ?p ?o
} WHERE {
    ?sh rdfs:label "量子力学".
    { ?sh skos:broader* ?s BIND(skos:broader as ?p) } UNION
    { ?sh skos:narrower* ?s BIND(skos:narrower as ?p) }
    ?s ?p ?o
}

RDFグラフを扱うアプリケーションで汎用的に利用できる

異なるデータ種別の連携

山崎正和アーカイブの資料種別
- さまざまな種類の情報をグラフとして繋いでいくのがRDFの真骨頂
- 作品から蔵書に至るFRBR階層的な情報に加え、上演や手帳記述などのイベント型情報も
- 蔵書データはISBNからNDLサーチを検索してRDFを取得 → 名前正規化などの上でRDF化
- 利活用スキーマをベースに、書誌（体現形）だけでなく蔵書（アイテム）や著作、イベントも記述する用語を追加

デジタルアーカイブと注釈

デジタル化と書き込みの注釈化
- 蔵書のうち書込み／付箋のあるページを選んでデジタル化
- 傍線や書込みの一部を試験的にウェブ注釈モデルで記述しIIIFビューアで表示
書き込みによる蔵書から著作へ
- 著作での引用もウェブ注釈モデルで記述し、蔵書から作品へのつながりを表現

書誌からバーチャル書棚へ

蔵書の書誌データと保存情報で書棚の収録書をリスト化
- 蔵書がどのような本と隣り合っているかなどからも発見がある
- NC213
- 蔵書データの持つ架蔵書棚（contentLocation）プロパティ値を用いて1棚分の書誌データを抽出
- タイトル、著者、分類からリスト要素を作り、棚内順序（position）プロパティに従ってソート
書誌データを利用してスタイルを設定
- materialExtentの情報から高さ、厚さをスタイルシートで設定
  - 多重化されているが、概ね275p ; 20cmのような規則＝アプリケーション処理可能（例外には悩む）
  - ```
  791, 80p 図31枚 地図48p ; 28cm
  6, 48, 38, 4, 104p, 図版 [2] 枚23cm
  335, 46p ; 20cm + 11p
  iv, 222 p. illus., ports., map, geneal. table. 22 cm
```
- さらに十進分類に基づき色分け。また上置きなどの配置を動的に調整

RDFと知識グラフ分析

KGE (Knowledge Graph Embedding)
- RDFなどの知識グラフは複雑な構造になり把握しにくい
- 知識グラフの情報を機械学習で低次元ベクトル空間に埋め込む
- 意味的な情報を保持しながらデータの視覚化や解釈を容易にする
  - たとえばWikidata:Embedding ProjectのWikidata Vector Database（まだ日本語は弱い）
- リンク予測を用いて欠落したデータを補完（たとえばtemporalがないアイテムの年代を推定）
ジャパンサーチRDFでKGEを試す
- 全体の学習は高コスト → 1つのデータセットをPyKEENで学習
  - ここでは埼玉県立近代美術館収蔵作品の単純プロパティのみを材料に
- 学習結果からコサイン距離を用いて著者の近傍関係をグラフ化

参照先

参照したリソース
1. Shape Expressions (ShEx) 2.1 Primer, 2019-10-08, Shape Expressions Community Group final report
  <https://shex.io/shex-primer/>
2. ジャパンサーチの制約記述
  <https://jpsearch.go.jp/static/developer/jps.shex>
3. Wikidata:WikiProject Schemas
  <https://www.wikidata.org/wiki/Wikidata:WikiProject_Schemas>
4. shex.js: shex.js javascript package
  <https://github.com/shexjs/shex.js>
5. ShEx2 - Simple Online Validator (ジャパンサーチのテストShEx付き）
  <https://shex.io/webapps/shex.js/doc/shex-simple.html?manifestURL=https://www.kanzaki.com/works/2025/pub/jps-shex-manifest.json>
6. Apache Jena ShEx Documentation
  <https://jena.apache.org/documentation/shex/>
7. Shapes Constraint Language (SHACL)
  <https://www.w3.org/TR/shacl/>
8. Apache Jena Fuseki - SPARQL 1.1 server
  <https://jena.apache.org/documentation/fuseki2/index.html>
9. GraphDB - Semantic Graph Database
  <https://graphdb.ontotext.com/>
10. Apache Lucene - Ultra-fast Search Library
  <https://lucene.apache.org/>
11. 大規模言語モデルを用いたオントロジー自動構築のためのゼロショット・プロンプトの比較と基礎的評価, by 古崎晃司, et al., 2025, 人工知能学会全国大会論文集 (第39回)
  <https://doi.org/10.11517/pjsai.JSAI2025.0_3P4OS46b04>
12. 大規模言語モデルのZero-Shotトリプル抽出性能の評価, by 乙村浩太郎, et al., 2025, 言語処理学会第31回年次大会
  <https://www.anlp.jp/proceedings/annual_meeting/2025/#P6-16>
13. 社内知識の活用を支援する知識グラフ自動生成, by 福田悠貴, et al., 2025, 人工知能学会第二種研究会資料
  <https://doi.org/10.11517/jsaisigtwo.2024.SWO-064_05>
14. 山崎正和アーカイブ
  <https://archive.yamazaki-masakazu.jp/>
15. Web Annotation Data Model, 2017-02-23, W3C Recommendation
  <https://www.w3.org/TR/annotation-model/>
16. 蔵書から作品へ：山崎正和アーカイブギャラリー
  <https://archive.yamazaki-masakazu.jp/gallery/annotation>
17. Wikidata:Embedding Project
  <https://www.wikidata.org/wiki/Wikidata:Embedding_Project>
18. Wikidata Vector Database
  <https://wd-vectordb.wmcloud.org/>
19. PyKEEN documentation
  <https://pykeen.readthedocs.io/>

RDF再訪：設計、課題、そして応用

考える：RDFデータ設計での留意点

RDFのコア(1)：トリプルとグラフ

RDFのコア(2)：URIと共通＝標準化

ジャパンサーチのRDF

値と関係の設計(1)：単純値と構造化

値と関係の設計(2)：利用のバランス

検証の方法

悩む：RDFデータづくりの課題と対応

情報の多重化と飛び地

埋め込まれた構造

直接目的語と間接ノード

SPARQLの日本語検索

AIの時代に

使う：応用素材としてのRDF

ウェブアプリケーションでの利用

グラフ階層の探索

異なるデータ種別の連携

デジタルアーカイブと注釈

書誌からバーチャル書棚へ

RDFと知識グラフ分析

参照先