我在以下内容中使用乌龟格式的RDF
@prefix ab: <http://learningsparql.com/ns/addressbook#> .
@prefix d: <http://learningsparql.com/ns/data#> .
d:i0432 ab:firstName "Richard" .
d:i0432 ab:lastName "Mutt" .
d:i0432 ab:homeTel "(229) 276-5135" .
d:i0432 ab:nick "Dick" .
d:i0432 ab:email "[email protected]" .
d:i9771 ab:firstName "Cindy" .
d:i9771 ab:lastName "Marshall" .
d:i9771 ab:homeTel "(245) 646-5488" .
d:i9771 ab:email "[email protected]" .
d:i8301 ab:firstName "Craig" .
d:i8301 ab:lastName "Ellis" .
d:i8301 ab:workTel "(245) 315-5486" .
d:i8301 ab:email "[email protected]" .
d:i8301 ab:email "[email protected]" .
且查询为
PREFIX ab: <http://learningsparql.com/ns/addressbook#>
SELECT ?first ?last
WHERE
{
?s ab:lastName ?last .
OPTIONAL {?s ab:nick ?first. }.
OPTIONAL {?s ab:firstName ?first .}.
}
结果是
------------------------
| first | last |
========================
| "Craig" | "Ellis" |
| "Cindy" | "Marshall" |
| "Dick" | "Mutt" |
------------------------
但是如果我将查询更改为
PREFIX ab: <http://learningsparql.com/ns/addressbook#>
SELECT ?first ?last
WHERE
{
OPTIONAL {?s ab:nick ?first. }.
OPTIONAL {?s ab:firstName ?first .}.
?s ab:lastName ?last .
}
结果是
-------------------
| first | last |
===================
| "Dick" | "Mutt" |
-------------------
谁能解释造成这种差异的原因是什么?我认为SPARQL查询中的句点与“和”运算符相同。
这里的顺序很重要
SPARQL查询的语义是通过SPARQL代数表达的,这里的两个查询产生了截然不同的代数。我使用SPARQL Query Validator项目提供的Apache Jena(免责声明-我是该项目的提交者)来生成代数。
您的第一个查询产生以下代数:
(base <http://example/base/>
(prefix ((ab: <http://learningsparql.com/ns/addressbook#>))
(project (?first ?last)
(leftjoin
(leftjoin
(bgp (triple ?s ab:lastName ?last))
(bgp (triple ?s ab:nick ?first)))
(bgp (triple ?s ab:firstName ?first))))))
您的第二个查询产生以下代数:
(base <http://example/base/>
(prefix ((ab: <http://learningsparql.com/ns/addressbook#>))
(project (?first ?last)
(join
(leftjoin
(leftjoin
(table unit)
(bgp (triple ?s ab:nick ?first)))
(bgp (triple ?s ab:firstName ?first)))
(bgp (triple ?s ab:lastName ?last))))))
您可以看到查询中的三重模式以不同的顺序出现,并且运算符也不同。重要的是,您的第二个查询的join
仅保留双方的兼容解决方案,而第一个查询仅使用leftjoin
,如果没有兼容的解决方案,则按原样保留LHS解决方案。
因此,在第一个查询中,您首先会找到带有ab:lastName
的内容,然后可选地添加ab:nick
或ab:firstName
(如果存在的话,因此您可以返回数据中的所有人员。
[在第二个查询中,您首先找到带有ab:nick
的内容,然后可选地添加带有ab:firstName
的内容,然后要求所有内容都具有ab:lastName
。因此,您只能获得返回姓氏的人。
我认为SPARQL查询中的句点与“和”运算符相同。
否,它仅终止三元模式,并且可以选择遵循其他子句(但并非必须这样做),它不是“ and”运算符。
除非存在leftjoin
或minus
子句暗含替代的联接运算符(例如OPTIONAL
或MINUS
),否则相邻的基本图形模式将联接
table unit
?[table unit
是一个特殊的运算符,对应于SPARQL查询中的空图形模式。
例如SELECT * WHERE { }
将产生代数(table unit)
它产生一个空行,按照SPARQL的语义,它意味着可以将其连接到任何对象并返回其他对象,因此从本质上讲,它就像一个连接标识。在许多情况下,SPARQL引擎可以简化代数以删除table unit
,因为在大多数情况下,它对查询的语义没有影响。
在您的第一个查询中,从技术上讲,在join
和table unit
运算符之间还有另一个join
,但是在普通联接的情况下,table unit
的存在不会起作用(因为它是联接标识),因此它可以并且被简化出来。
但是对于OPTIONAL
,SPARQL规范要求产生的代数是该子句中的事物与前面的子句所具有的左连接。对于第二个查询,在第一个OPTIONAL
之前没有前面的子句(从技术上讲,那里有一个隐式的空图形模式),因此生成的第一个leftjoin
的左侧是table unit
。与普通的join
不同,在这种情况下table unit
必须保留,因为leftjoin
的语义说,如果没有与RHS兼容的解决方案,则LHS的结果将保留。
我们可以通过更简单的查询来说明这一点:
SELECT *
WHERE
{
OPTIONAL { ?s a ?type }
}
产生代数:
(base <http://example/base/>
(leftjoin
(table unit)
(bgp (triple ?s <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?type))))