很显然SPARQL和其他RDF相关的技术在重叠的大数据和NoSQL的世界中会大有用武之地，但是对专注于该领域的人来说这好像还不够明显，例如本周的Strata会议基本上对RDF或SPARQL无所顾及。我看的越深入，我就觉得这个灵活的、标准化的数据模型和查询语言已经可以在上述人群努力去处理的各类问题中已经表现得相当不错。
一旦数据被采集，它就必须被提取On。传统的BI的说法是抽取、转换刚和装载（Extract,Transform,and Load，ETL）：即把合适的信息放在对应的数据库脚本的表格中，并对特定的域进行操作处理使得他们容易处理。
大数据的一个显著特征是，这些数据往往是非结构化的。也就是说在我们开始分析他们之前， 我们是不清楚其内在信息结构的。我们当然可以进行某些转换——例如把IP地址变成城市的名称，或者使用单向的来隐藏特定的字段——但是我们还是要紧紧抓住原始数据并且在我们分析的时候来定义其结构。
对于一个具有很长时间XML背景的人来说，我知道关于"structured" vs. "unstructured"数据的说法是一个 data 具有非常相对性意义的概念——对一个人来说的结构化数据可能对另一个人来说是非结构化的，尤其前者是个XML领域的二后者是关系数据库领域的——这就是术语"semi-structured" 做为一个协调性形容词的出现缘由。我将打造一个新的术语，以期和Google hits没什么相关 "minimally structured"——如果我们手上有一个虽小但是足够用结构来作为起点并开始工作的话，那么你的数据就是最小化结构的。并且RDFS做为"边分析定义结构边分析"是非常棒的，这可以一步步来，并且OWL可以进一步往深走。
有一些最小化的结构可以被演绎并且使其显性化：
即使没有大量的数据类型不匹配，关系数据库的一大弱点是其脚本（schema）的静态特征。在一个快速扩张的环境下，计算的结果将会随着对信号不断侦测和抽取的过程而进化。Semi-structured数据库符合这样的灵活性要求：它们提供了足够的结构来组织数据，但在数据存储之前不要求一个具体的规范。
这对于三元组来说也是一样的，后者提供了两个世界最好的东西：不要数据脚本，你可以不断地累积数据，并且使用一个标准的查询语言来检索；如果你愿意，你还可以逐渐地增加脚本元数据（schema metadata）——通常基于查询结果 (often based on query results)来协助更进一步的查询。
NoSQL数据库通常被称为“非脚本化（schemaless）” ，因为他们不许要具备和关系数据库相关联的正规脚本。后者——通常在软件正式编写以前就要定义好——其缺失意味着非脚本化数据库将会较好地适应目前的软件开发实践如敏捷开发。从一个简单的可以工作小项目开始，不断快速迭代来响应用户输入的方式并不能与项目一开始就把所有的数据脚本设计定义的方式好很好协调。我们也无法预测数据将被怎样使用，以及随着项目的开展会有什么样的数据进一步要添加。
这里又一次对基于RDF的技术来说是十分容易处理的情况。在"开发之前就拼装大脚本"和"尽管扔掉那些减弱灵活性的脚本"的选择之外，你还可以在项目进行中需要的时候，和中间层一点加入的脚本元数据进行一道工作。
从我听到的各类型的NoSQL数据库产品，面向图的Neo4J好像是最接近三元组存储（triplestores），该产品也是对图进行存储graphs。 下面这个关于另一类NoSQL数据库种类的描述真正引起了我的注意，尽管：
Cassandra和HBase都被称为是面向列的数据库,更为恰当的名称其实应当是“稀疏行存储（sparse row store）。在这些数据库中，和关系型“表”相对等的是一个行的集合，使用一个键值来标识。每行含有一个无限制数目的列；这些列实际上是一些必要的键值用来查询该行中的各种值。列可以在任何时间加入，并且对某一给定的行来说没有使用到的列将不占据任何存储空间。不存在NULL。
这个就是 "和关系型“表”相对等"?这听起来更像是等同于被某一主题所归类的一组三元组。属性（谓语）实际上就是那些必须的供你查询的和这些主题相关的值的键值；你可以在任何时候为某个主题添加“属性名称/值”，由于它们并不依赖于某种固定的脚本，并且未被使用的属性将不占据任何存储（也就没有NULL）。
我乐意见到的，而且已经听说了一些实质性的尝试,是这些NoSQL数据库系统的SPARQL端（ endpoints）。D2RQ和R2RML
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。