This page describes the actions that should and should not result in updating the last-modified date of a resource.

  1. Binary
    1. Creating node (should be the same as the created date)
    2. Updating fcr:metadata properties with PUT or PATCH (question)
    3. Updating content
  2. Container
    1. Creating node (should be the same as the created date)
    2. Updating properties with PUT or PATCH
    3. Creating a child resource (results in new ldp:contains property)
    4. Creating a child in a DirectContainer or IndirectContainer that has the resource as the ldp:membershipResource (results in new membership property)

 

  • No labels

9 Comments

  1. A. Soroka

    This is the HTTP last-modified under discussion here?

  2. Esmé Cowles

    Yes, and the fedora:lastModified triple that drives that.

  3. 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).

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

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

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

          1. A. Soroka

            Sure, although maybe it needs to be dynamic? My suspicion is that fedora:lastModified is about persistence and HTTP last-mod is about the behavior of the API, so that fedora:lastModified is stored (and updated as part of persistence workflows) but HTTP last-mod is generated when a response is generated.

            1. 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:

              • Inbound links (when those are included)
              • Updates to children (when those are included)
              • Direct/Indirect container updates (for when those are omitted) 

               

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

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