Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Prerelease f4

Overview

Excerpt
Within fedora Fedora 4, snapshots of the current state of an object a resource may be saved into the version history either through explicit user requests or during each update to that object.  The properties or content of a node saved in these version checkpoints may be accessed later to serve as a historical record of the object.  Future feature development may allow for easy reversion to prior versions, export of the entire history or other useful actions.

Creating versions

RDF for historic version shapshots may be browsed and old non-RDF content may be downloaded.  Furthermore, an object or subgraph may be reverted to the state that it existed in a historic version.

Creating versions

...

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 can optionally must provide a label that both serves to easily differentiate a version from another and allows allow easy retrieval of that version.

Expand
titleClick to expand the full REST API Documentation...

Include Page
RESTful HTTP API - Versioning
RESTful HTTP API - Versioning

Note
titleDuplicate 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 a resource has a version with a given label, you may not create another version with that label.  If you later delete a labeled version, you may then create a new version with that label.
Tip

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 historythis feature.

Possible strategies include:

  • For batch operations, only create version checkpoints once nodes have been ingested, verified and tested.
  • For high value but small small (but high-level) data such as the descriptive metadata entered created by subject experts, set a versioning policy to store every modification to capture , thereby capturing the entirety of the curatorial endeavor.
  • Create snapshot versions that correspond to released versions of content (iei.e., version X of a shared dataset, controlled vocabulary or collection)

Implicit version creation

If you wish to save a full history of a node by having versions created every time the node is updated, you can set the property "fedora:version-policy" to "auto-version".  This can be achieved using the sparql update form on the HTML view of the object or by using some other HTTP client software to invoke REST endpoints. 

Code Block
PREFIX fedora: <http://fedora.info/definitions/v4/rest-api#>
INSERT DATA { <> fedora:versioningPolicy "auto-version" }
Tip

If your needs for digital preservation are highest and you're willing to sacrifice a little bit of performance, you can set up repository-wide automatic versioning.

 

Viewing old Versions

From the HTML view (or by issuing HTTP GET methods in via an HTTP client program) you can get the version history of a node by appending "/fcr:versions" to it's base URL.  The root Each version will always be listed and represents the object at inception.  Following the root version will be any other versions created.  When labels have been specified, those labels will be displayed, otherwise the version will be identified by the modification date. , with the version label as the title.

Previewing historic properties

...

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.

Tip
titleFeature Note

Future versions of fedora will allow reversion to previous versions.

 

Turn off Node Versioning

The fedora repository can operate with unversionable nodes as well as versionable nodes.  By default, the "mix:versionable" mixin is applied to newly created fedora nodes.  This enables versioning (though does not necessarily result in the creation of versions) for that node.  Version-related operations will not work against unversionable nodes, an the presence of the "versioning-policy" will have no effect.

See how to make fedora nodes unversionable here.

 

view it, download non RDF-content or revert the resource or subraph to that version.

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 "Revert to this Version" exists, that when clicked restores the object (and possibly the sub-graph) to the version viewed.

Info

When restoring an old version, two operations occur:

  1. 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.
  2. The current state of the resource will be updated to match the version being restored – but a new version will not be created.  You can create a version explicitly if you want to create a version that records the revert.

Deleting a previous version

If you wish to remove historic version snapshots you may do so either using the REST API or the HTML view of the historic version. You may not, however, delete the most recent version snapshot