solid
Mutable and immutable resources
Clarify the notion of mutable and immutable resources.
Describe the interface.
Currently covered by WAC-Allow. (Not saying it’s the best option though.)
With WAC one can set resource to read-only but at any time make it writable again, does it satisfy your immutability requirement @csarven ? I think for each requirement would be useful to have at least one use case documented to illustrate it.
I don't think WAC-Allow addresses what I had in mind about immutable resources, but correct me if I have missed.
There may exist an agent that's can't alter a resource but other agents may through alternative routes, or a server may due to any reason. There may even be bit rot.
I was loosely considering https://www.w3.org/TR/rdf11-concepts/#change-over-time in particular "Some RDF sources may, however, be immutable snapshots of another RDF source, archiving its state at some point in time" and so how to approach that.
The social and technical mechanism would need to provide some assurance/promise and verifiability that a resource's state did not mutate in contrast to mutable resources which are often how RDFSources treated.
So giving consideration to signatures, digests, fixity, Memento..
Relates to https://github.com/solid/solid-spec/issues/204 .
Copying from duplicate #459
In Solid Application Interoperability (aka SAI) we define some resources as Immutable. They are never modified and when needed are replaced with new immutable resources.
This came out of implementation experience and allows much simpler handling of various artifacts (represented by web resources) that SAI relies on. We only use it for artifacts that are specific to SAI, that is only relevant in a specific context, and clients follow their noses to them through other resources which guarantee stable URIs.
I'm going to document our experience from writing SAI spec and implementing it. If other specs can also take advantage of immutable resources, we can collaborate on a common strategy and document best practices.
