Validata is an online web application for validating an RDF document against a set of constraints. This is useful for data exchange applications or ensuring conformance of an RDF dataset against a community agreed standard. Constraints are expressed as a Shape Expression (ShEx) schema. Validata extends the ShEx functionality to support multiple requirement levels. Validata can be repurposed for di erent deployments by providing it with a new ShEx schema. The Validata code is available from https://github.com/HW-SWeL/Validata.
Validation { checking the conformance of a dataset against a schema { has been an integral part of XML and relational data generation, use, and exchange. It provides guarantees that the data conforms to some structure which enables tools to consume and process that data. This is essential to support data exchange. However there is no standard for expressing constraints for RDF data.
There has been a growing interest in validating RDF data beyond checking
consistency with OWL ontologies [
The contribution of this paper is to present the Validata tool: a web
application that enables users to easily check the conformance of an RDF document
against a ShEx schema description. Validata provides client-side, browser-based
validation of RDF documents, although it is also possible to use it through
an API so that it can be included as part of a data publishing pipeline. The
validation provides support for multiple RDF serialisations as well as di erent
1 http://www.w3.org/2014/data-shapes/ accessed November 2015
requirement levels, i.e. stating whether a property is required, desirable or
entirely optional. Validata was developed to check dataset descriptions (RDF
documents) against the W3C Health Care and Life Sciences Community (HCLS)
Pro le for Dataset Descriptions [
The W3C HCLS Community Pro le [
For each description type, the metadata properties that need to be supplied
are identi ed and provided with a requirement level drawn from [
The HCLS Community Pro le is not the only dataset description speci
cation that exists. Others include BioDBCore [
We aimed to develop a tool that would meet the needs for validating RDF descriptions of datasets against di erent conformance schemas. The tool should be able to accept RDF in commonly used RDF serialisations, e.g. Turtle, TriG, and N-Triples, and the descriptions may be supplied by either copying and pasting into the web tool, or via le upload. The tool should also support common features of RDF such as string literals being provided with language tags.
It should be possible to specify di erent requirement levels such as those
speci ed in [
The main motivating use case for our tool comes from the HCLS community pro le. Thus the validation tool should be deployable on the W3C HCLS pages, i.e. it can be served from a standard web server without any server side code. The tool should support recent versions of the major browsers, i.e. Chrome, Firefox, Internet Explorer, and Safari. However, as validation is an important part of publishing data, it is desirable that the tool can also be used as part of a data publishing pipeline.
A typical interaction with the tool will be to re ne a dataset description to ensure conformance with the chosen schema. To support this the tool should provide informative error and warning messages to the user. It should also be possible to edit the RDF data and easily recheck the validation. 4
The Shape Expression Language (ShEx) was chosen for specifying the schema
constraints on the RDF dataset descriptions [
Figure 2 shows an excerpt of the ShEx schema for the HCLS community pro le. The shape de nes the properties and objects for a resource to match. In this case it de nes a <SummaryLevelShape> that consists of four constraints. The shape must have a rdf:type declaration of dctypes:Dataset, and a title provided using dct:title with a language tagged string value. The shape may have an alternative title provided as a language tagged string using the dct:alternative property. The nal constraint is that the dct:created property must not be used at all { the negation is stated with the `!' and the match 1 <SummaryLevelShape> { 2 `MUST` rdf:type (dctypes:Dataset), 3 `MUST` dct:title rdf:langString, 4 `MAY` dct:alternative rdf:langString+, 5 `MUST` !dct:created .
6 } all with the `.'. Multiplicity of properties can be stated using standard regular expression syntax, e.g. '+' for one or more occurrences.
The full ShEx schema2 contains a shape declaration for each of the
description types: SummaryLevelShape, VersionLevelShape, DistributionLevelShape,
and RDFDistributionLevelShape. Two distribution level shapes are de ned
since several of the properties only make sense when describing an RDF dataset,
viz. the VoID properties [
The Validata tool is a web application that is composed of two modules { a user interface over a standalone validator. Both the user interface and the validator are written in Javascript to enable the web application to be deployed on the W3C web server, and run entirely on the client side. The code for the Validata user interface is available from https://github.com/HW-SWeL/Validata while the code for the validation backend is available from https://github.com/ HW-SWeL/ShEx-validator.
The user interface has been developed using various existing libraries. jQuery3 is used for DOM manipulation with cross-browser functionality while Twitter Bootstrap4 is used for cross-browser responsive pages. Browserify5 was used to manage dependencies, and CodeMirror6 was used to provide text editor panes which have line numbers. This enables informative error messages that reference the line in the original RDF document that was at fault.
The ShEx-Validator has been developed as a node.js module7 which provides a standalone Javascript runtime environment. The core of the validator is the ShEx Javascript library8. The ShEx-Validator separates the tasks of validation 2 https://github.com/HW-SWeL/ShEx-validator/blob/ 043b396d9652deaf178628ba6f0b648464e4a8da/samples/HCLS%20Deployment/ hcls-chembl17-example-description.ttl accessed November 2015 3 https://jquery.com accessed November 2015 4 http://getbootstrap.com/ accessed November 2015 5 http://browserify.org/ accessed November 2015 6 https://codemirror.net/ accessed November 2015 7 https://nodejs.org/ accessed November 2015 8 Developed by Eric Prud'hommeaux https://github.com/ericprud/ShExDemo/ blob/96c7fb04827254af4618bdaeed49b3032fd002d3/RDF.js accessed Nov 2015 and reporting errors; the latter being handled by the user interface. To enable support for di erent requirement levels, the ShEx language was extended to enable arbitrary tags prior to each path expression (shown in Figure 2). peg.js9 was used to parse the extended grammar to generate the ShEx schema parser. For parsing RDF documents the N3.js library10 was used which supports Turtle, TriG, N-Triples and N-Quads. Instead of using asynchronous callbacks in the code, the promises library11 was used to enable an immediate response which would resolve to its actual value at some point in the future. Support for language tags has also been added to the ShEx validator. This means that multiplicity constraints are not violated if the property is given in multiple languages. A library of unit tests have been developed for the ShEx-Validator backend. These are run using the Mocha framework12 and ensure that the new features added to the validator do not break existing features.
The separation of the UI and the ShEx-Validator means that the validator
functionality can be deployed independently of the UI. For example, it could be
incorporated into a data publishing pipeline meaning that dataset descriptions
are validated as part of the data creation process. Alternatively it could be used
as a library in other tools such as a dataset description editor tool [
A screenshot of the W3C HCLS community pro le deployment of the Validata tool is given in Figure 3. This is shown with the ChEMBL 2015 Demo deployed and the validation requirement level set to `MAY' { meaning that the user would like error reports generated for properties declared at any of the conformance levels. Essentially the toggle enables the user to select the strictness of the validator which is desirable in di erent scenarios. 6.1
The left side of the UI is used to provide summary information to the user. At
the top are the typical series of steps for using the tool, viz. (1) Select Schema, (2)
Input Data, (3) Con gure Options, and (4) Validation Results. These navigation
aids guide the user through the main panel without breaking the information
into multiple pages; thus allowing the user to scroll up and down and adjust
things as they require. Immediately below these instructions is the option to
load a precon gured demo. In this case it corresponds to the example used in
[
At the bottom of the left panel is a Status Summary box that indicates the validation progress. In this case it shows that the schema and the data are both syntactically valid but that the data does not conform to the constraints speci ed in the schema at the `MAY' level. 6.2
The main part of the UI is used for providing the RDF data to validate, and displaying the results of the validation.
Select Schema Panel. The Select Schema panel (collapsed in the screenshot) is used for selecting a ShEx schema from a drop down menu; in the HCLS deployment there is only a single schema to choose from. The ShEx speci cation of the schema can be viewed by clicking on the Show Source button (not shown in the screenshot due to the collapsed panel). The motivation for the Select Schema panel is to allow users to validate their descriptions against multiple schemes in a single tool.
Input Data Panel. RDF data can be supplied for validation in one of several serialisations, with the validator automatically detecting the syntax. The user can either drag and drop an RDF le onto the panel, select the Browse button to upload a le, or copy and paste the RDF into the editor box. The RDF is parsed as it is entered to ensure that it is syntactically valid, resulting in the data row of the Status Summary turning green.
Con gure Options Panel. The user may con gure various options that are applied during validation. Initially the ShEx-Validator attempts to automatically identify the resources in the supplied RDF, and the shape that each resource should validate against. These are shown at the top of the Con gure Options panel. These often need correcting, either resources are not identi ed or they are not being validated against the appropriate shape. The user can use the drop down menus to correct these. For example if a resource is identi ed but is being validated against the wrong shape then the correct shape can be selected. Additional resources from the supplied RDF can be added using the Add Resource button, and correspondingly removed using the Remove Resource button. The interaction between the user and the add and remove resource buttons needs additional work to improve the user experience as only the bottom resource can currently be removed. Instead the user should be able to directly select the rows that are to be removed.
The next con guration option allows the user to select whether to generate
an error if additional properties are found, i.e. a resource matches a shape but
has additional properties. Following the nomenclature of [
The nal con guration option informs the ShEx-Validator at which requirement level the validation should take place. Any properties that are de ned in the ShEx schema with the selected requirement level and missing from the resource in the RDF will be reported as errors, those with a lower requirement level will be reported as warnings. This panel is only shown for schema that have requirement levels declared. The e ect of choosing di erent requirement levels is that the UI will return validation results at the di erent levels as either errors or warnings. Users have found this desirable as a means of rst developing a minimal description by ensuring that it matches the `MUST' properties and then iteratively validating at the lower levels.
Validation Results Panel. The bottom panel of the tool provides the validation results. For each of the resources shown in the Con gure Options panel, an entry is shown in the Validation Results panel. If the resource conforms to the shape description, then it is shown under the green Matches panel. This allows the user to see which parts of the RDF document match to a ShEx constraint. Clicking on an individual match will jump the focus of the UI up to the corresponding line of the supplied RDF data. If all the properties match then the validation row of the Status Summary will turn green.
Two severity levels of reports can be generated when properties are not present: (i) errors shown with red highlighting, and (ii) warnings shown with amber highlighting. The categorisation is controlled by the chosen requirement level. This is desirable as several properties de ned at the SHOULD and MAY requirement level are seen as optional since they do not make sense for every situation. If ShEx optional properties were used, such reports would not be generated.
Additionally, error reports are generated for invalid syntax or when the incorrect object is supplied for a property, e.g. a string is provided instead of an IRI. Through the use of the codemirror library, when these errors are clicked-on the corresponding line in the RDF is highlighted in the editor pane allowing the user to correct the error. Due to the nature of parsing errors, these are not always accurate, but are generally in the correct region of the document. 6.3
Validata is a generic tool for validating RDF documents against a set of constraints captured as a ShEx schema. The tool can easily be deployed in di erent settings by editing the con guration le containing the ShEx schema. To demonstrate this exibility, we have deployed Validata at two other locations for di erent dataset description schemas.
An instance capable of validating DCAT records [
We have also deployed a version of Validata for validating dataset descriptions
against the Open PHACTS speci cation [
Various approaches for describing constraints on an RDF document have been
considered [
The Fancy ShEx Demo developed by Eric Prud'hommeaux13 is a proof of concept system to showcase the capabilities of the ShEx language. It provides a Javascript implementation for validating RDF against a ShEx schema and was chosen as the basis for our own implementation. It is limited to only accepting RDF in the turtle serialisation and does not support the use of language tags. The focus of the tool is not on the user experience when validating an RDF document. Instead the purpose of the tool is on demonstrating the capabilities of the ShEx language. Thus it has several features that are not required for the validation use case, e.g. the ability to generate SPARQL queries to perform the validation. The error messages generated are terse and require knowledge of ShEx. We have aimed to provide more user oriented error messages.
ShExScala14 developed by Jose Emilo Labra Gayo is a Scala implementation of a ShEx validator. It supports multiple RDF serialisations and can be used to validate an RDF dataset from a given URL or SPARQL endpoint. It was not possible to use our implementation as it requires a server-side deployment.
The most similar work to our own is the DCAT validator developed as part
of the Google Summer of Code 201515. This is a web application for validating
DCAT dataset descriptions [
Validata provides a recon gurable, online tool for validating RDF documents against a set of constraints de ned in a ShEx schema. Informative error and warning messages are presented to the user to enable them to re ne their RDF to conform with the schema. The validation implementation extends the standard ShEx de nition to support di erent requirement levels; with the levels being de ned in the schema de nition rather than prescribed by the ShEx language.
The tool has been deployed by the W3C HCLS Interest Group to validate dataset descriptions against their community pro le. Additional deployments have been made for the DCAT speci cation and the Open PHACTS project.
Future work on the Validata tool includes improving the user experience, e.g. allowing users to save edited RDF les and improving the selection of resources to validate. Once these changes to the UI have been made a user evaluation should be conducted.
We thank Eric Prud'hommeaux for the support and advice received throughout the development of Validata.