4

我最近遇到了SPARQL 1.1 联合扩展的工作草案，并想知道这是否已经可以使用命名图（不要减损上述草案的有用性）。

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

给定以下查询：

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

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

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

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

    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> {...}正在使用 a）。

只有当它不能执行上述操作时，才执行以下任一操作：

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

或者

LOAD <http://www.autotrader.co.uk/cars/used>
  1. 返回适当的搜索结果。

OFFSET显然，围绕's 和LIMIT's可能还有一些额外的考虑

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

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

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

4

1 回答 1

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

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

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

于 2017-10-26T17:05:04.333 回答