The choice heritage teams have had to make

Heritage data is relational before it is anything else. A person, an object, a place, an event, an era: the value is in how they connect, and the connections carry as much scholarship as the records. That data also has to travel. It speaks shared vocabularies (CIDOC-CRM, Dublin Core, EDM, MARC) so it can join the linked-open-data cloud, reach Europeana, and outlive any single system. And it is multilingual, multi-institutional, and long-lived: provenance and rights move with it across decades and handoffs.

Tools have forced a trade. Bespoke RDF and CIDOC-CRM stacks model that rigour faithfully, but only people fluent in RDF can contribute. Curator-friendly platforms let anyone edit, but flatten the structure, lose the graph, and don't round-trip to the standards your peers expect. Institutions have had to choose which half to give up.

What NeoWiki commits to

NeoWiki refuses the trade. Your schemas map to and from the standard vocabularies (CIDOC-CRM, Dublin Core, EDM, MARC/BIBFRAME), so the same records export as RDF, import from existing catalogues, and round-trip with Wikidata and Europeana. A vocabulary modelled once is packaged and shared, ready for the next institution.

The data lives in a real graph database, queried in standard languages like SPARQL, so a collection answers the questions that matter: how a workshop connects to its patrons, what an object's provenance chain actually is, which works survive from a collection long since dispersed.

Curators contribute through forms derived from the schema, in their own language, with no RDF to hand-write. Federation lets each institution keep and govern its own data while queries reach across the network, and enrichments can flow back to the systems they came from. Every statement carries its provenance: who asserted it, when, under which rights statement, through which chain of production. For heritage publishing, that is not a feature, it is the record.

The discipline you have always practised pays a new dividend here. Structured, sourced, standards-mapped collections are the trustworthy ground that AI needs to answer without inventing, and NeoWiki opens that ground to AI-assisted curation and retrieval on your terms. The catalogue you have tended for decades becomes the thing that keeps the machines honest.

It is open source, and yours to keep: self-host it, or let us run it. No vendor holds your collection, and standards-based exports mean you can always walk. For publicly-funded heritage work, that independence is the point.

Built with ECHOLOT

NeoWiki is ECHOLOT's core system, and Professional Wiki leads its development. ECHOLOT is an EU Horizon Europe consortium building tools for the European Collaborative Cloud for Cultural Heritage, funded through 2028.

ECHOLOT has received funding from the European Union's European Research Executive Agency under grant agreement Nº 101233096. More on ECHOLOT and EU funding.

It is built and tested against real collections. Across the consortium, five case studies exercise the system:

• The first shared pool of entity identifiers for Basque cultural heritage, across fragmented and multilingual datasets.
• Multilingual European literary bibliography, transformed and enriched from library MARC data.
• Diverse media-art collections, harmonised across institutions.
• Flemish fine and performing arts, published to Wikimedia Commons and Europeana.
• Swedish GLAM data round-tripped: published out, with enrichments fed back to the source.

Where NeoWiki is going

The cultural-heritage capabilities are being built now: deeper RDF support; AI-assisted import, reconciliation, and enrichment; finer-grained rights and provenance tooling; and visualisations that read a collection at a glance. ECHOLOT funds much of this work, but the capabilities land in NeoWiki itself, open source, for any institution to use.