VocBench Logo

Home Documentation Downloads Support About us

User Management

The Administration Pages

By clicking on the top-right corner user button, it is possible to access a series of options for the user. The "Administration" option on the menu allows the administrator to create new users, new roles and assign users to projects with a given role.


User Management

The User Management page lists all the users registered on the system, allowing other users to view (and edit, if authorized) their description.

The three buttons: Active, Inactive, New on the left panel activate filters (all "true" by default) for filtering in/out users who have been activated by the administrator, who are still pending activation (new) or who are inactive due to an explicit deactivation.

The status-switch on top of the right-panel allows the administrator to activate/deactivate the selected user.

User Management

Role Management

The Role Management page lists all the roles defined on the system and allows authorized users to edit them. Roles define sets of capabilities that can be assigned to existing users, per project. The "per project" means that a given user could be given the role of "Project Manager" in a certain project, while being only a "lexicographer" in another project.

The left panel lists all the available roles. If a role is greyed, it means it has been defined at the factory-level and thus cannot be edited. The right panel lists the capabilities for the selected role. Roles can only be created when a project the user is logged to a given project, as newly created roles are stored locally to each project.

The buttons on the left panel allow respectively to: create a new role, delete a role (not possible for factory-defined roles), import a role from a saved description or export a role.

User-defined roles can be modified by defining/editing their capabilities through the right panel.

Role Management

Editing Capabilities

We have created a dedicated capability language for expressing user capabilities. The capability language is based on the Prolog logic programming language and allows for a rich set of expressions, supported by entailments (e.g. specific capabilities can be entailed by more general ones, based on a concept of "coverage" expressed in the capability).

In order for a user to perform an action, the range of capabilities owned by the user must satisfy those required by the action. The Prolog-based technology for checking capabilities is available both server and client side. The engine in the server provides the ultimate check for authorization (as requests could be performed by bypassing the client) while the client one is used to enable visualization/activatin of UI elements, depending on the logged user. This way, it is possible to have very dynamic UIs automatically modeled on users' capabilities, which are ultimately defined in the service code, with no further redundancy in the code.

As Semantic Turkey is based on Java, server-side we adopted tuProlog, a Java-based light-weight Prolog system for distributed applications and infrastructures, developed by the APICe research labs of the University of Bologna

For the client, our choice fell on jsprolog, a simple Prolog interpreter written with TypeScript. Thanks to Dmitry Soloviev for his constant help and improvements he brought to jsprolog so that we could adopt it in VocBench.

In general, a capability is expressed by:

The vocabolary for Subject and Scope varies depending on the chosen Area (see next section on vocabulary)

Capabilities are expressed by formulas in the following form:


The OperationSet is represented by any combination of the letters C,R,U,D,V, in between ' ' (e.g. 'CU', 'R', 'CRUD', 'V')

In some cases, monadic variations of the area specification are admitted, in the form:


where term can be the scope, or another special term. There is no general semantics for the monadic variations, and these are explained case by case.

Specifications of the sole area are also possible, usually implying unlimited power over that area, as in this example:


representing the capability to perform any operation on the RDF data.

The capability editor (in the following figure) offers a wizard for completing most of the capability description without writing any code.

Editing Capabilities

The grey text area at the bottom of the editor shows the composed capability expression.

Capabilities Vocabulary

The following table describes the range of possible combos of Subjects and Scopes for each Area. Monadic expressions provide short syntactic variations for various combinations of subject and scopes, or further semantics.

Area Subject Scopes Monadic Variations of the Scopes

RDF (rdf)



with no brackets implies all operations on the RDF area.

one of:



where <language> must be expressed between "" (e.g. "en"). xLabel without any language allows operations on xLabels for any language

The following entailments hold between capabilities made explicit on a subject (on the left) and other subjects covered by the expressed capability

  • resource --> any resource
  • property --> objectProperty
  • property --> datatypeProperty
  • property --> annotationProperty
  • property --> ontologyProperty
  • skosCollection --> skosOrderedCollection


one of:

  • values (applicable to all subjects)

  • alignment (applicable to all subjects)
    allows the authorized user to perform mapping operations on the specified subject

  • instances (applicable to subject: "cls" only)
    allows the authenticated user to perform operations related to the instances of the subject class

  • lexicalization (applicable to all subjects)
    allows the authorized user to perform operations on any kind of lexicalization for the given subject

  • notes (applicable to all subjects)
    allows the authorized user to perform operations on any kind of note for the given subject

  • domain (applicable to all property type of subjects)
    allows for performing operations on the domain of the subject property

  • range (applicable to all property type of subjects)
    allows for performing operations on the range of the subject property

  • schemes (applicable to concept, conceptScheme, skosCollection, skosOrderedCollection, xLabel)
    allows the authorized user to perform operations on the relationship between the subject and existing schemes

  • taxonomy (applicable to concepts, classes, properties, collections)
    covers all kind of taxonomic relationship, when applicable to the subject  (e.g. for concepts, classes, properties, collections, intended as the containment relation between collections)

  • formRepresentations (applicable to ontolexForm)

  • subterms (applicable to ontolexLexicalEntry)

  • constituents (applicable to ontolexLexicalEntry)

  • any of the available subject resources. A monadic expression containing only a resource as a subject allows to perform all
  • lexicalization: this means that the user is able to perform any operation related to lexicalizations for any resource
  • import: any operation related to data import
  • sparql: any operation via SPARQL. Concerning the CRUD, only R is required for queries and U for updates.
  • skos: any operation specific to the skos model
  • ontolex: any operation specific to the ontolex model


Role Based Access Control (rbac)




  • capability: appliable to role only, allows the authenticated user to perform operations related to capabilities for the subject role
  • role: appliable to user only, allows the authenticated user to perform operations related to roles for the subject user
role: this capability is needed for operations centered on roles, with no relations to users/capabilities
Project Management (pm)


Any of the following scopes can be associated to the subject project

  • baseuri
  • defnamespace
  • prefixMapping
  • group
  • collaboration
project: for operations centered on a project (read, create etc..), with no relationship to other aspects
User Management (um) user

Any of the following scopes can be associated to the subject user

  • activation: allows the authorized user to activate the subject user
  • project: allows the authorized user to associate the subject user to a given project
user: for operations centered on users (read, create etc..), with no relationship to other aspects
Custom Forms (cform)
  • form:
  • formCollection: a collection of forms

The following scopes are available:

  • mapping: associable to the form subject, it allows the authorized user to perform operations related to form mapping
  • form: associable to the formCollection subject, it allows the authorized user to perform operations related to the association between forms and formCollections
form: for operations centered on forms (read, create etc..), with no relationship to other aspects
System (sys)

The following subjects are available:

  • metadataRegistry
  • ontologyMirror
  • plugins
No scopes are available for the moment, all system expressions are (for now) monadic  

Group Management

The Group Management page lists all the groups defined on the system and allows authorized users to create them, delete and edit their information. Groups define an aggregation of users and give the possibility to constrain or limit the management of SKOS thesauri to their members. The left panel lists all the available groups and the right panel shows the information about the selected group. The buttons on the left panel heading allow respectively to: create, delete and edit a group.

Groups Management

Groups are defined system-wide, but their properties, namely the users who belong to them and the limitation they introduce, are local to each project. This means that a user may belong to a group in a Project A but not in a Project B, or that a group may have limitations in Project A but not in Project B.
That said, in order to manage the above properties is necessary to switch to the Projects panel from the top-left selector.

Group membership

The group membership of a user can be defined in the Project-Users management panel. Once a projec-user pair is selected, on the left panel their settings are shown.
A user can be assigned to a single group per project. The checkbox on the top-right corner of the Assigned Group panel, if checked, tells to the system that the group limitations for the given project must be applied. This means that a group membership doesn't necessarily imply that its limitation (if any) are applied to all the users.

Groups user assignment

Group limitations

As stated before, a group can be used in order to constrain or limitate the opreation that its users can perform on a SKOS thesaurus. In particular it is possible to configure the following:

Groups limitations

About the ConceptScheme authorizations, any changes on a unauthorized scheme or any of its concepts (according to this configuration) will be denied. For instance, considering the configuration show in the previous figure, a user that belongs to the ART group in the Eurovoc project, cannot add a concept to a scheme different from EuroVoc (en).

Denied operation on scheme