Skip to content

Update Docs towards New Version Deploy #155

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 19 commits into from
Jun 5, 2025
Merged
Show file tree
Hide file tree
Changes from 17 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions .wordlist.txt
Original file line number Diff line number Diff line change
Expand Up @@ -360,3 +360,21 @@ propname
propvalue
ro
GenAI

WCC
SPpath
SSpath

undirected
preprocessing
subgraphs
directionality
iteratively
analytics
Pathfinding
Brin
Sergey
lookups
componentId
Betweenness
betweenness
91 changes: 91 additions & 0 deletions algorithms/betweenness_centrality.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
---
title: "Betweenness Centrality"
description: "Measures the importance of nodes based on the number of shortest paths that pass through them."
parent: "Algorithms"
---

# Betweenness Centrality

## Introduction

Betweenness Centrality is a graph algorithm that quantifies the importance of a node based on the number of shortest paths that pass through it. Nodes that frequently occur on shortest paths between other nodes have higher betweenness centrality scores. This makes the algorithm useful for identifying **key connectors** or **brokers** within a network.

## Algorithm Overview

The core idea of Betweenness Centrality is that a node is more important if it lies on many of the shortest paths connecting other nodes. It’s particularly useful in understanding information flow or communication efficiency in a graph.

For example, in a social network, a person who frequently connects otherwise unconnected groups would have high betweenness centrality.

## Syntax

The procedure has the following call signature:
```cypher
CALL algo.betweenness({
nodeLabels: [<node_label>],
relationshipTypes: [<relationship_type>]
})
YIELD node, score
```

### Parameters

| Name | Type | Description | Default |
|-----------------------|---------|-------------------------------------------------|---------|
| `nodeLabels` | Array | *(Optional)* List of Strings representing node labels | [] |
| `relationshipTypes` | Array | *(Optional)* List of Strings representing relationship types | [] |

### Yield

| Name | Type | Description |
|---------|-------|-----------------------------------------------|
| `node` | Node | The node being evaluated |
| `score` | Float | The betweenness centrality score for the node |

## Example:

Lets take this Social Graph as an example:
![Social Graph](../images/between.png)

### Create the Graph

```cypher
CREATE
(a:Person {name: 'Alice'}),
(b:Person {name: 'Bob'}),
(c:Person {name: 'Charlie'}),
(d:Person {name: 'David'}),
(e:Person {name: 'Emma'}),
(a)-[:FRIEND]->(b),
(b)-[:FRIEND]->(c),
(b)-[:FRIEND]->(d),
(c)-[:FRIEND]->(e),
(d)-[:FRIEND]->(e)
```

### Run Betweenness Centrality - Sort Persons by importance based on FRIEND relationship

```cypher
CALL algo.betweenness({
'nodeLabels': ['Person'],
'relationshipTypes': ['FRIEND']
})
YIELD node, score
RETURN node.name AS person, score
ORDER BY score DESC
```

Expected result:

| person | score |
|-----------|--------|
| `Bob` | 6 |
| `Charlie` | 2 |
| `David` | 2 |
| `Alice` | 0 |
| `Emma` | 0 |

## Usage Notes

- Scores are based on **all shortest paths** between node pairs.
- Nodes that serve as bridges between clusters tend to score higher.
- Can be computationally expensive on large, dense graphs.
97 changes: 97 additions & 0 deletions algorithms/bfs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
---
title: "BFS"
description: "Breadth-First Search (BFS) explores a graph level by level, visiting all neighbors of a node before moving to the next depth."
parent: "Algorithms"
---

# BFS

## Overview

The Breadth-First Search (BFS) procedure allows you to perform a breadth-first traversal of a graph starting from a specific node.
BFS explores all the nodes at the present depth before moving on to nodes at the next depth level.
This is particularly useful for finding the shortest path between two nodes or exploring a graph layer by layer.

## Syntax

```
CALL algo.bfs(start_node, max_depth, relationship)
YIELD nodes, edges
```

## Arguments

| Name | Type | Description | Default |
|--------------|----------------|-----------------------------------------------------------------------------|------------|
| start_node | Node | Starting node for the BFS traversal | (Required) |
| max_depth | Integer | Maximum depth to traverse | (Required) |
| relationship | String or null | The relationship type to traverse. If null, all relationship types are used | null |

## Returns

| Name | Type | Description |
|-------|------|----------------------------------------------|
| nodes | List | List of visited nodes in breadth-first order |
| edges | List | List of edges traversed during the BFS |

## Examples

### Social Network Friend Recommendations

This example demonstrates how to use BFS to find potential friend recommendations in a social network.
By exploring friends of friends, BFS uncovers second-degree connections—people you may know through mutual friends—which are often strong candidates for relevant and meaningful recommendations.

#### Create the Graph

```cypher
CREATE
(alice:Person {name: 'Alice', age: 28, city: 'New York'}),
(bob:Person {name: 'Bob', age: 32, city: 'Boston'}),
(charlie:Person {name: 'Charlie', age: 35, city: 'Chicago'}),
(david:Person {name: 'David', age: 29, city: 'Denver'}),
(eve:Person {name: 'Eve', age: 31, city: 'San Francisco'}),
(frank:Person {name: 'Frank', age: 27, city: 'Miami'}),

(alice)-[:FRIEND]->(bob),
(alice)-[:FRIEND]->(charlie),
(bob)-[:FRIEND]->(david),
(charlie)-[:FRIEND]->(eve),
(david)-[:FRIEND]->(frank),
(eve)-[:FRIEND]->(frank)
```

![Graph BFS](../images/graph_bfs.png)

#### Find Friends of Friends (Potential Recommendations)

```
// Find Alice's friends-of-friends (potential recommendations)
MATCH (alice:Person {name: 'Alice'})
CALL algo.bfs(alice, 2, 'FRIEND')
YIELD nodes

// Process results to get only depth 2 connections (friends of friends)
WHERE size(nodes) >= 3
WITH alice, nodes[2] AS potential_friend
WHERE NOT (alice)-[:FRIEND]->(potential_friend)
RETURN potential_friend
```

In this social network example, the BFS algorithm helps find potential friend recommendations by identifying people who are connected to Alice's existing friends but not directly connected to Alice yet.


## Performance Considerations

- **Indexing:** Ensure properties used for finding your starting node are indexed for optimal performance
- **Maximum Depth:** Choose an appropriate max_depth value based on your graph's connectivity; large depths in highly connected graphs can result in exponential growth of traversed nodes
- **Relationship Filtering:** When applicable, specify the relationship type to limit the traversal scope
- **Memory Management:** Be aware that the procedure stores visited nodes in memory to avoid cycles, which may require significant resources in large, densely connected graphs

## Error Handling

Common errors that may occur:

- **Null Starting Node:** If the start_node parameter is null, the procedure will raise an error; ensure your MATCH clause successfully finds the starting node
- **Invalid Relationship Type:** If you specify a relationship type that doesn't exist in your graph, the traversal will only include the starting node
- **Memory Limitations:** For large graphs with high connectivity, an out-of-memory error may occur if too many nodes are visited
- **Result Size:** If the BFS traversal returns too many nodes, query execution may be slow or time out; in such cases, try reducing the max_depth or filtering by relationship types
181 changes: 181 additions & 0 deletions algorithms/cdlp.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,181 @@
---
title: "Community Detection using Label Propagation (CDLP)"
description: "Community Detection using Label Propagation (CDLP)"
parent: "Algorithms"
---

# Community Detection using Label Propagation (CDLP)

## Overview

The Community Detection using Label Propagation (CDLP) algorithm identifies communities in networks by propagating labels through the graph structure.
Each node starts with a unique label, and through iterative propagation, nodes adopt the most frequent label among their neighbors, naturally forming communities where densely connected nodes share the same label.

CDLP serves as a powerful algorithm in scenarios such as:
- Social network community detection
- Biological network module identification
- Web page clustering and topic detection
- Market segmentation analysis
- Fraud detection networks

## Algorithm Details

CDLP initializes by assigning each node a unique label (typically its node ID).
The algorithm then iteratively updates each node's label to the most frequent label among its neighbors.
During each iteration, nodes are processed in random order to avoid deterministic bias.
The algorithm continues until labels stabilize (no changes occur) or a maximum number of iterations is reached.
The final labels represent community assignments, where nodes sharing the same label belong to the same community.

The algorithm's strength lies in its ability to discover communities without requiring prior knowledge of the number of communities or their sizes.
It runs in near-linear time and mimics epidemic contagion by spreading labels through the network.

### Performance

CDLP operates with a time complexity of **O(m + n)** per iteration, where:
- **n** represents the total number of nodes
- **m** represents the total number of edges

The algorithm typically converges within a few iterations, making it highly efficient for large-scale networks.

## Syntax

```cypher
CALL algo.labelPropagation([config])
```

### Parameters

The procedure accepts an optional configuration `Map` with the following parameters:

| Name | Type | Default | Description |
|---------------------|---------|------------------------|----------------------------------------------------------------------------------|
| `nodeLabels` | Array | All labels | Array of node labels to filter which nodes are included in the computation |
| `relationshipTypes` | Array | All relationship types | Array of relationship types to define which edges are traversed |
| `maxIterations` | Integer | 10 | Maximum number of iterations to run the algorithm |

### Return Values
The procedure returns a stream of records with the following fields:

| Name | Type | Description |
|---------------|---------|---------------------------------------------------------------------|
| `node` | Node | The node entity included in the community |
| `communityId` | Integer | Identifier of the community the node belongs to |

## Examples

Let's take this Social Network as an example:

```
(Alice)---(Bob)---(Charlie) (Kate)
| | |
(Diana) | (Eve)---(Frank)
| | | |
(Grace)--(Henry) (Iris)--(Jack)
```

There are 3 different communities that should emerge from this network:
- Alice, Bob, Charlie, Diana, Grace, Henry
- Eve, Frank, Iris, Jack
- Any isolated nodes

### Create the Graph

```cypher
CREATE
(alice:Person {name: 'Alice'}),
(bob:Person {name: 'Bob'}),
(charlie:Person {name: 'Charlie'}),
(diana:Person {name: 'Diana'}),
(eve:Person {name: 'Eve'}),
(frank:Person {name: 'Frank'}),
(grace:Person {name: 'Grace'}),
(henry:Person {name: 'Henry'}),
(iris:Person {name: 'Iris'}),
(jack:Person {name: 'Jack'}),
(kate:Person {name: 'Kate'}),

(alice)-[:KNOWS]->(bob),
(bob)-[:KNOWS]->(charlie),
(alice)-[:KNOWS]->(diana),
(bob)-[:KNOWS]->(henry),
(diana)-[:KNOWS]->(grace),
(grace)-[:KNOWS]->(henry),
(charlie)-[:KNOWS]->(eve),
(eve)-[:KNOWS]->(frank),
(eve)-[:KNOWS]->(iris),
(frank)-[:KNOWS]->(jack),
(iris)-[:KNOWS]->(jack)
```

### Example: Detect all communities in the network

```cypher
CALL algo.labelPropagation() YIELD node, communityId RETURN node.name AS name, communityId ORDER BY communityId, name
```

#### Expected Results
| name | communityId |
|------------|-------------|
| `Alice` | 0 |
| `Bob` | 0 |
| `Charlie` | 0 |
| `Diana` | 0 |
| `Grace` | 0 |
| `Henry` | 0 |
| `Eve` | 2 |
| `Frank` | 2 |
| `Iris` | 2 |
| `Jack` | 2 |
| `Kate` | 10 |

### Example: Detect communities with limited iterations

```cypher
CALL algo.labelPropagation({maxIterations: 5}) YIELD node, communityId
```

### Example: Focus on specific node types

```cypher
CALL algo.labelPropagation({nodeLabels: ['Person']}) YIELD node, communityId
```

### Example: Use only certain relationship types

```cypher
CALL algo.labelPropagation({relationshipTypes: ['KNOWS', 'FRIENDS_WITH']}) YIELD node, communityId
```

### Example: Combine node and relationship filtering

```cypher
CALL algo.labelPropagation({
nodeLabels: ['Person'],
relationshipTypes: ['KNOWS']
}) YIELD node, communityId
```

### Example: Group communities together

```cypher
CALL algo.labelPropagation() YIELD node, communityId
RETURN collect(node.name) AS community_members, communityId, count(*) AS community_size
ORDER BY community_size DESC
```

#### Expected Results
| community_members | communityId | community_size |
|----------------------------------------------------------|-------------|----------------|
| `["Alice", "Bob", "Charlie", "Diana", "Grace", "Henry"]` | 0 | 6 |
| `["Eve", "Frank", "Iris", "Jack"]` | 2 | 4 |
| `["Kate"]` | 10 | 1 |

### Example: Find the largest communities

```cypher
CALL algo.labelPropagation() YIELD node, communityId
RETURN communityId, collect(node) AS nodes, count(*) AS size
ORDER BY size DESC
LIMIT 1
```

Loading
Loading