By Jeroen De Meester, Application Manager Collections, Collection IT, Rijksmuseum Research Services

Every object in a museum collection comes from somewhere, and “somewhere” is rarely a throwaway detail. A painting’s place of origin, a photograph’s depicted city, the birthplace of an artist: all of these are geographic terms that need to live in the collection management system as more than just a label. In our case, that system is Axiell Collections, and the geographic thesaurus behind it turned out to hide a surprising amount of work.

This post is about a pipeline we built to automate that work, and about the efficiency gain that came with it. As a disclaimer up front: what follows is a description of the tool and the workflow it replaced, written for people who don’t necessarily work with Axiell Collections or Wikidata day to day. This tool and workflow are still evolving, and any code or import produced by it is thoroughly tested.

What a geographic term actually needs

A geographic term in Axiell Collections isn’t just a name typed into a field. To be genuinely useful for search, filtering, and eventual public presentation, a well-formed term usually benefits from three things beyond its label.

First, it needs a place in an administrative hierarchy: a village belongs to a municipality, a municipality to a province, and so on. In Axiell this is modelled as a “broader_term” link, so that a search for a province can also surface terms filed under the villages within it.

Second, it benefits from links into shared authority files, specifically Wikidata, the Getty Thesaurus of Geographic Names (TGN) and GeoNames. These links are what let our data interoperate with other museums and archives that use the same authorities, rather than existing as an island. And the same links work just as well closer to home, connecting a place in Collections to that same place in one of our own other systems, such as our library catalogue, which would otherwise have no shared way of identifying that place at all.

Third, it benefits from an actual mapped boundary where one exists: a GIS shape that lets the place be shown on a map and searched spatially, rather than just matched by name.

Put together, one modest-looking “place of origin” field can represent a small stack of decisions and lookups behind the scenes.

How we used to do this

Until recently, this all happened by hand, and it started before a record even existed. Colleagues in the Rijksmuseum aren’t allowed to add geographic terms to the thesaurus themselves: with many people able to add a “place of origin” on the fly, the risk of duplicate or inconsistent entries in a shared thesaurus was judged too high. Instead, a colleague who needed a new term would request one in a shared Teams channel, and had to supply the Wikidata item, a “Q-number” the term should be based on.

From there, an administrator did everything by hand. The term’s label and other properties were largely derived from the Wikidata item on which the request was based. The Wikidata reference itself had to be typed or pasted into Collections, which turned out to be a surprisingly common source of small errors: is it http:// or https:// in front of the Wikidata URI? The place type was chosen by hand based on what Wikidata said the place was. The broader term, the administrative parent, was looked up and entered by hand too. Very occasionally, for a handful of terms, we’d also track down and add a matching Getty TGN or GeoNames identifier by hand.

Coordinates were their own small ordeal. Wikidata stores a place’s coordinates under its “coordinate location” property (P625), but getting them into Collections meant a detour through an external tool, GeoHack, to read off a usable latitude and longitude, then typing those numbers into Collections’ own map widget by hand. And even after all that, the result was never the place’s actual boundary: at best, it was a single point or a rough circle standing in for a shape that, in reality, might be a city, a province, or a scattered group of islands.

The problem wasn’t the people doing the work. It was the process itself: every term had to touch several different sources and tools, each with its own small chance of a typo, a wrong digit, or a rough approximation standing in for the real shape.

So we asked a simple question: what if most of this could be automated?

The idea: read the data that already exists

The realisation behind this project was fairly simple: almost everything we were retyping by hand already exists, in structured and actively maintained open datasets that are familiar to most GLAM technologists.

Wikidata already links a huge number of places to their Getty TGN ID, their GeoNames ID, their administrative parent (via the “located in” relationship), and, for many, a corresponding OpenStreetMap link. OpenStreetMap, in turn, holds the actual boundary geometry for administrative areas, buildings, and much more, maintained by a large community of mappers.

Rather than a person visiting several websites per term, the pipeline visits them programmatically. Given a Wikidata identifier, it:

• fetches the relevant labels and administrative hierarchy;
• records the correct Wikidata reference;
• picks up the Getty TGN and GeoNames identifiers wherever the Wikidata item carries them;
• retrieves the corresponding boundary geometry from OpenStreetMap where available;
• checks what our own geographic thesaurus already contains to avoid duplicates;
• produces a ready-to-import Axiell XML file.

For the rare place with no Wikidata item at all, the pipeline can still fetch a boundary directly from a given OpenStreetMap reference. That route is deliberately narrower: with no Wikidata item to draw a label, hierarchy, or authority link from, it can only add or update the GIS information of a term that already exists in Collections, rather than create a new term from scratch.

Either way, the pipeline works through an entire batch of identifiers pasted in by the collection manager, not just one term at a time.

Automated, but not blind

A pipeline that quietly guesses at metadata is arguably worse than no pipeline at all, so a fair amount of the design effort went into making the suggestions cautious rather than clever.

The most basic example is the term’s label. Our thesaurus works in two languages, so for a new term the Dutch and English labels are pre-filled from Wikidata’s own labels for that item where available, rather than one being typed by hand and the other left blank or guessed at.

Term types and monument types are derived from Wikidata’s own classification of a place, using its direct “instance of” statement. If that does not produce a match, the tool takes exactly one careful step up the classification hierarchy, checking the class’s own “subclass of” relationship.

We deliberately stop there. An open-ended climb through Wikidata’s community-maintained class structure can wander into distantly related, and occasionally incorrect, categories. One extra step can often provide a useful match; going further starts to introduce too much uncertainty.

Broader-term suggestions follow the same philosophy. They are derived from Wikidata’s administrative hierarchy, then cross-checked against the candidate’s own name as an additional safety net before being suggested at all.

None of these suggestions are written to Collections automatically. Every one is surfaced in a review screen first, so a person always makes the final call before anything is imported.

The pipeline’s job is to remove repetitive lookup work, not the human judgment that goes with it.

Real data is messy, and the pipeline has to be too

A tool like this only earns its keep once it survives contact with a real collection backlog: years of accumulated terms, covering a far wider and stranger range of places than any test dataset we could have written ourselves. That range is what surfaces the edge cases.

We encountered small hamlets that have never had their boundary mapped in OpenStreetMap at all. In those cases, the pipeline falls back to a single coordinate point rather than blocking the record entirely. We encountered administrative regions made up of several disconnected parts, which need to be handled as proper multi-polygons rather than flattened into something simpler. And we encountered the occasional place for which no Wikidata item exists at all, where a direct OpenStreetMap reference can still be used as an input.

None of these cases were anticipated up front. Each one came from an actual record in our own backlog that the first version of the tool could not handle.

The efficiency case

This is ultimately where the value of the project becomes visible. Instead of spending several manual minutes on one term at a time, across multiple lookups and tools, we can now paste in dozens of terms at once and have a reviewable result back within moments. But speed is only half the story. The same shift also improves the accuracy, consistency and richness of the data that ends up in Collections.

The http:// versus https:// slip in a hand-typed Wikidata link simply cannot happen anymore, because the reference is read programmatically rather than retyped. The GeoHack detour for coordinates is gone, because the pipeline reads a place’s location directly and, where available, retrieves its actual mapped boundary.

That also changes what a geographic term can represent in Collections. A village, city, province or scattered island group can now be represented by its actual community-mapped boundary, rather than by a single point or a rough circle standing in for it.

Beyond these specific fixes, the same underlying shift means richer, more connected records. Imported terms retain their available references to Wikidata, OpenStreetMap, and, where present, Getty TGN and GeoNames, rather than becoming static labels. And it means greater consistency across records, because hundreds of terms can now be processed using the same structure instead of hundreds of individual decisions being made on different days.

Where this goes next

We’re continuing to refine the one-step hierarchy fallback described above, deliberately keeping it to a single careful step rather than widening it, and working through more of our own backlog to surface further edge cases.

The approach is not specific to the Rijksmuseum’s collection. Other institutions running Axiell or Adlib Collections with a comparable geographic thesaurus may face many of the same challenges: connecting geographic terms to external authorities, finding reliable GIS geometry, and keeping a growing thesaurus consistent without turning every update into manual lookup work.

We’re still developing the tool, and we’d be glad to hear from anyone tackling a similar problem, whether you’re using Axiell, Adlib, or something else entirely.

---

This tool and workflow are still evolving, and any code or import produced by it is tested in an acceptance environment before it touches production data. Parts of the implementation were developed with the help of AI coding tools, with all output reviewed and tested by us before use. Get in touch if you’d like to compare notes.