CIM 格式

云信息模型 (CIM) 从一开始就被设计为基于标准、与应用程序无关的业务概念模型（客户、订单、产品、帐户以及它们之间的关系）。但只有当需要它的系统能够实际使用它时，概念模型才有用。这就是为什么 CIM 不是作为单个专有工件发布，而是作为一系列序列化发布，每个序列化针对不同类别的工具、运行时和受众。

本页介绍了每种 CIM 格式的含义、用途以及如何在其中进行选择。如果您是企业数据架构师、集成或 ETL 工程师、应用程序或平台供应商或开源贡献者，您首先采用的格式取决于您在管道中的位置。

要点

• CIM 分布在两个系列：语义 Web 格式（JSON-LD、RDF 架构、SHACL、R2RML）和人类可读/关系格式（AML 词汇、AML 方言、RAML 类型、JSON 架构、SQL DDL）。
• 概念模型（​​concepts.*）描述实体和关系； 规范模式（schema.*）描述数据形状和约束。它们是具有不同目的的独立工件。
• JSON-LD 是规范的机器可读形式； AML 是相同内容的人类可读形式； SQL DDL 和 JSON Schema 是大多数应用程序和 ETL 团队直接使用的形式。
• R2RML 是桥梁：它将关系模式映射到 RDF 图，这就是将现有 SQL 数据库连接到语义层的方式。
• 选择格式是 消费者的问题，而不是偏好 - 选择您的目标工具链本机摄取的格式，并使用其他格式作为交叉检查。

为什么 CIM 以多种格式提供

大多数数据模型都以一种形式发布——通常是 ER 图、电子表格或特定于供应商的元数据文件。直到您需要在使用不同堆栈的组织之间共享模型之前，这种方法都有效。零售平台可能运行 PostgreSQL 和 dbt；合作伙伴可能会运行图数据库和三元组存储； SaaS 供应商可能会公开 JSON API 并使用 JSON 架构验证有效负载。如果共享模型仅存在于其中一种方言中，那么其他人都必须翻译它 - 并且翻译会产生偏差。

CIM 的多格式策略是对这个问题的有意回答。该模型只需编写一次，然后*​​转换为能够清晰映射到公认标准的格式**，以便每个消费者使用其已有的工具来采用 CIM。这与 万维网联盟 (W3C) 等标准机构背后的理念相同，该机构发布了 CIM 重用而不是重新发明的 RDF、SHACL 和 R2RML 等规范。它还符合 CIM 项目运作的 Linux 基金会 更广泛的互操作性使命。

实际好处是双重的：采用不同技术的企业可以采用 CIM，而无需进行彻底替换，并且贡献者可以以与其专业知识相匹配的任何格式扩展模型，因为知道可以重新生成其他序列化。

概念模型与规范模式

在比较文件格式之前，它有助于区分 CIM 保持不同的两个层，而新手经常混淆这两个层。

Related: Fivetran — The fully managed ELT pipeline that just keeps running.

• 概念模型回答存在什么以及它如何关联。它定义了实体（客户、订单、产品）、它们的属性以及它们之间的关系。它有意接近商业词汇，并刻意淡化物理细节。
• 规范模式回答有效实例是什么样子。它添加了系统可以验证的数据形状和约束（基数、类型、必填字段、值范围）。

在 CIM 发行版中，它们映射到两个文件名主干：概念层的“concepts.”和规范层的“schema.”。将它们分开意味着业务分析师可以读取概念模型，而无需费力地阅读约束语法，而工程师可以根据模式验证有效负载，而无需完整的概念叙述。

语义网格式

这些格式将 CIM 表示为基于 RDF 的图。当您的消费者包括三重存储、知识图、本体工具或任何对链接数据进行推理的系统时，它们是正确的选择。

JSON-LD — concepts.json 和 schema.json

JSON-LD 是具有链接数据上下文的 JSON，这使其成为普通 Web API 和语义 Web 之间的实用桥梁。 CIM 发布了两个 JSON-LD 工件：

Our pick: Workato — Automation-led iPaaS that business teams can actually build on.

• concepts.json — 实体和关系的概念描述，以 RDF 模式表示。
• schema.json — 规范数据形状和附加约束，以 SHACL 表示。

因为它是有效的 JSON，所以“concepts.json”和“schema.json”可以通过普通 JSON 工具加载，但因为它们带有“@context”，所以它们也扩展为完整的 RDF 三元组。这种双重性质就是为什么 JSON-LD 通常是那些希望语义保真度而不是在第一天就采用专门的 RDF 堆栈的团队的最佳默认设置。

RDF 模式 — schema.json

RDF 模式 (RDFS) 提供了用于描述类和属性的词汇表——“rdfs:Class”、“rdfs:subClassOf”和“rdfs:domain”/“rdfs:range”结构，让机器理解订单是一个业务文档，并且其客户属性指向客户。 CIM 使用 RDFS 为概念模型提供正式语义，以便子类层次结构和属性域是机器可解释的，而不仅仅是记录的。

SHACL — schema.json

形状约束语言 (SHACL) 是一种 W3C 标准，用于根据一组称为形状的条件验证 RDF 图。 RDFS 说明类是什么，而 SHACL 说明有效实例必须满足什么——所需的属性、允许的值类型、基数限制。 CIM 的规范数据形状以 SHACL 表示，这意味着任何 SHACL 处理器都可以验证符合 CIM 的数据，而无需自定义代码。

R2RML — schema.rdml

R2RML 是用于将关系数据库模式映射到 RDF 图的 W3C 标准。这是对集成和 ETL 工程师最重要的格式，因为它是现有 SQL 数据库（及其表、列和外键）作为符合 CIM 的链接数据公开的机制。您无需手动重新建模操作数据库，而是编写（或生成）R2RML 映射来声明每个表和列如何对应于 CIM 实体和属性。结果是现有关系数据的虚拟 RDF 图。

人类可读和关系格式

并非每个消费者都需要 RDF。应用程序开发人员、数据建模人员和 DBA 通常希望他们可以在文本编辑器中读取某些内容或直接加载到数据库中。 CIM 通过 AML、RAML、JSON 架构和 SQL DDL 序列化为它们提供服务。

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

AML（此处用作建模方言的 AnyLogic 建模语言 谱系）是 CIM 的人类可读表达。 CIM 发布了三个 AML 工件：

Related: Matillion — Push-down ELT built for cloud data warehouses.

• concepts.yaml — AML 词汇，概念模型的人类可读版本。
• schema.yaml — AML 方言，规范数据形状的人类可读版本。
• schema.raml — 规范形状的 RAML 数据类型渲染。

词汇和方言之间的区别值得内化：词汇定义术语（模型的名词和动词），而方言定义如何将这些术语组合成有效的结构。如果您是第一次查看 CIM，“concepts.yaml”通常是最容易接近的入口点。

JSON Schema — schema.json

JSON Schema 是验证 JSON 文档的事实上的标准，几乎所有现代语言都通过本机或库支持。 CIM 的 JSON 架构工件将规范数据形状表示为 JSON 架构，这使得它可以直接在已经验证 JSON 有效负载的 API 网关、消息代理和 CI 管道中使用。如果您的集成表面是 REST 或事件驱动的 JSON，这通常是您想要的格式。

SQL DDL — schema.sql

SQL DDL 是一组“CREATE TABLE”、“CREATE VIEW”和约束语句，用于在关系数据库中具体化规范形状。 CIM 以 SQL 2008 语法为目标，这使得 DDL 可以在主要关系引擎之间移植。这是 DBA 和 ETL 工程师在想要建立符合 CIM 的物理模式（例如，镜像规范模型的临时数据库或集成数据库）时采用的格式。

If you are shopping: Boomi AtomSphere — Enterprise iPaaS for hybrid cloud-to-on-prem integration.

选择格式：实用指南

不存在单一的“正确”格式。正确的选择取决于接下来使用模型的人或物。使用下表作为决策辅助。

如果您的消费者是…	开始使用	因为…
业务分析师或数据建模师正在审查模型	AML 词汇表 (concepts.yaml)	人类可读，商业词汇优先
三重存储、知识图谱或本体工具	JSON-LD (concepts.json, schema.json)	带有 JSON 入口的原生 RDF
SHACL 验证器或语义数据质量管道	SHACL (schema.json)	RDF 上的标准约束验证
您想要公开为链接数据的现有关系数据库	R2RML (schema.rdml)	将表/列映射到 CIM 实体，无需重新建模
REST 或事件驱动的 JSON API	JSON 架构 (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（词汇） — 人类可读的概念模型。
• AML（方言） — 人类可读的规范形状。
• JSON-LD（词汇和模式） — 机器可读的语义模型。
• R2RML — 关系到 RDF 的映射。
• RAML 类型 — 作为 RAML 数据类型的规范形状。
• SQL DDL — 作为可移植 SQL 的规范形状。

每次下载都包含该格式的完整 CIM 定义，这意味着您可以逐步采用 CIM：从当前工具链支持的格式开始，并随着互操作性需求的增长添加其他格式。

跨格式贡献

由于 CIM 是一个开放项目，因此欢迎贡献——并且多格式结构决定了贡献的运作方式。贡献者通常分为两类：

• 模型贡献者提出新的实体、关系或约束。这些更改只需编写一次，然后就会传播到其他序列化。
• 格式贡献者 改进特定序列化的保真度或工具 - 例如，改进 R2RML 映射或 SQL DDL 可移植性。

如果您正在做出贡献，实际规则是了解您正在更改哪一层（概念层与规范层）以及因此必须重新生成哪些格式。该项目的 GitHub 存储库和贡献者 Web 表单是参与的入口点。

常见问题

CIM 中的 concepts.json 和 schema.json 有什么区别？

concepts.json 是概念模型 — CIM 中的实体和关系，用 RDF Schema 语义表示为 JSON-LD。 schema.json 是规范模式 - 数据形状和附加约束，表示为具有 SHACL 语义的 JSON-LD。简而言之，“概念”描述了存在的事物； “schema”描述了有效实例必须是什么样子。

为什么 CIM 以如此多种格式发布同一个模型？

因为不同的消费者使用不同的技术。三元组存储需要RDF； JSON API 需要 JSON Schema； DBA 需要 SQL DDL；业务分析师需要一些易于阅读的内容。以多种标准格式发布 CIM 可以让每个受众使用他们已有的工具来采用该模型，而不是强迫每个人使用单一堆栈。

R2RML 在 CIM 中的用途是什么？

R2RML 是用于将关系数据库模式映射到 RDF 图的 W3C 标准。在 CIM 中，它是将现有 SQL 数据库公开为符合 CIM 的关联数据的桥梁，因此您可以将运行中的关系系统连接到语义层，而无需手动重新建模。

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 格式而不更新其他格式吗？

你可以，但你不应该。这些格式是一个基础模型的序列化，因此手动编辑单一格式会导致各格式之间出现偏差。扩展源模型并重新生成其他序列化。

进一步阅读

• 万维网联盟 (W3C) — RDF、RDF Schema、SHACL 和 R2RML 背后的标准机构，这些是 CIM 所基于的规范。
• 形状约束语言 (SHACL) — 用于 CIM 标准数据形状的约束语言的背景。
• Linux 基金会 — CIM 项目运作的基金会。