FAQ/zh-hans

From semantic-mediawiki.org
< FAQ
FAQFAQ/zh-hans

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

何谓Semantic MediaWiki?[edit]

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?[edit]

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

Semantic MediaWiki受欢迎的程度如何?[edit]

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

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

Semantic MediaWiki的性能如何?[edit]

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

SMW如何存储其数据?[edit]

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

SMW为何不把SPARQL作为其查询语言?[edit]

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

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

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

在SMW之中可推理获得什么知识?[edit]

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

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

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

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

查询结果当中为何没有出现我刚刚新增的数据?[edit]

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

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

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

Semantic MediaWiki很棒!它会不会最终用在Wikipedia上?[edit]

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

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

把SMW用在Wiktionary之类其他的Wikimedia网站上如何?[edit]

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

SMW计划还有其他那些功能特性?[edit]

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

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

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

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

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

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

我还能如何为SMW工作提供帮助?[edit]

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

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

SMW有哪些替代者?[edit]

我们的确认为,不论是免费的,还是私有的,目前还没有其他替代软件,能够像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相关的活动或会议?[edit]

"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的文档记录如此之多!到底我该从何下手?[edit]

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

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

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


本页面的其他语种: enesfrru