Skip to content
This repository has been archived by the owner on Mar 14, 2024. It is now read-only.

Using it with undirected graph #14

Closed
aditya-malte opened this issue Apr 3, 2019 · 5 comments
Closed

Using it with undirected graph #14

aditya-malte opened this issue Apr 3, 2019 · 5 comments

Comments

@aditya-malte
Copy link

Hello,
I'd like to ask how this can be used for a simple undirected graph(without any relationship type)
For example, given a social network graph, where each edge always represents a friendship, would it be possible to produce embeddings?
Can I directly replace the relationship type parameter with "friend" for all edges?

Regards,
Aditya Malte

@ledw
Copy link
Contributor

ledw commented Apr 3, 2019

Hi @aditya-malte, yes you can use it for a social network graph with only one edge type (friendship). We have an example on LiveJournal which is similar to your case. You can check it out at
examples/livejournal.py
In particular, in this example we set the relation type parameter to be 'none' (since there is only one relation in the graph, we do not need to learn relation parameters to distinguish different relations).

@aditya-malte
Copy link
Author

aditya-malte commented Apr 3, 2019

Hello @ledw,
Thank you very much for your quick and apt response.

Regards,
Aditya Malte

@lw
Copy link
Contributor

lw commented Apr 4, 2019

To add to what @ledw said, PBG's data model treats all edges as directed, and this is quite hard to change. However, in all cases I know, it generally works to replace an undirected a <-> b edge with two directed a -> b and b -> a edges. (In fact, even when the original data only contains asymmetric a -> b edges it often helps to artificially add the reverse edges b ~> a of a different relation type).

As for the handling of a single relation type, the "native" (HDF5-based) edgelist format of PBG requires to specify the relation type of all edges, which in this case would be 0 (the first and only item of the relations list in the config file). However the importer from TSV is a bit smarter than that and, if you don't tell it which column contains the relation index, it will assume all edges are of relation type 0.

@aditya-malte
Copy link
Author

aditya-malte commented Apr 4, 2019

Hello @lerks,
Thank you for talking about making it symmetric.
However, I did not understand your second point (and how exactly it is smarter)
Do you mean to say that if there is no column for relation, it will automatically assume "none" relation type.
Eg- having just
node0 node1
Instead of
node0 friend node1.

Thanks
Aditya Malte

@lw
Copy link
Contributor

lw commented Apr 5, 2019

Sorry, I made something very simple sound more fancy than it is.
Suppose John is friends with Jane: "John" is entity number 13, "Jane" is entity number 27, and the friendship relation type is type 0 (the first and only). Then, the HDF5 format represents the triplet as (13, 27, 0), i.e., the 0 must be explicitly specified. However the TSV is allowed to just contain John Jane because the importer will set the relation type to 0 automatically if it's not specified.

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

No branches or pull requests

3 participants