...
See Pattern 1.2 in https://tools.ietf.org/html/rfc7089#page-18 for details.
Jira | ||||||
---|---|---|---|---|---|---|
|
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:
Jira | ||||||
---|---|---|---|---|---|---|
|
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'
Jira | ||||||
---|---|---|---|---|---|---|
|
Support OPTIONS request on LDPRms
Response to include header 'Allow: GET, HEAD, OPTIONS, DELETE'
Jira | ||||||
---|---|---|---|---|---|---|
|
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.
Jira | ||||||
---|---|---|---|---|---|---|
|
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.
Jira | ||||||
---|---|---|---|---|---|---|
|
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
Jira | ||||||
---|---|---|---|---|---|---|
|
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).
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2621
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
Jira | ||||||
---|---|---|---|---|---|---|
|
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 | ||||||
---|---|---|---|---|---|---|
|
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
The versioning type A LDPR will be added to the LDPR, making it created as a LDPRv with the versioning type.
A LDPCv will be created for the LDPRv
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
A LDPR will be created as a LDPRv with the versioning type.
A LDPCv will be created
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.
Jira | ||||||
---|---|---|---|---|---|---|
|
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
The versioning type will be added to the LDPR, making it a LDPRv.
A LDPCv will be created for the LDPRv
A LDPRm will be generated, contained by the LDPCv.
Jira | ||||||
---|---|---|---|---|---|---|
|
...
Restore a LDPRm
Discusssion of the details for this feature are still ongoing at https://github.com/fcrepo/fcrepo-specification/issues/217
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2626
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 LDPRvdoes 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
...