Mapping Structured Data with Agentic Workflows
A skill-based agentic workflow that automates schema mapping to ontology-aligned RDF, with human review of key modelling decisions, illustrated with two FIFA datasets and deployed as a virtual knowledge graph using Ontop and GraphDB.
Main Takeaways
- Schema mapping to RDF combines routine, automatable steps with modelling decisions that genuinely require human domain expertise.
- The workflow separates source analysis and ontology mapping into distinct, codified skills, producing inspectable reports rather than a single black-box prompt.
- The agent flags ambiguous decisions (e.g., how to model relationships) and asks the human engineer to resolve them, with all choices recorded in a decision log.
- Validation is treated as a required pre-condition for deployment, catching syntax, join, and datatype errors before the mappings go live in GraphDB via Ontop.
Producing ontology-aligned RDF from structured data sources is a task that combines routine, repeatable steps with decisions that genuinely require domain expertise. This post describes an agentic workflow that separates the two: reusable, codified skills handle source inspection, mapping authoring, validation, and documentation, while a human knowledge graph engineer resolves the modelling decisions that require judgment.
The cost of schema mapping: Preparation before automation
Producing ontology-aligned RDF from a structured source involves much more than associating columns with ontology properties. The process normally starts by inspecting the source data schema, profiling its values, selecting vocabulary terms, and designing URI templates.
After these preparatory steps, the knowledge graph engineer chooses an appropriate technology for the transformation and specifies it by authoring an RML, R2RML or OBDA mapping, creates the result by either materializing the RDF or deploying a virtual knowledge graph, and finally validates the result (if SHACL shapes are available).
Why an agentic workflow?
The mapping engines themselves are mature. Tools such as Ontop and RMLMapper can execute mappings reliably once the required artifacts have been prepared. Most of the effort lies instead in understanding the source and making modeling decisions.
A knowledge graph engineer must determine which identifiers are stable, which columns represent relationships, which repeated values should be split up, which strings should become reusable resources, and which fields should remain literals. Two foreign keys may point to the same table while expressing different roles. Values stored as text may require conversion to dates, booleans, or numbers. Vacuous values like “N/A” or “empty” should be omitted. The target ontology may cover common concepts but lack precise terms for domain-specific attributes, thus requiring extensions.
These decisions make schema mapping a suitable task for an agentic workflow. Instead of asking a language model to generate a complete mapping from a single prompt, the procedure can be encoded as reusable skills. An agent follows those skills, produces inspectable artifacts, invokes existing mapping tools, and asks the knowledge graph engineer to resolve decisions that require human judgment. The aim is not to remove the ontology expert. It is to reduce the repetitive work involved in source inspection, mapping authoring, documentation, testing, and iteration (Fig. 1).
Use case: FIFA datasets
The proposed approach is generic, however we apply it in the context of two FIFA datasets: FC players and World Cup matches. The first dataset is a denormalized dataset on FIFA players based on the FC-26 video game (Fig. 2) provided in CSV format, whereas the second is a normalized dataset on World Cup matches (Fig. 3) provided both as a collection of CSV files and as a relational database. The two datasets were selected because they represent complementary mapping challenges: denormalized data require discovering reusable entities and relationships from repeated attributes, while normalized data require preserving the semantics of explicit relational structures through joins and foreign keys.
The approach: Codified skills, agent execution
Source analysis before mapping
The workflow is organized around two complementary skills.
The first is source schema analysis. It examines the data at the source and documents the observed schema, profiles the dataset and even reasons about risks and unresolved questions. At the end of this stage, the agent produces a handoff report, used as input by the next stage.
The second is RDF/ontology mapping. It uses that handoff report to identify RDF resources, select ontology classes and properties, assign confidence levels, design URI templates, and generate the requested RML, R2RML, or OBDA mappings together with a human-readable mapping summary.
Separating the two stages prevents premature modelling. The source-analysis skill does not choose final ontology terms or generate RDF mappings. It first establishes what the source contains and which interpretations are supported by evidence.
The interrogative version of the source schema analysis skill performs this analysis incrementally:
- Schema inspection covers tables or files, columns, datatypes, keys, constraints, and declared relationships.
- Record profiling examines sample values, nulls, recurring codes, date formats, boolean encodings, and candidate controlled vocabularies.
- Relationship analysis identifies declared and inferred joins, candidate keys, lookup tables, and functional dependencies.
- Mapping handoff summarises candidate entities, relationships, identifiers, labels, datatype issues, and open questions.
Agent execution
The following figure illustrates the interaction with a Claude Code agent that asks the user for various stages A-D and can be used in schema analysis, derived from the respective skill.
Before moving to a deeper stage, the agent can ask whether the knowledge graph engineer wants it to continue. It also asks targeted questions whenever the source is ambiguous. For example, it may ask whether a 0/1 field should be interpreted as a boolean or integer, or whether two foreign keys referencing the same table represent different semantic roles.
The resulting handoff summary also reduces the input required by the mapping skill, i.e. creates a ‘stripped-down’ version of the sources. It distills the original source into a compact, mapping-relevant summary, allowing the next step to work from the essential schema facts, inferred relationships, datatype observations, and open decisions rather than repeatedly analysing the full source.
The answers are stored in a decision log. This log records each question, the available alternatives, the knowledge graph engineer’s decision, and its consequences for the later mapping.
The ontology-mapping skill uses a similar approach. For each source entity or field, the agent considers candidate ontology terms and assigns confidence levels:
- High confidence for a direct and precise match;
- Medium confidence for a broader term that preserves the main meaning;
- Low confidence for an approximation that may introduce semantic loss.
Human judgement and Agent execution
Where two alternatives have similar confidence, in order to ‘break ties’ the agent asks the knowledge graph engineer to choose one of the options or keep both. It may also ask whether a repeated value should become a resource, whether a relationship should be reified, whether an extension (custom) term is acceptable, or which identifier should be used in a URI.
For example, the following shots show three alternatives for representing the home & away teams of a match.
- The first alternative uses two dedicated properties from schema.org:
- The second alternative uses the general schema.org Role pattern
- The third alternative uses “Participation node and a parthood relation”
The same principle follows the next steps. The following shot shows three decisions about how to represent Venue & Place (in this case we omitted the details about each choice):
The modelling shown in Fig. 5 represents the preferred mapping suggestion by the agent and it is using the dedicated Schema.org terms schema:SportsEvent, schema:homeTeam, and schema:awayTeam. By contrast, the alternative in Fig. 6, based on role participation, does not conform semantically to the Schema.org Role pattern, since schema:competitor is not used as both the incoming and outgoing property, as required by the pattern. Furthermore, schema:athlete is intended to refer to a person rather than a team. In the modelling proposed in Fig. 7, schema:superEvent would be more precise than the suggested schema:isPartOf. This alternative also fails to preserve the distinct “home” and “away” roles of the participating teams.
The previous example illustrates the need for human judgment considering that an agent may generate a structurally plausible modeling that is inconsistent with the defined semantics of the target vocabulary.
Finally, once the decisions are selected, the agent generates the mapping summary in a separate Markdown file, URI strategy, executable mappings, validation evidence, and deployment or materialization instructions.
To conclude, the knowledge graph engineer therefore defines the target vocabulary, modelling constraints, extension policy, URI conventions, and review criteria; the agent carries out the procedural work within those boundaries.
Handling vocabulary gaps: Documented extensions
Standard vocabularies should be reused wherever they preserve the meaning of the source. In the worked examples, Schema.org provides useful terms for people, teams, sports events, countries, cities, stadiums, names, identifiers, dates, external profile URLs, and locations.
However, a general-purpose vocabulary cannot represent every concept found in a specialized dataset. One possible response is to use the closest available standard property. This may produce valid RDF, but it can also weaken or change the source meaning. A property may have a similar label while differing in its intended domain, range, or semantics.
The mapping skill therefore follows a conservative policy:
- Search for an adequate term in the target vocabulary.
- Prefer the standard term when it preserves the source meaning.
- Avoid overloading a vaguely related property.
- Introduce a project-specific term when no adequate standard term exists.
- Document every extension in the mapping summary.
A precise extension term can be preferable to an imprecise standard term. The extension should use a stable project namespace and be accompanied by a short explanation covering the source field, its intended meaning, the alternatives considered, and the expected datatype or target resource.
In the FIFA examples, extensions were used for concepts such as game-specific player ratings, team group letters, and tournament stages. Schema.org covered the surrounding people, teams, events, and locations, but did not provide sufficiently precise properties for all of these specialized attributes.
Because the extensions are recorded explicitly, they remain reviewable. A data engineer can approve them, replace them with terms from another ontology, or revise the modelling approach without searching through the generated mapping files.
From mapping to queryable graph: Ontop and GraphDB
For relational sources, the generated R2RML or Ontop OBDA mapping can be loaded into an Ontop-backed virtual repository in GraphDB. Users query the repository through SPARQL, while Ontop translates the queries ‘on-the-fly’ into SQL and executes them over the original database.
The relational system remains the source of truth, as there is no need to move the data. The mapping artifact becomes the integration layer between the relational schema and the ontology-aligned graph view. The agent can generate the necessary artifacts, including the mapping file, database properties, GraphDB repository configuration, deployment commands, and representative SPARQL queries.
As encoded in the RDF/ontology mapping skill definition (SKILL.md), the mapping is validated as a pre-condition for the next deployment step. Validation checks whether the syntax is accepted, referenced tables and columns exist, joins can be evaluated, URI templates are well formed, prefixes are declared, and datatype transformations are valid. The agent will run in multiple loops the ‘validate’ command via Ontop CLI until the necessary changes to the mappings are done and they run successfully.
./ontop-cli/ontop validate \ -m datasets/fifa-world-cup-2026-match-data-unofficial/mappings/worldcup-schemaorg-obda-mapping.obda \ -p datasets/fifa-world-cup-2026-match-data-unofficial/worldcup.properties
We assume that the necessary details for accessing the relational database are already provided in worldcup.properties file, as in the following:
jdbc.url=jdbc:postgresql://localhost:5432/worldcup jdbc.driver=org.postgresql.Driver jdbc.user=user jdbc.password=
Materialization can follow the validation step as a stronger condition of verification, which makes errors easier to diagnose. Ontop can generate RDF from relational mappings, while an RML mapper can execute mappings over CSV and other tabular sources. The resulting Turtle file can then be inspected, or loaded into a triple store in the case of the output generated by RML mappings.
./ontop-cli/ontop materialise \ -m datasets/fifa-world-cup-2026-match-data-unofficial/mappings/worldcup-schemaorg-obda-mapping.obda \ -p datasets/fifa-world-cup-2026-match-data-unofficial/worldcup.properties \ -f turtle \ -o datasets/fifa-world-cup-2026-match-data-unofficial/output/worldcup-materialised-obda.ttl java -jar rmlmapper-8.1.0-r380-all.jar \ -m datasets/fifa-world-cup-2026-match-data-unofficial/mappings/worldcup-schemaorg-rml-mapping.ttl \ -o datasets/fifa-world-cup-2026-match-data-unofficial/output/worldcup-materialised-rml.ttl
Typical checks derived from the skill include counts of resources by class, counts of important relationships, datatype correctness, malformed URIs, missing labels, duplicate resources, and the use of extension terms.
Once the mapping is generated, the deployment to GraphDB is done via the following curl command, which includes the repository configuration file, the access to the database, and the respective mappings.
curl -X POST http://localhost:7200/rest/repositories \ -F "config=@ontop-repo-config-obda-v2.ttl" \ -F "propertiesFile=@worldcup.properties" \ -F "obdaFile=@mappings/worldcup-schemaorg-obda-mapping.obda"
Once the virtual repository has been deployed successfully, the underlying relational database can be queried using SPARQL (Fig. 10).
Illustration: The FIFA datasets
The workflow was tested with two structurally different football datasets – normalized vs denormalized databases. Their purpose was to illustrate the end-to-end process, not to develop a comprehensive sports knowledge graph. Both cases were driven by a short orchestrator prompt that sequenced source analysis, decision resolution, ontology mapping, validation, and execution. Each run produced an analysis report, decision log, mapping summary, mapping files, and RDF output or virtual-graph configuration.
The first source contained World Cup 2026 fixtures in a normalized relational database. It included tables for matches, teams, host cities, and tournament stages. Foreign keys connected each match to its home team, away team, host location, and stage.
The source-analysis skill identified that home_team_id and away_team_id referenced the same teams table but represented different roles. The mapping therefore used schema:homeTeam and schema:awayTeam rather than collapsing both into a generic relationship.
Matches were represented as schema:SportsEvent resources, while teams, cities, countries, and stadiums became separate resources. The database was mapped in R2RML and Ontop OBDA and exposed through a GraphDB Ontop virtual repository.
The second source was a denormalized dataset about FIFA players derived from the video game FC 26. Each row described a player but also contained repeated information about countries, leagues, clubs, national teams, positions, contracts, and game-specific ratings.
The analysis showed that several repeated values should become linked resources rather than literals. The RML mapping therefore represented players as schema:Person resources and created separate resources for countries, teams, and leagues. Project-specific extensions preserved the meaning of attributes not covered precisely by Schema.org.
Wrapping up: Lessons from the workflow
The main contribution of the proposed skill-based workflow is not only the generation of mappings, but the production of inspectable documents and files at every stage, allowing results to be reviewed, corrected, and rerun. The different challenges in the mapping process posed by denormalized and normalized sources were addressed through the LLM-guided source-analysis skill. For denormalized data, the skill helped identify implicit entities and relationships embedded in repeated attributes. For normalized relational data, it summarized tables, keys, foreign-key relationships, and join paths that needed to be preserved in the mappings.
A key lesson learned was that validation must be treated as a pre-condition for deployment rather than an optional final check. Iterative validation with the mapping engine exposed syntax, SQL, join, datatype, prefix, and URI-template problems before repository creation; only mappings that passed these checks could be deployed reliably as an Ontop-backed virtual repository in GraphDB. Materialization as a stronger condition can provide additional evidence by allowing the generated resources, relationships, and datatypes to be inspected. Especially, when generating both OBDA and R2RML mappings, it can be used to ‘cross-check’ and test the equivalence between the mappings in terms of output triples.
Human judgment remains essential for class and property choices, extension policy, relationship modeling choices, and URI design. The agent reduces the associated analysis, drafting, execution, and documentation effort, but not the need for expert review across the end-to-end knowledge graph workflow. The transferable asset is therefore the skill-based workflow itself: a project can substitute a different source, target vocabulary, mapping format, or deployment environment while retaining the same sequence of source analysis, decision resolution, mapping generation, validation, and deployment.
Details
What is a knowledge graph
Knowledge graphs are a collection of interlinked descriptions of entities that put data into context and enable data analytics & sharing.
Learn moreFAQ
Any Questions? Look Here
RDF (Resource Description Framework) is a W3C standard for data interchange that models information as a directed, labeled graph using "triples" (subject-predicate-object). It is used to represent structured data as knowledge graphs because it provides a flexible, schema-agnostic framework that enables the seamless integration of heterogeneous data sources. By using globally unique identifiers (URIs) and formal semantics, RDF ensures that data is machine-readable and interoperable, allowing for precise disambiguation of entities and the ability to infer new knowledge through automated reasoning.
Agentic AI workflows differ from a single LLM prompt by shifting from a linear, one-shot response to a dynamic, iterative process. While a single prompt requires the LLM to solve a complex task in one execution—often leading to hallucinations or logic gaps—agentic workflows decompose tasks into smaller, manageable steps. These workflows use autonomous "agents" that can proactively select specialized tools (such as SPARQL for structured data or Knowledge Graphs for reasoning), apply self-correction through feedback loops, and maintain a "long-term memory" of decision traces to ensure the final output is accurate and contextually grounded.
The primary difference between materializing RDF data and using a virtual knowledge graph (VKG) lies in how the data is stored and accessed. Materialization follows an ETL (Extract, Transform, Load) approach where data is physically converted into RDF triples and stored in a graph database, enabling high-performance queries and complex reasoning at the cost of potential data staleness and increased storage requirements. In contrast, a virtual knowledge graph provides a real-time, "zero-copy" view of data residing in its original source (such as a relational database) by translating SPARQL queries into the source's native language (e.g., SQL) on the fly. While virtualization ensures data freshness and avoids replication, it typically entails a performance trade-off due to the overhead of query translation and the limitations of the underlying source's processing capabilities.
Handling denormalized versus normalized datasets differently is essential because they present distinct structural challenges for semantic integration. Normalized datasets, typically originating from relational databases, possess a rigid schema where relationships are already explicitly defined; these are often handled through declarative mappings (such as R2RML) or virtualization to translate tabular data into graph triples while preserving logical consistency. In contrast, denormalized datasets often contain significant redundancy and varying levels of standardization, requiring more intensive ETL processes—including data cleaning, entity resolution, and property value normalization—to align them with a unified ontology. This differential treatment ensures that the resulting knowledge graph is a high-quality, interconnected network of unique entities rather than a collection of fragmented or redundant data silos.
SHACL (Shapes Constraint Language) validation ensures data quality in knowledge graphs by providing a standardized, machine-readable framework to define and enforce structural and semantic constraints on RDF data. As a W3C standard, SHACL allows organizations to declaratively specify rules—such as required properties, data types, value ranges, and cardinality—without the need for custom code, ensuring that all data conforms to a predefined schema. By facilitating both bulk and incremental validation, SHACL identifies inconsistencies like missing mandatory values or incorrect data types and generates detailed violation reports. This rigorous checking prevents the ingestion of invalid data, maintains graph integrity, and supports the reliable scaling and integration of information from diverse sources.
In AI-driven data modeling workflows, human review remains indispensable because AI, while efficient at processing large datasets and accelerating repetitive tasks, often lacks the capacity for nuanced judgment, ethical reasoning, and understanding complex systemic causalities. Human-in-the-loop (HITL) validation serves as a critical quality control layer that ensures the accuracy and relevance of data before it is integrated into a knowledge graph, effectively mitigating risks such as "hallucinations," algorithmic bias, and logical inconsistencies. Furthermore, human oversight provides the necessary explainability and accountability required for regulatory compliance and trust, transforming AI from a potential "black box" into a transparent tool that augments human expertise rather than replacing it. By acting as a continuous feedback loop, human experts refine AI models over time, ensuring that the resulting data structures remain aligned with evolving business logic and societal values.