Sparql变量在块内部未绑定的块之外

Question

在针对Sesame内存存储的Sparql查询中,我想将查询条件分开,例如"Patient is male"与我生成查询结果的查询的其余部分.

让我们考虑一下这个简单的查询:

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX nci:<http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#>
PREFIX roo: <http://www.cancerdata.org/roo/>

SELECT DISTINCT *
WHERE { 
  ?Patient a nci:C16960 . 
  ?Patient roo:100018 ?gender .
  ?gender a nci:C20197 .
  BIND(bound(?Patient) as ?bound0) .
  { 
    BIND(bound(?Patient) as ?bound1) .
  } 
  UNION { 
    ?Patient a nci:C16960 . 
    BIND(bound(?Patient) as ?bound2) .
  } 
} 

Bound0始终为true(如预期的那样).Bound1始终为false,并且Bound2在结果集中根本没有值(有和没有额外的？Patient triple).

这是否意味着？Patient变量在第一个块中是已知的,但没有绑定,并且它在第二个块中根本不存在(即使我再次声明它)？为什么会有区别？

我的目标是首先定义复杂的查询条件,并将结果集减少到只匹配所有条件的患者.然后使用已经减少的？患者来收集输出中请求的所有数据.

在此先感谢您的帮助!

编辑

为了进一步说明我的意图,这是一个更复杂的查询.我可以用OPTIONAL而不是UNION编写相同的查询.但是当我使用OPTIONAL时,结果集中的行数会保持快速增长,每个OPTIONAL块返回的命中次数也会增加.如果两个块都返回多个匹配,则结果包含hits1*hits2记录.我认为我可以通过在高级别使用UNION使其更可预测并将其保持在hits1 + hits2中.是否有显着的性能差异？

SELECT DISTINCT ?Patient ?Gender ?Neoplastic_Process ?MStage ?TStage
WHERE { 
 ?Patient a nci:C16960 . 
     { 
     ?Patient roo:100018 ?Gender . 
     ?Gender a ?GenderType . 
    } 
    UNION { -- SHOULD I USE OPTIONAL HERE INSTEAD (And for the block above?)
     ?Patient roo:100008 ?Neoplastic_Process . 
     ?Neoplastic_Process a ?Neoplastic_ProcessType . 
        OPTIONAL { 
         ?Neoplastic_Process roo:100241 ?MStage . 
         ?MStage a ?MStageType . 
        } 
        OPTIONAL { 
         ?Neoplastic_Process roo:100244 ?TStage . 
         ?TStage a ?TStageType . 
        } 
    } 
}

我想当我使用OPTIONAL添加到结果集而不是UNION时,我的分离查询条件的问题不起作用,因为它是同一个块的所有部分.

Answer 1

SPARQL执行被定义为功能性的,即.自下而上.在以同样的方式(1+2) * 3意味着计算1+2,那么就*或double(1+2)方法计算1+2并通过3,不1+2给double.

{ 
    BIND(bound(?Patient) as ?bound1) .
}

计算然后与(与一个连接)组合

?Patient a nci:C16960 . 
?Patient roo:100018 ?gender .
?gender a nci:C20197 .

所以

{ 
    BIND(bound(?Patient) as ?bound1) .
}

没有约束力 ?Patient

引擎会以不同的方式分析查询并在内部执行,但前提是它得到相同的结果.

在a的不同部分重复较小的图案可能更容易UNION.对于较大的模式,避免重复考虑子SELECT或OPTIONAL来扩展结果.(问题中的示例看似简化,因此很难说出最好的方法.)