使用SPARQL和RDF存储

使用SPARQL和RDF存储
Provides information about using SPARQL and related RespositoryConnectors.
Table of Contents

默认情况下，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 2本体语言，并提供相应的接口来查询所存储的数据（比如，借助于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更新语言的数据库。在Semantic MediaWiki 1.7.0当中，要求存储接受那些并未说明图形（graph）的更新和查询；不过，计划未来删除这项限制。目前，有两个地方保存维护有RDF存储列表：

• semanticweb.org
• w3.org

（注意：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';

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

Virtuoso

自从Semantic MediaWiki 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数据库之中尚无任何数据。要采用维基站点当前的内容填充该数据库，有必要先刷新所有的数据。详情请参见修复数据和数据结构。任何刷新这些数据的方法都会有效。所有的SMW查询（嵌入式查询或语义搜索）都将针对RDF数据库来执行，因此，只有当刷新了所有的数据之后，它们的结果才会准确无误。

已知的局限性

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

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