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 speak 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 project to the standard vocabularies (CIDOC-CRM, Dublin Core, EDM, MARC/BIBFRAME), and to several at once, reshaped so what reaches Europeana or a partner system is that ontology, not your internal model under new names. Importing from existing catalogues and from Wikidata is on the roadmap.

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, with no RDF to hand-write. Every statement carries its provenance: who asserted it and when. For heritage publishing, that is not a feature, it is the record. On the roadmap: querying across institutions, rights statements, and chain-of-production tracking.

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; multilingual data values; 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.