Ontology-Driven Data Lineage

• Ontology-driven data lineage tracking is an approach that uses explicit semantic models, typically OWL/RDF knowledge graphs, to represent and analyze data transformations.
• It integrates operational metadata and logical inference to query, validate, and infer missing dependency links across tables, columns, rows, and cells.
• Empirical evidence shows that enriched ontologies boost precision, recall, and overall performance in complex data transformation scenarios.

Ontology-driven data lineage tracking is the representation and analysis of how data assets are produced, transformed, and related by means of an explicit semantic model, typically instantiated as an OWL/RDF knowledge graph. In this approach, lineage is not restricted to operational dependency metadata: tables, views, columns, rows, cell values, transformations, executions, constraints, and governance artifacts are modeled as first-class entities, so that lineage can be queried, validated, and, when dependencies are missing, inferred. In relational databases the problem is motivated by broken lineage—incomplete or missing dependency links caused by complex ETL, undocumented temporary objects, external systems, or legacy environments—and by the need to support regulatory compliance, impact analysis, debugging, auditing, and safe reuse of data products (Dutkiewicz et al., 15 May 2026).

1. Scope, lineage semantics, and problem setting

Data lineage in relational systems documents how data moves and changes from source tables, through queries and transformations, to derived tables, views, and reports. The relevant dependency space spans multiple granularities: tables, views, materialized views, temporal and external tables; columns and attributes; rows; and individual cell values. A persistent difficulty is that explicit dependency catalogs usually capture only explicit references, whereas logical derivations created by multi-step ETL, nonlinear transformations, or procedural code may remain unrecorded. Ontology-driven approaches address this gap by treating lineage as a semantic modeling problem rather than as a purely syntactic feature of a specific DBMS (Dutkiewicz et al., 15 May 2026).

A second distinction, important beyond relational databases, is between materialized lineage and logical lineage. Materialized lineage denotes concrete graphs of influence between individual entities captured at runtime, whereas logical lineage denotes higher-level descriptions of how an operation must relate inputs to outputs, independent of any particular container implementation. XProv formalizes this distinction through a common intermediate representation based on lineage-constraint tags, such as One-to-One, Slice[DIM], Identity, and Condition[DIM, INDEX], thereby making cross-library lineage behavior expressible as reusable, machine-checkable constraints (Zhao, 23 Jun 2025).

The broader semantic orientation has earlier roots in work that studied the generation of a domain conceptual model from a given ontology. That line of work, based on ontologically derived semantics of the BWW model and mappings from DAML+OIL constructs to conceptual-model elements, demonstrated that a conceptual data model can be generated from an ontology, subject to validation by a domain specialist before it evolves into a global conceptual model integrating multiple data and information sources [0412036]. This suggests a precursor to later lineage systems in which ontology serves not only as documentation, but as the integration layer on which lineage reasoning is built.

2. Ontological structure and modeling primitives

The most explicit recent formulation for relational databases is the Relational Database Data Lineage Ontology, defined in OWL and grounded in reused vocabularies including CSVW, DSD, and PROV-O. Its structural core introduces classes such as Table, Column, Row, and ColumnValue or CellValue, together with properties such as hasColumn, hasRow, and belongsToColumn. It extends this core with a refined database-object taxonomy comprising View, MaterializedView, TemporalTable, ExternalTable, Query, StoredCode, NamedDBObject, and TabularDataObject, so that lineage can distinguish base tables from derived or procedural objects (Dutkiewicz et al., 15 May 2026).

Lineage itself is modeled explicitly at several granularities, all grounded in prov:wasDerivedFrom: tableDerivedFrom, columnDerivedFrom, rowDerivedFrom, and valueDerivedFrom. The result is a hierarchical lineage model in which table-level, column-level, row-level, and cell-level derivations coexist within a single schema. At the row level, the formal relation can be written as

$$\text{rowDerivedFrom} \subseteq \text{Row} \times \text{Row}.$$

This multi-level design is central because even when prediction or querying is performed at one level, evidence is often supplied by relations defined at other levels (Dutkiewicz et al., 15 May 2026).

A distinguishing feature of ontology-driven lineage is the inclusion of structural and semantic metadata that are usually absent from minimal provenance models. The relational ontology introduces Constraint and its specializations PrimaryKey, ForeignKey, NotNullConstraint, and CheckConstraint, together with hasConstraint and referencesTable. It also introduces DataType and hasDatatype, with support for datatype attributes such as name and length. These elements provide machine-readable cues about structural compatibility and likely transformation behavior, which later become useful both for reasoning and for learning-based lineage discovery (Dutkiewicz et al., 15 May 2026).

Process semantics are equally important. The ontology therefore adds Query, StoredCode, QueryExecution, ProcExecution, and FuncExecution, with properties such as usesTable, generatesRow, and execution-linking relations for queries, functions, and procedures. In effect, provenance is represented not only as a dependency graph between data objects, but also as a graph of activities and executions that mediate those dependencies. Enterprise-scale governance models generalize the same principle: an upper ontology can align data assets, enterprise architecture artifacts, and governance constructs by reusing DCAT, FOAF, Dublin Core, PROV-O, SKOS, SHACL, and related vocabularies, thereby making lineage part of a broader semantic fabric that includes lifecycle state, roles and responsibilities, quality rules, and business glossary terms (Oliveira et al., 2023).

3. Knowledge-graph instantiation and lineage inference

Ontology-driven lineage becomes operational when the ontology is instantiated as a knowledge graph from database metadata, selected data values, and execution traces. In the relational setting, this begins with extraction of catalog metadata for tables, views, columns, constraints, and foreign keys, stored in CSV form. Because RDF is binary, each n-ary relational fact is decomposed into $n+1$ binary relations. The resulting graph contains nodes for tables, columns, rows, cell values, constraints, data types, queries, and execution instances, and edges corresponding to properties such as hasColumn, hasDatatype, hasConstraint, usesTable, generatesRow, and the various derivedFrom relations (Dutkiewicz et al., 15 May 2026).

Instance-level lineage can be injected from cursor-based SQL traces. In the relational study, each lineage record is a tuple

$(t_1, c_1, v_1, t_2, c_2, v_2),$

where the source and target are identified by table, column, and value. These tuples are resolved against the knowledge graph by matching triples of the form (Row, hasCellValue, ColumnValue), (ColumnValue, exactValue, v), and (ColumnValue, belongsToColumn, Column), after which the graph is populated with explicit rowDerivedFrom edges. The knowledge graph thus contains both semantic context and observed lineage facts (Dutkiewicz et al., 15 May 2026).

The discovery of missing lineage links is then cast as an inductive link prediction problem. Training and test graphs are disjoint at the node level but share relation types; all explicit rowDerivedFrom edges are retained in the training graph and removed from the test graph, where they serve as ground truth. The model used in the relational study is a path-based Siamese GNN that samples several paths between a candidate source-target pair, encodes those paths with shared embeddings and BiLSTM layers, fuses the resulting path representations, and scores the target relation by a dot product between the fused path embedding $\mathbf{p}$ and the embedding $\mathbf{r}$ of rowDerivedFrom:

$$s(u,v;R)=\sigma\left(\mathbf{p}^\top\mathbf{r}\right).$$

Because the model learns patterns over paths of relation types rather than over node identities, it is inductive: it can generalize to unseen rows, columns, or tables as long as the ontology-defined relation vocabulary is shared (Dutkiewicz et al., 15 May 2026).

The conceptual importance of this arrangement is that ontology design directly controls the feature space available to the predictor. Additional object types, constraints, datatypes, and process semantics increase graph density and diversify the relation paths that connect candidate lineage endpoints. A join path that traverses a foreign key, a datatype signature, and a query execution is semantically richer than a path built only from table-column membership. Ontology-driven lineage tracking therefore treats schema design, provenance design, and inference quality as a single coupled problem rather than as separate engineering layers (Dutkiewicz et al., 15 May 2026).

4. Operational architectures and application domains

Ontology-driven lineage tracking is not confined to one execution model. In enterprise governance settings, it is embedded in a metadata-driven architecture whose central artifact is a knowledge graph describing avatars of data assets in their business context, including governance principles, lifecycle state, provenance from source systems, and lineage across transformations. In the clinical DG4.0 framework, multiple ontologies articulated by an enterprise upper ontology generate business glossaries, conceptual and logical data models, data dictionaries, catalogs, FAIR metadata, governance reports, and API endpoints. Technical lineage is modeled by linking input variables to transformations and transformations to output variables; business lineage is modeled through temporal relations such as nvuo:timelyPrecedes and nvuo:timelyFollows across data stages (Oliveira et al., 2023).

That framework provides a concrete lineage example for adverse-event end date and time. Variables such as RP.AE.AEENDAT, DR.AE.AEENDTC, DR.AE.AEENDTN, DR.AE.AEENDY, SD.AE.AEENDY, and AD.ADAE.AEENDY are linked through derivations including NCDS COPY_ELEMENT, NCDS DTC, NCDS DTN, and NCDS STUDY_DAY. A SPARQL query traverses :isInputOf, :hasOutput, :transformationRule, and :dataStage to reconstruct the lineage chain. This shows ontology-driven lineage in its enterprise form: the graph is simultaneously a provenance repository, a governance registry, and a queryable semantic index (Oliveira et al., 2023).

A different operationalization appears in blockchain-based provenance. There, the TOVE Traceability Ontology defines Traceable Resource Unit and Primitive Activity, together with relations such as produce_tru and consume_tru, and axioms such as “A tru is produced only once.” Those ontological constraints are translated into Solidity structs, mappings, modifiers, and functions, so that provenance tracing and constraint enforcement are executed on Ethereum. Although developed for supply chains, the conceptual pattern is transferable to data lineage by replacing physical TRUs with datasets, files, or model artifacts and primitive activities with ETL jobs or workflow steps (Kim et al., 2016).

The physical computation of fine-grained lineage can also be decoupled from the ontology. PredTrace formulates row-level lineage as predicate pushdown through SQL and data-science pipelines. With intermediate materialization it computes exact lineage; without intermediate results it returns a superset and refines it iteratively. The paper explicitly treats this as complementary to ontology-driven lineage: the ontology supplies the conceptual and logical layer, while predicate pushdown supplies an efficient, system-agnostic procedural backend that can feed row-level wasDerivedFrom facts into a semantic graph (Lin et al., 2024). XProv plays a similar role for cross-library data-science workflows by providing a common multidimensional-array abstraction, a dataflow DAG, fine-grained influence relations, and reusable lineage-constraint tags that can be elevated into ontology classes and properties (Zhao, 23 Jun 2025).

5. Empirical evidence and observed benefits

The clearest direct evidence that ontology design affects lineage quality comes from the relational database study. Experiments were conducted on Northwind-derived transformation scenarios spanning projection, linear transformation, nonlinear transformation, and selection-, join-, and union-based relational patterns. Across the $3 \times 3$ task grid, each task contained 20 scenarios, with 17 used for training and 3 for testing. Training graphs included all rowDerivedFrom edges and structural or procedural relations; for each existing edge, 3 random paths were sampled, yielding approximately 5 million training samples per graph. Training was performed for 3 epochs with batch size 32, and evaluation used Precision, Recall, AUC, and Hits@10 (Dutkiewicz et al., 15 May 2026).

The enriched ontology improved all reported averages relative to the baseline ontology: Precision by $+0.04$, Recall by $+0.02$, AUC by $+0.03$, and Hits@10 by $n+1$0. Join-based tasks showed the most visible gains. In join-projection, AUC increased from $n+1$1 to $n+1$2 and Hits@10 from $n+1$3 to $n+1$4; in join-linear, AUC increased from $n+1$5 to $n+1$6 and Hits@10 from $n+1$7 to $n+1$8; in join-nonlinear, AUC increased from $n+1$9 to $(t_1, c_1, v_1, t_2, c_2, v_2),$0 and Hits@10 from $(t_1, c_1, v_1, t_2, c_2, v_2),$1 to $(t_1, c_1, v_1, t_2, c_2, v_2),$2. Even in selection-based tasks where AUC was already about $(t_1, c_1, v_1, t_2, c_2, v_2),$3, Hits@10 still improved by $(t_1, c_1, v_1, t_2, c_2, v_2),$4 to $(t_1, c_1, v_1, t_2, c_2, v_2),$5. The central empirical conclusion is that ontology expressiveness directly influences KG-based lineage discovery quality (Dutkiewicz et al., 15 May 2026).

Evidence on the execution side comes from PredTrace. It supports all 22 TPC-H queries and 70 sampled real-world data-processing pipelines, including cases with nested subqueries and widely used UDFs. With intermediate results, average lineage-query time on TPC-H was $(t_1, c_1, v_1, t_2, c_2, v_2),$6 ms with a maximum of $(t_1, c_1, v_1, t_2, c_2, v_2),$7 s; runtime overhead during pipeline execution averaged $(t_1, c_1, v_1, t_2, c_2, v_2),$8 ms, and storage overhead averaged about $(t_1, c_1, v_1, t_2, c_2, v_2),$9 MB. The paper reports up to $\mathbf{p}$0 speedup over the best prior lazy lineage baseline when intermediate results can be saved, and the abstract reports that it can infer lineage in seconds while outperforming prior lazy approaches by up to $\mathbf{p}$1 (Lin et al., 2024). These results do not measure ontology quality, but they establish that ontology-driven systems need not sacrifice operational efficiency if they are paired with an adequate procedural backend.

A further empirical question concerns ontology construction itself. OntoEKG evaluates a two-stage LLM pipeline for enterprise ontology construction on Data, Finance, and Logistics documents. In the Data domain, fuzzy-match evaluation reached an F1-score of $\mathbf{p}$2; exact-match evaluation for the same domain gave Precision $\mathbf{p}$3, Recall $\mathbf{p}$4, and F1 $\mathbf{p}$5. Finance and Logistics performed substantially worse, and the reported limitations centered on scope definition and hierarchical reasoning (Oyewale et al., 1 Feb 2026). For ontology-driven lineage, this is consequential because the quality of the lineage graph depends not only on lineage-capture mechanisms but also on the correctness of the ontology that structures the graph.

6. Limitations, misconceptions, and research directions

A common misconception is that ontology-driven lineage is merely descriptive metadata management. The available evidence contradicts this. In the relational setting, the ontology is a determinant of downstream link-prediction performance; in enterprise governance, the ontology is the keystone for FAIRification, lifecycle management, roles and responsibilities, governance checks, provenance from source systems, and lineage across transformations (Dutkiewicz et al., 15 May 2026). Ontology design therefore has computational consequences, not only documentation value.

The complementary misconception is that ontology alone is sufficient. The examined systems all rely on additional mechanisms: SQL cursor-based capture of row-level lineage, inductive link prediction over KGs, predicate pushdown and symbolic verification, SHACL validation, SPARQL query templates, or smart-contract execution. The ontology supplies semantics, type structure, and interoperability; the physical lineage engine supplies concrete evidence or candidate links. This layered view is explicit in work that distinguishes logical from materialized lineage and in architectures that separate high-level constraint vocabularies from low-level runtime capture (Zhao, 23 Jun 2025).

Current limitations are correspondingly practical. In the relational ontology study, fine-grained ground truth depends on SQL cursor-based lineage capture, which may be unavailable or expensive in production environments; experiments were performed on Northwind with synthetic scenarios; the ontology is tailored to relational databases; and evaluation focused on rowDerivedFrom although the ontology also supports column-, table-, and value-level lineage (Dutkiewicz et al., 15 May 2026). In LLM-assisted ontology construction, scope ambiguity, class-versus-individual confusion, hierarchy-direction errors, and ambiguous properties remain serious failure modes, with much stronger results in the Data domain than in Finance or Logistics (Oyewale et al., 1 Feb 2026).

The declared research agenda follows directly from these constraints. For relational KG-based discovery, proposed directions include ablation studies of individual ontology components, application to larger and more heterogeneous databases, evaluation of broader inductive link-prediction models, and protocols closer to real operational conditions, including incomplete logs, noisy metadata, and evolving schemas (Dutkiewicz et al., 15 May 2026). For automated ontology authoring, the evident need is progressive, human-in-the-loop construction rather than autonomous generation (Oyewale et al., 1 Feb 2026). A plausible implication is that future ontology-driven lineage systems will combine richer upper ontologies, executable or query-rewriting lineage backends, and learned constraint vocabularies, while preserving a clear distinction between exact lineage facts, approximate lineage candidates, and ontology-level commitments about what those facts mean (Zhao, 23 Jun 2025).