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.
Validation
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 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 represented in the various views (e.g. the values represented in the resource-view and the various resource trees on the left) available in VocBench according to the following conventions:
- in green, italic: added triples (e.g. relationships shown in the resource view)
- backgrounded in green: added resources as wholes (i.e. as RDF as no "containing frame" for resources and their description is sparse across the various triples mentioning them, the existence of a resource is identified as the presence of one or more type declarations, thus introduced with the predicate rdf:type)
- in red, stroke-through: removed triples (e.g. relationships shown in the resource view)
- backgrounded in red: removed resources as wholes
It is possible for authorized users to access the list of actions 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.
Users with no validation capabilities can still access the Validation page; however the view is limited to their actions only and they can only reject them (Accept not allowed).
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:
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.
History
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
Commits Filter
The filter panel in the History and Validation pages allows users to refine their search criteria to find specific commits or staging commits within the application. The following filters are available:
- Operations: this filter allows users to narrow down their search based on the type of operation performed. These operations correspond directly to the underlying services invoked when users interact with the system.
- Performers: by selecting one or more users from the list, users can filter commits based on the individuals who executed the actions.
- Time: defines a specific range within which the operations were performed.
- Resource: by entering the IRI of a resource, users can filter commits to only display those related to the specified resource.
The Resource filter is particularly useful when tracking changes to specific entities of the dataset. Within the ResourceView, users will find links specifically tailored to redirect to the History and Validation pages. These links are designed to automatically pre-fill the Resource filter with the IRI of the resource currently being viewed.
Blacklisting
If blacklisting is enabled, some operations that involve 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.
