Hello,
As you can see my title, I am wondering that what is the point of using different types of edges while using a machine learning algorithm like FastRP.
Right now I have 7 types of edges in my graph but they do not have any properties. They only have different names, that's all.
While I am creating a in-memory graph, I include these 7 types of edges. I realized that they consume too much memory, one of them covers 9-10 GB memory.
-
I want to decrease these 7 types of edges to 1 type and expecting that 1 type of edge consume 9-10GB. Old one (7 types) consumes 7 x 10GB = 70 GB. So I have more 60 GB free. Is it possible ?
-
Does it matter on the FastRP algorithm ? Using no-property 7 types of edges vs no-property 1 type edge.
Thank you so much.
Note: In-Memory graph creating code:
MATCH
WHERE
WITH gds.alpha.graph.project
Hi Berkay,
Before answering your questions, I want to clarify your question.
You currently have a model that might look like:
In your updated scenario, you would like to collapse all the relationships to a single type to reduce the number of total relationships before creating the node embedding.
Is this correct?
Hello Alison,
Not exactly. But I need to clear one thing before my model, there is no property right now and there won't be any in the future. So we don't need "property" word in this topic.
Here is my model ( Sorry for my drawing :( )
You're drawing is great. (You can also check out arrow.app for future drawings.)
So the total number of relationships doesn't change, just the type of relationship changes. Yes?
Thank you 
Yes, exactly. The number I am seeing right of the Neo4j Browser won't change. Just decrease the type of the edges to 1 from 7.
For example, I am using gds.graph.project for creating a named graph. I use the code standing below as relationship configuration.
TYPE_1: {type: 'TYPE_1', orientation: 'UNDIRECTED'},
TYPE_2: {type: 'TYPE_2', orientation: 'UNDIRECTED'},
TYPE_3: {type: 'TYPE_3', orientation: 'UNDIRECTED'},
TYPE_4: {type: 'TYPE_4', orientation: 'UNDIRECTED'},
TYPE_5: {type: 'TYPE_5', orientation: 'UNDIRECTED'},
TYPE_6: {type: 'TYPE_6', orientation: 'UNDIRECTED'},
TYPE_7: {type: 'TYPE_7', orientation: 'UNDIRECTED'},
I want to change that to this:
TYPE_ALL: {type: 'TYPE_ALL', orientation: 'UNDIRECTED'},
Probably I will use less memory while creating named graph but I am not sure about is it affecting the FastRP embeddings? They are just names and doesn't have properties so my influence is they won't affect too.
Hello @berkay.coskuner98 ,
thats a very good question.
For embedding algorithms, I can answer it depends on if the embedding can encapsulate the relationship type information. Specifically, you might want to look into HashGNN (HashGNN - Neo4j Graph Data Science).
More general, you can use the algorithm traits at the top of a page to see if multiple relationship types are useful. In our preview does we splitted the Heterogeneous trait into Heterogeneous nodes and Heterogeneous relationships to make it easier.
Most of our algorithms do not distinct between relationship types, but it can be useful if you plan to run algorithms on subsets of your projection (by using the relationshipTypes filter on the algorithm).
For the memory aspect, its true that only projection them as one relationship type will save memory as we can compress them better.
TLDR: For FastRP, you dont need to keep the relationship types but you can might want to look into HashGNN.
Hello Florentin,
Thank you for your reply.
I understand your answer. But now, it seems to me a little bit meaningless that different types of edges, only their names are different, to what extent can it contribute to learning?
I am satisfied with the memory aspect, thank you so much.
It can be useful for instead inside Link Prediction pipelines, where you need to distinguish between the target and context relationship type.
Also you can project your whole graph and then run your graph algorithms on different subgraphs by using the relationshipTypes filter on most of the algorithm calls.
Hope this makes the purpose of having multiple rel types projected
Hello Florentin,
Now I am totally satisfied.
Thank you for your reply.
1 Like
