Built-in XSLT and CSS stylesheets


XSLT is a functional, Turing-complete XML transformation language.

LinkedDataHub's XSLT 3.0 stylesheets work by transforming RDF/XML response body from the underlying HTTP API. Additional metadata from RDF vocabularies is used to improve user experience.


RDF/XML is an important RDF syntax which functions as a bridge to the XML technology stack. The stylesheets use Jena's "plain" RDF/XML output which groups statements by subject and does not nest resource descriptions. This allows for predictable XPath patterns:

  • /rdf:RDF — represents the RDF graph
  • /rdf:RDF/rdf:Description or /rdf:RDF/*[*][@rdf:about] | /rdf:RDF/*[*][@rdf:nodeID]— resource description which contains properties
  • /rdf:RDF/rdf:Description/@rdf:about — subject resource URI
  • /rdf:RDF/rdf:Description/@rdf:nodeID — subject blank node ID
  • /rdf:RDF/rdf:Description/* predicate (e.g. rdf:type) whose URI is concat(namespace-uri(), local-name())
  • /rdf:RDF/rdf:Description/*/@rdf:resource — object resource
  • /rdf:RDF/rdf:Description/*/@rdf:nodeID — object blank node ID
  • /rdf:RDF/rdf:Description/*/text() — literal value


XSLT stylesheet components used by LinkedDataHub:

<xsl:include> is used to inclkude one stylesheet into another. The import mechanism is specified in 3.10.2 Stylesheet Inclusion the XSLT 3.0 specification. The templates from the included stylesheets have the same priority as those of the importing stylesheet.
<xsl:import> is used to import one stylesheet into another. The import mechanism is specified in 3.10.3 Stylesheet Import the XSLT 3.0 specification. The templates from the imported stylesheets have lower priority than those of the importing stylesheet.
XSD-typed global parameters passed to the stylesheet
Lookup keys
Template rules for XML node processing

One XSLT stylesheet can be specified per application. In order to reuse LinkedDataHub's built-in templates, it should import the system stylesheet layout.xsl and only override the necessary templates. That is however not a requirement, the stylesheet could also use its own independent transformation logic.

If there is no stylesheet specified for the application, the system stylesheet is used. It defines the overall layout and imports resource-level and container-specific stylesheets, as well as per-vocabulary stylesheets.

Note that LinkedDataHub itself imports stylesheets from Web-Client, which uses the same template modes but produces a much simpler layout.

There is also a special client-side stylesheet which is not used to render a full layout, but only manipulate DOM elements in the browser in response to user or system events. It is processed using Saxon-JS which provides IXSL (client-side extensions for XSLT). It imports and reuses some of the same sub-stylesheets as the server-side system stylesheet does, but avoids loading per-vocabulary stylesheets in order to improve page load time. Templates of the client-side stylesheet can also be overridden.


Main namespaces used in XSLT stylesheets
Prefix Namespace Vocabulary Description
rdf: The RDF Concepts Vocabulary Namespace for the RDF/XML elements, mostly used for matching input data
srx: Namespace for the SPARQL Query Results XML elements, mostly used for matching input data
xsl: Namespace for the XSLT stylesheet elements
ixsl: Namespace for the Interactive XSL extensions
bs2: XSLT-only namespace that is used for Bootstrap 2.3.2-based layout templates
xhtml: XSLT-only namespace that is used for generic (X)HTML templates
ldt: Linked Data Templates LDT processing-related concepts
ac: Web-Client vocabulary Client-side concepts
lapp: AtomGraph Platform LDT application concepts
lacl: LinkedDataHub ACL ontology ACL concepts


Both global (i.e. stylesheet-level) and template parameters are declared using <xsl:param>. For example:

<xsl:param name="ac:uri" as="xs:anyURI"/>

This parameter can be accessed using $ac:uri. For example:

<xsl:if test="$ac:uri">
    <xsl:value-of select="$ac:uri"/>

LinkedDataHub sets these global parameters by default (the list is not exhaustive):

Base URI of the current application
The URI of the ontology of the current application
The absolute URI of the current document (without query string)
The URI of the current layout mode
The URI of the class whose instance is being created.
RDF/XML document with the metadata of the current LDT application
RDF/XML document with the metadata of the currently authenticated agent (if any)


XSLT template components:

XPath-based match pattern which either does or does not match an XML node
Allows to group templates and distinguish them from other groups which have the same match patterns (e.g. different layout modes)
XSD-typed parameters passed to the template invocation
Contains the XML output nodes as well as XSLT processing instructions

XSLT processing starts at the root of the RDF/XML document and produces HTML elements by applying templates on all of the RDF/XML nodes while moving down the XML tree. In other words, it starts at the graph level, moves down to resource description elements, then to property elements, and ends with identifier attributes and literal text nodes.

Templates are applied (invoked) using <xsl:apply-templates>. Mode can be specified, e.g. <xsl:apply-templates mode="bs2:Header">. To stay in the current mode without explicitly specifying it, use <xsl:apply-templates mode="#current">. <xsl:with-param> is used to supply parameters.

LinkedDataHub provides the following default template modes, which are used to render the layout modes:

  • Graph-level modes that apply to rdf:RDF
    • bs2:Block which renders full resource description with all properties
    • bs2:BlockList renders a list of resources
    • xhtml:Table renders a table with resources as rows and properties as columns
    • bs2:Grid renders a gallery of thumbnails
    • bs2:Form which renders an RDF/POST form for for creation of new resources (when $ac:forClass parameter is set) or editing of existing resource
  • Resource-level templates modes that apply to rdf:Description
    • bs2:Block renders full resource description (by default header and property list)
    • bs2:Header renders resource header (by default with type information)
    • bs2:PropertyList renders definition list with property names and values (by default grouped by resource types)

When adding new user-defined modes, it is recommended to choose a new namespace for them as well as a user-defined prefix.

An example of a template that matches rdf:Description:

<xsl:template match="*[*][@rdf:about] | *[*][@rdf:nodeID]" mode="bs2:Block">
    <xsl:param name="id" as="xs:string?"/>
    <xsl:param name="class" as="xs:string?"/>

        <xsl:if test="$id">
            <xsl:attribute name="id" select="$id"/>
        <xsl:if test="$class">
            <xsl:attribute name="class" select="$class"/>

        <xsl:apply-templates select="." mode="bs2:Header"/>

        <xsl:apply-templates select="." mode="bs2:PropertyList"/>

ldh:ContentList mode renders the content specified by the rdf:_1 value of the current document.

There are a few special template modes such as ac:label and ac:description and related functions ac:label() and ac:description() which are used not to render layout but to extract metadata from resource descriptions. They can be used to retrieve a resource label and description no matter which RDF vocabularies are used in the data. They do so by invoking templates of respective mode from vocabulary-specific stylesheets.

Overriding templates

Templates are overridden by redefining them in the importing stylesheet and providing the same or more specific match pattern and the same mode. The XSLT specification specifies exactly how template priorities are determined in 6.4 Conflict Resolution for Template Rules.

The overriding template can then get the output of the overridden template by invoking either <xsl:apply-imports> or <xsl:next-match>. Read more about 6.7 Overriding Template Rules.

Always override the most specific template, i.e. if you want to change how a property is rendered, do not override the template for resource description, only the one for the property.


Keys are a lookup mechanism. They are defined on the stylesheet level using <xsl:key> and invoked using the key() function. For example:

<xsl:key name="resources" match="*[*][@rdf:about] | *[*][@rdf:nodeID]" use="@rdf:about | @rdf:nodeID"/>

<xsl:template match="*">
    <xsl:for-each select="key('resources', $ac:uri)">
        <xsl:value-of select="ac:label(.)"/>

They key definition matches rdf:Description elements and uses their identifiers (URI or blank node ID). The template then looks up the RDF description of the current resource, i.e. the resource with URI that equals $ac:uri which is the absolute URI of the current request, and outputs its label.

Loading data

The stylesheet is processing one main RDF/XML document at a time, which is supplied by the LinkedDataHub's HTML writer. However it is possible to load additional XML documents over HTTP using the document() XSLT function. To avoid XSLT errors on any possible error responses, it is advisable to do a conditional check using the doc-available() function before doing the actual document() call.

For example, instead of hardcoding the title of this document as Stylesheets, we can use the following code to load it and output it on the fly:

<xsl:value-of select="key('resources', '', document(''))"/>

In case this document changes its title, all such references would automatically render the updated title. On the other hand, it incurs the overhead of making an HTTP request.

LinkedDataHub's default stylesheets are using this feature extensively. In fact, one HTML page is rendered from a dozen of RDF/XML documents.

Built-in model ontologies as well as some other system and well-known ontologies, have a local copy in each LinkedDataHub instance. As a result, retrieving their descriptions by dereferencing their URIs using document() does not incur an HTTP request and is much faster. The URI-to-file mapping is defined as Jena's location mapping and can be found in location-mapping.n3 and prefix-mapping.n3.

Client-side stylesheets use ixsl:schedule-action to load XML documents asynchronously.


Bootstrap 2.3.2 theme is used with some customizations.

The CSS stylesheets is specified in the xhtml:Style XSLT template mode.


The JavaScript files are specified in the xhtml:Script XSLT template mode.

LinkedDataHub only uses JavaScript for the functionality that cannot be achieved using client-side XSLT.