使用SPARQL和RDF存储

Template:Interlanguagelink: en

使用SPARQL和RDF存储
Property "Has description" (as page type) with input value "Provides information about using SPARQL and related RespositoryConnectors." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.


Table of Contents
Contents 1 关于采用RDF数据库的支持与反对意见 1.1 优势 1.2 缺点 2 针对RDF数据库做出决定 3 配置SMW 3.1 4Store 3.2 Virtuoso 3.3 其他的RDF存储 4 将数据移动到新的数据库 5 已知的局限性

默认情况下，SMW会把所有的数据都存储在MediaWiki所使用的同一个关系数据库当中（通常是MySQL数据库）。这将保证安装起来简便易行，但关系数据库对于语义数据来说并不是一种理想的存储手段。一种更为自然的，适合于SMW数据的数据模型就是RDF。RDF乃是一种数据格式，它把信息组织在图形（graphs）之中，而不是固定的数据库表当中。幸运的是，还是可以采用基于RDF的系统，结合标准的SQL数据库，来管理查询SMW的数据。本页面将阐述其中的细节。

关于采用RDF数据库的支持与反对意见

优势

在特定的维基站点之中是否要采用某种RDF存储，取决于许多的因素，包括所采用的具体的RDF数据库。不过，我们还是可以合理地期望获得下列优势：

查询性能更佳
RDF存储在设计上旨在采用SPARQL查询语言来应答查询。与采用关系数据库的SQL查询语言相比，采用这种语言则可以更为自然地表达SMW查询。从这种意义上来说，SMW查询乃是RDF数据库系统最为典型的用例。而且，对于SMW查询来说，许多针对关系数据库查询的重要优化方法毫无用处，或者起着误导的作用。因此，可以期望，RDF存储应当可以提供极佳的查询性能。

额外的接口
支持SPARQL标准的RDF存储还允许其他应用程序针对自己的数据提出SPARQL查询，且无须借助于SMW网络前端（web frontend）。这使得我们可以在其他应用程序当中有效地利用维基站点数据。有些具备SPARQL能力的数据库还进一步支持（部分的）OWL本体语言，并提供相应的接口来查询所存储的数据（比如，借助于OWL链接协议（OWL Link protocol））。语义网应用程序也可以利用许多的公共编程库（common programming libraries）（如librdf或OWL API），从而有助于在较低的层次上将它们与其他的工具集成起来。

推理功能以及基于本体的数据存取能力
RDF Schema和 OWL之类的语义网语言，比如通过允许声明派生类（derived classes）或声明进一步的属性特性（property characteristics）（如属性的可递性<transitivity>），还为建模提供了额外的表达功能。有些具备SPARQL能力的数据库还能够评价这些查询应答功能；比如，对于基于本体的数据存取（ontology-based data access，OBDA）来说，利用语义建模构造（semantic modeling constructs），依据数据来创建“虚拟视图（virtual views）”的方法。

数据集成和本体重用
可以在RDF数据库之中存储由SMW来更新的额外数据。这样，RDF存储就可以作为数据集成和本体重用的一种平台来发挥作用。

计算资源的物理隔离
采用与MediaWiki之中不同的数据库后端，为在多个服务器之间分配任务提供了一种简便的方法。因而，尤其是可以防止复杂查询影响维基站点的基本操作，即使是它们意外地消耗了惊人数量的计算能力，也就是说，在它们搞垮了为RDF数据库提供主机托管服务的服务器的情况下。

缺点

然而，同时也存在着许多可能的缺点：

存储要求更高
只是在RDF数据库之中对数据进行了镜像，而不是从SQL数据库之中删除了数据。因而，需要额外的存储空间。

额外的维护工作
RDF 后端在SMW之中的安装并不难，但要运行额外的数据库管理系统，仍要花费一些精力。

有关性能和稳定性的疑问
目前，已有许多工业级的RDF数据库可用，其中有些还是免费或开源的。然而，将这些系统与SMW配合使用的经验还是有限的，因而在决定为大型SMW应用程序采用特殊的后端之前，进行一些测试还是会有所帮助。

幸运的是，无须花费太多精力，即可在基于SQL的存储后端与基于RDF的存储后端之间来回切换，因此，在试用一段时间之后，还可以再做定夺。

针对RDF数据库做出决定

原则上，SMW支持任何支持SPARQL查询语言 和SPARQL 1.1之中所介绍的 the SPARQL更新语言的数据库。在SMW 1.7.0当中，要求存储接受那些并未说明图形（graph）的更新和查询；不过，计划未来删除这项限制。目前，有两个地方保存维护有RDF存储列表：

（注意：RDF存储有时又称为“三元组存储<triple stores>”，尽管许多现代的存储实际上属于“四元组存储<quad stores>”，后者也为每个RDF三元组赋予一个具名图形<graph>。）

截至2012年，两个尤为值得注意的，自由且开源的RDF数据库就是4Store和Virtuoso。二者均已成功用于SMW，尽管当前因为在SMW查询之中并不使用具名图形的上述限制，Virtuoso仍需要在SMW之中进行若干不大的变更。

配置SMW

SPARQL请求，无论是查询还是更新，都是通过Web服务来交换的。这就意味着，请求是发送到URLs和数据是从URLs那里接收，而URLs则是说明相应服务的位置。这种位置是由RDF数据库及其配置来确定的。例如，在本地机器上，4Store的SPARQL查询Web服务（“端点”）典型的默认位置可能就会是http://localhost:8080/sparql/。

为了对SMW进行配置，以便使用SPARQL数据库，需要您了解SPARQL查询服务的位置以及SPARQL更新服务的位置。选择性的就是，您还可以利用某种在更新上支持基于HTTP 之上的SPARQL 协议的服务（如果使用的话，对于简单的更新请求，SMW将会首选这种方法，而不是SPARQL更新<SPARQL Update>；当出现问题的时候，则可予以忽略）。如下面例子所示，则必须在LocalSettings.php之中给出这些Web服务的位置：

$smwgDefaultStore = 'SMWSparqlStore';
$smwgSparqlQueryEndpoint = 'http://localhost:8080/sparql/';  # 查询服务的位置
$smwgSparqlUpdateEndpoint = 'http://localhost:8080/update/'; # 更新服务的位置
$smwgSparqlDataEndpoint = 'http://localhost:8080/data/';     # 基于HTTP之上的SPARQL服务（SPARQL over HTTP service）的位置
                                                             #  可选；出现问题时，则可予以忽略
$smwgSparqlDefaultGraph = 'http://example.org/mydefaultgraphname'; # 默认图形的可选名称

第一行说的是，SMW要采用SPARQL存储实现（store implementation）来存储数据（而不是默认的SMWSQLStore2）。其余行则提供的是相关的服务位置；其中，最后两行可省略。在许多情况下，不应设置smwgSparqlDataEndpoint，因为大多数存储都有其各自的置入协议（protocol for posting）。

默认情况下，SMW将使用的是基于最新SPARQL文档的通用SPARQL连接器。一些RDF数据库可能会并不完全兼容它，或者可能会需要专门的调整，以便利用那些高级的非标准功能特性。

4Store

4Store用户应当采用上述设置，但还要额外做出如下设置：

$smwgSparqlDatabase = 'SMWSparqlDatabase4Store';

这是自SMW 1.6.0以来才提供的。这将确保采用4Stores软限制功能来限制查询应答时所需的那些资源。而且，用于数据端点的协议（如果加以了配置的话）是4Store所特有的。推荐使用这项功能，因为其在写入上效率更高。

Virtuoso

自从SMW 1.7.1以来，提供了对Virtuoso的支持。Virtuoso用户应当采用如下设置：

$smwgDefaultStore = 'SMWSparqlStore';
$smwgSparqlDatabase = 'SMWSparqlDatabaseVirtuoso';
$smwgSparqlQueryEndpoint = 'http://localhost:8890/sparql/';
$smwgSparqlUpdateEndpoint = 'http://localhost:8890/sparql/';
$smwgSparqlDataEndpoint = '';
$smwgSparqlDefaultGraph = 'http://example.org/mydefaultgraphname';

其中，确切的URLs取决于本地配置。可以任意选择默认图形的URI，但必须加以设置。Virtuoso（至少是某些版本）的使用目前也存在着一些已知的局限性：

数值型数据类型并未得到正确的支持，因而当查询条件需要数字取值时，Virtuoso会遗失查询结果。这也会影响日期类型Type:Date属性，因为查询时也使用数字型取值。
某些编辑（插入）查询会因未知原因而失败，也许是与不寻常的/复杂的输入数据有关（比如，在字符串之中使用特殊字符）；当试图在页面上存储此类取值时，就会出现错误。
Virtuoso遇到负值年份的XSD日期时会失败，即使是此类日期遵循ISO标准只有四位数字。试图存储此类数据时会造成错误。

其他的RDF存储

那些符合官方SPARQL和SPARQL更新标准的存储大多应当能够很好地工作。例如，已有报道说明Sesame可以与默认连接器协同工作。在许多情况下，都应当采用设置$smwgSparqlDataEndpoint = '';，因为对于（可选）数据端点协议的支持并未通过很好的测试。

要利用您的存储的特殊功能，通过对SMWSparqlDatabase划分子类（subclassing），即可轻松地创建经过改良的实现。在4Store和Virtuoso的文件当中可以找到示例（参见目录./includes/sparql/）。可将有关建议和文件放置到缺陷跟踪程序（bugtracker）当中（参见左侧的链接）或者采用电子邮件来发送。

将数据移动到新的数据库

在变更了配置之后，RDF数据库之中尚无任何数据。要采用维基站点当前的内容填充该数据库，有必要先刷新所有的数据。详情请参见Help:修复SMW数据。任何刷新这些数据的方法都会有效。所有的SMW查询（嵌入式查询或语义搜索）都将针对RDF数据库来执行，因此，只有当刷新了所有的数据之后，它们的结果才会准确无误。

已知的局限性

当采用借助于RDF数据库的查询应答机制时，目前尚不支持少数的功能：

概念查询（Concept queries）： 在RDF存储当中，尚不支持概念。
类别和属性层级结构（Category and property hierarchies）：只有当RDF数据库备有对于RDF Schema的rdfs:subClassOf和rdfs:subPropertyOf功能特性的内置支持时，才会把层级结构考虑进来。否则，层级结构信息就不会带来额外的查询结果。

Status:	effective
Progress:	99%
Version:	1.9.3+