Closeness centrality does not seem to work with a graph (projected) that has more than one node types.
When I run the code below for a subgraph with one node type I get results as expected. But running closeness on a projected subgraph with two node types returns closeness centrality 0.
CALL algo.closeness.stream(
'MATCH (g:Graph {_id: "412903bb-28a8-44c9..."})-[:NODES]->(n:Node)
RETURN id(n) as id',
'MATCH (g:Graph {_id: "412903bb-28a8-44c9..."})-[:NODES]->(n:Node)
MATCH (n)-[]->(m:Node)<-[:NODES]-(g) WHERE n <> m
RETURN id(n) as source, id(m) as target',
{graph:'cypher'}
) YIELD nodeId, centrality
WITH algo.asNode(nodeId) as node, centrality
ORDER BY centrality
RETURN node.name, centrality as closeness
You may have different types of nodes (like below) connected to one another, and you may want take them as the same type for calculation purposes. Why does the graph projection take node types into consideration anyway?
I don't see how having a common label for :Graph and :Node nodes will help. :Graph is just an identifier of a subgraph that points to all the :Node nodes.
The problem I point here is why there is no consistency between algo.closeness and other algo functions such as algo.eigenvector or algo.similarity.jaccard. They all take a list of nodes and a lists of relationships and return a graph result regardless of input node types, it just sees the node ids anyway.
Why does algo.closeness take node types into account in its calculation? It should just work like other algo functions, just take in ids and return the metrics for each node. @michael.hunger should I use the Neo4j Graph Data Science version instead? Thanks!
@arikan My understanding is that Graph Algorithm package is deprecated for all versions of neo4j versions. Yeah, surely migrate to GDS - it has new features, new algorithms and documentation is easier to understand.