FAQ/zh-hans

下列是关于Semantic MediaWiki的一些常见问题解答。

何谓Semantic MediaWiki？

Semantic MediaWiki（缩写为SMW）是对MediaWiki的一种扩展。MediaWiki乃是最为知名的，支撑驱动Wikipedia的维基应用程序。SMW让用户能够在维基页面中存储数据，在其他地方查询这些数据，从而将使用SMW的维基站点转变成为一种语义维基。目前，存在着许多其他旨在与Semantic MediaWiki配合使用的扩展（当前至少有30种之多）；术语"Semantic MediaWiki"有时用来指这整个扩展家族。这些扩展涵盖了方方面面的事情，包括帮助用户录入数据，实现数据的可视化（采用地图、日历和图形之类的格式），导入和导出SMW数据，以及把SMW用于工作流程用途。

应当注意的是，本扩展有时又简单地称作"Semantic"，这也许是因为其大多数的附带扩展的名称均以"Semantic"开头，如"Semantic Forms"（语义表单），尽管这么叫并不合适。

正像几乎所有其他的MediaWiki扩展那样，Semantic MediaWiki不但自由，而且开源。

要更多地了解SMW，可以阅读本网站上的资料以及Wikipedia上关于SMW的文章。

谁在开发Semantic MediaWiki？

SMW最初是由卡尔斯鲁厄理工学院（Karlsruhe Institute of Technology，KIT）的几个程序员所开发的。不过，近些年，这项工作已经大范围展开，把世界各地许多其他的开发人员都包括了进来；详情请参见SMW项目的有关情况。诸多基于SMW的扩展是由相当多其他的贡献者开发出来的。

Semantic MediaWiki受欢迎的程度如何？

SMW当前正在用于近300家活跃的公共维基站点。不可能知道到底有多少家私有维基站点在运用SMW，但根据公共和私有维基站点在错误报告等等当中询问的频率来看，粗略估计，运用SMW的私有维基站点的数量相当于公共维基站点。

一些使用Semantic MediaWiki的，比较著名的公共维基站点包括Oh Internet、OpenEI和SNPedia。在内部使用SMW的公司包括Audi和Pfizer。其他使用SMW的组织机构包括纽约大都会艺术博物馆（Metropolitan Museum of Art）和联合国（United Nations）。许多国家的政府机构也在使用SMW，包括美国和加拿大。

Semantic MediaWiki的性能如何？

SMW除了相当大规模的实际安装以外，为了确定SMW的性能，还完成了各种各样的测试。遗憾的是，任何这些测试至今尚未发布任何的结果发现。不过，我们的确知道其中的一些结论：即使对于数百万行的数据，SMW也得到了成功的使用；限制因素通常是过度复杂的查询。目前，已经证实各种标准性能改进措施确实有益于SMW的性能，包括APC和memcached之类高速缓存工具的使用、增加缓冲大小之类的MySQL调整以及独立数据库服务器的使用。"Semantic MediaWiki提速"页面当中包括有更多的此类技巧。

SMW如何存储其数据？

Semantic MediaWiki在MediaWiki所使用的数据库（通常为MySQL数据库）之中利用额外的10张数据表来存储其数据。SMW还可以将其数据另外存储在4store和Virtuoso之类的RDF triplestore（RDF triplestore三元组存储）当中，尽管在此类情况下，同时还在使用其标准数据库。关于triplestore存储的详情，请参见使用SPARQL和RDF存储页面。

SMW为何不把SPARQL作为其查询语言？

SPARQL乃是语义网的主要查询语言，利用SPARQL来查询SMW数据有着许多大的优点：与SMW的原生查询语言相比，SPARQL总体上更为灵活；除了这种维基站点自己的数据外，SPARQL还允许查询其他来源的语义数据；而且，使用SPARQL还可以免得用户们去学习又一种查询语言。

之所以认为不可能利用SPARQL来查询直接存储在主控SMW数据库表当中的数据，主要是因为同样的灵活性：SMW现有的查询系统无法处理许多的SPARQL查询。

然而，SPARQL查询却可以轻松地处理利用RDF triplestore所存储的数据。不过，现在已经可能利用多种不同的方式，在RDF之中存储SMW数据，亦可针对来自SMW型维基站点的数据发出SPARQL查询。 — 参见上面的问题。

在SMW之中可推理获得什么知识？

语义系统的优势之一就是，并不是每个数据都必须明确地予以声明出来；有些数据可以是推断出来的。当前，SMW支持四种类型的推理：

• 子类别（subcategory）（对特定类别当中页面的查询，也将获得所有其子类别当中的那些页面）、
• 子属性（sub-property）（可以将属性声明为其他属性的子属性，并且可以按照这种方式进行查询）、
• 等同性（equality）（指向某个又重定向到另外页面的页面的属性，已会将其取值转移给另外那个页面）
• 逆向属性（inverse properties）（您可以从反方向针对属性进行查询）。

详情请参见关于推理的帮助页面。

推理还有另外两种途径： 如果您在利用模板来存储语义数据，可以在相应的模板当中创建自定义推理 — 例如，利用#if 解析函数（#if parser function）, 可以添加对于一个关于某个人的页面的调用，从而如果该人拥有至少一个孩子且该人为男性，则就把该页面添加到"Fathers"（父亲）这个类别。 另外，亦可利用RDF triple stores和SPARQL查询，完成表达能力更强的推理。

查询结果当中为何没有出现我刚刚新增的数据？

SMW数据的创建或修改之间有时存在着一定的延迟，当新数据显示在查询结果当中的时候，那是因为MediaWiki本身的页面缓冲机制。在不了解任何替代手段的情况下，有些人会通过再次保存包含该次查询的页面，来暂时解决这个问题，但这么做并无必要 — 您可以通过在该页面上进行一次MediaWiki刷新/清洗，即可对该查询结果加以刷新。 如果您是一位MediaWiki管理员，单击"refresh"（刷新）选项卡（不要与浏览器上的"reload"（重新加载）按钮搞混淆了，该按钮并没有任何作用）即可实现这一点。如果您不是管理员，转到该页面以"&action=purge"结尾的URL去，即可获得同样的效果。或者，您也可以等待就是了 — 高速缓冲的页面通常会在24小时以内刷新。

如果您希望从不缓冲某些维基页面，可以安装MagicNoCache扩展，并在这些页面之中的任何地方添加字符串"__NOCACHE__"即可。

最后，如果您运行的是中小型的维基站点，只需彻底关闭MediaWiki页面缓冲功能，而这也许并不会对性能产生巨大的影响。这项设置只需轻轻松松的一步即可完成。

Semantic MediaWiki很棒！它会不会最终用在Wikipedia上？

"semantic Wikipedia"（语义维基百科）的梦想最初是受创建Semantic MediaWiki的启发，而且现在还继续激励着它的一些开发人员。另一方面，Semantic MediaWiki作为一个概念，大多数的MediaWiki核心开发人员都已熟悉了不短的时间，而其中一些人也对它表达出了巨大的热情（例如，参见这个视频当中的21:18 – 22:44）。

幸运的是，目前看来最终这个梦想可能会真的实现。当前，有一个称为"Wikidata"的计划内项目。该项目会利用Semantic MediaWiki来帮助创建单独一个大规模的数据存储，从而可供所有不同语言维基百科用于填充其信息框（infoboxes ）。 — 也可以供外部系统查询。该项目将需要对SMW加以某种修改，以便支持数据的多种语言，以及对于每个数据的引用信息。Wikimedia Deutschland目前正在协调这个项目，且计划在2012年的某个时候启动。

把SMW用在Wiktionary之类其他的Wikimedia网站上如何？

其他多个不同的维基媒体基金会（Wikimedia Foundation）项目之中也含有结构化数据，因而有可能受益于Semantic MediaWiki：Wikimedia Commons、Wikispecies、Wiktionary和MediaWiki.org就是几个例子。与在Wikipedia之上运用SMW相比，无论是何种原因，在这些站点运用SMW的想法目前还没有激起多少兴趣。不过，"Wikidata"项目如果行得通的话，最终也会把部分或全部的其他这些站点包括进来。

SMW计划还有其他那些功能特性？

对于SMW以及在其基础之上的扩展的一些计划内的新功能特性，可参见开发路线图页面。

我想贡献一个错误修复方法/新的功能特性/新的扩展。我该怎么办呢？

首先，我们衷心感谢SMW每位潜在新的贡献者的热情。许多的用户都已经贡献了有益的功能特性和错误修复方法，而且几乎每个SMW开发人员也都是从贡献仅仅一点点代码起步的。

如果您希望贡献的只是一个错误修复方法，最好的办法就是为您的代码创建一个补丁，并通过Bugzilla把它提交上来。

如果您贡献的是一项新的功能特性，甚至可能是一种新的可能的扩展，则强烈建议您首先向semediawiki-user邮件列表写封关于它的电子邮件。— 有可能早已存在这样一种功能特性或者插件。或者已有人在开展这项工作，或者过去已经讨论过且认为缺乏可行性，或者至少其他人对如何实现它有着有益的想法。

如果您正在计划着着手开发，有关详情和资源，请参见开发人员支持 页面。

我还能如何为SMW工作提供帮助？

即使您不是开发人员，也有各种各样您可以帮助SMW项目的事情可作。 如果您或贵组织机构已经受益于Semantic MediaWiki，可以撰写一份对它的褒奖 —只是关于它如何有用的简短描述，将其发送至testimonials@semantic-mediawiki.org，我们将非常感谢。 您也可以在semediawiki-user邮件列表以及互联网中继聊天频道（#semantic-mediawiki IRC channel）之上，回答其他用户的提问。

如果您拥有博客或者Twitter账户，你可以写些有关Semantic MediaWiki的东西。 最后，如果您与媒体有什么联系的话，或者您自己就在媒体界的话，我们觉得SMW就是一个引人入胜的主题。 — 迄今为止，SMW在新闻出版领域的覆盖量还极其得少，无论是纸质出版还是在线媒体。

SMW有哪些替代者？

我们的确认为，不论是免费的，还是私有的，目前还没有其他替代软件，能够像Semantic MediaWiki这样成就灵活的协作式数据结构。 不过，在众多的公司当中，Microsoft SharePoint相当经常地被人作为一个替代选项（关于SMW相对于SharePoint的优势的一种看法，请参见这里）。

目前，存在着多种不同的语义维基应用程序，尽管现在我们只是听说了Wikidsmart。 Wikidsmart是对Confluence的一个扩展，被认为是Semantic MediaWiki的一种直接替代者，而这可能是因为Confluence维基引擎的流行所造成的。

SMW与MongoDB之类面向文档的数据库（document-oriented databases）有着某些共同的特点，尽管与此类数据库通常所做的相比，SMW的功能更像是一种前端应用程序，因此很少把它们看作是替代者。

在MediaWiki世界里面，有时会把DynamicPageList（动态页面列表，DPL）扩展与SMW相比较。DPL也允许页面查询，尽管其并不支持语义标注： 其所有的查询都依据的是类别以及其他标准的MediaWiki属性，如页面的最后修订日期。相对于SMW而言，DPL的一大优势就是其支持页面修订次数之类页面元数据的查询，而SMW则并不支持。 尽管并没有什么规矩反对同时使用二者，但一些维基站点并不联合使用二者。

整体来说，Semantic MediaWiki的真正竞争者乃是每个所谓的"交钥匙式（turnkey）"应用程序。此类应用程序旨在用于存储特定类型的数据。SMW作为一种廉价而又灵活的替代品，我们希望看到许多此类应用程序的用户考虑切换到SMW。

有没有SMW相关的活动或会议？

"SMWCon"，又叫“Semantic MediaWiki Conference（语义媒体维基会议）”，乃是SMW用户和开发人员两年一次的聚会，在美国和欧洲交替举办。至今，SMWCon已经举办了四次。下一届将是2012年4月25–27日在美国加利福尼亚卡尔斯巴德举办的SMWCon 2012年春季会议。

还有常常讨论SMW的其他活动。 迄今为止，每年一次的 Wikimania会议总是有一个SMW开发人员代表团（实际上，SMW就是在2005年首届Wikimania上首次提出来的）。 语义技术大会（Semantic Technology Conference）（又称为SemTech）上通常也会有一些SMW开发人员和用户；这个会议有时甚至还为语义维基设有专题（比如，SemTech 2010大会上的语义维基专题）。 WikiSym则是另一个时常讨论SMW相关主题的活动系列。

SMW的文档记录如此之多！到底我该从何下手？

着手使用Semantic MediaWiki的一种方法就是，搞清楚自己到底想使用哪些附加扩展 — 那些可以对您的数据结构以及您在自己的维基站点之上应用SMW具有重大影响的扩展。您可以参阅完整的SMW扩展列表。

目前有两种不同的SMW扩展包您可以下载，每个包都提供了"精心策划"的一套SMW外围软件：

• Semantic Bundle（语义包）
• SMW+（其中也包括着一个定制版本的MediaWiki）

另外，您还可以查阅作为一些维基站点范例的一套月度SMW维基站点；这些维基站点已经成功地把Semantic MediaWiki应用于各种各样的用途。

本页面的其他语种： en, es, fr, ru