NeoWiki
Get a demo
NeoWiki

Compare

NeoWiki vs Wikibase

Both are real structured data on top of MediaWiki. The difference is what shape the data takes, where it lives, and what you build on top versus what ships.

Wikibase is the data layer behind Wikidata. It has spent more than a decade making the case that structured knowledge belongs in items, expressed as RDF, with statements, qualifiers, and references. NeoWiki picks different commitments at the same layer of the stack: structured data attached to regular wiki pages, a property graph instead of triples, native schemas that drive form-based editing, and display UIs that ship by default. The two answer the same question with different defaults.

Where the work lives

Both extend the same MediaWiki underneath. The commitment difference shows up in the three layers above it: how authors put structure in, where that structure lives, and how it comes back out.

Wikibase

Authoring

Item editor (Item: namespace)

Storage

RDF triples + qualifiers

Query

SPARQL via WDQS

Blazegraph today, QLever migration in flight

NeoWiki

Authoring

Schema-driven forms (in revision slots)

Storage

Graph database

Query

Cypher

SPARQL via QLever, planned

MediaWiki

Shared foundation

WikibaseNeoWiki
Storage RDF triples: subject, statements, qualifiers, and references. Structured JSON in MediaWiki revision slots.
Schemas Property constraints and EntitySchema (ShEx). Both advisory. Native schemas with types, constraints, and defaults.
AuthoringBespoke entity editor, one statement at a time.Form-based editing derived from your schema.
Page model Items live in a dedicated namespace, separate from wiki pages. Structured data attached to regular MediaWiki pages.
Query SPARQL via WDQS. Blazegraph today, QLever migration in flight. Cypher over a graph database. SPARQL via QLever, planned.
Display Build the read-side via Lua, templates, or external apps. Display UIs ship built-in. Query results render inline on pages.
AI groundingNot built in.GraphRAG endpoint by construction.

Same question, different mechanics

Find every person born after 1900, with their birth year and field. Both wikis can do it. The shape of the answer is what differs.

sparql
SELECT ?person ?birth ?field WHERE {
  ?person wdt:P31 wd:Q5 ;       # instance of human
          wdt:P569 ?birth ;     # date of birth
          wdt:P101 ?field .     # field of work
  FILTER(?birth > "1900-01-01"^^xsd:date)
}
cypher
MATCH (p:Person)
WHERE p.birthDate > date('1900-01-01')
RETURN p, p.birthDate, p.field
sparql
SELECT ?person ?born ?field
WHERE {
  ?person a :Person ;
          :birthDate ?born ;
          :field ?field .
  FILTER(?born > "1900-01-01"^^xsd:date)
}

If you're already on Wikibase

NeoWiki and Wikibase have genuinely different data models. RDF triples don't auto-translate to property-graph nodes and relationships, and the page model differs: Wikibase items don't map one-to-one to NeoWiki pages with revision slots. Migration is a scoping conversation. We look at your item structure, your SPARQL patterns, the federation graph you depend on, and shape the path.

If you are choosing between the two for a new project, the trade is between Wikibase's federation gravity and RDF-native ergonomics, and NeoWiki's defaults: schema-driven forms, display UIs, inline queries, and GraphRAG by construction. Wikibase wins when you feed into Wikidata, when RDF is a hard requirement, or when items-in-a-namespace fits the data better than pages. NeoWiki wins when authoring needs to be form-driven, when display and inline queries should ship without custom Lua, or when AI grounding is primary.

Items, or pages.

Same question, different defaults.

Talk to us about migrationTry the sandbox