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