Publishing on the web made easy

The DotWebStack framework makes publishing data on the web easy. In five minutes you can:

Quick links:

Creating webapplications made easy

The DotWebStack framework is an extendible java framework that is available as maven dependencies and distributed via maven as java jar libraries. You can easily extend the framework by creating your own libraries or by incorporating the framework in your own java application.

Using webapplications made easy

If you don’t want to make your own webapplication, you can also just grab the our reference application, the DotWebStack theatre that we use to demonstrate the power of the DotWebStack framework.

You can also use the DotWebStack theatre legacy application, that is the successor of the Linked Data Theatre and contains all its user interface features.


Introduction to the DotWebStack Theatre

“DotWebStack” stands for: Data on the web Stack. It is a stack of libraries for publishing data on the web and can also be used to manage data on the web, by enabling the transaction (“write”) functionality.

The DotWebStack project includes a reference application, called the “DotWebStack Theatre” that uses the DotWebStack framework and can be used as a ready-build, instantly usable application. The DotWebStack theatre is the successor of the Linked Data Theatre and is also known als “Linked Data Theatre 2.0” or simply “LDT 2.0”.

The DotWebStack theatre can be described as a data driven web application. A user (or application) enters a URL in his browser, and the theatre will return the corresponding Linked Data for that URL. The LDT uses a configuration to know which data should be returned to the user and in which format. Using the OpenAPI specification, the data can also be returned in a JSON format that conforms to the contract as specified by the OpenAPI specification.


The configuration of the theatre is also Linked Data, conform the ELMO vocabulary.

A URL from the user could be an identification of a resource, using a 303 of # URI. It can also be the endpoint of a REST webservice, for example:

This last example shows how the theatre can be used to handle non-dereferenceable URI’s.

The theatre uses content negotiation to format the reponse to the user, for example:

Using the Theatre

An important aspect of the DotWebStack is the notion of sites and stages. A DotWebStack application typically “listens” to one or more domainnames, like This is called a “site”. At such a site at least one “stage” exists. The main stage at this site corresponds to the URL http://{domain name}. Extra stages can be created with the path after the domain name, for example:

Every stage has a backstage. The backstage can be used to configure a DotWebStack application. It contains a simple editor to write and store the configuration for the application that should be used on the stage. The use of the backstage is optional: you could place the configuration in a directory in your filesystem and refer to this location via the application.yml system configuration file:

    resourcePath: file:./config

Using the theatre-metaphor, the concepts of site, stage and backstage can easily be explained:

Site, stage and backstage

DotWebStack configuration

From the URL entered by the user, the application looks for a representation that is applicable for that particular URL. Three strategies are available:

Configuration overview

The configuration for a particular representation should contain a SPARQL query to retrieve the data from a SPARQL endpoint. The configuration also includes a declaration of the appearance that should be used for the retrieved data. An appearance might for example be a tabular appearance, or a geographical appearance, or a form-style appearance. Tweaking the appearance can be performed by adding fragment definitions to the the configuration. The end result will be presented to the user, using content negotiation.

Examples of appearances

The Linked Data Theatre is capable of showing a wide variety of appearances for a particular Linked Data set. Some appearances are restricted tot CONSTRUCT style queries, other can also be used with SELECT style queries. Below are some typical examples.

The full range of appearances is described in the appearances topic.

Content appearance

The default appearance for a CONSTRUCT query is the content appearance. The content appearance will show a two column table for every subject in the result set, a row per triple, first column containing the predicate, second column containing the object.

Content appearance

Table appearance

The default appearance for a SELECT query is the table appearance. The results of the select query are displayed in a paged table. Every variable is displayed as a column.

Table appearance

Tree appearance

A tree appearance can be used to create a tree of resources, using the link between resources (from a CONSTRUCT query), for example a taxonomy of concepts.

Tree appearance

Graph appearance

The graph appearance creates a graphical representation of the linked data, using rectangles for items and arrows for the relations between the items. Users can expand the graph by selecting an item. Depending on the SPARQL query for the representation, specific relations between resources are depicted.

Graph appearance

Geo appearance

The geo appearance shows a map of the world, including points or polygons from the query result. Currently, both OpenStreetMap and the Dutch Topographic map are supported.

Geo appearance

Image appearance

The image appearance is a specialisation of the geo appearance. Instead of a map background, you can select your own image. Polygons are plotted on this map using a simple X,Y coordinate system. These polygons can also be dragged to different locations on the image, which introduces the possibility to use the image appearance as a planboard. The new locations can also be uploaded to the triple stored. The image appearance also includes the posibility to export the map to a PDF file or PNG image.

Image appearance

Form appearance

The form appearance is used to give the user the opportunity to enter query parameters. Support is available for various data types, such as date pickers, text input, file upload and selecting a value from a list. A combination of a form appearance and some other appearance gives you the possibility to create dynamic result sets, where the user can enter there parameters. A typical use is the search form.

Form appearance

Text appearance

To display “regular” text documents, you can use the text appearance.

Text appearance

A navbar appearance creates a navigation bar with drop down menus.

Navbar appearance

You can also include a search form in the navbar. The search query can be specified, as well as a specific search form for more advanced search queries.

Search appearance