Architecture 适当解耦OWL/RDF知识和（主要是数字）事实的体系结构

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

例如，我一直在考虑一种混合体系结构，其中事实将存储在一个单独的SQL数据库中（即，使用纯关系模型，而不是关系模型上的RDF），并将查询分解为两个阶段：第二阶段（SQL）从第一阶段（本体）检索的概念中派生（或引导）

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

---

（我已经在上问过这个问题了，但没有用。）

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

此外，许多选项针对特定的用例集和规模进行了优化，因此如果您对第一个选项的性能不满意，您可以尝试多个选项。另外，不要在这里使用您自己的，您不会创建性能甚至比最差的RDF数据库还要好的东西。您还可能从使用本机RDF存储的数据库中获得更好的性能，而不是由关系数据库支持的数据库，至少在我的经验中是这样的

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

SPARQL将为您提供一种非常类似SQL的强大查询语言，其中包括聚合（在SPARQL 1.1中）。它可能不具备应用程序所需的所有功能，您可能需要构建一些自定义处理代码，但它应该为您提供一个良好的支撑。RDF数据库针对处理SPARQL查询进行了优化，因此通常不需要担心性能，但SPARQL在复杂性方面是PSPACE complete，因此您可以编写一个不容易回答的查询

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

---

祝你好运。

我只是想为你的优秀答案提供一个替代方案

关于他的基于RDF的解决方案：

从度量中分析可能是用R来完成的，所以如果你需要一个完整的RDF/SPARQL解决方案，你也可以考虑。在这里，您将拥有一个集成良好且可维护的解决方案，从数据模型到处理

替代实施方案：

我认为语义web相关技术的选择在很大程度上取决于您对数据的查询类型。你打算对本体论进行任何推理吗？它是一个复杂的知识库吗？您将来是否要将这些数据与其他数据合并？你是否计划有朝一日向公众公布这些数据？如果是，那么用OWL或RDF表示您的数据可能会很有趣，这样您就可以利用该语言的表达能力来制定您单独使用SQL无法完成的事情，并提供一个框架来共享您的信息

---

如果您认为SQL查询足以检索您想要的所有数据，那么我只需将信息存储在关系数据库中：它快速、安全且经过测试。如果包含这些概念的OWL本体只是一个简单的词汇表，那么您可以将这些术语与其他术语一起存储在数据库中。

进入一个关于不同领域的项目，但同样涉及到易于rdf的、基于图形的社会事实和大量信号/数字数据。然而，在我的例子中，这两者是非常耦合的，因此推论需要同时基于社会和数字。你是怎么把一堆数字数据放进去的