SEO / GEO 数据治理与规范标准细则（九）：Metadata Governance——为什么企业不能只有数据，却没有描述数据的标准？

系列专题：SEO / GEO 数据治理与规范标准细则

本篇主题：Metadata Governance / 元数据标准化、语义管理与生命周期治理

发布日期：2026年10月21日

关键词：Metadata Standard、Business Glossary、Metadata Registry、Data Dictionary、Semantic Metadata、Data Catalog、Data Lineage、Metadata Quality、Metadata Lifecycle

一家工业设备企业已经建立了相对完善的数据管理体系。

工程部门负责批准产品技术参数，PIM保存标准产品数据，WordPress负责对外发布产品页面，销售系统生成报价，AI知识库为客服与业务人员提供技术问答。

前八篇讨论的治理机制，也正在逐步落实。

关键数据具备Source of Truth。数据变更能够追溯Provenance。质量检测已经进入自动化流程。Producer与Consumer之间建立了Data Contract。

但一次看似普通的产品资料更新，仍然造成了严重的信息混乱。

工程部门使用的字段叫：

rated_power_kw

PIM系统中叫：

power_kw

WordPress自定义字段中叫：

product_power

销售表格中叫：

electrical_capacity

而AI知识库将这些字段统一理解成：

Power Requirement。

系统之间的数据同步没有报错。字段类型也没有错误。甚至所有数值都可以正常读取。

但问题出现了。

工程部门所说的Rated Power，指的是特定配置下的额定功率。

销售人员使用的Electrical Capacity，可能是在询问场地的供电能力。

而AI回答中的Power Requirement，又可能被理解成完整的供电需求。

这三个概念有关联，却并不必然相同。

更危险的是，数据系统没有记录这种区别。

于是，当客户询问：

“这款设备的现场供电需要满足什么条件？”

AI从知识库中找到：

rated_power_kw = 82

便回答：“设备需要82 kW的供电容量。”

这里的82 kW可能是准确的额定功率，却不足以直接构成完整的现场供电要求。

错误并不是因为AI没有读取到数据，也不是因为Data Contract发生了技术性违约。

真正的问题是：

企业统一了数据的传输，却没有统一数据的含义。

这就是第九篇必须解决的问题。

Metadata Governance。

一、为什么有了Data Contract，还需要Metadata Governance？

第八篇已经建立了Data Contract，要求生产者和消费者对数据结构、字段语义、质量规则、版本兼容与变更流程达成明确约定。

那么，为什么还需要独立讨论Metadata？

因为Data Contract通常围绕某个具体数据交付边界展开。而Metadata Governance要解决的是跨越多个数据接口、系统和业务领域的统一描述问题。

例如，企业可能同时拥有产品数据契约、客户数据契约、报价数据契约、网站内容数据契约、营销分析事件契约、AI知识库文档契约。

这些契约都可能包含一个叫product_id的字段。

但它们是否使用相同的业务实体定义？是否采用同一套产品身份标识？是否存在不同的版本范围？某个系统中的产品系列ID，是否被另一个系统误认为具体产品型号ID？

这些问题并不能仅靠每份Data Contract各自定义字段来解决。

企业还需要一个跨系统的语义管理基础。

它必须让不同团队能够共同回答：

这个字段到底是什么意思？

它与哪个业务概念对应？

该概念由谁定义？

有哪些允许使用的名称？

哪些字段虽然名称相似，却不能等同？

某个定义改变以后，哪些系统受到影响？

因此，第八篇与第九篇之间的关系可以概括为：

Data Contract约束数据如何交付。

Metadata Governance管理这些约定所依赖的统一描述、定义和关系。

前者控制接口，后者建立能够被多个接口共同复用的语义基础。

二、Metadata究竟是什么？

Metadata通常被称为：描述数据的数据。

这是一个有用的入门解释，但对于企业实际应用来说，还不够。

因为Metadata描述的对象不只有数据表。

它也可以描述数据集、文件、业务概念、产品属性、分析指标、API、数据处理任务、网站内容、AI知识文档，以及这些对象之间的关系。

ISO/IEC 11179-1:2023《Information technology — Metadata registries — Part 1: Framework》为理解元数据和元数据注册提供了基础框架。

该标准明确将元数据理解为对数据的描述，其关注重点是数据描述与注册管理，而不是试图定义所有类型的元数据系统。

官方来源：https://www.iso.org/standard/78914.html

在本系列中，我们进一步采用一个面向SEO/GEO工程实践的定义：

Metadata是用于识别、解释、管理、发现、验证及正确使用数据和知识资产的结构化描述信息。

例如：

rated_power_kw = 82

这是一条数据。

而下面这些信息属于描述该数据的Metadata：

Business Name:
Rated Power

Business Definition:
Approved rated power
for a specified configuration

Data Type:
Decimal

Unit:
kW

Applicable Context:
standard_50hz

Source of Truth:
PLM

Data Owner:
Engineering

Effective Version:
V4.2

Allowed Use:
Product Technical Specification

前者告诉系统：值是多少。

后者告诉系统：这个值是什么、在什么条件下成立，以及应当怎样使用。

这两部分共同决定数据能否真正转化为可靠知识。

三、Metadata与Data并不是永远固定的两种对象

Metadata并不是某种永远独立于Data之外的数据类型。

一项信息究竟是Data还是Metadata，取决于当前讨论的对象和使用场景。

例如，对于产品记录而言，unit = kW是描述技术参数的元数据。

但对于企业的数据字典系统而言，kW本身又可以成为一个受治理的记录。

它可以拥有标准名称、符号、适用维度、定义来源、允许的换算关系、审批版本。

所以：

Metadata本身也需要Metadata。

这不是无限增加描述层级的理由。

而是提醒企业：只要某项描述信息被多个系统依赖，并可能影响业务判断，它就应该受到适当治理。

元数据治理最终要防止的，正是这种情况：

用于解释数据的规则，自己却没有统一解释。

四、SEO/GEO企业应该如何分类Metadata？

在工程实践中，可以将Metadata按主要治理目的分为六类。

需要说明：这是一套面向本系列业务场景的实施分类，并非ISO/IEC 11179规定的唯一六类分类体系。

类别	主要描述内容	典型示例
Business Metadata	业务概念与定义	产品型号、有效询盘、额定功率
Technical Metadata	技术结构与类型	字段、表、Schema、API、数据类型
Operational Metadata	运行与处理状态	同步时间、任务结果、更新频率
Governance Metadata	权责及使用规则	Owner、Steward、权限、生命周期
Provenance Metadata	来源与变更历史	Source ID、Evidence、Lineage
Quality Metadata	数据质量信息	规则、检测结果、异常、质量状态

这六类信息不应被看作六个互不相干的数据库。

它们是同一个数据资产的不同观察维度。

Business Metadata：解决“业务上是什么意思”

例如，lead到底代表一次表单提交、一条CRM联系人记录，还是经过验证的有效销售线索？

如果没有明确业务定义，数据团队即使可以计算Lead Count，也无法保证营销部门和销售部门正在讨论同一项指标。

Technical Metadata：解决“技术上怎样表达”

例如：

field_name: rated_power_kw
type: decimal
nullable: false
source_table: product_facts

这些信息让数据处理程序能够读取、校验和转换数据，但字段类型无法自动解释业务含义。

Operational Metadata：解决“系统怎样运行”

例如：数据最近一次同步成功是什么时候？一次导入处理了多少条记录？是否出现失败或延迟？下游消费系统当前使用的是哪个快照？

这些信息直接影响企业判断数据是否仍然可用。

Governance Metadata：解决“谁能决定怎样使用”

例如：Data Owner是谁？哪些字段可以公开？某条记录是否允许进入AI知识库？版本废弃以后是否仍可用于历史查询？

这些条件决定信息是否具有使用资格。

Provenance Metadata：解决“从哪里来、经过什么”

它延续第六篇的数据追溯体系，记录Source、Evidence、Transformation和下游依赖。

Quality Metadata：解决“是否满足要求”

它延续第七篇的数据质量体系，记录Quality Rule、检测时间、检测结果、Incident和Admission Decision。

真正有效的Metadata Governance，应使这些信息可以相互连接，而不是分别维护六份彼此不一致的登记表。

五、为什么Metadata治理必须先从Business Glossary开始？

企业最容易犯的错误，是一开始就建立复杂的数据目录。

系统自动扫描数据库，生成了几千张表和数万个字段。

但团队仍然不知道：哪些字段代表同一项业务概念，哪些字段只有名称相似，哪些指标可以直接比较，哪些术语已经废弃。

这种情况下，企业拥有的只是大量Technical Metadata，却没有形成一致的Business Meaning。

所以对于多数SEO/GEO应用，本系列建议从Business Glossary开始。

Business Glossary，即业务术语表。

它不是普通的中英文词汇对照表，也不只是网站关键词库。

它真正的作用，是为企业的重要业务概念建立统一、经过批准、可跨系统引用的定义。

例如：“产品型号”“额定功率”“标准配置”“有效询盘”“询盘转化率”“内容发布状态”“权威数据源”。

每一个概念都应当具有稳定身份，而不是依赖某个系统中的显示名称。

六、Business Glossary最重要的不是名称，而是Concept ID

假设三个系统都使用power，但工程部门指额定功率，售后部门指运行功耗，销售部门指场地供电能力。

如果只根据名称建立映射，就可能错误地把三个概念合并。

正确方式应该是先定义概念。

例如：

CONCEPT-ENG-001:
Rated Power

CONCEPT-ENG-002:
Operating Power Consumption

CONCEPT-PROJECT-003:
Site Electrical Supply Requirement

然后将系统字段分别关联到这些概念。

这样，即使不同系统使用相同字段名称，也不会自动被视为同一个业务含义。

反过来，如果不同系统使用不同的名称，但它们确实代表同一项概念，也可以通过Concept ID建立关系。

这形成了一条重要原则：

名称可以变化，业务概念的身份和定义不能在未经审批的情况下被悄悄改变。

如果一个概念的核心含义发生实质变化，更稳妥的方式可能是建立新的Concept ID，并明确记录与旧概念的关系，而不是在旧Concept ID下直接重写定义，使历史数据失去解释依据。

七、W3C SKOS：怎样让业务术语具有机器可理解的关系？

W3C在2009年8月18日发布的SKOS Recommendation，为知识组织体系提供了标准化数据模型。

SKOS可以描述概念、首选名称、替代名称、隐藏检索名称、概念之间的上下位关系、相关关系、概念定义和说明。

官方来源：https://www.w3.org/TR/skos-reference/

对于Business Glossary，最重要的是几个属性。

SKOS属性	作用	实际用途
skos:Concept	定义一个概念资源	建立业务概念身份
skos:prefLabel	首选标签	标准名称
skos:altLabel	替代标签	同义称呼、简称
skos:hiddenLabel	隐藏标签	检索用历史名称或拼写变体
skos:definition	概念定义	统一业务含义
skos:broader	更广义的概念	分类与概念层级
skos:narrower	更狭义的概念	子类或细分概念
skos:related	相关概念	关联但不等同的术语

例如，企业可以将Rated Power与Electrical Supply Requirement建立相关关系，但不能因为二者相关，就认为它们可以互相替代。

这对于AI知识系统尤其重要。

Related不等于Equivalent。

Alternative Label也不应该被用来合并实际含义不同的概念。

SKOS支持多语言标签，并规定一个概念在相同语言标签下不能存在多个首选词汇标签。

这能够为企业建立中英文业务术语管理提供标准基础。

但SKOS本身并不自动证明某个术语的工程定义正确。

概念含义仍然需要相应Data Owner批准。

八、建立第一份可执行的Business Glossary Record

下面继续使用额定功率案例。

concept_id: CONCEPT-ENG-001

preferred_label:
  en: Rated Power
  zh-CN: 额定功率

alternative_labels:
  en:
    - Rated Electrical Power

definition:
  en: >
    Approved rated power of the specified
    product configuration under the
    defined operating conditions.

business_domain: Engineering

context_required:
  - product_id
  - configuration_id
  - operating_conditions

canonical_unit: kW

owner_role: Engineering Data Owner
steward_role: Product Data Steward

related_concepts:
  - CONCEPT-PROJECT-003

status: APPROVED
version: "1.0"

这是一份本系列提出的内部YAML示例，并不是SKOS或ISO/IEC 11179的原生配置文件。

真正的工程价值，在于把原本散落在部门经验、Excel表头和系统代码中的定义，转化为统一登记的对象。

这里必须做一项重要区分。

Rated Electrical Power只有在企业正式确认其可作为同一概念的替代称呼时，才能加入Alternative Labels。

而Power Requirement如果在实际业务中可能代表更广泛的供电要求，就不应仅因为语言相似而成为同义词。

这样才能避免AI、搜索系统和人员将相关概念错误合并。

九、术语表不是关键词表，关键词表也不能代替业务术语标准

SEO人员通常非常熟悉关键词研究。

例如：

industrial equipment power
equipment electrical requirement
rated power
power consumption
power supply capacity

这些搜索词能够反映用户的表达方式，但它们并不自动具有相同的业务语义。

用户可能是在查询产品规格，也可能是在寻找现场安装要求，还可能是在比较设备能耗。

如果企业把这些词全部映射到一个Power概念，就可能失去识别不同User Task的能力。

因此：

SEO Keyword Vocabulary与Business Glossary应该相互关联，但不能直接等同。

关键词库可以记录用户怎样表达需求。

Business Glossary应记录企业怎样正式定义业务概念。

二者之间可以建立关系：

Search Query
     ↓
User Intent
     ↓
Business Concept
     ↓
Approved Data / Knowledge
     ↓
Relevant Content

这个流程让企业能够在理解搜索需求的同时，避免用错误的业务概念回答问题。

它也与“SEO/GEO内容创作规范”中强调的User Task直接衔接。

十、从Business Glossary进入Field Semantic Standard

有了统一术语，还需要把概念映射到具体技术字段。

例如：

Business Concept:
CONCEPT-ENG-001
        ↓
PLM:
rated_power_kw
        ↓
PIM:
power_rating
        ↓
WordPress ACF:
product_rated_power_kw

如果三个字段都经过验证，确实指向同一项业务概念，就可以建立Mapping。

但Mapping不应该只保存：

A = B

还需要明确：字段类型、单位、配置条件、是否存在转换、是否具有版本差异、映射由谁批准、映射在什么时间范围内有效。

例如：

来源字段	目标字段	转换	语义关系
rated_power_kw	product_rated_power_kw	直接映射	已验证等价
rated_power_w	rated_power_kw	W ÷ 1000	条件等价
peak_power_kw	rated_power_kw	不允许自动转换	不等价
site_supply_requirement	rated_power_kw	不允许直接映射	相关但不等价

这里最有价值的，并不是告诉系统哪些字段可以合并，而是明确：

哪些字段禁止在缺少额外证据时被视为相同。

在AI自动化大规模处理数据时，这种限制非常重要。

十一、Field Semantic Standard至少需要管理哪些属性？

本系列建议对Critical Data Element建立统一字段元数据标准。

元数据字段	作用
field_id	稳定字段身份
technical_name	技术字段名
business_concept_id	对应业务概念
business_definition	审批后的字段定义
data_type	数据类型
unit	单位
precision	精度
nullable	是否允许为空
applicable_context	适用条件
source_of_truth	权威数据来源
owner_id	业务责任人或角色
steward_id	治理责任人
quality_rule_refs	关联质量规则
contract_refs	关联数据契约
provenance_refs	来源与追溯关联
allowed_use	允许使用范围
classification	数据敏感性分类
lifecycle_status	生命周期状态
metadata_version	元数据版本

这些属性不是每个普通字段都必须全部配置。

对于一般辅助字段，可以采用精简模型。

但对于产品工程参数、正式价格、合规信息、营销核心指标、AI知识库关键Claim，应优先建立完整定义。

特别需要避免：

Data Type正确，但Business Meaning缺失。

因为这往往是系统之间出现无声数据错误的起点。

十二、ISO/IEC 11179：Metadata Registry为什么需要正式注册机制？

如果企业只是把术语和字段说明记录在多个Excel中，就可能很快再次出现新的问题。

一个部门修改定义，另一个部门仍然使用旧版本。

某个字段已经停用，却继续出现在新接口。

业务Owner已经调整，但登记表仍然指向原责任人。

为了防止这些情况，Metadata需要正式的Registration机制。

ISO/IEC 11179-3:2023定义了元数据注册系统共用设施的概念模型。

根据ISO公开的标准摘要，该标准覆盖注册项的身份识别、指定与定义、注册、分类以及注册项之间的映射。

2026年5月发布的该标准修订补充文件，进一步涉及注册项映射能力的增强。

官方来源：

https://www.iso.org/standard/78915.html

https://www.iso.org/standard/89914.html

这说明，Metadata Registry的重点不只是保存字段列表，而是建立一套可长期管理的注册对象和关系。

但也必须明确：企业若只是参考ISO/IEC 11179的理念，自行设计字段模型，并不能因此宣称系统已经完整符合该标准。

正式标准符合性仍需根据标准具体要求进行评价。

十三、Metadata Registry究竟是什么？

Metadata Registry，即元数据注册体系。

它负责为重要元数据对象建立身份、名称、定义、分类、责任、状态、版本、关系、审批和变更记录。

例如：

metadata_id:
META-PRODUCT-POWER-001

object_type:
Data Element

business_concept:
CONCEPT-ENG-001

technical_name:
rated_power_kw

owner:
Engineering

source_system:
PLM

registration_status:
ACTIVE

metadata_version:
1.2.0

这个Record并不需要保存所有产品的实际功率值。

它主要描述：rated_power_kw是什么字段，以及企业怎样管理它。

具体业务数据依然可以保存在PLM、PIM或其他业务系统中。

因此：

Metadata Registry不是把全公司数据重新复制一次。

它应该管理数据资产的描述、语义和治理关系，并尽量与原系统建立关联。

十四、Metadata Registry、Data Catalog与Business Glossary有什么区别？

三个概念经常被当成同一件事，实际上，它们的治理重点不同。

系统或能力	核心问题	主要管理对象
Business Glossary	业务概念是什么意思？	概念、术语、定义、关系
Metadata Registry	元数据对象如何登记和维护？	ID、定义、状态、版本、映射
Data Catalog	企业拥有哪些数据资产，怎样发现？	数据集、服务、表、文件等
Schema Registry	数据结构有哪些版本，是否兼容？	Schema、版本、兼容策略

这些能力可以由同一个软件平台提供，但概念上必须区分。

例如，Data Catalog帮助团队找到“企业有哪些产品数据集？”

Business Glossary帮助团队理解“Rated Power是什么意思？”

Metadata Registry负责说明“哪个正式注册的字段对应这个概念？”

Schema Registry则能够帮助系统判断“新版数据结构能否兼容旧版消费者？”

如果将四者混为一谈，企业可能采购了一套具备数据搜索功能的平台，却发现它不能有效管理业务术语与字段语义。

十五、W3C DCAT 3：数据目录为什么需要统一元数据模型？

2024年8月22日，W3C正式发布DCAT Version 3 Recommendation。

DCAT是一套基于RDF的数据目录词汇，用于描述数据集、数据服务及相关资源，促进不同数据目录之间的互操作。

DCAT 3还扩展了数据版本和数据集系列等描述能力。

官方来源：https://www.w3.org/TR/vocab-dcat-3/

例如，一个企业可能维护PLM产品主数据集、PIM发布数据集、CRM客户询盘数据集、SEO搜索表现数据集、营销归因数据集、AI知识库文档索引。

如果每个系统采用完全不同的目录元数据方式，就很难进行统一发现和治理。

DCAT提供了一种标准化描述数据目录资源的基础。

这里需要注意：DCAT主要面向数据集、数据服务等目录资源的描述与互操作。

它并不自动解决企业所有字段级语义治理问题。

对于字段级业务定义，可以结合企业自己的Data Dictionary、Business Glossary以及适当的元数据注册模型实现。

因此：

DCAT解决目录互操作的重要问题，但不等于完整的企业Metadata Governance。

十六、Dublin Core：如何描述一份文件或知识资源？

并非所有企业数据都以数据库表的形式存在。

SEO/GEO知识体系中还有大量PDF、研究报告、技术手册、文章、案例文档、视频、图像、AI生成的摘要。

对于这些资源，也需要统一描述。

Dublin Core Metadata Initiative维护的DCMI Metadata Terms提供了多个通用元数据术语，例如：

identifier、title、description、creator、publisher、language、modified、source、license、rights。

官方来源：https://www.dublincore.org/specifications/dublin-core/dcmi-terms/

这些术语可以帮助不同内容系统采用更一致的资源描述方式。

例如，企业可能需要记录一份技术手册：

document_id:
DOC-FW30-V42

title:
FW-30 Technical Specification

language:
en

publisher:
Engineering Department

version:
4.2

source:
PLM-DOC-008

rights:
Internal Use

status:
Approved

但不能认为只要使用了DCMI术语，就自动完成了文档许可检查、质量验证和访问控制。

Metadata标准提供描述能力。

Governance机制决定这些描述如何被审核、维护与实际执行。

十七、Metadata Registry的最小可运行数据模型

对于多数中小型企业，本系列建议先建立四类核心对象。

1. Business Concept

管理业务概念及其定义，例如CONCEPT-ENG-001，Rated Power。

2. Data Element

管理字段的技术表达和业务关联，例如FIELD-PLM-001，rated_power_kw。

3. Data Asset

管理数据集、API、文件和知识资产，例如ASSET-PIM-PRODUCTS。

4. Metadata Relationship

管理不同元数据对象之间的映射与依赖。

例如：

FIELD-PLM-001
    ├── represents
    │   CONCEPT-ENG-001
    │
    ├── belongs_to
    │   ASSET-PLM-SPECS
    │
    ├── governed_by
    │   CONTRACT-PRODUCT-001
    │
    └── validated_by
        RULE-DQ-003

这四类对象可以作为第一版Metadata Registry的基础。

但对象之间还应根据需要建立更精确的关系类型，例如represents、derived_from、mapped_to、governed_by、owned_by、consumed_by、supersedes。

必须注意，这些关系名称是本系列提出的内部注册模型示例，不应直接冒充W3C PROV或其他标准已经定义的全部关系。

企业如果需要跨系统语义互操作，应进一步建立与相应标准词汇的正式映射。

十八、Metadata不应只登记名称，还必须登记关系的有效性

假设系统登记：

PLM.rated_power_kw
maps_to
PIM.power_kw

但过了两年，PIM中的power_kw被重新定义为另一种功率指标。

如果映射关系没有随之更新，Metadata Registry就会产生危险的错误。

因此，一条关键Mapping至少应该记录映射来源、映射目标、关系类型、适用Context、必要转换规则、审批角色、生效时间、失效时间和映射版本。

例如：

{
  "mapping_id": "MAP-PRODUCT-0042",
  "source_field_id": "FIELD-PLM-001",
  "target_field_id": "FIELD-PIM-008",
  "relation": "equivalent_under_context",
  "context": "standard_50hz",
  "transformation": "identity",
  "approved_by_role": "Engineering Data Owner",
  "status": "ACTIVE",
  "version": "1.0"
}

这属于本系列的示例格式。

它表达的重点是：

字段Mapping本身也是需要版本与审批的治理对象。

不能因为曾经建立过映射，就假设它永远有效。

十九、Metadata Quality：怎样判断元数据本身是否合格？

到这里，我们已经建立元数据分类、业务术语、字段标准和Metadata Registry。

但还存在一个问题：

如果Metadata本身出现错误，系统怎么办？

例如：一个字段拥有错误定义；两个不同业务概念被赋予相同Concept ID；Data Owner已经不存在；数据资产标记为Active，但实际来源已经废弃；映射关系指向旧字段。

这些都属于Metadata Quality问题。

因此，元数据也必须进入第七篇建立的Data Quality体系。

本系列建议优先检查六个方面。

质量维度	核心问题	典型检测
Completeness	必填元数据是否齐全？	定义、Owner、状态非空
Validity	结构是否符合约束？	ID、类型、状态枚举合法
Uniqueness	是否出现身份冲突？	同一作用域ID唯一
Semantic Consistency	是否存在定义与映射冲突？	单位、概念、关系检查
Currentness	元数据是否仍然有效？	Owner有效、版本未废弃
Traceability	修改是否可追溯？	版本、审批、变更记录

这六项是本系列建议采用的最小Metadata Quality检查模型，不是ISO/IEC 11179规定的完整六维质量体系。

其中，机器可以自动检查字段是否有Definition，但Definition是否真正符合业务事实，通常还需要具备Authority的人员审核。

因此：

Metadata Completeness不等于Semantic Correctness。

这与第七篇“准确的数据仍然可能不合格”的结论完全一致。

二十、建立Metadata Quality Rules

例如，企业可以为关键字段建立以下规则。

rule_set_id: META-QUALITY-001
rule_set_version: "1.0"

scope:
  object_type: CriticalDataElement

rules:
  - id: META-001
    check: business_concept_exists
    severity: critical

  - id: META-002
    check: definition_approved
    severity: critical

  - id: META-003
    check: owner_is_active
    severity: critical

  - id: META-004
    check: source_of_truth_defined
    severity: critical

  - id: META-005
    check: contract_reference_valid
    severity: important

  - id: META-006
    check: mapping_not_deprecated
    severity: important

admission:
  critical_failures_allowed: 0
  on_failure: quarantine

这些规则是概念性配置，不属于某个通用元数据平台可以直接执行的原生语法。

真正实施时，需要将各项规则连接到Business Glossary、Owner Registry、Source Registry、Data Contract Registry、Mapping Registry。

如果系统只是检查字段文本不为空，就不能声称已经确认其业务定义正确。

例如：

definition:
This is a power value.

形式上存在定义，但它显然不足以支撑关键工程参数的标准化应用。

因此，对于Critical Data Element，Metadata Quality Gate应当同时覆盖结构验证与必要的语义审批。

二十一、Metadata Quality Threshold应该怎样设定？

企业可能统计：“关键字段Metadata完整率为98%。”

但还必须进一步问：缺失的是哪些Metadata？

如果缺失的是非关键标签，可以进入待修复队列。

但如果缺失的是Source of Truth或Data Owner，则可能导致整个数据使用链路无法明确权责。

因此，不建议使用单一总体分数作为最终准入依据。

本系列建议采用：

Critical Metadata Gate + Metadata Quality Scorecard。

对于Critical Data Element，可设置以下示例要求：

检查项	示例要求	失败行为
Concept ID	必须存在且有效	Block
Business Definition	必须完成审批	Block
Data Owner	必须有效	Block
Source of Truth	必须明确	Block
Contract Reference	必须满足接口策略	Block / Conditional
Mapping Status	不得依赖已废弃映射	Block
Optional Description	按批准阈值管理	Warning

这不是说企业所有Metadata都必须100%完整。

而是说：决定关键事实能否被正确使用的核心描述信息，不应因为总体完成率很高而被忽略。

对于非关键Metadata，可以按照实际成本和风险定义不同要求。

二十二、Metadata Lifecycle：为什么元数据也需要生效和退役机制？

许多企业建立元数据登记表以后，就不再维护。

过了一段时间：字段已经改名，系统已经迁移，Owner已经调整，业务定义发生变化，旧术语仍然存在，但Registry里没有任何状态变化。

最终，原本为了消除混乱建立的Metadata Registry，自己变成了新的混乱来源。

因此，Metadata也必须拥有生命周期。

本系列建议采用以下基础状态：

DRAFT
   ↓
UNDER_REVIEW
   ↓
APPROVED
   ↓
ACTIVE
   ↓
DEPRECATED
   ↓
RETIRED

其中：

Draft表示定义正在编写，尚不能作为生产环境的权威解释。

Under Review表示进入评审流程。

Approved表示完成正式审批，但不一定已经部署到所有系统。

Active表示当前有效且被允许在规定范围内使用。

Deprecated表示已经不建议用于新系统，现有依赖需要按计划迁移。

Retired表示不再允许用于新的生产用途，并根据需要保留历史记录。

实际工作中，还可能存在Rejected、Suspended等辅助状态。

但不应为每一种细微情况都无限增加状态。

重点是确保状态真正影响数据使用策略。

二十三、Metadata定义发生变化，是否一定需要新版本？

这取决于变化的性质。

例如：修正一个不改变含义的错别字，增加英文翻译，补充字段说明。

与以下变化并不相同：将额定功率重新定义为峰值功率，改变金额字段是否含税，改变询盘指标的去重规则，改变国家或地区的适用范围。

后一类变化可能直接影响现有Consumer的业务结果。

因此，应区分：

Editorial Change：文字表达修订，但业务含义不变。

Structural Change：元数据结构或字段约束发生变化。

Semantic Change：业务定义、计算口径、适用范围或概念身份发生变化。

Governance Change：Owner、权限、审批或允许用途发生变化。

其中Semantic Change应当触发更严格的影响分析。

对于已经被大量内容和系统依赖的核心概念，如果含义发生重大变化，通常应考虑创建新Concept ID或显式的新语义版本，并保留旧版本的历史解释能力。

因为：

企业不能为了让现在的数据变得统一，就悄悄改写历史数据当时的定义。

二十四、Metadata Drift：为什么字段没有删除，也可能发生严重故障？

第八篇重点讨论Breaking Change。

但Metadata Governance还需要关注另一种更隐蔽的问题：

Metadata Drift。

即元数据实际状态逐渐偏离了已批准的描述和定义。

例如：

Data Contract仍然声明：

rated_power_kw:
Approved rated power

但上游开发团队将该字段改为保存另一种功率指标。

技术字段仍然存在。JSON Schema仍然有效。消费者程序也没有发生报错。

可是业务语义已经改变。

这是一种比字段删除更难发现的风险。

因为：

结构没有坏，意义已经变了。

因此，Metadata Drift Detection不应只检查Schema Diff。

还需要检查Business Definition变化、单位变化、字段映射变化、Authority变化、Owner变化、分类与权限变化、允许用途变化。

当发现关键元数据与批准版本存在差异时，应将其视为正式治理事件，而不是默认为普通文档更新。

二十五、从Metadata Drift进入变更影响分析

如果一个核心概念被修改：

哪些字段会受到影响？哪些Data Contract使用这个概念？哪些WordPress页面显示相关数据？哪些Schema映射依赖这个定义？哪些PDF需要重新生成？哪些AI知识库Chunk需要重新验证？哪些分析指标需要重新计算？

真正成熟的Metadata Registry应能够通过关系信息完成查询。

例如：

CONCEPT-ENG-001
      ↓
FIELD-PLM-001
      ↓
CONTRACT-PRODUCT-001
      ↓
FIELD-PIM-008
      ↓
WORDPRESS-FIELD-018
      ↓
PRODUCT-PAGE-042
      ↓
RAG-DOCUMENT-104

当概念或字段定义变化时，这条关系链可以帮助识别可能受影响的下游资产。

但需要注意：

记录了Metadata Relationship，并不意味着系统已经自动实现Impact Analysis。

影响分析仍然需要读取关系、判断有效版本、识别依赖状态，并生成相应处理任务。

因此本系列建议逐步建立：

Metadata Change → Dependency Discovery → Impact Assessment → Approval → Migration → Verification。

这样第六篇的Data Provenance、第八篇的Data Contract与本篇Metadata Governance才能真正连接。

二十六、WordPress应该怎样使用Metadata Governance？

对于使用WordPress构建外贸独立站的企业，这个问题需要落实到具体字段和工作流程。

首先要区分三种不同层次。

第一层：企业内部的数据语义Metadata。

例如rated_power_kw的正式定义、Owner、单位和Source of Truth。

第二层：WordPress内容管理Metadata。

例如文章ID、Slug、作者、发布时间、分类、标签、ACF自定义字段。

第三层：SEO展示相关Metadata与结构化数据。

例如Title、Meta Description、Canonical URL、Robots指令、JSON-LD。

三者有关联，但不能直接等同。

WordPress的post_meta或ACF字段，更多是技术存储与内容管理机制。

Rank Math或其他SEO插件生成的Title、Description与JSON-LD，则服务于网页表达和搜索相关功能。

而企业内部的业务概念定义、工程参数Authority、质量规则与使用权限，不能仅靠SEO插件自动建立。

Google Search Central明确要求，页面结构化数据应真实反映页面内容，避免使用无关或误导性信息；即使符合技术要求，也不保证获得Rich Result展示。

官方来源：https://developers.google.com/search/docs/appearance/structured-data/sd-policies

因此，本系列建议：

先治理业务数据及其Metadata，再将经批准的数据映射到WordPress内容与适用的结构化数据。

而不是先由SEO插件生成字段，再由业务部门反向接受插件的默认定义。

二十七、一个适合WordPress的Metadata传播链路

可以建立如下流程：

Business Glossary
        ↓
Approved Field Definition
        ↓
Metadata Registry
        ↓
PIM Data Contract
        ↓
Canonical Field Mapping
        ↓
WordPress REST API
        ↓
ACF / Page Template
        ↓
Visible Content
        +
Applicable Structured Data

这里的关键是：

WordPress使用的字段映射应具有可追溯的业务概念和契约版本。

例如：

concept_id:
CONCEPT-ENG-001

source_field:
PLM.rated_power_kw

canonical_field:
PIM.rated_power_kw

wordpress_field:
product_rated_power_kw

metadata_version:
1.2.0

当工程定义发生变化时，团队能够知道哪些页面需要重新检查。

这里也要注意，不是所有内部Metadata都应该公开。

例如内部审批信息、供应商商业秘密、客户合同、受权限限制的工程证据。

这些信息可以留在治理系统中。

WordPress前台只展示经过授权、对用户有实际价值的内容。

Metadata Governance不等于把全部内部Metadata公开给搜索引擎。

二十八、GSC和GA4：为什么营销指标必须有Business Metadata？

产品数据之外，SEO和数字营销分析也是最容易发生术语混乱的领域。

例如团队在月度报告中写：“Organic Traffic增长了25%。”

这个数字可能来自Google Search Console、GA4、某个第三方SEO工具。

但它们的统计对象并不一定相同。

GSC的Clicks是搜索表现报告中的点击指标。

GA4的Sessions则属于网站分析体系中的会话指标。

即使二者都被团队称为“自然流量”，也不能据此认为它们可以直接互换。

Google关于Search Console表现报告的官方帮助文档明确说明，Clicks的计数与搜索结果中的点击行为有关，而且报表在Property和Page等不同聚合层次下可能采用不同的计算方式。

官方参考：

https://support.google.com/webmasters/answer/10268906

https://support.google.com/webmasters/answer/17011364

因此，一个合格的SEO指标Business Glossary应当记录：

Metric ID、标准名称、数据来源、具体定义、计算公式、统计粒度、维度、时区、数据刷新状态、筛选条件、Owner、适用报表。

例如：

项目	GSC Clicks	GA4 Organic Sessions
Metric ID	METRIC-GSC-CLICKS	METRIC-GA4-ORG-SESSIONS
来源	GSC	GA4
统计对象	搜索结果点击	归属于自然搜索的会话
主要用途	搜索可见性与点击分析	站内访问与转化分析
能否直接等同	否	否

在内部报告中，这两个指标可以进行关联分析。

但不能未经口径说明就简单相减，或将其差值直接解释为数据错误。

分析数据的Metadata标准，决定了管理层能否正确理解数据结果。

二十九、AI知识库为什么更需要Metadata，而不是只需要Embedding？

对于RAG系统，Metadata的重要性更加明显。

假设企业导入了两份产品技术规范。

旧版本：

Document:
FW30-SPEC-V3.8

Rated Power:
75 kW

新版本：

Document:
FW30-SPEC-V4.2

Rated Power:
82 kW

如果知识库只保存：

chunk_text
embedding

系统就可能在检索中遇到两个语义相近、但适用时间不同的Chunk。

这时单纯依赖文本相似度，不能可靠决定哪个版本应当回答当前用户的问题。

因此，RAG需要Document-level与Chunk-level Metadata。

例如：

{
  "chunk_id": "CHUNK-FW30-1042",
  "document_id": "DOC-FW30-V42",
  "source_id": "SOURCE-PLM-008",
  "product_id": "FW-30",
  "configuration_id": "standard_50hz",
  "concept_ids": [
    "CONCEPT-ENG-001"
  ],
  "document_version": "4.2",
  "knowledge_status": "VERIFIED",
  "effective_from": "2026-09-20",
  "allowed_use": [
    "technical_reference",
    "product_content"
  ]
}

但必须进一步强调：

仅仅存储这些Metadata，还不等于系统会自动遵守。

检索程序必须实际执行Source Admission、Context Filtering、Version Filtering、Permission Checking、Evidence Validation。

只有Metadata进入检索决策逻辑，才可能产生治理效果。

所以：

Metadata-rich Retrieval，不等于Governed Retrieval。

前者拥有描述信息，后者会依据这些信息执行准入和过滤。

三十、Metadata还能帮助AI避免概念混淆

回到开头的例子。

用户询问：“设备现场需要什么供电条件？”

系统通过Business Glossary识别：

User Task:
Site Power Planning

然后映射到相应业务概念：

CONCEPT-PROJECT-003
Site Electrical Supply Requirement

而不是直接把问题映射成：

CONCEPT-ENG-001
Rated Power

系统可以进一步发现：现场供电要求可能需要结合设备配置、额定功率、电压、频率及其他工程条件进行评估。

如果知识库只拥有额定功率，便应回答：

现有数据提供了额定功率，但不足以独立确认完整现场供电要求。

这就是Semantic Metadata对AI知识应用的重要价值。

它不保证AI永远不会出错，但可以使企业建立更清晰的概念区分、检索约束和证据边界。

对于GEO研究，其真正意义在于：

帮助企业知识体系更准确地表达“我们知道什么，以及这些知识适用于什么问题”。

不能由此推断，增加Metadata字段就必然提高生成式搜索引用概率。

三十一、Metadata Governance必须形成可执行的准入门禁

到这里，企业已经建立Business Glossary、Field Semantic Standard、Metadata Registry、Metadata Quality Rules、Lifecycle Status、Metadata Mapping。

接下来需要把它们连接到实际的生产流程。

本系列建议建立：

Metadata Admission Gate。

它位于关键数据正式进入知识层和发布层之前。

Data Received
      ↓
Data Contract Validation
      ↓
Metadata Identity Check
      ↓
Business Concept Check
      ↓
Owner & Authority Check
      ↓
Metadata Quality Check
      ↓
Context & Lifecycle Check
      ↓
Data Quality Gate
      ↓
Usage Authorization
      ↓
ADMIT / CONDITIONAL / QUARANTINE / REJECT

这条链路必须根据实际风险执行。

例如，非关键文章标签缺失，可以允许进入编辑待补流程。

但关键工程字段缺少Business Definition或Source of Truth，就不应该直接进入正式产品参数发布流程。

同时，Metadata Admission Gate不能替代事实核验。

即使某字段拥有完整Metadata，也仍然需要检查实际数据是否准确。

三十二、Metadata Quality Incident：元数据出错以后怎么处理？

假设某Data Steward发现：PIM中的power_kw字段，错误映射到了另一个功率概念。

由于该映射被WordPress和RAG同时使用，异常可能已经传播。

这时不能只修改Metadata Registry中的一行文字。

应当建立正式事件。

至少包括：

incident_id:
META-INCIDENT-0042

affected_object:
FIELD-PIM-008

issue_type:
SEMANTIC_MAPPING_ERROR

severity:
CRITICAL

affected_assets:
WordPress Product Pages
RAG Knowledge Documents

owner:
Engineering Data Owner

status:
OPEN

然后执行：

识别错误定义、确认正确Concept、检查相关Mapping、识别已发布内容、修复注册记录、修复受影响数据、重新验证消费者、确认RAG索引状态，最后关闭事件。

这里需要特别强调：

修复Metadata不一定会自动修复已经产生的下游内容。

例如，一个WordPress页面已经将错误值写成静态HTML。

即使Metadata Registry的定义改正，已发布页面仍然需要重新同步或人工修复。

同样，AI知识库可能需要重新解析、切分或索引。

这就是为什么Metadata Governance必须与Data Lineage和Distribution Registry关联。

三十三、企业应该怎样衡量Metadata Governance效果？

本系列建议从六项基础指标开始。

Metadata Coverage Rate

已经建立规定Metadata记录的关键资产，占应治理关键资产总数的比例。

Business Definition Coverage

具有经过批准的Business Concept或业务定义的关键字段，占关键字段总数的比例。

Owner Coverage

具有有效责任角色的关键Metadata对象占比。

Semantic Mapping Coverage

需要跨系统映射的关键字段中，完成有效映射登记与审批的比例。

Metadata Freshness Compliance

在规定的更新或复核窗口内，仍然保持有效Metadata状态的对象占比。

Metadata Incident Resolution Time

发现元数据错误以后，到完成修复、复测和必要的下游验证所需时间。

这些指标必须明确分母、统计范围与质量要求。

例如Owner Coverage = 100%，并不代表Owner真的履行了职责。

如果所有记录都填写同一个无人管理的邮箱，指标仍然可能达到100%。

所以不能只检查：有没有值。

还应检查：该值是否有效。

这就是元数据质量治理与普通字段填充率统计之间的区别。

三十四、中小型B2B企业如何用30天建立第一版Metadata Governance？

对于已经使用WordPress、PIM、GA4、GSC和基础自动化工具的企业，建议先从最常被复用、最容易引起业务歧义的对象开始。

不需要第一天就建设复杂的企业知识图谱。

第一周：建立业务概念清单

选择三个核心Domain：Product、Marketing Analytics、Content & Knowledge。

从中筛选20—30个关键概念。

例如Product Model、Rated Power、Product Configuration、Valid Lead、GSC Clicks、GA4 Organic Sessions、Approved Content、Verified Knowledge。

为每个概念建立稳定Concept ID和初步定义，并指定Owner。

阶段交付：

Business Glossary V1。

第二周：建立字段语义与Mapping标准

识别PLM、PIM、WordPress、GA4和知识库中的关键字段。

至少确认Technical Name、Business Concept、Data Type、Unit、Context、Source of Truth、Owner、Contract Reference。

阶段交付：

Field Semantic Dictionary + Mapping Registry。

第三周：建立Metadata Registry与质量规则

可以先使用受版本控制的YAML、JSON或关系数据库实现。

重点不是系统复杂度，而是保证唯一ID、审批状态、版本、关系、质量检查、变更历史。

至少实现必填Metadata验证、Concept ID有效性验证、Owner有效性验证、关键Mapping状态检查。

阶段交付：

Metadata Registry V1 + Metadata Quality Rules。

第四周：接入发布和变更流程

选择一条真实生产链路：

PIM
 ↓
WordPress
 ↓
Structured Data
 ↓
RAG

将关键Metadata检查放入同步或发布流程。

同时建立Metadata Change Request、Impact Analysis、Deprecation Policy、Incident Workflow。

阶段交付：

可执行的Metadata Governance Gate。

30天计划的目标不是治理企业所有字段，而是让一个关键业务流程开始使用正式、受版本管理且可验证的Metadata。

三十五、SEO / GEO Metadata Governance的MUST、SHOULD、MAY规范

以下为本系列提出的企业工程实施规则，不代表ISO、W3C或Google联合发布了SEO/GEO元数据治理强制标准。

MUST｜必须

MUST-01：关键数据元素必须具有稳定的Metadata ID或等效身份标识。

MUST-02：关键业务字段必须关联经过批准的Business Definition或Business Concept。

MUST-03：数据字段的技术名称不得被直接视为充分的业务语义定义。

MUST-04：关键Metadata必须明确Owner、治理状态及版本信息。

MUST-05：涉及核心业务含义、单位、Context或Source of Truth的修改，必须进入正式变更管理流程。

MUST-06：不同业务概念不得仅因为名称相同或相似，就被自动映射为Equivalent。

MUST-07：关键跨系统字段映射必须具有可识别的Mapping Record。

MUST-08：Metadata发生Critical Violation时，必须能够阻止相关数据进入未经批准的生产用途。

MUST-09：Metadata定义发生重大变更时，必须能够识别重要的下游依赖。

MUST-10：Deprecated或Retired元数据不得未经明确策略继续作为新的生产接口或关键知识依据。

SHOULD｜建议

企业应建立统一Business Glossary，并为重要概念维护标准名称、替代名称与必要的多语言标签。

应对关键数据字段建立Field Semantic Dictionary。

应将Metadata Registry与Source Registry、Data Contract、Quality Rule和Provenance连接。

应建立Metadata Quality Scorecard和Metadata Drift Detection。

应定期检查无Owner、无Definition、无有效Mapping和长期未复核的Metadata对象。

应为关键业务术语和字段定义建立变更审批与历史版本保存机制。

MAY｜可选

企业可以根据规模和技术成熟度逐步采用：

ISO/IEC 11179相关注册模型、SKOS、DCAT 3、DCMI Metadata Terms、Metadata API、Enterprise Data Catalog、Knowledge Graph、Automated Metadata Harvesting、Semantic Mapping Engine、Metadata Policy as Code、Automated Impact Analysis。

但不能因为引入某种技术标准，就默认企业已完成所有业务定义与质量审核。

三十六、Metadata Governance Checklist：发布前应该检查什么？

对于准备进入正式知识与内容生产链路的关键数据，至少检查：

• 是否存在稳定的Business Concept ID？
• 是否具有明确的业务定义？
• 是否存在未经批准的同义名称？
• Technical Field是否关联正确Business Concept？
• 单位、精度、Context和有效时间是否明确？
• Source of Truth和Data Owner是否有效？
• 字段Mapping是否经过验证？
• Metadata Version是否与Data Contract兼容？
• 关键Metadata是否具有有效Lifecycle Status？
• 是否存在失效的Owner或废弃字段？
• 是否能够识别Metadata Change对下游内容的影响？
• RAG文档和Chunk是否继承必要Metadata？
• WordPress输出是否与批准的业务事实保持一致？
• 是否存在Critical Metadata Quality Incident？
• 是否满足当前用途的授权和发布条件？

这些问题构成了本系列的第一版：

SEO / GEO Metadata Admission Checklist。

三十七、最终要建立的，是企业统一的数据描述能力

从第一篇写到第九篇，我们已经不再只是讨论怎样收集数据、清洗数据或者生产SEO内容。

整个体系已经逐步形成：

Source
   ↓
Data Lifecycle
   ↓
Source of Truth
   ↓
Ownership
   ↓
Source Admission
   ↓
Data Provenance
   ↓
Data Quality
   ↓
Data Contract
   ↓
Metadata Governance
   ↓
Governed Knowledge
   ↓
Content / Analytics / RAG / AI

这里需要说明：这不是要求企业在技术架构中按照上述顺序部署九套独立系统。

它表达的是治理能力之间的逻辑关系。

例如，Metadata Governance实际上需要贯穿Source、Data Quality、Data Contract和Knowledge等多个环节，而不是只存在于流水线末端。

更准确的架构应该是：

Metadata作为跨系统的统一描述层，为多个治理环节提供共同的概念、身份、状态和关系。

当企业真正建立这种能力以后：

工程部门不必反复解释Rated Power是什么意思。

WordPress不会仅根据字段名称猜测业务含义。

营销团队能够明确区分GSC Clicks与GA4 Sessions。

AI知识库可以依据Concept和Context约束检索。

Data Contract能够引用统一的业务定义。

数据质量检查能够使用经过批准的字段语义。

数据发生变化时，系统可以识别受影响的消费者。

这才是Metadata Governance真正的价值。

写在最后：数据最大的风险，不一定是错误，而是被错误理解

在AI大规模参与信息处理以前，企业的数据混乱往往依赖人工发现。

一个工程师看到错误的功率名称，会主动询问。一位经验丰富的销售人员发现配置不匹配，可能会返回技术部门核实。

但当数据开始被自动提取、转换、聚合、翻译、写入网站、生成PDF和进入AI知识库以后，系统通常不会像熟悉业务的工程师那样主动怀疑一个字段。

如果它看到：

power = 82

却不知道：

什么Power？什么单位？适用哪种配置？由谁批准？用于什么任务？与哪些概念不能混同？

那么这条数据虽然可以被机器读取，却还没有达到真正可被可靠使用的程度。

因此：

机器可读，不等于机器可正确理解。

Metadata Governance要解决的，就是让企业关键数据具有一致、明确、可管理的描述能力。

本篇最重要的结论是：

数据治理不能只治理数据值，还必须治理数据的名称、定义、上下文、身份、关系与生命周期。否则，企业可能拥有准确的数据，却仍然因为不同系统对其含义的理解不同，持续产生错误的知识和业务结果。

对SEO而言，这种能力为内容事实一致性、数据结构和分析口径提供基础。

对GEO和RAG而言，它为概念识别、上下文过滤、来源关联和知识使用策略提供基础。

对数字营销而言，它让不同系统中的指标能够被正确理解与比较。

它不会自动提高搜索排名，也不能保证AI一定引用企业。

但它能够减少企业内部因为数据含义不清、定义漂移和跨系统映射错误所导致的失真。

真正有价值的数据，不仅应该有正确的值，还应该拥有正确、明确且可持续维护的解释。

下一篇

《SEO / GEO 数据治理与规范标准细则（十）：Entity Identity & Master Data——为什么名称统一了，系统仍然可能把不同对象当成同一个？》

第九篇解决的是：企业如何统一描述数据和业务概念。

但还需要继续回答：

如果两个系统都写着FW-30，它们是否一定代表同一款产品？

如果品牌名称、公司名称、产品系列、产品型号和产品配置之间存在多层级关系，企业应该如何区分？

客户CRM中的不同名称是否代表同一家企业？

AI知识库如何避免将不同产品、不同配置或不同组织的事实混合？

第十篇将继续推进到：

Entity Identity、Master Data Management、Canonical ID、Entity Resolution、Deduplication、Identity Mapping、Golden Record、Entity Relationship与Identity Lifecycle。

最终建立：

SEO / GEO Entity Identity & Master Data Standard。

参考依据与标准边界

1. ISO/IEC 11179-1:2023 — Metadata Registries: Framework

为理解元数据及元数据注册提供基础框架。

官方来源：https://www.iso.org/standard/78914.html

2. ISO/IEC 11179-3:2023 — Metamodel for Registry Common Facilities

定义元数据注册共用设施的概念模型，包括注册对象识别、指定与定义、注册、分类及映射等能力。

官方来源：https://www.iso.org/standard/78915.html

3. ISO/IEC 11179-3:2023/Amd 1:2026 — Enhancements to Item Mapping

2026年5月发布的修订补充文件，涉及注册项映射能力增强。本文仅依据ISO公开摘要讨论其范围，不将未核验的具体条款作为实施要求。

官方来源：https://www.iso.org/standard/89914.html

4. W3C — SKOS Simple Knowledge Organization System Reference

2009年8月18日发布的W3C Recommendation，用于表达知识组织体系中的概念、标签、定义及概念关系。

官方来源：https://www.w3.org/TR/skos-reference/

5. W3C — Data Catalog Vocabulary Version 3

2024年8月22日发布的W3C Recommendation，用于描述数据目录、数据集和数据服务，并支持目录互操作及版本相关元数据。

官方来源：https://www.w3.org/TR/vocab-dcat-3/

6. Dublin Core Metadata Initiative — DCMI Metadata Terms

提供用于描述资源的通用元数据词汇，包括Identifier、Title、Description、Publisher、Language、Source、License和Rights等。

官方来源：https://www.dublincore.org/specifications/dublin-core/dcmi-terms/

7. W3C — PROV-O: The PROV Ontology

定义Entity、Activity、Agent等概念及来源与派生关系，可与企业元数据和数据血缘管理结合。

官方来源：https://www.w3.org/TR/prov-o/

8. W3C — Data Quality Vocabulary

提供描述质量维度、质量指标和质量测量信息的词汇，为Metadata Quality信息表达提供参考。

官方来源：https://www.w3.org/TR/vocab-dqv/

9. Google Search Central — General Structured Data Guidelines

规定Google Search结构化数据的技术和质量要求，强调结构化数据应真实反映页面内容、保持准确及避免误导，并明确不保证Rich Result展示。

官方来源：https://developers.google.com/search/docs/appearance/structured-data/sd-policies

本系列自定义实施规范说明

本文提出的 SEO / GEO Metadata Classification、Business Glossary Record、Field Semantic Standard、Metadata Registry最小对象模型、Metadata Quality Gate、Metadata Admission Checklist、Metadata Drift Incident、Metadata Lifecycle、MUST / SHOULD / MAY规则及30天实施路径，属于本系列结合SEO、GEO、PIM、WordPress、GSC、GA4、RAG与企业数字营销业务提出的工程实践模型。

本文引用ISO/IEC 11179、W3C SKOS、DCAT、DCMI、PROV及DQV作为参考依据，但不意味着这些机构联合发布了统一的SEO/GEO Metadata Governance行业标准，也不意味着采用本文示例即可宣称完整符合相关标准。

元数据治理能够提高数据解释、系统协作、审计追溯与知识管理的可靠性，但不能直接保证搜索排名、生成式搜索引用或营销转化表现。