三个医院说三种话，机器想帮忙都听不懂
本体（ontology）这个词，原文给的定义是 “某个领域里术语的、以及术语之间关系的、显式的形式化规范”（Gruber, 1993）。这个定义一上来就劝退人，我们先放一边。
看它实际长什么样更直观：你在 Yahoo! 上点过的网站分类目录，在 Amazon 上翻过的商品参数分类，都是本体——只不过精细程度差得远。Yahoo! 那种是粗分类，Amazon 那种开始带参数了。
本体这些年做了两件事：一是从人工智能实验室里走出来，进了各领域专家的日常工具；二是从单机走向了万维网。
万维网上的东西是给人看的，机器看不懂。这带来一个很实际的问题：你想让一个智能体（agent，就是能自己跑起来帮你干活的程序）去三个不同的医疗网站抓信息，然后合并起来回答你的问题——它做不到，因为这三个网站对“高血压”的叫法、字段、层级可能完全不同。
W3C（万维网联盟）在解决这件事。他们推的 RDF（Resource Description Framework，资源描述框架）就是一门用来描述网页知识的语言，目标是让机器也能读懂网页上的信息。DARPA（美国国防高级研究计划局）和 W3C 又联手在 RDF 上加了更强的表达力，搞出了 DAML（DARPA Agent Markup Language），专门为了促进网上代理之间的互操作（Hendler & McGuinness, 2000）。
各学科自己在建领域本体。医学界的成果最扎实，有 SNOMED 这种大型标准化结构化词汇表，也有 UMLS（统一医学语言系统）的语义网络。通用型的大本体也在出现——联合国开发计划署和邓白氏（Dun & Bradstreet）合作搞出了 UNSPSC，专门管产品和服务的术语分类。
本体为需要共享某个领域信息的研究者们定义了一套共同词汇表。它包括这个领域里基本概念的、机器可解释的定义，以及概念之间的关系。
用这本书自己的话说，一个本体加一组实例，就构成一个知识库（knowledge base）。
原文列了五条动机，这不是凑数的清单，每一条对应一类真实的痛点：
（1）让人和智能体对“信息结构”达成共识。 这是最常见的目标（Musen, 1992; Gruber, 1993）。假设有几个医疗网站，如果它们共享并公开同一套底层术语本体，那么计算机代理就能从这些不同站点抽取信息并聚合起来——聚合的结果可以用来回答用户的查询，也可以喂给别的程序当输入。
（2）让领域知识可以复用。 这是近几年本体研究火起来的核心推力之一。原文举的例子是“时间”：很多不同领域的模型都需要表达时间概念——时间区间、时间点、时间的相对度量等等。如果有一组研究者已经把这套时间本体做细了，其他人直接拿来用就行。更进一步，如果你要建一个很大的本体，可以把若干个描述局部领域的现成本体拼起来；也可以拿一个通用本体（比如 UNSPSC）做底子，往上扩展出自己领域的部分。
（3）把领域假设显式写出来。 一个实现背后总藏着关于这个领域的各种假设。把这些假设显式写出来，好处是——当领域知识变了，你能改得动。反过来，把关于世界的假设硬编码（hard-code）在程序语言代码里，这些假设既难找、难理解，也难改，尤其对没有编程背景的人来说。另外，领域知识的显式规范对新用户也有用：他们得先知道这个领域里的术语是什么意思。
（4）把领域知识和操作知识分开。 这是本体的另一个常见用法。原文的例子是产品配置（McGuinness & Wright, 1998）：我们可以把“按给定规格，用零部件配置出一个产品”这件事描述下来，然后写一个与具体产品和零部件无关的配置程序。这样，我们建一个“PC 部件及其特性”的本体，就能用这个算法去配置定制 PC；把“电梯部件”的本体喂给同一个算法，它就能配置电梯（Rothenfluh et al., 1996）。
（5）分析领域知识。 一旦术语有了声明式（declarative）的规范，就可以对它们做分析。当你既要复用现成本体、又要扩展它的时候，对术语做形式化分析价值极高（McGuinness et al., 2000）。
几个网站共享同一套术语，程序才能把数据拼起来。
别人做好的「时间」「人」这些轮子，拿来就用。
规则不再藏在代码里——领域变了，改得动。
同一个配置引擎，换本体就能配电梯。
形式化之后，机器能替你查矛盾和环。
原文特别强调这一点：建本体往往不是目标。 建一个领域本体，本质上和“为一堆数据定义好数据结构，好让别的程序来用”是一回事。
问题求解方法、领域无关的应用、智能体，都是把本体和基于本体构建的知识库当作数据来用的。本文全程用的例子就是这件事：建一个“葡萄酒与食物、以及二者如何搭配”的本体。这个本体之后可以作为一整套餐厅管理工具的基础——
📌 本小节为双语版补译——中文精读版未收录原书序言。补在这里，是因为它说清了本体设计和面向对象设计的本质区别。
本指南建立在我们使用 Protégé-2000、Ontolingua 和 Chimaera 作为本体编辑环境的经验之上。书中的示例统一使用 Protégé-2000。
贯穿全书的酒与食物示例，大致基于一篇介绍 CLASSIC 的论文中给出的示例知识库——CLASSIC 是一个基于描述逻辑的知识表示系统（Brachman et al., 1991）。CLASSIC 教程（McGuinness et al., 1994）进一步发展了这个例子。Protégé-2000 和其他基于框架的系统以声明式方式描述本体：显式说明类层次是什么、个体属于哪些类。
本指南中的一些本体设计思想，源自面向对象设计的文献（Rumbaugh et al., 1991; Booch et al., 1997）。但是，本体开发不同于面向对象编程里的类和关系设计。面向对象编程主要围绕类上的方法展开——程序员根据类的操作属性做设计决策；而本体设计者根据类的结构属性做这些决策。结果是：本体中类的结构以及类之间的关系，和一个相似领域的面向对象程序里的结构是不同的。
本体开发者可能遇到的所有问题，不可能在一本书里讲完——本指南也不打算全部覆盖。我们要提供的是一个起点：一份帮助新手本体设计者上手的入门指南。如果你的领域需要更复杂的结构和设计机制，书末给出了一些可以继续查阅的地方。
最后，不存在唯一正确的本体设计方法论，我们也没有试图定义一套。这里提出的想法，都是我们自己在本体开发经验中觉得有用的。书末列了一批参考文献，供查阅其他方法论。