Page History

...

1. Ignore any ACL on a versioned resource; instead honor the ACL that the Original Resource (LDPRv) has.  Essentially the versioned resource 'inherit' the ACL from the version container (LDPCv). 
   1. If the LDPCv has no ACL - default back to the LDPRv??  Or perhaps the LDPCv points to some sort of default ACL?
   2. This scenario allows for the LDPRv to potentially have a separate ACL from the versions of itself. 
2. Any versioned resource always has the same ACL as the Original Resource (LDPRv).  In other words, the ACL on the LDPCv always applies to all versions of the resource. If the ACL is changed or updated on the LDPCv, all the versions then have that same change/update.  The ACL would be stored and referenced from the LDPRv (not stored in the versions). 
3. When a LDPR is versioned, honor the ACL that's on the versioned resource that was there at the time the version was created.
   1.  If the URL of the ACL pointed to never changes, then all the versions will have the same ACL restrictions as the LDPRv. 
   2.  If the URL of the ACL pointed to changes over time, then the versions may have different ACL restrictions, from both each other and the Original Resource.
   3. This scenario gets complicated quickly, especially when an ACL that's on a version, but no longer on the LDPRv, gets removed from the system.  
4. Version the ACL along with the LDPRv.  
   1. This would be a tricky scenario to work with as an admin would potentially be unable to manage access appropriately. Given that mementos are immutable, the versioned ACLs wouldn't be able to change and an admin would be unable to change authorizations for versions of resources. 

URIs in LDPRm, and the "multiple parent" problem

It seems to be difficult to determine the identity of the "parent" of a resource via ldp:contains with versioning.  

1. LDPR contains LDPR (without versioning).  This one is simple.  A ldp:contains A/B.  A/B has exactly one parent:  A.
2. LDPRv contains LDPRv.  This one is also pretty simple.  A ldp:contains A/B, A/B has exactly one parent: A.
3. LDPRm contains LDPRv.  This one is a little less straightforward.  There could be multiple resources that assert they contain B:  What does a client need to know the identity of the resource that contains B?
   1. A_m1 (an LDPRm for A):  <A_m1> <ldp:contains> <B> 
   2. A_m2 (a different LDPRm for A): <A_m2> <ldp:contaiins> <B>
   3. A (an LDPRv): <A> <ldp:contains> <B>
4. LDPRm contains LDPRm. This one causes problems due to the fact that an LDPRm MUST be contained by an LDPCv as well.  For memento B_m1 of resource B What does a client need to know in order to determine which one is B_m1's parent via containment?:
   1. A_m1 (an LDPRm for A):  <A_m1> <ldp:contains> <B_m1> 
   2. A_m2 (a different LDPRm for A): <A_m2> <ldp:contaiins> <B_m1>
   3. B_cv (The LDPCv for B):  <B_cv> <ldp:contains> <B_m1>

Snapshot Versioning (problem ?)

The current fedora implementation creates (and links to) new LDPRs when a non-empty LDPRv is versioned. These resources are neither an LDPRv, nor LDPRm

For example, consider a container A  and A/B where A ldp:contains B.

Creating a version v1 of <A> creates a resource <A/fcr:versions/v1>.  This is essentially an LDPRm, and contains triple <A/fcr:versions/v1> ldp:contains <A/fcr:versions/v1/B>.  

Issues are:

1. <A/fcr:versions/v1/B> is a new LDPR, bit its relationship to versioning is not defined in any spec.  It is not an LDPRv, nor an LDPRm.  It does not the have equivalent of an LDPCv associated with it.
2. There is no explicit or implicit relationship between <A/fcr:versions/v1/B> and <B>

All of this may be fine, but it lies outside of any specification.  Essentially, "when you create a new version of a resource, that resource versions now points new and different things that it didn't previously point to, and have nothing to do with versioning"