Roles administration

Introduction

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 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 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:

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

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)

 

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