我最近遇到了 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>
    
  • 返回适当的搜索结果。

  • 显然,围绕 OFFSETLIMIT 可能还有一些额外的考虑

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

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

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

    最佳答案

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

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

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

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

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

    关于sparql - 命名图和联合 SPARQL 端点,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/5042331/

    10-11 20:07