--- title: bigclam url: https://nexyron.tech/docs/cypher/procedures/algorithms/community-detection/bigclam description: An overlapping community algorithm based on latent community affiliation strengths. --- # bigclam ## Generic Description An overlapping community algorithm based on latent community affiliation strengths. Simple example: ```cypher CALL nexyron.bigclam() ``` Community detection procedures partition or group nodes by structural affinity. They are useful for segmentation, fraud-ring analysis, recommendation features, and exploratory graph profiling. ## Consumer-Level Explanation Use BigCLAM when you want overlap, but you want that overlap to come from an affiliation model rather than simple label diffusion. Different community algorithms optimize different objectives and assumptions. Modularity methods, label propagation, block models, overlapping memberships, and partition-quality metrics should be chosen for the question, not swapped blindly. ## Conceptual Explanation BigCLAM treats communities more like latent factors that explain why edges exist. Nodes can have strong affiliation to one community and weaker affiliation to others. This is especially useful when overlap is not noise but an expected property of the domain. ## How It Differs From Nearby Algorithms Compared with SLPA and SLLPA, BigCLAM is more model-like and often easier to explain in terms of affiliation strength. Compared with Louvain or Leiden, it is much better when forcing a single community would hide the real structure. Compared with stochastic block models, it is more directly about memberships than about block interaction probabilities. ## When To Choose It - social or creator ecosystems with explicit multi-community participation - B2B account graphs where companies span multiple market segments - security graphs where compromised infrastructure supports several campaigns ## More Detailed Explanation BigCLAM is a good choice when analysts think in terms of memberships or affiliations rather than strict partition boundaries. It often fits product, audience, and threat-intelligence narratives better than single-label algorithms In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with `YIELD` and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example. ## Advanced Example The advanced example keeps `bigclam` in a named Cypher pipeline so the procedure output shape, downstream filters, and returned columns are visible to planner tooling. ```cypher CALL nexyron.bigclam() YIELD node_id, community_id, affiliation_strength RETURN node_id, community_id, affiliation_strength LIMIT 10 ``` ## Real Use Cases - Find users who sit at the overlap of several content tastes or product categories. - Detect shared infrastructure that participates in multiple threat clusters. - Build richer audience segments for marketing and recommendation systems. - compare algorithm output with domain labels or time windows before operationalizing it - feed graph-analytic scores into ranked reports, feature contracts, or investigation queues only after checking the modeling assumptions ## Real Limitations And Tradeoffs - Overlap can become hard to communicate if every node receives too many memberships. - Affiliation-based outputs can be over-read as ground truth rather than one model of the network. - Requires stronger discipline in downstream consumers because “community id” is no longer a single scalar.