> 译文仅供阅读便利。具有规范效力的是英文原文。

# 命名示例

**元宇宙规范**

**文档编号：** MU-V2-REFARCH-008  
**标题：** 命名示例  
**文档类别：** 说明性  
**版本：** 2.0（草案）  
**状态：** 工作草案  
**规范性引用：** MMAS（命名约定）  
**说明性引用：** Reference Repository、Anti-Patterns  
**版权：** © Orkestron.AI  
**许可：** Apache-2.0

---

# 1. 目的

本文档为符合元宇宙的仓库、元模型与语义制品给出示意性的命名示例。

它以具体例子演示推荐做法，从而补足规范性的命名约定规范。

---

# 2. 设计原则

名称应当是：

- 清晰的；
- 稳定的；
- 可读于人的；
- 可读于 AI 的；
- 与技术无关的；
- 语义上确有其义的。

名称应当描述概念，而不是实现。

---

# 3. 仓库名

推荐：

- employee-meta-model
- product-meta-model
- software-meta-model
- organization-meta-model
- healthcare-meta-model

避免：

- model-v2-final
- temp-repository
- test123
- new-model

---

# 4. 目录名

推荐：

- 00-foundation
- 01-constitution
- 02-architecture
- 03-federation
- 04-core-concepts
- 05-reference-architecture
- 06-domain-models
- 07-guides
- examples

避免：

- misc
- docs2
- stuff
- temp

---

# 5. 文档名

推荐：

- Employee.md
- Organization.md
- Projection.md
- Semantic-Mapping.md
- Federation-Contracts.md

避免：

- employee_final_v3.md
- new_file.md
- draft2.md

规范性文件名应当在各次发布之间保持稳定。

---

# 6. 命名空间示例

推荐：

- employee
- organization
- finance
- healthcare
- ai-agent
- software

带限定的示例：

- employee:Employee
- employee:Skill
- organization:Department
- product:Product
- software:Service

---

# 7. 对象示例

推荐的对象名：

- Employee
- Department
- Product
- Customer
- Invoice
- Contract
- Service
- AIAgent

对象名应当代表业务概念。

---

# 8. 关系示例

推荐：

- reportsTo
- memberOf
- owns
- assignedTo
- dependsOn
- implements
- supervises
- belongsTo

关系名应当表达其语义含义。

---

# 9. 事件示例

推荐：

- EmployeeCreated
- ContractApproved
- ProjectionPublished
- IdentityBound
- FederationEstablished
- SynchronizationCompleted

事件应当描述已经完成的发生之事。

---

# 10. 投影示例

推荐的投影名：

- EmployeePublicProjection
- EmployeeHRProjection
- EmployeePayrollProjection
- ProductCatalogProjection
- IncidentSummaryProjection

投影名应当点明其上下文。

---

# 11. 契约示例

推荐：

- EmployeeDisclosureContract
- HRFederationContract
- ProductExchangeContract
- AIAgentCapabilityContract

契约名应当点明其目的。

---

# 12. 身份示例

正典身份：

employee:550e8400-e29b-41d4-a716-446655440000

本地身份：

HR-10245

绑定：

employee:550e8400... ↔ HR-10245

正典身份应当在全球范围内保持稳定。

---

# 13. 版本示例

推荐：

- 1.0.0
- 1.2.1
- 2.0.0

避免：

- final
- latest
- vNext

应当采用语义化版本。

---

# 14. 完整的命名示例

仓库：

employee-meta-model

命名空间：

employee

对象：

Employee

关系：

reportsTo

投影：

EmployeeHRProjection

契约：

EmployeeDisclosureContract

事件：

EmployeePromoted

这一串名称，演示了贯穿各架构层的一致语义命名。

---

# 15. 架构检查清单

发布之前：

- 这个名称稳定吗？
- 它与技术无关吗？
- 它在语义上确有其义吗？
- 不了解实现的人能看懂吗？
- 它与 MMAS 的命名约定一致吗？

---

# 16. 走向一部语义风格指南

本文档的示例讲的是*命名*，但命名只是文体一致的一个侧面。正如 *Google Java Style Guide* 所管的远不止标识符名称 - 它还涵盖排版、注释、惯用法与统一措辞，使成千上万的工程师写出的代码读起来像出自一人之手 - 元宇宙同样需要一部统一的**语义风格指南**，来管辖语义模型该如何*书写*，而不只是如何命名。

一部语义风格指南会在一处把下列各项标准化：

- **命名规则** - 本文档通篇所示的那些约定（仓库、命名空间、对象、关系、事件、投影、契约、身份、版本）。
- **实体描述规则** - 对象、关系或事件如何描述、按什么次序、写到多细。
- **统一措辞** - 定义所用的语气与句式保持一致，使成千上万份各自独立撰写的模型，其描述读起来如出一辙。
- **关系与事件的约定** - 关系用动词形式（`reportsTo`、`dependsOn`），事件用完成过去式（`EmployeePromoted`、`ContractApproved`）。
- **结语的体例** - 每份文档收尾陈述的统一形式。
- **统一的目的 / 范围 / 原则** - 共同的开篇结构，使每份文档都以同样可辨的方式交代其目的、范围与设计原则。
- **领域元模型的建议** - 用这些零件拼出一份完整领域模型的门内体例。

目标是*可供机器合并的一致性*：当成千上万个组织以同一种一致的体例发布语义模型，AI 智能体理解、分析、比较与合并它们的可靠程度，将远胜于各家自造措辞的局面。体例上的一致并非装点门面 - 对一个 AI 原生的生态而言，它是跨模型自动推理的先决条件。

---

# 未来方向

上文所述的**语义风格指南**，预期会长成规范性命名约定的一份独立说明性伴侣 - 元宇宙版的语言风格指南，涵盖命名、描述、措辞、关系与事件约定、文档结构与结语形式。衡量它是否成功的尺子很简单：任何两个遵循它的组织所产出的模型，AI 智能体读起来、分析起来、合并起来，都会像出自同一位作者。

---

# 结语

一致的命名，是长期语义互操作的必要条件。

用上稳定、有义、与技术无关的名称，元宇宙的各项实现对人与 AI 智能体来说都会更易理解、更易校验、更易联邦、更易演进，同时在各仓库与各领域之间保全语义上的清晰。