...

To summarize:
1) If no Accept-Datetime is provided, then the LDRPv is returned
2) If Accept-Datetime is provided, then the nearest LDPRm with a Memento-Datetime < than requested time, or LDPRv with created time < than requested time is returned.

Anchor
ref-int ref-int

Immutable LDPRms and Relaxing Referential Integrity

Fcrepo/Memento defines a past version of a LDPRm (aka a memento) as a fixed representation of the original LDPR at the time the version was created. However, a memento can be incorrectly modified in the following scenario, given memento M of original resource O, and another resource R:

1. M contains relation dc:related to R
2. Delete resource R
3. Modeshape automatically removes dc:related relation from M
4. M no longer matches O at the time that M was created.

This is because modeshape fedora maintains referential integrity - if a resource is deleted, all references to that resource are removed as well.

To address this, requirements for referential integrity would be relaxed for mementos such that they could continue to refer to the deleted resource. This means that mementos could have triples that reference objects that no longer exist.

This would come with some implications:

• When restoring a LDPRm, references to would become active again, meaning that they could then be subject to removal. There would likely need to be error reporting to inform clients of this.

Two options for how to handle this would include:

1. When an LDPRm is created from an LDPRv, all references to modeshape nodes would be converted to URIs. Since they would no longer be node references, they would not be cleaned up.
2. Instead of storing a LDPRm as a LDPRS, it could be stored as a RDF serialization of the LDPRS stored to a binary.

Anchor
version-single version-single

Versions will be of individual resources, versus tree snapshots

In Fedora 4, when a version of a resource is created, a snapshot of it and the entire tree of child resources it contains is captured.  Moving ahead, the proposed design would instead only create a version of the requested resource, stopping there rather than versioning its child resources.  The resource would be copied as it is and links to other resources would remain intact.

For example, 

1) Create resources </a> and </a/b> as versionable resources (LDPRvs)
2) Create LDPRm of </a>
  Produces LDPRm </a/fcr:versions/20170919080311> in LDPCv
3) GET LDPRm </a/fcr:versions/20170919080311>, which returns:
  </a/fcr:versions/20170919080311> ldp:contains </a/b>
4) GET LDPRv /a
  </a> ldp:contains </a/b>
5) No LDPRm was created for </a/b>

Implications:

• Resource versions could now be managed individually versus creating unwanted trees when only wanted to version a single resource's metadata.
• Creating a snapshot of an entire tree would need to be triggered with many individual API requests.
• Retrieving or restoring a tree of resources to a particular point in time would require individual API requests with datetime negotiation.
• Creation and management of versions would shift from being a Modeshape provided feature to the Fedora code base.

Draft Tickets

Add versioning response headers to LDPRv HEAD/GET responses

...