I think we've found that the node similarity procedure solved better solved the problem that users had than the Jaccard one.
With Jaccard you had to build up lists of arrays before computing, whereas with node similarity it computes it based on the graph structure. And the majority of users can solve their problems with node similarity.
Do you have some old code that uses Jaccard n Graph Algos and you're trying to translate it to GDS? Perhaps I can help you translate it if you share the query.
We do consider Jaccard part of the algorithms library, but as you correctly guess, and @markhneedham explained - for performance at scale, Node Similarity or KNN are better choices than Jaccard or Cosine similarity. Node similarity uses the jaccard similarity metric, but it leverages neighboring nodes instead of properties or lists.
We don't have any plans to deprecate or remove Jaccard, but we're not currently working on promoting it to the beta tier. Do you have a use case that can't be addressed with Node Similarity?
Also, since now i will be using gds 1.1.1 and using graph projections, I don't seem to be able to create a graph projection where i reduce the size of the projection filtering on node properties. I see the template below, but i seem unable to
Thank you very much Mark. One other issue:
In our graph model, there exists > 2.6 million Guests. To reduce the size of a graph projection and reduce the memory footprint, we wish to filter the Guests based on a particular node property (call it 'tier'). I have been reviewing the documentation and the only possible method is to use a parameter identifying the value of 'tier' that we wish to filter? Is this correct or is there another way?
Thank you again.