History and Validation

How are History and Validation Managed

VB3 implements a track-change mechanism working at triple-level. Triples removed/added by each action are reified, grouped around a common resource representing the action that produced the change and stored in a separated (but connected to the project) RDF repository (the support repository) together with the actions’ metadata about the invoked action and the context of its invocation.

The change-tracking mechanism has been implemented as a sail for the RDF4J framework (http://rdf4j.org/). The sail is embedded within the system, but can also be deployed as a pluggable component inside other sail-compliant triple stores (see the section of the system administration manual on using a Separate Triple Store).

During the project creation it is possible to enable the History, Validation and Blacklisting features. The latter can be enabled only if the Validation is enabled as well.

Create project HVB


In projects requiring validation of the performed actions, changes are not directly affecting the core data. In fact, changes are stored in the support repository (as described in the introduction, in the form of reified triples with action metadata) and, specifically for the validation, in the form of plain (non reified) triples in a dedicated graph (the staging graph) of the core repository.

The staging graph is used to allow users to be immediately notified of the changes brought to the repository, even though they have still not been confirmed. In particular, changes will be represeted in the various views (e.g. the values represented in the resource-view and the various resource trees on the left) available in VocBench:

as in figure below.

Validation View

It is possible for authorized users to access the list of actions under to be validated through the Validation View ("Validation" button from the menu in the project stripe). In the figure below, it is possible to see, for each action, the identifier of the committed transaction, the type of action (column "Action"), the list of parameters of the action, the user who performed the action and the date and time when it was performed. The combo-box at the end of the row allows the user in charge of validating the actions to accept or reject each action.

Validation View

The number of shown parameters is dynamic in the size of the window, though it is possible to inspect all of them by clicking on the [...] symbol that appears when at least one parameter has been hidden due to lack of space, as shown in the figure below:

Validation Parameters

If the metadata of the performed action is not enough to evaluate the change, by clicking on the commit identifier it is also possible to inspect the triples that have been added/removed by the change. In figure below, the four triples added by an "addAltLabel" action are being shown.

Validation Parameters


If history is enabled in the project, it is possible to access the list of performed actions through the "History" button from the menu in the project stripe. In the figure below, the History View is shown. It is identical to the Validation View, except for the absence of the "Validate" column

History View


If blacklisting is enabled, some operations that envole literal content, might be blacklisted, namely if the operation is rejected, further actions that contain the same literal, will be automatically blocked. For example, if the addition of the label "contrattisti"@en is rejected, future addition of this label to the a resource, or the creation of a new resource with this label, will be rejected. Anyway the addition could be forced.

In the validation view, for those operations allowing the blacklisting, a comment button is available and it is enabled only when the operation is rejected. Through this button is possible (optionally, but highly recommended) to provide a comment for motivating the reason of the rejection. This comment will be shown in the error message (shown in the previous image) each time the user will try to add blacklisted values.