VocBench Logo

Home Documentation Downloads Support

A comparison between VocBench 2 and VocBench 3

VocBench 3 aims at improving its previous incarnation by setting new standards for flexibility, openness and expressive power as a free and open source RDF modelling platform. Its final delivery is planned by the end of July 2017

With respect to VocBench 2, the current version of VB3 already offers a much more flexible environment, fine grained RDF editing, support for OWL and SKOS core, but it still lacks the role-based access control and the manageable publication workflow. These features will be implemented by the end of the project, when VB3 will definitively replace its predecessor.

The following table provides a simple feature comparison between VocBench 2 and VocBench 3, detailing for VB3 if the feature is already available in the version that can be currently built from the sources, or if it is in any case expected to be developed by the end of the project. The table cannot represent the many other improvements that VB3 will bring over VB2, this table is however useful in terms of a macroscopic feature comparison


TBD: to be developed


Feature VB2 VB3
SKOS Editing SKOS only possible as an export of the native SKOSXL YES
OWL Editing NO YES (to a limited extent in the first release)
Reified Notes Only Definitions YES (powered by Custom Forms)
RDF Editing Capabilities Governed by Tabs, scoped on skos:concepts and skosxl:Labels
YES, Unrestricted
SKOS Collections NO YES
Access Control and User Management YES YES
Role Based Access Control (RBAC) YES YES: a much more flexible system than in VB2, it is possible to completely customize roles and capabilities, and even create new ones very easily
History YES; stored on a separated SQL database; content limited to action metadata YES; stored as triples in a triple store; content as action metadata and actual list of changed triples
Action Validation YES (upon rejection of action A, a a counter-action to A is fired) YES: with validation enabled, all changed triples are reified and stored in a staging repository; normal triples are stored in a staging graph for temporary visualization. Upon validation, these are moved to the working graph (and in case of history, saved as reified changed triples on the history repository)
Publication Workflow YES

YES; streamlined wrt VB2, now it is interwoven with the validation mechanism. Any triples added/removed through validation are stored in a dedicated store and previewed in a dedicated graph of the main data store.

Thus, resources with their definition (triples with rdf:type) still under validation are assumed to be new resources while if their definition is being deleted (under approval of validation) these are considered to be proposed for deletion, without needing a dedicated status property for that. The only explicit status is related to deprecated resources, adopting the standard owl:deprecated property. Resources with their owl:deprecated status being uder validation are considered as proposed for deprecation.

Provenance YES (on the relational DB) YES; everything is stored in RDF, using widespred vocabularies for provenance (e.g. PROV-O)
Custom Forms NO YES: possibility to define custom forms when adding new istances of certain classes or new values of certain properties (currently available only as the latter, called custom ranges)
Integrated Constraint Validation NO YES
Alignment Support YES YES
Alignment Validation NO YES
Metadata Vocabularies NO YES: Support for VoID, LIME, DCAT, DCAT-AP, ADMS.
More can be added through a dedicated extension point.
Versioning NO

YES: users can create snapshots of a repository and tag them with a version identifier (and other metadata, such as the time of creation of the snapshot). It is possible to time-travel through different versions of the edited repository