RDF and centrality
I mentioned before that RDF has an issue with graph machine learning. Centrality is another place where LPGs have a clear advantage.
If you’ve ever tried to run PageRank or betweenness centrality on an RDF dataset, you’ve hit the wall. The problem is structural. RDF stores everything as SPO triples, which is powerful for reasoning and interoperability but graph algorithms assume a clean node-edge-node topology. RDF doesn’t give you that out of the box.
Before you can run a single centrality measure, you need to filter out literal nodes (strings, dates, numbers — pure sinks with no outgoing edges), blanks (structural glue with no real-world identity), type triples (rdf:type turns owl:Class into a massive hub), ontology nodes (rdfs:subClassOf, owl:sameAs definitionally central, semantically meaningless for analytics), reification nodes (if you’ve reified statements, you now have 4 extra triples of noise per fact) and whatnot. That’s a lot of cleaning before you get to the actual question you wanted to answer.
When using Neo4j GDS or Memgraph Sage you are a happy soldier. Node labels are not nodes. Relationship types are not nodes. Properties are not nodes. No projection step, no whitelist, no cleanup ritual. Running PageRank on a Neo4j graph is a single procedure call. Running it on an RDF store requires a SPARQL construct query, a projection to an in-memory graph, and careful namespace filtering , just to get to the starting line.
Before you load your guns. This isn’t a flaw in RDF. The same uniformity that makes OWL reasoning expressive is exactly what makes it awkward for graph analytics. The data model serves two masters and fully satisfies neither. If your use case is graph analytics LPG wins on ergonomics and happiness every time.
The right tool depends on what you’re optimizing for: reasoning and interoperability (RDF), or graph computation (LPG). As always, I’m impartial and only try to emphasize things.