Rdf 奇SPARQL行为

我目前正在研究迭代扩展算法，它将成为一个项目的基础。该算法给出了一个种子URI，在此基础上，它通过逐步扩展，跟踪已访问的节点和未探索区域的边界，在内存中创建一个图。为了创建这个扩展，我创建了两个SPARQL模板，将URI从frontier提供给它们。两个简化表达式为：

CONSTRUCT {?s ?p ?o}
WHERE {
    ?s ?p ?o .
    FILTER(?s IN (<URI_1>, <URI_2>,... <URI_N>)) .
    FILTERS....
}

构造{s？p？o}
在哪里{
？s？p？o。
过滤器（？s IN（，…））。
过滤器。。。。
}

及

构造{s？p？o}
在哪里{
？s？p？o。
过滤器（？o IN（，…））。
过滤器。。。
}

第一个表达式获取边界节点为主体的所有三元组，第二个表达式获取边界节点为对象的所有三元组。还应该注意的是，我添加了几个过滤器，为了简单起见，这些过滤器被省略了

当我执行这些查询时，语句1和语句2在执行时间上有相当大的差异。语句一的执行速度比语句二快3-6倍，尽管语句基本相同

---

有人能提供一个提示，说明为什么这两个查询之间存在如此大的差异吗？更好的是，如何重组查询二以获得更好的性能？

您还没有告诉我们您使用的是哪种SPARQL egine或triple store。一个可能的原因是您正在对主题而不是对象的索引执行的存储。也可能是第二个查询只是返回更多的结果。但是，如果不了解您的具体设置，就无法判断。此外，一个幼稚的引擎实际上可能会对

过滤器进行筛选（？s in…

，首先生成大量三元组，然后过滤掉结果。您可以使用

values？s{…}

代替，这应该是等效的，但是使用朴素的引擎可能更有效。无论如何都值得一试。@user2357906每个构造结果中有多少个三元组？另外，您将以什么格式返回结果？TTL和RDF/XML确实支持“漂亮”格式，因为单个主题的属性和值可以分组，但单个对象的主题和属性不能分组，所以编写这种格式可能需要更长的时间。因此，构建图形可能需要大致相同的时间，但编写和发送输出可能需要更长的时间。在每种情况下，您得到的实际响应数据有多大？例如，三元组

sp1o1。这是p1 o2。s p2 o3

可以写入

s p1 o1，o2；p2 o3.

，但

s1 p1 o。s2 p1o。无法在TTL和RDF/XML中清除s3 p2 o

。使用一种格式，其中每一行需要三行（例如，N-Triples），可能会消除差异。我强烈建议您通过测试，而不仅仅是通过Jena测试您的查询。我不希望出现与长查询字符串相同的问题，也不希望出现

CONSTRUCT

和

SELECT

查询执行时间之间的极端差异。无论我的期望是否实现，这些测试都应该为您提供一些明确的前进道路。

CONSTRUCT {?s ?p ?o}
WHERE {
    ?s ?p ?o .
    FILTER(?o IN (<URI_1>, <URI_2>,... <URI_N>)) .
    FILTERS...
}