构建分类法只是开始,真正的挑战在于治理——尤其是在大型组织中,数十个系统共享和依赖数百个术语结构。本文详细解析了分类法变更的六种典型类型,并展示如何建智能变更工作流、统一管理术语生命周期、同步下游系统,避免信息混乱,实现高效协作与治理。

关于分类治理
我相信大多数分类学家都会同意,构建分类法很有趣。
但大多数分类学家并不是把大部分时间都花在构建分类法上。
实际上,在一个分类法项目启动并运行之后,分类学家的大部分工作都投入到了分类法治理上。
关于分类法治理的话题早已文献浩繁;在 Google 中搜索精确词组“taxonomy governance”可得约 3000 条结果。这些内容大多要么说明“为何治理很重要(确实如此)”,要么提出“建议的治理做法和战略”。
我们还需要考虑,在大型企业中分布着大量分类法时的治理问题。在某些大型组织,分类法的变更如此频繁,以至于组织所需的工作——以及应对变更对下游系统的影响——达到了另一种规模。
大规模企业分类法治理
毫不夸张地说,一些大型分类法项目包含数百个(真的)分类法,分布在数十个系统中,例如:
分类法/本体管理系统
产品信息管理(PIM)系统
内容管理系统(CMS)
数字资产管理(DAM)系统
营销平台
销售与客户互动平台
活动策划与管理平台
数据分析平台
……以及各种网站和其他应用
某些系统存储并管理词汇表,另一些系统则将其引入以支持导航、标注、分析等需要词汇控制的功能。
管理变更请求及其下游影响,除了需要专职人员外,还得配备某种工单或请求跟踪系统,在专用词汇管理系统中建立一个或多个环境,并制定各种优先级和分拣工作流。
变更请求可能相互冲突或因其他原因产生问题。添加或移除术语需要对资产重新标注并进行其他下游更改,导致同步问题——假设你已经通过 API 将所有系统集成并实时传递数据,而不是定期下载更新文件。有时人们会提出已有的需求,或提出不合理的需求,这就需要调查研究并与用户沟通。
这一切看起来都很艰巨且难以组织。幸好,组织整理正是我们的行李包。用分类法以及图表就可以实现。
分类学变化真的只有几个基本形式。因此,让我们对更改类型进行分类,以确定每种更改所需的工作量(和特定工作流程)。
分类法变更的几种基本类型
分类法变更其实只有几种基本形态。我们可以据此对变更类型进行分类,从而确定每种变更所需的工作量和对应的具体工作流。
删除术语
添加术语
移动术语
重命名(或更新)术语
拆分术语
合并术语
1. 删除术语
示例: 零售商不再销售“北京奥运会”相关商品
从分类法中删除某一术语,是一项复杂操作。多数系统提供“弃用”(deprecate)选项:将术语从分类法中移除(在实际使用中看不到),但在系统中仍保留该对象,以便恢复。相比之下,“硬删除”会彻底移除该术语。哪种方式合适,取决于治理协议。
更棘手的是,已被标注了该术语的内容或对象怎么办?能否批量删除这些标签,或者需要提交工单让 IT 编写脚本?哪些下游系统需要更新以反映变更?相关网站是否也要同步?是否存在基于该术语的历史分析,尽管不再使用该术语,却还在报表中?这些复杂性往往使人们倾向于弃用而非硬删除。
2. 添加术语
示例: 为了对新内容进行分类,需要新增术语“大型语言模型”
添加术语或许是最简单的操作,下游系统只需在下次与分类法工具同步时接收新术语即可。
若无需征得分类法负责人的许可,添加术语的主要工作在于与请求者澄清需求(这是用于什么?)、确定首选标签(叫它什么?)以及填写其他属性和字段。后者往往耗时且需关注细节。
虽然应定期对已发布内容进行重新索引以纳入新术语,但最好将其安排为周期性的批量更新(除非有紧迫的业务需求)。
3. 移动术语
示例: 冥王星不再属于“行星”,而是归为“矮行星”
相比添加和删除,移动术语并不常见,且需了解所有下游系统如何消费分类法。许多系统仅将标签存为单个术语,按简单层级或扁平列表存储,此时只要更新或刷新同步即可无碍。但某些系统(包括某些文档标注方式)还存储和利用术语的“完整路径”(path to root):
生物学 → 分子生物学 → 微阵列
在这些情况下,移动术语与删除类似,可能引发标注的级联影响。
4. 重命名术语
示例: “Facebook” 改名为 “Meta”
此处 “重命名” 指首选标签的变更。与移动和删除类似,最主要的问题在于对已有标注对象的影响,下游系统应能在刷新后自动使用新标签。需要注意的是,首选标签的变更可能伴随定义(Definition)或范围说明(Scope Note)等其他字段的更新。
也可能仅是其他属性的更新(首选标签保持不变),此时是否会影响下游系统,取决于这些属性是否也被消费。
5. 拆分术语
示例: 将 “教育” 拆分为 “K-12” 和 “高等教育”
拆分实质上是一次删除和两次添加,除非旧术语保留并重命名(此时是更新加添加),并伴随删除和添加的全部复杂性。
拆分是上述操作中最复杂的一种。因为除了编程式地将变更推到系统外,还需人工审查所有被标注为 “教育” 的内容,以判定其应归入 “K-12” 还是 “高等教育”。
6. 合并术语
示例: 将 “针织帽” 与 “毛线帽” 合并为 “帽子”
合并通常最少见,其过程包含两次删除和一次添加。同样,理想情况下,应有标注系统支持一键式批量操作。
梳理和规划
将各类变更工作具体化,能够将令人望而生畏的、杂乱无章的工作量,转变为一系列可管理的任务和职责。
上述每种操作都需不同的工作流和对下游影响的考量。有些操作相对简单,仅需与其他部门协调;有些操作更为复杂。理解每种变更的工作量级别,便于为变更请求设定优先级,并进行有效的“分诊”与资源分配。