1. 序論：歴史の反響と「10日間の萌芽」

1.1 背景と目的

本報告書は、masanork氏によって提案された「Semantic Resource Network (SRN)」およびその実装形態である「Sorane（空音）」プロジェクトに対し、過去のWeb標準化の歴史——特にXMLベースのSemantic WebとSOAP（Simple Object Access Protocol）の失敗——を踏まえた批判的分析を行うものである。

ユーザーは、SRNを「この10日くらいで温めたもので非常に萌芽的なコンセプト」と位置づけている。しかし、技術史を紐解けば、短期間で構想されたプロトコルやアーキテクチャが、その後の数十年にわたり業界を支配、あるいは停滞させる「技術的負債」となった例は枚挙にいとまがない。JavaScriptがBrendan Eichによってわずか10日間で設計された事実は、その柔軟性がWebを爆発的に普及させた一方で、動的型付けやスコープ管理の曖昧さが長きにわたり大規模開発の足枷となった二面性を示唆している。

SRNが掲げる「Semantic（意味論的）」、「Resource（資源）」、「Network（ネットワーク）」という3つの単語は、いずれも2000年代初頭のWeb技術コミュニティで最も手垢にまみれ、かつ多くの失望を生んだ用語である。これらを2025年の現在において再定義しようとする試みは、極めて野心的であると同時に、過去の失敗パターン（アンチパターン）を無意識に踏襲する高いリスクを孕んでいる。

本報告書の目的は、SRNの構想——具体的には、Web/A（Web Authentication）、L2E（Layer 2 Encryption）、WASM（WebAssembly）、そしてRustによる実装エコシステム——を、過去の「巨大な失敗」との比較において検証することにある。なぜSOAPはRESTに敗北したのか？ なぜSemantic Webは「Web 3.0」の夢として語られながら、実用的なインフラとして定着しなかったのか？ これらの問いに対する冷徹な分析なしに、SRNの成功はおぼつかない。

1.2 分析の視点とスコープ

本分析では、masanork氏の公開情報（GitHubリポジトリ、ブログ記事タイトル、過去の登壇資料）から推察されるSRNの技術スタック（Identity, Privacy, Rust, WASM）を前提としつつ、以下の3つの次元で批判的検討を行う。

  1. 複雑性の経済学 (Economics of Complexity):
    SOAPが陥った「WS-*（WS-デス・スター）」のような仕様の肥大化を、SRNはいかにして回避するか？ 特にL2Eのような暗号化レイヤーの追加は、システム全体の複雑性を指数関数的に増大させるリスクがある。
  2. 意味の記述と解決 (Semantic Resolution):
    Semantic Webが直面した「オントロジー構築のコスト」と「論理推論の計算爆発」に対し、SRNは生成AI（LLM）やベクトル空間モデルといった現代的なアプローチでどう対抗するか？
  3. 開発者体験と普及戦略 (Developer Experience & Adoption):
    JSONとRESTがXMLとSOAPを駆逐した最大の要因は「人間可読性」と「参入障壁の低さ」であった。バイナリ指向（WASM）や強固なセキュリティ（Web/A）を志向するSRNは、この歴史的教訓とどう折り合いをつけるか？

---

2. 第1部：死体解剖 —— XML/SOAPの栄光と惨状

SRNの設計を論じる前に、我々はまず「なぜ先行者たちが死に絶えたのか」を詳細に検分しなければならない。SOAPとXML Semantic Webの失敗は、単なる技術的な優劣ではなく、Webという分散システムの「生態系」に対する誤解に起因している。

2.1 SOAP (Simple Object Access Protocol) の逆説

SOAPは、その名称に "Simple" を冠していたにもかかわらず、Web史上最も複雑で難解なプロトコルの一つとして歴史に名を刻むこととなった1。Microsoft、IBMなどのエンタープライズ巨頭が主導したこの規格は、企業の基幹システムをインターネット経由で接続するという壮大なビジョンを持っていたが、その設計思想には致命的な欠陥があった。

2.1.1 "WS-Deathstar"：仕様の爆発的肥大化

SOAPの最大の罪は、単一のプロトコルで完結せず、機能不足を補うために無数の拡張仕様（WS-*）を生み出したことにある。
WS-Security、WS-Addressing、WS-ReliableMessaging、WS-AtomicTransaction、WS-Policy……これらは相互に依存し合い、実装者に巨大な負担を強いた。業界ではこれを、映画『スター・ウォーズ』に登場する未完の巨大要塞になぞらえて「WS-Deathstar」と呼んだ。

仕様名 目的 失敗の要因
WS-Security メッセージレベルの署名・暗号化 ヘッダー構造が極めて複雑で、正規化（Canonicalization）処理でのバグが多発。相互運用性が著しく低かった2。
WS-AtomicTransaction 分散トランザクション (2PC) Webのような不安定なネットワーク上で、ACID特性（原子性・一貫性）を保証しようとした無謀な試み。CAP定理を無視した設計。
WS-ReliableMessaging 到達保証・順序保証 TCP/IP層ですでに行われていることをアプリケーション層で再実装する「レイヤー違反」。ミドルウェアの肥大化を招いた3。

SRNへの教訓:
SRNにおいて、もしWeb/AやL2Eといったコンポーネントが、それぞれ独立した複雑な仕様を持ち、それらを全て実装しなければネットワークに参加できない「オール・オア・ナッシング」の構造になっているならば、それはSOAPの轍を踏んでいる。プロトコルは「積み木（Composable）」であるべきだが、SOAPのそれは「ジェンガ」であり、一つ抜けば崩壊する密結合であった。

2.1.2 「エンベロープ」という名の密室

SOAPは、XMLメッセージを「エンベロープ（封筒）」、「ヘッダー」、「ボディ」に分割する構造を採用した4。これは郵便システムを模したメタファーであったが、Webのアーキテクチャスタイルとは決定的に相性が悪かった。
Web（HTTP）は、リソース（URL）に対してメソッド（GET/POST）を適用するスタイルだが、SOAPは全ての操作をHTTP POSTの中に隠蔽し、URLは単なる「エンドポイント（窓口）」に過ぎなくなった。これにより、Webのキャッシュ機構、プロキシ、ファイアウォールといった既存のインフラが機能しなくなったのである。
SRNへの批判的視点:
SRNが「L2E（Layer 2 Encryption）」によって通信内容を独自にカプセル化しようとしている点は、SOAPのエンベロープ構造と酷似している。もしL2Eが、HTTPヘッダーやURLの意味を隠蔽し、中身をブラックボックス化するものであれば、それは「Webの上でWebを再発明する」行為であり、パフォーマンスとデバッグ容易性を犠牲にする結果となるだろう。

2.1.3 型付けの強迫観念とWSDLの呪い

SOAPと対になるWSDL（Web Services Description Language）は、インターフェース記述言語として機能した。これはRustのような静的型付け言語を好むエンジニア（masanork氏のプロフィール5から推測される属性）にとっては理想的に見えるかもしれない。
しかし、分散システムにおける厳密な型契約（Contract）は、システムの進化を阻害した。サーバー側で型定義を少し変更（例：intからlongへ）しただけで、クライアント側のスタブ生成コードがコンパイルエラーを起こし、システム全体が停止する「密結合」を引き起こしたのである6。
一方、REST/JSONが勝利したのは、JSONがスキーマレスであり、未知のフィールドを無視する「寛容な読者（Tolerant Reader）」パターンを自然と促したからである。
SRNがRust/WASMベースである場合、この「型の厳密さ」がネットワークの柔軟性を殺さないよう、極めて慎重な設計が求められる。

---

3. 第2部：Semantic Webの亡霊 —— 「意味」を定義することの不可能性

次に、SRNの名称に含まれる「Semantic」の系譜を検証する。Tim Berners-Leeが提唱したSemantic Webは、HTMLという「表示のためのWeb」を、RDF（Resource Description Framework）による「データのWeb」へと進化させる構想であった。しかし、その夢は実質的に破綻した。

3.1 「亀の塔 (Turtles all the way up)」と記述の無限後退

Clay Shirkyは2001年のエッセイで、Semantic Webのアプローチを痛烈に批判した1。
「意味」とは絶対的なものではなく、文脈依存である。ある人にとっての「癌」は病気であり、生物学者にとっては細胞増殖のメカニズムであり、保険会社にとっては支払いリスクである。これら全ての文脈を単一のオントロジーで記述しようとすると、メタデータを記述するためのメタデータ、さらにそのためのメタデータ……という無限後退（Turtles all the way up）に陥る。
SRNへの示唆:
もしSRNが「リソースの真の意味を記述する単一のネットワーク」を目指しているなら、それは不可能な挑戦である。masanork氏のブログタイトルにある「Sorane（空音）」が、万物を包括するような抽象概念を指しているならば警戒が必要だ。成功するシステムは、意味を定義するのではなく、意味の「ゆらぎ」を許容するものである。

3.2 論理学（Logics）の敗北と統計学（Statistics）の勝利

Semantic Webの中核技術であるOWL（Web Ontology Language）は、記述論理（Description Logic）に基づいていた。これは「AはBである」「BはCではない」といった厳密な命題論理の積み重ねである。
しかし、現実世界は矛盾に満ちている。Web上には「地球は丸い」というデータと「地球は平らだ」というデータが並存している。論理ベースのシステム（推論エンジン）は、矛盾（Inconsistency）を含むデータを入力されると破綻するか、あるいは「全ての命題が真となる」爆発（Ex Falso Quodlibet）を起こす7。
SRNへの警告:
2025年の現在、意味処理の主役は「論理」から「統計（確率）」へと移行している。ChatGPTに代表されるLLMは、オントロジーを持たないが、膨大なテキストデータの共起確率から「意味のようなもの」を創発させている。
SRNが旧来のRDFトリプルストアのような「正解のあるデータベース」を構築しようとしているなら、それは時代錯誤である。むしろ、ベクトルデータベース（Vector Store）のように、曖昧さを数値（距離）として扱える基盤が必要である。

3.3 RDF/XMLの構文的悪夢と開発者体験の欠如

Semantic Webが普及しなかった最大の要因の一つは、その主要な記述形式であったRDF/XMLの可読性の低さにある8。
XMLの冗長なタグ、名前空間（xmlns）の複雑さ、グラフ構造を木構造（XML）に無理やりマッピングしたことによる不自然なネスト……これらは開発者の精神を摩耗させた。
対照的に、JSONは「単なるキーと値のペア」であり、リストは単なる配列であった。JSON-LD（JSON for Linking Data）が登場して初めて、Linked Dataの概念がGoogleやSchema.orgを通じて一般に普及し始めた事実は、**「開発者体験（DX）が正しさに勝る」**という冷酷な現実を示している9。
SRNの「Sorane」におけるデータ形式:
SRNがどのようなデータ形式を採用するかは不明だが、もし独自のバイナリ形式や、人間が手書きできない複雑な設定ファイル（TOMLやYAMLであっても、構造が複雑なら同じことだ）を要求するなら、普及のハードルは極めて高くなる。

---

4. 第3部：SRN & Sorane —— Web/A・L2E・WASMによる再構築の解剖

ここからは、masanork氏の断片的な情報（GitHub、ブログタイトル11）に基づき、SRNの具体的なアーキテクチャを推測・復元し、現代的な視点から批判的分析を加える。

4.1 "Sorane" (空音) とSRNのアーキテクチャ推論

ブログタイトル「From GlyphPicker to SSG sorane」13や「srn:空音の由来とWeb/Aの契機」11から推察するに、SRNの実装形態である「Sorane」は、単なる静的サイトジェネレーター（SSG）の枠を超え、分散型のリソース配信・認証ネットワークへと進化しようとしている。

想定されるSRNの構成要素：

  1. Resource (WASM modules): 静的なHTML/JSONだけでなく、実行可能なコード（WASM）自体をリソースとして扱う。
  2. Identity (Web/A & DID): WebAuthnや分散ID（DID）を用いた、パスワードレスかつ暗号学的に検証可能な本人確認。
  3. Transport (L2E): Layer 2 Encryption。HTTP/TLSの上（あるいは代替）として機能する、アプリケーション層でのエンドツーエンド暗号化。

この構成は、Web 3.0（ブロックチェーン的な意味での）やIPFS、Solidプロジェクトに近いが、Rust/WASM中心のエコシステムである点が特徴的だ。

4.2 L2E (Layer 2 Encryption) の功罪：中間ボックスとの戦争

「L2E」という概念は、SRNにおいて最も野心的かつ危険な賭けである。
通常のHTTPS（TLS）は、クライアントとサーバー間の通信経路を暗号化するが、サーバー上ではデータは平文に戻る（TLS終端）。しかし、L2Eが「アプリケーション層での暗号化（Application-Layer Encryption）」を指すなら、データはサーバー上でも暗号化されたままであり、最終的な受信者（User AgentやWASMランタイム）だけが復号できる。
批判：キャッシュと可視性の喪失
RESTアーキテクチャの成功要因の一つは、「可視性（Visibility）」と「キャッシュ可能性（Cacheability）」である。URLを見ればリソースが特定でき、HTTPヘッダーを見ればキャッシュ制御ができる。
しかし、L2Eによってペイロードが完全に不透明なblob（バイナリ塊）になると、CDN（Content Delivery Network）やISPのキャッシュサーバーは機能しなくなる。
SOAPもまた、HTTP POSTの中にXMLを隠蔽したことでキャッシュを無効化し、パフォーマンス問題に苦しんだ。SRNがL2Eを強制すれば、Webの最大の武器である「スケーラビリティ」を自ら捨てることになる。
対策の提言:
L2Eを採用するならば、ヘッダー情報は平文（あるいは部分的な開示）とし、ルーティングやキャッシングに必要なメタデータは露出させる「Onion Routing」的なアプローチか、HTTP標準の Vary ヘッダー等を巧みに利用する設計が必須となる。

4.3 Web/A (Web Authentication) と「認証の壁」

ブログ記事「srn:空音の由来とWeb/Aの契機」11は、SRNが認証（Authn）をコア機能として統合していることを示唆している。masanork氏はデジタル庁やマイナンバー制度に関連するIdentityの専門家でもあり14、ここには強力なセキュリティ設計が施されているはずだ。

批判：オープン性とのトレードオフ
Webが成功したのは、基本が「パブリック」であり、認証が「オプション」だったからだ。リンクをクリックすれば誰でも見られる。
しかし、SRNが「すべてのリソースアクセスにWeb/Aによる署名検証を求める」ような設計（ゼロトラストの極致）になっていると、それは「Web」ではなく「巨大なVPN」あるいは「イントラネット」になってしまう。
Semantic Webの文脈で言えば、「Linked Data」はオープンデータであることが前提だった。認証の壁が高すぎると、クローラーやAIエージェントがデータを収集できず、ネットワーク効果が働かない。
SRNへの問い:
SRNは「Googleにインデックスされること」を拒絶するのか？ それとも、パブリックな領域とプライベートな領域（Sorane）をシームレスに繋ぐ仕組みがあるのか？ Identityの専門家としてのmasanork氏の手腕が問われるが、過剰なセキュリティは往々にして利便性を殺す（Security-Usability Trade-off）。

4.4 WASM (WebAssembly) と「ブラックボックス化する意味」

SRNにおいてリソースがWASMモジュールとして提供される場合、新たな「意味論的」課題が発生する。
HTMLやXML、JSONはテキストであり、人間が読んで意味を理解できる（Human-readable）。
しかし、WASMはバイナリ形式の命令列であり、逆アセンブルしても元のロジックやデータの意味を理解することは極めて困難である。
批判：View Sourceの死
Webの発展を支えた文化の一つに「View Source（ソースを表示）」がある。他人のサイトのHTMLを見て学び、改良する文化だ。
SRNがリソースをWASM化し、さらにL2Eで暗号化する場合、それは**「完全に不透明なWeb」**の誕生を意味する。検索エンジンはどうやってWASMの中身をインデックスするのか？ セマンティックな検索はどう実現されるのか？
もしWASMモジュールに付随して「マニフェスト（JSON-LD等）」を用意し、そこにメタデータを書くというアプローチ（WSDLの再来）を採るなら、前述の「メタデータと実体の乖離（嘘のメタデータ）」問題が再燃する。

---

5. 第4部：現代における「意味論」の再定義 —— ロジックからベクトルへ

SRNが「Semantic」を標榜する以上、2010年代のSemantic Webの失敗を乗り越える新しいアプローチが必要である。その鍵は、生成AI（Generative AI）とベクトル検索（Vector Search）にある。

5.1 生成AI時代のメタデータ管理

かつてのSemantic Webでは、人間が手動でRDFタグを付けたり、複雑なNLPパイプラインでエンティティ抽出を行う必要があった15。これはコストが高すぎた。
しかし現在は、LLMにテキストや画像を投げれば、高精度なメタデータ（JSON-LD）を自動生成できる。
SRNは、人間がメタデータを管理するのではなく、**「AIがバックグラウンドで勝手に意味付けを行う」**アーキテクチャを前提とすべきである。
Soraneへの提言:
「Sorane」がSSG（Static Site Generator）であるなら、ビルドプロセスにおいてLLMを呼び出し、コンテンツから自動的にベクトル埋め込み（Embeddings）を生成し、それをサイドカーとしてリソースに添付する仕組みを標準搭載すべきだ。これにより、ユーザーは意識することなくSemantic Resource Networkに参加できる。

5.2 オントロジーの動的解決 (Dynamic Ontology Resolution)

Semantic Webの失敗の一つは「共通オントロジーの合意形成」に時間がかかりすぎたことだ。
SRNでは、共通のオントロジーを強制すべきではない。
Aさんが「Book」というスキーマを使い、Bさんが「Shoseki」というスキーマを使っても、検索時や結合時にLLMが「Book ≈ Shoseki」であると推論し、動的にマッピングを行えばよい。
これを**「Late-binding Semantics（遅延結合意味論）」**と呼ぶことができる。SOAP/WSDLの「Early-binding（事前結合）」の対極にあるこのアプローチこそが、現代の分散システムに求められる柔軟性である。

---

6. 第5部：SRNへの戦略的提言とロードマップ

以上の批判的分析を踏まえ、SRN (Sorane) が「XML/SOAPの惨状」を回避し、次世代のWebインフラとして機能するための具体的な戦略を提言する。

6.1 「Worse is Better」の受容：プロトコルを太らせるな

Richard P. Gabrielの「Worse is Better（悪いほうが良い）」哲学1を再評価せよ。

  • 正しさ（Correctness）よりも単純さ（Simplicity）を優先する。
  • 完全性（Completeness）よりも実装のしやすさを優先する。

L2EやWeb/Aの仕様を完璧に固めてからリリースするのではなく、まずは「HTTP + JSON + 署名」だけのミニマルな実装でエコシステムを立ち上げるべきだ。複雑な機能はオプション（Extension）として切り出し、コアプロトコルは極限まで薄く保つこと。SOAPの失敗は、コア（Envelope）に複雑な処理（Header processing）を詰め込みすぎたことにある。

6.2 エコシステムとしての設計：Rust/WASMの強みを活かす

masanork氏の強みであるRust/WASMのエコシステムを活かす戦略は正しい。
しかし、それを「プロトコル」として強制するのではなく、「リファレンス実装」として提供すべきだ。

  • tfrv/tsfrvのようなツールの拡充: ユーザーはプロトコルを使いたいのではなく、便利なツールを使いたいのだ。SRNに対応した高速なビューア、エディタ、検索エンジンをRustで開発し、その利便性によってSRNの普及を牽引する（Product-led Growth）。
  • WASMによる「ポータブルな意味解析器」: リソース（データ）と共に、そのデータを解析・表示するためのWASMコードを配布する。これにより、クライアント環境に依存せず、常に正しい「意味」を再現できる。これはJava Appletの夢の再来だが、WASMの安全性と軽量さがあれば実現可能かもしれない。

6.3 Identity First, but Privacy Preserving

SRNの核心がIdentity（Web/A）にあるなら、W3CのDID（Decentralized Identifiers）やVerifiable Credentials（VC）との完全な互換性を維持すべきである。
しかし、ここでも「XML署名の悪夢」を避けるため、JSON Web Token (JWT) やCWT (CBOR Web Token) といった、開発者に馴染みのある軽量フォーマットを採用すること。
また、L2Eの暗号化においては、完全な秘匿化だけでなく、ゼロ知識証明（Zero-Knowledge Proofs）を用いた「中身を見せずに正当性を証明する」アプローチを検討すべきだ。これにより、中間ボックス（キャッシュ等）に対して「データの正当性」だけを検証させ、中身は見せないという新しいキャッシュモデルが構築できる可能性がある。

---

7. 結論：SRNが「次のSOAP」にならないために

masanork氏の「Semantic Resource Network (SRN)」および「Sorane」は、その名称から過去の失敗の亡霊を呼び起こすが、Rust、WASM、Web/A、L2Eといった要素技術の選択は、現代のWebが抱える課題（プライバシー、パフォーマンス、信頼性）に対する正当なアプローチである。

しかし、歴史は残酷なほど繰り返す。
かつてSOAPが「企業間連携の決定版」を目指して複雑さの海に沈んだように、SRNもまた「究極のプライバシーと意味のネットワーク」を目指す過程で、過剰なエンジニアリング（Over-engineering）の罠に陥る危険性が極めて高い。
SRNが成功するための条件は、以下の3点に集約される：

  1. 脱・完全主義: 厳密なオントロジーや完全な暗号化を初期要件とせず、既存のWeb（HTML/HTTP/JSON）との妥協点を探ること。
  2. 脱・論理偏重: 意味の解決を固定的なロジックではなく、統計的・確率的アプローチ（AI）に委ねる柔軟なアーキテクチャを採用すること。
  3. 開発者中心主義 (DX First): 高尚な思想よりも、npm install srn あるいは cargo install sorane で即座に動き、console.log で中身が見えるような、手触りの良いツールチェーンを提供すること。

「萌芽的なコンセプト」である今こそ、削ぎ落とせる複雑さは全て削ぎ落とす勇気が必要である。SRNが、過去の「Semantic Web」の墓標の上に築かれる新たなバベルの塔ではなく、実用的で堅牢な「空の音（Sorane）」としてWeb全体に響き渡ることを期待する。

---

付録：技術比較マトリクス (SOAP vs REST vs SRN想定)

比較項目 SOAP (Legacy) REST (Current Standard) SRN / Sorane (Proposed) 評価・リスク
通信プロトコル HTTP, SMTP, TCP等（トランスポート非依存） HTTP/HTTPS (HTTPセマンティクスに依存) HTTP/QUIC + L2E L2Eによるカプセル化がHTTPのメリット（キャッシュ等）を阻害するリスク大。
データ形式 XML (厳密なスキーマ) JSON, HTML, XML (柔軟) WASM, Binary, Rust structs? バイナリ化による可読性の低下。デバッグ困難。
状態管理 Stateful (WS-Context等で管理) Stateless (HATEOAS) Identity-bound State? 認証コンテキストの持ち回りが複雑化する懸念。
セキュリティ WS-Security (ヘッダーでの署名・暗号化) TLS (Transport層) + OAuth2 Web/A + L2E アプリケーション層での暗号化は強力だが実装難易度が高い。
意味記述 WSDL, UDDI OpenAPI (Swagger), Human readable docs Sorane Metadata / AI Vectors? AI活用なら勝ち筋あり。手動メタデータなら敗北必至。
結合度 密結合 (Tight Coupling) 疎結合 (Loose Coupling) Code Coupling (WASM)? インターフェース変更への耐性が鍵。

本表からも明らかなように、SRNはSOAPと同様の「高機能・高複雑性」の領域に踏み込もうとしている。RESTが勝ち取った「シンプルさ」の領域に、いかにして高度な機能を「シンプルに見せて」統合できるかが、SRNの成否を分ける分水嶺となるだろう。

引用文献

  1. Too Much Semantics is Harmful in Information Technology - Daniel Lemire's blog, 12月 31, 2025にアクセス、 https://lemire.me/blog/2007/01/14/too-much-semantics-is-harmful-in-information-technology/
  2. SOAP vs. REST: Understanding the Differences - API7.ai, 12月 31, 2025にアクセス、 https://api7.ai/learning-center/api-101/soap-vs-rest-differences
  3. Soap vs Rest (Why comparing them is a nonsense) - OctoPerf - Load Testing Blog, 12月 31, 2025にアクセス、 https://blog.octoperf.com/soap-vs-rest-why-comparing-them-is-a-nonsense/
  4. SOAP vs. REST: Solving the Testing Challenges of Each - Parasoft, 12月 31, 2025にアクセス、 https://www.parasoft.com/blog/soap-vs-rest-solving-the-testing-challenges-of-each/
  5. 1月 1, 1970にアクセス、 https://github.com/masanork?tab=repositories&q=&type=&language=&sort=updated
  6. Error Handling in SOAP to REST: Best Practices - Blog, 12月 31, 2025にアクセス、 https://blog.dreamfactory.com/error-handling-in-soap-to-rest-best-practices
  7. The Semantic Web and why it failed. - The Data Blog, 12月 31, 2025にアクセス、 https://data-mining.philippe-fournier-viger.com/the-semantic-web-and-why-it-failed/
  8. RDF AND JSON-LD UseCases - Data on the Web Best Practices - W3C, 12月 31, 2025にアクセス、 https://www.w3.org/2013/dwbp/wiki/RDF_AND_JSON-LD_UseCases
  9. Having Your Cake and Eating It Too: JSON-LD as an RDF serialization format, 12月 31, 2025にアクセス、 https://biss.pensoft.net/article/74266/
  10. Intro to How Structured Data Markup Works | Google Search Central | Documentation, 12月 31, 2025にアクセス、 https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
  11. masanork's developer notes, 12月 31, 2025にアクセス、 https://masanork.github.io/
  12. 1月 1, 1970にアクセス、 https://masanork.github.io/2025-12-23-srn.html
  13. 1月 1, 1970にアクセス、 https://masanork.github.io/2023-08-26-sorane.html
  14. masanork (Masanori Kusunoki) · GitHub, 12月 31, 2025にアクセス、 https://github.com/masanork
  15. Enabling a Knowledge Supply Chain: From Content Resources to Ontologies - CEUR-WS.org, 12月 31, 2025にアクセス、 https://ceur-ws.org/Vol-187/16.pdf
  16. OKKAM: Towards a Solution to the “Identity Crisis” on the Semantic Web - CEUR-WS, 12月 31, 2025にアクセス、 https://ceur-ws.org/Vol-201/33.pdf