01. Structured collaborative editing
Authoring is collaborative MediaWiki: the version history, watchlist, and review workflow your editors already know. Statements live in a dedicated revision slot as JSON, captured by form-based editors derived from the schema, not by guess-the-template magic. A page can carry one Main Subject and any number of Child Subjects (ADR 7), so you can describe a city, a population statistic, and a population update on one page without losing the boundary between them.
The page is still wikitext. Templates, links, parser functions, talk pages, and discussion all keep working. The structured data sits in its own slot beside the prose, in a format you can read and version, not in a parallel database that breaks when the wiki gets edited around it.
02. Schemas as a first-class concept
Every Subject has a Schema: a named type, a list of Property Definitions, types and constraints. Schemas are stored as JSON (SchemaFormat), edited through dedicated forms, and validated server-side. Every property declares its type once, the editor follows, the API enforces it.
Property types are a plugin: text, URL, number, select with stable IDs, relations to other Subjects. Constraints (minimum, maximum, required, uniqueItems) and display defaults (precision, format) live with the definition, not with the page that happens to use it. A schema change is a discrete edit with a revision history, not an emergent reshuffling of conventions.
{
"description": "A business entity",
"propertyDefinitions": {
"Founded at": { "type": "number" },
"Websites": { "type": "url", "multiple": true },
"Status": {
"type": "select",
"options": [
{ "id": "opt_active", "label": "Active" },
{ "id": "opt_acquired", "label": "Acquired" }
],
"required": true
},
"Has product": {
"type": "relation",
"relation": "Has product",
"targetSchema": "Product",
"multiple": true
}
}
}03. A real graph database
The structured data on every page is projected into a graph database as a query-optimized secondary store. Pages become :Page nodes; Subjects become :Subject nodes labelled with their Schema; Statements become node properties; Relations become typed edges with stable IDs. The MediaWiki revision slot stays the source of truth, the graph stays in sync.
The graph is for the questions traversal is the right shape for: shortest paths, connected components, multi-hop joins, breadth-first walks. The kinds of questions a relational store fights you on. Neo4j is the default; the architecture is pluggable, and the API does not invent a proprietary query abstraction over it.
04. Native query languages
Cypher is exposed today through the parser function and the Lua API; SPARQL via QLever is the planned second surface. Both are languages people learn once and use elsewhere; neither is invented for NeoWiki. The lesson from twenty years of #ask, taken seriously: a wiki-specific query DSL becomes its own maintenance burden, and the people you want querying your data already know the standard ones.
MATCH (c:Company)
WHERE c.`Founded at` > 2010
RETURN c.name, c.`Founded at`
ORDER BY c.`Founded at` DESC05. Federated, standards-aware
NeoWiki speaks RDF where the standards already live: cultural heritage on CIDOC-CRM and Dublin Core, library catalogues on MARC and BIBFRAME, and the wider linked-open-data cloud through equivalence mappings. Properties are local by default, with a mapping layer that aligns local Schemas to standard vocabularies on export. Wikidata and Wikibase remain peers; data flows in and out through declared mappings, not through a single hard-coded conversion.
Federation matters because no institution holds all the relevant knowledge. Round-tripping with Wikidata, with partner archives, with Europeana and the European Collaborative Cloud for Cultural Heritage is what makes the data work in the world it lives in.
06. AI-Ready by construction
Generative models are fluent and unreliable. The fix is grounding: the model retrieves from a structured, governed knowledge source before it speaks. NeoWiki is that source, by construction. Schemas mean the data has shape; revisions mean the data has provenance; the graph means the data is queryable, traversable, and citable in subgraphs rather than paragraphs.
The AI surface is built on the same structured layer humans edit, not on a separate vector index that drifts. A retrieval-augmented agent reads through the same Cypher and SPARQL endpoints; an editing agent writes through a preview framework that shows the resulting changes before applying them. NeoWiki ships the open-source preview and execution surface; commercial AI assistants plug in.
{{#cypher_raw:
MATCH (c:Company)-[:`Has product`]->(p)
RETURN c.name, p.name LIMIT 10
}}07. Provenance and governance
Every fact has a writer's schema (ADR 11): the type the property had when the value was written, kept on the Statement so a later schema change does not silently re-interpret old data. Every page has a revision history, every editor has an attribution, every category is queryable.
Backend validation is not optional: the API rejects writes that violate the Schema before they reach storage. Required fields, ranges, enumerations, target Schemas for relations, all enforced at the boundary the AI agents and the import scripts go through, not just at the form layer. Subject and Relation IDs are stable nanoid identifiers that survive renames and moves.
08. MediaWiki under it, not bolted on
NeoWiki is a MediaWiki extension. The wiki you may already run keeps its skin, its login, its watchlist, its talk pages, and the extensions you have come to depend on. Editor communities transfer. Institutional muscle memory transfers. URL stability and SEO transfer. The structured data layer is the addition, not the replacement.
This is also a hedge against platform risk. MediaWiki's installed base, governance, and extension ecosystem are durable; the institution is not betting on a startup's roadmap as the foundation of its knowledge work.
09. Open surfaces and extensibility
Three programmatic surfaces are live today: a REST API for Subjects, Schemas, and Statements; the mw.neowiki Lua library for schema introspection and Cypher queries inside templates; and the parser functions for inline values, rendered Subject views, and raw Cypher results.
View Types and Property Types both register as plugins, so an extension can add a new way to render a Subject (infobox, card, table, anything you build) or a new property kind (coordinate, currency, a sector-specific value type) without forking the core.
GET /rest.php/neowiki/v0/subject/s1abc5def6ghi78
GET /rest.php/neowiki/v0/schema/Companylocal nw = require('mw.neowiki')
nw.getValue('Founded at', { page = 'ACME Inc' })
nw.query('MATCH (c:Company) RETURN c.name LIMIT 5')10. Sovereign by design
NeoWiki is open source and runs on infrastructure you own. No data leaves the wiki for a hosted service, no vendor's lifecycle dictates yours, no backend pulls usage logs. EU-friendly by default, BFSG-aware on the surfaces that matter, CIDOC-CRM and FAIR principles by design.
Sovereign is also a posture about AI. Knowledge that grounds your AI agents stays in your wiki, under your editorial control, with the lineage every claim depends on. The model is a renter; the wiki is the owner.