Resource Versioning

[csarven]

Solid Protocol should support resource versioning.

See also:

• Mutable and immutable resources #279
• Creation of Memento resources #61
• Fedora API Specification 1.0 - Resource Versioning
• HTTP Resource Versioning
• ..

[csarven]

Do you mean under Memento? Yes, I'm aware, which is why I also mentioned the Fedora spec - in that they've invested quite a bit of thought and energy in that we can adopt/evolve/inspired..

But, I guess it is not entirely about Memento (even though that covers a lot of ground).. just that "resource versioning" is somewhat vague in context of LDP or even LD.

There are of course provenance line of work, .. so, we just have to connect the dots.

[elf-pavlik]

A while ago I looked at having something like https://github.com/substack/forkdb which has nice way to save any number of newer versions and defer any potential conflict resolution for later. With offline functionality of Progressive Web Apps I think versioning needs to have graceful way to deal with potential conflicts.

Also looking at https://www.w3.org/2011/rdf-wg/wiki/Graph_Terminology I find interesting possibility of having g-box denoted by IRI as well as each g-snap denoted by IRI, than something like HTTP303 redirect between IRI denoting g-box and current (aka HEAD) g-snap. Something like that may come as requirement in systems which require strict audit trial and for example rely on Linked Data Signatures for each RDFSource and use append only dataset. In that case querying usually would only work on sub dataset of all the current g-snaps (HEADs).

[josephguillaume]

To provide some additional examples/connections:

1. In Trellis, a resource is its own timegate and mementos can be accessed with query parameters (e.g. ?version=1508889600734) and ?ext=timemap provides a timemap in both RDF and application/link-format https://github.com/trellis-ldp/trellis/wiki/Resource-Versioning

2. On Linux, https://github.com/presslabs/gitfs can provide a simple mechanism for memento creation. It exposes directories "current" and "history". Changes to current are automatically grouped and committed after a time delay and then appear in history. I haven't yet tried to implement a timegate or link headers, but it should be possible given this already provides a memento pattern to versioning.

With this server side approach, clients do not even need to know that versioning is implemented, but are informed through link headers if they can make use of this functionality.

There is no clear way for a client to request that a particular resource or container be versioned. Trellis LDP seems to just version every resource. Gitfs requires server and filesystem access and versions a git repository and the folders and files it contains.