Deep change detection for containers

Clients need a reliable and efficient way to determine whether any resource within a container hierarchy has changed and when, and ideally what may have changed, without having to traverse the entire tree on every sync.

(Aside: this may also need or want to incorporate if and what auxiliary resources of resources within a container hierarchy changed.)

As it stands, while the Solid Protocol expects servers to include the Last-Modified header in the response, update of that value is left to the discretion of the server, and there is no requirement that the container's Last-Modified also reflects a change that may have happened somewhere within a given container hierarchy ( https://solidproject.org/TR/2024/protocol-20240512#container-last-modified-comparison ). So, this issue is to revisit this topic since it was put aside at the time.

There may be a range of solutions with varying complexity and cost, from always requiring a server to use most up to date modified value (and the distinction between the container resource itself and a resource within a container hierarchy), to client's detecting server's capabilities, to client sending a preference signal, to sync or async updates (notifications), to querying, to... whatever. So, e.g., potentially using:

• Last-Modified header
• Prefer header
• Preference-Applied header
• Depth header
• PROPFIND header
• HEAD or GET methods
• QUERY method

Re QUERY, e.g.:

QUERY /
Content-Type: application/sparql-query (or whatever)
Prefer: return=deep-last-modified (or whatever)

SELECT ?resource ?modified (or whatever)
...

Start with the Solid Protocol section on container Last-Modified comparison, then compare the listed header, method, query, and notification approaches. Done means the project has agreed on a concrete deep-change-detection direction and captured the resulting protocol requirements or specification changes.