Reverse member relationship

scossu commented

2026-02-10 22:04:06 +00:00

Owner

The foreseen user workflows for depositing contents may benefit from having a member_of property (attributed to the member) rather than a has_member one (attributed to the container). This for a few reasons:

When editing a LL spreadsheet, it is easier to copy and paste the same container ID on a stack of cells representing members of the same container, than copying and pasting the individual member IDs on a container.
It is easier to visually and mentally navigate the spreadsheet to review the memberships.
One only needs to submit a single resource to add it or remove its membership. Currently, to modify the list of members, the full list of members of the container must be re-submitted.
A much faster method (O(n)) can be easily built for inferring members from source paths, as the path already includes the implicit container. Currently, the method for inferring members is very slow (O(n^2)) as it does a "cross-join" of all the LL entries.

This may be best done before v1.0.0 is released.

The foreseen user workflows for depositing contents may benefit from having a `member_of` property (attributed to the member) rather than a `has_member` one (attributed to the container). This for a few reasons: 1. When editing a LL spreadsheet, it is easier to copy and paste the same container ID on a stack of cells representing members of the same container, than copying and pasting the individual member IDs on a container. 2. It is easier to visually and mentally navigate the spreadsheet to review the memberships. 3. One only needs to submit a single resource to add it or remove its membership. Currently, to modify the list of members, the full list of members of the container must be re-submitted. 4. A much faster method (O(n)) can be easily built for inferring members from source paths, as the path already includes the implicit container. Currently, the method for inferring members is very slow (O(n^2)) as it does a "cross-join" of all the LL entries. This may be best done before v1.0.0 is released.

scossu added this to the v1.0.0 RC milestone

2026-02-10 22:04:06 +00:00

scossu added the

labels

2026-02-10 22:04:06 +00:00

scossu commented

2026-02-13 22:02:08 +00:00

Author

Owner

A caveat about this implementation is that, when updating a single resource as a member of an existing container that has a tree, there is no information on where the new member should be placed in the tree.

The most straightforward course of action is not to update the container tree (or trees, if multiple containers are specified). If the tree must be updated, the container has to be re-submitted including the members arranged by path, as usual.

A caveat about this implementation is that, when updating a single resource as a member of an existing container that has a tree, there is no information on where the new member should be placed in the tree. The most straightforward course of action is not to update the container tree (or trees, if multiple containers are specified). If the tree must be updated, the container has to be re-submitted including the members arranged by path, as usual.

scossu referenced this issue

2026-02-14 15:02:29 +00:00

Show inverse membership in presentation #40

scossu referenced this issue from a pull request that will close it,

2026-02-17 22:39:14 +00:00

Reverse membership and other updates: #43

scossu closed this issue

2026-02-17 22:39:23 +00:00

Rows
Columns

Reverse member relationship #39