Is HeteroGraphConv truly compatible with the R-GCN paper?

[ketyi]

Computing the update of a single graph node:

in [1703.06103] Modeling Relational Data with Graph Convolutional Networks

If we use HeteroGraphConv — DGL 0.8.0post1 documentation with GraphConv — DGL 0.8.0post1 documentation or the RelGraphConv — DGL 0.8.0post1 documentation classes then the message aggregation is performed only for the neighbors along the incoming edges of nodes (e.g. dgl/graphconv.py at 0.8.x · dmlc/dgl · GitHub) which seems pretty logical but not 100% conform with Figure 2 of the original paper.

Is it okay then not to aggregate additionally along the outgoing edges as well (within the same relation type of course)?

[BarclayII]

Nice catch! While our example does not aggregate along outgoing edges within the same relation type together with the incoming edges (cc @mufeili), I think it’s still possible to do so by adding a reverse relation for each existing relation, and sharing the convolution module between the existing relation and its reverse relation. Essentially, aggregating along the outgoing edges is the same as aggregating along the reverse of incoming edges. So you could do something like:

module_AB = dglnn.SAGEConv(10, 10)
hg = dgl.HeteroGraphConv({
    ('A', 'AB', 'B'): module_AB,
    ('B', 'rev-AB', 'A'): module_AB,
    ...})

[ketyi]

Hi Quan,

Thank you for the response! Although, it’s indeed a good solution but I’m just worried that it’d be perplexing the directionality information of relations.