为什么 GraphQL 会重写语义网

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

在从社区中的同事那里得到很多关于这个特定断言的砖块之前，我想就我认为语义网目前在哪里以及为什么遇到麻烦提出一些我自己的观察：

太复杂了。我花了几年时间才真正理解 RDF 是如何工作的，部分原因是它假设人们能够理解图范式和逻辑推理模型。如果你有博士学位。在计算语言学中，RDF 并不难理解，但如果你有两年的 JavaScript 或 Python 编程证书，那么 RDF 的图模型很可能是难以理解的。再加上配置三重存储图可能是一场后勤噩梦，并且大多数程序员（更不用说数据分析师）遇到 RDF 急剧下降的可能性。

推断边缘案例。RDF 最强大的方面之一，至少就该技术的支持者而言，是它用于逻辑推理的能力。推理，涉及使用模型本身的各个方面来呈现新信息的能力，可以产生一些非常有效的应用，但前提是模型本身可以像其他信息一样导航，并且只有模型被设计为很容易做出这样的推论。然而，在实践中，由于继承过于复杂或模型未能考虑时间复杂性，许多复杂模型已经失败。此外，使用 SPARQL，对内在推理的需求大幅下降。但是，如果没有这个用例，RDF 的许多好处就会被搁置一旁。

缺乏内在测序。RDF 的工作基于（公认有效的）假设，即图中没有内在顺序。可以通过创建链表来创建外部排序，但由于路径遍历顺序实际上并没有得到一致的尊重，因此不能保证通过 SPARQL 保留它。由于有大量操作实际上排序非常重要，因此这种限制是一个重要的限制，并且在对象数据库（支持数组或序列）日益成为常态的世界中，有许多与分析相关的活动根本无法在当前的知识库上完成。

用例失败。多年来，我参与了许多语义项目。他们中的大多数人充其量只是取得了喜忧参半的成功，还有一些是惨败，后来被其他技术所取代。十年前，自然语言处理似乎是语义网领域的一个亮点，但如果你十年后看这个领域，大部分真正的创新都与机器学习有关，从 BERT 到最新的 GPT -3。图技术在某些地方取得了巨大的进展，但这些领域越来越多地围绕标记的属性图构建，而不是 rdf 图。在某些领域，知识图谱可以产生巨大的影响（例如，合规建模），但是当没有人同意这些模型到底是什么样子时，

格式互操作性差。RDF 是一种抽象语言，但它依赖于各种各样的表示，其中许多都有……问题。RDF-XML 甚至使强化的 XML 用户变得神经质。在必须管理命名空间之前，Turtle 是一种优雅的小语言，但采用它的人相对较少，而且在 JSON 是主要通信模式的环境中表现不佳。JSON-LD 是一个不错的尝试。在大多数情况下，所涉及的问题归结为 JSON 是一种假定分层折叠的对象描述语言，而 RDF 从根本上是规范化的，特别是对于复杂的有向图，在许多情况下，对象之间的边界远未明确。

缺乏一致的摄取。这是一个双重问题。很难将非 RDF 内容提取到 RDF 表单中。部分原因是从一开始就没有真正定义摄取过程，因为当时的假设是您加载了 Turtle（甚至更原始的表示），然后对现有的断言体进行推理。一旦你超越了静态内容的想法，那么事务数据库的所有复杂性也必须针对三重存储来解决。请注意，已经有许多好的解决方案，但没有出现真正的统一性。

图形数据库是强大的工具，尤其是在数据连接性高的世界中，但越来越明显的是，即使对于知识库，也是时候进行重构了。

GraphQL 的承诺
当我意识到另一种查询语言 (XQuery) 和 XML 世界中文档的性质时，我开始使用 RDF。XML 数据库通常是文档的集合，每个文档都有自己的 URL。该 URL（统一资源定位符）也是一个 IRI（国际资源标识符）。对于叙述性文档，每个子文档（例如章节）在基础文档中都是独立的假设通常是有效的，但也有例外（尤其是在教科书出版中）。但是，一旦您开始处理描述其他类型实体的文档，这种假设就会失效，尤其是当多个容器引用同一个子文档时。

虽然 IRI 的概念是 XML 中的一个基本概念，但构建一种语义链接语言需要一段时间，并且有几种不同的尝试朝着不同的方向进行（xlink、rdf、rdfa、xpointer 等）。造成这种混淆的部分原因是大多数人甚至现在都没有区分指向通信网络（互联网或其某些子部分）中节点的链接指针和指向知识中节点的链接指针。 （或概念）网络。这也不应该那么令人惊讶——这不是数据库理论中通常出现的区别，因为大多数数据库在引用（也称为键或指针）方面是内部一致的，并且概念链接的想法在 SQL 数据库中没有意义，因为一个后果。

此外，如果您习惯于使用文档对象序列化，例如 JSON，那么必须创建复杂查询来获取给定类型的特定对象的想法似乎需要做很多工作，尤其是当结果归一化时（例如，在离散的、已识别的块中）而不是在分层文档中——尤其是当您已经可以从 JSON 数据库（如 Couchbase 或 ArrangoDB）中获取相同的内容时。

事实上，在大多数情况下，开发人员想要的是一种获取文档特定部分的方法，根据需要对该文档应用转换，而不必担心将一组组件拼接在一起。同样，他们希望能够以可以检查其有效性的方式发布内容。他们可以使用 XQuery 来做到这一点，但 XML 在符号上被视为过于重量级（一个价值相对较小的论点），而 JSON 在句法上符合他们最熟悉的范式。

这是 GraphQL 所承诺的，对于相当广泛的用例，这也是程序员和数据科学家都想要的。

重要的是 GraphQL 设法完成了 Sparql 和 RDF 堆栈承诺但从未完全交付的大部分内容。具体来说，

便于使用。GraphQL 需要客户端和服务器来构建查询，但是该客户端使示意图发现相对简单，
数据存储不可知。GraphQL 可以在关系数据库、三元存储、Excel 文档或数据服务上工作，用于摄取和查询。
可变形。通过查询和变异语言对数据集执行转换的能力有限。
可变的。用于更新服务器上内容的突变可以通过与系统无关的突变查询来完成。
示意图。虽然不如 RDF 强大，但 GraphQL 使用 TypeScript 或 JSON Schema 来指定示意图关系，并且可以在进入之前进行验证。
以 JSON 为中心。十年前，关于 XML 或 JSON 是否会占主导地位仍然存在一些问题。今天，没有真正的问题——对于非叙述性内容，JSON 几乎胜出，而 XML（不足为奇）仍然受到叙述性内容的青睐，即使不是那么重要。
联合的。可以（通过扩展）使 GraphQL 查询联合起来。SPARQL 在这方面仍然具有优势，但即使在 RDF 领域，联邦也仍未得到广泛应用。
换句话说，GraphQL 提供了一个抽象层，在大多数情况下已经足够好，在其他情况下（例如排序）比 SPARQL 提供的更可取。

GraphQL 和知识图谱
这并不一定意味着 GraphQL 将消除对知识图或 RDF 的需求，但它确实改变了 Sparql、Cypher 或类似方言等语言所扮演的角色。这确实发挥重要作用的一个方面是创建 GraphQL 模式。关系数据库模式通常由约定固定，而 XML 和 JSON 模式在它们确实存在时，主要是作为基于遵守规则启动操作的一种手段。当 Typescript 涉及约束建模时，对于该角色来说根本不够健壮，并且考虑到不同数据系统中涉及的可变性，这个特定功能很可能仍然是数据存储的权限。

同样，推理涉及通过推理引擎或 SPARQL 脚本（或两者）构建三元组。使用 Triple Stores 的主要问题之一是查询涉及的安全方面。如果当底层数据模型发生变化时，使用 SPARQL 脚本从 RDF 模式构造 TypeScript 文档，那么这实际上提供了一层保护。RDF 为内部状态建模，GraphQL 为该状态的外部表示建模。

这也可以帮助处理突变，提供一个代理层，可以在知识图的状态的内部和外部表示之间进行映射。SPARQL Update 是一个强大的工具，但由于该工具非常强大，因此许多数据库管理员不愿意将其授予外部用户。这还允许以一致且受控的方式插入额外的元数据和/或在 JSON 内容和 RDF 之间创建映射，包括生成一致的时间戳和 IRI。

此外，越来越多的知识图谱上的 GraphQL 实现使用 JSON-LD 上下文对象。这提供了一种维护 IRI 的方法，而不会显着影响 GraphQL 生成的 JSON 的实用性。这种方法还解决了 JSON-LD 的一个令人讨厌的方面，因为 GraphQL 生成的 JSON 结构可以被非规范化，从而减少了带外这样做的需要。

语义 GraphQL 的未来
尽管如此，GraphQL 可能会在未来几年将涉及 RDF 的引擎推向 JSON/混合存储。三重存储通常是围绕 n 元组索引构建的，尽管附加索引编码为 JSON 检索优化的中间结构。这些所谓的混合数据库也可以将服务层呈现为看起来像关系数据存储，尽管有一些潜在的损失。

这也指向了未来联合查询变得不太可能而不是更多的可能性，这应该不足为奇。联邦有很多与之相关的问题，从语义问题（对特定本体进行标准化的挑战）到性能问题（连接延迟），再到安全性和可访问性。然而，使用 GraphQL，开发翻译层的成本变得相当低，并且责任不在数据提供者身上，而是在数据消费者身上。事实上，我可以看到通用本体到本体查询的售后市场，这可以很好地缓解关联数据中涉及的更大难题之一。

GraphQL 也可能最终成为语义和标记属性图 (LPG) 操作之间的桥梁。虽然可以在 RDF 图中进行最短路径计算，但这并不是利用这种图的最有效方式（事实上，最短路径计算，从交通应用程序到基因测序的所有应用中，本质上都是 LPG 擅长的地方。另一方面, LPG 充其量对推理无动于衷。然而 GraphQL 可以很容易地从属性图中加载 LPG，可以执行多种优化，然后可以通过已知接口返回结果。

最后，关于真正的推理作为逻辑形式的计算系统，我们可能走在正确的轨道上，但我怀疑推理需要你有上下文，使用模糊逻辑的能力，以及那种贝叶斯分析似乎是机器学习的标志。换句话说，今天的语义系统可能充其量只是非常原始的近似它们将在十年或两年内的位置。事实上，这是数学家库尔特·哥德尔在近一个世纪前证明的。我们从中吸取教训，在此基础上继续前进。

相关帖子DA内容精选 2022年300个以上最佳免费数据科学课 大厂数据分析面试指南！来自亚马逊、谷歌、微软、头条、美团的面试问题！ 机器学习模型方法总结 历史最全机器学习/深度学习/人工智能专业术语表中英对照表 机器学习如何应用于商业场景？三个真实的商业项目 数据工作者的自我修养 | 哪些技能是必不可少的？ 《汗牛充栋：数据分析书籍分享》CDA网校新课上线 文本挖掘常用的107个语料库 一图读懂“东数西算”工程 零基础转行数据分析，看这篇文章就够了

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏1 回帖

关键词：GRAPH GRAP RAP APH 语义网