Why do i give up semantic mediawiki

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

原因

我放弃 Semantic MediaWiki 的原因有以下：

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

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

理解

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

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

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

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

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

安装

首先，检查兼容性：

1. mediawiki 版本
2. php 版本
3. mbstring 是否安装
4. pcre 版本
5. mysql 版本
6. elasticsearch 版本

其次，使用 composer 安装，在 mediawiki/composer.local.json 中添加以下：

{
	"require": {
                  "mediawiki/semantic-media-wiki": "~5.0"
        }
}

最后，安装且更新数据库：

# 去 LocalSetting.php 添加：
wfLoadExtension( 'SemanticMediaWiki' );
enableSemantics( 'example.org' );
composer update --no-dev
php maintenance/update.php

脚本

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 扩展，支持在不同页面之间的语义链接管理。

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

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

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