POST request to LDPCv to create new
Specification
- 4.1.3.1 In supporting PUT to LDPRv in order to create a LDPRm, is this just included for server managed versions? Or is PUT to an LDPRv intended to be addressable separately from a LDPR so as to trigger this behavior?
- https://github.com/fcrepo/fcrepo-specification/issues/215
- Propose that PUT language is removed and that server managed behaviors are left up to implementors so long as they meet other requirements
- 4.3.1 What is the default serialization for GET requests to LDPCv? The only required encoding is application/link-format.
- This will depend on if the LDPCv remains the same object as the timemap
- 4.3.5 What is the expected behavior if a POST to an LDPCv is made which specifies a Memento-Datetime that is already in use by an existing LDPRm for that LDPRv?
- Having two memento's with the same datetime would result in datetime negotiation yielding indeterminate results.
- Ignore request and return a 412 response? Delete and replace the existing version?
- This could be something we decide - perhaps the new one overwrites the existing one?
- Starting with a 412 response
- 4.5 Does the modeshape fcrepo currently have a server managed option for versioning?
- We need to make sure that a server managed scenario knows how to handle an LDPCv correctly - in that it doesn't version that resource if a user issues a PUT against it (as a user would if they want the original resource LDPRv to get versioned).
...
- 2.2.1 - noted above in 4.2.3: on a GET/HEAD request to a LDPRm or TimeGate (the LDPRv, in this case) a Link header must be returned with relation type of 'original' which points to URI of the original resource (LDPRv)
- 2.2.2 - on a GET/HEAD request to a LDPR or LDPRm, a Link header must be returned with the relation type of 'timegate', which points to the the timegate for the resource.
- multiple timegate Links are possible
- 2.2.3 - on a GET/HEAD request to a LDPR or LDPRm or TimeGate(which is the LDPR, in this case), a Link header must be returned with the relation type of 'timemap', which points to the timemap for the resource.
- support "from" and "until" attributes? These would cause the returned representation of the time map to only include the interval requested.
- the link should make use the 'type' attribute to indicate the mime type of the timemap.
Other questions
- Should LDPRv's return Content-Location and Memento-Datetime headers? The later is required by https://tools.ietf.org/html/rfc7089#section-4.1.2 but may not make sense in fcrepo's usage.
LDPCv Example Response
Code Block | ||
---|---|---|
| ||
# GET request to LDPCv curl http://localhost/rest/a/fcr:versions -H "Accept: application/link-format" -v < HTTP/1.1 200 OK < Date: Thu, 21 Jun 2017 00:06:50 GMT < Server: Apache < Content-Type: application/link-format < Allow: GET, HEAD, OPTIONS, POST, PATCH, DELETE < Accept-Post: text/turtle,text/rdf+n3,text/n3,application/rdf+xml,application/n-triples,application/ld+json,multipart/form-data,application/sparql-update < Accept-Patch: application/sparql-update < Connection: close <http://localhost/rest/a>;rel="original timegate", <http://localhost/rest/a/fcr:versions> ; rel="self";type="application/link-format" ; from="Tue, 20 Jun 2016 18:02:59 GMT" ; until="Wed, 09 Apr 2017 20:30:51 GMT", <http://localhost/rest/a/fcr:versions/20160620180259356>; rel="memento";datetime="Tue, 20 Jun 2016 18:02:59 GMT", <http://localhost/rest/a/fcr:versions/version_1>; rel="memento";datetime="Fri, 06 Jan 2017 18:50:11 GMT", <http://localhost/rest/a/fcr:versions/20170409203051112>; rel="memento";datetime="Wed, 09 Apr 2017 20:30:51 GMT", |
...
- Resource versions could now be managed individually, rather than creating unwanted trees, when the goal is only 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 -
The following headers should be added to responses to HEAD and GET requests to LDPRv's only when the resource is versioned (has the http://fedora.info/definitions/fcrepo#VersionedResource type):
...
See Pattern 1.2 in https://tools.ietf.org/html/rfc7089#page-18 for details.
Support Datetime negiotation for LDPRvs
Jira | ||||||
---|---|---|---|---|---|---|
|
Support Datetime negiotation for LDPRvs
Implement Implement support for datetime negotiation for the retrieval of previous versions of a resource as follows:
- 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.1The response must contain headers as outlined in ticket <LDPRm GET response>
- When a datetime 'Accept-Datetime' is provided:
- Must respond with a 302 status code and an empty body
- Response must contain 'Location' header containing the URI of the LDPRm or LDPRv that was negotiated
- Must contain all other standard LDPRm GET response headers
- When a datetime is provided, Fedora will respond with the past LDPRm chronologically nearest (min-past) , Fedora will respond with the LDPRm chronologically nearest to the given header as follows:
Jira | ||||||
---|---|---|---|---|---|---|
|
Add versioning headers for LDPRm HEAD/GET responses
Responses to LDPRm HEAD and GET requests must include headers as outlined below. A resource is a LDPRm if it is of type http://fedora.info/definitions/fcrepo#VersionedResource
- Add HTTP header LinkAdd 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 'ContentMemento-LocationDatetime' headerAdd 'Memento-Datetime' header
Jira | ||||||
---|---|---|---|---|---|---|
|
Support OPTIONS request on LDPRms
Response to include header 'Allow: GET, HEAD, OPTIONS, DELETE'
Prevent modification requests to LDPRm
PATCH/POST/PUT requests should all return 405 responses
Jira | ||||||
---|---|---|---|---|---|---|
|
Prevent modification requests to LDPRm
PATCH/POST/PUT requests should all return 405 responses
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 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 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
Create an LDPCv
Implement the creation of a LDPCv.
- The LDPCv must not be a child of the LDPRv
- It must be a LDPC ( https://fcrepo.github.io/fcrepo-specification/#LDPC )
- It must contain a relationship to its LDPRv (what would this be? a property?)
Delete a LDPCv
Jira | ||||||
---|---|---|---|---|---|---|
|
Delete a LDPCv
See: https://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
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2621
Delete a LDPRv
(this one might not (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
Jira | ||||||
---|---|---|---|---|---|---|
|
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'.
Enable Versioning on an Existing LDPR
Note: this is still under discussion since an empty PUT to an LDPR may not be valid.
Jira | ||||||
---|---|---|---|---|---|---|
|
Enable Versioning on a new LDPR
A PUT or POST request to create an object will make a resource versionable 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 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
...