Feature request: nodeSimilarity algorithm on a graph from catalog

[tomasonjo]

Currently, there is no option to define which nodes you want to use for items and which ones you want to use for the weights part of the algorithm. By items and weights I am referring to the implementation of the alpha similarity procedures. As far as I can tell at this moment it defines items and weights based on the direction of the relationship, e.g.:

(a)-->(b) will turn into item: a, weights: collect(b). So the source node a is designated to be treated as an item while the target node b will be treated as weights. If we had already planned for this when we were projecting the graph then no problem, but otherwise there is no option to change the assignment of the item and weights. This is especially a problem when projecting an undirected graph from the start, but also otherwise.

Because you can be dealing with an undirected network, just looking at the relationship direction is not enough. It would be best if we could assign which node labels to use as items and which ones as weights. But because we already support nodeLabels parameter it shouldn't be confusing :confused: And we want to be backward compatible.

It's a tough cookie, one option would be to add something like itemLabels and weightsLabels parameters. But then nodeLabels and relationshipTypes parameters are not really needed and could only confuse a user. This will be a bigger problem with the cosine similarity for example because there we would ideally support both extracting vectors from the graph as we do currently in the example: CREATE (praveena)-[:LIKES {score: 9}]->(indian), but also to support input like node embeddings in the form of a node property. Maybe overall the syntax for similarity algos should be a bit different from other algorithms?