Glossary
Data fusion
Data fusion combines observations or datasets to produce a consolidated representation for a defined task.
Knowledge fusion
Data fusion is the combination of information from multiple inputs into an output intended to be more useful for a task. Inputs may be measurements, records or reported values. The term does not prescribe a single algorithm: the method depends on whether inputs are complementary, redundant or conflicting. The output's meaning also depends on how measurement scales, entity identities and observation times were aligned.
A practitioner may join datasets to fill complementary fields, reconcile duplicate measurements or produce a summary estimate. Each operation requires a declared policy for missingness and disagreement. A calculated average is appropriate for some measurements but meaningless for categorical legal status. Before combining anything, the input values must be comparable and the task must state what constitutes a valid result.
When an organization must defend a derived value, it needs the inputs and transformation that produced it. A consolidated field without that lineage conceals both errors and legitimate alternatives. Knowledge fusion is closely related but places greater emphasis on semantics and claims about entities; provenance records where fused values came from and what operations affected them.
Example
Two Halden Therapeutics AG (fictional) datasets provide complementary trial dates; the combined view keeps each date's source rather than presenting an unattributed pair.
Complementary, redundant and conflicting inputs
Data fusion covers three situations that need different treatment. When inputs are complementary, each covers fields the others lack, and the task is to combine them without confusing one source's blank with another's value. When inputs are redundant, several sources report the same field consistently, and the task is to deduplicate and confirm. When they conflict, the task is to choose or reconcile, which is the territory of truth discovery and of the entry on data conflict. A pipeline usually meets all three in the same dataset, and the rules for each should be stated separately.
For numeric measurements the classical toolbox includes weighted averages and filters that account for the known precision of each instrument. For categorical and textual facts such as legal status or a name, averaging is meaningless and the options are selection, retention of alternatives, or abstention. Hogan and colleagues discuss how knowledge graphs handle integration across heterogeneous sources, and the article on knowledge-graph data-source evaluation lists what to check about each source before its values are combined.
Declaring the policy
Each fused field needs a declared policy that a reviewer can read: the sources in scope, their priority or weight, the treatment of missing values, the treatment of disagreement, and the tolerance within which two numeric values count as equal. The policy belongs with the data, not in the code of a one-off job, because a change to it changes the meaning of every value derived under it. The related notion of survivorship rules is the same idea applied to the choice of a single surviving value when duplicate records are merged.
The policy should also say what is not fused. A field that comes from a single trustworthy source and is not corroborated is not made more reliable by being combined with unrelated data, and a field is not made more complete by a default value invented to fill a gap. The null semantics entry explains why a blank must remain distinguishable from a zero, an empty string or a not-applicable marker.
A worked example
Two datasets describe the same trial of Halden Therapeutics AG (fictional). One has the planned enrolment target and the sponsor; the other has the actual enrolment to date and the recruiting countries. They are complementary on these fields. Both carry a start date, which differs by one week. The fusion policy states that dates from the registry take precedence over dates from the commercial dataset, that a difference of more than thirty days triggers review, and that both source values are retained. The resulting record shows the registry date, flags the week-long difference as within tolerance, and carries the commercial value as an alternative. If the sponsor later amends the registry, the policy and the retained alternative together make the change traceable through the entry on data lineage.
Related terms and boundaries
Knowledge fusion shares the goal and differs in emphasis: it treats entities and statements as the objects of fusion, where data fusion often combines tables and measurements. The reconciliation step relies on data conflict handling and on schema alignment, and the audit of the result relies on data lineage. A golden record is the usual product when the fused entity is a customer, supplier or organisation, and survivorship rules are the declared policy by which it is formed.
Checks a reviewer can run
Ask for the fusion policy for a given field and the test cases that cover it. Ask how a blank in one source is told apart from a value in another. Pick a numeric field and ask what tolerance defines agreement. Confirm that source values are retained beside the fused value and that a change in policy triggers a re-run with a record of the change.
Common misreadings
- Averaging values with incompatible meanings.
- Assuming a join key proves entity identity.
- Discarding source-level disagreement.
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Where does "Data fusion" bear on a decision of yours?
This entry sits under knowledge fusion. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.
Or write to [email protected] in your own words.