sparql - 为什么 Jean 和 Sesame/OpenRDF 的 SPARQL 处理器对除法运算的解释会发生变化？

Question

以下 SPARQL 查询在两个流行 SDK( Jena 和 Sesame / OpenRDF )的 SPARQL 引擎上运行时会产生不同的结果:

PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>

SELECT  ?v1 ?v2 ?v3 ?v4 ?v5 ?v6
WHERE
{
    BIND (            1    / 3             as ?v1)
    BIND (  xsd:float(1    / 3)            as ?v2)
    BIND (  xsd:float(1)   / 3             as ?v3)
    BIND ( (          1.0  / 3)            as ?v4)
    BIND (  xsd:float(1.0  / 3)            as ?v5)
    BIND (  xsd:float(1.0) / 3             as ?v6)
}

最新版本 Jena 的结果对我来说很有意义(为了便于阅读而格式化):

v1: 0.333333333333333333333333
v2: "0.333333333333333333333333"^^xsd:float
v3: "0.33333334"^^xsd:float
v4: 0.333333333333333333333333
v5: "0.333333333333333333333333"^^xsd:float
v6: "0.33333334"^^xsd:float

另一方面，最新版本的 Sesame/OpenRDF 返回(为了便于阅读而格式化):

v1: "0"^^<http://www.w3.org/2001/XMLSchema#decimal>
v2: "0.0"^^<http://www.w3.org/2001/XMLSchema#float>
v3: "0.33333334"^^<http://www.w3.org/2001/XMLSchema#float>
v4: "0.3"^^<http://www.w3.org/2001/XMLSchema#decimal>
v5: "0.3"^^<http://www.w3.org/2001/XMLSchema#float>
v6: "0.33333334"^^<http://www.w3.org/2001/XMLSchema#float>

强调一点:Jena 永远不会像 Sesame/OpenRDF 那样返回 0 或 0.0 或 0.3。谁能解释一下为什么数值结果有如此大的差异？如何对同一个 SPARQL 查询获得相同的结果？或者，哪一个是正确的(从某种意义上说，无论数学正确性如何，都可以正确实现 SPARQL 标准)？

Answer 1

这种差异是由 Sesame 的除法运算符实现中采用的不同舍入/缩放策略造成的。

第一个运算符:

1 / 3 as ?v

将两个整数值相除并将结果绑定(bind)到 ?v，这将是一个十进制类型的值。

由于 1/3 是一个具有无限小数扩展的分数，因此我们需要对结果进行四舍五入。然而，由于两个输入变量的小数位数(即小数位数)为零，Sesame 的 MathUtil 也将结果的小数位数设置为零，因此除法的结果 (0.3333...) 被缩放到零位并四舍五入，结果为 0。

您可以在 Sesame 中通过显式向输入值添加比例来解决此问题。例如:

SELECT  ?v1 
WHERE
{
    BIND ( 1.0000 / 3 as ?v1)
}

将导致:

?v1:  "0.3333"^^<http://www.w3.org/2001/XMLSchema#decimal>    

请注意，我们实际上在这里所做的是将您的输入值之一从整数更改为小数。这有点类似于在 Java 中执行 1/3 将得到 0，但您可以通过转换为 double 来解决这个问题。

据我从 XPath 规范(定义了 SPARQL 重用的除法运算符)来看，Jena 和 Sesame 的行为都符合规范，因为数字运算上缩放数字的选择是实现定义的。

当然，这并不是说如果 Sesame 在进行除法时对此类重复分数使用更高的精度，那就不会更实用。作为改进请求记录在 http://www.openrdf.org/issues/browse/SES-1063 ，并且由于这是一件微不足道的事情，因此将在下一个版本中支持这一点。同时，我希望上述内容能为您提供合适的解决方法。