BREG DCAT EDITOR

The BREG DCAT Editor is a web form where public administrations can create and manage descriptions of base registries in a way that is technically robust, cost-efficient and collaborative in terms of end-user benefits. The tool also allows public administrations to visualise the descriptions in a human-readable way and to export them in an interoperable, machine-readable format conformant to the BREG DCAT 2.0 specification.

USE-CASES

The tool covers the following use-cases:

ID	Use case
UC1	Create a BREG DCAT description.
UC2	Edit a BREG DCAT description.
UC3	Remove a BREG DCAT description.
UC4	Export BREG DCAT descriptions.
UC5	Search for a BREG DCAT description.
UC6	Visualise the saved descriptions.

More details on use-cases see here.

HIGH-LEVEL VIEW OF ARCHITECTURE

Figure 1: Editor - High-level architecture

TECHNOLOGIES

The tool consists of the following parts:

• Drupal 7: the content management system used to manage the creation and modification of the BREG DCAT descriptions;
• PHP: the programming language in which the tool is written. As Drupal 7 is used, the programming language used is PHP;
• MySQL database: database of the Drupal installation;
• Virtuoso triple store: the triple store where all the descriptions are stored;
• SPARQL endpoint: Endpoint to query the triple store by using the SPARQL query language.

Content management system

The content management system used for the BREG DCAT Editor 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 and JavaScript were 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 authorisation profiles. The plugins used by the Editor can be found in Annex I.

The modules are not independent systems, but are components that work together to create new functionalities. The plethora of module options and broad development community assured that the modules needed for the specific needs could be found. Furthermore, all modules are free, they incur no cost for the public administrations. Some changes were made to existing modules to customise them further to the needs covered by the scope.

More information on the modules can be found at https://www.drupal.org.

Database

The database for the BREG DCAT Editor is a Virtuoso triple store and a MySQL relational database. The triple store can be queried using the SPARQL query language via the SPARQL endpoint (created by the SPARQL Endpoint module) to extract the BREG DCAT descriptions in RDF/XML.

SELECT ?s ?o ?p WHERE { ?s ?o ?p}

Several result formats can be chosen (RDF/XML, csv, XML, etc.).

Figure 2: Editor – SPARQL-Endpoint

After the creation of the BREG DCAT descriptions by an authenticated user, they are stored in the Drupal database. Drupal stores content in ‘nodes’, i.e. an individual piece of content, stored as a specific type. BREG DCATs descriptions, for example, are stored as “BREG DCAT” nodes.

The data is pushed from the Drupal instance to the triple store when a user adds, edits or deletes a BREG DCAT description. This provides a backup for the data if something would happen with the Virtuoso database.

Figure 3: Editor - Storing descriptions

SOURCE-CODE

The source code of the tool is provisionally available on GitHub here: https://github.com/BRegDCAT-AP-Tools/breg-dcat-editor

DEPLOYMENT

To deploy the BREG DCAT Editor locally, the administration will need PHP and Drupal environments installed on their webserver. The PHP version currently used is 5.6.15, and the Drupal version is 7.42. Finally, a Virtuoso triple store is needed to store the data that is created by the users.

The easiest way to install it locally is to install XAMPP or any similar package. Afterwards, the code downloaded from GitHub has all the necessary components except the JSON-LD support package.

In addition, it is important to have installed the JSON-LD support package for the export, as it is a soft-dependency. The easiest way to install the package is using Composer. The correct composer.phar and composer.json files are already included in the GitHub project. The execution of the command below in the directory where the Drupal installation is located, will install all the needed dependencies.

$ php composer.phar install

$ php composer.phar update

The developer can download the code from GitHub to get the latest version of the BREG DCAT Editor. After the installation, several configurations will have to be made.

Configuration of the Search API

The Search API controls the RDF indexing and the indexing to the triple store. The Indexer that needs to be configured is called Virtuoso. It can be found in the administrator panel > Configuration > Search and metadata > Search API

 

Figure 4: Editor – Adapting the Search API

The Virtuoso SPARQL Endpoint URL has to point to the right URL (see Figure 13), a Graph URI has to be specified and the user with SPARQL/Update privileges has to be configured. Specifying the Graph URI and configuring the privileges should be done in the Virtuoso Conductor.

Figure 5: Editor – Configuring the Search API

Configuration of the export module

In order to configure the export module locally, a few changes need to be made in the code of the export module, to ensure that the right endpoint and graph are used. The change must be made in export.module, which can be found in DrupalInstallation/sites/all/modules/export. The changes need to be made on line 33, line 39 and optionally on line 46.

• Line 33 : Replace the content between quotes by the correct URI of the endpoint (keeping the quotes);
• Line 39: Change GRAPHURI to the chosen URI for the local graph;
• Line 46: Change the URL of the export directly (optional).

Figure 6: Editor – Point the export to the correct URIs

Applying these changes should make the integrated export of the BREG DCAT Editor work correctly.

Configuration of the XSL transformation

There is a different way of exporting the data, i.e. by querying the endpoint directly and converting the output generated by SPARQL. To this end, the XSL transformation script can be used to transform the output to BREG DCAT 2.0 RDF. It should be noted that this is only needed when querying the SPARQL endpoint, not when using the integrated export.

There is a batch file to facilitate the transformation. It calls Saxon[4] to perform the XSL transformation on the export of the BREG DCAT Editor. Therefore, Saxon must be installed for the export functionality. The version used is 9.7.

After installing Saxon, the script has to be adapted by updating (see Figure 15):

1. Location of the Saxon folder;
2. Name of the saxon.jar;
3. Location of the input file;
4. Location of the XSL-file;
5. Location of where the output should come.

Figure 7: Editor - Adapting transformation script

ADAPTABILITY

The test implementation of the BREG DCAT Editor can be easily adapted to include new functionalities or make changes to the BREG DCAT 2.0.

The Editor is designed for the BREG DCAT 2.0. It is, however, adaptable to reflect any data model. In the Editor, the administrator can freely add or remove classes and properties. RDF mappings for these classes can be assigned, and existing mappings can be changed.

Adding classes can be done by specifying new “Content types” in the Admin Panel: Structure >> Content type >> Add Content Type.

Figure 16 shows the screen that will appear. To add a new class, the administrator should follow the steps described below:

1. Choose the name of the class;
2. Specify the first property of the class. Usually, the first property is the identifier;
3. Configure the RDF mapping

Figure 8: Editor - Editor - Adding a new class

Figure 9 shows the RDF mapping interface. To map the RDF, the administrator has to insert the correct predicates in the supplied fields:

1. The class predicate;
2. The property predicate and datatype.

Figure 9: Editor - adding RDF to a new class

After the class is created, properties can be added by going to the “manage fields” screen (Structure>> Content types >> manage fields). In this menu, new fields can be added. In addition, existing fields can be chosen from the drop-down menu, to reuse fields that have already been defined (for instance, the field description can be easily reused). For the new field the input method/field type needs to be chosen (text field, select list, etc.).

Figure 10: Editor - Adding new properties

If the property indicates a relation to another class, the “Node reference” field needs to be chosen (see Figure 11).

Figure 11: Editor - Adding relations between classes

When the name and field type is chosen, a user should click “Save”. A new screen will appear where a user is asked to input all the property specific values, i.e. number of characters, options of the select list, class to which a property relates, etc. Finally, the RDF mapping of the property needs to be specified in this screen.

The built-in export functionality will reflect the changes automatically. If, however, a user needs to use the SPARQL endpoint as input for the export, the supplied XSL transformation file will need to be adapted.

When changes are made to existing classes (for instance, certain properties are added), the already saved descriptions will lack this property. However, they can be edited retrospectively to include the properties.