Finding children of a resource in hierharchies - on bidirectional relationships

[joepio]

I want to present users with a hierarchy view that let's them easily see which children and parents a resource has. However, resources only need to define their parent, but not the other way around. So how should a client find the children of a resource? What endpoints or methods should an Atomic Data Server offer to deal with this?

Let the client construct TPF queries using collections

A client can construct a query to find all resources that point to some parent, which inversely means you have found its children.

• No new back-end logic required
• Hard to discover children, requires knowledge of how hierarchies work

Add a /children endpoint / plugin, that returns any children for a resource

• Can be made as a plugin / endpoint , which is where additions should primarily live
• Still hard to discover from a resource what it's children are

Always include (local) children in parent resource

When a commit is created that has a parent relation, update that parent, too, and add it's new child.

• Makes Commit handling and caching more complex
• Makes changes to a resource without any signatures or commits (although that is also done in some dynamic fields of Collections, for example)
• No additional runtime / query cost for server
• Resources become a bit more bloated, especially if a resource has a huge amount of children

Add an inverseOf Property, server finds items

When creating a Property, the user can decide to add an inverseOf Property. When fetching a Resource, the server checks the Properties. If any of these has an inverseOf Property, it will also perform a Query to retrieve these items.

• Can be used for children / parent, but also for all other types of relationships. For example, an Ontology may describe which Classes it has, but these Classes should perhaps also link to the Ontology.
• Makes serialisation far slower, as each property will now need to be checked. However, these are often already present in memory, thus the added cost can be worth it. Also, it is likely that in time, other dynamic properties will emerge.
• Finding the inverse properties can be a big cost, too. Servers will need efficient indexing or caching to keep things snappy. Atomic-Server already does this, though so it should not be a big problem.
• How do we validate these Properties? Only one-way?

Additional thoughts

• This is maybe not just an issue for parent/child relationships, but also for all bidirectional relationships. Ideally, there is a system to keep track of relationships (foreign keys, for example: #43)