帮助:Semantic Bundle/SMW

来自GIPRs
跳转至: 导航搜索
项目文档
项目主页 GIPRs语义维基
文档类型 日志
优先级
状 态 进行中
发布日期 2013/03/11
完成日期
作 者 GIPRs语义维基项目团队
来 源 www.giprs.org
源语言 中文

目录

前言

LAMP(Linux + Apache + Mysql + PHP) + MW(MediaWiki) + SMW(Semantic MediaWiki) = 双语法律语义维基 = GIPRs2013新版”,这原本计划在2013年春节前实现的,没想到每个环节都遇到了N多问题。LAMP可以外包解决,MW有大量文档和实例,SMW实在找不到什么人可以帮忙的。技术人员在网站框架搭建好后是不管应用的,剩下的问题只有自己边学边解决了。此外,用回国内服务器后,网速快了很多,忽然发现用MW做笔记比OneNote类似的网络版方便好多,顺便也用此笔记梳理下日后Wiki的用法。

仲奕,2013年2月24日晚

需求分析

有了MW,为什么还要用SMW?先梳理下需求,然后有针对性的去看参考文档:

  • 需要跨语言使用关键字、分类、名字空间、日期等检索、筛选、聚合站内知识点;
  • 需要检索、筛选、聚合文档/页面之间的链接关系(若可行,在呈现复杂的多维关系方面,则语义维基比思维导图更具优势);
  • 需要将检索、筛选、聚合得到的数据,根据用途以不同的形式呈现或输出;
  • 与以上需求相对应,需要为文档指定关键词、分类、属性,等等;
  • MW的使用太过自由、繁杂,需要尽快能的简化、统一操作,例如:确定文档的分类、属性,等等;
  • MW不能完全可视化编辑,创建编辑表格尤其不便;
  • MW作为知识库、其搜索、协同写作/编辑、版本控制、负载能力已被广为认可,SMW的语义工具对主营业务是否有帮助;

初步来看,SMW是可以满足上述需求的。但是,MW经过近两周的准备已可以立即投入使用,其效果也是可预见的;而实施SMW,还需要学习、测试,以最终评估其实施的复杂度和最终效果。

参考文档

为解决上述需求,本文主要参考、引用上述文档,以理解、测试、实施SMW。

初步理解

通看上述参考文档,初步理解如下:

  • 编辑:即,数据输入,主要通过Semantic Forms来实施,大量涉及MW模板;(重点)
  • 简单查询:有查询/搜索界面,无需深入研究,但需要理解SMW系统设置;
  • 复杂查询:关键词“Ask、查询、嵌入式查询、参数”,用来检索、筛选、聚合数据,需要理解语法和参数含义/用法;(难点)
  • 显示信息/结果格式:即,数据输出,定义、设置、输出复杂查询的结果;(难点,好在要求不高,准确/工整即可)
  • 导入/导出:数据输入/输出工具。

此外,参考常见问题解答以及Semantic MediaWiki vs. SharePoint,可以对SMW有初步了解。不论两者比较的结果如何,如果把SMW当作SharePoint,那MW就或许可以当作是Windows,Semantic Forms或许可以当作是InfoPath,这样理解也许对快速上手SMW有些帮助。

小结:SMW同其他数据处理软件,都绕不开3个核心环节:数据输入 → 查询 → 数据输出! 在了解界面、基本概念/术语后,即按此3个环节来理解/测试SMW。


安装

已完成,详见帮助:Semantic Bundle

设置

LocalSettings.php

参考文档:http://semantic-mediawiki.org/wiki/Help:%E9%85%8D%E7%BD%AE

[待处理]

Concept caching

运行php SMW_conceptCache.php结果如下:

This script is used to manage concept caches for Semantic MediaWiki. Concepts
are semantic queries stored on Concept: pages. The elements of concepts can be
computed online, or they can come from a pre-computed cache. The wiki may even
be configured to display certain concepts only if they are available cached.
This script can create, delete and update these caches, or merely show their
status.
Usage: php SMW_conceptCache.php <action> [<select concepts>] [<options>]
Actions: --help Show this message. --status Show the cache status of the selected concepts. --create Rebuild caches for the selected concepts. --delete Remove all caches for the selected concepts.
If no further options are given, all concepts in the wiki are processed.
Select concepts: --concept "Concept name" Process only this one concept. --hard Process only concepts that are not allowed to be computed online according to the current wiki settings. --update Process only concepts that already have some cache, i.e. do not create any new caches. For the opposite (only concepts without caches), use --old with a very high number. --old <min> Process only concepts with caches older than <min> minutes or with no caches at all. -s <startid> Process only concepts with page id of at least <startid> -e <endid> Process only concepts with page id of at most <endid>
Selection options can be combined to process only concepts that meet all the requirements at once. If --concept is given, then -s and -e are ignored.
Options: --quiet Do not give any output. --verbose Give additional output. No effect if --quiet is given.

均使用默认设置,需求明确后调整。

Pretty URIs

根据:https://www.mediawiki.org/wiki/Manual:Short_URL

该URL还有有风险的,而且若不改URL,迁移MW时(尤其是将数据同步到本地电脑WAMP环境运行时)会方便很多(至少不会产生URL问题),暂时不改。

Using SPARQL and RDF stores

  • RDF是专门用来存储语义数据的,要用SPARQL来查询,目前暂不使用。

界面

参考文档:

事实框

  • 参数“$smwgShowFactbox”,默认值为“SMW_FACTBOX_HIDDEN”,i.e. 默认不显示“事实框”
  • 可在任何页面上使用__NOFACTBOX__ 和 __SHOWFACTBOX__,从而隐藏或显示该页面上的事实框(在页面内容非空的情况下)
  • 事实框左列显示“属性”,右列显示该属性的取值。

语义浏览

设置

全部显示

$smwgBrowseShowAll:默认设置为true;  

逆向显示

$smwgBrowseShowInverse:默认设置为false 

简单搜索

  • Special:SearchByProperty,是为查找语义反向链接(semantic backlinks)备有一个简单的搜索表单。
  • 输入属性名称和目标取值,返回所有具有该属性且其取值为该取值的页面的列表;若返回很少结果,则同时还会显示那些最为接近的结果。
  • 设置:$smwgSearchByPropertyFuzzy设置为false来关闭该功能。

查看所有的属性、类型和取值

每个属性在属性命名空间Property当中,分别都有着各自的页面。

除了事实框以及普通搜索之中的那些链接之外,还有用来查找维基站点属性的特殊方法:

语义搜索

Special:Ask,参考文档:http://semantic-mediawiki.org/wiki/Help:%E8%AF%AD%E4%B9%89%E6%90%9C%E7%B4%A2%E9%A1%B5%E9%9D%A2Special:Ask


属性及类型

属性(properties )及类型(types)是Semantic MediaWiki之中输入语义数据的基本方式。 可将属性视为«维基页面之中取值的类别»。(引自:http://semantic-mediawiki.org/wiki/Help:%E5%B1%9E%E6%80%A7%E5%8F%8A%E7%B1%BB%E5%9E%8B)

创建属性

"Date"类型属性

日期类型,参考文档:http://semantic-mediawiki.org/wiki/Help:Type_Date

在Data类型下,创建“发布日期、生效日期、修订日期”3个属性,测试成功,但是SMW不能识别中文日期格式,目前只能采用“[[生效日期::2012.1.1|2012年1月1日]]”模式标引

用途:可定义法律文本“发布日期、修订日期、生效日期、失效日期”,以及专利文献中的有关日期,等等;可使用语义表单统一输入。

"URL"类型属性

“Annotation URI”、“URL”,2个属性,参考文档:

“Annotation URI”较少用,通常用“URL”类型属性,标引形式/格式为“http://www.giprs.org”的URL链接

"Page"类型属性

“页面”类型属性,主要用于标引Wiki页面链接,参考文档:http://semantic-mediawiki.org/wiki/Help:%E6%95%B0%E6%8D%AE%E7%B1%BB%E5%9E%8B_%E9%A1%B5%E9%9D%A2%E5%9E%8B

URL和Page类型属性用途小结: MW仅显示链入页面的链接,若需要可定义“URL”或“Page”类型属性,可标引并统计链出页面的链接

“文本”和“字符串”类型属性

所以,仅使用Text类型。

"Quantity"

Custom units

用途:解决“日”、“天”类似的相同意思但不同表达形式的期限表达方式

属性的数据类型

SMW在Special页面中的“类型”(Type)和“类”(Class)是两个不同的概念。

“类”(Class),Special:CreateClass,刚开始我以为这和Java的Class属相似概念。初步测试下来看,SMW的类,只是“一个页面,是为方便同时创建属性、模板、表单和分类的一个页面,并可能与Html的Class有关”。“类”创建完毕后,在Special没有对应的列表来显示全部已创建的“类”,i.e. “类”不能重用。此外,参考文档中并没有详细提及“类”的概念和使用,故暂不研究和启用它。

“类型”(Type),我理解为“语义数据类型”,在Special:Types列出,其含义详见:http://www.semantic-mediawiki.org/wiki/Help:Properties_and_types#Datatypes_for_properties

Type与Property的关系:Type下有多种数据类型,每个数据类型下有可有多个Property,每个Property可有多个“取值(Value)”

模板和表单

参考文档:

使用 Special:CreateClass 页面创建表单(SF)是最简单快捷的方式,创建后可根据需求调整,测试几次就可以大致了解SF的基本操作了。

注:修改Class创建的表单时,模板和表单中的属性名称要一致,在增加属性前应首先创建它。我是先修改表单,然后同步修改模板中的数据,使得两者数据保持一致,可参考 Form:法律法规,这是本站创建的第一个表单。

问题

SMW详细的参考文档比较少(和MW比较而言),当实现用属性标引文本、用表单创建页面后,就产生了一个困惑:如果确定MW分类和SMW属性的使用策略?

  • MW的分类比较直观,操作简单,在稳定性和效率方面我个人认为肯定比SMW的属性要好;
  • 用表单创建页面确实比较方便,需要统一输入的数据都可以定义在表单中,可统一数据结构;
  • 目前需要在表单中定义的属性,大都是分类名称,因为单纯使用模板无法达到类似InfoPath的效果,其结果就是大部分MW分类都被SMW的属性覆盖了。

需要解决的问题:

1、是否采用双轨制,i.e. MW分类和SMW属性并存?

  • 优点:不过分依赖SMW,若SMW出问题,卸载后基本不影响MW页面的使用
  • 缺点:管理麻烦且有点混乱,而且会浪费服务器资源

2、优先使用SMW属性

  • 优点:管理相对方便(相对于双轨制),能够更灵活的查询数据,并将结果呈现出来(类似于Drupal的View扩展)
  • 缺点:SMW肯定不如MW稳定和完善,本站安装后已经更新了两次,还没解决问题;SMW相对MW要更耗资源,还不清楚页面增加后,查询/输出是否会影响访问速度,而MW则不需要过于担心此类问题(同等负载前提下)

3、优先用MW分类,SMW的属性仅用作标引页面文本

  • 若仅用MW分类,那是最简单且稳定的
  • 分类多了,管理和使用实在不方便;用DPL调用页面同样很耗资源,尤其是存在循环分类时

分类和属性两者最终目的都是为了标引、查询、聚合数据,等SMW下个版本出来,看看是否解决了现有问题,若SMW能够基本稳定运行的,还是会考虑用它。
(截至目前,http://translatewiki.net/ 有近10万个属性,300多万个页面,我们的小网站应该没有什么大问题)


语义查询

页面选择

附日期条件的页面选择:

{{#ask: [[Concept:GIPRs新闻动态]] [[发布日期::>2012.8.1]] | ?发布日期#ISO= | |sort=发布日期 | order=desc | format=ul | limit=10 | searchlabel=浏览更多查询结果}}

已应用的页面:GIPRs:新闻动态


严格的比较操作符


显示信息


结果格式


嵌入式查询


概念


推理

格式结果