Source-linked AI summary

Automated Construction of FAIR Digital Object Knowledge Graphs from Flat Cultural Heritage Records

Zeyd Boukhers, Lingxiao Kong, Xenophon Zabulis, Georgios Toubekis

arXiv:2608.23263v1cs.AIcs.CLcs.DL

TL;DR

Europeana’s largely plain-text metadata does not satisfy the FDO goal of a fully machine-actionable graph with resolvable references. The paper presents an LLM pipeline that classifies values at the PID/literal boundary, links reusable entities to controlled vocabularies, and constructs CIDOC-CRM-based FDOs. It reports 58.5% resolution for values Europeana had not already enriched, while manual review found 17 of 33 cross-lingual merges correct.

  • Problem

    Europeana stores most metadata values as plain strings, whereas FDOs require reusable entities to be expressed as resolvable PIDs for machine actionability.

  • Method

    An LLM classifies each metadata value, decides whether it is a reusable entity or terminal literal, routes entities to controlled vocabularies, and instantiates shared entities as FDOs.

  • Results

    58.5% of values requiring new resolution were resolved, and manual review judged 17 of 33 cross-lingual surface-form merges correct.

  • Takeaways & Limitations

    The resulting graph’s distinguishing property is that every node is typed and resolvable, rather than greater connectivity than string matching.

  • Takeaways & Limitations

    The evaluation uses automatic quality proxies rather than human-annotated gold, so its measures do not verify correct linking, literal decisions, or meaningful bridges.

Abstract

from arXiv · show

The FAIR Digital Object (FDO) framework mandates that metadata attribute values be expressed as persistent identifiers (PIDs) wherever possible, to produce a fully machine-actionable graph in which every reference is resolvable. The Europeana Data Model was designed long before the FDO specification, and it stores most metadata values as plain text. This serves human browsing well enough, but gives an automated agent nothing to follow across records or collections. We present a pipeline that transforms flat Europeana records into an FDO-compliant knowledge graph structured with CIDOC-CRM. Following the FDO specification, we model every heritage entity as a discrete FDO with its own PID, type, profile, and metadata layer. The core technical challenge is automating the FDO-prescribed distinction between values that must become PID references (resolvable entities) and those that may remain literals (terminal leaves such as notes, measurements, and dates). We address this with a large language model that classifies each metadata value, routes it to a controlled vocabulary (Getty AAT, Wikidata, VIAF, PeriodO), and links it to a shared entity FDO. We evaluate using 637 archaeological records from five Europeana providers, processing each with the LLM. The pipeline links 86% of metadata slots, resolving 58.5% of values Europeana had not already enriched. It also merges cross-lingual surface forms that byte-identical matching keeps apart, where 17 of 33 such merges are correct on manual review. Graph connectivity does not separate this from string matching; what distinguishes the FDO graph is that every node is typed and resolvable.

1 Introduction

The paper addresses the gap between Europeana’s plain-text metadata and the FDO requirement for typed, resolvable PID references. It presents an LLM-driven pipeline that enforces the PID/literal boundary and constructs an FDO-native graph from flat records.

  • Motivation: FDO metadata values should be resolvable PIDs for reusable entities, while terminal leaves such as measurements, notes, and dates may remain literals.This distinction is defined by the FDO architecture rather than by entity-linking convenience.
  • Motivation: Europeana’s plain-text values prevent automated agents from traversing records to places, creators, or shared entities.For example, strings such as “Bracara Augusta” and “Cristina Braga” do not themselves resolve to shared place or person identifiers.
  • Approach: The pipeline uses an LLM to classify metadata values, decide whether they cross the PID/literal boundary, and resolve eligible values to shared entity FDOs.Each entity FDO has its own PID, type, profile, and CIDOC-CRM metadata layer.
  • Contributions and evaluation: 58.5% of values requiring new resolution were resolved, while 89.6% overall were resolved after Europeana’s pre-linked URIs were included.The two figures are reported separately because the first excludes Europeana’s existing enrichment.
  • Contributions and evaluation: The evaluation processes 637 records from five providers and reports connectivity changes that depend on the slot population.With an identical slot population, entity resolution reduces disconnected components from 32 to 20, whereas string matching reaches 8 when all content values are included.

2 Related Work

Prior work links cultural-heritage mentions, enriches records, and constructs knowledge graphs, but this paper targets a narrower FDO-specific decision. Its system must first determine which values are entities that should receive PIDs and which are terminal literals.

  • FDOs and cultural-heritage models: FDOs provide persistent, typed, self-describing units with machine-resolvable identifiers, while EDM aggregates and enriches collection records.CIDOC-CRM complements EDM by providing an event-centric ontology for integrating complex heritage information.
  • FDOs and cultural-heritage models: Cultural-heritage records remain difficult to model because they are heterogeneous, incomplete, historically accumulated, and often weakly structured.This motivates semantic models and linked-data approaches across institutional collections.
  • Entity linking: Entity-linking systems connect textual mentions to canonical entities, with Wikidata supporting multilingual and externally connected authority control.Heritage Connector and related systems apply record linkage, entity extraction, relation extraction, and deep learning to museum data.
  • Paper-specific distinction: The paper differs by deciding whether a value is an entity at all before linking, because the FDO specification determines which values may remain literals.Its contribution is the PID/literal boundary decision and its use in populating an FDO graph rather than a benchmark of dedicated linker accuracy.
  • LLMs for data integration: LLMs have been applied to schema matching, data cleaning, entity resolution, knowledge-graph construction, completion, and semantic enrichment.The related work frames foundation models as supporting structured data integration while knowledge graphs provide grounding and interpretability.

3 System Overview

The system extracts Europeana slots, classifies each non-prelinked value at the PID/literal boundary, resolves eligible entities through controlled vocabularies, and instantiates them as FDOs. The resulting graph separates structural FDO metadata from typed CIDOC-CRM relations and is designed for machine traversal.

  • Design principles: The pipeline reserves PIDs for reusable entities and literals for terminal leaves, making this rule the governing design constraint.Every heritage entity is represented as a discrete FDO in the resulting graph.
  • Stage 1: Slot extraction: Stage 1 decomposes each rich-profile Europeana record into metadata slots consisting of a field and value.The projection uses EDM-derived API fields, including entity-bearing fields and literal-oriented fields.
  • Stage 2: Boundary classification: Stage 2 asks an LLM to classify each non-prelinked value as a reusable entity requiring a PID or a terminal value remaining literal.The classification is framed as an explicit FDO-prescribed boundary decision.
  • Stage 2: Boundary classification: The LLM jointly outputs a 16-class semantic type, a binary resolvability decision, and a target vocabulary in one structured JSON call.Record context includes the title, type, and country.
  • Stage 3: Entity resolution: Stage 3 queries controlled-vocabulary APIs for resolvable values, applies fallback chains, and reranks similar candidates using record context.The target vocabularies include VIAF, Wikidata, AAT, and PeriodO; places route to Wikidata.
  • Stage 4: FDO graph construction: Resolved entities become full FDOs whose property objects are PIDs of other FDOs, while external vocabulary URIs appear as owl:sameAs links.CIDOC-CRM relations connect objects to places, materials, people, groups, types, and periods.
  • Stage 4: FDO graph construction: The graph gives every node a PID, type, and resolvable metadata structure, enabling machine traversal, querying, and composition.FDO types and operations are themselves registered as PID-bearing FDOs, while the kernel contains only structural identifiers and metadata references.

4 Evaluation

The evaluation tests connectivity, typing, routing, and cross-lingual merging on 637 archaeological records, while showing that connectivity alone is an unstable proxy for machine actionability.

  • Dataset and setup: 637 archaeological records from five Europeana providers are evaluated across content-bearing metadata fields.The dataset contains 12,720 slots; 9,197 already carry Europeana vocabulary URIs and 3,523 are plain strings.
  • Connectivity: Entity resolution reduces connected components from 32 to 20 and raises the largest component from 69.4% to 73.6% over 10,995 slots.Over all 12,720 content values, string matching reaches 8 components because unlinked identical strings still connect records.
  • Connectivity: Connectivity does not stably distinguish entity resolution from string matching because its direction depends on the chosen slot population.Shared rights or organization values can dominate connectivity, so both graphs are restricted to content-bearing fields and frequent values are removed.
  • FDO graph structure: The FDO graph produces 800 entity FDOs and 9,054 CIDOC-CRM edges, with every FDO node carrying a resolvable identifier and semantic type.Only 63.8% of flat-graph URI-string nodes have that combination; the remainder are bare literals.
  • Surface-form merging: 33 entity FDOs absorb 176 surface forms, but manual review finds only 17 correct merges and 16 incorrect ones.Correct merges attach to 327 records, while incorrect merges concentrate in PERIOD and include internal identifiers mapped to unrelated concepts.
  • Typing and routing: Strict vocabulary routing is 73.1% (1315/1798), while PERIOD type–vocabulary consistency is 62.5% on 331 slots.The consistency check is measurable only for PERIOD because other classes route predominantly to Wikidata, where any semantic type is admissible.
  • Limitations: The evaluation relies on automatic proxies without human-annotated gold, and its results are limited to archaeology in one aggregator.The authors state that these measures do not verify correct links, unresolved literals, or meaningful bridges, and make no generalisation claim to other collections or aggregators.

5 Conclusion

The paper presents an LLM-driven pipeline that enforces the FDO PID/literal boundary when transforming flat Europeana metadata into a machine-actionable CIDOC-CRM graph. It concludes that the graph’s measured benefit is typed, resolvable nodes and merged surface variants, while quality claims remain dependent on automatic proxies.

  • The pipeline resolves reusable cultural-heritage entities to persistent identifiers while retaining terminal attributes as literals.
  • Resolved places, actors, periods, object types, and concepts become full FDOs connected through CIDOC-CRM relations.
  • The measured benefit is typed, resolvable nodes and merged surface variants rather than increased record reachability.
  • Quality claims rely on automatic proxies rather than human judgement, motivating a future human-annotated gold set.

GenAI Usage Disclosure

The authors disclose using generative AI for language editing, explanatory drafting, and software development, with author review and verification.

  • Generative AI assisted language editing, paragraph restructuring, explanatory drafting, code drafting, debugging, and implementation clarity.
  • The authors state that generated text and code were reviewed, verified, tested where applicable, and approved.
Loading 2608.23263v1…