Add a reverse-link index to Collection instead of reverse properties on types

[ehennestad]

There is no way to ask a collection which nodes link to a given node. A "referenced by" view in the GUI, a check before removing a node, or answering "which dataset versions study this subject" all need it, and today each caller has to walk every node's linked properties itself.

Proposal: a reverse-link index on openminds.Collection, not reverse properties on the type classes.

• Collection keeps an index from target identifier to the source nodes and the property names that hold the link. It is built lazily on first use from getLinkedInstances of every node, and invalidated by the existing PropertyWithLinkedInstanceChanged event and by add/remove, so it never goes stale and costs nothing until asked.
• A public method, for example getLinkingNodes(node) returning the source nodes and, as a second output, the property name each link sits in. Optionally Node.linkedFrom(collection) as a convenience that delegates to it.
• Type-level questions stay where they already are: openminds.introspection.MetaType.isLinkedTypeOfAnyProperty and linkedTypeOfProperty answer which types and properties can link to a type; the index answers which nodes do.

Why not reverse properties, the way fairgraph does it

• A reverse link is derived state. As a property it would have to be kept consistent on every assignment, removal and deserialization, excluded from serialization, from the change events and from the required-property logic, and it would put a cycle in every parent-child pair. fairgraph carries exactly that machinery: reverse properties excluded from save, special-cased in queries, aliased on name collisions, filled with lazy placeholders when empty.
• The names do not exist yet. The schemas carry nameForReverseLink on every linked property, and it is null in all 941 occurrences in v5.0 and latest. fairgraph fills the gap with a 258-line hand-written map. If upstream names arrive (there is a branch adding them), they become labels the pipeline can emit as metadata for the index's results, not properties.
• Reverse traversal against the Knowledge Graph is a query-API feature and belongs in openminds-kg-sync (Support the KG query API: query builder, cross-link filters, stored queries ehennestad/openminds-kg-sync#11), not in the object model.

Tests

• Index answers correctly for linked, mixed-type and embedded-then-linked cases (a link inside an embedded value is a link from the embedding node).
• Assigning, clearing and re-assigning a linked property updates the answer; removing a node from the collection removes it from the index.
• A node linked from two properties of one source appears once with both property names.
• Cost: building the index for the round-trip fixture collection is not measurably slower than a full getLinkedInstances sweep, since that is all it is.

🤖 Generated with Claude Code