关于双时态RDF模型的实现：一种实验方法 吴迪、 王宪曾、 阿卜杜拉·乌兹·坦塞尔

《Informatics》：On the Implementations of theBiTemporal RDF Model: An Experimental Approach Di Wu, Hsien-Tseng Wang and Abdullah Uz Tansel

　　摘要 双时态RDF（BiTRDF）模型通过整合有效时间和事务时间来扩展标准的RDF数据模型，从而能够表示和查询动态和历史知识。尽管BiTRDF的理论基础已经建立，但其实际实现策略尚未得到系统研究。本文通过探索六种实现BiTRDF的替代方法来填补这一空白，这些方法结合了面向对象编程和面向数据库的设计，使用Python和PostgreSQL。我们使用从50万到1600万个双时态三元组六个合成数据集来评估这些方法。评估关注内存消耗、数据加载时间和随着数据量增加的查询性能。结果显示，当知识存储适合内存时，所有方法的性能相当。随着数据集规模超出可用RAM，面向数据库的实现实现了显著更好的加载和查询性能，而面向对象的实现则提供了更大的灵活性和可扩展性。这些发现证明了使用现有技术实现BiTRDF的可行性，并为根据数据规模、性能要求和可扩展性需求选择适当的实现策略提供了实际指导。

1. 引言
互联网已经超越了通信、交易和云存储的平台，现在成为一个庞大且持续扩展的知识库，人类和机器都在其中创建、共享和分析信息。语义网被提出是为了通过语义网层次结构框架实现机器可理解的数据和自动化推理[1]。该框架的核心是资源描述框架（RDF），它提供了一个标准模型，用于将知识表示为形式为 ?????????????????????, ??????????????????????????, ?????????????????? 的三元组。尽管其简单且被广泛采用，但标准RDF仅限于表示二元关系。建模更复杂的n元关系通常需要具体化或额外的扩展，这会增加建模复杂性并可能引入性能开销。当使用RDF表示动态和演变的知识时，这些限制变得更加明显。
时间信息是许多现实世界应用的基本方面，包括法律记录、金融系统、科学数据管理和历史知识库。时间数据通常可以分为两类：有效时间，表示事实在现实世界中成立的时间；以及事务时间，表示该事实在数据存储中存储、更新或删除的时间。时间关系数据库强调管理这两个时间维度的重要性，以支持审计、历史查询和数据一致性。
同样，也有越来越多的需求在RDF和RDF Schema中支持时间语义。时间RDF扩展旨在捕捉知识随时间的演变并启用历史推理。然而，许多现有方法将时间视为属性，严重依赖具体化，或仅支持单一时间维度。因此，这些模型往往面临结构复杂性增加、可扩展性受限或实现策略不明确的问题。
双时态RDF模型（BiTRDF）通过统一地将有效时间和事务时间扩展到RDF来解决这些挑战。在这种模型中，时间被视为一参考，将时间语义直接嵌入RDF资源中，而不是作为辅助属性附加时间戳。这种设计避免了基于具体化的时间知识管理方法的复杂性[2,3]。在BiTRDF中，所有资源和关系本质上都是双时态的，从而实现更清晰的语义和更强的时间一致性。尽管之前的工作已经建立了BiTRDF的理论基础，但实际问题仍然存在。特别是，目前还不清楚如何使用现有的编程语言和数据管理技术高效地实现、存储、查询和扩展BiTRDF。
本文的目标是弥合理论和实践之间的差距。我们通过结合面向对象编程技术和面向数据库的设计来探索BiTRDF的多种实现策略。我们没有提出单一的实现方案，而是研究和比较了六种替代方法，每种方法代表了灵活性、性能、内存消耗和可扩展性之间的不同权衡。通过系统的实验，我们使用不同大小的数据集来评估这些方法，并分析它们在数据加载和查询等常见操作下的行为。
为了实现上述目标，以下三个考虑因素指导了我们的研究：
- 有效地将BiTRDF映射到关系型和面向对象的结构，同时保持时间一致性。
- 在数据集规模超过物理内存时，研究以内存为中心和以存储为中心的设计之间的性能权衡。
本文的其余部分组织如下。第2节回顾了关于时间RDF扩展和双时态数据管理的相关工作。第3节总结了双时态RDF模型的关键定义和原则。第4节介绍了六种BiTRDF方法的设计和实现，包括一个运行示例和查询说明。第5节描述了实验设置和评估方法，第6节对性能结果进行了比较分析，并讨论了发现。最后，第7节以对未来工作的建议和方向结束了本文。
附录中提供了额外的支持细节：附录A详细介绍了输入-处理-输出（IPO）工作流程；附录B、附录C、附录D、附录E、附录F和附录G说明了在每种方法中实现的运行示例；附录H提供了全面的双时态查询示例；附录I包含了来自性能实验的详细数据表。

2. 相关工作
尽管时间RDF已经得到了广泛研究，但大多数研究集中在表示上，而不是高效实现上。常见的组织方式是在RDF模型中附加时间信息：图形级嵌入、三元组级嵌入和资源级嵌入[4]。图形级方法通常使用命名图将共享的时间上下文与一组三元组关联起来[5]。三元组级方法通过显式或隐式的具体化将时间附加到单个声明上，这可能会增加三元组数量并使查询处理复杂化[6,7]。资源级方法通过时间化RDF资源（主体、谓词和/或对象）来时间化RDF，例如，通过时间化谓词（如Singleton Property）或引入实体版本（如4D Fluents）[8,9]。
本研究不是提出新的编码方式，而是实现了并评估了BiTRDF，这是一种在资源级别上将两个时间维度统一分配给RDF资源的双时态模型[2,3]。因此，我们将相关工作围绕（i）RDF存储工程和索引，（ii）现有引擎上对时间/版本化RDF的可执行支持，以及（iii）为实施设计提供信息的双时态数据库基础来进行。

2.1. SPARQL工作负载的RDF存储实现和索引
RDF查询性能主要由物理设计决定，包括存储布局、索引和连接处理。Sesame示例了一个独立于存储的架构，它将查询评估与存储后端分离，从而在同一查询层下实现不同的后端实现[10]。对RDF存储和SPARQL引擎的调查显示，物理设计通常是主要的性能因素[11]。
RDF中的三元组模式查询受益于对主体、谓词和对象的多种排列的索引。Hexastore通过六元组索引支持不同访问模式的加速[12]。RDF-3X同样表明，仔细的索引设计加上高效的查询处理可以将SPARQL评估扩展到大型数据集[13]。这激励我们将索引和访问路径设计视为我们BiTRDF实现研究中的关键变量。

2.2. 在现有RDF存储上执行的时间化和版本化RDF
一个关键的实际问题是现有的RDF标准是否可以处理时间语义。命名图提供了一种标准方式，用于将元数据（如出处和时间上下文）附加到三元组集[5]。利用这一想法，关于RDF归档的研究通常在数据中编码版本，并将版本化查询转换为标准SPARQL系统。Cuevas和Hogan比较了几种用于RDF归档的命名图编码，并研究了这些选择如何影响查询成本[14]。Ostrich提出了用于随机访问版本化查询的存储和索引方法，并分析了数据加载、存储开销和查询性能之间的权衡[15]。总体而言，这些研究表明，时间感知的RDF支持往往较少依赖于抽象模型，而更多依赖于数据的存储方式和查询的执行方式。

2.3. 用于实现BiTRDF的双时态数据库
BiTRDF的设计理念是基于双时态数据库的。它支持有效时间和事务时间，以实现类似时间“截至”和变化导向的查询的操作符。TSQL2整合了核心的时间数据库概念，并标准化了后来系统经常采用的时间操作符[16]。当这些想法应用于RDF时，许多现有方法要么将时间视为属性，要么添加额外的结构层（例如具体化或映射构造）。SPARQL及其扩展（如C-SPARQL）提供了在查询执行时评估时间条件的机制来查询RDF数据。然而，这些方法通常将时间信息视为注释或外部属性，并不强制执行数据模型级别的时间一致性。相比之下，BiTRDF模型将有效时间和事务时间语义直接嵌入RDF资源和关系中，确保时间一致性作为数据的内在属性得以维护。
虽然提出了几种替代的时间RDF模型，但目前还没有建立用于并行性能基准测试的双时态RDF原型[4]。因此，本工作中介绍的实现侧重于实现这种资源级别的双时态表示，提供了一个存储和索引基础，可以更一致地支持时间查询。我们基于现有的RDF存储和归档见解，比较和评估了存储组织、索引和查询执行方面的权衡[11,12,13,15]。

3. BiTRDF模型概述
本节简要介绍了双时态RDF（BiTRDF）模型[2,3]，为本文后面探讨的实现策略提供了理论基础。本节介绍了直接影响系统设计和实现的关键概念和约束。
BiTRDF通过将两个时间维度整合到所有RDF资源中来扩展标准的RDF数据模型。BiTRDF的核心设计原则是将时间视为参考，而不是属性。而不是用时间戳注释事实，时间语义直接嵌入RDF资源和关系的结构中。这种设计导致模型更清晰，并能够对现实世界的有效性和系统历史进行一致推理。
BiTRDF引入了两个时间维度：
- 有效时间（VT），表示事实在现实世界中成立的时期；
- 事务时间（TT），表示事实在知识库中存储、已知或维护的时期。
这些维度使BiTRDF能够捕捉现实世界事实和系统知识的演变，这在概念上与双时态关系数据库一致。

3.1. 双时态资源和三元组
在BiTRDF中，所有RDF组件——主体、谓词和对象——本质上都是双时态的。每个资源都携带一个有效时间区间和一个事务时间区间，表示其在现实世界中的存在及其在系统中的记录历史。
- 双时态资源（??????????）：一个标准的RDF资源r扩展了有效时间区间（?????）和事务时间区间（?????）。形式上任一双时态资源定义为：??????????={??•?????•?????∣??∈??∧?????∈???????∧?????∈???????},
其中R表示RDF资源集，???????和???????分别表示有效时间区间和事务时间区间集。直观地说，?????指定了资源在现实世界中存在或成立的时间，而?????指定了它被系统知道或维护的时间。
- 双时态三元组（?????????????????????????）：一个双时态三元组在保持其所有组件时间一致性的同时保留了标准的RDF结构：?????????????????????????︰{???????????????????????????????>∣??????????∈(??????????∪??????????)∧??????????∈??????????∧??????????∈(??????????∪??????????∪??????????)∧??????????.?????≠?∧??????????.?????≠?∧??????????.??????(??????????.??3∩??????????.?????)∧??????????.??????(??????????.?????∩??????????.?????)}，
其中??????????、??????????、??????????和??????????分别表示双时态IRI、空节点、文字和谓词集。
这个定义施加了一个关键约束：一个关系只有在它的主体和对象存在于相同的有效时间和事务时间区间内时才能存在。这个约束对于维护时间一致性至关重要，并对BiTRDF数据结构的存储和验证方式有直接影响。

3.2. 时间一致性和核心操作符
BiTRDF模型的一个核心优势是其内置的时间一致性支持。BiTRDF通过一个完整性规则和两个核心操作符确保知识库中的所有事实在时间上是一致的。这些运算符允许系统重建过去的系统状态和对真实世界的历史视图。双时态三重一致性（BiTemporal Triple Integrity）：对于一个双时态谓词??????????来说，其主体??????????和对象??????????必须在谓词的时间跨度内共存：??????????.??????(??????????.?????∩??????????.?????)∧??????????.??????(??????????.?????∩??????????.?????)（3）。这条规则防止了时间矛盾，例如断言在相同时间不存在的实体之间的关系，并确保知识库始终代表一个逻辑上可能的世界。回滚运算符（Rollback Operator，??????）：回滚运算符可以重建知识库在某个过去时间????的状态：???????(?????)={??∣??.??????????}（4）。这个运算符支持诸如“系统在时间????时知道什么？”这样的查询，并提供了一种正式的机制来恢复历史系统状态。时间切片运算符（Time Slice Operator，????）：时间切片运算符可以检索在给定有效时间间隔????内对真实世界有效的事实，这些事实是在时间????的交易时记录的：?????(?????,????,????)={??∣??.?????=????∧??.??????????}（5）。这个运算符能够重建历史世界状态，并支持诸如“根据当时的知识，这个时期发生了什么？”这样的查询。这些运算符的完整形式语义和证明可以在[2,3]中找到。BiTRDF模型及其核心运算符共同为基于RDF的系统管理双时态知识提供了一个严格且面向实现的基础。在下一节中，我们将在此基础上提出BiTRDF的具体设计选择和实现策略。

RDF存储负责持久存储、管理和查询RDF图。由于BiTRDF扩展了标准RDF模型以支持双时态语义，其实现必须支持双时态资源和双时态三重组的创建、存储、检索和查询，同时保持时间一致性和可接受的查询性能。基于第3节介绍的??????????和?????????????????????????的形式定义，我们现在将这些理论约束（特别是三重一致性规则）转化为具体的数据结构和逻辑。本节介绍了两种BiTRDF的实现策略。第一种策略采用关系数据库视角，使用PostgreSQL，并强调持久性、索引和可扩展性。第二种策略遵循面向对象编程（OOP）设计，使用Python（版本3.8.8）实现，并强调灵活性、模块化和内存中的性能。这些方法展示了性能、内存使用、可扩展性和系统复杂性之间的权衡。特别关注索引和搜索机制，因为查询处理是时间知识存储的核心要求。

关系数据库系统为管理结构化和持久化数据提供了一个成熟而健壮的基础。虽然存在原生的RDF存储，但许多系统无法高效支持复杂的基于区间的逻辑[2]。特别是，大多数RDF引擎都是围绕固定的基于三重组的模式设计的，通常通过具体化、命名图或注释模式来支持时间信息，这引入了额外的结构开销并复杂化了查询处理。选择PostgreSQL是因为它支持自定义复合数据类型和GiST索引，这些更适合双时态区间运算，而不是标准的三重组存储索引[17]。这些特性使得可以直接使用原生数据库操作对双时态属性进行建模并高效评估，而不是在RDF结构中间接编码。此外，这种选择能够精确控制存储布局和索引策略，这对于系统地评估不同BiTRDF实现的性能权衡至关重要。数据库模式遵循时间数据库设计的既定原则[18]，并将BiTRDF概念直接映射到关系构造。该设计包括一个复合数据类型和三个核心表。

双时态资源数据类型：PostgreSQL允许用户使用CREATE TYPE语句定义自定义复合数据类型。为了表示双时态资源，我们定义了一个名为BiTemporalResource的复合类型，它封装了有效时间和事务时间区间：Name字段表示标准的RDF资源标识符，而其他字段捕捉其有效时间和事务时间区间。这种数据类型直接对应于BiTRDF资源模型，并在各个表中重复使用，以确保一致性并简化时间查询处理。

双时态三重组表：双时态三重组存储在一个名为BiTemporalTripleTable的专用表中：每一行代表一个单独的双时态三重组。Id列唯一标识一个三重组，并支持索引和未来的扩展。主体和对象作为资源标识符存储，而谓词使用BiTemporalResource类型存储，以捕捉它们的时间语义。这种设计在避免不必要地复制实体级别的时间数据的同时，保持了关系的时间一致性。

为了独立管理实体和谓词的时间元数据，定义了两个额外的表：这些表存储了主体、对象和谓词的时间生命周期。主键约束确保了唯一性，并允许在查询执行和完整性验证期间高效查找双时态资源。高效查询处理对RDF存储至关重要。PostgreSQL自动为主键创建B树索引，从而快速检索实体和谓词。在三重组表上定义了额外的索引，以支持常见的RDF访问模式：这些索引对应于标准的主体-谓词-对象排列，并允许根据任何三重组组件进行高效查询。B树索引提供对数时间复杂度，并支持精确匹配和基于范围的时间条件。

除了基于数据库的方法外，BiTRDF还可以使用Python的面向对象设计来实现。这种方法强调模块性、可扩展性和易于实验，非常适合原型设计和内存分析。实现读取用Turtle语法[19]表示的BiTRDF图。每个输入行代表一个双时态三重组。输入处理器顺序解析文件，并将每一行分解为RDF资源、时间区间和结构关系。为简单起见，假设输入文件在语法上是正确的。

面向对象的设计将BiTRDF的构建分解为几个模块化组件：资源构造器（Resource Constructor），将IRI、字面量或空节点转换为RDF资源对象；时间数据构造器（Temporal Data Constructor），提取时间注释并构建有效时间和事务时间区间；双时态资源构造器（Bitemporal Resource Constructor），将RDF资源与时间区间结合起来；双时态三重组构造器（Bitemporal Triple Constructor），在强制执行双时态三重组一致性的同时组装双时态主体、谓词和对象。这种模块化结构使得添加额外的维度（如置信值或空间属性）变得简单。整个输入-处理-输出工作流程总结在表A1中。统一的查询处理器支持基于模式的双时态三重组搜索。查询可以限制主体、谓词、对象、有效时间、事务时间或这些维度的组合。该处理器被设计为通用和参数驱动的，允许灵活的查询公式化。系统还支持序列化，允许将存储的知识导出回Turtle格式。这确保了输入和输出表示之间的一致性，并支持与其他RDF工具的互操作性。BiTRDF模型在概念层面定义，独立于任何特定的RDF序列化格式。虽然在我们的实现中使用了Turtle以提高可读性，但底层双时态语义可以用N-Triples或JSON-LD等替代格式保存，前提是有效时间和事务时间区间必须作为资源表示的一部分明确编码。在这种实现中，时间区间被表示为结构化的字面值，可以在不同格式之间一致地序列化。只要保持了BiTRDF的时间组件和一致性约束，序列化的选择不会影响模型的正确性。

为了支持快速的内存查询，OOP实现使用Python字典作为索引结构。字典提供基于哈希的访问，平均查找时间为常数时间。维护了三种嵌套的字典索引：主体索引：{?????????? :{??????????:{??????????}}}；谓词索引：{?????????? :{??????????:{??????????}}}；对象索引：{?????????? :{??????????:{??????????}}}。这种设计实现了高效查询，但增加了内存使用和更新开销，因为所有索引都必须保持同步。这反映了知识存储设计中常见的空间-时间权衡。

基于PostgreSQL的实现强调持久性、可扩展性和成熟的索引支持，适合大型和长期存在的BiTRDF知识存储。相比之下，面向对象的实现强调灵活性、可扩展性和快速的内存访问，非常适合实验和较小规模的工作负载。这些互补的设计构成了下一节中实证评估的基础。

实验评估的目标有三个：（1）证明BiTRDF知识存储可以正确构建和查询；（2）验证在有效时间和事务时间约束下的双时态查询的正确性；（3）比较不同实现选项在内存使用、加载时间和查询效率方面的性能。

我们检查了一系列现有的三重组存储，包括RDF Benchmarks[20]、Oracle Spatial和Graph 12c[21,22]、AllegroGraph[23]、Stardog[24,25,26]、OpenLink Virtuoso[27,28,29]、GraphDB[30,31]、BlazeGraph[32]、Jena TDB[33,34,35]、RDF4Led[36]、RDFox[37]、RDFLib[38]、3Store[39]、4Store[40]、OpenRDF Sesame[41]、Rya[42]。虽然这些三重组存储支持标准RDF模型并且通常集成SQL功能，但将它们的资源扩展以包含时间信息仍然很困难。尽管这些现有解决方案满足了一些期望，但它们缺乏包含时间知识的关键可扩展性需求。

根据第4节描述的设计前提，我们开发了一个名为BiTRDFLib的软件包，其中包含了六种实现选项。这些选项在如何表示和存储BiTRDF元素方面有所不同，使我们能够探索灵活性、性能和可扩展性之间的权衡。这些选项分为两类：面向对象的实现和以存储为导向的实现。面向对象的（OOP）实现显式构建BiTRDF元素，包括时间区间、双时态资源和双时态三重组。所有OOP选项共享相同的解析、构建、查询和序列化逻辑，仅在底层存储结构上有所不同。

OOP + 字典：使用Python字典和基于哈希的索引。维护三个字典以优化基于主体、谓词和对象的查询。OOP + DataFrame：使用Pandas DataFrame以表格形式存储双时态三重组、实体和谓词，利用内置的索引和过滤操作。OOP + 列表：将每个双时态三重组作为列表元素存储，不进行重组。这种方法最小化了结构开销，但未优化查询性能。

以存储为导向的实现通过直接存储原子值而不是对象实例来优先考虑简单性和性能。这些方法绕过了BiTRDF元素的构建，而是专注于高效的价值级存储。数据库 + PostgreSQL：使用关系模式和复合双时态数据类型，如第4节所述，并将数据持久化在PostgreSQL数据库中。数据库 + 字典：将每个双时态三重组存储为15个原子值，对应于三个双时态资源及其时间区间，使用Python字典。

为了演示目的，我们使用了一个运行的示例BiTRDF知识存储：这个替代方案被包括进来，是为了为那些优先考虑快速部署而非效率的场景提供直接的实现方法。存储在列表中的运行示例在附录D.5.5中有所描述。数据库实现方面，虽然面向对象的替代方案用于构建BiTRDF实例，但面向数据库的替代方案则侧重于三元组的检索。在没有BiTRDF元素的情况下，数据库逻辑中的替代方案在面向对象逻辑上缺乏灵活性和扩展性，但它们在加载和搜索方面可以更高效。我们在本节中详细讨论了这些可能的替代方案。

**数据库 + PostgreSQL**：在这个替代方案中，我们采用了一个关系型数据库，并使用了一个名为Pony的Python包来在Python和PostgreSQL之间进行通信。存储在关系表中的运行示例在附录E中有所描述。

**数据库 + 字典**：在这个替代方案中，我们也采用了Python字典数据结构。一个双时态三元组包含15个部分，分别为：????????????????????_???????????????????????、????????????????????_???????、????????????????????_???????、????????????????????_???????、????????????????????_???????、??????????????????????????_???????????????????????、??????????????????????????_???????、??????????????????????????_???????、??????????????????????????_???????、??????????????????????????_???????、?????????????????_???????????????????????、?????????????????_???????、?????????????????_???????、?????????????????_???????。这种存储结构是正式的BiTemporal Resource定义的直接映射。由于一个双时态资源由5个部分组成，而一个三元组由3个双时态资源组成，因此总存储需求为15个原子值。由于文本文件中的每一行代表一个双时态三元组，我们直接将这些15个值存储在字典中。存储在字典中的运行示例在附录F中有所描述。

**数据库 + 列表**：在这个替代方案中，我们也采用了Python列表数据结构。如前一个替代方案所述，每个双时态三元组包含15个部分。一个大小为15的列表可以存储这些部分的值。存储在列表中的运行示例在附录G中有所描述。

**查询示例**：我们评估了三类查询：
- **结构化查询**，通过主题、谓词或对象进行过滤；
- **有效时间查询**，检索在指定时间点有效的事实；
- **事务时间查询**，重新构建给定事务时间点的知识存储。

代表性的查询结果显示在表A2、表A3、表A4、表A5、表A6、表A7、表A8、表A9、表A10、表A11、表A12和表A13中。这些示例证实了BiTRDF操作符正确地执行了有效时间约束并支持回滚语义。

**用例场景**：该数据集被设计用来模拟具有时间演变的动态知识图谱，在这种图谱中，实体和关系会随着现实世界时间（有效时间）和系统记录时间（事务时间）的变化而变化。这种场景常见于以下领域：
- 人员和就业历史跟踪；
- 位置和移动数据（例如，个人在不同地区之间的移动）；
- 组织隶属关系和机构变更；
- 版本化的知识库和数据审计系统。

在这项研究中，我们将这种时间实体-关系演变场景作为人员记录、移动跟踪和组织历史等领域的抽象用例，其中实体随着时间改变位置和隶属关系，这些变化需要根据有效时间（变化发生时）和事务时间（记录时）进行审计。这一概念性场景直接指导了我们合成数据集的设计，这些数据集编码了在两个时间维度下实体和关系的演变模式，同时允许我们系统地控制规模和时间分布以进行性能实验。第5.3节中的运行示例（例如，个人随时间居住在不同州并在不同机构工作）反映了这种时间实体-关系演变场景，这是更大规模合成数据集的概念基础。

**数据集描述**：为了评估性能和可扩展性，我们生成了六个合成的BiTRDF知识存储。这些数据集是系统生成的，以控制系统控制：
- 双时态三元组的数量；
- 有效时间和事务时间间隔的分布；
- 结构维度和时间维度的独立性。

这种设计使我们能够隔离系统级别的性能特性（内存使用、加载时间和查询效率），而不受特定领域数据不规则性的干扰。虽然数据是合成的，但它保留了现实世界时间知识图谱的结构和时间属性，包括重叠的时间间隔、演变的关系和多版本实体状态。基于这种受控设计，数据集进一步结构化以评估在逐渐增加的数据量下的可扩展性。具体来说，我们生成了六个规模逐渐增加的知识存储，以模拟高频双时态事件场景，如财务审计或法律记录，其中精确定位有效时间和事务时间对于数据来源证明至关重要。每个双时态三元组由三个此类资源组成。例如，以下是随机生成的双时态三元组：

根据指定的双时态三元组数量创建了BiTRDF知识存储。我们从一个相对较小的知识存储开始，只有500,000个三元组，最终到一个相对较大的知识存储，有16,000,000个三元组。为了评估它们的性能扩展性，每个三元组存储的三元组数量都翻倍。特别是，我们希望检查并比较在计算需求超过随机访问内存（RAM）并且操作系统需要在RAM和物理存储之间交换之前的性能。我们在表1中总结了这六个BiTRDF知识存储。表1总结了六个知识存储。所选择的数据集设计特别适合评估BiTRDF模型。首先，它需要同时管理有效时间（现实世界的变化）和事务时间（系统记录的历史），这两个是BiTRDF的两个核心时间维度。其次，生成的数据在实体和关系之间强制执行时间一致性，反映了BiTRDF模型（第3节）中定义的完整性约束。第三，数据集支持代表性的查询模式，包括时间切片查询（例如，“在时间t时什么是真的？”）和回滚查询（例如，“系统在时间t时知道什么？”），这些与BiTRDF操作符直接对齐。因此，数据集为评估BiTRDF实现的正确性和性能提供了一个受控且具有代表性的环境。

**测试设备描述**：所有实验都是在配置如表2所示的消费级笔记本电脑上进行的。这种设置在现实中更接近实际部署环境，而不是专用服务器。

**评估标准**：我们使用三个标准化标准来衡量性能：内存消耗、加载时间和查询时间。
- **内存消耗**：BiTRDFLib首先将数据加载到内存中以构建和存储BiTRDF知识存储。内存消耗反映了处理和存储BiTRDF知识存储的空间效率。内存消耗是使用psutil测量的，这是一个跨平台的库，用于检索有关运行进程和系统利用率的信息。该测量比较了函数执行前后的总内存使用情况。它还可以指示RAM是否足够处理需求：当发生RAM和物理存储之间的交换时，我们可以观察到较小甚至负的内存消耗。
- **加载时间**：在比较不同实现时，加载时间是整体性能的一部分。因为所有数据必须在查询任务开始之前加载到内存中，所以加载所需时间直接影响系统的效率。
- **查询时间**：实际上，搜索时间对实现性能至关重要，因为许多用户频繁执行搜索。对于满意的用户体验而言，长时间的响应是不可接受的。了解每种替代方案在这个标准下的表现非常重要。比较交换发生前后的性能也很重要，因为它直接关联到可扩展性。我们使用了一个简单的查询来找到所有主体资源匹配的三元组，以进行评估。加载和搜索所用的时间是使用cProfile测量的，cProfile是Python内置的模块，提供了程序执行的统计信息。为了获得更准确的结果，我们计算了每种替代方案在100次运行中的这些定量值的平均值。除了这三个定量值的总值外，我们还计算了它们每百万三元组的值，因为这些值有助于评估可扩展性。

**结果和讨论**：本节从三个角度呈现并分析了实验结果：内存消耗、加载时间和查询时间。目的是了解随着BiTRDF知识存储规模的增加，不同实现方案的行为如何变化，以及识别可扩展性和性能之间的权衡。

**表A14**总结了所有六个数据集中所有六种实现方案的内存消耗情况。对于较小的知识存储（D1和D2），所有替代方案的内存使用情况相当。在这个规模上，内存消耗主要受实现开销的影响，而不是数据集大小。基于PostgreSQL的替代方案由于需要初始化单独的数据库进程和内部缓冲区而消耗更多内存。当数据集达到D3时，PostgreSQL开始将数据卸载到磁盘上，导致观察到的内存使用量暂时减少。这种行为反映了内部数据库内存管理，而不是空间效率的提高。对于较大的数据集（D4-D6），所有替代方案都超过了可用的RAM，并在一定程度上依赖于磁盘交换。

在基于OOP的替代方案中，尽管对象创建和元数据引入了非微不足道的开销，但在交换发生后的内存使用保持相对稳定。相比之下，面向数据库的字典和列表替代方案在更大的规模下显示出更高的内存增长，因为所有原子值都是显式存储的，没有对象重用。图1显示了绝对内存使用量和每百万三元组的趋势。总体而言，一旦数据集规模超过物理内存，内存消耗主要由数据表示选择和系统级别的内存管理驱动。

**表A15**报告了加载每个知识存储所需时间的详细信息。如预期，所有替代方案的加载时间都随着数据集规模的增加而增加。对于小型和中型数据集（D1-D3），差异不大，所有实现都在合理的时间内完成加载。一旦数据集超过可用内存（D4-D6），性能差距变得明显。基于OOP的替代方案由于每个三元组都必须被解析、实例化为对象并通过内部结构连接而产生了更高的加载成本。在这些替代方案中，基于列表的实现由于其更简单的存储模型而表现最佳。

面向数据库的替代方案通过直接存储原子值来更高效地加载数据。基于字典的数据库方法始终实现最快的加载时间，其次是基于列表的变体。PostgreSQL表现出稳定的行为，但由于数据库通信和事务处理引入了开销。这些趋势在图2中得到了清晰说明，特别是在每百万三元组的比较中。总体而言，面向数据库的存储更适合大规模数据摄入，而基于OOP的实现则更注重语义清晰度而非加载效率。

**表A16**总结了查询时间结果的详细信息。对于小型数据集（D1和D2），所有替代方案都提供了快速的查询响应时间。随着数据集规模的增加，性能差异变得更加明显。从D3开始，基于OOP + 字典的替代方案的查询时间显著增加，主要是由于嵌套字典遍历和内存交换效应。其他替代方案则更平稳地扩展。基于列表的OOP方法尽管进行线性扫描，但仍保持可接受的性能，受益于最小的结构开销。面向数据库的替代方案表现一致，PostgreSQL得益于内部查询优化和高效的磁盘访问。

**图3**确认了面向数据库的实现即使在内存压力下也提供了更可预测的查询性能。

**结论**：本文首次系统研究了BiTemporal RDF模型的实际实现方法。通过对六种实现方案的全面实验评估，我们考察了不同的设计选择如何影响内存消耗、加载时间和查询性能。结果表明，对于小规模知识存储，所有替代方案的表现相似。当有足够的RAM可用时（最多约一百万个三元组），所有实现的加载时间保持在30秒以下，查询时间保持在0.5秒以下。在这个规模上，实现的选择对整体系统性能的影响很小，允许开发者优先考虑设计的清晰度和可扩展性。一旦知识存储超过可用内存，性能差异就变得明显。对于包含超过两百万条三元组的数据集，基于数据库的实现方式在数据加载和查询方面始终优于基于对象的实现方式。在测试的最大规模（1600万条三元组）下，基于对象编程（OOP）与字典组合的方式需要2849秒来加载数据，而基于数据库与字典组合的方式仅用91.9秒就完成了加载。在查询性能上也观察到了类似的差距：OOP与字典组合的方式需要67秒，而基于PostgreSQL的实现方式仅需15.25秒。这些结果表明，存储策略对系统的可扩展性至关重要。

除了定量性能之外，各种实现方式之间的架构权衡也非常重要。虽然基于数据库的设计更注重检索效率，但基于对象的实现方式与BiTRDF概念模型更加契合，并提供了强大的灵活性和可扩展性。这些方法允许开发者轻松修改双时态资源定义、引入新的维度，或调整解析和序列化逻辑。对于那些处理中等规模知识库的应用程序，或者强调快速开发和实验的应用程序来说，这些方法提供了实用且易于维护的解决方案。

与SPARQL及其扩展（如C-SPARQL）不同，后者主要通过过滤或流处理在查询层面处理时间相关问题，我们的实现方式注重将双时态语义直接嵌入到数据模型和存储层面。这种资源级别的方法避免了对实体化或辅助结构的依赖，从而减少了结构上的开销并提高了效率。因此，所提出的实现方案为支持现有或未来的时态SPARQL扩展提供了实用的存储和索引基础。

本文的主要贡献总结如下：
- 首次系统地研究了BiTemporal RDF模型的实际实现策略。
- 设计并实现了六种使用Python和PostgreSQL存储和管理BiTRDF知识库的替代方法。
- 基于内存消耗、数据加载时间和多个数据集规模的查询性能，对这些方法进行了实证评估。
- 分析了每种方法的优点和局限性，并为在不同系统需求下选择合适的实现策略提供了实用指导。

尽管本研究并未提供一个完全具备生产环境的BiTRDF系统，但它展示了BiTRDF模型的可行性，并强调了其实现过程中的关键设计考虑因素。未来工作还有几个方向有待探索，包括支持更新和删除操作、在BiTRDF与标准RDF之间进行转换、与基于SPARQL的查询进行集成，以及开发时态推理机制。这些扩展将进一步推动双时态语义在基于RDF的知识系统中的应用。