---
title: Ontology-Driven Data Lineage
url: https://www.emergentmind.com/topics/ontology-driven-data-lineage-tracking
type: topic
---

# Ontology-Driven Data Lineage

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 [2605.16068].

## 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 [2605.16068].

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 [2506.18252].

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 [2605.16068].

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 [2605.16068].

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 [2605.16068].

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 [2311.02082].

## 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 [2605.16068].

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 [2605.16068].

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 [2605.16068].

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 [2605.16068].

## 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 [2311.02082].

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 [2311.02082].

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 [1610.02922].

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 [2412.16864]. 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 [2506.18252].

## 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 [2605.16068].

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 \(+0.11\). Join-based tasks showed the most visible gains. In join-projection, AUC increased from \(0.83\) to \(0.89\) and Hits@10 from \(0.45\) to \(0.68\); in join-linear, AUC increased from \(0.78\) to \(0.84\) and Hits@10 from \(0.42\) to \(0.62\); in join-nonlinear, AUC increased from \(0.83\) to \(0.86\) and Hits@10 from \(0.31\) to \(0.57\). Even in selection-based tasks where AUC was already about \(0.98\), Hits@10 still improved by \(0.09\) to \(0.15\). The central empirical conclusion is that ontology expressiveness directly influences KG-based lineage discovery quality [2605.16068].

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 \(226.6\) ms with a maximum of \(2.25\) s; runtime overhead during pipeline execution averaged \(34.7\) ms, and storage overhead averaged about \(4.5\) MB. The paper reports up to \(98\times\) 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 \(10\times\) [2412.16864]. 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 \(0.724\); exact-match evaluation for the same domain gave Precision \(0.083\), Recall \(0.133\), and F1 \(0.102\). Finance and Logistics performed substantially worse, and the reported limitations centered on scope definition and hierarchical reasoning [2602.01276]. 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 [2605.16068]. 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 [2506.18252].

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 [2605.16068]. 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 [2602.01276].

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 [2605.16068]. For automated ontology authoring, the evident need is progressive, human-in-the-loop construction rather than autonomous generation [2602.01276]. 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 [2506.18252].

Source: https://www.emergentmind.com/topics/ontology-driven-data-lineage-tracking