View source for 为什么没放弃 Semantic MediaWiki

20250522 update:

因为我解决了 Semantic MediaWiki 使用 apcu 导致前后端缓存不一致的问题，即改用 redis 缓存。所以，我真正用上了 Semantic MediaWiki。没办法，它确实很符合我要完成的一项工作的需求。

----
Semantic MediaWiki 是 MediaWiki 一系列拓展的合集。宣称是实现 MediaWiki 的语义化。有可能是我还没搞懂，以我目前的认知来看，用它性价比很低，值得直接放弃，后来者想尝试的，建议试试 Cargo。

== 原因 ==
我放弃 Semantic MediaWiki 的原因有以下：
# 主观原因，composer 在国内网络联通性太差，普通人很难搞定。这将导致新手安装都无法顺畅，更不要谈应用它了
# 客观原因，MediaWiki 官方舍弃了 Semantic 方案，自行开发了一套语义化方案
# Semantic MediaWiki 的缓存做得很垃圾，删掉的属性一会儿又出现了，逼死强迫症
# Semantic MediaWiki 的速度很慢，改点东西很卡顿，这是 feature，不是 bug，要自行手动运行各类 job 脚本
# Semantic MediaWiki 的 Create Template 缺乏健壮性，套出来的 Forms 与预想有较大出入，又丑又怪

当然，以上可能全是因为我还没有彻底弄懂它，但我已经不想在它身上耗时间了。

== 理解 ==
[[File:Semantic.png|500px]]

我最初想用 Semantic MediaWiki，是出于自动化需求，我想 MediaWiki 自动帮我搞定开庭日期、案名、案件程序、各类名单。

以我现在的了解，Semantic MediaWiki 做的就是一件事：给文字添加一种属性。根据此属性，后续可以查询、自动显示、美化、自动拼装。

但是，操作的繁杂性，与预期的收益，完全不成正比。

在我看来，难度大于七步，入手大于七天，与赚钱无关，就不值得学了。

万一以后又有了迫切需要 Semantic MediaWiki 的场合，或者我对它的了解更加深入，或者它被我吐槽的点得到完善，我又一次需要它，为了减少以后的折腾时间，记录一下现今对 Semantic MediaWiki 的一些东西的理解及操作。

== 安装 ==
首先，检查兼容性：
# mediawiki 版本
# php 版本
# mbstring 是否安装
# pcre 版本
# mysql 版本
# elasticsearch 版本

其次，使用 composer 安装，在 mediawiki/composer.local.json 中添加以下：
<pre>
{
	"require": {
                  "mediawiki/semantic-media-wiki": "~5.0"
        }
}
</pre>

<syntaxhighlight lang="bash" line>
# 在 /var/lib/mediawiki 目录安装且更新数据库
composer update --no-dev
</syntaxhighlight>

<syntaxhighlight lang="bash" line>
# 去 LocalSetting.php 添加：
wfLoadExtension( 'SemanticMediaWiki' );
enableSemantics( 'example.org' );
</syntaxhighlight>

<syntaxhighlight lang="bash" line>
sudo php maintenance/update.php
</syntaxhighlight>

== 脚本 ==
; disposeOutdatedEntities.php
: 翻译：处理并删除已过期的实体
: 说明：在 SMW 中，如果某些实体（如属性或概念）因版本升级或配置变更已失效，这个脚本会将它们清理掉，避免数据库中留存陈旧数据。

; dumpRDF.php
: 翻译：导出现有三元组为 RDF 格式
: 说明：把数据库中存储的所有语义三元组（Subject–Predicate–Object）输出为标准的 RDF 文件，方便与其它工具或语义网平台交换数据。

; populateHashField.php
: 翻译：批量填充 “smw_hash” 数据库字段
: 说明：在从旧版本升级到 SMW 3.0.1+ 时，用于一次性为所有实体生成并写入哈希值字段，加快后续的数据比较和查找。

; purgeEntityCache.php
: 翻译：一次性清空所有实体相关的缓存条目
: 说明：不仅清除页面缓存，还会删除那些与实体（概念、属性）关联的各种缓存，使下一次访问从头重建数据，常用于调试或重大配置变更后。

; rebuildConceptCache.php
: 翻译：重建概念（分类）缓存
: 说明：针对 SMW 概念（即分类）生成或更新其在页面侧的缓存视图，确保分类展示或查询结果与底层数据一致。

; rebuildData.php
: 翻译：重建所有语义数据
: 说明：根据你选定的数据存储后端（如默认存储或 Elasticsearch），重新解析所有页面上的语义注释，生成最新的存储索引，适用于大规模更新后。

; rebuildElasticIndex.php
: 翻译：重建 Elasticsearch 索引
: 说明：当你使用 Elasticsearch 作为 SMW 后端时，此脚本会重新创建搜索索引，确保引擎中包含所有最新的实体文档。

; rebuildElasticMissingDocuments.php
: 翻译：查找并补建 Elasticsearch 中缺失的文档
: 说明：扫描索引与数据库差异，对于 Elasticsearch 中漏掉的实体，自动调度更新任务，将它们重新加入索引，防止查询遗漏。

; rebuildFulltextSearchTable.php
: 翻译：重建全文搜索数据表
: 说明：如果你开启了 SMW 的全文检索功能，这个脚本会清空并重建用于全文搜索的专用表，保证搜索内容的完整与准确。

; rebuildPropertyStatistics.php
: 翻译：重建属性使用统计信息
: 说明：统计各语义属性在整个 wiki 中出现的次数，并将结果缓存下来，以便在 Special:Statistics 或其他报表页面中快速展示。

; removeDuplicateEntities.php
: 翻译：删除未被其他表引用的重复实体
: 说明：在长期使用中可能会产生多余、重复的实体记录，此脚本会识别那些孤立无用的实体并将其从主实体表中移除，节省存储空间。

; runImport.php
: 翻译：从导入文件批量导入内容
: 说明：配合 SMW 的导出/备份功能使用，可以将提前准备好的语义数据文件一次性导入到当前 wiki 中。

; setupStore.php
: 翻译：初始化或重置数据存储后端
: 说明：用于安装新站或更换存储方案时，一键创建或更新数据库表结构与索引，保障所选存储后端（MySQL、Elasticsearch 等）与 SMW 版本兼容。

; updateEntityCollation.php
: 翻译：批量更新 “smw_sort” 排序字段的字符集／校对规则
: 说明：当你修改了实体存储表的字符集或校对规则（collation）设置后，运行此脚本可让所有已有实体的排序字段重新生成，避免排序异常。

; updateEntityCountMap.php
: 翻译：批量填充 “smw_countmap” 计数字段
: 说明：在升级到 SMW 3.2+ 后，新增了存储实体引用计数的字段，本脚本会一次性为所有实体计算并写入引用次数，以支持统计功能。

; updateQueryDependencies.php
: 翻译：更新所有包含嵌入式查询的实体
: 说明：当实体页面中包含 #ask 等嵌入式查询时，修改了查询逻辑或模板后，运行此脚本可触发重新处理，保证页内查询结果与最新定义一致。

== 生态 ==

以下对 Semantic MediaWiki（SMW）相关扩展按功能类别进行归纳说明，每个小节说明扩展的用途、使用场景、主要解决的问题，并辅以简单示例。

SMW 核心提供了在 MediaWiki 上存储及查询结构化数据的能力，而这些扩展则在此基础上：添加/修改数据、可视化展示、扩展存储能力、与三元存储交互、监控变化、导入外部数据及提供各种工具。它们解决了从表单输入、层次组织、数据可视化、引文管理、跨语言链接到外部数据集成等一系列需求，帮助构建功能丰富的语义知识库。

=== 添加与修改数据 ===

==== Cognitive Process Designer ====

用途：通过界面创建、导入、导出和注释 BPMN（业务流程模型与符号）流程。

场景：团队需在 wiki 内记录和共享标准化业务流程，例如审批或采购流程。

解决问题：无需外部建模工具，即可在 wiki 中直观地管理流程模型及版本。

示例：财务部门使用该扩展在 wiki 上绘制并注释“报销审批”流程图，方便新同事学习。

==== HierarchyBuilder ====

用途：定义并维护页面间的层级结构，可将该层级作为表单输入类型。

场景：需要组织并呈现人员架构或组织结构图时。

解决问题：避免手动维护多重子页面或复杂模板，通过语义属性动态生成层次视图。

示例：HR 在 wiki 中用该扩展建立公司部门树状图，并在员工档案表单中作为“所属部门”下拉项。

==== Semantic Forms（Page Forms） ====

用途：基于模板字段自动生成页面创建/编辑表单。

场景：任何希望用表单代替手动填写模板参数的场景，如产品信息录入。

解决问题：规范数据录入格式，降低模板编辑出错率，提高用户体验。

示例：技术团队为“服务器配置”页面创建表单，输入 CPU、内存和存储等字段即可完成页面创建。

==== Semantic Forms Select ====

用途：在 Page Forms 中生成可动态获取值的下拉选择项。

场景：当表单选项源自已有的语义查询结果，如从已定义的“项目列表”中选项目。

解决问题：避免手动维护下拉选项，自动与语义数据保持一致。

示例：在“任务分配”表单中，下拉框实时列出所有“活跃项目”供选择。

==== Semantic Glossary ====

用途：定义术语和缩略词及其解释，鼠标悬停时显示定义。

场景：技术文档或百科类内容中，频繁出现专业术语需即时查看释义。

解决问题：无需额外跳转，提升阅读连贯性和学习效率。

示例：在生物学相关条目中，将“蛋白质组学”添加至术语表，悬停即可显示简介。

==== Semantic Organization ====

用途：提供可配置的组织结构模板，比如人员、任务等信息。

场景：企业内部管理人员档案、任务分配及部门信息时。

解决问题：通过标准化模板和语义字段，统一展示与查询组织信息。

示例：使用该扩展创建“员工信息”模板，包含姓名、职位、联系方式等属性。

=== 展示数据 ===

==== Semantic Result Formats ====

用途：为 #ask 查询提供大量可视化结果格式，如日历、时间轴、图表等。

场景：需要将查询结果按日历展示项目进度，或用图表展示统计数据。

解决问题：无需自定义前端组件，即可在 wiki 内生成丰富多样的可视化输出。

示例：用日历格式显示“会议安排”查询结果，按日期高亮标注。

==== Maps ====

用途：利用 Google Maps、OpenLayers、Leaflet 等服务在地图上显示地理坐标数据。

场景：项目管理、事件分布可视化，或地点型内容（旅游、门店）展示。

解决问题：与语义坐标结合，自动在地图上标出相关页面对应的位置。

示例：在“野生动物观察”页面，用地图展示所有记录了坐标的观察点。

==== Semantic Compound Queries ====

用途：通过 #compound_query 同时展示多个语义查询结果。

场景：需在同一页面并列显示不同类型的数据，如同时展示在线用户和最近编辑。

解决问题：避免多次嵌套调用 #ask，统一筛选和布局。

示例：在“仪表盘”页面同时列出“高优先级任务”和“即将到期事件”。

==== Semantic Drilldown ====

用途：提供基于分类和属性过滤的分面导航（faceted browser）。

场景：面对大量条目，需要按属性快速缩小结果集时。

解决问题：无需外部框架，即可在 wiki 内实现多维度数据筛选。

示例：在“图书目录”页面，按“作者”“出版年份”“主题”逐层过滤。

==== Technology Portfolio ====

用途：为 #ask 查询添加“投资组合”式的可视化格式。

场景：IT 资产管理或技术成熟度评估时，以矩阵形式展示项目布局。

解决问题：直观体现不同项目在各象限（如风险/收益）中的分布。

示例：在“产品路线”页面，用组合图显示各产品的成熟度与市场潜力。

==== Technology Radar ====

用途：为 #ask 查询添加“雷达图”式可视化格式。

场景：展示技术趋势或能力评估雷达图形。

解决问题：一览多维度指标，便于比较与决策。

示例：在“技能矩阵”页面，用雷达图展示团队在不同技术栈上的能力。

=== 存储附加数据 ===

==== Semantic Cite ====

用途：定义 #scite 解析函数，用于生成引用脚注并将引用信息以语义属性存储。

场景：学术或文档项目中，需要同时显示脚注和后续查询引用统计。

解决问题：引用管理与语义查询结合，支持“被引用次数”等统计。

示例：在技术文档中调用 #scite，同时生成带元数据的参考列表，可通过查询列出所有引用该文档的页面。

==== Semantic Interlanguage Links ====

用途：定义跨语言页面间链接的解析函数，存储并查询不同语言对应关系。

场景：多语言文档维护，需要在不同语言版本间互链。

解决问题：区别于 Translate 扩展，支持在不同页面之间的语义链接管理。

示例：在英文条目中使用 <nowiki>{{interlanguagelink:fr|PageName}}</nowiki>，自动记录并展示法文对应页面。

==== Semantic Internal Objects ====

用途：提供 #set_internal 等函数，实现“子对象”（n 元关系）语义存储。

场景：一条页面需存储多组同类属性，如课程及其多个授课时间。

解决问题：标准属性只能一对多，子对象支持多对多复合数据建模。

示例：在“会议”页面内，分别记录多场分会的信息（名称、时间、地点）。

==== Semantic Extra Special Properties ====

用途：为所有页面添加额外的特殊属性，如“贡献用户”“首创用户”“当前修订 ID”等。

场景：需要对页面元信息做查询或展示。

解决问题：无需自定义维护，即可在查询中使用丰富的内置页眉属性。

示例：通过内置属性查询列出“本月新创建页面”及其创建者。

=== 通过 RDF 三元存储存储数据 ===

==== LinkedWiki ====

用途：连接到外部 RDF 三元存储（如 4store），并可在 wiki 内发起 SPARQL 查询。

场景：需要与 Wikidata 或其他 SPARQL 端点集成时。

解决问题：突破 SMW 内部存储，直接在 wiki 中消费和呈现任意三元存储数据。

示例：在页面中直接用 SPARQL 查询 Wikidata，显示某地标的坐标和简介。

==== SPARQL Result format ====

用途：对接不同 SPARQL 端点并以多种格式呈现查询结果。

场景：跨域整合语义数据并在 wiki 中直观展示。

解决问题：免去手动解析 JSON/XML，自动格式化 SPARQL 输出。

=== 监控与工作流 ===

==== Semantic Watchlist ====

用途：为语义属性变化设置专属监视列表，并可分组、通过邮件通知。

场景：关注关键数据属性（如库存、状态）变动的项目管理。

解决问题：传统 watchlist 仅监视页面，无法聚焦属性级别的变化。

示例：财务人员监控“预算剩余”属性，一旦修改即收到邮件提醒。

=== 导入外部数据 ===

==== External Data ====

用途：从外部 URL、数据库、LDAP、SOAP/REST 服务或文件中检索、过滤并格式化数据到 wiki。

场景：需要将 ERP、CRM 等系统数据实时展示在 wiki 页面。

解决问题：无需中间脚本，直接在 wiki 内调用外部接口并可选存储为语义属性。

示例：在“销售报表”页面，实时拉取公司 CRM 系统的月度销售额并生成表格。

=== 工具类扩展 ===

以下扩展多为辅助开发或集成工具，常在大型部署或与第三方系统对接时使用：

==== PhpTags SMW ====

可在 PHPTags 中查询和修改 SMW 数据。

==== Semantic Breadcrumb Links ====

基于语义属性动态生成面包屑导航。

==== Semantic Dependency Updater ====

监控页面语义数据变化并自动更新依赖页面（null-edit）。

==== Semantic Dependency ====

定义页面间语义依赖关系，当被依赖页面数据变化时触发更新。

==== Semantic Meta Tags ====

根据语义属性生成 HTML <meta> 标签，便于 SEO 和社交平台分享。

==== Semantic Scribunto ====

在 Scribunto 模块中原生支持 SMW 数据访问。

==== SMWConnector ====

BlueSpice 与 SMW 之间的核心接口，用于集成与扩展。

==== Title Icon ====

为页面名称旁添加图标，提升列表或分类视图的可视化效果。