> 译文仅供阅读便利。具有规范效力的是英文原文。 # 命名约定 **元宇宙规范** **文档编号：** MU-V2-ARCH-003 **标题：** 元模型架构标准 - 命名约定 **文档类别：** 规范性 **版本：** 2.0（草案） **状态：** 工作草案 **规范性引用：** 元宇宙宪章（MUC）、MMAS-Core **说明性引用：** Versioning、元宇宙联邦协议（MUFP） **版权：** © Orkestron.AI **许可：** Apache-2.0 --- # 1. 目的 本文档定义在整个元宇宙生态中通行的命名规则。 一致的命名有助于可发现性、语义互操作、联邦、自动化以及长期可维护性。 --- # 2. 适用范围 这些规则适用于： - 元宇宙各项标准； - 元模型； - 包（bundle）； - 层； - 对象； - 属性； - 关系； - 事件； - 契约； - 投影配置； - 命名空间。 实现可以定义额外的本地约定，只要它们仍与本规范保持兼容。 --- # 3. 命名原则 名称必须做到： - 无歧义； - 稳定； - 可读于人； - 可读于机器； - 与技术无关； - 语义上确有其义。 名称必须描述概念，而不是实现细节。 --- # 4. 正典语言 英语必须是全部规范性名称的正典语言。 本地化标签可以作为元数据提供。 正典标识符必须保持与语言无关。 --- # 5. 标识符与显示名 每一件重要制品应当区分： - 标识符（稳定） - 显示名（便于人读） 示例： 标识符： employee.performance-review 显示名： Employee Performance Review 显示名可以变更。 标识符应当保持稳定。 --- # 6. 正典语义名（CSN） 标识符与显示名之间的区分，对每一个公共概念都被推广为一个**正典语义名（Canonical Semantic Name，CSN）**。每个公共概念必须同时拥有： - 一个**人读 / 显示名** - 本地化、便于人读，并且可以自由变更（例如 "Salary Agreement"）； - 一个不可变的**正典语义名（CSN）** - 稳定且与技术无关的含义标识符（例如 `employee.compensation.salaryAgreement`）。 示例： ```text Display Name : Salary Agreement CSN : employee.compensation.salaryAgreement ``` CSN 类似于全限定类名或 RDF 中的 URI，但它有意做到**与技术无关**：它不承诺任何编程语言、序列化格式或传输方式。它表达的是一个概念在其语义层级中的位置，仅此而已。 规则： - 每个公共概念必须恰有一个 CSN。 - CSN 一经发布必须不可变；重命名某个概念必须按 [Versioning](Versioning.md) 视为语义变更，并且必须产生一个新的 CSN，绝不是对既有 CSN 的悄然改写。 - 所有**联邦交互必须交换 CSN**。元宇宙联邦协议（MUFP）传输的是 CSN；它不得以显示名作为身份依据。 - 用户界面应当呈现本地化的显示名，同时把它解析到其背后的 CSN。 - 显示名可以因语言、上下文与呈现方式而异；CSN必须保持不变。 为防止联邦中出现名称冲突，CSN 应当与定义该概念那一版本的[语义指纹](Versioning.md)配对使用。二者合起来：CSN 指明*是哪个概念*，指纹指明*是哪一种含义*，从而使用同一 CSN 的两个宇宙能在依赖它之前先查明彼此是否真的在语义上一致。 --- # 6a. CSN 文法与标识符方案 为使 CSN 与标识符可被机器校验，本节给出它们的形式文法。 **正典语义名**必须符合下列 ABNF（RFC 5234）： ```abnf CSN = segment *("." segment) segment = lower *(ALPHA / DIGIT) lower = %x61-7A ; a-z (a segment SHALL start lowercase) ALPHA = %x41-5A / %x61-7A DIGIT = %x30-39 ``` 第一个 `segment` 是**命名空间**；其余各段在其中命名该概念（例如 `employee.compensation.salaryAgreement` - 命名空间为 `employee`）。该文法是 [`schemas/common.schema.json`](../schemas/common.schema.json) 中 `csn` 模式的规范性来源，并由 [Validation](Validation.md) 的检查项 `V2-03` 强制执行。 **标识符**（对象、关系、事件、契约或投影的 `id`，以及本地身份的取值）是不透明的，并且必须在其所命名之物的整个生命期内保持稳定。实现必须采用下列标识符方案之一并予以声明，使消费方能够解析它： | 方案 | 形式 | 示例 | |--------|------|---------| | `uuid` | 一个 UUID | `9d3f2c1a-...` | | `uri` | 一个绝对 URI | `https://acme.example/person/12345` | | `urn` | 一个 URN | `urn:mu:person:9d3f2c1a` | | `qname` | 宇宙内的 `scheme:value` | `employee:12345` | 标识符必须按精确字节串比较；不得折叠大小写，也不得作规范化处理。[正典身份](../04-core-concepts/Identity.md)把方案与取值配成一对（`{ "scheme": "urn", "value": "urn:mu:person:9d3f2c1a" }`）。新方案可以被登记，而不破坏既有标识符。 --- # 7. 命名空间约定 每个公共概念必须归属于某个命名空间。 推荐格式： namespace:Concept 示例： employee:Skill organization:Department product:Capability schema:Person fhir:Patient 命名空间必须在其语义范围内全局唯一。 --- # 8. 元模型命名 元模型应当使用具有描述性的名称。 推荐示例： Employee Meta-Model Product Landscape Meta-Model Enterprise Landscape Meta-Model 避免使用绑定具体实现的名称。 --- # 9. 包命名 包名应当是表示语义领域的名词。 示例： Identity Knowledge Governance Runtime History Security --- # 10. 层命名 每一层必须表示一个连贯的语义关切。 层名应当： - 使用单数名词； - 避免缩写； - 避免技术名称。 示例： Employment History Projects Compensation Competencies --- # 11. 对象命名 对象名应当： - 使用单数名词； - 表示真实的或概念上的实体； - 避免实现术语。 推荐： Employee Project Skill 避免： EmployeeTable ProjectDTO SkillRecord --- # 12. 属性命名 属性名应当： - 描述事实； - 使用 lowerCamelCase； - 避免前缀； - 避免来自实现的后缀。 推荐： firstName createdAt currentPosition 避免： emp_name fld1 col_employee --- # 13. 关系命名 关系名应当描述其语义含义。 示例： worksFor reportsTo owns dependsOn assignedTo 诸如 "link" 或 "relation" 之类的笼统名称应当避免。 --- # 14. 事件命名 事件应当描述已经发生的事实。 推荐模式： 示例： EmployeeCreated ContractSigned ProjectArchived 避免使用祈使语气的名称。 --- # 15. 契约命名 契约应当描述业务上的或语义上的目的。 示例： Employment Contract Knowledge Disclosure Contract Federation Agreement 避免面向实现的名称。 --- # 16. 文件命名 规范文档应当采用： Title-Case-With-Hyphens.md 示例： Meta-Universe-Constitution.md Federation-Contracts.md Identity-Binding.md 示例文件应当带上后缀： .example.yaml --- # 17. 保留术语 下列术语由元宇宙标准族保留： Universe Dimension Namespace Meta-Model Bundle Layer Object Projection Relationship Event Contract Context Identity 这些术语不得被重新定义为不兼容的含义。 --- # 18. 导入的标准 导入的概念必须在切实可行的情况下保留其原有名称。 本地扩展应当扩展导入的概念，而不是给它们改名。 示例： schema:Person ↓ employee:Employee --- # 19. 命名的稳定性 标识符必须在各兼容版本之间保持稳定。 重命名应当被视为语义变更。 每当标识符发生变化，必须提供迁移指引。 --- # 20. 未来方向 正典语义名确立了一个稳定、与技术无关的身份层，未来的工作可以把它展开为一部**语义风格指南**：一份配套标准，规定 CSN 各段的文法、大小写与复数规则、推荐的层级深度，以及本地化显示名跨语言映射到 CSN 的解析算法。这样一部指南还会规定一项面向整个联邦的 CSN 解析服务，使任何宇宙都能把一个 CSN 解引用到定义它的版本及其[语义指纹](Versioning.md)，从而在命名与含义之间闭合回路。 --- # 结语 一致的命名是语义互操作的前提。 这些约定的目的不只是文体上的整齐，而是造就稳定、在全球范围内可被理解的语义模型 - 它们能够演进、能够联邦，也能被人与人工智能系统同样可靠地解读。