类 / 实例 / 属性值 三分判定

一直击本质

一句话：每遇到一个新名词，你都要回答一个三选一的问题——“它是个盒子、是盒子里的一件东西、还是贴在盒子上的一个标签？” 这三个身份分别是类、实例、属性值。

先说生活直觉。

假设你在整理家里的储物间，你要给每样东西贴标签。

• 你写下“工具”、“餐具”、“药品”——这些是盒子。它们不指某样具体的东西，而是“某一类东西”的名字。
• 你把一把螺丝刀放进“工具”盒子里——这把螺丝刀是一个实例。
• 螺丝刀上贴着一张标签“材质：金属”——“金属”是个属性值。它自己不是一样东西，它是在描述螺丝刀。

这就是本体的全部动作：分盒子、放东西、贴标签。 而这本书里 4.4、4.5、4.6 三节反复纠缠的，就是怎么判断一个新词该分到哪一类。

正式定义：

本书第 2 章给的定义是“类描述领域中的概念”“具体的酒是这个类的实例”；4.6 节给了一条判据：

个体实例是知识库里所表示的最具体的概念。

二差异特征：与【属性值】的质的不同

最容易被搞混的一对是“类”和“属性值”——因为同一个区分，两种建法都说得通。

现场实测：你想表达“有的酒是红的，有的是白的”。怎么建？

质的不同，体现在两边的能力清单上：

换句话说，两者的分水岭是：这个区分会不会“活起来”。

• 如果这个区分只会被读（查询时过滤一下），用属性值。
• 如果这个区分会被推理（“因为它是红酒，所以它必然有单宁含量”），必须建类。

三存在意义：它解决了什么真实痛点

痛点的名字叫：建模的粒度失控。 两个方向都会翻车。

事故一：类在“搬家”——分类体系每天都在变

场景：你想在餐厅酒瓶本体里建一个 ChilledWine（冰镇酒）类。

会怎样：一位顾客点了一瓶酒，服务生从冰柜里拿出来——这瓶酒立刻变成 ChilledWine 的实例。喝了一会儿，酒温了——它又变成 WarmWine 的实例。下一桌客人又点它，再冰一次——又变回来。

具体后果：

• 任何统计都失真。“本店冰镇酒的库存周转率”这个报表，取决于统计的时刻而不是事实——同一瓶酒在 8 点算冰镇酒、10 点不算。
• 任何推理都不可靠。基于“冰镇酒”这个类做的任何推理（“冰镇酒适合配生蚝”），对同一瓶酒时真时假。
• 用户困惑。顾客昨天买的“冰镇酒”今天在分类里找不到了。

原文的判据（4.5 节）：一个个体实例所属的类，不应该经常变。通常，当我们用外在属性而不是内在属性来区分类时，这些类的实例就会频繁地在类之间迁移。

事故二：该建类没建——机器不知道“红与白互斥”

场景：你图省事，把颜色做成属性值：Wine.color ∈ {RED, WHITE}，不建 RedWine/WhiteWine 类。

会怎样：后来有人录了一条数据，颜色填了 RED 又填了 WHITE，或者某个类同时被声明为这两种。

具体后果：机器一声不吭。 它不知道 RED 和 WHITE 不能共存——因为“互斥”（4.8 节）这个声明只能声明在类之间，属性值没有互斥机制。于是这个错误一路潜伏到报表里。

事故三：该建属性值却建了类——类爆炸，推理跑不动

场景：你为每一个区分都建类：DelicateWine、ModerateWine、StrongWine；FullBodyWine、MediumBodyWine、LightBodyWine……

会怎样：颜色 3 种 × 酒体 3 种 × 风味 3 种 × 糖分 3 种 = 81 个类（还没算葡萄品种）。真实的酒类组合还会更多。

具体后果：

• 推理机算不动。类数量直接决定推理的搜索空间。
• 维护成本爆炸。要加一个新的风味等级？81 个类要乘 4，变成 108 个。
• 原文明确禁止这种行为（4.4 节末）：我们引入了 Red wine、White wine、Rose wine 这些类，是因为这个区分在酒的世界里是自然存在的。我们没有为“清淡的酒”“中等酒体的酒”等等建类。

事故四：把实例当类——“子实例”根本不存在

场景：你把 Bourgogne region 建成实例，然后又想表达 Cotes d'Or region 是一个 Bourgogne region。

会怎样：做不到。 原文 4.6 节说得很干脆：只有类才能被组织成层次——知识表示系统里没有“子实例”这个概念。

具体后果：你被迫做一堆随意的判断——“哪几个产区算类、哪几个算实例”，而这个判断本来就没有客观标准。原文的解法是把所有产区统统升成类，然后把它们标成 Abstract（抽象类，不能有直接实例）。

四流程定位

1）它处于哪个环节或接口上？

它是一道分诊台，卡在第 3 步和第 4/5/7 步之间：

第3步 列出术语清单（不做分类）
          ↓
    ┌─────────────────┐
    │   ★ 三分判定台 ★   │  ← 你在这里
    └─────────────────┘
     ↓        ↓        ↓
   类        属性       （暂时搁置）
     ↓        ↓
第4步 建类层次  第5步 定义属性
     ↓
第7步 建实例 ←—— 从这里往下，"最具体的概念"变成实例

注意：它是一个“分诊台”，不是“一次性的关卡”。 每加一个新词，都要过一次。

2）启动条件：什么时候必须启动它？

3）禁用条件：什么情况下绝对不该用它？

禁用条件一：领域范围还没定的时候，不要用它。

原文 4.5 节说得很清楚：答案通常取决于我们为本体定义的范围。—— “白葡萄酒”这个概念在我们的领域里有多重要？ 同一个词，在“印酒标的工厂”和“做酒菜搭配”两个领域里，答案相反。所以：第 1 步没做完，这道判定就没有输入，得出的结论是假的。 强行判定，等于凭空猜。

禁用条件二：不要用它来回答“要不要建更多的类”。

那是 4.4 节的活，用的是另一套判据（“子类有没有新属性/新约束/新关系”）。三分判定回答的是“它是什么身份”，不是“该不该有它”。 两者混用会出这种错：判定某个术语是“属性值”，就以为“不用建这个类了”——但 4.4 节明确说，即使不引入新属性，参照层次和专家共识这两种情况仍然应该建类。

禁用条件三：不要用它来决定“命名”。

“单数还是复数”（6.2 节）、“用空格还是驼峰”（6.1 节）是命名问题。把命名问题误当身份问题，会得出“用复数就说明它是类”这种谬论——原文 6.2 节明确说两种都行，只要一致。

禁用条件四：不要用“这个区分在现实世界里为不为真”作为唯一判据。

这是最反直觉的一条，也是 4.7 节 Experimenter 案例的教训：

Experimenter 是 BiologicalOrganism 的子类——这句话在现实中为真。但不该放进本体，因为它会给所有实验者实例塞进体重、年龄、物种这些无关字段。

判据不是“真不真”，而是“对我的应用有没有用、会不会有害”。

五操作白盒化

输入：喂给这道判定的是什么？

注意第三个输入是硬要求。 原文 4.5 节说答案取决于范围——没有范围，判断不成立。

传导：三道筛子，按顺序过

三道筛子的因果逻辑：

• 筛 1 先过：因为“实例”是相对应用的概念。原文明说“个体实例是知识库里所表示的最具体的概念”——所以必须先知道“最细到哪”，才能判。
  例：Sterling Vineyards Merlot 在“酒菜搭配”应用里是实例；但如果你要记录每瓶酒的库存，它就得变成类（它的每个年份/每瓶是实例）。
• 筛 2 是核心判据：原文 4.5 节的两条判据都在这。

  如果带着不同属性值的那些概念，会成为其他类中不同属性的限制条件，那我们应当为这个区分建一个新类。
  如果一个区分在领域里很重要，并且我们会把在该区分上取不同值的对象看作是不同种类的对象，那我们就应当为这个区分建一个新类。

• 筛 3 是兜底：过不了筛 2 的，用迁移率兜底。原文 4.5 节：一个个体实例所属的类，不应该经常变。 通常，当我们用外在属性而不是内在属性来区分类时，这些类的实例就会频繁地在类之间迁移。

输出：产出什么？

一个判定结论，外加一个理由记录：

理由记录不是可选项。 原文 4.7 节明确要求：

我们应该把这类设计决策记录在本体的文档里，以造福那些将查看这个本体、却可能不了解我们当初设想的是什么应用的用户。否则，打算把这个本体复用到其他应用的人，可能会试图把 experimenter 当作 person 的子类使用，而不知道原始建模里并没有包含这个事实。

六代价权衡

这一节要分两边算账。

路线 A：判成“类”

得到：可继承（子类自动拿到属性）；可被别的属性当约束（pairingGoodFor 的 range 可以写 RedWine）；可参与互斥声明 → 机器能替你查错（4.8 节）；可参与多重继承（4.3 节 Port 的例）。

牺牲：类数量指数膨胀（颜色 × 酒体 × 风味 × 糖分 = 乘法增长）；推理成本上升（类数量直接决定推理搜索空间）；维护成本上升（加一个维度，所有组合都要重算）。

在什么场景下会真的疼：

当那个区分是“正交维度”的时候。

“颜色”和“酒体”是两个独立的维度——一款酒可以是“红 + 饱满”，也可以是“红 + 清淡”。如果你为每个组合建类，你就把两个维度的笛卡尔积硬编码成了类列表。

原文 4.4 节末踩的正是这个坑：我们没有为“清淡的酒”“中等酒体的酒”建类。

路线 B：判成“属性值”

得到：本体扁平、简洁；新增维度零成本（加一个枚举值即可）；查询过滤简单直接。

牺牲：完全失去推理性。“红酒有单宁含量”这句话无处安放——你没法在 Wine 上挂 tanninLevel（白酒没有），也没法挂在一个不存在的 RedWine 类上。失去校验能力。机器不知道 RED 和 WHITE 互斥。

在什么场景下会真的疼，而且疼得最厉害：

当你需要“某个区分才有的字段”时——路线 B 直接失灵，没有替代方案。

这就是原文 4.5 节里 Red Merlot / White Merlot 那个例子：红梅洛和白梅洛确实是不同的酒（用同一种葡萄酿成），如果我们建的是一个细致的酒本体，这个区分就很重要。

量化这个“疼”：

把 tanninLevel 挂在 Wine 上：10 款酒全部被授予该属性，但其中只有 6 款是红酒（真该有）→ Precision = 6/10 = 0.6。
建 RedWine 类再挂：6 款全部命中 → Precision = 6/6 = 1.0。

精确度从 0.6 到 1.0，代价就是多建一个类。这笔交易通常划算。

七生态对接

上游：谁给它喂输入？

下游：它的结论喂给了谁？

有一个下游反馈环值得单独点出：

判定 → 建类 → 实例投入使用 → 发现实例在频繁换类
   ↑                                    ↓
   └────────── 回头重判 ←────────────────┘

这就是迭代（第 3 章原则 2）在这道分诊台上的具体形态。

八旧知缝合

比方一（最好用的一个）：像给文件夹分类

你在电脑上整理文件：

• 文件夹 = 类（“工作”、“照片”、“财务”）
• 某个具体文件 = 实例（2026年度预算.xlsx）
• 文件的属性 = 属性值（“只读”、“大小 2MB”）

现在问你：“已备份”应该是文件夹还是属性？

答案取决于行为：

• 如果“已备份”只是你在文件上打的一个勾，用来筛选一下——属性（右键属性里勾一个框）。
• 如果“已备份”意味着它要被移到另一个位置、参与另一套规则、还需要有“最近一次备份时间”这样的子字段——那它其实是个文件夹。

判据就是那句话：这个区分会不会“活起来”。

比方二：像生物学里的“物种”和“毛色”

这是最精准的一个比方，因为它自带“什么该是分类、什么不该是分类”的直觉。

• 物种是分类（人是哺乳动物，猫是哺乳动物）——因为物种决定本质：一只动物不会今天是人、明天是猫。
• 毛色不是分类（黑猫、白猫都是猫）——因为毛色是外在特征：猫可以换毛、可以染色。

这正是原文 4.5 节 ChilledWine 案例的同构：

为什么生物学不会把“白猫”单列为一个物种？ 因为那会让分类学失控——一只猫剃了毛，它就换物种了。本体面对的是一模一样的问题。

比方三：像项目管理里的“里程碑”和“标签”

用过 Jira / 看板的人都懂这个区别：

• 工作流状态（待办 / 进行中 / 已完成）：互斥、有序、每条只能选一个，改状态是一个事件。→ 这是类的结构。
• 标签（#紧急 #前端 #王某）：可多可少、可顺手加、正交。→ 这是属性值。

“冰镇酒”该是状态还是标签？ 状态。而状态每天在变——所以它不该是一个独立的“文件夹”。原文的迁移率判据，本质上就是在问：“这是个状态，还是个分类？”

九数值案例串讲

场景：一家餐厅的酒瓶本体。这里会同时出现“该建类”和“该建属性值”两种正确判断，以及它们各自的数值依据。

9.1 场景与数据

领域范围：管理餐厅酒窖的 100 瓶库存，支持“按类别查库存”“酒菜搭配推荐”。
能力问题：包括“哪些红酒有高单宁？”“现在有几瓶冰着的酒？”“波尔多配什么？”

观测数据（一天营业，8 小时）：

9.2 公式

公式 1：迁移率（对应第四步的“禁用条件”判断）

判决规则（阈值 θ）：ρ(C) > θ → 属性值；ρ(C) ≤ θ → 类。

公式 2：挂载精确度（对应第六步的“代价权衡”）

读法：挂在 c 上的属性 s，落在“真正该有它”的实例上的比例。越接近 1 越好。

公式 3：区分的信息增益（辅助判据，用来回答“这个区分值不值得建类”）

其中 H 是香农熵 H(X) = −Σ p_i log₂ p_i。
读法：G(t) 越大，说明知道 t 之后对预测的把握提升越多——这个区分越“有用”，越值得建类。G(t)=0 说明这个区分什么信息都没提供。

9.3 手工验算

① 迁移率：ChilledWine vs RedWine（阈值 θ = 0.1 次/(瓶·天)）

ChilledWine（冰镇酒）：身份变更次数 60 次进 + 35 次出 = M = 95；ρ = 95 / (100 × 1) = 0.95 次/(瓶·天)。

RedWine（红酒）：一天内红酒变白酒 0 次 → M = 0；ρ = 0 / (100 × 1) = 0。

口算验算：0.95 是 0.1 的 9.5 倍——ChilledWine 越界非常明显，不是边界情况。

结论落地（原文 4.5 节的处方）：在一张描述餐厅里酒瓶的本体中，不应该有 Chilled wine 这个类。chilled 属性应该就是“瓶中酒”的一个属性值而已。于是本体里加一个布尔属性 chilled（默认 false），不建类。

② 挂载精确度：tanninLevel 挂哪里？

数据：Wine 有 10 个实例，其中 6 个是红酒（真该有单宁含量），4 个是白酒（不该有）。

提升 0.40，代价是一个类。

更关键的是：方案 A 不只是“不够准”，它在语义上是错的——它等于断言“每一款酒都有单宁含量”，而白酒没有单宁含量是客观事实。原文对此的判词是：再往上泛化一步——把 tannin level 挂到 Wine 类上——就不对了，因为我们不用单宁含量来描述白葡萄酒。

方案 B 还有额外收益：RedWine 这个类可以参与互斥声明（RedWine ⊥ WhiteWine），把“红与白不可兼得”变成机器可校验的断言。

③ 信息增益：为什么 color 特殊？

原文说了一句很有意思的话：通常，数字、颜色、地点都是属性值，不会导致新建类。 不过，酒是个显著的例外，因为颜色对酒的描述来说太重要了。

用信息增益量化这句话。假设要考虑的“下一个问题”是“这款酒配什么食物”，食物只有两类：肉 和 海鲜。在 6 款已知的酒里：3 款红酒全部配肉，3 款白酒中 2 款配海鲜、1 款配肉。

这就是“颜色太重要了”的量化版本。 只知道颜色，就能把“配什么菜”的不确定性砍掉一半（0.918 → 0.459）。在信息论里，G = 0.459 比特是个很高的值。

对比一下“酒标用什么纸”这个区分：它对“配什么菜”的信息增益是 G = 0——零增益的区分，永远不该建类（这正是原文 4.7 节“酒标用什么纸不该进本体”的数学表述）。

9.4 Java 代码

import java.util.*;
import java.util.stream.Collectors;

/**
 * 三分判定器：实现本报告 9.2 节的三条公式
 */
public class TripleClassification {

    /** 判定结果 */
    enum Kind { CLASS, INSTANCE, SLOT_VALUE }

    // ---------- 公式1：迁移率 ----------
    // ρ(C) = M(C) / (N · Δt)
    record Migration(double changes, int total, double days) {
        double rho() { return changes / (total * days); }
    }

    static final double THETA = 0.1;   // 阈值 θ：次/(实例·天)

    /**
     * 第四步·禁用条件：迁移率超阈值 → 降级为属性值
     * 这是 4.5 节"一个个体实例所属的类，不应该经常变"的可执行版本
     */
    static Kind decideByMigration(Migration m) {
        return m.rho() > THETA ? Kind.SLOT_VALUE : Kind.CLASS;
    }

    // ---------- 公式2：挂载精确度 ----------
    static double precision(Set<String> instancesOfC, Set<String> shouldHaveS) {
        if (instancesOfC.isEmpty()) return 0.0;                      // 除零保护
        Set<String> hit = new HashSet<>(instancesOfC);
        hit.retainAll(shouldHaveS);                                  // 交集
        return (double) hit.size() / instancesOfC.size();
    }

    // ---------- 公式3：信息增益 ----------
    // G(t) = H(Y) - H(Y|t)，H 为香农熵，底数 2
    static double entropy(List<String> labels) {
        if (labels.isEmpty()) return 0.0;
        Map<String, Long> freq = labels.stream()
                .collect(Collectors.groupingBy(x -> x, Collectors.counting()));
        double n = labels.size(), h = 0.0;
        for (long c : freq.values()) {
            double p = c / n;
            h -= p * (Math.log(p) / Math.log(2));                    // 换底公式：log2(p)
        }
        return h;
    }

    static double infoGain(List<String> y, List<String> t) {
        double base = entropy(y);                                    // H(Y)
        Map<String, List<Integer>> groups = new LinkedHashMap<>();
        for (int i = 0; i < t.size(); i++) {
            groups.computeIfAbsent(t.get(i), k -> new ArrayList<>()).add(i);
        }
        double cond = 0.0;                                           // H(Y|t) 加权平均
        for (List<Integer> idx : groups.values()) {
            List<String> sub = idx.stream().map(y::get).toList();
            cond += (double) idx.size() / y.size() * entropy(sub);
        }
        return base - cond;                                          // G(t)
    }

    public static void main(String[] args) {
        System.out.println("=== 公式1：迁移率判定（θ = " + THETA + "）===");
        // ChilledWine：100 瓶，一天内 60 次冰镇 + 35 次回温
        Migration chilled = new Migration(60 + 35, 100, 1.0);
        // RedWine：100 瓶，一天内 0 次身份变更
        Migration red = new Migration(0, 100, 1.0);
        System.out.printf("  ChilledWine: ρ=%.2f → %s%n", chilled.rho(), decideByMigration(chilled));
        System.out.printf("  RedWine    : ρ=%.2f → %s%n", red.rho(), decideByMigration(red));

        System.out.println("\n=== 公式2：tanninLevel 挂哪里？===");
        Set<String> allWines = Set.of("w1","w2","w3","w4","w5","w6","w7","w8","w9","w10");
        Set<String> redWines = Set.of("w1","w2","w3","w4","w5","w6");
        Set<String> shouldHaveTannin = redWines;                     // 客观事实：只有红酒该有单宁
        System.out.printf("  挂在 Wine    : Precision = %.2f%n", precision(allWines, shouldHaveTannin));
        System.out.printf("  挂在 RedWine : Precision = %.2f%n", precision(redWines, shouldHaveTannin));

        System.out.println("\n=== 公式3：区分的信息增益 ===");
        List<String> food   = List.of("肉","肉","肉","海鲜","海鲜","肉");   // 6 款酒配的菜
        List<String> color  = List.of("红","红","红","白","白","白");       // 颜色
        List<String> paper  = List.of("A","B","A","B","A","B");            // 酒标用什么纸（无关属性）
        System.out.printf("  G(color)      = %.3f 比特%n", infoGain(food, color));
        System.out.printf("  G(labelPaper) = %.3f 比特  ← 零增益，不该建类%n", infoGain(food, paper));
    }
}

运行结果（已核对，与 9.3 手工验算一致）：

=== 公式1：迁移率判定（θ = 0.1）===
  ChilledWine: ρ=0.95 → SLOT_VALUE
  RedWine    : ρ=0.00 → CLASS

=== 公式2：tanninLevel 挂哪里？===
  挂在 Wine    : Precision = 0.60
  挂在 RedWine : Precision = 1.00

=== 公式3：区分的信息增益 ===
  G(color)      = 0.459 比特
  G(labelPaper) = 0.000 比特  ← 零增益，不该建类

9.5 逐行对照八步