preferential_attachment

Generic Description

Multiplies the sizes of two neighbor sets. It is documented separately because similarity orientation, vector dimensions, and set semantics directly affect ranking and interpretation.

Simple example:

RETURN preferential_attachment(['a', 'b'], ['c', 'd', 'e']) AS value

Consumer-Level Explanation

Use it as a link-prediction baseline where high-degree endpoints should score higher. Prefer this function when symbolic graph filters and similarity evidence should remain in one auditable Cypher pipeline.

More Detailed Explanation

preferential_attachment keeps similarity scoring in the same Cypher pipeline as symbolic graph filters and document metadata checks. That lets a query combine labels, relationships, time filters, and embedding or set overlap scores without asking a client to reconcile separate result sets.

Advanced Example

This example applies preferential_attachment after symbolic graph filtering, which keeps hybrid retrieval constraints and similarity scoring in one visible pipeline.

MATCH (d:Document)
WITH d, keys(properties(d.metadata)) AS metadata_keys
RETURN d.title AS document,
       preferential_attachment(metadata_keys, ['kind', 'lang', 'owner']) AS broad_attachment_score
ORDER BY broad_attachment_score DESC

Real Use Cases

• semantic ranking over embedded documents after graph/time filtering
• link-prediction features based on shared neighbors or metadata overlap
• hybrid retrieval where symbolic constraints and vector scores are both visible

Real Limitations And Tradeoffs

• vector functions require compatible dimensions and meaningful embedding spaces
• set-similarity functions treat lists as sets and may ignore duplicate frequency
• a high similarity score is evidence, not proof of domain equivalence