Wikidata as a Reconciliation Anchor: Curating Data for Long-Term Preservation

(2.1) Case study: Named entities, authority files & identifiers

Metadata curation for ARCHE is an iterative process that ensures deposited datasets adhere to the ARCHE schema and provide as much information as possible at a minimum at the top level of a data collection. A key part of this process is identifying and disambiguating named entities and enriching and linking them to persistent identifiers from external authority files wherever possible. We encourage depositors to provide additional external persistent identifiers for named entities and we provide extended functionality for a set of, currently, 27 sources that fulfil some requirements like API access and sustainability. Due to its broad and ever-expanding coverage, and its proven usefulness to curators in finding IDs from other authority files, Wikidata was one of the first items on this list of supported sources (it is available in JSON format on GitHub⁹).

In practice, if a named entity has a supported external identifier, any missing information can be fetched from that source. This is valuable both for data creators and curators, because it allows the provided metadata to be enriched and normalised, even when manual curation is not possible due to the large number of entities. For example, if we get a place with the ID “Q1741” in the form of the URI “http://www.wikidata.org/entity/Q1741” without any further information, our technical setup is capable of fetching a label, further supported identifiers, and coordinates, which then reveal that behind “Q1741” stands Vienna in Austria. By fetching further identifiers, duplicates in ARCHE are minimised, as another entity with the GeoNames URI “https://sws.geonames.org/2761367/” can then be merged with our newly ingested entity Q1741 (Figure 2).

Figure 2

By fetching labels from a preferred source, a normalisation of the named entities is possible. Yet, this is not straightforward, as especially in the case of historic persons the preferred version of a name or title or a combination varies from authority file to authority file as shown in Table 1 and using a single source is not possible because they all complement each other.

Another normalisation done on the side of ARCHE with the aforementioned list of supported authority file sources is related to URI normalisation, which is done with rules formalised as regular expressions as shown in Figure 3. This is required to avoid another type of duplicate where e.g. a person was created with the Wikidata URI “https://www.wikidata.org/wiki/Q186709” and later, from another data creator, another person with the URI “http://www.wikidata.org/entity/Q186709” is created. Both URIs refer to the same named entity but in ARCHE disambiguation is done on the level of the URI and without any normalisation these two URIs are interpreted as two distinct entities. An extreme example for an authority file with a large variability of URIs is GeoNames, where one identifier can be resolved with up to 14 different URIs.

Figure 3

In Wikidata, this kind of normalisation is done by using individual properties for each external authority file. For example, the property P1566¹⁰ is used to attach a GeoNames ID (e.g. 2761369) to an item in Wikidata. With the help of URI templates related to each property, e.g. P1630¹¹ (formatter URL) the GeoNames ID can then be displayed as a clickable link pointing to “https://www.geonames.org/2761369”. Furthermore, with the property P8966¹² (URL match pattern), regular expressions similar to those in Figure 3 can be included to extract an ID from a given URI. This open and easily accessible documentation of the URI templates provides a useful source when new identifier sources shall be added to the list for ARCHE.

(2.2) Case study: Reconciliation of Persons

As ARCHE has developed over time, also the data and metadata curation processes have evolved. At the beginning of ARCHE the number of named entities was manageable and a lot of semi-manual curation was still affordable. Given the increasing amount of new data collections and associated metadata, and the fact that named entities do not require an external identifier, it became necessary to merge duplicates with disjoint links to related resources and to reconcile entities without identifiers. The reasons for a lack of authority file identifiers include the entities being e.g. historical persons where not enough information was available, or a missing awareness for LOD from the data creator side.

For the reconciliation, we opted for Wikidata because it is natively supported in OpenRefine¹³ (Delpeuch et al., 2025), for which ARCHE also provides a Reconciliation Service API¹⁴ endpoint via “https://arche.acdh.oeaw.ac.at/openrefine/reconcile”. As the use of Wikidata in library catalogues is becoming increasingly common (Tharani, 2021; van Veen, 2019), so is the number of named entities stored within it. At the time of the reconciliation, about 2000 persons without any external identifier in ARCHE were found in Wikidata. Still, about 4500 persons remained without any match. For some this is due to misspellings (e.g. extra space between first and second name), used abbreviations (e.g. “Eisenst.” or “Rose Fr.”), and ambiguous names lacking further information to accurately determine their respective authority identifier (e.g. “Strauss”).

Yet, there is a large portion of persons whose authority files simply do not exist or cannot be reliably determined, so the question of how to manage them remains. Should these be kept as individual instances of the class Person according to the ARCHE schema, should they be kept as a text value within a new datatype property or should they be omitted?

It seems that there is no one solution that fits all, but that it has to be decided on a case to case basis. For example, identifiable persons with rich additional metadata could be entered into Wikidata, if they currently do not exist there yet. However, because ARCHE is a digital archive with all the tasks attached to the mission of long-term preservation of research data (Trognitz et al., 2024) and not an authority file service nor a database, the resources for curating information about named entities are scarce. Thus, we rely on the provision of authority identifiers and rich metadata by the data creators. However, as the Data Policy “pursues an aggressive Open Access strategy in the publication of research results” (ACDH n.d.), researchers are advised and supported in re-using authority files and actively contributing to open accessible services, such as Wikidata. In this way we try to encourage the use, enhancement and provision of Linked Open Data.

(3.1) Case study: language code vocabulary

To denote the language of a resource, we chose to use the three-letter ISO 639-3 language codes (SIL Global, n.d.) because these cover living and extinct languages that might be submitted within a research data collection to ARCHE. For these codes, a SKOS vocabulary was not readily available in 2019. While Lexvo.org posed an alternative source for language information following Linked Data principles (De Melo, 2015), ARCHE’s software setup at that time required the list to be formalised in SKOS (Isaac & Summers, 2009). Thus, a list available from IANA was imported into OpenRefine and reconciled with Wikidata. Links to the items in Wikidata are included in the vocabulary with owl:sameAs and links to the already existing SKOS vocabulary with ISO 639-1¹⁶ language codes were included via skos:exactMatch (Figure 4). In the course of the preparation, 18 entries identified as missing in Wikidata were created¹⁷ via the QuickStatements tool (Wikidata contributors, 2025), which can be conveniently used via OpenRefine. The resulting vocabulary is now available at https://vocabs.acdh.oeaw.ac.at/iso6393/. It will require updating to reflect changes to the ISO 639-3 language code set over the past five years. The workflow will then include both using and contributing to wikidata.

Figure 4

(3.2) Case study: subject vocabulary

To aid in better describing and finding the various datasets from heterogeneous humanities disciplines covering a diverse range of subjects, which are difficult to foresee, the ARCHE schema currently has a data type property acdh:hasSubject that allows a free text value. Since ARCHE plans to use this property as a facet in the search interface, a consolidation, normalisation, reconciliation, and translation (German to English or vice versa) of all the included values is necessary. The goal for the Subject Vocabulary is to create a structured set of subject terms identifying what a resource or collection is about. By mapping the subject terms supplied by depositors to a controlled list, we aim to create a normalised and interoperable set of descriptors.

There are two potential strategies for achieving this that are currently under consideration. One approach would be a high-level controlled vocabulary in which broad, general categories could be applied and used to support faceted browsing and discovery. Alternatively, a more detailed, fine-grained, yet open vocabulary could be implemented. In this approach, the subject terms provided by the depositors would be mapped directly to external authority files and vocabularies such as Wikidata. While this approach would allow the vocabulary to grow dynamically and contain all contributions supplied by depositors, on the other hand, this set of terms would likely not be suitable for a faceted search due to a lack of structure.

Perhaps the most effective solution will be a hybrid approach. By employing a high-level vocabulary for general categorisation, we would not be giving up the chance for implementing another useful access point, while still allowing for richer subject terminology by utilising links to external authorities. Wikidata could play a valuable role here, as most items are defined as instances of a particular subject class (https://www.wikidata.org/wiki/Property:P31). This would help with grouping subjects across the reconciled terms. The main challenge would be drawing a line between broad categories, which would likely require experimentation and user feedback. As this approach would combine usability with extensible, semantic richness, ARCHE would be taking advantage of both approaches, enhancing discoverability while remaining connected to the wider linked data landscape.

(4.1) Kulturpool

Kulturpool¹⁹ serves as Austria’s central search portal and competence centre for digitised cultural heritage. It aggregates and presents digital objects from a wide range of museums, libraries, and archives. It forms part of the national strategy “Kulturerbe Digital”, initiated by the Federal Ministry for Housing, Arts, Culture, Media and Sport (BMWKMS) and implemented at the Natural History Museum Vienna (NHMW).

As a national cross-domain aggregator, Kulturpool functions as an intermediary layer between local datasets and the wider landscape of European aggregation, particularly Europeana.²⁰ Its partner institutions vary widely in technical capacity, descriptive standards, and metadata granularity and include institutions that operate without formal metadata management systems or controlled vocabularies. Consequently, the incoming datasets are heterogeneous in format, quality, and conceptual modelling.

Contributing institutions are not required to provide controlled vocabularies or fully standardised metadata. This open approach reflects Kulturpool’s commitment to inclusivity: institutions of all sizes and levels of technical maturity can participate, provided their data meet a minimal interoperability threshold. By prioritising accessibility over strict standardisation, Kulturpool accommodates the diversity of Austria’s cultural heritage sector.

A persistent issue across aggregated data is the inconsistent treatment of named entities – people, places, organisations, materials, and concepts. The same person may appear under multiple spellings or variants, places are often entered without geocoordinates, and institutions often lack persistent identifiers altogether. These discrepancies hinder semantic interoperability and limit the capacity to interconnect data across collections.

For Kulturpool, reconciling these inconsistencies is not only a matter of improving search precision but also of enabling a more coherent representation of Austrian cultural heritage as a whole. The effort focuses on aligning diverse institutional data with established global reference systems while respecting the autonomy and descriptive practices of the contributing partners.

For Kulturpool, Wikidata’s openness and inclusivity are central advantages. Its global, multilingual structure allows both scholarly and vernacular knowledge to coexist, which is especially relevant for cultural heritage data that bridges academic and community contexts. This pluralistic framework aligns with Kulturpool’s mission to represent the diversity of Austria’s cultural institutions within a shared semantic environment.

Kulturpool is currently developing a workflow that uses Wikidata as a central anchor for metadata harmonisation. Kulturpool employs an internal OpenSearch²¹ instance to index a locally extracted subset of the Wikidata dataset derived from regular dump files. The use of a local index provides several advantages. It allows large-scale operations without external API limits or latency, supports tailored scoring mechanisms for domain-specific patterns, and preserves data sovereignty within Kulturpool’s infrastructure.

Within this workflow, each metadata field – such as creator, material, or subject – is reconciled against the corresponding Wikidata entity types. Restricting matches to relevant types improves precision and reduces the likelihood of false positives. Candidate entities are ranked based on similarity scores computed from labels, aliases, and other identifying properties. Low-confidence matches are flagged for manual verification, allowing curators to confirm, correct, or reject suggestions before identifiers are stored.

The long-term goal of reconciliation extends beyond standardising identifiers. By linking named entities across datasets, Kulturpool can enrich and contextualise metadata with biographical information, images, dates, descriptions, and more. This enables users to navigate collections through semantic relationships, for example by connecting works held by multiple institutions or by tracking distribution patterns of artefacts made of similar materials. Furthermore, the reconciliation infrastructure enables Kulturpool to support participating institutions by returning enriched data that include Wikidata identifiers and normalised entity names.

The Kulturpool initiative demonstrates how Wikidata, though not a traditional authoritative source, can unify heterogeneous information under shared identifiers and provide a common semantic language across institutions. It also highlights disparities in resources: while large museums operate within established frameworks, smaller entities rely on shared infrastructures like Kulturpool, which offers reconciliation and enrichment services to promote interoperability and wider access to Linked Open Data.

(4.2) CLARIN

The Common Language Resources and Technology Infrastructure (CLARIN)²² is an European Research Infrastructure Consortium dedicated to language data and tools. CLARIN offers a broad range of interoperable services that serve CLARIN’s Open Science agenda and adhere to the FAIR data principles. One core component for the semantic interoperability layer of CLARIN is the CLARIN Concept Registry (CCR),²³ which is relevant for serving interoperable metadata, e.g. following the Component MetaData Infrastructure (CMDI) schema (Ďurčo & Windhouwer, 2014). The CCR is a controlled vocabulary in SKOS format with a collection of concepts relevant to language resources. Originally, this vocabulary was conceived as the ISO TC 37 Data Category Registry (DCR) called ISOcat (Snijders et al., 2009). ISOcat is recently being abandoned in favour of Wikidata, which required some mapping effort resulting in 74% (693 out of 933) of suitable mappings for the entries. As soon as the mapping is completed, this change will also become visible in the SKOS vocabulary (Uytvanck, 2025, pp. 8–17).

(4.3) ARIADNE

The ARIADNE Research Infrastructure²⁴ (ARIADNE RI) operates an Open Access data catalogue, the ARIADNE portal,²⁵ which aggregates archaeology and heritage resources from over 40 countries across four continents.

The resources in the ARIADNE portal are described using the AO-Cat Ontology (Felicetti et al., 2025), which incorporates the subject concepts of the Getty Art and Architecture Thesaurus (Getty AAT, 2017) for ARIADNE subject keywords. As the subject keywords should be available in multiple languages, the use of Wikidata was proposed because adding more labels in multiple languages is quicker and easier than adding them to the Getty AAT. This sparked a discussion on why ARIADNE uses the Getty AAT and not Wikidata as its main reference vocabulary, which culminated in a short feature stating that the Getty AAT was chosen for being a widely-adopted archaeological standard with high-quality, curated terminology and stable linked data implementation. While Wikidata offers advantages like flexibility, openness, and broader scope, it is more general-purpose, subject to frequent changes, and was not designed as a primary source for specialised domains. However, ARIADNE supports using Wikidata in the provided metadata as the AO-Cat Ontology allows to include links from other sources which are used in the indexing mechanisms of the ARIADNE Portal (Basset et al., 2020).