Page History

...

• 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.
  • Need to determine what acceptable validation or outcomes would be for restoring when information could be lost.

...

• Resource versions could now be managed individually versus , rather than creating unwanted trees, when the goal is 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.

...

• A new LDPRm is created from the LDPRv
• The LDPRm will have a Memento-Datetime matching the provided Accept-Datetime
• Response includes 'Link: rel=timemap' pointing to LDPCv for versioned resources
• include 'Vary: Accept-Datetime' header in response
• If the LDPCv for the LDPRv does not already exist, then it will be created and contain the new LDPRm

POST request to LDPCv to create

...

LDPRm

...

Update POST to LDPCv to include support for versioning headers.  In practice, the LDPCv for object with uri <http://localhost/rest/a> would be <http://localhost/rest/a/fcr:versions>

See: https://fcrepo.github.io/fcrepo-specification/#ldpcvpost

• if the request contained a body, then a new LDPRm is created from the submitted body
• if the request body was empty, then a new LDPRm is created from the current version of the LDPRv.
• Creates LDPRm from the current LDPRv, as is the current behavior in fcrepo
• If the LDPCv does not already exist, then it will be created and contain the new LDPRm
• If a Memento-Datetime header is provided as part of this POST request, then the newly created LDPRm must honorattempt to use it as the memento datetime
  • If a LDPRm already exists with the same Memento-Datetime specified, then the LDPRm is not created and a '412 already exists' response is returned.
  Does this need to support body requests? (QUESTION)
• Response from a successful creation should return a LDPRm headers, particularly the Memento-Datetime of the new LDPRm.
• Response must include a Location header referencing the URI of the newly created LDPRm.

Remove Support for Slug Header on POST to LDPCv

• Currently the modeshape fedora will request a "Slug" header be supplied to use as the label of the version. This should be taken out, to be replaced by the Memento-Datetime header, if that's present.  The label should be a timestamp per the the Memento DateTime Section of  of the Memento spec 

Create an LDPCv

...

• This response type is NOT required to include all statements in the LDPCv's graph, only those that are required by the link-format, outlined https://tools.ietf.org/html/rfc7089#page-36
  • Including: URI of LDPRv for this timemap, all LDPRms in this LDPCv with their memento date times, timegate link, link to the LDPCv

HEAD / GET on LDPCv

...

• Must indicate TimeMap in the same way it indicates the Container interaction model of the resource via HTTP headers.

...

•  See: https://fcrepo.github.io/fcrepo-specification/#general-3
• Must return Vary-Post and Vary-Put with value 'Memento-Datetime'.

Answered questions

• 4.1.1 Should the "timegate" link only be present when an object is versioned or should all LDPR that could be versioned provide this link?
  • Yes, it should always be present
  • This seems to imply that all resources are LDPRv's from the start 
• 4.3.1 Why does each memento need a separate TimeMap to be created, rather than sharing one for all of the LDPRv and LDPRm of one LDPR?
  • This was a misinterpretation.  In the modeshape implementation, currently the timemap is the fcr:versions endpoint.
• 4.3.1 LDPCv must not be contained by the LDPRv
  • does that mean that fcr:versions will no longer be a subpath of the LDPR?
  • This only applies to ldp:contains, the uri is irrelevant
• 4.1.2 The Fcrepo spec doesn't mention it directly, but is there a conflict between the Memento "Content-Location" header and External File's "Content-Location"?  Can they both appear in the same response?
  • External File Content-Location header just appears on LDP-NR HEAD/GET requests, while Memento uses the header for responses from LDPRm and maybe LDPRv, both of which are LDP-RS's.  So the headers should not both appear on the same response
• 4.3.1 How do you determine what serializations are available for TimeMaps?  HEAD is not currently supported and is not in the Memento spec.
  
  • GET response formats are not actually listed in any other requests, only for Post and Patch.
  • However, it would likely be helpful to include info about HEAD and GET requests in the spec
    • https://github.com/fcrepo/fcrepo-specification/issues/223

...