Semantic MediaWiki: turning a MediaWiki install into a queryable knowledge base

An extension first, a framework second

Semantic MediaWiki, abbreviated SMW, is a free, open-source extension to MediaWiki that lets you store and query data within the wiki's pages. The description is a good deal more specific than the usual wiki plugin language, because SMW does not just tag pages with categories and templates. It stores typed properties, records them, and answers queries over them. The README also positions it as a full-fledged framework with many spinoff extensions that can turn a wiki into a knowledge management system, and it adds that all data created within SMW can be published via the Semantic Web so other systems can use it. The two audiences are therefore different. One is an organisation that has a MediaWiki and wants the pages inside it to carry machine-readable data, with a query interface for editors and an export path for other systems. The other is a developer who wants to extend a wiki with the ecosystem of extensions that grew around SMW rather than build a separate application. The requirement is simply MediaWiki and its dependencies, such as PHP, with supported versions listed in a compatibility matrix in the repository.

Installation is a Composer step, and the docs come in two layers

The recommended installation path is Composer, and the README points to a detailed installation guide in the repository and to a separate compatibility document for version support. That is a small amount of instruction for something that changes how a wiki stores data, and the reason is the second documentation layer. Most of the documentation lives on the Semantic MediaWiki wiki, but a small core of documentation is bundled with the software itself. The README is candid that this bundled documentation is minimalistic and less explanatory than what is on the wiki, but it is always kept up to date and applies to the version of the code it ships with. The bundled documents are the user documentation, the technical documentation, and a hacking guide under the architecture directory, so a developer working on the extension has a version-matched reference even when the site documentation is ahead of the release. The same division applies to support. The user mailing list handles user questions, the chatroom handles both user and developer discussion, and the issue tracker on GitHub is for bug reports.

Cloning needs --recursive because the test harness is a submodule

The repository carries submodules, and the README flags this with an explicit note for anyone who cloned it wrong. The repository contains submodules, so it must be cloned with the --recursive option in Git, and if that was not done at clone time it can be fixed afterwards. The commands are git submodule init followed by git submodule update, and the note points out that the fix is available when the recursive clone was not used at clone time.

The submodule matters because the CI harness is not fetched at build time. The docker-compose-ci repository, which provides docker-compose-ci based CI and testing for MediaWiki extensions, has already been integrated into the Semantic MediaWiki repository as a Git submodule, and it uses Make as its main entry point and command line interface. The Makefile in the repository root reflects that arrangement. It checks whether the build directory exists, and if it does not, it runs a shell command to update the submodule before including build/Makefile. So the CI setup is versioned alongside the extension rather than pinned to whatever the upstream project has at the moment you run it. The same Makefile also carries the environment the tests expect, with MW_VERSION set to 1.43, PHP_VERSION set to 8.1, DB_TYPE set to mysql, and DB_IMAGE quoted as mariadb:11.2, plus toggles for Composer and Node.js behaviour.

The test path is make ci, backed by a container stack

The testing instructions are structured as three steps, and the first is cloning the repository recursively, which the previous section covers. The second is ensuring the test container is running, which needs Make and Docker on the machine:

make --version
docker --version

The third step runs lint, the code style check and the tests in one command:

make ci

The overall shape is a containerised CI in a box rather than a test suite you run against an installed wiki. The docker-compose-ci project spins up the MediaWiki instance, the database and the PHP environment, and the Makefile's variables are what select the versions. The PHP version and the database image are both overridable, and the DB_TYPE default of mysql with the mariadb:11.2 image is a specific pairing worth knowing if you want to test against a different engine. There is a NODE_JS flag defaulting to true, which enables the Node.js related tests and the npm install step, and a COMPOSER_EXT flag doing the same for composer update inside the extension. The JavaScript side has its own runner. package.json defines a test script that calls node-qunit, which in turn runs qunit with a setup file against the tests/node-qunit test files, and a coverage variant that wraps the same run in nyc with text, html and clover reporters.

What the repository layout says about the extension's shape

The top-level entries describe a mature MediaWiki extension rather than a small script. The extension.json file registers the extension with MediaWiki, and the src/ directory holds the PHP source, with res/ for resources and templates/ for the server-side templates that render query results and forms. The data/ directory is where Semantic MediaWiki keeps its own structured data, and the maintenance/ directory holds the scripts that populate or repair that data, which is the part of a semantic extension that causes pain when it drifts. i18n/ carries the translation files. The testing side is split: phpunit.xml.dist for the PHP test configuration and the tests/ directory for the suites, alongside the Node.js tests referenced by package.json. The linting and static analysis configuration is visible too, with .phpcs.xml for the code style rules and a .phan/ directory for the static analyser, and .gitmodules at the root records the submodule wiring discussed earlier. The presence of SECURITY.md and publiccode.yml adds the usual governance files for a project used in production, and a separate build/ directory holds the vendored CI build definition.

Query and export are the point, the wiki is the interface

The repository's topic tags and description make the intent clear. Semantic MediaWiki turns MediaWiki into a knowledge management platform with query and export capabilities, and the project topics list query, result-format, sparql, rdf, linked-data and knowledge-graph alongside the mediawiki and database tags. That combination tells you the two access paths. Inside the wiki, editors get a query interface over the data they and their colleagues have annotated, which is what turns a wiki from a pile of pages into something you can ask questions of. Outside the wiki, the same data can be published so other systems can consume it, including through the Semantic Web route the README highlights. The triplestore angle appears in the project's own demonstration videos, where the README links a video covering the Sesame and Fuseki triplestore setup alongside the general introduction videos. The distinction between SMW and a dedicated graph database is the interesting comparison. A triple store is built to answer arbitrary graph queries fast. SMW answers queries over data that lives inside wiki pages and is written by editors in the normal editing flow, and its query language is tied to the wiki's own data model rather than to a general graph language. The trade is authoring convenience against query generality.

The licence is the GPL, and the version line moves quickly

Two licence artefacts sit side by side in the repository root. The README states that Semantic MediaWiki is released under the GNU General Public License, version 2 or later, and says the COPYING file explains SMW's copyright and licence. The repository's own metadata records the licence as a custom one that GitHub cannot classify, which is a common side effect of a licence file with a format the detector does not parse, and it is a reminder to read COPYING rather than trust an automated label. For a GPL licensed extension that means the copyleft terms travel with the code, so an organisation embedding it into a larger product has obligations to check rather than assume. On the release cadence, the listed versions are 7.3.1 on 2026-09-28, 7.3.0 on 2026-09-16 and 7.2.1 on 2026-08-19, and the last push to the repository was on 2026-10-19. Those numbers describe a project shipping point releases and then continuing work afterwards, which is the usual pattern for a MediaWiki extension that has to track core releases. The compatibility matrix in the repository is the document to read before an upgrade, since the supported MediaWiki and PHP versions are the constraint that decides whether a given release will work for you.

Editorial conclusion

Semantic MediaWiki suits organisations that already run MediaWiki and want their pages to carry structured, queryable data that can also be published to the Semantic Web, and it suits developers who want to extend a wiki with the spinoff extension ecosystem rather than build a separate application. It is the wrong choice if you do not already run MediaWiki, if your editors will not annotate pages, or if you need the query performance of a dedicated triple store. Verify first the MediaWiki and PHP versions allowed by the compatibility matrix, that your database type matches the one the test harness expects, and that you have read the bundled installation guide before upgrading an existing wiki.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SemanticMediaWiki/SemanticMediaWiki on GitHub