语义建模与数据

第 6 章 糟糕的描述

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

我语言的局限意味着我世界的局限。

路德维希-维特根斯坦

在开发语义模型时，我们会定义有助于人类理解的方面（元素名称、文本定义、使用指南和其他文档），以及旨在实现机器可理解性的方面（与其他元素的关系、逻辑公理、推理规则等）。 作为语义模型的创建者，我们非常重视机器可解释性方面，这是正确的，但我们往往低估了创建人类可清晰理解的语义模型的重要性和难度。相反，作为语义模型的用户，我们往往低估了我们实际上误解了语义模型真正含义的可能性，最终导致我们以不正确的方式使用语义模型。这也许是数据供应商和消费者之间存在语义鸿沟的最大原因。

本章介绍了我们在通过名称、文本定义和其他类型的人类可读信息来描述语义模型元素时常犯的一些错误，并提供了提高这些描述质量的技巧和指南。

起坏名字

在我举办语义建模讲座或面试 雇用人员时，我最喜欢做的测验如下：假设您想为一家公司的客户建模，而这些客户可以是自然人，也可以是其他公司。图 6-1中的两个语义模型哪个是正确的，左边的还是右边的？

图 6-1. 建模困境

左边的模型认为有一个类Customer 和它的两个子类Person 和Organization 。而右边的模型则认为，类Customer 应该是类Person 的子类，同时也是类Organization 的子类。大多数人都倾向于回答左边的模式是正确的，但他们嗅到了陷阱的味道，仍然犹豫不决。事实上，这确实是个陷阱，即两个模型都是错误的。让我们来看看为什么。

右边的模型，如果用自然语言来表达，就是说 "所有客户既是个人，同时也是组织"。然而，这是不可能的，因为一个人不可能是一个组织（一个人的公司仍然是一个公司，而不是一个人）。另一方面，左边的模型说 "所有的人和组织同时也是客户"；这也是有问题的，因为它意味着在领域或数据中不存在不是客户的人或组织。后一个错误建模的例子只是错误命名的一个案例。

如果建模元素的名称不能帮助人类用户理解该元素的含义，或者更糟糕的是，会导致用 户产生错误的理解，那么这个名称就是糟糕的。在图 6-1 的左侧模型中，类Person 的命名很糟糕，因为实际上建模者想表示的是有形的客户，而不是所有的人。类Organization 也是如此。因此，这两个类更准确的名称分别是PrivateCustomer 和 Corporate​Customer，而图 6-2 所示的模型要好得多。即使在您的领域中，您只对作为客户的个人和组织感兴趣，情况也应该是这样。

图 6-2. 图 6-1建模困境的解决方案

树立坏榜样

即使是在语义建模专家设计的模型中，糟糕的命名也比你想象的要经常发生。 例如，SKOS 框架为意义包含建模定义的关系名为 。这显然是一个模棱两可的名称，它没有提供任何关于关系的预期方向的信息，也就是说，如果 "A B"，那么 A 是否比 B 更宽泛，反之亦然。现在，在 SKOS 规范中，这个问题通过一个注释得到了澄清，该注释指出，" ...