Sparql Jena Fuseki和Blazegraph在字符串文本的“类型严格性”方面表现不同

我正在玩Blazegraph 2.1.5和Jena Fuseki 3.10.0。首先，我使用以下查询插入两个三元组：

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

insert data {
  <http://s> <http://untyped> 'abc' .
  <http://s> <http://typed> 'abc'^^xsd:string .
}

select * where { ?s ?p 'abc' }

Jena Fuseki找到两个三元组，而Blazegraph只找到“未类型化”的一个

如果我特别要求输入一个版本，也会发生同样的情况：

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

select * where { ?s ?p 'abc'^^xsd:string }

Jena Fuseki再次找到这两个三元组，而Blazegraph只找到“类型化”的一个

这种行为显然不同

以下是我的问题：

哪种行为仅仅是其中一种，或者两者都符合SparQL 1.1规范？ 如果Jena Fuseki行为是唯一与规范一致的行为，那么是否可以将Blazegraph配置为Fuseki行为？ 如果Blazegraph行为是“正确”的，有没有一种方法可以在不使用并集或过滤器的情况下找到这两个三元组？

---

这是一个有趣的问题，因为答案一点也不明显。当前的TripleStore实现了2013年标准化的语言SPARQL 1.1。它是RDF的查询语言，但适用于当时的RDF版本，即2004年标准化的RDF版本

在RDF 2004中，文字可以是或。纯文本是一个UNICODE字符串，带有可选字符。类型化文字是一个未编码的字符串，带有

SPARQL调用没有语言标记的纯文本。一个简单的文本，作为一个UNICODE字符串，永远不会与类型化的文本相同，类型化的文本在所有情况下都是成对的。因此，一些文本和一些文本^^xsd:string在RDF 2004和SPARQL 1.1中是不同的文本

现在，在2014年，出现了一个新版本的RDF，其中所有文字都有a，包括带有语言标记的文字。不必在具体的语法中提到它们的数据类型IRI。语言标记的存在足以将数据类型IRI标识为rdf:langString。在具体语法中，使用xsd:string键入的文本可以在不使用数据类型IRI的情况下编写。因此，根据RDF1.1，Turtle或N-triple语法中的一些文本实际上意味着一些文本^^xsd:string

当您使用符合RDF 1.1的RDF API以及SPARQL 1.1实现时，会出现与您的问题相关的问题。如果加载的RDF文档包含：

<subject> <predicate> "some text" .

它应该根据RDF 1.1规范进行解释，还是应该按照SPARQL 1.1规范进行加载？原则上，这：

INSERT DATA {
  <http://s> <http://untyped> 'abc' .
  <http://s> <http://typed> 'abc'^^xsd:string .
}

---

是SPARQL 1.1，所以应该理解为包含2个三元组，其中一个是简单文本，一个是类型化文本。但是SPARQL实现使用RDFAPI，因此混合使用RDF1.1和SPARQL 1.1可能会使系统应用不可预测的行为。我想，您只能依靠文档和测试来实现特定的实现。

没有语言标记的“abc”是自RDF 1.1以来隐式的“abc”^^xsd:string。另请参见“简单文本是数据类型为IRI的抽象语法文本的语法糖”@UnformedUser看起来要么Blazegraph违反了SPARQL 1.1规范，要么他们不支持它。我说的对吗？可能有关联：