历史学家知识工程/建模 简介：上下文
由于这是一本面向历史学家的书籍，我们将提到，关于以下讨论中所述概念的完整历史，但我们现在不会深入探讨，因为它们不会有助于对初始理解的理解。
知识工程的基本问题是，执行实际推理的逻辑理论无法很好地处理不一致或矛盾的信息（还记得星际迷航中那些爆炸的计算机吗？）。不幸的是，知识工程模型所模拟的人类理论往往是相互矛盾的。
引入上下文，它基本上允许我们将单个陈述分配给单个说话者。
更像是我们正在努力成为的知识工程师，我们可以通过引入一个新的关系来最好地解释上下文：让ist表示“在（上下文）中为真”。
;; the controversy surrounding Wolfang Amadeus Mozart's relationship ;; with Antonio Salieri represented kills(AntonioSalieri,WolfgangAmadeusMozart) not(kills(AntonioSalieri,WolfgangAmadeusMozart))
;; contextualizing the claims via ist ist(Amadeus-TheMovie,kills(AntonioSalieri,WolfgangAmadeusMozart)) ist(Austria18thCenturyContext,not(kills(AntonioSalieri,WolfgangAmadeusMozart)))
虽然第一个表示会明显导致矛盾，但第二个不必；事实上，这些主张很好地隔离在不同的上下文中。然而，语境化是一个非此即彼的命题；要么每个语句都与一个上下文“柯里化”，要么都没有。通常，这种情况通过识别一个基本或默认上下文来处理，在这个上下文中，那些没有意义地进行语境化（即由所有上下文共享）的东西可以被放置。
上下文可以组织成包含关系层次结构，就像我们看到类型层次结构可以一样。
我们两个上下文，Amadeus-TheMovie和Austria18thCenturyContext，所共享的一些背景知识现在可以移到一个父上下文中，例如，GenericMozartFama或类似的。这种将知识移到其他上下文中的行为有时被称为提升。这种方法使得开发新上下文非常经济实惠：所需的大部分知识已经在其他上下文中陈述过，然后可以简单地在新的上下文中包含起来。
- 解释为什么使用参数的一阶化不起作用
ist对上下文表示方法的一个副作用是，它可以相对简单地推论到其他上下文。例如，以下查询可用于查找电影和莫扎特的现实生活存在差异的所有情况
;; get the points of contention ist(?CONTEXT-A,?SENTENCE) && subsumesContext(?CONTEXT-A,GenericMozartFama) && ist(?CONTEXT-B,not(?SENTENCE)) && subsumesContext(?CONTEXT-B,GenericMozartFama)
同样，这不再是一阶逻辑查询，因为我们不再仅仅关注关系，而是关注包含谓词的整个句子。这是一个更高阶的查询。
一些表示语言，如CycL，是在对上下文的可用性做出强假设的情况下设计的；在这些语言中，它们被称为微理论，并在OpenCyc和其他CycL实现中得到特殊实现支持。不幸的是，许多表示或推理系统都没有对上下文进行明确的支持。由于非 FOL 的需求，模拟上下文可能会很困难。
在简要概述了上下文对知识工程推理的贡献之后，我们准备进入一个大型示例，该示例将突出显示我们迄今为止讨论的所有功能。希望这将把不同的部分汇集在一起，并让您了解历史学家知识工程如何变得可操作。