Why is RandomLinkSplit on an undirected graph returning directed edge label index?

[saiden89]

Hi everyone. Recently I've been dealing a lot with GNN link prediction models, and one of the very first steps to do is to partition the data into train, validation and testing; you know, the usual stuff.
To my understanding, in PyG this is achieved through RandomLinkSplit:

from torch_geometric.datasets import FakeDataset
from torch_geometric.transforms import RandomLinkSplit
from torch_geometric.utils import is_undirected


dataset = FakeDataset(
    num_graphs=1, 
    avg_num_nodes=100, 
    num_node_types=1, 
    edge_dim=20, 
    is_undirected=True
)


transform = RandomLinkSplit(is_undirected=True)
splits = transform(dataset[0])

What I'm currently not grasping is the reason beneath providing the supervision edge index (edge_label_index) in directed form, even when specifically informing the transform that we are currently dealing with a undirected network.

print(is_undirected(splits[0].edge_index)) # True
print(is_undirected(splits[0].edge_label_index)) # False

Is this intended behaviour? If so, what am I currently missing?

[rusty1s]

This is intended behavior since an undirected edge_label_index would just blow up the amounts of labels artificially since one usually uses a symmetric encoder to predict the links in this scenario. If you still want to incorporate both directions as part of your labels, you can simply flip the matrix and use it for supervision as well. WDYT?

[saiden89]

I understand the reasoning, thanks, but I don't think it's so far-fetched the idea that someone would use an asymmetric decoder (say, an MLP) to predict the edges based on two node's concatenated emeddings.
From a user perspective (especially from a novice) I think there is an expectation that such major conversions should not pass silently and with no documentation to support the decision.
I you want I'd be happy to help in this regard :).

[rusty1s]

I would very much appreciate help here. We can update the doc-string for sure. If you think this is absolutely necessary, we can also think about adding an argument to return undirected edge labels.

[saiden89]

I can submit a PR in the following days for updating the docstring. Regarding feature enhancement, is there a way to check where community and developer consensus lies (open an issue?). I'm kind on the fence, on one hand more features are often nice, on the other hand I wouldn't want to bloat the codebase with useless features.

[rusty1s]

We can create an issue around this and try to get people's opinion in.

[saiden89]

Discussion continues on #5190.