tbloader vs SPARQL INSERT - 为什么命名图的行为不同？答案

【问题标题】：tbloader vs SPARQL INSERT - Why different behaviour with named graphs?tbloader vs SPARQL INSERT - 为什么命名图的行为不同？
【发布时间】：2013-09-19 10:00:23
【问题描述】：

在连接 ARQ、TDB 和 Named Graphs 的命令行工具时出现了奇怪的行为。如果在命名图中通过 tdbloader 导入数据，则无法通过 SPARQL SELECT 查询中的 GRAPH 子句进行查询。但是，当使用 SPARQL INSERT 在同一个图中插入数据时，可以进行此查询。

我有以下汇编器描述文件tdb.ttl：

@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ja:     <http://jena.hpl.hp.com/2005/11/Assembler#> .
@prefix tdb:     <http://jena.hpl.hp.com/2008/tdb#> .


[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
tdb:DatasetTDB  rdfs:subClassOf  ja:RDFDataset .
tdb:GraphTDB    rdfs:subClassOf  ja:Model .

[] rdf:type         tdb:DatasetTDB ;
    tdb:location "DB" ;
.

文件data.ttl中有一个数据集：

<a> <b> <c>.

现在，我使用 tdbloader 插入这些数据，然后使用 SPARQL INSERT 插入另一个三元组，都在命名图 data 中：

tdbloader --desc tdb.ttl --graph data data.ttl
update --desc tdb.ttl "INSERT DATA {GRAPH <data> {<d> <e> <f>.}}"

现在，可以通过以下方式使用 SPARQL 查询数据：

$arq --desc tdb.ttl "SELECT *  WHERE{ GRAPH ?g {?s ?p ?o.}}"
----------------------------
| s   | p   | o   | g      |
============================
| <a> | <b> | <c> | <data> |
| <d> | <e> | <f> | <data> |
----------------------------

一切看起来都很完美。但现在我只想查询这个名为图 data 的特定：

$ arq --desc tdb.ttl "SELECT *  WHERE{ GRAPH <data> {?s ?p ?o.}}"
-------------------
| s   | p   | o   |
===================
| <d> | <e> | <f> |
-------------------

为什么从 tdbloader 导入的数据丢失了？这个查询有什么问题？如何从两个导入中获取结果？

【问题讨论】：

我不知道为什么会这样，但谢谢提出了一个深思熟虑的问题，并提供了一个我们可以用来重现问题的最小工作示例！
更多有趣的结果，见pastebin.com/3cT4fagi。简而言之，SELECT * WHERE { values ?g { <data> } graph ?g { ?s ?p ?o }} 只返回 one 值，但 SELECT * WHERE { values ?s { <a> <d> } graph ?g { ?s ?p ?o }} 返回 2，SELECT * WHERE { values ?g { <data> UNDEF } graph ?g { ?s ?p ?o }} 返回 3（结果重复)。
有趣的是，如果你使用绝对 URI 而不是相对 URI，就像我在 pastebin.com/ViWmNmWT 中展示的那样，你会得到你想要的结果。
我想知道这里发生的情况是否是 tdbloader --desc tdb.ttl --graph data data.ttl 和 update --desc tdb.ttl "INSERT DATA {GRAPH <data> {<d> <e> <f>.}}" 中的相对 URI 的解析方式不同，因此您最终会得到两个不同的 URI，它们恰好打印在这些结果的方式相同。
是的 - 感谢您提供完整的最小示例。我花了更多时间来回答这个问题，否则我可能会这样做。

标签： sparql jena tdb arq named-graphs

【解决方案1】：

试试这个查询：

PREFIX : <data>
SELECT * { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } }

输出是

----------------------------
| s   | p   | o   | g      |
============================
| <a> | <b> | <c> | <data> |
| <d> | <e> | <f> | :      |
----------------------------

或尝试：

 tdbquery --loc DB --file Q.rq -results srj

以不同的形式获得结果。

文本输出使事情看起来不错，但两个不同的事情最终成为<data>。

你看到的是

tdbloader --desc tdb.ttl --graph data data.ttl

完全按照原样使用data 来命名图形。但是

INSERT DATA {GRAPH <data> {<d> <e> <f>.}}

执行完整的 SPARQL 解析，并根据基本 URI 进行解析，可能看起来像 file://*currentdirectory*。

以文本形式打印时，URI 会被缩写，包括使用基础。所以原来的data（来自tdbloader）和file:///path/data都显示为<data>。

PREFIX : <data>

为文本输出提供一种不同的方式，将其写为:。

终于尝试了：

BASE <http://example/>
SELECT * { { ?s ?p ?o } UNION { GRAPH ?g { ?s ?p ?o } } }

它将基本 URI 设置为不靠近数据 URI 的东西，因此通过基本 URI 关闭漂亮的格式：

----------------------------------------------------------------------------------------------------------------
| s                        | p                        | o                        | g                           |
================================================================================================================
| <file:///home/afs/tmp/a> | <file:///home/afs/tmp/b> | <file:///home/afs/tmp/c> | <data>                      |
| <file:///home/afs/tmp/d> | <file:///home/afs/tmp/e> | <file:///home/afs/tmp/f> | <file:///home/afs/tmp/data> |
----------------------------------------------------------------------------------------------------------------

【讨论】：

感谢您对此问题的详细解释。然后我将使用绝对 URI。那么，UNION 就没有必要了。