Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HGT for a many(source)-to-one(target) node classification task #36

Open
shaanchandra opened this issue Feb 27, 2021 · 0 comments
Open

Comments

@shaanchandra
Copy link

shaanchandra commented Feb 27, 2021

Hi @acbull ,
Thank you for the great work here! Really appreciate it ! I had the following questoin:

I am trying to benchmark HGT on the Online Retai-2 dataset that has transaction records of the type (invoice_id, stock_id, customer_id, country_id, quantity, price).
I made an artificial node classification task for this where we want to classify the customer nodes as either low, mid, or high activity (based on some segregation of their spending behavior).

So in this case, the customer nodes are the target nodes. For the source nodes, we have 2 options:

  • Have all the other types of nodes (invoice, stock, country) as source nodes to the customer node.

  • Have one type of source node only (say, just stock_id connected to customer). This is similar to the paper-venue problem where there is just one type of source and target nodes. However, in our case, there are MULTIPLE stock_id nodes that connect to a customer node (a customer buys multiple items).

I wanted to know your thoughts on how can the code be adapted for this (if at all? ) Since the current version of tasks seem quite limiting in the sense that there can be just one type of source and target nodes in a heterogenous graph processing where many kinds of nodes exist.

Specifically, I planned to add multiple source nodes to each target node in this way:

train_pairs = defaultdict(list)
valid_pairs = defaultdict(list)
test_pairs  = defaultdict(list)
for target_id in self.config['graph'].edge_list['customer']['stock']['ST_CU']:
    for source_id in self.config['graph'].edge_list['customer']['stock']['ST_CU'][target_id]:
        _time = self.config['graph'].edge_list['customer']['stock']['ST_CU'][target_id][source_id]
        if _time in self.train_range:
            if target_id not in train_pairs:
                train_pairs[target_id].append([source_id, _time])
        elif _time in self.valid_range:
            if target_id not in valid_pairs:
                valid_pairs[target_id].append([source_id, _time])
        else:
            if target_id not in test_pairs:
                test_pairs[target_id].append([source_id, _time])

NOTE: the train_pairs etc are now defaultdict(list) and we append each [source_id, _time] edge information to each target_id key.
However, this would also change the sample_sub_graph() method and all the subsequent methods like to_torch() thereafter.
Especially, how do propose to change for example this part layer_data[_type][_id] = [len(layer_data[_type]), _time] in sample_sub_graph() ? Since now, we have multiple _time instances coming from the multiple source edges?
Essentially what am asking is how do we incorporate the generalized use-case of many source nodes connected to a target node and how to determine the _time information in such case. Does the entire rest of the framework support this more practical use-case?

I am happy to share more information or explain better if this is not clear already!

I also wanted to know why do you call the PV and PF tasks as node classification? It looks more like an edge prediction task between edges of nodes of a graph. This is also more apparent from your code where you mask edges between target and source nodes. In node classification tasks, the labels are not really nodes of the graph. If you are predicting if 2 nodes of a graph are connected then it is a node prediction task isn't it?
Please correct me if I am wrong!

Looking forward to your reply!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant