Page History

...

See Pattern 1.2 in https://tools.ietf.org/html/rfc7089#page-18 for details.

Support Datetime negiotation for LDPRvs

...

• GET requests to LDPRv URIs must support the 'Accept-Datetime' header
• It must follow the syntax outlined in https://tools.ietf.org/html/rfc7089#section-2.1.1
• The response must contain headers as outlined in ticket <LDPRm GET response>
• When a datetime is provided, Fedora will respond with the LDPRm chronologically nearest to the given header as follows:
  • See: Datetime negotiation example

Add versioning headers for LDPRm HEAD/GET responses

...

• Add HTTP header Link: rel="timegate" to the LDPRv
• Include 'Link: rel="timemap"' on versioned resource pointing to LDPCv
• add 'original' link header referencing LDPRv
• Add 'Content-Location' header
• Add 'Memento-Datetime' header

Support OPTIONS request on LDPRms

Response to include header 'Allow: GET, HEAD, OPTIONS, DELETE'

Support OPTIONS request on LDPRms

Response to include header 'Allow: GET, HEAD, OPTIONS, DELETE'

Prevent modification requests to LDPRm

...

DELETE -  If a resource is deleted from the repository, it appears as if all triples across the repository that have that resource as an object will get removed.  Even in a versioned resource.  According to the API spec, mementos need to be immutable.  This particular behavior of cleaning up will have to change where mementos are concerned.  

PUT requests PUT requests to LDPRv (work in progress)

...

• 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.
• If a Memento-Datetime header is provided as part of this POST request, then the newly created LDPRm must attempt 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.
• 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 Memento DateTime Section of the Memento spec 

Delete a LDPCv

Delete a LDPCv

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

• Deletes the LDPCv, which has the affect of also deleting all of the LDPRm's contained by it.
• The versioning interaction model is removed from the LDPRv (http://fedora.info/definitions/fcrepo#VersionedResource).

Delete a LDPRv

(this one might not actually be a ticket, since the behavior, though not totally correct, is in line with what we're targeting.)

...

• 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

HEAD / GET on LDPCv

• Must indicate TimeMap in the same way 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'.

Jira
server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2623

Enable Versioning on

...

a new LDPR

Note: this is still under discussion since an empty PUT to an LDPR may not be valid.

A PUT request to an Existing LDPR will make a resource versionable 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. The versioning type A LDPR will be added to the LDPR, making it created as a LDPRv with the versioning type.

2. A LDPCv will be created for the LDPRv

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

Enable Versioning on a new LDPR

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

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

The newly created LDPCv:

...

The newly created LDPCv:

• must not be a child of the LDPRv
• must be a LDPC ( https://fcrepo.github.io/fcrepo-specification/#LDPC )
• must be track its relationship to the LDPRv
• Note: it will be replacing the current "fcr:versions" path, which was previously used to access modeshape versions.  Versioning will no longer be using built in modeshape tree snapshotting features features.

Enable Versioning on an Existing LDPR

Note: this is still under discussion since an empty PUT to an LDPR may not be valid.

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 for the LDPRv

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

...

Restore a LDPRm

Discusssion of the details for this feature are still ongoing at https://github.com/fcrepo/fcrepo-specification/issues/217

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

...