This page describes the actions that should and should not result in updating the last-modified date of a resource.
- Binary
- Creating node (should be the same as the created date)
- Updating fcr:metadata properties with PUT or PATCH
- Updating content
- Container
- Creating node (should be the same as the created date)
- Updating properties with PUT or PATCH
- Creating a child resource (results in new ldp:contains property)
- Creating a child in a DirectContainer or IndirectContainer that has the resource as the
ldp:membershipResource
(results in new membership property)
9 Comments
A. Soroka
This is the HTTP last-modified under discussion here?
Esmé Cowles
Yes, and the
fedora:lastModified
triple that drives that.A. Soroka
Hm, that's what I was wondering about. I think those two may actually be different. The HTTP property is about changes in the representation, but the triple is about changes in the resource (so 2d, for example, should change the HTTP property but not the triple).
Esmé Cowles
We are currently not making that distinction: we are just using getLastModifedDate.
For ETags, we are in the process of making them Weak ETags (representing the resource not the representation), but AFAIK, there isn't the same distinction for the HTTP Last-Modified header.
A. Soroka
I know-- I'm suggesting that there should be, and that we have a simple invariant: HTTP last-mod is always equal to or later than
fedora:lastModified.
Esmé Cowles
As long as we are updating the code to explicitly update a property when updates occur, we could conceivably also manage one or more additional properties for when inbound links, Direct/Indirect Container changes, etc. happen that would change some representations.
A. Soroka
Sure, although maybe it needs to be dynamic? My suspicion is that
is about persistence and HTTP last-mod is about the behavior of the API, so thatfedora:lastModified
is stored (and updated as part of persistence workflows) but HTTP last-mod is generated when a response is generated.fedora:lastModified
Esmé Cowles
I think a dynamic HTTP last-modified could be good, and handle the different representations driving by LDP Prefer headers. Though I think that would still require keeping track of various kinds of links that could impact the representation:
A. Soroka
Yeah, there's going to have to be some book-keeping, no doubt. But given that some of these calculations are expensive (and you know how I hate baking into the API assumptions about the ability of a Fedora impl to track inbound links) it would be good for this to be dynamic so that headers could be used to accept or reject various costs.