Practical Ontologies & How to Build Them - Part 3
企业级实用本体论及构建指南系列(1/4)：Palantir 数据建模的哲学与实践
企业级实用本体论的实践指南(2/4)：Palantir Foundry如何将组织数据映射到本体概念及关键设计考量
文章摘要
本文是关于如何在Palantir Foundry中应用本体论思维来操作数据的四部曲系列的第三部分。我们将深入探讨对象、事件和时间序列之间的区别，分析何时使用它们以构建实用且易于理解的本体论，旨在为企事业单位和科研专家提供数据建模的实用指南。
全文推文
引言：本体论在数据操作中的重要性
在当今数据驱动的时代，如何高效地组织和利用数据成为企事业单位及科研院所的核心挑战。本体论（Ontology）作为一种结构化数据建模方法，能够帮助组织将复杂的业务数据转化为可操作的洞察。本文是“实用本体论与构建之道”系列的第三部分，聚焦于Palantir Foundry平台中对象（Objects）、事件（Events）和时间序列（Time Series）的应用与建模策略。通过对这些核心概念的深入剖析，我们希望为专业人士提供实用工具，帮助他们在数据管理和分析中更进一步。
Palantir Foundry作为一个强大的数据整合与分析平台，提供了丰富的工具来支持本体论的构建与应用。本系列的前两部分已经介绍了本体论的基础概念以及在Foundry中构建操作性本体论的关键考量。在这一部分中，我们将深入探讨如何区分和应用对象、事件与时间序列，并结合实际案例分析在Foundry中建模的最佳实践。
核心概念：对象、事件与时间序列的区别
在构建本体论时，对象、事件和时间序列是三个基本且相互区分的概念。理解它们的定义和适用场景对于构建清晰且高效的数据模型至关重要。以下是对三者的详细解析：
对象（Objects）：对象是随时间持续存在的实体，其属性会随时间演变，且之前的属性值会被覆盖。例如，一个“人（Person）”对象的“年龄（Age）”属性会随着时间增加而更新。这种可变性（Mutability）是对象的核心特性，意味着对象的属性值会随着时间在原地演化，而不保留历史记录。
事件（Events）：事件是在某个时间点发生或持续一段时间的活动，其属性在事件发生时或期间被捕获，且之后不再改变。例如，一个“旅程（Journey）”事件可能包含“开始时间（Start Time）”、“结束时间（End Time）”和“持续时间（Duration）”等属性。事件通常是时间性的且不可变的，一旦事件结束，其属性值就固定下来。
时间序列（Time Series）：时间序列记录了对象属性值随时间变化的历史记录。例如，一个“传感器（Sensor）”对象的“温度（Temperature）”属性会随时间变化，生成一个时间序列，存储每次变化的值及其对应的日期和时间。时间序列与事件类似，也是时间性和不可变的，但其重点在于记录连续或离散的时间点上的数据变化。
需要注意的是，尽管上述定义提供了一个清晰的框架，但实际应用中也存在一些边缘情况。例如，一个“旅程”事件的“状态（Status）”属性可能在旅程进行过程中从“进行中（In Progress）”更新为“完成（Complete）”，显示出一定的可变性。然而，事件中捕获的其他数据（如平均速度或行驶距离）在事件结束后通常不再变化。
在Palantir Foundry中的建模实践
在Palantir Foundry平台中，对象和事件都被建模为“对象类型（Object Types）”。本体论上的区别主要体现在为每种对象类型添加的属性选择上。例如，创建一个“铁路旅程（Rail Journeys）”对象类型时，可以通过添加“开始时间戳（Start_Timestamp）”和“结束时间戳（End_Timestamp）”属性，确保其在下游应用中作为事件使用。此外，在Foundry的“本体管理器（Ontology Manager）”的“能力（Capabilities）”选项卡中配置对象时，可以明确指定开始和结束时间属性，将其标记为事件。这种配置在某些应用（如Vertex）中是必需的，而在大多数情况下是可选的。
如果需要将事件与其他时间信息（如时间序列属性）结合使用，例如在时间序列图表上叠加事件或使用事件边界过滤时间序列数据，则必须在本体论中明确配置事件。
时间序列属性的处理
在Foundry中，时间序列通过“时间序列属性（Time Series Properties）”来处理，这些属性记录了对象某个属性随时间的历史值。例如，车辆在旅程中的“燃料水平（Fuel Level）”可以作为时间序列属性存储。
在开发Foundry本体论时，常常需要决定如何捕获时间数据：是将时间序列属性添加到对象中，还是创建一个与事件相关的新事件类型对象，并将其链接到原始对象。以“车辆（Vehicle）”对象类型为例，
创建“旅程（Journeys）”对象类型作为事件：从本体论上看，这是一个事件。如果后台数据规模适中（例如几百到几百万条旅程记录），这种方法是合理的。这种建模方式通常反映了数据在源系统中的存储方式，简单直观。
创建聚合视图，例如“每日车辆旅程指标（Daily Vehicle Journey Metrics）”：这种方法按天和车辆为键，存储一天内车辆旅程数据的聚合结果，如“每趟旅程平均燃料消耗”或“当天总活跃秒数”。如果数据规模较大且下游用例仅需聚合指标，这种方法可以节省计算和存储资源。
从事件表中提取时间序列属性并添加到车辆对象类型：这种方法有两个主要原因：一是数据规模需要（时间序列属性在Foundry中存储和查询效率高）；二是下游用例会受益于时间序列格式的数据，例如需要基于原始时间序列创建多个派生时间序列（如导数、积分或其他时间计算）。
需要注意的是，上述“燃料水平”时间序列可能较为稀疏，通常我们希望数据源能提供更频繁的更新（如每秒更新一次燃料水平），例如通过车辆上的传感器获取数据。在Foundry中，每个时间序列都需要一个唯一标识符（例如“时间序列ID”列，结合时间序列名称和车辆主键生成）。将时间序列连接到“车辆”对象类型时，
存储方式对用例的影响
以时间序列形式存储车辆的燃料水平（而不是作为旅程的开始和结束燃料水平属性）会改变数据在Foundry中的潜在用例。选择哪种方法取决于数据需求和目标解决方案。从存储和计算效率的角度看，时间序列属性通常更高效，因此在适用用例中应优先使用。时间序列属性还具有一致的格式，无论追踪的对象或属性为何，其本质都是时间点上的值集合。因此，它们可以通过减少事件类型对象的需求，简化本体论结构，将其替换为对象上的时间序列属性。
在实际应用中，由于Foundry提供了多种操作工具，有些工具更适合时间序列属性，有些则更适合事件类型对象，因此一种常见的做法是同时以两种方式建模时间数据：
创建一个事件类型的“旅程（Journeys）”对象类型； 在相关“车辆（Vehicles）”对象上创建时间序列属性。
这些时间序列可能部分从旅程数据中提取，部分来自其他源系统（如存储传感器读数的数据库）。这种双重建模方式确保数据可用于各种下游用例，最大化其价值。
展望：系列第四部分的主题
在“实用本体论与构建之道”系列的第四部分中，我们将探索Foundry本体论中的动词（或称“动作，Actions”）的使用。这些动作用于实现变更和触发业务流程，是构建本体论的关键考量。通过将人类决策的结果反馈到本体论中，动作通常能解锁全新的价值维度。
