Shape Expression Examples

These initial examples include only the standard functionality of Shape Expressions. Examples of Semantic Actions are found below.

Issue Representation

This annotated example exemplifies the Shape Expression language with an example which verifies an RDF record such as you would find in an issue tracking system.

For those who like syntax highlighting, note the colorized option above Validation:. Selecting this also enables one to use the control up and down arrows to highlight the correspondences between schema, data and the solutions shown after successful validation:

<IssueShape> {                           # An <IssueShape> has:
    ex:state (ex:unassigned ex:assigned), # state which is
                                          #   unassigned or assigned.
}

<Issue1>
    ex:state        ex:unassigned ;
.

PASS {
  <http://ex.example/#state> (<http://ex.example/#unassigned> <http://ex.example/#assigned>) matched by <Issue1> <http://ex.example/#state> <http://ex.example/#unassigned>.
}

Changing focus between the schema, data and validation panes affects the order in which the rules, triples and solutions are visited by control up and down arrow.

One can either verify that a given node in the data matches the start shape in the schema or select "Find type nodes" to test all subject nodes in the graph against any of the types in the schema:

The Shape Expression schema can be expressed using a superset of Resource Shapes and implemented as a SPARQL query. Another SPARQL query finds the triples that were not touched by a particular schema. These links are in the Validation: pane and look like: SPARQL query

The <permalink> captures the current contents of the schema and data inputs in a long, long URL. Selecting add to history continuously updates the browser history with permalinks, enabling the browser's back button to act as undo. In order to prevent confused deputy attacks, the javascript semantic actions are disabled by default on any schemas loaded from the URL.

Inheritance of shape expressions produces data structures analogous to those produced by class inheritance in programming languages.

Issue with Inheritance

We extend the issue representation with (multiple) inheritance to show how ValueReferences can be satisfied by subshapes.

Semantic actions can be used to extend validation expressivity or invoke functions when the input data satisfies a particular rule in a pattern.

Date order verification

The core functionality of Shape Expressions does not include any date comparisons. This can be accomplished with semanti actions, at the cost of portability. For instance, the issue record example above can be extended with both %js{ %} and %sparql{ %} extensions to perform the necessary comparisons in those implementations, but this will not necessarily work for other implementations. In this example, we sanity-check that the ex:reproducedOn date of an issue is later than the ex:reportedOn.
%sparql{ ?s ex:reportedOn ?rpt . FILTER (?o > ?rpt) %}
The table below shows the effect of applying error checks at different granularities and passing or failing data:

The failing examples include a ex:reproducedOn "2013-01-23T10:00:00"^^xsd:dateTime which is before ex:reportedOn "2013-01-23T10:18:00"^^xsd:dateTime (and is thus logically suspect). These examples can be made to pass by e.g. editing the ex:reproducedOn to be an hour later: "2013-01-23T11:00:00"^^xsd:dateTime.

GenX/GenJ

"GenX" is an example application which uses a simple language to convert RDF data into XML. After loading the GenX Issue example or GenJ Issue example, you will see
View GenX output as popup or link.
on the right underneath Validation messages:. This will display the XML tree produced by executing the GenX semantic actions whill validating the input. Enabling the popup in another window allows one to see the generated XML change dynamically as one manipulates the data or the %GenX{ %} actions in the schema.

The same tree can be generated with %js{ %} semantic actions at the cost of readability.

RDF Collections are first/rest lists written in RDF. There are special syntaxes for them in most RDF serializations, including Turtle's (el1 el2 ...) syntax. This ShEx idiom provides a typed-collection, enforcing that each element be of a particular type, in this example, an integer:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xs: <http://www.w3.org/2001/XMLSchema#>
start=<subj>

<subj> {
  <p> @<li>
}

<li> {
  rdf:rest (rdf:nil)
  | rdf:first xs:integer,
    rdf:rest @<li>
}

<s1> <p> (1 2) .
<s2> <p> (3 4 5) .

(see live example)

The type constraint on the rdf:first xs:integer arc rule can instead reference a complex type, e.g. rdf:first @<issue>. (see live example)