As we only render explicitly selected nodes, auto-layouting is less important than on classical hub-and-spoke visualizations. But it might still not hurt to replace the unmaintained webcola layouter with something more modern. Based on what we actually show here, this is the conclusion of a Claude discussion about the topic:
elkjs is the fitting choice here:
- Layered algorithm = genuine top-down hierarchy (rank + cycle-breaking + crossing minimization), not a soft force-pull, and it's designed for general directed graphs, not just trees — matches your "hierarchy isn't inherent, the algorithm imposes it" point.
- separateConnectedComponents covers the multi-selection case natively, no extra code.
- Input is already clean: DiagramModel's nodes/links are just IRI-to-IRI object-property edges (literals never enter the graph), so no pre-filtering needed before handing it to elk.
- Actively maintained, unlike webcola.
- It'd sit alongside the existing forceLayout as a second layoutFunction, no rendering changes.
Only open question to raise with the client/product side: whether hierarchy direction should be based on all object-property edges, or whether certain predicates (e.g. skos:broader, hasPart) should be weighted as the "real" hierarchy edges. That's a product decision, not a technical blocker — elk works either way, it just changes what the layout looks like.
And as @BenjaminHofstetter mentioned, auto-layouting is plain wrong in many cases as we miss out on spatial orientation that way. Mid-term, a "save" functionality might be more useful so we can share visualizations & use it for documentation as well.
As we only render explicitly selected nodes, auto-layouting is less important than on classical hub-and-spoke visualizations. But it might still not hurt to replace the unmaintained webcola layouter with something more modern. Based on what we actually show here, this is the conclusion of a Claude discussion about the topic:
And as @BenjaminHofstetter mentioned, auto-layouting is plain wrong in many cases as we miss out on spatial orientation that way. Mid-term, a "save" functionality might be more useful so we can share visualizations & use it for documentation as well.