はじめに
RDF（Resource Description Framework）でデータを扱う際、「RDFS（RDF Schema）」と「SHACL（Shapes Constraint Language）」という2つの仕組みが出てきます。どちらもプロパティやクラスの制約を定義できますが、目的も動作も全く異なります 。
この記事では、特に混乱しやすい以下の疑問に答えます：
rdfs:domain/rdfs:rangeと SHACL のsh:class/sh:datatypeは何が違うのか？- RDFS の range と異なる SHACL 制約を設定してもいいのか？
- range がクラス（
foaf:Person）なのに SHACL でデータ型（xsd:string）を指定するのは問題ないか？
1. RDFSとSHACLの根本的な違い
RDFS：推論（Inference）のため
RDFS は**「もしこのプロパティが使われたら、こういう知識が導き出せる」**という宣言です。
意味 :
ex:authorが使われたら、主語（subject）は自動的にex:Bookのメンバーと推論される- 目的語（object）は自動的に
ex:Personのメンバーと推論される
特徴 :
- ✅ 新しい知識を生成 する（推論エンジンが実行）
- ✅ Open World Assumption（世界は開かれている）
- ✅ エラーという概念はない
- ✅ 「もし使われたら、これも真である」という宣言
SHACL：検証（Validation）のため
SHACL は**「既存のデータがこのルールに従っているかチェック」**する制約です。
意味 : 「データはこのルールに従うべき」
特徴 :
- ✅ ルール違反を検出 する（検証エンジンが実行）
- ✅ Closed World Assumption的（ルールに明示されたものを検証）
- ✅ エラーレポートを生成
- ✅ 「データはこうあるべき」という制約
2. 両者の比較表
| 観点 | RDFS domain/range | SHACL property shape |
|---|---|---|
| 目的 | 意味定義・推論 | データ検証 |
| 動作 | 新しい知識を生成 | ルール違反を検出 |
| 哲学 | Open World | Closed World的 |
| タイミング | スキーマ設計時 | データ登録・検証時 |
| 実行主体 | 推論エンジン | 検証エンジン |
| 結果 | 推論されたトリプル | バリデーションレポート |
| 柔軟性 | より緩い | より厳密 |
3. 実践的な使い分け
パターン1：RDFS で意味を定義、SHACL で品質を保証
これが最も推奨される組み合わせ です。
パターン2：プロファイルごとに異なる制約
同じ語彙を、用途に応じて異なる制約で使えます。
4. よくある疑問Q&A
Q1: RDFS の range と異なる SHACL 制約を設定できますか？
A: はい、できますし、推奨される場合も多いです。
ただし、SHACL は range と同じか、より厳しい制約にすべき です。
✅ 推奨パターン：サブクラスで絞り込む
✅ 推奨パターン：リテラル型を具体化
⚠️ 避けるべきパターン：range より広くする
論理的に矛盾はしませんが、混乱を招きます。
Q2: range がクラスなのに SHACL でデータ型を指定するのは問題ですか？
A: はい、これは意味的な矛盾です。絶対に避けてください。
❌ 問題のある例
なぜ問題か :
rdfs:range foaf:Person: 値はfoaf:Personのインスタンス（URI参照 ）sh:datatype xsd:string: 値は文字列リテラル
この2つは型として互換性がありません ：
0
✅ 正しいパターン1：URI参照を使う
1
✅ 正しいパターン2：リテラルを使う
2
✅ 推奨パターン：両方提供する
3
Q3: 型カテゴリの整合性とは？
A: RDFS range と SHACL 制約は同じ「型カテゴリ」でなければなりません。
| rdfs:range | SHACL 制約 | 型カテゴリ | 評価 |
|---|---|---|---|
foaf:Person | sh:class foaf:Person | クラス ↔ クラス | ✅ 整合 |
foaf:Person | sh:class foaf:Agent | クラス ↔ クラス | ⚠️ より緩い |
foaf:Agent | sh:class foaf:Person | クラス ↔ クラス | ✅ より厳しい（推奨） |
foaf:Person | sh:datatype xsd:string | クラス ↔ データ型 | ❌ 矛盾 |
xsd:string | sh:datatype xsd:integer | データ型 ↔ データ型 | ❌ 矛盾 |
rdfs:Literal | sh:datatype xsd:string | データ型 ↔ データ型 | ✅ 具体化（推奨） |
5. 実際のアプリケーションでの活用例
ケース：メタデータ管理システム
4
6. まとめ：設計指針
語彙設計（RDFS）のポイント
- できるだけ一般的に定義 する（再利用性を高める）
- domain/range は柔軟に （将来の拡張を考慮）
- 意味的な関係を明示 （推論に使える情報を提供）
プロファイル設計（SHACL）のポイント
- 用途に応じて具体的な制約を設定 （データ品質を保証）
- RDFS range と同じか、より厳しい制約に （より緩くしない）
- 型カテゴリの整合性を保つ （クラス↔クラス、データ型↔データ型）
- 必須・任意、個数制限などを明確に （運用ルールを反映）
禁止事項
❌ RDFS がクラス（foaf:Person）なのに SHACL でデータ型（xsd:string）を指定
❌ RDFS がデータ型（xsd:string）なのに SHACL で別のデータ型（xsd:integer）を指定
❌ SHACL の制約を RDFS range より緩くする
推奨事項
✅ RDFS は汎用的に、SHACL は具体的に
✅ サブクラスやサブプロパティで絞り込む
✅ プロファイルごとに異なる制約を設定
✅ URI参照とリテラルは別プロパティで管理
7. さらに学ぶために
- RDF 1.1 Primer
- RDF Schema 1.1
- SHACL - Shapes Constraint Language
- SHACL Playground - SHACL制約を試せるオンラインツール