Document the algo.pagerank direction property (OUT/IN/BOTH), and correct its default

[robfrank]

The algo.pagerank reference page does not document the direction config property at all, and the shared note that describes direction generically is inaccurate for PageRank specifically. This matters more now than it did: until ArcadeData/arcadedb#6956, direction: 'IN' did not actually work, so there was little to document. It works now, and the page should say so.

Source of truth for all of the below: ArcadeData/arcadedb#6956 (fix(pagerank): honor IN direction in OLTP fallback), plus the class Javadoc on AlgoPageRank and GraphAlgorithms.pageRank after that PR.

1. direction is missing from the algo.pagerank page

src/main/asciidoc/reference/graph-algorithms/centrality.adoc omits it from both the syntax block and the parameters table.

Current syntax line:

CALL algo.pagerank([{dampingFactor: 0.85, maxIterations: 20, tolerance: 0.0001, weightProperty: null}])
YIELD node, score

Suggested:

CALL algo.pagerank([{dampingFactor: 0.85, maxIterations: 20, tolerance: 0.0001, weightProperty: null, direction: 'OUT'}])
YIELD node, score

And a parameters-table row:

Parameter	Type	Required	Default	Description
direction	String	No	OUT	Edge direction rank is pushed along: OUT, IN, or BOTH

2. The default is OUT, not BOTH

src/main/asciidoc/reference/graph-algorithms/notes.adoc says:

• "BOTH" — edges in either direction (default for most algorithms)

That default does not hold for PageRank, which defaults to OUT (AlgoPageRank.execute: an absent or non-String direction yields Vertex.DIRECTION.OUT). A reader who takes the shared note at face value will assume undirected behaviour and get directed scores. Worth an explicit "PageRank defaults to OUT" either on the PageRank page or as a carve-out in the note.

3. "which edges are considered" understates what IN does for PageRank

The shared note frames direction as a filter. For PageRank it is not a filter, it selects which edges rank flows along:

• OUT — rank is pushed along stored edges
• IN — rank is pushed along the reverse of every edge, i.e. PageRank over the reversed graph, without materializing a reversed copy
• BOTH — pushed both ways, treating the graph as undirected

IN is the useful way to ask "which vertices are important because of what points at them, reversed" — for example ranking sources rather than sinks in a citation or link graph. Calling it a filter makes it read like a minor variant of OUT, which is how the bug in #6956 went unnoticed.

4. The dangling-node sentence is direction-dependent

The Description currently reads:

Dangling nodes (no outgoing edges) contribute their rank to all nodes proportionally via the teleportation mechanism.

"No outgoing edges" is only true for OUT. Dangling means "no edges in the direction rank is being pushed" — so under IN a dangling node is one with no incoming edges, and under BOTH one with no edges at all. Suggest rewording to something like "Dangling nodes (no edges in the direction rank is pushed along)".

Note for whoever picks this up

direction applies to both execution paths — the CSR/Graph-Analytical-View path and the OLTP fallback — and they agree on all three values as of #6956. Weighted PageRank (weightProperty set) always uses the OLTP path; that is also currently undocumented and may be worth a sentence, since it has performance implications on a graph that otherwise has a covering view.

[robfrank]

Update: ArcadeData/arcadedb#6956 now also rejects an unrecognised direction for algo.pagerank rather than silently coercing it to OUT, so the docs should say that too:

• OUT, IN, BOTH (case-insensitive) are accepted
• anything else raises an error naming the parameter, rather than falling back
• absent or explicitly null still means the default, OUT

That reinforces point 2 above: since a wrong value is now an error rather than a silent OUT, the shared note claiming BOTH is "the default for most algorithms" is the more likely thing to mislead a reader writing PageRank calls.

Scope note for accuracy: this rejection currently applies to algo.pagerank only. The other ~23 procedures still coerce unknown directions to BOTH via the shared GraphEngine.parseDirection - tracked as ArcadeData/arcadedb#6976. So the generic direction note in notes.adoc should not yet claim repo-wide validation.