LinkedDataHub: a low-code platform where applications are RDF data

Applications and documents are data, not code

LinkedDataHub is open source software for managing data, creating visualisations and building applications on RDF knowledge graphs, and its defining characteristic is a completely data-driven architecture. Applications and documents are defined as data, managed using a single generic HTTP API and presented using declarative technologies. The default application structure and user interface ship with the platform, but they can be completely overridden and customised. The README makes the practical consequence explicit: unless custom server-side processing is required, no imperative code such as Java or JavaScript needs to be involved at all. That is a real architectural position rather than a slogan, and it is what separates this from a graph visualisation library bolted onto a web framework. It also defines where the platform ends. The moment you need behaviour the declarative model cannot express, you are back to writing code, and the platform's value is that in most cases you do not. The two audiences named are researchers who need an RDF-native FAIR data environment that can consume and collect Linked Data and SPARQL documents, and developers who want a declarative full stack framework with an out of the box UI and API.

The primary language is XSLT, and the UI is one vocabulary

The primary language of the repository is XSLT, and that tells you how the presentation layer works. The rendering pipeline is declarative by construction rather than by convention. Version 6 redraws the interface on a design system that ships with the platform, and the app shell, content blocks, action bar, property lists, tables, modals and forms all render one class vocabulary. The single app layer is ldh.css, and a dataspace stylesheet overrides it, so a deployment changes the look of the whole platform through one stylesheet rather than by editing components. The README points out that Bootstrap 2 is gone with the bs2: template modes, and that the CHANGELOG describes what that means for an application stylesheet written against it, which is the kind of breaking change a version 6 release should call out plainly. The Makefile shows the same idea at build level. A dataspace serves its documents from the root of its origin, so the base URI is that root with no path component, and the Makefile computes that origin lazily so the error only fires when a target actually needs a URI. The Dockerfile compiles a client stylesheet into a SEF with a separate compiler stage.

Editing happens in the page with an RDFa-aware rich text editor

One capability is worth singling out because it is unusual for this class of platform. XHTML documents can be edited in place using a built-in RDFa-aware rich text editor, where annotations link selected text directly to Knowledge Graph terms and embed machine-readable RDF statements in the markup without leaving the page. The alternative approach, and the one most linked data tools force on you, is to edit in a separate editor and re-import the result, which breaks the round trip between what a reader sees and what the graph contains. Here the annotation is in the same document as the prose, so the connection between a term and the sentence describing it is preserved in the artefact itself. The README also notes that the project started with the intention of using it for Linked Data publishing and gradually became a multi-purpose data-driven platform, which is a fair description of how the feature set grew. The repository layout backs the platform claim with separate directories for the platform code, the rdf/ assets, the plugins/, the cli/ directory and the config/ directory.

Setup is Docker Compose plus generated certificates and three password files

The prerequisites are a bash shell 4.x, which is included by default on Linux, Docker with at least 8GB of memory dedicated to it, and Docker Compose. On Windows the documentation points at the Windows Subsystem for Linux. The installation sequence has a shape worth understanding before you run it. You fork the repository and clone the fork into a folder, then create an .env file filling out the missing values, using .env_sample as a template. The values include the compose settings, the protocol, the two ports and the host, plus owner identity fields:

     COMPOSE_CONVERT_WINDOWS_PATHS=1
     COMPOSE_PROJECT_NAME=linkeddatahub

     PROTOCOL=https
     HTTP_PORT=81
     HTTPS_PORT=4443
     HOST=localhost

Next you generate the server's SSL certificates with a script that takes the env file and two arguments:

     ./bin/server-cert-gen.sh .env nginx ssl

The script creates an ssl sub-folder where the certificates and public keys are placed. Then you create the password files, secrets/client_truststore_password.txt, secrets/owner_cert_password.txt and secrets/secretary_cert_password.txt, plus an optional secrets/openai_api_key.txt if you enable the assistant, which is declared in docker-compose.override.yml like the OAuth secrets. Without that key the assistant runs plans but cannot write them. The one password you must remember to authenticate with a WebID client certificate is owner_cert_password.

make up -- --build starts five services and mounts the state

The launch is a single make target, and the argument handling is the one detail that catches people out:

     make up -- --build

The README explains that make up passes its arguments on to docker-compose up, and that the double dash is required before any argument starting with a hyphen, otherwise make treats it as one of its own options. The command builds the Docker image, starts the container and mounts the state sub-folders. The ssl folder holds three sets of files: owner stores the root owner's WebID certificate, keystore and public key, secretary stores the root application's WebID certificate, keystore and public key, and server stores the server's certificate, which is also used by nginx. The data folder is where the triplestores persist RDF data, datasets is where the platform persists agent metadata files, and uploads is where it stores content-hashed file uploads. Startup takes up to half a minute while datasets are loaded into the triplestores, and after a successful start you should see periodic healthcheck requests to the https://localhost:4443/ns URL. The compose file shows the service topology, with nginx fronting the platform and depending on its health check, and the platform depending on fuseki, the sef-compiler and an egress service.

The compose file shows a triplestore, a compiler and a cache in front of it

Reading docker-compose.yml tells you what the platform actually runs. The nginx service uses the nginx:1.31.1 image with a 128m memory limit and is configured with an nginx_conf config mounted at /etc/nginx/nginx.conf. It publishes three ports: the HTTP port mapped to 8080 to let Tomcat do the HTTP to HTTPS redirect, the HTTPS port mapped to 8443, and an HTTPS client cert port mapped to 9443 that defaults to 5443. The linkeddatahub service is built from the repository Dockerfile and carries a 2048m memory limit, and it runs as root with a comment explaining why, since the ldh user does not have permissions to the mounted folder which is owned by root. The JVM is given a heap of up to 75 percent of the container RAM through CATALINA_OPTS, the timezone is set to Europe/Copenhagen, and the proxy settings point at nginx on port 9443. The Dockerfile itself is multi-stage. The first stage is maven:3.9-eclipse-temurin-21 and it downloads and extracts Apache Jena, pinned to a JENA_VERSION of 6.1.0, then resolves dependencies with a standalone Maven profile before installing the project. A separate node:22-alpine stage compiles the SEF, which the comments explain is out of process because the compile peaks around 1.5GB resident, which would be fatal beside a Tomcat heap sized at 75 percent of a 2GB limit.

The Makefile is meant to be byte-identical across deployments

The deployment Makefile carries an unusual convention that is worth reading before you change anything in it. Its header states that it is byte-identical across LinkedDataHub and every LDH-based deployment repo, following the same convention docker-compose.yml follows, and that it should not be edited per repo. The resync procedure is a copy of the canonical file, and the check is that diff between the two Makefiles must print nothing. Everything repository-specific goes into two optional includes, make/config.mk for variables such as which scripts to call and what drop wipes, and make/local.mk for targets a repository adds or replaces by naming them in LOCAL_TARGETS. The variables at the top of the file show the shape of a deployment. LDH_HOME points at the LinkedDataHub checkout and LDH at the ldh binary inside it, CERT_GEN at the certificate generation script, OWNER_CERT at the keystore path, and DROP_PATHS lists the directories a drop target wipes, namely datasets, fuseki, ssl, uploads, sef, packages and settings. The file also defines SEF_ENTRY as files/client.xsl and SEF_OUT as the compiled output, which is the client stylesheet artefact the compiler stage produces.

Editorial conclusion

LinkedDataHub suits research groups that need a FAIR, RDF-native data environment and a declarative way to publish and edit it without writing an application per dataset, and it suits developers who want a full stack framework where the UI and the API come from the same data model. It is the wrong choice for a small static site, for a team that does not want to operate a triplestore and a Java service, and for anyone who needs behaviour the declarative model cannot express without dropping into server-side code. Verify first that the version you deploy matches the version 6 design system you are reading about, that the make up target builds cleanly on your Docker setup with at least 8GB of memory, and that the WebID client certificate flow works with the browsers your users actually have.

Frequently asked questions

Official sources

1. AtomGraph/LinkedDataHub on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases