sparql - 命名图和联合 SPARQL 端点

Question

我最近遇到了 SPARQL 1.1 Federation Extensions 的工作草案并想知道这是否已经可以使用命名图(不减损上述草案的有用性)。

我对命名图的理解有点模糊，除了我从阅读规范中得到的唯一一件事包括关于合并的规则，在查询时与其他图相关的非合并。由于这不能完全满足我的理解，我的问题如下:

给定以下查询:

SELECT ?something
FROM NAMED <http://www.vw.co.uk/models/used>
FROM NAMED <http://www.autotrader.co.uk/cars/used>
WHERE {
    ...
}

假设查询处理器/端点可以或应该在命名图的上下文中执行以下操作是否合理:

检查命名图是否在本地存在

如果没有，则执行以下操作(在上述查询的情况下，我将使用第二个命名图)

GET/sparql/?query=EncodedQuery HTTP/1.1
主持人:www.autotrader.co.uk
用户代理:my-sparql-client/0.1

其中 EncodedQuery 仅包含 FROM NAMED 中的第二个命名图子句和 WHERE对 GRAPH 的条款进行了相应修改子句(例如，如果使用 GRAPH <http://www.vw.co.uk/models/used> {...})。

只有当它不能执行上述 ，然后执行以下任一操作:

GET /cars/used HTTP/1.1
Host: www.autotrader.co.uk

或者

LOAD <http://www.autotrader.co.uk/cars/used>

返回适当的搜索结果。

显然，OFFSET 周围可能还有一些额外的考虑因素。的和 LIMIT的

我还记得很久以前在遥远的星系的某个地方读到，任何 SPARQL 端点的默认图都应该是根据以下约定的命名图:

对于:http://www.vw.co.uk/sparql/应该有一个命名图:http://www.vw.co.uk表示默认图，因此按照上述逻辑，应该已经可以使用命名图来联合 SPARQL 端点。

我问的原因是我想在上面的例子中开始促进跨域的联合，而不必等待标准，确保我不会做一些不合时宜或与其他东西不兼容的事情 future 。

Answer 1

联合查询(使用 SERVICE 或 FROM)中使用的命名图和 URL 是两个不同的东西。后者指向 SPARQL 端点，命名图位于三重存储中，主要功能是分离不同的数据集。这反过来又有助于提高性能和表示知识，例如表示一组语句的来源。

例如，您可能有两个数据源都声明 ?movie has-rating ?x您可能想知道哪个来源在说明哪个评级，在这种情况下，您可以使用与两个来源相关联的两个命名图(例如，http://www.example.com/rotten-tomatoes 和 http://www.example.com/imdb)。如果您将两个数据集存储在同一个三重存储中，您可能会想要使用 NG，而远程端点是另一回事。此外，命名图的 URL 可以与 VoID 等词汇一起使用。将数据集描述为一个整体(例如，数据集名称、三元组的导入位置和时间、维护者是谁、用户许可)。这是将三重存储划分为 NG 的另一个原因。

也就是说，您将 NG 绑定(bind)到端点 URL 的机制可能会作为一个选项来实现，但我认为将其强制执行并不是一个好主意，因为分别管理远程端点 URL 和 NG 可能更有用。

此外，联合查询的真正挑战是提供端点透明的查询，使查询引擎足够智能以分析查询并了解如何拆分它并在正确的端点上执行部分查询(然后以高效的方式连接结果)方式)。对此进行了大量研究，最重要的结果之一(据我所知)是FedX ，已用于实现多个查询分布优化 (example)。

最后要补充的是，我依稀记得你提到的关于 $url、$url/sparql 的约定。有几种方法(例如 LOD cloud )。也就是说，在当今大多数三重存储(例如，Virtuoso)中，未指定命名图(不使用 GRAPH)的查询的工作方式与陷入默认图情况不同，它们实际上查询所有的并集存储中的命名图，这通常更有用(当您不知道某事在哪里陈述时，或者您想要集成跨图数据时)。