...
- 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.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 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.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?
- This could be something we decide - perhaps the new one overwrites the existing one?
- 4.3 There is currently no section defining that GET requests are required for LDPCv
- What is the default serialization?
...