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.

Role Management

Below is a description of predefined roles in the system and their permissions.

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:

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.

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)

Note:

rdf

with no brackets implies all operations on the RDF area.

one of:

resource
cls
individual
property
objectProperty
datatypeProperty
annotationProperty
ontologyProperty
ontology
dataRange
datatype
concept
conceptScheme
xLabel
xLabel(<language>)
skosCollection
skosOrderedCollection
ontolexForm
ontolexLexicalEntry
limeLexicon
graph

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

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:

  • C: creates a new named graph
  • R: reads the list of available named graphs
  • U: updates a graph (any other than the working graph, which can be written by default), intended as the content (the triples in the graph); notice that this must be used in combination with another capability for the specific operation
  • D: drops a named graph
metadata about the resource identifying the graph can instead be modified according the subjects used for all the other resources (e.g. rdf(graph, values) for values of triples having the graph as subject)

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)

 

role

user

  • 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)

project

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