How to Use the Semantic MediaWiki Extension for Structured Data

Semantic MediaWiki succeeds or fails on one habit: annotations must go through templates, not inline. This article is the working pattern — typed properties, template-driven data entry, #ask reporting — with the performance rules that keep SMW fast. (Installation and basic query syntax are covered in the companion guide on this blog; this one is about patterns.)

1. The template as the contract

Inline annotations ([[Property::Value]] scattered through prose) rot quickly: inconsistent fields, mixed data types, annotations that survive deletion. The maintainable version concentrates annotation in the record template:

<includeonly>
[[Category:Books]]
[[Has title::{{{title|{{PAGENAME}}}}}]]
[[Has author::{{{author|}}}]]
[[Has publication year::{{{year|}}}]]
</includeonly>

The form (via Page Forms) writes into the template's parameters; the template outputs the annotations. Every page of that type then has exactly the same property set, and queries can rely on it.

2. Type your properties

A property page (Property:Has publication year) declaring [[Has type::Number]] enables range comparisons and validation. The types in regular use:

• Page — references to other pages (authors, projects)
• Number, Date, Boolean — queryable scalars
• Text/String — display-only values
• Geographic coordinate — map output via Semantic Result Formats

Un-typed properties work but compare lexically; typing is what makes #ask comparisons ('year > 2000') trustworthy.

3. Reports with #ask

Books by F. Scott Fitzgerald:
{{#ask: [[Category:Books]] [[Has author::F. Scott Fitzgerald]]
 |?Has publication year
 |sort=Has publication year
 |order=asc
 |format=table
}}

Output formats that pull weight:

• format=table / broadtable — the default reports
• format=count — dashboard numbers ('X open tickets')
• format=list/ul/ol — inline link lists
• format=json/csv — data hand-off (with Semantic Result Formats)
• format=map (with openlayers/googlemaps formats) — geodata

Reports belong in dedicated pages or templates, not scattered across articles — one query per purpose, reused by transclusion.

4. Query performance rules

• Constrain by category — every #ask should start from a category or property instead of scanning the wiki
• Limit output — limit=20 on user-facing tables; the global cap ($smwgQMaxLimit, default 10000) is a safety net, not a style
• Cache hot queries — SMW result caching is on by default; raise the lifetime ($smwgQueryResultCacheLifetime) for expensive report pages
• Watch the query log — Special:SemanticMediaWiki and the profiling output show slow queries; refactor the bad ones (usually a missing constraint or format misuse)

5. The pattern in one paragraph

Type the properties, bind them to templates, enter data through forms, and query through #ask pages. That is the entire recipe. The failure modes — untamed annotations, untyped properties, query tables on every article — all come from skipping one of those four steps. SMW documentation (semantic-mediawiki.org) is exhaustive; the pattern above is the part that keeps the wiki usable at scale.