> 译文仅供阅读便利。具有规范效力的是英文原文。 # 扩展模型 **元宇宙规范** **文档编号：** MU-V2-ARCH-005 **标题：** 元模型架构标准 - 导入与扩展外部模型 **文档类别：** 规范性 **版本：** 2.0（草案） **状态：** 工作草案 **规范性引用：** 元宇宙宪章（MUC）、MMAS-Core、MMAS-Package **说明性引用：** Versioning、Naming-Conventions、[Meta-Model-Composition](Meta-Model-Composition.md) **版权：** © Orkestron.AI **许可：** Apache-2.0 --- # 1. 目的 本文档定义元宇宙的元模型必须如何导入、引用并扩展外部语义模型，同时保持互操作性、语义完整性与长期可维护性。 目标是鼓励复用既有标准，而不是重新定义已经存在的概念。 --- # 2. 适用范围 本规范适用于： - 导入的语义模型； - 导入的命名空间； - 导入的对象； - 导入的关系； - 导入的词表； - 本地扩展； - 语义映射。 --- # 3. 架构原则 元宇宙必须**优先扩展而非重复**。 只要既有语义标准已经足够精确地描述了所需概念，就应当导入它们。 本文档治理的是外部模型的*导入与扩展*，而某个概念应当是字面字段、嵌套（内嵌）元模型，还是指向另行治理模型的引用，这一结构性问题由 [Meta-Model-Composition](Meta-Model-Composition.md) 规定。 --- # 4. 语义包 外部标准不得作为一堆零散对象被导入。它必须作为**语义包**导入：一个单一、版本化、自描述的单位，完整承载此次导入，并可作为整体加以推理。这相当于软件包管理器在语义知识领域的对应物，依赖是作为具名、带版本的制品被获取，而不是被零碎复制。 语义包至少必须声明： - **来源声明** - 出处标准及其权威方（例如 Schema.org、O\*NET、HL7 FHIR）； - **导入的命名空间** - 从来源引入的命名空间； - **所选对象** - 被导入的具体概念，而不是整个来源； - **本地扩展** - 在导入概念之上添加的扩展，保持可单独识别； - **语义映射** - 导入概念与本地概念之间的显式映射（见第 10 节）； - **兼容性约束** - 使该包保持有效的条件； - **兼容版本范围** - 已知该包可与之配合工作的来源版本范围； - **语义指纹** - 该包自身的[语义指纹](Versioning.md)，以便消费方能判断对「同一」标准的两次导入在含义上是否真正一致。 把一次导入当作语义包来对待，就让每个依赖都拥有稳定的身份、版本范围与指纹，正如软件包管理器为代码所做的那样，只是应用于语义知识。语义包是导入时的视图；它可分发、可发布的形态是 [MMAS-Package](MMAS-Package.md) 所定义的**语义分发包（SDP）**，后者携带同样的声明，另加打包、签名与合规元数据。 --- # 5. 导入模型 被导入的模型必须仍然是独立的语义权威。 导入某个模型不得转移以下各项的所有权： - 语义； - 标识符； - 版本； - 治理。 来源标准仍然保持权威。 --- # 6. 导入元数据 每个被导入的模型至少必须声明： - 来源标准； - 命名空间； - 导入的版本； - 导入日期； - 本地所有者； - 兼容性声明。 --- # 7. 导入的命名空间 只要可行，导入的概念就必须保留其原有命名空间。 示例： schema:Person fhir:Patient odata:Entity bpmn:Process 本地别名可以存在，但不得取代正典引用。 --- # 8. 扩展模型 本地模型可以扩展导入的概念。 扩展必须： - 保留原有含义； - 避免修改导入的语义； - 保持可单独识别； - 声明所有权。 首选做法： 导入的概念 + 本地扩展 = 扩展后的概念 --- # 9. 被禁止的修改 实现不得： - 重新定义导入的语义； - 悄然重命名导入的概念； - 更改导入的标识符； - 宣称拥有导入的标准。 如果确实需要不兼容的行为，则必须创建一个新的本地概念。 --- # 10. 语义映射 映射必须显式描述导入概念与本地概念之间的关系。 所支持的映射类型可以包括： - 等价 - 扩展 - 特化 - 泛化 - 派生自 - 部分映射 - 需要转换 映射必须考虑版本。 --- # 11. 版本管理 导入的模型必须保留指向其原有版本的引用。 本地扩展必须声明其与导入版本的兼容性。 导入标准发生变化时，应当触发兼容性评估，而不是自动迁移。 --- # 12. 多来源模型 元模型可以同时导入多个外部标准。 示例： - schema.org - OData - FHIR - O*NET - BPMN 冲突必须通过语义映射显式解决。 --- # 13. 所有权 导入概念的所有权仍属于来源标准。 本地扩展的所有权属于进行扩展的元模型。 所有权边界必须保持显式。 --- # 14. 可追溯性 每一个导入的概念都必须保持可追溯至其出处。 可追溯性应当标明： - 来源标准； - 命名空间； - 原始标识符； - 导入的版本； - 扩展历史。 --- # 15. 联邦 当双方都支持同一个导入标准时，联邦宇宙之间应当交换正典的语义引用。 当使用不同标准时，联邦应当依靠显式的语义映射，而不是隐含的假设。 --- # 16. 推荐的导入流程 1. 发现一个既有的语义标准。 2. 评估其语义适配度。 3. 导入正典概念。 4. 保留命名空间与版本。 5. 仅在必要处添加本地扩展。 6. 发布语义映射。 7. 在演进中维持兼容性。 --- # 17. 典型示例 适合导入的标准例如： - Schema.org - OData CSDL - RDF / OWL 词表 - OpenAPI 模式 - BPMN - DMN - HL7 FHIR - O*NET - ESCO - ArchiMate - IFC - OPC UA 这份清单仅供参考，并不穷尽。 --- # 18. 架构不变量 导入外部模型绝不得违反： - 元宇宙宪章； - 语义身份； - 溯源； - 所有权； - 可追溯性； - 版本完整性。 --- # 19. 未来方向 语义包确立了导入时的依赖单位。一个未来方向是把这些包在联邦范围内的管理标准化：依赖解析、传递性导入、版本范围求解，以及重叠标准之间的冲突仲裁，做法与成熟的包生态相仿。这与 [MMAS-Package](MMAS-Package.md) 所预期的**语义包注册表**相汇合：在其中，语义包按其[语义指纹](Versioning.md)与兼容版本范围被发布、发现与解析，而不是靠临时复制。 --- # 结语 元宇宙的设计目标是成为语义标准的联邦，而不是它们的替代品。 首选的架构做法是发现、导入、引用并扩展既有的语义模型，同时保留它们的身份、治理与含义。这使得一个由可互操作元模型构成的全球生态成为可能，它们协同演进，而不是碎裂成彼此孤立的语义孤岛。