Page History

...

1. Enable Versioning on a LDPR

   1. A PUT or POST request to create an object will make a resource versionable if it includes header Link: rel="type" with type of http://fedora.info/definitions/fcrepo#VersionedResource

      1. A LDPR will be created as a LDPRv with the versioning type.

      2. A LDPCv will be created, from which a TimeMap can be generated.

      3. A LDPRm will be generated, contained by the LDPCv.

      4. Any subsequent responses from the LDPRv will include the appropriate memento links in the header: Timegate, Timemap

   2. A PUT request to an Existing LDPR will make a resource versionable if it includes header Link: rel="type" with type of http://fedora.info/definitions/fcrepo#VersionedResource

      1. The versioning type will be added to the LDPR, making it a LDPRv.

      2. A LDPCv will be created, from which a TimeMap can be generated.

      3. A LDPRm will be generated, contained by the LDPCv.

      4. Any subsequent responses from the LDPRv will include the appropriate memento links in the header: timegate, timemap

2. Check if a resource is versionable and discover the TimeMap/LDPCv

   1. A HEAD request on the LDPRv will return response with Link rel="type" http://fedora.info/definitions/fcrepo#VersionedResource which indicates versioning support and a 'Link rel="timemap"' points to the URL of the LDPCv/TimeMap.

3. Check if the client can create versions

   1. An OPTIONS request on LDPCv/TimeMap that contains an "Allow: POST" header indicates that versions can be created by a client.

4. Creating a new version of a LDPRv 

   • Note: when creating a new version of the LDPRv, only the single resource itself will be versioned. There is no concept of "tree" snapshots anymore. 

   1. A POST request to the LDPCv with an empty body and no "Memento-Datetime" header will cause a new memento of the LDPRv to be created with current date/time. 

   2. A POST request to the LDPCv with header "Memento-Datetime" and no body will create a historic verision with current state of the LDPRv an empty resource with the specificed date/time. 

   3. A POST request to the LDPCv with header "Memento-Datetime" and a body will create a historic version with the specified body and date/time.

   4. A POST request to the LDPCv with a body and no "Memento-Datetime" header to create a version with the specified body and the current datetime.

5. Access the TimeMap (LDPCv) to see what versions exist

   1. A GET request to the LDPCv with the "Accept: application/link-format" header will cause the TimeMap to be returned. 

   2. A GET request to the LDPCv with no "Accept:" header, or one specificying an RDF format will result in the LDPCv being returned in rdf format. 

   3. The response from the GET will include a "Vary-Post: Memento-Datetime" to indicate that a client can request a specific time be associated with a memento when it's created via a POST. 

6. Access an existing version (LDPRm)

   1. A GET request to the TimeGate Resource (the LDPRv itself) with "Accept-Datetime" header specified will return the LDPRm associated with that datetime, or the closest one if there is not an exact match. 

      • example header usage:  "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT"

      • a Link header will be in the response to show the TimeGate URI 

   2. A GET request to LDPRm/Memento (if the LDPRm/Memento has its own URI), will result in the memento being returned if it exists.

   3. See: Datetime negotiation algorithm example for Accept-Datetime negotiation details.

   4. Any response from the LDPRv will include link relation headers of type "timegate" (referring to the LDPRv), "original" (also referring to this LDPRv), and "timemap" (referencing the URI of the LDPCv). 

7. Delete an existing version (LDPRm)

   1. A DELETE request to LDPRm/Memento will result in that memento being deleted. 

8. Restore an existing version (LDPRm) 

   • Note: This interaction still needs to be ironed out as this is currently under discussion in Spec Issue 217

   1. A PUT request to LDPRv/TimeGate with header (can't be Content-Location, but something like it) pointing to the LDPRm/Memento URI to indicate the version to restore- OR - A PATCH request to LDPRv/TimeGate with no body and a "Memento-Datetime"  header indicating the version to restore, will result in the memento that relates to that date/time being restored. 

...

Internal Interactions / Algorithms

...

1. LDPRv  – has child → LDPCv – has children → LDPRm(s)
   as long as we do not generate ldp:contains triples on the LDPRv for the LDPCv using this Predicate. We can ensure that deleting a LDPRv will remove the LDPCv and deleting the LDPCv with delete all the LDPRm(s).
2. How do we do the above filtering? 
   1. Do we add new RDF types (fcrepo-specification issue 233)? 
   2. Do we just add a property to the JCR node?
3. A GET or HEAD request to a timemap (LDPCv) should return all LDRm(s) and their start-end ranges. 
   1. Do we want to generate this list on the fly or store it on the LDPCv and update it on any create/update or delete?
   2. The Memento-Datetime provided when creating a LDPRm (or the current date) indicates the start datetime of that version.
      1. would the end datetime be the next update to the LDPRv?
      2. would it be the lastModified date of the LDPRv?
         
         

Design Implementation

If some of this is crazy or overkill, please don't do it. I'm finding it harder to create interface and classes than I expected without actually writing any code.

• In fcrepo-kernel-api and fcrepo-kernel-modeshape
  • Repurpose isVersioned(), enableVersioning() and disableVersioning() in FedoraResource interface, add getTimeMap() function to get contained LDPCv also in FedoraResourceImpl
  • Create TimeMap interace defining getVersions(), getVersion(final Date/Instant d), createVersion(), createVersion(final Date/Instant d), getOriginal() and Modeshape implementing class
    • VersionService interface and VersionServiceImpl functions/code (if useful) can be moved to TimeMap class. createVersion() for instance.
  • Repurpose FedoraVersion interface and FedoraVersionImpl, perhaps need getOriginal() and getTimemap() for them.
• In fcrepo-http-api
  • Repurpose FedoraVersioning paths for use with TimeMap
  • Repurpose FedoraVersions to allow direct access to a specific Memento via its URI. (/fcrepo/rest/foo/fcr:versions/1234-5678)