Behind my comments on issue 143: acp:apply* relations are confusing and issue 149: proposal: generalise acp:access lies my experience developing the rww-play implementation of Solid.

In rww-play I implemented a simple scheme where ACR can themselves have ACR. This has the following advantages:

1. It is simple: any resource can have an have a Link: ... rel="acp" ... header that specifies who can view and edit the resource. ACRs can be their own ACRs. (or else we'd have an infinite regress)
2. Hence a client can dereference any link it comes across, and then only needs to follow one procedure to determine what it needs to do to view or edit the resource - namely follow the Link: ... rel="acp" ... header.
3. There is no need to have triple based access control within an ACR. If a client can edit an ACR it can change all triples therein. Neither the client nor the server needs to worry about some triples being editable in a resource and others not being editable.
4. We can imagine much more sophisticated granularity of access control. A resource R1 may only be viewable by US citizens. The ACR for R1 may only be editable - as specified by the ACR of the ACR of R1 - by people of security clearance level 1 ... Actually it is easy to implement a Locked policy by having all ACRs have a Link: ... rel='acp' to one root ACR that gives rights to the owner of the Pod.

What I did not implement, and I think we can inspire ourselves by the work on ACP here, is a way to describe ACRs on ACRs.

Here is a sketch of what it could look like. (I did not add a root ACR but that would just follow the pattern below, and would thus give us the same effect as the accessLocked I think).