【发布时间】：2015-08-14 05:42:04
【问题描述】：
信息模型和本体有什么区别？
它们在我看来是一样的。
谢谢！
【问题讨论】：
标签： database-design data-modeling ontology information-theory
【发布时间】：2015-08-14 05:42:04
【问题描述】：
简短的回答是本体是理论，信息模型是应用。
Difference Between Ontology and Epistemology
本体研究如何根据相似的特征将各种现有实体组合在一起，并试图找出这些相似之处。该字段还尝试查找存在的对象之间的关系。
在特定应用程序中，您不需要所有实体和所有关系。您只需要对那个应用程序或应用程序组（公司）有意义的那些。
一个简单的例子是地址。大多数公司将地址存储为字符串，因为它们仅在与其他公司或客户生成通信时使用地址。
美国邮政局需要将其所有地址分成不同的字段。他们必须与城市和州交叉检查邮政编码。在较大的城市中，邮政编码可能会根据特定街道的门牌号而变化。
这个邮政服务的地址本体对于大多数其他公司使用来说过于详细。
【讨论】：
-
那么，将地址存储为字符串被认为是“信息模型”的一部分，而拥有地址实体是本体的一部分？谢谢！
-
本体让我想到了 ER 建模，因为它最初是在 1970 年代提出的。毕竟，如果不是实体的发现，本体是什么？
-
邮政编码实际上是一个有趣的案例。当执行“区域改进计划”（ZIP）时，代码的目的就是：代码。这意味着它们不仅仅是字符串。 USPS 以外的一些人对他们的某些功能感兴趣。例如，按邮政编码分类的大宗邮件（或曾经）比未分类的大宗邮件便宜。
两者之间并没有 100% 的明确区分，这或许可以解释为什么您将它们视为同一事物。你可以说一个本体总是一个模型，但一个模型并不总是一个本体——这个观点得到了this presentation 的支持，它比现在更深入地讨论了（有时可能更概念化）适合SO。
如果您接受上述解释（本体是模型的子集），那么只需了解信息模型何时是本体。回到演示文稿，它说本体是概念性的，而不是物理构造，是关于现实世界而不是软件或代码。
该演示文稿将本体的创建与在创建类图之前执行的域建模进行了比较，但是正如您在数据库上下文中所询问的那样，明显的比较是概念数据模型......当然可能与这样的域模型相同。如果您考虑数据建模过程，您将创建一个没有属性或数据类型的概念模型，然后再转向逻辑模型和物理模型，这些模型的存在是为了处理模型的规范化以防止数据异常，定义数据类型等等。因此，概念数据模型很可能可以描述为本体，但逻辑和物理模型不能。
领域模型（旨在作为面向对象类模型的第一步）可能与概念模型（旨在作为关系物理数据模型的第一步）相同的原因是我们完全没有OO 语言和 RDBMS 施加的限制或过程中的规范化规则。我们只对我们感兴趣的概念以及它们之间的关系进行建模。对象关系阻抗不匹配问题仅在您采用这两种物理建模域区域的方法时才存在 - 它在概念级别不存在。
吉尔伯特在他的回答中所说的几乎就在那里 - 他是正确的，地址作为字符串的物理表示是信息建模定义。但是 USPS 决定将其存储为单独的字段也是信息建模定义。本体定义只是关于地址的概念，以及描述地址不同部分的概念，以及它们之间的关系如何意味着地址是由概念部分的特定集合组成的。如果为零售公司工作的人和为 USPS 工作的人决定使用相同的语言或工具创建地址的本体定义，他们应该提出一些非常相似的东西，如果不完全相同的话。将这些概念全部存储在一个字符串或一个数字、一个字符串、另一个数字等中的决定适用于信息建模领域。
【讨论】：
-
你对“物理”感到困惑。域是逻辑的一部分，因此域的选择（单个域“地址”与各种不同的域“国家”“州”“邮政编码”“街道名称”“门牌号”）是逻辑级别的选择，而不是物理级别的选择.
-
但是选择在数据库中维护该结构是物理级别的选择。公司和 USPS 都必须做出物理设计决策，示例中的 USPS 只是选择了更接近概念和逻辑表示的一种。
一些带有“本体”的引用
从文本中学习本体的挑战当然是推导 基于某些符号使用的有意义的概念，即 单词或术语
（“Ontology Learning and Population from Text”，Philipp Cimiano）
为了真正应对当前和未来的挑战，一个 需要企业的概念模型，以保持一致， 全面、一致、简洁，只显示见 企业模式的运作……我们称之为 概念模型和本体模型"
（“企业本体”，Jan Dietz）
据此，我会说信息模型和本体是同义词。 Ontology 具有更多的哲学背景，希腊起源，并且在 Michel Foucault 的书中比 IT 文档更受期待，但这两个词都表示“存在的事物”。
【讨论】：