含糊不清的问题:
1:为什么将近 100% 的应用程序开发人员、应用程序开发社区和文献(书籍、教程等)认为您想使用关系数据库或键值存储来表达数据?
2:为什么不是每个人都使用“三重”数据结构?
3:Triples 不是适用于关系数据库和键值存储的所有问题吗?Triples 至少在每种情况下都不是那么容易使用吗?
含糊不清的问题:
1:为什么将近 100% 的应用程序开发人员、应用程序开发社区和文献(书籍、教程等)认为您想使用关系数据库或键值存储来表达数据?
2:为什么不是每个人都使用“三重”数据结构?
3:Triples 不是适用于关系数据库和键值存储的所有问题吗?Triples 至少在每种情况下都不是那么容易使用吗?
三元组可以表示任何其他数据结构。但这并不一定会让它们更容易使用。如果你的问题是表格的,那么表格数据结构会更好。使用图数据结构,您需要考虑如何从三元组组成表格,这是额外的工作。
解决大多数问题(尤其是数据形状可预测的简单问题)不需要图形数据结构的灵活性。
更一般地说,我认为相当多的开发人员很快就会迷失在 RDF、OWL、SKOS、本体、推理引擎等相互纠缠的混乱中。对于那些想:“但我只想要用户的订单历史”(或其他),这一切都只是有点太多了,处理等等。
我以前也问过自己同样的问题。通常人们将复杂性作为问题。这确实是一个坏习惯,因为我们离开问题的时间越长,它就会变得越糟。语义网是一个复杂问题的复杂解决方案。它没有变得更容易。我还认为将简单性与 RDBMS 进行比较是幼稚的。现在大多数开发人员都熟悉 ORM 并使用抽象的持久性,有些人从未意识到持久性机制。语义 Web (ORDFM) 的持久性框架通常没有那么复杂或进化。话虽如此,许多组织正在远离 RDBMS 并投资于 NoSQL 解决方案,其中 RDF 和 SPARQL 在我看来是最佳候选者。
当人们谈论语义网变得复杂时,我总是指出一个很好的案例研究是 Bart van Leeuwen 的故事:
http://semtechbizsf2012.semanticweb.com/sessionPop.cfm?confid=65&proposalid=4590
如果真正的全职消防员(扑灭真正的火灾)可以使用 SPARQL 和 RDF 代替数据库和专有格式来解决真正的问题(紧急服务中的数据可访问性),那么我们其他人就没有理由不去. 我的观点是,不是技术是障碍,而是其他东西。