Within Fedora 4, snapshots of the current state of an object may be saved into the version history. The properties or content of a node saved in these versions may be accessed later to serve as a historical record of the object. Future feature development may allow for easy export of the entire history or other useful actions.
Enabling Versioning
By default, nodes do not have the mix:versionable mixin, which means that they do not have any versioning triples, or versions listed. When you make a request to create a version, the mix:versionable mixin is added to that node automatically.
This mixin can also be added manually using SPARQL Update:
When you wish to save a snapshot of the current version of a node to the version history you can use the REST API. When saving these versions you must provide a label that both serves to easily differentiate a version from another and allows easy retrieval of that version.
For previous versions for which explicit names were not provided, you may use the UUID property which you can find by parsing the response from the listing of available versions.
Response:
Status: 204 No Content
Status:
204 No Content: if the version is reverted successfully
404 Not Found: if the version does not exist
Response: The requested resource is not available.
Trying to delete the current version of a resource will result in an error. To revert to an old version of a resource, first revert to the old version using the PATCH method, and then delete the newer version.
Status:
204 No Content: if the version is reverted successfully
400 Bad Request: if trying to delete the most recent version
Response: Cannot remove current version
404 Not Found: if the version does not exist
Response: The requested resource is not available.
Duplicate Version Labels
If a second version is created with the same label as a previous version, that label is quietly reassigned to the most recent version tagged with that label.
Version creation is a relatively costly operation. With the ability to create versions whenever you wish, you can develop workflows that maximize the utility of the version history.
Possible strategies include:
For batch operations, only create version checkpoints once nodes have been ingested, verified and tested.
For high value but small data such as descriptive metadata entered by subject experts, set a versioning policy to store every modification to capture the entirety of the curatorial endeavor.
Create snapshot versions that correspond to released versions of content (ie, version X of a shared dataset, controlled vocabulary or collection)
Viewing old Versions
From the HTML view (or by issuing HTTP GET methods in an HTTP client program) you can get the version history of a node by appending "/fcr:versions" to it's base URL. Each version will be listed, either using the version label as the title, or for versions without labels, the modification date will be used instead.
Previewing historic properties
By clicking on the box for a version you can expand and collapse a view of the version properties.
Navigating to the full view of an historic version
By clicking on the label of a version in the version listing you will be taken to the stored version of that resource. Because it's part of the historic record, you cannot edit it and certain properties have been stored in different property names (mixin types, uuid) but you can export that snapshot or view any content.
Reverting to a previous version
If you wish to restore an object to a previous version you may do so using the REST API, or even the HTML view. In the HTML view of a historic version, a button exists on the right hand side saying "Revert to this Version" that when clicked restores the object (and possibly the subgraph) to the version viewed.
When restoring an old version, two operations occur:
Immediately before restoring the old version, a version snapshot is made to reflect the current state of the object. This version will not have a version label.
The current state of the resource will be updated to match the old version – but a new version will not be created. You can create a new version explicitly if you want to create a new version that records the revert.