我正在开展一项主要涉及公共卫生指标的申请。相关概念和知识保存在OWL本体中。最终还会有一个（可能很重要的）数字事实（例如，X的指标具有值Y），随着更多数据被碾压并添加到应用程序中，它将随着时间的推移而增长。鉴于查询这个系统将意味着操纵概念（来自本体），还有（数字）事实，我想知道（广义上）什么是理想的数据模型/存储架构。
我一直在考虑一种混合架构，其中事实将存储在单独的SQL数据库中（即使用纯关系模型，而不是RDF-关系模型），并且查询将被分解分为两个阶段：第二个（SQL）从第一个（本体）检索到的概念派生（或引导）。
然而，当我读到强大的三重存储能够处理大量数据（十亿+三倍）时，它表明我还可以尝试将我的事实保存在RDF存储中（可能使用关系数据库实现）。这将带来我想要提供更统一的查询接口的好处（因为我可以使用相同的API或查询引擎在模式和事实存储中同时查询，而不是像我的混合方法那样在过程中混合SQL）。另一方面，我想我也会丢失关系数据库的数据处理功能（假设三重存储没有针对聚合，缩减等操作进行优化），这在我的上下文中可能很有用。 作为最后一条信息，我已经投入了一些精力开始学习Jena框架，所以如果这些建议能够考虑到它，我会很感激。
（我已在answers.semanticweb.com上问过这个问题，但没有用。）
答案 0 :(得分：4)
看起来您的应用程序的纯RDF解决方案可行。如您所知，RDF数据库正在快速成熟，并且有许多高质量的开源和商业选项可用。大多数扩展到数十亿或数百亿的三元组，并支持核心semweb标准。
此外，许多选项针对特定的一组用例和比例进行了优化，因此如果您对第一个选项的性能不满意，可以尝试多个选项。另外，不要在这里推销自己的东西，你不会把一些比最差的RDF数据库表现更好的东西拼凑在一起。您也可能从使用本机RDF存储的数据库中获得更好的性能，而不是由关系数据库支持的数据，至少在我的经验中，这是真的。
至于Jena，它是一个合理的使用框架，我个人更喜欢Sesame，但两者都非常适合使用。但是，与在Jena（或Sesame）上进行标准化相比，您最好不要在SPARQL上标准化应用程序的RDF部分，无论是部分还是全部。这样做的好处是数据库和编程语言无关。 SPARQL协议基于HTTP，因此您可以使用几乎任何语言并且能够与数据库通信，并且因为您使用的是SPARQL而不是自定义协议，所以您可以根据需求的变化更轻松地更改数据库。如果您希望在组织内部或网络上公开数据，也可以让其他人轻松利用您的数据。
SPARQL将为您提供一种非常类似SQL的强大查询语言，其中包括聚合（在SPARQL 1.1中）。它可能没有您应用程序所需的所有内容，您可能必须构建一些自定义处理代码，但它应该为您提供良好的支持。 RDF数据库针对处理SPARQL查询进行了优化，因此无需担心性能，但SPARQL在复杂性方面完全是PSPACE，因此您可以编写无法轻松应答的查询。
最后，虽然混合架构可行，但我担心的是长期会造成不必要的维护负担。如果您对semtech感到好奇，并认为它至少适合您的部分应用程序，那么您可以先尝试使用pure-semtech解决方案，看看您能获得多少。
祝你好运。答案 1 :(得分：1)
仅提供Michael的优秀答案的替代方案。
关于他的基于RDF的解决方案：
指标的分析可能是用R完成的，所以如果你想要一个完整的RDF / SPARQL解决方案，你也可以考虑R package for SPARQL。您可以在这里找到一个集成且可维护的解决方案，从数据模型直接到处理。
替代实施：
我认为语义网相关技术的选择在很大程度上取决于您对数据提出的查询类型。你是否会对本体论使用任何推理？这是一个复杂的知识库吗？您是否打算将这些数据与其他数据结合起来？您是否计划有一天为公众发布数据？如果是，那么在OWL或RDF中表示您的数据可能会很有趣，因此您可以利用该语言的表达能力来制定您无法单独使用SQL的内容，并提供一个共享信息的支架。 / p>
如果您认为SQL查询足以检索所需的所有数据，那么我只需将信息存储在关系数据库中：它快速，安全且经过测试。如果包含概念的OWL本体只是一个简单的词汇表，那么您可以将这些术语与其他术语一起存储在数据库中。