提要：围绕着计算机应用领域的“本体”（ontology）的基本概念，讨论了数据/信息建模与数据字典、模型驱动设计（DDD）的领域建模、企业建模等概念。
本体概念
计算机应用领域的本体（ontology）概念，因其哲学渊源[1]和人工智能（AI）出身，充满了神秘色彩，常让人觉得高不可攀。在概念划分时，也往往冠以“计算机科学”与“信息科学”这样的高帽子。实际上，我认为它是一个比较简单明了的概念，与普通的数据字典、词汇表、各种通用建模技术或体系等有着本质、密切的关系。
公认计算机科学（人工智能）领域本体概念的确立，是来自 Thomas R. Gruber 在 1992 年左右的工作[2]，他借鉴哲学的本体（Ontology）概念，在人工智能、知识表达研究的背景下导入了这个新概念：
“An ontology is an explicit specification of a conceptualization.”
直译就是：“本体是概念（化）的明确规范。”这里 conceptualization 稍微有些费解，中文的基本译法是“概念化”，字面上看是个过程，这可能更让人困惑。Gruber 进一步明确：
“A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose.”
即：conceptualization 是我们为了某种目的而希望表达的，世界的抽象、简化视图。这里“本体”是作为一种实体（可数的）来定义，conceptualization，主要是指某种具体的、有目的的概念化（概念抽取与表述）过程的结果，也就是一系列具体的概念表述（规定、约定）。有人喜欢在这个定义中添加“形式化”与“共享”，从本质上理解，这并非必要。所谓“形式化”，可以理解为“明确规定”方式和程度的一种体现，例如，也可以有“形式化本体”和“非形式化本体”这样的不同本体概念。所谓“共享”，有助于理解人们为何要建立本体，但它是非本质的：本质的、决定本体的是“目的”。理解本体概念中的目的非常重要，因为在现实世界无限性、连续性和动态性背景之下，“目的”是使概念化过程达成某种确定性结果至关重要的条件。
经过上述讨论，我们可以这样解读 Gruber 的本体概念：本体是一种明确表述的概念规范，是为某种目的而建立的、世界的简化和抽象的视图。按照对模型的一般性理解，本体无疑就是一种模型。建立本体的过程，就是一个建模的过程。
数据字典
数据字典（Data Dictionary）算得上信息系统开发中的骨灰级概念。虽然概念有些老，但在真实的计算机应用开发中，它始终是重要的基础要素之一。
计算机应用开发中的数据字典，核心就是某种受控词汇表。其基本的简单形式之一，是词汇字符串加编码——前者应当是用户可读的文本，后者加以适当约束（例如唯一性约束），作为适合计算机处理的编码（大陆也常见“信息/数据编码”这一说法）。在这个基础上，最基本的扩展，是增加说明文本（或描述、解释）及别名等。附加在数据字典上的典型信息，通常还会包括数据定义（对应到计算机支持的数据结构）及相关的操作规则（约束等）。再进一步，就涉及这些数据项之间的关系，从基本的分类到更具体的语义（问题域语义与计算机操作语义）和相互间的关联关系等。
在信息系统开发的过程中，这一数据字典成为连接问题领域的“意义/概念”和计算机程序的桥梁，它通常会建成计算机可直接处理的形式（但未必直接包含在应用系统中）。它的内容必须受到控制。另一方面，作为纯粹应用系统开发中的数据字典，其中包含的条目，并不一定都来自“问题领域”，也可能是软件系统本身所需。与“本体”的基本定义比较，我们至少可以明确：数据字典和本体是非常接近的。我们甚至可以这样理解：如果说，某些数据字典过于简单，没有包含某些“公认”的本体内容，那正是它的目的所决定的，因而，依然可以看作是一种简单的本体。此外，与典型的本体创建活动相比，数据字典常常是限定在一个特定的系统范围之内，而本体则是“先于”、“独立于”具体应用系统而开发的。
数据建模与数据模型
数据建模（Data Modeling）是软件工程的一个基本概念，它比数据字典要更广泛和重要，后者实际上可以看作是数据建模的一部分。
过去几十年，数据建模始终与数据库（主要是关系型数据库）的发展紧密关联，在实践、技术和理论方面都有非常丰富的积累。数据建模的结果（输出），是数据模型（data model）。在实践和理论中，数据模型并不是单一的概念，可能泛指很多类型的模型，例如数据结构，数据库模型，逻辑的、概念的、语义的、物理的数据模型等等。我观察，这个领域的实践与技术虽然丰富，却并没有形成相对完善统一的理论体系。各种概念、方法常常有不同的渊源和各自的实践领域、技术基础，而它们之间的关系（比如在基本概念的使用上）常常是不清晰的。
数据建模方面，最有代表性的基本概念，可能就是概念层、逻辑层、物理层的三层架构。一般而言，可以这样理解：它们是计算机所要储存、处理的数据，在三种不同抽象层次上的描述。概念数据模型（conceptual data model）描述计算机系统将要处理的问题领域中的事物，它本身常常采用实体联系模型（E-R Model）。逻辑数据模型（logical data model）描述的是计算机组织数据的逻辑结构，关系数据模型（relational data model）是逻辑模型最常见的类型，其内容呈现为具体的表、列、键及各种约束的定义。物理数据模型（physical data model）是逻辑数据模型的实现，任何一种可实际运行的数据库平台，都包含自己的物理数据模型。而平台的使用（应用开发）者，基本上只工作在逻辑层，仅通过平台提供的接口间接地操纵物理层。
这三个层次，逻辑层是一个中介，物理模型和概念（信息）模型是它的两面：对计算机的那一面，呈现物理数据（从语义上说，是计算机操作语义）；对人的那一面，呈现为可理解的信息，也就是语义——在业务或应用中的意义。概念模型，也常常被看作是“语义模型”或“信息模型”，它与“本体”基本上处于同样的相对位置。概念建模最常用的 E-R 模型被看作本体模型的一种。一个完整的数据建模系统，把问题领域（例如，企业的业务/需求，属于所谓“现实世界”）的事物与在计算机上如何描述与储存联系了起来。
传统的数据建模与“地道的”本体不同的一个基本点，也许就是“物理数据”的实现。数据建模通常都联系到具体的应用系统，甚至多数就是作为特定系统开发的一部分，而本体的设计/维护，通常只是针对某种特定目的（或应用领域，这常常是很笼统的），但并不针对某个具体应用系统。任何一个建立起来的本体系统，也包含着物理储存方案，但它会被看作是与本体的应用严格分离的——而数据建模作为一个系统自身的需求，可以与物理实现最紧密地捆绑在一起。基于本体的应用，本质上，就是数据独立、面向信息（模型）的系统。（对此类系统的讨论，可见综合信息系统开发途径与策略分析等）
数据建模领域的信息工程方法及其分支（比如信息规划或信息资源规划，参见信息工程与信息系统架构向企业架构的发展等文），实际上也是一种将数据建模与特定的应用开发/实现隔离策略的尝试。这一实践，与“本体”具有更大的重叠性，但从企业应用开发实践的角度看，这一分支的发展却非常有限。换一个角度，也许可以说，作为一种特定分支发展受限的同时，其中合理的原理或要素，已经通过其它途径发展了。
领域建模与领域模型
在近年的计算机软件领域流行的领域建模与领域模型（ Domain Modeling and Domain Model）大概还不能算是建模领域的一种独立概念，它们是这几年流行的软件开发方法体系“领域驱动设计”（Domain-Driven Design, DDD）中的概念。DDD 的基本思想，是要把应用系统的开发直接建立在对应用所涉及的问题域（即领域，或简称域）的明确描述——模型上。它的具体发展和实践，则是发源于面向对象技术（OO）阵营。从概念和原理上看，它无疑是一种模型驱动软件系统开发（MDSD），因而也可纳入软件领域的模型驱动工程（MDE）之中。
从道理上不难理解，所谓的“领域模型”，与传统数据建模中的概念模型的地位非常相似[3]。虽然 DDD 自然产生与发展条件决定了，它带有强烈的面向对象技术特点，与特定的软件系统架构风格联系得非常紧密，尤其是近年流行的基于 ORM（对象-关系映射）概念的中间件技术。客观地看，这一方面使得 DDD 具有非常强的实践性、实用性，另一方面，也限制了它的空间，使它处于一种具体的开发技术（风格）的位置上，而并不像其名字所暗示的那么广泛。
企业建模与企业参考模型
在企业工程相关领域，传统的研究与实践，主要使用企业建模、企业参考模型与企业参考架构（框架）概念。但这个领域同样有一些研究，围绕着本体，即“企业本体”（enterprise ontology）的概念，例如我们介绍过的，简·迪茨的企业工程等。这个领域的传统概念“企业参考模型”，与企业本体也很接近，实际上，它们都是要构造一些基础性、通用性的企业模型，换言之，企业本体就是一种通用企业参考模型。Zachman 的企业架构框架，也被称为一种企业本体。
我们对与企业工程的研究，强调企业模型与企业应用（信息系统）的衔接（参见 企业工程的内容与企业架构的定位、企业应用探索十五年之路线图等文），直接继承和沿用企业模型这个基本概念，并且将它与信息系统中的数据建模（概念建模）联系起来。我们从更一般化、多角度立场上去理解和运用企业模型这个基本概念，研究它的工作方式，围绕一般事物建模和通用企业模型框架等展开。这在实质上看，是一种“本体化”路径，但我们是在本体概念流行之外建构体系，因此，在我们的概念体系中，一直没有引进“本体”概念。虽然从多年前语义网热开始，我们就一直在观察、追踪，但只是从原理的角度加以借鉴、吸收。
若干讨论
我们搜集了一些与本体密切相关的重要模型概念，将它们与本体的关系绘制成一个示意图。它主要基于较为宽泛的本体及模型概念理解（留意这个图很难展表现这些概念之间的复杂关系）。这个图至少给出这样一种信息：所有这些重要的模型概念，都可以从本体研究那里找到重叠或借鉴的东西。
对计算机领域的本体，从语言（许多专门的本体建模语言）到形式或结构、内容构成要素等等，都已经形成了许多具体原则。以“完备本体”的标准来衡量其他领域对于概念或词汇建模的一些工作（例如：著名的英文词汇及其关系数据库 WordNet），则往往发现许多“不足”，因而有人喜欢强调诸如此类的系统不是本体。
从更深的层次看，搞清楚它们描述内容的范围、方法及其具体限制等等，才是更重要的，或者说，看到所有这些工作的相同（重叠）与不同之处才是最重要的，而不是拘泥于概念的纯粹性或规范性、完备性。
从本体的角度看信息系统开发中的各种受控词汇表、数据词典或数据/信息建模及其模型，是很有意义的。与“完备的”本体相比，它们可能在形式、内容（比如词汇）描述的深度或完善程度方面有所区别。另一方面，我们也可以认为，任何有具体目的的本体，实际上都是一种“领域模型”，虽然这个领域有时相当宽泛，例如许多为“知识表达”这样的综合目的建立的基础本体或上层本体。
企业建模的情形稍微复杂一些。在我们的应用途径中，这个体系本身就有类似本体与本体应用的不同层次。这也涉及本体概念的相对性问题。
本体是一个相对概念。前面讨论的 Gruber 的本体概念中的“世界”（the world），其本身就是相对性的。从理解的角度，我们可以把它缩小为“问题域”或“应用域”，或者所谓“论域”。
本体实践中最基本的课题之一，是“边界”（范围）与“演化”问题。一方面，现实世界本身不是一成不变的，因而，应用中的本体也需要变化；另一方面，哪些概念具有通用性，应该纳入本体，哪些不是，会是最繁琐和难解的问题；而在实际应用中，这一问题还必然地与现实世界的变化，以及应用系统边界的变化与不确定性联系在一起。这既是本体应用中的难点与要点，也是所有建模与模型研究中的难点与要点。流行的“模型驱动”概念，我们所提出的模型驱动机制与模型驱动系统，都是围绕着这一点。
计算机科学领域的本体，是一个广受关注，获得大量研究的课题。一名专门的本体研究者，对于什么是本体，会有非常严格的判断标准。但从本质理解和发展的方向上，把这样一些本体研究领域之外的概念联系起来，却是非常有意义的。本体研究领域的大量工作，可能会是一个很好的基础或枢纽。以目前的情形来看，这些分散、重叠而又不同一的概念的大量存在，显示了计算机应用这个领域的复杂性和某种不成熟特征，但我们有充分的理由相信，它们之间具备固有的协调性。
注释
[1] 为了区分，在英文中习惯将哲学的本体作为专有名词，写作Ontology，加以区别
[2] Gruber, Thomas R. (1993) A translation approach to portable ontology specifications
[3] 为突出这一点，在前面的描述中，我刻意用了“问题领域”一词——这并不是传统数据建模领域的习惯
评论
linfd 2011-03-02 • 09:36
什么是数据独立、面向信息（模型）的系统,希望博主能举几个例子TY 2011-03-02 • 11:16
手边的例子，比如“文档处理”应用，本质上，它是数据独立的。
大的例子，比如所谓“语义网”，从方向上说是如此（这里是近年计算机应用领域本体研究的大本营之一，这两者是内在关联的）
经典的例子，比如数据库（应用）。
下面几篇文章，讨论了相关的话题：
- 综合信息系统开发途径与策略分析
- 数据库和面向对象本来是两股道上跑的车
- 功能还是资源——信息系统的两种开发途径
- 以数据库为中心与面向数据库
linfd 2011-03-03 • 13:37
你说的那种面向数据库的应用有些冷,关系数据库都有在面临抛弃TY 2011-03-03 • 14:40
也许现在讲面向数据库的话题，特别是关系型，会有技术流的人瞧不起，尤其是 OO folks，潮流派的，大家都在讲云，讲移动终端……但企业信息系统从来就没脱离过这个基础。一些非关系数据库，比如所谓键-值（key-value）数据库的出现是必然也是必要的，可以留意它们的背景。它们是应互联网带来的大量不同于传统局域网应用需求而出现的。我不认为它们是来全面“取代”关系数据库的。
关系数据库的理论，尤其是应用理论的确需要发展。商业产品可以被取代。但基础技术和基础原理不会。不管云怎么飘，终端怎么移动，综合企业应用的基础都必须存在linfd 2011-03-05 • 16:33
您说的基础是指关系型数据库?TY 2011-03-05 • 19:43
说白点是数据（信息）。落实在架构上，是”数据库“。落实到具体实现上，目前似乎也没有真正“取代”关系数据库的东西（保守点地说，对综合企业应用或叫信息系统）
yushan 2011-03-11 • 14:03
我们搜集了一些与本体密切相关的重要模型概念，将它们与本体的关系绘制成一个示意图。它主要基于较为宽泛的本体及模型概念理解（留意这个图很难展表现这些概念之间的复杂关系）。这个图至少给出这样一种信息：所有这些重要的模型概念，都可以从本体研究那里找到重叠或借鉴的东西。 从更深的层次看，搞清楚它们描述内容的范围、方法及其具体限制等等，才是更重要的，或者说，看到所有这些工作的相同（重叠）与不同之处才是最重要的，而不是拘泥于概念的纯粹性或规范性、完备性。
在老余举出的这些相关概念中，我觉的缺了术语体系（术语学），也许这个可以看作字典、词汇表和分类法中的一部分吧。在企业架构中，划分出业务平台一层，它的特征是与技术平台无关。
业务平台要求能够制定对企业本体（企业工程）的描述语言，它与 IT 语言无关。
但既然它可以对所有的行业企业模型进行表述，所以它又是一种企业本体的元语言，还不是领域语言。
领域语言才是与行业有关的语言，它的精髓应该就是要回答何以能形成一个独立的行业语义框架，所谓的行业本体，也许这就是我多年一直要追踪抓住的“在逃犯”。
据我所知，目前研究领域语言，都没有达到这一层认识。一个典型例子是，研究行业术语的，还有所谓的语义网，还是停留在对图书检索中使用的上下位概念，集合/元素关系，整体/部分等关系津津乐道，这些关系是概念之间的逻辑关系，是分析命题。这些逻辑分析概念中，没有与行业的任何关系。
而康德早就指出，我们的全部问题是应该回答：必然的综合语句如何可能？这个关键问题。
把这个哲学问题进行语言学转向，就是要回答：
何以一些概念术语它们构成了一个完整的语义框架，可以成为一个行业的本体。我现在应该说，已经找到了“在逃犯”的出生户口了，抓到他就不难了。TY 2011-03-11 • 16:25
补充得好。术语学（terminology ）当然可以列进去。
领域专用语言（DSL）这个概念本身就联系着某些悖论。相比之下，“本体”这个概念显得很纯粹和基本。在国外，它代表一个方向。
原始发表：企业工程论坛，2011-02-28,
http://www.ee-forum.org/wp/pub/ty/2011-02-p2491.html）
作者印：dcb442
相关阅读
