我最近遇到了SPARQL 1.1 Federation Extensions的工作草案,并想知道这是否已经可以使用命名图表(不会减损上述草案的用处)。
我对命名图的理解有点朦胧,除了我从阅读规范中发现的唯一内容包括合并的规则,在查询时与其他图相关的非合并。由于这不能完全满足我的理解,我的问题如下:
给出以下查询:
SELECT ?something
FROM NAMED <http://www.vw.co.uk/models/used>
FROM NAMED <http://www.autotrader.co.uk/cars/used>
WHERE {
...
}
假设查询处理器/端点可以或应该在命名图的上下文中执行以下操作是否合理:
检查是否存在本地存在的命名图
如果没有则执行以下操作(在上述查询的情况下,我将使用第二个命名图)
GET / sparql /?query = EncodedQuery HTTP / 1.1 主持人:www.autotrader.co.uk 用户代理:my-sparql-client / 0.1
其中EncodedQuery仅包含FROM NAMED
子句中的第二个命名图,并且WHERE
子句相应地针对GRAPH
子句进行了修改(例如,如果GRAPH <http://www.vw.co.uk/models/used> {...}
是GET /cars/used HTTP/1.1
Host: www.autotrader.co.uk
被使用)。
仅在无法执行上述操作时,请执行以下任一操作:
LOAD <http://www.autotrader.co.uk/cars/used>
或
OFFSET
显然,围绕LIMIT
和{{1}}的
我还记得很久以前在遥远的星系中读过的地方,根据以下惯例,任何SPARQL端点的默认图都应该是一个命名图:
对于:http://www.vw.co.uk/sparql/,应该有一个命名图:http://www.vw.co.uk代表默认图,因此通过上述逻辑,应该已经可以使用命名图联合SPARQL端点。
我问的原因是我想在上面的例子中开始推广跨域的联合,而不必等待标准,确保我不会做一些不合适的事情或与某些东西不兼容的事情否则将来。
答案 0 :(得分:0)
使用SERVICE或FROM在联合查询中使用的命名图和URL是两回事。后者指向SPARQL端点,命名图形位于三重存储中,并具有分隔不同数据集的主要功能。反过来,这对提高性能和表示知识都很有用,例如一组语句的来源是什么。
例如,您可能有两个数据源都声明?movie has-rating ?x
,您可能想知道哪个来源说明了哪个等级,在这种情况下,您可以使用与这两个来源关联的两个命名图(例如, http://www.example.com/rotten-tomatoes
和http://www.example.com/imdb
)。如果您将两个数据集存储在同一个三元组存储中,则需要使用NG,而远程端点则是另一回事。此外,命名图与VoID等词汇表一起用于描述整个数据集,这是将它们存储在三重存储中的意愿的另一个原因。
您可以将NG绑定到端点URL的机制作为选项实现,但我不认为将其作为强制要求是一个好主意,因为单独管理远程端点URL和NG可能更多是有用的。
此外,联合查询的真正挑战是提供端点透明查询,使查询引擎足够智能分析查询并了解如何拆分查询并在右端点上执行部分查询。有很多研究正在进行中,其中一个最重要的结果(据我所知)是FedX,它已用于实现多个查询分发优化(example)。 / p>
要添加的最后一件事,我依稀记得你提到的关于$ url,$ url / sparql的约定。有几种方法(例如LOD cloud)。也就是说,在目前大多数三重商店(例如,Virtuoso)中,没有指定命名图(不使用GRAPH)的查询工作方式与落入默认图形情况不同,它们实际上是查询商店中所有命名图形的联合,通常更有用(当您不知道某些内容被陈述,或者您想要整合交叉图形数据时)。