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.
A graph database, queried in standard languages
Your structured data lives on the page and is mirrored into a graph database 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) or SPARQL (the W3C standard).
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.
Read and edit permissions are set 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.
GraphRAG-style retrieval returns subgraphs, 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.
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 it is published. RDF import is on the roadmap.
Project your data to the ontologies of your choice, such as CIDOC-CRM, EDM, or Linked Art, 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 aggregators and partner systems such as Europeana, 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.
Multilingual data values are in progress.
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.