Help:使用SPARQL和RDF存储

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

优势
在特定的维基站点之中是否要采用某种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）（如属性的可递性 ），还为建模提供了额外的表达功能. 有些具备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存储列表：


 * semanticweb.org
 * w3.org

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

截至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更新；当出现问题的时候，则可予以忽略）. 如下面例子所示，则必须在LocalSettings.php之中给出这些Web服务的位置：

第一行说的是，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用户应当采用如下设置：

其中，确切的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功能特性的内置支持时，才会把层级结构考虑进来. 否则，层级结构信息就不会带来额外的查询结果.