Graph Merging

The computational process of establishing semantic correspondences between two distinct schemas. Before merging instance data, the system must map equivalent classes and properties.

• Schema Mapping: Identifies that Person in Graph A is equivalent to Human in Graph B.
• Property Matching: Determines that date_of_birth and birthDate refer to the same attribute.
• Structural Heterogeneity: Resolves conflicts where one graph uses a single attribute while another uses a complex sub-graph to represent the same fact.

The core deduplication engine that determines if two nodes from different graphs refer to the same real-world object. This step prevents the creation of duplicate entities in the merged graph.

• Probabilistic Matching: Uses algorithms like Fellegi-Sunter to weigh the evidence of attributes like names, dates, and locations.
• Blocking Keys: Reduces the quadratic search space by grouping potential matches using shared attributes (e.g., same postal code).
• SameAs Assertions: Explicitly links two URIs using the owl:sameAs property to declare identity, a critical step for linked data consolidation.

When two matching entities possess contradictory attribute values, a deterministic logic must decide which value survives in the final golden record.

• Source Priority: A predefined trust hierarchy where data from an authoritative ERP system overrides a scraped web source.
• Temporal Freshness: The most recent timestamp wins, assuming newer data is more accurate.
• Majority Voting: In multi-source merges, the value confirmed by the highest number of independent sources is selected.
• Manual Curation: High-stakes conflicts (e.g., financial totals) are flagged for human review.

Maintaining an auditable trail of origin for every fact in the merged graph. This is essential for debugging and trust.

• Edge Attribution: Every merged triple is annotated with metadata identifying the source graph and extraction timestamp.
• Lineage Graphs: Visual representations showing how a specific value was derived from raw sources through the merge pipeline.
• Justification Logs: Records the specific survivorship rule or matching algorithm that caused a value to be selected, enabling downstream users to verify the logic.

Beyond attribute matching, the structural relationships of nodes provide powerful signals for merging. Two nodes are likely the same if they share highly similar neighborhoods.

• Structural Similarity: Algorithms like SimRank compute similarity based on the principle that two objects are similar if they are related to similar objects.
• Sub-graph Isomorphism: Identifies identical patterns of relationships connecting entities, revealing redundant substructures.
• Transitive Closure: If Node A matches Node B, and Node B matches Node C, the system infers that A and C are the same entity, collapsing the entire cluster into a single canonical node.

The ability to merge updates from source graphs without requiring a full recomputation of the entire canonical graph. This is critical for dynamic, real-time systems.

• Change Data Capture (CDC): Listens to transaction logs of source databases to detect new, updated, or deleted records.
• Delta Processing: Only the modified sub-graphs are re-evaluated for entity resolution and conflict resolution.
• Tombstoning: When an entity is deleted in a source, it is marked as deprecated in the merged graph rather than silently removed, preserving referential integrity for systems that depend on the canonical ID.