You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Specification

  • 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
  • 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?
  • 4.1.3.1 In supporting PUT to LDPRv, which would cause an LDPRm to be created, is this just in support of server managed versions?  Or is PUT to an LDPRv intended to be addressable separately from a LDPR so as to trigger this behavior?
  • 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.
  • 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?
    • In the modeshape implementation, 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.3.5 What is the expected behavior if a POST to an LDPCv is made which specifies a Memento-Datetime which 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?

Delta

With Fedora API Specification:

  • 4.1.1 Add HTTP header Link: rel="timegate" referencing itself
    • versions will need to be accessible via the TimeGate, which is the LDPRv, versus TimeMap (which is what '/path/to/object/fcr:versions' currently is).  New URL for TimeGate access to versions?  Actually, a URL with fcr:versions in it could probably be returned, so long as negotiation on what the DateTime the user wants happens via the TimeGate, which is the LDPRv itself. 
  • 4.1.2.1include 'Vary: Accept-Datetime' header in response
  • 4.2.3 When requesting a Memento or a TimeGate, a Link header must be returned with type of "original" which points to the URI of the original.  See 2.2.1. Link Relation Type "original"
  • 4.2.3 "Memento-Datetime" should be returned when making a GET against a memento, indicating the timestamp of the memento
  • 4.1.2.2 The TimeMap link may support "from" and "until" attributes, do we want to provide/support these?  See 2.2.3. Link Relation Type "timemap"
  • 4.1.2.1 How is fedora going to handle Accept-Datetime negotiation?  nearest version?  nearest version before requested time?  Or is it even going to be used this way?  See 3.1. Datetime Negotiation (first paragraph after example steps)
  • 4.3.5 Are we going to need to take away the ability to provide version labels since they are not a part of the Memento API and not mentioned in the fcrepo spec?
  • It would be helpful to record which Datetime Negotiation pattern the modeshape implementation uses in documentation

With Memento Specification:


  • 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. 

Draft Tickets

Add versioning response headers to LDPRv HEAD/GET responses

Responses to HEAD and GET requests to LDPRv's (regular LDPR's which are or can be versioned) should return the following headers:

  • Vary: accept-datetime
  • Include 'Link: rel="timegate"' referencing itself. This is always present for versionable LDPR's.
  • Include 'Link: rel="timemap"' on versioned resource pointing to LDPCv. This is only present if this LDPRv has been previously versioned/has a LDPCv.
  • Since the LDPRv is also its own timegate, it must return an 'original' link header referencing itself
  • Include 'Content-Location' header ?
  • Add 'Memento-Datetime' header ?

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

Support Datetime negiotation for LDPRv's

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.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:
    • Returns nearest LDPRm with Memento-Datetime <= provided Accept-Datetime
    • otherwise, return nearest LDPRm with Memento-Datetime > Accept-Datetime
    • If no LDPRm's exist, then the LDPRv is returned

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 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'

PUT requests to LDPRv (work in progress)

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

If a Accept-Datetime is provided on a regular PUT request to an LDPRv

  • 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


POST request to LDPCv to create new LDPRm

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

  • Creates LDPRm from the current LDPRv, as is the current behavior in fcrepo
  • If a Memento-Datetime header is provided as part of this POST request, then the newly created LDPRm must honor
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.