Form-based collaborative editing
Your team works in forms generated from your Schemas: typed fields, dropdowns, and pickers for the links between Subjects. The Schema's constraints are checked as they edit, so structure holds at the point of entry. No syntax to learn.
Structured records and prose share the page: same diffs, same change notifications, same review workflows. One record can describe several related entities, such as a project, its team, and a recent milestone, without losing the boundaries between them.
Work page-first, with structured records beside the prose that explains them, or subject-first, where each record stands on its own and nobody has to think in pages. One setting switches the wiki; everything else stays the same.
Schemas as a contract
A Subject is a structured entity, such as a person or a product. Each Schema defines one Subject type: its fields, their types, constraints, and defaults. Constraints are checked wherever data is written, by people, scripts, or AI agents, and you choose per constraint whether a violation blocks the save or just flags it.
Schemas evolve without migrations. When a Schema changes, past edits keep their original meaning: a new constraint flags older data instead of rewriting it. Schema edits are tracked and reversible, like any other change.
Graph databases, queried in standard languages
Your structured data lives on the page and is mirrored into graph databases as you edit. The graph is the right shape for questions about how things connect: who's connected to whom, what depends on what, what's reachable from where.
Query it in Cypher (the language behind ISO GQL) on Neo4j, or in SPARQL (the W3C standard) on any SPARQL 1.1 store, such as QLever, Oxigraph, or Fuseki. Run several at once, each with its own projection of the same data.
If you don't need graph queries, NeoWiki runs without any graph database.
MATCH (c:Company)
WHERE c.`Founded at` > 2010
RETURN c.name, c.`Founded at`
ORDER BY c.`Founded at` DESCProvenance and governance
Every structured-data edit is versioned and attributed: who changed what, when. Subjects and Relations have stable identifiers, so references survive renames and moves.
You set read and edit permissions per page, and so per Subject when each Subject has its own page.
On the roadmap: rights statements and chain-of-production tracking for cultural-heritage publishing.
AI-ready by construction
Your AI grounds on the same substrate your editors maintain: Schemas, validation, revision history, the graph itself.
Graph queries give your AI connected records, not paragraph chunks.
AI agents use the same write paths as human editors, and can check a change against the Schema before writing it. Whatever review workflows you've configured apply to them: live immediately by default, or held for approval on the page. Approval that also holds their edits back from queries and APIs is on the roadmap.
Bring your own AI: the MediaWiki MCP server connects any MCP client to your Subjects, Schemas, and queries.
Federated and standards-aware
Your data exports as RDF without any mapping, and every Subject has a dereferenceable URI, so it is linked data as soon as you publish it. RDF import is on the roadmap.
Project your data to the ontologies of your choice, such as CIDOC-CRM or EDM, and to several at once. A Mapping reshapes the data where the target ontology demands it, so what comes out is that ontology, not your internal model under new names. That is what makes your data interoperable with partner systems, without modelling the wiki around them.
Wikis in one farm share a graph, so a single query reaches across them while each wiki keeps its own data. Querying across institutions and importing data from Wikibase and Wikidata are on the roadmap.
You can record text values in several languages, each exported with its language tag.
Power without engineering tickets
Your team builds custom, data-driven pages directly in NeoWiki.
Layouts control how each Subject type displays: which properties show, in what order, with what formatting, no code required. A scripting layer goes further: it reads your structured data, runs queries, and renders the results inline on any page.
Under the hood, that scripting layer is MediaWiki's templates, Lua, and parser functions, now able to read Subjects and run Cypher and SPARQL. Existing templates and Lua modules keep working.
Yours to build on
A REST API, described in OpenAPI, covers reading and writing Subjects, reading Schemas, validation, queries, and RDF export. Bulk import is on the roadmap.
Extension points cover custom Property Types and View Types, external Subject sources, approval workflows, and additional graph stores. Extensions can reuse NeoWiki's frontend components.
GET /rest.php/neowiki/v0/subject/s1abc5def6ghi78
GET /rest.php/neowiki/v0/schema/Company
POST /rest.php/neowiki/v0/query/cypherSovereign by design
Your data stays yours: no telemetry, no third-party services. Standards-based exports (RDF, JSON, MediaWiki XML) mean no lock-in.
NeoWiki is open source on GitHub under the GPL. Host it yourself, or use our managed NeoWiki Hosting.