\n

Plain RDF/XML

\n

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:

\n

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

\n

\n

Stylesheets

\n

XSLT stylesheet components used by LinkedDataHub:

\n

\n

Includes

\n

<xsl:include> is used to include 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.

\n

Imports

\n

<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.

\n

Parameters

\n

XSD-typed global parameters passed to the stylesheet

\n

Keys

\n

Lookup keys

\n

Templates

\n

Template rules for XML node processing

\n

\n

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.

\n

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.

\n

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

\n

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.

\n

\n

Namespaces

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Main namespaces used in XSLT stylesheets

Prefix	Namespace	Vocabulary	Description
rdf:	http://www.w3.org/1999/02/22-rdf-syntax-ns#	The RDF Concepts Vocabulary	Namespace for the RDF/XML elements, mostly used for matching input data
srx:	http://www.w3.org/2005/sparql-results#		Namespace for the SPARQL Query Results XML elements, mostly used for matching input data
xsl:	http://www.w3.org/1999/XSL/Transform		Namespace for the XSLT stylesheet elements
ixsl:	http://saxonica.com/ns/interactiveXSLT		Namespace for the Interactive XSL extensions
bs2:	http://graphity.org/xsl/bootstrap/2.3.2		XSLT-only namespace that is used for Bootstrap 2.3.2-based layout templates
xhtml:	http://www.w3.org/2011/http#		XSLT-only namespace that is used for generic (X)HTML templates
ldt:	https://www.w3.org/ns/ldt#	Linked Data Templates	LDT processing-related concepts
ac:	https://w3id.org/atomgraph/client#	Web-Client vocabulary	Client-side concepts
lapp:	https://w3id.org/atomgraph/linkeddatahub/apps#	LinkedDataHub application ontology	LinkedDataHub application concepts
lacl:	https://w3id.org/atomgraph/linkeddatahub/admin/acl#	LinkedDataHub ACL ontology	ACL concepts

\n

\n

Parameters

\n

Both global (i.e. stylesheet-level) and template parameters are declared using <xsl:param>. LinkedDataHub sets the following global parameters by default (the list is non-exhaustive):

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Parameter	Type	Description
$ldt:base	xs:anyURI	Base URI of the current application
$lapp:Application	document-node()?	RDF/XML metadata of the current application
$foaf:Agent	document-node()?	RDF/XML metadata of the authenticated agent (if any)
$ldh:requestUri	xs:anyURI	Full request URI including query string
$ac:endpoint	xs:anyURI	SPARQL query endpoint URI (defaults to resolve-uri('sparql', $ldt:base))
$sd:endpoint	xs:anyURI?	Service-description endpoint URI, if different from $ac:endpoint
$acl:agent	xs:anyURI?	URI of the authenticated agent
$acl:mode	xs:anyURI*	ACL access modes granted for the current request
$ac:mode	xs:anyURI*	Current layout mode (derived: ldh:ContentMode if the document has content blocks, otherwise ac:ReadMode)
$lapp:origin	xs:anyURI	Origin URI of the current application

\n

\n

Functions

\n

LinkedDataHub and Web-Client provide XSLT functions available to all stylesheets.

\n

URI utility functions

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Function	Returns	Description
ac:absolute-path($href as xs:anyURI)	xs:anyURI	Strips query string and fragment from a URI, returning the path-only form
ac:build-uri(   $path as xs:anyURI?,   $params as map(xs:string, xs:string*) )	xs:anyURI?	Appends a percent-encoded query string built from the parameter map to $path
ac:document-uri($uri)	xs:anyURI	Strips the fragment identifier from a URI, making it suitable for use with document()
ac:fragment-id($uri as xs:anyURI)	xs:string?	Extracts the fragment identifier (the part after #)
ldh:request-uri()	xs:anyURI	Returns the full request URI including query string (server-side only)
ldh:base-uri($node as node())	xs:anyURI	Returns the base URI of an XML node; wraps the built-in base-uri()
ldh:href($uri as xs:anyURI?)	xs:anyURI	Resolves a URI to a local href, proxying external URIs through the LinkedDataHub proxy. Overloads accept $query-params as map(xs:string, xs:string*) and $fragment as xs:string?
ldh:query-params($mode as xs:anyURI*)	map(xs:string, xs:string*)	Builds a query parameter map for the given layout mode(s). Overload also accepts $forClass as xs:anyURI?
ldh:parse-query-params($query-string as xs:string)	map(xs:string, xs:string*)	Parses a URL query string into a map of key to value(s)

\n

RDF metadata functions

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Function	Returns	Description
ac:label($resource as element())	xs:string?	Extracts a human-readable label from an RDF resource description, trying multiple vocabulary properties
ac:description($resource as element())	xs:string?	Extracts a human-readable description from an RDF resource description

\n

HTTP and SPARQL functions

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Function	Returns	Description
ldh:query-result($endpoint as xs:anyURI, $query as xs:string)	document-node()	Executes a SPARQL query against the given endpoint and returns the result document (cached)
ldh:send-request(   $href as xs:anyURI,   $method as xs:string,   $media-type as xs:string?,   $body as item()?,   $headers as map(xs:string, xs:string) )	document-node()?	Makes an HTTP request and returns the response as a document (server-side extension function)

\n

\n

Templates

\n

XSLT template components:

\n

\n

Match

\n

XPath-based match pattern which either does or does not match an XML node

\n

Mode

\n

Allows to group templates and distinguish them from other groups which have the same match patterns (e.g. different layout modes)

\n

Parameters

\n

XSD-typed parameters passed to the template invocation

\n

Body

\n

Contains the XML output nodes as well as XSLT processing instructions

\n

\n

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.\n 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.

\n

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.

\n

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

\n

\n
• Graph-level modes that apply to rdf:RDF\n
  \n
  • default mode which renders full resource descriptions
  \n
  • bs2:BlockList renders a list of resources
  \n
  • xhtml:Table renders a table with resources as rows and properties as columns
  \n
  • bs2:Grid renders a gallery of thumbnails
  \n
  • 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
  \n
  \n
\n
• Resource-level templates modes that apply to rdf:Description\n
  \n
  • default mode renders full resource description (by default header and property list)
  \n
  • bs2:Header renders resource header (by default with type information)
  \n
  • bs2:PropertyList renders definition list with property names and values (by default grouped by resource types)
  \n
  \n
\n

\n

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

\n

An example of a template that matches rdf:Description:

\n

<xsl:template match=\"*[*][@rdf:about] | *[*][@rdf:nodeID]\">\n    <xsl:param name=\"id\" as=\"xs:string?\"/>\n    <xsl:param name=\"class\" as=\"xs:string?\"/>\n\n    <div>\n        <xsl:if test=\"$id\">\n            <xsl:attribute name=\"id\" select=\"$id\"/>\n        </xsl:if>\n        <xsl:if test=\"$class\">\n            <xsl:attribute name=\"class\" select=\"$class\"/>\n        </xsl:if>\n\n        <xsl:apply-templates select=\".\" mode=\"bs2:Header\"/>\n\n        <xsl:apply-templates select=\".\" mode=\"bs2:PropertyList\"/>\n    </div>\n</xsl:template>

\n

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

\n

There are a few special template modes such as ac:label and ac:description and related functions ac:label() and ac:description() which are\n 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\n vocabularies are used in the data. They do so by invoking templates of respective mode from vocabulary-specific stylesheets.

\n

\n

Overriding templates

\n

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.

\n

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.

\n

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.

\n

\n

Keys

\n

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

\n

<xsl:key name=\"resources\" match=\"*[*][@rdf:about] | *[*][@rdf:nodeID]\" use=\"@rdf:about | @rdf:nodeID\"/>\n\n<xsl:template match=\"*\">\n    <xsl:for-each select=\"key('resources', ldh:base-uri(.))\">\n        <xsl:value-of select=\"ac:label(.)\"/>\n    </xsl:for-each>\n</xsl:template>

\n

\n

Loading data

\n

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 \n using the document() XSLT function. To avoid XSLT errors on any possible error responses, it is advisable\n to do a conditional check using the doc-available() function before doing the actual document() call.

\n

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:

\n

<xsl:value-of select=\"key('resources', 'https://docs.linkeddatahub.com/reference/stylesheet/', document('https://docs.linkeddatahub.com/reference/stylesheet/'))\"/>

\n

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.

\n

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

\n

Built-in ontologies as well as some other system and well-known ontologies, have a local copy in\n 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\n is defined as Jena's location mapping and can be found in\n location-mapping.n3 and prefix-mapping.n3.

\n

Client-side stylesheets use <ixsl:schedule-action> (deprecated) and <ixsl:promise> to load XML documents asynchronously.

\n