Introducing NeoWiki: Structured Data for MediaWiki

NeoWiki at a glance

At its core, NeoWiki lets you edit versioned structured data via forms. The forms are based on schemas, which you also create and edit via user-friendly UIs. You can query your data through graph databases. For example, you can list every active project a person leads, with its partners.

Subjects are your records, such as a person, a company, or a project. Each subject follows one schema.

Schemas define the shape of your data: property names, types, constraints, and defaults. Think of a Person schema, a Company schema, or a Project schema. Property types include text, numbers, dates, URLs, choice lists, text with a language tag, and relations to other subjects. The NeoWiki glossary explains these and other terms.

Forms let editors fill in typed fields with autocompletion and validation. If a related subject or schema doesn't exist yet, you create it on the spot, without leaving the form.

A page can hold several subjects. The Rijksmuseum page on our demo wiki carries the museum as its main subject, shown in an infobox. It also carries each year's attendance, with its visitor count and source, as a subject of its own. You edit those inside the museum's form. If you prefer one page per record, switch the wiki to subject-first mode.

Your wiki is the source of truth. Structured data is stored as JSON in a dedicated MediaWiki revision slot. Every change appears in the page history, with diffs and attribution. Approval flows work.

Standard query languages. NeoWiki projects your data into SPARQL 1.1 stores such as QLever, Oxigraph, and Fuseki, or into Neo4j for Cypher queries. You query from Lua modules or through the REST API.

Design principles

Usable without technical skills. You can view and edit your data and its schemas entirely through user-friendly interfaces, without ever seeing JSON, wikitext, or other technical plumbing. If you want to, you can still open the JSON and access your data through wikitext and Lua. The interface responds instantly as you work (reactive UI), one of many decisions that bring NeoWiki closer to tools like Notion and Airtable.

Your data stays yours. NeoWiki sends no telemetry and needs no third-party services. You can export your data as RDF, JSON, or MediaWiki XML, so you are not locked in.

Value over features. We focus on supporting the common use cases well rather than chasing every feature. In software, you often get over 90% of the value for less than 10% of the features. We explicitly do not aim for feature parity with existing solutions, be it those in the MediaWiki space or outside.

A solid foundation. Two things keep NeoWiki sustainable. The first is technical excellence: a well-thought-out architecture and automated tests. The second is simplicity: we build on popular existing tools such as QLever and Neo4j. This makes NeoWiki a solid foundation for continued innovation. The roadmap shows some of what can be built on top.

NeoWiki 0.1 Beta

From 0.1 on, every breaking change to stored data comes with a migration script or upgrade guide. It is still a beta, though: don't use it for a critical production system. Some capabilities you need might not be (fully) there yet (see the roadmap), and we're making changes rapidly.

The quickest way to play with NeoWiki is via the demo wiki at neowiki.dev. Before you can edit, create an account and confirm your email address.

You can install NeoWiki with Docker or add it to an existing MediaWiki (1.43 or later). The installation docs also cover the key settings.

Prefer not to run it yourself? We can host a pilot for you.

Recent progress

Much of what follows is new since our first public demo in March.

There is a new dashboard for your NeoWiki at Special:NeoWiki. Here you'll find recent changes to your data and links to other key overview pages, such as Special:Schemas and Special:Subjects, which list your schemas and subjects with controls to edit them.

You can now browse your data without having standard wiki content. Key components are the Special:Subjects list page, which supports search and filtering, and the Special:Subject page, which shows a single subject together with a list of referencing subjects (incoming links). For people with a Wikibase-like use case, such as an authority file or a controlled vocabulary, we've added subject-first mode, which makes your wiki data-centric instead of page-centric, so you can work without having to think about wiki pages.

You can now configure your NeoWiki via an on-wiki page. The configuration is stored in JSON, with changes visible and revertible in the page history. We also added a UI on top so you don't have to deal with the JSON directly. If you would rather not allow on-wiki configuration, you can turn it off in LocalSettings.php.

Schema import and export UIs. While you could already export and import schemas (and subjects, mappings, layouts, etc.) via the APIs and standard MediaWiki mechanisms, you can now also use a convenient export and import UI on Special:Schemas.

Configurable data display. NeoWiki's core gives you control over how values are rendered, for instance, via the precision attribute on number property definitions. We created an extensible view system that lets you choose whether to show a subject as an infobox, as a card, or in some other way. You can define layouts that specify which properties to show, override display attributes (e.g., numbers with a different precision), and customize the view (e.g., the border color of an infobox). While the foundations are there, some UIs are still missing and are on our roadmap.

Linked open data comes from ontology mappings, which project your own schemas onto a standard ontology in RDF exports and SPARQL stores. On the demo wiki, Pablo Picasso is an ordinary Person page. The mapping to the Europeana Data Model (EDM) exports him as an edm:Agent and his birthplace, Málaga, as an edm:Place. The CIDOC-CRM mapping models his birth as an event. One store can hold your native data and its EDM projection side by side, and a single query can combine both.

# Page "Pablo Picasso"
neo-subj:s2picasso2aaaa2 a edm:Agent;
    rdfs:label "Pablo Picasso";
    foaf:name "Pablo Picasso";
    skos:note "Spanish painter, sculptor, and printmaker who co-founded…"@en;
    rdaGr2:gender "Male";
    rdaGr2:dateOfBirth "1881-10-25"^^xsd:date;
    rdaGr2:placeOfBirth neo-subj:s2birthcity2aa2.

# Page "Málaga"
neo-subj:s2birthcity2aa2 a edm:Place;
    rdfs:label "Málaga".

NeoWiki started out with support for Neo4j, the world's most popular graph database, allowing you to run Cypher queries over your data. We then added a plugin system for graph stores and now support both Neo4j and SPARQL stores such as QLever, Virtuoso, and Oxigraph. You can run NeoWiki with any combination of those, or none. You can even run several instances of the same SPARQL store, each with its own graph projection, for example, one QLever instance for CIDOC-CRM and another for EDM.

Roadmap

Capabilities you can look forward to:

• Bulk import and other import tooling. Easy import from files, RDF, and Wikidata.
• Built-in query result visualizations. You can already create your own visualizations on top of the APIs, Lua, and wikitext, but we plan to add built-in ones, loosely inspired by SMW's "result formats", such as tables, maps, charts, and timelines.
• Advanced dates, such as those in the Extended Date/Time Format (EDTF), so you can record uncertain dates, ranges, partial dates like October 2026, and more. We'll build on the foundations we created for Wikibase EDTF.
• Images, other media files, and locations as property values.
• Additional multilingual support. You can already model multilingual values via the "Text with language" property type, which is similar to Wikibase's "Monolingual text" type. We'll likely also add multilingual support for some of these: property labels, choice list options, subject labels, and schema descriptions.
• Interface translations. Until then, NeoWiki's own interface is English only, while MediaWiki's interface and your content can be in any language.

Not planned yet, but possible on today's foundation:

• Editing values directly from query results. This capability has been requested over and over for about 20 years in SMW, and we can now finally realize it via NeoWiki's architecture.
• Using the data of an SMW or Wikibase in NeoWiki, making it accessible for queries and visualization. For Wikibases installed directly next to NeoWiki, we could even enable editing of the Wikibase items via NeoWiki's UIs, providing the form-based editing experience commonly requested by the community.
• Linking and querying data from external systems. Example: autocompletion on GeoNames locations.
• Faceted search, which allows you to filter and browse your data, building on top of our Wikibase Faceted Search work and experience.

We expect various complementary capabilities to be built on top of NeoWiki, for instance, via the ECHOLOT project:

• Ready-made schema+mapping bundles you import and subscribe to, such as a bundle for museums that want to model their data according to CIDOC-CRM and export EDM for Europeana.
• Reconciliation and enrichment via a dedicated web-based application and human-in-the-loop agentic workflows.

Excited about any of these or don't see your own top wishlist items? Let us know; we prioritize what is most needed.

NeoWiki and Semantic MediaWiki

Semantic MediaWiki (SMW) is the main inspiration behind NeoWiki.

We continue to maintain SMW, with six releases since June 2026, from the major Semantic MediaWiki 7.0.0 release to 7.3.1. The SMW project is in a better state than it was a few years ago. We also continue to provide managed SMW hosting and SMW software development.

NeoWiki does not aim for feature parity with SMW. If SMW serves your wiki well, keep using it.

As SMW maintainers, we've long wanted to improve usability and bring the software to the next level. Unfortunately, some things get in the way of achieving that vision on top of SMW. The project has accumulated quite a lot of technical debt, making it hard to make large changes. Additionally, it has accrued lots of capabilities and contains ancient architectural choices that prevent large changes without severely breaking existing use cases. After many years of feeling stuck, we bit the bullet and reimagined the SMW concept from the ground up, bringing us to NeoWiki.

With NeoWiki, we strive to reach broader adoption by appealing to users for whom SMW is too technical. We hope this brings new organizations to MediaWiki, which benefits everyone who builds on it, SMW users included.

You can run SMW and NeoWiki side by side on the same wiki. We do not yet have an integration between the two, but that might well happen, depending on demand.

If you do wish to migrate from SMW to NeoWiki, beware that there is no migration tool yet. Contact us for advice.

If you know SMW, the main concepts map like this. Your property pages and Page Forms definition become one schema, such as Person, which NeoWiki turns into a form. Properties belong to their schema rather than to the whole wiki. Subobjects become subjects on the same page. Instead of #ask, you write Cypher or SPARQL queries. Until the result visualizations on our roadmap arrive, you show query results through Lua.

We'll be creating a detailed comparison between SMW and NeoWiki in the near future, together with a guide to NeoWiki for those already familiar with SMW concepts.

NeoWiki and Wikibase

NeoWiki shares much of Wikibase's DNA. Both store structured data as JSON in page revisions, give every record a stable ID and a resolvable URI, and export RDF that you can query with SPARQL. In subject-first mode, subjects get their own pages in a dedicated namespace, just like Wikibase items.

NeoWiki fulfills many wishes we've seen from the Wikibase community. Some highlights:

• Form-based editing
• Built-in constraints, including the ability to reject edits that violate them
• In-wiki display for readers
• RDF in standard ontologies such as EDM and CIDOC-CRM, through mappings

Some places where we deliberately departed from how Wikibase does things:

• NeoWiki embraces standard wiki pages. They are great for showing your data to readers and combining it with text. Wikibase item pages can only hold data. In NeoWiki, pages can hold both data and text, like in SMW, but with the data stored in out-of-the-way JSON.
• IDs in NeoWiki are randomly generated, avoiding import problems. You can also mint them in bulk for larger imports, so you are not forced to create subjects before you can reference them.
• You define properties in schemas. Wikibase properties are global: any item can use any of them. A NeoWiki subject uses the properties its schema defines, and mappings tie those to shared ontology terms in RDF.
• Simpler data model: a property graph, where our subjects are the nodes and our relations are the edges. This gives you a simpler structure for qualification, which benefits from schemas and can be nested arbitrarily deep: go ahead and qualify those qualifiers if you so wish.

We continue to invest in the Wikibase community by maintaining our Wikibase extensions, providing managed Wikibase hosting, and innovating further.

If Wikibase serves you well, keep using it. Wikibase remains the better fit when you feed data into Wikidata, rely on its tool ecosystem, or federate across Wikibase instances.

You can run NeoWiki together with Wikibase on the same wiki. Similar to how Semantic Wikibase brings Wikibase data into SMW, we are exploring integrations that would make your Wikibase data available through NeoWiki. You could even edit it there. If you're interested in migrating from Wikibase or connecting it to NeoWiki, contact us.

NeoWiki and AI

We purposefully did not include AI in NeoWiki core, but it is simultaneously built with AI in mind, for those who want AI integration.

NeoWiki forms an excellent complement to AI systems, providing a versioned system of record that AIs can read, query, and edit. The page history provides a safety net and transparency. The comprehensive REST API and query endpoints give your AI what it needs, and you can use our MediaWiki MCP Server for smooth integration via its NeoWiki tools.

Who is behind NeoWiki

Our team at Professional Wiki builds NeoWiki: Morne Alberts, Alistair Kim, Karsten Hoffmeyer, and me, together with everyone who has contributed on GitHub. NeoWiki is open source under GPL-2.0-or-later.

NeoWiki is the core system of ECHOLOT (European Cultural Heritage Optimised Linked Open Tools). ECHOLOT is an EU Horizon Europe project that runs through 2028, with 15 partners in 12 countries. It is led by TIB – Leibniz Information Centre for Science and Technology. We lead the work package that develops NeoWiki.

Funded by the European Union

Hallo Welt!, the company behind BlueSpice, chose NeoWiki as the structured-data layer of BlueSpice Galaxy, its new knowledge management platform. It also funds the integration.

Thanks to our ECHOLOT partners, whose expertise in cultural heritage and linked data shaped this release, to Hallo Welt!, and to everyone who tested early versions: your input brought us to this exciting 0.1 release. Special thanks to Lozana Rossenova and George Bruseker for their myriad conceptual contributions. We also thank the SMW and Wikibase communities for laying the foundations, especially Markus Krötzsch and Denny Vrandečić.

Get involved

If you want to pilot NeoWiki in your organization, contact us. We already provide NeoWiki hosting.

I'm giving two talks at the MediaWiki Users and Developers Conference (MUDCon) in Ljubljana, also streamed on YouTube: "NeoWiki in Action" on November 11 and "Let AI Work With Your Wiki" on November 12. On November 13, Karsten Hoffmeyer is running a beginners' tutorial for NeoWiki.

We're moving fast. If you spot stale documentation, have capability wishes, or have feedback on what's already there, let us know in GitHub Discussions.

If you develop MediaWiki extensions, you can build on NeoWiki's extension points, for example, to add your own property types or views. We'll add more extension points based on demand.

Follow NeoWiki on Mastodon, Bluesky, and X, or sign up for email updates.