【问题标题】:Proper usage of VALUES in federated queries在联合查询中正确使用 VALUES
【发布时间】:2018-11-26 14:07:15
【问题描述】:

注意:可能存在 GrapbDB 错误(参见 cmets)

我在 GraphDB 中有这个知识库:

PREFIX : <http://my_awesome_cats_collection#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>


:foo a :cat ;
     :name 'Marble' ;
     owl:sameAs wd:Q27745011 .
# and many other cats

我试过这个联合查询

select * where { 
    # remote service
    SERVICE <https://query.wikidata.org/sparql> {
        ?cat wdt:P463 ?membership
    }

    ?cat :name ?name .
    VALUES ?name {'Marble'}

} 

我从 Wikidata(即 Musashi 的 Marble 成员)得到了预期的结果。

如果我像这样切换模式的顺序:

select * where { 

    ?cat :name ?name .
    VALUES ?name {'Marble'}

    # remote service
    SERVICE <https://query.wikidata.org/sparql> {
        ?cat wdt:P463 ?membership
    }
} 

我得到了很多误报结果(即,属于 Musashi 家的其他猫的数据,而我只想得到 Marble。我猜是本地模式和远程模式之间的一种交叉产品)。

在 SPARQL 1.1 的 official doc 中,他们说:

联合查询可以使用 VALUES 子句来约束结果 基于解决方案绑定从远程端点接收来自 评估查询的其他部分。

(摘录信息丰富。感谢@TallTed 指出这一点)

那么,在联合时,VALUES 是否只能用作最终过滤器?怎么回事?

编辑:

  • 使用 GraphDB 执行查询
  • 这似乎是 GraphDB 查询优化器的一个错误(感谢:Stanislav Kralin)

【问题讨论】:

  • 不知道您的“假阳性结果”,也不知道您本地的 SPARQL 引擎,很难说“发生了什么”。我看到的第一件事是您的两个查询中似乎都有错字——?ca wdt:P463 可能应该是?cat wdt:P463。然后,我注意到您摘录的 SPARQL 1.1 文档部分(“2.4 服务和价值的相互作用(信息性)”)是 信息性,而不是 规范性,它说 MAY 所以这只是可能性的指导。
  • 我用 GraphDB 尝试了这些查询。操作,对不起:我要改正错别字。谢谢,不过这不是问题。我看到摘录只是信息丰富,但它是我在试图找出这种奇怪行为时发现的唯一参考。关于误报,我还获得了属于 Musashi 家的其他猫的数据,而我只想获得 Marble
  • 1.它似乎是 GraphDB 的查询优化器错误。 2.结果似乎也取决于选择的规则集。 3、第一次查询,?cat :name 'Marble'比较快。 4. 2.4 节无关紧要,它是关于如何通过本地获得的解决方案来调度远程查询。
  • 嘿@StanislavKralin,很高兴在这里见到你!嗯不错!我要添加 GraphDB 标签来引诱 Ontotext 的人。我绝对可以使用?cat :name 'Marble',但我不能以这种方式查询更多的猫(这就是我尝试使用VALUES 的原因)。谢谢!
  • 只是一个想法——你可以试试FILTER ( ?name IN ( 'Marble' ) )而不是VALUES ?name {'Marble'}...这在很多情况下会更慢,但如果它不会触发明显的错误,那就是速度不足可能是合理的。

标签: sparql rdf graphdb federated-queries


【解决方案1】:

您发布的示例演示了 SPARQL 规范的一个极端案例,它结合了多个相关主题,并且在我看来非常模棱两可。下面的详细信息解释了 GraphDB 引擎中所采取的假设和设计决策。请注意,这可能与其他实现读取以下规范行的方式不同:

服务和价值观的相互作用

SPARQL Federation 1.1 有一个非规范部分描述了这种情况下的行为:

SPARQL 1.1 联合查询的实施者可以使用 VALUES 子句来限制从远程端点接收到的结果,该结果基于解决方案绑定来评估查询的其他部分。

GraphDB 的查询优化器无法从远程 SPARQL 端点检索任何统计信息,因此它采用天真地将查询抛出到远程 SERVICE 并在本地连接结果的方法。因此,查询优化任务掌握在知道两个存储库中架构的用户手中,通过以程序方式重新排列查询(见下文)。

联合查询是子查询

每个远程查询都被视为子查询并按原样发送到外部端点。这是等效的语法:

# remote service
SERVICE <https://query.wikidata.org/sparql> {
    SELECT ?cat ?membership {
        ?cat wdt:P463 ?membership
    }
    LIMIT <put any limit>
}

先评估子查询,然后自下而上传播所有变量

根据SPARQL specification,不应该从外部推入子查询中的变量绑定:

子查询是一种将 SPARQL 查询嵌入到其他查询中的方法,通常是为了实现其他方式无法实现的结果,例如限制查询中某些子表达式的结果数量。

由于 SPARQL 查询评估的自下而上性质,首先对子查询进行逻辑评估,然后将结果投影到外部查询。

请注意,只有从子查询中投影出来的变量才会对外部查询可见或在范围内。

此时,不再可能使用选择性非常高的本地子句有效地执行查询。这就是为什么 GraphDB 数据库公开了一个特殊的配置参数来打破对 SPARQL 规范的遵守:

./graphdb -Dreuse.vars.in.subselects

在这种情况下,查询引擎将忽略 SPARQL 规范,并将来自外部查询的变量推送到子选择中。启用此参数后您的正确查询版本是:

PREFIX : <http://my_awesome_cats_collection#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>

select * where {
    
    ?cat :name ?name .
    VALUES ?name {
        'Marble'
    }
    
    # remote service
    SERVICE <https://query.wikidata.org/sparql> {
        ?cat wdt:P463 ?membership
    }
}

使用应该如何优化远程端点的查询执行计划

VALUES/BIND 是程序性的,根据 SPARQL 规范,它们的位置很重要

BIND 表单允许从基本图形模式或属性路径表达式将值分配给变量。 BIND 的使用结束了前面的基本图形模式。 BIND 子句引入的变量在 BIND 中使用之前不得在组图模式中使用。

在这种特殊情况下,另一种效率低得多的相同查询形式是首先执行远程端点查询(即从 Wikidata 下载所有结果),然后将它们与本地较小的数据集连接:

PREFIX : <http://my_awesome_cats_collection#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>

select * where {
    
    # remote service
    SERVICE <https://query.wikidata.org/sparql> {
        ?cat wdt:P463 ?membership
    }

    ?cat :name ?name .
    VALUES ?name {
        'Marble'
    }
}

我希望这能让您全面了解 GraphDB 对 SPARQL 规范的解释以及如何优化联合查询的所有可能性。

【讨论】:

  • 然后出现两个问题... 1. 是否应该将联合查询视为先进行逻辑评估的子查询?在这种情况下,第 2.4 节似乎并不认为自下而上的语义违规是有害的。 2. 为什么不执行join?在第一个查询中,即使使用(本地)?cat_local owl:sameAs ?cat_remote 也不会执行。
  • 我稍微调整了我的答案,以更好地解决您的评论
  • 正确的命令行选项是./graphdb -Dreuse.vars.in.subselects=true。正在考虑将值推送到联合查询中的问题 (GDB-3043)。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-08-23
  • 1970-01-01
  • 1970-01-01
  • 2023-03-28
  • 2021-05-05
  • 1970-01-01
相关资源
最近更新 更多