CIM 格式

雲端資訊模型 (Cloud Information Model, CIM) 從一開始就被設計為一個基於標準、與應用程式無關的業務概念模型 —— 包含客戶、訂單、產品、帳戶以及它們之間的關係。但只有當需要它的系統能夠實際消費（consume）它時，概念模型才有用。這就是為什麼 CIM 不是作為單一專有工件發布，而是作為一系列序列化 (serializations) 發布，每種序列化針對不同類別的工具、運行時間和受眾。

本頁介紹了每種 CIM 格式的含義、用途以及如何在其中進行選擇。如果您是企業資料架構師、整合或 ETL 工程師、應用程式或平台供應商或開源貢獻者，您首先採用的格式取決於您在管線 (pipeline) 中的位置。

要點

• CIM 分佈為兩個系列：語義網 (semantic-web) 格式（JSON-LD、RDF Schema、SHACL、R2RML）和人類可讀/關係格式（AML vocabulary、AML dialect、RAML types、JSON Schema、SQL DDL）。
• 概念模型 (concepts.*) 描述實體和關係；規範模式 (canonical schema) (schema.*) 描述資料形狀和約束。它們是具有不同目的的獨立工件。
• JSON-LD 是規範的機器可讀形式；AML 是相同內容的人類可讀形式；SQL DDL 和 JSON Schema 是大多數應用程式和 ETL 團隊直接消費的形式。
• R2RML 是橋樑：它將關係模式對應到 RDF 圖，這就是將現有 SQL 資料庫連接到語義層的方式。
• 選擇格式是消費者的問題，而非偏好問題 —— 選擇您的目標工具鏈原生攝取的格式，並使用其他格式作為交叉檢查。

為什麼 CIM 會以多種格式提供

大多數資料模型都僅以一種形式發布 —— 通常是 ER 圖、電子表格或特定於供應商的元資料檔案。在您需要跨使用不同技術堆疊的組織共用模型之前，這種方法都有效。零售平台可能運行 PostgreSQL 和 dbt；合作夥伴可能會運行圖形資料庫和三元組儲存 (triple store)；SaaS 供應商可能會公開 JSON API 並使用 JSON Schema 驗證有效負載 (payloads)。如果共享模型僅存在於其中一種方言中，那麼其他人都必須翻譯它 —— 而翻譯會產生偏差 (drift)。

CIM 的多格式策略是對這個問題的刻意回應。該模型只需編寫一次，然後轉換為能夠清晰地映射到公認標準的格式，以便每個消費者使用其已有的工具來採用 CIM。這與 萬維網聯盟 (W3C) 等標準機構背後的理念相同，該機構發布了如 RDF、SHACL 和 R2RML 等規範，CIM 重用而非重新發明這些規範。它也符合 CIM 計畫所屬的 Linux 基金會 更廣泛的互通性使命。

實際好處是雙重的：採用不同技術的企業可以採用 CIM 而無需徹底替換 (rip-and-replace)，且貢獻者可以用於與其專業知識相匹配的任何格式擴展模型，因為他們知道其他序列化可以重新生成。

概念模型與規範模式

在比較文件格式之前，有助於區分 CIM 保持獨立的兩個層級 —— 而新手經常將這兩者混淆。

相關： Fivetran — 完全託管的 ELT 管道持續運行.

• 概念模型回答存在什麼以及它如何關聯。它定義了實體（客戶、訂單、產品）、它們的屬性以及它們之間的關係。它有意接近業務詞彙，並刻意淡化物理細節。
• 規範模式回答有效的實例 (instance) 是什麼樣子。它添加了系統可以驗證的資料形狀和約束 —— 基數 (cardinality)、類型、必填欄位、值範圍。

在 CIM 分發版中，它們對應到兩個檔案名稱前綴：概念層使用 concepts.*，規範層使用 schema.*。將它們分開意味著業務分析師可以閱讀概念模型而無需費力研究約束語法，而工程師可以根據模式驗證有效負載，而無需閱讀完整的概念敘述。

語義網格式

這些格式將 CIM 表示為基於 RDF 的圖。當您的消費者包括三元組儲存、知識圖譜、本體 (ontology) 工具或任何對連結資料進行推理的系統時，它們是正確的選擇。

JSON-LD — concepts.json 和 schema.json

JSON-LD 是具有連結資料上下文的 JSON，這使其成為普通 Web API 和語義網之間的實用橋樑。CIM 發布了兩個 JSON-LD 工件：

我們的選擇： Workato — 業務團隊實際上可以在此基礎上建立自動化主導的 iPaaS.

• concepts.json — 實體和關係的概念描述，以 RDF Schema 表示。
• schema.json — 規範資料形狀和附加約束，以 SHACL 表示。

因為它是有效的 JSON，所以 concepts.json 和 schema.json 可以透過普通 JSON 工具加載，但因為它們帶有 @context，所以它們也能擴展為完整的 RDF 三元組。這種雙重性質就是為什麼 JSON-LD 通常是那些希望在第一天就獲得語義保真度，而無需採用專門 RDF 堆疊的團隊的最佳預設選擇。

RDF Schema — schema.json

RDF Schema (RDFS) 提供了用於描述類別和屬性的詞彙表 —— 包含 rdfs:Class、rdfs:subClassOf 和 rdfs:domain/rdfs:range 結構，讓機器能理解「訂單」是一個業務文件，且其客戶屬性指向一個「客戶」。CIM 使用 RDFS 為概念模型提供正式語義，使子類別層次結構和屬性域是機器可解釋的，而不僅僅是記錄在案。

SHACL — schema.json

形狀約束語言 (SHACL) 是一種 W3C 標準，用於根據一組稱為「形狀 (shapes)」的條件驗證 RDF 圖。RDFS 說明類別是什麼，而 SHACL 說明有效實例必須滿足什麼——例如所需的屬性、允許的值類型、基數限制。CIM 的規範資料形狀以 SHACL 表示，這意味著任何 SHACL 處理器都可以驗證符合 CIM 的數據，而無需自訂程式碼。

R2RML — schema.rdml

R2RML 是將關聯式資料庫模式對應到 RDF 圖的 W3C 標準。這是對整合和 ETL 工程師最重要的格式，因為它是將現有 SQL 資料庫（及其資料表、欄位和外鍵）作為符合 CIM 的連結資料 (linked data) 公開的機制。您無需手動重新建模操作資料庫，而是編寫（或產生）R2RML 映射，以聲明每個資料表和欄位如何對應到 CIM 實體和屬性。其結果是建立在現有關聯式資料之上的虛擬 RDF 圖。

人類可讀與關聯式格式

並非每個使用者都需要 RDF。應用程式開發人員、資料建模人員和 DBA 通常希望使用可以在文字編輯器中讀取或直接載入到資料庫中的格式。CIM 為他們提供了 AML、RAML、JSON Schema 和 SQL DDL 序列化格式。

AML — concepts.yaml、schema.yaml、schema.raml

AML（此處用作建模方言的 AnyLogic Modeling Language 譜系）是 CIM 的人類可讀表達方式。CIM 發布了三個 AML 工件：

相關： Matillion — 為雲端資料倉儲所建構的下推式 ELT.

• concepts.yaml — AML 詞彙 (vocabulary)，概念模型的人類可讀版本。
• schema.yaml — AML 方言 (dialect)，規範資料形狀的人類可讀版本。
• schema.raml — 規範形狀的 RAML 資料類型渲染。

詞彙與方言之間的區別值得內化：詞彙定義術語（模型的名詞和動詞），而方言定義如何將這些術語組合成有效的結構。如果您是第一次審閱 CIM，concepts.yaml 通常是最容易入門的切入點。

JSON Schema — schema.json

JSON Schema 是驗證 JSON 文件的實事標準 (de facto standard)，幾乎所有現代語言都原生支援或透過程式庫支援。CIM 的 JSON Schema 工件將規範資料形狀表示為 JSON Schema，這使得它能直接用於已經驗證 JSON 有效負載 (payloads) 的 API 閘道、訊息代理程式和 CI 管道。如果您的整合介面是 REST 或事件驅動的 JSON，這通常是您需要的格式。

SQL DDL — schema.sql

SQL DDL 是一組 CREATE TABLE、CREATE VIEW 和約束語句，用於在關聯式資料庫中具體化規範形狀。CIM 以 SQL 2008 語法為目標，這使得 DDL 在主要關聯式引擎之間具有可移植性。這是 DBA 和 ETL 工程師在想要建立符合 CIM 的實體模式（例如，鏡像規範模型的暫存或整合資料庫）時所採用的格式。

如果您正在購物： Boomi AtomSphere — 用於雲端到本地混合整合的企業 iPaaS.

選擇格式：實用指南

不存在單一的「正確」格式。正確的選擇取決於接下來是誰或什麼在消費該模型。請使用下表作為決策輔助。

如果您的消費者是…	從…開始	因為…
審閱模型的業務分析師或資料建模師	AML 詞彙 (concepts.yaml)	人類可讀，商業詞彙優先
三元儲存 (triple store)、知識圖譜或本體工具	JSON-LD (concepts.json, schema.json)	具有 JSON 入口的原生 RDF
SHACL 驗證器或語意資料品質管道	SHACL (schema.json)	基於 RDF 的標準約束驗證
您想要公開為連結資料的現有關聯式資料庫	R2RML (schema.rdml)	將資料表/欄位對應到 CIM 實體，無需重新建模
REST 或事件驅動的 JSON API	JSON Schema (schema.json)	直接驗證 JSON 有效負載
您想要使其符合 CIM 的關聯式資料庫	SQL DDL (schema.sql)	可移植的 SQL 2008 DDL
RAML 描述的 API	RAML 類型 (schema.raml)	RAML 工具鏈原生

一些實際的注意事項：

• 不要將這些格式視為獨立模型。 它們是同一底層 CIM 的不同序列化。如果您發現例如 schema.json (JSON Schema) 和 schema.json (SHACL) 之間存在差異，那是一個錯誤或版本偏差，而非設計選擇——請回報此問題。
• 注意檔名衝突。 多種格式共用 schema 主幹但副檔名不同 (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml)。下載完整發行版時，請將格式目錄分開，以免一種序列化覆寫另一種。
• 將格式與驗證階段相匹配。 使用概念格式進行設計時審閱，使用規範格式進行執行時間驗證。針對概念模型進行驗證沒有意義，因為它缺乏約束。
• 優先選擇自動產生而非手動編輯。 如果您擴展 CIM，請擴展來源並重新產生其他序列化，而不是手動編輯每種格式，否則各格式之間將會出現同步偏差。

下載完整的 CIM 發行版

CIM 以每種可用格式的完整定義形式分發，因此您可以直接下載所需序列化格式的整個模型，而無需逐一組裝。已發布的下載選項有：

• AML (vocabulary) — 人類可讀的概念模型。
• AML (dialect) — 人類可讀的規範形狀 (canonical shapes)。
• JSON-LD (vocabulary & schema) — 機器可讀的語意模型。
• R2RML — 關聯式到 RDF 的對應 (relational-to-RDF mapping)。
• RAML Types — 作為 RAML 資料類型的規範形狀。
• SQL DDL — 作為可移植 SQL 的規範形狀。

每次下載都包含該格式的完整 CIM 定義，這表示您可以逐步採用 CIM：從目前工具鏈支援的格式開始，並隨著互通性需求的增長添加其他格式。

跨格式貢獻

由於 CIM 是一個開放項目，因此歡迎貢獻 — 且多格式結構決定了貢獻的運作方式。貢獻者通常分為兩類：

• 模型貢獻者提出新的實體、關係或約束。這些變更只需編寫一次，然後就會傳播到其他序列化格式。
• 格式貢獻者改進特定序列化的保真度或工具 — 例如，精煉 R2RML 對應或 SQL DDL 的可移植性。

如果您正在做出貢獻，實際規則是了解您正在更改哪一層（概念層 vs. 規範層）以及因此必須重新產生哪些格式。此專案的 GitHub 儲存庫和貢獻者 Web 表單是參與的入口點。

常見問題

CIM 中的 concepts.json 和 schema.json 有什麼不同？

concepts.json 是概念模型 — 即 CIM 中的實體和關係，以具有 RDF Schema 語意的 JSON-LD 表示。schema.json 是規範模式 (canonical schema) — 即資料形狀和附加約束，以具有 SHACL 語意的 JSON-LD 表示。簡而言之，concepts 描述了存在什麼；schema 描述了有效的實例必須是什麼樣子。

為什麼 CIM 以如此多種格式發布同一個模型？

因為不同的使用者使用不同的技術。三元組儲存 (triple store) 需要 RDF；JSON API 需要 JSON Schema；資料庫管理員 (DBA) 需要 SQL DDL；業務分析師需要人類可讀的內容。以多種標準格式發布 CIM，讓每類受眾都能使用他們已有的工具來採用該模型，而不是強迫每個人使用單一技術棧。

R2RML 在 CIM 中的用途是什麼？

R2RML 是將關聯式資料庫模式對應到 RDF 圖的 W3C 標準。在 CIM 中，它是將現有 SQL 資料庫公開為符合 CIM 的連結資料 (linked data) 的橋樑，因此您可以將操作關聯式系統連接到語意層，而無需手動重新建模。

AML 與 JSON-LD 格式相同嗎？

不同。AML 是 CIM 的人類可讀表達方式 — 包含詞彙 (concepts.yaml) 和方言 (schema.yaml、schema.raml)。JSON-LD 是機器可讀且基於 RDF 的表達方式。它們描述相同的模型，但針對不同的受眾和工具鏈。

我應該從哪一種 CIM 格式開始？

這取決於您的使用者。如果您正在審查模型，請從 AML 詞彙開始。如果您正在建立 JSON API，請從 JSON Schema 開始。如果要連接關聯式資料庫，請從 R2RML 或 SQL DDL 開始。如果您正在使用知識圖譜，請從 JSON-LD 和 SHACL 開始。

我可以編輯一種 CIM 格式而不更新其他格式嗎？

可以，但不建議這樣做。這些格式是一個底層模型的不同序列化，因此手動編輯單一格式會導致系列版本不同步。請擴展來源模型並重新產生其他序列化格式。

進一步閱讀

• World Wide Web Consortium (W3C) — RDF、RDF Schema、SHACL 和 R2RML 背後的標準機構，這些是 CIM 建立其上的規範。
• Shapes Constraint Language (SHACL) — 關於用於 CIM 規範資料形狀的約束語言之背景資料。
• Linux Foundation — CIM 專案在其下運作的基金會。