Validating RDF data

Chapter 6  Applications

In this chapter we describe several applications of RDF validation. We start with the WebIndex, a medium-size linked data portal that was one of the earliest applications of ShEx. We describe it using ShEx and SHACL so the reader can see how both formalisms can be applied to describe RDF data.

In Section 6.2, we present the use of ShEx in HL7 FHIR, which was one of the main motivations for the development of ShEx.

Section 6.3 describes Springer Nature SciGraph, a real-world application of SHACL. Section 6.4 talks about validation use cases that have emerged in the DBpedia project.

We end the chapter with two exercises: the validation of ShEx files, encoded as RDF using ShEx itself (Section 6.5), and the validation of SHACL shapes graphs in RDF using SHACL (Section 6.6). These exercises help us understand the expressiveness of both formalisms.

6.1  Describing a Linked Data Portal

Linked data portals have emerged as a way to publish data on the Web in accordance with principles that improve data reuse and integration. As discussed in Section 1.1, linked data uses RDF to make statements that establish relationships between arbitrary things. In this section, we consider one of the earliest practical applications of ShEx, the description of a real linked data portal, the WebIndex, and its data model. Some contents of this section have been taken from this paper [58] where we also compare the performance of two early implementations of ShEx and SHACL.

The WebIndex is a multi-dimensional measure of the World Wide Web’s contribution to development and human rights globally. In its latest edition (from 2014), it covers 81 countries and incorporates indicators that assess several areas such as universal access; freedom and openness; relevant content; and empowerment. Its first version provided a data portal where the data was obtained by transforming raw observations and precomputed values from Excel sheets into RDF. The second version added an approach to validation and computation that resulted in a verifiable version of the index data.

The WebIndex data model is based on the RDF Data Cube vocabulary [24] and reuses several vocabularies such as Organization ontology [83] and Dublin Core [10].

Figure 6.1 shows the main concepts of the data model. The boxes represent the different shapes of nodes that are published in the data portal.

---

Figure 6.1: Simplified WebIndex data model.

---

The main concept is an observation of type wf:Observation which has a float value cex:value for a given indicator, as well as the country, year, and dataset. Observations can be raw observations, which are obtained from an external source, or computed observations, which are obtained from other observations by computational processes.

A dataset contains a number of slices, each of which also contains a number of observations. Indicators are provided by an organization of type org:Organization, which is based on the Organization ontology.

Datasets are also published by organizations.

A sample from the DITU dataset provided by ITU (International Telecommunication Union) states that, in 2011, Spain had a value of 23.78 for the TU-B (Broadband subscribers per 100 population) indicator. This information is represented in Turtle as:

Data following the WebIndex data model is richly interrelated. Observations are linked to indicators and to datasets. Datasets contain links to slices. Slices have links both to indicators and back to observations. Both datasets and indicators are linked to the organizations by which they are published or made available. Such links are illustrated in the following example:

For verification, the WebIndex data model includes a representation of computations that declare how each observation has been obtained, either from a raw dataset or computed from the observations of other datasets. The structure of computation descriptions, presented in [56], is omitted here for simplicity.

In the next section we formally define the structure of this simplified WebIndex data model using ShEx and review the main differences with the original.

6.1.1  WebIndex in ShEx

The following declaration indicates that a valid :Country shape must have exactly one rdfs:label and exactly one wf:iso2 both of which must be literals of type xsd:string. In the case of wf:iso2 it must also have length 2.

In this example, we deliberately omitted the requirement for a rdf:type declaration. This means that, in order to satisfy the :Country shape, a node need only have the properties that have been specified and may or may not include rdf:type declarations.

By default, shape definitions are open meaning that additional triples with different predicates may be present, so nodes of shape :Country could have other properties beyond those prescribed by the shape.

The shape of datasets is described as follows:

This says that nodes conforming to :DataSet shape must have rdf:type with value qb:DataSet, a qb:structure of wf:DSD, an optional rdfs:label of type xsd:string, one or more qb:slice predicates whose object is the subject of a set of triples matching the :Slice shape definition and exactly one dct:publisher, whose object is the subject of a set of triples matching the :Organization shape.

The :Slice shape is defined in a similar fashion:

The :Observation shape in the WebIndex data model has two rdf:type declarations, which indicate that they must be instances of both the RDF Data Cube class of Observation ( qb:Observation) and the wf:Observation class from the Web Foundation ontology. The property dct:publisher is optional, but if it appears, it must have value wf:WebFoundation.

Values conforming to :Observation shape can either have a wf:source property of type IRI (which, in this context, is used to indicate that it is a raw observation that has been taken from the source represented by the IRI), or a cex:computation property whose value conforms to the :Computation shape.

It should be noted that shapes do not define the semantics of an RDF graph. While the designers of the WebIndex dataset model have determined that a raw observation would be indicated using the wf:source predicate and with the object IRI referencing the original source, ShEx simply states that, in order for a subject to satisfy the :Observation, it must include either a wf:source or a cex:computation predicate, period. Meaning must be found elsewhere.

A computation is represented as a node with type cex:Computation.

The type of indicators must be either wf:PrimaryIndicator or wf:SecondaryIndicator. They must also contain the property wf:provider with a value conforming to shape :Organization.

In the case of organizations, we declare these as closed shapes using the CLOSED modifier and only allow the properties rdfs:label, foaf:homepage and rdf:type, which must have the value org:Organization. The EXTRA modifier is used to declare that we allow other values for the rdf:type property (using the Turtle keyword a).

Shape Expressions offer an intuitive way to describe the contents of linked data portals. They have been used to document both the WebIndex¹ and another data portal with a similar model, the Landbook² data portal. Their documentation defines templates for the different shapes of resources and for the triples that can be retrieved when dereferencing those resources. These templates define the dataset structure in a declarative way and can serve as a contract between developers of the data portal contents and designers of the data model. Having a good data model with a corresponding Shape Expressions specification facilitated the communication between the various stakeholders involved.

The data model described in this chapter differs from the original one for readability and didactic proposes in the following ways:

• We omitted the representation of computations, which are represented as single nodes with type cex:Computation. A more detailed description of computations was described at [56]. We have also simplified the representation of the webindex structure, which was composed of sub-indexes, components and other properties such as labels and provenance information.
• We defined the shapes of countries to include just two simple properties. We deliberately omit the mandatory use of rdf:type declaration to show that it is possible to have nodes without that declaration. In the original WebIndex data model all countries had a mandatory rdf:type arc but there were several generated nodes which did not have rdf:type declarations. As we omitted the representation of computations we decided to offer that possibility for countries as an example.

Appendix A includes the full version of the WebIndex ShEx description used in this book.

6.1.2  WebIndex in SHACL

Although the original data portal was modeled in ShEx, we undertook the exercise of defining a SHACL description for the same contents so that we could compare the expressiveness of ShEx and SHACL. In this section we present a possible encoding in SHACL.

An equivalent description in SHACL of the :Country shape defined on page ?? would be:

As can be seen, the :Country shape is defined by two constraints which specify that the datatype of rdfs:label and wf:iso2 properties must be xsd:string and that wf:iso2 has length 2.

The default SHACL cardinality constraint is [0..*] meaning that cardinality constraints that are omitted in ShEx grammar must be explicitly stated in SHACL as:

Optionality ( ? or * in ShEx) can be represented either by omitting sh:minCount or by sh:minCount=0. An unbounded maximum cardinality ( * or + in ShEx) must be represented in SHACL by omitting sh:maxCount. As an example, the definition of the :DataSet shape declares that rdfs:label is optional (by omitting the sh:minCount property) and declares that there must be one or more qb:slice predicates conforming to the qb:slice definition (by omitting the value of sh:maxCount).

The predicate sh:node is used to indicate that the value of a property must have a given shape. In this way, a shape can refer to another shape. Note that the WebIndex data model contains cycles—shapes refer to other shapes and those shapes can refer back to the first ones—which can generate recursive shapes. Nevertheless, the handling of recursion in SHACL is implementation-dependent so it is necessary to circumvent this feature following some of the techniques shown in section 5.12.1).

The definition of :Slice is similar to :DataSet, so we can omit it for clarity. The full version of the SHACL shapes that we used in this section is shown in appendix B.

There are three items that need more explanation in the SHACL definition of the :Observation shape. The first of these is the repeated appearance of the rdf:type property with two values. Although we initially represented it using qualified value shapes, we noticed that it could also be represented as:

The definition of observations also contains an optional property with a fixed value. This was defined in ShEx as:

which means that observations can either have a property dct:publisher with the fixed value wf:WebFoundation or they can not have that property.

A possible representation in SHACL is to use an sh:or of two shapes: one in which there is no dct:publisher ( sh:maxCount=0) and one with exactly one value for dct:published.

The last item requiring additional explanation is the disjunction definition which says that observations must have either the property cex:computation with a value of shape :Computation or the property wf:source with an IRI value, but not both. In ShEx, it was defined as:

In SHACL, this declaration can be defined using the sh:xone (exactly one) property constraint:

In the case of indicators we can see again the separation between the :Indicator shape and the wf:PrimaryIndicator and wf:SecondaryIndicator classes.

We defined organizations as closed shapes with the possibility that the rdf:type property has some extra values apart from the org:Organization. This constraint can be expressed in SHACL as:

An important aspect that deserves some explanation is the use of recursion to represent cyclic data models. While ShEx can define cyclic data models in a natural way, the lack of recursion in SHACL needs to be circumvented.

One possibility is to add a discriminating rdf:type arc to every node so that its shape can be associated to its class. We opted to add a sh:targetClass declaration to some shapes, such as :Observation, conflating that shape with the class qb:Observation. Any node that contains a rdf:type arc pointing to qb:Observation must conform to the :Observation shape declared by the WebIndex.

While this approach may be reasonable in closed contexts, it can cause problems in the open semantic web if one combines data from other datasets. For example, we defined another data model based on RDF data cube for the LandPortal project³ which also contained values of type qb:Observation but with different structures. We consider that forcing every node of type qb:Observation to have the same structure is not a good practice and that it may be better to separate the target declarations from the shapes definitions.

6.2  Describing Clinical Records—FHIR

Fast Healthcase Interoperability Resources (FHIR)⁴ is a framework created by HL7, a clinical standards organization, to define data formats and APIs for exchanging electronic health records. FHIR Release 3.0 was published in March 2017 and adds support for RDF.

FHIR has a resource-oriented architecture that describes the different entities involved in a clinical record. In a typical example, a patient ( Patient resource) visits a clinician ( Practitioner resource), who records some observations ( Observation resource), reviews some lab results ( Diagnostic results probably referencing other observations) and diagnoses a clinical issue ( Condition resource). These resources can be expressed interchangeably in multiple formats: JSON, XML, and RDF.

FHIR resources are described by structure definitions in a FHIR-specific schema language. This machine-readable language is translated into format-specific schema languages such as XML Schema plus Schematron, JSON Schema, and ShEx.

The structure of FHIR resources is documented as machine-generated HTML tables. Figure 6.2 shows part of the FHIR Observation resource⁵.

FHIR structure definitions have two forms of limited disjunction. The first, choices of the types of referenced resources, can be seen in subject and performer in Figure 6.2. The second is a choice between a set of datatypes where the name of the datatype is appended to the property name, indicated by the [x] notation (see effective[x] and value[x] in Figure 6.2). These are captured in ShEx using the shape expression ShapeOr (’ OR’) and the triple expression OneOf (’ |’) respectively:

---

Figure 6.2: Part of Observation resource in FHIR.

---

6.2.1  FHIR as Linked Data

The definition of the RDF representation of FHIR was greatly simplified because FHIR was designed to be resource-oriented. While clinical records are not expected to end up on the web, the REST architecture was an easy way to implement addressability and separation of concerns.

This means that FHIR resources are interlinked in a fashion that is already familiar to users of Linked Data. For example, the Observation excerpt includes references for the subject and performer. The subject may be a resource of type Patient, Group, Device or Location, and the performer may be a Practitioner, Organization, Patient, or a RelatedPerson (see Figure 6.2). While Linked Data is most commonly associated with RDF, these constraints apply equally to the XML and JSON representations of FHIR. However, of the four schema languages used to validate FHIR, only ShEx validation spans resources.

There are several reasons why one might want to limit validation to a single document: other resources might not be available or relevant and it may be impractical either computationally or procedurally to test conformance of many resources at once. However, a common use case for Linked Data is that all related data is addressable and available. Extending our schema to include verification of external referents allows us to ensure that a resource is coherent not only on its own but also when used in the context of the resources to which it is linked.

6.2.2  Consistency constraints

The FHIR-specific schemas are expressed as combinations of structure definitions describing types and containership, and constraints. Most constraints are co-existence constraints, e.g., if there is a duration there must be a durationUnits. For XML, structure definitions are expressed as XML Schema, and co-existence constraints are expressed, where possible, in Schematron. For RDF, structure definitions and coexistence constraints are both expressed in ShEx.

An example with co-existence constraints is the representation of the Timing datatype, which represents an event that may occur multiple times. A Timing schedule can be a list of events and/or criteria for when the event happens, which can be expressed in a structured form and/or as a code. Figure 6.2.2 shows the HTML representation of Timing.

---

Figure 6.3: Complete Timing datatype in FHIR.

---

While these human-friendly HTML representations are generated from the FHIR schema, they could easily be generated from representations in other schema languages such as XML Schema, ShEx or SHACL. Schemas using more expressivity may be difficult to convey graphically to users. For instance, these property trees do not have a way to assert co-existence constraints, e.g. that certain properties are mutually exclusive. In a UML stack, these sorts of constraints would be expressed using OCL (see section 3.1.1).

The value set idiom of specifying a value type and a value set (e.g., <code> and fhirvs:units-of-time) allows one to specify the structure and also to specify values within that structure.

6.2.3  FHIR/RDF Development

The FHIR/RDF group, a joint undertaking of W3C and HL7, used ShEx not only to define the final product but also to describe intermediate ideas and test them against example data. To this end, members of the group learned ShEx to streamline the process with concrete, testable proposals. During the development and deployment of version 3 of FHIR, Harold Solbrig (Mayo Clinic) implemented a pipeline to test shapes against FHIR example data, catching errors in both the examples and the ShEx schema.

Because the agile FHIR standardization process is centered around the maintenance of FHIR resource structure definitions, the ShEx for FHIR is generated from these definitions. The easy way to do this is to generate ShExJ (the JSON representation) but because the FHIR group wanted these to be appealing to readers, they were transformed into ShExC, making specific white space decisions in the process. These ShExC representations could then be parsed to the abstract syntax to be tested against the reference ShExJ schemas. The latter transformation was simpler and less error prone as it is involved only with the direct semantics.

6.2.4  Generic Properties

Because electronic medical records use a consistent template to represent most clinical data, they rely heavily on generic properties. These properties may be used multiple times with different constraints. A simple example of this is a blood pressure, which actually consists of two measurements: systolic (pressure during heart beat) and diastolic (pressure between heart beats). Both of these measurements are connected to the blood pressure measurement by a fhir:Observation.component property.

This example is long, but it is taken directly from a use case. In fact, its length encourages us to do a bit of factoring. While we want to keep constraints on the codes for systolic and diastolic, we can create a separate <valueObs> shape to capture the quantity measurement.

This schema has two repeated properties: fhir:Observation.component with different constraints (one for systolic and the other for diastolic). It takes advantage of ShEx’s intuitive additive semantics where requirements for repeated properties are simply expressed as additional triple patterns (see section 4.6.7).

6.3  Springer Nature SciGraph

Springer Nature SciGraph⁸ is a new Linked Open Data platform aggregating data sources from Springer Nature and key partners from the scholarly domain. The platform currently collates information from across the research landscape, such as funders, research projects, conferences, affiliations, and publications (books and journals). This high-quality data from trusted and reliable sources provides a rich semantic description of how information is related, as well as enabling innovative visualizations of the scholarly domain.

Data quality is a key component in SciGraph. In earlier work, SPIN was used in various validation scenarios. However, SPIN was hard to maintain and to read by non-experts and SHACL was chosen instead. SHACL is now used to validate data before the data enters the main triplestore. SHACL is also used to specify which classes and properties can be published from the triplestore.

All of the SHACL shapes used in building public datasets of Springer Nature SciGraph are published in a Github repository.⁹ There are shapes that define the RDF structure of all SciGraph entity types such as articles, grants, and journals.

The following snippet of the Article shape says that all SHACL instances of sg:Article must have exactly one sg:scigraphId that is a string, at most one value for sg:doi, a string following a specific pattern and at most one value for sg:role that can be one of:author, editor or principal investigator.

6.4  DBpedia Validation Use Cases

DBpedia¹⁰ ([60]) is a crowdsourced community effort to extract structured information from Wikipedia and make this information available on the Web. DBpedia data is available as RDF dumps, through a linked data interface and a SPARQL endpoint. The current DBpedia release (version 2016-04¹¹) provides circa 9.5 billion RDF triples.

Validating such large amounts of RDF data is a challenging task, and various methods have been applied. At the time of writing, the core validation of DBpedia is performed with neither ShEx nor SHACL. However, it is worth mentioning some approaches that work on large and noisy datasets.

6.4.1  Ontology-based Validation

One of the core sources of validation for DBpedia is the DBpedia ontology. The DBpedia ontology is crowdsourced and maintained by the community on the http://mappings.dbpedia.org wiki. At the time of writing, the ontology consists of circa 750 classes, organized in a hierarchy, and 2,600 properties. The community can define class disjoint statements and for properties, axioms such as domain, range, literal datatypes, and functional properties. The DBpedia ontology both drives the correct extraction of RDF triples from Wikipedia pages and is used in post-processing steps to remove data violations.

The DBpedia extraction framework has many extractors that parse different parts of a Wikipedia page and generate RDF triples. The Mapping-based extractor is a special extractor that focuses on high-quality extraction from Wikipedia infoboxes. To achieve this it uses the DBpedia ontology and the community-maintained infobox-to-ontology mappings. Each infobox mapping maps a Wikipedia infobox template to a DBpedia class and each infobox template parameter to a property mapping (see [60, sec. 2.4]) . At extraction time, each property mapping is associated with a different parser, according to the rdfs:range of the DBpedia property of each property mapping. For example, if the range of a property is defined as an xsd:date (e.g. dbo:birthDate), property mappings with this property generate a value only if the value can be parsed as a date.

As a post-processing step, the RDFS and OWL axioms defined in the DBpedia ontology are used to further clean up the extracted data. A common approach is to run RDFUnit on the data and get back detailed violation reports. These reports are used to identify common sources of error that can be planned for fixing. Another approach is a set of scripts that parse facts and, depending on the conformance of a fact to a set of axioms (e.g., rdfs:domain, rdfs:range, owl:disjointWith, etc) dispatches the facts to different dataset buckets before publishing.

6.4.2  RDF Mappings Validation

A very common way to generate RDF data is through a mapping document. In a general case, a mapping document contains rules that can be used to transform input data to RDF. The mapping rules can be encoded in a script (e.g., using XSLT), in code, or formulated in mapping languages such as R2RML [28] and RML [30].

A single error in the mapping document can, in many cases, be propagated to many errors on the generated instance data, and the number of errors is usually proportional to the input size. Consider for example a mapping document that generates person data and represents the age of a person with the property foaf:age and the value as xsd:double instead of xsd:integer. Every person instance in the generated RDF will have a violation for the datatype of foaf:age. Fixing such errors in the mapping document is an easy task, but once the data is generated the task becomes harder, especially on big datasets.

Dimou et al. [31] propose a workflow for including quality assessment of the mappings in the general dataset quality assessment workflow. The authors use the dataset schema information (i.e., ontologies) to identify schema errors of the dataset directly from an RML mapping document. The results illustrate that violations such as domain and range, mistyped datatypes, class and property disjointness, and the like can be identified directly from the mapping document. Evaluation of this work indicates that fixing errors directly in the mapping document is more efficient. For example, in the case of DBpedia, an automatic quality assessment of the mappings took less than a minute while the complete dataset validation took more than 16 hours.

However, the mapping quality assessment of the mappings cannot identify all possible schema errors in the target dataset. Some constraints, such as cardinality, can only be identified on the target dataset.

Even though this approach currently works with OWL and RDFS, it would be an easy exercise to extend it to SHACL or ShEx. Given a set of mappings and a set of Shapes, one could identify incompatibilities directly from the mapping document.

6.4.3  Validating Link Contributions with SHACL

DBpedia promotes Github for accepting link contributions from the DBpedia community¹² and, recently, there has been an effort to automate the link verification process (see [32, Section 3.3]). This has put into place a set of quality checks that validate various aspects of the link submission and is integrated with common continuous integration services, such as Travis CI.

This approach enables instant checks on pull requests and reports problems to the submitter. In addition to scripts that check for instance valid RDF files, there is a script that checks if the link manifest file conforms to the following SHACL schema.¹³

The defined quality checks cannot capture all possible errors in a link submission process. However, they can (a) provide a very useful feedback to the link submitter, and (b) enable DBpedia to automatically pre-process some steps in the link generation pipeline.

6.4.4  Ontology Validation with SHACL

The DBpedia ontology has been maintained by the DBpedia community in a crowdsourced manner at the http://mappings.dbpedia.org wiki. There is an ongoing effort to move ontology development onto Github for easier collaboration and for the sake of more control over the ontology structure. ¹⁴ At the time of writing, the following constraints are defined to ensure that each DBpedia class and each DBpedia property conform to DBpedia community requirements:

• Each DBpedia class and property must have at least one rdfs:label and at least one rdfs:comment that are of rdf:langString datatype with unique language.
• Each DBpedia class can have at most one direct super class.
• Each DBpedia property can have at most one direct super property.
• Each DBpedia property can have at most one rdfs:domain.
• Each DBpedia property can have at most one rdfs:range.
• The domain and range of each property must be defined as an owl:Class.
• Top-level DBpedia classes must be discussed before defined.

These constraints are implemented with the following SHACL definitions. RDFUnit is used to perform the validation as well as integrate with Travis CI and automate the checks on each commit and pull request.

An interesting part of this use case is the use of SHACL-SPARQL to define the complex constraint Top-level DBpedia classes must be discussed before defined. Here, only nine specific classes are allowed as top-level classes (i.e. classes with no superclass except owl:Thing) and are hard-coded in the SPARQL query. Even though this creates a tight coupling of the shape to the data, top-level DBpedia classes are not changing frequently and adjusting the constraint can indeed stimulate discussion.

6.5  ShEx for ShEx

Given that one serialization format for ShEx is RDF, it is possible to use ShEx to validate itself, i.e., to validate RDF graphs representing ShEx schemas. The RDF serialization representation of ShEx is called ShExR.

The following example contains a simple ShEx schema using ShExR in Turtle:

In the following, we will describe the ShEx schemas that can validate RDF files in ShExR (as above). The full code is included in the annex C and has been adapted from Appendix C (ShEx shape) of the ShEx specification.¹⁵

ShExR graphs contain an RDF node with rdf:type sx:Schema, an optional list of starting semantic actions, a start declaration and zero or more sx:shapes declarations whose values must be shape expressions <ShapeExpr>.

Most of the shapes in this schema are defined as CLOSED to limit the appearance of unexpected triples.

As discussed in Section 4.4.3, there are six possibilities for defining shape expressions. Which can be enumerated as:

<ShapeOr> and <ShapeAnd> have a similar representation which contains a list of at least two shape expressions represented by the <shapeExprList2Plus> shape, which will be described later.

<ShapeNot> contains a shape expression:

The following code represents lists of shape expressions. <shapeExprList2Plus is a list of at least two shape expressions, and <shapeExprList1Plus> is a list of at least one.

Node constraints are formed by one or more declarations of node kind, datatype, string facet, numeric facet, or a list of possible values.

A shape can contain the Boolean directives sx:closed and sx:extra as well as a sx:tripleExpression and an optional list of semantic actions.