The BREG DCAT Mapping Tool will allow public administrations to create mappings in order to harmonise different data models used for describing data in base registries, either within a country or across borders, to another data model, being the BREG DCAT 2.0 or any other data model.

The tool can also visualise the mappings, export them in a machine-readable format, and analyse the coverage between the two mapped data models. The Mapping Tool is key for the interoperable and (semi-)automatic exchange of information. Without mapping different data models, the exchange and especially the integration of data from base registries described in different sources using different data models would not be feasible.


The tool covers the following use-cases:


Use case


Add/Edit/Remove metadata manually.


Map a data model.


Visualise saved mappings.


Export mappings.


View statistics.

More details on use-cases see here.


MT architecture

Figure 1: Mapping Tool - High level architecture

  • Drupal 7, the content management system that the BREG DCAT Mapping Tool uses to create and modify the mappings;
  • PHP, the programming language in which the tool is written;
  • MySQL database, i.e. the database of the Drupal installation; and
  • Virtuoso as triple store where all the descriptions are stored.

Content management system

The content management system used for the BREG DCAT Mapping Tool is Drupal 7. Drupal 7 is written in PHP, so custom modules or adaptation of existing modules developed for the pilot use this language.

HTML was used for layout changes and small functionality additions.

Drupal 7 is chosen for its stability and scalability, the maturity of the modules and plugins for this version, and the user management system that provides us with authorisation profiles. The plugins used by the Mapping Tool are the same as the ones used by the Editor, and can be found in Annex I.


The database used for the mapping tool is a Virtuoso triple store, together with a MySQL relational database.


The source code of the tool is provisionally available on GitHub here:


This section explains how to deploy the test implementation of the BREG DCAT Mapping Tool. There are two different ways to deploy or use the BREG DCAT Mapping Tool, i.e. local deployment or direct access to the web server installation.

Local deployment

The deployment of the BREG DCAT Mapping Tool requires the installation of PHP and Drupal environments. The PHP version currently used is 5.6.15, and the Drupal version is 7.42. Furthermore, the deployment requires the installation of Virtuoso as triple store to save the data created by the users.

Additionally, the export functionality needs to have the JSON-LD support package installed. However, the code available on GitHub has all the necessary components except the JSON-LD support package. We recommend using Composer for its installation. It requires the composer.phar and composer.json files, which are included in the GitHub project. The execution of the commands below installs all the needed dependencies, executed from the Drupal installation directory.

$ php composer.phar install

$ php composer.phar update

Finally, the modules need to be configured to ensure that the data is stored correctly.

Configuration of the mapping module

The mapping module points to the SPARQL Endpoint thus it has to be set with the right address. This is done on line 631 in the mapping.module (see Figure 27). The endpoint will need the correct privileges to write to the triple store.

MT 2

Figure 2: Mapping Tool – mapping.module configuration

Configuration of the BREG DCAT 2.0 module

The BREG DCAT 2.0 module points to the SPARQL Endpoint as well. Therefore, it has to be set with the right address. This is done on line 512 in the mapping.module (see Figure 28).

MT 3

Figure 3: Mapping Tool – BREG DCAT 2.0 mapping.module configuration

Configuration of the editmapping.module

There are a few changes that need to be made in the code of the export module to ensure that the right endpoint and graph is being used. The change must be made in the “editmappings.module”, which can be found in:


The changes need to be made on line 372 and line 453 (see Figure 29 and Figure 30). In both lines the correct endpoint URI needs to be assigned to the “endpoint” variable.


Figure 4: Mapping tool – editmapping.module configuration (1/2)

MT 5

Figure 5: Mapping tool – editmapping.module configuration (2/2)

Applying these changes is a requirement to ensure the export function works correctly.


The test implementation of the mapping tool can be adapted by modifying the Drupal modules according to the new user needs.

The Mapping tool consist of 4 modules:

  • The BREG DCAT 2.0 mapping module;
  • The generic mapping module;
  • The export module;
  • The edit mapping module.

These modules are written in PHP and changes will need to be made directly in the source code.

The form to create the BREG DCAT descriptions has many different form elements like input fields, buttons and labels. The Drupal Form API is used to define these form elements[1].

A change that probably needs to happen when adapting the tool in any MS, is the translation of all the labels. The label form elements are defined in the function mapping_basic and can be changed here.

Each form element defines one input field, button, label or, layout element. An example can be found below:

  1. Form input element (select list, options are populated from the database);
  2. Layout element.

MT 6

Figure 6: Mapping Tool - Code snippet BREG DCAT 2.0 mapping tool

To change the labels of the elements, the user needs to change the “title attribute” as shown below:

MT 7

Figure 7: Mapping tool - Changing the labels of the form elements

Another possible changes to adapt the tools is to configure a source data model to easily create mappings. The test implementation of the mapping tool offers this option for mappings with the BREG DCAT 2.0. There are two facets to configuring a data model in the tool:

  • defining classes and properties;
  • defining the corresponding URIs.

The classes and properties are defined in an array. An example to define the classes is given below:

MT 8

Figure 8: Mapping tool - Adding classes to the mapping tool

The only modification needed for the predefinition of metadata from other data models, is changing the elements in the mentioned array to the classes of the new data model. Afterwards, the properties can be updated for each class as seen below.

MT 9

Figure 9: Mapping tool - Adding the correct properties

  • Change the class to the corresponding label;
  • Add the correct properties.

Defining the URIs for the saved classes and properties is done in the same module (see Figure 35):

  • $datamodellabelArray: array to add the identifying labels of the classes and properties. The identifying labels for classes are the name of the class without any whitespace, for properties the identifying labels are the name of the class + are the name of the property without any whitespace;
  • $uriArray: Add here the URIs in the same order as the added classes and properties.

MT 10

Figure 10: Mapping tool - Adding URIs to the mapping tool

[1] References for the elements and their attributes can be found here:!topics!forms_api_reference.html/7.x