Temporal heterogeneous graphs combine three properties that enterprise data naturally exhibits: multiple entity types, multiple relationship types, and time-varying structure. An e-commerce database has customers, orders, products, and categories (heterogeneous). They are connected by places, contains, and belongs-to relationships (heterogeneous edges). And all of these relationships have timestamps (temporal). A temporal heterogeneous graph captures all three simultaneously.
The three dimensions
Dimension 1: heterogeneous node types
Different entity types have different feature spaces. A customer node has features like age, location, and account tenure. An order node has amount, timestamp, and payment method. A product node has price, category, and rating. A homogeneous GNN would treat all nodes identically. A heterogeneous GNN uses type-specific transformations to handle each feature space appropriately.
Dimension 2: heterogeneous edge types
Different relationship types carry different semantic meaning. A “places” edge (customer to order) carries different information than a “contains” edge (order to product). Heterogeneous message passing applies different transformations per edge type, learning that “customer purchased product” means something different from “customer viewed product.”
Dimension 3: temporal edges
Relationships evolve over time. A customer placed order A in January and order B in March. At prediction time February 1, only order A should be visible. The temporal dimension filters edges by timestamp, ensuring that message passing at time T only uses information from before T.
Message passing on temporal heterogeneous graphs
Standard message passing is modified in two ways:
- Type-specific transformations: each edge type (e.g., customer-places-order) has its own message function and weight matrices. Messages from orders to customers are computed differently from messages from products to orders.
- Temporal filtering: before message passing at prediction time T, edges with timestamps after T are removed. A customer node only receives messages from orders placed before T. This happens automatically in the data pipeline.
The combination means that at any prediction time, the model sees only the relevant subgraph: the correct entity types with their type-specific features, connected by the correct relationship types, filtered to only include historically valid connections.
Enterprise data is temporal heterogeneous by default
Consider common enterprise databases:
- E-commerce: customers, orders, products, categories, reviews, sessions. All with timestamps.
- Banking: accounts, transactions, merchants, devices, alerts. Transactions carry timestamps; account features evolve.
- Healthcare: patients, visits, diagnoses, prescriptions, lab results, providers. Every clinical event has a date.
- Telecom: subscribers, calls, plans, devices, towers, support tickets. Usage data is inherently temporal.
- Manufacturing: machines, sensors, work orders, parts, suppliers, quality inspections. Production data is timestamped.
Every one of these databases maps to a temporal heterogeneous graph through the standard relational-database-as-graph mapping, with timestamps added from date/timestamp columns.
Architectural approaches
Several architectures handle temporal heterogeneous graphs:
- HGT (Heterogeneous Graph Transformer): uses type-specific attention with separate key, query, and value projections per node type and edge type.
- R-GCN + temporal filtering: relation-specific weight matrices with edges filtered by timestamp. Simpler but less expressive.
- Relational Graph Transformer (KumoRFM): combines heterogeneous type handling with temporal positional encodings, learning when a relationship occurred matters as much as which entities it connects.