Roles administration
Introduction
The Role Management page lists all roles defined in 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 assigned the role of "Project Manager" in a particular project, while being only a "Lexicographer" in another project.
The assignment of roles to users is not covered in this page, it is only possible from the Project-Users management panel in the Project management page.
The Roles panel
The left panel lists all the available roles. If a role is grayed out, it means that it has been defined at the factory level and is therefore not available for editing. The right panel lists the capabilities for the selected role. Roles can only be created when the user is logged in to a specific project, as newly created roles are stored locally for 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.

Below is a description of predefined roles in the system and their permissions.
- Project Managers have administrator rights local to the projects for which they have been granted this role.
- Ontology editors are allowed to perform basic editing actions and more complex ontology modeling, such as expressing logical axioms.
- Thesaurus editors are allowed to perform basic editing actions and to maintain thesauri by means of the SKOS vocabulary
- Lexicographers (and terminologists) are allowed to edit lexicalizations (for any type of lexical model: rdfs:labels, skos/skos-xl terminological labels, ontolex entries). This role can be limited to certain languages.
- Mappers are allowed to perform alignments only.
- Validators are allowed to validate the actions of other users (useful when Validation is active in the given project)
- RDF geeks are allowed to perform any operation on RDF data, edit and run Reports and Custom Services.
- Lurkers can read everything in a project, but are not allowed to edit anything.
Note that Administrator is not a role, rather a type of user, this is why it does not appear in the roles panel. The administrator has full access to the system and no restriction on any functionality, this is why it is worthless to assign any role to an administrator. Any instance of VocBench is initialized with one administrator, who can later one nominate other administrators. Another type of user is the super user. Super users have one single superpower: they can create projects and automatically be endowed with the project manager role for their created projects. Besides this, they are normal users, so they can be given roles different from project manager in other projects, or they can be even removed the role of project manager from the administrator in a project they created.
To know exactly what each role can do, the role capabilities must be examined. For example, by looking at the figure above and the information given in the following sections, you can see exactly what permissions a lexicographer has, apart from editing labels and notes.
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/activation 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:
- an Area (e.g. RDF, as of all operations on RDF data, or RBAC, as the set of management operations related to Role Based Access Control)
- a Subject (the element on which an operation is being performed, e.g. users)
- a Scope (a scoping modifier for the subject)
- the set of allowed operations on the above, expressed through the traditional CRUD pattern (Create, Read, Update, Delete), extended with a Validate operation.
The vocabulary for Subject and Scope varies depending on the chosen Area (see next section on vocabulary)
Capabilities are expressed by formulas in the following form:
capability(<area>(<subject>,<scope>),<OperationSet>)
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:
capability(<area>(<term>),<OperationSet>).
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:
capability(rdf,'CRUDV').
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.

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) Note: rdf with no brackets implies all operations on the RDF area. |
one of: resource 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
graphs (through the subject graph) are managed both as resources and as their content, in particular, for the sole rdf(graph), the crud is interpreted as follows:
|
one of:
|
|
Role Based Access Control (rbac)
|
role user |
|
role: this capability is needed for operations centered on roles, with no relations to users/capabilities |
Project Management (pm) |
project |
Any of the following scopes can be associated to the subject project
|
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
|
user: for operations centered on users (read, create etc..), with no relationship to other aspects |
Custom Forms (cform) |
|
The following scopes are available:
|
form: for operations centered on forms (read, create etc..), with no relationship to other aspects |
System (sys) |
The following subjects are available:
|
No scopes are available for the moment, all system expressions are (for now) monadic |