This tool is aimed to support public administrations in the context of the BRegDCAT-AP v2 implementations.


The validator service is based on SHACL, a specification that provides a way to set constraints and rules (shapes) on RDF graphs. A SHACL implementation then checks the SHACL shapes on the RDF graph and produces a conformance report; such reports provide information about the number and details of the shape constraint violations.

In the case of BRegDCAT-AP v2, two SHACL files were produced during the ontology development phase. Although these rules could have been combined into one file, a decision was made to split them into two distinct files for clarity purposes:

Unlike the other tools described in this document, the Validator has not been developed from scratch, and, it is instead provided as-a-Service by the ISA² Interoperability Test Bed (ITB).


The ISA² ITB validator instance for the BRegDCAT-AP ontology is configured by exposing a configuration file in a public GitHub repository:

A Continuous Integration pipeline on the ISA² ITB detects all updates on this configuration and then redeploys the validator with the latest configuration.

The most relevant sections of the service configuration are presented in the following block:

validator.type = main

validator.typeOptions.main = latest, v2.00

validator.typeLabel.main = BRegDCAT-AP

validator.optionLabel.latest = Latest

validator.optionLabel.v2.00 = Version 2.00

validator.completeTypeOptionLabel.main.latest = Latest BRegDCAT-AP version (2.00)

validator.completeTypeOptionLabel.main.v2.00 = BRegDCAT-AP version 2.00

validator.label.optionLabel = Version

validator.shaclFile.main.latest = v2.00

Two types of validation are currently available: latest and v2.00 (both are currently the same). The latest configuration type is there for compatibility, so users and applications may safely refer to it with the knowledge that it will always point to the most recent version of the BRegDCAT-AP specification.

The following figure provides an overview of the configuration process:

Valiadtor config

Figure 1: Validator - Configuration process

Service integration and usage

There are three different interfaces to the validator service:

  • REST API: REST is an architectural approach to the design of HTTP APIs based on a semantic usage of the HTTP verbs and the representation of entities as resources uniquely identified by URLs. The REST API interface was selected for integration due to its simplicity and the fact that there is a plethora of tools and libraries to integrate HTTP APIs into the Web application development pipeline;
  • SOAP API: SOAP is a protocol for the construction of Web services based on the exchange of messages serialised in XML. This interface is presented as an alternative for the REST API option; however, it was not used for the implementation of the tools;
  • Web UI: A Web application that presents a form where users can upload their own RDF files for validation. The results of the SHACL validation process are presented in a format that is adequate for human interpretation. This could be used, for example, to validate the RDF data serialised in RDF/XML produced by the Creator tool.

Using the REST API, the types of validation that are currently available may be retrieved by sending a GET request to the info endpoint:

curl --location --request GET '' \

--header 'Accept: application/json'

On the other hand, a POST request to the validate endpoint can be used to get a SHACL validation report for a set of RDF triples. The location of the RDF source, syntax of that source (e.g. Turtle, RDF/XML), type of validation, and syntax of the result report have to be indicated in the request body:

curl --location --request POST '' \

--header 'Content-Type: application/json' \

--data-raw '{

    "contentToValidate": "…",

    "contentSyntax": "text/turtle",

    "embeddingMethod": "URL",

    "validationType": "latest",

    "reportSyntax": "application/rdf+xml"


The validator service has been integrated with the Harvester tool to ensure that all external data sources are properly validated before data is persisted in the Virtuoso triple store. The following figure provides an overview of this integration.

validator harvester integration

Figure 2: Validator – Harvester integration