Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mutable and immutable resources #279

Open
csarven opened this issue Jul 24, 2019 · 5 comments
Open

Mutable and immutable resources #279

csarven opened this issue Jul 24, 2019 · 5 comments

Comments

@csarven
Copy link
Member

csarven commented Jul 24, 2019

Clarify the notion of mutable and immutable resources.

Describe the interface.

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Jul 24, 2019 via email

@elf-pavlik
Copy link
Member

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.

@csarven
Copy link
Member Author

csarven commented Jul 24, 2019

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 .

@elf-pavlik
Copy link
Member

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.

@damooo
Copy link

damooo commented Oct 13, 2022

See Also: ocfl. ocfl, and bagit are used by GLAM people, for storing immutable, long term object archives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Specification
  
Awaiting triage
Development

No branches or pull requests

4 participants