用于 OWL/RDF 知识和(主要是数字的)事实的适当解耦的架构

Question

我正在开发一个主要处理公共(public)卫生指标的应用程序。相关概念和知识保存在 OWL 本体中。随着越来越多的数据被处理并添加到应用程序中，最终还会有一些(可能很重要的)数字事实(例如，X 的指标的值为 Y)，它们会随着时间的推移而增长。鉴于查询该系统将意味着操纵概念(来自本体)，但也意味着操纵(数字)事实，我想知道(从广义上讲)它的理想数据模型/存储架构是什么。

例如，我一直在考虑一种混合架构，其中事实将存储在单独的 SQL 数据库中(即使用纯关系模型，而不是 RDF-over-relational 模型)，并且查询将被分解分为两个阶段:第二个阶段 (SQL) 从第一个阶段(本体)检索到的概念派生(或引导)。

然而，正如我所读到的关于能够处理大量数据(十亿以上的三元组)的健壮的三元组存储，这表明我也可以尝试将我的事实保存在 RDF 存储中(可能使用关系数据库实现)。我认为这将有利于提供更统一的查询接口(interface)(因为我可以使用相同的 API 或查询引擎同时查询模式和事实存储，而不是像我的混合方法那样在过程中混合使用 SQL)。另一方面，我想我也会失去关系数据库的数据处理能力(假设三重存储没有针对聚合、缩减等操作进行优化)，这在我的上下文中可能很有用。作为最后一条信息，我已经投入了一些精力开始学习 Jena 框架，所以如果建议能够考虑到这一点，我将不胜感激。

(我已经在 answers.semanticweb.com 上问过这个问题，但无济于事。)

Answer 1

您的应用程序的纯 RDF 解决方案似乎可行。正如您所注意到的，RDF 数据库正在迅速成熟，并且有许多高质量的开源和商业选项可用。大多数都可以很好地扩展到数十亿或数百亿的三元组，并支持核心 semweb 标准。

此外，许多选项都针对一组特定的用例和规模进行了优化，因此如果您对第一个选项的性能不满意，可以尝试多个选项。另外，不要在这里推出自己的产品，您不会拼凑出比最差的 RDF 数据库性能更好的东西。您还可能从使用 native RDF 存储的数据库中获得更好的性能，而不是使用关系数据库支持的数据库，至少根据我的经验，这是事实。

至于 Jena，它是一个合理的框架，我个人更喜欢 Sesame，但两者都非常好用。但是，与其在 Jena(或 Sesame)上进行标准化，不如在 SPARQL 上对应用程序的 RDF 部分(部分或全部)进行标准化。这样做的好处是与数据库和编程语言无关。 SPARQL 协议(protocol)基于 HTTP，因此您几乎可以使用任何语言并能够与数据库对话，并且因为您使用的是 SPARQL 而不是自定义协议(protocol)，所以您可以随着需求的发展更轻松地更改数据库。如果您希望在您的组织内或在网络上公开您的数据，它还可以让其他人轻松使用您的数据。

SPARQL 将为您提供一种非常类似于 SQL 的强大查询语言，其中包括聚合(在 SPARQL 1.1 中)。它可能不具备您的应用程序所需的一切，您可能必须构建一些自定义处理代码，但它应该为您提供良好的立足点。 RDF 数据库针对处理 SPARQL 查询进行了优化，因此通常无需担心性能，但 SPARQL 在复杂性方面是 PSPACE 完备的，因此您可以编写无法轻松回答的查询。

最后，虽然混合架构可以工作，但我担心的是长期可能会造成不必要的维护负担。如果您对 semtech 感到好奇，并且认为它至少适合您的部分应用，您可以先尝试使用 pure-semtech 解决方案，看看您能走多远。

祝你好运。