In the current system there is not the idea of a "correct" path through the hasConcept / hasResource "tree" to a specific resource or concept. Any series of steps which arrives at the object is equally valid.

Before what stopped just anyone from editing was the "owner" of the pid in Fedora. Since we are moving away from that permissions model, we need to select who should be able to edit / delete the object.

Multiple users from multiple projects may want to view an object.

We've decided that if the object is held within two research spaces, one project space is the owner, and the other simply has a "link" to the object.

We've also decided to combine this with another issue. This issue has been problematic to scripts and also to how the entire store of data can be conceptualized: we do not have a proper tree structure. The tree we show in the UI can have concepts with themselves as their own grandchildren, and multiple concepts can point to (join on) a single concept or resource.

The way the solution will manifest in the Fedora backend will be through a relationship from the child to the object that will control its permissions. The parent must also have the hasConcept relationship to the child. The name of the new relationship is to be determined. The new relationship is in the opposite direction from the hasConcept relationship that is currently used to create the tree we see in the UI.

The user interface changes are also not fully determined, but in general will change very little and for nearly all users will not change at all. The visible tree will still be based on the hasConcept relationships, but if the child does not have the relationship back to its parent, there will probably be an indicator in some way to show it's a "linked" object instead of a direct child: SID-902 .

This Issue is specifically to cover the PHP handling and manipulations of the new relationship and another will be for the UI changes.