2

I am working on an application dealing mainly with public health indicators. The related concepts and knowledge are kept in an OWL ontology. There will also be eventually a (potentially important) number of numerical facts (e.g. indicator for X has value Y), which will grow over time, as more data gets crunched and added to the application. Given that querying this system will imply manipulating concepts (from the ontology), but also (numerical) facts, I am wondering what could be (in broad terms) an ideal data model/storage architecture for it.

I've been contemplating for instance an hybrid architecture where the facts would be stored in a separate SQL database (i.e. using a pure relational model, not a RDF-over-relational one), and for which the querying would be decomposed in two phases: the second (SQL) being derived (or guided) from concepts retrieved from the first (ontology).

As I read however about robust triple stores being able to handle massive amounts of data (billion+ triples), it suggests that I could also try to keep my facts in an RDF store (perhaps implemented with a relational DB). This would have the benefit I suppose of offering a more unified query interface (as I could query simultaneously in the the schema and fact stores using a same API or query engine, instead of mixing SQL in the process as with my hybrid approach). On the other hand, I guess I'd also lose the data crunching capabilities of a relational DB (assuming a triple store is not optimized for operations like aggregation, reduction, etc.) which might be useful in my context. As a final piece of information, I have already invested some energy in beginning to learn the Jena framework, so I'd appreciate if the suggestions could take it into account.

(I already asked this question on answers.semanticweb.com, to no avail.)

4

2 回答 2

4

您的应用程序的纯 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 解决方案，看看您能走多远。

祝你好运。

于 2013-04-18T17:40:42.140 回答
1

只是为了提供迈克尔出色答案的替代方案。

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

指标分析可能会使用 R 完成，因此如果您选择完整的 RDF/SPARQL 解决方案，您还可以考虑SPARQL 的 R 包。您将在这里拥有一个集成良好且可维护的解决方案，从数据模型直接到处理。

替代实现：

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

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

于 2013-04-18T22:24:02.333 回答