Skip to content

Glossary

Knowledge fusion

Knowledge fusion combines claims from multiple sources into a coherent account while preserving uncertainty and origin.

Knowledge fusion

Knowledge fusion brings information about the same real-world subjects into a coherent representation. It encompasses identity alignment, terminology alignment, conflicting claims and missing information. The goal is not merely to pool records: merged statements must remain interpretable under their original scope and time. A useful fused view can contain settled values, competing alternatives and explicit gaps rather than a single filled field for every property.

In practice, sources use different identifiers, schemas and publication schedules. Fusion work first asks whether records refer to the same subject and whether their properties mean the same thing. Claims can then be compared with their source context intact. The output may support search or analysis, but the intermediate distinctions matter when a user needs to trace an answer back to original material.

For a defensible organizational decision, fusion must not make disagreement disappear by silently overwriting one source. Reviewers need to see which identity and semantic alignments were assumed, and which facts remain contested. Data fusion often emphasizes combining datasets or measurements; knowledge fusion additionally treats meaning, entities and assertions as first-class parts of the problem.

Example

Halden Therapeutics AG (fictional) appears under two spellings in a registry and a publication; their claims are compared only after the identity and field meanings are established.

The steps in a fusion pipeline

A fusion pipeline has recognisable stages, though real systems interleave them. Extraction or ingestion produces statements from documents, tables and structured feeds; see information extraction. Schema alignment maps the fields and vocabularies of each source to a common one; see schema alignment. Entity resolution decides which records and mentions denote the same real-world subject; see entity resolution. Conflict handling compares the aligned statements and applies a rule or model, as set out under truth discovery. Finally, the result is published with whatever uncertainty and provenance the consumer needs.

Errors at each stage compound. A wrong entity match produces a conflict that is not real; a wrong field mapping makes agreement look like disagreement; an extractor error looks like a source error. The Knowledge Vault system fused extractions from several kinds of web content with prior knowledge from existing knowledge bases and reported a calibrated probability for each candidate fact, instead of a yes or no. The article on what survived of Knowledge Vault at web scale discusses which of its ideas have held up in practice.

What a fused record must still show

The test of a fusion output is whether it can be taken apart. Given any value, a reader should be able to find the statements that contributed, the alignments and identity decisions that brought them together, and the rule or model that chose among them. If a record stores identity decisions as merged rows with no memory of the original pieces, a wrong merge cannot be undone; the article on merging or relating organization records describes the cheaper alternative of relating records without merging them, which keeps the choice reversible.

Time must be treated carefully. Fusion often runs repeatedly as sources change, and a value displayed today should be reproducible as of the day a decision was made on it. That is the concern of the entries on as-of queries and point-in-time reproducibility, and of the article on bitemporal data and temporal knowledge graphs.

A worked example

A registry lists Halden Therapeutics AG (fictional) under its legal name; a trial database lists a sponsor called Halden Thera; a news archive mentions Halden. The pipeline first aligns fields, so that sponsor in one source and registrant in another are both mapped to the organisation role. Identity resolution uses the registry number where available and the address and trade name otherwise, and marks the news mention as a probable match with a stated score instead of a certain one. Conflict handling then compares the three statements about the company's headquarters. The fused record reports one headquarters with a source, shows that the news mention was not used because its match was below the threshold, and lists one open conflict. A reader can reconstruct each of these steps.

Related terms and boundaries

Data fusion is the broader and older term, covering measurements and records as well as statements; knowledge fusion adds meaning and assertion as first-class concerns. The inputs usually arrive through information extraction or knowledge-base population, and the output is often held as a knowledge graph described by an ontology. Treating the stages as separable, each with its own tests, is what allows a failure to be located: wrong identity, wrong mapping, wrong extraction or wrong choice among conflicting claims.

Checks a reviewer can run

Take any fused value and ask for the contributing statements, the identity decisions and the field mappings behind it. Ask how many conflicts are open and how many were suppressed by a rule. Ask whether a wrong identity merge can be undone without rebuilding. Ask for the fused view as of an earlier date.

Common misreadings

  • Merging names before checking identity.
  • Treating similar field labels as equivalent without definition.
  • Hiding conflicts in a final record.

Related terms

Appears in

Found an error on this page? See corrections for what counts as one, how to report it and the dated log.

Enquiry

Where does "Knowledge 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.