命名图和联合 SPARQL 端点答案

【问题标题】：Named Graphs and Federated SPARQL Endpoints命名图和联合 SPARQL 端点
【发布时间】：2011-02-18 14:15:48
【问题描述】：

我最近遇到了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 子句中的第二个命名图，并且针对 GRAPH 子句对 WHERE 子句进行了相应修改（例如，如果使用了 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's 和 LIMIT's 周围可能还有一些其他注意事项

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

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

我问的原因是我想在上面的例子中开始跨域推广联盟，而不必等待标准，确保我不会做一些不合时宜或不兼容的事情其他的在未来。

【问题讨论】：

命名图和联合查询是相当正交的功能。将命名图视为（局部）三元组的特定子集。对于远程端点的查询，使用SERVICE 关键字。 AFAIK，Jena Assembler 允许将命名图映射到本地文件，并且可能其他三元组允许将命名图映射到远程三元组，但这些解决方案是特定于供应商的。至于默认图表的默认名称，this specification 目前不包含此类内容。
您所说的功能似乎是特定于 Virtuoso 的，请参阅 e。 G。 stackoverflow.com/questions/22409110/…

标签： sparql semantic-web named-graphs federated-queries

【解决方案1】：

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

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

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

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

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

【讨论】：