NeoWiki vs Wikibase

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 (several subjects per page, or one page per subject), 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.

NeoWiki

Authoring

Schema-driven forms and REST API

Storage

Versioned JSON on pages, optionally projected to graph databases

Query

Cypher or SPARQL

Any SPARQL store, including QLever and Oxigraph

Wikibase

Authoring

Statement editor on Item pages

Storage

JSON entities on Item pages

Query

SPARQL via WDQS

Blazegraph today, QLever migration in flight

MediaWiki

Shared foundation

	NeoWiki	Wikibase
Storage	Structured JSON in MediaWiki revision slots.	JSON entities: statements, qualifiers, and references.
Schemas	Native schemas with types, constraints, and defaults.	Property constraints and EntitySchema (ShEx). Both advisory.
Authoring	Form-based editing derived from your schema.	Bespoke entity editor, one statement at a time.
Page model	On regular wiki pages, or one Subject per page in subject-first mode.	Items live in a dedicated namespace, separate from wiki pages.
Query	Cypher or SPARQL over a graph database.	SPARQL via WDQS. Blazegraph today, QLever migration in flight.
Display	Display UIs ship built-in. Built-in displays for query results are on the roadmap.	Build the read-side via Lua, templates, or external apps.

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.

Wikibase

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)
}

CypherSPARQL

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. Wikibase statements don't auto-translate to property-graph nodes and relationships, though the page model lines up: in subject-first mode an item maps to one subject with its own page. How qualifiers, references, and rank translate is worked through in Qualifiers and References. 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 and display UIs. Wikibase wins when you feed into Wikidata, when you need its tooling ecosystem, or when you federate across Wikibase instances. NeoWiki wins when authoring needs to be form-driven or when display should ship without custom Lua.

Items, or pages.

Same question, different defaults.

Talk to us about migration Try the sandbox