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

Legend:

TBD: to be developed

 

Feature VB2 VB3
SKOS Editing SKOS only possible as an export of the native SKOSXL YES
SKOSXL Editing YES YES
OWL Editing NO YES (to a limited extent in the first release)
Reified Notes Only Definitions YES
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 TBD
Role Based Access Control (RBAC) YES TBD
History YES; stored on a separated SQL database; content limited to action metadata TBD; 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) TBD: 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 TBD
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