RDF三重商店,适合日常节目吗?

时间:2010-03-23 16:54:31

标签: rdf semantics

我非常喜欢这些,并希望将它们用于一切。为什么在日常编程(实体/表格)中使用RDF三重存储,例如联系人,客户,公司等,这是一个坏主意。

我所遇到的技术是否有短暂下降。我担心检索数据,但我认为这是SPARQL所涵盖的。

5 个答案:

答案 0 :(得分:2)

没有一种适合所有人的工具。三重商店今天适用于某些类型的任务,而不适用于其他任务。

在semanticoverflow.com上询问了similar question,并且常见答案是相同的:“使用适当的东西”。

答案 1 :(得分:2)

查询时间往往比传统数据库慢得多,即使是简单查询也是如此。此外,许多RDF存储不支持标准数据库功能,如事务,崩溃恢复,......

答案 2 :(得分:2)

我们在使用RDF三重存储进行一般编程时遇到的一个缺点是大多数引擎不支持查询中的聚合(min,max,group by)。

我们用来在RDBMS之间做出决定的清单如下

RDBMS if

  • 静态架构
  • 非常大量的数据
  • 不需要RDF导出
  • 需要Lucene支持(例如通过Hibernate搜索很容易)
  • 强大的数据一致性要求(涉及金钱等)

RDF if

  • 未修复或动态架构
  • 从小到大的数据
  • 需要RDF导出
  • 松散的数据一致性要求

如果您没有正确的工具,重构正在进行的项目的RDFBMS模式可能会产生很大的开销。

一些RDF引擎也提供Lucene支持,但没有像Hibernate Search那样记录和支持。

RDF引擎的可扩展性也在稳步提升,NoSQL方面的想法被整合到RDF引擎中,但如果你选择Jena和Sesame的标准引擎,这个部门仍然非常有效。

答案 3 :(得分:2)

尚未提及的一个问题是,更新三重存储以反映不断变化的数据通常比RDBMS或OODBMS更多的工作,因为没有“对象”或“行”的概念 - 只有三元组和资源。因此,删除域对象需要小心,否则最终会在triplestore中留下大量垃圾。没有级联删除是一个密切相关的问题。

从好的方面来说,RDF对日常应用程序也很有帮助,因为您可以灵活地在实体之间添加新的子类,关系或子关系,而不必破坏任何代码,并轻松地向资源添加注释,注释等。

答案 4 :(得分:1)

除了Peteris的回答之外,在为三重商店建模数据与其他技术(如OOP,关系数据库,XML等)之间存在一些关键差异。行,类,属性等

这在很大程度上取决于您想要做什么,不管它们是否合适,以及您是否可以找到具有适合您应用的性能特征的产品。

人们倾向于将三重存储描述为无模式数据库,但实际上除非您使用某种形式的模式/本体,否则它们并不是特别有用。如果你想使用SPARQL来获取东西,那么你需要在商店中创建一些可以编写查询的模式模式。

就我个人而言,我仍会使用关系数据库来做很多事情而且仍然会这样做,而我正在使用RDF和三重存储来处理越来越多的东西,这并不意味着我已经准备好抛弃哪些东西了。

作为最后一点,即使您暂时使用关系数据库,也有像DB2RDF这样的技术可以将关系数据库转换为RDF,这样您就可以暂时使用数据库,然后将数据库导出到根据需要将来的RDF