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.

Administration

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:

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
concept
conceptScheme
xLabel
xLabel(<language>)
skosCollection
skosOrderedCollection

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

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